My Webpage

IEEE Standard for Information technologyâ€” Telecommunications and information exchange between systems Local and metropolitan area networksâ€” Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications IEEE Computer Society Sponsored by the LAN/MAN Standards Committee IEEE 3 Park Avenue IEEE Std 802.11â„¢-2016 (Revision of New York, NY 10016-5997 IEEE Std 802.11-2012) USA IEEE Std 802.11â„¢-2016 (Revision of IEEE Std 802.11-2012) IEEE Standard for Information technologyâ€” Telecommunications and information exchange between systems Local and metropolitan area networksâ€” Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Prepared by the 802.11 Working Group of the LAN/MAN Standards Committee of the IEEE Computer Society Approved 7 December 2016 IEEE-SA Standards Board Abstract: Technical corrections and clarifications to IEEE Std 802.11 for wireless local area networks (WLANs) as well as enhancements to the existing medium access control (MAC) and physical layer (PHY) functions are specified in this revision. Amendments 1 to 5 published in 2012 and 2013 have also been incorporated into this revision. Keywords: 2.4 GHz, 256-QAM, 3650 MHz, 4.9 GHz, 5 GHz, 5.9 GHz, 60 GHz, advanced encryption standard, AES, audio, beamforming, carrier sense multiple access/collision avoidance, CCMP, channel switching, clustering, contention based access period, Counter mode with Cipher- block chaining Message authentication code Protocol, confidentiality, CSMA/CA, DFS, direct link, directional multi-gigabit, dynamic allocation of service period, dynamic extension of service period, dynamic frequency selection, dynamic truncation of service period, E911, EDCA, emergency alert system, emergency services, fast session transfer, forwarding, GCMP, generic advertisement service, high throughput, IEEE 802.11â„¢, international roaming, interworking, interworking with external networks, LAN, local area network, MAC, management, measurement, medium access control, media-independent handover, medium access controller, mesh, MIH, millimeter-wave, MIMO, MIMO-OFDM, multi-band operation, multi-hop, multi-user MIMO, multiple input multiple output, network advertisement, network discovery, network management, network selection, noncontiguous frequency segments, OCB, path-selection, personal basic service set, PHY, physical layer, power saving, QoS, quality of service, quality-of-service management frame, radio, radio frequency, RF, radio resource, radio management, relay operation, spatial sharing, SSPN, subscriber service provider, television white spaces, TPC, transmit power control, video, wireless access in vehicular environments, wireless LAN, wireless local area network, WLAN, wireless network management, zero-knowledge proof The Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue, New York, NY 10016-5997, USA Copyright Â© 2016 by The Institute of Electrical and Electronics Engineers, Inc. All rights reserved. Published 14 December 2016. Printed in the United States of America. IEEE is a registered trademark in the U.S. Patent & Trademark Office, owned by The Institute of Electrical and Electronics Engineers, Incorporated. Print: ISBN 978-1-5044-3646-5 STD22369 PDF: ISBN 978-1-5044-3645-8 STDPD22369 IEEE Prohibits discrimination, harassment, and bullying. For more information, visit http://www.ieee.org/web/aboutus/whatis/policies/p9-26.html. No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission of the publisher. Important Notices and Disclaimers Concerning IEEE Standards Documents IEEE documents are made available for use subject to important notices and legal disclaimers. These notices and disclaimers, or a reference to this page, appear in all standards and may be found under the heading â€œImportant Notices and Disclaimers Concerning IEEE Standards Documents.â€ They can also be obtained on request from IEEE or viewed at http://standards.ieee.org/IPR/disclaimers.html. Notice and Disclaimer of Liability Concerning the Use of IEEE Standards Docu- ments IEEE Standards documents (standards, recommended practices, and guides), both full-use and trial-use, are developed within IEEE Societies and the Standards Coordinating Committees of the IEEE Standards Association (â€œIEEE-SAâ€) Standards Board. IEEE (â€œthe Instituteâ€) develops its standards through a consensus development process, approved by the American National Standards Institute (â€œANSIâ€), which brings together volunteers representing varied viewpoints and interests to achieve the final product. IEEE Standards are documents developed through scientific, academic, and industry-based technical working groups. Volunteers in IEEE working groups are not necessarily members of the Institute and participate without compensation from IEEE. While IEEE administers the process and establishes rules to promote fairness in the consensus development process, IEEE does not independently evaluate, test, or verify the accuracy of any of the information or the soundness of any judgments contained in its standards. IEEE Standards do not guarantee or ensure safety, security, health, or environmental protection, or ensure against interference with or from other devices or networks. Implementers and users of IEEE Standards documents are responsible for determining and complying with all appropriate safety, security, environmental, health, and interference protection practices and all applicable laws and regulations. IEEE does not warrant or represent the accuracy or content of the material contained in its standards, and expressly disclaims all warranties (express, implied and statutory) not included in this or any other document relating to the standard, including, but not limited to, the warranties of: merchantability; fitness for a particular purpose; non- infringement; and quality, accuracy, effectiveness, currency, or completeness of material. In addition, IEEE disclaims any and all conditions relating to: results; and workmanlike effort. IEEE standards documents are supplied â€œAS ISâ€ and â€œWITH ALL FAULTS.â€ Use of an IEEE standard is wholly voluntary. The existence of an IEEE standard does not imply that there are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to the scope of the IEEE standard. Furthermore, the viewpoint expressed at the time a standard is approved and issued is subject to change brought about through developments in the state of the art and comments received from users of the standard. In publishing and making its standards available, IEEE is not suggesting or rendering professional or other services for, or on behalf of, any person or entity nor is IEEE undertaking to perform any duty owed by any other person or entity to another. Any person utilizing any IEEE Standards document, should rely upon his or her own independent judgment in the exercise of reasonable care in any given circumstances or, as appropriate, seek the advice of a competent professional in determining the appropriateness of a given IEEE standard. IN NO EVENT SHALL IEEE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO: PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE PUBLICATION, USE OF, OR RELIANCE UPON ANY STANDARD, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE AND REGARDLESS OF WHETHER SUCH DAMAGE WAS FORESEEABLE. Translations The IEEE consensus development process involves the review of documents in English only. In the event that an IEEE standard is translated, only the English version published by IEEE should be considered the approved IEEE standard. 3 Copyright Â© 2016 IEEE. All rights reserved. Official statements A statement, written or oral, that is not processed in accordance with the IEEE-SA Standards Board Operations Manual shall not be considered or inferred to be the official position of IEEE or any of its committees and shall not be considered to be, or be relied upon as, a formal position of IEEE. At lectures, symposia, seminars, or educational courses, an individual presenting information on IEEE standards shall make it clear that his or her views should be considered the personal views of that individual rather than the formal position of IEEE. Comments on standards Comments for revision of IEEE Standards documents are welcome from any interested party, regardless of membership affiliation with IEEE. However, IEEE does not provide consulting information or advice pertaining to IEEE Standards documents. Suggestions for changes in documents should be in the form of a proposed change of text, together with appropriate supporting comments. Since IEEE standards represent a consensus of concerned interests, it is important that any responses to comments and questions also receive the concurrence of a balance of interests. For this reason, IEEE and the members of its societies and Standards Coordinating Committees are not able to provide an instant response to comments or questions except in those cases where the matter has previously been addressed. For the same reason, IEEE does not respond to interpretation requests. Any person who would like to participate in revisions to an IEEE standard is welcome to join the relevant IEEE working group. Comments on standards should be submitted to the following address: Secretary, IEEE-SA Standards Board 445 Hoes Lane Piscataway, NJ 08854 USA Laws and regulations Users of IEEE Standards documents should consult all applicable laws and regulations. Compliance with the provisions of any IEEE Standards document does not imply compliance to any applicable regulatory requirements. Implementers of the standard are responsible for observing or referring to the applicable regulatory requirements. IEEE does not, by the publication of its standards, intend to urge action that is not in compliance with applicable laws, and these documents may not be construed as doing so. Copyrights IEEE draft and approved standards are copyrighted by IEEE under U.S. and international copyright laws. They are made available by IEEE and are adopted for a wide variety of both public and private uses. These include both use, by reference, in laws and regulations, and use in private self-regulation, standardization, and the promotion of engineering practices and methods. By making these documents available for use and adoption by public authorities and private users, IEEE does not waive any rights in copyright to the documents. Photocopies Subject to payment of the appropriate fee, IEEE will grant users a limited, non-exclusive license to photocopy portions of any individual standard for company or organizational internal use or individual, non-commercial use only. To arrange for payment of licensing fees, please contact Copyright Clearance Center, Customer Service, 222 Rosewood Drive, Danvers, MA 01923 USA; +1 978 750 8400. Permission to photocopy portions of any individual standard for educational classroom use can also be obtained through the Copyright Clearance Center. 4 Copyright Â© 2016 IEEE. All rights reserved. Updating of IEEE Standards documents Users of IEEE Standards documents should be aware that these documents may be superseded at any time by the issuance of new editions or may be amended from time to time through the issuance of amendments, corrigenda, or errata. An official IEEE document at any point in time consists of the current edition of the document together with any amendments, corrigenda, or errata then in effect. Every IEEE standard is subjected to review at least every ten years. When a document is more than ten years old and has not undergone a revision process, it is reasonable to conclude that its contents, although still of some value, do not wholly reflect the present state of the art. Users are cautioned to check to determine that they have the latest edition of any IEEE standard. In order to determine whether a given document is the current edition and whether it has been amended through the issuance of amendments, corrigenda, or errata, visit the IEEE-SA Website at http://ieeexplore.ieee.org or contact IEEE at the address listed previously. For more information about the IEEE SA or IEEEâ€™s standards development process, visit the IEEE-SA Website at http://standards.ieee.org. Errata Errata, if any, for all IEEE standards can be accessed on the IEEE-SA Website at the following URL: http:// standards.ieee.org/findstds/errata/index.html. Users are encouraged to check this URL for errata periodically. Patents Attention is called to the possibility that implementation of this standard may require use of subject matter covered by patent rights. By publication of this standard, no position is taken by the IEEE with respect to the existence or validity of any patent rights in connection therewith. If a patent holder or patent applicant has filed a statement of assurance via an Accepted Letter of Assurance, then the statement is listed on the IEEE-SA Website at http://standards.ieee.org/about/ sasb/patcom/patents.html. Letters of Assurance may indicate whether the Submitter is willing or unwilling to grant licenses under patent rights without compensation or under reasonable rates, with reasonable terms and conditions that are demonstrably free of any unfair discrimination to applicants desiring to obtain such licenses. Essential Patent Claims may exist for which a Letter of Assurance has not been received. The IEEE is not responsible for identifying Essential Patent Claims for which a license may be required, for conducting inquiries into the legal validity or scope of Patents Claims, or determining whether any licensing terms or conditions provided in connection with submission of a Letter of Assurance, if any, or in any licensing agreements are reasonable or non-discriminatory. Users of this standard are expressly advised that determination of the validity of any patent rights, and the risk of infringement of such rights, is entirely their own responsibility. Further information may be obtained from the IEEE Standards Association. 5 Copyright Â© 2016 IEEE. All rights reserved. Participants At the time this revision was sent to sponsor ballot, the IEEE 802.11 Working Group (WG) had the following officers: Adrian P. Stephens, Chair Jon W. Rosdahl, 1st Vice Chair Dorothy V. Stanley, 2nd Vice Chair Stephen McCann, Secretary The officers of the WG Task Group mc and the members of the WG ballot group for this revision are as follows: Dorothy V. Stanley, Chair Mark A. Hamilton, Vice Chair Jon W. Rosdahl, Secretary Adrian P. Stephens, Technical Editor Osama S. Aboulmagd Rojan Chitrakar Hiroshi Harada Santosh P. Abraham Jinsoo Choi Daniel N. Harkins Roberto Aiello Sangsung Choi Brian D. Hart Thomas Alexander Li Chia Chia Choo Ahmadreza Hedayat Peiman Amini Sayantan Choudhury Robert F. Heile Sirikiat Lek Ariyavisitakul Liwen Chu Jerome Henry Lee R. Armstrong Jinyoung Chun Chin Keong Ho Yusuke Asai John Coffey Anh Tuan Hoang Alex Ashley Kenneth Coop Dien Hoang Kwok Shum Au Carlos Cordeiro Wei Hong Vijay Auluck Neiyer Correal Ying-Chuan Hsiao Stefan Aust Subir Das Jing-Rong Hsieh David Bagby Hendricus De Ruijter David Hunter Eugene Baik Rolf J. de Vegt Yasuhiko Inoue Gabor Bajko Yohannes Demessie Mitsuru Iwaoka Raja Banerjea Michael Denson Wuncheol Jeong Phillip Barber Ting Dong Yangseok Jeong Anuj Batra Xiandong Dong Sunggeun Jin Tuncer Baykas Klaus Doppler ZhongYi Jin Alan Berkema Roger P. Durand Nihar Jindal Nehru Bhandaru Donald E. Eastlake V. K. Jones Philippe Boucachard Peter Ecclesine Jari Junell Andre Bourdoux Richard Edgar Padam Kafle John Buffington Amal Ekbal Carl W. Kain Lin Cai Marc Emmelmann Hyunduk Kang George Calcev Vinko Erceg Mika Kasslin Ping Fang Richard H. Kennedy Chris Calvert Stuart J. Kerry Radhakrishna Canchi Yonggang Fang Eunkyung Kim Laurent Cariou Qin Fei Jeongki Kim William Carney Stanislav Filin Jinho Kim Jaesun Cha Norman Finn Joo Young Kim Romana Challans Matthew J. Fischer Joonsuk Kim Kim Chang George Flammer Suhwook Kim Kuor-Hsin Chang Chittabrata Ghosh Taejoon Kim Xin Chang James P. K. Gilb Youhan Kim Clint F. Chaplin Reinhard Gloger Youngsoo Kim Bin Chen Daning Gong Shoichi Kitazawa Jiamin Chen David Goodall Jarkko Kneckt Jixin Chen Elad Gottlib Gwangzeen Ko Lidong Chen Sudheer A. Grandhi Fumihide Kojima Qian Chen Stephen Grau Tom Kolze Xi Chen Michael Grigat Timo Koskela Minho Cheong David Halasz Bruce P. Kraemer George Cherian Christopher J. Hansen Jin-Sam Kwak Francois Chin Peng Hao Joseph Kwak 6 Copyright Â© 2016 IEEE. All rights reserved. Hyoungjin Kwon Sandhya Patil Tong Tian Young Hoon Kwon Xiaoming Peng Jens Tingleff Paul Lambert Eldad Perahia Fei Tong Zhou Lan James E. Petranovich Ha Nguyen Tran Leonardo Lanante Albert Petrick Kazuyoshi Tsukada James Lansford John Petro Masahiro Umehira Jean-Pierre Le Rouzic Xu Ping Richard D. J. Van Nee Anseok Lee Juho Pirskanen Allert Van Zelst Donghun Lee Khiam Boon Png Prabodh Varshney Jae Seung Lee Vishakan Ponnampalam Sameer Vermani Wookbong Lee Ron Porat Dalton T. Victor Zhongding Lei Henry S. Ptasinski Gabriel Villardi Wai Kong Leung Rethnakaran Pulikkoonattu George A. Vlantis Joseph Levy Chang-Woo Chang Pyo Chao Chun Wang Feng Li Emily H. Qi Haiguang Wang Huan-Bang Li Huyu Qu Haiming Wang Liang Li Harish Ramamurthy James June Wang Lingjie Li Jayaram Ramasastry Lei Wang Yunbo Li Ivan Reede Lin Wang Yunzhou Li Edward Reuss Qi Wang Zhiqiang Li Maximilian Riegel Xiang Wang Erik Lindskog Mark Rison Xuehuan Wang Jianhan Liu Zhigang Rong Lisa Ward Pei Liu Cheol Ryu Zou Wei-Xia Yong Liu Kiseon Ryu Lei Wen Zongru Liu Kazuyuki Sakoda Menzo M. Wentink Peter Loc Ruben E. Salazar Cardozo Harya Wicaksana Su Lu Hemanth Sampath Eric Wong Long Luo Sigurd Schelstraete Harry R. Worstell Yi Luo Jean Schwoerer Tianyu Wu Zhendong Luo Jonathan Segev Zhanji Wu Kaiying Lv Cristina Seibert Zhenyu Xiao Michael Lynch Yongho Seok Dongmei Xu Jouni K. Malinen Kunal Shah Quanping Xu Hiroshi Mano Huairong Shao Guang-Qi Yang Simone Merlin Zhenhai Shao Lin Yang James Miller Stephen J. Shellhammer Xun Yang Keiichi Mizutani Ian Sherlock Yunsong Yang Apurva Mody Wei Shi Fan Ye Michael Montemurro Nobuhiko Shibagaki James Yee Kenichi Mori Shusaku Shimada Peter Yee Hitoshi Morioka Chang Sub Shin Wai-Leong Yeow Ronald Murias Thomas M. Siep Kaoru Yokoo Andrew Myles Michael Sim Su Khiong Khiong Yong Yukimasa Nagai Dwight Smith Christopher Young Yuhei Nagao Graham Kenneth Smith Heejung Yu Hiroki Nakano Myung Sun Song Zhan Yu Chiu Ngo Sudhir Srinivasa Tevfik Yucek Paul Nikolich Robert Stacey Guangrong Yue Hiroyo Ogawa Lawrence Stefani Katsuo D. A. Yunoki Minseok Oh Rene Struik Hongyuan Zhang Min-Seok Oh Jung Hoon Suh Hui Zhang David Olson Chin-Sean Sum Junjian Zhang Satoshi Oyama Bo Sun Nianzu Zhang Michael J. Paljug Chen Sun Xin Zhang Santos Ghanshyam Pandey Sheng Sun Mu Zhao Anna Pantelidou Kazuaki Takahashi Jun Zheng Giwon Park Mineo Takai Shoukang Zheng Minyoung Park Sagar Tamhane Mingtuo Zhou Seung-Hoon Park Joseph Teo Yan Zhuang Jaya Shankar Pathmasuntharam Thomas Tetzlaff Lan Zhuo Jerry Thrasher 7 Copyright Â© 2016 IEEE. All rights reserved. Major contributions were received from the following individuals: Carlos Aldana Mitsuru Iwaoka Kazuyuki Sakoda Yaron Alpert Assaf Kasher Amichai Sanderovich Edward Au Peter Khoury Sigurd Schelstraete Gabor Bajko Youhan Kim Yongho Seok Sean Coffey Wookbong Lee Graham Kenneth Smith Daniel Cohn Erik Lindskog Dorothy V. Stanley Carlos Cordeiro Jouni K. Malinen Adrian P. Stephens Peter Ecclesine Stephen McCann Bo Sun Vinko Erceg Michael Montemurro Fei Tong Matthew J. Fischer Hiroyuki Motozuka Payam Torab Michael Fischer Andrew Myles Solomon Trainin Mark A. Hamilton Eldad Perahia Ganesh Venkatesan Daniel N. Harkins Emily H. Qi Qi Wang Brian D. Hart Mark Rison Gaius Wee Guido R. Hiertz Jon W. Rosdahl Menzo M. Wentink Wei Hong Dick Roy Mingguang Xu David Hunter Chen Yanming The following members of the individual balloting committee voted on this revision. Balloters may have voted for approval, disapproval, or abstention. Osama S. Aboulmagd David Evans Assaf Kasher Tomoko Adachi Zhong Fan Ruediger Kays Iwan Adhicandra Liu Fangfang Stuart J. Kerry Thomas Alexander Matthew J. Fischer Yongbum Kim Richard Alfvin Michael Fischer Youhan Kim Nobumitsu Amachi Avraham Freedman Patrick Kinney Carol Ansley Dan Gal Bruce P. Kraemer Butch Anton Devon Gayle Yasushi Kudoh Yusuke Asai James P. K. Gilb Thomas Kurihara Alfred Asterjadhi Tim Godfrey Paul Lambert Stefan Aust Joel Goergen Jeremy Landt Michael Bahr Randall Groves Mark Laubach Gabor Bajko Robert Grow Hyeong Ho Lee Phillip Barber Michael Gundlach Wookbong Lee Tuncer Baykas Chris Guy James Lepp Mathilde Benveniste Gloria Gwynne Joseph Levy Harry Bims Rainer Hach Arthur H. Light Gennaro Boggia Russell Haines William Lumpkins Nancy Bravin Mark A. Hamilton Chris Lyttle Theodore Brillhart Christopher J. Hansen Elvis Maculuba Jerome Henry Jouni K. Malinen John Buffington James Marin William Byrd Marco Hernandez Roger Marks Brent Cain Guido Hiertz Jeffery Masters Radhakrishna Canchi Ronald Hochnadel Stephen McCann Fengming Cao Werner Hoelzl Michael McInnis William Carney David Hunter Filip Mestanov Juan Carreon Tetsushi Ikegami Apurva Mody Minho Cheong Noriyuki Ikeuchi Jose Morales Keith Chow Yasuhiko Inoue Ronald Murias Jinyoung Chun Sergiu Iordanescu Rick Murphy Charles Cook Akio Iso Andrew Myles Todor Cooklev Atsushi Ito Juichi Nakada Carlos Cordeiro Raj Jain Nabil Nasser Steven Crowley Michael Johas Teener Michael Newman Yezid Donoso Adri Jovin Chiu Ngo Sourav Dutta Joe Natharoj Juisai Nicks Nikjoo Donald E. Eastlake Naveen Kakani Paul Nikolich Peter Ecclesine Shinkyo Kaku Satoshi Obara Richard Edgar Hyunjeong Kang Robert Oâ€™Hara Marc Emmelmann Piotr Karocki Yoshihiro Ohba 8 Copyright Â© 2016 IEEE. All rights reserved. Satoshi Oyama Andy Scott Keat Beng Toh Stephen Palm Yongho Seok Payam Torab Glenn Parsons Kunal Shah Solomon Trainin Arumugam Paventhan Ian Sherlock Ha Nguyen Tran Brian Phelps Shusaku Shimada Kazuyoshi Tsukada Walter Pienciak Robert Slater Mark-Rene Uchida Subburajan Ponnuswamy Di Dieter Smely Lorenzo Vangelista Clinton Powell Graham Kenneth Smith Allert Van Zelst Venkatesha Prasad Daniel Smolinski Dmitri Varsanofiev Emily H. Qi Kapil Sood Prabodh Varshney R. K. Rannow Robert Stacey Ganesh Venkatesan George A. Vlantis Maximilian Riegel Dorothy V. Stanley Khurram Waheed Mark Rison Thomas Starai Haiming Wang Robert Robinson Adrian P. Stephens Lei Wang Benjamin Rolfe Rene Struik Stephen Webb Jon W. Rosdahl Walter Struppler Hung-Yu Wei Kazuyuki Sakoda Mark Sturza Menzo M. Wentink Osman Sakr Rakesh Taori Chun Yu Charles Wong Amichai Sanderovich David Tepen Forrest Wright John Santhoff Patricia Thaler James Yee Naotaka Sato David Thompson Oren Yuen Bartien Sayogo Edward Tiedemann Daidi Zhong Sigurd Schelstraete Jens Tingleff Zhen Zhou When the IEEE-SA Standards Board approved this revision on 7 December 2016, it had the following membership: Jean-Philippe Faure, Chair Ted Burse, Vice Chair John D. Kulick, Past Chair Konstantinos Karachalios, Secretary Chuck Adams Ronald W. Hotchkiss Mehmet Ulema Masayuki Ariyoshi Michael Janezic Yingli Wen Stephen Dukes Joseph L. Koepfinger* Howard Wolfman Jianbin Fan Hung Ling Don Wright J. Travis Griffith Kevin Lu Yu Yuan Gary Hoffman Annette D. Reilly Daidi Zhong Gary Robinson *Member Emeritus 9 Copyright Â© 2016 IEEE. All rights reserved. Introduction This introduction is not part of IEEE Std 802.11-2016, IEEE Standard for Information technologyâ€” Telecommunications and information exchange between systemsâ€”Local and metropolitan area networkâ€”Specific requirementsâ€”Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. This revision gives users, in one document, the IEEE 802.11 standard for wireless local area networks (WLANs) with all of the amendments that have been published to date. Incorporating published amendments The original standard was published in 1997, revised in 1999 with MIB changes, and reaffirmed in 2003. A revision was published in 2007, which incorporated into the 1999 edition the following amendments: â€” IEEE Std 802.11aâ„¢-1999: High-speed Physical Layer in the 5 GHz Band (Amendment 1) â€” IEEE Std 802.11bâ„¢-1999: Higher-Speed Physical Layer Extension in the 2.4 GHz Band (Amendment 2) â€” IEEE Std 802.11b-1999/Corrigendum 1-2001: Higher-speed Physical Layer (PHY) extension in the 2.4 GHz band (Corrigendum 1 to Amendment 2) â€” IEEE Std 802.11dâ„¢-2001: Specification for operation in additional regulatory domains (Amendment 3) â€” IEEE Std 802.11gâ„¢-2003: Further Higher Data Rate Extension in the 2.4 GHz Band (Amendment 4) â€” IEEE Std 802.11hâ„¢-2003: Spectrum and Transmit Power Management Extensions in the 5 GHz band in Europe (Amendment 5) â€” IEEE Std 802.11iâ„¢-2004: Medium Access Control (MAC) Security Enhancements (Amendment 6) â€” IEEE Std 802.11jâ„¢-2004: 4.9 GHzâ€“5 GHz Operation in Japan (Amendment 7) â€” IEEE Std 802.11eâ„¢-2005: Medium Access Control (MAC) Quality of Service Enhancements (Amendment 8) A revision was published in 2012, which incorporated into the 2007 revision the following amendments: â€” IEEE Std 802.11kâ„¢-2008: Radio Resource Measurement of Wireless LANs (Amendment 1) â€” IEEE Std 802.11râ„¢-2008: Fast Basic Service Set (BSS) Transition (Amendment 2) â€” IEEE Std 802.11yâ„¢-2008: 3650â€“3700 MHz Operation in USA (Amendment 3) â€” IEEE Std 802.11wâ„¢-2009: Protected Management Frames (Amendment 4) â€” IEEE Std 802.11nâ„¢-2009: Enhancements for Higher Throughput (Amendment 5) â€” IEEE Std 802.11pâ„¢-2010: Wireless Access in Vehicular Environments (Amendment 6) â€” IEEE Std 802.11zâ„¢-2010: Extensions to Direct-Link Setup (DLS) (Amendment 7) â€” IEEE Std 802.11vâ„¢-2011: Wireless Network Management (Amendment 8) â€” IEEE Std 802.11uâ„¢-2011: Interworking with External Networks (Amendment 9) â€” IEEE Std 802.11sâ„¢-2011: Mesh Networking (Amendment 10) This revision is based on IEEE Std 802.11-2012, into which the following amendments have been incorporated: â€” IEEE Std 802.11aeâ„¢-2012: Prioritization of Management Frames (Amendment 1) â€” IEEE Std 802.11aaâ„¢-2012: MAC Enhancements for Robust Audio Video Streaming (Amendment 2) 10 Copyright Â© 2016 IEEE. All rights reserved. â€” IEEE Std 802.11adâ„¢-2012: Enhancements for Very High Throughput in the 60 GHz Band (Amendment 3) â€” IEEE Std 802.11acâ„¢-2013: Enhancements for Very High Throughput for Operation in Bands below 6 GHz (Amendment 4) â€” IEEE Std 802.11afâ„¢-2013: Television White Spaces (TVWS) Operation (Amendment 5) Technical corrections, clarifications, and enhancements In addition, this revision specifies technical corrections and clarifications to IEEE Std 802.11 as well as enhancements to the existing medium access control (MAC) and physical layer (PHY) functions. In addition, this revision removes some features previously marked as obsolete and adds new indications of other obsolete features. 11 Copyright Â© 2016 IEEE. All rights reserved. Renumbering of clauses and annexes The numbering of certain clauses and annexes has been modified since IEEE Std 802.11-2012. The evolution of this numbering is shown in Figure i. Key: Unchanged Changed Deleted Amendments to Amendments to IEEE Std 802.11â€2007 IEEE Std 802.11â€2012 IEEE Std 802.11â€ 802.11â€2007 802.11â€2012 Clause 1 Clause 1 Clause 1 Clause 2 Clause 2 Clause 2 Clause 3 Clause 3 Clause 3 3.3 Clause 4 Clause 4 Clause 4 Clause 5 Clause 5 Clause 5 Clause 6 Clause 6 Clause 6 Clause 7 Clause 7 6.4 Clause 8 Clause 7 Clause 8 Clause 9 7.4 Clause 9 Clause 10 Clause 8 Clause 10 Clause 11 Clause 9 Clause 11 802.11w: Clause 11A Clause 10 Clause 12 801.11u: Clause 11B Clause 11 Clause 13 802.11s: Clause 11C Clause 12 Clause 14 Clause 12 Clause 13 Clause 15 Clause 13 Clause 14 Clause 16 Clause 14 Clause 15 Clause 17 Clause 15 Clause 16 Clause 18 Clause 16 Clause 17 Clause 19 Clause 17 Clause 18 Clause 20 Clause 18 Clause 19 Clause 21 Clause 19 Clause 20 Clause 22 802.11n: Clause 20 802.11ad: Clause 21 Annex A Annex A 802.11ac: Clause 22 Annex B Annex B 802.11af: Clause 23 Annex C Normative Annex C Annex A Annex D Annexes Annex D Annex B Annex E Annex E Annex C Annex F Annex F Annex D Annex G Annex G Annex E Annex H Annex H Annex F Annex I Annex I Annex G Annex J Annex J Annex H Annex K Annex K Annex I Annex L Annex L Annex J Annex M Informative Annex M Annex K Annex N Annexes Annex N Annex L Annex O Annex O Annex M Annex P Annex P Annex N Annex Q Annex O Annex R 802.11k: Annex Q Annex P Annex S 802.11n: Annex R Annex Q Annex T 802.11n: Annex S Annex R Annex U 802.11n: Annex T Annex S Annex V 802.11z: Annex U Annex T 802.11v: Annex V Annex U 802.11aa: Annex X 802.11v: Annex W Annex V 802.11ad: Annex Y 802.11u: Annex X Annex W 802.11ad: Annex Z 802.11s: Annex Y Figure iâ€”The evolution of numbering in IEEE Std 802.11 12 Copyright Â© 2016 IEEE. All rights reserved. Contents 1. Overview............................................................................................................................................ 122 1.1 Scope...................................................................................................................................... 122 1.2 Purpose................................................................................................................................... 122 1.3 Supplementary information on purpose................................................................................. 122 1.4 Word usage ............................................................................................................................ 123 1.5 Terminology for mathematical, logical, and bit operations................................................... 124 2. Normative references ......................................................................................................................... 125 3. Definitions, acronyms, and abbreviations.......................................................................................... 128 3.1 Definitions ............................................................................................................................. 128 3.2 Definitions specific to IEEE Std 802.11 ................................................................................ 143 3.3 Definitions specific to IEEE 802.11 operation in some regulatory domains......................... 170 3.4 Abbreviations and acronyms ................................................................................................. 170 3.5 Abbreviations and acronyms in some regulatory domains .................................................... 182 4. General description ............................................................................................................................ 183 4.1 General description of the architecture .................................................................................. 183 4.2 How wireless local area networks (WLANs) are different.................................................... 183 4.2.1 Introduction............................................................................................................ 183 4.2.2 Wireless station (STA)........................................................................................... 183 4.2.3 Media impact on design and performance ............................................................. 183 4.2.4 The impact of handling mobile STAs.................................................................... 184 4.2.5 Interaction with other IEEE 802Â® layers............................................................... 184 4.2.6 Interaction with non-IEEE-802 protocols.............................................................. 184 4.3 Components of the IEEE 802.11 architecture ....................................................................... 184 4.3.1 General................................................................................................................... 184 4.3.2 The independent BSS (IBSS) ................................................................................ 185 4.3.3 The personal BSS (PBSS)...................................................................................... 185 4.3.4 STA membership in a BSS is dynamic.................................................................. 185 4.3.5 Distribution system (DS) concepts ........................................................................ 186 4.3.5.1 Overview............................................................................................. 186 4.3.5.2 Extended service set (ESS): the large coverage network.................... 187 4.3.6 Area concepts......................................................................................................... 188 4.3.7 Integration with non-IEEE-802.11 LANs.............................................................. 189 4.3.8 Robust security network association (RSNA) ....................................................... 190 4.3.9 Centralized coordination service set (CCSS) and extended centralized AP or PCP clustering (ECAPC)............................................................................. 190 4.3.10 QoS BSS ................................................................................................................ 192 4.3.11 Wireless LAN radio measurements ....................................................................... 193 4.3.11.1 General ................................................................................................ 193 4.3.11.2 Beacon................................................................................................. 194 4.3.11.3 Measurement pilot............................................................................... 194 4.3.11.4 Frame .................................................................................................. 194 4.3.11.5 Channel load ....................................................................................... 195 4.3.11.6 Noise histogram .................................................................................. 195 4.3.11.7 STA statistics ...................................................................................... 195 4.3.11.8 Location .............................................................................................. 195 4.3.11.9 Measurement pause............................................................................. 195 13 Copyright Â© 2016 IEEE. All rights reserved. 4.3.11.10 Neighbor report ................................................................................... 195 4.3.11.11 Link measurement............................................................................... 195 4.3.11.12 Transmit stream/category measurement ............................................. 195 4.3.12 Operation in licensed frequency bands .................................................................. 196 4.3.12.1 General ................................................................................................ 196 4.3.12.2 Dynamic STA enablement (DSE) in licensed bands .......................... 196 4.3.12.3 Contention based protocol (CBP) in nonexclusively licensed bands . 196 4.3.12.4 Using DSE STA identification to resolve interference....................... 196 4.3.12.5 Further coexistence enhancements in nonexclusively licensed bands 196 4.3.13 High-throughput (HT) STA ................................................................................... 196 4.3.14 Very high throughput (VHT) STA ........................................................................ 197 4.3.15 Television very high throughput (TVHT) STA ..................................................... 198 4.3.16 STA transmission of Data frames outside the context of a BSS ........................... 199 4.3.17 Tunneled direct-link setup ..................................................................................... 200 4.3.18 Wireless network management .............................................................................. 200 4.3.18.1 Overview............................................................................................. 200 4.3.18.2 BSS max idle period management ...................................................... 201 4.3.18.3 BSS transition management ................................................................ 201 4.3.18.4 Channel usage ..................................................................................... 201 4.3.18.5 Collocated interference reporting........................................................ 201 4.3.18.6 Diagnostic reporting............................................................................ 201 4.3.18.7 Directed multicast service (DMS)....................................................... 201 4.3.18.8 Event reporting.................................................................................... 202 4.3.18.9 Flexible multicast service (FMS)........................................................ 202 4.3.18.10 Location services................................................................................. 202 4.3.18.11 Multicast Diagnostic report................................................................. 202 4.3.18.12 Multiple BSSID capability.................................................................. 202 4.3.18.13 Proxy ARP .......................................................................................... 202 4.3.18.14 QoS traffic capability .......................................................................... 202 4.3.18.15 SSID list .............................................................................................. 203 4.3.18.16 Triggered STA statistics...................................................................... 203 4.3.18.17 TIM broadcast ..................................................................................... 203 4.3.18.18 Timing measurement........................................................................... 203 4.3.18.19 Fine timing measurement.................................................................... 203 4.3.18.20 Traffic filtering service ....................................................................... 203 4.3.18.21 U-APSD coexistence........................................................................... 203 4.3.18.22 WNM notification ............................................................................... 203 4.3.18.23 WNM sleep mode ............................................................................... 204 4.3.19 Subscription service provider network (SSPN) interface ...................................... 204 4.3.20 Mesh BSS .............................................................................................................. 205 4.3.20.1 General ................................................................................................ 205 4.3.20.2 Overview of the mesh BSS ................................................................. 205 4.3.20.3 Mesh STA ........................................................................................... 205 4.3.20.4 IEEE 802.11 components and mesh BSS ........................................... 206 4.3.20.5 Introduction to mesh functions ........................................................... 207 4.3.21 DMG STA.............................................................................................................. 210 4.3.22 DMG relay ............................................................................................................. 211 4.3.23 Robust audio video (AV) streaming ...................................................................... 211 4.3.23.1 Groupcast with retries (GCR) ............................................................. 211 4.3.23.2 Stream classification service (SCS) .................................................... 212 4.3.23.3 Overlapping BSS (OBSS) management ............................................. 212 4.3.23.4 Interworking with IEEE 802.1Qâ„¢ Stream Reservation Protocol (SRP)................................................................................................... 212 4.3.23.5 Intra-access category prioritization ..................................................... 212 14 Copyright Â© 2016 IEEE. All rights reserved. 4.3.24 Operation under geolocation database (GDB) control .......................................... 213 4.4 Logical service interfaces ...................................................................................................... 215 4.4.1 General................................................................................................................... 215 4.4.2 SS ........................................................................................................................... 215 4.4.3 PBSS control point service (PCPS) ....................................................................... 216 4.4.4 DSS ........................................................................................................................ 216 4.5 Overview of the services........................................................................................................ 217 4.5.1 General................................................................................................................... 217 4.5.2 Distribution of MSDUs within a DS...................................................................... 218 4.5.2.1 Distribution ......................................................................................... 218 4.5.2.2 Integration ........................................................................................... 219 4.5.2.3 QoS traffic scheduling ........................................................................ 219 4.5.3 Services that support the distribution service and the PCP service ....................... 220 4.5.3.1 General ................................................................................................ 220 4.5.3.2 Mobility types ..................................................................................... 220 4.5.3.3 Association.......................................................................................... 220 4.5.3.4 Reassociation ...................................................................................... 221 4.5.3.5 Disassociation ..................................................................................... 221 4.5.4 Access control and data confidentiality services ................................................... 222 4.5.4.1 General ................................................................................................ 222 4.5.4.2 Authentication..................................................................................... 222 4.5.4.3 Deauthentication ................................................................................. 223 4.5.4.4 Data confidentiality............................................................................. 223 4.5.4.5 Key management................................................................................. 224 4.5.4.6 Data origin authenticity....................................................................... 224 4.5.4.7 Replay detection.................................................................................. 224 4.5.4.8 Fast BSS transition.............................................................................. 225 4.5.4.9 Robust management frame protection ................................................ 225 4.5.5 Spectrum management services............................................................................. 225 4.5.5.1 General ................................................................................................ 225 4.5.5.2 TPC ..................................................................................................... 225 4.5.5.3 DFS ..................................................................................................... 225 4.5.6 Traffic differentiation and QoS support................................................................. 226 4.5.6.1 General ................................................................................................ 226 4.5.6.2 Quality-of-service management frame support................................... 226 4.5.7 Support for higher layer timer synchronization ..................................................... 226 4.5.8 Radio measurement service ................................................................................... 227 4.5.9 Interworking with external networks ..................................................................... 227 4.5.10 Generic advertisement service (GAS) ................................................................... 228 4.6 Multiple logical address spaces ............................................................................................. 228 4.7 Differences among ESS, PBSS, and IBSS LANs.................................................................. 229 4.8 Differences between ESS and MBSS LANs ......................................................................... 231 4.9 Reference model .................................................................................................................... 231 4.9.1 General................................................................................................................... 231 4.9.2 Interworking reference model................................................................................ 231 4.9.3 Reference model for supporting multiple MAC sublayers .................................... 233 4.9.4 Reference model for multi-band operation ............................................................ 234 4.10 IEEE Std 802.11 and IEEE Std 802.1X-2010 ....................................................................... 236 4.10.1 General................................................................................................................... 236 4.10.2 IEEE 802.11 usage of IEEE Std 802.1X-2010 ...................................................... 236 4.10.3 Infrastructure functional model overview.............................................................. 237 4.10.3.1 General ................................................................................................ 237 4.10.3.2 AKM operations with AS ................................................................... 237 4.10.3.3 AKM operations with a password or PSK .......................................... 239 15 Copyright Â© 2016 IEEE. All rights reserved. 4.10.3.4 Alternate operations with PSK............................................................ 240 4.10.3.5 Disassociation ..................................................................................... 241 4.10.4 IBSS functional model description ........................................................................ 241 4.10.4.1 General ................................................................................................ 241 4.10.4.2 Key usage............................................................................................ 241 4.10.4.3 Sample IBSS 4-way handshakes......................................................... 241 4.10.4.4 IBSS IEEE 802.1X example ............................................................... 243 4.10.5 PBSS functional model description ....................................................................... 244 4.10.6 Authenticator-to-AS protocol ................................................................................ 245 4.10.7 PMKSA caching .................................................................................................... 245 4.10.8 Protection of group addressed robust Management frames................................... 245 5. MAC service definition ..................................................................................................................... 246 5.1 Overview of MAC services ................................................................................................... 246 5.1.1 Data service............................................................................................................ 246 5.1.1.1 General ................................................................................................ 246 5.1.1.2 Determination of UP ........................................................................... 246 5.1.1.3 Interpretation of priority parameter in MAC service primitives......... 246 5.1.1.4 Interpretation of service class parameter in MAC service primitives in a STA ............................................................................. 247 5.1.2 Security services .................................................................................................... 248 5.1.3 MSDU ordering ..................................................................................................... 248 5.1.4 MSDU format ........................................................................................................ 249 5.1.5 MAC data service architecture .............................................................................. 250 5.1.5.1 General ................................................................................................ 250 5.1.5.2 Non-AP STA role................................................................................ 253 5.1.5.3 AP role ................................................................................................ 253 5.1.5.4 Mesh STA role .................................................................................... 253 5.1.5.5 Mesh gate role..................................................................................... 254 5.2 MAC data service specification ............................................................................................. 254 5.2.1 General................................................................................................................... 254 5.2.2 MA-UNITDATA.request ...................................................................................... 254 5.2.2.1 Function .............................................................................................. 254 5.2.2.2 Semantics of the service primitive ...................................................... 255 5.2.2.3 When generated................................................................................... 255 5.2.2.4 Effect of receipt................................................................................... 255 5.2.3 MA-UNITDATA.indication .................................................................................. 257 5.2.3.1 Function .............................................................................................. 257 5.2.3.2 Semantics of the service primitive ...................................................... 257 5.2.3.3 When generated................................................................................... 257 5.2.3.4 Effect of receipt................................................................................... 258 5.2.4 MA-UNITDATA-STATUS.indication.................................................................. 259 5.2.4.1 Function .............................................................................................. 259 5.2.4.2 Semantics of the service primitive ...................................................... 259 5.2.4.3 When generated................................................................................... 261 5.2.4.4 Effect of receipt................................................................................... 261 6. Layer management............................................................................................................................. 262 6.1 Overview of management model ........................................................................................... 262 6.2 Generic management primitives ............................................................................................ 263 6.3 MLME SAP interface ............................................................................................................ 263 6.3.1 Introduction............................................................................................................ 263 16 Copyright Â© 2016 IEEE. All rights reserved. 6.3.2 Power management................................................................................................ 264 6.3.2.1 Introduction......................................................................................... 264 6.3.2.2 MLME-POWERMGT.request............................................................ 264 6.3.2.3 MLME-POWERMGT.confirm........................................................... 264 6.3.3 Scan........................................................................................................................ 265 6.3.3.1 Introduction......................................................................................... 265 6.3.3.2 MLME-SCAN.request ........................................................................ 265 6.3.3.3 MLME-SCAN.confirm ....................................................................... 267 6.3.4 Synchronization ..................................................................................................... 276 6.3.4.1 Introduction......................................................................................... 276 6.3.4.2 MLME-JOIN.request .......................................................................... 276 6.3.4.3 MLME-JOIN.confirm ......................................................................... 278 6.3.5 Authenticate ........................................................................................................... 279 6.3.5.1 Introduction......................................................................................... 279 6.3.5.2 MLME-AUTHENTICATE.request .................................................... 279 6.3.5.3 MLME-AUTHENTICATE.confirm ................................................... 280 6.3.5.4 MLME-AUTHENTICATE.indication................................................ 282 6.3.5.5 MLME-AUTHENTICATE.response.................................................. 283 6.3.6 Deauthenticate ....................................................................................................... 284 6.3.6.1 Introduction......................................................................................... 284 6.3.6.2 MLME-DEAUTHENTICATE.request............................................... 284 6.3.6.3 MLME-DEAUTHENTICATE.confirm.............................................. 285 6.3.6.4 MLME-DEAUTHENTICATE.indication .......................................... 285 6.3.7 Associate ................................................................................................................ 286 6.3.7.1 Introduction......................................................................................... 286 6.3.7.2 MLME-ASSOCIATE.request............................................................. 286 6.3.7.3 MLME-ASSOCIATE.confirm............................................................ 288 6.3.7.4 MLME-ASSOCIATE.indication ........................................................ 292 6.3.7.5 MLME-ASSOCIATE.response .......................................................... 295 6.3.8 Reassociate............................................................................................................. 297 6.3.8.1 Introduction......................................................................................... 297 6.3.8.2 MLME-REASSOCIATE.request........................................................ 297 6.3.8.3 MLME-REASSOCIATE.confirm....................................................... 299 6.3.8.4 MLME-REASSOCIATE.indication ................................................... 303 6.3.8.5 MLME-REASSOCIATE.response ..................................................... 306 6.3.9 Disassociate ........................................................................................................... 309 6.3.9.1 MLME-DISASSOCIATE.request ...................................................... 309 6.3.9.2 MLME-DISASSOCIATE.confirm ..................................................... 309 6.3.9.3 MLME-DISASSOCIATE.indication.................................................. 310 6.3.10 Reset....................................................................................................................... 310 6.3.10.1 Introduction......................................................................................... 310 6.3.10.2 MLME-RESET.request....................................................................... 311 6.3.11 Start ........................................................................................................................ 311 6.3.11.1 Introduction......................................................................................... 311 6.3.11.2 MLME-START.request ...................................................................... 311 6.3.11.3 MLME-START.confirm ..................................................................... 317 6.3.12 Stop ........................................................................................................................ 317 6.3.12.1 General ................................................................................................ 317 6.3.12.2 MLME-STOP.request ......................................................................... 317 6.3.13 Protocol layer model for spectrum management and radio measurement............. 318 6.3.14 Measurement request ............................................................................................. 321 6.3.14.1 Introduction......................................................................................... 321 6.3.14.2 MLME-MREQUEST.request ............................................................. 321 6.3.14.3 MLME-MREQUEST.indication......................................................... 322 17 Copyright Â© 2016 IEEE. All rights reserved. 6.3.15 Channel measurement............................................................................................ 323 6.3.15.1 Introduction......................................................................................... 323 6.3.15.2 MLME-MEASURE.request................................................................ 323 6.3.15.3 MLME-MEASURE.confirm............................................................... 324 6.3.16 Measurement report ............................................................................................... 325 6.3.16.1 Introduction......................................................................................... 325 6.3.16.2 MLME-MREPORT.request................................................................ 325 6.3.16.3 MLME-MREPORT.indication ........................................................... 326 6.3.17 Channel switch....................................................................................................... 327 6.3.17.1 MLME-CHANNELSWITCH.request ................................................ 327 6.3.17.2 MLME-CHANNELSWITCH.confirm ............................................... 328 6.3.17.3 MLME-CHANNELSWITCH.indication............................................ 328 6.3.17.4 MLME-CHANNELSWITCH.response.............................................. 329 6.3.18 TPC request............................................................................................................ 331 6.3.18.1 Introduction......................................................................................... 331 6.3.18.2 MLME-TPCADAPT.request .............................................................. 331 6.3.18.3 MLME-TPCADAPT.confirm ............................................................. 331 6.3.19 SetKeys .................................................................................................................. 332 6.3.19.1 MLME-SETKEYS.request ................................................................. 332 6.3.20 DeleteKeys............................................................................................................. 333 6.3.20.1 MLME-DELETEKEYS.request ......................................................... 333 6.3.21 MIC (michael) failure event .................................................................................. 334 6.3.21.1 MLME-MICHAELMICFAILURE.indication.................................... 334 6.3.22 EAPOL................................................................................................................... 335 6.3.22.1 MLME-EAPOL.request...................................................................... 335 6.3.22.2 MLME-EAPOL.confirm..................................................................... 336 6.3.23 MLME-PEERKEY-START .................................................................................. 336 6.3.23.1 MLME-PEERKEY-START.request................................................... 336 6.3.24 SetProtection .......................................................................................................... 337 6.3.24.1 MLME-SETPROTECTION.request................................................... 337 6.3.25 MLME-PROTECTEDFRAMEDROPPED ........................................................... 338 6.3.25.1 MLME- PROTECTEDFRAMEDROPPED.indication ...................... 338 6.3.26 TS management interface ...................................................................................... 338 6.3.26.1 General ................................................................................................ 338 6.3.26.2 MLME-ADDTS.request ..................................................................... 339 6.3.26.3 MLME-ADDTS.confirm .................................................................... 341 6.3.26.4 MLME-ADDTS.indication ................................................................. 344 6.3.26.5 MLME-ADDTS.response ................................................................... 346 6.3.26.6 MLME-DELTS.request ...................................................................... 349 6.3.26.7 MLME-DELTS.indication.................................................................. 350 6.3.26.8 MLME-ADDTSRESERVE.request ................................................... 351 6.3.26.9 MLME-ADDTSRESERVE.confirm................................................... 352 6.3.26.10 MLME-ADDTSRESERVE.indication ............................................... 353 6.3.26.11 MLME-ADDTSRESERVE.response ................................................. 354 6.3.27 Management of direct links ................................................................................... 354 6.3.27.1 Introduction......................................................................................... 354 6.3.27.2 MLME-DLS.request ........................................................................... 355 6.3.27.3 MLME-DLS.confirm .......................................................................... 355 6.3.27.4 MLME-DLS.indication....................................................................... 356 6.3.27.5 MLME-DLS.response......................................................................... 357 6.3.27.6 MLME-DLS-TEARDOWN.request ................................................... 358 6.3.27.7 MLME-DLS-TEARDOWN.indication............................................... 359 6.3.28 Higher layer synchronization support.................................................................... 360 6.3.28.1 Introduction......................................................................................... 360 18 Copyright Â© 2016 IEEE. All rights reserved. 6.3.28.2 MLME-HL-SYNC.request ................................................................. 360 6.3.28.3 MLME-HL-SYNC.indication ............................................................. 361 6.3.29 Block Ack .............................................................................................................. 361 6.3.29.1 General ................................................................................................ 361 6.3.29.2 MLME-ADDBA.request..................................................................... 361 6.3.29.3 MLME-ADDBA.confirm ................................................................... 363 6.3.29.4 MLME-ADDBA.indication ................................................................ 364 6.3.29.5 MLME-ADDBA.response .................................................................. 365 6.3.29.6 MLME-DELBA.request ..................................................................... 367 6.3.29.7 MLME-DELBA.indication ................................................................. 368 6.3.30 Schedule element management.............................................................................. 369 6.3.30.1 Introduction......................................................................................... 369 6.3.30.2 MLME-SCHEDULE.request.............................................................. 369 6.3.30.3 MLME-SCHEDULE.indication ......................................................... 369 6.3.31 Vendor-specific action ........................................................................................... 370 6.3.31.1 Introduction......................................................................................... 370 6.3.31.2 MLME-VSPECIFIC.request............................................................... 370 6.3.31.3 MLME-VSPECIFIC.indication .......................................................... 371 6.3.32 Neighbor report request ......................................................................................... 372 6.3.32.1 General ................................................................................................ 372 6.3.32.2 MLME-NEIGHBORREPREQ.request............................................... 372 6.3.32.3 MLME-NEIGHBORREPREQ.indication .......................................... 373 6.3.33 Neighbor report response....................................................................................... 374 6.3.33.1 General ................................................................................................ 374 6.3.33.2 MLME-NEIGHBORREPRESP.request ............................................. 374 6.3.33.3 MLME-NEIGHBORREPRESP.indication......................................... 375 6.3.34 Link Measure Request ........................................................................................... 376 6.3.34.1 General ................................................................................................ 376 6.3.34.2 MLME-LINKMEASURE.request ...................................................... 376 6.3.34.3 MLME-LINKMEASURE.confirm ..................................................... 377 6.3.35 MLME SAP interface for resource request ........................................................... 378 6.3.35.1 MLME-RESOURCE-REQUEST.request........................................... 378 6.3.35.2 MLME-RESOURCE-REQUEST.indication ...................................... 379 6.3.35.3 MLME-RESOURCE-REQUEST.response ........................................ 380 6.3.35.4 MLME-RESOURCE-REQUEST.confirm ......................................... 380 6.3.35.5 MLME-RESOURCE-REQUEST-LOCAL.request............................ 381 6.3.35.6 MLME-RESOURCE-REQUEST-LOCAL.confirm........................... 382 6.3.36 MLME SAP interface for remote requests ............................................................ 382 6.3.36.1 MLME-REMOTE-REQUEST.request ............................................... 382 6.3.36.2 MLME-REMOTE-REQUEST.indication........................................... 383 6.3.37 Extended channel switch announcement ............................................................... 383 6.3.37.1 General ................................................................................................ 383 6.3.37.2 MLME-EXTCHANNELSWITCH.request......................................... 384 6.3.37.3 MLME-EXTCHANNELSWITCH.confirm ....................................... 385 6.3.37.4 MLME-EXTCHANNELSWITCH.indication .................................... 385 6.3.37.5 MLME-EXTCHANNELSWITCH.response ...................................... 387 6.3.38 DSE power constraint announcement.................................................................... 388 6.3.38.1 General ................................................................................................ 388 6.3.38.2 MLME-DSETPC.request.................................................................... 388 6.3.38.3 MLME-DSETPC.confirm................................................................... 389 6.3.38.4 MLME-DSETPC.indication ............................................................... 390 6.3.38.5 MLME-DSETPC.response ................................................................. 390 6.3.39 Enablement ............................................................................................................ 391 6.3.39.1 General ................................................................................................ 391 19 Copyright Â© 2016 IEEE. All rights reserved. 6.3.39.2 MLME-ENABLEMENT.request........................................................ 391 6.3.39.3 MLME-ENABLEMENT.confirm....................................................... 392 6.3.39.4 MLME-ENABLEMENT.indication ................................................... 393 6.3.39.5 MLME-ENABLEMENT.response ..................................................... 394 6.3.40 Deenablement ........................................................................................................ 395 6.3.40.1 MLME-DEENABLEMENT.request .................................................. 395 6.3.40.2 MLME-DEENABLEMENT.indication.............................................. 396 6.3.41 SA Query support .................................................................................................. 397 6.3.41.1 MLME-SA-QUERY.request............................................................... 397 6.3.41.2 MLME-SA-QUERY.confirm ............................................................. 398 6.3.41.3 MLME-SA-QUERY.indication .......................................................... 398 6.3.41.4 MLME-SA-QUERY.response ............................................................ 399 6.3.42 Get TSF timer ........................................................................................................ 400 6.3.42.1 General ................................................................................................ 400 6.3.42.2 MLME-GETTSFTIME.request .......................................................... 400 6.3.42.3 MLME-GETTSFTIME.confirm ......................................................... 400 6.3.43 Timing Advertisement ........................................................................................... 401 6.3.43.1 General ................................................................................................ 401 6.3.43.2 MLME-TIMING-ADVERTISEMENT.request ................................. 401 6.3.43.3 MLME-TIMING-ADVERTISEMENT.indication ............................. 402 6.3.44 TDLS Discovery .................................................................................................... 403 6.3.44.1 General ................................................................................................ 403 6.3.44.2 MLME-TDLSDISCOVERY.request.................................................. 403 6.3.44.3 MLME-TDLSDISCOVERY.confirm................................................. 404 6.3.44.4 MLME-TDLSDISCOVERY.indication ............................................. 405 6.3.44.5 MLME-TDLSDISCOVERY.response ............................................... 405 6.3.45 TDLS direct-link establishment............................................................................. 406 6.3.45.1 General ................................................................................................ 406 6.3.45.2 MLME-TDLSSETUPREQUEST.request........................................... 406 6.3.45.3 MLME-TDLSSETUPREQUEST.indication ...................................... 407 6.3.45.4 MLME-TDLSSETUPRESPONSE.request......................................... 408 6.3.45.5 MLME-TDLSSETUPRESPONSE.indication .................................... 409 6.3.45.6 MLME-TDLSSETUPCONFIRM.request .......................................... 409 6.3.45.7 MLME-TDLSSETUPCONFIRM.indication...................................... 410 6.3.45.8 MLME-TDLSPOTENTIALPEERSTA.request ................................. 410 6.3.45.9 MLME-TDLSPOTENTIALPEERSTA.confirm ................................ 411 6.3.46 TDLS direct-link teardown .................................................................................... 412 6.3.46.1 General ................................................................................................ 412 6.3.46.2 MLME-TDLSTEARDOWN.request.................................................. 412 6.3.46.3 MLME-TDLSTEARDOWN.indication ............................................. 413 6.3.47 TDLS peer U-APSD (TPU) ................................................................................... 413 6.3.47.1 General ................................................................................................ 413 6.3.47.2 MLME-TDLSPTI.request................................................................... 414 6.3.47.3 MLME-TDLSPTI.confirm.................................................................. 415 6.3.47.4 MLME-TDLSPTI.indication .............................................................. 415 6.3.47.5 MLME-TDLSPTI.response ................................................................ 416 6.3.48 TDLS channel switching ....................................................................................... 417 6.3.48.1 General ................................................................................................ 417 6.3.48.2 MLME-TDLSCHANNELSWITCH.request ...................................... 417 6.3.48.3 MLME-TDLSCHANNELSWITCH.confirm ..................................... 418 6.3.48.4 MLME-TDLSCHANNELSWITCH.indication.................................. 419 6.3.48.5 MLME-TDLSCHANNELSWITCH.response.................................... 419 6.3.49 TDLS peer PSM..................................................................................................... 420 6.3.49.1 General ................................................................................................ 420 20 Copyright Â© 2016 IEEE. All rights reserved. 6.3.49.2 MLME-TDLSPEERPSM.request ....................................................... 420 6.3.49.3 MLME-TDLSPEERPSM.confirm...................................................... 421 6.3.49.4 MLME-TDLSPEERPSM.indication................................................... 422 6.3.49.5 MLME-TDLSPEERPSM.response..................................................... 422 6.3.50 Event request.......................................................................................................... 423 6.3.50.1 General ................................................................................................ 423 6.3.50.2 MLME-EVLREQUEST.request ......................................................... 423 6.3.50.3 MLME-EVLREQUEST.indication..................................................... 424 6.3.51 Event report............................................................................................................ 425 6.3.51.1 General ................................................................................................ 425 6.3.51.2 MLME-EVLREPORT.request............................................................ 425 6.3.51.3 MLME-EVLREPORT.indication ....................................................... 426 6.3.52 Event ...................................................................................................................... 427 6.3.52.1 General ................................................................................................ 427 6.3.52.2 MLME-EVLOG.request ..................................................................... 427 6.3.52.3 MLME-EVLOG.confirm .................................................................... 427 6.3.53 Diagnostic request.................................................................................................. 428 6.3.53.1 General ................................................................................................ 428 6.3.53.2 MLME-DIAGREQUEST.request....................................................... 428 6.3.53.3 MLME-DIAGREQUEST.indication .................................................. 429 6.3.54 Diagnostic report.................................................................................................... 430 6.3.54.1 MLME-DIAGREPORT.request ......................................................... 430 6.3.54.2 MLME-DIAGREPORT.indication ..................................................... 431 6.3.55 Location configuration request .............................................................................. 431 6.3.55.1 General ................................................................................................ 431 6.3.55.2 MLME-LOCATIONCFG.request....................................................... 432 6.3.55.3 MLME-LOCATIONCFG.confirm ..................................................... 433 6.3.55.4 MLME-LOCATIONCFG.indication .................................................. 433 6.3.55.5 MLME-LOCATIONCFG.response .................................................... 434 6.3.56 Location track notification..................................................................................... 435 6.3.56.1 General ................................................................................................ 435 6.3.56.2 MLME-LOCATIONTRACKNOTIF.request ..................................... 435 6.3.56.3 MLME-LOCATIONTRACKNOTIF.indication................................. 436 6.3.57 Timing measurement ............................................................................................. 437 6.3.57.1 General ................................................................................................ 437 6.3.57.2 MLME-TIMINGMSMT.request......................................................... 438 6.3.57.3 MLME-TIMINGMSMT.confirm ....................................................... 439 6.3.57.4 MLME-TIMINGMSMT.indication .................................................... 440 6.3.58 Fine timing measurement (FTM)........................................................................... 441 6.3.58.1 General ................................................................................................ 441 6.3.58.2 MLME-FINETIMINGMSMT.request................................................ 442 6.3.58.3 MLME-FINETIMINGMSMT.confirm............................................... 443 6.3.58.4 MLME-FINETIMINGMSMT.indication ........................................... 444 6.3.59 BSS transition management................................................................................... 446 6.3.59.1 BSS transition management procedure ............................................... 446 6.3.59.2 MLME-BTMQUERY.request ............................................................ 446 6.3.59.3 MLME-BTMQUERY.indication........................................................ 448 6.3.59.4 MLME-BTM.request .......................................................................... 449 6.3.59.5 MLME-BTM.indication...................................................................... 450 6.3.59.6 MLME-BTM.response........................................................................ 451 6.3.59.7 MLME-BTM.confirm ......................................................................... 452 6.3.60 FMS setup .............................................................................................................. 453 6.3.60.1 General ................................................................................................ 453 6.3.60.2 MLME-FMS.request........................................................................... 454 21 Copyright Â© 2016 IEEE. All rights reserved. 6.3.60.3 MLME-FMS.confirm.......................................................................... 454 6.3.60.4 MLME-FMS.indication ...................................................................... 455 6.3.60.5 MLME-FMS.response ........................................................................ 456 6.3.61 Collocated Interference request ............................................................................. 456 6.3.61.1 General ................................................................................................ 456 6.3.61.2 MLME-CLINTERFERENCEREQUEST.request .............................. 457 6.3.61.3 MLME-CLINTERFERENCEREQUEST.indication.......................... 458 6.3.62 Collocated Interference report ............................................................................... 459 6.3.62.1 General ................................................................................................ 459 6.3.62.2 MLME-CLINTERFERENCEREPORT.request................................. 459 6.3.62.3 MLME-CLINTERFERENCEREPORT.indication ............................ 460 6.3.63 TFS setup ............................................................................................................... 460 6.3.63.1 General ................................................................................................ 460 6.3.63.2 MLME-TFS.request............................................................................ 461 6.3.63.3 MLME-TFS.confirm........................................................................... 462 6.3.63.4 MLME-TFS.indication ....................................................................... 462 6.3.63.5 MLME-TFS.response ......................................................................... 463 6.3.64 WNM sleep mode request...................................................................................... 464 6.3.64.1 General ................................................................................................ 464 6.3.64.2 MLME-SLEEPMODE.request ........................................................... 465 6.3.64.3 MLME-SLEEPMODE.indication....................................................... 465 6.3.64.4 MLME-SLEEPMODE.response......................................................... 466 6.3.64.5 MLME-SLEEPMODE.confirm .......................................................... 467 6.3.65 TIM broadcast setup .............................................................................................. 468 6.3.65.1 General ................................................................................................ 468 6.3.65.2 MLME-TIMBROADCAST.request ................................................... 469 6.3.65.3 MLME-TIMBROADCAST.confirm .................................................. 469 6.3.65.4 MLME-TIMBROADCAST.indication............................................... 470 6.3.65.5 MLME-TIMBROADCAST.response................................................. 471 6.3.66 QoS traffic capability update ................................................................................. 471 6.3.66.1 General ................................................................................................ 471 6.3.66.2 MLME-QOSTRAFFICCAPUPDATE.request................................... 472 6.3.66.3 MLME-QOSTRAFFICCAPUPDATE.indication .............................. 473 6.3.67 Channel Usage request........................................................................................... 473 6.3.67.1 General ................................................................................................ 473 6.3.67.2 MLME-CHANNELUSAGE.request .................................................. 474 6.3.67.3 MLME-CHANNELUSAGE.confirm ................................................. 475 6.3.67.4 MLME-CHANNELUSAGE.indication.............................................. 476 6.3.67.5 MLME-CHANNELUSAGE.response................................................ 477 6.3.68 DMS or GCR request and response procedure ...................................................... 478 6.3.68.1 General ................................................................................................ 478 6.3.68.2 MLME-GATS.request ........................................................................ 478 6.3.68.3 MLME-GATS.confirm ....................................................................... 479 6.3.68.4 MLME-GATS.indication.................................................................... 480 6.3.68.5 MLME-GATS.response...................................................................... 480 6.3.68.6 MLME-GATS-TERM.request............................................................ 481 6.3.68.7 MLME-GATS-TERM.indication ....................................................... 482 6.3.69 Timing measurement request................................................................................. 483 6.3.69.1 General ................................................................................................ 483 6.3.69.2 MLME-TIMINGMSMTRQ.request ................................................... 483 6.3.69.3 MLME-TIMINGMSMTRQ.indication............................................... 483 6.3.70 Fine timing measurement request .......................................................................... 484 6.3.70.1 General ................................................................................................ 484 6.3.70.2 MLME-FINETIMINGMSMTRQ.request .......................................... 484 22 Copyright Â© 2016 IEEE. All rights reserved. 6.3.70.3 MLME-FINETIMINGMSMTRQ.indication...................................... 485 6.3.71 WNM notification request ..................................................................................... 486 6.3.71.1 General ................................................................................................ 486 6.3.71.2 MLME-WNMNOTIFICATIONREQUEST.request .......................... 486 6.3.71.3 MLME-WNMNOTIFICATIONREQUEST indication...................... 487 6.3.72 WNM notification response................................................................................... 488 6.3.72.1 MLME-WNMNOTIFICATIONRESPONSE.request ........................ 488 6.3.72.2 MLME-WNMNOTIFICATIONRESPONSE.indication.................... 488 6.3.73 Network discovery and selection support .............................................................. 489 6.3.73.1 General ................................................................................................ 489 6.3.73.2 MLME-GAS.request........................................................................... 489 6.3.73.3 MLME-GAS.confirm.......................................................................... 490 6.3.73.4 MLME-GAS.indication ...................................................................... 492 6.3.73.5 MLME-GAS.response ........................................................................ 493 6.3.74 QoS Map element management ............................................................................. 494 6.3.74.1 General ................................................................................................ 494 6.3.74.2 MLME-QOS-MAP.request................................................................. 495 6.3.74.3 MLME-QOS-MAP.indication ............................................................ 495 6.3.75 Mesh peering management .................................................................................... 496 6.3.75.1 Introduction......................................................................................... 496 6.3.75.2 MLME-MESHPEERINGMANAGEMENT.request.......................... 496 6.3.75.3 MLME-MESHPEERINGMANAGEMENT.confirm......................... 497 6.3.75.4 MLME-MESHPEERINGMANAGEMENT.indication ..................... 498 6.3.75.5 MLME-MESHPEERINGMANAGEMENT.response ....................... 498 6.3.76 Mesh power management ...................................................................................... 499 6.3.76.1 Introduction......................................................................................... 499 6.3.76.2 MLME-MESHPOWERMGT.request................................................. 499 6.3.76.3 MLME-MESHPOWERMGT.confirm................................................ 500 6.3.77 Mesh neighbor offset synchronization................................................................... 500 6.3.77.1 Introduction......................................................................................... 500 6.3.77.2 MLME-MESHNEIGHBOROFFSETSYNCSTART.request ............. 501 6.3.77.3 MLME-MESHNEIGHBOROFFSETSYNCSTART.confirm ............ 501 6.3.77.4 MLME-MESHNEIGHBOROFFSETCALCULATE.request............. 502 6.3.77.5 MLME-MESHNEIGHBOROFFSETCALCULATE.confirm............ 502 6.3.77.6 MLME-MESHNEIGHBOROFFSETSYNCSTOP.request ................ 503 6.3.77.7 MLME-MESHNEIGHBOROFFSETSYNCSTOP.confirm ............... 503 6.3.78 Mesh TBTT adjustment ......................................................................................... 504 6.3.78.1 Introduction......................................................................................... 504 6.3.78.2 MLME-MESHTBTTADJUSTMENT.request ................................... 504 6.3.78.3 MLME-MESHTBTTADJUSTMENT.confirm .................................. 505 6.3.78.4 MLME-MESHTBTTADJUSTMENT.indication ............................... 506 6.3.78.5 MLME-MESHTBTTADJUSTMENT.response ................................. 506 6.3.79 MCCA management interface ............................................................................... 507 6.3.79.1 Introduction......................................................................................... 507 6.3.79.2 MLME-ACTIVATEMCCA.request ................................................... 507 6.3.79.3 MLME-MCCASETUP.request........................................................... 508 6.3.79.4 MLME-MCCASETUP.confirm.......................................................... 509 6.3.79.5 MLME-MCCASETUP.indication ...................................................... 510 6.3.79.6 MLME-MCCASETUP.response ........................................................ 511 6.3.79.7 MLME-MCCAADVERTISEMENT.request ..................................... 512 6.3.79.8 MLME-MCCAADVERTISEMENT.confirm .................................... 512 6.3.79.9 MLME-MCCAADVERTISEMENT.indication ................................. 513 6.3.79.10 MLME-MCCAADVERTISEMENT.response ................................... 514 6.3.79.11 MLME-MCCATEARDOWN.request ................................................ 514 23 Copyright Â© 2016 IEEE. All rights reserved. 6.3.79.12 MLME-MCCATEARDOWN.indication............................................ 515 6.3.80 MBSS congestion control ...................................................................................... 516 6.3.80.1 Introduction......................................................................................... 516 6.3.80.2 MLME-MBSSCONGESTIONCONTROL.request............................ 516 6.3.80.3 MLME-MBSSCONGESTIONCONTROL.indication ....................... 516 6.3.81 MBSS proxy update............................................................................................... 517 6.3.81.1 Introduction......................................................................................... 517 6.3.81.2 MLME-MBSSPROXYUPDATE.request........................................... 517 6.3.81.3 MLME-MBSSPROXYUPDATE.confirm.......................................... 518 6.3.81.4 MLME-MBSSPROXYUPDATE.indication ...................................... 519 6.3.81.5 MLME-MBSSPROXYUPDATE.response ........................................ 519 6.3.82 MBSS mesh gate announcement ........................................................................... 520 6.3.82.1 Introduction......................................................................................... 520 6.3.82.2 MLME-MBSSGATEANNOUNCEMENT.request............................ 520 6.3.82.3 MLME-MBSSGATEANNOUNCEMENT.indication ....................... 521 6.3.83 Mesh link metric .................................................................................................... 522 6.3.83.1 Introduction......................................................................................... 522 6.3.83.2 MLME-MESHLINKMETRICREAD.request .................................... 522 6.3.83.3 MLME-MESHLINKMETRICREAD.confirm ................................... 522 6.3.83.4 MLME-MESHLINKMETRICREPORT.request................................ 523 6.3.83.5 MLME-MESHLINKMETRICREPORT.indication ........................... 524 6.3.84 HWMP mesh path selection .................................................................................. 525 6.3.84.1 Introduction......................................................................................... 525 6.3.84.2 MLME-HWMPMESHPATHSELECTION.request ........................... 525 6.3.84.3 MLME-HWMPMESHPATHSELECTION.indication....................... 526 6.3.85 QMF policy............................................................................................................ 527 6.3.85.1 Introduction......................................................................................... 527 6.3.85.2 MLME-QMFPOLICY.request............................................................ 527 6.3.85.3 MLME-QMFPOLICY.indication ....................................................... 528 6.3.85.4 MLME-QMFPOLICYCHANGE.request ........................................... 528 6.3.85.5 MLME-QMFPOLICYCHANGE.confirm.......................................... 529 6.3.85.6 MLME-QMFPOLICYCHANGE.indication....................................... 530 6.3.85.7 MLME-QMFPOLICYCHANGE.response......................................... 530 6.3.85.8 MLME-QMFPOLICYSET.request..................................................... 531 6.3.86 SCS request and response procedure ..................................................................... 532 6.3.86.1 General ................................................................................................ 532 6.3.86.2 MLME-SCS.request............................................................................ 532 6.3.86.3 MLME-SCS.confirm........................................................................... 533 6.3.86.4 MLME-SCS.indication ....................................................................... 534 6.3.86.5 MLME-SCS.response ......................................................................... 535 6.3.86.6 MLME-SCS-TERM.request .............................................................. 535 6.3.86.7 MLME-SCS-TERM.indication........................................................... 536 6.3.87 QLoad report management .................................................................................... 537 6.3.87.1 General ................................................................................................ 537 6.3.87.2 MLME-QLOAD.request..................................................................... 537 6.3.87.3 MLME-QLOAD.confirm.................................................................... 538 6.3.87.4 MLME-QLOAD.indication ............................................................... 539 6.3.87.5 MLME-QLOAD.response ................................................................. 539 6.3.88 HCCA TXOP advertisement management ............................................................ 540 6.3.88.1 General ................................................................................................ 540 6.3.88.2 MLME-TXOPADVERTISEMENT.request....................................... 540 6.3.88.3 MLME-TXOPADVERTISEMENT.confirm...................................... 541 6.3.88.4 MLME-TXOPADVERTISEMENT.indication .................................. 542 6.3.88.5 MLME-TXOPADVERTISEMENT.response .................................... 543 24 Copyright Â© 2016 IEEE. All rights reserved. 6.3.89 GCR group membership management................................................................... 544 6.3.89.1 General ................................................................................................ 544 6.3.89.2 MLME-GROUP-MEMBERSHIP.request.......................................... 544 6.3.89.3 MLME-GROUP-MEMBERSHIP.confirm......................................... 545 6.3.89.4 MLME-GROUP-MEMBERSHIP.indication ..................................... 546 6.3.89.5 MLME-GROUP-MEMBERSHIP.response ....................................... 546 6.3.90 AP PeerKey management ..................................................................................... 547 6.3.90.1 General ................................................................................................ 547 6.3.90.2 MLME-APPEERKEY.request............................................................ 547 6.3.90.3 MLME-APPEERKEY.indication ....................................................... 548 6.3.91 On-channel Tunneling operation ........................................................................... 549 6.3.91.1 General ................................................................................................ 549 6.3.91.2 MLME-OCTunnel.request.................................................................. 550 6.3.91.3 MLME-OCTunnel.indication ............................................................. 550 6.3.92 Multi-band operation ............................................................................................. 551 6.3.92.1 General ................................................................................................ 551 6.3.92.2 MLME-FST-SETUP.request .............................................................. 551 6.3.92.3 MLME-FST-SETUP.indication.......................................................... 552 6.3.92.4 MLME-FST-SETUP.response............................................................ 552 6.3.92.5 MLME-FST-SETUP.confirm ............................................................. 553 6.3.92.6 MLME-FST-ACK.request .................................................................. 554 6.3.92.7 MLME-FST-ACK.indication.............................................................. 554 6.3.92.8 MLME-FST-ACK.response................................................................ 555 6.3.92.9 MLME-FST-ACK.confirm ................................................................. 555 6.3.92.10 MLME-FST-TEARDOWN.request.................................................... 556 6.3.92.11 MLME-FST-TEARDOWN.indication ............................................... 556 6.3.92.12 MLME-FST-INCOMING.request ...................................................... 557 6.3.93 DMG relay operation ............................................................................................. 558 6.3.93.1 General ................................................................................................ 558 6.3.93.2 MLME-RELAY-SEARCH.request .................................................... 558 6.3.93.3 MLME-RELAY-SEARCH.confirm ................................................... 559 6.3.93.4 MLME-RELAY-SEARCH.indication................................................ 559 6.3.93.5 MLME-RELAY-SEARCH.response.................................................. 560 6.3.93.6 MLME-RLS.request ........................................................................... 560 6.3.93.7 MLME-RLS.confirm .......................................................................... 561 6.3.93.8 MLME-RLS.indication ....................................................................... 562 6.3.93.9 MLME-RLS.response ......................................................................... 563 6.3.93.10 MLME-RLS-TEARDOWN.request ................................................... 563 6.3.93.11 MLME-RLS-TEARDOWN.indication............................................... 564 6.3.94 Quieting adjacent BSS operation ........................................................................... 564 6.3.94.1 General ................................................................................................ 564 6.3.94.2 MLME-QAB.request .......................................................................... 565 6.3.94.3 MLME-QAB.confirm ......................................................................... 565 6.3.94.4 MLME-QAB.indication...................................................................... 566 6.3.94.5 MLME-QAB.response........................................................................ 567 6.3.95 DMG beamforming................................................................................................ 568 6.3.95.1 General ................................................................................................ 568 6.3.95.2 MLME-BF-TRAINING.request ......................................................... 568 6.3.95.3 MLME-BF-TRAINING.confirm ........................................................ 569 6.3.95.4 MLME-BF-TRAINING.indication..................................................... 569 6.3.96 PN event report ...................................................................................................... 570 6.3.96.1 General ................................................................................................ 570 6.3.96.2 MLME-PN-EXHAUSTION.indication .............................................. 570 6.3.96.3 MLME-PN-WARNING.indication..................................................... 571 25 Copyright Â© 2016 IEEE. All rights reserved. 6.3.97 Channel Availability Query ................................................................................... 571 6.3.97.1 Introduction......................................................................................... 571 6.3.97.2 MLME-CHANNELAVAILABILITYQUERY.request ..................... 571 6.3.97.3 MLME-CHANNELAVAILABILITYQUERY.confirm .................... 572 6.3.97.4 MLME-CHANNELAVAILABILITYQUERY.indication ................. 573 6.3.97.5 MLME-CHANNELAVAILABILITYQUERY.response ................... 574 6.3.98 Channel schedule management.............................................................................. 575 6.3.98.1 Introduction......................................................................................... 575 6.3.98.2 MLME-CHANNELSCHEDULEMANAGEMENT.request.............. 575 6.3.98.3 MLME-CHANNELSCHEDULEMANAGEMENT.confirm............. 576 6.3.98.4 MLME-CHANNELSCHEDULEMANAGEMENT.indication ......... 577 6.3.98.5 MLME-CHANNELSCHEDULEMANAGEMENT.response ........... 578 6.3.99 Contact verification signal ..................................................................................... 579 6.3.99.1 Introduction......................................................................................... 579 6.3.99.2 MLME-CVS.request ........................................................................... 579 6.3.99.3 MLME-CVS.indication....................................................................... 580 6.3.100 GDD Enablement................................................................................................... 581 6.3.100.1 Introduction......................................................................................... 581 6.3.100.2 MLME-GDDENABLEMENT.request ............................................... 581 6.3.100.3 MLME-GDDENABLEMENT.confirm.............................................. 582 6.3.100.4 MLME-GDDENABLEMENT.indication........................................... 583 6.3.100.5 MLME-GDDENABLEMENT.response............................................. 583 6.3.101 Network channel control management .................................................................. 584 6.3.101.1 Introduction......................................................................................... 584 6.3.101.2 MLME-NETWORKCHANNELCONTROL.request......................... 584 6.3.101.3 MLME-NETWORKCHANNELCONTROL.confirm........................ 585 6.3.101.4 MLME-NETWORKCHANNELCONTROL.indication .................... 586 6.3.101.5 MLME-NETWORKCHANNELCONTROL.response ...................... 587 6.3.102 White space map (WSM)....................................................................................... 588 6.3.102.1 Introduction......................................................................................... 588 6.3.102.2 MLME-WSM.request ......................................................................... 588 6.3.102.3 MLME-WSM.indication..................................................................... 589 6.3.103 Estimated Throughput (ESTT) .............................................................................. 589 6.3.103.1 General ................................................................................................ 589 6.3.103.2 MLME-ESTIMATED-THROUGHPUT.request................................ 589 6.3.103.3 MLME-ESTIMATED-THROUGHPUT.confirm............................... 591 6.3.104 Get authentication/association state....................................................................... 591 6.3.104.1 General ................................................................................................ 591 6.3.104.2 MLME-GETAUTHASSOCSTATE.request....................................... 592 6.3.104.3 MLME-GETAUTHASSOCSTATE.confirm ..................................... 592 6.4 MAC state generic convergence function (MSGCF) ............................................................ 593 6.4.1 Overview of the convergence function .................................................................. 593 6.4.2 Overview of convergence function state machine ................................................. 593 6.4.3 Convergence function state list.............................................................................. 594 6.4.3.1 ESS_CONNECTED............................................................................ 594 6.4.3.2 ESS_DISCONNECTED ..................................................................... 594 6.4.3.3 ESS_DISENGAGING ........................................................................ 594 6.4.3.4 STANDBY.......................................................................................... 594 6.4.4 Convergence function state transitions .................................................................. 594 6.4.4.1 Transitions to ESS_CONNECTED .................................................... 594 6.4.4.2 Transitions to ESS_ DISCONNECTED ............................................. 595 6.4.4.3 Transitions to ESS_DISENGAGING ................................................. 595 6.4.4.4 Transitions to STANDBY................................................................... 595 6.4.5 Convergence function informational events .......................................................... 595 26 Copyright Â© 2016 IEEE. All rights reserved. 6.4.6 MAC state generic convergence SAP.................................................................... 595 6.4.7 ESS status reporting............................................................................................... 596 6.4.7.1 MSGCF-ESS-LINK-UP.indication..................................................... 596 6.4.7.2 MSGCF-ESS-LINK-DOWN.indication ............................................. 597 6.4.7.3 MSGCF-ESS-LINK-GOING-DOWN.indication ............................... 598 6.4.7.4 MSGCF-ESS-LINK-EVENT-ROLLBACK.indication...................... 599 6.4.7.5 MSGCF-ESS-LINK-DETECTED.indication ..................................... 600 6.4.7.6 MSGCF-ESS-LINK-SCAN.request ................................................... 601 6.4.7.7 MSGCF-ESS-LINK-SCAN.confirm .................................................. 602 6.4.8 Network configuration ........................................................................................... 602 6.4.8.1 MSGCF-ESS-LINK-CAPABILITY.request ...................................... 602 6.4.8.2 MSGCF-ESS-LINK-CAPABILITY.confirm ..................................... 603 6.4.8.3 MSGCF-ESS-LINK-PARAMETERS.request.................................... 604 6.4.8.4 MSGCF-ESS-LINK-PARAMETERS.confirm................................... 606 6.4.8.5 MSGCF-GET-ESS-LINK-PARAMETERS.request........................... 606 6.4.8.6 MSGCF-GET-ESS-LINK-PARAMETERS.confirm ......................... 607 6.4.9 Network events ...................................................................................................... 607 6.4.9.1 MSGCF-ESS-LINK-THRESHOLD-REPORT.indication ................. 607 6.4.10 Network command interface.................................................................................. 608 6.4.10.1 MSGCF-ESS-LINK-COMMAND.request......................................... 608 6.4.11 MAC state SME SAPâ€”mobility management ..................................................... 609 6.4.11.1 MSSME-ESS-LINK-GOING-DOWN.indication............................... 609 6.5 PLME SAP interface ............................................................................................................. 610 6.5.1 General................................................................................................................... 610 6.5.2 PLME-RESET.request........................................................................................... 610 6.5.2.1 Function .............................................................................................. 610 6.5.2.2 Semantics of the service primitive ...................................................... 610 6.5.2.3 When generated................................................................................... 610 6.5.2.4 Effect of receipt................................................................................... 610 6.5.3 PLME-CHARACTERISTICS.request .................................................................. 611 6.5.3.1 Function .............................................................................................. 611 6.5.3.2 Semantics of the service primitive ...................................................... 611 6.5.3.3 When generated................................................................................... 611 6.5.3.4 Effect of receipt................................................................................... 611 6.5.4 PLME-CHARACTERISTICS.confirm ................................................................. 611 6.5.4.1 Function .............................................................................................. 611 6.5.4.2 Semantics of the service primitive ...................................................... 611 6.5.4.3 When generated................................................................................... 614 6.5.4.4 Effect of receipt................................................................................... 614 6.5.5 PLME-TXTIME.request........................................................................................ 614 6.5.5.1 Function .............................................................................................. 614 6.5.5.2 Semantics of the service primitive ...................................................... 614 6.5.5.3 When generated................................................................................... 614 6.5.5.4 Effect of receipt................................................................................... 614 6.5.6 PLME-TXTIME.confirm....................................................................................... 615 6.5.6.1 Function .............................................................................................. 615 6.5.6.2 Semantics of the service primitive ...................................................... 615 6.5.6.3 When generated................................................................................... 615 6.5.6.4 Effect of receipt................................................................................... 615 7. DS SAP specification......................................................................................................................... 616 7.1 Introduction............................................................................................................................ 616 7.2 SAP primitives....................................................................................................................... 616 27 Copyright Â© 2016 IEEE. All rights reserved. 7.2.1 General................................................................................................................... 616 7.2.2 MSDU transfer....................................................................................................... 617 7.2.2.1 General ................................................................................................ 617 7.2.2.2 DS-UNITDATA.request ..................................................................... 617 7.2.2.3 DS-UNITDATA.indication................................................................. 617 7.2.3 Mapping updates.................................................................................................... 618 7.2.3.1 General ................................................................................................ 618 7.2.3.2 DS-STA-NOTIFY.request .................................................................. 618 8. PHY service specification.................................................................................................................. 620 8.1 Scope...................................................................................................................................... 620 8.2 PHY functions........................................................................................................................ 620 8.3 Detailed PHY service specifications...................................................................................... 620 8.3.1 Scope and field of application ............................................................................... 620 8.3.2 Overview of the service ......................................................................................... 620 8.3.3 Overview of interactions........................................................................................ 620 8.3.4 Basic service and options....................................................................................... 620 8.3.4.1 PHY SAP peer-to-peer service primitives .......................................... 620 8.3.4.2 PHY SAP inter-(sub)layer service primitives..................................... 621 8.3.4.3 PHY SAP service primitives parameters ............................................ 621 8.3.4.4 Vector descriptions ............................................................................. 622 8.3.5 PHY SAP detailed service specification................................................................ 623 8.3.5.1 Introduction......................................................................................... 623 8.3.5.2 PHY-DATA.request............................................................................ 623 8.3.5.3 PHY-DATA.indication ....................................................................... 623 8.3.5.4 PHY-DATA.confirm........................................................................... 624 8.3.5.5 PHY-TXSTART.request..................................................................... 624 8.3.5.6 PHY-TXSTART.confirm.................................................................... 625 8.3.5.7 PHY-TXEND.request ......................................................................... 626 8.3.5.8 PHY-TXEND.confirm ........................................................................ 626 8.3.5.9 PHY-TXHEADEREND.indication..................................................... 627 8.3.5.10 PHY-CCARESET.request .................................................................. 627 8.3.5.11 PHY-CCARESET.confirm ................................................................. 628 8.3.5.12 PHY-CCA.indication .......................................................................... 628 8.3.5.13 PHY-RXSTART.indication ................................................................ 632 8.3.5.14 PHY-RXEND.indication..................................................................... 632 8.3.5.15 PHY-CONFIG.request........................................................................ 633 8.3.5.16 PHY-CONFIG.confirm....................................................................... 634 8.3.5.17 PHY-TXBUSY.indication .................................................................. 634 8.4 PHY management .................................................................................................................. 635 9. Frame formats .................................................................................................................................... 636 9.1 General requirements ............................................................................................................. 636 9.2 MAC frame formats............................................................................................................... 636 9.2.1 Basic components .................................................................................................. 636 9.2.2 Conventions ........................................................................................................... 636 9.2.3 General frame format............................................................................................. 637 9.2.4 Frame fields ........................................................................................................... 638 9.2.4.1 Frame Control field............................................................................. 638 9.2.4.2 Duration/ID field................................................................................. 644 9.2.4.3 Address fields...................................................................................... 645 9.2.4.4 Sequence Control field........................................................................ 646 28 Copyright Â© 2016 IEEE. All rights reserved. 9.2.4.5 QoS Control field ................................................................................ 647 9.2.4.6 HT Control field.................................................................................. 654 9.2.4.7 Frame Body field ................................................................................ 661 9.2.4.8 FCS field ............................................................................................. 665 9.2.5 Duration/ID field (QoS STA) ................................................................................ 665 9.2.5.1 General ................................................................................................ 665 9.2.5.2 Setting for single and multiple protection under enhanced distributed channel access (EDCA) .................................................... 665 9.2.5.3 Setting for QoS CF-Poll frames .......................................................... 667 9.2.5.4 Setting for frames sent by a TXOP holder under HCCA.................... 668 9.2.5.5 Settings within a PSMP sequence....................................................... 668 9.2.5.6 Settings within a dual CTS sequence.................................................. 668 9.2.5.7 Setting for control response frames .................................................... 669 9.2.5.8 Setting for other response frames........................................................ 669 9.3 Format of individual frame types........................................................................................... 669 9.3.1 Control frames ....................................................................................................... 669 9.3.1.1 Format of Control frames.................................................................... 669 9.3.1.2 RTS frame format ............................................................................... 670 9.3.1.3 CTS frame format ............................................................................... 670 9.3.1.4 Ack frame format ................................................................................ 671 9.3.1.5 PS-Poll frame format .......................................................................... 671 9.3.1.6 CF-End frame format .......................................................................... 672 9.3.1.7 CF-End +CF-Ack frame format.......................................................... 672 9.3.1.8 BlockAckReq frame format ................................................................ 672 9.3.1.9 BlockAck frame format ...................................................................... 676 9.3.1.10 Control Wrapper frame ....................................................................... 680 9.3.1.11 Poll frame format ................................................................................ 681 9.3.1.12 Service period request (SPR) frame format ........................................ 681 9.3.1.13 Grant frame format.............................................................................. 682 9.3.1.14 DMG CTS frame format ..................................................................... 683 9.3.1.15 DMG DTS frame format..................................................................... 683 9.3.1.16 Sector sweep (SSW) frame format...................................................... 683 9.3.1.17 Sector sweep feedback (SSW-Feedback) frame format ..................... 684 9.3.1.18 Sector sweep Ack (SSW-Ack) frame format ...................................... 684 9.3.1.19 Grant Ack frame format...................................................................... 685 9.3.1.20 VHT NDP Announcement frame format ............................................ 685 9.3.1.21 Beamforming Report Poll frame format ............................................. 687 9.3.2 Data frames ............................................................................................................ 687 9.3.2.1 Format of Data frames ........................................................................ 687 9.3.2.2 Aggregate MSDU (A-MSDU) format ................................................ 690 9.3.3 Management frames............................................................................................... 692 9.3.3.1 Terminology of Management frames and MMPDUs ......................... 692 9.3.3.2 Format of Management frames ........................................................... 692 9.3.3.3 Beacon frame format........................................................................... 694 9.3.3.4 ATIM frame format ............................................................................ 698 9.3.3.5 Disassociation frame format ............................................................... 698 9.3.3.6 Association Request frame format...................................................... 699 9.3.3.7 Association Response frame format ................................................... 700 9.3.3.8 Reassociation Request frame format................................................... 702 9.3.3.9 Reassociation Response frame format ................................................ 704 9.3.3.10 Probe Request frame format ............................................................... 706 9.3.3.11 Probe Response frame format ............................................................. 708 9.3.3.12 Authentication frame format ............................................................... 712 9.3.3.13 Deauthentication ................................................................................. 715 29 Copyright Â© 2016 IEEE. All rights reserved. 9.3.3.14 Action frame format............................................................................ 715 9.3.3.15 Action No Ack frame format .............................................................. 716 9.3.3.16 Timing Advertisement frame format .................................................. 716 9.3.4 Extension frames.................................................................................................... 716 9.3.4.1 Format of Extension frames................................................................ 716 9.3.4.2 DMG Beacon ...................................................................................... 717 9.3.5 Frame addressing in an MBSS............................................................................... 721 9.4 Management and Extension frame body components ........................................................... 723 9.4.1 Fields that are not elements ................................................................................... 723 9.4.1.1 Authentication Algorithm Number field............................................. 723 9.4.1.2 Authentication Transaction Sequence Number field .......................... 724 9.4.1.3 Beacon Interval field........................................................................... 724 9.4.1.4 Capability Information field................................................................ 724 9.4.1.5 Current AP Address field.................................................................... 727 9.4.1.6 Listen Interval field............................................................................. 727 9.4.1.7 Reason Code field ............................................................................... 728 9.4.1.8 AID field ............................................................................................. 731 9.4.1.9 Status Code field ................................................................................. 731 9.4.1.10 Timestamp field .................................................................................. 736 9.4.1.11 Action field ......................................................................................... 736 9.4.1.12 Dialog Token field .............................................................................. 738 9.4.1.13 DLS Timeout Value field.................................................................... 738 9.4.1.14 Block Ack Parameter Set field............................................................ 738 9.4.1.15 Block Ack Timeout Value field .......................................................... 739 9.4.1.16 DELBA Parameter Set field................................................................ 739 9.4.1.17 QoS Info field...................................................................................... 739 9.4.1.18 Measurement Pilot Interval field......................................................... 741 9.4.1.19 Max Transmit Power field .................................................................. 741 9.4.1.20 Transmit Power Used field ................................................................. 741 9.4.1.21 Channel Width field ............................................................................ 741 9.4.1.22 Operating Class and Channel field...................................................... 742 9.4.1.23 SM Power Control field ...................................................................... 742 9.4.1.24 PCO Phase Control field ..................................................................... 743 9.4.1.25 PSMP Parameter Set field................................................................... 743 9.4.1.26 PSMP STA Info field.......................................................................... 744 9.4.1.27 MIMO Control field............................................................................ 745 9.4.1.28 CSI Report field .................................................................................. 746 9.4.1.29 Noncompressed Beamforming Report field ....................................... 748 9.4.1.30 Compressed Beamforming Report field ............................................. 750 9.4.1.31 Antenna Selection Indices field .......................................................... 753 9.4.1.32 Organization Identifier field................................................................ 753 9.4.1.33 Rate Identification field ...................................................................... 754 9.4.1.34 GAS Query Response Fragment ID field ........................................... 755 9.4.1.35 Venue Info field .................................................................................. 756 9.4.1.36 Target Channel.................................................................................... 759 9.4.1.37 Operating Class ................................................................................... 759 9.4.1.38 Send-Confirm field ............................................................................. 759 9.4.1.39 Anti-Clogging Token field.................................................................. 759 9.4.1.40 Scalar field .......................................................................................... 760 9.4.1.41 Finite field element (FFE) field .......................................................... 760 9.4.1.42 Confirm field....................................................................................... 760 9.4.1.43 Finite Cyclic Group field .................................................................... 760 9.4.1.44 TXOP Reservation field...................................................................... 760 9.4.1.45 Relay Capable STA Info field............................................................. 761 30 Copyright Â© 2016 IEEE. All rights reserved. 9.4.1.46 Band ID field....................................................................................... 761 9.4.1.47 DMG Parameters field ........................................................................ 761 9.4.1.48 VHT MIMO Control field................................................................... 763 9.4.1.49 VHT Compressed Beamforming Report field .................................... 764 9.4.1.50 TVHT Compressed Beamforming Report field.................................. 773 9.4.1.51 MU Exclusive Beamforming Report field .......................................... 774 9.4.1.52 TVHT MU Exclusive Beamforming Report field .............................. 778 9.4.1.53 Operating Mode field .......................................................................... 778 9.4.1.54 Membership Status Array field ........................................................... 782 9.4.1.55 User Position Array field .................................................................... 782 9.4.1.56 Device Location Information Body field ............................................ 782 9.4.1.57 WSM Type field and WSM Information field.................................... 783 9.4.2 Elements................................................................................................................. 784 9.4.2.1 General ................................................................................................ 784 9.4.2.2 SSID element ...................................................................................... 790 9.4.2.3 Supported Rates and BSS Membership Selectors element................. 790 9.4.2.4 DSSS Parameter Set element .............................................................. 792 9.4.2.5 CF Parameter Set element................................................................... 792 9.4.2.6 TIM element........................................................................................ 792 9.4.2.7 IBSS Parameter Set element ............................................................... 795 9.4.2.8 Challenge Text element ...................................................................... 795 9.4.2.9 Country element.................................................................................. 795 9.4.2.10 Request element .................................................................................. 798 9.4.2.11 Extended Request element .................................................................. 798 9.4.2.12 ERP element........................................................................................ 799 9.4.2.13 Extended Supported Rates and BSS Membership Selectors element. 799 9.4.2.14 Power Constraint element ................................................................... 800 9.4.2.15 Power Capability element ................................................................... 800 9.4.2.16 TPC Request element.......................................................................... 801 9.4.2.17 TPC Report element............................................................................ 801 9.4.2.18 Supported Channels element............................................................... 802 9.4.2.19 Channel Switch Announcement element ............................................ 802 9.4.2.20 Secondary Channel Offset element..................................................... 803 9.4.2.21 Measurement Request element ........................................................... 804 9.4.2.22 Measurement Report element ............................................................. 835 9.4.2.23 Quiet element ...................................................................................... 881 9.4.2.24 IBSS DFS element .............................................................................. 881 9.4.2.25 RSNE .................................................................................................. 882 9.4.2.26 Vendor Specific element ..................................................................... 890 9.4.2.27 Extended Capabilities element............................................................ 890 9.4.2.28 BSS Load element............................................................................... 896 9.4.2.29 EDCA Parameter Set element............................................................. 897 9.4.2.30 TSPEC element ................................................................................... 899 9.4.2.31 TCLAS element .................................................................................. 906 9.4.2.32 TS Delay element................................................................................ 914 9.4.2.33 TCLAS Processing element ................................................................ 914 9.4.2.34 Schedule element ................................................................................ 915 9.4.2.35 QoS Capability element ...................................................................... 916 9.4.2.36 AP Channel Report element................................................................ 916 9.4.2.37 Neighbor Report element .................................................................... 916 9.4.2.38 RCPI element ...................................................................................... 923 9.4.2.39 BSS Average Access Delay element .................................................. 923 9.4.2.40 Antenna element ................................................................................. 924 9.4.2.41 RSNI element...................................................................................... 925 31 Copyright Â© 2016 IEEE. All rights reserved. 9.4.2.42 Measurement Pilot Transmission element .......................................... 925 9.4.2.43 BSS Available Admission Capacity element...................................... 926 9.4.2.44 BSS AC Access Delay element .......................................................... 927 9.4.2.45 RM Enabled Capabilities element....................................................... 929 9.4.2.46 Multiple BSSID element..................................................................... 931 9.4.2.47 Mobility Domain element (MDE)....................................................... 933 9.4.2.48 Fast BSS Transition element (FTE) .................................................... 933 9.4.2.49 Timeout Interval element (TIE) .......................................................... 936 9.4.2.50 RIC Data element (RDE) .................................................................... 936 9.4.2.51 RIC Descriptor element ...................................................................... 937 9.4.2.52 DSE Registered Location element ...................................................... 937 9.4.2.53 Extended Channel Switch Announcement element ............................ 939 9.4.2.54 Supported Operating Classes element................................................. 939 9.4.2.55 Management MIC element.................................................................. 941 9.4.2.56 HT Capabilities element...................................................................... 941 9.4.2.57 HT Operation element......................................................................... 950 9.4.2.58 20/40 BSS Intolerant Channel Report element ................................... 954 9.4.2.59 Overlapping BSS Scan Parameters element ....................................... 955 9.4.2.60 20/40 BSS Coexistence element ......................................................... 955 9.4.2.61 Time Advertisement element .............................................................. 956 9.4.2.62 Link Identifier element........................................................................ 958 9.4.2.63 Wakeup Schedule element .................................................................. 958 9.4.2.64 Channel Switch Timing element......................................................... 959 9.4.2.65 PTI Control element............................................................................ 959 9.4.2.66 TPU Buffer Status element ................................................................. 960 9.4.2.67 Event Request element........................................................................ 961 9.4.2.68 Event Report element.......................................................................... 967 9.4.2.69 Diagnostic Request element................................................................ 973 9.4.2.70 Diagnostic Report element.................................................................. 984 9.4.2.71 Location Parameters element .............................................................. 986 9.4.2.72 Nontransmitted BSSID Capability element ........................................ 994 9.4.2.73 SSID List element ............................................................................... 994 9.4.2.74 Multiple BSSID-Index element .......................................................... 995 9.4.2.75 FMS Descriptor element ..................................................................... 995 9.4.2.76 FMS Request element ......................................................................... 996 9.4.2.77 FMS Response element....................................................................... 998 9.4.2.78 QoS Traffic Capability element ........................................................ 1000 9.4.2.79 BSS Max Idle Period element........................................................... 1001 9.4.2.80 TFS Request element ........................................................................ 1002 9.4.2.81 TFS Response element...................................................................... 1004 9.4.2.82 WNM Sleep Mode element............................................................... 1005 9.4.2.83 TIM Broadcast Request element....................................................... 1006 9.4.2.84 TIM Broadcast Response element .................................................... 1007 9.4.2.85 Collocated Interference Report element ........................................... 1008 9.4.2.86 Channel Usage element..................................................................... 1009 9.4.2.87 Time Zone element ........................................................................... 1010 9.4.2.88 DMS Request element ...................................................................... 1011 9.4.2.89 DMS Response element .................................................................... 1013 9.4.2.90 Destination URI element................................................................... 1016 9.4.2.91 U-APSD Coexistence element .......................................................... 1017 9.4.2.92 Interworking element ........................................................................ 1017 9.4.2.93 Advertisement Protocol element....................................................... 1019 9.4.2.94 Expedited Bandwidth Request element ............................................ 1021 9.4.2.95 QoS Map element.............................................................................. 1022 32 Copyright Â© 2016 IEEE. All rights reserved. 9.4.2.96 Roaming Consortium element .......................................................... 1023 9.4.2.97 Emergency Alert Identifier element.................................................. 1024 9.4.2.98 Mesh Configuration element............................................................. 1024 9.4.2.99 Mesh ID element............................................................................... 1028 9.4.2.100 Mesh Link Metric Report element .................................................... 1029 9.4.2.101 Congestion Notification element ...................................................... 1029 9.4.2.102 Mesh Peering Management element ................................................. 1030 9.4.2.103 Mesh Channel Switch Parameters element ....................................... 1031 9.4.2.104 Mesh Awake Window element ......................................................... 1032 9.4.2.105 Beacon Timing element .................................................................... 1032 9.4.2.106 MCCAOP Setup Request element .................................................... 1033 9.4.2.107 MCCAOP Setup Reply element ....................................................... 1034 9.4.2.108 MCCAOP Advertisement Overview element................................... 1035 9.4.2.109 MCCAOP Advertisement element.................................................... 1036 9.4.2.110 MCCAOP Teardown element........................................................... 1038 9.4.2.111 GANN element ................................................................................. 1039 9.4.2.112 RANN element.................................................................................. 1039 9.4.2.113 PREQ element................................................................................... 1040 9.4.2.114 PREP element ................................................................................... 1042 9.4.2.115 PERR element ................................................................................... 1044 9.4.2.116 PXU element ..................................................................................... 1045 9.4.2.117 PXUC element .................................................................................. 1046 9.4.2.118 Authenticated Mesh Peering Exchange element............................... 1047 9.4.2.119 MIC element ..................................................................................... 1047 9.4.2.120 Quality-of-Service Management Frame Policy element................... 1048 9.4.2.121 Intra-Access Category Priority element............................................ 1049 9.4.2.122 SCS Descriptor element .................................................................... 1050 9.4.2.123 QLoad Report element ..................................................................... 1051 9.4.2.124 HCCA TXOP Update Count element .............................................. 1053 9.4.2.125 Higher Layer Stream ID element ..................................................... 1054 9.4.2.126 GCR Group Address element .......................................................... 1054 9.4.2.127 DMG BSS Parameter Change element ............................................. 1055 9.4.2.128 DMG Capabilities element................................................................ 1055 9.4.2.129 DMG Operation element .................................................................. 1063 9.4.2.130 DMG Beam Refinement element...................................................... 1064 9.4.2.131 DMG Wakeup Schedule element...................................................... 1066 9.4.2.132 Extended Schedule element .............................................................. 1067 9.4.2.133 STA Availability element ................................................................. 1069 9.4.2.134 DMG TSPEC element....................................................................... 1070 9.4.2.135 Next DMG ATI element ................................................................... 1073 9.4.2.136 Channel Measurement Feedback element......................................... 1074 9.4.2.137 Awake Window element ................................................................... 1076 9.4.2.138 Multi-band element ........................................................................... 1076 9.4.2.139 ADDBA Extension element ............................................................. 1079 9.4.2.140 Next PCP List element .................................................................... 1079 9.4.2.141 PCP Handover element ................................................................... 1080 9.4.2.142 DMG Link Margin element ............................................................. 1080 9.4.2.143 DMG Link Adaptation Acknowledgment element........................... 1081 9.4.2.144 Switching Stream element ............................................................... 1082 9.4.2.145 Session Transition element .............................................................. 1083 9.4.2.146 Dynamic Tone Pairing (DTP) Report element ................................. 1084 9.4.2.147 Cluster Report element ..................................................................... 1085 9.4.2.148 Relay Capabilities element................................................................ 1086 9.4.2.149 Relay Transfer Parameter Set element.............................................. 1087 33 Copyright Â© 2016 IEEE. All rights reserved. 9.4.2.150 Quiet Period Request element........................................................... 1088 9.4.2.151 Quiet Period Response element ........................................................ 1089 9.4.2.152 BeamLink Maintenance element ...................................................... 1089 9.4.2.153 Multiple MAC Sublayers (MMS) element ...................................... 1090 9.4.2.154 U-PID element ................................................................................. 1091 9.4.2.155 ECAPC Policy element .................................................................... 1092 9.4.2.156 Cluster Time Offset element ............................................................ 1093 9.4.2.157 Antenna Sector ID Pattern element................................................... 1094 9.4.2.158 VHT Capabilities element................................................................. 1095 9.4.2.159 VHT Operation element.................................................................... 1102 9.4.2.160 Extended BSS Load element............................................................. 1104 9.4.2.161 Wide Bandwidth Channel Switch element ....................................... 1105 9.4.2.162 Transmit Power Envelope element ................................................... 1106 9.4.2.163 Channel Switch Wrapper element..................................................... 1108 9.4.2.164 AID element...................................................................................... 1109 9.4.2.165 Quiet Channel element...................................................................... 1109 9.4.2.166 Operating Mode Notification element .............................................. 1110 9.4.2.167 UPSIM element................................................................................. 1110 9.4.2.168 Fine Timing Measurement Parameters element................................ 1111 9.4.2.169 Device Location element .................................................................. 1115 9.4.2.170 White Space Map element ................................................................ 1115 9.4.2.171 Reduced Neighbor Report element ................................................... 1115 9.4.2.172 TVHT Operation element ................................................................. 1117 9.4.2.173 FTM Synchronization Information element ..................................... 1118 9.4.2.174 Estimated service parameters element .............................................. 1118 9.4.2.175 Future Channel Guidance element.................................................... 1120 9.4.3 Subelements ......................................................................................................... 1121 9.4.4 TLV encodings .................................................................................................... 1122 9.4.4.1 General .............................................................................................. 1122 9.4.4.2 Common TLVs ................................................................................. 1122 9.4.5 Access network query protocol (ANQP) elements.............................................. 1127 9.4.5.1 General .............................................................................................. 1127 9.4.5.2 Query List ANQP-element................................................................ 1128 9.4.5.3 Capability List ANQP-element......................................................... 1128 9.4.5.4 Venue Name ANQP-element............................................................ 1129 9.4.5.5 Emergency Call Number ANQP-element......................................... 1130 9.4.5.6 Network Authentication Type ANQP-element................................. 1130 9.4.5.7 Roaming Consortium ANQP-element .............................................. 1132 9.4.5.8 Vendor Specific ANQP-element....................................................... 1132 9.4.5.9 IP Address Type Availability ANQP-element.................................. 1133 9.4.5.10 NAI Realm ANQP-element .............................................................. 1134 9.4.5.11 3GPP Cellular Network ANQP-element........................................... 1137 9.4.5.12 AP Geospatial Location ANQP-element .......................................... 1138 9.4.5.13 AP Civic Location ANQP-element................................................... 1138 9.4.5.14 AP Location Public Identifier URI/FQDN ANQP-element ............. 1139 9.4.5.15 Domain Name ANQP-element ......................................................... 1139 9.4.5.16 Emergency Alert URI ANQP-element ............................................. 1140 9.4.5.17 Emergency NAI ANQP-element ...................................................... 1140 9.4.5.18 TDLS Capability ANQP-element ..................................................... 1140 9.4.5.19 Neighbor Report ANQP-element...................................................... 1141 9.4.5.20 Venue URL ANQP-element ............................................................. 1141 9.4.5.21 Advice of Charge ANQP-element .................................................... 1142 9.4.5.22 Local Content ANQP-element .......................................................... 1143 9.4.5.23 Network Authentication Type with Timestamp ANQP-element...... 1144 34 Copyright Â© 2016 IEEE. All rights reserved. 9.4.6 Registered location query protocol (RLQP) elements ......................................... 1144 9.4.6.1 General .............................................................................................. 1144 9.4.6.2 Channel Availability Query RLQP-element .................................... 1145 9.4.6.3 Channel Schedule Management RLQP-element............................... 1147 9.4.6.4 Network Channel Control RLQP-element........................................ 1147 9.4.6.5 Vendor Specific RLQP-element ....................................................... 1148 9.5 Fields used in Management and Extension frame bodies and Control frames .................... 1149 9.5.1 Sector Sweep field ............................................................................................... 1149 9.5.2 Dynamic Allocation Info field ............................................................................. 1149 9.5.3 Sector Sweep Feedback field ............................................................................... 1150 9.5.4 BRP Request field................................................................................................ 1151 9.5.5 Beamforming Control field.................................................................................. 1152 9.5.6 Beamformed Link Maintenance field .................................................................. 1154 9.6 Action frame format details ................................................................................................. 1155 9.6.1 Introduction.......................................................................................................... 1155 9.6.2 Spectrum management Action frames ................................................................. 1155 9.6.2.1 General .............................................................................................. 1155 9.6.2.2 Measurement Request frame format ................................................. 1156 9.6.2.3 Measurement Report frame format ................................................... 1156 9.6.2.4 TPC Request frame format ............................................................... 1156 9.6.2.5 TPC Report frame format ................................................................. 1157 9.6.2.6 Channel Switch Announcement frame format.................................. 1157 9.6.3 QoS Action frame details..................................................................................... 1158 9.6.3.1 General .............................................................................................. 1158 9.6.3.2 Basic and DMG ADDTS Request frame format .............................. 1159 9.6.3.3 Basic and DMG ADDTS Response frame format ............................ 1161 9.6.3.4 DELTS frame format ........................................................................ 1163 9.6.3.5 Schedule frame format ...................................................................... 1164 9.6.3.6 QoS Map Configure frame format .................................................... 1165 9.6.3.7 ADDTS Reserve Request frame format............................................ 1165 9.6.3.8 ADDTS Reserve Response frame format ......................................... 1166 9.6.4 DLS Action frame details .................................................................................... 1166 9.6.4.1 General .............................................................................................. 1166 9.6.4.2 DLS Request frame format ............................................................... 1167 9.6.4.3 DLS Response frame format............................................................. 1167 9.6.4.4 DLS Teardown frame format............................................................ 1168 9.6.5 Block Ack Action frame details........................................................................... 1169 9.6.5.1 General .............................................................................................. 1169 9.6.5.2 ADDBA Request frame format......................................................... 1169 9.6.5.3 ADDBA Response frame format ...................................................... 1170 9.6.5.4 DELBA frame format ....................................................................... 1171 9.6.6 Vendor-specific action details ............................................................................. 1172 9.6.7 Radio Measurement action details ....................................................................... 1173 9.6.7.1 General .............................................................................................. 1173 9.6.7.2 Radio Measurement Request frame format ...................................... 1173 9.6.7.3 Radio Measurement Report frame format ........................................ 1174 9.6.7.4 Link Measurement Request frame format ........................................ 1174 9.6.7.5 Link Measurement Report frame format .......................................... 1175 9.6.7.6 Neighbor Report Request frame format............................................ 1175 9.6.7.7 Neighbor Report Response frame format ......................................... 1176 9.6.8 Public Action details ............................................................................................ 1177 9.6.8.1 Public Action frames......................................................................... 1177 9.6.8.2 20/40 BSS Coexistence Management frame format ......................... 1178 9.6.8.3 Measurement Pilot frame format ...................................................... 1179 35 Copyright Â© 2016 IEEE. All rights reserved. 9.6.8.4 DSE Enablement frame format ......................................................... 1180 9.6.8.5 DSE Deenablement frame format ..................................................... 1181 9.6.8.6 DSE Registered Location Announcement frame format .................. 1182 9.6.8.7 Extended Channel Switch Announcement frame format.................. 1182 9.6.8.8 DSE Measurement Request frame format ........................................ 1183 9.6.8.9 DSE Measurement Report frame format .......................................... 1183 9.6.8.10 DSE Power Constraint frame format ................................................ 1185 9.6.8.11 Vendor Specific Public Action frame format ................................... 1186 9.6.8.12 GAS Initial Request frame format .................................................... 1186 9.6.8.13 GAS Initial Response frame format.................................................. 1187 9.6.8.14 GAS Comeback Request frame format............................................. 1188 9.6.8.15 GAS Comeback Response frame format .......................................... 1189 9.6.8.16 TDLS Discovery Response frame format......................................... 1190 9.6.8.17 Location Track Notification frame format........................................ 1191 9.6.8.18 QMF Policy frame format................................................................. 1192 9.6.8.19 QMF Policy Change frame format.................................................... 1193 9.6.8.20 QLoad Request frame format............................................................ 1193 9.6.8.21 QLoad Report frame format.............................................................. 1194 9.6.8.22 HCCA TXOP Advertisement frame ................................................. 1194 9.6.8.23 HCCA TXOP Response frame ......................................................... 1195 9.6.8.24 Public Key frame .............................................................................. 1196 9.6.8.25 Channel Availability Query frame format ........................................ 1197 9.6.8.26 Channel Schedule Management frame format.................................. 1197 9.6.8.27 Contact Verification Signal frame format......................................... 1199 9.6.8.28 GDD Enablement Request frame format .......................................... 1199 9.6.8.29 GDD Enablement Response frame format........................................ 1200 9.6.8.30 Network Channel Control frame format ........................................... 1200 9.6.8.31 White Space Map Announcement frame format............................... 1201 9.6.8.32 Fine Timing Measurement Request frame format ............................ 1201 9.6.8.33 Fine Timing Measurement frame format .......................................... 1202 9.6.8.34 QAB Request frame format .............................................................. 1205 9.6.8.35 QAB Response frame format............................................................ 1205 9.6.9 FT Action frame details ....................................................................................... 1206 9.6.9.1 General .............................................................................................. 1206 9.6.9.2 FT Request frame.............................................................................. 1207 9.6.9.3 FT Response frame ........................................................................... 1207 9.6.9.4 FT Confirm frame ............................................................................. 1208 9.6.9.5 FT Ack frame .................................................................................... 1209 9.6.10 SA Query Action frame details............................................................................ 1209 9.6.10.1 General .............................................................................................. 1209 9.6.10.2 SA Query Request frame .................................................................. 1210 9.6.10.3 SA Query Response frame................................................................ 1210 9.6.11 Protected Dual of Public Action frames .............................................................. 1211 9.6.12 HT Action frame details ...................................................................................... 1212 9.6.12.1 HT Action field ................................................................................. 1212 9.6.12.2 Notify Channel Width frame format................................................. 1212 9.6.12.3 SM Power Save frame format........................................................... 1213 9.6.12.4 PSMP frame format .......................................................................... 1213 9.6.12.5 Set PCO Phase frame format ............................................................ 1214 9.6.12.6 CSI frame format .............................................................................. 1214 9.6.12.7 Noncompressed Beamforming frame format.................................... 1215 9.6.12.8 Compressed Beamforming frame format.......................................... 1215 9.6.12.9 Antenna Selection Indices Feedback frame format .......................... 1216 9.6.13 TDLS Action field formats .................................................................................. 1216 36 Copyright Â© 2016 IEEE. All rights reserved. 9.6.13.1 General .............................................................................................. 1216 9.6.13.2 TDLS Setup Request Action field format......................................... 1217 9.6.13.3 TDLS Setup Response Action field format ...................................... 1218 9.6.13.4 TDLS Setup Confirm Action field format ........................................ 1220 9.6.13.5 TDLS Teardown Action field format................................................ 1221 9.6.13.6 TDLS Peer Traffic Indication Action field format ........................... 1221 9.6.13.7 TDLS Channel Switch Request Action field format ........................ 1222 9.6.13.8 TDLS Channel Switch Response Action field format ...................... 1222 9.6.13.9 TDLS Peer PSM Request Action field format.................................. 1223 9.6.13.10 TDLS Peer PSM Response Action field format ............................... 1223 9.6.13.11 TDLS Peer Traffic Response Action field format ............................ 1224 9.6.13.12 TDLS Discovery Request Action field format ................................. 1224 9.6.14 WNM Action details ............................................................................................ 1225 9.6.14.1 WNM Action fields........................................................................... 1225 9.6.14.2 Event Request frame format ............................................................. 1226 9.6.14.3 Event Report frame format ............................................................... 1226 9.6.14.4 Diagnostic Request frame format ..................................................... 1227 9.6.14.5 Diagnostic Report frame format ....................................................... 1227 9.6.14.6 Location Configuration Request frame format ................................. 1228 9.6.14.7 Location Configuration Response frame format............................... 1229 9.6.14.8 BSS Transition Management Query frame format ........................... 1230 9.6.14.9 BSS Transition Management Request frame format ........................ 1230 9.6.14.10 BSS Transition Management Response frame format ...................... 1232 9.6.14.11 FMS Request frame format............................................................... 1233 9.6.14.12 FMS Response frame format ............................................................ 1234 9.6.14.13 Collocated Interference Request frame format ................................. 1234 9.6.14.14 Collocated Interference Report frame format ................................... 1235 9.6.14.15 TFS Request frame format................................................................ 1236 9.6.14.16 TFS Response frame format ............................................................. 1236 9.6.14.17 TFS Notify frame format .................................................................. 1237 9.6.14.18 TFS Notify Response frame format .................................................. 1237 9.6.14.19 WNM Sleep Mode Request frame format ........................................ 1237 9.6.14.20 WNM Sleep Mode Response frame format...................................... 1238 9.6.14.21 TIM Broadcast Request frame format .............................................. 1240 9.6.14.22 TIM Broadcast Response frame format ............................................ 1240 9.6.14.23 QoS Traffic Capability Update frame format ................................... 1241 9.6.14.24 Channel Usage Request frame format .............................................. 1241 9.6.14.25 Channel Usage Response frame format ............................................ 1242 9.6.14.26 DMS Request frame format .............................................................. 1243 9.6.14.27 DMS Response frame format............................................................ 1243 9.6.14.28 Timing Measurement Request frame format .................................... 1243 9.6.14.29 WNM Notification Request frame format ........................................ 1244 9.6.14.30 WNM Notification Response frame format...................................... 1245 9.6.15 Unprotected WNM Action details ....................................................................... 1245 9.6.15.1 Unprotected WNM Action fields...................................................... 1245 9.6.15.2 TIM frame format ............................................................................. 1246 9.6.15.3 Timing Measurement frame format .................................................. 1246 9.6.16 Self-protected Action frame details ..................................................................... 1247 9.6.16.1 Self-protected Action fields .............................................................. 1247 9.6.16.2 Mesh Peering Open frame format ..................................................... 1248 9.6.16.3 Mesh Peering Confirm frame format ................................................ 1249 9.6.16.4 Mesh Peering Close frame format .................................................... 1251 9.6.16.5 Mesh Group Key Inform frame format............................................. 1251 9.6.16.6 Mesh Group Key Acknowledge frame format.................................. 1252 37 Copyright Â© 2016 IEEE. All rights reserved. 9.6.17 Mesh Action frame details ................................................................................... 1253 9.6.17.1 Mesh Action fields ............................................................................ 1253 9.6.17.2 Mesh Link Metric Report frame format............................................ 1253 9.6.17.3 HWMP Mesh Path Selection frame format ...................................... 1254 9.6.17.4 Gate Announcement frame format.................................................... 1254 9.6.17.5 Congestion Control Notification frame format................................. 1255 9.6.17.6 MCCA Setup Request frame format................................................. 1255 9.6.17.7 MCCA Setup Reply frame format .................................................... 1256 9.6.17.8 MCCA Advertisement Request frame format .................................. 1256 9.6.17.9 MCCA Advertisement frame format ................................................ 1257 9.6.17.10 MCCA Teardown frame format........................................................ 1257 9.6.17.11 TBTT Adjustment Request frame format ......................................... 1258 9.6.17.12 TBTT Adjustment Response frame format....................................... 1258 9.6.18 Multihop Action frame details ............................................................................. 1259 9.6.18.1 Multihop Action fields ...................................................................... 1259 9.6.18.2 Proxy Update frame format............................................................... 1259 9.6.18.3 Proxy Update Confirmation frame format ........................................ 1260 9.6.19 Robust AV Streaming Action frame details ........................................................ 1260 9.6.19.1 General ............................................................................................. 1260 9.6.19.2 SCS Request frame format................................................................ 1261 9.6.19.3 SCS Response frame format ............................................................. 1261 9.6.19.4 Group Membership Request frame format ....................................... 1262 9.6.19.5 Group Membership Response frame format..................................... 1262 9.6.20 DMG Action frame details .................................................................................. 1263 9.6.20.1 DMG Action field ............................................................................. 1263 9.6.20.2 Power Save Configuration Request frame format ............................ 1263 9.6.20.3 Power Save Configuration Response frame format.......................... 1264 9.6.20.4 Information Request frame format.................................................... 1265 9.6.20.5 Information Response frame format ................................................. 1265 9.6.20.6 Handover Request frame format ....................................................... 1266 9.6.20.7 Handover Response frame format..................................................... 1267 9.6.20.8 DTP Request frame format ............................................................... 1267 9.6.20.9 DTP Report frame format ................................................................. 1268 9.6.20.10 Relay Search Request frame format.................................................. 1268 9.6.20.11 Relay Search Response frame format ............................................... 1269 9.6.20.12 Multi-relay Channel Measurement Request frame format ............... 1269 9.6.20.13 Multi-relay Channel Measurement Report frame format ................. 1270 9.6.20.14 RLS Request frame format ............................................................... 1271 9.6.20.15 RLS Response frame format ............................................................. 1272 9.6.20.16 RLS Announcement frame format.................................................... 1272 9.6.20.17 RLS Teardown frame format ............................................................ 1273 9.6.20.18 Relay Ack Request frame format...................................................... 1274 9.6.20.19 Relay Ack Response frame format ................................................... 1274 9.6.20.20 TPA Request frame format ............................................................... 1275 9.6.20.21 TPA Response frame format............................................................. 1275 9.6.20.22 TPA Report frame format ................................................................. 1276 9.6.20.23 ROC Request frame format............................................................... 1276 9.6.20.24 ROC Response frame format ............................................................ 1277 9.6.21 FST Action frame details ..................................................................................... 1278 9.6.21.1 FST Action field................................................................................ 1278 9.6.21.2 FST Setup Request frame format...................................................... 1278 9.6.21.3 FST Setup Response frame format ................................................... 1279 9.6.21.4 FST Teardown frame format............................................................. 1280 9.6.21.5 FST Ack Request frame format ........................................................ 1281 38 Copyright Â© 2016 IEEE. All rights reserved. 9.6.21.6 FST Ack Response frame format...................................................... 1281 9.6.21.7 On-channel Tunnel Request frame format........................................ 1282 9.6.22 Unprotected DMG Action frame details.............................................................. 1283 9.6.22.1 Unprotected DMG Action field ........................................................ 1283 9.6.22.2 Announce frame format .................................................................... 1283 9.6.22.3 BRP frame format ............................................................................. 1284 9.6.23 VHT Action frame details.................................................................................... 1285 9.6.23.1 VHT Action field .............................................................................. 1285 9.6.23.2 VHT Compressed Beamforming frame format ................................ 1286 9.6.23.3 Group ID Management frame format ............................................... 1286 9.6.23.4 Operating Mode Notification frame format ...................................... 1287 9.7 Aggregate MPDU (A-MPDU)............................................................................................. 1287 9.7.1 A-MPDU format .................................................................................................. 1287 9.7.2 MPDU delimiter CRC field ................................................................................. 1290 9.7.3 A-MPDU contents ............................................................................................... 1290 10. MAC sublayer functional description.............................................................................................. 1295 10.1 Introduction.......................................................................................................................... 1295 10.2 MAC architecture ................................................................................................................ 1295 10.2.1 General................................................................................................................. 1295 10.2.2 DCF...................................................................................................................... 1296 10.2.3 PCF ...................................................................................................................... 1297 10.2.4 Hybrid coordination function (HCF) ................................................................... 1297 10.2.4.1 General .............................................................................................. 1297 10.2.4.2 HCF contention based channel access (EDCA)................................ 1297 10.2.4.3 HCF controlled channel access (HCCA) .......................................... 1300 10.2.5 Mesh coordination function (MCF) ..................................................................... 1301 10.2.6 Combined use of DCF, PCF, and HCF................................................................ 1301 10.2.7 Fragmentation/defragmentation overview ........................................................... 1301 10.2.8 MAC data service ................................................................................................ 1302 10.3 DCF...................................................................................................................................... 1303 10.3.1 General................................................................................................................. 1303 10.3.2 Procedures common to the DCF and EDCAF ..................................................... 1305 10.3.2.1 CS mechanism................................................................................... 1305 10.3.2.2 MAC-level acknowledgments........................................................... 1305 10.3.2.3 IFS..................................................................................................... 1306 10.3.2.4 Setting and resetting the NAV .......................................................... 1310 10.3.2.5 RTS/CTS with fragmentation ........................................................... 1311 10.3.2.6 VHT RTS procedure ......................................................................... 1313 10.3.2.7 CTS and DMG CTS procedure......................................................... 1313 10.3.2.8 Dual CTS protection ......................................................................... 1314 10.3.2.9 Acknowledgment procedure ............................................................. 1316 10.3.2.10 MU acknowledgment procedure....................................................... 1317 10.3.2.11 Duplicate detection and recovery...................................................... 1319 10.3.2.12 NAV distribution............................................................................... 1322 10.3.2.13 Operation of aSlotTime..................................................................... 1323 10.3.3 Random backoff time........................................................................................... 1323 10.3.4 DCF access procedure ......................................................................................... 1324 10.3.4.1 Introduction....................................................................................... 1324 10.3.4.2 Basic access....................................................................................... 1324 10.3.4.3 Backoff procedure for DCF .............................................................. 1325 10.3.4.4 Recovery procedures and retransmit limits....................................... 1328 10.3.4.5 Control of the channel....................................................................... 1329 39 Copyright Â© 2016 IEEE. All rights reserved. 10.3.5 Individually addressed MPDU transfer procedure .............................................. 1330 10.3.6 Group addressed MPDU transfer procedure........................................................ 1330 10.3.7 DCF timing relations ........................................................................................... 1331 10.3.8 Signal extension ................................................................................................... 1334 10.3.9 Determination of PLME aCWmin characteristics ............................................... 1334 10.4 PCF ...................................................................................................................................... 1334 10.4.1 General................................................................................................................. 1334 10.4.2 CFP structure and timing ..................................................................................... 1335 10.4.3 PCF access procedure .......................................................................................... 1337 10.4.3.1 General .............................................................................................. 1337 10.4.3.2 Fundamental access........................................................................... 1337 10.4.3.3 NAV operation during the CFP ........................................................ 1337 10.4.4 PCF transfer procedure ........................................................................................ 1338 10.4.4.1 General .............................................................................................. 1338 10.4.4.2 PCF transfers when the PC STA is transmitter or recipient ............. 1338 10.4.4.3 Operation with overlapping point-coordinated BSSs ....................... 1340 10.4.4.4 CFPMaxDuration limit ..................................................................... 1340 10.4.4.5 CF usage rules................................................................................... 1340 10.4.5 CF polling list ...................................................................................................... 1341 10.4.5.1 General .............................................................................................. 1341 10.4.5.2 Polling list processing ....................................................................... 1341 10.4.5.3 Polling list update procedure............................................................. 1341 10.5 Fragmentation ...................................................................................................................... 1342 10.6 Defragmentation .................................................................................................................. 1342 10.7 Multirate support.................................................................................................................. 1343 10.7.1 Overview.............................................................................................................. 1343 10.7.2 Basic HT-MCS Set field ...................................................................................... 1344 10.7.3 Basic STBC MCS ................................................................................................ 1344 10.7.4 Basic rate set, basic HT-MCS set, and basic VHT-MCS and NSS set for mesh STA ............................................................................................................ 1345 10.7.5 Rate selection for Data and Management frames ................................................ 1345 10.7.5.1 Rate selection for non-STBC Beacon and non-STBC PSMP frames................................................................................................ 1345 10.7.5.2 Rate selection for STBC group addressed Data and Management frames................................................................................................ 1345 10.7.5.3 Rate selection for other group addressed Data and Management frames................................................................................................ 1345 10.7.5.4 Rate selection for polling frames ...................................................... 1346 10.7.5.5 Rate selection for +CF-Ack frames .................................................. 1346 10.7.5.6 Rate selection for Data frames sent within an FMS stream .............. 1346 10.7.5.7 Rate selection for other individually addressed Data and Management frames.......................................................................... 1346 10.7.6 Rate selection for Control frames ........................................................................ 1348 10.7.6.1 General rules for rate selection for Control frames........................... 1348 10.7.6.2 Rate selection for Control frames that initiate a TXOP .................... 1349 10.7.6.3 Rate selection for CF-End frames..................................................... 1349 10.7.6.4 Rate selection for Control frames that are not control response frames................................................................................................ 1350 10.7.6.5 Rate selection for control response frames ....................................... 1351 10.7.6.6 Channel Width selection for Control frames .................................... 1355 10.7.6.7 Control frame TXVECTOR parameter restrictions .......................... 1356 10.7.7 Multirate support for DMG STAs ....................................................................... 1356 10.7.7.1 Usage of DMG Control modulation class......................................... 1356 40 Copyright Â© 2016 IEEE. All rights reserved. 10.7.7.2 Rate selection rules for Control frames transmitted by DMG STAs ....................................................................................... 1356 10.7.7.3 Rate selection for group addressed Data and Management frames transmitted by DMG STAs ............................................................... 1357 10.7.7.4 Rate selection for individually addressed Data and Management frames transmitted by DMG STAs ................................................... 1358 10.7.7.5 Rate selection for BRP packets......................................................... 1358 10.7.8 Multiple BSSID Rate Selection ........................................................................... 1358 10.7.9 Modulation classes............................................................................................... 1358 10.7.10 Non-HT basic rate calculation ............................................................................. 1359 10.7.11 Channel Width in non-HT and non-HT duplicate PPDUs .................................. 1360 10.7.12 Rate selection constraints for VHT STAs............................................................ 1361 10.7.12.1 Rx Supported VHT-MCS and NSS Set ............................................ 1361 10.7.12.2 Tx Supported VHT-MCS and NSS Set............................................. 1361 10.7.12.3 Additional rate selection constraints for VHT PPDUs ..................... 1362 10.8 MSDU transmission restrictions .......................................................................................... 1363 10.9 HT Control field operation .................................................................................................. 1364 10.10 Control Wrapper operation .................................................................................................. 1364 10.11 MSDU processing................................................................................................................ 1364 10.12 A-MSDU operation.............................................................................................................. 1365 10.13 A-MPDU operation.............................................................................................................. 1367 10.13.1 A-MPDU contents ............................................................................................... 1367 10.13.2 A-MPDU length limit rules ................................................................................. 1367 10.13.3 Minimum MPDU Start Spacing field .................................................................. 1367 10.13.4 A-MPDU aggregation of group addressed Data frames ...................................... 1368 10.13.5 Transport of A-MPDU by the PHY data service ................................................. 1369 10.13.6 A-MPDU padding for VHT PPDU...................................................................... 1369 10.13.7 Setting the EOF field of the MPDU delimiter ..................................................... 1370 10.13.8 Transport of VHT single MPDUs........................................................................ 1370 10.14 PPDU duration constraint .................................................................................................... 1371 10.15 DMG A-PPDU operation..................................................................................................... 1371 10.16 LDPC operation ................................................................................................................... 1371 10.17 STBC operation ................................................................................................................... 1372 10.18 Short GI operation ............................................................................................................... 1372 10.19 Greenfield operation ............................................................................................................ 1373 10.20 Group ID and partial AID in VHT PPDUs.......................................................................... 1373 10.21 Operation across regulatory domains .................................................................................. 1375 10.21.1 General................................................................................................................. 1375 10.21.2 Operation upon entering a regulatory domain ..................................................... 1375 10.21.3 Operation with operating classes ......................................................................... 1375 10.21.4 Operation with the Transmit Power Envelope element ....................................... 1376 10.21.5 Operation with coverage classes.......................................................................... 1376 10.22 HCF...................................................................................................................................... 1377 10.22.1 General................................................................................................................. 1377 10.22.2 HCF contention based channel access (EDCA) .................................................. 1377 10.22.2.1 Reference model ............................................................................... 1377 10.22.2.2 EDCA backoff procedure.................................................................. 1379 10.22.2.3 EDCA TXOPs................................................................................... 1380 10.22.2.4 Obtaining an EDCA TXOP............................................................... 1380 10.22.2.5 EDCA channel access in a VHT or TVHT BSS ............................... 1383 10.22.2.6 Sharing an EDCA TXOP .................................................................. 1384 10.22.2.7 Multiple frame transmission in an EDCA TXOP ............................. 1384 10.22.2.8 TXOP limits ...................................................................................... 1387 10.22.2.9 Truncation of TXOP ......................................................................... 1388 41 Copyright Â© 2016 IEEE. All rights reserved. 10.22.2.10 Termination of TXOP ....................................................................... 1389 10.22.2.11 Retransmit procedures....................................................................... 1390 10.22.3 HCF controlled channel access (HCCA) ............................................................. 1392 10.22.3.1 General .............................................................................................. 1392 10.22.3.2 HCCA procedure............................................................................... 1393 10.22.3.3 HCCA TXOP structure and timing................................................... 1396 10.22.3.4 NAV operation of a TXOP under HCCA ......................................... 1397 10.22.3.5 HCCA transfer rules.......................................................................... 1397 10.22.4 Admission control at the HC ............................................................................... 1400 10.22.4.1 General .............................................................................................. 1400 10.22.4.2 Contention based admission control procedures............................... 1400 10.22.4.3 Controlled-access admission control ................................................ 1402 10.23 Mesh coordination function (MCF) ..................................................................................... 1404 10.23.1 General................................................................................................................. 1404 10.23.2 MCF contention based channel access ................................................................ 1404 10.23.3 MCF controlled channel access (MCCA)............................................................ 1404 10.23.3.1 General .............................................................................................. 1404 10.23.3.2 MCCA activation .............................................................................. 1405 10.23.3.3 MCCAOP reservations ..................................................................... 1405 10.23.3.4 Neighborhood MCCAOP periods at a mesh STA ............................ 1406 10.23.3.5 MCCA access fraction (MAF).......................................................... 1407 10.23.3.6 MCCAOP setup procedure ............................................................... 1407 10.23.3.7 MCCAOP advertisement .................................................................. 1408 10.23.3.8 MCCAOP teardown.......................................................................... 1413 10.23.3.9 Access during MCCAOPs ................................................................ 1414 10.23.3.10 Interaction with time synchronization............................................... 1415 10.24 Block acknowledgment (block ack) .................................................................................... 1415 10.24.1 Introduction.......................................................................................................... 1415 10.24.2 Setup and modification of the block ack parameters ........................................... 1416 10.24.3 Data and acknowledgment transfer using immediate block ack policy and delayed block ack policy...................................................................................... 1418 10.24.4 Receive buffer operation...................................................................................... 1420 10.24.5 Teardown of the block ack mechanism ............................................................... 1421 10.24.6 Selection of BlockAck and BlockAckReq variants ............................................. 1421 10.24.7 HT-immediate block ack extensions.................................................................... 1422 10.24.7.1 Introduction to HT-immediate block ack extensions........................ 1422 10.24.7.2 HT-immediate block ack architecture............................................... 1422 10.24.7.3 Scoreboard context control during full-state operation..................... 1423 10.24.7.4 Scoreboard context control during partial-state operation ................ 1424 10.24.7.5 Generation and transmission of BlockAck frames by an HT STA or DMG STA .................................................................................... 1425 10.24.7.6 Receive reordering buffer control operation ..................................... 1426 10.24.7.7 Originatorâ€™s behavior ........................................................................ 1428 10.24.7.8 Maintaining block ack state at the originator.................................... 1429 10.24.7.9 Originatorâ€™s support of recipientâ€™s partial state ................................ 1429 10.24.8 HT-delayed block ack extensions ........................................................................ 1430 10.24.8.1 Introduction....................................................................................... 1430 10.24.8.2 HT-delayed block ack negotiation .................................................... 1430 10.24.8.3 Operation of HT-delayed block ack.................................................. 1430 10.24.9 Protected block ack agreement ............................................................................ 1430 10.24.10 GCR block ack..................................................................................................... 1431 10.24.10.1 Introduction....................................................................................... 1431 10.24.10.2 Scoreboard context control during GCR block ack .......................... 1431 10.24.10.3 GCR block ack BlockAckReq and BlockAck frame exchanges ...... 1432 42 Copyright Â© 2016 IEEE. All rights reserved. 10.24.11 DMG block ack with flow control ....................................................................... 1434 10.24.11.1 General .............................................................................................. 1434 10.24.11.2 DMG block ack architecture with flow control ................................ 1434 10.24.11.3 Scoreboard context control with flow control................................... 1435 10.24.11.4 Receive Reordering Buffer with flow control operation .................. 1435 10.24.11.5 Generation and transmission of BlockAck frame by a STA with flow control ....................................................................................... 1437 10.24.11.6 Originatorâ€™s behavior with flow control support .............................. 1438 10.25 No Acknowledgment (No Ack) ........................................................................................... 1438 10.26 Protection mechanisms ........................................................................................................ 1438 10.26.1 Introduction.......................................................................................................... 1438 10.26.2 Protection mechanism for non-ERP receivers ..................................................... 1438 10.26.3 Protection mechanisms for transmissions of HT PPDUs .................................... 1440 10.26.3.1 General .............................................................................................. 1440 10.26.3.2 Protection rules for HT STA operating a direct link......................... 1443 10.26.3.3 RIFS protection ................................................................................. 1443 10.26.3.4 Use of OBSS Non-HT STAs Present field ....................................... 1443 10.26.3.5 Protection rules for an HT mesh STA............................................... 1444 10.26.4 L_LENGTH and L_DATARATE parameter values for HT-mixed format PPDUs.................................................................................................................. 1445 10.26.5 L-SIG TXOP protection....................................................................................... 1446 10.26.5.1 General rules ..................................................................................... 1446 10.26.5.2 L-SIG TXOP protection rules at the TXOP holder........................... 1447 10.26.5.3 L-SIG TXOP protection rules at the TXOP responder ..................... 1449 10.26.5.4 L-SIG TXOP protection NAV update rule ....................................... 1449 10.26.6 Protection rules for VHT STAs ........................................................................... 1449 10.27 MAC frame processing ........................................................................................................ 1449 10.27.1 Introduction.......................................................................................................... 1449 10.27.2 Revision level field processing ............................................................................ 1449 10.27.3 Duration/ID field processing ............................................................................... 1449 10.27.4 Response to an invalid Action frame ................................................................... 1450 10.27.5 Operation of the Dialog Token field.................................................................... 1450 10.27.6 Element parsing ................................................................................................... 1450 10.27.7 Vendor specific element parsing.......................................................................... 1450 10.27.8 Extensible element parsing .................................................................................. 1450 10.27.9 Extensible subelement parsing............................................................................. 1450 10.27.10 Extensible TLV parsing ....................................................................................... 1451 10.28 Reverse direction protocol ................................................................................................... 1451 10.28.1 General................................................................................................................. 1451 10.28.2 Reverse direction (RD) exchange sequence ........................................................ 1451 10.28.3 Rules for RD initiator .......................................................................................... 1452 10.28.4 Rules for RD responder ....................................................................................... 1453 10.29 PSMP operation ................................................................................................................... 1454 10.29.1 General................................................................................................................. 1454 10.29.2 Frame transmission mechanism during PSMP .................................................... 1454 10.29.2.1 PSMP frame transmission (PSMP-DTT and PSMP-UTT)............... 1454 10.29.2.2 PSMP downlink transmission (PSMP-DTT) .................................... 1455 10.29.2.3 PSMP uplink transmission (PSMP-UTT) ......................................... 1455 10.29.2.4 PSMP burst ....................................................................................... 1456 10.29.2.5 Resource allocation within a PSMP burst......................................... 1458 10.29.2.6 PSMP-UTT retransmission ............................................................... 1459 10.29.2.7 PSMP acknowledgment rules ........................................................... 1460 10.29.2.8 PSMP group addressed transmission rules ....................................... 1461 10.29.3 Scheduled PSMP.................................................................................................. 1462 43 Copyright Â© 2016 IEEE. All rights reserved. 10.29.4 Unscheduled PSMP ............................................................................................. 1462 10.30 Sounding PPDUs ................................................................................................................. 1462 10.31 Link adaptation .................................................................................................................... 1463 10.31.1 Introduction.......................................................................................................... 1463 10.31.2 Link adaptation using the HT variant HT Control field ...................................... 1464 10.31.3 Link adaptation using the VHT variant HT Control field ................................... 1466 10.32 Transmit beamforming ........................................................................................................ 1468 10.32.1 HT steering matrix calculations........................................................................... 1468 10.32.2 HT transmit beamforming with implicit feedback .............................................. 1469 10.32.2.1 General .............................................................................................. 1469 10.32.2.2 Unidirectional implicit transmit beamforming ................................. 1470 10.32.2.3 Bidirectional implicit transmit beamforming.................................... 1471 10.32.2.4 Calibration......................................................................................... 1472 10.32.3 Explicit feedback beamforming........................................................................... 1477 10.32.4 VHT MU beamforming ....................................................................................... 1481 10.33 Antenna selection (ASEL) ................................................................................................... 1481 10.33.1 Introduction.......................................................................................................... 1481 10.33.2 Procedure ............................................................................................................. 1482 10.34 Null data packet (NDP) sounding ........................................................................................ 1485 10.34.1 HT NDP sounding protocol ................................................................................. 1485 10.34.2 Transmission of an HT NDP ............................................................................... 1487 10.34.3 Determination of HT NDP destination ................................................................ 1487 10.34.4 Determination of HT NDP source ....................................................................... 1487 10.34.5 VHT sounding protocol ....................................................................................... 1488 10.34.5.1 General .............................................................................................. 1488 10.34.5.2 Rules for VHT sounding protocol sequences ................................... 1488 10.34.5.3 Rules for fragmented feedback in VHT sounding protocol sequences .......................................................................................... 1492 10.34.6 Transmission of a VHT NDP............................................................................... 1493 10.35 Mesh forwarding framework ............................................................................................... 1493 10.35.1 General................................................................................................................. 1493 10.35.2 Forwarding information ....................................................................................... 1494 10.35.3 Addressing and forwarding of individually addressed mesh Data frames .......... 1494 10.35.3.1 At source mesh STAs (individually addressed)................................ 1494 10.35.3.2 At intermediate and destination mesh STAs (individually addressed).......................................................................................... 1495 10.35.4 Addressing and forwarding of group addressed mesh Data frames .................... 1496 10.35.4.1 At source mesh STAs (group addressed) .......................................... 1496 10.35.4.2 At recipient mesh STAs (group addressed) ...................................... 1497 10.35.5 Addressing of Management frames and MMPDU forwarding ........................... 1497 10.35.5.1 General .............................................................................................. 1497 10.35.5.2 MMPDU forwarding using individually addressed Multihop Action frames.................................................................................... 1498 10.35.5.3 MMPDU forwarding using group addressed Multihop Action frames................................................................................................ 1498 10.35.6 Detection of duplicate MSDUs/MMPDUs .......................................................... 1499 10.35.7 Mesh STAs that do not forward........................................................................... 1499 10.35.8 MSDU forwarding and unknown destination ...................................................... 1499 10.36 DMG channel access ........................................................................................................... 1500 10.36.1 General................................................................................................................. 1500 10.36.2 Access periods within a beacon interval.............................................................. 1500 10.36.3 ATI transmission rules......................................................................................... 1501 10.36.4 DTI transmission rules......................................................................................... 1503 10.36.5 Contention based access period (CBAP) transmission rules ............................... 1504 44 Copyright Â© 2016 IEEE. All rights reserved. 10.36.6 Channel access in scheduled DTI ........................................................................ 1505 10.36.6.1 General .............................................................................................. 1505 10.36.6.2 Service period (SP) allocation........................................................... 1506 10.36.6.3 Contention based access period (CBAP) allocation ......................... 1507 10.36.6.4 Pseudo-static allocations ................................................................... 1508 10.36.6.5 Guard time......................................................................................... 1508 10.36.6.6 DMG protected period ...................................................................... 1509 10.36.6.7 Service period recovery .................................................................... 1513 10.36.7 Dynamic allocation of service period .................................................................. 1513 10.36.7.1 General .............................................................................................. 1513 10.36.7.2 Polling period (PP)............................................................................ 1515 10.36.7.3 Grant period (GP).............................................................................. 1516 10.36.8 Dynamic truncation of service period.................................................................. 1517 10.36.9 Dynamic extension of service period................................................................... 1518 10.36.10 Updating multiple NAVs ..................................................................................... 1519 10.37 DMG AP or PCP clustering................................................................................................. 1521 10.37.1 General................................................................................................................. 1521 10.37.2 Cluster formation ................................................................................................. 1522 10.37.2.1 Decentralized AP or PCP cluster formation ..................................... 1522 10.37.2.2 Centralized AP or PCP cluster formation ......................................... 1524 10.37.3 Cluster maintenance............................................................................................. 1527 10.37.3.1 General cluster maintenance ............................................................. 1527 10.37.3.2 Decentralized AP or PCP cluster maintenance ................................. 1527 10.37.3.3 Centralized AP or PCP cluster maintenance..................................... 1528 10.37.3.4 Centralized AP or PCP cluster MAC requirements .......................... 1529 10.37.4 Cluster report and re-scheduling.......................................................................... 1530 10.37.5 Decentralized AP or PCP cluster request ............................................................ 1532 10.38 DMG beamforming.............................................................................................................. 1532 10.38.1 General................................................................................................................. 1532 10.38.2 Sector-level sweep (SLS) phase .......................................................................... 1535 10.38.2.1 General .............................................................................................. 1535 10.38.2.2 Initiator sector sweep (ISS)............................................................... 1537 10.38.2.3 Responder sector sweep (RSS) ......................................................... 1539 10.38.2.4 Sector sweep (SSW) feedback .......................................................... 1541 10.38.2.5 SSW ack............................................................................................ 1542 10.38.3 Beam Refinement Protocol (BRP) phase............................................................. 1543 10.38.3.1 General .............................................................................................. 1543 10.38.3.2 BRP setup subphase .......................................................................... 1545 10.38.4 Beamforming in BTI............................................................................................ 1547 10.38.5 Beamforming in A-BFT....................................................................................... 1548 10.38.5.1 Allocation of A-BFT ........................................................................ 1548 10.38.5.2 Operation during the A-BFT............................................................. 1548 10.38.5.3 STA Beamforming after A-BFT ....................................................... 1552 10.38.5.4 Beamforming in A-BFT with multiple DMG antennas .................... 1553 10.38.6 Beamforming in DTI ........................................................................................... 1553 10.38.6.1 General .............................................................................................. 1553 10.38.6.2 SLS phase execution ......................................................................... 1554 10.38.6.3 Multiple sector ID capture (MIDC) subphase .................................. 1555 10.38.6.4 BRP phase execution ........................................................................ 1563 10.38.7 Beam tracking ...................................................................................................... 1566 10.38.8 State machines ..................................................................................................... 1568 10.39 DMG link adaptation ........................................................................................................... 1570 10.39.1 General................................................................................................................. 1570 10.39.2 DMG TPC............................................................................................................ 1570 45 Copyright Â© 2016 IEEE. All rights reserved. 10.39.3 Fast link adaptation .............................................................................................. 1571 10.40 DMG dynamic tone pairing (DTP) ...................................................................................... 1572 10.41 DMG relay operation ........................................................................................................... 1573 10.41.1 General................................................................................................................. 1573 10.41.2 Link switching ..................................................................................................... 1573 10.41.2.1 General .............................................................................................. 1573 10.41.2.2 SP request and allocation .................................................................. 1573 10.41.2.3 Usage of RDS.................................................................................... 1574 10.41.2.4 Relay frame exchange rules .............................................................. 1574 10.41.2.5 Link monitoring ................................................................................ 1577 10.41.3 Link cooperation .................................................................................................. 1577 10.41.3.1 TPA procedure .................................................................................. 1577 10.41.3.2 Frame exchange operation ................................................................ 1579 10.41.4 Relay link adaptation ........................................................................................... 1580 11. MLME ............................................................................................................................................. 1581 11.1 Synchronization ................................................................................................................... 1581 11.1.1 General................................................................................................................. 1581 11.1.2 Basic approach ..................................................................................................... 1581 11.1.2.1 TSF for an infrastructure BSS or a PBSS ......................................... 1581 11.1.2.2 TSF for an IBSS................................................................................ 1582 11.1.2.3 TSF for an MBSS.............................................................................. 1582 11.1.3 Maintaining synchronization ............................................................................... 1582 11.1.3.1 General .............................................................................................. 1582 11.1.3.2 Beacon generation in non-DMG infrastructure networks................. 1582 11.1.3.3 Beacon generation in a DMG infrastructure BSS and in a PBSS..... 1583 11.1.3.4 DMG beacon generation before establishment of a BSS.................. 1585 11.1.3.5 Beacon generation in an IBSS .......................................................... 1586 11.1.3.6 Beacon generation in an MBSS ........................................................ 1586 11.1.3.7 Beacon reception............................................................................... 1587 11.1.3.8 Multiple BSSID procedure................................................................ 1588 11.1.3.9 TSF timer accuracy ........................................................................... 1589 11.1.4 Acquiring synchronization, scanning .................................................................. 1589 11.1.4.1 General .............................................................................................. 1589 11.1.4.2 Passive scanning ............................................................................... 1591 11.1.4.3 Active scanning................................................................................. 1591 11.1.4.4 Initializing a BSS .............................................................................. 1596 11.1.4.5 Synchronizing with a BSS ................................................................ 1597 11.1.4.6 Operation of Supported Rates and BSS Membership Selectors element and Extended Supported Rates and BSS Membership Selectors element .............................................................................. 1597 11.1.5 Adjusting STA timers .......................................................................................... 1598 11.1.6 Terminating a BSS............................................................................................... 1599 11.1.7 Supported rates and extended supported rates advertisement ............................. 1599 11.2 Power management.............................................................................................................. 1599 11.2.1 General................................................................................................................. 1599 11.2.2 Bufferable MMPDUs........................................................................................... 1600 11.2.3 Power management in a non-DMG infrastructure network................................. 1600 11.2.3.1 General .............................................................................................. 1600 11.2.3.2 STA power management modes ....................................................... 1601 11.2.3.3 AP TIM transmissions ...................................................................... 1602 11.2.3.4 TIM types.......................................................................................... 1602 11.2.3.5 Power management with APSD........................................................ 1603 46 Copyright Â© 2016 IEEE. All rights reserved. 11.2.3.6 AP operation during the CP .............................................................. 1607 11.2.3.7 AP operation during the CFP ............................................................ 1610 11.2.3.8 Receive operation for STAs in PS mode during the CP ................... 1611 11.2.3.9 Receive operation for STAs in PS mode during the CFP ................. 1612 11.2.3.10 Receive operation using APSD......................................................... 1612 11.2.3.11 STAs operating in the active mode ................................................... 1613 11.2.3.12 AP aging function ............................................................................. 1613 11.2.3.13 PSMP power management ................................................................ 1613 11.2.3.14 TDLS peer power save mode............................................................ 1614 11.2.3.15 TDLS peer U-APSD (TPU) .............................................................. 1616 11.2.3.16 FMS power management .................................................................. 1618 11.2.3.17 TIM Broadcast .................................................................................. 1621 11.2.3.18 WNM sleep mode ............................................................................. 1623 11.2.3.19 VHT TXOP power save.................................................................... 1625 11.2.4 Power management in an IBSS ........................................................................... 1626 11.2.4.1 Introduction....................................................................................... 1626 11.2.4.2 Basic approach .................................................................................. 1626 11.2.4.3 Initialization of power management within an IBSS ........................ 1628 11.2.4.4 STA power state transitions .............................................................. 1628 11.2.5 Power management in an MBSS ......................................................................... 1629 11.2.6 SM power save..................................................................................................... 1629 11.2.7 Power management in a PBSS and DMG infrastructure BSS ............................ 1630 11.2.7.1 General .............................................................................................. 1630 11.2.7.2 Non-AP and non-PCP STA power management mode .................... 1632 11.2.7.3 PCP power management mode ......................................................... 1636 11.2.7.4 ATIM frame usage for power management of non-AP STAs .......... 1639 11.2.8 ATIM frame and frame transmission in IBSS, DMG infrastructure BSS, and PBSS ............................................................................................................. 1641 11.3 STA authentication and association..................................................................................... 1642 11.3.1 State variables ...................................................................................................... 1642 11.3.2 State transition diagram for nonmesh STAs ........................................................ 1643 11.3.3 Frame filtering based on STA state ..................................................................... 1643 11.3.4 Authentication and deauthentication ................................................................... 1646 11.3.4.1 General .............................................................................................. 1646 11.3.4.2 Authenticationâ€”originating STA..................................................... 1646 11.3.4.3 Authenticationâ€”destination STA..................................................... 1647 11.3.4.4 Deauthenticationâ€”originating STA ................................................. 1647 11.3.4.5 Deauthenticationâ€”destination STA ................................................. 1648 11.3.5 Association, reassociation, and disassociation .................................................... 1648 11.3.5.1 General .............................................................................................. 1648 11.3.5.2 Non-AP and non-PCP STA association initiation procedures.......... 1649 11.3.5.3 AP or PCP association receipt procedures........................................ 1651 11.3.5.4 Non-AP and non-PCP STA reassociation initiation procedures....... 1652 11.3.5.5 AP or PCP reassociation receipt procedures..................................... 1655 11.3.5.6 Non-AP and non-PCP STA disassociation initiation procedures ..... 1657 11.3.5.7 Non-AP and non-PCP STA disassociation receipt procedure .......... 1657 11.3.5.8 AP or PCP disassociation initiation procedure ................................. 1658 11.3.5.9 AP or PCP disassociation receipt procedure..................................... 1658 11.3.5.10 PBSS procedures for nonassociated STAs........................................ 1659 11.3.6 Additional mechanisms for an AP collocated with a mesh STA......................... 1659 11.3.7 Communicating PBSS information ..................................................................... 1659 11.3.8 Neighbor report information upon rejection with suggested BSS transition....... 1659 11.4 TS operation......................................................................................................................... 1660 11.4.1 Introduction.......................................................................................................... 1660 47 Copyright Â© 2016 IEEE. All rights reserved. 11.4.2 TSPEC construction............................................................................................. 1662 11.4.3 TS life cycle ......................................................................................................... 1662 11.4.4 TS setup ............................................................................................................... 1664 11.4.4.1 General .............................................................................................. 1664 11.4.4.2 Non-AP-STA-initiated TS setup....................................................... 1664 11.4.4.3 AP-initiated TS setup ........................................................................ 1665 11.4.4.4 TS setup procedures for both AP and non-AP STA initiation.......... 1666 11.4.4.5 TS renegotiation................................................................................ 1669 11.4.5 TS setup by resource request during a fast BSS transition .................................. 1669 11.4.6 PSMP management.............................................................................................. 1669 11.4.7 Failed TS setup .................................................................................................... 1670 11.4.8 Data transfer......................................................................................................... 1671 11.4.9 TS deletion ........................................................................................................... 1672 11.4.9.1 Deletion of a TS established between an HC, DMG AP, or PCP and a non-AP and non-PCP STA...................................................... 1672 11.4.9.2 Peer-to-peer TS deletion and deletion of an allocation..................... 1673 11.4.10 TS timeout............................................................................................................ 1675 11.4.11 TS suspension ...................................................................................................... 1676 11.4.12 TS reinstatement .................................................................................................. 1676 11.4.13 DMG allocation formats ...................................................................................... 1678 11.4.13.1 General .............................................................................................. 1678 11.4.13.2 Isochronous allocations..................................................................... 1678 11.4.13.3 Asynchronous allocations ................................................................ 1678 11.4.14 PTP TS operation................................................................................................. 1679 11.5 Block ack operation ............................................................................................................. 1679 11.5.1 Introduction.......................................................................................................... 1679 11.5.2 Setup and modification of the block ack parameters ........................................... 1679 11.5.2.1 General .............................................................................................. 1679 11.5.2.2 Procedure at the originator ................................................................ 1680 11.5.2.3 Procedure at the recipient.................................................................. 1681 11.5.2.4 Procedure common to both originator and recipient......................... 1681 11.5.3 Teardown of the block ack mechanism ............................................................... 1682 11.5.3.1 General .............................................................................................. 1682 11.5.3.2 Procedure at the initiator of the block ack teardown ........................ 1682 11.5.3.3 Procedure at the recipient of the DELBA frame............................... 1682 11.5.4 Error recovery upon a peer failure ....................................................................... 1683 11.6 Higher layer timer synchronization ..................................................................................... 1684 11.6.1 Introduction.......................................................................................................... 1684 11.6.2 Procedure at the STA ........................................................................................... 1685 11.7 DLS operation...................................................................................................................... 1685 11.7.1 General................................................................................................................. 1685 11.7.2 DLS procedures ................................................................................................... 1686 11.7.2.1 General .............................................................................................. 1686 11.7.2.2 Setup procedure at the QoS STA ...................................................... 1687 11.7.2.3 Setup procedure at the AP................................................................. 1687 11.7.2.4 Operation of the DLS Timeout Value field ...................................... 1687 11.7.3 Data transfer after setup ....................................................................................... 1688 11.7.4 DLS teardown ...................................................................................................... 1688 11.7.4.1 General .............................................................................................. 1688 11.7.4.2 STA-initiated DLS teardown procedure ........................................... 1688 11.7.4.3 Teardown procedure at the AP.......................................................... 1689 11.7.4.4 AP-initiated DLS teardown procedure.............................................. 1689 11.7.5 Error recovery upon a peer failure ....................................................................... 1690 11.7.6 Secure DLS operation .......................................................................................... 1690 48 Copyright Â© 2016 IEEE. All rights reserved. 11.8 TPC procedures.................................................................................................................... 1690 11.8.1 General................................................................................................................. 1690 11.8.2 Association based on transmit power capability.................................................. 1691 11.8.3 Peering based on transmit power capability ........................................................ 1692 11.8.4 Interpretation of transmit power capability ......................................................... 1692 11.8.5 Specification of regulatory and local maximum transmit power levels .............. 1693 11.8.6 Transmit power selection..................................................................................... 1694 11.8.7 Transmit power adaptation .................................................................................. 1694 11.9 DFS procedures.................................................................................................................... 1694 11.9.1 General................................................................................................................. 1694 11.9.2 Association based on supported channels............................................................ 1696 11.9.2.1 Association based on supported channels in a non-DMG BSS ........ 1696 11.9.2.2 Providing supported channels upon association in a DMG BSS ...... 1696 11.9.3 Quieting channels for testing ............................................................................... 1696 11.9.4 Testing channels for radar.................................................................................... 1697 11.9.5 Discontinuing operations after detecting radar .................................................... 1698 11.9.6 Detecting radar..................................................................................................... 1698 11.9.7 Requesting and reporting of measurements......................................................... 1698 11.9.8 Selecting and advertising a new channel ............................................................. 1699 11.9.8.1 General .............................................................................................. 1699 11.9.8.2 Selecting and advertising a new channel in a non-DMG infrastructure BSS ............................................................................. 1700 11.9.8.3 Selecting and advertising a new channel in an IBSS ........................ 1700 11.9.8.4 MBSS channel switching .................................................................. 1702 11.9.8.5 HT-greenfield transmissions in operating classes that include a behavior limit of DFS_50_100_Behavior......................................... 1704 11.9.8.6 Selecting and advertising a new channel in a DMG BSS ................. 1705 11.9.9 Channel Switch Announcement element operation............................................. 1705 11.9.10 Future Channel Guidance operation .................................................................... 1705 11.10 Extended channel switching (ECS) ..................................................................................... 1706 11.10.1 General................................................................................................................. 1706 11.10.2 Advertising supported operating classes.............................................................. 1706 11.10.3 Selecting and advertising a new channel and/or operating class ......................... 1706 11.10.3.1 General .............................................................................................. 1706 11.10.3.2 Selecting and advertising a new channel in an infrastructure BSS... 1707 11.10.3.3 Selecting and advertising a new channel in an IBSS ........................ 1708 11.10.3.4 Selecting and advertising a new channel in an MBSS...................... 1708 11.11 Radio measurement procedures ........................................................................................... 1709 11.11.1 General................................................................................................................. 1709 11.11.2 Measurement on operating and nonoperating channels....................................... 1709 11.11.3 Measurement start time........................................................................................ 1709 11.11.4 Measurement Duration ........................................................................................ 1710 11.11.5 Station responsibility for conducting measurements ........................................... 1711 11.11.6 Requesting and reporting of measurements......................................................... 1711 11.11.7 Repeated Measurement Request frames .............................................................. 1714 11.11.8 Triggered autonomous reporting ......................................................................... 1714 11.11.9 Specific measurement usage ................................................................................ 1716 11.11.9.1 Beacon report .................................................................................... 1716 11.11.9.2 Frame report...................................................................................... 1719 11.11.9.3 Channel load report........................................................................... 1720 11.11.9.4 Noise Histogram report..................................................................... 1720 11.11.9.5 STA Statistics report ......................................................................... 1721 11.11.9.6 LCI report (Location configuration information report)................... 1723 11.11.9.7 Measurement Pause........................................................................... 1724 49 Copyright Â© 2016 IEEE. All rights reserved. 11.11.9.8 Transmit Stream/Category Measurement report............................... 1725 11.11.9.9 Location Civic report ........................................................................ 1726 11.11.9.10 Location Identifier report .................................................................. 1728 11.11.9.11 Fine Timing Measurement Range report .......................................... 1729 11.11.10 Usage of the neighbor report ............................................................................... 1730 11.11.10.1 General .............................................................................................. 1730 11.11.10.2 Requesting a neighbor report ............................................................ 1730 11.11.10.3 Responding to a neighbor report request .......................................... 1731 11.11.11 Link Measurement ............................................................................................... 1733 11.11.12 Measurement of the RPI histogram ..................................................................... 1733 11.11.13 Operation of the Max Transmit Power field ........................................................ 1734 11.11.14 Multiple BSSID set .............................................................................................. 1734 11.11.15 Measurement Pilot frame generation and usage .................................................. 1734 11.11.15.1 General .............................................................................................. 1734 11.11.15.2 Measurement Pilot frame generation by an AP ................................ 1735 11.11.15.3 Measurement pilot usage by a STA .................................................. 1737 11.11.16 Access Delay Measurement................................................................................. 1737 11.11.17 BSS Available Admission Capacity .................................................................... 1737 11.11.18 AP Channel Report .............................................................................................. 1738 11.11.19 Multicast diagnostic reporting ............................................................................. 1738 11.11.20 CCA request and report ....................................................................................... 1739 11.11.21 RPI Histogram request and report ....................................................................... 1739 11.12 DSE procedures ................................................................................................................... 1739 11.12.1 General................................................................................................................. 1739 11.12.2 Enablement and deenablement ............................................................................ 1740 11.12.2.1 General .............................................................................................. 1740 11.12.2.2 Enablement requester STA ............................................................... 1741 11.12.2.3 Enablement responder STA .............................................................. 1741 11.12.2.4 Deenablement requester STA ........................................................... 1741 11.12.2.5 Deenablement responder STA .......................................................... 1742 11.12.3 Registered STA operation.................................................................................... 1742 11.12.4 Enabling STA operation with DSE...................................................................... 1742 11.12.5 Dependent STA operation with DSE................................................................... 1743 11.13 Group addressed robust management frame procedures ..................................................... 1745 11.14 SA Query procedures........................................................................................................... 1745 11.15 HT BSS Operation ............................................................................................................... 1746 11.16 20/40 MHz BSS operation ................................................................................................... 1746 11.16.1 Rules for operation in 20/40 MHz BSS ............................................................... 1746 11.16.2 Basic 20/40 MHz BSS functionality.................................................................... 1746 11.16.3 Channel scanning and selection methods for 20/40 MHz operation ................... 1747 11.16.3.1 General .............................................................................................. 1747 11.16.3.2 Scanning requirements for a 20/40 MHz BSS .................................. 1747 11.16.3.3 Channel management at the AP and in an IBSS............................... 1749 11.16.4 40 MHz PPDU transmission restrictions ............................................................. 1751 11.16.4.1 Fields used to determine 40 MHz PPDU transmission restrictions .. 1751 11.16.4.2 Infrastructure non-AP STA restrictions ............................................ 1751 11.16.4.3 AP restrictions................................................................................... 1752 11.16.4.4 Restrictions on non-AP STAs that are not infrastructure BSS members ............................................................................................ 1753 11.16.5 Scanning requirements for 40-MHz-capable STA .............................................. 1754 11.16.6 Exemption from OBSS scanning ......................................................................... 1754 11.16.7 Communicating 20/40 BSS coexistence information .......................................... 1755 11.16.8 Support of DSSS/CCK in 40 MHz ...................................................................... 1755 11.16.9 STA CCA sensing in a 20/40 MHz BSS ............................................................. 1756 50 Copyright Â© 2016 IEEE. All rights reserved. 11.16.10 NAV assertion in 20/40 MHz BSS ...................................................................... 1756 11.16.11 Signaling 40 MHz intolerance ............................................................................. 1756 11.16.12 Switching between 40 MHz and 20 MHz............................................................ 1757 11.17 Phased coexistence operation (PCO) ................................................................................... 1759 11.17.1 General description of PCO ................................................................................. 1759 11.17.2 Operation at a PCO active AP ............................................................................. 1760 11.17.3 Operation at a PCO active non-AP STA ............................................................. 1761 11.18 20/40 BSS Coexistence Management frame usage ............................................................. 1762 11.19 RSNA A-MSDU procedures ............................................................................................... 1763 11.20 Public Action frame addressing ........................................................................................... 1764 11.21 STAs communicating Data frames outside the context of a BSS........................................ 1764 11.22 Timing Advertisement ......................................................................................................... 1764 11.22.1 Introduction.......................................................................................................... 1764 11.22.2 Timing advertisement frame procedures ............................................................. 1765 11.22.3 UTC TSF Offset procedures ................................................................................ 1765 11.23 Tunneled direct-link setup ................................................................................................... 1765 11.23.1 General................................................................................................................. 1765 11.23.2 TDLS payload...................................................................................................... 1767 11.23.3 TDLS Discovery .................................................................................................. 1767 11.23.4 TDLS direct-link establishment........................................................................... 1767 11.23.5 TDLS direct-link teardown .................................................................................. 1769 11.23.6 TDLS channel switching ..................................................................................... 1770 11.23.6.1 General .............................................................................................. 1770 11.23.6.2 General behavior on the off-channel................................................. 1772 11.23.6.3 Setting up a 40 MHz direct link ........................................................ 1773 11.23.6.4 TDLS channel switching and power saving ..................................... 1774 11.23.6.5 Setting up a wide bandwidth off-channel direct link ........................ 1774 11.24 Wireless network management procedures ......................................................................... 1775 11.24.1 Wireless network management dependencies ..................................................... 1775 11.24.2 Event request and report procedures.................................................................... 1776 11.24.2.1 Event request and event report.......................................................... 1776 11.24.2.2 Transition event request and report................................................... 1777 11.24.2.3 RSNA event request and report ........................................................ 1778 11.24.2.4 Peer-to-peer link event request and report ........................................ 1778 11.24.2.5 WNM log event request and report................................................... 1779 11.24.2.6 Vendor Specific event request and report ......................................... 1779 11.24.3 Diagnostic request and report procedures............................................................ 1779 11.24.3.1 Diagnostic request and diagnostic report .......................................... 1779 11.24.3.2 Configuration Profile report.............................................................. 1781 11.24.3.3 Manufacturer information STA report.............................................. 1781 11.24.3.4 Association diagnostic ...................................................................... 1782 11.24.3.5 IEEE 802.1X authentication diagnostic ............................................ 1782 11.24.4 Location track procedures.................................................................................... 1783 11.24.4.1 Location track configuration procedures .......................................... 1783 11.24.4.2 Location track notification procedures ............................................. 1785 11.24.5 Timing measurement procedure .......................................................................... 1787 11.24.6 Fine timing measurement (FTM) procedure........................................................ 1789 11.24.6.1 Overview........................................................................................... 1789 11.24.6.2 FTM capabilities ............................................................................... 1790 11.24.6.3 Fine timing measurement procedure negotiation.............................. 1791 11.24.6.4 Measurement exchange..................................................................... 1793 11.24.6.5 Fine timing measurement parameter modification ........................... 1798 11.24.6.6 Fine timing measurement termination .............................................. 1798 11.24.6.7 LCI and Location Civic retrieval using FTM procedure .................. 1799 51 Copyright Â© 2016 IEEE. All rights reserved. 11.24.7 BSS transition management for network load balancing..................................... 1800 11.24.7.1 BSS transition capability................................................................... 1800 11.24.7.2 BSS transition management query.................................................... 1800 11.24.7.3 BSS transition management request ................................................. 1801 11.24.7.4 BSS transition management response ............................................... 1802 11.24.8 FMS multicast rate processing............................................................................. 1803 11.24.9 Collocated interference reporting ........................................................................ 1804 11.24.10 QoS Traffic capability procedure ........................................................................ 1805 11.24.11 AC Station Count................................................................................................. 1806 11.24.12 TFS procedures .................................................................................................... 1806 11.24.12.1 TFS capability ................................................................................... 1806 11.24.12.2 TFS non-AP STA operation.............................................................. 1808 11.24.12.3 TFS AP operation.............................................................................. 1808 11.24.13 BSS max idle period management....................................................................... 1809 11.24.14 Proxy ARP (including Proxy Neighbor Discovery) service ................................ 1809 11.24.15 Channel usage procedures ................................................................................... 1810 11.24.16 Group addressed transmission service ................................................................. 1811 11.24.16.1 General .............................................................................................. 1811 11.24.16.2 DMS procedures ............................................................................... 1811 11.24.16.3 GCR procedures................................................................................ 1814 11.24.17 WNM notification................................................................................................ 1824 11.25 WLAN interworking with external networks procedures.................................................... 1824 11.25.1 General................................................................................................................. 1824 11.25.2 Interworking capabilities and information........................................................... 1825 11.25.3 Interworking procedures: generic advertisement service (GAS)......................... 1825 11.25.3.1 Introduction....................................................................................... 1825 11.25.3.2 GAS Protocol .................................................................................... 1826 11.25.3.3 ANQP procedures ............................................................................. 1833 11.25.3.4 Registered location query protocol (RLQP) procedures................... 1838 11.25.4 Interworking procedures: IEEE 802.21 MIH support ......................................... 1838 11.25.5 Interworking procedures: interactions with SSPN............................................... 1839 11.25.5.1 General operation .............................................................................. 1839 11.25.5.2 Authentication and cipher suites selection with SSPN ..................... 1839 11.25.5.3 Reporting and session control with SSPN ........................................ 1840 11.25.6 Interworking procedures: emergency services support ....................................... 1841 11.25.7 Interworking procedures: emergency alert system (EAS) support ...................... 1842 11.25.8 Interworking procedures: support for the advertisement of roaming consortiums.......................................................................................................... 1843 11.25.9 Interworking procedures: support for QoS mapping from external networks..... 1843 11.26 Quality-of-service management frame (QMF) .................................................................... 1844 11.26.1 General................................................................................................................. 1844 11.26.1.1 Overview........................................................................................... 1844 11.26.1.2 Default QMF policy .......................................................................... 1845 11.26.2 QMF policy advertisement and configuration procedures .................................. 1847 11.26.2.1 Overview........................................................................................... 1847 11.26.2.2 QMF policy change in an infrastructure BSS or in an MBSS .......... 1848 11.26.2.3 QMF policy configuration in an infrastructure BSS ......................... 1849 11.26.2.4 QMF policy configuration in an IBSS or OCB................................. 1850 11.26.2.5 QMF policy configuration in an MBSS............................................ 1850 11.26.3 Interpreting QMF access categories .................................................................... 1850 11.27 Robust AV streaming .......................................................................................................... 1851 11.27.1 Robust AV streaming dependencies .................................................................... 1851 11.27.2 SCS procedures.................................................................................................... 1851 11.28 Procedures to manage OBSS ............................................................................................... 1853 52 Copyright Â© 2016 IEEE. All rights reserved. 11.28.1 General ................................................................................................................ 1853 11.28.2 QLoad Report element......................................................................................... 1853 11.28.2.1 Introduction....................................................................................... 1853 11.28.2.2 Calculating field values .................................................................... 1854 11.28.2.3 Requesting QLoad Reports using radio measurement requests........ 1855 11.28.3 HCCA TXOP negotiation ................................................................................... 1856 11.28.4 HCCA AP timing synchronization for HCCA TXOP advertisement.................. 1860 11.28.4.1 General ............................................................................................. 1860 11.28.4.2 Timing offset..................................................................................... 1860 11.28.4.3 Clock drift adjustment ...................................................................... 1860 11.29 DMG beamformed link and BSS maintenance.................................................................... 1861 11.29.1 Beamformed link maintenance ............................................................................ 1861 11.29.2 PCP Handover...................................................................................................... 1863 11.29.2.1 General .............................................................................................. 1863 11.29.2.2 Explicit handover procedure ............................................................. 1864 11.29.2.3 Implicit handover procedure ............................................................. 1865 11.30 DMG BSS peer and service discovery ............................................................................... 1865 11.30.1 Information Request and Response ..................................................................... 1865 11.30.2 Peer Service Discovery ........................................................................................ 1866 11.31 Changing DMG BSS parameters ........................................................................................ 1867 11.31.1 General................................................................................................................. 1867 11.31.2 Moving the TBTT ................................................................................................ 1867 11.31.3 Changing beacon interval duration ...................................................................... 1868 11.31.4 Maintaining synchronization in an AP or PCP cluster ........................................ 1869 11.31.5 Recommending DMG BSS parameters to the AP or PCP................................... 1869 11.32 Spatial sharing and interference mitigation for DMG STAs ............................................... 1870 11.32.1 General................................................................................................................. 1870 11.32.2 Spatial sharing and interference assessment ........................................................ 1870 11.32.3 Achieving spatial sharing and interference mitigation ........................................ 1871 11.32.4 PBSS and infrastructure BSS stability in OBSS scenarios.................................. 1873 11.33 Multi-band operation .......................................................................................................... 1873 11.33.1 General................................................................................................................. 1873 11.33.2 FST setup protocol............................................................................................... 1875 11.33.2.1 General .............................................................................................. 1875 11.33.2.2 Transitioning between states............................................................. 1877 11.33.2.3 FST TS switching.............................................................................. 1882 11.33.3 FST teardown....................................................................................................... 1884 11.33.4 On-channel Tunneling (OCT) operation.............................................................. 1884 11.33.5 FST payload ......................................................................................................... 1886 11.34 MMSL cluster operation ..................................................................................................... 1886 11.34.1 Introduction.......................................................................................................... 1886 11.34.2 MMSL cluster setup............................................................................................. 1887 11.34.2.1 General .............................................................................................. 1887 11.34.2.2 MMSL cluster setup of non-AP and non-PCP MM-SME coordinated STA with AP or PCP..................................................... 1888 11.34.2.3 MMSL cluster setup of non-AP and non-PCP STA with another non-AP and non-PCP STA ............................................................... 1888 11.35 DMG coexistence with non-IEEE-802.11 systems ............................................................. 1888 11.36 DMG relay procedures......................................................................................................... 1889 11.36.1 General................................................................................................................. 1889 11.36.2 Common relay setup procedures.......................................................................... 1890 11.36.2.1 Introduction....................................................................................... 1890 11.36.2.2 Relay capabilities and RDS discovery procedures ........................... 1890 11.36.2.3 RDS selection procedure................................................................... 1890 53 Copyright Â© 2016 IEEE. All rights reserved. 11.36.2.4 RLS procedure .................................................................................. 1891 11.36.3 Relay operation-type change procedure .............................................................. 1891 11.36.4 Relay teardown .................................................................................................... 1892 11.37 Quieting adjacent DMG BSSs ............................................................................................. 1892 11.37.1 General................................................................................................................. 1892 11.37.2 Procedure at the requester AP.............................................................................. 1893 11.37.3 Procedure at the responder AP............................................................................. 1893 11.38 DMG beamforming.............................................................................................................. 1894 11.39 DMG MAC sublayer attributes............................................................................................ 1896 11.40 VHT BSS operation ............................................................................................................. 1896 11.40.1 Basic VHT BSS functionality.............................................................................. 1896 11.40.2 Channel selection methods for a VHT BSS......................................................... 1900 11.40.3 Scanning requirements for VHT STA ................................................................. 1900 11.40.4 Channel switching methods for a VHT BSS ....................................................... 1900 11.40.5 NAV assertion in a VHT BSS ............................................................................. 1903 11.40.6 VHT STA antenna indication .............................................................................. 1903 11.40.7 Basic VHT-MCS and NSS set operation ............................................................. 1903 11.40.8 Extended NSS BW Support Signaling................................................................. 1904 11.41 Group ID management operation ........................................................................................ 1904 11.42 Notification of operating mode changes .............................................................................. 1905 11.43 Basic TVHT BSS functionality ........................................................................................... 1907 11.44 Operation under the control of a GDB................................................................................. 1908 11.44.1 General................................................................................................................. 1908 11.44.2 GDD enabling STA operation ............................................................................. 1909 11.44.3 GDD dependent STA operation........................................................................... 1909 11.44.4 Channel availability query (CAQ) procedure ...................................................... 1911 11.44.4.1 Introduction....................................................................................... 1911 11.44.4.2 CAQ requesting STA ........................................................................ 1912 11.44.4.3 CAQ responding STA....................................................................... 1912 11.44.5 Channel schedule management (CSM) procedures ............................................. 1914 11.44.5.1 Introduction....................................................................................... 1914 11.44.5.2 CSM requesting STA ........................................................................ 1915 11.44.5.3 CSM responding STA....................................................................... 1915 11.44.6 Contact verification signal (CVS)........................................................................ 1916 11.44.7 Network channel control (NCC) procedures ....................................................... 1916 11.44.7.1 Introduction....................................................................................... 1916 11.44.7.2 NCC requesting STA ........................................................................ 1917 11.44.7.3 NCC responding STA ....................................................................... 1918 11.44.8 Reduced neighbor report...................................................................................... 1918 11.44.9 White space map (WSM)..................................................................................... 1919 11.45 Beacon RSSI ........................................................................................................................ 1920 11.46 Estimated throughput ........................................................................................................... 1920 12. Security ............................................................................................................................................ 1923 12.1 Conventions ......................................................................................................................... 1923 12.2 Framework ........................................................................................................................... 1923 12.2.1 Classes of security algorithm ............................................................................... 1923 12.2.2 Security methods.................................................................................................. 1923 12.2.3 RSNA STA capabilities ....................................................................................... 1923 12.2.4 RSNA establishment............................................................................................ 1923 12.2.5 RSNA PeerKey Support ...................................................................................... 1925 12.2.6 RSNA assumptions and constraints..................................................................... 1926 12.2.7 Requirements for the Protected Frame field ........................................................ 1927 54 Copyright Â© 2016 IEEE. All rights reserved. 12.2.8 Requirements for robust management frame protection...................................... 1927 12.2.9 Emergency service establishment in an RSN ...................................................... 1927 12.3 Pre-RSNA security methods ................................................................................................ 1927 12.3.1 Status of Pre-RSNA security methods................................................................. 1927 12.3.2 Wired equivalent privacy (WEP)......................................................................... 1928 12.3.2.1 WEP overview .................................................................................. 1928 12.3.2.2 WEP MPDU format .......................................................................... 1928 12.3.2.3 WEP state.......................................................................................... 1928 12.3.2.4 WEP procedures................................................................................ 1929 12.3.3 Pre-RSNA authentication .................................................................................... 1931 12.3.3.1 Overview........................................................................................... 1931 12.3.3.2 Open System authentication.............................................................. 1931 12.3.3.3 Shared Key authentication ................................................................ 1932 12.4 Authentication using a password ......................................................................................... 1935 12.4.1 SAE overview ...................................................................................................... 1935 12.4.2 Assumptions on SAE ........................................................................................... 1936 12.4.3 Representation of a password .............................................................................. 1936 12.4.4 Finite cyclic groups.............................................................................................. 1936 12.4.4.1 General .............................................................................................. 1936 12.4.4.2 Elliptic curve cryptography (ECC) groups ....................................... 1937 12.4.4.3 Finite field cryptography (FFC) groups ............................................ 1940 12.4.5 SAE protocol........................................................................................................ 1941 12.4.5.1 Message exchanges ........................................................................... 1941 12.4.5.2 PWE and secret generation ............................................................... 1942 12.4.5.3 Construction of an SAE Commit message........................................ 1942 12.4.5.4 Processing of a peerâ€™s SAE Commit message .................................. 1942 12.4.5.5 Construction of an SAE Confirm message ....................................... 1943 12.4.5.6 Processing of a peerâ€™s SAE Confirm message.................................. 1943 12.4.6 Anti-clogging tokens............................................................................................ 1943 12.4.7 Framing of SAE ................................................................................................... 1944 12.4.7.1 General .............................................................................................. 1944 12.4.7.2 Data type conversion......................................................................... 1944 12.4.7.3 Authentication transaction sequence number for SAE ..................... 1945 12.4.7.4 Encoding and decoding of SAE Commit messages.......................... 1945 12.4.7.5 Encoding and decoding of SAE Confirm messages ......................... 1946 12.4.7.6 Status codes....................................................................................... 1946 12.4.8 SAE finite state machine...................................................................................... 1946 12.4.8.1 General .............................................................................................. 1946 12.4.8.2 States ................................................................................................. 1947 12.4.8.3 Events and output.............................................................................. 1948 12.4.8.4 Timers ............................................................................................... 1948 12.4.8.5 Variables ........................................................................................... 1949 12.4.8.6 Behavior of state machine................................................................. 1949 12.5 RSNA confidentiality and integrity protocols ..................................................................... 1953 12.5.1 Overview.............................................................................................................. 1953 12.5.2 Temporal key integrity protocol (TKIP).............................................................. 1953 12.5.2.1 TKIP overview.................................................................................. 1953 12.5.2.2 TKIP MPDU formats ........................................................................ 1956 12.5.2.3 TKIP MIC ......................................................................................... 1957 12.5.2.4 TKIP countermeasures procedures ................................................... 1959 12.5.2.5 TKIP mixing function ....................................................................... 1963 12.5.2.6 TKIP replay protection procedures ................................................... 1967 12.5.3 CTR with CBC-MAC protocol (CCMP) ............................................................. 1967 12.5.3.1 General .............................................................................................. 1967 55 Copyright Â© 2016 IEEE. All rights reserved. 12.5.3.2 CCMP MPDU format ....................................................................... 1968 12.5.3.3 CCMP cryptographic encapsulation ................................................. 1969 12.5.3.4 CCMP decapsulation......................................................................... 1972 12.5.4 Broadcast/multicast integrity protocol (BIP) ....................................................... 1974 12.5.4.1 BIP overview..................................................................................... 1974 12.5.4.2 BIP MMPDU format......................................................................... 1975 12.5.4.3 BIP AAD construction ...................................................................... 1975 12.5.4.4 BIP replay protection ........................................................................ 1975 12.5.4.5 BIP transmission ............................................................................... 1976 12.5.4.6 BIP reception..................................................................................... 1976 12.5.5 GCM protocol (GCMP) ....................................................................................... 1977 12.5.5.1 GCMP overview ............................................................................... 1977 12.5.5.2 GCMP MPDU format ....................................................................... 1978 12.5.5.3 GCMP cryptographic encapsulation ................................................. 1978 12.5.5.4 GCMP decapsulation ........................................................................ 1980 12.6 RSNA security association management ............................................................................. 1982 12.6.1 Security associations............................................................................................ 1982 12.6.1.1 Security association definitions ........................................................ 1982 12.6.1.2 TPKSA .............................................................................................. 1987 12.6.1.3 Security association life cycle........................................................... 1988 12.6.2 RSNA selection.................................................................................................... 1991 12.6.3 RSNA policy selection in an infrastructure BSS ................................................. 1991 12.6.4 TSN policy selection in an infrastructure BSS .................................................... 1992 12.6.5 RSNA policy selection in an IBSS and for DLS ................................................. 1993 12.6.6 TSN policy selection in an IBSS ......................................................................... 1994 12.6.7 RSNA policy selection in an MBSS .................................................................... 1994 12.6.8 RSNA policy selection in a PBSS ....................................................................... 1995 12.6.9 RSN management of the IEEE 802.1X Controlled Port...................................... 1995 12.6.10 RSNA authentication in an infrastructure BSS.................................................... 1996 12.6.10.1 General .............................................................................................. 1996 12.6.10.2 Preauthentication and RSNA key management ................................ 1996 12.6.10.3 Cached PMKSAs and RSNA key management................................ 1997 12.6.11 RSNA authentication in an IBSS......................................................................... 1998 12.6.12 RSNA authentication in an MBSS....................................................................... 1999 12.6.13 RSNA authentication in a PBSS .......................................................................... 1999 12.6.14 RSNA key management in an infrastructure BSS ............................................... 2000 12.6.15 RSNA key management in an IBSS .................................................................... 2000 12.6.16 RSNA key management in an MBSS .................................................................. 2001 12.6.17 RSNA key management in a PBSS ..................................................................... 2001 12.6.18 RSNA security association termination ............................................................... 2001 12.6.19 Protection of robust Management frames ............................................................ 2002 12.6.20 Robust management frame selection procedure .................................................. 2003 12.6.21 RSNA rekeying.................................................................................................... 2004 12.6.22 Multi-band RSNA ............................................................................................... 2004 12.6.22.1 General .............................................................................................. 2004 12.6.22.2 Nontransparent multi-band RSNA ................................................... 2005 12.6.22.3 Transparent multi-band RSNA ........................................................ 2006 12.6.22.4 Multi-band RSNA with TDLS in a non-DMG BSS ......................... 2006 12.7 Keys and key distribution .................................................................................................... 2007 12.7.1 Key hierarchy....................................................................................................... 2007 12.7.1.1 General .............................................................................................. 2007 12.7.1.2 PRF.................................................................................................... 2008 12.7.1.3 Pairwise key hierarchy ...................................................................... 2009 12.7.1.4 Group key hierarchy.......................................................................... 2011 56 Copyright Â© 2016 IEEE. All rights reserved. 12.7.1.5 Integrity group key hierarchy............................................................ 2012 12.7.1.6 PeerKey key hierarchy ...................................................................... 2012 12.7.1.7 FT key hierarchy ............................................................................... 2014 12.7.2 EAPOL-Key frames............................................................................................. 2018 12.7.3 EAPOL-Key frame construction and processing................................................. 2027 12.7.4 EAPOL-Key frame notation ................................................................................ 2028 12.7.5 Nonce generation ................................................................................................. 2028 12.7.6 4-way handshake.................................................................................................. 2029 12.7.6.1 General .............................................................................................. 2029 12.7.6.2 4-way handshake message 1 ............................................................. 2030 12.7.6.3 4-way handshake message 2 ............................................................. 2031 12.7.6.4 4-way handshake message 3 ............................................................. 2033 12.7.6.5 4-way handshake message 4 ............................................................. 2035 12.7.6.6 4-way handshake implementation considerations............................. 2037 12.7.6.7 Sample 4-way handshake.................................................................. 2037 12.7.6.8 4-way handshake analysis................................................................. 2038 12.7.7 Group key handshake........................................................................................... 2040 12.7.7.1 General .............................................................................................. 2040 12.7.7.2 Group key handshake message 1 ...................................................... 2041 12.7.7.3 Group key handshake message 2 ...................................................... 2042 12.7.7.4 Group key handshake implementation considerations...................... 2042 12.7.7.5 Sample group key handshake............................................................ 2042 12.7.8 PeerKey handshake.............................................................................................. 2043 12.7.8.1 General .............................................................................................. 2043 12.7.8.2 SMK handshake ................................................................................ 2044 12.7.8.3 PeerKey setup and handshake error conditions ................................ 2049 12.7.8.4 STKSA rekeying ............................................................................... 2050 12.7.8.5 Error reporting................................................................................... 2051 12.7.9 TDLS PeerKey (TPK) security protocol ............................................................. 2052 12.7.9.1 General .............................................................................................. 2052 12.7.9.2 TPK handshake ................................................................................. 2052 12.7.9.3 TPK handshake security assumptions............................................... 2054 12.7.9.4 TPK Security Protocol handshake messages .................................... 2054 12.7.9.5 Supplicant state machine procedures ................................................ 2058 12.7.9.6 Supplicant PeerKey state machine states .......................................... 2060 12.7.9.7 Supplicant PeerKey state machine variables .................................... 2062 12.7.10 RSNA Supplicant key management state machine.............................................. 2062 12.7.10.1 General .............................................................................................. 2062 12.7.10.2 Supplicant state machine states......................................................... 2063 12.7.10.3 Supplicant state machine variables ................................................... 2063 12.7.11 RSNA Authenticator key management state machine......................................... 2064 12.7.11.1 General .............................................................................................. 2064 12.7.11.2 Authenticator state machine states.................................................... 2068 12.7.11.3 Authenticator state machine variables .............................................. 2069 12.7.11.4 Authenticator state machine procedures ........................................... 2070 12.8 Mapping EAPOL keys to IEEE 802.11 keys....................................................................... 2070 12.8.1 Mapping PTK to TKIP keys ................................................................................ 2070 12.8.2 Mapping GTK to TKIP keys ............................................................................... 2070 12.8.3 Mapping PTK to CCMP keys .............................................................................. 2071 12.8.4 Mapping GTK to CCMP keys ............................................................................. 2071 12.8.5 Mapping GTK to WEP-40 keys........................................................................... 2071 12.8.6 Mapping GTK to WEP-104 keys......................................................................... 2071 12.8.7 Mapping IGTK to BIP keys................................................................................. 2071 12.8.8 Mapping PTK to GCMP keys.............................................................................. 2071 57 Copyright Â© 2016 IEEE. All rights reserved. 12.8.9 Mapping GTK to GCMP keys ............................................................................. 2071 12.9 Per-frame pseudocode.......................................................................................................... 2072 12.9.1 WEP frame pseudocode....................................................................................... 2072 12.9.2 RSNA frame pseudocode..................................................................................... 2073 12.9.2.1 General .............................................................................................. 2073 12.9.2.2 Per-MSDU/Per-A-MSDU Tx pseudocode........................................ 2073 12.9.2.3 Per-MMPDU Tx pseudocode............................................................ 2074 12.9.2.4 Per-MPDU Tx pseudocode ............................................................... 2076 12.9.2.5 Per-MPDU Tx pseudocode for MMPDU ......................................... 2077 12.9.2.6 Per-MPDU Rx pseudocode............................................................... 2077 12.9.2.7 Per-MPDU Rx pseudocode for an MMPDU .................................... 2078 12.9.2.8 Per-MSDU/Per-A-MSDU Rx pseudocode ....................................... 2082 12.9.2.9 Per-MMPDU Rx pseudocode ........................................................... 2083 12.10 Authenticated mesh peering exchange (AMPE).................................................................. 2084 12.11 AP PeerKey support............................................................................................................. 2084 12.11.1 AP PeerKey overview.......................................................................................... 2084 12.11.2 AP PeerKey protocol ........................................................................................... 2085 13. Fast BSS transition........................................................................................................................... 2089 13.1 Overview.............................................................................................................................. 2089 13.2 Key holders .......................................................................................................................... 2089 13.2.1 Introduction.......................................................................................................... 2089 13.2.2 Authenticator key holders .................................................................................... 2090 13.2.3 Supplicant key holders......................................................................................... 2091 13.3 Capability and policy advertisement.................................................................................... 2092 13.4 FT initial mobility domain association ................................................................................ 2092 13.4.1 Overview.............................................................................................................. 2092 13.4.2 FT initial mobility domain association in an RSN .............................................. 2092 13.4.3 FT initial mobility domain association in a non-RSN ......................................... 2095 13.5 FT protocol .......................................................................................................................... 2096 13.5.1 Overview.............................................................................................................. 2096 13.5.2 Over-the-air FT protocol authentication in an RSN ............................................ 2096 13.5.3 Over-the-DS FT protocol in an RSN ................................................................... 2098 13.5.4 Over-the-air FT protocol in a non-RSN............................................................... 2100 13.5.5 Over-the-DS FT protocol in a non-RSN.............................................................. 2101 13.6 FT resource request protocol ............................................................................................... 2102 13.6.1 Overview.............................................................................................................. 2102 13.6.2 Over-the-air fast BSS transition with resource request ....................................... 2102 13.6.3 Over-the-DS fast BSS transition with resource request....................................... 2104 13.7 FT reassociation ................................................................................................................... 2107 13.7.1 FT reassociation in an RSN ................................................................................. 2107 13.7.2 FT reassociation in a non-RSN ............................................................................ 2108 13.8 FT authentication sequence ................................................................................................. 2109 13.8.1 Overview.............................................................................................................. 2109 13.8.2 FT authentication sequence: contents of first message........................................ 2110 13.8.3 FT authentication sequence: contents of second message ................................... 2110 13.8.4 FT authentication sequence: contents of third message....................................... 2111 13.8.5 FT authentication sequence: contents of fourth message .................................... 2112 13.9 FT security architecture state machines............................................................................... 2113 13.9.1 Introduction.......................................................................................................... 2113 13.9.2 R0KH state machine ............................................................................................ 2113 13.9.2.1 General .............................................................................................. 2113 13.9.2.2 R0KH state machine states ............................................................... 2114 58 Copyright Â© 2016 IEEE. All rights reserved. 13.9.2.3 R0KH state machine variables.......................................................... 2115 13.9.2.4 R0KH state machine procedures....................................................... 2115 13.9.3 R1KH state machine ............................................................................................ 2115 13.9.3.1 General .............................................................................................. 2115 13.9.3.2 R1KH state machine states ............................................................... 2117 13.9.3.3 R1KH state machine variables.......................................................... 2118 13.9.3.4 R1KH state machine procedures....................................................... 2119 13.9.4 S0KH state machine............................................................................................. 2119 13.9.4.1 General .............................................................................................. 2119 13.9.4.2 S0KH state machine states................................................................ 2119 13.9.4.3 S0KH state machine variables .......................................................... 2120 13.9.4.4 S0KH state machine procedures ....................................................... 2120 13.9.5 S1KH state machine............................................................................................. 2120 13.9.5.1 General .............................................................................................. 2120 13.9.5.2 S1KH state machine states................................................................ 2120 13.9.5.3 S1KH state machine variables .......................................................... 2123 13.9.5.4 S1KH state machine procedures ....................................................... 2124 13.10 Remote request broker (RRB) communication ................................................................... 2124 13.10.1 Overview.............................................................................................................. 2124 13.10.2 Remote request broker (RRB) ............................................................................. 2124 13.10.3 Remote Request/Response frame definition........................................................ 2125 13.11 Resource request procedures ............................................................................................... 2126 13.11.1 General................................................................................................................. 2126 13.11.2 Resource information container (RIC) ................................................................ 2126 13.11.3 Creation and handling of a resource request........................................................ 2129 13.11.3.1 FTO procedures................................................................................. 2129 13.11.3.2 AP procedures ................................................................................... 2130 14. MLME mesh procedures ................................................................................................................. 2132 14.1 Mesh STA dependencies ..................................................................................................... 2132 14.2 Mesh discovery .................................................................................................................... 2132 14.2.1 General................................................................................................................. 2132 14.2.2 Mesh identifier ..................................................................................................... 2132 14.2.3 Mesh profile ......................................................................................................... 2133 14.2.4 Mesh STA configuration ..................................................................................... 2133 14.2.5 Supplemental information for the mesh discovery .............................................. 2133 14.2.6 Scanning mesh BSSs ........................................................................................... 2134 14.2.7 Candidate peer mesh STA ................................................................................... 2134 14.2.8 Establishing or becoming a member of a mesh BSS ........................................... 2135 14.2.9 Establishing mesh peerings.................................................................................. 2135 14.3 Mesh peering management (MPM) ..................................................................................... 2136 14.3.1 General................................................................................................................. 2136 14.3.2 State variable management .................................................................................. 2137 14.3.3 Mesh authentication ............................................................................................. 2137 14.3.4 Mesh peering instance controller ......................................................................... 2138 14.3.4.1 Overview........................................................................................... 2138 14.3.4.2 Creating a new mesh peering instance.............................................. 2138 14.3.4.3 Deleting mesh peering instances....................................................... 2139 14.3.5 Mesh peering instance selection .......................................................................... 2139 14.3.6 Mesh peering open............................................................................................... 2140 14.3.6.1 Generating Mesh Peering Open frames ............................................ 2140 14.3.6.2 Mesh Peering Open frame processing .............................................. 2140 14.3.7 Mesh peering confirm .......................................................................................... 2140 59 Copyright Â© 2016 IEEE. All rights reserved. 14.3.7.1 Generating Mesh Peering Confirm frames ....................................... 2140 14.3.7.2 Mesh Peering Confirm frame processing.......................................... 2141 14.3.8 Mesh peering close .............................................................................................. 2141 14.3.8.1 Generating Mesh Peering Close frames............................................ 2141 14.3.8.2 Mesh Peering Close frame processing .............................................. 2141 14.4 Mesh peering management finite state machine (MPM FSM)............................................ 2141 14.4.1 General................................................................................................................. 2141 14.4.2 States .................................................................................................................... 2141 14.4.3 Events and actions ............................................................................................... 2142 14.4.4 Timers .................................................................................................................. 2143 14.4.5 State transitions.................................................................................................... 2144 14.4.6 IDLE state ............................................................................................................ 2145 14.4.7 OPN_SNT state.................................................................................................... 2146 14.4.8 CNF_RCVD state ................................................................................................ 2146 14.4.9 OPN_RCVD state ................................................................................................ 2147 14.4.10 ESTAB state ........................................................................................................ 2148 14.4.11 HOLDING state ................................................................................................... 2148 14.5 Authenticated mesh peering exchange (AMPE).................................................................. 2148 14.5.1 Overview.............................................................................................................. 2148 14.5.2 Security capabilities selection.............................................................................. 2149 14.5.2.1 Instance Pairwise Cipher Suite selection .......................................... 2149 14.5.2.2 Group cipher suite selection.............................................................. 2150 14.5.3 Construction and processing AES-SIV-protected mesh peering Management frames................................................................................................................... 2150 14.5.4 Distribution of group transient keys in an MBSS................................................ 2151 14.5.5 Mesh peering Management frames for AMPE .................................................... 2151 14.5.5.1 General .............................................................................................. 2151 14.5.5.2 Mesh peering open for AMPE .......................................................... 2151 14.5.5.3 Mesh peering confirm for AMPE ..................................................... 2152 14.5.5.4 Mesh peering close for AMPE.......................................................... 2153 14.5.6 AMPE finite state machine .................................................................................. 2153 14.5.6.1 Overview........................................................................................... 2153 14.5.6.2 Additional events and actions to MPM FSM.................................... 2154 14.5.6.3 State transitions ................................................................................. 2154 14.5.7 Keys and key derivation algorithm for the authenticated mesh peering exchange (AMPE)................................................................................................ 2156 14.6 Mesh group key handshake.................................................................................................. 2157 14.6.1 General................................................................................................................. 2157 14.6.2 Protection on mesh group key handshake frames................................................ 2158 14.6.3 Mesh Group Key Inform frame construction and processing.............................. 2158 14.6.4 Mesh Group Key Acknowledge frame construction and processing .................. 2159 14.6.5 Mesh group key implementation considerations ................................................. 2160 14.7 Mesh security ....................................................................................................................... 2160 14.8 Mesh path selection and metric framework ......................................................................... 2161 14.8.1 General................................................................................................................. 2161 14.8.2 Extensible path selection framework ................................................................... 2161 14.8.3 Link metric reporting ........................................................................................... 2161 14.9 Airtime link metric............................................................................................................... 2162 14.10 Hybrid wireless mesh protocol (HWMP) ............................................................................ 2163 14.10.1 General................................................................................................................. 2163 14.10.2 Terminology......................................................................................................... 2164 14.10.3 On-demand path selection mode.......................................................................... 2166 14.10.4 Proactive tree building mode ............................................................................... 2166 14.10.4.1 General .............................................................................................. 2166 60 Copyright Â© 2016 IEEE. All rights reserved. 14.10.4.2 Proactive PREQ mechanism ............................................................. 2167 14.10.4.3 Proactive RANN mechanism ............................................................ 2167 14.10.5 Collocated STAs .................................................................................................. 2168 14.10.6 Parameters for extensible path selection framework ........................................... 2168 14.10.7 Addressing of HWMP Mesh Path Selection frame ............................................. 2168 14.10.8 General rules for processing HWMP elements.................................................... 2170 14.10.8.1 General .............................................................................................. 2170 14.10.8.2 HWMP propagation .......................................................................... 2170 14.10.8.3 HWMP sequence numbering ............................................................ 2170 14.10.8.4 Forwarding information .................................................................... 2171 14.10.8.5 Repeated attempts at path discovery................................................. 2172 14.10.8.6 Limiting the rate of HWMP SN increments ..................................... 2173 14.10.9 Path request (PREQ) mechanism......................................................................... 2173 14.10.9.1 General .............................................................................................. 2173 14.10.9.2 Function ............................................................................................ 2173 14.10.9.3 Conditions for generating and sending a PREQ element.................. 2173 14.10.9.4 PREQ element processing................................................................. 2182 14.10.10 Path reply (PREP) mechanism............................................................................. 2183 14.10.10.1 General .............................................................................................. 2183 14.10.10.2 Function ............................................................................................ 2183 14.10.10.3 Conditions for generating and sending a PREP element .................. 2183 14.10.10.4 PREP element processing ................................................................. 2186 14.10.11 Path error (PERR) mechanism............................................................................. 2187 14.10.11.1 General .............................................................................................. 2187 14.10.11.2 Function ............................................................................................ 2187 14.10.11.3 Conditions for generating and sending a PERR element.................. 2188 14.10.11.4 PERR element processing................................................................. 2192 14.10.12 Root announcement (RANN) mechanism ........................................................... 2192 14.10.12.1 General .............................................................................................. 2192 14.10.12.2 Function ............................................................................................ 2193 14.10.12.3 Conditions for generating and sending a RANN element................. 2193 14.10.12.4 RANN element reception.................................................................. 2194 14.10.13 Considerations for support of STAs without mesh functionality ........................ 2195 14.11 Interworking with the DS .................................................................................................... 2195 14.11.1 Overview of interworking between a mesh BSS and a DS ................................. 2195 14.11.2 Gate announcement (GANN) .............................................................................. 2196 14.11.2.1 General .............................................................................................. 2196 14.11.2.2 Function ............................................................................................ 2196 14.11.2.3 Conditions for generating and sending a GANN element ................ 2196 14.11.2.4 GANN element processing ............................................................... 2198 14.11.3 Data forwarding at proxy mesh gates .................................................................. 2198 14.11.3.1 General .............................................................................................. 2198 14.11.3.2 Forwarding of MSDUs from the MBSS to the DS ........................... 2198 14.11.3.3 Forwarding of MSDUs from the DS to the MBSS ........................... 2199 14.11.4 Proxy information and proxy update ................................................................... 2200 14.11.4.1 General .............................................................................................. 2200 14.11.4.2 Proxy information ............................................................................. 2200 14.11.4.3 Proxy update (PXU).......................................................................... 2201 14.11.4.4 Proxy update confirmation (PXUC) ................................................. 2203 14.11.5 Mesh STA collocation ......................................................................................... 2204 14.12 Intra-mesh congestion control ............................................................................................. 2204 14.12.1 General................................................................................................................. 2204 14.12.2 Congestion control signaling protocol ................................................................. 2204 14.13 Synchronization and beaconing in MBSSs.......................................................................... 2205 61 Copyright Â© 2016 IEEE. All rights reserved. 14.13.1 TSF for MBSSs.................................................................................................... 2205 14.13.2 Extensible synchronization framework ............................................................... 2205 14.13.2.1 General .............................................................................................. 2205 14.13.2.2 Neighbor offset synchronization method.......................................... 2205 14.13.3 Beaconing ............................................................................................................ 2208 14.13.3.1 Beacon generation in MBSSs ........................................................... 2208 14.13.3.2 Beacon reception for mesh STA ....................................................... 2208 14.13.4 Mesh beacon collision avoidance (MBCA)......................................................... 2208 14.13.4.1 Overview........................................................................................... 2208 14.13.4.2 Beacon timing advertisement............................................................ 2209 14.13.4.3 TBTT selection ................................................................................. 2212 14.13.4.4 TBTT adjustment .............................................................................. 2212 14.13.4.5 Frame transmission across reported TBTT ....................................... 2214 14.13.4.6 Delayed beacon transmissions .......................................................... 2214 14.14 Power save in a mesh BSS................................................................................................... 2214 14.14.1 General................................................................................................................. 2214 14.14.2 Mesh power management modes......................................................................... 2215 14.14.2.1 General .............................................................................................. 2215 14.14.2.2 Peer-specific mesh power management modes ................................ 2215 14.14.2.3 Nonpeer mesh power management modes........................................ 2216 14.14.3 Mesh power management mode indications and transitions ............................... 2216 14.14.3.1 General .............................................................................................. 2216 14.14.3.2 Transition to a higher activity level .................................................. 2217 14.14.3.3 Transition to a lower activity level ................................................... 2217 14.14.4 TIM transmissions in an MBSS........................................................................... 2217 14.14.5 TIM types............................................................................................................. 2218 14.14.6 Mesh awake window ........................................................................................... 2218 14.14.7 Power save support .............................................................................................. 2218 14.14.8 Operation in peer-specific and nonpeer mesh power management modes.......... 2219 14.14.8.1 General .............................................................................................. 2219 14.14.8.2 Operation in active mode .................................................................. 2219 14.14.8.3 Operation in deep sleep mode for nonpeer mesh STAs.................... 2219 14.14.8.4 Operation in light sleep mode for a mesh peering ............................ 2220 14.14.8.5 Operation in deep sleep mode for a mesh peering ............................ 2220 14.14.8.6 Conditions for doze state................................................................... 2220 14.14.9 Mesh peer service periods.................................................................................... 2221 14.14.9.1 General .............................................................................................. 2221 14.14.9.2 Initiation of a mesh peer service period ............................................ 2221 14.14.9.3 Operation during a mesh peer service period.................................... 2222 14.14.9.4 Termination of a mesh peer service period ....................................... 2222 14.14.10 MCCA use by power saving mesh STA .............................................................. 2223 15. DSSS PHY specification for the 2.4 GHz band designated for ISM applications .......................... 2224 15.1 Overview.............................................................................................................................. 2224 15.1.1 General................................................................................................................. 2224 15.1.2 Scope.................................................................................................................... 2224 15.1.3 DSSS PHY functions ........................................................................................... 2224 15.1.3.1 General .............................................................................................. 2224 15.1.3.2 PLME ................................................................................................ 2224 15.1.4 Service specification method and notation .......................................................... 2224 15.2 DSSS PHY specific service parameter list ......................................................................... 2225 15.2.1 Introduction.......................................................................................................... 2225 15.2.2 TXVECTOR parameters...................................................................................... 2225 62 Copyright Â© 2016 IEEE. All rights reserved. 15.2.2.1 General .............................................................................................. 2225 15.2.2.2 TXVECTOR LENGTH .................................................................... 2225 15.2.2.3 TXVECTOR DATARATE............................................................... 2225 15.2.2.4 TXVECTOR SERVICE.................................................................... 2225 15.2.2.5 TXVECTOR TXPWR_LEVEL_INDEX ......................................... 2226 15.2.2.6 TXVECTOR TIME_OF_DEPARTURE_REQUESTED................. 2226 15.2.2.7 TXVECTOR TX_ANTENNA.......................................................... 2226 15.2.3 RXVECTOR parameters ..................................................................................... 2226 15.2.3.1 General .............................................................................................. 2226 15.2.3.2 RXVECTOR LENGTH .................................................................... 2226 15.2.3.3 RXVECTOR RSSI............................................................................ 2227 15.2.3.4 RXVECTOR SIGNAL ..................................................................... 2227 15.2.3.5 RXVECTOR SERVICE ................................................................... 2227 15.2.3.6 RXVECTOR RCPI ........................................................................... 2227 15.2.3.7 RXVECTOR SQ ............................................................................... 2227 15.2.3.8 RXVECTOR RX_ANTENNA ......................................................... 2227 15.2.4 TXSTATUS parameters ...................................................................................... 2227 15.2.4.1 General .............................................................................................. 2227 15.2.4.2 TXSTATUS TIME_OF_DEPARTURE........................................... 2227 15.2.4.3 TXSTATUS TIME_OF_DEPARTURE_ClockRate........................ 2227 15.3 DSSS PHY ........................................................................................................................... 2228 15.3.1 Overview.............................................................................................................. 2228 15.3.2 PPDU format........................................................................................................ 2228 15.3.3 PHY field definitions ........................................................................................... 2229 15.3.3.1 General .............................................................................................. 2229 15.3.3.2 PHY SYNC field............................................................................... 2229 15.3.3.3 PHY SFD .......................................................................................... 2229 15.3.3.4 PHY SIGNAL field........................................................................... 2229 15.3.3.5 PHY SERVICE field......................................................................... 2229 15.3.3.6 PHY LENGTH field ......................................................................... 2229 15.3.3.7 PHY CRC field ................................................................................. 2230 15.3.4 PHY/DSSS PHY data scrambler and descrambler .............................................. 2231 15.3.5 PHY data modulation and modulation rate change ............................................. 2232 15.3.6 Transmit PHY ...................................................................................................... 2232 15.3.7 Receive PHY ....................................................................................................... 2234 15.4 DSSS PLME ........................................................................................................................ 2235 15.4.1 PLME SAP sublayer management primitives ..................................................... 2235 15.4.2 DSSS PHY MIB .................................................................................................. 2235 15.4.3 DSSS PHY ........................................................................................................... 2235 15.4.4 PHY operating specifications, general................................................................. 2235 15.4.4.1 General .............................................................................................. 2235 15.4.4.2 Operating frequency range................................................................ 2235 15.4.4.3 Channel Numbering of operating channels....................................... 2236 15.4.4.4 Spreading sequence........................................................................... 2239 15.4.4.5 Modulation and channel data rates.................................................... 2239 15.4.4.6 Transmit and receive in-band and out-of-band spurious emissions.. 2240 15.4.4.7 TX-to-RX turnaround time ............................................................... 2240 15.4.4.8 RX-to-TX turnaround time ............................................................... 2240 15.4.4.9 Slot time ............................................................................................ 2240 15.4.4.10 Transmit and receive antenna connector impedance ........................ 2240 15.4.5 PHY transmit specifications ................................................................................ 2240 15.4.5.1 Introduction....................................................................................... 2240 15.4.5.2 Transmit power levels....................................................................... 2240 15.4.5.3 Minimum transmitted power level.................................................... 2241 63 Copyright Â© 2016 IEEE. All rights reserved. 15.4.5.4 Transmit power level control ............................................................ 2241 15.4.5.5 Transmit spectrum mask ................................................................... 2241 15.4.5.6 Transmit center frequency tolerance................................................. 2241 15.4.5.7 Chip clock frequency tolerance......................................................... 2241 15.4.5.8 Transmit power-on and power-down ramp....................................... 2241 15.4.5.9 RF carrier suppression ...................................................................... 2242 15.4.5.10 Transmit modulation accuracy.......................................................... 2243 15.4.5.11 Time of Departure accuracy.............................................................. 2245 15.4.6 PHY receiver specifications................................................................................. 2245 15.4.6.1 Introduction....................................................................................... 2245 15.4.6.2 Receiver minimum input level sensitivity ........................................ 2245 15.4.6.3 Receiver maximum input level ......................................................... 2245 15.4.6.4 Receiver adjacent channel rejection.................................................. 2246 15.4.6.5 CCA .................................................................................................. 2246 15.4.6.6 Received Channel Power Indicator Measurement ............................ 2247 15.4.6.7 DSSS PHY TXTIME calculation ..................................................... 2247 16. High rate direct sequence spread spectrum (HR/DSSS) PHY specification ................................... 2248 16.1 Overview.............................................................................................................................. 2248 16.1.1 General................................................................................................................. 2248 16.1.2 Scope.................................................................................................................... 2248 16.1.3 HR/DSSS PHY functions .................................................................................... 2248 16.1.3.1 General .............................................................................................. 2248 16.1.3.2 PLME ................................................................................................ 2249 16.1.4 Service specification method and notation .......................................................... 2249 16.2 HR/DSSS PHY .................................................................................................................... 2249 16.2.1 Overview.............................................................................................................. 2249 16.2.2 PPDU format........................................................................................................ 2249 16.2.2.1 General .............................................................................................. 2249 16.2.2.2 Long PPDU format ........................................................................... 2249 16.2.2.3 Short PPDU format ........................................................................... 2250 16.2.3 PPDU field definitions......................................................................................... 2251 16.2.3.1 General .............................................................................................. 2251 16.2.3.2 Long PHY SYNC field ..................................................................... 2251 16.2.3.3 Long PHY SFD................................................................................. 2251 16.2.3.4 Long PHY SIGNAL field ................................................................. 2251 16.2.3.5 Long PHY SERVICE field ............................................................... 2251 16.2.3.6 Long PHY LENGTH field................................................................ 2252 16.2.3.7 PHY CRC (CRC-16) field ................................................................ 2253 16.2.3.8 Long PHY data modulation and modulation rate change ................. 2255 16.2.3.9 Short PHY synchronization (shortSYNC) ........................................ 2255 16.2.3.10 Short PHY SFD field (shortSFD) ..................................................... 2255 16.2.3.11 Short PHY SIGNAL field (shortSIGNAL)....................................... 2256 16.2.3.12 Short PHY SERVICE field (shortSERVICE)................................... 2256 16.2.3.13 Short PHY LENGTH field (shortLENGTH) .................................... 2256 16.2.3.14 Short CRC-16 field (shortCRC)........................................................ 2256 16.2.3.15 Short PHY data modulation and modulation rate change................. 2256 16.2.4 PHY/HR/DSSS PHY data scrambler and descrambler ....................................... 2256 16.2.5 Transmit PHY ...................................................................................................... 2257 16.2.6 Receive PHY........................................................................................................ 2258 16.3 HR/DSSS PLME.................................................................................................................. 2261 16.3.1 PLME SAP sublayer management primitives ..................................................... 2261 16.3.2 HR/DSSS PHY MIB............................................................................................ 2261 64 Copyright Â© 2016 IEEE. All rights reserved. 16.3.3 HR/DSSS PHY .................................................................................................... 2263 16.3.4 HR/DSSS TXTIME calculation........................................................................... 2263 16.3.5 Vector descriptions .............................................................................................. 2264 16.3.6 PHY operating specifications, general................................................................. 2265 16.3.6.1 General .............................................................................................. 2265 16.3.6.2 Operating frequency range................................................................ 2265 16.3.6.3 Channel Numbering of operating channels....................................... 2265 16.3.6.4 Modulation and channel data rates.................................................... 2266 16.3.6.5 Spreading sequence and modulation for 1 Mb/s and 2 Mb/s ............ 2266 16.3.6.6 Spreading sequences and modulation for CCK modulation at 5.5 Mb/s and 11 Mb/s.................................................................... 2267 16.3.6.7 Transmit and receive in-band and out-of-band spurious emissions.. 2269 16.3.6.8 TX-to-RX turnaround time ............................................................... 2269 16.3.6.9 RX-to-TX turnaround time ............................................................... 2269 16.3.6.10 Slot time ............................................................................................ 2269 16.3.6.11 Transmit and receive impedance at the antenna connector............... 2269 16.3.7 PHY transmit specifications ................................................................................ 2269 16.3.7.1 Introduction....................................................................................... 2269 16.3.7.2 Transmit power levels....................................................................... 2269 16.3.7.3 Transmit power level control ............................................................ 2270 16.3.7.4 Transmit spectrum mask ................................................................... 2270 16.3.7.5 Transmit center frequency tolerance................................................. 2270 16.3.7.6 Chip clock frequency tolerance......................................................... 2270 16.3.7.7 Transmit power-on and power-down ramp....................................... 2271 16.3.7.8 RF carrier suppression ...................................................................... 2271 16.3.7.9 Transmit modulation accuracy.......................................................... 2272 16.3.7.10 Time of Departure accuracy.............................................................. 2274 16.3.8 PHY receiver specifications................................................................................. 2274 16.3.8.1 Introduction....................................................................................... 2274 16.3.8.2 Receiver minimum input level sensitivity ........................................ 2274 16.3.8.3 Receiver maximum input level ......................................................... 2275 16.3.8.4 Receiver adjacent channel rejection.................................................. 2275 16.3.8.5 CCA .................................................................................................. 2275 16.3.8.6 Received Channel Power Indicator Measurement ............................ 2276 17. Orthogonal frequency division multiplexing (OFDM) PHY specification ..................................... 2277 17.1 Introduction.......................................................................................................................... 2277 17.1.1 General................................................................................................................. 2277 17.1.2 Scope.................................................................................................................... 2277 17.1.3 OFDM PHY functions ......................................................................................... 2277 17.1.3.1 General .............................................................................................. 2277 17.1.3.2 PLME ................................................................................................ 2277 17.1.3.3 Service specification method ............................................................ 2278 17.2 OFDM PHY specific service parameter list ........................................................................ 2278 17.2.1 Introduction.......................................................................................................... 2278 17.2.2 TXVECTOR parameters...................................................................................... 2278 17.2.2.1 General .............................................................................................. 2278 17.2.2.2 TXVECTOR LENGTH .................................................................... 2279 17.2.2.3 TXVECTOR DATARATE............................................................... 2279 17.2.2.4 TXVECTOR SERVICE.................................................................... 2279 17.2.2.5 TXVECTOR TXPWR_LEVEL_INDEX ......................................... 2279 17.2.2.6 TXVECTOR TIME_OF_DEPARTURE_REQUESTED................. 2279 17.2.2.7 TXVECTOR CH_BANDWIDTH_IN_NON_HT ............................ 2279 65 Copyright Â© 2016 IEEE. All rights reserved. 17.2.2.8 TXVECTOR DYN_BANDWIDTH_IN_NON_HT......................... 2280 17.2.3 RXVECTOR parameters ..................................................................................... 2280 17.2.3.1 General .............................................................................................. 2280 17.2.3.2 RXVECTOR LENGTH .................................................................... 2281 17.2.3.3 RXVECTOR RSSI............................................................................ 2281 17.2.3.4 RXVECTOR DATARATE............................................................... 2281 17.2.3.5 RXVECTOR SERVICE ................................................................... 2281 17.2.3.6 RXVECTOR RCPI ........................................................................... 2281 17.2.3.7 RXVECTOR CH_BANDWIDTH_IN_NON_HT............................ 2281 17.2.3.8 RXVECTOR DYN_BANDWIDTH_IN_NON_HT......................... 2282 17.2.4 TXSTATUS parameters ...................................................................................... 2282 17.2.4.1 General .............................................................................................. 2282 17.2.4.2 TXSTATUS TIME_OF_DEPARTURE........................................... 2282 17.2.4.3 TXSTATUS TIME_OF_DEPARTURE_ClockRate........................ 2282 17.3 OFDM PHY ......................................................................................................................... 2283 17.3.1 Introduction.......................................................................................................... 2283 17.3.2 PPDU format........................................................................................................ 2283 17.3.2.1 General .............................................................................................. 2283 17.3.2.2 Overview of the PPDU encoding process......................................... 2283 17.3.2.3 Modulation-dependent parameters.................................................... 2285 17.3.2.4 Timing-related parameters ................................................................ 2285 17.3.2.5 Mathematical conventions in the signal descriptions ....................... 2286 17.3.2.6 Discrete time implementation considerations ................................... 2288 17.3.3 PHY preamble (SYNC) ....................................................................................... 2288 17.3.4 SIGNAL field ...................................................................................................... 2290 17.3.4.1 General .............................................................................................. 2290 17.3.4.2 RATE field........................................................................................ 2290 17.3.4.3 PHY LENGTH field ......................................................................... 2291 17.3.4.4 Parity (P), Reserved (R), and SIGNAL TAIL fields......................... 2291 17.3.5 DATA field .......................................................................................................... 2291 17.3.5.1 General .............................................................................................. 2291 17.3.5.2 SERVICE field.................................................................................. 2291 17.3.5.3 PPDU TAIL field .............................................................................. 2292 17.3.5.4 Pad bits (PAD) .................................................................................. 2292 17.3.5.5 PHY DATA scrambler and descrambler .......................................... 2292 17.3.5.6 Convolutional encoder ...................................................................... 2295 17.3.5.7 Data interleaving ............................................................................... 2297 17.3.5.8 Subcarrier modulation mapping........................................................ 2298 17.3.5.9 Pilot subcarriers................................................................................. 2301 17.3.5.10 OFDM modulation............................................................................ 2301 17.3.6 CCA ..................................................................................................................... 2302 17.3.7 PHY data modulation and modulation rate change ............................................. 2302 17.3.8 PHY operating specifications (general) ............................................................... 2303 17.3.8.1 General .............................................................................................. 2303 17.3.8.2 Outline description............................................................................ 2303 17.3.8.3 Regulatory requirements ................................................................... 2304 17.3.8.4 Operating channel frequencies.......................................................... 2304 17.3.8.5 Transmit and receive in-band and out-of-band spurious emissions.. 2305 17.3.8.6 Slot time ............................................................................................ 2305 17.3.8.7 Transmit and receive impedance at the antenna connector............... 2305 17.3.9 PHY transmit specifications ................................................................................ 2305 17.3.9.1 General .............................................................................................. 2305 17.3.9.2 Transmit power levels....................................................................... 2305 17.3.9.3 Transmit spectrum mask ................................................................... 2305 66 Copyright Â© 2016 IEEE. All rights reserved. 17.3.9.4 Transmission spurious....................................................................... 2307 17.3.9.5 Transmit center frequency tolerance................................................. 2307 17.3.9.6 Symbol clock frequency tolerance.................................................... 2307 17.3.9.7 Modulation accuracy......................................................................... 2307 17.3.9.8 Transmit modulation accuracy test ................................................... 2308 17.3.9.9 Time of Departure accuracy.............................................................. 2309 17.3.10 PHY receiver specifications................................................................................. 2310 17.3.10.1 Introduction....................................................................................... 2310 17.3.10.2 Receiver minimum input sensitivity ................................................. 2310 17.3.10.3 Adjacent channel rejection................................................................ 2311 17.3.10.4 Nonadjacent channel rejection .......................................................... 2311 17.3.10.5 Receiver maximum input level ......................................................... 2312 17.3.10.6 CCA requirements............................................................................. 2312 17.3.10.7 Received Channel Power Indicator Measurement ............................ 2312 17.3.11 Transmit PHY ...................................................................................................... 2313 17.3.12 Receive PHY........................................................................................................ 2315 17.4 OFDM PLME ...................................................................................................................... 2317 17.4.1 PLME SAP sublayer management primitives ..................................................... 2317 17.4.2 OFDM PHY MIB ................................................................................................ 2317 17.4.3 OFDM TXTIME calculation ............................................................................... 2320 17.4.4 OFDM PHY characteristics ................................................................................. 2320 18. Extended Rate PHY (ERP) specification......................................................................................... 2322 18.1 Overview.............................................................................................................................. 2322 18.1.1 General................................................................................................................. 2322 18.1.2 Introduction.......................................................................................................... 2322 18.1.3 Operational modes ............................................................................................... 2322 18.1.4 Scope.................................................................................................................... 2323 18.1.5 ERP functions ...................................................................................................... 2323 18.2 PHY-specific service parameter list .................................................................................... 2323 18.3 Extended Rate PHY sublayer .............................................................................................. 2325 18.3.1 Introduction.......................................................................................................... 2325 18.3.2 PPDU format........................................................................................................ 2325 18.3.2.1 General .............................................................................................. 2325 18.3.2.2 Long preamble PPDU format ........................................................... 2326 18.3.2.3 Short preamble PPDU format ........................................................... 2326 18.3.2.4 ERP-OFDM PPDU format................................................................ 2326 18.3.3 PHY data modulation and rate change ................................................................ 2326 18.3.3.1 Long and short preamble formats ..................................................... 2326 18.3.3.2 ERP-OFDM format........................................................................... 2327 18.3.4 CCA ..................................................................................................................... 2327 18.3.5 PHY receive procedure ........................................................................................ 2327 18.4 ERP operating specifications (general)................................................................................ 2327 18.4.1 Introduction.......................................................................................................... 2327 18.4.2 Regulatory requirements...................................................................................... 2327 18.4.3 Operating channel frequencies............................................................................. 2328 18.4.4 Transmit and receive in-band and out-of-band spurious emissions .................... 2328 18.4.5 SIFS ..................................................................................................................... 2328 18.4.6 CCA performance ................................................................................................ 2328 18.4.7 PHY transmit specifications ................................................................................ 2328 18.4.7.1 General .............................................................................................. 2328 18.4.7.2 Transmit power levels....................................................................... 2328 18.4.7.3 Transmit spectral mask ..................................................................... 2328 67 Copyright Â© 2016 IEEE. All rights reserved. 18.4.7.4 Transmit center frequency tolerance................................................. 2329 18.4.7.5 Symbol clock frequency tolerance.................................................... 2329 18.4.7.6 Time of Departure accuracy.............................................................. 2329 18.4.8 PHY receive specifications .................................................................................. 2329 18.4.8.1 General .............................................................................................. 2329 18.4.8.2 Receiver minimum input level sensitivity ........................................ 2329 18.4.8.3 Adjacent channel rejection................................................................ 2329 18.4.8.4 Receive maximum input level capability.......................................... 2329 18.5 ERP PLME .......................................................................................................................... 2330 18.5.1 PLME SAP .......................................................................................................... 2330 18.5.2 MIB ...................................................................................................................... 2330 18.5.3 TXTIME .............................................................................................................. 2331 18.5.3.1 General .............................................................................................. 2331 18.5.3.2 ERP-OFDM TXTIME calculations .................................................. 2331 18.5.4 ERP characteristics .............................................................................................. 2332 19. High-throughput (HT) PHY specification ....................................................................................... 2334 19.1 Introduction.......................................................................................................................... 2334 19.1.1 Introduction to the HT PHY ................................................................................ 2334 19.1.2 Scope.................................................................................................................... 2334 19.1.3 HT PHY functions ............................................................................................... 2334 19.1.3.1 General .............................................................................................. 2334 19.1.3.2 PHY management entity (PLME)..................................................... 2334 19.1.3.3 Service specification method ............................................................ 2335 19.1.4 PPDU formats ...................................................................................................... 2335 19.2 HT PHY service interface.................................................................................................... 2335 19.2.1 Introduction.......................................................................................................... 2335 19.2.2 TXVECTOR and RXVECTOR parameters ........................................................ 2335 19.2.3 PHYCONFIG_VECTOR parameters .................................................................. 2342 19.2.4 Effect of CH_BANDWIDTH, CH_OFFSET, and MCS parameters on PPDU format........................................................................................................ 2343 19.2.5 Support for NON_HT formats ............................................................................. 2344 19.2.6 TXSTATUS parameters ...................................................................................... 2346 19.3 HT PHY ............................................................................................................................... 2346 19.3.1 Introduction.......................................................................................................... 2346 19.3.2 PPDU format........................................................................................................ 2346 19.3.3 Transmitter block diagram................................................................................... 2348 19.3.4 Overview of the PPDU encoding process............................................................ 2349 19.3.5 Modulation and coding scheme (MCS) ............................................................... 2353 19.3.6 Timing-related parameters ................................................................................... 2354 19.3.7 Mathematical description of signals .................................................................... 2356 19.3.8 Transmission in the upper/lower 20 MHz of a 40 MHz channel......................... 2358 19.3.9 HT preamble ........................................................................................................ 2359 19.3.9.1 Introduction....................................................................................... 2359 19.3.9.2 HT-mixed format preamble .............................................................. 2359 19.3.9.3 Non-HT portion of the HT-mixed format preamble ......................... 2359 19.3.9.4 HT portion of HT-mixed format preamble ....................................... 2363 19.3.9.5 HT-greenfield format preamble ........................................................ 2373 19.3.10 Transmission of NON_HT format PPDUs with more than one transmit chain .. 2375 19.3.11 Data field.............................................................................................................. 2375 19.3.11.1 General .............................................................................................. 2375 19.3.11.2 SERVICE field.................................................................................. 2376 19.3.11.3 Scrambler .......................................................................................... 2376 68 Copyright Â© 2016 IEEE. All rights reserved. 19.3.11.4 Coding............................................................................................... 2376 19.3.11.5 Encoder parsing operation for two BCC FEC encoders ................... 2376 19.3.11.6 Binary convolutional coding and puncturing.................................... 2377 19.3.11.7 LDPC codes ...................................................................................... 2377 19.3.11.8 Data interleaver ................................................................................. 2382 19.3.11.9 Constellation mapping ...................................................................... 2384 19.3.11.10 Pilot subcarriers................................................................................. 2385 19.3.11.11 OFDM modulation............................................................................ 2387 19.3.11.12 Non-HT duplicate transmission ........................................................ 2392 19.3.12 Beamforming ....................................................................................................... 2392 19.3.12.1 General .............................................................................................. 2392 19.3.12.2 Implicit feedback beamforming ........................................................ 2393 19.3.12.3 Explicit feedback beamforming ........................................................ 2396 19.3.13 HT Preamble format for sounding PPDUs .......................................................... 2400 19.3.13.1 General .............................................................................................. 2400 19.3.13.2 Sounding with a NDP ....................................................................... 2401 19.3.13.3 Sounding PPDU for calibration ........................................................ 2401 19.3.13.4 Sounding PPDU for channel quality assessment .............................. 2402 19.3.14 Regulatory requirements...................................................................................... 2403 19.3.15 Channel numbering and channelization............................................................... 2403 19.3.15.1 General .............................................................................................. 2403 19.3.15.2 Channel allocation in the 2.4 GHz Band........................................... 2403 19.3.15.3 Channel allocation in the 5 GHz band .............................................. 2403 19.3.15.4 40 MHz channelization ..................................................................... 2403 19.3.16 Slot time............................................................................................................... 2404 19.3.17 Transmit and receive impedance at the antenna connector ................................. 2404 19.3.18 PHY transmit specification .................................................................................. 2404 19.3.18.1 Transmit spectrum mask ................................................................... 2404 19.3.18.2 Spectral flatness ................................................................................ 2406 19.3.18.3 Transmit power ................................................................................. 2406 19.3.18.4 Transmit center frequency tolerance................................................. 2407 19.3.18.5 Packet alignment ............................................................................... 2407 19.3.18.6 Symbol clock frequency tolerance.................................................... 2407 19.3.18.7 Modulation accuracy......................................................................... 2407 19.3.18.8 Time of Departure accuracy.............................................................. 2409 19.3.19 HT PHY receiver specification............................................................................ 2410 19.3.19.1 Receiver minimum input sensitivity ................................................. 2410 19.3.19.2 Adjacent channel rejection................................................................ 2410 19.3.19.3 Nonadjacent channel rejection .......................................................... 2411 19.3.19.4 Receiver maximum input level ......................................................... 2411 19.3.19.5 CCA sensitivity ................................................................................. 2411 19.3.19.6 Received channel power indicator (RCPI) measurement ................. 2413 19.3.19.7 Reduced interframe space (RIFS) ..................................................... 2413 19.3.20 PHY transmit procedure ...................................................................................... 2413 19.3.21 PHY receive procedure ........................................................................................ 2415 19.4 HT PLME ............................................................................................................................ 2420 19.4.1 PLME SAP sublayer management primitives ..................................................... 2420 19.4.2 PHY MIB ............................................................................................................. 2420 19.4.3 TXTIME calculation............................................................................................ 2424 19.4.4 HT PHY ............................................................................................................... 2425 19.5 Parameters for HT MCSs..................................................................................................... 2427 20. Directional multi-gigabit (DMG) PHY specification ...................................................................... 2436 69 Copyright Â© 2016 IEEE. All rights reserved. 20.1 DMG PHY introduction....................................................................................................... 2436 20.1.1 Scope.................................................................................................................... 2436 20.1.2 DMG PHY functions ........................................................................................... 2436 20.1.2.1 PHY management entity (PLME)..................................................... 2436 20.1.2.2 Service specification method ............................................................ 2436 20.2 DMG PHY service interface................................................................................................ 2436 20.2.1 Introduction.......................................................................................................... 2436 20.2.2 TXVECTOR and RXVECTOR parameters ........................................................ 2437 20.2.3 TXSTATUS parameters ...................................................................................... 2439 20.3 Common parameters ............................................................................................................ 2439 20.3.1 Channelization ..................................................................................................... 2439 20.3.2 Transmit mask...................................................................................................... 2440 20.3.3 Common requirements......................................................................................... 2440 20.3.3.1 Introduction....................................................................................... 2440 20.3.3.2 Center frequency tolerance ............................................................... 2440 20.3.3.3 Symbol clock tolerance..................................................................... 2440 20.3.3.4 Transmit center frequency leakage ................................................... 2441 20.3.3.5 Transmit rampup and rampdown ...................................................... 2441 20.3.3.6 Antenna setting ................................................................................. 2441 20.3.3.7 Maximum input requirement ............................................................ 2441 20.3.3.8 Receive sensitivity ............................................................................ 2441 20.3.4 Timing-related parameters ................................................................................... 2443 20.3.5 Mathematical conventions in the signal description............................................ 2444 20.3.5.1 General .............................................................................................. 2444 20.3.5.2 Windowing function ......................................................................... 2445 20.3.6 Common preamble............................................................................................... 2446 20.3.6.1 General .............................................................................................. 2446 20.3.6.2 Short Training field........................................................................... 2446 20.3.6.3 Channel Estimation field................................................................... 2447 20.3.6.4 Transmission of the preamble and BRP fields in an OFDM packet. 2448 20.3.7 HCS calculation for headers of DMG control mode, DMG OFDM mode, and DMG SC mode.............................................................................................. 2449 20.3.8 Common LDPC parity matrices .......................................................................... 2449 20.3.8.1 General .............................................................................................. 2449 20.3.8.2 Rate 1/2 LDPC code matrix H = 336 rows x 672 columns, Z = 42.. 2450 20.3.8.3 Rate 5/8 LDPC code matrix H = 252 rows x 672 columns, Z = 42.. 2450 20.3.8.4 Rate 3/4 LDPC code matrix H = 168 rows x 672 columns, Z = 42.. 2450 20.3.8.5 Rate 13/16 LDPC code matrix H = 126 rows x 672 columns, Z = 42 ................................................................................................ 2451 20.3.9 Scrambler ............................................................................................................. 2451 20.3.10 Received channel power indicator (RCPI) measurement .................................... 2451 20.4 DMG control mode .............................................................................................................. 2452 20.4.1 Introduction.......................................................................................................... 2452 20.4.2 PPDU format........................................................................................................ 2452 20.4.3 Transmission ........................................................................................................ 2452 20.4.3.1 Preamble............................................................................................ 2452 20.4.3.2 Header ............................................................................................... 2453 20.4.3.3 Data field........................................................................................... 2454 20.4.4 Performance requirements ................................................................................... 2455 20.4.4.1 Transmit requirements ...................................................................... 2455 20.4.4.2 Receive requirements........................................................................ 2456 20.5 DMG OFDM mode.............................................................................................................. 2456 20.5.1 Introduction.......................................................................................................... 2456 20.5.2 PPDU format........................................................................................................ 2457 70 Copyright Â© 2016 IEEE. All rights reserved. 20.5.3 Transmission ........................................................................................................ 2457 20.5.3.1 Header ............................................................................................... 2457 20.5.3.2 Data field........................................................................................... 2460 20.5.4 Performance requirements ................................................................................... 2466 20.5.4.1 Transmit requirements ...................................................................... 2466 20.5.4.2 Receive requirements........................................................................ 2468 20.6 DMG SC mode .................................................................................................................... 2468 20.6.1 Introduction.......................................................................................................... 2468 20.6.2 PPDU format........................................................................................................ 2469 20.6.3 Transmission ........................................................................................................ 2469 20.6.3.1 Header ............................................................................................... 2469 20.6.3.2 Data field........................................................................................... 2473 20.6.4 Performance requirements ................................................................................... 2479 20.6.4.1 Transmit requirements ...................................................................... 2479 20.6.4.2 Receive requirements........................................................................ 2480 20.7 DMG low-power SC mode .................................................................................................. 2481 20.7.1 Introduction.......................................................................................................... 2481 20.7.2 Transmission ........................................................................................................ 2481 20.7.2.1 Preamble............................................................................................ 2481 20.7.2.2 Header ............................................................................................... 2481 20.7.2.3 Data field........................................................................................... 2481 20.8 PHY transmit procedure ...................................................................................................... 2484 20.9 PHY receive procedure ........................................................................................................ 2487 20.10 Beamforming ....................................................................................................................... 2488 20.10.1 Beamforming concept.......................................................................................... 2488 20.10.2 Beamforming frame format ................................................................................. 2488 20.10.2.1 Sector-level sweep ............................................................................ 2488 20.10.2.2 Beam refinement ............................................................................... 2488 20.11 Golay sequences .................................................................................................................. 2492 20.12 DMG PLME ........................................................................................................................ 2494 20.12.1 PLME SAP sublayer management primitives ..................................................... 2494 20.12.2 DMG PHY MIB................................................................................................... 2494 20.12.3 TXTIME calculation............................................................................................ 2494 20.12.4 DMG PHY ........................................................................................................... 2495 21. Very high throughput (VHT) PHY specification ............................................................................ 2497 21.1 Introduction.......................................................................................................................... 2497 21.1.1 Introduction to the VHT PHY ............................................................................. 2497 21.1.2 Scope.................................................................................................................... 2498 21.1.3 VHT PHY functions ............................................................................................ 2498 21.1.3.1 General .............................................................................................. 2498 21.1.3.2 PHY management entity (PLME)..................................................... 2498 21.1.3.3 Service specification method ............................................................ 2498 21.1.4 PPDU formats ...................................................................................................... 2498 21.2 VHT PHY service interface ................................................................................................. 2499 21.2.1 Introduction.......................................................................................................... 2499 21.2.2 TXVECTOR and RXVECTOR parameters ........................................................ 2499 21.2.3 PHYCONFIG_VECTOR parameters .................................................................. 2507 21.2.4 Effects of CH_BANDWIDTH parameter on PPDU format................................ 2508 21.2.5 Support for NON_HT and HT formats................................................................ 2511 21.2.5.1 General .............................................................................................. 2511 21.2.5.2 Support for NON_HT format when NON_HT_MODULATION is OFDM ........................................................................................... 2512 71 Copyright Â© 2016 IEEE. All rights reserved. 21.2.5.3 Support for HT formats..................................................................... 2513 21.2.6 TXSTATUS parameters ...................................................................................... 2513 21.3 VHT PHY ............................................................................................................................ 2514 21.3.1 Introduction.......................................................................................................... 2514 21.3.2 VHT PPDU format .............................................................................................. 2514 21.3.3 Transmitter block diagram................................................................................... 2515 21.3.4 Overview of the PPDU encoding process............................................................ 2522 21.3.4.1 General .............................................................................................. 2522 21.3.4.2 Construction of L-STF ...................................................................... 2522 21.3.4.3 Construction of the L-LTF ................................................................ 2523 21.3.4.4 Construction of L-SIG ...................................................................... 2523 21.3.4.5 Construction of VHT-SIG-A ............................................................ 2523 21.3.4.6 Construction of VHT-STF ................................................................ 2524 21.3.4.7 Construction of VHT-LTF ................................................................ 2524 21.3.4.8 Construction of VHT-SIG-B............................................................. 2525 21.3.4.9 Construction of the Data field in a VHT SU PPDU ......................... 2525 21.3.4.10 Construction of the Data field in a VHT MU PPDU ........................ 2527 21.3.5 VHT modulation and coding scheme (VHT-MCS)............................................. 2527 21.3.6 Timing-related parameters ................................................................................... 2528 21.3.7 Mathematical description of signals .................................................................... 2531 21.3.7.1 Notation............................................................................................. 2531 21.3.7.2 Subcarrier indices in use ................................................................... 2531 21.3.7.3 Channel frequencies.......................................................................... 2532 21.3.7.4 Transmitted signal............................................................................. 2533 21.3.7.5 Definition of tone rotation................................................................. 2537 21.3.8 VHT preamble ..................................................................................................... 2538 21.3.8.1 Introduction....................................................................................... 2538 21.3.8.2 Non-VHT portion of VHT format preamble..................................... 2538 21.3.8.3 VHT portion of VHT format preamble............................................. 2542 21.3.9 Transmission of NON_HT and HT PPDUs with multiple transmit chains ......... 2556 21.3.9.1 Transmission of 20 MHz NON_HT PPDUs with more than one transmit chain.................................................................................... 2556 21.3.9.2 Transmission of HT PPDUs with more than four transmit chains ... 2556 21.3.10 Data field.............................................................................................................. 2556 21.3.10.1 General .............................................................................................. 2556 21.3.10.2 SERVICE field.................................................................................. 2557 21.3.10.3 CRC calculation for VHT-SIG-B ..................................................... 2558 21.3.10.4 Scrambler .......................................................................................... 2558 21.3.10.5 Coding............................................................................................... 2559 21.3.10.6 Stream parser..................................................................................... 2561 21.3.10.7 Segment parser.................................................................................. 2563 21.3.10.8 BCC interleaver................................................................................. 2564 21.3.10.9 Constellation mapping ...................................................................... 2566 21.3.10.10 Pilot subcarriers................................................................................. 2574 21.3.10.11 OFDM modulation............................................................................ 2575 21.3.10.12 Non-HT duplicate transmission ........................................................ 2577 21.3.11 SU-MIMO and DL-MU-MIMO Beamforming ................................................... 2578 21.3.11.1 General .............................................................................................. 2578 21.3.11.2 Beamforming Feedback Matrix V .................................................... 2579 21.3.11.3 Maximum Number of Total Spatial Streams in VHT MU PPDUs... 2579 21.3.11.4 Group ID ........................................................................................... 2579 21.3.12 VHT preamble format for sounding PPDUs........................................................ 2580 21.3.13 Regulatory requirements...................................................................................... 2580 21.3.14 Channelization ..................................................................................................... 2581 72 Copyright Â© 2016 IEEE. All rights reserved. 21.3.15 Slot time............................................................................................................... 2582 21.3.16 Transmit and receive port impedance .................................................................. 2582 21.3.17 VHT transmit specification.................................................................................. 2582 21.3.17.1 Transmit spectrum mask ................................................................... 2582 21.3.17.2 Spectral flatness ................................................................................ 2586 21.3.17.3 Transmit center frequency and symbol clock frequency tolerance... 2587 21.3.17.4 Modulation accuracy......................................................................... 2587 21.3.17.5 Time of Departure accuracy.............................................................. 2590 21.3.18 VHT receiver specification .................................................................................. 2590 21.3.18.1 Receiver minimum input sensitivity ................................................. 2590 21.3.18.2 Adjacent channel rejection................................................................ 2591 21.3.18.3 Nonadjacent channel rejection .......................................................... 2592 21.3.18.4 Receiver maximum input level ......................................................... 2593 21.3.18.5 CCA sensitivity ................................................................................. 2593 21.3.18.6 RSSI .................................................................................................. 2595 21.3.19 PHY transmit procedure ...................................................................................... 2595 21.3.20 PHY receive procedure ........................................................................................ 2597 21.4 VHT PLME.......................................................................................................................... 2602 21.4.1 PLME SAP sublayer management primitives ..................................................... 2602 21.4.2 PHY MIB ............................................................................................................. 2605 21.4.3 TXTIME and PSDU_LENGTH calculation........................................................ 2606 21.4.4 VHT PHY ............................................................................................................ 2607 21.5 Parameters for VHT-MCSs ................................................................................................. 2608 22. Television very high throughput (TVHT) PHY specification ......................................................... 2625 22.1 Introduction.......................................................................................................................... 2625 22.1.1 Introduction to the TVHT PHY ........................................................................... 2625 22.1.2 Scope.................................................................................................................... 2626 22.1.3 TVHT PHY functions .......................................................................................... 2626 22.1.3.1 General .............................................................................................. 2626 22.1.3.2 PHY management entity (PLME)..................................................... 2626 22.1.3.3 Service specification method ............................................................ 2626 22.1.4 PPDU formats ...................................................................................................... 2627 22.2 TVHT PHY service interface .............................................................................................. 2627 22.2.1 Introduction.......................................................................................................... 2627 22.2.2 TXVECTOR and RXVECTOR parameters ........................................................ 2627 22.2.3 Effects of CH_BANDWIDTH parameter on PPDU format................................ 2634 22.2.4 Support for NON_HT and HT formats................................................................ 2634 22.3 TVHT PHY sublayer ........................................................................................................... 2636 22.3.1 Introduction.......................................................................................................... 2636 22.3.2 VHT PPDU format in TVWS bands.................................................................... 2636 22.3.3 Transmitter block diagram................................................................................... 2637 22.3.4 Overview of the PPDU encoding process............................................................ 2638 22.3.4.1 General .............................................................................................. 2638 22.3.4.2 Construction of L-STF ...................................................................... 2638 22.3.4.3 Construction of the L-LTF ................................................................ 2639 22.3.4.4 Construction of L-SIG ...................................................................... 2639 22.3.4.5 Construction of TVHT-SIG-A .......................................................... 2640 22.3.4.6 Construction of TVHT-STF.............................................................. 2640 22.3.4.7 Construction of TVHT-LTF.............................................................. 2641 22.3.4.8 Construction of TVHT-SIG-B .......................................................... 2641 22.3.4.9 Construction of the Data field in an SU PPDU................................. 2641 22.3.4.10 Construction of the Data field in an MU PPDU ............................... 2642 73 Copyright Â© 2016 IEEE. All rights reserved. 22.3.5 Modulation and coding scheme (MCS) ............................................................... 2642 22.3.6 Timing-related parameters ................................................................................... 2643 22.3.7 Mathematical description of signals .................................................................... 2644 22.3.8 TVHT preamble ................................................................................................... 2648 22.3.8.1 Introduction....................................................................................... 2648 22.3.8.2 Non-TVHT portion of TVHT format preamble................................ 2648 22.3.8.3 TVHT portion of TVHT format preamble........................................ 2649 22.3.9 Transmission of NON_HT and HT PPDUs with multiple antennas ................... 2651 22.3.10 Data field.............................................................................................................. 2651 22.3.10.1 General .............................................................................................. 2651 22.3.10.2 SERVICE field.................................................................................. 2651 22.3.10.3 CRC calculation for TVHT-SIG-B ................................................... 2651 22.3.10.4 Scrambler .......................................................................................... 2651 22.3.10.5 Coding............................................................................................... 2651 22.3.10.6 Stream parser..................................................................................... 2651 22.3.10.7 Segment parser.................................................................................. 2651 22.3.10.8 BCC interleaver................................................................................. 2651 22.3.10.9 Constellation mapping ...................................................................... 2652 22.3.10.10 Pilot subcarriers................................................................................. 2653 22.3.10.11 OFDM modulation transmission in VHT format.............................. 2653 22.3.10.12 Non-HT duplicate transmission ........................................................ 2653 22.3.11 SU-MIMO and MU-MIMO Beamforming.......................................................... 2654 22.3.11.1 General .............................................................................................. 2654 22.3.11.2 Beamforming Feedback Matrix V .................................................... 2654 22.3.11.3 Group ID ........................................................................................... 2654 22.3.12 TVHT preamble format for sounding PPDUs ..................................................... 2654 22.3.13 Regulatory requirements...................................................................................... 2654 22.3.14 Channelization ..................................................................................................... 2655 22.3.15 Slot time............................................................................................................... 2656 22.3.16 Transmit and receive port impedance .................................................................. 2656 22.3.17 TVHT transmit specification ............................................................................... 2657 22.3.17.1 Transmit spectrum mask ................................................................... 2657 22.3.17.2 Spectral flatness ................................................................................ 2658 22.3.17.3 Transmit center frequency and symbol clock frequency tolerance... 2659 22.3.17.4 Modulation accuracy......................................................................... 2659 22.3.17.5 Time of Departure accuracy.............................................................. 2660 22.3.18 TVHT receiver specification ............................................................................... 2660 22.3.18.1 General .............................................................................................. 2660 22.3.18.2 Receiver minimum input sensitivity ................................................. 2660 22.3.18.3 Adjacent channel rejection................................................................ 2661 22.3.18.4 Nonadjacent channel rejection .......................................................... 2661 22.3.18.5 Receiver maximum input level ......................................................... 2662 22.3.18.6 CCA sensitivity ................................................................................. 2662 22.3.18.7 RSSI .................................................................................................. 2664 22.3.19 PHY transmit procedure ...................................................................................... 2664 22.3.20 PHY receive procedure ........................................................................................ 2664 22.4 TVHT PLME ....................................................................................................................... 2665 22.4.1 PLME SAP sublayer management primitives ..................................................... 2665 22.4.2 PHY MIB ............................................................................................................. 2665 22.4.3 TXTIME and PSDU_LENGTH calculation........................................................ 2665 22.4.4 TVHT PHY.......................................................................................................... 2665 22.5 Parameters for TVHT MCSs ............................................................................................... 2666 74 Copyright Â© 2016 IEEE. All rights reserved. Annex A (informative) Bibliography ........................................................................................................ 2673 Annex B (normative) Protocol Implementation Conformance Statement (PICS) proforma..................... 2677 B.1 Introduction.................................................................................................................... 2677 B.2 Abbreviations and special symbols................................................................................ 2677 B.2.1 Symbols for Status column .............................................................................. 2677 B.2.2 General abbreviations for Item and Support columns...................................... 2677 B.3 Instructions for completing the PICS proforma............................................................. 2678 B.3.1 General structure of the PICS proforma........................................................... 2678 B.3.2 Additional information ..................................................................................... 2679 B.3.3 Exception information...................................................................................... 2679 B.3.4 Conditional status ............................................................................................. 2679 B.4 PICS proformaâ€”IEEE Std 802.11-2016....................................................................... 2681 B.4.1 Implementation identification .......................................................................... 2681 B.4.2 Protocol summary ............................................................................................ 2681 B.4.3 IUT configuration............................................................................................. 2682 B.4.4 MAC protocol .................................................................................................. 2684 B.4.5 Direct sequence PHY functions ....................................................................... 2698 B.4.6 OFDM PHY functions ..................................................................................... 2701 B.4.7 High rate, direct sequence PHY functions ....................................................... 2712 B.4.8 Regulatory domain extensions ......................................................................... 2716 B.4.9 ERP functions................................................................................................... 2717 B.4.10 Spectrum management extensions ................................................................... 2719 B.4.11 Operating classes extensions ............................................................................ 2723 B.4.12 QoS base functionality ..................................................................................... 2723 B.4.13 QoS enhanced distributed channel access (EDCA) ......................................... 2724 B.4.14 QoS hybrid coordination function (HCF) controlled channel access (HCCA) ............................................................................................................ 2725 B.4.15 Radio management extensions ......................................................................... 2726 B.4.16 DSE functions .................................................................................................. 2732 B.4.17 High-throughput (HT) features ..................................................................... 2735 B.4.18 Tunneled direct-link setup extensions.............................................................. 2742 B.4.19 WNM extensions.............................................................................................. 2743 B.4.20 Interworking (IW) with external networks extensions..................................... 2747 B.4.21 Mesh protocol capabilities ............................................................................... 2749 B.4.22 QMF extensions .............................................................................................. 2752 B.4.23 RobustAVT extensions ................................................................................... 2753 B.4.24 DMG features ................................................................................................. 2754 B.4.25 Very high throughput (VHT) features.............................................................. 2762 B.4.26 TVWS functions............................................................................................... 2769 Annex C (normative) ASN.1 encoding of the MAC and PHY MIB ......................................................... 2776 C.1 General........................................................................................................................... 2776 C.2 Guidelines for IEEE 802.11 MIB authors/editors ......................................................... 2776 C.3 MIB detail ...................................................................................................................... 2776 Annex D (normative) Regulatory references............................................................................................. 3269 D.1 External regulatory references ....................................................................................... 3269 D.2 Radio performance specifications.................................................................................. 3271 D.2.1 Transmit and receive in-band and out-of-band spurious emissions ................. 3271 D.2.2 Transmit power levels ...................................................................................... 3271 75 Copyright Â© 2016 IEEE. All rights reserved. D.2.3 Transmit spectrum mask .................................................................................. 3272 D.2.4 Transmit Mask M ............................................................................................. 3273 D.2.5 CCA-ED threshold ........................................................................................... 3274 Annex E (normative) Country elements and operating classes ................................................................. 3275 E.1 Country information and operating classes ................................................................... 3275 E.2 Band-specific operating requirements ........................................................................... 3287 E.2.1 General ............................................................................................................. 3287 E.2.2 3650â€“3700 MHz in the United States .............................................................. 3287 E.2.3 5.9 GHz band in the United States (5.850â€“5.925 GHz) ................................... 3289 E.2.4 5.9 GHz band in Europe (5.855â€“5.925 GHz)................................................... 3289 E.2.5 TVWS band in the United States and Canada (54 MHz to 698 MHz) ............ 3289 E.2.6 TVWS band in Europe ..................................................................................... 3291 Annex F (normative) HT LDPC matrix definitions................................................................................... 3293 Annex G (normative) Frame exchange sequences..................................................................................... 3296 G.1 General........................................................................................................................... 3296 G.2 Basic sequences ............................................................................................................. 3298 G.3 EDCA and HCCA sequences ........................................................................................ 3299 G.4 HT and VHT sequences ................................................................................................. 3301 Annex H (normative) Usage of Ethertype 89-0d....................................................................................... 3311 Annex I (informative) Examples of encoding a frame for OFDM PHYs and DMG PHYs...................... 3312 I.1 Example 1 - BCC encoding ........................................................................................... 3312 I.1.1 Introduction ...................................................................................................... 3312 I.1.2 The message for the BCC example .................................................................. 3313 I.1.3 Generation of the preamble .............................................................................. 3314 I.1.4 Generation of the SIGNAL field ...................................................................... 3319 I.1.5 Generating the DATA bits for the BCC example ............................................ 3323 I.1.6 Generating the first DATA symbol for the BCC example............................... 3327 I.1.7 Generating the additional DATA symbols....................................................... 3333 I.1.8 The entire packet for the BCC example ........................................................... 3334 I.2 Generating encoded DATA bitsâ€”LDPC example 1..................................................... 3342 I.2.1 The message for LDPC example 1................................................................... 3342 I.2.2 Prepending the SERVICE field for LDPC example 1 ..................................... 3343 I.2.3 Scrambling LDPC example 1........................................................................... 3345 I.2.4 Inserting shortening bits for LDPC example 1................................................. 3346 I.2.5 Encoding data for LDPC example 1 ................................................................ 3348 I.2.6 Removing shortening bits and puncturing for LDPC example 1 ..................... 3351 I.3 Generating encoded DATA bitsâ€”LDPC example 2..................................................... 3353 I.3.1 The message for LDPC example 2................................................................... 3353 I.3.2 Prepending the SERVICE field for LDPC example 2 ..................................... 3355 I.3.3 Scrambling LDPC example 2........................................................................... 3357 I.3.4 Inserting the shortening bits for LDPC example 2........................................... 3358 I.3.5 Encoding the data for LDPC example 2........................................................... 3360 I.3.6 Removing shortening bits and repetition for LDPC example 2 ....................... 3364 I.4 DMG example data vectors ........................................................................................... 3368 I.5 DMG Example 1 â€“ DMG control mode encoding......................................................... 3368 I.5.1 DMG control mode preamble .......................................................................... 3368 76 Copyright Â© 2016 IEEE. All rights reserved. I.5.2 Control mode header ........................................................................................ 3369 I.5.3 DMG control mode payload............................................................................. 3371 I.6 DMG Example 2 â€“ DMG SC mode encoding ............................................................... 3372 I.6.1 DMG SC mode preamble ................................................................................. 3372 I.6.2 DMG SC mode header ..................................................................................... 3373 I.6.3 DMG SC mode payload ................................................................................... 3375 I.7 DMG Example 3 â€“ DMG OFDM mode encoding ........................................................ 3381 I.7.1 DMG OFDM mode preamble .......................................................................... 3381 I.7.2 DMG OFDM mode header .............................................................................. 3381 I.7.3 DMG OFDM mode header modulation ........................................................... 3384 I.7.4 DMG OFDM mode payload coding................................................................. 3385 I.7.5 DMG OFDM mode MCS14 payload modulation............................................ 3385 I.7.6 DMG OFDM mode MCS17 payload modulation............................................ 3387 I.7.7 DMG OFDM mode MCS19 payload modulation............................................ 3388 I.7.8 DMG OFDM mode MCS23 payload modulation............................................ 3390 I.8 DMG Example 4 â€“ DMG low-power SC mode encoding............................................. 3391 I.8.1 DMG low-power SC mode preamble............................................................... 3391 I.8.2 DMG low-power SC mode header................................................................... 3391 I.8.3 DMG low-power SC mode MCS26 payload ................................................... 3392 I.8.4 DMG low-power SC mode MCS30 payload ................................................... 3393 Annex J (informative) RSNA reference implementations and test vectors............................................... 3395 J.1 TKIP temporal key mixing function reference implementation and test vector............ 3395 J.1.1 TKIP temporal key mixing function reference implementation ...................... 3395 J.1.2 Test vectors ...................................................................................................... 3405 J.2 Michael reference implementation and test vectors ...................................................... 3407 J.2.1 Michael test vectors.......................................................................................... 3407 J.2.2 Sample code for michael .................................................................................. 3408 J.3 PRF reference implementation and test vectors ............................................................ 3415 J.3.1 PRF reference code .......................................................................................... 3415 J.3.2 PRF test vectors................................................................................................ 3416 J.4 Suggested pass-phrase-to-PSK mapping ....................................................................... 3416 J.4.1 Introduction ...................................................................................................... 3416 J.4.2 Test vectors ...................................................................................................... 3417 J.5 Suggestions for random number generation .................................................................. 3417 J.5.1 General ............................................................................................................. 3417 J.5.2 Software sampling............................................................................................ 3418 J.5.3 Hardware-assisted solution .............................................................................. 3419 J.6 Additional test vectors ................................................................................................... 3420 J.6.1 Notation ............................................................................................................ 3420 J.6.2 WEP cryptographic encapsulation ................................................................... 3420 J.6.3 TKIP test vector ............................................................................................... 3421 J.6.4 CCMP test vectors............................................................................................ 3422 J.6.5 PRF test vectors................................................................................................ 3423 J.7 Key hierarchy test vectors for pairwise keys ................................................................. 3425 J.7.1 General ............................................................................................................. 3425 J.7.2 CCMP-128 pairwise key derivation ................................................................. 3425 J.7.3 TKIP pairwise key derivation .......................................................................... 3425 J.8 Test vectors for AES-128-CMAC ................................................................................. 3426 J.9 Management frame protection test vectors .................................................................... 3426 J.9.1 BIP with broadcast Deauthentication frame..................................................... 3426 J.9.2 CCMP-128 with unicast Deauthentication frame ............................................ 3428 J.10 SAE test vector .............................................................................................................. 3429 77 Copyright Â© 2016 IEEE. All rights reserved. J.11 GCMP ............................................................................................................................ 3430 J.11.1 Test vector ........................................................................................................ 3430 J.11.2 Example of encryption C code ......................................................................... 3433 Annex K (informative) TSPECs and Admission control........................................................................... 3446 K.1 Example use of TSPEC for admission control .............................................................. 3446 K.2 Recommendation for implementation of contention based admission control.............. 3447 K.2.1 Use of ACM (admission control mandatory) subfield ..................................... 3447 K.2.2 Deriving medium time ..................................................................................... 3447 K.3 Guidelines and reference design for sample scheduler and admission control unit ...... 3449 K.3.1 Guidelines for deriving service schedule parameters....................................... 3449 K.3.2 Reference design for sample scheduler and admission control unit ................ 3450 K.4 TSPEC construction....................................................................................................... 3452 K.4.1 Surplus Bandwidth Allocation ......................................................................... 3453 K.4.2 Minimum and Maximum Service Interval ....................................................... 3457 K.4.3 Minimum, Mean, and Peak Data Rate ............................................................. 3458 Annex L (informative) Examples and sample code for encoding a TIM Partial Virtual Bitmap.............. 3459 L.1 Introduction.................................................................................................................... 3459 L.2 Examples........................................................................................................................ 3459 L.3 Sample C code ............................................................................................................... 3462 Annex M (informative) Integration function ............................................................................................. 3468 M.1 Introduction.................................................................................................................... 3468 M.2 Ethernet V2.0/IEEE 802.3 LAN integration function ................................................... 3468 M.3 Example ......................................................................................................................... 3468 M.4 Integration service versus bridging................................................................................ 3470 Annex N (informative) AP functional description .................................................................................... 3471 N.1 Introduction.................................................................................................................... 3471 N.2 Terminology................................................................................................................... 3471 N.3 Primary ACM_STA functions ....................................................................................... 3475 N.4 Primary AP functions..................................................................................................... 3475 N.5 Primary DS functions..................................................................................................... 3477 N.6 Primary portal function .................................................................................................. 3477 Annex O (informative) Additional VHT and HT information .................................................................. 3478 O.1 VHT and HT waveform generator tool.......................................................................... 3478 O.2 A-MPDU deaggregation ................................................................................................ 3478 O.3 Example of an RD exchange sequence.......................................................................... 3480 O.4 Illustration of determination of NDP addresses............................................................. 3481 O.5 20/40 MHz BSS establishment and maintenance .......................................................... 3482 O.5.1 Signaling 20/40 MHz BSS capability and operation ....................................... 3482 O.5.2 Establishing a 20/40 MHz BSS ........................................................................ 3482 O.5.3 Monitoring channels for other BSS operation.................................................. 3483 Annex P (informative) Location and Time Difference accuracy test ........................................................ 3485 P.1 Location via Time Difference of arrival ........................................................................ 3485 78 Copyright Â© 2016 IEEE. All rights reserved. P.2 Time Difference of departure accuracy test................................................................... 3485 P.3 Differential Distance Computation using Fine Timing Measurement frames............... 3487 Annex Q (informative) Example use of the Destination URI for Event and Diagnostic Reports ............. 3489 Q.1 Destination URI payload ............................................................................................... 3489 Q.2 Use of HTTP (or HTTPS) for Destination URI of Event and Diagnostic Reports ....... 3489 Annex R (informative) Interworking with external networks ................................................................... 3491 R.1 General........................................................................................................................... 3491 R.2 Network discovery and selection ................................................................................... 3491 R.2.1 General ............................................................................................................. 3491 R.2.2 Airport .............................................................................................................. 3491 R.2.3 Shopping........................................................................................................... 3492 R.2.4 Sales meeting.................................................................................................... 3493 R.2.5 Museum ............................................................................................................ 3493 R.2.6 Emergency call ................................................................................................. 3494 R.2.7 Emergency alert................................................................................................ 3495 R.3 QoS mapping guidelines for interworking with external networks ............................... 3495 R.3.1 General ............................................................................................................. 3495 R.3.2 Determination of the mapping for a STA......................................................... 3496 R.3.3 Example of QoS mapping from different networks ......................................... 3496 R.4 Interworking and SSPN interface support ..................................................................... 3498 R.4.1 General ............................................................................................................. 3498 R.4.2 SSPN interface parameters............................................................................... 3499 R.5 Interworking with external networks and emergency call support................................ 3503 R.5.1 General ............................................................................................................. 3503 R.5.2 Background on emergency call support over IEEE 802.11 infrastructure....... 3503 R.5.3 System aspects for emergency call support...................................................... 3504 R.5.4 Description of the Expedited Bandwidth Request element.............................. 3505 R.5.5 Access to emergency services in an RSN ........................................................ 3506 R.6 Peer information ............................................................................................................ 3507 R.7 Calculating Estimated Throughput ................................................................................ 3507 Annex S (informative) Mesh BSS operation ............................................................................................. 3510 S.1 Clarification of mesh Data frame format ....................................................................... 3510 S.2 Operational considerations for interworking ................................................................. 3510 S.2.1 Formation and maintenance of the IEEE 802.1D spanning tree ...................... 3510 S.3 Power save parameters selection ................................................................................... 3511 S.3.1 General ............................................................................................................. 3511 S.3.2 Selecting the mesh power management mode based on traffic load................ 3511 S.3.3 Scanning of mesh BSSs.................................................................................... 3511 S.3.4 Default parameters ........................................................................................... 3512 S.3.5 MSDU forwarding in an MBSS containing mesh STAs in light or deep sleep mode........................................................................................................ 3512 S.3.6 Synchronization maintenance of mesh STAs in deep sleep mode................... 3512 S.4 SIV key wrapping test vector......................................................................................... 3513 S.5 Airtime link metric usage example ................................................................................ 3514 S.6 Generation of proactive PREP elements in the proactive PREQ mechanism of HWMP ........................................................................................................................... 3514 S.6.1 General ............................................................................................................. 3514 S.6.2 Additions to forwarding information ............................................................... 3515 79 Copyright Â© 2016 IEEE. All rights reserved. S.6.3 Actions when sending Data frames as source mesh STA ................................ 3515 S.6.4 Actions on receipt of a proactive PREQ element............................................. 3515 S.6.5 Generation of proactive PREP elements .......................................................... 3515 S.7 Generation of PREQ elements in proactive RANN mechanism of HWMP.................. 3516 S.7.1 General ............................................................................................................. 3516 S.7.2 Additions to forwarding information ............................................................... 3516 S.7.3 Actions when sending Data frames as source mesh STA ................................ 3516 S.7.4 Actions on receipt of proactive RANN element .............................................. 3516 S.7.5 Actions on receipt of a PREP element ............................................................. 3517 Annex T (informative) Overlapping BSS (OBSS) management............................................................... 3518 T.1 Introduction.................................................................................................................... 3518 T.2 QLoad Report element................................................................................................... 3518 T.2.1 General ............................................................................................................. 3518 T.2.2 Calculating medium time ................................................................................. 3519 T.2.3 Calculation of potential traffic self................................................................... 3519 T.2.4 Calculation of allocated traffic self .................................................................. 3521 T.2.5 Calculation of allocated traffic shared.............................................................. 3522 T.2.6 Calculation of EDCA Access Factor................................................................ 3522 T.2.7 EDCA Overhead Factor ................................................................................... 3523 T.2.8 Calculation of HCCA Access Factor ............................................................... 3524 T.3 Channel selection using QLoad report........................................................................... 3524 T.3.1 General ............................................................................................................. 3524 T.3.2 AP with admission control mandatory ............................................................. 3524 T.3.3 AP with an HC ................................................................................................. 3525 T.3.4 Channel selection procedures........................................................................... 3525 T.4 Sharing in an OBSS situation ........................................................................................ 3526 T.4.1 General ............................................................................................................. 3526 T.4.2 Sharing schemes ............................................................................................... 3527 T.5 Mitigating consequences of OBSS sharing in presence of noncollaborating devices ... 3529 Annex U (informative) Functions of the centralized coordination service root (CCSR) .......................... 3530 Annex V (informative) TSPEC aggregation for DMG BSSs .................................................................... 3531 80 Copyright Â© 2016 IEEE. All rights reserved. Tables Table 4-1â€”GDD mechanisms and timescales ............................................................................................ 214 Table 6-1â€”Supported TS management primitives ..................................................................................... 339 Table 6-2â€”Reason codes for network down .............................................................................................. 597 Table 6-3â€”Reason codes for ESS link down ............................................................................................. 598 Table 6-4â€”ESS description ........................................................................................................................ 600 Table 6-5â€”Trigger support values.............................................................................................................. 600 Table 6-6â€”Event Capability Set ................................................................................................................. 603 Table 6-7â€”ESS Link Parameter Set ........................................................................................................... 605 Table 8-1â€”PHY SAP peer-to-peer service primitives................................................................................ 620 Table 8-2â€”PHY SAP inter-(sub)layer service primitives .......................................................................... 621 Table 8-3â€”PHY SAP service primitive parameters ................................................................................... 621 Table 8-4â€”Vector descriptions................................................................................................................... 622 Table 8-5â€”The channel-list parameter elements ........................................................................................ 629 Table 9-1â€”Valid type and subtype combinations ...................................................................................... 639 Table 9-2â€”Control Frame Extension ......................................................................................................... 640 Table 9-3â€”To/From DS combinations in Data frames............................................................................... 641 Table 9-4â€”To/From DS combinations in Management frames ................................................................ 642 Table 9-5â€”Duration/ID field encoding ...................................................................................................... 645 Table 9-6â€”QoS Control field ..................................................................................................................... 648 Table 9-7â€”QoS Control field for frames transmitted within a DMG PPDU ............................................. 649 Table 9-8â€”TID subfield ............................................................................................................................. 649 Table 9-9â€”Ack Policy subfield in QoS Control field of QoS Data frames................................................ 650 Table 9-10â€”AC Constraint subfield values................................................................................................ 654 Table 9-11â€”RDG/More PPDU subfield values ......................................................................................... 655 Table 9-12â€”Subfields of Link Adaptation Control subfield ...................................................................... 656 Table 9-13â€”Subfields of the MAI subfield ................................................................................................ 656 Table 9-14â€”ASEL Command and ASEL Data subfields........................................................................... 657 Table 9-15â€”Calibration control subfields .................................................................................................. 658 Table 9-16â€”CSI/Steering subfield values .................................................................................................. 658 Table 9-17â€”VHT variant HT Control field subfields ............................................................................... 659 Table 9-18â€”MFB subfield in the VHT variant HT Control field ............................................................. 661 Table 9-19â€”Maximum data unit sizes (in octets) and durations (in microseconds) ................................. 662 Table 9-20â€”Valid values for the Address Extension Mode subfield ........................................................ 664 Table 9-21â€”BAR Ack Policy subfield ....................................................................................................... 673 Table 9-22â€”BlockAckReq frame variant encoding ................................................................................... 674 Table 9-23â€”BA Ack Policy subfield.......................................................................................................... 677 Table 9-24â€”BlockAck frame variant encoding ........................................................................................ 677 Table 9-25â€”STA Info subfields ................................................................................................................. 686 Table 9-26â€”Address field contents ............................................................................................................ 688 Table 9-27â€”Beacon frame body................................................................................................................. 694 Table 9-28â€”Disassociation frame body ..................................................................................................... 699 Table 9-29â€”Association Request frame body ............................................................................................ 699 Table 9-30â€”Association Response frame body ......................................................................................... 700 Table 9-31â€”Reassociation Request frame body......................................................................................... 702 Table 9-32â€”Reassociation Response frame body ...................................................................................... 704 Table 9-33â€”Probe Request frame body ..................................................................................................... 706 Table 9-34â€”Probe Response frame body ................................................................................................... 708 Table 9-35â€”Authentication frame body ..................................................................................................... 712 Table 9-36â€”Presence of fields and elements in Authentication frames..................................................... 713 Table 9-37â€”Deauthentication frame body ................................................................................................. 715 Table 9-38â€”Action frame body.................................................................................................................. 715 Table 9-39â€”Action No Ack frame body .................................................................................................... 716 81 Copyright Â© 2016 IEEE. All rights reserved. Table 9-40â€”Timing Advertisement frame body ........................................................................................ 716 Table 9-41â€”DMG Beacon frame body ..................................................................................................... 717 Table 9-42â€”Valid address field usage for Mesh Data and Multihop Action frames ................................. 721 Table 9-43â€”Non-AP STA usage of QoS, CF-Pollable, and CF-Poll Request ........................................... 725 Table 9-44â€”AP usage of QoS, CF-Pollable, and CF-Poll Request............................................................ 726 Table 9-45â€”Reason codes .......................................................................................................................... 728 Table 9-46â€”Status codes ............................................................................................................................ 732 Table 9-47â€”Category values ...................................................................................................................... 736 Table 9-48â€”Settings of the Max SP Length subfield ................................................................................. 740 Table 9-49â€”Settings of the Channel Width field ....................................................................................... 742 Table 9-50â€”Settings of the PCO Phase Control field ................................................................................ 743 Table 9-51â€”Subfields of the MIMO Control field..................................................................................... 745 Table 9-52â€”CSI Report field (20 MHz)..................................................................................................... 746 Table 9-53â€”CSI Report field (40 MHz)..................................................................................................... 747 Table 9-54â€”Number of matrices and carrier grouping .............................................................................. 748 Table 9-55â€”Noncompressed Beamforming Report field (20 MHz) .......................................................... 749 Table 9-56â€”Noncompressed Beamforming Report field (40 MHz) .......................................................... 749 Table 9-57â€”Order of angles in the Compressed Beamforming Report field ............................................. 750 Table 9-58â€”Quantization of angles............................................................................................................ 751 Table 9-59â€”Compressed Beamforming Report field (20 MHz) ................................................................ 751 Table 9-60â€”Compressed Beamforming Report field (40 MHz) ................................................................ 752 Table 9-61â€”Venue group codes and descriptions ...................................................................................... 756 Table 9-62â€”Venue type assignments ......................................................................................................... 757 Table 9-63â€”Band ID field ......................................................................................................................... 761 Table 9-64â€”The BSS Type subfield when the Discovery mode field is 0................................................. 762 Table 9-65â€”The BSS Type subfield when the Discovery mode field is 1................................................. 762 Table 9-66â€”Subfields of the VHT MIMO Control field ........................................................................... 763 Table 9-67â€”Order of angles in the Compressed Beamforming Feedback Matrix subfield ...................... 765 Table 9-68â€”Quantization of angles............................................................................................................ 767 Table 9-69â€”VHT Compressed Beamforming Report information ........................................................... 767 Table 9-70â€”Subcarriers for which a Compressed Beamforming Feedback Matrix subfield is sent back 768 Table 9-71â€”Average SNR of Space-Time Stream i subfield..................................................................... 773 Table 9-72â€”MU Exclusive Beamforming Report information ................................................................. 775 Table 9-73â€”Number of subcarriers and subcarrier mapping .................................................................... 776 Table 9-74â€”Subfield values of the Operating Mode field ......................................................................... 779 Table 9-75â€”Setting of the Channel Width subfield and 160/80+80 BW subfield at a VHT STA transmitting the Operating Mode field ........................................................................... 780 Table 9-76â€”WSM Type definition............................................................................................................. 783 Table 9-77â€”Element IDs ........................................................................................................................... 784 Table 9-78â€”BSS membership selector value encoding ............................................................................. 791 Table 9-79â€”Coverage Class field parameters ............................................................................................ 798 Table 9-80â€”Values of the Secondary Channel Offset field ....................................................................... 803 Table 9-81â€”Summary of use of Enable, Request, and Report bits ............................................................ 805 Table 9-82â€”Measurement type definitions for measurement requests ..................................................... 805 Table 9-83â€”Optional subelement IDs for Channel Load request .............................................................. 808 Table 9-84â€”Reporting Condition subfield for Channel Load report ......................................................... 809 Table 9-85â€”Optional subelement IDs for Noise Histogram request.......................................................... 810 Table 9-86â€”Reporting Condition subfield for Noise Histogram report..................................................... 810 Table 9-87â€”Measurement Mode definitions for Beacon request............................................................... 812 Table 9-88â€”Optional subelement IDs for Beacon request......................................................................... 812 Table 9-89â€”Reporting Condition subfield for Beacon report .................................................................... 813 Table 9-90â€”Reporting Detail values .......................................................................................................... 814 Table 9-91â€”Optional subelement IDs for Frame request........................................................................... 815 Table 9-92â€”Group Identity for a STA Statistics request ........................................................................... 816 82 Copyright Â© 2016 IEEE. All rights reserved. Table 9-93â€”Optional subelement IDs for STA Statistics request.............................................................. 817 Table 9-94â€”Location Subject field definition ............................................................................................ 820 Table 9-95â€”Optional subelement IDs for LCI request ............................................................................. 821 Table 9-96â€”Optional subelement IDs for Transmit Stream/Category Measurement Request .................. 824 Table 9-97â€”Delayed MSDU Range Definitions ........................................................................................ 825 Table 9-98â€”Optional subelement IDs for Measurement Pause request..................................................... 826 Table 9-99â€”Optional subelement IDs for STA Multicast Diagnostics request ......................................... 828 Table 9-100â€”Civic Location Type field values ......................................................................................... 829 Table 9-101â€”Location Service Interval Units............................................................................................ 829 Table 9-102â€”Optional subelement IDs for Location Civic request ........................................................... 829 Table 9-103â€”Optional subelement IDs for Location Identifier request..................................................... 830 Table 9-104â€”Optional subelement IDs for Directional Channel Quality request...................................... 832 Table 9-105â€”Reporting Condition subfield for Directional Channel Quality report ................................ 832 Table 9-106â€”FTM Range subelement IDs for Fine Timing Measurement Range request........................ 834 Table 9-107â€”Measurement Type field definitions for measurement reports............................................. 837 Table 9-108â€”RPI definitions for an RPI histogram report ........................................................................ 839 Table 9-109â€”Optional subelement IDs for Channel Load report .............................................................. 841 Table 9-110â€”IPI Definitions for a Noise Histogram report ....................................................................... 842 Table 9-111â€”Optional subelement IDs for Noise Histogram report.......................................................... 843 Table 9-112â€”Optional subelement IDs for Beacon report......................................................................... 844 Table 9-113â€”Optional subelement IDs for Frame report........................................................................... 846 Table 9-114â€”Group Identity for a STA Statistics report ........................................................................... 848 Table 9-115â€”Optional subelement IDs for STA Statistics report.............................................................. 854 Table 9-116â€”Subelement IDs for LCI Report ........................................................................................... 856 Table 9-117â€”Delay definitions for a Transmit Stream/Category Measurement report for a Bin 0 Range field value of 10 TU ........................................................................... 864 Table 9-118â€”Optional subelement IDs for Transmit Stream/Category Measurement report.................... 865 Table 9-119â€”Optional subelement IDs for Multicast Diagnostics report.................................................. 867 Table 9-120â€”Summary of fields used in the STA Multicast Diagnostics report....................................... 867 Table 9-121â€”Subelement IDs for Location Civic report ........................................................................... 868 Table 9-122â€”Location Shape IDs .............................................................................................................. 870 Table 9-123â€”Map Types ............................................................................................................................ 873 Table 9-124â€”Subelement IDs for Location Identifier report ..................................................................... 874 Table 9-125â€”URI/FQDN Descriptor field values...................................................................................... 875 Table 9-126â€”Optional subelement IDs for Directional Channel Quality report........................................ 877 Table 9-127â€”Optional subelement IDs for Directional Measurement report ............................................ 878 Table 9-128â€”Optional subelement IDs for Directional Statistics report ................................................... 879 Table 9-129â€”Error Code field values......................................................................................................... 880 Table 9-130â€”Optional subelement IDs for Fine Timing Measurement Range report ............................... 881 Table 9-131â€”Cipher suite selectors............................................................................................................ 884 Table 9-132â€”Cipher suite usage ................................................................................................................ 886 Table 9-133â€”AKM suite selectors ............................................................................................................. 886 Table 9-134â€”PTKSA/GTKSA/STKSA replay counters usage ................................................................. 889 Table 9-135â€”Extended Capabilities field .................................................................................................. 891 Table 9-136â€”ACI-to-AC coding ................................................................................................................ 898 Table 9-137â€”Default EDCA Parameter Set element parameter values if dot11OCBActivated is false ... 899 Table 9-138â€”Default EDCA parameter set for STA operation if dot11OCBActivated is true ................. 899 Table 9-139â€”Direction subfield encoding ................................................................................................. 900 Table 9-140â€”Access Policy subfield.......................................................................................................... 901 Table 9-141â€”TS Info Ack Policy subfield encoding ................................................................................. 901 Table 9-142â€”Setting of Schedule subfield................................................................................................. 902 Table 9-143â€”Reliability subfield values .................................................................................................... 906 Table 9-144â€”User Priority field of TCLAS element ................................................................................. 906 Table 9-145â€”Frame classifier type ............................................................................................................ 907 83 Copyright Â© 2016 IEEE. All rights reserved. Table 9-146â€”Interpretation of the Classifier Mask Control subfield values ............................................. 908 Table 9-147â€”Map from location of Classifier Mask subfield to target subfield ....................................... 908 Table 9-148â€”Classifier parameters for Classifier Type 4 .......................................................................... 910 Table 9-149â€”Encoding of Processing subfield .......................................................................................... 915 Table 9-150â€”Reachability field ................................................................................................................. 917 Table 9-151â€”Optional subelement IDs for Neighbor report ..................................................................... 919 Table 9-152â€”Preference field values ......................................................................................................... 921 Table 9-153â€”HT/VHT Operation Information subfields........................................................................... 922 Table 9-154â€”RCPI values .......................................................................................................................... 923 Table 9-155â€”Optional subelement IDs for Measurement Pilot Transmission .......................................... 926 Table 9-156â€”Available Admission Capacity Bitmask definition .............................................................. 927 Table 9-157â€”RM Enabled Capabilities definition ..................................................................................... 929 Table 9-158â€”Optional subelement IDs for Multiple BSSID ..................................................................... 932 Table 9-159â€”Subelement IDs .................................................................................................................... 934 Table 9-160â€”Timeout Interval Type field value........................................................................................ 936 Table 9-161â€”Resource type code in RIC Descriptor element ................................................................... 937 Table 9-162â€”Subfields of the HT Capability Information field ................................................................ 942 Table 9-163â€”Subfields of the A-MPDU Parameters field......................................................................... 944 Table 9-164â€”Transmit MCS Set ................................................................................................................ 945 Table 9-165â€”Subfields of the HT Extended Capabilities field.................................................................. 946 Table 9-166â€”Subfields of the Transmit Beamforming Capabilities field.................................................. 947 Table 9-167â€”ASEL Capability field subfields........................................................................................... 950 Table 9-168â€”HT Operation element fields and subfields .......................................................................... 951 Table 9-169â€”Encoding of the Timing Capabilities field ........................................................................... 957 Table 9-170â€”Time Value field format when Timing Capabilities is 2...................................................... 958 Table 9-171â€”Event Type field definitions for event requests and reports................................................. 961 Table 9-172â€”Transition Event Request subelement .................................................................................. 962 Table 9-173â€”RSNA Event Request subelement ....................................................................................... 964 Table 9-174â€”Peer-to-Peer Link Event Request subelement ...................................................................... 966 Table 9-175â€”Event Report Status .............................................................................................................. 968 Table 9-176â€”Transition and Transition Query reasons ............................................................................. 969 Table 9-177â€”Peer Status definitions .......................................................................................................... 972 Table 9-178â€”Diagnostic Request/Report Type definitions ....................................................................... 973 Table 9-179â€”Association Diagnostic request contents .............................................................................. 974 Table 9-180â€”IEEE 802.1X Authentication Diagnostic request contents .................................................. 974 Table 9-181â€”Diagnostic subelement ID values ......................................................................................... 975 Table 9-182â€”Credentials values................................................................................................................. 976 Table 9-183â€”Collocated Radio Type ......................................................................................................... 978 Table 9-184â€”Device Type definitions ....................................................................................................... 978 Table 9-185â€”Power Save Mode definition ................................................................................................ 981 Table 9-186â€”Tx Power Modes .................................................................................................................. 983 Table 9-187â€”Manufacturer Information STA report contents................................................................... 984 Table 9-188â€”Configuration Profile report contents................................................................................... 985 Table 9-189â€”Association Diagnostic report contents ................................................................................ 985 Table 9-190â€”IEEE 802.1X Authentication Diagnostic report contents .................................................... 986 Table 9-191â€”Optional subelement IDs for Location Parameters ............................................................. 986 Table 9-192â€”Report Interval Units field.................................................................................................... 988 Table 9-193â€”Motion Indicator field .......................................................................................................... 991 Table 9-194â€”Speed Units........................................................................................................................... 991 Table 9-195â€”Indication Parameter values ................................................................................................. 993 Table 9-196â€”Optional subelement IDs for FMS Request subelements..................................................... 997 Table 9-197â€”Optional subelement IDs for FMS Response subelements .................................................. 998 Table 9-198â€”FMS Element Status and TFS Response Status definition................................................... 999 Table 9-199â€”QoS Traffic Capability Bitmask/Flags definition .............................................................. 1001 84 Copyright Â© 2016 IEEE. All rights reserved. Table 9-200â€”TFS Action Code field values ............................................................................................ 1002 Table 9-201â€”Optional subelement IDs for TFS Request parameters ...................................................... 1003 Table 9-202â€”Optional subelement IDs for TFS Response parameters.................................................... 1004 Table 9-203â€”Action Type definitions...................................................................................................... 1006 Table 9-204â€”WNM Sleep Mode Response Status definition .................................................................. 1006 Table 9-205â€”Status field values............................................................................................................... 1007 Table 9-206â€”Usage Mode definitions...................................................................................................... 1010 Table 9-207â€”DMS Request Type field .................................................................................................... 1012 Table 9-208â€”Optional subelement IDs for DMS Descriptor................................................................... 1012 Table 9-209â€”GATS Retransmission Policy field values ......................................................................... 1013 Table 9-210â€”GCR Delivery Method field values.................................................................................... 1013 Table 9-211â€”Response Type field values ................................................................................................ 1014 Table 9-212â€”Optional subelement IDs for DMS Status .......................................................................... 1015 Table 9-213â€”Optional subelement IDs for U-APSD coexistence ........................................................... 1017 Table 9-214â€”Access network type........................................................................................................... 1018 Table 9-215â€”Advertisement protocol ID definitions............................................................................... 1020 Table 9-216â€”Precedence Level field description..................................................................................... 1022 Table 9-217â€”Active Path Selection Protocol Identifier field values ....................................................... 1025 Table 9-218â€”Active Path Selection Metric Identifier field values .......................................................... 1025 Table 9-219â€”Congestion Control Mode Identifier field values............................................................... 1026 Table 9-220â€”Synchronization Method Identifier field values ................................................................. 1026 Table 9-221â€”Authentication Protocol Identifier field values .................................................................. 1027 Table 9-222â€”Mesh Peering Protocol Identifier field values .................................................................... 1030 Table 9-223â€”MCCA Reply Code field values......................................................................................... 1035 Table 9-224â€”SCS Request Type definitions............................................................................................ 1050 Table 9-225â€”Optional subelement IDs for SCS Descriptor element....................................................... 1051 Table 9-226â€”Sharing Policy definitions .................................................................................................. 1052 Table 9-227â€”Optional subelement IDs for QLoad Report element......................................................... 1052 Table 9-228â€”Protocol ID definitions ....................................................................................................... 1054 Table 9-229â€”Subfields of the A-MPDU Parameters subfield ................................................................. 1057 Table 9-230â€”Beam Tracking Time Limit negotiation ............................................................................. 1060 Table 9-231â€”Mapping of Extended SC MCS to Maximum Supported Rx/Tx MCS subfield values..... 1061 Table 9-232â€”Maximum Number Of Basic A-MSDU Subframes In A-MSDU subfield ........................ 1062 Table 9-233â€”Maximum Number Of Short A-MSDU Subframes In A-MSDU subfield ........................ 1062 Table 9-234â€”FBCK-REQ field description ............................................................................................. 1065 Table 9-235â€”FBCK-TYPE field description ........................................................................................... 1066 Table 9-236â€”AllocationType subfield values.......................................................................................... 1068 Table 9-237â€”Allocation Format subfield values ..................................................................................... 1071 Table 9-238â€”Allocation Period field values ............................................................................................ 1072 Table 9-239â€”TSCONST Period values ................................................................................................... 1073 Table 9-240â€”Channel Measurement Feedback element format ............................................................ 1074 Table 9-241â€”Channel measurement ........................................................................................................ 1075 Table 9-242â€”STA Role subfield values .................................................................................................. 1077 Table 9-243â€”Activity field values .......................................................................................................... 1081 Table 9-244â€”Session Type subfield values ............................................................................................. 1083 Table 9-245â€”DTP Report element format ............................................................................................... 1084 Table 9-246â€”MMS Element Owner subfield definition .......................................................................... 1090 Table 9-247â€”Single AID subfield definition .......................................................................................... 1091 Table 9-248â€”LLC Header Copy field size............................................................................................... 1092 Table 9-249â€”Subfields of the VHT Capabilities Information field ......................................................... 1096 Table 9-250â€”Setting of the Supported Channel Width Set subfield and Extended NSS BW Support subfield at a STA transmitting the VHT Capabilities Information field ....................... 1099 Table 9-251â€”Supported VHT-MCS and NSS Set subfields .................................................................. 1100 Table 9-252â€”VHT Operation Information subfields ............................................................................... 1103 85 Copyright Â© 2016 IEEE. All rights reserved. Table 9-253â€”BSS bandwidth when the VHT Operation Information field Channel Width subfield is 1.................................................................................................................................. 1104 Table 9-254â€”Meaning of Local Maximum Transmit Power Count subfield .......................................... 1107 Table 9-255â€”Definition of Local Maximum Transmit Power Unit Interpretation subfield .................... 1107 Table 9-256â€”Status Indication field values ............................................................................................. 1112 Table 9-257â€”Burst Duration field encoding ............................................................................................ 1112 Table 9-258â€” Format And Bandwidth field............................................................................................. 1114 Table 9-259â€”TVHT Operation Information subfields............................................................................. 1117 Table 9-260â€”Access Category subfield encoding ................................................................................... 1119 Table 9-261â€”Data Format subfield encoding .......................................................................................... 1119 Table 9-262â€”BA Window Size subfield encoding .................................................................................. 1120 Table 9-263â€”General TLV format ........................................................................................................... 1122 Table 9-264â€”Device Class field definition .............................................................................................. 1123 Table 9-265â€”Device Identification Information field definition ............................................................. 1123 Table 9-266â€”Device Location Information field definition .................................................................... 1123 Table 9-267â€”Channel Schedule Descriptor Tuple attribute definition .................................................... 1124 Table 9-268â€”Channel Schedule Descriptor Value fields ........................................................................ 1124 Table 9-269â€”WSM information values ................................................................................................... 1125 Table 9-270â€”WSM Information Value fields .......................................................................................... 1126 Table 9-271â€”ANQP-element definitions ................................................................................................. 1127 Table 9-272â€”Network Authentication Type Indicator definitions .......................................................... 1131 Table 9-273â€”IPv6 Address field values................................................................................................... 1133 Table 9-274â€”IPv4 Address field values................................................................................................... 1134 Table 9-275â€”Authentication Parameter types.......................................................................................... 1136 Table 9-276â€”Authentication Parameter format for the Expanded EAP method ..................................... 1137 Table 9-277â€”Vendor Specific Authentication Parameters ...................................................................... 1137 Table 9-278â€”Advice of Charge Type field values................................................................................... 1142 Table 9-279â€”Local Content State values ................................................................................................. 1143 Table 9-280â€”RLQP-element definitions.................................................................................................. 1145 Table 9-281â€”Reason Result Code field values ........................................................................................ 1146 Table 9-282â€”Reason Result Code field values ........................................................................................ 1148 Table 9-283â€”Encoding of BeamLink Maintenance Unit Index............................................................... 1154 Table 9-284â€”The Beamformed Link Maintenance negotiation............................................................... 1155 Table 9-285â€”Spectrum Management Action field values ....................................................................... 1155 Table 9-286â€”QoS Action field values ..................................................................................................... 1158 Table 9-287â€”Encoding of the ADDTS Request frame variant................................................................ 1159 Table 9-288â€”Encoding of the ADDTS Response frame variant ............................................................. 1159 Table 9-289â€”Basic ADDTS Request frame variant Action field format................................................. 1159 Table 9-290â€”DMG ADDTS Request frame variant Action field format ............................................... 1160 Table 9-291â€”Basic ADDTS Response frame variant Action field format .............................................. 1162 Table 9-292â€”DMG ADDTS Response frame variant Action field format ............................................. 1163 Table 9-293â€”DELTS frame Action field format ..................................................................................... 1164 Table 9-294â€”Schedule frame Action field format ................................................................................... 1164 Table 9-295â€”QoS Map Configure frame Action field format ................................................................. 1165 Table 9-296â€”ADDTS Reserve Request frame Action field format......................................................... 1165 Table 9-297â€”ADDTS Reserve Response frame Action field format ...................................................... 1166 Table 9-298â€”DLS Action field values ..................................................................................................... 1166 Table 9-299â€”DLS Request frame Action field format ............................................................................ 1167 Table 9-300â€”DLS Response frame Action field format .......................................................................... 1168 Table 9-301â€”DLS Teardown frame Action field format ......................................................................... 1169 Table 9-302â€”Block Ack Action field values ........................................................................................... 1169 Table 9-303â€”ADDBA Request frame Action field format...................................................................... 1170 Table 9-304â€”ADDBA Response frame Action field format ................................................................... 1171 Table 9-305â€”DELBA frame Action field format .................................................................................... 1172 86 Copyright Â© 2016 IEEE. All rights reserved. Table 9-306â€”Radio Measurement Action field values ............................................................................ 1173 Table 9-307â€”Public Action field values .................................................................................................. 1177 Table 9-308â€”20/40 BSS Coexistence Management frame Action field format ...................................... 1178 Table 9-309â€”Optional subelement IDs for Measurement Pilot frame .................................................... 1180 Table 9-310â€”Reason Result Code field values ........................................................................................ 1181 Table 9-311â€”Reason Result Code field values ........................................................................................ 1181 Table 9-312â€”Reason Result Code field values ........................................................................................ 1185 Table 9-313â€”GAS Initial Request Action field format............................................................................ 1186 Table 9-314â€”GAS Initial Response Action field format ......................................................................... 1187 Table 9-315â€”GAS Comeback Request Action field format .................................................................... 1189 Table 9-316â€”GAS Comeback Response Action field format.................................................................. 1189 Table 9-317â€”TDLS Discovery Response Action field format ................................................................ 1190 Table 9-318â€”Location Parameters Element field for Location Track Notification frame....................... 1192 Table 9-319â€”QLoad Request frame Action field format......................................................................... 1193 Table 9-320â€”QLoad Report frame Action field format........................................................................... 1194 Table 9-321â€”Public Key Frame Usage field values ................................................................................ 1196 Table 9-322â€”Reason Result Code field values ....................................................................................... 1198 Table 9-323â€”Channel Schedule Management Mode field values ........................................................... 1198 Table 9-324â€”QAB Request frame Action field format ........................................................................... 1205 Table 9-325â€”QAB Response frame Action field format ......................................................................... 1206 Table 9-326â€”FT Action field values ........................................................................................................ 1206 Table 9-327â€”FT Request frame body ...................................................................................................... 1207 Table 9-328â€”FT Response frame body.................................................................................................... 1208 Table 9-329â€”FT Confirm frame body ..................................................................................................... 1208 Table 9-330â€”FT Ack frame body ............................................................................................................ 1209 Table 9-331â€”SA Query Action field values ............................................................................................ 1210 Table 9-332â€”Public Action field values defined for Protected Dual of Public Action frames................ 1211 Table 9-333â€”HT Action field values ....................................................................................................... 1212 Table 9-334â€”Notify Channel Width frame Action field format .............................................................. 1213 Table 9-335â€”SM Power Save frame Action field format ........................................................................ 1213 Table 9-336â€”PSMP frame Action field format........................................................................................ 1214 Table 9-337â€”Set PCO Phase frame Action field format.......................................................................... 1214 Table 9-338â€”CSI frame Action field format............................................................................................ 1214 Table 9-339â€”Noncompressed Beamforming frame Action field format................................................. 1215 Table 9-340â€”Compressed Beamforming frame Action field format....................................................... 1215 Table 9-341â€”Antenna Selection Indices Feedback frame Action field format........................................ 1216 Table 9-342â€”TDLS Action field values................................................................................................... 1216 Table 9-343â€”Information for TDLS Setup Request Action field ............................................................ 1217 Table 9-344â€”Information for TDLS Setup Response Action field.......................................................... 1218 Table 9-345â€”Information for TDLS Setup Confirm Action field ........................................................... 1220 Table 9-346â€”Information for TDLS Teardown Action field................................................................... 1221 Table 9-347â€”Information for TDLS Peer Traffic Indication Action field............................................... 1221 Table 9-348â€”Information for TDLS Channel Switch Request Action field............................................ 1222 Table 9-349â€”Information for TDLS Channel Switch Response Action field ......................................... 1223 Table 9-350â€”Information for TDLS Peer PSM Request Action field ..................................................... 1223 Table 9-351â€”Information for TDLS Peer PSM Response Action field................................................... 1223 Table 9-352â€”Information for TDLS Peer Traffic Response Action field................................................ 1224 Table 9-353â€”Information for TDLS Discovery Request Action field..................................................... 1225 Table 9-354â€”WNM Action field values .................................................................................................. 1225 Table 9-355â€”Location Parameters Element field for Location Configuration Request frame................ 1228 Table 9-356â€”Location Parameters Element field for Location Configuration Response frame ............. 1229 Table 9-357â€”BTM status code definitions............................................................................................... 1233 Table 9-358â€”Optional subelement IDs for WNM Sleep Mode parameters ............................................ 1239 Table 9-359â€”QoS Traffic Capability Flags definition ............................................................................. 1241 87 Copyright Â© 2016 IEEE. All rights reserved. Table 9-360â€”WNM notification type ...................................................................................................... 1244 Table 9-361â€”Optional subelement IDs for WNM Notification Request ................................................. 1245 Table 9-362â€”WNM Notification Response Status .................................................................................. 1245 Table 9-363â€”Unprotected WNM Action field values.............................................................................. 1246 Table 9-364â€”Self-protected Action field values ...................................................................................... 1248 Table 9-365â€”Mesh Peering Open frame Action field format .................................................................. 1248 Table 9-366â€”Mesh Peering Confirm frame Action field format ............................................................. 1250 Table 9-367â€”Mesh Peering Close frame Action field format.................................................................. 1251 Table 9-368â€”Mesh Group Key Inform frame Action field format .......................................................... 1252 Table 9-369â€”Mesh Group Key Acknowledge frame Action field format............................................... 1252 Table 9-370â€”Mesh Action field values.................................................................................................... 1253 Table 9-371â€”Mesh Link Metric Report frame Action field format......................................................... 1253 Table 9-372â€”HWMP Mesh Path Selection frame Action field format ................................................... 1254 Table 9-373â€”Gate Announcement frame Action field format................................................................. 1255 Table 9-374â€”Congestion Control Notification frame Action field format .............................................. 1255 Table 9-375â€”MCCA Setup Request frame Action field format .............................................................. 1256 Table 9-376â€”MCCA Setup Reply frame Action field format ................................................................. 1256 Table 9-377â€”MCCA Advertisement Request frame Action field format................................................ 1256 Table 9-378â€”MCCA Advertisement frame Action field format ............................................................. 1257 Table 9-379â€”MCCA Teardown frame Action field format..................................................................... 1257 Table 9-380â€”TBTT Adjustment Request frame Action field format ...................................................... 1258 Table 9-381â€”TBTT Adjustment Response frame Action field format.................................................... 1258 Table 9-382â€”Multihop Action field values.............................................................................................. 1259 Table 9-383â€”Proxy Update frame Action field format............................................................................ 1259 Table 9-384â€”Proxy Update Confirmation frame Action field format ..................................................... 1260 Table 9-385â€”Robust AV streaming Robust Action field values ............................................................. 1260 Table 9-386â€”DMG Action field values .................................................................................................. 1263 Table 9-387â€”Power Save Configuration Request frame Action field format ......................................... 1264 Table 9-388â€”Power Save Configuration Response frame Action field format ....................................... 1264 Table 9-389â€”Information Request frame Action field format................................................................. 1265 Table 9-390â€”Information Response frame Action field format .............................................................. 1266 Table 9-391â€”Handover Request frame Action field format .................................................................... 1266 Table 9-392â€”Handover Response frame Action field format.................................................................. 1267 Table 9-393â€”Relay Search Request frame Action field format............................................................... 1268 Table 9-394â€”Relay Search Response frame Action field format ........................................................... 1269 Table 9-395â€”Multi-relay Channel Measurement Request frame Action field format............................. 1269 Table 9-396â€”Multi-relay Channel Measurement Report frame Action field format............................... 1270 Table 9-397â€”RLS Request frame Action field format ............................................................................ 1271 Table 9-398â€”RLS Response frame Action field format .......................................................................... 1272 Table 9-399â€”RLS Announcement frame Action field format ................................................................. 1273 Table 9-400â€”RLS Teardown frame Action field format ......................................................................... 1273 Table 9-401â€”Relay Ack Request frame Action field format .................................................................. 1274 Table 9-402â€”Relay Ack Response frame Action field format................................................................. 1274 Table 9-403â€”TPA Request frame Action field format ............................................................................ 1275 Table 9-404â€”TPA Response frame Action field format .......................................................................... 1276 Table 9-405â€”TPA Report frame Action field format .............................................................................. 1276 Table 9-406â€”ROC Request frame Action field format............................................................................ 1277 Table 9-407â€”ROC Response frame Action field format ......................................................................... 1277 Table 9-408â€”FST Action field values...................................................................................................... 1278 Table 9-409â€”FST Setup Request frame Action field format .................................................................. 1278 Table 9-410â€”FST Setup Response frame Action field format ................................................................ 1279 Table 9-411â€”FST Teardown frame Action field format.......................................................................... 1280 Table 9-412â€”FST Ack Request frame Action field format ..................................................................... 1281 Table 9-413â€”FST Ack Response frame Action field format ................................................................... 1281 88 Copyright Â© 2016 IEEE. All rights reserved. Table 9-414â€”On-channel Tunnel Request frame Action field format ..................................................... 1282 Table 9-415â€”Unprotected DMG Action field values .............................................................................. 1283 Table 9-416â€”Announce frame Action field format ................................................................................ 1283 Table 9-417â€”BRP frame Action field format .......................................................................................... 1284 Table 9-418â€”VHT Action field values .................................................................................................... 1285 Table 9-419â€”VHT Compressed Beamforming frame Action field format.............................................. 1286 Table 9-420â€”Group ID Management frame Action field format............................................................. 1286 Table 9-421â€”Operating Mode Notification frame Action field format ................................................... 1287 Table 9-422â€” MPDU delimiter fields (non-DMG).................................................................................. 1289 Table 9-423â€”MPDU delimiter fields (DMG) .......................................................................................... 1289 Table 9-424â€”A-MPDU contexts .............................................................................................................. 1291 Table 9-425â€”A-MPDU contents in the data enabled immediate response context ................................. 1292 Table 9-426â€”A-MPDU contents in the data enabled no immediate response context ............................ 1293 Table 9-427â€”A-MPDU contents in the PSMP context ............................................................................ 1293 Table 9-428â€”A-MPDU contents MPDUs in the control response context.............................................. 1294 Table 9-429â€”A-MPDU contents in the VHT single MPDU context....................................................... 1294 Table 10-1â€”UP-to-AC mappings ............................................................................................................. 1298 Table 10-2â€”Dual CTS rules ..................................................................................................................... 1314 Table 10-3â€”Transmitter sequence number spaces ................................................................................... 1319 Table 10-4â€”Receiver caches .................................................................................................................. 1321 Table 10-5â€”Determination of the EstimatedAckTxTime based on properties of the PPDU causing the EIFS ......................................................................................................................... 1333 Table 10-6â€”Modulation classes .............................................................................................................. 1359 Table 10-7â€”Non-HT reference rate.......................................................................................................... 1360 Table 10-8â€”Example of rate selection for VHT PPDUs.......................................................................... 1362 Table 10-9â€”Settings for the TXVECTOR parameters GROUP_ID and PARTIAL_AID ...................... 1374 Table 10-10â€”Channels indicated idle by the channel-list parameter ....................................................... 1383 Table 10-11â€”Modulation classes eligible for TXOP termination............................................................ 1389 Table 10-12â€”Rate and modulation class of a final transmission in a TXOP ........................................... 1390 Table 10-13â€”Protection requirements for HT Protection field values nonmember protection mode and non-HT mixed mode ............................................................................................... 1441 Table 10-14â€”Applicable HT protection mechanisms .............................................................................. 1442 Table 10-15â€”STA type requirements for transmit beamforming with implicit feedback ....................... 1469 Table 10-16â€”Transmit beamforming support required with implicit feedback....................................... 1470 Table 10-17â€”Rules for HT beamformee immediate feedback transmission responding to non-NDP sounding ........................................................................................................ 1479 Table 10-18â€”Rules for HT beamformee immediate feedback transmission responding to NDP sounding................................................................................................................ 1479 Table 10-19â€”Mandatory and optional procedures in the Beamforming mechanism .............................. 1534 Table 11-1â€”Bufferable/nonbufferable classification of MMPDUs ......................................................... 1600 Table 11-2â€”Power states for an awake BI .............................................................................................. 1631 Table 11-3â€”Power states for a doze BI .................................................................................................... 1632 Table 11-4â€”Types of block ack agreement based on capabilities and ADDBA conditions for non-DMG STAs............................................................................................................. 1681 Table 11-5â€”Types of block ack agreement based on capabilities and ADDBA conditions for DMG STAs .................................................................................................................... 1682 Table 11-6â€”ReasonCode values for DLS teardown ................................................................................ 1689 Table 11-7â€”Allowed measurement requests............................................................................................ 1698 Table 11-8â€”Measurement Duration ......................................................................................................... 1710 Table 11-9â€”Allowed measurement requests............................................................................................ 1712 Table 11-10â€”Measurement pilot activated definition .............................................................................. 1735 Table 11-11â€”DSE STA attributes ............................................................................................................ 1740 Table 11-12â€”A-MSDU STA behavior for RSN associations ................................................................. 1763 Table 11-13â€”STA recovery procedures for a changed retransmission policy ........................................ 1820 89 Copyright Â© 2016 IEEE. All rights reserved. Table 11-14â€”Non-AP STA recovery procedures for a changed delivery method................................... 1821 Table 11-15â€”ANQP usage ....................................................................................................................... 1833 Table 11-16â€”ESR and UESA field settings ............................................................................................. 1841 Table 11-17â€”Default QMF policy .......................................................................................................... 1845 Table 11-18â€”QMF policy description for valid combination of optional fields in the QACM field ...... 1851 Table 11-19â€”Contents of HCCA TXOP Response frame ....................................................................... 1859 Table 11-20â€”Exceptions for the initiator ................................................................................................ 1878 Table 11-21â€”FST status at state transition............................................................................................... 1880 Table 11-22â€”Setting of Single AID field................................................................................................. 1887 Table 11-23â€”DMG MAC sublayer attribute values ................................................................................ 1896 Table 11-24â€”VHT BSS bandwidth.......................................................................................................... 1897 Table 11-25â€”Setting of Channel Center Frequency Segment 0, Channel Center Frequency Segment 1, and Channel Center Frequency Segment 2 subfields ................................. 1898 Table 11-26â€”Extended NSS channel width ............................................................................................. 1899 Table 11-27â€”TVHT BSS bandwidth ....................................................................................................... 1907 Table 12-1â€”AAD length .......................................................................................................................... 1970 Table 12-2â€”Robust management frame selection in an infrastructure BSS ............................................ 1992 Table 12-3â€”Robust management frame selection in an IBSS ................................................................. 1994 Table 12-4â€”Cipher suite key lengths ....................................................................................................... 2021 Table 12-5â€”Key RSC field ...................................................................................................................... 2022 Table 12-6â€”KDE...................................................................................................................................... 2023 Table 12-7â€”SMK error types ................................................................................................................... 2025 Table 12-8â€”Integrity and key-wrap algorithms ....................................................................................... 2027 Table 13-1â€”FT authentication elements .................................................................................................. 2110 Table 13-2â€”Remote Request/Response Payload format.......................................................................... 2126 Table 13-3â€”Resource types and resource descriptor definitions ............................................................. 2127 Table 14-1â€”State variables for mesh STAs ............................................................................................. 2137 Table 14-2â€”MPM finite state machine .................................................................................................... 2144 Table 14-3â€”AMPE finite state machine................................................................................................... 2155 Table 14-4â€”Airtime cost constants .......................................................................................................... 2162 Table 14-5â€”Parameters of the airtime link metric for extensible path selection framework................... 2163 Table 14-6â€”Precursor and next hop examples (forward path)................................................................. 2165 Table 14-7â€”Precursor and next hop examples (reverse path).................................................................. 2166 Table 14-8â€”Parameters of HWMP for extensible path selection framework .......................................... 2168 Table 14-9â€”Data for creation and update of forwarding information due to PREQ element and PREP element ................................................................................................................ 2172 Table 14-10â€”Contents of a PREQ element in Case A ............................................................................. 2174 Table 14-11â€”Contents of a PREQ element in Case B ............................................................................. 2175 Table 14-12â€”Contents of a PREQ element in Case C ............................................................................. 2176 Table 14-13â€”Contents of a PREQ element in Case D ............................................................................. 2177 Table 14-14â€”Contents of a PREQ element in Case E1 ........................................................................... 2178 Table 14-15â€”Contents of a PREQ element in Case E2 ........................................................................... 2179 Table 14-16â€”Contents of a PREQ element in Case E3 ........................................................................... 2180 Table 14-17â€”Contents of a PREP element in Case A.............................................................................. 2184 Table 14-18â€”Contents of a PREP element in Case B .............................................................................. 2184 Table 14-19â€”Contents of a PREP element in Case C .............................................................................. 2185 Table 14-20â€”Contents of a PREP element in Case D.............................................................................. 2186 Table 14-21â€”Contents of a PERR element in Case A ............................................................................. 2188 Table 14-22â€”Contents of a PERR element in Case B ............................................................................. 2189 Table 14-23â€”Contents of a PERR element in Case C ............................................................................. 2190 Table 14-24â€”Contents of a PERR element in Case D ............................................................................. 2191 Table 14-25â€”Contents of a RANN element in Case A ............................................................................ 2193 Table 14-26â€”Contents of a RANN element in Case B ............................................................................ 2194 Table 14-27â€”Contents of a GANN element in Case A............................................................................ 2197 90 Copyright Â© 2016 IEEE. All rights reserved. Table 14-28â€”Contents of a GANN element in Case B ............................................................................ 2197 Table 14-29â€”Contents of a PXU element ................................................................................................ 2202 Table 14-30â€”Contents of a PXUC element ............................................................................................. 2203 Table 14-31â€”Peer-specific mesh power management mode definition................................................... 2216 Table 14-32â€”Mesh peer service period triggering with RSPI and EOSP subfield combinations in peer trigger frame........................................................................................................... 2222 Table 15-1â€”TXVECTOR parameters ...................................................................................................... 2225 Table 15-2â€”RXVECTOR parameters ...................................................................................................... 2226 Table 15-3â€”TXSTATUS parameters ....................................................................................................... 2228 Table 15-4â€”MIB attribute default values/ranges .................................................................................... 2237 Table 15-5â€”DSSS PHY characteristics.................................................................................................... 2238 Table 15-6â€”DSSS PHY frequency channel plan ..................................................................................... 2239 Table 15-7â€”1 Mb/s DBPSK encoding table ............................................................................................ 2239 Table 15-8â€”2 Mb/s DQPSK encoding table ............................................................................................ 2240 Table 16-1â€”SERVICE field definitions ................................................................................................... 2251 Table 16-2â€”Example of LENGTH calculations for CCK ....................................................................... 2253 Table 16-3â€”MIB attribute default values/ranges ..................................................................................... 2262 Table 16-4â€”HR/DSSS PHY characteristics ............................................................................................. 2263 Table 16-5â€”Parameter vectors ................................................................................................................. 2264 Table 16-6â€”HR/DSSS PHY frequency channel plan .............................................................................. 2265 Table 16-7â€”1 Mb/s DBPSK encoding table ............................................................................................ 2266 Table 16-8â€”2 Mb/s DQPSK encoding table ............................................................................................ 2267 Table 16-9â€”DQPSK encoding table ........................................................................................................ 2268 Table 16-10â€”5.5 Mb/s CCK encoding table ............................................................................................ 2268 Table 16-11â€”QPSK encoding table ......................................................................................................... 2269 Table 17-1â€”TXVECTOR parameters ...................................................................................................... 2278 Table 17-2â€”RXVECTOR parameters ...................................................................................................... 2280 Table 17-3â€”TXSTATUS parameters ....................................................................................................... 2282 Table 17-4â€”Modulation-dependent parameters ....................................................................................... 2285 Table 17-5â€”Timing-related parameters ................................................................................................... 2285 Table 17-6â€”Contents of the SIGNAL field.............................................................................................. 2290 Table 17-7â€”Contents of the first 7 bits of the scrambling sequence........................................................ 2293 Table 17-8â€”TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT values ................................... 2294 Table 17-9â€”RXVECTOR parameter CH_BANDWIDTH_IN_NON_HT values................................... 2294 Table 17-10â€”DYN_BANDWIDTH_IN_NON_HT values ..................................................................... 2294 Table 17-11â€”Modulation-dependent normalization factor KMOD ........................................................... 2298 Table 17-12â€”BPSK encoding table.......................................................................................................... 2300 Table 17-13â€”QPSK encoding table ......................................................................................................... 2300 Table 17-14â€”16-QAM encoding table ..................................................................................................... 2300 Table 17-15â€”64-QAM encoding table ..................................................................................................... 2300 Table 17-16â€”Major parameters of the OFDM PHY ................................................................................ 2303 Table 17-17â€”Allowed relative constellation error versus data rate ......................................................... 2308 Table 17-18â€”Receiver performance requirements................................................................................... 2310 Table 17-19â€”Optional enhanced receiver performance requirements ..................................................... 2311 Table 17-20â€”MIB attribute default values/ranges ................................................................................... 2318 Table 17-21â€”OFDM PHY characteristics................................................................................................ 2321 Table 18-1â€”TXVECTOR parameters ...................................................................................................... 2324 Table 18-2â€”TXSTATUS parameters ....................................................................................................... 2324 Table 18-3â€”RXVECTOR parameters ...................................................................................................... 2325 Table 18-4â€”MIB attribute default values/ranges ..................................................................................... 2330 Table 18-5â€”ERP characteristics............................................................................................................... 2332 Table 19-1â€”TXVECTOR and RXVECTOR parameters......................................................................... 2336 Table 19-2â€”Interpretation of FORMAT, CH_BANDWIDTH, and CH_OFFSET parameters .............. 2343 Table 19-3â€”Mapping of the HT PHY parameters for NON_HT operation............................................. 2344 91 Copyright Â© 2016 IEEE. All rights reserved. Table 19-4â€”TXSTATUS parameter......................................................................................................... 2346 Table 19-5â€”Elements of the HT PPDU ................................................................................................... 2347 Table 19-6â€”Timing-related constants ...................................................................................................... 2354 Table 19-7â€”Frequently used parameters.................................................................................................. 2355 Table 19-8â€”Value of tone scaling factor ................................................................................................. 2358 Table 19-9â€”Cyclic shift for non-HT portion of packet............................................................................ 2360 Table 19-10â€”Cyclic shift values of HT portion of packet ....................................................................... 2363 Table 19-11â€”HT-SIG fields ..................................................................................................................... 2364 Table 19-12â€”Determining the number of space-time streams................................................................. 2369 Table 19-13â€”Number of HT-DLTFs required for data space-time streams ............................................ 2369 Table 19-14â€”Number of HT-ELTFs required for extension spatial streams........................................... 2370 Table 19-15â€”LDPC parameters ............................................................................................................... 2378 Table 19-16â€”PPDU encoding parameters................................................................................................ 2379 Table 19-17â€”Number of rows and columns in the interleaver ................................................................ 2383 Table 19-18â€”Constellation mapper output to spatial mapper input for STBC ........................................ 2385 Table 19-19â€”Pilot values for 20 MHz transmission ................................................................................ 2386 Table 19-20â€”Pilots values for 40 MHz transmission (excluding MCS 32)............................................. 2386 Table 19-21â€”Maximum available space-time streams ............................................................................ 2402 Table 19-22â€”Allowed relative constellation error versus constellation size and coding rate.................. 2408 Table 19-23â€”Receiver minimum input level sensitivity.......................................................................... 2410 Table 19-24â€”HT PHY MIB attributes ..................................................................................................... 2420 Table 19-25â€”HT PHY characteristics...................................................................................................... 2425 Table 19-26â€”Symbols used in MCS parameter tables............................................................................. 2427 Table 19-27â€”MCS parameters for mandatory 20 MHz, NSS = 1, NES = 1 ............................................. 2427 Table 19-28â€”MCS parameters for optional 20 MHz, NSS = 2, NES = 1, EQM....................................... 2428 Table 19-29â€”MCS parameters for optional 20 MHz, NSS = 3, NES = 1, EQM....................................... 2428 Table 19-30â€”MCS parameters for optional 20 MHz, NSS = 4, NES = 1, EQM....................................... 2429 Table 19-31â€”MCS parameters for optional 40 MHz, NSS = 1, NES = 1 ................................................. 2429 Table 19-32â€”MCS parameters for optional 40 MHz, NSS = 2, NES = 1, EQM....................................... 2430 Table 19-33â€”MCS parameters for optional 40 MHz, NSS = 3, EQM ..................................................... 2430 Table 19-34â€”MCS parameters for optional 40 MHz, NSS = 4, EQM ..................................................... 2431 Table 19-35â€”MCS parameters for optional 40 MHz MCS 32 format, NSS = 1, NES = 1 ....................... 2431 Table 19-36â€”MCS parameters for optional 20 MHz, NSS = 2, NES = 1, UEQM.................................... 2431 Table 19-37â€”MCS parameters for optional 20 MHz, NSS = 3, NES = 1, UEQM.................................... 2432 Table 19-38â€”MCS parameters for optional 20 MHz, NSS = 4, NES = 1, UEQM.................................... 2432 Table 19-39â€”MCS parameters for optional 40 MHz, NSS = 2, NES = 1, UEQM.................................... 2433 Table 19-40â€”MCS parameters for optional 40 MHz, NSS = 3, UEQM................................................... 2434 Table 19-41â€”MCS parameters for optional 40 MHz, NSS = 4, UEQM................................................... 2434 Table 20-1â€”TXVECTOR and RXVECTOR parameters ........................................................................ 2437 Table 20-2â€”TXSTATUS parameters ....................................................................................................... 2439 Table 20-3â€”Receiver sensitivity .............................................................................................................. 2441 Table 20-4â€”Timing-related parameters ................................................................................................... 2443 Table 20-5â€”Frequently used parameters.................................................................................................. 2444 Table 20-6â€”Rate 1/2 LDPC code matrix (Each nonblank element i in the table is the cyclic permutation matrix Pi of size Z Ã— Z; blank entries represent the zero matrix of size Z Ã— Z) ................................................................................................................. 2450 Table 20-7â€”Rate 5/8 LDPC code matrix (Each nonblank element i in the table is the cyclic permutation matrix Pi of size Z Ã— Z; blank entries represent the zero matrix of size Z Ã— Z) ................................................................................................................. 2450 Table 20-8â€”Rate 3/4 LDPC code matrix (Each nonblank element i in the table is the cyclic permutation matrix Pi of size Z Ã— Z; blank entries represent the zero matrix of size Z Ã— Z) ................................................................................................................. 2450 92 Copyright Â© 2016 IEEE. All rights reserved. Table 20-9â€”Rate 13/16 LDPC code matrix (Each nonblank element i in the table is the cyclic permutation matrix Pi of size Z Ã— Z; blank entries represent the zero matrix of size Z Ã— Z) ................................................................................................................. 2451 Table 20-10â€”DMG control mode modulation and coding scheme.......................................................... 2452 Table 20-11â€”DMG control mode header fields ....................................................................................... 2453 Table 20-12â€”DMG control mode EVM requirements............................................................................. 2456 Table 20-13â€”DMG OFDM mode header fields ...................................................................................... 2457 Table 20-14â€”DMG OFDM mode modulation and coding schemes ....................................................... 2459 Table 20-15â€”LDPC code rates................................................................................................................. 2460 Table 20-16â€”DMG OFDM mode EVM requirements ........................................................................... 2467 Table 20-17â€”DMG SC mode header fields ............................................................................................ 2469 Table 20-18â€”Parameters for computing Length field value in SC header when Extended SC MCS Indication field is set to 1............................................................................................... 2471 Table 20-19â€”DMG SC mode modulation and coding schemes .............................................................. 2471 Table 20-20â€”LDPC code rates................................................................................................................. 2473 Table 20-21â€”Values of NCBPB .............................................................................................................. 2478 Table 20-22â€”DMG SC mode EVM requirements ................................................................................... 2479 Table 20-23â€”DMG low-power SC mode modulation and coding schemes ............................................ 2481 Table 20-24â€”Zero filling for DMG SC mode BRP packets .................................................................... 2491 Table 20-25â€”The sequence Ga128(n)...................................................................................................... 2493 Table 20-26â€”The sequence Gb128(n)...................................................................................................... 2493 Table 20-27â€”The sequence Ga64(n)........................................................................................................ 2493 Table 20-28â€”The sequence Gb64(n)........................................................................................................ 2493 Table 20-29â€”The sequence Ga32(n)........................................................................................................ 2493 Table 20-30â€”The sequence Gb32(n)........................................................................................................ 2493 Table 20-31â€”DMG PHY MIB attribute default values ........................................................................... 2494 Table 20-32â€”DMG PHY characteristics.................................................................................................. 2495 Table 21-1â€”TXVECTOR and RXVECTOR parameters ........................................................................ 2499 Table 21-2â€”Interpretation of FORMAT, NON_HT_MODULATION, CH_BANDWIDTH, and CH_OFFSET parameters .............................................................................................. 2508 Table 21-3â€”Mapping of VHT PHY parameters for NON_HT operation................................................ 2512 Table 21-4â€”Fields of the VHT PPDU...................................................................................................... 2514 Table 21-5â€”Timing-related constants ...................................................................................................... 2528 Table 21-6â€”Frequently used parameters ................................................................................................. 2529 Table 21-7â€”Center frequency of the portion of the PPDU transmitted in frequency segment iSeg ....... 2534 Table 21-8â€”Tone scaling factor and guard interval duration values for PHY fields ............................... 2536 Table 21-9â€”CH_BANDWIDTH and ...................................................................................................... 2537 Table 21-10â€”Cyclic shift values for L-STF, L-LTF, L-SIG, and VHT-SIG-A fields of the PPDU........ 2538 Table 21-11â€”Cyclic shift values for the VHT modulated fields of a PPDU ........................................... 2542 Table 21-12â€”Fields in the VHT-SIG-A field .......................................................................................... 2544 Table 21-13â€”Number of VHT-LTFs required for different numbers of space-time streams .................. 2548 Table 21-14â€”Fields in the VHT-SIG-B field ........................................................................................... 2552 Table 21-15â€”VHT-SIG-B bits (before Tail field) in NDP for various channel widths ........................... 2553 Table 21-16â€”SERVICE field ................................................................................................................... 2557 Table 21-17â€”Number of rows and columns in the interleaver ................................................................ 2564 Table 21-18â€” J(iSS) values ...................................................................................................................... 2565 Table 21-19â€”LDPC tone mapping distance for each bandwidth ............................................................. 2571 Table 21-20â€”Constellation mapper output to spatial mapper input for STBC ....................................... 2573 Table 21-21â€”Pilot values for 80 MHz transmission ................................................................................ 2575 Table 21-22â€”Fields to specify VHT channels ......................................................................................... 2581 Table 21-23â€”Maximum transmit spectral flatness deviations ................................................................. 2586 Table 21-24â€”Allowed relative constellation error versus constellation size and coding rate.................. 2588 Table 21-25â€”Receiver minimum input level sensitivity.......................................................................... 2591 Table 21-26â€”Minimum required adjacent and nonadjacent channel rejection levels.............................. 2592 93 Copyright Â© 2016 IEEE. All rights reserved. Table 21-27â€”Conditions for CCA BUSY on the primary 20 MHz ......................................................... 2594 Table 21-28â€”VHT PHY MIB attributes ................................................................................................. 2603 Table 21-29â€”VHT PHY characteristics ................................................................................................... 2607 Table 21-30â€”VHT-MCSs for mandatory 20 MHz, NSS = 1 ................................................................... 2608 Table 21-31â€”VHT-MCSs for optional 20 MHz, NSS = 2 ....................................................................... 2609 Table 21-32â€”VHT-MCSs for optional 20 MHz, NSS = 3 ....................................................................... 2609 Table 21-33â€”VHT-MCSs for optional 20 MHz, NSS = 4 ....................................................................... 2610 Table 21-34â€”VHT-MCSs for optional 20 MHz, NSS = 5 ....................................................................... 2610 Table 21-35â€”VHT-MCSs for optional 20 MHz, NSS = 6 ....................................................................... 2611 Table 21-36â€”VHT-MCSs for optional 20 MHz, NSS = 7 ....................................................................... 2611 Table 21-37â€”VHT-MCSs for optional 20 MHz, NSS = 8 ....................................................................... 2612 Table 21-38â€”VHT-MCSs for mandatory 40 MHz, NSS = 1 ................................................................... 2612 Table 21-39â€”VHT-MCSs for optional 40 MHz, NSS = 2 ....................................................................... 2613 Table 21-40â€”VHT-MCSs for optional 40 MHz, NSS = 3 ....................................................................... 2613 Table 21-41â€”VHT-MCSs for optional 40 MHz, NSS = 4 ....................................................................... 2614 Table 21-42â€”VHT-MCSs for optional 40 MHz, NSS = 5 ....................................................................... 2614 Table 21-43â€”VHT-MCSs for optional 40 MHz, NSS = 6 ....................................................................... 2615 Table 21-44â€”VHT-MCSs for optional 40 MHz, NSS = 7 ....................................................................... 2615 Table 21-45â€”VHT-MCSs for optional 40 MHz, NSS = 8 ....................................................................... 2616 Table 21-46â€”VHT-MCSs for mandatory 80 MHz, NSS = 1 ................................................................... 2616 Table 21-47â€”VHT-MCSs for optional 80 MHz, NSS = 2 ....................................................................... 2617 Table 21-48â€”VHT-MCSs for optional 80 MHz, NSS = 3 ....................................................................... 2617 Table 21-49â€”VHT-MCSs for optional 80 MHz, NSS = 4 ....................................................................... 2618 Table 21-50â€”VHT-MCSs for optional 80 MHz, NSS = 5 ....................................................................... 2618 Table 21-51â€”VHT-MCSs for optional 80 MHz, NSS = 6 ....................................................................... 2619 Table 21-52â€”VHT-MCSs for optional 80 MHz, NSS = 7 ....................................................................... 2619 Table 21-53â€”VHT-MCSs for optional 80 MHz, NSS = 8 ....................................................................... 2620 Table 21-54â€”VHT-MCSs for optional 160 MHz and 80+80 MHz, NSS = 1.......................................... 2620 Table 21-55â€”VHT-MCSs for optional 160 MHz and 80+80 MHz, NSS = 2.......................................... 2621 Table 21-56â€”VHT-MCSs for optional 160 MHz and 80+80 MHz, NSS = 3.......................................... 2621 Table 21-57â€”VHT-MCSs for optional 160 MHz and 80+80 MHz, NSS = 4.......................................... 2622 Table 21-58â€”VHT-MCSs for optional 160 MHz and 80+80 MHz, NSS = 5.......................................... 2622 Table 21-59â€”VHT-MCSs for optional 160 MHz and 80+80 MHz, NSS = 6.......................................... 2623 Table 21-60â€”VHT-MCSs for optional 160 MHz and 80+80 MHz, NSS = 7.......................................... 2623 Table 21-61â€”VHT-MCSs for optional 160 MHz and 80+80 MHz, NSS = 8.......................................... 2624 Table 22-1â€”TXVECTOR and RXVECTOR parameters ........................................................................ 2628 Table 22-2â€”PPDU format as a function of CH_BANDWIDTH parameter ........................................... 2634 Table 22-3â€”Modulation-dependent parameters for Non-HT duplicate mode in TVWS band ................ 2635 Table 22-4â€”RATE field in L-SIG ............................................................................................................ 2635 Table 22-5â€”Timing-related constants in Non-HT PPDU ........................................................................ 2636 Table 22-6â€”Tone location in Non-HT PPDU .......................................................................................... 2637 Table 22-7â€”Fields of the VHT PPDU in TVWS bands........................................................................... 2638 Table 22-8â€”Timing-related parameters ................................................................................................... 2643 Table 22-9â€”Tone location ........................................................................................................................ 2643 Table 22-10â€”Center frequency of a PPDU transmitted in frequency segment iSeg ............................... 2646 Table 22-11â€”Tone scaling factor and guard interval duration values for PHY fields ............................. 2647 Table 22-12â€”Transmission mode and Gamma subk,m ........................................................................... 2647 Table 22-13â€”B0-B1 (BW) in TVHT-SIG-A1 ......................................................................................... 2649 Table 22-14â€”Number of rows and columns in the interleaver ................................................................ 2652 Table 22-15â€”LDPC Tone Mapping Distance for each transmission mode ............................................. 2652 Table 22-16â€”Parameters for Non-HT duplicate transmissions................................................................ 2654 Table 22-17â€”Fields to specify TVHT channels ....................................................................................... 2655 Table 22-18â€”Spectral mask frequency scaling factor for contiguous transmission ................................ 2657 Table 22-19â€”Spectral mask frequency scaling factor for TVHT_MODE_4N........................................ 2657 94 Copyright Â© 2016 IEEE. All rights reserved. Table 22-20â€”Spectral mask frequency scaling factor for TVHT_MODE_2N........................................ 2658 Table 22-21â€”Maximum transmit spectral flatness deviations ................................................................. 2659 Table 22-22â€”Receiver minimum input level sensitivity.......................................................................... 2661 Table 22-23â€”Minimum required adjacent and nonadjacent channel rejection levels.............................. 2662 Table 22-24â€”Conditions for CCA BUSY on the primary channel .......................................................... 2663 Table 22-25â€”TVHT PHY characteristics ................................................................................................ 2665 Table 22-26â€”TVHT MCSs for TVHT_MODE_1, NSS = 1.................................................................... 2666 Table 22-27â€”TVHT MCSs for TVHT_MODE_1, NSS = 2.................................................................... 2667 Table 22-28â€”TVHT MCSs for TVHT_MODE_1, NSS = 3.................................................................... 2667 Table 22-29â€”TVHT MCSs for TVHT_MODE_1, NSS = 4.................................................................... 2668 Table 22-30â€”TVHT MCSs for TVHT_MODE_2C and TVHT_MODE_2N, NSS = 1 .......................... 2668 Table 22-31â€”TVHT MCSs for TVHT_MODE_2C and TVHT_MODE_2N, NSS = 2 .......................... 2669 Table 22-32â€”TVHT MCSs for TVHT_MODE_2C and TVHT_MODE_2N, NSS = 3 .......................... 2669 Table 22-33â€”TVHT MCSs for TVHT_MODE_2C and TVHT_MODE_2N, NSS = 4 .......................... 2670 Table 22-34â€”TVHT MCSs for TVHT_MODE_4C and TVHT_MODE_4N, NSS = 1 .......................... 2670 Table 22-35â€”TVHT MCSs for TVHT_MODE_4C and TVHT_MODE_4N, NSS = 2 .......................... 2671 Table 22-36â€”TVHT MCSs for TVHT_MODE_4C and TVHT_MODE_4N, NSS = 3 .......................... 2671 Table 22-37â€”TVHT MCSs for TVHT_MODE_4C and TVHT_MODE_4N, NSS = 4 .......................... 2672 Table D-1â€”Regulatory requirement list ................................................................................................... 3269 Table D-2â€”Behavior limits ..................................................................................................................... 3270 Table D-3â€”Maximum STA transmit power classification for the 5.85â€“5.925 GHz band in the United States .................................................................................................................. 3271 Table D-4â€”Spectrum mask data for 5 MHz channel spacing .................................................................. 3272 Table D-5â€”Spectrum mask data for 10 MHz channel spacing ................................................................ 3272 Table D-6â€”Spectrum mask data for 20 MHz channel spacing ................................................................ 3273 Table E-1â€”Operating classes in the United States ................................................................................... 3276 Table E-2â€”Operating classes in Europe................................................................................................... 3278 Table E-3â€”Operating classes in Japan ..................................................................................................... 3279 Table E-4â€”Global operating classes ........................................................................................................ 3283 Table E-5â€”Operating classes in China .................................................................................................... 3286 Table E-6â€”DSE timer limits .................................................................................................................... 3288 Table E-7â€”TVWS GDD timer limits ....................................................................................................... 3290 Table E-8â€”Device Identification Information Value fields ..................................................................... 3290 Table E-9â€”WSM Information Value fields ............................................................................................. 3291 Table E-10â€”TVWS GDD timer limits ..................................................................................................... 3292 Table F-1â€”Matrix prototypes for codeword block length n = 648 bits, subblock size is Z = 27 bits...... 3293 Table F-2â€”Matrix prototypes for codeword block length n = 1296 bits, subblock size is Z = 54 bits.... 3294 Table F-3â€”Matrix prototypes for codeword block length n = 1944 bits, subblock size is Z = 81 bits.... 3295 Table G-1â€”Attributes applicable to frame exchange sequence definition ............................................... 3296 Table H-1â€”Payload Type field values ..................................................................................................... 3311 Table I-1â€”The message for the BCC example......................................................................................... 3313 Table I-2â€”Frequency domain representation of the short sequences....................................................... 3314 Table I-3â€”One period of IFFT of the short sequences............................................................................. 3314 Table I-4â€”Time domain representation of the short sequence................................................................. 3315 Table I-5â€”Frequency domain representation of the long sequences........................................................ 3317 Table I-6â€”Time domain representation of the long sequence.................................................................. 3317 Table I-7â€”Bit assignment for SIGNAL field ........................................................................................... 3319 Table I-8â€”SIGNAL field bits after encoding ........................................................................................... 3320 Table I-9â€”SIGNAL field bits after interleaving ...................................................................................... 3320 Table I-10â€”Frequency domain representation of SIGNAL field............................................................. 3321 Table I-11â€”Frequency domain representation of SIGNAL field with pilots inserted ............................. 3321 Table I-12â€”Time domain representation of SIGNAL field ..................................................................... 3322 Table I-13â€”The DATA bits before scrambling........................................................................................ 3323 Table I-14â€”Scrambling sequence for seed 1011101................................................................................ 3325 95 Copyright Â© 2016 IEEE. All rights reserved. Table I-15â€”The DATA bits after scrambling .......................................................................................... 3325 Table I-16â€”The BCC encoded DATA bits .............................................................................................. 3327 Table I-17â€”First permutation ................................................................................................................... 3330 Table I-18â€”Second permutation............................................................................................................... 3330 Table I-19â€”Interleaved bits of first DATA symbol ................................................................................. 3331 Table I-20â€”Frequency domain of first DATA symbol ............................................................................ 3333 Table I-21â€”Polarity of the pilot subcarriers ............................................................................................. 3333 Table I-22â€”Time domain representation of the short training sequence ................................................. 3334 Table I-23â€”Time domain representation of the long training sequence .................................................. 3335 Table I-24â€”Time domain representation of the SIGNAL field (1 symbol) ............................................. 3336 Table I-25â€”Time domain representation of the DATA field: symbol 1of 6............................................ 3337 Table I-26â€”Time domain representation of the DATA field: symbol 2 of 6........................................... 3338 Table I-27â€”Time domain representation of the DATA field: symbol 3 of 6........................................... 3339 Table I-28â€”Time domain representation of the DATA field: symbol 4 of 6........................................... 3339 Table I-29â€”Time domain representation of the DATA field: symbol 5 of 6........................................... 3340 Table I-30â€”Time domain representation of the DATA field: symbol 6 of 6........................................... 3341 Table I-31â€”Message for LDPC example 1 .............................................................................................. 3342 Table I-32â€”DATA bits for LDPC example 1 before scrambling ............................................................ 3343 Table I-33â€”DATA bits for LDPC example 1 after scrambling ............................................................... 3345 Table I-34â€”DATA bits for LDPC example 1 after insertion of shortening bits ...................................... 3346 Table I-35â€”DATA bits for LDPC example 1 after LDPC encoding ....................................................... 3348 Table I-36â€”DATA bits after puncturing and removal of shortening bits ................................................ 3351 Table I-37â€”Message for LDPC example 2 .............................................................................................. 3354 Table I-38â€”DATA bits for LDPC example 2 before scrambling ............................................................ 3355 Table I-39â€”DATA bits for LDPC example 2 after scrambling ............................................................... 3357 Table I-40â€”DATA bits for LDPC example 2 after insertion of shortening bits ...................................... 3359 Table I-41â€”DATA bits for LDPC example 2 after LDPC encoding ....................................................... 3361 Table I-42â€”DATA bits after removal of shortening bits and copying of repetition bits ......................... 3364 Table I-43â€”DMG control mode header settings ...................................................................................... 3369 Table I-44â€”DMG SC control header settings .......................................................................................... 3374 Table I-45â€”DMG OFDM mode header settings ...................................................................................... 3382 Table J-1â€”Test vectors for block function ............................................................................................... 3407 Table J-2â€”Test vectors for michael.......................................................................................................... 3407 Table J-3â€”Notation example .................................................................................................................... 3420 Table J-4â€”Sample plaintext MPDU ......................................................................................................... 3420 Table J-5â€”ARC4 encryption .................................................................................................................... 3421 Table J-6â€”Expanded MPDU after WEP encapsulation ........................................................................... 3421 Table J-7â€”Sample TKIP parameters ........................................................................................................ 3421 Table J-8â€”Sample plaintext and cipher text MPDUs, using parameter from Table J-7 .......................... 3422 Table J-9â€”RSN PRF Test Vector 1.......................................................................................................... 3423 Table J-10â€”RSN PRF Test Vector 2........................................................................................................ 3424 Table J-11â€”RSN PRF Test Vector 3........................................................................................................ 3424 Table J-12â€”RSN PRF Test Vector 4........................................................................................................ 3424 Table J-13â€”Sample values for pairwise key derivations ......................................................................... 3425 Table J-14â€”Sample derived CCMP-128 temporal key (TK) ................................................................... 3425 Table J-15â€”Sample derived PTK ............................................................................................................. 3426 Table K-1â€”Admissible TSPECs .............................................................................................................. 3446 Table K-2â€”SBA vs Packets/s ................................................................................................................... 3455 Table K-3â€”Table HCCA SBA for video streams .................................................................................... 3456 Table M-1â€”IEEE 802.11 integration service STT ................................................................................... 3468 Table M-2â€”Ethernet/IEEE 802.3 to IEEE 802.11 translation ................................................................. 3469 Table M-3â€”IEEE 802.11 to Ethernet/IEEE 802.3 translation ................................................................. 3469 Table Q-1â€”Destination URI payload ....................................................................................................... 3489 Table R-1â€”Mapping table of DSCP to 3GPP QoS information and EDCA ACs.................................... 3497 96 Copyright Â© 2016 IEEE. All rights reserved. Table R-2â€”Example Enterprise DSCP to UP/AC mapping..................................................................... 3497 Table R-3â€”UP to DSCP range mapping example.................................................................................... 3498 Table R-4â€”SSPN Interface information or permission parameters ......................................................... 3499 Table S-1â€”Default parameters for mesh STAs that intend to operate in light or deep sleep mode for mesh peerings........................................................................................................... 3512 97 Copyright Â© 2016 IEEE. All rights reserved. Figures Figure iâ€”The evolution of numbering in IEEE Std 802.11.......................................................................... 12 Figure 4-1â€”BSSs ........................................................................................................................................ 185 Figure 4-2â€”DSs and APs............................................................................................................................ 186 Figure 4-3â€”ESS.......................................................................................................................................... 187 Figure 4-4â€”A representative signal intensity map ..................................................................................... 188 Figure 4-5â€”Collocated coverage areas....................................................................................................... 189 Figure 4-6â€”Connecting to other IEEE 802 LANs ..................................................................................... 189 Figure 4-7â€”CCSS and ECAPC .................................................................................................................. 191 Figure 4-8â€”SSPN interface service architecture ........................................................................................ 204 Figure 4-9â€”Example MBSS containing mesh STAs, mesh gates, APs, and portals ................................. 206 Figure 4-10â€”Example device consisting of mesh STA and AP STA to connect an MBSS and an infrastructure BSS............................................................................................................ 207 Figure 4-11â€”MAC data transport over an MBSS ...................................................................................... 210 Figure 4-12â€”DMG relay in a DMG BSS ................................................................................................... 211 Figure 4-13â€”Multiple APs and multiple GDBs ......................................................................................... 213 Figure 4-14â€”IEEE 802.11 architecture for infrastructure BSS and PBSS................................................. 217 Figure 4-15â€”IEEE 802.11 Infrastructure model ........................................................................................ 218 Figure 4-16â€”IEEE 802.11 architecture (again).......................................................................................... 229 Figure 4-17â€”Logical architecture of an IBSS ............................................................................................ 230 Figure 4-18â€”Logical architecture of a PBSS ............................................................................................. 230 Figure 4-19â€”Portion of the ISO/IEC basic reference model covered in this standard............................... 232 Figure 4-20â€”Interworking reference model ............................................................................................... 232 Figure 4-21â€”ESS link illustration .............................................................................................................. 233 Figure 4-22â€”Reference model for supporting multiple MAC sublayers ................................................... 233 Figure 4-23â€”Reference model for a multi-band capable device (transparent FST)................................... 234 Figure 4-24â€”Reference model for a multi-band capable device (nontransparent FST)............................. 235 Figure 4-25â€”Establishing the IEEE 802.11 association............................................................................. 237 Figure 4-26â€”IEEE 802.1X EAP authentication ......................................................................................... 238 Figure 4-27â€”Establishing pairwise and group keys ................................................................................... 239 Figure 4-28â€”Delivery of subsequent group keys ....................................................................................... 240 Figure 4-29â€”Example using SAE authentication....................................................................................... 240 Figure 4-30â€”Sample 4-way handshakes in an IBSS .................................................................................. 242 Figure 4-31â€”Example using IEEE 802.1X authentication......................................................................... 243 Figure 4-32â€”Example of RSNA setup in a PBSS...................................................................................... 244 Figure 5-1â€”MAC data plane architecture .................................................................................................. 251 Figure 5-2â€”MAC data plane architecture (transparent FST) ..................................................................... 252 Figure 5-3â€”Role-specific behavior block for non-AP STA....................................................................... 253 Figure 5-4â€”Role-specific behavior block for AP....................................................................................... 253 Figure 5-5â€”Role-specific behavior block for mesh STA........................................................................... 254 Figure 5-6â€”Role-specific behavior block for mesh gate............................................................................ 254 Figure 6-1â€”GET and SET operations ........................................................................................................ 262 Figure 6-2â€”Layer management model ....................................................................................................... 318 Figure 6-3â€”Measurement requestâ€”accepted ............................................................................................ 319 Figure 6-4â€”Measurement requestâ€”rejected.............................................................................................. 320 Figure 6-5â€”TPC adaptation........................................................................................................................ 320 Figure 6-6â€”Channel switching................................................................................................................... 321 Figure 6-7â€”TDLS direct-link establishment .............................................................................................. 407 Figure 6-8â€”TDLS direct-link teardown ..................................................................................................... 412 Figure 6-9â€”TPU ......................................................................................................................................... 414 Figure 6-10â€”TDLS channel switching....................................................................................................... 417 Figure 6-11â€”TDLS peer PSM.................................................................................................................... 420 Figure 6-12â€”Event protocol exchange ....................................................................................................... 424 98 Copyright Â© 2016 IEEE. All rights reserved. Figure 6-13â€”Diagnostic protocol exchange ............................................................................................... 428 Figure 6-14â€”Location configuration request and response protocol exchange ......................................... 432 Figure 6-15â€”Location track notification protocol exchange...................................................................... 435 Figure 6-16â€”Timing measurement primitives and timestamps capture..................................................... 437 Figure 6-17â€”Fine timing measurement primitives and timestamps capture.............................................. 441 Figure 6-18â€”BSS transition management requestâ€”accepted ................................................................... 447 Figure 6-19â€”FMS setup protocol exchange............................................................................................... 453 Figure 6-20â€”Collocated interference protocol exchange........................................................................... 457 Figure 6-21â€”TFS request and response exchange ..................................................................................... 461 Figure 6-22â€”WNM sleep mode request and response exchange ............................................................... 464 Figure 6-23â€”TIM broadcast setup protocol exchange ............................................................................... 468 Figure 6-24â€”QoS traffic capability update protocol exchange .................................................................. 472 Figure 6-25â€”Channel usage request protocol exchange ............................................................................ 474 Figure 6-26â€”DMS or GCR setup protocol exchange................................................................................. 478 Figure 6-27â€”Example SCS setup and termination protocol exchange ...................................................... 532 Figure 6-28â€”Operation of OCT ................................................................................................................. 549 Figure 6-29â€”MSGCF state machine .......................................................................................................... 593 Figure 7-1â€”DS architecture........................................................................................................................ 616 Figure 8-1â€”The channel-list parameter element for 40 MHz, 80 MHz, and 160 MHz channel width...... 630 Figure 8-2â€”The channel-list parameter element for 80+80 MHz channel width ...................................... 630 Figure 8-3â€”TVHT channel-list parameter element and channel bandwidth for TVHT_W, TVHT_2W, and TVHT_W+W........................................................................................ 630 Figure 8-4â€”TVHT channel-list parameter element and channel bandwidth for TVHT_4W and TVHT_2W+2W ............................................................................................................... 631 Figure 9-1â€”MAC frame format.................................................................................................................. 638 Figure 9-2â€”Frame Control field when Type is not equal to 1 or Subtype is not equal to 6 ...................... 638 Figure 9-3â€”Frame Control field when Type is equal to 1 and Subtype is equal to 6 ................................ 638 Figure 9-4â€”Sequence Control field............................................................................................................ 647 Figure 9-5â€”Sequence Number field in QMFs............................................................................................ 647 Figure 9-6â€”QoS AP PS Buffer State subfield............................................................................................ 652 Figure 9-7â€”Buffered AC subfield .............................................................................................................. 654 Figure 9-8â€”HT Control field...................................................................................................................... 654 Figure 9-9â€”HT Control Middle subfield of the HT variant HT Control field ........................................... 655 Figure 9-10â€”Link Adaptation Control subfield ........................................................................................ 655 Figure 9-11â€”MAI subfield ......................................................................................................................... 656 Figure 9-12â€”ASELC subfield .................................................................................................................... 657 Figure 9-13â€”HT Control Middle subfield of the VHT variant HT Control field ...................................... 659 Figure 9-14â€”MSI/STBC subfield when the Unsolicited MFB subfield is 1.............................................. 660 Figure 9-15â€”MFB subfield in the VHT variant HT Control field ............................................................. 660 Figure 9-16â€”Mesh Control field ................................................................................................................ 663 Figure 9-17â€”Mesh Flags subfield .............................................................................................................. 663 Figure 9-18â€”Mesh Address Extension subfield......................................................................................... 664 Figure 9-19â€”Frame Control field subfield values within Control frames ................................................. 669 Figure 9-20â€”RTS frame ............................................................................................................................. 670 Figure 9-21â€”CTS frame ............................................................................................................................. 670 Figure 9-22â€”Ack frame.............................................................................................................................. 671 Figure 9-23â€”PS-Poll frame ........................................................................................................................ 671 Figure 9-24â€”CF-End frame........................................................................................................................ 672 Figure 9-25â€”CF-End +CF-Ack frame........................................................................................................ 672 Figure 9-26â€”BlockAckReq frame.............................................................................................................. 673 Figure 9-27â€”BAR Control field ................................................................................................................. 673 Figure 9-28â€”Block Ack Starting Sequence Control subfield .................................................................... 674 Figure 9-29â€”BAR Information field (Multi-TID BlockAckReq).............................................................. 675 Figure 9-30â€”Per TID Info subfield ............................................................................................................ 675 99 Copyright Â© 2016 IEEE. All rights reserved. Figure 9-31â€”BAR Information field format (GCR BlockAckReq)........................................................... 676 Figure 9-32â€”BlockAck frame .................................................................................................................... 676 Figure 9-33â€”BA Control field.................................................................................................................... 677 Figure 9-34â€”BA Information field (BlockAck)......................................................................................... 678 Figure 9-35â€”BA Information field (Compressed BlockAck) .................................................................... 679 Figure 9-36â€”BA Information field (Multi-TID BlockAck) ....................................................................... 679 Figure 9-37â€”BA Information field (Extended Compressed BlockAck) .................................................... 680 Figure 9-38â€”BA Information field format (GCR BlockAck) .................................................................... 680 Figure 9-39â€”Control Wrapper frame ......................................................................................................... 681 Figure 9-40â€”Poll frame format .................................................................................................................. 681 Figure 9-41â€”SPR frame format.................................................................................................................. 682 Figure 9-42â€”Grant frame format................................................................................................................ 682 Figure 9-43â€”DMG CTS frame format ....................................................................................................... 683 Figure 9-44â€”DMG DTS frame format....................................................................................................... 683 Figure 9-45â€”SSW frame format ................................................................................................................ 684 Figure 9-46â€”SSW-Feedback frame format................................................................................................ 684 Figure 9-47â€”SSW-Ack frame format ........................................................................................................ 685 Figure 9-48â€”Grant Ack frame format ........................................................................................................ 685 Figure 9-49â€”VHT NDP Announcement frame format .............................................................................. 685 Figure 9-50â€”Sounding Dialog Token field ................................................................................................ 686 Figure 9-51â€”STA Info field ....................................................................................................................... 686 Figure 9-52â€”Beamforming Report Poll frame format ............................................................................... 687 Figure 9-53â€”Data frame............................................................................................................................. 687 Figure 9-54â€”A-MSDU structure ................................................................................................................ 690 Figure 9-55â€”Basic A-MSDU subframe structure ...................................................................................... 691 Figure 9-56â€”A-MSDU subframe structure for Mesh Data ........................................................................ 691 Figure 9-57â€”Short A-MSDU subframe structure ...................................................................................... 692 Figure 9-58â€”Management frame format.................................................................................................... 692 Figure 9-59â€”Extension frame format......................................................................................................... 717 Figure 9-60â€”DMG Beacon frame format .................................................................................................. 717 Figure 9-61â€”Beacon Interval Control field................................................................................................ 719 Figure 9-62â€”Clustering Control field format if the Discovery Mode field is 0......................................... 720 Figure 9-63â€”Clustering Control field format if the Discovery Mode field is 1......................................... 721 Figure 9-64â€”Example addressing for a mesh Data frame.......................................................................... 723 Figure 9-65â€”Authentication Algorithm Number field............................................................................... 723 Figure 9-66â€”Authentication Transaction Sequence Number field ............................................................ 724 Figure 9-67â€”Beacon Interval field ............................................................................................................. 724 Figure 9-68â€”Capability Information field (non-DMG STA) .................................................................... 724 Figure 9-69â€”Capability Information field (DMG STA) ............................................................................ 725 Figure 9-70â€”Current AP Address field ...................................................................................................... 727 Figure 9-71â€”Listen Interval field ............................................................................................................... 727 Figure 9-72â€”Reason Code field ................................................................................................................. 728 Figure 9-73â€”AID field ............................................................................................................................... 731 Figure 9-74â€”Status Code field ................................................................................................................... 731 Figure 9-75â€”Timestamp field .................................................................................................................... 736 Figure 9-76â€”Action field ........................................................................................................................... 736 Figure 9-77â€”Dialog Token fixed field ....................................................................................................... 738 Figure 9-78â€”DLS Timeout Value fixed field ............................................................................................ 738 Figure 9-79â€”Block Ack Parameter Set fixed field..................................................................................... 738 Figure 9-80â€”Block Ack Timeout Value fixed field................................................................................... 739 Figure 9-81â€”DELBA Parameter Set field.................................................................................................. 739 Figure 9-82â€”QoS Info field when sent by an AP....................................................................................... 739 Figure 9-83â€”QoS Info field when set by a non-AP STA........................................................................... 740 Figure 9-84â€”Measurement Pilot Interval fixed field ................................................................................. 741 100 Copyright Â© 2016 IEEE. All rights reserved. Figure 9-85â€”Max Transmit Power field .................................................................................................... 741 Figure 9-86â€”Transmit Power Used field ................................................................................................... 741 Figure 9-87â€”Channel Width fixed field..................................................................................................... 741 Figure 9-88â€”Operating Class and Channel field........................................................................................ 742 Figure 9-89â€”SM Power Control fixed field ............................................................................................... 742 Figure 9-90â€”PCO Phase Control fixed field.............................................................................................. 743 Figure 9-91â€”PSMP Parameter Set fixed field............................................................................................ 743 Figure 9-92â€”PSMP STA Info fixed field (group addressed) ..................................................................... 744 Figure 9-93â€”PSMP STA Info fixed field (individually addressed) ........................................................... 744 Figure 9-94â€”MIMO Control field.............................................................................................................. 745 Figure 9-95â€”CSI matrix coding ................................................................................................................. 748 Figure 9-96â€”V matrix coding (noncompressed beamforming) ................................................................. 750 Figure 9-97â€”First example of Compressed Beamforming Report field encoding..................................... 753 Figure 9-98â€”Second example of Compressed Beamforming Report field encoding ................................ 753 Figure 9-99â€”Antenna Selection Indices fixed field ................................................................................... 753 Figure 9-100â€”Organization Identifier field................................................................................................ 754 Figure 9-101â€”Identification field format ................................................................................................... 754 Figure 9-102â€”Mask field format................................................................................................................ 754 Figure 9-103â€”MCS Index field format when the MCS Selector field is 3, 4, 5, or 6................................ 755 Figure 9-104â€”GAS Query Response Fragment ID field ........................................................................... 756 Figure 9-105â€”Venue Info field format....................................................................................................... 756 Figure 9-106â€”Target Channel field format ................................................................................................ 759 Figure 9-107â€”Operating Class field format ............................................................................................... 759 Figure 9-108â€”Send-Confirm field ............................................................................................................. 759 Figure 9-109â€”Anti-Clogging Token field.................................................................................................. 759 Figure 9-110â€”Scalar field .......................................................................................................................... 760 Figure 9-111â€”FFE field ............................................................................................................................. 760 Figure 9-112â€”Confirm field....................................................................................................................... 760 Figure 9-113â€”Finite Cyclic Group field .................................................................................................... 760 Figure 9-114â€”TXOP Reservation field format .......................................................................................... 760 Figure 9-115â€”Relay Capable STA Info field............................................................................................. 761 Figure 9-116â€”DMG Parameters................................................................................................................. 762 Figure 9-117â€”VHT MIMO Control field................................................................................................... 763 Figure 9-118â€”Operating Mode field .......................................................................................................... 779 Figure 9-119â€”Membership Status Array field ........................................................................................... 782 Figure 9-120â€”User Position Array field .................................................................................................... 782 Figure 9-121â€”Device Location Information Body field format ................................................................ 783 Figure 9-122â€”Element format.................................................................................................................... 784 Figure 9-123â€”SSID element format........................................................................................................... 790 Figure 9-124â€”Supported Rates and BSS Membership Selectors element format ..................................... 791 Figure 9-125â€”DSSS Parameter Set element format .................................................................................. 792 Figure 9-126â€”CF Parameter Set element format ....................................................................................... 792 Figure 9-127â€”TIM element format ............................................................................................................ 793 Figure 9-128â€”IBSS Parameter Set element format.................................................................................... 795 Figure 9-129â€”Challenge Text element format........................................................................................... 795 Figure 9-130â€”Country element format ...................................................................................................... 795 Figure 9-131â€”Subband Triplet Sequence format....................................................................................... 796 Figure 9-132â€”Subband Triplet field .......................................................................................................... 796 Figure 9-133â€”Triplet field if dot11OperaratingClassRequired is true....................................................... 796 Figure 9-134â€”Format of m-th Operating/Subband Sequence field ........................................................... 796 Figure 9-135â€”Request element .................................................................................................................. 798 Figure 9-136â€”Extended Request element .................................................................................................. 798 Figure 9-137â€”ERP element........................................................................................................................ 799 Figure 9-138â€”ERP Parameters field .......................................................................................................... 799 101 Copyright Â© 2016 IEEE. All rights reserved. Figure 9-139â€”Extended Supported Rates and BSS Membership Selectors element format ..................... 800 Figure 9-140â€”Power Constraint element format ....................................................................................... 800 Figure 9-141â€”Power Capability element format ....................................................................................... 800 Figure 9-142â€”TPC Request element format .............................................................................................. 801 Figure 9-143â€”TPC Report element format ................................................................................................ 801 Figure 9-144â€”Supported Channels element format ................................................................................... 802 Figure 9-145â€”Channel Switch Announcement element format ................................................................ 802 Figure 9-146â€”Secondary Channel Offset element format ......................................................................... 803 Figure 9-147â€”Measurement Request element format................................................................................ 804 Figure 9-148â€”Measurement Request Mode field ...................................................................................... 805 Figure 9-149â€”Measurement Request field format for a Basic request ...................................................... 806 Figure 9-150â€”Measurement Request field format for a CCA request....................................................... 807 Figure 9-151â€”Measurement Request field format for an RPI Histogram request ..................................... 807 Figure 9-152â€”Measurement Request field format for Channel Load request ........................................... 807 Figure 9-153â€”Channel Load Reporting data field format ......................................................................... 808 Figure 9-154â€”Measurement Request field format for Noise Histogram request....................................... 809 Figure 9-155â€”Noise Histogram Reporting data field format..................................................................... 810 Figure 9-156â€”Measurement Request field format for Beacon request...................................................... 811 Figure 9-157â€”Beacon Reporting data field format .................................................................................... 813 Figure 9-158â€”Measurement Request field format for Frame request........................................................ 815 Figure 9-159â€”Measurement Request field format for STA Statistics request........................................... 816 Figure 9-160â€”Triggered Reporting subelement for STA Counters ........................................................... 817 Figure 9-161â€”STA Counter Trigger Condition field ................................................................................. 818 Figure 9-162â€”Triggered Reporting subelement for QoS STA Counters ................................................... 818 Figure 9-163â€”QoS STA Counter Trigger Condition field......................................................................... 819 Figure 9-164â€”Triggered Reporting subelement for RSNA Counters ........................................................ 819 Figure 9-165â€”RSNA Trigger Condition field............................................................................................ 820 Figure 9-166â€”Measurement Request field format for LCI request ........................................................... 820 Figure 9-167â€”Azimuth Request subelement format .................................................................................. 821 Figure 9-168â€”Azimuth Request field ........................................................................................................ 821 Figure 9-169â€”Originator Requesting STA MAC Address subelement format ......................................... 822 Figure 9-170â€”Target MAC Address subelement format ........................................................................... 822 Figure 9-171â€”Format of Maximum Age subelement ................................................................................ 822 Figure 9-172â€”Measurement Request field format for Transmit Stream/Category Measurement Request............................................................................................................................. 823 Figure 9-173â€”Traffic Identifier field ......................................................................................................... 823 Figure 9-174â€”Triggered Reporting subelement format ............................................................................. 824 Figure 9-175â€”Triggered Reporting field.................................................................................................... 824 Figure 9-176â€”Trigger Conditions bit-field ................................................................................................ 824 Figure 9-177â€”Delay Threshold subfield .................................................................................................... 825 Figure 9-178â€”Measurement Request field format for Measurement Pause request.................................. 826 Figure 9-179â€”Measurement Request field format for a Multicast Diagnostics request ............................ 827 Figure 9-180â€”Multicast Triggered Reporting subelement format ............................................................. 827 Figure 9-181â€”Multicast Trigger Condition field ....................................................................................... 827 Figure 9-182â€”Location Civic Request field format ................................................................................... 828 Figure 9-183â€”Location Identifier request field format .............................................................................. 830 Figure 9-184â€”Measurement Request field format for Directional Channel Quality request..................... 831 Figure 9-185â€”Directional Channel Quality Reporting data field format................................................... 832 Figure 9-186â€”Measurement Request field format for Directional Measurement request ......................... 833 Figure 9-187â€”Measurement Request field format for Directional Statistics request ................................ 833 Figure 9-188â€”Directional Statistics Bitmap field format .......................................................................... 834 Figure 9-189â€”Measurement Request field for a Fine Timing Measurement Range request..................... 834 Figure 9-190â€”Format of Maximum Age subelement ................................................................................ 835 Figure 9-191â€”Measurement Report element format.................................................................................. 836 102 Copyright Â© 2016 IEEE. All rights reserved. Figure 9-192â€”Measurement Report Mode field ........................................................................................ 836 Figure 9-193â€”Measurement Report field format for a Basic report .......................................................... 837 Figure 9-194â€”Map field format ................................................................................................................. 838 Figure 9-195â€”Measurement Report field format for a CCA report........................................................... 838 Figure 9-196â€”Measurement Report field format for an RPI histogram report.......................................... 839 Figure 9-197â€”Measurement Report field format for Channel Load report ............................................... 840 Figure 9-198â€”Measurement Report field format for Noise Histogram report........................................... 841 Figure 9-199â€”Measurement Report field format for Beacon report.......................................................... 843 Figure 9-200â€”Reported Frame Information field ...................................................................................... 844 Figure 9-201â€”Measurement Report field format for Frame report............................................................ 845 Figure 9-202â€”Frame Count Report subelement format ............................................................................. 846 Figure 9-203â€”Frame Report Entry field format......................................................................................... 846 Figure 9-204â€”Measurement Report field format for STA Statistics report............................................... 847 Figure 9-205â€”Measurement Report field format for dot11Counters Group.............................................. 852 Figure 9-206â€”Measurement Report field format for dot11MACStatistics Group .................................... 852 Figure 9-207â€”Measurement Report field format for dot11QosCounters Group for UPx ......................... 853 Figure 9-208â€”Measurement Report field format for dot11BSSAverageAccessDelay Group................... 853 Figure 9-209â€”Measurement Report field format for RSNA Counters Group ........................................... 854 Figure 9-210â€”Data field of the Reporting Reason subelement for STA Counters .................................... 854 Figure 9-211â€”Data field of the Reporting Reason subelement for QoS STA Counters............................ 855 Figure 9-212â€”Data field of the Reporting Reason subelement for RSNA Counters................................. 855 Figure 9-213â€”Format of Location Configuration Information Report ...................................................... 855 Figure 9-214â€”LCI subelement format ....................................................................................................... 856 Figure 9-215â€”LCI field format .................................................................................................................. 856 Figure 9-216â€”Azimuth Report subelement format .................................................................................... 858 Figure 9-217â€”Azimuth Report subfield ..................................................................................................... 858 Figure 9-218â€”Z subelement format ........................................................................................................... 859 Figure 9-219â€”STA Floor Info field format................................................................................................ 859 Figure 9-220â€”Relative Location Error subelement format........................................................................ 860 Figure 9-221â€”Relative Location Error field format................................................................................... 860 Figure 9-222â€”Usage Rules/Policy subelement format .............................................................................. 861 Figure 9-223â€”Usage Rules/Policy Parameters field format ...................................................................... 861 Figure 9-224â€”Co-Located BSSID List subelement format ....................................................................... 862 Figure 9-225â€”Measurement Report field format for Transmit Stream/Category Measurement report..... 862 Figure 9-226â€”Reporting Reason field........................................................................................................ 863 Figure 9-227â€”Measurement Report field format for a Multicast Diagnostics report ................................ 865 Figure 9-228â€”Multicast Reporting Reason field ....................................................................................... 866 Figure 9-229â€”Location Civic report field format ...................................................................................... 867 Figure 9-230â€”Location Civic subelement format ...................................................................................... 868 Figure 9-231â€”Location Reference subelement format .............................................................................. 869 Figure 9-232â€”Location Shape subelement format..................................................................................... 869 Figure 9-233â€”2-Dimension Point Location Shape Value format .............................................................. 870 Figure 9-234â€”3-Dimension Point Location Shape Value format .............................................................. 870 Figure 9-235â€”Circle Location Shape Value format................................................................................... 870 Figure 9-236â€”Sphere Location Shape Value format ................................................................................. 871 Figure 9-237â€”Polygon Location Shape Value format ............................................................................... 871 Figure 9-238â€”Prism Location Shape Value format ................................................................................... 871 Figure 9-239â€”Ellipse Location Shape Value format ................................................................................. 872 Figure 9-240â€”Ellipsoid Location Shape Value format .............................................................................. 872 Figure 9-241â€”Arcband Location Shape Value format............................................................................... 872 Figure 9-242â€”Map Image subelement format ........................................................................................... 873 Figure 9-243â€”Location Identifier report field format ................................................................................ 874 Figure 9-244â€”Public Identifier URI/FQDN subelement format................................................................ 875 Figure 9-245â€”Measurement report field format for Directional Channel Quality report.......................... 876 103 Copyright Â© 2016 IEEE. All rights reserved. Figure 9-246â€”Measurement Report field format for Directional Measurement report ............................. 877 Figure 9-247â€”Measurement Results field format ...................................................................................... 877 Figure 9-248â€”Measurement Report field format for Directional Statistics report .................................... 878 Figure 9-249â€”Measurement Report field format for a Fine Timing Measurement Range report ............. 879 Figure 9-250â€”Range Entry field format..................................................................................................... 879 Figure 9-251â€”Error Entry field format ...................................................................................................... 880 Figure 9-252â€”Quiet element format .......................................................................................................... 881 Figure 9-253â€”IBSS DFS element format................................................................................................... 882 Figure 9-254â€”Channel Map field format ................................................................................................... 882 Figure 9-255â€”RSNE format....................................................................................................................... 882 Figure 9-256â€”Suite selector format ........................................................................................................... 884 Figure 9-257â€”RSN Capabilities field format............................................................................................. 888 Figure 9-258â€”Vendor Specific element format ......................................................................................... 890 Figure 9-259â€”Extended Capabilities element format ................................................................................ 891 Figure 9-260â€”BSS Load element format ................................................................................................... 896 Figure 9-261â€”EDCA Parameter Set element............................................................................................. 897 Figure 9-262â€”AC_BE, AC_BK, AC_VI, and AC_VO Parameter Record field format ........................... 897 Figure 9-263â€”ACI/AIFSN field................................................................................................................. 897 Figure 9-264â€”ECWmin and ECWmax fields ............................................................................................ 898 Figure 9-265â€”TSPEC element format ....................................................................................................... 900 Figure 9-266â€”TS Info field ........................................................................................................................ 900 Figure 9-267â€”Nominal MSDU Size field .................................................................................................. 902 Figure 9-268â€”DMG Attributes field format .............................................................................................. 905 Figure 9-269â€”TCLAS element format....................................................................................................... 906 Figure 9-270â€”Frame Classifier field.......................................................................................................... 907 Figure 9-271â€”Frame Classifier field of Classifier Type 0 ......................................................................... 909 Figure 9-272â€”Frame Classifier field of Classifier Type 1 for traffic over IPv4........................................ 909 Figure 9-273â€”Frame Classifier field of Classifier Type 1 for traffic over IPv6........................................ 909 Figure 9-274â€”Frame Classifier field of Classifier Type 2 ......................................................................... 909 Figure 9-275â€”Frame Classifier field of Classifier Type 3 ......................................................................... 910 Figure 9-276â€”Frame Classifier subfield of Classifier Type 4 for traffic over IPv4 .................................. 911 Figure 9-277â€”Frame Classifier subfield of Classifier Type 4 for traffic over IPv6 .................................. 911 Figure 9-278â€”Frame Classifier field of Classifier Type 5 ......................................................................... 912 Figure 9-279â€”Frame Classifier field of Classifier Type 6 ......................................................................... 912 Figure 9-280â€”Frame Control Match Specification subfield of Classifier Type 6 ..................................... 912 Figure 9-281â€”Duration/ID Match Specification subfield of Classifier Type 6 ......................................... 913 Figure 9-282â€”Address 1 Match Specification subfield of Classifier Type 6 ............................................ 913 Figure 9-283â€”Address 2 Match Specification subfield of Classifier Type 6 ............................................ 913 Figure 9-284â€”Address 3 Match Specification subfield of Classifier Type 6 ............................................ 913 Figure 9-285â€”Sequence Control Match Specification subfield of Classifier Type 6 ................................ 913 Figure 9-286â€”Address 4 Match Specification subfield of Classifier Type 6 ............................................ 913 Figure 9-287â€”QoS Control Match Specification subfield of Classifier Type 6 ........................................ 913 Figure 9-288â€”HT Control Match Specification subfield of Classifier Type 6 .......................................... 914 Figure 9-289â€”TS Delay element................................................................................................................ 914 Figure 9-290â€”TCLAS Processing element ................................................................................................ 914 Figure 9-291â€”Schedule element ................................................................................................................ 915 Figure 9-292â€”Schedule Info field .............................................................................................................. 915 Figure 9-293â€”QoS Capability element format........................................................................................... 916 Figure 9-294â€”AP Channel Report element format .................................................................................... 916 Figure 9-295â€”Neighbor Report element format ........................................................................................ 917 Figure 9-296â€”BSSID Information field ..................................................................................................... 917 Figure 9-297â€”Capabilities subfield............................................................................................................ 918 Figure 9-298â€”TSF subelement format ....................................................................................................... 919 Figure 9-299â€” BSS Transition Candidate Preference subelement format ................................................. 920 104 Copyright Â© 2016 IEEE. All rights reserved. Figure 9-300â€”BSS Termination Duration subelement format................................................................... 921 Figure 9-301â€”Bearing subelement format ................................................................................................. 921 Figure 9-302â€”Wide Bandwidth Channel subelement format .................................................................... 922 Figure 9-303â€”RCPI element format .......................................................................................................... 923 Figure 9-304â€”BSS Average Access Delay element format....................................................................... 923 Figure 9-305â€”Antenna element format...................................................................................................... 925 Figure 9-306â€”RSNI element format .......................................................................................................... 925 Figure 9-307â€”Measurement Pilot Transmission element format .............................................................. 925 Figure 9-308â€”BSS Available Admission Capacity element format .......................................................... 926 Figure 9-309â€”BSS AC Access Delay element format............................................................................... 927 Figure 9-310â€”Access Category Access Delay subfields ........................................................................... 928 Figure 9-311â€”RM Enabled Capabilities element format ........................................................................... 929 Figure 9-312â€”Multiple BSSID element format ......................................................................................... 931 Figure 9-313â€”Mobility Domain element format ....................................................................................... 933 Figure 9-314â€”FT Capability and Policy field ............................................................................................ 933 Figure 9-315â€”FTE format .......................................................................................................................... 933 Figure 9-316â€”MIC Control field................................................................................................................ 934 Figure 9-317â€”Optional Parameter(s) field ................................................................................................. 934 Figure 9-318â€”GTK subelement format...................................................................................................... 935 Figure 9-319â€”GTK subelementâ€™s Key Info subfield ................................................................................. 935 Figure 9-320â€”IGTK subelement format .................................................................................................... 935 Figure 9-321â€”TIE format........................................................................................................................... 936 Figure 9-322â€”RDE format ......................................................................................................................... 936 Figure 9-323â€”RIC Descriptor element format........................................................................................... 937 Figure 9-324â€”DSE Registered Location element format .......................................................................... 937 Figure 9-325â€”DSE Registered Location Information field format............................................................ 938 Figure 9-326â€”Extended Channel Switch Announcement element format ................................................ 939 Figure 9-327â€”Supported Operating Classes element format ..................................................................... 939 Figure 9-328â€”Current Operating Class Extension Sequence field format ................................................ 940 Figure 9-329â€”Operating Class Duple Sequence field format .................................................................... 940 Figure 9-330â€”Management MIC element format ...................................................................................... 941 Figure 9-331â€”HT Capabilities element format .......................................................................................... 941 Figure 9-332â€”HT Capability Information field ......................................................................................... 942 Figure 9-333â€”A-MPDU Parameters field.................................................................................................. 944 Figure 9-334â€”Supported MCS Set field .................................................................................................... 944 Figure 9-335â€”HT Extended Capabilities field........................................................................................... 945 Figure 9-336â€”Transmit Beamforming Capabilities field........................................................................... 947 Figure 9-337â€”ASEL Capability field......................................................................................................... 949 Figure 9-338â€”HT Operation element format ............................................................................................. 950 Figure 9-339â€”HT Operation Information field .......................................................................................... 951 Figure 9-340â€”20/40 BSS Intolerant Channel Report element format ....................................................... 954 Figure 9-341â€”Overlapping BSS Scan Parameters element format............................................................ 955 Figure 9-342â€”20/40 BSS Coexistence element format.............................................................................. 955 Figure 9-343â€”20/40 BSS Coexistence Information field .......................................................................... 956 Figure 9-344â€”Time Advertisement element format .................................................................................. 956 Figure 9-345â€”Link Identifier element format ............................................................................................ 958 Figure 9-346â€”Wakeup Schedule element format ...................................................................................... 958 Figure 9-347â€”Channel Switch Timing element format ............................................................................. 959 Figure 9-348â€”PTI Control element format ................................................................................................ 959 Figure 9-349â€”TPU Buffer Status element format...................................................................................... 960 Figure 9-350â€”TPU Buffer Status Information field .................................................................................. 960 Figure 9-351â€”Event Request element format ............................................................................................ 961 Figure 9-352â€”Transition Target BSSID subelement format...................................................................... 962 Figure 9-353â€”Transition Source BSSID subelement format ..................................................................... 962 105 Copyright Â© 2016 IEEE. All rights reserved. Figure 9-354â€”Transition Time Threshold subelement format................................................................... 963 Figure 9-355â€”Transition Result subelement format .................................................................................. 963 Figure 9-356â€”Match Value field definitions ............................................................................................. 963 Figure 9-357â€”Frequent Transition subelement format .............................................................................. 964 Figure 9-358â€”RSNA Target BSSID subelement format ........................................................................... 964 Figure 9-359â€”Authentication Type subelement format............................................................................. 965 Figure 9-360â€”EAP Method subelement format......................................................................................... 965 Figure 9-361â€”RSNA Result subelement format ........................................................................................ 965 Figure 9-362â€”Match Value field definitions ............................................................................................. 966 Figure 9-363â€”Peer Address subelement format......................................................................................... 966 Figure 9-364â€”Channel Number subelement format .................................................................................. 967 Figure 9-365â€”Event Report element format .............................................................................................. 968 Figure 9-366â€”Event Report format for Transition event ........................................................................... 969 Figure 9-367â€”Event Report format for RSNA event................................................................................. 971 Figure 9-368â€”Event Report format for peer-to-peer link event................................................................. 971 Figure 9-369â€”Event Report format for WNM log event ........................................................................... 972 Figure 9-370â€”Diagnostic Request element format .................................................................................... 973 Figure 9-371â€”Diagnostic subelement format ............................................................................................ 974 Figure 9-372â€”Credential Type subelement format .................................................................................... 976 Figure 9-373â€”AKM Suite subelement format ........................................................................................... 976 Figure 9-374â€”AP Descriptor subelement format....................................................................................... 976 Figure 9-375â€”Antenna Type subelement format ....................................................................................... 977 Figure 9-376â€”Cipher Suite subelement format.......................................................................................... 977 Figure 9-377â€”Collocated Radio Type subelement format......................................................................... 977 Figure 9-378â€”Device Type subelement format ......................................................................................... 978 Figure 9-379â€”EAP Method subelement format......................................................................................... 979 Figure 9-380â€”Firmware Version subelement format................................................................................. 980 Figure 9-381â€”MAC Address subelement format....................................................................................... 980 Figure 9-382â€”Manufacturer ID String subelement format ........................................................................ 980 Figure 9-383â€”Manufacturer Model String subelement format.................................................................. 980 Figure 9-384â€”Manufacturer OI subelement format................................................................................... 981 Figure 9-385â€”Manufacturer Serial Number String subelement format..................................................... 981 Figure 9-386â€”Power Save Mode subelement format ................................................................................ 981 Figure 9-387â€” Profile ID subelement format............................................................................................. 982 Figure 9-388â€”Supported Operating Classes subelement format ............................................................... 982 Figure 9-389â€”Status Code subelement format........................................................................................... 982 Figure 9-390â€”SSID subelement format ..................................................................................................... 983 Figure 9-391â€”Tx Power Capability subelement format ............................................................................ 983 Figure 9-392â€”Certificate ID subelement format........................................................................................ 983 Figure 9-393â€”Diagnostic Report element format ...................................................................................... 984 Figure 9-394â€”Location Parameters element format .................................................................................. 986 Figure 9-395â€”Location Indication Parameters subelement ....................................................................... 987 Figure 9-396â€”Location Indication Channels subelement .......................................................................... 989 Figure 9-397â€”Location Status subelement ................................................................................................ 989 Figure 9-398â€”Radio subelement ................................................................................................................ 990 Figure 9-399â€”Motion subelement.............................................................................................................. 991 Figure 9-400â€”Location Indication Broadcast Data Rate subelement ........................................................ 992 Figure 9-401â€”Time of Departure subelement............................................................................................ 992 Figure 9-402â€”Location Indication Options subelement ............................................................................ 993 Figure 9-403â€”Options Used field format................................................................................................... 993 Figure 9-404â€”Nontransmitted BSSID Capability element format ............................................................ 994 Figure 9-405â€”DMG BSS Control field format .......................................................................................... 994 Figure 9-406â€”SSID List element format ................................................................................................... 994 Figure 9-407â€”Multiple BSSID-Index element format............................................................................... 995 106 Copyright Â© 2016 IEEE. All rights reserved. Figure 9-408â€”FMS Descriptor element format ......................................................................................... 995 Figure 9-409â€”FMS Counter format ........................................................................................................... 996 Figure 9-410â€”FMS Request element format ............................................................................................. 996 Figure 9-411â€”FMS subelement format...................................................................................................... 997 Figure 9-412â€”FMS Response element format ........................................................................................... 998 Figure 9-413â€”FMS Status subelement format ........................................................................................... 998 Figure 9-414â€”TCLAS Status subelement format .................................................................................... 1000 Figure 9-415â€”QoS Traffic Capability element format ............................................................................ 1000 Figure 9-416â€”BSS Max Idle Period element format ............................................................................... 1001 Figure 9-417â€”Idle Options field .............................................................................................................. 1002 Figure 9-418â€”TFS Request element format............................................................................................. 1002 Figure 9-419â€”TFS subelement format .................................................................................................... 1003 Figure 9-420â€”TFS Request Vendor Specific subelement format ........................................................... 1003 Figure 9-421â€”TFS Response element format .......................................................................................... 1004 Figure 9-422â€”TFS Status subelement format .......................................................................................... 1005 Figure 9-423â€”TFS Response Vendor Specific subelement format ......................................................... 1005 Figure 9-424â€”WNM Sleep Mode element format ................................................................................... 1005 Figure 9-425â€”TIM Broadcast Request element format ........................................................................... 1006 Figure 9-426â€”TIM Broadcast Response element format......................................................................... 1007 Figure 9-427â€” Collocated Interference Report element format............................................................... 1008 Figure 9-428â€”Interference Level Accuracy/Interference Index field format .......................................... 1008 Figure 9-429â€”Channel Usage element format ......................................................................................... 1010 Figure 9-430â€”Time Zone element format................................................................................................ 1010 Figure 9-431â€”DMS Request element format........................................................................................... 1011 Figure 9-432â€”DMS Descriptor ................................................................................................................ 1011 Figure 9-433â€”GCR Request subelement format...................................................................................... 1013 Figure 9-434â€”DMS Response element format ........................................................................................ 1014 Figure 9-435â€”DMS Status field format ................................................................................................... 1014 Figure 9-436â€”GCR Response subelement format ................................................................................... 1016 Figure 9-437â€”Destination URI element format ....................................................................................... 1016 Figure 9-438â€”U-APSD Coexistence element format .............................................................................. 1017 Figure 9-439â€”Interworking element format ............................................................................................ 1018 Figure 9-440â€”Access Network Options field format............................................................................... 1018 Figure 9-441â€”Advertisement Protocol element format ........................................................................... 1019 Figure 9-442â€”Advertisement Protocol Tuple field format ...................................................................... 1020 Figure 9-443â€”Query Response Info field format..................................................................................... 1020 Figure 9-444â€”Expedited Bandwidth Request element format................................................................. 1021 Figure 9-445â€”QoS Map element format .................................................................................................. 1022 Figure 9-446â€”DSCP Exception format.................................................................................................... 1022 Figure 9-447â€”DSCP Range description................................................................................................... 1023 Figure 9-448â€”Roaming Consortium element format............................................................................... 1023 Figure 9-449â€”OI #1 and #2 Lengths field format.................................................................................... 1024 Figure 9-450â€”Emergency Alert Identifier element format ...................................................................... 1024 Figure 9-451â€”Mesh Configuration element format ................................................................................. 1024 Figure 9-452â€”Mesh Formation Info field ................................................................................................ 1027 Figure 9-453â€”Mesh Capability field........................................................................................................ 1028 Figure 9-454â€”Mesh ID element format ................................................................................................... 1028 Figure 9-455â€”Mesh Link Metric Report element format ........................................................................ 1029 Figure 9-456â€”Flags field.......................................................................................................................... 1029 Figure 9-457â€”Congestion Notification element format........................................................................... 1030 Figure 9-458â€”Mesh Peering Management element format ..................................................................... 1030 Figure 9-459â€”Mesh Channel Switch Parameters element format ........................................................... 1031 Figure 9-460â€”Flags field.......................................................................................................................... 1031 Figure 9-461â€”Mesh Awake Window element format ............................................................................. 1032 107 Copyright Â© 2016 IEEE. All rights reserved. Figure 9-462â€”Beacon Timing element format......................................................................................... 1032 Figure 9-463â€”Report Control field .......................................................................................................... 1033 Figure 9-464â€”Beacon Timing Information field ..................................................................................... 1033 Figure 9-465â€”MCCAOP Setup Request element format ........................................................................ 1034 Figure 9-466â€”MCCAOP Reservation field ............................................................................................. 1034 Figure 9-467â€”MCCAOP Setup Reply element format............................................................................ 1035 Figure 9-468â€”MCCAOP Advertisement Overview element format ....................................................... 1035 Figure 9-469â€”Flags field format .............................................................................................................. 1036 Figure 9-470â€”MCCAOP Advertisement element format ........................................................................ 1036 Figure 9-471â€”MCCAOP Advertisement Element Information field ...................................................... 1037 Figure 9-472â€”MCCAOP Reservation Report field ................................................................................. 1038 Figure 9-473â€”MCCAOP Teardown element format ............................................................................... 1038 Figure 9-474â€”GANN element format...................................................................................................... 1039 Figure 9-475â€”RANN element format ...................................................................................................... 1039 Figure 9-476â€”Flags field format .............................................................................................................. 1040 Figure 9-477â€”PREQ element format ....................................................................................................... 1040 Figure 9-478â€”Flags field format .............................................................................................................. 1041 Figure 9-479â€”Per Target Flags field format ............................................................................................ 1042 Figure 9-480â€”PREP element format........................................................................................................ 1043 Figure 9-481â€”Flags field format .............................................................................................................. 1043 Figure 9-482â€”PERR element format ....................................................................................................... 1044 Figure 9-483â€”Flags field format .............................................................................................................. 1044 Figure 9-484â€”PXU element format ......................................................................................................... 1045 Figure 9-485â€”Proxy Information field..................................................................................................... 1045 Figure 9-486â€”Flags subfield .................................................................................................................... 1046 Figure 9-487â€”PXUC element format....................................................................................................... 1046 Figure 9-488â€”Authenticated Mesh Peering Exchange element format ................................................... 1047 Figure 9-489â€”MIC element format.......................................................................................................... 1048 Figure 9-490â€”QMF Policy element format ............................................................................................. 1048 Figure 9-491â€”QACM field format........................................................................................................... 1048 Figure 9-492â€”QACM Header subfield .................................................................................................... 1048 Figure 9-493â€”Intra-Access Category Priority element format ................................................................ 1049 Figure 9-494â€”Intra-Access Priority field format ..................................................................................... 1049 Figure 9-495â€”SCS Descriptor element format ........................................................................................ 1050 Figure 9-496â€”QLoad Report element format .......................................................................................... 1051 Figure 9-497â€”QLoad field format............................................................................................................ 1053 Figure 9-498â€”HCCA TXOP Update Count element format ................................................................... 1053 Figure 9-499â€”Higher Layer Stream ID element format .......................................................................... 1054 Figure 9-500â€”GCR Group Address element format................................................................................ 1054 Figure 9-501â€”DMG BSS Parameter Change element format ................................................................. 1055 Figure 9-502â€”Change Type Bitmap field format .................................................................................... 1055 Figure 9-503â€”DMG Capabilities element format .................................................................................... 1055 Figure 9-504â€”DMG STA Capability Information field format ............................................................... 1056 Figure 9-505â€”A-MPDU parameters subfield format............................................................................... 1057 Figure 9-506â€”Supported MCS Set subfield format ................................................................................. 1058 Figure 9-507â€”DMG AP Or PCP Capability Information field format .................................................... 1059 Figure 9-508â€”Extended SC MCS Capabilities field................................................................................ 1061 Figure 9-509â€”DMG Operation element format ....................................................................................... 1063 Figure 9-510â€”DMG Operation Information field format ........................................................................ 1063 Figure 9-511â€”DMG BSS Parameter Configuration field format............................................................. 1064 Figure 9-512â€”DMG Beam Refinement element format .......................................................................... 1064 Figure 9-513â€”FBCK-REQ field format ................................................................................................... 1065 Figure 9-514â€”FBCK-TYPE field format ................................................................................................. 1066 Figure 9-515â€”DMG Wakeup Schedule element format .......................................................................... 1067 108 Copyright Â© 2016 IEEE. All rights reserved. Figure 9-516â€”Extended Schedule element format................................................................................... 1067 Figure 9-517â€”Allocation field format...................................................................................................... 1068 Figure 9-518â€”Allocation Control subfield format ................................................................................... 1068 Figure 9-519â€”STA availability element format....................................................................................... 1069 Figure 9-520â€”STA Info field format ....................................................................................................... 1070 Figure 9-521â€”DMG TSPEC element format ........................................................................................... 1070 Figure 9-522â€”DMG Allocation Info field format.................................................................................... 1071 Figure 9-523â€”Traffic Scheduling Constraint Set field format................................................................. 1072 Figure 9-524â€”Constraint subfield format ................................................................................................ 1073 Figure 9-525â€”Next DMG ATI element format........................................................................................ 1073 Figure 9-526â€”Awake Window element format ....................................................................................... 1076 Figure 9-527â€”Multi-band element format .............................................................................................. 1076 Figure 9-528â€”Multi-band Control field format ...................................................................................... 1077 Figure 9-529â€”Multi-band Connection Capability field format................................................................ 1078 Figure 9-530â€”ADDBA Extension element format .................................................................................. 1079 Figure 9-531â€”ADDBA Capabilities field format .................................................................................... 1079 Figure 9-532â€”Next PCP List element format .......................................................................................... 1079 Figure 9-533â€”PCP Handover element format ......................................................................................... 1080 Figure 9-534â€”DMG Link Margin element format................................................................................... 1080 Figure 9-535â€”DMG Link Adaptation Acknowledgment element format ............................................... 1081 Figure 9-536â€”Switching Stream element format..................................................................................... 1082 Figure 9-537â€”Switching parameters field format .................................................................................... 1082 Figure 9-538â€”Session Transition element format.................................................................................... 1083 Figure 9-539â€”Session Control field format ............................................................................................. 1083 Figure 9-540â€”Cluster Report element format .......................................................................................... 1085 Figure 9-541â€”Cluster Report Control field format .................................................................................. 1085 Figure 9-542â€”Relay Capabilities element format .................................................................................... 1086 Figure 9-543â€”Relay Capability Information field format........................................................................ 1087 Figure 9-544â€”Relay Transfer Parameter Set element format .................................................................. 1087 Figure 9-545â€”Relay Transfer Parameter field format.............................................................................. 1088 Figure 9-546â€”Quiet Period Request element format ............................................................................... 1088 Figure 9-547â€”Quiet Period Response element format............................................................................. 1089 Figure 9-548â€”BeamLink Maintenance element format........................................................................... 1089 Figure 9-549â€”MMS element format ........................................................................................................ 1090 Figure 9-550â€”MMS Control field format ................................................................................................ 1090 Figure 9-551â€”U-PID element format....................................................................................................... 1092 Figure 9-552â€”ECAPC Policy element format ......................................................................................... 1092 Figure 9-553â€”ECAPC Policy Detail field format.................................................................................... 1092 Figure 9-554â€”Cluster Time Offset element format ................................................................................. 1093 Figure 9-555â€”Antenna Sector ID Pattern element format ....................................................................... 1094 Figure 9-556â€”Sequence Generator 1 ....................................................................................................... 1094 Figure 9-557â€”Sequence Generator 2 ....................................................................................................... 1095 Figure 9-558â€”VHT Capabilities element format ..................................................................................... 1095 Figure 9-559â€”VHT Capabilities Information field .................................................................................. 1096 Figure 9-560â€”Supported Channel Width Set field (TVHT) .................................................................... 1100 Figure 9-561â€”Supported VHT-MCS and NSS Set field.......................................................................... 1100 Figure 9-562â€”Rx VHT-MCS Map and Tx VHT-MCS Map subfields and Basic VHT-MCS And NSS Set field.................................................................................................................. 1102 Figure 9-563â€”VHT Operation element format ........................................................................................ 1102 Figure 9-564â€”VHT Operation Information field ..................................................................................... 1102 Figure 9-565â€”Extended BSS Load element format ................................................................................. 1104 Figure 9-566â€”Wide Bandwidth Channel Switch element format............................................................ 1106 Figure 9-567â€”Transmit Power Envelope element format........................................................................ 1106 Figure 9-568â€”Transmit Power Information field..................................................................................... 1106 109 Copyright Â© 2016 IEEE. All rights reserved. Figure 9-569â€”Channel Switch Wrapper element format ......................................................................... 1108 Figure 9-570â€”AID element format .......................................................................................................... 1109 Figure 9-571â€”Quiet Channel element format .......................................................................................... 1109 Figure 9-572â€”Operating Mode Notification element .............................................................................. 1110 Figure 9-573â€”UPSIM element format ..................................................................................................... 1110 Figure 9-574â€”UPSIM Flags field format................................................................................................. 1110 Figure 9-575â€”Fine Timing Measurement Parameters element format .................................................... 1111 Figure 9-576â€”Fine Timing Measurement Parameters field format ......................................................... 1111 Figure 9-577â€”Calculation of Partial TSF Timer field ............................................................................. 1113 Figure 9-578â€”Device Location element format....................................................................................... 1115 Figure 9-579â€”WSM element format........................................................................................................ 1115 Figure 9-580â€”Reduced Neighbor Report element format ....................................................................... 1115 Figure 9-581â€”Neighbor AP Information field format ............................................................................. 1116 Figure 9-582â€”TBTT Information Header subfield .................................................................................. 1116 Figure 9-583â€”TBTT Information field .................................................................................................... 1117 Figure 9-584â€”TVHT Operation element format...................................................................................... 1117 Figure 9-585â€”TVHT Operation Information field................................................................................... 1117 Figure 9-586â€”FTM Synchronization Information element format.......................................................... 1118 Figure 9-587â€”Estimated Service Parameters element format.................................................................. 1118 Figure 9-588â€”ESP Information field format............................................................................................ 1119 Figure 9-589â€”Future Channel Guidance element format ........................................................................ 1120 Figure 9-590â€”Subelement format ............................................................................................................ 1121 Figure 9-591â€”ANQP-element format ...................................................................................................... 1127 Figure 9-592â€”Query List ANQP-element format .................................................................................... 1128 Figure 9-593â€”Capability List ANQP-element format ............................................................................. 1129 Figure 9-594â€”Venue Name ANQP-element format ................................................................................ 1129 Figure 9-595â€”Venue Name Tuple subfield ............................................................................................. 1130 Figure 9-596â€”Emergency Call Number ANQP-element format ............................................................. 1130 Figure 9-597â€”Emergency Call Number Duple subfield format .............................................................. 1130 Figure 9-598â€”Network Authentication Type ANQP-element format ..................................................... 1131 Figure 9-599â€”Network Authentication Type Tuple subfield format....................................................... 1131 Figure 9-600â€”Roaming Consortium ANQP-element format................................................................... 1132 Figure 9-601â€”OI Duple subfield format .................................................................................................. 1132 Figure 9-602â€”Vendor Specific ANQP-element format ........................................................................... 1133 Figure 9-603â€”IP Address Type Availability ANQP-element.................................................................. 1133 Figure 9-604â€”IP Address field format ..................................................................................................... 1133 Figure 9-605â€”NAI Realm ANQP-element format................................................................................... 1134 Figure 9-606â€”NAI Realm Tuple subfield format .................................................................................... 1134 Figure 9-607â€”NAI Realm Encoding subfield format .............................................................................. 1135 Figure 9-608â€”EAP Method Tuple subfield format.................................................................................. 1135 Figure 9-609â€”Authentication Parameter subfield format ........................................................................ 1136 Figure 9-610â€”3GPP Cellular Network ANQP-element format ............................................................... 1138 Figure 9-611â€”AP Geospatial Location ANQP-element format............................................................... 1138 Figure 9-612â€”AP Civic Location ANQP-element format ....................................................................... 1138 Figure 9-613â€”AP Location Public Identifier URI/FQDN ANQP-element format.................................. 1139 Figure 9-614â€”Domain Name ANQP-element format.............................................................................. 1139 Figure 9-615â€”Domain Name Duple subfield format ............................................................................... 1139 Figure 9-616â€”Emergency Alert URI ANQP-element format.................................................................. 1140 Figure 9-617â€”Emergency NAI ANQP-element format........................................................................... 1140 Figure 9-618â€”TDLS Capability ANQP-element format ......................................................................... 1140 Figure 9-619â€”Neighbor Report ANQP-element format .......................................................................... 1141 Figure 9-620â€”Venue URL ANQP-element format.................................................................................. 1141 Figure 9-621â€”Venue URL Duple field .................................................................................................... 1141 Figure 9-622â€”Advice of Charge ANQP-element format......................................................................... 1142 110 Copyright Â© 2016 IEEE. All rights reserved. Figure 9-623â€”Advice of Charge Duple field ........................................................................................... 1142 Figure 9-624â€”Plan Information Tuple field............................................................................................. 1142 Figure 9-625â€”Local Content ANQP-element format .............................................................................. 1143 Figure 9-626â€”Local Content Duple field................................................................................................. 1143 Figure 9-627â€”Network Authentication Type with Timestamp ANQP-element format .......................... 1144 Figure 9-628â€”Network Authentication Timestamp Tuple subfield format ............................................. 1144 Figure 9-629â€”RLQP-element format....................................................................................................... 1145 Figure 9-630â€”Channel Availability Query RLQP-element format ......................................................... 1145 Figure 9-631â€”Channel Query Info field format....................................................................................... 1146 Figure 9-632â€”Channel Schedule Management RLQP-element format ................................................... 1147 Figure 9-633â€”Network Channel Control RLQP-element format ............................................................ 1147 Figure 9-634â€”Vendor Specific RLQP-element format............................................................................ 1149 Figure 9-635â€”SSW field format .............................................................................................................. 1149 Figure 9-636â€”Dynamic Allocation Info field format .............................................................................. 1150 Figure 9-637â€”SSW Feedback field format when transmitted as part of an ISS ...................................... 1150 Figure 9-638â€”SSW Feedback field format when not transmitted as part of an ISS ................................ 1151 Figure 9-639â€”BRP Request field format ................................................................................................ 1151 Figure 9-640â€”BF Control field format when both IsInitiatorTXSS and IsResponderTXSS subfields are equal to 1 and the BF Control field is transmitted in Grant or Grant Ack frames... 1152 Figure 9-641â€”BF Control field format in all other cases......................................................................... 1153 Figure 9-642â€”Beamformed Link Maintenance field format.................................................................... 1154 Figure 9-643â€”Measurement Request frame Action field format............................................................. 1156 Figure 9-644â€”Measurement Report frame Action field format............................................................... 1156 Figure 9-645â€”TPC Request frame Action field format ........................................................................... 1157 Figure 9-646â€”TPC Report frame Action field format ............................................................................. 1157 Figure 9-647â€”Channel Switch Announcement frame Action field format.............................................. 1157 Figure 9-648â€”Vendor Specific frame Action field format ...................................................................... 1172 Figure 9-649â€”Radio Measurement Request frame Action field format .................................................. 1173 Figure 9-650â€”Radio Measurement Report frame Action field format .................................................... 1174 Figure 9-651â€”Link Measurement Request frame Action field format .................................................... 1174 Figure 9-652â€”Link Measurement Report frame Action field format ...................................................... 1175 Figure 9-653â€”Neighbor Report Request frame Action field format........................................................ 1176 Figure 9-654â€”Neighbor Report Response frame Action field format ..................................................... 1176 Figure 9-655â€”Measurement Pilot frame Action field format .................................................................. 1179 Figure 9-656â€”Condensed Capability Information field........................................................................... 1179 Figure 9-657â€”DSE Enablement frame Action field format..................................................................... 1180 Figure 9-658â€”DSE Deenablement frame Action field format................................................................. 1181 Figure 9-659â€”DSE Registered Location Announcement frame Action field format .............................. 1182 Figure 9-660â€”Extended Channel Switch Announcement frame Action field format.............................. 1182 Figure 9-661â€”DSE Measurement Request frame Action field format .................................................... 1183 Figure 9-662â€”DSE Measurement Report frame Action field format ...................................................... 1184 Figure 9-663â€”DSE LCI field format........................................................................................................ 1184 Figure 9-664â€”DSE Power Constraint frame Action field format ............................................................ 1185 Figure 9-665â€”Vendor Specific Public Action frame Action field format ............................................... 1186 Figure 9-666â€”Query Request Length field .............................................................................................. 1187 Figure 9-667â€”Query Request field .......................................................................................................... 1187 Figure 9-668â€”GAS Comeback Delay field.............................................................................................. 1188 Figure 9-669â€”Query Response Length field............................................................................................ 1188 Figure 9-670â€”Query Response field ........................................................................................................ 1188 Figure 9-671â€”Location Track Notification Action field format .............................................................. 1191 Figure 9-672â€”QMF Policy frame Action field contents .......................................................................... 1192 Figure 9-673â€”QMF Policy Change Action field contents ....................................................................... 1193 Figure 9-674â€”HCCA TXOP Advertisement frame Action field format ................................................. 1194 Figure 9-675â€”HCCA TXOP Response frame Action field format.......................................................... 1195 111 Copyright Â© 2016 IEEE. All rights reserved. Figure 9-676â€”Public Key Action field format ......................................................................................... 1196 Figure 9-677â€”Channel Availability Query frame Action field format .................................................... 1197 Figure 9-678â€”Channel Schedule Management frame Action field format.............................................. 1197 Figure 9-679â€”Contact Verification Signal frame Action field format .................................................... 1199 Figure 9-680â€”GDD Enablement Request frame Action field format...................................................... 1199 Figure 9-681â€”GDD Enablement Response frame Action field format ................................................... 1200 Figure 9-682â€”Network Channel Control frame Action field format ....................................................... 1200 Figure 9-683â€”White Space Map Announcement frame Action field format .......................................... 1201 Figure 9-684â€”Fine Timing Measurement Request Action field format .................................................. 1202 Figure 9-685â€”Fine Timing Measurement Action field format ................................................................ 1203 Figure 9-686â€”Format of the TOD Error field .......................................................................................... 1203 Figure 9-687â€”Format of the TOA Error field .......................................................................................... 1203 Figure 9-688â€”FT Request frame Action field format .............................................................................. 1207 Figure 9-689â€”FT Response frame Action field format ........................................................................... 1207 Figure 9-690â€”FT Confirm frame Action field format ............................................................................. 1208 Figure 9-691â€”FT Ack frame Action field format .................................................................................... 1209 Figure 9-692â€”SA Query Request frame Action field format .................................................................. 1210 Figure 9-693â€”SA Query Response frame Action field format ................................................................ 1210 Figure 9-694â€”Event Request Action field format.................................................................................... 1226 Figure 9-695â€”Event Report Action field format...................................................................................... 1227 Figure 9-696â€”Diagnostic Request Action field format............................................................................ 1227 Figure 9-697â€”Diagnostic Report Action field format.............................................................................. 1227 Figure 9-698â€”Location Configuration Request Action field format ....................................................... 1228 Figure 9-699â€”Location Configuration Response Action field format..................................................... 1229 Figure 9-700â€”BSS Transition Management Query Action field format ................................................. 1230 Figure 9-701â€”BSS Transition Management Request Action field format .............................................. 1230 Figure 9-702â€”Request Mode field ........................................................................................................... 1231 Figure 9-703â€”Disassociation Timer field format..................................................................................... 1232 Figure 9-704â€”Session Information URL field format ............................................................................. 1232 Figure 9-705â€” BSS Transition Management Response Action field format ........................................... 1232 Figure 9-706â€”FMS Request Action field format ..................................................................................... 1233 Figure 9-707â€”FMS Response Action field format .................................................................................. 1234 Figure 9-708â€”Collocated Interference Request Action field format ....................................................... 1234 Figure 9-709â€”Request Info field format .................................................................................................. 1235 Figure 9-710â€”Collocated Interference Report Action field format ......................................................... 1235 Figure 9-711â€”TFS Request frame format ................................................................................................ 1236 Figure 9-712â€”TFS Response Action field format.................................................................................... 1236 Figure 9-713â€”TFS Notify Action field format ........................................................................................ 1237 Figure 9-714â€”TFS Notify Response Action field format ........................................................................ 1237 Figure 9-715â€”WNM Sleep Mode Request frame format ........................................................................ 1238 Figure 9-716â€”WNM Sleep Mode Response Action field format ............................................................ 1238 Figure 9-717â€”WNM Sleep Mode GTK subelement format .................................................................... 1239 Figure 9-718â€”WNM Sleep Mode IGTK subelement format................................................................... 1239 Figure 9-719â€”TIM Broadcast Request Action field format..................................................................... 1240 Figure 9-720â€”TIM Broadcast Response Action field format .................................................................. 1240 Figure 9-721â€”QoS Traffic Capability Update Action field format ......................................................... 1241 Figure 9-722â€”Channel Usage Request Action field format..................................................................... 1242 Figure 9-723â€”Channel Usage Response Action field format .................................................................. 1242 Figure 9-724â€”DMS Request Action field format .................................................................................... 1243 Figure 9-725â€”DMS Response Action field format.................................................................................. 1243 Figure 9-726â€”Timing Measurement Request Action field format .......................................................... 1244 Figure 9-727â€”WNM Notification Request Action field format .............................................................. 1244 Figure 9-728â€”WNM Notification Response Action field format ............................................................ 1245 Figure 9-729â€”TIM Action field format ................................................................................................... 1246 112 Copyright Â© 2016 IEEE. All rights reserved. Figure 9-730â€”Timing Measurement Action field format ........................................................................ 1246 Figure 9-731â€”SCS Request frame Action field format ........................................................................... 1261 Figure 9-732â€”SCS Response frame Action field format ......................................................................... 1261 Figure 9-733â€”SCS Status duple format ................................................................................................... 1261 Figure 9-734â€”Group Membership Request frame Action field format ................................................... 1262 Figure 9-735â€”Group Membership Response frame Action field format................................................. 1262 Figure 9-736â€”DTP Request frame Action field format ........................................................................... 1267 Figure 9-737â€”DTP Report frame Action field format ............................................................................. 1268 Figure 9-738â€”Channel Measurement Info field format ........................................................................... 1270 Figure 9-739â€”Relay Operation Type field format ................................................................................... 1277 Figure 9-740â€”Definition of the OCT MMPDU field............................................................................... 1282 Figure 9-741â€”A-MPDU format ............................................................................................................... 1287 Figure 9-742â€”EOF Padding field format ................................................................................................. 1287 Figure 9-743â€”A-MPDU subframe format ............................................................................................... 1288 Figure 9-744â€”MPDU delimiter (non-DMG) ........................................................................................... 1288 Figure 9-745â€”MPDU delimiter (DMG)................................................................................................... 1288 Figure 9-746â€”MPDU Length field (non-DMG) ...................................................................................... 1289 Figure 9-747â€”MPDU delimiter CRC calculation .................................................................................... 1290 Figure 10-1â€”Non-DMG STA MAC architecture..................................................................................... 1295 Figure 10-2â€”DMG STA MAC architecture............................................................................................. 1296 Figure 10-3â€”Fragmentation ..................................................................................................................... 1302 Figure 10-4â€”Some IFS relationships ....................................................................................................... 1306 Figure 10-5â€”RTS/CTS/data/Ack and NAV setting ................................................................................. 1311 Figure 10-6â€”RTS/CTS with fragmented MSDU ..................................................................................... 1312 Figure 10-7â€”RTS/CTS with transmitter priority and missed acknowledgment ...................................... 1312 Figure 10-8â€”Example of dual CTS mechanism (STBC initiator) ........................................................... 1316 Figure 10-9â€”Example of dual CTS mechanism (non-STBC initiator) .................................................... 1316 Figure 10-10â€”Individually addressed data/Ack/BA frame ...................................................................... 1317 Figure 10-11â€”Example of TXOP containing VHT MU PPDU transmission with immediate acknowledgment to VHT MU PPDU ............................................................................ 1318 Figure 10-12â€”Example of TXOP containing VHT MU PPDU transmission with no immediate acknowledgment to VHT MU PPDU ............................................................................ 1318 Figure 10-13â€”Example of exponential increase of CW........................................................................... 1324 Figure 10-14â€”Basic access method.......................................................................................................... 1325 Figure 10-15â€”Backoff procedure............................................................................................................. 1326 Figure 10-16â€”Example topology of NAV setting in DMG STAs ........................................................... 1327 Figure 10-17â€”Backoff procedure for DMG STAs................................................................................... 1327 Figure 10-18â€”Transmission of a multiple-fragment MSDU using SIFS................................................. 1329 Figure 10-19â€”DCF timing relationships .................................................................................................. 1331 Figure 10-20â€”CFP/CP alternation ........................................................................................................... 1335 Figure 10-21â€”Beacon frames and CFPs .................................................................................................. 1336 Figure 10-22â€”Example of delayed beacon and shortened CFP ............................................................... 1336 Figure 10-23â€”Example of PCF frame transfer ........................................................................................ 1338 Figure 10-24â€”Reference implementation model when dot11AlternateEDCAActivated is false or not present...................................................................................................................... 1378 Figure 10-25â€”Reference implementation model when dot11AlternateEDCAActivated is true ............. 1378 Figure 10-26â€”EDCA mechanism timing relationships............................................................................ 1382 Figure 10-27â€”Illustration of TXOP sharing and PPDU construction...................................................... 1385 Figure 10-28â€”Example of TXOP truncation ........................................................................................... 1389 Figure 10-29â€”CAP/CFP/CP periods ........................................................................................................ 1394 Figure 10-30â€”Polled TXOP ..................................................................................................................... 1396 Figure 10-31â€”Example MCCAOP reservation with MCCAOP Periodicity equal to 2 .......................... 1406 Figure 10-32â€”Message sequence chart for block ack mechanism: (a) setup, (b) data and acknowledgment transfer, and (c) teardown.................................................................. 1416 113 Copyright Â© 2016 IEEE. All rights reserved. Figure 10-33â€”Typical block ack sequence when immediate policy is used............................................ 1419 Figure 10-34â€”Typical block ack sequence when delayed policy is used ................................................ 1420 Figure 10-35â€”HT-immediate block ack architecture............................................................................... 1423 Figure 10-36â€”Example of frame exchange with GCR block ack retransmission policy......................... 1433 Figure 10-37â€”DMG block ack architecture ............................................................................................. 1434 Figure 10-38â€”Flow control and its associated parameters as a function of receiver buffer size ............. 1435 Figure 10-39â€”Basic concept of L-SIG TXOP protection ........................................................................ 1446 Figure 10-40â€”Example of L-SIG duration setting ................................................................................... 1447 Figure 10-41â€”Illustration of PSMP sequence with and without PSMP recovery.................................... 1457 Figure 10-42â€”PSMP burst ....................................................................................................................... 1457 Figure 10-43â€”PSMP burst showing resource allocation.......................................................................... 1459 Figure 10-44â€”PSMP burst showing retransmission and resource allocation .......................................... 1459 Figure 10-45â€”Example PPDU exchange for unidirectional implicit transmit beamforming .................. 1471 Figure 10-46â€”Example PPDU exchange for bidirectional implicit transmit beamforming .................... 1472 Figure 10-47â€”Calibration procedure with sounding PPDU containing an MPDU ................................. 1474 Figure 10-48â€”Calibration procedure with NDP ...................................................................................... 1475 Figure 10-49â€”Calibration procedure with NDP when STA B supports transmitting sounding PPDUs for which only one channel dimension can be estimated (i.e., a single column of the MIMO channel matrix) .......................................................................... 1476 Figure 10-50â€”Transmit ASEL ................................................................................................................. 1483 Figure 10-51â€”Receive ASEL................................................................................................................... 1484 Figure 10-52â€”Example of the sounding protocol with a single VHT beamformee................................. 1490 Figure 10-53â€”Example of the sounding protocol with more than one VHT beamformee ...................... 1490 Figure 10-54â€”Example of access periods within a beacon interval......................................................... 1501 Figure 10-55â€”Example of frame exchanges during the ATI ................................................................... 1502 Figure 10-56â€”The guard time .................................................................................................................. 1509 Figure 10-57â€”Example of dynamic allocation of service period mechanism.......................................... 1514 Figure 10-58â€”Decentralized AP or PCP clustering for 3 APs and PCPs ................................................ 1523 Figure 10-59â€”An example of beamforming training ............................................................................... 1533 Figure 10-60â€”An example of SLS ........................................................................................................... 1536 Figure 10-61â€”An example of SLS ........................................................................................................... 1536 Figure 10-62â€”Initiator TXSS or initiator RXSS ...................................................................................... 1538 Figure 10-63â€”Responder TXSS or responder RXSS............................................................................... 1540 Figure 10-64â€”Example of beam refinement transaction.......................................................................... 1544 Figure 10-65â€”Example of BRP setup subphase procedure (SLS in BTI and A-BFT) ............................ 1547 Figure 10-66â€”Example of skipping the BRP setup subphase (SLS in DTI) ........................................... 1547 Figure 10-67â€”A-BFT structure ................................................................................................................ 1550 Figure 10-68â€”SSW slot (aSSSlotTime) definition .................................................................................. 1550 Figure 10-69â€”Example of time allocation for the MIDC subphase with MID and BC subphases ......... 1555 Figure 10-70â€”Example of time allocation for the MIDC subphase with the MID subphase only .......... 1555 Figure 10-71â€”Example of using BRP setup subphase to set up subsequent MIDC subphase in A-BFT and DTI ............................................................................................................. 1556 Figure 10-72â€”Example of using BRP setup subphase to set up subsequent MIDC subphase in DTI..... 1557 Figure 10-73â€”Conceptual flow of sample MIDC subphase execution with MID and BC subphases for initiator link .............................................................................................................. 1558 Figure 10-74â€”Examples of using MID Extension field during execution of MID subphase .................. 1560 Figure 10-75â€”Beam combining ............................................................................................................... 1561 Figure 10-76â€”Conceptual flow of sample MIDC subphase execution with only MID subphase for initiator link .............................................................................................................. 1561 Figure 10-77â€”Example of using BRP setup subphase to set up subsequent R-MID subphase ............... 1562 Figure 10-78â€”Example beam refinement transaction (receive training) ................................................. 1565 Figure 10-79â€”Example beam refinement transaction (transmit training)................................................ 1565 Figure 10-80â€”Example beam refinement transaction (combination of receive and transmit training) ... 1565 Figure 10-81â€”Example of beam tracking procedure with initiator requesting TRN-R ........................... 1567 114 Copyright Â© 2016 IEEE. All rights reserved. Figure 10-82â€”Example of beam tracking procedure with initiator requesting TRN-T ........................... 1568 Figure 10-83â€”SLS phase state machine (initiator) .................................................................................. 1569 Figure 10-84â€”SLS phase state machine (responder) ............................................................................... 1569 Figure 10-85â€”Example of fast link adaptation procedure ....................................................................... 1572 Figure 10-86â€”Example of Normal mode operation with FD-AF relay ................................................... 1575 Figure 10-87â€”Example of operation with HD-DF relay.......................................................................... 1577 Figure 10-88â€”TPA mechanism ................................................................................................................ 1578 Figure 10-89â€”Example of data transmission in SP with link cooperation relay ..................................... 1579 Figure 11-1â€”Beacon transmission on a busy network ............................................................................. 1583 Figure 11-2â€”Example of DMG beacon transmission by an AP or PCP during the BTI ......................... 1584 Figure 11-3â€”Beacon transmission in an IBSS ......................................................................................... 1587 Figure 11-4â€”Probe response .................................................................................................................... 1592 Figure 11-5â€”Active scanning for DMG STAs......................................................................................... 1593 Figure 11-6â€”PCP factor for a DMG STA ................................................................................................ 1596 Figure 11-7â€”Infrastructure power management operation (no PCF operating)....................................... 1603 Figure 11-8â€”Power management in an IBSSâ€”basic operation .............................................................. 1627 Figure 11-9â€”State transition diagram of non-AP and non-PCP STA in active and PS modes................ 1633 Figure 11-10â€”State transition diagram of PCP power management mode.............................................. 1637 Figure 11-11â€”Example operation of PPS mode ...................................................................................... 1639 Figure 11-12â€”Example of ATIM frame response behavior in PS mode ................................................. 1640 Figure 11-13â€”Relationship between state and services between a given pair of nonmesh STAs ........... 1643 Figure 11-14â€”TS life cycle ...................................................................................................................... 1663 Figure 11-15â€”TS setup............................................................................................................................. 1664 Figure 11-16â€”TS setup when initiated by the AP.................................................................................... 1665 Figure 11-17â€”Failed TS setup detected within non-AP STAâ€™s MLME .................................................. 1671 Figure 11-18â€”TS deletion ........................................................................................................................ 1673 Figure 11-19â€”Deletion of a TS established using a PTP TSPEC ............................................................ 1674 Figure 11-20â€”Deletion of an allocation in which both Source AID and Destination AID are not the broadcast AID ................................................................................................................ 1674 Figure 11-21â€”TS timeout......................................................................................................................... 1677 Figure 11-22â€”Block ack setup ................................................................................................................. 1680 Figure 11-23â€”Block ack deletion............................................................................................................. 1682 Figure 11-24â€”Error recovery by the receiver upon a peer failure ........................................................... 1683 Figure 11-25â€”The four steps involved in direct-link handshake ............................................................. 1685 Figure 11-26â€”DLS message flow ............................................................................................................ 1686 Figure 11-27â€”STA-initiated DLS teardown message flow ..................................................................... 1688 Figure 11-28â€”Example of Measurement Pilot frame scheduling ............................................................ 1736 Figure 11-29â€”Dependent STA state machine .......................................................................................... 1743 Figure 11-30â€”Phased coexistence operation (PCO) ................................................................................ 1759 Figure 11-31â€”Events occurring for a TDLS direct-link channel switch.................................................. 1771 Figure 11-32â€”STA transmission on three channels, three frames per channel with Normal Report Interval ........................................................................................................................... 1785 Figure 11-33â€”Timing measurement procedure........................................................................................ 1788 Figure 11-34â€”Concurrent FTM sessions ................................................................................................. 1790 Figure 11-35â€”Example negotiation and measurement exchange sequence, ASAP=0, and FTMs per Burst = 2 .................................................................................................................. 1794 Figure 11-36â€”Example negotiation and measurement exchange sequence, ASAP=1, and FTMs per Burst = 2 .................................................................................................................. 1795 Figure 11-37â€”Example negotiation and measurement exchange sequence for a single burst instance, ASAP=1, and FTMs per Burst = 3 ................................................................................ 1796 Figure 11-38â€”GAS frame sequence with dot11GASPauseForServerResponse equal to true................. 1826 Figure 11-39â€”GAS frame sequence with GAS fragmentation and dot11GASPauseForServerResponse equal to true......................................................... 1827 115 Copyright Â© 2016 IEEE. All rights reserved. Figure 11-40â€”GAS frame sequence with GAS fragmentation and dot11GASPauseForServerResponse equal to false ....................................................... 1828 Figure 11-41â€”Example TDLS Capability discovery using ANQP.......................................................... 1837 Figure 11-42â€”Example of beamformed link maintenance ...................................................................... 1863 Figure 11-43â€”Moving the TBTT position ............................................................................................... 1868 Figure 11-44â€”Changing beacon interval duration ................................................................................... 1869 Figure 11-45â€”Example of spatial sharing assessment ............................................................................. 1871 Figure 11-46â€”Example of spatial sharing between SP1 and SP2 ............................................................ 1872 Figure 11-47â€”Procedure of the FST setup protocol................................................................................. 1875 Figure 11-48â€”States of the FST setup protocol ....................................................................................... 1876 Figure 11-49â€”On-channel tunneling procedure ....................................................................................... 1884 Figure 11-50â€”Quieting adjacent BSS operation ...................................................................................... 1893 Figure 11-51â€”Beamforming training procedure in the DTI .................................................................... 1895 Figure 11-52â€”Beamforming training when joining an infrastructure BSS or PBSS ............................... 1895 Figure 11-53â€”GDD dependent STA state transition diagram ................................................................. 1910 Figure 12-1â€”Construction of expanded WEP MPDU ............................................................................. 1928 Figure 12-2â€”WEP encapsulation block diagram ..................................................................................... 1930 Figure 12-3â€”WEP decapsulation block diagram ..................................................................................... 1930 Figure 12-4â€”SAE finite state machine..................................................................................................... 1947 Figure 12-5â€”TKIP encapsulation block diagram..................................................................................... 1954 Figure 12-6â€”TKIP decapsulation block diagram..................................................................................... 1955 Figure 12-7â€”Construction of expanded TKIP MPDU ............................................................................. 1956 Figure 12-8â€”TKIP MIC relation to IEEE 802.11 processing (informative)............................................ 1957 Figure 12-9â€”TKIP MIC processing format ............................................................................................. 1958 Figure 12-10â€”Michael message processing ............................................................................................. 1959 Figure 12-11â€”Michael block function ..................................................................................................... 1959 Figure 12-12â€”Authenticator MIC countermeasures ................................................................................ 1961 Figure 12-13â€”Supplicant MIC countermeasures ..................................................................................... 1962 Figure 12-14â€”Phase 1 key mixing ........................................................................................................... 1965 Figure 12-15â€”Phase 2 key mixing ........................................................................................................... 1966 Figure 12-16â€”Expanded CCMP MPDU .................................................................................................. 1968 Figure 12-17â€”CCMP encapsulation block diagram................................................................................. 1969 Figure 12-18â€”AAD construction ............................................................................................................. 1970 Figure 12-19â€”Nonce construction ........................................................................................................... 1971 Figure 12-20â€”Nonce Flags subfield......................................................................................................... 1971 Figure 12-21â€”CCMP decapsulation block diagram................................................................................. 1972 Figure 12-22â€”BIP Encapsulation............................................................................................................. 1975 Figure 12-23â€”BIP AAD Construction ..................................................................................................... 1975 Figure 12-24â€”Expanded GCMP MPDU.................................................................................................. 1978 Figure 12-25â€”GCMP encapsulation block diagram ................................................................................ 1978 Figure 12-26â€”Nonce construction ........................................................................................................... 1979 Figure 12-27â€”GCMP decapsulation block diagram ................................................................................ 1980 Figure 12-28â€”Pairwise key hierarchy ...................................................................................................... 2009 Figure 12-29â€”Group key hierarchy (informative) ................................................................................... 2012 Figure 12-30â€”PeerKey hierarchy............................................................................................................. 2013 Figure 12-31â€”FT key hierarchy at an Authenticator ............................................................................... 2015 Figure 12-32â€”EAPOL-Key frame ........................................................................................................... 2019 Figure 12-33â€”Key Information bit layout................................................................................................ 2019 Figure 12-34â€”KDE format....................................................................................................................... 2023 Figure 12-35â€”GTK KDE format.............................................................................................................. 2024 Figure 12-36â€”MAC address KDE format................................................................................................ 2024 Figure 12-37â€”PMKID KDE format ......................................................................................................... 2024 Figure 12-38â€”SMK KDE format ............................................................................................................. 2024 Figure 12-39â€”Nonce KDE format ........................................................................................................... 2024 116 Copyright Â© 2016 IEEE. All rights reserved. Figure 12-40â€”Lifetime KDE format ........................................................................................................ 2025 Figure 12-41â€”Error KDE format ............................................................................................................. 2025 Figure 12-42â€”IGTK KDE format ............................................................................................................ 2025 Figure 12-43â€”Key ID KDE...................................................................................................................... 2026 Figure 12-44â€”Multi-band GTK KDE ...................................................................................................... 2026 Figure 12-45â€”Multi-band Key ID KDE................................................................................................... 2027 Figure 12-46â€”Sample 4-way handshake.................................................................................................. 2038 Figure 12-47â€”Sample group key handshake............................................................................................ 2043 Figure 12-48â€”PeerKey handshake Supplicant key management state machine...................................... 2061 Figure 12-49â€”RSNA Supplicant key management state machine........................................................... 2063 Figure 12-50â€”Authenticator state machines, part 1 ................................................................................. 2065 Figure 12-51â€”Authenticator state machines, part 2 ................................................................................. 2066 Figure 12-52â€”Authenticator state machines, part 3 ................................................................................. 2066 Figure 12-53â€”Authenticator state machines, part 4 ................................................................................. 2067 Figure 13-1â€”FT key holder architecture .................................................................................................. 2090 Figure 13-2â€”FT initial mobility domain association in an RSN.............................................................. 2093 Figure 13-3â€”FT initial mobility domain association in a non-RSN ........................................................ 2095 Figure 13-4â€”Over-the-air FT protocol in an RSN ................................................................................... 2096 Figure 13-5â€”Over-the-DS FT protocol in an RSN .................................................................................. 2098 Figure 13-6â€”MLME interfaces for over-the-DS FT protocol messages.................................................. 2099 Figure 13-7â€”Over-the-air FT protocol in a non-RSN .............................................................................. 2100 Figure 13-8â€”Over-the-DS FT protocol in a non-RSN ............................................................................. 2101 Figure 13-9â€”Over-the-air FT resource request protocol in an RSN ........................................................ 2103 Figure 13-10â€”Over-the-air FT resource request protocol in a non-RSN................................................. 2103 Figure 13-11â€”Over-the-DS FT resource request protocol in an RSN ..................................................... 2105 Figure 13-12â€”Over-the-DS FT resource request protocol in a non-RSN ................................................ 2105 Figure 13-13â€”R0KH state machine ......................................................................................................... 2114 Figure 13-14â€”R1KH state machine, including portions of the SME (part 1).......................................... 2116 Figure 13-15â€”R1KH state machine, including portions of the SME (part 2).......................................... 2117 Figure 13-16â€”S0KH state machine.......................................................................................................... 2119 Figure 13-17â€”S1KH state machine, including portions of the SME (part 1) .......................................... 2121 Figure 13-18â€”S1KH state machine, including portions of the SME (part 2) .......................................... 2122 Figure 13-19â€”Sample message flow for over-the-DS resource request .................................................. 2125 Figure 13-20â€”RIC-Request format .......................................................................................................... 2127 Figure 13-21â€”Resource Request format .................................................................................................. 2127 Figure 13-22â€”Resource Request example #1 .......................................................................................... 2127 Figure 13-23â€”Resource Request example #2 .......................................................................................... 2128 Figure 13-24â€”RIC-Request example #1 .................................................................................................. 2128 Figure 13-25â€”RIC-Request example #2 .................................................................................................. 2128 Figure 13-26â€”RIC-Request example #3 .................................................................................................. 2128 Figure 13-27â€”RIC-Response format........................................................................................................ 2128 Figure 13-28â€”Example QoS RIC-Response ............................................................................................ 2128 Figure 13-29â€”Overview of RIC processing at an AP .............................................................................. 2130 Figure 14-1â€”Logical flowchart of protocol interaction in the mesh peering management framework ... 2136 Figure 14-2â€”Finite state machine of the MPM protocol.......................................................................... 2145 Figure 14-3â€”Finite state machine of the AMPE protocol........................................................................ 2156 Figure 14-4â€”Illustration of definitions..................................................................................................... 2164 Figure 14-5â€”Example of mesh power management mode usage ............................................................ 2215 Figure 14-6â€”Mesh power management operation ................................................................................... 2219 Figure 14-7â€”Mesh peer service period .................................................................................................... 2221 Figure 15-1â€”PPDU format....................................................................................................................... 2228 Figure 15-2â€”CRC-16 implementation ..................................................................................................... 2230 Figure 15-3â€”Example CRC calculation ................................................................................................... 2231 Figure 15-4â€”Data scrambler .................................................................................................................... 2231 117 Copyright Â© 2016 IEEE. All rights reserved. Figure 15-5â€”Data descrambler................................................................................................................. 2232 Figure 15-6â€”Transmit PHY ..................................................................................................................... 2232 Figure 15-7â€”PHY transmit state machine................................................................................................ 2233 Figure 15-8â€”Receive PHY....................................................................................................................... 2234 Figure 15-9â€”PHY receive state machine ................................................................................................. 2236 Figure 15-10â€”Transmit spectrum mask ................................................................................................... 2241 Figure 15-11â€”Transmit power-on ramp................................................................................................... 2242 Figure 15-12â€”Transmit power-down ramp.............................................................................................. 2242 Figure 15-13â€”Modulation accuracy measurement example .................................................................... 2243 Figure 15-14â€”Chip clock alignment with baseband eye pattern.............................................................. 2244 Figure 16-1â€”Long PPDU format ............................................................................................................. 2250 Figure 16-2â€”Short PPDU format ............................................................................................................. 2250 Figure 16-3â€”CRC-16 implementation ..................................................................................................... 2254 Figure 16-4â€”Example of CRC calculation............................................................................................... 2255 Figure 16-5â€”Data scrambler .................................................................................................................... 2256 Figure 16-6â€”Data descrambler................................................................................................................. 2257 Figure 16-7â€”Transmit PHY ..................................................................................................................... 2258 Figure 16-8â€”Receive PHY....................................................................................................................... 2259 Figure 16-9â€”PHY receive state machine ................................................................................................. 2261 Figure 16-10â€”Transmit spectrum mask ................................................................................................... 2270 Figure 16-11â€”Transmit power-on ramp................................................................................................... 2271 Figure 16-12â€”Transmit power-down ramp.............................................................................................. 2271 Figure 16-13â€”Modulation accuracy measurement example .................................................................... 2272 Figure 16-14â€”Chip clock alignment with baseband eye pattern.............................................................. 2273 Figure 17-1â€”PPDU format....................................................................................................................... 2283 Figure 17-2â€”Illustration of OFDM frame with cyclic extension and windowing for (a) single reception or (b) two receptions of the FFT period......................................................... 2287 Figure 17-3â€”Inputs and outputs of inverse Fourier transform ................................................................. 2288 Figure 17-4â€”OFDM training structure..................................................................................................... 2289 Figure 17-5â€”SIGNAL field bit assignment ............................................................................................. 2290 Figure 17-6â€”SERVICE field bit assignment ........................................................................................... 2291 Figure 17-7â€”Data scrambler .................................................................................................................... 2292 Figure 17-8â€”Convolutional encoder (k = 7) ............................................................................................ 2295 Figure 17-9â€”Example of the bit-stealing and bit-insertion procedure (r = 3/4, 2/3) ............................... 2296 Figure 17-10â€”BPSK, QPSK, 16-QAM, and 64-QAM constellation bit encoding .................................. 2299 Figure 17-11â€”Subcarrier frequency allocation ........................................................................................ 2302 Figure 17-12â€”Transmitter and receiver block diagram for the OFDM PHY .......................................... 2303 Figure 17-13â€”Transmit spectrum mask for 20 MHz transmission .......................................................... 2306 Figure 17-14â€”Transmit spectrum mask for 10 MHz transmission .......................................................... 2306 Figure 17-15â€”Transmit spectrum mask for 5 MHz transmission ............................................................ 2307 Figure 17-16â€”Constellation error............................................................................................................. 2309 Figure 17-17â€”Transmit PHY ................................................................................................................... 2313 Figure 17-18â€”PHY transmit state machine.............................................................................................. 2315 Figure 17-19â€”Receive PHY..................................................................................................................... 2316 Figure 17-20â€”PHY receive state machine ............................................................................................... 2318 Figure 19-1â€”PPDU format....................................................................................................................... 2347 Figure 19-2â€”Transmitter block diagram 1 ............................................................................................... 2350 Figure 19-3â€”Transmitter block diagram 2 .............................................................................................. 2350 Figure 19-4â€”Timing boundaries for PPDU fields.................................................................................... 2356 Figure 19-5â€”L-SIG structure ................................................................................................................... 2362 Figure 19-6â€”Format of HT-SIG1 and HT-SIG2 ..................................................................................... 2365 Figure 19-7â€”Data tone constellations in an HT-mixed format PPDU..................................................... 2366 Figure 19-8â€”HT-SIG CRC calculation .................................................................................................... 2367 Figure 19-9â€”Generation of HT-DLTFs ................................................................................................... 2371 118 Copyright Â© 2016 IEEE. All rights reserved. Figure 19-10â€”Generation of HT-ELTFs.................................................................................................. 2371 Figure 19-11â€”Puncturing at rate 5/6 ........................................................................................................ 2377 Figure 19-12â€”Examples of cyclic-permutation matrices with Z=8 ......................................................... 2379 Figure 19-13â€”LDPC PPDU encoding padding and puncturing of a single codeword ............................ 2381 Figure 19-14â€”Beamforming MIMO channel model (3x2 example) ....................................................... 2393 Figure 19-15â€”Baseband-to-baseband channel ......................................................................................... 2394 Figure 19-16â€”Example of an NDP used for sounding............................................................................. 2401 Figure 19-17â€”Transmit spectral mask for 20 MHz transmission in the 2.4 GHz band ........................... 2404 Figure 19-18â€”Transmit spectral mask for a 40 MHz channel in the 2.4 GHz band ................................ 2405 Figure 19-19â€”Transmit spectral mask for 20 MHz transmission in the 5 GHz band .............................. 2405 Figure 19-20â€”Transmit spectral mask for a 40 MHz channel in the 5 GHz band ................................... 2406 Figure 19-21â€”Packet alignment example (HT-greenfield format packet with short GI)......................... 2407 Figure 19-22â€”PHY transmit procedure (HT-mixed format PPDU) ........................................................ 2414 Figure 19-23â€”PHY transmit procedure (HT-greenfield format PPDU) .................................................. 2414 Figure 19-24â€”PHY transmit state machine.............................................................................................. 2416 Figure 19-25â€”PHY receive procedure for HT-mixed format PPDU format ........................................... 2417 Figure 19-26â€”PHY receive procedure for HT-greenfield format PPDU................................................. 2417 Figure 19-27â€”PHY receive state machine ............................................................................................... 2418 Figure 20-1â€”Transmit mask .................................................................................................................... 2440 Figure 20-2â€”Packet structure ................................................................................................................... 2444 Figure 20-3â€”Illustration of windowing function ..................................................................................... 2445 Figure 20-4â€”SC preamble ........................................................................................................................ 2446 Figure 20-5â€”OFDM preamble ................................................................................................................. 2446 Figure 20-6â€”Channel Estimation field for SC packets ........................................................................... 2447 Figure 20-7â€”Channel Estimation field for OFDM packets ..................................................................... 2447 Figure 20-8â€”Data scrambler .................................................................................................................... 2451 Figure 20-9â€”DMG control mode PPDU format ...................................................................................... 2452 Figure 20-10â€”DMG control mode preamble ........................................................................................... 2452 Figure 20-11â€”OFDM frame format ......................................................................................................... 2457 Figure 20-12â€”64-QAM modulation mapping.......................................................................................... 2463 Figure 20-13â€”SC frame format................................................................................................................ 2469 Figure 20-14â€”BPSK constellation bit encoding ...................................................................................... 2476 Figure 20-15â€”QPSK constellation bit encoding ...................................................................................... 2476 Figure 20-16â€”16-QAM constellation bit encoding.................................................................................. 2477 Figure 20-17â€”64-QAM constellation bit encoding.................................................................................. 2478 Figure 20-18â€”Block transmission ............................................................................................................ 2479 Figure 20-19â€”Blocking for DMG low-power SC mode .......................................................................... 2484 Figure 20-20â€”PHY transmit procedure.................................................................................................... 2485 Figure 20-21â€”Typical Tx state machine (Training Length = 0 is assumed; some optional features such as DMG SC low-power mode are not shown)....................................................... 2486 Figure 20-22â€”PHY receive procedure ..................................................................................................... 2487 Figure 20-23â€”Typical Rx state machine (some optional features such as DMG low-power SC mode are not shown)...................................................................................................... 2489 Figure 20-24â€”BRP packet structure......................................................................................................... 2490 Figure 20-25â€”TRN field definition.......................................................................................................... 2492 Figure 21-1â€” PHY interaction on transmit for various PPDU formats.................................................... 2511 Figure 21-2â€”PHY interaction on receive for various PPDU formats ...................................................... 2511 Figure 21-3â€”PHY-CONFIG and CCA interaction with Clause 17, Clause 19, and Clause 21 PHYs .... 2512 Figure 21-4â€”VHT PPDU format.............................................................................................................. 2514 Figure 21-5â€”Transmitter block diagram for the L-SIG and VHT-SIG-A fields ..................................... 2515 Figure 21-6â€”Transmitter block diagram for the VHT-SIG-B field of a 20 MHz, 40 MHz, and 80 MHz VHT SU PPDU................................................................................................ 2516 Figure 21-7â€”Transmitter block diagram for the VHT-SIG-B field of a 20 MHz, 40 MHz, and 80 MHz VHT MU PPDU .............................................................................................. 2516 119 Copyright Â© 2016 IEEE. All rights reserved. Figure 21-8â€”Transmitter block diagram for the VHT-SIG-B field of a 160 MHz VHT SU PPDU ....... 2517 Figure 21-9â€”Transmitter block diagram for the VHT-SIG-B field of an 80+80 MHz VHT SU PPDU . 2517 Figure 21-10â€”Transmitter block diagram for the Data field of a 20 MHz, 40 MHz, or 80 MHz VHT SU PPDU with BCC encoding ............................................................................. 2518 Figure 21-11â€”Transmitter block diagram for the Data field of a 20 MHz, 40 MHz, or 80 MHz VHT SU PPDU with LDPC encoding ........................................................................... 2518 Figure 21-12â€”Transmitter block diagram for the Data field of a 20 MHz, 40 MHz, or 80 MHz VHT MU PPDU............................................................................................................. 2519 Figure 21-13â€”Transmitter block diagram for the Data field of a 160 MHz VHT SU PPDU with BCC encoding................................................................................................................ 2520 Figure 21-14â€”Transmitter block diagram for the Data field of a 160 MHz VHT SU PPDU with LDPC encoding.............................................................................................................. 2520 Figure 21-15â€”Transmitter block diagram for the Data field of an 80+80 MHz VHT SU PPDU with BCC encoding................................................................................................................ 2521 Figure 21-16â€”Transmitter block diagram for the Data field of an 80+80 MHz VHT SU PPDU with LDPC encoding.............................................................................................................. 2522 Figure 21-17â€”Timing boundaries for VHT PPDU fields ........................................................................ 2534 Figure 21-18â€”VHT-SIG-A1 structure ..................................................................................................... 2543 Figure 21-19â€”VHT-SIG-A2 structure ..................................................................................................... 2543 Figure 21-20â€”Data tone constellation in the VHT PPDU pre-VHT modulated fields ............................ 2546 Figure 21-21â€”Generation of VHT-LTF symbols per frequency segment ............................................... 2550 Figure 21-22â€”VHT-SIG-B bits in 20 MHz, 40 MHz, 80 MHz, 160 MHz, and 80+80 MHz transmissions.................................................................................................................. 2553 Figure 21-23â€”VHT-SIG-B and SERVICE field relationship .................................................................. 2558 Figure 21-24â€”Constellation bit encoding for 256-QAM (1st quadrant).................................................. 2567 Figure 21-25â€”Constellation bit encoding for 256-QAM (2nd quadrant) ................................................ 2568 Figure 21-26â€”Constellation bit encoding for 256-QAM (3rd quadrant) ................................................. 2569 Figure 21-27â€”Constellation bit encoding for 256-QAM (4th quadrant) ................................................. 2570 Figure 21-28â€”VHT NDP format.............................................................................................................. 2580 Figure 21-29â€”Example transmit spectral mask for 20 MHz mask PPDU ............................................... 2583 Figure 21-30â€”Example transmit spectral mask for 40 MHz mask PPDU ............................................... 2583 Figure 21-31â€”Example transmit spectral mask for 80 MHz mask PPDU ............................................... 2584 Figure 21-32â€”Example transmit spectral mask for 160 MHz mask PPDU ............................................. 2584 Figure 21-33â€”Example transmit spectral mask for 80+80 MHz mask PPDU......................................... 2585 Figure 21-34â€”PHY transmit procedure for SU transmission................................................................... 2596 Figure 21-35â€”PHY transmit state machine for SU transmission............................................................. 2598 Figure 21-36â€”PHY receive procedure for SU transmission .................................................................... 2599 Figure 21-37â€”PHY receive state machine ............................................................................................... 2600 Figure 22-1â€”VHT PPDU format in TVWS bands................................................................................... 2636 Figure 22-2â€”Transmitter block diagram for the Data field of a TVHT_MODE_2N or TVHT_MODE_4N SU PPDU with BCC encoding ...................................................... 2639 Figure 22-3â€”Transmitter block diagram for the Data field of a TVHT_MODE_2N or TVHT_MODE_4N SU PPDU with LDPC encoding.................................................... 2640 Figure 22-4â€”Example transmit spectral mask for an 6+6 MHz mask PPDU .......................................... 2658 Figure D-1â€”Transmit spectrum mask and application............................................................................. 3273 Figure H-1â€”Ethertype 89-0d frame body................................................................................................. 3311 Figure I-1â€”DMG control mode preamble expressed in Ga128 and Gb128 sequences............................ 3369 Figure I-2â€”DMG control mode header coding and modulation .............................................................. 3370 Figure I-3â€”DMG control mode payload coding and modulation ............................................................ 3371 Figure I-4â€”DMG SC mode preamble expressed in Ga128 and Gb128 sequences .................................. 3372 Figure I-5â€”DMG SC mode header coding and modulation..................................................................... 3373 Figure I-6â€”DMG SC mode MCS1 payload coding and modulation ....................................................... 3376 Figure I-7â€”DMG SC mode MCS2â€”MCS12 payload coding and modulation....................................... 3377 Figure I-8â€”DMG OFDM mode preamble................................................................................................ 3381 120 Copyright Â© 2016 IEEE. All rights reserved. Figure I-9â€”DMG OFDM mode header coding ........................................................................................ 3382 Figure I-10â€”DMG OFDM mode header modulation............................................................................... 3384 Figure I-11â€”DMG OFDM mode payload coding .................................................................................... 3385 Figure I-12â€”DMG OFDM mode SQPSK payload modulation ............................................................... 3386 Figure I-13â€”DMG OFDM mode QPSK payload modulation ................................................................. 3387 Figure I-14â€”DMG OFDM mode 16-QAM payload modulation ............................................................. 3389 Figure I-15â€”DMG OFDM mode 64-QAM payload modulation ............................................................. 3390 Figure I-16â€”DMG low-power SC mode payload coding and modulation .............................................. 3392 Figure J-1â€”Randomness generating circuit.............................................................................................. 3419 Figure K-1â€”Schedule for stream from STA i .......................................................................................... 3450 Figure K-2â€”Schedule for streams from STAs i to k ................................................................................ 3451 Figure K-3â€”Reallocation of TXOPs when a stream is dropped .............................................................. 3452 Figure L-1â€”Partial Virtual Bitmap example #1 ....................................................................................... 3459 Figure L-2â€”Partial Virtual Bitmap example #2 ....................................................................................... 3460 Figure L-3â€”Partial Virtual Bitmap example #3 ....................................................................................... 3460 Figure L-4â€”Partial Virtual Bitmap example #4, Method A and Method B ............................................. 3460 Figure L-5â€”Partial Virtual Bitmap example #5, Method A or Method B ............................................... 3461 Figure L-6â€”Partial Virtual Bitmap example #6, Method A..................................................................... 3461 Figure L-7â€”Partial Virtual Bitmap example #6, Method B ..................................................................... 3462 Figure N-1â€”Very high level UML use case diagram for the AP ............................................................. 3472 Figure N-2â€”Very high level UML use case diagram for the WLAN system .......................................... 3472 Figure N-3â€”High-level UML use case diagram for the WLAN system.................................................. 3473 Figure N-4â€”High-level UML entity diagram for the WLAN system ...................................................... 3474 Figure N-5â€”AP UML composition diagram (alternate syntax) ............................................................... 3475 Figure N-6â€”High-level UML use case diagram for the AP..................................................................... 3476 Figure O-1â€”A-MPDU parsing ................................................................................................................. 3479 Figure O-2â€”Example of RD exchange sequence showing response burst .............................................. 3480 Figure O-3â€”Determination of NDP source and destination for unidirectional NDP sequences ............. 3481 Figure O-4â€”Determination of NDP source and destination for bidirectional NDP sequence ................. 3482 Figure P-1â€”Parameters recorded by Observing STA when monitoring an FTM message exchange ..... 3488 Figure R-1â€”Interworking IEEE 802.11 infrastructure supporting multiple SSPNs ................................ 3496 Figure R-2â€”Basic architecture of the interworking service ..................................................................... 3499 Figure S-1â€”Format of a CCMP-128-encrypted mesh Data frame containing a single MSDU ............... 3510 Figure V-1â€”Example of TSPEC aggregation (SPCA and EDCA access policies) ................................. 3531 Figure V-2â€”Example of TSPEC aggregation (SPCA, EDCA, and SEMM access policies)................... 3532 121 Copyright Â© 2016 IEEE. All rights reserved. IEEE Standard for Information technologyâ€” Telecommunications and information exchange between systems Local and metropolitan area networksâ€” Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications 1. Overview 1.1 Scope The scope of this standard is to define one medium access control (MAC) and several physical layer (PHY) specifications for wireless connectivity for fixed, portable, and moving stations (STAs) within a local area. 1.2 Purpose The purpose of this standard is to provide wireless connectivity for fixed, portable, and moving stations within a local area. This standard also offers regulatory bodies a means of standardizing access to one or more frequency bands for the purpose of local area communication. 1.3 Supplementary information on purpose Specifically, in the context of IEEE 802.11â„¢-compliant devices, this standard â€” Describes the functions and services required by a device to operate within independent, personal, and infrastructure networks as well as the aspects of device mobility (transition) within those networks. â€” Describes the functions and services that allow a device to communicate directly with another such device outside of an independent or infrastructure network. â€” Defines the MAC procedures to support the MAC service data unit (MSDU) delivery services. â€” Defines several PHY signaling techniques and interface functions that are controlled by the MAC. â€” Permits the operation of a device within a wireless local area network (WLAN) that coexists with multiple overlapping IEEE 802.11 WLANs. â€” Describes the requirements and procedures to provide data confidentiality of user information and MAC management information being transferred over the wireless medium (WM) and authentication of devices. â€” Defines mechanisms for dynamic frequency selection (DFS) and transmit power control (TPC) that may be used to satisfy regulatory requirements for operation in any band. 122 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” Defines the MAC procedures to support local area network (LAN) applications with quality-of- service (QoS) requirements, including the transport of voice, audio, and video. â€” Defines mechanisms and services for wireless network management of devices that include BSS transition management, channel usage and coexistence, collocated interference reporting, diagnostic, multicast diagnostic and event reporting, flexible multicast, efficient beacon mechanisms, proxy ARP advertisement, location, timing measurement, directed multicast, extended sleep modes, traffic filtering, and management notification. â€” Defines functions and procedures aiding network discovery and selection by devices, information transfer from external networks using QoS mapping, and a general mechanism for the provision of emergency services. â€” Defines the MAC procedures that are necessary for wireless multi-hop communication to support wireless LAN mesh topologies. â€” Defines medium access control mechanisms to support the prioritization of Management frames. â€” Defines mechanisms to improve audio video (AV) streaming QoS while maintaining data and voice performance. â€” Defines the PHY signaling, MAC, and beamforming procedures required for operation with directional antenna patterns. 1.4 Word usage In this document, the word shall is used to indicate a mandatory requirement. The word should is used to indicate a recommendation. The word may is used to indicate a permissible action. The word can is used for statements of possibility and capability. The construction â€œx to yâ€ or â€œx-yâ€ represents an inclusive range (i.e., the range includes both values x and y). The construction â€œup to yâ€ represents an inclusive upper bound (i.e., the range includes the value y). Any action specified as relating to a SAP primitive is to be interpreted as an action on an invocation or instance of that primitive. If represents a scalar field, scalar subfield, scalar parameter or scalar MIB attribute: â€” if â€œ isâ€ is used in a context that relates to the testing or setting the value of â€œâ€ this usage is to be interpreted as though written â€œthe value of isâ€ â€” â€œ indicate(s)â€ is to be interpreted as though written â€œthe value of indicate(s)â€ â€” â€œindicated by â€ is to be interpreted as though written â€œindicated by the value of â€ â€” â€œ that indicateâ€ is to be interpreted as though written â€œ whose value indicatesâ€ If represents a frame, element, subelement, structured field, structured subfield, structured parameter or structured MIB attribute: â€” â€œ indicate(s)â€ is to be interpreted as though written â€œthe contents of indicateâ€ â€” â€œindicated by â€ is to be interpreted as though written â€œindicated by the contents of â€ â€” â€œ that indicateâ€ is to be interpreted as though written â€œ whose contents indicateâ€ If represents a SAP primitive: â€” â€œ indicate(s)â€ is to be interpreted as though written â€œthe (or an) invocation of indicatesâ€ â€” â€œindicated by â€ is to be interpreted as though written â€œindicated by the (or an) invocation of â€ 123 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The construction of descriptions for uses of the SHA family of hash functions [HMAC-]SHA-<1,256,384>[- n] is used to refer to hash functions/HMACs where square brackets indicate optional information, and n is an integer indicating the length, in bits, of the output when truncating. 1.5 Terminology for mathematical, logical, and bit operations Floor (x), also written as x , is the largest integer smaller than or equal to x. For example, Floor (2.3) is 2 and Floor (â€“2.3) is â€“3. The two parameter form, Floor (x, y), is the largest multiple of y smaller than or equal to x; this operator is not used in this standard if y is negative. For example, Floor (3.3, 2) is 2 and Floor (â€“3.3, 2) is â€“4. Ceil (x), also written as x is the smallest integer larger than or equal to x. For example, Ceil (2.3) is 3 and Ceil (â€“2.3) is â€“2. The two parameter form, Ceil (x, y), is the smallest multiple of y larger than or equal to x; this operator is not used in this standard if y is negative. For example, Ceil (2.3, 2) is 4 and Ceil (â€“2.3, 2) is â€“2. Round (x) is the integer closest to x, rounding values with a fractional part of 0.5 away from zero. For example, Round (2.3) is 2, Round (2.5) is 3, Round (â€“2.3) is â€“2 and Round (â€“2.5) is â€“3. x mod y is the remainder when x is divided by y; this operator is not used in this standard if y is negative; the result is positive even if x is negative. For example, 5 mod 3 is 2 and â€“5 mod 3 is 1. The symbol represents bitwise exclusive OR (XOR). log2 (x) is the logarithm of x to the base 2. For example, log2 (32) is 5. Re (z) is the real part of complex number z. Im (z) is the imaginary part of complex number z (not including the factor i). For example, Re (1 â€“ 2i) is 1 and Im (1 â€“ 2i) is â€“2. x && y is the short-circuiting Boolean AND. x || y is the concatenation of x and y, except in code, where it sometimes is the short-circuiting Boolean OR (as determined by the context). !x is the Boolean NOT. x >> y is x logically shifted right (i.e., zeros are inserted at the most significant end) by y; this operator is not used in this standard if y is negative. x << y is x shifted left (i.e., zeros are inserted at the least significant end) by y; this operator is not used in this standard if y is negative. x == y is Boolean equality. x != y Boolean inequality. x & y, where x and y are numbers, is the bitwise AND of x and y. x | y, where x and y are numbers, is the bitwise OR of x and y. 0x introduces a hexadecimal number. For example, 0x12 is 18 decimal. 124 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications L (S, F, N) is bits F to F+Nâ€“1 of the bit string S starting from the left, using the IEEE 802.11 bit conventions from 9.2.2. Truncate-N (S) is bits 0 to Nâ€“1 of the bit string S starting from the left, using the IEEE 802.11 bit conventions from 9.2.2). Other bits are irretrievably deleted. exp (x) is e to the power x, where e is the base of natural logarithms. 2. Normative references The following referenced documents are indispensable for the application of this standard (i.e., they must be understood and used; therefore, each referenced document is cited in the text and its relationship to this document is explained). For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments or corrigenda) at the time of publication of this standard applies. 3GPP TS 24.302, Access to the 3GPP Evolved Packet Core (EPC) via non-3GPP access networks; Stage 3.1 ETSI EN 301 893, Broadband Radio Access Networks (BRAN); 5 GHz high performance RLAN; Part 2: Harmonized EN covering essential requirements of article 3.2 of the R&TTE Directive.2 FIPS PUB 180-4, Secure Hash Standard.3 FIPS PUB 197, Advanced Encryption Standard (AES). IANA EAP Method Type Numbers, http://www.iana.org/assignments/eap-numbers. IEEE Std 754â„¢-2008, IEEE Standard for Binary Floating-Point Arithmetic.4,5 IEEE Std 802Â®-2014, IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture. IEEE Std 802.1ASâ„¢, IEEE Standard for Local and Metropolitan Area Networksâ€”Timing and Synchronization for Time-Sensitive Applications in Bridged Local Area Networks. IEEE Std 802.1Qâ„¢-2003, IEEE Standard for Local and Metropolitan Area Networks: Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks. IEEE Std 802.1Qâ„¢-2011, IEEE Standard for Local and Metropolitan Area Networks: Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks. IEEE Std 802.1Xâ„¢-2010, IEEE Standard for Local and Metropolitan Area Networks: Port-Based Network Access Control. IEEE Std 802.21â„¢-2008, IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Services. 13GPPâ„¢ documents are available from the 3rd Generation Partnership Project Web site (http://www.3gpp.org). 2 ETSI documents are available from the European Telecommunications Standards Institute (http://www.etsi.org). 3 FIPS publications are available from the National Technical Information Service (NTIS) (http://csrc.nist.gov). 4The IEEE standards or products referred to in this clause are trademarks owned by The Institute of Electrical and Electronics Engineers, Inc. 5 IEEE publications are available from The Institute of Electrical and Electronics Engineers (http://standards.ieee.org/). 125 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications IEEE Std 802.3â„¢-2012, IEEE Standard for Ethernet. IETF RFC 791, Internet Protocol, Sept. 1981.6 IETF RFC 826, An Ethernet Address Resolution Protocol, David C. Plummer, November 1982. IETF RFC 925, Multi-LAN Address Resolution, J. Postel, Oct. 1984. IETF RFC 1035, Domain Names â€” Implementation and Specification, P. Mockapetris, Nov. 1987. IETF RFC 1042, A Standard for the Transmission of IP Datagrams over IEEE 802Â® Networks, J. Postel, J. Reynolds, Feb. 1988. IETF RFC 1321, The MD5 Message-Digest Algorithm, Apr. 1992 (status: informational). IETF RFC 2104, HMAC: Keyed-Hashing for Message Authentication, H. Krawczyk, M. Bellare, R. Canetti, Feb. 1997 (status: informational). IETF RFC 2409, The Internet Key Exchange (IKE), D. Harkins, D. Carrel, Nov. 1998 (status: Standards Track). IETF RFC 2460, Internet Protocol, Version 6 (IPv6), S. Deering, R. Hinden, Dec. 1998. IETF RFC 5424, The Syslog Protocol, R. Gerhards, March 2009. IETF RFC 3394, Advanced Encryption Standard (AES) Key Wrap Algorithm, J. Schaad, R. Housley, Sept. 2002 (status: informational). IETF RFC 3610, Counter with CBC-MAC (CCM), D. Whiting, R. Housley, N. Ferguson, Sept. 2003 (status: informational). IETF RFC 3629, UTF-8, a transformation format of ISO 10646, F. Yergeau, Nov. 2003. IETF RFC 3748, Extensible Authentication Protocol (EAP), B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, H. Levkowetz, June 2004. IETF RFC 3986, Uniform Resource Identifier (URI): Generic Syntax, Jan. 2005. IETF RFC 4017, Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs, D. Stanley, J. Walker, B. Aboba, Mar. 2005 (status: informational). IETF RFC 4119, A Presence-based GEOPRIV Location Object Format, J. Peterson, December 2005. IETF RFC 4282, The Network Access Identifier, Dec. 2005. IETF RFC 4776, Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information, Nov. 2006. IETF RFC 4861, Neighbor Discovery for IP version 6 (IPv6), T. Narten, E. Nordmark, W. Simpson, H. Soliman, Sept. 2007. IETF RFC 5216, The EAP-TLS Authentication Protocol, D. Simon, B. Aboba, R. Hurst, March 2008. 6 IETF documents (i.e., RFCs) are available for download at http://tools.ietf.org/html/ and http://tools.ietf.org/pdf/. 126 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications IETF RFC 5227, IPv4 Address Conflict Detection, S. Cheshire, July 2008. IETF RFC 5297, Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES), D. Harkins, October 2008 (status: informational). IETF RFC 5985, HTTP-Enabled Location Delivery (HELD), M. Barnes (Ed.), September 2010. IETF RFC 6225, Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information, J. Polk, M. Linsner, M. Thomson, B. Aboba, July 2011. ISO 639, Codes for the Representation of Names of Languages. ISO 14962:1997, Space data and information transfer systems â€” ASCII encoded English. ISO 3166-1, Codes for the representation of names of countries and their subdivisionsâ€”Part 1: Country codes.7 ISO 3166-2, Codes for the representation of names of countries and their subdivisionsâ€” Part 2: Country subdivision code. ISO 4217 Currency codes.8 ISO/IEC 7498-1:1994, Information technologyâ€”Open Systems Interconnectionâ€”Basic Reference Model: The Basic Model. ISO/IEC 8802-2:1998, Information technologyâ€”Telecommunications and information exchange between systemsâ€”Local and metropolitan area networksâ€”Specific requirementsâ€”Part 2: Logical link control. ISO/IEC 8824-1:1995, Information technologyâ€”Abstract Syntax Notation One (ASN.1): Specification of basic notation. ISO/IEC 8824-2:1995, Information technologyâ€”Abstract Syntax Notation One (ASN.1): Information object specification. ISO/IEC 8824-3:1995, Information technologyâ€”Abstract Syntax Notation One (ASN.1): Constraint specification. ISO/IEC 8824-4:1995, Information technologyâ€”Abstract Syntax Notation One (ASN.1): Parameterization of ASN.1 specifications. ISO/IEC 11802-5:1997, Information technologyâ€”Telecommunications and information exchange between systemsâ€”Local and metropolitan area networksâ€”Technical reports and guidelinesâ€”Part 5: Medium Access Control (MAC) Bridging of Ethernet V2.0 in Local Area Networks (previously known as IEEE Std 802.1H-1997 [B24]9). ISO/IEC 15802-3, Information Technologyâ€”Telecommunications and information exchange between systemsâ€”Local and metropolitan area networksâ€”Common specificationsâ€”Part 3: Media Access Control (MAC) Bridges. 7 ISO/IEC publications are available from the ISO Central Secretariat (http://www.iso.ch/). ISO/IEC publications are also available in the United States from the American National Standards Institute (http://www.ansi.org/). 8See http://www.currency-iso.org/en/home/tables/table-a1.html 9 The numbers in brackets correspond to the numbers of the bibliography in Annex A. 127 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ITU-R Recommendation TF.460-4(2002), Standard-frequency and time-signal emissions.10 ITU-T Recommendation O.150, General requirements for instrumentation for performance measurements on digital transmission equipment. ITU-T Recommendation Z.120 (2004), Programming Languagesâ€”Formal Description Techniques (FDT)â€”Message Sequence Chart (MSC). NIST Special Publication 800-38B, Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication, Dworkin, M.11 NIST Special Publication 800-38D, Recommendation for Block Cipher Modes of Operation: Galois/ Counter Mode (GCM) and GMAC, Morris Dworkin, November 2007. OASIS Emergency Management Technical Committee, â€œEmergency Data Exchange Language (EDXL) Distribution Element, v. 1.0.â€ OASIS Standard EDXL-DE v1.0, May 2006. OMA OMA-TS-ULP-V2_0_1 UserPlane Location Protocol, December 2012.12 3. Definitions, acronyms, and abbreviations 3.1 Definitions For the purposes of this standard, the following terms and definitions apply. IEEE Standards Dictionary Online should be referenced for terms not defined in this clause.13 access control: The prevention of unauthorized usage of resources. access point (AP): An entity that contains one station (STA) and provides access to the distribution services, via the wireless medium (WM) for associated STAs. An AP comprises a STA and a distribution system access function (DSAF). access point (AP) reachability: An AP is reachable by a station (STA) if preauthentication messages can be exchanged between the STA and the target AP via the distribution system (DS). NOTEâ€”Preauthentication is defined in 12.6.10.2.14 additional authentication data (AAD): Data that are not encrypted, but are cryptographically protected. admission control: An algorithm intended to prevent the violation of parameterized service commitments made by the network to admitted flows by controlling the admittance of a new flow into a resource constrained network. aggregate medium access control (MAC) protocol data unit (A-MPDU): A structure that contains one or more MPDUs and is transported by a physical layer (PHY) as a single PHY service data unit (PSDU). 10ITU publications are available from the International Telecommunications Union (http://www.itu.int/). 11 NIST publications are available from the National Institute of Standards and Technology (http://csrc.nist.gov/). 12 OMA publications are available from the Open Mobile Alliance (http://openmobilealliance.org/). 13IEEE Standards Dictionary Online is available at http://ieeexplore.ieee.org/xpls/dictionary.jsp. 14 Notes in text, tables, and figures of a standard are given for information only and do not contain requirements needed to implement the standard. 128 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications aggregate medium access control (MAC) protocol data unit (A-MPDU) subframe: A portion of an A- MPDU that contains a delimiter and optionally contains an MPDU plus any necessary padding. aggregate medium access control (MAC) service data unit (A-MSDU): A structure that contains one or more MSDUs and is transported within a single (unfragmented) data medium access control (MAC) protocol data unit (MPDU). aggregate medium access control (MAC) service data unit (A-MSDU) subframe: A portion of an A-MSDU that contains a header and associated MSDU. antenna connector: The measurement point of reference for radio frequency (RF) measurements in a station (STA). The antenna connector is the point in the STA architecture representing the input of the receiver (output of the antenna) for radio reception and the input of the antenna (output of the transmitter) for radio transmission. In systems using multiple antennas or antenna arrays, the antenna connector is a virtual point representing the aggregate output of (or input to) the multiple antennas. In systems using active antenna arrays with processing, the antenna connector is the output of the active array, which includes any processing gain of the active antenna subsystem. antenna selection (ASEL) receiver: A station (STA) that performs receive ASEL. antenna selection (ASEL) transmitter: A station (STA) that performs transmit ASEL. antenna weight vector (AWV): A vector of weights describing the excitation (amplitude and phase) for each element of an antenna array. association: The service used to establish access point/station (AP/STA) mapping and enable STA invocation of the distribution system services (DSSs). authentication: The service used to establish the identity of one station (STA) as a member of the set of STAs authorized to associate with another STA. Authentication Server (AS): An entity that provides an authentication service to an Authenticator. This service determines, from the credentials provided by the Supplicant, whether the Supplicant is authorized to access the services provided by the Authenticator. (IEEE Std 802.1X-201015) Authenticator: An entity at one end of a point-to-point LAN segment that facilitates authentication of the entity attached to the other end of that link. (IEEE Std 802.1X-2010) authenticator address (AA): The medium access control (MAC) address of the IEEE 802.1X Authenticator. authorization: The act of determining whether a particular right, such as access to a resource, is granted to an entity. NOTEâ€”See IETF RFC 2903 [B35]. authorized: To be explicitly allowed. average noise plus interference power indicator (ANIPI): A medium access control (MAC) indication of the average noise plus interference power measured on a channel that meets the two simultaneous conditions: 1) the station (STA) is not transmitting a frame, and 2) the station (STA) is not receiving a frame addressed to itself. 15 Information on references can be found in Clause 2. 129 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications azimuth: The horizontal orientation of the front surface of a station or of a radio antenna systemâ€™s main lobe measured clockwise from true north. basic service area (BSA): The area containing the members of a basic service set (BSS). It might contain members of other BSSs. basic service set (BSS): A set of stations (STAs) that have successfully synchronized using the JOIN service primitives16 and one STA that has used the START primitive. Alternatively, a set of STAs that have used the START primitive specifying matching mesh profiles where the match of the mesh profiles has been verified via the scanning procedure. Membership in a BSS does not imply that wireless communication with all other members of the BSS is possible. basic service set (BSS) max idle period: A time period during which the access point (AP) does not disassociate a station (STA) due to nonreceipt of frames from that STA. basic service set (BSS) transition: Change of association by a station (STA) from one BSS to another BSS in the same extended service set (ESS). beamformee: A station (STA) that receives a physical layer (PHY) protocol data unit (PPDU) that was transmitted using a beamforming steering matrix. beamformer: A station (STA) that transmits a physical layer (PHY) protocol data unit (PPDU) using a beamforming steering matrix. beamforming: A spatial filtering mechanism used at a transmitter to improve the received signal power or signal-to-noise ratio (SNR) at an intended receiver. Syn: beam steering. beamforming steering matrix: A matrix determined using knowledge of the channel between a transmitter and an intended receiver that maps from space-time streams to transmit antennas with the goal of improving the signal power or signal-to-noise ratio (SNR) at the intended receiver. big endian: The concept that, for a given multi-octet numeric representation, the most significant octet has the lowest address. broadcast address: A unique group address that specifies all stations (STAs). calibration initiator: A station (STA) that initiates a calibration sequence. calibration responder: A station (STA) that transmits during a calibration sequence in response to a transmission by a calibration initiator. candidate peer mesh station (STA): A neighbor mesh STA to which a mesh peering has not been established but meets eligibility requirements to become a peer mesh STA. channel: An instance of wireless medium (WM) use for the purpose of passing physical layer (PHY) protocol data units (PDUs) between two or more stations (STAs). channel spacing: The difference between the center frequencies of two nonoverlapping and adjacent channels of the radio transmitter. cipher suite: A set of one or more algorithms, designed to provide data confidentiality, data authenticity or integrity, and/or replay protection. 16 Description of these primitives can be found in 6.3.4. 130 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications clear channel assessment (CCA) function: The logical function in the physical layer (PHY) that determines the current state of use of the wireless medium (WM). collocated interference: Interference that is caused by another radio or station (STA) emitting radio energy located in the same physical device as the reporting STA, where the reported characteristics of the interference are known a priori without interference detection, measurement, or characterization by the reporting STA. collocated radio: A radio capable of emitting radio-frequency energy located in the same physical device as the reporting station (STA), where the radioâ€™s type and some link characteristics are known without signal detection or measurement by the reporting STA. configuration profile: A collection of parameters identified by a profile identifier (ID) that represent a current or available configuration of a station (STA). contiguous transmission: A transmission that uses only one frequency segment. coordination function: The logical function that determines when a station (STA) is permitted to transmit protocol data units (PDUs) via the wireless medium (WM). Counter mode with Cipher-block chaining Message authentication code (CCM): A symmetric key block cipher mode providing confidentiality using counter mode (CTR) and data origin authenticity using cipher-block chaining message authentication code (CBC-MAC). NOTEâ€”See IETF RFC 3610. cryptographic encapsulation: The process of generating the cryptographic payload from the plaintext data. This comprises the cipher text as well as any associated cryptographic state required by the receiver of the data, e.g., initialization vectors (IVs), sequence numbers, message integrity codes (MICs), key identifiers. data confidentiality: A property of information that prevents disclosure to unauthorized individuals, entities, or processes. deauthentication service: The service that voids an existing authentication relationship. decapsulate: To recover an unprotected frame from a protected one. decapsulation: The process of generating plaintext data by decapsulating an encapsulated frame. dependent station (STA): A STA that is not registered and whose operational parameters are dictated by messages it receives from an enabling STA. Once enabled by the dynamic STA enablement (DSE) process, a dependent STAâ€™s continued operation becomes contingent upon being able to receive messages from its enabling STA over the wireless medium (WM). destination mesh station (STA): A mesh STA that is the final destination of a MAC service data unit (MSDU). This mesh STA might reside in a proxy mesh gate that might forward the MSDU to a STA outside of the mesh basic service set (MBSS). A destination mesh STA might be an end station as defined in IEEE Std 802. direct link: A bidirectional link from one quality-of-service (QoS) station (STA) to another QoS STA operating in the same infrastructure QoS basic service set (BSS) that does not pass through a QoS access point (AP). Once a direct link has been set up, all frames between the two QoS STAs are exchanged directly. directed frame: See: individually addressed. 131 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications directed multicast service (DMS): A service in which the access point (AP) transmits group addressed frames as individually addressed frames to the requesting non-AP station (STA). disassociation service: The service that removes an existing association. distributed coordination function (DCF): A class of coordination function where the same coordination function logic is active in every station (STA) in the basic service set (BSS) whenever the network is in operation. distribution service: The service that, by using association information, delivers medium access control (MAC) service tuples within the distribution system (DS). distribution system (DS): A system used to interconnect a set of basic service sets (BSSs) and integrated local area networks (LANs) to create an extended service set (ESS). distribution system access function (DSAF): A function within an access point (AP) or mesh gate that uses the medium access control (MAC) service and distribution system service (DSS) to provide access between the distribution system (DS) and the wireless medium (WM). distribution system medium (DSM): The medium or set of media used by a distribution system (DS) for communications between access points (APs), mesh gates, and the portal of an extended service set (ESS). distribution system service (DSS): The set of services provided by the distribution system (DS) that enable the medium access control (MAC) to transport MAC service tuples between stations (STAs) that are not in direct communication with each other over a single instance of the wireless medium (WM). NOTE 1â€”These services include transport of MAC service tuples between the access points (APs) of basic service sets (BSSs) within an extended service set (ESS), transport of MAC service tuples between the portal and BSSs within an ESS, transport of MAC service tuples between mesh gates in the same or different mesh basic service sets (MBSSs), transport of MAC service tuples between mesh gates and APs, transport of MAC service tuples between mesh gates and a portal, and transport of MAC service tuples between STAs in the same BSS when the MAC service tuples has a group destination address or the destination is an individual address and the STA is associated with an AP. NOTE 2â€”DSSs are provided between pairs of MACs not on the same instance of the WM. dynamic frequency selection (DFS): Facilities mandated to satisfy requirements in some regulatory domains for radar detection and uniform channel spreading in the 5 GHz band. These facilities might also be used for other purposes, such as automatic frequency planning. dynamic station (STA) enablement (DSE): The process by which an enabling STA grants permission and dictates operational procedures to STAs that are subject to its control. effective isotropic radiated power (EIRP): The equivalent power of a transmitted signal in terms of an isotropic (omnidirectional) radiator. The EIRP equals the product of the transmitter power and the antenna gain (reduced by any coupling losses between the transmitter and antenna). emergency alert system (EAS): A U.S. national public warning system. enabling station (STA): A registered STA that has the authority to control when and how a dependent STA can operate. An enabling STA communicates an enabling signal to its dependents over the wireless medium (WM). An enabling STA chooses whether other dynamic STA enablement (DSE) messages are exchanged over the air, over the distribution system (DS), or by mechanisms that rely on transport via higher layers. encapsulate: To construct a protected frame from an unprotected frame. encapsulation: The process of generating a protected frame by encapsulating plaintext data. 132 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications extended service area (ESA): The area within which members of an extended service set (ESS) can communicate. An ESA is larger than or equal to a basic service area (BSA) and might involve several basic service sets (BSSs) in overlapping, disjointed, or both configurations. extended service set (ESS): A set of one or more interconnected basic service sets (BSSs) that appears as a single BSS to the logical link control (LLC) layer at any station (STA) associated with one of those BSSs. extended service set (ESS) transition: Change of association by a station (STA) from one basic service set (BSS) in one ESS to another BSS in a different ESS. fast basic service set (BSS) transition: Change of association by a station (STA) that is from one BSS in one extended service set (ESS) to another BSS in the same ESS and that minimizes the amount of time that the data connectivity is lost between the STA and the distribution system (DS). fast session transfer (FST): The transfer of a session from a channel to another channel, in the same or different frequency bands. The term â€œsessionâ€ refers to non-physical layer state information kept by a pair of stations (STAs) that communicate directly (i.e., excludes forwarding). fixed station (STA): A STA that is physically attached to a specific location. In licensed bands, a fixed STA might be authorized to operate only at a specific location. forwarding information: The information maintained by a mesh station (STA) that allows the mesh STA to perform its path selection and forwarding functions. frame: A unit of data exchanged between peer protocol entities. frequency segment: A contiguous block of spectrum used by a transmission. frame exchange sequence: A sequence of frames specified by Annex G. Gaussian frequency shift keying (GFSK): A modulation scheme in which the data are first filtered by a Gaussian filter in the baseband and then modulated with a simple frequency modulation. geolocation: A location within an earth-centric frame of reference. group: The entities in a wireless network, e.g., an access point (AP) and its associated stations (STAs), or all of the STAs in an independent basic service set (IBSS) network. group address: A medium access control (MAC) address that has the group bit equal to 1. Syn: multicast address. group addressed: A group addressed medium access control (MAC) service data unit (MSDU) is an MSDU that has a group address as its destination address (DA). A group addressed MAC protocol data unit (MPDU) is an MPDU that has a group address in its Address 1 field. Syn: multicast. group master key (GMK): An auxiliary key that might be used to derive a group temporal key (GTK). group temporal key (GTK): A random value, assigned by the group source, which is used to protect group addressed medium access control (MAC) protocol data units (MPDUs) from that source. The GTK might be derived from a group master key (GMK). hidden station (STA): A STA whose transmissions are not detected using carrier sense (CS) by a second STA, but whose transmissions interfere with transmissions from the second STA to a third STA 133 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications homogenous extended service set (ESS): A collection of basic service sets (BSSs), within the same extended service set (ESS), in which every subscription service provider network (SSPN) or other external network reachable at one BSS is reachable at all of them. idle power indicator (IPI): A physical layer (PHY) indication of the total channel power (noise and interference) as measured in the channel at the receiving antenna connector while the station (STA) is idle, i.e., neither transmitting nor receiving a frame. IEEE 802.1X authentication: Extensible Authentication Protocol (EAP) authentication transported by the IEEE 802.1X protocol. independent basic service set (IBSS): A basic service set (BSS) that forms a self-contained network, and in which no access to a distribution system (DS) is available. individual address: A medium access control (MAC) address in which the group bit is 0. Syn: directed address, unicast address. individually addressed: When applied to a medium access control (MAC) service data unit (MSDU), it is an MSDU with an individual address as the destination address (DA). When applied to a MAC protocol data unit (MPDU), it is an MPDU with an individual address in the Address 1 field. Syn: directed, unicast. infrastructure: An infrastructure comprises a distribution system (DS), one or more APs, zero or one portal, and zero or more mesh gates. It is also the logical location of distribution and integration service functions of an extended service set (ESS). infrastructure authorization information: The information that specifies the access rights of the user of a non-access-point (non-AP) station (STA). This information might include the rules for routing the user traffic, a set of permissions about services that a user is allowed to access, quality-of-service (QoS) configuration information, or the accounting policy to be applied by the infrastructure. integration service: The service that enables delivery of medium access control (MAC) service data units (MSDUs) between the distribution system (DS) and a local area network (LAN) (via a portal). integrity group temporal key (IGTK): A random value, assigned by the broadcast/multicast source station (STA), which is used to protect group addressed medium access control (MAC) management protocol data units (MMPDUs) from that source STA. link margin: Ratio of the received signal power to the minimum required by the station (STA). The STA might incorporate rate information and channel conditions, including interference, into its computation of link margin. The specific algorithm for computing the link margin is implementation dependent. link metric: A criterion used to characterize the performance, quality, and eligibility of a link. little endian: The concept that, for a given multi-octet numeric representation, the least significant octet has the lowest address. liveness: A demonstration that the peer is actually participating in this instance of communication. location subject local: The term used when a location request is for the location of the requesting STA, i.e., when the requesting STA asks, â€œWhere am I?â€ location subject remote: The term used when a location request is for the location of the reporting STA, i.e., when the requesting STA asks, â€œWhere are you?â€ 134 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications location subject third party: The term used when the location request is for the location of a station (STA) other than the requesting STA or the requested STA, (i.e., when the requesting STA asks, â€œWhere is he/ she?â€) master session key (MSK): Keying material that is derived between the Extensible Authentication Protocol (EAP) peer and exported by the EAP method to the Authentication Server (AS). NOTEâ€”In this standard, this key is at least 64 octets in length. medium access control (MAC) frame: The unit of data exchanged between MAC entities. Syn: medium access control (MAC) protocol data unit (MPDU). NOTEâ€”In contexts in which the MAC is clearly the subject, â€œframeâ€ is an implicit reference to a MAC frame. medium access control (MAC) protocol data unit (MPDU): The unit of data exchanged between two peer MAC entities using the services of the physical layer (PHY). Syn: medium access control (MAC) frame. medium access control (MAC) service data unit (MSDU): Information that is delivered as a unit between MAC service access points (SAPs). medium access control (MAC) service tuple: The collection of a MAC service data unit (MSDU) along with the source address, destination addresses, priority, and service class associated with the MSDU, which are passed as parameters across the MAC service access point (SAP) and are delivered across the distribution system between access points (APs), mesh gates, and the portal of an extended service set (ESS). mesh basic service set (MBSS): A basic service set (BSS) that forms a self-contained network of mesh stations (STAs) that use the same mesh profile. An MBSS contains zero or more mesh gates, and can be formed from mesh STAs that are not in direct communication. mesh facility: The set of enhanced functions, channel access rules, frame formats, mutual authentication methods, and managed objects used to provide data transfer among autonomously operating stations (STAs) that might not be in direct communication with each other over a single instance of the wireless medium. Communication between STAs using the mesh facility takes place using only the wireless medium. The mesh facility transports an MSDU between source and destination STAs over potentially multiple hops of the wireless medium without transiting the MAC SAP at intermediate STAs. mesh gate: Any entity that has a mesh station (STA) function and a distribution system access function (DSAF) to provide access to a single distribution system for the mesh basic service set (MBSS). mesh link: A link from one mesh station (STA) to a neighbor mesh STA that have a mesh peering with each other. mesh neighborhood: The set of all neighbor mesh stations (STAs) of a particular mesh STA. mesh path: A concatenated set of mesh links from a source mesh station (STA) to a destination mesh STA. mesh path selection: The process of selecting a mesh path. mesh peering: A relationship between two mesh stations (STAs) that is required for direct communication over a single instance of the wireless medium (WM). A mesh peering is established with a mesh peering protocol. 135 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications mesh profile: A set of values of parameters that identifies the attributes of the mesh basic service set (MBSS) and that is used in a single MBSS. NOTEâ€”The mesh profile consists of the identifiers that are the values for the parameters: mesh ID, active path selection protocol, active path selection metric, congestion control mode, synchronization method, and authentication protocol. mesh services: The set of services that enable the creation and operation of a mesh basic service set (MBSS). mesh station (STA): A quality-of-service (QoS) STA that implements the mesh facility. message integrity code (MIC): A value generated by a cryptographic function. If the input data are changed, a new value cannot be correctly computed without knowledge of the cryptographic key(s) used by the cryptographic function. NOTEâ€”This is traditionally called a message authentication code (MAC), but the acronym MAC is already reserved for another meaning in this standard. mobile station (STA): A type of STA that uses network communications while in motion. mobility domain: A set of basic service sets (BSSs), within the same extended service set (ESS), that support fast BSS transitions between themselves and that are identified by the setâ€™s mobility domain identifier (MDID). mobility domain identifier (MDID): An identifier that names a mobility domain. multi-level precedence and preemption (MLPP): A framework used with admission control for the treatment of traffic streams based on precedence, which supports the preemption of an active traffic stream by a higher precedence traffic stream when resources are limited. Preemption is the act of forcibly removing a traffic stream in progress in order to free up resources for another higher precedence traffic stream. multi-user multiple input, multiple output (MU-MIMO): A technique by which multiple stations (STAs), each with one or more antennas, either simultaneously transmit to a single STA or simultaneously receive from a single STA independent data streams over the same radio frequencies. NOTEâ€”IEEE Std 802.11 supports only downlink (DL) MU-MIMO. See downlink multi-user multiple input, multiple output (DL-MU-MIMO) (in 3.2). multicast: See: group addressed. multicast address: See: group address. multicast-group address: A medium access control (MAC) address associated by higher level convention with a group of logically related stations (STAs). multiple basic service set identifier (BSSID) capability: The capability to advertise information for multiple BSSIDs using a single Beacon or Probe Response frame instead of using multiple Beacon or Probe Response frames, each corresponding to a single BSSID, and the capability to indicate buffered frames for these multiple BSSIDs using a single traffic indication map (TIM) element in a single Beacon. multiple input, multiple output (MIMO): A physical layer (PHY) configuration in which both transmitter and receiver use multiple antennas. multiple medium access control (MAC) station management entity (SME) (MM-SME): Component of station management that manages multiple cooperating stations (STAs). 136 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications neighbor access point (AP): Any AP that is a potential service set transition candidate. neighbor station (STA): A STA in the following relationship: STA A is a neighbor to STA B if STA A can both directly transmit to and receive from STA B over the wireless medium. network access identifier (NAI): The user identity submitted by the Supplicant during IEEE 802.1X authentication. NOTEâ€”See IETF RFC 4282. network access server (NAS) client: The client component of a NAS that communicates with the Authentication Server (AS). network allocation vector (NAV): An indicator, maintained by each station (STA), of time periods when transmission onto the wireless medium (WM) is not initiated by the STA regardless of whether the STAâ€™s clear channel assessment (CCA) function senses that the WM is busy. next-hop mesh station (STA): The next peer mesh STA on the mesh path to the destination mesh STA. non-access-point (non-AP) station (STA): A STA that is not contained within an access point (AP). nonce: A numerical value, used in cryptographic operations associated with a given cryptographic key, that is not to be reused with that key, including over all reinitializations of the system through all time. noncontiguous transmission: A transmission that uses nonadjacent frequency segments. nonoperating channel: A channel that is not the operating channel of the basic service set (BSS) of which the station (STA) is a member. non-quality-of-service (non-QoS) access point (AP): An AP that does not support the quality-of-service (QoS) facility. non-quality-of-service (non-QoS) basic service set (BSS): A BSS that does not support the quality-of- service (QoS) facility. non-quality-of-service (non-QoS) station (STA): A STA that does not support the quality-of-service (QoS) facility. operating channel: The operating channel is the channel in which beacons are transmitted. NOTEâ€”In IEEE Std 802.11, the serving access point (AP) of an infrastructure basic service set (BSS) or the dynamic frequency selection (DFS) owner of an independent basic service set (IBSS) transmits beacons. operating channel width: The channel width in which the station (STA) is currently able to receive. overlapping basic service set (OBSS): A basic service set (BSS) operating on the same channel as the stationâ€™s (STAâ€™s) BSS and within (either partly or wholly) its basic service area (BSA). over-the-air fast basic service set (BSS) transition (FT): An FT method in which the station (STA) communicates over a wireless medium (WM) link to the target access point (AP). over-the-DS (distribution system) fast basic service set (BSS) transition (FT): An FT method in which the station (STA) communicates with the target access point (AP) via the current AP. 137 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications pairwise: Referring to, or an attribute of, two entities that are associated with each other, e.g., an access point (AP) and an associated station (STA), or two STAs in an independent basic service set (IBSS) network. This term is used to refer to a type of encryption key hierarchy pertaining to keys shared by only two entities. pass-phrase: A secret text string employed to corroborate the userâ€™s identity. password: A shared, secret, and potentially low-entropy word, phrase, code, or key used as a credential for authentication purposes. NOTEâ€”The method of distribution of a password to the units in the system is outside the scope of this standard. path metric: An aggregate multi-hop criterion used to characterize the performance, quality, and eligibility of a mesh path. peer mesh station (STA): A mesh STA to which a mesh peering has been established. peer-to-peer link: A direct link within a quality-of-service (QoS) basic service set (BSS), a tunnelled direct-link setup (TDLS) link, or a STA-to-STA communication in an independent basic service set (IBSS). peer-to-peer traffic specification (PTP TSPEC): The quality-of-service (QoS) characteristics of a data flow between non-access point (non-AP) QoS stations (STAs). per-frame encryption key: A unique encryption key constructed for each medium access control (MAC) protocol data unit (MPDU). physical layer (PHY) frame: The unit of data exchanged between PHY entities. Syn: physical layer (PHY) protocol data unit (PPDU). NOTEâ€”In contexts in which the PHY is clearly the subject, â€œframeâ€ is an implicit reference to a PHY frame. physical layer (PHY) protocol data unit (PPDU): The unit of data exchanged between two peer PHY entities to provide the PHY data service. piggyback: The overloading of data with an acknowledgment of a previously received frame to the station (STA) to which the data is directed. portable station (STA): A type of station (STA) that might be moved from location to location, but that only uses network communications while at a fixed location. portal: The logical point at which the integration service is provided. NOTEâ€”For the purposes of this Standard, there is at most one portal in a given ESSâ€™s infrastructure. In an implementation, a single logical portal function may be provided by multiple devices that provide integration services for the ESS. How such multiple devices coordinate to appear as a single logical portal is implementation dependent. precursor mesh station (STA): A neighbor peer mesh STA on the mesh path to the destination mesh STA, that identifies the mesh STA as the next-hop mesh STA. preshared key (PSK): A static key that is distributed to the units in the system by some out-of-band means. primary channel: The common channel of operation for all stations (STAs) that are members of the basic service set (BSS). 138 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications prioritized quality of service (QoS): The provisioning of service in which the medium access control (MAC) protocol data units (MPDUs) with higher priority are given a preferential treatment over MPDUs with a lower priority. NOTEâ€”Prioritized QoS is provided through the enhanced distributed channel access (EDCA) mechanism. protection mechanism: Any procedure that attempts to update the network allocation vector (NAV) of all receiving stations (STAs) prior to the transmission of a frame that might or might not be detected as valid network activity by the physical layer (PHY) entities at those receiving STAs. protection mechanism frame: Any frame that is sent as part of a protection mechanism procedure. protocol instance: An execution of a particular protocol that consists of the state of the communicating parties as well as the messages exchanged. proxy mesh gate: A mesh gate acting as an intermediary for IEEE 802 stations (STAs) outside the mesh basic service set (MBSS). pseudorandom function (PRF): A function that hashes various inputs to derive a pseudorandom value. In order to ensure liveness of a communication in which a pseudorandom value is used, a nonce is used as one of the inputs to the function. public safety answering point (PSAP): A physical location where emergency calls are received and routed to the appropriate emergency service dispatch center. NOTEâ€”See NENA 08-002 [B56]. quadrature binary phase shift keying (QBPSK): A binary phase shift keying modulation in which the binary data is mapped onto the imaginary (Q) axis. quality-of-service (QoS) access point (AP): An AP that supports the QoS facility. NOTEâ€”In IEEE Std 802.11, the functions of a QoS AP are a superset of the functions of a non-QoS AP, and thus a QoS AP is able to function as a non-QoS AP to non-QoS stations (STAs). quality-of-service (QoS) basic service set (BSS): A BSS that provides the QoS facility. An infrastructure QoS BSS contains a QoS access point (AP). quality-of-service (QoS) facility: The set of enhanced functions, channel access rules, frame formats, frame exchange sequences and managed objects used to provide parameterized and prioritized QoS. quality-of-service (QoS) independent basic service set (IBSS): An IBSS in which one or more of its stations (STAs) support the QoS facility. quality-of-service (QoS) station (STA): A STA that implements the QoS facility. NOTEâ€”A QoS STA acts as a non-QoS STA when associated in a non-QoS basic service set (BSS). radio frequency (RF) chain: The physical entity that is able to act as a receive chain or transmit chain, or both. reassociation service: The service that enables an established association [between access point (AP) and station (STA)] to be transferred from one AP to another (or the same) AP. receive chain: The physical entity that implements any necessary signal processing to provide the received signal to the digital baseband. Such signal processing includes filtering, amplification, down-conversion, and sampling. 139 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications receive power: Mean power measured at the antenna connector. received channel power indicator (RCPI): An indication of the total channel power (signal, noise, and interference) of a received frame measured on the channel and at the antenna connector used to receive the frame. received power indicator (RPI): A quantized measure of the received power level as seen at the antenna connector. registered location: The geolocation of a station (STA) registered in accordance with the requirements for the regulatory domain. registered location query protocol (RLQP): The query protocol for registered location information that is received and transported by generic advertisement service (GAS) Public Action frames. registered location secure server (RLSS): An entity that accesses and manages a database that organizes storage of information by geographic location and securely holds the location and some operating parameters of one or more basic service sets (BSSs). registered station (STA): A STA for which information needs to be submitted to an appropriate regulatory or coordination authority before it is allowed to transmit. remote request broker (RRB): The component of the station management entity (SME) of an access point (AP) that supports fast basic service set (BSS) transitions over the distribution system (DS). roaming consortium: A group of subscription service providers (SSPs) having inter-SSP roaming agreements. service set transition: A station (STA) movement from one basic service set (BSS) to another BSS, i.e., either a BSS transition or an extended service set (ESS) transition. serving access point (AP): The AP to which the station (STA) is associated. single-user (SU) physical layer (PHY) protocol data unit (PPDU): A PPDU with a format that is capable of carrying only a single PHY service data unit (PSDU), or no PSDU. sounding: The use of preamble training fields to measure the channel for purposes other than demodulation of the Data portion of the physical layer (PHY) protocol data unit (PPDU) containing the training fields. NOTEâ€”These uses include calculation of transmit steering, calculation of recommended modulation and coding scheme (MCS), and calculation of calibration parameters. source mesh station (STA): A mesh STA from which a medium access control (MAC) service data unit (MSDU) enters the mesh basic service set (MBSS). A source mesh STA is either a mesh STA that is the source of an MSDU or a proxy mesh gate that receives an MSDU from a STA outside of the MBSS and forwards the MSDU on a mesh path. space-time streams: Streams of modulation symbols created by applying a combination of spatial and temporal processing to one or more spatial streams of modulation symbols. spatial multiplexing (SM): A transmission technique in which data streams are transmitted on multiple spatial channels that are provided through the use of multiple antennas at the transmitter and the receiver. 140 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications spatial stream: One of several streams of bits or modulation symbols that might be transmitted over multiple spatial dimensions that are created by the use of multiple antennas at both ends of a communications link. station (STA): A logical entity that is a singly addressable instance of a medium access control (MAC) and physical layer (PHY) interface to the wireless medium (WM). NOTEâ€”For IEEE 802.11 purposes, a station is any MAC/PHY entity providing the IEEE 802.11 MAC services. This differs from the IEEE 802 definition of â€˜station,â€™ which includes bridges (or â€˜end stationsâ€™) that are endpoints of link layer data traffic. station service (SS): The set of services that support transport of medium access control (MAC) service data units (MSDUs) between stations (STAs) within a basic service set (BSS). subscription service provider (SSP): An organization (operator) offering connection to network services, perhaps for a fee. subscription service provider network (SSPN): The network controlled by a subscription service provider (SSP). The network maintains user subscription information. Supplicant: An entity at one end of a point-to-point LAN segment that is being authenticated by an Authenticator attached to the other end of that link. (IEEE Std 802.1X-2010) Supplicant address (SPA): The medium access control (MAC) address of the IEEE 802.1X Supplicant. television white spaces (TVWS): The opportunistic use of allocated but not assigned spectrumâ€”spectrum allocated for broadcast television, but with no assignment at a particular location. time unit (TU): A measurement of time equal to 1024 Âµs. traffic category (TC): A label for medium access control (MAC) service data units (MSDUs) that have a distinct user priority (UP), as viewed by higher layer entities, relative to other MSDUs provided for delivery over the same link. Traffic categories are meaningful only to MAC entities that support quality of service (QoS) within the MAC data service. These MAC entities determine the UP for MSDUs belonging to a particular traffic category using the priority value provided with those MSDUs at the MAC service access point (MAC SAP). traffic classification (TCLAS): The specification of certain parameter values to identify a protocol data unit (PDU) or a medium access control (MAC) service data unit (MSDU). The classification process is performed above the MAC service access point (MAC SAP), within the MLME, or within the MAC, based on the type of classification. traffic filter: A set of traffic specifications defined by the use of traffic classification (TCLAS) elements that are utilized by the traffic filtering service (TFS) to identify specific allowed frames. traffic filtering service (TFS): A service provided by an access point (AP) to a non-AP station (STA) to reduce the number of frames sent to the non-AP STA by not forwarding individually addressed frames addressed to the non-AP STA that do not match traffic filters specified by the non-AP STA. traffic identifier (TID): Any of the identifiers usable by higher layer entities to distinguish medium access control (MAC) service data units (MSDUs) to MAC entities that support quality of service (QoS) within the MAC data service. NOTEâ€”There are 16 possible TID values; eight identify traffic categories (TCs), and the other eight identify parameterized traffic streams (TSs). The TID is assigned to an MSDU in the layers above the MAC. 141 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications traffic specification (TSPEC): The quality-of-service (QoS) characteristics of a data flow to and from a QoS station (STA). traffic stream (TS): A set of medium access control (MAC) service data units (MSDUs) to be delivered subject to the quality-of-service (QoS) parameter values provided to the MAC in a particular traffic specification (TSPEC). TSs are meaningful only to MAC entities that support QoS within the MAC data service. These MAC entities determine the TSPEC applicable for delivery of MSDUs belonging to a particular TS using the priority parameter provided with those MSDUs at the MAC service access point (MAC SAP). transmission opportunity (TXOP): An interval of time during which a particular quality-of-service (QoS) station (STA) has the right to initiate frame exchange sequences onto the wireless medium (WM). NOTEâ€”A TXOP is defined by a starting time and a maximum duration. transmit chain: The physical entity that implements any necessary signal processing to generate the transmit signal from the digital baseband. Such signal processing includes digital to analog conversion, filtering, amplification and up-conversion. type/length/value (TLV): A format that consists of a type, a length, and a value. unauthorized disclosure: The process of making information available to unauthorized individuals, entities, or processes. unauthorized resource use: The use of a resource not consistent with the defined security policy. unicast: See: individually addressed. unicast address: See: individual address. uniform spreading: A regulatory requirement for a channel selection mechanism that provides uniform usage across a minimum set of channels in the regulatory domain. unreachable destination: A destination mesh station (STA) for which the link to the next hop of the mesh path to this destination mesh STA is no longer usable. user priority (UP): A value associated with an medium access control (MAC) service data unit (MSDU) that indicates how the MSDU is to be handled. The UP is assigned to an MSDU in the layers above the MAC. validated AP: An AP that has either been explicitly configured as a neighbor or learned through a mechanism such as the Beacon report. wildcard BSSID: A BSSID value used to represent all BSSIDs. NOTEâ€”In IEEE Std 802.11, this is represented by all binary 1s. wildcard SSID: A SSID value used to represent all SSIDs. NOTEâ€”In IEEE Std 802.11, this is represented by the value â€œnullâ€. wireless medium (WM): The medium used to implement the transfer of protocol data units (PDUs) between peer physical layer (PHY) entities of a wireless local area network (LAN). 142 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 3.2 Definitions specific to IEEE Std 802.11 The following terms and definitions are specific to terms or references in this standard and are not appropriate for inclusion in the IEEE Standards Dictionary: Glossary of Terms & Definitions. 20 MHz basic service set (BSS): A BSS in which the Secondary Channel Offset field is equal to no secondary channel (SCN). 20 MHz high-throughput (HT): A Clause 19 transmission with TXVECTOR parameter FORMAT equal to HT_MF or HT_GF and TXVECTOR parameter CH_BANDWIDTH equal to HT_CBW20. 20 MHz mask physical layer (PHY) protocol data unit (PPDU): One of the following PPDUs: a) A Clause 17 PPDU transmitted using the 20 MHz transmit spectral mask defined in Clause 17. b) A Clause 18 orthogonal frequency division multiplexing (OFDM) PPDU transmitted using the transmit spectral mask defined in Clause 18. c) A high-throughput (HT) PPDU with the TXVECTOR parameter CH_BANDWIDTH equal to HT_CBW20 and the CH_OFFSET parameter equal to CH_OFF_20 transmitted using the 20 MHz transmit spectral mask defined in Clause 19. d) A very high throughput (VHT) PPDU with TXVECTOR parameter CH_BANDWIDTH equal to CBW20 transmitted using the 20 MHz transmit spectral mask defined in Clause 21. e) A Clause 17 PPDU transmitted by a VHT STA using the transmit spectral mask defined in Clause 21. f) An HT PPDU with the TXVECTOR parameter CH_BANDWIDTH equal to HT_CBW20 and the CH_OFFSET parameter equal to CH_OFF_20 transmitted by a VHT STA using the 20 MHz transmit spectral mask defined in Clause 21. 20 MHz physical layer (PHY) protocol data unit (PPDU): A Clause 15 PPDU, Clause 17 PPDU (when using 20 MHz channel spacing), Clause 16 PPDU, Clause 18 orthogonal frequency division multiplexing (OFDM) PPDU, Clause 19 20 MHz high-throughput (HT) PPDU with the TXVECTOR parameter CH_BANDWIDTH equal to HT_CBW20, or Clause 21 20 MHz very high throughput (VHT) PPDU with the TXVECTOR parameter CH_BANDWIDTH equal to CBW20. 20/40 MHz basic service set (BSS): A BSS in which the supported channel width of the access point (AP) or dynamic frequency selection (DFS) owner (DO) station (STA) is 20 MHz and 40 MHz (Channel Width field is equal to 1) and the Secondary Channel Offset field is equal to a value of secondary channel above (SCA) or secondary channel below (SCB). 40-MHz-capable (40MC) high-throughput (HT) access point (AP): An HT AP that included a value of 1 in the Supported Channel Width Set subfield (indicating its capability to operate on a 40 MHz channel) of its most recent transmission of a frame containing an HT Capabilities element. 40-MHz-capable (40MC) high-throughput (HT) access point (AP) 2G4: An HT AP 2G4 that is also a 40MC HT AP. 40-MHz-capable (40MC) high-throughput (HT) access point (AP) 5G: An HT AP 5G that is also a 40MC HT AP. 40-MHz-capable (40MC) high-throughput (HT) station (STA): An HT STA that included a value of 1 in the Supported Channel Width Set subfield (indicating its capability to operate on a 40 MHz channel) of its most recent transmission of a frame containing an HT Capabilities element. 143 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 40-MHz-capable (40MC) high-throughput (HT) station (STA) 2G4: An HT STA 2G4 that is also a 40MC HT STA. 40-MHz-capable (40MC) high-throughput (HT) station (STA) 5G: An HT STA 5G that is also a 40MC HT STA. 40 MHz high-throughput (HT): A Clause 19 transmission with TXVECTOR parameter FORMAT equal to HT_MF or HT_GF and TXVECTOR parameter CH_BANDWIDTH equal to HT_CBW40. 40 MHz mask physical layer (PHY) protocol data unit (PPDU): One of the following PPDUs: a) A 40 MHz high-throughput (HT) PPDU (TXVECTOR parameter CH_BANDWIDTH equal to HT_CBW40) transmitted using the 40 MHz transmit spectral mask defined in Clause 19. b) A 40 MHz non-HT duplicate PPDU (TXVECTOR parameter CH_BANDWIDTH equal to NON_HT_CBW40) transmitted by a non-very high throughput (non-VHT) STA using the 40 MHz transmit spectral mask defined in Clause 19. c) A 40 MHz non-HT duplicate PPDU (TXVECTOR parameter CH_BANDWIDTH equal to CBW40) transmitted by a very high throughput (VHT) STA using the 40 MHz transmit spectral mask defined in Clause 21. d) A 20 MHz HT PPDU with the TXVECTOR parameter CH_BANDWIDTH equal to HT_CBW20 and the CH_OFFSET parameter equal to either CH_OFF_20U or CH_OFF_20L transmitted using the 40 MHz transmit spectral mask defined in Clause 19. e) A 20 MHz VHT PPDU with the TXVECTOR parameter CH_BANDWIDTH equal to CBW20 transmitted using the 40 MHz transmit spectral mask defined in Clause 21. f) A 40 MHz VHT PPDU with the TXVECTOR parameter CH_BANDWIDTH equal to CBW40 transmitted using the 40 MHz transmit spectral mask defined in Clause 21. g) A 40 MHz HT PPDU (TXVECTOR parameter CH_BANDWIDTH equal to HT_CBW40) transmitted by a VHT STA using the 40 MHz transmit spectral mask defined in Clause 21. h) A 20 MHz non-HT PPDU (TXVECTOR parameter CH_BANDWIDTH equal to CBW20) transmitted using the 40 MHz transmit spectral mask defined in Clause 19. i) A 20 MHz non-HT PPDU (TXVECTOR parameter CH_BANDWIDTH equal to CBW20) transmitted by a VHT STA using the 40 MHz transmit spectral mask defined in Clause 21. 40 MHz physical layer (PHY) protocol data unit (PPDU): A 40 MHz high-throughput (HT) PPDU (TXVECTOR parameter CH_BANDWIDTH equal to HT_CBW40), or a 40 MHz non-HT duplicate PPDU (TXVECTOR parameter CH_BANDWIDTH equal to NON_HT_CBW40 or TXVECTOR parameter CH_BANDWIDTH equal to CBW40), or a 40 MHz very high throughput (VHT) PPDU (TXVECTOR parameter CH_BANDWIDTH equal to CBW40). 4-way handshake: A pairwise key management protocol defined by this standard. This handshake confirms mutual possession of a pairwise master key (PMK) by two parties and distributes a group temporal key (GTK). 4-way station-to-station link (STSL) transient key (STK) handshake: A key management protocol between two parties that confirms mutual possession of an STSL master key (SMK) and distributes an STK. 80 MHz mask physical layer (PHY) protocol data unit (PPDU): A PPDU that is transmitted using the 80 MHz transmit spectral mask defined in Clause 21 and that is one of the following: a) An 80 MHz very high throughput (VHT) PPDU (TXVECTOR parameter CH_BANDWIDTH equal to CBW80) b) An 80 MHz non-high-throughput (non-HT) duplicate PPDU (TXVECTOR parameter CH_BANDWIDTH equal to CBW80) 144 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications c) A 20 MHz non-HT, high-throughput (HT), or VHT PPDU (TXVECTOR parameter CH_BANDWIDTH equal to CBW20) d) A 40 MHz non-HT duplicate, HT, or VHT PPDU (TXVECTOR parameter CH_BANDWIDTH equal to CBW40) 80 MHz physical layer (PHY) protocol data unit (PPDU): A Clause 21 80 MHz very high throughput (VHT) PPDU (TXVECTOR parameter CH_BANDWIDTH equal to CBW80) or a Clause 21 80 MHz non- high-throughput (non-HT) duplicate PPDU (TXVECTOR parameter CH_BANDWIDTH equal to CBW80). 160 MHz mask physical layer (PHY) protocol data unit (PPDU): A PPDU that is transmitted using the 160 MHz transmit spectral mask defined in Clause 21 and that is one of the following: a) A 160 MHz very high throughput (VHT) PPDU (TXVECTOR parameter CH_BANDWIDTH equal to CBW160) b) A 160 MHz non-high-throughput (non-HT) duplicate PPDU (TXVECTOR parameter CH_BANDWIDTH equal to CBW160) c) A 20 MHz non-HT, high-throughput (HT), or VHT PPDU (TXVECTOR parameter CH_BANDWIDTH equal to CBW20) d) A 40 MHz non-HT duplicate, HT, or VHT PPDU (TXVECTOR parameter CH_BANDWIDTH equal to CBW40) e) An 80 MHz non-HT duplicate or VHT PPDU (TXVECTOR parameter CH_BANDWIDTH equal to CBW80) 160 MHz physical layer (PHY) protocol data unit (PPDU): A Clause 21 160 MHz very high throughput (VHT) PPDU (TXVECTOR parameter CH_BANDWIDTH equal to CBW160) or a Clause 21 160 MHz non-high-throughput (non-HT) duplicate PPDU (TXVECTOR parameter CH_BANDWIDTH equal to CBW160). 80+80 MHz mask physical layer (PHY) protocol data unit (PPDU): A PPDU that is transmitted using the 80+80 MHz transmit spectral mask defined in Clause 21 and that is one of the following: a) An 80+80 MHz very high throughput (VHT) PPDU (TXVECTOR parameter CH_BANDWIDTH equal to CBW80+80) b) An 80+80 MHz non-high-throughput (non-HT) duplicate PPDU (TXVECTOR parameter CH_BANDWIDTH equal to CBW80+80) 80+80 MHz physical layer (PHY) protocol data unit (PPDU): A Clause 21 80+80 MHz very high throughput (VHT) PPDU (TXVECTOR parameter CH_BANDWIDTH equal to CBW80+80) or a Clause 21 80+80 MHz non-high-throughput (non-HT) duplicate PPDU (TXVECTOR parameter CH_BANDWIDTH equal to CBW80+80). access category (AC): A label for the common set of enhanced distributed channel access (EDCA) parameters that are used by a quality-of-service (QoS) station (STA) to contend for the channel in order to transmit medium access control (MAC) service data units (MSDUs) with certain priorities. access network query protocol (ANQP): The query protocol for access network information retrieval transported by generic advertisement service (GAS) Public Action frames. access period: A time period during a beacon interval established in a directional multi-gigabit (DMG) basic service set (BSS). access point (AP) path: Path between two tunneled direct-link setup (TDLS) peer stations (STAs) via the AP with which the STAs are currently associated. 145 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications active mode: A power management mode in which a nonmesh station (STA) remains in the awake state, and a mesh power management mode with respect to a neighbor peer mesh STA in which a mesh station remains in the awake state and is expected to receive frames from this neighbor peer mesh STA. advanced groupcast with retries (GCR): A set of features comprising the GCR block acknowledgment retransmission policy and the GCR service period (GCR-SP) delivery method. advertisement protocol: Access network query protocol (ANQP) and higher layer protocols defined external to this standard that are used for network and service discovery. advertisement server: A logical server that provides the information repository for a specific advertisement protocol. The location of the physical server that instantiates the advertisement server is outside the scope of this standard. aggregated schedule: The aggregation of delivery and/or poll schedules by the quality-of-service (QoS) access point (AP) for a particular QoS station (STA) into a single service period (SP). authentication and key management (AKM) suite: A set of one or more algorithms designed to provide authentication and key management, either individually or in combination with higher layer authentication and key management algorithms outside the scope of this standard. average noise power indicator (ANPI): A medium access control (MAC) indication of the average noise plus interference power measured when the channel is idle as defined by three simultaneous conditions: 1) the virtual carrier sense (CS) mechanism indicates idle channel, 2) the station (STA) is not transmitting a frame, and 3) the STA is not receiving a frame. bandwidth signaling transmitter address (TA): A TA that is used by a very high throughput (VHT) station (STA) to indicate the presence of additional signaling related to the bandwidth to be used in subsequent transmission in an enhanced distributed channel access (EDCA) transmission opportunity (TXOP). It is represented by the IEEE medium access control (MAC) individual address of the transmitting VHT STA but with the Individual/Group bit set to 1. base channel: Channel on which the tunneled direct-link setup (TDLS) peer station (STA) is associated with an access point (AP). basic channel unit (BCU): For television very high throughput (TVHT) operation, 6 MHz, 7 MHz, or 8 MHz, depending on the regulatory domain. basic modulation and coding scheme (MCS) set: The set of MCS values that are supported by all high- throughput (HT) stations (STAs) that are members of an HT basic service set (BSS). basic space-time block coding (STBC) modulation and coding scheme (MCS): An MCS value and STBC encoder specification used in the transmission of STBC-encoded Control frames and STBC-encoded group addressed frames. beacon header interval (BHI): The period of time that starts at the target beacon transmission time (TBTT) of a beacon interval of a directional multi-gigabit (DMG) basic service set (BSS) and that ends no later than the beginning of the data transfer interval (DTI) of the beacon interval. beacon transmission interval (BTI): The time interval between the start of the first Directional Multi- gigabit (DMG) Beacon frame transmission by a DMG station (STA) in a beacon interval to the end of the last DMG Beacon frame transmission by the STA in the same beacon interval. 146 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications bufferable medium access control (MAC) management protocol data unit (MMPDU): An MMPDU that is eligible to be queued for delivery using a power-saving mechanism (see Table 11-1). bufferable unit (BU): A medium access control (MAC) service data unit (MSDU), aggregate MAC service data unit (A-MSDU) [high-throughput (HT) stations (STAs) and directional multi-gigabit (DMG) STAs only], or bufferable MAC management protocol data unit (MMPDU). centralized coordination service root (CCSR): An entity that provides synchronization and configuration services to synchronization access points (S-APs). centralized coordination service set (CCSS): The collection of one centralized coordination service root (CCSR) and a set of one or more synchronization access points (S-APs) that are stationary with respect to their local environment while operating and are connected to the CCSR. concealed groupcast with retries (GCR) frame: A group addressed frame that is transmitted using the aggregate medium access control (MAC) service data unit (A-MSDU) frame format with the destination address (DA) field set to the GCR concealment address. contention based access period (CBAP): The time period in the data transfer interval (DTI) of a directional multi-gigabit (DMG) basic service set (BSS) during which enhanced distributed channel access (EDCA) is used. contention free (CF) pollable: A station (STA) that is able to respond to a CF poll with a Data frame if such a frame is queued and able to be generated. contention free period (CFP): The time period during the operation of a point coordination function (PCF) when the right to transmit is assigned to stations (STAs) solely by a point coordinator (PC), allowing frame exchanges to occur between members of the basic service set (BSS) without contention for the wireless medium (WM). contention period (CP): The time period outside of the contention free period (CFP) in a point-coordinated basic service set (BSS). In a BSS where there is no point coordinator (PC), this corresponds to the entire time of operation of the BSS. controlled access phase (CAP): A time period during which the hybrid coordinator (HC) maintains control of the medium, after gaining medium access by sensing the channel to be idle for a point coordination function (PCF) interframe space (PIFS) duration. It might span multiple consecutive transmission opportunities (TXOPs) and can contain polled TXOPs. deep sleep mode: A mesh power management mode with respect to a neighbor peer mesh STA in which a mesh station (STA) alternates between awake and doze states and is not expected to receive beacons from this neighbor peer mesh STA. delivery-enabled access category (AC): A quality-of-service (QoS) access point (AP) AC where the AP is allowed to use enhanced distributed channel access (EDCA) to deliver traffic from the AC to a QoS station (STA) in an unscheduled service period (SP) triggered by the STA. delivery traffic indication map (DTIM) interval: The interval between the consecutive target beacon transmission times (TBTTs) of beacons containing a DTIM. The value, expressed in time units, is equal to the product of the value in the Beacon Interval field and the value in the DTIM Period subfield in the TIM element in Beacon frames. 147 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications destination directional multi-gigabit (DMG) station (STA): A DMG STA identified by the destination association identifier (AID) field contained in a Grant frame or Extended Schedule element that caused the allocation of a service period (SP) or a contention based access period (CBAP). direct sequence spread spectrum/complementary code keying (DSSS/CCK): A Clause 15 or Clause 16 transmission. directional multi-gigabit (DMG): Pertaining to operation in a frequency band containing a channel with the channel starting frequency above 45 GHz. NOTEâ€”The channel starting frequency for IEEE 802.11 stations (STAs) is defined in Annex E. directional multi-gigabit (DMG) access point (AP): An AP whose radio transmitter is capable of transmitting and receiving DMG physical layer (PHY) protocol data units (PPDUs). directional multi-gigabit (DMG) antenna: A DMG antenna is a phased array, a single element antenna, or a set of switched beam antennas covered by a quasi-omni antenna pattern. directional multi-gigabit (DMG) basic service set (BSS): A BSS in which DMG Beacon frames are transmitted by DMG stations (STAs). directional multi-gigabit (DMG) frame: A frame transmitted or received within a DMG physical layer (PHY) protocol data unit (PPDU). directional multi-gigabit (DMG) physical layer (PHY) protocol data unit (PPDU): A Clause 20 PPDU. directional multi-gigabit (DMG) station (STA): A STA whose radio transmitter is capable of transmitting and receiving DMG physical layer (PHY) protocol data units (PPDUs). directional transmission: A transmission that does not use an omnidirectional antenna pattern or quasi- omni antenna pattern. downlink: A unidirectional link from an access point (AP) to one or more non-AP stations (STAs) or a unidirectional link from a non-AP destination directional multi-gigabit (DMG) STA to a non-AP source DMG STA. downlink multi-user multiple input, multiple output (DL-MU-MIMO): A technique by which an access point (AP) with more than one antenna transmits a physical layer (PHY) protocol data unit (PPDU) to multiple receiving non-AP stations (STAs) over the same radio frequencies, wherein each non-AP STA simultaneously receives one or more distinct space-time streams. dynamic bandwidth operation: A feature of a very high throughput (VHT) station (STA) in which the request-to-send/clear-to-send (RTS/CTS) exchange, using non-high-throughput (non-HT) duplicate physical layer (PHY) protocol data units (PPDUs), negotiates a potentially reduced channel width (compared to the channel width indicated by the RTS) for subsequent transmissions within the current transmission opportunity (TXOP). dynamic frequency selection (DFS) owner: A station (STA) in an independent basic service set (IBSS) or off-channel tunneled direct link setup (TDLS) direct link that takes responsibility for selecting the next channel after radar is detected operating in a channel. Due to the nature of IBSSs, it cannot be guaranteed that there is a single DFS owner at any particular time and the protocol is robust to this situation. EAPOL-Key confirmation key (KCK): A key used to integrity-check an EAPOL-Key frame. 148 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications EAPOL-Key encryption key (KEK): A key used to encrypt the Key Data field in an EAPOL-Key frame. EAPOL-Key frame: A Data frame that carries all or part of an IEEE 802.1X EAPOL PDU of type EAPOL- Key. EAPOL-Key request frame: A Data frame that carries all of part of an IEEE 802.1X EAPOL-Key protocol data unit (PDU) with the Request bit in the Key Information field in the IEEE 802.11 key descriptor set to 1. EAPOL-Start frame: A Data frame that carries all or part of an IEEE 802.1X EAPOL PDU of type EAPOL-Start. emergency services association: A robust security network association (RSNA) between an access point (AP) and a non-AP station (STA) without security credentials; the non-AP STA is granted access to emergency services using unprotected frames via this association. enhanced distributed channel access (EDCA): The prioritized carrier sense multiple access with collision avoidance (CSMA/CA) access mechanism used by quality-of-service (QoS) stations (STAs) in a QoS basic service set (BSS) and STAs operating outside the context of a BSS. This access mechanism is also used by the QoS access point (AP) and operates concurrently with hybrid coordination function (HCF) controlled channel access (HCCA). enhanced distributed channel access function (EDCAF): A logical function in a quality-of-service (QoS) station (STA) that determines, using enhanced distributed channel access (EDCA), when a frame in the transmit queue with the associated access category (AC) is permitted to be transmitted via the wireless medium (WM). There is one EDCAF per AC. extended centralized access point (AP) or personal basic service set (PBSS) control point (PCP) cluster (ECAPC): The collection of 1) a single centralized coordination service set (CCSS), 2) the set of centralized AP or PCP clusters such that each synchronization AP (S-AP) of a centralized AP or PCP cluster is within the CCSS, and 3) all stations (STAs) within the basic service sets (BSSs) of the S-APs and member APs and PCPs of the centralized AP or PCP clusters. extended channel switching (ECS): A procedure that is used to announce a pending change of operating channel, operating class, or both. extended rate physical layer (ERP): A physical layer (PHY) compliant with Clause 18. extended rate physical layer (PHY) using complementary code keying (CCK) modulation (ERP- CCK): A mode of operation of a PHY operating under Clause 18 rules, where MODULATION=ERP-CCK. extended rate physical layer (PHY) using direct sequence spread spectrum (DSSS) modulation (ERP- DSSS): A PHY operating under Clause 18 rules, where MODULATION=ERP-DSSS. extended rate physical layer (PHY) using direct sequence spread spectrum (DSSS) or complementary code keying (CCK) modulation (ERP-DSSS/CCK): A PHY operating under Clause 18 rules, where MODULATION=ERP-CCK or MODULATION=ERP-DSSS. extended rate physical layer (PHY) using orthogonal frequency division multiplexing (OFDM) modulation (ERP-OFDM): A mode of operation of a PHY operating under Clause 18 rules, where MODULATION=ERP-OFDM. extended service set (ESS) link: In the context of an IEEE 802.11 medium access control (MAC) entity, a connection path through the wireless medium between a non-access-point (non-AP) station (STA) and one of the APs that is a member of the ESS. 149 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications fast basic service set (BSS) transition (FT) 4-way handshake: A pairwise key management protocol used during FT initial mobility domain association. This handshake confirms mutual possession of a pairwise master key, the PMK-R1, by two parties and distributes a group temporal key (GTK). fast basic service set (BSS) transition (FT) initial mobility domain association: The first association or first reassociation procedure within a mobility domain, during which a station (STA) indicates its intention to use the FT procedures. fast basic service set (BSS) transition (FT) originator: A station (STA) that initiates the FT protocol by sending an FT Request frame or an Authentication frame with Authentication Algorithm Number field equal to Fast BSS Transition. fine timing measurement (FTM) procedure: A procedure that allows a station (STA) to determine its distance from another STA. flexible multicast service (FMS): A service that enables a non-access-point (non-AP) station (STA) to request a multicast delivery interval longer than the delivery traffic indication map (DTIM) interval for the purposes of lengthening the period of time a STA can be in a power save state. flexible multicast service (FMS) stream: A succession of frames transmitted by the access point (AP) that correspond to a single flexible multicast stream identifier (FMSID). flexible multicast service (FMS) stream set: A collection of FMS streams identified by the value of the FMS Token field, used during the FMS Request procedure. flexible multicast stream identifier (FMSID): An identifier assigned by the access point (AP) to a particular group addressed stream subsequent to a successful FMS Request. fragmentation: The process of partitioning a medium access control (MAC) service data unit (MSDU) or MAC management protocol data unit (MMPDU) into a sequence of smaller MAC protocol data units (MPDUs) prior to transmission. The process of recombining a set of fragment MPDUs into an MSDU or MMPDU is known as defragmentation. These processes are described in 5.8.1.9 of ISO/IEC 7498-1:1994. future channel guidance: future channel guidance communicates likely future channel information so that STAs can efficiently move their activity when the absence of Beacon frames is noticed. geolocation database (GDB): A database whose operation is mandated or authorized by a regulatory authority and that organizes storage of information by geographic location. geolocation database dependent (GDD): A modifier describing when station (STA) operation is dependent on information received from a geolocation database (GDB). geolocation database dependent (GDD) access point (AP): A station (STA) dependent on information received from a geolocation database (GDB) in order to initiate and maintain a network. geolocation database dependent (GDD) dependent station (STA): A STA that is under the control of a GDD enabling STA. geolocation database dependent (GDD) enabling station (STA): A STA that has the authority to control the operation of GDD dependent STAs after obtaining available spectrum for use at its own location. geolocation database dependent (GDD) fixed station (STA): A STA whose geographical location information is fixed and maintained in a geolocation database (GDB) and whose operation depends on information received from that database. 150 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications geolocation database dependent (GDD) geolocated non-access point (non-AP) station (STA): A STA that is not an AP and is authorized by a geolocation database (GDB) to operate at its current location. geolocation database dependent (GDD) non-access point (non-AP) station (STA): A STA that is not an AP but operates under the control of a GDD enabling STA. generic advertisement service (GAS): An over-the-air transportation service that provides over-the-air transportation for frames of higher layer advertisements between stations (STAs) or between an advertisement server and a non-access-point (non-AP) STA. The protocol(s) used to relay frames between an AP, portal, and advertisement server is outside the scope of this standard. GAS supports higher layer protocols that employ a query/response mechanism. global operating class: An operating class value that is any of the non-reserved values in Table E-4. group addressed bufferable unit (BU): A group addressed medium access control (MAC) service data unit (MSDU) or group addressed bufferable MAC management protocol data unit (MMPDU). group addressed quality-of-service management frame (GQMF): A group addressed Management frame that is transmitted using the quality-of-service management frame (QMF) service. group addressed transmission service (GATS): A mechanism comprising directed multicast service (DMS) and groupcast with retries (GCR), for delivery of group addressed frames. group key handshake: A group key management protocol defined by this standard. It is used only to issue a new group temporal key (GTK) to peers with whom the local station (STA) has already formed security associations. group temporal key security association (GTKSA): The context resulting from a successful group temporal key (GTK) distribution exchange via either a group key handshake or a 4-way handshake. groupcast with retries (GCR) active (GCR-A) delivery: A delivery method for a group addressed stream subject to a GCR agreement wherein the frames are transmitted without regard to the power state of non- access-point (non-AP) stations (STAs). groupcast with retries (GCR) concealment address: A medium access control (MAC) address that is used to prevent group addressed frames transmitted via the GCR unsolicited retry or GCR block ack retransmission policies from being passed up the medium access control service access point (MAC SAP) of GCR-incapable stations (STAs). groupcast with retries (GCR) frame: A group addressed frame subject to a GCR agreement between the access point (AP) and at least one station (STA) within the infrastructure basic service set (BSS) or between peer mesh STAs in a mesh BSS. groupcast with retries (GCR) group address: A group address subject to a GCR agreement between the access point (AP) and at least one station (STA) within the basic service set (BSS) or between peer mesh STAs in a mesh BSS. groupcast with retries (GCR) service: A means for transmission and retransmission of medium access control (MAC) service data units (MSDUs) to a destination that is a group address. The GCR service provides greater reliability by using group addressed retransmissions, concealed from GCR-incapable stations (STAs). 151 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications groupcast with retries (GCR) service period (GCR-SP) aggregate medium access control (MAC) service data unit (A-MSDU): An A-MSDU subject to the GCR service with the delivery method equal to GCR-SP. groupcast with retries (GCR) service period (GCR-SP) frame: A frame subject to the GCR service when the delivery method is GCR-SP. groupcast with retries (GCR) service period (GCR-SP) medium access control (MAC) service data unit (MSDU): An MSDU subject to the GCR service with the delivery method equal to GCR-SP. groupcast with retries (GCR) transmission opportunity (TXOP): An interval of time during which an access point (AP) or a mesh station (STA) has the right to initiate frame exchange sequences onto the wireless medium (WM) for the purpose of transmitting multiple frames that are subject to the GCR service. high-throughput (HT) basic service set (BSS): A BSS in which Beacon frames transmitted by an HT station (STA) include the HT Capabilities element. high-throughput (HT) beamformee: An HT station (STA) that receives an HT physical layer (PHY) protocol data unit (PPDU) that was transmitted using a beamforming steering matrix and that supports an HT transmit beamforming feedback mechanism. high-throughput (HT) beamformer: An HT station (STA) that transmits an HT physical layer (PHY) protocol data unit (PPDU) using a beamforming steering matrix. high-throughput (HT) delayed (HT-delayed) block acknowledgment (Ack): A delayed block ack mechanism that requires the use of the compressed BlockAck frame and the No Acknowledgment ack policy setting within both BlockAckReq and BlockAck frames. This block ack scheme is negotiated between two HT stations (STAs) that both support HT-delayed block ack. high-throughput (HT) greenfield (HT-greenfield) format: A physical layer (PHY) protocol data unit (PPDU) format of the HT PHY using the HT-greenfield format preamble. This format is represented at the PHY data service access point (SAP) by the TXVECTOR/RXVECTOR FORMAT parameter being equal to HT_GF. high-throughput (HT) immediate (HT-immediate) block acknowledgment (Ack): An immediate block ack mechanism that requires the use of the compressed BlockAck frame and an implicit block ack request and allows partial-state operation at the recipient. This block ack scheme is negotiated between two HT or directional multi-gigabit (DMG) stations (STAs). high-throughput (HT) mixed (HT-mixed) format: A physical layer (PHY) protocol data unit (PPDU) format of the HT PHY using the HT-mixed format preamble. This format is represented at the PHY data service access point (SAP) by the TXVECTOR/RXVECTOR FORMAT parameter being equal to HT_MF. high-throughput (HT) modulation and coding scheme (HT-MCS): A specification of the HT physical layer (PHY) parameters that consists of modulation order (e.g., BPSK, QPSK, 16-QAM, 64-QAM), forward error correction (FEC) coding rate (e.g., 1/2, 2/3, 3/4, 5/6), and number of spatial streams (NSS) and that is used in an HT PHY protocol data unit (PPDU). high-throughput (HT) null data packet (NDP) announcement: A physical layer (PHY) protocol data unit (PPDU) that contains one or more +HTC frames (i.e., frames with an HT Control field) that have the HT NDP Announcement subfield equal to 1. high-throughput (HT) physical layer (PHY) protocol data unit (PPDU): A Clause 19 PPDU with the TXVECTOR FORMAT parameter equal to HT_MF or HT_GF. 152 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications high-throughput (HT) station (STA) 2G4: An HT STA that is also a STA 2G4. high-throughput (HT) station (STA) 5G: An HT STA that is also a STA 5G. hybrid coordination function (HCF): A coordination function that combines and enhances aspects of the contention based and contention free access methods to provide quality-of-service (QoS) stations (STAs) with prioritized and parameterized QoS access to the wireless medium (WM), while continuing to support non-QoS STAs for best-effort transfer. The HCF includes the functionality provided by both enhanced distributed channel access (EDCA) and HCF controlled channel access (HCCA). hybrid coordination function (HCF) controlled channel access (HCCA): The channel access mechanism utilized by the hybrid coordinator (HC) to coordinate contention free media use by quality-of-service (QoS) stations (STAs) for downlink individually addressed, uplink, and direct-link transmissions. hybrid coordinator (HC): A type of coordinator, defined as part of the quality-of-service (QoS) facility, that implements the frame exchange sequences and medium access control (MAC) service data unit (MSDU) handling rules defined by the hybrid coordination function (HCF). IEEE 802.11 station (STA): Any station that is compliant with IEEE Std 802.11. Any reference to the term station (STA) in this standard that is not qualified by the term IEEE 802.11 implicitly refers to an IEEE 802.11 station. individually addressed bufferable unit (BU): An individually addressed medium access control (MAC) service data unit (MSDU), individually addressed aggregate MAC service data unit (A-MSDU) [high- throughput (HT) stations (STAs) and directional multi-gigabit (DMG) STAs only], or individually addressed bufferable MAC management protocol data unit (MMPDU). individually addressed quality-of-service management frame (IQMF): An individually addressed Management frame that is transmitted using the quality-of-service management frame (QMF) service. interworking service: A service that supports use of an IEEE 802.11 network with non-IEEE-802.11 networks. Functions of the interworking service assist non-access-point (non-AP) stations (STAs) in discovering and selecting IEEE 802.11 networks, in using appropriate quality-of-service (QoS) settings for transmissions, in accessing emergency services, and in connecting to subscription service providers (SSPs). key counter: A 256-bit (32-octet) counter that is used in the pseudorandom function (PRF) to generate initialization vectors (IVs). There is a single key counter per station (STA) that is global to that STA. key data encapsulation (KDE): A format for data other than elements in the EAPOL-Key Data field. key management service: A service to distribute and manage cryptographic keys within a robust security network (RSN). light sleep mode: A mesh power management mode with respect to a neighbor peer mesh STA in which a mesh station (STA) alternates between awake and doze states and is expected to receive beacons from this neighbor peer mesh STA. link: In the context of an IEEE 802.11 medium access control (MAC) entity, a physical path consisting of exactly one traversal of the wireless medium (WM) that is usable to transfer MAC service data units (MSDUs) between two stations (STAs). location configuration information (LCI): As defined in IETF RFC 6225: includes latitude, longitude, and altitude, with uncertainty indicators for each. 153 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications medium access control (MAC) management protocol data unit (MMPDU): The unit of data exchanged between two peer MAC entities, using services of the physical layer (PHY), to implement the MAC management protocol. The MMPDU is transported in one or more Management frames. The MMPDU might include a Mesh Control field or management message integrity code element (Management MIC element), but does not include a MAC header, a frame check sequence (FCS), or any other security encapsulation overhead. NOTEâ€”The MMPDU occupies a position in the management plane similar to that of the MAC service data unit (MSDU) in the data plane. An MSDU or MMPDU is transmitted in one or more MAC protocol data units (MPDUs) (with the Type field set to Data or Management, respectively). An MSDU can be carried in an aggregate MAC service data unit (A-MSDU). An A-MSDU is transmitted in one MPDU. An MSDU, A-MSDU, or MMPDU can be carried (in an MPDU) in an A-MPDU. mesh awake window: A period of time during which the mesh station (STA) operates in awake state after its Beacon or Probe Response frame transmission that contained the Mesh Awake Window element. mesh coordination function (MCF): A coordination function that combines aspects of the contention based and scheduled access methods. The MCF includes the functionality provided by both enhanced distributed channel access (EDCA) and MCF controlled channel access (MCCA). mesh coordination function (MCF) controlled channel access (MCCA): A coordination function for the mesh basic service set (MBSS). mesh coordination function (MCF) controlled channel access opportunity (MCCAOP): A period of time scheduled for frame transmissions between mesh stations (STAs) using MCF controlled channel access (MCCA). mesh Data frame: A Data frame that is transmitted by a mesh station (STA). mesh peer service period: A period of time during which one or more individually addressed frames are transmitted between two peer mesh stations (STAs) with at least one of those mesh STAs operating in light sleep or deep sleep mode. A mesh peer service period is directional and might contain one or more transmission opportunities (TXOPs). mesh peer service period owner: A mesh station (STA) that obtains transmission opportunities (TXOPs), transmits individually addressed frames to the recipient mesh STA in the mesh peer service period, and terminates the mesh peer service period. mesh peering management: A group of protocols to facilitate mesh peering establishment and closure. mesh power management mode: The activity level identifier of a mesh station (STA) set per mesh peering or for nonpeer neighbor STAs. A lower activity level enables a mesh STA to reduce its power consumption. mesh power management mode tracking: Operation to observe the peering-specific mesh power management modes from the peer mesh STAs and to maintain the peering-specific mesh power management modes for each peer mesh STA. message integrity code (MIC) key: TKIP only: The portion of a transient key used to validate the integrity of medium access control (MAC) service data units (MSDUs) or MAC protocol data units (MPDUs). michael: The message integrity code (MIC) for the temporal key integrity protocol (TKIP). minimum downlink transmission time (DTT) to uplink transmission time (UTT) [DTT2UTT] spacing: The minimum time within a power save multi-poll (PSMP) sequence between the end of a stationâ€™s (STAâ€™s) PSMP-DTT and the start of its PSMP-UTT. 154 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications modulation and coding scheme (MCS): A specification of the physical layer (PHY) parameters that consists of modulation order (e.g., BPSK, QPSK, 16-QAM, 64-QAM, and 256-QAM), forward error correction (FEC) coding rate (e.g., 1/2, 2/3, 3/4, 5/6), and, depending on the context, the number of space- time streams. modulation and coding scheme 32 (MCS 32) format: A physical layer (PHY) protocol data unit (PPDU) format of the high-throughput (HT) PHY in which signals in two halves of the occupied channel width contain the same information. This HT PPDU format supports the lowest rate. modulation and coding scheme (MCS) feedback (MFB) requester: A station (STA) that transmits a physical layer (PHY) protocol data unit (PPDU) containing an HT Control field in which the MCS request (MRQ) subfield is equal to 1. modulation and coding scheme (MCS) feedback (MFB) responder: A station (STA) that transmits a physical layer (PHY) protocol data unit (PPDU) containing an HT Control field with the MFB field containing an MCS index or the value 127 in response to a PPDU containing an HT Control field in which the MCS request (MRQ) subfield is equal to 1. multiple basic service set identifier (BSSID) set: A collection of cooperating access points (APs), such that all of the APs use a common operating class, channel, and antenna connector. multiple medium access control (MAC) sublayers link (MMSL): A link between two stations (STAs), wherein one of the STAs is coordinated by a multiple MAC station management entity (MM-SME) that delivered a Multiple MAC Sublayers (MMS) element to the peer STA. multiple medium access control (MAC) sublayers link (MMSL) cluster: The set of all MMSLs between a pair of stations (STAs). multi-user (MU) beamformee: A non-access-point (non-AP) station (STA) that receives a physical layer (PHY) protocol data unit (PPDU) that was transmitted using a multi-user beamforming steering matrix and that supports the very high throughput (VHT) transmit beamforming feedback mechanism with a VHT null data packet (NDP) Announcement frame that includes more than one STA Info field. multi-user (MU) beamformer: An access point (AP) that transmits a physical layer (PHY) protocol data unit (PPDU) using a multi-user beamforming steering matrix. multi-user (MU) physical layer (PHY) protocol data unit (PPDU): A PPDU that carries one or more PHY service data units (PSDUs) for one or more stations (STAs) using the downlink multi-user multiple input, multiple output (DL-MU-MIMO) technique. no acknowledgment/no retry (No-Ack/No-Retry): A retransmission policy for group addressed frames in which each frame is transmitted once and without acknowledgment. non-40-MHz-capable (non-40MC) high-throughput (HT) station (STA): A STA that is not a 40-MHz- capable (40MC) HT STA. nonaggregate medium access control (MAC) protocol data unit (non-A-MPDU) frame: A frame that is transmitted in a physical layer (PHY) protocol data unit (PPDU) with the TXVECTOR AGGREGATION parameter either absent or equal to NOT_AGGREGATED. nonbandwidth signaling transmitter address (TA): An address in the TA field of an medium access control (MAC) protocol data unit (MPDU) in which the Individual/Group bit has the value 0. 155 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications nonbufferable medium access control (MAC) management protocol data unit (MMPDU): An MMPDU that is not a bufferable MMPDU. nonconcealed groupcast with retries (GCR) frame: A group addressed frame that is not transmitted to the GCR concealment address. nonextended rate physical layer (NonERP): A physical layer (PHY) compliant with Clause 15 or Clause 16, but not with Clause 18. nongroupcast with retries (non-GCR): A method for delivering group addressed frames without using the groupcast with retries (GCR) unsolicited retry retransmission policy, the GCR block acknowledgment retransmission policy, or the GCR service period (GCR-SP) delivery method. nongroupcast with retries service period (non-GCR-SP): A method for the delivery of group addressed frames without the use of a groupcast with retries service period (GCR-SP). non-high-throughput (non-HT): A modifier meaning neither high throughput (HT) nor very high throughput (VHT). non-high-throughput (non-HT) duplicate: A transmission format of the physical layer (PHY) that duplicates a 20 MHz non-HT transmission in two or more 20 MHz channels and allows a station (STA) in a non-HT basic service set (BSS) on any one of the 20 MHz channels to receive the transmission. A non-HT duplicate format is one of the following: a) 40 MHz non-HT duplicate: A transmission format of the PHY that replicates a 20 MHz non-HT transmission in two adjacent 20 MHz channels. b) 80 MHz non-HT duplicate: A transmission format of the PHY that replicates a 20 MHz non-HT transmission in four adjacent 20 MHz channels. c) 160 MHz non-HT duplicate: A transmission format of the PHY that replicates a 20 MHz non-HT transmission in eight adjacent 20 MHz channels. d) 80+80 MHz non-HT duplicate: A transmission format of the PHY that replicates a 20 MHz non-HT transmission in two frequency segments of four adjacent 20 MHz channels where the two frequency segments of channels are not adjacent. non-high-throughput (non-HT) duplicate frame: A frame transmitted in a non-HT duplicate physical layer (PHY) protocol data unit (PPDU). non-high-throughput (non-HT) duplicate in television white spaces (TVWS) band: A transmission format of the physical layer (PHY) that duplicates a single basic channel unit (BCU) non-HT transmission in two or more BCUs and allows a station (STA) in a non-HT basic service set (BSS) on any one BCU to receive the transmission. A non-HT duplicate format is one of the following: a) TVHT_W non-HT duplicate: A PHY transmission that replicates a non-HT PHY protocol data unit (PPDU) two times in a single BCU b) TVHT_2W non-HT duplicate: A PHY transmission that replicates a non-HT PPDU four times in two contiguous BCUs c) TVHT_4W non-HT duplicate: A PHY transmission that replicates a non-HT PPDU eight times in four contiguous BCUs d) TVHT_W+W non-HT duplicate: A PHY transmission that replicates a non-HT PPDU two times in each single BCU e) TVHT_2W+2W non-HT duplicate: A PHY transmission that replicates a non-HT PPDU four times in each of two contiguous BCUs 156 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications non-high-throughput (non-HT) duplicate physical layer (PHY) protocol data unit (PPDU): A PPDU transmitted by a Clause 19 or Clause 21 PHY with the TXVECTOR FORMAT parameter equal to NON_HT and the CH_BANDWIDTH parameter equal to NON_HT_CBW40, CBW40, CBW80, CBW160, or CBW80+80. non-high-throughput (non-HT) duplicate physical layer (PHY) protocol data unit (PPDU) in television white spaces (TVWS) band: A PPDU transmitted by a Clause 22 PHY with the TXVECTOR parameter FORMAT set to NON_HT and the TXVECTOR parameter CH_BANDWIDTH set to TVHT_W, TVHT_2W, TVHT_4W, TVHT_W+W, or TVHT_2W+2W. non-high-throughput (non-HT) physical layer (PHY) protocol data unit (PPDU): A PPDU that is transmitted by Clause 15, Clause 16, Clause 17, or Clause 18 PHY, or not using a TXVECTOR FORMAT parameter equal to HT_MF, HT_GF or VHT. non-high-throughput (non-HT) SIGNAL field (L-SIG) transmit opportunity (TXOP) protection: A protection mechanism in which protection is established by the non-HT SIG Length and Rate fields indicating a duration that is longer than the duration of the PPDU itself. nonpeer mesh power management mode: The activity level identifier of a mesh station (STA) toward nonpeer neighbor mesh STAs. Two nonpeer mesh power management modes are defined: active mode and deep sleep mode. non-personal basic service set (BSS) control point (non-PCP) station (STA): A STA that is not a personal BSS control point (PCP). non-phased-coexistence-operation-capable (non-PCO-capable) 20/40 station (STA): A high-throughput (HT) STA that included a value of 1 in the Supported Channel Width Set subfield (indicating its capability to operate on a 40 MHz channel) of its most recent transmission of a frame containing an HT Capabilities element and that sets the PCO field in the HT Extended Capabilities field to 0. nonprimary channel: In a 40 MHz, 80 MHz, 160 MHz, or 80+80 MHz very high throughput (VHT) basic service set (BSS), any 20 MHz channel other than the primary 20 MHz channel. non-quality-of-service management frame (non-QMF) access point (AP): An AP that does not implement the quality-of-service management frame (QMF) service. non-quality-of-service management frame (non-QMF) station (STA): A STA that does not implement the quality-of-service management frame (QMF) service. non-space-time-block-coding (non-STBC) frame: A frame that is transmitted in a physical layer (PHY) protocol data unit (PPDU) that has the TXVECTOR STBC parameter equal to 0, or a frame that is received in a PPDU that has the RXVECTOR STBC parameter equal to 0. nontransmitted basic service set (BSS) identifier (BSSID): A BSSID that is not transmitted explicitly, but that can be derived from the information encoded in Probe Response, Beacon and directional multi-gigabit (DMG) Beacon frames and Neighbor reports. null data packet (NDP): A physical layer (PHY) protocol data unit (PPDU) that carries no Data field. off-channel: A channel used by a tunneled direct link setup (TDLS) station (STA) that does not overlap the channel(s) used by the access point (AP) with which the TDLS STA is associated. operating class: An E.1 index into a set of values for radio operation in a regulatory domain. 157 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications operational rate set: The set of data rates that a station (STA) is capable of receiving. The operational rate set is defined locally by the OperationalRateSet parameter of the MLME-START.request or MLME- JOIN.request primitive. The operational rate set of a peer is defined by the data rates (i.e., excluding the MSB of each octet of the (Extended) Supported Rates field) from the peerâ€™s Supported Rates and BSS Membership Selectors element and, if present, the Extended Supported Rates and BSS Membership Selectors element. outside the context of a basic service set (BSS) (OCB): A mode of operation in which a STA is not a member of a BSS and does not utilize IEEE 802.11 authentication, association, or data confidentiality services. pairwise master key (PMK): The key derived from a key generated by an Extensible Authentication Protocol (EAP) method or obtained directly from a preshared key (PSK). pairwise master key (PMK) R0 key holder (R0KH): The component of robust security network association (RSNA) key management of the Authenticator that is authorized to derive and hold the PMK-R0, derive the PMK-R1s, and distribute the PMK-R1s to the R1KHs. pairwise master key (PMK) R0 key holder identifier (R0KH-ID): An identifier that names the holder of the PMK-R0 in the Authenticator. pairwise master key (PMK) R0 name (PMKR0Name): An identifier that names the PMK-R0. pairwise master key (PMK) R0 (PMK-R0): The key at the first level of the fast basic service set (BSS) transition (FT) key hierarchy. pairwise master key (PMK) R1 key holder (R1KH): The component of robust security network association (RSNA) key management of the Authenticator that receives a PMK-R1 from the R0KH, holds the PMK-R1, and derives the pairwise transient keys (PTKs). pairwise master key (PMK) R1 key holder identifier (R1KH-ID): An identifier that names the holder of a PMK-R1 in the Authenticator. pairwise master key (PMK) R1 name (PMKR1Name): An identifier that names a PMK-R1. pairwise master key (PMK) R1 (PMK-R1): A key at the second level of the fast basic service set (BSS) transition (FT) key hierarchy. pairwise master key (PMK) S0 key holder (S0KH): The component of robust security network association (RSNA) key management of the Supplicant that derives and holds the PMK-R0, derives the PMK-R1s, and provides the PMK-R1s to the S1KH. pairwise master key (PMK) S0 key holder identifier (S0KH-ID): An identifier that names the holder of the PMK-R0 in the Supplicant. pairwise master key (PMK) S1 key holder (S1KH): The component of robust security network association (RSNA) key management in the Supplicant that receives a PMK-R1 from the S0KH, holds the PMK-R1, and derives the pairwise transient keys (PTKs). pairwise master key (PMK) S1 key holder identifier (S1KH-ID): An identifier that names the holder of the PMK-R1 in the Supplicant. 158 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications pairwise master key security association (PMKSA): The context resulting from a successful IEEE 802.1X authentication exchange between the peer and Authentication Server (AS) or from a preshared key (PSK). pairwise transient key (PTK): A concatenation of session keys derived from the pairwise master key (PMK) or from the PMK-R1. Its components are a key confirmation key (KCK), a key encryption key (KEK), and a temporal key (TK), which is used to protect information exchanged over the link. pairwise transient key (PTK) name (PTKName): An identifier that names the PTK. pairwise transient key security association (PTKSA): The context resulting from a successful 4-way handshake between a peer and Authenticator. parameterized quality of service (QoS): The treatment of the medium access control (MAC) protocol data units (MPDUs) depends on the parameters associated with the MPDU. Parameterized QoS is primarily provided through the hybrid coordination function (HCF) controlled channel access (HCCA) mechanism, but is also provided by the enhanced distributed channel access (EDCA) mechanism when used with a traffic specification (TSPEC) for admission control. payload protected (PP) aggregate medium access control (MAC) service data unit (A-MSDU): An A-MSDU that is protected with counter mode (CTR) with cipher-block chaining message authentication code (CBC-MAC) protocol (CCMP) or Galois/counter mode (GCM) protocol (GCMP) but does not include the A-MSDU Present field (bit 7 of the QoS Control field) in the construction of the additional authentication data (AAD). peer trigger frame: A Mesh Data or quality-of-service (QoS) Null frame that initiates a mesh peer service period. PeerKey handshake: A key management protocol composed of the station-to-station link (STSL) master key (SMK) handshake and the 4-way STSL transient key (STK) handshake. This is used to create new SMK security associations (SMKSAs) and STK security associations (STKSAs) to secure the STSLs. peer-specific mesh power management mode: The activity level identifier of a mesh station (STA) set per mesh peering. Three peer-specific mesh power management modes are defined: active mode, light sleep mode, and deep sleep mode. per-frame sequence counter: For temporal key integrity protocol (TKIP), the counter that is used as the nonce in the derivation of the per-frame encryption key. For counter mode with cipher-block chaining message authentication code protocol (CCMP) or Galois/counter mode (GCM) protocol (GCMP), the per- frame initialization vector (IV). personal basic service set (PBSS): A directional multi-gigabit (DMG) basic service set (BSS) that includes one STA that is in a PBSS control point (PCP), and in which access to a distribution system (DS) is not present. personal basic service set (PBSS) control point (PCP): An entity that contains one station (STA) and coordinates access to the wireless medium (WM) by STAs that are members of a PBSS. personal basic service set (PBSS) control point (PCP) or access point (AP) cluster: A single directional multi-gigabit (DMG) synchronization AP or synchronization PCP, plus zero or more neighboring DMG APs or PCPs (or a mixture of both) that join as member APs and PCPs to the synchronization AP or synchronization PCP. 159 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications phased coexistence operation (PCO): A basic service set (BSS) mode with alternating 20 MHz and 40 MHz phases controlled by an access point (AP). phased coexistence operation (PCO) active access point (AP): A high-throughput (HT) AP that is operating PCO. phased coexistence operation (PCO) active basic service set (BSS): A BSS in which a PCO active access point (AP) has the PCO Active field in the HT Operation element equal to 1. phased coexistence operation (PCO) active non-access-point (non-AP) station (STA): A high- throughput (HT) non-AP STA that is associated with a PCO basic service set (BSS) and following PCO. phased coexistence operation (PCO) active station (STA): A STA that is either a PCO active access point (AP) or a PCO active non-AP STA. phased coexistence operation (PCO) capable (PCO-capable) access point (AP): A high-throughput (HT) AP that sets the PCO field in the HT Extended Capabilities field to 1. phased coexistence operation (PCO) capable (PCO-capable) non-access-point (non-AP) station (STA): A high-throughput (HT) non-AP STA that sets the PCO field in the HT Extended Capabilities field to 1. phased coexistence operation (PCO) capable (PCO-capable) station (STA): A STA that is either a PCO capable access point (AP) or a PCO capable non-AP STA. phased coexistence operation (PCO) inactive basic service set (BSS): A 20/40 MHz BSS in which an access point (AP) has the PCO Active field in the HT Operation element equal to 0. point coordination function (PCF): A class of possible coordination functions in which the coordination function logic is active in only one station (STA) in a basic service set (BSS) at any given time that the network is in operation. point coordinator (PC): The entity within the STA in an AP that performs the point coordination function. power save (PS) mode: A power management mode in which a nonmesh station (STA) alternates between awake and doze states. power save multi-poll (PSMP): A mechanism that provides a time schedule that is used by an access point (AP) and its stations (STAs) to access the wireless medium. The mechanism is controlled using the PSMP frame. power save multi-poll (PSMP) burst: A series of one or more PSMP sequences, separated by short interframe space (SIFS). power save multi-poll downlink transmission time (PSMP-DTT): A period of time described by a PSMP frame during which the access point (AP) transmits. power save multi-poll (PSMP) sequence: A sequence of frames in which the first frame is a PSMP frame that is followed by transmissions in zero or more power save multi-poll downlink transmission times (PSMP-DTTs) and then by transmissions in zero or more power save multi-poll uplink transmission times (PSMP-UTTs). The schedule of the PSMP-DTTs and PSMP-UTTs is defined in the PSMP frame. power save multi-poll (PSMP) session: The relationship between an AP and one or more STAs that exists while any TS exists that uses the PSMP mechanism with the same service period. 160 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications power save multi-poll uplink transmission time (PSMP-UTT): A period of time described by a PSMP frame during which a non-access-point (non-AP) station (STA) can transmit. power save multi-poll uplink transmission time (PSMP-UTT) spacing: The period of time between the end of one PSMP-UTT and the start of the following PSMP-UTT within the same PSMP sequence. power save (PS) station (STA): A station that is in power save mode. pre-robust security network association (pre-RSNA): The type of association used by a pair of stations (STAs) if the procedure for establishing authentication or association between them did not include the 4- way handshake. pre-robust security network association (pre-RSNA) STA: A STA that is not able to create robust security network associations (RSNAs). primary 20 MHz channel: In a 40 MHz, 80 MHz, 160 MHz, or 80+80 MHz very high throughput (VHT) basic service set (BSS), the 20 MHz channel that is used to transmit 20 MHz physical layer (PHY) protocol data units (PPDUs). In a VHT BSS, the primary 20 MHz channel is also the primary channel. primary 40 MHz channel: In an 80 MHz, 160 MHz, or 80+80 MHz very high throughput (VHT) basic service set (BSS), the 40 MHz channel that is used to transmit 40 MHz physical layer (PHY) protocol data units (PPDUs). primary 80 MHz channel: In a 160 MHz or 80+80 MHz very high throughput (VHT) basic service set (BSS), the 80 MHz channel that is used to transmit 80 MHz physical layer (PHY) protocol data units (PPDUs). primary access category (AC): The AC associated with the enhanced distributed channel access function (EDCAF) that gains channel access. Protected Dual of Public Action frame: An Action frame with the category value specified in 9.4.1.11 (Table 9-47). For each Protected Dual of Public Action frame, there is a dual Action frame in a category that is specified with â€œNoâ€ in the â€œRobustâ€ column of Table 9-47. quality-of-service management frame (QMF): A Management frame that is transmitted using the QMF service. quality-of-service management frame (QMF) access point (AP): A quality-of-service AP that implements the QMF service. quality-of-service management frame (QMF) policy: A policy defining the access category of Management frames. QMF stations (STAs) transmit their Management frames using the access category defined by the policy. quality-of-service management frame (QMF) service: A service in which the enhanced distributed channel access (EDCA) access category with which a Management frame is sent is determined according to a configured policy. quality-of-service management frame (QMF) station (STA): A quality-of-service STA that implements the QMF service. quality-of-service (QoS) frame: A frame containing the QoS Control field. 161 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications quasi-omni antenna pattern: A directional multi-gigabit (DMG) antenna operating mode with the widest beamwidth attainable. receive sector sweep (RXSS): Reception of Sector Sweep (SSW) frames via different sectors, in which a sweep is performed between consecutive receptions. received signal-to-noise indicator (RSNI): An indication of the signal-to-noise plus interference ratio of a received frame. resource information container (RIC): A sequence of elements that include resource request and response parameters. reverse direction (RD) initiator: A station (STA) that is a transmit opportunity (TXOP) holder that transmits a medium access control (MAC) protocol data unit (MPDU) in which the reverse direction grant/ more physical layer protocol data unit (RDG/More PPDU) subfield is equal to 1. reverse direction (RD) responder: A station (STA) that is not the RD initiator and whose medium access control (MAC) address matches the value of the Address 1 field of a received MAC protocol data unit (MPDU) in which the RDG/More PPDU subfield is equal to 1. robust Action frame: An Action frame with a category value specified in 9.4.1.11 (Table 9-47 with â€œYesâ€ in the â€œRobustâ€ column). robust Management frame: A Management frame that is eligible for protection. robust security network association (RSNA): The type of association used by a pair of stations (STAs) if the procedure to establish authentication or association between them includes the 4-way handshake or FT protocol. Note that existence of an RSNA between two STAs does not of itself provide robust security. Robust security is provided when all STAs in the network use RSNAs. robust security network association (RSNA) capable (RSNA-capable): Pertains to a station (STA) that is able to create RSNAs. robust security network association (RSNA) key management: Key management that includes the 4-way handshake, the group key handshake, authenticated mesh peering exchange, mesh group key handshake, and the PeerKey handshake. If fast basic service set (BSS) transition (FT) is enabled, the FT 4-way handshake and FT authentication sequence are also included. robust security network (RSN): A security network that allows only the creation of robust security network associations (RSNAs). An RSN can be identified by the indication in the RSN element (RSNE) of Beacon frames that the group cipher suite specified is not wired equivalent privacy (WEP). scheduled service period (SP): An SP that is scheduled by a quality-of-service (QoS) access point (AP) or a personal basic service set (PBSS) control point (PCP). secondary 20 MHz channel: In a 40 MHz very high throughput (VHT) basic service set (BSS), the 20 MHz channel adjacent to the primary 20 MHz channel that together form the 40 MHz channel of the 40 MHz VHT BSS. In an 80 MHz VHT BSS, the 20 MHz channel adjacent to the primary 20 MHz channel that together form the primary 40 MHz channel of the 80 MHz VHT BSS. In a 160 MHz or 80+80 MHz VHT BSS, the 20 MHz channel adjacent to the primary 20 MHz channel that together form the primary 40 MHz channel of the 160 MHz or 80+80 MHz VHT BSS. In a VHT BSS, the secondary 20 MHz channel is also the secondary channel. 162 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications secondary 40 MHz channel: In an 80 MHz very high throughput (VHT) basic service set (BSS), the 40 MHz channel adjacent to the primary 40 MHz channel that together form the 80 MHz channel of the 80 MHz VHT BSS. In a 160 MHz or 80+80 MHz VHT BSS, the 40 MHz channel adjacent to the primary 40 MHz channel that together form the primary 80 MHz channel. secondary 80 MHz channel: In a 160 MHz or 80+80 MHz very high throughput (VHT) basic service set (BSS), the 80 MHz channel not including the primary 20 MHz channel, that together with the primary 80 MHz channel form the 160 MHz or 80+80 MHz channel of the 160 MHz or 80+80 MHz VHT BSS. secondary access category (AC): An AC that is not associated with the enhanced distributed channel access function (EDCAF) that gains channel access. NOTEâ€”Traffic associated with a secondary AC can be included in a multi-user (MU) physical layer (PHY) protocol data unit (MU PPDU) that includes traffic associated with the primary AC. There could be multiple secondary ACs at a given time. secondary channel: A 20 MHz channel associated with a primary channel used by high-throughput (HT) stations (STAs) for the purpose of creating a 40 MHz channel or used by very high throughput (VHT) STAs for the purpose of creating the primary 40 MHz channel. sector: A transmit or receive antenna pattern corresponding to a sector identifier (ID). security network: A basic service set (BSS) in which the station (STA) starting the BSS provides information about the security capabilities and configuration of the BSS by including the robust security network element (RSNE) in Beacon frames. self-protected action frame: An Action frame that is not eligible for protection by the robust management frame service. The protection on each Self-protected Action frame is provided by the protocol that uses the frame. service interval (SI): The interval between the starts of two successive scheduled service periods (SPs). service period (SP): A period of time during which one or more downlink individually addressed frames are transmitted to a quality-of-service (QoS) station (STA) and/or one or more transmission opportunities (TXOPs) are granted to the same STA. SPs are either scheduled or unscheduled. NOTEâ€”A non-access-point (non-AP) STA can have at most one nongroupcast with retries SP (non-GCR-SP) active at any time. shared bands: Radio frequency bands in which dissimilar services are permitted. signaling and payload protected (SPP) aggregate medium access control (MAC) service data unit (A-MSDU): An A-MSDU that is protected with counter mode (CTR) with cipher-block chaining message authentication code (CBC-MAC) protocol (CCMP) or Galois/counter mode (GCM) protocol (GCMP) and that includes the A-MSDU Present field (bit 7 of the QoS Control field) in the construction of the additional authentication data (AAD). sounding physical layer (PHY) protocol data unit (PPDU): A PPDU that is intended by the transmitting station (STA) to enable the receiving STA to estimate the channel between the transmitting STA and the receiving STA. The Not Sounding field in the High Throughput SIGNAL field (HT-SIG) is equal to 0 in sounding PPDUs. source directional multi-gigabit (DMG) station (STA): A DMG STA identified by the source association identifier (AID) field contained in a Grant frame or Extended Schedule element that caused the allocation of a service period (SP) or contention based access period (CBAP). 163 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications space-time block coding (STBC) beacon: A beacon that is transmitted using the basic STBC modulation and coding scheme (MCS) to enable discovery of the basic service set (BSS) by high-throughput (HT) stations (STAs) that support the HT STBC feature in order to extend the range of the BSS. space-time block coding (STBC) delivery traffic indication map (DTIM): An STBC beacon transmission that is a DTIM Beacon frame. space-time block coding (STBC) frame: A frame that is transmitted in a physical layer (PHY) protocol data unit (PPDU) that has a nonzero value of the TXVECTOR STBC parameter, or a frame that is received in a PPDU that has a nonzero value of the RXVECTOR STBC parameter. spatial sharing (SPSH): Use of a frequency channel by multiple stations (STAs) that are located in the same vicinity, and whose directional transmissions might overlap in time. staggered preamble: A physical layer (PHY) preamble in a sounding PHY protocol data unit (PPDU) that is not a null data packet (NDP) and that includes one or more Data Long Training fields (DLTFs) and one or more Extension Long Training fields (ELTFs). staggered sounding: The use of a sounding physical layer (PHY) protocol data unit (PPDU) that is not a null data packet (NDP) and that includes one or more Data Long Training fields (DLTFs) and one or more Extension Long Training fields (ELTFs). station (STA) 2G4: A STA that is operating on a channel that belongs to any operating class that has a value of 25 or 40 for the entry in the â€œChannel spacingâ€ column and that has a value of 2.407 or 2.414 for the entry in the â€œChannel starting frequencyâ€ column of any of the tables found in E.1. station (STA) 5G: A STA that is operating on a channel that belongs to any operating class that has a value of 20 or 40 for the entry in the â€œChannel spacingâ€ column and that has a value of 5 for the entry in the â€œChannel starting frequencyâ€ column of any of the tables found in E.1. station-to-station link (STSL): A direct link established between two non-access-point (non-AP) stations (STAs) while associated to a common access point (AP), that was not established using tunneled direct-link setup (TDLS). station-to-station link (STSL) master key security association (SMKSA): The context resulting from a successful STSL master key (SMK) handshake. station-to-station link (STSL) master key (SMK): A random value generated by an access point (AP) during an SMK handshake. It is used for deriving an STSL transient key (STK). station-to-station link (STSL) master key (SMK) handshake: A key management protocol between two parties that creates a new SMK. station-to-station link (STSL) transient key security association (STKSA): The context resulting from a successful 4-way STSL transient key (STK) exchange. station-to-station link (STSL) transient key (STK): A concatenation of session keys derived from the STSL master key (SMK). Its components are an STSL key confirmation key (SKCK), an STSL key encryption key (SKEK), and a temporal key (TK), which is used to protect information exchanged over the link. subscription service provider (SSP) roaming: The act when a station (STA) uses an SSPâ€™s IEEE 802.11 infrastructure, with which the terminal has no direct agreement, based on a subscription and formal agreement with the STAâ€™s own SSP. 164 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications successful transmission: A transmission and the reception of its expected acknowledgment or a transmission for which no acknowledgment is expected. sweep: A sequence of transmissions, separated by a short beamforming interframe space (SBIFS) interval, in which the antenna configuration at the transmitter or receiver is changed between transmissions. synchronization access point (AP) (S-AP): An AP that provides synchronization and other services to an AP cluster or personal basic service set (PBSS) control point (PCP). synchronization personal basic service set (PBSS) control point (PCP) (S-PCP): A PCP that provides synchronization and other services to an access point (AP) cluster or PCP cluster. television very high throughput 2W (TVHT_2W): Two contiguous basic channel units (BCUs) in television white spaces (TVWS). television very high throughput 2W+2W (TVHT_2W+2W): Two noncontiguous frequency segments, each of which comprises two contiguous basic channel units (BCUs) in television white spaces (TVWS). television very high throughput 4W (TVHT_4W): Four contiguous basic channel units (BCUs) in television white spaces (TVWS). television very high throughput (TVHT) basic service set (BSS): A set of stations (STAs) that consists of a geolocation database dependent (GDD) enabling STA operating in television white spaces (TVWS) and one or more of its GDD STAs. television very high throughput W (TVHT_W): One basic channel unit in television white spaces (TVWS). television very high throughput W+W (TVHT_W+W): Two noncontiguous basic channel units (BCUs) in television white spaces (TVWS). temporal encryption key: The portion of a pairwise transient key (PTK) or group temporal key (GTK) used directly or indirectly to encrypt data in medium access control (MAC) protocol data units (MPDUs). temporal key (TK): Temporal key integrity protocol (TKIP) only: The combination of temporal encryption key and a message integrity code (MIC) key. Non-TKIP only: A temporal encryption key. time priority Management frame: a Management frame that is transmitted using specific frame type channel access rules. traffic indication map (TIM) broadcast: A service that enables a non-access-point (non-AP) station (STA) to request periodic transmission of a TIM frame by the AP. TIM frames have shorter duration than Beacon frames and can be transmitted at a higher physical layer (PHY) rate, which allows the STA to save additional power while periodically checking for buffered traffic in standby mode, relative to the power consumed if the station (STA) were to periodically wake up to receive a Beacon frame. traffic stream identifier (TSID): Any of the identifiers usable by higher layer entities to distinguish medium access control (MAC) service data units (MSDUs) to MAC entities for parameterized quality of service (QoS) [i.e., the traffic stream (TS) with a particular traffic specification (TSPEC)] within the MAC data service. The TSID is assigned to an MSDU in the layers above the MAC. transition security network (TSN): A security network that allows the creation of pre-robust security network associations (pre-RSNAs) as well as RSNAs. A TSN is identified by the indication in the robust 165 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications security network element (RSNE) of Beacon frames that the group cipher suite in use is wired equivalent privacy (WEP). transmission opportunity (TXOP) holder: A quality-of-service (QoS) station (STA) that has either been granted a TXOP by the hybrid coordinator (HC) or successfully contended for a TXOP. transmission opportunity (TXOP) responder: A station (STA) that transmits a frame in response to a frame received from a TXOP holder during a frame exchange sequence, but that does not acquire a TXOP in the process. transmit power: The effective isotropic radiated power (EIRP) when referring to the operation of an orthogonal frequency division multiplexing (OFDM) physical layer (PHY) in a country where so regulated. transmit sector sweep (TXSS): Transmission of multiple sector sweep (SSW) or directional multi-gigabit (DMG) Beacon frames via different sectors, in which a sweep is performed between consecutive transmissions. transmit sector sweep (TXSS) contention based access period (CBAP): A CBAP that is available to all stations (STAs) in an extended centralized personal basic service set (PBSS) control point (PCP) or access point (AP) cluster outside which TXSSs in the data transfer interval (DTI) can be prohibited. transmitted basic service set identifier (BSSID): The BSSID included in the medium access control (MAC) header transmitter address field of a Beacon frame when the multiple BSSID capability is supported. trigger-enabled access category (AC): A quality-of-service (QoS) station (STA) AC where frames of subtype QoS Data and QoS Null from the STA that map to the AC trigger an unscheduled service period (SP) if one is not in progress. tunneled direct-link setup (TDLS): A protocol that uses a specific Ethertype encapsulation to TDLS frames through an access point (AP) to establish a TDLS direct link. tunneled direct-link setup (TDLS) direct link: Direct link between two non-access-point (non-AP) stations (STAs) that has been established using the TDLS protocol. tunneled direct-link setup (TDLS) initiator station (STA): A STA that transmits a TDLS Setup Request frame or a TDLS Discovery Request frame. tunneled direct-link setup (TDLS) peer power save mode (PSM): A PSM that is based on periodically scheduled service periods (SPs), which can be used between two stations (STAs) that have set up a TDLS direct link. tunneled direct-link setup (TDLS) peer power save mode (PSM) initiator: A station (STA) that transmits a TDLS Peer PSM Request frame. tunneled direct-link setup (TDLS) peer power save mode (PSM) responder: A station (STA) that transmits a TDLS Peer PSM Response frame. tunneled direct-link setup (TDLS) peer station (STA): A STA with a TDLS direct link. tunneled direct-link setup (TDLS) peer unscheduled automatic power save delivery (U-APSD) [TDLS peer U-APSD (TPU)]: A power save mode based on unscheduled service periods that can be used between two stations (STAs) that have set up a TDLS direct link. 166 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications tunneled direct-link setup (TDLS) peer unscheduled automatic power save delivery (U-APSD) [TDLS peer U-APSD (TPU)] buffer station (STA): A TDLS peer STA that buffers traffic for a TPU sleep STA. tunneled direct-link setup (TDLS) peer unscheduled automatic power save delivery (U-APSD) [TDLS peer U-APSD (TPU)] sleep station (STA): A TDLS STA that entered power save mode on a TDLS direct link and that is using TPU for the delivery of buffered traffic. tunneled direct-link setup (TDLS) power save mode (PSM): TDLS peer PSM or peer unscheduled automatic power save delivery (U-APSD). tunneled direct-link setup (TDLS) responder station (STA): A STA that receives or is the intended recipient of a TDLS Setup Request frame or TDLS Discovery Request frame. TVHT_2W mask physical layer (PHY) protocol data unit (PPDU): One of the following PPDUs: a) A Clause 22 TVHT_2W very high throughput (VHT) PPDU (TX_VECTOR parameter CH_BANDWIDTH set to TVHT_2W and TXVECTOR parameter FORMAT set to VHT) transmitted using the TVHT_2W transmit spectral mask defined in 22.3.17.1 b) A Clause 22 TVHT_2W NON_HT PPDU (TX_VECTOR parameter CH_BANDWIDTH set to TVHT_2W, TXVECTOR parameter FORMAT set to NON_HT, and TXVECTOR parameter NON_HT_MODULATION set to NON_HT_DUP_OFDM) transmitted using the TVHT_2W transmit spectral mask defined in 22.3.17.1 c) A Clause 22 TVHT_W VHT PPDU (TX_VECTOR parameter CH_BANDWIDTH set to TVHT_W and TXVECTOR parameter FORMAT set to VHT) transmitted using the TVHT_2W transmit spectral mask defined in 22.3.17.1 d) A Clause 22 TVHT_W NON_HT PPDU (TX_VECTOR parameter CH_BANDWIDTH set to TVHT_W, TXVECTOR parameter FORMAT set to NON_HT, and TXVECTOR parameter NON_HT_MODULATION set to NON_HT_DUP_OFDM) transmitted using the TVHT_2W transmit spectral mask defined in 22.3.17.1 TVHT_2W+2W mask physical layer (PHY) protocol data unit (PPDU): One of the following PPDUs: a) A Clause 22 TVHT_2W+2W very high throughput (VHT) PPDU (TX_VECTOR parameter CH_BANDWIDTH set to TVHT_2W+2W and TXVECTOR parameter FORMAT set to VHT) transmitted using the TVHT_2W+2W transmit spectral mask defined in 22.3.17.1 b) A Clause 22 TVHT_2W+2W NON_HT PPDU (TX_VECTOR parameter CH_BANDWIDTH set to TVHT_2W+2W, TXVECTOR parameter FORMAT set to NON_HT, and TXVECTOR parameter NON_HT_MODULATION set to NON_HT_DUP_OFDM) transmitted using the TVHT_2W+2W transmit spectral mask defined in 22.3.17.1 c) A Clause 22 TVHT_2W VHT PPDU (TX_VECTOR parameter CH_BANDWIDTH set to TVHT_2W and TXVECTOR parameter FORMAT set to VHT) transmitted using the TVHT_2W+2W transmit spectral mask defined in 22.3.17.1 d) A Clause 22 TVHT_2W NON_HT PPDU (TX_VECTOR parameter CH_BANDWIDTH set to TVHT_2W, TXVECTOR parameter FORMAT set to NON_HT, and TXVECTOR parameter NON_HT_MODULATION set to NON_HT_DUP_OFDM) transmitted using the TVHT_2W+2W transmit spectral mask defined in 22.3.17.1 e) A Clause 22 TVHT_W VHT PPDU (TX_VECTOR parameter CH_BANDWIDTH set to TVHT_W and TXVECTOR parameter FORMAT set to VHT) transmitted using the TVHT_2W+2W transmit spectral mask defined in 22.3.17.1 f) A Clause 22 TVHT_W NON_HT PPDU (TX_VECTOR parameter CH_BANDWIDTH set to TVHT_W, TXVECTOR parameter FORMAT set to NON_HT, and TXVECTOR parameter NON_HT_MODULATION set to NON_HT_DUP_OFDM) transmitted using the TVHT_2W+2W transmit spectral mask defined in 22.3.17.1 167 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications TVHT_4W mask physical layer (PHY) protocol data unit (PPDU): One of the following PPDUs: a) A Clause 22 TVHT_4W very high throughput (VHT) PPDU (TX_VECTOR parameter CH_BANDWIDTH set to TVHT_4W and TXVECTOR parameter FORMAT set to VHT) transmitted using the TVHT_4W transmit spectral mask defined in 22.3.17.1 b) A Clause 22 TVHT_4W NON_HT PPDU (TX_VECTOR parameter CH_BANDWIDTH set to TVHT_4W, TXVECTOR parameter FORMAT set to NON_HT, and TXVECTOR parameter NON_HT_MODULATION set to NON_HT_DUP_OFDM) transmitted using the TVHT_4W transmit spectral mask defined in 22.3.17.1 c) A Clause 22 TVHT_2W VHT PPDU (TX_VECTOR parameter CH_BANDWIDTH set to TVHT_2W and TXVECTOR parameter FORMAT set to VHT) transmitted using the TVHT_4W transmit spectral mask defined in 22.3.17.1 d) A Clause 22 TVHT_2W NON_HT PPDU (TX_VECTOR parameter CH_BANDWIDTH set to TVHT_2W, TXVECTOR parameter FORMAT set to NON_HT, and TXVECTOR parameter NON_HT_MODULATION set to NON_HT_DUP_OFDM) transmitted using the TVHT_4W transmit spectral mask defined in 22.3.17.1 e) A Clause 22 TVHT_W VHT PPDU (TX_VECTOR parameter CH_BANDWIDTH set to TVHT_W and TXVECTOR parameter FORMAT set to VHT) transmitted using the TVHT_4W transmit spectral mask defined in 22.3.17.1 f) A Clause 22 TVHT_W NON_HT PPDU (TX_VECTOR parameter CH_BANDWIDTH set to TVHT_W, TXVECTOR parameter FORMAT set to NON_HT, and TXVECTOR parameter NON_HT_MODULATION set to NON_HT_DUP_OFDM) transmitted using the TVHT_4W transmit spectral mask defined in 22.3.17.1 TVHT_MODE_1 physical layer (PHY) protocol data unit (PPDU): One of the following PPDUs: A Clause 22 TVHT_W VHT PPDU or TVHT_W NON_HT PPDU. TVHT_MODE_2C physical layer (PHY) protocol data unit (PPDU): One of the following PPDUs: A Clause 22 TVHT_2W VHT PPDU or TVHT_2W NON_HT PPDU. TVHT_MODE_2N physical layer (PHY) protocol data unit (PPDU): One of the following PPDUs: A Clause 22 TVHT_W+W VHT PPDU or TVHT_W+W NON_HT PPDU. TVHT_MODE_4C physical layer (PHY) protocol data unit (PPDU): One of the following PPDUs: A Clause 22 TVHT_4W VHT PPDU or TVHT_4W NON_HT PPDU. TVHT_MODE_4N physical layer (PHY) protocol data unit (PPDU): One of the following PPDUs: A Clause 22 TVHT_2W+2W VHT PPDU or TVHT_2W+2W NON_HT PPDU. TVHT_W mask physical layer (PHY) protocol data unit (PPDU): One of the following PPDUs: a) A Clause 22 TVHT_W very high throughput (VHT) PPDU (TX_VECTOR parameter CH_BANDWIDTH set to TVHT_W and TXVECTOR parameter FORMAT set to VHT) transmitted using the TVHT_W transmit spectral mask defined in 22.3.17.1 b) A Clause 22 TVHT_W NON_HT PPDU (TX_VECTOR parameter CH_BANDWIDTH set to TVHT_W, TXVECTOR parameter FORMAT set to NON_HT, and TXVECTOR parameter NON_HT_MODULATION set to NON_HT_DUP_OFDM) transmitted using the TVHT_W transmit spectral mask defined in 22.3.17.1 TVHT_W+W mask physical layer (PHY) protocol data unit (PPDU): One of the following PPDUs: a) A Clause 22 TVHT_W+W very high throughput (VHT) PPDU (TX_VECTOR parameter CH_BANDWIDTH set to TVHT_W+W and TXVECTOR parameter FORMAT set to VHT) transmitted using the TVHT_W+W transmit spectral mask defined in 22.3.17.1 168 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications b) A Clause 22 TVHT_W+W NON_HT PPDU (TX_VECTOR parameter CH_BANDWIDTH set to TVHT_W+W, TXVECTOR parameter FORMAT set to NON_HT, and TXVECTOR parameter NON_HT_MODULATION set to NON_HT_DUP_OFDM) transmitted using the TVHT_W+W transmit spectral mask defined in 22.3.17.1 c) A Clause 22 TVHT_W VHT PPDU (TX_VECTOR parameter CH_BANDWIDTH set to TVHT_W and TXVECTOR parameter FORMAT set to VHT) transmitted using the TVHT_W+W transmit spectral mask defined in 22.3.17.1 d) A Clause 22 TVHT_W NON_HT PPDU (TX_VECTOR parameter CH_BANDWIDTH set to TVHT_W, TXVECTOR parameter FORMAT set to NON_HT, and TXVECTOR parameter NON_HT_MODULATION set to NON_HT_DUP_OFDM) transmitted using the TVHT_W+W transmit spectral mask defined in 22.3.17.1 unscheduled service period (SP): The period that is started when a quality-of-service (QoS) station (STA) transmits a trigger frame to the QoS access point (AP). uplink: A unidirectional link from a non-access point (non-AP) station (STA) to an access point (AP) or a unidirectional link from a non-AP source directional multi-gigabit (DMG) STA to a non-AP destination DMG STA. user: An individual station or group of stations (STAs) identified by a single receive address (RA) in the context of single-user multiple input, multiple output (SU-MIMO) or multi-user multiple input, multiple output (MU-MIMO). vendor organizationally unique identifier (OUI): An OUI that is not the IEEE 802.11 OUI (00-0F-AC) very high throughput (VHT) basic service set (BSS): A BSS in which a Beacon frame transmitted by a VHT station (STA) includes the VHT Operation element. very high throughput (VHT) beamformee: A VHT station (STA) that receives a VHT physical layer (PHY) protocol data unit (PPDU) that was transmitted using a beamforming steering matrix and that supports the VHT transmit beamforming feedback mechanism. very high throughput (VHT) beamformer: A VHT station (STA) that transmits a VHT physical layer (PHY) protocol data unit (PPDU) using a beamforming steering matrix. very high throughput (VHT) modulation and coding scheme (VHT-MCS): A specification of the VHT physical layer (PHY) parameters that consists of modulation order (e.g., BPSK, QPSK, 16-QAM, 64-QAM, 256-QAM) and forward error correction (FEC) coding rate (e.g., 1/2, 2/3, 3/4, 5/6) and that is used in a VHT PHY protocol data unit (PPDU). very high throughput (VHT) multi-user (MU) physical layer (PHY) protocol data unit (PPDU): A VHT PPDU with a format that is capable of carrying up to four PHY service data units (PSDUs) for up to four users and is transmitted using the downlink multi-user multiple input, multiple output (DL-MU-MIMO) technique. very high throughput (VHT) physical layer (PHY) protocol data unit (PPDU): A PPDU transmitted with the TXVECTOR parameter FORMAT equal to VHT. very high throughput (VHT) single medium access control (MAC) protocol data unit (VHT single MPDU): An MPDU that is the only MPDU in an aggregate MPDU (A-MPDU) carried in a VHT physical layer (PHY) protocol data unit (PPDU) and that is carried in an A-MPDU subframe with the EOF subfield of the MPDU delimiter field equal to 1. 169 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications very high throughput (VHT) single-user-only (SU-only) beamformee: A VHT beamformee that does not receive VHT multi-user (MU) physical layer (PHY) protocol data units (PPDUs). very high throughput (VHT) single-user-only (SU-only) beamformer: A VHT beamformer that does not transmit VHT multi-user (MU) physical layer (PHY) protocol data units (PPDUs). very high throughput (VHT) single-user (SU) physical layer (PHY) protocol data unit (PPDU): A VHT PPDU transmitted with the TXVECTOR parameters FORMAT equal to VHT and GROUP_ID equal to 0 or 63. white space map (WSM): Information on identified available frequencies that is obtained from a geolocation database (GDB) and that is used by IEEE 802.11 stations (STAs). wired equivalent privacy (WEP): A deprecated cryptographic data confidentiality algorithm specified by this standard. wireless network management (WNM) sleep mode: An extended power save mode for non-access-point (non-AP) stations (STAs) whereby a non-AP STA need not listen for every delivery traffic indication map (DTIM) Beacon frame and does not perform group temporal key/integrity group temporal key (GTK/IGTK) updates. 3.3 Definitions specific to IEEE 802.11 operation in some regulatory domains ISO 3166-1 defines the international two-letter designation for country names, and these designations are included [in square brackets] at the end of each definition that has clear attribution to a regulatory domain. contact verification signal (CVS): A signal sent by a geolocation database dependent (GDD) enabling station (STA) to validate the list of available frequencies and to verify that the receiving GDD STA is within reception range of the master white space device (WSD) [US]. personal/portable station (STA): A STA that uses network communications at unspecified locations [US]. television band device (TVBD): An intentional radiator that operates on an unlicensed basis on available channels in the broadcast television frequency bands [US]. white space device (WSD): An entity that employs cognitive facilities to use white space spectrum without causing harmful interference to protected services [EU]. 3.4 Abbreviations and acronyms 3GPP 3rd Generation Partnership Project 40MC forty MHz capable 802.x LAN IEEE 802-based local area networks such as IEEE Std 802.3 and IEEE Std 802.11 AA authenticator address AAA authentication, authorization, and accounting AAD additional authentication data A-BFT association beamforming training AC access category ACI access category index Ack acknowledgment ACM admission control mandatory 170 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ACU admission control unit ADDBA add block acknowledgment ADDTS add traffic stream AES advanced encryption standard AES-128-CMAC advanced encryption standard (with 128-bit key) cipher-based message authentication code AFC automatic frequency control AGC automatic gain control AID association identifier AIFS arbitration interframe space AIFSN arbitration interframe space number AKM authentication and key management AKMP authentication and key management protocol A-MPDU aggregate MAC protocol data unit AMPE authenticated mesh peering exchange A-MSDU aggregate MAC service data unit ANIPI average noise plus interference power indicator ANonce authenticator nonce ANPI average noise power indicator ANQP access network query protocol AP access point APSD automatic power save delivery ARP Address Resolution Protocol AS authentication server ASEL antenna selection ASN.1 Abstract Syntax Notation One ASRA additional step required for access ATI announcement transmission interval ATIM announcement traffic indication message AV audio video AWV antenna weight vector BA block acknowledgment BAR block acknowledgment request BC beam combining BCC binary convolutional code BCU basic channel unit BF beamforming BHI beacon header interval BIP broadcast/multicast integrity protocol BPSK binary phase shift keying BRP beam refinement protocol BRPIFS beam refinement protocol interframe space BSA basic service area BSS basic service set BSSID basic service set identifier BT bit time 171 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications BTI beacon transmission interval BU bufferable unit BW bandwidth CAP controlled access phase CAQ channel availability query CBAP contention based access period CBC cipher-block chaining CBC-MAC cipher-block chaining message authentication code CBP contention based protocol CCA clear channel assessment CCK complementary code keying CCM CTR with CBC-MAC CCMP CTR with CBC-MAC Protocol CCSR centralized coordination service root CCSS centralized coordination service set CF contention free CFP contention free period CID Company ID C-MPDU coded MPDU CP contention period C-PSDU coded PSDU CRC cyclic redundancy code CS carrier sense CSD cyclic shift diversity CSI channel state information CSM channel schedule management CSMA/CA carrier sense multiple access with collision avoidance CTR counter mode CTS clear to send CTS1 clear to send 1 CTS2 clear to send 2 CVS contact verification signal CW contention window DA destination address DBPSK differential binary phase shift keying DCF distributed coordination function DCLA dc level adjustment DEI drop eligibility indicator DELBA delete block acknowledgment DELTS delete traffic stream DFS dynamic frequency selection DFT discrete Fourier transform DIFS distributed (coordination function) interframe space DLL data link layer DL-MU-MIMO downlink multi-user multiple input, multiple output DLS direct-link setup 172 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DLTF Data Long Training field DMG directional multi-gigabit DMS directed multicast service DMSID directed multicast service identifier DN destination network DO DFS owner Dp desensitization DQPSK differential quadrature phase shift keying DR data rate DS distribution system DSAF distribution system access function DSCP differentiated services code point DSE dynamic station enablement DSM distribution system medium DSS distribution system service DSSS direct sequence spread spectrum DST daylight saving time DTI data transfer interval DTIM delivery traffic indication map DTP dynamic tone pairing EAP Extensible Authentication Protocol (IETF RFC 3748 [B42]) EAPOL Extensible Authentication Protocol over LANs (IEEE Std 802.1X-2010) EAS emergency alert system EBR expedited bandwidth request ECAPC extended centralized AP or PCP cluster ECS extended channel switching ED energy detection EDCA enhanced distributed channel access EDCAF enhanced distributed channel access function EDT eastern daylight time EHCC extended hyperbolic congruence code EIFS extended interframe space EIRP equivalent isotropically radiated power ELTF Extension Long Training field EOF end-of-frame EOSP end of service period EPD EtherType Protocol Discrimination (IEEE Std 802-2014) ERP extended rate PHY ERP-CCK extended rate PHY using CCK modulation ERP-DSSS extended rate PHY using DSSS modulation ERP-DSSS/CCK extended rate PHY using DSSS or CCK modulation ERP-OFDM extended rate PHY using OFDM modulation ESA extended service area ESP estimated service parameters ESR emergency services reachable ESS extended service set 173 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications EST eastern standard time EVM error vector magnitude FCS frame check sequence FD-AF full-duplex amplify-and-forward FEC forward error correction FER frame error ratio FFC finite field cryptography FFE finite field element FFT Fast Fourier Transform FIFO first in first out FMS flexible multicast service FMSID flexible multicast stream identifier FOV field of view FSM finite state machine FST fast session transfer FSTS fast session transfer session FT fast BSS transition FTAA fast BSS transition authentication algorithm FTE fast BSS transition element FTM fine timing measurement FTO fast BSS transition originator GANN gate announcement GAS generic advertisement service GATS group addressed transmission service GCM Galois/counter mode GCMP Galois/Counter Mode Protocol GCR groupcast with retries GCR-A groupcast with retries active GCR-SP groupcast with retries service period GDB geolocation database GDD geolocation database dependent GFSK Gaussian frequency shift key or keying GI guard interval GID group identifier GMK group master key GNonce group nonce GP grant period GPRS general packet radio service GPS Global Positioning System GQMF group addressed quality-of-service Management frame GTK group temporal key GTKSA group temporal key security association HC hybrid coordinator HCC hyperbolic congruence code HCCA HCF controlled channel access HCF hybrid coordination function 174 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications HD-DF half-duplex decode-and-forward HEC header error check HELD HTTP-enabled location delivery HEMM HCCA, EDCA mixed mode HESSID homogenous extended service set identifier HIPERLAN high-performance radio local area network HPA high power amplifier HR/DSSS high rate direct sequence spread spectrum using the long preamble and header HR/DSSS/short high rate direct sequence spread spectrum using the optional short preamble and header mode HT high-throughput HTC high-throughput control HT-GF-STF high-throughput Greenfield Short Training field HT-SIG high-throughput SIGNAL field HT-STF high-throughput Short Training field HTTP hyptertext transfer protocol HTTPS hyptertext transfer protocol secure HWMP hybrid wireless mesh protocol HWMP SN hybrid wireless mesh protocol sequence number IBSS independent basic service set ICMP Internet Control Message Protocol ICV integrity check value IDFT inverse discrete Fourier transform IFFT inverse Fast Fourier Transform IFS interframe space IGTK integrity group temporal key IGTKSA integrity group temporal key security association IMp intermodulation protection INonce initiator nonce IPI idle power indicator IPN IGTK packet number IQMF individually addressed quality-of-service Management frame I/Q in phase and quadrature ISM industrial, scientific, and medical ISS initiator sector sweep IUT implementation under test IV initialization vector KCK EAPOL-Key confirmation key KDE key data encapsulation KDF key derivation function KEK EAPOL-Key encryption key LAN local area network LBIFS long beamforming interframe space LCI location configuration information LDPC low-density parity check LFSR linear feedback shift register 175 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications LGR legendre symbol LLC logical link control L-LTF non-HT Long Training field LME layer management entity LNA low noise amplifier LP low power LPD LLC Protocol Discrimination (IEEE Std 802-2014) LRC long retry count LSB least significant bit L-SIG non-HT SIGNAL field L-STF non-HT Short Training field LTF Long Training field MAC medium access control MAC_I initiator mac address MAC_P peer mac address MAF MCCA access fraction MBCA mesh beacon collision avoidance MBIFS medium beamforming interframe space MBSS mesh basic service set MCCA MCF controlled channel access MCCAOP MCF controlled channel access opportunity MCF mesh coordination function MCS modulation and coding scheme MDE Mobility Domain element MDID mobility domain identifier MFB MCS feedback MFPC management frame protection capable MFPR management frame protection required MFSI MCS feedback sequence identifier MGTK mesh group temporal key MIB management information base MIC message integrity code MID multiple sector identifier MIDC multiple sector identifier capture MIH media-independent handover MIMO multiple input, multiple output MLME MAC sublayer management entity MLPP multi-level precedence and preemption MME Management MIC element MMPDU MAC management protocol data unit MMS multiple MAC sublayers MMSL multiple MAC sublayers link MM-SME multiple MAC station management entity MPDU MAC protocol data unit MPM mesh peering management MRQ MCS request 176 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MSB most significant bit MSDU MAC service data unit MSGCF MAC state generic convergence function MSI MRQ sequence identifier MSK master session key MTK mesh temporal key MU multi-user MU-MIMO multi-user multiple input, multiple output N/A not applicable NAI network access identifier NAS network access server NAV network allocation vector NCC network channel control NDP null data packet NonERP nonextended rate PHY NSS number of spatial streams NTP Network Time Protocol (IETF RFC 1305 [B27]) OBSS overlapping basic service set OCB outside the context of a BSS OCT on-channel tunneling OFDM orthogonal frequency division multiplexing OI organization identifier OSI Open Systems Interconnection (ISO/IEC 7498-1:1994) OUI organizationally unique identifier PAE port access entity (IEEE Std 802.1X-2010) PBAC protected block ack agreement capable PBSS personal basic service set PC point coordinator PCF point coordination function PCP PBSS control point PCPS PBSS control point service PCO phased coexistence operation PDU protocol data unit PER packet error ratio PERR path error PHB per-hop behavior PHY physical layer PHYCS PHY carrier sense PHYED PHY energy detection PICS protocol implementation conformance statement PIFS point (coordination function) interframe space PLME physical layer management entity PLW PSDU length word PMK pairwise master key PMKID pairwise master key identifier PMK-R0 pairwise master key, first level 177 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications PMK-R1 pairwise master key, second level PMKSA pairwise master key security association PN packet number PN pseudonoise (code sequence) PNonce peer nonce PP polling period PP A-MSDU payload protected aggregate MAC service data unit PPDU PHY protocol data unit PREP path reply PREQ path request PRF pseudorandom function PRNG pseudorandom number generator PS power save (mode) PSAP public safety answering point PSDU PHY service data unit PSF PHY Signaling field PSK preshared key PSM power save mode PSMP power save multi-poll PSMP-DTT power save multi-poll downlink transmission time PSMP-UTT power save multi-poll uplink transmission time PTI peer traffic indication PTK pairwise transient key PTKSA pairwise transient key security association PTP TSPEC peer-to-peer traffic specification PWE password element of an ECC group PXU proxy update PXUC proxy update confirmation QAB quieting adjacent BSS QACM QMF access category mapping QAM quadrature amplitude modulation QBPSK quadrature binary phase shift keying QLDRC QoS long drop-eligible retry counter QLRC QoS long retry counter QMF quality-of-service Management frame QoS quality of service QPSK quadrature phase shift keying QSDRC QoS short drop-eligible retry counter QSRC QoS short retry counter R0KH PMK-R0 key holder in the Authenticator R0KH-ID PMK-R0 key holder identifier in the Authenticator R1KH PMK-R1 key holder in the Authenticator R1KH-ID PMK-R1 key holder identifier in the Authenticator RA receiver address or receiving station address RADIUS remote authentication dial-in user service (IETF RFC 2865 [B33]) RANN root announcement 178 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications RAV resource allocation vector RCPI received channel power indicator RD reverse direction RDE RIC Data element RDG reverse direction grant RDS relay DMG STA REDS relay endpoint DMG STA RF radio frequency RFC request for comments RIC resource information container RIFS reduced interframe space RLAN radio local area network RLQP registered location query protocol RLS relay link setup RLSS registered location secure server ROC relay operation type change RPI receive power indicator RRB remote request broker RSC receive sequence counter RSN robust security network RSNA robust security network association RSNE Robust Security Network element RSNI received signal-to-noise indicator RSPI receiver service period initiated RSS responder sector sweep RSSI receive signal strength indicator RTS request to send RTT round trip time RX receive or receiver RXASSI receive antenna selection sounding indication RXASSR receive antenna selection sounding request RXSS receive sector sweep S0KH PMK-R0 key holder in the Supplicant S0KH-ID PMK-R0 key holder identifier in the Supplicant S1KH PMK-R1 key holder in the Supplicant S1KH-ID PMK-R1 key holder identifier in the Supplicant SA source address SAE simultaneous authentication of equals SAP service access point S-AP synchronization access point S-APSD scheduled automatic power save delivery SA Query security association query SBIFS short beamforming interframe space SC single carrier SCA secondary channel above SCB secondary channel below 179 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications SCN no secondary channel SCS stream classification service SCSID stream classification service identifier SDL specification and description language SDU service data unit SEMM SPCA-EDCA mixed mode SFD start frame delimiter SKCK STSL key confirmation key SKEK STSL key encryption key SI service interval SIFS short interframe space SLRC station long retry count SLS sector-level sweep SM spatial multiplexing SME station management entity SMK STSL master key SMKSA STSL master key security association SMT station management SNAP Sub-Network Access Protocol SNonce supplicant nonce SNR signal-to-noise ratio SP service period SPA supplicant address SPCA service period channel access S-PCP synchronization PBSS control point SPP A-MSDU signaling and payload protected aggregate MAC service data unit SPR service period request SPSH spatial sharing SQ signal quality (PN code correlation strength) SRC short retry count SS station service SSID service set identifier SSP subscription service provider SSPN subscription service provider network SSRC station short retry count SSW sector sweep STA station STBC space-time block coding STF Short Training field STK STSL transient key STKSA STSL transient key security association STSL station-to-station link STT selective translation table SU single-user SU-MIMO single-user multiple input, multiple output SYNC synchronization 180 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications TA transmitter address or transmitting station address TAI Temps Atomique International (International Atomic Time) TBTT target beacon transmission time TC traffic category TCLAS traffic classification TDDTI time division data transfer interval TDLS tunneled direct-link setup TFS traffic filtering service TID traffic identifier TIE Timeout Interval element TIM traffic indication map TK temporal key TKIP temporal key integrity protocol TLV type/length/value TMPTT target measurement pilot transmission time TOA time of arrival TOD time of departure TPA transmission time-point adjustment TPC transmit power control TPK TDLS PeerKey TPKSA TDLS PeerKey security association TPU TDLS peer U-APSD TRN-R receive training TRN-T transmit training TRQ training request TS traffic stream TSC TKIP sequence counter TSF timing synchronization function TSID traffic stream identifier TSN transition security network TSPEC traffic specification TTAK TKIP-mixed transmit address and key TTL time to live TTTT target TIM transmission time TU time unit TVHT television very high throughput TVWS television white spaces TX transmit or transmitter TXASSI transmit antenna selection sounding indication TXASSR transmit antenna selection sounding request TXE transmit enable TXOP transmission opportunity TXSS transmit sector sweep U-APSD unscheduled automatic power save delivery UCT unconditional transition UESA unauthenticated emergency service accessible 181 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ULS Universal Licensing System U-NII unlicensed national information infrastructure UP user priority UPSIM unscheduled power save indication map URI Uniform Resource Identifier URL Universal Resource Locator URN Uniform Resource Name UTC Coordinated Universal Time VHT very high throughput VLAN virtual local area network VoIP voice over Internet Protocol (IP) WEP wired equivalent privacy WLAN wireless local area network WM wireless medium WNM wireless network management WSM white space map 3.5 Abbreviations and acronyms in some regulatory domains ISO 3166-1 defines the international two-letter designation for country names, and these designations are included [in square brackets] at the end of each abbreviation that has clear attribution to a regulatory domain. PLMR/CRS private land mobile radio/cellular radio service [US] TVBD television band device [US] WSD white space device [EU] 182 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 4. General description 4.1 General description of the architecture This clause presents the concepts and terminology used within this standard. Specific terms are defined in Clause 3. Illustrations convey key IEEE 802.11 concepts and the interrelationships of the architectural components. IEEE Std 802.11 uses an architecture to describe functional components of an IEEE 802.11 LAN. The architectural descriptions are not intended to represent any specific physical implementation of IEEE Std 802.11. 4.2 How wireless local area networks (WLANs) are different 4.2.1 Introduction Wireless networks have fundamental characteristics that make them significantly different from traditional wired LANs. 4.2.2 Wireless station (STA) In the design of wired LANs it is implicitly assumed that an address is equivalent to a physical location. In wireless networks, this is not always the case. In IEEE Std 802.11, the addressable unit is a station (STA). Physical and operational characteristics are defined by modifiers that are placed in front of the term STA. For example, in the case of location and mobility, the addressable units are the fixed STA, the portable STA, and the mobile STA. The STA is an addressable destination, but not (in general) a fixed location. A STA might take on multiple distinct characteristics, each of which shape its function. For example, a single addressable unit might simultaneously be a portable STA, a quality-of-service (QoS) STA, a dependent STA, and a hidden STA. 4.2.3 Media impact on design and performance The PHYs used in IEEE Std 802.11 are fundamentally different from wired media. Thus IEEE 802.11 PHYs: a) Use a medium that has neither absolute nor readily observable boundaries outside of which STAs with PHY transceivers are known to be unable to receive network frames b) Are unprotected from other signals that are sharing the medium c) Communicate over a medium significantly less reliable than wired PHYs d) Have dynamic topologies e) Lack full connectivity, and therefore the assumption normally made that every STA can hear every other STA is invalid (i.e., STAs might be â€œhiddenâ€ from each other) f) Have time-varying and asymmetric propagation properties g) Might experience interference from logically disjoint IEEE 802.11 networks operating in overlapping areas Because of limitations on wireless PHY ranges, WLANs intended to cover reasonable geographic distances can be built from basic coverage building blocks. When providing QoS services, the MAC endeavors to provide QoS â€œservice guaranteesâ€ within the limitations of the medium properties identified above. In other words, particularly in unlicensed spectrum, true guarantees are often not possible. However, gradations of service are always possible; and in sufficiently controlled environments, QoS guarantees are possible. 183 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 4.2.4 The impact of handling mobile STAs One of the requirements of IEEE Std 802.11 is to handle mobile as well as portable STAs. A portable STA is one that is moved from location to location, but that is used only while at a fixed location. Mobile STAs actually access the LAN while in motion. For technical reasons, it is not sufficient to handle only portable STAs. Propagation effects blur the distinction between portable and mobile STAs; stationary STAs often appear to be mobile due to propagation effects. Mobile STAs typically are battery powered. Hence power management is an important consideration. For example, it cannot be presumed that a STAâ€™s receiver is always powered on. 4.2.5 Interaction with other IEEE 802Â® layers IEEE Std 802.11 is required to appear to higher layers [logical link control (LLC)] as a general-purpose IEEE 802 LAN. This requires that the IEEE 802.11 network handle STA mobility within the MAC sublayer. To meet reliability assumptions (that LLC makes about lower layers), it is necessary for IEEE Std 802.11 to incorporate functionality that is untraditional for MAC sublayers. In a robust security network association (RSNA), IEEE Std 802.11 provides functions to protect Data frames, IEEE Std 802.1X-2010 provides authentication and a Controlled Port, and IEEE Std 802.11 and IEEE Std 802.1X-2010 collaborate to provide key management. All STAs in an RSNA have a corresponding IEEE 802.1Xâ„¢ entity that handles these services. This standard defines how an RSNA utilizes IEEE Std 802.1X-2010 to access these services. Within IEEE Std 802.11, EAPOL PDUs are carried as MSDUs within one or more Data frames, as described in IEEE Std 802.1X-2010, Clause 12. Within this standard, Data frames used for this purpose are generally referred to as EAPOL-Key frames, EAPOL-Key request frames, and EAPOL-Start frames. When used to support applications that have QoS requirements, each IEEE 802.11 LAN provides a link within an end-to-end QoS environment that can be established between, and managed by, higher layer entities. To handle QoS traffic in a manner comparable to other IEEE 802 LANs, the IEEE 802.11 QoS facility requires the IEEE 802.11 MAC sublayers to incorporate functionality that is not traditional for MAC sublayers. In addition, it might be necessary for certain higher layer management entities to be â€œWLAN awareâ€ at least to the extent of understanding that the available bandwidth and other QoS characteristics of a WLAN are subject to frequent, and sometimes substantial, dynamic changes due to causes other than traffic load and are outside the direct control of network management entities. 4.2.6 Interaction with non-IEEE-802 protocols An RSNA utilizes non-IEEE-802 protocols for its authentication and key management (AKM) services. Some of these protocols are defined by other standards organizations, such as the Internet Engineering Task Force (IETF). 4.3 Components of the IEEE 802.11 architecture 4.3.1 General The IEEE 802.11 architecture consists of several components that interact to provide a WLAN that supports STA mobility transparently to upper layers. The basic service set (BSS) is the basic building block of an IEEE 802.11 LAN. Figure 4-1 shows two BSSs, each of which has two STAs that are members of the BSS. 184 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications It is useful to think of each oval depicting a BSS as the coverage area within which the member STAs of the BSS can remain in communication. In the case of transmissions such as in a directional multi-gigabit (DMG) BSS, the individual coverage area of a transmission from one member STA to another can be thought of as a cone and hence is referred to as a directional transmission. The collection of all possible directional transmissions by a member STA defines the coverage area. (The concept of area, while not precise, is often good enough.) This area is called the Basic Service Area (BSA). If a STA moves out of its BSA, it can no longer directly communicate with other STAs present in the BSA. Figure 4-1â€”BSSs 4.3.2 The independent BSS (IBSS) The IBSS is the most basic type of IEEE 802.11 LAN. Since the BSSs shown in Figure 4-1 are simple and lack other components (contrast this with Figure 4-2), the two can be taken to be representative of two IBSSs. This mode of operation is possible when IEEE 802.11 STAs are able to communicate directly. Because this type of IEEE 802.11 LAN is often formed without preplanning, for only as long as the LAN is needed. 4.3.3 The personal BSS (PBSS) Similar to the IBSS, the PBSS is a type of IEEE 802.11 LAN in which STAs communicate directly with each other. In contrast to the IBSS, in the PBSS one STA assumes the role of the PBSS control point (PCP). The PCP provides the basic timing for the PBSS through DMG Beacon and Announce frames as well as allocation of service periods and contention based access periods. A PBSS can be established only by DMG STAs. Not every DMG BSS is a PBSS. A DMG BSS can be a PBSS, an infrastructure BSS, or an IBSS. 4.3.4 STA membership in a BSS is dynamic A STAâ€™s membership in a BSS is dynamic (STAs turn on, turn off, come within range, and go out of range). To become a member of an infrastructure BSS or an IBSS, a STA joins the BSS using the synchronization procedure described in 11.1.4.5. To start a new mesh BSS or to become a member of a mesh BSS, a STA starts the transmission of Beacons and performs the synchronization maintenance procedure described in 14.13. To access all of the services of an infrastructure BSS, a STA becomes â€œassociated.â€ These 185 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications associations are dynamic and involve the use of the distribution system service (DSS), which is described in 4.4.4. A mesh STA does not become associated as there is no central entity in a mesh BSS (MBSS). Instead, a mesh STA peers with other mesh STAs. 4.3.5 Distribution system (DS) concepts 4.3.5.1 Overview PHY limitations determine the direct station-to-station distance that is supported. For some networks this distance is sufficient; for other networks, increased coverage is required. Instead of existing independently, an infrastructure BSS might also form a component of an extended form of network that is built with multiple BSSs. The architectural component used to interconnect infrastructure BSSs is the DS. IEEE Std 802.11 logically separates the WM from the distribution system medium (DSM). Each logical medium is used for different purposes, by a different component of the architecture. The IEEE 802.11 definitions neither preclude, nor demand, that the multiple media be either the same or different. Recognizing that the multiple media are logically different is key to understanding the flexibility of the architecture. The IEEE 802.11 LAN architecture is specified independently of the physical characteristics of any specific implementation. The DS enables mobile device support by providing the logical services necessary to handle address to destination mapping and seamless integration of multiple BSSs. An access point (AP) is any entity that has STA functionality and a distribution system access function (DSAF), which enables access to the DS, via the WM for associated STAs. Figure 4-2 adds the DS, DSM and AP components to the IEEE 802.11 architecture picture. Figure 4-2â€”DSs and APs Data move between a BSS and the DS via the DSAF in an AP. An AP contains a STA and is addressable on the WM using its STA address. The addresses used by an AP for communication on the WM and on the DSM are not necessarily the same. 186 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Data sent to the APâ€™s STA address by one of the STAs associated with it are always received at the uncontrolled port for processing by the IEEE 802.1X port access entity. In addition, if the controlled port is authorized, these frames conceptually transit the DS. 4.3.5.2 Extended service set (ESS): the large coverage network The DS and infrastructure BSSs allow IEEE Std 802.11 to create a wireless network of arbitrary size and complexity. IEEE Std 802.11 refers to this type of network as the ESS. An ESS is the union of the infrastructure BSSs with the same SSID connected by a DS. The ESS does not include the DS. The key concept is that the ESS appears the same to an LLC layer as an IBSS. STAs within an ESS can communicate and mobile STAs might move from one BSS to another (within the same ESS) transparently to LLC. Owing to its distributed nature, a mesh BSS (MBSS) has no central entity like the AP of an infrastructure BSS. Instead, an MBSS forms a single set of independent mesh STAs. This set is indivisible and cannot be further unified. The ESS concept does not apply to the MBSS. However, it is possible to use a Mesh BSS as all or part of the DS that connects an ESS. Nothing is assumed by IEEE Std 802.11 about the relative physical locations of the BSSs in Figure 4-3. Figure 4-3â€”ESS All of the following are possible a) The BSSs partially overlap. This is commonly used to arrange coverage within a physical volume. b) The BSSs could be physically disjoint. Logically there is no limit to the distance between BSSs. c) The BSSs are physically collocated. This could be done to provide redundancy. d) One (or more) IBSSs or ESSs are physically present in the same location as one (or more) ESSs. This could arise for a number of reasons. Some examples are when an IBSS is operating in a location that also has an ESS, when physically overlapping IEEE 802.11 networks have been set up by different organizations, and when two or more different access and security policies are needed in the same location. 187 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 4.3.6 Area concepts For wireless PHYs, well-defined coverage areas simply do not exist. Propagation characteristics are dynamic and unpredictable. Small changes in position or direction might produce dramatic differences in signal strength. Similar effects occur whether a STA is stationary or mobile (as moving objects might impact station-to-station propagation). Figure 4-4 shows a signal strength map for a simple square room with a standard metal desk and an open doorway. This figure is a static snapshot; the propagation patterns change dynamically as STAs and objects in the environment move. The dark (solid) blocks in the lower left are a metal desk and there is a doorway at the top right of the figure. The figure indicates relative differences in field strength with different intensities and indicates the variability of field strength even in a static environment. The difference between the greatest signal strength and the least signal strength in this figure is 50 dB. Figure 4-4â€”A representative signal intensity map While the architecture diagrams show sharp boundaries for BSSs, this is an artifact of the pictorial representation, not a physical reality. Because dynamic three-dimensional field strength pictures are difficult to draw, well-defined shapes are used by IEEE 802.11 architectural diagrams to represent the coverage of a BSS. Further description difficulties arise when attempting to describe collocated coverage areas. Consider Figure 4-5, in which STA 6 could belong to BSS 2 or BSS 3. While the concept of sets of STAs is correct, it is often convenient to talk about areas. For many topics the concept of area is sufficient. Volume is a more precise term than area, though still not technically correct. For historical reasons and convenience, this standard uses the common term area. 188 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Figure 4-5â€”Collocated coverage areas 4.3.7 Integration with non-IEEE-802.11 LANs To integrate the IEEE 802.11 architecture with a non-IEEE-802.11 LAN, including a traditional wired LAN, a final logical architectural component is introducedâ€”a portal. A portal is the logical point at which the integration service is provided. All data from or to non-IEEE- 802.11 LANs enter or leave the IEEE 802.11 architecture via a portal. The integration service is responsible for any addressing changes or other logical mappings that might be required when MSDUs pass between the DS and the integrated LAN. It is possible for one device to offer both the functions of an AP and a portal. For example, a portal to a wired IEEE 802 LAN is shown in Figure 4-6. BSS 1 IEEE Std 802.11 Components STA 1 STA 2 AP DS AP IEEE 802 LAN Portal STA 3 STA 4 BSS 2 Figure 4-6â€”Connecting to other IEEE 802 LANs 189 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 4.3.8 Robust security network association (RSNA) The following features are defined for an RSNA: â€” Enhanced authentication mechanisms for STAs â€” Key management algorithms â€” Cryptographic key establishment â€” Enhanced data cryptographic encapsulation mechanisms, such as counter mode with cipher-block chaining message authentication code protocol (CCMP), Galois/counter mode protocol (GCMP), and, optionally, temporal key integrity protocol (TKIP). â€” Fast basic service set (BSS) transition (FT) mechanism â€” Enhanced cryptographic encapsulation mechanisms for robust Management frames An RSNA might rely on components external to the IEEE 802.11 architecture. The first component is an IEEE 802.1X port access entity (PAE). PAEs are present on all STAs in an RSNA and control the forwarding of data to and from the medium access control (MAC). An AP always implements the Authenticator PAE and Extensible Authentication Protocol (EAP) Authenticator roles, and a non-AP STA always implements the Supplicant PAE and EAP peer roles. In an IBSS or PBSS, each STA implements both the Authenticator PAE and Supplicant PAE roles and both EAP Authenticator and EAP peer roles. A second component is the Authentication Server (AS). The AS authenticates the elements of the RSNA itself, i.e., the STAs provide material that the RSNA elements use to authenticate each other. The AS communicates through the IEEE 802.1X Authenticator with the IEEE 802.1X Supplicant on each STA, enabling the STA to be authenticated to the AS and vice versa. An RSNA depends upon the use of an EAP method that supports mutual authentication of the AS and the STA, such as those that meet the requirements in IETF RFC 4017. In certain applications, the AS might be integrated into the same physical device as the AP, or into a STA in an IBSS or PBSS. In some applications, there is no need for a PAE or AS, and a STA and AP, or two IBSS STAs, or two mesh STAs in an MBSS, might authenticate each other using a password. An RSNA using fast BSS transition relies on an external protocol to distribute keys between the pairwise master key (PMK) R0 key holder (R0KH) and PMK-R1 key holder (R1KH) Authenticator components. The requirements for this protocol are described in 13.2.2. 4.3.9 Centralized coordination service set (CCSS) and extended centralized AP or PCP clustering (ECAPC) AP or PBSS control point (PCP) clustering is a protocol between a DMG synchronization AP or DMG synchronization PCP (S-AP or S-PCP) and other APs and PCPs within the cluster, known as member APs and PCPs. This protocol is used to improve spatial sharing and interference mitigation among the DMG BSSs of the S-AP or S-PCP and member APs and PCPs. AP or PCP clustering allows an AP or PCP within a cluster to schedule transmissions in nonoverlapping time periods with respect to other APs and PCPs that are in the same cluster. There are two types of clustering: â€” In decentralized AP or PCP clustering, there is a single S-AP or S-PCP in the BSA of the S-AP or S-PCP. â€” In centralized AP or PCP clustering, there can be multiple S-APs in the BSA of any one S-AP and all S-APs are coordinated via a single centralized coordination service set (CCSS). 190 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A CCSS comprises a centralized coordination service root (CCSR) and a set of one or more synchronization APs that while operating are stationary with respect to their local environment and are connected to the CCSR via, for instance, one of the following: â€” The DS to an AP (or beyond, to a STA associated to the AP) â€” A combination of distribution service, portal, and external network The CCSR provides coordination services for the CCSS, such as selecting the target beacon transmission time of S-APs within the CCSS to minimize interference. The CCSR might logically reside within an S-AP or in another entity as long as it has a globally administered MAC address. A CCSS is suited to an area and a frequency band having the following propagation characteristics: â€” The BSAs of the S-APs within the CCSS cover the area, and â€” Transmissions within the area are isolated to a high degree. An extended centralized AP or PCP cluster (ECAPC) comprises a single CCSS and an accompanying set of centralized AP or PCP clusters. Each S-AP of one of the centralized AP or PCP clusters is inside the CCSS. The ECAPC also includes all STAs in the BSSs of the S-APs and member APs and PCPs of the centralized AP or PCP clusters. An example is shown in Figure 4-7, in which: â€” STA3a and STA3b are two STAs coordinated by a one MM-SME component. â€” STA4a and STA4b are two STAs coordinated by a second MM-SME component. â€” The CCSR happens to be located in an external network. Centralized External Network Coordination Service Root Portal DS1 S-AP S-AP Centralized STA1 CCSS AP or PCP STA2 BSS1 cluster ECAPC STA5 BSS2 (excluding DS2 DS1, DS2 PCP and AP external STA4b STA4a network) STA3a STA3b BSS4 BSS3 STA8 STA6 STA7 Figure 4-7â€”CCSS and ECAPC 191 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The CCSS might contain whole ESSs, subsets of ESSs, or some combination of them. Decentralized AP or PCP clustering can be employed without establishing a CCSS, CCSR, or ECAPC. 4.3.10 QoS BSS The IEEE 802.11 QoS facility provides MAC enhancements to support LAN applications with QoS requirements. The QoS enhancements are available to QoS STAs associated with a QoS access point or PCP in a QoS BSS. A subset of the QoS enhancements is available for use between STAs that are members of the same QoS IBSS. Similarly, a subset of the QoS enhancements is available for use between neighbor peer mesh STAs. A mesh BSS is one type of QoS BSS and it is described in 4.3.20. A QoS STA that is a non-DMG STA might associate with a non-QoS access point in a non-QoS BSS, to provide the non-QoS MAC data service, for example, when there is no QoS BSS with which to associate. As a mesh STA does not implement the necessary service, the mesh STA does not associate with any access point. A DMG STA is a QoS STA. A DMG BSS is a QoS BSS. The enhancements that distinguish QoS STAs from non-QoS STAs and QoS APs from non-QoS APs are collectively termed the QoS facility. Which of the QoS-specific mechanisms a QoS STA supports might vary among QoS implementations, as well as between QoS STAs and QoS APs, over ranges specified in subsequent clauses. All service primitives, frame formats, coordination function and frame exchange rules, and management interface functions except for the block acknowledgment (block ack) function, direct-link setup (DLS), and automatic power save delivery (APSD) are part of the core QoS facility. A QoS STA or QoS AP implements those core QoS facility necessary for its QoS functions to interoperate with other QoS STAs. Functions such as the block ack, DLS, and APSD are separate from the core QoS facility; and the presence of these functions is indicated by STAs separately from the core QoS facility. For infrastructure BSS and IBSS, this standard provides four mechanisms for the support of applications with QoS requirements. The first mechanism, designated the enhanced distributed channel access (EDCA), delivers traffic based on differentiating user priorities (UPs). This differentiation is achieved by varying the following for different UP values: â€” Amount of time a STA senses the channel to be idle before backoff or transmission, or â€” The length of the contention window to be used for the backoff, or â€” The duration a STA transmits after it acquires the channel. These transmissions might also be subject to certain channel access restrictions in the form of admission control. A DMG STA uses EDCA only within a contention based access period (CBAP). Details of EDCA are provided in 10.22.2 and, for DMG STAs, additional details are provided in 10.36.4, 10.36.5, and 10.36.6.3. The second mechanism, designated the hybrid coordination function (HCF) controlled channel access (HCCA), which is not applicable to DMG STAs, allows for the reservation of transmission opportunities (TXOPs) with the hybrid coordinator (HC). A STA requests the HC for TXOPs, both for its own transmissions as well as for transmissions from the AP to itself.17 The request is initiated by the station 17 In the case of downlink traffic streams (TSs). 192 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications management entity (SME) of the STA. The HC, which is collocated at the AP, either accepts or rejects the request based on an admission control policy. If the request is accepted, the HC schedules TXOPs for both STAs (both the AP and the non-AP STA). For transmissions from the non-AP STA, the HC polls the STA based on the parameters supplied by the STA at the time of its request. For transmissions to the STA, the AP directly obtains TXOPs from the collocated HC and delivers the queued frames to the STA, again based on the parameters supplied by the STA. Details of the mechanism are provided in 10.22.3 and 11.4. This mechanism might be used for applications such as voice and video, which need periodic service from the HC. If the application constraints dictate the use of this mechanism, the application initiates this mechanism by using the management service primitives. The third mechanism, designated the service period (SP) access or service period channel access (SPCA), is applicable only to DMG STAs and allows for the reservation of channel time by the AP or PCP. A non-AP and non-PCP STA requests SPs from an AP or PCP. These SPs can be used for transmission to any other STA in the BSS. The request is initiated by the SME of the non-AP and non-PCP STA. The AP or PCP either accepts or rejects the request based on an admission control policy. If the request is accepted, the AP or PCP uses the Extended Schedule element to schedule SPs for communication between the source and destination DMG STAs indicated within the request. Details of this mechanism are provided in 10.36.6.2, 10.36.6.4, 10.36.6.6, and 11.4. The fourth mechanism, designated as dynamic allocation, is applicable only to DMG STAs and allows for near-real-time reservation of channel time with an AP or PCP. This type of access is used in addition to the service period and contention based access period mechanisms. An AP or PCP can poll a STA and receive requests for channel time allocation. Based on the received requests, the AP or PCP can accept a request and immediately allocate (within the same beacon interval) channel time for the STA to communicate with another STA by using a Grant frame. Details of this mechanism are provided in 10.36.7, 10.36.8, and 10.36.9. The AP of a QoS BSS might allow non-QoS STAs to associate. All individually addressed frames that are sent to non-QoS STAs by an AP do not use the frame formats associated with the QoS facility. A QoS STA associated in a non-QoS BSS acts as a non-QoS STA. 4.3.11 Wireless LAN radio measurements 4.3.11.1 General Wireless LAN (WLAN) radio measurements enable STAs to understand the radio environment in which they exist. WLAN radio measurements enable STAs to observe and gather data on radio link performance and on the radio environment. A STA can choose to make measurements locally, request a measurement from another STA, or be requested by another STA to make one or more measurements and return the results. Radio measurement data is made available to STA management and upper protocol layers where it might be used for a range of applications. The measurements enable adjustment of STA operation to better suit the radio environment. The radio measurement service includes measurements that extend the capability, reliability, and maintainability of WLANs by providing standard measurements across vendors, and the service provides the resulting measurement data to upper layers in the communications stack. In addition to featuring standard measurements and delivering measurement information to upper layers, there are applications that require quantifiable radio environment measurements in order to attain the necessary performance levels. These applications include VoIP, video over IP, location based applications, as well as applications requiring mitigation of harsh radio environments (multifamily dwellings, airplanes, factories, municipalities, etc.). Radio measurements address most of the existing issues in using unlicensed radio spectrum to meet the requirements of these emerging technologies. 193 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications To address the mobility requirements of technologies, such as VoIP and video streaming, radio measurements, such as Channel Load request/report and the Neighbor request/report, can be used to collect transition information, which can drastically speed up handoffs between BSSs within the same ESS. By accessing and using this information, the STAs (either in APs or in non-AP STAs) can make intelligent decisions about the most effective way to utilize the available spectrum, power, and bandwidth for their communications. The request/report measurements are as follows: â€” Beacon â€” Frame â€” Channel Load â€” Noise Histogram â€” STA Statistics â€” LCI (location configuration information) â€” Neighbor Report â€” Link Measurement â€” Transmit Stream/Category Measurement The request-only mechanism is as follows: â€” Measurement Pause The report-only mechanism is as follows: â€” measurement pilot These measurement mechanisms provide the capability for a STA to manage and query its radio environment, and to make appropriate assessments about its health and efficiency. It is the first step in making WLAN smart and capable of making appropriate decisions for fast transition, for mesh connectivity, and for managing the radio environment for all wireless devices. 4.3.11.2 Beacon The Beacon request/report pair enables a STA to request from another STA a list of APs whose beacons it can receive on a specified channel or channels. The Beacon report request/response provides a means for a requesting STA to obtain received beacon, probe response, and measurement pilot information from a responding STA. 4.3.11.3 Measurement pilot The Measurement Pilot frame provides a subset of the information provided in a Beacon frame, is smaller than a Beacon, and is transmitted more often than a Beacon. The purpose of the Measurement Pilot frame is to assist a STA with scanning. 4.3.11.4 Frame The Frame request/report pair returns a picture of all of the channel traffic and a count of all of the frames received at the measuring STA. For each unique Transmitter Address, the STA reports the Transmitter Address, number of frames received from this transmitter, average power level (RCPI) for these frames, and BSSID of the transmitter. 194 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 4.3.11.5 Channel load The Channel Load request/report pair returns the channel utilization measurement as observed by the measuring STA. 4.3.11.6 Noise histogram The Noise Histogram request/report pair returns a power histogram measurement of non-IEEE-802.11 noise power by sampling the channel when virtual carrier sense indicates idle and the STA is neither transmitting nor receiving a frame. 4.3.11.7 STA statistics The STA Statistics request/report pair returns groups of values for STA counters and for BSS Average Access Delay. The STA counter group values include transmitted fragment counts, group addressed transmitted frame counts, failed counts, retry counts, multiple retry counts, frame duplicate counts, Request to Send (RTS) success counts, RTS failure counts, Acknowledgment (Ack) failure counts, received fragment counts, group addressed received frame counts, FCS error counts, and transmitted frame counts. BSS Average Access Delay group values include AP average access delay, average access delay for each access category, associated STA count, and channel utilization. 4.3.11.8 Location The Location request/report pair returns a requested location in terms of latitude, longitude, and altitude. It includes types of altitude such as floors. A requested location can be the location of the requester (e.g., â€œWhere am I?â€) or the location of the reporting STA (e.g., â€œWhere are you?â€) or the location of another STA. 4.3.11.9 Measurement pause The Measurement Pause request is defined, but no report comes back from this request. The measurement pause permits the inclusion of a quantified delay between the execution of individual measurements that are provided in a series within a Measurement Request frame. The measurement pause used as the last measurement in a frame provides control of the measurement period when Measurement Request frames are to be repeated. 4.3.11.10 Neighbor report The neighbor report request is sent to an AP, which returns a neighbor report containing information about known neighbor APs that are candidates for a service set transition. Neighbor reports contain information from dot11RMNeighborReportTable concerning neighbor APs. This request/report pair enables a STA to gain information about the neighbors of the associated AP to be used as potential roaming candidates. 4.3.11.11 Link measurement The link measurement request/report exchange provides measurements of the RF characteristics of a STA- to-STA link. This measurement indicates the instantaneous quality of a link. 4.3.11.12 Transmit stream/category measurement When two QoS STAs have an ongoing traffic stream between them, the Transmit Stream/Category Measurement request/report pair enables either STA to query the other about the conditions of the stream. The transmit stream/category measurement report provides the transmit-side performance metrics for the measured traffic stream. Trigger conditions included in the Transmit Stream/Category Measurement request 195 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications can initiate triggered Transmit Stream/Category Measurement reports upon detection of the trigger condition. 4.3.12 Operation in licensed frequency bands 4.3.12.1 General IEEE 802.11 devices can operate on frequencies that are licensed by national regulatory bodies. Although this standard has been generalized so that it is independent of license type, band, and country of operation, only the bands and associated regulations listed in Annex D have been specifically considered. 4.3.12.2 Dynamic STA enablement (DSE) in licensed bands The DSE operating procedures are used to automate the channel provisioning and regulatory controls needed for unregistered IEEE 802.11 STAs to operate as dependent STAs in licensed spectrum.18 4.3.12.3 Contention based protocol (CBP) in nonexclusively licensed bands The granting of licenses on a nonexclusive, uncoordinated basis in the same area leads to the possibility of overlapping networks. When overlapping networks cause co-channel interference, regulations, such as those governing the 3650 MHz band in the United States, require the use of a CBP â€œby which a transmitter provides reasonable opportunities for other transmitters to operate.â€19 IEEE 802.11 carrier sense multiple access with collision avoidance (CSMA/CA) is suitable for this purpose in most situations. 4.3.12.4 Using DSE STA identification to resolve interference When CSMA/CA is not able to sufficiently sense the presence of another licenseeâ€™s STA (i.e., a hidden STA) or if a secondary licensee causes inference to a primary licensee, the secondary licensee is obliged to resolve complaints that result from interference caused by any STA under its control (including dependent STAs). In order to facilitate the interference resolution processes, all STAs operating in nonexclusively licensed spectrum use the DSE STA and location information procedures. The STA identification and location information procedures are tied because, by default, registered STAs broadcast their actual location as their unique identifier. Dependent STAs broadcast the location of the STA that has enabled them as well as a unique code selected by the licensee. This method puts a victim of the interference in contact with the party responsible for rectifying the problem, and, at the same time, it protects the privacy of the dependent STAâ€™s operator. 4.3.12.5 Further coexistence enhancements in nonexclusively licensed bands While not explicitly required to meet specific rules, a number of optional IEEE 802.11 mechanisms, when used together, are able to meet general requirements for spectrum sharing, incumbent detection, and other cognitive radio functions in licensed bands. The specific mechanisms for each band are detailed in E.2. 4.3.13 High-throughput (HT) STA The IEEE 802.11 HT STA provides PHY and MAC features that can support a throughput of 100 Mb/s and greater, as measured at the MAC data service access point (SAP). An HT STA supports HT features as 18In some licensed frequency bands, wireless equipment can be owned and operated by individuals who do not hold a license. In such instances, devices are permitted to operate only if they are either communicating with, or receiving permission to transmit from, a STA that is maintained by a licensed operator. The Japanese 4.9 GHz band and the U.S. 4.94â€“4.99 GHz public safety band are examples in which IEEE 802.11 STAs operate under such arrangements. 19 Definition of CBP from FCC 05-56, Report and Order and Memorandum Opinion and Order, clause 58. 196 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications identified in Clause 10 and Clause 19. An HT STA operating in the 5 GHz band supports transmission and reception of frames that are compliant with mandatory PHY specifications as defined in Clause 17. An HT STA operating in the 2.4 GHz band supports transmission and reception of frames that are compliant with mandatory PHY specifications as defined in Clause 16 and Clause 18. An HT STA is also a QoS STA. The HT features are available to HT STAs associated with an HT AP. A subset of the HT features is available for use between two HT STAs that are members of the same IBSS. Similarly, a subset of the HT features is available for use between two HT STAs that have established mesh peering (see 9.4.2.56 for details). An HT STA has PHY features consisting of the modulation and coding scheme (MCS) set described in 19.3.5 and physical layer (PHY) protocol data unit (PPDU) formats described in 19.1.4. Some PHY features that distinguish an HT STA from a non-HT STA are referred to as multiple input, multiple output (MIMO) operation; spatial multiplexing (SM); spatial mapping (including transmit beamforming); space-time block coding (STBC); low-density parity check (LDPC) encoding; and antenna selection (ASEL). The allowed PPDU formats are non-HT format, HT-mixed format, and HT-greenfield format (see 19.1.4). The PPDUs can be transmitted with 20 MHz bandwidth and might be transmitted with 40 MHz bandwidth. An HT STA has MAC features that include frame aggregation, some block ack features, power save multi- poll (PSMP) operation, reverse direction (RD), and protection mechanisms supporting coexistence with non-HT STAs. 4.3.14 Very high throughput (VHT) STA The IEEE 802.11 VHT STA operates in frequency bands below 6 GHz excluding the 2.4 GHz band. A VHT STA is an HT STA that, in addition to features supported as an HT STA, supports VHT features identified in Clause 9, Clause 10, Clause 11, Clause 14, Clause 17, and Clause 21. The main PHY features in a VHT STA that are not present in an HT STA are the following: â€” Mandatory support for 40 MHz and 80 MHz channel widths â€” Mandatory support for VHT single-user (SU) PPDUs â€” Optional support for 160 MHz and 80+80 MHz channel widths â€” Optional support for VHT sounding protocol to support beamforming â€” Optional support for VHT multi-user (MU) PPDUs â€” Optional support for VHT-MCSs 8 and 9 The main MAC features in a VHT STA that are not present in an HT STA are the following: â€” Mandatory support for the A-MPDU padding of a VHT PPDU â€” Mandatory support for VHT single MPDU â€” Mandatory support for responding to a bandwidth indication (provided by the RXVECTOR parameters CH_BANDWIDTH_IN_NON_HT and DYN_BANDWIDTH_IN_NON_HT) in a non- HT and non-HT duplicate RTS frame â€” Optional support for MPDUs of up to 11 454 octets â€” Optional support for A-MPDU pre-end-of-frame (pre-EOF) padding (see 9.7.1) of up to 1 048 575 octets â€” Optional support for VHT link adaptation Most VHT features, among other benefits, increase the maximum throughput achievable between two VHT STAs over that achievable using HT features alone. The VHT features are available to VHT STAs associated with a VHT AP. A subset of the VHT features is available for use between two VHT STAs that are members of the same IBSS. Similarly, a subset of the VHT features is available for use between two 197 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications VHT STAs that have established mesh peering. A subset of the VHT features is available for use between two VHT STAs that have established a TDLS link. The support for VHT transmit beamforming sounding and VHT MU PPDUs in a VHT AP and more than one VHT STA within a VHT BSS enables the optional use of downlink MU multiple input, multiple output (DL-MU-MIMO). With DL-MU-MIMO the AP can create up to four A-MPDUs, each carrying MPDUs destined for an associated MU beamformee capable STA. The AP uses group identifiers (GIDs) to signal potential recipient STAs. The AP transmits the A-MPDUs simultaneously in separate space-time streams such that each recipient STA is able to demodulate the space-time streams carrying its A-MPDU. The simultaneous transmission of A-MPDUs in a single VHT MU PPDU provides a means to increase aggregate throughput over that achieved by sending the A-MPDUs in separate SU PPDUs. The use of certain HT features, such as reduced interframe space (RIFS), is not permitted for VHT STAs. 4.3.15 Television very high throughput (TVHT) STA The IEEE 802.11 TVHT STA operates in television white spaces (TVWS) bands. A TVHT STA supports all mandatory features of a VHT STA as mandatory features except for HT-mixed format PPDUs and 20 MHz, 40 MHz, and 80 MHz channel widths. A TVHT STA supports all optional features of a VHT STA as optional features except for HT-greenfield format PPDUs, 160 MHz or 80+80 MHz channel widths, more than 4 spatial streams, and Short GI (which is mandatory). The 20 MHz, 40 MHz, 80 MHz, 160 MHz, or 80+80 MHz channel widths and more than 4 spatial streams are not used in STAs operating as TVHT STAs. The features and behaviors of VHT STAs specified in Clause 6, Clause 8, Clause 9, Clause 10, Clause 11, Clause 14, and Annex G apply to TVHT STAs as well, unless stated otherwise. For Clause 6, Clause 8, Clause 9, Clause 10, Clause 11, and Clause 14, the following replacements are applied for TVHT STAs: â€” â€œTVHT_W/TVHT_2Wâ€ replaces â€œ20/40 MHzâ€. â€” â€œTVHT_W/TVHT_2W/TVHT_4Wâ€ replaces â€œ20/40/80/160 MHzâ€. â€” â€œTVHT_Wâ€, â€œTVHT_2Wâ€, and â€œTVHT_4Wâ€ replace â€œ20 MHzâ€, â€œ40 MHzâ€, and â€œ80 MHz,â€ respectively. â€” â€œTVHT_Wâ€ replaces â€œCBW20â€. â€” â€œTVHT_2Wâ€ replaces â€œCBW40â€. â€” â€œTVHT_4Wâ€ replaces â€œCBW80â€ and â€œCBW80+80â€. â€” â€œsecondaryTVHT_2Wâ€ replaces â€œsecondary40â€. â€” â€œTVHT STAâ€ replaces â€œVHT STAâ€. â€” â€œTVHT APâ€ replaces â€œVHT APâ€. â€” â€œTVHT BSSâ€ replaces â€œVHT BSSâ€. â€” â€œTVHT-MCSâ€ replaces â€œVHT-MCSâ€. â€” â€œTVHT Operationâ€ replaces â€œVHT Operationâ€. â€” â€œdot11TVHTOptionImplementedâ€ replaces â€œdot11VHTOptionImplementedâ€. â€” â€œdot11TVHTControlFieldOptionImplementedâ€ replaces both â€œdot11VHTControlFieldOption- Implementedâ€ and â€œdot11HTControlFieldSupportedâ€. â€” â€œdot11TVHTShortGIOptionIn4WActivatedâ€ replaces â€œdot11VHTShortGIOptionIn80Activatedâ€. â€” â€œdot11TVHTSUBeamformerOptionImplementedâ€ replaces â€œdot11VHTSUBeamformerOption- Implementedâ€. 198 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” â€œdot11TVHTSUBeamformeeOptionImplementedâ€ replaces â€œdot11VHTSUBeamformeeOption- Implementedâ€. â€” â€œdot11TVHTMUBeamformerOptionImplementedâ€ replaces â€œdot11VHTMUBeamformerOption- Implementedâ€. â€” â€œdot11TVHTMUBeamformeeOptionImplementedâ€ replaces â€œdot11VHTMUBeamformeeOption- Implementedâ€. â€” â€œdot11TVHTTXOPPowerSaveOptionImplementedâ€ replaces â€œdot11VHTTXOPPowerSaveOptionImplementedâ€. â€” â€œdot11TVHTOBSSScanCountâ€ replaces â€œdot11VHTOBSSScanCountâ€. â€” â€œdot11TVHTExtendedNSSBWCapableâ€ replaces â€œdot11VHTExtendedNSSBWCapableâ€. â€” Reference to 9.4.1.50 replaces reference to 9.4.1.49. â€” Reference to 9.4.1.52 replaces reference to 9.4.1.51. â€” Reference to 9.4.2.172 replaces reference to 9.4.2.159. â€” Reference to 11.43 replaces reference to 11.40.1 â€” Reference to Clause 22 and its subclauses replace reference to Clause 21 and its subclauses. For Annex G, the following replacements are applied for TVHT STAs: â€” â€œTVHTâ€ replaces â€œVHTâ€. â€” â€œtvhtâ€ replaces â€œvhtâ€. The main PHY features in a TVHT STA that are not present in a VHT STA are the following: â€” Mandatory support for TVHT_W channel width. â€” Optional support for TVHT_W+W channel width. â€” Optional support for TVHT_2W channel width. â€” Optional support for TVHT_4W channel width. â€” Optional support for TVHT_2W+2W channel width. These TVHT features are available to TVHT STAs associated with a TVHT AP. A subset of the TVHT features is available for use between two TVHT STAs that are members of the same IBSS. 4.3.16 STA transmission of Data frames outside the context of a BSS In addition to defining procedures for STA communication within a BSS, this standard also defines procedures for a STA that is not a member of a BSS to transmit Data frames. Such Data frames are defined as being transmitted outside the context of a BSS (OCB). A STA transmits a Data frame outside the context of a BSS only if dot11OCBActivated is true. NOTEâ€”The specific frame subtypes that a STA is allowed to send when it has dot11OCBActivated true are specified in 11.21. When dot11OCBActivated is true, a Data frame can be sent to either an individual or a group destination MAC address. This type of communication is possible only between STAs that are able to communicate directly over the wireless medium. It allows immediate communication, avoiding the latency associated with establishing a BSS. When dot11OCBActivated is true, a STA is not a member of a BSS and it does not utilize the IEEE 802.11 authentication, association, or data confidentiality services. This capability is particularly well suited for use in rapidly varying communication environments such as those involving mobile STAs in which the interval over which the communication exchanges take place is of very short duration (e.g., on the order of tens or hundreds of milliseconds). Since IEEE 802.11 MAC sublayer authentication services are not used when dot11OCBActivated is true, any required authentication services 199 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications are provided by the station management entity (SME) or by applications outside of the MAC sublayer, such as those described in the IEEE 1609 [B21] family of standards. A STA whose MIB does not include dot11OCBActivated operates as if the attribute is false. Communication of Data frames when dot11OCBActivated is true might take place in a frequency band that is dedicated for its use, and such a band might require licensing depending on the regulatory domain (see Annex E). A STA for which dot11OCBActivated is true initially transmits and receives on a channel known in advance, either through regulatory designation or some other out-of-band communication. A STAâ€™s SME determines PHY parameters, as well as any changes in the operating channel, e.g., using information obtained via out-of-band communication or over-the-air frame exchange. When dot11OCBActivated is true, a sending STA sets the BSSID field to the wildcard BSSID value (see 9.2.4.3.4). The Vendor Specific frame (see 9.6.6) provides one means for STAs to exchange management information prior to communicating Data frames outside the context of a BSS. 4.3.17 Tunneled direct-link setup Tunneled direct-link setup (TDLS) is characterized by the use of signaling frames that are encapsulated in Data frames so that the signaling frames are transmitted through an AP transparently. Therefore, unlike with DLS, the AP does not need to be direct-link aware, nor does it have to support the same set of capabilities that are used on the direct link, in order for TDLS to be used. To allow a STA to enter a TDLS power save mode, TDLS provides two power save mechanisms: TDLS peer unscheduled automatic power save delivery (U-APSD) (TPU) and TDLS peer power save mode (PSM). TDLS allows STAs to use the TDLS PeerKey (TPK) handshake to provide data confidentiality and message authentication. STAs that set up a TDLS direct link remain associated with the AP and transmit frames directly to the other TDLS peer STA. 4.3.18 Wireless network management 4.3.18.1 Overview Wireless network management (WNM) enables STAs to exchange information for the purpose of improving the overall performance of the wireless network. STAs use WNM protocols to exchange operational data so that each STA is aware of the network conditions, allowing STAs to be more cognizant of the topology and state of the network. WNM protocols provide a means for STAs to be aware of the presence of collocated interference, and enable STAs to manage RF parameters based on network conditions. In addition to providing information on network conditions, WNM also provides a means to exchange location information, provide support for the multiple BSSID capability on the same wireless infrastructure, support efficient delivery of group addressed frames, and enable a WNM sleep mode in which a STA can sleep for long periods of time without receiving frames from the AP. The WNM service includes the following: â€” BSS max idle period management â€” BSS transition management â€” Channel usage â€” Collocated interference reporting â€” Diagnostic reporting â€” Directed multicast service (DMS) â€” Event reporting â€” Flexible multicast service (FMS) 200 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” Location services â€” Multicast diagnostic reporting â€” Multiple BSSID capability â€” Proxy Address Resolution Protocol (ARP) â€” QoS traffic capability â€” SSID list â€” Triggered STA statistics â€” TIM broadcast â€” Timing measurement â€” Traffic filtering service â€” U-APSD coexistence â€” WNM notification â€” WNM sleep mode 4.3.18.2 BSS max idle period management BSS max idle period management enables an AP to indicate a time period during which the AP does not disassociate a STA due to nonreceipt of frames from the STA. This supports improved STA power saving and AP resource management. 4.3.18.3 BSS transition management BSS transition management enables an AP to request non-AP STAs to transition to a specific AP, or to indicate to a non-AP STA a set of preferred APs, due to network load balancing or BSS Termination. 4.3.18.4 Channel usage Channel usage information is provided by the AP to the non-AP STA to recommend channels for BSSs that are not infrastructure BSSs or an off-channel TDLS direct link. The non-AP STAs can use the channel usage information as part of channel selection processing for a BSS that is not an infrastructure BSS or an off- channel TDLS direct link. 4.3.18.5 Collocated interference reporting Collocated interference reporting enables the requesting STA to obtain information on interference due to collocated radios at the reporting STA. The requesting STA can use that information to schedule its transmissions to minimize the effects of the interference. 4.3.18.6 Diagnostic reporting Diagnostic requests enable a STA to request a non-AP STA to report information that might be helpful in diagnosing and resolving problems with the WLAN network. Diagnostic reports include information on hardware, configuration, and STA capabilities. 4.3.18.7 Directed multicast service (DMS) The DMS enables a non-AP STA to request the AP to transmit group addressed frames destined to the requesting STA as individually addressed frames. 201 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 4.3.18.8 Event reporting Event requests enable a STA to request a non-AP STA to send particular real-time event reports. The types of events include transition, RSNA, WNM log, and peer-to-peer link events. A transition event is transmitted after a non-AP STA successfully completes a BSS transition. Transition events are used to diagnose transition performance problems. An RSNA event report describes the type of Authentication used for the RSNA. RSNA events are used to diagnose security and authentication performance problems. A WNM log event report enables a non-AP STA to transmit a set of WNM log event messages to the requesting STA. WNM log event reports are used to access the contents of a STAâ€™s WNM log. A peer-to- peer link event report enables a non-AP STA to inform the requesting STA that a peer-to-peer link has been established. peer-to-peer link event reports are used to monitor the use of peer-to-peer links in the network. 4.3.18.9 Flexible multicast service (FMS) The flexible multicast service enables a non-AP STA to request an alternate delivery traffic indication map (DTIM) delivery interval for one or more sets of group addressed streams that the non-AP STA receives. This enables the non-AP STA to wake up at the alternate DTIM interval rather than every DTIM and enables significant power saving when a non-AP STA receives group addressed traffic. The FMS also enables a STA to establish a data rate and delivery interval for group addressed traffic higher than the minimum data rate available. Delivery of group addressed data to power saving STAs using a DTIM beacon is described in 11.2.3.4. 4.3.18.10 Location services Location Configuration Request and Response frames enable STAs to configure a collection of location related parameters for Location Track Notification frames. The AP can indicate that it can provide location data to support applications such as emergency services. Location services also provide the ability for STAs to exchange location information using Radio Measurement Request and Radio Measurement Report frames. The protocol supports exchange-by-value and exchange-by-reference mechanisms. The location value can be exchanged in geospatial (LCI) and civic formats. The location reference is a URL that defines from where the location value is retrieved. 4.3.18.11 Multicast Diagnostic report Multicast Diagnostic reports enable a non-AP STA to report statistics for multicast traffic it received from a transmitting STA. This can be used by an AP to measure quality of multicast reception by a non-AP STA. 4.3.18.12 Multiple BSSID capability The Multiple BSSID capability enables the advertisement of information for BSSIDs using a single Beacon or Probe Response frame instead of multiple Beacon and Probe Response frames, each corresponding to a single BSSID. The Multiple BSSID capability also enables the indication of buffered frames for multiple BSSIDs using a single TIM element in a single beacon. 4.3.18.13 Proxy ARP The Proxy ARP capability enables an AP to indicate that the non-AP STA does not receive ARP frames. The Proxy ARP capability enables the non-AP STA to remain in power save for longer periods of time. 4.3.18.14 QoS traffic capability QoS traffic capability procedures enable the QoS STA to indicate that it is capable of transmitting traffic belonging to the corresponding user priority (UP) from applications that require generation of such traffic. 202 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The QoS Traffic Capability might be used for example as an input to estimate the blocking probability of a voice application based on the number of voice capable non-AP STAs. 4.3.18.15 SSID list The SSID List element enables the non-AP STA to request information on a list of SSIDs. This is intended to reduce the number of Probe Request frames sent by the non-AP STA. 4.3.18.16 Triggered STA statistics The Triggered STA Statistics reporting capability enables generation of a STA statistics report (see 4.3.11.9) when the statistics of interest reach a predefined threshold. 4.3.18.17 TIM broadcast The TIM broadcast protocol defines a mechanism to enable a STA to receive an indication of buffered individually addressed traffic, independent of the Beacon frame, reducing the wake time of the STA. 4.3.18.18 Timing measurement Timing Measurement frames allow a recipient STA to accurately measure the offset of its clock relative to a clock in the sending STA. With the regular transfer of Timing Measurement frames from one STA to another, it is possible for the recipient STA to track changes in the offset of its clock with respect to the sending STA over time and thus detect and compensate for any drift between the clocks. 4.3.18.19 Fine timing measurement Fine timing measurement allows a STA to accurately measure the round trip time (RTT) between it and another STA. With the regular transfer of Fine Timing Measurement frames it is possible for the recipient STA to track changes in its relative location with other STAs in the environment. 4.3.18.20 Traffic filtering service The traffic filtering service enables an AP to determine if MSDUs and Management frames destined for a STA match a specific set of traffic filters that are enabled at the AP per the request of the STA. Individually addressed frames that do not match any of the traffic filters in the set are discarded. Individually addressed frames that do match at least one of the set of the enabled traffic filters are delivered to the STA. The STA can also negotiate to have a notification frame sent prior to the delivery of the frame matching the traffic filter. 4.3.18.21 U-APSD coexistence The U-APSD coexistence capability enables the non-AP STA to indicate a requested transmission duration to the AP for use of U-APSD service periods. Use of the transmission duration enables the AP to transmit frames during the service period and improve the likelihood that the non-AP STA receives the frames when the non-AP STA is experiencing interference. The U-APSD coexistence capability reduces the likelihood that the AP transmits frames during the service period that are not received successfully. 4.3.18.22 WNM notification WNM notification provides a mechanism for a STA to notify another STA of a management event. One event is defined: firmware update notification. 203 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 4.3.18.23 WNM sleep mode WNM sleep mode is an extended power save mode for non-AP STAs in which a non-AP STA need not listen for every DTIM Beacon frame, and need not perform GTK/IGTK updates. WNM sleep mode enables a non-AP STA to signal to an AP that it might sleep for a specified length of time. This enables a non-AP STA to reduce power consumption and remain associated while the non-AP STA has no traffic to send to or receive from the AP. 4.3.19 Subscription service provider network (SSPN) interface An AP can interact with external networks using a SSPN interface for the purpose of authenticating users and provisioning services, as shown in Figure 4-8. The exchange of authentication and provisioning information between the SSPN and the AP passes transparently through the portal. The protocol used to exchange this information is outside the scope of this standard. The logical SSPN interface provides the means for an AP to consult an SSPN for authenticating and authorizing a specific non-AP STA and to report statistics and status information to the SSPN. Authentication and provisioning information for non-AP STAs received from the SSPN are stored in the AP management information base (MIB) and are used to limit layer-2 services provided to that non-AP STA. Detailed interactions describing the SSPN interface are provided in 11.25.5. BSS1 802.11 MAC/PHY ESS STA1 STA2 AP DS Portal SSPN AP Interface 802.x LAN STA3 STA4 AAA & Data 802.11 MAC/PHY Connection BSS2 SSPN = DN Figure 4-8â€”SSPN interface service architecture The SSPN interface provides the non-AP STA access to the services provisioned in the SSPN via the currently associated BSS. Services might include virtual local area network (VLAN) mapping and tunnel establishment that are transparent to the non-AP STA and outside the scope of this standard. The SSPN interface also allows the non-AP STA to access services in destination networks (DNs) other than the SSPN. An example of a DN other than SSPN is the provision of Internet access via the IEEE 802 LAN, or an intermediary network that connects the IEEE 802.11 infrastructure and the SSPN. NOTEâ€”The SSPN Interface Service is not supported in an IBSS. 204 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 4.3.20 Mesh BSS 4.3.20.1 General The IEEE 802.11 mesh facility provides MAC enhancements to support wireless LAN mesh topologies. The mesh facilities are available to mesh STAs that belong to a mesh BSS (MBSS). Only the mesh discovery service is available to a mesh STA that has not become a member of an MBSS. The enhancements that distinguish mesh STAs from nonmesh STAs are collectively termed the â€œmesh facility.â€ The mesh-specific mechanisms vary among implementations. 4.3.20.2 Overview of the mesh BSS A mesh BSS is an IEEE 802.11 LAN consisting of autonomous STAs. Inside the mesh BSS, all STAs establish wireless links with neighbor STAs to mutually exchange MSDUs. Further, using the multi-hop capability, MSDUs and Management frames can be transferred between STAs that are not in direct communication with each other over a single instance of the wireless medium. From the data delivery point of view, it appears as if all STAs in a mesh BSS are directly connected at the MAC layer even if the STAs are not within range of each other. The multi-hop capability enhances the range of the STAs and benefits wireless LAN deployments. STAs in a mesh BSS might be sources, sinks, or propagators of traffic; some mesh STAs might propagate traffic for other STAs, but do not act as a source or sink of traffic. As described in 4.3.20.4, a mesh BSS might have interfaces to external networks and can be a DSM for infrastructure BSSs. Within a mesh BSS, STAs utilize the mesh coordination function (MCF) to access the channel. MCF is based on the core QoS facility described in 4.3.10, and a mesh BSS is categorized as one type of QoS BSS. MCF is specified in 10.23. 4.3.20.3 Mesh STA A STA that belongs to a mesh BSS is termed a â€œmesh stationâ€ (mesh STA). Mesh STAs are QoS STAs that support mesh services, i.e., they participate in formation and operation of a mesh basic service set (MBSS). A mesh STA implements a subset of the QoS functionality: â€” Use of QoS frame format â€” EDCA (as a part of MCF) â€” Block acknowledgment (optional) â€” No acknowledgment (optional) â€” Use of TSPEC, TCLAS, and TCLAS Processing elements to establish DMS or GCR agreements (optional) A mesh BSS does not incorporate the full hybrid coordinator (HC) and BSS QoS functionality. MBSSs do not incorporate the following: â€” HCCA â€” Traffic stream (TS) management â€” Admission control â€” Automatic power save delivery (APSD) â€” Direct-link setup (DLS) â€” Tunneled direct-link setup (TDLS) 205 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 4.3.20.4 IEEE 802.11 components and mesh BSS Example mesh and infrastructure BSSs are illustrated in Figure 4-9. Only mesh STAs participate in mesh functionalities such as formation of the mesh BSS, path selection, and forwarding. Accordingly, a mesh STA is not a member of an IBSS or an infrastructure BSS. Consequently, mesh STAs do not communicate with nonmesh STAs. infrastructure BSS 18 STA 19 STA 20 STA 18 DS Mesh AP AP infrastructure Gate BSS 13 STA 13 Mesh STA 9 STA 14 STA 15 Mesh STA 11 Mesh Portal infrastructure STA 10 Non-802.11 BSS 17 LAN STA 21 Mesh STA 22 STA 12 STA 33 infrastructure STA 17 STA 8 BSS 25 Mesh mesh STA 26 AP BSS 2 STA 27 Portal Mesh Gate STA 25 AP DS collocated DS with DS Mesh Mesh Gate Mesh Gate Gate Mesh Mesh Mesh STA 1 STA 5 STA 2 Mesh STA 16 Mesh Mesh Mesh Mesh STA 3 STA 6 mesh STA 4 STA 7 BSS 1 Figure 4-9â€”Example MBSS containing mesh STAs, mesh gates, APs, and portals However, instead of existing independently, an MBSS might also access the distribution system (DS). The MBSS interconnects with other BSSs through the DS. Then, mesh STAs can communicate with nonmesh STAs. Therefore, a logical architectural component is introduced in order to integrate the MBSS with the DSâ€”the mesh gate. Data move between an MBSS and the DS via one or more mesh gates. Thus, the mesh gate is the logical point at which MSDUs from an MBSS enter the IEEE 802.11 DS, via the DSAF. Once an 206 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MBSS contains a mesh gate that connects it to the IEEE 802.11 DS, the MBSS can be integrated with other infrastructure BSSs too, given that their APs connect to the same DS. Several mesh gates are shown in Figure 4-9 connecting different MBSSs to the DS. When an MBSS accesses the IEEE 802.11 DS through its mesh gate, the MBSS can be integrated with a non-IEEE-802.11 LAN. To integrate the IEEE 802.11 DS to which this MBSS connects, the DS needs to contain a portal. See 4.3.7. Consequently, mesh gate and portal are different entities. The portal integrates the IEEE 802.11 architecture with a non-IEEE-802.11 LAN (e.g., a traditional wired LAN), whereas the mesh gate integrates the MBSS with the IEEE 802.11 DS. It is possible for one device to offer any combination of the functions of an AP, a portal, and a mesh gate; see 14.11.5. An example device combining the functions of an AP and a mesh gate is shown in Figure 4-10. The implementation of such collocated entities is beyond the scope of this standard. The configuration of a mesh gate that is collocated with an access point allows the utilization of the mesh BSS as a distribution system medium. In this case, two different entities (mesh STA and access point) exist in the collocated device and the mesh BSS is hidden to STAs that associate to the access point. The mesh STA collocation is outlined in 14.11.5, which states that the usage of a distinct MAC address for each collocated STA avoids ambiguities. infrastructure BSS 25 STA 26 STA 27 STA 25 AP DS Mesh Gate Mesh STA 5 Mesh STA 2 Mesh STA 4 Mesh Mesh STA 6 STA 7 mesh BSS 1 Figure 4-10â€”Example device consisting of mesh STA and AP STA to connect an MBSS and an infrastructure BSS 4.3.20.5 Introduction to mesh functions 4.3.20.5.1 General A mesh BSS is formed and operated by the set of services called mesh services. Mesh services are provided by the following major mesh facilities: â€” Mesh discovery â€” Mesh peering management 207 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” Mesh security â€” Mesh beaconing and synchronization â€” Mesh coordination function â€” Mesh power management â€” Mesh channel switching â€” Three address, four address, and extended address frame formats â€” Mesh path selection and forwarding â€” Interworking with external networks â€” Intra-mesh congestion control â€” Emergency service support in mesh BSS 4.3.20.5.2 Mesh discovery A mesh STA performs either active scanning or passive scanning to discover an operating mesh BSS. Each mesh STA transmits Beacon frames periodically and responds with Probe Response frames when a Probe Request frame is received, so that neighbor mesh STAs can perform mesh discovery appropriately. The identification of the mesh BSS is given by the Mesh ID element contained in the Beacon and the Probe Response frames. The details for the mesh discovery facility are described in 14.2. 4.3.20.5.3 Mesh peering management (MPM) Within a mesh BSS, direct communication between neighbor mesh STAs is allowed only when they are peer mesh STAs. After mesh discovery, two neighbor mesh STAs agree to establish a mesh peering to each other, and, after successfully establishing the mesh peering, they become peer mesh STAs. A mesh STA can establish a mesh peering with multiple neighbor mesh STAs. The mesh peering management (MPM) facilitates the mesh peering establishment and closure of the mesh peerings. The details of MPM are described in 14.3. 4.3.20.5.4 Mesh security In an MBSS, mesh link security protocols are used to authenticate a pair of mesh STAs and to establish session keys between them. Mesh authentication protocols establish a shared, common pairwise master key (PMK), and authenticate a peer mesh STA. The authenticated mesh peering exchange protocol relies on the existence of the PMK between the two mesh STAs to establish an authenticated peering and derive session keys. The details of mesh security are described in 12.4, 14.3.3, 14.5, and 14.6. 4.3.20.5.5 Mesh beaconing and synchronization In order to assist mesh discovery, mesh power management, and synchronization in a mesh BSS, all mesh STAs periodically transmit Beacon frames. Synchronization in a mesh BSS is maintained by the MBSSâ€™s active synchronization method. The default synchronization method is the neighbor offset synchronization method. Mesh beacon collision avoidance (MBCA) mitigates collisions of Beacon frames among hidden nodes. The details of mesh beaconing and synchronization are described in 14.13. 4.3.20.5.6 Mesh coordination function (MCF) A mesh STA uses the mesh coordination function (MCF) for channel access. MCF consists of EDCA (contention based channel access defined in 10.23.2) and MCCA (controlled channel access defined in 10.23.3). MCCA is a reservation based channel access method and aims to optimize the efficiency of frame exchanges in a mesh BSS. 208 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 4.3.20.5.7 Mesh power management A mesh STA can manage the activity level of its links per mesh peering. A mesh STA sets the activity level of each of its mesh peerings to either active mode, light sleep mode, or deep sleep mode. The mesh STA performs mesh power management mode tracking for each of its neighbor peer mesh STAs, and delivers the frames based on the rules defined in 14.14. 4.3.20.5.8 Mesh channel switching When a mesh STA switches the operating channel, it uses the channel switching protocol defined in 11.9.8 and 11.10. The channel switching protocol enables the propagation of channel switch notifications throughout the mesh BSS, prior to the channel switch execution. 4.3.20.5.9 Frame addressing in an MBSS Three address, four address, and extended address frame formats enable the distribution of MSDUs over multiple instances of the wireless medium within a mesh BSS and integration to the ESS. Frame format details are described in Clause 9 and 9.3.5. 4.3.20.5.10 Mesh path selection and forwarding Mesh path selection enables path discovery over multiple instances of the wireless medium within a mesh BSS. The overview of the mesh path selection framework is described in 14.8. The hybrid wireless mesh protocol (HWMP) is defined as the default path selection protocol for the mesh BSS. HWMP provides both proactive path selection and reactive path selection. The details of HWMP are described in 14.10. The path selection protocol uses link metrics in the assessment of a mesh path to the destination. The airtime link metric is the default link metric. It is defined in 14.9. Once the mesh path of a particular pair of the source mesh STA and the destination mesh STA is found through the mesh path selection function, mesh STAs propagate the data by the forwarding function. The details of the forwarding function are described in 10.35. As a result of the mesh path selection and forwarding, MSDUs are transmitted among all of the mesh STAs in a mesh BSS, even if the mesh STAs are not neighbor STAs of each other. Figure 4-11 depicts the MSDU transfer within a mesh BSS. 4.3.20.5.11 Interworking with the DS A mesh BSS might contain one or more mesh gates that connect to one or more distribution systems. A mesh gate can announce its presence in the mesh BSS by sending Gate Announcement frames. Alternatively a mesh gate can announce its presence in the mesh BSS by sending HWMP Path Selection frames with the RANN element or the PREQ element indicating mesh gate announcement, when it is configured as a root mesh STA. Typically a mesh gate announces its presence when it is collocated with a portal or it has access to a portal. Gate announcements allow mesh STAs to select the appropriate mesh gate and build a path toward it. Note that, when multiple mesh gates that have access to the same DS are present in the mesh BSS, proper configuration is necessary. When a mesh gate has access to IEEE 802 STAs outside the mesh BSS, the mesh gate acts as a proxy for the IEEE 802 STAs outside the MBSS. Such a mesh gate is called a proxy mesh gate. The details of the proxy functionality are described in 14.11.3. The details of the mesh BSS interworking are described in 14.11. 209 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MSDU source MSDU MSDU destination MAC SAP Mesh Mesh STA 4 STA 6 Mesh Mesh STA 1 STA 7 Mesh STA 5 Mesh Mesh STA 2 Mesh STA 8 STA 3 Mesh mesh BSS Mesh STA 10 (MBSS) STA 9 Mesh STA 11 Figure 4-11â€”MAC data transport over an MBSS 4.3.20.5.12 Intra-mesh congestion control Intra-mesh congestion control is used to provide flow control over the multi-hop communication. Intra-mesh congestion control is useful to mitigate wasteful wireless medium utilization caused by buffer overflow at mesh STAs. Intra-mesh congestion control consists of three main mechanisms: local congestion monitoring and congestion detection, congestion control signaling, and local rate control. The details of the intra-mesh congestion control are described in 14.12. 4.3.20.5.13 Emergency service support in mesh BSS Depending on regulations, emergency services support might be mandated over the mesh network. In this case the Beacon and Probe Response frames inform whether a mesh STA supports emergency services, advertising to other mesh STAs that mesh peering for emergency services is possible. If a mesh STA subsequently requires emergency services, an emergency indication is then set within the Mesh Peering Open frame. Mesh STAs that support emergency services, accept peering from other mesh STAs requiring emergency services, transferring frames to an emergency server (such as a PSAP). 4.3.21 DMG STA The IEEE 802.11 DMG STA provides PHY and MAC features that can support a throughput of 1 Gb/s and greater, as measured at the MAC data service access point (SAP). A DMG STA supports DMG features as identified in Clause 10, Clause 11, and Clause 20. A DMG STA operates in a DMG BSS and supports transmission and reception of frames that are compliant with PHY specifications as defined in Clause 20. A DMG STA is also a QoS STA. The basic channel access of a DMG STA (see 10.36) allows it to operate in an Infrastructure BSS, in an IBSS, and in a PBSS. Certain DMG features such as service period allocation are available only to DMG STAs that are associated with an AP or with a PCP, while other DMG features such as EDCA operation in a PBSS do not require association. A DMG STA supports beamforming (BF) as described in 10.38 and 20.10 and GCM encryption as described in 12.5.5. A DMG STA supports the PHY signaling as described in 20.4, 20.5, 20.6, and 20.7. At a minimum, a DMG STA supports the mandatory modulation and coding scheme (MCS) and PHY protocol data unit (PPDU) formats described in 20.4 and 20.6. A DMG STA has PHY features that include a low-density parity check 210 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications (LDPC) encoding, a preamble making use of Golay sequences, and beamforming. The PPDUs are always transmitted with the same channel spacing as described in Annex E. A DMG STA supports MAC features that provide channel access in an environment in which transmissions use a directional antenna pattern. A DMG STA has MAC features that include frame aggregation, block ack features, service periods, contention based access periods, DMG protected period, AP or PCP clustering, dynamic channel time management, reverse direction, spatial sharing, beamforming, and operation (fast session transfer) in a multi-band device. A DMG STA is not a mesh STA. A DMG STA does not use any of the following: HCCA, power save multi-poll (PSMP), DLS, TDLS, HT-delayed block ack, GCR. 4.3.22 DMG relay The IEEE 802.11 DMG relay function allows a source relay endpoint DMG STA (REDS) to transmit frames to a destination REDS with the assistance of another DMG STA, the relay DMG STA (RDS), as shown in Figure 4-12. Relaying can improve the reliability of communication in a DMG BSS in the case the direct link between the source REDS and the destination REDS has poor quality or is disrupted. Following the DMG relay setup procedures, a source REDS can discover and select an appropriate RDS to act as the relay for a particular destination REDS, prior to Data frame transmission using the relay. A relay operating as a link switching type of relay uses the RDS to forward frames between the source and destination REDS if the direct link between the REDS is disrupted. In a link cooperation of relay operation, the RDS simultaneously repeats the transmission of frames between the source and destination REDS, which can possibly increase the signal quality received at the destination REDS. STA 2 (RDS) Relay links STA 5 (REDS) STA 1 (REDS) STA 4 STA 3 Figure 4-12â€”DMG relay in a DMG BSS 4.3.23 Robust audio video (AV) streaming Robust AV streaming improves AV streaming performance when using IEEE Std 802.11 for consumer and enterprise applications. 4.3.23.1 Groupcast with retries (GCR) The GCR service allows a STA to request greater reliability for one or more group addressed streams that the STA receives. Greater reliability is provided via unsolicited retries or the block ack mechanism. A non- AP STA can request delivery so that the AP transmits the frames via EDCA within GCR service periods when all associated non-AP STAs are in active mode or the awake state of the PS mode. 211 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 4.3.23.2 Stream classification service (SCS) SCS enables the establishment of a classification using layer 2 and/or layer 3 signaling to match incoming unicast MSDUs. Once classified, unicast MSDUs matching the classification are assigned to an access category and are tagged with their drop eligibility. When intra-access category prioritization is enabled (see 4.3.23.5), SCS allows MSDUs matching the classification to be assigned to the primary or alternate transmit queues so that finer grained prioritization can be applied. 4.3.23.3 Overlapping BSS (OBSS) management The objective of OBSS management is to facilitate cooperative sharing of the medium between APs that operate in the same channel and that are able to receive or obtain frames from each other, including Beacon frames. These frames might be received directly or via associated STAs that support the Beacon request capability (see 11.11.10). OBSS management provides the means to â€” Provide additional information for channel selection â€” Extend the admission control mechanism to a distributed environment â€” Enable the coordination of scheduled TXOPs between OBSSs OBSS management enables stationary and portable APs to provide to neighboring APs information for the selection of a channel and for the cooperative sharing of that channel. The main component of OBSS management is the QLoad report that provides information on â€” The reporting APâ€™s overlap situation â€” The reporting APâ€™s QoS traffic load â€” The total QoS traffic load of BSSs directly overlapping the reporting APâ€™s BSS This information might be used to aid an AP when searching for a channel and also when sharing a channel in an overlap situation. To coordinate the TXOPs of overlapping HCCA APs, OBSS management provides a means for an AP to advertise its TXOP allocations so another AP might schedule its own TXOPs to avoid those already scheduled. 4.3.23.4 Interworking with IEEE 802.1Qâ„¢ Stream Reservation Protocol (SRP) Support for SRP from IEEE Std 802.1Q enables integration of the TSPEC ADDTS request/response protocol with IEEE 802.1Q SRP to enable end-to-end SRP reservations when one or more IEEE 802.11 links are part of a path from IEEE 802.1Q Talker to IEEE 802.1Q Listener. 4.3.23.5 Intra-access category prioritization Intra-access category prioritization provides six transmit queues that map to four enhanced distributed channel access functions (EDCAFs) to enable differentiation between traffic streams that are in the same access category in order for finer grained prioritization to be applied between individual AV streams or voice streams. 212 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 4.3.24 Operation under geolocation database (GDB) control Regulators designate television broadcast bands for the deployment of dynamic sharing technologies. Different schemes result in different times that elapse from the moment an authorized database is told to change access to a particular slice of spectrum and the time that sharing radios are required to change their operations. One current system design allows the GDBs to utilize a fully populated map of all protected services, and the databases have precalculated maps that are effective on timescales of one to two days. Another system design allows the protected services to negotiate with controllers of unlicensed devices so that both can share available broadcast channels and facilitate response times of less than an hour where necessary and even within minutes if desired. Another system design has the GDB fully control all white space devices by requiring them to tell the database their intended location and emissions footprint and receive permission before any broadcast band transmission starts. Any change of intended frequencies or powers is told to the database, and permission is received before the change takes place. The architectural role of components depends on the security and timeliness requirements in particular regulatory domains. Figure 4-13 shows two infrastructure BSSs in which APs are geolocation database dependent (GDD) enabling STAs and the other STAs are GDD dependent STAs. AP1 STA1 GDD enabling STA GDD dependent STA GDB1 Registered Location Secure STA2 Server GDD dependent STA RLSS AP2 STA3 GDD dependent STA GDD enabling STA GDB2 Outside scope of IEEE Std 802.11 Scope of IEEE Std 802.11 Figure 4-13â€”Multiple APs and multiple GDBs In most regulatory domains, GDD enabling STAs are required to â€” Securely communicate with GDBs â€” Maintain the white space maps (WSMs) and other information received from GDBs â€” Create and transmit a contact verification signal to inform GDD dependent STAs that the map they received is still valid 213 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A registered location query protocol (RLQP) is provided to share the WSMs and current channel use among GDD enabling STAs in a neighborhood. GDD dependent STAs can query both their GDD enabling STA and the registered location secure server (RLSS) about WSMs and channel utilization. In some regulatory domains, a RLSS can provide GDBs with the current channel use information for all of the BSSs and IBSSs that communicate with it. In some regulatory domains, the RLSS communicates with controllers of other white space systems to coordinate emissions footprints of their services. By accessing and using this information, the STAs can make intelligent decisions about the most effective way to utilize the available spectrum, power, and bandwidth for their communications. The specific mechanisms are as follows: â€” Channel availability query, used to obtain one or more WSMs of available channels for an area or a geolocation â€” Channel schedule management, used to obtain start and ending times for each available white space channel â€” Contact verification signal, used by a GDD dependent STA to verify it is still receiving frames from its GDD enabling STA â€” GDD enablement, the procedure where a GDD enabling STA forms a network and maintains the network under the control of a GDB â€” Network channel control, used to inform a local channel controller that has a view of nearby transmitters and their emissions footprints â€” WSM, used to retrieve the available white space channels and their transmit power restrictions The use of the mechanisms in a particular regulatory domain depends on the specific regulatory requirements. Table 4-1 gives a view of the use of specific mechanisms to meet regulatory requirements in terms of daily, hourly, and minute timescales. Implementers are referred to the regulatory sources in Table D.1 for further information. Operation in countries within defined regional regulatory domains might be subject to additional or alternative national regulations. Table 4-1â€”GDD mechanisms and timescales Daily consultation Hourly consultation Mechanism Minute responsiveness required required Channel availability query Informative Informative Not applicable Channel schedule Informative Informative Not applicable management Contact verification signal Required to be secure Might be secure Loss of consecutive signals requires action GDD enablement Required Required Required Network channel control Informative Informative Not applicable WSM Required for GDD Required for GDD Required for GDD enabling STA, might be enabling STA, might be enabling STA, might be translated for GDD translated for GDD translated for GDD dependent STA dependent STA dependent STA These mechanisms allow a BSS to manage and query its radio environment and a GDB to control the radio environment for all wireless services. 214 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 4.4 Logical service interfaces 4.4.1 General IEEE Std 802.11 explicitly does not specify the details of implementations. Instead, IEEE Std 802.11 specifies services to aid understanding how the architectural components are logically organized. The services are associated with different components of the architecture. There are three categories of IEEE 802.11 serviceâ€”the station service (SS), the PCP service (PCPS), and the distribution system service (DSS). These categories of service are used by the IEEE 802.11 MAC sublayer. The complete set of IEEE 802.11 architectural services are as follows: a) Authentication b) Association c) Deauthentication d) Disassociation e) Distribution f) Integration g) Data confidentiality h) Reassociation i) MSDU delivery j) DFS k) TPC l) Higher layer timer synchronization (QoS facility only) m) QoS traffic scheduling (QoS facility only) n) Radio measurement o) DSE This set of services is divided into three groups: the SS, the PCPS, and the DSS. The SS is part of every STA. The PCPS is provided by the PCP of a PBSS. The DSS is provided by the DS. 4.4.2 SS The service provided by STAs is known as the SS. The SS is present in every IEEE 802.11 STA (including APs, as APs include STA functionality). The SS is specified for use by MAC sublayer entities. All STAs provide the SS. The SS is as follows: a) Authentication (not used when dot11OCBActivated is true) b) Deauthentication (not used when dot11OCBActivated is true) c) Data confidentiality (not used when dot11OCBActivated is true) d) MSDU delivery e) DFS f) TPC g) Higher layer timer synchronization (QoS facility only) h) QoS traffic scheduling (QoS facility only) 215 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications i) Radio measurement j) DSE 4.4.3 PBSS control point service (PCPS) The service provided by the PCP of a PBSS is known as the PCPS. Since each STA within a PBSS can operate as a PCP, each STA in the PBSS is capable of providing the PCPS, if it becomes the PCP of the PBSS. Non-PCP STAs do not provide the PCPS. The services that comprise the PCPSs are the following: a) Association b) Disassociation c) Reassociation d) QoS traffic scheduling The PCPS is specified for use by MAC sublayer entities. 4.4.4 DSS The service provided by the DS is known as the DSS. IEEE Std 802.11 explicitly does not specify the details of DS implementation structure. Instead, IEEE Std 802.11 specifies the services that are provided by a DS implementation. A DS can be created from many different technologies including current IEEE 802 wired LANs. IEEE Std 802.11 does not constrain the DS to be either data link or network layer based. Nor does IEEE Std 802.11 constrain a DS to be either centralized or distributed in nature. This service is represented in the IEEE 802.11 architecture by arrows within APs and mesh gates, indicating that the service is used to cross media and possibly address space logical boundaries. An AP and a mesh gate are logical entities, and the functions described might be shared by one or more physical entities. The services that comprise the DSS are as follows: a) Association (not mesh facility) b) Disassociation (not mesh facility) c) Distribution d) Integration e) Reassociation (not mesh facility) f) QoS traffic scheduling (QoS facility only) g) DSE h) Interworking with the DS (mesh facility only) DSSs are specified for use by MAC sublayer entities. Figure 4-14 combines the components from previous figures with the three types of services to show the IEEE 802.11 architecture for infrastructure BSS and PBSS. 216 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications IEEE Std 802.11 Components BSS 1 802.11 MAC/PHY STA 1 SS STA 2 BSS 3 AP ESS STA 6 DSS Y H P / DS SS C A M 1 1 . 2 0 8 DSS DSS AP STA 5 Portal PCP STA 3 SS PCPS STA 4 802.11 MAC/PHY BSS 2 802.x LAN Figure 4-14â€”IEEE 802.11 architecture for infrastructure BSS and PBSS 4.5 Overview of the services 4.5.1 General There are many services specified by IEEE Std 802.11. Six of the services are used to support medium access control (MAC) service data unit (MSDU) delivery between STAs. Three of the services are used to control IEEE 802.11 LAN access and confidentiality. Two of the services are used to provide spectrum management. One of the services provides support for LAN applications with QoS requirements. Another of the services provides support for higher layer timer synchronization. One of the services is used for radio measurement. This subclause presents the services, an overview of how each service is used, and a description of how each service relates to other services and the IEEE 802.11 architecture. The services are presented in an order designed to help build an understanding of the operation of an IEEE 802.11 network. As a result, the services that comprise the SS and DSS are intermixed in order (rather than being grouped by category). The services that comprise the PCPS are a subset of the services provided by the SS and DSS. Each of the services is supported by one or more MAC frame types. Some of the services are supported by MAC management PDUs, which are transported in MAC Management frames. The MSDU delivery service is supported by MAC Data frames. All of these frames gain access to the WM via the IEEE 802.11 MAC sublayer medium access method specified in Clause 10. The IEEE 802.11 MAC sublayer uses four types of frameâ€”Data, Management, Extension, and Control (see Clause 9). Data frames are handled by the MAC data plane (see Figure 5-1). 217 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MAC Management frames and MAC Extension frames (see 9.3.4) are handled via the MAC management plane. MAC Control frames are used to support the delivery of IEEE 802.11 Data, Management, and Extension frames. The examples here assume an ESS environment. The differences among the ESS, the PBSS, and the IBSS environments are discussed separately in 4.7. 4.5.2 Distribution of MSDUs within a DS 4.5.2.1 Distribution This is the primary service used by IEEE 802.11 STAs. It is conceptually invoked by every data message to or from an IEEE 802.11 STA operating in an ESS (when the frame is sent via the DS). Distribution is via the DSS. Refer to the ESS in Figure 4-15 and consider an MSDU being sent from STA 1 to STA 4. One or more frames containing the MSDU are sent from STA 1 and received by STA 2 (the â€œinputâ€ AP). The AP gives a MAC service tuple containing the MSDU to the DSS. It is the job of the distribution service to deliver the MAC service tuple within the DS in such a way that it arrives at the appropriate DS destination for the intended recipient. In this example, the MAC service tuple is distributed to STA 3 (the â€œoutputâ€ AP) and STA 3 accesses the WM to send one or more frames containing the MSDU to STA 4 (the intended destination). Integration Distribution System Portal Nonâ€802.11 network 802.1X Port 802.1X Port Filtering (Optional) Filtering (Optional) Data Link MAC Sublayer Layer MAC Sublayer STA2 STA3 Physical PHY PHY Layer APs Nonâ€AP STA STA4 Nonâ€AP STA1 STA Nonâ€AP STA Figure 4-15â€”IEEE 802.11 Infrastructure model 218 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The previous example was a case in which the AP that invoked the distribution service was different from the AP that received the distributed MAC service tuple. If the MSDU had been intended for a STA that was a member of the same BSS as the sending STA, then the â€œinputâ€ and â€œoutputâ€ APs for the MAC service tuple would have been the same. If a MAC service tuple with a group addressed destination is provided to the DS, the DS is responsible for delivering that MAC service tuple to all appropriate APs in the ESS, including the â€œinputâ€ AP, to allow the AP to send frame(s) containing the MSDU to other associated non-AP STAs in its BSS. Generally, the DS will deliver the MAC service tuple to all the APs in the ESS. Optionally, an implementation-specific or higher layer filtering may be applied to restrict the delivery to a known subset of the APs in the ESS; such filtering is beyond the scope of this standard. How the MAC service tuple is distributed within the DS is not specified by IEEE Std 802.11. All IEEE Std 802.11 is required to do is to provide the DS with enough information for the DS to be able to determine the â€œoutputâ€ point that corresponds to the intended recipient. The necessary information is provided to the DS by the three association related services (association, reassociation, and disassociation). In all the examples above, the distribution service was logically invoked. Whether the MAC service tuple actually had to traverse the physical DSM or not is a DS implementation matter and is not specified by this standard. While IEEE Std 802.11 does not specify DS implementations, it does recognize and support the use of the WM as one possible DSM. This is specifically supported by the IEEE 802.11 frame formats. (Refer to Clause 9 for details.) A mesh BSS might form an entire DS or a part of a DS using the WM, as shown in Figure 4-9. Mesh services are used to form a mesh BSS and distribute MSDUs. Clause 14 defines how mesh BSSs are formed and how MSDUs are distributed through a mesh BSS. 4.5.2.2 Integration When the distribution service determines that the intended recipient of an MSDU is a member of an integrated LAN, the â€œoutputâ€ point of the DS is a portal instead of an AP. MAC service tuples that are distributed to a portal cause the DS to invoke the Integration function (conceptually after the distribution service). The Integration function is responsible for accomplishing whatever is needed to deliver a MAC service tuple from the DSM to the integrated LAN media (including any required media or address space translations). Integration is one of the services in the DSS. MSDUs received from an integrated LAN (via a portal) by the DS for an IEEE 802.11 STA invoke the Integration function before the MAC service tuple is distributed by the distribution service. The details of an Integration function are dependent on a specific DS implementation and are outside the scope of this standard. 4.5.2.3 QoS traffic scheduling QoS traffic scheduling provides intra-BSS QoS frame transfers under the HCF, using either contention based or controlled channel access. At each TXOP, a traffic scheduling entity at the STA selects a frame for transmission, from the set of frames at the heads of a plurality of traffic queues, based on requested UP and/ or parameter values in the traffic specification (TSPEC) for the requested MSDU. Additional information is available in 10.22. 219 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 4.5.3 Services that support the distribution service and the PCP service 4.5.3.1 General The primary purpose of a MAC sublayer is to transfer MSDUs between MAC sublayer entities. The information required for the distribution service to operate is provided by the association services. Before an MSDU can be handled by the distribution service, a STA is â€œassociated.â€ To understand the concept of association, it is necessary first to understand the concept of mobility. 4.5.3.2 Mobility types The three transition types of significance to this standard that describe the mobility of STAs within a network are as follows: a) No-transition: In this type, two subclasses that are usually indistinguishable are identified: 1) Staticâ€”no motion. 2) Local movementâ€”movement within the PHY range of the communicating STAs, i.e., movement within a basic service area (BSA). b) BSS-transition: This type is defined as a STA movement from one BSS in one ESS to another BSS within the same ESS. A fast BSS transition is a BSS transition that establishes the state necessary for data connectivity before the reassociation rather than after the reassociation. c) ESS-transition: This type is defined as STA movement from a BSS in one ESS to a BSS in a different ESS. This case is supported only in the sense that the STA might move. Maintenance of upper-layer connections cannot be guaranteed by IEEE Std 802.11; in fact, disruption of service is likely to occur. The FT protocol provides a mechanism for a STA to perform a BSS transition between access points (APs) in a robust security network (RSN) or when quality-of-service (QoS) admission control is enabled in the ESS. The different association services support the different categories of mobility. 4.5.3.3 Association To deliver an MSDU within a DS, the distribution service needs to know which AP to access for the given IEEE 802.11 STA. This information is provided to the DS by the concept of association. Association is necessary, but not sufficient, to support BSS-transition mobility. Association is sufficient to support no- transition mobility. Association is one of the services in the DSS. Before a STA is allowed to send an MSDU via an AP, it first becomes associated with the AP. The act of becoming associated invokes the association service, which provides the STA to AP mapping to the DS. How the information provided by the association service is stored and managed within the DS is not specified by this standard. Within a robust security network (RSN), association is handled differently. In an RSNA, the IEEE 802.1X Port determines when to allow data traffic across an IEEE 802.11 link. A single IEEE 802.1X Port maps to one association, and each association maps to an IEEE 802.1X Port. An IEEE 802.1X Port consists of an IEEE 802.1X Controlled Port and an IEEE 802.1X Uncontrolled Port. The IEEE 802.1X Controlled Port is blocked from passing general data traffic between two STAs until an IEEE 802.1X authentication procedure completes successfully over the IEEE 802.1X Uncontrolled Port. Once the AKM completes successfully, data protection is enabled to prevent unauthorized access, and the IEEE 802.1X Controlled Port unblocks to allow protected data traffic. IEEE 802.1X Supplicants and Authenticators exchange protocol information via 220 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications the IEEE 802.1X Uncontrolled Port. It is expected that most other protocol exchanges use the IEEE 802.1X Controlled Ports. However, a given protocol might need to bypass the authorization function and make use of the IEEE 802.1X Uncontrolled Port. NOTEâ€”See IEEE Std 802.1X-2010 for a discussion of Controlled Port and Uncontrolled Port. At any given instant, a STA is associated with no more than one AP. This allows the DS to determine a unique answer to the question, â€œWhich AP is serving STA X?â€ Once an association is completed, a STA can make full use of a DS (via the AP) to communicate. Association is always initiated by the non-AP STA, not the AP. An AP might be associated with many STAs at the same time. A STA learns what APs are present and what operational capabilities are available from each of those APs and then invokes the association service to establish an association. For details of how a STA learns about what APs are present, see 11.1.4. 4.5.3.4 Reassociation Association is sufficient for no-transition MSDU delivery between IEEE 802.11 STAs. Additional functionality is needed to support BSS-transition mobility. The additional required functionality is provided by the reassociation service. Reassociation is one of the services in the DSS. The reassociation service is invoked to â€œmoveâ€ a current association from one AP to another. This keeps the DS informed of the current mapping between AP and STA as the STA moves from BSS to BSS within an ESS. Reassociation also enables changing association attributes of an established association while the STA remains associated with the same AP. Reassociation is always initiated by the non-AP STA. Only the fast BSS transition facility can move an RSNA during reassociation. Therefore, if FT is not used, the old RSNA is deleted and a new RSNA is constructed. 4.5.3.5 Disassociation The disassociation service is invoked when an existing association is to be terminated. Disassociation is one of the services in the DSS. In an ESS, this tells the DS to void existing association information. Attempts to send MSDUs via the DS to a disassociated STA will be unsuccessful. The disassociation service can be invoked by either party in an association (non-AP STA or AP). Disassociation is a notification, not a request. Disassociation cannot be refused by the receiving STA except when management frame protection is negotiated and the message integrity check fails. An AP can disassociate STAs to enable the AP to be removed from a network for service or for other reasons. STAs attempt to disassociate when they leave a network. However, the MAC protocol does not depend on STAs invoking the disassociation service. (MAC management is designed to accommodate loss of communication with an associated STA.) 221 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 4.5.4 Access control and data confidentiality services 4.5.4.1 General Two services are required for IEEE Std 802.11 to provide functionality equivalent to that which is inherent to wired LANs. The design of wired LANs assumes the physical attributes of wire. In particular, wired LAN design assumes the physically closed and controlled nature of wired media. The physically open medium nature of an IEEE 802.11 LAN violates those assumptions. In a WLAN that does not support RSNA, two services, authentication and data confidentiality, are defined. IEEE 802.11 authentication is used instead of the wired media physical connection. WEP encryption was defined to provide the data confidentiality aspects of closed wired media. An RSNA uses the IEEE 802.1X authentication service along with enhanced data cryptographic encapsulation mechanisms, such as TKIP, CCMP, and GCMP, to provide access control. The IEEE 802.11 station management entity (SME) provides key management via an exchange of EAPOL-Key frames. Data confidentiality and data integrity are provided by RSN key management together with the enhanced data cryptographic encapsulation mechanisms. 4.5.4.2 Authentication IEEE 802.11 authentication operates at the link level between IEEE 802.11 STAs. IEEE Std 802.11 does not provide either end-to-end (MSDU origin to MSDU destination) or user-to-user authentication. IEEE Std 802.11 attempts to control LAN access via the authentication service. IEEE 802.11 authentication is an SS. This service might be used by all STAs to establish their identity to STAs with which they communicate, in both ESSs and IBSSs. If a mutually acceptable level of authentication has not been established between two STAs, an association is not established. IEEE Std 802.11 defines four IEEE 802.11 authentication methods: Open System authentication, Shared Key authentication, FT authentication, and simultaneous authentication of equals (SAE). Open System authentication admits any STA to the DS. Shared Key authentication relies on WEP to demonstrate knowledge of a WEP encryption key. FT authentication relies on keys derived during the initial mobility domain association to authenticate the stations as defined in Clause 13. SAE authentication uses finite field cryptography to prove knowledge of a shared password. The IEEE 802.11 authentication mechanism also allows definition of new authentication methods. An RSNA might support SAE authentication. An RSNA also supports authentication based on IEEE Std 802.1X-2010, or preshared keys (PSKs) after Open System authentication. IEEE 802.1X authentication utilizes the EAP to authenticate STAs and the AS with one another. This standard does not specify an EAP method that is mandatory to implement. See 12.6.5 for a description of the IEEE 802.1X authentication and PSK usage within an IEEE 802.11 IBSS. In an RSNA, IEEE 802.1X Supplicants and Authenticators exchange protocol information via the IEEE 802.1X Uncontrolled Port. The IEEE 802.1X Controlled Port is blocked from passing general data traffic between two STAs until an IEEE 802.1X authentication procedure completes successfully over the IEEE 802.1X Uncontrolled Port. SAE authentication or Open System IEEE 802.11 authentication is used by non-DMG STAs in an RSN for infrastructure BSS. SAE authentication, Open System IEEE 802.11 authentication, or no IEEE 802.11 authentication is used in an RSN for IBSS. SAE authentication is used in an MBSS. An RSNA disallows the use of Shared Key IEEE 802.11 authentication. In an RSN for DMG BSS, Open System IEEE 802.11 authentication is not used (12.2.4). 222 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A STA might be authenticated with many other STAs at the same time. Because the IEEE 802.1X authentication process could be time-consuming (depending on the authentication protocol in use), the authentication service can be invoked independently of the association service. This type of preauthentication is typically done by a STA while it is already associated with an AP (with which it previously authenticated). IEEE Std 802.11 does not require that STAs preauthenticate with APs. However, authentication is required before an association establishment is complete. If the authentication is left until reassociation time, this might impact the speed with which a STA reassociates between APs, limiting BSS-transition mobility performance. The use of preauthentication takes the authentication service overhead out of the time-critical reassociation process. SAE authentication is performed prior to association and a STA can take advantage of the fact that it can be IEEE 802.11 authenticated to many APs simultaneously by completing the SAE protocol with any number of APs while still being associated to another AP. RSNA security can be established after association using the resulting shared key. 4.5.4.3 Deauthentication The deauthentication service is invoked when an existing Open System, Shared Key, or SAE authentication is to be terminated. Deauthentication is an SS. In an ESS, because authentication is a prerequisite for association, the act of deauthentication causes the STA to be disassociated. The deauthentication service can be invoked by either authenticated party (non-AP STA or AP). Deauthentication is not a request; it is a notification. The association at the transmitting STA is terminated when the STA sends a deauthentication notice to an associated STA. Deauthentication, and if associated, disassociation cannot be refused by the receiving STA except when management frame protection is negotiated and the message integrity check fails. In an RSN ESS, Open System IEEE 802.11 authentication is required. In an RSN ESS, deauthentication results in termination of any association for the deauthenticated STA. It also results in the IEEE 802.1X Controlled Port for that STA being disabled and deletes the pairwise transient key security association (PTKSA). The deauthentication notification is provided to IEEE Std 802.1X-2010 via the MAC layer. In an RSNA, deauthentication also deletes any related pairwise transient key security association (PTKSA), group temporal key security association (GTKSA), station-to-station link (STSL) master key security association (SMKSA), STSL transient key security association (STKSA), TPK security association (TPKSA), integrity group temporal key security association (IGTKSA), mesh GTKSA, and mesh TKSA that exist in the STA and closes the associated IEEE 802.1X Controlled Port. If pairwise master key security association (PMKSA) caching is not enabled, deauthentication also deletes the PMKSA or mesh PMKSA. In an RSN IBSS, Open System authentication is optional, but a STA is required to recognize Deauthentication frames. Deauthentication results in the IEEE 802.1X Controlled Port for that STA being disabled and deletes the PTKSA. 4.5.4.4 Data confidentiality In a wired LAN, only those STAs physically connected to the wire can send or receive LAN traffic. With a wireless shared medium, there is no physical connection, and all STAs and certain other RF devices in or near the LAN might be able to send, receive, and/or interfere with the LAN traffic. A STA receives traffic that is within range and transmits to any other STA within range. Thus, the connection of a single wireless link (without data confidentiality) to an existing wired LAN might seriously degrade the security level of the wired LAN. 223 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications To bring the security of the WLAN up to the level implicit in wired LAN design, IEEE Std 802.11 provides the ability to protect the contents of frames. This functionality is provided by the data confidentiality service. Data confidentiality is an SS. IEEE Std 802.11 provides several cryptographic algorithms to protect data traffic, including: WEP, TKIP, CCMP, and GCMP. WEP and TKIP are based on the ARC420 algorithm, and CCMP and GCMP are based on the advanced encryption standard (AES). A means is provided for STAs to select the algorithm(s) to be used for a given association. IEEE Std 802.11 provides the following security protocols for protection of individually addressed robust Management frames: CCMP and GCMP. This standard does not provide data confidentiality for group addressed robust Management frames, except for certain Action frames related to mesh operation, as indicated in Table 9-47. IEEE Std 802.11 provides one security protocol, CCMP, for protection of individually addressed and group addressed Data frames between mesh STAs. The default data confidentiality state for all IEEE 802.11 STAs is â€œin the clear,â€ i.e., without protection. If the data confidentiality service is not invoked, all frames are sent unprotected. If this policy is unacceptable to the sender, it does not send Data frames; and if the policy is unacceptable to the receiver, it discards any received Data frames. Unprotected Data frames and unprotected robust Management frames received at a STA configured for mandatory data confidentiality, as well as protected Data frames and protected robust Management frames using a key not available at the receiving STA, are discarded without an indication to LLC (or without indication to distribution services in the case of â€œTo DSâ€ frames received at an AP). These frames are acknowledged on the WM [if received without frame check sequence (FCS) error] to avoid wasting WM bandwidth on retries of frames that are being discarded. 4.5.4.5 Key management The enhanced data confidentiality, data authentication, and replay protection mechanisms require fresh cryptographic keys and corresponding security associations. The procedures defined in this standard provide fresh keys by means of protocols called the 4-way handshake, FT 4-way handshake, FT protocol, FT resource request protocol, and group key handshake. 4.5.4.6 Data origin authenticity The data origin authenticity mechanism defines a means by which a STA that receives a Data or protected robust Management frame can determine which STA transmitted the MAC protocol data unit (MPDU). This feature is required in an RSNA to prevent one STA from masquerading as a different STA. Data origin authenticity is applicable only to individually addressed Data frames, and individually addressed robust Management frames. The protocols do not guarantee data origin authenticity for group addressed frames, as this cannot be accomplished using symmetric keys and public key methods are too computationally expensive. 4.5.4.7 Replay detection The replay detection mechanism defines a means by which a STA that receives a Data or protected robust Management frame from another STA can detect whether the received frame is an unauthorized 20 Details of the ARC4 algorithm are available from RSA Security, Inc. Contact RSA Security, 174 Middlesex Turnpike, Bedford, MA 01730 (http://www.rsasecurity.com/), for algorithm details and the uniform ARC4 license terms that RSA offers to anyone wishing to use ARC4 for the purpose of implementing the IEEE 802.11 WEP option. If necessary, contact the IEEE Standards Department Intellectual Property Rights Administrator for details on how to communicate with RSA. 224 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications retransmission. This replay protection mechanism is provided for Data frames for STAs that use enhanced data cryptographic encapsulation mechanisms. The replay protection mechanism is also provided for robust Management frames for STAs that use CCMP, GCMP, and broadcast/multicast integrity protocol (BIP). 4.5.4.8 Fast BSS transition The FT mechanism defines a means for a STA to set up security and QoS parameters prior to reassociation to a new AP. This mechanism allows time-consuming operations to be removed from the time-critical reassociation process. 4.5.4.9 Robust management frame protection Robust Management frames are a set of Management frames that can be protected by the management frame protection service. Management frame protection protocols in an infrastructure BSS or IBSS apply to robust Management frames after RSNA PTK establishment for protection of individually addressed frames is completed and after delivery of the IGTK to protect group addressed frames. Robust management frame protection is implemented by CCMP, GCMP, BIP, and the SA Query procedure. Management frame protection protocols in an MBSS apply to individually addressed frames after establishment of the RSNA MTK, and to group addressed frames indicated as â€œGroup Addressed Privacyâ€ in Table 9-47. Robust management frame protection is implemented with CCMP and GCMP. 4.5.5 Spectrum management services 4.5.5.1 General Two services are required to satisfy requirements in some regulatory domains (see Annex D and Annex E) for operation in the 5 GHz band. These services are called transmit power control (TPC) and dynamic frequency selection (DFS). 4.5.5.2 TPC Regulations that apply to the 5 GHz band in certain regulatory domains require RLANs operating in the 5 GHz band to use transmitter power control, involving specification of a regulatory maximum transmit power and a mitigation requirement for each allowed channel. The TPC service is used to satisfy this regulatory requirement. The TPC service provides for the following: â€” Association of STAs with an AP based on the STAsâ€™ power capability â€” Specification of regulatory and local maximum transmit power levels for the current channel â€” Selection of a transmit power for each transmission in a channel within constraints imposed by regulatory requirements â€” Adaptation of transmit power based on a range of information, including path loss and link margin estimates 4.5.5.3 DFS Regulations that apply to the 5 GHz band in certain regulatory domains require RLANs operating in the 5 GHz band to avoid co-channel operation with radar systems and to provide uniform utilization of available channels. The DFS service is used to satisfy these regulatory requirements. 225 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The DFS service provides for the following: â€” Association of STAs with an AP based on the STAsâ€™ supported channels. â€” Quieting the current channel so it can be tested for the presence of radar with less interference from other STAs. â€” Testing channels for radar before using a channel and while operating in a channel. â€” Discontinuing operations after detecting radar in the current channel to avoid interference with radar. â€” Detecting radar in the current and other channels based on regulatory requirements. â€” Requesting and reporting of measurements in the current and other channels. â€” Selecting and advertising a new channel to assist the migration of a BSS after radar is detected. 4.5.6 Traffic differentiation and QoS support 4.5.6.1 General IEEE Std 802.11 uses a shared medium and provides differentiated control of access to the medium to handle data transfers with QoS requirements. The QoS facility (per MSDU traffic category and TSPEC negotiation) allows an IEEE 802.11 LAN to become part of a larger network providing end-to-end QoS delivery or to function as an independent network providing transport on a per-link basis with specified QoS commitments. The specifications regarding the integration and operability of the QoS facility with any other end-to-end QoS delivery mechanism like Resource Reservation Protocol (RSVP) are beyond the scope of this standard. 4.5.6.2 Quality-of-service management frame support When the quality-of-service management frame (QMF) service is enabled, some Management frames might be transmitted using an access category other than the access category assigned to voice traffic (access category AC_VO, see 9.4.2.29) in order to improve the quality of service of other traffic streams. This is achievable by the use of a QMF policy. A QMF policy defines the access categories of different Management frames. Only QoS STAs are able to implement QMF policy. A non-AP QMF STA uses the default QMF policy or the QMF policy accepted from a peer QMF STA to transmit Management frames to that peer QMF STA. A QMF AP sets its own QMF policy for the transmission of QMFs to its associated STAs. A QMF STA uses access category AC_VO to transmit Management frames to STAs that do not support the QMF service. 4.5.7 Support for higher layer timer synchronization Some applications, e.g., the transport and rendering of audio or video streams, require synchronized timers shared among different STAs. Greater accuracy (in terms of jitter bounds) or finer timer granularity than that provided by a BSS timing synchronization function (TSF) might be an additional requirement. In support of such applications, this standard defines a MAC service that enables layers above the MAC to accurately synchronize application-dependent timers shared among STAs. The service is usable by more than one application at a time. 226 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Although the timer synchronization methods and accuracy requirements are application-dependent and are beyond the scope of this standard, they rely on an indication from each MAC that is provided essentially simultaneously, via group addressed transmissions, to the STAs. The MAC accomplishes this by indicating the occurrence of the end of the last symbol of particular Data frames; the Data frames of interest are identified by their MAC header Address 1 field when it contains a group address previously registered with the MAC. The last symbol is observed21 on the WM by STAs within a BSS while the delay between the observation and the delivery of the indication is known within a MAC by design (and communicated to the application by implementation dependent means). The common reference point in time provided by the end of last symbol indication is the essential building block upon which a variety of application-dependent timer synchronization methods might be based. 4.5.8 Radio measurement service The Radio measurement service provides the following: â€” The ability to request and report radio measurements in supported channels. â€” The ability to perform radio measurements in supported channels. â€” An interface for upper layer applications to retrieve radio measurements using MLME primitives and/or MIB access. â€” Information about neighbor APs. 4.5.9 Interworking with external networks The interworking service allows non-AP STAs to access services provided by an external network according to the subscription or other characteristics of that external network. An IEEE 802.11 non-AP STA might have a subscription relationship with an external network, e.g., with an SSPN. An overview of the interworking functions addressed in this standard is provided below: â€” Network discovery and selection â€” Discovery of suitable networks through the advertisement of access network type, roaming consortium and venue information, via Management frames â€” Selection of a suitable IEEE 802.11 infrastructure using advertisement services (e.g., access network query protocol (ANQP) or an IEEE 802.21â„¢ Information Server) in the BSS or in an external network reachable via the BSS. â€” Selection of an SSPN or external network with its corresponding IEEE 802.11 infrastructure â€” Emergency services â€” Emergency Call and Network Alert support at the link level â€” QoS mapping distribution â€” SSPN interface service between the AP and the SSPN The generic advertisement service (GAS), described in 4.5.10, provides both support for a STAâ€™s network discovery and selection, and support for a conduit for communication by a non-AP STA with other information resources in a network before joining the wireless LAN. The interworking service supports emergency services by providing methods for users to access emergency services via the IEEE 802.11 infrastructure, advertising that emergency services are supported (see 11.25.6) and identifying that a traffic stream is used for emergency services. 21 The synchronization indication (observed time) within the BSS varies slightly due to propagation. 227 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The interworking service provides QoS mapping for SSPNs and other external networks. Since each SSPN or other external network might have its own layer-3 end-to-end packet marking practice (e.g., differentiated services code point (DSCP) usage conventions), a means to remap the layer-3 service levels to a common over-the-air service level is necessary. The QoS Map service provides STAs a mapping of network-layer QoS packet marking to over-the-air QoS frame marking (i.e., user priority). The SSPN Interface service supports service provisioning and transfer of user permissions from the SSPN to the AP. The method and protocol by which these permissions are transferred from the SSPN are outside the scope of this standard. 4.5.10 Generic advertisement service (GAS) GAS provides functionality that enables STAs to discover the availability of information related to desired network services, e.g., information about services such as provided in an IBSS, local access services, available subscription service providers (SSPs) and/or SSPNs or other external networks. GAS uses a generic container to advertise network servicesâ€™ information over an IEEE 802.11 network. Public Action frames are used to transport this information. While the specification of network services information is outside the scope of this standard, in an infrastructure BSS there is a need for STAs to query for information on network services provided by SSPNs or other external networks beyond an AP, before they associate with the wireless LAN. The exchange of information can also be performed after associating to the BSS. In an IBSS/PBSS, GAS functionality enables a STA to access the availability and information related to desired services provided by other STAs in the IBSS/PBSS. Exchange of information using GAS can be performed either prior to joining an IBSS/PBSS or after joining the IBSS/PBSS. There are a number of reasons why providing information to a STA in a preassociated state is beneficial: â€” It supports more informed decision making about an IEEE 802.11 infrastructure or PBSS with which to associate. This is generally more efficient than requiring a non-AP and non-PCP STA to associate with an AP or PCP before discovering the information and then deciding whether to stay associated. â€” It is possible for the non-AP and non-PCP STA to query multiple networks in parallel. â€” The non-AP STA can discover information about APs that are not part of the same administrative group as the AP with which it is associated, supporting the selection of an AP belonging to a different IEEE 802.11 infrastructure that has an appropriate SSP roaming agreement in place. 4.6 Multiple logical address spaces Just as the IEEE 802.11 architecture allows for the possibility that the WM, DSM, and an integrated non- IEEE-802.11 LAN might all be different physical media, it also allows for the possibility that each of these components might be operating within different address spaces. IEEE Std 802.11 only uses and specifies the use of the WM address space. Each IEEE 802.11 PHY operates in a single mediumâ€”the WM. The IEEE 802.11 MAC operates in a single address space. MAC addresses are used on the WM in the IEEE 802.11 architecture. Therefore, it is unnecessary for the standard to explicitly specify that its addresses are â€œWM addresses.â€ This is assumed throughout this standard. IEEE Std 802.11 has chosen to use the IEEE 802 48-bit address space (see 9.2.4.3.2). Thus IEEE 802.11 addresses are compatible with the address space used by the IEEE 802 LAN family. 228 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The IEEE 802.11 choice of address space implies that for many instantiations of the IEEE 802.11 architecture, the non-IEEE-802.11 LAN MAC address space and the IEEE 802.11 MAC address space might be the same. In those situations where a DS that uses MAC level IEEE 802 addressing is appropriate, all three of the logical address spaces used within a system could be identical. While this is a common case, it is not the only combination allowed by the architecture. The IEEE 802.11 architecture allows for all three logical address spaces to be distinct. A multiple address space example is one in which the DS implementation uses network layer addressing. In this case, the WM address space and the DS address space are different. Note that IEEE 802.11 STAs within a single ESS share the same address space, fulfilling the transparency requirement from the definition of the DS. The DSS uses this same address space, even in the case where the DSM uses a different address space. The ability of the architecture to handle multiple logical media and address spaces is key to the ability of IEEE Std 802.11 to be independent of the DS implementation and to interface cleanly with network layer mobility approaches. The implementation of the DS is unspecified and is beyond the scope of this standard. 4.7 Differences among ESS, PBSS, and IBSS LANs In 4.3.2 the concept of the IBSS LAN was introduced, and in 4.3.3 the concept of the PBSS LAN was introduced. In an IBSS or PBSS, a STA communicates directly with one or more other STAs. Consider the full IEEE 802.11 architecture as shown in Figure 4-16. IEEE Std 802.11 Components BSS 1 802.11 MAC/PHY STA 1 SS STA 2 BSS 3 AP ESS STA 6 DSS Y H P / DS SS C A M 1 1 . 2 0 8 DSS DSS AP STA 5 Portal PCP STA 3 SS PCPS STA 4 802.11 MAC/PHY BSS 2 802.x LAN Figure 4-16â€”IEEE 802.11 architecture (again) 229 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications An IBSS consists of STAs that are directly connected. Thus there is (by definition) only one BSS. Further, because there is no physical DS, there is no portal, integrated non-IEEE-802.11 LAN, or DSS. The logical picture reduces to Figure 4-17. IEEE Std 802.11 Independent BSS IEEE Std 802.11 MAC/PHY STA 1 STA 2 SS Figure 4-17â€”Logical architecture of an IBSS An important difference between the IBSS and the PBSS is that, within the PBSS, Beacons are not transmitted by every STA and instead only a single STA, namely the PCP, is responsible for DMG Beacon frame transmission. Within the IBSS, all STAs are responsible for Beacon frame transmission. When compared to the infrastructure BSS, the PBSS does not provide certain DSSs as described in 4.4.3. There can be more than one PBSS in the same BSA. One of the STAs within each PBSS assumes the role of the PCP. The logical picture of the PBSS reduces to Figure 4-18. IEEE Std 802.11 Personal BSS IEEE Std 802.11 MAC/PHY STA 1/PCP SS STA 2 Figure 4-18â€”Logical architecture of a PBSS Only the minimum two STAs are shown in Figure 4-17. An IBSS can have an arbitrary number of members. In an IBSS only Class 1 and Class 2 frames are allowed because there is no DS in an IBSS. The services that apply to an IBSS are the SSs. A QoS IBSS supports operation under the HCF using TXOPs gained through the EDCA mechanism. The parameters that control differentiation of the delivery of MSDUs with different priority using EDCA are fixed. A QoS IBSS has no HC and does not support polled TXOP operation and setting up of TSPEC. The services that apply to the PBSS are the SSs and the PCPSs as described in 4.4.3. A PBSS supports operation under the HCF using TXOPs gained through the EDCA mechanism. In a PBSS, the EDCA 230 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications mechanism is used only within CBAPs. The parameters that control differentiation of traffic classes using EDCA can be configured by the PCP in a PBSS. The PCP of a PBSS has no HC, but can support TSPEC setup, DMG TSPEC setup, and service periods. In an IBSS each STA enforces its own security policy. In an infrastructure BSS or a PBSS, an AP or a PCP, respectively, can enforce a uniform security policy across all STAs. 4.8 Differences between ESS and MBSS LANs In 4.3.20, the concept of the MBSS LAN was introduced. It was noted that using the multi-hop capability it appears as if all mesh STAs are directly connected at the MAC layer even if the STAs are not within range of each other. This is different from an IBSS, where STAs cannot communicate if they are not within range of each other. Unlike the IBSS, an MBSS might have access to the DS. An MBSS connects through one or more mesh gates to the DS. Since in an MBSS it appears as if all mesh STAs are directly connected at the MAC layer, the MBSS can be used as a DSM. APs, a portal, and mesh gates might use the MBSS as a DSM to provide the DSS. Thus, different infrastructure BSSs can unite over the MBSS to form an ESS for example. An AP identifies the infrastructure BSS that it forms. This is different from the MBSS where no such central entity exists. Whereas infrastructure BSSs need the ESS and thus the DS to unite, the MBSS appears the same to an LLC layer without the need for access to a DS. However, if an MBSS has one or more mesh gates providing access to the DS, the MBSS might exist in disjointed areas and yet form a single network. 4.9 Reference model 4.9.1 General This standard presents the architectural view, emphasizing the separation of the system into two major parts: the MAC of the data link layer (DLL) and the PHY. These layers are intended to correspond closely to the lowest layers of the ISO/IEC basic reference model of Open Systems Interconnection (OSI) (ISO/IEC 7498- 1:1994). The layers and sublayers described in this standard are shown in Figure 4-19. There is an interface between the IEEE 802.1X Supplicant/Authenticator and the SME not shown in Figure 4-19. This interface is described in IEEE Std 802.1X-2010. 4.9.2 Interworking reference model The MAC state generic convergence function (MSGCF) provides services to higher layer protocols based on MAC state machines and interactions between the layers. Interworking functions might require correlating information from multiple management entities. It is the function of the MSGCF to correlate information for higher layer entities. The MSGCF observes the interactions between the MLME and SME, and between the PLME and SME. After correlation of lower- layer MLME and PLME events, the MSGCF might synthesize indications to higher layer entities. Figure 4-20 shows an entity, the MSGCF, defined in 6.4, that has access to all management information through exposure to the MAC sublayer and PHY management entities, and provides management information to higher level entities, such as Mobility Managers, supporting heterogeneous medium mobility. An example of how the MSGCF interfaces to these higher layer entities, is provided by the media- independent handover (MIH) interface, as defined in IEEE Std 802.21-2008. 231 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 802.1X Authenticator / 802.1X Supplicant MAC SAP RSNA Key MAC Sublayer Management Management Data Link MAC Sublayer Entity Layer MLME SAP MLME-PLME PHY SAP SAP Station Management Entity PHY Sublayer Physical PHY Sublayer Management PLME SAP Layer Entity Figure 4-19â€”Portion of the ISO/IEC basic reference model covered in this standard MSGCF SAP MAC State Generic 802.1X 802.1X Authenticator Convergence Function / Supplicant MAC SAP MSGCF-SME SAP MAC Sublayer RSNA Key Management Management Data Link MAC Sublayer Entity MLME SAP Layer MLME-PLME PHY SAP SAP Station PHY Sublayer Management Physical PHY Sublayer Management PLME SAP Entity Layer Entity Figure 4-20â€”Interworking reference model The MSGCF is designed to provide the status of the connection of a non-AP STA to a set of BSSs comprising a single ESS. Figure 4-21 illustrates the concept of an ESS Link. This reflects the state of a connection to an ESS independent of any particular access point. In Figure 4-21, STA3 is associated with either AP1 or AP2. The state of the ESS Link is up when STA3 is associated with any of the APs comprising an ESS. 232 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 802.x LAN Portal DS AP1 STA1 AP2 STA2 STA3 BSS1 BSS2 ESS Figure 4-21â€”ESS link illustration 4.9.3 Reference model for supporting multiple MAC sublayers An MM-SME function interfaces with the SMEs of the coordinating STAs. STAs managed under the MM- SME share the same antennas and PHY and optionally unify power management. The reference model for supporting multiple MAC sublayers is shown in Figure 4-22. 802.1X 802.1X 802.1X SME SME SME MM- MAC 1 SAP STA 1 MAC 2 SAP MAC n SAP SME STA 2 STA n MAC Sublayer MAC Sublayer MAC Sublayer MAC Sublayer MAC Sublayer MAC Sublayer Management Entity Management Entity Management Entity PHY SAP MLME-PLME SAP PLME SAP PHY Figure 4-22â€”Reference model for supporting multiple MAC sublayers An MM-SME coordinates the management of multiple MAC sublayers. Each MAC sublayer has a separate MAC SAP and MLME SAP. A MAC SAP together with its corresponding MLME SAP is identified by a MAC address. Even when coordinated by an MM-SME, each MAC retains its single MAC address, and each STA contains a single MAC; therefore, the MM-SME coordinates multiple STAs as well as multiple MACs. 233 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Multiple STAs coordinated by an MM-SME have a single PHY that is shared by the multiple MAC sublayers. Transmission attempts of different MAC sublayers can collide internally if the STAs share a single PHY, and a backoff procedure is invoked in this case. Since multiple STAs coordinated by the same MM-SME share the PHY, the STAs cannot directly exchange frames with each other. NOTEâ€”The multiple MAC reference model shown in Figure 4-22 defines how multiple STAs can share the same physical layer entity. If this model is used in conjunction with the reference model for multi-band operation (see 4.9.4), the multiple MAC reference model applies within each physical layer entity contained in the multi-band device whereas the multi-band operation reference model applies to different physical layers. The MM-SME accesses each of the MLME SAPs of the coordinated STAs separately to deliver MLME SAP primitives. STAs that are coordinated by the same MM-SME can establish a multiple MAC sublayers link (MMSL) with a peer STA. The set of all MMSLs between a pair of STAs creates an MMSL cluster. An MM-SME controls the power management mode, DMG antenna configuration, and other parameters and states of the coordinated STAs to eliminate unnecessary duplication of functions. A change in the power management mode of the STAs coordinated by an MM-SME is signaled to a peer STA via any one of the STAsâ€™ MAC sublayer. Also, a beamforming link established between STAs can be used by all of the MAC sublayers of any of the STAs coordinated by the same MM-SME. For these purposes, a Multiple MAC Sublayers (MMS) element is used. The MMS element contains multiple MAC addresses of the MACs coordinated by the same MM-SME. The element can be included in any frame that advertises the MM-SME capabilities, such as Probe Request and Probe Response frames and Information Request and Information Response frames, and the frames that establish communication agreements, such as Association, ADDTS Request, ADDTS Response, BlockAckReq and BlockAck. 4.9.4 Reference model for multi-band operation The reference model of a device that is multi-band capable (see 11.33) and that supports transparent fast session transfer (FST) is shown in Figure 4-23. The reference model of a device that is multi-band capable and that supports nontransparent FST is shown in Figure 4-24. 802.1X Authenticator / Multi-band Management Supplicant RSNA Key Management 802.1X MAC SAP Transparent FST Entity MAC Sublayer MAC Sublayer Management Entity Management Entity MAC Sublayer MAC Sublayer MLME-PLME SAP PHY SAP PHY SAP MLME-PLME SAP PHY Management PHY Management SME PHY PHY SME Entity Entity STA 1 STA 2 (e.g., in 2.4 GHz) (e.g., in 60 GHz) Figure 4-23â€”Reference model for a multi-band capable device (transparent FST) 234 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Multi-band Management 802.1X 802.1X MAC SAP MAC SAP MAC Sublayer 802.1X MAC Sublayer 802.1X MAC Sublayer MAC Sublayer Management Entity Authenticator / Management Entity Authenticator / Supplicant Supplicant PHY SAP MLME-PLME SAP PHY SAP MLME-PLME SAP RSNA Key RSNA Key Management Management PHY Management PHY Management PHY PHY Entity Entity SME SME STA 1 STA 2 (e.g., in 2.4 GHz) (e.g., in 60 GHz) Figure 4-24â€”Reference model for a multi-band capable device (nontransparent FST) A multi-band capable device can manage operation over more than one frequency band/channel. The operation across the different frequency bands/channels can be simultaneous or nonsimultaneous. A multi-band capable device can also support multiple MAC sublayers; in this case, it is coordinated by an MM-SME. NOTEâ€”For simplicity, Figure 4-23 and Figure 4-24 depict the reference model when there is a one-to-one mapping between PHYs and MACs. However, the reference model for a multi-band capable device can be applied in conjunction with the reference model for STAs that support multiple MAC sublayers (see 4.9.3). An FST session is the state resulting from the operation of the FST session setup protocol. The SME of a multi-band capable device contains a multi-band management entity that is responsible for coordinating the setup, configuration, teardown, and transfer of FST sessions from a band/channel to another band/channel supported by the multi-band capable device. If using nontransparent FST, the multi- band management entity can employ a combination of the source and destination MAC addresses in both the old and new band/channel to configure the routing of MSDUs and MLME primitives within the STA. If using transparent FST, in addition to the MAC addresses, the multi-band management entity can employ the TID of an FST session for this routing. The multi-band procedures (see 11.33) allow a pair of multi-band capable devices to discover, synchronize, (de)authenticate, (re)associate, disassociate, and manage resources with each other on any common band/ channel that is supported by both STAs. When used in the context of FST, the term â€œsessionâ€ refers to non-PHY state information that is kept in a pair of STAs that communicate directly (i.e., excludes forwarding) and that is available prior to and following a session transfer. This state information is different depending if transparent or nontransparent is used. For transparent FST, a shared multi-band management entity has access to the local information within each SME; and in this case the state information includes block ack agreements, TSs, association state, RSNA, security keys, sequence counter, and PN counter. For nontransparent FST, the function of the multi- band management entity is restricted to coordinating the setup and teardown of a session transfer with no access to other local information within each SME. Therefore, with nontransparent FST, any information local to an SME needs to be reestablished for the new band/channel, and this can be done either prior to or following the session transfer (see 11.33). 235 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications By using the on-channel tunneling (OCT) multi-band procedure described in 11.33.4, the SME of a multi- band capable device can instruct one of its MLMEs to use the OCT services provided by another MLME of the same multi-band capable device to communicate with a peer MLME of a peer multi-band capable device. This enables the SMEs of a pair of multi-band capable devices to provide a seamless FST, including performing (de)authentication and (re)association across bands/channels. The MLMEs that use the OCT services provided by another MLME within the same multi-band capable device to communicate are referred to as being over-the-WM disabled with respect to each other. Following an FST, two peer over-the- WM disabled MLMEs can become over-the-WM enabled with respect to each other. As described in 5.1.5, a MAC address is not unique within the multi-band capable device when transparent FST is intended to be used. When transparent FST is used, a single MAC SAP at each peer is presented to the higher layers of that peer for all of the frequency bands/channels that are identified by the same MAC address at that peer. When nontransparent FST is used, different MAC SAPs are presented to higher layers since different MAC addresses are used prior to and following an FST. Therefore, when nontransparent FST is used, higher layers are responsible for managing the session transition between different frequency bands/ channels. Each MAC SAP is controlled by a separate and independent RSNA key management entity and IEEE 802.1X Authenticator/Supplicant, unless if transparent FST is used in which case the multi-band management entity is responsible for coordinating with each of the SMEs to ensure that a single RSNA key management entity and IEEE 802.1X Authenticator/Supplicant are shared among the MACs and that a single IEEE 802.1X entity is controlled. 4.10 IEEE Std 802.11 and IEEE Std 802.1X-2010 4.10.1 General An RSNA relies on IEEE Std 802.1X-2010 to provide authentication services and uses the IEEE 802.11 key management scheme defined in 12.7. The IEEE 802.1X access control mechanisms apply to the association between a STA and an AP and to the relationship between the IBSS STA and STA peer. The APâ€™s SME performs the Authenticator and, optionally, the Supplicant and AS roles. In an infrastructure BSS, a non-AP STAâ€™s SME performs the Supplicant role. In an IBSS the SME takes on both the Supplicant and Authenticator roles and might take on the AS role. 4.10.2 IEEE 802.11 usage of IEEE Std 802.1X-2010 IEEE Std 802.11 depends upon IEEE Std 802.1X-2010 to control the flow of MAC service data units (MSDUs) between the DS and STAs by use of the IEEE 802.1X Controlled/Uncontrolled Port model. IEEE 802.1X EAPOL PDUs are transmitted in one or more IEEE 802.11 Data frames and passed via the IEEE 802.1X Uncontrolled Port. The IEEE 802.1X Controlled Port is blocked from passing general data traffic between two STAs until an IEEE 802.1X authentication procedure completes successfully over the IEEE 802.1X Uncontrolled Port. It is the responsibility of both the Supplicant and the Authenticator to implement port blocking. Each association between a pair of STAs creates a unique pair of IEEE 802.1X Ports, and authentication takes place relative to those ports alone. IEEE Std 802.11 depends upon IEEE Std 802.1X-2010 and the 4-way handshake, FT 4-way handshake, FT protocol, FT resource request protocol, and group key handshake, described in Clause 12 and Clause 13, to establish and change cryptographic keys. Keys are established after authentication has completed. Keys might change for a variety of reasons, including expiration of an IEEE 802.1X authentication timer, key compromise, danger of compromise, or policy. 236 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 4.10.3 Infrastructure functional model overview 4.10.3.1 General This subclause summarizes the system setup and operation of an RSN, in three cases: when a password or PSK is used during IEEE 802.11 authentication, when an IEEE 802.1X AS is used after Open System authentication, and when a PSK is used after Open System authentication. In an RSN, an AP includes an Authenticator, and each associated STA includes a Supplicant. 4.10.3.2 AKM operations with AS The following AKM operations are carried out when an IEEE 802.1X AS is used: a) Prior to any use of IEEE Std 802.1X-2010, IEEE Std 802.11 assumes that the Authenticator and AS have established a secure channel. The security of the channel between the Authenticator and the AS is outside the scope of this standard. Authentication credentials are distributed to the Supplicant and AS prior to association. b) A STA discovers the APâ€™s security policy through passively monitoring Beacon frames or through active probing (shown in Figure 4-25). If IEEE 802.1X authentication is used, the EAP authentication process starts when the Authenticator sends the EAP-Request (shown in Figure 4-26) or the Supplicant sends the EAPOL-Start frame. EAP messages pass between the Supplicant and AS via the Authenticator and Supplicantâ€™s Uncontrolled Ports. This is shown in Figure 4-26. STA AP IEEE Std 802.11 probe request IEEE Std 802.11 probe response (security parameters) IEEE Std 802.11 open system authentication request IEEE Std 802.11 open system authentication response IEEE Std 802.11 association request (security parameters) IEEE Std 802.11 association response IEEE Std 802.1X controlled port blocked Figure 4-25â€”Establishing the IEEE 802.11 association 237 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications c) The Supplicant and AS authenticate each other and generate a PMK. The PMK is sent from the AS to the Authenticator over the secure channel. See Figure 4-26. Supplicant Authenticator AS IEEE 802.1X EAP Request IEEE 802.1X EAP Response Access Request (EAP Request) EAP Authentication Protocol Exchange Accept / EAP Success / Key Material IEEE 802.1X EAP Success IEEE 802.1X Controlled Port Blocked for STA Figure 4-26â€”IEEE 802.1X EAP authentication A 4-way handshake or FT 4-way handshake utilizing EAPOL-Key frames is initiated by the Authenticator to do the following: â€” Confirm that a live peer holds the PMK. â€” Confirm that the PMK is current. â€” In the case of fast BSS transition, derive PMK-R0s and PMK-R1s. â€” Derive a fresh pairwise transient key (PTK) from the PMK or, in the case of fast BSS transition, from the PMK-R1. â€” Install the pairwise encryption and integrity keys. â€” Transport the group temporal key (GTK) and GTK sequence number from Authenticator to Supplicant and install the GTK and GTK sequence number in the STA and, if not already installed, in the AP. â€” If management frame protection is negotiated, transport the IGTK and the IGTK packet number (IPN) from the Authenticator to the Supplicant and install these values in the STA and, if not already installed, in the AP. â€” Verify that the RSN capabilities negotiated are valid as defined in 9.4.2.25.4. â€” Confirm the cipher suite selection. Installing the PTK, and where applicable the GTK and, if management frame protection is negotiated, the IGTK, causes the MAC to encrypt and decrypt all subsequent MSDUs irrespective of their path through the controlled or uncontrolled ports. Upon successful completion of the 4-way handshake, the Authenticator and Supplicant have authenticated each other; and the IEEE 802.1X Controlled Ports are unblocked to permit general data traffic. See Figure 4-27. 238 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Supplicant Authenticator Key (PMK) is known Key (PMK) is known Generate SNonce Generate ANonce Message 1: EAPOL-Key(ANonce, Individual) Derive PTK Message 2: EAPOL-Key(SNonce, Individual, MIC) Derive PTK If needed Generate GTK and IGTK Message 3: EAPOL-Key(Install PTK, Individual, MIC, Encrypted (GTK, IGTK)) Message 4: EAPOL-Key(Individual, MIC) Install PTK, GTK. Install PTK, GTK. IGTK IGTK IEEE 802.1X Controlled port unblocked Figure 4-27â€”Establishing pairwise and group keys If the Authenticator later changes the GTK, it sends the new GTK and GTK sequence number to the Supplicant using the group key handshake to allow the Supplicant to continue to receive group addressed frames and, optionally, to transmit and receive individually addressed frames. EAPOL-Key frames are used to carry out this exchange. See Figure 4-28. When management frame protection is negotiated, the Authenticator also uses the group key handshake with all associated STAs to change the IGTK. The Authenticator encrypts the GTK and IGTK values in the EAPOL-Key frame as described in 12.7. 4.10.3.3 AKM operations with a password or PSK The following AKM operations are carried out when authentication is accomplished using a Password or PSK: â€” A STA discovers the APâ€™s security policy through passively monitoring the Beacon frames or through active probing. After discovery the STA performs SAE authentication using Authentication frames with the AP (see Figure 4-29). â€” Upon the successful conclusion of SAE, both the STA and AP generate a PMK. The STA then associates to an AP and negotiates security policy. The AKM in the Association Request and Response frames is confirmed to be the AKM of SAE or of fast BSS transition. â€” The PMK generated by SAE is used in a 4-way handshake using EAPOL-Key frames, just as with IEEE 802.1X authentication when an AS is present. See Figure 4-27. 239 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” The GTK and GTK sequence number are sent from the Authenticator to the Supplicant just as in the AS case. See Figure 4-27 and Figure 4-28. Supplicant Authenticator Generate GTK, IGTK Encrypt GTK, IGTK with KEK Message 1: EAPOL-Key(Encrypted GTK, Encrypted IGTK, Group, MIC) Install GTK, IGTK Message 2: EAPOL-Key(Group, MIC) Figure 4-28â€”Delivery of subsequent group keys STA AP IEEE Std 802.11 Probe Request IEEE Std 802.11 Probe Response (Security Parameters) IEEE Std 802.11 SAE Authentication (Commit Message) IEEE Std 802.11 SAE Authentication (Commit Message) IEEE Std 802.11 SAE Authentication (Confirm Message) IEEE Std 802.11 SAE Authentication (Confirm Message) Figure 4-29â€”Example using SAE authentication 4.10.3.4 Alternate operations with PSK The following AKM operations represent an alternate operation of using a PSK. This operation has security vulnerabilities when used with a low-entropy key and is recommended to be used only after taking that into account. When this operation is carried out, the PMK is a PSK: â€” A STA discovers the APâ€™s security policy through passively monitoring Beacon frames or through active probing (shown in Figure 4-25). A STA associates with an AP and negotiates a security policy. The PMK is the PSK. â€” The 4-way handshake using EAPOL-Key frames is used, just as with IEEE 802.1X authentication, when an AS is present. See Figure 4-27. 240 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” The GTK and GTK sequence number are sent from the Authenticator to the Supplicant just as in the AS case. See Figure 4-27 and Figure 4-28. â€” If management frame protection is negotiated, the IGTK and IGTK packet number are sent from the Authenticator to the Supplicant just as in the AS case. See Figure 4-27 and Figure 4-28. 4.10.3.5 Disassociation Disassociation initiated by either STA in an RSNA causes the deletion of the PTKSA at both ends and the deletion of the GTKSA in a non-AP STA. The controlled and uncontrolled ports created for this association are also deleted. 4.10.4 IBSS functional model description 4.10.4.1 General This subclause summarizes the system setup and operation of an RSNA in an IBSS. An IBSS RSNA is specified in 12.6.11. 4.10.4.2 Key usage In an IBSS the individually addressed Data frames between two STAs are protected with a pairwise key. The key is part of the PTK, which is derived during a 4-way handshake. In an IBSS the 4-way handshake can follow IEEE 802.11 authentication of one STA to another. Such authentication might be used by the peer to cause deletion of the PTKSA and Block the Controlled Port, resetting any previous handshake. In an IBSS group addressed Data frames are protected by a key, e.g., named B1, that is generated by the STA transmitting the group addressed frame. To allow other STAs to decrypt group addressed frames, B1 is sent to all of the other STAs in the IBSS. B1 is sent in an EAPOL-Key frame, encrypted under the EAPOL- Key encryption key (KEK) portion of the PTK, and protected from modification by the EAPOL-Key confirmation key (KCK) portion of the PTK. In an IBSS the SME responds to Deauthentication frames from a STA by deleting the PTKSA associated with that STA. 4.10.4.3 Sample IBSS 4-way handshakes In this example (see Figure 4-30), there are three STAs: S1, S2, S3. The group addressed frames sent by S1 are protected by B1; similarly B2 for S2, and B3 for S3. For STAs S2 and S3 to decrypt group addressed frames from S1, B1 is sent to S2 and S3. This is done using the 4-way handshake initially and using the group key handshake for GTK updates. The 4-way handshake from S1 to S2 allows S1 to send group addressed frames to S2, but does not allow S2 to send group addressed frames to S1 because S2 has a different transmit GTK. Therefore, S2 needs to initiate a 4-way handshake to S1 to allow S1 to decrypt S2â€™s group addressed frames. Similarly, S2 also needs to initiate a 4-way handshake to S3 to enable S3 to receive group addressed frames from S2. In a similar manner S3 needs to complete the 4-way handshake with S1 and S2 to deliver B3 to S1 and S2. In this example, there are six 4-way handshakes. In general, N Supplicants require N(Nâ€“1) 4-way handshakes. 241 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Figure 4-30â€”Sample 4-way handshakes in an IBSS NOTEâ€”In principle the KCK and KEK from a single 4-way handshake can be used for the group key handshake in both directions, but using two 4-way handshakes means the Authenticator key state machine does not need to be different between IBSS and ESS. The group key handshake can be used to send the GTKs to the correct STAs. The 4-way handshake is used to derive the pairwise key and to send the initial GTK. Because in an IBSS there are two 4-way handshakes between any two Supplicants and Authenticators, the pairwise key used between any two STAs is from the 4-way handshake initiated by the STA Authenticator with the higher MAC address (see 12.7.1 for the notion of address comparison). The KCK and KEK used for a group key handshake are the KCK and KEK derived by the 4-way handshake initiated by the same Authenticator that is initiating the group key handshake. In an IBSS a secure link exists between two STAs when both 4-way handshakes have completed successfully. The Supplicant and Authenticator 4-way handshake state machines interact so the IEEE 802.1X variable portValid is not set to 1 until both 4-way handshakes complete. If a fourth STA comes within range and its SME decides to initiate a security association with the three peers, its Authenticator initiates 4-way handshakes with each of the other three Supplicants. Similarly, the original three STA Authenticators in the IBSS need to initiate 4-way handshakes to the fourth STA Supplicant. A STA learns that a peer STA is RSNA-enabled and the peerâ€™s security policy (e.g., whether the Authentication and Key Management Protocol (AKMP) is SAE, PSK, or IEEE 802.1X authentication) from the Beacon or Probe Response frame. The initiation might start for a number of reasons: a) The fourth STA receives a Beacon or Probe Response frame from a MAC address with which it has not completed a 4-way handshake. b) An SME receives an MLME-PROTECTEDFRAMEDROPPED.indication primitive from a MAC address with which it has not completed a 4-way handshake. This could be a group addressed Data frame transmitted by any of the STAs. In order to set up a security association to the peer STA, an SME that does not know the security policy of the peer can send a Probe Request frame to the peer STA to find its security policy before setting up a security association to the peer STA. c) An SME receives message 1 of the 4-way handshake sent to a STA because the initiator received a broadcast Data frame, Beacon frame, or Probe Response frame from that STA. In order to set up a security association to the peer STA, a STA that received a 4-way handshake but does not know the security policy of the peer can send a Probe Request frame to the peer STA to find its security policy before setting up a security association to the peer STA. 242 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 4.10.4.4 IBSS IEEE 802.1X example When IEEE 802.1X authentication is used, each STA needs to include an IEEE 802.1X Authenticator and AS. A STA learns that a peer STA is RSNA-enabled and the peerâ€™s security policy (e.g., whether the AKMP is PSK or IEEE 802.1X authentication) from the Beacon or Probe Response frame. Each Supplicant sends an EAPOL-Start frame to every other STA to which it intends to authenticate, and each STAâ€™s Authenticator responds with the identity of the credential it intends to use. The EAPOL-Start and EAP-Request/Identity messages are initiated when a protected Data frame (indicated via an MLME-PROTECTEDFRAMEDROPPED.indication primitive), an IEEE 802.1X message, Beacon frame, or Probe Response frame is received from a MAC address with which the STA has not completed IEEE 802.1X authentication. In order to set up a security association to the peer STA, an SME that does not know the security policy of the peer can send a Probe Request frame to the peer STA to find its security policy before setting up a security association to the peer STA. Although Figure 4-31 shows the two IEEE 802.1X exchanges serialized, they might occur interleaved. S1 S2 EAPOL-Start Request/Identity EAP-Response/Identity EAP Authentication EAP Success 4-way handshake EAPOL-Start Request/Identity EAP-Response/Identity EAP Authentication EAP Success 4-way handshake Figure 4-31â€”Example using IEEE 802.1X authentication 243 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 4.10.5 PBSS functional model description This subclause summarizes the system setup and operation of an RSNA in a PBSS. If a non-PCP STA chooses to associate with the PCP of the PBSS, the non-PCP STA establishes an RSNA with the PCP following the infrastructure functional model as specified in 4.10.3. If a non-PCP STA wants to establish an RSNA with the PCP without association or if the non-PCP STA wants to establish an RSNA with another non-PCP STA, it can directly initiate an RSNA authentication with the peer STA, followed by a 4-way handshake. One difference between this model and the IBSS functional model is that only one RSNA authentication and one 4-way handshake are performed between two STAs. If both STAs initiate an RSNA setup at the same time, the RSNA setup initiated by the STA with the lower MAC address is carried through, while the RSNA setup initiated by the STA with the higher MAC address is terminated. Figure 4-32 shows an example of the RSNA setup in a PBSS. An initiator STA discovers a peer STAâ€™s RSNA policies through the DMG Beacons from the peer STA if the peer STA is the PCP or through the Probe Response or Information Response frames from the peer STA. In this example, the initiator STA does not associate with the peer STA. The initiator STA performs RSNA authentication with the peer STA to derive a PMK. A 4-way handshake is then started to complete the RSNA setup. Initiator STA Peer STA Unassociated Unassociated DMG Beacon (DMG Privacy = 1) Probe/Information Request Probe/Information Response (RSN IE) RSNA Authentication Message 1 Message 2 (RSN IE) Message 3 (RSN IE, GTK) Message 4 RSNA RSNA established established Figure 4-32â€”Example of RSNA setup in a PBSS 244 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 4.10.6 Authenticator-to-AS protocol The Authenticator-to-AS authentication definition is out of the scope of this standard, but, to provide security assurances, the protocol needs to support the following functions: a) Mutual authentication between the Authenticator and AS b) A channel for the Supplicant/AS authentication c) The ability to pass the generated key from the AS to the Authenticator in a manner that provides authentication of the key source, preserves integrity of the key transfer, and preserves data confidentiality of the key from all other parties Suitable protocols include, but are not limited to, remote authentication dial-in user service (RADIUS) (IETF RFC 2865 [B33]) and Diameter (IETF RFC 3588 [B40]). 4.10.7 PMKSA caching The Authenticator and Supplicant can cache PMKSAs, which include the IEEE 802.1X state. A PMKSA can be deleted from the cache for any reason and at any time. The STA can supply a list of PMK identifiers in the (Re)Association Request frame. Each key identifier names a PMKSA; the PMKSA can contain a single PMK. The Authenticator specifies the selected PMK identifier in message 1 of the 4-way handshake. The selection of the key identifiers to be included within the (Re)Association Request frame and message 1 of the 4-way handshake is out of the scope of this standard. 4.10.8 Protection of group addressed robust Management frames When management frame protection is negotiated, all group addressed robust Management frames are encapsulated using the procedures defined in 11.13. This service provides integrity protection of group addressed robust Management frames using BIP. 245 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 5. MAC service definition 5.1 Overview of MAC services 5.1.1 Data service 5.1.1.1 General This service provides peer LLC sublayer entities with the ability to exchange MSDUs. To support this service, the local MAC uses the underlying PHY-level services to transport an MSDU to a peer MAC entity, where it is delivered to the peer LLC sublayer. Such asynchronous MSDU transport is performed on a connectionless basis. By default, MSDU transport is on a best-effort basis. However, the QoS facility uses a traffic identifier (TID) to specify differentiated services on a per-MSDU basis. The QoS facility also permits more synchronous behavior to be supported on a connection-oriented basis using TSPECs. There are no guarantees that the submitted MSDU will be delivered successfully. Group addressed transport is part of the data service provided by the MAC. Due to the characteristics of the WM, group addressed MSDUs might experience a lower QoS, compared to that of individually addressed MSDUs. All STAs support the data service, but only QoS STAs in a QoS BSS differentiate their MSDU delivery according to the designated traffic category or traffic stream (TS) of individual MSDUs. QoS STAs that support the QMF service differentiate their MMPDU delivery according to the MMPDUâ€™s access category. The access category of each MMPDU is designated by the transmitterâ€™s current QMF policy. Because operation of certain functions of the MAC can cause reordering of some MSDUs, as discussed in more detail below, in non-QoS STAs, there are two service classes within the data service. By selecting a class, each LLC sublayer entity initiating the transfer of MSDUs is able to control whether MAC entities are or are not allowed to reorder those MSDUs. There are two service classes available in a QoS STA: QoSAck and QoSNoAck. The service classes are used to signal if the MSDU is to be transmitted with or without using the MAC-level acknowledgment. In QoS STAs either associated in a BSS or having membership in an IBSS, the MAC uses a set of rules that tends to cause higher UP MSDUs in a BSS to be sent before lower UP MSDUs in the BSS. The MAC sublayer entities determine the UPs for MSDUs based on the TID values provided with those MSDUs. If a TSPEC has been provided for a TS, via the MAC sublayer management entity, the MAC attempts to deliver MSDUs belonging to that TS in accordance with the QoS parameter values contained in the TSPEC. In a BSS with some STAs supporting the QoS facility and others not supporting the QoS facility, in delivering an MSDU to a non-QoS STA, the QoS STA uses the access category (AC) corresponding to the UP of the MSDU. 5.1.1.2 Determination of UP The QoS facility supports eight priority values, referred to as UPs. The values a UP may take are the integer values from 0 to 7 and are identical to the IEEE 802.1Dâ„¢ priority tags. An MSDU with a particular UP is said to belong to a traffic category (TC) with that UP. The UP is provided with each MSDU at the medium access control service access point (MAC SAP) either directly, in the UP parameter, or indirectly, in a TSPEC or SCS Descriptor element designated by the UP parameter. 5.1.1.3 Interpretation of priority parameter in MAC service primitives The value of the priority parameter in the MAC service primitives (see 5.2) may be a noninteger value of either Contention or ContentionFree or may be any integer value in the range 0 to 15. When the priority parameter has an integer value, it is used in the TID subfields that appear in certain frames that are used to deliver and to control the delivery of QoS data across the WM. 246 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Priority parameter and TID subfield values 0 to 7 are interpreted as UPs for the MSDUs. Outgoing MSDUs with UP values 0 to 7 are handled by MAC entities at STAs in accordance with the UP. Priority parameter and TID subfield values 8 to 15 specify TIDs that are also TS identifiers (TSIDs) and select the TSPEC for the TS designated by the TID. Outgoing MSDUs with priority parameter values 8 to 15 are handled by MAC entities at STAs in accordance with the UP value determined from the UP subfield as well as other parameter values in the selected TSPEC. When an MSDU arrives with a priority value between 8 and 15 and for which there is no TSPEC defined, then the MSDU shall be sent with priority parameter set to 0. The noninteger values of the priority parameter are allowed at all non-QoS STAs. The use of priority value of ContentionFree is deprecated at QoS STAs. The integer values of the priority parameter (i.e., TID) are supported only at QoS STAs that are in a QoS BSS. A range of 0 to 15 is supported by QoS STAs associated in a QoS BSS; whereas a range of 0 to 7 is supported by QoS STAs that are members of a QoS IBSS. If a QoS STA is associated in a non-QoS BSS, the STA is functioning as a non-QoS STA, so the priority value is always Contention or ContentionFree. At QoS STAs associated in a QoS BSS, MSDUs with a priority of Contention are considered equivalent to MSDUs with TID 0, and those with a priority of ContentionFree are delivered using the contention free delivery if a point coordinator (PC) is present in the AP. If a PC is not present, MSDUs with a priority of ContentionFree shall be delivered using an UP of 0. At STAs associated in a non-QoS BSS, all MSDUs with an integer priority are considered equivalent to MSDUs with a priority of Contention. The received individually addressed frames at a QoS STA may be as follows: a) Non-QoS subtypes, in which case the STA shall assign to them a priority of Contention, if they are received during the contention period (CP), or ContentionFree, if they are received during the contention free period (CFP). b) QoS subtypes, in which case the STA shall infer the UP value from the TID in the QoS Control field directly for TID values between 0 and 7. For TID values between 8 and 15 the STA shall extract the UP value in the UP subfield of the TS Info field in the associated TSPEC or from the UP field in the associated TCLAS (traffic classification) element, as applicable. QoS APs deliver the UP with the received MSDUs to the DS. 5.1.1.4 Interpretation of service class parameter in MAC service primitives in a STA In QoS STAs, the value of the service class parameter in the MAC service primitive (see 5.2) may be a noninteger value of QoSAck or QoSNoAck. When an MSDU is received from the MAC SAP with one of the following service class indications, and the recipient STA is a QoS STA: â€” QoSAck, the MSDU is transmitted using one or more QoS Data frame(s) with the Ack Policy subfield in the QoS Control field set to Normal Ack or Implicit Block Ack Request, PSMP Ack, or Block Ack. â€” QoSNoAck, the MSDU is transmitted using one or more QoS Data frame(s) with the Ack Policy subfield in the QoS Control field set to No Ack. When an MSDU is received from the MAC SAP and the recipient STA is not a QoS STA, the MSDU is transmitted using one or more non-QoS Data frame(s). When a QoS Data frame is received from another STA, the service class parameter in the MA-UNITDATA.indication primitive is set to â€” QoSAck, if the frame is a QoS Data frame with the Ack Policy subfield in the QoS Control field equal to either Normal Ack or Block Ack. 247 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” QoSAck, if the frame was delivered via the DMS or the GCR block ack retransmission policy. â€” QoSNoAck, if the frame is a QoS Data frame with the Ack Policy subfield in the QoS Control field equal to No Ack. This service class is also used when the DA parameter is a group address unless the frame was delivered via DMS or the GCR block ack retransmission policy. When a non-QoS Data frame is received from a STA, the service class parameter in the MA-UNITDATA.indication primitive is set to â€” QoSAck, if the frame is an individually addressed frame and is acknowledged by the STA. â€” QoSNoAck, if the frame is a group addressed frame and is not acknowledged by the STA. 5.1.2 Security services Security services in IEEE Std 802.11 are provided by the authentication service and the CCMP, GCMP, and BIP mechanisms. The scope of the security services provided is limited to station-to-station data and robust Management frame transmissions. When CCMP or GCMP is used, the data confidentiality service is provided for Data frames and individually addressed robust Management frames. For the purposes of this standard, CCMP, GCMP, and BIP are viewed as logical services located within the MAC sublayer as shown in the reference model, Figure 4-19 (in 4.9). Actual implementations of CCMP, GCMP, and BIP are transparent to the LLC sublayer and other layers above the MAC sublayer. The security services provided by CCMP and GCMP in IEEE Std 802.11 are as follows: a) Data Confidentiality; b) Authentication; and c) Access control in conjunction with layer management. BIP provides message integrity and access control for group addressed robust Management frames. During the authentication exchange, both parties exchange authentication information as described in Clause 12 and Clause 13. The MAC sublayer security services provided by CCMP, GCMP, and BIP rely on information from non MAC sublayer management or system entities. Management entities communicate information to CCMP, GCMP, and BIP through a set of MAC sublayer management entity (MLME) interfaces and MIB attributes; in particular, the decision tree for CCMP, GCMP, and BIP defined in 12.9 is driven by MIB attributes. The use of WEP for confidentiality, authentication, or access control is deprecated. The WEP algorithm is unsuitable for the purposes of this standard. The use of TKIP is deprecated. The TKIP algorithm is unsuitable for the purposes of this standard. A STA that has associated with management frame protection enabled shall not use pairwise cipher suite selectors WEP-40, WEP-104, TKIP, or â€œUse group cipher suite.â€ A mesh STA with dot11MeshSecurityActivated equal to true shall not use the pairwise cipher suite selectors WEP-40, WEP-104, or TKIP. 5.1.3 MSDU ordering The services provided by the MAC sublayer permit, and might in certain cases require, the reordering of MSDUs. In a non-QoS STA, the MAC does not intentionally reorder MSDUs except as might be necessary to improve the likelihood of successful delivery based on the current operational (â€œpower management,â€ FMS, DMS) mode of the designated recipient STA(s). The sole effect of this reordering (if any), for the set of 248 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MSDUs received at the MAC service interface of any single STA, is a change in the delivery order of group addressed MSDUs, relative to individually addressed MSDUs, originating from a single source STA address. If a higher layer protocol using the data service cannot tolerate this possible reordering, the optional StrictlyOrdered service class can be used. MSDUs transferred between any pair of STAs using the StrictlyOrdered service class are not subject to the relative reordering that is possible when the ReorderableGroupAddressed service class is used. However, the ability to receive MSDUs sent using the StrictlyOrdered service class precludes simultaneous use of the MAC power management facilities at that STA. Note that the use of the StrictlyOrdered service class is obsolete and the StrictlyOrdered service class might be removed in a future revision of the standard. The MSDUs are reordered, not only to improve the likelihood of successful delivery based on the current operational mode of the designated recipient STA(s), but also to honor the priority parameters, specified in the MA-UNITDATA.request primitive, of the individual MSDUs. The effects of this reordering (if any), for the set of MSDUs received at the MAC service interface of any single STA, are: a) A change in the delivery order of group addressed MSDUs, relative to individually addressed MSDUs, and b) The reordering of MSDUs with different TID values, originating from a single source STA address. There shall be no reordering of individually addressed MSDUs with the same TID value and addressed to the same destination. STAs operating in a non-QoS BSS shall follow the reordering rules as defined for a non-QoS STA. In order for the MAC to operate properly, this standard assumes that the DS meets the MSDU (â€œobjectâ€) reordering requirements of IEEE Std 802.1ACâ„¢-2012 [B22]. Operational restrictions that provide the appropriate ordering of MSDUs are specified in 10.8. When MSDU or A-MSDU reordering is performed, the information in the MAC service tuple(s) for the MSDU(s) shall be maintained and reordered as a unit. 5.1.4 MSDU format Logical Link Control (LLC) sublayer entities use the MAC sublayer service to exchange PDUs with peer LLC sublayer entities. These PDUs are termed MAC sublayer SDUs (MSDUs) when sent to the MAC sublayer. There are two LLC sublayer protocols used (see IEEE Std 802-2014); LLC Protocol Discrimination (LPD) (see ISO/IEC 8802-2:1998) and EtherType Protocol Discrimination (EPD) (see IEEE Std 802.3-2012). LPD is used for transmission of all IEEE 802.11 MSDUs with the exception of the 5.9 GHz bands where EPD is used (see E.2.3 and E.2.4). When LPD is used, in order to achieve interoperability, implementers are recommended to apply the procedures described in ISO/IEC Technical Report 11802-5:1997 (previously known as IEEE Std 802.1H- 1997 [B24]), along with a selective translation table (STT) that handles a few specific network protocols, with specific attention to the operations required when passing MSDUs to or from LANs or operating system components that use the Ethernet frame format (EPD). Note that such translations might be required in a STA. 249 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 5.1.5 MAC data service architecture 5.1.5.1 General The MAC data plane architecture (i.e., processes that involve transport of all or part of an MSDU) is shown in Figure 5-1 when transparent FST is not being used and shown in Figure 5-2 when transparent FST is being used. The dotted line box labeled â€œRole-specific behaviorsâ€ is replaced by one of several options, depending on the role of the STA. See the following subclauses During transmission, an MSDU goes through some or all of the following processes: MSDU rate limiting, aggregate MSDU (A-MSDU) aggregation, frame delivery deferral during power save mode, sequence number assignment, integrity protection, fragmentation, encryption, frame formatting, and aggregate MAC protocol data unit (A-MPDU) aggregation. When transparent FST is used, an MSDU first goes through an additional transparent FST entity that contains a demultiplexing process that forwards the MSDU down to the selected TX MSDU Rate Limiting process, and thence MAC data plane processing as described in the previous sentence. IEEE Std 802.1X-2010 may block the MSDU at the Controlled Port before the preceding processing occurs. Otherwise, at some point, the Data frames that contain all or part of the MSDU are queued per AC/TS. During reception, a received Data frame goes through processes of possible A-MPDU deaggregation, MPDU header and cyclic redundancy code (CRC) validation, duplicate removal, decryption, possible reordering if the block ack mechanism is used, replay detection, defragmentation, integrity checking, possible A-MSDU deaggregation, and possible MSDU rate limiting. Then, one or more MSDUs are delivered to the MAC SAP or to the DS via the DSAF. When transparent FST is used, MSDUs originating from different PHY SAPs go through a final step of a transparent FST entity that contains a multiplexing process before delivering the MSDU. The IEEE 802.1X Controlled/Uncontrolled Ports discard any received MSDU if the Controlled Port is not enabled and if the MSDU does not represent an IEEE 802.1X frame. When transparent FST is used, the same security keys, sequence counter, and PN counter are used by the MAC data plane to encrypt the MPDU prior to and following an FST, and the same security keys are used to check the integrity and perform the protection of MSDUs. When nontransparent FST is used, independent RSNAs, security keys, sequence counters, and PN counters have to be established for each MAC data plane to be used prior to and following an FST. When transparent FST is used, a single MAC SAP at each peer is presented to the higher layers of that peer for all of the frequency bands/channels that are identified by the same MAC address at that peer. When nontransparent FST is used, different MAC SAPs are presented to higher layers since different MAC addresses are used prior to and following an FST. 250 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Local 802.1X Higher Upper PAE Layer Layers Entities LPD/EPD LPD/EPD LLC sublayer () () 802.11 For AP role specific behavior this connection is not present Role- specific behavior (M) â€“ MAC SAP (U) â€“ Uncontrolled port (C) - Controlled port (U) (C) IEEE 802.1X Controlled and Uncontrolled Port Filtering (optional) (M) RX/TX MSDU Rate Limiting A-MSDU Aggregation (TX) / De-aggregation (RX) PS Defer Queuing (AP or IBSS STA (null) only) MSDU Flow - Transmitting MSDU Flow â€“ Receiving Sequence Number (null) Assignment MSDU Integrity and Protection (optional) Fragmentation (TX) / Defragmentation (RX) Packet Number Replay Detection Assignment (optional) Block Ack The â€˜MPDU (null) Buffering and Reordering Decryption and Integrity MPDU (optional)â€™ and Encryption (TX) / Decryption (RX) â€˜Block Ack and Integrity (optional) Buffering and Reorderingâ€™ Duplicate (null) processes may Detection be performed in (null) Block Ack either order (RX) Scoreboarding Address 1 address (null) filtering MPDU Header + CRC Creation (TX) / Validation (RX) A-MPDU Aggregation (TX) / De-aggregation (RX) Figure 5-1â€”MAC data plane architecture 251 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Local 802.1X Higher Upper PAE Layer Layers Entities LPD/EPD LPD/EPD LLC sublayer () () 802.11 For AP role specific behavior this connection is not present Role- specific behavior (U) (C) IEEE 802.1X Controlled and Uncontrolled Port Filtering (optional) (M) Transparent FST Entity (M) (M) RX/TX MSDU RX/TX MSDU Rate Limiting Rate Limiting A-MSDU A-MSDU Aggregation (TX) / De-aggregation (RX) Aggregation (TX) / De-aggregation (RX) PS Defer Queuing PS Defer Queuing (AP or IBSS STA (null) (AP or IBSS STA (null) only) only) MSDU Flow - Transmitting MSDU Flow â€“ Receiving Same Sequence Number security Sequence Number (null) (null) Assignment keys Assignment and MSDU Integrity Sequence MSDU Integrity and Protection counter and Protection (optional) (optional) Fragmentation (TX) / Fragmentation (TX) / Defragmentation (RX) Defragmentation (RX) Packet Number Replay Detection Packet Number Replay Detection Assignment (optional) Assignment (optional) Same Block Ack security Block Ack (null) Buffering and keys (null) Buffering and Reordering and Reordering PN MPDU MPDU counters Encryption (TX) / Decryption (RX) Encryption (TX) / Decryption (RX) and Integrity (optional) and Integrity (optional) Duplicate Duplicate (null) (null) Detection Detection Block Ack Block Ack (null) (null) Scoreboarding Scoreboarding Address 1 address Address 1 address (null) (null) filtering filtering MPDU Header + CRC MPDU Header + CRC Creation (TX) / Validation (RX) Creation (TX) / Validation (RX) A-MPDU A-MPDU Aggregation (TX) / De-aggregation (RX) Aggregation (TX) / De-aggregation (RX) PHY in channel 1 PHY in channel 2 Figure 5-2â€”MAC data plane architecture (transparent FST) 252 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 5.1.5.2 Non-AP STA role The MAC data plane architecture of a non-AP STA is completed by replacing the role-specific behavior block with that shown in Figure 5-3. The function of this block in a non-AP STA is to perform destination address filtering as described in 10.2.8. NOTEâ€”In implementations, the DA address filtering function may be done â€œlower in the stack.â€ It is shown in the role- specific behavior block location for simplicity, and any implementation choice needs to provide equivalent behavior. DA address filtering Figure 5-3â€”Role-specific behavior block for non-AP STA 5.1.5.3 AP role In an AP, the MAC data plane architecture includes distribution system access in its role-specific behavior block, as shown in Figure 5-4.This block provides access to the DS for associated non-AP STAs as described in 4.5.2.1. NOTEâ€”This behavior block indicates that there is no access through the controlled port to or from the local upper-lay- ers (the LLC sublayer) at an AP. Any such access is logically achieved in the architecture via transition of the DS and Portal to an integrated LAN. In actual implementations, this is likely to be optimized, and data frames appear to be deliv- ered directly to one or more local LLC sublayer entities on the same physical device as the AP. Such optimization is effectively distributing the functions of the DS and Portal, and it is the responsibility of the implementation to ensure the logical behavior of these entities is maintained. Other APs/Mesh Gates/ Portal in the ESS DSAF (C) (DSS) * Distribution System (DS) * - DSS service may conceptually be provided by the â€œrecursiveâ€ use of a network stack Figure 5-4â€”Role-specific behavior block for AP 5.1.5.4 Mesh STA role The MAC data plane architecture of a mesh STA is completed by replacing the role-specific behavior block with that shown in Figure 5-5. The function of this block in a mesh STA is described in Figure 10.35. This role is not applicable when transparent FST is used, and does not apply to Figure 5-2. 253 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Path selection function (Local address or Mesh forwarding) Figure 5-5â€”Role-specific behavior block for mesh STA 5.1.5.5 Mesh gate role The MAC data plane architecture of a mesh gate is completed by replacing the role-specific behavior block with that shown in Figure 5-6. The function of this block in a mesh gate is described in 14.11. This role is not applicable when transparent FST is used, and does not apply to Figure 5-2. To local LLC sublayer Other APs/Mesh Gates/ Portal in the ESS DSAF Path selection function (C) (DSS) * Distribution (Local address, DS, or Mesh System (DS) forwarding) * - DSS service may conceptually be provided by the â€œrecursiveâ€ use of a network stack Figure 5-6â€”Role-specific behavior block for mesh gate 5.2 MAC data service specification 5.2.1 General The IEEE 802.11 MAC supports the following service primitives as defined in ISO/IEC 8802-2:1998: â€” MA-UNITDATA.request â€” MA-UNITDATA.indication â€” MA-UNITDATA-STATUS.indication IEEE Std 802.11 places restrictions and semantics on the parameter values for these primitives, as described in 5.2.2 to 5.2.4. 5.2.2 MA-UNITDATA.request 5.2.2.1 Function This primitive requests a transfer of an MSDU from a local LLC sublayer entity to a single peer LLC sublayer entity, or multiple peer LLC sublayer entities in the case of group addresses. 254 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 5.2.2.2 Semantics of the service primitive The parameters of the primitive are as follows: MA-UNITDATA.request( source address, destination address, routing information, data, priority, service class ) The source address (SA) parameter specifies an individual MAC sublayer address of the sublayer entity from which the MSDU is being transferred. The destination address (DA) parameter specifies either an individual or a group MAC sublayer entity address. The routing information parameter specifies the route for the data transfer (a null value indicates source routing is not to be used). For IEEE Std 802.11, the routing information parameter shall be null. The data parameter specifies the MSDU to be transmitted by the MAC sublayer entity. The length of the MSDU shall be less than or equal to the value shown in Table 9-19. The priority parameter specifies the requested priority of the data unit transfer. The allowed values of priority are described in 5.1.1.3. The service class parameter specifies the requested service class of the data unit transfer. The allowed values of service class are described in 5.1.1.4 and 5.1.3. 5.2.2.3 When generated This primitive is generated by the LLC sublayer entity when an MSDU is to be transferred to a peer LLC sublayer entity or entities. 5.2.2.4 Effect of receipt On receipt of this primitive, the MAC sublayer entity determines whether it is able to fulfill the request according to the requested parameters. A request that cannot be fulfilled according to the requested parameters is discarded, and this action is indicated to the LLC sublayer entity using an MA-UNITDATA- STATUS.indication primitive that describes why the MAC was unable to fulfill the request. If the request can be fulfilled according to the requested parameters, the MAC sublayer entity properly formats a frame and passes it to the lower layers for transfer to a peer MAC sublayer entity or entities (see 5.1.4), and indicates this action to the LLC sublayer entity using an MA-UNITDATA-STATUS.indication primitive with transmission status set to Successful. At an AP for which dot11SSPNInterfaceActivated is true, upon receipt of an MA-UNITDATA.request primitive having an individually addressed destination address and a priority of Contention or ContentionFree, the APâ€™s MAC sublayer shall perform rate limiting to enforce the resource utilization limit in dot11NonAPStationMaxAuthBestEffortRate in the dot11InterworkingEntry identified by the destination MAC address of the frame to be transmitted. The specific mechanism to perform rate limiting is outside the scope of this standard. â€” If the rate limiting mechanism does not discard the frame, then dot11NonAPStationBestEffort- MSDUCount shall be incremented by 1 and dot11NonAPStationBestEffortOctetCount shall be incremented by the number of octets in the MSDU. 255 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” If the rate limiting mechanism discards the frame, then dot11NonAPStationDroppedBestEffort- MSDUCount shall be incremented by 1 and dot11NonAPStationDroppedBestEffortOctetCount shall be incremented by the number of octets in the MSDU. At an AP for which dot11SSPNInterfaceActivated is true, upon receipt of an MA-UNITDATA.request primitive having an individually addressed destination address for which the priority is an integer in the range 0 to 7, then the APâ€™s MAC sublayer shall derive the access category from the priority using the mapping in Table 10-1. The APâ€™s MAC sublayer shall retrieve the MIB variables listed below from the dot11InterworkingEntry identified by the destination MAC address of the frame to be transmitted and perform the following operations: â€” If the access category is AC_VO, then the APâ€™s MAC sublayer shall perform rate limiting to enforce the resource utilization limit in dot11NonAPStationMaxAuthVoiceRate; the specific mechanism to perform rate limiting is outside the scope of this standard. If the rate limiting mechanism does not discard the frame, then dot11NonAPStationVoiceMSDUCount shall be incremented by 1 and dot11NonAPStationVoiceOctetCount shall be incremented by the number of octets in the MSDU. If the rate limiting mechanism discards the frame, then dot11NonAPStationDroppedVoiceMSDU- Count shall be incremented by 1 and dot11NonAPStationDroppedVoiceOctetCount shall be incremented by the number of octets in the MSDU. â€” If the access category is AC_VI, then the APâ€™s MAC sublayer shall perform rate limiting to enforce the resource utilization limit in dot11NonAPStationMaxAuthVideoRate; the specific mechanism to perform rate limiting is outside the scope of this standard. If the rate-limiting mechanism does not discard the frame, then dot11NonAPStationVideoMSDUCount shall be incremented by 1 and dot11NonAPStationVideoOctetCount shall be incremented by the number of octets in the MSDU. If the rate limiting mechanism discards the frame, then dot11NonAPStationDroppedVideoMSDU- Count shall be incremented by 1 and dot11NonAPStationDroppedVideoOctetCount shall be incremented by the number of octets in the MSDU. â€” If the access category is AC_BE, then the APâ€™s MAC sublayer shall perform rate limiting to enforce the resource utilization limit in dot11NonAPStationMaxAuthBestEffortRate; the specific mechanism to perform rate limiting is outside the scope of this standard. If the rate-limiting mechanism does not discard the frame, then dot11NonAPStationBestEffortMSDUCount shall be incremented by 1 and dot11NonAPStationBestEffortOctetCount shall be incremented by the number of octets in the MSDU. If the rate limiting mechanism discards the frame, then dot11NonAPStationDroppedBestEffortMSDUCount shall be incremented by 1 and dot11NonAPStationDroppedBestEffortOctetCount shall be incremented by the number of octets in the MSDU. â€” If the access category is AC_BK, then the APâ€™s MAC sublayer shall perform rate limiting to enforce the resource utilization limit in dot11NonAPStationMaxAuthBackgroundRate; the specific mechanism to perform rate limiting is outside the scope of this standard. If the rate-limiting mechanism does not discard the frame, then dot11NonAPStationBackgroundMSDUCount shall be incremented by 1 and dot11NonAPStationBackgroundOctetCount shall be incremented by the number of octets in the MSDU. If the rate limiting mechanism discards the frame, then dot11NonAPStationDroppedBackgroundMSDUCount shall be incremented by 1 and dot11NonAPStationDroppedBackgroundOctetCount shall be incremented by the number of octets in the MSDU. At an AP for which dot11SSPNInterfaceActivated is true, upon receipt of an MA-UNITDATA.request primitive having an individually addressed destination address whose priority is an integer in the range 8 to 15, then the APâ€™s MAC sublayer shall perform rate limiting to enforce the resource utilization limit in dot11NonAPStationAuthMaxHCCAHEMMRate; the specific mechanism to perform rate limiting is outside the scope of this standard. â€” If the rate-limiting mechanism does not discard the frame, then dot11NonAPStationHCCAHEMM- MSDUCount shall be incremented by 1, and dot11NonAPStationHCCAHEMMOctetCount shall be incremented by the number of octets in the MSDU. 256 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” If the rate limiting mechanism discards the frame, then dot11NonAPStationDroppedHCCAHEMM- MSDUCount shall be incremented by 1 and dot11NonAPStationDroppedHCCAHEMMOctetCount shall be incremented by the number of octets in the MSDU. 5.2.3 MA-UNITDATA.indication 5.2.3.1 Function This primitive defines the transfer of an MSDU from the MAC sublayer entity to the LLC sublayer entity, or entities in the case of group addresses. In the absence of error, the contents of the data parameter are logically complete and unchanged relative to the data parameter in the associated MA-UNITDATA.request primitive. 5.2.3.2 Semantics of the service primitive The parameters of the primitive are as follows: MA-UNITDATA.indication( source address, destination address, routing information, data, reception status, priority, service class ) The SA parameter is an individual address as specified by the SA field of the incoming frame. The DA parameter is either an individual or a group address as specified by the DA field of the incoming frame. The routing information parameter specifies the route that was used for the data transfer. The MAC sublayer entity shall set this field to null. The data parameter specifies the MSDU as received by the local MAC entity. The reception status parameter indicates the success or failure of the received frame. The MAC always reports â€œsuccessâ€ because all failures of reception are discarded without generating MA- UNITDATA.indication primitive. The priority parameter specifies the receive processing priority that was used for the data unit transfer. The allowed values of priority are described in 5.1.1.3. The service class parameter specifies the receive service class that was used for the data unit transfer. The allowed values of service class are described in 5.1.1.4 and 5.1.3. 5.2.3.3 When generated The MA-UNITDATA.indication primitive is passed from the MAC sublayer entity to the LLC sublayer entity or entities to indicate the arrival of a frame at the local MAC sublayer entity. Frames are reported only if they are validly formatted at the MAC sublayer, received without error, received with valid (or null) security and integrity information, and their destination address designates the local MAC sublayer entity. 257 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 5.2.3.4 Effect of receipt The effect of receipt of this primitive by the LLC sublayer is dependent on the content of the MSDU. At an AP for which dot11SSPNInterfaceActivated is true, upon receipt of a frame with the Type subfield equal to Data having a group DA, the APâ€™s MAC sublayer shall discard the frame if dot11NonAPStationAuthSourceMulticast is false in the dot11InterworkingEntry identified by the source MAC address of the received frame. If dot11NonAPStationAuthSourceMulticast is true, the APâ€™s MAC sublayer shall perform rate limiting to enforce the resource utilization limit in dot11NonAPStationAuthMaxSourceMulticastRate in the dot11InterworkingEntry identified by the source MAC address of the received frame. The specific mechanism to perform rate limiting is outside the scope of this standard. â€” If the rate limiting mechanism does not discard the frame, then dot11NonAPStationMulticast- MSDUCount shall be incremented by 1 and dot11NonAPStationMulticastOctetCount shall be incremented by the number of octets in the MSDU. â€” If the rate limiting mechanism discards the frame, then dot11NonAPStationDroppedMulticast- MSDUCount. shall be incremented by 1 and dot11NonAPStationDroppedMulticastOctetCount. shall be incremented by the number of octets in the MSDU. At an AP for which dot11SSPNInterfaceActivated is true, upon receipt of an individually addressed frame with the Type subfield equal to Data and a priority of Contention or ContentionFree, then the APâ€™s MAC sublayer shall perform rate limiting to enforce the resource utilization limit in dot11NonAPStationMaxAuthBestEffortRate in the dot11InterworkingEntry identified by the source MAC address of the received frame. The specific mechanism to perform rate limiting is outside the scope of this standard. â€” If the rate limiting mechanism does not discard the frame, then dot11NonAPStationBestEffort- MSDUCount shall be incremented by 1 and dot11NonAPStationBestEffortOctetCount shall be incremented by the number of octets in the MSDU. â€” If the rate limiting mechanism discards the frame, then dot11NonAPStationDroppedBestEffort- MSDUCount shall be incremented by 1 and dot11NonAPStationDroppedBestEffortOctetCount shall be incremented by the number of octets in the MSDU. At an AP for which dot11SSPNInterfaceActivated is true, upon receipt of an individually addressed frame with the Type subfield equal to Data, for which the priority is an integer in the range 0 to 7, then the APâ€™s MAC sublayer shall derive the access category from the priority using the mapping in Table 10-1. The APâ€™s MAC sublayer shall retrieve the MIB variables from the dot11InterworkingEntry identified by the source MAC address of the received frame and perform the following operations: â€” If the access category is AC_VO, then the APâ€™s MAC sublayer shall perform rate limiting to enforce the resource utilization limit in dot11NonAPStationMaxAuthVoiceRate; the specific mechanism to perform rate limiting is outside the scope of this standard. If the rate-limiting mechanism does not discard the frame, then dot11NonAPStationVoiceMSDUCount shall be incremented by 1 and dot11NonAPStationVoiceOctetCount shall be incremented by the number of octets in the MSDU. If the rate limiting mechanism discards the frame, then dot11NonAPStationDroppedVoiceMSDU- Count shall be incremented by 1 and dot11NonAPStationDroppedVoiceOctetCount shall be incremented by the number of octets in the MSDU. â€” If the access category is AC_VI, then the APâ€™s MAC sublayer shall perform rate limiting to enforce the resource utilization limit in dot11NonAPStationMaxAuthVideoRate; the specific mechanism to perform rate limiting is outside the scope of this standard. If the rate-limiting mechanism does not discard the frame, then dot11NonAPStationVideoMSDUCount shall be incremented by 1 and dot11NonAPStationVideoOctetCount shall be incremented by the number of octets in the MSDU. If the rate limiting mechanism discards the frame, then dot11NonAPStationDroppedVideoMSDU- Count shall be incremented by 1 and dot11NonAPStationDroppedVideoOctetCount shall be incremented by the number of octets in the MSDU. 258 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” If the access category is AC_BE, then the APâ€™s MAC sublayer shall perform rate limiting to enforce the resource utilization limit in dot11NonAPStationMaxAuthBestEffortRate; the specific mechanism to perform rate limiting is outside the scope of this standard. If the rate-limiting mechanism does not discard the frame, then dot11NonAPStationBestEffortMSDUCount shall be incremented by 1 and dot11NonAPStationBestEffortOctetCount shall be incremented by the number of octets in the MSDU. If the rate limiting mechanism discards the frame, then dot11NonAPStationDroppedBestEffortMSDUCount shall be incremented by 1 and dot11NonAPStationDroppedBestEffortOctetCount shall be incremented by the number of octets in the MSDU. â€” If the access category is AC_BK, then the APâ€™s MAC sublayer shall perform rate limiting to enforce the resource utilization limit in dot11NonAPStationMaxAuthBackgroundRate; the specific mechanism to perform rate limiting is outside the scope of this standard. If the rate-limiting mechanism does not discard the frame, then dot11NonAPStationBackgroundMSDUCount shall be incremented by 1 and dot11NonAPStationBackgroundOctetCount shall be incremented by the number of octets in the MSDU. If the rate limiting mechanism discards the frame, then dot11NonAPStationDroppedBackgroundMSDUCount shall be incremented by 1 and dot11NonAPStationDroppedBackgroundOctetCount shall be incremented by the number of octets in the MSDU. At an AP for which dot11SSPNInterfaceActivated is true, upon receipt of an individually addressed frame with the Type subfield equal to Data for which the priority is an integer in the range 8 to 15, the APâ€™s MAC sublayer shall perform rate limiting to enforce the resource utilization limit in dot11NonAPStationAuthMaxHCCAHEMMRate; the specific mechanism to perform rate limiting is outside the scope of this standard. â€” If the rate-limiting mechanism does not discard the frame, then dot11NonAPStationHCCAHEMM- MSDUCount shall be incremented by 1, and dot11NonAPStationHCCAHEMMOctetCount shall be incremented by the number of octets in the MSDU. â€” If the rate limiting mechanism discards the frame, then dot11NonAPStationDroppedHCCAHEMM- MSDUCount shall be incremented by 1 and dot11NonAPStationDroppedHCCAHEMMOctetCount shall be incremented by the number of octets in the MSDU. 5.2.4 MA-UNITDATA-STATUS.indication 5.2.4.1 Function This primitive has local significance and provides the LLC sublayer with status information for the corresponding preceding MA-UNITDATA.request primitive. 5.2.4.2 Semantics of the service primitive The parameters of the primitive are as follows: MA-UNITDATA-STATUS.indication( source address, destination address, transmission status, provided priority, provided service class ) The SA parameter is an individual MAC sublayer entity address as specified in the associated MA- UNITDATA.request primitive. 259 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The DA parameter is either an individual or group MAC sublayer entity address as specified in the associated MA-UNITDATA.request primitive. The transmission status parameter is used to pass status information back to the local requesting LLC sublayer entity. IEEE Std 802.11 specifies the following values for transmission status: a) Successful. b) Undeliverable (excessive data length). c) Undeliverable (non-null source routing). d) Undeliverable: unsupported priority (for priorities other than Contention or ContentionFree at a non- QoS STA; or for priorities other than Contention, ContentionFree, or an integer in the range 0 to 15 at a QoS STA). e) Undeliverable: unsupported service class (for service classes other than ReorderableGroupAddressed or StrictlyOrdered for non-QoS STAs and service classes other than QoSAck or QoSNoAck for QoS STAs). f) Unavailable priority (for ContentionFree when no PC or HC is available, or an integer in the range 1 to 15 at a STA that is associated in a non-QoS BSS, or an integer in the range 8 to 15 at a STA that is a member of an IBSS, in which case the MSDU is transmitted with a provided priority of Contention). g) Undeliverable: unavailable service class (for StrictlyOrdered service when the STAâ€™s power management mode is other than â€œactiveâ€ for non-QoS STAs; QoS STAs do not return this value as they do not provide the StrictlyOrdered service). h) Undeliverable (no BSS available). i) Undeliverable (cannot encrypt with a null key). j) In a STA in which dot11RejectUnadmittedTraffic is true, Undeliverable: unadmitted traffic (for a requested priority in the range 0 to 7 because there is no admitted TS for this priority and admission control is required for the AC). k) In an AP in which dot11SSPNInterfaceActivated is true, Undeliverable (violation of limit specified by dot11NonAPStationMaxAuthVoiceRate in the dot11InterworkingTable for the non-AP STA identified by the destination address of the MA-UNITDATA.request primitive). l) In an AP in which dot11SSPNInterfaceActivated is true, Undeliverable (violation of limit specified by dot11NonAPStationMaxAuthVideoRate in the dot11InterworkingTable for the non-AP STA identified by the destination address of the MA-UNITDATA.request primitive). m) In an AP in which dot11SSPNInterfaceActivated is true, Undeliverable (violation of limit specified by dot11NonAPStationMaxAuthBestEffortRate in the dot11InterworkingTable for the non-AP STA identified by the destination address of the MA-UNITDATA.request primitive). n) In an AP in which dot11SSPNInterfaceActivated is true, Undeliverable (violation of limit specified by dot11NonAPStationAuthMaxBackgroundRate in the dot11InterworkingTable for the non-AP STA identified by the destination address of the MA-UNITDATA.request primitive). o) In an AP in which dot11SSPNInterfaceActivated is true, Undeliverable (violation of limit specified by dot11NonAPStationAuthMaxHCCAHEMMRate in the dot11InterworkingTable for the non-AP STA identified by the destination address of the MA-UNITDATA.request primitive). If the transmission status parameter is Successful, the provided priority parameter specifies the priority used for the associated data unit transfer (Contention, ContentionFree, or an integer in the range 0 to 15); otherwise the provided priority parameter is not present. If the transmission status parameter is Successful, the provided service class parameter specifies the class of service for the associated data unit transfer; otherwise the provided service class parameter is not present. In non-QoS STAs, the value of this parameter is ReorderableGroupAddressed or StrictlyOrdered. In QoS STAs, it is QoSAck or QoSNoAck. 260 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 5.2.4.3 When generated The MA-UNITDATA-STATUS.indication primitive is passed from the MAC sublayer entity to the LLC sublayer entity to indicate the status of the service provided for the corresponding MA-UNITDATA.request primitive. 5.2.4.4 Effect of receipt The effect of receipt of this primitive by the LLC sublayer is dependent upon the type of operation employed by the LLC sublayer entity. 261 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6. Layer management 6.1 Overview of management model Both the MAC sublayer and PHY conceptually include management entities, called MLME and PLME, respectively. These entities provide the layer management service interfaces through which layer management functions are invoked. In order to provide correct MAC operation, an SME is present within each STA. The SME is a layer- independent entity that resides in a separate management plane or resides â€œoff to the side.â€ Some of the functions of the SME are specified in this standard. Typically this entity is responsible for such functions as the gathering of layer-dependent status from the various layer management entities (LMEs), and similarly setting the value of layer-specific parameters. The SME typically performs such functions on behalf of general system management entities and would implement standard management protocols. Figure 4-19 (in 4.9) depicts the relationship among management entities. The various entities within this model interact in various ways. Certain of these interactions are defined explicitly within this standard, via a SAP across which defined primitives are exchanged. This definition includes the GET and SET operations between MLME, PLME and SME as well as other individually defined service primitives, represented as double arrows within Figure 6-1. Other interactions are not defined explicitly within this standard, such as the interfaces between the MAC and MLME and between the PLME and PHY; the specific manner in which these MAC and PHY LMEs are integrated into the overall MAC sublayer and PHY is not specified within this standard. A STA includes only one instance of a PHY entity. MLME MAC MIB MLME-GET/SET MAC PLME-GET/SET Station Management Entity PHY MIB PLME-GET/SET PHY PLME Figure 6-1â€”GET and SET operations The management SAPs within this model are the following: â€” SME-MLME SAP â€” SME-PLME SAP â€” MLME-PLME SAP The latter two SAPs support identical primitives, and in fact might be viewed as a single SAP (called the PLME SAP) that is used either directly by MLME or by SME. In this fashion, the model reflects what is anticipated to be a common implementation approach in which PLME functions are controlled by the MLME (on behalf of SME). 262 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.2 Generic management primitives The management information specific to each layer is represented as a MIB for that layer. The MLME and PLME are viewed as â€œcontainingâ€ the MIB for that layer. The generic model of MIB-related management primitives exchanged across the management SAPs is to allow the SAP user-entity to either GET the value of a MIB attribute, or to SET the value of a MIB attribute. The invocation of a SET.request primitive might require that the layer entity perform certain defined actions. Figure 6-1 depicts these generic primitives. The GET and SET primitives are represented as REQUESTs with associated CONFIRM primitives. These primitives are prefixed by MLME or PLME depending upon whether the MAC sublayer or PHY management SAP is involved. In the following, XX denotes MLME or PLME: XX-GET.request(MIBattribute) Requests the value of the given MIBattribute. XX-GET.confirm(status, MIBattribute, MIBattributevalue) Returns the appropriate MIB attribute value if status = â€œsuccess,â€ otherwise returns an error indica- tion in the Status field. Possible error status values include â€œinvalid MIB attributeâ€ and â€œattempt to get write-only MIB attribute.â€ XX-SET.request(MIBattribute, MIBattributevalue) Requests that the indicated MIB attribute be set to the given value. If this MIBattribute implies a specific action, then this requests that the action be performed. XX-SET.confirm(status, MIBattribute) If status = â€œsuccess,â€ this confirms that the indicated MIB attribute was set to the requested value; otherwise it returns an error condition in status field. If this MIBattribute implies a specific action, then this confirms that the action was performed. Possible error status values include â€œinvalid MIB attributeâ€ and â€œattempt to set read-only MIB attribute.â€ Additionally, there are certain requests that can be invoked across a given SAP that do not involve the setting or getting of a specific MIB attribute. One of these is supported by each SAP, as follows: â€” XX-RESET.request: where XX is MLME or PLME as appropriate This service is used to initialize the management entities, the MIBs, and the datapath entities. It might include a list of attributes for items to be initialized to nondefault values. Other SAP-specific primitives are identified in 6.3. 6.3 MLME SAP interface 6.3.1 Introduction The services provided by the MLME to the SME are specified in this subclause. These services are described in an abstract way (following the model described in ITU-T Recommendation X.210 [B54]) and do not imply any particular implementation or exposed interface. MLME SAP primitives are of the general form ACTION.request primitive followed by ACTION.confirm primitive (for an exchange initiated by the SAP client) and ACTION.indication primitive followed by ACTION.response primitive (for an exchange initiated by the MLME). The SME uses the services provided by the MLME through the MLME SAP. 263 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.2 Power management 6.3.2.1 Introduction This mechanism supports the process of establishment and maintenance of the power management mode of a STA. 6.3.2.2 MLME-POWERMGT.request 6.3.2.2.1 Function This primitive requests a change in the power management mode. 6.3.2.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-POWERMGT.request( PowerManagementMode, ReceiveDTIMs ) Name Type Valid range Description PowerManagementMode Enumeration ACTIVE, An enumerated type that describes the POWER_SAVE requested power management mode of the STA. ReceiveDTIMs Boolean true, false Non-DMG BSS: When true, this parameter causes the STA to awaken to receive all DTIM frames. When false, the STA is not required to awaken for every DTIM Beacon frame. DMG BSS: Not applicable 6.3.2.2.3 When generated This primitive is generated by the SME to implement the power-saving strategy of an implementation. 6.3.2.2.4 Effect of receipt This request sets the STAâ€™s power management parameters. The MLME subsequently issues an MLME- POWERMGT.confirm primitive that reflects the results of the power management change request. 6.3.2.3 MLME-POWERMGT.confirm 6.3.2.3.1 Function This primitive confirms the change in power management mode. 6.3.2.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-POWERMGT.confirm( ResultCode ) 264 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description ResultCode Enumeration SUCCESS, Indicates the result of the NOT_SUPPORTED MLME-POWERMGT.request primitive. 6.3.2.3.3 When generated This primitive is generated by the MLME as a result of an MLME-POWERMGT.request primitive to establish a new power management mode. It is not generated until the change has completed as defined in 11.2.3. 6.3.2.3.4 Effect of receipt The SME is notified of the change of power management mode. 6.3.3 Scan 6.3.3.1 Introduction This mechanism supports the process of determining the characteristics of the available BSSs. 6.3.3.2 MLME-SCAN.request 6.3.3.2.1 Function This primitive requests a survey of potential BSSs that the STA can later elect to try to join. 6.3.3.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-SCAN.request( BSSType, BSSID, SSID, ScanType, ProbeDelay, ChannelList, MinChannelTime, MaxChannelTime, RequestInformation, SSID List, ChannelUsage, AccessNetworkType, HESSID, MeshID, DiscoveryMode, VendorSpecificInfo ) 265 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description BSSType Enumeration INFRASTRUCTURE, Determines whether infrastructure BSS, PERSONAL, PBSS, IBSS, MBSS, or all, are included INDEPENDENT, in the scan. MESH, ANY_BSS BSSID MACAddress Any valid individual or Identifies a specific or wildcard BSSID. broadcast MAC address SSID Octet string 0â€“32 octets Specifies the desired SSID or the wildcard SSID. ScanType Enumeration ACTIVE, Indicates either active or passive PASSIVE scanning. ProbeDelay Integer N/A Delay (in microseconds) to be used prior to transmitting a Probe frame during active scanning. ChannelList Set of integers Each channel is selected Specifies a list of channels that are from the valid channel examined when scanning for a BSS. range for the appropriate PHY and carrier set. MinChannelTime Integer N/A The minimum time (in TU) to spend on each channel when scanning. MaxChannelTime Integer MinChannelTime The maximum time (in TU) to spend on each channel when scanning. RequestInformation A list of As defined in 9.4.2.10 This parameter is optionally present if (Extended) and 9.4.2.11. dot11RadioMeasurementActivated is true Element IDs and is placed in a Probe Request frame to request that the responding STA include the requested information in the Probe Response frame. SSID List A set of SSID As defined in 9.4.2.2. One or more SSID elements that are Element optionally present when dot11SSIDListActivated is true. ChannelUsage A set of Channel As defined in 9.4.2.86 Specifies request types for the Channel Usage element Usage request. AccessNetworkTyp As defined in 0 to 15 Specifies the target specific access e Table 9-214 network type or the wildcard access network type. This field is present when dot11InterworkingServiceActivated is true. HESSID MAC Address Any valid individual Specifies the target specific HESSID MAC address or the network identifier or the wildcard network broadcast MAC address identifier. This field is present when dot11InterworkingServiceActivated is true. Mesh ID Octet string 0â€“32 octets Only present if BSSType = MESH or BSSType = ANY_BSS. Specifies the target Mesh ID or wildcard Mesh ID. DiscoveryMode Integer 0â€“1 Indicates, if equal to 1, that a DMG Beacon frame is transmitted during active scanning with the Discovery Mode field set to 1 and, if equal to 0, that a DMG Beacon frame is not transmitted during active scanning. Present only when dot11DMGOptionImplemented is true. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 266 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.3.2.3 When generated This primitive is generated by the SME for a STA to determine if there are other BSSs that it can join. 6.3.3.2.4 Effect of receipt This request initiates the scan process when the current frame exchange sequence is completed. 6.3.3.3 MLME-SCAN.confirm 6.3.3.3.1 Function This primitive returns the descriptions of the set of BSSs detected by the scan process. 6.3.3.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-SCAN.confirm( BSSDescriptionSet, BSSDescriptionFromMeasurementPilotSet, ResultCode, VendorSpecificInfo ) Name Type Valid range Description BSSDescriptionSet Set of N/A The BSSDescriptionSet is returned to BSSDescriptions indicate the results of the scan request. It is a set containing zero or more instances of a BSSDescription. BSSDescriptionFrom Set of N/A The MeasurementPilotSet BSSDescriptionFrom BSSDescriptionFromMeasurementPilotS MeasurementPilots et is returned to indicate the results of the scan request derived from measurement pilots. It is a set containing zero or more instances of a BSSDescriptionFromMeasurementPilot. Present if dot11RMMeasurementPilotActivated is nonzero; otherwise not present. ResultCode Enumeration SUCCESS, Indicates the result of the MLME- NOT_SUPPORTED SCAN.confirm primitive. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 Each BSSDescription consists of the parameters shown in the following table, in which the term peer STA refers to the STA transmitting the Beacon frame or Probe Response frame from which the BSSDescription was determined and the term local STA refers to the STA performing the scan, and in which the â€œIBSS adoptionâ€ column indicates whether a) This parameter is adopted by a STA that is joining an IBSS. b) This parameter is adopted by a STA that is a member of an IBSS that receives a beacon from a STA that is a member of the same IBSS and that has a timestamp value that is greater than the local TSF value (see 11.1.5). 267 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description IBSS adoption BSSID MACAddress N/A The BSSID of the found BSS Adopt or the MAC address of the found mesh STA. SSID Octet string 0â€“32 octets The SSID of the found BSS. Adopt BSSType Enumeration INFRASTRUCTUR The type of the found BSS. Adopt E, PERSONAL, INDEPENDENT, MESH Beacon Period Integer N/A The beacon period (in TU) of Adopt the found BSS if the BSSType is not MESH, or of the found mesh STA if the BSSType = MESH. DTIM Period Integer As defined in 9.4.2.6 The DTIM period (in beacon Adopt periods) of the BSS if the BSSType is not MESH, or of the mesh STA if the BSSType = MESH. Timestamp Integer N/A The timestamp of the received Adopt frame (Probe Response/ Beacon) from the found BSS. Local Time Integer N/A The value of the local STAâ€™s Do not adopt TSF timer at the start of reception of the first octet of the timestamp field of the received frame (Probe Response or Beacon) from the found BSS. PHY Parameter Set As defined in As defined in frame The parameter sets relevant to Adopt frame format format or according the PHY from the received or according to the relevant PHY Beacon or Probe Response to the relevant clause. frame. If no PHY Parameter PHY clause. Set element is present in the received frame, this parameter contains the channel number on which the frame was received. Valid channel numbers are defined in the relevant PHY clause. CF Parameter Set CF Parameter As defined in 9.4.2.5 The parameter set for the CF Do not adopt Set element periods, if found BSS supports CF mode. IBSS Parameter IBSS As defined in 9.4.2.7 The parameter set for the Adopt Set Parameter Set IBSS, if found BSS is an IBSS. element CapabilityInformat Capability As defined in 9.4.1.4 The advertised capabilities of Do not adopt ion Information the BSS. field BSSBasicRateSet Set of integers Non-DMG BSS: 1- Non-DMG BSS: The set of Adopt 127 excluding values data rates (in units of 500 kb/s) from Table 9-78, for that all STAs in the BSS are each member of the able to use for communication. set All STAs in the BSS are able to receive and transmit at each of the data rates listed in the set. DMG BSS: Empty. 268 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description IBSS adoption OperationalRateSe Non-DMG Non-DMG BSS: 1- Non-DMG BSS: The set of Do not adopt t BSS: Set of 127 excluding values data rates (in units of 500 kb/s) integers from Table 9-78, for that the peer STA is able to use each member of the for communication within the DMG BSS: set BSS. The peer STA is able to Set of receive at each of the data rates numbers DMG BSS: 0-24, 9.1, listed in the set. This set is a or 12.1-12.6, for each superset of the rates contained member of the set in the BSSBasicRateSet parameter. DMG BSS: The set of MCS indexes that the peer STA uses for communication within the BSS. Country As defined in As defined in the The information required to Adopt the Country Country element identify the regulatory domain element in which the peer STA is located and to configure its PHY for operation in that regulatory domain. Present if TPC functionality is required, as specified in 11.8, or dot11MultiDomainCapability Activated is true or dot11RadioMeasurementActiv ated is true; otherwise not present. IBSS DFS Integer 1â€“255 The time interval that is used Adopt Recovery Interval for DFS recovery. Present if DFS functionality is required, as specified in 11.9 and BSSType = INDEPENDENT; otherwise not present. RSN RSNE As defined in A description of the cipher Do not adopt 9.4.2.25 suites and AKM suites supported in the BSS. Load BSS Load As defined in The values from the BSS Load Do not adopt element 9.4.2.28 element if such an element was present in the Probe Response or Beacon frame, else null. EDCAParameterSe EDCA As defined in The values from the EDCA Adopt t Parameter Set 9.4.2.29 Parameter Set element if such element an element was present in the Probe Response or Beacon frame, else null. QoSCapability QoS As defined in The values from the QoS Adopt Capability 9.4.2.35 Capability element if such an element element was present in the Probe Response or Beacon frame, else null. AP Channel Report AP Channel As defined in The values from the AP Adopt Report 9.4.2.36 Channel Report element if element such an element was present in the probe response or Beacon frame, else null. 269 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description IBSS adoption BSS Average BSS Average As defined in The values from the BSS Adopt Access Delay Access Delay 9.4.2.39 Average Access Delay element element if such an element was present in the probe response or Beacon frame, else null. Antenna Antenna As defined in The values from the Antenna Adopt element 9.4.2.40 element if such an element was present in the probe response or Beacon frame, else null. BSS Available BSS As defined in The values from the BSS Adopt Admission Available 9.4.2.43 Available Admission Capacity Capacity Admission element if such an element was Capacity present in the probe response element or Beacon frame, else null. BSS AC Access BSS AC As defined in The values from the BSS AC Adopt Delay Access Delay 9.4.2.44 Access Delay element if such element an element was present in the probe response or Beacon frame, else null. Measurement Pilot Measurement As defined in The values from the Adopt Transmission Pilot 9.4.2.42 Measurement Pilot Information Transmission Transmission element if such element an element was present in the probe response or Beacon frame, else null. Multiple BSSID As defined in As defined in The values from the Multiple Do not adopt Multiple 9.4.2.46 BSSID element if such an BSSID element was present in the element probe response or Beacon frame, else null. RM Enabled RM Enabled As defined in The values from the RM Adopt Capabilities Capabilities 9.4.2.45 Enabled Capabilities element if element such an element was present in the probe response or Beacon frame, else null. RCPIMeasurement Integer As defined in The RCPI of the received Adopt 9.4.2.38 frame. RSNIMeasurement Integer As defined in The RSNI of the received Adopt 9.4.2.41 frame. Requested Set of As defined in Elements requested by the Adopt elements elements 9.4.1.36 Request element or Extended Request element of the Probe Request frame. DSERegisteredLoc DSE As defined in The information from the DSE Adopt ation Registered 9.4.2.52 Registered Location element, if Location such a field is present in the element Probe Response or Beacon frame, else null. Present if DSE functionality is required, as specified in 11.12, or dot11LCIDSERequired is true; otherwise not present. 270 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description IBSS adoption HT Capabilities As defined in As defined in The values from the HT Do not adopt frame format 9.4.2.56 Capabilities element if such an element was present in the Probe Response or Beacon frame, else null. The parameter is optionally present if dot11HighThroughputOptionI mplemented is true; otherwise not present. HT Operation As defined in As defined in The values from the HT Adopt frame format 9.4.2.57 Operation element if such an element was present in the Probe Response or Beacon frame, else null. The parameter is optionally present if dot11HighThroughputOptionI mplemented is true; otherwise not present. BSSMembershipS Set of integers A value from The set of features that are Adopt electorSet Table 9-78 for each supported by all STAs joining member of the set this BSS. Extended As defined in As defined in Specifies the parameters within Do not adopt Capabilities frame format 9.4.2.27 the Extended Capabilities element that are supported by the MAC entity. 20/40 BSS As defined in As defined in Specifies the parameters within Do not adopt Coexistence frame format 9.4.2.60 the 20/40 BSS Coexistence element that are indicated by the MAC entity. The parameter is present if dot112040BSSCoexistence- ManagementSupport is true. Overlapping BSS As defined in As defined in Specifies the parameters within Adopt Scan Parameters frame format 9.4.2.59 the Overlapping BSS Scan Parameters element that are indicated by the MAC entity. This parameter is optionally present if dot11FortyMHzOptionImplem ented is true and is not present if dot11FortyMHzOptionImplem ented is false. FMSDescriptor FMS As defined in The values from the FMS Do not adopt Descriptor 9.4.2.75 Descriptor element if such an element element was present in the Probe Response or Beacon frame, else null. QoSTrafficCapabil QoS Traffic As defined in The values from the QoS Do not adopt ity Capability 9.4.2.78 Traffic Capability element if element such an element was present in the Probe Response or Beacon frame, else null. ChannelUsage A set of As defined in Specifies parameters for the Do not adopt Channel 9.4.2.86 Channel Usage. Usage element 271 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description IBSS adoption TimeAdvertisemen Time As defined in The values from the Time Do not adopt t Advertisemen 9.4.2.61 Advertisement element if such t element an element was present in the Probe Response or Beacon frame, else null. TimeZone Time Zone As defined in The values from the Time Zone Do not adopt element 9.4.2.87 element if such an element was present in the Probe Response or Beacon frame, else null. MeshID Mesh ID As defined in The value of MeshID element Do not adopt element 9.4.2.99 if such element was present in the probe response or Beacon frame, else null. MeshConfiguratio Mesh As defined in The values from the Mesh Do not adopt n Configuration 9.4.2.98 Configuration element if such element an element was present in the probe response or Beacon frame, else null. Mesh Awake Mesh Awake As defined in The values from the Mesh Do not adopt Window Window 9.4.2.104 Awake Window element if element such an element was present in the Probe Response or Beacon frame, else null. BeaconTiming Beacon As defined in The values from the Beacon Do not adopt Timing 9.4.2.105 Timing element if such an element element was present in the Probe Response or Beacon frame, else null. MCCAOP MCCAOP As defined in frame The values from the Beacon Do not adopt Advertisement Advertisemen format Timing element if such an Overview t Overview element was present in the element Probe Response or Beacon frame, else null. MCCAOP MCCAOP As defined in frame The values from the Beacon Do not adopt Advertisement Advertisemen format Timing element if such an t element was present in the Probe Response or Beacon frame, else null. QMFPolicy QMF Policy As defined in The values from the QMF Do not adopt element 9.4.2.120 Policy element if such an element was present in the Probe Response or Beacon frame, else null. QLoad Report As defined in As defined in The values from the QLoad Do not adopt. frame format 9.4.2.123 Report element if such an element was present in the Probe Response frame, else null. Sector Sweep As defined in As defined in 9.3.4.2 The values from the Sector Adopt frame format Sweep field from the DMG Beacon frame, else null. The parameter is present only if dot11DMGOptionImplemente d is true. 272 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description IBSS adoption Beacon Interval As defined in As defined in 9.3.4.2 The values from the Beacon Adopt Control frame format Interval Control field from the DMG Beacon frame, else null. The parameter is present only if dot11DMGOptionImplemente d is true. DMG Parameters As defined in As defined in 9.3.4.2 The values from the DMG Adopt frame format Parameters field from the DMG Beacon frame, else null. The parameter is present only if dot11DMGOptionImplemente d is true. Clustering Control As defined in As defined in 9.3.4.2 The values from the Clustering Do not adopt frame format Control field from the DMG Beacon frame, else null. The parameter is present only if dot11DMGOptionImplemente d is true. DMG Capabilities As defined in As defined in The values from the DMG Do not adopt frame format 9.4.2.128 Capabilities element if such an element was present in the Probe Response or DMG Beacon frame, else null. The parameter is optionally present only if dot11DMGOptionImplemente d is true. DMG Operation As defined in As defined in The values from the DMG Adopt frame format 9.4.2.128 Operation element if such an element was present in the Probe Response or DMG Beacon frame, else null. The parameter is optionally present only if dot11DMGOptionImplemente d is true. Extended Schedule As defined in As defined in The values from the Extended Adopt frame format 9.4.2.132 Schedule element if such an element was present in the Probe Response or DMG Beacon frame, else null. The parameter is optionally present only if dot11DMGOptionImplemente d is true. Next DMG ATI As defined in As defined in The values from the Next Adopt frame format 9.4.2.135 DMG ATI element if such an element was present in the Probe Response or DMG Beacon frame, else null. The parameter is optionally present only if dot11DMGOptionImplemente d is true. 273 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description IBSS adoption DMG BSS As defined in As defined in The values from the DMG BSS Adopt Parameter Change frame format 9.4.2.127 Parameter Change element if such an element was present in the Probe Response or DMG Beacon frame, else null. The parameter is optionally present only if dot11DMGOptionImplemente d is true. Multi-band As defined in As defined in The values from the Multi- Adopt frame format 9.4.2.138 band element if such an element was present in the Probe Response or DMG Beacon frame, else null. The Multi-band element is optionally present if dot11MultibandImplemented is true. DMG Wakeup As defined in As defined in The values from the DMG Adopt Schedule frame format 9.4.2.131 Wakeup Schedule element if such an element was present in the Probe Response or DMG Beacon frame, else null. The parameter is optionally present only if dot11DMGOptionImplemente d is true. Antenna Sector ID As defined in As defined in The values from the Antenna Adopt Pattern frame format 9.4.2.157 Sector ID Pattern element if such an element was present in the Probe Response or DMG Beacon frame, else null. The parameter is optionally present only if dot11DMGOptionImplemente d is true. Relay Capabilities As defined in As defined in The values from the Relay Do not adopt frame format 9.4.2.148 Capabilities element if such an element was present in the Probe Response or DMG Beacon frame, else null. The parameter is optionally present only if dot11RelayActivated is true. VHT Capabilities As defined in As defined in The values from the VHT Do not adopt frame format 9.4.2.158 Capabilities element. The parameter is present if dot11VHTOptionImplemented is true and a VHT Capabilities element was present in the Probe Response or Beacon frame from which the BSSDescription was determined. The parameter is not present otherwise. 274 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description IBSS adoption VHT Operation As defined in As defined in The values from the VHT Adopt frame format 9.4.2.159 Operation element. The parameter is present if dot11VHTOptionImplemented is true and a VHT Operation element was present in the Probe Response or Beacon frame from which the BSSDescription was determined. The parameter is not present otherwise. TVHT Operation As defined in As defined in The values from the TVHT Adopt frame format 9.4.2.172 Operation element if such an element was present in the Probe Response or Beacon frame; otherwise, null. The parameter is optionally present only if dot11TVHTOptionImplemente d is true. Each BSSDescriptionFromMeasurementPilot consists of the following parameters, in which the term peer STA refers to the STA transmitting the Measurement Pilot frame from which the BSSDescription was determined and the term local STA refers to the STA performing the scan: Name Type Valid range Description BSSID MACAddress N/A The BSSID of the found BSS. BSS Type Enumeration INFRASTRUCT The type of the found BSS. URE Local Time Integer N/A The value of the local STAâ€™s TSF timer at the start of reception of the first octet of the timestamp field of the received frame from the found BSS. Condensed Capability Condensed As defined in The advertised condensed capabilities of the Information Capability 9.6.8.3 BSS. Information field Condensed Country Condensed As defined in Together with the Operating Class, the String Country String 9.6.8.3 information required to identify the regulatory field domain in which the peer STA is located and to configure its PHY for operation in that regulatory domain. Operating Class Operating Class The field is Together with the Condensed Country String, field defined in the information required to identify the 9.6.8.3, valid regulatory domain in which the peer STA is values for the located and to configure its PHY for operation field are defined in that regulatory domain. in Annex E. Channel Channel field The field is The operating channel of the BSS indicated in defined in the received frame 9.6.8.3, valid values for the field are defined in Annex E. Measurement Pilot Measurement As defined in The Measurement Pilot interval of the BSS Interval Pilot Interval 9.6.8.3 indicated in the received frame field 275 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description Multiple BSSID element Multiple BSSID As defined in Indicates that the BSS is within a multiple element 9.4.2.46 BSSID set (see 11.11.14). The range of BSSIDs is determined by the BSSID and Multiple BSSID element. PHY Type Integer As defined in The dot11PHYType of the received frame. Annex C RCPIMeasurement Integer As defined in The RCPI of the received frame. 9.4.2.38 RSNIMeasurement Integer As defined in The RSNI of the received frame. 9.4.2.41 6.3.3.3.3 When generated This primitive is generated by the MLME as a result of an MLME-SCAN.request primitive to ascertain the operating environment of the STA. 6.3.3.3.4 Effect of receipt The SME is notified of the results of the scan procedure. 6.3.4 Synchronization 6.3.4.1 Introduction This mechanism supports the process of selection of a peer in the authentication process. 6.3.4.2 MLME-JOIN.request 6.3.4.2.1 Function This primitive requests synchronization with a BSS, of which type is infrastructure or independent. 6.3.4.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-JOIN.request( SelectedBSS, JoinFailureTimeout, NAVSyncDelay, OperationalRateSet, Capability Information, HT Capabilities, VHT Capabilities, Extended Capabilities, 20/40 BSS Coexistence, InterworkingInfo, AdvertisementProtocolInfo, VendorSpecificInfo ) 276 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description SelectedBSS BSSDescription N/A The BSSDescription of the BSS to join. The SelectedBSS is a member of the set of descriptions that was returned as a result of an MLME-SCAN.request primitive. JoinFailureTimeout Integer 1 The time limit, in units of beacon intervals, after which the join procedure is terminated. NAVSyncDelay Integer N/A Delay (in microseconds) to be used prior to transmitting when changing from doze to awake state, if no frame is detected by which the network allocation vector (NAV) can be set. OperationalRateSet Non-DMG BSS: Set Non-DMG BSS: a Non-DMG BSS: The set of data rates (in of integers value in units of 500 kb/s) that the STA is able to dot11SupportedData use for communication within the BSS. DMG BSS: Set of RatesRxTable, for The STA is able to receive at each of the numbers each member of the data rates listed in the set. This set is a set superset of the rates contained in the BSSBasicRateSet parameter of the DMG BSS: 0-24, SelectedBSS parameter. 9.1, or 12.1-12.6, for DMG BSS: The set of MCS indexes that each member of the the STA uses for communication within set the BSS. CapabilityInformatio Capability As defined in 9.4.1.4 The capabilities to be advertised for the n Information field BSS. HT Capabilities As defined in frame As defined in The HT capabilities to be advertised for format HT 9.4.2.56; the HT- the BSS. The parameter is present if Capabilities element MCSs in the element dot11HighThroughputOptionImplemente are present in d is true; otherwise, this parameter is not dot11SupportedMC present. SRxTable and the highest supported data rate in the element does not exceed dot11HighestSuppor tedDataRate VHT Capabilities As defined in VHT As defined in Specifies the parameters in the VHT Capabilities element 9.4.2.158; the VHT- Capabilities element that are supported by MCSs in the element the STA. The parameter is present if are present in dot11VHTOptionImplemented is true and dot11VHTRxVHTM not present otherwise. CSMap/ dot11VHTTxVHTM CSMap and the highest supported rates in the element do not exceed dot11VHTRxHighes tDataRateSupported/ dot11VHTTxHighes tDataRateSupported Extended As defined in frame As defined in Specifies the parameters within the Capabilities format 9.4.2.27 Extended Capabilities element that are supported by the MAC entity. 277 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description 20/40 BSS As defined in frame As defined in Specifies the parameters within the 20/40 Coexistence format 9.4.2.60 BSS Coexistence element that are indicated by the MAC entity. The parameter is present if dot112040BSSCoexistence- ManagementSupport is true. InterworkingInfo As defined in frame As defined in Specifies the Interworking capabilities of format Interworking STA. This field is present when element in 9.4.2.92 dot11InterworkingServiceActivated is true. AdvertisementProtoc Integer or Sequence As defined in Identifies zero or more Advertisement olInfo of integers Advertisement Protocols and advertisement control to be Protocol element in used in the BSSs. This field is present Table 9-215 when dot11InterworkingServiceActivated is true. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.4.2.3 When generated This primitive is generated by the SME for a STA to establish synchronization with a BSS. 6.3.4.2.4 Effect of receipt This primitive initiates a synchronization procedure once the current frame exchange sequence is complete. The MLME synchronizes its timing with the specified BSS based on the information provided in the SelectedBSS parameter. The MLME subsequently issues an MLME-JOIN.confirm primitive that reflects the results. If the MLME of a non-DMG STA receives an MLME-JOIN.request primitive with the SelectedBSS parameter containing a BSSBasicRateSet parameter that contains any unsupported rates, the MLME response in the resulting MLME-JOIN.confirm primitive shall contain a ResultCode parameter that is not set to the value SUCCESS. If the MLME of an HT STA receives an MLME-JOIN.request primitive with the SelectedBSS parameter containing a Basic HT-MCS Set field in the HT Operation parameter that contains any unsupported MCSs, the MLME response in the resulting MLME-JOIN.confirm primitive shall contain a ResultCode parameter that is not set to the value SUCCESS. If the MLME of a VHT STA receives an MLME-JOIN.request primitive with a SelectedBSS parameter containing a Basic VHT-MCS And NSS Set field in the VHT Operation parameter that contains any unsupported tuple, the MLME response in the resulting MLME-JOIN.confirm primitive shall contain a ResultCode parameter that is not set to the value SUCCESS. If the MLME of a DMG STA receives an MLME-JOIN.request primitive with the SelectedBSS parameter containing a BSSBasicRateSet parameter that is not empty, or with the OperationalRateSet parameter containing any unsupported MCSs, the MLME response in the resulting MLME-JOIN.confirm primitive shall contain a ResultCode parameter that is not set to the value SUCCESS. 6.3.4.3 MLME-JOIN.confirm 6.3.4.3.1 Function This primitive confirms synchronization with a BSS. 278 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.4.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-JOIN.confirm( ResultCode, VendorSpecificInfo ) Name Type Valid range Description ResultCode Enumeration SUCCESS, Indicates the result of the MLME- JOIN_FAILURE_TI JOIN.request primitive. MEOUT VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.4.3.3 When generated This primitive is generated by the MLME as a result of an MLME-JOIN.request primitive to establish synchronization with a BSS. 6.3.4.3.4 Effect of receipt The SME is notified of the results of the synchronization procedure. 6.3.5 Authenticate 6.3.5.1 Introduction This mechanism supports the process of establishing an authentication relationship with a peer MAC entity. 6.3.5.2 MLME-AUTHENTICATE.request 6.3.5.2.1 Function This primitive requests authentication with a specified peer MAC entity. 6.3.5.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-AUTHENTICATE.request( PeerSTAAddress, AuthenticationType, AuthenticateFailureTimeout, Content of FT Authentication elements, Content of SAE Authentication frame, Multi-band local, Multi-band peer, VendorSpecificInfo ) 279 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description PeerSTAAddress MACAddress Any valid individual MAC Specifies the address of the peer MAC address entity with which to perform the authentication process. AuthenticationType Enumeration OPEN_SYSTEM, Specifies the type of authentication SHARED_KEY, algorithm to use during the FAST_BSS_TRANSITION, authentication process. SAE AuthenticateFailureT Integer 1 Specifies a time limit (in TU) after imeout which the authentication procedure is terminated. Content of FT Sequence of As defined in 13.8 The set of elements to be included in Authentication elements the first message of the FT elements authentication sequence, as described in 13.8.2. Present if dot11FastBSSTransitionActivated is true; otherwise not present. Content of SAE Sequence of As defined in 9.4.1.38, The set of elements and fields to be Authentication frame elements and 9.4.1.39, 9.4.1.40, 9.4.1.41, included in the SAE Commit message fields 9.4.1.42, and 9.4.1.43 or SAE Confirm message. Present if AuthenticationType indicates SAE authentication; otherwise not present. Multi-band local Multi-band As defined in 9.4.2.138 Specifies the parameters within the element Multi-band element that are supported by the local MAC entity. The parameter is present if dot11MultibandImplemented is true and is absent otherwise. Multi-band peer Multi-band As defined in 9.4.2.138 Specifies the parameters within the element Multi-band element that identify the remote (peer) MAC entity. This parameter is present if OCT is being used and is absent otherwise. VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements. elements 6.3.5.2.3 When generated This primitive is generated by the SME for a STA to establish authentication with a specified peer MAC entity in order to permit Class 2 frames, or mesh peering Management frames for AMPE utilizing SAE authentication, to be exchanged between the two STAs. During the authentication procedure, the SME might generate additional MLME-AUTHENTICATE.request primitives. 6.3.5.2.4 Effect of receipt This primitive initiates an authentication procedure. In the case that a response is received from the responder STA, the MLME subsequently issues an MLME-AUTHENTICATE.confirm primitive that reflects the results. 6.3.5.3 MLME-AUTHENTICATE.confirm 6.3.5.3.1 Function This primitive reports the results of an authentication attempt with a specified peer MAC entity. 280 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.5.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-AUTHENTICATE.confirm( PeerSTAAddress, AuthenticationType, ResultCode, Content of FT Authentication elements, Content of SAE Authentication frame, Multi-band local, Multi-band peer, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MACAddress Any valid individual MAC Specifies the address of the peer MAC address entity with which the authentication process was attempted. This value matches the peerSTAAddress parameter specified in the corresponding MLME- AUTHENTICATE.request primitive. AuthenticationType Enumeration OPEN_SYSTEM, Specifies the type of authentication SHARED_KEY algorithm that was used during the FAST_BSS_TRANSITION, authentication process. This value SAE matches the AuthenticationType parameter specified in the corresponding MLME-AUTHENTICATE.request primitive. ResultCode Enumeration SUCCESS, REFUSED, Indicates the result of the MLME- ANTI-CLOGGING AUTHENTICATE.request primitive. TOKEN REQUIRED, FINITE CYCLIC GROUP NOT SUPPORTED, AUTHENTICATION REJECTED, AUTH FAILURE TIMEOUT Content of FT Sequence of As defined in 13.8 The set of elements included in the Authentication elements second message of the FT authentication elements sequence, as described in 13.8.3. Present if dot11FastBSSTransitionActivated is true; otherwise not present. Content of SAE Sequence of As defined in 9.4.1.38, The set of elements to be included in the Authentication frame elements 9.4.1.39, 9.4.1.40, 9.4.1.41, SAE Commit message or SAE Confirm 9.4.1.42, and 9.4.1.43 message. Present if AuthenticationType indicates SAE authentication; otherwise not present. Multi-band local Multi-band As defined in 9.4.2.138 Specifies the parameters within the Multi- element band element that identify the local MAC entity. This parameter is present if OCT is being used and is absent otherwise. Multi-band peer Multi-band As defined in 9.4.2.138 Specifies the parameters within the Multi- element band element that are supported by the remote (peer) MAC entity. This parameter is present if OCT is being used and is absent otherwise. VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements. elements 281 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.5.3.3 When generated This primitive is generated by the MLME as a result of an MLME-AUTHENTICATE.request primitive to authenticate with a specified peer MAC entity. 6.3.5.3.4 Effect of receipt The SME is notified of the results of the authentication procedure. 6.3.5.4 MLME-AUTHENTICATE.indication 6.3.5.4.1 Function This primitive indicates receipt of a request from a specific peer MAC entity to establish an authentication relationship with the STA processing this primitive. 6.3.5.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-AUTHENTICATE.indication( PeerSTAAddress, AuthenticationType, Content of FT Authentication elements, Content of SAE Authentication frame, Multi-band local, Multi-band peer, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MACAddress Any valid individual MAC Specifies the address of the peer MAC address entity with which the authentication relationship was established. AuthenticationType Enumeration OPEN_SYSTEM, Specifies the type of authentication SHARED_KEY, algorithm that was used during the FAST_BSS_ authentication process. TRANSITION, SAE Content of FT Sequence of As defined in 13.8 The set of elements included in the Authentication elements first message of the FT authentication elements sequence, as described in 13.8.2. Present if dot11FastBSSTransitionActivated is true; otherwise not present. Content of SAE Sequence of As defined in 9.4.1.38, The set of elements to be included in Authentication frame elements 9.4.1.39, 9.4.1.40, 9.4.1.41, the SAE Commit message or SAE 9.4.1.42, and 9.4.1.43 Confirm message. Present if AuthenticationType indicates SAE authentication; otherwise not present. Multi-band local Multi-band As defined in 9.4.2.138 Specifies the parameters within the element Multi-band element that identify the local MAC entity. This parameter is present if OCT is being used and is absent otherwise. 282 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description Multi-band peer Multi-band As defined in 9.4.2.138 Specifies the parameters within the element Multi-band element that are supported by the remote (peer) MAC entity. This parameter is present if OCT is being used and is absent otherwise. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.5.4.3 When generated This primitive is generated by the MLME as a result of the receipt of an authentication request from a specific peer MAC entity. 6.3.5.4.4 Effect of receipt The SME is notified of the receipt of the authentication request. 6.3.5.5 MLME-AUTHENTICATE.response 6.3.5.5.1 Function This primitive is used to send a response to a specific peer MAC entity that requested authentication with the STA that issued this primitive. 6.3.5.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-AUTHENTICATE.response( PeerSTAAddress, ResultCode, Content of FT Authentication elements, Content of SAE Authentication frame, Multi-band local, Multi-band peer, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MACAddress Any valid individual Specifies the address of the peer MAC MAC address entity from which the authentication request was received. ResultCode Enumeration SUCCESS, Indicates the result response to the REFUSED, ANTI- authentication request from the peer CLOGGING MAC entity. TOKEN REQUIRED, FINITE CYCLIC GROUP NOT SUPPORTED, AUTHENTICATIO N REJECTED Content of FT Sequence of elements As defined in 13.8 The set of elements to be included in the Authentication second message of the FT authentication elements sequence, as described in 13.8.3. Present if dot11FastBSSTransitionActivated is true; otherwise not present. 283 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description Content of SAE Sequence of elements As defined in The set of elements to be included in the Authentication frame 9.4.1.38, 9.4.1.39, SAE Commit message or SAE Confirm 9.4.1.40, 9.4.1.41, message. Present if the 9.4.1.42, and AuthenticationType of the MLME- 9.4.1.43 AUTHENTICATE.indication primitive that generated this response indicated SAE authentication; otherwise not present. Multi-band local Multi-band element As defined in Specifies the parameters within the Multi- 9.4.2.138 band element that are supported by the local MAC entity. The parameter is present if dot11MultibandImplemented is true and is absent otherwise. Multi-band peer Multi-band element As defined in Specifies the parameters within the Multi- 9.4.2.138 band element that identify the remote (peer) MAC entity. This parameter is present if OCT is being used and is absent otherwise. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.5.5.3 When generated This primitive is generated by the SME of a STA as a response to an MLME-AUTHENTICATE.indication primitive. 6.3.5.5.4 Effect of receipt This primitive initiates transmission of a response to the specific peer MAC entity that requested authentication. 6.3.6 Deauthenticate 6.3.6.1 Introduction This mechanism supports the process of invalidating an authentication relationship with a peer MAC entity. 6.3.6.2 MLME-DEAUTHENTICATE.request 6.3.6.2.1 Function This primitive requests that the authentication relationship with a specified peer MAC entity be invalidated. 6.3.6.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-DEAUTHENTICATE.request( PeerSTAAddress, ReasonCode, VendorSpecificInfo ) 284 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description PeerSTAAddress MACAddress Any valid individual Specifies the address of the peer MAC MAC address entity with which to perform the deauthentication process. ReasonCode Reason Code field As defined in 9.4.1.7 Specifies the reason for initiating the deauthentication procedure. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.6.2.3 When generated This primitive is generated by the SME for a STA to invalidate authentication with a specified peer MAC entity in order to prevent the exchange of Class 2 frames, or mesh peering Management frames for AMPE utilizing SAE authentication, between the two STAs. During the deauthentication procedure, the SME might generate additional MLME-DEAUTHENTICATE.request primitives. 6.3.6.2.4 Effect of receipt This primitive initiates a deauthentication procedure. The MLME subsequently issues an MLME- DEAUTHENTICATE.confirm primitive that reflects the results. 6.3.6.3 MLME-DEAUTHENTICATE.confirm 6.3.6.3.1 Function This primitive reports the results of a deauthentication attempt with a specified peer MAC entity. 6.3.6.3.2 Semantics of the service primitive The primitive parameter is as follows: MLME-DEAUTHENTICATE.confirm( PeerSTAAddress ) Name Type Valid range Description PeerSTAAddress MACAddress Any valid individual Specifies the address of the peer MAC MAC address entity with which the deauthentication process was attempted. 6.3.6.3.3 When generated This primitive is generated by the MLME as a result of an MLME-DEAUTHENTICATE.request primitive to invalidate the authentication relationship with a specified peer MAC entity. 6.3.6.3.4 Effect of receipt The SME is notified of the results of the deauthentication procedure. 6.3.6.4 MLME-DEAUTHENTICATE.indication 6.3.6.4.1 Function This primitive reports the invalidation of an authentication relationship with a specific peer MAC entity. 285 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.6.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-DEAUTHENTICATE.indication( PeerSTAAddress, ReasonCode, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MACAddress Any valid individual Specifies the address of the peer MAC MAC address entity with which the authentication relationship was invalidated. ReasonCode Reason Code field As defined in 9.4.1.7 Specifies the reason the deauthentication procedure was initiated. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.6.4.3 When generated This primitive is generated by the MLME as a result of the invalidation of an authentication relationship with a specific peer MAC entity. 6.3.6.4.4 Effect of receipt The SME is notified of the invalidation of the specific authentication relationship. 6.3.7 Associate 6.3.7.1 Introduction The following primitives describe how a STA becomes associated with an AP. 6.3.7.2 MLME-ASSOCIATE.request 6.3.7.2.1 Function This primitive requests association with a specified peer MAC entity that is within an AP. 6.3.7.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-ASSOCIATE.request( PeerSTAAddress, ListenInterval, Supported Channels, RSN, QoSCapability, Content of FT Authentication elements, SupportedOperatingClasses, SM Power Save, QoSTrafficCapability, TIMBroadcastRequest, EmergencyServices, 286 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DMG Capabilities, Multi-band local, Multi-band peer, MMS, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MACAddress Any valid individual Specifies the address of the peer MAC MAC address entity with which to perform the association process. ListenInterval Integer 0 Specifies how often the STA awakens and listens for the next Beacon frame, if it enters power save mode. Supported Channels As defined in the As defined in the The list of channels in which the STA is Supported Channels Supported Channels capable of operating. element element Present if DFS functionality is required, as specified in 11.9; otherwise not present. RSN RSNE As defined in A description of the cipher suites and 9.4.2.25 AKM suites selected by the STA. QoSCapability QoS Capability As defined in Specifies the parameters within the QoS element 9.4.2.35 Capability element that are supported by the MAC entity. The parameter is present if dot11QosOptionImplemented is true; otherwise not present. Content of FT Sequence of elements As defined in 13.4 The set of elements to be included in the Authentication initial mobility domain association elements request, as described in 13.4. Present if dot11FastBSSTransitionActivated is true; otherwise not present. SupportedOperating As defined in the As defined in Specifies the supported operating classes Classes Supported Operating 9.4.2.54 capabilities of the STA. This parameter is Classes element present if dot11ExtendedChannelSwitchActivated is true. SM Power Save Integer As defined in Indicates the spatial multiplexing power Table 9-162 save mode that is in operation immediately after association. QoS Traffic As defined in the As defined in Specifies the QoS Traffic Capability flags Capability QoS Traffic 9.4.2.78 of the non-AP STA. This parameter is Capability optionally present if element dot11ACStationCountActivated is true and is not present otherwise. TIMBroadcastReque As defined in the As defined in Specifies the proposed service parameters st TIM Broadcast 9.4.2.83 for TIM Broadcast. This parameter is Request element optionally present if dot11TIMBroadcastActivated is true and is not present otherwise. EmergencyServices Boolean true, false Specifies that the non-AP STA intends to associate for the purpose of unauthenticated access to emergency services. The parameter is optionally be present if dot11InterworkingServiceActivated is true and is not present otherwise. 287 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description DMG Capabilities DMG Capabilities As defined in Specifies the parameters within the DMG element 9.4.2.128 Capabilities element that are supported by the MAC entity. The parameter is present if dot11DMGOptionImplemented is true and is absent otherwise. Multi-band local Multi-band element As defined in Specifies the parameters within the Multi- 9.4.2.138 band element that are supported by the local MAC entity. The parameter is present if dot11MultibandImplemented is true and is absent otherwise. Multi-band peer Multi-band element As defined in Specifies the parameters within the Multi- 9.4.2.138 band element that identify the remote (peer) MAC entity. The parameter is present if OCT is being used and is absent otherwise. MMS Multiple MAC As defined in Specifies the parameters within the Sublayers element 9.4.2.153 Multiple MAC Sublayers element that are supported by the MAC entity. The parameter is present if dot11MultipleMACActivated is true and is absent otherwise. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 Additional parameters needed to perform the association procedure are not included in the primitive parameter list since the MLME already has that data (maintained as internal state). 6.3.7.2.3 When generated This primitive is generated by the SME when a STA wishes to establish association with an AP or PCP. 6.3.7.2.4 Effect of receipt This primitive initiates an association procedure. In the case that a response is received from the responder STA, the MLME subsequently issues an MLME-ASSOCIATE.confirm primitive that reflects the results. 6.3.7.3 MLME-ASSOCIATE.confirm 6.3.7.3.1 Function This primitive reports the results of an association attempt with a specified peer MAC entity that is in an AP or PCP. 6.3.7.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-ASSOCIATE.confirm( ResultCode, CapabilityInformation, AssociationID, EDCAParameterSet, RCPI of Request, RSNI of Request, RCPI of Response, RSNI of Response, 288 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications RMEnabledCapabilities, Content of FT Authentication elements, SupportedOperatingClasses, Extended Capabilities, 20/40 BSS Coexistence, TimeoutInterval, BSSMaxIdlePeriod, TIMBroadcastResponse, QosMapSet, QMFPolicy, DMG Capabilities, Multi-band local, Multi-band peer, MMS, VendorSpecificInfo ) Name Type Valid range Description ResultCode Enumeration SUCCESS, Indicates the result of the MLME- REFUSED_REASON_UNSPECIFIED, ASSOCIATE.request primitive. REFUSED_NOT_AUTHENTICATED, REFUSED_CAPABILITIES_MISMATCH, REFUSED_EXTERNAL_REASON, REFUSED_AP_OUT_OF_MEMORY, REFUSED_BASIC_RATES_MISMATCH, REJECTED_EMERGENCY_SERVICES_ NOT_SUPPORTED, REFUSED_TEMPORARILY Capability- Capability As defined in 9.4.1.4 Specifies the operational Information Information capabilities advertised by the AP field or PCP. AssociationID Integer Non-DMG: 1â€“2007 If the association request result DMG: 1â€“254 was SUCCESS, then AssociationID specifies the association ID value assigned by the AP or PCP. EDCAParameter EDCA As defined in 9.4.2.29 Specifies the EDCA parameter set Set Parameter Set that the STA should use. The element parameter is present if dot11QosOptionImplemented is true; otherwise not present. RCPI of Request Integer As defined in 9.4.2.38 Indicates the RCPI value contained in the received Association Response frame. This value represents the RCPI that the AP or PCP measured at the time it received the corresponding Association Request frame. The element is optionally present if dot11RMRCPIMeasurementActiv ated is true; otherwise not present. 289 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description RSNI of Request Integer As defined in 9.4.2.41 Indicates the RSNI value contained in the received Association Response frame. This value represents the RSNI that the AP or PCP measured at the time it received the corresponding Association Request frame. The element is optionally present if dot11RMRSNIMeasurementActi vated is true; otherwise not present. RCPI of Integer As defined in 9.4.2.38 The RCPI value represents the Response measured RCPI of the corresponding Association Response frame. The element is optionally present if dot11RMRCPIMeasurementActiv ated is true; otherwise not present. RSNI of Integer As defined in 9.4.2.41 RSNI at the time the Response corresponding Association Response frame was receive. The element is optionally present if dot11RMRSNIMeasurementActi vated is true; otherwise not present. RMEnabledCapa RM Enabled As defined in 9.4.2.45 Specifies the RM enabled bilities Capabilities capabilities advertised by the AP element or PCP. The element is present if dot11RadioMeasurementActivate d is true; otherwise not present. Content of FT Sequence of As defined in 13.4 The set of elements included in Authentication elements the initial mobility domain elements association response, as described in 13.4. Present if dot11FastBSSTransitionActivated is true; otherwise not present. SupportedOperat As defined in As defined in 9.4.2.54 Specifies the supported operating ingClasses the Supported classes capabilities of the STA. Operating This parameter is present if Classes dot11ExtendedChannelSwitchAct element ivated is true; otherwise not present. Extended As defined in As defined in 9.4.2.27 Specifies the parameters within Capabilities frame format the Extended Capabilities element that are supported by the MAC entity. 20/40 BSS As defined in As defined in 9.4.2.60 Specifies the parameters within Coexistence frame format the 20/40 BSS Coexistence element that are indicated by the MAC entity. The parameter is present if dot112040BSSCoexistence- ManagementSupport is true. TimeoutInterval Timeout As defined in 9.4.2.49 This parameter is present when Interval ResultCode is element, as REFUSED_TEMPORARILY. defined in frame format 290 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description BSSMaxIdlePeri As defined in As defined in 9.4.2.79 Indicates the BSS max idle period od BSS Max Idle parameters of the AP or PCP. Period This parameter is present if element dot11WirelessManagementImple mented is true and is not present otherwise. TIMBroadcastRe As defined in As defined in 9.4.2.84 Specifies the service parameters sponse TIM for TIM Broadcast. This Broadcast parameter is optionally present if Response dot11TIMBroadcastActivated is element true and the TIM Broadcast Request element is present in the corresponding Association Request frame; this parameter is not present otherwise. QoSMapSet As defined in As defined in 9.4.2.95 Specifies the QoS Map the non- frame format AP and non-PCP STA should use. QMFPolicy QMF Policy As defined in 9.4.2.120 The values from the QMF Policy element element if such an element was present in the Association Response frame; otherwise, null. DMG DMG As defined in 9.4.2.128 Specifies the parameters within Capabilities Capabilities the DMG Capabilities element element that are supported by the MAC entity. The parameter is present if dot11DMGOptionImplemented is true and is absent otherwise. Multi-band local Multi-band As defined in 9.4.2.138 Specifies the parameters within element the Multi-band element that identify the local MAC entity. The parameter is present if OCT is being used and is absent otherwise. Multi-band peer Multi-band As defined in 9.4.2.138 Specifies the parameters within element the Multi-band element that are supported by the remote (peer) MAC entity. This parameter is present if OCT is being used and is absent otherwise. MMS Multiple As defined in 9.4.2.153 Specifies the parameters within MAC the Multiple MAC Sublayers Sublayers element that are supported by the element MAC entity. The parameter is present if dot11MultipleMACActivated is true and is absent otherwise. VendorSpecificIn A set of As defined in 9.4.2.26 Zero or more elements. fo elements 6.3.7.3.3 When generated This primitive is generated by the MLME as a result of an MLME-ASSOCIATE.request primitive or receipt of an Association Response frame from the peer MAC entity to associate with a specified peer MAC entity that is in an AP or PCP. 6.3.7.3.4 Effect of receipt The SME is notified of the results of the association procedure. 291 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.7.4 MLME-ASSOCIATE.indication 6.3.7.4.1 Function This primitive indicates that a specific peer MAC entity is requesting association with the local MAC entity, which is in an AP or PCP. 6.3.7.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-ASSOCIATE.indication( PeerSTAAddress, CapabilityInformation, ListenInterval, SSID, OperationalRateSet, BSSMembershipSelectorSet, RSN, QoSCapability, RCPI, RSNI, RMEnabledCapabilities, Content of FT Authentication elements, SupportedOperatingClasses, DSERegisteredLocation, HT Capabilities, Extended Capabilities, 20/40 BSS Coexistence, QoSTrafficCapability, TIMBroadcastRequest, EmergencyServices, DMG Capabilities, Multi-band local, Multi-band peer, MMS, VHT Capabilities, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MACAddress Any valid individual Specifies the address of the peer MAC entity MAC address from which the association was received. Capability- Capability As defined in 9.4.1.4 Specifies the operational capability definitions Information Information field provided by the peer MAC entity as part of the association request. ListenInterval Integer 0 Specifies the listen interval provided by the peer MAC entity as part of the association request. SSID Octet string 0â€“32 octets Specifies the SSID provided by the peer MAC entity as part of the association request. 292 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description OperationalRateSet Non-DMG BSS: Non-DMG BSS: 1- The set of data rates (in units of 500 kb/s) that the Set of integers 127 excluding values STA that is requesting association is able to use from Table 9-78 for for communication within the BSS. The STA is DMG BSS: Set of each member of the able to receive at each of the data rates listed in numbers set the set. This set is a superset of the rates contained in the BSSBasicRateSet parameter. DMG BSS: 0-24, 9.1, or 12.1-12.6, for DMG BSS: The set of MCS indexes that the AP each member of the or PCP uses for communication within the BSS. set BSSMembershipSel Set of integers A value from The set of features that the STA that is requesting ectorSet Table 9-78, for each association is able to use for communication member of the set RSN RSNE As defined in A description of the cipher suites and AKM 9.4.2.25 suites selected by the STA. QoSCapability QoS Capability As defined in Specifies the parameters within the element 9.4.2.35 QoSCapability that are supported by the peer MAC entity. The parameter is optionally present if dot11QosOptionImplemented is true; otherwise not present. RCPI Integer As defined in The RCPI value represents the measured RCPI of 9.4.2.38 the corresponding Association Request frame. The element is optionally present if dot11RMRCPIMeasurementActivated is true; otherwise not present. RSNI Integer As defined in The RSNI value represents the measured RSNI at 9.4.2.41 the time the corresponding Association Request frame was received. The element is optionally present if dot11RMRSNIMeasurementActivated is true; otherwise not present. RMEnabledCapabil RM Enabled As defined in Specifies the RM enabled capabilities advertised ities Capabilities 9.4.2.45 by the AP or PCP. The element is present if element dot11RadioMeasurementActivated is true; otherwise not present. Content of FT Sequence of As defined in 13.4 The set of elements included in the initial Authentication elements mobility domain association, as described in elements 13.4. Present if dot11FastBSSTransitionActivated is true; otherwise not present. SupportedOperating As defined in the As defined in Indicates the supported operating classes Classes Supported 9.4.2.54 capabilities of the AP or PCP. This parameter is Operating Classes present if element dot11ExtendedChannelSwitchActivated is true; otherwise not present. DSERegisteredLoc As defined in the As defined in Indicates the DSE registered location including ation DSE Registered 9.4.2.52 the dependent enablement identifier assigned by Location element the enabling STA. This parameter is optionally present if dot11LCIDSERequired is true; otherwise not present. HT Capabilities As defined in As defined in Specifies the parameters within the HT frame format 9.4.2.56 Capabilities element that are supported by the MAC entity. The parameter is optionally present if dot11HighThroughputOptionImplemented is true; otherwise not present. Extended As defined in As defined in Specifies the parameters within the Extended Capabilities frame format 9.4.2.27 Capabilities element that are supported by the MAC entity. 293 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description 20/40 BSS As defined in As defined in Specifies the parameters within the 20/40 BSS Coexistence frame format 9.4.2.60 Coexistence element that are indicated by the MAC entity. The parameter is present if dot112040BSSCoexistenceManagementSupport is true. QoS Traffic As defined in the As defined in Specifies the QoS Traffic Capability flags of the Capability QoS Traffic 9.4.2.78 non-AP and non-PCP STA. This parameter is Capability element optionally present if dot11ACStationCountActivated is true and is not present otherwise. TIMBroadcastRequ As defined in TIM As defined in Specifies the proposed service parameters for est Broadcast Request 9.4.2.83 TIM Broadcast. This parameter is optionally element present if dot11TIMBroadcastActivated is true and is not present otherwise. EmergencyServices Boolean true, false Specifies the setting of the UESA field received from the non-AP and non-PCP STA, if an Interworking element was present in the Association Request frame. The parameter is present if dot11InterworkingServiceActivated is true; otherwise not present. DMG Capabilities DMG Capabilities As defined in Specifies the parameters within the DMG element 9.4.2.128 Capabilities element that are supported by the MAC entity. The parameter is present if dot11DMGOptionImplemented is true and is absent otherwise. Multi-band local Multi-band As defined in Specifies the parameters within the Multi-band element 9.4.2.138 element that identify the local MAC entity. The parameter is present if OCT is being used and is absent otherwise. Multi-band peer Multi-band As defined in Specifies the parameters within the Multi-band element 9.4.2.138 element that are supported by the remote (peer) MAC entity. This parameter is present if OCT is being used and is absent otherwise. MMS Multiple MAC As defined in Specifies the parameters within the Multiple Sublayers element 9.4.2.153 MAC Sublayers element that are supported by the MAC entity. The parameter is present if dot11MultipleMACActivated is true and is absent otherwise. VHT Capabilities As defined in As defined in Specifies the parameters in the VHT Capabilities VHT Capabilities 9.4.2.158 element that are supported by the STA. The element parameter is present if dot11VHTOptionImplemented is true and the VHT Capabilities element is present in the Association Request frame received from the STA. The parameter is not present otherwise. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.7.4.3 When generated This primitive is generated by the MLME as a result of the receipt of an association request from a specific peer MAC entity. 6.3.7.4.4 Effect of receipt The SME is notified of the receipt of the association request. 294 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.7.5 MLME-ASSOCIATE.response 6.3.7.5.1 Function This primitive is used to send a response to a specific peer MAC entity that requested an association with the STA that issued this primitive, which is in an AP or PCP. 6.3.7.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-ASSOCIATE.response( PeerSTAAddress, ResultCode, AssociationID, RCPI, RSNI, RMEnabledCapabilities, Content of FT Authentication elements, SupportedOperatingClasses, TimeoutInterval, BSSMaxIdlePeriod, TIMBroadcastResponse, QoSMapSet, Multi-band peer, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MACAddress Any valid individual MAC address Specifies the address of the peer MAC entity from which the association request was received. ResultCode Enumeration SUCCESS, Indicates the result response to REFUSED_REASON_UNSPECIFIED, the association request from the REFUSED_CAPABILITIES_MISMATC peer MAC entity. H, REFUSED_EXTERNAL_REASON, REFUSED_AP_OUT_OF_MEMORY, REFUSED_BASIC_RATES_MISMATC H, REJECTED_EMERGENCY_SERVICE S_NOT_SUPPORTED, REFUSED_TEMPORARILY AssociationID Integer Non-DMG: 1â€“2007 If the association request result DMG: 1â€“254 was SUCCESS, then AssociationID specifies the association ID value assigned to the peer MAC entity by the AP or PCP. RCPI Integer As defined in 9.4.2.38 The RCPI value represents the measured RCPI of the corresponding Association Request frame. The element is optionally present if dot11RMRCPIMeasurementAc tivated is true; otherwise not present. 295 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description RSNI Integer As defined in 9.4.2.41 The RSNI value represents the measured RSNI at the time the corresponding Association Request frame was received. The element is optionally present if dot11RMRSNIMeasurementAc tivated is true; otherwise not present. RMEnabledCapabil RM Enabled As defined in 9.4.2.45 Specifies the RM enabled ities Capabilities capabilities advertised by the element AP or PCP. The element is present if dot11RadioMeasurementActiv ated is true; otherwise not present. Content of FT Sequence of As defined in 13.4 The set of elements to be Authentication elements included in the initial mobility elements domain association response, as described in 13.4. Present if dot11FastBSSTransitionActivat ed is true; otherwise not present. SupportedOperating As defined in the As defined in 9.4.2.54 Indicates the supported Classes Supported operating classes capabilities of Operating the AP or PCP. This parameter Classes element is present if dot11ExtendedChannelSwitch Activated is true. TimeoutInterval Timeout Interval As defined in 9.4.2.49 This parameter is present when element, as ResultCode is defined in frame REFUSED_TEMPORARILY. format BSSMaxIdlePeriod As defined in As defined in 9.4.2.79 Indicates the BSS max idle BSS Max Idle period parameters of the AP or Period element PCP. This parameter is present if dot11WirelessManagementImp lemented is true and is not present otherwise. TIMBroadcastResp As defined in As defined in 9.4.2.84 Specifies the service onse TIM Broadcast parameters for TIM Broadcast. Response This parameter is optionally element present if dot11TIMBroadcastActivated is true and the TIM Broadcast Request element is present in the corresponding Association Request frame; this parameter is not present otherwise. QoSMapSet As defined in As defined in 9.4.2.95 Specifies the QoS Map the non- frame format AP and non-PCP STA should use. Multi-band peer Multi-band As defined in 9.4.2.138 Specifies the parameters within element the Multi-band element that identify the remote (peer) MAC entity. The parameter is present if OCT is being used and is absent otherwise. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 296 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Additional parameters needed to perform the association response procedure are not included in the primitive parameter list since the MLME already has that data (maintained as internal state). 6.3.7.5.3 When generated This primitive is generated by the SME of a STA that is in an AP or PCP as a response to an MLME- ASSOCIATE.indication primitive. 6.3.7.5.4 Effect of receipt This primitive initiates transmission of an AssociationResponse to the specific peer MAC entity that requested association. 6.3.8 Reassociate 6.3.8.1 Introduction The following primitives describe how a STA becomes associated with another AP or PCP. 6.3.8.2 MLME-REASSOCIATE.request 6.3.8.2.1 Function This primitive requests a change in association to a specified new peer MAC entity that is in an AP or PCP. 6.3.8.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-REASSOCIATE.request( NewPCPorAPAddress, ListenInterval, Supported Channels RSN, QoSCapability, Content of FT Authentication elements, SupportedOperatingClasses, SM Power Save, QoSTrafficCapability, TIMBroadcastRequest, FMSRequest, DMSRequest, EmergencyServices, DMG Capabilities, Multi-band local, Multi-band peer, MMS, VendorSpecificInfo ) 297 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description NewPCPorAPAddr MACAddress Any valid individual Specifies the address of the peer MAC ess MAC address entity with which to perform the reassociation process. ListenInterval Integer 0 Specifies how often the STA awakens and listens for the next Beacon frame, if it enters power save mode. Supported Channels As defined in the As defined in the The list of channels in which the STA is Supported Channels Supported Channels capable of operating. element element Present if DFS functionality is required, as specified in 11.9; otherwise not present. RSN RSNE As defined in A description of the cipher suites and 9.4.2.25 AKM suites selected by the STA. QoSCapability QoS Capability As defined in Specifies the parameters within the QoS element 9.4.2.35 Capability element that are supported by the MAC entity. The parameter is present if dot11QosOptionImplemented is true; otherwise not present. Content of FT Sequence of elements As defined in 13.8 The set of elements to be included in the Authentication third message of the FT authentication elements sequence, as described in 13.8.4. Present if dot11FastBSSTransitionActivated is true; otherwise not present. SupportedOperating As defined in the As defined in Specifies the supported operating classes Classes Supported Operating 9.4.2.54 of the STA. This parameter is present if Classes element dot11ExtendedChannelSwitchActivated is true. SM Power Save Integer As defined in Indicates the spatial multiplexing power Table 9-162 save mode that is in operation immediately after reassociation. QoS Traffic As defined in the As defined in Specifies the QoS Traffic Capability flags Capability QoS Traffic 9.4.2.78 of the non-AP and non-PCP STA. This Capability element parameter is optionally present if dot11ACStationCountActivated is true and is not present otherwise. TIMBroadcastRequ As defined in TIM As defined in Specifies the proposed service parameters est Broadcast Request 9.4.2.83 for TIM Broadcast. This parameter is element optionally present if dot11TIMBroadcastActivated is true and is not present otherwise. FMSRequest As defined in FMS As defined in Specifies the proposed multicast Request element 9.4.2.76 parameters for FMS Request. This parameter is optionally present if dot11FMSActivated is true and is not present otherwise. DMSRequest Sequence of DMS As defined in Specifies the proposed multicast Request elements 9.4.2.88 parameters for DMS Request. This parameter is optionally present if dot11DMSActivated is true and is not present otherwise. EmergencyServices Boolean true, false Specifies that the non-AP and non-PCP STA intends to reassociate for the purpose of unauthenticated access to emergency services. The parameter shall only be present if dot11InterworkingServiceActivated is true. 298 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description DMG Capabilities DMG Capabilities As defined in Specifies the parameters within the DMG element 9.4.2.128 Capabilities element that are supported by the MAC entity. The parameter is present if dot11DMGOptionImplemented is true and is absent otherwise. Multi-band local Multi-band element As defined in Specifies the parameters within the Multi- 9.4.2.138 band element that are supported by the local MAC entity. The parameter is present if dot11MultibandImplemented is true and is absent otherwise. Multi-band peer Multi-band element As defined in Specifies the parameters within the Multi- 9.4.2.138 band element that identify the remote (peer) MAC entity. The parameter is present if OCT is being used and is absent otherwise. MMS Multiple MAC As defined in Specifies the parameters within the Sublayers element 9.4.2.153 Multiple MAC Sublayers element that are supported by the MAC entity. The parameter is present if dot11MultipleMACActivated is true and is absent otherwise. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 Additional parameters needed to perform the reassociation procedure are not included in the primitive parameter list since the MLME already has that data (maintained as internal state). 6.3.8.2.3 When generated This primitive is generated by the SME for a STA to change association to a specified new peer MAC entity that is in an AP or PCP. 6.3.8.2.4 Effect of receipt This primitive initiates a reassociation procedure. In the case that a response is received from the responder STA, the MLME subsequently issues an MLME-REASSOCIATE.confirm primitive that reflects the results. 6.3.8.3 MLME-REASSOCIATE.confirm 6.3.8.3.1 Function This primitive reports the results of a reassociation attempt with a specified peer MAC entity that is in an AP or PCP. 6.3.8.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-REASSOCIATE.confirm( ResultCode, CapabilityInformation, AssociationID, EDCAParameterSet, RCPI of Request, RSNI of Request, RCPI of Response, 299 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications RSNI of Response, RMEnabledCapabilities, Content of FT Authentication elements, SupportedOperatingClasses, Extended Capabilities, 20/40 BSS Coexistence, TimeoutInterval, BSSMaxIdlePeriod, TIMBroadcastResponse, FMSResponse, DMSResponse, QoSMapSet, QMFPolicy, DMG Capabilities, Multi-band local, Multi-band peer, MMS, VendorSpecificInfo ) Name Type Valid range Description ResultCode Enumeration SUCCESS, Indicates the result of the MLME- REFUSED_REASON_UNSPE REASSOCIATE.request primitive. CIFIED, REFUSED_NOT_AUTHENTI CATED, REFUSED_CAPABILITIES_M ISMATCH, REFUSED_EXTERNAL_REA SON, REFUSED_AP_OUT_OF_ME MORY, REFUSED_BASIC_RATES_MI SMATCH, REJECTED_EMERGENCY_S ERVICES_NOT_SUPPORTED, REFUSED_TEMPORARILY Capability- Capability As defined in 9.4.1.4 Specifies the operational capabilities Information Information advertised by the AP or PCP. field AssociationID Integer Non-DMG: 1â€“2007 If the association request result was DMG: 1â€“254 SUCCESS, then AssociationID specifies the association ID value assigned by the AP or PCP. EDCAParameterSet EDCA As defined in 9.4.2.29 Specifies the EDCA parameter set that Parameter the STA should use. The parameter is Set element present if dot11QosOptionImplemented is true; otherwise not present. RCPI of Request Integer As defined in 9.4.2.38 Indicates the RCPI value contained in the received Reassociation Response frame. This value represents the RCPI that the AP or PCP measured at the time it received the corresponding Reassociation Request frame. The element is optionally present if dot11RMRCPIMeasurementActivated is true; otherwise not present. 300 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description RSNI of Request Integer As defined in 9.4.2.41 Indicates the RSNI value contained in the received Reassociation Response frame. This value represents the RSNI that the AP or PCP measured at the time it received the corresponding Reassociation Request frame. The element is optionally present if dot11RMRSNIMeasurementActivated is true; otherwise not present. RCPI of Response Integer As defined in 9.4.2.38 The RCPI value represents the measured RCPI of the corresponding Reassociation Response frame. The element is optionally present if dot11RMRCPIMeasurementActivated is true; otherwise not present. RSNI of Response Integer As defined in 9.4.2.41 RSNI at the time the corresponding Reassociation Response frame was received. The element is optionally present if dot11RMRSNIMeasurementActivated is true; otherwise not present. RMEnabledCapabil RM Enabled As defined in 9.4.2.45 Specifies the RM enabled capabilities ities Capabilities advertised by the AP or PCP. The element element is present if dot11RadioMeasurementActivated is true; otherwise not present. Content of FT Sequence of As defined in 13.8 The set of elements included in the fourth Authentication elements message of the FT authentication elements sequence, as described in 13.8.5. This includes an optional response to a resource request (RIC). Present if dot11FastBSSTransitionActivated is true; otherwise not present. SupportedOperating As defined in As defined in 9.4.2.54 Specifies the supported operating classes Classes the of the STA. This parameter is present if Supported dot11ExtendedChannelSwitchActivated Operating is true; otherwise not present. Classes element Extended As defined in As defined in 9.4.2.27 Specifies the parameters within the Capabilities frame format Extended Capabilities element that are supported by the MAC entity. 20/40 BSS As defined in As defined in 9.4.2.60 Specifies the parameters within the 20/40 Coexistence frame format BSS Coexistence element that are indicated by the MAC entity. The parameter is present if dot112040BSSCoexistenceManagement Support is true. TimeoutInterval Timeout As defined in 9.4.2.49 This parameter is present when Interval ResultCode is element, as REFUSED_TEMPORARILY. defined in frame format BSSMaxIdlePeriod As defined in As defined in 9.4.2.79 Indicates the BSS max idle period BSS Max parameters of the AP or PCP. This Idle Period parameter is present if element dot11WirelessManagementImplemented is true and is not present otherwise. 301 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description TIMBroadcastResp As defined in As defined in 9.4.2.84 Specifies the service parameters for TIM onse TIM Broadcast. This parameter is optionally Broadcast present if dot11TIMBroadcastActivated Response is true and the TIM Broadcast Request element element is present in the corresponding Association Request frame; this parameter is not present otherwise. FMSResponse As defined in As defined in 9.4.2.77 Specifies the multicast parameters for FMS FMS Response. This parameter is Response optionally present if dot11FMSActivated element is true and the FMS Request element is present in the corresponding Association Request frame; this parameter is not present otherwise. DMSResponse Sequence of As defined in 9.4.2.89 Specifies the multicast parameters for DMS DMS Response. This parameter is Response optionally present if dot11DMSActivated elements is true and the DMS Request element is present in the corresponding Association Request frame; this parameter is not present otherwise. QoSMapSet As defined in As defined in 9.4.2.95 Specifies the QoS Map the non-AP and frame format non-PCP STA should use. QMFPolicy QMF Policy As defined in 9.4.2.120 Describes the QMF policy of the AP. This element parameter is present when dot11QMFActivated is true and is not present otherwise. DMG Capabilities DMG As defined in 9.4.2.128 Specifies the parameters within the DMG Capabilities Capabilities element that are supported element by the MAC entity. The parameter is present if dot11DMGOptionImplemented is true and is absent otherwise. Multi-band local Multi-band As defined in 9.4.2.138 Specifies the parameters within the element Multi-band element that identify the local MAC entity. The parameter is present if OCT is being used and is absent otherwise. Multi-band peer Multi-band As defined in 9.4.2.138 Specifies the parameters within the element Multi-band element that are supported by the remote (peer) MAC entity. This parameter is present if OCT is being used and is absent otherwise. MMS Multiple As defined in 9.4.2.153 Specifies the parameters within the MAC Multiple MAC Sublayers element that Sublayers are supported by the MAC entity. The element parameter is present if dot11MultipleMACActivated is true and is absent otherwise. VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements. elements 6.3.8.3.3 When generated This primitive is generated by the MLME as a result of an MLME-REASSOCIATE.request primitive to reassociate with a specified peer MAC entity that is in an AP or PCP. 302 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.8.3.4 Effect of receipt The SME is notified of the results of the reassociation procedure. 6.3.8.4 MLME-REASSOCIATE.indication 6.3.8.4.1 Function This primitive indicates that a specific peer MAC entity is requesting reassociation with the local MAC entity, which is in an AP or PCP. 6.3.8.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-REASSOCIATE.indication( PeerSTAAddress, CurrentAPAddress, CapabilityInformation, ListenInterval, SSID, OperationalRateSet, BSSMembershipSelectorSet, RSN, QoSCapability, RCPI, RSNI, RMEnabledCapabilities, Content of FT Authentication elements, SupportedOperatingClasses, DSERegisteredLocation, HT Capabilities, Extended Capabilities, 20/40 BSS Coexistence, QoSTrafficCapability, TIMBroadcastRequest, FMSRequest, DMSRequest, EmergencyServices, DMG Capabilities, Multi-band local, Multi-band peer, MMS, VHT Capabilities, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MACAddress Any valid individual Specifies the address of the peer MAC MAC address entity from which the reassociation request was received. CurrentAPAddress MACAddress Any valid individual Specifies the address of the AP or PCP with MAC address which the peer STA is currently associated. 303 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description Capability- Capability As defined in 9.4.1.4 Specifies the operational capability Information Information field definitions provided by the peer MAC entity as part of the reassociation request. ListenInterval Integer 0 Specifies the listen interval provided by the peer MAC entity as part of the reassociation request. SSID Octet string 0â€“32 octets Specifies the desired SSID provided by the peer MAC entity as part of the reassociation request. OperationalRateSet Non-DMG BSS: Set Non-DMG BSS: 1- The set of data rates (in units of 500 kb/s) of integers 127 excluding values that the STA that is requesting association is from Table 9-78 for able to use for communication within the DMG BSS: Set of each member of the BSS. The STA is able to receive at each of numbers set the data rates listed in the set. This set is a superset of the rates contained in the DMG BSS: 0-24, BSSBasicRateSet parameter. 9.1, or 12.1-12.6, for each member of the DMG BSS: The set of MCS indexes that the set AP or PCP uses for communication within the BSS. BSSMembershipSe Set of integers A value from The set of features that the STA that is lectorSet Table 9-78, for each requesting association is able to use for member of the set communication RSN RSNE As defined in A description of the cipher suites and AKM 9.4.2.25 suites selected by the STA. QoSCapability QoS Capability As defined in Specifies the parameters within the QoS element 9.4.2.35 Capability that are supported by the peer MAC entity. The parameter is present if dot11QosOptionImplemented is true; otherwise not present. RCPI Integer As defined in The RCPI value represents the measured 9.4.2.38 RCPI of the corresponding Reassociation Request frame. The element is optionally present if dot11RMRCPIMeasurementActivated is true; otherwise not present. RSNI Integer As defined in The RSNI value represents the measured 9.4.2.41 RSNI at the time the corresponding Reassociation Request frame was received. The element is optionally present if dot11RMRSNIMeasurementActivated is true; otherwise not present. RMEnabledCapabi RM Enabled As defined in Specifies the RM enabled capabilities lities Capabilities element 9.4.2.45 advertised by the AP or PCP. The element is present if dot11RadioMeasurementActivated is true; otherwise not present. Content of FT Sequence of elements As defined in 13.8 The set of elements included in the third Authentication message of the FT authentication sequence, elements as described in 13.8.4. Present if dot11FastBSSTransitionActivated is true; otherwise not present. SupportedOperatin As defined in the As defined in Specifies the supported operating classes of gClasses Supported Operating 9.4.2.54 the STA. This parameter is present if Classes element dot11ExtendedChannelSwitchActivated is true; otherwise not present. 304 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description DSERegisteredLoc As defined in the As defined in Indicates the DSE registered location ation DSE Registered 9.4.2.52 including the dependent enablement Location element identifier assigned by the enabling STA. This parameter is optionally present if dot11LCIDSERequired is true; otherwise not present. HT Capabilities As defined in frame As defined in Specifies the parameters within the HT format 9.4.2.56 Capabilities element that are supported by the MAC entity. The parameter is optionally present if dot11HighThroughputOptionImplemented is true. Extended As defined in frame As defined in Specifies the parameters within the Capabilities format 9.4.2.27 Extended Capabilities element that are supported by the MAC entity. 20/40 BSS As defined in frame As defined in Specifies the parameters within the 20/40 Coexistence format 9.4.2.60 BSS Coexistence element that are indicated by the MAC entity. The parameter is present if dot112040BSSCoexistenceManagementSu pport is true. QoS Traffic As defined in the As defined in Specifies the QoS Traffic Capability flags Capability QoS Traffic 9.4.2.78 of the non-AP and non-PCP STA. This Capability element parameter is optionally present if dot11ACStationCountActivated is true and is not present otherwise. TIMBroadcastReq As defined in TIM As defined in Specifies the proposed service parameters uest Broadcast Request 9.4.2.83 for TIM Broadcast. This parameter is element optionally present if dot11TIMBroadcastActivated is true and is not present otherwise. FMSRequest As defined in FMS As defined in Specifies the proposed multicast parameters Request element 9.4.2.76 for FMS Request. This parameter is optionally present if dot11FMSActivated is true and is not present otherwise. DMSRequest Sequence of DMS As defined in Specifies the proposed multicast parameters Request elements 9.4.2.88 for DMS Request. This parameter is optionally present if dot11DMSActivated is true and is not present otherwise. EmergencyService Boolean true, false Specifies the setting of the UESA field s received from the non-AP and non-PCP STA, if an Interworking element was present in the Reassociation Request frame. The parameter is present if dot11InterworkingServiceActivated is true; otherwise not present. DMG Capabilities DMG Capabilities As defined in Specifies the parameters within the DMG element 9.4.2.128 Capabilities element that are supported by the MAC entity. The parameter is present if dot11DMGOptionImplemented is true and is absent otherwise. Multi-band local Multi-band element As defined in Specifies the parameters within the Multi- 9.4.2.138 band element that identify the local MAC entity. The parameter is present if dot11MultibandImplemented is true and is absent otherwise. 305 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description Multi-band peer Multi-band element As defined in Specifies the parameters within the Multi- 9.4.2.138 band element that are supported by the remote (peer) MAC entity. This parameter is present if OCT is being used and is absent otherwise. MMS Multiple MAC As defined in Specifies the parameters within the Sublayers element 9.4.2.153 Multiple MAC Sublayers element that are supported by the MAC entity. The parameter is present if dot11MultipleMACActivated is true and is absent otherwise. VHT Capabilities As defined in VHT As defined in Specifies the parameters in the VHT Capabilities element 9.4.2.158 Capabilities element that are supported by the STA. The parameter is present if dot11VHTOptionImplemented is true and the VHT Capabilities element is present in the Reassociation Request frame received from the STA. The parameter is not present otherwise. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.8.4.3 When generated This primitive is generated by the MLME as a result of the establishment of a reassociation with a specific peer MAC entity that resulted from a reassociation procedure that was initiated by that specific peer MAC entity. 6.3.8.4.4 Effect of receipt The SME is notified of the establishment of the reassociation. 6.3.8.5 MLME-REASSOCIATE.response 6.3.8.5.1 Function This primitive is used to send a response to a specific peer MAC entity that requested a reassociation with the STA that issued this primitive, which is in an AP or PCP. 6.3.8.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-REASSOCIATE.response( PeerSTAAddress, ResultCode, AssociationID, RCPI, RSNI, RMEnabledCapabilities, Content of FT Authentication elements, SupportedOperatingClasses, TimeoutInterval, BSSMaxIdlePeriod, TIMBroadcastResponse, FMSResponse, 306 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DMSResponse, QoSMapSet, Multi-band peer, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MACAddress Any valid individual MAC address Specifies the address of the peer MAC entity from which the reassociation request was received. ResultCode Enumeration SUCCESS, Indicates the result response to REFUSED_REASON_UNSPECIFIED, the reassociation request from REFUSED_CAPABILITIES_MISMATC the peer MAC entity. H, REFUSED_EXTERNAL_REASON, REFUSED_AP_OUT_OF_MEMORY, REFUSED_BASIC_RATES_MISMATC H REJECTED_EMERGENCY_SERVICE S_NOT_SUPPORTED, REFUSED_TEMPORARILY AssociationID Integer Non-DMG: 1â€“2007 If the reassociation request DMG: 1â€“254 result was SUCCESS, then AssociationID specifies the association ID value assigned to the peer MAC entity by the AP or PCP. RCPI Integer As defined in 9.4.2.38 The RCPI value represents the measured RCPI of the corresponding Reassociation Request frame. The element is optionally present if dot11RMRCPIMeasurementAc tivated is true; otherwise not present. RSNI Integer As defined in 9.4.2.41 The RSNI value represents the measured RSNI at the time the corresponding Reassociation Request frame was received. The element is optionally present if dot11RMRSNIMeasurementAc tivated is true; otherwise not present. RMEnabledCapabil RM Enabled As defined in 9.4.2.45 Specifies the RM enabled ities Capabilities capabilities advertised by the element AP or PCP. The element is present if dot11RadioMeasurementActiv ated is true; otherwise not present. Content of FT Sequence of As defined in 13.8 The set of elements to be Authentication elements included in the fourth message elements of the FT authentication sequence, as described in 13.8.5. This includes an optional response to a resource request (RIC). Present if dot11FastBSSTransitionActivat ed is true; otherwise not present. 307 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description SupportedOperating As defined in As defined in 9.4.2.54 Specifies the supported Classes the Supported operating classes of the STA. Operating This parameter is present if Classes dot11ExtendedChannelSwitch element Activated is true. TimeoutInterval Timeout As defined in 9.4.2.49 This parameter is present when Interval ResultCode is element, as REFUSED_TEMPORARILY. defined in frame format BSSMaxIdlePeriod As defined in As defined in 9.4.2.79 Indicates the BSS max idle BSS Max Idle period parameters of the AP or Period PCP. This parameter is present element if dot11WirelessManagementImp lemented is true and is not present otherwise. TIMBroadcastResp As defined in As defined in 9.4.2.84 Specifies the service onse TIM parameters for TIM Broadcast. Broadcast This parameter is optionally Response present if element dot11TIMBroadcastActivated is true and the TIM Broadcast Request element is present in the corresponding Association Request frame; this parameter is not present otherwise. FMSResponse As defined in As defined in 9.4.2.77 Specifies the multicast FMS parameters for FMS Response. Response This parameter is optionally element present if dot11FMSActivated is true and the FMS Request element is present in the corresponding Association Request frame; this parameter is not present otherwise. DMSResponse Sequence of As defined in 9.4.2.89 Specifies the multicast DMS parameters for DMS Response. Response This parameter is optionally elements present if dot11DMSActivated is true and the DMS Request element is present in the corresponding Association Request frame; this parameter is not present otherwise. QoSMapSet As defined in As defined in 9.4.2.95 Specifies the QoS Map the non- frame format AP and non-PCP STA should use. Multi-band peer Multi-band As defined in 9.4.2.138 Specifies the parameters within element the Multi-band element that identify the remote (peer) MAC entity. The parameter is present if OCT is being used and is absent otherwise. VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements. elements Additional parameters needed to perform the reassociation response procedure are not included in the primitive parameter list since the MLME already has that data (maintained as internal state). 308 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.8.5.3 When generated This primitive is generated by the SME of a STA that is in an AP or PCP as a response to an MLME- REASSOCIATE.indication primitive. 6.3.8.5.4 Effect of receipt This primitive initiates transmission of a response to the specific peer MAC entity that requested reassociation. 6.3.9 Disassociate 6.3.9.1 MLME-DISASSOCIATE.request 6.3.9.1.1 Function This primitive requests disassociation with a specified peer MAC entity. 6.3.9.1.2 Semantics of the service primitive The primitive parameters are as follows: MLME-DISASSOCIATE.request( PeerSTAAddress, ReasonCode, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MACAddress Any valid individual Specifies the address of the peer MAC MAC address entity with which to perform the disassociation process. ReasonCode Reason Code field As defined in 9.4.1.7 Specifies the reason for initiating the disassociation procedure. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.9.1.3 When generated This primitive is generated by the SME for a STA to disassociate from a STA with which it has an association. 6.3.9.1.4 Effect of receipt This primitive initiates a disassociation procedure. The MLME subsequently issues an MLME-DISASSOCIATE.confirm primitive that reflects the results. 6.3.9.2 MLME-DISASSOCIATE.confirm 6.3.9.2.1 Function This primitive reports the results of a disassociation procedure with a specific peer MAC entity. 309 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.9.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-DISASSOCIATE.confirm() 6.3.9.2.3 When generated This primitive is generated by the MLME as a result of an MLME-DISASSOCIATE.request primitive to disassociate with a specified peer MAC entity. 6.3.9.2.4 Effect of receipt The SME is notified of the results of the disassociation procedure. 6.3.9.3 MLME-DISASSOCIATE.indication 6.3.9.3.1 Function This primitive reports disassociation with a specific peer MAC entity. 6.3.9.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-DISASSOCIATE.indication( PeerSTAAddress, ReasonCode, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MACAddress Any valid individual Specifies the address of the peer MAC MAC address entity with which the association relationship was invalidated. ReasonCode Reason Code field As defined in Specifies the reason the disassociation 9.4.1.7 procedure was initiated. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.9.3.3 When generated This primitive is generated by the MLME as a result of the invalidation of an association relationship with a specific peer MAC entity. 6.3.9.3.4 Effect of receipt The SME is notified of the invalidation of the specific association relationship. 6.3.10 Reset 6.3.10.1 Introduction This mechanism supports the process of resetting the MAC. 310 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.10.2 MLME-RESET.request 6.3.10.2.1 Function This primitive requests that the MAC entity be reset. 6.3.10.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-RESET.request( STAAddress, SetDefaultMIB ) Name Type Valid range Description STAAddress MACAddress Any valid individual Specifies the MAC address that is to be used by the MAC address MAC entity that is being reset. This value can be used to provide a locally administered STA address. SetDefaultMIB Boolean true, false If true, all MIB attributes are set to their default values. The default values are implementation dependent. If false, the MAC is reset, but all MIB attributes retain the values that were in place prior to the generation of the MLME-RESET.request primitive. 6.3.10.2.3 When generated This primitive is generated by the SME to reset the MAC to initial conditions. The MLME-RESET.request primitive shall be used prior to use of the MLME-START.request primitive. 6.3.10.2.4 Effect of receipt This primitive sets the MAC to initial conditions, clearing all internal variables to the default values. MIB attributes can be reset to their implementation dependent default values by setting the SetDefaultMIB flag to true. If dot11OCBActivated is true and if the SetDefaultMIB parameter is false, MAC operation shall resume in less than 2 TU after the STAAddress parameter is changed. 6.3.11 Start 6.3.11.1 Introduction This mechanism supports the process of creating a new BSS or becoming a member of an MBSS. 6.3.11.2 MLME-START.request 6.3.11.2.1 Function This primitive requests that the MAC entity start a new BSS or become a member of an MBSS. 6.3.11.2.2 Semantics of the service primitive The primitive parameters are as follows: 311 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MLME-START.request( SSID, BSSType, BeaconPeriod, DTIMPeriod, CF parameter set, PHY parameter set, IBSS parameter set, NAVSyncDelay, CapabilityInformation, BSSBasicRateSet, OperationalRateSet, Country, IBSS DFS Recovery Interval, EDCAParameterSet, DSERegisteredLocation, HT Capabilities, HT Operation, BSSMembershipSelectorSet, Extended Capabilities, 20/40 BSS Coexistence, Overlapping BSS Scan Parameters, MultipleBSSID, InterworkingInfo, AdvertisementProtocolInfo, RoamingConsortiumInfo, Mesh ID, Mesh Configuration, QMFPolicy, DMG Capabilities, Multi-band, MMS, DMG Operation, Clustering Control, CBAP Only, PCP Association Ready, VHT Capabilities, VHT Operation, VendorSpecificInfo ) Name Type Valid range Description SSID Octet string 0â€“32 octets The SSID of the BSS. BSSType Enumeration INFRASTRUCTURE, The type of the BSS. INDEPENDENT, MESH, PERSONAL Beacon Period Integer 1 The beacon period (in TU) of the BSS if the BSSType is not MESH, or of the mesh STA if the BSSType is MESH. DTIM Period Integer As defined in 9.4.2.6 The DTIM Period (in beacon periods) of the BSS if the BSSType is not MESH, or of the mesh STA if the BSSType is MESH. CF parameter set CF Parameter As defined in 9.4.2.5 The parameter set for CF periods, if the BSS Set element supports CF mode. 312 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description PHY parameter sets DSSS As defined in 9.4.2.4 The parameter sets relevant to the PHY. Parameter Set element IBSS parameter set IBSS As defined in 9.4.2.7 The parameter set for the IBSS, if BSS is an Parameter Set IBSS. element NAVSyncDelay Integer N/A Delay (in microseconds) to be used, while the STA is a member of this BSS, prior to transmitting when changing from doze to awake state, if no frame is detected by which the NAV can be set. CapabilityInformation Capability As defined in 9.4.1.4 The capabilities to be advertised for the BSS. Information field BSSBasicRateSet Set of integers Non-DMG BSS: a value Non-DMG BSS: The set of data rates (in in both units of 500 kb/s) that all STAs in the BSS dot11SupportedDataRat are able to use for communication. All STAs esRxTable and in the BSS including the STA that is creating dot11SupportedDataRat the BSS, are able to receive and transmit at esTxTable for each each of the data rates listed in the set. member of the set DMG BSS: Empty. OperationalRateSet Non-DMG Non-DMG BSS: a value Non-DMG BSS: The set of data rates (in BSS: Set of in units of 500 kb/s) that the STA is able to use integers dot11SupportedDataRat for communication within the BSS. The STA esRxTable for each is able to receive at each of the data rates DMG BSS: member of the set listed in the set. This set is a superset of the Set of numbers rates contained in the BSSBasicRateSet DMG BSS: 0-24, 9.1, or parameter. 12.1-12.6, for each member of the set DMG BSS: The set of MCS indexes that the STA uses for communication within the BSS. Country As defined in As defined in the The information required to identify the the Country Country element regulatory domain in which the STA is element located and to configure its PHY for operation in that regulatory domain. Present if TPC functionality is required, as specified in 11.8 or dot11MultiDomainCapabilityActivated is true; otherwise not present. IBSS DFS Recovery Integer 1â€“255 The time interval that is used for DFS Interval recovery. Present if DFS functionality is required, as specified in 11.9 and BSSType = INDEPENDENT; otherwise not present. EDCAParameterSet EDCA As defined in 9.4.2.29 The initial EDCA parameter set values to be (QoS only) Parameter Set used in the BSS. The parameter is present if element dot11QosOptionImplemented is true; otherwise not present. DSERegisteredLocati As defined in As defined in 9.4.2.52 The information for the DSE Registered on the DSE Location element. The parameter is present if Registered dot11LCIDSERequired is true. Location element 313 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description HT Capabilities As defined in As defined in 9.4.2.56; The HT capabilities to be advertised for the frame format the HT-MCSs in the BSS. The parameter is present if HT element are present in dot11HighThroughputOptionImplemented is Capabilities dot11SupportedMCSRx true; otherwise, this parameter is not present. element Table and the highest supported data rate in the element does not exceed dot11HighestSupported DataRate HT Operation As defined in As defined in 9.4.2.57; The additional HT capabilities to be frame format the HT-MCSs in the advertised for the BSS. HT Operation element are present in The parameter is present if element both dot11HighThroughputOptionImplemented is dot11SupportedMCSRx true; otherwise, this parameter is not present. Table and dot11SupportedMCSTx Table BSSMembershipSelec Set of integers A value from Table 9- The set of features that are supported by all torSet 78 for each member of STAs joining this BSS, and by the STA that the set is creating the BSS. Extended Capabilities As defined in As defined in 9.4.2.27 Specifies the parameters within the Extended frame format Capabilities element that are supported by the MAC entity. 20/40 BSS As defined in As defined in 9.4.2.60 Specifies the parameters within the 20/40 Coexistence frame format BSS Coexistence element that are indicated by the MAC entity. The parameter is present if dot112040BSSCoexistence- ManagementSupport is true. Overlapping BSS As defined in As defined in 9.4.2.59 Specifies the parameters within the Scan Parameters frame format Overlapping BSS Scan Parameters element that are indicated by the MAC entity. This parameter is optionally present if dot11FortyMHzOptionImplemented is true; otherwise, it is not present. MultipleBSSID As defined in As defined in Multiple This element is optionally present when Multiple BSSID Element in dot11RMMeasurementPilotActivated is a BSSID 9.4.2.46 value between 2 and 7 and the AP is a Element in member of a multiple BSSID set (see 9.4.2.46 11.11.14) with two or more members, or if dot11MultiBSSIDActivated is true. InterworkingInfo As defined in As defined in Specifies the Interworking capabilities of frame format Interworking element in STA. This field is present when 9.4.2.92 dot11InterworkingServiceActivated is true. AdvertisementProtoco Integer or As defined in Identifies zero or more Advertisement lInfo Sequence of Advertisement Protocol Protocols and advertisement control to be integers element in Table 9-215 used in the BSSs. This field is present when dot11InterworkingServiceActivated is true. RoamingConsortiumI As defined in As defined in roaming Specifies identifying information for SSPs nfo frame format consortium element in whose security credentials can be used to 9.4.2.96 authenticate with the AP. This field is optionally present when dot11InterworkingServiceActivated is true. Mesh ID Octet string 0â€“32 octets The value of MeshID. This element is present if the BSSType = MESH; otherwise not present. 314 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description Mesh As defined in As defined in 9.4.2.98 Specifies the configuration of the mesh STA. Configuration frame format This element is present if the BSSType = MESH; otherwise not present. QMFPolicy QMF Policy As defined in 9.4.2.120 This element is present when element dot11QMFActivated is true and BSSType = INFRASTRUCTURE or MESH, and it is not present otherwise. The element is provided by the SME to signal to the MLME the QMF policy to be used for this BSS. DMG Capabilities DMG As defined in 9.4.2.128 Specifies the parameters within the DMG Capabilities Capabilities element that are supported by element the MAC entity. The parameter is present if dot11DMGOptionImplemented is true and is absent otherwise. Multi-band Multi-band As defined in 9.4.2.138 Specifies the parameters within the Multi- element band element that are supported by the MAC entity. The parameter is present if dot11MultibandImplemented is true and is absent otherwise. MMS Multiple MAC As defined in 9.4.2.153 Specifies the parameters within the Multiple Sublayers MAC Sublayers element that are supported element by the MAC entity. The parameter is present if dot11MultipleMACActivated is true and is absent otherwise. DMG Operation DMG As defined in 9.4.2.128 Specifies the parameters within the DMG Operation Operation element that are supported by the element MAC entity. The parameter is present if dot11DMGOptionImplemented is true and is absent otherwise. Clustering Control Clustering As defined in 9.3.4.2 Specifies the parameters within the Control field Clustering Control field that are supported by the MAC entity. The parameter is present if dot11ClusteringActivated is true and is absent otherwise. CBAP Only Integer 0 or 1 Specifies the setting of the CBAP Only field as defined in 9.3.4.2 PCP Association Integer 0 or 1 Specifies the setting of the PCP Association Ready Ready field as defined in 9.3.4.2 VHT Capabilities As defined in As defined in 9.4.2.158; Specifies the parameters in the VHT VHT the VHT-MCSs in the Capabilities element that are supported by Capabilities element are present in the STA. The parameter is present if element dot11VHTRxVHTMCS dot11VHTOptionImplemented is true and Map/ not present otherwise. dot11VHTTxVHTMCS Map and the highest supported data rates in the element do not exceed dot11VHTRxHighestDa taRateSupported/ dot11VHTTxHighestDa taRateSupported 315 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description VHT Operation As defined in As defined in 9.4.2.159; Provides additional information for operating VHT the VHT-MCSs in the the VHT BSS. The parameter is present if Operation element are present in dot11VHTOptionImplemented is true and element both not present otherwise. dot11VHTRxVHTMCS Map and dot11VHTTxVHTMCS Map VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements. elements 6.3.11.2.3 When generated This primitive is generated by the SME to start an infrastructure BSS (with the MAC entity within an AP), an IBSS (with the MAC entity acting as the first STA in the IBSS), or an MBSS (with the MAC entity acting as the first mesh STA in the MBSS) or to become a member of an existing MBSS or a PBSS (with the MAC entity within a PCP). In an MBSS, this primitive starts the process of mesh beaconing. The MLME-START.request primitive in an MBSS shall be generated before any synchronization or mesh peering have been attempted. The MLME-START.request primitive shall not be used after successful use of the MLME-START.request primitive or successful use of the MLME-JOIN.request primitive without generating an intervening MLME- RESET.request primitive. 6.3.11.2.4 Effect of receipt This primitive initiates the BSS initialization procedure once the current frame exchange sequence is complete. The MLME subsequently issues an MLME-START.confirm primitive that reflects the results of the creation procedure. If the MLME of a non-DMG STA receives an MLME-START.request primitive with a BSSBasicRateSet parameter containing any unsupported rates, the MLME response in the resulting MLME-START.confirm primitive shall contain a ResultCode parameter that is not set to the value SUCCESS. If the MLME of an HT STA receives an MLME-START.request primitive with the Basic HT-MCS Set field of the HT Operation parameter containing any unsupported MCSs, the MLME response in the resulting MLME-START.confirm primitive shall contain a ResultCode parameter that is not set to the value SUCCESS. If the MLME of a VHT STA receives an MLME-START.request primitive with a Basic VHT-MCS And NSS Set field in the VHT Operation parameter containing any unsupported tuple, the MLME response in the resulting MLME-START.confirm primitive shall contain a ResultCode parameter that is not set to the value SUCCESS. If the MLME of a DMG STA receives an MLME-START.request primitive with a BSSBasicRateSet parameter containing any rates, or with the OperationalRateSet parameter containing any unsupported MCSs, the MLME response in the resulting MLME-START.confirm primitive shall contain a ResultCode parameter that is not set to the value SUCCESS. 316 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.11.3 MLME-START.confirm 6.3.11.3.1 Function This primitive reports the results of a BSS creation procedure or a procedure to become a member of an MBSS. 6.3.11.3.2 Semantics of the service primitive The primitive parameter is as follows: MLME-START.confirm( ResultCode ) Name Type Valid range resetDescription ResultCode Enumeration SUCCESS, Indicates the result of the BSS_ALREADY_STARTED_OR_JOINED, MLME-START.request RESET_REQUIRED_BEFORE_ START, primitive. NOT_SUPPORTED 6.3.11.3.3 When generated This primitive is generated by the MLME as a result of an MLME-START.request primitive to create a new BSS or to become a member of an MBSS. 6.3.11.3.4 Effect of receipt The SME is notified of the results of the BSS creation procedure or a procedure to become a member of an MBSS. 6.3.12 Stop 6.3.12.1 General This mechanism supports the process of terminating an existing BSS. 6.3.12.2 MLME-STOP.request 6.3.12.2.1 Function This primitive requests that the MAC entity stop a BSS previously started by using an MLME- START.request primitive 6.3.12.2.2 Semantics of the service primitive The primitive parameter is as follows: MLME-STOP.request( SSID ) Name Type Valid range Description SSID Octet string 0â€“32 octets The SSID of the BSS to be stopped. 317 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.12.2.3 When generated This primitive is generated by the SME to terminate an infrastructure BSS (with the MAC entity within an AP) or a PBSS (with the MAC entity within the PCP). The MLME-STOP.request primitive shall be generated only after successful use of an MLME-START.confirm primitive. The MLME-STOP termination procedure does not reset the MAC to initial conditions. An MLME- RESET.request primitive shall be issued prior to use of the MLME-START.request primitive and subsequent to the use of an MLME-STOP.request primitive. The SME should notify associated non-AP STAs of imminent infrastructure BSS termination before issuing the MLME-STOP.request primitive. This can be done with the BSS transition management procedure, using the Termination information. 6.3.12.2.4 Effect of receipt This primitive initiates the termination of the BSS. All services provided by the AP to an infrastructure BSS, including Beacon and Probe Response frame transmissions and access to the DS, are stopped by the termination. All STAs in an infrastructure BSS are deauthenticated by the termination. In a PBSS, all of the services provided by the PCP, including DMG Beacons, are stopped by the termination. All of the STAs in a PBSS have their RSNA unestablished by the termination. 6.3.13 Protocol layer model for spectrum management and radio measurement The layer management extensions for measurement, TPC, and channel switching assume a certain partition of functionality between the MLME and SME. This partitioning assumes that policy decisions (e.g., regarding measurement and channel switching) reside in the SME, while the protocol for measurement, switch timing, and the associated frame exchanges resides within the MLME (see Figure 6-2). SME Channel Switch Measurement Decision Policy MREQUEST MREPORT MEASURE CHANNEL SWITCH & MLME Channel Switch Measurement Measurement Timing Protocol Frames MAC Timing PLME Figure 6-2â€”Layer management model 318 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The informative diagrams within this subclause further illustrate the protocol layer model adopted. Figure 6-3 and Figure 6-4 depict the measurement process for a peer STA to accept and reject a measurement request, respectively. Figure 6-5 illustrates the TPC adaptation process. Lastly, Figure 6-6 depicts the management process for a channel switch using a Channel Switch Announcement frame. Note that these diagrams are intended as examples and do not depict all possible protocol scenarios, e.g., a measurement request may result in more than one Measurement Report frame as described in 11.9.7 and 11.11. IEEE802.11 STA IEEE802.11 STA SME MLME MLME SME Decision to request measurement from peer STA Measurement/Radio Measurement MLMEâ€MREQUEST.request Request frame MLMEâ€MREQUEST.indication Decision to accept measurement request from peer STA MLMEâ€MEASURE.request Measurement process MLMEâ€MEASURE.confirm Compile measurement report Measurement/Radio Measurement MLMEâ€MREPORT.confirm Report frame MLMEâ€MREPORT.request Measurement request completed Figure 6-3â€”Measurement requestâ€”accepted 319 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications IEEE802.11 STA IEEE802.11 STA SME MLME MLME SME Decision to request measurement from peer STA Measurement/Radio Measurement MLMEâ€MREQUEST.request Request frame MLMEâ€MREQUEST.indication Decision to reject measurement request from peer STA as refuse or incapable Measurement/Radio Measurement MLMEâ€MREPORT.confirm Report frame MLMEâ€MREPORT.request Measurement request completed Figure 6-4â€”Measurement requestâ€”rejected IEEE802.11 STA IEEE802.11 STA SME MLME MLME SME Decision to adapt transmit power MLMEâ€TPCADAPT.request TPC Request frame TPC Protocol TPC Report frame TPC Protocol MLMEâ€TPCADAPT.confirm Figure 6-5â€”TPC adaptation 320 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications IEEE 802.11 STA IEEE 802.11 STA SME MLME MLME SME Decision to switch channel Channel Switch MLME - CHANNEL Announcement frame MLME- CHANNEL SWITCH.request (multiple) SWITCH.indication Decision to follow switch MLME- CHANNEL SWITCH.response Channel switch Channel switch via PLME via PLME MLME - CHANNEL SWITCH.confirm Channel switch complete Figure 6-6â€”Channel switching 6.3.14 Measurement request 6.3.14.1 Introduction This set of primitives supports the signaling of measurement requests between peer SMEs. 6.3.14.2 MLME-MREQUEST.request 6.3.14.2.1 Function This primitive requests the transmission of a measurement request to a peer entity. 6.3.14.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-MREQUEST.request( Peer MAC Address, Dialog Token, Measurement Request Set, Number of Repetitions, Measurement Category, VendorSpecificInfo ) 321 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description Peer MAC Address MACAddress Any valid individual The address of the peer MAC entity to or group MAC which the measurement request is address transmitted. Dialog Token Integer 1â€“255 The dialog token to identify the measurement transaction. Measurement Set of measurement Set of measurement A set of measurement requests, each Request Set requests, each as requests, each as containing a measurement token, defined in the defined in 9.4.2.21 measurement request mode, measurement Measurement type, and measurement request. Request element format Number of Integer 0 â€“ 65 535 The number of times the Measurement Repetitions Request Set is to be repeated. The parameter is present if Measurement Category is Radio Measurement and dot11RadioMeasurementActivated is true; otherwise not present. Measurement Enumeration SPECTRUM Indicates whether the contents of the Category MANAGEMENT, or Measurement Report Set parameter is a RADIO set of Spectrum Management requests or MEASUREMENT a set of Radio Measurement requests. The parameter is present if dot11RadioMeasurementActivated is true; otherwise not present. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.14.2.3 When generated This primitive is generated by the SME to request that a Measurement Request frame be sent to a peer entity to initiate one or more measurements. 6.3.14.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a Measurement Request frame containing the set of Measurement Request elements specified. This frame is then scheduled for transmission. 6.3.14.3 MLME-MREQUEST.indication 6.3.14.3.1 Function This primitive indicates that a Measurement Request frame has been received requesting the measurement of one or more channels. 6.3.14.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-MREQUEST.indication( Peer MAC Address, Dialog Token, Measurement Request Set, Number of Repetitions, 322 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Measurement Category, VendorSpecificInfo ) Name Type Valid range Description Peer MAC Address MACAddress Any valid individual The address of the peer MAC entity from MAC address which the measurement request was received. Dialog Token Integer 1â€“255 The dialog token to identify the measurement transaction. Measurement Set of measurement Set of measurement A set of measurement requests, each Request Set requests, each as requests, each as containing a Measurement Token, defined in the defined in 9.4.2.21 Measurement Request Mode, Measurement Measurement Type, and Measurement Request element Request. format Number of Integer 0 â€“ 65 535 The number of times the Measurement Repetitions Request Set is to be repeated. The parameter is present if Measurement Category is Radio Measurement and dot11RadioMeasurementActivated is true; otherwise not present. Measurement Enumeration SPECTRUM Indicates whether the contents of the Category MANAGEMENT, or Measurement Report Set parameter is a RADIO set of Spectrum Management requests or MEASUREMENT a set of Radio Measurement requests. The parameter is present if dot11RadioMeasurementActivated is true; otherwise not present. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.14.3.3 When generated This primitive is generated by the MLME when a valid Measurement Request frame is received. 6.3.14.3.4 Effect of receipt On receipt of this primitive, the SME either rejects the request or commences the requested measurements. 6.3.15 Channel measurement 6.3.15.1 Introduction This set of primitives supports the requesting and reporting of measurement data. 6.3.15.2 MLME-MEASURE.request 6.3.15.2.1 Function This primitive is generated by the SME to request that the MLME initiate specified measurements. 6.3.15.2.2 Semantics of the service primitive The primitive parameters are as follows: 323 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MLME-MEASURE.request( Dialog Token, Measurement Request Set ) Name Type Valid range Description Dialog Token Integer 0â€“255 The dialog token to identify the measurement transaction. Measurement Set of measurement Set of measurement A set of measurement requests, each Request Set requests, each as requests, each as containing a Measurement Token, defined in the defined in 9.4.2.21 Measurement Request Mode, Measurement Measurement Type, and Measurement Request element Request. 6.3.15.2.3 When generated This primitive is generated by the SME to request that the MLME initiate the specified measurements. 6.3.15.2.4 Effect of receipt On receipt of this primitive, the MLME commences the measurement process. 6.3.15.3 MLME-MEASURE.confirm 6.3.15.3.1 Function This primitive reports the result of a measurement. 6.3.15.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-MEASURE.confirm( Dialog Token, Measurement Report Set, ) Name Type Valid range Description Dialog Token Integer 0â€“255 The dialog token to identify the measurement transaction. Measurement Set of measurement Set of measurement reports, A set of measurement reports, Report Set reports, each as each as defined in 9.4.2.22 each containing a Measurement defined in the Token, Measurement Report Measurement Report Mode, Measurement Type, and element Measurement Report. 6.3.15.3.3 When generated This primitive is generated by the MLME to report the results when a measurement set completes. 6.3.15.3.4 Effect of receipt On receipt of this primitive, the SME evaluates the result code and, if appropriate, stores the channel measurements pending communication to the requesting entity or for local use. 324 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.16 Measurement report 6.3.16.1 Introduction This set of primitives supports the signaling of measurement reports. 6.3.16.2 MLME-MREPORT.request 6.3.16.2.1 Function This primitive supports the signaling of measurement reports between peer SMEs. 6.3.16.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-MREPORT.request( Peer MAC Address, Dialog Token, Measurement Report Set, Measurement Category, VendorSpecificInfo ) Name Type Valid range Description Peer MAC Address MACAddress Any valid individual The address of the peer MAC entity to MAC address which the measurement report is sent. Dialog Token Integer 0â€“255 The dialog token to identify the measurement transaction. Set to 0 for an autonomous report. Measurement Report Set of measurement Set of measurement A set of measurement reports, each Set reports, each as reports, each as containing a Measurement Token, defined in the defined in 9.4.2.22 Measurement Report Mode, Measurement Report Measurement Type, and Measurement element format Report. Measurement Enumeration SPECTRUM Indicates whether the Measurement Category MANAGEMENT, or Report Set is a set of Spectrum RADIO Management or Radio Measurement MEASUREMENT reports. The parameter is present if dot11RadioMeasurementActivated is true; otherwise not present. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.16.2.3 When generated This primitive is generated by the SME to request that a frame be sent to a peer entity to report the results of measuring one or more channels. 6.3.16.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a Measurement Report frame containing the set of measurement reports. This frame is then scheduled for transmission. 325 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.16.3 MLME-MREPORT.indication 6.3.16.3.1 Function This primitive indicates that a Measurement Report frame has been received from a peer entity. This management report is either a response to an earlier measurement request (e.g., MLME- MREQUEST.request primitive) or an autonomous report. 6.3.16.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-MREPORT.indication( Peer MAC Address, Dialog Token, Measurement Report Set, Measurement Category, VendorSpecificInfo ) Name Type Valid range Description Peer MAC Address MACAddress Any valid individual The address of the peer MAC entity from MAC address which the Measurement Report frame was received. Dialog Token Integer 0â€“255 The dialog token to identify the measurement transaction. Set to 0 for an autonomous report. Measurement Set of measurement Set of measurement A set of measurement reports, each Report Set reports, each as reports, each as containing a Measurement Token, defined in the defined in 9.4.2.22 Measurement Report Mode, Measurement Measurement Report Type, and Measurement Report. element format Measurement Enumeration SPECTRUM Indicates whether the Measurement Category MANAGEMENT, or Report Set is a set of Spectrum RADIO Management or Radio Measurement MEASUREMENT reports. The parameter is present if dot11RadioMeasurementActivated is true; otherwise not present. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.16.3.3 When generated This primitive is generated by the MLME when a valid Measurement Report frame is received. 6.3.16.3.4 Effect of receipt On receipt of this primitive, measurement data might be available for SME processes, such as channel selection. 326 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.17 Channel switch 6.3.17.1 MLME-CHANNELSWITCH.request 6.3.17.1.1 Function This primitive requests a switch to a new operating channel. 6.3.17.1.2 Semantics of the service primitive The primitive parameters are as follows: MLME-CHANNELSWITCH.request( Mode, Channel Number, Secondary Channel Offset, Channel Switch Count, Mesh Channel Switch Parameters, Wide Bandwidth Channel Switch, New Transmit Power Envelope, VendorSpecificInfo ) Name Type Valid range Description Mode Integer 0, 1 Channel switch mode, as defined for the Channel Switch Announcement element. Channel Number Integer As defined in Specifies the new channel number. 17.3.8.4.3 Secondary Channel Integer As in Table 9-80 Specifies the position of secondary Offset channel in relation to the primary channel. The parameter is present if dot11FortyMHzOperationImplemented is true; otherwise, the parameter is not present. Channel Switch As defined in As defined in Specifies the time period until the channel Count 9.4.2.19 9.4.2.19 switch event, as described in 9.4.2.19 Mesh Channel As defined in As defined in Specifies MBSS Channel Switch Switch 9.4.2.103 9.4.2.103 Parameters used by a mesh STA. This Parameters parameter is present if the dot11MeshActivated is true; otherwise, the parameter is not present. Wide Bandwidth As defined in As defined in Specifies channel parameters used when Channel Switch 9.4.2.161 9.4.2.161 switching to a channel width wider than 40 MHz. The parameter is present if dot11VHTOptionImplemented is true and switching to a channel width wider than 40 MHz; otherwise, the parameter is not present. New Transmit Power Set of New Transmit N/A Specifies power parameters used for the Envelope Power Envelope BSS after the channel switch. Optionally elements present if dot11VHTOptionImplemented is true. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 327 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.17.1.3 When generated This primitive is generated by the SME to schedule a channel switch and announce this switch to peer entities in the BSS. 6.3.17.1.4 Effect of receipt On receipt of this primitive, the MLME schedules the channel switch event and announces this switch to other STAs in the BSS using the Channel Switch Announcement frame or element. The MLME sets the timing of the frame transmission taking into account the activation delay. 6.3.17.2 MLME-CHANNELSWITCH.confirm 6.3.17.2.1 Function This primitive reports the result of a request to switch channel. 6.3.17.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-CHANNELSWITCH.confirm( ResultCode, VendorSpecificInfo ) Name Type Valid range Description ResultCode Enumeration SUCCESS, Reports the result of a channel UNSPECIFIED FAILURE switch request. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.17.2.3 When generated This primitive is generated by the MLME when a channel switch request completes. Possible unspecified failure causes include an inability to schedule a channel switch announcement. 6.3.17.2.4 Effect of receipt The SME is notified of the results of the channel switching procedure. 6.3.17.3 MLME-CHANNELSWITCH.indication 6.3.17.3.1 Function This primitive indicates that a channel switch announcement has been received from a peer entity. 6.3.17.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-CHANNELSWITCH.indication( Peer MAC Address, Mode, Channel Number, Secondary Channel Offset, 328 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Channel Switch Count, Mesh Channel Switch Parameters, Wide Bandwidth Channel Switch, New Transmit Power Envelope, VendorSpecificInfo ) Name Type Valid range Description Peer MAC Address MACAddress Any valid individual The address of the peer MAC entity from MAC address which the Measurement Report frame was received. Mode Integer 0, 1 Channel switch mode, as defined for the Channel Switch Announcement element. Channel Number Integer As defined in Specifies the new channel number. 17.3.8.4.3 Secondary Channel Integer As in Table 9-80 Specifies the position of secondary Offset channel in relation to the primary channel. The parameter is optionally present if dot11FortyMHzOperationImplemented is true; otherwise not present. Channel Switch As defined in As defined in Specifies the time period until the channel Count 9.4.2.19 9.4.2.19 switch event, as described in 9.4.2.19 Mesh Channel As defined in As defined in Specifies MBSS Channel Switch Switch 9.4.2.103 9.4.2.103 Parameters used by a mesh STA. This Parameters parameter is present if the dot11MeshActivated is true; otherwise, the parameter is not present. Wide Bandwidth As defined in As defined in Specifies channel parameters used when Channel Switch 9.4.2.161 9.4.2.161 switching to a channel width wider than 40 MHz. The parameter is present if dot11VHTOptionImplemented is true and switching to a channel width wider than 40 MHz; otherwise, the parameter is not present. New Transmit Power Set of New Transmit N/A Specifies power parameters used for the Envelope Power Envelope BSS after the channel switch. Optionally elements present if dot11VHTOptionImplemented is true. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.17.3.3 When generated This primitive is generated by the MLME when a valid Channel Switch Announcement frame is received. 6.3.17.3.4 Effect of receipt On receipt of this primitive, the SME decides whether to accept the switch. 6.3.17.4 MLME-CHANNELSWITCH.response 6.3.17.4.1 Function This primitive is used to schedule an accepted channel switch. 329 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.17.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-CHANNELSWITCH.response( Mode, Channel Number, Secondary Channel Offset, Channel Switch Count, Mesh Channel Switch Parameters, Wide Bandwidth Channel Switch, New Transmit Power Envelope, VendorSpecificInfo ) Name Type Valid range Description Mode Integer 0, 1 Channel switch mode, as defined for the Channel Switch Announcement element. Channel Number Integer As defined in Specifies the new channel number. 17.3.8.4.3 Secondary Channel Integer As in Table 9-80 Specifies the position of secondary channel Offset in relation to the primary channel. The parameter is optionally present if dot11FortyMHzOperationImplemented is true; otherwise not present. Channel Switch As defined in As defined in Specifies the time period until the channel Count 9.4.2.19 9.4.2.19 switch event, as described in 9.4.2.19 Mesh Channel As defined in As defined in Specifies MBSS Channel Switch Switch 9.4.2.103 9.4.2.103 Parameters used by a mesh STA. This Parameters parameter is present if the dot11MeshActivated is true; otherwise, the parameter is not present. Wide Bandwidth As defined in As defined in Specifies channel parameters used when Channel Switch 9.4.2.161 9.4.2.161 switching to a channel width wider than 40 MHz. The parameter is present if dot11VHTOptionImplemented is true and switching to a channel width wider than 40 MHz; otherwise, the parameter is not present. New Transmit Power Set of New Transmit N/A Specifies power parameters used for the Envelope Power Envelope BSS after the channel switch. Optionally elements present if dot11VHTOptionImplemented is true. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.17.4.3 When generated This primitive is generated by the SME to schedule an accepted channel switch request. 6.3.17.4.4 Effect of receipt On receipt of this primitive, the MLME schedules the channel switch. 330 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.18 TPC request 6.3.18.1 Introduction This set of primitives supports the adaptation of transmit power between peer entities as described in 11.8.7. 6.3.18.2 MLME-TPCADAPT.request 6.3.18.2.1 Function This primitive supports the adaptation of transmit power between peer entities as specified in 11.8.7. 6.3.18.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TPCADAPT.request( Peer MAC Address, Dialog Token, VendorSpecificInfo ) Name Type Valid range Description Peer MAC Address MACAddress Any valid individual The address of the peer MAC entity to or group MAC which the TPC request is sent. address Dialog Token Integer 1â€“255 The dialog token to identify the TPC transaction. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.18.2.3 When generated This primitive is generated by the SME to request that a TPC Request frame be sent to a peer entity to request that entity to report transmit power and link margin information. 6.3.18.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a TPC Request frame. This frame is then scheduled for transmission. 6.3.18.3 MLME-TPCADAPT.confirm 6.3.18.3.1 Function This primitive reports the result of the TPC adaptation procedure. 6.3.18.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TPCADAPT.confirm( ResultCode Transmit Power, Link Margin, 331 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Rate, VendorSpecificInfo ) Name Type Valid range Description ResultCode Enumeration SUCCESS, Reports the outcome of a request UNSPECIFIED FAILURE to send a TPC Request frame. Transmit Power Integer â€“127 to 127 Value of the Transmit Power field of the TPC Report element of the TPC Report frame. Link Margin Integer â€“127 to 127 Value of the Link Margin field of the TPC Report element of the TPC Report frame. Rate Integer As defined in 9.4.2.3 The rate at which the TPC Request frame was sent. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.18.3.3 When generated This primitive is generated by the MLME when the TPC adaptation procedure completes. 6.3.18.3.4 Effect of receipt The SME is notified of the results of the TPC adaptation procedure. 6.3.19 SetKeys 6.3.19.1 MLME-SETKEYS.request 6.3.19.1.1 Function This primitive causes the keys identified in the parameters of the primitive to be set in the MAC and enabled for use. 6.3.19.1.2 Semantics of the service primitive The primitive parameter is as follows: MLME-SETKEYS.request( Keylist ) Name Type Valid range Description Keylist A set of SetKeyDescriptors N/A The list of keys to be used by the MAC. Each SetKeyDescriptor consists of the following parameters: Name Type Valid range Description Key Bit string N/A The temporal key value Length Integer N/A The number of bits in the Key to be used. 332 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description Key ID Integer 0â€“3 shall be used Key identifier with WEP, TKIP, CCMP, and GCMP; 4â€“5 with BIP; and 6â€“4095 are reserved Key Type Integer Group, Pairwise, Defines whether this key is a group key, PeerKey, IGTK pairwise key, PeerKey, or Integrity Group key. Address MACAddress Any valid This parameter is valid only when the Key individual MAC Type value is Pairwise, when the Key Type address value is Group and the STA is in IBSS, or when the Key Type value is PeerKey. Receive Sequence Count 8 octets N/A Value to which the RSC(s) is initialized. Cipher Suite Selector 4 octets As defined in The cipher suite required for this 9.4.2.25 association. 6.3.19.1.3 When generated This primitive is generated by the SME at any time when one or more keys are to be set in the MAC. 6.3.19.1.4 Effect of receipt Receipt of this primitive causes the MAC to apply the keys as follows, subject to the MLME- SETPROTECTION.request primitive: â€” The MAC uses the key information (as defined by the Key Type, Key ID, Address and Cipher Suite Selector parameters) for the transmission of subsequent frames to which the key applies (as defined by the Key Type, Key ID and Address elements). â€” The MAC installs the key with the associated Key ID such that received frames for the cipher suite indicated by the Cipher Suite Selector, of the appropriate type, and containing the matching Key ID are processed using that key and its associated state information, subject to validation based on the Receive Sequence Count. 6.3.20 DeleteKeys 6.3.20.1 MLME-DELETEKEYS.request 6.3.20.1.1 Function This primitive causes the keys identified in the parameters of the primitive to be deleted from the MAC and thus disabled for use. 6.3.20.1.2 Semantics of the service primitive The primitive parameter is as follows: MLME-DELETEKEYS.request( Keylist ) Name Type Valid range Description Keylist A set of N/A The list of keys to be deleted from the DeleteKeyDescriptors MAC. 333 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Each DeleteKeyDescriptor consists of the following parameters: Name Type Valid range Description Key ID Integer 0â€“3 shall be used Key identifier. with WEP, TKIP, CCMP, and GCMP; 4â€“5 with BIP; and 6â€“4095 are reserved Key Type Integer Group, Pairwise, Defines whether this key is a group key, PeerKey, IGTK pairwise key, PeerKey, or Integrity Group key. Address MACAddress Any valid individual This parameter is valid only when the Key MAC address Type value is Pairwise, or when the Key Type value is Group and is from an IBSS STA, or when the Key Type value is PeerKey. 6.3.20.1.3 When generated This primitive is generated by the SME at any time when keys for a security association are to be deleted in the MAC. 6.3.20.1.4 Effect of receipt Receipt of this primitive causes the MAC to delete all the temporal keys identified by each DeleteKeyDescriptor in the Keylist (as defined by the Key Type, Key ID and Address elements), and to cease using them. 6.3.21 MIC (michael) failure event 6.3.21.1 MLME-MICHAELMICFAILURE.indication 6.3.21.1.1 Function This primitive reports that a MIC failure event was detected. 6.3.21.1.2 Semantics of the service primitive The primitive parameters are as follows: MLME-MICHAELMICFAILURE.indication ( Count, Address, Key Type, Key ID, TSC ) 334 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description Count Integer 1 or 2 The current number of MIC failure events. Address MACAddress Any valid individual The source MAC address of the frame. MAC address Key Type Integer Group, Pairwise, The key type that the received frame PeerKey used. Key ID Integer 0â€“3 Key identifier. TSC 6 octets N/A The TSC value of the frame that generated the MIC failure. 6.3.21.1.3 When generated This primitive is generated by the MAC when it has detected a MIC failure. 6.3.21.1.4 Effect of receipt The SME is notified that the MAC has detected a MIC failure; see 12.5.2.4. 6.3.22 EAPOL 6.3.22.1 MLME-EAPOL.request 6.3.22.1.1 Function This primitive is generated by the SME when the SME has an EAPOL-Key frame to send. 6.3.22.1.2 Semantics of the service primitive The primitive parameters are as follows: MLME-EAPOL.request ( Source Address, Destination Address, Data ) Name Type Valid range Description Source Address MACAddress N/A The MAC sublayer address from which the EAPOL PDU is being sent. Destination Address MACAddress N/A The MAC sublayer entity address to which the EAPOL PDU is being sent. Data EAPOL PDU (as N/A The EAPOL PDU to be transmitted. defined in IEEE Std 802.1X-2010 Clause 11) 6.3.22.1.3 When generated This primitive is generated by the SME when the SME has a EAPOL-Key frame to send. 6.3.22.1.4 Effect of receipt The MAC sends this EAPOL-Key frame. 335 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.22.2 MLME-EAPOL.confirm 6.3.22.2.1 Function This primitive indicates that this EAPOL-Key frame has been transmitted by the MAC. 6.3.22.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-EAPOL.confirm ( ResultCode ) Name Type Valid range Description ResultCode Enumeration SUCCESS, Indicates whether the EAPOL-Key frame TRANSMISSION_FAILURE has been transmitted to the target STA. 6.3.22.2.3 When generated This primitive is generated by the MAC as a result of an MLME-EAPOL.request primitive being generated to send an EAPOL-Key frame. 6.3.22.2.4 Effect of receipt The SME is always notified whether this EAPOL-Key frame has been transmitted to the IEEE 802.11 MAC. This primitive communicates that the frame has been transmitted; see the procedures in 12.5.2.4.1. 6.3.23 MLME-PEERKEY-START 6.3.23.1 MLME-PEERKEY-START.request 6.3.23.1.1 Function This primitive is generated by the SME to start a PeerKey handshake with a peer. 6.3.23.1.2 Semantics of the service primitive The primitive parameters are as follows: MLME-PEERKEY-START.request ( PeerSTAAddress, RSN ) Name Type Valid range Description PeerSTAAddress MACAddress Any valid individual Specifies the address of the peer MAC entity MAC address with which to perform the PeerKey handshake process. RSN RSNE As defined in A description of the cipher suites supported 9.4.2.25 by initiator STA. 336 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.23.1.3 When generated This primitive is generated by the SME for a STA to initiate a PeerKey handshake with a specified peer MAC entity in order to create a secure link between the two STAs. 6.3.23.1.4 Effect of receipt This primitive initiates the SMK handshake as part of PeerKey handshake by sending an EAPOL-Key frame. 6.3.24 SetProtection 6.3.24.1 MLME-SETPROTECTION.request 6.3.24.1.1 Function This primitive indicates whether protection is required for frames sent to and received from the indicated MAC address. 6.3.24.1.2 Semantics of the service primitive The primitive parameter is as follows: MLME-SETPROTECTION.request( Protectlist ) Name Type Valid range Description Protectlist A set of protection N/A The list of how each key is being used elements currently. Each Protectlist consists of the following parameters: Name Type Valid range Description Address MACAddress Any valid individual This parameter is valid only when the Key MAC address Type value is Pairwise or when the Key Type value is Group and is from an IBSS STA or PeerKey. ProtectType Enumeration None, Rx, Tx, The protection value for this MAC. Rx_Tx Key Type Integer Group, Pairwise, Defines whether this key is a group key, PeerKey, IGTK pairwise key, PeerKey, or Integrity Group key. 6.3.24.1.3 When generated This primitive is generated by the SME when protection is required for frames sent to and received from the indicated MAC address. 6.3.24.1.4 Effect of receipt Receipt of this primitive causes the MAC to set the protection and to protect Data frames as indicated in the ProtectType parameter of the Protectlist parameter: â€” None: Specifies that Data frames to and from the MAC address are not protected. 337 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” Rx: Specifies that Data frames from the MAC address are protected (i.e., any Data frames without protection received from the MAC address are discarded) but Data frames to the MAC address are not protected. â€” Tx: Specifies that Data frames to the MAC address are protected but Data frames from the MAC address are not protected. â€” Rx_Tx: Specifies that Data frames to and from the MAC address are protected. Once Data frames are protected to and/or from the specified MAC address, the MLME- SETPROTECTION.request primitive is used to reset the prior setting. Invocation of the MLME- SETPROTECTION.request primitive with a ProtectType of None deletes a protection state. 6.3.25 MLME-PROTECTEDFRAMEDROPPED 6.3.25.1 MLME- PROTECTEDFRAMEDROPPED.indication 6.3.25.1.1 Function This primitive notifies the SME that a frame has been dropped because a temporal key was unavailable. 6.3.25.1.2 Semantics of the service primitive This primitive has two parameters, the MAC addresses of the two STAs. The primitive parameters are as follows: MLME-PROTECTEDFRAMEDROPPED.indication ( Address1, Address2 ) Name Type Valid range Description Address1 MACAddress Any valid individual MAC address of TA. MAC address Address2 MACAddress Any valid individual MAC address of RA. MAC address 6.3.25.1.3 When generated This primitive is generated by the MAC when a frame is dropped because no temporal key is available for the frame. 6.3.25.1.4 Effect of receipt The SME is notified that a frame was dropped. The SME can use this information in an IBSS to initiate a security association to the peer STA. 6.3.26 TS management interface 6.3.26.1 General This mechanism supports the process of adding, modifying, or deleting a TS in a BSS using the procedures defined in 11.4. 338 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The primitives used for this mechanism are called TS Management primitives, which include MLME- ADDTS.xxx, MLME-DELTS.xxx, and MLME-ADDTSRESERVE.xxx primitives, where xxx denotes request, confirm, indication, or response. Each primitive contains parameters that correspond to a QoS Action frame. Requests and responses may cause the transmission of the corresponding QoS Action frames. Confirms and indications are issued upon the receipt of the appropriate QoS Action frame. Table 6-1 defines which primitives are supported by which type of STA. Table 6-1â€”Supported TS management primitives Primitive Request Confirm Indication Response ADDTS (in the DMG STA DMG STA DMG STA DMG STA context of non-AP QoS STA non-AP QoS STA HC HC establishing a TS) ADDTS (in the Non-AP and non-PCP Non-AP and non-PCP DMG AP or PCP DMG AP or context of DMG STA DMG STA PCP requesting an allocation) DELTS DMG STA DMG STA DMG STA â€” non-AP QoS STA non-AP QoS STA non-AP QoS STA HC HC HC ADDTSRESERVE HC HC non-AP QoS STA non-AP QoS STA 6.3.26.2 MLME-ADDTS.request 6.3.26.2.1 Function This primitive requests addition (or modification) of a TS. It requests the HC or PCP to admit the new or changed TS. 6.3.26.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-ADDTS.request ( DialogToken, TSPEC, TCLAS, TCLASProcessing, U-APSD Coexistence, EBR, IntraAccessCategoryPriority, HigherLayerStreamID, STAAddress, DMG TSPEC, Multi-band, U-PID, MMS, VendorSpecificInfo ) 339 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description DialogToken Integer 0â€“127 Identifies the ADDTS transaction. TSPEC As defined in TSPEC element As defined in 9.4.2.30 with Specifies the TSID, traffic with the exception of the the exception of the surplus characteristics, and QoS surplus bandwidth allowance, bandwidth allowance, requirements of the TS of minimum PHY rate, and minimum PHY rate, and concern. maximum and minimum SIs, maximum and minimum SIs, which are optionally specified which are optionally specified TCLAS TCLAS element As defined in 9.4.2.31 Zero or more TCLAS elements. Specifies the rules and parameters by which an MSDU may be classified to the specified TS. TCLASProcessing TCLAS Processing element As defined in 9.4.2.33 Specifies how the TCLAS elements are to be processed when there are multiple TCLAS elements. U-APSD U-APSD Coexistence As defined in 9.4.2.91. Indicates the coexistence Coexistence element parameters for requested transmission during a U- APSD service period. EBR Expedited Bandwidth As defined in 9.4.2.94 Specifies the precedence Request element level of the TS request. This element is optionally present when dot11EBRActivated is true. IntraAccessCategor Intra-Access Category As defined in 9.4.2.121 Specifies the intra-AC yPriority Priority element priorities the STA should use. HigherLayerStream Higher Layer Stream ID As defined in 9.4.2.125 Identifies the higher layer ID element stream. STAAddress MACAddress Specifies the MAC address of the peer STA for a PTP TSPEC. DMG TSPEC DMG TSPEC element As defined in 9.4.2.134 Specifies the characteristics and QoS (scheduling) requirements of the DMG allocation request. Multi-band Multi-band element As defined in 9.4.2.138 Specifies the frequency band and channel number where the TSID is to be established. The parameter is absent if the TSID is intended to be established on the same frequency band and channel where the ADDTS Request frame is transmitted. 340 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description U-PID U-PID element As defined in 9.4.2.154 This parameter is optionally present and specifies the parameters of the LLC for the purpose of (de)multiplexing of frames associated with the TSID. MMS Multiple MAC Sublayers As defined in 9.4.2.153 This parameter is element optionally present and specifies the parameters of an MMSL cluster establishment. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.26.2.3 When generated This primitive is generated by the SME to request the addition of a new (or modification of an existing) TS in order to support parameterized QoS transport of the MSDUs belonging to this TS when a higher layer protocol or mechanism signals the STA to initiate such an addition (or modification). 6.3.26.2.4 Effect of receipt The STA operates according to the procedures defined in 11.4. 6.3.26.3 MLME-ADDTS.confirm 6.3.26.3.1 Function This primitive reports the results of a TS addition (or modification) attempt. 6.3.26.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-ADDTS.confirm( ResultCode, DialogToken, TSDelay, TSPEC, Schedule, TCLAS, TCLASProcessing, EBR, HigherLayerStreamID, STAAddress, DMG TSPEC, Multi-band, U-PID, MMS, VendorSpecificInfo ) 341 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description ResultCode Enumeration SUCCESS, Indicates the results of the REJECTED_WITH_SUGGESTED_CHA corresponding MLME- NGES, ADDTS.request primitive. REJECTED_FOR_DELAY_PERIOD, REJECTED_WITH_SUGGESTED_BSS_ TRANSITION, REQUESTED_TCLAS_NOT_SUPPORTE D, TCLAS_RESOURCES_EXHAUSTED, REJECTED_HOME_WITH_ SUGGESTED_CHANGES, REJECTED_FOR_SSP_PERMISSIONS, SUCCESS_STA_IN_PS_MODE, REJECT_U-PID_SETTING DialogToken Integer As defined in the corresponding MLME- Identifies the ADDTS ADDTS.request primitive transaction. TSDelay Integer 0 When the result code is REJECTED_FOR_DELAY_ PERIOD, provides the amount of time a STA should wait before attempting another ADDTS Request frame. TSPEC TSPEC As defined in 9.4.2.30 Specifies the TS information, element traffic characteristics, and QoS requirements of the TS. Schedule Schedule As defined in 9.4.2.34 Specifies the schedule element information, service start time, SI, and the specification interval. TCLAS TCLAS As defined in 9.4.2.31 Zero or more TCLAS element elements. Specifies the rules and parameters by which an MSDU may be classified to the specified TS. TCLASProcessing TCLAS As defined in 9.4.2.33 Specifies how the TCLAS Processing elements are to be processed element when there are multiple TCLAS elements. EBR Expedited As defined in 9.4.2.94 Specifies the precedence level Bandwidth of the TS request. Request This element is optionally element present when dot11EBRActivated is true. HigherLayerStream Higher Layer As defined in 9.4.2.125 Identifies the higher layer ID Stream ID stream. element STAAddress MACAddres Specifies the MAC address of s the peer STA for a PTP TSPEC. DMG TSPEC DMG As defined in 9.4.2.134 Specifies the characteristics TSPEC and QoS (scheduling) element requirements of the DMG allocation request. 342 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description Multi-band Multi-band As defined in 9.4.2.138 Specifies the frequency band element and channel number where the TSID is to be established. The parameter is absent if the TSID is intended to be established on the same frequency band and channel where the ADDTS Request frame is transmitted. U-PID U-PID As defined in 9.4.2.154 This parameter is optionally element present and specifies the parameters of the LLC for the purpose of (de)multiplexing of frames associated with the TSID. MMS Multiple As defined in 9.4.2.153 This parameter is optionally MAC present and specifies the Sublayers parameters of an MMSL element cluster establishment. VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements. elements For the ResultCode value of SUCCESS received by a non-DMG STA, the TSPEC and the optional TCLAS parameters describe the characteristics of the TS that has been created (or modified); and the specified (nonzero) parameters [with the exception of Service Start Time, Medium Time, and any possibly unspecified minimum set of parameters (see 10.22.4.3) in the TSPEC in ADDTS Request frame] exactly match those of the matching MLME-ADDTS.request primitive. For other values of ResultCode received by a non-DMG STA, no new TS has been created. In the case of REJECTED_WITH_ SUGGESTED_CHANGES, the TSPEC represents an alternative proposal by the HC based on information about the current status of the MAC entity. In the case of REJECTED_HOME_WITH_SUGGESTED_CHANGES, the TSPEC represents an alternative proposal by the HC based on information received from the SSPN interface. A TS is not created with this definition. If the suggested changes are acceptable to the STA, it is the responsibility of the STA to set up the TS with the suggested changes. In the case of REJECTED_WITH_SUGGESTED_BSS_TRANSITION, non-AP STA should retry TS setup process with the newly associated AP once the transition is done. If this is the result of a modification of an existing TS, the status of that TS remains unchanged. For the ResultCode value of SUCCESS or SUCCESS_STA_IN_PS_MODE received by a DMG STA, the DMG TSPEC and the optional TCLAS parameters describe the characteristics of the allocation or TS that has been created (or modified); and the specified (nonzero) parameters [with the exception of Maximum Allocation in the DMG TSPEC in the ADDTS Request frame] exactly match those of the matching MLME- ADDTS.request primitive. For other values of ResultCode received by a DMG STA, no new allocation or TS has been created. In the case of REJECTED_WITH_SUGGESTED_CHANGES or REJECT_U-PID_SETTING, then the DMG TSPEC, Multi-band, and U-PID parameters represent an alternative proposal by the peer STA. In such cases, an allocation or TS has not been created. If the suggested changes are acceptable to the STA, it is the responsibility of the STA to set up the allocation or TS with the suggested changes. If this failure is the result of a modification of an existing allocation or TS, the status of that allocation or TS remains unchanged. 343 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.26.3.3 When generated This primitive is generated by the MLME as a result of an MLME-ADDTS.request primitive indicating the results of that request. This primitive is generated when the STA receives a response in the form of an ADDTS Response frame in the corresponding QoS Action frame from the HC or DMG STA. 6.3.26.3.4 Effect of receipt The SME is notified of the results of the TS addition (or modification) procedure. The SME should operate according to the procedures defined in 11.4. 6.3.26.4 MLME-ADDTS.indication 6.3.26.4.1 Function This primitive reports to the DMG STAâ€™s SME or the HCâ€™s SME the request for adding (or modifying) a TS. 6.3.26.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-ADDTS.indication ( DialogToken, STAAddress, TSPEC, TCLAS, TCLASProcessing, U-APSD Coexistence, EBR, IntraAccessCategoryPriority, HigherLayerStreamID, DMG TSPEC, Multi-band, U-PID, MMS, VendorSpecificInfo ) Name Type Valid range Description DialogToken Integer As defined in the Identifies the ADDTS transaction. received ADDTS Request frame STAAddress MACAddress Contains the MAC address of the STA that initiated the MLME-ADDTS.request primitive. 344 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description TSPEC As defined in the As defined in Specifies the TSID, traffic TSPEC element, with 9.4.2.30 with the characteristics, and QoS requirements of the exception of the exception of the the TS. surplus bandwidth surplus bandwidth allowance, minimum allowance, minimum PHY rate, and PHY rate, and maximum and maximum and minimum SIs, which minimum SIs, which are optionally are optionally specified specified TCLAS TCLAS element As defined in 9.4.2.31 Zero or more TCLAS elements. Specifies the rules and parameters by which an MSDU may be classified to the specified TS. TCLASProcessing TCLAS Processing As defined in 9.4.2.33 Specifies how the TCLAS elements are element to be processed when there are multiple TCLAS elements. U-APSD Coexistence U-APSD As defined in Indicates the coexistence parameters for Coexistence element 9.4.2.91 requested transmission during a U-APSD service period. EBR Expedited Bandwidth As defined in Specifies the precedence level of the TS Request element 9.4.2.94 request. This element is optionally present when dot11EBRActivated is true. IntraAccessCategory Intra-Access As defined in Specifies the intra-AC priorities the STA Priority Category Priority 9.4.2.121 should use. element HigherLayerStreamI Higher Layer Stream As defined in Identifies the higher layer stream. D ID element 9.4.2.125 DMG TSPEC DMG TSPEC As defined in Specifies the characteristics (scheduling) element 9.4.2.134 and QoS requirements of the DMG allocation request. Multi-band Multi-band element As defined in Specifies the frequency band and 9.4.2.138 channel number where the TSID is to be established. The parameter is absent if the TSID is intended to be established on the same frequency band and channel where the ADDTS Request frame is transmitted. U-PID U-PID element As defined in This parameter is optionally present and 9.4.2.154 specifies the parameters of the LLC for the purpose of (de)multiplexing of frames associated with the TSID. MMS Multiple MAC As defined in This parameter is optionally present and Sublayers element 9.4.2.153 specifies the parameters of an MMSL cluster establishment. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 The TCLAS is optional at the discretion of the STA that originated the request. 345 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.26.4.3 When generated This primitive is generated by the MLME as a result of receipt of a request to add (or modify) a TS by a specified STA in the form of an ADDTS Request frame. 6.3.26.4.4 Effect of receipt The SME is notified of the request for a TS addition (or modification) by a specified STA. This primitive solicits an MLME-ADDTS.response primitive from the SME that reflects the results of admission control at the HC or DMT STA on the TS requested to be added (or modified). The SME should operate according to the procedures defined in 11.4. The SME generates an MLME-ADDTS.response primitive within a dot11ADDTSResponseTimeout. 6.3.26.5 MLME-ADDTS.response 6.3.26.5.1 Function This primitive responds to the request for a TS addition (or modification) by a specified STAâ€™s MAC entity. 6.3.26.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-ADDTS.response( ResultCode, DialogToken, STAAddress, TSDelay, TSPEC, Schedule, TCLAS, TCLASProcessing, EBR, HigherLayerStreamID, DMG TSPEC, Multi-band, U-PID, MMS, VendorSpecificInfo ) 346 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description ResultCode Enumeration SUCCESS, REJECTED_WITH_ Indicates the results of the SUGGESTED_CHANGES, corresponding MLME- REJECTED_FOR_DELAY_PERIOD, ADDTS.indication primitive. REJECTED_WITH_SUGGESTED_ BSS_TRANSITION, REQUESTED_TCLAS_NOT_ SUPPORTED, TCLAS_RESOURCES_ EXHAUSTED, REJECTED_HOME_WITH_ SUGGESTED_CHANGES, REJECTED_FOR_SSP_ PERMISSIONS, SUCCESS_STA_IN_PS_MODE, REJECT_U-PID_SETTING DialogToken Integer As defined in the corresponding DialogToken of the matching MLME-ADDTS.indication MLME-ADDTS.indication primitive. STAAddress MACAddress Contains the STA address of the matching MLME- ADDTS.indication primitive. TSDelay Integer 0 When the result code is REJECTED_FOR_DELAY_ PERIOD, provides the amount of time a STA should wait before attempting another ADDTS request. TSPEC TSPEC element As defined in 9.4.2.30 Specifies the QoS parameters of the TS. Schedule Schedule As defined in 9.4.2.34 Specifies the schedule element information, service start time, SI, and the specification interval. TCLAS TCLAS As defined in 9.4.2.31 Zero or more TCLAS element elements. Specifies the rules and parameters by which an MSDU may be classified to the specified TS. TCLASProcessing TCLAS As defined in 9.4.2.33 Specifies how the TCLAS Processing elements are to be processed element when there are multiple TCLAS elements. EBR Expedited As defined in 9.4.2.94 Specifies the precedence level Bandwidth of the TS request. Request This element is optionally element present when dot11EBRActivated is true. HigherLayerStream Higher Layer As defined in 9.4.2.125 Identifies the higher layer ID Stream ID stream. element DMG TSPEC DMG TSPEC As defined in 9.4.2.134 Specifies the characteristics element (scheduling) and QoS requirements of the DMG allocation request. 347 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description Multi-band Multi-band As defined in 9.4.2.138 Specifies the frequency band element and channel number where the TSID is to be established. The parameter is absent if the TSID is intended to be established on the same frequency band and channel where the ADDTS Request frame is transmitted. U-PID U-PID element As defined in 9.4.2.154 This parameter is optionally present and specifies the parameters of the LLC for the purpose of (de)multiplexing of frames associated with the TSID. MMS Multiple MAC As defined in 9.4.2.153 This parameter is optionally Sublayers present and specifies the element parameters of an MMSL cluster establishment. VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements. elements The DialogToken and STAAddress parameters contain the values from the matching MLME- ADDTS.indication primitive. If a non-DMG STA receives a result code of SUCCESS, the TSPEC and (optional) TCLAS parameters contain the values from the matching MLME-ADDTS-indication. If a DMG STA receives a result code of SUCCESS or SUCCESS_STA_IN_PS_MODE, the DMG TSPEC and (optional) TCLAS parameters contain the values from the matching MLME-ADDTS.indication primitive. If a non-DMG STA receives a result code of REJECTED_WITH_SUGGESTED_CHANGES or REJECTED_HOME_WITH_ SUGGESTED_CHANGES, the TSPEC and TCLAS parameters represent an alternative proposed TS either based on information local to the MAC entity or using additional information received across the SSPN interface. The TS, however, is not created. The TSID and direction values within the TSPEC are as in the matching MLME-ADDTS.indication primitive. The difference may lie in the QoS (e.g., minimum data rate, mean data rate, and delay bound) values, as a result of admission control performed at the SME of the HC on the TS requested to be added (or modified) by the STA. If sufficient bandwidth is not available, the QoS values may be reduced. In one extreme, the minimum data rate, mean data rate, and delay bound may be all set to 0, indicating that no QoS is to be provided to this TS. If a DMG STA receives a result code of REJECTED_WITH_SUGGESTED_CHANGES or REJECT_U- PID_SETTING, then the DMG TSPEC, TCLAS, Multi-band, and U-PID parameters represent an alternative proposal for the allocation or TS. The allocation or TS, however, has not been created. The allocation ID value within the DMG TSPEC is as in the matching MLME-ADDTS.indication primitive. The difference might lie in the other parameter values, as a result of admission control performed at the SME of the peer STA on the allocation or TS requested to be added (or modified). If sufficient bandwidth is not available, the QoS values might be reduced. If the result code is REJECTED_WITH_SUGGESTED_BSS_TRANSITION, the non-AP STA should initiate a transition query as defined in 11.24.7. Once the transition is completed, the STA should retry TS setup process, as defined in 11.4.4. 348 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.26.5.3 When generated This primitive is generated by the SME at the HC or DMG STA as a result of an MLME-ADDTS.indication primitive to initiate addition (or modification) of a TS with a specified peer MAC entity or entities. 6.3.26.5.4 Effect of receipt This primitive approves addition (or modification) of a TS requested by a specified STAâ€™s MAC entity, with or without altering the TSPEC. This primitive causes the MAC entity at the HC or DMG STA to send an ADDTS Response frame to the requesting STA containing the specified parameters. 6.3.26.6 MLME-DELTS.request 6.3.26.6.1 Function This primitive requests deletion of a TS with a specified peer MAC. This primitive may be generated by one of the following: â€” DMG STA â€” Non-AP STA â€” PCP â€” HC 6.3.26.6.2 Semantics of the service primitive The primitive parameters are as follows: MLME-DELTS.request( STAAddress, TSInfo, ReasonCode, STAAddress, DMG Allocation Info, Multi-band, VendorSpecificInfo ) Name Type Valid range Description STAAddress MACAddress Specifies the MAC address of the STA that initiated this TS. Present only at the HC. TSInfo TS Info field As defined in 9.4.2.30 Specifies the TS to be deleted. Not present when DMG Allocation Info is present. ReasonCode Enumeration STA_LEAVING, END_TS, Indicates the reason why UNKNOWN_TS, TIMEOUT, the TS is being deleted. SERVICE_CHANGE_PRECLUDES_TS STAAddress MACAddress Specifies the MAC address of the peer STA for the PTP TSPEC. 349 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description DMG Allocation DMG As defined in 9.4.2.134 Specifies the DMG Info Allocation Info allocation to be deleted. field Not present when TSInfo is present. Multi-band Multi-band As defined in 9.4.2.138 Specifies the frequency element band and channel number where the TS is to be deleted. The parameter is absent if the TS is intended to be deleted on the same frequency band and channel where the DELTS is transmitted. VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements. elements 6.3.26.6.3 When generated This primitive is generated by the SME to initiate deletion of a TS when a higher layer protocol or mechanism signals the STA to initiate such a deletion. 6.3.26.6.4 Effect of receipt This primitive initiates a TS deletion procedure. This primitive causes the local MAC entity to send out a DELTS frame containing the specified parameters. If this primitive was generated at the HC, the frame is sent to the specified STAâ€™s MAC address. If this primitive was generated at the non-AP STA that is a non-DMG STA, the frame is sent to its HC. A DMG STA sends the frame to the specified STAâ€™s MAC address. In any of these cases, the DELTS frame does not solicit a response from the recipient frame other than an acknowledgment to receipt of the frame. 6.3.26.7 MLME-DELTS.indication 6.3.26.7.1 Function This primitive reports the deletion of a TS by a specified peer MAC entity or deletion of the TS due to an inactivity timeout (HC or PCP only). 6.3.26.7.2 Semantics of the service primitive The primitive parameters are as follows: MLME-DELTS.indication( STAAddress, TSInfo, ReasonCode, DMG Allocation Info, Multi-band, VendorSpecificInfo ) 350 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description STAAddress MACAddress Specifies the MAC address of the STA for which the TS is being deleted. Present only at the HC. TSInfo TS Info field As defined in 9.4.2.30 Specifies the TS information of the TS of concern. Not present when DMG Allocation Info is present. ReasonCode Enumeration STA_LEAVING, END_TS, Indicates the reason why the UNKNOWN_TS, TIMEOUT, TS is being deleted. SERVICE_CHANGE_PRECLUDES_TS DMG Allocation DMG As defined in 9.4.2.134 Specifies the DMG allocation Info Allocation Info under consideration. Not field present when TSInfo is present. Multi-band Multi-band As defined in 9.4.2.138 Specifies the frequency band element and channel number for the TS under consideration. The parameter is absent if the TS is intended to be deleted on the same frequency band and channel where the DELTS is transmitted. VendorSpecificIn A set of As defined in 9.4.2.26 Zero or more elements. fo elements 6.3.26.7.3 When generated This primitive is generated by the MLME when it receives a DELTS frame from the specified peer MAC entity. This primitive may also be generated by the MLME at the DMG STA or HC as a result of inactivity of a particular TS. Inactivity results when a period equal to the inactivity interval in the TSPEC for the TS elapses â€” Without arrival of an MSDU belonging to that TS at the MAC entity of the DMG STA or HC via an MA-UNITDATA.request primitive when the DMG STA or HC is the source STA of that TS or â€” Without reception of an MSDU belonging to that TS by the MAC entity of the DMG STA or HC when the DMG STA or HC is not the source STA of that TS. This primitive is generated after any other state concerning the TSID/direction within the MAC has been deleted. 6.3.26.7.4 Effect of receipt The SME is notified of the initiation of a TS deletion by a specified peer MAC entity. 6.3.26.8 MLME-ADDTSRESERVE.request 6.3.26.8.1 Function This primitive request is used by the SME at the AP to start the AP-initiated TS setup procedure. 351 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.26.8.2 Semantics of the service primitive The primitive parameters are as follows: MLME-ADDTSRESERVE.request ( TSPEC, HigherLayerStreamID, Schedule, VendorSpecificInfo ) Name Type Valid range Description TSPEC TSPEC element As defined in 9.4.2.30 Specifies the QoS parameters of the TS. HigherLayerStreamID Higher Layer Stream ID As defined in 9.4.2.125 Stream identifier assigned element by a higher layer protocol. Schedule Schedule element As defined in 9.4.2.34 Specifies the schedule information, service start time, SI, and the specification interval. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.26.8.3 When generated This primitive is generated by the SME at the AP to start the AP-initiated TS setup procedure. If the parameter validation on the parameters used in this primitive succeeds, an ADDTS Reserve Request frame is transmitted from the AP to a non-AP STA. 6.3.26.8.4 Effect of receipt The STA operates according to the procedures defined in 11.4.4.3. 6.3.26.9 MLME-ADDTSRESERVE.confirm 6.3.26.9.1 Function This primitive is an indication to the SME that is generated by the MLME as a result of receiving an ADDTS Reserve Response frame from the non-AP STA to which the AP sent a corresponding ADDTS Reserve Request frame. 6.3.26.9.2 Semantics of the service primitive The primitive parameters are as follows: MLME-ADDTSRESERVE.confirm ( ResultCode, StreamID, VendorSpecificInfo ) 352 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description ResultCode Enumeration SUCCESS, FAILURE Indicates the results of the corresponding MLME- ADDTSReserve.request primitive. StreamID Higher Layer Stream ID As defined in 9.4.2.125 Stream identifier specified in element the corresponding MLME- ADDTSReserve.request primitive. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.26.9.3 When generated This primitive is generated by the MLME as a result of receiving an ADDTS Reserve Response frame from the non-AP STA to which the AP sent a corresponding ADDTS Reserve Request action. 6.3.26.9.4 Effect of receipt The SME is notified of the results of the AP-initiated TS setup procedure. 6.3.26.10 MLME-ADDTSRESERVE.indication 6.3.26.10.1 Function This primitive reports to the non-AP STAâ€™s SME the initiation of AP-initiated TS setup procedure. 6.3.26.10.2 Semantics of the service primitive The primitive parameters are as follows: MLME-ADDTSRESERVE.indication ( APAddress, TSPEC, Schedule, HigherLayerStreamID, VendorSpecificInfo ) Name Type Valid range Description APAddress MAC Address â€” Contains the MAC address of the AP initiating the TS setup procedure. TSPEC TSPEC element As defined in 9.4.2.30 Specifies the QoS parameters of the TS. Schedule Schedule element As defined in 9.4.2.34 Specifies the schedule information, service start time, SI, and the specification interval. HigherLayerStreamID Higher Layer Stream ID As defined in 9.4.2.125 Stream identifier in the element received ADDTS Reserve Request frame. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 353 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.26.10.3 When generated This primitive is generated by the MLME at the non-AP STA as a result of the receipt of an ADDTS Reserve Request frame from the AP to which the non-AP STA is associated. 6.3.26.10.4 Effect of receipt The SME is notified of the receipt of the ADDTS Reserve Request frame from the AP. This primitive solicits the SME to participate in the AP-initiated TS setup procedure. The SME should operate according to the procedures defined in 11.4.4.3. 6.3.26.11 MLME-ADDTSRESERVE.response 6.3.26.11.1 Function This primitive is used by a non-AP STA to indicate to the HC the completion of an AP-initiated TS setup procedure. 6.3.26.11.2 Semantics of the service primitive The primitive parameters are as follows: MLME-ADDTSRESERVE.response ( HigherLayerStreamID, ResultCode, VendorSpecificInfo ) Name Type Valid range Description HigherLayerStreamID Higher Layer Stream ID As defined in 9.4.2.125 Stream identifier specified in element the corresponding MLME- ADDTSReserve.indication primitive. ResultCode Enumeration SUCCESS, FAILURE Indicates the result of the AP-initiated TS setup procedure. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.26.11.3 When generated This primitive is generated by the SME at the non-AP STA to indicate to an HC that the non-AP STA has setup a TS in response to a higher layer protocol. 6.3.26.11.4 Effect of receipt The STA operates according to the procedures defined in 11.4.4.3. 6.3.27 Management of direct links 6.3.27.1 Introduction This subclause describes the management procedures associated with direct links. 354 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.27.2 MLME-DLS.request 6.3.27.2.1 Function This primitive requests the setup of a direct link with a specified peer MAC entity. 6.3.27.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-DLS.request( PeerMACAddress, DLSTimeoutValue, VendorSpecificInfo ) Name Type Valid range Description PeerMACAddress MACAddress Any valid individual Specifies the MAC address of the STA MAC address that is the intended immediate recipient of the data flow. DLSTimeoutValue Integer 0 Specifies a time limit (in seconds) after which the direct link is terminated if there are no frame exchange sequences with the peer. A value of 0 implies that the direct link is never to be terminated based on a timeout. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.27.2.3 When generated This primitive is generated by the SME to set up a direct link with another STA. 6.3.27.2.4 Effect of receipt This primitive initiates a DLS procedure. In the case that a response is received from the responder STA, the MLME subsequently issues an MLME-DLS.confirm primitive that reflects the results. 6.3.27.3 MLME-DLS.confirm 6.3.27.3.1 Function This primitive reports the results of a DLS attempt with a specified peer MAC entity. 6.3.27.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-DLS.confirm( PeerMACAddress, ResultCode, CapabilityInformation, DLSTimeoutValue, OperationalRateSet, HT Capabilities, 355 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications VHT Capabilities VendorSpecificInfo ) Name Type Valid range Description PeerMACAddress MACAddress Any valid individual MAC Specifies the MAC address of the address STA that is the intended immediate recipient of the data flow. ResultCode Enumeration SUCCESS, Indicates the results of the DLS_NOT_ALLOWED, corresponding MLME-DLS.request NOT_PRESENT, primitive. NOT_QOS_STA, REFUSED CapabilityInformati Capability As defined in 9.4.1.4 Specifies the capabilities of the peer on Information field MAC entity. DLSTimeoutValue Integer 0 Specifies a time limit (in seconds) after which the direct link is terminated if there are no frame exchange sequences with the peer. A value of 0 implies that the direct link is never to be terminated based on a timeout. OperationalRateSet Set of integers Non-DMG BSS: 1-127 Non-DMG BSS: The set of data rates excluding values from (in units of 500 kb/s) that the peer Table 9-78 for each member STA is able to use for direct link of the set communication. The peer STA is able to receive at each of the data rates listed in the set. HT Capabilities As defined in As defined in 9.4.2.56 Specifies the parameters within the frame format HT Capabilities element that are supported by the peer MAC entity. The parameter is optionally present if dot11HighThroughputOptionImpleme nted is true; otherwise not present. VHT Capabilities As defined in As defined in 9.4.2.158 Specifies the parameters in the VHT VHT Capabilities element that are Capabilities supported by the peer MAC entity. element The parameter is optionally present if dot11VHTOptionImplemented is true and not present otherwise. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.27.3.3 When generated This primitive is generated by the MLME as a result of an MLME-DLS.request primitive to establish a direct link with a specified peer MAC entity. 6.3.27.3.4 Effect of receipt The SME is notified of the results of the DLS procedure. 6.3.27.4 MLME-DLS.indication 6.3.27.4.1 Function This primitive reports the establishment of a direct link with a specified peer MAC entity. 356 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.27.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-DLS.indication( PeerMACAddress, CapabilityInformation, DLSTimeoutValue, OperationalRateSet, HT Capabilities, VHT Capabilities VendorSpecificInfo ) Name Type Valid range Description PeerMACAddress MACAddress Any valid individual Specifies the MAC address of the STA that is MAC address the sender of the data flow. CapabilityInformati Capability As defined in 9.4.1.4 Specifies the operational capability definitions on Information field to be used by the peer MAC entity. DLSTimeoutValue Integer 0 Specifies a time limit (in seconds) after which the direct link is terminated if there are no frame exchange sequences with the peer. A value of 0 implies that the direct link is never to be terminated based on a timeout. OperationalRateSet Set of integers Non-DMG BSS: 1- Non-DMG BSS: The set of data rates (in units 127 excluding values of 500 kb/s) that the peer STA is able to use for from Table 9-78 for direct link communication. The peer STA is each member of the able to receive at each of the data rates listed in set the set. HT Capabilities As defined in As defined in Specifies the parameters within the HT frame format 9.4.2.56 Capabilities element that are supported by peer the MAC entity. The parameter is optionally present if dot11HighThroughputOptionImplemented is true; otherwise not present. VHT Capabilities As defined in As defined in Specifies the parameters in the VHT VHT 9.4.2.158 Capabilities element that are supported by the Capabilities peer MAC entity. The parameter is optionally element present if dot11VHTOptionImplemented is true and not present otherwise. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.27.4.3 When generated This primitive is generated by the MLME as result of the establishment of a direct link with a specific peer MAC entity that resulted from a DLS procedure that was initiated by that specific peer MAC entity. 6.3.27.4.4 Effect of receipt The SME is notified of the establishment of the DLS. 6.3.27.5 MLME-DLS.response 6.3.27.5.1 Function This primitive responds to the request for establishment of a direct link. 357 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.27.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-DLS.response( PeerMACAddress, ResultCode, DLSTimeoutValue, VendorSpecificInfo ) Name Type Valid range Description PeerMACAddress MACAddress Any valid individual Specifies the MAC address of the STA that is MAC address the sender of the data flow. ResultCode Enumeration SUCCESS, Indicates the results of the corresponding DLS_NOT_ALLOW MLME-DLS.indication primitive. ED, REFUSED DLSTimeoutValue Integer 0 Specifies a time limit (in seconds) after which the direct link is terminated if there are no frame exchange sequences with the peer. A value of 0 implies that the direct link is never to be terminated based on a timeout. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.27.5.3 When generated This primitive is generated by the SME as a result of an MLME-DLS.indication primitive to initiate establishment of a direct link. 6.3.27.5.4 Effect of receipt This primitive causes the MAC entity to send a DLS Response frame to the requesting STA containing the specified parameters. 6.3.27.6 MLME-DLS-TEARDOWN.request 6.3.27.6.1 Function When initiated by a non-AP STA, this primitive requests the teardown of the direct link with a specified peer MAC entity. When initiated by an AP, this primitive requests the teardown of direct link between two specified MAC entities. 6.3.27.6.2 Semantics of the service primitive The primitive parameters are as follows: MLME-DLS-TEARDOWN.request( PeerMACAddress1, PeerMACAddress2, ReasonCode, VendorSpecificInfo ) 358 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description PeerMACAddress1 MACAddress Any valid individual MAC Specifies the MAC address of the STA address that is the intended immediate recipient of the teardown. PeerMACAddress2 MACAddress Any valid individual MAC Specifies the MAC address of the STA address with which the DLS is being torn down. This parameter is applicable only at the AP. ReasonCode Enumeration STA_LEAVING, Indicates the reason why the direct link is END_DLS, being torn down. PEERKEY_MISMATCH, UNKNOWN_DLS, TIMEOUT, PEER_INITIATED, AP_INITIATED VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.27.6.3 When generated This primitive is generated by the SME for tearing down a direct link with another STA. 6.3.27.6.4 Effect of receipt This primitive initiates a direct-link teardown procedure. The MLME subsequently issues an MLME-DLS- TEARDOWN.confirm primitive that reflects the results. 6.3.27.7 MLME-DLS-TEARDOWN.indication 6.3.27.7.1 Function This primitive indicates the teardown of an already established direct link with a specific peer MAC entity. 6.3.27.7.2 Semantics of the service primitive The primitive parameters are as follows: MLME-DLS-TEARDOWN.indication( PeerMACAddress, ReasonCode, VendorSpecificInfo ) Name Type Valid range Description PeerMACAddress MACAddress Any valid individual MAC Specifies the MAC address of the STA address that is the sender of the data flow. ReasonCode Enumeration STA_LEAVING, Indicates the reason why the direct link is END_DLS, being torn down. PEERKEY_MISMATCH, UNKNOWN_DLS, TIMEOUT, PEER_INITIATED, AP_INITIATED VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 359 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.27.7.3 When generated This primitive is generated by the MLME as result of the teardown of a direct link with a specific peer MAC entity that resulted from a direct link teardown procedure that was initiated either by that specific peer MAC entity or by the local MAC entity. 6.3.27.7.4 Effect of receipt The SME is notified of the teardown of the DLS. 6.3.28 Higher layer synchronization support 6.3.28.1 Introduction This mechanism supports the process of synchronization among higher layer protocol entities residing within different wireless STAs. The actual synchronization mechanism in the higher layer is out of the scope of this standard. In principle, the MLME indicates the transmission/reception of frames with a specific group address in the Address 1 field of a Data frame. 6.3.28.2 MLME-HL-SYNC.request 6.3.28.2.1 Function This primitive requests activation of the synchronization support mechanism. 6.3.28.2.2 Semantics of the service primitive The primitive parameter is as follows: MLME-HL-SYNC.request( GroupAddress ) Name Type Valid range Description GroupAddress MACAddress A group MAC Specifies the group MAC address to which the address synchronization frames are addressed. A synchronization frame is a Data frame with higher layer synchronization information. 6.3.28.2.3 When generated This primitive is generated by the SME when a higher layer protocol initiates a synchronization process. 6.3.28.2.4 Effect of Receipt This request activates the synchronization support mechanism at the STA. The MLME issues an MLME- HL-SYNC.indication primitive when a higher layer synchronization frame, which is a Data frame with the specified group address in Address 1 field, is received or transmitted. 360 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.28.3 MLME-HL-SYNC.indication 6.3.28.3.1 Function This primitive indicates the last symbol on air of a higher layer synchronization frame, whether transmitted or received by the MAC. 6.3.28.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-HL-SYNC.indication( SourceAddress, SequenceNumber ) Name Type Valid range Description SourceAddress MACAddress Any valid individual Specifies the SA of the STA that transmitted MAC address the higher layer synchronization frame. SequenceNumber Integer As defined in Specifies the sequence number of the higher 9.2.4.4.2 layer synchronization frame received or transmitted. 6.3.28.3.3 When generated This primitive is generated by the MLME when the reception or transmission of a higher layer synchronization frame is detected, as indicated by the PHY-RXEND.indication or PHY-TXEND.confirm primitives generated by the PHY. The higher layer synchronization frame is identified by the group MAC address registered by an earlier MLME-HL-SYNC.request primitive in the Address 1 field of a Data frame. 6.3.28.3.4 Effect of receipt The SME is notified of the reception or transmission of a higher layer synchronization frame. 6.3.29 Block Ack 6.3.29.1 General This mechanism supports the initiation (or modification) and termination of block ack. The primitives used for this mechanism are called block ack primitives, which include MLME-ADDBA.xxx and MLME-DELBA.xxx primitives, where xxx denotes request, confirm, indication, or response. Each primitive contains parameters that correspond to a Block Ack Action frame body. Requests and responses may cause these frames to be sent. Confirms and indications are emitted when an appropriate Block Ack Action frame is received. 6.3.29.2 MLME-ADDBA.request 6.3.29.2.1 Function This primitive requests the initiation (or modification) of block ack with a peer MAC entity. 6.3.29.2.2 Semantics of the service primitive The primitive parameters are as follows: 361 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MLME-ADDBA.request( PeerSTAAddress, DialogToken, TID, BlockAckPolicy, BufferSize, BlockAckTimeout, BlockAckStartingSequenceControl, GCRGroupAddress, Multi-band, TCLAS, ADDBA Extension, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MACAddress N/A Specifies the address of the peer MAC entity with which to perform the block ack initiation (or modification). DialogToken Integer 0â€“255 Identifies the ADDBA transaction. TID Integer 0â€“15 Specifies the TID of the data. BlockAckPolicy Enumeration Immediate, Specifies the block ack policy. Delayed BufferSize Integer 0â€“1023 Specifies the number of MPDUs that can be held in its buffer. BlockAckTimeout Integer 0 â€“ 65 535 Specifies the number of TUs without a frame exchange between peers after which the block ack agreement is considered to be torn down. BlockAckStartingS Block Ack As defined in Specifies the value of the Block Ack Starting equenceControl Starting 9.3.1.8 Sequence Control subfield. Sequence Control subfield GCRGroupAddress GCR Group As defined in Specifies the group address for which a block ack Address element 9.4.2.126 agreement is requested. If the element is present, a GCR Group Address element is included in the transmitted ADDBA Request frame. Multi-band Multi-band As defined in Specifies the frequency band and channel number element 9.4.2.138 where the block ack agreement is to be established. The parameter is absent if the block ack agreement is intended to be established on the same frequency band and channel where the ADDBA Request frame is transmitted. TCLAS TCLAS element As defined in Zero or more TCLAS elements. Specifies the 9.4.2.31 rules and parameters by which an MSDU might be classified to the specified TID. ADDBA Extension ADDBA As defined in Specifies additional parameters associated with Extension 9.4.2.139 the block ack agreement. element VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.29.2.3 When generated This primitive is generated by the SME to request initiation (or modification) of block ack with the specified peer MAC entity. 362 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.29.2.4 Effect of receipt The STA sends the ADDBA Request frame to the specified peer MAC entity. 6.3.29.3 MLME-ADDBA.confirm 6.3.29.3.1 Function The primitive reports the results of initiation (or modification) of the block ack attempt with the specified peer MAC entity. 6.3.29.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-ADDBA.confirm( PeerSTAAddress, DialogToken, TID, ResultCode, BlockAckPolicy, BufferSize, BlockAckTimeout, GCRGroupAddress, Multi-band, TCLAS, ADDBA Extension, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MACAddress N/A Specifies the address of the peer MAC entity with which the block ack initiation (or modification) was attempted. This value matches the PeerSTAAddress parameter specified in MLME- ADDBA.request primitive. DialogToken Integer 0â€“255 Identifies the ADDBA transaction. This value matches the DialogToken parameter specified in MLME-ADDBA.request primitive. TID Integer 0â€“15 Specifies the TID of the data. This value matches the TID specified in MLME-ADDBA.request primitive. ResultCode Enumeration SUCCESS, Indicates the result of the corresponding MLME- REFUSED ADDBA.request primitive. BlockAckPolicy Enumeration Immediate, Specifies the block ack policy. Delayed BufferSize Integer 0â€“1023 Specifies the maximum number of MPDUs in the block for the specified TID. BlockAckTimeout Integer 0 â€“ 65 535 Specifies the number of TUs without a frame exchange between peers after which the block ack agreement is considered to be torn down. GCRGroupAddress GCR Group As defined in Specifies the group address for which a block ack Address element 9.4.2.126 agreement was requested. 363 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description Multi-band Multi-band As defined in Specifies the frequency band and channel number element 9.4.2.138 where the block ack initiation was attempted. The parameter is absent if the block ack agreement is intended was attempted to be established on the same frequency band and channel where the ADDBA Request frame is transmitted. TCLAS TCLAS element As defined in Zero or more TCLAS elements. Specifies the 9.4.2.31 rules and parameters by which an MSDU might be classified to the specified TID. ADDBA Extension ADDBA As defined in Specifies additional parameters associated with Extension 9.4.2.139 the block ack agreement. element VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.29.3.3 When generated This primitive is generated by the MLME as a result of an MLME-ADDBA.request primitive to indicate the results of that request. 6.3.29.3.4 Effect of receipt The SME is notified of the results of the block ack initiation (or modification). 6.3.29.4 MLME-ADDBA.indication 6.3.29.4.1 Function This primitive reports the initiation (or modification) of block ack by a peer MAC entity. 6.3.29.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-ADDBA.indication( PeerSTAAddress, DialogToken, TID, BlockAckPolicy, BufferSize, BlockAckTimeout, GCRGroupAddress, Multi-band, TCLAS, ADDBA Extension, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MACAddress N/A Specifies the address of the peer MAC entity that requested the block ack initiation (or modification). DialogToken Integer 0â€“255 Identifies the ADDBA transaction. TID Integer 0â€“15 Specifies the TID of the data. 364 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description BlockAckPolicy Enumeration Immediate, Specifies the block ack policy. Delayed BufferSize Integer 0â€“1023 Specifies the number of MPDUs that can be held in peerSTAAddress buffer. BlockAckTimeout Integer 0 â€“ 65 535 Specifies the number of TUs without a frame exchange between peers after which the block ack agreement is considered to be torn down. GCRGroupAddress GCR Group As defined in Specifies the group address for which a block ack Address element 9.4.2.126 agreement is requested. This element is present if a GCR Group Address element was included in the transmitted ADDBA Request frame. Multi-band Multi-band As defined in Specifies the frequency band and channel number element 9.4.2.138 where the block ack agreement is to be established. The parameter is absent if the block ack agreement is intended to be established on the same frequency band and channel where the ADDBA Request frame is transmitted. TCLAS TCLAS element As defined in Zero or more TCLAS elements. Specifies the 9.4.2.31 rules and parameters by which an MSDU might be classified to the specified TID. ADDBA Extension ADDBA As defined in Specifies additional parameters associated with Extension 9.4.2.139 the block ack agreement. element VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.29.4.3 When generated This primitive is generated by the MLME as a result of receipt of a block ack initiation (or modification) by the specified peer MAC entity in the form of an ADDBA Request frame. 6.3.29.4.4 Effect of receipt The SME is notified of the initiation (or modification) of the block ack by the specified peer MAC entity. 6.3.29.5 MLME-ADDBA.response 6.3.29.5.1 Function The primitive responds to the initiation (or modification) by a specified peer MAC entity. 6.3.29.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-ADDBA.response( PeerSTAAddress, DialogToken, TID, ResultCode, BlockAckPolicy, BufferSize, BlockAckTimeout, GCRGroupAddress, Multi-band, 365 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications TCLAS, ADDBA Extension, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MACAddress N/A Specifies the address of the peer MAC entity that attempted the block ack initiation (or modification). This value matches the PeerSTAAddress parameter specified in MLME- ADDBA.indication primitive. DialogToken Integer 0â€“255 Identifies the ADDBA transaction. This value matches the DialogToken parameter specified in MLME-ADDBA.indication primitive. TID Integer 0â€“15 Specifies the TID of the data. This value matches the TID specified in MLME-ADDBA.indication primitive. ResultCode Enumeration SUCCESS, Indicates the result of the corresponding MLME- REFUSED ADDBA.indication primitive. BlockAckPolicy Enumeration Immediate, Specifies the block ack policy. Undefined when Delayed the result code is REFUSED. BufferSize Integer 0â€“1023 Specifies the maximum number of MPDUs in the block for the specified TID. Undefined when the result code is REFUSED. BlockAckTimeout Integer 0 â€“ 65 535 Specifies the number of TUs without a frame exchange between peers after which the block ack agreement is considered to be torn down. GCRGroupAddress GCR Group As defined in Specifies the group address for which a block ack Address element 9.4.2.126 agreement was requested. Multi-band Multi-band As defined in Specifies the frequency band and channel number element 9.4.2.138 where the block ack agreement is intended to be established. The parameter is absent if the block ack agreement is intended to be established on the same frequency band and channel where the ADDBA Response frame is transmitted. TCLAS TCLAS element As defined in Zero or more TCLAS elements. Specifies the 9.4.2.31 rules and parameters by which an MSDU might be classified to the specified TID. ADDBA Extension ADDBA As defined in Specifies additional parameters associated with Extension 9.4.2.139 the block ack agreement. element VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.29.5.3 When generated This primitive is generated by the MLME as a result of an MLME-ADDBA.indication primitive to initiate block ack by the specified peer MAC entity. 6.3.29.5.4 Effect of receipt The primitive causes the MAC entity to send an ADDBA Response frame to the specified peer MAC entity. 366 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.29.6 MLME-DELBA.request 6.3.29.6.1 Function This primitive requests the deletion of block ack with a peer MAC entity. 6.3.29.6.2 Semantics of the service primitive The primitive parameters are as follows: MLME-DELBA.request( PeerSTAAddress, Direction, TID, ReasonCode, Multi-band, TCLAS, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MACAddress N/A Specifies the address of the peer MAC entity with which to perform the block ack deletion. Direction Enumeration Originator, Specifies if the MAC entity initiating the MLME- Recipient DELBA.request primitive is the originator or the recipient of the data stream that uses the Block Ack. TID Integer 0â€“15 Specifies the TID of the MSDUs for which this block ack agreement has been set up. ReasonCode Enumeration STA_LEAVING, Indicates the reason why the block ack agreement END_BA, is being deleted. UNKNOWN_BA, TIMEOUT Multi-band Multi-band As defined in Specifies the frequency band and channel number element 9.4.2.138 where the block ack agreement is to be deleted. The parameter is absent if the block ack agreement to be deleted is established on the same frequency band and channel where the DELBA frame is transmitted. TCLAS TCLAS element As defined in Zero or more TCLAS elements. Specifies the 9.4.2.31 rules and parameters by which an MSDU might be classified to the specified TID. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.29.6.3 When generated This primitive is generated by the SME to request deletion of block ack with the specified peer MAC entity. 6.3.29.6.4 Effect of receipt The STA sends the DELBA frame to the specified peer MAC entity. 367 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.29.7 MLME-DELBA.indication 6.3.29.7.1 Function This primitive reports the deletion of block ack by a peer MAC entity. 6.3.29.7.2 Semantics of the service primitive The primitive parameters are as follows: MLME-DELBA.indication( PeerSTAAddress, Direction, TID, ReasonCode, Multi-band, TCLAS, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MACAddress N/A Specifies the address of the peer MAC entity with which to perform the block ack deletion. Direction Enumeration Originator, Specifies if the MAC entity initiating the MLME- Recipient DELBA.request primitive is the originator or the recipient of the data stream that uses block ack. TID Integer 0â€“15 Specifies the TID of the MSDUs for which this block ack agreement has been set up. ReasonCode Enumeration STA_LEAVING, Indicates the reason why the block ack agreement END_BA, is being deleted. UNKNOWN_BA, TIMEOUT Multi-band Multi-band As defined in Specifies the frequency band and channel number element 9.4.2.138 where block ack agreement is to be deleted. The parameter is absent if the block ack deletion refers to the same frequency band and channel where the DELBA frame is transmitted. TCLAS TCLAS element As defined in Zero or more TCLAS elements. Specifies the 9.4.2.31 rules and parameters by which an MSDU might be classified to the specified TID. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.29.7.3 When generated This primitive is generated by the MLME as a result of receipt of a block ack deletion by the specified peer MAC entity in the form of a DELBA frame. 6.3.29.7.4 Effect of receipt The SME is notified of the deletion of the block ack by the specified peer MAC entity. 368 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.30 Schedule element management 6.3.30.1 Introduction This subclause describes the management procedures associated with the QoS Schedule element. The primitives defined are MLME-SCHEDULE.request and MLME-SCHEDULE.indication. 6.3.30.2 MLME-SCHEDULE.request 6.3.30.2.1 Function This primitive requests transmission of a Schedule frame. It is valid at the HC. 6.3.30.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-SCHEDULE.request( STAAddress, Schedule, VendorSpecificInfo ) Name Type Valid range Description STAAddress MACAddress Any valid individual MAC address of the STA to which the address Schedule frame shall be sent. Schedule Schedule As defined in Specifies the schedule for the STA, element 9.4.2.34 including the SI (minimum and maximum), TXOP duration (minimum and maximum), and specification interval. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.30.2.3 When generated This primitive is generated by the SME at the HC to send the schedule information, in the form of a Schedule frame, to a specified STA when the schedule information for the STA is changed. 6.3.30.2.4 Effect of receipt This primitive causes the MAC entity at the HC to send a Schedule frame to the STA specified in the primitive containing the specified Schedule parameters. 6.3.30.3 MLME-SCHEDULE.indication 6.3.30.3.1 Function This primitive reports the reception of a new schedule by the STA in the form of a Schedule frame. 369 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.30.3.2 Semantics of the service primitive The primitive parameter is as follows: MLME-SCHEDULE.indication( Schedule, VendorSpecificInfo ) Name Type Valid range Description Schedule Schedule As defined in Specifies the schedule for the STA, including the element 9.4.2.34 SI (minimum and maximum), TXOP duration (minimum and maximum), and specification interval. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.30.3.3 When generated This primitive is generated by the MLME as a result of receipt of a new schedule in the form of a Schedule frame. 6.3.30.3.4 Effect of receipt The SME is notified of the receipt of QoS schedule in the form of a Schedule frame. The new Schedule parameters overwrite the previously stored values. 6.3.31 Vendor-specific action 6.3.31.1 Introduction This set of primitives supports the signaling of (Protected) Vendor Specific frames among peer SMEs. 6.3.31.2 MLME-VSPECIFIC.request 6.3.31.2.1 Function This primitive requests transmission of a Vendor Specific frame. 6.3.31.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-VSPECIFIC.request( PeerMACAddress, Protected, Organization Identifier, VendorSpecificContent ) 370 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description PeerMACAddress MACAddress Any valid individual The address of the peer MAC entity or MAC address or any group of entities to which the Vendor valid group MAC Specific frame is sent. address Protected Boolean true, false Specifies whether the request is sent using a robust Management frame. If true, the request is sent using a Protected Vendor Specific frame. If false, the request is sent using a Vendor Specific frame. Organization Identifier As defined in As defined in Contains a public value assigned by 9.4.1.32 9.4.1.32 the IEEE to identify the organization that has defined the content of the particular vendor-specific action. VendorSpecificContent Determined by the Determined by the Vendor-specific content. entity to whom the entity to whom the Organization Organization Identifier is Identifier is registered registered 6.3.31.2.3 When generated This primitive is generated by the SME to request that a Vendor Specific frame be sent. 6.3.31.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a Vendor Specific frame containing the set of elements and vendor-specific fields. The STA then attempts to transmit the frame. 6.3.31.3 MLME-VSPECIFIC.indication 6.3.31.3.1 Function This primitive indicates that a Vendor Specific frame has been received from a peer entity. 6.3.31.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-VSPECIFIC.indication( PeerMACAddress, Protected, Organization Identifier, RCPI, VendorSpecificContent ) 371 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description PeerMACAddress MACAddress Any valid The address of the peer MAC entity from individual MAC which the Vendor Specific frame was address received. Protected Boolean true, false Specifies whether the request was received using a robust Management frame. If true, the request was received using a Protected Vendor Specific frame. If false, the request was received using a Vendor Specific frame. Organization Identifier As defined in As defined in Contains a public value assigned by the 9.4.1.32 9.4.1.32 IEEE to identify the organization that has defined the content of the particular vendor- specific action. RCPI As defined in As defined in Present when dot11OCBActivated is true. 9.4.2.38 9.4.2.38 RCPI is the measured value of received channel power on the received Vendor Specific frame. VendorSpecificContent Determined by the Determined by the Vendor-specific content. entity to whom the entity to whom the Organization Organization Identifier is Identifier is registered registered 6.3.31.3.3 When generated This primitive is generated by the MLME when a valid Vendor Specific frame is received. 6.3.31.3.4 Effect of receipt On receipt of this primitive, the vendor specific content can be made available for SME processes. 6.3.32 Neighbor report request 6.3.32.1 General The following MLME primitives support the signaling of neighbor report requests. 6.3.32.2 MLME-NEIGHBORREPREQ.request 6.3.32.2.1 Function This primitive requests that a Neighbor Report Request frame be sent to the AP with which the STA is associated. It is valid only at a radio measurement capable STA. 6.3.32.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-NEIGHBORREPREQ.request( DialogToken, SSID, LCI Measurement Request, Location Civic Measurement Request, VendorSpecificInfo ) 372 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description DialogToken Integer 1â€“255 The dialog token to identify the neighbor report transaction. SSID As defined in the As defined in the Optional SSID element to request a neighbor list for a SSID element SSID element specific SSID. LCI As defined in As defined in Optional element included to request LCI information Measurement 9.6.7.6 9.6.7.6 in Neighbor Report elements Request Location Civic As defined in As defined in Optional element included to request location civic Measurement 9.6.7.6 9.6.7.6 information in Neighbor Report elements Request VendorSpecificI A set of As defined in Zero or more elements. nfo elements 9.4.2.26 6.3.32.2.3 When generated This primitive is generated by the SME to request that a Neighbor Report Request frame be sent to the AP with which the STA is associated to request a neighbor report. 6.3.32.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a Neighbor Report Request frame. The STA then attempts to transmit this to the AP with which it is associated. 6.3.32.3 MLME-NEIGHBORREPREQ.indication 6.3.32.3.1 Function This primitive indicates that a Neighbor Report Request frame was received. It is valid only at a radio measurement capable AP. 6.3.32.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-NEIGHBORREPREQ.indication( PeerSTAAddress, DialogToken, SSID, LCI Measurement Request, Location Civic Measurement Request, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddres MACAddress Any valid The address of the STAâ€™s MAC entity from which a s individual MAC Neighbor Report Request frame was received. address DialogToken Integer 1â€“255 The dialog token in the Neighbor Report Request frame that was received. SSID As defined in the As defined in the Optional SSID element to request a neighbor list for a SSID element SSID element specific SSID. 373 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description LCI As defined in As defined in Optional element included to request LCI information Measurement 9.6.7.6 9.6.7.6 in Neighbor Report elements Request Location Civic As defined in As defined in Optional element included to request location civic Measurement 9.6.7.6 9.6.7.6 information in Neighbor Report elements Request VendorSpecificI A set of As defined in Zero or more elements. nfo elements 9.4.2.26 6.3.32.3.3 When generated This primitive is generated by the MLME when a valid Neighbor Report Request frame is received. 6.3.32.3.4 Effect of receipt On receipt of this primitive, the SME operates according to the procedure in 11.11.10.3. 6.3.33 Neighbor report response 6.3.33.1 General The following MLME primitives support the signaling of neighbor report responses. 6.3.33.2 MLME-NEIGHBORREPRESP.request 6.3.33.2.1 Function This primitive requests that a neighbor report response be sent. This may be in response to an MLME- NEIGHBORREPREQ.indication primitive or an autonomous request. It is valid only at a radio measurement capable AP. 6.3.33.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-NEIGHBORREPRESP.request( PeerSTAAddress, DialogToken, NeighborListSet, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MACAddress Any valid The address of the STAâ€™s MAC entity to which a individual Neighbor Report Response frame is to be sent. MAC address DialogToken Integer 0â€“255 The dialog token to identify the neighbor report transaction. Set to the value received in the corresponding MLME- NEIGHBORREPREQ.indication primitive or to 0 for an autonomous report. 374 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description NeighborListSet Set of Neighbor As defined in A set of Neighbor List elements, each representing a List elements 9.4.2.37 neighboring AP being reported as defined in the each as defined Neighbor Report element format. in the Neighbor Report element format VendorSpecificInf A set of As defined in Zero or more elements. o elements 9.4.2.26 6.3.33.2.3 When generated This primitive is generated by the SME to request a neighbor report be sent. This may be in response to an earlier MLME-NEIGHBORREPREQ.indication primitive or a request to transmit an autonomous report. 6.3.33.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a Neighbor Report Response frame. The STA then attempts to transmit this to the STA indicated by the PeerSTAAddress parameter. 6.3.33.3 MLME-NEIGHBORREPRESP.indication 6.3.33.3.1 Function This primitive indicates that a neighbor report response has been received. This may be in response to an earlier neighbor report request (MLME-NEIGHBORREPREQ.request primitive) or an autonomous report. It is valid only at a radio measurement capable STA. 6.3.33.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-NEIGHBORREPRESP.indication( PeerSTAAddress, DialogToken, NeighborListSet, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MACAddress Any valid The address of the AP from which the Neighbor individual MAC Report Response frame was received. address DialogToken Integer 0â€“255 The Dialog Token received in the Neighbor Report Response frame to identify the neighbor report transaction. NeighborListSet Set of Neighbor As defined in A set of Neighbor List elements derived from the List elements, 9.4.2.37 MIB table dot11RMNeighborReportTable, each each as defined in representing a neighboring AP being reported as the Neighbor defined in the Neighbor Report element format. Report element format VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 375 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.33.3.3 When generated This primitive is generated by the MLME when a valid Neighbor Report Response frame is received. 6.3.33.3.4 Effect of receipt The SME is notified of the receipt of the neighbor report data. 6.3.34 Link Measure Request 6.3.34.1 General The following primitives support the measurement of link path loss and the estimation of link margin between peer entities. 6.3.34.2 MLME-LINKMEASURE.request 6.3.34.2.1 Function This primitive supports the measurement of link path loss and the estimation of link margin between peer entities. NOTEâ€”The layer management model used assumes that the handling of a received Link Measurement Request frame is entirely within the MLME. Correspondingly there are no MLME-SME primitives specified for the peer side of a link measurement request transaction. 6.3.34.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-LINKMEASURE.request( PeerMACAddress, DialogToken, Transmit Power, Max Transmit Power, VendorSpecificInfo ) Name Type Valid range Description PeerMACAdd MACAddress Any valid The address of the peer MAC entity to which the Link ress individual MAC Measure Request shall be sent. address DialogToken Integer 1â€“255 The dialog token to identify the Link Measure transaction. Transmit Integer As defined in The transmit power to be used when transmitting the Power 9.6.7.4 Link Measurement Request frame and included in the frame body. See 9.6.7.4. Max Transmit Integer As defined in The maximum transmit power to be used by the Power 9.6.7.4 transmitting STA on its operating channel. See 9.6.7.5. VendorSpecifi A set of As defined in Zero or more elements. cInfo elements 9.4.2.26 6.3.34.2.3 When generated This primitive is generated by the SME to request that a Link Measurement Request frame be sent to the peer entity to request that entity to report transmit power and link margin information. 376 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.34.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a Link Measurement Request frame. The STA then attempts to transmit this to the STA indicated in the PeerMACAddress parameter. 6.3.34.3 MLME-LINKMEASURE.confirm 6.3.34.3.1 Function This primitive reports the result of a Link Measurement request. 6.3.34.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-LINKMEASURE.confirm( ResultCode, DialogToken, TransmitPower, LinkMargin, RCPI of Request, RSNI of Request, RCPI of Report, RSNI of Report, ReceiveAntennaID, TransmitAntennaID, VendorSpecificInfo ) Name Type Valid range Description ResultCode Enumeration SUCCESS, Indicates the result of the corresponding UNSPECIFIED FAILURE MLME-LINKMEASURE.request primitive. DialogToken Integer As defined in the The dialog token to identify the link corresponding MLME-LINK- measurement transaction. MEASURE.request primitive TransmitPower As defined in the As defined in the TPC Report The contents of the Transmit Power field TPC Report element of the received Link Measurement element Report frame. Present if ResultCode = SUCCESS; otherwise not present. LinkMargin As defined in the As defined in the TPC Report The contents of the Link Margin field of TPC Report element the received Link Measurement Report element frame. Present if ResultCode = SUCCESS; otherwise not present. RCPI of Request Integer As defined in 9.4.2.38 Indicates the RCPI value contained in the corresponding Link Measurement Report frame received at the requesting STA. Present if ResultCode = SUCCESS; otherwise not present. RSNI of Request Integer As defined in 9.4.2.41 Indicates the RSNI value contained in the corresponding Link Measurement Report frame received at the requesting STA. Present if ResultCode = SUCCESS; otherwise not present 377 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description RCPI of Report Integer As defined in 9.4.2.38 The RCPI level of the corresponding Link Measurement Report frame received at the requesting STA. Present if ResultCode = SUCCESS; otherwise not present. RSNI of Report Integer As defined in 9.4.2.41 The RSNI of the corresponding Link Measurement Report frame received at the requesting STA. Present if ResultCode = SUCCESS; otherwise not present. Receive Integer 0â€“255 The Antenna ID corresponding to the Antenna ID antenna on which the Link Measurement Request frame was received at the reporting STA. Antenna ID is defined in 9.4.2.29. Transmit Integer 0â€“255 The Antenna ID corresponding to the Antenna ID antenna used to transmit the Link Measurement Report frame. Antenna ID is defined in 9.4.2.29. VendorSpecificI A set of As defined in 9.4.2.26 Zero or more elements. nfo elements 6.3.34.3.3 When generated This primitive is generated by the MLME when a valid Link Measurement Report frame is received from the requested STA. 6.3.34.3.4 Effect of receipt On receipt of this primitive, the SME evaluates the ResultCode and may use the reported data. 6.3.35 MLME SAP interface for resource request 6.3.35.1 MLME-RESOURCE-REQUEST.request 6.3.35.1.1 Function This primitive is used to perform the over-the-air resource request of an FT resource request protocol. The over-the-air resource request is performed using Authentication frames, with an authentication algorithm number corresponding to FT authentication and an authentication algorithm sequence number of 3 or 4. 6.3.35.1.2 Semantics of the service primitive The primitive parameters are as follows: MLME-RESOURCE-REQUEST.request( PeerMACAddress, Contents of FT Authentication elements, VendorSpecificInfo ) 378 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description PeerMACAddress MACAddress Any valid individual Specifies the MAC address of the AP that is MAC address the intended immediate recipient of the resource request. Content of FT Sequence of As defined in 13.8 The set of elements to be included in the FT Authentication elements elements Confirm frame, as described in 13.8.4. VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements. elements 6.3.35.1.3 When generated This primitive is generated by the SME to send the third frame of the over-the-air FT resource request protocol. The third frame is an Authentication frame, with an number corresponding to FT authentication and an Authentication algorithm sequence number of 3. 6.3.35.1.4 Effect of receipt Upon receipt of this primitive, the MLME constructs the appropriate Authentication frame and causes it to be transmitted to the peer MAC address. 6.3.35.2 MLME-RESOURCE-REQUEST.indication 6.3.35.2.1 Function This primitive is used to enact the security and QoS resource request with a specified peer MAC entity. 6.3.35.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-RESOURCE-REQUEST.indication( PeerMACAddress, Content of FT Authentication elements, VendorSpecificInfo ) Name Type Valid range Description PeerMACAddress MACAddress Any valid individual Specifies the MAC address of the STA that MAC address was the sender of the resource request. Content of FT Sequence of As defined in 13.8 The set of elements included in the FT Authentication elements elements Confirm frame, as described in 13.8.4. VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements. elements 6.3.35.2.3 When generated This primitive is generated by the MLME at an AP to indicate that the third frame of the over-the-air FT resource request protocol has been received. The third frame is an Authentication frame, with an authentication algorithm number corresponding to FT authentication and an authentication algorithm sequence number of 3. 6.3.35.2.4 Effect of receipt Upon receipt of this primitive, the SME examines the Transition element and RSNE contents and responds to the peer MAC address using the MLME-RESOURCE-REQUEST.response primitive. 379 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.35.3 MLME-RESOURCE-REQUEST.response 6.3.35.3.1 Function This primitive is used to enact the security and QoS resource request protocol with a specified peer MAC entity. 6.3.35.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-RESOURCE-REQUEST.response( PeerMACAddress, Content of FT Authentication elements, VendorSpecificInfo ) Name Type Valid range Description PeerMACAddress MACAddress Any valid individual Specifies the MAC address of the STA that MAC address is the intended immediate recipient of the resource response. Content of FT Sequence of As defined in 13.8 The set of elements to be included in the FT Authentication elements elements Ack frame, as described in 13.8.5. This includes an optional response to a resource request (RIC). VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements. elements 6.3.35.3.3 When generated This primitive is generated by the SME at an AP to cause the transmission of the fourth frame in the over- the-air FT resource request protocol. The fourth frame is an Authentication frame, with an authentication algorithm number corresponding to FT authentication and an authentication algorithm sequence number of 4. 6.3.35.3.4 Effect of receipt Upon receipt of this primitive, the MLME constructs the appropriate Authentication frame and causes it to be transmitted to the peer MAC address. 6.3.35.4 MLME-RESOURCE-REQUEST.confirm 6.3.35.4.1 Function This primitive is used to enact the security and QoS resource request protocol with a specified peer MAC entity. 6.3.35.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-RESOURCE-REQUEST.confirm( PeerMACAddress, Content of FT Authentication elements, VendorSpecificInfo ) 380 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description PeerMACAddress MACAddress Any valid individual Specifies the MAC address of the AP that MAC address was the sender of the resource response. Content of FT Sequence of As defined in 13.8 The set of elements included in the FT Ack Authentication elements elements frame, as described in 13.8.5. This includes an optional response to a resource request (RIC). VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements. elements 6.3.35.4.3 When generated This primitive is generated by the MLME on receipt of the fourth frame in the FT resource request protocol. 6.3.35.4.4 Effect of receipt Upon receipt of this primitive, the SME examines the content of the message and completes its processing of the resource request. 6.3.35.5 MLME-RESOURCE-REQUEST-LOCAL.request 6.3.35.5.1 Function This primitive is used to enact the over-the-DS FT resource request protocol for a specified peer MAC entity. The over-the-DS FT resource request protocol is performed by communication between the STA and the SME of the target AP, bypassing the MAC of the target AP. This MLME function is used to allow the MAC of the target AP to process the resource requests. 6.3.35.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-RESOURCE-REQUEST-LOCAL.request( MACAddress, Content of Resource Descriptor(s) ) Name Type Valid range Description MACAddress MACAddress Any valid individual Specifies the MAC address of the STA that MAC address is making the resource request. Content of Resource Sequence of As defined in 13.11.2 Specifies the resource(s) that are being Descriptor(s) elements requested. 6.3.35.5.3 When generated This primitive is generated by the SME at a target AP upon receiving an over-the-DS resource request to request resources within the local MAC. 6.3.35.5.4 Effect of receipt Upon receipt of this primitive, the MAC checks for resource availability and allocates resources as requested. 381 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.35.6 MLME-RESOURCE-REQUEST-LOCAL.confirm 6.3.35.6.1 Function This primitive is used to respond to a local resource request for resources from the SME. 6.3.35.6.2 Semantics of the service primitive The primitive parameters are as follows: MLME-RESOURCE-REQUEST-LOCAL.confirm( MACAddress, Content of Resource Descriptor(s), ResultCode ) Name Type Valid range Description MACAddress MACAddress Any valid individual Specifies the MAC address of the STA that MAC address is making the resource request. Content of Resource Sequence of As defined in 13.11.2 Specifies the resource(s) that were allocated Descriptor(s) elements or could have been allocated. ResultCode Enumeration SUCCESS, Indicates the result of the outcome of a REFUSED, resource request. UNSPECIFIED FAILURE 6.3.35.6.3 When generated This primitive is generated by the MAC in response to a local resource request for resources via MLME- RESOURCE-REQUEST-LOCAL.request primitive. 6.3.35.6.4 Effect of receipt Upon receipt of this primitive, the SME prepares a success or failure response to be sent to the STA via the current AP. 6.3.36 MLME SAP interface for remote requests 6.3.36.1 MLME-REMOTE-REQUEST.request 6.3.36.1.1 Function This primitive is used by the SME of a non-AP STA (to send over-the-DS requests) and the SME of an AP (to send over-the-DS responses) to request the MAC to send an FT Action frame. 6.3.36.1.2 Semantics of the service primitive The primitive parameters are as follows: MLME-REMOTE-REQUEST.request( PeerMACAddress, Content of FT Action Frame ) 382 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description PeerMACAddress MACAddress Any valid individual Specifies the MAC address of the STA that MAC address is the destination of the Action frame Content of FT Action Sequence of As defined in 9.6.9 The Action frame to send to the STA. Frame octets 6.3.36.1.3 When generated This primitive is generated by the SME to send an FT Action frame to a specific peer MAC entity. 6.3.36.1.4 Effect of receipt Upon receipt of this primitive, the MAC forwards the Action frame to the STA identified in the Action frame. 6.3.36.2 MLME-REMOTE-REQUEST.indication 6.3.36.2.1 Function This primitive is used by the MAC to indicate to the SME the reception of an FT Action frame. 6.3.36.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-REMOTE-REQUEST.indication( PeerMACAddress, Contents of FT Action Frame ) Name Type Valid range Description PeerMACAddress MACAddress Any valid individual Specifies the MAC address of the STA that MAC address issued the Action frame. Content of FT Action Sequence of As defined in 9.6.9 The Action frame received from the STA. Frame octets 6.3.36.2.3 When generated This primitive is generated by the MAC as a result of the receipt of an FT Action frame from a specific peer MAC entity. 6.3.36.2.4 Effect of receipt Upon receipt of this primitive, the remote request broker (RRB) in the SME of the current AP forwards the Action frame to the target AP identified in the Action frame. 6.3.37 Extended channel switch announcement 6.3.37.1 General The following MLME primitives support the signaling of extended channel switch announcement. 383 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.37.2 MLME-EXTCHANNELSWITCH.request 6.3.37.2.1 Function This primitive requests that a (Protected) Extended Channel Switch Announcement frame be sent by an AP or mesh STA. 6.3.37.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-EXTCHANNELSWITCH.request( Mode, OperatingClass, ChannelNumber, ChannelSwitchCount, Protected, Mesh Channel Switch Parameters, New Country, Wide Bandwidth Channel Switch, New Transmit Power Envelope, VendorSpecificInfo ) Name Type Valid range Description Mode Integer 0,1 Channel switch mode, as defined for the Extended Channel Switch Announcement element. OperatingClass Integer As defined in Specifies the new operating class. Annex E ChannelNumber Integer As defined in Specifies the new channel number. Annex E ChannelSwitchCo As defined in As defined in Specifies the time period until the channel switch unt 9.4.2.53 9.4.2.53 event, as described in 9.4.2.53 Protected Boolean true, false Specifies whether the request is sent using a robust Management frame. If true, the request is sent using the Protected Extended Channel Switch Announcement frame. If false, the request is sent using the Extended Channel Switch Announcement frame. Mesh Channel As defined in As defined in Specifies MBSS Channel Switch Parameters Switch 9.4.2.103 9.4.2.103 used by a mesh STA. This parameter is present if Parameters the dot11MeshActivated is true; otherwise, the parameter is not present. New Country As defined in As defined in Specifies the country, operating class table and 9.4.2.9 9.4.2.9 operating classes used for the BSS after the channel switch. Optionally present if dot11VHTOptionImplemented is true. Wide Bandwidth As defined in As defined in Specifies channel parameters used when Channel Switch 9.4.2.161 9.4.2.161 switching to a channel width wider than 40 MHz. The parameter is present if dot11VHTOptionImplemented is true and switching to a channel width wider than 40 MHz; otherwise, the parameter is not present. 384 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description New Transmit Set of New N/A Specifies power parameters used for the BSS Power Envelope Transmit Power after the channel switch. Optionally present if Envelope elements dot11VHTOptionImplemented is true. VendorSpecificInf A set of elements As defined in Zero or more elements. o 9.4.2.26 6.3.37.2.3 When generated This primitive is generated by the STA management entity (SME) to request that a (Protected) Extended Channel Switch Announcement frame be sent to a STA that is associated to the AP or to peer mesh STAs in the MBSS. 6.3.37.2.4 Effect of receipt On receipt of this primitive, the MLME constructs and transmits a (Protected) Extended Channel Switch Announcement frame. 6.3.37.3 MLME-EXTCHANNELSWITCH.confirm 6.3.37.3.1 Function This primitive reports the result of a request to switch channel. 6.3.37.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-EXTCHANNELSWITCH.confirm( VendorSpecificInfo ) Name Type Valid range Description VendorSpecificInf A set of elements As defined in Zero or more elements. o 9.4.2.26 6.3.37.3.3 When generated This primitive is generated by the MLME when an extended channel switch request completes. Possible unspecified failure causes include an inability to schedule an extended channel switch announcement. 6.3.37.3.4 Effect of receipt The SME is notified of the results of the extended channel switching procedure. 6.3.37.4 MLME-EXTCHANNELSWITCH.indication 6.3.37.4.1 Function This primitive indicates that a (Protected) Extended Channel Switch Announcement frame was received from an AP or from a peer mesh STA. 385 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.37.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-EXTCHANNELSWITCH.indication( Peer MAC Address, Mode, OperatingClass, ChannelNumber, ChannelSwitchCount, Protected, Mesh Channel Switch Parameters, New Country, Wide Bandwidth Channel Switch, New Transmit Power Envelope, VendorSpecificInfo ) Name Type Valid range Description Peer MAC MACAddress Any valid The address of the peer MAC entity from which Address individual MAC the Extended Channel Switch Announcement address frame was received. Mode Integer 0, 1 Channel switch mode, as defined for the Channel Switch Announcement element. OperatingClass Integer As defined in Specifies the new operating class. Annex E ChannelNumber Integer As defined in Specifies the new channel number. Annex E ChannelSwitchCo As defined in As defined in Specifies the time period until the channel switch unt 9.4.2.53 9.4.2.53 event, as described in 9.4.2.53 Protected Boolean true, false Specifies whether the request was received using a robust Management frame. If true, the request was received using the Protected Extended Channel Switch Announcement frame. If false, the request was received using the Extended Channel Switch Announcement frame. Mesh Channel As defined in As defined in Specifies MBSS Channel Switch Parameters Switch 9.4.2.103 9.4.2.103 used by a mesh STA. This parameter is present if Parameters the dot11MeshActivated is true; otherwise, the parameter is not present. New Country As defined in As defined in Specifies the country, operating class table and 9.4.2.9 9.4.2.9 operating classes used for the BSS after the channel switch. Optionally present if dot11VHTOptionImplemented is true. Wide Bandwidth As defined in As defined in Specifies channel parameters used when Channel Switch 9.4.2.161 9.4.2.161 switching to a channel width wider than 40 MHz. The parameter is present if dot11VHTOptionImplemented is true and switching to a channel width wider than 40 MHz; otherwise, the parameter is not present. New Transmit Set of New N/A Specifies power parameters used for the BSS Power Envelope Transmit Power after the channel switch. Optionally present if Envelope elements dot11VHTOptionImplemented is true. VendorSpecificInf A set of elements As defined in Zero or more elements. o 9.4.2.26 386 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.37.4.3 When generated This primitive is generated by the MLME when a valid (Protected) Extended Channel Switch Announcement frame is received. 6.3.37.4.4 Effect of receipt On receipt of this primitive, the SME decides whether to accept the switch request. 6.3.37.5 MLME-EXTCHANNELSWITCH.response 6.3.37.5.1 Function This primitive is used to schedule an accepted extended channel switch. 6.3.37.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-EXTCHANNELSWITCH.response( Mode, OperatingClass, ChannelNumber, ChannelSwitchCount, Mesh Channel Switch Parameters, New Country, Wide Bandwidth Channel Switch, New Transmit Power Envelope, VendorSpecificInfo ) Name Type Valid range Description Mode Integer 0, 1 Channel switch mode, as defined for the Channel Switch Announcement element. OperatingClass Integer As defined in Specifies the new operating class. Annex E ChannelNumber Integer As defined in Specifies the new channel number. Annex E ChannelSwitchCo As defined in As defined in Specifies the time period until the channel switch unt 9.4.2.53 9.4.2.53 event, as described in 9.4.2.53 Mesh Channel As defined in As defined in Specifies MBSS Channel Switch Parameters Switch 9.4.2.103 9.4.2.103 used by a mesh STA. This parameter is present if Parameters the dot11MeshActivated is true; otherwise, the parameter is not present. New Country As defined in As defined in Specifies the country, operating class table and 9.4.2.9 9.4.2.9 operating classes used for the BSS after the channel switch. Optionally present if dot11VHTOptionImplemented is true. Wide Bandwidth As defined in As defined in Specifies channel parameters used when Channel Switch 9.4.2.161 9.4.2.161 switching to a channel width wider than 40 MHz. The parameter is present if dot11VHTOptionImplemented is true and switching to a channel width wider than 40 MHz; otherwise, the parameter is not present. 387 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description New Transmit Set of New N/A Specifies power parameters used for the BSS Power Envelope Transmit Power after the channel switch. Optionally present if Envelope elements dot11VHTOptionImplemented is true. VendorSpecificInf A set of elements As defined in Zero or more elements. o 9.4.2.26 6.3.37.5.3 When generated This primitive is generated by the SME to schedule an accepted extended channel switch request. 6.3.37.5.4 Effect of receipt On receipt of this primitive, the MLME schedules the extended channel switch. 6.3.38 DSE power constraint announcement 6.3.38.1 General The following MLME primitives support the signaling of DSE power constraint to dependent STAs. 6.3.38.2 MLME-DSETPC.request 6.3.38.2.1 Function This primitive requests that a (Protected) DSE Power Constraint frame be sent by an enabling STA. 6.3.38.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-DSETPC.request( RequesterSTAAddress, ResponderSTAAddress, DSELocalPowerConstraint, Protected, VendorSpecificInfo ) Name Type Valid range Description RequesterSTAAdd MACAddress Any valid Specifies the address of the MAC entity of the ress individual MAC enabling STA. address ResponderSTAAd MACAddress Any valid Specifies the address of the MAC entity that dress individual MAC initiates the enablement process. address DSELocalPowerC Integer 0â€“255 Specifies the local power constraint, as described onstraint in the DSE Power Constraint frame (see 9.6.8.10). 388 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description Protected Boolean true, false Specifies whether the request is sent using a robust Management frame. If true, the request is sent using the Protected DSE Power Constraint frame. If false, the request is sent using the DSE Power Constraint frame. VendorSpecificInf A set of elements As defined in Zero or more elements. o 9.4.2.26 6.3.38.2.3 When generated This primitive is generated by the SME to request that a (Protected) DSE Power Constraint Announcement frame be sent to a dependent STA. 6.3.38.2.4 Effect of receipt Upon receipt of this primitive, the MLME constructs a (Protected) DSE Power Constraint Announcement frame. The enabling STA then schedules this frame for transmission. 6.3.38.3 MLME-DSETPC.confirm 6.3.38.3.1 Function This primitive reports the results of a request to send a (Protected) DSE Power Constraint Announcement frame. 6.3.38.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-DSETPC.confirm( ResultCode, VendorSpecificInfo ) Name Type Valid range Description ResultCode Enumeration SUCCESS, Indicates the result of MLME-DSETPC.request REFUSED primitive. VendorSpecificInf A set of elements As defined in Zero or more elements. o 9.4.2.26 6.3.38.3.3 When generated This primitive is generated by the MLME when a DSE power constraint announcement completes. 6.3.38.3.4 Effect of receipt The SME is notified of the results of the DSE power constraint procedure. 389 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.38.4 MLME-DSETPC.indication 6.3.38.4.1 Function This primitive indicates that a DSE Power Constraint Announcement frame was received from an enabling STA. 6.3.38.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-DSETPC.indication( RequesterSTAAddress, ResponderSTAAddress, DSELocalPowerConstraint, Protected, VendorSpecificInfo ) Name Type Valid range Description RequesterSTAAddr MACAddress Any valid Specifies the address of the peer MAC entity that ess individual MAC initiated the enablement process. address ResponderSTAAdd MACAddress Any valid Specifies the address of the peer MAC entity that ress individual MAC is the enabling STA. address DSELocalPowerCo Integer 0â€“255 Specifies the local power constraint, as described nstraint in the DSE Power Constraint frame (see 9.6.8.10). Protected Boolean true, false Specifies whether the request was received using a robust Management frame. If true, the request was received using the Protected DSE Power Constraint frame. If false, the request was received using the DSE Power Constraint frame. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.38.4.3 When generated This primitive is generated by the MLME when a valid (Protected) DSE Power Constraint Announcement frame is received. 6.3.38.4.4 Effect of receipt On receipt of this primitive, the SME performs the DSE power constraint procedure (see 11.12.5). 6.3.38.5 MLME-DSETPC.response 6.3.38.5.1 Function This primitive is used to report the result of the DSE power constraint procedure. 390 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.38.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-DSETPC.response( RequesterSTAAddress, ResponderSTAAddress, ResultCode, Protected, VendorSpecificInfo ) Name Type Valid range Description RequesterSTAAddr MACAddress Any valid Specifies the address of the MAC entity of the ess individual MAC enabling STA. address ResponderSTAAdd MACAddress Any valid Specifies the address of the peer MAC entity that ress individual MAC initiates the enabling process. address ResultCode Enumeration SUCCESS, Reports the result of a DSE power constraint REFUSED procedure. Protected Boolean true, false Specifies whether the response is sent using a robust Management frame. If true, the response is sent using the Protected DSE Power Constraint frame. If false, the response is sent using the DSE Power Constraint frame. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.38.5.3 When generated This primitive is generated by the SME to schedule a response to DSE power constraint announcement. 6.3.38.5.4 Effect of receipt On receipt of this primitive, the MLME schedules the transmission of a (Protected) DSE power constraint result to the enabling STA that sent the DSE power constraint announcement. 6.3.39 Enablement 6.3.39.1 General This mechanism supports the process of establishing an enablement relationship with a peer MAC entity. 6.3.39.2 MLME-ENABLEMENT.request 6.3.39.2.1 Function This primitive requests enablement with a specified peer MAC entity. 6.3.39.2.2 Semantics of the service primitive The primitive parameters are as follows: 391 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MLME-ENABLEMENT.request( RequesterSTAAddress, ResponderSTAAddress, EnablementTimeLimit, Protected, VendorSpecificInfo ) Name Type Valid range Description RequesterSTAAdd MACAddress Any valid Specifies the address of the MAC entity that ress individual MAC initiates the enablement process. address ResponderSTAAd MACAddress Any valid Specifies the address of the MAC entity of the dress individual MAC enabling STA. address EnablementTimeL Integer >0 Specifies a time limit (in TU) after which the imit enablement process is terminated. Protected Boolean true, false Specifies whether the request is sent using a robust Management frame. If true, the request is sent using the Protected DSE Enablement frame. If false, the request is sent using the DSE Enablement frame. VendorSpecificInf A set of elements As defined in Zero or more elements. o 9.4.2.26 6.3.39.2.3 When generated This primitive is generated by the SME for a STA to establish enablement with a specified peer MAC entity. During the enablement procedure, the SME can generate additional MLME-ENABLEMENT.request primitives. 6.3.39.2.4 Effect of receipt This primitive initiates an enablement procedure. In the case that a response is received from the responder STA, the MLME subsequently issues an MLME-ENABLEMENT.confirm primitive that reflects the results. 6.3.39.3 MLME-ENABLEMENT.confirm 6.3.39.3.1 Function This primitive reports the results of an enablement attempt with a specified peer MAC entity. 6.3.39.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-ENABLEMENT.confirm( RequesterSTAAddress, ResponderSTAAddress, ResultCode, Protected, 392 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications EnablementIdentifier, VendorSpecificInfo ) Name Type Valid range Description RequesterSTAAddr MACAddress Any valid Specifies the address of the MAC entity that ess individual MAC initiated the enablement process. This value address matches the RequesterSTAAddress parameter specified in the corresponding MLME- ENABLEMENT.request primitive. ResponderSTAAdd MACAddress Any valid Specifies the address of the peerMAC entity with ress individual MAC which the enablement process was address attempted.This value matches the ResponderSTAAddress parameter specified in the corresponding MLME- ENABLEMENT.request primitive. ResultCode Enumeration SUCCESS, Indicates the result of MLME- REFUSED, ENABLEMENT.request primitive. TOO_MANY_SI MULTANEOUS_ REQUESTS EnablementIdentifi Integer 0 â€“ 65 535 Specifies the dependent enablement identifier. er Protected Boolean true, false Specifies whether the response was received using a robust Management frame. If true, the response was received using the Protected DSE Enablement frame. If false, the response was received using the DSE Enablement frame. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.39.3.3 When generated This primitive is generated by the MLME as a result of an MLME-ENABLEMENT.request primitive for enablement with a specified peer MAC entity. 6.3.39.3.4 Effect of receipt The SME is notified of the results of the enablement procedure. 6.3.39.4 MLME-ENABLEMENT.indication 6.3.39.4.1 Function This primitive indicates receipt of a request from a specific peer MAC entity to establish an enablement relationship with the STA processing this primitive. 6.3.39.4.2 Semantics of the service primitive The primitive parameters are as follows: 393 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MLME-ENABLEMENT.indication( RequesterSTAAddress, ResponderSTAAddress, Protected, VendorSpecificInfo ) Name Type Valid range Description RequesterSTAAddr MACAddress Any valid Specifies the address of the peer MAC entity that ess individual MAC initiated the enablement process. address ResponderSTAAdd MACAddress Any valid Specifies the address of the peer MAC entity that ress individual MAC is the enabling STA. address Protected Boolean true, false Specifies whether the request was sent using a robust Management frame. If true, the request was sent using the Protected DSE Enablement frame. If false, the request was sent using the DSE Enablement frame. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.39.4.3 When generated This primitive is generated by the MLME as a result of the receipt of an enablement request from a specific peer MAC entity. 6.3.39.4.4 Effect of receipt The SME is notified of the receipt of this enablement request. 6.3.39.5 MLME-ENABLEMENT.response 6.3.39.5.1 Function This primitive is used to send a response to a specified peer MAC entity that requested enablement with the STA that issued this primitive. 6.3.39.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-ENABLEMENT.response( RequesterSTAAddress, ResponderSTAAddress, ResultCode, EnablementIdentifier, Protected, VendorSpecificInfo ) 394 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description RequesterSTAAddr MACAddress Any valid Specifies the address of the MAC entity that ess individual MAC initiated the enablement process. address ResponderSTAAdd MACAddress Any valid Specifies the address of the peerMAC entity that ress individual MAC is the enabling STA. address ResultCode Enumeration SUCCESS, Indicates the result response to the enablement REFUSED, request from the peer MAC entity. TOO_MANY_SI MULTANEOUS_ REQUESTS EnablementIdentifi Integer 0-65 535 Specifies the dependent enablement identifier. er Protected Boolean true, false Specifies whether the response is sent using a robust Management frame. If true, the response is sent using the Protected DSE Enablement frame. If false, the response is sent using the DSE Enablement frame. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.39.5.3 When generated This primitive is generated by the SME of a STA as a response to an MLME-ENABLEMENT.indication primitive. 6.3.39.5.4 Effect of receipt This primitive initiates transmission of a response to the specific peer MAC entity that requested enablement. 6.3.40 Deenablement 6.3.40.1 MLME-DEENABLEMENT.request 6.3.40.1.1 Function This primitive requests that the enablement relationship with a specified peer MAC entity be invalidated. 6.3.40.1.2 Semantics of the service primitive The primitive parameters are as follows: MLME-DEENABLEMENT.request( RequesterSTAAddress, ResponderSTAAddress, ReasonCode, Protected, VendorSpecificInfo ) 395 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description RequesterSTAAdd MACAddress Any valid Specifies the address of the peer MAC entity that ress individual MAC requests the deenablement process. address ResponderSTAAd MACAddress Any valid Specifies the address of the MAC entity that dress individual MAC becomes deenabled in the process. address ReasonCode Reason Result As defined in Specifies the reason code for initiating the Code field 9.6.8.5 deenablement process. Protected Boolean true, false Specifies whether the request is sent using a robust Management frame. If true, the request is sent using the Protected DSE Deenablement frame. If false, the request is sent using the DSE Deenablement frame. VendorSpecificInf A set of elements As defined in Zero or more elements. o 9.4.2.26 6.3.40.1.3 When generated This primitive is generated by the SME for a STA to invalidate enablement with a specified peer MAC entity in order to prevent the exchange of (Protected dual of) Public Action frames between the two STAs. During the deenablement procedure, the SME can generate additional MLME-DEENABLEMENT.request primitives. 6.3.40.1.4 Effect of receipt This primitive initiates a deenablement procedure. 6.3.40.2 MLME-DEENABLEMENT.indication 6.3.40.2.1 Function This primitive reports the invalidation of an enablement relationship with a specified peer MAC entity. 6.3.40.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-DEENABLEMENT.indication( RequesterSTAAddress, ResponderSTAAddress, ReasonCode, Protected, VendorSpecificInfo ) Name Type Valid range Description RequesterSTAAdd MACAddress Any valid Specifies the address of the peer MAC entity with ress individual MAC which the enablement relationship was address invalidated. ResponderSTAAd MACAddress Any valid Specifies the address of the MAC entity with dress individual MAC which the enablement relationship was address invalidated. 396 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description ReasonCode Reason Result As defined in Specifies the reason the deenablement procedure Code field 9.6.8.5 was initiated. Protected Boolean true, false Specifies whether the request was received using a robust Management frame. If true, the request was received using the Protected DSE Deenablement frame. If false, the request was received using the DSE Deenablement frame. VendorSpecificInf A set of elements As defined in Zero or more elements. o 9.4.2.26 6.3.40.2.3 When generated This primitive is generated by the MLME as a result of the invalidation of an enablement relationship with a specific peer MAC entity. 6.3.40.2.4 Effect of receipt The SME is notified of the invalidation of the specific enablement relationship. 6.3.41 SA Query support 6.3.41.1 MLME-SA-QUERY.request 6.3.41.1.1 Function This primitive requests that a SA Query Request frame be sent to a specified peer STA to which the STA is associated. 6.3.41.1.2 Semantics of the service primitive The primitive parameters are as follows: MLME-SA-QUERY.request( PeerSTAAddress, TransactionIdentifier, VendorSpecificInfo ) Name Type Valid range Description PeerSTA Address MAC Address Any valid individual Specifies the address of the peer MAC Address MAC entity for the SA Query TransactionIdentifier 2 octets As defined in 9.6.10.2 The Transaction Identifier to identify the SA Query Request and Response transaction VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.41.1.3 When generated This primitive is generated by the SME to request that a SA Query Request frame be sent to a specified peer STA with which the STA is associated. 397 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.41.1.4 Effect of receipt On receipt of this primitive, the MLME constructs a SA Query Request frame. The STA then attempts to transmit this to the peer STA with which it is associated. 6.3.41.2 MLME-SA-QUERY.confirm 6.3.41.2.1 Function This primitive reports the result of a SA Query procedure. 6.3.41.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-SA-QUERY.confirm( PeerSTAAddress, TransactionIdentifier, VendorSpecificInfo ) Name Type Valid Range Description PeerSTA Address MAC Address Any valid individual Specifies the address of the peer MAC Address MAC entity for the SA Query TransactionIdentifier 2 octets As defined in 9.6.10.2 The Transaction Identifier to identify the SA Query Request and Response transaction VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.41.2.3 When generated This primitive is generated by the MLME as a result of the receipt of a valid SA Query Response frame. 6.3.41.2.4 Effect of receipt On receipt of this primitive, the SME may use the response as a sign of liveness of the peer STA. 6.3.41.3 MLME-SA-QUERY.indication 6.3.41.3.1 Function This primitive indicates that a SA Query Request frame was received from a STA. 6.3.41.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-SA-QUERY.indication( PeerSTAAddress, TransactionIdentifier, VendorSpecificInfo ) 398 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description PeerSTA Address MAC Address Any valid individual Specifies the address of the peer MAC Address MAC entity for the SA Query TransactionIdentifier 2 octets As defined in 9.6.10.2 The Transaction Identifier to identify the SA Query Request and Response transaction VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.41.3.3 When generated This primitive is generated by the MLME when a valid SA Query Request frame is received. 6.3.41.3.4 Effect of receipt On receipt of this primitive, the SME operates according to the procedure in 11.3. 6.3.41.4 MLME-SA-QUERY.response 6.3.41.4.1 Function This primitive is generated in response to an MLME-SA-QUERY.indication primitive requesting a SA Query Response frame be sent to a STA. 6.3.41.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-SA-QUERY.response( PeerSTAAddress, TransactionIdentifier, VendorSpecificInfo ) Name Type Valid range Description PeerSTA Address MAC Address Any valid individual Specifies the address of the peer MAC Address MAC entity for the SA Query TransactionIdentifier 2 octets As defined in 9.6.10.2 The Transaction Identifier to iden- tify the SA Query Request and Response transaction VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.41.4.3 When generated This primitive is generated by the SME, in response to an MLME-SA-QUERY.indication primitive, requesting a SA Query Response frame be sent to a STA. 6.3.41.4.4 Effect of receipt On receipt of this primitive, the MLME constructs a SA Query Response frame. The STA then attempts to transmit this to the STA indicated by the PeerSTAAddress parameter. 399 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.42 Get TSF timer 6.3.42.1 General This mechanism is used to request the current value of the TSF timer that the STA maintains. 6.3.42.2 MLME-GETTSFTIME.request 6.3.42.2.1 Function This primitive is generated by the SME to request that the MLME returns the value of its TSF timer. The value returned in TSFtime (as specified in 6.3.42.3.2) is the value of the TSF timer at the instant the MLME- GETTSFTIME.request primitive is received. 6.3.42.2.2 Semantics of the service primitive This primitive has no parameters. 6.3.42.2.3 When generated This primitive is generated by the SME to request the value of the TSF timer from the MLME. 6.3.42.2.4 Effect of receipt The MLME issues an MLME-GETTSFTIME.confirm primitive. 6.3.42.3 MLME-GETTSFTIME.confirm 6.3.42.3.1 Function This primitive is generated by the MLME to report to the SME the result of a request to get the value of the TSF timer. 6.3.42.3.2 Semantics of the service primitive This primitive uses the following parameters: MLME-GETTSFTIME.confirm( ResultCode, TSFtime ) Name Type Valid range Description ResultCode Enumeration SUCCESS, Reports the outcome of an MLME- FAILURE GETTSFTIME.request primitive TSFtime Integer 0 â€“ (264 â€“1) The value of the TSF timer. Present if ResultCode is SUCCESS; otherwise not present. 6.3.42.3.3 When generated This primitive is generated by the MLME to report to the SME the result of an MLME- GETTSFTIME.request primitive. 400 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.42.3.4 Effect of receipt The SME is notified of the result of an MLME-GETTSFTIME.request primitive and, if successful, has the value of the TSF timer at the instant the MLME-GETTSFTIME.request primitive was received by the MLME. If the result of an MLME-GETTSFTIME.request primitive is failure, the TSFtime parameter is not included in the MLME-GETTSFTIME.confirm primitive. NOTEâ€”The TSF timer value can be used, along with other information, by the SME to compute an offset between an external time standard such as a version of Coordinated Universal Time (UTC) from a Global Positioning System (GPS) unit and the TSF timer. 6.3.43 Timing Advertisement 6.3.43.1 General The Timing Advertisement primitives are used to communicate timing and other information from the higher layers or the SME of one STA to the higher layers or SME of other STAs. 6.3.43.2 MLME-TIMING-ADVERTISEMENT.request 6.3.43.2.1 Function This primitive is generated by the SME to request that the MLME generate a Timing Advertisement frame to transmit timing and, optionally, higher layer information. 6.3.43.2.2 Semantics of the service primitive This primitive provides the following parameters: MLME-TIMING-ADVERTISEMENT.request( PeerMACAddress, Capability Information, Country, Power Constraint, Time Advertisement, Extended Capabilities, VendorSpecificInfo ) Name Type Valid range Description PeerMACAddress MACAddress Any valid individual or The address of the peer MAC entity or group of group MAC address entities to which the Timing Advertisement frame is sent. Capability As defined in As defined in 9.4.1.4 The announced capabilities of the STA. Information 9.4.1.4 Country As defined in As defined in 9.4.2.9 The information required to identify the 9.4.2.9 regulatory domain in which the STA is located and to configure its PHY for operation in that regulatory domain. Present only when TPC functionality is required, as specified in 11.8 or when dot11MultiDomainCapabilityActivated is true. Power Constraint As defined in As defined in 9.4.2.14 Optional. The Power Constraint element contains 9.4.2.14 the information necessary to allow a STA to determine the local maximum transmit power in the current channel. 401 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description Time As defined in As defined in 9.4.2.61 Timing announced by the STA. Advertisement 9.4.2.61 Extended As defined in As defined in 9.4.2.27 Optional. The Extended Capabilities element Capabilities 9.4.2.27 might be present if any of the fields in this element are nonzero. VendorSpecificInf A set of As defined in 9.4.2.26 Zero or more elements. o elements 6.3.43.2.3 When generated This primitive is generated by the SME to request that the MLME generates a Timing Advertisement frame for transmission. 6.3.43.2.4 Effect of receipt Upon the receipt of this primitive, the MLME attempts to transmit a Timing Advertisement frame to the specified MAC address, using the procedures defined in 11.22. 6.3.43.3 MLME-TIMING-ADVERTISEMENT.indication 6.3.43.3.1 Function This primitive is generated by the MLME to indicate to the SME the reception of a Timing Advertisement frame. 6.3.43.3.2 Semantics of the service primitive This primitive provides the following parameters: MLME-TIMING-ADVERTISEMENT.indication( Timestamp, Capability Information, Local Time, Country, Power Constraint, Time Advertisement, Extended Capabilities, RCPI, Source MAC address, VendorSpecificInfo ) Name Type Valid range Description Timestamp Integer N/A The timestamp of the received frame. Capability As defined in 9.4.1.4 As defined in The announced capabilities of the STA. Information 9.4.1.4 Local Time Integer N/A Local Time is the value of a stationâ€™s TSF timer at the start of reception of the first octet of the timestamp field of the received Timing Advertisement frame. 402 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description Country As defined in 9.4.2.9 As defined in The information required to identify the 9.4.2.9 regulatory domain in which the STA is located and to configure its PHY for operation in that regulatory domain. Present only when TPC functionality is required, as specified in 11.8 or when dot11MultiDomainCapabilityActivated is true. Power As defined in As defined in The Power Constraint element contains the Constraint 9.4.2.14 9.4.2.14 information necessary to allow a STA to determine the local maximum transmit power in the current channel. Time As defined in As defined in Timing announced by the STA. Advertisement 9.4.2.61 9.4.2.61 Extended As defined in As defined in The Extended Capabilities element might be Capabilities 9.4.2.27 9.4.2.27 present if any of the fields in this element are nonzero. RCPI Integer as defined in As defined in RCPI is the measured value of received channel 9.4.2.38 9.4.2.38 power on the received Timing Advertisement frame. Source MAC As defined in As defined in The SA field of the MAC header from the Address 9.2.4.3.6 9.2.4.3.6 received Timing Advertisement frame. VendorSpecific A set of elements As defined in Zero or more elements. Info 9.4.2.26 6.3.43.3.3 When generated This primitive is generated by the MLME when a Timing Advertisement frame is received. 6.3.43.3.4 Effect of receipt Upon the receipt of this primitive, the SME is notified that a Timing Advertisement frame has been received. 6.3.44 TDLS Discovery 6.3.44.1 General The following MLME primitives support the signaling of TDLS Discovery. 6.3.44.2 MLME-TDLSDISCOVERY.request 6.3.44.2.1 Function This primitive requests that a TDLS Discovery Request frame be sent through the AP path. 6.3.44.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TDLSDISCOVERY.request( DestinationAddress, TDLSDiscoveryRequest ) 403 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description DestinationAddress MAC Any valid Specifies the DA to which a TDLS Discovery Address individual MAC Request frame is transmitted. Address TDLSDiscoveryRequest Sequence of As defined in Specifies the proposed service parameters for octets TDLS Discovery the TDLS Discovery Request frame. Request frame 6.3.44.2.3 When generated This primitive is generated by the SME to request that a TDLS Discovery Request frame be sent through the AP. 6.3.44.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a TDLS Discovery Request frame. The STA then attempts to transmit this frame. 6.3.44.3 MLME-TDLSDISCOVERY.confirm 6.3.44.3.1 Function This primitive is generated when a valid TDLS Discovery Response frame is received. 6.3.44.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TDLSDISCOVERY.confirm( TDLSPeerSTAAddress, TDLSDiscoveryResponse ) Name Type Valid range Description TDLSPeerSTAAddress MAC Any valid Specifies the MAC address of the TDLS peer Address individual MAC STA from which a TDLS Discovery Response Address frame was received. TDLSDiscoveryResponse Sequence of As defined in Specifies the service parameters contained in octets TDLS the received TDLS Discovery Response frame. Discovery Response frame 6.3.44.3.3 When generated This primitive is generated when a valid TDLS Discovery Response frame is received. 6.3.44.3.4 Effect of receipt On receipt of this primitive, the SME evaluates the MLME-TDLSDISCOVERY.confirm primitive and may use the reported data. 404 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.44.4 MLME-TDLSDISCOVERY.indication 6.3.44.4.1 Function This primitive indicates that a TDLS Discovery Request frame was received from a TDLS peer STA. 6.3.44.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TDLSDISCOVERY.indication( TDLSPeerSTAAddress, TDLSDiscoveryRequest ) Name Type Valid range Description TDLSPeerSTAAddress MACAddress Any valid Specifies the MAC address of the TDLS peer STA individual MAC from which a TDLS Discovery Request frame was Address received. TDLSDiscoveryRequest Sequence of As defined in Specifies the proposed service parameters of the octets TDLS TDLS Discovery Request frame. Discovery Request frame 6.3.44.4.3 When generated This primitive is generated by the MLME when a valid TDLS Discovery Request frame is received. 6.3.44.4.4 Effect of receipt On receipt of this primitive, the SME operates according to the procedure in 11.23. 6.3.44.5 MLME-TDLSDISCOVERY.response 6.3.44.5.1 Function This primitive requests that a TDLS Discovery Response frame be sent directly to the TDLS peer STA from which a TDLS Discovery Request frame was received. 6.3.44.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TDLSDISCOVERY.response( TDLSPeerSTAAddress, TDLSDiscoveryResponse ) Name Type Valid range Description TDLSPeerSTAAddress MAC Any valid Specifies the MAC address of the TDLS peer Address individual MAC STA to which a TDLS Discovery Response Address frame is transmitted. TDLSDiscoveryResponse Sequence of As defined in Specifies the proposed service parameters for octets TDLS Discovery the TDLS Discovery Response frame. Response frame 405 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.44.5.3 When generated This primitive is generated by the SME to request that a TDLS Discovery Response frame be sent to the TDLS peer STA from which a TDLS Discovery Request frame was received. 6.3.44.5.4 Effect of receipt On receipt of this primitive, the MLME constructs a TDLS Discovery Response frame. The STA then attempts to transmit this frame to the TDLS peer STA. 6.3.45 TDLS direct-link establishment 6.3.45.1 General The following MLME primitives support the signaling of tunneled direct-link setup. Figure 6-7 depicts the TDLS direct-link establishment process. The figure is an example of only the basic procedure and is not meant to be exhaustive of all possible uses of the protocol. 6.3.45.2 MLME-TDLSSETUPREQUEST.request 6.3.45.2.1 Function This primitive requests that a TDLS Setup Request frame be sent to a candidate TDLS responder STA. 6.3.45.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TDLSSETUPREQUEST.request( TDLSResponderAddress, TDLSSetupRequest ) Name Type Valid range Description TDLSResponderAddress MAC Address Any valid Specifies the MAC address of the STA to individual MAC which the TDLS Setup Request frame is Address transmitted. TDLSSetupRequest Sequence of As defined in Specifies the proposed service parameters for octets TDLS Setup the TDLS Setup. Request frame 6.3.45.2.3 When generated This primitive is generated by the SME to request that a TDLS Setup Request frame be sent to a candidate TDLS responder STA. 6.3.45.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a TDLS Setup Request frame. The STA then attempts to transmit this frame to the candidate TDLS responder STA. 406 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications IEEE 802.11 initiating STA IEEE 802.11 peer STA SME MLME MLME SME MLME -TDLSPOTENTIAL PEERSTA.request MLME -TDLSPOTENTIAL PEERSTA.indication MLME-- TDLSSETUP TDLS Setup MLME-- TDLSSETUP REQUEST.request Request frame REQUEST.indication ProcessTDLS Process TDLS SetupRequest Setup Request Action MLME-- DLSSETUP TDLS Setup MLME-- TDLSSETUP RESPONSE.indication Response frame RESPONSE.request Process TDLS Process TDLS Setup Response Action MLME-- TDLSSETUP TDLS Setup MLME-- TDLSSETUP CONFIRM.request Confirm frame CONFIRM.indication Figure 6-7â€”TDLS direct-link establishment 6.3.45.3 MLME-TDLSSETUPREQUEST.indication 6.3.45.3.1 Function This primitive indicates that a TDLS Setup Request frame was received. 6.3.45.3.2 Semantics of the service primitive The primitive parameters are as follows: 407 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MLME-TDLSSETUPREQUEST.indication( TDLSInitiatorAddress, TDLSSetupRequest ) Name Type Valid range Description TDLSInitiatorAddress MACAddress Any valid Specifies the MAC address of the TDLS individual MAC initiator STA from which a TDLS Setup Address Request frame was received. TDLSSetupRequest Sequence of octets As defined in Specifies the proposed service parameters TDLS Setup for the TDLS Setup. Request frame 6.3.45.3.3 When generated This primitive is generated by the MLME when a valid TDLS Setup Request frame is received. 6.3.45.3.4 Effect of receipt On receipt of this primitive, the SME operates according to the procedure in 11.23. 6.3.45.4 MLME-TDLSSETUPRESPONSE.request 6.3.45.4.1 Function This primitive requests that a TDLS Setup Response frame be sent to the TDLS initiator STA. 6.3.45.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TDLSSETUPRESPONSE.request( TDLSInitiatorAddress, TDLSSetupResponse ) Name Type Valid range Description TDLSInitiatorAddress MAC Address Any valid Specifies the MAC address of the TDLS individual MAC initiator STA to which a TDLS Setup Address Response frame is transmitted. TDLSSetupResponse Sequence of octets As defined in Specifies the proposed service parameters TDLS Setup for the TDLS Setup. Response frame 6.3.45.4.3 When generated This primitive is generated by the SME to request that a TDLS Setup Response frame be sent to the TDLS initiator STA. 6.3.45.4.4 Effect of receipt On receipt of this primitive, the MLME constructs a TDLS Setup Response frame. The STA then attempts to transmit this to the TDLS initiator STA. 408 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.45.5 MLME-TDLSSETUPRESPONSE.indication 6.3.45.5.1 Function This primitive indicates that a TDLS Setup Response frame was received from the TDLS responder STA. 6.3.45.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TDLSSETUPRESPONSE.indication( TDLSResponderAddress, TDLSSetupResponse ) Name Type Valid range Description TDLSResponderAddre MACAddress Any valid Specifies the MAC address of the TDLS ss individual MAC responder STA from which a TDLS Setup Address Response frame was received. TDLSSetupResponse Sequence of As defined in Specifies the proposed service parameters for octets TDLS Setup the TDLS Setup. Response frame 6.3.45.5.3 When generated This primitive is generated by the MLME when a valid TDLS Setup Response frame is received. 6.3.45.5.4 Effect of receipt On receipt of this primitive, the SME operates according to the procedure in 11.23. 6.3.45.6 MLME-TDLSSETUPCONFIRM.request 6.3.45.6.1 Function This primitive requests that a TDLS Setup Confirm frame be sent to the TDLS responder STA. 6.3.45.6.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TDLSSETUPCONFIRM.request( TDLSResponderAddress, TDLSSetupConfirm ) Name Type Valid range Description TDLSResponderAddress MAC Address Any valid Specifies the MAC address of the TDLS individual MAC responder STA to which a TDLS Setup Address Confirm frame is transmitted. TDLSSetupConfirm Sequence of As defined in Specifies the proposed service parameters for octets TDLS Setup the TDLS Setup. Confirm frame 409 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.45.6.3 When generated This primitive is generated by the SME to request that a TDLS Setup Confirm frame be sent to the TDLS responder STA. 6.3.45.6.4 Effect of receipt On receipt of this primitive, the MLME constructs a TDLS Setup Confirm frame. The STA then attempts to transmit this to the TDLS responder STA. 6.3.45.7 MLME-TDLSSETUPCONFIRM.indication 6.3.45.7.1 Function This primitive indicates that a TDLS Setup Confirm frame was received from the TDLS initiator STA. 6.3.45.7.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TDLSSETUPCONFIRM.indication( TDLSInitiatorAddress, TDLSSetupConfirm ) Name Type Valid range Description TDLSInitiatorA MACAddress Any valid Specifies the MAC address of the TDLS initiator ddress individual MAC STA from which a TDLS Setup Confirm frame was Address received. TDLSSetupCon Sequence of octets As defined in Specifies the proposed service parameters for the firm TDLS Setup TDLS setup. Confirm frame 6.3.45.7.3 When generated This primitive is generated by the MLME when a valid TDLS Setup Confirm frame is received. 6.3.45.7.4 Effect of receipt On receipt of this primitive, the SME operates according to the procedure in 11.23. 6.3.45.8 MLME-TDLSPOTENTIALPEERSTA.request 6.3.45.8.1 Function This primitive requests information about a potential TDLS peer STA. 6.3.45.8.2 Semantics of the service primitive The primitive parameter is as follows: MLME-TDLSPOTENTIALPEERSTA.request( MACAddress ) 410 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid Range Description MACAddress MAC Address Any valid Specifies the MAC address of the potential individual MAC TDLS peer STA. Address 6.3.45.8.3 When generated This primitive is generated by the SME to request the MLME to provide information about a potential TDLS peer STA. 6.3.45.8.4 Effect of receipt On receipt of this primitive, the MLME responds with the requested information about the identified STA. 6.3.45.9 MLME-TDLSPOTENTIALPEERSTA.confirm 6.3.45.9.1 Function This primitive informs the SME about a potential TDLS peer STA. 6.3.45.9.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TDLSPOTENTIALPEERSTA.confirm( MACAddress, RSSI ) Name Type Valid range Description MACAddress MAC Address Any valid Specifies the MAC address of the STA for individual MAC which information is requested. Address RSSI Integer â€“1 to RSSI Max Specifies the RSSI from the STA. â€“1 indicates that the STA is not present. 6.3.45.9.3 When generated This primitive is generated by the MLME to indicate to the SME that a potential TDLS peer STA has been detected. 6.3.45.9.4 Effect of receipt On receipt of this primitive, the SME may attempt to set up a TDLS direct link by issuing an MLME- TDLSSETUPREQUEST.request primitive to the MLME. 411 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.46 TDLS direct-link teardown 6.3.46.1 General The following MLME primitives support the signaling of tunneled direct-link setup. Figure 6-8 depicts the TDLS direct-link teardown process. The figure is an example of only the basic procedure and is not meant to be exhaustive of all possible uses of the protocol. IEEE 802.11 initiating STA IEEE 802.11 peer STA SME MLME MLME SME MLME- TDLS TDLS Teardown frame MLME- TDLS TEARDOWN.request TEARDOWN.indication Figure 6-8â€”TDLS direct-link teardown 6.3.46.2 MLME-TDLSTEARDOWN.request 6.3.46.2.1 Function This primitive requests that a TDLS Teardown frame be sent to the TDLS peer STA. 6.3.46.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TDLSTEARDOWN.request( TDLSPeerSTAAddress, TDLSTeardown ) Name Type Valid range Description TDLSPeerSTAAddress MAC Address Any valid Specifies the MAC address of the TDLS peer individual MAC STA to which a TDLS Teardown frame is Address transmitted. TDLSTeardown Sequence of As defined in Specifies the proposed service parameters for octets TDLS Teardown the TDLS teardown. frame 6.3.46.2.3 When generated This primitive is generated by the SME to request that a TDLS Teardown frame be sent to the TDLS peer STA. 412 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.46.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a TDLS Teardown frame. The STA then attempts to transmit this frame to the TDLS peer STA. 6.3.46.3 MLME-TDLSTEARDOWN.indication 6.3.46.3.1 Function This primitive indicates that a TDLS Teardown frame was received from a TDLS peer STA. 6.3.46.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TDLSTEARDOWN.indication( TDLSPeerSTAAddress, TDLSTeardown ) Name Type Valid range Description TDLSPeerSTAA MACAddress Any valid The MAC address of the TDLS peer STA from ddress individual MAC which a TDLS Teardown frame was received. Address TDLSTeardown Sequence of As defined in Specifies the proposed service parameters for the octets TDLS Teardown TDLS teardown. frame 6.3.46.3.3 When generated This primitive is generated by the MLME when a valid TDLS Teardown frame is received. 6.3.46.3.4 Effect of receipt On receipt of this primitive, the SME should operate according to the procedure in 11.23. 6.3.47 TDLS peer U-APSD (TPU) 6.3.47.1 General The following MLME primitives support the signaling of TPU. Figure 6-9 depicts the TPU process. The figure is an example of only the basic procedure and is not meant to be exhaustive of all possible uses of the protocol. 413 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications IEEE 802.11 initiating STA IEEE 802.11 peer STA SME MLME MLME SME MLME- TDLS Peer Traffic Indication frame MLME- TDLSPTI.request TDLSPTI.indication Process TDLS Peer Traffic Indication Action MLME- TDLS Peer Traffic Response frame MLME- TDLSPTI.confirm TDLSPTI.response Figure 6-9â€”TPU 6.3.47.2 MLME-TDLSPTI.request 6.3.47.2.1 Function This primitive requests that a TDLS Peer Traffic Indication frame be sent to a TDLS peer STA. 6.3.47.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TDLSPTI.request( TDLSPeerSTAAddress, TDLSPTI ) Name Type Valid range Description TDLSPeerSTAAddress MAC Address Any valid Specifies the address of the MAC entity with individual MAC which to perform the TPU process. Address TDLSPTI Sequence of As defined in Specifies the proposed service parameters for octets TDLS Peer the TPU. Traffic Indication frame 414 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.47.2.3 When generated This primitive is generated by the SME to request that a TDLS Peer Traffic Indication frame be sent to the TDLS peer STA. 6.3.47.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a TDLS Peer Traffic Indication frame. The STA then attempts to transmit this to the TDLS peer STA. 6.3.47.3 MLME-TDLSPTI.confirm 6.3.47.3.1 Function This primitive reports the result of an MLME-TDLSPTI.request primitive to trigger an unscheduled SP from a candidate TDLS peer STA. This primitive is generated after transmitting a Peer Traffic Indication frame when this frame contains a PTI Control field, and after receiving a Peer Traffic Response frame otherwise. 6.3.47.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TDLSPTI.confirm( TDLSPeerSTAAddress, TDLSPTR ) Name Type Valid range Description TDLSPeerSTAA MAC Address Any valid individual MAC Specifies the MAC address of the peer ddress Address MAC entity with which to perform the TPU process. TDLSPTR Sequence of As defined in TDLS Peer Specifies the proposed service parameters octets Traffic Response frame for the TPU. 6.3.47.3.3 When generated This primitive is generated by the MLME as a result of an MLME-TDLSPTI.request primitive and indicates the results of the request. This primitive is generated when the STA successfully receives a TDLS Peer Traffic Response frame from the TDLS peer STA or when an unspecified failure occurs. 6.3.47.3.4 Effect of receipt On receipt of this primitive, the SME evaluates the results of the MLME-TDLSPTI.request primitive and may use the reported data. 6.3.47.4 MLME-TDLSPTI.indication 6.3.47.4.1 Function This primitive indicates that a TDLS Peer Traffic Indication frame was received from a TDLS peer STA. 415 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.47.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TDLSPTI.indication( TDLSPeerSTAAddress, TDLSPTI ) Name Type Valid range Description TDLSPeerSTAA MACAddress Any valid The MAC address of the non-AP STA MAC entity ddress individual MAC from which a TDLS Peer Traffic Indication frame was Address received. TDLSPTI Sequence of As defined in Specifies the proposed service parameters for the TPU. octets TDLS Peer Traffic Indication frame 6.3.47.4.3 When generated This primitive is generated by the MLME when a valid TDLS Peer Traffic Indication frame is received. 6.3.47.4.4 Effect of receipt On receipt of this primitive, the SME should operate according to the procedure as specified in 11.2.3.15. 6.3.47.5 MLME-TDLSPTI.response 6.3.47.5.1 Function This primitive requests that a TDLS Peer Traffic Response frame be sent to the TDLS peer STA. 6.3.47.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TDLSPTI.response( PeerSTAAddress, TDLSPTR ) Name Type Valid range Description PeerSTAAddress MAC Any valid Specifies the address of the peer MAC entity Address individual MAC with which to perform the TPU. Address TDLSPTR Sequence of As defined in Specifies the proposed service parameters for the octets TDLS Peer TPU. Traffic Response frame 6.3.47.5.3 When generated This primitive is generated by the SME to request that a TDLS Peer Traffic Response frame be sent to the TDLS peer STA. 416 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.47.5.4 Effect of receipt On receipt of this primitive, the MLME constructs a TDLS Peer Traffic Response frame. The STA then attempts to transmit this to the TDLS peer STA. 6.3.48 TDLS channel switching 6.3.48.1 General The following MLME primitives support the signaling of a TDLS channel switch. Figure 6-10 depicts the TDLS channel switching process. The figure is an example of only the basic procedure and is not meant to be exhaustive of all possible uses of the protocol. IEEE 802.11 initiating STA IEEE 802.11 peer STA SME MLME MLME SME MLME- TDLS TDLS Channel Switch MLME- TDLS CHANNELSWITCH.request Request frame CHANNELSWITCH.indication Process TDLS Channel Switch Request Action MLME- TDLS TDLS Channel Switch MLME- TDLS CHANNELSWITCH.confirm Response frame CHANNELSWITCH.response Figure 6-10â€”TDLS channel switching 6.3.48.2 MLME-TDLSCHANNELSWITCH.request 6.3.48.2.1 Function This primitive requests that a TDLS Channel Switch Request frame be sent to the TDLS peer STA. 6.3.48.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TDLSCHANNELSWITCH.request( TDLSPeerSTAAddress, TDLSChannelSwitchRequest ) 417 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description TDLSPeerSTAAddress MAC Any valid Specifies the address of the TDLS peer MAC Address individual MAC entity to which a TDLS Channel Switch Request Address frame is transmitted. TDLSChannelSwitchRequest Sequence As defined in Specifies the proposed service parameters for the of octets TDLS Channel TDLS Channel Switch. Switch Request frame 6.3.48.2.3 When generated This primitive is generated by the SME to request that a TDLS Channel Switch Request frame be sent to the TDLS peer STA. 6.3.48.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a TDLS Channel Switch Request frame. The STA then attempts to transmit this to the TDLS peer STA. 6.3.48.3 MLME-TDLSCHANNELSWITCH.confirm 6.3.48.3.1 Function This primitive reports the result of an MLME-TDLSCHANNELSWITCH.request primitive to switch a channel with a TDLS peer STA. 6.3.48.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TDLSCHANNELSWITCH.confirm( TDLSPeerSTAAddress, TDLSChannelSwitchResponse ) Name Type Valid range Description TDLSPeerSTAAddress MAC Any valid individual MAC Specifies the MAC address of the TDLS Address Address peer STA from which a TDLS Channel Switch Response frame was received. TDLSChannelSwitchRes Sequence of As defined in TDLS Specifies the proposed service ponse octets Channel Switch Response parameters for the TDLS Channel frame Switch. 6.3.48.3.3 When generated This primitive is generated by the MLME as a result of an MLME-TDLSCHANNELSWITCH.request primitive and indicates the results of the request. This primitive is generated when the STA successfully receives a TDLS Channel Switch Response frame from the TDLS peer STA. 6.3.48.3.4 Effect of receipt On receipt of this primitive, the SME evaluates the results of the MLME-TDLSCHANNEL- SWITCH.request primitive and may use the reported data. 418 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.48.4 MLME-TDLSCHANNELSWITCH.indication 6.3.48.4.1 Function This primitive indicates that a TDLS Channel Switch Request frame was received from a TDLS peer STA. 6.3.48.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TDLSCHANNELSWITCH.indication( TDLSPeerSTAAddress, TDLSChannelSwitchRequest ) Name Type Valid range Description TDLSPeerSTAAddres MACAddress Any valid Specifies the MAC address of the TDLS peer s individual MAC STA from which a TDLS Channel Switch Address Request frame was received. TDLSChannelSwitch Sequence of As defined in Specifies the proposed service parameters for the Request octets TDLS Channel TDLS Channel Switch. Switch Request frame 6.3.48.4.3 When generated This primitive is generated by the MLME when a valid TDLS Channel Switch Request frame is received. 6.3.48.4.4 Effect of receipt On receipt of this primitive, the SME should operate according to the procedure in 11.23. 6.3.48.5 MLME-TDLSCHANNELSWITCH.response 6.3.48.5.1 Function This primitive requests that a TDLS Channel Switch Response frame be sent to the TDLS peer STA. 6.3.48.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TDLSCHANNELSWITCH.response( TDLSPeerSTAAddress, TDLSChannelSwitchResponse ) Name Type Valid range Description TDLSPeerSTAAddress MAC Address Any valid Specifies the MAC address of the TDLS peer individual MAC STA to which a TDLS Channel Switch Response Address frame is transmitted. TDLSChannelSwitchRe Sequence of As defined in Specifies the proposed service parameters for the sponse octets TDLS Channel TDLS Channel Switch. Switch Response frame 419 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.48.5.3 When generated This primitive is generated by the SME to request that a TDLS Channel Switch Response frame be sent to the TDLS peer STA. 6.3.48.5.4 Effect of receipt On receipt of this primitive, the MLME constructs a TDLS Channel Switch Response frame. The STA then attempts to transmit this frame to the TDLS peer STA. 6.3.49 TDLS peer PSM 6.3.49.1 General The following MLME primitives support the management of TDLS peer PSM. Figure 6-11 depicts the TDLS peer PSM process. The figure is an example of only the basic procedure and is not meant to be exhaustive of all possible uses of the protocol. IEEE 802.11 initiating STA IEEE 802.11 peer STA SME MLME MLME SME MLME -TDLS TDLS Peer PSM Request frame MLME- TDLS PEERPSM.request PEERPSM.indication Process TDLS Peer PSM Request Action MLME- TDLS TDLS Peer PSM Response frame MLME- TDLS PEERPSM.confirm PEERPSM.response Figure 6-11â€”TDLS peer PSM 6.3.49.2 MLME-TDLSPEERPSM.request 6.3.49.2.1 Function This primitive requests that a TDLS Peer PSM Request frame be sent to the TDLS peer STA. 420 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.49.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TDLSPEERPSM.request( TDLSPeerSTAAddress, TDLSPeerPSMRequest ) Name Type Valid range Description TDLSPeerSTAAddress MAC Any valid Specifies the MAC address of the TDLS peer Address individual MAC STA to which a TDLS Peer PSM Request frame Address is transmitted. TDLSPeerPSMRequest Sequence of As defined in Specifies the proposed service parameters for the octets TDLS Peer PSM TDLS peer PSM. Request frame 6.3.49.2.3 When generated This primitive is generated by the SME to request that a TDLS Peer PSM Request frame be sent to the TDLS peer STA. 6.3.49.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a TDLS Peer PSM Request frame. The STA then attempts to transmit this to the TDLS peer STA. 6.3.49.3 MLME-TDLSPEERPSM.confirm 6.3.49.3.1 Function This primitive reports the result of an MLME-TDLSPEERPSM.request primitive to initiate power save mode based on scheduled service periods with a TDLS peer STA. 6.3.49.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TDLSPEERPSM.confirm( TDLSPeerSTAAddress, TDLSPeerPSMResponse ) Name Type Valid range Description TDLSPeerSTAAddress MAC Any valid individual MAC Specifies the MAC address of the TDLS Address Address peer STA from which a TDLS Peer PSM Response frame was received. TDLSPeerPSMResponse Sequence of As defined in TDLS Peer Specifies the proposed service octets PSM Response frame parameters for the TDLS peer PSM. 6.3.49.3.3 When generated This primitive is generated by the MLME as a result of an MLME-TDLSPEERPSM.request primitive and indicates the results of the request. 421 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This primitive is generated when the STA successfully receives a TDLS Peer PSM Response frame from the TDLS peer STA or when an unspecified failure occurs. 6.3.49.3.4 Effect of receipt On receipt of this primitive, the SME evaluates the results of the MLME-TDLSPEERPSM.request primitive and may use the reported data. 6.3.49.4 MLME-TDLSPEERPSM.indication 6.3.49.4.1 Function This primitive indicates that a TDLS Peer PSM Request frame was received from a TDLS peer STA. 6.3.49.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TDLSPEERPSM.indication( TDLSPeerSTAAddress, TDLSPeerPSMRequest ) Name Type Valid range Description TDLSPeerSTAAddress MAC Any valid Specifies the MAC address of the TDLS peer Address individual STA MAC entity from which a TDLS Peer PSM MAC Address Request frame was received. TDLSPeerPSMRequest Sequence of As defined in Specifies the proposed service parameters for the octets TDLS Peer TDLS peer PSM. PSM Request frame 6.3.49.4.3 When generated This primitive is generated by the MLME when a valid TDLS Peer PSM Request frame is received. 6.3.49.4.4 Effect of receipt On receipt of this primitive, the SME should operate according to the procedure in 11.2.3.14. 6.3.49.5 MLME-TDLSPEERPSM.response 6.3.49.5.1 Function This primitive requests that a TDLS Peer PSM Response frame be sent to the TDLS peer STA. 6.3.49.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TDLSPEERPSM.response( TDLSPeerSTAAddress, TDLSPeerPSMResponse ) 422 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description TDLSPeerSTAAddress MAC Any valid Specifies the MAC address of the TDLS peer Address individual MAC STA to which a TDLS Peer PSM Response frame Address is transmitted. TDLSPeerPSMResponse Sequence of As defined in Specifies the proposed service parameters for the octets TDLS Peer PSM TDLS peer PSM. Response frame 6.3.49.5.3 When generated This primitive is generated by the SME to request that a TDLS Peer PSM Response frame be sent to the TDLS peer STA. 6.3.49.5.4 Effect of receipt On receipt of this primitive, the MLME constructs a TDLS Peer PSM Response frame. The STA then attempts to transmit this to the TDLS peer STA. 6.3.50 Event request 6.3.50.1 General This set of primitives supports the exchange of Event Request and Event Report frames. The informative diagram shown in Figure 6-12 illustrates the Event Request and Event Report process and is not meant to be exhaustive of all possible protocol uses. 6.3.50.2 MLME-EVLREQUEST.request 6.3.50.2.1 Function This primitive requests the transmission of an event request to a peer entity. 6.3.50.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-EVLREQUEST.request( Peer MAC Address, Dialog Token, Event Request Set, Destination URI, VendorSpecificInfo ) Name Type Valid range Description Peer MAC Address MACAddress Any valid The address of the peer MAC entity to which the individual MAC event request is sent. Address Dialog Token Integer 1â€“255 The dialog token to identify the event transaction. Event Request Set Set of event Set of event A set of event elements describing the requested elements elements event. Destination URI Destination URI Destination URI The Destination URI element as defined in element element 9.4.2.90. VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 423 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STA A STA B SME MLME MLME SME MLME- Event Log MLME-EVL EVLREQUEST.request Request frame REQUEST.indication MLME-EVLOG.request Process Event Log Action MLME-EVLOG.confirm MLME- Event Log MLME- EVLREPORT.indication Report frame EVLREPORT.request Figure 6-12â€”Event protocol exchange 6.3.50.2.3 When generated This primitive is generated by the SME to request that an Event Request frame be sent to a peer entity to initiate one or more transactions. 6.3.50.2.4 Effect of receipt On receipt of this primitive, the MLME constructs an Event Request frame containing the set of event elements specified. This frame is then scheduled for transmission. 6.3.50.3 MLME-EVLREQUEST.indication 6.3.50.3.1 Function This primitive indicates that an Event Request frame requesting an event transaction has been received. 6.3.50.3.2 Semantics of the service primitive The primitive parameters are as follows: 424 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MLME-EVLREQUEST.indication( Peer MAC Address, Dialog Token, Event Request Set, Destination URI, VendorSpecificInfo ) Name Type Valid range Description Peer MAC Address MACAddress Any valid The address of the peer MAC entity from which individual MAC the event request was received. Address Dialog Token Integer 1â€“255 The dialog token to identify the event transaction. Event Request Set Set of event Set of event A set of event elements describing the requested elements elements event. Destination URI Destination URI Destination URI The Destination URI element as defined in element element 9.4.2.90. VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.50.3.3 When generated This primitive is generated by the MLME when a valid Event Request frame is received. 6.3.50.3.4 Effect of receipt On receipt of this primitive, the SME either rejects the request or commences the event transaction. 6.3.51 Event report 6.3.51.1 General This set of primitives supports the signaling of event reports. 6.3.51.2 MLME-EVLREPORT.request 6.3.51.2.1 Function This primitive supports the signaling of event reports between peer SMEs. 6.3.51.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-EVLREPORT.request( Peer MAC Address, Dialog Token, Event Report Set, VendorSpecificInfo ) 425 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description Peer MAC Address MACAddress Any valid The address of the peer MAC entity to which the individual MAC event report is sent. Address Dialog Token Integer 1â€“255 The dialog token to identify the event transaction. Event Report Set Set of event Set of event A set of event elements describing the response elements elements to the event request. VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.51.2.3 When generated This primitive is generated by the SME to request that an Event Report frame be sent to a peer entity to report the results of one or more transactions. 6.3.51.2.4 Effect of receipt On receipt of this primitive, the MLME constructs an Event Report frame containing the set of event elements. This frame is then scheduled for transmission. 6.3.51.3 MLME-EVLREPORT.indication 6.3.51.3.1 Function This primitive indicates that an Event Report frame has been received from a peer entity. 6.3.51.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-EVLREPORT.indication( Peer MAC Address, Dialog Token, Event Report Set, VendorSpecificInfo ) Name Type Valid range Description Peer MAC Address MACAddress Any valid The address of the peer MAC entity from which individual MAC the event report was received. Address Dialog Token Integer 1â€“255 The dialog token to identify the event transaction. Event Report Set Set of event Set of event A set of event elements describing the response elements elements to the event request. VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.51.3.3 When generated This primitive is generated by the MLME when a valid Event Report frame is received. 6.3.51.3.4 Effect of receipt On receipt of this primitive, the event data can be made available for SME processes. 426 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.52 Event 6.3.52.1 General This set of primitives supports the requesting and reporting of event data. 6.3.52.2 MLME-EVLOG.request 6.3.52.2.1 Function This primitive is generated by the SME to request that the MLME identify specific events. 6.3.52.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-EVLOG.request( Dialog Token, Event Request Set ) Name Type Valid range Description Dialog Token Integer 1â€“255 The dialog token to identify the event transaction. Event Request Set Set of event Set of event A set of event elements describing the response elements elements to the event request. 6.3.52.2.3 When generated This primitive is generated by the SME to request that the MLME initiate the specified event. 6.3.52.2.4 Effect of receipt On receipt of this primitive, the MLME commences the identification of events. 6.3.52.3 MLME-EVLOG.confirm 6.3.52.3.1 Function This primitive reports the result of an event. 6.3.52.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-EVLOG.confirm( Dialog Token, Event Report Set ) Name Type Valid range Description Dialog Token Integer 1â€“255 The dialog token to identify the event transaction. Event Report Set Set of event Set of event A set of event report elements describing the report elements report elements reported event. 427 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.52.3.3 When generated This primitive is generated by the MLME to report the results when event identification completes. 6.3.52.3.4 Effect of receipt On receipt of this primitive, the SME evaluates the result and, if appropriate, stores the events pending communication to the requesting entity or for local use. 6.3.53 Diagnostic request 6.3.53.1 General This set of primitives supports the initiation of diagnostics between peer SMEs. The informative diagram shown in Figure 6-13 depicts the diagnostic reporting process and is not meant to be exhaustive of all possible protocol uses. STA A STA B SME MLME MLME SME MLME- MLME- DIAGREQUEST.request Diagnostic Request frame DIAGREQUEST.indication Process Diagnostic Action MLME- Diagnostic Report frame MLME- DIAGREPORT.indication DIAGREPORT.request Figure 6-13â€”Diagnostic protocol exchange 6.3.53.2 MLME-DIAGREQUEST.request 6.3.53.2.1 Function This primitive requests the transmission of a Diagnostic Request frame to a peer entity. 6.3.53.2.2 Semantics of the service primitive The primitive parameters are as follows: 428 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MLME-DIAGREQUEST.request( Peer MAC Address, Dialog Token, Diagnostic Request Set, Destination URI, VendorSpecificInfo ) Name Type Valid range Description Peer MAC Address MACAddress Any valid The address of the peer MAC entity to which the individual MAC diagnostic request is sent. Address Dialog Token Integer 1â€“255 The dialog token to identify the diagnostic transaction. Diagnostic Request Set of diagnostic Set of diagnostic A set of diagnostic elements describing the Set elements elements requested diagnostics. Destination URI Destination URI Destination URI The Destination URI element as defined in element element 9.4.2.90. VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.53.2.3 When generated This primitive is generated by the SME to request that a Diagnostic Request frame be sent to a peer entity to initiate one or more diagnostic transactions. 6.3.53.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a Diagnostic Request frame containing the set of diagnostic elements specified. This frame is then scheduled for transmission. 6.3.53.3 MLME-DIAGREQUEST.indication 6.3.53.3.1 Function This primitive indicates that a Diagnostic Request frame requesting a Diagnostic transaction has been received. 6.3.53.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-DIAGREQUEST.indication( Peer MAC Address, Dialog Token, Diagnostic Request Set, Destination URI, VendorSpecificInfo ) 429 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description Peer MAC Address MACAddress Any valid The address of the peer MAC entity from which individual MAC the diagnostic request was received. Address Dialog Token Integer 1â€“255 The dialog token to identify the diagnostic transaction. Diagnostic Request Set of diagnostic Set of diagnostic A set of diagnostic elements describing the Set elements elements requested diagnostics. Destination URI Destination URI Destination URI The Destination URI element as defined in element element 9.4.2.90. VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.53.3.3 When generated This primitive is generated by the MLME when a valid Diagnostic Request frame is received. 6.3.53.3.4 Effect of receipt On receipt of this primitive, the SME either rejects the request or commences the diagnostic transaction. 6.3.54 Diagnostic report 6.3.54.1 MLME-DIAGREPORT.request 6.3.54.1.1 Function This primitive supports the signaling of diagnostic reports between peer SMEs. 6.3.54.1.2 Semantics of the service primitive The primitive parameters are as follows: MLME-DIAGREPORT.request( Peer MAC Address, Dialog Token, Diagnostic Report Set, VendorSpecificInfo ) Name Type Valid range Description Peer MAC Address MACAddress Any valid The address of the peer MAC entity from which individual MAC the diagnostic report was received. Address Dialog Token Integer 1â€“255 The dialog token to identify the diagnostic transaction. Diagnostic Report Set of diagnostic Set of diagnostic A set of diagnostic elements describing the Set elements elements results of the requested diagnostics. VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.54.1.3 When generated This primitive is generated by the SME to request that a Diagnostic Report frame be sent to a peer entity to report the results of one or more diagnostic transactions. 430 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.54.1.4 Effect of receipt On receipt of this primitive, the MLME constructs a Diagnostic Report frame containing the set of diagnostic elements. This frame is then scheduled for transmission. 6.3.54.2 MLME-DIAGREPORT.indication 6.3.54.2.1 Function This primitive indicates that a Diagnostic Report frame has been received from a peer entity. 6.3.54.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-DIAGREPORT.indication( Peer MAC Address, Dialog Token, Diagnostic Report Set, VendorSpecificInfo ) Name Type Valid range Description Peer MAC Address MACAddress Any valid The address of the peer MAC entity to which the individual MAC diagnostic report is sent. Address Dialog Token Integer 1â€“255 The dialog token to identify the diagnostic transaction. Diagnostic Report Set of diagnostic Set of diagnostic A set of diagnostic elements describing the Set elements elements results of the requested diagnostics. VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.54.2.3 When generated This primitive is generated by the MLME when a valid Diagnostic Report frame is received. 6.3.54.2.4 Effect of receipt On receipt of this primitive, the diagnostic data can be made available for SME processes. 6.3.55 Location configuration request 6.3.55.1 General This set of primitives supports the exchange of location configuration parameter information between peer SMEs. The informative diagram shown in Figure 6-14 depicts the location configuration request and response process and is not meant to be exhaustive of all possible protocol uses. 431 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STA A STA B SME MLME MLME SME MLME- MLME- Location Configuration LOCATIONCFG LOCATIONCFG Request frame .indication .request Process Location Configuration Action MLME- MLME- LOCATIONCFG Location Configuration LOCATIONCFG .confirm Response frame .response Figure 6-14â€”Location configuration request and response protocol exchange 6.3.55.2 MLME-LOCATIONCFG.request 6.3.55.2.1 Function This primitive requests the transmission of a Location Configuration Request frame to a peer entity. 6.3.55.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-LOCATIONCFG.request( Peer MAC Address, Dialog Token, Location Parameters, VendorSpecificInfo ) Name Type Valid range Description Peer MAC Address MACAddress Any valid The address of the peer MAC entity to which the individual MAC location configuration request is sent. Address Dialog Token Integer 1â€“255 The dialog token to identify the location transaction. Location Location Location A Location Parameters element containing one or Parameters Parameters Parameters more subelements describing the STA location element element information. See 9.4.2.71. VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 432 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.55.2.3 When generated This primitive is generated by the SME to request that a Location Configuration Request frame be sent to a peer entity to convey location configuration information. 6.3.55.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a Location Configuration Request frame containing the set of Location Parameters elements specified. This frame is then scheduled for transmission. 6.3.55.3 MLME-LOCATIONCFG.confirm 6.3.55.3.1 Function This primitive reports the result of a location configuration request. 6.3.55.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-LOCATIONCFG.confirm( Dialog Token, Peer MAC Address, Location Parameters, VendorSpecificInfo ) Name Type Valid range Description Dialog Token Integer 1â€“255 The dialog token to identify the location transaction. Peer MAC Address MACAddress Any valid The address of the peer MAC entity to which the individual MAC location configuration response is sent. Address Location Location Location A Location Parameters element containing one or Parameters Parameters Parameters more subelements describing the STA location element element information. See 9.4.2.71. VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.55.3.3 When generated This primitive is generated by the MLME when transmission of the Location Configuration Request frame is acknowledged, when (re)transmission of the Location Configuration Request frame fails, or when a failure reason is unspecified. 6.3.55.3.4 Effect of receipt No effect of receipt is specified. 6.3.55.4 MLME-LOCATIONCFG.indication 6.3.55.4.1 Function This primitive indicates that a Location Configuration Request frame has been received requesting a location transaction. 433 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.55.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-LOCATIONCFG.indication( Peer MAC Address, Dialog Token, Location Parameters, VendorSpecificInfo ) Name Type Valid range Description Peer MAC Address MACAddress Any valid The address of the peer MAC entity from which individual MAC the location configuration request was received. Address Dialog Token Integer 1â€“255 The dialog token to identify the location transaction. Location Location Location A Location Parameters element containing one or Parameters Parameters Parameters more subelements describing the STA location element element information. See 9.4.2.71. VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.55.4.3 When generated This primitive is generated by the MLME when a valid Location Configuration Request frame is received. 6.3.55.4.4 Effect of receipt On receipt of this primitive, the SME either rejects the request or commences the location transaction. 6.3.55.5 MLME-LOCATIONCFG.response 6.3.55.5.1 Function This primitive requests the transmission of location information to a peer entity, in response to a received Location Configuration Request frame. 6.3.55.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-LOCATIONCFG.response( Peer MAC Address, Dialog Token, Location Parameters, VendorSpecificInfo ) 434 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description Peer MAC Address MACAddress Any valid The address of the peer MAC entity to which the individual MAC location request is sent. Address Dialog Token Integer 1â€“255 The dialog token to identify the location transaction. Location Location Location A location parameters element containing one or Parameters Parameters Parameters more subelements describing the STA location element element information. See 9.4.2.71. VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.55.5.3 When generated This primitive is generated by the SME to request that a Location Configuration Response frame be sent to a peer entity to convey location configuration information. 6.3.55.5.4 Effect of receipt On receipt of this primitive, the MLME constructs a Location Configuration Response frame containing the set of location parameters elements specified. This frame is then scheduled for transmission. 6.3.56 Location track notification 6.3.56.1 General This set of primitives supports the location track notification from one SME to one or more receiving SMEs. The informative diagram in Figure 6-15 depicts the location track notification process, is not meant to be exhaustive of all possible protocol uses. STA A STA B SME MLME MLME SME MLME- Location Track MLME-LOCATIONTRACKNOTIF LOCATIONTRACKNOTIF .request Notification frame .indication Figure 6-15â€”Location track notification protocol exchange 6.3.56.2 MLME-LOCATIONTRACKNOTIF.request 6.3.56.2.1 Function This primitive requests the transmission of Location Configuration Request frame to a peer entity. 6.3.56.2.2 Semantics of the service primitive The primitive parameters are as follows: 435 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MLME-LOCATIONTRACKNOTIF.request( Peer MAC Address, Location Parameters, Measurement Report, VendorSpecificInfo ) Name Type Valid range Description Peer MAC Address MACAddress Any valid The address of the peer MAC entity to which the individual or location track notification is sent. group addressed MAC Address Location Location Location A location parameters element containing one or Parameters Parameters Parameters more subelements describing the STA location element element information. See 9.4.2.71. Measurement Measurement Measurement A Measurement Report element contains the Report Report element Report element beacon measurement information. See 9.4.2.22. VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.56.2.3 When generated This primitive is generated by the SME to request that a Location Track Notification frame be sent to a peer entity to help convey location information. 6.3.56.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a Location Track Notification frame containing the set of location parameters elements specified. This frame is then scheduled for transmission. 6.3.56.3 MLME-LOCATIONTRACKNOTIF.indication 6.3.56.3.1 Function This primitive indicates that a Location Track Notification frame has been received. 6.3.56.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-LOCATIONTRACKNOTIF.indication( Peer MAC Address, Location Parameters, Measurement Report, VendorSpecificInfo ) 436 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description Peer MAC Address MACAddress Any valid The address of the peer MAC entity from which individual or the location track notification was received. group addressed MAC Address Location Location Location A location parameters element containing one or Parameters Parameters Parameters more subelements describing the STA location element element information. See 9.4.2.71. Measurement Measurement Measurement A Measurement Report element contains the Report Report element Report element beacon measurement information. See 9.4.2.22. VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.56.3.3 When generated This primitive is generated by the MLME when a valid Location Track Notification frame is received. 6.3.56.3.4 Effect of receipt On receipt of this primitive, the SME uses the information contained within the notification. 6.3.57 Timing measurement 6.3.57.1 General The following set of primitives supports exchange of timing measurement information from one SME to another. The informative diagram in Figure 6-16 depicts various points in time that are of interest to the timing measurement procedure. STA A STA B SME MLME MLME SME t1 MLME-TIMINGMSMT.request t2 t3 MLME-TIMINGMSMT t4 .indication MLME-TIMINGMSMT.confirm Figure 6-16â€”Timing measurement primitives and timestamps capture NOTE 1â€”In Figure 6-16, t1 and t3 correspond to the point in time at which the start of the preamble for the transmitted frame appears at the transmit antenna connector. An implementation may capture a timestamp during the transmit processing earlier or later than the point at which it actually occurs and offset the value to compensate for the time difference. NOTE 2â€”In Figure 6-16, t2 and t4 correspond to the point in time at which the start of the preamble for the incoming frame arrives at the receive antenna connector. Because time is needed to detect the frame and synchronize with its logical structure, an implementation determines when the start of the preamble for the incoming frame arrived at the receive antenna connector by capturing a timestamp some time after it occurred and compensating for the delay by subtracting an offset from the captured value. 437 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.57.2 MLME-TIMINGMSMT.request 6.3.57.2.1 Function This primitive requests the transmission of Timing Measurement frame to a peer entity. 6.3.57.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TIMINGMSMT.request( Peer MAC Address, Dialog Token, Follow Up Dialog Token, t1, Max t1 Error, t4, Max t4 Error, VendorSpecific ) Name Type Valid range Description Peer MAC Address MACAddress Any valid The address of the peer MAC entity to which the individual Timing Measurement frame is sent. addressed MAC Address Dialog Token Integer 1â€“255 The dialog token to identify the Timing Measurement frame. Follow Up Dialog Integer 0â€“255 The dialog token of a Timing Measurement Token frame which the current frame follows, or 0 if there is no such frame. See 11.24.5. t1 Integer 0â€“(232â€“1) The value of t1 (see Figure 6-16) for the Timing Measurement frame identified by the Follow Up Dialog Token, in units of 10 ns, or null if the Follow Up Dialog Token is 0. Max t1 Error Integer 0â€“255 The maximum error in the t1 value in units of 10 ns; see 9.6.15.3, or null if the Follow Up Dialog Token is 0. t4 Integer 0â€“(232â€“1) The value of t4 (see Figure 6-16) for the Timing Measurement frame identified by the Follow Up Dialog Token, in units of 10 ns, or null if the Follow Up Dialog Token is 0. Max t4 Error Integer 0â€“255 The maximum error in the t4 value in units of 10 ns, or null if the Follow Up Dialog Token is 0. VendorSpecific A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.57.2.3 When generated This primitive is generated by the SME to request that a Timing Measurement frame be sent to a peer entity. 6.3.57.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a Timing Measurement frame with the specified parameters. This frame is then scheduled for transmission. 438 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.57.3 MLME-TIMINGMSMT.confirm 6.3.57.3.1 Function This primitive indicates that a Timing Measurement frame has been received by the peer STA to which it was sent. 6.3.57.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TIMINGMSMT.confirm( Peer MAC Address, Dialog Token, t1, Max t1 Error, t4, Max t4 Error ) Name Type Valid range Description Peer MAC Address MACAddress Any valid The address of the peer MAC entity to which individual acknowledges the receipt of the Timing addressed MAC Measurement frame. Address Dialog Token Integer 1â€“255 The dialog token to identify the Timing Measurement frame. t1 32-bit unsigned 0 â€“ (232â€“1) The value of t1 (see Figure 6-16) for the Timing Integer Measurement frame identified by the Dialog Token, in units of 10 ns, or null if the Dialog Token is 0. Max t1 Error Integer 0â€“255 The maximum error in the t1 value in units of 10 ns; see 9.6.15.3, or null if the Dialog Token is 0. t4 32-bit unsigned 0 â€“ (232â€“1) The value of t4 (see Figure 6-16) for the Timing Integer Measurement frame identified by the Dialog Token, in units of 10 ns, or null if the Dialog Token is 0. Max t4 Error Integer 0â€“255 The maximum error in the t4 value in units of 10 ns, or null if the Dialog Token is 0. 6.3.57.3.3 When generated This primitive is generated by the MLME when an Ack frame corresponding to the Timing Measurement frame is received from the peer STA. 6.3.57.3.4 Effect of receipt On receipt of this primitive, the SME uses the information contained within the notification. 439 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.57.4 MLME-TIMINGMSMT.indication 6.3.57.4.1 Function This primitive indicates that a Timing Measurement frame has been received and the corresponding Ack frame has been transmitted. 6.3.57.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TIMINGMSMT.indication( Peer MAC Address, Dialog Token, Follow Up Dialog Token, t1, Max t1 Error, t4, Max t4 Error, t2, Max t2 Error, t3, Max t3 Error, VendorSpecific ) Name Type Valid range Description Peer MAC Address MACAddress Any valid The address of the peer MAC entity from which individual the Timing Measurement frame was sent. addressed MAC Address Dialog Token Integer 1â€“255 The dialog token to identify the Timing Measurement frame. Follow Up Dialog Integer 1â€“255 The dialog token of a Timing Measurement frame Token which the current frame follows, or 0 if there is no such frame. See 11.24.5. t1 32-bit unsigned 0 â€“ (232â€“1) The value of t1 (see Figure 6-16) for the Timing integer Measurement frame identified by the Follow Up Dialog Token, contained in the Timing Measurement frame identified by the Dialog Token, in units of 10 ns, or null if the Follow Up Dialog Token is 0. Max t1 Error Integer 0â€“255 The maximum error in the t1 value in units of 10 ns; see 9.6.15.3, or null if the Follow Up Dialog Token is 0. t4 32-bit unsigned 0 â€“ (232â€“1) The value of t4 (see Figure 6-16) for the Timing integer Measurement frame identified by the Follow Up Dialog Token, contained in the Timing Measurement frame identified by the Dialog Token, in units of 10 ns, or null if the Follow Up Dialog Token is 0. Max t4 Error Integer 0â€“255 The maximum error in the t4 value in units of 10 ns, or null if the Follow Up Dialog Token is 0. 440 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description t2 32-bit unsigned 0 â€“ (232â€“1) The value of t2 (see Figure 6-16) for the Timing Integer Measurement frame identified by the Dialog Token, in units of 10 ns, or null if the Dialog Token is 0. Max t2 Error Integer 0â€“255 The maximum error in the t2 value in units of 10 ns, or null if the Dialog Token is 0. t3 32-bit unsigned 0 â€“ (232â€“1) The value of t3 (see Figure 6-16) for the Timing integer Measurement frame identified by the Dialog Token, in units of 10 ns, or null if the Dialog Token is 0. Max t3 Error Integer 0â€“255 The maximum error in the t3 value in units of 10 ns, or null if the Dialog Token is 0. VendorSpecific A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.57.4.3 When generated This primitive is generated by the MLME when a valid Timing Measurement frame is received. 6.3.57.4.4 Effect of receipt On receipt of this primitive, the SME uses the information contained within the notification. 6.3.58 Fine timing measurement (FTM) 6.3.58.1 General The following set of primitives supports exchange of FTM information from one SME to another. The informative diagram in Figure 6-17 depicts various points in time that are of interest to the FTM procedure. STA A STA B SME MLME Antenna Antenna MLME SME t1 MLME-FINETIMINGMSMT .request t2 MLME-FINETIMINGMSMT .indication MLME-FINETIMINGMSMT t3 .confirm t4 Figure 6-17â€”Fine timing measurement primitives and timestamps capture NOTE 1â€”In Figure 6-17, t1 and t3 correspond to the point in time at which the start of the preamble for the transmitted frame appears at the transmit antenna connector. An implementation may capture a timestamp during the transmit processing earlier or later than the point at which it actually occurs and offset the value to compensate for the time difference. NOTE 2â€”In Figure 6-17, t2 and t4 correspond to the point in time at which the start of the preamble for the incoming frame arrives at the receive antenna connector. Because time is needed to detect the frame and synchronize with its logical structure, an implementation determines when the start of the preamble for the incoming frame arrived at the 441 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications receive antenna connector by capturing a timestamp some time after it occurred and compensating for the delay by subtracting an offset from the captured value. NOTE 3â€”In the MLME-FINETIMINGMSMT.request primitive the t1, Max t1 Error Exponent, t4 and Max t4 Error Exponent parameters are set to the values in the prior MLME-FINETIMINGMSMT.confirm primitive for that Peer MAC Address and with a Dialog Token parameter equal to the Follow Up Dialog Token parameter in the request, or 0 if there was none. In the MLME-FINETIMIMGMSMT.confirm primitive the t1, Max t1 Error Exponent, t4 and Max t4 Error Exponent parameters are set to the values determined for the Fine Timing Measurement frame and its acknowledgment. This primitive is not issued if no acknowledgment is received. In the MLME- FINETIMINGMSMT.indication primitive the t1, Max t1 Error Exponent, t4 and Max t4 Error Exponent parameters are set to the values in the Fine Timing Measurement frame and the t2, Max t2 Error Exponent, t3 and Max t3 Error Exponent parameters are set to the values determined for the Fine Timing Measurement frame and its acknowledgment. 6.3.58.2 MLME-FINETIMINGMSMT.request 6.3.58.2.1 Function This primitive requests the transmission of a Fine Timing Measurement frame to a peer entity. 6.3.58.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-FINETIMINGMSMT.request( Peer MAC Address, Dialog Token, Follow Up Dialog Token, t1, Max t1 Error Exponent, t4, Max t4 Error Exponent, FTM Synchronization Information, LCI Report, Location Civic Report, Fine Timing Measurement Parameters, VendorSpecific ) Name Type Valid range Description Peer MAC Address MACAddress Any valid The address of the peer MAC entity to which the individual Fine Timing Measurement frame is sent. addressed MAC Address Dialog Token Integer 0â€“255 The dialog token to identify the Fine Timing Measurement frame. A value of 0 indicates the end of the FTM session. Follow Up Dialog Integer 0â€“255 The dialog token of a Fine Timing Measurement Token frame which the current frame follows, or 0 if there is no such frame. See 11.24.6. t1 Integer 0â€“(248â€“1) The value of t1 (see Figure 6-17) for the Fine Timing Measurement frame identified by the Follow Up Dialog Token, in units of picoseconds, or null if the Follow Up Dialog Token is 0. Max t1 Error Integer 0â€“31 The maximum error in the t1 value. This is Exponent represented using a function of the Max t1 Error Exponent parameter as defined in Equation (9-4), or is null if the Follow Up Dialog Token is 0. 442 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description 48 t4 Integer 0â€“(2 â€“1) The value of t4 (see Figure 6-17) for the Fine Timing Measurement frame identified by the Follow Up Dialog Token, in units of picoseconds, or null if the Follow Up Dialog Token is 0. Max t4 Error Integer 0â€“31 The maximum error in the t4 value. This is Exponent represented using a function of the Max t4 Error Exponent parameter as defined in Equation (9-4), or is null if the Follow Up Dialog Token is 0. FTM As defined in As defined in Optional element to report synchronization Synchronization 9.4.2.173 9.4.2.173 information of sender Information LCI Report As defined in As defined in Optional element to report LCI information of 9.6.8.33 9.6.8.33 sender Location Civic As defined in As defined in Optional element to report location civic Report 9.6.8.33 9.6.8.33 information of sender Fine Timing As defined in As defined in Optional element containing the proposed FTM Measurement 9.4.2.168 9.4.2.168 configuration Parameters VendorSpecific A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.58.2.3 When generated This primitive is generated by the SME to request that a Fine Timing Measurement frame be sent to a peer entity. 6.3.58.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a Fine Timing Measurement frame with the specified parameters. This frame is then scheduled for transmission. 6.3.58.3 MLME-FINETIMINGMSMT.confirm 6.3.58.3.1 Function This primitive indicates that a Fine Timing Measurement frame has been received by the peer STA to which it was sent. 6.3.58.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-FINETIMINGMSMT.confirm( Peer MAC Address, Dialog Token, t1, Max t1 Error Exponent, t4, Max t4 Error Exponent ) 443 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description Peer MAC Address MACAddress Any valid The address of the peer MAC entity to which individual acknowledges the receipt of the Fine Timing addressed MAC Measurement frame. Address Dialog Token Integer 0â€“255 The dialog token to identify the Fine Timing Measurement frame. A value of 0 indicates the end of the FTM session. t1 48-bit unsigned 0â€“(248â€“1) The value of t1 (see Figure 6-17) for the Fine Integer Timing Measurement frame identified by the Dialog Token, in units of picoseconds, or null if the Dialog Token is 0. Max t1 Error Integer 0â€“31 The maximum error in the t1 value. This is Exponent represented using a function of the Max t1 Error Exponent parameter as defined in Equation (9-4), or is null if the Dialog Token is 0. t4 48-bit unsigned 0â€“(248â€“1) The value of t4 (see Figure 6-17) for the Fine Integer Timing Measurement frame identified by the Dialog Token, in units of picoseconds, or null if the Dialog Token is 0. Max t4 Error Integer 0â€“31 The maximum error in the t4 value. This is Exponent represented using a function of the Max t4 Error Exponent parameter as defined in Equation (9-4), or is null if the Dialog Token is 0. 6.3.58.3.3 When generated This primitive is generated by the MLME when an Ack frame corresponding to the Fine Timing Measurement frame is received from the peer STA. 6.3.58.3.4 Effect of receipt On receipt of this primitive, the SME uses the information contained within the notification. 6.3.58.4 MLME-FINETIMINGMSMT.indication 6.3.58.4.1 Function This primitive indicates that a Fine Timing Measurement frame has been received and the corresponding Ack frame has been transmitted. 6.3.58.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-FINETIMINGMSMT.indication( Peer MAC Address, Dialog Token, Follow Up Dialog Token, t1, Max t1 Error Exponent, t4, Max t4 Error Exponent, t2, Max t2 Error Exponent t3, 444 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Max t3 Error Exponent, FTM Synchronization Information, LCI Report, Location Civic Report, Fine Timing Measurement Parameters, VendorSpecific ) Name Type Valid range Description Peer MAC Address MACAddress Any valid The address of the peer MAC entity from which individual the Fine Timing Measurement frame was sent. addressed MAC Address Dialog Token Integer 0â€“255 The dialog token to identify the Fine Timing Measurement frame. A value of 0 indicates the end of the FTM session. Follow Up Dialog Integer 0â€“255 The dialog token of a Fine Timing Measurement Token frame which the current frame follows, or 0 if there is no such frame. See 11.24.6. t1 48-bit unsigned 0â€“(248â€“1) The value of t1 (see Figure 6-17) for the Fine integer Timing Measurement frame identified by the Follow Up Dialog Token, contained in the Fine Timing Measurement frame identified by the Dialog Token, in units of picoseconds, or null if the Follow Up Dialog Token is 0. Max t1 Error Integer 0â€“31 The maximum error in the t1 value. This is Exponent represented using a function of the Max t1 Error Exponent parameter as defined in Equation (9-4), or is null if the Follow Up Dialog Token is 0. t4 48-bit unsigned 0â€“(248â€“1) The value of t4 (see Figure 6-17) for the Fine integer Timing Measurement frame identified by the Follow Up Dialog Token, contained in the Fine Timing Measurement frame identified by the Dialog Token, in units of picoseconds, or null if the Follow Up Dialog Token is 0. Max t4 Error Integer 0â€“31 The maximum error in the t4 value. This is Exponent represented using a function of the Max t4 Error Exponent parameter as defined in Equation (9-4), or is null if the Follow Up Dialog Token is 0. t2 48-bit unsigned 0â€“(248â€“1) The value of t2 (see Figure 6-17) for the Fine Integer Timing Measurement frame identified by the Dialog Token, in units of picoseconds, or null if the Dialog Token is 0. Max t2 Error Integer 0â€“31 The maximum error in the t2 value. This is Exponent represented using a function of the Max t2 Error Exponent parameter defined in Equation (9-4), or is null if the Dialog Token is 0. t3 48-bit unsigned 0â€“(248â€“1) The value of t3 (see Figure 6-17) for the Fine integer Timing Measurement frame identified by the Dialog Token, in units of picoseconds, or null if the Dialog Token is 0. Max t3 Error Integer 0â€“31 The maximum error in the t3 value. This is Exponent represented using a function of the Max t3 Error Exponent parameter defined in Equation (9-4), or is null if the Dialog Token is 0. FTM As defined in As defined in Optional element to report synchronization Synchronization 9.4.2.173 9.4.2.173 information of sender Information 445 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description LCI Report As defined in As defined in Optional element to report LCI information of 9.6.8.33 9.6.8.33 sender Location Civic As defined in As defined in Optional element to report location civic Report 9.6.8.33 9.6.8.33 information of sender Fine Timing As defined in As defined in Optional element containing the proposed FTM Measurement 9.4.2.168 9.4.2.168 configuration Parameters VendorSpecific A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.58.4.3 When generated This primitive is generated by the MLME when a valid Fine Timing Measurement frame is received. 6.3.58.4.4 Effect of receipt On receipt of this primitive, the SME uses the information contained within the notification. 6.3.59 BSS transition management 6.3.59.1 BSS transition management procedure The informative diagram shown in Figure 6-18 depicts the BSS transition management procedure and is not meant to be exhaustive of all possible protocol uses. 6.3.59.2 MLME-BTMQUERY.request This set of primitives supports the signaling of BSS Transition Management Query frames between non-AP STAs and an AP. 6.3.59.2.1 Function This primitive requests transmission of a BSS Transition Management Query frame to the AP with which the STA is associated. 6.3.59.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-BTMQUERY.request( Peer MAC Address, DialogToken, BSSTransitionQueryReason, BSSTransitionCandidateListEntries, VendorSpecificInfo ) 446 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications AP Non-AP STA SME MLME MLME SME Decision to request or provide BSS transition candidate AP list MLME-BTMQUERY BSS Transition Management .indication MLME-BTMQUERY Query frame (optional) .request Decision to send autonomous BSS Transition Request or triggered by BSS Transition Query BSS Transition Management MLME-BTM.indication MLME-BTM.request Request frame STA roaming evaluation and decision BSS Transition Management MLME-BTM.response MLME-BTM.confirm Response frame (optional) STA reassociation or Fast BSS Transition STA reassociation Figure 6-18â€”BSS transition management requestâ€”accepted Name Type Valid range Description Peer MAC Address MACAddress Any valid The address of the peer MAC entity to which the individual MAC BSS Transition Management Query frame is sent. Address DialogToken Integer 1â€“255 The dialog token to identify this BSS transition management transaction. BSSTransitionQuery Integer 0â€“255 As defined in 9.6.14.8. Reason BSSTransitionCandi Set of Neighbor Set of Neighbor Contains the description of candidate BSS dateListEntries Report Elements Report Elements transition APs and their capabilities as described as defined in the in 9.4.2.37. Neighbor Report Element in 9.4.2.37 VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 447 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.59.2.3 When generated This primitive is generated by the SME to request that a BSS Transition Management Query frame be sent to the AP with which the STA is associated to initiate a BSS transition management procedure. 6.3.59.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a BSS Transition Management Query frame. The STA then attempts to transmit the frame to the AP with which it is associated. 6.3.59.3 MLME-BTMQUERY.indication 6.3.59.3.1 Function This primitive indicates that a BSS Transition Management Query frame was received from a non-AP STA. 6.3.59.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-BTMQUERY.indication( Peer MAC Address, DialogToken, BSSTransitionQueryReason, BSSTransitionCandidateListEntries, VendorSpecificInfo ) Name Type Valid range Description Peer MAC Address MACAddress Any valid The address of the non-AP STA MAC entity individual MAC from which a BSS Transition Management Query Address frame was received. DialogToken Integer 1â€“255 The dialog token to identify the BSS transition management transaction received in the BSS Transition Management Query frame. BSSTransitionQuery Integer 0â€“255 The BSS Transition Query Reason Code in the Reason BSS Transition Management Query frame that was received. BSSTransitionCandi Set of Neighbor Set of Neighbor Contains the description of candidate BSS dateListEntries Report Elements Report Elements transition APs and their capabilities as described as defined in the in 9.4.2.37. Neighbor Report Element in 9.4.2.37 VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.59.3.3 When generated This primitive is generated by the MLME when a valid BSS Transition Management Query frame is received. 6.3.59.3.4 Effect of receipt On receipt of this primitive, the SME shall operate according to the procedure in 11.24.7. 448 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.59.4 MLME-BTM.request 6.3.59.4.1 Function This primitive requests transmission of a BSS Transition Management Request frame to a non-AP STA. 6.3.59.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-BTM.request( Peer MAC Address DialogToken, RequestMode, DisassociationTimer, ValidityInterval, BSSTerminationDuration, SessionInformationURL, BSSTransitionCandidateListEntries, VendorSpecificInfo ) Name Type Valid range Description Peer MAC Address MACAddress Any valid The address of the peer MAC entity to which the individual MAC BSS Transition Management Request frame is Address sent. DialogToken Integer 1â€“255 The dialog token to identify the BSS transition management transaction. Set to 0 for an autonomous BSS Transition Management Request frame. RequestMode Integer As specified in Contains RequestMode for the BSS Transition 9.6.14.10 Management Request frame. DisassociationTimer Integer 0 â€“ 65 535 Specifies the number of TBTTs until the AP disassociates the non-AP STA. A value of 0 indicates time of disassociation has not yet been determined and a value of 1 indicates disassociation shall occur before the next TBTT. ValidityInterval Integer 1â€“255 Specifies the number of beacon transmission times (TBTTs) until this recommendation of this BSS transition candidate list is no longer valid. BSSTerminationDura BSS BSS Contains the BSS Termination Duration tion Termination Termination subelement (see 9.4.2.37) for the current BSS and Duration Duration is subelement subelement present only when the BSS Termination Included field is 1 in the Request mode field. SessionInformationU URL n/a Optionally contains a URL formatted per IETF RL RFC 3986 where additional information pertaining to the userâ€™s accounting session is found. BSSTransitionCandi Set of Neighbor Set of Neighbor Contains the description of candidate BSS dateListEntries Report Elements Report Elements transition APs and their capabilities as described as defined in the in 9.4.2.37. Neighbor Report Element in 9.4.2.37 VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 449 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.59.4.3 When generated This primitive is generated by the SME to request that a BSS Transition Management Request frame be sent to an associated non-AP STA. This request is sent either following the reception of an MLME- BTMQUERY.indication primitive or may be sent autonomously. 6.3.59.4.4 Effect of receipt On receipt of this primitive, the MLME constructs a BSS Transition Management Request frame. The STA then attempts to transmit this frame to the indicated non-AP STA. 6.3.59.5 MLME-BTM.indication 6.3.59.5.1 Function This primitive indicates that a BSS Transition Management Request frame was received from the AP with which the STA is associated. 6.3.59.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-BTM.indication( PeerMACAddress, DialogToken, RequestMode, DisassociationTimer, ValidityInterval, BSSTerminationDuration, SessionInformationURL, BSSTransitionCandidateListEntries, VendorSpecificInfo ) Name Type Valid range Description PeerMACAddress MACAddress Any valid The address of the MAC entity from which a BSS individual MAC Transition Management Request frame was Address received. DialogToken Integer 1â€“255 The dialog token to identity the BSS transition management transaction as received in the BSS Transition Management Request frame. RequestMode Integer As specified in Contains the RequestMode for the BSS 9.6.14.10 Transition Management Request frame. Disassociation Integer 0 â€“ 65 535 Specifies the number of TBTTs until the AP Timer disassociates the non-AP STA. A value of 0 indicates time of disassociation has not been determined yet and a value of 1 indicates disassociation shall occur before the next TBTT. ValidityInterval Integer 1â€“255 Specifies the number of beacon transmission times (TBTTs) until this recommendation of this BSS transition candidate list is no longer valid. BSSTerminationDura BSS BSS Contains the BSS Termination Duration tion Termination Termination subelement (see 9.4.2.37) for the current BSS and Duration Duration is present only when the BSS Termination subelement subelement Included field is 1 in the Request mode field. 450 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description SessionInformationU URL n/a Optionally contains a URL formatted per IETF RL RFC 3986 where additional information pertaining to the userâ€™s accounting session may be found. BSSTransitionCandi Set of Neighbor Set of Neighbor Contains the description of candidate BSS dateListEntries Report Elements Report Elements transition APs and their capabilities as described as defined in the in 9.4.2.37. Neighbor Report Element in 9.4.2.37 VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.59.5.3 When generated This primitive is generated by the MLME when a valid BSS Transition Management Request frame is received. 6.3.59.5.4 Effect of receipt On receipt of this primitive the SME shall operate according to the procedure in 11.24.7. 6.3.59.6 MLME-BTM.response 6.3.59.6.1 Function This primitive requests transmission of a BSS Transition Management Response frame to the AP with which the STA is associated. 6.3.59.6.2 Semantics of the service primitive The primitive parameters are as follows: MLME-BTM.response( Peer MAC Address DialogToken, BTMStatusCode, BSSTerminationDelay, TargetBSSID, BSSTransitionCandidateListEntries, VendorSpecificInfo ) Name Type Valid range Description Peer MAC Address MACAddress Any valid The address of the peer MAC entity to which the individual MAC BSS Transition Management Query frame is sent. Address DialogToken Integer 1â€“255 The dialog token to identify the BSS transition management transaction. BTMStatusCode Integer 0â€“255 As defined in 9.6.14.10. BSSTerminationDelay Integer 0â€“255 As defined in 9.6.14.10. TargetBSSID MACAddress Any valid The BSSID of the BSS that the STA decided to individual MAC transition to. Field shall be null if STA decided Address not to transition. 451 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description BSSTransitionCandida Set of Neighbor Set of Neighbor Contains the description of candidate BSS teListEntries Report Elements Report Elements transition APs and their capabilities as described as defined in the in 9.4.2.37. Neighbor Report Element in 9.4.2.37 VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.59.6.3 When generated This primitive is generated by the SME to request that a BSS Transition Management Response frame be sent to the AP with which the STA is associated. 6.3.59.6.4 Effect of receipt On receipt of this primitive, the MLME constructs a BSS Transition Management Response frame. The non- AP STA then attempts to transmit this to the AP with which it is associated. 6.3.59.7 MLME-BTM.confirm 6.3.59.7.1 Function This primitive reports the results of a BSS Transition Management attempt with a specified peer MAC entity that is within an AP. 6.3.59.7.2 Semantics of the service primitive The primitive parameters are as follows: MLME-BTM.confirm( Peer MAC Address, DialogToken, BSSTransitionQueryReason, BTMStatusCode, BSSTerminationDelay, TargetBSSID, BSSTransitionCandidateListEntries, VendorSpecificInfo ) Name Type Valid range Description Peer MAC Address MAC Address Any valid The address of the non-AP STA MAC entity individual MAC from which a BSS Transition Management Address Response frame was received. DialogToken Integer 1â€“255 The dialog token to identify the BSS transition management transaction as received in the BSS Transition Management Response frame. BTMStatusCode Integer 0â€“255 As defined in 9.6.14.10. BSSTerminationDelay Integer 0â€“255 As defined in 9.6.14.10. TargetBSSID MACAddress Any valid The BSSID of the BSS that the STA indicated to individual MAC transition to as received in the BSS Transition Address Management Response frame. 452 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description BSSTransitionCandida Set of Neighbor Set of Neighbor Contains the BSS Transition Candidate List teListEntries Report Elements Report Elements Entries in the received BSS Transition as defined in the Management Response frame. Neighbor Report Element in 9.4.2.37 VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.59.7.3 When generated This primitive is generated by the MLME when transmission of the BSS Transition Management Request frame is acknowledged, when (re)transmission of the BSS Transition Management Request frame fails, or when a failure reason is unspecified. 6.3.59.7.4 Effect of receipt On receipt of this primitive, the SME shall operate according to the procedure in 11.24.7. 6.3.60 FMS setup 6.3.60.1 General The following MLME primitives support the signaling of FMS setup. The informative diagram shown in Figure 6-19 depicts the FMS setup process and is not meant to be exhaustive of all possible protocol uses. STA A STA B SME MLME MLME SME MLME-FMS MLME-FMS .request FMS Request frame .indication Process FMS Action MLME-FMS MLME-FMS.confirm FMS Response frame .response Figure 6-19â€”FMS setup protocol exchange 453 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.60.2 MLME-FMS.request 6.3.60.2.1 Function This primitive requests that an FMS Request frame be sent to the AP with which the non-AP STA is associated. 6.3.60.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-FMS.request( PeerSTAAddress, DialogToken, FMSRequest, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MAC Address Any valid Specifies the address of the peer MAC entity with individual MAC which to perform the FMS process. Address Dialog Token Integer 1â€“255 The dialog token to identify the FMS transaction. FMSRequest FMS Request As defined in Specifies the proposed service parameters for the element 9.4.2.76 FMS. VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.60.2.3 When generated This primitive is generated by the SME to request that an FMS Request frame be sent to the AP with which the STA is associated. 6.3.60.2.4 Effect of receipt On receipt of this primitive, the MLME constructs an FMS Request frame. The STA then attempts to transmit this to the AP with which it is associated. 6.3.60.3 MLME-FMS.confirm 6.3.60.3.1 Function This primitive reports the result of an FMS procedure. 6.3.60.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME- FMS.confirm( Peer MAC Address, Dialog Token, FMSResponse, VendorSpecificInfo ) 454 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description Peer MAC Address MACAddress Any valid The address of the peer MAC entity to which the individual MAC location response is sent. Address Dialog Token Integer 0â€“255 The dialog token to identify the FMS transaction. FMSResponse FMS Response As defined in Specifies service parameters for the FMS. element 9.4.2.77 VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.60.3.3 When generated This primitive is generated by the MLME as a result of an MLME-FMS.request primitive and indicates the results of the request. This primitive is generated when the STA receives an FMS Response frame from the AP. 6.3.60.3.4 Effect of receipt On receipt of this primitive, the SME should operate according to the procedure in 11.2.3.16. 6.3.60.4 MLME-FMS.indication 6.3.60.4.1 Function This primitive indicates that an FMS Request frame was received from a non-AP STA. 6.3.60.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME- FMS.indication( PeerSTAAddress, DialogToken, FMSRequest, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MACAddress Any valid The address of the non-AP STA MAC entity individual MAC from which an FMS Request frame was received. Address Dialog Token Integer 1â€“255 The dialog token to identify the FMS transaction. FMSRequest FMS Request As defined in Specifies the proposed service parameters for the element 9.4.2.76 FMS. VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.60.4.3 When generated This primitive is generated by the MLME when a valid FMS Request frame is received. 6.3.60.4.4 Effect of receipt On receipt of this primitive, the SME should operate according to the procedure in 11.2.3.16. 455 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.60.5 MLME-FMS.response 6.3.60.5.1 Function This primitive is either generated in response to a received FMS Request frame or autonomously by the AP and requests the transmission of an FMS Response frame. 6.3.60.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-FMS.response( PeerSTAAddress, FMSResponse, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MACAddress Any valid The address of the non-AP STA MAC entity individual MAC from which an FMS Request frame was received. Address Dialog Token Integer 0â€“255 The dialog token to identify the FMS transaction. FMSResponse FMS Response As defined in Specifies service parameters for the FMS. element 9.4.2.77 VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.60.5.3 When generated This primitive is generated by the SME to request that an FMS Response frame be sent to a peer entity to convey FMS information. 6.3.60.5.4 Effect of receipt On receipt of this primitive, the MLME constructs an FMS Response frame. The STA then attempts to transmit this to the non-AP STA indicated by the PeerSTAAddress parameter. 6.3.61 Collocated Interference request 6.3.61.1 General This set of primitives supports the exchange of collocated interference information between peer SMEs. The informative diagram shown in Figure 6-20 depicts the Collocated Interference request and response process and is not meant to be exhaustive of all possible protocol uses. 456 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STA A STA B SME MLME MLME SME MLME- MLME- Collocated Interference CLINTERFERENCE CLINTERFERENCE Request frame REQUEST.request REQUEST.indication Measurement process MLME- MLME- CLINTERFERENCE Collocated Interference CLINTERFERENCE REPORT.indication Response frame REPORT.request Figure 6-20â€”Collocated interference protocol exchange 6.3.61.2 MLME-CLINTERFERENCEREQUEST.request 6.3.61.2.1 Function This primitive requests the transmission of Collocated Interference Request frame to a peer entity. 6.3.61.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-CLINTERFERENCEREQUEST.request( Peer MAC Address, Dialog Token, Request Info, VendorSpecificInfo ) Name Type Valid range Description Peer MAC Address MACAddress Any valid The address of the peer MAC entity to which the individual MAC collocated interference request is sent. Address, or the group MAC address 457 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description Dialog Token Integer 1â€“255 The dialog token to identify the collocated interference transaction. Request Info Integer As defined in Specifies the requested information. the Collocated Interference Request frame, see 9.6.14.13 VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.61.2.3 When generated This primitive is generated by the SME to request that a Collocated Interference Request frame be sent to a peer entity. 6.3.61.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a Collocated Interference Request frame. This frame is then scheduled for transmission. 6.3.61.3 MLME-CLINTERFERENCEREQUEST.indication 6.3.61.3.1 Function This primitive indicates that a Collocated Interference Request frame has been received requesting a Collocated Interference report. 6.3.61.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-CLINTERFERENCEREQUEST.indication( Peer MAC Address, Dialog Token, Request Info, VendorSpecificInfo ) Name Type Valid range Description Peer MAC Address MACAddress Any valid The address of the peer MAC entity from which individual MAC the Collocated Interference request was received. Address or the group MAC address Dialog Token Integer 1â€“255 The dialog token to identify the collocated interference transaction. Request Info Integer As defined in Specifies the requested information. the Collocated Interference Request frame, see 9.6.14.13 VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 458 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.61.3.3 When generated This primitive is generated by the MLME when a valid Collocated Interference Request frame is received. 6.3.61.3.4 Effect of receipt On receipt of this primitive, the SME either rejects the request or commences the Collocated Interference reporting procedure as described in 11.24.9. 6.3.62 Collocated Interference report 6.3.62.1 General This set of primitives supports the exchange of collocated interference information between peer SMEs. 6.3.62.2 MLME-CLINTERFERENCEREPORT.request 6.3.62.2.1 Function This primitive requests the transmission of Collocated Interference Report to a peer entity, in response to a received Collocated Interference Request frame. 6.3.62.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-CLINTERFERENCEREPORT.request( Peer MAC Address, Dialog Token, Collocated Interference Report, VendorSpecificInfo ) Name Type Valid range Description Peer MAC Address MACAddress Any valid The address of the peer MAC entity to which the individual MAC Collocated Interference Report is sent. Address Dialog Token Integer 1â€“255 The dialog token to identify the collocated interference transaction. Collocated Collocated As defined in Specifies the collocated interference Interference Report Interference 9.4.2.85 characteristics. Report elements VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.62.2.3 When generated This primitive is generated by the SME to request that a Collocated Interference Report frame be sent to a peer entity to convey collocated interference information. 6.3.62.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a Collocated Interference Report frame. This frame is then scheduled for transmission. 459 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.62.3 MLME-CLINTERFERENCEREPORT.indication 6.3.62.3.1 Function This primitive indicates that a Collocated Interference Report frame has been received. 6.3.62.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-CLINTERFERENCEREPORT.indication( Peer MAC Address, Dialog Token, Collocated Interference Report, VendorSpecificInfo ) Name Type Valid range Description Peer MAC Address MACAddress Any valid The address of the peer MAC entity from which individual MAC the location response was received. Address Dialog Token Integer 1â€“255 The dialog token to identify the location transaction. Collocated Collocated As defined in Specifies the collocated interference Interference Report Interference 9.4.2.85 characteristics. Report elements VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.62.3.3 When generated This primitive is generated by the MLME when a valid Collocated Interference Report frame is received. 6.3.63 TFS setup 6.3.63.1 General This set of primitives supports the exchange of the signaling of TFS setup between peer SMEs. The informative diagram shown in Figure 6-21 depicts the TFS request and response process and is not meant to be exhaustive of all possible protocol uses. 460 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications AP Non-AP STA SME MLME MLME SME MLME- TFS.indication TFS Request frame MLME-TFS.request Process TFS TFS Operation Request Action MLME-TFS.response TFS Response frame MLME-TFS.confirm Figure 6-21â€”TFS request and response exchange 6.3.63.2 MLME-TFS.request 6.3.63.2.1 Function This primitive requests that a TFS Request frame be sent to the AP with which the STA is associated. 6.3.63.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TFS.request( PeerSTAAddress, DialogToken, TFSRequest, VendorSpecific ) Name Type Valid range Description PeerSTAAddress MAC Address Any valid Specifies the address of the peer MAC entity for individual MAC TFS. Address DialogToken Integer 0â€“255 The dialog token to identify the TFS Request and Response transaction. TFSRequest A set of TFS As defined in Specifies the proposed service parameters for the Request the TFS Request TFS. One or more TFS Request elements. elements element VendorSpecific A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.63.2.3 When generated This primitive is generated by the SME to request that a TFS Request frame be sent to the AP with which the STA is associated. 461 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.63.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a TFS Request frame. The STA then attempts to transmit this to the AP with which it is associated. 6.3.63.3 MLME-TFS.confirm 6.3.63.3.1 Function This primitive reports the result of a TFS procedure. 6.3.63.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TFS.confirm( PeerSTAAddress, DialogToken, TFSResponse, VendorSpecific ) Name Type Valid range Description PeerSTAAddress MAC Address Any valid The address of the peer MAC entity from which individual MAC the TFS Response frame is received. Address DialogToken Integer 0â€“255 The dialog token to identify the TFS Request and Response transaction. TFSResponse A set of TFS As defined in Specifies service parameters for the TFS. One or Response the TFS more TFS Response elements. elements Response element VendorSpecific A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.63.3.3 When generated This primitive is generated by the MLME when the STA receives a TFS Response frame from the AP. 6.3.63.3.4 Effect of receipt On receipt of this primitive, the SME evaluates the result and may use the reported data. The SME should operate according to the procedure in 11.24.12. 6.3.63.4 MLME-TFS.indication 6.3.63.4.1 Function This primitive indicates that a TFS Request frame was received from a non-AP STA. 462 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.63.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TFS.indication( PeerSTAAddress, DialogToken, TFSRequest, VendorSpecific ) Name Type Valid range Description PeerSTAAddress MACAddress Any valid The address of the non-AP STA MAC entity individual MAC from which a TFS Request frame was received. Address DialogToken Integer 0â€“255 The dialog token to identify the TFS Request and Response transaction. TFSRequest A set of TFS As defined in Specifies the proposed service parameters for the Request the TFS Request TFS. One or more TFS Request elements. elements element VendorSpecific A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.63.4.3 When generated This primitive is generated by the MLME when a valid TFS Request frame is received. 6.3.63.4.4 Effect of receipt On receipt of this primitive the SME should operate according to the procedure in 11.24.12. 6.3.63.5 MLME-TFS.response 6.3.63.5.1 Function This primitive is generated in response to an MLME-TFS.indication primitive requesting a TFS Response frame be sent to a non-AP STA. 6.3.63.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TFS.response( PeerSTAAddress, DialogToken, TFSResponse, VendorSpecific ) 463 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description PeerSTAAddress MACAddress Any valid The address of the non-AP STA MAC entity individual MAC from which a TFS Request frame was received. Address DialogToken Integer 0â€“255 The dialog token to identify the TFS Request and Response transaction. TFSResponse A set of TFS As defined in Specifies service parameters for the TFS. One or Response 9.4.2.81 more TFS Response elements. elements VendorSpecific A set of As defined in Zero or more elements. elements. 9.4.2.26 6.3.63.5.3 When generated This primitive is generated by the SME in response to an MLME-TFS.indication primitive requesting a TFS Response be sent to a non-AP STA. 6.3.63.5.4 Effect of receipt On receipt of this primitive, the MLME constructs a TFS Response frame. The STA then attempts to transmit this to the non-AP STA indicated by the PeerSTAAddress parameter. 6.3.64 WNM sleep mode request 6.3.64.1 General This set of primitives supports the exchange of sleep mode parameter information between peer SMEs. The informative diagram shown in Figure 6-22 depicts the sleep mode request and response process and is not meant to be exhaustive of all possible protocol uses. AP Non-AP STA SME MLME MLME SME MLME-SLEEPMODE WNM Sleep Mode Request MLME-SLEEPMODE .indication frame .request Process WNM sleep mode request MLME-SLEEPMODE WNM Sleep Mode Response MLME-SLEEPMODE .response frame .confirm Figure 6-22â€”WNM sleep mode request and response exchange 464 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.64.2 MLME-SLEEPMODE.request 6.3.64.2.1 Function This primitive requests that a WNM Sleep Mode Request frame be sent to the AP with which the STA is associated. 6.3.64.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-SLEEPMODE.request( PeerSTAAddress, DialogToken, SleepMode, TFSRequest, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MAC Address Any valid The address of the peer MAC entity to which the individual MAC WNM Sleep Mode Request frame is to be sent. Address DialogToken Integer 0â€“255 The dialog token to identify the WNM sleep mode request and response transaction. SleepMode As defined in As defined in Specifies the proposed WNM sleep mode service the WNM Sleep the WNM Sleep parameters for the WNM Sleep Mode Request Mode Mode frame. element element TFSRequest A set of TFS As defined in Specifies the proposed TFS service parameters Request 9.4.2.80 for the WNM Sleep Mode Request frame. elements VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.64.2.3 When generated This primitive is generated by the SME to request that a WNM Sleep Mode Request frame be sent to the AP with which the STA is associated. 6.3.64.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a WNM Sleep Mode Request frame. The STA then attempts to transmit this to the AP with which it is associated. 6.3.64.3 MLME-SLEEPMODE.indication 6.3.64.3.1 Function This primitive indicates that a WNM Sleep Mode Request frame was received from a non-AP STA. 465 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.64.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-SLEEPMODE.indication( PeerSTAAddress, DialogToken, SleepMode, TFSRequest, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MACAddress Any valid The address of the peer MAC entity from which individual MAC the WNM Sleep Mode Request frame is received. Address DialogToken Integer 0â€“255 The dialog token to identify the WNM sleep mode request and response transaction. SleepMode As defined in As defined in Specifies the proposed WNM sleep mode service the WNM Sleep the WNM Sleep parameters for the WNM Sleep Mode Request Mode Mode frame. element element TFSRequest A set of TFS As defined in Specifies the proposed TFS service parameters Request 9.4.2.80 for the WNM Sleep Mode Request frame. elements VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.64.3.3 When generated This primitive is generated by the MLME when a valid WNM Sleep Mode Request frame is received. 6.3.64.3.4 Effect of receipt On receipt of this primitive, the SME should operate according to the procedure in 11.2.3.18. 6.3.64.4 MLME-SLEEPMODE.response 6.3.64.4.1 Function This primitive requests the transmission of sleep mode information to a peer entity, in response to a received WNM Sleep Mode Request frame. 6.3.64.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-SLEEPMODE.response( PeerSTAAddress, DialogToken, SleepMode, TFSResponse, VendorSpecificInfo ) 466 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description PeerSTAAddress MAC Address Any valid The address of the peer MAC entity to which the individual MAC WNM Sleep Mode Response frame is to be sent. Address DialogToken Integer 0â€“255 The dialog token to identify the WNM sleep mode request and response transaction. SleepMode As defined in As defined in Specifies the proposed WNM sleep mode service the WNM Sleep the WNM Sleep parameters for the WNM Sleep Mode Response Mode Mode frame. element element TFSResponse A set of TFS As defined in Specifies the proposed TFS service parameters Request 9.4.2.81 for the WNM Sleep Mode Response frame. elements VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.64.4.3 When generated This primitive is generated by the SME to request that a WNM Sleep Mode Response frame be sent to a peer entity to convey WNM sleep mode information. 6.3.64.4.4 Effect of receipt On receipt of this primitive, the MLME constructs a WNM Sleep Mode Response frame containing the WNM Sleep Mode elements specified. This frame is then scheduled for transmission. 6.3.64.5 MLME-SLEEPMODE.confirm 6.3.64.5.1 Function This primitive reports the result of a request to send a WNM Sleep Mode Response frame. 6.3.64.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-SLEEPMODE.confirm( PeerSTAAddress, DialogToken, SleepMode, TFSResponse, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MAC Address Any valid The address of the peer MAC entity from which individual MAC the WNM Sleep Mode Response frame is Address received. DialogToken Integer 0â€“255 The dialog token to identify the WNM sleep mode request and response transaction. SleepMode As defined in As defined in Specifies the proposed WNM sleep mode service the WNM Sleep the WNM Sleep parameters for the WNM Sleep Mode Response Mode Mode frame. element element 467 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description TFSResponse A set of TFS As defined in Specifies the proposed TFS service parameters Request the TFS for the WNM Sleep Mode Response frame. elements Response element VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.64.5.3 When generated This primitive is generated by the MLME when the STA receives a WNM Sleep Mode Response frame from the AP. 6.3.64.5.4 Effect of receipt No effect of receipt is specified. 6.3.65 TIM broadcast setup 6.3.65.1 General The following MLME primitives support the signaling of TIM Broadcast Setup. The informative diagram shown in Figure 6-23 depicts the TIM Broadcast setup process and is not meant to be exhaustive of all possible protocol uses. STA A STA B SME MLME MLME SME MLME- MLME- TIMBROADCAST TIM Broadcast Request frame TIMBROADCAST .request .indication Process TIM Broadcast Action MLME- MLME- TIMBROADCAST TIM Broadcast Response TIMBROADCAST .confirm frame .response Figure 6-23â€”TIM broadcast setup protocol exchange 468 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.65.2 MLME-TIMBROADCAST.request 6.3.65.2.1 Function This primitive requests that a TIM Broadcast Request frame be sent to the AP with which the non-AP STA is associated. 6.3.65.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TIMBROADCAST.request( PeerSTAAddress, Dialog Token, TIMBroadcastRequest, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MAC Address Any valid Specifies the address of the peer MAC entity with individual MAC which to perform the TIM Broadcast process. Address Dialog Token Integer 1â€“255 The dialog token to identify the TIM Broadcast request and response transaction. TIMBroadcastRequ As defined in As defined in Specifies the proposed service parameters for the est TIM Broadcast 9.4.2.83 TIM Broadcast. Request element VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.65.2.3 When generated This primitive is generated by the SME to request that a TIM Broadcast Request frame be sent to the AP with which the STA is associated. 6.3.65.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a TIM Broadcast Request frame. The STA then attempts to transmit this to the AP with which it is associated. 6.3.65.3 MLME-TIMBROADCAST.confirm 6.3.65.3.1 Function This primitive reports the result of a TIM Broadcast procedure. 6.3.65.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TIMBROADCAST.confirm( PeerSTAAddress, Dialog Token, TIMBroadcastResponse, VendorSpecificInfo ) 469 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description PeerSTAAddress MAC Address Any valid Specifies the address of the peer MAC entity with individual MAC which to perform the TIM Broadcast process. Address Dialog Token Integer 0â€“255 The dialog token to identify the TIM Broadcast request and response transaction. TIMBroadcastResp As defined in As defined in Specifies service parameters for the TIM onse TIM Broadcast 9.4.2.84 Broadcast. Response element VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.65.3.3 When generated This primitive is generated by the MLME when the STA receives a TIM Broadcast Response frame from the AP. 6.3.65.3.4 Effect of receipt On receipt of this primitive, the SME evaluates the results in the TIMBroadcastResponse element and may use the reported data. 6.3.65.4 MLME-TIMBROADCAST.indication 6.3.65.4.1 Function This primitive indicates that a TIM Broadcast Request frame was received from a non-AP STA. 6.3.65.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TIMBROADCAST.indication( PeerSTAAddress, Dialog Token, TIMBroadcastRequest, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MACAddress Any valid The address of the non-AP STA MAC entity individual MAC from which a TIM Broadcast Request frame was Address received. Dialog Token Integer 1â€“255 The dialog token to identify the TIM Broadcast request and response transaction. TIMBroadcastRequ As defined in As defined in Specifies the proposed service parameters for the est TIM Broadcast 9.4.2.83 TIM Broadcast. Request element VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.65.4.3 When generated This primitive is generated by the MLME when a valid TIM Broadcast Request frame is received. 470 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.65.4.4 Effect of receipt On receipt of this primitive, the SME should operate according to the procedure in 11.2.3.17. 6.3.65.5 MLME-TIMBROADCAST.response 6.3.65.5.1 Function This primitive is generated in response to an MLME-TIMBROADCAST.indication primitive requesting a TIM Broadcast Response frame be sent to a non-AP STA. 6.3.65.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TIMBROADCAST.response( PeerSTAAddress, Dialog Token, TIMBroadcastResponse, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MACAddress Any valid The address of the non-AP STA MAC entity individual MAC from which a TIM Broadcast Request frame was Address received. Dialog Token Integer 0â€“255 The dialog token to identify the TIM Broadcast request and response transaction. TIM Broadcast As defined in As defined in Specifies service parameters for the TIM Response TIM Broadcast 9.4.2.84 Broadcast. Response element VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.65.5.3 When generated This primitive is generated by the SME in response to an MLME-TIMBROADCAST.indication primitive requesting a TIM Broadcast Response be sent to a non-AP STA. 6.3.65.5.4 Effect of receipt On receipt of this primitive, the MLME constructs a TIM Broadcast Response frame. The STA then attempts to transmit this to the non-AP STA indicated by the PeerSTAAddress parameter. 6.3.66 QoS traffic capability update 6.3.66.1 General The MLME-QOSTRAFFICCAPUPDATE.request and MLME-QOSTRAFFICCAPUPDATE.indication primitives provide the transport of QoS Traffic Capability information from a non-AP STA to the AP with which the STA is associated. The informative diagram shown in Figure 6-24 depicts the QoS traffic capability update process. 471 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NON-AP STA AP SME MLME MLME SME MLME-QOSTRAFFIC QoS Traffic Capability Update MLME-QOSTRAFFIC CAPUPDATE.request frame CAPUPDATE.indication Figure 6-24â€”QoS traffic capability update protocol exchange 6.3.66.2 MLME-QOSTRAFFICCAPUPDATE.request 6.3.66.2.1 Function This primitive requests that a QoS Traffic Capability Update frame be sent to the AP with which the STA is associated. 6.3.66.2.2 Semantics of the service primitive The primitive parameter is as follows: MLME-QOSTRAFFICCAPUPDATE.request( QoSTrafficCapability, VendorSpecificInfo ) Name Type Valid range Description QoS Traffic Bit field as As defined in Specifies the QoS Traffic Capability flags of the Capability defined in 9.6.14.23 non-AP STA. This parameter is present if 9.6.14.23 dot11WirelessManagementImplemented is true and dot11QoSTrafficCapabilityActivated is true, and it is not present otherwise. VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.66.2.3 When generated This primitive is generated by the SME to request that a QoS Traffic Capability Update frame be sent to the AP with which the STA is associated. 6.3.66.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a QoS Traffic Capability Update frame. The STA then attempts to transmit this to the AP with which it is associated. 472 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.66.3 MLME-QOSTRAFFICCAPUPDATE.indication 6.3.66.3.1 Function This primitive indicates that a QoS Traffic Capability Update frame was received from a non-AP STA. 6.3.66.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-QOSTRAFFICCAPUPDATE.indication( PeerSTAAddress, QoS Traffic Capability, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MACAddress Any valid The address of the non-AP STA MAC entity individual MAC from which a QoS Traffic Capability Update Address frame was received. QoS Traffic Bit field as As defined in Specifies the QoS Traffic Capability flags of the Capability defined in 9.6.14.23 non-AP STA. This parameter is present if 9.6.14.23 dot11WirelessManagementImplemented is true and dot11QoSTrafficCapabilityActivated is true, and it is not present otherwise. VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.66.3.3 When generated This primitive is generated by the MLME when a valid QoS Traffic Capability Update frame is received. 6.3.66.3.4 Effect of receipt On receipt of this primitive the SME should operate according to the procedure in 11.24.10. 6.3.67 Channel Usage request 6.3.67.1 General The following MLME primitives support the signaling of Channel Usage request. Figure 6-25 depicts the Channel Usage request process. The figure illustrates the basic protocol and is only an example and therefore is not meant to be exhaustive of all possible protocol uses. 473 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STA A STA B SME MLME MLME SME MLME- MLME- CHANNELUSAGE CHANNELUSAGE .request Channel Usage Request frame .indication Process Channel Usage request MLME- MLME- CHANNELUSAGE CHANNELUSAGE .confirm Channel Usage Response frame .response Figure 6-25â€”Channel usage request protocol exchange 6.3.67.2 MLME-CHANNELUSAGE.request 6.3.67.2.1 Function This primitive requests the transmission of a Channel Usage Request frame be sent to an AP. 6.3.67.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-CHANNELUSAGE.request( PeerSTAAddress, Dialog Token, ChannelUsage, SSID, SupportedOperatingClasses, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MAC Address Any valid Specifies the address of the peer MAC entity with individual MAC which to perform the Channel Usage process. Address Dialog Token Integer 1â€“255 The dialog token to identify the Channel Usage request and response transaction. ChannelUsage A set of Channel As defined in Specifies request types for the Channel Usage Usage element 9.4.2.86 request. 474 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description SSID Octet string 0â€“32 octets Specifies the desired SSID or the wildcard SSID. SupportedOperating As defined in As defined in Specifies the Supported Operating Classes Classes Supported 9.4.2.54 information for the Channel Usage Request. Operating Classes element VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.67.2.3 When generated This primitive is generated by the SME to request that a Channel Usage Request frame be sent to the BSS which is advertising the SSID passed down in this primitive. 6.3.67.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a Channel Usage Request frame. The STA then attempts to transmit this to the BSS which is advertising the SSID included in this primitive request. When wild card SSID is passed down, the MLME-CHANNELREQUEST.request primitive shall be transmitted to all BSSs in the current scan list as determined by the most recent MLME-SCAN.request primitive. 6.3.67.3 MLME-CHANNELUSAGE.confirm 6.3.67.3.1 Function This primitive reports the result of a Channel Usage procedure. 6.3.67.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-CHANNELUSAGE.confirm( PeerSTAAddress, Dialog Token, ChannelUsage, SSID, Country String, Power Constraint, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MAC Address Any valid Specifies the address of the peer MAC entity with individual MAC which to perform the Channel Usage process. Address Dialog Token Integer 1â€“255 The dialog token to identify the Channel Usage request and response transaction. ChannelUsage A set of Channel As defined in Specifies parameters for the Channel Usage. Usage element 9.4.2.86 475 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description SSID Octet string 0â€“32 octets Specifies the SSID or the wildcard SSID used in the request. Country String Octet string 3 octets Specifies Country strings. Power Constraint An element As defined in Zero or one Power Constraint element. 9.4.2.14 VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.67.3.3 When generated This primitive is generated when the STA receives a Channel Usage Response frame from the AP. 6.3.67.3.4 Effect of receipt On receipt of this primitive the SME should operate according to the procedure in 11.24.15. 6.3.67.4 MLME-CHANNELUSAGE.indication 6.3.67.4.1 Function This primitive indicates that a Channel Usage Request frame was received from a non-AP STA. 6.3.67.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-CHANNELUSAGE.indication( PeerSTAAddress, Dialog Token, ChannelUsage, SSID, SupportedOperatingClasses, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MACAddress Any valid The address of the non-AP STA MAC entity individual MAC from which a Channel Usage Request frame was Address received. Dialog Token Integer 0â€“255 The dialog token to identify the Channel Usage request and response transaction. ChannelUsage A set of Channel As defined in Specifies request types for the Channel Usage Usage element 9.4.2.86 request. SSID Octet string 0â€“32 octets Specifies the desired SSID or the wildcard SSID. SupportedOperating As defined in As defined in Specifies the Supported Operating Classes Classes Supported 9.4.2.54 information for the Channel Usage Request. Operating Classes element VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 476 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.67.4.3 When generated This primitive is generated by the MLME when a valid Channel Usage Request frame is received. 6.3.67.4.4 Effect of receipt On receipt of this primitive the SME should operate according to the procedure in 11.24.15. 6.3.67.5 MLME-CHANNELUSAGE.response 6.3.67.5.1 Function This primitive is generated in response to an MLME-CHANNELUSAGE.indication primitive requesting a Channel Usage Response frame be sent to a non-AP STA. 6.3.67.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-CHANNELUSAGE.response( PeerSTAAddress, Dialog Token, ChannelUsage, SSID, Country String, Power Constraint, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MACAddress Any valid The address of the non-AP STA MAC entity individual MAC from which a Channel Usage Request frame was Address received. Dialog Token Integer 0â€“255 The dialog token to identify the Channel Usage request and response transaction. ChannelUsage A set of Channel As defined in Specifies parameters for the Channel Usage. Usage elements 9.4.2.86 SSID Octet string 0â€“32 octets Specifies the desired SSID or the wildcard SSID. Country String Octet string 3 octets Specifies Country strings. Power Constraint An element As defined in Zero or one Power Constraint element. 9.4.2.14 VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.67.5.3 When generated This primitive is generated by the SME in response to an MLME-CHANNELUSAGE.indication primitive requesting a Channel Usage Response be sent to a non-AP STA. 6.3.67.5.4 Effect of receipt On receipt of this primitive, the MLME constructs a Channel Usage Response frame. The STA then attempts to transmit this to the non-AP STA indicated by the PeerSTAAddress parameter. 477 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.68 DMS or GCR request and response procedure 6.3.68.1 General The following MLME primitives support the signaling of DMS or GCR request and response procedure. The informative diagram shown in Figure 6-26 depicts the DMS or GCR request and response process and is not meant to be exhaustive of all possible protocol uses. STA AP SME MLME MLME SME MLME- MLME-GATS DMS Request frame .indication GATS.request Process DMS or GCR request MLME- MLME-GATS DMS Response frame .response GATS.confirm AP may terminate a granted DMS or GCR service at any time MLME-GATS- MLME-GATS- TERM.indication DMS Response frame TERM.request Figure 6-26â€”DMS or GCR setup protocol exchange 6.3.68.2 MLME-GATS.request 6.3.68.2.1 Function This primitive requests the transmission of a DMS Request frame be sent to an AP or peer mesh STA. 6.3.68.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-GATS.request( PeerSTAAddress, Dialog Token, DMSRequest, VendorSpecificInfo ) 478 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description PeerSTAAddres MAC Address Any valid Specifies the address of the peer MAC entity with s individual which to perform the DMS or GCR process. MAC Address Dialog Token Integer 1â€“255 The dialog token to identify the DMS or GCR request and response transaction. DMSRequest Sequence of As defined in Specifies group addressed frames and parameters DMS Request 9.4.2.88 for the requested DMS or GCR stream. elements VendorSpecific A set of As defined in Zero or more elements. Info elements 9.4.2.26 6.3.68.2.3 When generated This primitive is generated by the SME to request that a DMS Request frame be sent to the AP with which the STA is associated or peer mesh STA. 6.3.68.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a DMS Request frame. The STA then attempts to transmit this to the AP with which the STA is associated or peer mesh STA. 6.3.68.3 MLME-GATS.confirm 6.3.68.3.1 Function This primitive reports the result of a DMS or GCR procedure. 6.3.68.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-GATS.confirm( PeerSTAAddress, Dialog Token, DMSResponse, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MAC Address Any valid Specifies the address of the peer MAC entity individual MAC with which to perform the DMS or GCR process. Address Dialog Token Integer 1â€“255 The dialog token to identify the DMS or GCR request and response transaction. DMSResponse Sequence of DMS As defined in Specifies the status returned by the AP or peer Response 9.4.2.89 mesh STA responding to the STAâ€™s requested elements DMS or GCR stream. VendorSpecificIn A set of elements As defined in Zero or more elements. fo 9.4.2.26 6.3.68.3.3 When generated This primitive is generated when the STA receives a DMS Response frame from the AP or peer mesh STA. 479 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.68.3.4 Effect of receipt On receipt of this primitive the SME should operate according to the procedure in 11.24.16. 6.3.68.4 MLME-GATS.indication 6.3.68.4.1 Function This primitive indicates that a DMS Request frame was received from a non-AP STA or peer mesh STA. 6.3.68.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-GATS.indication( PeerSTAAddress, Dialog Token, DMSRequest, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MACAddress Any valid The address of the non-AP STA or peer mesh individual MAC STA MAC entity from which a DMS Request Address frame was received. Dialog Token Integer 1â€“255 The dialog token to identify the DMS or GCR request and response transaction. DMSRequest Sequence of As defined in Specifies group addressed frames for the DMS Request 9.4.2.88 requested DMS or GCR stream. elements VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.68.4.3 When generated This primitive is generated by the MLME when a valid DMS Request frame is received. 6.3.68.4.4 Effect of receipt On receipt of this primitive the SME should operate according to the procedure in 11.24.16. 6.3.68.5 MLME-GATS.response 6.3.68.5.1 Function This primitive is generated in response to an MLME-GATS.indication primitive requesting a DMS Response frame be sent to a non-AP STA or peer mesh STA. 480 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.68.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-GATS.response( PeerSTAAddress, Dialog Token, DMSResponse, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MACAddress Any valid The address of the non-AP STA or peer mesh individual MAC STA MAC entity from which a DMS Request Address frame was received. Dialog Token Integer 1â€“255 The Dialog Token to identify the DMS or GCR request and response transaction. DMSResponse Sequence of As defined in Specifies the status returned by the AP or peer DMS Response 9.4.2.89 mesh STA responding to the STAâ€™s requested elements DMS or GCR stream. VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.68.5.3 When generated This primitive is generated by the SME in response to an MLME-GATS.indication primitive requesting a DMS Response be sent to a non-AP STA or peer mesh STA. 6.3.68.5.4 Effect of receipt On receipt of this primitive, the MLME constructs a DMS Response frame. The STA then attempts to transmit this to the non-AP STA or peer mesh STA indicated by the PeerSTAAddress parameter. 6.3.68.6 MLME-GATS-TERM.request 6.3.68.6.1 Function This primitive requests the transmission of a DMS Response frame to terminate a granted DMS or GCR service. 6.3.68.6.2 Semantics of the service primitive The primitive parameters are as follows: MLME-GATS-TERM.request( PeerSTAAddress, Dialog Token, DMSResponse, VendorSpecificInfo ) 481 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description PeerSTAAddress MACAddress Any valid The address of the non-AP STA or peer mesh individual MAC STA MAC entity from which a DMS Request Address frame was received. Dialog Token Integer 0 Set to 0 for an autonomous DMS Response frame. DMSResponse Sequence of As defined in Specifies the requested DMS or GCR stream that DMS Response 9.4.2.89 is canceled by the AP or peer mesh STA. elements VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.68.6.3 When generated This primitive is generated by the SME to terminate DMS or GCR service. 6.3.68.6.4 Effect of receipt On receipt of this primitive, the MLME constructs a DMS Response frame. The STA then attempts to transmit this to the non-AP STA or peer mesh STA indicated by the PeerSTAAddress parameter. 6.3.68.7 MLME-GATS-TERM.indication 6.3.68.7.1 Function This primitive is generated by the MLME when a valid unsolicited DMS Response frame is received. 6.3.68.7.2 Semantics of the service primitive The primitive parameters are as follows: MLME-GATS-TERM.indication( PeerSTAAddress, Dialog Token, DMSResponse, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MAC Address Any valid Specifies the address of the peer MAC entity individual MAC with which to perform the DMS or GCR process. Address Dialog Token Integer 0 Set to 0 for an autonomous DMS Response frame. DMSResponse Sequence of DMS As defined in Specifies the requested DMS or GCR stream that Response 9.4.2.89 is canceled by the AP or peer mesh STA. elements VendorSpecificIn A set of elements As defined in Zero or more elements. fo 9.4.2.26 6.3.68.7.3 When generated This primitive is generated when the STA receives an unsolicited DMS Response frame from the AP or peer mesh STA. 482 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.68.7.4 Effect of receipt On receipt of this primitive the SME should operate according to the procedure in 11.24.16. 6.3.69 Timing measurement request 6.3.69.1 General The following set of primitives supports triggering a Timing Measurement procedure or stopping an ongoing Timing Measurement procedure. 6.3.69.2 MLME-TIMINGMSMTRQ.request 6.3.69.2.1 Function This primitive requests the transmission of a Timing Measurement Request frame to a peer entity. 6.3.69.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TIMINGMSMTRQ.request( Peer MAC Address, Trigger, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MAC Address Any valid The address of the peer MAC entity to which the individual MAC Timing Measurement Request frame is sent. Address Trigger Integer 0â€“1 The trigger to identify the action. VendorSpecificIn A set of elements As defined in Zero or more elements. fo 9.4.2.26 6.3.69.2.3 When generated This primitive is generated by the SME to request that a Timing Measurement Request frame be sent to a peer entity. 6.3.69.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a Timing Measurement Request frame with the specified parameters. This frame is then scheduled for transmission. 6.3.69.3 MLME-TIMINGMSMTRQ.indication 6.3.69.3.1 Function This primitive indicates that a Timing Measurement Request frame has been received and the corresponding Ack frame has been transmitted. 483 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.69.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TIMINGMSMTRQ.indication( Peer MAC Address, Trigger, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MAC Address Any valid The address of the peer MAC entity to which the individual MAC Timing Measurement Request frame is sent. Address Trigger Integer 0â€“1 The trigger to identify the action. VendorSpecificIn A set of elements As defined in Zero or more elements. fo 9.4.2.26 6.3.69.3.3 When generated This primitive is generated by the MLME when a valid Timing Measurement Request frame is received. 6.3.69.3.4 Effect of receipt On receipt of this primitive, the SME uses the information contained within the notification. 6.3.70 Fine timing measurement request 6.3.70.1 General The following set of primitives supports triggering a FTM procedure or stopping an ongoing FTM procedure. 6.3.70.2 MLME-FINETIMINGMSMTRQ.request 6.3.70.2.1 Function This primitive requests the transmission of a Fine Timing Measurement Request frame to a peer entity. 6.3.70.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-FINETIMINGMSMTRQ.request( Peer MAC Address, Trigger, LCI Request, Location Civic Request, Fine Timing Measurement Parameters, Vendor Specific ) 484 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description PeerSTAAddress MAC Address Any valid The address of the peer MAC entity to which the individual MAC Fine Timing Measurement Request frame is sent. Address Trigger Integer 0â€“1 The trigger to identify the action. LCI Request As defined in As defined in Optional element to request LCI information of 9.6.8.32 9.6.8.32 sender Location Civic As defined in As defined in Optional element to request location civic Request 9.6.8.32 9.6.8.32 information of sender Fine Timing As defined in As defined in Optional element containing the requested FTM Measurement 9.4.2.168 9.4.2.168 configuration Parameters VendorSpecific A set of elements As defined by Zero or more elements 9.4.2.26 6.3.70.2.3 When generated This primitive is generated by the SME to request that a Fine Timing Measurement Request frame be sent to a peer entity. 6.3.70.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a Fine Timing Measurement Request frame with the specified parameters. This frame is then scheduled for transmission. 6.3.70.3 MLME-FINETIMINGMSMTRQ.indication 6.3.70.3.1 Function This primitive indicates that a Fine Timing Measurement Request frame has been received and the corresponding Ack frame has been transmitted. 6.3.70.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-FINETIMINGMSMTRQ.indication( Peer MAC Address, Trigger, LCI Request, Location Civic Request, Fine Timing Measurement Parameters, Vendor Specific ) Name Type Valid range Description PeerSTAAddress MAC Address Any valid The address of the peer MAC entity to which the individual MAC Fine Timing Measurement Request frame is sent. Address Trigger Integer 0â€“1 The trigger to identify the action. LCI Request As defined in As defined in Optional element to request LCI information of 9.6.8.32 9.6.8.32 sender Location Civic As defined in As defined in Optional element to request location civic Request 9.6.8.32 9.6.8.32 information of sender 485 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description Fine Timing As defined in As defined in Optional element containing the requested FTM Measurement 9.4.2.168 9.4.2.168 configuration Parameters VendorSpecific A set of elements As defined by Zero or more elements 9.4.2.26 6.3.70.3.3 When generated This primitive is generated by the MLME when a valid Fine Timing Measurement Request frame is received. 6.3.70.3.4 1 Effect of receipt On receipt of this primitive, the SME uses the information contained within the notification. 6.3.71 WNM notification request 6.3.71.1 General This set of primitives supports the exchange of WNM Notification Request and Response frames between peer SMEs. 6.3.71.2 MLME-WNMNOTIFICATIONREQUEST.request 6.3.71.2.1 Function This primitive requests the transmission of a WNM Notification Request frame to a peer entity. 6.3.71.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-WNMNOTIFICATIONREQUEST.request( Peer MAC Address, Dialog Token, Type, Optional Subelements, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MAC Address Any valid The address of the peer MAC entity to which individual MAC the WNM Notification Request frame is sent. Address Dialog Token Integer 1â€“255 The dialog token to identify the WNM notification transaction. Type Integer 1â€“255 The type of WNM notification. Optional Set subelements As defined in A set of subelements describing the notification. Subelements 9.6.14.29 VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 486 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.71.2.3 When generated This primitive is generated by the SME to request that a WNM Notification Request frame be sent to a peer entity to initiate a WNM notification. 6.3.71.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a WNM Notification Request frame containing the elements specified. This frame is then scheduled for transmission. 6.3.71.3 MLME-WNMNOTIFICATIONREQUEST indication 6.3.71.3.1 Function This primitive indicates that a WNM Notification Request frame has been received. 6.3.71.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-WNMNOTIFICATIONREQUEST.indication( Peer MAC Address, Dialog Token, Type, Optional Subelements, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MAC Address Any valid The address of the peer MAC entity from which individual MAC the WNM notification request was received. Address Dialog Token Integer 1â€“255 The dialog token to identify the WNM notification transaction. Type Integer 1â€“255 The type of WNM notification request. Optional Set subelements As defined in A set of subelements describing the Subelements 9.6.14.29 notification. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.71.3.3 When generated This primitive is generated by the MLME when a valid WNM Notification Request frame is received. 6.3.71.3.4 Effect of receipt On receipt of this primitive, the SME replies to the request. 487 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.72 WNM notification response 6.3.72.1 MLME-WNMNOTIFICATIONRESPONSE.request 6.3.72.1.1 Function This primitive supports the signaling of the WNM Notification Response frame between peer SMEs. 6.3.72.1.2 Semantics of the service primitive The primitive parameters are as follows: MLME-WNMNOTIFICATIONRESPONSE.request( Peer MAC Address, Dialog Token, Response Status, Optional Subelements, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MAC Address Any valid The address of the peer MAC entity to which individual MAC the WNM Notification Response frame is sent. Address Dialog Token Integer 1â€“255 The dialog token to identify the WNM notification transaction. Response Status Integer 1â€“255 The response status of the WNM notification. Optional Set subelements As defined in A set of subelements describing the results of Subelements 9.6.14.30 the WNM notification. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.72.1.3 When generated This primitive is generated by the SME to request that a WNM Notification Response frame be sent to a peer entity to report the results of the WNM notification. 6.3.72.1.4 Effect of receipt On receipt of this primitive, the MLME constructs a WNM Notification Response frame containing the indicated fields. This frame is then scheduled for transmission. 6.3.72.2 MLME-WNMNOTIFICATIONRESPONSE.indication 6.3.72.2.1 Function This primitive indicates that a WNM Notification Response frame has been received from a peer entity. 6.3.72.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-WNMNOTIFICATIONRESPONSE.indication( Peer MAC Address, Dialog Token, Response Status, 488 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Optional Subelements, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MAC Address Any valid The address of the peer MAC entity from which individual MAC the WNM Notification Response frame was Address received. Dialog Token Integer 1â€“255 The dialog token to identify the WNM notification transaction. Response Status Integer 1â€“255 The response status of the WNM notification. Optional Set subelements As defined in A set of subelements describing the results of Subelements 9.6.14.30 the WNM notification. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.72.2.3 When generated This primitive is generated by the MLME when a valid WNM Notification Response frame is received. 6.3.72.2.4 Effect of receipt On receipt of this primitive, the WNM notification can be made available for SME processes. 6.3.73 Network discovery and selection support 6.3.73.1 General This set of primitives supports the process of GAS. 6.3.73.2 MLME-GAS.request 6.3.73.2.1 Function This primitive requests the information of a specific advertisement service from another STA and requests the STA to provide GAS. 6.3.73.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-GAS.request( PeerSTAAddress, DialogToken, AdvertisementProtocolID, Query, QueryFailureTimeout, Protected, Multi-band, VendorSpecificInfo ) 489 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description PeerSTAAddress MacAddress Any valid Specifies the address of the peer MAC entity to individual which query is transmitted. MacAddress DialogToken Integer 0â€“255 The dialog token to identify the GAS transaction. AdvertisementProt Integer or As defined in This contains an Advertisement Protocol ID (see ocolID Sequence of Table 9-215 9.4.2.93), which might be IEEE 802.11 assigned integers or vendor specified. Query String N/A Query string formatted using protocol identified in AdvertisementProtocolID. E.g., if the AdvertisementProtocolID value is 1, then Query is formatted as defined in IEEE Std 802.21-2008. QueryFailureTimeo Integer >1 The time limit, in units of beacon intervals, after ut which the GAS Query procedure is terminated. Protected Boolean true, false Specifies whether the request is sent using a robust Management frame. If true, the request is sent using a Protected Dual of Public Action frame. Otherwise, the request is sent using a Public Action frame. Multi-band Multi-band As defined in Specifies the frequency band and channel number element 9.4.2.138 to which the GAS transaction applies. The parameter is absent if the GAS transaction applies to the same frequency band and channel where the frame is transmitted. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.73.2.3 When generated This primitive is generated by the SME to request a specific Advertisement Service from another STA. 6.3.73.2.4 Effect of receipt The STA operates according to the procedures defined in 11.25.3. 6.3.73.3 MLME-GAS.confirm 6.3.73.3.1 Function This primitive reports the status code and Query Response from an Advertisement Server to the requesting STA. 6.3.73.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-GAS.confirm( PeerSTAAddress, DialogToken, ResultCode, ResponseInfo, Protected, Multi-band, VendorSpecificInfo ) 490 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description PeerSTAAddress MacAddress Any valid individual MacAddress Specifies the address of the peer MAC entity to which query is transmitted. DialogToken Integer 0â€“255 The dialog token to identify the GAS transaction. ResultCode Enumeration SUCCESS, Indicates the result response NO_OUTSTANDING_GAS_REQUEST, to the GAS request from the GAS_ADVERTISEMENT_PROTOCOL_ peer MAC entity. NOT_SUPPORTED, GAS_QUERY_RESPONSE_ OUTSTANDING, GAS_QUERY_RESPONSE_TOO_LARGE , SERVER_UNREACHABLE, GAS_QUERY_TIMEOUT, GAS_RESPONSE_NOT_RECEIVED_ FROM_SERVER ResponseInfo String N/A Query Response string formatted using protocol identified in AdvertisementProtocolID. E.g., if the AdvertisementProtocolID value is 1, then Query is formatted as defined in IEEE Std 802.21-2008. Protected Boolean true, false Specifies whether the response was received in a robust Management frame. If true, the response was received using a Protected Dual of Public Action frame. Otherwise, the response was received using a Public Action frame. Multi-band Multi-band As defined in 9.4.2.138 Specifies the frequency band element and channel number to which the GAS transaction applies. The parameter is absent if the GAS transaction applies to the same frequency band and channel where the frame is transmitted. VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements. elements The mapping of Status Code received in the GAS Response frame is mapped to the corresponding Result Code in Table 9-46. 6.3.73.3.3 When generated This primitive is generated by the MLME as a response to the MLME-GAS.request primitive indicating the result of that request. The primitive is generated when the requesting STA receives a query response in a (Protected) GAS Initial Response frame or one or more (Protected) GAS Comeback Response frames. 491 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.73.3.4 Effect of receipt The STA operates according to the procedures defined in 11.25.3. 6.3.73.4 MLME-GAS.indication 6.3.73.4.1 Function This primitive reports to the STAâ€™s SME about the GAS Request. 6.3.73.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-GAS.indication( PeerSTAAddress, DialogToken, AdvertisementProtocolID, Query, Protected, Multi-band, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MacAddress Any valid Specifies the address of the peer MAC entity individual MAC from which the query message was received. address DialogToken Integer 0â€“255 The dialog token to identify the GAS transaction. AdvertisementProt Integer or As defined in This contains an Advertisement Protocol ID (see ocolID Sequence of Table 9-215 9.4.2.93), which might be IEEE 802.11 assigned integers or vendor specified. Query String N/A Query string formatted using protocol identified in AdvertisementProtocolID. E.g., if the AdvertisementProtocolID value is 1, then Query is formatted as defined in IEEE Std 802.21-2008. Protected Boolean true, false Specifies whether the request was received in a robust Management frame. If true, the request was received in a Protected Dual of Public Action frame. Otherwise, the request was received in a Public Action frame. Multi-band Multi-band As defined in Specifies the frequency band and channel number element 9.4.2.138 to which the GAS transaction applies. The parameter is absent if the GAS transaction applies to the same frequency band and channel where the frame is transmitted. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 492 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.73.4.3 When generated This primitive is generated by the MLME as a result of receipt of a GAS request from STA. 6.3.73.4.4 Effect of receipt The SME is notified of the request from the STA. The SME operates according to the procedures defined in 11.25.3. The SME generates an MLME-GAS.response primitive within a dot11GASResponseTimeout. 6.3.73.5 MLME-GAS.response 6.3.73.5.1 Function This primitive responds to the request for an advertisement service by a specified STA MAC entity. 6.3.73.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-GAS.response( PeerSTAAddress, DialogToken, ResultCode, ResponseInfo, Protected, Multi-band, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MacAddress Any valid individual MAC address Specifies the address of the peer MAC entity to which query response information is transmitted. DialogToken Integer 0â€“255 The dialog token to identify the GAS transaction. ResultCode Enumeration SUCCESS, Indicates the result response NO_OUTSTANDING_GAS_REQUEST, to the GAS-request from the GAS_ADVERTISEMENT_PROTOCOL_ peer MAC entity. See NOT_SUPPORTED, Table 9-46. GAS_QUERY_RESPONSE_ OUTSTANDING, GAS_QUERY_RESPONSE_TOO_LARGE, SERVER_UNREACHABLE, GAS_QUERY_TIMEOUT, GAS_RESPONSE_NOT_RECEIVED_ FROM_SERVER 493 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description ResponseInfo String N/A Query Response string formatted using protocol identified in AdvertisementProtocolID. E.g., if the AdvertisementProtocolID value is 1, then Query is formatted as defined in IEEE Std 802.21-2008. Protected Boolean true, false Specifies whether the response is sent using a robust Management frame. If true, the response is sent using a Protected Dual of Public Action frame. Otherwise, the response is sent using a Public Action frame. Multi-band Multi-band As defined in 9.4.2.138 Specifies the frequency element band and channel number where the GAS transaction applies. The parameter is absent if the GAS transaction applies to the same frequency band and channel where the frame is transmitted. VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements. elements 6.3.73.5.3 When generated This primitive is generated by the MLME as a result of an MLME-GAS.indication primitive. 6.3.73.5.4 Effect of receipt This primitive causes the MAC entity at the STA to send a (Protected) GAS Initial Response frame to the requesting STA and optionally one or more (Protected) GAS Comeback Response frames. 6.3.74 QoS Map element management 6.3.74.1 General The QoS Map element is provided to non-AP STAs in (Re)Association Response frames. However, if the SME of an AP detects a change of the QoS Map information while one or more non-AP STAs are associated to the BSS, then the AP may transmit an unsolicited QoS Map element to associated STAs. The APâ€™s SME invokes the MLME-QOS-MAP.request primitive to cause individually addressed frames containing a QoS Map element to be transmitted to associated STAs. The APâ€™s SME invokes the MLME-QOS-MAP.request primitive to transmit individually addressed frames containing a QoS Map element to associated STAs. When a non-AP STA receives such unsolicited QoS Map information, its MLME generates an MLME- QOS-MAP.indication primitive to the STAâ€™s SME. In turn, the SME should take appropriate action, e.g., initiate an ADDTS or DELTS if admission control changes are necessary. 494 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.74.2 MLME-QOS-MAP.request 6.3.74.2.1 Function This primitive is used by an AP to transmit an unsolicited QoS Map Configure frame to a specified non-AP STA MAC entity. The specified non-AP STA MAC address is an individual MAC address. 6.3.74.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-QOS-MAP.request( Non-APSTAAddress, QoSMapSet, IntraAccessCategoryPriority, VendorSpecificInfo ) Name Type Valid range Description Non- MacAddress Any valid Specifies the address of the peer MAC entity APSTAAddress individual MAC from which query message is received. address QoSMapSet As defined in As defined in Specifies the QoS Map information the non-AP frame format 9.4.2.95 STA should use. IntraAccessCategor Intra-Access As defined in Specifies the intra-AC priorities the STA should yPriority Category Priority 9.4.2.121 use. The parameter is present if element dot11SCSActivated is true; otherwise not present. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.74.2.3 When generated This primitive is generated by the MLME at the AP as a result of any change in the AP QoS Map configurations. 6.3.74.2.4 Effect of receipt This primitive causes the MAC entity at the AP to send a QoS Map element in a QoS Map Configure frame to the non-AP STA. 6.3.74.3 MLME-QOS-MAP.indication 6.3.74.3.1 Function This primitive reports the QoS mapping information sent from the AP to the non-AP STA. 6.3.74.3.2 Semantics of the service primitive The primitive parameter is as follows: MLME-QOS-MAP.indication( QoSMapSet, IntraAccessCategoryPriority, VendorSpecificInfo ) 495 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description QoSMapSet As defined in As defined in Specifies the QoS Map information to be used by frame format 9.4.2.95 the non-AP STA. IntraAccessCatego Intra-Access As defined in Specifies the intra-AC priorities the STA should ryPriority Category Priority 9.4.2.121 use. element VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.74.3.3 When generated This primitive is generated when the non-AP STA receives a QoS Map element in an unsolicited QoS Map Configure frame from the AP. The SME of the non-AP STA should use the information to decide proper actions. For example, an ADDTS or DELTS procedure should be activated if the QoS Map information indicates a change in the admission control. 6.3.74.3.4 Effect of receipt The non-AP STA operates according to the procedures defined in 11.25.9. 6.3.75 Mesh peering management 6.3.75.1 Introduction The following primitives facilitate the mesh peering management protocol and authenticated mesh peering exchange protocol. 6.3.75.2 MLME-MESHPEERINGMANAGEMENT.request 6.3.75.2.1 Function This primitive requests that the MAC entity establish, confirm, or close a mesh peering with the specified peer MAC entity by sending a mesh peering Management frame to the peer MAC entity. The mesh peering management procedures are specified in 14.3. 6.3.75.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-MESHPEERINGMANAGEMENT.request( PeerMACAddress, MeshPeeringMgmtFrameContent, VendorSpecificInfo ) 496 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description PeerMACAddress MAC Address Valid individual MAC Specifies the address of the peer MAC address entity to which the Mesh Peering Management frame is to be sent. MeshPeeringMgmtFra Sequence of As defined in 9.6.16.2, The contents of the Action field of the meContent octets 9.6.16.3, or 9.6.16.4 Mesh Peering Open, Mesh Peering Confirm, or Mesh Peering Close frame to send to the peer MAC entity. VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements. elements 6.3.75.2.3 When generated This primitive is generated by the SME to request that a mesh peering Management frame be sent to the specified mesh STA. 6.3.75.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a mesh peering Management frame containing the information specified. The frame is scheduled for transmission. 6.3.75.3 MLME-MESHPEERINGMANAGEMENT.confirm 6.3.75.3.1 Function This primitive reports the results of a request to send a mesh peering Management frame. 6.3.75.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-MESHPEERINGMANAGEMENT.confirm( PeerMACAddress, MeshPeeringMgmtFrameContent, VendorSpecificInfo ) Name Type Valid range Description PeerMACA MAC Address Valid individual MAC address Specifies the address of the peer MAC ddress entity to which the Mesh Peering Management frame was sent. MeshPeerin Sequence of As defined in 9.6.16.2, The contents of the Action field of the Mesh gMgmtFram octets 9.6.16.3, or 9.6.16.4 Peering Open, Mesh Peering Confirm, or eContent Mesh Peering Close frame received from the peer MAC entity. VendorSpec A set of As defined in 9.4.2.26 Zero or more elements. ificInfo elements 6.3.75.3.3 When generated This primitive is generated as a result of an MLME-MESHPEERINGMANAGEMENT.request primitive with a specified MAC peer. 497 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.75.3.4 Effect of receipt The SME is notified of the results of the mesh peering management protocol request. 6.3.75.4 MLME-MESHPEERINGMANAGEMENT.indication 6.3.75.4.1 Function This primitive indicates to the SME that the MLME has received a mesh peering Management frame from a peer MAC entity. 6.3.75.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-MESHPEERINGMANAGEMENT.indication( PeerMACAddress, MeshPeeringMgmtFrameContent, VendorSpecificInfo ) Name Type Valid range Description PeerMACAddress MAC Address Valid individual MAC Specifies the address of the peer MAC address entity from which the Mesh Peering Management frame was received. MeshPeeringMgm Sequence of As defined in 9.6.16.2, The contents of the Action field of the tFrameContent octets 9.6.16.3, or 9.6.16.4 Mesh Peering Open, Mesh Peering Confirm, or Mesh Peering Close frame received from the peer MAC entity. VendorSpecificInf A set of As defined in 9.4.2.26 Zero or more elements. o elements 6.3.75.4.3 When generated This primitive is generated by the MLME as a result of the receipt of a mesh peering Management frame from a peer MAC entity. 6.3.75.4.4 Effect of receipt The SME is notified of the reception of a mesh peering Management frame and is provided the contents of the frame. 6.3.75.5 MLME-MESHPEERINGMANAGEMENT.response 6.3.75.5.1 Function This primitive is used to send a response to a mesh peering Management frame to the specified peer MAC entity. 6.3.75.5.2 Semantics of the service primitive The primitive parameters are as follows: 498 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MLME-MESHPEERINGMANAGEMENT.response( PeerMACAddress, ResultCode, MeshPeeringMgmtFrameContent, VendorSpecificInfo ) Name Type Valid range Description PeerMACA MAC Address Valid individual MAC address Specifies the address of the peer MAC ddress entity to which the Mesh Peering Management frame is to be sent. ResultCode Enumeration SUCCESS, Reports the result response to the mesh INVALID_PARAMETERS peering Management frame from the peer MAC entity. MeshPeerin Sequence of As defined in 9.6.16.2, The contents of the Action field of the Mesh gMgmtFram octets 9.6.16.3, or 9.6.16.4 Peering Open, Mesh Peering Confirm, or eContent Mesh Peering Close frame to send to the peer MAC entity. VendorSpec A set of As defined in 9.4.2.26 Zero or more elements. ificInfo elements 6.3.75.5.3 When generated This primitive is generated by the SME as a response to an MLME- MESHPEERINGMANAGEMENT.indication primitive. 6.3.75.5.4 Effect of receipt This primitive indicates scheduling for transmission of a Mesh Peering frame containing the indicated response. 6.3.76 Mesh power management 6.3.76.1 Introduction The following primitives describe how a mesh entity changes its mesh power management mode for a mesh peering. 6.3.76.2 MLME-MESHPOWERMGT.request 6.3.76.2.1 Function This primitive requests a change in the mesh STAs mesh power management mode for the mesh peering. 6.3.76.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-MESHPOWERMGT.request( PeerMACAddress, Mesh Power Management Mode ) 499 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid Range Description PeerMACAd- MAC Valid individual MAC Specifies the address of the peer MAC entity to dress Address address which the mesh power management mode is changed. Mesh Power Enumeration ACTIVE_MODE, Specifies the mesh power management mode that Management LIGHT_SLEEP_MODE, the local mesh STA is using for the mesh peering. Mode DEEP_SLEEP_MODE 6.3.76.2.3 When generated The primitive is generated when the mesh entity wishes to change the mesh power management mode of a mesh peering. 6.3.76.2.4 Effect of receipt This primitive initiates the local mesh STAâ€™s mesh power management mode change of the mesh peering. The MLME subsequently issues an MLME-MESHPOWERMGT.confirm primitive that reflects the results. 6.3.76.3 MLME-MESHPOWERMGT.confirm 6.3.76.3.1 Function This primitive reports the result of a mesh power management mode change attempt. 6.3.76.3.2 Semantics of the service primitive The primitive parameter is as follows: MLME-MESHPOWERMGT.confirm( PeerMACAddress ) Name Type Valid Range Description PeerMAC MAC Valid individual MAC Specifies the address of the peer MAC entity Address Address address to which the mesh power management mode is changed. 6.3.76.3.3 When generated This primitive is generated as a result of an MLME-MESHPOWERMGT.request primitive. 6.3.76.3.4 Effect of receipt The SME is notified of the results of the mesh power management mode change for a mesh peering procedure. 6.3.77 Mesh neighbor offset synchronization 6.3.77.1 Introduction This mechanism manages the neighbor offset synchronization method with the specified neighbor STA. 500 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.77.2 MLME-MESHNEIGHBOROFFSETSYNCSTART.request 6.3.77.2.1 Function This primitive requests to start the neighbor offset synchronization method with the specified neighbor STA. 6.3.77.2.2 Semantics of the service primitive The primitive parameter is as follows: MLME-MESHNEIGHBOROFFSETSYNCSTART.request( PeerMACAddress ) Name Type Valid range Description PeerMACAddress MAC Address Any valid Specifies the address of the peer MAC entity individual with which to start the neighbor offset MAC address synchronization method. 6.3.77.2.3 When generated This primitive is generated by the SME to start the neighbor offset synchronization method with the specified neighbor STA. 6.3.77.2.4 Effect of receipt On receipt of this primitive, the MLME commences the neighbor offset synchronization method and the calculation of the TSF timer offset value. The MLME subsequently issues an MLME- MESHNEIGHBOROFFSETSYNCSTART.confirm primitive that reflects the results of this request. 6.3.77.3 MLME-MESHNEIGHBOROFFSETSYNCSTART.confirm 6.3.77.3.1 Function This primitive reports the results of a mesh neighbor offset synchronization request. 6.3.77.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-MESHNEIGHBOROFFSETSYNCSTART.confirm( PeerMACAddress, TSFOffsetValue ) Name Type Valid range Description PeerMACAddress MAC Address Valid individual MAC address Specifies the address of the peer MAC entity to which the neighbor offset synchronization is requested. TSFOffsetValue Integer â€“263 to (263â€“1) Indicates the TSF offset value with the specified neighbor STA, expressed in 2s complement in Âµs. 501 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.77.3.3 When generated This primitive is generated by the MLME as a result of an MLME- MESHNEIGHBOROFFSETSYNCSTART.request primitive and report the TSF offset value. 6.3.77.3.4 Effect of receipt The SME is notified of the results of the mesh neighbor offset synchronization request. 6.3.77.4 MLME-MESHNEIGHBOROFFSETCALCULATE.request 6.3.77.4.1 Function This primitive requests a calculation result of the TSF timer offset value for the specified neighbor STA. 6.3.77.4.2 Semantics of the service primitive The primitive parameter is as follows: MLME-MESHNEIGHBOROFFSETCALCULATE.request( PeerMACAddress ) Name Type Valid range Description PeerMACAddress MAC Address Any valid Specifies the address of the peer MAC entity individual with which to report the TSF offset value. MAC address 6.3.77.4.3 When generated This primitive is generated by the SME to order a calculation of the TSF timer offset value with the specified neighbor STA. 6.3.77.4.4 Effect of receipt On receipt of this primitive, the MLME receives a Beacon or Probe Response frame and calculates the TSF timer offset value from the received frame. The MLME tries to receive a Beacon frame immediately after the issue of MLME-MESHNEIGHBOROFFSETCALCULATE.request primitive even if the mesh STA does not listen to the Beacon frame from the specified neighbor STA regularly (i.e., in deep sleep mode toward the specified neighbor STA). The MLME subsequently issues an MLME- MESHNEIGHBOROFFSETCALCULATE.confirm primitive that reflects the results of this request. 6.3.77.5 MLME-MESHNEIGHBOROFFSETCALCULATE.confirm 6.3.77.5.1 Function This primitive reports the results of a mesh neighbor offset calculation request. 6.3.77.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-MESHNEIGHBOROFFSETCALCULATE.confirm( PeerMACAddress, TSFOffsetValue ) 502 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description PeerMACAddress MAC Address Valid individual MAC address Specifies the address of the peer MAC entity to which the Neighbor Offset Measure is requested. TSFOffsetValue Integer â€“263 to (263â€“1) Indicates the TSF offset value with the specified neighbor STA, expressed in 2s complement in Âµs. 6.3.77.5.3 When generated This primitive is generated by the MLME as a result of an MLME- MESHNEIGHBOROFFSETCALCULATE.request primitive to report a TSF offset value. 6.3.77.5.4 Effect of receipt The SME is notified of the results of the mesh neighbor offset calculation request. 6.3.77.6 MLME-MESHNEIGHBOROFFSETSYNCSTOP.request 6.3.77.6.1 Function This primitive requests to stop the neighbor offset synchronization method with the specified neighbor STA. 6.3.77.6.2 Semantics of the service primitive The primitive parameter is as follows: MLME-MESHNEIGHBOROFFSETSYNCSTOP.request( PeerMACAddress ) Name Type Valid range Description PeerMACAddress MAC Address Any valid Specifies the address of the peer MAC entity individual with which to stop the neighbor offset MAC address synchronization method. 6.3.77.6.3 When generated This primitive is generated by the SME to stop the maintenance of the neighbor offset synchronization method with the specified neighbor STA. 6.3.77.6.4 Effect of receipt On receipt of this primitive, the MLME stops the neighbor offset synchronization method with the specified peer. The MLME subsequently issues an MLME-MESHNEIGHBOROFFSETSYNCSTOP.confirm primitive that reflects the results of this request. 6.3.77.7 MLME-MESHNEIGHBOROFFSETSYNCSTOP.confirm 6.3.77.7.1 Function This primitive reports the results of a neighbor offset synchronization method stop request. 503 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.77.7.2 Semantics of the service primitive The primitive parameter is as follows: MLME-MESHNEIGHBOROFFSETSYNCSTOP.confirm( PeerMACAddress ) Name Type Valid range Description PeerMACAddress MAC Address Valid individual MAC address Specifies the address of the peer MAC entity to which the Neighbor Offset Stop is requested. 6.3.77.7.3 When generated This primitive is generated by the MLME as a result of an MLME- MESHNEIGHBOROFFSETSYNCSTOP.request primitive. 6.3.77.7.4 Effect of receipt The SME is notified of the results of the mesh neighbor offset synchronization stop request. 6.3.78 Mesh TBTT adjustment 6.3.78.1 Introduction The following primitives describe how a mesh STA requests a TBTT adjustment from a neighboring peer mesh STA. 6.3.78.2 MLME-MESHTBTTADJUSTMENT.request 6.3.78.2.1 Function This primitive requests transmission of a TBTT Adjustment Request frame. 6.3.78.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-MESHTBTTADJUSTMENT.request( PeerMACAddress, BeaconTiming, VendorSpecificInfo ) Name Type Valid range Description PeerMACAddress MAC Address Any valid Specifies the address of the peer MAC entity individual to which the TBTT Adjustment Request is MAC address sent. BeaconTiming A set of As defined in A set of Beacon Timing elements of the mesh Beacon 9.4.2.105 STA. Timing elements VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 504 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.78.2.3 When generated This primitive is generated by the SME to request that a TBTT Adjustment Request frame be sent to a peer entity to request the adjustment of the peer entityâ€™s TBTT. 6.3.78.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a TBTT Adjustment Request frame containing the Beacon Timing elements. This frame is then scheduled for transmission. The MLME subsequently issues an MLME-MESHTBTTADJUSTMENT.confirm primitive that reflects the result of this request. 6.3.78.3 MLME-MESHTBTTADJUSTMENT.confirm 6.3.78.3.1 Function This primitive reports the result of a mesh TBTT adjustment request. 6.3.78.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-MESHTBTTADJUSTMENT.confirm( PeerMACAddress, ResultCode, BeaconTiming, VendorSpecificInfo ) Name Type Valid range Description PeerMACAddress MAC Address Any valid individual MAC Specifies the address of the peer address MAC entity from which the TBTT Adjustment Response is received. ResultCode Enumeration SUCCESS, Indicates the result of the TBTT REFUSED_REASON_ adjustment request. UNSPECIFIED, CANNOT_FIND_ ALTERNATIVE_TBTT BeaconTiming A set of As defined in 9.4.2.105 A set of Beacon Timing elements Beacon Timing of the responding mesh STA. elements Present only when such an element was present in the TBTT Adjustment Response frame. VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements. elements 6.3.78.3.3 When generated This primitive is generated by the MLME as a result of an MLME-MESHTBTTADJUSTMENT.request primitive to indicate the result of that request. 6.3.78.3.4 Effect of receipt The SME is notified of the result of the mesh TBTT adjustment request. 505 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.78.4 MLME-MESHTBTTADJUSTMENT.indication 6.3.78.4.1 Function This primitive indicates that a specific peer MAC entity is requesting adjustment of the TBTT. 6.3.78.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-MESHTBTTADJUSTMENT.indication( PeerMACAddress, BeaconTiming, VendorSpecificInfo ) Name Type Valid range Description PeerMACAddress MAC Address Any valid individual Specifies the address of the peer MAC MAC address entity from which the TBTT Adjustment request was received. BeaconTiming A set of Beacon As defined in 9.4.2.105 A set of Beacon Timing elements of the Timing elements requesting mesh STA. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.78.4.3 When generated This primitive is generated by the MLME as a result of the receipt of a TBTT Adjustment Request frame from the specified peer MAC entity. 6.3.78.4.4 Effect of receipt The SME is notified of the receipt of the TBTT adjustment request by the specified peer MAC entity. The mesh STA that received this primitive subsequently processes the TBTT scanning and adjustment procedure described in 14.13.4.4.3, and responds with the MLME-MESHTBTTADJUSTMENT.response primitive. 6.3.78.5 MLME-MESHTBTTADJUSTMENT.response 6.3.78.5.1 Function This primitive is used to send a response to the specified peer MAC entity that requested a TBTT adjustment from the mesh STA that issued this primitive. 6.3.78.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-MESHTBTTADJUSTMENT.response( PeerMACAddress, Status Code, BeaconTiming, VendorSpecificInfo ) 506 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description PeerMACAddress MAC Address Any valid individual MAC Specifies the address of the peer address MAC entity to which the TBTT Adjustment Response is sent. Status Code As defined in SUCCESS, Indicates the result response to the frame format REFUSED_REASON_ TBTT adjustment request from the UNSPECIFIED, peer mesh STA. CANNOT_FIND_ ALTERNATIVE_TBTT BeaconTiming A set of As defined in 9.4.2.105 A set of Beacon Timing elements Beacon Timing of the mesh STA. Present only elements when the STA could not find an alternative TBTT. VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements. elements 6.3.78.5.3 When generated This primitive is generated by the SME of a mesh STA as response to an MLME- MESHTBTTADJUSTMENT.indication primitive. 6.3.78.5.4 Effect of receipt This primitive initiates the transmission of a TBTT Adjustment Response frame to the peer MAC entity that requested the TBTT adjustment. On receipt of this primitive, the MLME constructs a TBTT Adjustment Response frame. This frame is then scheduled for transmission. 6.3.79 MCCA management interface 6.3.79.1 Introduction The following primitives describe how a mesh entity manages its MCCA operation. 6.3.79.2 MLME-ACTIVATEMCCA.request 6.3.79.2.1 Function This primitive requests that the MAC entity activate MCCA. 6.3.79.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-ACTIVATEMCCA.request( MCCAScanDuration, MAFLimit, MCCAAdvertPeriodMax, MCCAMaxTrackStates, MCCACWmin, MCCACWmax, MCCAAIFSN ) 507 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description MCCAScanDu Integer 0 â€“ 65 535 Specifies the duration in TUs that the mesh STA ration shall not initiate or accept MCCA Setup Request frames. MAFLimit Integer 0â€“255 Specifies the maximum MCCA access fraction allowed at the mesh STA. This number is always a multiple of (1/255) of the DTIM Interval. MCCAAdvert Integer 0â€“255 Specifies the maximum interval that a mesh STA PeriodMax with dot11MCCAActivated equal to true waits for an MCCAOP advertisement. It is expressed in number of DTIM intervals. MCCAMaxTra Integer dot11MCCAMinTrackStates Specifies the total number of MCCAOP ckStates â€“ 65 535 reservations that the MAC entity is able to track. MCCACWmin Integer 0â€“15 Specifies the value of the minimum size of the contention window that the MAC entity uses for channel access during an MCCAOP. MCCACWma Integer 0â€“63 Specifies the value of the maximum size of the x contention that the MAC entity uses for channel access during an MCCAOP. MCCAAIFSN Integer 0â€“15 Specifies the value of the AIFSN that the MAC entity uses for channel access during an MCCAOP. 6.3.79.2.3 When generated This primitive is generated by the SME to start the use of MCCA. 6.3.79.2.4 Effect of receipt This primitive sets dot11MCCAActivated to true and initializes the MCCA parameters. 6.3.79.3 MLME-MCCASETUP.request 6.3.79.3.1 Function This primitive requests that the MAC entity set up an MCCAOP reservation. 6.3.79.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-MCCASETUP.request( MCCAOPDuration, MCCAOPPeriodicity, MCCAOPOffset, MCCAOPResponder, VendorSpecificInfo ) Name Type Valid range Description MCCAOPDuration Integer 0 â€“ 65 535 Specifies the MCCAOP Duration of the needed MCCAOPs as described in 9.4.2.106.2. MCCAOPPeriodicity Integer 0â€“255 Specifies the MCCAOP Periodicity of the needed MCCAOPs as described in 9.4.2.106.2. 508 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description MCCAOPOffset Integer 0 â€“ 16 777 215 Specifies the MCCAOP offset of the needed MCCAOPs as described in 9.4.2.106.2. MCCAOPResponder MAC address Any valid Specifies the MAC address of the intended individual or MCCAOP responder. group MAC address VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.79.3.3 When generated This primitive is generated by the SME to start an MCCAOP setup procedure. 6.3.79.3.4 Effect of receipt This primitive causes the transmission of an MCCA Setup Request frame to the MCCAOP responder provided that the conditions for the transmission are met. In the case that a response is received from the responder STA, the MLME subsequently issues an MLME-MCCASETUP.confirm primitive that reflects the results. 6.3.79.4 MLME-MCCASETUP.confirm 6.3.79.4.1 Function This primitive is generated by the MLME to report the result of an MLME-MCCASETUP.request primitive, which was issued in order to establish an MCCAOP reservation with the peer MAC entity specified in MCCAOPResponder. 6.3.79.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-MCCASETUP.confirm( MCCAOPParameters, MCCAOPID, MCCAOPResponder, ResultCode, VendorSpecificInfo ) Name Type Valid range Description MCCAOPParameters MCCAOP See 9.4.2.106.2 The MCCAOP reservation Reservation parameters. MCCAOPID Integer 0â€“254 MCCAOP reservation ID of the MCCAOP reservation. MCCAOPResponder MAC address Any valid individual or group Specifies the MAC address of the MAC address intended MCCAOP responder. 509 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description ResultCode Enumeration SUCCESS, Indicates the result of the MLME- INVALID_PARAMETERS, MCCASETUP.request primitive. MCCAOP_RESERVATION_C ONFLICT, MAF_LIMIT_EXCEEDED, MCCA_TRACK_LIMIT_EX CEEDED VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements. elements 6.3.79.4.3 When generated This primitive is generated by the MLME as a result of an MLME-MCCASETUP.request primitive to establish an MCCAOP reservation with the peer mesh STA identified in MCCAOPResponder or upon receipt of an MCCA Setup Reply frame from the peer mesh STA identified in MCCAOPResponder. 6.3.79.4.4 Effect of receipt The SME is notified of the results of the MCCAOP setup procedure. 6.3.79.5 MLME-MCCASETUP.indication 6.3.79.5.1 Function This primitive indicates the receipt of an MCCA Setup Request frame from the peer MAC entity specified in MCCAOPOwner. 6.3.79.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-MCCASETUP.indication( MCCAOPParameters, MCCAOPID, MCCAOPOwner, VendorSpecificInfo ) Name Type Valid range Description MCCAOPParameters MCCAOP See 9.4.2.106.2 The MCCAOP reservation parameters. Reservation MCCAOPID Integer 0â€“254 MCCAOP reservation ID of the MCCAOP reservation. MCCAOPOwner MAC address Any valid individual Specifies the MAC address of the MAC address MCCAOP owner. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.79.5.3 When generated This primitive is generated by the MLME as result of the receipt of an MCCA Setup Request frame from the peer MAC entity specified in MCCAOPOwner. 510 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.79.5.4 Effect of receipt The SME is notified of the request to establish an MCCAOP reservation with the peer MAC entity specified in MCCAOPOwner. 6.3.79.6 MLME-MCCASETUP.response 6.3.79.6.1 Function This primitive is used to send a response to the peer MAC entity specified in MCCAOPOwner that requested the set up of the MCCAOP reservation. 6.3.79.6.2 Semantics of the service primitive The primitive parameters are as follows: MLME-MCCASETUP.response( MCCAOPParameters, MCCAOPID, MCCAOPOwner, ResultCode, VendorSpecificInfo ) Name Type Valid range Description MCCAOPParameters MCCAOP See 9.4.2.106.2 The MCCAOP reservation Reservation parameters. MCCAOPID Integer 0â€“254 MCCAOP reservation ID of the MCCAOP reservation. MCCAOPOwner MAC address Any valid individual MAC Specifies the MAC address of the address MCCAOP owner. ResultCode Enumeration SUCCESS, Indicates the result of the MLME- INVALID_PARAMETERS, MCCASETUP.request primitive. MCCAOP_RESERVATION_C ONFLICT, MAF_LIMIT_EXCEEDED, MCCA_TRACK_LIMIT_EX CEEDED VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements. elements 6.3.79.6.3 When generated This primitive is generated by the SME of a STA as a response to an MLME-MCCASETUP.indication primitive. 6.3.79.6.4 Effect of receipt This primitive initiates transmission of a response to the peer MAC entity specified in the MCCAOPOwner that requested the set up of an MCCAOP reservation. 511 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.79.7 MLME-MCCAADVERTISEMENT.request 6.3.79.7.1 Function This primitive requests that the MAC entity request an MCCAOP advertisement from the specified peer MAC entity by sending an MCCA Advertisement Request frame to the peer MAC entity. 6.3.79.7.2 Semantics of the service primitive The primitive parameters are as follows: MLME-MCCAADVERTISEMENT.request( PeerMACAddress, VendorSpecificInfo ) Name Type Valid range Description PeerMACAddress MAC address Any valid Specifies the MAC address of the peer MAC individual that sends the Advertisement. MAC address VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.79.7.3 When generated This primitive is generated by the SME to request an MCCAOP advertisement from the specified peer MAC entity. 6.3.79.7.4 Effect of receipt This primitive causes the transmission of an MCCA Advertisement Request frame to the specified peer MAC entity. In the case that a response is received from the responder STA, the MLME subsequently issues an MLME-MCCAADVERTISEMENT.confirm primitive that reflects the results. 6.3.79.8 MLME-MCCAADVERTISEMENT.confirm 6.3.79.8.1 Function This primitive reports the result of an MLME-MCCAADVERTISEMENT.request primitive. 6.3.79.8.2 Semantics of the service primitive The primitive parameters are as follows: MLME-MCCAADVERTISEMENT.confirm( MCCAOPAdvertisement, PeerMACAddress, ResultCode, VendorSpecificInfo ) 512 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description MCCAOPAdvertise MCCAOP See 9.4.2.109 One or more MCCAOP ment Advertisement Advertisement elements. PeerMACAddress MAC address Any valid individual MAC Specifies the MAC address of the address transmitter of the MCCAOP advertisement. ResultCode Enumeration SUCCESS, REFUSED Indicates the result of the MLME- MCCAADVERTISEMENT.request primitive. VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements. elements 6.3.79.8.3 When generated This primitive is generated by the MLME as a result of an MLME-MCCAADVERTISEMENT.request primitive. 6.3.79.8.4 Effect of receipt The SME is notified of the results of the MCCA Advertisement Request frame. 6.3.79.9 MLME-MCCAADVERTISEMENT.indication 6.3.79.9.1 Function This primitive reports that an MCCA Advertisement Request frame has been received from the specified peer MAC entity. 6.3.79.9.2 Semantics of the service primitive The primitive parameters are as follows: MLME-MCCAADVERTISEMENT.indication( PeerMACAddress, VendorSpecificInfo ) Name Type Valid range Description PeerMACAddress MAC address Any valid individual Specifies the MAC address of the MAC address transmitter of the MCCA Advertisement Request frame. VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements. elements 6.3.79.9.3 When generated This primitive is generated by the MLME upon receipt of an MCCA Advertisement Request frame from the specified peer MAC entity. 6.3.79.9.4 Effect of receipt The SME is notified of the request to advertise its MCCAOP reservations. 513 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.79.10 MLME-MCCAADVERTISEMENT.response 6.3.79.10.1 Function This primitive requests that the MAC entity respond to the MCCAOP advertisement request from the specified peer MAC entity by sending an MCCA Advertisement frame to the peer MAC entity. 6.3.79.10.2 Semantics of the service primitive The primitive parameters are as follows: MLME-MCCAADVERTISEMENT.response( MCCAOPAdvertisement, PeerMACAddress, ResultCode, VendorSpecificInfo ) Name Type Valid range Description MCCAOPAdvertise MCCAOP See 9.4.2.109 One or more MCCAOP ment Advertisement Advertisement elements. PeerMACAddress MAC address Any valid individual MAC Specifies the MAC address of the address transmitter of the MCCA Advertisement frame. ResultCode Enumeration SUCCESS, REFUSED Indicates the result of the MLME- MCCAADVERTISEMENT.respon se primitive. VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements. elements 6.3.79.10.3 When generated This primitive is generated by the SME of a STA as a response to an MLME- MCCAADVERTISEMENT.indication procedure. 6.3.79.10.4 Effect of receipt This primitive initiates transmission of a response to the specified peer MAC entity that requested advertisement of the MCCAOP reservations. 6.3.79.11 MLME-MCCATEARDOWN.request 6.3.79.11.1 Function This primitive requests that the MAC entity tear down an MCCAOP reservation. 6.3.79.11.2 Semantics of the service primitive The primitive parameters are as follows: MLME-MCCATEARDOWN.request( MCCAOPID, PeerMACAddress, VendorSpecificInfo ) 514 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description MCCAOPID Integer 0â€“255 Specifies the MCCAOP reservation ID of the MCCAOP reservation to be torn down. PeerMACAddress MAC address Any valid Specifies the MAC address of the peer MAC individual for the MCCAOP reservation. MAC address VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.79.11.3 When generated This primitive is generated by the SME to start an MCCAOP teardown procedure. 6.3.79.11.4 Effect of receipt This primitive causes the teardown MCCAOP reservation identified by means of the MCCAOP reservation ID in MCCAOPID, and the transmission of an MCCA Teardown frame to the peer MAC entity in Peer- MACAddress. 6.3.79.12 MLME-MCCATEARDOWN.indication 6.3.79.12.1 Function This primitive reports that an MCCA Teardown frame has been received from the specified peer MAC entity. 6.3.79.12.2 Semantics of the service primitive The primitive parameters are as follows: MLME-MCCATEARDOWN.indication( MCCAOPID, PeerMACAddress, VendorSpecificInfo ) Name Type Valid range Description MCCAOPID Integer 0â€“255 MCCAOP reservation ID of the MCCAOP reservation to be torn down. PeerMACAddress MAC address Any valid individual Specifies the MAC address of the peer MAC address MAC for the MCCAOP reservation. VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements. elements 6.3.79.12.3 When generated This primitive is generated by the MLME as result of receipt of a MCCA Teardown frame. 6.3.79.12.4 Effect of receipt The SME is notified of the request to start an MCCAOP teardown procedure. 515 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.80 MBSS congestion control 6.3.80.1 Introduction The following primitives describe how a mesh STA manages its congestion control operation. 6.3.80.2 MLME-MBSSCONGESTIONCONTROL.request 6.3.80.2.1 Function This primitive requests that the MAC entity notify the peer MAC entity on the congestion level or requests to traffic generation by transmitting a Congestion Control Notification frame to the specified peer MAC entity. 6.3.80.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME- MBSSCONGESTIONCONTROL.request( PeerMACAddress, CongestionNotification, VendorSpecificInfo ) Name Type Valid range Description PeerMACAddress MAC Address Any valid Specifies the address of the peer MAC entity individual to which the Congestion Control Notification MAC address frame is sent. CongestionNotification A set of As defined in Congestion notification information generated Congestion 9.4.2.101 by the mesh STA. Notification elements VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.80.2.3 When generated The SME generates this primitive to request that the MAC notify its peer MAC about the current congestion level. 6.3.80.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a Congestion Control Notification frame. This frame is then scheduled for transmission. 6.3.80.3 MLME-MBSSCONGESTIONCONTROL.indication 6.3.80.3.1 Function This primitive indicates that a congestion notification has been received. 6.3.80.3.2 Semantics of the service primitive The primitive parameters are as follows: 516 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MLME- MBSSCONGESTIONCONTROL.indication( PeerMACAddress, CongestionNotification, VendorSpecificInfo ) Name Type Valid range Description PeerMACAddress MAC Address Any valid individual Specifies the address of the peer MAC MAC address entity from which the Congestion Control Notification frame was received. CongestionNotification A set of As defined in 9.4.2.101 Congestion notification information Congestion contained in the received Congestion Notification Control Notification frame. elements VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements. elements 6.3.80.3.3 When generated This primitive is generated by the MLME as a result of the receipt of a Congestion Control Notification frame from a specific peer MAC entity. 6.3.80.3.4 Effect of receipt The SME is notified of the results of the receipt of the congestion control notification from the specified peer MAC entity. The mesh STA that received this primitive subsequently activates the local rate control as described in 14.12. 6.3.81 MBSS proxy update 6.3.81.1 Introduction The following primitives describe how a mesh STA reports the proxy update information to another mesh STA in the MBSS. 6.3.81.2 MLME-MBSSPROXYUPDATE.request 6.3.81.2.1 Function This primitive requests that the MAC entity inform a destination mesh STA about its proxy information by transmitting a Proxy Update frame to the specified peer MAC entity. 6.3.81.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME- MBSSPROXYUPDATE.request( PeerMACAddress, ProxyUpdate, VendorSpecificInfo ) 517 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description PeerMACAddress MAC Address Any valid Specifies the address of the peer MAC entity individual to which the Proxy Update frame is sent. MAC address ProxyUpdate A set of PXU As defined in A set of proxy information available at the elements 9.4.2.116 mesh STA. VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.81.2.3 When generated This primitive is generated by the SME to request that a Proxy Update frame be sent to the specified peer MAC entity. 6.3.81.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a Proxy Update frame containing the PXU element. This frame is then scheduled for transmission. In the case that a response is received from the responder STA, the MLME subsequently issues an MLME- MBSSPROXYUPDATE.confirm primitive that reflects the results of this request. 6.3.81.3 MLME-MBSSPROXYUPDATE.confirm 6.3.81.3.1 Function This primitive reports the results of a proxy update request. 6.3.81.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME- MBSSPROXYUPDATE.confirm( PeerMACAddress, ProxyUpdateConfirmation, VendorSpecificInfo ) Name Type Valid range Description PeerMACAddress MAC Address Any valid individual MAC Specifies the address of the peer address MAC entity from which the Proxy Update Confirmation frame is received. ProxyUpdateConfirm A set of As defined in 9.4.2.117 A set of proxy update confirmation ation PXUC information from the peer MAC elements entity to which the Proxy Update frame was sent. VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements. elements 6.3.81.3.3 When generated This primitive is generated by the MLME as a result of an MLME-MBSSPROXYUPDATE.request primitive. 518 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.81.3.4 Effect of receipt The SME is notified of the results of the MBSS proxy update request. 6.3.81.4 MLME-MBSSPROXYUPDATE.indication 6.3.81.4.1 Function This primitive indicates that an update of the proxy information has been received from a specific peer MAC entity. 6.3.81.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME- MBSSPROXYUPDATE.indication( PeerMACAddress, ProxyUpdate, VendorSpecificInfo ) Name Type Valid range Description PeerMACAddress MAC Address Any valid individual Specifies the address of the peer MAC MAC address entity from which the update of the proxy information was received. ProxyUpdate A set of As defined in 9.4.2.116 A set of proxy information received from PXU elements the peer mesh STA. VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements. elements 6.3.81.4.3 When generated This primitive is generated by the MLME as a result of the receipt of a Proxy Update frame from a specific peer MAC entity. 6.3.81.4.4 Effect of receipt The SME is notified of the results of the receipt of the proxy update request by the specified peer MAC entity. The mesh STA that received this primitive subsequently updates the proxy information as described in 14.11.4.3. 6.3.81.5 MLME-MBSSPROXYUPDATE.response 6.3.81.5.1 Function This primitive is used to send a response to a specific peer MAC entity that sent an update of the proxy information to the mesh STA that issued this primitive. 519 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.81.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME- MBSSPROXYUPDATE.response( PeerMACAddress, ProxyUpdateConfirmation, VendorSpecificInfo ) Name Type Valid range Description PeerMACAddress MAC Address Any valid individual MAC Specifies the address of the peer address MAC entity to which the Proxy Update Confirmation frame is sent. ProxyUpdateConfirm A set of As defined in 9.4.2.117 A set of proxy update confirmation ation PXUC information to be sent to the peer elements MAC entity. VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements. elements 6.3.81.5.3 When generated This primitive is generated by the SME of a STA as a response to an MLME- MBSSPROXYUPDATE.indication primitive. 6.3.81.5.4 Effect of receipt This primitive initiates transmission of a response to the specific peer MAC entity that sent an update of the proxy information. On receipt of this primitive, the MLME constructs a Proxy Update Confirmation frame. The frame contains one or more PXUC elements. This frame is then scheduled for transmission. 6.3.82 MBSS mesh gate announcement 6.3.82.1 Introduction The following primitives describe how a mesh STA announces mesh gate reachability. 6.3.82.2 MLME-MBSSGATEANNOUNCEMENT.request 6.3.82.2.1 Function This primitive requests that the MAC entity update the mesh gate information by transmitting a Gate Announcement frame to the specified MAC entity. 6.3.82.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME- MBSSGATEANNOUNCEMENT.request( PeerMACAddress, GateAnnouncement, VendorSpecificInfo ) 520 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description PeerMACAddress MAC Address Any valid Specifies the address of the MAC entity to group MAC which the Gate announcement frame is sent. address GateAnnouncement GANN As defined in A set of gate announcement information to be element 9.4.2.111 sent through a Gate Announcement frame. VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 6.3.82.2.3 When generated This primitive is generated by the SME to request that a Gate Announcement frame be sent to the specified MAC entity. 6.3.82.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a Gate Announcement frame containing the GANN element. This frame is then scheduled for transmission following the interval specified by dot11MeshGateAnnouncementInterval. 6.3.82.3 MLME-MBSSGATEANNOUNCEMENT.indication 6.3.82.3.1 Function This primitive indicates that a mesh gate announcement has been received from the specific peer MAC entity. 6.3.82.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME- MBSSGATEANNOUNCEMENT.indication( PeerMACAddress, GateAnnouncement, VendorSpecificInfo ) Name Type Valid range Description PeerMACAddress MAC Address Any valid individual Specifies the address of the peer MAC MAC address entity from which the gate announcement was received. GateAnnouncement GANN As defined in 9.4.2.111 A set of gate announcement information element contained in the received Gate Announcement frame. VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements. elements 6.3.82.3.3 When generated This primitive is generated by the MLME as a result of the receipt of a Gate Announcement frame from a specific peer MAC entity. 521 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.82.3.4 Effect of receipt The SME is notified of the reachability to a mesh gate in the mesh BSS. The mesh STA received this primitive subsequently triggers an MBSSGATEANNOUNCEMENT.request primitive as described in 14.11.2. 6.3.83 Mesh link metric 6.3.83.1 Introduction Subclause 6.3.83 describes the management procedures associated with mesh link metric reporting. 6.3.83.2 MLME-MESHLINKMETRICREAD.request 6.3.83.2.1 Function This primitive requests to read a link metric value between the local MAC entity and a specific peer MAC entity. 6.3.83.2.2 Semantics of the service primitive The primitive parameter is as follows: MLME-MESHLINKMETRICREAD.request( PeerMACAddress ) Name Type Valid range Description PeerMACAddress MAC Address Any valid Specifies the address of the peer MAC entity individual for which the link metric value is read MAC address 6.3.83.2.3 When generated This primitive is generated by the SME to read the link metric value for the mesh link to the specified peer MAC entity. 6.3.83.2.4 Effect of receipt On receipt of this primitive, the MLME reports the link metric value. The MLME subsequently issues an MLME-MESHLINKMETRICREAD.confirm primitive that reflects the results of this request. 6.3.83.3 MLME-MESHLINKMETRICREAD.confirm 6.3.83.3.1 Function This primitive reports the results of a link metric read request. 6.3.83.3.2 Semantics of the service primitive The primitive parameters are as follows: 522 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MLME- MESHLINKMETRICREAD.confirm( LinkMetricValue, VendorSpecificInfo ) Name Type Valid range Description LinkMetricValue Mesh Link As defined in 9.4.2.100 The link metric value for the mesh Metric Report link to the specified peer MAC element entity. VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements. elements 6.3.83.3.3 When generated This primitive is generated by the MLME as a result of an MLME-MESHLINKMETRICREAD.request primitive to request a link metric value. 6.3.83.3.4 Effect of receipt The SME is notified of the results of the link metric read request. 6.3.83.4 MLME-MESHLINKMETRICREPORT.request 6.3.83.4.1 Function This primitive requests that the MAC entity either transmit a link metric to or request a link metric from the specified peer MAC entity. 6.3.83.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-MESHLINKMETRICREPORT.request( PeerMACAddress, LinkMetricRequestFlag, MeshLinkMetricReport, VendorSpecificInfo ) Name Type Valid range Description PeerMACAddress MAC Address Any valid Specifies the address of the peer MAC entity individual to which the Mesh Link Metric Report is sent. MAC address LinkMetricRequestFlag Enumeration REPORT_ON Indicates whether the mesh STA requests a LY, link metric report from the peer MAC entity. REPORT_AN D_REQUEST MeshLinkMetricReport Mesh Link As defined in A metric value computed for the Metric Report 9.4.2.100 corresponding link. element VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 523 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.83.4.3 When generated This primitive is generated by the SME to request that a Mesh Link Metric Report frame be sent to a peer MAC entity in order to report a link metric value and to request a mesh link metric report from the peer MAC entity if LinkMetricRequestFlag is equal to REPORT_AND_REQUEST. 6.3.83.4.4 Effect of receipt On receipt of this primitive, the MLME constructs a Mesh Link Metric Report frame.The Request subfield in the Flags field of the Mesh Link Metric Report element is set depending on the parameter given by the LinkMetricRequestFlag. If LinkMetricRequestFlag is equal to REPORT_ONLY, the Request subfield is set to 0. If LinkMetricRequestFlag is equal to REPORT_AND_REQUEST, the Request subfield is set to 1. This frame is then scheduled for transmission. 6.3.83.5 MLME-MESHLINKMETRICREPORT.indication 6.3.83.5.1 Function This primitive indicates that a Mesh Link Metric Report frame has been received from a peer MAC entity. This Mesh Link Metric Request Report can be in response to an earlier MLME- MESHLINKMETRICREPORT.request primitive with LinkMetricRequestFlag equal to REPORT_AND_REQUEST. 6.3.83.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME- MESHLINKMETRICREPORT.indication( PeerMACAddress, LinkMetricRequestFlag, MeshLinkMetricReport, VendorSpecificInfo ) Name Type Valid range Description PeerMACAddress MAC Address Any valid individual Specifies the address of the peer MAC MAC address entity from which the Mesh Link Metric Report frame was received. LinkMetricRequestFlag Enumeration REPORT_ONLY, Indicates whether the peer MAC entity REPORT_AND_ requests a link metric report. REQUEST MeshLinkMetricReport Mesh Link As defined in 9.4.2.100 A metric value reported from the Metric Report specified peer MAC entity. element VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements. elements 6.3.83.5.3 When generated This primitive is generated by the MLME as a result of the receipt of a Mesh Link Metric Report frame from a specific peer MAC entity. 524 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.83.5.4 Effect of receipt The SME is notified of the receipt of the link metric report from the specified peer MAC entity. When LinkMetricRequestFlag is equal to REPORT_AND_REQUEST, the mesh STA responds with a Mesh Link Metric Report frame. 6.3.84 HWMP mesh path selection 6.3.84.1 Introduction The following primitives describe how a mesh STA establishes and maintains a mesh path to a specified peer MAC entity. 6.3.84.2 MLME-HWMPMESHPATHSELECTION.request 6.3.84.2.1 Function This primitive requests that the MAC entity establish or maintain a mesh path to the specified peer MAC entity by transmitting an HWMP Mesh Path Selection frame to the specified peer MAC entity. 6.3.84.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-HWMPMESHPATHSELECTION.request( PeerMACAddress, RootAnnouncement, PathRequest, PathReply, PathError, VendorSpecificInfo ) Name Type Valid range Description PeerMACAddress MAC Address Any valid Specifies the address of the peer MAC entity individual or to which the HWMP Mesh Path Selection group MAC frame is sent. address RootAnnouncement RANN As defined in A set of RANN elements generated by the element 9.4.2.112 mesh STA. Present if the mesh STA is configured as a root mesh STA using the proactive RANN mechanism [dot11MeshHWMProotMode = rann (4)], and as described in 14.10.12; otherwise not present. PathRequest PREQ As defined in A set of PREQ elements generated by the element 9.4.2.113 mesh STA. Present as described in 14.10.9. PathReply PREP As defined in A set of PREP elements generated by the mesh element 9.4.2.114 STA. Present as described in 14.10.10. PathError PERR As defined in A set of PERR elements generated by the element 9.4.2.115 mesh STA. Present as described in 14.10.11. VendorSpecificInfo A set of As defined in Zero or more elements. elements 9.4.2.26 525 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.84.2.3 When generated This primitive is generated by the SME to request that an HWMP Mesh Path Selection frame be sent to a specified peer entity. 6.3.84.2.4 Effect of receipt On receipt of this primitive, the MLME constructs an HWMP Mesh Path Selection frame. This frame is then scheduled for transmission. 6.3.84.3 MLME-HWMPMESHPATHSELECTION.indication 6.3.84.3.1 Function This primitive indicates that an HWMP Mesh Path Selection frame has been received from the specified peer MAC entity. 6.3.84.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-HWMPMESHPATHSELECTION.indication( PeerMACAddress, RootAnnouncement, PathRequest, PathReply, PathError, VendorSpecificInfo ) Name Type Valid range Description PeerMACAddress MAC Address Any valid individual Specifies the address of the peer MAC MAC address entity from which the HWMP Mesh Path Selection frame was received. RootAnnouncement RANN As defined in 9.4.2.112 A set of RANN elements contained in the element received frame. Present only when such an element was present in the received frame. PathRequest PREQ As defined in 9.4.2.113 A set of PREQ elements contained in the element received frame. Present only when such an element was present in the received frame. PathReply PREP As defined in 9.4.2.114 A set of PREP elements contained in the element received frame. Present only when such an element was present in the received frame. PathError PERR As defined in 9.4.2.115 A set of PERR elements contained in the element received frame. Present only when such an element was present in the received frame. VendorSpecificInfo A set of As defined in 9.4.2.26 Zero or more elements. elements 526 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.84.3.3 When generated This primitive is generated by the MLME as a result of the receipt of an HWMP Mesh Path Selection frame from a specific peer MAC entity. 6.3.84.3.4 Effect of receipt The SME is notified of the results of the receipt of the HWMP Mesh Path Selection from the specified peer MAC entity. The mesh STA received this primitive subsequently activates path selection procedures described in 14.10. 6.3.85 QMF policy 6.3.85.1 Introduction The following MLME primitives support the signaling of QMF policy. 6.3.85.2 MLME-QMFPOLICY.request 6.3.85.2.1 Function This primitive requests the transmission of an unsolicited QMF Policy frame to a peer entity. 6.3.85.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-QMFPOLICY.request ( Peer STA Address, QMFPolicy, VendorSpecificInfo ) Name Type Valid range Description Peer STA MAC Address Any valid individual The address of the peer MAC entity to which the Address MAC Address QMF policy is sent. QMFPolicy QMF Policy As defined in This parameter describes the QMF policy the peer element 9.4.2.120 STA is required to use. VendorSpeci A set of As defined in 9.4.2.26 Zero or more elements. ficInfo elements 6.3.85.2.3 When generated This primitive is generated by the SME to request that a QMF Policy frame be sent to a peer entity to communicate QMF policy information. 6.3.85.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a QMF Policy frame. This frame is then scheduled for transmission. 527 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.85.3 MLME-QMFPOLICY.indication 6.3.85.3.1 Function This primitive indicates that an unsolicited QMF Policy frame has been received from a peer entity. 6.3.85.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-QMFPOLICY.indication ( Peer STA Address, QMFPolicy, VendorSpecificInfo ) Name Type Valid range Description Peer STA MAC Address Any valid individual The address of the peer MAC from which the QMF Address MAC Address policy was received. QMFPolicy QMF Policy As defined in This parameter describes the QMF policy the peer element 9.4.2.120 STA is requiring to be used. VendorSpeci A set of As defined in 9.4.2.26 Zero or more elements. ficInfo elements 6.3.85.3.3 When generated This primitive is generated by the MLME when a valid QMF Policy frame with dialog token equal to 0 is received from a peer entity. 6.3.85.3.4 Effect of receipt The SME is notified of the receipt of a QMF policy. 6.3.85.4 MLME-QMFPOLICYCHANGE.request 6.3.85.4.1 Function This primitive supports the change of QMF Policy between peer STAs. The SME requests the transmission of a QMF Policy Change frame in order to request a change in the QMF policy the STA uses to transmit to the peer STA. 6.3.85.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-QMFPOLICYCHANGE.request ( Peer STA Address, Dialog Token, QMFPolicy, VendorSpecificInfo ) 528 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description Peer STA MAC Address Any valid individual The address of the peer MAC entity to which the Address MAC Address QMF policy change request is sent. Dialog Integer 1â€“255 The dialog token to identify the QMF policy Token change transaction. QMFPolicy QMF Policy As defined in This parameters describes the QMF policy the STA element 9.4.2.120 is requesting to use. VendorSpeci A set of As defined in 9.4.2.26 Zero or more elements. ficInfo elements 6.3.85.4.3 When generated This primitive is generated by the SME when a STA wishes to request a change of the QMF policy it uses to transmit Management frames to a peer entity. 6.3.85.4.4 Effect of receipt On receipt of this primitive, the MLME constructs a QMF Policy Change frame containing the set of QMF policy parameters. This frame is then scheduled for transmission. 6.3.85.5 MLME-QMFPOLICYCHANGE.confirm 6.3.85.5.1 Function This primitive reports the results of a policy change attempt with a peer QMF STA. 6.3.85.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-QMFPOLICYCHANGE.confirm ( Peer STA Address, Dialog Token, Result Code, VendorSpecificInfo ) Name Type Valid range Description Peer STA MAC Address Any valid individual The address of the peer MAC entity from which the Address MAC Address QMF policy was received. Dialog Integer 1â€“255 The dialog token to identify the QMF policy Token change transaction. Result Code Enumeration SUCCESS, Reports the receipt of a QMF Policy frame and the REJECT result of the QMF policy change at the peer SME or if no matching response is received within dot11QMFPolicyChangeTimeout TU. VendorSpeci A set of As defined in 9.4.2.26 Zero or more elements. ficInfo elements 529 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.85.5.3 When generated This primitive is generated by the MLME as a result of receipt of a QMF Policy frame with a dialog token that matches the dialog token from the MLME-QMFPOLICYCHANGE.request primitive. 6.3.85.5.4 Effect of receipt The SME is notified of the results of the QMF policy change procedure. 6.3.85.6 MLME-QMFPOLICYCHANGE.indication 6.3.85.6.1 Function This primitive indicates that a QMF Policy Change frame has been received from a peer entity. 6.3.85.6.2 Semantics of the service primitive The primitive parameters are as follows: MLME-QMFPOLICYCHANGE.indication ( Peer STA Address, Dialog Token, QMFPolicy, VendorSpecificInfo ) Name Type Valid range Description Peer STA MAC Address Any valid individual The address of the peer MAC entity from which the Address MAC Address QMF policy change request was received. Dialog Integer 1â€“255 The dialog token to identify the QMF policy Token change transaction. QMFPolicy QMF Policy As defined in This parameter describes the QMF policy the peer element 9.4.2.120 STA is requesting to use. VendorSpeci A set of As defined in 9.4.2.26 Zero or more elements. ficInfo elements 6.3.85.6.3 When generated This primitive is generated by the MLME when a valid QMF Policy Change frame is received from a peer entity. 6.3.85.6.4 Effect of receipt On receipt of this primitive, the parameters of the QMF Policy Change frame are provided to the SME to be processed. 6.3.85.7 MLME-QMFPOLICYCHANGE.response 6.3.85.7.1 Function This primitive requests the transmission of a QMF Policy frame with no QMF Policy field to a peer entity, in response to a received QMF Policy Change frame. 530 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.85.7.2 Semantics of the service primitive The primitive parameters are as follows: MLME-QMFPOLICYCHANGE.response ( Peer STA Address, Dialog Token, Result Code, VendorSpecificInfo ) Name Type Valid range Description Peer STA MAC Address Any valid individual The address of the peer MAC entity to which the Address MAC Address QMF Policy frame is sent in response to a QMF policy change request. Dialog Integer 1â€“255 The dialog token identifying the QMF policy Token change transaction. Result Code Enumeration SUCCESS, Reports the outcome of the transaction. REJECT VendorSpeci A set of As defined in 9.4.2.26 Zero or more elements. ficInfo elements 6.3.85.7.3 When generated This primitive is generated by the SME to request that a QMF Policy frame be transmitted to a peer entity to convey the results of the QMF policy change procedure. 6.3.85.7.4 Effect of receipt On receipt of this primitive, the MLME constructs a QMF Policy frame containing the set of QMF Policy elements specified. This frame is then scheduled for transmission. 6.3.85.8 MLME-QMFPOLICYSET.request 6.3.85.8.1 Function This primitive directs the setting of a specific QMF policy in the local MLM. 6.3.85.8.2 Semantics of the service primitive The primitive parameters are as follows: MLME-QMFPOLICYSET.request ( Peer STA address, QMFPolicy ) Name Type Valid range Description Peer STA MAC Address Any valid individual The address of the peer STA for which the QMF Address MAC address policy is to be used. If this parameter is null, the QMF policy applies to all transmissions. QMFPolicy QMF Policy As defined in This parameter describes the QMF policy the element 9.4.2.120 MLME is directed to use for all QMFs transmitted to the Peer STA Address. 531 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.85.8.3 When generated This primitive is generated by the SME to set the MLMEâ€™s QMF policy for a peer STA. 6.3.85.8.4 Effect of receipt On receipt of this primitive, the MLME uses the supplied set of QMF policy parameters in future transmis- sions to the peer. 6.3.86 SCS request and response procedure 6.3.86.1 General The following MLME primitives support the signaling of the SCS request and response procedure. The informative diagram shown in Figure 6-27 depicts the SCS request and response process and is not meant to be exhaustive of all possible protocol uses. Non-AP STA AP SME MLME MLME SME MLME- MLME- SCS.request SCS Request frame SCS.indication Process SCS request MLME- MLME- SCS.confirm SCS Response frame SCS.response AP might decide to terminate a granted SCS at any time MLME-SCS- MLME-SCS- TERM.indication SCS Response frame TERM.request Figure 6-27â€”Example SCS setup and termination protocol exchange 6.3.86.2 MLME-SCS.request 6.3.86.2.1 Function This primitive requests transmission of an SCS Request frame to an AP. 6.3.86.2.2 Semantics of the service primitive The primitive parameters are as follows: 532 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MLME-SCS.request( PeerSTAAddress, DialogToken, SCSRequest, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MAC Address Any valid individual Specifies the address of the MAC address peer MAC entity with which to perform the SCS process. DialogToken Integer 1â€“255 The dialog token to identify the SCS request and response transaction. SCSRequest SCS Descriptor element SCS Descriptor Specifies frame classifiers element, as defined in and priority for the requested 9.4.2.122 SCS stream. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.86.2.3 When generated This primitive is generated by the SME to request that a SCS Request frame be sent to the AP with which the STA is associated. 6.3.86.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a SCS Request frame. The STA then attempts to transmit this frame to the AP with which the STA is associated. 6.3.86.3 MLME-SCS.confirm 6.3.86.3.1 Function This primitive reports the result of a SCS procedure. 6.3.86.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-SCS.confirm( PeerSTAAddress, DialogToken, SCSResponse, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MAC Address Any valid individual MAC Specifies the address of the address peer MAC entity with which to perform the SCS process. DialogToken Integer 1â€“255 The dialog token to identify the SCS request and response transaction. 533 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description SCSResponse SCS Status duple SCS Status duple, as defined Specifies the status returned in 9.6.19.3 by the AP responding to the STAâ€™s requested SCSID. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.86.3.3 When generated This primitive is generated by the MLME as a result of an MLME-SCS.request primitive and indicates the results of the request. This primitive is generated when the STA receives a SCS Response frame from the AP. 6.3.86.3.4 Effect of receipt On receipt of this primitive, the SME should operate according to the procedure in 11.27.2. 6.3.86.4 MLME-SCS.indication 6.3.86.4.1 Function This primitive indicates that an SCS Request frame was received from a non-AP STA. 6.3.86.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-SCS.indication( PeerSTAAddress, DialogToken, SCSRequest, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MACAddress Any valid individual The address of the non-AP MAC address STA MAC entity from which an SCS Request frame was received. DialogToken Integer 1â€“255 The dialog token to identify the SCS request and response transaction. SCSRequest SCS Descriptor element SCS Descriptor Specifies frame classifiers element, as defined in and priority for the requested 9.4.2.122 SCS stream. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.86.4.3 When generated This primitive is generated by the MLME when a valid SCS Request frame is received. 6.3.86.4.4 Effect of receipt On receipt of this primitive, the SME should operate according to the procedure in 11.27.2. 534 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.86.5 MLME-SCS.response 6.3.86.5.1 Function This primitive is generated in response to an MLME-SCS.indication primitive requesting an SCS Response frame be sent to a non-AP STA. 6.3.86.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-SCS.response( PeerSTAAddress, DialogToken, SCSResponse, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MACAddress Any valid individual The address of the non-AP MAC address STA MAC entity from which a SCS Request frame was received. DialogToken Integer 1â€“255 The dialog token to identify the SCS request and response transaction. SCSResponse SCS Status duple SCS Status duple, as Specifies the status returned defined in 9.6.19.3 by the AP responding to the STAâ€™s requested SCSID. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.86.5.3 When generated This primitive is generated by the SME in response to an MLME-SCS.indication primitive requesting an SCS Response frame be sent to a non-AP STA. 6.3.86.5.4 Effect of receipt On receipt of this primitive, the MLME constructs a SCS Response frame. The STA then attempts to transmit this frame to the non-AP STA indicated by the PeerSTAAddress parameter. 6.3.86.6 MLME-SCS-TERM.request 6.3.86.6.1 Function This primitive requests the transmission of a SCS Response frame to a non-AP STA to terminate an established SCS stream. 6.3.86.6.2 Semantics of the service primitive The primitive parameters are as follows: MLME-SCS-TERM.request( PeerSTAAddress, DialogToken, SCSResponse, VendorSpecificInfo ) 535 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description PeerSTAAddress MACAddress Any valid individual The address of the non-AP MAC address STA MAC entity to which the SCS Response frame is to be sent. DialogToken Integer 0 Set to 0 for an autonomous SCS Response frame. SCSResponse SCS Status duple SCS Status duple, as Specifies the requested defined in 9.6.19.3 SCSID that is canceled by the AP. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.86.6.3 When generated This primitive is generated by the SME to terminate an SCS stream. 6.3.86.6.4 Effect of receipt On receipt of this primitive, the MLME constructs an SCS Response frame. The STA then attempts to transmit this frame to the non-AP STA indicated by the PeerSTAAddress parameter. 6.3.86.7 MLME-SCS-TERM.indication 6.3.86.7.1 Function This primitive is generated by the MLME when a valid unsolicited SCS Response frame is received. 6.3.86.7.2 Semantics of the service primitive The primitive parameters are as follows: MLME-SCS-TERM.indication( ResultCode, DialogToken, SCSResponse, VendorSpecificInfo ) Name Type Valid range Description ResultCode Enumeration SUCCESS, FAILURE Indicates the result of the MLME-SCS-TERM.request primitive. DialogToken Integer 0 Set to 0 for an autonomous SCS Response frame. SCSResponse SCS Status duple SCS Status duple, as Specifies the requested defined in 9.6.19.3 SCSID that is canceled by the AP. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 536 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.86.7.3 When generated This primitive is generated when the STA receives an unsolicited SCS Response frame from the AP. 6.3.86.7.4 Effect of receipt On receipt of this primitive, the SME should operate according to the procedure in 11.27.2. 6.3.87 QLoad report management 6.3.87.1 General The QLoad report management primitives support the process of QLoad reporting between APs as described in 11.28.2. 6.3.87.2 MLME-QLOAD.request 6.3.87.2.1 Function This primitive is used by an AP to transmit a QLoad Request frame to a specified AP. 6.3.87.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-QLOAD.request( PeerMACAddress, DialogToken, Protected, VendorSpecificInfo ) Name Type Valid range Description PeerMACAddress MACAddress Any valid individual The address of the peer MAC address MAC entity to which the QLoad Request frame is sent. DialogToken Integer 1â€“255 Specifies a number unique to the MLME-QLOAD.request primitive. Protected Boolean true, false If true, the request is sent using the Protected QLoad Request frame. If false, the request is sent using the QLoad Request frame. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.87.2.3 When generated This primitive is generated by the SME at an AP to request the transmission of a QLoad Request frame to the AP indicated by the PeerMACAddress parameter. 537 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.87.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a QLoad Request frame if the Protected parameter is false or a Protected QLoad Request frame if the Protected parameter is true. The AP then attempts to transmit this frame to the AP indicated by the PeerMACAddress parameter. 6.3.87.3 MLME-QLOAD.confirm 6.3.87.3.1 Function This primitive reports the result of a request to send a QLoad Request frame. 6.3.87.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-QLOAD.confirm( PeerMACAddress, DialogToken, Protected, QLoadReport, VendorSpecificInfo ) Name Type Valid range Description PeerMACAddress MACAddress Any valid individual MAC The address of the peer address MAC entity to which the QLoad Request frame was sent. DialogToken Integer 0â€“255 Specifies a number unique to the QLoad Report request and response transaction or 0 when an unsolicited report was sent. Protected Boolean true, false If true, the response was sent using the Protected QLoad Report frame. If false, the response was sent using the QLoad Report frame. QLoadReport Set of reports, each Set of reports, each as Set of reports, each as as defined in the defined in the QLoad Report defined in the QLoad Report QLoad Report element element. element VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.87.3.3 When generated This primitive is generated by the MLME as a result of an MLME-QLOAD.request primitive indicating the results of that request. This primitive is generated when the STA receives a response in the form of a QLoad Report frame in the corresponding Robust AV Streaming Action frame. 6.3.87.3.4 Effect of receipt The SME is notified of the results of the QLoad request procedure. The SME should operate according to the procedures defined in 11.28.2. 538 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.87.4 MLME-QLOAD.indication 6.3.87.4.1 Function This primitive indicates that a QLoad Request frame has been received. 6.3.87.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-QLOAD.indication( PeerMACAddress, DialogToken, Protected, VendorSpecificInfo ) Name Type Valid range Description PeerMACAddress MACAddress Any valid individual The address of the peer MAC address MAC entity from which the QLoad Request frame was received. DialogToken Integer 1â€“255 Specifies a number unique to the MLME-QLOAD.request primitive. Protected Boolean true, false If true, the request was sent using the Protected QLoad Request frame. If false, the request was sent using the QLoad Request frame. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.87.4.3 When generated This primitive is generated by the MLME when a valid (Protected) QLoad Request frame is received. 6.3.87.4.4 Effect of receipt On receipt of this primitive, the SME either rejects the request or commences the transaction as described in 11.28.2. 6.3.87.5 MLME-QLOAD.response 6.3.87.5.1 Function This primitive is used by an AP to transmit a QLoad Report frame to a specified AP in response to a QLoad Request frame. 6.3.87.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-QLOAD.response( PeerMACAddress, DialogToken, Protected, 539 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications QLoadReport, VendorSpecificInfo ) Name Type Valid range Description PeerMACAddress MACAddress Any valid individual The address of the peer MAC address MAC entity to which the QLoad Report frame is sent. DialogToken Integer 0â€“255 The dialog token of the matching MLME- QLOAD.indication primitive or 0 when sending an unsolicited report. Protected Boolean true, false If true, the response is sent using the Protected QLoad Report frame. If false, the response is sent using the QLoad Report frame. QLoadReport Set of reports, each as Set of reports, each as Set of reports, each as defined in the QLoad defined in the QLoad defined in the QLoad Report Report element Report element element. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.87.5.3 When generated This primitive is generated by the SME at an AP in response to the reception of a QLoad Request frame from the AP indicated by the PeerMACAddress parameter. 6.3.87.5.4 Effect of receipt On receipt of this primitive, the MLME constructs a QLoad Report frame if the Protected parameter is false or a Protected QLoad Report frame if the Protected parameter is true. The AP then attempts to transmit this frame to the other AP indicated by the PeerMACAddress parameter. 6.3.88 HCCA TXOP advertisement management 6.3.88.1 General The TXOP advertisement management primitives support the process of TSPEC schedule negotiation between APs, as described in 11.28. 6.3.88.2 MLME-TXOPADVERTISEMENT.request 6.3.88.2.1 Function This primitive is used by an AP to transmit an HCCA TXOP advertisement to a specified AP. 6.3.88.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TXOPADVERTISEMENT.request( PeerMACAddress, DialogToken, Protected, ActiveTXOPReservations, 540 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications PendingTXOPReservations, VendorSpecificInfo ) Name Type Valid range Description PeerMACAddress MACAddress Any valid individual The address of the peer MAC address MAC entity to which the TXOP Advertisement frame is sent. DialogToken Integer 0â€“255 Specifies a number unique to the TXOPAdvertisement.request primitive. Protected Boolean true, false If true, the request is sent using the Protected HCCA TXOP Advertisement frame. If false, the request is sent using the HCCA TXOP Advertisement frame. ActiveTXOPReservations TXOP Reservation As defined in 9.4.1.44 Specifies the HCCA TXOPs that have been created. PendingTXOPReservations TXOP Reservation As defined in 9.4.1.44 Specifies the HCCA TXOPs that are in the process of being created. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.88.2.3 When generated This primitive is generated by the SME at an AP to request a (Protected) HCCA TXOP Advertisement frame be sent to the AP indicated by the PeerMACAddress parameter. 6.3.88.2.4 Effect of receipt On receipt of this primitive, the MLME constructs an HCCA TXOP Advertisement frame if the Protected parameter is false or constructs a Protected HCCA TXOP Advertisement frame if the Protected parameter is true. This frame is then scheduled for transmission. 6.3.88.3 MLME-TXOPADVERTISEMENT.confirm 6.3.88.3.1 Function This primitive reports the result of a request to perform HCCA TXOP negotiation. 6.3.88.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TXOPADVERTISEMENT.confirm( ResultCode, PeerMACAddress, DialogToken, Protected, AlternateSchedule, AvoidanceRequest, VendorSpecificInfo ) 541 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description ResultCode Enumeration SUCCESS, Reports the outcome of a TS_SCHEDULE_ request to send a TXOP CONFLICT advertisement. Indicates the results of the corresponding MLME- TXOPADVERTISE.request primitive. PeerMACAddress MACAddress Any valid individual MAC The address of the peer address MAC entity from which the Scheduled TXOP Response frame was received. DialogToken Integer 0â€“255 The dialog token to identify the scheduled TXOP advertisement and scheduled TXOP response transaction. Protected Boolean true, false If true, the response was sent using the Protected HCCA TXOP Response frame. If false, the response was sent using the HCCA TXOP Response frame. AlternateSchedule TXOP Reservation As defined in 9.4.1.44 Specifies an alternate TXOP when status code is not SUCCESS. AvoidanceRequest TXOP Reservation As defined in 9.4.1.44 Specifies a TXOP to avoid when status code is not SUCCESS. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.88.3.3 When generated This primitive is generated by the MLME as a result of an MLME-TXOPADVERTISEMENT.request primitive indicating the results of that request. This primitive is generated when the STA receives a response in the form of an HCCA TXOP Response frame in the corresponding Public Action frame, or when the STA receives a response in the form of a Protected HCCA TXOP Response frame in the corresponding frame. 6.3.88.3.4 Effect of receipt On receipt of this primitive, the SME performs the behavior defined in 11.28.3. 6.3.88.4 MLME-TXOPADVERTISEMENT.indication 6.3.88.4.1 Function This primitive indicates that an HCCA TXOP Advertisement frame has been received from a peer entity. 6.3.88.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TXOPADVERTISEMENT.indication( PeerMACAddress, DialogToken, Protected, ActiveTXOPReservations, 542 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications PendingTXOPReservations, VendorSpecificInfo ) Name Type Valid range Description PeerMACAddress MACAddress Any valid individual The address of the peer MAC address MAC entity from which the HCCA TXOP Advertisement frame was sent. DialogToken Integer 0â€“255 Specifies a number unique to the MLME- TXOPADVERTISEMENT.r equest primitive. Protected Boolean true, false If true, the request was sent using the Protected HCCA TXOP Request frame. If false, the request was sent using the HCCA TXOP Request frame. ActiveTXOPReservations TXOP Reservation As defined in 9.4.1.44 Specifies the HCCA TXOPs that have been created. PendingTXOPReservations TXOP Reservation As defined in 9.4.1.44 Specifies the HCCA TXOPs that are in the process of being created. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.88.4.3 When generated This primitive is generated by the MLME when a valid HCCA TXOP Advertisement frame is received. 6.3.88.4.4 Effect of receipt On receipt of this primitive, the SME performs the behavior defined in 11.28.3. 6.3.88.5 MLME-TXOPADVERTISEMENT.response 6.3.88.5.1 Function This primitive is used by an AP to transmit an HCCA TXOP Response frame to a specified AP. 6.3.88.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TXOPADVERTISEMENT.response( PeerMACAddress, DialogToken, Protected, StatusCode, ScheduleConflict, AlternateSchedule, AvoidanceRequest, VendorSpecificInfo ) 543 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description PeerMACAddress MACAddress Any valid individual The address of the peer MAC address MAC entity to which the HCCA TXOP Response frame is sent. DialogToken Integer 0â€“255 The dialog token to identify the TXOP advertisement and TXOP response transaction. Protected Boolean true, false If true, the response is sent using the Protected HCCA TXOP Response frame. If false, the response is sent using the HCCA TXOP Response frame. StatusCode Enumeration SUCCESS, The result of checking the TS_SCHEDULE_ TXOP reservation from the CONFLICT (as defined corresponding TXOP in 9.4.1.9) advertisement. ScheduleConflict Integer 1â€“number of TXOP The TXOP reservation from reservations the HCCA TXOP Advertisement frame that conflicts with an existing or in-progress schedule. AlternateSchedule TXOP Reservation As defined in 9.4.1.44 Specifies an alternate TXOP when status code is not SUCCESS. AvoidanceRequest TXOP Reservation As defined in 9.4.1.44 Specifies a TXOP to avoid when status code is not SUCCESS. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.88.5.3 When generated This primitive is generated by the SME at an AP to request the sending of an HCCA TXOP Response frame to another AP indicated by the PeerMACAddress parameter. 6.3.88.5.4 Effect of receipt On receipt of this primitive, the MLME constructs an HCCA TXOP Response frame if the Protected parameter is false or constructs a Protected HCCA TXOP Response frame if the Protected parameter is true. The AP then attempts to transmit this frame to the AP indicated by the PeerMACAddress parameter. 6.3.89 GCR group membership management 6.3.89.1 General The group membership primitives support the process of group membership requesting and reporting between an AP and its associated STAs as described in 11.24.16.3.2. 6.3.89.2 MLME-GROUP-MEMBERSHIP.request 6.3.89.2.1 Function This primitive is used by an AP to initiate a Group Membership Request frame to a specified associated STA. 544 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.89.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-GROUP-MEMBERSHIP.request( PeerMACAddress, DialogToken, VendorSpecificInfo ) Name Type Valid range Description PeerMACAddress MACAddress Any valid individual The address of the peer MAC address MAC entity to which the Group Membership Request frame is to be sent. DialogToken Integer 0â€“255 Specifies a number unique to the MLME-GROUP- MEMBERSHIP.request primitive. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.89.2.3 When generated This primitive is generated by the SME at an AP to request the sending of a Group Membership Request frame to the associated STA indicated by the PeerMACAddress parameter. 6.3.89.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a Group Membership Request frame. The AP then attempts to transmit this frame to the STA indicated by the PeerMACAddress parameter. 6.3.89.3 MLME-GROUP-MEMBERSHIP.confirm 6.3.89.3.1 Function This primitive reports the result of a request for a STAâ€™s group membership. 6.3.89.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-GROUP-MEMBERSHIP.confirm( GroupAddress, VendorSpecificInfo ) Name Type Valid range Description GroupAddress MAC Address Any valid MAC address that Zero or more MAC has the Individual/Group addresses that correspond to Address bit set the contents of the dot11GroupAddressesTable of the STA that responded to the group address request. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 545 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.89.3.3 When generated This primitive is generated by the MLME as a result of an MLME-GROUP-MEMBERSHIP.request primitive indicating the results of that request. This primitive is generated when the STA receives a response in the form of a Group Membership Response frame in the corresponding robust Action frame from the associated STA. 6.3.89.3.4 Effect of receipt The SME is notified of the results of the group membership request procedure. The SME should operate according to the procedures defined in 11.24.16.3.2. 6.3.89.4 MLME-GROUP-MEMBERSHIP.indication 6.3.89.4.1 Function This primitive indicates that a Group Membership Request frame has been received from a peer entity. 6.3.89.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-GROUP-MEMBERSHIP.indication( PeerMACAddress, DialogToken, VendorSpecificInfo ) Name Type Valid range Description PeerMACAddress MACAddress Any valid individual The address of the peer MAC address MAC entity from which the Group Membership Request frame was sent. DialogToken Integer 0â€“255 Specifies a number unique to the MLME-GROUP- MEMBERSHIP primitive. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.89.4.3 When generated This primitive is generated by the MLME when a valid Group Membership Request frame is received. 6.3.89.4.4 Effect of receipt On receipt of this primitive, the SME performs the behavior defined in 11.24.16.3.2. 6.3.89.5 MLME-GROUP-MEMBERSHIP.response 6.3.89.5.1 Function This primitive responds to the request for the contents of the group address table by a specified STAâ€™s MAC entity. 546 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.89.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-GROUP-MEMBERSHIP.response( PeerMACAddress, DialogToken, GroupAddress, VendorSpecificInfo ) Name Type Valid range Description PeerMACAddress MACAddress Any valid individual The address of the peer MAC address MAC entity to which the Group Membership Response frame is sent. DialogToken Integer 0â€“255 Specifies a number unique to the MLME-GROUP- MEMBERSHIP primitive. GroupAddress MAC Address Any valid MAC address Zero or more MAC that has the Individual/ addresses that correspond to Group Address bit set the contents of the dot11GroupAddressesTable of the STA that is responding to the group address request. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.89.5.3 When generated This primitive is generated by the MLME as a result of an MLME-GROUP-MEMBERSHIP.indication primitive. 6.3.89.5.4 Effect of receipt On receipt of this primitive, the SME performs the behavior defined in 11.24.16.3.2. 6.3.90 AP PeerKey management 6.3.90.1 General The AP PeerKey management primitives support the AP PeerKey protocol to provide session identification and data confidentiality for an AP-to-AP connection, as described in 12.11. 6.3.90.2 MLME-APPEERKEY.request 6.3.90.2.1 Function This primitive is used by an AP to transmit a public key to a specified AP and to request the peerâ€™s public key. 6.3.90.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-APPEERKEY.request( 547 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications PeerMACAddress, RequestType, Group, PublicKey, VendorSpecificInfo ) Name Type Valid range Description PeerMACAddress MACAddress Any valid individual The address of the peer MAC address MAC entity to which the Public Key frame is sent. RequestType Integer As defined in Table 9- Specifies the type of request. 321 Group Finite Cyclic Group As defined in 9.4.1.41 Specifies cyclic group from field which the public key was generated. PublicKey Scalar field As defined 9.4.1.40 The public key of the AP sending this Public Key frame. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.90.2.3 When generated This primitive is generated by the SME at an AP to request the sending of a Public Key frame to another AP indicated by the PeerMACAddress parameter. 6.3.90.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a Public Key frame. The AP then attempts to transmit this frame to the AP indicated by the PeerMACAddress parameter. 6.3.90.3 MLME-APPEERKEY.indication 6.3.90.3.1 Function This primitive indicates that a Public Key frame has been received from a peer entity. 6.3.90.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-APPEERKEY.indication( PeerMACAddress, RequestType, Group, PublicKey, 548 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications VendorSpecificInfo ) Name Type Valid range Description PeerMACAddress MACAddress Any valid individual The address of the peer MAC address MAC entity from which the Public Key frame has been received. RequestType Integer As defined in Table 9- Specifies the type of request. 321 Group Finite Cyclic Group 9.4.1.41 Specifies cyclic group from field which the public key was generated. PublicKey Scalar field 9.4.1.40 The public key of the AP that sent this Public Key frame. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.90.3.3 When generated This primitive is generated by the MLME when a valid Public Key frame is received. 6.3.90.3.4 Effect of receipt On receipt of this primitive, the SME performs the behavior defined in 12.11. 6.3.91 On-channel Tunneling operation 6.3.91.1 General On-channel tunneling (OCT) primitives are used as part of multi-band operation (see 11.33). OCT frames are used to transport Management frames between peer MLME entities of multi-band capable devices. The operation of the OCT is illustrated in Figure 6-28. Multi-band capable device Multi-band capable device SME NT-MLME TR-MLME TR-MLME NT-MLME SME MLME- OCTunnel.req (tunneled MMPDU) On-channel Tunnel Request frame MLME- OCTunnel.ind (tunneled MMPDU) Figure 6-28â€”Operation of OCT An initiator MLME of a STA that might not be currently enabled to transmit generates an MLME- OCTunnel.request primitive to a local MLME entity of a STA that is enabled to transmit. This request carries the contents of a Management frame and replaces transmission over-the-WM of that frame. 549 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The recipient MLME generates the MLME-OCTunnel.indication primitive to the local MLME entity identified in the On-channel Tunnel Request frame. The direct MLME-to-MLME primitive exchange should be viewed as shorthand for an exchange through the SMEs and multi-band entity, i.e., an MLME addresses another local MLME entity by sending that primitive through its SME and the multi-band entity to the SME of the MLME entity of a STA that is enabled to transmit, which reflects that primitive to the appropriate recipient. 6.3.91.2 MLME-OCTunnel.request 6.3.91.2.1 Function This primitive requests transmission of an On-channel Tunnel Request frame. 6.3.91.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-OCTunnel.request( PeerSTAAddress, OCT MMPDU, Multi-band peer ) Name Type Valid range Description PeerSTAAddress MAC Address Any valid individual MAC Specifies the MAC address of the STA address to which the On-channel Tunnel Request frame is transmitted. OCT MMPDU OCT MMPDU As defined in the On-channel The OCT MMPDU carries the structure Tunnel Request frame format MMPDU to be tunneled to the specified (see 9.6.21.7) MLME entity of the specified STA. Multi-band peer Multi-band As defined in the Multi-band The Multi-band element identifies the element element format (see 9.4.2.138) peer MLME entity that should receive the OCT MMPDU. 6.3.91.2.3 When generated This primitive is generated by another MLME to request that an On-channel Tunnel Request frame be sent to another STA. 6.3.91.2.4 Effect on receipt On receipt of this primitive, the MLME constructs and attempts to transmit an On-channel Tunnel Request frame. 6.3.91.3 MLME-OCTunnel.indication 6.3.91.3.1 Function This primitive indicates that an On-channel Tunnel Request frame was received. 6.3.91.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-OCTunnel.indication( 550 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications PeerSTAAddress, OCT MMPDU, Multi-band local ) Name Type Valid range Description PeerSTAAddress MAC Address Any valid individual MAC Specifies the MAC address of the STA address from which the On-channel Tunnel Request frame was received. OCT MMPDU OCT MMPDU As defined in the On-channel The OCT MMPDU carries the structure Tunnel Request frame format MMPDU that is being tunneled to the (see 9.6.21.7) local MLME entity. Multi-band local Multi-band As defined in the Multi-band The Multi-band element identifies the element element format (see 9.4.2.138) local MLME entity that should receive the OCT MMPDU. 6.3.91.3.3 When generated This primitive is generated by the MLME to notify another MLME when a valid On-channel Tunnel Request frame is received. 6.3.91.3.4 Effect on receipt The recipient of this primitive is an MLME entity in a multi-band device. On receipt of this primitive, the MLME retrieves the tunneled frame and processes it as though it were received over-the-WM. 6.3.92 Multi-band operation 6.3.92.1 General This subclause describes the management procedures associated with the multi-band operation mechanism. 6.3.92.2 MLME-FST-SETUP.request 6.3.92.2.1 Function This primitive requests transmission of an FST Setup Request frame. 6.3.92.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-FST-SETUP.request( FSTResponderAddress, FSTSetupRequest ) 551 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description FSTResponderAddress MAC Address Any valid individual Specifies the MAC address of the MAC address STA to which the FST Setup Request frame is transmitted. FSTSetupRequest FST Setup As defined in the FST Specifies the parameters of the FST Request Action Setup Request frame Setup. field format 6.3.92.2.3 When generated This primitive is generated by the SME to request that an FST Setup Request frame be sent to another STA. 6.3.92.2.4 Effect on receipt On receipt of this primitive, the MLME constructs and attempts to transmit an FST Setup Request frame. 6.3.92.3 MLME-FST-SETUP.indication 6.3.92.3.1 Function This primitive indicates that an FST Setup Request frame was received. 6.3.92.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-FST-SETUP.indication( FSTInitiatorAddress, FSTSetupRequest ) Name Type Valid range Description FSTInitiatorAddress MAC Address Any valid individual Specifies the MAC address of the MAC address STA from which the FST Setup Request frame was received. FSTSetupRequest FST Setup Request As defined in FST Setup Specifies the parameters of the FST Action field Request frame Setup. 6.3.92.3.3 When generated This primitive is generated by the MLME when a valid FST Setup Request frame is received. 6.3.92.3.4 Effect on receipt On receipt of this primitive, the SME operates according to the procedure in 11.33. 6.3.92.4 MLME-FST-SETUP.response 6.3.92.4.1 Function This primitive requests that an FST Setup Response frame be transmitted to the FST initiator STA. 6.3.92.4.2 Semantics of the service primitive The primitive parameters are as follows: 552 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MLME-FST-SETUP.response( FSTInitiatorAddress, FSTSetupResponse ) Name Type Valid range Description FSTInitiatorAddress MAC Address Any valid Specifies the MAC address of the STA to individual MAC which the FST Setup Response frame is address transmitted. FSTSetupResponse FST Setup Response As defined in Specifies the parameters of the FST Setup. Action field FST Setup Response frame 6.3.92.4.3 When generated This primitive is generated by the SME to request that an FST Setup Response frame is be transmitted to the FST initiator STA. 6.3.92.4.4 Effect on receipt On receipt of this primitive, the MLME constructs and attempts to transmit an FST Setup Response frame. 6.3.92.5 MLME-FST-SETUP.confirm 6.3.92.5.1 Function This primitive indicates that an FST Setup Response frame was received. 6.3.92.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-FST-SETUP.confirm( FSTResponderAddress, FSTSetupResponse ) Name Type Valid range Description FSTResponderAddress MAC Address Any valid Specifies the MAC address of the STA from individual MAC which the FST Setup Response frame was address received. FSTSetupResponse FST Setup As defined in Specifies the parameters of the FST Setup. Response Action FST Setup field Response frame 6.3.92.5.3 When generated This primitive is generated by the MLME when a valid FST Setup Response frame is received. 6.3.92.5.4 Effect on receipt On receipt of this primitive, the SME operates according to the procedure in 11.33. 553 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.92.6 MLME-FST-ACK.request 6.3.92.6.1 Function This primitive requests transmission of an FST Ack Request frame. 6.3.92.6.2 Semantics of the service primitive The primitive parameters are as follows: MLME-FST-ACK.request( FSTResponderAddress, FSTAckRequest ) Name Type Valid range Description FSTResponderAddress MAC Address Any valid Specifies the MAC address of the STA to individual MAC which the FST Ack Request frame is address transmitted. FSTAckRequest FST Ack Request As defined in Specifies the parameters of the FST Ack Action field FST Ack Request. Request frame 6.3.92.6.3 When generated This primitive is generated by the SME to request that an FST Ack Request frame be sent to another STA. 6.3.92.6.4 Effect on receipt On receipt of this primitive, the MLME constructs and attempts to transmit an FST Ack Request frame. 6.3.92.7 MLME-FST-ACK.indication 6.3.92.7.1 Function This primitive indicates that an FST Ack Request frame was received. 6.3.92.7.2 Semantics of the service primitive The primitive parameters are as follows: MLME-FST-ACK.indication( FSTInitiatorAddress, FSTAckRequest ) Name Type Valid range Description FSTInitiatorAddress MAC Address Any valid Specifies the MAC address of the STA from individual MAC which the FST Ack Request frame was address received. FSTAckRequest FST Ack Request As defined in Specifies the parameters of the FST Ack Action field FST Ack Request. Request frame 554 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.92.7.3 When generated This primitive is generated by the MLME when a valid FST Ack Request frame is received. 6.3.92.7.4 Effect on receipt On receipt of this primitive, the MLME operates according to the procedure in 11.33. 6.3.92.8 MLME-FST-ACK.response 6.3.92.8.1 Function This primitive requests that an FST Ack Response frame be transmitted to the FST initiator STA. 6.3.92.8.2 Semantics of the service primitive The primitive parameters are as follows: MLME-FST-ACK.response( FSTInitiatorAddress, FSTAckResponse ) Name Type Valid range Description FSTInitiatorAddress MAC Address Any valid Specifies the MAC address of the STA to individual MAC which the FST Ack Response frame is address transmitted. FSTAckResponse FST Ack Response As defined in Specifies the parameters of the FST Ack Action field FST Ack Response. Response frame 6.3.92.8.3 When generated This primitive is generated by the SME to request that an FST Ack Response frame be transmitted to the FST initiator STA. 6.3.92.8.4 Effect on receipt On receipt of this primitive, the MLME constructs and attempts to transmit an FST Ack Response frame. 6.3.92.9 MLME-FST-ACK.confirm 6.3.92.9.1 Function This primitive indicates that an FST Ack Response frame was received. 6.3.92.9.2 Semantics of the service primitive The primitive parameters are as follows: MLME-FST-ACK.confirm( FSTResponderAddress, FSTAckResponse ) 555 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description FSTResponderAddress MAC Address Any valid Specifies the MAC address of the STA individual MAC from which the FST Ack Response address frame was received. FSTAckResponse FST Ack Response As defined in FST Specifies the parameters of the FST Action field Ack Response Ack Response. frame 6.3.92.9.3 When generated This primitive is generated by the MLME when a valid FST Ack Response frame is received. 6.3.92.9.4 Effect on receipt On receipt of this primitive, the MLME operates according to the procedure in 11.33. 6.3.92.10 MLME-FST-TEARDOWN.request 6.3.92.10.1 Function This primitive requests that an FST Teardown frame be transmitted to the FST initiator STA. 6.3.92.10.2 Semantics of the service primitive The primitive parameters are as follows: MLME-FST-TEARDOWN.request( FSTPeerSTAAddress, FSTTeardown ) Name Type Valid range Description FSTPeerSTAAddress MAC Address Any valid individual Specifies the MAC address of the STA to MAC address which the FST Teardown frame is transmitted. FSTTeardown FST Teardown As defined in FST Specifies the parameters of the FST Action field Teardown frame teardown. 6.3.92.10.3 When generated This primitive is generated by the SME to request that an FST Teardown frame be transmitted to the FST peer STA. 6.3.92.10.4 Effect on receipt On receipt of this primitive, the MLME constructs and attempts to transmit an FST Teardown frame. 6.3.92.11 MLME-FST-TEARDOWN.indication 6.3.92.11.1 Function This primitive indicates that an FST Teardown frame was received. 556 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.92.11.2 Semantics of the service primitive The primitive parameters are as follows: MLME-FST-TEARDOWN.indication( FSTPeerSTAAddress, FSTAckResponse ) Name Type Valid range Description FSTPeerSTAAddress MAC Address Any valid Specifies the MAC address of the STA from individual MAC which the FST Teardown frame was address received. FSTTeardown FST Teardown As defined in FST Specifies the parameters of the FST Action field Teardown frame teardown. 6.3.92.11.3 When generated This primitive is generated by the MLME when a valid FST Teardown frame is received. 6.3.92.11.4 Effect on receipt On receipt of this primitive, the MLME operates according to the procedure in 11.33. 6.3.92.12 MLME-FST-INCOMING.request 6.3.92.12.1 Function This primitive announces an incoming FST from another band/channel. This primitive does not result in the transmission of a frame. 6.3.92.12.2 Semantics of the service primitive The primitive parameters are as follows: MLME-FST-INCOMING.request( FSTInitiatorAddress, FSTResponderAddress, FSTSetupRequest, FSTSetupResponse, FSTIsInitiator ) Name Type Valid range Description FSTInitiatorAddress MAC Address Any valid individual Specifies the MAC address of the STA MAC address that is the FST initiator. FSTResponderAddress MAC Address Any valid individual Specifies the MAC address of the STA MAC address that is the FST responder. FSTSetupRequest FST Setup As defined in FST Specifies the parameters of the last FST Request Action Setup Request frame Setup Request frame exchanged between field the initiator and responder. 557 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description FSTSetupResponse FST Setup As defined in FST Specifies the parameters of the last FST Response Action Setup Response Setup Response frame exchanged field frame between the initiator and responder. FSTIsInitiator Boolean true, false Indicates the role that the STA performs in the FST. Set to true if the STA performs in the role of initiator STA, and set to false otherwise. 6.3.92.12.3 When generated This primitive is generated by the SME to announce that an FST session is being transferred from another band/channel. 6.3.92.12.4 Effect on receipt On receipt of this primitive, the MLME is notified of an incoming FST session. The MLME does not transmit a frame as a result of this primitive. 6.3.93 DMG relay operation 6.3.93.1 General This subclause describes the management procedures associated with DMG relay. 6.3.93.2 MLME-RELAY-SEARCH.request 6.3.93.2.1 Function This primitive requests a list of relay DMG STAs (RDSs) in the BSS. 6.3.93.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-RELAY-SEARCH.request( DestinationMACAddress ) Name Type Valid range Description DestinationMACAddress MACAddress Any valid individual Specifies the MAC address of the non- MAC address AP and non-PCP STA that is the intended immediate recipient of the data flow. 6.3.93.2.3 When generated This primitive is generated by the SME at a non-AP and non-PCP STA to transmit a request to the PCP/AP for a list of RDSs in the BSS. 6.3.93.2.4 Effect on receipt This primitive initiates a relay search procedure. The MLME subsequently issues an MLME-RELAY- SEARCH.confirm primitive that reflects the results. 558 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.93.3 MLME-RELAY-SEARCH.confirm 6.3.93.3.1 Function This primitive reports a list of RDSs in the BSS. 6.3.93.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-RELAY-SEARCH.confirm( RelayCapableSTAInfo, ResultCode ) Name Type Valid range Description RelayCapableSTAInfo As defined in frame As defined in As described in 9.4.1.45 (zero or more) format 9.4.1.45 ResultCode Enumeration SUCCESS, Indicates the results of the corresponding REFUSED MLME-RELAY-SEARCH.request primitive. 6.3.93.3.3 When generated This primitive is generated when a valid Relay Search Response frame is received. 6.3.93.3.4 Effect on receipt The SME is notified of the results of the relay search procedure. 6.3.93.4 MLME-RELAY-SEARCH.indication 6.3.93.4.1 Function This primitive reports to the SME the request for obtaining a list of RDSs in the BSS. 6.3.93.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-RELAY-SEARCH.indication( SourceMACAddress ) Name Type Valid range Description SourceMACAddress MACAddress Any valid individual Specifies the MAC address of the non-AP MAC address and non-PCP STA that is the intended immediate recipient of the data flow. 6.3.93.4.3 When generated This primitive is generated by the MLME as a result of the receipt of a request to obtain a list of RDSs in the BSS. The receipt of the request resulted from a relay search procedure that was initiated by the STA indicated by the source MAC address specified in the primitive. 559 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.93.4.4 Effect on receipt The SME is notified of a request by a specified non-AP and non-PCP STA to obtain a list of RDSs in the BSS. 6.3.93.5 MLME-RELAY-SEARCH.response 6.3.93.5.1 Function This primitive is used to provide the results of a Relay Search Request. 6.3.93.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-RELAY-SEARCH.response( PeerMACAddress, RelayCapableSTAInfo, StatusCode ) Name Type Valid range Description PeerMACAddress MACAddress Any valid individual The address of the MAC entity to which MAC address the Relay Search Response frame was sent. RelayCapableSTAInfo As defined in As defined in 9.4.1.45 As described in 9.4.1.45 (zero or more) frame format StatusCode As defined in As defined in 9.4.1.9 As described in 9.4.1.9 frame format 6.3.93.5.3 When generated This primitive is generated by the SME to provide the results of a Relay Search Request. 6.3.93.5.4 Effect on receipt On receipt of this primitive, the MLME constructs and attempts to transmit a Relay Search Response frame. 6.3.93.6 MLME-RLS.request 6.3.93.6.1 Function This primitive requests the set up of a relay link with a specified peer MAC entity via a specified relay MAC entity. 6.3.93.6.2 Semantics of the service primitive The primitive parameters are as follows: MLME-RLS.request( DestinationMACAddress, RelayMACAddress, DestinationCapabilityInformation, RelayCapabilityInformation, RelayTransferParameterSet ) 560 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description DestinationMACAddress MACAddress Any valid Specifies the MAC address of the individual non-AP and non-PCP STA that is the MAC address intended immediate recipient of the data flow. RelayMACAddress MACAddress Any valid Specifies the MAC address of the individual selected RDS. MAC address DestinationCapabilityInformation As defined in As defined in Indicates the Relay Capability frame format frame format Information field within the Relay Capabilities element of the target destination relay endpoint DMG STA (REDS). RelayCapabilityInformation As defined in As defined in Indicates the Relay Capability frame format frame format Information field within the Relay Capabilities element of the selected RDS. RelayTransferParameterSet As defined in As defined in Specifies the parameters for the relay frame format frame format operation. 6.3.93.6.3 When generated This primitive is generated by the SME at a non-AP and non-PCP STA to set up a relay link with another non-AP and non-PCP STA. 6.3.93.6.4 Effect on receipt This primitive initiates a relay link setup procedure. 6.3.93.7 MLME-RLS.confirm 6.3.93.7.1 Function This primitive reports the results of a relay link setup attempt with a specified peer MAC entity. 6.3.93.7.2 Semantics of the service primitive The primitive parameters are as follows: MLME-RLS.confirm( PeerMACAddress, RelayMACAddress, ResultCode ) Name Type Valid range Description PeerMACAddress MACAddress Any valid individual Specifies the MAC address of the non- MAC address AP and non-PCP STA from which the frame was received. RelayMACAddress MACAddress Any valid individual Specifies the MAC address of the MAC address selected RDS ResultCode Enumeration SUCCESS, REFUSED Indicates the results of the corresponding MLME-RLS.request primitive. 561 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.93.7.3 When generated This primitive is generated when a valid RLS Response frame is received. 6.3.93.7.4 Effect on receipt The SME is notified of the results of the relay link setup procedure. 6.3.93.8 MLME-RLS.indication 6.3.93.8.1 Function This primitive reports the establishment of a relay link with a specified peer MAC entity. 6.3.93.8.2 Semantics of the service primitive The primitive parameters are as follows: MLME-RLS.indication( SourceMACAddress, RelayMACAddress, SourceCapabilityInformation, RelayCapabilityInformation, RelayTransferParameterSet ) Name Type Valid range Description SourceMACAddress MACAddress Any valid Specifies the MAC address of the STA individual that is the intended immediate recipient MAC address of the data flow. RelayMACAddress MACAddress Any valid Specifies the MAC address of the individual selected RDS MAC address SourceCapabilityInformation As defined in As defined in Specifies the operational capability frame format frame format definitions to be used by the peer MAC entity. RelayCapabilityInformation As defined in As defined in Indicates the Relay Capability frame format frame format Information field within the Relay Capabilities element of the selected RDS RelayTransferParameterSet As defined in As defined in Specifies the parameters for the relay frame format frame format operation 6.3.93.8.3 When generated This primitive is generated by the MLME as a result of the establishment of a relay link with a specific peer MAC entity, and that resulted from a relay link setup procedure that was initiated by that specific source MAC entity. 6.3.93.8.4 Effect on receipt The SME is notified of the establishment of the relay link setup. 562 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.93.9 MLME-RLS.response 6.3.93.9.1 Function This primitive is used to provide the results of an RLS Request. 6.3.93.9.2 Semantics of the service primitive The primitive parameters are as follows: MLME-RLS.response( PeerMACAddress, DestinationStatusCode, RelayStatusCode ) Name Type Valid range Description PeerMACAddress MACAddress Any valid individual Specifies the MAC address of the peer MAC address STA. DestinationStatusCode As defined in As defined in 9.4.1.9 As described in 9.4.1.9 frame format RelayStatusCode As defined in As defined in 9.4.1.9 As described in 9.4.1.9 frame format 6.3.93.9.3 When generated This primitive is generated by the SME to provide the results of a RLS Request. 6.3.93.9.4 Effect on receipt On receipt of this primitive, the MLME constructs and attempts to transmit an RLS Response frame. 6.3.93.10 MLME-RLS-TEARDOWN.request 6.3.93.10.1 Function This primitive requests the teardown of the relay link with a specified peer MAC entity. 6.3.93.10.2 Semantics of the service primitive The primitive parameters are as follows: MLME-RLS-TEARDOWN.request( DestinationMACAddress, RelayMACAddress, Reason ) Name Type Valid range Description DestinationMACAddress MACAddress Any valid individual Specifies the MAC address of the non- MAC address AP and non-PCP STA that is the intended immediate recipient of the data flow. RelayMACAddress MACAddress Any valid individual Specifies the MAC address of the MAC address selected RDS. Reason Enumeration REQUESTED Indicates the reason why the relay link is being torn down. 563 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.93.10.3 When generated This primitive is generated by the SME for tearing down a relay link with another non-AP and non-PCP STA. 6.3.93.10.4 Effect on receipt This primitive initiates a relay link teardown procedure. The MLME subsequently issues an MLME-RLS- TEARDOWN.confirm primitive that reflects the results. 6.3.93.11 MLME-RLS-TEARDOWN.indication 6.3.93.11.1 Function This primitive indicates the teardown of an already established relay link with a specific peer MAC entity. 6.3.93.11.2 Semantics of the service primitive The primitive parameters are as follows: MLME-RLS-TEARDOWN.indication( SourceMACAddress, Reason ) Name Type Valid range Description SourceMACAddress MACAddress Any valid individual Specifies the MAC address of the non- MAC address AP and non-PCP STA that is the intended immediate recipient of the data flow. Reason Enumeration REQUESTED Indicates the reason why the relay link is being torn down. 6.3.93.11.3 When generated This primitive is generated by the MLME as result of the teardown of a relay link with a specific peer MAC entity, and that resulted from a relay link teardown procedure that was initiated either by that specific peer MAC entity or by the local MAC entity. 6.3.93.11.4 Effect on receipt The SME is notified of the relay link teardown. 6.3.94 Quieting adjacent BSS operation 6.3.94.1 General This subclause describes the management procedure associated with the QAB operation. The primitives defined are MLME-QAB.request, MLME-QAB.confirm, MLME-QAB.indication, and MLME-QAB.response primitive. 564 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.94.2 MLME-QAB.request 6.3.94.2.1 Function This primitive requests transmission of a (protected) QAB Request frame. 6.3.94.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-QAB.request( DialogToken, RequesterAP Address, ResponderAP Address, QuietPeriodRequest, Protected, VendorSpecificInfo ) Name Type Valid range Description DialogToken Integer 1â€“255 The dialog token to identify the QAB transaction. RequesterAP Address MACAddress Any valid The address of the MAC entity from individual MAC which the (protected) QAB Request address frame was sent. ResponderAP Address MACAddress Any valid The address of the peer MAC entity to individual MAC which the (protected) QAB request was address sent. QuietPeriodRequest A set of information As described in As described in 9.4.2.150. subfields 9.4.2.150 Protected Boolean true, false Specifies whether the request is sent using a robust Management frame. If true, the request is sent using the Protected QAB Request frame. If false, the request is sent using the QAB Request frame. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.94.2.3 When generated This primitive is generated by the STA management entity (SME) to request that a (Protected) QAB frame be sent by a STA. 6.3.94.2.4 Effect on receipt On receipt of this primitive, the MLME constructs and transmits a (Protected) QAB Request frame. 6.3.94.3 MLME-QAB.confirm 6.3.94.3.1 Function This primitive reports the result of a transmission of a QAB Request frame. 565 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.94.3.2 Semantics of the service primitive The primitive parameters as follows: MLME-QAB.confirm( DialogToken, RequesterAP Address, ResponderAP Address, QuietPeriodResponse, ResultCode, VendorSpecificInfo ) Name Type Valid range Description DialogToken Integer 1â€“255 The dialog token to identify the QAB transaction. RequesterAP Address MACAddress Any valid individual The address of the MAC entity to MAC address which the (protected) QAB Response frame was addressed. ResponderAP Address MACAddress Any valid individual The address of the peer MAC entity MAC address from which the (protected) QAB Response was received. QuietPeriodResponse A set of information As described in As described in 9.4.2.151. subfields 9.4.2.151 ResultCode Enumeration SUCCESS Reports the result of an QAB request. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.94.3.3 When generated This primitive is generated by the MLME when a QAB request completes. Possible unspecified failure causes include an inability to provide the Quiet Period Request element. 6.3.94.3.4 Effect on receipt The SME is notified of the results of the QAB request procedure. 6.3.94.4 MLME-QAB.indication 6.3.94.4.1 Function This primitive indicates that a (Protected) QAB Request frame was received. 6.3.94.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-QAB.indication( DialogToken PeerMACAddress, QuietPeriodRequest, Protected, VendorSpecificInfo ) 566 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description DialogToken Integer 1â€“255 The dialog token to identify the QAB transaction. PeerMACAddress MACAddress Any valid The address of the peer MAC entity from individual MAC which the QAB Request frame was address received. QuietPeriodRequest A set of information As described in As described in 9.4.2.150. subfields 9.4.2.150 Protected Boolean true, false Specifies whether the request was received using a robust Management frame. If true, the request was received using the Protected QAB Request frame. If false, the request was received using the QAB Request frame. VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.94.4.3 When generated This primitive is generated by the MLME when a valid (Protected) QAB Request frame is received. 6.3.94.4.4 Effect on receipt On receipt of this primitive, the SME decides whether to schedule quiet periods as requested. 6.3.94.5 MLME-QAB.response 6.3.94.5.1 Function This primitive is used to provide the results of a QAB Request. 6.3.94.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-QAB.response( DialogToken, RequesterAP Address, ResponderAP Address, QuietPeriodResponse, VendorSpecificInfo ) Name Type Valid range Description DialogToken Integer 1â€“255 The dialog token to identify the QAB transaction. RequesterAP Address MACAddress Any valid individual The address of the MAC entity to MAC address which the (protected) QAB Response frame was sent. ResponderAP Address MACAddress Any valid individual The address of the peer MAC entity MAC address from which the (protected) QAB Response was sent. 567 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description QuietPeriodResponse A set of information As described in As described in 9.4.2.151. subfields 9.4.2.151 VendorSpecificInfo A set of elements As defined in Zero or more elements. 9.4.2.26 6.3.94.5.3 When generated This primitive is generated by the SME to provide the results of a QAB Request. 6.3.94.5.4 Effect on receipt On receipt of this primitive, the MLME provides the results of a QAB Request. 6.3.95 DMG beamforming 6.3.95.1 General This subclause describes the management procedures associated with DMG beamforming. 6.3.95.2 MLME-BF-TRAINING.request 6.3.95.2.1 Function This primitive requests that beamforming training occur with a peer STA. 6.3.95.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-BF-TRAINING.request( PeerSTAAddress, RequestBRP ) Name Type Valid range Description PeerSTAAddress MACAddress Any valid individual Specifies the address of the peer MAC address MAC entity with which to perform beamforming training. RequestBRP Boolean true, false If true, the beam refinement protocol (BRP) is performed as part of the beamforming training. If false, only sector-level sweep (SLS) is performed. 6.3.95.2.3 When generated This primitive is generated by the SME to request that beamforming training be performed with a peer STA. 6.3.95.2.4 Effect on receipt On receipt of this primitive, the MLME invokes the MAC sublayer beamforming training procedures defined in 10.38. 568 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.95.3 MLME-BF-TRAINING.confirm 6.3.95.3.1 Function This primitive reports the outcome of a requested beamforming training procedure. 6.3.95.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-BF-TRAINING.confirm( PeerSTAAddress, ResultCode ) Name Type Valid range Description PeerSTAAddress MACAddress Any valid individual Specifies the address of the peer MAC address MAC entity with which beamforming training was performed or attempted. ResultCode Enumeration SUCCESS, BF- Indicates the result of the TIMEOUT beamforming procedure. 6.3.95.3.3 When generated This primitive is generated by the MLME to report the result of beamforming training with a peer STA. 6.3.95.3.4 Effect on receipt The SME is notified of the result of the procedure. 6.3.95.4 MLME-BF-TRAINING.indication 6.3.95.4.1 Function This primitive indicates that beamforming training with a peer STA, and at the request of that peer, has completed. 6.3.95.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-BF-TRAINING.indication( PeerSTAAddress, ResultCode ) Name Type Valid range Description PeerSTAAddress MACAddress Any valid individual Specifies the address of the peer MAC address MAC entity with which beamforming training was performed. ResultCode Enumeration SUCCESS, BF- Indicates the result of the TIMEOUT beamforming procedure. 569 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.95.4.3 When generated This primitive is generated by the MLME to indicate successful completion of a beamforming training procedure requested by a peer STA. 6.3.95.4.4 Effect on receipt The SME is notified of the result of the procedure. 6.3.96 PN event report 6.3.96.1 General This subclause describes the management procedures associated with PN event report. 6.3.96.2 MLME-PN-EXHAUSTION.indication 6.3.96.2.1 Function This primitive indicates that the PN associated with a temporal key exceeds the threshold that is defined in dot11PNExhaustionThresholdLow and dot11PNExhaustionThresholdHigh. 6.3.96.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-PN-EXHAUSTION.indication( Key ID, Key Type, Address ) Name Type Valid range Description Key ID Integer N/A Key identifier. Key Type Integer Group, Pairwise, Defines whether this key is a group key, pairwise PeerKey, IGTK key, PeerKey, or Integrity Group key. Address MAC address Any valid individual This parameter is valid only when the Key Type MAC address value is Pairwise, or when the Key Type value is Group and is from an IBSS STA, or when the Key Type value is PeerKey. 6.3.96.2.3 When generated This primitive is generated by the MLME when the PN associated with a temporal key exceeds the threshold that is defined in dot11PNExhaustionThresholdLow and dot11PNExhaustionThresholdHigh. 6.3.96.2.4 Effect of receipt On receipt of this primitive, the SME deletes the temporal key associated with the PN. 570 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.96.3 MLME-PN-WARNING.indication 6.3.96.3.1 Function This primitive indicates that the PN associated with a temporal key exceeds the threshold that is defined in dot11PNWarningThresholdLow and dot11PNWarningThresholdHigh. 6.3.96.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-PN-WARNING.indication( Key ID, Key Type, Address ) Name Type Valid range Description Key ID Integer N/A Key identifier. Key Type Integer Group, Pairwise, Defines whether this key is a group key, PeerKey, IGTK pairwise key, PeerKey, or Integrity Group key Address MAC address Any valid This parameter is valid only when the Key individual MAC Type value is Pairwise, or when the Key address Type value is Group and is from an IBSS STA, or when the Key Type value is PeerKey. 6.3.96.3.3 When generated This primitive is generated by the MLME when the PN associated with a temporal key exceeds the threshold that is defined in dot11PNWarningThresholdLow and dot11PNWarningThresholdHigh. 6.3.96.3.4 Effect of receipt On receipt of this primitive, the SME can create a new temporal key before the PN space is exhausted. 6.3.97 Channel Availability Query 6.3.97.1 Introduction The following MLME primitives support the signaling of channel availability query process for the channel query requests and responses. 6.3.97.2 MLME-CHANNELAVAILABILITYQUERY.request 6.3.97.2.1 Function This primitive requests that a (Protected) Channel Availability Query frame be sent to a specified peer MAC entity. 6.3.97.2.2 Semantics of the service primitive The primitive parameters are as follows: 571 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MLME-CHANNELAVAILABILITYQUERY.request ( PeerSTAAddress, ChannelAvailabilityQuery, Protected, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MAC Address Any valid individual The address of the peer MAC entity MAC address to which the Channel Availability Query frame is sent. ChannelAvailabilityQ A set of As defined in 9.6.8.25 Specifies the parameters of channel uery information query. subfields Protected Boolean true, false Specifies whether the request is sent using a robust Management frame. If true, the request is sent using the Protected Channel Availability Query frame. If false, the request is sent using the Channel Availability Query frame. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.97.2.3 When generated This primitive is generated by the SME to request channel query procedure with a specified peer MAC entity. 6.3.97.2.4 Effect of receipt This primitive initiates a channel query procedure. The MLME subsequently issues a MLME- CHANNELAVAILABILITYQUERY.confirm primitive that reflects the results. 6.3.97.3 MLME-CHANNELAVAILABILITYQUERY.confirm 6.3.97.3.1 Function This primitive reports the results of a channel query attempt with a specified peer MAC entity. 6.3.97.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-CHANNELAVAILABILITYQUERY.confirm ( PeerSTAAddress, ResultCode, ChannelAvailabilityQuery, Protected, VendorSpecificInfo ) 572 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description PeerSTAAddress MAC Address Any valid individual The address of the peer MAC entity MAC address from which the response to the Channel Availability Query frame was received. ResultCode Enumeration SUCCESS, Indicates the result of MLME- SUCCESS_MULTIPL CHANNELAVAILABILITYQUERY.r E, REFUSED, equest primitive. DEVICE_VERIFICAT ION_FAILURE ChannelAvailabilityQ A set of As defined in 9.6.8.25 Specifies the parameters of channel uery information fields query. Protected Boolean true, false Specifies whether the response was received using a robust Management frame. If true, the response was received using the Protected Channel Availability Query frame. If false, the response was received using the Channel Availability Query frame. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.97.3.3 When generated This primitive is generated by the MLME as a result of an MLME- CHANNELAVAILABILITYQUERY.request primitive and indicates the results of a channel availability query procedure. 6.3.97.3.4 Effect of receipt The SME is notified of the results of the channel query procedure. 6.3.97.4 MLME-CHANNELAVAILABILITYQUERY.indication 6.3.97.4.1 Function This primitive indicates that a (Protected) Channel Availability Query frame was received from a peer STA. 6.3.97.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-CHANNELAVAILABILITYQUERY.indication ( PeerSTAAddress, ChannelAvailabilityQuery, Protected, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MAC Address Any valid individual The address of the peer MAC entity MAC address from which the Channel Availability Query frame was received. ChannelAvailabilityQ A set of information As defined in 9.6.8.25 Specifies the parameters of channel uery subfields query. 573 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description Protected Boolean true, false Specifies whether the request was received using a robust Management frame. If true, the request was received using the Protected Channel Availability Query frame. If false, the request was received using the Channel Availability Query frame. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.97.4.3 When generated This primitive is generated by the MLME as a result of the receipt of a channel query request from a specific peer MAC entity. 6.3.97.4.4 Effect of receipt The SME is notified of the receipt of this channel query request. 6.3.97.5 MLME-CHANNELAVAILABILITYQUERY.response 6.3.97.5.1 Function This primitive is used to send a response to a specified peer MAC entity that requested channel query with the STA that issued this primitive. 6.3.97.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-CHANNELAVAILABILITYQUERY.response ( PeerSTAAddress, ResultCode, ChannelAvailabilityQuery, Protected, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MAC Address Any valid individual The address of the peer MAC entity to MAC address which the Channel Availability Query frame with the response is sent. ResultCode Enumeration SUCCESS, Indicates the result response of the SUCCESS_MULTIP channel availability query from the peer LE, REFUSED, MAC entity. DEVICE_VERIFICA TION_FAILURE ChannelAvailability A set of information As defined in 9.6.8.25 Specifies the parameters of channel Query subfields query. 574 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description Protected Boolean true, false Specifies whether the response is sent using a robust Management frame. If true, the response is sent using the Protected Channel Availability Query frame. If false, the response is sent using the Channel Availability Query frame. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.97.5.3 When generated This primitive is generated by the SME of a STA as a response to an MLME- CHANNELAVAILABILITYQUERY.indication primitive. 6.3.97.5.4 Effect of receipt Upon receipt of this primitive, the MLME constructs the Channel Availability Query frame as the response. This frame is then scheduled for transmission to the peer MAC address. 6.3.98 Channel schedule management 6.3.98.1 Introduction The following MLME primitives support the signaling of channel schedule management. 6.3.98.2 MLME-CHANNELSCHEDULEMANAGEMENT.request 6.3.98.2.1 Function This primitive requests that a (Protected) Channel Schedule Management frame be sent. 6.3.98.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-CHANNELSCHEDULEMANAGEMENT.request ( PeerSTAAddress, ReasonResultCode, ChannelScheduleManagementMode, DeviceIdentification, ChannelSchedule, Protected, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MAC address Any valid individual The address of the peer MAC entity to MAC address which the Channel Schedule Management frame is sent. ReasonResultCode An enumerated As defined in 9.6.8.26 value for the Reason Result Code field 575 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description ChannelScheduleMa An enumerated As defined in 9.6.8.26 nagementMode value for the Channel Schedule Management Mode field DeviceIdentification Device As defined in 9.4.4.2.2 The Device Identification Information Identification parameter indicates the regulatory Information identification of the STA that is requesting the schedule information. ChannelSchedule A set of Channel As defined in 9.4.4.2.4 The Channel Schedule parameter Schedule indicates the channels for which the Descriptors schedule information is requested. Protected Boolean true, false Specifies whether the request is sent using a robust Management frame. If true, the request is sent using the Protected Channel Schedule Management frame. If false, the request is sent using the Channel Schedule Management frame. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.98.2.3 When generated This primitive is generated by the SME to request that a (Protected) Channel Schedule Management frame be sent by a STA. 6.3.98.2.4 Effect of receipt On receipt of this primitive, the MLME constructs and schedules transmission of a (Protected) Channel Schedule Management frame. 6.3.98.3 MLME-CHANNELSCHEDULEMANAGEMENT.confirm 6.3.98.3.1 Function This primitive reports the result of a channel schedule management query. 6.3.98.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-CHANNELSCHEDULEMANAGEMENT.confirm ( PeerSTAAddress, ReasonResultCode, ChannelScheduleManagementMode, DeviceIdentification, ChannelSchedule, Protected, VendorSpecificInfo ) 576 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description PeerSTAAddress MAC address Any valid individual The address of the peer MAC entity from MAC address which the Channel Schedule Management frame was received. ReasonResultCode An enumerated As defined in 9.6.8.26 value for the Reason Result Code field ChannelScheduleMa An enumerated As defined in 9.6.8.26 nagementMode value for the Channel Schedule Management Mode field DeviceIdentification Device As defined in 9.4.4.2.2 The Device Identification Information Identification parameter indicates the regulatory Information identification of the STA that is requesting the schedule information. ChannelSchedule A set of Channel As defined in 9.4.4.2.4 The Channel Schedule parameter indicates Schedule the channels for which the schedule Descriptors information is provided. Protected Boolean true, false Specifies whether the response is sent using a robust Management frame. If true, the response is sent using the Protected Channel Schedule Management frame. If false, the response is sent using the Channel Schedule Management Public Action frame. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.98.3.3 When generated This primitive is generated by the MLME when a channel schedule request completes. Possible unspecified failure causes include an inability to provide the channel schedule information. 6.3.98.3.4 Effect of receipt The SME is notified of the results of the channel schedule management procedure. 6.3.98.4 MLME-CHANNELSCHEDULEMANAGEMENT.indication 6.3.98.4.1 Function This primitive indicates that a (Protected) Channel Schedule Management frame was received from a peer STA. 6.3.98.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-CHANNELSCHEDULEMANAGEMENT.indication ( PeerSTAAddress, ReasonResultCode, ChannelScheduleManagementMode, DeviceIdentification, ChannelSchedule, Protected, VendorSpecificInfo ) 577 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description PeerSTAAddress MAC address Any valid individual The address of the peer MAC entity from MAC address which the Channel Schedule Management frame was received. ReasonResultCode An enumerated As defined in 9.6.8.26 value for the Reason Result Code field ChannelScheduleMa An enumerated As defined in 9.6.8.26 nagementMode value for the Channel Schedule Management Mode field DeviceIdentification Device As defined in 9.4.4.2.2 The Device Identification Information Identification parameter indicates the regulatory Information identification of the STA that is requesting the schedule information. ChannelSchedule A set of Channel As defined in 9.4.4.2.4 The Channel Schedule parameter indicates Schedule the channels for which the schedule Descriptors information is requested. Protected Boolean true, false Specifies whether the request was received using a robust Management frame. If true, the request was received using the Protected Channel Schedule Management frame. If false, the request was received using the Channel Schedule Management frame. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.98.4.3 When generated This primitive is generated by the MLME when a valid (Protected) Channel Schedule Management frame is received. 6.3.98.4.4 Effect of receipt On receipt of this primitive, the SME decides whether to provide the channel schedule information. 6.3.98.5 MLME-CHANNELSCHEDULEMANAGEMENT.response 6.3.98.5.1 Function This primitive is used to provide channel schedule information on channel availability. 6.3.98.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-CHANNELSCHEDULEMANAGEMENT.response ( PeerSTAAddress, ReasonResultCode, ChannelScheduleManagementMode, DeviceIdentification, ChannelSchedule, Protected, VendorSpecificInfo ) 578 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description PeerSTAAddress MAC address Any valid individual The address of the peer MAC entity to MAC address which the Channel Schedule Management frame is sent. ReasonResultCode An enumerated As defined in 9.6.8.26 value for the Reason Result Code field ChannelScheduleMa An enumerated As defined in 9.6.8.26 nagementMode value for the Channel Schedule Management Mode field DeviceIdentification Device As defined in The Device Identification Information Identification 9.4.4.2.2 parameter indicates the regulatory Information identification of the STA that is requesting the schedule information. ChannelSchedule A set of Channel As defined in The Channel Schedule parameter Schedule 9.4.4.2.4 indicates the channels for which the Descriptors schedule information is provided. Protected Boolean true, false Specifies whether the response is sent using a robust Management frame. If true, the response is sent using the Protected Channel Schedule Management Public Action frame. If false, the response is sent using the Channel Schedule Management Public Action frame. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. 6.3.98.5.3 When generated This primitive is generated by the SME to provide the channel schedule information. 6.3.98.5.4 Effect of receipt On receipt of this primitive, the MLME constructs an appropriate response in a (Protected) Channel Schedule Management frame and schedules the transmission of the frame to the peer MAC entity. 6.3.99 Contact verification signal 6.3.99.1 Introduction The following MLME primitives support the signaling of the contact verification signal (CVS). 6.3.99.2 MLME-CVS.request 6.3.99.2.1 Function This primitive requests that a Contact Verification Signal frame be sent by a STA to a specified peer MAC entity in order to validate a WSM. 6.3.99.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-CVS.request ( PeerSTAAddress, Protected, ContactVerificationSignal ) 579 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description PeerSTAAddress MAC Address Any valid Specifies the address of the peer MAC individual MAC entity with which to perform the Address contact verification signal process. Protected Boolean true, false Specifies whether the request is sent using a robust Management frame. If true, the request is sent using the Protected Contact Verification Signal frame. If false, the request is sent using the Contact Verification Signal frame. ContactVerificationSignal Contact Verification As defined in Specifies the service parameters for Signal element 9.6.8.27 the Contact Verification Signal frame. 6.3.99.2.3 When generated This primitive is generated by the SME to request that a Protected Contact Verification Signal frame be sent by a STA to a specified peer MAC entity. 6.3.99.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a Protected Contact Verification Signal frame. This frame is then scheduled for transmission. 6.3.99.3 MLME-CVS.indication 6.3.99.3.1 Function This primitive indicates that a Contact Verification Signal frame was received from a specific peer MAC entity. 6.3.99.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-CVS.indication ( PeerSTAAddress, Protected, ContactVerificationSignal ) Name Type Valid range Description PeerSTAAddress MAC Address Any valid The address of the peer MAC entity individual MAC from which a Contact Verification Address Signal frame was received. Protected Boolean true, false Specifies whether the request is sent using a robust Management frame. If true, the request is sent using the Protected Contact Verification Signal frame. If false, the request is sent using the Contact Verification Signal frame. ContactVerificationSignal Contact Verification As defined in Specifies the service parameters for Signal element 9.6.8.27 the Contact Verification Signal frame. 580 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.99.3.3 When generated This primitive is generated by the MLME when a valid Protected Contact Verification Signal frame is received. 6.3.99.3.4 Effect of receipt On receipt of this primitive, the SME is notified of the receipt of the Contact Verification Signal frame. 6.3.100 GDD Enablement 6.3.100.1 Introduction The following MLME primitives support the signaling of GDD enablement. 6.3.100.2 MLME-GDDENABLEMENT.request 6.3.100.2.1 Function This primitive requests that a (Protected) GDD Enablement Request frame be sent to a peer entity. 6.3.100.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-GDDENABLEMENT.request ( PeerSTAAddress, DialogToken, Protected, DeviceClass, DeviceID ) Name Type Valid range Description PeerSTAAddress MAC address Any individual valid Specifies the address of the peer MAC MAC address entity with which to perform the GDD enablement process. DialogToken Integer 1â€“255 The dialog token to identify the event transaction. Protected Boolean true, false Specifies whether the request is sent using a robust Management frame. If true, the request is sent using the Protected GDD Enablement Request frame. If false, the request is sent using the GDD Enablement Request frame. DeviceClass DeviceClass As defined in 9.4.4.2.1 Specifies the service parameters for the GDD Enablement Request frame. DeviceID Device As defined in 9.4.4.2.2 Specifies the service parameters for the Identification GDD Enablement Request frame. Information 6.3.100.2.3 When generated This primitive is generated by the SME to request that a (Protected) GDD Enablement Request frame be sent to the peer entity. 581 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.100.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a (Protected) GDD Enablement Request frame. This frame is then scheduled for transmission. 6.3.100.3 MLME-GDDENABLEMENT.confirm 6.3.100.3.1 Function This primitive reports the result of an MLME-GDDENABLEMENT.request primitive to initiate GDD enablement. 6.3.100.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-GDDENABLEMENT.confirm ( PeerSTAAddress, DialogToken, Protected, ResultCode, WSM ) Name Type Valid range Description PeerSTAAddress MAC address Any individual valid MAC Specifies the address of the peer MAC address entity with which to perform the GDD enablement process. DialogToken Integer 1â€“255 The dialog token to identify the event transaction. Protected Boolean true, false Specifies whether the response is sent using a robust Management frame. If true, the response is sent using the Protected GDD Enablement Response frame. If false, the response is sent using the GDD Enablement Response frame. ResultCode Enumeration SUCCESS, REFUSED, Indicates the result response to the GDD ENABLEMENT DENIED, Enablement Request frame from the peer ENABLEMENT Denied due entity. to restriction from GDB WSM WSM element As defined in 9.4.1.57 Specifies the service parameters for the white space map. 6.3.100.3.3 When generated This primitive is generated by the MLME as a result of an MLME-GDDENABLEMENT.request primitive and indicates the results of the request. This primitive is generated when the STA successfully receives a GDD Enablement Response frame from the peer entity or when an unspecified failure occurs. 6.3.100.3.4 Effect of receipt On receipt of this primitive, the SME evaluates the results of the MLME-GDDENABLEMENT.request primitive and may use the reported data. 582 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.100.4 MLME-GDDENABLEMENT.indication 6.3.100.4.1 Function This primitive indicates that a (Protected) GDD Enablement Request frame was received from a peer entity. 6.3.100.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-GDDENABLEMENT.indication ( PeerSTAAddress, DialogToken, Protected, DeviceClass, DeviceID ) Name Type Valid range Description PeerSTAAddress MAC address Any individual valid The address of the peer entity from which a MAC address GDD Enablement Request frame was received. DialogToken Integer 1â€“255 The dialog token to identify the event transaction. Protected Boolean true, false Specifies whether the request is sent using a robust Management frame. If true, the request is sent using the Protected GDD Enablement Request frame. If false, the request is sent using the GDD Enablement Request frame. DeviceClass DeviceClass As defined in 9.4.4.2.1 Specifies the service parameters for the GDD Enablement Request frame. DeviceID Device As defined in 9.4.4.2.2 Specifies the service parameters for the Identification GDD Enablement Request frame. Information 6.3.100.4.3 When generated This primitive is generated by the MLME when a valid (Protected) GDD Enablement Request frame is received. 6.3.100.4.4 Effect of receipt On receipt of this primitive, the SME operates according to the procedure in 11.44.1. 6.3.100.5 MLME-GDDENABLEMENT.response 6.3.100.5.1 Function This primitive indicates that a (Protected) GDD Enablement Response frame be sent to the peer entity. 6.3.100.5.2 Semantics of the service primitive MLME-GDDENABLEMENT.response ( PeerSTAAddress, DialogToken, 583 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Protected, ResultCode, WSM ) Name Type Valid range Description PeerSTAAddress MAC address Any individual valid MAC The address of the peer entity from which a address GDD Enablement Request frame was received. DialogToken Integer 1â€“255 The dialog token to identify the event transaction. Protected Boolean true, false Specifies whether the response is sent using a robust Management frame. If true, the response is sent using the Protected GDD Enablement Response frame. If false, the response is sent using the GDD Enablement Response frame. ResultCode Enumeration SUCCESS, REFUSED, Indicates the result response to the GDD ENABLEMENT DENIED, Enablement Request frame from the peer ENABLEMENT Denied due entity. to restriction from GDB WSM WSM element As defined in 9.4.1.57 Specifies the service parameters for the white space map. 6.3.100.5.3 When generated This primitive is generated by the SME to request that a GDD Enablement Response frame be sent to the peer entity. 6.3.100.5.4 Effect of receipt On receipt of this primitive, the MLME constructs a GDD Enablement Response frame. This frame is then scheduled for transmission. 6.3.101 Network channel control management 6.3.101.1 Introduction The following MLME primitives support the signaling of network channel control management. 6.3.101.2 MLME-NETWORKCHANNELCONTROL.request 6.3.101.2.1 Function This primitive requests that a (Protected) Network Channel Control Public Action frame be sent by a STA to a specified peer MAC entity. 6.3.101.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-NETWORKCHANNELCONTROL.request ( PeerSTAAddress, DialogToken, NetworkChannelControl, 584 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Protected, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MAC Address Any valid individual or The address of the peer MAC group MAC Address entity to which the Network Channel Control frame is transmitted. DialogToken Integer 0â€“255 The dialog token to identify the network channel control transaction. NetworkChannelCon A set of information As defined in 9.6.8.30 Specifies the parameters of trol subfields network channel control. Protected Boolean true, false Specifies whether the request is sent using a robust Management frame. If true, the request is sent using the Protected Network Channel Control frame. If false, the request is sent using the Network Channel Control frame. VendorSpecificInfo A set of vendor As defined in 9.4.2.26 Zero or more elements. specific elements 6.3.101.2.3 When generated This primitive is generated by the SME to request that a (Protected) Network Channel Control Public Action frame be sent by a STA to the specified peer MAC entity. 6.3.101.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a (Protected) Network Channel Control Public Action frame. This frame is then scheduled for transmission. 6.3.101.3 MLME-NETWORKCHANNELCONTROL.confirm 6.3.101.3.1 Function This primitive reports the result of a request to network channel control. 6.3.101.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-NETWORKCHANNELCONTROL.confirm ( PeerSTAAddress, DialogToken, NetworkChannelControl, Protected, VendorSpecificInfo ) 585 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description PeerSTAAddress MAC Address Any valid individual MAC The address of the peer MAC entity address from which the response in a Network Channel Control frame is received. DialogToken Integer 0â€“255 The dialog token to identify the network channel control transaction. NetworkChannelC A set of As defined in 9.6.8.30 Specifies the parameters of network ontrol information channel control. subfields Protected Boolean true, false Specifies whether the response is sent using a robust Management frame. If true, the response is sent using the Protected Network Channel Control Public Action frame. If false, the response is sent using the Network Channel Control Public Action frame. VendorSpecificInfo A set of vendor As defined in 9.4.2.26 Zero or more elements. specific elements 6.3.101.3.3 When generated This primitive is generated by the MLME when a network channel control request completes. Possible unspecified failure causes include an inability to schedule a Network Channel Control Public Action frame. 6.3.101.3.4 Effect of receipt The SME is notified of the results of the network channel control procedure. 6.3.101.4 MLME-NETWORKCHANNELCONTROL.indication 6.3.101.4.1 Function This primitive indicates that a (Protected) Network Channel Control Public Action frame was received from a STA. 6.3.101.4.2 Semantics of the service primitive The primitive parameters are as follows: MLME-NETWORKCHANNELCONTROL.indication ( PeerSTAAddress, DialogToken, NetworkChannelControl, Protected, VendorSpecificInfo ) 586 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description PeerSTAAddress MAC address Any valid individual The address of the peer MAC entity from MAC address which the Network Channel Control frame was received. DialogToken Integer 0â€“255 The dialog token to identify the network channel control transaction. NetworkChannelC A set of As defined in 9.6.8.30 Specifies the parameters of network channel ontrol information control. subfields Protected Boolean true, false Specifies whether the request was received using a robust Management frame. If true, the request was received using the Protected Network Channel Control Public Action frame. If false, the request was received using the Network Channel Control Public Action frame. VendorSpecificInfo A set of vendor As defined in 9.4.2.26 Zero or more elements. specific elements 6.3.101.4.3 When generated This primitive is generated by the MLME when a valid (Protected) Network Channel Control Public Action frame is received. 6.3.101.4.4 Effect of receipt On receipt of this primitive, the SME decides whether to accept the network channel control request. 6.3.101.5 MLME-NETWORKCHANNELCONTROL.response 6.3.101.5.1 Function This primitive is generated by the SME to schedule the transmission of a network channel control response. 6.3.101.5.2 Semantics of the service primitive The primitive parameters are as follows: MLME-NETWORKCHANNELCONTROL.response ( PeerSTAAddress, DialogToken, NetworkChannelControl, Protected, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MAC Address Any valid individual or The address of the peer MAC group MAC address entity to which the response in a Network Channel Control frame is transmitted. DialogToken Integer 0â€“255 The dialog token to identify the network channel control transaction. 587 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description NetworkChannelCo A set of information As defined in 9.6.8.30 Specifies the parameters of ntrol subfields network channel control. Protected Boolean true, false Specifies whether the response is sent using a robust Management frame. If true, the response is sent using the Protected Network Channel Control Public Action frame. If false, the response is sent using the Network Channel Control Public Action frame. VendorSpecificInfo A set of vendor specific As defined in 9.4.2.26 Zero or more elements. elements 6.3.101.5.3 When generated This primitive is generated by the SME to request that a network channel control response be sent to the peer entity. 6.3.101.5.4 Effect of receipt On receipt of this primitive, the MLME schedules the response to the specific peer MAC entity that has requested a network channel control response. 6.3.102 White space map (WSM) 6.3.102.1 Introduction The following MLME primitives support the signaling of the WSM. 6.3.102.2 MLME-WSM.request 6.3.102.2.1 Function This primitive requests that a White Space Map Announcement frame be sent by a GDD enabling STA in order to provide a WSM to a GDD dependent STA. 6.3.102.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-WSM.request ( PeerSTAAddress, WhiteSpaceMap ) Name Type Valid range Description PeerSTAAddress MAC Address Any valid individual Specifies the address of the peer MAC MAC Address entity with which to perform the WSM process. WhiteSpaceMap White Space Map As defined in 9.4.2.170 Specifies the service parameters for the element WSM. 588 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.102.2.3 When generated This primitive is generated by the SME to request that a White Space Map Announcement frame be sent by a GDD enabling STA to a specified peer MAC entity. 6.3.102.2.4 Effect of receipt On receipt of this primitive, the MLME constructs a White Space Map Announcement frame. This frame is then scheduled for transmission. 6.3.102.3 MLME-WSM.indication 6.3.102.3.1 Function This primitive indicates receipt of a request of a White Space Map Announcement frame. 6.3.102.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-WSM.indication ( PeerSTAAddress, WhiteSpaceMap ) Name Type Valid range Description PeerSTAAddress MAC Address Any valid individual MAC The address of the peer MAC Address entity from which a WSM was received. WhiteSpaceMap White Space Map As defined in 9.4.2.170 Specifies the service parameters element for the WSM. 6.3.102.3.3 When generated This primitive is generated by the MLME when a valid White Space Map Announcement frame is received. 6.3.102.3.4 Effect of receipt On receipt of this primitive, the SME is notified of the receipt of White Space Map Announcement frame. 6.3.103 Estimated Throughput (ESTT) 6.3.103.1 General The following set of MLME primitives support the transport of an estimate of the achievable throughput for a potential or an existing link between two STAs. 6.3.103.2 MLME-ESTIMATED-THROUGHPUT.request 6.3.103.2.1 Function This primitive is generated by the SME to request that the MLME provide an estimated throughput for a potential or existing association. 589 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.103.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-ESTIMATED-THROUGHPUT.request ( PeerSTAAddress, AverageMSDUSizeOutbound, AverageMSDUSizeInbound ) Name Type Valid range Description PeerSTAAddress MAC Address Any valid individual MAC Specifies the MAC address of the Address STA for which throughput is to be estimated assuming an association to that STA if an association with that STA does not currently exist. AverageMSDUSizeI An ordered set of â€“1 to 7920, for each member of A set of integers providing an nbound integers the set estimate of the average number of octets per MSDU expected to be delivered to the wireless medium to this STA by the STA corresponding to the PeerMACAddress to this STA, specified per access category in the order AC_VO, AC_VI, AC_BE, AC_BK. A value of â€“1 means that the size is unspecified, a value of 0 means that no MSDUs are expected to be delivered for this access category. AverageMSDUSizeO An ordered set of â€“1 to 7920, for each member of A set of integers providing an utbound integers the set estimate of the average number of octets per MSDU expected to be delivered to the wireless medium by this STA to the STA corresponding to the PeerMACAddress, specified per access category in the order AC_VO, AC_VI, AC_BE, AC_BK. A value of â€“1 means that the size is unspecified, a value of 0 means that no MSDUs are expected to be delivered for this access category. 6.3.103.2.3 When generated This primitive is generated by the SME to request that the MLME provide an estimate of throughput for MSDUs sent between this STA and the STA which corresponds to the PeerMACAddress provided in the parameter list. 6.3.103.2.4 Effect of receipt On receipt of this primitive, the MLME generates a set of estimates of throughput for MSDUs sent between the STA which corresponds to the PeerMACAddress provided in the parameter list and this STA. 590 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.103.3 MLME-ESTIMATED-THROUGHPUT.confirm 6.3.103.3.1 Function This primitive reports the result of a request to provide a set of estimated throughput values for a potential or existing link. 6.3.103.3.2 Semantics of the service primitive The primitive uses the following parameters: MLME-ESTIMATED-THROUGHPUT.confirm ( PeerSTAAddress, EstimatedThroughputOutbound, EstimatedThroughputInbound ) Name Type Valid range Description PeerSTAAddress MAC Address Any valid individual MAC Specifies the MAC address of the Address STA for which throughput is to be estimated assuming a link with that STA if a link with that STA does not currently exist. EstimatedThrough An ordered set of Non-negative real numbers The estimated throughput in the putOutbound Real Numbers direction from the STA corresponding to the PeerMACAddress to this STA with units of MSDU bits per second, specified per access category in the order AC_VO, AC_VI, AC_BE, AC_BK. A value of 0 means no estimate is available. EstimatedThrough An ordered set of Non-negative real numbers The estimated throughput in the putInbound Real Numbers direction from this STA to the STA corresponding to the PeerMACAddress with units of MSDU bits per second, specified per access category in the order AC_VO, AC_VI, AC_BE, AC_BK. A value of 0 means no estimate is available. 6.3.103.3.3 When generated This primitive is generated by the MLME to provide a set of estimates of throughput for MSDUs sent between the STA which corresponds to the PeerMACAddress indicated in the parameter list and this STA. 6.3.103.3.4 Effect of receipt On receipt of this primitive, the SME may use the reported estimates to make link, association and forwarding decisions. 6.3.104 Get authentication/association state 6.3.104.1 General This mechanism is used to obtain authentication/association state. 591 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.104.2 MLME-GETAUTHASSOCSTATE.request 6.3.104.2.1 Function This primitive is generated by the SME to request that the MLME return the authentication/association state with respect to a given peer STA. 6.3.104.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-GETAUTHASSOCSTATE.request ( PeerSTAAddress, ) Name Type Valid range Description PeerSTAAddress MAC Address Any valid individual MAC Specifies the address of the peer address MAC entity whose authentication/ association state is requested 6.3.104.2.3 When generated This primitive is generated by the SME to request the authentication/association state from the MLME. 6.3.104.2.4 Effect of receipt The MLME issues an MLME-GETAUTHASSOCSTATE.confirm primitive. 6.3.104.3 MLME-GETAUTHASSOCSTATE.confirm 6.3.104.3.1 Function This primitive is generated by the MLME to report to the SME the result of a request to get the authentication/association state. 6.3.104.3.2 Semantics of the service primitive The primitive parameters are as follows: MLME-GETAUTHASSOCSTATE.confirm ( PeerSTAAddress, AuthAssocState ) Name Type Valid range Description PeerSTAAddress MAC Address Any valid individual MAC Specifies the address of the peer address MAC entity whose authentication/ association state was requested AuthAssocState Integer 1-4 See 11.3.1 and 14.3.2 6.3.104.3.3 When generated This primitive is generated by the MLME to report the authentication/association state to the SME. 592 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.3.104.3.4 Effect of receipt The SME is notified of the result of an MLME-GETAUTHASSOCSTATR.request primitive. 6.4 MAC state generic convergence function (MSGCF) 6.4.1 Overview of the convergence function The MSGCF provides an abstraction of a link between a non-AP STA and an ESS (an ESS-link) to its higher layer entity. The MSGCF provides control of an ESS-link and generates events based on the state of an ESS- link. A non-AP STA that transitions between two APs in the same ESS can operate transparently to the LLC sublayer, and does not change state in the state machine defined within 6.4. This clause defines interactions between the MSGCF and MLME and PLME through the MLME SAP and PLME SAP respectively, as well as with the SME via the MSGCF-SME SAP. The detailed manner in which the SAPs are implemented is not specified within this standard. 6.4.2 Overview of convergence function state machine The convergence function maintains information on the state of the ESS, using the state machine shown in Figure 6-29. Because Figure 6-29 is defined in terms of ESS connectivity, it is not affected by changes in association provided that the transition was an intra-ESS transition. ESS_CONNECTED MSGCF-ESS-LINK-DOWN.indication MSGCF-ESS-LINK-UP.indication ESS_DISENGAGING ESS_DISCONNECTED STANDBY Figure 6-29â€”MSGCF state machine 593 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.4.3 Convergence function state list 6.4.3.1 ESS_CONNECTED In the ESS_CONNECTED state, a non-AP STA has completed all layer 2 setup activities and is able to send Class 3 frames to peer LLC entities. A non-AP STA remains in this state as long as it is possible to send Class 3 frames through any AP within an ESS. A non-AP STA does not leave this state upon successful intra- ESS transitions. 6.4.3.2 ESS_DISCONNECTED In the ESS_DISCONNECTED state, a non-AP STA is unable to send Class 3 frames to peer LLC entities. Higher layer network protocols are unavailable. In this state, a non-AP STA may use GAS to perform network discovery and selection. 6.4.3.3 ESS_DISENGAGING In the ESS_DISENGAGING state, the non-AP STAâ€™s SME anticipates that links to all APs within the ESS will be lost in a defined time interval, but the non-AP STA is still able to send Class 3 frames to peer LLC entities. The predictive failure of the link might be due to explicit disassociation by the peer, the imminent invalidation of cryptographic keys because of usage limits (such as sequence counter exhaustion), or predictive signal strength algorithms. In this state, it is recommended that a non-AP STA also initiate a search to find a new ESS. 6.4.3.4 STANDBY In the STANDBY state, the non-AP STA is powered down and unable to communicate with any other STAs. 6.4.4 Convergence function state transitions 6.4.4.1 Transitions to ESS_CONNECTED 6.4.4.1.1 From ESS_DISCONNECTED To make this transition, a non-AP STA will have completed the network selection process and the relevant procedures to attach to the ESS, including IEEE 802.11 authentication, IEEE 802.11 association, and, if required, IEEE 802.11 RSN procedures. When this transition is completed, the MSGCF sends an MSGCF- ESS-LINK-UP.indication primitive to higher layers. 6.4.4.1.2 From ESS_DISENGAGING To make this transition, the SME cancels a previous event that predicted an ESS link failure. This might be due to network parameters indicating renewed link strength or a successful renewal of an expiring RSN SA. When this transition is complete, the MSGCF sends an MSGCF-ESS-LINK-EVENT- ROLLBACK.indication primitive to indicate that a prior link failure predictive event is no longer valid. If the transition was due to network parameters crossing a threshold, the MSGCF also sends an MSGCF-ESS- LINK-THRESHOLD-REPORT.indication primitive to higher layers. 594 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.4.4.2 Transitions to ESS_ DISCONNECTED 6.4.4.2.1 From ESS_CONNECTED This transition indicates that administrative action was taken to shut down the link, a sudden loss of signal strength or that RSN keys expired and could not be renewed. At the conclusion of this transition, the MSGCF sends an MSGCF-ESS-LINK-DOWN.indication primitive to higher layer protocols. 6.4.4.2.2 From ESS_DISENGAGING This transition indicates that the predictive link failure event has occurred. At the conclusion of this transition, the MSGCF issues an MSGCF-ESS-LINK-DOWN.indication primitive to higher layer protocols. 6.4.4.2.3 From STANDBY This transition occurs when the non-AP STA is powered on and initialized. No event is issued by the MSGCF. 6.4.4.3 Transitions to ESS_DISENGAGING 6.4.4.3.1 From ESS_CONNECTED When the parameters as defined in Table 6-7 change or imminent action is taken to bring down the link, the SME may predict an imminent link failure and initiate a transition. Upon completion of this transition, the MSGCF issues an MSGCF-ESS-LINK-GOING-DOWN event. If the cause of the transition was the degradation of network parameters beyond the thresholds stored in the MIB, an MSGCF-ESS-LINK- THRESHOLD-REPORT.indication primitive is also issued to higher layers. 6.4.4.4 Transitions to STANDBY 6.4.4.4.1 From ESS_DISCONNECTED When the non-AP STA has disconnected from an ESS, it may be administratively powered off to extend battery life. No events are issued by the MSGCF upon completion of this transition. 6.4.5 Convergence function informational events Informational events may occur in any state. When they occur, the SME updates the convergence function MIB with new parameters. Informational events do not cause state changes in Figure 6-29. Informational events are generated when new potential ESS links are discovered, when the network parameter thresholds are set or read, and when higher layer protocols issue commands to the non-AP STA through the MSGCF- ESS-LINK-COMMAND.request primitive. 6.4.6 MAC state generic convergence SAP The MAC state generic convergence SAP is the interface between the convergence function and higher layer protocols. It presents a standardized interface for higher layer protocols to access the state of the MAC, whether that state information is available in the MLME, PLME, or SME. Some events on the MAC state generic convergence SAP require event identifiers for use as a dialog token in event sequencing and rollback. The EventID is an unsigned integer that is initialized to 1 when the non-AP STA leaves the STANDBY state. 595 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.4.7 ESS status reporting 6.4.7.1 MSGCF-ESS-LINK-UP.indication 6.4.7.1.1 Function This event is triggered when a new ESS has been made available for sending frames. 6.4.7.1.2 Semantics of the service primitive The primitive parameters are as follows: MSGCF-ESS-LINK-UP.indication( ESSIdentifier ) Name Type Valid range Description ESSIdentifier String N/A An identifier composed of the string value of the SSID element concatenated with the value of the HESSID if it is in use. The HESSID is encoded in upper-case ASCII characters with the octet values separated by dash characters, as described in IETF RFC 3580 [B39]. 6.4.7.1.3 When generated This primitive is generated when the ESS link to a network of APs is available to exchange Data frames. The generation of this primitive may vary depending on the contents of dot11WEPDefaultKeysTable and dot11WEPKeyMappingsTable and the setting of dot11RSNAOptionImplemented. If there are no entries in the dot11WEPDefaultKeysTable, no entry for the current AP in dot11WEPKeyMappingsTable, and dot11RSNAOptionImplemented is false, then the network does not use encryption. This event is generated upon receipt of an MLME-ASSOCIATE.confirm primitive with a result code of success. If there are entries in the dot11WEPDefaultKeysTable, or an entry for the current AP in dot11WEPKeyMappingsTable, or dot11RSNAOptionImplemented is true, then the network requires the use of encryption on the link. Before declaring that the link is ready to exchange Data frames, the convergence function receives an MLME-ASSOCIATE.confirm primitive with a result code of success and the SME emits an MLME-SETKEYS.request primitive. The latter primitive is used to determine that a WEP key is available, or that the RSN 4-way handshake has completed. This event is not triggered by MLME-REASSOCIATE.confirm primitives because MLME- REASSOCIATE.confirm primitives are defined as transitions within the same ESS. The MLME-ASSOCIATE.confirm primitive may be issued upon AP transitions. It is the objective of the MSGCF to generate this event only upon the initial connection to an IEEE 802.11 network, when the MSGCF state machine moves into the ESS_CONNECTED state. 6.4.7.1.4 Effect of receipt This event is made available to higher layer protocols by the convergence function. Actions taken by higher layers are outside of scope of this standard, but may include router discovery, IP configuration, and other higher layer protocol operations. 596 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.4.7.2 MSGCF-ESS-LINK-DOWN.indication 6.4.7.2.1 Function This event is triggered to indicate that the connection to an ESS is no longer available for sending frames. 6.4.7.2.2 Semantics of the service primitive The eventâ€™s parameters are as follows: MSGCF-ESS-LINK-DOWN.indication ( ESSIdentifier, ReasonCode ) Name Type Valid range Description ESSIdentifier String N/A An identifier composed of the string value of the SSID element concatenated with the value of the HESSID if it is in use. ReasonCode Enumerated EXPLICT_DISCONNECT, Reason code, drawn from Table 6-2. KEY_EXPIRATION, LOW_POWER, VENDOR_SPECIFIC Table 6-2â€”Reason codes for network down Name Description EXPLICIT_DISCONNECT An explicit disconnection operation (disassociation or deauthentication) was initiated by the non-AP STA or the non-AP STAâ€™s current serving AP (the AP with which the STA is associated) and the non-AP STA was unable to (re)associate with an alternate AP in the same ESS. KEY_EXPIRATION Keys used by an RSN SA have expired due to time or traffic limitations, or TKIP countermeasures have invalidated the key hierarchy. LOW_POWER If the SME reports that the interface was shut down to conserve power, that event may be reported to higher level protocols. VENDOR_SPECIFIC Vendor-specific usage. 6.4.7.2.3 When generated This event is generated when the SME declares that connectivity to an ESS is lost. It may be generated in the case of an explicit disconnection from the link peer, received as an MLME-DEAUTHENTICATE.indication or an MLME-DISASSOCIATE.indication primitive. The SME should wait for a period of dot11ESSDisconnectFilterInterval before declaring connectivity lost to confirm that a non-AP STA is unable to (re)associate with any alternate AP within the ESS. 6.4.7.2.4 Effect of receipt This event is made available to higher layer protocols by the convergence function. Actions taken by those higher layers are outside the scope of this standard, but may include removing entries from routing and forwarding tables, and attempting to initiate handover of open application connections to network interfaces that are still active. 597 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.4.7.3 MSGCF-ESS-LINK-GOING-DOWN.indication 6.4.7.3.1 Function This event is triggered to indicate the expectation that the connection to an ESS will no longer be available for sending frames in the near future. 6.4.7.3.2 Semantics of the service primitive The event parameters are as follows: MSGCF-ESS-LINK-GOING-DOWN.indication( ESSIdentifier, EventID, TimeInterval, ReasonCode ) Name Type Valid range Description ESSIdentifier String N/A An identifier composed of the string value of the SSID element concatenated with the value of the HESSID if it is in use. EventID Integer N/A An integer used to identify the event that is used in the case of event rollback. TimeInterval Integer N/A Time Interval, in time units, in which the link is expected to go down. Connectivity is expected to be available at least for time specified by TimeInterval. Reason Code Enumerated EXPLICT_DISCONNECT, Indicates the reason the link is expected to go KEY_EXPIRATION, down, drawn from Table 6-3. LOW_POWER, VENDOR_ SPECIFIC Table 6-3â€”Reason codes for ESS link down Name Description EXPLICIT_DISCONNECT An explicit disconnection operation (Disassociation or Deauthentication) was initiated by the non-AP STA or the non-AP STAâ€™s current serving AP. KEY_EXPIRATION Keys used by an RSN SA have expired due to time or traffic limitations, or TKIP countermeasures have invalidated the key hierarchy. LOW_POWER If the SME reports that the interface is going to be shut down to conserve power, that event may be reported to higher level protocols. VENDOR_SPECIFIC Vendor-specific usage. 598 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.4.7.3.3 When generated This notification is generated by the MSGCF when the ESS link is currently established and is expected to go down within the specified time interval. The network can be expected to go down because of an event whose timing is well understood, such as an explicit disconnection event observed on the MLME SAP. It can also be expected as the result of a predictive algorithm that monitors link quality. The details of such a predictive algorithm used are beyond the scope of this standard. The convergence function should attempt to deliver this event at least dot11ESSLinkDownTimeInterval time units before the link is predicted to go down. Different higher layer network protocols might need different levels of advance notice, and might configure dot11ESSLinkDownTimeInterval accordingly. Not all thresholds in the dot11MACStateParameterTable are supported by every PHY. In the case when a threshold parameter is not supported it is not applied. 6.4.7.3.4 Effect of receipt This event is made available to higher layer protocols by the convergence function. Actions taken by those higher layers are outside the scope of this standard, but may include beginning preparations for handover. 6.4.7.4 MSGCF-ESS-LINK-EVENT-ROLLBACK.indication 6.4.7.4.1 Function This event is used to indicate that specific previous reports or events are no longer valid and should be disregarded. 6.4.7.4.2 Semantics of the service primitive The event parameters are as follows: MSGCF-ESS-LINK-EVENT-ROLLBACK.indication( ESSIdentifier, EventID ) Name Type Valid range Description ESSIdentifier String N/A An identifier for the network, composed of the string value of the SSID element used to identify the network, concatenated with the value of the HESSID if it is in use. EventID Integer N/A An integer used to identify the event that is used in the case of event rollback. 6.4.7.4.3 When generated This event is generated when a previous predictive event is no longer valid within its expiration time. The MSGCF-ESS-LINK-EVENT-ROLLBACK.indication primitive is used in conjunction with the MSGCF-ESS-LINK-GOING-DOWN.indication primitive. The MSGCF-ESS-LINK-EVENT- ROLLBACK.indication primitive is issued when the prediction of link failure is no longer valid. Algorithms used to determine that link failure predictions are beyond the scope of this standard. 599 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.4.7.4.4 Effect of receipt This event is made available to higher layer protocols by the convergence function to cancel any actions begun by the previous event. Actions taken by those higher layers are outside the scope of this standard, but may include canceling any handover procedures started by the MSGCF-ESS-LINK-GOING-DOWN event. 6.4.7.5 MSGCF-ESS-LINK-DETECTED.indication 6.4.7.5.1 Function This event reports on the presence of a new ESS. 6.4.7.5.2 Semantics of the service primitive The primitive parameters are as follows: MSGCF-ESS-LINK-DETECTED.indication( ESSIdentifier, ESSDescription ) Name Type Valid range Description ESSIdentifier String N/A An identifier for the network, composed of the string value of the SSID used to identify the network, concatenated with the value of the HESSID if it is in use. ESSDescription As defined in N/A A set of information about the ESS. Table 6-4 Table 6-4â€”ESS description Name Syntax Description SSID String The SSID used by the ESS. InformationServic As described in Table 6-5 A set of values indicating the type of information eSupport services supported on this network. TriggerSupport As described in Table 6-5 A set of values indicating the support for the types of triggers that can be used to propose that the station take action. RSN As defined in 9.4.2.25 The RSN configuration of the ESS. Interworking As defined in 9.4.2.92 Interworking configuration of the ESS. Table 6-5â€”Trigger support values Name Description MIH_CS_ES_Support This network supports the IEEE 802.21 MIH Command Service and Event Service. Vendor_Specific_Trigger_Support This network supports a vendor-specific trigger service. 600 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.4.7.5.3 When generated Support for MIH is indicated by the presence or absence of the relevant Advertisement Protocol IDs in the Advertisement Protocol element.To maintain the list of detected networks, the SME issues recurring MLME- SCAN.request primitives to the MLME. The SME may schedule these requests to avoid interruption of user traffic. Responses to these requests, received in the MLME-SCAN.confirm primitives, contain a list of detected networks. Each network is stored in dot11MACStateESSLinkDetectedTable. This table holds a list of networks, organized by Network Identifier. Each entry in the table contains a list of BSSIDs within the network, as well as indications of support for MIH. Support for MIH is indicated by the presence or absence of the relevant Advertisement Protocol IDs in the Advertisement Protocol element. Each entry in the table is held for at least dot11ESSLinkDetectionHoldInterval time units. When a non-AP STA has not observed an ESS for longer than dot11ESSLinkDetectionHoldInterval, it may be removed from the table. This event is generated when a new entry is made into the dot11MACStateESSLinkDetectedTable. Modifications to existing entries in the list, such as an update to the BSSID list, do not trigger this event. 6.4.7.5.4 Effect of receipt This event is made available to higher layer protocols by the convergence function. Actions taken by those higher layers are outside the scope of this standard. 6.4.7.6 MSGCF-ESS-LINK-SCAN.request 6.4.7.6.1 Function This function is used by higher layer protocols to request that the SME perform a scan operation for available ESSs. 6.4.7.6.2 Semantics of the service primitive The primitive parameters are as follows: MSGCF-ESS-LINK-SCAN.request( SSID, HESSID, AccessNetworkType ) Name Type Valid range Description SSID Octet string 0â€“32 octets Specific or wildcard. HESSID As defined in As defined in The HESSID to search for. It can be set to all 1s 9.4.2.92 9.4.2.92 for use as a wildcard to match all available HESSID values. AccessNetworkType As defined in As defined in This may be a specific value to match one type of 9.4.2.92 9.4.2.92 networks, or all 1s to match all access network types. 6.4.7.6.3 When generated This request is generated when higher protocol layers request a list of available ESSs. 6.4.7.6.4 Effect of receipt The SME generates a corresponding MLME-SCAN.request primitive to find available networks. 601 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.4.7.7 MSGCF-ESS-LINK-SCAN.confirm 6.4.7.7.1 Function This function reports information on available ESSs to higher protocol layers. 6.4.7.7.2 Semantics of the service primitive The primitive parameters are as follows: MSGCF-ESS-LINK-SCAN.confirm( ESSIdentifiers, ESSDescriptions ) Name Type Valid range Description ESSIdentifiers Set of Strings N/A An identifier for the network composed of the string value of the SSID used to identify the network, concatenated with the value of the HESSID if it is in use. ESSDescriptions Set of N/A A set of information about each discovered ESS. ESSDescriptions, as defined in Table 6-4 6.4.7.7.3 When generated This primitive is generated when scan results are available for reporting to higher protocol layers, in response to an MSGCF-ESS-LINK-SCAN.request primitive. 6.4.7.7.4 Effect of receipt This event is made available to higher layer protocols by the convergence function. Actions taken by those higher layers are outside the scope of this standard. 6.4.8 Network configuration 6.4.8.1 MSGCF-ESS-LINK-CAPABILITY.request 6.4.8.1.1 Function This primitive requests a list of the capabilities supported by a network. 6.4.8.1.2 Semantics of the service primitive The primitive parameters are as follows: MSGCF-ESS-LINK-CAPABILITY.request( ESSIdentifier ) Name Type Valid range Description ESSIdentifier String N/A An identifier for the network, composed of the string value of the SSID element used to identify the network, concatenated with the value of the HESSID if it is in use. 602 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.4.8.1.3 When generated This primitive is issued to service higher layer protocols by reporting on the capabilities of a particular network. 6.4.8.1.4 Effect of receipt The convergence function retrieves the capabilities and reports them via the MSGCF-ESS-LINK- CAPABILITY.confirm primitive. 6.4.8.2 MSGCF-ESS-LINK-CAPABILITY.confirm 6.4.8.2.1 Function This primitive reports the convergence function capabilities of the network to higher layer protocols. 6.4.8.2.2 Semantics of the service primitive The primitive parameters are as follows: MSGCF-ESS-LINK-CAPABILITY.confirm( ESSIdentifier, EssLinkParameterSet, ReasonCode ) Name Type Valid range Description ESSIdentifier String N/A An identifier for the network, composed of the string value of the SSID element used to identify the network, concatenated with the value of the HESSID if it is in use. EventCapability As defined in N/A list of supported events. Set Table 6-6 ReasonCode Enumerated SUCCESS, An error code, if applicable. UNKNOWN_NETWORK, UNKNOWN_CAPABILITIES Table 6-6â€”Event Capability Set Name Type Valid range Description NonAPSTAMacAddress MacAddress Any valid The MAC address of the non-AP STA that individual MAC is reporting the new network. Address ESS-Link-Up Boolean true, false Indicates whether the MSGCF-ESS-LINK- UP.indication primitive as defined in 6.4.7.1 is supported. ESS-Link-Down Boolean true, false Indicates whether the MSGCF-ESS-LINK- DOWN.indication primitive as defined in 6.4.7.2 is supported. ESS-Link-Going-Down Boolean true, false Indicates whether the MSGCF-ESS-LINK- GOING-DOWN primitive as defined in 6.4.7.3 is supported. 603 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 6-6â€”Event Capability Set (continued) Name Type Valid range Description ESS-Link-Event- Boolean true, false Indicates whether the MSGCF-ESS-LINK- Rollback EVENT-ROLLBACK.indication primitive as defined in 6.4.7.4 is supported. ESS-Link-Detected Boolean true, false Indicates whether the MSGCF-ESS-LINK- DETECTED.indication primitive as defined in 6.4.7.5 is supported. ESS-Link-Threshold- Boolean true, false Indicates whether the MSGCF-ESS-LINK- Report THRESHOLD-REPORT.indication primitive as defined in 6.4.9.1 is supported. ESS-Link-Command Boolean true, false Indicates whether the MSGCF-ESS-LINK- COMMAND.request primitive as defined in 6.4.10.1 is supported. 6.4.8.2.3 When generated This primitive is generated in response to the MSGCF-ESS-LINK-CAPABILITY.request primitive to report whether specific events are supported. 6.4.8.2.4 Effect of receipt This event is made available to higher layer protocols by the convergence function. 6.4.8.3 MSGCF-ESS-LINK-PARAMETERS.request 6.4.8.3.1 Function This primitive sets thresholds for reporting of network events. 6.4.8.3.2 Semantics of the service primitive The primitive parameters are as follows: MSGCF-ESS-LINK-PARAMETERS.request( ESSIdentifier, EssLinkParameterSet ) Name Type Valid range Description ESSIdentifier String N/A An identifier for the network, composed of the string value of the SSID element used to identify the network, concatenated with the value of the HESSID if it is in use. ESSLinkParamete As defined in N/A The EssLinkParameterSet is used to configure rSet Table 6-7 when event reports are sent to higher protocol layers. The ESSLinkParameterSet parameter is defined in Table 6-7. It may include any or all of the parameters in Table 6-7. 604 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 6-7â€”ESS Link Parameter Set Name Type Valid range Description PeakOperationalRat Integer As defined in The integer representing the target peak e 9.4.2.3 modulation data rate used for Data frame transmission. MinimumOperation Integer As defined in The integer encoding of the target minimum alRate 9.4.2.3 modulation data rate used in Data frame transmission. NetworkDowntimeI Integer 0 â€“ 65 535 Target advance warning time interval, in TUs, for nterval MSGCF-ESS-LINK-GOING-DOWN events. DataFrameRSSI Integer â€“100 to 40 The received signal strength in dBm of received Data frames from the network. This may be time- averaged over recent history by a vendor-specific smoothing function. BeaconRSSI Integer â€“100 to 40 The received signal strength in dBm of Beacon frames received on the channel. This may be time- averaged over recent history by a vendor-specific smoothing function. BeaconSNR Integer 0â€“100 The signal-to-noise ratio of the received Data frames, in dB. This may be time-averaged over recent history by a vendor-specific smoothing function. DataFrameSNR Integer 0â€“100 The signal-to-noise ratio of the received Beacon frames, in dB. This may be time-averaged over recent history by a vendor-specific smoothing function. DataThroughput Integer 0 â€“ 65 535 The data throughput in megabits per second, rounded to the nearest megabit. This may be time- averaged over recent history by a vendor-specific smoothing function. MissedBeaconRate Real N/A The rate at which beacons have not been received in missed beacons per second. This may be time- averaged over recent history by a vendor-specific smoothing function. FrameErrorRate Real N/A The frame error rate of the network in errors per second. This may be time-averaged over recent history by a vendor-specific smoothing function. VendorSpecific Vendor As defined by Additional vendor-specific parameters may be Specific 9.4.2.26 included in this event. 6.4.8.3.3 When generated This event is generated when higher protocol layers wish to set the performance parameters for a network. Higher protocol layers are responsible for ensuring that the set of configured network parameters is consistent with all subscribers to those higher layer protocols. 6.4.8.3.4 Effect of receipt Parameters supplied in the event are stored in the MIB, either in the dot11MACStateConfigTable or the dot11MACStateParameterTable. 605 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.4.8.4 MSGCF-ESS-LINK-PARAMETERS.confirm 6.4.8.4.1 Function This primitive indicates whether network parameters were accepted. 6.4.8.4.2 Semantics of the service primitive The primitive parameters are as follows: MSGCF-ESS-LINK-PARAMETERS.confirm( ESSIdentifier, EssLinkParameterSet, ) Name Type Valid range Description ESSIdentifier String N/A An identifier for the network, composed of the string value of the SSID element used to identify the network, concatenated with the value of the HESSID if it is in use. EssLinkParamete As defined in N/A The EssLinkParameterSet is used to rSet Table 6-7 configure when event reports are sent to higher protocol layers. 6.4.8.4.3 When generated This primitive is generated in response to the MSGCF-ESS-LINK-PARAMETERS.request primitive and is used to indicate whether the parameter set was accepted. 6.4.8.4.4 Effect of receipt The SME is notified of the new parameter set. 6.4.8.5 MSGCF-GET-ESS-LINK-PARAMETERS.request 6.4.8.5.1 Function This primitive retrieves the current network parameters for a specific network. 6.4.8.5.2 Semantics of the service primitive The primitive parameter is as follows: MSGCF-GET-ESS-LINK-PARAMETERS.request( ESSIdentifier ) Name Type Valid range Description ESSIdentifier String N/A An identifier for the network, composed of the string value of the SSID element used to identify the network, concatenated with the value of the HESSID if it is in use. 6.4.8.5.3 When generated This primitive is used by higher layers to retrieve the currently stored parameters for a network. 606 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.4.8.5.4 Effect of receipt The SME retrieves the network parameters and makes them available through the MSGCF-GET-ESS-LINK- PARAMETERS.confirm primitive. 6.4.8.6 MSGCF-GET-ESS-LINK-PARAMETERS.confirm 6.4.8.6.1 Function This primitive reports the current network parameters. 6.4.8.6.2 Semantics of the service primitive The primitive parameters are as follows: MSGCF-GET-ESS-LINK-PARAMETERS.confirm( ESSIdentifier, EssLinkParameterSet, ) Name Type Valid range Description ESSIdentifier String N/A An identifier for the network, composed of the string value of the SSID element used to identify the network, concatenated with the value of the HESSID if it is in use. EssLinkParamet As defined N/A The EssLinkParameterSet is used to erSet 6.4.8.3 configure when event reports are sent to higher protocol layers. 6.4.8.6.3 When generated This primitive is generated by the MSGCF as a result of the MSGCF-GET-ESS-LINK- PARAMETERS.request primitive. 6.4.8.6.4 Effect of receipt The higher layer protocols are notified of the current network parameters. 6.4.9 Network events 6.4.9.1 MSGCF-ESS-LINK-THRESHOLD-REPORT.indication 6.4.9.1.1 Function This event reports that the layer 2 network performance has crossed a threshold set by the operations described in Table 6-5. 6.4.9.1.2 Semantics of the service primitive The primitive parameters are as follows: MSGCF-ESS-LINK-THRESHOLD-REPORT.indication( ESSIdentifier, EssLinkParameterSet, ThresholdCrossingDirectionSet ) 607 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description ESSIdentifier String N/A An identifier for the network, composed of the string value of the SSID element used to identify the network, concatenated with the value of the HESSID if it is in use. EssLinkParame As defined in Table 6-7 N/A A list of EssLinkParameterSets and their terSet current values that have crossed preset thresholds for alerts. ThresholdCross Set of ThresholdCrossing UPWARD, Whether the parameter has crossed the ingDirectionSet Directions, one for each DOWNWARD threshold while rising or falling. value in the EssLinkParameterSet 6.4.9.1.3 When generated The convergence function is responsible for monitoring network performance. If the monitored parameters cross the configured threshold, this event is generated to inform higher layer protocols. 6.4.9.1.4 Effect of receipt This event is made available to higher layer protocols by the convergence function. Actions taken by those higher layers are outside the scope of this standard, but may include preparations for handover or assessing whether handover should be imminent. 6.4.10 Network command interface 6.4.10.1 MSGCF-ESS-LINK-COMMAND.request 6.4.10.1.1 Function This primitive requests that a STA take action for a network. 6.4.10.1.2 Semantics of the service primitive The primitive parameters are as follows: MSGCF-ESS-LINK-COMMAND.request( ESSIdentifier, CommandType ) Name Type Valid range Description ESSIdentifier String N/A An identifier for the network, composed of the string value of the SSID element used to identify the network, concatenated with the value of the HESSID if it is in use. CommandType Enumerated DISCONNECT, Type of command to perform on the link LOW_POWER, as described in the following subclauses. POWER_UP, POWER_DOWN, SCAN 6.4.10.1.3 When generated This primitive is generated by a higher layer protocol. 608 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.4.10.1.4 Effect of receipt The convergence function issues commands to the SME to implement the requested action on behalf of higher layers. When the DISCONNECT command type is specified, the higher layer is requesting that the STA disconnect from its peer. When the SME on a non-AP STA receives this command, the SME issues an MLME- DEAUTHENTICATE.request primitive to disconnect from the network, and the SME refrains from reconnecting to that network. When the POWER_DOWN command type is specified, the SME powers down the non-AP STA. Before doing so, it may choose to notify the AP. When the POWER_UP command type is specified, the SME starts the non-AP STA. When the LOW_POWER command type is specified, the higher layer is requesting that the interface be placed in a low power mode. This action is accomplished by issuing an MLME-POWERMGT.request primitive with the PowerManagementMode parameter set to POWER_SAVE. When the SCAN command type is specified, the higher layer is requesting that the STA search for networks. This action is accomplished by issuing an MLME-SCAN.request primitive. Detected networks are made available in the dot11MACStateESSLinkDetectedTable, as well as through the MSGCF-ESS-LINK- DETECTED.indication primitive. 6.4.11 MAC state SME SAPâ€”mobility management 6.4.11.1 MSSME-ESS-LINK-GOING-DOWN.indication 6.4.11.1.1 Function This primitive indicates that the SME is predicting a link failure. 6.4.11.1.2 Semantics of the service primitive The primitive parameters are as follows: MSSME-ESS-LINK-GOING-DOWN.indication( ESSIdentifier, TimeInterval, ReasonCode ) Name Type Valid range Description NonAPSTAMac MacAddress Any valid individual MAC The MAC address of the non-AP STA that Address Address is reporting that an ESS is expected to go down. ESSIdentifier String N/A An identifier for the network, composed of the string value of the SSID element used to identify the network, concatenated with the value of the HESSID if it is in use. 609 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Valid range Description TimeInterval Integer N/A Time Interval, in time units, in which the link is expected to go down. Connectivity is expected to be available at least for time specified by TimeInterval. Reason Code Enumerated EXPLICIT_DISCONNECT, Indicates the reason the link is expected to LINK_PARAMETER_DEG go down. RADATION, KEY_EXPIRATION, LOW_POWER, QOS_UNAVAILABLE, VENDOR_SPECIFIC 6.4.11.1.3 When generated This notification is generated by the SME when the network connection is currently established and is expected to go down. The details of the predictive algorithm used are beyond the scope of this standard. One method of implementing this function would be to generate this indication when link quality is fading and no better AP can be found. 6.4.11.1.4 Effect of receipt This indication is received by the MSGCF and is used to generate the MSGCF-ESS-LINK-DOWN.indication primitive due to link parameter degradation. 6.5 PLME SAP interface 6.5.1 General The PHY management service interface consists of the generic PLMEGET and PLMESET primitives on PHY MIB attributes, as described previously, together with the PLME-RESET and PLME- CHARACTERISTICS primitives and the following specific primitives. 6.5.2 PLME-RESET.request 6.5.2.1 Function This primitive is a request by the SME to reset the PHY. The PHY is always reset to the receive state to avoid accidental data transmission. 6.5.2.2 Semantics of the service primitive This primitive has no parameters. 6.5.2.3 When generated This primitive is generated at any time to reset the PHY. 6.5.2.4 Effect of receipt Receipt of this primitive by the PHY causes the PHY entity to reset both the transmit and the receive state machines and places the PHY into the receive state. 610 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.5.3 PLME-CHARACTERISTICS.request 6.5.3.1 Function This primitive is a request by the SME to provide the PHY operational characteristics. 6.5.3.2 Semantics of the service primitive This primitive has no parameters. 6.5.3.3 When generated This primitive is generated by the SME, at initialization time, to request the PHY entity to provide its operational characteristics. 6.5.3.4 Effect of receipt The effect of receipt of this primitive by the PHY entity is the generation of a PLME-CHARACTERISTICS. confirm primitive that conveys its operational characteristics. 6.5.4 PLME-CHARACTERISTICS.confirm 6.5.4.1 Function This primitive provides the PHY operational parameters. 6.5.4.2 Semantics of the service primitive The primitive provides the following parameters: PLME-CHARACTERISTICS.confirm( aSlotTime, aSIFSTime, aSignalExtension, aCCATime, aCCAMidTime, aRxPHYStartDelay, aRxTxTurnaroundTime, aTxPHYDelay, aRxPHYDelay, aRxTxSwitchTime, aTxRampOnTime, aAirPropagationTime, aMACProcessingDelay, aPreambleLength, aRIFSTime, aSymbolLength, aSTFOneLength, aSTFTwoLength, aLTFOneLength, aLTFTwoLength, aPHYHeaderLength, aPHYSigTwoLength, aPHYServiceLength, aPHYConvolutionalTailLength, 611 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications aPSDUMaxLength, aPPDUMaxTime, aIUSTime, aDTT2UTTTime, aCWmin, aCWmax, aMaxCSIMatricesReportDelay aMaxTODError, aMaxTOAError, aTxPHYTxStartRFDelay, aTxPHYTxStartRMS, aMaxTODFineError, aMaxTOAFineError ) The values assigned to the parameters are as specified in the PLME SAP interface specification contained within each PHY subclass of this standard. Not all parameters are used by all PHYs defined within this standard. Name Type Description aSlotTime integer The Slot Time (in microseconds) that the MAC uses for defining IFSs. See 10.3.7. aSIFSTime integer The nominal time (in microseconds) that the MAC and PHY require in order to receive the last symbol of a frame on the WM, process the frame, and respond with the first symbol on the WM of the earliest possible response frame. See 10.3.7. aSignalExtension integer Duration (in microseconds) of the signal extension (i.e., a period of no transmission) that is included at the end of certain PPDU formats; see 19.3.2 and 10.3.8. aCCATime integer For Clause 15 through Clause 18 PHYs and Clause 20 PHYs, the maximum time (in microseconds) the CCA mechanism has available to assess the medium to determine whether the medium is busy or idle. For Clause 19 and Clause 21 PHYs, the maximum time (in microseconds) that the CCA mechanism has available to detect the start of a valid IEEE 802.11 transmission within the primary channel and to assess the energy on the medium within the primary, secondary, secondary40 (Clause 21 PHY only), and secondary80 (Clause 21 PHY only) channels that fall inside the operating channel, in order to determine the values of the STATE and channel-list parameters of the PHY-CCA.indication primitive. aCCAMidTime integer For Clause 21 PHYs, the maximum time (in microseconds) the CCA mechanism has available to assess the medium to determine whether an IEEE 802.11 transmission is present on a nonprimary channel. aRxPHYStartDelay integer The delay, in microseconds, from the start of the PPDU at the receiverâ€™s antenna to the issuance of the PHY-RXSTART.indication primitive. aRxTxTurnaroundTime integer The maximum time (in microseconds) that the PHY requires to change from receiving to transmitting the start of the first symbol. See 10.3.7. aTxPHYDelay integer The nominal time (in microseconds) that the PHY uses to deliver a symbol from the MAC interface to the air interface. aRxPHYDelay integer The nominal time (in microseconds) that the PHY uses to deliver the last bit of a received frame from end of the last symbol on the WM to the MAC. aRxTxSwitchTime integer The nominal time (in microseconds) that the PHY takes to switch from Receive to Transmit. aTxRampOnTime integer The maximum time (in microseconds) that the PHY takes to turn the Transmitter on. 612 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Description aAirPropagationTime integer Twice the propagation time (in microseconds) for a signal to cross the maximum distance between the most distant allowable STAs that are slot synchronized. aMACProcessingDelay integer The maximum time (in microseconds) available for the MAC to issue a PHY-TXSTART.request primitive pursuant to a PHY-RXEND.indication primitive (for response after SIFS) or PHY-CCA.indication(IDLE) primitive (for response at any slot boundary following a SIFS). This constraint on MAC performance is defined as a PHY-specific parameter because of its use, along with other PHY-specific time delays, in calculating the two PHY characteristics of primary concern to the MAC: aSlotTime and aSIFSTime. See 10.3.7. aPreambleLength integer The current PHYâ€™s preamble length (in microseconds). If the actual value of the length of the modulated preamble is not an integer number of microseconds, the value is rounded up to the next higher value. aRIFSTime integer Value of the reduced interframe space (in microseconds), which is the time by which multiple transmissions from a single transmitter may be separated, when no SIFS-separated response transmission is expected. See 10.3.2.3.2 aSymbolLength integer The current PHYâ€™s Symbol length (in microseconds). If the actual value of the length is not an integer number of Âµs, the value is rounded up to the next higher value. aSTFOneLength integer Length of the non-HT-STF (L-STF) for HT-mixed format, and the HT- greenfield STF (HT-GF-STF) for HT-greenfield format (in microseconds) aSTFTwoLength integer Length of the HT-STF (in microseconds) aLTFOneLength integer Length of the First HT-LTF (in microseconds) aLTFTwoLength integer Length of the Additional HT-LTFs (in microseconds) aPHYHeaderLength integer The current PHYâ€™s header length (in microseconds), excluding aPHYSigTwoLength if present. If the actual value of the length of the modulated header is not an integer number of microseconds, the value is rounded up to the next higher value. aPHYSigTwoLength integer Length of the HT SIGNAL field (HT-SIG) (in microseconds). aPHYServiceLength integer The length of the PHY SERVICE field (in number of bits). aPHYConvolutionalTail integer The length of the sequence of convolutional code tail bits (in number of Length bits). aPSDUMaxLength integer The maximum number of octets in a PSDU that can be conveyed by a PPDU. aPPDUMaxTime integer The maximum duration of a PPDU in milliseconds. aIUSTime integer The minimum time between the end of a PSMP-UTT and the start of the following PSMP-UTT in the same PSMP sequence. aDTT2UTTTime integer The minimum time between the end of a PSMP-DTT and the start of the PSMP-UTT addressed to the same STA. aCWmin integer The minimum size of the CW, in units of aSlotTime. aCWmax integer The maximum size of the CW, in units of aSlotTime. aMaxCSIMatricesReport integer The maximum time (in milliseconds) between the reception of a frame Delay containing a CSI Feedback Request or an null data packet (NDP) announcement and the transmission of the first CSI frame containing channel state information measured from the received Sounding Complete frame. See 10.32.2.4.4. aMaxTODError Integer An estimate of the maximum error (in 10 ns units) in the TX_START_OF_FRAME_OFFSET value in the PHY- TXSTART.confirm(TXSTATUS) primitive. The estimated maximum error includes any error due to implementation component and environmental (including temperature) variability. aMaxTOAError Integer An estimate of the maximum error (in 10 ns units) in the RX_START_OF_FRAME_OFFSET value in the PHY- RXSTART.indication(RXVECTOR) primitive. The estimated maximum error includes any error due to implementation component and environmental (including temperature) variability. 613 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Name Type Description aTxPHYTxStartRFDelay Integer The delay (in units of 0.5 ns) between a PHY-TXSTART.request primitive being issued and the first frame energy sent by the transmitting port, for the current channel. aTxPHYTxStartRMS Integer The RMS time of departure error (in units of 0.5 ns), where the time of departure error equals the difference between TIME_OF_DEPARTURE and the time of departure measured by a reference entity using a clock synchronized to the start time and mean frequency of the local PHY entityâ€™s clock. aMaxTODFineError Integer An estimate of the maximum error (in units of picoseconds) in the TX_START_OF_FRAME_OFFSET value in the PHY- TXSTART.confirm(TXSTATUS) primitive. The estimated maximum error includes any error due to implementation component and environmental (including temperature) variability. aMaxTOAFineError Integer An estimate of the maximum error (in units of picoseconds) in the RX_START_OF_FRAME_OFFSET value in the PHY- RXSTART.indication(RXVECTOR) primitive. The estimated maximum error includes any error due to implementation component and environmental (including temperature) variability. 6.5.4.3 When generated This primitive is issued by the PHY entity in response to a PLME-CHARACTERISTICS.request primitive. 6.5.4.4 Effect of receipt The receipt of this primitive provides the operational characteristics of the PHY entity. 6.5.5 PLME-TXTIME.request 6.5.5.1 Function This primitive is a request for the PHY to calculate the time required to transmit onto the WM a PPDU containing a specified length PSDU, and using a specified format, data rate, and signaling. 6.5.5.2 Semantics of the service primitive This primitive provides the following parameter: PLME-TXTIME.request( TXVECTOR ) The TXVECTOR represents a list of parameters that the MAC sublayer provides to the local PHY entity in order to transmit a PSDU. The minimum required PHY parameters are listed in 8.3.4.4. 6.5.5.3 When generated This primitive is issued by the MAC sublayer to the PHY entity when the MAC sublayer needs to determine the time required to transmit a particular PSDU. 6.5.5.4 Effect of receipt The effect of receipt of this primitive by the PHY entity is to generate a PHY-TXTIME.confirm primitive that conveys the required transmission time. 614 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6.5.6 PLME-TXTIME.confirm 6.5.6.1 Function This primitive indicates the time required to transmit the PPDU described in the corresponding PLME- TXTIME.request primitive. When the TXVECTOR parameter FORMAT in the corresponding PLME-TXTIME.request primitive is VHT, the primitive also provides the number of octets, per user, required to fill the PPDU. 6.5.6.2 Semantics of the service primitive This primitive provides the following parameter: PLME-TXTIME.confirm( TXTIME PSDU_LENGTH[] ) The TXTIME represents the time, in microseconds, required to transmit the PPDU described in the corresponding PLME-TXTIME.request primitive. If the calculated time includes a fractional microsecond, a non-DMG STA rounds the TXTIME value to the next higher integer. A DMG STA does not round the TXTIME value up or down (see 20.12.3). The PSDU_LENGTH[] parameter is an array of size TXVECTOR parameter NUM_USERS. Each value in the array indicates the number of octets required to fill the PPDU for the user represented by that array index. The parameter is present only when the TXVECTOR FORMAT parameter is VHT. 6.5.6.3 When generated This primitive is issued by the local PHY entity in response to a PLME-TXTIME.request primitive. 6.5.6.4 Effect of receipt The receipt of this primitive provides the MAC sublayer with the PPDU transmission time. 615 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 7. DS SAP specification 7.1 Introduction The DS SAP is the interface between the DS SAP service users and the DS SAP service provider. The DS SAP service users are the connected APs, mesh gates, and the portal. The DS SAP service provider is the DS. Figure 7-1 shows the location of the DS in the IEEE 802.11 architecture. The DS SAP is indicated in this Figure by the lines connecting the DS to its service users. In Figure 7-1, the DS has four users, two APs, a mesh gate, and a portal, so the DS is shown passing behind the MAC/PHYs of the STAs. DSAF DSAF DSAF Portal MAC MAC Mesh MAC MAC MAC MAC PHY PHY PHY PHY DS PHY PHY 802.11 Medium 802.11 Medium 802.11 Medium 802.3 Medium Nonâ€AP STAs AP1 AP2 Mesh Gate Portal â€ DS SAP Figure 7-1â€”DS architecture The DS SAP interface specification describes the primitives required to get MAC service tuples in and out of the DS and update the DSâ€™s mapping of STAs to APs or to mesh gates. Describing the DS itself or the functions thereof is out of scope of this annex. The DS SAP actions are as follows: a) Accept MSDUs (as part of MAC service tuples) from APs, mesh gates, and the portal. b) Deliver MSDUs (as part of MAC service tuples) to APs, mesh gates, or the portal. c) Accept STA-to-AP mapping updates from the APs. d) Accept STA-to-mesh gate mapping updates from the mesh gates. When the DS delivers the MAC service tuples to an AP, the AP then determines when and how to deliver the MAC service tuples to the APâ€™s MAC (via the MAC SAP). When the DS delivers the MAC service tuples to a mesh gate, the mesh gate then determines when and how to deliver the MAC service tuples to the mesh gateâ€™s MAC (via the MAC SAP). 7.2 SAP primitives 7.2.1 General The DS SAP service interface primitives are as follows: a) DS-UNITDATA.request b) DS-UNITDATA.indication c) DS-STA-NOTIFY.request 616 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 7.2.2 MSDU transfer 7.2.2.1 General The DS-UNITDATA primitives accept and deliver IEEE 802.11 MAC service tuples, including all of the parameters and data as defined in 5.2.2.2. 7.2.2.2 DS-UNITDATA.request 7.2.2.2.1 Function This primitive requests distribution of a MAC service tuple across the DS. 7.2.2.2.2 Semantics of the service primitive The primitive parameters are as follows: DS-UNITDATA.request( MAC service tuple, SourceType ) Name Type Valid range Description MAC service tuple IEEE 802.11 Any valid data unit Specifies the MAC service tuple to be MSDU according to 5.2.2.2, distributed via the DS. including data and all parameters SourceType Enumeration SRC_AP, Specifies the type of entity that is requesting SRC_MESH_GATE, distribution of a MAC service tuple. SRC_PORTAL 7.2.2.2.3 When generated This primitive is generated by an AP, mesh gate, or portal to submit a MAC service tuple to the DS for distribution. 7.2.2.2.4 Effect of receipt This primitive initiates distribution of the MAC service tuple through the DS. An individually addressed MAC service tuple from an AP, mesh gate, or portal is distributed through the DS to the corresponding AP, mesh gate, or portal. A group addressed MAC service tuple from an AP is distributed to all APs, mesh gates, and the portal, including the originating entity. A group addressed MAC service tuple from a portal is distributed to all APs and mesh gates. 7.2.2.3 DS-UNITDATA.indication 7.2.2.3.1 Function This primitive indicates delivery of a MAC service tuple from the DS to an AP, mesh gate, or portal. 617 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 7.2.2.3.2 Semantics of the service primitive The primitive parameters are as follows: DS-UNITDATA.indication( MAC service tuple ) Name Type Valid range Description MAC service tuple IEEE 802.11 Any valid data unit Specifies the MAC service tuple that is being MSDU according to 5.2.2.2, delivered by the DS. including data and all parameters 7.2.2.3.3 When generated This primitive is generated by the DS to deliver a MAC service tuple to an AP, mesh gate, or portal. 7.2.2.3.4 Effect of receipt This primitive delivers a MAC service tuple to an AP, mesh gate, or portal. 7.2.3 Mapping updates 7.2.3.1 General The DS-STA-NOTIFY primitive is used to maintain the STA-to-AP and mesh STA-to-mesh gate mapping data of the DS. 7.2.3.2 DS-STA-NOTIFY.request 7.2.3.2.1 Function This primitive requests an update to the DSâ€™s STA-to-AP map or mesh STA-to-mesh gate map. 7.2.3.2.2 Semantics of the service primitive The primitive parameters are as follows: DS-STA-NOTIFY.request( STAAddress, UpdateType ) Name Type Valid range Description STAAddress MACAddress Any valid individual When generated by an AP, specifies the MAC address address of the STA whose association status with the AP has changed. When generated by a mesh gate, specifies the address of the mesh STA whose reachability status through the mesh gate has changed. UpdateType Enumeration ADD, MOVE, Specifies the DS mapping update DELETE operation to be performed. 618 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 7.2.3.2.3 When generated This primitive is generated by an AP or mesh gate to update the DSâ€™s STA-to-AP map or mesh STA-to- mesh gate map. 7.2.3.2.4 Effect of receipt When generated by an AP, this primitive updates the DSâ€™s STA-to-AP map, which controls to which AP the DS delivers MAC service tuples that are destined for a given STA. When generated by a mesh gate, this primitive updates the DSâ€™s mesh STA-to-mesh gate map, which controls to which mesh gate the DS delivers MAC service tuples that are destined for a given mesh STA. The mesh STA-to-mesh gate map can be incomplete. There are many mechanisms to implement this mapping update for the cases of ADD and MOVE. One example mechanism, in the case where the DS is an IEEE 802 LAN, is to use an IEEE 802.2â„¢ XID null frame. 619 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 8. PHY service specification 8.1 Scope The PHY services provided to the MAC are described in this clause. Different PHYs are defined as part of this standard. Each PHY can consist of the following protocol functions: a) A function that defines a method of mapping the MPDUs into a framing format suitable for sending and receiving user data and management information between two or more STAs. b) A function that defines the characteristics of, and method of transmitting and receiving data through, a WM between two or more STAs. 8.2 PHY functions The protocol reference model for the IEEE 802.11 architecture is shown in Figure 4-19 (in 4.9). Most PHY definitions contain two functional entities: the PHY function and the layer management function. The PHY service is provided to the MAC entity at the STA through a SAP, called the PHYSAP, as shown in Figure 4-19. 8.3 Detailed PHY service specifications 8.3.1 Scope and field of application The services provided by the PHY to the MAC are specified in this subclause. These services are described in an abstract way and do not imply any particular implementation or exposed interface. 8.3.2 Overview of the service The function of the PHY is to provide a mechanism for transferring MPDUs between two or more STAs. 8.3.3 Overview of interactions The primitives associated with communication between the MAC sublayer and the PHY fall into two basic categories: a) Service primitives that support MAC peer-to-peer interactions; b) Service primitives that have local significance and support sublayer-to-sublayer interactions. 8.3.4 Basic service and options 8.3.4.1 PHY SAP peer-to-peer service primitives Table 8-1 indicates the primitives for peer-to-peer interactions. Table 8-1â€”PHY SAP peer-to-peer service primitives Primitive Request Indication Confirm PHY-DATA X X X 620 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 8.3.4.2 PHY SAP inter-(sub)layer service primitives Table 8-2 indicates the primitives for sublayer-to-sublayer interactions. Table 8-2â€”PHY SAP inter-(sub)layer service primitives Primitive Request Indication Confirm PHY-TXSTART X X PHY-TXEND X X PHY-CCARESET X X PHY-CCA X PHY-RXSTART X PHY-RXEND X PHY-CONFIG X X PHY-TXBUSY X PHY-TXHEADEREND X 8.3.4.3 PHY SAP service primitives parameters Table 8-3 shows the parameters used by one or more of the PHY SAP service primitives. Table 8-3â€”PHY SAP service primitive parameters Parameter Associated primitive Value DATA PHY-DATA.request Octet value X'00'â€“X'FF' PHY-DATA.indication TXVECTOR PHY-TXSTART.request A set of parameters STATE PHY-CCA.indication (BUSY, [channel-list]) (IDLE) RXVECTOR PHY-RXSTART.indication A set of parameters PHY-RXEND.indication RXERROR PHY-RXEND.indication NoError, FormatViolation, CarrierLost, UnsupportedRate, Filtered IPI-STATE PHY-CCARESET.request IPI-ON, IPI-OFF PHY-CCARESET.confirm IPI-REPORT PHY-CCA.indication A set of IPI values for the preceding PHY-CCARESET.confirm time interval PHYCONFIG_VECTOR PHY-CONFIG A set of parameters TXSTATUS PHY-TXSTART.confirm A set of parameters STATE PHY-TXBUSY.indication IDLE, BUSY 621 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 8.3.4.4 Vector descriptions Several service primitives include a parameter vector. This vector is a list of parameters that may vary depending on the PHY type. Table 8-4 lists the minimum parameter values required by the MAC or PHY in each of the parameter vectors. Table 8-4â€”Vector descriptions Parameter Associated vector Value DATARATE TXVECTOR, RXVECTOR PHY dependent. The name of the field used to specify the Tx data rate and report the Rx data rate may vary for different PHYs. LENGTH TXVECTOR, RXVECTOR PHY dependent ACTIVE_RXCHAIN_SET PHYCONFIG_VECTOR The ACTIVE_RXCHAIN_SET parameter indicates which receive chains of the available receive chains are active. OPERATING_CHANNEL PHYCONFIG_VECTOR The operating channel the PHY is configured use. SECONDARY_CHANNEL PHYCONFIG_VECTOR Enumerated type: _OFFSET SECONDARY_CHANNEL_NONE indicates operation in 20 MHz HT STAs. SECONDARY_CHANNEL_ABOVE indicates operation in 40 MHz with the secondary channel above the primary. SECONDARY_CHANNEL_BELOW indicates operation in 40 MHz with the secondary channel below the primary. ANT_CONFIG PHYCONFIG_VECTOR Indicates which antenna configuration(s) is to be used when receiving packets and which configuration is to be used when switching configurations during the reception of a packet. Values are implementation dependent. GROUP_ID_MANAGEME PHYCONFIG_VECTOR Specifies membership status and STA position for NT each of the group IDs as described in 9.6.23.3 PARTIAL_AID_LIST_GID PHYCONFIG_VECTOR Includes the list of partial AIDs, of which the STA 00 is an intended recipient, associated with group ID 0. The settings of the PARTIAL_AID are specified in 10.20). PARTIAL_AID_LIST_GID PHYCONFIG_VECTOR Includes the list of partial AIDs, of which the STA 63 is an intended recipient, associated with group ID 63. The settings of the PARTIAL_AID are specified in 10.20). LISTEN_TO_GID00 PHYCONFIG_VECTOR When true, indicates to the PHY not to filter out PPDUs with GROUP_ID field equal to the value 0. LISTEN_TO_GID63 PHYCONFIG_VECTOR When true, indicates to the PHY not to filter out PPDUs with GROUP_ID field equal to the value 63. The Clause 19 PHY TXVECTOR and RXVECTOR contain additional parameters related to the operation of the Clause 19 PHY modes of operation as described in 19.2. In certain modes of operation, the 622 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DATARATE parameter is replaced by MCS, CH_BANDWIDTH and GI_TYPE values. The mapping from these values to data rate is defined in 19.5. The Clause 21 PHY TXVECTOR and RXVECTOR contain additional parameters related to the operation of the Clause 21 PHY modes of operation as described in 21.2. In certain modes of operation, the DATARATE parameter is replaced by MCS, CH_BANDWIDTH, NUM_STS, STBC and GI_TYPE values. The mapping from these values to data rate is defined 21.5, where VHT-MCS is MCS and NSS is NUM_STS / (STBC + 1). 8.3.5 PHY SAP detailed service specification 8.3.5.1 Introduction Subclause 8.3.5 describes the services provided by each PHY primitive. 8.3.5.2 PHY-DATA.request 8.3.5.2.1 Function This primitive defines the transfer of an octet of data from the MAC sublayer to the local PHY entity. 8.3.5.2.2 Semantics of the service primitive The primitive provides the following parameter: PHY-DATA.request( DATA USER_INDEX ) The DATA parameter is an octet of value X'00' to X'FF'. The USER_INDEX parameter (typically identified as u for a VHT STA; see NOTE 1 at the end of Table 21-1) is present for a VHT MU PPDU and indicates the index of the user in the TXVECTOR to which the accompanying DATA octet applies; otherwise, this parameter is not present. 8.3.5.2.3 When generated This primitive is generated by the MAC sublayer to transfer an octet of data to the PHY entity. This primitive can be issued only following a transmit initialization response (a PHY-TXSTART.confirm primitive) from the PHY. 8.3.5.2.4 Effect of receipt The receipt of this primitive by the PHY entity causes the PHY transmit state machine to transmit an octet of data. When the PHY entity receives the octet, it issues a PHY-DATA.confirm primitive to the MAC sublayer. 8.3.5.3 PHY-DATA.indication 8.3.5.3.1 Function This primitive indicates the transfer of data from the PHY to the local MAC entity. 623 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 8.3.5.3.2 Semantics of the service primitive The primitive provides the following parameter: PHY-DATA.indication( DATA ) The DATA parameter is an octet of value X'00' to X'FF'. 8.3.5.3.3 When generated The PHY-DATA.indication primitive is generated by a receiving PHY entity to transfer the received octet of data to the local MAC entity. The time between receipt of the last bit of the last provided octet from the WM and the receipt of this primitive by the MAC entity is aRxPHYDelay. 8.3.5.3.4 Effect of receipt The effect of receipt of this primitive by the MAC is unspecified. 8.3.5.4 PHY-DATA.confirm 8.3.5.4.1 Function This primitive is issued by the PHY to the local MAC entity to confirm the transfer of data from the MAC entity to the PHY. 8.3.5.4.2 Semantics of the service primitive The semantics of the primitive are as follows: PHY-DATA.confirm This primitive has no parameters. 8.3.5.4.3 When generated This primitive is issued by the PHY to the MAC entity the transfer of data from the MAC entity to the PHY has completed. The PHY issues this primitive in response to every PHY-DATA.request primitive issued by the MAC sublayer. 8.3.5.4.4 Effect of receipt The receipt of this primitive by the MAC causes the MAC to start the next MAC entity request. 8.3.5.5 PHY-TXSTART.request 8.3.5.5.1 Function This primitive is a request by the MAC sublayer to the local PHY entity to start the transmission of a PSDU. 8.3.5.5.2 Semantics of the service primitive The primitive provides the following parameter: 624 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications PHY-TXSTART.request( TXVECTOR ) The TXVECTOR represents a list of parameters that the MAC sublayer provides to the local PHY entity in order to transmit a PSDU. The minimum required PHY parameters are listed in 8.3.4.4. 8.3.5.5.3 When generated This primitive is issued by the MAC sublayer to the PHY entity when the MAC sublayer needs to begin the transmission of a PSDU. 8.3.5.5.4 Effect of receipt The effect of receipt of this primitive by the PHY entity is to start the local transmit state machine. The behavior expected by the MAC pursuant to the issuance of PHY-TXSTART.request primitive is shown in Figure 10-19 (in 10.3.7) and Figure 10-26. 8.3.5.6 PHY-TXSTART.confirm 8.3.5.6.1 Function This primitive is issued by the PHY to the local MAC entity to confirm the start of a transmission and to indicate parameters related to the start of the transmission. The PHY issues this primitive in response to every PHY-TXSTART.request primitive issued by the MAC sublayer. 8.3.5.6.2 Semantics of the service primitive The semantics of the primitive are as follows: PHY-TXSTART.confirm( TXSTATUS ) The TXSTATUS represents a list of parameters that the local PHY entity provides to the MAC sublayer related to the transmission of an MPDU. The required PHY parameters are listed in 8.3.4.3. 8.3.5.6.3 When generated This primitive is issued by the PHY to the MAC entity once all of the following conditions are met: â€” The PHY has received a PHY-TXSTART.request primitive from the MAC entity. â€” The PHY is ready to begin accepting outgoing data octets from the MAC. If dot11TODImplemented and dot11TODActivated are both true or dot11TimingMsmtActivated is true; and the parameter TIME_OF_DEPARTURE_REQUESTED in the TXVECTOR specified in the PHY- TXSTART.request is true, then the PHY shall include the TIME_OF_DEPARTURE corresponding to the time when the first frame energy is sent by the transmitting port and TIME_OF_DEPARTURE_ClockRate parameters in the TXSTATUS vector (See Table 15-3). If dot11TimingMsmtActivated is true, then the PHY shall include TX_START_OF_FRAME_OFFSET in the TXSTATUS vector (See Table 15-3). 625 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 8.3.5.6.4 Effect of receipt The receipt of this primitive by the MAC entity causes the MAC to start the transfer of data octets. Parameters in the TXSTATUS vector may be included in transmitted frames so that recipients on multiple channels can compensate for differences in the transmit time of the frames, and so to determine the time differences of air propagation times between transmitter and pairs of recipients and hence to compute the location of the transmitter via multilateration. See Annex P. In addition, the TXSTATUS vector may include the TX_START_OF_FRAME_OFFSET. 8.3.5.7 PHY-TXEND.request 8.3.5.7.1 Function This primitive is a request by the MAC sublayer to the local PHY entity that the current transmission of the PSDU be completed. 8.3.5.7.2 Semantics of the service primitive The semantics of the primitive are as follows: PHY-TXEND.request This primitive has no parameters. 8.3.5.7.3 When generated This primitive is generated when the MAC sublayer has received the last PHY-DATA.confirm primitive from the local PHY entity for the PSDU currently being transferred. 8.3.5.7.4 Effect of receipt The effect of receipt of this primitive by the local PHY entity is to stop the transmit state machine. 8.3.5.8 PHY-TXEND.confirm 8.3.5.8.1 Function This primitive is issued by the PHY to the local MAC entity to confirm the completion of a transmission. The PHY issues this primitive in response to every PHY-TXEND.request primitive issued by the MAC sublayer. 8.3.5.8.2 Semantics of the service primitive The semantics of the primitive are as follows: PHY-TXEND.confirm This primitive has no parameters. 8.3.5.8.3 When generated This primitive is issued by the PHY to the MAC entity when the PHY has received a PHY-TXEND.request primitive immediately after transmitting the end of the last bit of the last data octet indicating that the symbol containing the last data octet has been transferred and any Signal Extension has expired. 626 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 8.3.5.8.4 Effect of receipt The receipt of this primitive by the MAC entity provides the time reference for the contention backoff protocol. 8.3.5.9 PHY-TXHEADEREND.indication 8.3.5.9.1 Function This primitive indicates the transmission completion of the PHY header to the local MAC entity. 8.3.5.9.2 Semantics of the service primitive The semantics of the primitive are as follows: PHY-TXHEADEREND.indication This primitive has no parameters. 8.3.5.9.3 When generated The PHY-TXHEADEREND.indication primitive is generated by a transmitter PHY entity at the end of transmission of the last symbol containing the PHY header. 8.3.5.9.4 Effect of receipt The receipt of this primitive by the MAC entity causes the MAC to record the time when this primitive is received only if TIME_OF_DEPARTURE_REQUESTED is true in the corresponding PHY-TXSTART.request primitive. 8.3.5.10 PHY-CCARESET.request 8.3.5.10.1 Function This primitive is a request by the MAC sublayer to the local PHY entity to reset the PHY to the state appropriate for the end of a received frame and to turn IPI reporting on and off by means of the IPI-STATE parameter. 8.3.5.10.2 Semantics of the service primitive The primitive provides the following parameter: PHY-CCARESET.request( IPI-STATE ) The IPI-STATE parameter is present if dot11RadioMeasurementActivated is true. The IPI-STATE parameter can be one of two values: IPI-ON or IPI-OFF. The parameter value is IPI-ON when the MAC sublayer is requesting the PHY entity to report IPI values when the PHY is neither receiving nor transmitting an MPDU. IPI-ON turns on IPI reporting in the PHY entity. IPI-OFF turns off IPI reporting in the PHY entity. 627 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 8.3.5.10.3 When generated This primitive is generated by the MAC sublayer for the local PHY entity at the end of a NAV and at a time indicated in 10.3.2.1 after each MAC slot boundary, which is described in 10.3.7 and 10.22.2.4. This request can be used by some PHY implementations that may synchronize antenna diversity with slot timings. 8.3.5.10.4 Effect of receipt The effect of receipt of this primitive by the PHY entity is to reset the PHY to the state appropriate for the end of a received frame and to initiate a new CCA evaluation cycle. If IPI-STATE parameter is IPI-ON, the PHY entity collects IPI values when it is not transmitting or receiving and provides those values to the MAC sublayer using the IPI-REPORT parameter. 8.3.5.11 PHY-CCARESET.confirm 8.3.5.11.1 Function This primitive is issued by the PHY to the local MAC entity to confirm that the PHY has reset the CCA state machine and to provide observed IPI values when IPI reporting is turned on. 8.3.5.11.2 Semantics of the service primitive The primitive provides the following parameters: PHY-CCARESET.confirm( IPI-STATE, IPI-REPORT ) The IPI-STATE parameter is present if dot11RadioMeasurementActivated is true. The IPI-STATE parameter can be one of two values: IPI-ON or IPI-OFF. The IPI-STATE value shall be set to the value of IPI-STATE received by the PHY entity in the most recent PHY-CCARESET.request primitive. The IPI-REPORT parameter is present if dot11RadioMeasurementActivated is true and if IPI reporting was turned on prior to the receipt of the latest PHY-CCARESET.request primitive. The IPI-REPORT parameter provides a set of IPI values for a time interval. The set of IPI values are recent values observed by the PHY entity since the generation of the most recent PHY-TXEND.confirm, PHY-RXEND.indication, PHY- CCARESET.confirm, or PHY-CCA.indication primitive, whichever occurred latest. 8.3.5.11.3 When generated This primitive is issued by the PHY to the MAC entity when the PHY has received a PHY-CCA- RESET.request primitive. 8.3.5.11.4 Effect of receipt The effect of receipt of this primitive by the MAC is unspecified. 8.3.5.12 PHY-CCA.indication 8.3.5.12.1 Function This primitive is an indication by the PHY to the local MAC entity of the current state of the medium and to provide observed IPI values when IPI reporting is turned on. 628 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 8.3.5.12.2 Semantics of the service primitive The primitive provides the following parameters: PHY-CCA.indication( STATE, IPI-REPORT, channel-list ) The STATE parameter can be one of two values: BUSY or IDLE. The parameter value is BUSY if the assessment of the channel(s) by the PHY determines that the channel(s) are not available. Otherwise, the value of the parameter is IDLE. The IPI-REPORT parameter is present if dot11RadioMeasurementActivated is true and if IPI reporting has been turned on by the IPI-STATE parameter. The IPI-REPORT parameter provides a set of IPI values for a time interval. The set of IPI values may be used by the MAC sublayer for radio measurement purposes. The set of IPI values are recent values observed by the PHY entity since the generation of the most recent PHY- TXEND.confirm, PHY-RXEND.indication, PHY-CCARESET.confirm, or PHY-CCA.indication primitive, whichever occurred latest. When STATE is IDLE or when, for the type of PHY in operation, CCA is determined by a single channel, the channel-list parameter is absent. Otherwise, it carries a set indicating which channels are busy. The channel-list parameter in a PHY-CCA.indication primitive generated by a VHT STA contains at most a single element. Table 8-5 defines the members of this set. Table 8-5â€”The channel-list parameter elements channel-list element Meaning primary In an HT STA that is not a VHT STA, indicates that the primary 20 MHz channel is busy. In a VHT STA, indicates that the primary 20 MHz channel is busy according to the rules specified in 21.3.18.5.3. In a TVHT STA, indicates that the primary channel is busy according to the rules specified in 22.3.18.6.3. secondary In an HT STA that is not a VHT STA, indicates that the secondary channel is busy. In a VHT STA, indicates that the secondary 20 MHz channel is busy according to the rules specified in 21.3.18.5.4. In a TVHT STA, indicates that the secondary channel is busy according to the rules specified in 22.3.18.6.4. secondary40 Indicates that the secondary 40 MHz channel is busy according to the rules specified in 21.3.18.5.4. In a TVHT STA, indicates that the secondary TVHT_2W channel is busy according to the rules specified in 22.3.18.6.4. secondary80 Indicates that the secondary 80 MHz channel is busy according to the rules specified in 21.3.18.5.4. The relationship of the channel-list parameter elements to the 40 MHz, 80 MHz, and 160 MHz BSS operating channel is illustrated by example in Figure 8-1. The relationship of the channel-list parameter elements to the 80+80 MHz BSS operating channel is illustrated by example in Figure 8-2. 629 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications secondary80 secondary40 secondary primary 40 MHz 80 MHz 160 MHz Figure 8-1â€”The channel-list parameter element for 40 MHz, 80 MHz, and 160 MHz channel width secondary80 secondary40 secondary primary 80+80 MHz Figure 8-2â€”The channel-list parameter element for 80+80 MHz channel width For a TVHT STA, the relationship of the channel-list parameter elements to the TVHT_W, TVHT_2W, and TVHT_W+W BSS operating channel is illustrated in Figure 8-3. NOTEâ€“This channel not present for TVHT_W 1 BCU 1 BCU f[MHz] 0-n BCUs: 0 for TVHT_2W 1-n for TVHT_W+W, where n depends on operating class primary: any single BCU channel secondary: the non-primary TVHT_W channel Figure 8-3â€”TVHT channel-list parameter element and channel bandwidth for TVHT_W, TVHT_2W, and TVHT_W+W 630 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications For a TVHT STA, the relationship of the channel-list parameter elements to the TVHT_4W and TVHT_2W+2W BSS operating channel is illustrated in Figure 8-4. 1 BCU 1 BCU 1 BCU 1 BCU f [MHz] TVHT_2W 0-n BCUs: 0 for TVHT_4W 1-n for TVHT_2W+2W, where n depends on operating class primary: any single BCU channel secondary: the non-primary TVHT_W channel in the same TVHT_2W channel group secondary40: the TVHT_2W channel group that does not contain the primaryTVHT_W Figure 8-4â€”TVHT channel-list parameter element and channel bandwidth for TVHT_4W and TVHT_2W+2W 8.3.5.12.3 When generated For Clause 15 to Clause 20 PHYs, this primitive is generated within aCCATime of the occurrence of a change in the status of the primary channel from channel idle to channel busy or from channel busy to channel idle or when the elements of the channel-list parameter change. For Clause 21 and Clause 22 PHYS, this primitive is generated when the status of the channel(s) changes from channel idle to channel busy or from channel busy to channel idle or when the elements of the channel-list parameter change. This includes the period of time when the PHY is receiving data. The timing of PHY-CCA.indication primitives related to transitions on secondary channel(s) is PHY specific. Refer to specific PHY clauses for details about CCA behavior for a given PHY. NOTEâ€”For the VHT PHY, the timing information is omitted here and is defined in 21.3.18.5. If the STA is an HT STA but not a VHT STA and the operating channel width is 20 MHz, the PHY maintains the channel busy indication until the period indicated by the LENGTH field has expired, where the LENGTH field is â€” In a valid SIG field if the format of the PPDU is NON_HT â€” In a valid HT-SIG field if the format of the PPDU is HT_MF or HT_GF If the STA is an HT STA but not a VHT STA and the operating channel width is 40 MHz, the PHY maintains the channel busy indication until the period indicated by the LENGTH field has expired, where the LENGTH field is â€” In a valid SIG field if the format of the PPDU is NON_HT and the PPDU is received in the primary channel â€” In a valid HT-SIG field if the format of the PPDU is HT_MF or HT_GF provided that the PPDU is either a 20 MHz PPDU received in the primary channel or a 40 MHz PPDU 8.3.5.12.4 Effect of receipt The effect of receipt of this primitive by the MAC is unspecified. 631 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 8.3.5.13 PHY-RXSTART.indication 8.3.5.13.1 Function This primitive is an indication by the PHY to the local MAC entity that the PHY has received a valid start of a PPDU, including a valid PHY header. NOTEâ€”This primitive is not generated until the PHY has determined the PPDU format (e.g., a VHT PPDU, which starts with an HT PHY header). 8.3.5.13.2 Semantics of the service primitive The primitive provides the following parameter: PHY-RXSTART.indication( RXVECTOR ) The RXVECTOR represents a list of parameters that the PHY provides the local MAC entity upon receipt of a valid PHY header. The required parameters are listed in 8.3.4.4. 8.3.5.13.3 When generated This primitive is generated by the local PHY entity to the MAC sublayer when the PHY has successfully validated the PHY header at the start of a new PPDU. After generating a PHY-RXSTART.indication primitive, the PHY is expected to maintain physical medium busy status (not generating a PHY-CCA.indication(IDLE) primitive) during the period required by that PHY to transfer a frame of the indicated LENGTH at the indicated DATARATE. This physical medium busy condition should be maintained even if a PHY-RXEND.indication(CarrierLost) primitive or a PHY-RXEND.indication(FormatViolation) primitive is generated by the PHY prior to the end of this period. 8.3.5.13.4 Effect of receipt The effect of receipt of this primitive by the MAC is unspecified. 8.3.5.14 PHY-RXEND.indication 8.3.5.14.1 Function This primitive is an indication by the PHY to the local MAC entity that the PPDU currently being received is complete. 8.3.5.14.2 Semantics of the service primitive The primitive provides the following parameters: PHY-RXEND.indication( RXERROR, RXVECTOR ) The RXERROR parameter can convey NoError or one or more values indicating an error condition. A number of error conditions may occur after the PHYâ€™s receive state machine has detected what appears to be a valid preamble and SFD. The following describes the parameter returned for each of those error conditions. 632 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” NoError. This value is used to indicate that no error occurred during the receive process in the PHY. â€” FormatViolation. This value is used to indicate that the format of the received PPDU was in error. â€” CarrierLost. This value is used to indicate that during the reception of the incoming PSDU, the carrier was lost and no further processing of the PSDU can be accomplished. â€” UnsupportedRate. This value is used to indicate that during the reception of the incoming PPDU, a nonsupported date rate was detected. â€” Filtered. This value is used to indicate that during the reception of the PPDU, the PPDU was filtered out due to a condition set in the PHYCONFIG_VECTOR. NOTEâ€”The filtered condition might occur in a VHT STA due to GROUP_ID or PARTIAL_AID filtering in the PHY. The RXVECTOR represents a list of parameters that the PHY provides the local MAC entity. RXVECTOR is an included parameter only when dot11RadioMeasurementActivated is true. The required parameters are listed in 8.3.4.4. 8.3.5.14.3 When generated This primitive is generated by the PHY for the local MAC entity to indicate that the receive state machine has completed a reception with or without errors. When a Signal Extension is present, the primitive is generated at the end of the Signal Extension. In the case of an RXERROR value of NoError, the MAC uses the PHY-RXEND.indication primitive as reference for channel access timing, as shown in Figure 10-19 (in 10.3.7) and Figure 10-26. 8.3.5.14.4 Effect of receipt The effect of receipt of this primitive is for the MAC to begin inter-frame space processing, as described in 10.3.7 and 10.22.2.4. 8.3.5.15 PHY-CONFIG.request 8.3.5.15.1 Function This primitive is a request by the MAC sublayer to the local PHY entity to configure the PHY. 8.3.5.15.2 Semantics of the service primitive The primitive provides the following parameter: PHY-CONFIG.request( PHYCONFIG_VECTOR ) 8.3.5.15.3 When generated This primitive is generated by the MAC sublayer for the local PHY entity when it desires to change the configuration of the PHY. 8.3.5.15.4 Effect of receipt The effect of receipt of this primitive by the PHY is to apply the parameters provided with the primitive and to configure the PHY for future operation. 633 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 8.3.5.16 PHY-CONFIG.confirm 8.3.5.16.1 Function This primitive is issued by the PHY to the local MAC entity to confirm that the PHY has applied the parameters provided in the PHY-CONFIG.request primitive. 8.3.5.16.2 Semantics of the service primitive The semantics of the primitive are as follows: PHY-CONFIG.confirm This primitive has no parameters. 8.3.5.16.3 When generated This primitive is issued by the PHY to the MAC entity when the PHY has received and successfully applied the parameters in the PHY-CONFIG.request primitive. 8.3.5.16.4 Effect of receipt The effect of the receipt of this primitive by the MAC is unspecified. 8.3.5.17 PHY-TXBUSY.indication 8.3.5.17.1 Function This primitive is an indication by the PHY to the local MAC entity(ies) of the current transmission state of the PHY. 8.3.5.17.2 Semantics of the service primitive The primitive provides the following parameter: PHY-TXBUSY.indication (STATE) The STATE parameter can be one of two values: BUSY or IDLE. The parameter value is BUSY if the PHY is transmitting a PPDU and thus not available to respond with a PHY-TXSTART.confirm primitive to a PHY-TXSTART.request primitive. Otherwise, the value of the parameter is IDLE. 8.3.5.17.3 When generated The primitive is generated when the PHY issues a PHY-TXSTART.confirm primitive to one of the MAC entities coordinated by an MM-SME, and it is generated to all coordinated MAC entities except to the one to which it responds with the PHY-TXSTART.confirm primitive. The STATE of the primitive is set to BUSY. This primitive is generated within aTxPHYDelay of the occurrence of a change in the state of the PHY transmit state machine to the RX state. In this case, the STATE of the primitive is set to IDLE. 8.3.5.17.4 Effect of receipt The effect of receipt of this primitive by the MAC is unspecified if the STATE of the primitive is set to IDLE. The effect of receipt of this primitive by the MAC is specified in 10.22.2.11 if the STATE of the primitive is set to BUSY. 634 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 8.4 PHY management The MIB comprises the managed objects, attributes, actions, and notifications required to manage a STA. The definition of these managed objects, attributes, actions, and notifications, as well as their structure, is presented in Annex C. 635 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9. Frame formats 9.1 General requirements The format of the MAC frames is specified in this clause. A STA shall be able to properly construct a subset of the frames specified in this clause for transmission and to decode a (potentially different) subset of the frames specified in this clause upon validation following reception. The particular subset of these frames that a STA constructs and decodes is determined by the functions supported by that particular STA. A STA shall be able to validate every received frame using the frame check sequence (FCS) and to interpret certain fields from the MAC headers of all frames. A STA shall transmit frames using only the frame formats described in Clause 9. 9.2 MAC frame formats 9.2.1 Basic components Each frame consists of the following basic components: a) A MAC header, which comprises frame control, duration, address, optional sequence control information, optional QoS Control information (QoS Data frames only), and optional HT Control fields (+HTC frames only); b) A variable-length frame body, which contains information specific to the frame type and subtype; c) An FCS, which contains a 32-bit CRC based on ITU-T V.42 [B53]. 9.2.2 Conventions Structures defined in the MAC sublayer are described as a sequence of components (e.g., fields, subfields, elements and subelements) in specific order. Each figure and table in Clause 9 depicts the components as they appear in the MAC frame and in the order in which they are passed to the physical layer (PHY), from left to right and then from top to bottom. In figures, all bits within fields are numbered, from 0 to k, where the length of the field is k + 1 bits. Bits within numeric fields that are longer than a single bit are depicted in increasing order of significance, i.e., with the lowest numbered bit having the least significance. The octet boundaries within a field can be obtained by taking the bit numbers of the field modulo 8. Octets within numeric fields that are longer than a single octet are depicted in increasing order of significance, from lowest numbered bit to highest numbered bit. The octets in fields longer than a single octet are sent to the PHY in order from the octet containing the lowest numbered bits to the octet containing the highest numbered bits. Any field containing a CRC is an exception to this convention and is transmitted commencing with the coefficient of the highest-order term. MAC addresses are assigned as ordered sequences of bits. The Individual/Group bit is always transferred first and is bit 0 of the first octet. Organizationally unique identifiers (OUIs), Company IDs (CIDs), and Organization Identifiers are specified in two forms: an ordered sequence of octets, and a numeric form. Treating the OUI, CID, or Organization Identifier as an ordered sequence of octets, the leftmost octet is always transferred first. This is equivalent to transmitting the most significant octet of the numeric form first. Values specified in decimal are coded in natural binary unless otherwise stated. The values in Table 9-1 are in binary, with the bit assignments shown in the table. Values in other tables are shown in decimal notation. 636 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications An ASCII or UTF-8 string a sequence of ASCII-encoded octets without a terminating null. For evaluation purposes a nonce is interpreted as a sequence of octets with the most significant octet first and the most significant bit of an octet first. Reception, in references to frames or fields within frames (e.g., received Beacon frames or a received Duration/ID field), applies to MPDUs indicated from the PHY without error and validated by FCS within the MAC sublayer. Without further qualification, reception by the MAC sublayer implies that the frame contents are valid, and that the protocol version is supported (see 9.2.4.1.2), with no implication regarding frame addressing or regarding whether the frame type or other fields in the MAC header are meaningful to the MAC entity that has received the frame. A frame that contains the HT Control field is referred to as a +HTC frame. A Control Wrapper frame is a +HTC frame. A QoS Data frame that is transmitted by a mesh STA is referred to as a mesh Data frame. NOTEâ€”Subclause 9.2.4.1.4 constrains the setting of the From DS and To DS subfields in mesh Data frames. Parentheses enclosing portions of names or acronyms are used to designate a set of related names that vary based on the inclusion of the parenthesized portion. For example, â€” QoS +CF-Poll frame refers to the three QoS data subtypes that include â€œ+CF-Pollâ€: the QoS Data +CF-Poll frame, subtype 1010; QoS Data +CF-Ack +CF-Poll frame, subtype 1011; and QoS CF- Ack +CF-Poll frame, subtype 1111. â€” QoS CF-Poll frame refers specifically to the QoS CF-Poll frame, subtype 1110. â€” QoS (+)CF-Poll frame refers to all four QoS data subtypes with CF-Poll: the QoS CF-Poll frame, subtype 1110; the QoS CF-Ack +CF-Poll frame, subtype 1111; the QoS Data +CF-Poll frame, subtype 1010; and the QoS Data +CF-Ack +CF-Poll frame, subtype 1011. â€” QoS (+)Null frame refers to all three QoS data subtypes with â€œno dataâ€: the QoS Null (no data) frame, subtype 1100; the QoS CF-Poll (no data) frame, subtype 1110; and the QoS CF-Ack +CF- Poll frame, subtype 1111. â€” QoS +CF-Ack frame refers to the three QoS data subtypes that include â€œ+CF-Ackâ€: the QoS Data +CF-Ack frame, subtype 1001; QoS Data +CF-Ack +CF-Poll frame, subtype 1011; and QoS CF- Ack +CF-Poll frame, subtype 1111. â€” Whereas (QoS) CF-Poll frame refers to the QoS CF-Poll frame, subtype 1110, and the CF-Poll frame, subtype 0110. Reserved fields and subfields are set to 0 upon transmission and are ignored upon reception. 9.2.3 General frame format The MAC frame format comprises a set of fields that occur in a fixed order in all frames. Figure 9-1 depicts the general MAC frame format. The first three fields (Frame Control, Duration/ID, and Address 1) and the last field (FCS) in Figure 9-1 constitute the minimal frame format and are present in all frames, including reserved types and subtypes. The fields Address 2, Address 3, Sequence Control, Address 4, QoS Control, HT Control, and Frame Body are present only in certain frame types and subtypes. Each field is defined in 9.2.4. The format of each of the individual subtypes of each frame type is defined in 9.3. The components of management frame bodies are defined in 9.4. The formats of Action frames are defined in 9.6. The Frame Body field is of variable size, constrained as defined in 9.2.4.7.1. 637 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Octets: 2 2 6 0 or 6 0 or 6 0 or 2 0 or 6 0 or 2 0 or 4 variable 4 Frame Duration Address Address Address Sequence Address QoS HT Frame Control /ID 1 2 3 Control 4 Control Control Body FCS MAC header Figure 9-1â€”MAC frame format 9.2.4 Frame fields 9.2.4.1 Frame Control field 9.2.4.1.1 General The first three subfields of the Frame Control field are Protocol Version, Type, and Subtype. The remaining subfields of the Frame Control field depend on the setting of the Type and Subtype subfields. When the value of the Type subfield is not equal to 1 or the value of the Subtype subfield is not equal to 6, the remaining subfields within the Frame Control field are To DS, From DS, More Fragments, Retry, Power Management, More Data, Protected Frame, and +HTC/Order. In this case, the format of the Frame Control field is illustrated in Figure 9-2. B0 B1 B2 B3 B4 B7 B8 B9 B10 B11 B12 B13 B14 B15 Protocol Type Subtype To From More Retry Power More Protected +HTC/ Version DS DS Frag- Management Data Frame Order ments Bits: 2 2 4 1 1 1 1 1 1 1 1 Figure 9-2â€”Frame Control field when Type is not equal to 1 or Subtype is not equal to 6 When the value of the Type subfield is equal to 1 and the value of the Subtype subfield is equal to 6, the remaining subfields within the Frame Control field are the following: Control Frame Extension, Power Management, More Data, Protected Frame, and +HTC/Order. In this case, the format of the Frame Control field is illustrated in Figure 9-3. B0 B1 B2 B3 B4 B7 B8 B11 B12 B13 B14 B15 Protocol Type Subtype Control Frame Power More Protected +HTC/ Version Extension Management Data Frame Order Bits: 2 2 4 4 1 1 1 1 Figure 9-3â€”Frame Control field when Type is equal to 1 and Subtype is equal to 6 9.2.4.1.2 Protocol Version subfield The Protocol Version subfield is 2 bits in length and is invariant in size and placement across all revisions of this standard. For this standard, the value of the protocol version is 0. All other values are reserved. The revision level is incremented only when a fundamental incompatibility exists between a new revision and the prior edition of the standard. See 10.27.2. 9.2.4.1.3 Type and Subtype subfields The Type subfield is 2 bits in length, and the Subtype subfield is 4 bits in length. The Type and Subtype subfields together identify the function of the frame. There are three frame types: control, data, and 638 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications management. Each of the frame types has several defined subtypes. In Data frames, the most significant bit (MSB) of the Subtype subfield, B7, is defined as the QoS subfield. Table 9-1 defines the valid combinations of type and subtype. (The numeric values in Table 9-1 are shown in binary.) Table 9-1â€”Valid type and subtype combinations Type value Type Subtype value Subtype description B3 B2 description B7 B6 B5 B4 00 Management 0000 Association Request 00 Management 0001 Association Response 00 Management 0010 Reassociation Request 00 Management 0011 Reassociation Response 00 Management 0100 Probe Request 00 Management 0101 Probe Response 00 Management 0110 Timing Advertisement 00 Management 0111 Reserved 00 Management 1000 Beacon 00 Management 1001 ATIM 00 Management 1010 Disassociation 00 Management 1011 Authentication 00 Management 1100 Deauthentication 00 Management 1101 Action 00 Management 1110 Action No Ack 00 Management 1111 Reserved 01 Control 0000â€“0011 Reserved 01 Control 0100 Beamforming Report Poll 01 Control 0101 VHT NDP Announcement 01 Control 0110 Control Frame Extension 01 Control 0111 Control Wrapper 01 Control 1000 Block Ack Request (BlockAckReq) 01 Control 1001 Block Ack (BlockAck) 01 Control 1010 PS-Poll 01 Control 1011 RTS 01 Control 1100 CTS 01 Control 1101 Ack 01 Control 1110 CF-End 01 Control 1111 CF-End +CF-Ack 10 Data 0000 Data 10 Data 0001 Data +CF-Ack 10 Data 0010 Data +CF-Poll 639 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-1â€”Valid type and subtype combinations (continued) Type value Type Subtype value Subtype description B3 B2 description B7 B6 B5 B4 10 Data 0011 Data +CF-Ack +CF-Poll 10 Data 0100 Null (no data) 10 Data 0101 CF-Ack (no data) 10 Data 0110 CF-Poll (no data) 10 Data 0111 CF-Ack +CF-Poll (no data) 10 Data 1000 QoS Data 10 Data 1001 QoS Data +CF-Ack 10 Data 1010 QoS Data +CF-Poll 10 Data 1011 QoS Data +CF-Ack +CF-Poll 10 Data 1100 QoS Null (no data) 10 Data 1101 Reserved 10 Data 1110 QoS CF-Poll (no data) 10 Data 1111 QoS CF-Ack +CF-Poll (no data) 11 Extension 0000 DMG Beacon 11 Extension 0001â€“1111 Reserved Each Subtype subfield bit position is used to indicate a specific modification of the basic Data frame (subtype 0). Frame Control bit 4 is set to 1 in data subtypes that include +CF-Ack, bit 5 is set to 1 in data subtypes that include +CF-Poll, bit 6 is set to 1 in data subtypes that contain no Frame Body field, and bit 7 is set to 1 in the QoS data subtypes, which have QoS Control fields in their MAC headers. The Control Frame Extension subtype is used to increase the subtype space by reusing bits B8â€“B11. These additional Control frames are defined in Table 9-2. Table 9-2â€”Control Frame Extension Type value Subtype value Control Frame Extension value Description B3 B2 B7 B6 B5 B4 B11 B10 B9 B8 01 0110 0000 Reserved 01 0110 0001 Reserved 01 0110 0010 Poll 01 0110 0011 SPR 01 0110 0100 Grant 01 0110 0101 DMG CTS 01 0110 0110 DMG DTS 01 0110 0111 Grant Ack 01 0110 1000 SSW 640 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-2â€”Control Frame Extension (continued) Type value Subtype value Control Frame Extension value Description B3 B2 B7 B6 B5 B4 B11 B10 B9 B8 01 0110 1001 SSW-Feedback 01 0110 1010 SSW-Ack 01 0110 1011â€“1111 Reserved 9.2.4.1.4 To DS and From DS subfields The meaning of the combinations of values for the To DS and From DS subfields in Data frames are shown in Table 9-3. Table 9-3â€”To/From DS combinations in Data frames To DS and Meaning From DS values To DS = 0 A Data frame from one STA to another STA within the same IBSS or the same PBSS, a Data From DS = 0 frame direct from one non-AP STA to another non-AP STA within the same infrastructure BSS, or a Data frame outside the context of a BSS. This is the only valid combination for Data frames transmitted by an IBSS or PBSS STA, or outside the context of a BSS. To DS = 1 A Data frame destined for the DS or being sent by a STA associated with an AP to the Port From DS = 0 Access Entity in that AP. To DS = 0 A Data frame exiting the DS or being sent by the Port Access Entity in an AP, or a group From DS = 1 addressed mesh Data frame with the Mesh Control field present using the three-address MAC header format. This is the only valid combination for Data frames transmitted by an AP and group addressed Data frames transmitted by a mesh STA. To DS = 1 A Data frame using the four-address MAC header format. This standard defines procedures From DS = 1 for using this combination of field values only in a mesh BSS. This is the only valid combination for individually addressed Data frames transmitted by a mesh STA. The meanings of the combinations of values of the management frame To DS and From DS subfields are shown in Table 9-4. In Control frames, To DS and From DS, when present, are both zero. NOTEâ€”In Control frames of subtype Control Frame Extension, the To DS and From DS subfields are not defined, and their bit positions are part of the Control Frame Extension field (see 9.2.4.1.3, Table 9-2). 641 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-4â€”To/From DS combinations in Management frames To DS and Meaning From DS values To DS = 0 All non-QMF Management frames. From DS = 0 To DS = 1 All QMF Management frames. From DS = 0 To DS = 0 This combination is reserved. From DS = 1 To DS = 1 This combination is reserved. From DS = 1 9.2.4.1.5 More Fragments subfield The More Fragments subfield is 1 bit in length and is set to 1 in all Data or Management frames that have another fragment of the current MSDU or current MMPDU to follow. It is set to 0 in all other frames in which the More Fragments subfield is present. NOTEâ€”In Control frames of subtype Control Frame Extension, the More Fragments subfield is not present, and its bit position is part of the Control Frame Extension field (see 9.2.4.1.3, Table 9-2). 9.2.4.1.6 Retry subfield The Retry subfield is 1 bit in length and is set to 1 in any Data or Management frame that is a retransmission of an earlier frame, except as specified in 10.24.3. It is set to 0 in all other frames in which the Retry subfield is present. A receiving STA uses this indication to aid in the process of eliminating duplicate frames. NOTEâ€”In Control frames of subtype Control Frame Extension, the Retry subfield is not present, and its bit position is part of the Control Frame Extension field (see 9.2.4.1.3, Table 9-2). 9.2.4.1.7 Power Management subfield The Power Management subfield is 1 bit in length and is used to indicate the power management mode of a STA. The value of this subfield is either reserved (as defined below) or remains constant in each frame from a particular STA within a frame exchange sequence (see Annex G). The value indicates the mode of the STA after the successful completion of the frame exchange sequence. In an infrastructure BSS or PBSS, the following applies: â€” The Power Management subfield is valid only in frame exchanges as described in 11.2.3 and 11.2.7. In such exchanges, a value of 1 indicates that the STA will be in PS mode. A value of 0 indicates that the STA will be in active mode. â€” The Power Management subfield is reserved in all Management frames transmitted by a STA to an AP or PCP with which it is not associated. â€” The Power Management subfield is reserved in all frames transmitted by the AP. In an IBSS, the Power Management subfield is valid only in certain frames as described in 11.2.4.4. In such frames, a value of 1 indicates that the STA will be in PS mode. A value of 0 indicates that the STA will be in active mode. 642 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications In an MBSS, the Power Management subfield is valid only in frame exchanges as described per the mesh power management mode transitions rules in 14.14. In such exchanges, the value indicates the STAâ€™s power management mode (see 14.14). 9.2.4.1.8 More Data subfield The More Data subfield is 1 bit in length and is used differently by a non-DMG STA and by a DMG STA. A non-DMG STA uses the More Data subfield to indicate to a STA in PS mode that more BUs are buffered for that STA at the AP. The More Data subfield is valid in individually addressed Data or Management frames transmitted by an AP to a STA in PS mode. A value of 1 indicates that at least one additional buffered BU is present for the same STA. A non-DMG STA optionally sets the More Data subfield to 1 in individually addressed data type frames transmitted by a CF-Pollable STA to the PC in response to a CF-Poll to indicate that the STA has at least one additional buffered MSDU available for transmission in response to a subsequent CF-Poll. An AP optionally sets the More Data subfield to 1 in Ack frames to a non-DMG STA from which it has received a frame that contains a QoS Capability element in which the More Data Ack subfield is equal to 1 and that has one or more ACs that are delivery enabled and that is in PS mode to indicate that the AP has a pending transmission for the STA. A TDLS peer STA optionally sets the More Data subfield to 1 in Ack frames to a STA that has TDLS peer PSM enabled and that has the More Data Ack subfield equal to 1 in the QoS Capability element of its transmitted TDLS Setup Request frame or TDLS Setup Response frame to indicate that it has a pending transmission for the STA. The More Data subfield is 1 in individually addressed frames transmitted by a mesh STA to a peer mesh STA that is either in light sleep mode or in deep sleep mode for the corresponding mesh peering, when additional BUs remain to be transmitted to this peer mesh STA. The More Data subfield is set to 1 in individually addressed frames transmitted by a VHT AP to a VHT STA when both support the VHT TXOP power save feature (as determined from their VHT Capabilities elements) to indicate that at least one additional buffered BU is present for the STA. See 11.2.3.19. A non-DMG STA sets the More Data subfield to 0 in all other individually addressed frames. A non-DMG STA sets the More Data subfield to 1 in non-GCR-SP group addressed frames transmitted by the AP when additional group addressed bufferable units (BUs) that are not part of an active GCR-SP remain to be transmitted by the AP during this beacon interval. The More Data subfield is set to 0 in non- GCR-SP group addressed frames transmitted by the AP when no more group addressed BUs that are not part of an active GCR-SP remain to be transmitted by the AP during this beacon interval and in all group addressed frames transmitted by non-AP STAs. The More Data subfield is set to 1 in GCR-SP group addressed frames transmitted by the AP when additional group addressed BUs that are part of an active GCR-SP remain to be transmitted by the AP during this GCR-SP. The More Data subfield is set to 0 in GCR-SP group addressed frames transmitted by the AP when no more group addressed BUs that are part of an active GCR-SP remain to be transmitted by the AP during this GCR-SP. The More Data subfield is 1 in group addressed frames transmitted by a mesh STA when additional group addressed BUs remain to be transmitted. The More Data subfield is 0 in group addressed frames transmitted by a mesh STA when no more group addressed BUs remain to be transmitted. 643 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A DMG STA sets the More Data subfield as follows: â€” In individually addressed frames, it is set to 1 to indicate that the STA has MSDUs or A-MSDUs buffered for transmission to the frameâ€™s recipient during the current SP or TXOP. â€” It is set to 1 in group addressed frames transmitted by the AP when additional group addressed BUs remain to be transmitted by the AP during this beacon interval. The More Data subfield is set to 0 in group addressed frames transmitted by the AP when no more group addressed BUs remain to be transmitted by the AP during this beacon interval. A DMG STA does not set the More Data bit to 1 if it does not have any MSDUs or A-MSDUs buffered for transmission to the frameâ€™s recipient during the current SP or TXOP. 9.2.4.1.9 Protected Frame subfield The Protected Frame subfield is 1 bit in length. The Protected Frame subfield is set to 1 if the Frame Body field contains information that has been processed by a cryptographic encapsulation algorithm. The Protected Frame subfield is reserved in Control frames of subtype Control Frame Extension. When the Protected Frame subfield is equal to 1, the Frame Body field is protected utilizing the cryptographic encapsulation algorithm and expanded as defined in Clause 12. The Protected Frame subfield is set to 0 in Data frames of subtype Null, CF-Ack (no data), CF-Poll (no data), CF-Ack +CF-Poll (no data), QoS Null (no data), QoS CF-Poll (no data), and QoS CF-Ack +CF-Poll (no data) (see, for example, 12.5.2.2 and 12.5.3.1 that show that the frame body needs to be 1 octet or longer to apply the encapsulation). 9.2.4.1.10 +HTC/Order subfield The +HTC/Order subfield is 1 bit in length. It is used for two purposes: â€” It is set to 1 in a non-QoS Data frame transmitted by a non-QoS STA to indicate that the frame contains an MSDU, or fragment thereof, that is being transferred using the StrictlyOrdered service class. â€” It is set to 1 in a QoS Data or Management frame transmitted with a value of HT_GF, HT_MF, or VHT for the FORMAT parameter of the TXVECTOR to indicate that the frame contains an HT Control field. Otherwise, the +HTC/Order subfield is set to 0. NOTEâ€”The +HTC/Order subfield is always set to 0 for frames transmitted by a DMG STA. 9.2.4.2 Duration/ID field The Duration/ID field is 16 bits in length. The contents of this field vary with frame type and subtype, with whether the frame is transmitted during the CFP, and with the QoS capabilities of the sending STA. The contents of the field are defined as follows: a) In Control frames of subtype PS-Poll, the Duration/ID field carries the association identifier (AID) of the STA that transmitted the frame in the 14 least significant bits (LSB), and the 2 most significant bits (MSB) both set to 1. b) In frames transmitted by the PC and non-QoS STAs, during the CFP, the Duration/ID field is set to a fixed value of 32 768. c) In all other frames sent by non-QoS STAs and Control frames sent by QoS STAs, the Duration/ID field contains a duration value as defined for each frame type in 9.3. d) In Data and Management frames sent by QoS STAs, the Duration/ID field contains a duration value as defined for each frame type in 9.2.5. See 10.27.3 on the processing of this field in received frames. 644 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The encoding of the Duration/ID field is given in Table 9-5. Table 9-5â€”Duration/ID field encoding Bits 0â€“13 Bit 14 Bit 15 Usage 0â€“32 767 0 Duration value (in microseconds) within all frames except: â€” PS-Poll frames transmitted during the CP â€” frames transmitted during the CFP using the HCF 0 0 1 Fixed value under point coordination function (PCF) within frames transmitted during the CFP. 1â€“16 383 0 1 Reserved 0 1 1 Reserved 1â€“2007 1 1 AID in PS-Poll frames. 2008â€“16 383 1 1 Reserved See also 9.7.3 on the setting of the Duration/ID field of MAC headers of MPDUs in an A-MPDU. 9.2.4.3 Address fields 9.2.4.3.1 General There are four address fields in the MAC frame format. These fields are used to indicate the basic service set identifier (BSSID), source address (SA), destination address (DA), transmitting STA address (TA), and receiving STA address (RA). Certain frames might not contain some of the address fields. Certain address field usage is specified by the relative position of the address field (1â€“4) within the MAC header, independent of the type of address present in that field. For example, receiver address matching is always performed on the contents of the Address 1 field in received frames, and the receiver address of CTS and Ack frames is always obtained from the Address 2 field in the corresponding RTS frame, or from the frame being acknowledged. 9.2.4.3.2 Address representation Each Address field contains a 48-bit address as defined in Clause 8 of IEEE Std 802-2014. 9.2.4.3.3 Address designation A MAC sublayer address is one of the following two types: a) Individual address. The address assigned to a particular STA on the network. b) Group address. A multidestination address, which might be in use by one or more STAs on a given network. The two kinds of group addresses are as follows: 1) Multicast-group address. An address associated by higher level convention with a group of logically related STAs. 2) Broadcast address. A distinguished, predefined group address that always denotes the set of all STAs on a given LAN. All 1s are interpreted to be the broadcast address. This group is predefined for each communication medium to consist of all STAs actively connected to that medium; it is used to broadcast to all of the active STAs on that medium. 645 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The address space is also partitioned into locally administered and universal (globally administered) addresses. The nature of a body and the procedures by which it administers these universal (globally administered) addresses is beyond the scope of this standard. See IEEE Std 802-2014 for more information. 9.2.4.3.4 BSSID field The BSSID field is a 48-bit field of the same format as an IEEE 802 MAC address. When dot11OCBActivated is false, the value of this field uniquely identifies each BSS. The value of this field, in an infrastructure BSS, is the MAC address currently in use by the STA in the AP of the BSS. The value of this field in a PBSS is the MAC address of the PCP. The value of this field in an IBSS is a locally administered IEEE MAC address formed from a 46-bit random number generated according to the procedure defined in 11.1.4. The Individual/Group bit of the address is set to 0. The Universal/Local bit of the address is set to 1. This mechanism is used to provide a high probability of selecting a unique BSSID. The value of all 1s is used to indicate the wildcard BSSID. The wildcard value is not used in the BSSID field except where explicitly permitted in this standard. When dot11OCBActivated is true, the wildcard value is used in the BSSID field. When dot11OCBActivated is false and the BSSID field contains the wildcard value, the Address 1 (DA) field is also set to all 1s to indicate the broadcast address. 9.2.4.3.5 DA field The DA field contains an IEEE MAC individual or group address that identifies the MAC entity or entities intended as the final recipient(s) of the MSDU (or fragment thereof) or A-MSDU, as defined in 9.3.2.1, contained in the frame body field. 9.2.4.3.6 SA field The SA field contains an IEEE MAC individual address that identifies the MAC entity from which the transfer of the MSDU (or fragment thereof) or A-MSDU, as defined in 9.3.2.1, contained in the frame body field was initiated. The Individual/Group bit is always transmitted as a 0 in the source address. 9.2.4.3.7 RA field The RA field contains an IEEE MAC individual or group address that identifies the intended immediate recipient STA(s), on the WM, for the information contained in the frame body field. 9.2.4.3.8 TA field The TA field contains an IEEE MAC address that identifies the STA that has transmitted, onto the WM, the MPDU contained in the frame body field. If the Individual/Group bit is 0, then the TA field is the individual address of the STA; otherwise, the TA field is a bandwidth signaling TA, indicating that the frame carries additional information in the scrambling sequence (see 9.3.1.2, 10.7.6.6, and 10.7.11). 9.2.4.4 Sequence Control field 9.2.4.4.1 Sequence Control field structure The Sequence Control field is 16 bits in length and consists of two subfields, the Sequence Number and the Fragment Number. The format of the Sequence Control field is illustrated in Figure 9-4. The Sequence Control field is not present in Control frames. 646 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B0 B3 B4 B15 Fragment Number Sequence Number Bits: 4 12 Figure 9-4â€”Sequence Control field 9.2.4.4.2 Sequence Number field Each MSDU, A-MSDU, or MMPDU is assigned a sequence number. See 10.3.2.11. Sequence numbers are not assigned to Control frames, as the Sequence Control field is not present in those frames. The Sequence Number field in Data frames is a 12-bit field indicating the sequence number of the MSDU or A-MSDU. The Sequence Number field in QMFs comprises the QMF Sequence Number subfield and the AC Index (ACI) subfield. The QMF Sequence Number subfield is a 10-bit subfield indicating the sequence number of the frame. The ACI subfield is a 2-bit subfield indicating the ACI of the frame. The format of the Sequence Number field in QMFs is shown in Figure 9-5. B4 B13 B14 B15 QMF Sequence Number ACI Bits: 10 2 Figure 9-5â€”Sequence Number field in QMFs The value of the ACI subfield represents the ACI of the frame as defined in 9.4.2.29. The Sequence Number field in Management frames that are not QMFs is a 12-bit field indicating the sequence number of the frame. Each fragment of an MSDU or MMPDU contains a copy of the sequence number assigned to that MSDU or MMPDU. The sequence number remains constant in all retransmissions of an MSDU, MMPDU, or fragment thereof, except when the MSDU is delivered via both DMS and group addressed delivery via NoAck, GCR unsolicited retry, or GCR block ack retransmission policies. In such cases, the sequence numbers assigned to the MSDUs (re)transmitted using group addressed delivery need not match the sequence number of the corresponding individually addressed A-MSDUs delivered via DMS. 9.2.4.4.3 Fragment Number field The Fragment Number field is a 4-bit field indicating the number of each fragment of an MSDU or MMPDU. The fragment number is set to 0 in the first or only fragment of an MSDU or MMPDU and is incremented by one for each successive fragment of that MSDU or MMPDU. The fragment number is set to 0 in the only fragment of an A-MSDU. The fragment number remains constant in all retransmissions of the fragment. 9.2.4.5 QoS Control field 9.2.4.5.1 QoS Control field structure The QoS Control field is a 16-bit field that identifies the TC or TS to which the frame belongs as well as various other QoS-related, A-MSDU related, and mesh-related information about the frame that varies by 647 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications frame type, subtype, and type of transmitting STA. The QoS Control field is present in all Data frames in which the QoS subfield of the Subtype subfield is equal to 1 (see 9.2.4.1.3). When not transmitted within a DMG PPDU, each QoS Control field comprises five or eight subfields, as defined for the particular sender (HC or non-AP STA) and frame type and subtype. The usage of these subfields and the various possible layouts of the QoS Control field are described 9.2.4.5.2 to 9.2.4.5.12 and illustrated in Table 9-6. See 10.13.1 for constraints on the contents of the QoS Control field when present in an A-MPDU. Table 9-6â€”QoS Control field Applicable frame Bits Bits 11- Bit 4 Bits 5-6 Bit 7 Bits 8 Bit 9 Bit 10 (sub) types 0â€“3 15 QoS CF-Poll and QoS CF- Ack Ack +CF-Poll frames sent TID EOSP Reserved TXOP Limit Policy by HC QoS Data +CF-Poll and TID EOSP Ack A-MSDU TXOP Limit QoS Data +CF-Ack +CF- Policy Present Poll frames sent by HC QoS Data and QoS Data TID EOSP Ack A-MSDU AP PS Buffer State +CF-Ack frames sent by Policy Present HC QoS Null frames sent by Ack TID EOSP Reserved AP PS Buffer State HC Policy QoS Data and QoS Data TID 0 Ack A-MSDU TXOP Duration Requested +CF-Ack frames sent by Policy Present non-AP STAs that are not a TID 1 Ack A-MSDU Queue Size TPU buffer STA or a TPU Policy Present sleep STA in a nonmesh BSS QoS Null frames sent by Ack TID 0 Reserved TXOP Duration Requested non-AP STAs that are not a Policy TPU buffer STA or a TPU sleep STA in a nonmesh Ack TID 1 Reserved Queue Size BSS Policy QoS Data and QoS Data +CF-Ack frames sent by Ack A-MSDU TID EOSP Reserved TPU buffer STAs in a Policy Present nonmesh BSS QoS Null frames sent by Ack TPU buffer STAs in a TID EOSP Reserved Reserved Policy nonmesh BSS QoS Data and QoS Data +CF-Ack frames sent by Reserv Ack A-MSDU TID Reserved TPU sleep STAs in a ed Policy Present nonmesh BSS QoS Null frames sent by Reserv Ack TPU sleep STAs in a TID Reserved Reserved ed Policy nonmesh BSS Mesh Mesh All frames sent by mesh Ack A-MSDU Power TID EOSP Control RSPI Reserved STAs in a mesh BSS Policy Present Save Present Level 648 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The format of the QoS Control field for MPDUs transmitted within a DMG PPDU is provided in Table 9-7. Data subtypes not shown in the table are not transmitted within a DMG PPDU. Table 9-7â€”QoS Control field for frames transmitted within a DMG PPDU Applicable Bits Bits Bits frame Bit 4 Bit 7 Bit 8 Bit 9 Bit 14 Bit 15 0â€“3 5â€“6 10â€“13 (sub-)types QoS Data TID EOSP Ack A-MSDU A-MSDU RDG/ Buffered Reserved AC Policy Present Type More AC Constraint PPDU QoS Null TID EOSP Ack Reserved Reserved RDG/ Buffered Reserved AC Policy More AC Constraint PPDU 9.2.4.5.2 TID subfield The TID subfield identifies the TC or TS to which the corresponding MSDU (or fragment thereof) or A-MSDU in the Frame Body field belongs. The TID subfield also identifies the TC or TS of traffic for which a TXOP is being requested, through the setting of TXOP duration requested or queue size. The encoding of the TID subfield depends on the access policy (see 9.4.2.30) and is shown in Table 9-8. Additional information on the interpretation of the contents of this field appears in 5.1.1.3. Table 9-8â€”TID subfield Allowed values in bits 0â€“3 Access policy Usage (TID subfield) EDCA UP for either TC or TS, regardless of whether admission 0â€“7 control is required HCCA, SPCA TSID 8â€“15 HEMM, TSID, regardless of the access mechanism used 8â€“15 SEMM In QoS Data +CF-Poll frames, the TID subfield in the QoS Control field indicates the TID of the data. In QoS (+)CF-Poll frames of subtype Null, the TID subfield in the QoS Control field indicates the TID for which the poll is intended. The requirement to respond to that TID is nonbinding, and a STA can respond with any frame (see 10.22.3.5.1). For STAs where dot11OCBActivated is true, traffic streams are not used and the TID always corresponds to a TC. 9.2.4.5.3 EOSP (end of service period) subfield The EOSP subfield is 1 bit in length and is used by the HC to indicate the end of the current service period (SP) and by a DMG STA to indicate the end of the current SP or the end of the current allocated CBAP with individually addressed destination AID. The HC sets the EOSP subfield to 1 in its transmission and retransmissions of the SPâ€™s final frame to end an SP and sets it to 0 otherwise. To end an SP allocation or a CBAP allocation with individually addressed destination AID, the DMG STA sets the EOSP subfield to 1 in its final frame transmission and retransmissions within the allocation; otherwise, the DMG STA sets the EOSP subfield to 0. 649 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The mesh STA uses the EOSP subfield to indicate the end of the current mesh peer service period in which it operates as the owner. The mesh STA sets the EOSP subfield to 1 in its transmission and retransmissions of the mesh peer service periodâ€™s final frame to end a mesh peer service period, and sets it to 0 otherwise. See 14.14.9.4 for details. If dot11RobustAVStreamingImplemented is true, then the HC sets the EOSP subfield to 1 in a GCR-SP group addressed frame in order to indicate that no more GCR-SP frames of that group address are to be transmitted by the AP until the next scheduled SP for this GCR-SP stream. NOTEâ€”As GCR-A frames are sent outside of any SP, the EOSP subfield is set to 0 in a group addressed frame delivered using the GCR-A procedures described in 11.24.16.3.8. 9.2.4.5.4 Ack Policy subfield The Ack Policy subfield is 2 bits in length and identifies the acknowledgment policy that is followed upon the delivery of the MPDU. The interpretation of these 2 bits is given in Table 9-9. Table 9-9â€”Ack Policy subfield in QoS Control field of QoS Data frames Bits in QoS Control field Meaning Bit 5 Bit 6 0 0 Normal Ack or Implicit Block Ack Request. In a frame that is a non-A-MPDU frame or VHT single MPDU: The addressed recipient returns an Ack or QoS +CF-Ack frame after a short interframe space (SIFS) period, according to the procedures defined in 10.3.2.9 and 10.22.3.5. A non-DMG STA sets the Ack Policy subfield for individually addressed QoS Null (no data) frames to this value. Otherwise: The addressed recipient returns a BlockAck frame, either individually or as part of an A-MPDU starting a SIFS after the PPDU carrying the frame, according to the procedures defined in 10.3.2.9, 10.24.7.5, 10.24.8.3, 10.28.3, 10.28.4, and 10.32.3. 1 0 No Ack The addressed recipient takes no action upon receipt of the frame. More details are provided in 10.25. The Ack Policy subfield is set to this value in all individually addressed frames in which the sender does not require acknowledgment. The Ack Policy subfield is also set to this value in all group addressed frames that use the QoS frame format except with a TID for which a block ack agreement exists. This value of the Ack Policy subfield is not used for QoS Data frames with a TID for which a block ack agreement exists. The Ack Policy subfield for group addressed QoS Null (no data) frames is set to this value. 650 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-9â€”Ack Policy subfield in QoS Control field of QoS Data frames (continued) Bits in QoS Control field Meaning Bit 5 Bit 6 0 1 No explicit acknowledgment or PSMP Ack. When bit 6 of the Frame Control field (see 9.2.4.1.3) is set to 1: There might be a response frame to the frame that is received, but it is neither the Ack frame nor any Data frame of subtype +CF-Ack. The Ack Policy subfield for QoS CF-Poll and QoS CF-Ack +CF-Poll Data frames is set to this value. When bit 6 of the Frame Control field (see 9.2.4.1.3) is set to 0: The acknowledgment for a frame indicating PSMP Ack when it appears in a PSMP downlink transmission time (PSMP-DTT) is to be received in a later PSMP uplink transmission time (PSMP-UTT). The acknowledgment for a frame indicating PSMP Ack when it appears in a PSMP- UTT is to be received in a later PSMP-DTT. NOTEâ€”Bit 6 of the Frame Control field (see 9.2.4.1.3) indicates the absence of a data Frame Body field. When equal to 1, the QoS Data frame contains no Frame Body field, and any response is generated in response to a QoS CF-Poll or QoS CF-Ack +CF-Poll frame, but does not signify an acknowledgment of data. When set to 0, the QoS Data frame contains a Frame Body field, which is acknowledged as described in 10.29.2.7. 1 1 Block Ack The addressed recipient takes no action upon the receipt of the frame except for recording the state. The recipient can expect a BlockAckReq frame or implicit block ack request in the future to which it responds using the procedure described in 10.24. 9.2.4.5.5 TXOP Limit subfield The TXOP Limit subfield is an 8-bit field that is present in QoS Data frames of subtypes that include CF- Poll and specifies the time limit on a TXOP granted by a QoS (+)CF-Poll frame from an HC in an infrastructure BSS. In QoS Data frames with subtypes that include CF-Poll, the addressed STA is granted a TXOP that begins a SIFS after this frame and lasts no longer than the number of 32 s periods specified by the TXOP Limit subfield value. The range of time values is 32 s to 8160 s. A TXOP Limit subfield value of 0 indicates that only one MPDU or one QoS Null frame is to be transmitted immediately following the QoS (+)CF-Poll frame. 9.2.4.5.6 Queue Size subfield The Queue Size subfield is an 8-bit field that indicates the amount of buffered traffic for a given TC or TS at the STA sending this frame. The Queue Size subfield is present in QoS Data frames sent by non-AP STAs with bit 4 of the QoS Control field equal to 1. The AP might use information contained in the Queue Size subfield to determine the TXOP duration assigned to the STA. The queue size value is the total size, rounded up to the nearest multiple of 256 octets and expressed in units of 256 octets, of all MSDUs and A-MSDUs buffered at the STA (excluding the MSDU or A-MSDU of the present QoS Data frame) in the delivery queue used for MSDUs and A-MSDUs with TID values equal to the value in the TID subfield of this QoS Control field. A queue size value of 0 is used solely to indicate the absence of any buffered traffic in the queue used for the specified TID. A queue size value of 254 is used for all sizes greater than 64 768 octets. A queue size value of 255 is used to indicate an unspecified or unknown size. 651 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.2.4.5.7 TXOP Duration Requested subfield The TXOP Duration Requested subfield is present in QoS Data frames sent by STAs associated in a nonmesh BSS with bit 4 of the QoS Control field equal to 0. The TXOP Duration Requested subfield is an 8-bit field that indicates the duration, in units of 32 s, that the sending STA determines it needs for its next TXOP for the specified TID. A value of 0 indicates that no TXOP is requested for the specified TID in the current SP. A nonzero value represents a requested TXOP duration in the range 32 s to 8 160 s in increments of 32 s. See 10.22.3.5.2. 9.2.4.5.8 AP PS Buffer State subfield The AP PS Buffer State subfield, defined in Figure 9-6, is an 8-bit field that indicates the PS buffer state at the AP for a STA. The AP PS Buffer State subfield is further subdivided into three subfields: Buffer State Indicated, Highest-Priority Buffered AC, and AP Buffered Load. B8 B9 B10 B11 B12 B15 Reserved Buffer State Highest Priority QoS AP Indicated Buffered AC Buffered Load Bits: 1 1 2 4 Figure 9-6â€”QoS AP PS Buffer State subfield The Buffered State Indicated subfield is 1 bit in length and is used to indicate whether the AP PS buffer state is specified. A value of 1 indicates that the AP PS buffer state is specified. The Highest-Priority Buffered AC subfield is 2 bits in length and is used to indicate the AC of the highest priority traffic remaining that is buffered at the AP, excluding the MSDU or A-MSDU of the present frame. The AP Buffered Load subfield is 4 bits in length and is used to indicate the total buffer size, rounded up to the nearest multiple of 4096 octets and expressed in units of 4096 octets, of all MSDUs and A-MSDUs buffered at the QoS AP (excluding the MSDU or A-MSDU of the present QoS Data frame). An AP Buffered Load field value of 15 indicates that the buffer size is greater than 57 344 octets. An AP Buffered Load subfield value of 0 is used solely to indicate the absence of any buffered traffic for the indicated highest priority buffered AC when the Buffer State Indicated bit is 1. When the Buffered State Indicated subfield is equal to 0, the Highest-Priority Buffered AC subfield and the AP Buffered Load subfield are reserved. 9.2.4.5.9 A-MSDU Present subfield The A-MSDU Present subfield is 1 bit in length and indicates the presence of an A-MSDU. The A-MSDU Present subfield is set to 1 to indicate that the Frame Body field contains an entire A-MSDU as defined in 9.3.2.2. The A-MSDU Present subfield is set to 0 to indicate that the Frame Body field contains an MSDU or fragment thereof as defined in 9.3.2.1. NOTEâ€”A DMG STA, when the A-MSDU Present subfield is set to 1, can use one of two A-MSDU formats in the Frame Body. The specific A-MSDU format present is indicated by the A-MSDU Type subfield. 9.2.4.5.10 Mesh Control Present subfield The Mesh Control Present subfield is 1 bit in length, and indicates the presence of a Mesh Control field in the frame body. When the Mesh Control Present subfield is 1, the Frame Body field contains a Mesh Control field as defined in 9.2.4.7.3. The mesh STA sets the Mesh Control Present subfield to 1 in the mesh Data frame containing an unfragmented MSDU, an A-MSDU, or the first fragment of an MSDU. 652 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.2.4.5.11 Mesh Power Save Level subfield The Mesh Power Save Level subfield is 1 bit in length and indicates whether the mesh STAâ€™s peer-specific mesh power management mode will be deep sleep mode or light sleep mode after the successful completion of the frame exchange sequence. When the Power Management subfield in the Frame Control field in the frame is 1, the following applies: In individually addressed mesh Data frames, a value of 0 indicates that the mesh STAâ€™s peer-specific mesh power management mode for the recipient mesh STA will be light sleep mode (see 14.14.8.4). In individually addressed mesh Data frames, a value of 1 indicates that the mesh STAâ€™s peer-specific mesh power management mode for the recipient mesh STA will be deep sleep mode (see 14.14.8.5). In group addressed mesh Data frames, a value of 0 indicates that none of the peer-specific mesh power management modes of the mesh STA will be deep sleep mode. In group addressed mesh Data frames, a value of 1 indicates that at least one of the peer-specific mesh power management modes of the mesh STA is deep sleep mode. The Mesh Power Save Level subfield is reserved if the Power Management subfield in the Frame Control field is 0. 9.2.4.5.12 Receiver Service Period Initiated (RSPI) subfield The Receiver Service Period Initiated (RSPI) subfield is 1 bit in length. The subfield is set to 0 to indicate that the mesh peer service period, of which the receiver of this frame is the owner, is not initiated. The subfield is set to 1 to indicate that the mesh peer service period, of which the receiver of this frame is the owner, is initiated. The use of the RSPI subfield is described in 14.14.9.2. The RSPI subfield is reserved in group addressed frames. 9.2.4.5.13 A-MSDU Type subfield The A-MSDU Type subfield is 1 bit in length and indicates the type of A-MSDU present in the Frame Body. When the A-MSDU Type subfield is set to 0, the Frame Body field contains a Basic A-MSDU as defined in 9.3.2.2.2. When the A-MSDU Type subfield is set to 1, the Frame Body field contains a Short A-MSDU as defined in 9.3.2.2.3. The A-MSDU Type subfield is reserved if the A-MSDU Present subfield is set to 0. 9.2.4.5.14 RDG/More PPDU subfield The RDG/More PPDU subfield of the QoS Control field for DMG frames is interpreted differently depending on whether it is transmitted by an reverse direction (RD) initiator or an RD responder, as defined in Table 9-11. 9.2.4.5.15 AC Constraint subfield The AC Constraint subfield of the QoS Control field for DMG frames indicates whether the mapped AC of an RD Data frame is constrained to a single AC, as defined in Table 9-10. 9.2.4.5.16 Buffered AC subfield The Buffered AC subfield is a 4-bit bitmap that indicates buffered traffic for four ACs as defined in Figure 9-7. At least one BU for the indicated AC is buffered if the related subfield is set to 1. The Buffered AC subfield is reserved except in QoS Data frames and QoS Null frames. A non-AP and non-PCP STA can use information contained in the Buffered AC subfield to determine the ACs for which BU are buffered for it. 653 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B10 B11 B12 B13 BU for AC_VO BU for AC_VI BU for AC_BE BU for AC_BK Bits: 1 1 1 1 Figure 9-7â€”Buffered AC subfield 9.2.4.6 HT Control field 9.2.4.6.1 General The HT Control field is always present in a Control Wrapper frame and is present in QoS Data and Management frames as determined by the +HTC/Order subfield of the Frame Control field as defined in 9.2.4.1.10. NOTEâ€”The only control frame subtype for which HT Control field is present is the Control Wrapper frame. A Control frame that is described as +HTC (e.g., an RTS+HTC, CTS+HTC, BlockAck+HTC or BlockAckReq+HTC frame) implies the use of the Control Wrapper frame to carry that Control frame. The format of the 4-octet HT Control field is shown in Figure 9-8. B0 B1 B29 B30 B31 VHT HT Control Middle AC RDG/More Constraint PPDU Bits 1 29 1 1 Figure 9-8â€”HT Control field The HT Control field has two forms, the HT variant and the VHT variant. The two forms differ in the format of the HT Control Middle subfield, described in 9.2.4.6.2 for the HT variant and in 9.2.4.6.3 for the VHT variant and in the value of the VHT subfield. The VHT subfield of the HT Control field indicates whether the HT Control Middle subfield is the VHT Variant or the HT Variant. The VHT subfield is set to 1 to indicate that the HT Control Middle subfield is the VHT Variant and is set to 0 to indicate that the HT Control Middle subfield is the HT Variant. The AC Constraint subfield of the HT Control field indicates whether the mapped AC of an RD Data frame is constrained to a single AC, as defined in Table 9-10. Table 9-10â€”AC Constraint subfield values Value Description 0 The response to a reverse direction grant (RDG) contains Data frames from any TID; see 10.28.4. 1 The response to an RDG contains Data frames only from the same AC as the last Data frame received from the RD initiator; see 10.28.4. NOTEâ€”The AC of the last Data frame received from the RD initiator is determined directly from the TID of the received frame if the TID is between 0 and 7 inclusive or from the UP field of the TSPEC identified by the TID of the received frame if the TID is between 8 and 15 inclusive. 654 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The RDG/More PPDU subfield of the HT Control field is interpreted differently depending on whether it is transmitted by an RD initiator or an RD responder, as defined in Table 9-11. Table 9-11â€”RDG/More PPDU subfield values Role of Value Interpretation of value transmitting STA 0 Not an RD No reverse grant responder RD responder The PPDU carrying the frame is the last transmission by the RD responder 1 RD initiator An RDG is present RD responder The PPDU carrying the frame is followed by another PPDU 9.2.4.6.2 HT variant The format of the HT Control Middle subfield of the HT variant HT Control field is shown in Figure 9-9. B1 B15 B16 B17 B18 B19 B20 B21 B22 B23 B24 B25 B28 B29 Link HT NDP Calibration Calibration CSI/ Adaptation Position Sequence Reserved Steering Announce Reserved DEI Control ment Bits: 15 2 2 2 2 1 4 1 Figure 9-9â€”HT Control Middle subfield of the HT variant HT Control field The format of the Link Adaptation Control subfield of the HT variant HT Control field is defined in Figure 9-10. B1 B2 B5 B6 B8 B9 B15 TRQ MAI MFSI MFB/ASELC Bits: 1 4 3 7 Figure 9-10â€”Link Adaptation Control subfield 655 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The subfields of the Link Adaptation Control subfield are defined in Table 9-12. Table 9-12â€”Subfields of Link Adaptation Control subfield Subfield Meaning Definition TRQ Training request Set to 1 to request the responder to transmit a sounding PPDU. Set to 0 to indicate that the responder is not requested to transmit a sounding PPDU. See 10.32.2 and 10.34.2. MAI MCS request Set to 14 (indicating ASELI) to indicate that the MFB/ASELC subfield is (MRQ) or ASEL interpreted as ASELC. Otherwise, the MAI subfield is interpreted as shown indication in Figure 9-11, and the MFB/ASELC subfield is interpreted as MCS feedback (MFB). MFSI MCS feedback Set to the received value of MSI contained in the frame to which the MFB sequence identifier information refers. Set to 7 for unsolicited MFB. MFB/ASELC MCS feedback When the MAI subfield is equal to the value ASELI, this subfield is and antenna interpreted as defined in Figure 9-12 and Table 9-14. selection command/data Otherwise, this subfield contains recommended MFB. A value of 127 indicates that no feedback is present. The structure of the MAI subfield of the Link Adaptation Control subfield is defined in Figure 9-11. The subfields of the MAI subfield are defined in Table 9-13. B0 B1 B3 MRQ MSI Bits: 1 3 Figure 9-11â€”MAI subfield Table 9-13â€”Subfields of the MAI subfield Subfield Meaning Definition MRQ MCS request Set to 1 to indicate that MFB is requested. Set to 0 to indicate that no MFB is requested. MSI MRQ sequence identifier When the MRQ subfield is equal to 1, the MSI subfield contains a sequence number in the range 0 to 6 that identifies the specific request.When the MRQ subfield is equal to 0, the MSI subfield is reserved. 656 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The ASELC subfield of the Link Adaptation Control subfield contains the ASEL Command and ASEL Data subfields, as shown in Figure 9-12. The encoding of these subfields is shown in Table 9-14. B0 B2 B3 B6 ASEL Command ASEL Data Bits: 3 4 Figure 9-12â€”ASELC subfield Table 9-14â€”ASEL Command and ASEL Data subfields Interpretation of ASEL ASEL Command ASEL Data Command 0 Transmit Antenna Selection Number of remaining sounding PPDUs to be transmitted Sounding Indication (TXASSI) 0 to 15 See NOTE 1 Transmit Antenna Selection 0 when the command is Transmit ASEL Sounding Request Sounding Request (TXASSR) A number in the range 1 to 15, the number being the or Transmit ASEL Sounding number of the first sounding PPDU to be transmitted when Resumption the command is Transmit ASEL Sounding Resumption, where 0 corresponds to the first sounding PPDU in the original ASEL training sequence 2 Receive Antenna Selection Number of remaining sounding PPDUs to be received Sounding Indication (RXASSI) 0 to 15 See NOTE 3 Receive Antenna Selection Number of sounding PPDUs required Sounding Request (RXASSR) 0 to 15 4 Sounding Label Sequence number of the sounding PPDU corresponding to a channel state information (CSI) frame in ASEL feedback 0 to 15 5 No Feedback Due to ASEL A number in the range 0 to 15, the number being the Training Failure or Stale number of the first sounding PPDU that was not received Feedback properly, where 0 corresponds to the first sounding PPDU in the ASEL training sequence, or 0 if no sounding PPDUs were received properly, or 0 if this is a request for a full retraining sequence 6 Transmit Antenna Selection Number of remaining sounding PPDUs to be transmitted Sounding Indication requesting 0 to 15 feedback of explicit CSI (TXASSI-CSI) See NOTE 7 Reserved Reserved NOTEâ€”If the HT variant HT Control field is carried in a sounding PPDU, then the value of the ASEL Data field contains the remaining number of sounding frames following the current one. If null data packet (NDP) sounding frame is used, then the value in the ASEL Data field contains the number of NDPs following a non-NDP+HTC. The HT NDP Announcement subfield in the HT Control field is set to 1 to indicate NDP sounding. 657 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Calibration Position and Calibration Sequence subfields of the HT variant HT Control field are defined in Table 9-15. Table 9-15â€”Calibration control subfields Subfield Meaning Definition Calibration Position in calibration sounding Set to 0 indicates this is not a calibration frame. Position exchange sequence Set to 1 indicates calibration start. Set to 2 indicates sounding response. Set to 3 indicates sounding complete. Calibration Calibration sequence identifier The field is included in each frame within the calibration Sequence procedure and its value is unchanged for the frame exchanges during one calibration procedure. See 10.32.2.4.3. The Calibration Sequence subfield identifies an instance of the calibration procedure. The subfield is included in each frame within a calibration procedure, and its value is unchanged for frames within the same calibration procedure. The CSI/Steering subfield of the HT variant HT Control field indicates the type of feedback, as shown in Table 9-16. Table 9-16â€”CSI/Steering subfield values Value Definition 0 No feedback required 1 CSI 2 Noncompressed beamforming 3 Compressed beamforming The HT NDP Announcement subfield of the HT variant HT Control field indicates that an NDP will be transmitted after the frame (according to the rules described in 10.34). It is set to 1 to indicate that an NDP will follow; otherwise, it is set to 0. The DEI subfield of the HT Control field is 1 bit in length and is set by the transmitting STA to indicate the suitability of the corresponding MSDU or A-MSDU to be discarded if there are insufficient resources at the receiving STA. See 10.9 and 11.27.2. In a Management frame, the DEI subfield is reserved. 658 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.2.4.6.3 VHT variant The format of the HT Control Middle subfield of the VHT variant HT Control field is shown in Figure 9-13. B1 B2 B3 B5 B6 B8 B9 B23 B24 B26 B27 B28 B29 Reserved MRQ MSI/ MFSI/ MFB GID-H Coding FB Tx Unsolicited STBC GID-L Type Type MFB Bits: 1 1 3 3 15 3 1 1 1 Figure 9-13â€”HT Control Middle subfield of the VHT variant HT Control field The subfields of VHT variant HT Control field are defined in Table 9-17. Table 9-17â€”VHT variant HT Control field subfields Subfield Meaning Definition MRQ VHT-MCS Set to 1 to request VHT-MCS feedback (solicited MFB); otherwise, feedback request set to 0. MSI/STBC MRQ sequence If the Unsolicited MFB subfield is 0 and the MRQ subfield is 1, the identifier/STBC MSI/STBC subfield contains a sequence number in the range 0 to 6 indication that identifies the specific MCS feedback request. If the Unsolicited MFB subfield is 0 and the MRQ subfield is 0, the MSI/STBC subfield is reserved. If the Unsolicited MFB subfield is 1 and the MFB does not contain the value representing â€œno feedback is present,â€ the MSI/STBC field contains the Compressed MSI and STBC Indication subfields as shown in Figure 9-14. The STBC Indication subfield indicates whether the estimate in the MFB subfield is computed based on a PPDU using STBC encoding: Set to 0 if the PPDU was not STBC encoded Set to 1 if the PPDU was STBC encoded The Compressed MSI subfield contains a sequence number that identifies the specific MCS feedback request. It is in the range 0 to 3 if STBC Indication equals 0 or in the range 0 to 2 if STBC Indication equals 1. Otherwise, the MSI/STBC subfield is reserved. MFSI/GID-L MFB sequence If the Unsolicited MFB subfield is 0, the MFSI/GID-L subfield identifier/LSBs of contains the received value of MSI contained in the frame to which the group ID MFB information refers. If the Unsolicited MFB subfield is 1, the MFB does not contain the value representing â€œno feedback is present,â€ and the MFB is estimated from a VHT MU PPDU, then the MFSI/GID-L subfield contains the lowest 3 bits of group ID of that PPDU from which the MFB was estimated (bit 0 of the group ID appears in the lowest numbered bit of the field MFSI/GID-L). If the unsolicited MFB is estimated from an SU PPDU, the MFSI/GID-L subfield is set to all 1s. Otherwise, this subfield is reserved. MFB NUM_STS, VHT- MFB subfield is interpreted as defined in Table 9-18. This subfield MCS, BW and contains the recommended MFB. The combination of VHT-MCS=15 SNR feedback and NUM_STS=7 indicates that no feedback is present. 659 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-17â€”VHT variant HT Control field subfields (continued) Subfield Meaning Definition GID-H MSBs of group ID If the Unsolicited MFB subfield is 1, the MFB does not contain the value representing â€œno feedback is present,â€ and the unsolicited MFB is estimated from a VHT MU PPDU, then the GID-H subfield contains the highest 3 bits of group ID of the PPDU from which the unsolicited MFB was estimated (bit 3 of the group ID appears in the lowest numbered bit of the field GID-H). If the unsolicited MFB is estimated from an SU PPDU, the GID-H subfield is set to all 1s. Otherwise, this subfield is reserved. Coding Type Coding type of the If the Unsolicited MFB subfield is 1 and the MFB does not contain the measured PPDU value representing â€œno feedback is present,â€ the Coding Type subfield contains the Coding information (0 for BCC and 1 for LDPC) of the PPDU from which the unsolicited MFB was estimated. Otherwise, this subfield is reserved. FB Tx Type Transmission type If the Unsolicited MFB subfield is 1, the MFB does not contain the of the measured value representing â€œno feedback is present,â€ and FB Tx Type subfield PPDU is 0, then the unsolicited MFB is estimated from a VHT PPDU with RXVECTOR parameter BEAMFORMED equal to 0. If the Unsolicited MFB subfield is 1, the MFB does not contain the value representing â€œno feedback is present,â€ and the FB Tx Type subfield is 1, then the unsolicited MFB is estimated from a VHT PPDU with RXVECTOR parameter BEAMFORMED equal to 1. Otherwise, this subfield is reserved. Unsolicited MFB Unsolicited VHT- Set to 1 if the MFB is not a response to an MRQ. MCS feedback Set to 0 if the MFB is a response to an MRQ. indicator The format of the MSI/STBC subfield when the Unsolicited subfield is 1 is shown in Figure 9-14. B3 B4 B5 Compressed MSI STBC Indication Bits: 2 1 Figure 9-14â€”MSI/STBC subfield when the Unsolicited MFB subfield is 1 The format of the MFB subfield in the VHT variant HT Control field is shown in Figure 9-15. B9 B11 B12 B15 B16 B17 B18 B23 NUM_STS VHT-MCS BW SNR Bits: 3 4 2 6 Figure 9-15â€”MFB subfield in the VHT variant HT Control field 660 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The subfields of the MFB subfield in the VHT variant HT Control field are defined in Table 9-18. Table 9-18â€”MFB subfield in the VHT variant HT Control field Subfield Meaning Definition NUM_STS Recommended Indicates the recommended NUM_STS as defined in 10.31.3. NUM_STS The NUM_STS subfield contains an unsigned integer representing the number of space-time streams minus 1. VHT-MCS Recommended Indicates the recommended VHT-MCS as defined in 10.31.3. VHT-MCS The VHT-MCS subfield contains an unsigned integer in the range 0 to 9 representing a VHT-MCS Index value (defined in 21.5). BW Bandwidth of the If the Unsolicited MFB subfield is 1, the BW subfield indicates the recommended bandwidth for which the recommended VHT-MCS is intended, as VHT-MCS defined in 10.31.3: For a VHT STA: Set to 0 for 20 MHz Set to 1 for 40 MHz Set to 2 for 80 MHz Set to 3 for 160 MHz and 80+80 MHz. For a TVHT STA: Set to 0 for TVHT_W Set to 1 for TVHT_2W and TVHT_W+W Set to 2 for TVHT_4W and TVHT_2W+2W The value 3 is reserved. If the Unsolicited MFB subfield is 0, the BW subfield is reserved. SNR Average SNR Indicates the average SNR, which is an SNR averaged over data subcarriers and space-time streams. The SNR is averaged over all of the space-time streams and data subcarriers and is encoded as a 6-bit 2s complement number of SNR_average â€“ 22, where SNR_average is the sum of the values of SNR per frequency tone (in decibels) per space-time stream divided by the product of the number of space-time streams, as indicated in the NUM_STS subfield, and the number of frequency tones represented in the bandwidth in which the MFB was estimated. This encoding covers the SNR range from â€“10 dB to 53 dB in 1 dB steps. 9.2.4.7 Frame Body field 9.2.4.7.1 General The Frame Body is a variable-length field that contains information specific to individual frame types and subtypes. The minimum length of the frame body is 0 octets. The maximum length of the frame body is constrained or affected by the following: â€” The maximum MMPDU, MSDU, A-MSDU, and MPDU sizes supported by the recipient(s) for the PPDU format in use, as specified in Table 9-19 â€” The maximum PPDU duration (e.g., HT_MF L-SIG L_LENGTH, HT_GF, VHT, TVHT, or DMG aPPDUMaxTime (see Table 9-19); any nonzero TXOP limit; any regulatory constraints (e.g., CS4- msBehavior)) â€” The fields present in the MAC header (e.g., QoS Control, Address 4, HT Control) â€” The presence of security encapsulation (e.g., TKIP, CCMP or GCMP Header and MIC) â€” The presence of Mesh Control fields (see 9.2.4.7.3) 661 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NOTE 1â€”In an A-MSDU, the Mesh Control field is located in the A-MSDU Subframe Header (see Figure 9-56). In an MMPDU, the Mesh Control field is located within the MMPDU (see 9.6.18). Such Mesh Control fields need to be taken into account if a maximum A-MSDU or MMPDU size constraint applies as well as if a maximum MPDU size constraint applies. NOTE 2â€”TKIP is not allowed with A-MSDUs (see 12.2.6) or MMPDUs (see 12.5.4.1) and, therefore, need not be taken into account if a maximum A-MSDU or MMPDU size constraint applies. Table 9-19â€”Maximum data unit sizes (in octets) and durations (in microseconds) Non-HT non-VHT non-DMG PPDU HT PPDU VHT PPDU DMG PPDU and non-HT duplicate PPDU MMPDU size 2304 2304 See NOTE 1 2304 MSDU size 2304 2304 2304 7920 A-MSDU size 3839 or 3839 or 7935 See NOTE 3 7935 (see also 4065 Table 9-162) (see NOTE 2) (HT STA, see also Table 9-162), or N/A (non-HT STA, see also 10.12) MPDU size See NOTE 4 See NOTE 5 3895 or 7991 or See NOTE 5 11 454 (see also Table 9-249) PSDU size 212â€“1 216â€“1 4 692 480 (~222.16) 218â€“1 (see NOTE 7) (see Table 15-5, (see Table 19-25) (see Table 21-29) (see Table 20-32) Table 16-4, Table 17-21, Table 18-5) PPDU duration See NOTE 6 5484 (HT_MF; see 5484 2000 (see NOTE 7) 10.26.4) or 10 000 (see Table 21-29) (see Table 20-32) (HT_GF; see Table 19-25) NOTE 1â€”No direct constraint on the maximum MMPDU size; indirectly constrained by the maximum MPDU size (see 9.3.3.2). NOTE 2â€”Indirect constraint from the maximum PSDU size: 212â€“1 octets minus the minimum QoS Data frame overhead (26 octets for the MAC header and 4 octets for the FCS). NOTE 3â€”No direct constraint on the maximum A-MSDU size; indirectly constrained by the maximum MPDU size. NOTE 4â€”No direct constraint on the maximum MPDU size; indirectly constrained by the maximum MSDU/ MMPDU or (for HT STAs only) A-MSDU size. NOTE 5â€”No direct constraint on the maximum MPDU size; indirectly constrained by the maximum A-MSDU size. NOTE 6â€”No direct constraint on the maximum duration, but an L_LENGTH value above 2332 might not be supported by some receivers (see last NOTE in 10.26.4). NOTE 7â€”The values for maximum PSDU size and maximum PPDU duration are informative only. References to the normative requirements are provided. 662 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.2.4.7.2 Overhead for encryption The overhead for encryption is described in Clause 12. When the Mesh Control field is present in the frame body, the Mesh Control field is encrypted as a part of data. 9.2.4.7.3 Mesh Control field The Mesh Control field is present in a mesh Data frame containing an unfragmented MSDU or the first fragment of a fragmented MSDU and is present in a Multihop Action frame transmitted by a mesh STA. In mesh Data frames, when the Mesh Control Present subfield in the QoS Control field is 1, the Mesh Control field is prepended to the MSDU and located as follows: â€” When the frame body contains an MSDU (or a fragment thereof) and the frame is not encrypted, the Mesh Control field is located in the first octets of the frame body. â€” When the frame body contains an MSDU (or a fragment thereof) and the frame is encrypted, the Mesh Control field is located in the first octets of the encrypted data portion. â€” When the frame body contains an A-MSDU, the Mesh Control field is located in the A-MSDU subframe header as shown in Figure 9-56. In the Multihop Action frame, the Mesh Control field is present as specified in 9.6.18. The Mesh Control field is of variable length (6, 12, or 18 octets). The structure of the Mesh Control field is defined in Figure 9-16. Mesh Sequence Mesh Mesh Flags Mesh TTL Number Address Extension Octets: 1 1 4 0, 6, or 12 Figure 9-16â€”Mesh Control field The Mesh Flags subfield is 1 octet in length and contains the Address Extension Mode subfield. The structure of the Mesh Flags subfield is shown in Figure 9-17. B0 B1 B2 B7 Address Extension Mode Reserved Bits Bits: 2 6 Figure 9-17â€”Mesh Flags subfield The Address Extension Mode subfield indicates the contents of the Mesh Address Extension subfield. Table 9-20 defines valid values for the Address Extension Mode and describes the corresponding contents of the Mesh Address Extension subfield. The Mesh TTL subfield is 1 octet in length and contains an unsigned integer corresponding to the remaining number of hops the MSDU/MMPDU is forwarded. How the Mesh TTL is used in both individually and group addressed frames is described in 10.35.3 and 10.35.4. 663 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-20â€”Valid values for the Address Extension Mode subfield Address Mesh Address Address extension Address extension mode Extension Applicable extension mode mode description subfield length frame types name value (octets) 0 None No Mesh Address Extension 0 Data, Management subfield (Multihop Action, group addressed) 1 Address4 Mesh Address Extension 6 Management subfield contains Address 4 (Multihop Action, individually addressed), Data (proxied, group addressed) 2 Address5&6 Mesh Address Extension 12 Data (proxied, subfield contains Address 5 individually addressed) and Address 6 3 Reserved â€” â€” The Mesh Sequence Number subfield is 4 octets in length and contains an unsigned integer sequence number counter value. Source mesh STAs assign mesh sequence numbers from a single modulo 232 counter, starting at 0 and incrementing by 1 for each MSDU or MMPDU that is transmitted with a Mesh Control field. Usage of the Mesh Sequence Number is described in 10.35.6. NOTEâ€”It is believed that a 32-bit sequence number is sufficient as the rollover would occur after a period of 5 days assuming a source continuously transmitting at a rate of 104 frames per second. The Mesh Address Extension subfield, shown in Figure 9-18, is 6 or 12 octets in length and is present only when the Address Extension Mode subfield of the Mesh Flags subfield is a nonzero nonreserved value. The Mesh Address Extension subfield provides additional address fields for mesh address extension as defined in Table 9-20. The interpretation of the extended Address fields is described in 9.3.5. Address 4 Address 5 Address 6 Octets: 0 or 6 0 or 6 0 or 6 Figure 9-18â€”Mesh Address Extension subfield The Address 4 subfield is present when the Address Extension Mode subfield in the Mesh Flags subfield is 1. It carries a fourth address that is not included as a part of the MAC header for these frames. The Address 5 subfield and Address 6 subfield are present when the Address Extension Mode subfield in the Mesh Flags subfield is 2. It carries the addresses of source and destination end station of the end-to-end IEEE 802 communication in cases which either (or both) of the end stations are not mesh STAs at the beginning or end of a single mesh path. (See Figure 9-64.) NOTEâ€”This is useful, for example, when the end stations of IEEE 802 communication are nonmesh, external STAs that communicate over a mesh BSS via proxy mesh gates. Details on the usage of these optional address fields are given in 14.10.8.4. 664 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.2.4.8 FCS field The FCS field is a 32-bit field containing a 32-bit CRC. The FCS is calculated over all of the fields of the MAC header and the Frame Body field. These are referred to as the calculation fields. The FCS is calculated using the following standard generator polynomial of degree 32: G(x) = x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1 The FCS is the 1s complement of the sum (modulo 2) of the following: a) The remainder of xk (x31 + x30 + x29 + â€¦+ x2 + x + 1) divided (modulo 2) by G(x), where k is the number of bits in the calculation fields, and b) The remainder after multiplication of the contents (treated as a polynomial) of the calculation fields by x32 and then division by G(x). The FCS field is transmitted commencing with the coefficient of the highest-order term. As a typical implementation, at the transmitter, the initial remainder of the division is preset to all 1s and is then modified by division of the calculation fields by the generator polynomial G(x). The 1s complement of this remainder is transmitted, with the highest-order bit first, as the FCS field. At the receiver, the initial remainder is preset to all 1s and the serial incoming bits of the calculation fields and FCS, when divided by G(x), results (in the absence of transmission errors) in a unique nonzero remainder value. The unique remainder value is the polynomial: x31 + x30 + x26 + x25 + x24 + x18 + x15 + x14 + x12 + x11 + x10 + x8 + x6 + x5 + x4 + x3 + x + 1 9.2.5 Duration/ID field (QoS STA) 9.2.5.1 General The value in the Duration/ID field within Poll, SPR, Grant, Grant Ack, DMG CTS, DMG DTS, SSW, SSW- Feedback, and SSW-Ack frames transmitted by a DMG STA are described in 9.3.1.11 to 9.3.1.19. The value in the Duration/ID field within DMG Beacon frames transmitted by a DMG STA is described in 9.3.4.2. The value in the Duration/ID field in a frame transmitted by a QoS STA is defined in 9.2.5.2 to 9.2.5.8. All times are calculated in microseconds. If a calculated duration includes a fractional microsecond, that value inserted in the Duration/ID field is rounded up to the next higher integer. If a calculated duration results in a negative value, the value of the Duration/ID field is 0. 9.2.5.2 Setting for single and multiple protection under enhanced distributed channel access (EDCA) In transmissions under EDCA by a STA that initiates a TXOP, there are two classes of duration settings: single protection and multiple protection. In single protection, the value of the Duration/ID field of the frame can set a network allocation vector (NAV) value at receiving STAs that protects up to the end of any following Data, Management, or response frame plus any additional overhead frames as described below. In multiple protection, the value of the Duration/ID field of the frame can set a NAV that protects up to the estimated end of a sequence of multiple frames. 665 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The STA selects between single and multiple protection when it transmits the first frame of a TXOP. All subsequent frames transmitted by the STA in the same TXOP use the same class of duration settings. A STA always uses multiple protection in a TXOP that includes: â€” Frames that have the RDG/More PPDU subfield equal to 1 â€” PSMP frames â€” VHT NDP Announcement frames or Beamforming Report Poll frames The Duration/ID field is determined as follows: a) Single protection settings. 1) In an RTS frame that is not part of a dual clear-to-send (CTS) exchange, the Duration/ID field is set to the estimated time, in microseconds, required to transmit the pending frame, plus one CTS frame, plus one Ack or BlockAck frame if required, plus any NDPs required, plus explicit feedback if required, plus applicable IFSs. 2) In all CTS frames sent by STAs as the first frame in the exchange under EDCA and with the receiver address (RA) matching the MAC address of the transmitting STA, the Duration/ID field is set to one of the following: i) If there is a response frame, the estimated time required to transmit the pending frame, plus one SIFS, plus the response frame (Ack or BlockAck), plus any NDPs required, plus explicit feedback if required, plus an additional SIFS ii) If there is no response frame, the time required to transmit the pending frame, plus one SIFS 3) In a BlockAckReq frame, the Duration/ID field is set to the estimated time required to transmit one Ack or BlockAck frame, as applicable, plus one SIFS. 4) In a BlockAck frame that is not sent in response to a BlockAckReq frame or an implicit block ack request, the Duration/ID field is set to the estimated time required to transmit an Ack frame plus a SIFS. 5) In Management frames, non-QoS Data frames (i.e., with bit 7 of the Frame Control field equal to 0), and individually addressed Data frames with the Ack Policy subfield equal to Normal Ack only, the Duration/ID field is set to one of the following: i) If the frame is the final fragment of the TXOP, the estimated time required for the transmission of one Ack frame (including appropriate IFSs) ii) Otherwise, the estimated time required for the transmission of one Ack frame, plus the time required for the transmission of the following frame and its response if required, plus applicable IFSs. 6) In individually addressed QoS Data frames with the Ack Policy subfield equal to No Ack or Block Ack, for Action No Ack frames, and for group addressed frames, the Duration/ID field is set to one of the following: i) If the frame is the final fragment of the TXOP, 0 ii) Otherwise, the estimated time required for the transmission of the following frame and its response frame, if required (including appropriate IFSs) b) Multiple protection settings. The Duration/ID field is set to a value D as follows: 1) If TTXOP = 0 and TEND_NAV = 0, then D = TSINGLE-MSDU â€“ TPPDU 2) Else if TTXOP = 0 and TEND_NAV > 0, then D = max(0, TEND-NAV â€“TPPDU) 3) Else if TEND-NAV = 0, then min T PENDING T TXOP â€“ T PPDU D T TXOP â€“ T PPDU 4) Else T END â€“ NAV â€“ T PPDU D T TXOP â€“ REMAINING â€“ T PPDU 666 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications where TSINGLE-MSDU is the estimated time required for the transmission of the allowed frame exchange sequence defined in 10.22.2.8 (for a TXOP limit of 0), including applicable IFSs TPENDING is the estimated time required for the transmission of â€” Pending MPDUs of the same AC â€” Any associated immediate response frames â€” Any HT NDP, VHT NDP, or Beamforming Report Poll frame transmissions and explicit feedback response frames â€” Applicable IFSs â€” Any RDG TTXOP is the duration given by dot11EDCATableTXOPLimit (dot11QAP- EDCATableTXOPLimit for the AP) for that AC TTXOP-REMAINING is TTXOP less the time already used time within the TXOP TEND-NAV is the remaining duration of any NAV set by the TXOP holder, or 0 if no NAV has been established TPPDU is the time required for transmission of the current PPDU The estimated time required for transmission of a VHT Compressed Beamforming frame response is determined by assuming the following: â€” All feedback segments (as defined in 10.34.5.3) are transmitted, even if a Beamforming Report Poll frame is used and not all of the bits in the included Feedback Segment Retransmission Bitmap field are equal to 1. â€” The subfield values of the VHT MIMO Control field are as follows: â€” The Feedback Type, Nr Index, and Channel Width fields are as specified in 10.34.5. â€” The Nc Index field is as specified in 10.34.5 if the Feedback Type field is MU, or to the greatest value allowed by 10.34.5 if the Feedback Type field is SU. â€” The Grouping field indicates no grouping. â€” The Codebook Information field has the value 1. NOTE 1â€”Estimated times might prove to be inexact, if the TXOP responder has a choice of PHY options (e.g., BCC v. LDPC, use of STBC, use of short GI, PHY header/preamble format options) or MAC options (e.g., use of HT Control). Heuristics such as the TXOP responderâ€™s previous choices and channel conditions might be used to minimize the inexactitude. NOTE 2â€”If a TXOP includes the transmission of a VHT Compressed Beamforming frame by the TXOP responder, the TXOP holder can, if the duration estimates prove excessive, indicate truncation of the TXOP by using a CF-End frame, provided that the remaining duration of the TXOP after the transmission of the last frame can accommodate the CF-End frame (see 10.22.2.9). 9.2.5.3 Setting for QoS CF-Poll frames Within a Data frame containing QoS CF-Poll, the Duration/ID field value is set to one of the following: a) One SIFS plus the TXOP limit, if the TXOP limit is nonzero, or b) The time required for the transmission of one MPDU of nominal MSDU size and the associated Ack frame plus two SIFSs, if the TXOP limit is 0. 667 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.2.5.4 Setting for frames sent by a TXOP holder under HCCA Within a frame sent by a TXOP holder under hybrid coordination function (HCF) controlled channel access (HCCA), to provide NAV protection for the entire controlled access phase (CAP), the Duration/ID field is set to one of the following values: a) In an RTS frame 1) If the pending frame is the final frame, the time required to transmit the pending frame, plus one CTS frame, plus one Ack frame if required, plus three SIFSs 2) If the pending frame is not the final frame in the TXOP, the remaining duration of the TXOP b) In a CTS frame 1) If the pending frame is the sole frame in the TXOP, one of the following: i) If there is a response frame, the time required to transmit the pending frame, plus one SIFS, plus the response frame (Ack or BlockAck), plus an additional SIFS ii) If there is no response frame, the time required to transmit the pending frame, plus one SIFS 2) If the pending frame is not the final frame in the TXOP, the remaining duration of the TXOP c) Otherwise 1) If the frame is a nonfinal frame in a TXOP with multiple frame exchanges, the remaining duration of the TXOP 2) If the frame is the sole or final frame in the TXOP, the actual remaining time needed for this frame exchange sequence 9.2.5.5 Settings within a PSMP sequence Within a PSMP frame the Duration/ID field is set to a value that is no less than the time required to complete all PSMP-DTT and PSMP-UTT periods described in the frame. Within the PSMP-DTT and PSMP-UTT of a PSMP sequence, the Duration/ID field is set to the Duration/ID value of the preceding PSMP frame minus the time between the end of the PSMP frame and the end of the PPDU carrying the frame. NOTEâ€”In other words, all frames transmitted within a PSMP sequence locate the same NAV endpoint. 9.2.5.6 Settings within a dual CTS sequence Within a frame (â€œFrame1â€) (excluding a second CTS (CTS2) transmission, as defined in 10.3.2.8) sent by a QoS STA that is not a TXOP holder in a PPDU that contains an immediate response or that is sent by an RD responder, the Duration/ID field is set to the Duration/ID value from the frame(s) (â€œFrames2â€) that elicited the response or that carried the RDG minus the time interval between the end of the PPDU that carried Frame1 and the end of the PPDU that carries Frames2. Within a frame (â€œFrame1â€) (excluding a CTS2 transmission, as defined in 10.3.2.8) sent by a QoS STA that is a TXOP holder, the Duration/ID field is set according to the rules in the following subclauses: â€” 9.2.5.2 rule b) for multiple protection if Frame1 is not a QoS +CF-Poll frame and the TXOP holder is not operating under HCCA or PSMP â€” 9.2.5.3 if Frame1 is a QoS +CF-Poll frame and the TXOP holder is not operating under HCCA or PSMP â€” 9.2.5.4 if the TXOP holder is operating under HCCA â€” 9.2.5.5. if the TXOP holder is operating under PSMP 668 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Within the CTS2 of a dual CTS exchange, defined in 10.3.2.8, the Duration/ID field is set to the value of the Duration/ID field of the RTS frame that initiated the exchange minus the time required to transmit the first clear-to-sent (CTS1), CTS2, and the applicable IFSs. 9.2.5.7 Setting for control response frames This subclause describes how to set the Duration/ID field for CTS, Ack, and BlockAck frames transmitted by a QoS STA. In a CTS frame that is not part of a dual CTS sequence transmitted in response to an RTS frame, the Duration/ID field is set to the value obtained from the Duration/ID field of the RTS frame that elicited the response minus the time, in microseconds, between the end of the PPDU carrying the RTS frame and the end of the PPDU carrying the CTS frame. In an Ack frame, the Duration/ID field is set to the value obtained from the Duration/ID field of the frame that elicited the response minus the time, in microseconds between the end of the PPDU carrying the frame that elicited the response and the end of the PPDU carrying the Ack frame. In a BlockAck frame transmitted in response to a BlockAckReq frame or transmitted in response to a frame containing an implicit block ack request, the Duration/ID field is set to the value obtained from the Duration/ ID field of the frame that elicited the response minus the time, in microseconds between the end of the PPDU carrying the frame that elicited the response and the end of the PPDU carrying the BlockAck frame. 9.2.5.8 Setting for other response frames In any frame transmitted by a STA that is not the TXOP holder and is not specified by 9.2.5.1 to 9.2.5.7, the Duration/ID field is set to the value obtained from the Duration/ID field of the frame that elicited the response minus the time, in microseconds, between the end of the PPDU carrying the frame that elicited the response and the end of the PPDU carrying the frame. 9.3 Format of individual frame types 9.3.1 Control frames 9.3.1.1 Format of Control frames In the following descriptions, â€œimmediately previousâ€ frame means a frame whose reception concluded within the SIFS preceding the start of the current frame. The subfields within the Frame Control field of Control frames are set as illustrated in Figure 9-19. B0 B1 B2 B3 B4 B7 B8 B9 B10 B11 B12 B13 B14 B15 Power To From More Protected +HTC Protocol Type Retry Man- More Subtype DS DS Frag Frame /Order Version (Control) (0) age- Data (0) (0) (0) (0) (0) ment Bits: 2 2 4 1 1 1 1 1 1 1 1 Figure 9-19â€”Frame Control field subfield values within Control frames 669 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.3.1.2 RTS frame format The frame format for the RTS frame is as defined in Figure 9-20. Figure 9-20â€”RTS frame The RA field value of the RTS frame is the address of the STA, on the WM, that is the intended immediate recipient of the pending individually addressed Data, Management, or Control frame. The TA field value is the address of the STA transmitting the RTS frame or the bandwidth signaling TA of the STA transmitting the RTS frame. In an RTS frame transmitted by a VHT STA in a non-HT or non-HT duplicate format and where the scrambling sequence carries the TXVECTOR parameters CH_BANDWIDTH_IN_NON_HT and DYN_BANDWIDTH_IN_NON_HT (see 10.3.2.6), the TA field is a bandwidth signaling TA. For all RTS frames sent by non-QoS STAs, the duration value is the time, in microseconds, required to transmit the pending Data or Management frame, plus one CTS frame, plus one Ack frame, plus three SIFSs. If the calculated duration includes a fractional microsecond, that value is rounded up to the next higher integer. For RTS frames sent by QoS STAs, see 9.2.5. 9.3.1.3 CTS frame format The frame format for the CTS frame is as defined in Figure 9-21. Figure 9-21â€”CTS frame When the CTS frame is a response to an RTS frame, the value of the RA field of the CTS frame is set to the address from the TA field of the RTS frame with the Individual/Group bit forced to the value 0. When the CTS frame is the first frame in a frame exchange, the RA field is set to the MAC address of the transmitter. For all CTS frames transmitted by a non-QoS STA in response to RTS frames, the duration value is the value obtained from the Duration field of the immediately previous RTS frame, minus the time, in microseconds, required to transmit the CTS frame and its SIFS. If the calculated duration includes a fractional microsecond, that value is rounded up to the next higher integer. At a non-QoS STA, if the CTS frame is the first frame in the exchange and the pending Data or Management frame requires acknowledgment, the duration value is the time, in microseconds, required to transmit the pending Data or Management frame, plus two SIFSs plus one Ack frame. At a non-QoS STA, if the CTS frame is the first frame in the exchange and the pending Data or Management frame does not require acknowledgment, the duration value is the time, in microseconds, required to transmit the pending Data or Management frame, plus one SIFS. If the calculated duration includes a fractional microsecond, that value is rounded up to the next higher integer. 670 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications For other CTS frame transmissions by a QoS STA, the duration value is set as defined in 9.2.5. A CTS-to-self frame is a CTS frame in which the RA field is equal to the transmitterâ€™s MAC address. A CTS-to-AP frame is a CTS frame that is not transmitted in response to an RTS frame and in which the RA field is equal to the MAC address of the AP with which the STA is associated. 9.3.1.4 Ack frame format The frame format for the Ack frame is as defined in Figure 9-22. Figure 9-22â€”Ack frame The value of the RA field of the Ack frame is the nonbandwidth signaling TA from the Address 2 field of the immediately previous individually addressed Data, Management, BlockAckReq, BlockAck, or PS-Poll frames. For Ack frames sent by non-QoS STAs, if the More Fragments bit was equal to 0 in the Frame Control field of the immediately previous individually addressed Data or Management frame, the duration value is set to 0. In other Ack frames sent by non-QoS STAs, the duration value is the value obtained from the Duration/ID field of the immediately previous Data, Management, BlockAckReq, or BlockAck frame minus the time, in microseconds, required to transmit the Ack frame and its SIFS. If the calculated duration includes a fractional microsecond, that value is rounded up to the next higher integer. In all other Ack frames, the duration value is specified by 9.2.5. 9.3.1.5 PS-Poll frame format The frame format for the PS-Poll frame is as defined in Figure 9-23. Octets: 2 2 6 6 4 Frame Control ID BSSID(RA) TA FCS MAC header Figure 9-23â€”PS-Poll frame The BSSID is the address of the STA contained in the AP. The TA field value is the address of the STA transmitting the frame or a bandwidth signaling TA. In a PS-Poll frame transmitted by a VHT STA in a non- HT or non-HT duplicate format and where the scrambling sequence carries the TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT, the TA field value is a bandwidth signaling TA. The ID field contains the AID value assigned to the STA transmitting the frame by the AP in the (Re)Association Response frame that established that STAâ€™s current association, with the two MSBs set to 1. 671 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.3.1.6 CF-End frame format The frame format for the CF-End frame is as defined in Figure 9-24. Figure 9-24â€”CF-End frame When transmitted by a non-DMG STA, the Duration field is set to 0. When transmitted by a DMG STA, the Duration field is set to the time required to complete the CF-End truncation sequence of which it is part (see 10.36.8): Duration = (i â€“ 1) Ã— (TXTIME(CF-End) + SIFS), where i is in the range 1 to 3 and indicates the order of the CF-End frame in the truncation sequence in the reverse direction (i.e., i=1 corresponds to the last CF-End frame in the sequence). When transmitted by a non-DMG STA, the RA field is the broadcast group address. When transmitted by a DMG STA, the RA field is the MAC address of the STA that is the intended immediate recipient of the individually addressed Data or Management frame, or the broadcast group address. When transmitted by a non-DMG STA, the BSSID (TA) field is the address of the STA contained in the AP except that the Individual/Group bit of the BSSID (TA) field is set to 1 in a CF-End frame transmitted by a VHT STA to a VHT AP in a non-HT or non-HT duplicate format to indicate that the scrambling sequence carries the TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT. When transmitted by a DMG STA, the TA field is the MAC address of the STA transmitting the frame. 9.3.1.7 CF-End +CF-Ack frame format The frame format for the CF-End +CF-Ack frame is as defined in Figure 9-25. Figure 9-25â€”CF-End +CF-Ack frame The BSSID field is the address of the STA contained in the AP. The RA field is the broadcast group address. The Duration field is set to 0. 9.3.1.8 BlockAckReq frame format 9.3.1.8.1 Overview The frame format of the BlockAckReq frame is defined in Figure 9-26. 672 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Octets: 2 2 6 6 2 variable 4 Frame BAR Control Duration RA TA BAR Control Information FCS MAC header Figure 9-26â€”BlockAckReq frame The Duration field value is set as defined in 9.2.5. The RA field of the BlockAckReq frame is the address of the recipient STA. The TA field value is the address of the STA transmitting the BlockAckReq frame or a bandwidth signaling TA. In a BlockAckReq frame transmitted by a VHT STA in a non-HT or non-HT duplicate format and where the scrambling sequence carries the TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT, the TA field value is a bandwidth signaling TA. The BAR (for block acknowledgment request) Control field is shown in Figure 9-27. B0 B1 B2 B3 B4 B11 B12 B15 BAR Ack Compressed Multi-TID GCR Reserved TID_INFO Policy Bitmap Bits: 1 1 1 1 8 4 Figure 9-27â€”BAR Control field For BlockAckReq frames sent under Delayed and HT-delayed agreements, the BAR Ack Policy subfield of the BAR Control field has the meaning shown in Table 9-21. For BlockAckReq frames sent under other types of agreement, the BAR Ack Policy subfield is reserved. Table 9-21â€”BAR Ack Policy subfield Value Meaning 0 Normal Acknowledgment. The BAR Ack Policy subfield is set to this value when the sender requires immediate acknowledgment. The addressee returns an Ack frame. See 10.29.2.7. The value 0 is not used in frames transmitted by a DMG STA. 1 No Acknowledgment. The addressee sends no immediate response upon receipt of the frame. The BAR Ack Policy subfield is set to this value when the sender does not require immediate acknowledgment. The value 1 is not used in a Basic BlockAckReq frame outside a PSMP sequence. The value 1 is not used in an Multi-TID BlockAckReq frame. The values of the Multi-TID, Compressed Bitmap, and GCR subfields determine which of four possible BlockAckReq frame variants is represented, as indicated in Table 9-22. 673 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-22â€”BlockAckReq frame variant encoding Multi-TID Compressed Bitmap GCR BlockAckReq frame variant subfield value subfield value subfield value 0 0 0 Basic BlockAckReq 0 1 0 Compressed BlockAckReq 1 0 0 Extended Compressed BlockAckReq 1 1 0 Multi-TID BlockAckReq 0 0 1 Reserved 0 1 1 GCR BlockAckReq 1 0 1 Reserved 1 1 1 Reserved DMG STAs use only the Compressed BlockAckReq variant and the Extended Compressed BlockAckReq variant. The meaning of the TID_INFO subfield of the BAR Control field depends on the BlockAckReq frame variant type. The meaning of this subfield is explained within the subclause for each of the BlockAckReq frame variants. The meaning of the BAR Information field of the BlockAckReq frame depends on the BlockAckReq frame variant type. The meaning of this field is explained within the subclause for each of the BlockAckReq frame variants. NOTEâ€”Reference to â€œa BlockAckReqâ€ frame without any other qualification from other subclauses applies to any of the variants, unless specific exclusions are called out. 9.3.1.8.2 Basic BlockAckReq variant The use of the basic BlockAckReq variant is obsolete. Consequently, this subclause might be removed in a later revision of the standard. The TID_INFO subfield of the BAR Control field of the Basic BlockAckReq frame contains the TID for which a Basic BlockAck frame is requested. The BAR Information field of the Basic BlockAckReq frame contains the Block Ack Starting Sequence Control subfield, as shown in Figure 9-28. The Starting Sequence Number subfield of the Block Ack Starting Sequence Control subfield contains the sequence number of the first MSDU for which this Basic BlockAckReq frame is sent. The Fragment Number subfield is set to 0. B0 B3 B4 B15 Fragment Number Starting Sequence (0) Number Bits: 4 12 Figure 9-28â€”Block Ack Starting Sequence Control subfield 674 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.3.1.8.3 Compressed BlockAckReq variant The TID_INFO subfield of the BAR Control field of the Compressed BlockAckReq frame contains the TID for which a BlockAck frame is requested. The BAR Information field of the Compressed BlockAckReq frame contains the Block Ack Starting Sequence Control subfield, as shown in Figure 9-28. The Starting Sequence Number subfield of the Block Ack Starting Sequence Control subfield contains the sequence number of the first MSDU or A-MSDU for which this BlockAckReq frame is sent. The Fragment Number subfield of the Block Ack Starting Sequence Control subfield is set to 0. 9.3.1.8.4 Extended Compressed BlockAckReq variant The TID_INFO subfield of the BAR Control field of the Extended Compressed BlockAckReq frame contains the TID for which a BlockAck frame is requested. The BAR Information field of the Extended Compressed BlockAckReq frame contains the Block Ack Starting Sequence Control subfield, as shown in Figure 9-28 8-21. The Starting Sequence Number subfield of the Block Ack Starting Sequence Control subfield contains the sequence number of the first MSDU or A-MSDU for which this BlockAckReq frame is sent. The Fragment Number subfield of the Block Ack Starting Sequence Control subfield is set to 0. 9.3.1.8.5 Multi-TID BlockAckReq variant The TID_INFO subfield of the BAR Control field of the Multi-TID BlockAckReq frame determines the number of TIDs present in the Multi-TID BlockAckReq frame as given by TID_INFO + 1, e.g., a value of 2 in the TID_INFO subfield means that three TID values are present in the Multi-TID BlockAckReq frameâ€™s BAR Information field. The BAR Information field of the Multi-TID BlockAckReq frame comprises multiple sets of Per TID Info subfields and Block Ack Starting Sequence Control subfields, as shown in Figure 9-29. The Per TID Info subfield is shown in Figure 9-30. The Block Ack Starting Sequence Control subfield is shown in Figure 9-28. The Starting Sequence Number subfield of the Block Ack Starting Sequence Control subfield contains the sequence number of the first MSDU or A-MSDU for which this BlockAckReq frame is sent. The Fragment Number subfield of the Block Ack Starting Sequence Control subfield is set to 0. Octets: 2 2 Per TID Info Block Ack Starting Sequence Control Repeat for each TID Figure 9-29â€”BAR Information field (Multi-TID BlockAckReq) B0 B11 B12 B15 Reserved TID Value Bits: 12 4 Figure 9-30â€”Per TID Info subfield 675 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.3.1.8.6 GCR BlockAckReq variant The TID_INFO subfield of the BAR Control field of the GCR BlockAckReq frame is set to 0. The BAR Information field of the GCR BlockAckReq frame contains the Block Ack Starting Sequence Control subfield and GCR Group Address subfield, as shown in Figure 9-31. The Block Ack Starting Sequence Control subfield is shown in Figure 9-28. The Starting Sequence Number subfield of the Block Ack Starting Sequence Control subfield contains the sequence number of the first MSDU or A-MSDU for which this BlockAckReq frame is sent. The Fragment Number subfield of the Block Ack Starting Sequence Control subfield is set to 0. B0 B15 B16 B63 Block Ack Starting Sequence Control GCR Group Address Bits: 16 48 Figure 9-31â€”BAR Information field format (GCR BlockAckReq) The GCR Group Address subfield contains the MAC address of the group for which reception status is being requested. 9.3.1.9 BlockAck frame format 9.3.1.9.1 Overview The frame format of the BlockAck frame is defined in Figure 9-32. Octets: 2 2 6 6 2 variable 4 Frame Control Duration RA TA BA BA FCS Control Information MAC header Figure 9-32â€”BlockAck frame The Duration field value is set as defined in 9.2.5. The RA field of the BlockAck frame is the address of the recipient STA that requested the Block Ack. The TA field value is the address of the STA transmitting the BlockAck frame or a bandwidth signaling TA in the context of HT-delayed Block Ack. In a BlockAck frame transmitted in the context of HT-delayed Block Ack by a VHT STA in a non-HT or non-HT duplicate format and where the scrambling sequence carries the TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT, the TA field value is a bandwidth signaling TA. The BA Control field is defined in Figure 9-33. 676 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B0 B1 B2 B3 B4 B11 B12 B15 BA Ack Multi- Compressed Policy TID Bitmap GCR Reserved TID_INFO Bits: 1 1 1 1 8 4 Figure 9-33â€”BA Control field For BlockAck frames sent under Delayed and HT-delayed agreements, the BA Ack Policy subfield of the BA Control field has the meaning shown in Table 9-23. For BlockAck frames sent under other types of agreement, the BA Ack Policy subfield is reserved. Table 9-23â€”BA Ack Policy subfield Value Meaning 0 Normal Acknowledgment. The BA Ack Policy subfield is set to this value when the sender requires immediate acknowledgment. The addressee returns an Ack frame. The value 0 is not used for data sent under HT-delayed Block Ack during a PSMP sequence. The value 0 is not used in frames transmitted by DMG STAs. 1 No Acknowledgment. The addressee sends no immediate response upon receipt of the frame. The BA Ack Policy is set to this value when the sender does not require immediate acknowledgment. The value 1 in a Compressed BlockAck frame indicates HT-delayed block ack. HT-delayed block ack is obsolete and this value might be reserved in a later revision of the standard. The value 1 is not used in a Basic BlockAck frame outside a PSMP sequence. The value 1 is not used in an Multi-TID BlockAck frame. The values of the Multi-TID, Compressed Bitmap, and GCR subfields of the BA Control field determine which of the BlockAck frame variants is represented, as indicated in the Table 9-24. Table 9-24â€”BlockAck frame variant encoding Multi-TID Compressed Bitmap GCR BlockAck frame variant subfield value subfield value subfield value 0 0 0 Basic BlockAck 0 1 0 Compressed BlockAck 1 0 0 Extended Compressed BlockAck 1 1 0 Multi-TID BlockAck 0 0 1 Reserved 0 1 1 GCR BlockAck 1 0 1 Reserved 1 1 1 Reserved 677 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NOTEâ€”Reference to â€œa BlockAckâ€ frame without any other qualification from other subclauses applies to any of the variants, unless specific exclusions are called out. The GCR field indicates whether the BlockAck frame was sent in response to a GCR BlockAckReq frame. The GCR field is set to 1 when the BlockAck frame is sent in response to a GCR BlockAckReq frame and set to 0 otherwise. The meaning of the TID_INFO subfield of the BA Control field depends on the BlockAck frame variant type. The meaning of this subfield is explained within the subclause for each of the BlockAck frame variants. The meaning of the BA Information field depends on the BlockAck frame variant type. The meaning of this field is explained within the subclause for each of the BlockAck frame variants. 9.3.1.9.2 Basic BlockAck variant The use of the basic BlockAck variant is obsolete. This subclause might be removed in a later revision of the standard. The TID_INFO subfield of the BA Control field of the Basic BlockAck frame contains the TID for which this BlockAck frame is sent. The BA Information field of the Basic BlockAck frame comprises the Block Ack Starting Sequence Control subfield and the Block Ack Bitmap subfield, as shown in Figure 9-34. The format of the Block Ack Starting Sequence Control subfield is shown in Figure 9-28. The Starting Sequence Number subfield of the Block Ack Starting Sequence Control subfield contains the sequence number of the first MSDU for which this Basic BlockAck frame is sent and is set to the same value as in the immediately previously received Basic BlockAckReq frame. Block Ack Starting Sequence Control Block Ack Bitmap Octets: 2 128 Figure 9-34â€”BA Information field (BlockAck) The Block Ack Bitmap subfield is 128 octets in length and is used to indicate the received status of up to 64 MSDUs. Bit position n of the Block Ack Bitmap field, if equal to 1, acknowledges receipt of an MPDU with an MPDU sequence control value equal to (SSC + n), where SSC is the value of the Block Ack Starting Sequence Control subfield. Bit position n of the Block Ack Bitmap field, if equal to 0, indicates that an MPDU with MPDU sequence control value equal to (SSC + n) has not been received. Each of the MPDU Sequence Control field and Block Ack Starting Sequence Control subfield values are treated as a 16-bit unsigned integer. For unused fragment numbers of an MSDU, the corresponding bits in the bitmap are set to 0. 9.3.1.9.3 Compressed BlockAck variant The TID_INFO subfield of the BA Control field of the Compressed BlockAck frame contains the TID for which this BlockAck frame is sent. The BA Information field of the Compressed BlockAck frame comprises the Block Ack Starting Sequence Control subfield and the Block Ack Bitmap subfield, as shown in Figure 9-35. The Starting Sequence Number subfield of the Block Ack Starting Sequence Control subfield contains the sequence number of the first MSDU or A-MSDU for which this BlockAck frame is sent. The value of this subfield is defined in 10.24.7.5. The Fragment Number subfield of the Block Ack Starting Sequence Control subfield is set to 0. 678 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Block Ack Starting Sequence Control Block Ack Bitmap Octets: 2 8 Figure 9-35â€”BA Information field (Compressed BlockAck) The Block Ack Bitmap subfield of the BA Information field of the Compressed BlockAck frame is 8 octets in length and is used to indicate the received status of up to 64 entries, where each entry represents an MSDU or an A-MSDU. Each bit that is equal to 1 in the compressed Block Ack Bitmap field acknowledges the successful reception of a single MSDU or A-MSDU in the order of sequence number, with the first bit of the Block Ack Bitmap field corresponding to the MSDU or A-MSDU with the sequence number that matches the value of the Starting Sequence Number subfield of the Block Ack Starting Sequence Control subfield. 9.3.1.9.4 Multi-TID BlockAck variant The TID_INFO subfield of the BA Control field of the Multi-TID BlockAck frame contains the number of TIDs, less one, for which information is reported in the BA Information field. For example, a value of 2 in the TID_INFO subfield means that information for three TIDs is present. The BA Information field of the Multi-TID BlockAck frame comprises one or more instances of the Per TID Info, Block Ack Starting Sequence Control, and the Block Ack Bitmap subfields, as shown in Figure 9-36. The Per TID Info subfield is shown in Figure 9-30, and the Block Ack Starting Sequence Control subfield is shown in Figure 9-28. Octets: 2 2 8 Per TID Info Block Ack Starting Sequence Control Block Ack Bitmap Repeat for each TID Figure 9-36â€”BA Information field (Multi-TID BlockAck) The Starting Sequence Number subfield of the Block Ack Starting Sequence Control subfield is the sequence number of the first MSDU or A-MSDU for which this BlockAck frame is sent. The value of this subfield is defined in 10.24.7.5. The Fragment Number subfield of the Block Ack Starting Sequence Control subfield is set to 0. The first instance of the Per TID Info, Block Ack Starting Sequence Control, and Block Ack Bitmap subfields that is transmitted corresponds to the lowest TID value, with subsequent instances ordered by increasing values of the Per TID Info subfield. The Block Ack Bitmap subfield of the BA Information field of the Multi-TID BlockAck frame contains an 8-octet block ack bitmap. Each bit that is equal to 1 in the Block Ack Bitmap subfield acknowledges the successful reception of a single MSDU or A-MSDU in the order of sequence number with the first bit of the Block Ack Bitmap subfield corresponding to the MSDU or A-MSDU with the sequence number that matches the value of the Starting Sequence Number subfield of the Block Ack Starting Sequence Control subfield. 9.3.1.9.5 Extended Compressed BlockAck variant The TID_INFO subfield of the BA Control field of the Compressed BlockAck frame contains the TID for which a BlockAck frame is requested. 679 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The BA Information field of the Extended Compressed BlockAck frame is shown in Figure 9-37. The Starting Sequence Number subfield of the Block Ack Starting Sequence Control subfield contains the sequence number of the first MSDU or A-MSDU for which this BlockAck frame is sent. The value of this subfield is defined in 10.24.7.5. The Fragment Number subfield of the Block Ack Starting Sequence Control subfield is set to 0. Block Ack Starting Sequence Control Block Ack Bitmap RBUFCAP Octets: 2 8 1 Figure 9-37â€”BA Information field (Extended Compressed BlockAck) The Block Ack Bitmap subfield of the BA Information field of the Extended Compressed BlockAck frame is 8 octets in length and is used to indicate the received status of up to 64 entries, where each entry represents an MSDU or an A-MSDU. Each bit that is set to 1 in the Block Ack Bitmap subfield acknowledges the successful reception of a single MSDU or A-MSDU in the order of sequence number. The first bit of the Block Ack Bitmap subfield corresponds to the MSDU or A-MSDU with the sequence number that matches the value of the Starting Sequence Number subfield of the Block Ack Starting Sequence Control subfield. The RBUFCAP field contains an unsigned integer that is the number of MPDU buffers available to store received MPDUs at the time of transmission of the Extended Compressed BlockAck frame (10.39). 9.3.1.9.6 GCR Block Ack variant The TID_INFO subfield of the BA Control field of the GCR BlockAck frame contains the TID for which this BlockAck frame is sent. The BA Information field of the GCR BlockAck frame comprises the Block Ack Starting Sequence Control, GCR Group Address, and the Block Ack Bitmap subfields, as shown in Figure 9-38. The Block Ack Starting Sequence Control subfield is shown in Figure 9-28. The Starting Sequence Number subfield of the Block Ack Starting Sequence Control subfield contains the sequence number of the first A-MSDU for which this BlockAck frame is sent. The value of this subfield is defined in 10.24.10. The Fragment Number subfield of the Block Ack Starting Sequence Control subfield is set to 0. Block Ack Starting Sequence Control GCR Group Address Block Ack Bitmap Octets: 2 6 8 Figure 9-38â€”BA Information field format (GCR BlockAck) The GCR Group Address subfield is set to the value from the Group Address subfield of the GCR BAR Information field in the BlockAckReq frame to which the BlockAck frame is sent in response. The Block Ack Bitmap subfield is 8 octets in length and is used to indicate the received status of up to 64 entries, where each entry represents an MSDU or an A-MSDU. Each bit that is equal to 1 in the Block Ack Bitmap subfield acknowledges the successful reception of a single MSDU or A-MSDU in the order of sequence number, with the first bit of the Block Ack Bitmap subfield corresponding to the MSDU or A-MSDU with the sequence number that matches the value of the Starting Sequence Number subfield of the Block Ack Starting Sequence Control subfield. 9.3.1.10 Control Wrapper frame The format of the Control Wrapper frame is shown in Figure 9-39. 680 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Frame Duration/ Address Carried Frame HT Carried Control ID 1 Control Control Frame FCS Octets: 2 2 6 2 4 variable 4 Figure 9-39â€”Control Wrapper frame The Control Wrapper frame is used to wrap any other Control frame (i.e., excluding the Control Wrapper frame) together with an HT Control field. The Frame Control field is defined in 9.3.1. The value of the subtype field is the value from Table 9-1 of 9.2.4.1.3 that corresponds to Control Wrapper frame. The value of the Duration/ID field of the Control Wrapper frame is generated by following the rules for the Duration/ID field of the Control frame that is being wrapped. The value of the Address 1 field of the Control Wrapper frame is generated by following the rules for the Address 1 field of the Control frame that is being wrapped. The Carried Frame Control field contains the value of the Frame Control field of the wrapped Control frame. The HT Control field is defined in 9.2.4.6. The Carried Frame field contains the fields that follow the Address 1 field of the Control frame that is being wrapped, excluding the FCS field. The FCS field is defined in 9.2.4.8. 9.3.1.11 Poll frame format The format of the Poll frame is shown in Figure 9-40. Frame Duration RA TA Response FCS Control Offset Octets: 2 2 6 6 2 4 Figure 9-40â€”Poll frame format The Duration field is set to include the duration, in microseconds, of the remaining Poll frame transmissions (see 10.36.7.2), plus all appropriate IFSs (10.3.2.3), plus the duration of the SPR frame transmissions. The RA field contains the MAC address of the STA being polled. The TA field contains the MAC address of the AP or PCP. The Response Offset field indicates the offset, in units of 1 Âµs, beginning SIFS after the end of the Poll frame when the SPR frame in response to this Poll frame is transmitted. 9.3.1.12 Service period request (SPR) frame format The format of the SPR frame is shown in Figure 9-41. 681 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Frame Duration RA TA Dynamic BF Control FCS Control Allocation Info Octets: 2 2 6 6 5 2 4 Figure 9-41â€”SPR frame format When an SPR frame is sent in response to a Poll frame (see 10.36.7), the Duration field in the SPR frame is set to the value of the Duration field contained in the Poll frame, minus the value of the Response Offset field contained in the Poll frame multiplied by its unit as specified in 9.3.1.11, minus SIFS, minus the time taken to transmit the SPR frame. When the SPR frame is not sent in response to a Poll frame (see 10.36.9 and 11.4.13) and transmitted within an SP or a TXOP allocation, the Duration field is set to the time left in the allocation excluding the SPR transmission time. In all other cases, the Duration field is set to 0. The RA field contains the MAC address of the AP or PCP. The TA field contains the MAC address of the STA transmitting the SP request. The Dynamic Allocation Info field is defined in 9.5.2. The BF Control field is defined in 9.5.5. 9.3.1.13 Grant frame format The format of the Grant frame is shown in Figure 9-42. Frame Control Duration RA TA Dynamic BF Control FCS Allocation Info Octets: 2 2 6 6 5 2 4 Figure 9-42â€”Grant frame format For individually addressed Grant frames: â€” If the Grant frame is used to obtain a TXOP, the Duration/ID field is set to a value subject to the TXOP limit as described in 10.22.2.8. In all other cases within a CBAP, the Duration/ID field is set to the value equal of Duration/ID field of the immediately preceding frame minus TXTIME(Grant frame) minus aSIFSTime. â€” If the Grant frame is sent within an SP, the value of the Duration/ID field is set according to the rules in 10.36.7, 10.36.8, and 10.36.9 as appropriate depending on the Grant frame usage. â€” If the Grant frame is sent within an ATI, the value the Duration/ID is set according to the rules in 10.36.3. For group addressed Grant frames, the Duration/ID field is set to a value that is equal to the time between PHY-TXEND.indication primitive of the Grant frame and the start of the allocation as indicated by the value of the Allocation Duration subfield within the Dynamic Allocation Info field. The RA field contains the MAC address of the STA receiving the SP grant. The TA field contains the MAC address of the STA that has transmitted the Grant frame. The Dynamic Allocation Info field is defined in 9.5.2. The BF Control field is defined in 9.5.5. 682 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.3.1.14 DMG CTS frame format The frame format for the DMG CTS frame is as defined in Figure 9-43. Frame Control Duration RA TA FCS Octets: 2 2 6 6 4 Figure 9-43â€”DMG CTS frame format When the DMG CTS frame is a response to an RTS frame, the value of the RA field of the DMG CTS frame is set to the address from the TA field of the RTS frame. When the DMG CTS frame is the first frame in a frame exchange, the RA field is set to the MAC address of the transmitter. A DMG CTS-to-self frame is a DMG CTS frame in which the RA field is equal to the transmitterâ€™s MAC address. For DMG CTS frames other than DMG CTS-to-self frames, the Duration field is set to the value of the Duration field of the immediately previous RTS frame, minus the time, in microseconds, required to transmit the DMG CTS frame and its SIFS interval. For DMG CTS-to-self frames, the Duration field is set to the remaining duration of the TXOP or SP. If the calculated duration includes a fractional microsecond, that value is rounded up to the next higher integer. For DMG CTS frames other than DMG CTS-to-self frames, the TA field is the MAC address of the STA transmitting the DMG CTS frame. For DMG CTS-to-self frames, the TA field is set to the individual address of the recipient or the group address of the recipients of the frame that the DMG STA intends to transmit after the DMG CTS-to-self frame. 9.3.1.15 DMG DTS frame format The frame format for the DMG Denial to Send (DTS) frame is as defined in Figure 9-44. Frame Control Duration RA NAV-SA NAV-DA FCS Octets: 2 2 6 6 6 4 Figure 9-44â€”DMG DTS frame format The Duration field is set to the value of the transmitting STAâ€™s NAV â€“ (TXTIME(DMG DTS) + SIFS) or the remaining time in the SP at the end of the DMG DTS frame transmission, whichever is smaller. The transmitting STAâ€™s NAV is the value of its NAV at the start of the DMG DTS frame transmission. The RA field of the frame is copied from the TA field of the immediately previous RTS frame to which the DMG DTS frame is a response. The NAV-SA and the NAV-DA fields contain the MAC addresses of the source DMG STA and the destination DMG STA, respectively, whose exchange of an RTS and DMG CTS frame caused the last update to the NAV at the transmitting STA. 9.3.1.16 Sector sweep (SSW) frame format The frame format for the SSW frame is as defined in Figure 9-45. 683 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Frame Duration RA TA SSW SSW FCS Control Feedback Octets: 2 2 6 6 3 3 4 Figure 9-45â€”SSW frame format The Duration field is set to the time until the end of the current SSW slot when the SSW frame is transmitted within an association beamforming training (A-BFT). Otherwise, it is set to the time until the end of the SSW frame transmission that has the CDOWN subfield within the SSW field equal to 0, plus MBIFS, or until the end of the current allocation (see 10.38), whichever comes first. The RA field contains the MAC address of the STA that is the intended receiver of the sector sweep. The TA field contains the MAC address of the transmitter STA of the sector sweep frame. The SSW field is defined in 9.5.1. The SSW Feedback field is defined in 9.5.3. 9.3.1.17 Sector sweep feedback (SSW-Feedback) frame format The format of the SSW-Feedback frame is shown in Figure 9-46. Frame Duration RA TA SSW BRP Beamformed FCS Control Feedback Request Link Maintenance Octets: 2 2 6 6 3 4 1 4 Figure 9-46â€”SSW-Feedback frame format The Duration field is set to 0 when the SSW-Feedback frame is transmitted within an association beamforming training (A-BFT). When transmitted within a DTI, the Duration field is set to one of the following: a) If a BRP phase is requested through the BRP Request field, the Duration field is set to the time, in microseconds, required to transmit an SSW-Ack frame plus 2Ã—MBIFS (10.38.3.1). b) If a BRP phase is not requested, the Duration field is set to the time, in microseconds, required to transmit an SSW-Ack frame, plus MBIFS (10.38.3.1) or the time until the end of the current allocation, whichever comes earlier. The RA field contains the MAC address of the STA that is the intended destination of the SSW-Feedback frame. The TA field contains the MAC address of the STA transmitting the SSW-Feedback frame. The SSW Feedback field is defined in 9.5.3. The BRP Request field is defined in 9.5.4. The Beamformed Link Maintenance field is defined in 9.5.6. 9.3.1.18 Sector sweep Ack (SSW-Ack) frame format The format of the SSW-Ack frame is shown in Figure 9-47. 684 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Frame Duration RA TA SSW BRP Beamformed FCS Control Feedback Request Link Maintenance Octets: 2 2 6 6 3 4 1 4 Figure 9-47â€”SSW-Ack frame format The Duration field is set to the value of the Duration field of the immediately preceding SSW-Feedback frame, minus MBIFS, minus the time required to transmit the SSW-Ack frame. The RA field contains the MAC address of the STA that is the intended destination of the SSW-Ack frame. The TA field contains the MAC address of the STA transmitting the SSW-Ack frame. The SSW Feedback field is defined in 9.5.3. The BRP Request field is defined in 9.5.4. The Beamformed Link Maintenance field is defined in 9.5.6. 9.3.1.19 Grant Ack frame format The format of the Grant Ack frame is shown in Figure 9-48. The Grant Ack frame is sent as a response to the reception of a Grant frame. Frame Control Duration RA TA Reserved BF Control FCS Octets: 2 2 6 6 5 2 4 Figure 9-48â€”Grant Ack frame format The Duration field is set to the value obtained from the Duration/ID field of the immediately previous Grant frame minus the time, in microseconds, required to transmit the Grant Ack frame and its SIFS interval. The RA field of the Grant Ack frame is copied from the Address 2 field of the immediately previous Grant frame. The TA field contains the MAC address of the STA that has transmitted the Grant Ack frame. The BF Control field is defined in 9.5.5. 9.3.1.20 VHT NDP Announcement frame format The frame format of the VHT NDP Announcement frame is shown in Figure 9-49. Sounding Frame Duration RA TA Dialog STA Info 1 â€¦ STA Info n FCS Control Token Octets: 2 2 6 6 1 2 2 4 Figure 9-49â€”VHT NDP Announcement frame format The Duration field is set as defined in 9.2.5. 685 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The VHT NDP Announcement frame contains at least one STA Info field. If the VHT NDP Announcement frame contains only one STA Info field, then the RA field is set to the address of the STA that can provide feedback (see 10.34.5.2). If the VHT NDP Announcement frame contains more than one STA Info field, then the RA field is set to the broadcast address. The TA field is set to the address of the STA transmitting the VHT NDP Announcement frame or the bandwidth signaling TA of the STA transmitting the VHT NDP Announcement frame. In a VHT NDP Announcement frame transmitted by a VHT STA in a non-HT or non-HT duplicate format and where the scrambling sequence carries the TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT, the TA field is set to a bandwidth signaling TA. The format of the Sounding Dialog Token field is shown in Figure 9-50. B0 B1 B2 B7 Reserved Sounding Dialog Token Number Bits: 2 6 Figure 9-50â€”Sounding Dialog Token field The Sounding Dialog Token Number subfield in the Sounding Dialog Token field contains a value selected by the beamformer to identify the VHT NDP Announcement frame. The format of the STA Info field is shown in Figure 9-51. B0 B11 B12 B13 B15 AID12 Feedback Type Nc Index Bits: 12 1 3 Figure 9-51â€”STA Info field The subfields in the STA Info field are described in Table 9-25. Table 9-25â€”STA Info subfields Field Description AID12 Contains the 12 least significant bits of the AID of a STA expected to process the following VHT NDP and prepare the sounding feedback. Equal to 0 if the STA is an AP, mesh STA, or STA that is a member of an IBSS. Feedback Type Indicates the type of feedback requested. Set to 0 for SU. Set to 1 for MU. Nc Index If the Feedback Type field indicates MU, then Nc Index indicates the number of columns, Nc, in the Compressed Beamforming Feedback Matrix subfield minus 1: Set to 0 to request Nc = 1 Set to 1 to request Nc = 2 â€¦ Set to 7 to request Nc = 8 Reserved if the Feedback Type field indicates SU. 686 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.3.1.21 Beamforming Report Poll frame format The Beamforming Report Poll frame is shown in Figure 9-52. Frame Duration RA TA Feedback Segment FCS Control Retransmission Bitmap Octets: 2 2 6 6 1 4 Figure 9-52â€”Beamforming Report Poll frame format The Duration field is set as defined in 9.2.5. The RA field is set to the address of the intended recipient. The TA field is set to the address of the STA transmitting the Beamforming Report Poll or a bandwidth signaling TA. In a Beamforming Report Poll frame transmitted by a VHT STA in a non-HT or non-HT duplicate format and where the scrambling sequence carries the TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT, the TA field is set to a bandwidth signaling TA. The Feedback Segment Retransmission Bitmap field indicates the requested feedback segments of a VHT Compressed Beamforming report (see 10.34.5.3). If the bit in position n (n=0 for LSB and n=7 for MSB) is 1, then the feedback segment with the Remaining Feedback Segments subfield in the VHT MIMO Control field equal to n is requested. If the bit in position n is 0, then the feedback segment with the Remaining Feedback Segments subfield in the VHT MIMO Control field equal to n is not requested. 9.3.2 Data frames 9.3.2.1 Format of Data frames The format of a Data frame is defined in Figure 9-53. The Frame Control, Duration, Address 1, Address 2, Address 3, and Sequence Control fields are present in all data frame subtypes. The presence of the Address 4 field is determined by the setting of the To DS and From DS subfields of the Frame Control field (see below). The QoS Control field is present when the QoS subfield of the Subtype subfield is set to 1. Octets: 2 2 6 6 6 2 0 or 6 0 or 2 0 or 4 variable 4 Frame Address Address Address Sequence Address QoS HT Frame Duration FCS Control 1 2 3 Control 4 Control Control Body MAC header Figure 9-53â€”Data frame NOTEâ€”The maximum frame body size shown in Figure 9-53 is for GCMP encryption of a maximum-size A-MSDU (note that TKIP encryption is not allowed in this case and any Mesh Control fields are part of the A-MSDU subframes). The corresponding maximum for CCMP encryption is 7951 octets. The maximum frame body size if A-MSDUs are not used is 2346 octets for GCMP encryption of a maximum-size MSDU, 2338 octets for CCMP encryption of a maximum- size MSDU and 2342 octets for TKIP encryption of a maximum-size MSDU, including in both cases an 18-octet Mesh Control field. The frame body size might in all cases be greater if a vendor-specific cipher suite is used. 687 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Data frames with a value of 1 in the QoS subfield of the Subtype subfield are collectively referred to as QoS Data frames. Each of these data subtypes contains QoS in their names, and this frame format is distinguished by the presence of a QoS Control field in the MAC header. A QoS STA always uses QoS Data frames for data transmissions to other QoS STAs. A QoS STA uses frames with the QoS subfield of the Subtype subfield set to 0 for data transmissions to non-QoS STAs. A non-QoS STA always uses frames with the QoS subfield of the Subtype subfield set to 0 for data transmissions to other STAs. All STAs use frames with the QoS subfield of the Subtype subfield set to 0 for nonconcealed GCR broadcast Data frames unless a transmitting STA knows that all STAs in a BSS have QoS capability, in which case the transmitting STAs use QoS Data frames. All STAs use frames with the QoS subfield of the Subtype subfield set to 0 for nonconcealed GCR group addressed Data frames unless it is known to the transmitter that all STAs in the BSS that are members of the multicast group have QoS capability, in which case STAs use QoS Data frames. APs where dot11RobustAVStreamingImplemented is true or mesh STAs where dot11MeshGCRImplemented is true use frames with the QoS subfield of the Subtype subfield set to 1 for concealed GCR frames, as described in 11.24.16.3.5. The content of the address fields of Data frames are dependent upon the values of the To DS and From DS subfields in the Frame Control field and whether the Frame Body field contains either an MSDU (or fragment thereof) or an entire A-MSDU, as determined by the A-MSDU Present subfield of the QoS Control field (see 9.2.4.5.9). The content of the address fields transmitted by nonmesh STAs is defined in Table 9-26. The content of the address fields transmitted by mesh STAs is defined in 9.3.5. Where the content of a field is shown as not applicable (N/A), the field is omitted. Note that Address 1 always holds the receiver address of the intended receiver (or, in the case of group addressed frames, receivers), and that Address 2 always holds the address of the STA that is transmitting the frame. Table 9-26â€”Address field contents Address 3 Address 4 To From MSDU and MSDU and Address 1 Address 2 Basic Basic DS DS Short Short A-MSDU A-MSDU A-MSDU A-MSDU case case case case 0 0 RA = DA TA = SA BSSID BSSID N/A N/A 0 1 RA = DA TA = BSSID SA BSSID N/A N/A 1 0 RA = BSSID TA = SA DA BSSID N/A N/A 1 1 RA TA DA BSSID SA BSSID A STA uses the contents of the Address 2 field to direct the acknowledgment if an acknowledgment is necessary. The DA field contains the destination of the MSDU (or fragment thereof) or A-MSDU in the Frame Body field. The SA field contains the address of the MAC entity that initiated the MSDU (or fragment thereof) or A-MSDU in the Frame Body field. When a Data frame carries an MSDU (or fragment thereof), the DA and SA values related to that MSDU are carried in the Address 1, Address 2, Address 3, and Address 4 fields (according to the setting of the To DS and From DS subfields) as defined in Table 9-26. 688 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications When a Data frame carries an A-MSDU, the DA and SA values related to each MSDU carried by the A-MSDU are carried within the A-MSDU. Zero, one, or both of these fields are present in the Address 1 and Address 2 fields as indicated in Table 9-26. The RA field is the individual address of the STA that is the immediate intended receiver of the frame or the group address of the STAs that are the immediate intended receivers of the frame. The TA field is the address of the STA that is transmitting the frame. The BSSID of the Data frame is determined as follows: a) If the STA is contained within an AP or is associated with an AP, the BSSID is the address currently in use by the STA contained in the AP. b) If the STA is a member of an IBSS, the BSSID is the BSSID of the IBSS. c) If the STA is transmitting a Data frame when dot11OCBActivated is true, the BSSID is the wildcard BSSID. d) If the STA is a member of an MBSS, the BSSID is the address of the transmitter and is equal to the Data frameâ€™s TA. e) If the STA participates in a PBSS, the BSSID is the address of the STA contained in the PCP of the PBSS. The Sequence Control field is defined in 9.2.4.4. The QoS Control field is defined in 9.2.4.5. The presence of the QoS Control field is determined by the Subtype subfield of the Frame Control field, as specified in 9.2.4.1.3. The HT Control field is defined in 9.2.4.6. The presence of the HT Control field is determined by the +HTC/ Order subfield of the Frame Control field, as specified in 9.2.4.1.10. The frame body consists of either: â€” The MSDU (or a fragment thereof), the Mesh Control field (present if the frame is transmitted by a mesh STA and the Mesh Control Present subfield of the QoS Control field is 1, otherwise absent), and a security header and trailer (present if the Protected Frame subfield in the Frame Control field is 1, otherwise absent) â€” The A-MSDU and a security header and trailer (present if the Protected Frame subfield in the Frame Control field is 1, otherwise absent) The presence of an A-MSDU in the frame body is indicated by setting the A-MSDU Present subfield of the QoS Control field to 1, as shown in Table 9-6. For Data frames of subtype Null (no data), CF-Ack (no data), CF-Poll (no data), and CF-Ack +CF-Poll (no data) and for the corresponding QoS data frame subtypes, the Frame Body field is null (i.e., has a length of 0 octets); these subtypes are used for MAC control purposes. For Data frames of subtypes Data, Data +CF- Ack, Data +CF-Poll, and Data +CF-Ack +CF-Poll, the Frame Body field contains all of, or a fragment of, an MSDU after any encapsulation for security. For Data frames of subtypes QoS Data, QoS Data +CF-Ack, QoS Data +CF-Poll, and QoS Data +CF-Ack +CF-Poll, the Frame Body field contains an MSDU (or fragment thereof) or A-MSDU after any encapsulation for security. For Data frames of subtype QoS Data that are transmitted by a mesh STA, the Frame Body field also contains a Mesh Control field, as described in 9.2.4.7.3. The maximum length of the Frame Body field can be determined from the maximum MSDU length plus the length of the Mesh Control field (if present) plus any overhead from encapsulation for encryption (i.e., it is always possible to send a maximum length MSDU, with any encapsulations provided by the MAC layer 689 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications within a single Data frame). When the frame body carries an A-MSDU, the size of the frame body field is limited by: â€” The PHYâ€™s maximum PHY service data unit (PSDU) length â€” If A-MPDU aggregation is used by a non-VHT and non-DMG STA, a maximum MPDU length of 4095 octets (see 9.7) Within all Data frames sent by STAs during the CFP under PCF, the Duration field is set to 32 768. Within all Data frames sent by the QoS STA, the Duration field contains a duration value as defined in 9.2.5. Within all Data frames sent during the CP by non-QoS STAs, the Duration field is set according to the following rules: â€” If the Address 1 field contains a group address, the duration value is set to 0. â€” If the More Fragments bit is 0 in the Frame Control field of a frame and the Address 1 field contains an individual address, the duration value is set to the time, in microseconds, required to transmit one Ack frame, plus one SIFS. â€” If the More Fragments bit is 1 in the Frame Control field of a frame and the Address 1 field contains an individual address, the duration value is set to the time, in microseconds, required to transmit the next fragment of this Data frame, plus two Ack frames, plus three SIFSs. The duration value calculation for the Data frame is based on the rules in 10.7 that determine the data rate at which the Control frames in the frame exchange sequence are transmitted. If the calculated duration includes a fractional microsecond, that value is rounded up to the next higher integer. All STAs process Duration field values less than or equal to 32 767 from valid Data frames (without regard for the RA, DA, and/or BSSID address values that might be present in these frames) to update their NAV settings as appropriate under the coordination function rules. NOTE 1â€”The QoS Data and QoS Null subtypes are the only Data subtypes transmitted by a DMG STA. NOTE 2â€”The HT Control field is not present in frames transmitted by a DMG STA. 9.3.2.2 Aggregate MSDU (A-MSDU) format 9.3.2.2.1 General An A-MSDU is a sequence of A-MSDU subframes as shown in Figure 9-54. Each A-MSDU subframe consists of an A-MSDU subframe header followed by an MSDU and 0 to 3 octets of padding as shown in Figure 9-55 (in 9.3.2.2.2) and Figure 9-57 (in 9.3.2.2.3). A-MSDU subframe 1 A-MSDU subframe 2 â€¦ A-MSDU subframe n Figure 9-54â€”A-MSDU structure Two A-MSDU subframe formats are defined: the Basic A-MSDU subframe described in 9.3.2.2.2 and the Short A-MSDU subframe described in 9.3.2.2.3. Unless otherwise noted, in this standard, the term A-MSDU applies to both the Basic A-MSDU and the Short A-MSDU. The Basic A-MSDU uses only the Basic A-MSDU subframe format, while the Short A-MSDU uses only the Short A-MSDU subframe format. 9.3.2.2.2 Basic A-MSDU subframe format The structure of a Basic A-MSDU subframe is shown in Figure 9-55. In the Basic A-MSDU subframe, each A-MSDU subframe (except the last) is padded so that its length is a multiple of 4 octets. The last A-MSDU subframe has no padding. 690 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Octets: 6 6 2 variable 0â€“3 DA SA Length MSDU Padding A-MSDU subframe header Figure 9-55â€”Basic A-MSDU subframe structure The A-MSDU subframe header contains three fields: DA, SA, and Length. The order of these fields and the bits within these fields are the same as the IEEE 802.3â„¢ frame format. The DA and SA fields of the A-MSDU subframe header contain the values passed in the MA-UNITDATA.request and MA- UNITDATA.indication primitives. The Length field contains the length in octets of the MSDU. An A-MSDU contains only MSDUs whose DA and SA parameter values map to the same receiver address (RA) and transmitter address (TA) values. The rules for determining RA and TA are independent of whether the frame body carries an A-MSDU. NOTEâ€”It is possible to have different DA and SA parameter values in A-MSDU subframe headers of the same A-MSDU as long as they all map to the same Address 1 and Address 2 parameter values. The MPDU containing the A-MSDU is carried in any of the following data frame subtypes: QoS Data, QoS Data +CF-Ack, QoS Data +CF-Poll, QoS Data +CF-Ack +CF-Poll. The A-MSDU structure is contained in the frame body of a single MPDU. If encrypted, the MPDU is encrypted as a single unit. NOTEâ€”The value of TID present in the QoS Control field of the MPDU carrying the A-MSDU indicates the TID for all MSDUs in the A-MSDU. Because this value of TID is common to all MSDUs in the A-MSDU, only MSDUs delivered to the MAC by an MA-UNITDATA.request primitive with an integer priority parameter that maps to the same TID can be aggregated together using A-MSDU. When mesh Data frames are aggregated, the A-MSDU subframe header includes Mesh DA, Mesh SA, Length, and Mesh Control. The A-MSDU subframe structure for Mesh Data is defined in Figure 9-56. Octets: 6 6 2 6 or 18 0â€“2304 0-3 Mesh DA Mesh SA Length Mesh Control MSDU Padding A-MSDU subframe header Figure 9-56â€”A-MSDU subframe structure for Mesh Data The Mesh DA and Mesh SA fields contain the addresses of the destination mesh STA and the source mesh STA, respectively, determined in 9.3.5. The Length field contains the length in octets of the MSDU. The format of the Mesh Control field is described in 9.2.4.7.3. NOTEâ€”It is possible to have different Mesh DA, Mesh SA, and Mesh Control in subframe headers of the same A-MSDU as long as they all map to the same Address 1 and Address 2 values. 9.3.2.2.3 Short A-MSDU subframe format The Short A-MSDU subframe is shown in Figure 9-57. In the Short A-MSDU subframe, each A-MSDU subframe (except the last) is padded so that its length excluding the A-MSDU subframe header is a multiple of 4 octets. The last A-MSDU subframe has no padding. 691 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Octets: 2 0â€“7920 0-3 Length MSDU Padding A-MSDU subframe header Figure 9-57â€”Short A-MSDU subframe structure The Short A-MSDU subframe header consists of a Length field that contains the length in octets of the MSDU. NOTEâ€”The Short A-MSDU subframe format is not transmitted by non-DMG STAs. 9.3.3 Management frames 9.3.3.1 Terminology of Management frames and MMPDUs References in this standard to a â€œ frameâ€, where corresponds to one of the Management frame subtypes, are to be understood as being to a â€œ MMPDU, where the MMPDU is carried in the frame body of one or more Management frames with the Subtype field value corresponding to , plus information from the MPDU headers (the Management frame subtype and the addresses)â€. 9.3.3.2 Format of Management frames The format of a Management frame is defined in Figure 9-58. The Frame Control, Duration, Address 1, Address 2, Address 3, and Sequence Control fields are present in all management frame subtypes. In an MMPDU carried in one or more non-VHT PPDUs, the maximum MMPDU size is specified in Table 9-19. In an MMPDU carried in one or more PPDU(s), all of which are VHT PPDU(s), the maximum MMPDU size specified in Table 9-19 is the maximum MPDU size supported by the recipient(s) less the shortest management frame MAC header and FCS. NOTEâ€”In an MMPDU carried in one or more PPDUs, all of which are VHT PPDUs, the presence of encryption overhead (i.e., the MMPDU is transmitted in robust Management frames) or an HT Control field might cause an MMPDU to be fragmented that would not otherwise need to be fragmented. Octets: 2 2 6 6 6 2 0 or 4 variable 4 Frame Duration Address 1 Address 2 Address 3 Sequence HT Frame FCS Control Control Control Body MAC header Figure 9-58â€”Management frame format A STA uses the contents of the Address 1 field to perform the address matching for receive decisions. In the case where the Address 1 field contains a group address and the frame subtype is other than Beacon or the frame subtype Action, Category Multihop Action (Multihop Action frame), the Address 3 field also is validated to verify that the group addressed frame originated from a STA in the BSS of which the receiving STA is a member or from a mesh STA to which mesh peering is maintained. Details of addressing and forwarding of the group addressed frame in an MBSS are defined in 10.35.4. When the Address 1 field contains a group address and the frame subtype is either Probe Request or Action with Category Public, a wildcard BSSID value matches all receiving STAâ€™s BSSIDs. If the frame subtype is Beacon, other address matching rules apply, as specified in 11.1.3.7. Frames of subtype Probe Request with a group address in the Address 1 field are additionally processed as described in 11.1.4.3.2 for non-DMG STAs and 11.1.4.3.3 for 692 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DMG STAs. If the frame subtype is Action, the Category is Public, and the Action is 20/40 BSS Coexistence Management, then additional address matching rules for receive decisions apply as specified in 11.16 and 11.18. The address fields for all Management frames except Multihop Action frames are as follows: a) The Address 1 field of the Management frame is the RA (=DA) and is determined as the destination of the frame. b) The Address 2 field of the Management frame is the TA (=SA) and is determined as the address of the STA transmitting the frame. c) The Address 3 field of the Management frame is set and determined as follows: 1) In Probe Request frames, the Address 3 field is the BSSID. The BSSID is either a specific BSSID as described in item 4) below or the wildcard BSSID as defined in the procedures specified in 11.1.4. 2) In Public Action frames, the Address 3 field is the BSSID. The BSSID value is set according to 11.20. 3) If dot11OCBActivated is true, the Address 3 field is the wildcard BSSID. 4) Otherwise: i) If the STA is contained within an AP or is associated with an AP, the Address 3 field is the BSSID. The BSSID is the address currently in use by the STA contained in the AP. ii) If the STA is contained within an AP or is transmitting the Management frame to an AP, the Address 3 field is the BSSID. The BSSID is the address currently in use by the STA contained in the AP. iii) If the STA is transmitting the Management frame to one or more members of an IBSS, the Address 3 field is the BSSID of the IBSS. iv) If the STA is a mesh STA, the Address 3 field is the TA. The address fields for Multihop action frames are described in 9.3.5. Within a PBSS, the BSSID field of a Management frame is set to the MAC address in use by the STA contained in the PCP of the PBSS. Within all Management frames sent by STAs during the CFP under PCF, the Duration field is set to the value 32 768. Within all Management frames sent by the QoS STA, the Duration field contains a duration value as defined in 9.2.5. Within all Management frames sent during the CP by non-QoS STAs, the Duration field is set according to the following rules: â€” If the DA field contains a group address, the duration value is set to 0. â€” If the More Fragments bit is 0 in the Frame Control field of a frame and the DA field contains an individual address, the duration value is set to the time, in microseconds, required to transmit one Ack frame, plus one SIFS. â€” If the More Fragments bit is 1 in the Frame Control field of a frame, and the DA field contains an individual address, the duration value is set to the time, in microseconds, required to transmit the next fragment of this Management frame, plus two Ack frames, plus three SIFSs. The duration value calculation for the Management frame is based on the rules in 10.7 that determine the data rate at which the Control frames in the frame exchange sequence are transmitted. If the calculated duration includes a fractional microsecond, that value is rounded up to the next higher integer. All STAs process Duration field values less than or equal to 32 767 from valid Management frames to update their NAV settings as appropriate under the coordination function rules. 693 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The HT Control field is defined in 9.2.4.6. The presence of the HT Control field is determined by the +HTC/ Order subfield of the Frame Control field, as specified in 9.2.4.1.10. A Management frame is an IQMF when both â€” The RA of the Management frame corresponds to an individual MAC address; and â€” The To DS subfield is set to 1 and the From DS subfield of the Frame Control field is set to 0. A Management frame is a GQMF when both â€” The RA of the Management frame corresponds to a group MAC address; and â€” The To DS subfield is set to 1 and the From DS subfield of the Frame Control field is set to 0. The frame body consists of the fields followed by the elements defined for each management frame subtype. All fields and elements are mandatory unless stated otherwise and appear in the specified, relative order. STAs that encounter an element ID they do not recognize in the frame body of a received Management frame ignore that element and continue to parse the remainder of the management frame body (if any) for additional elements with recognizable element IDs. See 10.27.7. Unused element ID codes are reserved. Gaps might exist in the ordering of fields and elements within frames. The order that remains is ascending. 9.3.3.3 Beacon frame format The frame body of a Beacon frame contains the information shown in Table 9-27. Table 9-27â€”Beacon frame body Order Information Notes 1 Timestamp 2 Beacon interval 3 Capability Information 4 Service Set If dot11MeshActivated is true, the SSID element is the wildcard Identifier (SSID) value as described in 9.4.2.2. 5 Supported Rates and BSS Membership Selectors 6 DSSS Parameter Set The element is optionally present. The DSSS Parameter Set element is present within Beacon frames generated by STAs using Clause 15, Clause 16, and Clause 18 PHYs. The element is present within Beacon frames generated by STAs using a Clause 19 PHY in the 2.4 GHz band. 7 CF Parameter Set The CF Parameter Set element is present only within Beacon frames generated by APs supporting a PCF. This element is not present if dot11HighThroughputOption- Implemented is true and the Dual CTS Protection field of the HT Operation element is 1. 8 IBSS Parameter Set The IBSS Parameter Set element is present only within Beacon frames generated by IBSS STAs. 9 Traffic indication The TIM element is present only within Beacon frames generated map (TIM) by APs or mesh STAs. 694 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-27â€”Beacon frame body (continued) Order Information Notes 10 Country The Country element is present if dot11MultiDomainCapabilityActivated is true or dot11SpectrumManagementRequired is true or dot11RadioMeasurementActivated is true. 11 Power Constraint The Power Constraint element is present if dot11SpectrumManagementRequired is true and is optionally present if dot11RadioMeasurementActivated is true. 12 Channel Switch Channel Switch Announcement element is optionally present if Announcement dot11SpectrumManagementRequired is true. 13 Quiet The Quiet element is optionally present if dot11SpectrumManagementRequired is true or dot11RadioMeasurementActivated is true. 14 IBSS DFS IBSS DFS element is present if dot11SpectrumManagementRequired is true in an IBSS. 15 TPC Report The TPC Report element is present if dot11SpectrumManagementRequired is true or dot11RadioMeasurementActivated is true. 16 ERP The ERP element is present within Beacon frames generated by STAs using extended rate PHYs (ERPs) defined in Clause 18 and is optionally present in other cases. 17 Extended Supported The Extended Supported Rates and BSS Membership Selectors Rates and BSS element is present if there are more than eight supported rates, and Membership it is optional otherwise. Selectors 18 RSN The RSNE is present within Beacon frames generated by STAs that have dot11RSNAActivated equal to true. 19 BSS Load The BSS Load element is present if dot11QosOption- Implemented and dot11QBSSLoadImplemented are both true. 20 EDCA Parameter The EDCA Parameter Set element is present if Set dot11QosOptionImplemented is true, and dot11MeshActivated is false, and the QoS Capability element is not present. 21 QoS Capability The QoS Capability element is present if dot11QosOption- Implemented is true, and dot11MeshActivated is false, and EDCA Parameter Set element is not present. 22 AP Channel Report If dot11RMAPChannelReportActivated is true, one AP Channel Report element is present for each operating class that has at least 1 channel to report. 23 BSS Average Access The BSS Average Access Delay element is present if Delay dot11RMBSSAverageAccessDelayActivated is true and the value of the AP Average Access Delay field is not equal to 255 (measurement not available); otherwise, the BSS Average Access Delay element is optionally present if dot11RMBSSAverageAccessDelayActivated is true. 24 Antenna The Antenna element is present if dot11RMAntennaInformationActivated is true and the value of the Antenna ID field is not equal to 0 (unknown antenna); otherwise, the Antenna element is optionally present if dot11RMAntennaInformationActivated is true. 695 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-27â€”Beacon frame body (continued) Order Information Notes 25 BSS Available The BSS Available Admission Capacity element is present if Admission Capacity dot11RMBSSAvailableAdmissionCapacityActivated is true with the following exceptions: 1) when Available Admission Capacity Bitmask equals 0 (Available Admission Capacity List contains no entries), or 2) when the BSS Load element is present and the Available Admission Capacity Bitmask states that only AC_VO is present in the Available Admission Capacity List field. 26 BSS AC Access The BSS AC Access Delay element is present if Delay dot11RMBSSAverageAccessDelayActivated is true and at least one field of the element is not equal to 255 (measurement not available); otherwise, the BSS AC Access Delay element is optionally present if dot11RMBSSAverageAccessDelayActivated is true. 27 Measurement Pilot The Measurement Pilot Transmission element is present if Transmission dot11RMMeasurementPilotActivated is a value between 2 and 7. 28 Multiple BSSID One or more Multiple BSSID elements are present if dot11RMMeasurementPilotActivated is a value between 2 and 7 and the AP is a member of a multiple BSSID set (see 11.11.14) with two or more members, or if dot11MultiBSSIDActivated is true, or if dot11InterworkingServiceActivated is true and the AP is a member of a multiple BSSID set with two or more members and at least one dot11GASAdvertisementID exists. 29 RM Enabled RM Enabled Capabilities element is present if Capabilities dot11RadioMeasurementActivated is true. 30 Mobility Domain The Mobility Domain element (MDE) is present if dot11FastBSSTransitionActivated is true. 31 DSE registered The DSE Registered Location element is present if location dot11LCIDSERequired is true. 32 Extended Channel The Extended Channel Switch Announcement element is Switch optionally present if dot11ExtendedChannelSwitchActivated is Announcement true. 33 Supported Operating The Supported Operating Classes element is present if Classes dot11ExtendedChannelSwitchActivated is true. The Supported Operating Classes element is optionally present if dot11TVHTOptionImplemented is true. 34 HT Capabilities The HT Capabilities element is present when dot11HighThroughputOptionImplemented is true. 35 HT Operation The HT Operation element is included by an AP and a mesh STA when dot11HighThroughputOptionImplemented is true. 36 20/40 BSS The 20/40 BSS Coexistence element is optionally present when Coexistence the dot112040BSSCoexistenceManagementSupport is true. 37 Overlapping BSS The Overlapping BSS Scan Parameters element is optionally Scan Parameters present if dot11FortyMHzOptionImplemented is true. 38 Extended The Extended Capabilities element is present if any of the fields in Capabilities this element are nonzero. 39 FMS Descriptor The FMS Descriptor element is present if dot11FMSActivated is true. 40 QoS Traffic The QoS Traffic Capability element is optionally present if Capability dot11ACStationCountActivated is true. 696 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-27â€”Beacon frame body (continued) Order Information Notes 41 Time Advertisement The Time Advertisement element is present every dot11TimeAdvertisementDTIMInterval if dot11UTCTSFOffsetActivated is true. 42 Interworking The Interworking element is present if dot11InterworkingServiceActivated is true. 43 Advertisement Advertisement Protocol element is present if Protocol dot11InterworkingServiceActivated is true and at least one dot11GASAdvertisementID MIB attribute exists. 44 Roaming The Roaming Consortium element is present if Consortium dot11InterworkingServiceActivated is true and the dot11RoamingConsortiumTable has at least one entry. 45 Emergency Alert One or more Emergency Alert Identifier elements are present if Identifier dot11EASActivated is true and there are one or more EAS message(s) active in the network. 46 Mesh ID The Mesh ID element is present if dot11MeshActivated is true. 47 Mesh Configuration The Mesh Configuration element is present if dot11MeshActivated is true. 48 Mesh Awake The Mesh Awake Window element is optionally present if Window dot11MeshActivated is true. 49 Beacon Timing The Beacon Timing element is optionally present if both dot11MeshActivated and dot11MBCAActivated are true. 50 MCCAOP The MCCAOP Advertisement Overview element is optionally Advertisement present if both dot11MeshActivated and dot11MCCAActivated Overview are true. 51 MCCAOP One or more MCCAOP Advertisement elements are optionally Advertisement present if both dot11MeshActivated and dot11MCCAActivated are true. 52 Mesh Channel The Mesh Channel Switch Parameters element is present when Switch Parameters dot11MeshActivated is true and either Channel Switch Announcement element or Extended Channel Switch Announcement element is present. 53 QMF Policy Indicates the QMF policy parameters of the transmitting STA. The QMF Policy element is present when dot11QMFActivated is true and the transmitting STA is an AP or a mesh STA. This element is not present otherwise. 54 QLoad Report The QLoad Report element is present every dot11QLoadReportIntervalDTIM DTIMs if dot11QLoadReportActivated is true. 55 HCCA TXOP The HCCA TXOP Update Count element is present if both Update Count dot11PublicHCCATXOPNegotiationActivated is true and an HC is collocated with the AP. 56 Multi-band The Multi-band element is optionally present if dot11MultibandImplemented is true. 57 VHT Capabilities The VHT Capabilities element is present when the dot11VHTOptionImplemented is true. 58 VHT Operation The VHT Operation element is present when the dot11VHTOptionImplemented is true; otherwise, it is not present. 697 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-27â€”Beacon frame body (continued) Order Information Notes 59 Transmit Power One Transmit Power Envelope element is present for each distinct Envelope element value of the Local Maximum Transmit Power Unit Interpretation subfield that is supported for the BSS if both of the following conditions are met: â€” dot11VHTOptionImplemented or dot11ExtendedSpectrumManagementImplemented is true; â€” Either dot11SpectrumManagementRequired is true or dot11RadioMeasurementActivated is true. Otherwise, this parameter is not present. 60 Channel Switch The Channel Switch Wrapper element is optionally present if Wrapper element dot11VHTOptionImplemented or dot11ExtendedSpectrumManagementImplemented is true and at least one of a Channel Switch Announcement element or an Extended Channel Switch Announcement element is also present in the Beacon frame and the Channel Switch Wrapper element contains at least one subelement. 61 Extended BSS Load The Extended BSS Load element is optionally present if element dot11QosOptionImplemented, dot11QBSSLoadImplemented, and dot11VHTOptionImplemented are true. 62 Quiet Channel Either one Quiet Channel element containing an AP Quiet Mode field equal to 0 or, in an infrastructure BSS, one or more Quiet Channel elements each containing an AP Quiet Mode field equal to 1 are optionally present if dot11VHTOptionImplemented is true, and either dot11SpectrumManagementRequired or dot11RadioMeasurementActivated is true. 63 Operating Mode The Operating Mode Notification element is optionally present if Notification dot11OperatingModeNotificationImplemented is true. 64 Reduced Neighbor The Reduced Neighbor Report element is optionally present if Report dot11TVHTOptionImplemented is true. 65 TVHT Operation The TVHT Operation element is present for a TVHT STA when the dot11TVHTOptionImplemented is true; otherwise it is not present. 66 Estimated Service The Estimated Service Parameters element is present if Parameters dot11EstimatedServiceParametersOptionImplemented is true. 67 Future Channel The Future Channel Guidance element is optionally present if Guidance dot11FutureChannelGuidanceActivated is true. Last Vendor Specific One or more vendor-specific elements are optionally present. These elements follow all other elements. 9.3.3.4 ATIM frame format The frame body of an ATIM frame is null. 9.3.3.5 Disassociation frame format The frame body of a Disassociation frame contains the information shown in Table 9-28. 698 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-28â€”Disassociation frame body Order Information 1 Reason code Last â€“ 1 One or more vendor-specific elements are optionally present. Last The Management MIC element (MME) is present when management frame protection is enabled at the AP and the frame is a group addressed frame. NOTEâ€”The MME appears after all fields that it protects. Therefore, it appears last in the frame body to protect the frames as specified in 12.5.4. 9.3.3.6 Association Request frame format The frame body of an Association Request frame contains the information shown in Table 9-29. Table 9-29â€”Association Request frame body Order Information Notes 1 Capability Information 2 Listen Interval 3 SSID 4 Supported Rates and BSS This field is not present if dot11DMGOptionImplemented is true. Membership Selectors 5 Extended Supported Rates The Extended Supported Rates and BSS Membership Selectors and BSS Membership element is present if there are more than eight supported rates, and Selectors it is optional otherwise. This element is not present if dot11DMGOptionImplemented is true. 6 Power Capability The Power Capability element is present if dot11SpectrumManagementRequired is true or dot11RadioMeasurementActivated is true. 7 Supported Channels The Supported Channels element is present if dot11SpectrumManagementRequired is true and dot11ExtendedChannelSwitchActivated is false. 8 RSN The RSNE is present if dot11RSNAActivated is true. 9 QoS Capability The QoS Capability element is present if dot11QosOptionImplemented is true. 10 RM Enabled Capabilities RM Enabled Capabilities element is present if dot11RadioMeasurementActivated is true. 11 Mobility Domain The Mobility Domain element (MDE) is present in an Association Request frame if dot11FastBSSTransitionActivated is true and if the frame is being sent to an AP that advertised its FT capability in the MDE in its Beacon or Probe Response frame (i.e., AP also has dot11FastBSSTransitionActivated equal to true). 12 Supported Operating Classes The Supported Operating Classes element is present if dot11ExtendedChannelSwitchActivated is true. 13 HT Capabilities The HT Capabilities element is present when dot11HighThroughputOptionImplemented is true. 699 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-29â€”Association Request frame body (continued) Order Information Notes 14 20/40 BSS Coexistence The 20/40 BSS Coexistence element is optionally present when dot112040BSSCoexistenceManagementSupport is true. 15 Extended Capabilities The Extended Capabilities element is present if any of the fields in this element are nonzero. 16 QoS Traffic Capability The QoS Traffic Capability element is present if dot11QoSTrafficCapabilityActivated is true. 17 TIM Broadcast Request The TIM Broadcast Request element is present if dot11TIMBroadcastActivated is true. 18 Interworking The Interworking element is present if dot11InterworkingServiceActivated is true and the non-AP STA is requesting unauthenticated access to emergency services (see 11.3.5). 19 Multi-band The Multi-band element is optionally present if dot11MultibandImplemented is true. 20 DMG Capabilities The DMG Capabilities element is present if dot11DMGOptionImplemented is true. 21 Multiple MAC Sublayers The Multiple MAC Sublayers element is present if dot11MultipleMACActivated is true. 22 VHT Capabilities The VHT Capabilities element is present when the dot11VHTOptionImplemented is true. 23 Operating Mode Notification The Operating Mode Notification element is optionally present if dot11OperatingModeNotificationImplemented is true. Last Vendor Specific One or more vendor-specific elements are optionally present. These elements follow all other elements. 9.3.3.7 Association Response frame format The frame body of an Association Response frame contains the information shown in Table 9-30. Table 9-30â€”Association Response frame body Order Information Notes 1 Capability Information 2 Status code 3 AID 4 Supported Rates and BSS This field is not present if dot11DMGOptionImplemented is true. Membership Selectors 5 Extended Supported Rates The Extended Supported Rates and BSS Membership Selectors and BSS Membership element is present if there are more than eight supported rates and Selectors is optionally present otherwise. This element is not present if dot11DMGOptionImplemented is true. 6 EDCA Parameter Set The EDCA Parameter Set Element is present if dot11QosOptionImplemented is true; otherwise not present. 700 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-30â€”Association Response frame body (continued) Order Information Notes 7 RCPI The RCPI element is present if dot11RMRCPIMeasurementActivated is true. 8 RSNI The RSNI element is present if dot11RMRSNIMeasurementActivated is true. 9 RM Enabled Capabilities RM Enabled Capabilities element is present if dot11RadioMeasurementActivated is true. 10 Mobility Domain An MDE is present in an Association Response frame when dot11FastBSSTransitionActivated is true and this frame is a response to an Association Request frame that contained an MDE (i.e., an FT initial mobility domain association exchange). 11 Fast BSS Transition A Fast BSS Transition element (FTE) is present in an Association Response frame when dot11FastBSSTransitionActivated is true, dot11RSNAActivated is true, and this frame is a response to an Association Request frame that contained an MDE (i.e., an FT initial mobility domain association exchange in an RSN). 12 DSE registered location The DSE Registered Location element is present if dot11LCIDSERequired is true. 13 Timeout Interval (Association A Timeout Interval element (TIE) containing the Association Comeback time) Comeback time is present when dot11RSNAActivated is true, dot11RSNAProtectedManagementFramesActivated is true, and the association request is rejected with a status code REFUSED_TEMPORARILY. 14 HT Capabilities The HT Capabilities element is present when dot11HighThroughputOptionImplemented is true. 15 HT Operation The HT Operation element is included by an AP when dot11HighThroughputOptionImplemented is true. 16 20/40 BSS Coexistence The 20/40 BSS Coexistence element is optionally present when the dot112040BSSCoexistenceManagementSupport is true. 17 Overlapping BSS Scan The Overlapping BSS Scan Parameters element is optionally Parameters present if dot11FortyMHzOptionImplemented is true. 18 Extended Capabilities The Extended Capabilities element is present if any of the fields in this element are nonzero. 19 BSS Max Idle Period The BSS Max Idle Period element is present if dot11WirelessManagementImplemented is true. 20 TIM Broadcast Response The TIM Broadcast Response element is present if dot11TIMBroadcastActivated is true and the TIM Broadcast Request element is present in the Association Request frame that elicited this Association Response frame. 21 QoS Map The QoS Map element is present if dot11QosMapActivated is true and the QoS Map field in the Extended Capabilities element of the corresponding Association Request frame is 1. 22 QMF Policy The QMF Policy element is present if dot11QMFActivated is true and the QMFActivated subfield is 1 in the Extended Capabilities element in the Association Request frame that elicited this Association Response frame. 23 Multi-band The Multi-band element is optionally present if dot11MultibandImplemented is true. 701 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-30â€”Association Response frame body (continued) Order Information Notes 24 DMG Capabilities The DMG Capabilities element is present if dot11DMGOptionImplemented is true. 25 DMG Operation The DMG Operation element is present if dot11DMGOptionImplemented is true. 26 Multiple MAC Sublayers The Multiple MAC Sublayers element is present if dot11MultipleMACActivated is true. 27 Neighbor Report One or more Neighbor Report elements is present if the Reason Code is REJECTED_WITH_SUGGESTED_BSS_TRANSITION. 27 VHT Capabilities The VHT Capabilities element is present when the dot11VHTOptionImplemented is true. 28 VHT Operation The VHT Operation element is present when the dot11VHTOptionImplemented is true; otherwise, it is not present. 29 Operating Mode Notification The Operating Mode Notification element is optionally present if dot11OperatingModeNotificationImplemented is true. 30 Future Channel Guidance The Future Channel Guidance element is optionally present if dot11FutureChannelGuidanceActivated is true. Last Vendor Specific One or more vendor-specific elements are optionally present. These elements follow all other elements. 9.3.3.8 Reassociation Request frame format The frame body of a Reassociation Request frame contains the information shown in Table 9-31. Table 9-31â€”Reassociation Request frame body Order Information Notes 1 Capability Information 2 Listen Interval 3 Current AP address 4 SSID 5 Supported Rates and BSS This field is not present if dot11DMGOptionImplemented is true. Membership Selectors 6 Extended Supported Rates The Extended Supported Rates and BSS Membership Selectors and BSS Membership element is present if there are more than eight supported rates, and Selectors it is optional otherwise. This element is not present if dot11DMGOptionImplemented is true. 7 Power Capability The Power Capability element is present if dot11SpectrumManagementRequired is true or dot11RadioMeasurementActivated is true. 8 Supported Channels The Supported Channels element is present if dot11SpectrumManagementRequired is true and dot11ExtendedChannelSwitchActivated is false. 702 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-31â€”Reassociation Request frame body (continued) Order Information Notes 9 RSN The RSNE is present if dot11RSNAActivated is true; otherwise not present. 10 QoS Capability The QoS Capability element is present if dot11QosOptionImplemented is true. 11 RM Enabled Capabilities RM Enabled Capabilities element is present if dot11RadioMeasurementActivated is true. 12 Mobility Domain The MDE is present in a Reassociation Request frame if dot11FastBSSTransitionActivated is true and the frame is being sent to an AP that advertised its FT Capability in the MDE in its Beacon or Probe Response frame (i.e., AP also has dot11FastBSSTransitionActivated is true). 13 Fast BSS Transition An FTE is present in a Reassociation Request frame if dot11FastBSSTransitionActivated is true and dot11RSNAAuthenticationSuiteSelected is 00-0F-AC:3, 00-0F- AC:4, or 00-0F-AC:9 (i.e., part of a fast BSS transition in an RSN). 14 Resource information The set of elements that formulate a RIC-Request is optionally container (RIC) present in a Reassociation Request frame if â€” dot11FastBSSTransitionActivated is true, â€” The FT resource request protocol is not used, â€” The frame is being sent to an AP that advertised its FT capability in the MDE in its Beacon or Probe Response frame (i.e., AP also has dot11FastBSSTransitionActivated is true), and â€” Either dot11RSNAAuthenticationSuiteSelected is 00-0F- AC:3, 00-0F-AC:4, or 00-0F-AC:9 (i.e., part of a fast BSS transition in an RSN) or dot11RSNAActivated is false (i.e., not in an RSN). 15 Supported Operating Classes The Supported Operating Classes element is present if dot11ExtendedChannelSwitchActivated is true. 16 HT Capabilities The HT Capabilities element is present when dot11HighThroughputOptionImplemented is true. 17 20/40 BSS Coexistence The 20/40 BSS Coexistence element is optionally present when dot112040BSSCoexistenceManagementSupport is true. 18 Extended Capabilities The Extended Capabilities element is present if any of the fields in this element are nonzero. 19 QoS Traffic Capability The QoS Traffic Capability element is present if dot11QoSTrafficCapabilityActivated is true. 20 TIM Broadcast Request The TIM Broadcast Request element is present if dot11TIMBroadcastActivated is true. 21 FMS Request The FMS Request element is optionally present if dot11FMSActivated is true. 22 DMS Request The DMS Request element is optionally present if dot11DMSActivated is true. 23 Interworking The Interworking element is present if dot11InterworkingServiceActivated is true and the non-AP STA is requesting unauthenticated access to emergency services (see 11.3.5). 703 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-31â€”Reassociation Request frame body (continued) Order Information Notes 24 Multi-band The Multi-band element is optionally present if dot11MultibandImplemented is true. 25 DMG Capabilities The DMG Capabilities element is present if dot11DMGOptionImplemented is true. 26 Multiple MAC Sublayers The Multiple MAC Sublayers element is present if dot11MultipleMACActivated is true. 27 VHT Capabilities The VHT Capabilities element is present when the dot11VHTOptionImplemented is true. 28 Operating Mode Notification The Operating Mode Notification element is optionally present if dot11OperatingModeNotificationImplemented is true. Last Vendor Specific One or more vendor-specific elements are optionally present. These elements follow all other elements. 9.3.3.9 Reassociation Response frame format The frame body of a Reassociation Response frame contains the information shown in Table 9-32. Table 9-32â€”Reassociation Response frame body Order Information Notes 1 Capability Information 2 Status code 3 AID 4 Supported Rates and BSS This field is not present if dot11DMGOptionImplemented is true. Membership Selectors 5 Extended Supported Rates The Extended Supported Rates and BSS Membership Selectors and BSS Membership element is present if there are more than eight supported rates, and Selectors it is optional otherwise. This element is not present if dot11DMGOptionImplemented is true. 6 EDCA Parameter Set The EDCA Parameter Set Element is present if dot11QosOptionImplemented is true; otherwise not present. 7 RCPI The RCPI element is present if dot11RMRCPIMeasurementActivated is true. 8 RSNI The RSNI element is present if dot11RMRSNIMeasurementActivated is true. 9 RM Enabled Capabilities RM Enabled Capabilities element is present if dot11RadioMeasurementActivated is true. 10 RSN An RSNE is present in a Reassociation Response frame if dot11FastBSSTransitionActivated is true, dot11RSNAActivated is true, and this frame is a response to a Reassociation Request frame that contained an FTE (i.e., part of a fast BSS transition in an RSN). 704 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-32â€”Reassociation Response frame body (continued) Order Information Notes 11 Mobility Domain An MDE is present in a Reassociation Response frame if dot11FastBSSTransitionActivated is true and this frame is a response to a Reassociation Request frame that contained an MDE (i.e., either an FT initial mobility domain association exchange or part of a fast BSS transition). 12 Fast BSS Transition An FTE is present in a Reassociation Response frame if dot11FastBSSTransitionActivated is true, dot11RSNAActivated is true, and this frame is a response to a Reassociation Request frame that contained an MDE (i.e., either an FT initial mobility domain association exchange or part of a fast BSS transition in an RSN). 13 RIC The set of elements that formulate a RIC-Response is present in a Reassociation Response frame if dot11FastBSSTransitionActivated is true and this frame is a response to a Reassociation Request frame that contained a RIC- Request. 14 DSE registered location The DSE Registered Location element is present if dot11LCIDSERequired is true. 15 Timeout Interval (Association A TIE containing the Association Comeback time is present when Comeback time) dot11RSNAActivated is true, dot11RSNAProtectedManagementFramesActivated is true, and the reassociation is rejected with status code REFUSED_TEMPORARILY. 16 HT Capabilities The HT Capabilities element is present when dot11HighThroughputOptionImplemented is true. 17 HT Operation The HT Operation element is included by an AP when dot11HighThroughputOptionImplemented is true. 18 20/40 BSS Coexistence The 20/40 BSS Coexistence element is optionally present when dot112040BSSCoexistenceManagementSupport is true. 19 Overlapping BSS Scan The Overlapping BSS Scan Parameters element is optionally Parameters present if dot11FortyMHzOptionImplemented is true. 20 Extended Capabilities The Extended Capabilities element is present if any of the fields in this element are nonzero. 21 BSS Max Idle Period The BSS Max Idle Period element is present if dot11WirelessManagementImplemented is true. 22 TIM Broadcast Response The TIM Broadcast Response element is present if dot11TIMBroadcastActivated is true and the TIM Broadcast Request element is present in the Reassociation Request frame that elicited this Reassociation Response frame. 23 FMS Response The FMS Response element is present if dot11FMSActivated is true and the FMS Request element is present in the Reassociation Request frame that elicited this Reassociation Response frame. 24 DMS Response The DMS Response element is present if dot11DMSActivated is true and the DMS Request element is present in the Reassociation Request frame that elicited this Reassociation Response frame. 25 QoS Map The QoS Map element is present if dot11QosMapActivated is true and the QoS Map field in the Extended Capabilities element of the corresponding Reassociation Request frame is 1. 705 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-32â€”Reassociation Response frame body (continued) Order Information Notes 26 QMF Policy The QMF Policy element is present if dot11QMFActivated is true and the QMFActivated subfield is 1 in the Extended Capabilities element in the Reassociation Request that elicited this Reassociation Response frame. 27 Multi-band The Multi-band element is optionally present if dot11MultibandImplemented is true. 28 DMG Capabilities The DMG Capabilities element is present if dot11DMGOptionImplemented is true. 29 DMG Operation The DMG Operation element is present if dot11DMGOptionImplemented is true. 30 Multiple MAC Sublayers The Multiple MAC Sublayers element is present if dot11MultipleMACActivated is true. 31 Neighbor Report One or more Neighbor Report elements is present if the Reason Code is REJECTED_WITH_SUGGESTED_BSS_TRANSITION. 31 VHT Capabilities The VHT Capabilities element is present when the dot11VHTOptionImplemented is true. 32 VHT Operation The VHT Operation element is present when the dot11VHTOptionImplemented is true; otherwise, it is not present. 33 Operating Mode Notification The Operating Mode Notification element is optionally present if dot11OperatingModeNotificationImplemented is true. 34 Future Channel Guidance The Future Channel Guidance element is optionally present if dot11FutureChannelGuidanceActivated is true. Last Vendor Specific One or more vendor-specific elements are optionally present. These elements follow all other elements. 9.3.3.10 Probe Request frame format The frame body of a Probe Request frame contains the information shown in Table 9-33. Table 9-33â€”Probe Request frame body Order Information Notes 1 SSID If dot11MeshActivated is true, the SSID element is the wildcard value as described in 9.4.2.2. 2 Supported Rates and BSS This field is not present if dot11DMGOptionImplemented is true. Membership Selectors 3 Request The Request element is optionally present if dot11RadioMeasurementActivated is true. The Request element is optionally present if dot11MultiDomainCapabilityActivated is true or if dot11EstimatedServiceParametersOptionImplemented is true. 706 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-33â€”Probe Request frame body (continued) Order Information Notes 4 Extended Supported Rates The Extended Supported Rates and BSS Membership Selectors and BSS Membership element is present if there are more than eight supported rates and Selectors is optionally present otherwise. This element is not present if dot11DMGOptionImplemented is true. 5 DSSS Parameter Set The element is optionally present. The DSSS Parameter Set element is present within Probe Request frames generated by STAs using Clause 15, Clause 16, or Clause 18 PHYs if dot11RadioMeasurementActivated is true. The DSSS Parameter Set element is present within Probe Request frames generated by STAs using a Clause 19 PHY in the 2.4 GHz band if dot11RadioMeasurementActivated is true. The DSSS Parameter Set element is optionally present within Probe Request frames generated by STAs using Clause 15, Clause 16, or Clause 18 PHYs if dot11RadioMeasurementActivated is false. The DSSS Parameter Set element is optionally present within Probe Request frames generated by STAs using a Clause 19 PHY in the 2.4 GHz band if dot11RadioMeasurementActivated is false. 6 Supported Operating Classes The Supported Operating Classes element is present if dot11ExtendedChannelSwitchActivated is true. The Supported Operating Classes element is optionally present if dot11TVHTOptionImplemented is true. 7 HT Capabilities The HT Capabilities element is present when dot11HighThroughputOptionImplemented is true. 8 20/40 BSS Coexistence The 20/40 BSS Coexistence element is optionally present when dot112040BSSCoexistenceManagementSupport is true. 9 Extended Capabilities The Extended Capabilities element is present if any of the fields in this element are nonzero. 10 SSID List The SSID List element is optionally present if dot11SSIDListActivated is true. 11 Channel Usage The Channel Usage element is optionally present if dot11ChannelUsageActivated is true. 12 Interworking The Interworking element is present if dot11InterworkingServiceActivated is true. 13 Mesh ID The Mesh ID element is present if dot11MeshActivated is true. 14 Multi-band The Multi-band element is optionally present if dot11MultibandImplemented is true. 15 DMG Capabilities The DMG Capabilities element is present if dot11DMGOptionImplemented is true. 16 Multiple MAC Sublayers The Multiple MAC Sublayers element is present if dot11MultipleMACActivated is true. 17 VHT Capabilities The VHT Capabilities element is present when the dot11VHTOptionImplemented is true. 18 Estimated Service Parameters The Estimated Service Parameters element is optionally present if dot11EstimatedServiceParametersOptionImplemented is true. 707 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-33â€”Probe Request frame body (continued) Order Information Notes 19 Extended Request The Extended Request element is optionally present if dot11RadioMeasurementActivated is true. Last Vendor Specific One or more vendor-specific elements are optionally present. These elements follow all other elements. 9.3.3.11 Probe Response frame format The frame body of a Probe Response frame contains the information shown in Table 9-34. See additional details and procedures in 11.1.4. Table 9-34â€”Probe Response frame body Order Information Notes 1 Timestamp 2 Beacon interval 3 Capability Information 4 SSID If dot11MeshActivated is true, the SSID element is the wildcard value as described in 9.4.2.2. 5 Supported Rates and BSS This field is not present if dot11DMGOptionImplemented is true. Membership Selectors 6 DSSS Parameter Set The element is optionally present. The DSSS Parameter Set element is present within Probe Response frames generated by STAs using Clause 15, Clause 16, and Clause 18 PHYs. The DSSS Parameter Set element is present within Probe Response frames generated by STAs using a Clause 19 PHY in the 2.4 GHz band. 7 CF Parameter Set The CF Parameter Set element is present only within Probe Response frames generated by APs supporting a PCF. 8 IBSS Parameter Set The IBSS Parameter Set element is present only within Probe Response frames generated by IBSS STAs. 9 Country The Country element is present if dot11MultiDomainCapabilityActivated is true or dot11SpectrumManagementRequired is true or dot11RadioMeasurementActivated is true. 10 Power Constraint The Power Constraint element is present if dot11SpectrumManagementRequired is true and is optionally present if dot11RadioMeasurementActivated is true. 11 Channel Switch The Channel Switch Announcement element is optionally present if Announcement dot11SpectrumManagementRequired is true. 12 Quiet The Quiet element is optionally present if dot11SpectrumManagementRequired is true or if dot11RadioMeasurementActivated is true. 13 IBSS DFS The IBSS DFS element is present if dot11SpectrumManagementRequired is true in an IBSS. 708 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-34â€”Probe Response frame body (continued) Order Information Notes 14 TPC Report The TPC Report element is present if dot11SpectrumManagementRequired is true or dot11RadioMeasurementActivated is true. 15 ERP The ERP element is present within Probe Response frames generated by STAs using ERPs and is optionally present otherwise. 16 Extended Supported Rates The Extended Supported Rates and BSS Membership Selectors and BSS Membership element is present if there are more than eight supported rates, and Selectors it is optionally present otherwise. This element is not present if dot11DMGOptionImplemented is true. 17 RSN The RSNE is present if dot11RSNAActivated is true; otherwise not present. 18 BSS Load The BSS Load element is present if dot11QosOption-Implemented and dot11QBSSLoadImplemented are both true. 19 EDCA Parameter Set The EDCA Parameter Set element is present if dot11QosOptionImplemented is true and dot11MeshActivated is false. 20 Measurement Pilot The Measurement Pilot Transmission element is present if Transmission dot11RMMeasurementPilotActivated is between 2 and 7. 21 Multiple BSSID One or more Multiple BSSID elements are present if dot11RMMeasurementPilotActivated is between 2 and 7 and the AP is a member of a multiple BSSID set (see 11.11.14) with two or more members, or if dot11MultiBSSIDActivated is true, or if dot11InterworkingServiceActivated is true and the AP is a member of a multiple BSSID set with two or more members and at least one dot11GASAdvertisementID MIB attribute exists. 22 RM Enabled Capabilities The RM Enabled Capabilities element is present if dot11RadioMeasurementActivated is true. 23 AP Channel Report If dot11RMAPChannelReportActivated is true, one AP Channel Report element is optionally present for each operating class that has at least 1 channel to report. 24 BSS Average Access Delay The BSS Average Access Delay element is optionally present if dot11RMBSSAverageAccessDelayActivated is true and the value of the AP Average Access Delay field is not equal to 255 (measurement not available). 25 Antenna The Antenna element is optionally present if dot11RMAntennaInformationActivated is true and the value of the Antenna ID field is not equal to 0 (unknown antenna). 26 BSS Available Admission The BSS Available Admission Capacity element is optionally Capacity present if dot11RMBSSAvailableAdmissionCapacityActivated is true with the following exceptions: 1) when Available Admission Capacity Bitmask equals 0 (Available Admission Capacity List contains no entries), or 2) when the BSS Load element is present and the Available Capacity Bitmask equals 256 (Available Admission Capacity List contains only the AC_VO entry). 27 BSS AC Access Delay The BSS AC Access Delay element is optionally present if dot11RMBSSAverageAccessDelayActivated is true and at least one field of the element is not equal to 255 (measurement not available). 28 Mobility Domain The MDE is present if dot11FastBSSTransitionActivated is true. 709 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-34â€”Probe Response frame body (continued) Order Information Notes 29 DSE registered location The DSE Registered Location element is present if dot11LCIDSERequired is true. 30 Extended Channel Switch The Extended Channel Switch Announcement element is optionally Announcement present if dot11ExtendedChannelSwitchActivated is true. 31 Supported Operating Classes The Supported Operating Classes element is present if dot11ExtendedChannelSwitchActivated is true. The Supported Operating Classes element is optionally present if dot11TVHTOptionImplemented is true. 32 HT Capabilities The HT Capabilities element is present when dot11HighThroughputOptionImplemented is true. 33 HT Operation The HT Operation element is included by an AP and a mesh STA when dot11HighThroughputOptionImplemented is true. 34 20/40 BSS Coexistence The 20/40 BSS Coexistence element is optionally present when dot112040BSSCoexistenceManagementSupport is true. 35 Overlapping BSS Scan The Overlapping BSS Scan Parameters element is optionally Parameters present if dot11FortyMHzOptionImplemented is true. 36 Extended Capabilities The Extended Capabilities element is present if any of the fields in this element are nonzero. 37 QoS Traffic Capability The QoS Traffic Capability element is optionally present if dot11ACStationCountActivated is true. 38 Channel Usage The Channel Usage element is present if the Channel Usage element is present in the Probe Request frame and dot11ChannelUsageActivated is true. 39 Time Advertisement The Time Advertisement element is present if dot11UTCTSFOffsetActivated is true. 40 Time Zone The Time Zone element is present if dot11UTCTSFOffsetActivated is true. 41 Interworking The Interworking element is present if dot11InterworkingServiceActivated is true. 42 Advertisement Protocol Advertisement Protocol element is present if dot11InterworkingServiceActivated is true and at least one dot11GASAdvertisementID exists. 43 Roaming Consortium The Roaming Consortium element is present if dot11InterworkingServiceActivated is true and the dot11RoamingConsortiumTable has at least one entry. 44 Emergency Alert Identifier One or more Emergency Alert Identifier elements are present if dot11EASActivated is true and there are one or more EAS message(s) active in the network. 45 Mesh ID The Mesh ID element is present if dot11MeshActivated is true. 46 Mesh Configuration The Mesh Configuration element is present if dot11MeshActivated is true. 47 Mesh Awake Window The Mesh Awake Window element is optionally present if dot11MeshActivated is true. 48 Beacon Timing The Beacon Timing element is optionally present if both dot11MeshActivated and dot11MBCAActivated are true. 710 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-34â€”Probe Response frame body (continued) Order Information Notes 49 MCCAOP Advertisement The MCCAOP Advertisement Overview element is optionally Overview present if both dot11MeshActivated and dot11MCCAActivated are true. 50 MCCAOP Advertisement One or more MCCAOP Advertisement elements are optionally present if both dot11MeshActivated and dot11MCCAActivated are true. 51 Mesh Channel Switch The Mesh Channel Switch Parameters element is present if Parameters dot11MeshActivated is true and either Channel Switch Announcement element or Extended Channel Switch Announcement element is present. 52 QMF Policy The QMF Policy element is present if dot11QMFActivated is true and the QMFActivated subfield is 1 in the Extended Capabilities element in the Probe Request that elicited this Probe Response frame. 53 QLoad Report The QLoad Report element is present if dot11QLoadReportActivated is true. 54 Multi-band The Multi-band element is optionally present if dot11MultibandImplemented is true. 55 DMG Capabilities The DMG Capabilities element is present if dot11DMGOptionImplemented is true. 56 DMG Operation The DMG Operation element is present if dot11DMGOptionImplemented is true. 57 Multiple MAC Sublayers The Multiple MAC Sublayers element is present if dot11MultipleMACActivated is true. 58 Antenna Sector ID Pattern The Antenna Sector ID Pattern element is optionally present if dot11DMGOptionImplemented is true. 59 VHT Capabilities The VHT Capabilities element is present when the dot11VHTOptionImplemented is true. 60 VHT Operation The VHT Operation element is present when the dot11VHTOptionImplemented is true; otherwise, it is not present. 61 Transmit Power Envelope One Transmit Power Envelope element is present for each distinct element value of the Local Maximum Transmit Power Unit Interpretation subfield that is supported for the BSS if both of the following conditions are met: â€” dot11VHTOptionImplemented or dot11ExtendedSpectrumManagementImplemented is true; â€” Either dot11SpectrumManagementRequired is true or dot11RadioMeasurementActivated is true. Otherwise, this parameter is not present. 62 Channel Switch Wrapper The Channel Switch Wrapper element is optionally present if element dot11VHTOptionImplemented or dot11ExtendedSpectrumManagementImplemented is true and at least one of a Channel Switch Announcement element or an Extended Channel Switch Announcement element is also present in the Probe Response frame and the Channel Switch Wrapper element contains at least one subelement. 63 Extended BSS Load element The Extended BSS Load element is optionally present if dot11QosOptionImplemented, dot11QBSSLoadImplemented and dot11VHTOptionImplemented are true. 711 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-34â€”Probe Response frame body (continued) Order Information Notes 64 Quiet Channel Either one Quiet Channel element containing an AP Quiet Mode field equal to 0 or, in an infrastructure BSS, one or more Quiet Channel elements each containing an AP Quiet Mode field equal to 1 are optionally present if dot11VHTOptionImplemented is true, and either dot11SpectrumManagementRequired or dot11RadioMeasurementActivated is true. 65 Operating Mode Notification The Operating Mode Notification element is optionally present if dot11OperatingModeNotificationImplemented is true. 66 Reduced Neighbor Report The Reduced Neighbor Report element is optionally present if dot11TVHTOptionImplemented is true. 67 TVHT Operation The TVHT Operation element is present for a TVHT STA when the dot11TVHTOptionImplemented is true; otherwise it is not present. 68 Estimated Service Parameters The Estimated Service Parameters element is optionally present if dot11EstimatedServiceParametersOptionImplemented is true. 69 Relay Capabilities The Relay Capabilities element is present if dot11RelayActivated is true; otherwise not present. Lastâ€“1 Vendor Specific One or more vendor-specific elements are optionally present. These elements follow all other elements, except the Requested elements. Last Requested elements Elements requested by the Request element or Extended Request element(s) of the Probe Request frame are present if dot11MultiDomainCapabilityActivated or dot11EstimatedServiceParametersOptionImplemented is true. See 11.1.4.3.2 and 11.46. 9.3.3.12 Authentication frame format The frame body of an Authentication frame contains the information shown in Table 9-35. FT authentication is used when FT support is advertised by the AP and dot11FastBSSTransitionActivated is true in the STA. SAE authentication is used when dot11MeshActiveAuthenticationProtocol is sae (1). Table 9-35â€”Authentication frame body Order Information Notes 1 Authentication algorithm number 2 Authentication transaction sequence number 3 Status code The status code information is reserved in certain Authentication frames as defined in Table 9-36. 4 Challenge text A Challenge Text element is present only in certain Authentication frames as defined in Table 9-36. 5 RSN An RSNE is present only in certain Authentication frames as defined in Table 9-36. 6 Mobility Domain An MDE is present only in certain Authentication frames as defined in Table 9-36. 712 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-35â€”Authentication frame body (continued) Order Information Notes 7 Fast BSS Transition An FTE is present only in certain Authentication frames as defined in Table 9-36. 8 Timeout Interval A TIE containing the reassociation deadline interval is present (reassociation deadline) only in certain Authentication frames as defined in Table 9-36. 9 RIC A resource information container, containing a variable number of elements, is present only in certain Authentication frames as defined in Table 9-36. 10 Finite Cyclic Group An unsigned integer indicating a finite cyclic group as described in 12.4.4. This is present only in certain Authentication frames as defined in Table 9-36. 11 Anti-Clogging Token A random bit string used for anti-clogging purposes as described in 12.4.6. This is present only in certain Authentication frames as defined in Table 9-36. 12 Send-Confirm A binary encoding of an integer used for anti-replay purposes as described in 12.4.7.5. This is present only in certain Authentication frames as defined in Table 9-36. 13 Scalar An unsigned integer encoded as described in 12.4.7.4. This is present only in certain Authentication frames as defined in Table 9-36. 14 Finite field element A Finite field element field from a finite field encoded as described in 12.4.7.4. This is present is present only in certain Authentication frames as defined in Table 9-36. 15 Confirm An unsigned integer encoded as described in 12.4.7.5. This is present only in certain Authentication frames as defined in Table 9-36. 16 Multi-band The Multi-band element is optionally present if dot11MultibandImplemented is true. 17 Neighbor Report One or more Neighbor Report elements are present only in certain Authentication frames as defined in Table 9-36. Last Vendor Specific One or more vendor-specific elements are optionally present. These elements follow all other elements. Table 9-36â€”Presence of fields and elements in Authentication frames Authentication Authentication transaction Status code Presence of fields 4 onwards algorithm sequence number Open System 1 Reserved Not present Open System 2 Not Not present REJECTED_WITH_SUGGE STED_BSS_TRANSITION Open System 2 REJECTED_WITH_SUGGE One or more Neighbor Report STED_BSS_TRANSITION element(s) is present Shared Key 1 Reserved Not present Shared Key 2 Any The Challenge text element is present 713 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-36â€”Presence of fields and elements in Authentication frames (continued) Authentication Authentication transaction Status code Presence of fields 4 onwards algorithm sequence number Shared Key 3 Reserved The Challenge text element is present Shared Key 4 Any Not present FT 1 Reserved The Mobility Domain element is present. The Fast BSS Transition element and RSNEs are present if dot11RSNAActivated is true. FT 2 Not The Mobility Domain element is REJECTED_WITH_SUGGE present if the Status Code field is 0. STED_BSS_TRANSITION The Fast BSS Transition element and RSNEs are present if the Status Code field is 0 and dot11RSNAActivated is true. FT 2 REJECTED_WITH_SUGGE One or more Neighbor Report STED_BSS_TRANSITION element(s) is present FT 3 Reserved The Mobility Domain element is present. The Fast BSS Transition element and RSNEs are present if dot11RSNAActivated is true. The RIC element is optionally present. FT 4 Any The Mobility Domain element is present if the Status Code field is 0. The Fast BSS Transition element and RSNEs are present if dot11RSNAActivated is true. The RIC element is optionally present if the Status Code field is 0. The TIE (reassociation deadline) is present if a RIC element is present. SAE 1 Any Scalar is present if the Status Code field is zero. Element is present if the Status Code field is zero. Anti-Clogging Token is present if status is 76 or if frame is in response to a previous rejection with Status 76. Finite Cyclic Group is present if the Status Code field is zero or 76. 714 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-36â€”Presence of fields and elements in Authentication frames (continued) Authentication Authentication transaction Status code Presence of fields 4 onwards algorithm sequence number SAE 2 Not Send-Confirm is present. Confirm REJECTED_WITH_SUGGE is present. STED_BSS_TRANSITION SAE 2 REJECTED_WITH_SUGGE One or more Neighbor Report STED_BSS_TRANSITION element(s) are present 9.3.3.13 Deauthentication The frame body of a Deauthentication frame contains the information shown in Table 9-37. Table 9-37â€”Deauthentication frame body Order Information 1 Reason code Last â€“ 1 One or more vendor-specific elements are optionally present. Last The Management MIC element (MME) is present when management frame protection is enabled at the AP and the frame is a group addressed frame. NOTEâ€”The MME appears after all fields that it protects. Therefore, it appears last in the frame body to protect the frames as specified in 12.5.4. 9.3.3.14 Action frame format The frame body of an Action frame contains the information shown in Table 9-38. Table 9-38â€”Action frame body Order Information 1 Action Last â€“ 2 One or more vendor-specific elements are optionally present. These elements are absent when the Category subfield of the Action field is Vendor-Specific, Vendor-Specific Protected, or Self-protected or when the Category subfield of the Action field is VHT and the VHT Action subfield of the Action field is VHT Compressed Beamforming. Last â€“ 1 The Management MIC element (MME) is present when management frame protection is enabled at the AP, the frame is a group addressed robust Action frame, and the category of the Action frame does not support group addressed privacy as indicated by Table 9-47. Last The Authenticated Mesh Peering Exchange element is present in a Self-protected Action frame if dot11MeshSecurityActivated, dot11ProtectedQLoadReportActivated, or dot11ProtectedTXOPNegotiationActivated is true and a PMK exists between the sender and recipient of this frame; otherwise not present. NOTEâ€”The MME appears after any fields that it protects. Therefore, it appears last in the frame body to protect the frames as specified in 12.5.4. 715 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.3.3.15 Action No Ack frame format The frame body of an Action No Ack frame contains the information shown in Table 9-39. Table 9-39â€”Action No Ack frame body Order Information 1 Action Last One or more vendor-specific elements are optionally present. This element follows all other elements. NOTEâ€”The selection of Action or Action No Ack is made per frame that uses these formats. Unless specified as allowing the use of the Action No Ack management frame subtype, a frame described as an â€œAction frameâ€ uses only the Action subtype. 9.3.3.16 Timing Advertisement frame format The frame body of a Timing Advertisement frame contains the information shown in Table 9-40. Table 9-40â€”Timing Advertisement frame body Order Information Notes 1 Timestamp See 9.4.1.10 for Timestamp format. 2 Capability Information 3 Country The Country element is present if dot11MultiDomainCapabilityActivated is true or dot11SpectrumManagementRequired is true. 4 Power Constraint The Power Constraint element is optionally present if the Country element is present; otherwise not present. 5 Time Advertisement The Time Advertisement element is optionally present. See 9.4.2.61. 6 Extended Capabilities The Extended Capabilities element is present. Last Vendor specific One or more vendor-specific elements are optionally present. These elements follow all other elements. 9.3.4 Extension frames 9.3.4.1 Format of Extension frames The format of Extension frames is defined in Figure 9-59. The MAC header of an Extension frame starts with the Frame Control field followed by the Duration field. The MAC header of different Extension frames can have different number and types of fields following the Duration field. 716 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Octets: 2 2 variable variable ... variable variable 4 Frame Frame Control Duration ... Body FCS MAC header Figure 9-59â€”Extension frame format 9.3.4.2 DMG Beacon The format of the DMG Beacon frame is shown in Figure 9-60. In addition to supporting functions such as network synchronization (see 11.1), the DMG Beacon frame can also be used as a training frame for beamforming (see 10.38). Frame Control Duration BSSID Frame FCS Body Octets: 2 2 6 Variable 4 Figure 9-60â€”DMG Beacon frame format The Duration field is set to the time remaining until the end of the beacon transmission interval (BTI). The BSSID field contains the BSSID. The Frame Body field of the DMG Beacon frame contains the elements listed in Table 9-41. Table 9-41â€”DMG Beacon frame body Order Information Notes 1 Timestamp See 9.4.1.10 2 Sector Sweep See 9.5.1 3 Beacon Interval See 9.4.1.3 4 Beacon Interval Control See Figure 9-61. 5 DMG Parameters See 9.4.1.47 6 Clustering Control Optional. See Figure 9-62 and Figure 9-63. 7 DMG Capabilities The DMG Capabilities element is optionally present. 8 Extended Schedule The Extended Schedule element is optionally present. 9 RSN The RSNE is optionally present if dot11RSNAActivated is true. 10 Multiple BSSID One or more Multiple BSSID elements are optionally present if dot11MultiBSSIDActivated is true. 11 DMG Operation The DMG Operation element is optionally present. 12 Next DMG ATI The Next DMG ATI element is optionally present. 717 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-41â€”DMG Beacon frame body (continued) Order Information Notes 13 DMG BSS Parameter The DMG BSS Parameter Change element is optionally present. Change 14 Multi-band Zero or more Multi-band elements are present if dot11MultibandImplemented is true. 15 Awake Window The Awake Window element is optionally present. If present, this element specifies the characteristics of the awake window of a CBAP (see 11.2.7). 16 DMG Wakeup Schedule The DMG Wakeup Schedule element is optionally present (see 11.2.7.3.3. 17 UPSIM The UPSIM element is optionally present (see 11.2.7.2.2). 18 SSID The SSID element is optionally present. 19 IBSS Parameter Set The IBSS Parameter Set element is present only within DMG Beacon frames generated by IBSS STAs. 20 Country The Country element is optionally present if dot11MultiDomainCapabilityActivated is true or dot11SpectrumManagementRequired is true or dot11RadioMeasurementActivated is true. 21 BSS Load The BSS Load element is optionally present if dot11QosOptionImplemented and dot11QBSSLoadImplemented are both true. 22 EDCA Parameter Set The EDCA Parameter Set element is optionally present. 23 Power Constraint The Power Constraint element is optionally present if dot11SpectrumManagementRequired is true and is optionally present if dot11RadioMeasurementActivated is true. 24 Channel Switch The Channel Switch Announcement element is optionally present if Announcement dot11SpectrumManagementRequired is true. 25 Neighbor Report The Neighbor Report element is optionally present. 26 Quiet The Quiet element is optionally present if dot11SpectrumManagementRequired is true or dot11RadioMeasurementActivated is true. 27 QoS Capability The QoS Capability element is optionally present. 28 Extended Channel The Extended Channel Switch Announcement element is optionally Switch Announcement present if dot11ExtendedChannelSwitchActivated is true. 29 BSS Average Access The BSS Average Access Delay element is optionally present. Delay 30 RM Enabled The RM Enabled Capabilities element is optionally present if Capabilities dot11RadioMeasurementActivated is true. 31 Nontransmitted BSSID The Nontransmitted BSSID Capability element is optionally present. Capability 32 SSID List The SSID List element is optionally present if dot11SSIDListActivated is true. 33 Interworking The Interworking element is optionally present if dot11InterworkingServiceActivated is true. 718 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-41â€”DMG Beacon frame body (continued) Order Information Notes 34 Advertisement Protocol The Advertisement Protocol element is optionally present if dot11InterworkingServiceActivated is true and at least one dot11GASAdvertisementID exists. 35 Roaming Consortium The Roaming Consortium element is optionally present if dot11InterworkingServiceActivated is true and the dot11RoamingConsortiumTable has at least one entry. 36 STA Availability The STA Availability element is optionally present. 37 Next PCP List The Next PCP List element is optionally present. 38 PCP Handover The PCP Handover element is optionally present. 39 Antenna Sector ID The Antenna Sector ID Pattern element is optionally present. Pattern Last Vendor Specific One or more vendor-specific elements are optionally present. These elements follow all other elements. The format of the Beacon Interval Control field is shown in Figure 9-61. B0 B1 B2 B5 B6 B7 B9 B10 B13 B14 CC Discovery Next ATI A-BFT FSS IsResponderTXSS Present Mode Beacon Present Length Bits: 1 1 4 1 3 4 1 B15 B18 B19 B20 B26 B27 B30 B31 B36 B37 B42 B43 B44 B47 Next Fragmented TXSS N BIs A-BFT N PCP A-BFT in Association Reserved A-BFT TXSS Span A-BFT Count Ant Ready Bits: 4 1 7 4 6 6 1 4 Figure 9-61â€”Beacon Interval Control field The CC Present subfield is set to 1 to indicate that the Clustering Control field is present in the DMG Beacon. Otherwise, the Clustering Control field is not present. The Discovery Mode subfield is set to 1 if the STA is generating the DMG Beacon following the procedure described in 11.1.3.4. Otherwise, this subfield is set to 0. The Next Beacon subfield indicates the number of beacon intervals following the current beacon interval during which the DMG Beacon frame will not be present. The ATI Present subfield is set to 1 to indicate that the announcement transmission interval (ATI) is present in the current beacon interval. Otherwise, the ATI is not present. The A-BFT Length subfield specifies the size of the A-BFT following the BTI and is defined in units of a sector sweep slot (10.38.5). The value of this field is in the range 1 to 8, with the value being equal to the bit representation plus 1. 719 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The FSS subfield specifies the number of SSW frames allowed per sector sweep slot minus one (10.38.5). The range of this subfield is 0 to 15. For example, when the number of SSW frames allowed per sector sweep is 5, the subfield contains the value 4. The IsResponderTXSS subfield is set to 1 to indicate the A-BFT following the BTI is used for responder transmit sector sweep (TXSS). This field is set to 0 to indicate responder receive sector sweep (RXSS). When this subfield is set to 0, the FSS subfield specifies the length of a complete receive sector sweep by the STA sending the DMG Beacon frame. The Next A-BFT subfield indicates the number of beacon intervals during which the A-BFT is not be present. A value of 0 indicates that the A-BFT immediately follows this BTI. The Fragmented TXSS subfield is set to 1 to indicate the TXSS is a fragmented sector sweep and is set to 0 to indicate the TXSS is a complete sector sweep. The TXSS Span subfield indicates the number of beacon intervals it takes for the STA sending the DMG Beacon frame to complete the TXSS phase. This subfield is always greater than or equal to 1. The N BIs A-BFT subfield indicates the interval, in number of beacon intervals, at which the STA sending the DMG Beacon frame allocates an A-BFT. A value of 1 indicates that every beacon interval contains an A-BFT. The A-BFT Count subfield indicates the number of A-BFTs since the STA sending the DMG Beacon frame last switched RX DMG antennas for an A-BFT. A value of 0 indicates that the DMG antenna used in the forthcoming A-BFT differs from the DMG antenna used in the last A-BFT. This subfield is reserved if the value of the Number of RX DMG Antennas field within the STAâ€™s DMG Capabilities element is 1. The N A-BFT in Ant subfield indicates how many A-BFTs the STA sending the DMG Beacon frame receives from each DMG antenna in the DMG antenna receive rotation. This subfield is reserved if the value of the Number of RX DMG Antennas field within the STAâ€™s DMG Capabilities element is 1. The PCP Association Ready subfield is set to 1 to indicate that the PCP is ready to receive Association Request frames from non-PCP STAs and is set to 0 otherwise. This subfield is reserved when transmitted by a non-PCP STA. The DMG Parameters field is defined in 9.4.1.47. If the value of Discovery Mode field is 0, the Clustering Control field is formatted as shown in Figure 9-62. If the value of the Discovery Mode field is 1, the Clustering Control field is formatted as shown in Figure 9-63. B0 B7 B8 B55 B56 B57 B58 B62 B63 Beacon SP Cluster Duration Cluster ID Member Role ClusterMaxMem Reserved Bits: 8 48 2 5 1 Figure 9-62â€”Clustering Control field format if the Discovery Mode field is 0 720 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B0 B47 B48 B63 A-BFT Responder Address Reserved Bits: 48 16 Figure 9-63â€”Clustering Control field format if the Discovery Mode field is 1 If ECAPC Policy Enforced field is set to 0, the Beacon SP Duration subfield indicates the duration, in units of 8 Âµs, of the Beacon SPs in the cluster. If ECAPC Policy Enforced field is set to 1, the Beacon SP Duration subfield indicates the maximum duration, in units of 8 Âµs, of the beacon header interval (BHI) of the BSS, and the minimum duration of Beacon SPs in the cluster (see 10.37.2.2). The cluster to which the transmitter of the Clustering Control field belongs is identified by the Cluster ID subfield. The MAC address of the S-AP or synchronization PCP (S-PCP) is the Cluster ID of the cluster. The Cluster Member Role subfield identifies the role that the transmitting STA assumes within the cluster. A value of 0 means that the STA is currently not participating in clustering. A value of 1 means that the STA acts as the S-AP or S-PCP of the cluster. A value of 2 means that the STA participates in the cluster, but not as the S-AP or S-PCP. The value 3 is reserved. The ClusterMaxMem subfield defines the maximum number of PCPs and/or APs, including the S-AP or S- PCP, that can participate in the cluster. The value of the ClusterMaxMem subfield is computed in relation to the beacon interval value (10.38.2). The value 0 is reserved. Values 8 and above are reserved if the ECAPC Policy Enforced field is set to 0. The value 1 is assigned to the S-AP or S-PCP. The A-BFT Responder Address subfield contains the MAC address of the STA that is allowed to transmit during the A-BFT, if present, that follows the BTI. 9.3.5 Frame addressing in an MBSS Mesh Data frames and Multihop Action frames enable multihop MSDU and MMPDU forwarding in an MBSS using the Mesh Control field described in 9.2.4.7.3. Table 9-42 shows the valid combinations of address fields in mesh Data frames and Multihop Action frames along with the corresponding value of the Address Extension Mode subfield in the Mesh Control field. Table 9-42â€”Valid address field usage for Mesh Data and Multihop Action frames Address Supported From Address Address Address Address Address Address To DS extension frames DS 1 2 3 4 5 6 mode Mesh Data 1 1 None RA TA DA = SA = Not Not (individually Mesh DA Mesh SA Present Present addressed) Mesh Data 0 1 None DA TA SA = Not Not Not (group Mesh SA Present Present Present addressed) Mesh Data 1 1 Address5&6 RA TA Mesh DA Mesh SA DA SA (proxied, individually addressed) 721 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-42â€”Valid address field usage for Mesh Data and Multihop Action frames (continued) Address Supported From Address Address Address Address Address Address To DS extension frames DS 1 2 3 4 5 6 mode Mesh Data 0 1 Address4 DA TA Mesh SA SA Not Not (proxied, Present Present group addressed) Multihop 0 0 Address4 RA TA DA = SA = Not Not Action Mesh DA Mesh SA Present Present (individually addressed) Multihop 0 0 None DA TA SA = Not Not Not Action (group Mesh SA Present Present Present addressed) NOTE 1â€”To DS and From DS subfields are located in the Frame Control field (see 9.2.4.1.4). The Address Extension Mode subfield is located in the Mesh Flags subfield in the Mesh Control field (see 9.2.4.7.3). Address 1, Address 2, and Address 3 fields are located in the MAC header (see 9.2.3). The Address 4 field is located in the MAC header if both To DS and From DS subfields are 1; otherwise, the Address 4 field is located in the Mesh Address Extension subfield of the Mesh Control field (see 9.2.3 and 9.2.4.7.3). Address 5 and Address 6 fields are located in the Mesh Control field if they are present (see 9.2.4.7.3). NOTE 2â€”Values for the Address Extension Mode subfield are defined in see Table 9-20. In individually addressed Mesh Data and Multihop Action frames, Address 1 and Address 2 correspond to the mesh STA receiver address (RA) and the mesh STA transmitter address (TA) for a particular mesh link. Address 3 and Address 4 correspond to the destination mesh STA and the source mesh STA of a mesh path. The Address Extension Mode subfield in the Mesh Control field indicates the presence of an optional Mesh Address Extension subfield in the Mesh Control field. When the Extension Mode subfield equals â€œAddress5&6â€ (see Table 9-20), the Mesh Control field includes Address 5 and Address 6 that correspond to the end-to-end destination address (DA) and source address (SA) of STAs that communicate over the mesh path, for instance, external STAs that communicate over the mesh BSS via proxy mesh gates (see Figure 9-64). NOTEâ€”The forwarding of individually addressed mesh Data frames uses only mesh STA addresses in fields Address 1, Address 2, Address 3, and Address 4. This allows intermediate mesh STAs to forward mesh Data frames without necessarily having any knowledge of the addresses of the source and destination end stations, which might be external addresses. Thus, proxy information only needs to be maintained by proxy mesh gates and by source mesh STAs. The term source mesh STA refers to the first mesh STA on a mesh path. A source mesh STA is either a mesh STA that is the initial source of an MSDU/MMPDU or a mesh STA that receives an MSDU/MMPDU from a mesh path or from a STA outside the mesh BSS and translates and forwards the MSDU/MMPDU on the mesh path. The address of the source mesh STA is referred to as the Mesh SA. The term destination mesh STA refers to the final mesh STA on a mesh path. A destination mesh STA is either a mesh STA that is the final destination of an MSDU/MMPDU or a mesh STA that receives an MSDU/MMPDU from a mesh path and translates and forwards the MSDU/MMPDU on another mesh path or to a STA outside of the mesh BSS. The address of the destination mesh STA is referred to as the Mesh DA. In group addressed mesh Data frames, Address 1 and Address 2 correspond to the group address and the mesh STA transmitter address (TA). Address 3 corresponds to the mesh source address (mesh SA) of the group addressed mesh Data frame. The Address Extension Mode indicates the presence of an optional 722 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications address extension field Address 4 in the Mesh Control field that corresponds to the source address (SA) of external STAs that communicate over the mesh BSS via proxy mesh gates. NOTEâ€”The reason for not using the four-address MAC header format for group addressed traffic is to avoid interactions with existing implementations. Earlier revisions of this standard defined the four-address MAC header format without defining procedures for its use. As a result there is a large number of deployed devices that use the four- address frame format in ways that would affect and be affected by mesh traffic if four-address group addressed frames were to be used. Figure 9-64 illustrates the addressing of a mesh Data frame that contains an MSDU transmitted and forwarded on a mesh path from a mesh STA collocated with a portal (STA 1) to a mesh STA collocated with an AP (STA 2) where the source is a STA outside of the mesh BSS (STA 33) that is reachable via the portal and the destination is an IEEE 802.11 STA associated with the AP (STA 22). SA mesh SA TA RA mesh DA DA STA 33 link Portal Gate Mesh Mesh Mesh Mesh Gate AP mesh mesh mesh DS STA 1 STA 4 STA 6 STA 2 STA 17 link STA 22 802.x LAN link link link DS infrastructure BSS mesh BSS (MBSS) mesh path end to end 802 communication Figure 9-64â€”Example addressing for a mesh Data frame Details on how these address mappings work in forwarding processing are described in 10.35.3 and 10.35.4 9.4 Management and Extension frame body components 9.4.1 Fields that are not elements 9.4.1.1 Authentication Algorithm Number field The Authentication Algorithm Number field indicates a single authentication algorithm. The length of the Authentication Algorithm Number field is 2 octets. The Authentication Algorithm Number field is illustrated in Figure 9-65. The following values are defined for authentication algorithm number: Authentication algorithm number = 0: Open System Authentication algorithm number = 1: Shared Key Authentication algorithm number = 2: Fast BSS Transition Authentication algorithm number = 3: Simultaneous Authentication of Equals (SAE) Authentication algorithm number = 65 535: vendor specific use NOTEâ€”The use of this value implies that a Vendor Specific element is included with more information. All other values of authentication algorithm number are reserved. Authentication Algorithm Number Octets: 2 Figure 9-65â€”Authentication Algorithm Number field 723 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.1.2 Authentication Transaction Sequence Number field The Authentication Transaction Sequence Number field indicates the current state of progress through a multistep transaction. The length of the Authentication Transaction Sequence Number field is 2 octets. The Authentication Transaction Sequence Number field is illustrated in Figure 9-66. Authentication Transaction Sequence Number Octets: 2 Figure 9-66â€”Authentication Transaction Sequence Number field 9.4.1.3 Beacon Interval field The Beacon Interval field represents the number of time units (TUs) between target beacon transmission times (TBTTs). The length of the Beacon Interval field is 2 octets. The Beacon Interval field is illustrated in Figure 9-67. Beacon Interval Octets: 2 Figure 9-67â€”Beacon Interval field A value of 0 in the Beacon Interval field transmitted by a DMG STA indicates that the TBTT of the next BTI is unknown. 9.4.1.4 Capability Information field The Capability Information field contains a number of subfields that are used to indicate requested or advertised optional capabilities. The length of the Capability Information field is 2 octets. The format of the Capability Information field is defined in Figure 9-68 when transmitted by a non-DMG STA and in Figure 9-69 when transmitted by a DMG STA. B0 B1 B2 B3 B4 B5 B6 B7 ESS IBSS CF Pollable CF-Poll Privacy Short Reserved Reserved Request Preamble B8 B9 B10 B11 B12 B13 B14 B15 Spectrum QoS Short Slot APSD Radio Reserved Delayed Immediate Management Time Measurement Block Ack Block Ack Figure 9-68â€”Capability Information field (non-DMG STA) 724 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B0 B7 B8 B9 B10 B11 B12 B13 B15 Triggered DMG Parameters Spectrum Unscheduled Reserved Radio Reserved Management Measurement PS Bits: 8 1 1 2 1 3 Figure 9-69â€”Capability Information field (DMG STA) A DMG STA sets the Triggered Unscheduled PS subfield to 1 within the Capability Information field when it transmits a Capability Information field in which the Reverse Direction subfield is equal to 1 and is capable of delivering a BU as an RD responder on receipt of a PPDU containing an RDG MPDU with the Power Management subfield set to 1 and sets it to 0 otherwise. Each Capability Information subfield is interpreted according to the management frame subtype, as defined in this subclause. An AP sets the ESS subfield to 1 and the IBSS subfield to 0 within transmitted Beacon or Probe Response frames. Otherwise, the ESS and IBSS subfields are reserved. An IBSS STA sets the ESS subfield to 0 and the IBSS subfield to 1 in transmitted Beacon or Probe Response frames. A mesh STA sets the ESS and IBSS subfields to 0 in transmitted Beacon or Probe Response frames. A non-AP STA sets the QoS, CF-Pollable, and CF-Poll Request subfields in (Re)Association Request frames according to Table 9-43. A mesh STA sets the CF-Pollable and CF-Poll Request subfields to 0. Table 9-43â€”Non-AP STA usage of QoS, CF-Pollable, and CF-Poll Request CF-Poll QoS CF-Pollable Meaning request 0 0 0 STA is not CF-Pollable 0 0 1 STA is CF-Pollable, not requesting to be placed on the CF-Polling list 0 1 0 STA is CF-Pollable, requesting to be placed on the CF-Polling list 0 1 1 STA is CF-Pollable, requesting never to be polled 1 0 0 QoS STA requesting association in a QoS BSS 1 0 1 Reserved 1 1 0 Reserved 1 1 1 Reserved An AP sets the CF-Pollable and CF-Poll Request subfields in Beacon and Probe Response frames according to Table 9-44. A non-QoS AP sets the CF-Pollable and CF-Poll Request subfield values in (Re)Association Response frames equal to the values in the last Beacon or Probe Response frame that it transmitted. An AP sets the Privacy subfield to 1 within transmitted Beacon, Probe Response, (Re)Association Response frames if data confidentiality is required for all Data frames exchanged within the BSS. If data confidentiality is not required, the Privacy subfield is set to 0. In an RSNA, a non-AP STA in an infrastructure BSS sets the Privacy subfield to 0 within transmitted (Re)Association Request frames. The Privacy subfield is reserved in (Re)Association Request frames. 725 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-44â€”AP usage of QoS, CF-Pollable, and CF-Poll Request CF-Poll QoS CF-Pollable Meaning Request 0 0 0 No PC at non-QoS AP 0 0 1 PC at non-QoS AP for delivery only (no polling) 0 1 0 PC at non-QoS AP for delivery and polling 0 1 1 Reserved 1 0 0 QoS AP (HC) does not use CFP for delivery of individually addressed Data frames 1 0 1 QoS AP (HC) uses CFP for delivery, but does not send CF-Polls to non-QoS STAs 1 1 0 QoS AP (HC) uses CFP for delivery, and sends CF-Polls to non-QoS STAs 1 1 1 Reserved A STA within an infrastructure BSS sets the Privacy subfield to 1 in DLS Request and DLS Response frames if encryption is required for all Data frames exchanged. If encryption is not required, the Privacy subfield is set to 0. An IBSS STA sets the Privacy subfield to 1 in transmitted Beacon or Probe Response frames if data confidentiality is required for all Data frames exchanged within the IBSS. If data confidentiality is not required, An IBSS STA sets the Privacy subfield to 0 within these Management frames. A mesh STA sets the Privacy subfield to 1 in transmitted Beacon or Probe Response frames if data confidentiality is required for all Data frames exchanged within the MBSS. If data confidentiality is not required, a mesh STA sets the Privacy subfield to 0 within these Management frames. A STA that includes the RSNE in Beacon and Probe Response frames sets the Privacy subfield to 1 in any frame that includes the RSNE. An AP sets the Short Preamble subfield to 1 in transmitted Beacon, Probe Response, Association Response, and Reassociation Response frames to indicate that the use of the short preamble, as described in 16.2.2.3, is allowed within this BSS; an IBSS STA sets the Short Preamble subfield to 1 in transmitted Beacon when dot11ShortPreambleOptionImplemented is true. Otherwise an AP or an IBSS STA sets the Short Preamble subfield to 0. A mesh STA sets the Short Preamble subfield to 1 when dot11ShortPreambleOptionImplemented is true. Otherwise, a mesh STA sets the Short Preamble subfield to 0. An ERP STA sets dot11ShortPreambleOptionImplemented to true as all ERP STAs support both long and short preamble formats. A STA sets the Short Preamble subfield to 1 in transmitted Association Request and Reassociation Request frames and in DLS Request and DLS Response frames when dot11ShortPreambleOptionImplemented is true. Otherwise, a STA sets the Short Preamble subfield to 0. A STA sets the Spectrum Management subfield in the Capability Information field to 1 if dot11SpectrumManagementRequired is true; otherwise, it is set to 0. 726 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A STA sets the QoS subfield to 1 within the Capability Information field when dot11QosOptionImplemented is true and sets it to 0 otherwise. A STA sets the Short Slot Time subfield to 1 in transmitted Association Request, Reassociation Request, DLS Request, and DLS Response frames when dot11ShortSlotTimeOptionImplemented and dot11ShortSlotTimeOptionActivated are true. Otherwise, the STA sets the Short Slot Time subfield to 0. An AP sets the Short Slot Time subfield in transmitted Beacon, Probe Response, Association Response, and Reassociation Response frames to indicate the currently used slot time value within this BSS. See 11.1.3.2. See 10.3.2.13 for the operation of aSlotTime. For IBSS and MBSS, the Short Slot Time subfield is set to 0. An AP sets the APSD subfield to 1 within the Capability Information field when dot11APSDOptionImplemented is true and sets it to 0 otherwise. A non-AP STA always sets this subfield to 0. A STA sets the Delayed Block Ack subfield to 1 within the Capability Information field when dot11DelayedBlockAckOptionImplemented is true and sets it to 0 otherwise. A STA sets the Immediate Block Ack subfield to 1 within the Capability Information field when dot11ImmediateBlockAckOptionImplemented is true and sets it to 0 otherwise. A STA sets the Radio Measurement subfield in the Capability Information field to 1 when dot11RadioMeasurementActivated is true and sets it to 0 otherwise. The DMG Parameters field is defined in 9.4.1.47. 9.4.1.5 Current AP Address field The Current AP Address field is the MAC address of the AP with which the STA is currently associated. The length of the Current AP Address field is 6 octets. The Current AP Address field is illustrated in Figure 9-70. Current AP Address Octets: 6 Figure 9-70â€”Current AP Address field 9.4.1.6 Listen Interval field The Listen Interval field is used to indicate to the AP how often a STA in power save mode wakes to listen to Beacon frames. The value of this field is the ListenInterval parameter of the MLME- ASSOCIATE.request or MLME-REASSOCIATE.request primitive, in units of Beacon Interval. The length of the Listen Interval field is 2 octets. The Listen Interval field is illustrated in Figure 9-71. NOTEâ€”The value 0 might be used by a STA that never enters power save mode. Listen Interval Octets: 2 Figure 9-71â€”Listen Interval field An AP uses the listen interval in determining the lifetime of frames that it buffers for a STA. 727 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.1.7 Reason Code field This Reason Code field is used to indicate the reason that an unsolicited notification Management frame of type Disassociation, Deauthentication, DELTS, DELBA, DLS Teardown, or Mesh Peering Close was generated. It is contained in the Mesh Channel Switch Parameters element to indicate the reason for the channel switch. It is contained in the PERR element to indicate the reason for the path error. The length of the Reason Code field is 2 octets. The Reason Code field is illustrated in Figure 9-72. Reason Code Octets: 2 Figure 9-72â€”Reason Code field The reason codes are defined in Table 9-45. Table 9-45â€”Reason codes Reason Name Meaning code 0 Reserved 1 UNSPECIFIED_REASON Unspecified reason 2 INVALID_AUTHENTICATION Previous authentication no longer valid 3 LEAVING_NETWORK_DEAUT Deauthenticated because sending STA is leaving (or has left) H IBSS or ESS 4 REASON_INACTIVITY Disassociated due to inactivity 5 NO_MORE_STAS Disassociated because AP is unable to handle all currently associated STAs 6 INVALID_CLASS2_FRAME Class 2 frame received from nonauthenticated STA 7 INVALID_CLASS3_FRAME Class 3 frame received from nonassociated STA 8 LEAVING_NETWORK_DISASS Disassociated because sending STA is leaving (or has left) OC BSS 9 NOT_AUTHENTICATED STA requesting (re)association is not authenticated with responding STA 10 UNACCEPTABLE_POWER_CA Disassociated because the information in the Power Capability PABILITY element is unacceptable 11 UNACCEPTABLE_SUPPORTED Disassociated because the information in the Supported _CHANNELS Channels element is unacceptable 12 BSS_TRANSITION_DISASSOC Disassociated due to BSS transition management 13 REASON_INVALID_ELEMENT Invalid element, i.e., an element defined in this standard for which the content does not meet the specifications in Clause 9 14 MIC_FAILURE Message integrity code (MIC) failure 15 4WAY_HANDSHAKE_TIMEOU 4-way handshake timeout T 16 GK_HANDSHAKE_TIMEOUT Group key handshake timeout 17 HANDSHAKE_ELEMENT_MIS Element in 4-way handshake different from (Re)Association MATCH Request/Probe Response/Beacon frame 728 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-45â€”Reason codes (continued) Reason Name Meaning code 18 REASON_INVALID_GROUP_CI Invalid group cipher PHER 19 REASON_INVALID_PAIRWISE Invalid pairwise cipher _CIPHER 20 REASON_INVALID_AKMP Invalid AKMP 21 UNSUPPORTED_RSNE_VERSI Unsupported RSNE version ON 22 INVALID_RSNE_CAPABILITIE Invalid RSNE capabilities S 23 802_1_X_AUTH_FAILED IEEE 802.1X authentication failed 24 REASON_CIPHER_OUT_OF_P Cipher suite rejected because of the security policy OLICY 25 TDLS_PEER_UNREACHABLE TDLS direct-link teardown due to TDLS peer STA unreachable via the TDLS direct link 26 TDLS_UNSPECIFIED_REASON TDLS direct-link teardown for unspecified reason 27 SSP_REQUESTED_DISASSOC Disassociated because session terminated by SSP request 28 NO_SSP_ROAMING_AGREEM Disassociated because of lack of SSP roaming agreement ENT 29 BAD_CIPHER_OR_AKM Requested service rejected because of SSP cipher suite or AKM requirement 30 NOT_AUTHORIZED_THIS_LO Requested service not authorized in this location CATION 31 SERVICE_CHANGE_ TS deleted because QoS AP lacks sufficient bandwidth for this PRECLUDES_TS QoS STA due to a change in BSS service characteristics or operational mode (e.g., an HT BSS change from 40 MHz channel to 20 MHz channel) 32 UNSPECIFIED_QOS_REASON Disassociated for unspecified, QoS-related reason NOT_ENOUGH_BANDWIDTH Disassociated because QoS AP lacks sufficient bandwidth for 33 this QoS STA 34 MISSING_ACKS Disassociated because excessive number of frames need to be acknowledged, but are not acknowledged due to AP transmissions and/or poor channel conditions 35 EXCEEDED_TXOP Disassociated because STA is transmitting outside the limits of its TXOPs 36 STA_LEAVING Requesting STA is leaving the BSS (or resetting) 37 END_TS Requesting STA is no longer using the stream or session END_BA END_DLS 38 UNKNOWN_TS Requesting STA received frames using a mechanism for which UNKNOWN_BA a setup has not been completed 39 TIMEOUT Requested from peer STA due to timeout 45 PEERKEY_MISMATCH Peer STA does not support the requested cipher suite 729 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-45â€”Reason codes (continued) Reason Name Meaning code 46 PEER_INITIATED In a DLS Teardown frame: The teardown was initiated by the DLS peer In a Disassociation frame: Disassociated because authorized access limit reached 47 AP_INITIATED In a DLS Teardown frame: The teardown was initiated by the AP In a Disassociation frame: Disassociated due to external service requirements REASON_INVALID_FT_ACTIO 48 Invalid FT Action frame count N_FRAME_COUNT 49 REASON_INVALID_PMKID Invalid pairwise master key identifier (PMKID) 50 REASON_INVALID_MDE Invalid MDE 51 REASON_INVALID_FTE Invalid FTE 52 MESH-PEERING-CANCELED Mesh peering canceled for unknown reasons 53 MESH-MAX-PEERS The mesh STA has reached the supported maximum number of peer mesh STAs 54 MESH-CONFIGURATION- The received information violates the Mesh Configuration POLICY-VIOLATION policy configured in the mesh STA profile 55 MESH-CLOSE-RCVD The mesh STA has received a Mesh Peering Close frame requesting to close the mesh peering. 56 MESH-MAX-RETRIES The mesh STA has resent dot11MeshMaxRetries Mesh Peering Open frames, without receiving a Mesh Peering Confirm frame. 57 MESH-CONFIRM-TIMEOUT The confirmTimer for the mesh peering instance times out. 58 MESH-INVALID-GTK The mesh STA fails to unwrap the GTK or the values in the wrapped contents do not match 59 MESH-INCONSISTENT- The mesh STA receives inconsistent information about the PARAMETERS mesh parameters between mesh peering Management frames 60 MESH-INVALID-SECURITY- The mesh STA fails the authenticated mesh peering exchange CAPABILITY because due to failure in selecting either the pairwise ciphersuite or group ciphersuite 61 MESH-PATH-ERROR-NO- The mesh STA does not have proxy information for this PROXY-INFORMATION external destination. 62 MESH-PATH-ERROR-NO- The mesh STA does not have forwarding information for this FORWARDING-INFORMATION destination. 63 MESH-PATH-ERROR- The mesh STA determines that the link to the next hop of an DESTINATION- active path in its forwarding information is no longer usable. UNREACHABLE 64 MAC-ADDRESS-ALREADY- The Deauthentication frame was sent because the MAC EXISTS-IN-MBSS address of the STA already exists in the mesh BSS. See 11.3.6. 65 MESH-CHANNEL-SWITCH- The mesh STA performs channel switch to meet regulatory REGULATORY- requirements. REQUIREMENTS 730 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-45â€”Reason codes (continued) Reason Name Meaning code 66 MESH-CHANNEL-SWITCH- The mesh STA performs channel switching with unspecified UNSPECIFIED reason. 67â€“65 535 Reserved 9.4.1.8 AID field In infrastructure BSS operation, the AID field contains a value assigned by an AP or PCP during association. The field represents the 16-bit ID of a STA. In mesh BSS operation, the AID field is a value that represents the 16-bit ID of a neighbor peer mesh STA. An AID value is assigned by a mesh STA that receives and accepts a Mesh Peering Open frame to the transmitter of the Mesh Peering Open frame during the mesh peering establishment process (see 14.3.1). The length of the AID field is 2 octets. The AID field is illustrated in Figure 9-73. Association ID (AID) Octets: 2 Figure 9-73â€”AID field A non-DMG STA assigns the value of the AID in the range of 1 to 2007; the 5 MSBs of the AID field are reserved. A DMG STA assigns the value of the AID field in the range 1 to 254. The value 255 is reserved as the broadcast AID, and the value 0 corresponds to the AP or PCP. The 8 MSBs of the AID field are reserved. 9.4.1.9 Status Code field The Status Code field is used in a response Management frame to indicate the success or failure of a requested operation. The length of the Status Code field is 2 octets. The Status Code field is illustrated in Figure 9-74. Status Code Octets: 2 Figure 9-74â€”Status Code field If an operation is successful, then the status code is set to SUCCESS (0). A status code of SUCCESS_POWER_SAVE_MODE also indicates a successful operation. If an operation results in failure, the status code indicates a failure cause. The failure cause codes are defined in Table 9-46. 731 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-46â€”Status codes Status code Name Meaning 0 SUCCESS Successful. 1 REFUSED, Unspecified failure. REFUSED_REASON_UNSPECIFIED 2 TDLS_REJECTED_ALTERNATIVE_ TDLS wakeup schedule rejected but alternative schedule PROVIDED provided. 3 TDLS_REJECTED TDLS wakeup schedule rejected. 4 Reserved. 5 SECURITY_DISABLED Security disabled. 6 UNACCEPTABLE_LIFETIME Unacceptable lifetime. 7 NOT_IN_SAME_BSS Not in same BSS. 8â€“9 Reserved. 10 REFUSED_CAPABILITIES_ Cannot support all requested capabilities in the MISMATCH Capability Information field. 11 DENIED_NO_ASSOCIATION_EXIS Reassociation denied due to inability to confirm that TS association exists. 12 DENIED_OTHER_REASON Association denied due to reason outside the scope of this standard. 13 UNSUPPORTED_AUTH_ALGORIT Responding STA does not support the specified HM authentication algorithm. 14 TRANSACTION_SEQUENCE_ERRO Received an Authentication frame with authentication R transaction sequence number out of expected sequence. 15 CHALLENGE_FAILURE Authentication rejected because of challenge failure. 16 REJECTED_SEQUENCE_TIMEOUT Authentication rejected due to timeout waiting for next frame in sequence. 17 DENIED_NO_MORE_STAS Association denied because AP is unable to handle additional associated STAs. 18 REFUSED_BASIC_RATES_ Association denied due to requesting STA not supporting MISMATCH all of the data rates in the BSSBasicRateSet parameter, the Basic HT-MCS Set field of the HT Operation parameter, or the Basic VHT-MCS and NSS Set field in the VHT Operation parameter. 19 DENIED_NO_SHORT_PREAMBLE_ Association denied due to requesting STA not supporting SUPPORT the short preamble option. 20 Reserved. 21 Reserved. 22 REJECTED_SPECTRUM_MANAGE Association request rejected because Spectrum MENT_REQUIRED Management capability is required. 23 REJECTED_BAD_POWER_CAPABI Association request rejected because the information in LITY the Power Capability element is unacceptable. 24 REJECTED_BAD_SUPPORTED_CH Association request rejected because the information in ANNELS the Supported Channels element is unacceptable. 25 DENIED_NO_SHORT_SLOT_TIME_ Association denied due to requesting STA not supporting SUPPORT the Short Slot Time option. 732 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-46â€”Status codes (continued) Status code Name Meaning 26 Reserved. 27 DENIED_NO_HT_SUPPORT Association denied because the requesting STA does not support HT features. 28 R0KH_UNREACHABLE R0KH unreachable. 29 DENIED_PCO_TIME_NOT_SUPPOR Association denied because the requesting STA does not TED support the phased coexistence operation (PCO) transition time required by the AP. 30 REFUSED_TEMPORARILY Association request rejected temporarily; try again later. 31 ROBUST_MANAGEMENT_POLICY Robust management frame policy violation. _VIOLATION 32 UNSPECIFIED_QOS_FAILURE Unspecified, QoS-related failure. 33 DENIED_INSUFFICIENT_BANDWI Association denied because QoS AP or PCP has DTH insufficient bandwidth to handle another QoS STA. 34 DENIED_POOR_CHANNEL_CONDI Association denied due to excessive frame loss rates and/ TIONS or poor conditions on current operating channel. 35 DENIED_QOS_NOT_SUPPORTED Association (with QoS BSS) denied because the requesting STA does not support the QoS facility. 36 Reserved. 37 REQUEST_DECLINED The request has been declined. 38 INVALID_PARAMETERS The request has not been successful as one or more parameters have invalid values. 39 REJECTED_WITH_SUGGESTED_ The allocation or TS has not been created because the CHANGES request cannot be honored; however, a suggested TSPEC/DMG TSPEC is provided so that the initiating STA can attempt to set another allocation or TS with the suggested changes to the TSPEC/DMG TSPEC. 40 STATUS_INVALID_ELEMENT Invalid element, i.e., an element defined in this standard for which the content does not meet the specifications in Clause 9. 41 STATUS_INVALID_GROUP_CIPHE Invalid group cipher. R 42 STATUS_INVALID_PAIRWISE_CIP Invalid pairwise cipher. HER 43 STATUS_INVALID_AKMP Invalid AKMP. 44 UNSUPPORTED_RSNE_VERSION Unsupported RSNE version. 45 INVALID_RSNE_CAPABILITIES Invalid RSNE capabilities. 46 STATUS_CIPHER_OUT_OF_POLIC Cipher suite rejected because of security policy. Y 47 REJECTED_FOR_DELAY_PERIOD The TS or allocation has not been created; however, the HC or PCP might be capable of creating a TS or allocation, in response to a request, after the time indicated in the TS Delay element. 48 DLS_NOT_ALLOWED Direct link is not allowed in the BSS by policy. 49 NOT_PRESENT The Destination STA is not present within this BSS. 733 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-46â€”Status codes (continued) Status code Name Meaning 50 NOT_QOS_STA The Destination STA is not a QoS STA. 51 DENIED_LISTEN_INTERVAL_TOO Association denied because the listen interval is too _LARGE large. 52 STATUS_INVALID_FT_ACTION_F Invalid FT Action frame count. RAME_COUNT 53 STATUS_INVALID_PMKID Invalid pairwise master key identifier (PMKID). 54 STATUS_INVALID_MDE Invalid MDE. 55 STATUS_INVALID_FTE Invalid FTE. 56 REQUESTED_TCLAS_NOT_ Requested TCLAS processing is not supported by the AP SUPPORTED or PCP. 57 INSUFFICIENT_TCLAS_ The AP or PCP has insufficient TCLAS processing PROCESSING_RESOURCES resources to satisfy the request. 58 TRY_ANOTHER_BSS The TS has not been created because the request cannot be honored; however, the HC or PCP suggests that the STA transition to a different BSS to set up the TS. 59 GAS_ADVERTISEMENT_ GAS Advertisement Protocol not supported. PROTOCOL_NOT_SUPPORTED 60 NO_OUTSTANDING_GAS_ No outstanding GAS request. REQUEST 61 GAS_RESPONSE_NOT_ GAS Response not received from the Advertisement RECEIVED_FROM _SERVER Server. 62 GAS_QUERY_TIMEOUT STA timed out waiting for GAS Query Response. 63 GAS_QUERY_RESPONSE_ GAS Response is larger than query response length limit. TOO_ LARGE 64 REJECTED_HOME_WITH_ Request refused because home network does not support SUGGESTED_CHANGES request. 65 SERVER_UNREACHABLE Advertisement Server in the network is not currently reachable. 66 Reserved. 67 REJECTED_FOR_SSP_ Request refused due to permissions received via SSPN PERMISSIONS interface. 68 REFUSED_UNAUTHENTICATED_A Request refused because the AP or PCP does not support CCESS_NOT_SUPPORTED unauthenticated access. 69-71 Reserved. 72 INVALID_RSNE Invalid contents of RSNE. 73 U_APSD_COEXISTANCE_NOT_SU U-APSD coexistence is not supported. PPORTED 74 U_APSD_COEX_MODE_NOT_SUPP Requested U-APSD coexistence mode is not ORTED supported. 75 BAD_INTERVAL_WITH_U_APS Requested Interval/Duration value cannot be D_COEX supported with U-APSD coexistence. 76 ANTI_CLOGGING_TOKEN_REQUI Authentication is rejected because an Anti-Clogging RED Token is required. 734 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-46â€”Status codes (continued) Status code Name Meaning 77 UNSUPPORTED_FINITE_CYCLIC_ Authentication is rejected because the offered finite GROUP cyclic group is not supported. 78 CANNOT_FIND_ALTERNATIVE_ The TBTT adjustment request has not been successful TBTT because the STA could not find an alternative TBTT. 79 TRANSMISSION_FAILURE Transmission failure. 80 REQUESTED_TCLAS_NOT_ Requested TCLAS Not Supported. SUPPORTED 81 TCLAS_RESOURCES_EXHAUSTED TCLAS Resources Exhausted. 82 REJECTED_WITH_SUGGESTED_ Rejected with Suggested BSS transition. BSS_TRANSITION 83 REJECT_WITH_SCHEDULE Reject with recommended schedule. 84 REJECT_NO_WAKEUP_SPECIFIED Reject because no wakeup schedule specified. 85 SUCCESS_POWER_SAVE_MODE Success, the destination STA is in power save mode. 86 PENDING_ADMITTING_FST_SESSI FST pending, in process of admitting FST session. ON 87 PERFORMING_FST_NOW Performing FST now. 88 PENDING_GAP_IN_BA_WINDOW FST pending, gap(s) in block ack window. 89 REJECT_U-PID_SETTING Reject because of U-PID setting. 90â€“91 Reserved. 92 REFUSED_EXTERNAL_REASON (Re)Association refused for some external reason. 93 REFUSED_AP_OUT_OF_MEMORY (Re)Association refused because of memory limits at the AP. 94 REJECTED_EMERGENCY_ (Re)Association refused because emergency services are SERVICES_NOT_SUPPORTED not supported at the AP. 95 QUERY_RESPONSE_ GAS query response not yet received. OUTSTANDING 96 REJECT_DSE_BAND Reject since the request is for transition to a frequency band subject to DSE procedures and FST Initiator is a dependent STA. 97 TCLAS_PROCESSING_ Requested TCLAS processing has been terminated by TERMINATED the AP. 98 TS_SCHEDULE_CONFLICT The TS schedule conflicts with an existing schedule; an alternative schedule is provided. 99 DENIED_WITH_SUGGESTED_BAN The association has been denied; however, one or more D_AND_CHANNEL Multi-band elements are included that can be used by the receiving STA to join the BSS. 100 MCCAOP_RESERVATION_ The request failed due to a reservation conflict. CONFLICT 101 MAF_LIMIT_EXCEEDED The request failed due to exceeded MAF limit. 102 MCCA_TRACK_LIMIT_EXCEEDED The request failed due to exceeded MCCA track limit. 103 DENIED_DUE_TO_SPECTRUM_MA Association denied because the information in the NAGEMENT Spectrum Management field is unacceptable. 735 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-46â€”Status codes (continued) Status code Name Meaning 104 DENIED_VHT_NOT_SUPPORTED Association denied because the requesting STA does not support VHT features. 105 ENABLEMENT DENIED Enablement denied. 106 RESTRICTION FROM Enablement denied due to restriction from an authorized AUTHORIZED GDB GDB. 107 AUTHORIZATION DEENABLED Authorization deenabled. 108â€“65 535 Reserved. 9.4.1.10 Timestamp field This field represents the value of the timing synchronization function (TSF) timer (see 11.1 and 11.22) of a frameâ€™s source. The length of the Timestamp field is 8 octets. The Timestamp field is illustrated in Figure 9-75. Timestamp Octets: 8 Figure 9-75â€”Timestamp field 9.4.1.11 Action field The Action field provides a mechanism for specifying extended management actions. The format of the Action field is shown in Figure 9-76. Category Action Details Octets: 1 variable Figure 9-76â€”Action field The Category field is set to one of the nonreserved values shown in the â€œCodeâ€ column of Table 9-47. Action frames of a given category are referred to as Action frames. For example, frames in the QoS category are called QoS Action frames. The Action Details field contains the details of the action. The details of the actions allowed in each category are described in the appropriate subclause referenced in Table 9-47. Table 9-47â€”Category values Group Code Meaning See subclause Robust addressed privacy 0 Spectrum Management 9.6.2 Yes No 1 QoS 9.6.3 Yes No 2 DLS 9.6.4 Yes No 736 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-47â€”Category values (continued) Group Code Meaning See subclause Robust addressed privacy 3 Block Ack 9.6.5 Yes No 4 Public 9.6.8 No No 5 Radio Measurement 9.6.7 See No NOTE 1 6 Fast BSS Transition 9.6.9 Yes No 7 HT 9.6.12 No No 8 SA Query 9.6.10 Yes No 9 Protected Dual of Public 9.6.11 Yes No Action 10 WNM 9.6.14 Yes No 11 Unprotected WNM 9.6.15 No No 12 TDLS 9.6.13 â€” No See NOTE 2 13 Mesh 9.6.17 Yes Yes 14 Multihop 9.6.18 Yes Yes 15 Self-protected 9.6.16 No No 16 DMG 9.6.20 Yes No 17 Reserved (used by the Wi- â€” â€” â€” Fi AllianceÂ® a) 18 Fast Session Transfer 9.6.21 Yes No 19 Robust AV Streaming 9.6.19 Yes No 20 Unprotected DMG 9.6.22 No No 21 VHT 9.6.23 No No 21â€“125 Reserved â€” â€” â€” 126 Vendor-specific Protected 9.6.6 Yes No 127 Vendor-specific 9.6.6 No No 128â€“255 Error â€” â€” â€” NOTE 1â€”Radio Measurement frames are robust, except for Link Measurement Request and Link Measurement Report frames in a DMG BSS. NOTE 2â€”TDLS Action fields are always transported encapsulated within a Data frame (see 11.23.1), so the question of whether these frames are robust is not applicable. a See http://www.wi-fi.org. 737 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.1.12 Dialog Token field The Dialog Token field is used for matching action responses with action requests when there are multiple, concurrent action requests. The length of the Dialog Token field is 1 octet. The Dialog Token field is illustrated in Figure 9-77. See 10.27.5. Dialog Token Octets: 1 Figure 9-77â€”Dialog Token fixed field 9.4.1.13 DLS Timeout Value field The DLS Timeout Value field is used in the DLS Request frame to indicate the timeout value for the direct link. The length of the DLS Timeout Value field is 2 octets. The DLS Timeout Value field is illustrated in Figure 9-78. See 11.7.2.4. DLS Timeout Value Octets: 2 Figure 9-78â€”DLS Timeout Value fixed field 9.4.1.14 Block Ack Parameter Set field The Block Ack Parameter Set field is used in ADDBA Request and ADDBA Response frames to signal the parameters for setting up a Block Ack. The length of the Block Ack Parameter Set field is 2 octets. The Block Ack Parameter Set field is illustrated in Figure 9-79. B0 B1 B2 B5 B6 B15 A-MSDU Block Ack Policy TID Buffer Size Supported Bits: 1 1 4 10 Figure 9-79â€”Block Ack Parameter Set fixed field The A-MSDU Supported subfield is set to 1 by a STA to indicate that it supports an A-MSDU carried in a QoS Data frame sent under this block ack agreement. It is set to 0 otherwise. The Block Ack Policy subfield is set to 1 for Immediate Block Ack and 0 for Delayed Block Ack. The TID subfield contains the value of the TC or TS for which the BlockAck frame is being requested. The Buffer Size subfield indicates the number of buffers available for this particular TID.22 When the A-MSDU Supported field is equal to 0 as indicated by the STA transmitting the Block Ack Parameter Set field, each buffer is capable of holding a number of octets equal to the maximum size of an MSDU. When the A-MSDU Supported field is equal to 1 as indicated by the STA, each buffer is capable of holding a number of octets equal to the maximum size of an A-MSDU that is supported by the STA. 22 For buffer size, the recipient of data advertises a single scalar number that is the number of fragment buffers of the maximum MSDU or A-MSDU size (indicated by the A-MSDU Supported field) available for the block ack agreement that is being negotiated. Every buffered MPDU that is associated with this block ack agreement consumes one of these buffers regardless of whether the frame contains a whole MSDU (or a fragment thereof) or an A-MSDU. For example, ten maximum-size unfragmented MSDUs consumes the same amount of buffer space at the recipient as ten smaller fragments of a single MSDU of maximum size. 738 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications In an ADDBA Request frame, the Buffer Size subfield provides guidance for the frame receiver to decide its reordering buffer size. If the Buffer Size subfield is equal to 0, it implies that the originator of the block ack has no information to specify its value. In an ADDBA Response frame, when the Status Code field is equal to SUCCESS, the Buffer Size subfield is set to a value of at least 1. 9.4.1.15 Block Ack Timeout Value field The Block Ack Timeout Value field is used in the ADDBA Request and Response frames to indicate the timeout value for Block Ack. The length of the Block Ack Timeout Value field is 2 octets. The Block Ack Timeout Value field is illustrated in Figure 9-80. Block Ack Timeout Value Octets: 2 Figure 9-80â€”Block Ack Timeout Value fixed field The Block Ack Timeout Value field contains the duration, in TUs, after which the block ack setup is terminated, if there are no frame exchanges (see 11.5.4) within this duration using this block ack agreement. A value of 0 disables the timeout. 9.4.1.16 DELBA Parameter Set field The DELBA Parameter Set field is used in a DELBA frame to terminate an already set up Block Ack. The length of the DELBA Parameter Set field is 2 octets. The DELBA Parameter Set field is illustrated in Figure 9-81. B0 B10 B11 B12 B15 Reserved Initiator TID Bits: 11 1 4 Figure 9-81â€”DELBA Parameter Set field The Initiator subfield indicates if the originator or the recipient of the data is sending this frame. It is set to 1 to indicate the originator and is set to 0 to indicate the recipient. The TID subfield indicates the TSID or the UP for which the block ack has been originally set up. 9.4.1.17 QoS Info field The QoS Info field is 1 octet in length and contains capability information bits. The contents of the field are dependent on whether the STA is contained within an AP. The format of the QoS Info field, when sent by the AP, is defined in Figure 9-82. B0 B3 B4 B5 B6 B7 EDCA Parameter Q-Ack Queue Request TXOP Request Reserved Set Update Count Bits: 4 1 1 1 1 Figure 9-82â€”QoS Info field when sent by an AP 739 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The EDCA Parameter Set Update Count subfield is described in 10.2.4.2. APs set the Q-Ack subfield to 1 when dot11QAckOptionImplemented is true and set it to 0 otherwise. APs set the Queue Request subfield to 1 if they can process a nonzero Queue Size subfield in the QoS Control field in QoS Data frames and set it to 0 otherwise. APs set the TXOP Request subfield to 1 if they can process a nonzero TXOP Duration Requested subfield in the QoS Control field in QoS Data frames and set it to 0 otherwise. The format of the QoS Info field, when sent by the non-AP STA, is defined in Figure 9-83. B0 B1 B2 B3 B4 B5 B6 B7 AC_VO AC_VI AC_BK AC_BE Q-Ack Max SP More Data U-APSD U-APSD U-APSD U-APSD Length Ack Flag Flag Flag Flag Bits: 1 1 1 1 1 1 1 Figure 9-83â€”QoS Info field when set by a non-AP STA Each of the ACs U-APSD Flag subfields is 1 bit in length and set to 1 in (Re)Association Request frames to indicate that the corresponding AC (AC_BE, AC_BK, AC_VI, or AC_VO) is both trigger-enabled and delivery-enabled. It is set to 0 in (Re)Association Request frames to indicate that the corresponding AC is neither trigger-enabled nor delivery-enabled. A TSPEC as described in 11.2.3.5 is to be used to make a particular AC exclusively either trigger-enabled or delivery-enabled. These subfields are set to 0 when the APSD subfield in the Capability Information field received from the AP with which the non-AP STA is associating is equal to 0. Non-AP STAs set the Q-Ack subfield to 1 when dot11QAckOptionImplemented is true and set it to 0 otherwise. The Max SP Length subfield is 2 bits in length and indicates the maximum number of buffered BUs the STA is prepared to receive during any SP triggered by the STA. This subfield is reserved when the APSD subfield in the Capability Information field is equal to 0. If the APSD subfield in the Capability Information field is equal to 1, the settings of the values in the Max SP Length subfield are defined in Table 9-48. Table 9-48â€”Settings of the Max SP Length subfield Bit 5 Bit 6 Usage 0 0 The STA is prepared to receive all buffered BUs. 1 0 The STA is prepared to receive a maximum of two BUs per SP. 0 1 The STA is prepared to receive a maximum of four BUs per SP. 1 1 The STA is prepared to receive a maximum of six BUs per SP. Non-AP STAs set the More Data Ack subfield to 1 to indicate that they can process Ack frames with the More Data bit in the Frame Control field equal to 1 and remain in the awake state. Non-AP STAs set the More Data Ack subfield to 0 otherwise. For APs, the More Data Ack subfield is reserved. 740 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.1.18 Measurement Pilot Interval field The Measurement Pilot Interval field represents the number of time units (TUs) between target measurement pilot transmission times (TMPTTs). The length of the Measurement Pilot Interval field is 1 octet. The Mea- surement Pilot Interval field is illustrated in Figure 9-84. B0 B7 Measurement Pilot Interval Octets: 1 Figure 9-84â€”Measurement Pilot Interval fixed field 9.4.1.19 Max Transmit Power field The Max Transmit Power field is a 2s complement signed integer and is 1 octet in length, providing an upper limit, in units of dBm, on the transmit power as measured at the output of the antenna connector to be used by that AP on the current channel. See 11.11.13. The Max Transmit Power field is illustrated in Figure 9-85. B0 B7 Max Transmit Power Octets: 1 Figure 9-85â€”Max Transmit Power field 9.4.1.20 Transmit Power Used field The Transmit Power Used field is a 2s complement signed integer and is 1 octet in length. It is less than or equal to the Max Transmit Power and indicates the actual power used as measured at the output of the antenna connector, in units of dBm, by a STA when transmitting the frame containing the Transmit Power Used field. The Transmit Power Used value is determined any time prior to sending the frame in which it is contained and has a tolerance of Â±5 dB. The Transmit Power Used field is illustrated in Figure 9-86. B0 B7 Transmit Power Used Octets: 1 Figure 9-86â€”Transmit Power Used field 9.4.1.21 Channel Width field The Channel Width field is used in a Notify Channel Width frame (see 9.6.12.2) to indicate the channel width on which the sending STA is able to receive. The length of the field is 1 octet. The Channel Width field is illustrated in Figure 9-87. Channel Width Octets: 1 Figure 9-87â€”Channel Width fixed field 741 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If a STA transmitting or receiving this field is operating in an operating class that includes a value of PrimaryChannelLowerBehavior or PrimaryChannelUpperBehavior in the behavior limits set as specified in Annex E, then the values of the Channel Width field are defined in Table 9-49. If a STA transmitting or receiving this field is operating in an operating class that does not include a value of PrimaryChannelLowerBehavior or PrimaryChannelUpperBehavior in the behavior limits set as specified in Annex E, then this field is reserved. Table 9-49â€”Settings of the Channel Width field Value Meaning 0 20 MHz channel width 1 Any channel width in the STAâ€™s Supported Channel Width Set subfield 2â€“255 Reserved 9.4.1.22 Operating Class and Channel field The Operating Class and Channel field is used in the Location Indication Channels subelement of the Location Parameters element and in the Channel Usage element. The Operating Class and Channel field indicates an operating class and channel. The format of the field is defined in Figure 9-88. Operating Class Channel Octets: 1 1 Figure 9-88â€”Operating Class and Channel field The Operating Class field indicates an operating class value as defined in Annex E. The operating class is interpreted in the context of the country specified in the Beacon frame. The Channel field indicates a channel number, which is interpreted in the context of the indicated operating class. Channel numbers are defined in Annex E. 9.4.1.23 SM Power Control field The SM Power Control field is used in an SM Power Save frame (see 9.6.12.3) by a STA to communicate changes in its SM power-saving state. The field is 1 octet in length and is illustrated in Figure 9-89. B0 B1 B2 B7 SM Power Save Enabled SM Mode Reserved Bits: 1 1 6 Figure 9-89â€”SM Power Control fixed field The SM Power Save Enabled subfield indicates whether SM power saving is enabled at the STA. A value of 1 indicates enabled, and a value of 0 indicates disabled. 742 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The SM Mode subfield indicates the mode of operation. A value of 1 indicates dynamic SM power save mode, a value of 0 indicates static SM power save mode. The modes are described in 11.2.6. 9.4.1.24 PCO Phase Control field The PCO Phase Control field is used in a Set PCO Phase frame (see 9.6.12.5) to indicate the phase of PCO operation (see 11.17). The length of the field is 1 octet. The PCO Phase Control field is illustrated in Figure 9-90. PCO Phase Control Octets: 1 Figure 9-90â€”PCO Phase Control fixed field The PCO Phase Control field indicates the current PCO phase. The values of the PCO Phase Control field are defined in Table 9-50. Table 9-50â€”Settings of the PCO Phase Control field Value Meaning 0 20 MHz phase 1 40 MHz phase 2â€“255 Reserved 9.4.1.25 PSMP Parameter Set field The PSMP Parameter Set field is used in a PSMP frame (see 9.6.12.4) to define the number of PSMP STA Info fields held in the PSMP frame, to indicate whether the PSMP sequence is to be followed by another PSMP sequence, and to indicate the duration of the PSMP sequence. The PSMP Parameter Set field is 2 octets in length. The structure of the PSMP Parameter Set field is defined in Figure 9-91. B0 B4 B5 B6 B15 N_STA More PSMP PSMP Sequence Duration Bits: 5 6 10 Figure 9-91â€”PSMP Parameter Set fixed field The N_STA subfield indicates the number of STA Info fields present in the PSMP frame that contains the PSMP Parameter Set field. The More PSMP subfield, when set to 1, indicates that the current PSMP sequence will be followed by another PSMP sequence. A value of 0 indicates that there will be no PSMP sequence following the current PSMP sequence. 743 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The PSMP Sequence Duration subfield indicates the duration of the current PSMP sequence that is described by the PSMP frame, in units of 8 Âµs, relative to the end of the PSMP frame. Therefore, this field can describe a PSMP sequence with a duration of up to 8.184 ms. The next PSMP sequence within the current PSMP burst starts a SIFS after the indicated duration. 9.4.1.26 PSMP STA Info field The PSMP STA Info field is used by the PSMP frame (see 9.6.12.4). The PSMP STA Info field defines the allocation of time to the downlink (PSMP-DTT) and/or uplink (PSMP-UTT) associated with a single RA. There are two variants of the structure for the individually addressed and group addressed cases. The length of the PSMP STA Info field is 8 octets. The structure of the STA Info field is defined in Figure 9-92 and Figure 9-93. B0 B1 B2 B12 B13 B20 B21 B63 STA_INFO PSMP-DTT PSMP-DTT PSMP Group Type (=1) Start Offset Duration Address ID Bits: 2 11 8 43 Figure 9-92â€”PSMP STA Info fixed field (group addressed) B0 B1 B2 B12 B13 B20 B21 B36 B37 B47 B48 B57 B58 B63 STA_INFO PSMP-DTT PSMP-DTT PSMP-UTT PSMP-UTT Type Start Offset Duration STA_ID Start Offset Duration Reserved (=2) Bits: 2 11 8 16 11 10 6 Figure 9-93â€”PSMP STA Info fixed field (individually addressed) The STA_INFO Type subfield indicates the format of the remainder of the structure. When the STA_INFO Type subfield is equal to 1, the PSMP STA Info field is structured as defined in Figure 9-92 and supports the transmission of group addressed data by the AP. When the STA_INFO Type subfield is equal to 2, the PSMP STA Info field is structured as defined in Figure 9-93 and supports the exchange of data with a single STA. STA_INFO Type subfield values 0 and 3 are reserved. The PSMP-DTT Start Offset subfield indicates the start of the PSMP-DTT for the destination identified by the PSMP STA Info field, relative to the end of the PSMP frame, in units of 4 Âµs. This subfield locates the start of the first PPDU containing downlink data for this destination. The PSMP-DTT Duration subfield indicates the duration of the PSMP-DTT for the destination identified by the PSMP STA Info field, in units of 16 Âµs. This subfield locates the end of the last PPDU containing downlink data for this destination relative to the PDMP-DTT start offset. If no PSMP-DTT is scheduled for a STA, but a PSMP-UTT is scheduled for that STA, the PSMP-DTT Duration subfield is set to 0, and the PSMP-DTT Start Offset subfield is reserved. The PSMP Group Address ID (B21 to B63) subfield contains the 43 least significant bits (LSBs) of a 48 bit MAC address. Use of this subfield is described in 10.29.2.8. B63 contains the LSB of the group address (considering the Individual/Group bit to be the most significant bit (MSB)). The STA_ID subfield contains the AID of the STA to which the PSMP STA Info field is directed. 744 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The PSMP-UTT Start Offset subfield indicates the start of the PSMP-UTT. The offset is specified relative to the end of the PSMP frame. It is specified in units of 4 Âµs. The first PSMP-UTT is scheduled to begin after a SIFS from the end of the last PSMP-DTT described in the PSMP. The PSMP-UTT Duration subfield indicates the maximum length of a PSMP-UTT for a STA. PSMP-UTT duration is specified in units of 4 Âµs. All transmissions by the STA within the current PSMP sequence lie within the indicated PSMP-UTT. If no PSMP-UTT is scheduled for a STA, but a PSMP-DTT is scheduled for that STA, the PSMP-UTT Start Offset and PSMP-UTT Duration subfields are both set to 0. 9.4.1.27 MIMO Control field The MIMO Control field is used to manage the exchange of MIMO channel state or transmit beamforming feedback information. It is used in the CSI (see 9.6.12.6), Noncompressed Beamforming (see 9.6.12.7), and Compressed Beamforming (see 9.6.12.8) frames. The MIMO Control field is 6 octets in length and is defined in Figure 9-94. B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 B10 B11 B13 B14 B15 B16 B47 MIMO Remaining Nc Nr Control Grouping Coefficient Codebook Matrix Reserved Sounding Index Index Channel (Ng) Size Information Timestamp Width Segment Bits: 2 2 1 2 2 2 3 2 32 Figure 9-94â€”MIMO Control field The subfields of the MIMO Control field are defined in Table 9-51. Table 9-51â€”Subfields of the MIMO Control field Subfield Description Nc Index Indicates the number of columns in a matrix minus one: Set to 0 for Nc = 1 Set to 1 for Nc = 2 Set to 2 for Nc = 3 Set to 3 for Nc = 4 Nr Index Indicates the number of rows in a matrix minus one: Set to 0 for Nr = 1 Set to 1 for Nr = 2 Set to 2 for Nr = 3 Set to 3 for Nr = 4 MIMO Control Channel Indicates the width of the channel in which a measurement was made: Width Set to 0 for 20 MHz Set to 1 for 40 MHz Grouping (Ng) Number of carriers grouped into one: Set to 0 for Ng = 1 (No grouping) Set to 1 for Ng = 2 Set to 2 for Ng = 4 The value 3 is reserved 745 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-51â€”Subfields of the MIMO Control field (continued) Subfield Description Coefficient Size Indicates the number of bits in the representation of the real and imaginary parts of each element in the matrix. For CSI feedback: Set to 0 for Nb = 4 Set to 1 for Nb = 5 Set to 2 for Nb = 6 Set to 3 for Nb = 8 For noncompressed beamforming feedback: Set 0 for Nb = 4 Set 1 for Nb = 2 Set 2 for Nb = 6 Set 3 for Nb = 8 Codebook Information Indicates the size of codebook entries: Set to 0 for 1 bit for , 3 bits for Set to 1 for 2 bits for , 4 bits for Set to 2 for 3 bits for , 5 bits for Set to 3 for 4 bits for , 6 bits for Remaining Matrix Segment Contains the remaining segment number for the associated measurement report. Valid range: 0 to 7. Set to 0 for the last segment of a segmented report or the only segment of an unsegmented report. Sounding Timestamp Contains the lower 4 octets of the TSF timer value sampled at the instant that the MAC received the PHY-CCA.indication(IDLE) primitive that corresponds to the end of the reception of the sounding packet that was used to generate feedback information contained in the frame. 9.4.1.28 CSI Report field The CSI Report field is used by the CSI frame (see 9.6.12.6) to carry explicit channel state information to a transmit HT beamformer, as described in 10.32.3. The CSI Matrix subfields in the CSI Report field shown in Table 9-52 and Table 9-53 are matrices whose elements are taken from the CHAN_MAT parameter of RXVECTOR (see Table 19-1). Table 9-52â€”CSI Report field (20 MHz) Size Field Meaning (bits) SNR in receive chain 1 8 Signal-to-noise ratio in the first receive chain of the STA sending the report. ... SNR in receive chain Nr 8 Signal-to-noise ratio in the Nrâ€™th receive chain of the STA sending the report. CSI Matrix for carrier â€“28 3+2Ã— NbÃ—NcÃ—Nr CSI matrix (see Figure 9-95) ... 746 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-52â€”CSI Report field (20 MHz) (continued) Size Field Meaning (bits) CSI Matrix for carrier â€“1 3+2Ã— NbÃ—NcÃ—Nr CSI matrix CSI Matrix for carrier 1 3+2Ã— NbÃ—NcÃ—Nr CSI matrix ... CSI Matrix for carrier 28 3+2Ã— NbÃ—NcÃ—Nr CSI matrix The structure of the field depends on the value of the MIMO Control Channel Width subfield. The CSI Report field for 20 MHz has the structure defined in Table 9-52 where Nb is the number of bits determined by the Coefficients Size field of the MIMO Control field Nc is the number of columns in a CSI matrix determined by the Nc Index field of the MIMO Control field Nr is the number of rows in a CSI matrix determined by the Nr Index field of the MIMO Control field The CSI Report field for 40 MHz has the structure defined in Table 9-53. Table 9-53â€”CSI Report field (40 MHz) Size Field Meaning (bits) SNR in receive chain 1 8 Signal-to-noise ratio in the first receive chain of the STA sending the report. ... SNR in receive chain Nr 8 Signal-to-noise ratio in the Nrâ€™th receive chain of the STA sending the report. CSI Matrix for carrier â€“58 3+2Ã— NbÃ—NcÃ—Nr CSI matrix (see Figure 9-95) ... CSI Matrix for carrier â€“2 3+2Ã— NbÃ—NcÃ—Nr CSI matrix CSI Matrix for carrier 2 3+2Ã— NbÃ—NcÃ—Nr CSI matrix ... CSI Matrix for carrier 58 3+2Ã— NbÃ—NcÃ—Nr CSI matrix The signal-to-noise ratio (SNR) values in Table 9-52 and Table 9-53 are encoded as an 8-bit 2s complement value of 4 Ã— (SNR_average â€“ 22), where SNR_average is the decibel representation of linearly averaged values over the tones represented. This encoding covers the SNR range from â€“10 dB to 53.75 dB in 0.25 dB steps. Grouping is a method that reduces the size of the CSI Report field by reporting a single value for each group of Ng adjacent subcarriers. With grouping, the size of the CSI Report field is Nr 8+Ns (3+2 Nb Nc Nr) bits, where the number of subcarriers sent, Ns, is a function of Ng and whether matrices for 40 MHz or 20 MHz are sent. The value of Ns and the specific carriers for which matrices are sent are shown in Table 9-54. If the size of the CSI Report field is not an integer multiple of 8 bits, up to 7 0s are appended to the end of the report to make its size an integer multiple of 8 bits. 747 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-54â€”Number of matrices and carrier grouping Grouping BW Ns Carriers for which matrices are sent Ng 1 56 All data and pilot carriers: â€“28, â€“27,â€¦â€“2, â€“1, 1, 2,â€¦27, 28 â€“28,â€“26,â€“24,â€“22,â€“20,â€“18,â€“16,â€“14,â€“12,â€“10,â€“8,â€“6,â€“4,â€“2,â€“1, 20 MHz 2 30 1,3,5,7,9,11,13,15,17,19,21,23,25,27,28 4 16 â€“28,â€“24,â€“20,â€“16,â€“12,â€“8,â€“4,â€“1,1,5,9,13,17,21,25,28 1 114 All data and pilot carriers: â€“58, â€“57, â€¦, â€“3, â€“2, 2, 3,â€¦, 57, 58 â€“58,â€“56,â€“54,â€“52,â€“50,â€“48,â€“46,â€“44,â€“42,â€“40,â€“38,â€“36,â€“34,â€“32,â€“30, â€“28,â€“26,â€“24,â€“22,â€“20,â€“18,â€“16,â€“14,â€“12,â€“10,â€“8,â€“6,â€“4,â€“2, 2 58 40 MHz 2,4,6,8,10,12,14,16,18,20,22,24,26,28, 30,32,34,36,38,40,42,44,46,48,50,52,54,56,58 â€“58,â€“54,â€“50,â€“46,â€“42,â€“38,â€“34,â€“30,â€“26,â€“22,â€“18,â€“14,â€“10,â€“6, â€“2, 4 30 2,6,10,14,18,22,26,30,34,38,42,46,50,54,58 The CSI matrix Heff for a single carrier has the structure defined in Figure 9-95. The encoding rules for the elements of the Heff matrix are given in 19.3.12.3.2. For each subcarrier include { Carrier Matrix Amplitude of 3 bits For each of Nr rows in each CSI matrix in order: (1, â€¦, Nr) { Include Nc complex coefficients of CSI matrix Heff in order: (1, â€¦, Nc); each element of Heff includes the real part of the element (Nb bits) and imaginary part of the element (Nb bits) in that order } } Figure 9-95â€”CSI matrix coding When operating with a 40 MHz channel width, CSI feedback with a bandwidth of 20 MHz corresponds to the tones in the primary 20 MHz channel. 9.4.1.29 Noncompressed Beamforming Report field The Noncompressed Beamforming Report field is used by the Noncompressed Beamforming frame to carry explicit feedback in the form of noncompressed beamforming feedback matrices V for use by a transmit HT beamformer to determine steering matrices Q, as described in 10.32.3 and 19.3.12.3. The structure of the field is dependent on the value of the MIMO Control Channel Width subfield. The Noncompressed Beamforming Report field for 20 MHz has the structure defined in Table 9-55 where Nb is the number of bits determined by the Coefficients Size field of the MIMO Control field Nc is the number of columns in a beamforming feedback matrix determined by the Nc Index field of the MIMO Control field Nr is the number of rows in a beamforming feedback matrix determined by the Nr Index field of the MIMO Control field 748 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-55â€”Noncompressed Beamforming Report field (20 MHz) Size Field Meaning (bits) SNR for space-time stream 1 8 Average signal-to-noise ratio in the STA sending the report for space-time stream 1. ... SNR for space-time stream Nc 8 Average signal-to-noise ratio in the STA sending the report for space-time stream Nc. Beamforming Feedback Matrix for carrier â€“28 2Ã— NbÃ—NcÃ—Nr Beamforming feedback matrix V (see Figure 9-96) ... Beamforming Feedback Matrix for carrier â€“1 2Ã— NbÃ—NcÃ—Nr Beamforming feedback matrix V Beamforming Feedback Matrix for carrier 1 2Ã— NbÃ—NcÃ—Nr Beamforming feedback matrix V ... Beamforming Feedback Matrix for carrier 28 2Ã— NbÃ—NcÃ—Nr Beamforming feedback matrix V The Noncompressed Beamforming Report field for 40 MHz has the structure defined in Table 9-56. Table 9-56â€”Noncompressed Beamforming Report field (40 MHz) Size Field Meaning (bits) SNR for space-time stream 1 8 Average signal-to-noise ratio in the STA sending the report for space-time stream 1. ... SNR for space-time stream Nc 8 Average signal-to-noise ratio in the STA sending the report for space-time stream Nc. Beamforming Feedback Matrix for carrier â€“58 2Ã— NbÃ—NcÃ—Nr Beamforming feedback matrix V (see Figure 9-96) ... Beamforming Feedback Matrix for carrier â€“2 2Ã— NbÃ—NcÃ—Nr Beamforming feedback matrix V Beamforming Feedback Matrix for carrier 2 2Ã— NbÃ—NcÃ—Nr Beamforming feedback matrix V ... Beamforming Feedback Matrix for carrier 58 +2Ã— NbÃ—NcÃ—Nr Beamforming feedback matrix V The SNR values in Table 9-55 and Table 9-56 are encoded as an 8-bit 2s complement value of 4 Ã— (SNR_average â€“ 22), where SNR_average is the sum of the values of SNR per tone (in decibels) divided by the number of tones represented. This encoding covers the SNR range from â€“10 dB to 53.75 dB in 0.25 dB steps. The SNR in space-time stream i corresponds to the SNR associated with the column i of the beamforming feedback matrix V. Each SNR corresponds to the predicted SNR at the HT beamformee when the HT beamformer applies the matrix V. 749 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Grouping is a method that reduces the size of the Noncompressed Beamforming Report field by reporting a single value for each group of Ng adjacent subcarriers. With grouping, the size of the Noncompressed Beamforming Report field is Nc +Ns (2 Nb Nc Nr) bits. The number of subcarriers sent, Ns, is a function of Ng and whether matrices for 40 MHz or 20 MHz are sent. The value of Ns and the specific carriers for which matrices are sent is shown in Table 9-54. If the size of the Noncompressed Beamforming Report field is not an integer multiple of 8 bits, up to 7 0s are appended to the end of the report to make its size an integer multiple of 8 bits. A beamforming feedback matrix V for a single carrier has the structure defined in Figure 9-96. For each subcarrier include { For each of Nr rows in the Noncompressed beamforming feedback matrix in order: (1, â€¦, Nr) { Include Nc complex coefficients of the Noncompressed beamforming feedback matrix V in order: (1, â€¦, Nc ); each element of V includes the real part of the element (Nb bits) and imaginary part of the element (Nb bits) in that order } } Figure 9-96â€”V matrix coding (noncompressed beamforming) Encoding rules for elements of the V matrix are given in 19.3.12.3.5. When operating with a 40 MHz channel width, noncompressed feedback with a bandwidth of 20 MHz corresponds to the tones in the primary 20 MHz channel. 9.4.1.30 Compressed Beamforming Report field The Compressed Beamforming Report field is used by the Compressed Beamforming frame (see 9.6.12.8) to carry explicit feedback information in the form of angles representing compressed beamforming feedback matrices V for use by a transmit HT beamformer to determine steering matrices Q, as described in 10.32.3 and 19.3.12.3. The size of the Compressed Beamforming Report field depends on the values in the MIMO Control field. The Compressed Beamforming Report field contains the channel matrix elements indexed, first, by matrix angles in the order shown in Table 9-57 and, second, by data subcarrier index from lowest frequency to highest frequency. The explanation on how these angles are generated from the beamforming feedback matrix V is given in 19.3.12.3.6. Table 9-57â€”Order of angles in the Compressed Beamforming Report field Size of V Number of angles The order of angles in the Quantized Beamforming Feedback (Nr Ã— Nc) (Na) Matrices Information field 2Ã—1 2 11, 21 2Ã—2 2 11, 21 3Ã—1 4 11, 21, 21, 31 750 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-57â€”Order of angles in the Compressed Beamforming Report field (continued) Size of V Number of angles The order of angles in the Quantized Beamforming Feedback (Nr Ã— Nc) (Na) Matrices Information field 3Ã—2 6 11, 21, 21, 31, 22, 32 3Ã—3 6 11, 21, 21, 31, 22, 32 4Ã—1 6 11, 21, 31, 21, 31, 41 4Ã—2 10 11, 21, 31, 21, 31, 41, 22, 32, 32, 42 4Ã—3 12 11, 21, 31, 21, 31, 41, 22, 32, 32, 42, 33, 43 4Ã—4 12 11, 21, 31, 21, 31, 41, 22, 32, 32, 42, 33, 43 The angles are quantized as defined in Table 9-58. All angles are transmitted LSB to MSB. Table 9-58â€”Quantization of angles Quantized Quantized k - + -------------- radians k - + ------- = ------------- = ------------ b +1 b +2 b â€“1 b radians 2 2 2 2 where where b b k = 0 1 2 â€“1 k = 0 1 2 â€“1 b is the number of bits used to quantize b is the number of bits used to quantize (defined by the Codebook Information field of (defined by the Codebook Information field of the MIMO Control field; see 9.4.1.27); the MIMO Control field; see 9.4.1.27) The Compressed Beamforming Report field for 20 MHz has the structure defined in Table 9-59, where Na is the number of angles used for beamforming feedback matrix V (see Table 9-57). Table 9-59â€”Compressed Beamforming Report field (20 MHz) Size Field Meaning (bits) SNR in space-time stream 1 8 Average signal-to-noise ratio in the STA sending the report for space-time stream 1 ... SNR in space-time stream Nc 8 Average signal-to-noise ratio in the STA sending the report for space-time stream Nc Beamforming Feedback Matrix V for carrier â€“28 NaÃ—(b +b )/2 Beamforming feedback matrix V ... Beamforming Feedback Matrix V for carrier â€“1 NaÃ—(b +b )/2 Beamforming feedback matrix V 751 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-59â€”Compressed Beamforming Report field (20 MHz) (continued) Size Field Meaning (bits) Beamforming Feedback Matrix V for carrier 1 NaÃ—(b +b )/2 Beamforming feedback matrix V ... Beamforming Feedback Matrix V for carrier 28 NaÃ—(b +b )/2 Beamforming feedback matrix V The Compressed Beamforming Report field for 40 MHz has the structure defined in Table 9-60, where Na is the number of angles used for beamforming feedback matrix V (see Table 9-57). Table 9-60â€”Compressed Beamforming Report field (40 MHz) Size Field Meaning (bit) SNR in space-time stream 1 8 Average signal-to-noise ratio in the STA sending the report for space-time stream 1 ... SNR in space-time stream Nc 8 Average signal-to-noise ratio in the STA sending the report for space-time stream Nc Beamforming Feedback Matrix V for carrier â€“58 NaÃ—(b +b )/2 Beamforming feedback matrix V Beamforming Feedback Matrix V for NaÃ—(b +b )/2 Beamforming feedback matrix V carrier â€“58 + Ng ... Beamforming Feedback Matrix V for carrier â€“2 NaÃ—(b +b )/2 Beamforming feedback matrix V Beamforming Feedback Matrix V for carrier 2 NaÃ—(b +b )/2 Beamforming feedback matrix V Beamforming Feedback Matrix V for NaÃ—(b +b )/2 Beamforming feedback matrix V carrier 2 + Ng ... Beamforming Feedback Matrix V for carrier 58 NaÃ—(b +b )/2 Beamforming feedback matrix V The SNR values in Table 9-59 and Table 9-60 are encoded as an 8-bit 2s complement value of 4 Ã— (SNR_average â€“ 22), where SNR_average is the sum of the values of SNR per tone (in decibels) divided by the number of tones represented. This encoding covers the SNR range from â€“10 dB to 53.75 dB in 0.25 dB steps. Each SNR value per tone in stream i (before being averaged) corresponds to the SNR associated with the column i of the beamforming feedback matrix V determined at the HT beamformee. Each SNR corresponds to the predicted SNR at the HT beamformee when the HT beamformer applies the matrix V. Grouping is a method that reduces the size of the Compressed Beamforming Report field by reporting a single value for each group of Ng adjacent subcarriers. With grouping, the size of the Compressed Beamforming Report field is NcÃ—8+NsÃ—(NaÃ—(b +b )/2) bits, where the number of subcarriers sent, Ns, is a function of Ng and whether matrices for 40 MHz or 20 MHz are sent. The value of Ns and the specific carriers for which matrices are sent is defined in Table 9-54. If the size of the Compressed Beamforming Report field is not an integer multiple of 8 bits, up to 7 0s are appended to the end of the report to make its size an integer multiple of 8 bits. 752 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications See Figure 9-97 and Figure 9-98 for examples of this encoding. Bits b1..b5 b6..b8 b9..b13 b14..b16 â€¦ b441..b445 b446..b448 Data 11(â€“28) 21(â€“28) 11(â€“27) 21(â€“27) â€¦ 11(28) 21(28) Conditions: â€” 2Ã—2V â€” b = 3, b = 5 â€” No grouping â€” 20 MHz width â€” The matrix V is encoded using 8 bits per tone. Figure 9-97â€”First example of Compressed Beamforming Report field encoding Bits b1..b4 b5..b8 â€¦ b27..b28 b29..b30 b31..b34 â€¦ b59..b60 â€¦ b871..b874 â€¦ b899..b900 Data 11(â€“58) 21(â€“58) â€¦ 32(â€“58) 42(â€“58) 11(â€“54) â€¦ 42(â€“54) â€¦ 11(58) â€¦ 42(58) Conditions: â€” 4Ã—2V â€” b = 2, b = 4 â€” 4 tone grouping â€” 40 MHz width â€” The matrix V is encoded using 30 bits per tone. Figure 9-98â€”Second example of Compressed Beamforming Report field encoding When operating with a 40 MHz channel width, compressed feedback with a bandwidth of 20 MHz corresponds to the tones in the primary 20 MHz channel. 9.4.1.31 Antenna Selection Indices field The Antenna Selection Indices field is used within the Antenna Selection Indices Feedback frame to carry ASEL feedback, as described in 10.33. The Antenna Selection Indices field is 1 octet in length and illustrated in Figure 9-99. Antenna Selection Indices Octets: 1 Figure 9-99â€”Antenna Selection Indices fixed field Bits 0 to 7 in the Antenna Selection Indices field correspond to antennas with indices 0 to 7, respectively. A value of 1 in a bit indicates the corresponding antenna is selected, and the value of 0 indicates the corresponding antenna is not selected. 9.4.1.32 Organization Identifier field The Organization Identifier field contains a public unique identifier assigned by the IEEE. The order of the Organization Identifier field is described in 9.2.2. The IEEE has assigned organizationally unique identifiers 753 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications both of 24-bit length (OUI and CID) and longer length. In the latter case specific OUI values are shared over multiple organizations, e.g., using 36-bit length identifiers (OUI-36) (see IEEE Registration Authority [B19], [B20]). The length of the Organization Identifier field (j) is the minimum number of octets required to contain the entire organizationally unique identifier (see Figure 9-100), and the first 3 octets contain the OUI or CID portion of the identifier. Thus, the Organization Identifier field is 3 octets in length if the organizationally unique identifier is an OUI, or 5 octets in length if the organizationally unique identifier is an OUI-36. Organization Identifier Octets: j Figure 9-100â€”Organization Identifier field If the length of the organizationally unique identifier is not an integer number of octets, the least significant bits of the last octet are specified by the organization identified. NOTEâ€”For example, for the organizationally unique identifier 0x0050C24A4, the Organization Identifier field would contain 0x0050C24A4y where y represents the four least significant bits of the fifth octet of the field. The value of y is specified by the organization whose identifier is 0x0050C24A4. 9.4.1.33 Rate Identification field The Rate Identification field is 4 octets in length and contains the rate identification information for a frame that is not the current frame transmitted or received by a STA. This information allows services to exchange frame rate information prior to use of the frames that use the rate specified by the Rate Identification field. The contents of the field is defined in Figure 9-101. Mask MCS Index Rate Octets: 1 1 2 Figure 9-101â€”Identification field format The Mask field specifies which other fields in the Rate Identification field are used by a STA. The format of the Mask field is shown in Figure 9-102. B0 B2 B3 B4 B5 B7 MCS Selector Rate Type Reserved Bits: 3 2 3 Figure 9-102â€”Mask field format The MCS Selector field value 0 indicates that the MCS Index field is reserved. The MCS Selector field value 1 indicates the MCS Index field specifies an index value that is taken from Table 19-27 to Table 19-30 and Table 19-36 to Table 19-38 in 19.5. The MCS Selector field value 2 indicates the MCS Index field spec- ifies an index value that is taken from Table 19-31 to Table 19-35 and Table 19-40 to Table 19-41 in 19.5. The MCS Selector field value 3 indicates that the MCS Index field specifies values that are taken from Table 21-30 to Table 21-37, indicating a VHT-MCS for a 20 MHz channel width. The MCS Selector field value 4 indicates that the MCS Index field specifies values that are taken from Table 21-38 to Table 21-45, indicating a VHT-MCS for a 40 MHz channel width. 754 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications In frames transmitted by a TVHT STA, the MCS Selector field value 4 indicates that the MCS Index field specifies values that are taken from Table 22-26 to Table 22-29, indicating a TVHT MCS for a TVHT_W channel width. The MCS Selector field value 5 indicates that the MCS Index field specifies values that are taken from Table 21-46 to Table 21-53, indicating a VHT-MCS for an 80 MHz channel width. In frames transmitted by a TVHT STA, the MCS Selector field value 5 indicates that the MCS Index field specifies values that are taken from Table 22-30 to Table 22-33, indicating a TVHT MCS for a TVHT_2W or TVHT_W+W channel width. The MCS Selector field value 6 indicates that the MCS Index field specifies values that are taken from Table 21-54 to Table 21-61, indicating a VHT-MCS for a 160 MHz or 80+80 MHz channel width. In frames transmitted by a TVHT STA, the MCS Selector field value 6 indicates that the MCS Index field specifies values that are taken from Table 22-34 to Table 22-37, indicating a TVHT MCS for a TVHT_4W or TVHT_2W+2W channel width. The MCS Selector field value 7 is reserved. The Rate Type field set to 0 indicates the Rate field is reserved. The Rate Type field set to 1 indicates the Rate field specifies a data rate that is in the basic rate set. The Rate Type field set to 2 indicates the Rate field specifies a data rate that is not in the basic rate set. If MCS Selector is 1 or 2, the MCS Index field is a 1 octet unsigned integer that specifies the row index for one of the MCS parameter tables in 19.5. If MCS Selector is 3, 4, 5, or 6, the MCS Index field format is as shown in Figure 9-103. The NSS subfield indicates the number of spatial streams, and the VHT-MCS Index Row subfield indicates a value from the â€œVHT-MCS Indexâ€ column of Table 21-30 to Table 21-61 in 21.5 or from the â€œMCS Indexâ€ column of Table 22-26 to Table 22-37 in 22.5 that corresponds to the channel width and NSS values. B0 B2 B3 B6 B7 VHT-MCS NSS Index Row Reserved Bits 3 4 1 Figure 9-103â€”MCS Index field format when the MCS Selector field is 3, 4, 5, or 6 The Rate field contains a 2-octet unsigned integer that specifies the PHY rate in 0.5 Mb/s units. 9.4.1.34 GAS Query Response Fragment ID field A GAS Query Fragment Response ID field is used by the STA to indicate when a GAS Query Response spans multiple MMPDUs. STAs responding to GAS request use this field to inform the requesting STA of the GAS fragment number of the transmitted frames as well as identifying the last GAS fragment of the Query Response. Requesting STAs use this field to determine if any fragments of the Query Response are missing. The maximum value permitted in the GAS Query Response Fragment ID is 127. The More GAS Fragments field is set to 1 in GAS Query Response fragments of GAS Comeback Response frames that have another GAS fragment of the current query response to follow; otherwise, it is set to 0. The format of GAS Query Response Fragment ID is shown in Figure 9-104. 755 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B0 B6 B7 GAS Query Response Fragment ID More GAS Fragments Bits: 7 1 Figure 9-104â€”GAS Query Response Fragment ID field 9.4.1.35 Venue Info field The Venue Info field is a 2-octet field. It contains Venue Group and Venue Type subfields. The format of Venue Info subfield is shown in Figure 9-105. Venue Group Venue Type Octets: 1 1 Figure 9-105â€”Venue Info field format The Venue Group and Venue Type subfields are both 1-octet values selected from Table 9-61 and Table 9-62, respectively. The entries in Table 9-61 and Table 9-62 are drawn from the International Build- ing Codeâ€™s Use and Occupancy Classifications [B48]. Table 9-61â€”Venue group codes and descriptions Venue group code Venue group description 0 Unspecified 1 Assembly 2 Business 3 Educational 4 Factory and Industrial 5 Institutional 6 Mercantile 7 Residential 8 Storage 9 Utility and Miscellaneous 10 Vehicular 11 Outdoor 12â€“255 Reserved 756 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-62â€”Venue type assignments Venue group code Venue type code Venue description 0 0 Unspecified 0 1â€“255 Reserved 1 0 Unspecified Assembly 1 1 Arena 1 2 Stadium 1 3 Passenger Terminal (e.g., airport, bus, ferry, train station) 1 4 Amphitheater 1 5 Amusement Park 1 6 Place of Worship 1 7 Convention Center 1 8 Library 1 9 Museum 1 10 Restaurant 1 11 Theater 1 12 Bar 1 13 Coffee Shop 1 14 Zoo or Aquarium 1 15 Emergency Coordination Center 1 16â€“255 Reserved 2 0 Unspecified Business 2 1 Doctor or Dentist office 2 2 Bank 2 3 Fire Station 2 4 Police Station 2 6 Post Office 2 7 Professional Office 2 8 Research and Development Facility 2 9 Attorney Office 2 10â€“255 Reserved 3 0 Unspecified Educational 3 1 School, Primary 3 2 School, Secondary 3 3 University or College 3 4â€“255 Reserved 4 0 Unspecified Factory and Industrial 4 1 Factory 4 2â€“255 Reserved 757 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-62â€”Venue type assignments (continued) Venue group code Venue type code Venue description 5 0 Unspecified Institutional 5 1 Hospital 5 2 Long-Term Care Facility (e.g., Nursing home, Hospice, etc.) 5 3 Alcohol and Drug Rehabilitation Center 5 4 Group Home 5 5 Prison or Jail 5 6â€“255 Reserved 6 0 Unspecified Mercantile 6 1 Retail Store 6 2 Grocery Market 6 3 Automotive Service Station 6 4 Shopping Mall 6 5 Gas Station 6 6â€“255 Reserved 7 0 Unspecified Residential 7 1 Private Residence 7 2 Hotel or Motel 7 3 Dormitory 7 4 Boarding House 7 5â€“255 Reserved 8 0 Unspecified Storage 8 1â€“255 Reserved 9 0 Unspecified Utility and Miscellaneous 9 1â€“255 Reserved 10 0 Unspecified Vehicular 10 1 Automobile or Truck 10 2 Airplane 10 3 Bus 10 4 Ferry 10 5 Ship or Boat 10 6 Train 10 7 Motor Bike 10 8â€“255 Reserved 11 0 Unspecified Outdoor 11 1 Muni-mesh Network 11 2 City Park 11 3 Rest Area 758 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-62â€”Venue type assignments (continued) Venue group code Venue type code Venue description 11 4 Traffic Control 11 5 Bus Stop 11 6 Kiosk 11 7â€“255 Reserved 9.4.1.36 Target Channel The Target Channel field specifies the channel number of the target channel. The length of the Target Channel field is 1 octet. The Target Channel field is illustrated in Figure 9-106. Target Channel Octets: 1 Figure 9-106â€”Target Channel field format 9.4.1.37 Operating Class The Operating Class field specifies the operating class for the channel field included in the same frame. The length of the Operating Class field is 1 octet. Operating classes are defined in Annex E. The Operating Class field is illustrated in Figure 9-107. Operating Class Octets: 1 Figure 9-107â€”Operating Class field format 9.4.1.38 Send-Confirm field The Send-Confirm field is used with SAE authentication as an anti-replay counter as specified in 12.4. See Figure 9-108. Send-Confirm Octets: 2 Figure 9-108â€”Send-Confirm field 9.4.1.39 Anti-Clogging Token field The Anti-Clogging Token field is used with SAE authentication for denial-of-service protection as specified in 12.4. See Figure 9-109. Anti-Clogging Token Octets: variable Figure 9-109â€”Anti-Clogging Token field 759 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.1.40 Scalar field The Scalar field is used with SAE authentication to communicate cryptographic material as specified in 12.4. See Figure 9-110. Scalar Octets: variable Figure 9-110â€”Scalar field 9.4.1.41 Finite field element (FFE) field The FFE field is used with SAE authentication to communicate an element in a finite field as specified in 12.4. See Figure 9-111. FFE Octets: variable Figure 9-111â€”FFE field 9.4.1.42 Confirm field The Confirm field is used with SAE authentication to authenticate and prove possession of a cryptographic key as specified in 12.4. See Figure 9-112. Confirm Octets: variable Figure 9-112â€”Confirm field 9.4.1.43 Finite Cyclic Group field The Finite Cyclic Group is used in SAE to indicate which cryptographic group to use in the SAE exchange as specified in 12.4. See Figure 9-113. Finite Cyclic Group Octets: 2 Figure 9-113â€”Finite Cyclic Group field 9.4.1.44 TXOP Reservation field The format of the TXOP Reservation field is shown in Figure 9-114. Duration Service Interval Start Time Octets: 1 1 4 Figure 9-114â€”TXOP Reservation field format 760 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Duration subfield specifies the duration of the TXOP in units of 32 Âµs. The Service Interval subfield contains an 8-bit unsigned integer that specifies the service interval (SI) of the reservation in units of milliseconds. The Start Time subfield is the offset from the next TBTT to the start of the first SP and indicates the anticipated start time, expressed in microseconds, of the first TXOP after the TBTT. 9.4.1.45 Relay Capable STA Info field The format of the Relay Capable STA Info field is defined in Figure 9-115. B0 B7 B8 B23 AID Relay Capabilities Information Bits: 8 16 Figure 9-115â€”Relay Capable STA Info field The AID subfield contains the AID of the relay capable STA that is associated with the AP or PCP. The Relay Capability Information subfield is defined in 9.4.2.148. 9.4.1.46 Band ID field The Band ID field is 1 octet in length and is defined in Table 9-63. Table 9-63â€”Band ID field Band ID value Meaning 0 TV white spaces 1 Sub-1 GHz (excluding TV white spaces) 2 2.4 GHz 3 3.6 GHz 4 4.9 and 5 GHz 5 60 GHz 6â€“255 Reserved 9.4.1.47 DMG Parameters field The format of the DMG Parameters field is shown in Figure 9-116. 761 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B0 B1 B2 B3 B4 B5 B6 B7 ECAPC Policy BSS Type CBAP Only CBAP Source DMG Privacy Enforced Reserved Bits: 2 1 1 1 1 2 Figure 9-116â€”DMG Parameters If the BSS Type field is transmitted as part of a DMG Beacon frame that has the Discovery Mode field within the Beacon Interval Control field (see Figure 9-61) equal to 0, then the BSS Type subfield is defined in Table 9-64 for specific types of frame cited below. An AP sets the BSS Type subfield to 3 within transmitted DMG Beacon, Probe Response, or (Re)Association Response frames. A PCP sets the BSS Type subfield to 2 within transmitted DMG Beacon, Probe Response, or (Re)Association Response frames. An IBSS STA or a STA that is not a member of a BSS sets the BSS Type subfield to 1 within transmitted DMG Beacon or Probe Response frames. The BSS Type subfield is reserved for all other types of frame. Table 9-64â€”The BSS Type subfield when the Discovery mode field is 0 Subfield value BSS Type Transmitted by DMG STA 3 Infrastructure BSS AP 2 PBSS PCP 1 IBSS Any non-AP and non-PCP DMG STA 0 Reserved If the BSS Type field is transmitted as part of a DMG Beacon frame that has the Discovery Mode field within the Beacon Interval Control field (see Figure 9-61) equal to 1, the BSS Type subfield is defined in Table 9-65. Depending on the role of the STA that responds to the DMG Beacon frame (identified by the â€œResponding STA roleâ€ column of Table 9-65), the behavior is different and is defined in 10.38.5.2. Table 9-65â€”The BSS Type subfield when the Discovery mode field is 1 Subfield value Responding STA role Applicable BSS types 3 AP Infrastructure BSS 2 PCP PBSS 1 Non-AP STA PBSS, IBSS 0 Any Infrastructure BSS, PBSS, IBSS The CBAP Only, CBAP Source, and ECAPC Policy Enforced subfields are valid only when transmitted within a DMG Beacon, Probe Response, or (Re)Association Response frames and are set as follows: â€” The CBAP Only subfield indicates the type of link access provided by the STA sending the DMG Beacon frame in the data transfer interval (DTI) (see 10.36.2) of the beacon interval. The CBAP Only subfield is set to 1 when the entirety of the DTI portion of the beacon interval is allocated as a CBAP. The CBAP Only subfield is set to 0 when the allocation of the DTI portion of the beacon interval is provided through the Extended Schedule element. 762 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” The CBAP Source subfield is valid only if the CBAP Only subfield is 1. The CBAP Source subfield is set to 1 to indicate that the AP or PCP has higher priority to transmit during the CBAP than non- AP and non-PCP STAs. The CBAP Source subfield is set to 0 otherwise. â€” The ECAPC Policy Enforced subfield is set to 1 to indicate that medium access policies specific to the centralized AP or PCP cluster are required as defined in 10.37.3.4. The ECAPC Policy Enforced subfield is set to 0 to indicate that medium access policies specific to the centralized AP or PCP cluster are not required. The DMG Privacy subfield is set to 1 if dot11RSNAActivated is true. Otherwise, this subfield is set to 0. 9.4.1.48 VHT MIMO Control field The VHT MIMO Control field is included in every VHT Compressed Beamforming frame (see 9.6.23.2). The VHT MIMO Control field is defined in Figure 9-117. B0 B2 B3 B5 B6 B7 B8 B9 B10 B11 B12 B14 B15 B16 B17 B18 B23 Remaining First Sounding Nc Nr Channel Codebook Feedback Dialog Index Index Width Grouping Information Type Feedback Feedback Reserved Token Segments Segment Number Bits: 3 3 2 2 1 1 3 1 2 6 Figure 9-117â€”VHT MIMO Control field The subfields of the VHT MIMO Control field are defined in Table 9-66. Table 9-66â€”Subfields of the VHT MIMO Control field Subfield Description Nc Index Indicates the number of columns, Nc, in the compressed beamforming feedback matrix minus 1: Set to 0 for Nc = 1 Set to 1 for Nc = 2 â€¦ Set to 7 for Nc = 8 Nr Index Indicates the number of rows, Nr, in the compressed beamforming feedback matrix minus 1: Set to 0 for Nr = 1 Set to 1 for Nr = 2 â€¦ Set to 7 for Nr = 8 Channel Width Indicates the width of the channel in which the measurement to create the compressed beamforming feedback matrix was made: Set to 0 for 20 MHz Set to 1 for 40 MHz Set to 2 for 80 MHz Set to 3 for 160 MHz or 80+80 MHz Grouping Indicates the subcarrier grouping, Ng, used for the compressed beamforming feedback matrix: Set to 0 for Ng = 1 (No grouping) Set to 1 for Ng = 2 Set to 2 for Ng = 4 The value 3 is reserved 763 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-66â€”Subfields of the VHT MIMO Control field (continued) Subfield Description Codebook Indicates the size of codebook entries: Information If Feedback Type is SU: Set to 0 for 2 bits for Ïˆ, 4 bits for Set to 1 for 4 bits for Ïˆ, 6 bits for If Feedback Type is MU: Set to 0 for 5 bits for Ïˆ, 7 bits for Set to 1 for 7 bits for Ïˆ, 9 bits for Feedback Type Indicates the feedback type: Set to 0 for SU Set to 1 for MU Remaining Indicates the number of remaining feedback segments for the associated VHT Compressed Feedback Segments Beamforming frame: Set to 0 for the last feedback segment of a segmented report or the only feedback segment of an unsegmented report. Set to a value between 1 and 6 for a feedback segment that is neither the first nor the last of a segmented report. Set to a value between 1 and 7 for a feedback segment that is not the last feedback segment of a segmented report. In a retransmitted feedback segment, the field is set to the same value associated with the feedback segment in the original transmission. First Feedback Set to 1 for the first feedback segment of a segmented report or the only feedback segment Segment of an unsegmented report; set to 0 if it is not the first feedback segment or if the VHT Compressed Beamforming Report field and MU Exclusive Beamforming Report field are not present in the frame. In a retransmitted feedback segment, the field is set to the same value associated with the feedback segment in the original transmission. Sounding Dialog The sounding dialog token from the VHT NDP Announcement frame soliciting feedback Token Number In a VHT Compressed Beamforming frame not carrying all or part of a VHT Compressed Beamforming report (see 10.34.5 for a description of such a case), the Nc Index, Nr Index, Channel Width, Grouping, Codebook Information, Feedback Type and Sounding Dialog Token Number subfields are reserved, the First Feedback Segment subfield is set to 0 and the Remaining Feedback Segments subfield is set to 7. 9.4.1.49 VHT Compressed Beamforming Report field The VHT Compressed Beamforming Report field is used by the VHT Compressed Beamforming feedback (see 9.6.23.2) to carry explicit feedback information in the form of angles representing compressed beamforming feedback matrices V for use by a transmit beamformer to determine steering matrices Q, as described in 10.32.3 and 19.3.12.3. The size of the VHT Compressed Beamforming Report field depends on the values in the VHT MIMO Control field. The VHT Compressed Beamforming Report field contains VHT Compressed Beamforming Report information or successive (possibly zero-length) portions thereof in the case of segmented VHT Compressed Beamforming feedback (see 10.34.5). VHT Compressed Beamforming Report information is always included in the VHT Compressed Beamforming feedback. The VHT Compressed Beamforming Report information contains the channel matrix elements indexed, first, by matrix angles in the order shown in Table 9-67 and, second, by data subcarrier index from lowest frequency to highest frequency. The explanation on how these angles are generated from the beamforming feedback matrix V is given in 19.3.12.3.6. In Table 9-67, 764 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Nc is the number of columns in a compressed beamforming feedback matrix determined by the Nc Index field of the VHT MIMO Control field, Nr is the number of rows in a compressed beamforming feedback matrix determined by the Nr Index field of the VHT MIMO Control field. Table 9-67â€”Order of angles in the Compressed Beamforming Feedback Matrix subfield Size of V Number of The order of angles in the Compressed Beamforming Feedback Matrix (Nr Ã— Nc) angles (Na) subfield 2Ã—1 2 11, Ïˆ21 2Ã—2 2 11, Ïˆ21 3Ã—1 4 11, 21, Ïˆ21, Ïˆ31 3Ã—2 6 11, 21, Ïˆ21, Ïˆ31, 22, Ïˆ32 3Ã—3 6 11, 21, Ïˆ21, Ïˆ31, 22, Ïˆ32 4Ã—1 6 11, 21, 31, Ïˆ21, Ïˆ31, Ïˆ41 4Ã—2 10 11, 21, 31, Ïˆ21, Ïˆ31, Ïˆ41, 22, 32, Ïˆ32, Ïˆ42 4Ã—3 12 11, 21, 31, Ïˆ21, Ïˆ31, Ïˆ41, 22, 32, Ïˆ32, Ïˆ42, 33, Ïˆ43 4Ã—4 12 11, 21, 31, Ïˆ21, Ïˆ31, Ïˆ41, 22, 32, Ïˆ32, Ïˆ42, 33, Ïˆ43 5Ã—1 8 11, 21, 31, 41, Ïˆ21, Ïˆ31, Ïˆ41, Ïˆ51 5Ã—2 14 11, 21, 31, 41, Ïˆ21, Ïˆ31, Ïˆ41, Ïˆ51, 22, 32, 42, Ïˆ32, Ïˆ42, Ïˆ52 5Ã—3 18 11, 21, 31, 41, Ïˆ21, Ïˆ31, Ïˆ41, Ïˆ51, 22, 32, 42, Ïˆ32, Ïˆ42, Ïˆ52, 33, 43, Ïˆ43, Ïˆ53 5Ã—4 20 11, 21, 31, 41, Ïˆ21, Ïˆ31, Ïˆ41, Ïˆ51, 22, 32, 42, Ïˆ32, Ïˆ42, Ïˆ52, 33, 43, Ïˆ43, Ïˆ53, 44, Ïˆ54 5Ã—5 20 11, 21, 31, 41, Ïˆ21, Ïˆ31, Ïˆ41, Ïˆ51, 22, 32, 42, Ïˆ32, Ïˆ42, Ïˆ52, 33, 43, Ïˆ43, Ïˆ53, 44, Ïˆ54 6Ã—1 10 11, 21, 31, 41, 51, Ïˆ21, Ïˆ31, Ïˆ41, Ïˆ51, Ïˆ61 6Ã—2 18 11, 21, 31, 41, 51, Ïˆ21, Ïˆ31, Ïˆ41, Ïˆ51, Ïˆ61, 22, 32, 42, 52, Ïˆ32, Ïˆ42, Ïˆ52, Ïˆ62 6Ã—3 24 11, 21, 31, 41, 51, Ïˆ21, Ïˆ31, Ïˆ41, Ïˆ51, Ïˆ61, 22, 32, 42, 52, Ïˆ32, Ïˆ42, Ïˆ52, Ïˆ62, 33, 43, 53, Ïˆ43, Ïˆ53, Ïˆ63 6Ã—4 28 11, 21, 31, 41, 51, Ïˆ21, Ïˆ31, Ïˆ41, Ïˆ51, Ïˆ61, 22, 32, 42, 52, Ïˆ32, Ïˆ42, Ïˆ52, Ïˆ62, 33, 43, 53, Ïˆ43, Ïˆ53, Ïˆ63, 44, 54, Ïˆ54, Ïˆ64 6Ã—5 30 11, 21, 31, 41, 51, Ïˆ21, Ïˆ31, Ïˆ41, Ïˆ51, Ïˆ61, 22, 32, 42, 52, Ïˆ32, Ïˆ42, Ïˆ52, Ïˆ62, 33, 43, 53, Ïˆ43, Ïˆ53, Ïˆ63, 44, 54, Ïˆ54, Ïˆ64, 55, Ïˆ65 6Ã—6 30 11, 21, 31, 41, 51, Ïˆ21, Ïˆ31, Ïˆ41, Ïˆ51, Ïˆ61, 22, 32, 42, 52, Ïˆ32, Ïˆ42, Ïˆ52, Ïˆ62, 33, 43, 53, Ïˆ43, Ïˆ53, Ïˆ63, 44, 54, Ïˆ54, Ïˆ64, 55, Ïˆ65 7Ã—1 12 11, 21, 31, 41, 51, 61, Ïˆ21, Ïˆ31, Ïˆ41, Ïˆ51, Ïˆ61, Ïˆ71 7Ã—2 22 11, 21, 31, 41, 51, 61, Ïˆ21, Ïˆ31, Ïˆ41, Ïˆ51, Ïˆ61, Ïˆ71, 22, 32, 42, 52, 62, Ïˆ32, Ïˆ42, Ïˆ52, Ïˆ62, Ïˆ72 7Ã—3 30 11, 21, 31, 41, 51, 61, Ïˆ21, Ïˆ31, Ïˆ41, Ïˆ51, Ïˆ61, Ïˆ71, 22, 32, 42, 52, 62, Ïˆ32, Ïˆ42, Ïˆ52, Ïˆ62, Ïˆ72, 33, 43, 53, 63, Ïˆ43, Ïˆ53, Ïˆ63, Ïˆ73 765 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-67â€”Order of angles in the Compressed Beamforming Feedback Matrix subfield Size of V Number of The order of angles in the Compressed Beamforming Feedback Matrix (Nr Ã— Nc) angles (Na) subfield 7Ã—4 36 11, 21, 31, 41, 51, 61, Ïˆ21, Ïˆ31, Ïˆ41, Ïˆ51, Ïˆ61, Ïˆ71, 22, 32, 42, 52, 62, Ïˆ32, Ïˆ42, Ïˆ52, Ïˆ62, Ïˆ72, 33, 43, 53, 63, Ïˆ43, Ïˆ53, Ïˆ63, Ïˆ73, 44, 54, 64, Ïˆ54, Ïˆ64, Ïˆ74 7Ã—5 40 11, 21, 31, 41, 51, 61, Ïˆ21, Ïˆ31, Ïˆ41, Ïˆ51, Ïˆ61, Ïˆ71, 22, 32, 42, 52, 62, Ïˆ32, Ïˆ42, Ïˆ52, Ïˆ62, Ïˆ72, 33, 43, 53, 63, Ïˆ43, Ïˆ53, Ïˆ63, Ïˆ73, 44, 54, 64, Ïˆ54, Ïˆ64, Ïˆ74, 55, 65, Ïˆ65, Ïˆ75 7Ã—6 42 11, 21, 31, 41, 51, 61, Ïˆ21, Ïˆ31, Ïˆ41, Ïˆ51, Ïˆ61, Ïˆ71, 22, 32, 42, 52, 62, Ïˆ32, Ïˆ42, Ïˆ52, Ïˆ62, Ïˆ72, 33, 43, 53, 63, Ïˆ43, Ïˆ53, Ïˆ63, Ïˆ73, 44, 54, 64, Ïˆ54, Ïˆ64, Ïˆ74, 55, 65, Ïˆ65, Ïˆ75, 66, Ïˆ76 7Ã—7 42 11, 21, 31, 41, 51, 61, Ïˆ21, Ïˆ31, Ïˆ41, Ïˆ51, Ïˆ61, Ïˆ71, 22, 32, 42, 52, 62, Ïˆ32, Ïˆ42, Ïˆ52, Ïˆ62, Ïˆ72, 33, 43, 53, 63, Ïˆ43, Ïˆ53, Ïˆ63, Ïˆ73, 44, 54, 64, Ïˆ54, Ïˆ64, Ïˆ74, 55, 65, Ïˆ65, Ïˆ75, 66, Ïˆ76 8Ã—1 14 11, 21, 31, 41, 51, 61, 71, Ïˆ21, Ïˆ31, Ïˆ41, Ïˆ51, Ïˆ61, Ïˆ71, Ïˆ81 8Ã—2 26 11, 21, 31, 41, 51, 61, 71, Ïˆ21, Ïˆ31, Ïˆ41, Ïˆ51, Ïˆ61, Ïˆ71, Ïˆ81, 22, 32, 42, 52, 62, 72, Ïˆ32, Ïˆ42, Ïˆ52, Ïˆ62, Ïˆ72, Ïˆ82 8Ã—3 36 11, 21, 31, 41, 51, 61, 71, Ïˆ21, Ïˆ31, Ïˆ41, Ïˆ51, Ïˆ61, Ïˆ71, Ïˆ81, 22, 32, 42, 52, 62, 72, Ïˆ32, Ïˆ42, Ïˆ52, Ïˆ62, Ïˆ72, Ïˆ82, 33, 43, 53, Ï†63, 73, Ïˆ43, Ïˆ53, Ïˆ63, Ïˆ73, Ïˆ83 8Ã—4 44 11, 21, 31, 41, 51, 61, 71, Ïˆ21, Ïˆ31, Ïˆ41, Ïˆ51, Ïˆ61, Ïˆ71, Ïˆ81, 22, 32, 42, 52, 62, 72, Ïˆ32, Ïˆ42, Ïˆ52, Ïˆ62, Ïˆ72, Ïˆ82, 33, 43, 53, 63, 73, Ïˆ43, Ïˆ53, Ïˆ63, Ïˆ73, Ïˆ83, 44, 54, 64, 74, Ïˆ54, Ïˆ64, Ïˆ74, Ïˆ84 8Ã—5 50 11, 21, 31, 41, 51, 61, 71, Ïˆ21, Ïˆ31, Ïˆ41, Ïˆ51, Ïˆ61, Ïˆ71, Ïˆ81, 22, 32, 42, 52, 62, 72, Ïˆ32, Ïˆ42, Ïˆ52, Ïˆ62, Ïˆ72, Ïˆ82, 33, 43, 53, 63, 73, Ïˆ43, Ïˆ53, Ïˆ63, Ïˆ73, Ïˆ83, 44, 54, 64, 74, Ïˆ54, Ïˆ64, Ïˆ74, Ïˆ84, 55, 65, 75, Ïˆ65, Ïˆ75, Ïˆ85 8Ã—6 54 11, 21, 31, 41, 51, 61, 71, Ïˆ21, Ïˆ31, Ïˆ41, Ïˆ51, Ïˆ61, Ïˆ71, Ïˆ81, 22, 32, 42, 52, 62, 72, Ïˆ32, Ïˆ42, Ïˆ52, Ïˆ62, Ïˆ72, Ïˆ82, 33, 43, 53, 63, 73, Ïˆ43, Ïˆ53, Ïˆ63, Ïˆ73, Ïˆ83, 44, 54, 64, 74, Ïˆ54, Ïˆ64, Ïˆ74, Ïˆ84, 55, 65, 75, Ïˆ65, Ïˆ75, Ïˆ85, 66, 76, Ïˆ76, Ïˆ86 8Ã—7 56 11, 21, 31, 41, 51, 61, 71, Ïˆ21, Ïˆ31, Ïˆ41, Ïˆ51, Ïˆ61, Ïˆ71, Ïˆ81, 22, 32, 42, 52, 62, 72, Ïˆ32, Ïˆ42, Ïˆ52, Ïˆ62, Ïˆ72, Ïˆ82, 33, 43, 53, 63, 73, Ïˆ43, Ïˆ53, Ïˆ63, Ïˆ73, Ïˆ83, 44, 54, 64, 74, Ïˆ54, Ïˆ64, Ïˆ74, Ïˆ84, 55, 65, 75, Ïˆ65, Ïˆ75, Ïˆ85, 66, 76, Ïˆ76, Ïˆ86, 77, Ïˆ87 8Ã—8 56 11, 21, 31, 41, 51, 61, 71, Ïˆ21, Ïˆ31, Ïˆ41, Ïˆ51, Ïˆ61, Ïˆ71, Ïˆ81, 22, 32, 42, 52, 62, 72, Ïˆ32, Ïˆ42, Ïˆ52, Ïˆ62, Ïˆ72, Ïˆ82, 33, 43, 53, 63, 73, Ïˆ43, Ïˆ53, Ïˆ63, Ïˆ73, Ïˆ83, 44, 54, 64, 74, Ïˆ54, Ïˆ64, Ïˆ74, Ïˆ84, 55, 65, 75, Ïˆ65, Ïˆ75, Ïˆ85, 66, 76, Ïˆ76, Ïˆ86, 77, Ïˆ87 The beamforming feedback matrix V is formed by the beamformee as follows. The beamformer transmits an NDP with NSTS,NDP space-time streams, where NSTS,NDP takes a value between 2 and 8. Based on this NDP, the beamformee estimates the N RX BFEE N STS NDP channel, and based on that channel it determines a NrÃ—Nc orthonormal matrix V, where Nr and Nc satisfy Equation (9-1). Nr = N STS NDP Nc min(N STS NDP N RX BFEE) (9-1) Further restrictions on Nc are described in 10.34.5. 766 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The angles are quantized as defined in Table 9-68. Table 9-68â€”Quantization of angles Quantized Quantized k k = -------------- + -------------- radians = ------------- + ------- radians b +1 b +2 b â€“1 b 2 2 2 2 where where b b k = 0 1 2 â€“1 k = 0 1 2 â€“1 b is the number of bits used to quantize b is the number of bits used to quantize (defined by the Codebook Information (defined by the Codebook Information field of the VHT MIMO Control field field of the VHT MIMO Control field (see 9.4.1.48) (see 9.4.1.48) The VHT Compressed Beamforming Report information has the structure and order defined in Table 9-69, where Na is the number of angles used for the compressed beamforming feedback matrix subfield (see Table 9-67). Table 9-69â€”VHT Compressed Beamforming Report information Size Field Meaning (bits) Average SNR of Space-Time Stream 1 8 Signal-to-noise ratio at the beamformee for space-time stream 1 averaged over all data subcarriers. See Table 9-71. ... â€¦ â€¦ Average SNR of Space-Time Stream Nc 8 Signal-to-noise ratio at the beamformee for space-time stream Nc averaged over all data subcarriers. See Table 9-71. Compressed Beamforming Feedback Matrix V for NaÃ—(b +b )/2 Compressed beamforming feedback subcarrier k = scidx(0) matrix as defined in Table 9-67 Compressed Beamforming Feedback Matrix V for NaÃ—(b +b )/2 Compressed beamforming feedback subcarrier k = scidx(1) matrix as defined in Table 9-67 Compressed Beamforming Feedback Matrix V for NaÃ—(b +b )/2 Compressed beamforming feedback subcarrier k = scidx(2) matrix as defined in Table 9-67 ... â€¦ â€¦ Compressed Beamforming Feedback Matrix V for NaÃ—( b +b )/2 Compressed beamforming feedback subcarrier k = scidx(Ns â€“ 1) matrix as defined in Table 9-67 NOTEâ€”scidx() is defined in Table 9-70. 767 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Ns is the number of subcarriers for which the Compressed Beamforming Feedback Matrix subfield is sent back to the beamformer. A beamformee might choose to reduce Ns by using a method referred to as grouping, in which only a single Compressed Beamforming Feedback Matrix is reported for each group of Ng adjacent subcarriers. Ns is a function of the Channel Width and Grouping subfields in the VHT MIMO Control field (see 9.4.1.48). Table 9-70 lists Ns, the exact subcarrier indices and their order for which the Compressed Beamforming Feedback Matrix subfield is sent back. No padding is present between angles in the VHT Compressed Beamforming Report information, even if they correspond to different subcarriers. If the size of the VHT Compressed Beamforming Report information is not an integer multiple of 8 bits, up to seven zeros are appended to the end of the field to make its size an integer multiple of 8 bits. Table 9-70â€”Subcarriers for which a Compressed Beamforming Feedback Matrix subfield is sent back Channel Subcarriers for which Compressed Feedback Beamforming Matrix subfield Ng Ns Width is sent: scidx(0), scidx(1), â€¦, scidx(Ns-1) â€“28, â€“27, â€“26, â€“25, â€“24, â€“23, â€“22, â€“20, â€“19, â€“18, â€“17, â€“16, â€“15, â€“14, â€“13, â€“12, â€“11, â€“10, â€“9, â€“8, â€“6, â€“5, â€“4, â€“3, â€“2, â€“1, 1, 2, 3, 4, 5, 6, 8, 9, 10, 11, 12, 13, 14, 15, 1 52 16, 17, 18, 19, 20, 22, 23, 24, 25, 26, 27, 28 NOTEâ€”Pilot subcarriers (Â±21, Â±7) and DC subcarrier (0) are skipped 20 MHz â€“28, â€“26, â€“24, â€“22, â€“20, â€“18, â€“16, â€“14, â€“12, â€“10, â€“8, â€“6, â€“4, â€“2, â€“1, 1, 2, 4, 6, 8, 2 30 10, 12, 14, 16, 18, 20, 22, 24, 26, 28 4 16 â€“28, â€“24, â€“20, â€“16, â€“12, â€“8, â€“4, â€“1, 1, 4, 8, 12, 16, 20, 24, 28 â€“58, â€“57, â€“56, â€“55, â€“54, â€“52, â€“51, â€“50, â€“49, â€“48, â€“47, â€“46, â€“45, â€“44, â€“43, â€“42, â€“41, â€“40, â€“39, â€“38, â€“37, â€“36, â€“35, â€“34, â€“33, â€“32, â€“31, â€“30, â€“29, â€“28, â€“27, â€“26, â€“24, â€“23, â€“22, â€“21, â€“20, â€“19, â€“18, â€“17, â€“16, â€“15, â€“14, â€“13, â€“12, â€“10, â€“9, â€“8, â€“7, 1 108 â€“6, â€“5, â€“4, â€“3, â€“2, 2, 3, 4, 5, 6, 7, 8, 9, 10, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 54, 55, 56, 57, 58 40 MHz NOTEâ€”Pilot subcarriers (Â±53, Â±25, Â±11) and DC subcarriers (0, Â±1) are skipped. â€“58, â€“56, â€“54, â€“52, â€“50, â€“48, â€“46, â€“44, â€“42, â€“40, â€“38, â€“36, â€“34, â€“32, â€“30, â€“28, 2 58 â€“26, â€“24, -22, â€“20, â€“18, â€“16, â€“14, â€“12, â€“10, â€“8, â€“6, â€“4,â€“2, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48, 50, 52, 54, 56, 58 â€“58, â€“54, â€“50, â€“46, â€“42, â€“38, â€“34, â€“30, â€“26, â€“22, â€“18, â€“14, â€“10, â€“6,â€“2, 2, 6, 10, 4 30 14, 18, 22, 26, 30, 34, 38, 42, 46, 50, 54, 58 â€“122, â€“121, â€“120, â€“119, â€“118, â€“117, â€“116, â€“115, â€“114, â€“113, â€“112, â€“111, â€“110, â€“109, â€“108, â€“107, â€“106, â€“105, â€“104, â€“102, â€“101, â€“100, â€“99, â€“98, â€“97, â€“96, â€“95, â€“94, â€“93, â€“92, â€“91, â€“90, â€“89, â€“88, â€“87, â€“86, â€“85, â€“84, â€“83, â€“82, â€“81, â€“80, â€“79, â€“78, â€“77, â€“76, â€“74, â€“73, â€“72, â€“71, â€“70, â€“69, â€“68, â€“67, â€“66, â€“65, â€“64, â€“63, â€“62, â€“61, â€“60, â€“59, â€“58, â€“57, â€“56, â€“55, â€“54, â€“53, â€“52, â€“51, â€“50, â€“49, â€“48, â€“47, â€“46, â€“45, â€“44, â€“43, â€“42, â€“41, â€“40, â€“38, â€“37, â€“36, â€“35, â€“34, â€“33, â€“32, â€“31, â€“30, â€“29, â€“28, â€“27, â€“26, â€“25, â€“24, â€“23, â€“22, â€“21, â€“20, â€“19, â€“18, â€“17, â€“16, â€“15, â€“14, â€“13, â€“12, â€“10, â€“9, â€“8, â€“7, â€“6, â€“5, â€“4, â€“3, â€“2, 2, 3, 4, 5, 6, 7, 8, 9, 10, 12, 13, 14, 15, 16, 80 MHz 1 234 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122 NOTEâ€”Pilot subcarriers (Â±103, Â±75, Â±39, Â±11) and DC subcarriers (0, Â±1) are skipped. 768 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-70â€”Subcarriers for which a Compressed Beamforming Feedback Matrix subfield is sent back (continued) Channel Subcarriers for which Compressed Feedback Beamforming Matrix subfield Ng Ns Width is sent: scidx(0), scidx(1), â€¦, scidx(Ns-1) â€“122, â€“120, â€“118, â€“116, â€“114, â€“112, â€“110, â€“108, â€“106, â€“104, â€“102, â€“100, â€“98, â€“96, â€“94, â€“92, â€“90, â€“88, â€“86, â€“84, â€“82, â€“80, â€“78, â€“76, â€“74, â€“72, â€“70, â€“68, â€“66, â€“64, â€“62, â€“60, â€“58, â€“56, â€“54, â€“52, â€“50, â€“48, â€“46, â€“44, â€“42, â€“40, â€“38, â€“36, â€“34, 2 122 â€“32, â€“30, â€“28, â€“26, â€“24, â€“22, â€“20, â€“18, â€“16, â€“14, â€“12, â€“10, â€“8, â€“6, â€“4, â€“2, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48, 50, 80 MHz 52, 54, 56, 58, 60, 62, 64, 66, 68, 70, 72, 74, 76, 78, 80, 82, 84, 86, 88, 90, 92, 94, 96, 98, 100, 102, 104, 106, 108, 110, 112, 114, 116, 118, 120, 122 â€“122, â€“118, â€“114, â€“110, â€“106, â€“102, â€“98, â€“94, â€“90, â€“86, â€“82, â€“78, â€“74, â€“70, â€“66, â€“62, â€“58, â€“54, â€“50, â€“46, â€“42, â€“38, â€“34, â€“30, â€“26, â€“22, â€“18, â€“14, â€“10, â€“6, â€“2, 2, 6, 4 62 10, 14, 18, 22, 26, 30, 34, 38, 42, 46, 50, 54, 58, 62, 66, 70, 74, 78, 82, 86, 90, 94, 98, 102, 106, 110, 114, 118, 122 â€“250, â€“249, â€“248, â€“247, â€“246, â€“245, â€“244, â€“243, â€“242, â€“241, â€“240, â€“239, â€“238, â€“237, â€“236, â€“235, â€“234, â€“233, â€“232, â€“230, â€“229, â€“228, â€“227, â€“226, â€“225, â€“224, â€“223, â€“222, â€“221, â€“220, â€“219, â€“218, â€“217, â€“216, â€“215, â€“214, â€“213, â€“212, â€“211, â€“210, â€“209, â€“208, â€“207, â€“206, â€“205, â€“204, â€“202, â€“201, â€“200, â€“199, â€“198, â€“197, â€“196, â€“195, â€“194, â€“193, â€“192, â€“191, â€“190, â€“189, â€“188, â€“187, â€“186, â€“185, â€“184, â€“183, â€“182, â€“181, â€“180, â€“179, â€“178, â€“177, â€“176, â€“175, â€“174, â€“173, â€“172, â€“171, â€“170, â€“169, â€“168, â€“166, â€“165, â€“164, â€“163, â€“162, â€“161, â€“160, â€“159, â€“158, â€“157, â€“156, â€“155, â€“154, â€“153, â€“152, â€“151, â€“150, â€“149, â€“148, â€“147, â€“146, â€“145, â€“144, â€“143, â€“142, â€“141, â€“140, â€“138, â€“137, â€“136, â€“135, â€“134, â€“133, â€“132, â€“131, â€“130, â€“126, â€“125, â€“124, â€“123, â€“122, â€“121, â€“120, â€“119, â€“118, â€“116, â€“115, â€“114, â€“113, â€“112, â€“111, â€“110, â€“109, â€“108, â€“107, â€“106, â€“105, â€“104, -103, â€“102, â€“101, â€“100, â€“99, â€“98, â€“97, â€“96, â€“95, â€“94, â€“93, â€“92, â€“91, â€“90, â€“88, â€“87, â€“86, â€“85, â€“84, â€“83, â€“82, â€“81, â€“80, â€“79, â€“78, â€“77, â€“76, â€“75, â€“74, â€“73, â€“72, â€“71, â€“70, â€“69, â€“68, â€“67, â€“66, â€“65, â€“64, â€“63, â€“62, â€“61, â€“60, â€“59, â€“58, â€“57, â€“56, â€“55, â€“54, â€“52, â€“51, â€“50, â€“49, â€“48, â€“47, â€“46, â€“45, â€“44, â€“43, â€“42, â€“41, â€“40, â€“39, â€“38, â€“37, â€“36, â€“35, â€“34, â€“33, â€“32, â€“31, â€“30, â€“29, â€“28, â€“27, â€“26, â€“24, â€“23, â€“22, â€“21, â€“20, â€“19, â€“18, â€“17, 160 MHz 1 468 â€“16, â€“15, â€“14, â€“13, â€“12, â€“11, â€“10, â€“9, â€“8, â€“7, â€“6, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 118, 119, 120, 121, 122, 123, 124, 125, 126, 130, 131, 132, 133, 134, 135, 136, 137, 138, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226, 227, 228, 229, 230, 232, 233, 234, 235, 236, 237, 238, 239, 240, 241, 242, 243, 244, 245, 246, 247, 248, 249, 250 NOTEâ€”Pilot subcarriers (Â±231, Â±203, Â±167, Â±139, Â±117, Â±89, Â±53, Â±25), DC subcarriers (0, Â±1, Â±2, Â±3, Â±4, Â±5) and subcarriers Â±127, Â±128, Â±129 are skipped. 769 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-70â€”Subcarriers for which a Compressed Beamforming Feedback Matrix subfield is sent back (continued) Channel Subcarriers for which Compressed Feedback Beamforming Matrix subfield Ng Ns Width is sent: scidx(0), scidx(1), â€¦, scidx(Ns-1) â€“250, â€“248, â€“246, â€“244, â€“242, â€“240, â€“238, â€“236, â€“234, â€“232, â€“230, â€“228, â€“226, â€“224, â€“222, â€“220, â€“218, â€“216, â€“214, â€“212, â€“210, â€“208, â€“206, â€“204, â€“202, â€“200, â€“198, â€“196, â€“194, â€“192, â€“190, â€“188, â€“186, â€“184, â€“182, â€“180, â€“178, â€“176, â€“174, â€“172, â€“170, â€“168, â€“166, â€“164, â€“162, â€“160, â€“158, â€“156, â€“154, â€“152, â€“150, â€“148, â€“146, â€“144, â€“142, â€“140, â€“138, â€“136, â€“134, â€“132, â€“130, â€“126, â€“124, â€“122, â€“120, â€“118, â€“116, â€“114, â€“112, â€“110, -108, â€“106, â€“104, â€“102, â€“100, â€“98, â€“96, â€“94, â€“92, â€“90, â€“88, â€“86, â€“84, â€“82, â€“80, â€“78, â€“76, â€“74, â€“72, â€“70, â€“68, â€“66, â€“64, â€“62, â€“60, â€“58, â€“56, â€“54, â€“52, â€“50, â€“48, â€“46, â€“44, â€“42, â€“40, â€“38, â€“36, â€“34, â€“32, â€“30, â€“28, 2 244 â€“26, â€“24, â€“22, â€“20, â€“18, â€“16, â€“14, â€“12, â€“10, â€“8, â€“6, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62, 64, 66, 68, 70, 72, 74, 76, 78, 80, 82, 84, 86, 88, 90, 92, 94, 96, 98, 100, 102, 104, 106, 108, 110, 112, 114, 116, 118, 120, 122, 124, 126, 130, 132, 134, 136, 138, 140, 142, 144, 146, 148, 150, 152, 154, 156, 158, 160, 162, 164, 166, 168, 170, 172, 174, 176, 178, 180, 182, 184, 186, 188, 190, 192, 194, 196, 198, 200, 202, 160 MHz 204, 206, 208, 210, 212, 214, 216, 218, 220, 222, 224, 226, 228, 230, 232, 234, 236, 238, 240, 242, 244, 246, 248, 250 NOTEâ€”DC subcarriers 0, Â±2, Â±4 and Â±128 are skipped. â€“250, â€“246, â€“242, â€“238, â€“234, â€“230, â€“226, â€“222, â€“218, â€“214, â€“210, â€“206, â€“202, â€“198, â€“194, â€“190, â€“186, â€“182, â€“178, â€“174, â€“170, â€“166, â€“162, â€“158, â€“154, â€“150, â€“146, â€“142, â€“138, â€“134, â€“130, â€“126, â€“122, â€“118, â€“114, â€“110, â€“106, â€“102, â€“98, â€“94, â€“90, â€“86, â€“82, â€“78, â€“74, â€“70, â€“66, â€“62, â€“58, â€“54, â€“50, â€“46, â€“42, â€“38, â€“34, 4 124 â€“30, â€“26, â€“22, â€“18, â€“14, â€“10, â€“6, 6, 10, 14, 18, 22, 26, 30, 34, 38, 42, 46, 50, 54, 58, 62, 66, 70, 74, 78, 82, 86, 90, 94, 98, 102, 106, 110, 114, 118, 122, 126, 130, 134, 138, 142, 146, 150, 154, 158, 162, 166, 170, 174, 178, 182, 186, 190, 194, 198, 202, 206, 210, 214, 218, 222, 226, 230, 234, 238, 242, 246, 250 NOTEâ€”DC subcarriers Â±2 are skipped. 770 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-70â€”Subcarriers for which a Compressed Beamforming Feedback Matrix subfield is sent back (continued) Channel Subcarriers for which Compressed Feedback Beamforming Matrix subfield Ng Ns Width is sent: scidx(0), scidx(1), â€¦, scidx(Ns-1) â€“122(L), â€“121(L), â€“120(L), â€“119(L), â€“118(L), â€“117(L), â€“116(L), â€“115(L), â€“114(L), â€“113(L), â€“112(L), â€“111(L), â€“110(L), â€“109(L), â€“108(L), â€“107(L), â€“106(L), â€“105(L), -104(L), â€“102(L), â€“101(L), â€“100(L), â€“99(L), â€“98(L), â€“97(L), â€“96(L), â€“95(L), â€“94(L), â€“93(L), â€“92(L), â€“91(L), â€“90(L), â€“89(L), â€“88(L), â€“87(L), â€“86(L), â€“85(L), â€“84(L), â€“83(L), â€“82(L), â€“81(L), â€“80(L), â€“79(L), â€“78(L), â€“77(L), â€“76(L), â€“74(L), â€“73(L), â€“72(L), â€“71(L), â€“70(L), â€“69(L), â€“68(L), â€“67(L), â€“66(L), â€“65(L), â€“64(L), â€“63(L), â€“62(L), â€“61(L), â€“60(L), â€“59(L), â€“58(L), â€“57(L), â€“56(L), â€“55(L), â€“54(L), â€“53(L), â€“52(L), â€“51(L), â€“50(L), â€“49(L), â€“48(L), â€“47(L), â€“46(L), â€“45(L), â€“44(L), â€“43(L), â€“42(L), â€“41(L), â€“40(L), â€“38(L), â€“37(L), â€“36(L), â€“35(L), â€“34(L), â€“33(L), â€“32(L), â€“31(L), â€“30(L), â€“29(L), â€“28(L), â€“27(L), â€“26(L), â€“25(L), â€“24(L), â€“23(L), â€“22(L), â€“21(L), â€“20(L), â€“19(L), â€“18(L), â€“17(L), â€“16(L), â€“15(L), â€“14(L), â€“13(L), â€“12(L), â€“10(L), â€“9(L), â€“8(L), â€“7(L), â€“6(L), â€“5(L), â€“4(L), â€“3(L), â€“2(L), 2(L), 3(L), 4(L), 5(L), 6(L), 7(L), 8(L), 9(L), 10(L), 12(L), 13(L), 14(L), 15(L), 16(L), 17(L), 18(L), 19(L), 20(L), 21(L), 22(L), 23(L), 24(L), 25(L), 26(L), 27(L), 28(L), 29(L), 30(L), 31(L), 32(L), 33(L), 34(L), 35(L), 36(L), 37(L), 38(L), 40(L), 41(L), 42(L), 43(L), 44(L), 45(L), 46(L), 47(L), 48(L), 49(L), 50(L), 51(L), 52(L), 53(L), 54(L), 55(L), 56(L), 57(L), 58(L), 59(L), 60(L), 61(L), 62(L), 63(L), 64(L), 65(L), 66(L), 67(L), 68(L), 69(L), 70(L), 71(L), 72(L), 73(L), 74(L), 76(L), 77(L), 78(L), 79(L), 80(L), 81(L), 82(L), 83(L), 84(L), 85(L), 86(L), 87(L), 88(L), 89(L), 90(L), 91(L), 92(L), 93(L), 94(L), 95(L), 96(L), 97(L), 98(L), 99(L), 100(L), 101(L), 102(L), 104(L), 105(L), 106(L), 107(L), 108(L), 109(L), 110(L), 111(L), 112(L), 113(L), 114(L), 115(L), 116(L), 117(L), 118(L), 119(L), 120(L), 121(L), 122(L), â€“122(H), â€“121(H), â€“120(H), â€“119(H), â€“118(H), â€“117(H), â€“116(H), â€“115(H), â€“114(H), â€“113(H), â€“112(H), â€“111(H), â€“110(H), â€“109(H), â€“108(H), â€“107(H), â€“106(H), â€“105(H), â€“104(H), -102(H), -101(H), â€“100(H), â€“99(H), â€“98(H), â€“97(H), â€“96(H), â€“95(H), 80+80 â€“94(H), â€“93(H), â€“92(H), â€“91(H), â€“90(H), â€“89(H), â€“88(H), â€“87(H), â€“86(H), 1 468 MHz â€“85(H), â€“84(H), â€“83(H), -82(H), â€“81(H), â€“80(H), â€“79(H), â€“78(H), â€“77(H), â€“76(H), â€“74(H), â€“73(H), â€“72(H), â€“71(H), â€“70(H), â€“69(H), â€“68(H), â€“67(H), â€“66(H), â€“65(H), â€“64(H), â€“63(H), â€“62(H), â€“61(H), â€“60(H), â€“59(H), â€“58(H), â€“57(H), â€“56(H), â€“55(H), â€“54(H), â€“53(H), â€“52(H), â€“51(H), â€“50(H), â€“49(H), â€“48(H), â€“47(H), â€“46(H), â€“45(H), â€“44(H), â€“43(H), â€“42(H), â€“41(H), â€“40(H), â€“38(H), â€“37(H), â€“36(H), â€“35(H), â€“34(H), â€“33(H), â€“32(H), â€“31(H), â€“30(H), â€“29(H), â€“28(H), â€“27(H), â€“26(H), â€“25(H), â€“24(H), â€“23(H), â€“22(H), â€“21(H), â€“20(H), â€“19(H), â€“18(H), â€“17(H), â€“16(H), â€“15(H), â€“14(H), â€“13(H), â€“12(H), â€“10(H), â€“9(H), â€“8(H), â€“7(H), â€“6(H), â€“5(H), â€“4(H), â€“3(H), â€“2(H), 2(H), 3(H), 4(H), 5(H), 6(H), 7(H), 8(H), 9(H), 10(H), 12(H), 13(H), 14(H), 15(H), 16(H), 17(H), 18(H), 19(H), 20(H), 21(H), 22(H), 23(H), 24(H), 25(H), 26(H), 27(H), 28(H), 29(H), 30(H), 31(H), 32(H), 33(H), 34(H), 35(H), 36(H), 37(H), 38(H), 40(H), 41(H), 42(H), 43(H), 44(H), 45(H), 46(H), 47(H), 48(H), 49(H), 50(H), 51(H), 52(H), 53(H), 54(H), 55(H), 56(H), 57(H), 58(H), 59(H), 60(H), 61(H), 62(H), 63(H), 64(H), 65(H), 66(H), 67(H), 68(H), 69(H), 70(H), 71(H), 72(H), 73(H), 74(H), 76(H), 77(H), 78(H), 79(H), 80(H), 81(H), 82(H), 83(H), 84(H), 85(H), 86(H), 87(H), 88(H), 89(H), 90(H), 91(H), 92(H), 93(H), 94(H), 95(H), 96(H), 97(H), 98(H), 99(H), 100(H), 101(H), 102(H), 104(H), 105(H), 106(H), 107(H), 108(H), 109(H), 110(H), 111(H), 112(H), 113(H), 114(H), 115(H), 116(H), 117(H), 118(H), 119(H), 120(H), 121(H), 122(H) NOTE 1â€”Subcarrier x(L) denotes subcarrier index x in the frequency segment lower in frequency, and subcarrier x(H) denotes subcarrier index x in the frequency segment higher in frequency. NOTE 2â€”Pilot subcarriers (Â±103, Â±75, Â±39, Â±11) and DC subcarriers (0, Â±1) are skipped in each frequency segment. 771 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-70â€”Subcarriers for which a Compressed Beamforming Feedback Matrix subfield is sent back (continued) Channel Subcarriers for which Compressed Feedback Beamforming Matrix subfield Ng Ns Width is sent: scidx(0), scidx(1), â€¦, scidx(Ns-1) â€“122(L), â€“120(L), â€“118(L), â€“116(L), â€“114(L), â€“112(L), â€“110(L), â€“108(L), â€“106(L), -104(L), â€“102(L), â€“100(L), â€“98(L), â€“96(L), â€“94(L), â€“92(L), â€“90(L), â€“88(L), â€“86(L), â€“84(L), â€“82(L), â€“80(L), â€“78(L), â€“76(L), â€“74(L), â€“72(L), â€“70(L), â€“68(L), â€“66(L), â€“64(L), â€“62(L), â€“60(L), â€“58(L), â€“56(L), â€“54(L), â€“52(L), â€“50(L), â€“48(L), â€“46(L), â€“44(L), â€“42(L), â€“40(L), â€“38(L), â€“36(L), â€“34(L), â€“32(L), â€“30(L), â€“28(L), â€“26(L), â€“24(L), â€“22(L), â€“20(L), â€“18(L), â€“16(L), â€“14(L), â€“12(L), â€“10(L), â€“8(L), â€“6(L), â€“4(L), â€“2(L), 2(L), 4(L), 6(L), 8(L), 10(L), 12(L), 14(L), 16(L), 18(L), 20(L), 22(L), 24(L), 26(L), 28(L), 30(L), 32(L), 34(L), 36(L), 38(L), 40(L), 42(L), 44(L), 46(L), 48(L), 50(L), 52(L), 54(L), 56(L), 58(L), 60(L), 62(L), 64(L), 66(L), 68(L), 70(L), 72(L), 74(L), 76(L), 78(L), 80(L), 82(L), 84(L), 86(L), 88(L), 90(L), 92(L), 94(L), 96(L), 98(L), 100(L), 102(L), 104(L), 106(L), 108(L), 110(L), 112(L), 114(L), 116(L), 118(L), 120(L), 122(L), 2 244 â€“122(H), â€“120(H), â€“118(H), â€“116(H), â€“114(H), â€“112(H), â€“110(H), â€“108(H), â€“106(H), â€“104(H), â€“102(H), â€“100(H), â€“98(H), â€“96(H), â€“94(H), â€“92(H), â€“90(H), â€“88(H), â€“86(H), â€“84(H), â€“82(H), â€“80(H), â€“78(H), â€“76(H), â€“74(H), â€“72(H), â€“70(H), â€“68(H), â€“66(H), â€“64(H), â€“62(H), â€“60(H), â€“58(H), â€“56(H), â€“54(H), â€“52(H), â€“50(H), â€“48(H), â€“46(H), â€“44(H), â€“42(H), â€“40(H), â€“38(H), â€“36(H), â€“34(H), â€“32(H), â€“30(H), â€“28(H), â€“26(H), â€“24(H), â€“22(H), â€“20(H), â€“18(H), 80+80 â€“16(H), â€“14(H), â€“12(H), â€“10(H), â€“8(H), â€“6(H), -4(H), â€“2(H), 2(H), 4(H), 6(H), MHz 8(H), 10(H), 12(H), 14(H), 16(H), 18(H), 20(H), 22(H), 24(H), 26(H), 28(H), 30(H), 32(H), 34(H), 36(H), 38(H), 40(H), 42(H), 44(H), 46(H), 48(H), 50(H), 52(H), 54(H), 56(H), 58(H), 60(H), 62(H), 64(H), 66(H), 68(H), 70(H), 72(H), 74(H), 76(H), 78(H), 80(H), 82(H), 84(H), 86(H), 88(H), 90(H), 92(H), 94(H), 96(H), 98(H), 100(H), 102(H), 104(H), 106(H), 108(H), 110(H), 112(H), 114(H), 116(H), 118(H), 120(H), 122(H) â€“122(L), â€“118(L), â€“114(L), â€“110(L), â€“106(L), â€“102(L), â€“98(L), â€“94(L), â€“90(L), â€“86(L), â€“82(L), â€“78(L), â€“74(L), â€“70(L), â€“66(L), â€“62(L), â€“58(L), â€“54(L), â€“50(L), â€“46(L), â€“42(L), â€“38(L), â€“34(L), â€“30(L), â€“26(L), â€“22(L), â€“18(L), â€“14(L), â€“10(L), â€“6(L), â€“2(L), 2(L), 6(L), 10(L), 14(L), 18(L), 22(L), 26(L), 30(L), 34(L), 38(L), 42(L), 46(L), 50(L), 54(L), 58(L), 62(L), 66(L), 70(L), 74(L), 78(L), 82(L), 86(L), 90(L), 94(L), 98(L), 102(L), 106(L), 110(L), 114(L), 118(L), 122(L), 4 124 â€“122(H), â€“118(H), â€“114(H), â€“110(H), â€“106(H), â€“102(H), â€“98(H), â€“94(H), â€“90(H), -86(H), â€“82(H), â€“78(H), â€“74(H), â€“70(H), â€“66(H), â€“62(H), â€“58(H), â€“54(H), â€“50(H), â€“46(H), â€“42(H), â€“38(H), â€“34(H), â€“30(H), â€“26(H), â€“22(H), â€“18(H), â€“14(H), â€“10(H), â€“6(H), â€“2(H), 2(H), 6(H), 10(H), 14(H), 18(H), 22(H), 26(H), 30(H), 34(H), 38(H), 42(H), 46(H), 50(H), 54(H), 58(H), 62(H), 66(H), 70(H), 74(H), 78(H), 82(H), 86(H), 90(H), 94(H), 98(H), 102(H), 106(H), 110(H), 114(H), 118(H), 122(H) 772 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Average SNR of Space-Time Stream i subfield in the Table 9-69 is an 8-bit 2s complement integer whose definition is shown in Table 9-71. Table 9-71â€”Average SNR of Space-Time Stream i subfield Average SNR of Space-Time Stream i subfield AvgSNRi â€“128 10 dB â€“127 â€“9.75 dB â€“126 â€“9.5 dB â€¦ â€¦ +126 53.5 dB +127 53.75 dB The AvgSNRi in Table 9-71 is found by computing the SNR per subcarrier in decibels for the subcarriers identified in Table 9-70, and then computing the arithmetic mean of those values. Each SNR value per tone in stream i (before being averaged) corresponds to the SNR associated with the column i of the beamforming feedback matrix V determined at the beamformee. Each SNR corresponds to the predicted SNR at the beamformee when the beamformer applies all columns of the matrix V. A STA with a 40 MHz, 80 MHz, or 160 MHz operating channel width and sending feedback for a 20 MHz channel width includes only subcarriers corresponding to the primary 20 MHz channel in the Compressed Feedback Beamforming Matrix subfield. A STA with an 80 MHz or 160 MHz operating channel width and sending feedback for a 40 MHz channel width includes only subcarriers corresponding to the primary 40 MHz channel in the Compressed Feedback Beamforming Matrix subfield. A STA with a 160 MHz or 80+80 MHz operating channel width and sending feedback for an 80 MHz channel width includes only subcarriers corresponding to the primary 80 MHz channel in the Compressed Feedback Beamforming Matrix subfield. NOTEâ€”Multi-bit fields are transmitted LSB first according to the bit-ordering specification detailed in 9.2.2. 9.4.1.50 TVHT Compressed Beamforming Report field The format of the TVHT Compressed Beamforming Report field is the same as the VHT Compressed Beamforming Report field in 9.4.1.49 except for the following modifications. The subcarriers for which Compressed Feedback Beamforming Matrix subfield is sent in Table 9-70 for 40 MHz are used for each basic channel unit (BCU) in TVHT_MODE_1 and TVHT_MODE_2N. See tone location description in Table 22-9. For TVHT_MODE_2C with 6 MHz and 8 MHz channelization, the subcarriers for which Compressed Feedback Beamforming Matrix subfield is sent in the Lower BCU are based on subtracting 72 from the values shown in Table 9-70 and for the Upper BCU by adding 72. 773 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications For TVHT_MODE_2C with 7 MHz channelization, the subcarriers for which Compressed Feedback Beamforming Matrix subfield is sent in the Lower BCU are based on subtracting 84 from the values shown in Table 9-70 and for the Upper BCU by adding 84. For TVHT_MODE_4C with 6 MHz and 8 MHz channelization, the subcarriers for which Compressed Feedback Beamforming Matrix subfield is sent in the lowest, second to lowest, second to highest, and highest BCUs are based on subtracting 216, subtracting 72, adding 72, and adding 216 from the values shown in Table 9-70, respectively. For TVHT_MODE_4C with 7 MHz channelization, the subcarriers for which Compressed Feedback Beam- forming Matrix subfield is sent in the lowest, second to lowest, second to highest, and highest BCUs are based on subtracting 252, subtracting 84, adding 84, and adding 252 from the values shown in Table 9-70, respectively. For TVHT_MODE_4N channelization, the subcarriers for which Compressed Feedback Beamforming Matrix subfield is sent in each of the two noncontiguous frequency segments are as described for TVHT_MODE_2C. A STA with a TVHT_2W, TVHT_4W, TVHT_W+W, or TVHT_2W+2W operating channel width and sending feedback for a TVHT_W channel width includes a representation of the compressed beamforming feedback matrices of the subcarriers corresponding to the primary TVHT_W channel in the Compressed Feedback Beamforming Matrix subfield. A STA with a TVHT_4W or TVHT_2W+2W operating channel width and sending feedback for a TVHT_2W channel width includes a representation of the compressed beamforming feedback matrices of the subcarriers corresponding to the primary TVHT_2W channel in the Compressed Feedback Beamforming Matrix subfield. 9.4.1.51 MU Exclusive Beamforming Report field The MU Exclusive Beamforming Report field is used by the VHT Compressed Beamforming feedback (see 9.6.23.2) to carry explicit feedback information in the form of delta SNRs. The information in the VHT Compressed Beamforming Report field and the MU Exclusive Beamforming Report field can be used by the transmit MU beamformer to determine steering matrices Q, as described in 10.32.3, 19.3.12.3, and 21.3.11. The size of the MU Exclusive Beamforming Report field depends on the values in the VHT MIMO Control field. The MU Exclusive Beamforming Report field contains MU Exclusive Beamforming Report information or successive (possibly zero-length) portions thereof in the case of segmented VHT Compressed Beamforming feedback (see 10.34.5). The MU Exclusive Beamforming Report information is included in the VHT Compressed Beamforming feedback if the Feedback Type subfield in the VHT MIMO Control field indicates MU (see 9.4.1.48). The MU Exclusive Beamforming Report information consists of Delta SNR subfields for each space-time stream (1 to Nc) of a subset of the subcarriers typically spaced 2Ng apart, where Ng is signaled in the Grouping subfield of the VHT MIMO Control field, starting from the lowest frequency subcarrier and continuing to the highest frequency subcarrier. No padding is present between SNR k i in the MU Exclusive Beamforming Report field, even if they correspond to different subcarriers. The subset of subcarriers included is determined by the values of the Channel Width and Grouping subfields of the VHT MIMO Control field as listed in Table 9-73. For each subcarrier included, the deviation in dB of the SNR of that subcarrier for each column of V relative to the average SNR of the corresponding space-time stream is computed using Equation (9-2). 774 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 2 Hk Vk i SNR k i = min(max(round(10 log 10 ---------------------- â€“ SNR i) â€“ 8) 7) (9-2) N where k is the subcarrier index in the range sscidx(0), â€¦, sscidx(Ns'â€“1) i is the space-time stream index in the range 1, â€¦, Nc Hk is the estimated MIMO channel for subcarrier k Vk i is column i of the beamforming matrix V for subcarrier k N is the average noise plus interference power, measured at the beamformee, that was used to calculate SNR i SNR i is the average SNR of space-time stream i reported in the VHT Compressed Beamforming Report information (Average SNR in Space-Time Stream i field) Each Delta SNR subfield contains the SNR k i computed using Equation (9-2) and quantized to 4 bits in the range â€“8 dB to 7 dB with 1 dB granularity. The structure of the MU Exclusive Beamforming Report field is shown in Table 9-72. Table 9-72â€”MU Exclusive Beamforming Report information Size Field Meaning (Bits) Delta SNR for space-time stream 1 for 4 SNR sscidx as defined in Equation (9-2) 0 1 subcarrier k = sscidx(0) â€¦ â€¦ â€¦ Delta SNR for space-time stream Nc for 4 SNR sscidx as defined in Equation (9-2) 0 Nc subcarrier k = sscidx(0) Delta SNR for space-time stream 1 for 4 SNR sscidx as defined in Equation (9-2) 1 1 subcarrier k = sscidx(1) â€¦ â€¦ â€¦ Delta SNR for space-time stream Nc for 4 SNR sscidx as defined in Equation (9-2) 1 Nc subcarrier k = sscidx(1) â€¦ â€¦ â€¦ Delta SNR for space-time stream 1 for 4 SNR sscidx as defined in Equation (9-2) Ns' â€“ 1 1 subcarrier k = sscidx(Nsâ€™â€“1) â€¦ â€¦ â€¦ Delta SNR for space-time stream Nc for 4 SNR sscidx as defined in Equation (9-2) Ns' â€“ 1 Nc subcarrier k = sscidx(Nsâ€™â€“1) NOTEâ€”sscidx() is defined in Table 9-73. 775 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications In Table 9-72, Ns' is the number of subcarriers for which the Delta SNR subfield is sent back to the beamformer. Table 9-73 shows Ns', the exact subcarrier indices and their order for which the Delta SNR is sent back. Table 9-73â€”Number of subcarriers and subcarrier mapping Channel Subcarriers for which the Delta SNR subfield is sent: sscidx(0), sscidx(1), â€¦ Ng Ns' Width sscidx(Ns'â€“1) â€“28, â€“26, â€“24, â€“22, â€“20, â€“18, â€“16, â€“14, â€“12, â€“10, â€“8, â€“6, â€“4, â€“2, â€“1, 1, 2, 4, 6, 8, 10, 1 30 12, 14, 16, 18, 20, 22, 24, 26, 28 20 MHz 2 16 â€“28, â€“24, â€“20, â€“16, â€“12, â€“8, â€“4, â€“1, 1, 4, 8, 12, 16, 20, 24, 28 4 10 â€“28, â€“20, â€“12, â€“4, â€“1, 1, 4, 12, 20, 28 â€“58, â€“56, â€“54, â€“52, â€“50, â€“48, â€“46, â€“44, â€“42, â€“40, â€“38, â€“36, â€“34, â€“32, â€“30, â€“28, â€“26, 1 58 â€“24, â€“22, â€“20, â€“18, â€“16, â€“14, â€“12, â€“10, â€“8, â€“6, â€“4,â€“2, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48, 50, 52, 54, 56, 58 40 MHz â€“58, â€“54, â€“50, â€“46, â€“42, â€“38, â€“34, â€“30, â€“26, â€“22, â€“18, â€“14, â€“10, â€“6,â€“2, 2, 6, 10, 14, 2 30 18, 22, 26, 30, 34, 38, 42, 46, 50, 54, 58 4 16 â€“58, â€“50, â€“42, â€“34, â€“26, â€“18, â€“10, â€“2, 2, 10, 18, 26, 34, 42, 50, 58 â€“122, â€“120, â€“118, â€“116, â€“114, â€“112, â€“110, â€“108, â€“106, â€“104, â€“102, â€“100, â€“98, â€“96, â€“94, â€“92, â€“90, â€“88, â€“86, â€“84, â€“82, â€“80, â€“78, â€“76, â€“74, â€“72, â€“70, â€“68, â€“66, â€“64, â€“62, â€“60, â€“58, â€“56, â€“54, â€“52, â€“50, â€“48, â€“46, â€“44, â€“42, â€“40, â€“38, â€“36, â€“34, â€“32, â€“30, â€“28, 1 122 â€“26, â€“24, â€“22, â€“20, â€“18, â€“16, â€“14, â€“12, â€“10, â€“8, â€“6, â€“4, â€“2, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62, 64, 66, 68, 70, 72, 74, 76, 78, 80, 82, 84, 86, 88, 90, 92, 94, 96, 98, 100, 102, 104, 106, 108, 110, 112, 114, 116, 118, 120, 122 80 MHz â€“122, â€“118, â€“114, â€“110, â€“106, â€“102, â€“98, â€“94, â€“90, â€“86, â€“82, â€“78, â€“74, â€“70, â€“66, â€“62, â€“58, â€“54, â€“50, â€“46, â€“42, â€“38, â€“34, â€“30, â€“26, â€“22, â€“18, â€“14, â€“10, â€“6, â€“2, 2, 6, 10, 2 62 14, 18, 22, 26, 30, 34, 38, 42, 46, 50, 54, 58, 62, 66, 70, 74, 78, 82, 86, 90, 94, 98, 102, 106, 110, 114, 118, 122 â€“122, â€“114, â€“106, â€“98, â€“90, â€“82, â€“74, â€“66, â€“58, â€“50, â€“42, â€“34, â€“26, â€“18, â€“10, â€“2, 2, 4 32 10, 18, 26, 34, 42, 50, 58, 66, 74, 82, 90, 98, 106, 114, 122 â€“250, â€“248, â€“246, â€“244, â€“242, â€“240, â€“238, â€“236, â€“234, â€“232, â€“230, â€“228, â€“226, â€“224, â€“222, â€“220, â€“218, â€“216, â€“214, â€“212, â€“210, â€“208, â€“206, â€“204, â€“202, â€“200, â€“198, â€“196, â€“194, â€“192, â€“190, â€“188, â€“186, â€“184, â€“182, â€“180, â€“178, â€“176, â€“174, â€“172, â€“170, â€“168, â€“166, â€“164, â€“162, â€“160, â€“158, â€“156, â€“154, â€“152, â€“150, â€“148, â€“146, â€“144, â€“142, â€“140, â€“138, â€“136, â€“134, â€“132, â€“130, â€“126, â€“124, â€“122, â€“120, â€“118, â€“116, â€“114, â€“112, â€“110, â€“108, â€“106, â€“104, â€“102, â€“100, â€“98, â€“96, â€“94, â€“92, â€“90, â€“88, â€“86, â€“84, â€“82, â€“80, â€“78, â€“76, â€“74, â€“72, â€“70, â€“68, â€“66, â€“64, â€“62, â€“60, â€“58, â€“56, â€“54, â€“52, â€“50, â€“48, â€“46, â€“44, â€“42, â€“40, â€“38, â€“36, â€“34, â€“32, â€“30, â€“28, â€“26, â€“24, 160 MHz 1 244 â€“22, â€“20, â€“18, â€“16, â€“14, â€“12, â€“10, â€“8, â€“6, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62, 64, 66, 68, 70, 72, 74, 76, 78, 80, 82, 84, 86, 88, 90, 92, 94, 96, 98, 100, 102, 104, 106, 108, 110, 112, 114, 116, 118, 120, 122, 124, 126, 130, 132, 134, 136, 138, 140, 142, 144, 146, 148, 150, 152, 154, 156, 158, 160, 162, 164, 166, 168, 170, 172, 174, 176, 178, 180, 182, 184, 186, 188, 190, 192, 194, 196, 198, 200, 202, 204, 206, 208, 210, 212, 214, 216, 218, 220, 222, 224, 226, 228, 230, 232, 234, 236, 238, 240, 242, 244, 246, 248, 250 NOTEâ€”Subcarriers 0, Â±2, Â±4 and Â±128 are skipped. 776 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-73â€”Number of subcarriers and subcarrier mapping (continued) Channel Subcarriers for which the Delta SNR subfield is sent: sscidx(0), sscidx(1), â€¦ Ng Ns' Width sscidx(Ns'â€“1) â€“250, â€“246, â€“242, â€“238, â€“234, â€“230, â€“226, â€“222, â€“218, â€“214, â€“210, â€“206, â€“202, â€“198, â€“194, â€“190, â€“186, â€“182, â€“178, â€“174, â€“170, â€“166, â€“162, â€“158, â€“154, â€“150, â€“146, â€“142, â€“138, â€“134, â€“130, â€“126, â€“122, â€“118, â€“114, â€“110, â€“106, â€“102, â€“98, â€“94, â€“90, â€“86, â€“82, â€“78, â€“74, â€“70, â€“66, â€“62, â€“58, â€“54, â€“50, â€“46, â€“42, â€“38, â€“34, â€“30, â€“26, 2 124 â€“22, â€“18, â€“14, â€“10, â€“6, 6, 10, 14, 18, 22, 26, 30, 34, 38, 42, 46, 50, 54, 58, 62, 66, 70, 74, 78, 82, 86, 90, 94, 98, 102, 106, 110, 114, 118, 122, 126, 130, 134, 138, 142, 146, 150, 154, 158, 162, 166, 170, 174, 178, 182, 186, 190, 194, 198, 202, 206, 210, 214, 160 MHz 218, 222, 226, 230, 234, 238, 242, 246, 250 NOTEâ€”Subcarriers Â±2 are skipped. â€“250, â€“242, â€“234, â€“226, â€“218, â€“210, â€“202, â€“194, â€“186, â€“178, â€“170, â€“162, â€“154, â€“146, â€“138, â€“130, â€“126, â€“118, â€“110, â€“102, â€“94, â€“86, â€“78, â€“70, â€“62, â€“54, â€“46, â€“38, 4 64 â€“30, â€“22, â€“14, -6, 6, 14, 22, 30, 38, 46, 54, 62, 70, 78, 86, 94, 102, 110, 118, 126, 130, 138, 146, 154, 162, 170, 178, 186, 194, 202, 210, 218, 226, 234, 242, 250 â€“122(L), â€“120(L), â€“118(L), â€“116(L), â€“114(L), â€“112(L), â€“110(L), â€“108(L), â€“106(L), â€“104(L), â€“102(L), â€“100(L), â€“98(L), â€“96(L), â€“94(L), â€“92(L), â€“90(L), â€“88(L), â€“86(L), â€“84(L), â€“82(L), â€“80(L), â€“78(L), â€“76(L), â€“74(L), â€“72(L), â€“70(L), â€“68(L), â€“66(L), â€“64(L), â€“62(L), â€“60(L), â€“58(L), â€“56(L), â€“54(L), â€“52(L), â€“50(L), â€“48(L), â€“46(L), â€“44(L), â€“42(L), â€“40(L), â€“38(L), â€“36(L), â€“34(L), â€“32(L), â€“30(L), â€“28(L), â€“26(L), â€“24(L), â€“22(L), â€“20(L), â€“18(L), â€“16(L), â€“14(L), â€“12(L), â€“10(L), â€“8(L), â€“6(L), â€“4(L), â€“2(L), 2(L), 4(L), 6(L), 8(L), 10(L), 12(L), 14(L), 16(L), 18(L), 20(L), 22(L), 24(L), 26(L), 28(L), 30(L), 32(L), 34(L), 36(L), 38(L), 40(L), 42(L), 44(L), 46(L), 48(L), 50(L), 52(L), 54(L), 56(L), 58(L), 60(L), 62(L), 64(L), 66(L), 68(L), 70(L), 72(L), 74(L), 76(L), 78(L), 80(L), 82(L), 84(L), 86(L), 88(L), 90(L), 92(L), 94(L), 96(L), 98(L), 100(L), 102(L), 104(L), 106(L), 108(L), 110(L), 112(L), 114(L), 116(L), 1 244 118(L), 120(L), 122(L), â€“122(H), â€“120(H), â€“118(H), â€“116(H), â€“114(H), â€“112(H), â€“110(H), â€“108(H), â€“106(H), â€“104(H), â€“102(H), â€“100(H), â€“98(H), â€“96(H), â€“94(H), â€“92(H), â€“90(H), â€“88(H), â€“86(H), â€“84(H), â€“82(H), â€“80(H), â€“78(H), â€“76(H), â€“74(H), â€“72(H), â€“70(H), â€“68(H), â€“66(H), â€“64(H), â€“62(H), â€“60(H), â€“58(H), â€“56(H), â€“54(H), â€“52(H), â€“50(H), â€“48(H), â€“46(H), â€“44(H), â€“42(H), â€“40(H), â€“38(H), â€“36(H), â€“34(H), â€“32(H), â€“30(H), â€“28(H), â€“26(H), â€“24(H), â€“22(H), â€“20(H), â€“18(H), â€“16(H), â€“14(H), 80+80 â€“12(H), â€“10(H), â€“8(H), â€“6(H), â€“4(H), â€“2(H), 2(H), 4(H), 6(H), 8(H), 10(H), 12(H), MHz 14(H), 16(H), 18(H), 20(H), 22(H), 24(H), 26(H), 28(H), 30(H), 32(H), 34(H), 36(H), 38(H), 40(H), 42(H), 44(H), 46(H), 48(H), 50(H), 52(H), 54(H), 56(H), 58(H), 60(H), 62(H), 64(H), 66(H), 68(H), 70(H), 72(H), 74(H), 76(H), 78(H), 80(H), 82(H), 84(H), 86(H), 88(H), 90(H), 92(H), 94(H), 96(H), 98(H), 100(H), 102(H), 104(H), 106(H), 108(H), 110(H), 112(H), 114(H), 116(H), 118(H), 120(H), 122(H) â€“122(L), â€“118(L), â€“114(L), â€“110(L), â€“106(L), â€“102(L), â€“98(L), â€“94(L), â€“90(L), â€“86(L), â€“82(L), â€“78(L), â€“74(L), â€“70(L), â€“66(L), â€“62(L), â€“58(L), â€“54(L), â€“50(L), â€“46(L), â€“42(L), â€“38(L), â€“34(L), â€“30(L), â€“26(L), â€“22(L), â€“18(L), â€“14(L), â€“10(L), â€“6(L), â€“2(L), 2(L), 6(L), 10(L), 14(L), 18(L), 22(L), 26(L), 30(L), 34(L), 38(L), 42(L), 46(L), 50(L), 54(L), 58(L), 62(L), 66(L), 70(L), 74(L), 78(L), 82(L), 86(L), 90(L), 94(L), 98(L), 102(L), 106(L), 110(L), 114(L), 118(L), 122(L), â€“122(H), 2 124 â€“118(H), â€“114(H), â€“110(H), â€“106(H), â€“102(H), â€“98(H), â€“94(H), â€“90(H), â€“86(H), â€“82(H), â€“78(H), â€“74(H), â€“70(H), â€“66(H), â€“62(H), â€“58(H), â€“54(H), â€“50(H), â€“46(H), â€“42(H), â€“38(H), â€“34(H), â€“30(H), â€“26(H), â€“22(H), â€“18(H), â€“14(H), â€“10(H), â€“6(H), â€“2(H), 2(H), 6(H), 10(H), 14(H), 18(H), 22(H), 26(H), 30(H), 34(H), 38(H), 42(H), 46(H), 50(H), 54(H), 58(H), 62(H), 66(H), 70(H), 74(H), 78(H), 82(H), 86(H), 90(H), 94(H), 98(H), 102(H), 106(H), 110(H), 114(H), 118(H), 122(H) 777 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-73â€”Number of subcarriers and subcarrier mapping (continued) Channel Subcarriers for which the Delta SNR subfield is sent: sscidx(0), sscidx(1), â€¦ Ng Ns' Width sscidx(Ns'â€“1) â€“122(L), â€“114(L), â€“106(L), â€“98(L), â€“90(L), â€“82(L), â€“74(L), â€“66(L), â€“58(L), â€“50(L), -42(L), â€“34(L), â€“26(L), â€“18(L), â€“10(L), â€“2(L), 2(L), 10(L), 18(L), 26(L), 34(L), 42(L), 50(L), 58(L), 66(L), 74(L), 82(L), 90(L), 98(L), 106(L), 114(L), 122(L), â€“ 80+80 4 64 122(H), â€“114(H), â€“106(H), â€“98(H), â€“90(H), â€“82(H), â€“74(H), â€“66(H), â€“58(H), â€“ MHz 50(H), â€“42(H), â€“34(H), â€“26(H), â€“18(H), â€“10(H), â€“2(H), 2(H), 10(H), 18(H), 26(H), 34(H), 42(H), 50(H), 58(H), 66(H), 74(H), 82(H), 90(H), 98(H), 106(H), 114(H), 122(H) NOTE 1â€”sscidx() is defined in Table 9-72. NOTE 2â€”Subcarrier x(L) denotes subcarrier index x in the frequency segment lower in frequency, and subcarrier x(H) denotes subcarrier index x in the frequency segment higher in frequency. 9.4.1.52 TVHT MU Exclusive Beamforming Report field See Table 9.4.1.51 with the following modifications. For each BCU in TVHT_MODE_1 and TVHT_MODE_2N, the subcarriers used in the Delta SNR subfield are defined in Table 9-73 for 40 MHz. See the tone location description in Table 22-9. For TVHT_MODE_2C with 6 MHz and 8 MHz channelization, the subcarriers for which Delta SNR subfield is sent in the Lower BCU are based on subtracting 72 from the values shown in Table 9-73 and for the Upper BCU by adding 72. For TVHT_MODE_2C with 7 MHz channelization, the subcarriers for which Delta SNR subfield is sent in the Lower BCU are based on subtracting 84 from the values shown in Table 9-73 and for the Upper BCU by adding 84. For TVHT_MODE_4C with 6 MHz and 8 MHz channelization, the subcarriers for which Delta SNR subfield is sent in the lowest, second to lowest, second to highest, and highest BCUs are based on subtracting 216, subtracting 72, adding 72, and adding 216 from the values shown in Table 9-73, respectively. For TVHT_MODE_4C with 7 MHz channelization, the subcarriers for which Delta SNR subfield is sent in the lowest, second to lowest, second to highest, and highest BCUs are based on subtracting 252, subtracting 84, adding 84, and adding 252 from the values shown in Table 9-73, respectively. For TVHT_MODE_4N channelization, the subcarriers for which Delta SNR subfield is sent in each of the two noncontiguous frequency segments are as described for TVHT_MODE_2C. 9.4.1.53 Operating Mode field The Operating Mode field is present in the Operating Mode Notification frame (see 9.6.23.4) and Operating Mode Notification element (see 9.4.2.166). 778 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Operating Mode field is shown in Figure 9-118. B0 B1 B2 B3 B4 B6 B7 Channel Width 160/80+80 BW No LDPC Rx NSS Rx NSS Type Bits: 2 1 1 3 1 Figure 9-118â€”Operating Mode field The STA transmitting this field indicates its current operating channel width and the number of spatial streams it can receive using the settings defined in Table 9-74. Table 9-74â€”Subfield values of the Operating Mode field Subfield Description Channel Width If the Rx NSS Type subfield is 0, indicates the supported channel width: In a VHT STA, see Table 9-75 In a TVHT STA: Set to 0 for TVHT_W Set to 1 for TVHT_2W and TVHT_W+W Set to 2 for TVHT_4W and TVHT_2W+2W The value of 3 is reserved. Reserved if the Rx NSS Type subfield is 1. 160/80+80 BW This subfield, combined with the Channel Width subfield, the Supported Channel Width Set subfield and the Supported VHT-MCS and NSS Set subfield indicates whether 80+80 MHz and 160 MHz operation is supported. In a VHT STA, see Table 9-75. In a TVHT STA, this field is reserved. In a STA with dot11VHTExtendedNSSBWCapable either equal to false or not present, this field is set to 0. No LDPC Set to 1 to indicate that the STA transmitting this field prefers not to receive LDPC- encoded PPDUs; set to 0 otherwise. 779 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-74â€”Subfield values of the Operating Mode field (continued) Subfield Description Rx NSS If the Rx NSS Type subfield is 0, the value of this field, combined with other information described in 9.4.2.158.3, indicates the maximum number of spatial streams that the STA can receive. If the Rx NSS Type subfield is 1, the value of this field, indicates the maximum number of spatial streams that the STA can receive as a beamformee in an SU PPDU using a beamforming steering matrix derived from a VHT Compressed Beamforming report with Feedback Type subfield indicating MU in the corresponding VHT Compressed Beamforming frame sent by the STA. Set to 0 for NSS = 1 Set to 1 for NSS = 2 â€¦ Set to 7 for NSS = 8 NOTEâ€”In a STA with dot11VHTExtendedNSSBWCapable equal to true, NSS might be further modified per Table 9-75. Rx NSS Type Set to 0 to indicate that the Rx NSS subfield carries the maximum number of spatial streams that the STA can receive in any PPDU. Set to 1 to indicate that the Rx NSS subfield carries the maximum number of spatial streams that the STA can receive as a beamformee in an SU PPDU using a beamforming steering matrix derived from a VHT Compressed Beamforming report with the Feedback Type subfield indicating MU in the corresponding VHT Compressed Beamforming frame sent by the STA. NOTEâ€”An AP always sets this field to 0. Table 9-75â€”Setting of the Channel Width subfield and 160/80+80 BW subfield at a VHT STA transmitting the Operating Mode field NSS Support of STA transmitting the Location of Transmitted VHT Capabilities of Operating Mode field as a function of Location of secondary Operating Mode STA transmitting the the PPDU bandwidth (Ã—Max VHT NSS) 160 MHz 80 MHz field Operating Mode field (see requirements R1 and R2) center center frequency if frequency if BSS BSS 160/ Supported Extended 80 Channel 20 40 80 160 bandwidth bandwidth 80+80 Channel NSS BW +80 width MHz MHz MHz MHz is 160 MHz is 80+80 BW Width Set Support MHz MHz 0 0 0-2 0-3 1 1 0 0-2 0-3 1 1 2 0 0-2 0-3 1 1 1 2 1 0 1 1 1 1 1/2 CCFS2 780 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-75â€”Setting of the Channel Width subfield and 160/80+80 BW subfield at a VHT STA transmitting the Operating Mode field (continued) NSS Support of STA transmitting the Location of Transmitted VHT Capabilities of Operating Mode field as a function of Location of secondary Operating Mode STA transmitting the the PPDU bandwidth (Ã—Max VHT NSS) 160 MHz 80 MHz field Operating Mode field (see requirements R1 and R2) center center frequency if frequency if BSS BSS 160/ Supported Extended 80 Channel 20 40 80 160 bandwidth bandwidth 80+80 Channel NSS BW +80 width MHz MHz MHz MHz is 160 MHz is 80+80 BW Width Set Support MHz MHz 2 1 0 2 1 1 1 1/2 1/2 CCFS2 CCFS2 2 1 0 3 1 1 1 3/4 3/4 CCFS2 CCFS2 2 1 1 0 1 1 1 1 CCFS1 2 1 1 1 1 1 1 1 1/2 CCFS1 CCFS2 2 1 1 2 1 1 1 1 3/4 CCFS1 CCFS2 2 1 1 3 2 2 2 2 1 CCFS1 CCFS1 2 1 2 0 1 1 1 1 1 CCFS1 CCFS1 2 1 2 3 2 2 2 1 1 CCFS1 CCFS1 R1: NSS support shall be rounded down to the nearest integer. R2: The maximum NSS support shall be 8. NOTE 1â€”Max VHT NSS is defined per MCS in 9.4.2.158.3. NOTE 2â€”1/2Ã— or 3/4Ã— Max VHT NSS support might end up being 0, indicating no support. NOTE 3â€”Any other combination than the ones listed in this table is reserved. NOTE 4â€”CCFS1 refers to the value of the Channel Center Frequency Segment 1 field of the most recently transmitted VHT Operation element. NOTE 5â€”CCFS2 refers to the value of the Channel Center Frequency Segment 2 field of the most recently transmitted HT Operation element. NOTE 6â€”CCFS1 is nonzero when the current BSS bandwidth is 160 MHz or 80+80 MHz and the NSS support is at least Max VHT NSS. CCFS2 is zero in this case. NOTE 7â€”CCFS2 is nonzero when the current BSS bandwidth is 160 MHz or 80+80 MHz and the NSS support is less than Max VHT NSS. CCFS1 is zero in this case. NOTE 8â€”At most one of CCFS1 and CCFS2 is nonzero. NOTE 9â€”A supported multiple of Max VHT NSS applies to both transmit and receive. NOTE 10â€”Some combinations of Supported Channel Width Set and Extended NSS BW support might not occur in practice. NOTE 11â€”2Ã— Max VHT NSS support might be used for HT PPDUs (at 20 or 40 MHz PPDU bandwidth). 781 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.1.54 Membership Status Array field The Membership Status Array field is used in the Group ID Management frame (see 9.6.23.3). The length of the field is 8 octets. An 8 octet Membership Status Array field (indexed by the group ID) consists of a 1-bit Membership Status subfield for each of the 64 group IDs, as shown in Figure 9-119. B0 B1 B63 Membership Status Membership Status â€¦ Membership Status In Group ID 0 In Group ID 1 In Group ID 63 Bits: 1 1 1 Figure 9-119â€”Membership Status Array field Within the 8 octet Membership Status Array field, the 1-bit Membership Status subfield for each group ID is set as follows: â€” Set to 0 if the STA is not a member of the group â€” Set to 1 if STA is a member of the group The Membership Status subfields for group ID 0 (transmissions to AP) and group ID 63 (downlink SU transmissions) are reserved. 9.4.1.55 User Position Array field The User Position Array field is used in the Group ID Management frame (see 9.6.23.3). The length of the field is 16 octets. A 16 octet User Position Array field (indexed by the Group ID) consists of a 2-bit User Position subfield for each of the 64 group IDs, as shown in Figure 9-120. B0 B1 B2 B3 B126 B127 User Position In User Position In User Position In Group ID 0 Group ID 1 â€¦ Group ID 63 Bits: 2 2 2 Figure 9-120â€”User Position Array field If the Membership Status subfield for a particular group ID is 1, then the corresponding User Position subfield in the User Position Array field contains the group IDâ€™s User Position. If the Membership Status subfield for a group ID is 0 (meaning the STA is not a member of that group), then the corresponding User Position subfield in the User Position Array field is reserved. The User Position subfields for group ID 0 (transmissions to AP) and group ID 63 (downlink SU transmissions) are reserved. 9.4.1.56 Device Location Information Body field A Device Location Information Body field includes the location configuration information (LCI), which contains latitude, longitude, and altitude information. 782 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The format of the Device Location Information Body field is shown in Figure 9-121. B0 B5 B6 B39 B40 B45 B46 B79 Latitude Latitude Longitude Longitude Uncertainty Uncertainty Bits: 6 34 6 34 B80 B83 B84 B89 B90 B119 Altitude Type Altitude Altitude Uncertainty Bits: 4 6 30 B120 B122 B123 B124 B125 B126 B127 Datum RegLoc RegLoc DSE Dependent STA Version Agreement Bits: 3 1 1 1 2 Figure 9-121â€”Device Location Information Body field format The fields within the Device Location Information Body field are as defined in section 2.2 of IETF RFC 6225 except as defined in 9.4.2.52, and RegLoc Agreement and RegLoc DSE are set to 0. 9.4.1.57 WSM Type field and WSM Information field The WSM Type field is set to a number that identifies the type of WSM information and the frequency band where the following WSM Information field is applicable. The values of WSM Types are shown in Table 9- 76. A WSM Type field value of 1 indicates the WSM Information field of the WSM element contains available frequency information for operation in the TVWS. Other values are reserved. Table 9-76â€”WSM Type definition Name WSM Type Reserved 0 TV band WSM 1 Reserved 2â€“255 The WSM Information field indicates the available channel information as defined in 9.4.4.2.5. The WSM Information field corresponding to a TV band WSM is shown in Table 9-269. 783 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2 Elements 9.4.2.1 General Elements are defined to have a common general format consisting of a 1 octet Element ID field, a 1 octet Length field, an optional 1 octet Element ID Extension field, and a variable-length element-specific Information field. Each element is identified by the contents of the Element ID and, when present, Element ID Extension fields as defined in this standard. An Extended Element ID is a combination of an Element ID and an Element ID Extension for those elements that have a defined Element ID Extension. The Length field specifies the number of octets following the Length field. See Figure 9-122. The presence of the Element ID Extension field is determined by the Element ID field. Element ID Length Element ID Information Extension Octets: 1 1 0 or 1 variable Figure 9-122â€”Element format The set of valid elements is defined in Table 9-77. Table 9-77â€”Element IDs Element ID Element Element ID Extensible Extension SSID (see 9.4.2.2) 0 N/A Supported Rates and BSS Membership Selectors 1 N/A (see 9.4.2.3) Reserved 2 DSSS Parameter Set (see 9.4.2.4) 3 N/A CF Parameter Set (see 9.4.2.5) 4 N/A TIM (see 9.4.2.6) 5 N/A IBSS Parameter Set (see 9.4.2.7) 6 N/A Country (see 9.4.2.9) 7 N/A Reserved 8 Reserved 9 Request (see 9.4.2.10) 10 N/A BSS Load (see 9.4.2.28) 11 N/A EDCA Parameter Set (see 9.4.2.29) 12 N/A TSPEC (see 9.4.2.30) 13 N/A In a non-DMG BSS: no In a DMG BSS: yes TCLAS (see 9.4.2.31) 14 N/A Schedule (see 9.4.2.34) 15 N/A Challenge text (see 9.4.2.8) 16 N/A Reserved 17â€“31 N/A Power Constraint (see 9.4.2.14) 32 N/A 784 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-77â€”Element IDs (continued) Element ID Element Element ID Extensible Extension Power Capability (see 9.4.2.15) 33 N/A TPC Request (see 9.4.2.16) 34 N/A TPC Report (see 9.4.2.17) 35 N/A Supported Channels (see 9.4.2.18) 36 N/A Channel Switch Announcement (see 9.4.2.19) 37 N/A Measurement Request (see 9.4.2.21) 38 N/A Subelements, for formats using 9.4.2.21.4 to 9.4.2.21.12. Measurement Report (see 9.4.2.22) 39 N/A Subelements, for formats using 9.4.2.22.4 to 9.4.2.22.11. Quiet (see 9.4.2.23) 40 N/A IBSS DFS (see 9.4.2.24) 41 N/A ERP (see 9.4.2.12) 42 N/A Yes TS Delay (see 9.4.2.32) 43 N/A TCLAS Processing (see 9.4.2.33) 44 N/A HT Capabilities (see 9.4.2.56) 45 N/A Yes QoS Capability (see 9.4.2.35) 46 N/A Reserved 47 RSN (see 9.4.2.25) 48 N/A Yes Reserved 49 Extended Supported Rates and BSS Membership 50 N/A Selectors (see 9.4.2.13) AP Channel Report (see 9.4.2.36) 51 N/A Neighbor Report (see 9.4.2.37) 52 N/A Subelements RCPI (see 9.4.2.38) 53 N/A Yes Mobility Domain (MDE) (see 9.4.2.47) 54 N/A No Fast BSS Transition (FTE) (see 9.4.2.48) 55 N/A Timeout Interval (see 9.4.2.49) 56 N/A RIC Data (RDE) (see 9.4.2.50) 57 N/A DSE Registered Location (see 9.4.2.52) 58 N/A Supported Operating Classes (see 9.4.2.54) 59 N/A Extended Channel Switch Announcement 60 N/A (see 9.4.2.53) HT Operation (see 9.4.2.57) 61 N/A Yes Secondary Channel Offset (see 9.4.2.20) 62 N/A 785 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-77â€”Element IDs (continued) Element ID Element Element ID Extensible Extension BSS Average Access Delay (see 9.4.2.39) 63 N/A Yes Antenna (see 9.4.2.40) 64 N/A Yes RSNI (see 9.4.2.41) 65 N/A Yes Measurement Pilot Transmission (see 9.4.2.42) 66 N/A Subelements BSS Available Admission Capacity 67 N/A Yes (see 9.4.2.43) BSS AC Access Delay (see 9.4.2.44) 68 N/A Yes Time Advertisement (see 9.4.2.61) 69 N/A Yes RM Enabled Capabilities (see 9.4.2.45) 70 N/A Yes Multiple BSSID (see 9.4.2.46) 71 N/A Subelements 20/40 BSS Coexistence (see 9.4.2.60) 72 N/A Yes 20/40 BSS Intolerant Channel Report 73 N/A (see 9.4.2.58) Overlapping BSS Scan Parameters (see 9.4.2.59) 74 N/A RIC Descriptor (see 9.4.2.51) 75 N/A Management MIC (see 9.4.2.55) 76 N/A Event Request (see 9.4.2.67) 78 N/A Subelements Event Report (see 9.4.2.68) 79 N/A Diagnostic Request (see 9.4.2.69) 80 N/A Subelements Diagnostic Report (see 9.4.2.70) 81 N/A Subelements Location Parameters (see 9.4.2.71) 82 N/A Subelements Nontransmitted BSSID Capability (see 9.4.2.72) 83 N/A SSID List (see 9.4.2.73) 84 N/A Multiple BSSID-Index (see 9.4.2.74) 85 N/A FMS Descriptor (see 9.4.2.75) 86 N/A FMS Request (see 9.4.2.76) 87 N/A Subelements FMS Response (see 9.4.2.77) 88 N/A Subelements QoS Traffic Capability (see 9.4.2.78) 89 N/A Yes BSS Max Idle Period (see 9.4.2.79) 90 N/A Yes TFS Request (see 9.4.2.80) 91 N/A Subelements TFS Response (see 9.4.2.81) 92 N/A Subelements WNM Sleep Mode (see 9.4.2.82) 93 N/A Yes TIM Broadcast Request (see 9.4.2.83) 94 N/A Yes TIM Broadcast Response (see 9.4.2.84) 95 N/A Yes Collocated Interference Report (see 9.4.2.85) 96 N/A Yes Channel Usage (see 9.4.2.86) 97 N/A Subelements 786 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-77â€”Element IDs (continued) Element ID Element Element ID Extensible Extension Time Zone (see 9.4.2.87) 98 N/A Yes DMS Request (see 9.4.2.88) 99 N/A Subelements DMS Response (see 9.4.2.89) 100 N/A Subelements Link Identifier (see 9.4.2.62) 101 N/A Yes Wakeup Schedule (see 9.4.2.63) 102 N/A Yes Channel Switch Timing (see 9.4.2.64) 104 N/A Yes PTI Control (see 9.4.2.65) 105 N/A Yes TPU Buffer Status (see 9.4.2.66) 106 N/A Yes Interworking (see 9.4.2.92) 107 N/A Advertisement Protocol (see 9.4.2.93) 108 N/A Expedited Bandwidth Request (see 9.4.2.94) 109 N/A QoS Map (see 9.4.2.95) 110 N/A Yes Roaming Consortium (see 9.4.2.96) 111 N/A Yes Emergency Alert Identifier (see 9.4.2.97) 112 N/A Mesh Configuration (see 9.4.2.98 113 N/A Yes Mesh ID (see 9.4.2.99 114 N/A Mesh Link Metric Report (see 9.4.2.100) 115 N/A Congestion Notification (see 9.4.2.101) 116 N/A Yes Mesh Peering Management (see 9.4.2.102) 117 N/A Yes Mesh Channel Switch Parameters (see 9.4.2.103) 118 N/A Yes Mesh Awake Window (see 9.4.2.104) 119 N/A Yes Beacon Timing (see 9.4.2.105) 120 N/A MCCAOP Setup Request (see 9.4.2.106) 121 N/A Yes MCCAOP Setup Reply (see 9.4.2.107) 122 N/A MCCAOP Advertisement (see 9.4.2.109) 123 N/A Yes MCCAOP Teardown (see 9.4.2.110) 124 N/A Yes GANN (see 9.4.2.111) 125 N/A Yes RANN (see 9.4.2.112) 126 N/A Yes Extended Capabilities (see 9.4.2.27) 127 N/A Yes Reserved 128â€“129 PREQ (see 9.4.2.113) 130 N/A Yes PREP (see 9.4.2.114) 131 N/A Yes PERR (see 9.4.2.115) 132 N/A Yes Reserved 133â€“136 PXU (see 9.4.2.116) 137 N/A Yes PXUC (see 9.4.2.117) 138 N/A Yes 787 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-77â€”Element IDs (continued) Element ID Element Element ID Extensible Extension Authenticated Mesh Peering Exchange 139 N/A (see 9.4.2.118) MIC (see 9.4.2.119) 140 N/A Destination URI (see 9.4.2.90) 141 N/A Yes U-APSD Coexistence (see 9.4.2.91) 142 N/A Subelements DMG Wakeup Schedule (see 9.4.2.131) 143 N/A Yes Extended Schedule (see 9.4.2.132) 144 N/A Yes STA Availability (see 9.4.2.133) 145 N/A Yes DMG TSPEC (see 9.4.2.134) 146 N/A Yes Next DMG ATI (see 9.4.2.135) 147 N/A Yes DMG Capabilities (see 9.4.2.128) 148 N/A Yes Reserved 149â€“150 DMG Operation (see 9.4.2.129 151 N/A Yes DMG BSS Parameter Change (see 9.4.2.127) 152 N/A Yes DMG Beam Refinement (see 9.4.2.130) 153 N/A Yes Channel Measurement Feedback (see 154 N/A Yes 9.4.2.136) Reserved 155â€“156 Awake Window (see 9.4.2.137) 157 N/A Yes Multi-band (see 9.4.2.138) 158 N/A Yes ADDBA Extension (see 9.4.2.139) 159 N/A Yes NextPCP List (see 9.4.2.140) 160 N/A Yes PCP Handover (see 9.4.2.141) 161 N/A Yes DMG Link Margin (see 9.4.2.142) 162 N/A Yes Switching Stream (see 9.4.2.144) 163 N/A Yes Session Transition (see 9.4.2.145) 164 N/A Yes Dynamic Tone Pairing Report (see 9.4.2.146) 165 N/A Yes Cluster Report (see 9.4.2.147) 166 N/A Yes Relay Capabilities (see 9.4.2.148) 167 N/A Yes Relay Transfer Parameter Set (see 9.4.2.149) 168 N/A Yes BeamLink Maintenance (see 9.4.2.152) 169 N/A Yes Multiple MAC Sublayers (see 9.4.2.153) 170 N/A Yes U-PID (see 9.4.2.154) 171 N/A Yes DMG Link Adaptation Acknowledgment 172 N/A Yes (see 9.4.2.143) Reserved 173 788 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-77â€”Element IDs (continued) Element ID Element Element ID Extensible Extension MCCAOP Advertisement Overview (see 174 N/A Yes 9.4.2.108) Quiet Period Request (see 9.4.2.150) 175 N/A Yes Reserved 176 Quiet Period Response (see 9.4.2.151) 177 N/A Yes Reserved 178â€“180 QMF Policy (see 9.4.2.120) 181 N/A ECAPC Policy (see 9.4.2.155) 182 N/A Yes Cluster Time Offset (see 9.4.2.156) 183 N/A Yes Intra-Access Category Priority (see 9.4.2.121) 184 N/A Yes SCS Descriptor (see 9.4.2.122) 185 N/A Subelements QLoad Report (see 9.4.2.123) 186 N/A Subelements HCCA TXOP Update Count (see 9.4.2.124) 187 N/A No Higher Layer Stream ID (see 9.4.2.125) 188 N/A Yes GCR Group Address (see 9.4.2.126) 189 N/A No Antenna Sector ID Pattern (see 9.4.2.157) 190 N/A Yes VHT Capabilities (see 9.4.2.158) 191 N/A Yes VHT Operation (see 9.4.2.159) 192 N/A Yes Extended BSS Load (see 9.4.2.160) 193 N/A Yes Wide Bandwidth Channel Switch (see 9.4.2.161) 194 N/A Yes Transmit Power Envelope (see 9.4.2.162) 195 N/A Yes Channel Switch Wrapper (see 9.4.2.163) 196 N/A Subelements AID (see 9.4.2.164) 197 N/A Quiet Channel (see 9.4.2.165) 198 N/A Yes Operating Mode Notification (see 9.4.2.166) 199 N/A Yes UPSIM (see 9.4.2.167) 200 N/A Yes Reduced Neighbor Report (see 9.4.2.171) 201 N/A Yes TVHT Operation (see 9.4.2.172) 202 N/A Yes Reserved 203 Device Location (see 9.4.2.169) 204 N/A Yes White Space Map (see 9.4.2.170) 205 N/A Yes Fine Timing Measurement Parameters (see 206 N/A Yes 9.4.2.168) Reserved 207â€“220 Vendor Specific (see 9.4.2.26) 221 N/A Reserved 222â€“254 789 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-77â€”Element IDs (continued) Element ID Element Element ID Extensible Extension Reserved for elements using the Element ID 255 0â€“8 Extension field FTM Synchronization Information 255 9 Yes Extended Request 255 10 Estimated Service Parameters (see 9.4.2.174) 255 11 Yes Future Channel Guidance 255 14 Reserved for elements using the Element ID 255 12â€“255 Extension field The frame body components specified for many management subtypes result in elements ordered by ascending values of the Element ID field and then the Element ID Extension field (when present), with the exception of the MIC Management element (9.4.2.55). If present, the MIC Management element appears at the end of the robust management frame body. See 10.27.6 on the parsing of elements. A â€œYesâ€ in the Extensible column of an element listed in Table 9-77 indicates that the Length of the element might be extended in future revisions or amendments of this standard. See 10.27.8. When the Extensible column of an element is set to â€œSubelements,â€ then the element might be extended in future revisions or amendments of this standard by defining additional subelements. See 10.27.9. The element is not extensible otherwise (i.e., if not marked as â€œYesâ€ or â€œSubelementsâ€). 9.4.2.2 SSID element The SSID element indicates the identity of an ESS or IBSS. See Figure 9-123. Element ID Length SSID Octets: 1 1 0â€“32 Figure 9-123â€”SSID element format The Element ID and Length fields are defined in 9.4.2.1. The length of the SSID field is between 0 and 32 octets. A SSID field of length 0 is used within Probe Request frames to indicate the wildcard SSID. The wildcard SSID is also used in Beacon and Probe Response frames transmitted by mesh STAs. When the UTF-8 SSID subfield of the Extended Capabilities element is equal to 1 in the frame that includes the SSID element, or the Extended Capabilities of the source of the SSID information is known to include the UTF-8 SSID capability based on a previously received Extended Capabilities element, the SSID is interpreted using UTF-8 encoding. Otherwise, the character encoding of the octets in this SSID element is unspecified. 9.4.2.3 Supported Rates and BSS Membership Selectors element The Supported Rates and BSS Membership Selectors element specifies up to eight rates in the OperationalRateSet parameter, as described in the MLME-JOIN.request and MLME-START.request 790 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications primitives, and zero or more BSS membership selectors. The Information field is encoded as 1 to 8 octets, where each octet describes a single supported rate or BSS membership selector (see Figure 9-124). Element ID Length Supported Rates Octets: 1 1 1â€“8 Figure 9-124â€”Supported Rates and BSS Membership Selectors element format The Element ID and Length fields are defined in 9.4.2.1. Within Beacon, Probe Response, Association Response, Reassociation Response, Mesh Peering Open, and Mesh Peering Confirm frames, each rate contained in the BSSBasicRateSet parameter is encoded as an octet with the MSB (bit 7) set to 1, and bits 6 to 0 are set to the data rate, if necessary rounded up to the next 500 kb/s, in units of 500 kb/s (e.g., a 2.25 Mb/s rate contained in the BSSBasicRateSet parameter is encoded as X'85'). Each rate in the OperationalRateSet parameter not contained in the BSSBasicRateSet parameter is encoded with the MSB set to 0, and bits 6 to 0 are set in the same way as for a rate contained in the BSSBasicRateSet parameter (e.g., a 2 Mb/s rate not contained in the BSSBasicRateSet parameter is encoded as X'04'). Within Beacon, Probe Response, Association Response, Reassociation Response, Mesh Peering Open, and Mesh Peering Confirm frames, each BSS membership selector contained in the BSSMembershipSelectorSet parameter is encoded as an octet with the MSB (bit 7) set to 1, and bits 6 to 0 are set to the encoded value for the selector as found in Table 9-78 (e.g., an HT PHY BSS membership selector contained in the BSSMembershipSelectorSet parameter is encoded as X'FF'). A BSS membership selector that has the MSB (bit 7) set to 1 in the Supported Rates and BSS Membership Selectors element is defined to be basic. The MSB of each octet in the Supported Rates field in other management frame types is ignored by receiving STAs. The valid values for BSS membership selectors and their associated features are shown in Table 9-78. NOTEâ€”Because the BSS membership selector and supported rates are carried in the same field, the BSS membership selector value cannot match the value corresponding to any valid supported rate. This allows any value to be determined as either a supported rate or a BSS membership selector. Table 9-78â€”BSS membership selector value encoding Value Feature Interpretation 127 HT PHY Support for the mandatory features of Clause 19 is required in order to join the BSS that was the source of the Supported Rates and BSS Membership Selectors element or Extended Supported Rates and BSS Membership Selectors element containing this value. 126 VHT PHY Support for the mandatory features of Clause 21 is required in order to join the BSS that was the source of the Supported Rates and BSS Membership Selectors element or Extended Supported Rates and BSS Membership Selectors element containing this value. See 11.1.4.6. 791 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.4 DSSS Parameter Set element The DSSS Parameter Set element contains information to allow channel number identification for STAs. See Figure 9-125. Element ID Length Current Channel Octets: 1 1 1 Figure 9-125â€”DSSS Parameter Set element format The Element ID and Length fields are defined in 9.4.2.1. The Current Channel field is set to dot11CurrentChannel (see 15.4.4.3, 16.3.6.3, 17.3.8.4.2 and 19.3.15 for values). 9.4.2.5 CF Parameter Set element The PCF mechanism is obsolete. Consequently, this subclause might be removed in a later revision of the standard. The CF Parameter Set element contains the set of parameters necessary to support the PCF. See Figure 9-126. Element ID Length CFP Count CFP Period CFP MaxDuration CFP DurRemaining Octets: 1 1 1 1 2 2 Figure 9-126â€”CF Parameter Set element format The Element ID and Length fields are defined in 9.4.2.1. The CFPCount field indicates how many delivery traffic indication maps (DTIMs) (including the current frame) appear before the next CFP start. A CFPCount of 0 indicates that the current DTIM marks the start of the CFP. The CFPPeriod field indicates the number of DTIM intervals between the start of CFPs. The value is an integer number of DTIM intervals. The CFPMaxDuration field indicates the maximum duration, in TU, of the CFP that might be generated by this PCF. This value is used by STAs to set their NAV at the TBTT of Beacon frames that begin CFPs. The CFPDurRemaining field indicates the maximum time, in TU, remaining in the present CFP and is set to 0 in CFP Parameter elements of Beacon frames transmitted during the CP. The value of CFPDurRemaining is referenced to the immediately previous TBTT. This value is used by all STAs to update their NAVs during CFPs. 9.4.2.6 TIM element The TIM element contains four fields: DTIM Count, DTIM Period, Bitmap Control, and Partial Virtual Bitmap. See Figure 9-127. 792 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Element ID Length DTIM Count DTIM Period Bitmap Control Partial Virtual Bitmap Octets: 1 1 1 1 1 1â€“251 Figure 9-127â€”TIM element format The Element ID and Length fields are defined in 9.4.2.1. The Length field for this element is constrained as described below. The DTIM Count field indicates how many Beacon frames (including the current frame) appear before the next DTIM. A DTIM count of 0 indicates that the current TIM is a DTIM. The DTIM Count field is a single octet. When a TIM element is included in a TIM frame, the DTIM Count field is reserved. The DTIM Period field indicates the number of beacon intervals between successive DTIMs. If all TIMs are DTIMs, the DTIM Period field has the value 1. The DTIM Period value 0 is reserved. The DTIM period field is a single octet. The Bitmap Control field is a single octet. Bit 0 of the field contains the traffic indication virtual bitmap bit associated with AID 0. This bit is set to 1 in TIM elements with a value of 0 in the DTIM Count field when one or more group addressed MSDUs/MMPDUs are buffered at the AP or the mesh STA. The remaining 7 bits of the field form the Bitmap Offset. The traffic indication virtual bitmap, maintained by the AP or the mesh STA that generates a TIM, consists of 2008 bits, and it is organized into 251 octets such that bit number N (0 N 2007) in the bitmap corresponds to bit number (N mod 8) in octet number N / 8 where the low-order bit of each octet is bit number 0, and the high order bit is bit number 7. Each bit in the traffic indication virtual bitmap corresponds to traffic buffered for a specific neighbor peer mesh STA within the MBSS that the mesh STA is prepared to deliver23 or for a STA within the BSS that the AP is prepared to deliver at the time the Beacon frame is transmitted. Bit number N indicates the status of buffered, individually addressed MSDUs/MMPDUs for the STA whose AID is N. It is determined as follows: â€” If the STA is not using APSD, and any individually addressed MSDUs/MMPDUs for that STA are buffered and the AP or the mesh STA is prepared to deliver them, then bit number N in the traffic indication virtual bitmap is 1. â€” If the STA is using APSD, and any individually addressed MSDUs/MMPDUs for that STA are buffered in at least one nondelivery-enabled AC (if there exists at least one nondelivery-enabled AC), then bit number N in the traffic indication virtual bitmap is 1. â€” If the STA is using APSD, all ACs are delivery-enabled, and any individually addressed MSDUs/ MMPDUs for that STA are buffered in any AC, then bit number N in the traffic indication virtual bitmap is 1. â€” Otherwise, bit number N in the traffic indication virtual bitmap is 0. A PC might decline to set bits in the TIM for CF-Pollable STAs it does not intend to poll (see 11.2.3.7). When dot11MultiBSSIDActivated is false, the Partial Virtual Bitmap field consists of octets numbered N1 to N2 of the traffic indication virtual bitmap, where N1 is the largest even number such that bits numbered 1 to (N1 8) â€“ 1 in the traffic indication virtual bitmap are all 0 and N2 is the smallest number such that bits numbered (N2 + 1) 8 to 2007 in the traffic indication virtual bitmap are all 0. In this case, the Bitmap Offset subfield value contains the number N1/2, and the Length field is set to (N2 â€“ N1) + 4. NOTEâ€”The bit numbered 0 in the traffic indication virtual bitmap need not be included in the Partial Virtual Bitmap field even if that bit is set. 23 How the AP or mesh STA determines the traffic is prepared to deliver is outside the scope of this standard. 793 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications In the event that all bits other than bit 0 in the traffic indication virtual bitmap are 0, the Partial Virtual Bitmap field is encoded as a single octet equal to 0, the Bitmap Offset subfield is 0, and the Length field is 4. When dot11MultiBSSIDActivated is true, the Partial Virtual Bitmap field of the TIM element is constructed as follows, where the maximum possible number of BSSIDs is an integer power of 2, n = log2 (maximum possible number of BSSIDs), k is the number of actually supported nontransmitted BSSIDs, and k (2n â€“ 1). â€” The bits 1 to k of the bitmap are used to indicate that one or more group addressed frames are buffered for each AP corresponding to a nontransmitted BSSID. The AIDs from 1 to k are not allocated to a STA. The AIDs from (k + 1) to (2n â€“ 1) are reserved and set to 0. The remaining AIDs are shared by the BSSs corresponding to the transmitted BSSID and all nontransmitted BSSIDs. â€” When the DTIM Count field is 0 for a BSS that has a nontransmitted BSSID, and one or more group addressed frames are buffered at the AP for this BSS, the corresponding bits from bit 1 to bit k is set to 1. â€” Each bit starting from bit 2n in the traffic indication virtual bitmap corresponds to individually addressed traffic buffered for a specific STA within any BSS corresponding to a transmitted or nontransmitted BSSID at the time the Beacon frame is transmitted. The correspondence is based on the AID of the STA. â€” Based upon its knowledge of the capability of associated stations to support the multiple BSSID capability, as indicated by the corresponding field in the Extended Capabilities element and the content of the traffic indication virtual bitmap, an AP encodes the Partial Virtual Bitmap and the Bitmap Control field of the TIM element using one of the two following methods. Specifically, an AP uses Method B when it determines that the bit for each associated non-AP STA in the traffic indication virtual bitmap that is reconstructed by each non-AP STA from the received TIM element encoded using Method B is set correctly. Otherwise, an AP uses Method A. Method A and Method B are described as follows: a) Method A: The Partial Virtual Bitmap field consists of octets numbered 0 to N2 of the traffic indication virtual bitmap, where N2 is the smallest number such that bits numbered (N2 + 1) Ã— 8 to 2007 in the traffic indication virtual bitmap are all 0. If such a value N2 does not exist, that is, when not all bits in the last octet of the traffic indication virtual bitmap are equal to 0, N2 = 250. When using this method, the Bitmap Offset subfield value always contains the number 0, and the Length field is N2 + 4. b) Method B: The Partial Virtual Bitmap field consists of a concatenation of octets numbered 0 to N0 â€“ 1 and octets numbered N1 to N2 of the traffic indication virtual bitmap, where N0 is the smallest positive integer such that N0 Ã— 8 â€“ 2n < 8. If N0 is an odd number, then N1 is the largest odd number such that N0 < N1and each of the bits N0 Ã— 8 to (N1 Ã— 8 â€“ 1) is equal to 0. When N0 is an even number, N1 is the largest even number such that N0 < N1 and each of the bits N0 Ã— 8 to (N1 Ã— 8 â€“ 1) is equal to 0. If such a value N1 > N0 does not exist, N1 = N0. Additionally, N2 is the smallest integer value for which the values for bit (N2+1) Ã— 8 to 2007 in the traffic indication virtual bitmap are all 0. If such a value N2 does not exist, that is, when not all bits in the last octet of the traffic indication virtual bitmap are equal to 0, N2 = 250. When using this method, the Bitmap Offset subfield contains the value of (N1 â€“ N0)/2, and the Length field is N0 + N2 â€“ N1 + 4. NOTEâ€”When N1 = N0, Method B reduces to Method A. For both Method A and Method B, when there are no frames buffered for any BSS corresponding to a transmitted or nontransmitted BSSID supported, the Partial Virtual Bitmap field is encoded as a single octet equal to 0, the Bitmap Offset subfield is 0, and the Length field is 4. When there are no buffered individually addressed frames for any BSS corresponding to a transmitted or nontransmitted BSSID, but there are buffered group addressed frames for one or more of the BSSs, the Partial Virtual Bitmap field consists of the octets number 0 to N0 â€“ 1 where N0 is the smallest positive integer such that (N0 Ã— 8 â€“ 2n < 8). In this case, the Bitmap Offset subfield value contains the number 0, and the Length field is N0+3. 794 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.7 IBSS Parameter Set element The IBSS Parameter Set element contains the set of parameters necessary to support an IBSS. See Figure 9-128. Element ID Length ATIM Window Octets: 1 1 2 Figure 9-128â€”IBSS Parameter Set element format The Element ID and Length fields are defined in 9.4.2.1. The ATIM Window field contains the ATIM window length in TU. 9.4.2.8 Challenge Text element The Challenge Text element contains the challenge text within Authentication exchanges. See Figure 9-129. Element ID Length Challenge Text Octets: 1 1 1â€“253 Figure 9-129â€”Challenge Text element format The Element ID and Length fields are defined in 9.4.2.1. The content of the Challenge Text field is dependent upon the authentication algorithm and the transaction sequence number as specified in 12.3.3.2. 9.4.2.9 Country element The Country element contains the information required to allow a STA to identify the regulatory domain in which the STA is located and to configure its PHY for operation in that regulatory domain. The format of this element is as shown in Figure 9-130. Element ID Length Country String Triplet Padding (if needed) Octets: 1 1 3 QÃ—3 0 or 1 Figure 9-130â€”Country element format The Element ID and Length fields are defined in 9.4.2.1. The length of the element is variable, as the element contains the variable-length Triplet field. The Country String field is 3 octets in length. The AP and mesh STA set this field to the value contained in dot11CountryString before transmission in a Beacon or Probe Response frame. Upon reception of this element, a STA sets the value of the dot11CountryString to the value contained in this field. The three octets of the Country String have additional structure as defined by dot11CountryString (see Annex C). If dot11OperatingClassesRequired is false, then the Triplet field is a single Subband Triplet Sequence field, as shown in Figure 9-131, that is composed of Q Subband Triplet fields, where Q is one or more. The format of the Subband Triplet field is shown in Figure 9-132. 795 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications One or more Subband Triplet Octets: 3 Figure 9-131â€”Subband Triplet Sequence format Maximum First Channel Number of Transmit Number Channels Power Level Octets: 1 1 1 Figure 9-132â€”Subband Triplet field If dot11OperatingClassesRequired is true, then the Triplet field is composed of zero or more Subband Triplet fields followed by one or more Operating/Subband Sequences, as shown in Figure 9-133. Each Operating/Subband Sequence is composed of one Operating Triplet field followed by one Subband Triplet Sequence field, as shown in Figure 9-134. Each Subband Triplet Sequence field is composed of zero or more Subband Triplet fields. If dot11OperatingClassesRequired is true, the number of triplets in the Triplet M field is Q = N + 1 + P(m) , where N is the total number of Subband Triplet fields and M is the total m=1 number of Operating/Subband Sequences contained in Country element and P(m) is the number of Subband Triplet fields making up Operating/Subband Sequence field m. Zero or more One or more indexed by m = 1 2 M; M 1 Operating/Subband Subband Triplet Sequence Octets: 3 3 Figure 9-133â€”Triplet field if dot11OperaratingClassRequired is true Operating Triplet Subband Triplet Sequence Operating made up of P(m) Subband Extension Operating Coverage Triplet fields, where P(m) 0 Class Class Identifier Octets: 1 1 1 3P(m) Figure 9-134â€”Format of m-th Operating/Subband Sequence field The number Q of Subband fields or Operating triplet fields in the element is determined by the Length field. An operating class for an 80+80 MHz channel width is expressed by two consecutive Operating/Subband Sequences, where the first Operating/Subband Sequence field contains an Operating Triplet field indicating an 80 MHz Channel Spacing with an 80+ behavior limit and the second Operating/Subband Sequence field contains an Operating Triplet field indicating an 80 MHz Channel Spacing without an 80+ behavior limit. 796 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Operating/Subband Sequence fields that contain an Operating Class field for which the â€œChannel Spacing (MHz)â€ column in the appropriate table in Annex E equals 80 or 160 contain zero Subband Triplet fields. NOTE 1â€”Any Operating Triplet field indicating 80 MHz, 160 MHz, and 80+80 MHz can be omitted from the Country element (see 10.21.3). NOTE 2â€”The Transmit Power Envelope element is always used for TPC for 80 MHz, 160 MHz, or 80+80 MHz operating classes instead of Subband Triplet fields (see 11.40.1). The first octet in each Subband Triplet field or Operating Triplet field contains an unsigned integer and identifies the type of field. If the integer has a value less than or equal to 200, then the field is a Subband Triplet field. If the integer has a value of 201 or greater, then the field is an Operating Triplet field. The minimum length of the element is 8 octets. The First Channel Number field indicates the lowest channel number in the Subband Triplet field. No channel is indicated by more than one pair of First Channel Number and Number of Channels fields within a Subband Triplet Sequence field. [For example, the (First Channel Number, Number of Channels) pairs (2,4) and (5,2) in 2.4 GHz each indicate channel 5, therefore are not used within the same Subband Triplet Sequence field.] The First Channel Numbers are monotonically increasing within a Subband Triplet Sequence field. The First Channel Number and the Number of Channels pairs in a Country element are used to describe channels only in the band on which the frame containing the element is transmitted. The Number of Channels subfield of the subelement is 1 octet in length. Outside the 2.4 GHz band, the channel numbers that are included in a group of channels are separated by the BSS bandwidth. For Subband Triplet fields that are not within an Operating/Subband Sequence field, the BSS bandwidth is 20 MHz. For Subband Triplet fields that are within an Operating/Subband Sequence field, the BSS bandwidth is as indicated by the operating class in the same Operating/Subband Sequence field. In the 2.4 GHz band, the channel numbers that are included in a group of channels are separated by 5 MHz (for both 20 and 40 MHz BSS bandwidth), except that channel 14 is treated as if it were 5 MHz above channel 13. NOTEâ€”For example, the channels 1 to 11 in the 2.4 GHz band can be represented using one Subband Triplet subfield with First Channel Number = 1 and Number of Channels = 11. The channels 36, 40, 44 and 48 with 20 MHz BSS bandwidth in the 5 GHz band can be represented using one Subband Triplet subfield with First Channel Number = 36 and Number of Channels = 4. The six channels 183, 184, 185, 187, 188 and 189 (but not 186) with 10 MHz BSS bandwidth can be represented using three Subband Triplet subfields: one with First Channel Number = 183 and Number of Channels = 4, one with First Channel Number = 184 and Number of Channels = 1 and one with First Channel Number = 188 and Number of Channels = 1. The Maximum Transmit Power Level field is a signed number and is 1 octet in length. The Maximum Transmit Power Level field indicates the maximum power, in dBm, allowed to be transmitted. As the method of measurement for maximum transmit power level differs by regulatory domain, the value in this field is interpreted according to the regulations applicable for the domain identified by the Country String. An operating class is an index into a set of values for radio equipment sets of rules. The Operating Class field is 1 octet in length. A coverage class is an index into a set of values for aAirPropagationTime. The Coverage Class field is reserved in a DMG BSS. The Coverage Class field is 1 octet in length. The Coverage Class field of the Operating Triplet field specifies the aAirPropagationTime characteristic used in BSS operation, as shown in Table 9-79. The characteristic aAirPropagationTime describes variations in actual propagation time that are accounted for in a BSS and, together with maximum transmit power level, allow control of BSS diameter. The Padding field is 0 or 1 octet in length. The Padding field is used to add, if needed, a single octet (with the value 0) to the Country element so that its length is evenly divisible by 2. 797 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-79â€”Coverage Class field parameters Coverage class aAirPropagationTime value (Âµs) 0â€“31 n 3 , where n is the value of the coverage class 32â€“255 Reserved 9.4.2.10 Request element This element is placed in a Probe Request frame or Information Request frame to request that the responding STA include the requested information in the Probe Response frame or Information Response frame, respectively. The format of the element is as shown in Figure 9-135. Element ID Length Requested Element IDs Octets: 1 1 variable Figure 9-135â€”Request element The Element ID and Length fields are defined in 9.4.2.1. The Requested Element IDs are the list of elements that are requested to be included in the Probe Response or Information Response frame. The Requested Element IDs are listed in order of increasing element ID. The Requested Element IDs within a Request element transmitted in an Information Request frame do not include an element ID that corresponds to an element that will be included in the Information Response frame even in the absence of the Request element, as shown in Table 9-390. A given element ID is included at most once among the Requested Element IDs. NOTEâ€”Some implementations might unnecessarily include in a Probe Request frame a Request element that contains the element ID of an element that will be included in the Probe Response frame even in the absence of the element ID in the Request element; see the notes in Table 9-34. Some implementations might include in a Probe Request frame a Request element that contains the element ID of an element that will not be included in the Probe Response frame even in the presence of the element ID in the Request element. The Request element does not support Extended Element IDs. See 11.1.4.3.5 for additional requirements. 9.4.2.11 Extended Request element This element is placed in a Probe Request frame or Information Request frame to request that the responding STA include the requested information in the Probe Response frame or Information Response frame, respectively. The format of the element is as shown in Figure 9-136. Element ID Length Element ID Requested Requested Element ID Extension Element ID Extensions Octets: 1 1 1 1 variable Figure 9-136â€”Extended Request element The Element ID, Element ID Extension, and Length fields are defined in 9.4.2.1. 798 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Requested Element ID field contains one of the Element IDs used to indicate an extended element. The Requested Element ID Extensions field contains a list of 1-octet element ID extension values that, combined with the value of the Requested Element ID field, identify elements that are requested to be included in the Probe Response or Information Response frame. The values in this field are listed in increasing order. The requested elements within an Extended Request element transmitted in a Probe Request frame do not identify an element that will be included in the Probe Response frame even in the absence of the Request element, or will be excluded from the Probe Response frame even in the presence of the Extended Request element as described by the notes in Table 9-34. The requested elements within an Extended Request element transmitted in an Information Request frame do not identify an element that will be included in the Information Response frame even in the absence of the Extended Request element, as shown in Table 9-390. A given element ID extension value is included at most once in the Requested Element ID Extensions field. See 11.1.4.3.5 for additional requirements. 9.4.2.12 ERP element The ERP element contains information on the presence of Clause 15 or Clause 16 STAs in the BSS that are not capable of Clause 18 (ERP-OFDM) data rates. It also contains the requirement of the ERP element sender (AP, IBSS STA, or mesh STA) as to the use of protection mechanisms to optimize BSS performance and as to the use of long or short Barker preambles. See Figure 9-137 for a definition of the frame element. The ERP element has the form shown in Figure 9-137. Length ERP Element ID (1) Parameters Octets: 1 1 1 Figure 9-137â€”ERP element The Element ID and Length fields are defined in 9.4.2.1. The ERP Parameters field is defined in Figure 9-138. B0 B1 B2 B3 B7 NonERP_Present Use_Protection Barker_Preamble_Mode Reserved Bits: 1 1 1 5 Figure 9-138â€”ERP Parameters field Recommended behavior for setting the Use_Protection bit is contained in 10.26. 9.4.2.13 Extended Supported Rates and BSS Membership Selectors element The Extended Supported Rates and BSS Membership Selectors element specifies the rates in the OperationalRateSet parameter, as described in the MLME-JOIN.request and MLME-START.request primitives, and zero or more BSS membership selectors, where these are not carried in the Supported Rates and BSS Membership Selectors element. The Information field is encoded as 1 to 255 octets, where each octet describes a single supported rate or BSS membership selector (see Figure 9-139). 799 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Extended Supported Element ID Length Rates Octets: 1 1 1â€“255 Figure 9-139â€”Extended Supported Rates and BSS Membership Selectors element format The Element ID and Length fields are defined in 9.4.2.1. The format and interpretation of each octet of the Extended Supported Rates field is the same as that of an octet in the Supported Rates field in a Supported Rates and BSS Membership Selectors element (see 9.4.2.3). 9.4.2.14 Power Constraint element The Power Constraint element contains the information necessary to allow a STA to determine the local maximum transmit power in the current channel. The format of the Power Constraint element is shown in Figure 9-140. Local Power Element ID Length Constraint Octets: 1 1 1 Figure 9-140â€”Power Constraint element format The Element ID and Length fields are defined in 9.4.2.1. The Local Power Constraint field is coded as an unsigned integer in units of decibels. The local maximum transmit power for a channel is thus defined as the maximum transmit power level specified for the channel in the Country element minus the local power constraint specified for the channel (from the MIB) in the Power Constraint element. The Power Constraint element is included in Beacon frames, as described in 9.3.3.3, and Probe Response frames, as described in 9.3.3.11. The use of Power Constraint elements is described in 11.8.5. 9.4.2.15 Power Capability element The Power Capability element specifies the minimum and maximum transmit powers with which a STA is capable of transmitting in the current channel. The format of the Power Capability element is shown in Figure 9-141. Minimum Maximum Element ID Length Transmit Power Transmit Power Capability Capability Octets: 1 1 1 1 Figure 9-141â€”Power Capability element format The Element ID and Length fields are defined in 9.4.2.1. 800 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Minimum Transmit Power Capability field is set to the nominal minimum transmit power with which the STA is capable of transmitting in the current channel, with a tolerance Â± 5 dB. The field is coded as a signed integer in units of decibels relative to 1 mW. Further interpretation of this field is defined in 11.8.4. The Maximum Transmit Power Capability field is set to the nominal maximum transmit power with which the STA is capable of transmitting in the current channel, with a tolerance Â± 5 dB. The field is coded as a signed integer in units of decibels relative to 1 mW. Further interpretation of this field is defined in 11.8.4. The Power Capability element is included in Association Request frames, as described in 9.3.3.6; Reassociation Request frames, as described in 9.3.3.8; and Mesh Peering Open frame, as described in 9.6.16.2.2. The use of Power Capability elements is described in 11.8.2. 9.4.2.16 TPC Request element The TPC Request element contains a request for a STA to report transmit power and link margin information using a TPC Report element. The format of the TPC Request element is shown in Figure 9-142. Element ID Length Octets: 1 1 Figure 9-142â€”TPC Request element format The Element ID and Length fields are defined in 9.4.2.1. The TPC Request element is included in TPC Request frames, as described in 9.6.2.4. The use of TPC Request elements and frames is described in 11.8.7. 9.4.2.17 TPC Report element The TPC Report element contains transmit power and link margin information sent in response to a TPC Request element or a Link Measurement Request frame. A TPC Report element is included in a Beacon frame or Probe Response frame without a corresponding request. The format of the TPC Report element is shown in Figure 9-143. Element ID Length Transmit Power Link Margin Octets: 1 1 1 1 Figure 9-143â€”TPC Report element format The Element ID and Length fields are defined in 9.4.2.1. The Transmit Power field is set to the transmit power used to transmit the frame containing the TPC Report element. The field is coded as a 2s complement signed integer in units of decibels relative to 1 mW. The maximum tolerance for the transmit power value reported in the TPC Response element is Â± 5 dB. This tolerance is defined as the difference, in decibels, between the reported power value and the actual EIRP of the STA (when transmitting 1500 octet frames or maximum MPDU sized-frames, whichever is smaller). The Link Margin field contains the link margin for the receive time and for the receive rate of the frame containing the TPC Request element or the Link Measurement Request frame. The field is coded as a 2s 801 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications complement signed integer in units of decibels. The Link Margin field is reserved when a TPC Report element is included in a Beacon frame or Probe Response frame. The method used to measure the link margin is beyond the scope of this standard. The TPC Report element is included in TPC Report frames, as described in 9.6.2.5; Link Measurement Report frames, as described in 9.6.7.5; Beacon frames, as described in 9.3.3.3; and Probe Response frames, as described in 9.3.3.11. The use of TPC Report elements and frames is described in 11.8.7. 9.4.2.18 Supported Channels element The Supported Channels element contains a list of channel subbands (from those channels defined in 17.3.8.4.3) in which a STA is capable of operating. The format of the Supported Channels element is shown in Figure 9-144. One (first channel, number of channels) tuple for each subband First Channel Number of Element ID Length Number Channels Octets: 1 1 1 1 Figure 9-144â€”Supported Channels element format The Element ID and Length fields are defined in 9.4.2.1. The First Channel Number field is set to the first channel (as defined in 17.3.8.4.3) in a subband of supported channels. The Number of Channels field is set to the number of channels in a subband of supported channels. The Supported Channels element is included in Association Request frames, as described in 9.3.3.6; Reassociation Request frames, as described in 9.3.3.8; and Mesh Peering Open frame, as described in 9.6.16.2.2. The use of the Supported Channels element is described in 11.9.2 and 11.9.8. 9.4.2.19 Channel Switch Announcement element The Channel Switch Announcement element is used by an AP, IBSS STA, mesh STA, or PCP to advertise when it is changing to a new channel and the channel number of the new channel. The format of the Channel Switch Announcement element is shown in Figure 9-145. Channel Switch New Channel Channel Switch Element ID Length Mode Number Count Octets: 1 1 1 1 1 Figure 9-145â€”Channel Switch Announcement element format The Element ID and Length fields are defined in 9.4.2.1. The Channel Switch Mode field indicates any restrictions on transmission until a channel switch. An AP or IBSS STA sets the Channel Switch Mode field to either 0 or 1 on transmission. In an MBSS, the Channel Switch Mode field is reserved. See 11.9.9. The New Channel Number field is set to the number of the channel to which the STA is moving (as defined in 17.3.8.4.3). 802 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications For nonmesh STAs, the Channel Switch Count field either is set to the number of TBTTs until the STA sending the Channel Switch Announcement element switches to the new channel or is set to 0. A value of 1 indicates that the switch occurs immediately before the next TBTT. A value of 0 indicates that the switch occurs at any time after the frame containing the element is transmitted. For mesh STAs, the Channel Switch Count field is encoded as an octet with bits 6 to 0 set to the time, in units of 2 TU when the MSB (bit 7) is 0, or in units of 100 TU when the MSB (bit 7) is 1, until the mesh STA sending the Channel Switch Announcement element switches to the new channel. A value of 0 for bits 6 to 0 indicates that the switch occurs at any time after the frame containing the element is transmitted. For example, a 200 TU channel switch time is encoded as X'82' and a 10 TU channel switch time is encoded as X'05'. The Channel Switch Announcement element is included in Channel Switch Announcement frames, as described in 9.6.2.6, and can be included in Beacon frames, as described in 9.3.3.3, and Probe Response frames, as described in 9.3.3.11. The use of Channel Switch Announcement elements and frames is described in 11.9.8. 9.4.2.20 Secondary Channel Offset element The Secondary Channel Offset element is used by an AP, IBSS STA or mesh STA when changing to a new 40 MHz or wider channel. The format of the Secondary Channel Offset element is shown in Figure 9-146. The Secondary Channel Offset element is included in Channel Switch Announcement frames, as described in 9.6.2.6. Element ID Length Secondary Channel Offset Octets: 1 1 1 Figure 9-146â€”Secondary Channel Offset element format The Element ID and Length fields are defined in 9.4.2.1. The Secondary Channel Offset field of the Secondary Channel Offset element represents the position of the secondary channel relative to the primary channel. The values of the Secondary Channel Offset field are defined in Table 9-80. Table 9-80â€”Values of the Secondary Channel Offset field Value Name Description 0 SCN - no secondary channel Indicates that no secondary channel is present. 1 SCA - secondary channel above Indicates that the secondary channel is above the primary channel. 2 Reserved. 3 SCB - secondary channel below Indicates that the secondary channel is below the primary channel. 4â€“255 Reserved. 803 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.21 Measurement Request element 9.4.2.21.1 General The Measurement Request element contains a request that the receiving STA undertake the specified measurement action. The Measurement Request element is included in Measurement Request frames, as described in 9.6.2.2, or Radio Measurement Request frames, as described in 9.6.7.2. Measurement types 0, 1, and 2 are defined for spectrum management and are included only in Measurement Request frames. The use of Measurement Request elements for spectrum management is described in 11.9.7. All other measurement types are included only in Radio Measurement Request frames. The use of Measurement Request elements for radio measurement is described in 11.11. The format of the Measurement Request element is shown in Figure 9-147. Element ID Length Measurement Measurement Measurement Measurement Token Request Mode Type Request Octets: 1 1 1 1 1 variable Figure 9-147â€”Measurement Request element format The Element ID and Length fields are defined in 9.4.2.1. The value of the Length field is variable and depends on the length of the Measurement Request field. The minimum value of the Length field is 3 (based on a minimum length for the Measurement Request field of 0 octets). The Measurement Token is set to a nonzero number that is unique among the Measurement Request elements in a particular Measurement Request frame. The Measurement Request Mode field (shown in Figure 9-148) is a bit field with the following bits defined: â€” The Parallel bit (bit 0) is used to request that more than one measurement is to be started in parallel. Parallel is set to 1 to request that the measurement is to start at the same time as the measurement described by the next Measurement Request element in the same Measurement Request frame. Parallel is set to 0 if the measurements are to be performed in sequence. The Parallel bit is reserved when Enable is 1, in the last or only Measurement Request element in the frame, or when the value of the Measurement Type field is 0, 1, or 2 (spectrum management measurements). See 11.11.6. â€” The Enable bit (bit 1) is used to differentiate between a request to make a measurement and a request to control the measurement requests and triggered or autonomous reports generated by the destination STA. The Enable bit is further described in Table 9-81. â€” Request bit (bit 2) is described in Table 9-81. â€” Report bit (bit 3) is described in Table 9-81. â€” The Duration Mandatory bit (bit 4) indicates whether the measurement duration contained within the measurement request is interpreted as mandatory by the STA receiving the request. A value of 0 indicates that the duration requested is a maximum duration, and the requesting STA accepts measurement results taken over any shorter duration. A value of 1 indicates that the duration requested is a mandatory duration. The Duration Mandatory bit is reserved when the Enable bit is 1, or when the value of the Measurement Type field is 0, 1, 2, 8, or 255. See 11.11.4. â€” All other bits are reserved. 804 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B0 B1 B2 B3 B4 B5 B7 Duration Parallel Enable Request Report Reserved Mandatory Bits: 1 1 1 1 1 3 Figure 9-148â€”Measurement Request Mode field The use of the Enable, Request, and Report bits is summarized in Table 9-81. See 11.9.7 and 11.11.6 for the description of how a STA handles requests to enable or disable measurement requests and autonomous reports. See 11.11.8 for a description of the use of the Enable and Report bits in triggered reporting. Table 9-81â€”Summary of use of Enable, Request, and Report bits Bits Meaning of bits Enable Request Report 0 Reserved Reserved The transmitting STA is requesting that the destination STA make a measurement of type indicated in the Measurement Type field. When Enable bit is 0, Request and Report bits are reserved. 1 0 0 The transmitting STA is requesting that the destination STA not send any measurement requests or reports of the type indicated in the Measurement Type field. 1 1 0 The transmitting STA is indicating to the destination STA that it can accept measurement requests and is requesting the destination STA not send autonomous or triggered measurement reports of the type indicated in the Measurement Type field. NOTEâ€”This setting corresponds to the default STA behavior. 1 0 1 The transmitting STA is requesting that the destination STA not send measurement requests and indicating it accepts autonomous or triggered measurement reports of the type indicated in the Measurement Type field. 1 1 1 The transmitting STA is indicating to the destination STA that it can accept measurement requests and can accept autonomous or triggered measurement reports of the type indicated in the Measurement Type field. The Measurement Type field is set to a number that identifies a type of measurement request or measurement report. The measurement types that have been allocated for measurement requests are shown in Table 9-82 and measurement reports are shown in Table 9-107 (in 9.4.2.22). Table 9-82â€”Measurement type definitions for measurement requests Measurement Name type Basic 0 Clear Channel Assessment (CCA) 1 Receive Power Indication (RPI) Histogram 2 Channel Load 3 Noise Histogram 4 805 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-82â€”Measurement type definitions for measurement requests (continued) Measurement Name type Beacon 5 Frame 6 STA Statistics 7 LCI 8 Transmit Stream/Category Measurement 9 Multicast Diagnostics 10 Location Civic 11 Location Identifier 12 Directional Channel Quality 13 Directional Measurement 14 Directional Statistics 15 Fine Timing Measurement Range 16 Reserved 17â€“254 Measurement Pause 255 When the Enable bit is 0, the Measurement Request field contains the specification of a single measurement request corresponding to the measurement type, as described in 9.4.2.21.2 to 9.4.2.21.12. When the Enable bit is 1, the Measurement Request field is present only when requesting a triggered measurement. References in this standard to a â€˜ requestâ€™, where corresponds to one of the Measurement Types in Table 9-82 is equivalent to (according to context) a) â€˜a Measurement Request frame or Radio Measurement Request frame carrying a Measurement Request element with the measurement type field equal to â€™ or b) â€˜a Measurement Request element with the measurement type field equal to â€™. 9.4.2.21.2 Basic request The Measurement Request field corresponding to a Basic request is shown in Figure 9-149. See 11.9.7. Channel Measurement Measurement Number Start Time Duration Octets: 1 8 2 Figure 9-149â€”Measurement Request field format for a Basic request The Channel Number field is set to the channel number for which the measurement request applies where the channel number is a value from the â€œChannel setâ€ column in Table E-4, in a row having the same value in the â€œChannel spacing (MHz)â€ column as the width of the primary channel. The Measurement Start Time field is set to the TSF timer at the time (Â± 32 s) at which the requested Basic request measurement starts. A value of 0 indicates it starts immediately. The Measurement Duration field is set to the duration of the requested measurement, expressed in TUs. 806 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.21.3 CCA request (Clear channel access request) The Measurement Request field corresponding to a CCA request is shown in Figure 9-150. Channel Measurement Measurement Number Start Time Duration Octets: 1 8 2 Figure 9-150â€”Measurement Request field format for a CCA request The Channel Number field is set to the channel number for which the measurement request where the channel number is a value from the â€œChannel setâ€ column in Table E-4, in a row having the same value in the â€œChannel spacing (MHz)â€ column as the width of the primary channel. The Measurement Start Time field is set to the TSF at the time (Â± 32 s) at which the requested CCA request measurement starts. A value of 0 indicates it starts immediately. The Measurement Duration field is set to the duration of the requested measurement, expressed in TUs. 9.4.2.21.4 RPI histogram request (Received power indicator histogram request) The Measurement Request field corresponding to an RPI Histogram request is shown in Figure 9-151. Channel Measurement Measurement Number Start Time Duration Octets: 1 8 2 Figure 9-151â€”Measurement Request field format for an RPI Histogram request The Channel Number field is set to the channel number for which the measurement request where the channel number is a value from the â€œChannel setâ€ column in Table E-4, in a row having the same value in the â€œChannel spacing (MHz)â€ column as the width of the primary channel. The Measurement Start Time field is set to the TSF at the time (Â± 32 s) at which the requested RPI Histogram request measurement starts. A value of 0 indicates it starts immediately. The Measurement Duration field is set to the duration of the requested measurement, expressed in TUs. 9.4.2.21.5 Channel Load request The Measurement Request field corresponding to a Channel Load request is shown in Figure 9-152. Operating Channel Randomization Measurement Optional Class Number Interval Duration Subelements Octets: 1 1 2 2 variable Figure 9-152â€”Measurement Request field format for Channel Load request If the Wide Bandwidth Channel Switch subelement is not included, the Operating Class field indicates the operating class that identifies the channel set for which the measurement request applies. The Country, Operating Class, and Channel Number fields together specify the channel frequency and spacing for which the measurement request applies. Valid operating classes are listed in Annex E, excluding operating classes that encompass a primary channel but do not identify the location of the primary channel. The Channel 807 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Number field indicates the channel number for which the measurement request applies. Channel number is defined within an operating class as shown in Annex E. NOTEâ€”Examples of operating classes that encompass a primary channel but do not identify the location of the primary channel are operating classes with a value of 80 or 160 in the â€œChannel Spacing (MHz)â€ column in the applicable table in Annex E. If the Wide Bandwidth Channel Switch subelement is included, the fields in the Wide Bandwidth Channel Switch subelement indicate the channel for which the measurement request applies, and the Operating Class field and Channel Number field together specify the primary channel and primary 40 MHz channel within the channel identified by the Wide Bandwidth Channel Switch subelement. The Randomization Interval field specifies the upper bound of the random delay to be used prior to making the measurement, in units of TUs. See 11.11.3. The Measurement Duration field is set to the preferred or mandatory duration of the requested measurement, in units of TUs. See 11.11.4. The Optional Subelements field contains zero or more subelements. The subelement format and ordering of subelements are defined in 9.4.3. The Subelement ID field values for the defined subelements are shown in Table 9-83. Table 9-83â€”Optional subelement IDs for Channel Load request Subelement ID Name Extensible 0 Reserved 1 Channel Load Reporting Yes 2â€“162 Reserved 163 Wide Bandwidth Channel Switch Yes 164â€“220 Reserved 221 Vendor Specific 222â€“255 Reserved The Channel Load Reporting subelement indicates the condition for issuing a Channel Load report. The Channel Load Reporting subelement data field format is shown in Figure 9-153 and contains a 1-octet Reporting Condition subfield and a 1-octet Channel Load Reference Value subfield. The Reporting Condition subfield is described in Table 9-84. The Channel Load Reference value is a Channel Load value as defined in 11.11.9.3 and is the reference value for the indicated reporting condition. Reporting Channel Load Condition Reference Value Octets: 1 1 Figure 9-153â€”Channel Load Reporting data field format 808 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-84â€”Reporting Condition subfield for Channel Load report Condition for report to be issued Reporting Condition Report to be issued after each measurement (default, used when the Channel 0 Load Reporting subelement is not included in the Channel Load request). Report to be issued when the measured Channel Load is greater than or equal to 1 the reference value. Report to be issued when the measured Channel Load is less than or equal to the 2 reference value. Reserved 3â€“255 The Wide Bandwidth Channel Switch subelement has the same format as the corresponding element (see 9.4.2.161), with the constraint that the New Channel Width field indicates an 80 MHz, 160 MHz, or 80+80 MHz BSS bandwidth. The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26). Multiple Vendor Specific subelements might be included in the list of optional subelements. 9.4.2.21.6 Noise Histogram request The Measurement Request field corresponding to a Noise Histogram request is shown in Figure 9-154. Operating Channel Randomization Measurement Optional Class Number Interval Duration Subelements Octets: 1 1 2 2 variable Figure 9-154â€”Measurement Request field format for Noise Histogram request If the Wide Bandwidth Channel Switch subelement is not included, the Operating Class field indicates the operating class that identifies the channel set for which the measurement request applies. The Country, Operating Class, and Channel Number fields together specify the channel frequency and spacing for which the measurement request applies. Valid operating classes are listed in Annex E, excluding operating classes that encompass a primary channel but do not identify the location of the primary channel. The Channel Number field indicates the channel number for which the measurement request applies. Channel number is defined within an operating class as shown in Annex E. If the Wide Bandwidth Channel Switch subelement is included, the fields in the Wide Bandwidth Channel Switch subelement indicate the channel for which the measurement request applies, and the Operating Class and Channel Number together specify the primary channel and primary 40 MHz channel within the channel identified by the Wide Bandwidth Channel Switch subelement. The Randomization Interval field specifies the upper bound of the random delay to be used prior to making the measurement, in units of TUs. See 11.11.3. The Measurement Duration field is set to the preferred or mandatory duration of the requested measurement, in units of TUs. See 11.11.4. The Optional Subelements field contains zero or more subelements. The subelement format and ordering of subelements are defined in 9.4.3. 809 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Subelement ID field values for the defined subelements are shown in Table 9-85. Table 9-85â€”Optional subelement IDs for Noise Histogram request Subelement ID Name Extensible 0 Reserved 1 Noise Histogram Reporting Yes 2â€“162 Reserved 163 Wide Bandwidth Channel Switch Yes 164â€“220 Reserved 221 Vendor Specific 222â€“255 Reserved The Noise Histogram Reporting subelement indicates the condition for issuing a Noise Histogram report. The Noise Histogram Reporting subelement data field format is shown in Figure 9-155 and contains a 1- octet Reporting Condition subfield and a 1-octet ANPI Reference Value subfield. The Reporting Condition subfield is described in Table 9-86. The ANPI Reference Value is an ANPI value as defined in 11.11.9.4 and is the reference value for the indicated reporting condition. Reporting ANPI Condition Reference Value Octets: 1 1 Figure 9-155â€”Noise Histogram Reporting data field format Table 9-86â€”Reporting Condition subfield for Noise Histogram report Reporting Condition for report to be issued Condition Report to be issued after each measurement (default, used when Noise Histogram Reporting 0 subelement is not included in a Noise Histogram request). Noise Histogram report to be issued when measured ANPI is greater than or equal to the 1 reference value. Noise Histogram report to be issued when measured ANPI is less than or equal to the 2 reference value. Reserved 3â€“255 The Wide Bandwidth Channel Switch subelement has the same format as the corresponding element (see 9.4.2.161), with the constraint that the New Channel Width field indicates an 80 MHz, 160 MHz, or 80+80 MHz BSS bandwidth. The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26). Multiple Vendor Specific subelements might be included in the list of optional subelements. 810 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.21.7 Beacon request The Measurement Request field corresponding to a Beacon request is shown in Figure 9-156. Operating Channel Randomization Measurement Class Number Interval Duration Octets: 1 1 2 2 Measurement BSSID Optional Mode Subelements Octets: 1 6 variable Figure 9-156â€”Measurement Request field format for Beacon request If the Wide Bandwidth Channel Switch subelement is not included, the Operating Class field indicates the operating class that identifies the channel set for which the measurement request applies. The Country, Operating Class, and Channel Number fields together specify the channel frequency and spacing for which the measurement request applies. Valid operating classes are listed in Annex E. For operating classes that encompass a primary channel but do not identify the location of the primary channel, the Channel Number field value is either 0 or 255; otherwise, the Channel Number field value is 0, 255, or the channel number for which the measurement request applies and is defined within an operating class as shown in Annex E. For operating classes that identify the location of the primary channel, a Channel Number field value of 0 indicates a request to make iterative measurements for all supported channels in the operating class where the measurement is permitted on the channel and the channel is valid for the current regulatory domain. For operating classes that encompass a primary channel but do not identify the location of the primary channel, a Channel Number field value of 0 indicates a request to make iterative measurements for all primary channel positions within all requested and supported channels where the measurement is permitted on the channel and the channel is valid for the current regulatory domain. For operating classes that identify the location of the primary channel, a Channel Number field value of 255 indicates a request to make iterative measurements for all supported channels in the current operating class listed in the latest AP Channel Report received from the serving AP. A request frame is a request to make iterative measurements for all primary channel positions in all channels listed in the frameâ€™s AP Channel Report subelement when all of the following pertain: â€” The operating class indicated by the Operating Class field in that frame encompasses a primary channel. â€” The frame does not identify the location of that primary channel. â€” The value of the frameâ€™s Channel Number field is 255. â€” The channel is supported. â€” The measurement is permitted on the channel. â€” The channel is permitted in the current regulatory domain. If the Wide Bandwidth Channel Switch subelement is included, the fields in the Wide Bandwidth Channel Switch subelement indicate the channel for which the measurement request applies, and the Operating Class and Channel Number fields together specify the primary channel and primary 40 MHz channel within the channel identified by the Wide Bandwidth Channel Switch subelement. 811 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Randomization Interval field specifies the upper bound of the random delay to be used prior to making the measurement, in units of TUs. See 11.11.3. The Measurement Duration field is set to the preferred or mandatory duration of the requested measurement, in units of TUs. See 11.11.4. Measurement Mode indicates the mode to be used for the measurement. The valid measurement modes are listed in Table 9-87. The procedures for each mode are described in 11.11.9.1. Table 9-87â€”Measurement Mode definitions for Beacon request Mode Value Passive 0 Active 1 Beacon Table 2 Reserved 3â€“255 The BSSID field indicates the BSSID of the BSS(s) for which a beacon report is requested. When requesting beacon reports for all BSSs on the channel, the BSSID field contains the wildcard BSSID; otherwise the BSSID field contains a specific BSSID for a single BSS. The Optional Subelements field contains zero or more subelements. The subelement format and ordering of subelements are defined in 9.4.3. The Subelement ID field values for the defined subelements are shown in Table 9-88. Table 9-88â€”Optional subelement IDs for Beacon request Subelement ID Name Extensible 0 SSID 1 Beacon Reporting Yes 2 Reporting Detail Yes 3â€“9 Reserved 10 Request 11 Extended Request 12â€“50 Reserved 51 AP Channel Report 52â€“162 Reserved 163 Wide Bandwidth Channel Switch Yes 164â€“220 Reserved 221 Vendor Specific 222â€“255 Reserved 812 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The SSID subelement indicates the ESS(s) or IBSS(s) for which a beacon report is requested. When SSID is not included in a Beacon request, the default â€œwildcard SSIDâ€ is used; otherwise the SSID is included in the Beacon request and contains a specific SSID for a single ESS or IBSS. The wildcard SSID is used to represent all possible SSIDs. The SSID element is described in 9.4.2.2. The Beacon Reporting subelement indicates the condition for issuing a Beacon report. The Beacon Reporting subelement is optionally present in a Beacon request for repeated measurements; otherwise it is not present. The Beacon Reporting subelement data field format is shown in Figure 9-157 and contains a 1- octet Reporting Condition subfield and a 1-octet Threshold/Offset Reference subfield. The Reporting Condition subfield is described in Table 9-89. The Threshold/Offset Reference subfield contains either the threshold value or the offset value to be used for conditional reporting. For Reporting Condition subfield 1 and 2, the threshold value is a logarithmic function of the received signal power, as defined 9.4.2.38. For Reporting Condition subfield 3 and 4, the threshold value is a logarithmic function of the signal-to-noise ratio, as described in 9.4.2.41. For Reporting Condition subfield 5 to 10, the offset value is an 8-bit 2s complement integer in units of 0.5 dBm. The indicated reporting condition applies individually to each measured Beacon, Measurement Pilot, or Probe Response frame. Reporting conditions are further described in 11.11.9.1. Reporting Threshold/Offset Condition Reference Octets: 1 1 Figure 9-157â€”Beacon Reporting data field format Table 9-89â€”Reporting Condition subfield for Beacon report Condition for report to be issued in Repeated Measurement Reporting Condition Report to be issued after each measurement (default, used when the Beacon 0 Reporting subelement is not included in a Beacon request). The measured RCPI level is greater than the threshold value contained in the 1 Threshold/Offset Reference. The measured RCPI level is less than the threshold value contained in the Threshold/ 2 Offset Reference. The measured RSNI level is greater than the threshold value contained in the 3 Threshold/Offset Reference. The measured RSNI level is less than the threshold value contained in the Threshold/ 4 Offset Reference. The measured RCPI level is greater than a threshold defined by an offset from the 5 serving APâ€™s reference RCPI, where the offset value is contained in the Threshold/ Offset Reference. The measured RCPI level is less than a threshold defined by an offset from the 6 serving APâ€™s reference RCPI, where the offset value is contained in the Threshold/ Offset Reference. The measured RSNI level is greater than a threshold defined by an offset from the 7 serving APâ€™s reference RSNI, where the offset value is contained in the Threshold/ Offset Reference. The measured RSNI level is less than a threshold defined by an offset from the 8 serving APâ€™s reference RSNI, where the offset value is contained in the Threshold/ Offset Reference. 813 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-89â€”Reporting Condition subfield for Beacon report (continued) Condition for report to be issued in Repeated Measurement Reporting Condition The measured RCPI level is in a range bound by the serving APâ€™s reference RCPI 9 and an offset from the serving APâ€™s reference RCPI, where the offset value is contained in the Threshold/Offset Reference. The measured RSNI level is in a range bound by the serving APâ€™s reference RSNI 10 and an offset from the serving APâ€™s reference RSNI, where the offset value is contained in the Threshold/Offset Reference. Reserved 11â€“255 The Reporting Detail subelement contains a 1-octet Reporting Detail data field that defines the level of detail per AP to be reported to the requesting STA. The Reporting Detail values are defined in Table 9-90. Table 9-90â€”Reporting Detail values Level of detail requested Reporting Detail No fixed-length fields or elements 0 All fixed-length fields and any requested elements in the Request element if present 1 All fixed-length fields and elements (default, used when Reporting Detail subelement 2 is not included in a Beacon request) Reserved 3â€“255 The indicated reporting detail applies individually to each measured Beacon, Measurement Pilot, or Probe Response frame. If the Reporting Detail equals 1, a Request element is optionally present in the optional subelements field. If included, the Request element lists the Element IDs of the elements requested to be reported in the Reported Frame Body of the Beacon report. The Wide Bandwidth Channel Switch subelement has the same format as the corresponding element (see 9.4.2.161) with the constraint that the New Channel Width field indicates an 80 MHz, 160 MHz, or 80+80 MHz BSS bandwidth. The Request, Extended Request, AP Channel Report, and Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.10, 9.4.2.11, 9.4.2.36, and 9.4.2.26, respectively). Multiple AP Channel Report and Vendor Specific subelements can be included in the list of optional subelements. An AP Channel Report subelement containing an operating class with an 80+ behavior limit (as defined in Annex E) is interpreted in conjunction with following AP Channel Report elements as defined in 11.11.9.1. If one or more AP Channel Report elements are included, they indicate that iterative measurements are requested first on the channel(s) indicated by the Operating Class and Channel Number fields included in the Beacon request, and second on the channel(s) indicated by the Operating Class and Channel List fields of each AP Channel Report element included in the Beacon request. The procedures for iterative measurements on multiple channels are described in 11.11.9.1. 9.4.2.21.8 Frame request The Measurement Request field corresponding to a Frame request is shown Figure 9-158. 814 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Frame Operating Channel Randomization Measurement Request MAC Optional Class Number Interval Duration Address subelements Type Octets: 1 1 2 2 1 6 variable Figure 9-158â€”Measurement Request field format for Frame request If the Wide Bandwidth Channel Switch subelement is not included, the Operating Class field indicates the operating class that identifies the channel set for which the measurement request applies. The Country, Operating Class, and Channel Number fields together specify the channel frequency and spacing for which the measurement request applies. Valid operating classes are listed in Annex E, excluding operating classes that encompass a primary channel but do not identify the location of the primary channel. The Channel Number field indicates the channel number for which the measurement request applies. Channel number is defined within an operating class as shown in Annex E. If the Wide Bandwidth Channel Switch subelement is included, the fields in the Wide Bandwidth Channel Switch subelement indicate the channel for which the measurement request applies, and the Operating Class and Channel Number fields together specify the primary channel and primary 40 MHz channel within the channel identified by the Wide Bandwidth Channel Switch subelement. The Randomization Interval field specifies the upper bound of the random delay to be used prior to making the measurement, in units of TUs. See 11.11.3. The Measurement Duration field is set to the preferred or mandatory duration of the requested measurement, in units of TUs. See 11.11.4. The Frame Request Type indicates which subelements are requested in the Frame report. The value of 1 signifies that a Frame Count Report is requested. The values 0 and 2 to 255 are reserved. If the MAC Address field is the broadcast address, then all Data or Management frames are counted toward the Frame report generated in response to this Frame request. For other MAC addresses, only frames matching this MAC address as the Transmitter Address are counted toward the Frame report generated in response to this Frame request. The Optional Subelements field contains zero or more subelements. The subelement format and ordering of subelements are defined in 9.4.3. The Subelement ID field values for the defined subelements are shown in Table 9-91. Table 9-91â€”Optional subelement IDs for Frame request Subelement ID Name Extensible 0â€“162 Reserved 163 Wide Bandwidth Yes Channel Switch 164â€“220 Reserved 221 Vendor Specific 222â€“255 Reserved 815 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Wide Bandwidth Channel Switch subelement has the same format as the corresponding element (see 9.4.2.161), with the constraint that the New Channel Width field indicates an 80 MHz, 160 MHz, or 80+80 MHz BSS bandwidth. The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26). Multiple Vendor Specific subelements are optionally present in the list of optional subelements. 9.4.2.21.9 STA Statistics request The Measurement Request field corresponding to a STA Statistics request is shown in Figure 9-159. Peer MAC Randomization Measurement Group Identity Optional Address Interval Duration Subelements Octets: 6 2 2 1 variable Figure 9-159â€”Measurement Request field format for STA Statistics request The Peer MAC Address field is the RA or TA MAC address for the frame statistics of this measurement. The Randomization Interval field specifies the upper bound of the random delay to be used prior to making the measurement, in units of TUs. See 11.11.3. The Measurement Duration field is set to the duration of the requested measurement in TUs except when triggered reporting is used. When triggered reporting is used, the measurement duration is 0. Group Identity indicates the requested statistics group according to Table 9-92. Table 9-92â€”Group Identity for a STA Statistics request Statistics Group Name Group Identity STA Counters from dot11CountersTable 0 STA Counters from dot11MacStatistics group 1 QoS STA Counters for UP0 from dot11QosCountersTable 2 QoS STA Counters for UP1 from dot11QosCountersTable 3 QoS STA Counters for UP2 from dot11QosCountersTable 4 QoS STA Counters for UP3 from dot11QosCountersTable 5 QoS STA Counters for UP4 from dot11QosCountersTable 6 QoS STA Counters for UP5 from dot11QosCountersTable 7 QoS STA Counters for UP6 from dot11QosCountersTable 8 QoS STA Counters for UP7 from dot11QosCountersTable 9 BSS Average Access Delays as described in 9.4.2.39 and 9.4.2.44 10 STA Counters from dot11CountersGroup3 (A-MSDU) 11 STA Counters from dot11CountersGroup3 (A-MPDU) 12 STA Counters from dot11CountersGroup3 (BlockAckReq, Channel Width, PSMP) 13 STA Counters from dot11CountersGroup3 (RD, dual CTS, L-SIG TXOP protection) 14 816 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-92â€”Group Identity for a STA Statistics request (continued) Statistics Group Name Group Identity STA Counters from dot11CountersGroup3 (beamforming and STBC) 15 RSNA Counters 16 Reserved 17â€“255 The Optional Subelements field contains zero or more subelements. The subelement format and ordering of subelements are defined in 9.4.3. The Subelement ID field values for the defined subelements are shown in Table 9-93. Table 9-93â€”Optional subelement IDs for STA Statistics request Subelement ID Name Extensible 0 Reserved 1 Triggered Reporting 2â€“220 Reserved 221 Vendor Specific 222â€“255 Reserved The Triggered Reporting subelement is used to specify trigger conditions and thresholds for triggered STA Statistics measurements. It is present when setting up triggered reporting from STA Counters, QoS STA Counters, or RSNA Counters; see 11.11.9.5. The format of the Triggered Reporting subelement for STA Counters is shown in Figure 9-160. The fields marked as optional are only present if the appropriate bit in the STA Counter Trigger Condition field is 1. STA Counter dot11FailedCount dot11FCS Measurement ErrorCount Count Trigger Timeout Trigger Threshold Threshold Condition (optional) (optional) Octets: 4 2 2 0 or 4 0 or 4 dot11Multiple dot11Frame dot11RTS dot11Ack dot11RetryCount RetryCount DuplicateCount FailureCount FailureCount Threshold Threshold Threshold Threshold Threshold (optional) (optional) (optional) (optional) (optional) Octets: 0 or 4 0 or 4 0 or 4 0 or 4 0 or 4 Figure 9-160â€”Triggered Reporting subelement for STA Counters The value in the Measurement Count field specifies the number of MSDUs or MPDUs transmitted and/or received by the STA that are to be used to determine if one or more of the trigger conditions have been met. The Trigger Timeout field contains a value in units of 100 TUs during which a measuring STA does not generate further triggered STA Statistics reports after a trigger condition has been met. 817 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The STA Counter Trigger Condition field specifies trigger values used when requesting triggered STA Statistics reporting. The format of the STA Counter Trigger Condition field is shown in Figure 9-161. B0 B1 B2 B3 dot11FailedCount dot11FCSError dot11Multiple dot11Frame Count RetryCount DuplicateCount Bits 1 1 1 1 B4 B5 B6 B7 B15 dot11RTS dot11Ack dot11RetryCount Reserved FailureCount FailureCount Bits 1 1 1 9 Figure 9-161â€”STA Counter Trigger Condition field For each bit in the STA Counter Trigger Condition field that is 1, a corresponding threshold value exists (defined in Figure 9-160) in the Triggered Reporting subelement for STA Counters. With this, the STA Statistics request indicates that a STA Statistics report be generated when the corresponding STA counter defined in 9-205 and 9-206 (in 9.4.2.22.9) exceeds the value of the specified threshold, within the total number of MSDUs or MPDUs indicated in the Measurement Count field. See 11.11.9.5. One or more trigger conditions are set with specified thresholds. In the triggered STA Statistics request, the value of the Group Identity field is either 0 or 1. When the Group Identity field value of the triggered STA Statistics request is 0, B2â€“B6 in the STA Counter Trigger Condition field are set to 0. When the group identity of the triggered STA Statistics request is 1, B0 and B1 in the STA Counter Trigger Condition field are set to 0. The format of the Triggered Reporting subelement for QoS STA Counters is shown in Figure 9-162. The fields marked as optional are only present if the appropriate bit in the QoS STA Counter Trigger Condition subfield is 1. dot11QoSFailed dot11QoSRetry Measurement QoS STA Count Count Trigger Timeout Counter Trigger Count Condition Threshold Threshold (optional) (optional) Octets: 4 2 2 0 or 4 0 or 4 dot11QoSMultiple dot11QoSFrame dot11QoSRTSC dot11QoSAck dot11QoSDisca ount RetryCount DuplicateCount Failure FailureCount rdedCount Threshold Threshold Threshold Threshold (optional) (optional) Threshold (optional) (optional) (optional) Octets: 0 or 4 0 or 4 0 or 4 0 or 4 0 or 4 Figure 9-162â€”Triggered Reporting subelement for QoS STA Counters The UP of the QoS STA Counters for triggered QoS Statistics measurement is determined by the group identity of the Measurement Request field for a STA Statistics request as defined in 9-92. The value in the Measurement Count field specifies the number of MSDUs or MPDUs transmitted and/or received by the STAs that are to be used to determine if one or more of the trigger conditions have been met. The Trigger Timeout field contains a value in units of 100 TUs during which a measuring STA does not generate further triggered STA Statistics reports after a trigger condition has been met. 818 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The QoS STA Counter Trigger Condition field specifies reporting triggers when requesting triggered STA Statistics reporting. The format of the QoS STA Counter Trigger Condition field is shown in Figure 9-163. B0 B1 B2 B3 dot11QoS dot11QoS dot11QoSMultiple dot11QoSFrame FailedCount RetryCount RetryCount DuplicateCount Bits: 1 1 1 1 B4 B5 B6 B7-B15 dot11QoSRTS dot11QoSAck dot11QoS Reserved FailureCount FailureCount DiscardedCount Bits: 1 1 1 9 Figure 9-163â€”QoS STA Counter Trigger Condition field For each bit in the QoS STA Counter Trigger Condition field that is 1, a corresponding threshold value exists (defined in Figure 9-162) in the Triggered Reporting subelement for QoS STA Counters. With this, the STA Statistics request indicates that a STA Statistics report be generated when the corresponding QoS STA counter defined in Figure 9-207 (in 9.4.2.22.9) exceeds the value of the specified threshold, within the total number of MSDUs or MPDUs indicated in the Measurement Count field. See 11.11.9.5. One or more trigger conditions are set with specified thresholds. The format of the Triggered Reporting subelement for RSNA Counters is shown in Figure 9-164. The fields marked as optional are only present if the appropriate bit in the RSNA Trigger Condition subfield is 1. dot11RSNAStats dot11RSNA Measurement Trigger RSNA Counter CMACICVErrors StatsCMACRepla Count Timeout Trigger Condition Threshold ys Threshold (optional) (optional) Octets: 4 2 2 0 or 4 0 or 4 dot11RSNA StatsRobustMgmt dot11RSNAStats dot11RSNAStats dot11RSNAStats dot11RSNAStats TKIPICVErrors TKIPReplays CCMPDecryptErr CCMPReplays CCMPReplays Threshold Threshold ors Threshold Threshold Threshold (optional) (optional) (optional) (optional) (optional) Octets: 0 or 4 0 or 4 0 or 4 0 or 4 0 or 4 Figure 9-164â€”Triggered Reporting subelement for RSNA Counters The value in the Measurement Count field specifies the number of MPDUs transmitted and/or received by the STA that are to be used to determine if one or more of the trigger conditions have been met. The Trigger Timeout field contains a value in units of 100 TUs during which a measuring STA does not generate further triggered STA Statistics reports after a trigger condition has been met. The RSNA Counter Trigger Condition field specifies reporting triggers when requesting triggered STA Statistics reporting. The format of the RSNA Trigger Condition field is shown in Figure 9-165. 819 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B0 B1 B2 B3 dot11RSNAStats dot11RSNAStats dot11RSNA RobustMgmt dot11RSNAStats CMACICVErrors StatsCMACReplays TKIPICVErrors CCMPReplays Bits: 1 1 1 1 B4 B5 B6 B7 B15 dot11RSNAStats dot11RSNAStats dot11RSNAStats TKIPReplays CCMPDecryptErrors CCMPReplays Reserved Bits: 1 1 1 9 Figure 9-165â€”RSNA Trigger Condition field For each bit in the RSNA Trigger Condition field that is 1, a corresponding threshold value exists (defined in Figure 9-164) in the Triggered Reporting subelement for RSNA Counters. With this, the STA Statistics request indicates that a STA Statistics report be generated when the corresponding RSNA counter defined in Figure 9-209 (in 9.4.2.22.9) exceeds the value of the specified threshold, within the total number of MPDUs indicated in the Measurement Count field. See 11.11.9.5. One or more trigger conditions are set with specified thresholds. The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26). Multiple Vendor Specific subelements are optionally present in the list of optional subelements. 9.4.2.21.10 LCI request (Location configuration information request) The Measurement Request field corresponding to an LCI request is shown in Figure 9-166. Location Subject Optional Subelements Octets: 1 variable Figure 9-166â€”Measurement Request field format for LCI request The Location Subject field of an LCI request is a single octet. See Table 9-94. Table 9-94â€”Location Subject field definition Value Location Subject 0 Location Subject Local 1 Location Subject Remote 2 Location Subject Third Party 3â€“255 Reserved The term Local refers to the location of the requesting STA, and Remote refers to the location of the reporting STA. 820 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NOTEâ€”A measurement request with its Location Subject value Location Subject Local is used by a requesting STA to obtain its own location, asking â€œWhere am I?â€ The Measurement Request with its Location Subject value Location Subject Remote is used by a requesting STA to obtain the location of the reporting STA, asking â€œWhere are you?â€ The Optional Subelements field contains zero or more subelements. The subelement format and ordering of subelements are defined in 9.4.3. The Subelement ID field values for the defined subelements are shown in Table 9-95. Table 9-95â€”Optional subelement IDs for LCI request Subelement ID Name Extensible 0 Reserved 1 Azimuth Request Yes 2 Originator Requesting STA MAC Address 3 Target MAC Address 4 Maximum Age Yes 5â€“220 Reserved 221 Vendor Specific 222â€“255 Reserved The Azimuth Request subelement is present when requesting azimuth information. The Azimuth Request subelement is as shown in Figure 9-167. Subelement ID Length Azimuth Request Octets: 1 1 1 Figure 9-167â€”Azimuth Request subelement format The Subelement ID field is defined in Table 9-95. The Length field is defined in 9.4.3. The Azimuth Request field of an Azimuth Request subelement is shown in Figure 9-168. B0 B3 B4 B5 B7 Azimuth Azimuth Resolution Reserved Requested Type Bits: 4 1 3 Figure 9-168â€”Azimuth Request field 821 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Azimuth Resolution Requested is the number of valid most significant bits requested for the fixed-point value of Azimuth, reported in integer degrees. Values above 9 are reserved. Azimuth Type (bit 4) is set to 1 to request a report of the Azimuth of radio reception and is set to 0 to request a report of the Azimuth of front surface of the reporting STA. NOTEâ€”A geographic feature is an abstraction of a real-world phenomenon; it is a geographic feature if it is associated with a location relative to the Earth. The designation of a horizontal plane is relative to the Earth. The designation of the â€œfront surfaceâ€ of a station is arbitrary, but refers to an orientable surface (possessing a centerline) of the station. It is common to use a direction cosine matrix to convert from one coordinate system to another, i.e., body-centered coordinates to earth-centered coordinates. The Originator Requesting STA MAC Address subelement contains the MAC address of the STA request- ing the Location Information and it is present whenever the Location Subject field is set to 2. The format of the Originator Requesting STA MAC Address subelement is shown in Figure 9-169. Originator Subelement ID Length Requesting STA MAC Address Octets: 1 1 6 Figure 9-169â€”Originator Requesting STA MAC Address subelement format The Target MAC Address subelement contains the MAC address of the STA whose Location Information is requested and it is present whenever the Location Subject field is set to 2. The format of the Target MAC address subelement is shown in Figure 9-170. Target MAC Subelement ID Length Address Octets: 1 1 6 Figure 9-170â€”Target MAC Address subelement format The Maximum Age subelement indicates the maximum age of the requested LCI. The format of the Maximum Age subelement is defined in Figure 9-171. The absence of a Maximum Age subelement indicates that an LCI determined at or after the LCI request is received is requested. Subelement ID Length Maximum Age Octets: 1 1 2 Figure 9-171â€”Format of Maximum Age subelement The Length field is defined in 9.4.3. The Maximum Age field of a Maximum Age subelement indicates the maximum elapsed time between when an LCI is determined and when an LCI request is received, within which the LCI satisfies the LCI request. The Maximum Age field is encoded as an unsigned integer with units of 0.1 s. The value of 0 is reserved. The value of 65 535 indicates that any LCI age is acceptable. The Vendor Specific subelement has the same format as the Vendor Specific element (see 9.4.2.26). Multiple Vendor Specific subelements are optionally present in the list of optional subelements. 822 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.21.11 Transmit Stream/Category Measurement request The Transmit Stream/Category Measurement applies to TIDs for traffic streams associated with TSPECs and also to TIDs for traffic categories for QoS traffic without TSPECs. The Measurement Request field cor- responding to a Transmit Stream/Category Measurement request is shown in Figure 9-172. Randomization Measurement Peer STA Traffic Bin 0 Range Optional Interval Duration Address Identifier Subelements Octets: 2 2 6 1 1 variable Figure 9-172â€”Measurement Request field format for Transmit Stream/Category Measurement Request The Randomization Interval field is set to the maximum random delay in the measurement start time, in units of TUs. The use of the Randomization Interval field is described in 11.11.3. When requesting a triggered Transmit Stream/Category Measurement, the randomization interval is not used and the Randomization Interval field is reserved. See 11.11.9.8. The Measurement Duration is set to the duration of the requested measurement, in units of TUs except when setting up a triggered QoS measurement, when it is not used and is set to 0. The Peer STA Address contains a MAC address indicating the RA in the MSDUs to be measured. The Traffic Identifier field contains the TID subfield as shown in Figure 9-173. B0 B3 B4 B7 Reserved TID Bits: 4 4 Figure 9-173â€”Traffic Identifier field The TID subfield indicates the TC or TS for which traffic is to be measured. Bin 0 Range indicates the delay range of the first bin (Bin 0) of the Transmit Delay Histogram, in units of TUs. The Bin 0 Range value is used to calculate the delay ranges of the other 5 bins making up the histogram. The delay range for each bin increases in a binary exponential fashion as described in 9.4.2.22.11. The Optional Subelements field contains zero or more subelements. The subelement format and ordering of subelements are defined in 9.4.3. The Subelement ID field values for the defined subelements are shown in Table 9-96. 823 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-96â€”Optional subelement IDs for Transmit Stream/Category Measurement Request Subelement ID Name Extensible 0 Reserved 1 Triggered Reporting Yes 2â€“220 Reserved 221 Vendor Specific 222â€“255 Reserved The Triggered Reporting subelement is used to specify measurement trigger thresholds. It is present only if requesting triggered transmit stream/category measurement reporting. The Triggered Reporting subelement format is shown in Figure 9-174. Subelement ID Length Triggered Reporting Octets: 1 1 6 Figure 9-174â€”Triggered Reporting subelement format The Subelement ID field is defined in Table 9-96. The Length field is defined in 9.4.3. The Triggered Reporting field is as shown in Figure 9-175. Consecutive Trigger Average Error Error Delay Measurement Trigger Conditions Threshold Threshold Count Timeout Threshold Octets: 1 1 1 1 1 1 Figure 9-175â€”Triggered Reporting field Trigger Conditions is a bit-field that specifies reporting triggers when requesting a triggered transmit stream/ category measurement. The format of the Trigger Conditions bit-field is shown in Figure 9-176. B0 B1 B2 B3 B7 Average Consecutive Delay Reserved Bits: 1 1 1 5 Figure 9-176â€”Trigger Conditions bit-field â€” Average is set to 1 to request that a Transmit Stream/Category Measurement report be generated when the number of MSDUs for the TC or TS given by the TID that are discarded out of the number of preceding MSDUs specified in Measurement Count is greater than or equal to the value given in Average Error Threshold. MSDUs discarded due to the number of transmit attempts exceeding 824 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11ShortRetryLimit or dot11LongRetryLimit, or due to the MSDU lifetime having been reached, are counted. â€” Consecutive is set to 1 to request that a Transmit Stream/Category Measurement report be generated when the number of MSDUs for the TC or TS given by the TID that are discarded in succession is greater than or equal to the value given in Consecutive Error Threshold. MSDUs discarded due to the number of transmit attempts exceeding dot11ShortRetryLimit or dot11LongRetryLimit, or due to the MSDU lifetime having been reached, are counted. â€” Delay is set to 1 to request that a Transmit Stream/Category Measurement report be generated when the number of consecutive MSDUs for the TC or TS given by the TID that experience a transmit delay greater than or equal to the value specified in the Delay Threshold subfield is greater than or equal to the value given in Delayed MSDU Count. Delay is measured from the time the MSDU is passed to the MAC until the point at which the entire MSDU has been successfully transmitted, including receipt of the final Ack frame from the peer STA if the QoSAck service class is being used. The Average Error Threshold field contains a value representing the number of discarded MSDUs to be used as the threshold value for the Average trigger condition. The field is reserved if the Average Error Threshold subfield of the Trigger Conditions bit-field is 0. The Consecutive Error Threshold field contains a value representing the number of discarded MSDUs to be used as the threshold value for the consecutive trigger condition. The field is reserved if the Consecutive Error Threshold subfield of the Trigger Conditions bit-field is 0. The Delay Threshold field contains two subfields as shown in Figure 9-177. The Delay Threshold field is reserved if the Delay Threshold subfield of the Trigger Conditions bit-field is 0. B0 B1 B2 B7 Delayed MSDU Range Delayed MSDU Count Bits: 2 6 Figure 9-177â€”Delay Threshold subfield Delayed MSDU Range contains a value representing the MSDU transmit delay at or above which an MSDU is counted toward the Delayed MSDU Count threshold. Delayed MSDU Range is encoded as a value representing the lower bound of a bin in the Transmit Delay Histogram as shown in Table 9-97. The Transmit Delay Histogram is defined in 9.4.2.22.11. Table 9-97â€”Delayed MSDU Range Definitions Delayed MSDU Range Condition 0 Transmit Delay = Lower Bound of Bin 2 1 Transmit Delay = Lower Bound of Bin 3 2 Transmit Delay = Lower Bound of Bin 4 3 Transmit Delay = Lower Bound of Bin 5 Delayed MSDU Count contains a value representing the number of MSDUs to be used as the threshold value for the delay trigger condition. 825 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Measurement Count field contains a number of MSDUs. This value is used to calculate an average discard count for the average trigger condition. It is also used in place of measurement duration in determining the scope of the reported results when a report is triggered; see 11.11.9.8. The Trigger Timeout field contains a value, in units of 100 TU, during which a measuring STA does not generate further triggered transmit stream/category measurement reports after a trigger condition has been met. See 11.11.9.8. The Vendor Specific subelement has the same format as the Vendor Specific element (see 9.4.2.26). Multiple Vendor Specific subelements are optionally present in the list of optional subelements. 9.4.2.21.12 Measurement Pause request The Measurement Request field corresponding to a Measurement Pause request is shown in Figure 9-178. The Measurement Pause request cannot be processed in parallel with any other measurement request. See 11.11.9.7. Pause Time Optional Subelements Octets: 2 variable Figure 9-178â€”Measurement Request field format for Measurement Pause request The Pause Time field contains a number between 1 and 65 535 representing the time period for which measurements are suspended or paused. The time unit for the Pause Time is 10 TUs. The Pause Time value 0 is reserved. Measurement Pause requests are used to provide time delays between the execution times of Measurement Request elements in a Measurement Request frame. The Optional Subelements field contains zero or more subelements. The subelement format and ordering of subelements are defined in 9.4.3. The Subelement ID field values for the defined subelements are shown in Table 9-98. Table 9-98â€”Optional subelement IDs for Measurement Pause request Subelement ID Name Extensible 0â€“220 Reserved 221 Vendor Specific 222â€“255 Reserved The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26). Mul- tiple Vendor Specific subelements are optionally present in the list of optional subelements. 826 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.21.13 Multicast Diagnostics request The Measurement Request field corresponding to a Multicast Diagnostics request is shown in Figure 9-179. The response to a Multicast Diagnostics request is a Multicast Diagnostics report. Randomization Measurement Group MAC Multicast Triggered Optional Reporting Interval Duration Address (optional) Subelements Octets: 2 2 6 0 or 5 variable Figure 9-179â€”Measurement Request field format for a Multicast Diagnostics request The Randomization Interval field is the upper limit of random delay before the measurement begins, expressed in TUs. The use of the Randomization Interval field is described in 11.12.3. When requesting a triggered multicast diagnostic report, the Randomization Interval field is reserved. The Measurement Duration field is the duration of the requested measurement, expressed in TUs. When requesting a triggered multicast diagnostic report, the Measurement Duration field is reserved. A Group MAC Address field with the LSB of the first octet set to 1 contains the MAC address of the group addressed frames to which the measurement request relates. A Group MAC Address field with the LSB of the first octet set to 0 indicates that all group addressed frames, apart from the broadcast MAC address, are requested. The Multicast Triggered Reporting field is used to specify trigger conditions and thresholds. It is present only when requesting triggered multicast diagnostic reporting. The format of Multicast Triggered Reporting subelement is as shown in Figure 9-180. Subelement ID Length Multicast Trigger Inactivity Reactivation Condition Timeout Delay Octets: 1 1 1 1 1 Figure 9-180â€”Multicast Triggered Reporting subelement format The Multicast Trigger Condition field specifies reporting triggers for triggered management diagnostic reporting. The format of the Multicast Trigger Condition field is shown in Figure 9-181. B0 B1 B7 Inactivity Timeout Reserved Request Bits: 1 7 Figure 9-181â€”Multicast Trigger Condition field The Inactivity Timeout Request field is 1 to request that a multicast triggered report be generated when no group addressed frames with the monitored group address are received in a time equal to the value given in the Inactivity Timeout field. The Inactivity Timeout Request field is 0 when a multicast reception timeout is not requested. The Inactivity Timeout field contains a time value in units of 100 TUs to be used as the threshold value for the inactivity timeout trigger condition. 827 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Reactivation Delay field contains a value in units of 100 TUs during which a measuring STA does not generate further multicast triggered reports after a trigger condition has been met. The Optional Subelements field contains zero or more subelements. The subelement format and ordering of subelements are defined in 9.4.3. The Subelement ID field values for the defined subelements are shown in Table 9-99. Table 9-99â€”Optional subelement IDs for STA Multicast Diagnostics request Subelement ID Name Extensible 0 Reserved 1 Multicast Triggered Reporting 2â€“220 Reserved 221 Vendor Specific 222â€“255 Reserved The Vendor Specific subelement has the same format as the Vendor Specific element (see 9.4.2.26). The use of Multicast Diagnostics request is defined in 11.11.19. 9.4.2.21.14 Location Civic request The Measurement Request field corresponding to a Location Civic request is shown in Figure 9-182. The response to a Location Civic request is a Location Civic report. Location Location Civic Location Location Optional Subject Type Service Interval Service Interval Subelements Units Octets: 1 1 1 2 variable Figure 9-182â€”Location Civic Request field format The Location Subject field is a single octet and is defined in Table 9-94. The Civic Location Type field contains the format of location information in the Location Civic report, as indicated in Table 9-100. When the Civic Location Type value is Vendor Specific, a Vendor Specific subelement is included in the Optional Subelements field that identifies the Organization Identifier corresponding to the Civic Location Type field. 828 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-100â€”Civic Location Type field values Civic Location Type Name Description field value 0 IETF RFC 4776 Starting at the country code field (i.e., excluding the GEOCONF_CIVIC/ OPTION_GEOCONF_CIVIC, N/option-len and what fields); includes all subsequent RFCs that define additional civic address Types 1 Vendor Specific 2â€“255 Reserved The Location Service Interval Units field contains the units for the Location Service Interval field, as indicated in Table 9-101. Table 9-101â€”Location Service Interval Units Location Service Description Interval Units value 0 Seconds 1 Minutes 2 Hours 3â€“255 Reserved The Location Service Interval field is the time interval, expressed in the units indicated in the Location Service Interval Units field, at which the STA requests to receive Location Civic reports. A Location Service Interval of 0 indicates that only a single Location Civic report is requested. The Optional Subelements field contains zero or more subelements. The subelement format and ordering of subelements are defined in 9.4.3. The Subelement ID field values for the defined subelements are shown in Table 9-102. Table 9-102â€”Optional subelement IDs for Location Civic request Subelement ID Name Extensible 0 Reserved 1 Originator Requesting STA MAC Address 2 Target MAC Address 3â€“220 Reserved 221 Vendor Specific 222â€“255 Reserved 829 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Originator Requesting STA MAC Address subelement contains the MAC address of the STA requesting for the Location Information and it is present whenever the Location Subject field is set to 2. The format of the Originator Requesting STA MAC Address subelement is shown in Figure 9-169. The Target MAC Address subelement contains the MAC address of the STA whose Location Information is requested and it is present whenever the Location Subject field is set to 2. The format of the Target MAC address subelement is shown in Figure 9-170. The Vendor Specific subelement has the same format as the Vendor Specific element (see 9.4.2.26). 9.4.2.21.15 Location Identifier request The Measurement Request field corresponding to a Location Identifier request is shown in Figure 9-183. The response to a Location Identifier request is a Location Identifier report. Location Location Location Optional Service Interval Subject Units Service Interval Subelements Octets: 1 1 2 variable Figure 9-183â€”Location Identifier request field format The Location Subject field is a single octet and is defined in Table 9-94. The Location Service Interval Units field is defined in Table 9-101. The Location Service Interval field is the time interval, expressed in the units indicated in the Location Service Interval Units field, at which the STA requests to receive Location Identifier reports. A Location Service Interval of 0 indicates that only a single Location Identifier report is requested. The Optional Subelements field contains zero or more subelements. The subelement format and ordering of subelements are defined in 9.4.3. The Subelement ID field values for the defined subelements are shown in Table 9-103. Table 9-103â€”Optional subelement IDs for Location Identifier request Subelement ID Name Extensible 0 Reserved 1 Originator Requesting STA MAC Address 2 Target MAC Address 3â€“220 Reserved 221 Vendor Specific 222â€“255 Reserved The Originator Requesting STA MAC Address subelement contains the MAC address of the STA requesting the Location Information and it is present whenever the Location Subject field is set to 2. The format of the Originator Requesting STA MAC Address subelement is shown in Figure 9-169. 830 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Target MAC Address subelement contains the MAC address of the STA whose Location Information is requested and it is present whenever the Location Subject field is set to 2. The format of the Target MAC address subelement is shown in Figure 9-170. The Vendor Specific subelement has the same format as the Vendor Specific element (see 9.4.2.26). 9.4.2.21.16 Directional Channel Quality request The Measurement Request field corresponding to a Directional Channel Quality request is shown in Figure 9-184. This Measurement Request is transmitted from a Requesting STA to a Requested STA to perform measurements toward a Target STA. Operating Class Channel Number AID Reserved Measurement Method Octets: 1 1 1 1 1 Measurement Start Time Measurement Duration Number of Time Optional Subelements Blocks Octets: 8 2 1 Variable Figure 9-184â€”Measurement Request field format for Directional Channel Quality request The Operating Class field indicates the channel set for which the measurement request applies. Operating Class and Channel Number together specify the channel frequency and spacing for which the measurement request applies. Valid values of Operating Class are shown in Annex E. Channel Number field indicates the channel number for which the measurement request applies. Channel Number is defined within an Operating Class as shown in Annex E. The AID field indicates the Target STA. The Measurement Method field indicates the method that is to be used by the Requested STA to carry out this measurement request and report back in the measurement report. If this field is set to 0, it indicates ANIPI. If this field is set to 1, it indicates RSNI. Other values are reserved. The Measurement Start Time field is set to the TSF timer at the time at which the requested measurement starts. A value of 0 indicates that the measurement starts immediately. The Measurement Duration field is set to the preferred or mandatory duration of the requested measurement, in units of TUs. See 11.11.4. The Number of Time Blocks field indicates the number of time blocks within the Measurement Duration. The ratio (Measurement Duration/Number of Time Blocks) provides the duration of an individual measurement unit. The Optional Subelements field contains zero or more subelements. The subelement format and ordering of subelements are defined in 9.4.3. The Subelement ID field values for the defined subelements are shown in Table 9-104. 831 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-104â€”Optional subelement IDs for Directional Channel Quality request Subelement ID Name Extensible 0 Reserved 1 Directional Channel Quality Reporting Yes 2â€“220 Reserved 221 Vendor Specific 222â€“255 Reserved The Directional Channel Quality Reporting subelement indicates the condition for issuing a Directional Channel Quality report. Directional Channel Quality Reporting subelement data field format is shown in Figure 9-185 and contains a 1-octet Reporting Condition subfield and a 1-octet Directional Channel Quality Reference Value subfield. The Reporting Condition subfield is described in Table 9-105. The Directional Channel Quality Reference value is a Directional Channel Quality value and is the reference value for the indicated reporting condition. Reporting Directional Channel Condition Quality Reference Value Octets: 1 1 Figure 9-185â€”Directional Channel Quality Reporting data field format Table 9-105â€”Reporting Condition subfield for Directional Channel Quality report Reporting Condition for report to be issued condition Report to be issued after each measurement (default, used when Directional Channel 0 Quality Reporting subelement is not included in Directional Channel Quality Request). Report to be issued when measured ANIPI or RSNI is greater than or equal to the reference 1 value. Report to be issued when measured ANIPI or RSNI is less than or equal to the reference 2 value. Reserved 3â€“255 The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26). Multiple Vendor Specific subelements can be included in the list of Optional Subelements. 9.4.2.21.17 Directional Measurement request The Measurement Request field corresponding to a Directional Measurement request is shown in Figure 9-186. This Measurement Request is transmitted from a Requesting STA to a Requested STA to perform directional channel measurements in all sectored receiving directions. 832 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Measurement Operating Channel Measurement Duration Measurement Class Number Start Time Method per Direction Octets 1 1 8 2 1 Figure 9-186â€”Measurement Request field format for Directional Measurement request Operating Class field indicates the channel set for which the measurement request applies. Operating Class and Channel Number together specify the channel frequency and spacing for which the measurement request applies. Valid values of Operating Class are shown in Annex E. Channel Number field indicates the channel number for which the measurement request applies. Channel Number is defined within an Operating Class as shown in Annex E. The Measurement Start Time field is set to the TSF timer at the time at which the requested measurement starts. A value of 0 indicates that the measurement starts immediately. The Measurement Duration per Direction field is set to the preferred or mandatory duration of the requested measurement in each receiving direction, in units of TUs. The Measurement Method field indicates the method that is to be used by the Requested STA to carry out this measurement request and report back in the measurement report. If this field is set to 0, it indicates ANIPI. If this field is set to 1, it indicates RCPI. If the field is set to 2, it indicates Channel Load. Other values are reserved. 9.4.2.21.18 Directional Statistics request The Measurement Request field corresponding to a Directional Statistics request is shown in Figure 9-187. This Measurement Request is transmitted from a Requesting STA to a Requested STA to perform directional channel measurements in all sectored receiving directions. Measurement Directional Operating Channel Measurement Measurement Class Number Start Time Duration per Method Statistics Direction Bitmap Octets 1 1 8 2 1 1 Figure 9-187â€”Measurement Request field format for Directional Statistics request Operating Class field indicates the channel set for which the measurement request applies. Operating Class and Channel Number together specify the channel frequency and spacing for which the measurement request applies. Valid values of Operating Class are shown in Annex E. Channel Number field indicates the channel number for which the measurement request applies. Channel Number is defined within an Operating Class as shown in Annex E. The Measurement Start Time field is set to the TSF timer at the time at which the requested measurement starts. A value of 0 indicates that the measurement starts immediately. The Measurement Duration per Direction field is set to the preferred or mandatory duration of the requested measurement in each receiving direction, in units of TUs. 833 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Measurement Method field indicates the method that is to be used by the Requested STA to carry out this measurement request and report back in the measurement report. If this field is set to 0, it indicates ANIPI. If this field is set to 1, it indicates RCPI. If the field is set to 2, it indicates Channel Load. Other values are reserved. The Directional Statistics Bitmap field format is shown in Figure 9-188. The Maximum field set to 1 indicates that the maximum measurement result among all directions is expected in the measurement report. The Minimum field set to 1 indicates that the minimum measurement result among all directions is expected in the measurement report. The Average field set to 1 indicates that the average measurement result among all directions is expected in the measurement report. The Variance field set to 1 indicates that the variance of measurement results among all directions is expected in the measurement report. Other bits are reserved. B0 B1 B2 B3 B4 B7 Maximum Minimum Average Variance Reserved Bits: 1 1 1 1 4 Figure 9-188â€”Directional Statistics Bitmap field format 9.4.2.21.19 Fine Timing Measurement Range request The Measurement Request field corresponding to a Fine Timing Measurement Range request is shown in Figure 9-189. Randomization Minimum AP FTM Range Interval Count Subelements Octets: 2 1 variable Figure 9-189â€”Measurement Request field for a Fine Timing Measurement Range request The Randomization Interval field specifies the upper bound of the random delay to be used prior to making the measurement, in units of TUs. See 11.11.3. The Minimum AP Count field specifies the minimum number of FTM ranges between the requested STA and the APs listed in the Neighbor Report Subelements field that are requested. The value 0 and values above 15 are reserved. The FTM Range Subelements field contains one or more subelements. The subelement format and ordering of subelements are defined in 9.4.3. The FTM Range subelements are listed in Table 9-106. The Subelement IDs for subelements in the Fine Timing Measurement Range request are defined in Table 9-106. Table 9-106â€”FTM Range subelement IDs for Fine Timing Measurement Range request Subelement ID Name Extensible 0â€“3 Reserved 4 Maximum Age Yes 5-51 Reserved 834 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-106â€”FTM Range subelement IDs for Fine Timing Measurement Range request (continued) Subelement ID Name Extensible 52 Neighbor Report Subelements 53â€“220 Reserved 221 Vendor Specific 222â€“255 Reserved The FTM Range Subelements field includes a concatenation of at least Minimum AP Count Neighbor Report subelements. Each Neighbor Report subelement has the same format as the Neighbor Report element and contains the Wide Bandwidth Channel subelement. See Table 9-106 and Table 9.4.2.37. The Neighbor Report Subelements field specifies a superset of nearby APs with which the requested STA is requested to perform the FTM procedure (see 11.11.9.11). The Maximum Age subelement indicates the maximum age of the requested FTM ranges. The format of the Maximum Age subelement is defined in Figure 9-190. The absence of a Maximum Age subelement indicates that FTM ranges determined at or after the Fine Timing Measurement Range request is received are requested. Subelement ID Length Maximum Age Octets: 1 1 2 Figure 9-190â€”Format of Maximum Age subelement The Subelement ID field is defined in Table 9-106. The Length field is defined in 9.4.3. The Maximum Age field of the Maximum Age subelement indicates the maximum elapsed time between when FTM ranges are determined and when a Fine Timing Measurement Range request is received, within which the FTM ranges satisfy the Fine Timing Measurement Range request. The Maximum Age field is encoded as an unsigned integer with units of 0.1 s. The value 0 is reserved. The value 65 535 indicates that FTM ranges determined at any time are acceptable. The Vendor Specific subelement has the same format as the corresponding element (see 9.4.2.26). Multiple Vendor Specific subelements can be included in the Optional Subelements field. 9.4.2.22 Measurement Report element 9.4.2.22.1 General The Measurement Report element contains a measurement report. The format of the Measurement Report element is shown in Figure 9-191. The Measurement Report element is included in Measurement Report frames, as described in 9.6.2.3, or Radio Measurement Report frames, as described in 9.6.7.3. Measurement Types 0, 1, and 2 are used for spectrum management and are included only in Measurement Report frames. All other Measurement Types are included only in Radio Measurement Report frames. The use of Measurement Report elements and frames for spectrum management is described in 11.9.7. The use of Measurement Report elements and frames for radio measurement is described in 11.11. 835 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Measurement Measurement Measurement Measurement Element ID Length Token Report Mode Type Report Octets: 1 1 1 1 1 variable Figure 9-191â€”Measurement Report element format The Element ID and Length fields are defined in 9.4.2.1. The minimum value of the Length field is 3. The Measurement Token field is set to the value of the Measurement Token field in the corresponding Measurement Request element. If the Measurement Report element is being sent autonomously, then the Measurement Token is set to 0. If the Measurement Report element is being sent in a Location Track Notification frame, then the value of the Measurement Token field is set to the same value as the Location Configuration Request frame Dialog Token field that configured the STA to send the Location Track Notification frames. The Measurement Report Mode field (shown in Figure 9-192) is used to indicate the reason for a failed or rejected measurement request. The Measurement Report Mode is a bit field with the following bits defined: â€” Late bit (bit 0) indicates whether this STA is unable to carry out a measurement request because it received the request after the requested measurement time. The Late bit is set to 1 to indicate the request was too late. The Late bit is set to 0 to indicate the request was received in time for the measurement to be executed. The Late bit only applies to spectrum management measurement and is set to 0 in all measurement report elements for radio measurement types (see Table 9-107). â€” Incapable bit (bit 1) indicates whether this STA is incapable of generating a report of the type specified in the Measurement Type field that was previously requested by the destination STA of this Measurement Report element. The Incapable bit is set to 1 to indicate the STA is incapable. The Incapable bit is set to 0 to indicate the STA is capable or the report is autonomous. â€” Refused bit (bit 2) indicates whether this STA is refusing to generate a report of the type specified in the Measurement Type field that was previously requested by the destination STA of this Measurement Report element. The Refused bit is set to 1 to indicate the STA is refusing. The Refused bit is set to 0 to indicate the STA is not refusing or the report is autonomous. â€” All other bits are reserved. B0 B1 B2 B3 B7 Late Incapable Refused Reserved Bits: 1 1 1 5 Figure 9-192â€”Measurement Report Mode field No more than one bit is set to 1 within a Measurement Report Mode field. All bits within the Measurement Mode field are set to 0 if the results of a successful measurement request or an autonomous measurement are being reported. The Measurement Type field is set to a number that identifies the measurement report. The Measurement Types that have been allocated are shown in Table 9-107. 836 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-107â€”Measurement Type field definitions for measurement reports Name Measurement Type Basic 0 CCA 1 RPI Histogram 2 Channel Load 3 Noise Histogram 4 Beacon 5 Frame 6 STA Statistics 7 LCI 8 Transmit Stream/Category Measurement 9 Multicast Diagnostics 10 Location Civic 11 Location Identifier 12 Directional Channel Quality 13 Directional Measurement 14 Directional Statistics 15 Fine Timing Measurement Range 16 Reserved 17â€“255 The Measurement Report field is not present when the Late bit is equal to 1, the Incapable bit is equal to 1, or the Refused bit is equal to 1. Otherwise, it contains a single measurement report, as described in 9.4.2.22.2 to 9.4.2.22.11. References in this standard to a â€˜ reportâ€™, where corresponds to one of the Measurement Types in Table 9-107 is equivalent to (according to context) a) â€˜a Measurement Report frame or Radio Measurement Report frame carrying a Measurement Report element with the Measurement Type field equal to â€™ or b) â€˜a Measurement Report element with the Measurement Type field equal to â€™. 9.4.2.22.2 Basic report The format of the Measurement Report field corresponding to a Basic report is shown in Figure 9-193. Channel Measurement Measurement Map (see Number Start Time Duration Figure 9-194) Octets: 1 8 2 1 Figure 9-193â€”Measurement Report field format for a Basic report 837 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Channel Number field is set to the channel number to which the Basic report applies where the Channel Number is a value from the â€œChannel setâ€ column in Table E-4, in a row having the same value in the â€œChannel spacing (MHz)â€ column as the width of the primary channel. The Measurement Start Time field is set to the TSF at the time (Â± 32 s) at which the Basic report measurement started. The Measurement Duration field is set to the duration over which the Basic report was measured, expressed in TUs. The Map field is coded as a bit field, as shown in Figure 9-194, and contains the following bits: â€” BSS bit, which is set to 1 when at least one valid MPDU was received in the channel during the measurement period from another BSS. Otherwise, the BSS bit is set to 0. â€” OFDM preamble bit, which is set to 1 when at least one sequence of short training symbols, as defined in 17.3.3, was detected in the channel during the measurement period without a subsequent valid SIGNAL field (see 17.3.4). This indicates the presence of an OFDM preamble, such as high- performance RLAN/2 (HIPERLAN/2). Otherwise, the OFDM preamble bit is set to 0. â€” Unidentified Signal bit, which is set to 1 when, in the channel during the measurement period, there is significant power detected that is not characterized as radar, an OFDM preamble, or a valid MPDU. Otherwise, the Unidentified Signal bit is set to 0. The definition of significant power is implementation dependent. â€” Radar bit, which is set to 1 when radar was detected operating in the channel during the measurement period. The radar detection algorithm that satisfies regulatory requirements is outside the scope of this standard. Otherwise, the Radar bit is set to 0. â€” Unmeasured bit, which is set to 1 when this channel has not been measured. Otherwise, the Unmeasured bit is set to 0. When the Unmeasured field is equal to 1, all of the other bit fields are set to 0. Orthogonal frequency division Unidentified BSS Radar Unmeasured Reserved multiplexing Signal (OFDM) Preamble Bit: 0 1 2 3 4 5-7 Figure 9-194â€”Map field format 9.4.2.22.3 CCA report The format of the Measurement Report field corresponding to a CCA report is shown in Figure 9-195. Channel Measurement Measurement CCA Busy Number Start Time Duration Fraction Octets: 1 8 2 1 Figure 9-195â€”Measurement Report field format for a CCA report The Channel Number field contains the channel number to which the CCA report applies where the Channel Number is a value from the â€œChannel setâ€ column in Table E-4, in a row having the same value in the â€œChannel spacing (MHz)â€ column as the width of the primary channel. The Measurement Start Time field is set to the TSF at the time (Â± 32 s) at which the CCA report measurement started. 838 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Measurement Duration field is set to the duration over which the CCA report was measured, expressed in TUs. The CCA Busy Fraction field contains the fractional duration over which CCA indicated the channel was busy during the measurement duration. The resolution of the CCA busy measurement is in microseconds. The CCA Busy Fraction value is defined as 255 t busy -------------------------- - 1024 t MD where tbusy is the duration CCA indicated channel was busy ( s) tMD is the measurement duration (TUs) 9.4.2.22.4 RPI histogram report The format of the Measurement Report field corresponding to an RPI histogram report is shown in Figure 9-196. Channel Measurement Measurement Number Start Time Duration Octets: 1 8 2 RPI 0 RPI 1 RPI 2 RPI 3 RPI 4 RPI 5 RPI 6 RPI 7 density density density density density density density density Octets: 1 1 1 1 1 1 1 1 Figure 9-196â€”Measurement Report field format for an RPI histogram report The Channel Number field is set to the channel number to which the RPI histogram report applies where the Channel Number is a value from the â€œChannel setâ€ column in Table E-4, in a row having the same value in the â€œChannel spacing (MHz)â€ column as the width of the primary channel. The Measurement Start Time field is set to the TSF at the time (Â± 32 s) at which the RPI histogram report measurement started. The Measurement Duration field is set to the duration over which the RPI histogram report was measured, expressed in TUs. The RPI histogram report contains the RPI densities observed in the channel for the eight RPI levels defined in Table 9-108. See 11.11.12. Table 9-108â€”RPI definitions for an RPI histogram report RPI Power observed at the antenna (dBm) 0 Power â€“87 1 â€“87 < Power â€“82 2 â€“82 < Power â€“77 839 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-108â€”RPI definitions for an RPI histogram report (continued) RPI Power observed at the antenna (dBm) 3 â€“77 < Power â€“72 4 â€“72 < Power â€“67 5 â€“67 < Power â€“62 6 â€“62 < Power â€“57 7 â€“57 < Power The RPI histogram report provides an additional mechanism for a STA to gather information on the state of a channel from other STAs. The STA might use this information to assist in the choice of new channel, to help avoid false radar detections, and to assess the general level of interference present on a channel. 9.4.2.22.5 Channel Load report The format of the Measurement Report field corresponding to a Channel Load report is shown in Figure 9-197. Actual Operating Channel Measurement Optional Class Number Measurement Duration Channel Load Subelements Start Time Octets: 1 1 8 2 1 variable Figure 9-197â€”Measurement Report field format for Channel Load report If the Wide Bandwidth Channel Switch subelement is not included, the Operating Class field indicates the operating class that identifies the channel set for which the measurement report applies. The Country, Operating Class, and Channel Number fields together specify the channel frequency and spacing for which the measurement report applies. Valid operating classes are listed in Annex E, excluding operating classes that encompass a primary channel but do not identify the location of the primary channel. The Channel Number field indicates the channel number for which the measurement report applies. Channel number is defined within an operating class as shown in Annex E. NOTEâ€”Examples of operating classes that encompass a primary channel but do not identify the location of the primary channel are operating classes with a value of 80 or 160 in the â€œChannel Spacing (MHz)â€ column of the applicable table in Annex E. If the Wide Bandwidth Channel Switch subelement is included, the fields in the Wide Bandwidth Channel Switch subelement indicate the channel for which the measurement report applies, and the Operating Class and Channel Number fields together specify the primary channel and primary 40 MHz channel within the channel identified by the Wide Bandwidth Channel Switch subelement. Actual Measurement Start Time is set to the value of the measuring STAâ€™s TSF timer at the time the measurement started. Measurement Duration is set to the duration over which the Channel Load report was measured, in units of TUs. 840 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Channel Load contains the proportion of measurement duration for which the measuring STA determined the channel to be busy. Procedure for Channel Load measurement and definition of channel load values are found in 11.11.9.3. The Optional Subelements field contains zero or more subelements. The subelement format and ordering of subelements are defined in 9.4.3. The Subelement ID field values for the defined subelements are shown in Table 9-109. Table 9-109â€”Optional subelement IDs for Channel Load report Subelement ID Name Extensible 0â€“162 Reserved 163 Wide Bandwidth Yes Channel Switch 164â€“220 Reserved 221 Vendor Specific 222â€“255 Reserved The Wide Bandwidth Channel Switch subelement has the same format as the corresponding element (see 9.4.2.161), with the constraint that the New Channel Width field indicates an 80 MHz, 160 MHz, or 80+80 MHz BSS bandwidth. The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26). Multiple Vendor Specific subelements are optionally present in the list of optional subelements. 9.4.2.22.6 Noise Histogram report The format of the Measurement Report field of a Noise Histogram report is shown in Figure 9-198. Operating Channel Actual Measurement Measurement Antenna Class Number Start Time Duration ID ANPI Octets: 1 1 8 2 1 1 IPI 0 IPI 1 IPI 2 . . . IPI 8 IPI 9 IPI 10 Optional Density Density Density Density Density Density subelements Octets: 1 1 1 5 1 1 1 variable Figure 9-198â€”Measurement Report field format for Noise Histogram report If the Wide Bandwidth Channel Switch subelement is not included, the Operating Class field indicates the operating class that identifies the channel set for which the measurement report applies. The Country, Operating Class, and Channel Number fields together specify the channel frequency and spacing for which the measurement report applies. Valid operating classes are listed in Annex E, excluding operating classes that encompass a primary channel but do not identify the location of the primary channel. The Channel 841 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Number field indicates the channel number for which the measurement report applies. Channel number is defined within an operating class as shown in Annex E. If the Wide Bandwidth Channel Switch subelement is included, the fields in the Wide Bandwidth Channel Switch subelement indicate the channel for which the measurement report applies, and the Operating Class and Channel Number together specify the primary channel and primary 40 MHz channel within the channel identified by the Wide Bandwidth Channel Switch subelement. Actual Measurement Start Time is set to the value of the measuring STAâ€™s TSF timer at the time the measurement started. Measurement Duration is set to the duration over which the Noise Histogram report was measured, in units of TUs. Antenna ID is set to the identifying number for the antenna(s) used for this measurement. Antenna ID is defined in 9.4.2.40. ANPI is set to the average noise plus interference power value measured during the indicated measurement duration while the indicated channel is idle as described in 11.11.9.4. The Noise Histogram report contains the IPI densities, as defined in 11.11.9.4, observed in the channel for the eleven IPI levels defined in Table 9-110. Table 9-110â€”IPI Definitions for a Noise Histogram report IPI Level IPI Measured Power (dBm) 0 IPI â€“ 92 1 â€“92 < IPI â€“89 2 â€“89 < IPI â€“86 3 â€“86 < IPI â€“83 4 â€“83 < IPI â€“80 5 â€“80 < IPI â€“75 6 â€“75 < IPI â€“70 7 â€“70 < IPI â€“65 8 â€“65 < IPI â€“60 9 â€“60 < IPI â€“55 10 â€“55 < IPI The Optional Subelements field contains zero or more subelements. The subelement format and ordering of subelements are defined in 9.4.3. The Subelement ID field values for the defined subelements are shown in Table 9-111. The Wide Bandwidth Channel Switch subelement has the same format as the corresponding element (see 9.4.2.161) with the constraint that the New Channel Width field indicates an 80 MHz, 160 MHz, or 80+80 MHz BSS bandwidth. 842 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-111â€”Optional subelement IDs for Noise Histogram report Subelement ID Name Extensible 0â€“162 Reserved 163 Wide Bandwidth Yes Channel Switch 164â€“220 Reserved 221 Vendor Specific 222â€“255 Reserved The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26). Multiple Vendor Specific subelements are optionally present in the list of optional subelements. 9.4.2.22.7 Beacon report The format of the Measurement Report field corresponding to a Beacon report is shown in Figure 9-199. Actual Reported Operating Channel Measurement Start Measurement Frame Class Number Duration Time Information Octets: 1 1 8 2 1 Antenna Parent Optional RCPI RSNI BSSID ID TSF Subelements Octets: 1 1 6 1 4 variable Figure 9-199â€”Measurement Report field format for Beacon report The Operating Class field indicates the operating class that identifies the channel set of the received Beacon or Probe Response frame. The Country, Operating Class, and Channel Number fields together specify the channel frequency and spacing of the received Beacon or Probe Response frame. Valid operating classes are listed in Annex E. The Channel Number field indicates the channel number of the received Beacon or Probe Response frame. Channel number is defined within an operating class as shown in Annex E. If the PPDU carrying the received frame comprises noncontiguous frequency segments, the Operating Class and Channel Number fields identify the center frequency of frequency segment 0, and a Wide Bandwidth Channel Switch subelement is included to identify the center frequency of frequency segment 1 (the other fields in the subelement indicate 80+80 bandwidth and the same center frequency of frequency segment 0 as the Operating Class and Channel Number fields); otherwise the Wide Bandwidth Channel Switch subelement is not included. Actual Measurement Start Time is set to the value of the measuring STAâ€™s TSF timer at the time the measurement started. Measurement Duration is set to the duration over which the Beacon report was measured, in units of TUs. The Reported Frame Information field contains two subfields as shown in Figure 9-200. 843 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B0 B6 B7 Condensed PHY Reported Frame Type Type Bits: 7 1 Figure 9-200â€”Reported Frame Information field Condensed PHY Type indicates the physical medium type on which the Beacon, Measurement Pilot, or Probe Response frame being reported was received. It has an integer value between 0 and 127 coded according to dot11PHYType. Reported Frame Type indicates the type of frame reported. A value of 0 indicates a Beacon or Probe Response frame; a value of 1 indicates a Measurement Pilot frame. RCPI indicates the received channel power of the Beacon, Measurement Pilot, or Probe Response frame, which is a logarithmic function of the received signal power, as defined 9.4.2.38. RSNI indicates the received signal-to-noise indication for the Beacon, Measurement Pilot, or Probe Response frame, as described in 9.4.2.41. The BSSID field contains the BSSID from the Beacon, Measurement Pilot, or Probe Response frame being reported. The Antenna ID field contains the identifying number for the antenna(s) used for this measurement. Antenna ID is defined in 9.4.2.40. The Parent TSF field contains the lower 4 octets of the measuring STAâ€™s TSF timer value at the start of reception of the first octet of the timestamp field of the reported Beacon, Measurement Pilot, or Probe Response frame at the time the Beacon, Measurement Pilot, or Probe Response frame being reported was received. The Optional Subelements field contains zero or more subelements. The subelement format and ordering of subelements are defined in 9.4.3. The Subelement ID field values for the defined subelements are shown in Table 9-112. Table 9-112â€”Optional subelement IDs for Beacon report Subelement ID Name Extensible 0 Reserved 1 Reported Frame Body 2â€“162 Reserved 163 Wide Bandwidth Yes Channel Switch 164-220 Reserved 221 Vendor Specific 222â€“255 Reserved 844 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Reported Frame Body subelement contains the requested fields and elements of the frame body of the reported Beacon, Measurement Pilot, or Probe Response frame. If the Reporting Detail subelement of the corresponding Beacon request equals 0, the Reported Frame Body subelement is not included in the Beacon report. If the Reporting Detail subelement equals 1, all fixed fields and any elements identified in a Request element or Extended Request element in the corresponding Beacon request are included in the Reported Frame Body subelement, in the order that they appeared in the reported frame. If the Reporting Detail field equals 2, all fixed fields and elements are included in the order they appeared in the reported frame. Reported TIM elements are truncated such that only the first 4 octets of the element are reported and the element Length field is modified to indicate the truncated length of 4. Reported IBSS dynamic frequency selection (DFS) elements are truncated so that only the lowest and highest channel number map are reported and the element Length field is modified to indicate the truncated length of 13. Reported RSNEs are truncated so that only the first 4 octets of the element are reported and the element Length field is modified to indicate the truncated length of 4. If the length of the Reported Frame Body subelement would cause the Measurement Report element to exceed the maximum element size, then the Reported Frame Body subelement is truncated so that the last element in the Reported Frame Body subelement is a complete element. The Wide Bandwidth Channel Switch subelement has the same format as the corresponding element (see 9.4.2.161) with the constraint that the New Channel Width field indicates an 80 MHz, 160 MHz, or 80+80 MHz BSS bandwidth. The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26). Multiple Vendor Specific subelements are optionally present in the list of optional subelements. 9.4.2.22.8 Frame report The format of the Measurement Report field corresponding to a Frame report is shown in Figure 9-201. Actual Operating Channel Measurement Measurement Optional Class Number Duration Subelements Start Time Octets: 1 1 8 2 variable Figure 9-201â€”Measurement Report field format for Frame report If the Wide Bandwidth Channel Switch subelement is not included, the Operating Class field indicates the operating class that identifies the channel set for which the measurement report applies. The Country, Operating Class, and Channel Number fields together specify the channel frequency and spacing for which the measurement report applies. Valid operating classes are listed in Annex E, excluding operating classes that encompass a primary channel but do not identify the location of the primary channel. The Channel Number field indicates the channel number for which the measurement report applies. Channel number is defined within an operating class as shown in Annex E. If the Wide Bandwidth Channel Switch subelement is included, the fields in the Wide Bandwidth Channel Switch subelement indicate the channel for which the measurement report applies, and the Operating Class and Channel Number fields together specify the primary channel and primary 40 MHz channel within the channel identified by the Wide Bandwidth Channel Switch subelement. Actual Measurement Start Time is set to the value of the measuring STAâ€™s TSF timer at the time the measurement started. Measurement Duration is set to the duration over which the Frame report was measured, in units of TUs. 845 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Optional Subelements field contains zero or more subelements. The subelement format and ordering of subelements are defined in 9.4.3. The Subelement ID field values for the defined subelements are shown in Table 9-113. Table 9-113â€”Optional subelement IDs for Frame report Subelement ID Name Extensible 0 Reserved 1 Frame Count Report 2â€“162 Reserved 163 Wide Bandwidth Yes Channel Switch 164â€“220 Reserved 221 Vendor Specific 222â€“255 Reserved The Frame Count Report subelement is used to report information about frames sent by a transmitter. The Frame Count Report subelement is as shown in Figure 9-202. Subelement ID Length Frame Report Entries Octets: 1 1 n x 19 Figure 9-202â€”Frame Count Report subelement format The Subelement ID field is defined in Table 9-113. The Length field is defined in 9.4.3. The Frame Report Entries field contains zero or more frame report entries. The structure of a frame report entry is shown in Figure 9-203. Transmit BSSID PHY Average Last Last Antenna Frame Count Address Type RCPI RSNI RCPI ID Octets: 6 6 1 1 1 1 1 2 Figure 9-203â€”Frame Report Entry field format The Transmit Address field contains the Transmitter Address (TA) from the frames being reported. The BSSID field contains the BSSID from the frames being reported. PHY Type indicates the physical medium type for the frame(s) being reported. Valid entries are coded according to dot11PHYType. 846 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Average RCPI indicates the average value for the received channel power of frames received and counted in this Frame Report Entry field, as described in 11.11.9.2. Average RCPI is a logarithmic function of the received signal power, as defined 9.4.2.38. Last RSNI indicates the received signal-to-noise indication of the most recently measured frame counted in this Frame Report Entry field, as described in 9.4.2.41. Last RCPI indicates the received channel power of the most recently measured frame counted in this Frame Report Entry field. Last RCPI is a logarithmic function of the received signal power, as defined in 9.4.2.38. The Antenna ID field contains the identifying number for the antenna(s) used to receive the most recently measured frame counted in this Frame Report Entry field. Antenna ID is defined in 9.4.2.40. Frame Count is a count of the Data and Management frames received with the indicated transmit address and BSSID during the measurement duration. The value 65 535 indicates a count of 65 535 or more. The Wide Bandwidth Channel Switch subelement has the same format as the corresponding element (see 9.4.2.161), with the constraint that the New Channel Width field indicates an 80 MHz, 160 MHz, or 80+80 MHz BSS bandwidth. The Vendor Specific subelement has the same format as the Vendor Specific element (see 9.4.2.26). Multiple Vendor Specific subelements are optionally present in the list of optional subelements. 9.4.2.22.9 STA Statistics report The format of the Measurement Report field of a STA Statistics report is shown in Figure 9-204. Measurement Statistics Optional Duration Group Identity Group Data Subelements Octets: 2 1 variable variable Figure 9-204â€”Measurement Report field format for STA Statistics report The STA Statistics report reports the change in the requested Statistics Group Data values measured within the Measurement Duration. When the Measurement Duration is equal to 0 the current values of the requested Statistics Group Data is reported, rather than the change. The Measurement Duration is set to the duration over which the change in Statistics Group Data was measured and reported, in units of TUs. A Measurement Duration value of 0 indicates a report of the current values of the Statistics Group Data. Group Identity indicates the requested statistics group describing the Statistics Group Data according to Table 9-114. Statistics Group Data contains the requested statistics from the MIB in Annex C related to the interface on which the request was received according to Table 9-114. Units used for reporting a statistic or change in statistic are the units used to define the statistic in Annex C. When Measurement Duration value is nonzero, the reported data values for statistics that are not counters are the current values of the statistics data at the end of the Measurement Duration. 847 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-114â€”Group Identity for a STA Statistics report Group Statistics Group Identity Data field length Statistics Returned Requested (octets) 0 28 dot11Counters Group for the Interface on which the STA Statistics request was received (with the exception of WEPUndecryptableCount and those counters listed in Group Identity 1): dot11TransmittedFragmentCount (Counter32), dot11GroupTransmittedFrameCount (Counter32), dot11FailedCount (Counter32), dot11ReceivedFragmentCount (Counter32), dot11GroupReceivedFrameCount (Counter32), dot11FCSErrorCount (Counter32), dot11TransmittedFrameCount (Counter32) 1 24 dot11MACStatistics Group for the Interface on which the STA Statistics request was received: dot11RetryCount (Counter32), dot11MultipleRetryCount (Counter32), dot11FrameDuplicateCount (Counter32), dot11RTSSuccessCount (Counter32), dot11RTSFailureCount (Counter32), dot11AckFailureCount (Counter32) 2 52 dot11QosCounters Group for UP0 for the Interface on which the STA Statistics request was received: dot11QosTransmittedFragmentCount (Counter32), dot11QosFailedCount (Counter32), dot11QosRetryCount (Counter32), dot11QosMultipleRetryCount (Counter32), dot11QosFrameDuplicateCount (Counter32), dot11QosRTSSuccessCount (Counter32), dot11QosRTSFailureCount (Counter32), dot11QosAckFailureCount (Counter32), dot11QosReceivedFragmentCount (Counter32), dot11QosTransmittedFrameCount (Counter32), dot11QosDiscardedFrameCount (Counter32), dot11QosMPDUsReceivedCount (Counter32), dot11QosRetriesReceivedCount (Counter32) 3 52 dot11QosCounters Group for UP1 for the Interface on which the STA Statistics request was received: dot11QosTransmittedFragmentCount (Counter32), dot11QosFailedCount (Counter32), dot11QosRetryCount (Counter32), dot11QosMultipleRetryCount (Counter32), dot11QosFrameDuplicateCount (Counter32), dot11QosRTSSuccessCount (Counter32), dot11QosRTSFailureCount (Counter32), dot11QosAckFailureCount (Counter32), dot11QosReceivedFragmentCount (Counter32), dot11QosTransmittedFrameCount (Counter32), dot11QosDiscardedFrameCount (Counter32), dot11QosMPDUsReceivedCount (Counter32), dot11QosRetriesReceivedCount (Counter32) 848 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-114â€”Group Identity for a STA Statistics report (continued) Group Statistics Group Identity Data field length Statistics Returned Requested (octets) 4 52 dot11QosCounters Group for UP2 for the Interface on which the STA Statistics request was received: dot11QosTransmittedFragmentCount (Counter32), dot11QosFailedCount (Counter32), dot11QosRetryCount (Counter32), dot11QosMultipleRetryCount (Counter32), dot11QosFrameDuplicateCount (Counter32), dot11QosRTSSuccessCount (Counter32), dot11QosRTSFailureCount (Counter32), dot11QosAckFailureCount (Counter32), dot11QosReceivedFragmentCount (Counter32), dot11QosTransmittedFrameCount (Counter32), dot11QosDiscardedFrameCount (Counter32), dot11QosMPDUsReceivedCount (Counter32), dot11QosRetriesReceivedCount (Counter32) 5 52 dot11QosCounters Group for UP3 for the Interface on which the STA Statistics request was received: dot11QosTransmittedFragmentCount (Counter32), dot11QosFailedCount (Counter32), dot11QosRetryCount (Counter32), dot11QosMultipleRetryCount (Counter32), dot11QosFrameDuplicateCount (Counter32), dot11QosRTSSuccessCount (Counter32), dot11QosRTSFailureCount (Counter32), dot11QosAckFailureCount (Counter32), dot11QosReceivedFragmentCount (Counter32), dot11QosTransmittedFrameCount (Counter32), dot11QosDiscardedFrameCount (Counter32), dot11QosMPDUsReceivedCount (Counter32), dot11QosRetriesReceivedCount (Counter32) 6 52 dot11QosCounters Group for UP4 for the Interface on which the STA Statistics request was received: dot11QosTransmittedFragmentCount (Counter32), dot11QosFailedCount (Counter32), dot11QosRetryCount (Counter32), dot11QosMultipleRetryCount (Counter32), dot11QosFrameDuplicateCount (Counter32), dot11QosRTSSuccessCount (Counter32), dot11QosRTSFailureCount (Counter32), dot11QosAckFailureCount (Counter32), dot11QosReceivedFragmentCount (Counter32), dot11QosTransmittedFrameCount (Counter32), dot11QosDiscardedFrameCount (Counter32), dot11QosMPDUsReceivedCount (Counter32), dot11QosRetriesReceivedCount (Counter32) 849 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-114â€”Group Identity for a STA Statistics report (continued) Group Statistics Group Identity Data field length Statistics Returned Requested (octets) 7 52 dot11QosCounters Group for UP5 for the Interface on which the STA Statistics request was received: dot11QosTransmittedFragmentCount (Counter32), dot11QosFailedCount (Counter32), dot11QosRetryCount (Counter32), dot11QosMultipleRetryCount (Counter32), dot11QosFrameDuplicateCount (Counter32), dot11QosRTSSuccessCount (Counter32), dot11QosRTSFailureCount (Counter32), dot11QosAckFailureCount (Counter32), dot11QosReceivedFragmentCount (Counter32), dot11QosTransmittedFrameCount (Counter32), dot11QosDiscardedFrameCount (Counter32), dot11QosMPDUsReceivedCount (Counter32), dot11QosRetriesReceivedCount (Counter32) 8 52 dot11QosCounters Group for UP6 for the Interface on which the STA Statistics request was received: dot11QosTransmittedFragmentCount (Counter32), dot11QosFailedCount (Counter32), dot11QosRetryCount (Counter32), dot11QosMultipleRetryCount (Counter32), dot11QosFrameDuplicateCount (Counter32), dot11QosRTSSuccessCount (Counter32), dot11QosRTSFailureCount (Counter32), dot11QosAckFailureCount (Counter32), dot11QosReceivedFragmentCount (Counter32), dot11QosTransmittedFrameCount (Counter32), dot11QosDiscardedFrameCount (Counter32), dot11QosMPDUsReceivedCount (Counter32), dot11QosRetriesReceivedCount (Counter32) 9 52 dot11QosCounters Group for UP7 for the Interface on which the STA Statistics request was received: dot11QosTransmittedFragmentCount (Counter32), dot11QosFailedCount (Counter32), dot11QosRetryCount (Counter32), dot11QosMultipleRetryCount (Counter32), dot11QosFrameDuplicateCount (Counter32), dot11QosRTSSuccessCount (Counter32), dot11QosRTSFailureCount (Counter32), dot11QosAckFailureCount (Counter32), dot11QosReceivedFragmentCount (Counter32), dot11QosTransmittedFrameCount (Counter32), dot11QosDiscardedFrameCount (Counter32), dot11QosMPDUsReceivedCount (Counter32), dot11QosRetriesReceivedCount (Counter32) 850 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-114â€”Group Identity for a STA Statistics report (continued) Group Statistics Group Identity Data field length Statistics Returned Requested (octets) 10 8 dot11BSSAverageAccessDelay Group (only available at an AP): dot11STAStatisticsAPAverageAccessDelay (INTEGER), dot11STAStatisticsAverageAccessDelayBestEffort (INTEGER), dot11STAStatisticsAverageAccessDelayBackGround (INTEGER), dot11STAStatisticsAverageAccessDelayVideo (INTEGER), dot11STAStatisticsAverageAccessDelayVoice (INTEGER), dot11STAStatisticsStationCount (INTEGER), dot11STAStatisticsChannelUtilization (INTEGER) 11 40 STA Counters from dot11CountersGroup3 (A-MSDU): dot11TransmittedAMSDUCount (Counter32), dot11FailedAMSDUCount (Counter32), dot11RetryAMSDUCount (Counter32), dot11MultipleRetryAMSDUCount (Counter32), dot11TransmittedOctetsInAMSDUCount (Counter64), dot11AMSDUAckFailureCount (Counter32), dot11ReceivedAMSDUCount (Counter32), dot11ReceivedOctetsInAMSDUCount (Counter64) 12 36 STA Counters from dot11CountersGroup3 (A-MPDU): dot11TransmittedAMPDUCount (Counter32), dot11TransmittedMPDUsInAMPDUCount (Counter32), dot11TransmittedOctetsInAMPDUCount (Counter64), dot11AMPDUReceivedCount (Counter32), dot11MPDUInReceivedAMPDUCount (Counter32), dot11ReceivedOctetsInAMPDUCount (Counter64), dot11AMPDUDelimiterCRCErrorCount (Counter32) 13 36 STA Counters from dot11CountersGroup3 (BlockAckReq, Channel Width, PSMP): dot11ImplicitBARFailureCount (Counter32), dot11ExplicitBARFailureCount (Counter32), dot11ChannelWidthSwitchCount (Counter32), dot11TwentyMHzFrameTransmittedCount (Counter32), dot11FortyMHzFrameTransmittedCount (Counter32), dot11TwentyMHzFrameReceivedCount (Counter32), dot11FortyMHzFrameReceivedCount (Counter32), dot11PSMPUTTGrantDuration (Counter32), dot11PSMPUTTUsedDuration (Counter32) 14 36 STA Counters from dot11CountersGroup3 (RD, dual CTS, L-SIG TXOP protection): dot11GrantedRDGUsedCount (Counter32), dot11GrantedRDGUnusedCount (Counter32), dot11TransmittedFramesInGrantedRDGCount (Counter32), dot11TransmittedOctetsInGrantedRDGCount (Counter64), dot11DualCTSSuccessCount (Counter32), dot11DualCTSFailureCount (Counter32), dot11RTSLSIGSuccessCount (Counter32), dot11RTSLSIGFailureCount (Counter32) 15 20 STA Counters from dot11CountersGroup3 (beamforming and STBC): dot11BeamformingFrameCount (Counter32), dot11STBCCTSSuccessCount (Counter32), dot11STBCCTSFailureCount (Counter32), dot11nonSTBCCTSSuccessCount (Counter32), dot11nonSTBCCTSFailureCount (Counter32) 851 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-114â€”Group Identity for a STA Statistics report (continued) Group Statistics Group Identity Data field length Statistics Returned Requested (octets) 16 28 dot11RSNAStats Group for the Interface on which the STA Statistics request was received: dot11RSNAStatsBIPMICErrors (Counter32) dot11RSNAStatsCMACReplays (Counter32) dot11RSNAStatsRobustMgmtCCMPReplays(Counter32) dot11RSNAStatsTKIPICVErrors (Counter32) dot11RSNAStatsTKIPReplays (Counter32) dot11RSNAStatsCCMPDecryptErrors (Counter32) dot11RSNAStatsCCMPReplays (Counter32) 17â€“255 Reserved The format of the Measurement Report field for dot11Counters Group is shown in Figure 9-205. dot11TransmittedF dot11Group dot11Failed dot11Received dot11Group Transmitted ReceivedFrame ragmentCount FrameCount Count FragmentCount Count Octets: 4 4 4 4 4 dot11FCSError dot11Transmitted Count FrameCount Octets: 4 4 Figure 9-205â€”Measurement Report field format for dot11Counters Group The format of the Measurement Report field for dot11MACStatistics is shown in Figure 9-206. dot11RTS dot11Retry dot11Multiple dot11Frame dot11RTS Count RetryCount DuplicateCount Success FailureCount Count Octets: 4 4 4 4 4 dot11Ack FailureCount Octets: 4 Figure 9-206â€”Measurement Report field format for dot11MACStatistics Group The format of the Measurement Report field for dot11QosCounters Group for UPx is shown in Figure 9-207, where x is 0 â€“ 7 and where the listed variables are obtained from the column of the QoS Counters Table indexed by x + 1. For example, the variables for dot11QosCounters Group for UP2 are from the third column of the dot11QosCountersTable, obtained from the dot11QosCountersEntry in which dot11QosCountersIndex is equal to 3. 852 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11Qos Transmitted dot11Qos dot11Qos dot11Qos dot11Qos Multiple Frame Fragment FailedCount RetryCount RetryCount DuplicateCount Count Octets: 4 4 4 4 4 dot11Qos dot11Qos dot11Qos dot11Qos dot11Qos Transmitted RTS RTS Ack Received SuccessCount FailureCount FailureCount FragmentCount Frame Count Octets: 4 4 4 4 4 dot11Qos dot11Qos dot11Qos Discarded MPDUs Retries FrameCount ReceivedCount ReceivedCount Octets: 4 4 4 Figure 9-207â€”Measurement Report field format for dot11QosCounters Group for UPx The format of the Measurement Report field for dot11BSSAverageAccessDelay Group is shown in Figure 9-208. Non-QoS APs set dot11STAStatisticsAverageAccessDelayBestEffort, dot11STAStatistics- AverageAccessDelayBackGround, dot11STAStatisticsAverageAccessDelayVideo, and dot11STA- StatisticsAverageAccessDelayVoice to 255 (not available). dot11STA dot11STA dot11STA dot11STA dot11STA StatisticsAP Statistics Statistics Statistics Statistics AverageAccess AverageAccess AverageAccess Delay AverageAccess AverageAccess Delay DelayBestEffort DelayVideo DelayVoice BackGround Octets: 1 1 1 1 1 dot11STA dot11STA Statistics Statistics Channel StationCount Utilization Octets: 2 1 Figure 9-208â€”Measurement Report field format for dot11BSSAverageAccessDelay Group The Optional Subelements field contains zero or more subelements. The subelement format and ordering of subelements are defined in 9.4.3. The Subelement ID field values for the defined subelements are shown in Table 9-115. 853 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-115â€”Optional subelement IDs for STA Statistics report Subelement ID Name Extensible 0 Reserved 1 Reporting Reason 2â€“220 Reserved 221 Vendor Specific 222â€“255 Reserved The format of the Measurement Report field for RSNA Counters Group is shown in Figure 9-209. dot11RSNAStats dot11RSNAStats dot11RSNAStatsCM RobustMgmt dot11RSNAStats CMACICVErrors ACReplays TKIPICVErrors CCMPReplays Octets: 4 4 4 4 dot11RSNAStats dot11RSNAStats dot11RSNAStats TKIPReplays CCMPDecryptErrors CCMPReplays Octets 4 4 4 Figure 9-209â€”Measurement Report field format for RSNA Counters Group The Reporting Reason subelement indicates the reason why the measuring STA sent the STA Statistics report. It is present if Statistics Group Name is from STA Counters, QoS STA Counters, or RSNA Counters (see 11.11.9.5). The Data field of the Reporting Reason subelement for STA Statistics Group Identities 0 or 1 (STA Count- ers) is shown in Figure 9-210. B0 B1 B2 B3 dot11FCS dot11Multiple dot11Frame dot11Failed Error Retry Duplicate Bits 1 1 1 1 B4 B5 B6 B7 dot11RTS dot11Ack dot11Retry Reserved Failure Failure Bits 1 1 1 1 Figure 9-210â€”Data field of the Reporting Reason subelement for STA Counters The Data field of the Reporting Reason subelement for STA Statistics Group Identity 2 to 9 (QoS STA Counters) is shown in Figure 9-211. 854 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B0 B1 B2 B3 dot11QoS dot11QoS dot11QoSMultiple dot11QoSFrame Failed Retry Retry Duplicate Bits 1 1 1 1 B4 B5 B6 B7 dot11QoSRTS dot11QoSAck dot11QoS Reserved Failure Failure Discarded Bits 1 1 1 1 Figure 9-211â€”Data field of the Reporting Reason subelement for QoS STA Counters The Data field of the Reporting Reason subelement for STA Statistics Group Identity 16 (RSNA Counters) is shown in Figure 9-212. B0 B1 B2 B3 dot11RSNAStats dot11RSNAStats dot11RSNA dot11RSNAStats CMACICVErrors StatsCMACReplays RobustMgmt TKIPICVErrors CCMPReplays Bits: 1 1 1 1 B4 B5 B6 B7 dot11RSNAStats dot11RSNA dot11RSNAStats Reserved TKIPReplays StatsTKIPReplays CCMPReplays Bits: 1 1 1 1 Figure 9-212â€”Data field of the Reporting Reason subelement for RSNA Counters In a nontriggered STA Statistics report, all subfields of the Data field of the Reporting Reason subelement are set to 0. The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26). Multiple Vendor Specific subelements are optionally present in the list of optional subelements. 9.4.2.22.10 LCI report (Location configuration information report) An LCI report for a known LCI includes latitude, longitude, altitude, and related information. An unknown LCI is indicated by the Length field of the LCI subelement being set to 0 and there being no following subelements. The LCI report field format is shown in Figure 9-213. LCI Subelement Optional Sublements Octets: 2 or 18 variable Figure 9-213â€”Format of Location Configuration Information Report The subelements in the LCI report are defined in Table 9-116. 855 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-116â€”Subelement IDs for LCI Report Subelement ID Name Extensible 0 LCI 1 Azimuth Report Yes 2 Originator Requesting STA MAC Address 3 Target MAC Address 4 Z Subelements 5 Relative Location Error Yes 6 Usage Rules/Policy Yes 7 Co-Located BSSID List Yes 8â€“220 Reserved 221 Vendor Specific 222â€“255 Reserved The LCI Subelement field contains an LCI subelement. The LCI subelement is formatted as shown in Figure 9-214. Subelement ID Length LCI field (optional) Octets: 1 1 0 or 16 Figure 9-214â€”LCI subelement format The Subelement ID field is equal to the value for LCI in Table 9-116. The Length field is defined in 9.4.3. The LCI field is formatted as shown in Figure 9-215. B0 B5 B6 B39 B40 B45 B46 B79 B80 B83 B84 B89 Latitude Longitude Altitude Altitude Uncertainty Latitude Uncertainty Longitude Type Uncertainty Bits: 6 34 6 34 4 6 B90 B119 B120 B122 B123 B124 B125 B126 B127 RegLoc Dependent Altitude Datum RegLoc DSE Version Agreement STA Bits: 30 3 1 1 1 2 Figure 9-215â€”LCI field format 856 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The definitions of fields within the LCI field are as specified in Section 2.2 of IETF RFC 6225 (July 2011) or as defined herein. This structure and information fields are based on the LCI format described in IETF RFC 6225. NOTEâ€”This example shows how to encode the coordinates of the Sydney Opera House using the encoding defined in IETF RFC 6225. The building is a polygon with the following (latitude, longitude) coordinates: (-33.856 625Â°, +151.215 906Â°) (-33.856 299Â°, +151.215 343Â°) (-33.856 326Â°, +151.214 731Â°) (-33.857 533Â°, +151.214 495Â°) (-33.857 720Â°, +151.214 613Â°) (-33.857 369Â°, +151.215 375Â°) Latitude ranges from -33.857 720Â° to -33.856 299Â°; longitude ranges from +151.214 495Â° to +151.215 906Â°. For this example, the point that is encoded is chosen by finding the middle of each range, that is (-33.857 009 5Â°, +151.215 200 5Â°), which is encoded as (1110111100010010010011011000001101, 0100101110011011100010111011000011) (2s complement, 9 bits before binary point, 25 after, MSB first). These values can be derived as 234 â€“ Round (33.857 009 5 Ã— 225) and Round (151.215 200 5 Ã— 225), respectively. The latitude uncertainty (LatUnc) is given by inserting the difference between the center value and the outer value into the formula from Section 2.3.2 of IETF RFC 6225. This gives: LatUnc = 8 â€“ log2(â€“ 33.8570095 â€“ â€“ 33.857720 ) . The result is 18, which is encoded as 010010. Similarly, longitude uncertainty (LongUnc) is given by the formula: LongUnc = 8 â€“ log2(151.2152005 â€“ 151.214495) . The result is also 18, which is encoded as 010010. The top of the building is 67.4 meters above sea level, and a starting altitude of 0 meters above sea level is assumed. At the GPS coordinates of the Sydney Opera House, the sea level is approximately 22.5 m below the WGS84 ellipsoid. Therefore, the lowest altitude of the building is â€“22.5 m, while the highest altitude is (67.4 â€“ 22.5)=44.9 m from the WGS84 ellipsoid. The middle of the range is (44.9 â€“ 22.5)/2=11.2 m, which is encoded as 000000000000000000101100110011 (22 bits before binary point, 8 after, MSB first). Altitude uncertainty is given by the height of the building. Since the building is 67.4 m above sea level and basement is assumed to be at sea level, the uncertainty to be encoded is half of 67.4 m. Altitude uncertainty (AltUnc) uses the formula from Section 2.4.5 from IETF RFC 6225: AltUnc = 21 â€“ log2(33.7 â€“ 0) , the result is 15, which is encoded as 001111 (MSB first). The Altitude Type field is set to 1, indicating that the altitude is specified in meters. The Datum field is set to 1, indicating WGS84 coordinates. The RegLoc Agreement field is set to 0 for this example. The RegLoc DSE field is set to 0 for this example. The Dependent STA field is set to 0 for this example. The Version field is set to 1, as that is the only value currently defined in IETF RFC 6225. The LCI configuration information report for this example is encoded as (where underscores are used as field or octet delimiters): 010010_1110111100010010010011011000001101_010010_0100101110011011100010111011000011_0001 _001111_000000000000000000101100110011_001_0_0_0_01 (binary, MSB first per field) 010010_1011000001101100100100100011110111_010010_1100001101110100011101100111010010_1000 _111100_110011001101000000000000000000_100_0_0_0_10 (binary, LSB first per field) 01001010_11000001_10110010_01001000_11110111_01001011_00001101_11010001_11011001_1101001 0_10001111_00110011_00110100_00000000_00000000_10000010 (binary, rearranged into octets, with LSB first per octet) 01010010_10000011_01001101_00010010_11101111_11010010_10110000_10001011_10011011_0100101 1_11110001_11001100_00101100_00000000_00000000_01000001 (binary, MSB first, per octet) 52 83 4d 12 ef d2 b0 8b 9b 4b f1 cc 2c 00 00 41 (order over the PHY SAP, see 8.3.5 and 9.2.2) 857 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The RegLoc Agreement field is set to 1 to report that the STA is operating within a national policy area or an international agreement area near a national border (see 11.12.3); otherwise, it is 0. The RegLoc DSE field is set to 1 to report that the enabling STA is enabling the operation of STAs with DSE; otherwise, it is 0. The Dependent STA field is set to 1 to report that the STA is operating with the enablement of the enabling STA whose LCI is being reported; otherwise, it is 0. The Version field is a 2-bit field defined in IETF RFC 6225, and the use is described in IETF RFC 6225. The Optional Subelements field contains zero or more subelements with subelement ID greater than or equal to 1 as listed in Table 9-116. The subelement format and ordering of subelements are defined in 9.4.3. The Azimuth Report subelement is used to report an azimuth. The Azimuth Report subelement is as shown in Figure 9-216. Subelement ID Length Azimuth Report Octets: 1 1 2 Figure 9-216â€”Azimuth Report subelement format The Subelement ID field is defined in Table 9-116. The Length field is defined in 9.4.3. The Azimuth Report field of an Azimuth Report subelement contains three subfields as shown in Figure 9-217. B0 B1 B2 B3 B6 B7 B15 Reserved Azimuth Azimuth Resolution Azimuth Type Bits: 2 1 4 9 Figure 9-217â€”Azimuth Report subfield Azimuth Type is set to 1 to report the Azimuth of the bearing of the requester with respect to the responder and is set to 0 to report the Azimuth of front surface of the reporting STA. Azimuth Resolution is 4 bits, indicating the number of valid most significant bits in the Azimuth. Azimuth is a 9-bit unsigned integer value in degrees from true north, of the type defined by the Azimuth Type field. The Originator Requesting STA MAC Address subelement contains the MAC address of the STA that requested the Location Information and it is present whenever the Location Subject field in the corresponding LCI request was set to 2. The format of the Originator Requesting STA MAC Address subelement is shown in Figure 9-169. 858 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Target MAC Address subelement contains the MAC address of the STA whose Location Information was requested and it is present whenever the Location Subject field in the corresponding LCI request was set to 2. The format of the Target MAC Address subelement is shown in Figure 9-170. The Z subelement is used to report the floor and location of the STA with respect to the floor level. The format of the Z subelement is shown in Figure 9-218. Subelement ID Length STA Floor STA Height STA Height Info Above Floor Above Floor Uncertainty Octets: 1 1 2 3 1 Figure 9-218â€”Z subelement format The Subelement ID field is equal to the value for Z in Table 9-116. The Length field is defined in 9.4.3. The format of the STA Floor Info field is defined in Figure 9-218. B0 B1 B2 B15 Expected to STA Floor Move Number Bits: 2 14 Figure 9-219â€”STA Floor Info field format The Expected to Move field indicates whether the STA is expected to change its location. The value 1 indicates that the STA is expected to change its location. The value 0 indicates that the STA is not expected to change its location. The value 2 indicates that the STAâ€™s movement patterns are unknown. The value 3 is reserved. NOTEâ€”Examples of STAs that are expected to move include a) battery-powered STAs, b) STAs installed within trains/ vehicles, c) STAs installed for temporary events. The STA Floor Number field indicates the floor number of the STA. A higher value indicates a higher floor, and the integer approximates the floor number labels used at the venue (e.g., in stairwells and elevators, if present). The field is encoded as a 2s complement integer with units of 1/16-th of a floor. The value â€“8 192 indicates an unknown floor number. The value 8 191 indicates the STAâ€™s floor is 8 191/16 floors or more. The value â€“8 191 indicates the STAâ€™s floor is â€“8 191/16 floors or less. NOTEâ€”For example, a building with floors labeled as Basement 1, Ground, Mezzanine, 1, and 2 might have the floors identified by STA Floor Number values equal -16, 0, 8, 16 and 32 respectively. The STA Height Above Floor field indicates the height of the STA above the floor. The field is coded as a 2s complement integer with units of 1/4096 m. The value â€“8 388 608 indicates an unknown STA height above floor. The value â€“8 388 607 indicates the height of the STA above the floor is â€“8 388 607/4096 m or less. The value 8 388 607 indicates the height of the STA above the floor is 8 388 607/4096 m or more. A STA Height Above Floor Uncertainty value of 0 indicates an unknown STA height above floor uncertainty. Values 25 or higher are reserved. A value from 1 to 24 indicates that the actual STA height above floor, a, is bounded according to: 11 â€“ u 11 â€“ u hâ€“2 a h+2 859 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications where h is the value in units of 1/4096 m of the STA Height Above Floor field u is the value of the STA Height Above Floor Uncertainty field If the STA Height Above Floor field indicates an unknown STA height above floor, the STA Height Above Floor Uncertainty field is set to 0. The Relative Location Error subelement is used to report the location error of STAs with respect to a reference STA (rather than with respect to an absolute geographic location). The format of the Relative Location Error subelement is defined in Figure 9-220. Subelement ID Length Reference STA Relative Location Error Octets: 1 1 6 1 Figure 9-220â€”Relative Location Error subelement format The Subelement ID field is equal to the value for Relative Location Error in Table 9-116. The Length field is defined in 9.4.3. The Reference STA field contains the MAC address of the reference STA. The format of the Relative Location Error field is defined in Figure 9-221. B0 B3 B4 B7 Power of Two Power of Two Horizontal Error Vertical Error Bits: 4 4 Figure 9-221â€”Relative Location Error field format The Power Of Two Horizontal Error field contains an upper bound on the error between the horizontal location of the Reference STA and the Latitude and Longitude fields in the LCI subelement. The Power Of pâ€“8 Two Horizontal Error field indicates a relative horizontal error of 2 m, where p is the value of the Power of Two Horizontal Error field in the range 0 to 13. The value 14 indicates a relative horizontal error of greater than 32 m. The value 15 indicates an unknown relative horizontal error. The Power Of Two Vertical Error field contains an upper bound on the error between the vertical location of the Reference STA and the Altitude field in the LCI subelement. The Power Of Two Vertical Error field pâ€“8 indicates a relative vertical error of 2 m, where p is the value of the Power Of Two Vertical Error field in the range 0 to 13. The value 14 indicates a relative vertical error of greater than 32 m. The value 15 indicates an unknown relative vertical error. The Usage Rules/Policy subelement is used to report the usage rules of the reporting STA and whether additional STA or neighboring STA location information is available if the additional information can be transferred more securely. The format of the Usage Rules/Policy subelement is defined in Figure 9-222. 860 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Subelement ID Length Usage Rules/ Retention Policy Parame- Expires Rela- ters tive (optional) Octets: 1 1 1 0 or 2 Figure 9-222â€”Usage Rules/Policy subelement format The Subelement ID field is equal to the value for Usage Rules/Policy in Table 9-116. The Length field is defined in 9.4.3. The Usage Rules/Policy Parameters field is defined in Figure 9-223.B1 B0 B1 B2 B3 B7 Retransmission Retention Expires STA Location reserved Allowed Relative Present Policy Bits: 1 1 1 5 Figure 9-223â€”Usage Rules/Policy Parameters field format The Retransmission Allowed field definition is the same as the definition for the retransmission-allowed element in IETF RFC 4119, except that the â€œnoâ€ and â€œyesâ€ text encoding specified in IETF RFC 4119 is replaced by 0 and 1 respectively. The Retention Expires Relative Present field indicates whether Retention Expires Relative field is present. The value 1 indicates that the Retention Expires Relative field is present; otherwise the Retention Expires Relative field is not present. If the Retention Expires Relative field is not present, it indicates that the retention duration of the LCI report field is unbounded. The STA Location Policy field indicates whether additional STA or neighboring STA location information is available if the additional information can be transferred more securely. The security of the transfer is (from lowest to highest): unassociated, associated without RSNA established, associated with RSNA established but without management frame protection negotiated, and associated with both RSNA established and management frame protection negotiated. The additional information might be one or more of: 1) the STAâ€™s location with reduced uncertainty and 2) the location of additional neighbor APs, if the STA Location Policy field is carried within a Neighbor Report Response frame. A value of 1 indicates additional STA or neighboring STA location information is available. A value of 0 indicates no additional STA or neighboring STA location information is available. The definition of the Retention Expires Relative field is the same as the definition for the retention-expires element in IETF RFC 4119, except that the absolute time text encoding specified in IETF RFC 4119 is replaced by a relative binary encoding: the Retention Expires Relative field is encoded as a number of hours in the future relative to the time of transmission of the Usage Rules/Policy subelement. The Vendor Specific subelement has the same format as the Vendor Specific element (see 9.4.2.26). Multiple Vendor Specific subelements are optionally present in the list of optional subelements. The Co-Located BSSID List subelement is used to report the list of BSSIDs of the BSSs which share the same antenna connector with the reporting STA. The format of the Co-Located BSSID List subelement is shown in Figure 9-224 861 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Subelement MaxBSSID BSSID #1 BSSID #n ID Length Indicator (optional) â€¢â€¢â€¢ (optional) Octets: 1 1 1 6 6 Figure 9-224â€”Co-Located BSSID List subelement format The Subelement ID field is equal to the value for Co-Located BSSID list in Table 9-116. The Length field is defined in 9.4.3. The MaxBSSID Indicator field is as defined in 9.4.2.26. When set to a nonzero value, it indicates the maximum possible number of BSSs, including the reference BSS, which share the same antenna connector and have the same 48-(MaxBSSID indicator field) MSBs of the BSSIDs. When the BSSIDs of the co- located BSSs are configured at the reporting STA but not represented by the MaxMBSSID Indicator field, the BSSID fields are present in the Co-located BSSID List subelement to provide an explicit list of such BSSID values. When the MaxBSSID Indicator field is equal to zero, the BSSID fields contain an explicit list of the BSSID values of the BSSs which share the same antenna connector with the reporting STA. NOTEâ€”For example, if there are 4 BSSs which share the same antenna connector and their BSSIDs end with 16, 24, 30 and 31, and the range of MAC addresses ending with 16-31 inclusive are not assigned to other BSSs using a different antenna connector, then this list of 4 BSSIDs can be indicated with a value of 5 in the MaxBSSID Indicator field. Otherwise, the MaxBSSID Indicator field is set to zero and the BSSIDs are listed separately. 9.4.2.22.11 Transmit Stream/Category Measurement report The Transmit Stream/Category Measurement applies to TIDs for Traffic Streams associated with TSPECs and also to TIDs for Traffic Categories for QoS traffic without TSPECs. The format of the Measurement Report field corresponding to a Transmit Stream/Category Measurement report is shown in Figure 9-225. Actual Measurement Measurement Peer STA Traffic Reporting Transmitted Duration Address Identifier Reason MSDU Count Start Time Octets: 8 2 6 1 1 4 MSDU MSDU Failed MSDU QoS Average Average Discarded Multiple CF-Polls Transmit Count Count Retry Count Lost Count Queue Delay Delay Octets: 4 4 4 4 4 4 Bin 0 Optional Bin 0 Bin 1 Bin 2 Bin 3 Bin 4 Bin 5 Range Subelements Octets: 1 4 4 4 4 4 4 variable Figure 9-225â€”Measurement Report field format for Transmit Stream/ Category Measurement report Actual Measurement Start Time is set to the TSF at the time at which the measurement started, or for a triggered Transmit Stream/Category Measurement report, the TSF value at the reporting QoS STA when the trigger condition was met. 862 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Measurement Duration is set to the duration over which the Transmit Stream/Category Measurement report was measured, in units of TUs. In a triggered Transmit Stream/Category Measurement report, metrics are reported over a number of transmitted MSDUs rather than a duration; hence Measurement Duration is set to 0; see 11.11.9.8. The Peer STA Address contains a MAC address indicating the RA for the measured frames. The Traffic Identifier field contains the TID subfield as shown in Figure 9-172. The TID subfield indicates the TC or TS for which traffic was measured. The Reporting Reason field is a bit field indicating the reason that the measuring QoS STA sent the transmit stream/category measurement report. The Reporting Reason field is shown in Figure 9-226. B0 B1 B2 B3 B7 Average Consecutive Delay Trigger Reserved Trigger Trigger Bits: 1 1 1 5 Figure 9-226â€”Reporting Reason field â€” The Average Trigger bit set to 1 indicates that the Transmit Stream/Category Measurement report was generated as a triggered report due to the Average Error trigger. â€” The Consecutive Trigger bit set to 1 indicates that the Transmit Stream/Category Measurement report was generated as a triggered report due to the Consecutive Error trigger. â€” The Delay Trigger bit set to 1 indicates that the Transmit Stream/Category Measurement report was generated as a triggered report due to the delay exceeding the Delay Threshold. When a Transmit Stream/Category Measurement report is sent as a direct response to a Transmit Stream/ Category Measurement request and not as a triggered Transmit Stream/Category Measurement report, all bit fields in the Reporting Reason field are set to 0. This is termed a requested Transmit Stream/Category Measurement report. Within a triggered Transmit Stream/Category Measurement report, more than one bit field in the Reporting Reason field might be set to 1 if more than one trigger condition was met. The Transmitted MSDU Count, MSDU Failed Count, MSDU Discarded Count, MSDU Multiple Retry Count, QoS CF-Polls Lost Count, Average Queue Delay, Average Transmit Delay, and delay histogram fields relate to transmissions to the QoS STA given in the Peer STA Address field. Metrics are reported over the Measurement Duration, or for triggered transmit stream/category measurements, over the Measurement Count. Any counter that increments to a value of 232â€“1 terminates the measurement. The Transmitted MSDU Count field contains the number of MSDUs for the TC or the TS specified by the TID that were successfully transmitted. The MSDU Discarded Count field contains the number of MSDUs for the TC or the TS specified by the TID that were discarded due either to the number of transmit attempts exceeding dot11ShortRetryLimit or dot11LongRetryLimit (as appropriate), or due to the MSDU lifetime having been reached. The MSDU Failed Count field contains the number of MSDUs for the TC or the TS specified by the TID that were discarded due to the number of transmit attempts exceeding dot11ShortRetryLimit or dot11LongRetryLimit (as appropriate). The MSDU Multiple Retry Count field contains the number of MSDUs for the TC or the TS specified by the TID that were successfully transmitted after more than one retransmission attempt. 863 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The QoS CF-Polls Lost Count field contains the number of QoS (+)CF-Poll frames that were transmitted where there was no response from the QoS STA. QoS CF-Polls Lost Count are returned only if the reporting QoS STA is contained within an AP and the TID is for a TS. This field is set to 0 when QoS CF-Polls Lost Count is not returned. Average Queue Delay is the average queuing delay of the frames (MSDUs) that are passed to the MAC for the indicated peer STA address and the indicated traffic identifier. Queue Delay is expressed in TUs and is measured from the time the MSDU is passed to the MAC until the point at which the first or only fragment begins transmission. Average Transmit Delay is the average delay of the frames (MSDUs) that are successfully transmitted for the indicated Peer STA Address and TID. Average Transmit Delay is measured from the time the MSDU is passed to the MAC until the point at which the entire MSDU has been successfully transmitted, including receipt of the final Ack frame from the peer STA if the QoSAck service class is being used. Average Transmit delay is expressed in units of TUs. Bin 0 Range field value indicates the delay range of the first bin (Bin 0) of the Transmit Delay Histogram, in units of TUs. It is also used to calculate the delay ranges of the other five bins making up the histogram. The delay range for each bin increases in a binary exponential fashion as follows: Bin 0 range: 0 Delay < B0 = Bin 0 Range field value Bin i range: 2iâ€“1 B0 Delay < 2i B0 , for 1 i 4 Bin 5 range: 16 B0 Delay For example, if Bin 0 Range field value is 10 TUs, the bin delay ranges are as defined in Table 9-117. Table 9-117â€”Delay definitions for a Transmit Stream/Category Measurement report for a Bin 0 Range field value of 10 TU Measured MSDU Transmit Delay Bin (TUs) 0 Delay < 10 1 10 Delay < 20 2 20 Delay < 40 3 40 Delay < 80 4 80 Delay < 160 5 160 Delay To compute the value reported in Bin i (i.e., Bi for i = 0, 1...5 of the Transmit Delay Histogram), the STA initializes all bin values to 0. For each MSDU successfully transmitted, the measured MSDU Transmit Delay determines which bin is to be incremented. If the measured delay has a duration time t within Bin i, then Bin i is increased by one. MSDU Transmit Delay is measured from the time the MSDU is passed to the MAC until the point at which the entire MSDU has been successfully transmitted, including receipt of the final Ack frame from the peer STA if the QoSAck service class is being used. The sum of the values in all six bins is equal to the value reported in the Transmitted MSDU Count. 864 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Optional Subelements field contains zero or more subelements. The subelement format and ordering of subelements are defined in 9.4.3. The Subelement ID field values for the defined subelements are shown in Table 9-118. Table 9-118â€”Optional subelement IDs for Transmit Stream/Category Measurement report Subelement ID Name Extensible 0â€“220 Reserved 221 Vendor Specific 222â€“255 Reserved The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26). Multiple Vendor Specific subelements are optionally present in the list of optional subelements. 9.4.2.22.12 Multicast Diagnostics report The format of the Measurement Report field of a Multicast Diagnostics report is shown in Figure 9-227. Multicast Multicast Measurement Measurement Group MAC Time Duration Address Reporting Received MSDU Reason Count Octets: 8 2 6 1 4 First Sequence Last Sequence Multicast Rate Optional Number Number Subelements Octets: 2 2 2 variable Figure 9-227â€”Measurement Report field format for a Multicast Diagnostics report The Measurement Time field is the value of the STA TSF timer at the time the measurement started. In a triggered Multicast Diagnostics report, this is the TSF value at the reporting STA when the trigger condition was met. When the reason for sending the report is Performance Measurement and the Multicast Received MSDU Count is nonzero, the Measurement Time field is the value of the STA TSF timer at the time of the first group addressed MSDU received during the measurement interval. The Measurement Duration field specifies the period over which the Multicast Diagnostic report was generated, in units of TUs. The Group MAC Address field contains the value from the Group MAC Address field from the Multicast Diagnostics request to which the report relates. The Multicast Reporting Reason field indicates the reason why the measuring STA sent the Multicast Diagnostics report. The Multicast Reporting Reason field is shown in Figure 9-228. 865 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B0 B1 B2 B7 Inactivity Measurement Reserved Timeout Trigger Result Bits: 1 1 6 Figure 9-228â€”Multicast Reporting Reason field The subfields of the Multicast Reporting Reason field are defined as follows: â€” The Inactivity Timeout Trigger field set to 1 indicates that Multicast Diagnostics report was generated as a triggered report due to the timeout of the multicast diagnostic timer. â€” The Measurement Result field set to 1 indicates that the Multicast Diagnostic report contains the result of completing a Multicast Diagnostic request that did not contain a Multicast Triggered Reporting subelement. All of the bits in the Multicast Reporting Reason field are independent. The Multicast Received MSDU Count field contains the total number of group addressed MSDUs with the indicated multicast MAC address that were received during the measurement duration. For a triggered multicast diagnostics measurement, the Multicast Received MSDU Count field contains the total number of group addressed MSDUs with the indicated multicast MAC address that were received between the acceptance of the multicast diagnostics measurement request and the occurrence of the trigger condition. When the LSB of the first octet of the Multicast MAC address field in the Multicast Diagnostics request is 1, the twelve LSBs of the First Sequence Number field contain the sequence number of the first frame received with destination address equal to the value in the Multicast MAC address field during the measurement period. When the LSB of the first octet of the Multicast MAC address field in the Multicast Diagnostics request is 0, the twelve LSBs of the First Sequence Number field contain the sequence number of the first group addressed frame, that does not have the broadcast MAC address as its destination, received during the measurement period. The four most significant bits of the First Sequence Number field are set to 0. When the LSB of the first octet of the Multicast MAC address field in the Multicast Diagnostics request is 1, the twelve LSBs of the Last Sequence Number field contain the sequence number of the last frame received with destination address equal to the value in the Multicast MAC address field during the measurement period. When the LSB of the first octet of the Multicast MAC address field in the Multicast Diagnostics request is 0, the twelve LSBs of the Last Sequence Number field contain the sequence number of the last group addressed frame, that does not have the broadcast MAC address as its destination, received during the measurement period. The four most significant bits of the Last Sequence Number field are set to 0. The First Sequence Number field and the Last Sequence Number field are set to 0 if the Multicast Received MSDU Count is 0. The Multicast Rate field specifies the highest data rate, in 0.5 Mb/s units, at which the STA has received a group addressed frame during the measurement period. The Multicast Rate field is encoded with the MSB set to 1 to indicate that the data rate is in the basic rate set, and set to 0 to indicate that the data rate is not in the basic rate set. The remaining 15 bit value is multiplied by 0.5 Mb/s to indicate the data rate. The Multicast Rate field is 0 by the STA to indicate that it has not received a group addressed frame during the measurement period. The Optional Subelements field contains zero or more subelements. The subelement format and ordering of subelements are defined in 9.4.3. The Subelement ID field values for the defined subelements are shown in Table 9-119. 866 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-119â€”Optional subelement IDs for Multicast Diagnostics report Subelement ID Name Extensible 0â€“220 Reserved 221 Vendor Specific 222â€“255 Reserved The Vendor Specific subelement has the same format as the Vendor Specific element (see 9.4.2.26). The summary of fields used in the STA Multicast Diagnostics report is shown in Table 9-120. Table 9-120â€”Summary of fields used in the STA Multicast Diagnostics report Field Measurement Result Triggered Report Measurement Time Yes Yes Measurement Duration Yes Yes Group MAC Address Yes Yes Multicast Reporting Reason Yes Yes Multicast Received MSDU Count Yes Yes First Sequence Number Yes Yes Last Sequence Number Yes Yes Multicast Rate Yes Yes Optional Subelements Optional Optional The use of Multicast Diagnostics report is defined in 11.11.19. 9.4.2.22.13 Location Civic report The Location Civic report includes the location information defined in civic format for the location subject provided in the Location Civic request, as shown in Figure 9-229. Civic Location Location Civic Optional Type Subelement Subelements Octets: 1 variable variable Figure 9-229â€”Location Civic report field format The Civic Location Type field contains the format of location information in the Civic Location field, as indicated in Table 9-100. 867 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The subelement IDs of the Location Civic report are defined in Table 9-121. Table 9-121â€”Subelement IDs for Location Civic report Subelement ID Name Extensible 0 Location Civic 1 Originator Requesting STA MAC Address 2 Target MAC Address 3 Location Reference 4 Location Shape 5 Map Image 6 Reserved 7 Co-Located BSSID List Yes 8â€“220 Reserved 221 Vendor Specific 222â€“255 Reserved The Location Civic Subelement field contains a Location Civic subelement. The Location Civic subelement of the Location Civic report (see Figure 9-229) is formatted according to Figure 9-230. Subelement ID Length Location Civic Octets: 1 1 variable Figure 9-230â€”Location Civic subelement format The Subelement ID is equal to Location Civic as defined in Table 9-121. The Location Civic field contains the location information in the format as indicated in the Civic Location Type field. When the Civic Location Type field is IETF RFC 4776: â€” Location Civic field is formatted according to IETF RFC 4776 starting at the country code field (i.e., excluding the GEOCONF_CIVIC/ OPTION_GEOCONF_CIVIC, N/option-len and what fields) â€” An unknown civic location is indicated by a subelement Length of 0 and a zero-length Location Civic field â€” The Civic Location field follows the little-endian octet ordering When the Civic Location Type field is IETF RFC 4776, the Optional Subelements field optionally includes the Location Reference, Location Shape, Map Image, and Vendor Specific subelements as defined in Table 9-121. When the Civic Location Type field value is Vendor Specific, a Vendor Specific subelement is included in the Optional Subelements field that identifies the Organization Identifier corresponding to the Civic Location Type field. 868 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Optional Subelements field contains zero or more subelements with subelement ID greater than or equal to 1 as listed in Table 9-121. The subelement format and ordering of subelements are defined in 9.4.3. The Originator Requesting STA MAC Address subelement contains the MAC address of the STA that requested the Location Information and it is present whenever the Location Subject field in the corresponding Location Civic request was set to 2. The format of the Originator Requesting STA MAC Address subelement is shown in Figure 9-169. The Target MAC Address subelement contains the MAC address of the STA whose Location Information was requested and it is present whenever the Location Subject field in the corresponding Location Civic request was set to 2. The format of the Target MAC Address subelement is shown in Figure 9-170. The format of the Location Reference subelement is shown in Figure 9-231. Subelement ID Length Location Reference Octets: 1 1 variable Figure 9-231â€”Location Reference subelement format The Location Reference is an ASCII string that defines a position on a floor from which the relative location contained in the Location Shape subelement is offset. A Location Reference value of 0 length indicates that the position of the Location Shape is top north west corner (i.e., 0,0) of the floor plan on which the Location Shape is defined. The format of the Location Shape subelement is shown in Figure 9-232. Location Shape Location Shape Subelement ID Length ID Value Octets: 1 1 1 variable Figure 9-232â€”Location Shape subelement format The Location Shape subelement defines the position in meters, including uncertainty, of the entity being located. A Shape is specified with respect to either a 2-Dimensional or 3-Dimensional Coordinate Reference System where each point in the shape defines the direction from the Location Reference starting point. A positive X-axis value corresponds to an easterly direction relative to the Location Reference; a negative X- axis value corresponds to a westerly direction relative to the Location Reference; a positive Y-axis value corresponds to a northerly direction relative to the Location Reference; a negative Y-axis value corresponds to a southerly direction relative to the Location Reference and the Z-axis value corresponds to the altitude above the horizontal plane at the Location Reference. The Location Shape ID field contains a one-octet identifier that defines the shape contained in the subelement and is one of the values defined in Table 9-122. The Location Shape Value field contains the location shape value for each corresponding Location Shape ID. The formats of Location Shape Values are described in the following text. All shape field value units that are 4-octet single precision floating point values are in meters and are represented by binary32 floating point values as defined in IEEE Std 754-2008, with the least significant bit of the fraction occurring in bit 0 of the field. 869 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-122â€”Location Shape IDs Location Shape ID Name 0 Reserved 1 2-Dimension Point 2 3-Dimension Point 3 Circle 4 Sphere 5 Polygon 6 Prism 7 Ellipse 8 Ellipsoid 9 Arcband 10â€“255 Reserved The format of the 2-Dimension Point Location Shape Value is defined in Figure 9-233. X-coordinate Y-coordinate Octets: 4 4 Figure 9-233â€”2-Dimension Point Location Shape Value format The X-coordinate field contains a 4-octet single precision floating point value. The Y-coordinate field contains a 4-octet single precision floating point value. The format of the 3-Dimension Point Location Shape Value is defined in Figure 9-234. X-coordinate Y-coordinate Z-coordinate Octets: 4 4 4 Figure 9-234â€”3-Dimension Point Location Shape Value format The X-coordinate field contains a 4-octet single precision floating point value. The Y-coordinate field contains a 4-octet single precision floating point value. The Z-coordinate field contains a 4-octet single precision floating point value. The format of the Circle Location Shape Value is defined in Figure 9-235. X-coordinate Y-coordinate Radius Octets: 4 4 4 Figure 9-235â€”Circle Location Shape Value format 870 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The X-coordinate field contains a 4-octet single precision floating point value. The Y-coordinate field contains a 4-octet single precision floating point value. The Radius field contains a 4-octet single precision floating point value. The format of the Sphere Location Shape Value is defined in Figure 9-236. X-coordinate Y-coordinate Z-coordinate Radius Octets: 4 4 4 4 Figure 9-236â€”Sphere Location Shape Value format The X-coordinate field contains a 4-octet single precision floating point value. The Y-coordinate field contains a 4-octet single precision floating point value. The Z-coordinate field contains a 4-octet single precision floating point value. The Radius field contains a 4-octet single precision floating point value. The format of the Polygon Location Shape Value is defined in Figure 9-237. List of 2-Dimension Number of Points Points Octets: 1 variable Figure 9-237â€”Polygon Location Shape Value format The Number of Points field is a 1 octet unsigned integer that specifies the number of points defined in the polygon. The value 0 is reserved. The List of 2-Dimension Points is a sequence of 2D Point field values that define the closed polygon. The format of the Prism Location Shape Value is defined in Figure 9-238. List of 3-Dimension Number of Points Points Octets: 1 variable Figure 9-238â€”Prism Location Shape Value format The Number of Points field is a 1 octet unsigned integer that specifies the number of points defined in the prism. The value 0 is reserved. The List of 3-Dimension Points is a sequence of 3-Dimension Point field values that define the closed prism. The format of the Ellipse Location Shape Value is defined in Figure 9-239. 871 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications X-coordinate Y-coordinate Angle Semi-Major Axis Semi-Minor Axis Octets: 4 4 2 4 4 Figure 9-239â€”Ellipse Location Shape Value format The X-coordinate field contains a 4-octet single precision floating point value. The Y-coordinate field contains a 4-octet single precision floating point value. The Angle field contains a 2-octet unsigned integer between 0 and 359Â°. The Semi-Major Axis field contains a 4-octet single precision floating point value. The Semi-Minor Axis field contains a 4-octet single precision floating point value. The format of the Ellipsoid Location Shape Value is defined in Figure 9-240. X- Y- Z- Semi- Semi- Semi- Angle Vertical coordinate coordinate coordinate Major Axis Minor Axis Axis Octets: 4 4 4 2 4 4 4 Figure 9-240â€”Ellipsoid Location Shape Value format The X-coordinate field contains a 4-octet single precision floating point value. The Y-coordinate field contains a 4-octet single precision floating point value. The Z-coordinate field contains a 4-octet single precision floating point value. The Angle field contains a 2-octet unsigned integer between 0 and 359Â°. The Semi-Major Axis field contains a 4-octet single precision floating point value. The Semi-Minor Axis field contains a 4-octet single precision floating point value. The Semi-Vertical Axis field contains a 4-octet single precision floating point value. The format of the Arcband Location Shape Value is defined in Figure 9-241. X-coordinate Y-coordinate Inner Radius Outer Radius Start Angle Opening Angle Octets: 4 4 4 4 2 2 Figure 9-241â€”Arcband Location Shape Value format The X-coordinate field contains a 4-octet single precision floating point value. The Y-coordinate field contains a 4-octet single precision floating point value. The Inner Radius field contains a 4-octet single precision floating point value. 872 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Outer Radius field contains a 4-octet single precision floating point value. The Start Angle field contains a 2-octet unsigned integer between 0 and 359. The Opening Angle field contains a 2-octet unsigned integer between 0 and 359. The Map Image subelement contains a map reference that is used in combination with the Location Reference and Location Shape subelements. The format of the Map Image subelement is shown in Figure 9-242. Subelement ID Length Map Type Map URL Octets: 1 1 1 variable Figure 9-242â€”Map Image subelement format The Map Type field is a 1-octet unsigned integer that defines the type of map referred to by the Map URL field, as defined in Table 9-123. Table 9-123â€”Map Types Map Type Value Name 0 URL Defined 1 Png 2 Gif 3 Jpeg 4 Svg 5 dxf 6 Dwg 7 Dwf 8 cad 9 Tiff 10 gml 11 Kml 12 Bmp 13 Pgm 14 ppm 15 Xbm 16 Xpm 17 ico 18â€“255 Reserved The Map Type field value â€œURL Definedâ€ indicates the Map URL field value has a file extension, defined as a mime type and is self-descriptive. 873 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Map URL field is a variable-length field formatted in accordance with IETF RFC 3986 and provides the location of a floor map. The Co-Located BSSID List subelement is used to report the list of BSSIDs of the BSSs that share the same antenna connector with the reporting STA. The Co-Located BSSID List subelement is described in 9.4.2.22.10. The Vendor Specific subelement has the same format as the Vendor Specific element (see 9.4.2.26). 9.4.2.22.14 Location Identifier report The Location Identifier report includes an indirect reference to the location information for the location subject provided in the Location Identifier request, as shown in Figure 9-243. Zero or more Expiration TSF Public Identifier URI/ Optional FQDN Subelement Subelements Octets: 8 variable variable Figure 9-243â€”Location Identifier report field format The Expiration TSF field is the value of the TSF when the Public Identifier URI/FQDN subelement(s) that indicate a location object are no longer valid. The Expiration TSF field set to 0 indicates the Public Identifier URI/FQDN subelement(s) that indicate a location object do not expire. The Public Identifier URI/FQDN Subelement field contains zero or more Public Identifier URI/FQDN subelements. The subelement IDs for the Location Identifier report are shown in Table 9-124. Table 9-124â€”Subelement IDs for Location Identifier report Subelement ID Name Extensible 0 Public Identifier URI/FQDN 1 Originator Requesting STA MAC Address 2 Target MAC Address 3â€“220 Reserved 221 Vendor Specific 222â€“255 Reserved The Public Identifier URI/FQDN subelement of the Location Identifier report (see Figure 9-243) is formatted according to Figure 9-244. 874 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Subelement ID Length URI/FQDN Public Identifier Descriptor URI/FQDN Octets: 1 1 1 variable Figure 9-244â€”Public Identifier URI/FQDN subelement format The Subelement ID is equal to Public Identifier URI/FQDN as defined in Table 9-124. The URI/FQDN Descriptor field describes the Public Identifier URI/FQDN field. The URI/FQDN Descriptor field is defined in Table 9-125. Table 9-125â€”URI/FQDN Descriptor field values Value Usage 0 Reserved 1 The uniform resource locator (URI) of the Hypertext Transfer Protocol (HTTP) enabled location delivery (HELD) location object [IETF RFC 5985] 2 Fully qualified domain name of D-SLP SUPL server (excludes port number) [OMA OMA-TS-ULP-V2_0_1] (or higher version) 3â€“255 Reserved The Public Identifier URI/FQDN field contains a URI encoded using UTF-8 and formatted in accordance with IETF RFC 3986 that points to a location object or an FQDN that identifies a location server. A Public Identifier URI/FQDN field that points to a location object can be used to return the location value for the requesting STA. The format of the location value returned when the URI is dereferenced is dependent on the provider of the URI as indicated by the URI/FQDN Descriptor field. The Public Identifier URI field confirms the validity of the location estimate to an external agent when a STA forwards a location estimate to that agent. The protocol used to query the infrastructure for a location report based on the Public Identifier URI field is beyond the scope of this standard. A Public Identifier URI/FQDN field that points to a location server can be used to discover the location server and establish communications with it. The protocol used with the location server is indicated by the URI/FQDN Descriptor field. The Optional Subelements field contains zero or more subelements with subelement ID greater than or equal to 1 as listed in Table 9-124. The subelement format and ordering of subelements are defined in 9.4.3. The Originator Requesting STA MAC Address subelement contains the MAC address of the STA that requested the Location Information and it is present whenever the Location Subject field in the corresponding Location Identifier request was set to 2. The format of the Originator Requesting STA MAC Address subelement is shown in Figure 9-169. The Target MAC Address subelement contains the MAC address of the STA whose Location Information was requested and it is present whenever the Location Subject field in the corresponding Location Identifier request was set to 2. The format of the Target MAC Address subelement is shown in Figure 9-170. The Vendor Specific subelement has the same format as the Vendor Specific element (see 9.4.2.26). 875 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.22.15 Directional Channel Quality report The format of the Measurement Report field of a Directional Channel Quality report is shown in Figure 9-245. Operating Channel Measurement Measurement Class Number AID Reserved Method Start Time Octets: 1 1 1 1 1 8 Measurement Number of Time Measurement for Measurement for Optional â€¦ Duration Blocks (N) Time Block 1 Time Block N Subelements Octets: 2 1 1 1 Variable Figure 9-245â€”Measurement report field format for Directional Channel Quality report Operating Class field indicates the channel set for which the measurement report applies. Operating Class and Channel Number together specify the channel frequency and spacing for which the measurement report applies. Valid values of Operating Class are shown in Annex E. Channel Number field indicates the channel number for which the measurement report applies. Channel Number is defined within an Operating Class as shown in Annex E. The AID field indicates the Target STA. The Measurement Method field indicates the method used by the STA to carry out this measurement request and the format of the Measurement for Time Block field(s). If this field is set to 0, it indicates that the Measurement for Time Block fields are expressed in ANIPI. If this field is set to 1, it indicates that the Measurement for Time Block fields are expressed in RSNI. Other values are reserved. Measurement Start Time field is set to the value of the measuring STAâ€™s TSF timer at the time the measurement started. The Measurement Duration field is set to the duration of the measurement, in units of TUs. The Number of Time Blocks field indicates the number of time blocks within the measurement duration. The ratio (Measurement Duration/Number of Time Blocks) provides the duration of an individual measurement unit. The Measurement for Time Block fields are set to the ANIPI or average RSNI value measured during each (Measurement Duration/Number of Time Blocks) measurement units. The measurement units are set in the report in increasing order of start times. ANIPI is set to the average noise plus interference power value measured during the indicated Measurement Duration using the same units and accuracy as defined for ANPI in 11.11.9.4. Average RSNI is set according to 9.4.2.41, where RCPI is defined in 9.4.2.38. The Optional Subelements field contains zero or more subelements. The subelement format and ordering of subelements are defined in 9.4.3. The Subelement ID field values for the defined subelements are shown in Table 9-126. The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26). Multiple Vendor Specific subelements can be included in the list of Optional Subelements. 876 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-126â€”Optional subelement IDs for Directional Channel Quality report Subelement ID Name Extensible 0â€“220 Reserved 221 Vendor Specific 222â€“255 Reserved 9.4.2.22.16 Directional Measurement report The format of the Measurement Report field of a Directional Measurement report is shown in Figure 9-246. Measurement Operating Channel Measurement Duration Measurement Measurement Optional Class Number Start Time Method Results Subelements per Direction Octets 1 1 8 2 1 Variable Variable Figure 9-246â€”Measurement Report field format for Directional Measurement report Operating Class field indicates the channel set for which the measurement report applies. Operating Class and Channel Number together specify the channel frequency and spacing for which the measurement report applies. Valid values of Operating Class are shown in Annex E. Channel Number field indicates the channel number for which the measurement report applies. Channel Number is defined within an Operating Class as shown in Annex E. The Measurement Start Time field is set to the value of the measuring STAâ€™s TSF timer at the time the measurement started. The Measurement Duration per Direction field is set to the duration of the measurement in each receiving direction, in units of TUs. The Measurement Method field indicates the method used by the STA to carry out the measurement request and the format of values in the Measurement for Direction fields. If this field is set to 0, it indicates that the values in the Measurement for Direction fields are expressed in ANIPI. If this field is set to 1, it indicates that the values in the Measurement for Direction fields are expressed in RCPI. If this field is set to 2, it indicates that the values in the Measurement for Direction fields are expressed in Channel Load. Other values are reserved. ANIPI is defined in 9.4.2.22.15. RCPI is a logarithmic indication of the received channel power of the corresponding Link Measurement Request frame, as defined in 9.4.2.38. The format of the Measurement Results field is shown in Figure 9-247. The Measurement for Direction fields are set to the format of values specified in the Measurement Method field. Number of Measurement for Measurement for â€¦ Measurement for Directions Direction 1 Direction 2 Direction N Octets: 1 Variable Variable â€¦ Variable Figure 9-247â€”Measurement Results field format 877 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Optional Subelements field contains zero or more subelements. The subelement format and ordering of subelements are defined in 9.4.3. The Subelement ID field values for the defined subelements are shown in Table 9-127. Table 9-127â€”Optional subelement IDs for Directional Measurement report Subelement ID Name Extensible 0â€“220 Reserved 221 Vendor Specific 222â€“255 Reserved The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26). Multiple Vendor Specific subelements can be included in the list of Optional Subelements. 9.4.2.22.17 Directional Statistics report The format of the Measurement Report field of a Directional Statistics report is shown in Figure 9-248. Measurement Directional Operating Channel Measurement Measurement Measurement Optional Class Number Start Time Duration per Method Statistics Results Subelements Direction Bitmap Octets 1 1 8 2 1 1 Variable Variable Figure 9-248â€”Measurement Report field format for Directional Statistics report Operating Class field indicates the channel set for which the measurement report applies. Operating Class and Channel Number together specify the channel frequency and spacing for which the measurement report applies. Valid values of Operating Class are shown in Annex E. Channel Number field indicates the channel number for which the measurement report applies. Channel Number is defined within an Operating Class as shown in Annex E. The Measurement Start Time field is set to the value of the measuring STAâ€™s TSF timer at the time the measurement started. The Measurement Duration per Direction field is set to the duration of the measurement in each receiving direction, in units of TUs. The Measurement Method field indicates the method used by the STA to carry out the measurement request and the format of values in the Measurement Results field. If this field is set to 0, it indicates that the values in the Measurement Results field are expressed in ANIPI. If this field is set to 1, it indicates that the values in the Measurement Results field are expressed in RCPI. If this field is set to 2, it indicates that the values in the Measurement Results field are expressed in Channel Load. Other values are reserved. The Directional Statistics Bitmap field format is described in 9.4.2.21.18. When the Maximum field is set, it indicates that the maximum measurement result among all directions is included in the Measurement Results field. When the Minimum field is set, it indicates that the minimum measurement result among all directions is included in the Measurement Results field. If the Average field is set, it indicates that the average 878 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications measurement result among all directions is included in the Measurement Results field. If the Variance field is set, it indicates that the variance of measurement results among all directions is included in the Measurement Results field. Other bits are reserved. The Measurement Results field is set based on the values in the Measurement Method field and the Directional Statistics Bitmap field. If two or more subfields in the Directional Statistics Bitmap are set to 1, the corresponding measurement results are included in the Measurement Results field in the same sequence as they appear in the Directional Statistics Bitmap field. The Optional Subelements field contains zero or more subelements. The subelement format and ordering of subelements are defined in 9.4.3. The Subelement ID field values for the defined subelements are shown in Table 9-128. Table 9-128â€”Optional subelement IDs for Directional Statistics report Subelement ID Name Extensible 0â€“220 Reserved 221 Vendor Specific 222â€“255 Reserved The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26). Multiple Vendor Specific subelements can be included in the list of Optional Subelements. 9.4.2.22.18 Fine Timing Measurement Range report The format of the Measurement Report field corresponding to a Fine Timing Measurement Range report is shown in Figure 9-249. Range Entry Range Entry Error Entry Error Entry Optional Sub- Count Count elements Octets: 1 M x 15 1 N x 11 variable Figure 9-249â€”Measurement Report field format for a Fine Timing Measurement Range report The Range Entry Count field indicates the number of Range Entry fields (i.e., M in Figure 9-249). The Range Entry field indicates parameters relating to a successful range measurement with a single AP and is formatted according to Figure 9-250. Measurement BSSID Range Max Range Reserved Start Time Error Exponent Octets: 4 6 3 1 1 Figure 9-250â€”Range Entry field format 879 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Measurement Start Time field contains the least significant 4 octets of the TSF (synchronized with the associated AP) at the time (Â± 32 Âµs) at which the initial Fine Timing Measurement frame was transmitted where the timestamps of both the frame and response frame were successfully measured. The BSSID field contains the BSSID of the AP whose range is being reported. The Range field indicates the estimated range between the requested STA and the AP using the FTM procedure, in units of 1/4096 m. A value of 224â€“1 indicates a range of (224â€“1)/4096 m or higher. See 11.11.9.11. The Max Range Error Exponent field contains an upper bound for the error in the value specified in the Range field. A value of zero indicates an unknown error. A nonzero value indicates a maximum range error Max Range Error Exponent â€“ 13 of 2 m. The Max Range Error Exponent field has a maximum value of 25. Values in the range 26â€“255 are reserved. A value of 25 indicates a maximum range error of 4096 m or higher. For example, a value of 14 in the Max Range Error Exponent field indicates that the value in the Range field has a maximum error of Â±2 m. The Error Entry Count field indicates the number of Error Entry fields (i.e., N in Figure 9-249). The Error Entry field indicates parameters relating to a failed range measurement with a single AP and is formatted according to Figure 9-251. Measurement BSSID Error Code Start Time Octets: 4 6 1 Figure 9-251â€”Error Entry field format The Measurement Start Time field contains the least significant 4 octets of the TSF (synchronized with the associated AP) at the time (Â± 32 Âµs) at which the FTM failure was first detected. The BSSID field contains the BSSID of the AP whose range was attempted to be measured. The Error Code field is defined in Table 9-129. Table 9-129â€”Error Code field values Error Code Meaning 0â€“1 Reserved 2 AP reported â€œRequest incapableâ€ 3 AP reported â€œRequest failed. Do not send new request for a specified periodâ€ 4â€“7 Reserved 8 Unable to successfully transmit to AP 9â€“255 Reserved The Optional Subelements field contains zero or more subelements. The subelement format and ordering of subelements are defined in 9.4.3. 880 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Subelement ID field values for the defined subelements are shown in Table 9-130. Table 9-130â€”Optional subelement IDs for Fine Timing Measurement Range report Subelement ID Name Extensible 0â€“220 Reserved 221 Vendor Specific 222â€“255 Reserved The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26). Multiple Vendor Specific subelements can be included in the list of Optional Subelements. 9.4.2.23 Quiet element The Quiet element defines an interval during which no transmission occurs in the current channel. This interval might be used to assist in making channel measurements without interference from other STAs in the BSS. The format of the Quiet element is shown in Figure 9-252. Quiet Quiet Quiet Quiet Element ID Length Count Period Duration Offset Octets: 1 1 1 1 2 2 Figure 9-252â€”Quiet element format The Element ID and Length fields are defined in 9.4.2.1. The Quiet Count field is set to the number of TBTTs until the beacon interval during which the next quiet interval starts. A value of 1 indicates the quiet interval starts during the beacon interval starting at the next TBTT. A value of 0 is reserved. The Quiet Period field is set to the number of beacon intervals between the start of regularly scheduled quiet intervals defined by this Quiet element. A value of 0 indicates that no periodic quiet interval is defined. The Quiet Duration field is set to the duration of the quiet interval, expressed in TUs. The Quiet Offset field is set to the offset of the start of the quiet interval from the TBTT specified by the Quiet Count field, expressed in TUs. The value of the Quiet Offset field is less than one beacon interval. The Quiet element is optionally present in Beacon frames, as described in 9.3.3.3, and Probe Response frames, as described in 9.3.3.11. The use of Quiet elements is described in 11.9.3. 9.4.2.24 IBSS DFS element The IBSS DFS element contains information for DFS operation in an IBSS. The format of the IBSS DFS element is shown in Figure 9-253. 881 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Channel Map Element ID Length DFS DFS Recovery (see Owner Interval Figure 9-254) Octets: 1 1 6 1 2Ã—n Figure 9-253â€”IBSS DFS element format The Element ID and Length fields are defined in 9.4.2.1. The DFS Owner field is set to the individual IEEE MAC address of the STA that is the currently known DFS Owner in the IBSS. The DFS Recovery Interval field indicates the time interval that is used for DFS owner recovery, expressed as an integer number of beacon intervals. The DFS Recovery Interval value is static throughout the lifetime of the IBSS and is determined by the STA that starts the IBSS. The Channel Map field shown in Figure 9-254 contains a Channel Number field and a Map field (see 9.4.2.22.2) for each channel supported by the STA transmitting the IBSS DFS element. Note that n in Figure 9-253 is the number of channels supported by the STA. Channel Map n tuples, one for each Number supported channel Octets: 1 1 Figure 9-254â€”Channel Map field format The IBSS DFS element is optionally present in Beacon frames, as described in 9.3.3.3, and Probe Response frames, as described in 9.3.3.11. The use of IBSS DFS elements is described in 11.9.8.3. 9.4.2.25 RSNE 9.4.2.25.1 General The RSNE contains the information required to establish an RSNA. The format of the RSNE is defined in Figure 9-255. Group Data Pairwise Cipher Pairwise Cipher Element ID Length Version Cipher Suite Suite Count Suite List Octets: 1 1 2 0 or 4 0 or 2 0 or (4 Ã— m) AKM Suite AKM Suite RSN PMKID Group PMKID List Management Count List Capabilities Count Cipher Suite Octets: 0 or 2 0 or (4 Ã— n) 0 or 2 0 or 2 0 or (16 Ã— s) 0 or 4 Figure 9-255â€”RSNE format The Element ID and Length fields are defined in 9.4.2.1. The size of the RSNE is limited by the size of an element, which is 255 octets. Therefore, the number of pairwise cipher suites, AKM suites, and PMKIDs is limited. 882 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications In Figure 9-255, m denotes the pairwise cipher suite count, n the AKM suite count, and s is the PMKID count. All fields use the bit convention from 9.2.2. The RSNE contains up to and including the Version field. All fields after the Version field are optional. If any nonzero-length field is absent, then none of the subsequent fields is included. The Version field indicates the version number of the RSN protocol. Version 1 is defined in this standard. Other values are reserved. NOTEâ€”The following represent sample elements: 802.1X authentication, CCMP-128 pairwise and group data cipher suites (WEP-40, WEP-104, and TKIP not allowed): 30, // element id, 48 expressed as hexadecimal value 14, // length in octets, 20 expressed as hexadecimal value 01 00, // Version 1 00 0F AC 04, // CCMP-128 as group data cipher suite 01 00, // pairwise cipher suite count 00 0F AC 04, // CCMP-128 as pairwise cipher suite 01 00, // authentication count 00 0F AC 01 // IEEE 802.1X authentication 00 00 // No capabilities 802.1X authentication, CCMP-128 pairwise and group data cipher suites (WEP-40, WEP-104 and TKIP not allowed), preauthentication supported: 30, // element id, 48 expressed as hexadecimal value 14, // length in octets, 20 expressed as hexadecimal value 01 00, // Version 1 00 0F AC 04, // CCMP-128 as group data cipher suite 01 00, // pairwise cipher suite count 00 0F AC 04, // CCMP-128 as pairwise cipher suite 01 00, // authentication count 00 0F AC 01 // IEEE 802.1X authentication 01 00 // Preauthentication capabilities 802.1X authentication, Use GTK for pairwise cipher suite, WEP-40 group data cipher suites, optional RSN Capabilities field omitted: 30, // element id, 48 expressed as hexadecimal value 12, // length in octets, 18 expressed as hexadecimal value 01 00, // Version 1 00 0F AC 01, // WEP-40 as group data cipher suite 01 00, // pairwise cipher suite count 00 0F AC 00, // Use group cipher suite as pairwise cipher suite 01 00, // authentication count 00 0F AC 01 // IEEE 802.1X authentication 802.1X authentication, Use CCMP-128 for pairwise cipher suite, CCMP-128 group data cipher suites, preauthentication and a PMKID: 30, // element id, 48 expressed as hexadecimal value 26 // length in octets, 38 expressed as hexadecimal value 01 00, // Version 1 00 0F AC 04, // CCMP-128 as group data cipher suite 01 00, // pairwise cipher suite count 00 0F AC 04, // CCMP-128 as pairwise cipher suite 01 00, // authentication count 00 0F AC 01 // IEEE 802.1X authentication 01 00 // Preauthentication capabilities 01 00 // PMKID Count 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 // PMKID 802.1X authentication, CCMP-128 pairwise and group data cipher suites (WEP-40, WEP-104, and TKIP are not allowed), and management frame protection with AES-128-CMAC as the group management suite selector. 30, // element id, 48 expressed as hexadecimal value 1A, // length in octets, 26 expressed as hexadecimal value 01 00, // Version 1 883 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 00 0F AC 04, // CCMP-128 as group data cipher suite 01 00, // pairwise cipher suite count 00 0F AC 04, // CCMP-128 as pairwise cipher suite 01 00, // authentication count 00 0F AC 01 // IEEE 802.1X authentication 80 00 // management frame protection is enabled but not required 00 00 // No PMKIDs 00 0F AC 06, // BIP-CMAC-128 as the broadcast/multicast management cipher suite 9.4.2.25.2 Cipher suites The Group Data Cipher Suite field contains the cipher suite selector used by the BSS to protect group addressed frames. The Pairwise Cipher Suite Count field indicates the number of pairwise cipher suite selectors that are contained in the Pairwise Cipher Suite List field. The value 0 is reserved. The Pairwise Cipher Suite List field contains a series of cipher suite selectors that indicate the pairwise cipher suites. The Group Management Cipher Suite field contains the cipher suite selector used by the BSS to protect group addressed robust Management frames. When management frame protection is negotiated, the negotiated pairwise cipher suite is used to protect individually addressed robust Management frames, and the group management cipher suite is used to protect group addressed robust Management frames. Use of AES-128-CMAC is not valid as a data cipher suite. A suite selector has the format shown in Figure 9-256. OUI Suite Type Octets: 3 1 Figure 9-256â€”Suite selector format The OUI field contains an OUI or CID. The order of the OUI (organizationally unique identifier) field is described in 9.2.2. Table 9-131 provides the cipher suite selectors defined by this standard. Table 9-131â€”Cipher suite selectors OUI Suite type Meaning 00-0F-AC 0 Use group cipher suite 00-0F-AC 1 WEP-40 00-0F-AC 2 TKIP 00-0F-AC 3 Reserved 00-0F-AC 4 CCMP-128 00-0F-AC 5 WEP-104 00-0F-AC 6 BIP-CMAC-128 884 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-131â€”Cipher suite selectors (continued) OUI Suite type Meaning 00-0F-AC 7 Group addressed traffic not allowed 00-0F-AC 8 GCMP-128 00-0F-AC 9 GCMP-256 00-0F-AC 10 CCMP-256 00-0F-AC 11 BIP-GMAC-128 00-0F-AC 12 BIP-GMAC-256 00-0F-AC 13 BIP-CMAC-256 00-0F-AC 14â€“255 Reserved Other OUI or CID Any Vendor-specific In non-DMG RSNA, the cipher suite selector 00-0F-AC:4 (CCMP-128) is the default group cipher suite for Data frames when the Group Data Cipher Suite field is not included in the RSNE. In non-DMG RSNA, the cipher suite selector 00-0F-AC:4 (CCMP-128) is the default pairwise cipher suite when the Pairwise Cipher Suite List field is not included in the RSNE. In DMG RSNA, the cipher suite selector 00-0F-AC:8 (GCMP-128) is the default group cipher suite for Data frames when the Group Data Cipher Suite field is not included in the RSNE. In DMG RSNA, the cipher suite selector 00-0F-AC:8 (GCMP-128) is the default pairwise cipher suite when the Pairwise Cipher Suite List field is not included in the RSNE. In an RSNA with management frame protection enabled, the cipher suite selector 00-0F-AC:6 (BIP-CMAC- 128) is the default group cipher suite for Management frames when the Group Management Cipher Suite field is not included in the RSNE. The cipher suite selectors 00-0F-AC:1 (WEP-40) and 00-0F-AC:5 (WEP-104) are only valid as a group cipher suite in a transition security network (TSN) to allow pre-RSNA STAs to join an IBSS or to associate with an infrastructure BSS. Use of any group cipher suite other than TKIP, WEP-104, or WEP-40 with TKIP as the pairwise cipher suite is not supported. The cipher suite selector 00-0F-AC:0 (Use group cipher suite) is valid only as the pairwise cipher suite. An AP specifies the selector 00-0F-AC:0 (Use group cipher suite) for a pairwise cipher suite if it does not support any pairwise cipher suites. If an AP specifies 00-0F-AC:0 (Use group cipher suite) as the pairwise cipher selection, this is the only pairwise cipher selection the AP advertises. If any cipher suite other than TKIP, WEP-104, or WEP-40 is enabled, then the AP supports pairwise keys, and thus the suite selector 00-0F-AC:0 (Use group cipher suite) is not a valid option. Table 9-132 indicates the circumstances under which each cipher suite is used. 885 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-132â€”Cipher suite usage Cipher suite selector GTK PTK IGTK Use group cipher suite No Yes No WEP-40 Yes No No WEP-104 Yes No No TKIP Yes Yes No CCMP-128 Yes Yes No BIP-CMAC-128 No No Yes GCMP-128 Yes Yes No GCMP-256 Yes Yes No CCMP-256 Yes Yes No BIP-GMAC-128 No No Yes BIP-GMAC-256 No No Yes BIP-CMAC-256 No No Yes 9.4.2.25.3 AKM suites The AKM Suite Count field indicates the number of AKM suite selectors that are contained in the AKM Suite List field. The value 0 is reserved. The AKM Suite List field contains a series of AKM suite selectors. In an IBSS only a single AKM suite selector is specified because IBSS STAs use the same AKM suite and because there is no mechanism to negotiate the AKMP in an IBSS (see 12.6.5). Each AKM suite selector specifies an AKMP. Table 9-133 gives the AKM suite selectors defined by this standard. An AKM suite selector has the format shown in Figure 9-256. Table 9-133â€”AKM suite selectors Meaning Suite OUI type Key derivation Authentication type Key management type type 00-0F-AC 0 Reserved Reserved Reserved 00-0F-AC 1 Authentication negotiated RSNA key management as Defined in over IEEE Std 802.1X or defined in 12.7 or using 12.7.1.2 using PMKSA caching as PMKSA caching as defined in defined in 12.6.10.3 12.6.10.3 00-0F-AC 2 PSK RSNA key management as Defined in defined in 12.7, using PSK 12.7.1.2 00-0F-AC 3 FT authentication negotiated FT key management as Defined in over IEEE Std 802.1X defined in 12.7.1.7 12.7.1.7.2 using SHA-256 886 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-133â€”AKM suite selectors (continued) Meaning Suite OUI type Key derivation Authentication type Key management type type 00-0F-AC 4 FT authentication using PSK FT key management as Defined in defined in 12.7.1.7 12.7.1.7.2 using SHA-256 00-0F-AC 5 Authentication negotiated RSNA key management as Defined in over IEEE Std 802.1X or defined in 12.7 or using 12.7.1.7.2 using using PMKSA caching as PMKSA caching as defined in SHA-256 defined in 12.6.10.3 12.6.10.3 00-0F-AC 6 PSK RSNA Key Management as Defined in defined in 12.7 using PSK 12.7.1.7.2 using SHA-256 00-0F-AC 7 TDLS TPK handshake Defined in 12.7.1.7.2 using SHA-256 00-0F-AC 8 SAE authentication with RSNA key management as Defined in SHA-256 or using PMKSA defined in 12.7, PMKSA 12.7.1.7.2 using caching as defined in caching as defined in SHA-256 12.6.10.3 12.6.10.3 or authenticated mesh peering exchange as defined in 14.5 00-0F-AC 9 FT authentication over SAE FT key management defined Defined in in 12.7.1.7 12.7.1.7.2 using SHA-256 00-0F-AC 10 APPeerKey Authentication RSNA key management as Defined in with SHA-256 or using defined in 12.7 or using 12.7.1.7.2 using PMKSA caching as defined in PMKSA caching as defined in SHA-256 12.6.10.3 12.6.10.3 00-0F-AC 11 Authentication negotiated RSNA key management as Defined in over IEEE Std 802.1X or defined in 12.7 or using 12.7.1.7.2 using using PMKSA caching as PMKSA caching as defined in SHA-256 defined in 12.6.10.3 using a 12.6.10.3 Suite B compliant EAP method supporting SHA-256 00-0F-AC 12 Authentication negotiated RSNA key management as Defined in over IEEE Std 802.1X or defined in 12.7 or using 12.7.1.7.2 using using PMKSA caching as PMKSA caching as defined in SHA-384 defined in 12.6.10.3 using a 12.6.10.3 Suite B compliant EAP method supporting SHA-384 00-0F-AC 13 FT authentication negotiated FT key management as Defined in over IEEE Std 802.1X defined in 12.7.1.7 12.7.1.7.2 using SHA-384 00-0F-AC 14â€“255 Reserved Reserved Reserved Other OUI or Any Vendor-specific Vendor-specific Vendor-specific CID 887 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The AKM suite selector value 00-0F-AC:1 (i.e., Authentication negotiated over IEEE Std 802.1X with RSNA key management as defined in 12.7 or using PMKSA caching as defined in 12.6.10.3) is the default AKM suite when the AKM Suite List field is not included in the RSNE. NOTEâ€”The selector value 00-0F-AC:1 specifies only that IEEE Std 802.1X-2010 is used as the authentication transport. IEEE Std 802.1X-2010 selects the authentication mechanism. The AKM suite selector value 00-0F-AC:8 (i.e., SAE authentication with SHA-256 or using PMKSA caching as defined in 12.6.10.3 with SHA-256 key derivation) is used when either a password or PSK is used with RSNA key management. NOTEâ€”Selector values 00-0F-AC:1 and 00-0F-AC:8 can simultaneously be enabled by an Authenticator. The AKM suite selector value 00-0F-AC:2 (PSK) is used when an alternate form of PSK is used with RSNA key management. NOTEâ€”Selector values 00-0F-AC:1 and 00-0F-AC:2 can simultaneously be enabled by an Authenticator. The AKM suite selector value 00-0F-AC:11 is used only with cipher suite selector values 00-0F-AC:8 (GCMP-128) and 00-0F-AC:11 (BIP-GMAC-128). The AKM suite selector value 00-0F-AC:12 is used only with cipher suite selector values 00-0F-AC:9 (GCMP-256), 00-0F-AC:10 (CCMP-256), 00-0F-AC:13 (BIP-CMAC-256), and 00-0F-AC:12 (BIP-GMAC-256). The AKM suite selector value 00-0F-AC:13 is used only with cipher suite selector values 00-0F-AC:9 (GCMP-256), 00-0F-AC:10 (CCMP-256), 00-0F- AC:13 (BIP-CMAC-256), and 00-0F-AC:12 (BIP-GMAC-256). 9.4.2.25.4 RSN capabilities The RSN Capabilities field indicates requested or advertised capabilities. If the RSN Capabilities field is not present, the default value of 0 is used for all of the capability subfields. The length of the RSN Capabilities field is 2 octets. The format of the RSN Capabilities field is as illustrated in Figure 9-257 and described after the figure. B0 B1 B2 B3 B4 B5 B6 B7 Management Frame Management Frame Preauthenti No Pairwise PTKSA Replay GTKSA Replay Protection Required Protection Capable cation Counter Counter (MFPR) (MFPC) Bits: 1 1 2 2 1 1 B8 B9 B10 B11 B12 B13 B14 B15 Extended Key ID for Joint Multi- PeerKey SPP A-MSDU SPP A-MSDU Band RSNA Enabled Capable Required PBAC Individually Reserved Addressed Frames Bits: 1 1 1 1 1 1 2 Figure 9-257â€”RSN Capabilities field format â€” Bit 0: Preauthentication. An AP sets the Preauthentication subfield of the RSN Capabilities field to 1 to signal it supports preauthentication (see 12.6.10.2) and sets the subfield to 0 when it does not support preauthentication. A non-AP STA sets the Preauthentication subfield to 0. 888 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” Bit 1: No Pairwise. If a STA supports WEP default key 0 simultaneously with a pairwise key (see 12.7.1), then the STA sets the No Pairwise subfield of the RSN Capabilities field to 0. If a STA does not support WEP default key 0 simultaneously with a pairwise key (see 12.7.1), then the STA sets the No Pairwise subfield of the RSN Capabilities field to 1. The No Pairwise subfield describes a capability of a non-AP STA. IBSS STAs and APs set the No Pairwise subfield to 0. The No Pairwise subfield is set to 1 only in a TSN and when the pairwise cipher suite selected by the STA is TKIP. â€” Bits 2â€“3: PTKSA Replay Counter. A STA sets the PTKSA Replay Counter subfield of the RSN Capabilities field to the value contained in dot11RSNAConfigNumberOfPTKSAReplayCounters. The least significant bit (LSB) of dot11RSNAConfigNumberOfPTKSAReplayCounters is put in bit 2. See 12.5.2.6 and 12.5.3.4.4. The meaning of the value in the PTKSA/GTKSA/STKSA Replay Counter subfield is defined in Table 9-134. The number of replay counters per STKSA is the same as the number of replay counters per PTKSA. Table 9-134â€”PTKSA/GTKSA/STKSA replay counters usage Replay counter value Meaning 0 1 replay counter per PTKSA/GTKSA/STKSA 1 2 replay counters per PTKSA/GTKSA/STKSA 2 4 replay counters per PTKSA/GTKSA/STKSA 3 16 replay counters per PTKSA/GTKSA/STKSA â€” Bits 4â€“5: GTKSA Replay Counter. A STA sets the GTKSA Replay Counter subfield of the RSN Capabilities field to the value contained in dot11RSNAConfigNumberOfGTKSAReplayCounters. The LSB of dot11RSNAConfigNumberOfGTKSAReplayCounters is put in bit 4. See 12.5.2.6 and 12.5.3.4.4. The meaning of the value in the GTKSA Replay Counter subfield is defined in Table 9- 134. â€” Bit 6: Management Frame Protection Required (MFPR). A STA sets this bit to 1 to advertise that protection of robust Management frames is mandatory. A STA sets this bit to 1 when dot11RSNAProtectedManagementFramesActivated is true and dot11RSNAUnprotectedManagementFramesAllowed is false; otherwise it sets this bit to 0. If a STA sets this bit to 1, then that STA only allows RSNAs with STAs that provide Management Frame Protection. â€” Bit 7: Management Frame Protection Capable (MFPC). A STA sets this bit to 1 when dot11RSNAProtectedManagementFramesActivated is true to advertise that protection of robust Management frames is enabled. â€” Bit 8: Joint Multi-band RSNA. A STA sets the Joint Multi-band RSNA subfield to 1 to indicate that it supports the Joint Multi-band RSNA (12.6.22). Otherwise, this subfield is set to 0. â€” Bits 9: PeerKey Enabled. An AP STA sets the PeerKey Enabled subfield of the RSN Capabilities field to 1 to signal it supports PeerKey handshake (see 12.7.8). Otherwise, this subfield is set to 0. â€” Bit 10: SPP A-MSDU Capable. A STA sets the SPP A-MSDU Capable subfield of the RSN Capabilities field to 1 to signal that it supports signaling and payload protected A-MSDUs (SPP A-MSDUs) (see 11.19). Otherwise, this subfield is set to 0. â€” Bit 11: SPP A-MSDU Required. A STA sets the SPP A-MSDU Required subfield of the RSN Capabilities field to 1 when it allows only SPP A-MSDUs (i.e., does not send or receive payload protected A-MSDUs (PP A-MSDUs) (see 11.19). Otherwise, this subfield is set to 0. â€” Bit 12: PBAC (protected block ack agreement capable). A STA sets the PBAC subfield of RSN Capabilities field to 1 to indicate it is PBAC. Otherwise, this subfield is set to 0. 889 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” Bit 13: Extended Key ID for Individually Addressed Frames. This subfield is set to 1 to indicate that the STA supports Key ID values in the range 0 to 1 for a PTKSA and STKSA when the cipher suite is CCMP or GCMP. A value of 0 indicates that the STA only supports Key ID 0 for a PTKSA and STKSA. â€” Bits 14â€“15: Reserved. The remaining subfields of the RSN Capabilities field are reserved. 9.4.2.25.5 PMKID The PMKID Count and List fields are used only in the RSNE in the (Re)Association Request frame to an AP and in FT authentication sequence frames. The PMKID Count field indicates the number of PMKIDs that are contained in the PMKID List field. The PMKID List field contains a series (possibly empty) of PMKIDs that the STA believes to be valid for the destination AP. The PMKID can refer to a) A cached PMKSA that has been obtained through preauthentication with the target AP b) A cached PMKSA from an EAP or SAE authentication c) A PMKSA derived from a PSK for the target AP d) A PMK-R0 security association derived as part of an FT initial mobility domain association e) A PMK-R1 security association derived as part of an FT initial mobility domain association or as part of a fast BSS transition. See 12.7.1.3 for the construction of the PMKID, 13.8 for the population of PMKID for fast BSS transitions, and 12.7.1.7 for the construction of PMKR0Name and PMKR1Name. NOTEâ€”A STA need not insert a PMKID in the PMKID List field if the STA will not be using that PMKSA. 9.4.2.26 Vendor Specific element The Vendor Specific element is used to carry information not defined in this standard within a single defined format, so that reserved element IDs are not usurped for nonstandard purposes and so that interoperability is more easily achieved in the presence of nonstandard information. The element is in the format shown in Figure 9-258. Element ID Length Organization Vendor-specific content Identifier Octets: 1 1 j variable Figure 9-258â€”Vendor Specific element format The Element ID and Length fields are defined in 9.4.2.1. The Organization Identifier field identifies (see 9.4.1.32) the entity that has defined the content of the particular Vendor Specific element. See 9.4.1.32 for the definition of j. 9.4.2.27 Extended Capabilities element The Extended Capabilities element carries information about the capabilities of a STA that augment the capabilities specified in the Capability Information field. The format of this element is shown in Figure 9-259. 890 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Element ID Length Extended Capabilities Octets: 1 1 n Figure 9-259â€”Extended Capabilities element format The Element ID and Length fields are defined in 9.4.2.1. The Extended Capabilities field is a bit field indicating the extended capabilities being advertised by the STA transmitting the element. The length of the Extended Capabilities field is a variable n. The Extended Capabilities field is shown in Table 9-135. Table 9-135â€”Extended Capabilities field Bit Information Notes 0 20/40 BSS The 20/40 BSS Coexistence Management Support field indicates support for the Coexistence 20/40 BSS Coexistence Management frame and its use. The 20/40 BSS Management Coexistence Management Support field is set to 1 to indicate support for the Support communication of STA information through the transmission and reception of the 20/40 BSS Coexistence Management frame. The 20/40 BSS Coexistence Management Support field is set to 0 to indicate a lack of support for the communication of STA information through the transmission and reception of the 20/40 BSS Coexistence Management frame. 1 Reserved 2 Extended Channel The Extended Channel Switching field is 1 to indicate support for the Switching communication of channel switching information through the transmission and reception of the Extended Channel Switch Announcement element and Management frame, as described in 9.6.8.7. The Extended Channel Switching field is 0 to indicate a lack of support for extended channel switching. 3 Reserved 4 PSMP Capability This field indicates support for PSMP operation. See 10.29. Set to 0 if the STA does not support PSMP operation Set to 1 if the STA supports PSMP operation. 5 Reserved 6 S-PSMP Support Indicates support for scheduled PSMP. When the PSMP Capability field is equal to 0, the S-PSMP Support field is set to 0. When the PSMP Capability field is equal to 1, the S-PSMP Support field is defined as follows: Set to 0 if STA does not support S-PSMP Set to 1 if STA supports S-PSMP 7 Event The STA sets the Event field to 1 when dot11EventsActivated is true, and sets it to 0 otherwise. See 11.24.2. 8 Diagnostics The STA sets the Diagnostics field to 1 when dot11DiagnosticsActivated is true, and sets it to 0 otherwise. See 11.24.3. 9 Multicast The STA sets the Multicast Diagnostics field to 1 when dot11MulticastDiagnos- Diagnostics ticsActivated is true, and sets it to 0 otherwise. See 11.24.3. 891 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-135â€”Extended Capabilities field (continued) Bit Information Notes 10 Location Tracking The STA sets the Location Tracking field to 1 when dot11LocationTrackingActivated is true, and sets it to 0 otherwise. See 11.24.4. 11 FMS The STA sets the FMS field to 1 when dot11FMSActivated is true, and sets it to 0 otherwise. See 11.2.3.16 and 11.24.8. 12 Proxy ARP The AP sets the Proxy ARP Service field to 1 when dot11ProxyARPActivated is Service true, and sets it to 0 otherwise. See 11.24.14. A non-AP STA sets the Proxy ARP Service field to 0. 13 Collocated The STA sets the Collocated Interference Reporting field to 1 when Interference dot11CoLocIntfReportingActivated is true, and sets it to 0 otherwise. See 11.24.9. Reporting 14 Civic Location The STA sets the Civic Location field to 1 when dot11RMCivicConfigured is true, and sets it to 0 otherwise. See 11.11.9.9. 15 Geospatial The STA sets the Geospatial Location field to 1 when dot11RMLCIConfigured is Location true, and sets it to 0 otherwise. See 11.11.9.6. 16 TFS The STA sets the TFS field to 1 when dot11TFSActivated is true, and sets it to 0 otherwise. See 11.24.12. 17 WNM Sleep The STA sets the WNM Sleep Mode field to 1 when Mode dot11WNMSleepModeActivated is true, and sets it to 0 otherwise. See 11.2.3.18. 18 TIM Broadcast The STA sets the TIM Broadcast field to 1 when dot11TIMBroadcastActivated is true, and sets it to 0 otherwise. See 11.2.3.17. 19 BSS Transition The STA sets the BSS Transition field to 1 when dot11BSSTransitionActivated is true, and sets it to 0 otherwise. See 11.24.7. 20 QoS Traffic The STA sets the QoS Traffic Capability field to 1 when Capability dot11QoSTrafficCapabilityActivated is true, and sets it to 0 otherwise. See 11.24.10. 21 AC Station Count The STA sets the AC Station Count field to 1 when dot11ACStationCountActivated is true, and sets it to 0 otherwise. See 11.24.11. 22 Multiple BSSID The STA sets the Multiple BSSID field to 1 when dot11MultiBSSIDActivated is true, and sets it to 0 otherwise. See 11.11.14 and 11.1.3.8. 23 Timing The STA sets the Timing Measurement field to 1 when Measurement dot11TimingMsmtActivated is true, and sets it to 0 otherwise. See 11.24.5. 24 Channel Usage The STA sets the Channel Usage field to 1 when dot11ChannelUsageActivated is true and sets it to 0 otherwise. See 11.24.15. 25 SSID List The STA sets the SSID List field to 1 when dot11SSIDListActivated is true, and sets it to 0 otherwise. See 11.1.4. 26 DMS The STA sets the DMS field to 1 when dot11DMSActivated is true and sets it to 0 otherwise. See 11.24.16. 27 UTC TSF Offset The STA sets the UTC TSF Offset field to 1 when dot11UTCTSFOffsetActivated is true and sets it to 0 otherwise. See 11.22.3. 892 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-135â€”Extended Capabilities field (continued) Bit Information Notes 28 TPU Buffer STA The TPU Buffer STA Support subfield indicates support for the TPU buffer STA Support function, as defined in 11.2.3.15. When dot11TDLSPeerUAPSDBufferSTAActivated is true, and to indicate support for TPU on this link, the TPU Buffer STA Support subfield is set to 1. Otherwise, the TPU Buffer STA Support subfield is set to 0 to indicate that this capability is not supported on this link. 29 TDLS Peer PSM The TDLS Peer PSM Support subfield indicates support for TDLS peer PSM, as Support defined in 11.2.3.14. When dot11TDLSPeerPSMActivated is true, and to indicate support for TDLS peer PSM on this link, the TDLS Peer PSM Support subfield is set to 1. Otherwise, the TDLS Peer PSM Support subfield is set to 0 to indicate that this capability is not supported on this link. 30 TDLS channel When dot11TDLSChannelSwitchingActivated is true, and to indicate that the switching STA supports TDLS with TDLS Channel Switching on this link as described in 11.23, the TDLS Channel Switching capability subfield is set to 1. Otherwise, the TDLS Channel Switching subfield is set to 0 to indicate that this capability is not supported on this link. 31 Interworking When dot11InterworkingServiceActivated is true, the Interworking field is set to 1 to indicate the STA supports interworking service as described in 11.25. When dot11InterworkingServiceActivated is false, the Interworking field is set to 0 to indicate the STA does not support this capability. 32 QoS Map When dot11QosMapActivated is true, the QoS Map field is set to 1 to indicate the STA supports QoS Map service as described in 11.25.9. When dot11QosMapActivated is false, the QoS Map field is set to 0 to indicate the STA does not support this capability. 33 EBR When dot11EBRActivated is true, the EBR field is set to 1 to indicate the STA supports EBR operation as described in 11.4. When dot11EBRActivated is false, the EBR field is set to 0 to indicate the STA does not support this capability. 34 SSPN Interface When dot11SSPNInterfaceActivated is true, the SSPN Interface field is set to 1 to indicate the AP supports SSPN Interface service as described in 11.25.5. When dot11SSPNInterfaceActivated is false, the SSPN Interface is set to 0 to indicate the AP does not support this capability. Non-AP STAs set this field to 0. 35 Reserved 36 MSGCF When dot11MSGCFActivated is true, the MSGCF Capability field is set to 1 to Capability indicate the non-AP STA supports the MSGCF in 6.4. When dot11MSGCFActivated is false, the MSGCF Capability is set to 0 to indicate the non-AP STA does not support this capability. APs set this field to 0. 37 TDLS Support The TDLS Support subfield indicates support for TDLS, as defined in 11.23. When dot11TunneledDirectLinkSetupImplemented is true, this field is set to 1 to indicate support for TDLS. The field is set to 0 otherwise, to indicate that TDLS is not supported. 38 TDLS Prohibited The TDLS Prohibited subfield indicates whether the use of TDLS is prohibited. The field is set to 1 to indicate that TDLS is prohibited and to 0 to indicate that TDLS is allowed. 39 TDLS Channel The TDLS Channel Switching Prohibited subfield indicates whether the use of Switching TDLS Channel Switching is prohibited. The field is set to 1 to indicate that TDLS Prohibited Channel Switching is prohibited and to 0 to indicate that TDLS Channel Switching is allowed. 893 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-135â€”Extended Capabilities field (continued) Bit Information Notes 40 Reject Unadmitted When dot11RejectUnadmittedTraffic is true, the Reject Unadmitted Frame bit is Frame set to 1 to indicate that the STA rejects MA-UNITDATA.request primitives for frames belonging to an unadmitted TS. When dot11RejectUnadmittedTraffic is false, the Reject Unadmitted Frame bit is set to 0 to indicate that the STA is not required to reject MA-UNITDATA.request primitives for frames belonging to an unadmitted TS. When dot11RejectUnadmittedTraffic is not present, the Reject Unadmitted frame bit is set to 0. 41-43 Service Interval Duration of the shortest service interval (SI). Granularity Used for scheduled PSMP only. This field is defined when the S-PSMP Support field is set to 1; otherwise, it is reserved. See 11.4.6. Set to 0 for 5 ms Set to 1 for 10 ms Set to 2 for 15 ms Set to 3 for 20 ms Set to 4 for 25 ms Set to 5 for 30 ms Set to 6 for 35 ms Set to 7 for 40 ms 44 Identifier Location The STA sets the Identifier Location field to 1 when dot11RMIdentifierMeasurementActivated is true, and sets it to 0 otherwise. See 11.11.9.10. 45 U-APSD The STA sets the U-APSD Coexistence field to 1 when Coexistence dot11UAPSDCoexistenceActivated is true and sets it to 0 otherwise. See 11.2.3.5.2. 46 WNM The STA sets the WNM Notification field to 1 when Notification dot11WNMNotificationActivated is true and sets it to 0 otherwise. See 11.24.17. 47 QAB Capability Set to 1 if AP supports QAB Set to 0 otherwise 48 UTF-8 SSID The SSID in this BSS is interpreted using UTF-8 encoding 49 QMFActivated The STA sets the QMFActivated field to 1 when dot11QMFActivated is true and sets it to 0 otherwise. See 11.26. 50 QMFReconfigurat The STA sets the QMFReconfigurationActivated field to 1 when ionActivated dot11QMFActivated is true and sets it to 0 otherwise. See 11.26. 51 Robust AV The STA sets the Robust AV Streaming field to 1 when Streaming dot11RobustAVStreamingImplemented is true and sets it to 0 otherwise. See 11.27. 52 Advanced GCR The STA sets the Advanced GCR field to 1 when dot11AdvancedGCRActivated is true and sets it to 0 otherwise. See 11.24.16.3. 53 Mesh GCR The STA sets the mesh GCR field to 1 when dot11MeshGCRActivated is true and sets it to 0 otherwise. See 11.24.16.3. 54 SCS The STA sets the SCS field to 1 when dot11SCSActivated is true and sets it to 0 otherwise. See 11.27.2. 894 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-135â€”Extended Capabilities field (continued) Bit Information Notes 55 QLoad Report The STA sets the QLoad Report field to 1 when dot11QLoadReportActivated is true and sets it to 0 otherwise. See 11.28.2. 56 Alternate EDCA The STA sets the Alternate EDCA field to 1 when dot11AlternateEDCAActivated is true and sets it to 0 otherwise. See 10.2.4.2. 57 Unprotected The STA sets the Unprotected TXOP Negotiation field to 1 when TXOP dot11PublicTXOPNegotiationActivated is true and sets it to 0 otherwise. See Negotiation 11.28.3. 58 Protected TXOP The STA sets the Protected TXOP Negotiation field to 1 when Negotiation dot11ProtectedTXOPNegotiationActivated is true and sets it to 0 otherwise. See 11.28.3. 59 Reserved 60 Protected QLoad The STA sets the Protected QLoad Report field to 1 when Report dot11ProtectedQLoadReportActivated is true and sets it to 0 otherwise. See 11.28.2. 61 TDLS Wider The TDLS Wider Bandwidth subfield indicates whether the STA supports a wider Bandwidth bandwidth than the BSS bandwidth for a TDLS direct link with a primary channel equal to the primary or only channel of the base channel. The field is set to 1 to indicate that the STA supports a wider bandwidth and to 0 to indicate that the STA does not support a wider bandwidth. A 160 MHz bandwidth is defined to be identical to an 80+80 MHz bandwidth (i.e., one is not wider than the other). 62 Operating Mode If dot11OperatingModeNotificationImplemented is true, the Operating Mode Notification Notification field is set to 1 to indicate support for reception of the Operating Mode Notification element and the Operating Mode Notification frame. If dot11OperatingModeNotificationImplemented is false or not present, the Operating Mode Notification field is set to 0 to indicate lack of support for reception of the Operating Mode Notification element and the Operating Mode Notification frame. 63â€“64 Max Number Of Indicates the maximum number of MSDUs in an A-MSDU that the STA is able to MSDUs In receive from a VHT STA: A-MSDU Set to 0 to indicate that no limit applies. Set to 1 for 32. Set to 2 for 16. Set to 3 for 8 Reserved if A-MSDU is not supported or if the STA is not an HT STA. 65 Channel Schedule The STA sets the Channel Schedule Management field to 1 when Management dot11ChannelScheduleManagementActivated is true and sets it to 0 otherwise. See 11.44.5. 66 Geodatabase The STA sets the Geodatabase Inband Enabling Signal field to 1 when Inband Enabling dot11GDDActivated is true and the STA permits GDD dependent STAs to Signal operate. See 11.44.2. 67 Network Channel The STA sets the Network Channel Control field to 1 when Control dot11NetworkChannelControlActivated is true and sets it to 0 otherwise. See 11.44.7. 68 White Space Map The STA sets the White Space Map field to 1 when dot11WhiteSpaceMapActivated is true and sets it to 0 otherwise. See 11.44.9. 69 Channel The STA sets the Channel Availability Query field to 1 when Availability Query dot11GDDActivated is true and sets it to 0 otherwise. See 11.44.4. 895 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-135â€”Extended Capabilities field (continued) Bit Information Notes 70 Fine Timing The STA sets the Fine Timing Measurement Responder field to 1 when Measurement dot11FineTimingMsmtRespActivated is true and sets it to 0 otherwise. See Responder 11.24.6. 71 Fine Timing The STA sets the Fine Timing Measurement Initiator field to 1 when Measurement dot11FineTimingMsmtInitActivated is true and sets it to 0 otherwise. See 11.24.6. Initiator 73 Extended The STA sets the Extended Spectrum Management Capable field to 1 when Spectrum dot11ExtendedSpectrumManagementImplemented is true and Management dot11VHTOptionImplemented is false, and sets it to 0 otherwise. Capable 74 Future Channel The STA sets the Future Channel Guidance field to 1 when Guidance dot11FutureChannelGuidanceActivated is true and sets it to 0 otherwise. See 11.9.10. 72, 75â€“n Reserved If a STA does not support any of capabilities defined in the Extended Capabilities element, then the STA is not required to transmit the Extended Capabilities element. NOTEâ€”The fields of the Extended Capabilities element are not dynamic. They are determined by the parameters of the MLME-START.request or MLME-JOIN.request primitive that caused the STA to start or join its current BSS, and they remain unchanged until the next MLME-START.request or MLME-JOIN.request primitive. 9.4.2.28 BSS Load element The BSS Load element contains information on the current STA population and traffic levels in the BSS. The element information format is defined in Figure 9-260. This element might be used by the STA for vendor-specific AP selection algorithm when roaming. Length Available Admission Element ID Station Count Channel Utilization (5) Capacity Octets: 1 1 2 1 2 Figure 9-260â€”BSS Load element format The Element ID and Length fields are defined in 9.4.2.1. The STA Count field is interpreted as an unsigned integer that indicates the total number of STAs currently associated with this BSS. The Channel Utilization field is defined as the percentage of time, linearly scaled with 255 representing 100%, that the AP sensed the medium was busy, as indicated by either the physical or virtual carrier sense (CS) mechanism. When more than one channel is in use for the BSS, the Channel Utilization field value is calculated only for the primary channel. This percentage is computed using the formula, channel busy time ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- - Channel Utilization = 255 dot11ChannelUtilizationBeaconIntervals dot11BeaconPeriod 1024 896 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications where channel busy time is defined to be the number of microseconds during which the CS mechanism, as defined in 10.3.2.1, has indicated a channel busy indication, dot11ChannelUtilizationBeaconIntervals represents the number of consecutive beacon intervals during which the channel busy time is measured. The default value of dot11ChannelUtilizationBea- conIntervals is defined in Annex C. The Available Admission Capacity field is 2 octets long and contains an unsigned integer that specifies the remaining amount of medium time available via explicit admission control, in units of 32 s/s. The field is helpful for roaming STAs to select an AP that is likely to accept future admission control requests, but it does not represent an assurance that the HC admits these requests. 9.4.2.29 EDCA Parameter Set element The EDCA Parameter Set element provides information needed by STAs for proper operation of the QoS facility during the CP. The format of the EDCA Parameter Set element is defined in Figure 9-261. Length QoS Reserve AC_BE AC_BK AC_VI AC_VO Element ID Parameter Parameter Parameter Parameter (18) Info d Record Record Record Record Octets: 1 1 1 1 4 4 4 4 Figure 9-261â€”EDCA Parameter Set element The Element ID and Length fields are defined in 9.4.2.1. For an infrastructure BSS, the EDCA Parameter Set element is used by the AP to establish policy (by changing default MIB attribute values), to change policies when accepting new STAs or new traffic, or to adapt to changes in offered load. The most recent EDCA parameter set element received by a STA is used to update the appropriate MIB values. The format of the QoS Info field is defined in 9.4.1.17. The QoS Info field contains the EDCA Parameter Set Update Count subfield, which is initially set to 0 and is incremented each time any of the AC parameters changes. This subfield is used by non-AP STAs to determine whether the EDCA parameter set has changed and requires updating the appropriate MIB attributes. The formats of AC_BE, AC_BK, AC_VI, and AC_VO Parameter Record fields are identical and are illustrated in Figure 9-262. ACI / AIFSN ECWmin / TXOP Limit ECWmax Octets: 1 1 2 Figure 9-262â€”AC_BE, AC_BK, AC_VI, and AC_VO Parameter Record field format The format of the ACI/AIFSN field is illustrated in Figure 9-263. B0 B3 B4 B5 B6 B7 AIFSN ACM ACI Reserved Bits: 4 1 2 1 Figure 9-263â€”ACI/AIFSN field 897 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The value of the AC index (ACI) references the AC to which all parameters in this record correspond. The mapping between ACI and AC is defined in Table 9-136. The ACM (admission control mandatory) subfield indicates that admission control is required for the AC. If the ACM subfield is equal to 0, then there is no admission control for the corresponding AC. If the ACM subfield is set to 1, admission control has to be used prior to transmission using the access parameters specified for this AC. The AIFSN subfield indicates the number of slots after a SIFS a STA defers before either invoking a backoff or starting a transmission. The minimum value of the AIFSN subfield is 2. Table 9-136â€”ACI-to-AC coding ACI AC Description 0 AC_BE Best effort 1 AC_BK Background 2 AC_VI Video 3 AC_VO Voice The ECWmin and ECWmax fields are illustrated in Figure 9-264. B0 B3 B4 B7 ECWmin ECWmax Bits: 4 4 Figure 9-264â€”ECWmin and ECWmax fields The ECWmin and ECWmax fields encode the values of CWmin and CWmax, respectively, in an exponent form. The ECWmin and ECWmax values are defined so that CWmin = 2ECWmin â€“ 1 CWmax = 2ECWmax â€“ 1 Hence the minimum encoded value of CWmin and CWmax is 0, and the maximum value is 32 767. The value of the TXOP Limit field is specified as an unsigned integer, in units of 32 s. A TXOP Limit field value of 0 has a special meaning (see 10.22.2.8). Table 9-137 defines the default EDCA parameter values used by a non-AP STA if dot11OCBActivated is false.24 24 The default values for TXOP limit are expressed in milliseconds and are multiples of 32 s. 898 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-137â€”Default EDCA Parameter Set element parameter values if dot11OCBActivated is false TXOP limit For PHYs defined AC CWmin CWmax AIFSN For PHYs defined in Clause 17, For PHY defined Other in Clause 15 and Clause 18, Clause 16 Clause 19, and in Clause 22 PHYs Clause 21 AC_BK aCWmin aCWmax 7 3.264 ms 2.528 ms 0 0 AC_BE aCWmin aCWmax 3 3.264 ms 2.528 ms 0 0 AC_VI (aCWmin+1)/2 aCWmin 2 6.016 ms 4.096 ms 22.56 ms 0 â€“1 (BCU: 6 or 7 MHz), 16.92 ms (BCU: 8 MHz) AC_VO (aCWmin+1)/4 (aCWmin+1)/ 2 3.264 ms 2.080 ms 11.28 ms 0 â€“1 2â€“1 (BCU: 6 or 7 MHz), 8.46 ms (BCU: 8 MHz) If dot11OCBActivated is true, the default EDCA parameter set for STAs transmitting QoS frames is given in Table 9-138. Table 9-138â€”Default EDCA parameter set for STA operation if dot11OCBActivated is true AC CWmin CWmax AIFSN TXOP limit AC_BK aCWmin aCWmax 9 0 AC_BE aCWmin aCWmax 6 0 AC_VI (aCWmin+1)/2â€“1 aCWmin 3 0 AC_VO (aCWmin+1)/4â€“1 (aCWmin+1)/2â€“1 2 0 9.4.2.30 TSPEC element The TSPEC element contains the set of parameters that define the characteristics and QoS expectations of a traffic flow, in the context of a particular STA, for use by the HC or PCP and STA(s) or a mesh STA and its peer mesh STAs in support of QoS traffic transfer using the procedures defined in 11.4 and 11.24.16.3. The element information format comprises the items as defined in this subclause, and the structure is defined in Figure 9-265. The TSPEC allows a set of parameters more extensive than might be needed, or might be available, for any particular instance of parameterized QoS traffic. Unless indicated otherwise, fields that follow the TS Info field are set to 0 for any unspecified parameter values. STAs set the value of any parameters to unspecified if they have no information for setting that parameter. 899 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Element Length Nominal Maximum Minimum Maximum Inactivity Suspension TS Info MSDU MSDU Service Service ID (55) Size Size Interval Interval Interval Interval Octets: 1 1 3 2 2 4 4 4 4 Surplus Service Minimum Mean Peak Data Delay Minimum Medium DMG Start Time Data Rate Data Rate Rate Burst Size Bound PHY Rate Bandwidth Time Attributes Allowance Octets: 4 4 4 4 4 4 4 2 2 0 or 2 Figure 9-265â€”TSPEC element format The structure of the TS Info field is defined in Figure 9-266. B0 B1 B4 B5 B6 B7 B8 B9 B10 B11 B13 B14 B15 B16 B17 B23 TSInfo Traffic Access User Type TSID Direction Policy Aggregation APSD Priority Ack Schedule Reserved Policy Bits: 1 4 2 2 1 1 3 2 1 7 Figure 9-266â€”TS Info field The subfields of the TS Info field are defined as follows: â€” The Traffic Type subfield is a single bit and is set to 1 for a periodic traffic pattern (e.g., isochronous TS of MSDUs or A-MSDUs, with constant or variable sizes, that are originated at fixed rate) or set to 0 for an aperiodic, or unspecified, traffic pattern (e.g., asynchronous TS of low-duty cycles). â€” The TSID subfield is 4 bits in length and contains a value that is a TSID. Note that the MSB (bit 4 in TS Info field) of the TSID subfield is always set to 1 when the TSPEC element is included within an ADDTS Response frame. â€” The Direction subfield specifies the direction of data carried by the TS as defined in Table 9-139. Table 9-139â€”Direction subfield encoding Bit 5 Bit 6 Usage Uplink, defined as follows: â€” Non-DMG BSS: MSDUs or A-MSDUs are sent from the non-AP STA to HC 0 0 â€” DMG BSS: MSDUs or A-MSDUs are sent by the non-AP originator of the ADDTS Request frame Downlink, defined as follows: â€” Non-DMG BSS: MSDUs or A-MSDUs are sent from the HC to the non-AP 1 0 STA â€” DMG BSS: MSDUs or A-MSDUs are sent by the non-AP recipient of the ADDTS Request frame Direct link (MSDUs or A-MSDUs are sent from the non-AP STA to another non-AP 0 1 STA) 1 1 Bidirectional link (equivalent to a downlink request plus an uplink request, each direction having the same parameters). The fields in the TSPEC element specify resources for a single direction. Double the specified resources are required to support both streams. 900 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” The Access Policy subfield is 2 bits in length, specifies the access method to be used for the TS, and is defined in Table 9-140. Table 9-140â€”Access Policy subfield Bit 7 Bit 8 Usage 0 0 Reserved 1 0 Contention based channel access (EDCA) 0 1 Controlled channel access (HCCA for non-DMG STAs and SPCA for DMG STAs) 1 1 Controlled and contention based channel access (HCCA, EDCA mixed mode (HEMM) for non-DMG STAs; SPCA, EDCA mixed mode (SEMM) for DMG STAs) â€” The Aggregation subfield is 1 bit in length. The Aggregation subfield is valid only when the access method is HCCA or SPCA or when the access method is EDCA and the Schedule subfield is equal to 1. It is set to 1 by a non-AP STA to indicate that an aggregate schedule is required. It is set to 1 by the AP if an aggregate schedule is being provided to the STA. It is set to 0 otherwise. In all other cases, the Aggregation subfield is reserved. â€” The APSD subfield is a single bit and is set to 1 to indicate that automatic PS delivery is to be used for the traffic associated with the TSPEC and set to 0 otherwise. â€” The UP subfield is 3 bits and indicates the actual value of the UP to be used for the transport of MSDUs or A-MSDUs belonging to this TS when relative prioritization is required. When the TCLAS element is present in the request, the UP subfield in TS Info field of the TSPEC element is reserved. â€” The TS Info Ack Policy subfield is 2 bits in length and indicates whether MAC acknowledgments are required for MPDUs or A-MSDUs belonging to this TSID and the form of those acknowledgments. The encoding of the TS Info Ack Policy subfield is shown in Table 9-141. Table 9-141â€”TS Info Ack Policy subfield encoding Bit 14 Bit 15 Usage 0 0 Normal Acknowledgment The addressed recipient returns an Ack or QoS +CF-Ack frame after a SIFS, according to the procedures defined in 10.3.2.9, 10.4.4, and 10.22.3.5. 1 0 No Ack: The recipient(s) do not acknowledge the transmission. 0 1 Reserved 1 1 Block Ack: A separate block ack mechanism described in 10.24 is used. â€” The Schedule subfield is 1 bit in length and specifies the requested type of schedule. The setting of the subfield when the access policy is EDCA is shown in Table 9-142. When the Access Policy subfield is equal to any value other than EDCA, the Schedule subfield is reserved. When the Schedule and APSD subfields are equal to 1, the AP sets the aggregation bit to 1, indicating that an aggregate schedule is being provided to the STA. 901 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-142â€”Setting of Schedule subfield APSD Schedule Usage 0 0 No Schedule 1 0 Unscheduled APSD 0 1 Scheduled PSMP or GCR-SP 1 1 Scheduled APSD The Nominal MSDU Size field is 2 octets long and contains an unsigned integer that specifies the nominal size, in octets, of MSDUs or (where A-MSDU aggregation is employed) A-MSDUs belonging to the TS under this TSPEC and is defined in Figure 9-267. If the Fixed subfield is equal to 1, then the size of the MSDU or A-MSDU is fixed and is indicated by the Size subfield. If the Fixed subfield is equal to 0, then the size of the MSDU or A-MSDU might not be fixed and the Size subfield indicates the nominal MSDU size. If both the Fixed and Size subfields are equal to 0, then the nominal MSDU or A-MSDU size is unspecified. B0 B14 B15 Size Fixed Bits: 15 1 Figure 9-267â€”Nominal MSDU Size field The Maximum MSDU Size field is 2 octets long and contains an unsigned integer that specifies the maximum size, in octets, of MSDUs or A-MSDUs belonging to the TS under this TSPEC. The Minimum Service Interval field is 4 octets long and contains an unsigned integer that specifies the minimum interval, in microseconds, between the start of two successive SPs. If the TSPEC element is included within a GCR Request subelement that has the GCR delivery method equal to GCR-SP, a Minimum Service Interval field value of 0 indicates that SPs up to the maximum service interval are requested, including the continuous SP used by the GCR-A delivery method. The Maximum Service Interval field is 4 octets long and contains an unsigned integer that, when the TSPEC is for the admitting of HCCA streams, specifies the maximum interval, in microseconds, between the start of two successive SPs. If the TSPEC element is intended for EDCA Admission Control, the Maximum Service Interval field is used to indicate a latency limit, which limits the amount of aggregation (A-MSDU or A- MPDU) used, so that excessive latency does not occur (see K.4.2.1). The Maximum Service Interval field is greater than or equal to the Minimum Service Interval field. If the TSPEC element is included within a GCR Request subelement that has the GCR delivery method equal to GCR-SP, a Maximum Service Interval field value of 0 indicates that the continuous SP used by the GCR-A delivery method is requested. K.4.2.2 provides guidance on the use of the Maximum Service Interval to determine the limit of aggregation of nominal MSDUs. The Inactivity Interval field is 4 octets long and contains an unsigned integer that specifies the minimum amount of time, in microseconds, that can elapse without arrival or transfer of an MPDU belonging to the TS before this TS is deleted by the MAC entity at the HC. The Suspension Interval field is 4 octets long and contains an unsigned integer that specifies the minimum amount of time, in microseconds, that can elapse without arrival or transfer of an MSDU belonging to the TS before the generation of successive QoS(+)CF-Poll is stopped for this TS. A value of 4 294 967 295 (= 232 â€“ 1) disables the suspension interval, indicating that polling for the TS is not to be interrupted based on inactivity. The value of the suspension interval is always less than or equal to the inactivity interval. 902 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Service Start Time field is 4 octets and contains an unsigned integer that specifies the time, expressed in microseconds, when the first scheduled SP starts. The service start time indicates to the AP the time when a STA first expects to be ready to send frames and a power-saving STA needs to be awake to receive frames. This might help the AP to schedule service so that the MSDUs encounter small delays in the MAC and help the power-saving STAs to reduce power consumption. The field represents the four lower order octets of the TSF timer at the start of the SP. If APSD and Schedule subfields are 0, this field is also set to 0 (unspecified). The Minimum Data Rate field is 4 octets long and indicates the lowest data rate specified at the MAC SAP, for transport of MSDUs or A-MSDUs belonging to this TS within the bounds of this TSPEC. The field is encoded as a piecewise linear function described as follows: 31 F min F min 2 R min = 31 31 31 1024 F min â€“ 2 +2 F min 2 where Rmin is the minimum data rate (in units of bits per second) Fmin is the value of the Minimum Data Rate field The Mean Data Rate25 field is 4 octets long and indicates the average data rate specified at the MAC SAP, for transport of MSDUs or A-MSDUs belonging to this TS within the bounds of this TSPEC. The field is encoded as a piecewise linear function described as follows: 31 Fmean F mean 2 R mean = 31 31 31 1024 F mean â€“ 2 +2 F mean 2 where Rmean is the mean data rate (in units of bits per second) Fmean is the value of the Mean Data Rate field The Peak Data Rate field is 4 octets long and indicates the maximum allowable data rate specified at the MAC SAP for transport of MSDUs or A-MSDUs belonging to this TS within the bounds of this TSPEC. The field is encoded as a piecewise linear function described as follows: 31 Fpeak F peak 2 R peak = 31 31 31 1024 F peak â€“ 2 +2 F peak 2 where Rpeak is the peak data rate (in units of bits per second) Fpeak is the value of the Peak Data Rate field If p is the peak rate in bits per second, then the maximum amount of data, belonging to this TS, arriving in any time interval [t1,t2], where t1 < t2 and t2 â€“ t1 > 1 TU, does not exceed p Ã— (t2 â€“ t1) bits. 25 The mean data rate, the peak data rate, and the burst size are the parameters of the token bucket model, which provides standard terminology for describing the behavior of a traffic source. The token bucket model is described in IETF RFC 2212 [B29], IETF RFC 2215 [B30], and IETF RFC 3290 [B37]. 903 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Minimum, Mean and Peak Data Rates do not include the MAC and PHY overheads incurred in transporting the MSDUs or A-MSDUs, with the exception of the MAC overheads specific to A-MSDUs (A-MSDU subframe header and padding). K.4.3 provides guidance on how to determine the standard deviation of the TS and how to calculate the total traffic when there are multiple TSs. The Burst Size field is 4 octets long and contains an unsigned integer that specifies the maximum burst, in octets, of the MSDUs or A-MSDUs belonging to this TS that arrive at the MAC SAP at the peak data rate. A value of 0 indicates that there are no bursts. The Delay Bound field is 4 octets long and contains an unsigned integer that specifies the maximum amount of time, in microseconds, allowed to transport an MSDU or A-MSDU belonging to the TS in this TSPEC, measured between the time marking the arrival of the MSDU, or the first MSDU of the MSDUs constituting an A-MSDU, at the local MAC sublayer from the local MAC SAP and the time of completion of the successful transmission or retransmission of the MSDU or A-MSDU to the destination. The completion of the MSDU or A-MSDU transmission includes the relevant acknowledgment frame transmission time, if present. The Minimum PHY Rate field is 4 octets long and indicates the minimum PHY rate for transport of MSDUs or A-MSDUs belonging to this TS within the bounds of this TSPEC.26 See 11.4.2 for constraints on the selection of this field. The field is encoded as a piecewise linear function described as follows: 31 F minphy F minphy 2 R minphy = 31 31 31 1024 F minphy â€“ 2 +2 F minphy 2 where Rminphy is the minimum PHY rate (in units of bits per second) Fminphy is the value of the Minimum PHY Rate field The Surplus Bandwidth Allowance field is 2 octets long and specifies the excess allocation of time (and bandwidth) over and above the stated application rates required to transport an MSDU or A-MSDU belonging to the TS in this TSPEC. This field is represented as an unsigned binary number and, when specified, is greater than 0. The 13 least significant bits (LSBs) indicate the decimal part while the three MSBs indicate the integer part of the number. This field takes into account the retransmissions, as the rate information does not include retransmissions. It represents the ratio of over-the-air bandwidth (i.e., time that the scheduler allocates for the transmission of MSDUs or A-MSDUs at the required rates) to bandwidth of the transported MSDUs or A-MSDUs required for successful transmission (i.e., time that would be necessary at the minimum PHY rate if there were no errors on the channel) to meet throughput and delay bounds under this TSPEC, when specified. As such, it should be greater than unity. A value of 1 indicates that no additional allocation of time is requested. K.4.1 provides guidance on how to calculate the value for Surplus Bandwidth Allowance. The Medium Time field is a 16-bit unsigned integer and contains the amount of time admitted to access the medium, in units of 32 s/s. This field is reserved in the ADDTS Request frame and is set by the HC in the ADDTS Response frame. The derivation of this field is described in K.2.2. This field is not used for controlled channel access. 26 This rate information is intended to confirm that the TSPEC parameter values resulting from an admission control negotiation are sufficient to provide the required throughput for the TS. In a typical implementation, a TS is admitted only if the defined traffic volume can be accommodated at the specified rate within an amount of WM occupancy time that the admissions control entity is willing to allocate to this TS. 904 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The UP, Minimum Data Rate, Mean Data Rate, Peak Data Rate, Burst Size, Minimum PHY Rate, and Delay Bound fields in a TSPEC element express the QoS expectations requested by a STA, if this TSPEC was issued by that STA, or provided by the HC, if this TSPEC was issued by the HC, when these fields are specified with nonzero values. Unspecified parameters in these fields as indicated by a value of 0 indicate that the STA does not have specific requirements for these parameters if the TSPEC was issued by that STA or that the HC does not provide any specific values for these parameters if the TSPEC was issued by the HC. Annex K provides guidance on the use of the TSPEC and the settings of values of the various fields. The DMG Attributes field is defined in Figure 9-268. The DMG Attributes field is present in a TSPEC when the BSS to which the TSPEC applies is a DMG BSS; otherwise absent. B0 B3 B4 B5 B6 B7 B8 B9 B10 B15 Allocation ID Reserved Allocation A-MSDU Reliability Reserved Direction Subframe Bits: 4 2 1 1 2 6 Figure 9-268â€”DMG Attributes field format â€” The Allocation ID subfield is 4 bits in length. Traffic streams can share an allocation through TSPEC aggregation (see Annex V). The Allocation ID subfield is used as follows: â€” When setting up a TS, the DMG STA that transmits an ADDTS Request frame containing a TSPEC or PTP TSPEC element sets the Allocation ID subfield to a nonzero value to identify the allocation it requires to carry the TS. Alternatively, the same DMG STA sets the Allocation ID subfield to 0 to indicate any CBAP allocation with the broadcast AID as Source AID. â€” When setting up a TS, the DMG STA that transmits the ADDTS Response frame containing the TSPEC or PTP TSPEC element sets the Allocation ID subfield to a nonzero value that identifies the allocation carrying the TS. Alternatively, the same DMG STA sets the Allocation ID subfield to 0 to indicate any CBAP allocation with the broadcast AID as Source AID and Destination AID. â€” When deleting a TS, the DMG STA that transmits the DELTS frame containing a TSPEC or PTP TSPEC element sets the Allocation ID subfield to a nonzero value to identify the allocation that is carrying the TS to be deleted. Alternatively, the same DMG STA sets the Allocation ID subfield to 0 to indicate no allocation exists to carry the TS to be deleted. â€” The Allocation Direction subfield is 1 bit in length. It is equal to 1 when the originator of the ADDTS request is also the source of the allocation identified by the Allocation ID subfield and is equal to 0 otherwise. The Allocation Direction subfield is equal to 0 when the Allocation ID subfield is equal to 0. â€” The A-MSDU Subframe subfield is 1 bit in length and contains a value that indicates the A-MSDU subframe structure to be used for this TS. The A-MSDU Subframe subfield is set to 0 to indicate the Basic A-MSDU subframe structure and set to 1 to indicate the Short A-MSDU subframe structure. â€” The Reliability subfield is 2 bits in length and contains an expected reliability index. The reliability index refers to the PHY PER (PSDU error rate as in 20.3.3.8). The relation between the reliability index and the PER is shown in Table 9-143. The Reliability subfield in an ADDTS Request frame that has the Direction subfield set to downlink or in an ADDTS Response frame that has the Direction field set to uplink indicates the expectation of the PER of the destination DMG STA for this TS. The Reliability subfield in an ADDTS Request frame that has the Direction subfield set to uplink or in an ADDTS Response frame that has the Direction field set to downlink is reserved. The reliability information is provided by the SME using the MLME-ADDTS.request primitive and MLME-ADDTS.response primitives. Together with the link margin (10.39) and other implementation-specific information, this value can be used by the source DMG STA of this TS to estimate the MCS to be used for this particular TS. 905 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-143â€”Reliability subfield values Reliability index PER 0 Not specified 1 10-2 2 10-3 3 10-4 9.4.2.31 TCLAS element The TCLAS element contains a set of parameters necessary to identify various kinds of PDU or incoming MSDU (from a higher layer in all STAs or from the DS in an AP) that belong to a particular TS. The TCLAS element is also used when the traffic does not belong to a TS, for example, by the FMS, DMS, and TFS services. If required, the TCLAS element is provided in ADDTS Request and ADDTS Response frames only for the downlink or bidirectional links. The TCLAS element is always included when a PTP TSPEC is transmitted to a peer STA via an AP or PCP. The structure of this element is shown in Figure 9-269. Element ID Length User Priority Frame Classifier Octets: 1 1 1 variable Figure 9-269â€”TCLAS element format The Element ID and Length fields are defined in 9.4.2.1. When the UP field contains a value that is less than or equal to 7, the value specifies the UP of the associated MSDUs. When the UP field contains a value that is greater than or equal to 8 and less than or equal to 11, the value specifies the access category of the associated MPDUs. The UP field value 255 is reserved and indicates that the UP of the MSDU and the access category of the MPDU are not compared as part of the traffic filter. The encoding of the contents of the User Priority field of an TCLAS element is specified in Table 9-144. Table 9-144â€”User Priority field of TCLAS element User Priority Meaning 0â€“7 The User Priority value of an MSDU 8 The AC value of an MPDU is AC-VO 9 The AC value of an MPDU is AC-VI 10 The AC value of an MPDU is AC-BE 11 The AC value of an MPDU is AC-BK 12â€“254 Reserved 255 The User Priority field is not used for comparison. 906 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Frame Classifier field is 3â€“255 octets in length and is defined in Figure 9-270. Classifier Type Classifier Mask Classifier Parameters Octets: 1 1 or 3 variable Figure 9-270â€”Frame Classifier field The Frame Classifier field comprises the following subfields: Classifier Type, Classifier Mask, and Classifier Parameters. The Classifier Type subfield is 1 octet in length and specifies the type of classifier parameters in this TCLAS as defined in Table 9-145. Table 9-145â€”Frame classifier type Classifier type Classifier parameters 0 Ethernet parameters 1 TCP/UDP IP parameters 2 IEEE 802.1Q parameters 3 Filter Offset parameters 4 IP and higher layer parameters 5 IEEE 802.1D/Q parameters 6 IEEE 802.11 MAC header parameters 7â€“255 Reserved When the Classifier type is a value less than or equal to 5, the Classifier Mask subfield specifies a bitmap in which bits that have the value 1 identify a subset of the classifier parameters whose values need to match those of the corresponding parameters in a given MSDU for that MSDU to be classified to the TS of the affiliated TSPEC. The bitmap is ordered from the LSB to the MSB, with each bit pointing to one of the classifier parameters of the same relative position as shown in this subclause based on classifier type. When there are more bits in the bitmap than classifier parameters that follow, the MSBs that do not point to any classifier parameters are reserved. When the Classifier Type is equal to 6, the Classifier Mask subfield is three octets in length. It contains a sequence of nine two-bit Classifier Mask Control subfields. Each Classifier Mask Control subfield applies to a specific target field of the MAC header. It determines whether the target field is included in the comparison and whether an additional bitmask (the target field filter mask) is present. When the target field filter mask is present, it determines which bits of the target field are used in the comparison. Table 9-146 specifies the interpretation of the Classifier Mask Control subfield. 907 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-146â€”Interpretation of the Classifier Mask Control subfield values Size of Match Value of the Is the target Specification field Classifier Mask Description subfield filter (as a multiplier to Control subfield mask present? the size of the target subfield) 0 Target field is not included in classification No 0 1 Target field is included in classification. No 1 Match based on target field bitwise = target field filter specification 2 Reserved 3 Target subfield is included in classification. Yes 2 Match criteria: if the bit with the same bit position in target filter mask subfield is set to 1, the bit value in the target field = target field filter specification; if the bit with the same bit position in target filter mask subfield is set to 0, the bit in the target field match specification need not be compared. The map from the location of the Classifier Mask subfield to the target subfield is defined in Table 9-147. Table 9-147â€”Map from location of Classifier Mask subfield to target subfield Bit number Target field 0â€“1 Frame Control 2â€“3 Duration/ID 4â€“5 Address 1 6â€“7 Address 2 8â€“9 Address 3 10â€“11 Sequence Control 12â€“13 Address 4 14â€“15 QoS Control 16â€“17 HT Control 18â€“23 Reserved For Classifier Type 0, the classifier parameters are the following parameters contained in an Ethernet frame header: Source Address, Destination Address, and Type (â€œEthernetâ€ [B12]). The endianness of the Type field is as defined in Ethernet [B12]. The Frame Classifier field for Classifier Type 0 is defined in Figure 9-271. It has a length of 16 octets. 908 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Classifier Type (0) Classifier Mask Source Address Destination Address Type Octets: 1 1 6 6 2 Figure 9-271â€”Frame Classifier field of Classifier Type 0 For Classifier Type 1, frame classifier is defined for both IPv4 and IPv6, shown in Figure 9-272 and Figure 9-273, and distinguished by the Version field. Use of Classifier Type 1 for IPv6 is deprecated and replaced by Classifier Type 4. The subfields in the classifier parameters are represented and transmitted in the big-endian format. The classifier parameters are the following parameters: â€” In a TCP or UDP header: Source Address, Destination Address, Source Port, Destination Port, and Version, plus â€” One of the following: â€” In an IPv4 header: Differentiated Services Code Point (DSCP) (IETF RFC 2474 [B31]) and Protocol, or â€” In an IPv6 header: Flow Label. Classifier Type Classifier Version Source IP Destination Source Destination DSCP Protocol Reserved Mask Address IP Address Port Port (1) Octets: 1 1 1 4 4 2 2 1 1 1 Figure 9-272â€”Frame Classifier field of Classifier Type 1 for traffic over IPv4 Classifier Type Classifier Version Source IP Destination Source Destination Flow Mask Address IP Address Port Port Label (1) Octet 1 1 1 16 16 2 2 3 s: Figure 9-273â€”Frame Classifier field of Classifier Type 1 for traffic over IPv6 The DSCP field contains the value in the 6 LSBs, and the 2 MSBs are set to 0. The 2 MSBs of the DSCP field are ignored for frame classification. The value in the Version subfield is the value specified in IETF RFC 791 or IETF RFC 2460. For Classifier Type 2, the Classifier Parameter is the IEEE 802.1Q-2003 VLAN Tag TCI. The endianness of the IEEE 802.1Q VLAN TCI field is as defined in IEEE Std 802.1Q for the VLAN Tag TCI. The Frame Classifier field for Classifier Type 2 is defined in Figure 9-274. Classifier Type 802.1Q VLAN (2) Classifier Mask TCI Octets: 1 1 2 Figure 9-274â€”Frame Classifier field of Classifier Type 2 For Classifier Type 3, the classifier parameters are defined by a Filter Offset subfield, a Filter Value subfield and a Filter Mask subfield. The Frame Classifier subfield of Classifier Type 3 is defined in Figure 9-275. It has a variable length. 909 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Classifier Type (3) Classifier Mask Filter Offset Filter Value Filter Mask Octets: 1 1 2 variable variable Figure 9-275â€”Frame Classifier field of Classifier Type 3 The Classifier Mask subfield is reserved. The value of the Filter Offset subfield is the number of octets from the beginning of the MSDU or MMPDU at which the Filter Value is compared. The length of the Filter Value and Filter Mask subfields is (Length â€“ 5)/2, where Length is the value in the Length field of the TCLAS element. The Filter Value subfield is an octet string that is compared to the MSDU or MMPDU content, beginning at the octet indicated by the Filter Offset. The Filter Mask subfield is an octet string that is used to indicate which bits in the Filter Value subfield are compared. The length of the Filter Mask subfield is equal to the length of the Filter Value subfield. A bit in the Filter Value subfield is compared only if the matching bit in the Filter Mask subfield is 1. For Classifier Type 4, frame classifier is defined for both IPv4 and IPv6, shown in Figure 9-276 (with the Classifier Type subfield set to 4) and Figure 9-277, and distinguished by the Version subfield. The classifier parameters represent corresponding values in a received IPv4 or IPv6 frame and are defined in Table 9-148. The subfields in the classifier parameters are represented and transmitted in big-endian format. Table 9-148â€”Classifier parameters for Classifier Type 4 Included in IPv4 field length Included in IPv6 field length Subfield IPv4 (octets) IPv6 (octets) Version Yes 1 Yes 1 Source IP Address Yes 4 Yes 16 Destination IP Address Yes 4 Yes 16 Source Port Yes 2 Yes 2 Destination Port Yes 2 Yes 2 DSCP Yes 1 Yes 1 Protocol Yes 1 No n/a Next Header No n/a Yes 1 Flow Label No n/a Yes 3 910 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Frame Classifier subfield of Classifier Type 4 for traffic over IPv4 is shown in Figure 9-276. Classifier Type Classifier Mask Version(4) Source IP Destination IP (4) Address Address Octets: 1 1 1 4 4 Source Port Destination Port DSCP Protocol Reserved Octets: 2 2 1 1 1 Figure 9-276â€”Frame Classifier subfield of Classifier Type 4 for traffic over IPv4 The Frame Classifier subfield of Classifier Type 4 for traffic over IPv6 is shown in Figure 9-277. Classifier Type Classifier Mask Version(6) Source IP Destination IP (4) Address Address Octets: 1 1 1 16 16 Source Port Destination Port DSCP Next Header Flow Label Octets: 2 2 1 1 3 Figure 9-277â€”Frame Classifier subfield of Classifier Type 4 for traffic over IPv6 NOTEâ€”Frame classification when extension headers are used is supported only if the TCLAS does not classify on ports (Classifier Mask has the Source and Destination Port bits set to 0). The value in the Version subfield is the value specified in IETF RFC 791 or IETF RFC 2460. The DSCP subfield contains the value as described in IETF RFC 2474 in the 6 least significant bits. The 2 most significant bits are reserved. The Next Header subfield contains the next encapsulated protocol and is compatible with the values specified for the IPv4 Protocol subfield. In the presence of options in the IPv6 header, the Next Header subfield specifies the presence of one or more out of six extension headers as defined in IETF RFC 2460. The Flow Label subfield contains the value in the 20 least significant bits. The 4 most significant bits are reserved. NOTEâ€”For example, the flow label 0x12345 is represented as the octet sequence 0x01, 0x23, 0x45. A TCLAS element is valid when the Classifier Mask Version bit is 1. For Classifier Type 5 when used to match an IEEE 802.1D-2004 frame [B23], the classifier parameter is only the User Priority, and the DEI and VID parameters are ignored. For Classifier Type 5 when used to match an IEEE 802.1Q frame, the classifier parameters are: Priority Code Point, Drop Eligibility Indicator (DEI), and VLAN ID (VID). 911 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Frame Classifier field for Classifier Type 5 is defined in Figure 9-278. Classifier Type 802.1D UP/ Classifier Mask 802.1Q Priority 802.1Q DEI 802.1Q VID (5) Code Point Octets: 1 1 1 1 2 Figure 9-278â€”Frame Classifier field of Classifier Type 5 The subfields in the classifier parameters are represented and transmitted in big-endian format. The 802.1D UP/802.1Q Priority Code Point subfield contains the value to be matched to the appropriate type frame header in the 4 LSBs; the 4 MSBs are reserved. The 802.1Q DEI subfield contains the value to match against an IEEE 802.1Q frame header, in the LSB; the 7 MSBs are reserved. When matching an IEEE 802.1D-2004 frame header, this subfield is ignored. The 802.1Q VID subfield contains the value to match against an IEEE 802.1Q frame header, in the 12 LSBs; the 4 MSBs are reserved. When matching an IEEE 802.1D-2004 frame header, this subfield is ignored. For Classifier Type 6, the format of the Frame Classifier field of an TCLAS element is illustrated in Figure 9-279. Classifier Classifier Frame Control Duration Match Address 1 Match Address 2 Match Match Type (6) Mask Specification Specification Specification Specification Octets: 1 3 0 or 2 or 4 0 or 2 or 4 0 or 6 or 12 0 or 6 or 12 Address 3 Match Sequence Control Address 4 QoS Control HT Control Specification Specification Specification Specification Specification 0 or 6 or 12 0 or 2 or 4 0 or 6 or 12 0 or 2 or 4 0 or 4 or 8 Figure 9-279â€”Frame Classifier field of Classifier Type 6 For Classifier Type 6, the formats of the Frame Control Match Specification subfield, Duration/ID Match Specification subfield, Address 1 Match Specification subfield, Address 2 Match Specification subfield, Address 3 Match Specification subfield, Sequence Control Match Specification subfield, Address 4 Match Specification subfield, QoS Control Match Specification subfield and HT Control Match Specification subfield of the Frame Classifier field of a TCLAS element are shown in Figure 9-280, Figure 9-281, Figure 9-282, Figure 9-283, Figure 9-284, Figure 9-285, Figure 9-286, Figure 9-287, and Figure 9-288, respectively. The Match Specification subfield contains the match specification (i.e., the parameters) of the corresponding MAC header field with which an MPDU is compared. When the corresponding Filter Mask is not present, every bit in a Match Specification is compared; otherwise, only the bits with the same bit positions as the bits that are equal to 1 in the corresponding Filter Mask subfield are compared. Frame Control Match Frame Control Filter Mask Specification Octets: 2 0 or 2 Figure 9-280â€”Frame Control Match Specification subfield of Classifier Type 6 912 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Duration/ID Match Specification Duration/ID Filter Mask Octets: 2 0 or 2 Figure 9-281â€”Duration/ID Match Specification subfield of Classifier Type 6 Address 1 Match Specification Address 1 Filter Mask Octets: 6 0 or 6 Figure 9-282â€”Address 1 Match Specification subfield of Classifier Type 6 Address 2 Match Specification Address 2 Filter Mask Octets: 6 0 or 6 Figure 9-283â€”Address 2 Match Specification subfield of Classifier Type 6 Address 3 Match Specification Address 3 Filter Mask Octets: 6 0 or 6 Figure 9-284â€”Address 3 Match Specification subfield of Classifier Type 6 Sequence Control Match Sequence Control Filter Mask Specification Octets: 2 0 or 2 Figure 9-285â€”Sequence Control Match Specification subfield of Classifier Type 6 Address 4 Match Specification Address 4 Filter Mask Octets: 6 0 or 6 Figure 9-286â€”Address 4 Match Specification subfield of Classifier Type 6 QoS Control Match QoS Control Filter Mask Specification Octets: 2 0 or 2 Figure 9-287â€”QoS Control Match Specification subfield of Classifier Type 6 913 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications HT Control Match Specification HT Control Filter Mask Octets: 4 0 or 4 Figure 9-288â€”HT Control Match Specification subfield of Classifier Type 6 9.4.2.32 TS Delay element The TS Delay element is used in an ADDTS Response frame transmitted by an HC and indicates the time after which the ADDTS can be retried; see 11.4.7. The TS Delay element is defined in Figure 9-289. Element ID Length Delay (4) Octets: 1 1 4 Figure 9-289â€”TS Delay element The Element ID and Length fields are defined in 9.4.2.1. The Delay field is 4 octets long and specifies the amount of time, in TUs, a STA should wait before it reinitiates setup of a TS. The Delay field is set to 0 when an AP does not expect to serve any TSPECs for an indeterminate time and does not know this time a priori. 9.4.2.33 TCLAS Processing element The TCLAS Processing element is present in ADDTS Request, ADDTS Response, FMS Request, FMS Response, DMS Request, DMS Response, TFS Request and SCS Descriptor frames if there are multiple TCLAS elements associated with the request, response or descriptor. It is optionally present in the ADDTS Request and ADDTS Response frames if there are no TCLAS elements. Together with the TCLAS element(s), if present, it indicates how a PDU or MSDU should be processed by the classifier. The TCLAS Processing element is defined in Figure 9-290. Length Element ID Processing (1) Octets: 1 1 1 Figure 9-290â€”TCLAS Processing element The Element ID and Length fields are defined in 9.4.2.1. The Processing subfield is 1 octet long. The encoding of the Processing subfield is shown in Table 9-149. 914 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-149â€”Encoding of Processing subfield Processing Meaning subfield value 0 PDU contents or MSDU parameters have to match to the parameters in all of the associated TCLAS elements. 1 PDU contents or MSDU parameters have to match to at least one of the associated TCLAS elements. 2 PDUs or MSDUs that do not belong to any other TS are classified to the TS for which this TCLAS Processing element is used. In this case, there are no associated TCLAS elements. 3â€“255 Reserved 9.4.2.34 Schedule element The Schedule element is transmitted by the HC to a STA to announce the schedule that the HC/AP follows for admitted streams originating from or destined to that STA, or GCR-SP streams destined to that STA, in the future. The information in this element might be used by the STA for power management, internal scheduling, or any other purpose. The element information format is shown in Figure 9-291. Length Service Start Service Specification Element ID (12) Schedule Info Time Interval Interval Octets: 1 1 2 4 4 2 Figure 9-291â€”Schedule element The Element ID and Length fields are defined in 9.4.2.1. The Schedule Info field is shown in Figure 9-292. B0 B1 B4 B5 B6 B7 B15 Aggregation TSID Direction Reserved Bits: 1 4 2 9 Figure 9-292â€”Schedule Info field The Aggregation subfield is set to 1 if the schedule is an aggregate schedule for all TSIDs associated with the STA to which the frame is directed. It is set to 0 otherwise. The TSID subfield contains a value allowed for a TSID, as defined in 9.2.4.5.2, and indicates the TSID for which this schedule applies. The TSID subfield is reserved when the Schedule element is included within a GCR Response subelement. The Direction subfield is as defined in 9.4.2.30 and defines the direction of the TSPEC associated with the schedule. In a Schedule element sent within a GCR Response subelement, the Direction subfield is set to â€œDownlink.â€ The TSID and Direction subfields are valid only when the Aggregation subfield is 0. If the Aggregation subfield is 1, the TSID and Direction subfields are reserved. The Service Start Time field is 4 octets and indicates the anticipated time, expressed in microseconds, when service starts and represents the lower order 4 octets of the TSF timer value at the start of the first SP. The AP uses this field to confirm or modify the service start time indicated in the TSPEC request. The Service Interval field is 4 octets and indicates the time, expressed in microseconds, between two successive SPs and represents the measured time from the start of one SP to the start of the next SP. If the 915 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Schedule element is included within a GCR Response subelement that has the GCR delivery method equal to GCR-SP, a value of 0 in the Service Interval field indicates the delivery method is GCR-A. The Specification Interval field is 2 octets long and contains an unsigned integer that specifies the time interval, in TUs, to verify schedule compliance. The HC can set the Service Start Time field and the Service Interval field to 0 (unspecified) for nonpowersaving STAs, except when the Schedule element is included within a GCR Response subelement that has the GCR delivery method equal to GCR-SP (see 11.24.16.3.8). When the Schedule element is included within a GCR Response subelement that has the GCR delivery method equal to GCR-SP, the Service Start Time field is not set to 0 and the Service Interval field might be set to 0. 9.4.2.35 QoS Capability element The QoS Capability element contains a number of subfields that are used to advertise optional QoS capabilities at a QoS STA. The QoS Capability element is present in Beacon frames that do not contain the EDCA Parameter Set element and in (Re)Association Request frames. The QoS Capability element is defined in Figure 9-293. Element ID Length QoS Info (1) Octets: 1 1 1 Figure 9-293â€”QoS Capability element format The Element ID and Length fields are defined in 9.4.2.1. The QoS Info field is 1 octet in length and is defined in 9.4.1.17. 9.4.2.36 AP Channel Report element The AP Channel Report element contains a list of channels where a STA is likely to find an AP. The format of the AP Channel Report element is shown in Figure 9-294. See 11.11.18 for details. Operating Element ID Length Channel List Class Octets: 1 1 1 variable Figure 9-294â€”AP Channel Report element format The Element ID and Length fields are defined in 9.4.2.1. The minimum value of the Length field is 1 (based on a minimum length for the channel list field of 0 octets). Operating Class contains an enumerated value from Annex E, specifying the operating class in which the Channel List is valid. An AP Channel Report only reports channels for a single operating class. Multiple AP Channel Report elements are present when reporting channels in more than one operating class. The Channel List contains a variable number of octets, where each octet describes a single channel number. Channel numbering is dependent on Operating Class according to Annex E. 9.4.2.37 Neighbor Report element The format of the Neighbor Report element is shown in Figure 9-295. 916 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Element BSSID Operating Channel PHY Optional ID Length BSSID Information Class Number Type Subelements Octets: 1 1 6 4 1 1 1 variable Figure 9-295â€”Neighbor Report element format The Element ID and Length fields are defined in 9.4.2.1. Each Report element describes an AP and consists of BSSID, BSSID Information, Channel Number, Operating Class, PHY Type, and optionally includes optional subelements. The minimum value of the Length field is 13 (i.e., with no optional subelements in the Neighbor Report element). The BSSID is the BSSID of the BSS being reported. The subsequent fields in the Neighbor Report element pertain to this BSS. The BSSID Information field can be used to help determine neighbor service set transition candidates. It is 4 octets in length and contains the subfields as shown in Figure 9-296. B0 B1 B2 B3 B4 B9 B10 B11 B12 B13 B14 B31 AP Mobility High Very High Security Key Scope Capabilities FTM Reserved Reachability Domain Throughput Throughput Bits: 2 1 1 6 1 1 1 1 18 Figure 9-296â€”BSSID Information field The AP Reachability field indicates whether the AP identified by this BSSID is reachable by the STA that requested the neighbor report. For example, the AP identified by this BSSID is reachable for the exchange of preauthentication frames as described in 12.6.10.2. The values are shown in Table 9-150. Table 9-150â€”Reachability field Value Reachability Usage 0 Reserved Not used. 1 Not Reachable A station sending a preauthentication frame to the BSSID will not receive a response even if the AP indicated by the BSSID is capable of preauthentication. 2 Unknown The AP is unable to determine if the value Reachable or Not Reachable is to be returned. 3 Reachable The station sending a preauthentication frame to the BSSID can receive a response from an AP that is capable of preauthentication. The Security bit, if 1, indicates that the AP identified by this BSSID supports the same security provisioning as used by the STA in its current association. If the bit is 0, it indicates either that the AP does not support the same security provisioning or that the security information is not available at this time. The Key Scope bit, when set, indicates the AP indicated by this BSSID has the same authenticator as the AP sending the report. If this bit is 0, it indicates a distinct authenticator or the information is not available. 917 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Capabilities subfield contains selected capability information for the AP indicated by this BSSID. The bit fields within this subfield have the same meaning and are set to the equivalent bits within the Capability Information field (see 9.4.1.4) being sent in the beacons by the AP being reported. The format of the Capabilities subfield is as in Figure 9-297. B4 B5 B6 B7 B8 B9 Spectrum QoS APSD Radio Measurement Delayed Block Immediate Block Management Ack Ack Bits: 1 1 1 1 1 1 Figure 9-297â€”Capabilities subfield The Mobility Domain bit is set to 1 to indicate that the AP represented by this BSSID is including an MDE in its Beacon frames and that the contents of that MDE are identical to the MDE advertised by the AP send- ing the report. The High Throughput bit is set to 1 to indicate that the AP represented by this BSSID is an HT AP including the HT Capabilities element in its Beacons, and that the contents of that HT Capabilities element are identi- cal to the HT Capabilities element advertised by the AP sending the report. The Very High Throughput bit is set to 1 to indicate that the AP represented by this BSSID is a VHT AP and that the VHT Capabilities element, if included as a subelement in the report, is identical in content to the VHT Capabilities element included in the APâ€™s Beacon. The FTM field is set to 1 to indicate that the AP represented by this BSSID is an AP that has set the Fine Timing Measurement Responder field of the Extended Capabilities element to 1. The FTM field is set to 0 to indicate either that the reporting AP has dot11FineTimingMsmtRespActivated equal to false, or the reported AP has not set the Fine Timing Measurement Responder field of the Extended Capabilities element to 1 or that the Fine Timing Measurement Responder field of the reported AP is not available to the reporting AP at this time. Bits 14â€“31 are reserved. The Operating Class field indicates the channel set of the AP indicated by this BSSID. The Country, Operating Class, and Channel Number fields together specify the channel frequency and spacing for the channel on which the Beacon frames are being transmitted for the BSS being reported. Valid operating classes are listed in Annex E. The Channel Number field indicates the last known primary channel of the AP indicated by this BSSID. Channel number is defined within an operating class as shown in Annex E. The PHY Type field indicates the PHY type of the AP indicated by this BSSID. It is an integer value coded according to the value of the dot11PHYType. The Optional Subelements field contains zero or more subelements. The subelement format and ordering of subelements are defined in 9.4.3. The Subelement ID field values for the defined subelements are shown in Table 9-151. 918 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-151â€”Optional subelement IDs for Neighbor report Subelement ID Name Extensible 0 Reserved 1 TSF Information Yes 2 Condensed Country String Yes 3 BSS Transition Candidate Preference 4 BSS Termination Duration 5 Bearing 6 Wide Bandwidth Channel Yes 7â€“38 Reserved 39 Measurement Report Subelements 40â€“44 Reserved 45 HT Capabilities subelement Yes 46â€“60 Reserved 61 HT Operation subelement Yes 62 Secondary Channel Offset subelement 63â€“65 Reserved 66 Measurement Pilot Transmission Subelements 67â€“69 Reserved 70 RM Enabled Capabilities Yes 71 Multiple BSSID Subelements 72â€“190 Reserved 191 VHT Capabilities Yes 192 VHT Operation Yes 193â€“220 Reserved 221 Vendor Specific 222â€“255 Reserved The TSF subelement contains TSF Offset and Beacon Interval subfields as shown in Figure 9-298. Subelement ID Length TSF Offset Beacon Interval Octets: 1 1 2 2 Figure 9-298â€”TSF subelement format The Length field is defined in 9.4.3. The TSF Offset subfield is 2 octets long and contains the neighbor APâ€™s TSF timer offset. This is the time difference, in TU units, between the serving AP and a neighbor AP. This offset is given modulo the neighbor APâ€™s Beacon Interval and rounded to the nearest TU boundary. 919 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Beacon Interval field is the beacon interval of the Neighbor AP indicated by this BSSID. This field is defined in 9.4.1.3 and illustrated in Figure 9-67. The Condensed Country String subelement is set to the first two octets of the value contained in dot11CountryString. This subelement is present only if the country of the neighbor AP indicated by the BSSID differs from the country of the AP that sent this neighbor report. The Measurement Pilot Transmission subelement has the same format as the Measurement Pilot Transmission element (see 9.4.2.42). The Measurement Pilot Interval subelement is not included if the reported AP is not transmitting Measurement Pilot frames or if the Measurement Pilot Interval of the reported AP is unknown. A Measurement Report subelement with the Measurement Type field equal to LCI (see Table 9-107) is optionally present. If present, the subelement has the same format as the Measurement Report element with Measurement Type field equal to LCI.The subelement indicates the LCI of the neighbor STA and further includes the Z subelement, or the subelement indicates an unknown LCI (see 11.24.6.7). The Late, Incapable and Refused bits in the Measurement Report Mode field are set to 0. The Co-Located BSSID List subelement is present in the Measurement Report subelement of the Neighbor Report element, when there is at least one other BSS which is co-located with the reporting BSS. A Measurement Report subelement with the Measurement Type field equal to Location Civic (see Table 9- 107) is optionally present. If present, the subelement has the same format as the Measurement Report element with Measurement Type field equal to Location Civic, and the subelement indicates the civic address of the transmitting STA or an unknown civic address (see 11.24.6.7). The Late, Incapable and Refused bits in the Measurement Report Mode field are set to 0. The Co-Located BSSID List subelement is present in the Measurement Report subelement of the Neighbor Report element, when there is at least one other BSS which is co-located with the reporting BSS. When a Measurement Report subelement with Measurement Type field equal to LCI that includes a Co-Located BSSID List subelement is present, the Co- Located BSSID List subelement is not present in the Measurement Report subelement with Measurement Type field equal to Location Civic. The HT Capabilities subelement is the same as the HT Capabilities element as defined in 9.4.2.56. The HT Operation subelement is the same as the HT Operation element as defined in 9.4.2.57. The Secondary Channel Offset subelement is the same as the Secondary Channel Offset element as defined in 9.4.2.20. The RM Enabled Capabilities subelement has the same format as the RM Enabled Capabilities element (see 9.4.2.45). The Multiple BSSID subelement has the same format as the Multiple BSSID element (see 9.4.2.46). The reference BSSID for the Multiple BSSID subelement is the BSSID field in the Neighbor Report element. This subelement is not present if the neighbor AP is not a member of a multiple BSSID set with two or more members or its membership is unknown. (see 11.11.14). The format of the BSS Transition Candidate Preference subelement is shown in Figure 9-299. Subelement ID Length Preference Octets: 1 1 1 Figure 9-299â€” BSS Transition Candidate Preference subelement format 920 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Length field is defined in 9.4.3. The Preference field indicates the network preference for BSS transition to the BSS listed in this BSS Transition Candidate List Entries field in the BSS Transition Management Request frame, BSS Transition Management Query frame, and BSS Transition Management Response frame. The Preference field value is a number ranging from 0 to 255, as defined in Table 9-152, indicating an ordering of preferences for the BSS transition candidates for this STA. Additional details describing use of the Preference field are provided in 11.24.7. Table 9-152â€”Preference field values Preference field value Description 0 Excluded BSS; reserved when present in the BSS Transition Management Query or BSS Transition Management Response frames. 1â€“255 Relative values used to indicate the preferred ordering of BSSs, with 255 indicating the most preferred candidate and 1 indicating the least preferred candidate. The BSS Termination TSF field contained in the BSS Termination Duration subelement is the TSF time of the BSS transmitting the neighbor report that corresponds to the time when termination of the neighbor BSS occurs. How the BSS determines the neighbor BSS termination time is out of scope of the standard. The format of the BSS Termination Duration subelement is shown in Figure 9-300. BSS Subelement ID Length Duration Termination TSF Octets: 1 1 8 2 Figure 9-300â€”BSS Termination Duration subelement format The Length field is defined in 9.4.3. The BSS Termination TSF field indicates the value of the TSF timer when BSS termination will occur in the future. A BSS Termination TSF field value of 0 indicates that termination of the BSS will occur imminently. Prior to termination of the BSS, all associated STAs are disassociated by the AP. The Duration field is an unsigned 2-octet integer that indicates the number of minutes for which the BSS is not present. The Duration field value of 0 is reserved. The Duration field value is 65 535 when the BSS is terminated for a period longer than or equal to 65 535 minutes. The format of the Bearing subelement is shown in Figure 9-301. Subelement ID Length Bearing Distance Relative Height Octets: 1 1 2 4 2 Figure 9-301â€”Bearing subelement format The Length field is defined in 9.4.3. 921 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Bearing field specifies the direction that the neighbor, specified by the BSSID field in the Neighbor Report element, is positioned, relative to the reporting BSS and defined in relation to true north, increasing clockwise, measured in degrees from 0Â° to 359Â°. If the Bearing value is unknown, the subelement is not included. The Distance field specifies the distance that the neighbor, specified by the BSSID field in the Neighbor Report element, is positioned relative to the reporting BSS as a 4-octet single precision floating point value represented by a binary32 floating point value as defined in IEEE Std 754-2008, with the least significant bit of the fraction occurring in bit 0 of the field, in meters. If the Distance field value is unknown the field is set to 0. The Relative Height field, defined by a 2-octet signed integer, specifies the relative height in meters that the neighbor is positioned, relative to the reporting BSS. If the Relative height is unknown or at the same height as the reporting BSS, the field is 0. The format of the Wide Bandwidth Channel subelement is shown in Figure 9-302. Channel Center Channel Center Subelement ID Length Channel Width Frequency Frequency Segment 0 Segment 1 Octets: 1 1 1 1 1 Figure 9-302â€”Wide Bandwidth Channel subelement format The Length field is defined in 9.4.3. The Channel Width, Channel Center Frequency Segment 0, and Channel Center Frequency Segment 1 subfields are defined in Table 9-153. Table 9-153â€”HT/VHT Operation Information subfields Field Definition Encoding Channel This field defines the BSS Set to 0 for 20 MHz BSS bandwidth. Width bandwidth (see 11.40.1). Set to 1 for 40 MHz BSS bandwidth. Set to 2 for 80 MHz BSS bandwidth. Set to 3 for 160 MHz BSS bandwidth. Set to 4 for 80+80 MHz operating channel width. Values in the range 5 to 255 are reserved. Channel Defines the channel center For 20, 40, 80, or 160 MHz BSS bandwidth, Center frequency for an HT or VHT BSS indicates the channel center frequency index for the Frequency or the frequency segment 0 channel channel on which the HT or VHT BSS operates. Segment 0 center frequency for an 80+80 MHz VHT BSS. See 21.3.14. For 80+80 MHz BSS bandwidth, indicates the channel center frequency index for the 80 MHz channel of frequency segment 0 on which the VHT BSS operates. Channel Defines the frequency segment 1 For an 80+80 MHz BSS bandwidth, indicates the Center channel center frequency for an channel center frequency index of the 80 MHz Frequency 80+80 MHz VHT BSS. See channel of frequency segment 1 on which the VHT Segment 1 21.3.14. BSS operates. The channel center frequency index of segment 1 differs by more than 16 from the channel center frequency index of segment 0 (i.e., the channel center frequencies are more than 80 MHz apart). Reserved otherwise. 922 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The VHT Capabilities subelement is the same as the VHT Capabilities element as defined in 9.4.2.158. The VHT Operation subelement is the same as the VHT Operation element as defined in 9.4.2.159. The Vendor Specific subelement has the same format as the Vendor Specific element (see 9.4.2.26). Multiple Vendor Specific subelements are optionally present in the list of optional subelements. 9.4.2.38 RCPI element The RCPI element indicates the received frame power level at the receiving STA as shown in Figure 9-303. Element ID Length RCPI Octets: 1 1 1 Figure 9-303â€”RCPI element format The Element ID and Length fields are defined in 9.4.2.1. The RCPI field contains an RCPI value, which is an indication of the received RF power in the selected channel for a received frame. RCPI is a monotonically increasing, logarithmic function of the received power level. The allowed values for the RCPI field are defined in Table 9-154, where P is the received power level in dBm. Table 9-154â€”RCPI values RCPI Value Description 0 Represents P < â€“109.5 dBm 1â€“219 Power levels in the range â€“ 109.5 P 0 are represented by RCPI = 2 P + 110 220 Represents P 0 dBm 221â€“254 Reserved 255 Measurement not available 9.4.2.39 BSS Average Access Delay element The BSS Average Access Delay element contains the AP Average Access Delay, which is a measure of load in the BSS and is available in both QoS APs and non-QoS APs. The format of the BSS Average Access Delay element is defined in Figure 9-304. AP Average Element ID Length Access Delay Octets: 1 1 1 Figure 9-304â€”BSS Average Access Delay element format The Element ID and Length fields are defined in 9.4.2.1. 923 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The AP Average Access Delay is a scalar indication of the relative level of loading at an AP. A low value indicates more available capacity than a higher value. If the AP is not currently transmitting any DCF or EDCAF traffic, the AP Average Access Delay is set to 255. The values between 1 and 252 are a scaled representation of the average medium access delay for all DCF and EDCAF transmitted frames measured from the time the DCF or EDCAF MPDU is ready for transmission (i.e., begins CSMA/CA access) until the actual frame transmission start time. Non-QoS APs average the access delays for all DCF transmitted frames. QoS APs average the access delays for all EDCA transmitted frames of all ACs. The AP Average Access Delay values are scaled as follows: 0: Access Delay < 8 Âµs 1: 8 Âµs Access Delay < 16 Âµs 2 n 14: n 8 Âµs Access Delay < (n + 1) 8 Âµs 15: 120 Âµs Access Delay < 128 Âµs 16: 128 Âµs Access Delay < 144 Âµs 17 n 106: (n 16) â€“ 128 Âµs Access Delay < ((n + 1) 16) â€“ 128 Âµs 107: 1 584 Âµs Access Delay < 1 600 Âµs 108: 1 600 Âµs Access Delay < 1 632 Âµs 109 n 246: (n 32) â€“ 1 856 Âµs Access Delay < ((n + 1) 32) â€“ 1 856 Âµs 247: 6 048 Âµs Access Delay < 6 080 Âµs 248: 6 080 Âµs Access Delay < 8 192 Âµs 249: 8 192 Âµs Access Delay < 12 288 Âµs 250: 12 288 Âµs Access Delay < 16 384 Âµs 251: 16 384 Âµs Access Delay < 20 480 Âµs 252: 20 480 Âµs Access Delay < 24 576 Âµs 253: 24 576 Âµs Access Delay 254: Service unable to access channel 255: Measurement not available The values 0â€“253 indicate Average Access Delay when one or more frames were transmitted during the measurement window. The value 254 indicates that the DCF is or the EDCAFs are currently unable to access the channel due to continuous carrier sense mechanism deferral and that no frames were transmitted during the measurement window. The AP measures and averages the medium access delay for all transmit frames using the DCF or the EDCAFs over a continuous 30 s measurement window. See 11.11.16 for accuracy requirements. 9.4.2.40 Antenna element The Antenna element contains the Antenna ID field as shown in Figure 9-305. 924 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Element ID Length Antenna ID Octets: 1 1 1 Figure 9-305â€”Antenna element format The Element ID and Length fields are defined in 9.4.2.1. The Antenna ID field contains the identifying number for the relevant antenna(s). The Antenna ID identifies the antenna(s) used to transmit the frame the Antenna element is contained in. A specific antenna has an Antenna ID between 1 and 254. The value 0 indicates that the antenna identifier is unknown. The value 255 indicates that this transmission was made with multiple antennas, i.e., antennas were switched during the transmission. If during frame reception, different antennas are used to receive the preamble and body, the antenna ID identifies the antenna that receives the frame body. In these cases, the value 255 is not used. The value 1 is the only value used for a STA with only one antenna. STAs with more than one antenna assign Antenna IDs to each antenna and each antenna configuration as consecutive, positive integers starting with 1. Each Antenna ID number represents a unique antenna or unique configuration of multiple antennas characterized by a fixed relative position, a fixed relative direction, and a fixed peak gain for that position and direction. 9.4.2.41 RSNI element The RSNI element contains an RSNI value, as shown in Figure 9-306. Element ID Length RSNI Octets: 1 1 1 Figure 9-306â€”RSNI element format The Element ID and Length fields are defined in 9.4.2.1. RSNI is in steps of 0.5 dB. RSNI is calculated by the ratio of the received signal power (RCPI-ANPI) to the noise plus interference power (ANPI) using the expression: RSNI = (10 log10((RCPIpower â€“ ANPIpower) / ANPIpower)+10) 2 where RCPIpower and ANPIpower indicate power domain values for RCPI and ANPI and not dB domain values. RSNI in dB is scaled in steps of 0.5 dB to obtain 8-bit RSNI values, which cover the range from â€“10 dB to +117 dB. The value 255 indicates that RSNI is not available. See 11.11.9.4 for details and procedures for measuring ANPI. 9.4.2.42 Measurement Pilot Transmission element The Measurement Pilot Transmission element contains a Measurement Pilot Transmission field as shown in Figure 9-307. Measurement Pilot Optional Element ID Length Transmission Subelements Octets: 1 1 1 variable Figure 9-307â€”Measurement Pilot Transmission element format 925 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Element ID field is equal to the Measurement Pilot Transmission value in Table 9-77. The Element ID and Length fields are defined in 9.4.2.1. The Measurement Pilot Transmission field contains the Measurement Pilot Interval as specified in 9.4.1.18. The Optional Subelements field contains zero or more subelements. The subelement format and ordering of subelements are defined in 9.4.3. The Subelement ID field values for the defined subelements are shown in Table 9-155. Table 9-155â€”Optional subelement IDs for Measurement Pilot Transmission Subelement ID Name Extensible 0â€“220 Reserved 221 Vendor Specific 222â€“255 Reserved The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26). Multiple Vendor Specific subelements are optionally present in the list of optional subelements. 9.4.2.43 BSS Available Admission Capacity element The BSS Available Admission Capacity element contains a list of Available Admission Capacity fields at different User Priorities and Access Categories as shown in Figure 9-308. NOTEâ€”The BSS Available Admission Capacity element is helpful for roaming QoS STAs to select a QoS AP that is likely to accept future admission control requests, but it does not provide an assurance that the HC will admit these requests. Element Available Admission Available Admission ID Length Capacity Bitmask Capacity List Octets: 1 1 2 2 Ã— (total number of nonzero bits in Available Admission Capacity Bitmask) Figure 9-308â€”BSS Available Admission Capacity element format The Element ID and Length fields are defined in 9.4.2.1. The Length field is set to 2 + 2Nnz, where Nnz equals the total number of nonzero bits in Available Admission Capacity Bitmask. The Available Admission Capacity Bitmask field indicates the UP values that have an Available Admission Capacity specified in the Available Admission Capacity List field. The format of the Available Admission Capacity Bitmask is defined in Table 9-156. Each bit in the Available Admission Capacity Bitmask is set to 1 to indicate that the Available Admission Capacity for the corresponding traffic type is present in the Available Admission Capacity List field. The bit is set to 0 to indicate that the Available Admission Capacity for the corresponding traffic type is not present in the Available Admission Capacity List field. 926 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-156â€”Available Admission Capacity Bitmask definition Bit Available Admission Capacity Reported 0 UP 0 1 UP 1 2 UP 2 3 UP 3 4 UP 4 5 UP 5 6 UP 6 7 UP 7 8 AC 0 9 AC 1 10 AC 2 11 AC 3 12â€“15 Reserved The Available Admission Capacity List comprises a sequence of Available Admission Capacity fields corresponding respectively to the nonzero bits in the Available Admission Capacity Bitmask field. The Available Admission Capacity field is 2 octets long and contains an unsigned integer that specifies the amount of medium time available using explicit admission control for the corresponding UP or AC traffic, in units of 32 Âµs per 1 s. See 11.11.17 for furthers details. 9.4.2.44 BSS AC Access Delay element The BSS AC Access Delay element contains an Access Category Access Delay field, as shown in Figure 9-309. Element Access Category Length ID Access Delay Octets: 1 1 4 Figure 9-309â€”BSS AC Access Delay element format The Element ID and Length fields are defined in 9.4.2.1. The AC Access Delay field is formatted as four subfields as shown in Figure 9-310. The AC Access Delay is a scalar indication of the average access delay at a QoS AP for services for each of the indicated access categories. If the QoS AP is not currently transmitting any traffic using the indicated AC, the Average Access Delay for that AC is set to 255. The values between 1 and 252 are a scaled representation of the average medium access delay for transmitted frames in the indicated AC measured from the time the EDCA MPDU is ready for transmission (i.e., begins CSMA/CA access) until the actual frame transmission start time. The AC Access Delay values are scaled as follows: 927 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 0: Access Delay < 8 Âµs 1: 8 Âµs Access Delay < 16 Âµs 2 n 14: n 8 Âµs Access Delay < (n + 1) 8 Âµs 15: 120 Âµs Access Delay < 128 Âµs 16: 128 Âµs Access Delay < 144 Âµs 17 n 106: (n 16) â€“ 128 Âµs Access Delay < ((n + 1) 16) â€“ 128 Âµs 107: 1584 Âµs Access Delay < 1600 Âµs 108: 1600 Âµs Access Delay < 1632 Âµs 109 n 246: (n 32) â€“ 1856 Âµs Access Delay < ((n + 1) 32) â€“ 1856 Âµs 247: 6048 Âµs Access Delay < 6080 Âµs 248: 6080 Âµs Access Delay < 8192 Âµs 249: 8192 Âµs Access Delay < 12 288 Âµs 250: 12 288 Âµs Access Delay < 16 384 Âµs 251: 16 384 Âµs Access Delay < 20 480 Âµs 252: 20 480 Âµs Access Delay < 24 576 Âµs 253: 24 576 Âµs Access Delay 254: Service unable to access channel 255: Measurement not available The values 0â€“253 indicate Average Access Delay when one or more frames were transmitted during the measurement window. The value 254 indicates that the EDCAF is currently unable to access the channel due to continuous carrier sense mechanism deferral to higher priority AC transmissions and that no frames were transmitted during the measurement window. The QoS AP measures and averages the medium access delay for all transmit frames of the indicated AC using EDCA mechanism over a continuous 30 s measurement window. See 11.11.16 for accuracy requirements. Average Access Delay for Average Access Average Access Average Access Delay for Background Delay for Video Delay for Voice Best Effort (AC_BK) (AC_VI) (AC_VO) (AC_BE) Octets: 1 1 1 1 Figure 9-310â€”Access Category Access Delay subfields 928 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.45 RM Enabled Capabilities element The RM Enabled Capabilities element signals support for radio measurements in a STA. The element is shown in Figure 9-311. Element Length RM Enabled ID Capabilities Octets: 1 1 5 Figure 9-311â€”RM Enabled Capabilities element format The Element ID and Length fields are defined in 9.4.2.1. The RM Enabled Capabilities field is an octet string. Each subfield of this field indicates whether the corresponding capability listed in Table 9-157 is enabled. Table 9-157â€”RM Enabled Capabilities definition Bit position in the RM Enabled Field name Notes Capabilities field 0 Link Measurement A STA sets the Link Measurement Capability Enabled field to 1 Capability Enabled when dot11RMLinkMeasurementActivated is true and sets it to 0 otherwise. 1 Neighbor Report A STA sets the Neighbor Report Capability Enabled field to 1 Capability Enabled when dot11RMNeighborReportActivated is true and sets it to 0 otherwise. 2 Parallel Measurements A STA sets the Parallel Measurements Capability Enabled field to Capability Enabled 1 when dot11RMParallelMeasurementsActivated is true and sets it to 0 otherwise. 3 Repeated A STA sets the Repeated Measurements Capability Enabled field Measurements to 1 when dot11RMRepeatedMeasurementsActivated is true and Capability Enabled sets it to 0 otherwise. 4 Beacon Passive A STA sets the Beacon Passive Measurement Capability Enabled Measurement field to 1 when dot11RMBeaconPassiveMeasurementActivated is Capability Enabled true and sets it to 0 otherwise. 5 Beacon Active A STA sets the Beacon Active Measurement Capability Enabled Measurement field to 1 when dot11RMBeaconActiveMeasurementActivated is Capability Enabled true and sets it to 0 otherwise. 6 Beacon Table A STA sets the Beacon Table Measurement Capability Enabled Measurement field to 1 when dot11RMBeaconTableMeasurementActivated is Capability Enabled true and sets it to 0 otherwise. 7 Beacon Measurement A STA sets the Beacon Measurement Reporting Conditions Reporting Conditions Capability Enabled field to 1 when Capability Enabled dot11RMBeaconMeasurementReportingConditionsActivated is true and sets it to 0 otherwise. 8 Frame Measurement A STA sets the Frame Measurement Capability Enabled field to 1 Capability Enabled when dot11RMFrameMeasurementActivated is true and sets it to 0 otherwise. 929 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-157â€”RM Enabled Capabilities definition (continued) Bit position in the RM Enabled Field name Notes Capabilities field 9 Channel Load A STA sets the Channel Load Measurement Capability Enabled Measurement field to 1 when dot11RMChannelLoadMeasurementActivated is Capability Enabled true and sets it to 0 otherwise. 10 Noise Histogram A STA sets the Noise Histogram Measurement Capability Enabled Measurement field to 1 when dot11RMNoiseHistogramMeasurementActivated Capability Enabled is true and sets it to 0 otherwise. 11 Statistics Measurement A STA sets the Statistics Measurement Capability Enabled field to Capability Enabled 1 when dot11RMStatisticsMeasurementActivated is true and sets it to 0 otherwise. 12 LCI Measurement A STA sets the LCI Measurement Capability Enabled field to 1 Capability Enabled when dot11RMLCIMeasurementActivated is true and sets it to 0 otherwise. 13 LCI Azimuth A STA sets the LCI Azimuth Capability Enabled field to 1 when Capability Enabled dot11RMLCIAzimuthActivated is true and sets it to 0 otherwise. 14 Transmit Stream/ A STA sets the Transmit Stream/Category Measurement Category Measurement Capability Enabled field to 1 when Capability Enabled dot11RMTransmitStreamCategoryMeasurementActivated is true and sets it to 0 otherwise. 15 Triggered Transmit A STA sets the Triggered Transmit Stream/Category Measurement Stream/Category Capability Enabled field to 1 when Measurement dot11RMTriggeredTransmitStreamCategoryMeasurementActivate Capability Enabled d is true and sets it to 0 otherwise. 16 AP Channel Report A STA sets the AP Channel Report Capability Enabled field to 1 Capability Enabled when dot11RMAPChannelReportActivated is true and sets it to 0 otherwise. 17 RM MIB Capability A STA sets the RM MIB Capability Enabled field to 1 when Enabled dot11RMMIBActivated is true and sets it to 0 otherwise. 18â€“20 Operating Channel A STA sets the Operating Channel Max Measurement Duration Max Measurement field to equal dot11RMMaxMeasurementDuration. See 11.11.4. Duration 21â€“23 Nonoperating Channel A STA sets the Nonoperating Channel Max Measurement Max Measurement Duration field to equal Duration dot11RMNonOperatingChannelMaxMeasurementDuration. See 11.11.4. 24â€“26 Measurement Pilot A STA sets the Measurement Pilot Capability field to equal Capability dot11RMMeasurementPilotActivated. See Table 11-10 in 11.11.15. 27 Measurement Pilot A STA sets the Measurement Pilot Transmission Capability Transmission Enabled field to 1 when Information Capability dot11RMMeasurementPilotTransmissionInformationActivated is Enabled true and sets it to 0 otherwise. 28 Neighbor Report TSF A STA sets the Neighbor Report TSF Offset Capability Enabled Offset Capability field to 1 when dot11RMNeighborReportTSFOffsetActivated is Enabled true and sets it to 0 otherwise. 930 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-157â€”RM Enabled Capabilities definition (continued) Bit position in the RM Enabled Field name Notes Capabilities field 29 RCPI Measurement A STA sets the RCPI Measurement Capability Enabled field to 1 Capability Enabled when dot11RMRCPIMeasurementActivated is true and sets it to 0 otherwise. 30 RSNI Measurement A STA sets the RSNI Measurement Capability Enabled field to 1 Capability Enabled when dot11RMRSNIMeasurementActivated is true and sets it to 0 otherwise. 31 BSS Average Access A STA sets the BSS Average Access Delay Capability Enabled Delay Capability field to 1 when dot11RMBSSAverageAccessDelayActivated is Enabled true and sets it to 0 otherwise (see NOTE). 32 BSS Available A STA sets the BSS Available Admission Capacity Capability Admission Capacity Enabled field to 1 when Capability Enabled dot11RMBSSAvailableAdmissionCapacityActivated is true and sets it to 0 otherwise. 33 Antenna Capability A STA sets the Antenna Capability Enabled field to 1 when Enabled dot11RMAntennaInformationActivated is true and sets it to 0 otherwise. 34 FTM Range Report A STA sets the FTM Range Report Capability Enabled field to 1 Capability Enabled when dot11RMFineTimingMsmtRangeRepActivated is true and sets it to 0 otherwise. 35 Civic Location A STA sets the Civic Location Measurement Capability Enabled Measurement field to 1 when dot11RMCivicMeasurementActivated is true and Capability Enabled sets it to 0 otherwise. 36â€“39 Reserved NOTEâ€”At a QoS AP dot11RMBSSAverageAccessDelayActivated is true indicates that the AP BSS AC Access Delay capability is also enabled. 9.4.2.46 Multiple BSSID element The format of the Multiple BSSID element is shown in Figure 9-312. MaxBSSID Optional Element ID Length Indicator Subelements Octets: 1 1 1 variable Figure 9-312â€”Multiple BSSID element format The Element ID and Length fields are defined in 9.4.2.1. The Max BSSID Indicator field contains a value assigned to n, where 2n is the maximum number of BSSIDs in the multiple BSSID set, including the reference BSSID (see 11.11.14). The actual number of BSSIDs in the multiple BSSID set is not explicitly signaled. The BSSID(i) value corresponding to the ith BSSID in the multiple BSSID set is derived from a reference BSSID (REF_BSSID) as follows: BSSID(i) = BSSID_A | BSSID_B where 931 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications BSSID_A is a BSSID with (48â€“n) MSBs equal to the (48â€“n) MSBs of the REF_BSSID and n LSBs equal to 0 BSSID_B is a BSSID with (48â€“n) MSBs equal to 0 and n LSBs equal to [(n LSBs of REF_BSSID) +i] mod 2n When the Multiple BSSID element is transmitted in a Beacon, DMG Beacon, or Probe Response frame, the reference BSSID is the BSSID of the frame. More than one Multiple BSSID element can be included in a Beacon or DMG Beacon frame. The AP or DMG STA determines the number of Multiple BSSID elements. The AP or DMG STA does not fragment a nontransmitted BSSID profile subelement for a single BSSID across two Multiple BSSID elements unless the length of the nontransmitted BSSID profile subelement exceeds 255 octets. When the Multiple BSSID element is transmitted as a subelement in a Neighbor Report element, the reference BSSID is the BSSID field in the Neighbor Report element. The Optional Subelements field contains zero or more subelements. The subelement format and ordering of subelements are defined in 9.4.3. The Subelement ID field values for the defined subelements are shown in Table 9-158. Table 9-158â€”Optional subelement IDs for Multiple BSSID Subelement ID Name Extensible 0 Nontransmitted BSSID Profile 1â€“220 Reserved 221 Vendor Specific 222â€“255 Reserved The Nontransmitted BSSID Profile subelement contains a list of elements for one or more APs or DMG STAs that have nontransmitted BSSIDs and is defined as follows: â€” For each nontransmitted BSSID, the Nontransmitted BSSID Capability element (see 9.4.2.72) is the first element included, followed by a variable number of elements, in the order defined in 9-27. â€” The SSID and multiple BSSID-index subelements are included in the Nontransmitted BSSID Profile subelement. â€” The FMS Descriptor element is included in the Nontransmitted BSSID Profile subelement if the Multiple BSSID element is included in a Beacon frame and if the TIM field indicates there are buffered group addressed frames for this nontransmitted BSSID. â€” The Timestamp and Beacon Interval fields, DSSS Parameter Set, IBSS Parameter Set, Country, Channel Switch Announcement, Extended Channel Switch Announcement, Wide Bandwidth Channel Switch, Transmit Power Envelope, Supported Operating Classes, IBSS DFS, ERP Information, HT Capabilities, HT Operation, VHT Capabilities, and VHT Operation elements are not included in the Nontransmitted BSSID Profile subelement; the values of these elements for each nontransmitted BSSID are always the same as the corresponding transmitted BSSID element values. The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26). Multiple Vendor Specific subelements are optionally present in the list of optional subelements. The Multiple BSSID element is included in Beacon frames (as described in 9.3.3.3), in DMG Beacon frames (as described in 9.3.4.2), and Probe Response frames (as described in 9.3.3.11). The use of the Multiple BSSID element is described in 11.11.14. Nontransmitted BSSID advertisement procedures are described in 11.1.3.8. 932 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.47 Mobility Domain element (MDE) The MDE contains the MDID (Mobility Domain Identifier) field and the FT Capability and Policy field. The AP uses the MDE to advertise that it is included in the group of APs that constitute a mobility domain, to advertise its support for FT capability, and to advertise its FT policy information. The format for this element is given in Figure 9-313. Element ID Length MDID FT Capability and Policy Octets: 1 1 2 1 Figure 9-313â€”Mobility Domain element format The Element ID and Length fields are defined in 9.4.2.1. The MDID field is a 2-octet value that follows the ordering conventions defined in 9.2.2. The FT Capability and Policy field is 1 octet. The FT Capability and Policy field is defined in Figure 9-314. B0 B1 B2 B7 Fast BSS Resource Request Transition Reserved over DS Protocol Capability Bits: 1 1 6 Figure 9-314â€”FT Capability and Policy field Bits 0â€“1 of the FT Capability and Policy field control the behavior of STAs performing fast BSS transitions (see 13.3). The STA might use information from the MDE to determine the transition methods recommended by the AP and protocols supported by the AP. The choice of executing any specific transition method is outside the scope of this standard. If the Resource Request Protocol Capability subfield is 1, then the STA might perform the FT resource request protocol as described in 13.6. When sent by a STA to a target AP, the FT Capability and Policy field matches the value advertised by that target AP. See 13.8. 9.4.2.48 Fast BSS Transition element (FTE) The FTE includes information needed to perform the FT authentication sequence during a fast BSS transition in an RSN. This element is shown in Figure 9-315. Element MIC Optional ID Length Control MIC ANonce SNonce Parameter(s) Octets: 1 1 2 16 32 32 variable Figure 9-315â€”FTE format The Element ID and Length fields are defined in 9.4.2.1. 933 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The MIC Control field is two octets and is defined in Figure 9-316. B0 B7 B8 B15 Reserved Element Count Bits: 8 8 Figure 9-316â€”MIC Control field The Element Count subfield of the MIC Control field contains the number of elements that are included in the message integrity code (MIC) calculation. A value of 0 indicates no MIC is present. The MIC field contains a MIC that is calculated using the algorithm specified in 13.8.4 and 13.8.5. The ANonce field contains a value chosen by the R1KH. It is encoded following the conventions in 9.2.2. The SNonce field contains a value chosen by the S1KH. It is encoded following the conventions in 9.2.2. The format of the Optional Parameter(s) field is shown in Figure 9-317. Subelement ID Length Data Octets: 1 1 variable Figure 9-317â€”Optional Parameter(s) field The Subelement ID field is defined in Table 9-159: Table 9-159â€”Subelement IDs Value Contents of Data field 0 Reserved 1 PMK-R1 key holder identifier (R1KH-ID) 2 GTK subelement 3 PMK-R0 key holder identifier (R0KH-ID) 4 IGTK 5â€“255 Reserved R1KH-ID indicates the identity of the R1KH, which is used by the S0KH and the R0KH for deriving the PMK-R1s. It is encoded following the conventions in 9.2.2. 934 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The GTK subelement contains the group temporal key, which is encrypted (see procedures in 13.8.5) and is defined in Figure 9-318. Subelement ID Length Key Info Key Length RSC Wrapped Key Octets: 1 1 2 1 8 24â€“40 Figure 9-318â€”GTK subelement format The GTK subelement Key Info subfield is defined in Figure 9-319. B0 B1 B2 B15 Key ID Reserved Bits: 2 14 Figure 9-319â€”GTK subelementâ€™s Key Info subfield Key Length field is the length of the Key field in octets, not including any padding (see 13.8.5). RSC field contains the receive sequence counter (RSC) for the GTK being installed. Delivery of the RSC field value allows a STA to identify replayed MPDUs. If the RSC field value is less than 8 octets in length, the remaining octets are set to 0. The least significant octet of the transmit sequence counter (TSC) or packet number (PN) is in the first octet of the RSC field. See Table 12-5. For WEP, the RSC value is reserved. The Wrapped Key field contains the encrypted GTK as described in 13.8.5. When sent by a non-AP STA, the R0KH-ID indicates the R0KH with which the S0KH negotiated the PMK-R0 it is using for this transition. When sent by an AP, the R0KH-ID indicates the R0KH that the S0KH will be using to generate a PMK-R0 security association. It is encoded following the conventions from 9.2.2. The IGTK field contains the Integrity GTK, used for protecting robust Management frames. The IGTK subelement format is shown in Figure 9-320. Subelement ID Length Key ID IPN Key Length Wrapped Key Octets: 1 1 2 6 1 24 Figure 9-320â€”IGTK subelement format The Key ID field indicates the value of the BIP key identifier. The IPN field indicates the receive sequence counter for the IGTK being installed, to allow a STA to iden- tify replayed protected group addressed robust Management frames. The Key Length field is the length of IGTK in octets, not including any padding (see 13.8.5). The Wrapped Key field contains the wrapped IGTK being distributed. The length of the resulting AES-Key- wrapped IGTK in the Wrapped Key field is Key Length + 8 octets. 935 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.49 Timeout Interval element (TIE) The TIE specifies time intervals and timeouts. Figure 9-321 shows this element. Element ID Length Timeout Interval Type Timeout Interval Value Octets: 1 1 1 4 Figure 9-321â€”TIE format The Element ID and Length fields are defined in 9.4.2.1. The Timeout Interval Type field is defined in Table 9-160. Table 9-160â€”Timeout Interval Type field value Timeout Interval Type Meaning Units 0 Reserved 1 Reassociation deadline interval Time units (TUs) 2 Key lifetime interval Seconds 3 Association Comeback time Time units (TUs) 4 Time-to-Start (see 11.33.2.1) Time units (TUs) 5â€“255 Reserved The Timeout Interval Value field contains an unsigned 32-bit integer. It is encoded according to the conventions in 9.2.2. A reassociation deadline interval value of 0 indicates no deadline exists. A key lifetime interval value of 0 is reserved. 9.4.2.50 RIC Data element (RDE) The RIC refers to a collection of elements that are used to express a resource request and to convey responses to the corresponding requests. A RIC is a sequence of one or more Resource Requests, or a sequence of one or more Resource Responses. Each Resource Request or Response consists of an RDE, followed by one or more elements that describe that resource. See 13.11 for examples and procedures. The RDE format is shown in Figure 9-322. Resource Descriptor Element ID Length RDE Identifier Count Status Code Octets: 1 1 1 1 2 Figure 9-322â€”RDE format The Element ID and Length fields are defined in 9.4.2.1. 936 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The RDE Identifier field has an arbitrary 8-bit value, chosen by the resource requester to uniquely identify the RDE within the RIC. The Resource Descriptor Count field indicates the number of alternative Resource Descriptors that follow this RDE. The Status Code field is used in Resource Responses to indicate the result of the request. Valid values for the Status Code field are given in 9.4.1.9. When an RDE is included in a Resource Request, the Status Code field is reserved. 9.4.2.51 RIC Descriptor element The RIC Descriptor element is used with an RDE during a fast BSS transition to negotiate resources that are not otherwise described by elements. See 13.11 for procedures for including this element in a RIC. Figure 9-323 shows the format of this element. Element ID Length Resource Type Variable parameters Octets: 1 1 1 variable Figure 9-323â€”RIC Descriptor element format The Element ID and Length fields are defined in 9.4.2.1. The Resource Type field is defined in Table 9-161. Table 9-161â€”Resource type code in RIC Descriptor element Resource type Meaning Variable parameters value 1 Block Ack Block Ack Parameter Set field value as defined in 9.4.1.14, Block Ack Timeout field value as defined in 9.4.1.15, and Block Ack Starting Sequence Control subfield value as defined in 9.3.1.8. 0, 2â€“255 Reserved Variable parameters contain any additional data based on the resource type. 9.4.2.52 DSE Registered Location element A DSE Registered Location element includes DSE location configuration information (LCI), which contains latitude, longitude, and altitude information. The DSE Registered Location element format is shown in Figure 9-324. Element ID Length DSE Registered Location Information Octets: 1 1 20 Figure 9-324â€”DSE Registered Location element format 937 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Element ID and Length fields are defined in 9.4.2.1. The structure and information fields are based on the LCI format described in IETF RFC 6225. The DSE Registered Location Information field is shown in Figure 9-325. B0 B5 B6 B39 B40 B45 B46 B79 B80 B83 B84 B89 B90 B119 B120 B122 Latitude Latitude Longitude Longitude Altitude Altitude Altitude Datum Uncertainty Uncertainty Type Uncertainty Bits: 6 34 6 34 4 6 30 3 B123 B124 B125 B126 B127 B128 B143 B144 B151 B152 B159 Dependent RegLoc RegLoc DSE Dependent Version Enablement Operating Channel Agreement STA Class Number Identifier Bits: 1 1 1 2 16 8 8 Figure 9-325â€”DSE Registered Location Information field format The fields within the DSE Registered Location Information field are defined in Section 2.2 of IETF RFC 6225 (July 2011) except as defined in this standard. With an Altitude Type field value of 3 (i.e., height above ground is in meters), the altitude is defined to be in meters and is formatted in 2s complement, fixed-point, 22-bit integer part with 8-bit fraction. The Datum field is a 3-bit field defined in IETF RFC 6225, and the codes used are as defined in IETF RFC 6225. The RegLoc Agreement bit field is set to 1 to report that the STA is operating within a national policy area or an international agreement area near a national border (see 11.12.3); otherwise, it is 0. The RegLoc DSE bit field is set to 1 to report that the enabling STA is enabling the operation of STAs with DSE; otherwise, it is 0. The Dependent STA bit field is set to 1 to report that the STA is operating with the enablement of the enabling STA whose LCI is being reported; otherwise, it is 0. The Version field is a 2-bit field defined in IETF RFC 6225, and the use is described in IETF RFC 6225. The Dependent Enablement Identifier field is a 16-bit field with a value set by the enabling STA via the DSE Enablement frame; otherwise, it is set to 0. The Operating Class field indicates the channel set for which the enablement request, report, or announcement applies. The Operating Class and Channel Number fields together specify the channel frequency and channel bandwidth for which the report applies. Valid values for the Operating Class field are shown in Annex E. The Channel Number field indicates the channel number for which the enablement request, report, or announcement applies. The channel number is defined within an operating class as shown in Annex E. 938 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.53 Extended Channel Switch Announcement element The Extended Channel Switch Announcement element is used by an AP, IBSS STA, or mesh STA to advertise when the BSS is changing to a new channel or a new channel in a new operating class. The announcement includes both the operating class and the channel number of the new channel. The element is present only when an extended channel switch is pending. The format of the Extended Channel Switch Announcement element is shown in Figure 9-326. Element ID Length Channel New Operating New Channel Channel Switch Mode Class Number Switch Count Octets: 1 1 1 1 1 1 Figure 9-326â€”Extended Channel Switch Announcement element format The Element ID and Length fields are defined in 9.4.2.1. The Channel Switch Mode field indicates any restrictions on transmission until a channel switch. An AP or an IBSS STA sets the Channel Switch Mode field to either 0 or 1 on transmission as specified in 11.9.8.2 and 11.9.8.3. The Channel Switch Mode field is reserved in an MBSS. The New Operating Class field is set to the number of the operating class after the channel switch, as defined in Annex E. The New Channel Number field is set to the number of the channel after the channel switch. The channel number is a channel from the STAâ€™s new operating class as defined in Annex E. For nonmesh STAs, the Channel Switch Count field indicates either the number of target beacon transmission times (TBTTs) until the STA sending the Channel Switch Count field switches to the new channel or a value of 0. A value of 1 indicates that the switch occurs immediately before the next TBTT. A value of 0 indicates that the switch occurs any time after the frame containing the Channel Switch Count field is transmitted. For mesh STAs, the Channel Switch Count field is encoded as an octet with bits 6 to 0 set to the time, in units of 2 TU when the MSB (bit 7) is 0, or in units of 100 TU when the MSB (bit 7) is 1, until the mesh STA sending the Channel Switch Count field switches to the new channel. A value of 0 for bits 6 to 0 indicates that the switch occurs at any time after the frame containing the Channel Switch Count field is transmitted. For example, a 200 TU channel switch time is encoded as X'82' and a 10 TU channel switch time is encoded as X'05'. 9.4.2.54 Supported Operating Classes element The Supported Operating Classes element is used by a STA to advertise the operating classes that it is capable of operating with in this country. The format of the Supported Operating Classes element is shown in Figure 9-327. Current Operating Operating Class Element ID Length Current Operating Operating Class Extension Duple Sequence Class Classes Sequence (optional) (optional) Octets: 1 1 1 variable variable variable Figure 9-327â€”Supported Operating Classes element format 939 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Element ID and Length fields are defined in 9.4.2.1. The Current Operating Class field, concatenated with the Current Operating Class Extension field within the Current Operating Class Extension Sequence field if present, indicates the operating class in use for transmission and reception. If the operating class in use is a single octet, the Current Operating Class Extension Sequence field is not present. If the operating class in use is more than a single octet, then the Current Operating Class Extension Sequence field is present, and the concatenation of the Current Operating Class field with the Current Operating Class Extension Sequence field comprises N (where N 0) Operating Class octets with an 80+ behavior limit followed by one Operating Class octet without an 80+ behavior limit (as defined in Annex E). The Operating Classes field lists, in descending order or preference, all single-octet operating classes that the STA is capable of operating with in this country. The Operating Classes field terminates immediately before a OneHundredAndThirty Delimiter (see Figure 9-328), a Zero Delimiter (see Figure 9-329), or the end of the element. The format of the optional Current Operating Class Extension Sequence field is shown in Figure 9-328. one or more entries Current Operating OneHundredAndThirty Delimiter Class Extension Octets: 1 variable Figure 9-328â€”Current Operating Class Extension Sequence field format The OneHundredAndThirty Delimiter field is set to 130. The Current Operating Class Extension field comprises N (where N 0) Operating Class octets with an 80+ behavior limit followed by one Operating Class octet without an 80+ behavior limit (as defined in Annex E). The format of the Operating Class Duple Sequence field is shown in Figure 9-329. one or more entries Operating Class Zero Delimiter Duple List Octets: 1 2n Figure 9-329â€”Operating Class Duple Sequence field format The Zero Delimiter is set to 0. The Operating Class Duple List subfield lists all two-octet operating classes that the STA is capable of operating with in this country. Each operating class in the Operating Class Duple List subfield contains an Operating Class octet with an 80+ behavior limit followed by one Operating Class octet without an 80+ behavior limit (as defined in Annex E). Operating classes are transmitted in ascending order using the first octet in the operating class as the primary sort key and then the second octet in the operating class as the secondary sort key. If there are no two-octet operating classes that the STA is capable of operating with in this country, then the Operating Class Duple Sequence field is omitted from the Supported Operating Classes element. The Operating Class Duple List subfield terminates immediately before another zero octet or the end of the element. 940 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The use of this element is described in 11.10.2 and 11.11.9.1. 9.4.2.55 Management MIC element The Management MIC element (MME) provides message integrity and protects group addressed robust Management frames from forgery and replay. Figure 9-330 shows the MME format. Element ID Length Key ID IPN MIC Octets: 1 1 2 6 8 or 16 Figure 9-330â€”Management MIC element format The Element ID and Length fields are defined in 9.4.2.1. The Key ID field identifies the IGTK used to compute the MIC. Bits 0â€“11 define a value in the range 0â€“ 4095. Bits 12â€“15 are reserved. The IGTK Key ID is either 4 or 5. The remaining Key IDs are reserved. The IPN field contains a 6 octet value, interpreted as a 48-bit unsigned integer and used to detect replay of protected group addressed robust Management frames. The MIC field contains a message integrity code calculated over the robust Management frame as specified in 12.5.4.5 and 12.5.4.6. The length of the MIC field depends on the specific cipher negotiated and is either 8 octets (for BIP-CMAC-128) or 16 octets (for BIP-CMAC-256, BIP-GMAC-128, and BIP-GMAC-256). 9.4.2.56 HT Capabilities element 9.4.2.56.1 HT Capabilities element structure An HT STA declares that it is an HT STA by transmitting the HT Capabilities element. The HT Capabilities element contains a number of fields that are used to advertise optional HT capabilities of an HT STA. The HT Capabilities element is present in Beacon, Association Request, Association Response, Reassociation Request, Reassociation Response, Probe Request, Probe Response, Mesh Peering Open, and Mesh Peering Close frames. The HT Capabilities element is defined in Figure 9-331. Element HT A-MPDU Supported HT Extended Transmit ASEL Length Capability Beamforming ID Information Parameters MCS Set Capabilities Capabilities Capabilities Octets: 1 1 2 1 16 2 4 1 Figure 9-331â€”HT Capabilities element format The Element ID and Length fields are defined in 9.4.2.1. 9.4.2.56.2 HT Capability Information field The HT Capability Information field of the HT Capabilities element is 2 octets in length, and contains capability information bits. The structure of this field is defined in Figure 9-332. 941 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 LDPC Supported SM HT- Short GI for Short GI for Tx Rx Coding Channel Power Greenfield 20 MHz 40 MHz STBC STBC Capability Width Set Save Bits: 1 1 2 1 1 1 1 2 B10 B11 B12 B13 B14 B15 L-SIG TXOP HT-delayed Maximum DSSS/CCK Forty MHz Block Ack A-MSDU Length Mode in 40 MHz Reserved Intolerant Protection Support 1 1 1 1 1 1 Figure 9-332â€”HT Capability Information field The subfields of the HT Capability Information field are defined in Table 9-162. Table 9-162â€”Subfields of the HT Capability Information field Subfield Definition Encoding LDPC Indicates support for Set to 0 if not supported Coding receiving LDPC coded Set to 1 if supported Capability packets Supported Indicates the channel Set to 0 if only 20 MHz operation is supported Channel widths supported by the Set to 1 if both 20 MHz and 40 MHz operation is supported Width Set STA. See 11.16. This field is reserved when the transmitting or receiving STA is operating in an operating class that includes 20 in the Channel spacing (MHz) column of the appropriate table in Annex E. SM Power Indicates the spatial Set to 0 for static SM power save mode Save multiplexing power save Set to 1 for dynamic SM power save mode mode that is in operation Set to 3 for SM power save disabled or not supported immediately after (re)association. The value 2 is reserved See 11.2.6. Only valid in a (Re)Association Request frame sent to an AP. Otherwise this subfield is set to 0 or 3 upon transmission and is ignored upon reception. NOTEâ€”This subfield indicates the operational state immediately after (re)association as well as (if not set to 3) a capability. HT- Indicates support for the Set to 0 if not supported Greenfield reception of PPDUs with Set to 1 if supported HT-greenfield format. See 19.1.4. Short GI for Indicates short GI support Set to 0 if not supported 20 MHz for the reception of packets Set to 1 if supported transmitted with TXVECTOR parameter CH_BANDWIDTH equal to HT_CBW20 942 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-162â€”Subfields of the HT Capability Information field (continued) Subfield Definition Encoding Short GI for Indicates short GI support Set to 0 if not supported 40 MHz for the reception of packets Set to 1 if supported transmitted with TXVECTOR parameter CH_BANDWIDTH equal to HT_CBW40 Tx STBC Indicates support for the Set to 0 if not supported transmission of PPDUs Set to 1 if supported using STBC Rx STBC Indicates support for the Set to 0 for no support reception of PPDUs using Set to 1 for support of one spatial stream STBC Set to 2 for support of one and two spatial streams Set to 3 for support of one, two and three spatial streams HT-delayed Indicates support for HT- Set to 0 if not supported Block Ack delayed block ack Set to 1 if supported operation. See 10.24.8. Support indicates that the STA is able to accept an ADDBA request for HT-delayed Block Ack Maximum Indicates maximum Set to 0 for 3839 octets A-MSDU A-MSDU length. Set to 1 for 7935 octets Length See 10.12. DSSS/CCK Indicates use of DSSS/CCK In Beacon and Probe Response frames: Mode in mode in a 20/40 MHz BSS. Set to 0 if the BSS does not allow use of DSSS/CCK in 40 MHz 40 MHz See 11.16. Set to 1 if the BSS does allow use of DSSS/CCK in 40 MHz Otherwise: Set to 0 if the STA does not use DSSS/CCK in 40 MHz Set to 1 if the STA uses DSSS/CCK in 40 MHz See 11.16.8 for operating rules Forty MHz Indicates whether APs Set to 1 by an HT STA to prohibit a receiving AP from operating that Intolerant receiving this information APâ€™s BSS as a 20/40 MHz BSS; otherwise, set to 0. or reports of this information are required to prohibit 40 MHz transmissions (see 11.16.12). L-SIG Indicates support for the L- Set to 0 if not supported TXOP SIG TXOP protection Set to 1 if supported Protection mechanism (see 10.26.5) Support The following subfields are reserved for a mesh STA: Tx STBC, Rx STBC. 9.4.2.56.3 A-MPDU Parameters field The structure of the A-MPDU Parameters field of the HT Capabilities element is shown in Figure 9-333. 943 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B0 B1 B2 B4 B5 B7 Maximum A-MPDU Minimum MPDU Length Exponent Start Spacing Reserved Bits: 2 3 3 Figure 9-333â€”A-MPDU Parameters field The subfields of the A-MPDU Parameters field are defined in Table 9-163. Table 9-163â€”Subfields of the A-MPDU Parameters field Subfield Definition Encoding Maximum Indicates the maximum length of A-MPDU This field is an integer in the range 0 to 3. A-MPDU that the STA can receive. Length The length defined by this field is equal to Exponent 13 + Maximum A-MPDU Length Exponent 2 â€“ 1 octets. Minimum Determines the minimum time between the Set to 0 for no restriction MPDU Start start of adjacent MPDUs within an Set to 1 for 1/4 s Spacing A-MPDU that the STA can receive, Set to 2 for 1/2 s measured at the PHY SAP. Set to 3 for 1 s See 10.13.3. Set to 4 for 2 s Set to 5 for 4 s Set to 6 for 8 s Set to 7 for 16 s 9.4.2.56.4 Supported MCS Set field The Supported MCS Set field of the HT Capabilities element indicates which HT MCSs a STA supports. An MCS is identified by an MCS index, which is represented by an integer in the range 0 to 76. The interpretation of the MCS index (i.e., the mapping from MCS to data rate) is PHY dependent. For the HT PHY, see 19.5. The structure of the MCS Set field is defined in Figure 9-334. B0 B76 B77 B79 B80 B89 B90 B95 Rx MCS Bitmask Reserved Rx Highest Supported Data Rate Reserved Bits: 77 3 10 6 B96 B97 B98 B99 B100 B101 B127 Tx MCS Set Tx Rx MCS Set Tx Maximum Number Tx Unequal Spatial Streams Modulation Reserved Defined Not Equal Supported Supported Bits: 1 1 2 1 27 Figure 9-334â€”Supported MCS Set field 944 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Rx MCS Bitmask subfield of the Supported MCS Set field defines a set of MCS index values, where bit B0 corresponds to MCS 0 and bit B76 corresponds to MCS 76. NOTEâ€”An HT STA includes the mandatory MCS values defined in 19.1 in the Rx MCS Bitmask subfield. The Rx Highest Supported Data Rate subfield of the Supported MCS Set field defines the highest HT PPDU data rate that the STA is able to receive, in units of 1 Mb/s in the range 1 to 1023. If the maximum data rate expressed in Mb/s is not an integer, then the value is rounded down to the next integer. The value 0 indicates that this subfield does not specify the HT PPDU highest data rate that the STA is able to receive; see 10.7.6.5.3. The Tx MCS Set Defined, Tx Rx MCS Set Not Equal, Tx Maximum Number Spatial Streams Supported, and Tx Unequal Modulation Supported subfields of the Supported MCS Set field indicate the transmit- supported MCS set, as defined in Table 9-164. Table 9-164â€”Transmit MCS Set Tx MCS Tx Rx Tx Maximum Number Tx Unequal Modulation Condition Set MCS Set Spatial Streams Supported Supported Defined Not Equal No Tx MCS set 0 0 0 0 is defined The Tx MCS set 1 0 0 0 is defined and is equal to the Rx MCS set The Tx MCS set 1 1 Indicates the maximum number Indicates whether transmit is defined and is of spatial streams supported unequal modulation (UEQM) not necessarily when transmitting: is supported: equal to the Rx Set to 0 for 1 spatial stream Set to 0 for UEQM not MCS set Set to 1 for 2 spatial streams supported Set to 2 for 3 spatial streams Set to 1 for UEQM supported Set to 3 for 4 spatial streams 9.4.2.56.5 HT Extended Capabilities field The structure of the HT Extended Capabilities field of the HT Capabilities element is defined in Figure 9-335. B0 B1 B2 B3 B7 B8 B9 B10 B11 B12 B15 PCO MCS +HTC-HT RD PCO Transition Time Reserved Feedback Support Responder Reserved Bits: 1 2 5 2 1 1 4 Figure 9-335â€”HT Extended Capabilities field 945 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The subfields of the HT Extended Capabilities field are defined in Table 9-165. Table 9-165â€”Subfields of the HT Extended Capabilities field Subfield Definition Encoding PCO Indicates support for PCO. Set to 0 if not supported Set to 1 if supported When transmitted by an AP: indicates whether the AP can operate its BSS as a PCO BSS. When transmitted by a non-AP STA: indicates whether the STA can operate as a PCO active STA when the Transition Time subfield in its HT Extended Capabilities field meets the intended transition time of the PCO capable AP. The PCO mechanism is obsolete. Consequently, this subfield might be reserved in a later revision of this standard. PCO When transmitted by a non-AP STA: If the PCO subfield is equal to 0, this field is Transition indicates that the STA can switch between 20 reserved. Time MHz channel width and 40 MHz channel width within the specified time. Otherwise: Set to 1 for 400 Âµs When transmitted by an AP: indicates the Set to 2 for 1.5 ms PCO Transition Time to be used during PCO Set to 3 for 5 ms operation. The value contained in this field is dynamic when transmitted by an AP, i.e., the Set to 0 for no transition. In this case, the PCO value of this field might change at any time active STA does not change its operating during the lifetime of the association of a channel width and is able to receive 40 MHz STA with the AP. See 11.17.3. PPDUs during the 20 MHz phase (see 11.17). MCS Indicates whether the STA can provide MFB Set to 0 (No Feedback) if the STA does not Feedback provide MFB Set to 2 (Unsolicited) if the STA provides only unsolicited MFB Set to 3 (Both) if the STA can provide MFB in response to MRQ (either Delayed or Immediate, see 10.31.1) as well as unsolicited MFB The value 1 is reserved +HTC-HT Indicates support of the HT variant HT Set to 0 if not supported Support Control field. Set to 1 if supported See 10.9 RD Indicates support for acting as a reverse Set to 0 if not supported Responder direction responder, i.e., the STA might use Set to 1 if supported an offered RDG to transmit data to an RD initiator using the reverse direction protocol described in 10.28. The following subfield is reserved for a mesh STA: PCO. 946 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.56.6 Transmit Beamforming Capabilities The structure of the Transmit Beamforming Capabilities field is defined in Figure 9-336. B0 B1 B2 B3 B4 B5 B6 B7 B8 Implicit Transmit Receive Transmit Receive Transmit Implicit Explicit CSI Staggered Staggered Transmit Transmit Beamforming Sounding Sounding NDP NDP Beamforming Calibration Beamforming Receiving Capable Capable Capable Capable Capable Capable Capable Bits: 1 1 1 1 1 1 2 1 B9 B10 B11 B12 B13 B14 B15 B16 B17 B18 B19 B20 Explicit Explicit Explicit CSI Number of Explicit Explicit Transmit Noncompressed Compressed Minimal Beamformer Noncompressed Compressed Beamforming Beamforming Steering Capable Steering Capable Beamforming Feedback Feedback Grouping Antennas CSI Feedback Supported Capable Capable 1 1 2 2 2 2 2 B21 B22 B23 B24 B25 B26 B27 B28 B29 B31 Noncompressed Steering Compressed Steering CSI Max Number of Channel Number of Beamformer Number of Beamformer Rows Beamformer Estimation Reserved Antennas Supported Antennas Supported Supported Capability 2 2 2 2 3 Figure 9-336â€”Transmit Beamforming Capabilities field The subfields of the Transmit Beamforming Capabilities field are defined in Table 9-166. Table 9-166â€”Subfields of the Transmit Beamforming Capabilities field Subfield Definition Encoding Implicit Transmit Indicates whether this STA can receive Set to 0 if not supported Beamforming Transmit Beamforming steered frames Set to 1 if supported Receiving Capable using implicit feedback Receive Staggered Indicates whether this STA can receive Set to 0 if not supported Sounding Capable staggered sounding frames. Set to 1 if supported Transmit Staggered Indicates whether this STA can transmit Set to 0 if not supported Sounding Capable staggered sounding frames. Set to 1 if supported Receive NDP Indicates whether this receiver can Set to 0 if not supported Capable interpret null data packets as sounding Set to 1 if supported frames. Transmit NDP Indicates whether this STA can transmit Set to 0 if not supported Capable null data packets as sounding frames. Set to 1 if supported Implicit Transmit Indicates whether this STA can apply Set to 0 if not supported Beamforming implicit transmit beamforming. Set to 1 if supported Capable 947 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-166â€”Subfields of the Transmit Beamforming Capabilities field (continued) Subfield Definition Encoding Calibration Indicates whether the STA can participate Set to 0 if not supported in a calibration procedure initiated by another STA that is capable of generating Set to 1 if the STA can respond to a calibration an immediate response sounding PPDU request using the CSI report, but cannot and can provide a CSI report in response initiate calibration to the receipt of a sounding PPDU. The value 2 is reserved Set to 3 if the STA can both initiate and respond to a calibration request Explicit CSI Indicates whether this STA can apply Set to 0 if not supported Transmit transmit beamforming using CSI explicit Set to 1 if supported Beamforming feedback in its transmission Capable Explicit Indicates whether this STA can apply Set to 0 if not supported Noncompressed transmit beamforming using Set to 1 if supported Steering Capable noncompressed beamforming feedback matrix explicit feedback in its transmission Explicit Compressed Indicates whether this STA can apply Set to 0 if not supported Steering Capable transmit beamforming using compressed Set to 1 if supported beamforming feedback matrix explicit feedback in its transmission Explicit Transmit Indicates whether this receiver can return Set to 0 if not supported Beamforming CSI CSI explicit feedback. Set to 1 for delayed feedback Feedback Set to 2 for immediate feedback Set to 3 for delayed and immediate feedback Explicit Indicates whether this receiver can return Set to 0 if not supported Noncompressed noncompressed beamforming feedback Set to 1 for delayed feedback Beamforming matrix explicit feedback. Set to 2 for immediate feedback Feedback Capable Set to 3 for delayed and immediate feedback Explicit Compressed Indicates whether this receiver can return Set to 0 if not supported Beamforming compressed beamforming feedback matrix Set to 1 for delayed feedback Feedback Capable explicit feedback. Set to 2 for immediate feedback Set to 3 for delayed and immediate feedback Minimal Grouping Indicates the minimal grouping used for Set to 0 if the STA supports groups of 1 explicit feedback reports (no grouping) Set to 1 indicates groups of 1, 2 Set to 2 indicates groups of 1, 4 Set to 3 indicates groups of 1, 2, 4 CSI Number of Indicates the maximum number of Set to 0 for single Tx antenna sounding Beamformer beamformer antennas the HT beamformee Set to 1 for 2 Tx antenna sounding Antennas Supported can support when CSI feedback is Set to 2 for 3 Tx antenna sounding required Set to 3 for 4 Tx antenna sounding Noncompressed Indicates the maximum number of Set to 0 for single Tx antenna sounding Steering Number of beamformer antennas the HT beamformee Set to 1 for 2 Tx antenna sounding Beamformer can support when noncompressed Set to 2 for 3 Tx antenna sounding Antennas Supported beamforming feedback matrix is required Set to 3 for 4 Tx antenna sounding 948 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-166â€”Subfields of the Transmit Beamforming Capabilities field (continued) Subfield Definition Encoding Compressed Indicates the maximum number of Set to 0 for single Tx antenna sounding Steering Number of beamformer antennas the HT beamformee Set to 1 for 2 Tx antenna sounding Beamformer can support when compressed Set to 2 for 3 Tx antenna sounding Antennas Supported beamforming feedback matrix is required Set to 3 for 4 Tx antenna sounding CSI Max Number of Indicates the maximum number of rows of Set to 0 for a single row of CSI Rows Beamformer CSI explicit feedback from the HT Set to 1 for 2 rows of CSI Supported beamformee or calibration responder or Set to 2 for 3 rows of CSI transmit ASEL responder that an HT Set to 3 for 4 rows of CSI beamformer or calibration initiator or transmit ASEL initiator can support when CSI feedback is required. Channel Estimation Indicates the maximum number of space- Set 0 for 1 space-time stream Capability time streams (columns of the MIMO Set 1 for 2 space-time streams channel matrix) for which channel Set 2 for 3 space-time streams dimensions can be simultaneously Set 3 for 4 space-time streams estimated when receiving an NDP sounding PPDU or the extension portion of the HT Long Training fields (HT-LTFs) in a staggered sounding PPDU. See NOTE. NOTEâ€”The maximum number of space-time streams for which channel coefficients can be simultaneously estimated using the HT-LTFs corresponding to the data portion of the packet is limited by the Rx MCS Bitmask subfield of the Supported MCS Set field and by the Rx STBC subfield of the HT Capability Information field. Both fields are part of the HT Capabilities element. 9.4.2.56.7 ASEL Capability field The structure of the ASEL Capability field of the HT Capabilities element is defined in Figure 9-337. B0 B1 B2 B3 B4 B5 B6 B7 Explicit CSI Antenna Indices Explicit Antenna Feedback Feedback CSI Antenna Receive Transmit Based Indices Sounding Selection Transmit Based Feed- Feedback ASEL PPDUs Reserved Capable Transmit back Capable ASEL ASEL Capable Capable Capable Capable Capable Bits: 1 1 1 1 1 1 1 1 Figure 9-337â€”ASEL Capability field 949 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The subfields of the ASEL Capability field are defined in Table 9-167. Table 9-167â€”ASEL Capability field subfields Subfield Definition Encoding Antenna Selection Indicates whether this STA supports ASEL Set to 0 if not supported Capable Set to 1 if supported Explicit CSI Feedback Indicates whether this STA supports transmit ASEL Set to 0 if not supported Based Transmit ASEL based on explicit CSI feedback Set to 1 if supported Capable Antenna Indices Feedback Indicates whether this STA supports transmit ASEL Set to 0 if not supported Based Transmit ASEL based on antenna indices feedback Set to 1 if supported Capable Explicit CSI Feedback Indicates whether this STA can compute CSI and Set to 0 if not supported Capable provide CSI feedback in support of ASEL Set to 1 if supported Antenna Indices Feedback Indicates whether this STA can compute an antenna Set to 0 if not supported Capable indices selection and return an antenna indices Set to 1 if supported selection in support of ASEL Receive ASEL Capable Indicates whether this STA supports receive ASEL Set to 0 if not supported Set to 1 if supported Transmit Sounding Indicates whether this STA can transmit sounding Set to 0 if not supported PPDUs Capable PPDUs for ASEL training on request Set to 1 if supported 9.4.2.57 HT Operation element The operation of HT STAs in the BSS is controlled by the HT Operation element. The structure of this element is defined in Figure 9-338. HT Element Length Primary Operation Basic HT- ID Channel MCS Set Information Octets: 1 1 1 5 16 Figure 9-338â€”HT Operation element format The Element ID and Length fields are defined in 9.4.2.1. 950 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The structure of the HT Operation Information field is shown in Figure 9-339. B0 B1 B2 B3 B4 B7 Secondary Channel Offset STA Channel Width RIFS Mode Reserved Bits: 2 1 1 4 B8 B9 B10 B11 B12 B13 B20 B21 B23 HT Protection Nongreenfield HT Reserved OBSS Non-HT Channel Center Reserved STAs Present STAs Present Frequency Segment 2 2 1 1 1 11 2 B24 B29 B30 B31 B32 B33 B34 B35 B36 B39 Dual CTS STBC L-SIG TXOP Protection Reserved Dual Beacon PCO Active PCO Phase Reserved Protection Beacon Full Support 6 1 1 1 1 1 1 4 Figure 9-339â€”HT Operation Information field The Primary Channel field, subfields of the HT Operation Information field, and the Basic HT-MCS Set field are defined in Table 9-168. The â€œReserved in IBSS?â€ column indicates whether each field is reserved (Y) or not reserved (N) when this element is present in a frame transmitted within an IBSS. The â€œReserved in MBSS?â€ column indicates whether each field is reserved (Y) or not reserved (N) when this element is present in a frame transmitted within an MBSS. Table 9-168â€”HT Operation element fields and subfields Reserved Reserved Field Definition Encoding in IBSS? in MBSS? Primary Channel Indicates the channel number Channel number of the primary channel N N of the primary channel. See 11.16.2. Secondary Indicates the offset of the Set to 1 (SCA) if the secondary channel is N N Channel Offset secondary channel relative to above the primary channel the primary channel. Set to 3 (SCB) if the secondary channel is below the primary channel Set to 0 (SCN) if no secondary channel is present The value 2 is reserved STA Channel Defines the channel widths Set to 0 for a 20 MHz channel width N N Width that can be used to transmit to Set to 1 allows use of any channel width in the the STA. Supported channel width set See 11.16.12 This field is reserved when the transmitting or receiving STA is operating in an operating class that does not include a value of PrimaryChannelLowerBehavior or PrimaryChannelUpperBehavior in the behavior limits set as specified in Annex E. See NOTE 1. 951 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-168â€”HT Operation element fields and subfields (continued) Reserved Reserved Field Definition Encoding in IBSS? in MBSS? RIFS Mode Indicates whether the use of Set to 0 if use of RIFS is prohibited Y Y reduced interframe space is Set to 1 if use of RIFS is permitted permitted within the BSS. See 10.3.2.3.2 and 10.26.3.3 HT Protection Indicates protection Set to 0 for no protection mode Y N requirements of HT Set to 1 for nonmember protection mode transmissions. Set to 2 for 20 MHz protection mode See 10.26.3. Set to 3 for non-HT mixed mode Nongreenfield AP indicates if any HT STAs Set to 0 if all HT STAs that are associated are Y N HT STAs that are not HT-greenfield HT-greenfield capable or all HT peer mesh Present capable have associated. STAs are HT-greenfield capable Mesh STA indicates if it Set to 1 if one or more HT STAs that are not establishes a mesh peering HT-greenfield capable are associated or one or with an HT STA that is not more HT peer mesh STAs are not HT-greenfield HT-greenfield capable. capable Determines when a non-AP STA should use HT- greenfield protection. Present in Beacon and Probe Response frames transmitted by an AP or mesh STA. Otherwise reserved. See 10.26.3.1. OBSS Non-HT Indicates if the use of If not operating in an operating class for which Y Y STAs Present protection for non-HT STAs the behavior limits set listed in Annex E by overlapping BSSs is includes the value DFS_50_100_Behavior: determined to be desirable. Set to 1 if the use of protection for non-HT If the BSS is operating in an STAs by OBSSs is determined to be desirable. operating class for which the See NOTE 2. behavior limits set listed in Annex E includes the Set to 0 otherwise. DFS_50_100_Behavior, this field indicates if there exist any non-HT OBSSs and If operating in an operating class for which the whether HT-greenfield behavior limits set listed in Annex E includes transmissions are allowed. the value DFS_50_100_Behavior: Present in Beacon and Probe Set to 1 if there exists one or more non-HT Response frames transmitted OBSSs. Indicates that HT-greenfield by an AP. Otherwise transmissions are disallowed in the BSS. reserved. See 10.26.3.4 and 11.9.8.5. Set to 0 otherwise. Channel Center Defines the channel center For a STA with dot11VHTExtendedNSSBW- N N Frequency frequency for a 160 or 80+80 Capable equal to true: See Table 9-250, other- Segment 2 MHz BSS bandwidth with wise this field is set to 0. NSS support less than Max VHT NSS. NOTEâ€”This subfield is not used in a non-VHT See 21.3.14 and 9.4.2.158.3. HT STA. 952 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-168â€”HT Operation element fields and subfields (continued) Reserved Reserved Field Definition Encoding in IBSS? in MBSS? Dual Beacon Indicates whether the AP Set to 0 if no STBC beacon is transmitted Y Y transmits an STBC beacon. Set to 1 if an STBC beacon is transmitted by the AP The use of the dual beacon mechanism is deprecated. Dual CTS Dual CTS protection is used Set to 0 if dual CTS protection is not required Y Y Protection by the AP to set a NAV at Set to 1 if dual CTS protection is required STAs that do not support STBC and at STAs that can associate solely through the STBC beacon. See 10.3.2.8. The use of the dual CTS mechanism is deprecated. STBC Beacon Indicates whether the beacon Set to 0 in a primary beacon Y Y containing this element is a Set to 1 in an STBC beacon primary or an STBC beacon. The STBC beacon has half a beacon period shift relative to the primary beacon. Defined only in a Beacon frame transmitted by an AP. Otherwise reserved. See 11.1.3.2. L-SIG TXOP Indicates whether all HT STA Set to 0 if one or more HT STA in the BSS do Y Y Protection Full in the BSS support L-SIG not support L-SIG TXOP protection Support TXOP protection. Set to 1 if all HT STA in the BSS support L-SIG See 10.26.5. TXOP protection PCO Active Indicates whether PCO is Set to 0 if PCO is not active in the BSS Y Y active in the BSS Set to 1 if PCO is active in the BSS Present in Beacon/Probe Response frames transmitted by an AP. Otherwise reserved. Non-PCO STAs regard the BSS as a 20/40 MHz BSS and might associate with the BSS without regard to this field. See 11.17. PCO Phase Indicates the PCO phase of Set to 0 indicates switch to or continue 20 MHz Y Y operation phase Defined only in a Beacon and Set to 1 indicates switch to or continue 40 MHz Probe Response frames when phase PCO Active is 1. Otherwise reserved. See 11.17. 953 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-168â€”HT Operation element fields and subfields (continued) Reserved Reserved Field Definition Encoding in IBSS? in MBSS? Basic HT-MCS Indicates the HT MCS values A bitmap where a bit is set to 1 to indicate N N Set that are supported by all HT support for that MCS and 0 otherwise, where STAs in the BSS. bit 0 corresponds to MCS 0. Present in Beacon, Probe Response, Mesh Peering MCS values are defined in 9.4.2.56.4. Open and Mesh Peering Confirm frames. Otherwise reserved. NOTE 1â€”Any change of STA Channel Width field value does not impact the value of the HT Protection field. NOTE 2â€”Examples of when this bit might be set to 1 include, but are not limited to, the following situations: â€” One or more non-HT STAs are associated â€” A non-HT BSS is overlapping (a non-HT BSS might be detected by the reception of a Beacon or Probe Response frame that does not include an HT Capabilities element) 9.4.2.58 20/40 BSS Intolerant Channel Report element The 20/40 BSS Intolerant Channel Report element contains a list of channels on which a STA has found conditions that disallow the use of a 20/40 MHz BSS. The format of the 20/40 BSS Intolerant Channel Report element is shown in Figure 9-340. Element ID Length Operating Class Channel List Octets: 1 1 1 variable Figure 9-340â€”20/40 BSS Intolerant Channel Report element format The Element ID and Length fields are defined in 9.4.2.1. The minimum value of the Length field is 1 (based on a minimum length for the Channel List field of 0 octets). Operating Class field of the 20/40 MHz BSS Intolerant Channel Report element contains an enumerated value from Annex E, encoded as an unsigned integer, specifying the operating class in which the channel list is valid. If the operating class is â€œunknownâ€ as described in 11.16.12, the Operating Class field is set to 0. A 20/40 BSS Intolerant Channel Report only reports channels for a single operating class. Multiple 20/40 BSS Intolerant Channel Report elements are used to report channels in more than one operating class. The Channel List field of the 20/40 MHz BSS Intolerant Channel Report element contains a variable number of octets, where each octet describes a single channel number. Channel numbering is dependent on operating class according to Annex E. A 20/40 BSS Intolerant Channel Report element includes only channels that are valid for the regulatory domain in which the STA transmitting the element is operating and that are consistent with the Country element transmitted by the AP of the BSS of which it is a member. 954 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.59 Overlapping BSS Scan Parameters element The Overlapping BSS Scan Parameters element is used by an AP to indicate the values to be used by BSS members when performing OBSS scan operations. The format of the Overlapping BSS Scan Parameters element is shown in Figure 9-341. BSS OBSS OBSS OBSS OBSS Channel BSS Width Element Scan Scan Width Scan Scan Channel OBSS Scan Length Passive Active Activity ID Passive Active Trigger Total Per Total Per Transition Threshold Dwell Dwell Scan Delay Factor Interval Channel Channel Octets: 1 1 2 2 2 2 2 2 2 Figure 9-341â€”Overlapping BSS Scan Parameters element format The Element ID and Length fields are defined in 9.4.2.1. The OBSS Scan Passive Dwell field contains a value in TUs, encoded as an unsigned integer, that a receiving STA uses to set dot11OBSSScanPassiveDwell as described in 11.16.5. The OBSS Scan Active Dwell field contains a value in TUs, encoded as an unsigned integer, that a receiving STA uses to set dot11OBSSScanActiveDwell as described in 11.16.5. The BSS Channel Width Trigger Scan Interval field contains a value in seconds, encoded as an unsigned integer, that a receiving STA uses to set dot11BSSWidthTriggerScanInterval as described in 11.16.5. The OBSS Scan Passive Total Per Channel field contains a value in TUs, encoded as an unsigned integer, that a receiving STA uses to set dot11OBSSScanPassiveTotalPerChannel as described in 11.16.5. The OBSS Scan Active Total Per Channel field contains a value in TUs, encoded as an unsigned integer, that a receiving STA uses to set dot11OBSSScanActiveTotalPerChannel as described in 11.16.5. The BSS Width Channel Transition Delay Factor field contains an integer value that a receiving STA uses to set dot11BSSWidthChannelTransitionDelayFactor as described in 11.16.5. The OBSS Scan Activity Threshold field contains a value in hundredths of percent, encoded as an unsigned integer, that a receiving STA uses to set dot11OBSSScanActivityThreshold as described in 11.16.5. The use of each of these parameters is described in 11.16.5. 9.4.2.60 20/40 BSS Coexistence element The 20/40 BSS Coexistence element is used by STAs to exchange information that affects 20/40 BSS coexistence. The 20/40 BSS Coexistence element is formatted as shown in Figure 9-342. Element 20/40 BSS Coexistence ID Length Information field Octets: 1 1 1 Figure 9-342â€”20/40 BSS Coexistence element format 955 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Element ID and Length fields are defined in 9.4.2.1. The structure of the 20/40 BSS Coexistence Information field is shown in Figure 9-343. B0 B1 B2 B3 B4 B5 B7 Forty 20 MHz OBSS OBSS Informatio Scanning Scanning n Request MHz BSS Width Exemption Exemption Reserved Intolerant Request Request Grant Bits: 1 1 1 1 1 3 Figure 9-343â€”20/40 BSS Coexistence Information field The Information Request field is used to indicate that a transmitting STA is requesting the recipient to transmit a 20/40 BSS Coexistence Management frame with the transmitting STA as the recipient. The Forty MHz Intolerant field is set to 1 to prohibit an AP that receives this information or reports of this information from operating a 20/40 MHz BSS. When equal to 0, it does not prohibit a receiving AP from operating a 20/40 MHz BSS. This field is used for inter-BSS communication. The definition of this field is the same as the definition of the Forty MHz Intolerant field in the HT Capabilities element (see 9.4.2.56), and its operation is described in 11.16.11. The 20 MHz BSS Width Request field is set to 1 to prohibit a receiving AP from operating its BSS as a 20/40 MHz BSS. Otherwise, it is set to 0. This field is used for intra-BSS communication. The operation of this field is described in 11.16.12. The OBSS Scanning Exemption Request field is set to 1 to indicate that the transmitting non-AP STA is requesting the BSS to allow the STA to be exempt from OBSS scanning. Otherwise, it is set to 0. The OBSS Scanning Exemption Request field is reserved when transmitted by an AP. The OBSS Scanning Exemption Request field is reserved when a 20/40 BSS Coexistence element is included in a group addressed frame. The OBSS Scanning Exemption Grant field is set to 1 by an AP to indicate that the receiving STA is exempted from performing OBSS Scanning. Otherwise, it is set to 0. The OBSS Scanning Exemption Grant field is reserved when transmitted by a non-AP STA. The OBSS Scanning Exemption Grant field is reserved when a 20/40 BSS Coexistence element is included in a group addressed frame. 9.4.2.61 Time Advertisement element The Time Advertisement element, shown in Figure 9-344, specifies fields describing the source of time corresponding to a time standard, an external clock (external time source), an estimate of the offset between that time standard and the TSF timer, and an estimate of the standard deviation of the error in the offset estimate. This information is used by a receiving STA to align its own estimate of the time standard based on that of another STA. Timing Time Value Time Error Time Update Element ID Length Counter Capabilities (optional) (optional) (optional) Octets: 1 1 1 0 or 10 0 or 5 0 or 1 Figure 9-344â€”Time Advertisement element format The Element ID and Length fields are defined in 9.4.2.1. 956 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Timing Capabilities field specifies the STAâ€™s source and encoding of the Time Value field. The encoding of the Timing Capabilities field is specified in Table 9-169. Table 9-169â€”Encoding of the Timing Capabilities field Value Usage 0 No standardized external time source 1 Timestamp offset based on UTC [see ITU-R Recommendation TF.460-4(2002) [B51]]. The Timestamp offset value in nanoseconds is defined to be 0 at the beginning of the first nanosecond of the first day of the year 1958. 2 UTC time at which the TSF timer is 0. 3â€“255 Reserved When the value of the Timing Capabilities field is 0, only the Element ID, Length, and Timing Capabilities fields are included in the Time Advertisement element. When the value of the Timing Capabilities is 1, the following additional fields are included in the Time Advertisement element: â€” Time Value field, a 2s complement integer in nanoseconds that, when added to the Timestamp present in the same transmitted frame, gives the receiving STA an estimate of the time standard at the time the frame was transmitted. The Timestamp is derived from the TSF Timer as defined in 11.22. â€” Time Error field, which is set to an unsigned integer in nanoseconds that defines the standard deviation of the error in the Time Value estimate. The value of all 1s is used to indicate that the error is unknown. When the Timing Capabilities field is 2, the following fields are included in the Time Advertisement element: â€” The Time Value field is the UTC time at which the TSF Timer is 0, given that the TSF Timer units are 1 microsecond units as defined in 11.1.3. The format, including all subfields is shown in Table 9- 170. For any subfield not known in the Time Value field, the subfield value is 0. â€” The Time Error field is an unsigned integer in milliseconds that defines the standard deviation of the error in the Time Value estimate. â€” The Time Update Counter field is a modulo 256 counter that increments each time the AP updates the Time Value UTC at which the TSF Timer is 0. 957 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-170â€”Time Value field format when Timing Capabilities is 2 Octet Description 0â€“1 Year (0â€“65 534) 2 Month (0â€“12) 3 Day of month (0â€“31) 4 Hours (0â€“23) 5 Minutes (0â€“59) 6 Seconds (0â€“59) 7â€“8 Milliseconds (0â€“999) 9 Reserved 9.4.2.62 Link Identifier element The Link Identifier element contains information that identifies a TDLS direct link. The element information format is defined in Figure 9-345. Element TDLS initiator STA TDLS responder STA Length BSSID ID Address Address Octets: 1 1 6 6 6 Figure 9-345â€”Link Identifier element format The Element ID and Length fields are defined in 9.4.2.1. The BSSID field is set to the BSSID of the BSS to which the TDLS initiator STA is associated. The TDLS initiator STA Address field is set to the TDLS initiator STAâ€™s MAC address. The TDLS responder STA Address field is set to the TDLS responder STAâ€™s MAC address. 9.4.2.63 Wakeup Schedule element The Wakeup Schedule element contains information regarding the periodic wakeup schedule for TDLS peer PSM. The element format is defined in Figure 9-346. Maximum Awake Element Length Offset Interval Window Awake Idle ID Window Count Slots Duration Octets: 1 1 4 4 4 4 2 Figure 9-346â€”Wakeup Schedule element format The Element ID and Length fields are defined in 9.4.2.1. 958 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Offset field is the time in microseconds between TSF 0 and the start of a first Awake Window. See 11.2.3.14. The Interval field is set to the time in microseconds between the start of two successive Awake Windows. See 11.2.3.14. The Awake Window Slots field is set to the duration of the Awake Window in units of backoff slots (see 10.22.2.4). See 11.2.3.14. The Maximum Awake Window Duration field is set to the maximum duration of the Awake Window, in units of microseconds. See 11.2.3.14. The Idle Count field is set to the number of consecutive Awake Windows during which no individually addressed frame is received from the TDLS peer STA before a TDLS peer STA deletes the wakeup schedule. See 11.2.3.14. 9.4.2.64 Channel Switch Timing element The Channel Switch Timing element contains information regarding the channel switch timing. The element is defined in Figure 9-347. Element Switch Length SwitchTime ID Timeout Octets: 1 1 2 2 Figure 9-347â€”Channel Switch Timing element format The Element ID and Length fields are defined in 9.4.2.1. The Switch Time field is set to the time it takes for a STA sending the Channel Switch Timing element to switch channels, in units of microseconds. The Switch Timeout field is set to a time in units of microseconds. The STA sending the Channel Switch Timing element waits for the first Data frame exchange on the off-channel for Switch Timeout microseconds before switching back to base channel. The time is measured from the end of the last symbol of the Ack frame that is transmitted in response to TDLS Channel Switch Response frame, as seen on the WM. 9.4.2.65 PTI Control element The PTI Control element contains information regarding the traffic buffered at the TPU buffer STA for the TPU sleep STA at the time a TDLS Peer Traffic Indication frame is transmitted by the TPU buffer STA. The element is optionally included in the TDLS Peer Traffic Indication frame. The element is defined in Figure 9-348. Sequence Element ID Length TID Control Octets: 1 1 1 2 Figure 9-348â€”PTI Control element format 959 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Element ID and Length fields are defined in 9.4.2.1. The TID field contained in the PTI Control element is set to the TID of the latest MPDU that has been transmitted over the TDLS direct link to the TPU sleep STA that is the destination of the TDLS Peer Traffic Indication frame that contains the PTI Control element. See 11.2.3.15. The Sequence Control field is defined in 9.2.4.4. The Sequence Control field contained in the PTI Control element is set to the sequence number of the latest MPDU that has been transmitted over the TDLS direct link to the TPU sleep STA that is the destination of the TDLS Peer Traffic Indication frame that contains the PTI Control element. See 11.2.3.15. 9.4.2.66 TPU Buffer Status element The TPU Buffer Status element contains information regarding the traffic buffered at the TPU buffer STA for the TPU sleep STA at the time a TDLS Peer Traffic Indication frame is transmitted by the TPU buffer STA. The element is included in the TDLS Peer Traffic Indication frame. The element is defined in Figure 9-349. Element ID Length TPU Buffer Status Information Octets: 1 1 1 Figure 9-349â€”TPU Buffer Status element format The Element ID and Length fields are defined in 9.4.2.1. The TPU Buffer Status Information field is defined in Figure 9-350 B0 B1 B2 B3 B4 B7 AC_BK AC_BE AC_VI AC_VO traffic traffic traffic traffic Reserved available available available available Bits: 1 1 1 1 4 Figure 9-350â€”TPU Buffer Status Information field The AC_BK traffic available field is one bit in size and is set to 1 if AC_BK contains traffic buffered for the TPU sleep STA to which the TPU Buffer Status element will be transmitted and is set to 0 otherwise. The AC_BE traffic available field is one bit in size and is set to 1 if AC_BE contains traffic buffered for the TPU sleep STA to which the TPU Buffer Status element will be transmitted and is set to 0 otherwise. The AC_VI traffic available field is one bit in size and is set to 1 if AC_VI contains traffic buffered for the TPU sleep STA to which the TPU Buffer Status element will be transmitted and is set to 0 otherwise. The AC_VO traffic available field is one bit in size and is set to 1 if AC_VO contains traffic buffered for the TPU sleep STA to which the TPU Buffer Status element will be transmitted and is set to 0 otherwise. 960 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.67 Event Request element 9.4.2.67.1 Event Request definition The Event Request element contains a request to the receiving STA to perform the specified event action. The format of the Event Request element is shown in Figure 9-351. Element ID Length Event Token Event Type Event Response Event Request Limit Octets: 1 1 1 1 1 variable Figure 9-351â€”Event Request element format The Element ID and Length fields are defined in 9.4.2.1. The Event Token field is a nonzero number that is unique among the Event Request elements sent to each destination MAC address for which a corresponding Event Report element has not been received. The Event Type field is a number that identifies the type of event request. The values of the Event Type field are defined in Table 9-171. Table 9-171â€”Event Type field definitions for event requests and reports Name Event Type Transition 0 RSNA 1 Peer-to-peer link 2 WNM log 3 Reserved 4â€“220 Vendor Specific 221 Reserved 222â€“255 The Event Response Limit field contains the maximum number of requested Event Reports to be included in the Event Report element. A value of 0 indicates that no limit is set on the number of Event Reports to be included in the Event Report element. The Event Request field contains the event request corresponding to the Event Type, as described in 9.4.2.67.2 to 9.4.2.67.4. The Event Request field is not present when requesting a WNM log report. The Event Request element is included in an Event Request frame, as described in 9.6.14.2. The use of the Event Request element and Event Request frame is described in 11.24.2. 9.4.2.67.2 Transition event request The Event Request field corresponding to the Transition event request contains zero or more Transition Event Request subelements. A transition event is a STA movement or attempted movement from one BSS (the source BSS) in one ESS to another BSS (the target BSS) within the same ESS. 961 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Transition Event subelements specify the conditions in which a Transition Event Report is sent by a STA. The set of valid Transition Event Request subelements is defined in Table 9-172. Table 9-172â€”Transition Event Request subelement Transition Event Request subelement Subelement ID Transition Target BSSID 0 Transition Source BSSID 1 Transition Time Threshold 2 Transition Result 3 Frequent Transition 4 Reserved 5â€“255 The Transition Target BSSID subelement is used to request that a Transition Event Report includes the transition event entry when the target BSSID is equal to the specific BSSID in the Target BSSID field. Excluding this subelement from the Event Request element indicates a request for transition events for all target BSSIDs. The format of the Transition Target BSSID subelement is shown in Figure 9-352. Subelement ID Length Target BSSID Octets: 1 1 6 Figure 9-352â€”Transition Target BSSID subelement format The Subelement ID field is equal to the Transition Target BSSID value in Table 9-172. The Length field is defined in 9.4.3. The Target BSSID field contains a 6-octet BSSID. The Transition Source BSSID subelement is used to request that a Transition Event Report includes the transition event entry when the source BSSID is equal to the BSSID specified in the Source BSSID field. Excluding this subelement from the Event Request element indicates a request for transition events for all source BSSIDs. The format of the Transition Source BSSID subelement is shown in Figure 9-353. Subelement ID Length Source BSSID Octets: 1 1 6 Figure 9-353â€”Transition Source BSSID subelement format The Subelement ID field is equal to the Transition Source BSSID value in Table 9-172. The Length field is defined in 9.4.3. The Source BSSID field contains a 6-octet BSSID. 962 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Transition Time Threshold subelement is used to request that a Transition Event Report includes the transition event entry when the transition time is greater than or equal to the Transition Time Threshold value. The format of the Transition Time Threshold subelement is shown in Figure 9-354. Subelement ID Length Transition Time Threshold Octets: 1 1 2 Figure 9-354â€”Transition Time Threshold subelement format The Subelement ID field is equal to the Transition Time Threshold value in Table 9-172. The Length field is defined in 9.4.3. The Transition Time Threshold field contains a value representing the Transition Time to be used as the threshold value for the Transition Time condition in TUs. The Transition Time is defined in 11.24.2.2. The Transition Result subelement is used to request that a Transition Event Report includes the transition event entry that matches the transition result defined by this subelement. The format of Transition Result subelement is shown in Figure 9-355. Subelement ID Length Match Value Octets: 1 1 1 Figure 9-355â€”Transition Result subelement format The Subelement ID field is equal to the Transition Result value in Table 9-172. The Length field is defined in 9.4.3. The Match Value field is set with each bit as defined in Figure 9-356 to request that the specified transition results that match the bit descriptions are included in the Transition Event report. B0 B1 B2-B7 Include Successful Include Failed Reserved Transitions Transitions Bits 1 1 6 Figure 9-356â€”Match Value field definitions The Frequent Transition subelement is used to request that an alerting Transition Event report be generated when the total transition count during the specified time period is greater than or equal to the value given in Frequent Transition Count Threshold field. The format of the Frequent Transition subelement is shown in Figure 9-357. The Subelement ID field is equal to the Frequent Transition value in Table 9-172. The Length field is defined in 9.4.3. 963 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Frequent Transition Subelement ID Length Count Threshold Time Interval Octets: 1 1 1 2 Figure 9-357â€”Frequent Transition subelement format The Frequent Transition Count Threshold field is a 1-octet field containing the number of transitions in the measurement duration after which a Transition Event Report is generated. The Time Interval field is the time interval in TUs during which the STA determines if the Frequent Transition Count Threshold is exceeded. 9.4.2.67.3 RSNA event request The Event Request field corresponding to an RSNA event request contains zero or more RSNA Event Request subelements. The subelement format and ordering of subelements are defined in 9.4.3. The set of valid RSNA Event Request subelements is defined in Table 9-173. Table 9-173â€”RSNA Event Request subelement RSNA Event Request subelement Subelement ID RSNA Target BSSID 0 Authentication Type 1 EAP Method 2 RSNA Result 3 Reserved 4â€“255 The RSNA subelements specify reporting conditions for RSNA Event Reports. The RSNA Target BSSID subelement identifies the BSS at which an RSNA Event establishment was attempted. Excluding this subelement from the Event Request element indicates a request for transition events for all source BSSIDs. The format of the RSNA Target BSSID subelement is shown in Figure 9-358. Subelement ID Length Target BSSID Octets: 1 1 6 Figure 9-358â€”RSNA Target BSSID subelement format The Subelement ID field is equal to the RSNA Target BSSID value in Table 9-173. The Length field is defined in 9.4.3. The Target BSSID field contains a 6-octet BSSID. 964 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Authentication Type subelement is used to request that an RSNA Event Report includes the RSNA event entry when the Authentication Type is equal to the authentication type specified in the Authentication Type field. The format of the Authentication Type subelement is shown in Figure 9-359. Subelement ID Length Authentication Type Octets: 1 1 4 Figure 9-359â€”Authentication Type subelement format The Subelement ID field is equal to the Authentication Type value in Table 9-173. The Length field is defined in 9.4.3. The Authentication Type field contains one of the AKM suite selectors defined in Table 9-133 in 9.4.2.25.3. The EAP Method subelement is used to request that an RSNA Event Report includes the RSNA event entry when the EAP Method is equal to the EAP method specified in the EAP Method field. The format of the EAP Method subelement is shown in Figure 9-360. Subelement ID Length EAP Type EAP Vendor ID EAP Vendor (optional) Type (optional) Octets: 1 1 1 0 or 3 0 or 4 Figure 9-360â€”EAP Method subelement format The Subelement ID field is equal to the EAP Method value in Table 9-173. The Length field is defined in 9.4.3. The EAP Type field contains a value that identifies a single EAP method and is any valid IANA assigned EAP type. The EAP Vendor ID field contains a value that identifies the EAP Vendor. The EAP Vendor ID field is included when EAP Type field is 254 and is excluded otherwise. The EAP Vendor Type field contains a value that identifies the EAP Type as defined by the vendor. The EAP Vendor Type field is included when EAP Type field is 254 and is excluded otherwise. The RSNA Result subelement is used to request that an RSNA Event Report includes the RSNA event entry that matches the transition result defined by this subelement. The format of RSNA Result subelement is shown in Figure 9-361. Subelement ID Length Match Value Octets: 1 1 1 Figure 9-361â€”RSNA Result subelement format The Subelement ID field is equal to the RSNA Result value in Table 9-173. The Length field is defined in 9.4.3. 965 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Match Value field bits are set as defined in Figure 9-362 to request that the specified RSNA results that match that bit descriptions are included in the RSNA Event report. B0 B1 B2-B7 Include Successful Include Failed Reserved RSNA RSNA Bits 1 1 6 Figure 9-362â€”Match Value field definitions 9.4.2.67.4 Peer-to-peer link event request The Event Request field corresponding to peer-to-peer link event request contains zero or more Peer-to-Peer Link Event Request subelements. The Peer-to-Peer Link Event Request subelements are defined to have a common format consisting of a 1 octet Subelement ID field, a 1 octet Length field, and a variable-length subelement specific information field. The set of valid Peer-to-Peer Link Event Request subelements is defined in Table 9-174. Table 9-174â€”Peer-to-Peer Link Event Request subelement Peer-to-Peer Link Event Request Subelement ID subelement Peer Address 0 Channel Number 1 Reserved 2â€“255 The Peer-to-Peer Link subelements specify reporting conditions for peer-to-peer link event reporting. The Peer Address subelement identifies the peer STA, BSS, or IBSS of the peer-to-peer links to be reported. Excluding this subelement from the Event Request element indicates a request for peer-to-peer link events for any peer STA, any BSS, and any IBSS. The format of the Peer Address subelement is shown in Figure 9-363. Peer STA/ Subelement ID Length BSSID Address Octets: 1 1 6 Figure 9-363â€”Peer Address subelement format The Subelement ID field is equal to the Peer Address value in Table 9-174. The Length field is defined in 9.4.3. 966 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Peer STA/BSSID Address field contains a 6-octet MAC address of a peer STA or a BSSID for peer-to- peer links in an IBSS. If the indicated address matches the Address 1 field of the MAC header contents (see Table 9-26), then the address is a peer STA address for a TDLS or IBSS. If the indicated address matches the Address 3 field of the MAC header contents, then the address is a BSSID for the Direct Link in an infrastructure BSS or for the IBSS. The Channel Number subelement(s) identify the channel for the peer-to-peer links to be reported. Excluding this subelement from the Event Request element indicates a request for peer-to-peer link events for any channel. The format of the Channel Number subelement is shown in Figure 9-364. The identified channel is indicated by N+1 Channel Number subelements where the first N subelements contain an Operating Class octet with an 80+ behavior limit and the last subelement contains an Operating Class octet without an 80+ behavior limit (as defined in Annex E). Subelement ID Length Operating Class Channel Number Octets: 1 1 1 1 Figure 9-364â€”Channel Number subelement format The Subelement ID field is equal to the Channel Number value in Table 9-174. The Length field is defined in 9.4.3. The Operating Class field indicates the channel set of the peer-to-peer link to be used for the Peer-to-Peer Link event report. Operating Classes are defined in Annex E. The Channel Number field indicates the channel number or (if the corresponding operating class in Annex E has â€œâ€”â€ in the channel set column) the center frequency index of the frequency segment containing the primary channel of the peer-to-peer link events requested and included in the peer-to-peer link event report. A Channel Number of 0 in all N+1 Channel Number subelements indicates a request to report any peer-to- peer link event for any supported channel in the specified filtering Operating Class. 9.4.2.67.5 Vendor Specific event request The Event Request field corresponding to Vendor Specific event request contains zero or more Vendor Specific subelements. The Vendor Specific subelement has the same format as the Vendor Specific element (see 9.4.2.26). 9.4.2.68 Event Report element 9.4.2.68.1 Event Report Definition The Event Report element is used by a STA to report an event. The format of the Event Report element is shown in Figure 9-365. 967 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Event Report Element ID Length Event Token Event Type Status Octets: 1 1 1 1 1 Event TSF Event Time UTC Offset Event Report (optional) (optional) Error (optional) (optional) Octets: 0 or 8 0 or 10 0 or 5 variable Figure 9-365â€”Event Report element format The Element ID and Length fields are defined in 9.4.2.1. The Event Token field is the Event Token in the corresponding Event Request element. If the Event Report element is being sent autonomously then the Event Token is 0. The Event Type field is a number that identifies the type of event report. The Event Types are shown in Table 9-171. The Event Report Status field is a value in Table 9-175, indicating the STAâ€™s response to the Event Request. Table 9-175â€”Event Report Status Event Report Description Status 0 Successful 1 Request failed 2 Request refused 3 Request incapable 4 Detected frequent transition 5â€“255 Reserved The Event TSF, UTC Offset, Event Time Error, and Event Report fields are present only when the Event Report Status field is 0. The Event TSF field is TSF value when the STA logged the event. The UTC Offset field is the UTC value that corresponds to the UTC time when the TSF timer is equal to 0. If the UTC Offset is unknown, the field is 0. The Event Time Error field is the UTC standard deviation, as described in 9.4.2.61, that corresponds to the TSF value logged for the event. If the Event Time Error is unknown, the field is 0. The Event Report field contains the specification of a single event report, as described in 9.4.2.68.2 to 9.4.2.68.5. 968 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Event Report element is included in an Event Report frame, as described in 9.6.14.3. The use of the Event Report element and frame is described in 11.24.2. 9.4.2.68.2 Transition event report The format of the Event Report field corresponding to a Transition event report is shown in Figure 9-366. Source BSSID Target BSSID Transition Time Transition Transition Reason Result Octets: 6 6 2 1 2 Source RCPI Source RSNI Target RCPI Target RSNI Octets: 1 1 1 1 Figure 9-366â€”Event Report format for Transition event The Source BSSID field contains the 6-octet BSSID address of the associated AP prior to the attempted transition. The Target BSSID field contains the 6-octet BSSID address of the AP that is the target of the attempted Transition. The Transition Time field contains the transition time in TUs. The transition time is defined in 11.24.2.2. The Transition Reason field indicates the reason why a transition attempt occurred and contains one of the values in Table 9-176. Table 9-176â€”Transition and Transition Query reasons Transition Reason value Description 0 Unspecified 1 Excessive frame loss rates and/or poor conditions 2 Excessive delay for current traffic streams 3 Insufficient QoS capacity for current traffic streams (TSPEC rejected) 4 First association to ESS (the association initiated by an Association Request frame instead of a Reassociation Request frame) 5 Load balancing 6 Better AP found 7 Deauthenticated or Disassociated from the previous AP 8 AP failed IEEE 802.1X EAP Authentication 9 AP failed 4-way handshake 10 Received too many replay counter failures 11 Received too many data MIC failures 969 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-176â€”Transition and Transition Query reasons (continued) Transition Reason value Description 12 Exceeded maximum number of retransmissions 13 Received too many broadcast disassociations 14 Received too many broadcast deauthentications 15 Previous transition failed 16 Low RSSI 17 Roam from a non-IEEE-802.11 system 18 Transition due to received BSS Transition Request frame 19 Preferred BSS transition candidate list included 20 Leaving ESS 21â€“255 Reserved The Transition Result field contains the result of the attempted transition and is one of the status codes specified in Table 9-46 in 9.4.1.9. The Source RCPI field indicates the received channel power of the most recently measured frame from the Source BSSID before the STA reassociates to the Target BSSID. The Source RCPI is a logarithmic function of the received signal power, as defined in 9.4.2.38. The Source RSNI field indicates the received signal-to-noise indication of the most recently measured frame from the Source BSSID before the STA reassociates to the Target BSSID. The Source RSNI is a logarithmic function of the signal-to-noise ratio, as defined in 9.4.2.41. The Source BSSID, Source RCPI, and Source RSNI fields are set to 0 if the transition is initiated by an Association Request frame. The Target RCPI field indicates the received channel power of the first measured frame just after the STA reassociates to the Target BSSID. If association with the Target BSSID failed, the Target RCPI field indicates the received channel power of the most recently measured frame from the Target BSSID. The Target RCPI is a logarithmic function of the received signal power, as defined in 9.4.2.38. The Target RSNI field indicates the received signal-to-noise indication of the first measured frame just after the STA reassociates to the Target BSSID. If association with the Target BSSID failed, the Target RCPI field indicates the received signal-to-noise indication of the most recently measured frame from the Target BSSID. The Target RSNI is a logarithmic function of the signal-to-noise ratio, as defined in 9.4.2.41. 970 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.68.3 RSNA event report The format of the Event Report field corresponding to an RSNA event report is shown in Figure 9-367. Target BSSID Authentication EAP Method RSNA Result RSNE Type Octets: 6 4 1 or 8 2 variable Figure 9-367â€”Event Report format for RSNA event The Target BSSID field contains the 6-octet BSSID address of the AP accepting the authentication attempt. The Authentication Type field contains the Authentication type in use at the time of the authentication attempt and is one of the AKM suite selectors defined in Table 9-133 in 9.4.2.25.3. When the Authentication Type field is the value of either 00-0F-AC:1 (Authentication negotiated over IEEE Std 802.1X or using PMKSA caching as defined in 12.6.10.3) or 00-0F-AC:3 (AKM suite selector for fast BSS transition as defined in 12.6.3), the EAP Method field contains the IANA assigned EAP type. The EAP type contains either the legacy type (1 octet) or the expanded type (1 octet type = 254, 3-octet Vendor ID, 4- octet Vendor-Type). The EAP Method field is 0 otherwise. The EAP Method field is a single octet set to 0 otherwise. The RSNA Result field contains the result of the RSNA establishment attempt and is one of the status codes specified in Table 9-46 in 9.4.1.9. The RSNE field contains the entire contents of the negotiated RSNE at the time of the authentication attempt. The maximum length of the RSNE field is less than the maximum length of an RSNE, as defined in 9.4.2.25. If the length of the RSNE included here exceeds the maximum length of the RSNE field, the RSNE is truncated to the maximum length allowed for the RSNE field. 9.4.2.68.4 Peer-to-peer link event report The format of the Event Report field corresponding to a Peer-to-Peer Link event report is shown in Figure 9-368. Peer STA/ Operating Channel STA Tx Connection BSSID Peer Status Address Class Number Power Time Octets: 6 1 1 1 3 1 Figure 9-368â€”Event Report format for peer-to-peer link event A peer-to-peer link is defined to be either a Direct Link within a QoS BSS, a TDLS, or a STA-to-STA communication in an IBSS. The Peer STA/BSSID Address field contains a 6-octet MAC address. If this event is for a peer-to-peer link in an infrastructure BSS, this field contains the MAC address of the peer STA. If this event is for a peer-to- peer link in an IBSS, this field contains the BSSID of the IBSS. The Operating Class field indicates the channel set of the Peer-to-Peer link. Valid values of the Operating Class are shown in Annex E. 971 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Channel Number field indicates the peer-to-peer channel number of the peer-to-peer link. The Channel Number is defined within an Operating Class as shown in Annex E. The STA Tx Power field indicates the target transmit power at the antenna (i.e., EIRP) in dBm with a tolerance of Â± 5 dB of the lowest basic rate of the reporting STA. The Connection Time field contains the connection time in seconds. If the Peer Status is 0, this field indicates the duration of the Direct Link. If the Peer Status is 1, this field indicates the time difference from the time the Direct Link was established to the time at which the reporting STA generated the event report. If the Peer Status is 2, this field indicates the duration of the IBSS membership. If the Peer Status is 3, this field indicates the time difference from the time the STA joined the IBSS to the time at which the reporting STA generated the event report. See 11.24.2.4. The Peer Status field indicates the Peer link connection status as indicated in Table 9-177. Table 9-177â€”Peer Status definitions Peer Status Description 0 Direct Link terminated 1 Direct Link active 2 IBSS membership terminated 3 IBSS membership active 4â€“255 Reserved 9.4.2.68.5 WNM log event report The format of the Event Report field corresponding to a WNM log event report is shown in Figure 9-369. WNM Log Msg Octets: variable Figure 9-369â€”Event Report format for WNM log event The WNM Log Msg field contains the entire syslog message, consisting of the PRI, HEADER, and MSG portion of a WNM log message as described in IETF RFC 5424. The TAG field of the MSG portion of the message is a 17 octet string containing the ASCII representation of the STA MAC address using hexadecimal notation with colons between octets. The octet containing the Individual/Group bit occurs last, and that bit is in the least significant position within that octet. See 11.24.2.5. NOTEâ€”For example, the TAG field for a STA with MAC address AC-DE-48-12-7B-80 is "80:7B:12:48:DE:AC" or "80:7b:12:48:de:ac". 9.4.2.68.6 Vendor Specific event report The Event Report field corresponding to Vendor Specific event report contains zero or more Vendor Specific subelements. The Vendor Specific subelement has the same format as the Vendor Specific element (see 9.4.2.26). 972 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.69 Diagnostic Request element 9.4.2.69.1 Diagnostic Request definition The Diagnostic Request element contains a request that the receiving STA undertake the specified diagnos- tic action. The format of the Diagnostic Request element is shown in Figure 9-370. Diagnostic Diagnostic Diagnostic Diagnostic Element ID Length Subelements Token Request Type Timeout (optional) Octets: 1 1 1 1 2 variable Figure 9-370â€”Diagnostic Request element format The Element ID and Length fields are defined in 9.4.2.1. The minimum value of the Length field is 4 (based on a minimum length for the Diagnostic Subelements field of 0 octets). The Diagnostic Token field is a number that is unique among the Diagnostic Request elements sent to each destination MAC address for which a corresponding Diagnostic Report element has not been received. The Diagnostic Request Type field is a number that identifies a type of diagnostic request. The values of Diagnostic Request Types are shown in Table 9-178. Table 9-178â€”Diagnostic Request/Report Type definitions Name Diagnostic Type values Cancel Diagnostic Request 0 Manufacturer Information STA Report 1 Configuration Profile 2 Association Diagnostic 3 IEEE 802.1X Authentication Diagnostic 4 Reserved 5â€“220 Vendor Specific 221 Reserved 222â€“255 The Diagnostic Timeout field contains the time, in seconds, after which no response is returned. The Diagnostic Subelements field contains zero or more diagnostic subelements depending on the specific Diagnostic Request Type, as defined in 9.4.2.69.2 to 9.4.2.69.4. The Cancel Diagnostic Request, Manufacturer Information STA Report, and Configuration Profile Diagnostic Request elements carry no Diagnostic subelements. The Diagnostic Request element is included in a Diagnostic Request frame, as described in 9.6.14.4. The use of Diagnostic Request element and frames is described in 11.24.3. 973 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.69.2 Association Diagnostic request The Diagnostic Subelements field corresponding to an Association Diagnostic request type is shown in Table 9-179. The corresponding Diagnostic subelements are defined in 9.4.2.69.5. Table 9-179â€”Association Diagnostic request contents Order Subelement 1 AP Descriptor 2 Profile ID 9.4.2.69.3 IEEE 802.1X Authentication Diagnostic request The Diagnostic Subelements field corresponding to an IEEE 802.1X Authentication Diagnostic request type is shown in Table 9-180. The corresponding Diagnostic subelements are defined in 9.4.2.69.5. Table 9-180â€”IEEE 802.1X Authentication Diagnostic request contents Order Subelement 1 AP Descriptor 2 EAP Method 3 Credential Type 4 Profile ID 9.4.2.69.4 Vendor Specific diagnostic request The Diagnostic Subelements field corresponding to a Diagnostic Request element of type Vendor Specific diagnostic request contains zero or more Vendor Specific subelements. The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26). 9.4.2.69.5 Diagnostic subelement descriptions The following text describes the various subelements that are optionally included in Diagnostic Subelements field of a Diagnostic Request element (9.4.2.69) or a Diagnostic Report element (9.4.2.70). The format of a Diagnostic subelement is shown in Figure 9-371. Diagnostic Subelement Length Diagnostic Subelement ID Contents Octets: 1 1 variable Figure 9-371â€”Diagnostic subelement format 974 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Diagnostic Subelement ID field indicates the Diagnostic subelement ID and is any allocated value in Figure 9-181. Table 9-181â€”Diagnostic subelement ID values Subelement ID Subelement name 0 Credential Type 1 AKM Suite 2 AP Descriptor 3 Antenna Type 4 Cipher Suite 5 Collocated Radio Type 6 Device Type 7 EAP Method 8 Firmware Version 9 MAC Address 10 Manufacturer ID String 11 Manufacturer Model String 12 Manufacturer OI 13 Manufacturer Serial Number String 14 Power Save Mode 15 Profile ID 16 Supported Operating Classes 17 Status Code 18 SSID 19 Tx Power Capability 20 Certificate ID 21â€“220 Reserved 221 Vendor Specific 221â€“255 Reserved The Length field is the length in octets of the Diagnostic Subelement Contents field. The values of the Diagnostic Subelement Contents field are described in the following paragraphs. The format for the Credential Type subelement is shown in Figure 9-372. 975 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Credential Subelement ID Length Values Octets: 1 1 variable Figure 9-372â€”Credential Type subelement format The Credentials Values field indicates one or more types of credential. Each value is chosen from those shown in Table 9-182. Table 9-182â€”Credentials values Value Description 0 None 1 Preshared key 2 Username and password 3 X.509 certificate 4 Other certificate 5 One time password 6 Token 7â€“255 Reserved The format for the AKM Suite subelement is shown in Figure 9-373. Subelement ID Length OUI AKM Suite Octets: 1 1 3 1 Figure 9-373â€”AKM Suite subelement format The OUI and AKM Suite fields identify the authentication method, and the AKM suite selector is one of the values in Table 9-133 in 9.4.2.25.3. The format of the AP descriptor subelement is described in Figure 9-374. Subelement ID Length BSSID Operating Class Channel Number Octets: 1 1 6 1 1 Figure 9-374â€”AP Descriptor subelement format The set of current operating classes and channel widths of the AP is indicated by N+1 AP descriptor subelements where the first N subelements contain an Operating Class octet with an 80+ behavior limit and the last subelement contains an Operating Class octet without an 80+ behavior limit (as defined in Annex E). NOTEâ€”An 80+80 MHz AP sends four AP descriptor subelements for 20/40 MHz, 80 MHz, 80+ MHz (for the secondary 80 MHz frequency segment), and 80 MHz (for the primary 80 MHz frequency segment). 976 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The BSSID field is a 6-octet field, as described in 9.2.4.3.4, that identifies the BSS indicated in the AP Descriptor subelement. The Operating Class field contains an enumerated value from Annex E that identifies the mapping from Channel Number to frequency. The Channel Number field indicates a current operating channel or (if the corresponding operating class in Annex E has â€œâ€”â€ in the channel set column) the center frequency index of the frequency segment containing the primary channel, of the AP identified by the BSSID in the AP Descriptor. The format for the Antenna Type subelement is shown in Figure 9-375. Subelement ID Length Antenna Count Antenna Gain Antenna Type Octets: 1 1 1 1 variable Figure 9-375â€”Antenna Type subelement format The Antenna Count field contains a 1-octet field indicating the number of antennas of the indicated antenna type and antenna gain pair. The Antenna Count field value 0 is reserved. The Antenna Gain field contains the peak gain, in dBi, of the antenna. The Antenna Type field contains an ASCII string (truncated to 251 octets if required) describing the manufacturerâ€™s type information (i.e., a series of letters/numbers) of the antenna(s) connected to the wireless adapter. NOTEâ€”Beamforming antennas might have several Antenna IDs, depending on antenna bearing. The format for the Cipher Suite subelement is shown in Figure 9-376. Subelement ID Length OUI Suite Type Octets: 1 1 3 1 Figure 9-376â€”Cipher Suite subelement format The OUI and Suite Type fields identify the cipher suite, and the cipher suite selector is one of the values in Table 9-131. The format for the Collocated Radio Type subelement is shown in Figure 9-377. Collocated Subelement ID Length Radio Type Octets: 1 1 1 Figure 9-377â€”Collocated Radio Type subelement format The Collocated Radio Type subelement contains a 1-octet field indicating the type of collocated radio and is one of the values in Table 9-183. The method that a STA uses to obtain the information on the Collocated Radio is out of the scope of this standard. 977 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-183â€”Collocated Radio Type Collocated Radio Type Value Reserved 0 Cellular 1 Cordless 2 GPS 3 IEEE 802.11â„¢ 4 IEEE 802.15â„¢ 5 IEEE 802.16â„¢ 6 IEEE 802.20â„¢ 7 IEEE 802.22â„¢ 8 Digital Audio Broadcasting 9 Digital Video Broadcasting 10 Reserved 11â€“255 The Device Type subelement reports the type of device in which the IEEE 802.11 STA resides. The format of the Device Type subelement is shown in Figure 9-378. Subelement ID Length Device Type Octets: 1 1 1 Figure 9-378â€”Device Type subelement format The Device Type field is a 1-octet field indicating the category of device.27 The numerical assignment to each device type category is defined in Table 9-184. Table 9-184â€”Device Type definitions Device Type Value Reserved 0 Reference Design 1 Access Point or Wireless Router for Home or Small Office 2 Enterprise Access Point 3 Cable, DSL or Other Broadband Gateway 4 Digital Still Camera 5 27 The category of device is based on the Wi-Fi Alliance category definitions found at http://www.wi-fi.org/knowledge_center/insist- on-wifi-certified. 978 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-184â€”Device Type definitions (continued) Device Type Value Portable Video Camera 6 Networked Web Camera 7 Digital Audioâ€”Stationary 8 Digital Audioâ€”Portable 9 Set-Top Box, Media Extender, Media Server (includes players & recorders) 10 Display Device (television, monitor, picture frame) 11 Game Console or Game Console Adapter 12 Gaming Device â€”Portable 13 Media Server or Media Adapter 14 Network Storage Device 15 External Card 16 Internal Card 17 Ultra-Mobile PC 18 Notebook Computer 19 PDA (Personal Digital Assistant) 20 Printer or Print Server (includes scanner and/or fax capability) 21 Phoneâ€”Dual-Mode 22 Phoneâ€”Single-Mode 23 Smartphoneâ€”Dual-Mode 24 Smartphoneâ€”Single-Mode 25 Reserved 26-220 Other devices 221 Reserved 222â€“255 The format for the EAP Method subelement is shown in Figure 9-379. EAP Vendor ID EAP Vendor Subelement ID Length EAP Type (optional) Type (optional) Octets: 1 1 1 0 or 3 0 or 4 Figure 9-379â€”EAP Method subelement format The EAP Type field contains a value that identifies a single EAP method and is any valid IANA assigned EAP type. 979 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The EAP Vendor ID field contains a value that identifies the EAP Vendor. The EAP Vendor ID field is included when EAP Type field is 254 and is excluded otherwise. The EAP Vendor Type field contains a value that identifies the EAP Type as defined by the vendor. The EAP Vendor Type field is included when EAP Type field is 254 and is excluded otherwise. The format for the Firmware Version subelement is shown in Figure 9-380. Subelement ID Length Firmware Version Octets: 1 1 variable Figure 9-380â€”Firmware Version subelement format This Firmware Version field contains an ASCII string identifying the version of firmware currently installed on the wireless network adaptor. The format for the MAC Address subelement is shown in Figure 9-381. Subelement ID Length MAC Address Octets: 1 1 6 Figure 9-381â€”MAC Address subelement format This MAC Address field contains the 6-octet IEEE 802 MAC address of the STA. The format for the Manufacturer ID String subelement is shown in Figure 9-382. Subelement ID Length ID Octets: 1 1 variable Figure 9-382â€”Manufacturer ID String subelement format The ID field contains an ASCII string indicating the manufacturer identifier of the wireless network adaptor. The format for the Manufacturer Model String subelement is shown in Figure 9-383. Subelement ID Length Model Octets: 1 1 variable Figure 9-383â€”Manufacturer Model String subelement format The Model field contains an ASCII string indicating the model of the wireless network adaptor. The format for the Manufacturer OI subelement is shown in Figure 9-384. 980 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Subelement ID Length OI Octets: 1 1 3 or 5 Figure 9-384â€”Manufacturer OI subelement format The OI field contains an organization identifier, as defined in 9.4.1.32. The format for the Manufacturer Serial Number String subelement is shown in Figure 9-385. Subelement ID Length Serial Number Octets: 1 1 variable Figure 9-385â€”Manufacturer Serial Number String subelement format The Serial Number field contains an ASCII string indicating the serial number of the wireless network adaptor. The format for the Power Save Mode subelement is shown in Figure 9-386. Power Save Subelement ID Length Mode Octets: 1 1 4 Figure 9-386â€”Power Save Mode subelement format The Power Save Mode field is a bitmap field that indicates the power save mode(s) in use by the STA, as defined in Table 9-185. Table 9-185â€”Power Save Mode definition Power Save Mode Bit Unknown 0 None 1 PS mode (ReceiveDTIMs=1, see 11.2.3) 2 PS mode (ReceiveDTIMs=0, see 11.2.3) 3 U-APSD (see 11.2.3.5) 4 S-APSD (see 11.2.3.5) 5 U-PSMP (see 10.29 6 S-PSMP (see 10.29) 7 SM power save (see 11.2.6) 8 WNM sleep mode (see 11.2.3.18) 9 FMS (see 11.2.3.16) 10 TIM broadcast (see 11.2.3.17) 11 981 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-185â€”Power Save Mode definition (continued) Power Save Mode Bit TFS (see 11.24.12) 12 TPU (see 11.2.3.15) 13 TDLS peer PSM (see 11.2.3.14) 14 TXOP power save mode 15 Reserved 16â€“31 The format for the Profile ID subelement is shown in Figure 9-387. Subelement ID Length Profile ID Octets: 1 1 1 Figure 9-387â€” Profile ID subelement format The Profile ID field contains a unique identifier for referencing a configuration profile available on a device. The value of the identifier is uniquely associated to a single configuration profile on the device sending the identifier. The format for the Supported Operating Classes subelement is shown in Figure 9-388. Subelement ID Length Supported Operating Classes Element Octets: 1 1 variable Figure 9-388â€”Supported Operating Classes subelement format The Supported Operating Classes Element field contains the Supported Operating Classes element, as defined in 9.4.2.54. The format for the Status Code subelement is shown in Figure 9-389. Subelement ID Length Status Code Octets: 1 1 2 Figure 9-389â€”Status Code subelement format The Status Code field contains the final IEEE 802.11 Status code, as defined in Table 9-46 in 9.4.1.9, received at the end of the applicable operation. 982 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The format for the SSID subelement is shown in Figure 9-390. Subelement ID Length SSID Octets: 1 1 0 to 32 Figure 9-390â€”SSID subelement format The SSID field contains a Service Set Identifier with a maximum length of 32 octets, as defined in 9.4.2.2. The format for the Tx Power Capability subelement is shown in Figure 9-391. Subelement ID Length Tx Power Mode Tx Power Octets: 1 1 1 variable Figure 9-391â€”Tx Power Capability subelement format The Tx Power Mode field identifies the transmit power mode of the non-AP STA and is one of the values in Table 9-186. Table 9-186â€”Tx Power Modes Tx Power Mode Value Discrete 0 Range 1 Reserved 2â€“255 The Tx Power field indicates the target transmit power level(s) at the antenna(s) (i.e., EIRP), where the actual power is within Â±5 dB to the target. Each transmit power level is encoded in a single octet as a 2s complement value in dBm, rounded to the nearest integer. If the Tx Power Mode field is 0 then the Tx Power field contains one or more transmit power levels in increasing numerical order. If the Tx Power Mode field is 1, the Tx Power field contains the STAâ€™s minimum and nonzero maximum transmit power levels, in that order. The format for the Certificate ID subelement is shown in Figure 9-392. Subelement ID Length Certificate ID Octets: 1 1 variable Figure 9-392â€”Certificate ID subelement format The Certificate ID field contains an UTF-8 string indicating an identifier assigned to the STA in a manner outside the scope of the standard. The Certificate ID typically takes the form of â€œWFA3991â€ and might be used by a receiving STA to look up the certificate assigned to that ID. The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26). 983 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.70 Diagnostic Report element 9.4.2.70.1 Diagnostic report definition The Diagnostic Report element contains a Diagnostic report. The format of the Diagnostic Report element is shown in Figure 9-393. Element Length Diagnostic Diagnostic Diagnostic Diagnostic Subelements ID Token Report Type Status Octets: 1 1 1 1 1 variable Figure 9-393â€”Diagnostic Report element format The Element ID and Length fields are defined in 9.4.2.1. The minimum value of the Length field is 3. The Diagnostic Token field is the Diagnostic Token in the corresponding Diagnostic Request element. The Diagnostic Report Type field is a number that identifies the Diagnostic report. The Diagnostic Report Types are defined in Table 9-178. The Diagnostic Status field is a value in Table 9-175 (see 9.4.2.68), indicating the STAâ€™s response to the diagnostic request indicated by the diagnostic token. The Diagnostic Subelements field contains the results of the diagnostic request. The Diagnostic Subelements field contains the diagnostic subelement values, defined in 9.4.2.69.5 corresponding to the Diagnostic Report Type field value. The Diagnostic Report element is included in a Diagnostic Report frame, as described in 9.6.14.5. The use of Diagnostic Report element and frames is described in 11.24.3. 9.4.2.70.2 Manufacturer Information STA Report The contents of the Diagnostic Subelements field of a Diagnostic Report element of type Manufacturer Information STA Report is shown in Table 9-187. The corresponding Diagnostic subelements are defined in 9.4.2.69.5. Table 9-187â€”Manufacturer Information STA report contents Order Subelement 1 Manufacturer OI 2 Manufacturer ID string 3 Manufacturer model string 4 Manufacturer serial number string 6 Firmware Version 7 Antenna Type 984 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-187â€”Manufacturer Information STA report contents (continued) Order Subelement 8 Collocated Radio Type 9 Device Type 10 Certificate ID 9.4.2.70.3 Configuration Profile report The contents of the Diagnostic Subelements field of a Diagnostic Report element of type Configuration Profile is shown in Table 9-188. The corresponding Diagnostic subelements are defined in 9.4.2.69.5. Table 9-188â€”Configuration Profile report contents Order Subelement 1 Profile ID 2 Supported Operating Classes 3 Tx Power 4 Cipher Suite 5 AKM Suite 6 EAP Method 7 Credential Type 8 SSID 9 Power Save Mode 9.4.2.70.4 Association Diagnostic report The contents of the Diagnostic Subelements field of a Diagnostic Report element of type Association Diagnostic is shown in Table 9-189. The corresponding Diagnostic subelements are defined in 9.4.2.69.5. Table 9-189â€”Association Diagnostic report contents Order Subelement 1 AP Descriptor 2 Status Code 985 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.70.5 IEEE 802.1X Authentication Diagnostic report The contents of the Diagnostic Subelements field of a Diagnostic Report element of type IEEE 802.1X Authentication Diagnostic is shown in Table 9-190. The corresponding Diagnostic subelements are defined in 9.4.2.69.5. Table 9-190â€”IEEE 802.1X Authentication Diagnostic report contents Order Subelement 1 AP Descriptor 2 EAP Method 3 Credential Type 4 Status Code 9.4.2.70.6 Vendor Specific diagnostic report The contents of the Diagnostic subelements field of a Diagnostic Report element of type Vendor Specific contains zero or more Vendor Specific subelements that have the same formats as Vendor Specific elements in 9.4.2.26. 9.4.2.71 Location Parameters element 9.4.2.71.1 Location Parameters definition The Location Parameters element is used for location services. The format of this element is shown in Figure 9-394. Element ID Length Location Subelements Octets: 1 1 variable Figure 9-394â€”Location Parameters element format The Element ID and Length fields are defined in 9.4.2.1. The Location Subelements field contains one or more Location subelements described in Table 9-191. Table 9-191â€”Optional subelement IDs for Location Parameters Subelement Subelement name ID 1 Location Indication Parameters (see 9.4.2.71.2) 2 Location Indication Channels (see 9.4.2.71.3) 3 Location Status (see 9.4.2.71.4) 4 Radio (see 9.4.2.71.5) 986 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-191â€”Optional subelement IDs for Location Parameters (continued) Subelement Subelement name ID 5 Motion (see 9.4.2.71.6) 6 Location Indication Broadcast Data Rate (see 9.4.2.71.7) 7 Time of Departure (see 9.4.2.71.8) 8 Location Indication Options (see 9.4.2.71.9) 9â€“220 Reserved 221 Vendor Specific (see 9.4.2.26) 222â€“255 Reserved The Location Parameters element is included in Location Configuration Request frames, as described in 9.6.14.6; Location Configuration Response frames, as described in 9.6.14.7; and Location Track Notification frames, as described in 9.6.8.17. The use of the Location Parameters element is described in 11.24.4. The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26). Multiple Vendor Specific subelements are optionally present in the list of Optional subelements. 9.4.2.71.2 Location Indication Parameters subelement The Location Indication Parameters subelement contains STA location reporting characteristics. The format of the Location Indication Parameters subelement is shown in Figure 9-395. Normal Indication Report Normal Number of Subelement ID Length Multicast Report Address Interval Units Interval Frames per Channel Octets: 1 1 6 1 2 1 In-Motion In-Motion Number of Burst Tracking ESS Inter-frame Detection Report Interval Frames per Interval Duration Interval Channel Octets: 2 1 1 1 1 Figure 9-395â€”Location Indication Parameters subelement The Subelement ID field is defined in Table 9-191. The Length field is defined in 9.4.3. Except in Location Track Notification frames sent in an IBSS, the Indication Multicast Address field specifies the destination address to which the Location Track Notification frames are sent. The value of this field is a locally administered group address formed according to the procedure defined in 11.24.4.1. The field is reserved when Location Track Notification frames are transmitted in an IBSS. 987 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Report Interval Units field contains the units used for the Normal Report Interval field and In-Motion Report Interval field, as indicated in Table 9-192. Table 9-192â€”Report Interval Units field Report Interval Units Description 0 Hours 1 Minutes 2 Seconds 3 Milliseconds 4â€“255 Reserved The Normal Report Interval is the time interval, expressed in the units indicated in the Report Interval Units field, at which the reporting STA is expected to transmit one or more Location Track Notification frames if either dot11MotionDetectionActivated is false or the STA is stationary. The STA does not transmit Location Track Notification frames when the Normal Report Interval is 0. The Normal Number of Frames per Channel is the number of Location Track Notification frames per channel sent or expected to be sent by the STA at each Normal Report Interval. Motion is the act or process of moving, or a particular action or movement relative to the point at which the STA is configured to send Location Track Notification frames. Motion might be detected using one of the following criteria: â€” Detection of speed that is greater or equal to 0.5 m/sec. â€” Detection of movement or vibration, for example by a ball-in-tube sensor or accelerometer or other means. The exact criteria and mechanism to detect motion is out of scope for this standard. The In-Motion Report Interval is the time interval, expressed in the units indicated in the Report Interval Units field, at which the STA reports its location by sending a Location Track Notification frame when the reporting STA is in motion. If dot11MotionDetectionActivated is false, this field is 0. The In-Motion Number of Frames per Channel is the number of Location Track Notification frames per channel sent or expected to be sent by the STA at each In-Motion Report Interval. If dot11MotionDetectionActivated is false, this field is 0. The Burst Inter-frame Interval is the target time interval, expressed in milliseconds, between the transmissions of each of the Normal or In-Motion frames on the same channel. The Burst Inter-frame interval value is 0 to indicate that frames are transmitted with no target inter-frame delay. The Tracking Duration is the amount of time, in minutes, that a STA sends the Location Track Notification frames. The duration starts as soon as the STA sends a Location Configuration Response frame with a Location Status value of Success. If the Tracking Duration value is a nonzero value the STA sends Location Track Notification frames, based on the Normal and In-Motion Report Interval field values, until the duration ends. If the Tracking Duration is 0 the STA continuously sends Location Track Notification frames as defined by Normal and In-Motion Report Interval field values until transmission is terminated based on the procedures detailed in 11.24.4.2. 988 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The ESS Detection Interval is the periodicity, in minutes, that a STA checks for beacons transmitted by one or more APs belonging to the same ESS that configured the STA. If no beacons from the ESS are received for this period, the STA terminates transmission of Location Track Notification frames, as described in the procedures detailed in 11.24.4.2. The ESS Detection Interval field is not used when the ESS Detection Interval field value is 0. 9.4.2.71.3 Location Indication Channels subelement The Location Indication Channels subelement contains location reporting channel information. The format of the Location Indication Channels subelement format is shown in Figure 9-396. one or more entries Subelement Channel ID Length Entry Octets: 1 1 2xn Figure 9-396â€”Location Indication Channels subelement The Subelement ID field is defined in Table 9-191. The Length field is defined in 9.4.3. The Channel Entry field includes one or more Operating Class and Channel fields (see Figure 9-88). The Operating Class subfield of the Operating Class and Channel field indicates the frequency band on which a STA transmits Location Track Notification frames. The Channel subfield of the Operating Class and Channel field indicates a channel number on which a STA sends or an ESS expects to receive Location Track Notification frames. The Operating Class and Channel fields can be grouped together to identify a noncontiguous channel. A noncontiguous channel is indicated by a group of N+1 Operating Class and Channel fields where the first N Operating Class and Channel fields contain an Operating Class subfield with an 80+ behavior limit and the last Operating Class and Channel field in the group contains an Operating Class subfield without an 80+ behavior limit (as defined in Annex E). 9.4.2.71.4 Location Status subelement The Location Status subelement provides the result of a Location Request or Location Configuration Request frame. The format of the Location Status subelement is shown in Figure 9-397. Config Subelement ID Length Status Subelement ID Octets: 1 1 1 1 Figure 9-397â€”Location Status subelement 989 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Subelement ID field is defined in Table 9-191. The Length field is defined in 9.4.3. The Config Subelement ID field is a specific Location Parameters subelement ID transmitted in a Location Configuration Request frame as defined in Table 9-191. A Location Status subelement is included for each configuration subelement in the Location Configuration Request frame, except when all status values are the same. When all status values are the same, one Location Status subelement is included with the Config subelement ID set to 0 in the Location Configuration Response frame. The Status field identifies the result of the Location Request frame and is one of the values in Table 9-175. 9.4.2.71.5 Radio subelement The Radio subelement contains radio information. The format of the Radio subelement is shown in Figure 9- 398. Subelement Length Transmit Antenna Antenna RSNI RCPI ID Power ID Gain Octets: 1 1 1 1 1 1 1 Figure 9-398â€”Radio subelement The Subelement ID field is defined in Table 9-191. The Length field is defined in 9.4.3. The Transmit Power field is the transmit power used to transmit the current Location Track Notification frame containing the Location Parameters element with the Radio subelement and is a signed integer, 1 octet in length, reported as an EIRP in dBm. A value of â€“128 indicates that the transmit power is unknown. The tolerance for the transmit power value reported in the Radio subelement is Â± 5 dB. This tolerance is defined as the maximum possible difference, in decibels, between the reported power value and the total transmitted power across all antennas of the STA, which are measured when transmitting Location Request frames. The Antenna ID field is the identifying number for the antenna used to transmit the Location Request frame. The Antenna ID is defined in 9.4.2.40. The Antenna Gain field is the antenna gain of the antenna (or group of antennas) over which the Location Track Notification frame is transmitted and is a signed integer, 1 octet in length, reported in dB. A value of â€“ 128 indicates that the antenna gain is unknown. The RSNI field contains the RSNI value measured against the most recently received Location Configuration Request frame requesting that a Radio subelement be included in the Location Track Notification frame. The RSNI value is defined in 9.4.2.41. A value of 255 indicates that the RSNI value is unknown or is not used. The RCPI field contains the RCPI value measured against the most recently received Location Configuration Request frame requesting that a Radio subelement be included in the Location Track Notification frame. The RCPI value is defined in 9.4.2.38. A value of 255 indicates that the RCPI value is unknown or is not used. 990 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.71.6 Motion subelement The Motion subelement contains motion information. The format of the Motion subelement is shown in Figure 9-399. Subelement Length Motion Bearing Speed Horizontal Vertical ID Indicator Units Speed Speed Octets: 1 1 1 2 1 2 2 Figure 9-399â€”Motion subelement The Subelement ID field is defined in Table 9-191. The Length field is defined in 9.4.3. The Motion Indicator field is defined in Table 9-193. The mechanism that a STA uses to determine the value or transitions from one value to another of the Motion Indicator field is beyond the scope of the standard. Table 9-193â€”Motion Indicator field Motion Indicator value Description 0 Stationary: the device is stationary and not in motion. 1 Start of motion: the device was stationary and is now in motion. 2 In motion: the device is and has been in motion. 3 End of motion: the device was in motion and is now stationary. 4 Unknown: information related to motion is unknown. 5â€“255 Reserved The Bearing field, defined by a 2-octet unsigned integer, specifies the direction that the STA is traveling with relation to true north, increasing clockwise, measured in degrees from 0Â° to 359Â°. If the Bearing value is unknown, the field is 65 535. The Speed Units field contains the units for both Horizontal and Vertical Speed field, as defined in Table 9-194. Table 9-194â€”Speed Units Speed Units Value Description 0 Centimeters per second 1 Meters per second 2â€“255 Reserved 991 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Horizontal Speed field contains the horizontal speed of the STA expressed in the units indicated in the Speed Units field. If the Horizontal Speed value is unknown, the field is 65 535. The Vertical Speed field is a 2s complement signed integer indicating the vertical speed of the STA expressed in the units indicated in the Speed Units field. If the Vertical Speed value is unknown or greater than 32 766, the field is 32 767. If the Vertical Speed value is less than â€“32 767, the field is â€“32 768. The Motion subelement field values are valid at the time of transmission of the Location Track Notification frame containing the subelement. 9.4.2.71.7 Location Indication Broadcast Data Rate subelement The Location Indication Broadcast Data Rate subelement contains location reporting transmission rate information. The format of the Location Indication Broadcast Data Rate subelement format is shown in Figure 9-400. Subelement ID Length Broadcast Target Data Rate Octets: 1 1 4 Figure 9-400â€”Location Indication Broadcast Data Rate subelement The Subelement ID field is defined in Table 9-191. The Length field is defined in 9.4.3. The Broadcast Target Data Rate field specifies the target data rate at which the STA transmits Location Track Notification frames. The Broadcast Target Data Rate field format is specified by the Rate Identification field defined in 9.4.1.33. A value of 0 indicates the STA transmits Location Track Notification frames at a rate chosen by the STA transmitting the Location Track Notification frames. 9.4.2.71.8 Time of Departure subelement The Time of Departure subelement contains time of departure information for the Location Track Notification frame including the subelement. The format of the Time of Departure subelement is shown in Figure 9-401. Subelement Length TOD TOD RMS TOD Clock ID Timestamp Rate Octets: 1 1 4 2 2 Figure 9-401â€”Time of Departure subelement The Subelement ID field is defined in Table 9-191. The Length field is defined in 9.4.3. The TOD Timestamp field specifies when the first frame energy is sent by the transmitting port in units equal to 1/TOD Clock Rate, where the TOD Clock Rate is specified in the TOD Clock Rate field. The reported TOD timestamp value is determined from the TIME_OF_DEPARTURE parameter within the PHY-TXSTART.confirm primitive. 992 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The TOD RMS field specifies the RMS time of departure error in units equal to 1/TOD Clock Rate, where the TOD Clock Rate is specified in the TOD Clock Rate field, where the time of departure error equals the difference between the TOD Timestamp field and the time of departure measured by a reference entity using a clock synchronized to the start time and mean frequency of the local PHY entityâ€™s clock. The TOD RMS field is determined from aTxPHYTxStartRMS in units equal to 1/TOD Clock Rate, where the TOD Clock Rate is specified in the TOD Clock Rate field. The TOD Clock Rate field contains the clock rate used to generate the TOD timestamp value reported in the TOD Timestamp field, and it is specified in units of MHz. 9.4.2.71.9 Location Indication Options subelement The Location Indication Options subelement contains the options for the STA when transmitting the Loca- tion Track Notification frame. The format of the Location Indication Options subelement is shown in Figure 9-402. Subelement Length Options Indication ID Used Parameters Octets: 1 1 1 variable Figure 9-402â€”Location Indication Options subelement The Subelement ID field is defined in Table 9-191. The Length field is defined in 9.4.3. The Options Used field specifies which Indication Parameter fields in the Location Indication Options subelement are used. The format of the Options Used field is shown in Figure 9-403. B0 B1 B7 Beacon Measurement Mode Used Reserved Bits: 1 7 Figure 9-403â€”Options Used field format The Indication Parameters field defines a sequence of optional fields that are included in the Location Indication Options subelement based on the Options Used field value. The value of the Indication Parameters field is defined in Table 9-195. Table 9-195â€”Indication Parameter values Order Field length Field Description 1 1 Beacon The Beacon Measurement Mode field is the mode of Measurement beacon measurement, as defined in Table 9-87. The Mode results of the beacon measurement are included in the Location Track Notification frame, as described in 9.6.8.17 and 11.24.4.2. 2â€“8 Reserved 993 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.72 Nontransmitted BSSID Capability element The format of the Nontransmitted BSSID Capability element is shown in Figure 9-404. DMG Nontransmitted Nontransmitted BSSID DMG Element ID Length BSSID Capability BSS Capabilities Control Element Octets: 1 1 2 1 19 Figure 9-404â€”Nontransmitted BSSID Capability element format When transmitted by a DMG STA, the Nontransmitted BSSID Capability element includes the DMG BSS Control and the Nontransmitted BSSID DMG Capabilities Element fields. These fields are not present if this element is transmitted by non-DMG STAs. The Element ID and Length fields are defined in 9.4.2.1. The Nontransmitted BSSID Capability field contains the contents of the Capability Information field in beacons for the BSS when transmitted by a non-DMG STA. When transmitted by a DMG STA, the Nontransmitted BSSID Capability field is reserved. The Nontransmitted BSSID Capability element is included in the Nontransmitted BSSID Profile subelement of the Multiple BSSID element defined in 9.4.2.46. The use of the Multiple BSSID element is described in 11.11.14 and Nontransmitted BSSID advertisement procedures are described in 11.1.3.8. The DMG BSS Control field is defined in Figure 9-405. B0 B1 B2 B7 BSS Type Reserved Bits: 2 6 Figure 9-405â€”DMG BSS Control field format The BSS Type field is as defined in 9.4.1.47. The Nontransmitted BSSID DMG Capabilities Element field contains the DMG Capabilities element of the DMG STA. 9.4.2.73 SSID List element The format of the SSID List element is shown in Figure 9-406. Element ID Length SSID List Octets: 1 1 variable Figure 9-406â€”SSID List element format The Element ID and Length fields are defined in 9.4.2.1. 994 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The SSID List field is a list of SSID elements for which the STA is requesting information. The SSID List element is included in Probe Request frames, as described in 9.3.3.10. The use of the SSID List element and frames is described in 11.1.4. 9.4.2.74 Multiple BSSID-Index element The format of the Multiple BSSID-Index element is shown in Figure 9-407. Element ID Length BSSID Index DTIM Period DTIM Count (optional) (optional) Octets: 1 1 1 0 or 1 0 or 1 Figure 9-407â€”Multiple BSSID-Index element format The Element ID and Length fields are defined in 9.4.2.1. The value of the Length field is 1 octet when the Multiple BSSID-Index element is included in the Probe Response frame and otherwise is three octets. The BSSID Index field is a value between 1 and 2nâ€“ 1 that identifies the nontransmitted BSSID, where n is a nonzero, positive integer value. The DTIM Period field indicates the DTIM period for the BSSID. This field is not present when the Multiple BSSID-Index element is included in the Probe Response frame. The DTIM Count field indicates the DTIM count for the BSSID. This field is not present when the Multiple BSSID-Index element is included in the Probe Response frame. The Multiple BSSID-index element is included in the nontransmitted BSSID profile element, as described in 11.1.3.8. The use of the Multiple BSSID element and frames is described in 11.11.14. 9.4.2.75 FMS Descriptor element The FMS Descriptor element defines information about group addressed BUs buffered at the AP. It is present in the Beacon frames when dot11FMSActivated is true. The format of the FMS Descriptor element is shown in Figure 9-408. zero or more zero or more FMS Counters FMSIDs Number of FMS Element ID Length FMS Counters FMSIDs Counters Octets: 1 1 1 n m Figure 9-408â€”FMS Descriptor element format The Element ID and Length fields are defined in 9.4.2.1. The Number of FMS Counters field defines the number of FMS Counters fields that are contained in the FMS Descriptor element. The FMS Counters field contains zero or more FMS Counters. The format of the FMS Counter is shown in Figure 9-409. When one or more FMS streams are accepted at the AP, at least one FMS counter is present in the FMS Descriptor element. A maximum of eight FMS counters are permitted. The FMS counters are used 995 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications by the non-AP STA to identify the DTIM beacon after which group addressed BUs assigned to a particular delivery interval are transmitted. A single FMS Counter is shared by all FMS streams that use the same delivery interval. B0 B2 B3 B7 FMS Counter ID Current Count Bits: 3 5 Figure 9-409â€”FMS Counter format The FMS Counter ID field is a 3- bit value that represents the counter ID assigned by the AP for a particular FMS stream. The Current Count field indicates how many DTIM Beacon frames (including the current one) appear before the next DTIM Beacon frame after which the group addressed BUs assigned to a particular delivery interval are scheduled to be transmitted. The FMSIDs field contains zero or more FMSIDs. Each FMSID is a 1-octet identifier assigned by the AP. Inclusion of an FMSID indicates the AP has buffered BUs for the corresponding group addressed stream that is scheduled for transmission immediately after the DTIM Beacon frame. The FMS Descriptor element is included in Beacon frames, as described in 9.3.3.3. The use of the FMS Descriptor element and frames is described in 11.2.3.16. 9.4.2.76 FMS Request element The FMS Request element defines information about the group addressed frames being requested by the non-AP STA. The format of FMS Request element is shown in Figure 9-410. Element ID Length FMS Token FMS Request Subelements Octets: 1 1 1 variable Figure 9-410â€”FMS Request element format The Element ID and Length fields are defined in 9.4.2.1. The FMS Token field contains a unique identifier for the FMS Stream Set that is the set of FMS subelements specified in the request. If this is a new request, then the FMS Token field is set to 0. Otherwise, the FMS Token field is set to the value assigned by the AP in the FMS Response element. The FMS Request Subelements field contains one or more FMS Request subelements described in Table 9- 196. The format of the FMS subelement is shown in Figure 9-411. The Subelement ID field is 1 to uniquely identify this subelement as the FMS subelement. The Length field is defined in 9.4.3. 996 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-196â€”Optional subelement IDs for FMS Request subelements Subelement ID Subelement name 0 Reserved 1 FMS subelement 2â€“220 Reserved 221 Vendor Specific subelement 222â€“255 Reserved one or more TCLAS Elements TCLAS Max Subelement Length Delivery Delivery Rate FMSID TCLAS Processing ID Interval Identification Elements Element Interval (optional) Octets: 1 1 1 1 4 1 variable 0 or 3 Figure 9-411â€”FMS subelement format The Delivery Interval field defines the periodicity of stream transmission in units of DTIMs. The default value is 1. The value set to 0 indicates that requesting non-AP STA does not use the FMS stream identified by the TCLAS elements anymore. The Max Delivery Interval field defines the maximum delivery interval the non-AP STA supports for the requested stream in units of DTIMs. The value set to 0 indicates that the non-AP STA is willing to accept any maximum delivery interval supported by the AP. The Rate Identification field specifies the data rate as described in 9.4.1.33, at which the STA requests to receive group addressed frames. If the STA does not request a particular multicast rate, the Rate Identification field is 0. The FMSID field contains a unique identifier for this stream. If this is a new request, the FMSID field is reserved. Otherwise, the FMSID is set to the value assigned by the AP in the FMS Response element. The TCLAS Elements field contains one or more TCLAS elements to specify the traffic filter as defined in 9.4.2.31. The number of TCLAS elements is limited and the total size of the FMS Request element is less than or equal to 255 octets. The TCLAS Processing Element field is optionally present and defines how multiple TCLAS elements are processed as defined in 9.4.2.33. The FMS Request element is included in FMS Request frames, as described in 9.6.14.11. The use of the FMS Request element and frames is described in 11.2.3.16. The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26). 997 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.77 FMS Response element The FMS Response element provides information about the delivery of group addressed frames. The format of the FMS Response element is shown in Figure 9-412. Element ID Length FMS Token FMS Response Subelements Octets: 1 1 1 variable Figure 9-412â€”FMS Response element format The Element ID and Length fields are defined in 9.4.2.1. The FMS Token field is assigned by the AP for the set of FMS streams that share the counter identified by the FMS Counter ID maintained in the AP. The FMS Response Subelements field contains one or more FMS Response subelements described in Table 9-197. Table 9-197â€”Optional subelement IDs for FMS Response subelements Subelement ID Subelement name 0 Reserved 1 FMS Status subelement 2 TCLAS Status subelement 3â€“220 Reserved 221 Vendor Specific subelement 222â€“255 Reserved The format of the FMS Status subelement is shown in Figure 9-413. Max Rate Subelement Element Delivery FMS Multicast ID Length Status Interval Delivery FMSID Counter Identifica Address Interval tion Octets: 1 1 1 1 1 1 1 4 6 Figure 9-413â€”FMS Status subelement format The Subelement ID field is 1 to uniquely identify this subelement as the FMS Status subelement. The Length field is defined in 9.4.3. The Element Status field indicates the status of STAâ€™s requested delivery interval, as indicated in Table 9-198, provided by the AP. 998 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-198â€”FMS Element Status and TFS Response Status definition Value Description 0 Accept 1 Deny, due to request format error or ambiguous classifier. 2 Deny, due to lack of resources on the AP. 3 Deny, due to requested classifier(s) matching 2 or more existing streams on different intervals. 4 Deny, by policy, requested stream or filter is not permitted to participate in the service. 5 Deny, reason unspecified. 6 Alternate proposed, due to existing stream with different delivery interval. 7 Alternate proposed, due to policy limits on the AP. 8 Alternate proposed, because the AP changed the delivery interval. 9 Multicast rate changes not allowed. 10 Terminate, due to an AP policy change. 11 Terminate, due to lack of resources of the AP. 12 Terminate, due to other FMS stream with higher priority. 13 Alternate proposed, because the AP changed the maximum delivery interval. 14 Alternate proposed, because the AP is unable to provide requested TCLAS-based classifiers. 15â€“255 Reserved The Delivery Interval field defines the minimum integer of DTIM periods between successive transmissions of frames for the stream corresponding to that FMSID. The Max Delivery Interval field defines the maximum delivery interval the AP uses for the stream corresponding to FMSID. The value set to 0 indicates that the AP has no maximum delivery interval for the stream identified by FMSID. The FMSID field is assigned by the AP and provides a unique identifier for this stream within the BSS. The format of the FMS Counter field is shown in Figure 9-409. The FMS Counter ID field of the FMS Counter field is defined in 9.4.2.75. The Current Count field of the FMS Counter field is reserved in the FMS Status subelement. The Rate Identification field specifies the data rate as described in 9.4.1.33 to be used for the multicast service. If the value of the Rate Identification field is 0 then the data rate is undefined. The Multicast MAC Address field contains the MAC address of the multicast traffic to which this FMS response relates. The format of the TCLAS Status subelement is shown in Figure 9-414. 999 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications one or more TCLAS Elements Subelement TCLAS Processing Length FMSID TCLAS Elements ID Element (optional) Octets: 1 1 1 variable 0 or 3 Figure 9-414â€”TCLAS Status subelement format The Subelement ID field is 2 to uniquely identify this subelement as the TCLAS Status subelement. The Length field is defined in 9.4.3. The FMSID field is assigned by the AP and provides a unique identifier for this stream within the BSS. The TCLAS Elements field contains one or more TCLAS elements to specify the traffic filter as defined in 9.4.2.31. The number of TCLAS elements is limited and the total size of the FMS Response element is less than or equal to 255 octets. The TCLAS Processing Element field is optionally present and defines how multiple TCLAS elements are processed as defined in 9.4.2.33. The FMS Response element is included in FMS Response frames, as described in 9.6.14.12. The use of the FMS Response element and frames is described in 11.2.3.16. The Vendor Specific subelements have the same format as their corresponding elements (see 9.4.2.26). 9.4.2.78 QoS Traffic Capability element The QoS Traffic Capability element provides information about types of traffic generated by a non-AP QoS STA and is used by a QoS AP to indicate the access categories of associated non-AP QoS STAs. The format of the QoS Traffic Capability element is shown in Figure 9-415. QoS Traffic Capability AC STA Count List Element ID Length Bitmask/Flags (optional) Total number of nonzero bits in Bits 0â€“1 of QoS Octets: 1 1 1 Traffic Capability Bitmask/Flags field Figure 9-415â€”QoS Traffic Capability element format The Element ID and Length fields are defined in 9.4.2.1. The value of the Length field is 1 + n, where n equals the total number of nonzero bits in Bits 0â€“1 of the QoS Traffic Capability Bitmask/Flags field. The format of QoS Traffic Capability Bitmask/Flags field is defined in Table 9-199. Bits 0â€“1 serve as QoS Traffic Capability Bitmask. The bitmask indicates the AC values that have the station count specified in the following AC STA Count List. An AP sets the bit to 1 to indicate that the station count for the corresponding AC is present in the AC STA Count List field. An AP sets the bit to 0 to indicate that the station count for the corresponding AC is not present in the AC STA Count List field. Bits 0â€“1 are reserved in a transmission to an AP. 1000 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-199â€”QoS Traffic Capability Bitmask/Flags definition Bit Description 0 AC_VO 1 AC_VI 2 Reserved 3 Reserved 4 UP 4 Traffic 5 UP 5 Traffic 6 UP 6 Traffic 7 Reserved Bits 4â€“6 serve as QoS Traffic Capability Flags. Each of Bits 4â€“6 serves as a flag for a non-AP STA to indicate application requirements about the user priorities of the traffic it generates. A non-AP STA sets the bit to 1 to indicate the existence of an application that requires generation of traffic belonging to the corresponding user priority (UP). A non-AP STA sets the bit to 0 to indicate that such application does not exist. Bits 4â€“6 are reserved in a transmission from an AP. Bits 2â€“3 and Bit 7 are reserved. The AC STA Count List comprises a sequence of STA Count fields corresponding to the nonzero bits in the Bits 0â€“1 of the QoS Traffic Capability Bitmask/Flags field. The STA Count field is 1 octet long and contains an unsigned integer, encoded according to 9.2.2. The STA Count field specifies the number of associated QoS STAs that have indicated QoS traffic capability of the corresponding AC. If the number of STAs is greater than 255, the STA Count field is 255. The AC STA Count List field is present only when the QoS AP transmits the QoS Traffic Capability element. The QoS Traffic Capability element is included in Beacon frames, as described in 9.3.3.3; Probe Response frames, as described in 9.3.3.11; Association Request frames, as described in 9.3.3.6; and Reassociation Request frames, as described in 9.3.3.8. 9.4.2.79 BSS Max Idle Period element The BSS Max Idle Period element contains the time period a non-AP STA can refrain from transmitting frames to the AP before the AP disassociates the STA due to inactivity. The format of the BSS Max Idle Period element is shown in Figure 9-416. Element ID Length Max Idle Period Idle Options Octets: 1 1 2 1 Figure 9-416â€”BSS Max Idle Period element format The Element ID and Length fields are defined in 9.4.2.1. The Max Idle Period field indicates the idle timeout limit, as described in 11.24.13. The Idle Options field indicates the options associated with the BSS Idle capability. The Idle Options field is shown in Figure 9-417. 1001 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B0 B1-B7 Protected Keep-Alive Reserved Required Bits: 1 7 Figure 9-417â€”Idle Options field The Protected Keep-Alive Required subfield is set to 1 to indicate that only a protected frame indicates activity. The Protected Keep-Alive Required subfield is set to 0 to indicate that either an unprotected or a protected frame indicates activity. The BSS Max Idle Period element is included in Association Response frames, as described in 9.3.3.7, and Reassociation Response frames, as described in 9.3.3.9. The use of the BSS Max Idle Period element and frames is described in 11.24.13. 9.4.2.80 TFS Request element The TFS Request element defines information about the traffic filters that are enabled at the AP for the requesting non-AP STA. The format of the TFS Request element is defined in Figure 9-418. one or more TFS Request subelements TFS Action TFS Request Element ID Length TFS ID Code Subelements Octets: 1 1 1 1 variable Figure 9-418â€”TFS Request element format The Element ID and Length fields are defined in 9.4.2.1. The TFS ID field is assigned by the STA and provides a unique identifier for the traffic filter set specified by the TFS Request Subelements field. The TFS Action Code field defines the actions taken at the AP when a frame matches a traffic filter set. The functions of the bits in this field are shown in Table 9-200. Table 9-200â€”TFS Action Code field values Bit(s) Name Notes 0 Delete After Setting this field to 1for any traffic filter set indicates all traffic filter sets established at Match the AP for the non-AP STA are deleted when a frame matches any of the traffic filter sets established for the non-AP STA. A value of 0 for this field indicates no deletion of the traffic filter set upon a match. 1 Notify Setting this field to 1 indicates the STA is to be sent a TFS Notify frame upon the first frame matching to the traffic filter set or the first frame match after the AP receives a Notify Response frame containing the corresponding TFS ID. Setting this field to 0 indicates the AP does not send TFS Notify frame to the requesting STA. 2â€“7 Reserved All other bits are reserved. 1002 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The TFS Request Subelements field contains one or more TFS Request subelements described in Table 9-201. The subelement format and ordering of subelements are defined in 9.4.3. The Subelement ID field values for the defined subelements are shown in Table 9-201. Each TFS Request subelement specifies one traffic filter. Using multiple TFS Request subelements in a TFS Request element is the equivalent to a logical AND operation on the match conditions of each TFS Request subelement. Table 9-201â€”Optional subelement IDs for TFS Request parameters Subelement ID Subelement name 1 TFS subelement 221 Vendor Specific subelement 0, 2 to 220, 222 to 255 Reserved In a TFS Response element, the number of the response subelements is the same as the number of the TFS Request subelements in the corresponding TFS Request element, where the TFS Response subelements appear in the same order as the corresponding TFS Request subelements in the corresponding TFS Request frame. The format of the TFS subelement is shown in Figure 9-419. one or more TCLAS Elements Subelement ID Length TCLAS Elements TCLAS Processing Element (optional) Octets: 1 1 variable 0 or 3 Figure 9-419â€”TFS subelement format The Subelement ID field uniquely identifies this subelement to be the TFS subelement. The Length field is defined in 9.4.3. The TCLAS Elements field contains one or more TCLAS elements, each specifying a set of filtering parameters as defined in 9.4.2.31. The number of TCLAS elements is limited and the total size of the TFS Request element is less than 255 octets. The TCLAS Processing Element field is optionally present and defines how multiple TCLAS elements are processed as defined in 9.4.2.33. The format of the Vendor Specific subelement for a TFS Request element is shown in Figure 9-420. Subelement ID Length Vender Specific Octets: 1 1 variable Figure 9-420â€”TFS Request Vendor Specific subelement format 1003 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Subelement ID field uniquely identifies this subelement to be the TFS Request subelement. The Length field is defined in 9.4.3. The Vendor Specific field contains the vendor specific information. The TFS Request element is included in TFS Request frames, as described in 9.6.14.15, and WNM Sleep Mode Request frames, as described in 9.6.14.19. The use of the TFS Request element and frames is described in 11.24.12. 9.4.2.81 TFS Response element The TFS Response element defines information about the status of the requested filtering parameters. The format of the TFS Response element is defined in Figure 9-421. one or more TFS Response subelements TFS Response Element ID Length TFS ID Subelements Octets: 1 1 1 variable Figure 9-421â€”TFS Response element format The Element ID and Length fields are defined in 9.4.2.1. The TFS ID field indicates the unique ID for the TFS traffic filter set. The TFS Response Subelements field contains one or more TFS Response subelements. The subelement format and ordering of subelements are defined in 9.4.3. The Subelement ID field values for the defined subelements are shown in Table 9-202. In a TFS Response element, the number of the response subelements is the same as the number of the TFS Request subelements in the corresponding TFS Request element, where the TFS Response subelements appear in the same order as the corresponding TFS Request subelements in the corresponding TFS Request frame. Table 9-202â€”Optional subelement IDs for TFS Response parameters Subelement ID Subelement name 1 TFS Status subelement 221 Vendor Specific subelement 0, 2â€“220, 222â€“255 Reserved A TFS Status subelement contains the information as defined in Figure 9-422. 1004 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications TFS Subelement ID Length TFS Response Subelements Status (optional) Octets: 1 1 1 variable Figure 9-422â€”TFS Status subelement format The Length field is defined in 9.4.3. The TFS Response Status field indicates the status returned by the AP responding to the STAâ€™s requested traffic filter, as indicated in Table 9-198. If present, the TFS Subelements field contains one or more TFS Request subelements containing the alternative filtering parameters preferred by the AP. The format of the Vendor Specific subelement for a TFS Response element is shown in Figure 9-423. Subelement ID Length Vendor Specific Octets: 1 1 variable Figure 9-423â€”TFS Response Vendor Specific subelement format The Subelement ID field uniquely identifies this subelement to be the TFS Response subelement. The Length field is defined in 9.4.3. The Vendor Specific field contains the vendor specific information. The TFS Response element is included in TFS Response frames, as described in 9.6.14.16, and WNM Sleep Mode Response frames, as described in 9.6.14.20. The use of the TFS Response element and frames is described in 11.24.12. 9.4.2.82 WNM Sleep Mode element The WNM Sleep Mode element is used to enter and exit the WNM sleep mode. The format of the WNM Sleep Mode element is shown in Figure 9-424. Element Length Action WNM Sleep Mode WNM Sleep ID Type Response Status Interval Octets: 1 1 1 1 2 Figure 9-424â€”WNM Sleep Mode element format The Element ID and Length fields are defined in 9.4.2.1. The Action Type field is a number that identifies the type of WNM sleep mode request and response. The Action Types are shown in Table 9-203. 1005 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-203â€”Action Type definitions Name Action Type value Enter WNM sleep mode 0 Exit WNM sleep mode 1 Reserved 2â€“255 The WNM Sleep Mode Response Status field indicates the status returned by the AP responding to the non- AP STAâ€™s WNM sleep mode request as defined in Table 9-204. This field is valid only in the WNM Sleep Mode element in a WNM Sleep Mode Response frame and is reserved otherwise. Table 9-204â€”WNM Sleep Mode Response Status definition Value Description 0 Enter/Exit WNM sleep mode Accept. 1 Exit WNM sleep mode Accept, GTK/IGTK update required. 2 Denied. The AP is unable to perform the requested action. 3 Denied temporarily. The AP is unable to perform the requested action at the current time. The request can be submitted again at a later time. 4 Denied. Due to the pending key expiration. 5 Denied. The requested action was not granted due to other WNM services in use by the requesting STA. 6â€“255 Reserved The WNM Sleep Interval field is reserved if the Action Type field is 1. The WNM Sleep Interval field indicates to the AP how often a STA in WNM sleep mode wakes to receive Beacon frames, defined as the number of DTIM intervals. The value set to 0 indicates that the requesting non-AP STA does not wake up at any specific interval. The WNM Sleep Mode element is included in WNM Sleep Mode Request frames, as described in 9.6.14.19, and WNM Sleep Mode Response frames, as described in 9.6.14.20. The use of the WNM Sleep Mode element and frames is described in 11.2.3.18. 9.4.2.83 TIM Broadcast Request element The TIM Broadcast Request element contains information about the periodic TIM broadcast being requested by the non-AP STA. The format of the TIM Broadcast Request element is shown in Figure 9-425. TIM Broadcast Element ID Length Interval Octets: 1 1 1 Figure 9-425â€”TIM Broadcast Request element format 1006 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Element ID and Length fields are defined in 9.4.2.1. The TIM Broadcast Interval field is the number of beacon periods between TIM frame transmissions. A value of 0 terminates the use of TIM Broadcast for the requesting station. The TIM Broadcast Request element is included in TIM Broadcast Request frames, as described in 9.6.14.21; Association Request frames, as described in 9.3.3.6; and Reassociation Request frames, as described in 9.3.3.8. The use of the TIM Broadcast Request element and frames is described in 11.2.3.17. 9.4.2.84 TIM Broadcast Response element The TIM Broadcast Response element contains information about the periodic TIM broadcast by the AP. The format of the TIM Broadcast Response element is shown in Figure 9-426. TIM TIM High Rate Low Rate Element Broadcast Broadcast ID Length Status Interval Offset TIM Rate TIM Rate (optional) (optional) (optional) (optional) Octets: 1 1 1 0 or 1 0 or 4 0 or 2 0 or 2 Figure 9-426â€”TIM Broadcast Response element format The Element ID and Length fields are defined in 9.4.2.1. The value of the Length field is 1 or 10, depending on the presence of a TIM Broadcast schedule (TIM Broadcast Interval, TIM Broadcast Offset, High Rate TIM Rate, and Low Rate TIM Rate fields). The Status field indicates the status of the AP responding to the STAâ€™s requested delivery interval, as indicated in Table 9-205. Table 9-205â€”Status field values Field value Description 0 Accept 1 Accept, valid timestamp present in TIM frames 2 Denied 3 Overridden 4 Overridden, valid timestamp present in TIM frames 5â€“255 Reserved When the Status field is 0, 1, 3 or 4, the TIM Broadcast Interval field, TIM Broadcast Offset field, High Rate TIM Rate field, and Low Rate TIM Rate field are included in the TIM Broadcast Response element. The TIM Broadcast Interval field contains the number of beacon periods between scheduled TIM frame transmissions. The TIM Broadcast Offset field contains the offset in microseconds with a tolerance of Â± 4 Âµs relative to the TBTT for which a TIM frame is scheduled for transmission. The field contains a signed integer. 1007 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The High Rate TIM Rate field provides an indication of the rate that is used to transmit the high data rate TIM frame, in units of 0.5 Mb/s. A value of 0 indicates that the high rate TIM frame is not transmitted. The Low Rate TIM Rate field provides an indication of the rate that is used to transmit the low data rate TIM frame, in units of 0.5 Mb/s. A value of 0 indicates that the low rate TIM frame is not transmitted. The TIM Broadcast Response element is included in TIM Broadcast Response frames, as described in 9.6.14.22; Association Response frames, as described in 9.3.3.7; and Reassociation Response frames, as described in 9.3.3.9. The use of the TIM Broadcast Response element and frames is described in 11.2.3.17. 9.4.2.85 Collocated Interference Report element The Collocated Interference Report element contains some characteristics of the reported collocated interference. The Collocated Interference Report element is defined in Figure 9-427. Interference Interference Level Accuracy/ Element ID Length Report Period Level Interference Index Octets: 1 1 1 1 1 Interference Interference Interference Interference Start Time/Duty Center Interference Interval Burst Length Bandwidth Cycle Frequency Octets 4 4 4 4 2 Figure 9-427â€” Collocated Interference Report element format The Element ID and Length fields are defined in 9.4.2.1. The Report Period field contains an unsigned integer value in units of 200 TUs. If the Report Period field is a value that is greater than 0, then the reporting is periodic, and the field contains the period of sending the report. If the Report Period field is 0, then the reporting is not periodic, and a report is generated when the STA knows of a change in the collocated interference. See 11.24.9 for further details. The Interference Level field is a 2s complement signed integer indicating the maximum level of the collocated interference power in units of dBm over all receive chains averaged over a 4 s period during an interference period and across interference bandwidth. When the interference level is unknown, the field is +127 dBm. When the interference level is equal or greater than 126 dBm, the field is +126 dBm. If no collocated interference is present the field is â€“128 dBm. When the interference level is equal or lower than â€“ 127 dBm, the field is â€“127 dBm. The interference level is referenced to the antenna connector (see â€œantenna connectorâ€ in 3.1) used for reception, like RCPI. The Interference Level Accuracy/Interference Index field is shown in Figure 9-428. B0 B3 B4 B7 Expected Accuracy Interference Index Bits 4 4 Figure 9-428â€”Interference Level Accuracy/Interference Index field format 1008 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Expected Accuracy field represents an unsigned integer indicating the expected accuracy of the estimate of interference in dB with 95% confidence interval. If the Interference Level field is X (dBm) and the expected accuracy field is Y (dB), the actual interference level is in the range X â€“ Y to X +Y with the probability of 95%. The range of expected accuracy is from 0 dB to 14 dB. If accuracy is unknown or greater than 14 dB, then the Expected Accuracy field is 15. The Interference Index field indicates the interference index that is unique for each type of interference source. The field set to 0 indicates that no collocated interference is present. See 11.24.9 for further details. The Interference Interval field indicates the interval between two successive periods of interference in microseconds. When the interval between two successive periods of interference is variable the field is 232â€“1. When the interval between two successive periods of interference is equal or greater than 232â€“ 2 the field is 232â€“ 2. If no collocated interference is present, the field is 0. The Interference Burst Length field indicates the duration of each period of interference in microseconds. When the duration of each period of interference is variable the field is 232â€“ 1. When the duration of each period of interference is equal or greater than 232â€“ 2 the field is 232â€“ 2. If no collocated interference is pres- ent, the field is 0. The Interference Start Time/Duty Cycle field contains the least significant 4 octets (i.e., B0â€“B31) of the TSF timer at the start of the interference burst. When either the Interference Interval or the Interference Burst Length fields are set to 232â€“ 1, this field indicates the average duty cycle. The average duty cycle value is defined as follows: 32 T Average duty cycle = 2 â€“2 -----B- + 0.5 TI where TB is the average interference burst length TI is the average interference interval When the interference is nonperiodic or no collocated interference is present, the Interference Start Time field is 0. The Interference Center Frequency field indicates the center frequency of interference in units of 5 kHz. When center frequency is unknown, the center frequency of the STAâ€™s operating channel is reported. If no collocated interference is present the field is 0. The Interference Bandwidth field indicates the bandwidth in units of 5 kHz at the â€“3 dB roll-off point of the interference signal. When bandwidth of the interference signal is unknown, the field is 65 535. When bandwidth of the interference signal is equal or greater than 65 534 the field is 65 534. If no collocated interference is present, the field is 0. 9.4.2.86 Channel Usage element The Channel Usage element defines the channel usage information for BSSs that are not infrastructure BSSs or an off channel TDLS direct link. The format of the Channel Usage element is shown in Figure 9-429. 1009 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications zero or more entries Element Length Usage Channel ID Mode Entry Octets: 1 1 1 2n Figure 9-429â€”Channel Usage element format The Element ID and Length fields are defined in 9.4.2.1. The Usage Mode field is a number that identifies the usage of the recommended channels listed in the Operating Class/Channel Number pair fields. The Usage Mode definitions are shown in Table 9-206. Table 9-206â€”Usage Mode definitions Value Usage Mode 0 Noninfrastructure IEEE 802.11 network 1 Off-channel TDLS direct link 2â€“255 Reserved The Channel Entry field includes zero or more Operating Class and Channel fields. The format of the Operating Class and Channel fields is defined in 9.4.1.22. Operating Class and Channel fields can be grouped together to identify a noncontiguous channel as described in 9.4.2.71.3. The Channel Usage element can be included in Probe Request frames, as described in 9.3.3.10; Probe Response frames, as described in 9.3.3.11; Channel Usage Request frames, as described in 9.6.14.24; and Channel Usage Response frames, as described in 9.6.14.25. The use of the Channel Usage element and frames is described in 11.24.15. 9.4.2.87 Time Zone element The Time Zone element contains the local time zone of the AP. The format of the Time Zone element is shown in Figure 9-430. Element ID Length Time Zone Octets: 1 1 variable Figure 9-430â€”Time Zone element format The Element ID and Length fields are defined in 9.4.2.1. The format of the Time Zone field is as specified in 8.3 of IEEE Std 1003.1-2004: stdoffset[dst[offset][,start[/time],end[/time]]] 1010 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The length of the field is no less than 4 octets and no more than TZNAME_MAX, as defined in IEEE Std 1003.1-2004. The Time Zone field represents the time zone at the APâ€™s location. The encoding of the field is in ASCII characters as shown in the following Example-1. Example-1: EST5 Example-2: EST5EDT4,M3.2.0/02:00,M11.1.0/02:00 In the Example-2, the string is interpreted as a time zone that is normally five hours behind UTC, and four hours behind UTC during daylight saving time (DST), which runs from the second Sunday in March at 02:00 local time through the first Sunday in November at 02:00 local time. Normally, the time zone is abbreviated â€œESTâ€ but during DST it is abbreviated â€œEDT.â€ 9.4.2.88 DMS Request element The DMS Request element defines information about the group addressed frames to be transmitted as individual addressed frames. The format of the DMS Request element is shown in Figure 9-431. Element ID Length DMS Descriptor List Octets: 1 1 variable Figure 9-431â€”DMS Request element format The Element ID and Length fields are defined in 9.4.2.1. The DMS Descriptor List field contains one or more DMS Descriptors. The format of the DMS Descriptor is defined in Figure 9-432. zero or more TCLAS Elements TCLAS TSPEC DMS Request TCLAS Processing Optional DMSID Length Type Elements Element Element Subelements (optional) (optional) Octets: 1 1 1 variable 0 or 3 0 or 57 variable Figure 9-432â€”DMS Descriptor The DMSID field is set to 0 when the Request Type field is â€œAddâ€ as defined in Table 9-207; otherwise, the DMSID field is set to the nonzero value assigned by the AP STA to identify the DMS traffic flow. The DMS Length field is set to 1 + n, where n indicates the total length in octets of all of the TCLAS Elements, optional TCLAS Processing Element, optional TSPEC Element, and Optional Subelements fields contained in the DMS Descriptor field. The maximum value of the DMS Length field is 253. The Request Type field identifies the type of DMS request. The encoding of the Request Type field is shown in Table 9-207. 1011 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-207â€”DMS Request Type field Description Request Type field value Add 0 Remove 1 Change 2 Reserved 3â€“255 When the Request Type field contains â€œAdd,â€ the TCLAS Elements field contains one or more TCLAS elements to specify group addressed frames as defined in 9.4.2.31. When a GCR Request subelement is included in the DMS Descriptor and the Request Type field is equal to â€œAdd,â€ the TCLAS Elements field contains at least a TCLAS element with frame classifier type set to 0 (Ethernet parameters) to specify a destination group address as defined in 9.4.2.31. When the Request Type field contains any value other than â€œAdd,â€ the TCLAS Elements field contains zero TCLAS elements. When the Request Type field contains â€œAddâ€ and when there are two or more TCLAS elements present, the TCLAS Processing Element field contains one TCLAS Processing element to define how these TCLAS elements are to be processed, as defined in 9.4.2.33. Otherwise, the TCLAS Processing Element field contains zero TCLAS Processing elements. When the Request Type field contains â€œAddâ€ or â€œChange,â€ the TSPEC Element field optionally contains one TSPEC element to specify the characteristics and QoS expectations of the corresponding traffic flow as defined in 9.4.2.30. When a GCR Request subelement is included in the DMS Descriptor and the Request Type field is equal to â€œAddâ€ or â€œChange,â€ the TSPEC Element field contains one TSPEC element. Otherwise, the TSPEC Element field contains zero TSPEC elements. The Optional Subelements field contains zero or more subelements. The subelement format and ordering of subelements are defined in 9.4.3. The Subelement ID field values for the defined subelements are shown in Table 9-208. Table 9-208â€”Optional subelement IDs for DMS Descriptor Subelement ID Name Extensible 0 Reserved 1 GCR Request Yes 2â€“220 Reserved 221 Vendor Specific 222â€“255 Reserved Each DMS Descriptor contains zero or one GCR Request subelements. If present and the Request Type field is equal to â€œAddâ€ or â€œChange,â€ the GCR Request subelement indicates a request by a STA to respectively add or change the GCR service for a group addressed stream identified by the TCLAS element or by the DMSID in the DMS Descriptor. The format of the GCR Request subelement is shown in Figure 9-433. 1012 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B0 B7 B8 B15 B16 B19 B20 B23 GATS Retransmission Subelement ID Length Policy GCR Delivery Method Bits: 8 8 4 4 Figure 9-433â€”GCR Request subelement format The Length field is defined in 9.4.3. The GATS Retransmission Policy field is set to indicate the STAâ€™s preferred retransmission policy for the group address for which the GCR service is requested. The values are shown in Table 9-209. Table 9-209â€”GATS Retransmission Policy field values Value GATS retransmission policy Notes 0 No preference 1 DMS See 11.24.16.2. 2 GCR unsolicited retry See 11.24.16.3.6. 3 GCR Block Ack See 11.24.16.3.7. 4â€“15 Reserved The GCR Delivery Method field is set to indicate the STAâ€™s preferred delivery method for the group address for which the GCR service is requested. The values are shown in Table 9-210. Table 9-210â€”GCR Delivery Method field values Value GCR delivery method Notes 0 No preference 1 Non-GCR-SP See 11.24.16.3.1. 2 GCR-SP See 11.24.16.3.8. 3â€“15 Reserved The DMS Request element is included in DMS Request frames, as described in 9.6.14.26, and Reassociation Request frames, as described in 9.3.3.8. The use of the DMS Request element and frames is described in 11.24.16. 9.4.2.89 DMS Response element The DMS Response element provides the status information about the requested group addressed frames. The format of the DMS Response element is shown in Figure 9-434. 1013 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications one or more DMS Status field Element ID Length DMS Status List Octets: 1 1 variable Figure 9-434â€”DMS Response element format The Element ID and Length fields are defined in 9.4.2.1. The DMS Status List field contains one or more DMS Status field. The format of the DMS Status field is defined in Figure 9-435. zero or more TCLAS Elements Last TCLAS TSPEC DMS Response TCLAS Processing Optional DMSID Length Type Sequence Elements Element Element Subelements Control (optional) (optional) Octets: 1 1 1 2 variable 0 or 3 0 or 57 variable Figure 9-435â€”DMS Status field format The DMSID field is assigned by the AP and provides a unique identifier within the BSS for the DMS traffic flow identified by the TCLAS Elements, TCLAS Processing Element, and TSPEC Element fields. The uniqueness of the identifier is independent of the ordering of the TCLAS elements. In a mesh BSS, the DMSID field is assigned by a mesh STA that responds to a GCR request and is unique among all existing DMSIDs used by the mesh STA for its current GCR agreements. The value of the DMS Length field is set to 3 + n, where n indicates the total length in octets of all of the TCLAS Elements, optional TCLAS Processing Element, optional TSPEC Element, and Optional Subelements fields contained in the DMS Status field. When the Response Type field is set to â€œTerminate,â€ the value of the DMS Length field is set to 3. The maximum value of the DMS Length field is 253. The Response Type field indicates the response type returned by the AP responding to the non-AP STAâ€™s request or by a mesh STA responding to its peer mesh STAâ€™s request or indicates the DMS Status is an advertisement of an existing GCR service, as indicated in Table 9-211. Table 9-211â€”Response Type field values Field value Description Notes 0 Accept STA accepts the DMS or GCR request 1 Denied STA rejects the DMS or GCR request 2 Terminate STA terminates DMS previously accepted DMS or GCR request 3 GCR Advertise STA advertises a group addressed stream subject to an existing GCR agreement. 4â€“255 Reserved 1014 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications When the Last Sequence Control field is not supported the Last Sequence Control field is set to 65 535. When the Last Sequence Control field is supported and the Response Type field does not contain â€œTerminateâ€ or â€œGCR Advertise,â€ the Last Sequence Control field is reserved. When the Response Type field is â€œTerminateâ€ and the Last Sequence Control field is supported, Bit 0 to Bit 3 of the Last Sequence Control field is 0, and Bit 4 to Bit 15 of the Last Sequence Control field contains the sequence number of the last group addressed frame that the AP delivered to the non-AP STA that is the recipient of the DMS Response frame. If the Response Type field is â€œTerminateâ€ and the last frame received by the non-AP STA prior to DMS termination has not also been sent using a group addressed frame, the Last Sequence Control field is set to 65 534. When the Response Type field contains â€œAcceptâ€ or â€œDeniedâ€ and a GCR Response subelement is not included in the DMS Status field, the TCLAS Elements field contains one or more TCLAS elements to specify group addressed frames as defined in 9.4.2.31. When the Response Type field is equal to â€œAccept,â€ â€œDenied,â€ or â€œGCR Advertiseâ€ and a GCR Response subelement is included in the DMS Status field, the TCLAS Elements field contains at least one TCLAS element with frame classifier type set to 0 (Ethernet parameters) to specify a destination group address as defined in 9.4.2.31. Otherwise, the TCLAS Elements field contains zero TCLAS elements. When the Response Type field contains â€œAcceptâ€ or â€œDenied,â€ the TCLAS Processing Element field optionally contains one TCLAS Processing element to define how these TCLAS elements are to be processed, as defined in 9.4.2.33. When the Response Type field contains â€œTerminateâ€ or when there is only one TCLAS element, the TCLAS Processing Element field contains zero TCLAS Processing elements. When the Response Type field contains â€œAcceptâ€ or â€œDenied,â€ the TSPEC Element field optionally contains one TSPEC element to specify the characteristics and QoS expectations of the corresponding traffic flow as defined in 9.4.2.30. When a GCR Response subelement is included in the DMS Status field and the Response Type field is equal to â€œAccept,â€ â€œDenied,â€ or â€œGCR Advertise,â€ the TSPEC Element field contains one TSPEC element. Otherwise, the TSPEC Element field contains zero TSPEC elements. The Optional Subelements field contains zero or more subelements. The subelement format and ordering of subelements are defined in 9.4.3. The Subelement ID field values for the defined subelements are shown in Table 9-212. Table 9-212â€”Optional subelement IDs for DMS Status Subelement ID Name Extensible 0 Reserved 1 GCR Response Subelements 2â€“220 Reserved 221 Vendor Specific 222â€“255 Reserved The GCR Response subelement contains one of the following: â€” A response by an AP to a GCR request by a non-AP STA for GCR service for a group address â€” A response by a mesh STA to a GCR request by a peer mesh STA for GCR service for a group address â€” An unsolicited advertisement for the parameters of a group addressed stream subject to the GCR service 1015 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The format of the GCR Response subelement is shown in Figure 9-432. Subelement GATS GCR Delivery GCR Schedule Length Retransmission Concealment ID Policy Method Address Element Octets: 1 1 0 or 1 0 or 1 0 or 6 0 or 14 Figure 9-436â€”GCR Response subelement format The GATS Retransmission Policy, GCR Delivery Method, and GCR Concealment Address fields are present when the Response Type field is not equal to â€œDeniedâ€; otherwise, they are omitted. The Schedule Element field is optionally present when the Response Type field is not equal to â€œDenied.â€ The GATS Retransmission Policy field is set to indicate the current GCR retransmission policy for the group address for which the GCR service is requested. The values are shown in Table 9-209. The GCR Delivery method field is set to indicate the current GCR Delivery method for the group address for which the GCR service is requested. The values are shown in Table 9-210. The GCR Concealment Address field, when present, indicates the GCR concealment address, as described in 11.24.16.3.5. The Schedule Element field is present if the GCR delivery method is equal to GCR-SP. It indicates the current SP schedule for the group addressed stream (see 9.4.2.34). The DMS Response element is included in DMS Response frames, as described in 9.6.14.27, and Reassociation Response frames, as described in 9.3.3.9. The use of the DMS Response element and frames is described in 11.24.16. 9.4.2.90 Destination URI element The Destination URI element contains URI and ESS Detection Interval values from the requesting STA that the responding STA can be used to deliver Event or Diagnostic Report frames. The format of the Destination URI element is given in Figure 9-437. ESS Detection Element ID Length URI Interval Octets: 1 1 1 1â€“253 Figure 9-437â€”Destination URI element format The Element ID and Length fields are defined in 9.4.2.1. The ESS Detection Interval field is defined in 9.4.2.71.2 and its use for Event and Diagnostic requests is described in 11.24.2 and 11.24.3. The URI field specifies the destination URI for Event and Diagnostic reports using the format defined in IETF RFC 3986. The URI field value is limited to 253 octets. The Destination URI element is included as the last element in an Event or Diagnostic Request frame. The Destination URI element is included in Event Request frames, as described in 9.6.14.2, or Diagnostic Request frames, as described in 9.6.14.4. 1016 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Use of the Destination URI element in an Event Request frame is described in 11.24.2.1. Use of the Destination URI element in a Diagnostic Request frame is described in 11.24.3.1. 9.4.2.91 U-APSD Coexistence element The U-APSD coexistence provides the duration of requested transmission during a U-APSD service period. The format of the U-APSD Coexistence element is shown in Figure 9-438. Element ID Length TSF 0 Offset Interval/ Optional Duration Subelements Octets: 1 1 8 4 variable Figure 9-438â€”U-APSD Coexistence element format The Element ID and Length fields are defined in 9.4.2.1. A nonzero value of the TSF 0 Offset field is the number of microseconds since TSF time 0 when the non-AP STA knew the start of interference. The AP uses the TSF 0 Offset field together with the Interval/Duration field to enqueue frames for transmission to the non-AP STA using the procedures as described in 11.2.3.5.2. A TSF 0 Offset field value of 0 indicates the non-AP STA requests the AP transmit frames to the non-AP STA using the procedure described in 11.2.3.5.2 for the case where TSF 0 Offset is equal to 0. The Interval/Duration field is defined as follows: â€” When the TSF 0 Offset is 0, the Interval/Duration field is the number of microseconds during the U- APSD service period when the AP transmits frames to the non-AP STA as described in 11.2.3.5.2. â€” When the TSF 0 Offset is nonzero, the Interval/Duration field is the number of microseconds between the start of consecutive interference bursts. The Interval/Duration field value of 0 is reserved. The Optional Subelements field contains zero or more subelements. The subelement format and ordering of subelements are defined in 9.4.3. The Subelement ID field values for the defined subelements are shown in Table 9-213. Table 9-213â€”Optional subelement IDs for U-APSD coexistence Subelement ID Name Extensible 0â€“220 Reserved 221 Vendor Specific 222â€“255 Reserved 9.4.2.92 Interworking element The Interworking element contains information about the interworking service capabilities of a STA as shown in Figure 9-439. 1017 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Access Element ID Length Network Venue Info HESSID (optional) (optional) Options Octet 1 1 1 0 or 2 0 or 6 s: Figure 9-439â€”Interworking element format The Element ID and Length fields are defined in 9.4.2.1. The format of Access Network Options field is shown in Figure 9-440. Bits: B0 B3 B4 B5 B6 B7 Access Network Internet ASRA ESR UESA Type Figure 9-440â€”Access Network Options field format A non-AP STA sets Internet, ASRA, ESR, and UESA fields to 0 when including the Interworking element in the Probe Request frame. A non-AP STA sets the Internet, ASRA and ESR bits to 0 when including the Interworking element in (Re)Association Request frames. A mesh STA sets the Internet bit to 0 when including the Interworking element in Mesh Peering Open frames. In (Re)Association Request frames, a non-AP STA sets the UESA bit according to the procedures in 11.3.5. The access network types are shown in Table 9-214. The Access Network Type field is set by the AP or the mesh STA to advertise its access network type to non-AP STAs. A non-AP STA uses this field to indicate the desired access network type in an active scan. See R.2 for informative text on usage of fields contained within the Interworking element. Table 9-214â€”Access network type Access Meaning Description network type 0 Private network Nonauthorized users are not permitted on this network. Examples of this access network type are home networks and enterprise networks, which might employ user accounts. Private networks do not necessarily employ encryption. 1 Private network Private network but guest accounts are available. Example of this access with guest access network type is enterprise network offering access to guest users. 2 Chargeable The network is accessible to anyone, however, access to the network requires public network payment. Further information on types of charges might be available through other methods (e.g., IEEE Std 802.21, http/https redirect or DNS redirection). Examples of this access network type is a hotspot in a coffee shop offering internet access on a subscription basis or a hotel offering in-room internet access service for a fee. 3 Free public The network is accessible to anyone and no charges apply for the network network use. An example of this access network type is an airport hotspot or municipal network providing free service. 4 Personal device A network of personal devices. An example of this type of network is a network camera attaching to a printer, thereby forming a network for the purpose of printing pictures. 5 Emergency A network dedicated and limited to accessing emergency services. services only network 1018 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-214â€”Access network type (continued) Access Meaning Description network type 6 to 13 Reserved Reserved 14 Test or The network is used for test or experimental purposes only. experimental 15 Wildcard Wildcard access network type Bit 4 is the Internet field. The AP or mesh STA sets this field to 1 if the network provides connectivity to the Internet; otherwise it is set to 0 indicating that it is unspecified whether the network provides connectivity to the Internet. Bit 5 is the Additional Step Required for Access (ASRA) field. It is set to 1 by the AP to indicate that the network requires a further step for access. For more information, refer to Network Authentication Type Information in 9.4.5.6. A mesh STA uses the ASRA field as an emergency indicator. If a mesh STA requires emergency services, the ASRA field is set to 1; otherwise it is set to 0. See 11.25.6. Bit 6 is the ESR (emergency services reachable) field. It is set to 1 by the AP or mesh STA to indicate that emergency services are reachable through the AP or mesh STA; otherwise it is set to 0 indicating that it is unable to reach the emergency services. See 11.25.6. Bit 7 is the UESA (unauthenticated emergency service accessible) field. When set to 0, this field indicates that no unauthenticated emergency services are reachable through this AP or mesh STA. When set to 1, this field indicates that higher layer unauthenticated emergency services are reachable through this AP or mesh STA. A STA uses the Interworking element with the UESA bit set to 1 to gain unauthenticated access to a BSS to access emergency services. A mesh STA uses the Interworking element with the UESA bit set to 1 to gain unauthenticated access to another mesh STA to access emergency services. See 11.3.5. The Venue Info field is defined in 9.4.1.35. The HESSID field, which is the identifier for a homogeneous ESS, specifies the value of HESSID; see 11.25.2. A STA uses this field to indicate the target HESSID in an active scan per 11.1.4. The HESSID field for an AP is set to dot11HESSID. This optional field is not used by mesh STAs. 9.4.2.93 Advertisement Protocol element The Advertisement Protocol element contains information that identifies a particular advertisement protocol and its corresponding Advertisement Control. The Advertisement Protocol element format is shown in Figure 9-441. Advertisement Advertisement Element Protocol Tuple ID Length Protocol Tuple ... #n #1 (optional) Octets: 1 1 variable variable Figure 9-441â€”Advertisement Protocol element format 1019 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Element ID and Length fields are defined in 9.4.2.1. The format of Advertisement Protocol Tuple field is shown in Figure 9-442. Query Response Advertisement Info Protocol ID Octets: 1 variable Figure 9-442â€”Advertisement Protocol Tuple field format The format of Query Response Info field is shown in Figure 9-443. Bits: B0 B6 B7 Query Response Length Limit PAME-BI Figure 9-443â€”Query Response Info field format The Query Response Info field is defined as follows: â€” The Query Response Length Limit field indicates the maximum number of octets a STA will transmit in the Query Response field contained within one or more GAS Comeback Response frames. If the value of the Query Response Length Limit field is larger than the maximum MMPDU size, the Query Response will span multiple MMPDUs. The Query Response Length Limit field is encoded as an integer number of 256 octet units. A value of 0 is not permitted. A value of 0x7F means the maximum limit enforced is determined by the maximum allowable number of fragments in the GAS Query Response Fragment ID (see 9.4.1.34). The Query Response Length Limit field is reserved in a transmission from the requesting STA to the responding STA. â€” Bit 7, the Preassociation Message Exchange BSSID Independent (PAME-BI) bit, is used by an AP to indicate whether the Advertisement Server, which is the non-AP STAâ€™s peer for this Advertisement Protocol, returns a Query Response that is independent of the BSSID used for the GAS frame exchange. This bit is set to 1 to indicate the Query Response is independent of the BSSID; it is set to 0 to indicate that the Query Response may be dependent on the BSSID. See 11.25.3.2 for further information. Bit 7 is reserved for non-AP STAs. The Advertisement Protocol ID is a variable-length field. When this field contains a vendor-specific Advertisement Protocol ID, then this field will be structured per the Vendor Specific element defined in 9.4.2.26, where the Element ID of the Vendor Specific element of 9.4.2.26 is the first octet of the field and contains the vendor-specific value for Advertisement Protocol ID defined in Table 9-215; otherwise its length is 1 octet and its value is one of the values in Table 9-215. When one or more vendor-specific tuples are included in the Advertisement Protocol element, their total length needs to be constrained such that the total length of all of the Advertisement Protocol Tuple fields (both vendor specific and otherwise) is less than or equal to 255 octets. Table 9-215â€”Advertisement protocol ID definitions Name Value Access network query protocol (ANQP) 0 MIH Information Service 1 1020 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-215â€”Advertisement protocol ID definitions Name Value MIH Command and Event Services Capability Discovery 2 Emergency Alert System (EAS) 3 Registered location query protocol (RLQP) 4 Reserved 5â€“220 Vendor Specific 221 Reserved 222â€“255 â€” ANQP supports information retrieval from an Advertisement Server. ANQP is a protocol used by a requesting STA to query another STA (i.e., the receiving STA might respond to queries with or without proxying the query to a server in an external network). See 11.25.3.3 for information on ANQP procedures. â€” MIH Information Service is a service defined in IEEE Std 802.21-2008 to support information retrieval from an information repository. â€” MIH Command and Event Services capability discovery is a mechanism defined in IEEE Std 802.21 (see IEEE Std 802.21-2008) to support discovering capabilities of command service and event service entities in a STA or an external network. â€” The EAS allows a network to disseminate emergency alert notifications from an external network to non-AP STAs. EAS uses the message format as defined in OASIS EDXL. â€” The RLQP supports information retrieval from a RLSS. RLQP is a protocol used by a requesting STA to query another STA (i.e., the receiving STA can respond to queries with and without proxying the query to a server in an external network). 11.25 for information on RLQP procedures. â€” Advertisement Protocol ID 221 is reserved for Vendor Specific Advertisement Protocols. When the Advertisement Protocol ID is equal to 221, the format of the Advertisement Protocol ID subfield follows the format of the Vendor Specific element in 9.4.2.26. 9.4.2.94 Expedited Bandwidth Request element The Expedited Bandwidth Request element is transmitted from a non-AP STA to an AP in an ADDTS Request frame containing a TSPEC element and provides usage information for the bandwidth request. The Expedited Bandwidth Request element format is shown in Figure 9-444. Element ID Length Precedence Level Octets: 1 1 1 Figure 9-444â€”Expedited Bandwidth Request element format The Element ID and Length fields are defined in 9.4.2.1. The Precedence Level field is provided in Table 9-216. The precedence levels are derived from the 3rd Generation Partnership Project (3GPP) document 3GPP TS 22.067 [B3]. 1021 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-216â€”Precedence Level field description Precedence level value Description 0â€“15 Reserved 16 Emergency call, defined in NENA 08-002 [B56] 17 First responder (public) 18 First responder (private) 19 MLPP Level A 20 MLPP Level B 21 MLPP Level 0 22 MLPP Level 1 23 MLPP Level 2 24 MLPP Level 3 25 MLPP Level 4 26â€“255 Reserved The first responders (public) in Table 9-216 are government agencies or entities acting on behalf of the government, and the first responders (private) are private entities, such as individuals or companies. 9.4.2.95 QoS Map element The QoS Map element is transmitted from an AP to a non-AP STA in a (Re)Association Response frame or a QoS Map Configure frame and provides the mapping of higher layer quality-of-service constructs to User Priorities defined by transmission of Data frames in this standard. This element maps the higher layer priority from the DSCP field used with the Internet Protocol to User Priority as defined by this standard. The QoS Map element is shown in Figure 9-445. DSCP DSCP UP 0 UP 1 UP 2 UP 7 Element Length Exception ... Exception DSCP DSCP DSCP ... DSCP ID #1 #n (optional) (optional) Range Range Range Range Octets: 1 1 0 or 2 0 or 2 2 2 2 2 Figure 9-445â€”QoS Map element format The Element ID and Length fields are defined in 9.4.2.1. The Length field is set to 16+2Ã—n, where n is the number of DSCP Exception fields in the QoS Map element. DSCP Exception fields are optionally included in the QoS Map element. If included, the QoS Map element has a maximum of 21 DSCP Exception fields. The format of the exception field is shown in Figure 9-446. DSCP Value User Priority Octets: 1 1 Figure 9-446â€”DSCP Exception format 1022 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The DSCP value in the DSCP Exception field is in the range 0 to 63, or 255; the User Priority value is in the range 0 to 7. â€” When a non-AP STA begins transmission of a Data frame containing the Internet Protocol, it matches the DSCP field in the IP header to the corresponding DSCP value contained in this element. The non-AP STA first attempts to match the DSCP value to a DSCP exception field and uses the UP from the corresponding UP in the same DSCP exception field if successful; if no match is found then the non-AP STA attempts to match the DSCP field to a UP n DSCP Range field, and uses the n as the UP if successful; and otherwise uses a UP of 0. â€” Each DSCP Exception field has a unique DSCP Value. DSCP Low Value DSCP High Value Octets: 1 1 Figure 9-447â€”DSCP Range description The QoS Map element has a DSCP Range field corresponding to each of the 8 user priorities. The format of the range field is shown in Figure 9-447. The DSCP Range value is between 0 and 63 inclusive, or 255. â€” The DSCP range for each user priority is nonoverlapping. â€” The DSCP High Value is greater than or equal to the DSCP Low Value. â€” If the DSCP Range high value and low value are both equal to 255, then the corresponding UP is not used. 9.4.2.96 Roaming Consortium element The Roaming Consortium element contains information identifying the roaming consortium and/or SSP whose security credentials can be used to authenticate with the AP transmitting this element; see 11.25.8. The elementâ€™s format is shown in Figure 9-448. Number of OI OI OI OI Element ID Length ANQP #1 and #2 #2 #3 OIs Lengths #1 (optional) (optional) Octets: 1 1 1 1 variable variable variable Figure 9-448â€”Roaming Consortium element format The Element ID and Length fields are defined in 9.4.2.1. The format of the Number of ANQP OIs field is a one-octet unsigned integer whose value is the number of additional roaming consortium organization identifiers (OIs) obtainable via ANQP. A value of 0 means that no additional OIs are returned in response to an ANQP request for the Roaming Consortium list. A value of 255 means that 255 or more additional OIs are obtainable via ANQP. The OI #1 and #2 Lengths field format is shown in Figure 9-449. â€” The value of the OI #1 Length subfield is the length in octets of the OI #1 field. â€” The value of the OI #2 Length subfield is the length in octets of the OI #2 field. If the OI #2 field is not present, the value of the OI #2 Length subfield is set to 0. NOTEâ€”When there are three OIs, the OI #3 Length is calculated by subtracting sum of 2 plus the value of the OI #1 Length subfield plus the value of the OI #2 Length subfield from the value of the Length field. 1023 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Bits: B0 B3 B4 B7 OI #1 Length OI #2 Length Figure 9-449â€”OI #1 and #2 Lengths field format The OI field is defined in 9.4.1.32. Each OI identifies a roaming consortium (group of SSPs with inter-SSP roaming agreement) or a single SSP. The value of the OI(s) in this table are equal to the value of the first 3 OIs in the dot11RoamingConsortiumTable. If fewer than 3 values are defined in the dot11RoamingConsortiumTable, then only as many OIs as defined in the table are populated in this element. The values of the OIs in this element are equal to the values of the first OIs, up to 3, from the table. 9.4.2.97 Emergency Alert Identifier element The Emergency Alert Identifier element provides a hash to identify instances of the active EAS messages that are currently available from the network. The hash allows the non-AP STA to assess whether an EAS message advertised by an AP has been previously received and therefore whether it is necessary to download from the network. The format of the Emergency Alert Identifier element is provided in Figure 9-450. Element ID Length Alert Identifier Hash Octets: 1 1 8 Figure 9-450â€”Emergency Alert Identifier element format The Element ID and Length fields are defined in 9.4.2.1. The Alert Identifier Hash (AIH) is an 8-octet field. It is a unique value used to indicate an instance of an EAS message. The value of this field is the hash produced by the HMAC-SHA-1-64 hash algorithm operating on the EAS message. AIH =HMAC-SHA-1-64(â€œES_ALERTâ€, Emergency_Alert_Message) where â€œES_ALERTâ€ is an ASCII string. Emergency_Alert_Message is the EAS message itself. 9.4.2.98 Mesh Configuration element 9.4.2.98.1 General The Mesh Configuration element shown in Figure 9-451 is used to advertise mesh services. It is contained in Beacon frames and Probe Response frames transmitted by mesh STAs and is also contained in Mesh Peering Open and Mesh Peering Confirm frames. Active Path Active Path Congestion Synchroniz Authenticati Mesh Element Length Selection Selection Control ation on Protocol Formation Mesh ID Protocol Metric Mode Method Capability Identifier Identifier Identifier Identifier Identifier Info Octets 1 1 1 1 1 1 1 1 1 Figure 9-451â€”Mesh Configuration element format 1024 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Element ID and Length fields are defined in 9.4.2.1. The remainder of the fields are described in the following subclauses. 9.4.2.98.2 Active Path Selection Protocol Identifier The Active Path Selection Protocol Identifier field indicates the path selection protocol that is currently activated in the MBSS. Table 9-217 provides path selection protocol identifier values defined by this standard. Table 9-217â€”Active Path Selection Protocol Identifier field values Value Meaning 0 Reserved 1 Hybrid wireless mesh protocol (default path selection protocol) defined in 14.10 (default path selection protocol) 2â€“254 Reserved 255 Vendor specific (The active path selection protocol is specified in a Vendor Specific element) When the Active Path Selection Protocol Identifier field is 255, the active path selection protocol is specified by a Vendor Specific element that is present in the frame. The content of the Vendor Specific element is beyond the scope of this standard. (See 9.4.2.26.) 9.4.2.98.3 Active Path Selection Metric Identifier The Active Path Selection Metric Identifier field indicates the path metric that is currently used by the active path selection protocol in the MBSS. Table 9-218 provides the path selection metric identifier values defined by this standard. Table 9-218â€”Active Path Selection Metric Identifier field values Value Meaning 0 Reserved 1 Airtime link metric defined in 14.9 (default path selection metric) 2â€“254 Reserved 255 Vendor specific (The active metric is specified in a Vendor Specific element) When the Active Path Selection Metric Identifier field is 255, the active path metric is specified by a Vendor Specific element that is present in the frame. The content of the Vendor Specific element is beyond the scope of this standard. (See 9.4.2.26.) 1025 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.98.4 Congestion Control Mode Identifier The Congestion Control Mode Identifier field indicates the congestion control protocol that is currently activated in the MBSS. Table 9-219 provides the congestion control mode identifier values defined by this standard. Table 9-219â€”Congestion Control Mode Identifier field values Value Meaning 0 Congestion control is not activated (default congestion control mode) 1 Congestion control signaling protocol defined in 14.12.2 2â€“254 Reserved 255 Vendor specific (The active congestion control protocol is specified in a Vendor Specific element) The congestion mode identifier value of 0 indicates the mesh STA has no active congestion control protocol and is set as the default value for the congestion control mode identifier in the MBSS. When the Congestion Control Mode Identifier field is 255, the active congestion control protocol is specified by a Vendor Specific element that is present in the frame. The content of the Vendor Specific element is beyond the scope of this standard. (See 9.4.2.26.) 9.4.2.98.5 Synchronization Method Identifier The Synchronization Method Identifier field indicates the synchronization method that is currently activated in the MBSS. Table 9-220 provides the synchronization method identifier values defined by this standard. Table 9-220â€”Synchronization Method Identifier field values Value Meaning 0 Reserved 1 Neighbor offset synchronization method defined in 14.13.2.2 (default synchronization method) 2â€“254 Reserved 255 Vendor specific (The active synchronization method is specified in a Vendor Specific element) The neighbor offset synchronization method is defined as the default synchronization method among mesh STAs. The details of the neighbor offset synchronization method are described in 14.13.2.2. When the Synchronization Method Identifier field is 255, the active synchronization method is specified by a Vendor Specific element that is present in the frame. The content of the Vendor Specific element is beyond the scope of this standard. (See 9.4.2.26.) 1026 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.98.6 Authentication Protocol Identifier The Authentication Protocol Identifier field indicates the type of authentication protocol that is currently used to secure the MBSS. Table 9-221 provides the authentication protocol identifier values defined by this standard. Table 9-221â€”Authentication Protocol Identifier field values Value Meaning 0 No authentication method is required to establish mesh peerings within the MBSS 1 SAE defined in 12.4 2 IEEE 802.1X authentication 3â€“254 Reserved 255 Vendor specific (The active authentication protocol is specified in a Vendor Specific element) When the Authentication Protocol Identifier field is 255, the active authentication protocol is specified by a Vendor Specific element that is present in the frame. The content of the Vendor Specific element is beyond the scope of this standard. (See 9.4.2.26.) 9.4.2.98.7 Mesh Formation Info The format of the Mesh Formation Info field is shown in Figure 9-452. B0 B1 B6 B7 Connected to Number of Mesh Gate Peerings Connected to AS Bits: 1 6 1 Figure 9-452â€”Mesh Formation Info field The Connected to Mesh Gate subfield is set to 1, if the mesh STA has a mesh path to a mesh gate that announces its presence using GANN elements, RANN elements, or PREQ elements, and set to 0 otherwise. The Number of Peerings subfield contains an unsigned integer that indicates the number of mesh peerings currently maintained by the mesh STA or 63, whichever is smaller. The Connected to AS subfield is set to 1 if the Authentication Protocol Identifier field in the Mesh Configuration element is set to 2 (indicating IEEE 802.1X authentication) and the mesh STA has an active connection to an AS. NOTEâ€”When an AS is collocated with an IEEE 802.1X Authenticator an active connection is implicitly true. 1027 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.98.8 Mesh Capability The Mesh Capability field comprises a set of values indicating whether a mesh STA is a possible candidate for mesh peering establishment. The details of the Mesh Capability field are shown in Figure 9-453. B0 B1 B2 B3 B4 B5 B6 B7 Accepting Mesh Additional MCCA MCCA MBCA TBTT Mesh Supported Enabled Forwarding Enabled Adjusting Power Save Reserved Level Peerings Bits: 1 1 1 1 1 1 1 1 Figure 9-453â€”Mesh Capability field The Accepting Additional Mesh Peerings subfield is set to 1 if the mesh STA is willing to establish additional mesh peerings with other mesh STAs and set to 0 otherwise (i.e., the Accepting Additional Mesh Peerings subfield is set in accordance with dot11MeshAcceptingAdditionalPeerings). When the Mesh Configuration element is included in the Mesh Peering Open frame and in the Mesh Peering Confirm frame, the Accepting Additional Mesh Peerings subfield is set to 1. The MCCA Supported subfield is set to 1 if the mesh STA implements MCCA and set to 0 otherwise (i.e., the MCCA Supported subfield is set in accordance with dot11MCCAImplemented). The MCCA Enabled subfield is set to 1 if the mesh STA is using the MCCA and set to 0 otherwise (i.e., the MCCA Enabled subfield is set in accordance with dot11MCCAActivated). The Forwarding subfield is set to 1 if the mesh STA forwards MSDUs and set to 0 otherwise (i.e., the Forwarding subfield is set in accordance with dot11MeshForwarding). The MBCA Enabled subfield is set to 1 if the mesh STA is using MBCA and is set to 0 otherwise (i.e., the MBCA Enabled subfield is set in accordance with dot11MBCAActivated). (See 14.13.4.) The TBTT Adjusting subfield is set to 1 while the TBTT adjustment procedure is ongoing and is set to 0 otherwise. (See 14.13.4.4.3.) The Mesh Power Save Level subfield is set to 1 if at least one of the peer-specific mesh power management modes is deep sleep mode and set to 0 otherwise. The Mesh Power Save Level subfield is reserved when the Power Management subfield in the Frame Control field is set to 0. See 9.2.4.5.11. 9.4.2.99 Mesh ID element The Mesh ID element is used to advertise the identification of an MBSS and is described in 14.2.2. The format of the Mesh ID element is shown in Figure 9-454. The Mesh ID element is transmitted in Mesh Peering Open frames, Mesh Peering Confirm frames, Mesh Peering Close frames, Beacon frames, and Probe Request and Response frames. Element ID Length Mesh ID Octets: 1 1 0â€“32 Figure 9-454â€”Mesh ID element format The Element ID and Length fields are defined in 9.4.2.1. 1028 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A Mesh ID field of length 0 indicates the wildcard Mesh ID, which is used within Probe Request frame. Detailed usage of the Mesh ID element is described in 14.2.2. 9.4.2.100 Mesh Link Metric Report element The Mesh Link Metric Report element is transmitted by a mesh STA to a neighbor peer mesh STA to indicate the quality of the link between the transmitting mesh STA and the neighbor peer mesh STA. The format of the Mesh Link Metric Report element is shown in Figure 9-455. Element ID Length Flags Link Metric Octets: 1 1 1 variable Figure 9-455â€”Mesh Link Metric Report element format The Element ID and Length fields are defined in 9.4.2.1. The format of the Flags field is shown in Figure 9-456. B0 B1 B7 Request Reserved Bits: 1 7 Figure 9-456â€”Flags field The Flags field is set as follows: â€” Bit 0: Request subfield (0 = not a request, 1 = link metric report request). A Request subfield equal to 1 indicates that the recipient of Mesh Link Metric Report element is requested to send a link metric report to the transmitter of the Mesh Link Metric Report element. â€” Bit 1â€“7: Reserved. The Link Metric field indicates the value of the link metric associated with the mesh link between the peer mesh STA transmitting the Mesh Link Metric Report and the neighbor mesh STA receiving the Mesh Link Metric report. The length and the data type of the Link Metric field are determined by the active path selection metric identifier (see 9.4.2.98.3). The length and the data type for the airtime link metric are given in Table 14-5 in 14.9. 9.4.2.101 Congestion Notification element The Congestion Notification element is used to indicate the congestion status of the mesh STA per mesh destination and AC, and the duration for which the STA expects the congestion to last. The format of the Congestion Notification element is shown in Figure 9-457. The Congestion Notification element is included in Congestion Control Notification frames, as described in 9.6.17.5. The Element ID and Length fields are defined in 9.4.2.1. The Destination Mesh STA Address field is represented as a 48-bit MAC address and is set to the address of the mesh destination for which the intra-mesh congestion control is applied. It is set to the broadcast address if the intra-mesh congestion control is applied to all destinations. 1029 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Congestion Congestion Congestion Congestion Destination Notification Notification Notification Notification Element ID Length Mesh STA Duration Duration Duration Duration Address Timer Timer Timer Timer (AC_BK) (AC_BE) (AC_VI) (AC_VO) Octets: 1 1 6 2 2 2 2 Figure 9-457â€”Congestion Notification element format The element contains four Congestion Notification Duration fields for the four EDCA access categories to indicate the estimated congestion duration per AC at the mesh STA transmitting the congestion notification. The congestion notification duration values are encoded as unsigned integers in units of 100 Âµs. 9.4.2.102 Mesh Peering Management element The Mesh Peering Management element is used to manage a mesh peering with a neighbor mesh STA. The format of the Mesh Peering Management element is shown in Figure 9-458. Mesh Chosen Peering Local Link Peer Link ID Reason Code Element ID Length Protocol ID (optional) (optional) PMK (optional) Identifier Octets: 1 1 2 2 0 or 2 0 or 2 0 or 16 Figure 9-458â€”Mesh Peering Management element format The Element ID and Length fields are defined in 9.4.2.1. The Mesh Peering Protocol Identifier field indicates the type of mesh peering protocol that is currently used to establish mesh peerings. Table 9-222 provides the mesh peering protocol identifier values defined by this standard. Table 9-222â€”Mesh Peering Protocol Identifier field values Value Meaning 0 Mesh peering management protocol 1 Authenticated mesh peering exchange protocol 2â€“254 Reserved 255 Vendor specific (The active mesh peering protocol is specified in a Vendor Specific element) 256â€“65 535 Reserved When the Mesh Peering Protocol Identifier field is 255, the active mesh peering protocol is specified by a Vendor Specific element that is present in the frame. The content of the Vendor Specific element is beyond the scope of this standard. (See 9.4.2.26.) The Local Link ID field is the unsigned integer value generated by the local mesh STA to identify the mesh peering instance. The conditional components of the Mesh Peering Management element are present depending on the Action field value of the frame in which the Mesh Peering Management element is conveyed. 1030 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Peer Link ID field is the unsigned integer value generated by the peer mesh STA to identify the mesh peering instance. This field is not present for the Mesh Peering Open frame, is present for the Mesh Peering Confirm frame, and is optionally present for the Mesh Peering Close frame. The presence or absence of the Peer Link ID in a Mesh Peering Close is inferred by the Length field. The Reason Code field enumerates reasons for sending a Mesh Peering Close. It is present for the Mesh Peering Close frame and is not present for Mesh Peering Open or Mesh Peering Confirm frames. The reason code is defined in 9.4.1.7. The Chosen PMK field is present when dot11MeshSecurityActivated is true and a PMK is shared between the transmitter and receiver of the frame containing the element. It contains the PMKID that identifies the PMK used to protect the mesh peering Management frame. Detailed usage of the Mesh Peering Management element is described in 14.3.6, 14.3.7, 14.3.8, and 14.5.5. 9.4.2.103 Mesh Channel Switch Parameters element The Mesh Channel Switch Parameters element is used together with Channel Switch Announcement element and Extended Channel Switch Announcement element by a mesh STA to advertise to other mesh STAs when it is changing to a new operating channel and/or operating class. The format of the Mesh Channel Switch Parameters element is shown in Figure 9-459. Reason Precedence Element ID Length Time To Live Flags Code Value Octets: 1 1 1 1 2 2 Figure 9-459â€”Mesh Channel Switch Parameters element format The Element ID and Length fields are defined in 9.4.2.1. The Time To Live field is coded as an unsigned integer and indicates the remaining number of hops allowed for this element. The Flags field indicates the attribute of this channel switch attempt. The format of the Flags field is shown in Figure 9-460. B0 B1 B2 B3 B7 Transmit Restrict Initiator Reason Reserved Bits: 1 1 1 5 Figure 9-460â€”Flags field The Transmit Restrict subfield is set to 1 when the mesh STA asks neighboring peer mesh STAs not to transmit further frames except frames containing Mesh Channel Switch Parameters element on the current channel until the scheduled channel switch. The Transmit Restrict subfield is set to 0 otherwise. The Initiator subfield is set to 1 when the mesh STA initiates this channel switch attempt. The Initiator subfield is set to 0 when this channel switch attempt is initiated by another mesh STA and propagated by the current mesh STA. 1031 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Reason subfield indicates the validity of the Reason Code field. It is set to 1 if the Reason Code field is valid and is set to 0 otherwise. When the Reason subfield is 0, the content of the Reason Code field is reserved. The Reason Code field specifies the reason for the mesh channel switch. The Reason Code is defined in 9.4.1.7. The content of the Reason Code field is valid only when Reason subfield of Flags field is set to 1 and is reserved otherwise. The Precedence Value field is coded as unsigned integer and is set to a random value drawn from a uniform distribution in the range 0 to 65 535 determined by the initiator of this channel switch attempt. The Mesh Channel Switch Parameters element is included in Channel Switch Announcement frames, as described in 9.6.2.6, and Extended Channel Switch Announcement frames, as described in 9.6.8.7. During MBSS channel switching, the Mesh Channel Switch Parameters element is included in Beacon frames, as described in 9.3.3.3, and Probe Response frames, as described in 9.3.3.11, until the scheduled channel switch. 9.4.2.104 Mesh Awake Window element The Mesh Awake Window element is present in DTIM Beacon frames and is optionally present in Beacon and Probe Response frames. The format of the Mesh Awake Window element is shown in Figure 9-461. Element ID Length Mesh Awake Window Octets: 1 1 2 Figure 9-461â€”Mesh Awake Window element format The Element ID and Length fields are defined in 9.4.2.1. The Mesh Awake Window field is 2 octets long and contains an unsigned integer that indicates the duration of the mesh awake window in TUs. 9.4.2.105 Beacon Timing element The Beacon Timing element is used to advertise the beacon timing information of neighbor STAs (mesh STAs, IBSS APs, or IBSS STAs). The format of the Beacon Timing element is shown in Figure 9-462. Element ID Length Report Control Beacon Timing ... Beacon Timing Information #1 Information #N Octets: 1 1 1 6 ... 6 Figure 9-462â€”Beacon Timing element format The Element ID and Length fields are defined in 9.4.2.1. The Report Control field is used to signal information about the beacon timing information tuple contained in the Beacon Timing element. The structure of the Report Control field is defined in Figure 9-463. The Status Number subfield is set to the status number of the beacon timing information set. The status number is managed as described in 14.13.4.2.4. 1032 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Beacon Timing More Beacon Status Number Element Number Timing Elements Bits: 4 3 1 Figure 9-463â€”Report Control field The Beacon Timing Element Number subfield is an unsigned integer that indicates the index of the beacon timing information tuple contained in this Beacon Timing element. The Beacon Timing Element Number is set to 0 in the Beacon Timing element for the first or only tuple of the beacon timing information and is incremented by one for each successive tuple of the beacon timing information. The beacon timing information tuples are managed as described in 14.13.4.2.5. The More Beacon Timing Element subfield is set to 1 if a successive tuple of beacon timing information exists, and set to 0 otherwise. The Beacon Timing Information field contains the beacon timing information of a neighbor STA. When the mesh STA reports multiple beacon timing information, multiple Beacon Timing Information fields are included in the Beacon Timing element. The structure of the Beacon Timing Information field is defined in Figure 9-464. Neighbor Beacon Neighbor STA ID Neighbor TBTT Interval Octets: 1 3 2 Figure 9-464â€”Beacon Timing Information field The Neighbor STA ID subfield is an unsigned integer that indicates the identification of the neighbor STA corresponding to this beacon timing information. When a mesh peering is established with this neighbor STA, the MSB of this field is set to 0, and the rest of this field is set to the last 7 digits (7 LSBs) of the AID value assigned to this neighbor mesh STA. When a mesh peering is not established with this neighbor STA, the MSB of this field is set to 1, and the rest of this field is set to the last 7 digits (7 LSBs, taking the I/G bit as the MSB) of the 48-bit MAC address of this neighbor STA. NOTEâ€”Since the Neighbor STA ID subfield is provided in abbreviated form, it is possible that the same Neighbor STA ID value appears in multiple Beacon Timing Information fields. The Neighbor TBTT subfield is an unsigned integer that indicates a TBTT of the corresponding neighbor STA, measured in the local TSF timer of the mesh STA. The value is indicated in multiples of 32 Âµs. When the active synchronization method is the neighbor offset synchronization method, the TBTT is calculated as described in 14.13.4.2.2. The B5 to the B28 (taking the B0 as the LSB) of the calculated TBTT are contained in this subfield. The Neighbor Beacon Interval subfield is an unsigned integer that indicates the beacon interval being used by the corresponding neighbor STA. The unit of the Neighbor Beacon Interval subfield is TU. Detailed usage of the Beacon Timing element is described in 14.13.4.2. 9.4.2.106 MCCAOP Setup Request element 9.4.2.106.1 General The MCCAOP Setup Request element is used to make an MCCAOP reservation. This element is transmitted in individually addressed MCCA Setup Request frames or in group addressed MCCA Setup 1033 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Request frames. The mesh STA transmitting the MCCA Setup Request element is the MCCAOP owner of the MCCAOPs that will be scheduled with this reservation setup request. The receivers of the MCCAOP Setup Request frame are the MCCAOP responders. The format of the element is shown in Figure 9-465. Element ID Length MCCAOP MCCAOP Reservation ID Reservation Octets 1 1 1 5 Figure 9-465â€”MCCAOP Setup Request element format The Element ID and Length fields are defined in 9.4.2.1. The MCCAOP Reservation ID field is an eight bit unsigned integer that represents the ID for the MCCAOP reservation. It is determined by the MCCAOP owner. When used in combination with the MAC address of the MCCAOP owner, the MCCAOP Reservation ID uniquely identifies the MCCAOP reservation. If this MCCAOP Setup Request element is for an individually addressed transmission, the MCCAOP Reservation ID is between 0 and 127 and the MCCAOP Setup Request element is transmitted in an individually addressed frame to the intended responder. If this MCCAOP Setup Request element is for a group addressed transmission, the MCCAOP Reservation ID is between 128 and 254 and the MCCAOP Setup Request element is transmitted in a group addressed frame. The value 255 is not used to identify a single MCCAOP reservation. The MCCAOP Reservation field is described in 9.4.2.106.2. 9.4.2.106.2 MCCAOP Reservation field The MCCAOP Reservation field is a 5 octet field specifying a schedule for frame transmissions called MCCAOPs. The MCCAOP Reservation field consists of three subfields and its format is shown in Figure 9-466. MCCAOP MCCAOP Duration Periodicity MCCAOP Offset Octets: 1 1 3 Figure 9-466â€”MCCAOP Reservation field The MCCAOP Duration subfield is 1 octet in length and contains an unsigned integer. It specifies the duration of the MCCAOPs in multiples of 32 Âµs. The MCCAOP Periodicity subfield is 1 octet in length and contains a positive integer. It specifies the number of MCCAOPs scheduled in each DTIM interval. The MCCAOP Offset subfield is three octets in length and contains an unsigned integer. It specifies the beginning of the first MCCAOP in each DTIM interval. The value is specified in multiples of 32 Âµs. The sum of MCCAOP Offset plus MCCAOP Duration is constrained to be smaller than the duration of the DTIM interval divided by MCCAOP Periodicity. 9.4.2.107 MCCAOP Setup Reply element The MCCAOP Setup Reply element is used to reply to an MCCAOP Setup Request. This element is transmitted in individually addressed MCCA Setup Reply frames. The mesh STA transmitting the MCCA Setup Reply element is the MCCAOP responder of the MCCAOPs scheduled in this reservation setup. The 1034 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications receiver of the MCCAOP Setup Reply is the MCCAOP owner. The format of the element is shown in Figure 9-467. Element ID Length MCCAOP MCCA Reply MCCAOP Reservation ID Code Reservation Octets: 1 1 1 1 0 or 5 Figure 9-467â€”MCCAOP Setup Reply element format The Element ID and Length fields are defined in 9.4.2.1. The MCCAOP Reservation ID field is an eight bit unsigned integer that represents the ID for the requested series of MCCAOPs. It is determined by the MCCAOP owner and copied from the MCCAOP Setup Request element. When used in combination with the MAC address of the MCCAOP owner, the MCCAOP Reservation ID uniquely identifies the MCCAOP reservation. The MCCA Reply Code field is a 1 octet field that contains the reply code used in an MCCAOP Setup Reply element. The reply codes are defined in Table 9-223. Table 9-223â€”MCCA Reply Code field values MCCA reply code Meaning 0 Accept 1 Reject: MCCAOP reservation conflict 2 Reject: MAF limit exceeded 3 Reject: MCCA track limit (dot11MCCAMaxTrackStates) exceeded 4â€“255 Reserved The MCCAOP Reservation field includes an alternative to the MCCAOP reservation specified in the MCCAOP Setup Request frame. Its format is described in 9.4.2.106.2. When the MCCA Reply Code is 1, the MCCAOP Reservation field might be present. When the MCCA Reply Code is set to other values, the MCCAOP Reservation field is not present. 9.4.2.108 MCCAOP Advertisement Overview element The MCCAOP Advertisement Overview element is used by a mesh STA to advertise its MCCA Information and information about its MCCAOP Advertisement elements, representing its MCCAOP advertisement set, to its neighbors. This element is transmitted in MCCA Advertisement frames and optionally present in Beacon frames. The format of the MCCAOP Advertisement Overview element is shown in Figure 9-468. Element Advertisement Set MCCA Access MAF Advertisement Length Flags ID Sequence Number Fraction Limit Elements Bitmap Octets 1 1 1 1 1 1 2 Figure 9-468â€”MCCAOP Advertisement Overview element format 1035 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Element ID and Length fields are defined in 9.4.2.1. The Advertisement Set Sequence Number field is 1 octet in length and is coded as an unsigned integer. It is set to the advertisement set sequence number of the current MCCAOP advertisement set. The Advertisement Set Sequence Number, together with the MAC address of the transmitter of the MCCAOP Advertisement Overview element, identifies an MCCAOP advertisement set and provides an identifier and a chronological order of different MCCAOP advertisement sets of the same mesh STA. The format of the Flags field is shown in Figure 9-469. B0 B1 B7 Accept Reserved Reservations Bits: 1 7 Figure 9-469â€”Flags field format The Flags field is set as follows: â€” Bit 0: Accept Reservations subfield. The Accept Reservations subfield is set to 1 if the mesh STA accepts additional reservations. It is set to 0 otherwise. â€” Bit 1â€“7: Reserved The MCCA Access Fraction field is an eight bit unsigned integer. The MCCA Access Fraction field is set to the current value of the MCCA access fraction at the mesh STA rounded down to the nearest multiple of (1/ 255) of the DTIM interval length. The MAF Limit field is an eight bit unsigned integer. The MAF Limit field is set to the maximum MCCA access fraction allowed at the mesh STA rounded down to the nearest multiple of (1/255) of the DTIM interval length. The Advertisement Elements Bitmap field is 2 octets in length and indicates the MCCAOP Advertisement elements that are part of this MCCAOP advertisement set. The Advertisement Elements Bitmap field is a bitmap. Bit i in this bitmap equals 1 if the MCCAOP Advertisement element with MCCAOP Advertisement Element Index equal to i is part of this MCCAOP advertisement set, and it equals 0 otherwise. 9.4.2.109 MCCAOP Advertisement element 9.4.2.109.1 General The MCCAOP Advertisement element is used by a mesh STA to advertise MCCAOP reservations to its neighbors. This element is transmitted in MCCA Advertisement frames and optionally present in Beacon frames. The format of the element is shown in Figure 9-470. MCCAOP TX-RX Broadcast Interference Element Length Advertisement Set Advertisement Periods Periods Periods ID Sequence Number Element Information Report Report Report Octets: 1 1 1 1 variable variable variable Figure 9-470â€”MCCAOP Advertisement element format 1036 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Element ID and Length fields are defined in 9.4.2.1. The Advertisement Set Sequence Number field is 1 octet in length and is coded as an unsigned integer. It is set to the advertisement set sequence number of the current MCCAOP advertisement set. The Advertisement Set Sequence Number, together with the MAC address of the transmitter of the MCCAOP Advertisement element, identifies an MCCAOP advertisement set and provides an identifier and a chronological order of different MCCAOP advertisement sets of the same mesh STA. The MCCAOP Advertisement Element Information field is 1 octet in length. It is described in 9.4.2.109.2. The TX-RX Periods Report field is a variable-length field that contains an MCCAOP Reservation Report field, as described in 9.4.2.109.3. This field is present when the TX-RX Report Present subfield of the MCCAOP Advertisement Element Information field is equal to 1; it is not present otherwise. The TX-RX Periods Report field is described in 10.23.3.7.2. The Broadcast Periods Report field is a variable-length field that contains an MCCAOP Reservation Report field, as described in 9.4.2.109.3. This field is present when the Broadcast Report Present subfield of the MCCAOP Advertisement Element Information field is equal to 1; it is not present otherwise. The Broadcast Periods Report field is described in 10.23.3.7.2. The Interference Periods Report field is a variable-length field that contains an MCCAOP Reservation Report field, as described in 9.4.2.109.3. This field is present when the Interference Report Present subfield of the MCCAOP Advertisement Element Information field is equal to 1; it is not present otherwise. The Interference Periods Report field is described in 10.23.3.7.2. 9.4.2.109.2 MCCAOP Advertisement Element Information field The MCCA Information field is 1 octets in length and provides information on the MCCAOP reservations. The field consists of four subfields and its format is shown in Figure 9-471. B0 B3 B4 B5 B6 B7 MCCAOP TX-RX Broadcast Interference Advertisement Report Report Report Reserved Element Index Present Present Present Bits: 4 1 1 1 1 Figure 9-471â€”MCCAOP Advertisement Element Information field The MCCAOP Advertisement Element Index subfield is a 4-bit unsigned integer. It identifies the MCCAOP Advertisement element. The TX-RX Report Present subfield is 1 bit in length. It is set to 1 if the TX-RX Periods Report field is present in the MCCAOP Advertisement element and set to 0 if no TX-RX Periods Report field is present. The Broadcast Report Present subfield is 1 bit in length. It is set to 1 if the Broadcast Periods Report field is present in the MCCAOP Advertisement element and set to 0 if no Broadcast Periods Report field is present. The Interference Report Present subfield is 1 bit in length. It is set to 1 if the Interference Periods Report field is present in the MCCAOP Advertisement element and set to 0 if no Interference Periods Report field is present. 1037 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.109.3 MCCAOP Reservation Report field The MCCAOP Reservation Report field is of variable length and is used to report a number of MCCAOP reservations. The field consists of a variable number of subfields and its format is shown in Figure 9-472. Number of Reported MCCAOP MCCAOP MCCAOP Reservations Reservation 1 ... Reservation n Octets: 1 5 5 Figure 9-472â€”MCCAOP Reservation Report field The Number of Reported MCCAOP reservations is a field of 1 octet with an unsigned integer that specifies the number, n, of MCCAOP Reservations reported in this MCCAOP Reservation Report field. The MCCAOP Reservation 1 through MCCAOP Reservation n fields specify the MCCAOP reservations reported. Each MCCAOP Reservation field is 5 octets in length and its format is shown in Figure 9-466 in 9.4.2.106.2. 9.4.2.110 MCCAOP Teardown element The MCCAOP Teardown element is used to announce the teardown of an MCCAOP reservation. The MCCAOP Teardown element is transmitted in individually addressed MCCA Teardown frames or in group addressed MCCA Teardown frames. Its format is shown in Figure 9-473. MCCAOP Element ID Length MCCAOP Owner Reservation ID Octets: 1 1 1 0 or 6 Figure 9-473â€”MCCAOP Teardown element format The Element ID and Length fields are defined in 9.4.2.1. An MCCAOP Teardown element is transmitted by either the MCCAOP owner or the MCCAOP responder of a MCCAOP reservation to tear down the MCCAOP reservation. The MCCAOP Reservation ID field is an eight bit unsigned integer that represents the ID for the MCCAOP reservation. The MCCAOP Owner field is an optional field. It is 6 octets long and indicates the 48-bit MAC address of the MCCAOP owner. This field is included if the element is transmitted by the MCCAOP responder; it is not included otherwise. 1038 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.111 GANN element The GANN (gate announcement) element is used for announcing the presence of a mesh gate in the MBSS. The GANN element is transmitted in a Gate Announcement frame (see 9.6.17.4). The format of the GANN element is shown in Figure 9-474. Element Element Mesh GANN Length Flags Hop Count Gate Sequence Interval ID TTL Address Number Octets: 1 1 1 1 1 6 4 2 Figure 9-474â€”GANN element format The Element ID and Length fields are defined in 9.4.2.1. The Flags field is reserved. The Hop Count field is coded as an unsigned integer and indicates the number of hops from the originating mesh gate to the mesh STA transmitting this element. The Element TTL field is coded as an unsigned integer and indicates the remaining number of hops allowed for this element. The Mesh Gate Address field is represented as a 48-bit MAC address and is set to the MAC address of the mesh gate. The GANN Sequence Number field is coded as an unsigned integer and is set to a GANN Sequence Number specific for the originating mesh gate. The Interval field is coded as an unsigned integer and is set to the number of seconds between the periodic transmissions of Gate Announcements by the mesh gate. Detailed usage of the GANN element is described in 14.11.2. 9.4.2.112 RANN element The RANN (root announcement) element is used for announcing the presence of a mesh STA configured as root mesh STA with dot11MeshHWMProotMode set to rann (4). RANN elements are sent out periodically by such a root mesh STA. The RANN element is transmitted in an HWMP Mesh Path Selection frame (see 9.6.17.3). The format of the RANN element is shown in Figure 9-475. Root Mesh HWMP Element ID Length Flags Hop Element STA Sequence Interval Metric Count TTL Address Number Octets: 1 1 1 1 1 6 4 4 4 Figure 9-475â€”RANN element format The Element ID and Length fields are defined in 9.4.2.1. The format of the Flags field is shown in Figure 9-476. 1039 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B0 B1 B7 Gate Announcement Reserved Bits: 1 7 Figure 9-476â€”Flags field format The Flags field is set as follows: â€” Bit 0: Gate Announcement subfield (0 = gate announcement protocol not activated, 1 = gate announcement protocol activated). A Gate Announcement subfield equal to 1 indicates that the Root Mesh STA Address is a mesh gate with dot11MeshGateAnnouncements equal to true. â€” Bit 1â€“7: Reserved. The Hop Count field is coded as an unsigned integer and indicates the number of hops from the originating root mesh STA to the mesh STA transmitting this element. The Element TTL field is coded as an unsigned integer and indicates the remaining number of hops allowed for this element. The Root Mesh STA Address field is represented as a 48-bit MAC address and is set to the MAC address of the root mesh STA. The HWMP Sequence Number field is coded as an unsigned integer and is set to the HWMP sequence number (SN) specific to the root mesh STA. The Interval field is coded as an unsigned integer and is set to the number of TUs between the periodic transmissions of Root Announcements. The Metric field is set to the cumulative metric from the originating root mesh STA to the mesh STA transmitting the announcement. Detailed usage of the RANN element is described in 14.10.12. 9.4.2.113 PREQ element The PREQ (path request) element is used for discovering a path to one or more target mesh STAs, maintaining a path (optional), building a proactive (reverse) path selection tree to the root mesh STA, and confirming a path to a target mesh STA (optional). The PREQ element is transmitted in an HWMP Mesh Path Selection frame (see 9.6.17.3). The format of the PREQ element is shown in Figure 9-477. Path Originator Originator Originator Element Hop Element HWMP ID Length Flags Count TTL Discovery Mesh STA Sequence External Lifetime ID Address Address Number Octets: 1 1 1 1 1 4 6 4 0 or 6 4 Target Target Per Target HWMP Per Target HWMP Metric Target Target Address Sequence ... Target Address Sequence Count Flags #1 #1 Number Flags #N #N Number #1 #N 4 1 1 6 4 ... 1 6 4 Figure 9-477â€”PREQ element format 1040 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Element ID and Length fields are defined in 9.4.2.1. The format of the Flags field is shown in Figure 9-478. B0 B1 B2 B3 B5 B6 B7 Gate Addressing Proactive Reserved AE Reserved Announcement Mode PREP Bits 1 1 1 3 1 1 Figure 9-478â€”Flags field format The Flags field is set as follows: â€” Bit 0: Gate Announcement subfield (0 = gate announcement protocol not activated, 1 = gate announcement protocol activated). A Gate Announcement subfield equal to 1 indicates that the Originator Mesh STA Address is a mesh gate with dot11MeshGateAnnouncements equal to true. â€” Bit 1: Addressing Mode subfield (0 = group addressed, 1 = individually addressed). When the Addressing Mode subfield is 0, the PREQ element is sent in an HWMP Mesh Path Selection frame that is group addressed to all neighbor peer mesh STAs. When the Addressing Mode subfield is 1, the PREQ element is sent in an HWMP Mesh Path Selection frame that is individually addressed to a neighbor peer mesh STA. Detailed addressing information is provided in 14.10.7. â€” Bit 2: Proactive PREP subfield (0 = off, 1 = on). The Proactive PREP subfield is of relevance only if the Target Address is the broadcast address (all 1s). If equal to 1, every recipient of a PREQ element with Target Address equal to the broadcast address replies with a PREP element. If equal to 0, a recipient replies only under certain conditions (see 14.10.4.2) and does not reply otherwise. â€” Bit 3â€“5: Reserved. â€” Bit 6: AE (Address Extension) subfield (1= external address present, 0 = otherwise). An AE subfield equal to 1 indicates that the field Originator External Address is present, and that the originator mesh STA is a proxy for this external address. â€” Bit 7: Reserved. The Hop Count field is coded as an unsigned integer and is set to the number of hops from the originator to the mesh STA transmitting this element. The Element TTL field is coded as an unsigned integer and indicates the remaining number of hops allowed for this element. The Path Discovery ID field is coded as an unsigned integer and is set to some unique ID for this PathDiscovery. The Originator Mesh STA Address field is represented as a 48-bit MAC address and is set to the originator MAC address. The Originator HWMP Sequence Number field is coded as an unsigned integer and is set to the HWMP SN specific to the originator. The Originator External Address field is the MAC address of an external STA proxied by the Originator. This field is present only if the AE subfield in the Flags field is set to 1 and is represented as a 48-bit MAC address. The Lifetime field is coded as an unsigned integer and is set to the time for which mesh STAs receiving the PREQ element consider the forwarding information to be valid. The lifetime is measured in TUs. 1041 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Metric field is set to the cumulative metric from the originator to the mesh STA transmitting the PREQ element. The Target Count N field is coded as an unsigned integer and gives the number of targets (N) contained in this PREQ element. The maximum value of N is 20. The Per Target Flags field, the Target Address field, and the Target HWMP Sequence Number field are repeated N times in the element. The format of the Per Target Flags field is shown in Figure 9-479. B0 B1 B2 B3 B7 TO Reserved USN Reserved Bits: 1 1 1 5 Figure 9-479â€”Per Target Flags field format The Per Target Flags field is set as follows: â€” Bit 0: TO (Target Only) subfield: The TO subfield defines which mesh STA responds with a PREP element to the PREQ element containing an individual target address. If TO = 1, only the target mesh STA responds. If TO = 0, intermediate mesh STAs with active forwarding information to the target mesh STA also respond. See 14.10.10.3. â€” Bit 1: Reserved. â€” Bit 2: USN (Unknown Target HWMP Sequence Number) subfield: The USN subfield indicates whether the Target HWMP Sequence Number field of the corresponding target is interpreted as HWMP SN (USN = 0) or not (USN = 1), the latter meaning that a target HWMP SN is unknown at the originator mesh STA. â€” Bit 3â€“7: Reserved. The Target Address field is represented as a 48-bit MAC address. The Target HWMP Sequence Number field is coded as an unsigned integer and is the latest known HWMP SN received in the past by the originator mesh STA for any path toward the target. If such a target HWMP SN is not known, the USN subfield is set to 1 and Target HWMP Sequence Number field is reserved. Detailed usage of the PREQ element is described in 14.10.9. 9.4.2.114 PREP element The PREP (path reply) element is used to establish a forward path to a target and to confirm that a target is reachable. The PREP element is issued in response to a PREQ element. The PREP element is transmitted in an HWMP Mesh Path Selection frame (see 9.6.17.3). The format of the PREP element is shown in Figure 9-480. 1042 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Target Element Element Target HWMP Target Length Flags Hop Count Mesh STA External Lifetime ID TTL Address Sequence Address Number Octets: 1 1 1 1 1 6 4 0 or 6 4 Originator Originator HWMP Metric Mesh STA Address Sequence Number 4 6 4 Figure 9-480â€”PREP element format The Element ID and Length fields are defined in 9.4.2.1. The format of the Flags field is shown in Figure 9-481. B0 B5 B6 B7 Reserved AE Reserved Bits: 6 1 1 Figure 9-481â€”Flags field format The Flags field is set as follows: â€” Bit 0â€“5: Reserved. â€” Bit 6: AE (Address Extension) subfield (1 = external address present, 0 = otherwise). An AE subfield equal to 1 indicates that the field Target External Address is present, and that the target mesh STA is a proxy for this external address. â€” Bit 7: Reserved. The Hop Count field is coded as an unsigned integer and is set to the number of hops from the path target to the mesh STA transmitting this element. The Element TTL field is coded as an unsigned integer and indicates the remaining number of hops allowed for this element. The Target Mesh STA Address is the MAC address of the target mesh STA or target proxy mesh gate and is represented as a 48-bit MAC address. The Target HWMP Sequence Number field is coded as an unsigned integer and is set to the HWMP SN of the target mesh STA (if the AE subfield in the Flags field is set to 0) or target proxy mesh gate (if the AE subfield in the Flags field is set to 1). The Target External Address field is set to the external address on behalf of which the PREP element is sent. This field is present only if Bit 6 (AE subfield) in Flags field equals 1 and is represented as a 48-bit MAC address. The Lifetime field is coded as an unsigned integer and is set to the time for which mesh STAs receiving the PREP element consider the forwarding information to be valid. The lifetime is measured in TUs. 1043 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Metric field indicates the cumulative metric from the path target to the mesh STA transmitting this element. The Originator Mesh STA Address field is represented as a 48-bit MAC address and is set to the MAC address of the originator, which is contained in the PREQ element. The Originator HWMP Sequence Number field is coded as an unsigned integer and is set to the HWMP SN of the originator mesh STA contained in the PREQ element. The detailed usage of the PREP element is described in 14.10.10. 9.4.2.115 PERR element The PERR (path error) element is used for announcing an unreachable destination. The PERR element is transmitted in an HWMP Mesh Path Selection frame (see 9.6.17.3). The format of the PERR element is shown in Figure 9-482. Number of Destination HWMP Destination Reason Element Length Element Flags Sequence External ID TTL Destinations #1 Address #1 Number Address Code #1 ... N #1 #1 Octets: 1 1 1 1 1 6 4 0 or 6 2 Figure 9-482â€”PERR element format The Element ID and Length fields are defined in 9.4.2.1. The Element TTL field is coded as an unsigned integer and indicates the remaining number of hops allowed for this element. The Number of Destinations N field is coded as an unsigned integer and indicates the number of announced destinations in PERR. The maximum value of N is 19. The Flags field, the Destination Address field, the HWMP Sequence Number field, the Destination External Address field, and the Reason Code field are repeated N times in the element. The format of the Flags field is shown in Figure 9-483. B0 B5 B6 B7 Reserved AE Reserved Bits: 4 1 1 Figure 9-483â€”Flags field format The Flags field is set as follows: â€” Bit 0â€“5: Reserved. â€” Bit 6: AE (Address Extension) subfield (1 = destination external address is present, 0 = otherwise). â€” Bit 7: Reserved. The Destination Address field is represented as a 48-bit MAC address and indicates the detected unreachable destination MAC address. 1044 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The HWMP Sequence Number field is coded as an unsigned integer and indicates the HWMP SN for the invalidated destination, if applicable. Otherwise, the HWMP Sequence Number field is reserved depending on the reason code. The Destination External Address field is set to the external address, on behalf of which the PERR is sent. This field is present only if Bit 6 (AE subfield) in the Flags field equals 1 and is represented as a 48-bit MAC address. The Reason Code field specifies the reason for sending a PERR element. The Reason Code is defined in 9.4.1.7. The detailed usage of the PERR element is described in 14.10.11. 9.4.2.116 PXU element The PXU (proxy update) element is used to inform the destination mesh STA of the proxy information at the originator mesh STA. The PXU element is transmitted in a Proxy Update frame (see 9.6.18.2). The format of the PXU element is shown in Figure 9-484. PXU Number of Proxy Proxy Element Originator Proxy Length PXU ID Information ... Information ID MAC Information #1 #N Address (N) 11, 15, 17, or 11, 15, 17, or Octets: 1 1 1 6 1 21 21 Figure 9-484â€”PXU element format The Element ID and Length fields are defined in 9.4.2.1. The PXU ID field is coded as an unsigned integer and is set to the sequence number of the PXU. The source mesh STA sets the PXU ID field in the PXU element to a value from a single modulo 256 counter that is incremented by 1 for each new PXU element. The PXU Originator MAC Address field is represented as a 48-bit MAC address and is the MAC address of the mesh STA that originates this PXU element. The Number of Proxy Information fields is coded as an unsigned integer and is set to the number N of Proxy Information field that follow this field and that are reported to the destination mesh STA. The maximum value of N is 22. The Proxy Information field contains a single proxy information (see 14.11.4.2). The length of the Proxy Information field depends on the settings of the subfields in the Flags subfield and is 11, 15, 17, or 21 octets. The format of the Proxy Information field is defined in Figure 9-485. Proxy External MAC Information Proxy MAC Proxy Flags Information Address Sequence Address Lifetime Number Octets: 1 6 4 0 or 6 0 or 4 Figure 9-485â€”Proxy Information field 1045 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The format of the Flags subfield is shown in Figure 9-486. B0 B1 B2 B3 B7 Delete Originator Is Lifetime Reserved Proxy Bits: 1 1 1 5 Figure 9-486â€”Flags subfield The Flags subfield is set as follows: â€” Bit 0: The Delete subfield indicates whether this proxy information is to be deleted. It is set to 1 if the proxy information is to be deleted, and set to 0 otherwise. â€” Bit 1: The Originator Is Proxy subfield indicates that the originator mesh STA of the PXU element is the proxy mesh gate of this proxy information when set to 1. In this case, there is no Proxy MAC Address subfield present in this Proxy Information field. When the Originator Is Proxy subfield is 0, the Proxy MAC Address subfield is present in this Proxy Information field. â€” Bit 2: The Lifetime subfield indicates that the Proxy Information Lifetime subfield is present in this Proxy Information field when set to 1. â€” Bit 3â€“7: Reserved. The External MAC Address subfield is represented as a 48-bit MAC address and is the MAC address of the external STA proxied by the proxy mesh gate. The Proxy Information Sequence Number field is coded as an unsigned integer and is set to the sequence number of the proxy information. The sequence number of the proxy information defines a chronological order of the proxy information for the external STA at this proxy mesh gate. The Proxy MAC Address subfield is represented as a 48-bit MAC address and is set to the MAC address of proxy mesh gate. It is present if the Originator Is Proxy subfield of the Flags subfield is 0; it is not present otherwise. The Proxy Information Lifetime subfield is coded as an unsigned integer and is set to the time for which the mesh STA receiving this PXU considers this proxy information to be valid. The proxy information lifetime is measured in TUs. It is present if the Lifetime subfield of the Flags subfield is 1; it is not present otherwise. 9.4.2.117 PXUC element The PXUC (proxy update confirmation) element is used to confirm the previously received PXU. The PXUC element is transmitted in a Proxy Update Confirmation frame (see 9.6.18.3). The format of PXUC element is shown in Figure 9-487. PXU Recipient Element ID Length PXU ID MAC Address Octets 1 1 1 6 Figure 9-487â€”PXUC element format The Element ID and Length fields are defined in 9.4.2.1. 1046 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The PXU ID field is coded as an unsigned integer and is the PXU ID of the received PXU that is being confirmed. The PXU Recipient MAC Address is represented as a 48-bit MAC address and is set to the MAC address of the recipient of the PXU, i.e., the originator of the PXUC element. 9.4.2.118 Authenticated Mesh Peering Exchange element The Authenticated Mesh Peering Exchange element includes information needed to perform the authentication sequence during an authenticated mesh peering exchange. This element is shown in Figure 9-488. Element Selected Local Peer Key Replay GTKdata IGTKdata Length Pairwise Counter ID Cipher Suite Nonce Nonce (optional) (optional) (optional) Octets 1 1 4 32 32 8 variable variable Figure 9-488â€”Authenticated Mesh Peering Exchange element format The Element ID and Length fields are defined in 9.4.2.1. The Selected Pairwise Cipher Suite field contains a pairwise cipher suite selector, as defined in 9.4.2.25.2, indicating a cipher suite to be used to secure the link. The Local Nonce field contains a nonce value chosen by the mesh STA that is sending the element. It is encoded following the conventions from 9.2.2. The Peer Nonce field contains a nonce value that was chosen by the peer mesh STA or candidate peer mesh STA to which the element is being sent. It is encoded following the conventions from 9.2.2. The Key Replay Counter field is optional. It is used only for the Mesh Group Key Inform frame (see 14.6.3) and the Mesh Group Key Acknowledge frame (see 14.6.4). It is represented as an unsigned integer. The GTKdata field is optional. When present, it contains the bit string of {GTK || Key RSC || GTKExpirationTime} as the GTK data material. When present, the GTKdata field is protected by the exchange in which it is contained (see 14.5). The Key RSC denotes the last TSC or PN sent using the GTK and is specified in Table 12-5 of 12.7.2. GTKExpirationTime denotes the key lifetime of the GTK in seconds and the format is specified in Figure 12-40 of 12.7.2. The IGTKdata field is present when dot11RSNAProtectedManagementFramesActivated equals true. When present, it contains the Key ID, IPN and IGTK used with BIP for management frame protection. The format of the IGTKdata field is specified in Figure 12-42 of 12.7.2. Detailed usage of the Authenticated Mesh Peering Exchange element is described in 14.5.5 and in 14.6. 9.4.2.119 MIC element The MIC element provides message integrity to mesh peering Management frames. The format of the MIC element is shown in Figure 9-489. 1047 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Element ID Length MIC Octets: 1 1 16 Figure 9-489â€”MIC element format The Element ID and Length fields are defined in 9.4.2.1. The MIC field contains a message integrity code calculated over the mesh peering Management frame (as specified in 14.5) and the mesh group key handshake frame (as specified in 14.6). 9.4.2.120 Quality-of-Service Management Frame Policy element The Quality-of-Service Management Frame (QMF) Policy element defines a QMF access category mapping (QACM) of Management frames and is used to advertise and exchange QMF policy between STAs. The use of the QMF Policy element is given in 11.26. See Figure 9-490. Element ID Length QACM #1 ... QACM #N Octets: 1 1 variable variable Figure 9-490â€”QMF Policy element format The Element ID and Length fields are defined in 9.4.2.1. The QACM field specifies a group of Management frames and their associated access categories. See Figure 9-491 and see 11.26.3. QACM Header Action Frame Category Action Value Bitmap (optional) (optional) Octets: 2 0 or 1 variable Figure 9-491â€”QACM field format The format of the QACM Header subfield of the QACM field is defined in Figure 9-492. B0 B1 B2 B7 B8 B9 B10 B11 B12 B15 QACM Field Type QACM Field Length I G ACI Management Frame Subtype Bits: 2 6 1 1 2 4 Figure 9-492â€”QACM Header subfield The QACM Field Type subfield is 2 bits in length and defines the structure of the QACM field. Its value is 0. Values 1, 2, and 3 are reserved. The QACM Field Length subfield is 6 bits in length and defines the length in octets of the QACM field excluding the QACM Header subfield. The Individually Addressed subfield (I) is 1 bit in length. When the QACM applies to individually addressed Management frames, the value of the Individually Addressed subfield is 1. Otherwise, it is 0. The Group Addressed subfield (G) is 1 bit in length. When the QACM applies to group addressed Management frames, the value of the Group Addressed subfield is 1. Otherwise, it is 0. 1048 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The combination of I = 0 and G = 0 is not allowed. The ACI subfield is 2 bits in length. Each Management frame that is listed in the QACM Header subfield is transmitted using the access category identified by the accompanying ACI subfield. The Management Frame Subtype subfield is 4 bits in length. It indicates the subtype of Management frames that are sent using the access category indicated in the ACI subfield. The valid values for this subfield are the subtypes in Table 9-1 that correspond to Management frames. The Action Frame Category subfield is 1 octet in length and indicates the category of the Action frame, as defined in 9.4.1.1, of Action frames that are sent using the access category indicated in the ACI subfield. The Action Frame Category subfield is included only when the Management Frame Subtype subfield indicates Action or Action No Ack subtype as specified in 11.26.3. The Action Value Bitmap subfield is included when the QACM Policy is specified for a subset of Action frame types in a Action Frame Category. The Action Value Bitmap subfield is of variable length and indicates the action values, as defined in 9.6, for the corresponding Action frame category that are sent using the access category indicated in the ACI subfield. The Action Value Bitmap subfield is included only when the Management Frame Subtype subfield indicates Action or Action No Ack subtype and the QACM Field Length subfield is greater than or equal to 2. Each bit in the Action Value Bitmap subfield is mapped to the corresponding action value. The Action Value Bitmap subfield is zero padded to complete any incomplete octet. When included, the size in octets of the Action Value Bitmap field is found by subtracting 1 from the value of the QACM Field Length subfield. 9.4.2.121 Intra-Access Category Priority element The Intra-Access Category Priority element provides information from a non-AP STA to an AP on the relative priorities of streams within an AC, as described in 10.2.4.2 and 11.27.2. This element is optionally present in ADDTS Request, QoS Map Configure, or SCS Request frames. The Intra-Access Category Priority element is defined in Figure 9-493. Element ID Length Intra-Access Priority Octets: 1 1 1 Figure 9-493â€”Intra-Access Category Priority element format The Element ID and Length fields are defined in 9.4.2.1. The Intra-Access Priority field is defined in Figure 9-494. B0 B2 B3 B4 B5 B7 User Priority Alternate Queue Drop Eligibility Reserved Bits: 3 1 1 3 Figure 9-494â€”Intra-Access Priority field format The User Priority subfield indicates the UP of MSDUs or A-MSDUs of the stream to which this Intra- Access Category Priority element relates. The Alternate Queue subfield indicates the intended primary or alternate EDCA queue that is used for this stream. When dot11AlternateEDCAActivated is false, this subfield is reserved. When the Alternate Queue 1049 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications subfield is set to 0, the primary EDCA queue for this AC is used. When the Alternate Queue subfield is equal to 1, the Alternate EDCA queue for this AC (see 10.2.4.2) is used. The Drop Eligibility subfield is 1 bit in length and is used to indicate the suitability of this TS to be discarded if there are insufficient resources. If there are insufficient resources, a STA should discard the MSDUs or A-MSDUs of a TS with a Drop Eligibility subfield equal to 1, in preference to MSDUs or A-MSDUs of a TS whose Drop Eligibility subfield is equal to 0. See 11.26.2. The mechanisms for determining whether the resources are insufficient or when to discard MSDUs or A-MSDUs are beyond the scope of this standard. 9.4.2.122 SCS Descriptor element The SCS Descriptor element defines information about the stream that is being classified using the procedures defined in 11.27.2. The format of the SCS Descriptor element is shown in Figure 9-495. zero or more TCLAS Elements Intra- Access TCLAS TCLAS Element Length SCSID Request Category Elements Processing Optional ID Type Priority Element Subelements Element (optional) (optional) (optional) Octets: 1 1 1 1 0 or 3 variable 0 or 3 variable Figure 9-495â€”SCS Descriptor element format The Element ID and Length fields are defined in 9.4.2.1. The SCSID field is set to a nonzero value chosen by the non-AP STA identifying the SCS stream specified in this SCS Descriptor element. The Request Type field is set to a number to identify the type of SCS request. The Request Types are shown in Table 9-224. Table 9-224â€”SCS Request Type definitions Name Value Add 0 Remove 1 Change 2 Reserved 3â€“255 The Intra-Access Category Priority Element field is present when Request Type field is equal to â€œAddâ€ or â€œChangeâ€ and is defined in 9.4.2.121. The TCLAS Elements field contains zero or more TCLAS elements to specify how incoming MSDUs are classified as part of this SCS stream, as defined in 9.4.2.31. One or more TCLAS elements are present when Request Type field is equal to â€œAddâ€ or â€œChange,â€ and no TCLAS elements are present when Request Type field is equal to â€œRemove.â€ 1050 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The TCLAS Processing Element field is present when more than one TCLAS element is present in the TCLAS Elements field and contains a TCLAS Processing element that defines how the multiple TCLAS elements are to be processed, as defined in 9.4.2.33. The Optional Subelements field contains zero or more subelements. The subelement format and ordering of subelements are defined in 9.4.3. The Optional Subelement ID field values for the defined subelements are shown in Table 9-225. Table 9-225â€”Optional subelement IDs for SCS Descriptor element Subelement ID Name Extensible 0â€“220 Reserved 221 Vendor Specific 222â€“255 Reserved The SCS Descriptor element is included in SCS Request frames, as described in 9.6.19.2. The use of the SCS Descriptor element and SCS Request frames is described in 11.27.2. 9.4.2.123 QLoad Report element 9.4.2.123.1 QLoad Report element format The QLoad Report element contains the set of parameters necessary to support OBSS management. The format of the QLoad Report element is provided in Figure 9-496. Potential Allocated EDCA HCCA Element Allocated HCCA Sharing Optional ID Length Traffic Traffic Self Traffic Access Peak Access Overlap Policy Subelements Self Shared Factor Factor Octets: 1 1 5 5 5 1 2 1 1 1 variable Figure 9-496â€”QLoad Report element format The Element ID and Length fields are defined in 9.4.2.1. Potential Traffic Self, Allocated Traffic Self, and Allocated Traffic Shared fields use the QLoad field format as described in 9.4.2.123.2. The Potential Traffic Self field represents the peak composite QoS traffic for this BSS if all of the potential admission control and HCCA TSPECs from the non-AP STAs are active. The methods for gathering the total potential TSPEC information are described in 11.28.2. The Allocated Traffic Self field represents the composite QoS traffic for this BSS based upon all of the admission control and HCCA TSPECs admitted within the same BSS, as described in 11.28.2. The Allocated Traffic Shared field represents the sum of the Allocated Traffic Self field values that have been received or obtained from other APs whose beacons have been detected or obtained within the last 100 beacon periods, plus the Allocated Traffic Self field value of the AP itself. Computation of the values represented in the Allocated Traffic Shared field is described in 11.28.2. 1051 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications As described in 11.28.2, the EDCA Access Factor field value is the sum of the Potential Traffic Self field values that have been received or obtained from other APs, plus the Potential Traffic Self field value of the AP itself, minus the sum of the HCCA Peak field values that have been received or obtained from overlapping APs, minus the HCCA Peak field value of the AP itself. The EDCA Access Factor is expressed as a fraction rounded down to a multiple of 1/64. When the EDCA Access Factor is greater than 254/64, the EDCA Access Factor field is set to 255. The HCCA Peak field is the total peak HCCA TXOP requirement, over a period of 1 s, for the AP and BSS, for all of the HCCA TSPECs that are included in the QLoad. HCCA Peak is expressed in multiples of 32 Âµs over a period of 1 s. The HCCA Peak field is reserved if HCCA is not supported. NOTE Because the HCCA peak is calculated over 1 s periods, its value might be an underestimate of the instantaneous peak of interactive variable bit rate (VBR) flows. The HCCA Access Factor field value is the sum of the HCCA Peak field values in the QLoad Report elements that have been received from the APs of OBSSs, plus the HCCA Peak field value of the AP itself, as described in 11.28.2. It is expressed as a fraction rounded down to a multiple of 1/64. When the HCCA Access Factor is greater than 254/64, the HCCA Access Factor field is set to 255. The Overlap field indicates the number of other APs that are sharing the same channel and whose beacons have been detected or obtained within the last 100 beacon periods by the AP issuing this beacon. The Sharing Policy field contains the currently active sharing policy. The values for the Sharing Policy field are described in Table 9-226. Table 9-226â€”Sharing Policy definitions Sharing Policy field value Current sharing policy 0 Not specified 1 Static 2 Dynamic 3â€“220 Reserved 221 Vendor Specific 222â€“255 Reserved The Optional Subelements field contains zero or more subelements. The subelement format and ordering of subelements are defined in 9.4.3. The Subelement ID field values for the defined subelements are shown in Table 9-227. Table 9-227â€”Optional subelement IDs for QLoad Report element Subelement ID Name Extensible 0â€“220 Reserved 221 Vendor Specific 222â€“255 Reserved 1052 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.123.2 QLoad field format The QLoad field format is described in Figure 9-497. B0 B15 B16 B29 B30 B31 B32 B35 B36 B39 Mean Standard Reserved AC_VO AC_VI Streams Deviation Streams Bits: 16 14 2 4 4 Figure 9-497â€”QLoad field format The Mean subfield represents the amount of time admitted, or the amount of time scheduled traffic requires to access the medium, in units of 32 Âµs per second. In the case of EDCA admission control, this value is the sum of the admitted medium times, and for HCCA it is the total TXOP time required per second (see T.2.2). If the mean medium time is larger than 2 097 088 Âµs (65 534 Ã— 32), the Mean subfield is set to 0xFFFE. The Mean subfield is set to 0xFFFF to indicate that the mean medium time is unknown. The Standard Deviation subfield indicates the standard deviation from the mean medium time, in units of 32 Âµs per second. If the standard deviation is larger than 8128 Âµs (254 Ã— 32), the Standard Deviation subfield is set to 0x3FFE. The Standard Deviation subfield is set to 0x3FFF to indicate that the standard deviation from the mean is unknown. The AC_VO Streams subfield indicates the number of TSs using explicit admission control for AC_VO in the QoS traffic load report. Bidirectional streams are counted as two streams. If the number of admitted AC_VO streams is larger than 14, the AC_VO Streams subfield is set to 0xE. The AC_VO Streams subfield is set to 0xF to indicate that the number of TSs using explicit admission control for AC_VO is unknown. The AC_VI Streams subfield indicates the number of TSs using explicit admission control for AC_VI in the QoS traffic load report. Bidirectional streams are counted as two streams. If the number of TSs using explicit admission control for AC_VO is larger than 14, the AC_VI Streams subfield is set to 0xE. The AC_VI Streams subfield is set to 0xF to indicate that the number of TSs using explicit admission control for AC_VI is unknown. See 11.28.2 and Annex T. 9.4.2.124 HCCA TXOP Update Count element The HCCA TXOP Update Count element is used by an AP to advertise its change in TXOP schedule. The format is provided in Figure 9-498. Element ID Length Update Count Octets: 1 1 1 Figure 9-498â€”HCCA TXOP Update Count element format The Element ID and Length fields are defined in 9.4.2.1. The Update Count field is described in 11.28.3 and is used to indicate that a change has occurred in the number of active HCCA or HEMM TSs. 1053 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.125 Higher Layer Stream ID element The Higher Layer Stream ID element identifies a stream from a higher layer protocol. This element is used to bind messages that are exchanged in order to complete a procedure, e.g., messages exchanged in an AP- initiated TS setup procedure. See 11.4.4.3. The format is provided in Figure 9-499. Element ID Length Protocol ID Organization Higher Layer Identifier Stream ID Octets: 1 1 1 0, 3, or 5 variable Figure 9-499â€”Higher Layer Stream ID element format The Element ID and Length fields are defined in 9.4.2.1. The Protocol ID field identifies the higher layer protocol to which the stream belongs. The values defined for the Protocol ID field are described in Table 9-228. Table 9-228â€”Protocol ID definitions Protocol ID Protocol Description 0 Reserved 1 IEEE 802.1Q SRP Protocol is IEEE 802.1Q SRP, and the corresponding Stream ID is 8 octets long. 2â€“220 Reserved 221 Vendor Specific Corresponding Organization Identifier field is included in the element. 222â€“255 Reserved The Organization Identifier field is present when the Protocol ID field is equal to 221 and contains a organization identifier assigned by IEEE. The identifier is specified in 9.4.1.32. The order of the Organization Identifier field is described in 9.2.2. The Higher Layer Stream ID field is an octet string and is defined by the higher layer protocol specified in the Protocol ID field. 9.4.2.126 GCR Group Address element The GCR Group Address element defines information about group addressed frames to be transmitted using the GCR service. The format of the GCR Group Address element is shown in Figure 9-500. Element ID Length GCR Group Address Octets: 1 1 6 Figure 9-500â€”GCR Group Address element format The Element ID and Length fields are defined in 9.4.2.1. GCR Group Address field is the MAC address of the GCR group. 1054 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.127 DMG BSS Parameter Change element The DMG BSS Parameter Change element is defined in Figure 9-501. Element ID Length Change Type Bitmap TBTT Offset BI Duration Octets: 1 1 1 4 2 Figure 9-501â€”DMG BSS Parameter Change element format The Element ID and Length fields are defined in 9.4.2.1. The Change Type Bitmap field indicates the type of the parameter change to the BSS. This field is defined in Figure 9-502. B0 B1 B2 B7 Move Size Reserved Bits: 1 1 6 Figure 9-502â€”Change Type Bitmap field format If the Move subfield is set to 1, it indicates a change in the TBTT of the BSS. The TBTT is not changed if the Move field is set to 0. If the Size subfield is set to 1, it indicates a change in the beacon interval duration. The beacon interval duration is not changed if the Size subfield is set to 0. The TBTT Offset field contains a value expressed in microseconds. In any DMG BSS Parameter Change element included in the DMG Beacon and/or Announce frame, the value of the TBTT Offset field represents the lower order 4 octets of the AP or PCP TSF timer of the first changed TBTT. The BI Duration field value indicates the beacon interval, expressed in TUs, following the indicated DMG BSS parameter change. The BI Duration field is reserved if the Size bit of the Change Type Bitmap field is set to 0. 9.4.2.128 DMG Capabilities element 9.4.2.128.1 General The DMG Capabilities element contains a STA identifier and several fields that are used to advertise the support of optional DMG capabilities of a DMG STA. The element is present in Association Request, Association Response, Reassociation Request, Reassociation Response, Probe Request and Probe Response frames and can be present in DMG Beacon, Information Request, and Information Response frames. The DMG Capabilities element is formatted as defined in Figure 9-503. Maximum Maximum DMG STA DMG AP Or Element STA PCP DMG STA Extended Number Of Number Of Length AID Capability ID Address Capability BeamTracking SC MCS Basic A-MSDU Short A-MSDU Information TimeLimit Capabilities Subframes In Subframes In Information A-MSDU A-MSDU Octets: 1 1 6 1 8 2 2 1 1 1 Figure 9-503â€”DMG Capabilities element format The Element ID and Length fields are defined in 9.4.2.1. 1055 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The STA Address field contains the MAC address of the STA. The AID field contains the AID assigned to the STA by the AP or PCP. The AID field is reserved in Association Request, Reassociation Request and Probe Request frames and when used in an IBSS. 9.4.2.128.2 DMG STA Capability Information field The DMG STA Capability Information field, shown in Figure 9-504, represents the transmitting STA capabilities irrespective of the role of the STA. B0 B1 B2 B3 B4 B5 B6 B7 B13 Higher Layer SPSH and Number of Total Reverse Timer TPC Interference RX DMG Fast Link Number of Direction Adaptation Synchronization Mitigation Antennas Sectors Bit: 1 1 1 1 2 1 7 B14 B19 B20 B21 B26 B27 B28 B51 B52 RXSS DMG A-MPDU BA with Supported DTP Antenna Flow Length Reciprocity Parameters Control MCS Set Supported Bit: 6 1 6 1 24 1 B53 B54 B55 B56 B57 B59 B60 B61 B62 B63 Antenna Heartbeat RXSSTxR A-PPDU Supports Grant Ack Supported Heartbeat Other_AID Pattern Elapsed Supported ate Reserved Reciprocity Indication Supported Bit: 1 1 1 1 3 1 1 2 Figure 9-504â€”DMG STA Capability Information field format The Reverse Direction subfield is set to 1 if the STA supports RD as defined in 10.28 and is set to 0 otherwise. The Higher Layer Timer Synchronization subfield is set to 1 if the STA supports Higher Layer Timer Synchronization as defined in 11.6 and is set to 0 otherwise. The TPC subfield is set to 1 if the STA supports the TPC as defined in 11.8 and is set to 0 otherwise. The SPSH (spatial sharing) and Interference Mitigation subfield is set to 1 if the STA is capable of performing the function of SPSH and Interference Mitigation and if dot11RadioMeasurementActivated is true and is set to 0 otherwise (see 11.32). The Number of RX DMG Antennas subfield indicates the total number of receive DMG antennas of the STA. The value of this subfield is in the range 1 to 4, with the value being equal to the bit representation plus 1. The Fast Link Adaptation subfield is set to 1 to indicate that the STA supports the fast link adaptation procedure described in 10.39.3. Otherwise, it is set to 0. 1056 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Total Number of Sectors subfield indicates the total number of transmit sectors the STA uses in a transmit sector sweep combined over all DMG antennas, including any LBIFS required for DMG antenna switching (see 10.38). The value of this subfield is in the range 1 to 128, with the value being equal to the bit representation plus 1. The value represented by the RXSS Length subfield specifies the total number of receive sectors combined over all receive DMG antennas of the STA, including any LBIFS required for DMG antenna switching (see 10.38). The value represented by this subfield is in the range 2 to 128 and is given by (RXSS Length+1)Ã—2. The DMG Antenna Reciprocity subfield is set to 1 to indicate that the best transmit DMG antenna of the STA is the same as the best receive DMG antenna of the STA and vice versa. Otherwise, this subfield is set to 0. The A-MPDU Parameters subfield is shown in Figure 9-505. B0 B2 B3 B5 Maximum A-MPDU Minimum MPDU Length Exponent Start Spacing Bits: 3 3 Figure 9-505â€”A-MPDU parameters subfield format The subfields of the A-MPDU Parameters subfield are defined in Table 9-229. Table 9-229â€”Subfields of the A-MPDU Parameters subfield Subfield Definition Encoding Maximum A-MPDU Indicates the maximum length of This subfield is an integer in the range 0 to 5. Length Exponent A-MPDU that the STA can The length defined by this subfield is equal to receive. 2(13 + Maximum A-MPDU Length Exponent) â€“ 1 octets. Minimum MPDU Start Determines the minimum time Set to 0 for no restriction Spacing between the start of adjacent Set to 1 for 16 ns MPDUs within an A-MPDU that Set to 2 for 32 ns the STA can receive, measured at Set to 3 for 64 ns the PHY SAP. Set to 4 for 128 ns Set to 5 for 256 ns Set to 6 for 512 ns Set to 7 for 1024 ns The BA with Flow Control subfield is set to 1 if the STA supports BA with flow control as defined in 10.39 and is set to 0 otherwise. The Supported MCS Set subfield indicates which MCSs a STA supports. An MCS is identified by an MCS index, which is represented by an integer in the range 0 to 31 or by one of the values 9.1, 12.1, 12.2, 12.3, 12.4, 12.5 and 12.6. The interpretation of the MCS index (i.e., the mapping from MCS to data rate) is PHY dependent. For the DMG PHY, see Clause 20. The structure of the Supported MCS Set subfield is defined in Figure 9-506. 1057 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B0 B4 B5 B9 B10 B14 B15 B19 B20 B21 B22 B23 Maximum Maximum Low-Power Maximum SC OFDM Rx Maximum OFDM Tx SC Mode Code Rate Reserved Rx MCS SC Tx MCS 13/16 MCS MCS Supported Bits: 5 5 5 5 1 1 2 Figure 9-506â€”Supported MCS Set subfield format The Maximum SC Rx MCS subfield contains the value of the maximum MCS index the STA supports for reception of single-carrier frames. Values 0-3 of this subfield are reserved. Possible values for this subfield are shown in Table 20-19. This subfield does not indicate support for MCSs 9.1, 12.1, 12.2, 12.3, 12.4, 12.5 and 12.6. Support for these MCSs is indicated using the Extended SC MCS Capabilities field; see 9.4.2.128.5. The Maximum OFDM Rx MCS subfield contains the value of the maximum MCS index the STA supports for reception of OFDM frames. If this subfield is set to 0, it indicates that the STA does not support reception of OFDM frames. Values 1â€“17 of this subfield are reserved. Possible values for this subfield are described in 20.5.3.1.2. The Maximum SC Tx MCS subfield contains the value of the maximum MCS index the STA supports for transmission of single-carrier frames. Values 0-3 of this subfield are reserved. Possible values for this subfield are shown in Table 20-19. This subfield does not indicate support for MCSs 9.1, 12.1, 12.2, 12.3, 12.4, 12.5 and 12.6. Support for these MCSs is indicated using the Extended SC MCS Capabilities field; see 9.4.2.128.5. The Maximum OFDM Tx MCS subfield contains the value of the maximum MCS index the STA supports for transmission of OFDM frames. If this subfield is set to 0, it indicates that the STA does not support transmission of OFDM frames. Values 1â€“17 of this subfield are reserved. Possible values for this subfield are described 20.5.3.1.2. The Low-Power SC Mode Supported subfield is set to 1 to indicate that the STA supports the DMG low- power SC mode (20.7). Otherwise, it is set to 0. If the STA supports the low-power SC mode, it supports all low-power SC mode MCSs indicated in Table 20-23. The Code Rate 13/16 subfield specifies whether the STA supports rate 13/16. It is set to 1 to indicate that the STA supports rate 13/16 and is set to 0 otherwise. If this subfield is 0, MCSs with 13/16 code rate specified in Table 20-14 and Table 20-19 are not supported regardless of the value in Maximum SC/OFDM Tx/Rx MCS subfields. The DTP Supported subfield is set to 1 to indicate that the STA supports DTP as described in 10.40 and 20.5.3.2.4.6.3. Otherwise, it is set to 0. The A-PPDU Supported subfield is set to 1 to indicate that the STA supports A-PPDU aggregation as described in 10.15. Otherwise, it is set to 0. The Supports Other_AID subfield is set to 1 to indicate that the STA sets its AWV configuration according to the Other_AID subfield in the BRP Request field during the BRP procedure as described in 10.38.6.4.4 and 20.10.2.2.6, if the value of the Other_AID subfield is different from zero. Otherwise, this subfield is set to 0. The Heartbeat subfield is set to 1 to indicate that the STA expects to receive a frame from the AP or PCP during the ATI (10.36.3) and expects to receive a frame with the DMG Control modulation from a source DMG STA at the beginning of an SP (10.36.6.2) or TXOP (10.22.2). Otherwise, it is set to 0. 1058 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Antenna Pattern Reciprocity subfield is set to 1 to indicate that the transmit antenna pattern associated with an AWV is the same as the receive antenna pattern for the same AWV. Otherwise, this subfield is set to 0. The Heartbeat Elapsed Indication subfield is used to calculate the value of the Heartbeat Elapsed Time. The Heartbeat Elapsed Time is computed according to the following equation: 0 F HE = 0 T HE = F HE 2 - --------- F HE 0 4 where THE is the Heartbeat Elapsed Time (in milliseconds) FHE is the value of the Heartbeat Elapsed Indication subfield The Grant Ack Supported subfield is set to 1 to indicate that the STA is capable of responding to a Grant frame with a Grant Ack frame. Otherwise, this subfield is set to 0. The RXSSTxRate Supported subfield is set to 1 to indicate that the STA can perform an RXSS with SSW frames transmitted at MCS 1 of the DMG SC modulation class. Otherwise, it is set to 0. 9.4.2.128.3 DMG AP Or PCP Capability Information field The DMG AP Or PCP Capability Information field, illustrated in Figure 9-507, represents the capabilities when the transmitting STA performs in the role of AP or PCP and that are in addition to the capabilities in the DMG STA Capability Information field. B0 B1 B2 B3 B10 B11 TDDTI Pseudo-static PCP Handover MAX Associated STA Power Source Allocations Number Bit: 1 1 1 8 1 B12 B13 B14 B15 Decentralized AP or PCP Centralized AP or PCP Clustering PCP Forwarding Clustering Reserved Bit: 1 1 1 1 Figure 9-507â€”DMG AP Or PCP Capability Information field format The TDDTI (time division data transfer interval) subfield is set to 1 if the STA, while operating as an AP or PCP, is capable of providing channel access as defined in 10.36.6 and 11.4 and is set to 0 otherwise. The Pseudo-static Allocations subfield is set to 1 if the STA, while operating as an AP or PCP, is capable of providing pseudo-static allocations as defined in 10.36.6.4 and is set to 0 otherwise. The Pseudo-static Allocations subfield is set to 1 only if the TDDTI subfield in the DMG AP Or PCP Capability Information field is set to 1. The Pseudo-static Allocations subfield is reserved if the TDDTI subfield in the DMG AP Or PCP Capability Information field is set to 0. 1059 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The PCP Handover subfield is set to 1 if the STA, while operating as a PCP, is capable of performing a PCP Handover as defined in 11.29.2 and is set to 0 if the STA does not support PCP Handover. The MAX Associated STA Number subfield indicates the maximum number of STAs that the STA can perform association with if operating as an AP or PCP. The value of this subfield includes the STAs, if any, that are co-located with the AP or PCP. The Power Source subfield is set to 0 if the STA is battery powered and is set to 1 otherwise. The Decentralized AP or PCP Clustering subfield is set to 1 if the STA, when operating as an AP or PCP, is capable of performing decentralized AP or PCP clustering and is set to 0 otherwise. The PCP Forwarding subfield is set to 1 if the STA, while operating as a PCP, is capable of forwarding frames it receives from a non-PCP STA and destined to another non-PCP STA in the PBSS. This subfield is set to 0 otherwise. The Centralized AP or PCP Clustering subfield is set to 1 if the STA, when operating as an AP or PCP, is capable of performing centralized AP or PCP clustering and is set to 0 otherwise. An AP or PCP that is incapable of performing centralized AP or PCP clustering is subject to requirements as described in 10.37.2.2. 9.4.2.128.4 DMG STA Beam Tracking Time Limit field The BeamTrackingTimeLimit subfield contains the value of dot11BeamTrackingTimeLimit. The resulting value of dot11BeamTrackingTimeLimit of beam link established between peer STAâ€™s is negotiated following rules presented in Table 9-230. Table 9-230â€”Beam Tracking Time Limit negotiation dot11BeamTracking TimeLimit DMG STA DMG STA (STA-A) vs. BeamTrackingTimeLimit BeamTrackingTimeLimit Result dot11BeamTracking (STA-A) (STA-B) TimeLimit (STA-B) 0 0 NA Beam tracking is not supported >0 0 NA 0 >0 NA >0 and < 65 535 >0 and < 65 535 >, = dot11BeamTrackingTimeLimit (STA-A) >0 and < 65 535 >0 and < 65 535 < dot11BeamTrackingTimeLimit (STA-B) 65 535 >0 and < 65 535 NA dot11BeamTrackingTimeLimit (STA-B) >0 and < 65 535 65 535 NA dot11BeamTrackingTimeLimit (STA-A) 65 535 65 535 NA Default dot11BeamTrackingTimeLimit value 1060 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NOTEâ€”In Table 9-230 STA-A and STA-B refer to any of the STAs performing the Beam Tracking Time Limit negotiation procedure in no particular order. 9.4.2.128.5 Extended SC MCS Capabilities field The Extended SC MCS Capabilities field (see Figure 9-508) advertises the support of the STA for MCSs 9.1, 12.1, 12.2, 12.3, 12.4, 12.5 and 12.6. B0 B2 B3 B4 B6 B7 Maximum Code Rate 7/8 Maximum Code Rate 7/8 Extended SC Tx Tx Extended SC Rx Rx MCS MCS Bits: 3 1 3 1 Figure 9-508â€”Extended SC MCS Capabilities field The Maximum Extended SC Tx MCS subfield indicates the maximum transmit extended SC MCS supported by the STA. The values in the subfield are ordered as shown in Table 9-231. Table 9-231â€”Mapping of Extended SC MCS to Maximum Supported Rx/Tx MCS subfield values Value in Maximum Extended MCS name Extended SC Rx/Tx MCS field None 0 MCS 9.1 1 MCS 12.1 2 MCS 12.2 3 MCS 12.3 4 MCS 12.4 5 MCS 12.5 6 MCS 12.6 7 A STA that indicates support for transmission of an extended SC MCS by setting the value in the Maximum Extended SC Tx MCS subfield to k supports the subset of MCSs {9.1, 12.1, 12.2, 12.3, 12.4, 12.5 12.6} that have a data rate lower than or equal to the data rate of the MCS indicated by k. A STA that indicates support for MCSs with a data rate higher than the data rate of MCS 9.1 in the Maximum Extended SC Tx MCS subfield shall set the value of the Maximum SC Tx MCS subfield of the Supported MCS Set subfield to 12. A STA that indicates support for transmission of an extended SC MCS by setting the value in the Maximum Extended SC Tx MCS subfield to k supports all extended SC MCSs with values lower than or equal to k. The Maximum Extended SC Rx MCS subfield indicates the maximum receive extended SC MCS supported by the STA. The values in the subfield are ordered as shown in Table 9-231. A STA indicates support for transmission of code rate 7/8 by setting the Code Rate 7/8 Tx subfield to 1. If a STA indicates that it does not support code rate 7/8, then the STA does not support MCS 9.1 or 12.2 even if the value in the Maximum Extended SC Tx MCS subfield is greater than 1 or 3 respectively. A STA that 1061 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications indicates support for MCSs with a data rate higher than the data rate of MCS 9.1 in the Maximum Extended SC Rx MCS subfield shall set the value of the Maximum SC Rx MCS subfield of the Supported MCS Set subfield to 12. A STA that indicates support for reception of an extended SC MCS by setting the value in the Maximum Extended SC Rx MCS subfield to k supports the subset of MCSs {9.1, 12.1, 12.2, 12.3, 12.4, 12.5 12.6} that have a data rate lower than or equal to the data rate of the MCS indicated by k. A STA indicates support for reception of code rate 7/8 by setting the Code Rate 7/8 Rx subfield to 1. If a STA indicates that it does not support code rate 7/8, the STA does not support MCS 9.1 or 12.2 even if the value in the Maximum Extended SC Rx MCS field is greater than 1 or 3 respectively. 9.4.2.128.6 Maximum number of A-MSDU subframes in an A-MSDU The Maximum Number Of Basic A-MSDU Subframes In A-MSDU subfield is defined in Table 9-232 and indicates the maximum number of Basic A-MSDU subframes in an A-MSDU that the DMG STA is able to receive from another DMG STA. Table 9-232â€”Maximum Number Of Basic A-MSDU Subframes In A-MSDU subfield Value Meaning 0 No limit on the maximum number of Basic A-MSDU subframes supported 1 A maximum of 4 Basic A-MSDU subframes are supported 2 A maximum of 8 Basic A-MSDU subframes are supported 3 A maximum of 16 Basic A-MSDU subframes are supported 4 A maximum of 32 Basic A-MSDU subframes are supported 5 A maximum of 64 Basic A-MSDU subframes are supported 6 A maximum of 128 Basic A-MSDU subframes are supported 7 A maximum of 256 Basic A-MSDU subframes are supported 8â€“255 Reserved The Maximum Number Of Short A-MSDU Subframes In A-MSDU subfield is defined in Table 9-233 and indicates the maximum number of Short A-MSDU subfields in an A-MSDU that the DMG STA is able to receive from another DMG STA. Table 9-233â€”Maximum Number Of Short A-MSDU Subframes In A-MSDU subfield Value Meaning 0 No limit on the maximum number of Short A-MSDU subframes supported 1 A maximum of 32 Short A-MSDU subframes are supported 2 A maximum of 64 Short A-MSDU subframes are supported 3 A maximum of 128 Short A-MSDU subframes are supported 1062 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-233â€”Maximum Number Of Short A-MSDU Subframes In A-MSDU subfield (continued) Value Meaning 4 A maximum of 256 Short A-MSDU subframes are supported 5 A maximum of 512 Short A-MSDU subframes are supported 6 A maximum of 1024 Short A-MSDU subframes are supported 7â€“255 Reserved 9.4.2.129 DMG Operation element The operational parameters of a BSS provided by the AP or PCP are determined by the DMG Operation element defined in Figure 9-509. Element ID Length DMG Operation Information DMG BSS Parameter Configuration Octets: 1 1 2 8 Figure 9-509â€”DMG Operation element format The Element ID and Length fields are defined in 9.4.2.1. The DMG Operation Information field is shown in Figure 9-510. B0 B1 B2 B3 B15 TDDTI Pseudo-static allocations PCP Handover Reserved Bits: 1 1 1 13 Figure 9-510â€”DMG Operation Information field format The TDDTI subfield is set to 1 if the AP or PCP provides time division channel access as defined in 10.36.6 and is set to 0 otherwise. The Pseudo-static allocations subfield is set to 1 if the AP or PCP provides pseudo-static allocations as defined in 10.36.6.4 and is set to 0 otherwise. The Pseudo-static allocations subfield is set to 1 only if the TDDTI subfield in the DMG Operation Information field is 1. The Pseudo-static allocations subfield is reserved if the TDDTI subfield in the DMG Operation Information field is 0. The PCP Handover subfield is set to 1 if the PCP provides PCP Handover as defined in 11.29.2 and is set to 0 if the PCP does not provide PCP Handover. 1063 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The DMG BSS Parameter Configuration field is defined in Figure 9-511. PSRequestSuspensionInterval MinBHIDuration BroadcastSTAInfoDuration AssocRespConfirmTime Octets: 1 2 1 1 MinPPDuration SPIdleTimeout MaxLostBeacons Octets: 1 1 1 Figure 9-511â€”DMG BSS Parameter Configuration field format The PSRequestSuspensionInterval subfield indicates the power save suspension interval and is specified in number of beacon intervals. The MinBHIDuration subfield indicates the minimum duration of the BHI, which can include the BTI, A- BFT, and ATI and is specified in microseconds. The BroadcastSTAInfoDuration subfield indicates the amount of time that the AP or PCP expects to take to transmit information about associated STAs and is specified in number of beacon intervals. The AssocRespConfirmTime subfield indicates the amount of time that the AP or PCP expects to take to respond to association requests and is specified in units of 50 milliseconds. A non-PCP and non-AP STA that receives a DMG Operation element can use the value of this field to set dot11AssociationResponseTimeOut. The MinPPDuration subfield indicates the minimum duration of the PP and GP as part of the dynamic allocation of service period mechanism and is specified in microseconds. The SPIdleTimeout subfield indicates time during which a STA expects to receive a frame from its peer STA and is specified in microseconds. The MaxLostBeacons subfield contains the value of dot11MaxLostBeacons. 9.4.2.130 DMG Beam Refinement element The DMG Beam Refinement element is defined as shown in Figure 9-512. B0 B7 B8 B15 B16 B17 B18 B19 B20 Element ID Length Initiator TX-train- RX-train- TX-TRN-OK TXSS-FBCK-REQ response response Bits: 8 8 1 1 1 1 1 B21 B26 B27 B28 B29 B33 B34 B51 B52 B53 B54 B55 BS-FBCK BS-FBCK Antenna FBCK-REQ FBCK-TYPE MID Capability Reserved Extension Request ID Bits: 6 2 5 18 1 1 2 Figure 9-512â€”DMG Beam Refinement element format 1064 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Element ID and Length fields are defined in 9.4.2.1. A value of 1 in the Initiator field indicates that the sender is the beam refinement initiator. Otherwise, this field is set to 0. A value of 1 in the TX-train-response field indicates that this packet is the response to a TX training request. Otherwise, this field is set to 0. A value of 1 in the RX-train-response field indicates that the packet serves as an acknowledgment for a RX training request. Otherwise, this field is set to 0. A value of 1 in the TX-TRN-OK field confirms a previous training request received by a STA. Otherwise, this field is set to 0. A value of 1 in the TXSS-FBCK-REQ field indicates a request for transmit sector sweep feedback. The BS-FBCK field indicates the index of the TRN-T field that was received with the best quality in the last received BRP-TX PPDU, where the first TRN-T field in the PPDU is defined as having an index equal to 1. If the last received PPDU was not a BRP-TX PPDU, this field is set to 0. The determination of best quality is implementation dependent. The BS-FBCK Antenna ID field specifies the antenna ID corresponding to the sector indicated by the BF- FBCK field. The FBCK-REQ field is defined in Figure 9-513 and is described in Table 9-234. B29 B30 B31 B32 B33 Channel Measurement Sector ID Order SNR Requested Requested Number of Taps Requested Requested Bits: 1 1 2 1 Figure 9-513â€”FBCK-REQ field format Table 9-234â€”FBCK-REQ field description Subfield Meaning SNR Requested If set to 1, the SNR subfield is requested as part of the channel measurement feedback. Otherwise, set to 0. Channel Measurement If set to 1, the Channel Measurement subfield is requested as part of the channel Requested measurement feedback. Otherwise, set to 0. Number of Taps Requested Number of taps in each channel measurement: 0x0 â€“ 1 tap 0x1 â€“ 5 taps 0x2 â€“ 15 taps 0x3 â€“ 63 taps Sector ID Order Requested If set to 1, the Sector ID Order subfield is requested as part of the channel measurement feedback. Otherwise, set to 0. 1065 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The FBCK-TYPE field is defined in Figure 9-514 and is described in Table 9-235. When both Nmeas and Nbeam in this field are equal to 0, the Channel Measurement Feedback element is not present. B34 B35 B36 B37 B38 B39 B45 B46 B47 B48 B49 B51 SNR Channel Tap Delay Number of Number of Sector ID Link Antenna Number Measurement Taps Order Present Present Present Present Measurements Present Type Type of Beams Bits: 1 1 1 2 7 1 1 1 3 Figure 9-514â€”FBCK-TYPE field format Table 9-235â€”FBCK-TYPE field description Subfield Meaning SNR Present Set to 1 to indicate that the SNR subfield is present as part of the channel measurement feedback. Set to 0 otherwise. Channel Measurement Set to 1 to indicate that the Channel Measurement subfield is present as part of the Present channel measurement feedback. Set to 0 otherwise. Tap Delay Present Set to 1 to indicate that the Tap Delay subfield is present as part of the channel measurement feedback. Set to 0 otherwise. Number of Taps Number of taps in each channel measurement: Present 0x0 â€“ 1 tap 0x1 â€“ 5 taps 0x2 â€“ 15 taps 0x3 â€“ 63 taps Number of Number of measurements in the SNR subfield and the Channel Measurement subfield. Measurements It is equal to the number of TRN-T subfields in the BRP-TX packet on which the measurement is based, or the number of received sectors if TXSS result is reported by setting the TXSS-FBCK-REQ subfield to 1. Sector ID Order Set to 1 to indicate that the Sector ID Order subfield is present as part of the channel Present measurement feedback. Set to 0 otherwise. Link Type Set to 0 for the initiator link and to 1 for the responder link Antenna Type Set to 0 for the transmitter antenna and to 1 for the receiver antenna Number of Beams Indicates the number of beams in the Sector ID Order subfield for the MIDC subphase A value of 1 in the MID Extension field indicates the intention to continue transmitting BRP-RX packets during the MID subphases. Otherwise, this field is set to 0. A value of 1 in the Capability Request field indicates that the transmitter of the frame requests the intended receiver to respond with a BRP frame that includes the BRP Request field. Otherwise, this field is set to 0. 9.4.2.131 DMG Wakeup Schedule element The DMG Wakeup Schedule element is defined in Figure 9-515. 1066 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Element ID Length BI Start Time Sleep Cycle Number of Awake BIs Octets: 1 1 4 2 2 Figure 9-515â€”DMG Wakeup Schedule element format The Element ID and Length fields are defined in 9.4.2.1. The DMG Wakeup Schedule element is used to communicate the wakeup schedule (WS) of DMG STAs. The BI Start Time field indicates the lower order 4 octets of the TSF timer at the start of the first awake BI in the WS defined by the DMG Wakeup Schedule element. A transmitted BI Start Time field points to a TBTT not more than 231 Âµs minus aDMGDWSValidPeriod before, and not more than (231 â€“ 1) Âµs after the TBTT of the beacon interval during which the BI Start Time field is transmitted. NOTEâ€”The delay between the moment a STA receives a DMG Wakeup Schedule element over the air and the moment the STA interprets the value of the BI Start Time field in the element can be large, to the extent that the beacon interval during which the BI Start Time filed is interpreted is different from the beacon interval during which the DMG Wakeup Schedule element is received. Excluding an interval from the range of BI Start Time values at transmission enables the receiving STA to be able to correctly interpret any received value for the BI Start Time field of the DMG Wakeup Schedule element belonging to a STA in PS mode without having to remember the beacon interval during which the DMG Wakeup Schedule element was received, as long as the beginning of the beacon interval at the time of interpretation has not advanced more than aDMGDWSValidPeriod relative to the beginning of the beacon interval at the time of reception. The Sleep Cycle field indicates the sleep cycle duration in beacon intervals, i.e., the sum of awake BIs and doze BIs that make up the sleep cycle. The Number of Awake BIs field indicates the number of awake BIs at the beginning of each sleep cycle. A value of 0 for this field indicates that all BIs in the WS are doze BIs. 9.4.2.132 Extended Schedule element The Extended Schedule element is defined in Figure 9-516. Because the length parameter supports only 255 octets of information in an element, the AP or PCP can split the Allocation fields into more than one Extended Schedule element entry in the same DMG Beacon or Announce frame. Despite this splitting, the set of Extended Schedule element entries conveyed within a DMG Beacon and Announce frame is considered to be a single schedule for the beacon interval, and in this standard referred to simply as Extended Schedule element unless otherwise noted. The Allocation fields are ordered by increasing allocation start time with allocations beginning at the same time arbitrarily ordered. Element ID Length Allocation 1 Allocation 2 â€¦ Allocation n Octets: 1 1 15 15 â€¦ 15 Figure 9-516â€”Extended Schedule element format The Element ID and Length fields are defined in 9.4.2.1. The Allocation field is formatted as illustrated in Figure 9-517. 1067 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Allocation Allocation Allocation BF Source Destination Allocation Block Number Block Control Control AID AID Start of Blocks Duration Period Octets: 2 2 1 1 4 2 1 2 Figure 9-517â€”Allocation field format The Allocation Control subfield is defined in Figure 9-518. B0 B3 B4 B6 B7 B8 B9 B10 B11 B12 B15 Allocation Allocation Pseudo- PCP LP SC ID Type static Truncatable Extendable Active Used Reserved Bits: 4 3 1 1 1 1 1 4 Figure 9-518â€”Allocation Control subfield format The Allocation ID subfield, when set to a nonzero value, identifies an airtime allocation from Source AID to Destination AID. Except for CBAP allocations with broadcast Source AID and broadcast Destination AID, the tuple (Source AID, Destination AID, Allocation ID) uniquely identifies the allocation. For CBAP allocations with broadcast Source AID and broadcast Destination AID, the Allocation ID subfield is set to zero. The AllocationType subfield defines the channel access mechanism during the allocation, with possible values listed in Table 9-236. Table 9-236â€”AllocationType subfield values Bit 4 Bit 5 Bit 6 Meaning 0 0 0 SP allocation 1 0 0 CBAP allocation All other combinations Reserved The Pseudo-static subfield is set to 1 to indicate that this allocation is pseudo-static (10.36.6.4) and set to 0 otherwise. For an SP allocation, the Truncatable subfield is set to 1 to indicate that the source DMG STA and destination DMG STA can request SP truncation and set to 0 otherwise. For a CBAP allocation, the Truncatable subfield is reserved. For an SP allocation, the Extendable subfield is set to 1 to indicate that the source DMG STA and destination DMG STA can request SP extension and set to 0 otherwise. For a CBAP allocation, the Extendable subfield is reserved. For a PCP in active mode (see 11.2.7), or when applied to a CBAP or SP in a PCP awake BI, a value of 1 for the PCP Active subfield indicates that the PCP is available to transmit or receive during the CBAP or SP, and a value of 0 indicates the PCP unavailability to transmit or receive. The PCP Active subfield is set to 1 at least in the following cases: 1068 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” The PCP transmitting the subfield is the source or destination of the CBAP or SP â€” At least one of the Truncatable or Extendable subfields is set to 1 â€” The subfield is transmitted by an AP The value of the PCP Active subfield is ignored when it applies to a CBAP or SP that resides in a PCP doze BI. The BF Control subfield is defined in 9.5.5. The Source AID subfield is set to the AID of the STA that initiates channel access during the SP or CBAP allocation or, in the case of a CBAP allocation, can also be set to the broadcast AID if all STAs are allowed to transmit during the CBAP allocation. The Destination AID subfield is set to the AID of the STA that the source STA targets during the allocation, or to the broadcast AID if the source STA targets more than one STA during the allocation. If both Source AID and Destination AID subfields for an SP allocation are set to the broadcast AID, then during the SP a non-AP and non-PCP STA does not transmit unless it receives a Poll or Grant frame from the AP or PCP. The Allocation Start subfield contains the lower 4 octets of the TSF at the time the SP or CBAP starts. The Allocation Start subfield can be specified at a future beacon interval when the pseudo-static subfield is set to 1. The Allocation Block Duration subfield indicates the duration, in microseconds, of a time block for which the SP or CBAP allocation is made and cannot cross beacon interval boundaries. Possible values range from 1 to 32 767 for an SP allocation and 1 to 65 535 for a CBAP allocation. The Number of Blocks subfield contains the number of time blocks making up the allocation. The Allocation Block Period subfield contains the time, in microseconds, between the start of two consecutive time blocks belonging to the same allocation. The Allocation Block Period subfield is reserved when the Number of Blocks subfield is set to 1. The LP SC Used subfield is set to 1 to indicate that the low-power SC mode described in 20.7 is used in this SP. Otherwise, it is set to 0. 9.4.2.133 STA Availability element The STA Availability element is used by a non-AP and non-PCP STA to inform an AP or PCP about the STA availability during the subsequent CBAPs (10.36.5) and to indicate participation in the dynamic allocation of service periods (10.36.7). The AP or PCP uses the STA Availability element to inform the non- AP and non-PCP STAs of other STAs availability during subsequent CBAPs and participation of other STAs in the Dynamic allocation of service periods. The format of the STA Availability element is defined in Figure 9-519. Element ID Length STA Info 1 â€¦ STA Info n Octets: 1 1 2 â€¦ 2 Figure 9-519â€”STA availability element format The Element ID and Length fields are defined in 9.4.2.1. 1069 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The format of the STA Info field is shown in Figure 9-520. B0 B7 B8 B9 B10 B15 AID CBAP PP Available Reserved Bits: 8 1 1 6 Figure 9-520â€”STA Info field format The AID subfield contains the AID of the STA for which availability is indicated. The CBAP subfield is set to 1 to indicate that the STA is available to receive transmissions during CBAPs and set to 0 otherwise. The PP Available subfield is set to 1 to indicate that the STA is available during PPs (10.36.7) and is set to 0 otherwise. 9.4.2.134 DMG TSPEC element The DMG TSPEC element is present in the ADDTS Request frame sent by a non-AP and non-PCP DMG STA and contains the set of parameters needed to create or modify an airtime allocation. The DMG TSPEC element is also present in the ADDTS Response frame sent by a DMG AP or PCP and reflects the parameters, possibly modified, by which the allocation was created. The format of the DMG TSPEC element is shown in Figure 9-521. Element ID Length DMG Allocation Info BF Control Allocation Period Octets: 1 1 4 2 2 Minimum Maximum Minimum Number of Traffic Scheduling Allocation Allocation Duration Constraints Constraint Set Octets: 2 2 2 1 Variable Figure 9-521â€”DMG TSPEC element format The Element ID and Length fields are defined in 9.4.2.1. The DMG Allocation Info field is formatted as shown in Figure 9-522. The Allocation ID subfield identifies an allocation if set to a nonzero value and is used as follows: â€” The STA that transmits an ADDTS Request frame containing the DMG TSPEC element sets the Allocation ID subfield to a nonzero value to create a new allocation or modify an existing allocation. â€” The STA that transmits an ADDTS Response frame containing the DMG TSPEC element sets the Allocation ID subfield to a nonzero value to identify a created or modified allocation or sets it to 0 if creating or modifying the allocation failed. 1070 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B0 B3 B4 B6 B7 B8 B9 Allocation Pseudo- Allocation ID AllocationType Truncatable Format static Bits: 4 3 1 1 1 B10 B11 B12 B14 B15 B22 B23 B30 B31 Extendable LP SC UP Destination AID Source AID Reserved Used Bits: 1 1 3 8 8 1 Figure 9-522â€”DMG Allocation Info field format The AllocationType subfield defines the channel access mechanism used during the allocation, with values listed in Table 9-236. The Allocation Format field values are listed in Table 9-237. Table 9-237â€”Allocation Format subfield values Allocation Format subfield Description value 1 Isochronous allocation format 0 Asynchronous allocation format The Pseudo-static subfield is set to 1 for a pseudo-static allocation and set to 0 otherwise. For an SP allocation, the Truncatable subfield is set to 1 if the STA expects to truncate the SP, as described in 10.36.8. If the STA does not expect to truncate the SP, the Truncatable subfield is set to 0. The subfield is reserved for CBAP allocations. For an SP allocation, the Extendable subfield is set to 1 if the STA expects to extend the SP, as described in 10.36.9. If the STA does not expect to extend the SP, the Extendable subfield is set to 0. The subfield is reserved for CBAP allocations. The LP SC Used subfield is defined in 9.4.2.132. The UP subfield indicates the lowest priority UP to be used for possible transport of MSDUs belonging to TCs with the same source and destination of the allocation. The Destination AID subfield contains the AID of a STA that the requesting STA targets during the allocation. The Source AID subfield contains the AID of the STA that initiates channel access during the allocation. The BF Control subfield is defined in 9.5.5. 1071 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Allocation Period is specified as a fraction or multiple of the beacon interval (BI) as defined in Table 9-238. Table 9-238â€”Allocation Period field values B0â€“B14 B15 Meaning 0 0 Reserved 0 1 Not periodic or periodicity unknown 1â€“32 767 0 The allocation period is a multiple of the BI, i.e., allocation period = n x BI where n is the value represented by B0â€“B14 1â€“32 767 1 The allocation period is a fraction of the BI, i.e., allocation period = BI/n where n is the value represented by B0â€“B14. For isochronous allocation format requests the Allocation Period, Minimum Allocation and Maximum Allocation fields are set as follows: â€” The Allocation Period field indicates the period over which the allocation repeats. â€” The Minimum Allocation field is set to the minimum acceptable allocation in microseconds in each allocation period. â€” The Maximum Allocation field is set to the requested allocation in microseconds in each allocation period. For asynchronous allocation format requests the Maximum Allocation field is reserved, and the Allocation Period and Minimum Allocation fields are set as follows: â€” The Allocation Period field indicates the period over which the minimum allocation applies. The Allocation Period is an integer multiple of the beacon interval. â€” The Minimum Allocation field specifies the minimum allocation in microseconds that the STA expects within the allocation period. The Minimum Duration field specifies the minimum acceptable duration in microseconds. Possible values range from 1 to 32 767 for an SP allocation and 1 to 65 535 for a CBAP allocation. A value of 0 indicates no minimum specified. The Number of Constraints field indicates the number of Constraint subfields contained in the element. The value of this field ranges from 0 to 15. Other values are reserved. The Traffic Scheduling Constraint Set field contains one or more Constraint subfields (see Figure 9-523). One or more Constraint subfields Octets: Variable Figure 9-523â€”Traffic Scheduling Constraint Set field format The Constraint subfield is defined as illustrated in Figure 9-524. 1072 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications TSCONST Start Time TSCONST Duration TSCONST Period Interferer MAC address Octets: 4 2 2 6 Figure 9-524â€”Constraint subfield format The TSCONST Start Time subfield contains the lower 4 octets of the TSF at the time the scheduling constraint starts. The TSCONST Duration subfield indicates the time, in microseconds, for which the scheduling constraint is specified. The TSCONST Period subfield is specified as a fraction or multiple of the beacon interval (BI) as defined in Table 9-239. This subfield is used to indicate a periodic scheduling constraint by specifying the temporal gap between two consecutive scheduling constraints. Table 9-239â€”TSCONST Period values B0â€“B14 B15 Meaning 0 0 Reserved 0 1 Not periodic or periodicity unknown 1â€“32 767 0 The TSCONST period is a multiple of the BI, i.e., TSCONST period = n x BI where n is the value represented by B0â€“B14. 1â€“32 767 1 The TSCONST period is a fraction of the BI, i.e., TSCONST period = BI/n where n is the value represented by B0â€“B14. The Interferer MAC Address subfield is set to the value of the TA field within a frame received during the interval of time indicated by this Constraint subfield. If the value is unknown, the Interferer MAC Address subfield is set to the broadcast MAC address. 9.4.2.135 Next DMG ATI element The Next DMG ATI element indicates the earliest start time for the next ATI in a subsequent beacon interval. See Figure 9-525. Element ID Length Start Time ATI Duration Octets: 1 1 4 2 Figure 9-525â€”Next DMG ATI element format The Element ID and Length fields are defined in 9.4.2.1. The Start Time field contains the low-order 4 octets of the TSF for the earliest time at which the next ATI in a subsequent beacon interval starts. The ATI Duration field contains the duration, in microseconds, of the next ATI in a subsequent beacon interval. 1073 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.136 Channel Measurement Feedback element The Channel Measurement Feedback element is used to carry the channel measurement feedback data that the STA has measured on the TRN-T fields of the BRP packet that contained the Channel Measurement request, to provide a list of sectors identified during a sector sweep, or during beam combination (10.38.6.3). The format and size of the Channel Measurement Feedback element are defined by the parameter values specified in the accompanying DMG Beam Refinement element. The Channel Measurement Feedback element, as shown in Table 9-240, is composed of 4 subfields: the SNR subfield, the Channel Measurement subfield, the Tap Delay subfield, and the Sector ID Order subfield. Table 9-240â€”Channel Measurement Feedback element format Field Size Meaning Element ID 8 bits Length 8 bits SNR SNR 1 8 bits SNR as measured in the first TRN-T field or at the first sector from which SSW frame is received. SNR 2 8 bits SNR as measured in the second TRN-T field or at the second sector from which SSW frame is received. SNR N meas 8 bits SNR as measured in the Nmeas TRN-T field or at sector Nmeas from which SSW frame is received. Channel Channel Measurement 1 NtapsÃ—16 bits Channel measurement for the first TRN-T field Measurement Channel Measurement 2 NtapsÃ—16 bits Channel measurement for the second TRN-T field Channel Measurement NtapsÃ—16 bits Channel measurement for the Nmeas TRN-T field Nmeas Tap Delay Relative Delay Tap #1 8 bits The delay of Tap #1 in units of Tc relative to the path with the shortest delay detected. Relative Delay Tap #2 8 bits The delay of Tap #2 in units of Tc relative to the path with the shortest delay detected. Relative Delay Tap 8 bits The delay of Tap #Ntaps in units of Tc relative to #Ntaps the path with the shortest delay detected. 1074 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-240â€”Channel Measurement Feedback element format (continued) Field Size Meaning Sector ID Order Sector ID1 6 bits Sector ID for SNR1 being obtained, or sector ID of the first detected beam. Antenna ID1 2 bits Antenna ID corresponding to sector ID1. Sector ID2 6 bits Sector ID for SNR2 being obtained, or sector ID of the second detected beam. Antenna ID2 2 bits Antenna ID corresponding to sector ID2. Sector IDNmeas 6 bits Sector ID for SNRNmeas being obtained, or sector or sector IDNbeam ID of the detected beam Nbeam. Antenna IDNmeas 2 bits Antenna ID corresponding to sector IDNmeas or or Antenna IDNbeam sector IDNbeam The Element ID and Length fields are defined in 9.4.2.1. The number of channel/SNR measurements reported, Nmeas, is equal to the number of TRN-T subfields that were appended to the packet on which the measurements were performed. If the measurement reports the result of an SLS or of an MID, it is equal to the number of frames received during the sector sweep, or the number of packets used during the MID subphase. The SNR subfield levels are unsigned integers referenced to a level of â€“8 dB. Each step is 0.25 dB. SNR values less than or equal to â€“8 dB are represented as 0. SNR values greater than or equal to 55.75 dB are represented as 0xFF. The format of each channel measurement is specified in Table 9-241. Table 9-241â€”Channel measurement Field Size Meaning Relative I Component Tap #1 8 bits The in-phase component of impulse response for Tap #1, relative to the amplitude of the strongest tap measured. Relative Q Component Tap #1 8 bits The quadrature component of impulse response for Tap #1, relative to the amplitude of the strongest tap measured. Relative I Component Tap #2 8 bits The in-phase component of impulse response for Tap #2, relative to the amplitude of the strongest tap measured. Relative Q Component Tap #2 8 bits The quadrature component of impulse response for Tap #2, relative to the amplitude of the strongest tap measured. Relative I Component Tap #Ntaps 8 bits The in-phase component of impulse response for Tap #Ntaps, relative to the amplitude of the strongest tap measured. Relative Q Component Tap #Ntaps 8 bits The quadrature component of impulse response for Tap #Ntaps, relative to the amplitude of the strongest tap measured. 1075 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Each channel measurement contains Ntaps channel impulse taps. The channel impulse response reported for all Nmeas measurements correspond to a common set of relative tap delays. If the Tap Delay subfield is not present, then the Ntaps channel taps is interpreted as consecutive time samples, separated by Tc. The delay values in the Tap Delay subfield, when present, correspond to the strongest taps and are unsigned integers, in increments of Tc, starting from 0. Each channel tap is reported as an in-phase and quadrature component pair, with each component value represented as a 2s complement number between â€“128 and 127. Unless all in-phase and quadrature component values are reported as zero, they are scaled such that the two most significant bits for at least one of the component values equal 01 or 10 (binary). The Sector ID Order subfield indicates the TX sector IDs corresponding to the SNRs in the SNR subfield when the SNR Present subfield is set to 1 and Sector ID Order Present subfield is set to 1, in response to a BRP packet with the SNR Requested subfield set to 1. The Sector ID Order subfield indicates the TX sector IDs ranked in the decreasing order of link quality, determined in an implementation dependent manner, when the SNR Present subfield is set to 0 and the Sector ID Order Present subfield is set to 1 in response to setting the SNR Requested subfield to 0 and the Sector ID Order Requested subfield to 1. The FBCK-REQ field and the FBCK TYPE field in the DMG Beam Refinement element are used by the transmitter and receiver to, respectively, request for and indicate the sector IDs and their order. 9.4.2.137 Awake Window element The Awake Window element is defined as shown in Figure 9-526. Awake Window Element ID Length Duration Octets: 1 1 2 Figure 9-526â€”Awake Window element format The Element ID and Length fields are defined in 9.4.2.1. The Awake Window Duration field is 2 octets in length and contains the duration of the Awake Window in microseconds. 9.4.2.138 Multi-band element The Multi-band element indicates that the STA transmitting this element (the transmitting STA) is within a multi-band device capable of operating in a frequency band or operating class or channel other than the one in which this element is transmitted and that the transmitting STA is able to accomplish a session transfer from the current channel to a channel using another STA in the same device, in the other or same band. The format of the Multi-band element is shown in Figure 9-527. Element Multi-band Operating Channel Beacon ID Length Control Band ID Class Number BSSID Interval Octets: 1 1 1 1 1 1 6 2 Multi-band STA MAC Pairwise Cipher Pairwise Cipher TSF Offset Connection FSTSessionTimeout Address Suite Count Suite List Capability (optional) (optional) (optional) Octets: 8 1 1 0 or 6 0 or 2 4Ã—m Figure 9-527â€”Multi-band element format 1076 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Element ID and Length fields are defined in 9.4.2.1. The format of the Multi-band Control field is shown in Figure 9-528. B0 B2 B3 B4 B5 B7 STA Role STA MAC Address Pairwise Cipher Suite Present Reserved Present Bits: 3 1 1 3 Figure 9-528â€”Multi-band Control field format The STA Role subfield specifies the role the transmitting STA plays on the channel of the operating class indicated in this element. The possible values of the STA Role subfield are indicated in Table 9-242. If the STA Role subfield is set to IBSS STA, the BSSID subfield contains the BSSID of the IBSS. Table 9-242â€”STA Role subfield values STA role Value AP 0 TDLS STA 1 IBSS STA 2 PCP 3 Non-PCP and Non-AP STA 4 Reserved 5â€“7 NOTEâ€”A STA can perform in more than one role in a channel, and the STA Role subfield identifies the role that is most relevant for the STA for that channel. The STA MAC Address Present subfield indicates whether the STA MAC Address subfield is present in the Multi-band element. If the present subfield is set to 1, the STA MAC Address subfield is present. If the STA MAC Address Present subfield is set to 0, the STA MAC Address subfield is not present. The Pairwise Cipher Suite Present subfield indicates whether the Pairwise Cipher Suite Count field and the Pairwise Cipher Suite List field are present in the Multi-band element. If the Pairwise Cipher Suite Present subfield is set to 1, the Pairwise Cipher Suite Count field and the Pairwise Cipher Suite List field are present. If the Pairwise Cipher Suite Present subfield is set to 0, the Pairwise Cipher Suite Count field and the Pairwise Cipher Suite List field are not present. The Band ID field provides the identification of the frequency band related to the Operating Class and Channel Number fields. The Band ID field is defined in 9.4.1.46. Operating Class indicates the channel set for which the Multi-band element applies. Operating Class and Channel Number together specify the channel frequency and spacing for which the Multi-band element applies. Valid values of Operating Class are shown in Annex E. This field is set to 0 to indicate all operating classes within the frequency band specified by the value of the Band ID field. 1077 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Channel Number field is set to the number of the channel the transmitting STA is operating on or intends to operate on. This field is set to 0 to indicate all channels within the frequency band specified by the value of the Band ID field. The BSSID field specifies the BSSID of the BSS operating on the channel and frequency band indicated by the Channel Number and Band ID fields. The Beacon Interval field specifies the size of the beacon interval for the BSS operating on the channel and frequency band indicated by the Channel Number and Band ID fields. This field is set to 0 if no BSS is in operation in the indicated channel and frequency band. If the transmitting STA is a member of a PBSS or infrastructure BSS on both the channel indicated in this element and the channel on which the element is transmitted, then the TSF Offset field contains the time offset of the TSF of the PBSS or infrastructure BSS of which the transmitting STA is member on the channel indicated in this element relative to the TSF of the PBSS or infrastructure BSS corresponding to the BSSID indicated in the Address 3 field of the MPDU in which this element is transmitted. The value of the TSF Offset field is specified as a 2s complement integer in microsecond units. If the transmitting STA is not a member of an infrastructure BSS or PBSS on both the channel indicated in this element and the channel on which the element is transmitted, then the TSF Offset field contains the value 0. The Multi-band Connection Capability field is defined in Figure 9-529. The Multi-band Connection Capability field indicates the connection capabilities supported by the STA on the channel and band indicated in this element. B0 B1 B2 B3 B4 B5 B7 AP PCP DLS TDLS IBSS Reserved Bits: 1 1 1 1 1 3 Figure 9-529â€”Multi-band Connection Capability field format The AP subfield specifies whether the STA can function as an AP on the channel and band indicated in the element. It is set to 1 when the STA is capable to function as an AP, and it is set to 0 otherwise. The PCP subfield specifies whether the STA can function as a PCP on the channel and band indicated in the element. It is set to 1 when the STA is capable to function as a PCP, and it is set to 0 otherwise. The DLS subfield is set to 1 to indicate that the STA can perform a DLS on the channel and band indicated in the element. Otherwise, it is set to 0. The TDLS subfield is set to 1 to indicate that the STA can perform a TDLS on the channel and band indicated in the element. Otherwise, it is set to 0. The IBSS subfield is set to 1 to indicate that the STA is able to support IBSS on the channel and band indicated in the element. Otherwise, it is set to 0. The FSTSessionTimeout field is used in the FST Setup Request frame to indicate the timeout value for FST session setup protocol as defined in 11.33.1. The FSTSessionTimeout field contains the duration, in TUs, after which the FST setup is terminated. The STA MAC Address field contains the MAC address that the transmitting STA uses while operating on the channel indicated in this element. The STA MAC Address field is not present in this element if the STA MAC Address Present field is set to 0. 1078 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Pairwise Cipher Suite Count field and the Pairwise Cipher Suite List field are defined in 9.4.2.25. These fields are not present in this element if the Pairwise Cipher Suite Present subfield is set to 0. 9.4.2.139 ADDBA Extension element The ADDBA Extension element is shown in Figure 9-530. Element ID Length ADDBA Capabilities Octets: 1 1 1 Figure 9-530â€”ADDBA Extension element format The Element ID and Length fields are defined in 9.4.2.1. The ADDBA Capabilities field is shown in Figure 9-531. B0 B1 B7 No-Fragmentation Reserved Bits: 1 7 Figure 9-531â€”ADDBA Capabilities field format The ADDBA Extension element can be included in the ADDBA Request and Response frames. The No-Fragmentation subfield determines whether a fragmented MSDU can be carried in the MPDU sent under the block ack agreement. When this subfield set to 1 in the ADDBA Request frame, it indicates that the originator is not fragmenting sent MSDUs. When this subfield set to 1 in the ADDBA Response frame, it indicates that the recipient is not capable of receiving fragmented MSDUs. 9.4.2.140 Next PCP List element The Next PCP List element contains one or more AID of NextPCP i fields as shown in Figure 9-532. Element AID of AID of Length Token â€¦ ID NextPCP 1 NextPCP n Octets: 1 1 1 1 â€¦ 1 Figure 9-532â€”Next PCP List element format The Element ID and Length fields are defined in 9.4.2.1. The Token field is set to 0 when the PBSS is initialized and incremented each time the sequence of AID of NextPCP i fields is updated. Each AID of NextPCP i field contains the AID value of a STA. The AID values are listed in the order described in 11.29.2. 1079 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.141 PCP Handover element The PCP Handover element is used to indicate which STA becomes the new PCP following an explicit or implicit handover procedure. The PCP Handover element is defined in Figure 9-533. Element ID Length Old BSSID New PCP Address Remaining BIs Octets: 1 1 6 6 1 Figure 9-533â€”PCP Handover element format The Element ID and Length fields are defined in 9.4.2.1. The Old BSSID field contains the BSSID of the PBSS from which control is being handed over. The New PCP Address field indicates the MAC address of the new PCP following a handover. The Remaining BIs field indicates the number of beacon intervals, from the beacon interval in which this element is transmitted, remaining until the handover takes effect. 9.4.2.142 DMG Link Margin element 9.4.2.142.1 General The format of the DMG Link Margin element is shown in Figure 9-534. The DMG Link Margin element is included in a Link Measurement Report frame. Element ID Length Activity MCS Link Margin SNR Reference Timestamp Octets: 1 1 1 1 1 1 4 Figure 9-534â€”DMG Link Margin element format The Element ID and Length fields are defined in 9.4.2.1. The Activity field is set to a preferred action that the STA sending this element recommends that the peer STA indicated in the RA field of the Link Measurement Report frame execute. The method by which the sending STA determines a suitable action for the peer STA is implementation specific. The Activity field is defined in 9.4.2.142.2. The MCS field is set to an integer representation of the MCS that the STA sending this element recommends that the peer STA indicated in the RA field of the Link Measurement Report frame use to transmit frames to this STA. The reference PER for selection of the MCS is 10-2 for an MPDU length of 4096 octets. The method by which the sending STA determines a suitable MCS for the peer STA is implementation specific. Values 0â€“31 indicate MCS 0 to MCS 31. Values 133, 134, 135, 136, 137, 138, 140 indicate MCSs 12.1, 9.1, 12.3, 12.4, 12.5, 12.2 and 12.6, respectively. The Link Margin field contains the measured link margin of Data frames received from the peer STA indicated in the RA field of the Link Measurement Report frame and is coded as a 2s complement signed integer in units of decibels. A value of â€“128 indicates that no link margin is provided. The method used to measure the link margin is beyond the scope of this standard. The SNR field indicates the SNR measured during the reception of a PHY packet. Values are from â€“13 dB to 50.75 dB in 0.25 dB steps. 1080 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Reference Timestamp field contains the lower 4 octets of the TSF timer value sampled at the instant that the MAC received the PHY-CCA.indication(IDLE) primitive that corresponds to the end of the reception of the PPDU that was used to generate the feedback information contained in the Link Measurement Report frame. 9.4.2.142.2 Activity field The Activity field values are defined in Table 9-243. Table 9-243â€”Activity field values Preferred Action value Meaning 0 No change preferred 1 Change(d) MCS 2 Decrease(d) transmit power 3 Increase(d) transmit power 4 Fast session transfer (FST) 5 Power conserve mode 6 Perform SLS 7â€“255 Reserved 9.4.2.143 DMG Link Adaptation Acknowledgment element The format of the DMG Link Adaptation Acknowledgment element is shown in Figure 9-535. The DMG Link Adaptation Acknowledgment element is carried in the Optional Subelements field of the Link Measurement Report frame. Element ID Length Activity Reference Timestamp Octets: 1 1 1 4 Figure 9-535â€”DMG Link Adaptation Acknowledgment element format The Element ID and Length fields are defined in 9.4.2.1. The Activity field is set to the action that the STA sending this element has executed following the reception of the recommended activity in a Link Measurement Report frame. The method by which the sending STA determines the action is described in 10.39 and the Activity field is defined in 9.4.2.142.2. The Reference Timestamp field contains the lower 4 octets of the TSF timer value sampled at the instant that the MAC received the PHY-CCA.indication(IDLE) primitive that corresponds to the end of the reception of the PPDU that was used to generate the feedback information contained in the Link Measurement Report frame. 1081 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.144 Switching Stream element The Switching Stream element indicates the streams that the transmitting STA requests to be switched to a new frequency band or operating class or channel. The format of the Stream Switching element is shown in Figure 9-536. Element Length Old New Non-QoS Number of Streams Switching ID Band ID Band ID Data Frames Switching Parameters 2 Ã— Number of Octets: 1 1 1 1 1 1 Streams Switching Figure 9-536â€”Switching Stream element format The Element ID and Length fields are defined in 9.4.2.1. The Old Band ID field specifies the frequency band to which the information carried in this element is related. This field is defined in 9.4.1.46. The New Band ID field specifies the frequency band to which the information contained in the Stream ID In New Band subfield of this element is related. This field is defined in 9.4.1.46. The Non-QoS Data Frames field specifies whether non-QoS Data frames can be transmitted in the frequency band indicated in the New Band ID field. If the Non-QoS Data Frames field is set to 0, non-QoS Data frames cannot be transmitted in the frequency band indicated in the New Band ID field. If the Non-QoS Data Frames field is set to 1, non-QoS Data frames can be transmitted in the frequency band indicated in the New Band ID field. The Number of Streams Switching field specifies the number of streams to be switched. The format of Switching Parameters field is shown in Figure 9-537. B0 B3 B4 B5 B8 B9 B10 B11 B12 B15 Stream ID In Old Band Stream ID In New Band Stream ID In New Band LLT Type Reserved TID Direction TID Direction Valid Bits: 4 1 4 1 1 1 4 Figure 9-537â€”Switching parameters field format The Stream ID In Old Band and Stream ID In New Band subfields are comprised of the TID and Direction subfields. The subfields within the Stream ID In New Band subfield are reserved if the Stream ID In New Band Valid subfield is set to 0. The TID subfield specifies the stream in the corresponding band. The Direction subfield specifies whether the STA transmitting this element is the source or destination of the corresponding TID. It is set to 0 to indicate that the STA transmitting this element is the source of the TID, and it is set to 1 otherwise. The Stream ID In New Band Valid subfield is set to 1 if the information contained in the Stream ID In New Band subfield is valid, that is, the TID specified within the Stream ID In New Band subfield has been established in the band identified in the New Band ID field. The Stream ID In New Band Valid subfield is set to 0 otherwise. 1082 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The LLT Type subfield is set to 1 to indicate that the streambased Link Loss Countdown is used for the stream identified by the Stream ID In Old Band subfield. The LLT Type subfield is set to 0 to indicate that the STA-based Link Loss Countdown is used for the stream identified by the Stream ID In Old Band subfield. This subfield is reserved when the LLT field within the FST Setup Request or FST Setup Response frame containing this element is set to 0. 9.4.2.145 Session Transition element The Session Transition element is defined in Figure 9-538. New Band Old Band Element Length FSTS Session ID ID Control Band Band Setup Operation Setup Operation ID ID Octets: 1 1 4 1 1 1 1 1 1 1 Figure 9-538â€”Session Transition element format The Element ID and Length fields are defined in 9.4.2.1. The FSTS ID (fast session transfer session identifier) field contains the identification of the FST session established between a pair of STAs as allocated by the initiator (10.32). The Session Control field is defined in Figure 9-539. B0 B3 B4 B5 B7 Session Type Switch Intent Reserved Bit: 4 1 3 Figure 9-539â€”Session Control field format The Session Type subfield is defined as shown in Table 9-244 and indicates the type of connection/session that is intended to be set up in the new band for this FST session. Table 9-244â€”Session Type subfield values Value Session type 0 Infrastructure BSS 1 IBSS 2 DLS 3 TDLS 4 PBSS 5â€“255 Reserved When the Session Type subfield is set to IBSS and the STA Role subfield within the Multi-band element is set to IBSS STA, the BSSID field within the Multi-band element contains the MAC address of the BSSID of 1083 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications the IBSS. This indicates that the transmitting STA is not associated with an AP on the band and channel indicated in the Multi-band element. The Switch Intent subfield is set to 1 to indicate that the FST Initiator that transmitted the FST Setup Request frame intends to switch to the band/channel indicated within the Band ID subfield of the FST Setup Request frame and in the Multi-band element, even if the FST transition does not succeed. Otherwise, this subfield is set to 0. This subfield is reserved when transmitted within an FST Setup Response frame. The New Band and Old Band subfields are used for the signaling described in 11.33.1. Both the New Band and Old Band subfields contain a Band ID subfield, a Setup subfield, and an Operation subfield. The Band ID subfield is defined in 9.4.1.46. If a Multi-band element is present in the frame containing this Session Transition element, the Band ID subfield refers to the Operating Class and Channel Number fields within the Multi-band element provided the value of both of these fields are nonzero. The Setup subfield is set to 1 to indicate that the STA transmitting this element has an FST session established with the STA that the frame containing this element is addressed and in the band indicated within the Band ID subfield. Otherwise, it is set to 0. Other values are reserved. The Operation subfield is set to 1 to indicate that the STA is operating in the band indicated within the Band ID subfield. Otherwise, it is set to 0. Other values are reserved. 9.4.2.146 Dynamic Tone Pairing (DTP) Report element The DTP Report element is included in the DTP Response frame. The format of the DTP Report element is shown in Table 9-245. Table 9-245â€”DTP Report element format Field Length Meaning Element ID 8 bits Length 8 bits GroupPairIndex(0) 6 bits Index of DTP group pair n in the range 0 to NGâ€“1, for n = 0,1,2,â€¦,NGâ€“1 where NG=42 GroupPairIndex(1) 6 bits â€¦ â€¦ GroupPairIndex(NG-1) 6 bits Zero pad 4 bits Zero padding to make the DTP Feedback element length a multiple of 8 bits The Element ID and Length fields are defined in 9.4.2.1. GroupPairIndex(n) subfields for n=0,1,..,NGâ€“1(where NG=42) indicate DTP groups, which in turn determines how pairs of SQPSK symbols are mapped to OFDM tones when DTP is enabled, as described in 20.5.3.2.4.6.3. Valid values of GroupPairIndex(n) are in the range 0 to NGâ€“1. Furthermore valid values of GroupPairIndex(0), GroupPairIndex(1),â€¦, GroupPairIndex(NGâ€“1) are distinct and therefore represent a permutation of integers 0 to NGâ€“1. All numeric fields are encoded as unsigned integers. 1084 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.147 Cluster Report element The format of the Cluster Report element is shown in Figure 9-540. The Cluster Report element is included Action frames, such as Announce and Information Response frames, transmitted to the AP or PCP of the BSS. Because the Length field supports only 255 octets of information in an element, the STA can split the content of the Extended Schedule Element field, as described in 9.4.2.132, in different Cluster Report elements. The value of n in Figure 9-540 is given by the following equation: n = 255 â€“ 2 + S RB + S RT + S CC + S EPE + S TSCONST where SRB is the size of the Reported BSSID field in octets SRT is the size of the Reference Timestamp field in octets SCC is the size of the Clustering Control field in octets SEPE is the size of the ECAPC Policy Element field in octets STSCONST is the size of the Traffic Scheduling Constraint Set field in octets Cluster Report Reported Reference Clustering Element ID Length Control BSSID Timestamp Control Octets: 1 1 1 0 or 6 0 or 4 0 or 8 ECAPC Policy Extended Schedule Number of Element Element Constraints Traffic Scheduling Constraint Set Octets: 0, 13 or 17 0 or 17 â€“ n 1 Variable Figure 9-540â€”Cluster Report element format The Element ID and Length fields are defined in 9.4.2.1. The Cluster Report Control field is defined in Figure 9-541. B0 B1 B2 B3 B4 B5 B6 B7 ECAPC ECAPC Cluster Cluster Schedule TSCONST Request Report Present Present Policy Policy Reserved Enforced Present Bits: 1 1 1 1 1 1 2 Figure 9-541â€”Cluster Report Control field format The Cluster Request subfield is set to 1 to indicate that the STA is requesting the AP or PCP to start AP or PCP clustering (10.37). Otherwise, it is set to 0. The Cluster Report subfield is set to 1 to indicate that this element contains a cluster report. If this subfield is set to 1, the Reported BSSID, Reference Timestamp and Clustering Control fields are present in this element. Otherwise, if the Cluster Report subfield is set to 0, none of the Reported BSSID, Reference Timestamp, Clustering Control, Extended Schedule Element, and Traffic Scheduling Constraint Set fields is present in this element. 1085 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Schedule Present subfield is valid only if the Cluster Report subfield is set to 1; otherwise, it is reserved. The Schedule present subfield is set to 1 to indicate that the Extended Schedule Element field is present in this element. Otherwise, the Extended Schedule Element field is not present in this element. The TSCONST Present subfield is valid only if the Cluster Report subfield is set to 1; otherwise, it is reserved. The TSCONST Present subfield is set to 1 to indicate that the Number of Constraints field and the Traffic Scheduling Constraint Set field are present in this element. Otherwise, these fields are not present in this element. The ECAPC Policy Enforced subfield is valid only if the Cluster Report subfield is set to 1; otherwise, it is reserved. The ECAPC Policy Enforced subfield is defined in 9.3.4.2 and contains the ECAPC Policy Enforced subfield received in the DMG Beacon frame that generated this report. The ECAPC Policy Present subfield is valid only if the Cluster Report subfield is set to 1; otherwise, it is reserved. The ECAPC Policy Present subfield is set to 1 to indicate that the ECAPC Policy Present Element field is present in this element. Otherwise, the ECAPC Policy Present Element field is not present in this element. The Reported BSSID field contains the BSSID of the DMG Beacon frame that triggered this report. The Reference Timestamp field contains the lower 4 octets of the TSF timer value sampled at the instant that the STAâ€™s MAC received a DMG Beacon frame that triggered this report. The Clustering Control field is defined in 9.3.4.2 and contains the Clustering Control received in the DMG Beacon frame that triggered this report. The ECAPC Policy Element field is defined in 9.4.2.151 and contains the ECAPC Policy element obtained from the AP or PCP that sent the DMG Beacon frame that generated this report (see 10.37.4). The Extended Schedule Element field is defined in 9.4.2.132 and contains a single Extended Schedule element received in the DMG Beacon frame that generated this report. If an Extended Schedule element is not present in the received DMG Beacon, this field is set to all 0s. The Number of Constraints field indicates the number of Constraint subfields contained in the Traffic Scheduling Constraint Set field. The value of this field ranges from 0 to 15. Other values are reserved. The Traffic Scheduling Constraint Set field contains one or more Constraint subfields as defined in 9.4.2.134 and specifies periods of time with respect to the TBTT of the beacon interval of the BSS the STA participates where the STA experiences poor channel conditions, such as due to interference. 9.4.2.148 Relay Capabilities element A STA that intends to participate in relay operation (11.36) advertises its capabilities through the Relay Capabilities element. The Relay Capabilities element is defined in Figure 9-542. Element ID Length Relay Capabilities Information Octets: 1 1 2 Figure 9-542â€”Relay Capabilities element format The Element ID and Length fields are defined in 9.4.2.1. The Relay Capability Information field is defined in Figure 9-543. 1086 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B0 B1 B2 B3 B4 B5 B6 B7 B8 B15 Relay Relay Relay A/C Relay Supporter Client Permission Power Preference Duplex Cooperation Reserved Bits: 1 1 1 1 1 2 1 8 Figure 9-543â€”Relay Capability Information field format The Relay Supporter subfield indicates whether the STA is capable of relaying by transmitting and receiving frames between a pair of other STAs. A STA capable of relaying is called a relay STA. This subfield is set to 1 if the STA supports relaying; otherwise, it is set to 0. The Relay Client subfield indicates whether the STA is capable of using frame-relaying through a relay STA. It is set to 1 if the STA supports transmission and reception of frames through a relay STA; otherwise, it set to 0. The Relay Permission subfield indicates whether the AP or PCP allows relay operation (11.36) to be used within the APâ€™s or PCPâ€™s BSS. It is set to 0 if relay operation is not allowed in the BSS; otherwise, it is set to 1. This subfield is reserved when transmitted by a non-AP and non-PCP STA. The A/C Power subfield indicates whether the STA is capable of obtaining A/C power. It is set to 1 if the STA is capable of being supplied by A/C power; otherwise, it is set to 0. The Relay Preference subfield indicates whether the STA prefers to become RDS rather than REDS. It is set to 1 if a STA prefers to be RDS; otherwise, it is set to 0. The Duplex subfield indicates whether the STA is capable of full-duplex/amplify-and-forward (FD-AF) or half-duplex/decode-and-forward (HD-DF). It is set to 1 if the STA is not capable of HD-DF but is capable of only FD-AF. It is set to 2 if the STA is capable of HD-DF but is not capable of FD-AF. It is set to 3 if the STA is capable of both HD-DF and FD-AF. The value 0 is reserved. The Cooperation subfield indicates whether a STA is capable of supporting link cooperation. It is set to 1 if the STA supports both link cooperation and link switching. It is set to 0 otherwise. 9.4.2.149 Relay Transfer Parameter Set element A source REDS that intends to transfer frames via an RDS advertises the parameters for the relay operation with the transmission of a Relay Transfer Parameter Set element (11.36). The Relay Transfer Parameter Set element is defined in Figure 9-544. Element ID Length Relay Transfer Parameter Octets: 1 1 8 Figure 9-544â€”Relay Transfer Parameter Set element format The Element ID and Length fields are defined in 9.4.2.1. The Relay Transfer Parameter field is defined in Figure 9-545. 1087 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B0 B1 B2 B3 B7 B8 B15 B16 B23 B24 B39 B40 B55 B56 B63 Link Data Duplex- Cooperation- Tx-Mode Reserved Change Sensing First Second Reserved Mode Mode Period Period Interval Time Bits: 1 1 1 5 8 8 16 16 8 Figure 9-545â€”Relay Transfer Parameter field format The Duplex-Mode subfield indicates that the source REDS set the duplex mode of the RDS involved in RLS. The Duplex-Mode subfield value is set to 0 if the RDS operates in HD-DF mode. It is set to 1 if the RDS operates in FD-AF mode. The Cooperation-Mode subfield indicates whether the source REDS sets the link cooperation of the RDS involved in RLS. This subfield is valid only when the RDS is capable of link cooperation and Duplex-Mode subfield is set to 0. Otherwise, this subfield is reserved. The Cooperation-Mode subfield value is set to 0 if the RDS operates in link switching. It is set to 1 if the RDS operates in link cooperation. The Tx-Mode subfield indicates that the source REDS sets the transmission mode of the RDS involved in RLS. This subfield is valid only when the RDS is capable of link switching and the Duplex-Mode subfield is set to 1. Otherwise, this subfield is reserved. The Tx-Mode subfield value is set to 0 if a group of three STAs involved in the RLS operates in Normal mode and is set to 1 if the group operates in Alternation mode. The Link Change Interval subfield indicates when the link of frame transmission between source REDS and destination REDS is changed. From the start position of one reserved continuous SP, every time instant of link change interval can have an opportunity to change the link. Within one link change interval, only one link is used for frame transfer. The unit of this subfield is microseconds. This subfield is used only when the group involved in the RLS operates in link switching. The Data Sensing Time subfield indicates the defer time offset from the time instant of the next link change interval when the link switching occurs. By default, it is set to SIFS plus SBIFS. This subfield is used only when the STAs involved in the RLS operate in link switching with Tx-Mode that is 0. The First Period subfield indicates the period of the source REDS-RDS link in which the source REDS and RDS exchange frames. This subfield is used only when HD-DF RDS operates in link switching. The Second Period subfield indicates the period of the RDS-destination REDS link in which the RDS and destination REDS exchange frames and the following period of the RDS-source REDS link in which the RDS informs the source REDS of finishing one frame transfer. This subfield is used only when HD-DF RDS operates in link switching. 9.4.2.150 Quiet Period Request element The Quiet Period Request element defines a periodic sequence of quiet intervals that the requester AP requests the responder AP to schedule. The format of the Quiet Period Request element is shown in Figure 9-546. Quiet Element Request Quiet Quiet Repetition Target ID Length Token Period Period Duration Count BSSID Offset Octets: 1 1 2 2 4 2 1 6 Figure 9-546â€”Quiet Period Request element format 1088 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Element ID and Length fields are defined in 9.4.2.1. The Request Token field is set to a nonzero value chosen by the requester AP. The Quiet Period Offset field is set to the offset of the start of the first quiet interval from the QAB Request frame that contains this element, expressed in TUs. The reference time is the start of the preamble of the PPDU that contains this element. The Quiet Period field is set to the spacing between the start of two consecutive quiet intervals, expressed in TUs. The Quiet Duration field is set to duration of the quiet time, expressed in TUs. The Repetition Count field is set to the number of requested quiet intervals. NOTEâ€”The periodic sequence of quiet intervals ends after the start of preamble of the PPDU containing the QAB IE + Quiet Period Offset + (Repetition Count-1)Ã—Quiet Period + Quiet Duration (in TUs). The Target BSSID field is set to the responder APâ€™s MAC address. 9.4.2.151 Quiet Period Response element The Quiet Period Response element defines the feedback information from the AP that received the Quiet Period Request element. The format of the Quiet Period Response element is shown in Figure 9-547. Element ID Length Request Token BSSID Status Code Octets: 1 1 2 6 2 Figure 9-547â€”Quiet Period Response element format The Element ID and Length fields are defined in 9.4.2.1. The Request Token field is set to the value of the Request Token field of the corresponding received Quiet Period Request element. The BSSID field is set to the value of the Target BSSID field of the corresponding received Quiet Period Request element. The Status Code field is defined in 9.4.1.9. 9.4.2.152 BeamLink Maintenance element The format of the BeamLink Maintenance element is shown in Figure 9-548. The BeamLink Maintenance element is included in Action frames, such as Probe, Announce and the Information Request and Response frames, transmitted between a non-AP and non-PCP DMG STA and a DMG AP or PCP. The element is included in the Probe and Information Request and Response frames transmitted between non-AP and non- PCP DMG STAs. Element ID Length Beamformed Link Maintenance Octets: 1 1 1 Figure 9-548â€”BeamLink Maintenance element format 1089 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Element ID and Length fields are defined in 9.4.2.1. The Beamformed Link Maintenance field is defined in 9.5.6. 9.4.2.153 Multiple MAC Sublayers (MMS) element The format of Multiple MAC Sublayers (MMS) element is shown in Figure 9-549. The MMS element is included in Action frames, such as Probe Request, Association Request, Information Request, Announce, and Information Response frames, transmitted to the peer STA and the AP or PCP of the BSS. Element ID Length MMS Control STA MAC Address Interface Address(es) Octets: 1 1 1 6 6 Ã— n (variable) Figure 9-549â€”MMS element format The Element ID and Length fields are defined in 9.4.2.1. The MMS Control field is defined in Figure 9-550. B0 B1 B2 B3 B4 B5 B7 MMS Element Single MM-SME BeamLink Reserved Owner AID Power Mode Cluster Bit: 2 1 1 1 3 Figure 9-550â€”MMS Control field format The MMS Element Owner subfield is encoded as shown in Table 9-246. If the MMS Element Owner field is set to No Owner, then the Interface address(es) field in the MMS element is reserved. Table 9-246â€”MMS Element Owner subfield definition MMS Element Owner subfield value Meaning B0 B1 0 0 No Owner 1 0 Non-AP and Non-PCP MMS element 0 1 PCP MMS element 1 1 AP MMS element The Single AID subfield is one bit in length and is encoded as defined in Table 9-247. 1090 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-247â€”Single AID subfield definition MMS Element Single MMS MMS Owner AID element sent element sent Meaning from to B0 B1 B3 Non-AP and AP or PCP 1 0 1 Request to allocate single AID for MAC addresses non-PCP included in the MMS element STA Non-AP and AP or PCP 1 0 0 Do not allocate single AID for MAC addresses non-PCP included in the MMS element STA AP or PCP Non-PCP, 1 0 1 Single AID is allocated for all MAC addresses in the non-AP STA MMS element AP or PCP Non-PCP, 1 0 0 Single AID is not allocated for all MAC addresses non-AP STA in the MMS element Non-AP and Non-PCP, 1 0 1 Single AID is allocated for all MAC addresses in the non-PCP non-AP STA MMS element STA Non-AP and Non-PCP, 1 0 0 Single AID is not allocated for all MAC addresses non-PCP non-AP STA in the MMS element STA AP or PCP Non-PCP, 0 1 1 Single AID is allocated for all MAC addresses in the non-AP STA non-AP and non-PCP STA MMS element AP or PCP Non-PCP, 0 1 0 Single AID is not allocated for all MAC addresses non-AP STA in the non-AP and non-PCP STA MMS element The MM-SME Power Mode subfield is one bit in length and is set to 1 to indicate that when a STA advertised in the MMS element sent by the STA coordinated by an MM-SME moves from the awake to the doze state, then all other STAs advertised in the MMS element sent by the STA move to the doze state. The STA coordinated by the MM-SME moves to the awake state only when all STAs advertised in the MMS element move to the awake state. The MM-SME Power Mode subfield is set to 0 to indicate that when a STA advertised in the MMS element sent by the STA moves from the doze to the awake state, then all other STAs advertised in the MMS element sent by the STA coordinated by the MM-SME move to the awake state. The STA coordinated by the MM-SME moves to the doze state only when all STAs advertised in the MMS element move to the doze state. The BeamLink Cluster subfield is one bit in length and is set to 1 if the DMG STA intends to maintain the same beamformed link for all of the links within the MMSL cluster. Otherwise, this subfield is set to 0. The STA MAC Address field contains the MAC address of the STA. When present in the element, the Interface Address(es) field contains one or more MAC addresses that can be used to identify the STAs in addition to the STA MAC address, coordinated by the same MM-SME (see 11.34). 9.4.2.154 U-PID element The format of the Upper Layer Protocol Identification (U-PID) element is described in Figure 9-551. 1091 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications LLC Element ID Length Header LLC Header Copy Removed Octets: 1 1 1 Variable Figure 9-551â€”U-PID element format The Element ID and Length fields are defined in 9.4.2.1. The LLC Header Removed field is set to 1 to indicate that MSDUs do not contain the LLC (Logical Link Control) header over the WM. It is set to 0 otherwise. The content and corresponding size of the LLC Header Copy field are specified in Table 9-248. Table 9-248â€”LLC Header Copy field size LLC Header Copy field contents LLC Header Copy field size (octets) LLC header with 8-bit control field without SNAP 3 LLC header with 8-bit control field with SNAP 8 LLC header with 16-bit control field without SNAP 4 LLC header with 16-bit content field with SNAP 9 NOTEâ€”The structure of the LLC header is defined in IEEE Std 802.2-1998. The structure of the LLC with SNAP extension is defined in IEEE Std 802.2-1998. 9.4.2.155 ECAPC Policy element The format of the ECAPC Policy element is shown in Figure 9-552. Available TXSS TXSS TXSS Element ECAPC CCSR Cluster CBAP CBAP CBAP Length Policy ID Detail ID Time Offset Offset Duration MaxMem Bitmap (optional) (optional) (optional) Octets: 1 1 1 6 4 0 or 2 0 or 1 0 or 1 Figure 9-552â€”ECAPC Policy element format The Element ID and Length fields are defined in 9.4.2.1. The ECAPC Policy Detail field is defined in Figure 9-553. B0 B1 B2 B3 B7 BHI Enforced TXSS CBAP Enforced Protected Period Enforced Reserved Bits: 1 1 1 5 Figure 9-553â€”ECAPC Policy Detail field format 1092 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The BHI Enforced subfield set to 1 indicates that an AP or PCP in a centralized AP or PCP cluster completes the BHI for the current beacon interval before TBTT + (8Ã—Beacon SP duration), as described in 10.37.3.4. The BHI Enforced subfield set to 0 indicates that an AP or PCP within a cluster does not have to complete the BHI for the current beacon interval before TBTT + (8Ã—Beacon SP duration). The TXSS CBAP Enforced subfield set to 1 indicates that a STA in a centralized AP or PCP cluster performs each of its TXSSs in the DTI within one or more TXSS CBAPs, as described in 10.37.3.4. The TXSS CBAP Enforced subfield set to 0 indicates that a STA within a centralized AP or PCP cluster does not have to perform each of its TXSSs in the DTI within one or more TXSS CBAPs. The Protected Period Enforced subfield indicates that every scheduled SP in the BSS is a DMG protected period as specified in 10.36.6.6. The Protected Period Enforced subfield set to 0 indicates that a scheduled SP in the BSS does not have to be a DMG protected period. The CCSR ID field is set to the MAC address of the CCSR within the ECAPC that the AP or PCP belongs to. The AP or PCP is the transmitter of the frame containing the ECAPC Policy element except when the ECAPC Policy element is transmitted in a Cluster Report element, where the AP or PCP is the transmitter that triggered the Cluster report. The Available Time Cluster Offset Bitmap field is a bitmap where the bit nâ€“1, n = 1 to 32, indicates the availability of the nth Beacon SP. Values of n = 1 and greater than ClusterMaxMem are reserved (i.e., bit 0 and bits ClusterMaxMem+1 to 31 inclusive). Bit nâ€“1 set to 0 indicates that ClusterTimeOffsetn-1 is determined to be already in use by a neighboring AP or PCP, excluding the recipient if sent within an individually addressed frame, in the ECAPC. Bit nâ€“1 set to 1 indicates that ClusterTimeOffsetn-1 is not determined to be already in use by a neighboring AP or PCP, excluding the recipient if sent within an individually addressed frame, in the ECAPC. If TXSS CBAP Enforced field is set to 0, then the TXSS CBAP Offset field, the TXSS CBAP Duration field, and the TXSS CBAP MaxMem field are not present in the element; otherwise, they are present in the element. The TXSS CBAP Offset field is the delay of the first TXSS CBAP in a beacon interval from the TBTT, in units of 8 Âµs. The TXSS CBAP Duration field indicates the duration of each TXSS CBAP, in units of 8 Âµs. The TXSS CBAP MaxMem field is the number of TXSS CBAPs per beacon interval. 9.4.2.156 Cluster Time Offset element The format of the Cluster Time Offset element is shown in Figure 9-554. Element ID Length Cluster Time Offset Index Octets: 1 1 1 Figure 9-554â€”Cluster Time Offset element format The Element ID and Length fields are defined in 9.4.2.1. The Cluster Time Offset Index field is set to nâ€“1 for a member AP or member PCP of a centralized AP or PCP cluster that adopted the nth Beacon SP (see 10.37). Values equal to 0 and greater than ClusterMaxMem are reserved. 1093 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.157 Antenna Sector ID Pattern element The format of the Antenna Sector ID Pattern element is shown in Figure 9-555. B0 B7 B8 B15 B16 B19 B20 B25 B26 B31 B32 B39 B40 B47 Element ID Length Type Tap 1 State 1 Tap 2 State 2 Bits: 8 8 4 6 6 8 8 Figure 9-555â€”Antenna Sector ID Pattern element format The Element ID and Length fields are defined in 9.4.2.1. The Type field is set to 0 for Random Sequence Generator. Values 1 to 3 are reserved. The Tap 1 field indicates the taps for Sequence Generator 1. The State 1 field indicates the state for Sequence Generator 1. The Tap 2 field indicates the taps for Sequence Generator 2. The State 2 field indicates the state for Sequence Generator 2. Sequence Generator 1 is shown in Figure 9-556 and is defined as follows: â€” Generate the sector IDs for subsequent DMG Beacons by advancing the Sequence Generator 1, which is initialized using the values of the Tap 1 and State 1 fields contained in the Antenna Sector ID Pattern element received from the AP or PCP. â€” Advance the Sequence Generator 1 by one shift for each anticipated DMG Beacon frame transmission thereafter. â€” After advancing the Sequence Generator 1, if the next state equals the initial state for the second time, overwrite the state with an all-zero state. The next state following the state following all zero- state uses the first 6 bits of the state of Sequence Generator 2 as the initial state. â€” If the STAâ€™s total number of transmit sectors is not equal to the period of the Sequence Generator 1, ignore state(s) greater than or equal total number of transmit sectors and continue advancing Sequence Generator 1 until the state is less than the total number of transmit sectors. NOTEâ€”The taps are selected from the set of sequences with maximal length property. Tap 1 0 1 2 3 4 5 0 1 2 3 4 5 State 1 (= Sector ID) Figure 9-556â€”Sequence Generator 1 1094 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Sequence Generator 2 is shown in Figure 9-557 and is defined as follows: â€” Sequence Generator 2 is initiated with the value of the Tap 2 and State 2 fields contained in the Antenna Sector ID Pattern element received from the AP or PCP. â€” Sequence Generator 2 is advanced by one shift when a new initial state is needed from Sequence Generator 1. NOTEâ€”The taps are selected from the set of the sequences with maximal length property. Tap 2 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 State 2 Figure 9-557â€”Sequence Generator 2 9.4.2.158 VHT Capabilities element 9.4.2.158.1 VHT Capabilities element structure A VHT STA declares that it is a VHT STA by transmitting the VHT Capabilities element. The VHT Capabilities element contains a number of fields that are used to advertise the VHT capabilities of a VHT STA. The VHT Capabilities element is defined in Figure 9-558. Element VHT Capabilities Supported VHT-MCS ID Length Info and NSS Set Octets: 1 1 4 8 Figure 9-558â€”VHT Capabilities element format The Element ID and Length fields are defined in 9.4.2.1. 9.4.2.158.2 VHT Capabilities Information field The structure of the VHT Capabilities Information field is defined in Figure 9-559. 1095 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B0 B1 B2 B3 B4 B5 B6 B7 B8 B10 B11 B12 B13 B15 Short GI for 80 Short GI Maximum Supported for 160 SU SU Beamformee MPDU Channel Rx MHz/ and Tx Rx Beamformer Beamformee STS LDPC TVHT_ STBC STBC Length Width Set MODE_ 80+80 Capable Capable Capability MHz 4C Bits: 2 2 1 1 1 1 3 1 1 3 B16 B18 B19 B20 B21 B22 B23 B25 B26 B27 B28 B29 B30 B31 Number Of MU MU +HTC- Maximum VHT Link Rx Antenna Tx Antenna Extended TXOP A-MPDU Pattern Sounding Beamformer Beamformee PS VHT Length Adaptation Pattern Consistency NSS BW Dimensions Capable Capable Capable Capable Consistency Support Exponent 3 1 1 1 1 3 2 1 1 2 Figure 9-559â€”VHT Capabilities Information field The subfields of the VHT Capabilities Information field are defined in Table 9-249. Table 9-249â€”Subfields of the VHT Capabilities Information field Subfield Definition Encoding Maximum MPDU Indicates the maximum MPDU Set to 0 for 3895 octets. Length length that the STA is capable Set to 1 for 7991 octets. of receiving (see 10.12). Set to 2 for 11 454 octets. The value 3 is reserved. Supported Channel Together with the Extended In a non-TVHT STA, see Table 9-250. Width Set NSS BW Support subfield and Supported VHT-MCS and NSS In a TVHT STA, the field is structured into subfields as Set field, indicates the channel defined in Figure 9-560. widths and maximum NSS In a TVHT STA, set the TVHT_MODE_2C Support values per width supported by subfield to 1 if it supports TVHT_MODE_2C; otherwise the STA. See 11.40. set the subfield to 0. In a TVHT STA, set the TVHT_MODE_2N Support subfield to 1 if it supports TVHT_MODE_2N; otherwise set the subfield to 0. Rx LDPC Indicates support for receiving Set to 0 if not supported. LDPC encoded packets. Set to 1 if supported. Short GI for 80 In a non-TVHT STA, indicates In a non-TVHT STA, set to 1 if Short GI for 80 MHz is MHz/ short GI support for the supported. TVHT_MODE_4C reception of packets transmitted with TXVECTOR parameters In a TVHT STA, set to 1 if TVHT_MODE_4C is FORMAT equal to VHT and supported. CH_BANDWIDTH equal to CBW80. Otherwise set to 0. In a TVHT STA, indicates support for TVHT_MODE_4C. 1096 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-249â€”Subfields of the VHT Capabilities Information field (continued) Subfield Definition Encoding Short GI for 160 Indicates short GI support for Set to 0 if not supported. and 80+80 MHz the reception of packets Set to 1 if supported. transmitted with TXVECTOR parameters FORMAT equal to In a TVHT STA, set to 1 if it supports VHT and CH_BANDWIDTH TVHT_MODE_4N. equal to CBW160 or CBW80+80. Tx STBC Indicates support for the Set to 0 if not supported. transmission of at least 2x1 Set to 1 if supported. STBC. Rx STBC Indicates support for the Set to 0 for no support. reception of PPDUs using Set to 1 for support of one spatial stream. STBC. Set to 2 for support of one and two spatial streams. Set to 3 for support of one, two, and three spatial streams. Set to 4 for support of one, two, three, and four spatial streams. The values 5, 6, 7 are reserved. See NOTE 3. SU Beamformer Indicates support for operation Set to 0 if not supported. Capable as an SU beamformer (see Set to 1 if supported. 10.34.5). SU Beamformee Indicates support for operation Set to 0 if not supported. Capable as an SU beamformee (see Set to 1 if supported. 10.34.5). Beamformee STS Indicates the maximum number If the SU Beamformee Capable field is set to 1, set to Capability of space-time streams that the maximum number of space-time streams that the STA can STA can receive in a VHT NDP receive in a VHT NDP minus 1. and the maximum value of Nr Otherwise, reserved. that the STA transmits in a VHT Compressed Beamforming frame. Number of Beamformerâ€™s capability If the SU Beamformer Capable field is set to 1, set to the Sounding indicating the maximum value maximum supported value of the TXVECTOR parameter Dimensions of the TXVECTOR parameter NUM_STS minus 1. NUM_STS for a VHT NDP. Otherwise, reserved. MU Beamformer Indicates support for operation Set to 0 if not supported or if SU Beamformer Capable is Capable as an MU beamformer (see set to 0 or if sent by a non-AP STA. 10.34.5). Set to 1 if supported and SU Beamformer Capable is set to 1. MU Beamformee Indicates support for operation Set to 0 if not supported or if SU Beamformee Capable is Capable as an MU beamformee (see set to 0 or if sent by an AP. 10.34.5). Set to 1 if supported, SU Beamformee Capable is set to 1 and not sent by an AP. TXOP PS Indicates whether the AP Set to 0 if the AP does not support TXOP power save supports TXOP power save mode. mode or whether the non-AP Set to 1 if the AP supports TXOP power save mode. STA has enabled TXOP power Set to 0 if the non-AP STA does not enable TXOP power save mode. save mode. Set to 1 if the non-AP STA enables TXOP power save mode. 1097 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-249â€”Subfields of the VHT Capabilities Information field (continued) Subfield Definition Encoding +HTC-VHT Indicates whether the STA Set to 0 if not supported. Capable supports receiving a VHT Set to 1 if supported. variant HT Control field. Maximum A- Indicates the maximum length This field is an integer in the range 0 to 7. MPDU Length of an A-MPDU pre-EOF The length defined by this field is equal to Exponent padding that the STA can 2 13 + Maximum A-MPDU Length Exponent â€“ 1 octets. receive. VHT Link Indicates whether the STA If +HTC-VHT Capable is 1: Adaptation supports link adaptation using Set to 0 (No Feedback) if the STA does not provide Capable VHT variant HT Control field. VHT MFB. Set to 2 (Unsolicited) if the STA provides only unsolicited VHT MFB. Set to 3 (Both) if the STA can provide VHT MFB in response to VHT MRQ and if the STA provides unsolicited VHT MFB. The value 1 is reserved. Reserved if +HTC-VHT Capable is 0. Rx Antenna Indicates the possibility of a Set to 0 if the receive antenna pattern might change Pattern receive antenna pattern change. during the lifetime of the current association. Consistency Set to 1 if the receive antenna pattern does not change during the lifetime of the current association. See 11.40.6. Tx Antenna Indicates the possibility of a Set to 0 if the transmit antenna pattern might change Pattern transmit antenna pattern during the lifetime of the current association. Consistency change. Set to 1 if the transmit antenna pattern does not change during the lifetime of the current association. See 11.40.6. Extended NSS BW Together with the Supported In a non-TVHT STA, see Table 9-250. Support Channel Width Set subfield and Supported VHT-MCS and NSS In a TVHT STA, the field is reserved. Set field, indicates the channel widths and maximum NSS In a STA with dot11VHTExtendedNSSBWCapable equal values per width supported by to false or not present, this field is set to 0. the STA (for non-TVHT VHT STAs). See 11.40. NOTE 1â€”An AP that sets MU Beamformer Capable to 1 can transmit a VHT MU PPDU with only one nonzero TXVECTOR parameter NUM_STS[p], for 0 p 3. However, a STA that sets MU Beamformee Capable to 0 is not required to be able to demodulate a VHT MU PPDU with only one nonzero RXVECTOR parameter NUM_STS[p], for 0 p 3. NOTE 2â€”The value of the Maximum MPDU Length subfield of the VHT Capabilities Information field imposes a constraint on the allowed value in the Maximum MPDU Length subfield of the HT Capabilities element carried in the same frame (see 10.12). NOTE 3â€”Subject to any extended NSS BW support constraint. 1098 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-250â€”Setting of the Supported Channel Width Set subfield and Extended NSS BW Support subfield at a STA transmitting the VHT Capabilities Information field NSS Support of STA transmitting the VHT Location of Location of Transmitted VHT Capabilities Information field as a function of the 160 MHz 80+80 MHz Capabilities PPDU bandwidth (Ã—Max VHT NSS) (see channel center center Information field requirements R1 and R2) frequency if frequency if BSS BSS Supported Extended 20 MHz 40 MHz 80 MHz 160 80+80 bandwidth is bandwidth is Channel NSS BW MHz MHz 160 MHz 80+80 MHz Width Set Support 0 0 1 1 1 0 1 1 1 1 1/2 CCFS2 0 2 1 1 1 1/2 1/2 CCFS2 CCFS2 0 3 1 1 1 3/4 3/4 CCFS2 CCFS2 1 0 1 1 1 1 CCFS1 1 1 1 1 1 1 1/2 CCFS1 CCFS2 1 2 1 1 1 1 3/4 CCFS1 CCFS2 1 3 2 2 2 2 1 CCFS1 CCFS1 2 0 1 1 1 1 1 CCFS1 CCFS1 2 3 2 2 2 1 1 CCFS1 CCFS1 R1: NSS support shall be rounded down to the nearest integer. R2: The maximum NSS support shall be 8. NOTE 1â€”Max VHT NSS is defined per MCS in 9.4.2.158.3. NOTE 2â€”1/2Ã— or 3/4Ã— Max VHT NSS support might end up being 0, indicating no support. NOTE 3â€”Any other combination than the ones listed in this table is reserved. NOTE 4â€”CCFS1 refers to the value of the Channel Center Frequency Segment 1 field of the most recently transmitted VHT Operation element. NOTE 5â€”CCFS2 refers to the value of the Channel Center Frequency Segment 2 field of the most recently transmitted HT Operation element. NOTE 6â€”CCFS1 is nonzero when the current BSS bandwidth is 160 MHz or 80+80 MHz and the NSS support is at least Max VHT NSS. CCFS2 is zero in this case. NOTE 7â€”CCFS2 is nonzero when the current BSS bandwidth is 160 MHz or 80+80 MHz and the NSS support is less than Max VHT NSS. CCFS1 is zero in this case. NOTE 8â€”At most one of CCFS1 and CCFS2 is nonzero. NOTE 9â€”A supported multiple of Max VHT NSS applies to both transmit and receive. NOTE 10â€”2Ã— Max VHT NSS support might be used for HT PPDUs (at 20 or 40 MHz PPDU bandwidth). NOTE 11â€”A receiving STA in which dot11VHTExtendedNSSCapable is false will ignore the Extended NSS BW Support subfield and effectively evaluate this table only at the entries where Extended NSS BW Support is 0. 1099 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B0 B1 TVHT_MODE_2C Support TVHT_MODE_2N Support Bits: 1 1 Figure 9-560â€”Supported Channel Width Set field (TVHT) Support for short GI for the reception of packets with TXVECTOR parameter CH_BANDWIDTH equal to CBW20 or CBW40 is indicated in the HT Capabilities Info field of the HT Capabilities element. 9.4.2.158.3 Supported VHT-MCS and NSS Set field The Supported VHT-MCS and NSS Set field is used to convey the combinations of VHT-MCSs and spatial streams that a STA supports for reception and the combinations that it supports for transmission. The structure of the field is shown in Figure 9-561. B0 B15 B16 B28 B29 B31 B32 B47 B48 B60 B61 B62 B63 Rx Highest Tx Highest VHT Rx VHT-MCS Supported Maximum Tx VHT-MCS Supported Extended Map Long GI NSTS,total Map Long GI NSS BW Reserved Data Rate Data Rate Capable Bits: 16 13 3 16 13 1 2 Figure 9-561â€”Supported VHT-MCS and NSS Set field The Supported VHT-MCS and NSS Set fieldâ€™s subfields are defined in Table 9-251. Table 9-251â€”Supported VHT-MCS and NSS Set subfields Subfield Definition Encoding Rx VHT-MCS If transmitted by a STA in which The format and encoding of this subfield are Map dot11VHTEtxtendedNSSBWCapable is defined in Figure 9-562 and the associated not true, it indicates the maximum value description. of the RXVECTOR parameter MCS of a PPDU that can be received at all channel widths supported by this STA for each number of spatial streams. If transmitted by a STA in which dot11VHTExtendedNSSBWCapable is true, this field combined with the Extended NSS BW Support subfield and the 160/80+80 BW subfield of the Operating Mode field determines the maximum value of the RXVECTOR parameter MCS of a PPDU as described in 9.4.2.158.2 and 9.4.1.53. 1100 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-251â€”Supported VHT-MCS and NSS Set subfields (continued) Subfield Definition Encoding Rx Highest Indicates the highest long GI VHT PPDU The largest integer value less than or equal to Supported Long GI data rate that the STA is able to receive. the highest long GI VHT PPDU data rate in Data Rate Mb/s the STA is able to receive (see 10.7.12.1). The value 0 indicates that this subfield does not specify the highest long GI VHT PPDU data rate that the STA is able to receive. Maximum Indicates the maximum value for NSTS,total If MU beamformee capable and different from NSTS,total that can be sent to the STA in a VHT MU 0, indicates the maximum value for NSTS,total PPDU. minus 1 that can be sent to the STA in a VHT MU PPDU. NOTEâ€”This value is greater than or equal to the value in the Beamformee STS Capability subfield of the VHT Capabilities Information field. If MU Beamformee capable and equal to 0, indicates that the maximum value for NSTS,total is equal to the value in the Beamformee STS Capability subfield of the VHT Capabilities Information field. Otherwise reserved. Tx VHT-MCS If transmitted by a STA in which The format and encoding of this subfield are Map dot11VHTExtendedNSSBWCapable is defined in Figure 9-562 and the associated not true, indicates the maximum value of description. the TXVECTOR parameter MCS of a PPDU that can be transmitted at all channel widths supported by this STA for each number of spatial streams. If transmitted by a STA in which dot11VHTExtendedNSSBWCapable is true, this field combined with the Extended NSS BW Support subfield and the 160/80+80 BW subfield of an Operating Mode field determines the maximum value of the TXVECTOR parameter MCS of a PPDU as described in 9.4.2.158.2 and 9.4.1.53. Tx Highest Indicates the highest long GI VHT PPDU The largest integer value less than or equal to Supported Long GI data rate that the STA is able to transmit the highest long GI VHT PPDU data rate in Data Rate at. Mb/s that the STA is able to transmit (see 10.7.12.2). The value 0 indicates that this subfield does not specify the highest long GI VHT PPDU data rate that the STA is able to transmit. VHT Extended Indicates whether the STA is capable of If dot11VHTExtendedNSSBWCapable is true, NSS BW Capable interpreting the Extended NSS BW then this field is set to 1 to indicate that the Support subfield of the VHT Capabilities STA is capable of interpreting the Extended Information field. NSS BW Support subfield of the VHT Capabilities Information field. Set to 0 otherwise. 1101 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Rx VHT-MCS Map subfield and the Tx VHT-MCS Map subfield have the structure shown in Figure 9-562. B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 B10 B11 B12 B13 B14 B15 Max VHT- Max VHT- Max VHT- Max VHT- Max VHT- Max VHT- Max VHT- Max VHT- MCS For 1 MCS For 2 MCS For 3 MCS For 4 MCS For 5 MCS For 6 MCS For 7 MCS For 8 SS SS SS SS SS SS SS SS Bits: 2 2 2 2 2 2 2 2 Figure 9-562â€”Rx VHT-MCS Map and Tx VHT-MCS Map subfields and Basic VHT-MCS And NSS Set field The Max VHT-MCS For n SS subfield (where n = 1, ..., 8) is encoded as follows: â€” 0 indicates support for VHT-MCS 0-7 for n spatial streams â€” 1 indicates support for VHT-MCS 0-8 for n spatial streams â€” 2 indicates support for VHT-MCS 0-9 for n spatial streams â€” 3 indicates that n spatial streams is not supported The value of Max VHT NSS for a given MCS is equal to the smaller of: â€” the maximum value of n for which the Max VHT-MCS for n SS has a value that indicates support for that MAC (0, 1 or 2 for MCS 0-7, 1 or 2 for MCS 8, 2 for MCS 9) â€” the maximum supported NSS as indicated by the value of the Rx NSS field of the Operating Mode Notification frame if the value of RX NSS Type is 0 NOTEâ€”A VHT-MCS indicated as supported in the VHT-MCS Map fields for a particular number of spatial streams might not be valid at all bandwidths (see 21.5), might be limited by the declaration of Tx Highest Supported Long GI Data Rates and Rx Highest Supported Long GI Data Rates, and might be affected by 10.7.12.3 and the value of the Extended NSS BW Support field of the VHT Capabilities Information field in 9.4.2.158.2 and the 160/80+80 BW subfield of the Operating Mode field in 9.4.1.53. 9.4.2.159 VHT Operation element The operation of VHT STAs in the BSS is controlled by the HT Operation element and the VHT Operation element. The format of the VHT Operation element is defined in Figure 9-563. VHT Operation Basic VHT-MCS Element ID Length Information And NSS Set Octets: 1 1 3 2 Figure 9-563â€”VHT Operation element format The Element ID and Length fields are defined in 9.4.2.1. The structure of the VHT Operation Information field is defined in Figure 9-564. Channel Center Frequency Channel Center Frequency Channel Width Segment 0 Segment 1 Octets: 1 1 1 Figure 9-564â€”VHT Operation Information field 1102 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The VHT STA gets the primary channel information from the HT Operation element. The subfields of the VHT Operation Information field are defined in Table 9-252. Table 9-252â€”VHT Operation Information subfields Subfield Definition Encoding Channel Width This field, together with the HT Set to 0 for 20 MHz or 40 MHz BSS bandwidth. Operation element STA Channel Width field, defines the BSS Set to 1 for 80 MHz, 160 MHz or 80+80 MHz BSS bandwidth (see 11.40.1). bandwidth. Set to 2 for 160 MHz BSS bandwidth (deprecated). Set to 3 for non-contiguous 80+80 MHz BSS bandwidth (deprecated). Values in the range 4 to 255 are reserved. Channel Center Defines a channel center frequency For 80 MHz BSS bandwidth, indicates the channel Frequency Segment for an 80, 160, or 80+80 MHz VHT center frequency index for the 80 MHz channel on 0 BSS. See 21.3.14. which the VHT BSS operates. For 160 MHz BSS bandwidth and the Channel Width subfield equal to 1, indicates the channel center frequency index of the 80 MHz channel segment that contains the primary channel. For 160 MHz BSS bandwidth and the Channel Width subfield equal to 2, indicates the channel center frequency index of the 160 MHz channel on which the VHT BSS operates. For 80+80 MHz BSS bandwidth and the Channel Width subfield equal to 1 or 3, indicates the channel center frequency index for the primary 80 MHz channel of the VHT BSS. Reserved otherwise. Channel Center Defines a channel center frequency For a 20, 40, or 80 MHz BSS bandwidth, this Frequency Segment for a 160 or 80+80 MHz VHT BSS. subfield is set to 0. 1 See 21.3.14. For a 160 MHz BSS bandwidth and the Channel Width subfield equal to 1, indicates the channel center frequency index of the 160 MHz channel on which the VHT BSS operates. For a 160 MHz BSS bandwidth and the Channel Width subfield equal to 2, this field is set to 0. For an 80+80 MHz BSS bandwidth and the Channel Width subfield equal to 1 or 3, indicates the channel center frequency index of the secondary 80 MHz channel of the VHT BSS. See Table 9-253. Reserved otherwise. The Basic VHT-MCS And NSS Set field indicates the VHT-MCSs for each number of spatial streams in VHT PPDUs that are supported by all VHT STAs in the BSS (including IBSS and MBSS). The Basic VHT- MCS And NSS Set field is a bitmap of size 16 bits; each 2 bits indicates the supported VHT-MCS set for NSS from 1 to 8. The Basic VHT-MCS And NSS Set field is defined in Figure 9-562. 1103 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-253â€”BSS bandwidth when the VHT Operation Information field Channel Width subfield is 1 Channel Center Frequency BSS bandwidth Segment 1 subfield value CCFS1 = 0 80 MHz or less CCFS1 > 0 and 160 MHz | CCFS1 â€“ CCFS0 | = 8 (CCFS0: center frequency of the 80 MHz channel segment (40 MHz apart) that contains the primary channel) (CCFS1: center frequency of the 160 MHz channel) CCFS1 > 0 and 80+80 MHz | CCFS1 â€“ CCFS0 | > 16 (CCFS0: center frequency of the primary 80 MHz channel) (> 80 MHz apart) (CCFS1: center frequency of the secondary 80 MHz channel) CCFS1 > 0 and Reserved | CCFS1 â€“ CCFS0 | < 8 (< 40 MHz apart) CCFS1 > 0 and Reserved 8 < | CCFS1 â€“ CCFS0 | â‰¤ 16 (> 40 MHz and â‰¤ 80 MHz apart) NOTE 1â€”CCFS0 represents the value of the Channel Center Frequency Segment 0 subfield. NOTE 2â€”CCFS1 represents the value of the Channel Center Frequency Segment 1 subfield. 9.4.2.160 Extended BSS Load element The Extended BSS Load element reported by the AP contains information on MIMO spatial stream underutilization and bandwidth utilization. The element format is defined in Figure 9-565. A STA receiving the element might use the information it conveys in an implementation-specific AP selection algorithm. Observable Observable Observable MU-MIMO Element Length Capable STA Spatial Stream Secondary Secondary Secondary ID Underutilization 20 MHz 40 MHz 80 MHz Count Utilization Utilization Utilization Octets: 1 1 2 1 1 1 1 Figure 9-565â€”Extended BSS Load element format The Element ID and Length fields are defined in 9.4.2.1. The MU-MIMO Capable STA Count field indicates the total number of STAs currently associated with this BSS that have a 1 in the MU Beamformee Capable field of their VHT Capabilities element. The Spatial Stream Underutilization field is defined as the percentage of time, linearly scaled with 255 representing 100%, that the AP has underutilized spatial domain resources for given busy time of the medium. The spatial stream underutilization is calculated only for the primary channel. This percentage is computed using the formula, N max_SS T busy â€“ T utilized Spatial Stream Underutilization = ---------------------------------------------------------- 255 N max_SS T busy 1104 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications where N max_SS is the maximum number of spatial streams supported by the AP. T busy is the number of microseconds during which CCA indicated the channel was busy during the measurement duration. The resolution of the CCA busy measurement is in microseconds. N T utilized is N SS i T i , where T i is the time interval, in units of microseconds, during which the pri- i=1 mary 20 MHz channel is busy due to the transmission of one or more spatial streams by the AP to MU beamformee capable STAs; NSS,i is the number of spatial streams transmitted during the time interval T i ; and N is the number of busy events that occurred during the total measure- ment time which is less than or equal to dot11ChannelUtilizationBeaconIntervals consecutive beacon intervals. If T busy is 0, the Spatial Stream Underutilization field is reserved. The measurement of the observable loading on each of the secondary 20 MHz channel, secondary 40 MHz channel, and secondary 80 MHz channel in conjunction with the measurement on the primary 20 MHz channel provides a STA with the loading on the 40 MHz, 80 MHz, 160 MHz, and 80+80 MHz channels. The Observable Secondary 20 MHz Utilization, Observable Secondary 40 MHz Utilization, and Observable Secondary 80 MHz Utilization fields are defined using Equation (9-3). Observable Secondary W1 Utilization = (9-3) T busy W1 ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- - 255 dot11ChannelUtilizationBeaconIntervals dot11BeaconPeriod 1024 where dot11ChannelUtilizationBeaconIntervals represents the number of consecutive beacon intervals during which the secondary channel busy time is measured. Tbusy,W1 is computed as the sum of the times from PHY-CCA.indication(BUSY,{W2}) to the next issue of a PHY-CCA.indication primitive and that overlap the measurement interval, for W1 = 20, 40, or 80, and where W2 equals secondary, secondary40, or secondary80 for W1 = 20, 40, or 80, respectively. If the AP indicates a channel width of 20 MHz, 40 MHz, or 80 MHz in the STA Channel Width field in the HT Operation element and in the Channel Width field in the VHT Operation element, then the Observable Secondary 80 MHz Utilization field is reserved. If the AP indicates a channel width of 20 MHz or 40 MHz in the STA Channel Width field in the HT Operation element, then the Observable Secondary 40 MHz Utilization field is reserved. If the AP indicates a channel width of 20 MHz in the STA Channel Width field in the HT Operation element, then the Observable Secondary 20 MHz Utilization field is reserved. 9.4.2.161 Wide Bandwidth Channel Switch element The Wide Bandwidth Channel Switch element is included in Channel Switch Announcement frames, as described in 9.6.2.6, Extended Channel Switch Announcement frames, as described in 9.6.8.7, and TDLS Channel Switch Request frames, as described in 9.6.13.7. The format of the Wide Bandwidth Channel Switch element is shown in Figure 9-566. 1105 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications New New Element New Channel Center Channel Center Length ID Channel Width Frequency Frequency Segment 0 Segment 1 Octets: 1 1 1 1 1 Figure 9-566â€”Wide Bandwidth Channel Switch element format The Element ID and Length fields are defined in 9.4.2.1. The subfields New Channel Width, New Channel Center Frequency Segment 0, and New Channel Center Frequency Segment 1 have the same definition, respectively, as Channel Width, Channel Center Frequency Segment 0, and Channel Center Frequency Segment 1 in the VHT Operation Information field, described in Table 9-252. 9.4.2.162 Transmit Power Envelope element The Transmit Power Envelope element conveys the local maximum transmit power for various transmission bandwidths. The format of the Transmit Power Envelope element is shown in Figure 9-567. Element Transmit Local Maximum Local Maximum Local Maximum Local Maximum Length Power Transmit Power Transmit Power Transmit Power Transmit Power For ID Information For 20 MHz For 40 MHz For 80 MHz 160/80+80 MHz Octets: 1 1 1 1 0 or 1 0 or 1 0 or 1 Figure 9-567â€”Transmit Power Envelope element format The Element ID and Length fields are defined in 9.4.2.1. The format of the Transmit Power Information field is defined in Figure 9-568. B0 B2 B3 B5 B6 B7 Local Maximum Local Maximum Transmit Power Transmit Power Reserved Count Unit Interpretation Bits: 3 3 2 Figure 9-568â€”Transmit Power Information field The Local Maximum Transmit Power Count subfield indicates the number of Local Maximum Transmit Power For X MHz fields (where X = 20, 40, 80, or 160/80+80) minus 1 in the Transmit Power Envelope element, as shown in Table 9-254. 1106 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-254â€”Meaning of Local Maximum Transmit Power Count subfield Value Field(s) present 0 Local Maximum Transmit Power For 20 MHz. 1 Local Maximum Transmit Power For 20 MHz and Local Maximum Transmit Power For 40 MHz. 2 Local Maximum Transmit Power For 20 MHz, Local Maximum Transmit Power For 40 MHz, and Local Maximum Transmit Power For 80 MHz. 3 Local Maximum Transmit Power For 20 MHz, Local Maximum Transmit Power For 40 MHz, Local Maximum Transmit Power For 80 MHz, and Local Maximum Transmit Power For 160/80+80 MHz. For TVHT STAs, reserved. 4â€“7 Reserved The Local Maximum Transmit Power Unit Interpretation subfield provides additional interpretation for the units of the Local Maximum Transmit Power For X MHz fields (where X = 20, 40, 80, or 160/80+80) and is defined in Table 9-255. Allowed values are further constrained as defined in Annex E. Table 9-255â€”Definition of Local Maximum Transmit Power Unit Interpretation subfield Unit interpretation of the Value Local Maximum Transmit Power For X MHz fields 0 EIRP 1â€“7 Reserved NOTEâ€”This table is expected to be updated only if regulatory domains mandate the use of transmit power control with limits that cannot be converted into an EIRP value per transmission bandwidth. Local Maximum Transmit Power For X MHz fields (where X = 20, 40, 80, or 160/80+80) define the local maximum transmit power limit of X MHz PPDUs. Each Local Maximum Transmit Power For X MHz field is encoded as an 8-bit 2s complement signed integer in the range â€“64 dBm to 63 dBm with a 0.5 dB step. The value of 63.5 dBm indicates 63.5 dBm or higher (i.e., no local maximum transmit power constraint). In frames transmitted by a TVHT STA the Local Maximum Transmit Power for 20 MHz field indicates the Local Maximum Transmit Power for TVHT_W bandwidth; the Local Maximum Transmit Power for 40 MHz field indicates the Local Maximum Transmit Power for TVHT_2W or TVHT_W+W bandwidth; the Local Maximum Transmit Power for 80 MHz field indicates the Local Maximum Transmit Power for TVHT_4W or TVHT_2W+2W bandwidth; the Local Maximum Transmit Power for 160/80+80 MHz field is not included in the Transmit Power Envelope element. 1107 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.163 Channel Switch Wrapper element The Channel Switch Wrapper element contains subelements that indicate characteristics of the BSS after a channel switch. The format of the Channel Switch Wrapper element is defined in Figure 9-569. Procedures related to the inclusion of subelements in the Channel Switch Wrapper element are defined in 11.40.4. New Country Wide Bandwidth New Transmit Element Channel Switch Power Envelope ID Length subelement subelement subelement (optional) (optional) (optional) Octets: 1 1 variable variable variable Figure 9-569â€”Channel Switch Wrapper element format The Element ID and Length fields are defined in 9.4.2.1. The New Country subelement is present when an AP or mesh STA performs extended channel switching to a new Country, new Operating Class Table, or a changed set of operating classes relative to the contents of the Country element sent in the Beacon; otherwise, this subelement is not present. The format of the New Country subelement is defined to be the same as the format of the Country element (see 9.4.2.9), except that no Subband Triplet fields are present in the New Country subelement. The Country String field in the New Country subelement indicates the Country and Operating Class Table of the BSS after extended channel switching, and Operating Triplet fields within the New Country subelement indicate the operating classes of the BSS after extended channel switching (see 11.40.1). The Wide Bandwidth Channel Switch subelement is present under the following conditions: â€” Channel switching to a BSS bandwidth of 40 MHz or wider â€” Extended channel switching to a BSS bandwidth of 80 MHz or wider The Wide Bandwidth Channel Switch subelement is optionally present if extended channel switching to a BSS bandwidth of 40 MHz. The Wide Bandwidth Channel Switch subelement is not present if channel switching to a 20 MHz BSS bandwidth. The format of the Wide Bandwidth Channel Switch subelement is the same as the Wide Bandwidth Channel Switch element (see 9.4.2.161) except for the following: â€” A value 0 in the New Channel Width field signifies only a 40 MHz BSS bandwidth. â€” When switching to a 40 MHz BSS bandwidth, the New Channel Center Frequency Segment 0 field indicates the channel center frequency index for the 40 MHz channel after the channel switch. If present, the Wide Bandwidth Channel Switch subelement indicates the BSS bandwidth after channel switching (see 11.40.1). For example, when switching to a 40 MHz BSS bandwidth on channel indices 36 and 40, the New Channel Width field is set to 0, and the New Channel Center Frequency Segment 0 field is set to 38. Each New Transmit Power Envelope subelement that is present is defined to have the same format as the Transmit Power Envelope element (see 9.4.2.162) and includes a distinct value of the Local Maximum Transmit Power Unit Interpretation subfield. Each New Transmit Power Envelope subelement indicates the local maximum transmit powers for the BSS for the indicated bandwidths with an indicated unit interpretation after channel switching (see 11.40.1). 1108 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If transmitted by a TVHT STA, the Wide Bandwidth Channel Switch subelement is present when the STA is switching channels to a BSS bandwidth of TVHT_2W or TVHT_W+W bandwidth or wider; if switching to a TVHT_W bandwidth BSS bandwidth then this subelement is not present. 9.4.2.164 AID element The AID element includes the AID assigned by an AP during association that represents the 16-bit ID of a STA. The format of the AID element is shown in Figure 9-570. Element Length AID ID Octets: 1 1 2 Figure 9-570â€”AID element format The Element ID and Length fields are defined in 9.4.2.1. The AID field is defined in 9.4.1.8. 9.4.2.165 Quiet Channel element The Quiet Channel element is used to indicate that the secondary 80 MHz channel of a VHT BSS is to be quieted during a quiet interval, and, in an infrastructure BSS, to indicate if the primary 80 MHz channel of a VHT BSS can be used during the quiet interval. A quiet interval is established using either a Quiet element (see 9.4.2.23) or, in an infrastructure BSS, the Quiet Channel element if its AP Quiet Mode field is equal to 1. The Quiet Channel element is optionally present in Beacon frames, as described in 9.3.3.3, and Probe Response frames, as described in 9.3.3.11. The use of Quiet Channel elements is described in 11.9.3. The format of the Quiet Channel element is shown in Figure 9-571. Quiet Element Length AP Quiet Quiet Count Quiet Period Duration Quiet Offset ID Mode (optional) (optional) (optional) (optional) Octets: 1 1 1 0 or 1 0 or 1 0 or 2 0 or 2 Figure 9-571â€”Quiet Channel element format The Element ID and Length fields are defined in 9.4.2.1. The AP Quiet Mode field specifies STA behavior in an infrastructure BSS during the quiet intervals. When communications to the AP are allowed within the primary 80 MHz channel, then the AP Quiet Mode field is set to 1. Otherwise, the AP Quiet Mode field is set to 0. If the AP Quiet Mode field is 1, then the Quiet Count field, Quiet Period field, Quiet Duration field, and Quiet Offset field are present in the Quiet Channel element; otherwise, these fields are not present in the Quiet Channel element. The Quiet Count field, Quiet Period field, Quiet Duration field, and Quiet Offset field have the same definition as described in 9.4.2.23. 1109 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.166 Operating Mode Notification element The Operating Mode Notification element is used to notify STAs that the transmitting STA is changing one or more of its operating channel width, the maximum number of spatial streams it can receive, and its LDPC receive preference. The format of the Operating Mode Notification element is defined in Figure 9-572. Element Length Operating ID Mode Octets: 1 1 1 Figure 9-572â€”Operating Mode Notification element The Element ID and Length fields are defined in 9.4.2.1. The Operating Mode field is defined in 9.4.1.53. 9.4.2.167 UPSIM element The UPSIM element is defined as shown in Figure 9-573. Element ID Length UPSIM Flags Partial Unsched- uled Power Save Bitmap Octets: 1 1 1 0-32 Figure 9-573â€”UPSIM element format The Element ID and Length fields are defined in 9.4.2.1. The Length field for this element is constrained as described below. The UPSIM Flags field is defined in Figure 9-574. B0 B1 B2 B3 B7 PS PCP PS Non-PCP Reserved Bitmap Offset Bits: 1 1 1 5 Figure 9-574â€”UPSIM Flags field format The PS PCP field is set to 1 if the PCP is in unscheduled PS mode at the time of UPSIM element transmission and is set to 0 otherwise. The PS PCP field is set to 0 in infrastructure BSS. The PS Non-PCP field is set to 1 if all non-AP and non-PCP STAs are in unscheduled PS mode at the time of UPSIM element transmission and is set to 0 otherwise. The Bitmap Offset field defines the octet offset into a virtual bitmap maintained by the AP or PCP, as described below. The AP or PCP maintains an unscheduled power save indication virtual bitmap that is 256 bits in length and is organized into 32 octets such that bit number N ( 0 N 255 ) in the bitmap corresponds to bit number (N mod 8) in octet number N / 8 , where the low order bit of each octet is bit number 0, and the high order bit is bit number 7. Bit N in the bitmap is set to 1 if there is an associated DMG STA with AID equal to N and the STA is in unscheduled PS mode and is set to 0 if there is no associated DMG STA with AID equal to N or the STA is not in unscheduled PS mode. Bit 0 is set to 0 in the infrastructure BSS. Bit 255 is set to 0. 1110 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Partial Unscheduled Power Save Bitmap field is not present when bits numbered 1 to 254 of the unscheduled power save indication virtual bitmap all have the same value at the time of UPSIM element transmission. In this case, the Length field is set to 1 and the Bitmap Offset field is set to 0. When there are two bits in the unscheduled power save indication virtual bitmap with numbers between 1 and 254 and different values, the Partial Unscheduled Power Save Bitmap field consists of octets numbered N1 to N2 of the unscheduled power save indication virtual bitmap, where N1 is the largest integer such that bits numbered 1 to (N1Ã— 8) - 1 in the unscheduled power save indication virtual bitmap are all 0, and N2 is the smallest number such that bits numbered (N2 + 1) Ã— 8 to 255 in the unscheduled power save indication virtual bitmap are all 0. In this case, the Length field is set to (N2 - N1) + 2 and the Bitmap Offset subfield is set to N1. NOTEâ€”The Partial Unscheduled Power Save Bitmap field does not need to include bit 0 of the unscheduled power save indication virtual bitmap even if that bit is set. 9.4.2.168 Fine Timing Measurement Parameters element The Fine Timing Measurement Parameters element contains a number of fields that are used to advertise the requested or allocated FTM configuration from one STA to another. The Fine Timing Measurement Parameters element is included in the initial Fine Timing Measurement Request frame, as described in 9.6.8.32, and the initial Fine Timing Measurement frame, as described in 9.6.8.33. The use of the Fine Timing Measurement Parameters element is described in 11.24.6. The format of the Fine Timing Measurement Parameters element is shown in 9-575. Element ID Length Fine Timing Measurement Parameters Octets: 1 1 9 Figure 9-575â€”Fine Timing Measurement Parameters element format The format of the Fine Timing Measurement Parameters field is shown in 9-576. B0 B1 B2 B6 B7 B8 B11 B12 B15 B16 B23 B24 B39 Status Value Reserved Number of Burst Min Delta Partial Indication Bursts Duration FTM TSF Timer Exponent Bits: 2 5 1 4 4 8 16 B40 B41 B42 B43 B47 B48 B49 B50 B55 B56 B71 Partial TSF ASAP Capable ASAP FTMs per Reserved Format And Burst Timer No Burst Bandwidth Period Preference Bits: 1 1 1 5 2 6 16 Figure 9-576â€”Fine Timing Measurement Parameters field format The Element ID and Length fields are defined in 9.4.2.1. The Status Indication field indicates the responding STAâ€™s response to the Fine Timing Request. The encoding of the Status Indication field is shown in Table 9-256. 1111 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-256â€”Status Indication field values Value Description 0 Reserved 1 Successful (some requested parameters might have been overridden). Measurement exchanges are about to begin. 2 Request incapable. Do not send same request again. FTM session ends. 3 Request failed. Do not send new request for Value seconds. FTM session ends. The Status Indication field and Value field are reserved in the initial Fine Timing Measurement Request frame. When the Status Indication field is set to 3 by the responding STA, the Value field contains a duration in units of seconds; otherwise the Value field is reserved. The Number of Bursts Exponent field indicates how many burst instances, defined in 11.24.6.4, are requested for the FTM session if included in an initial Fine Timing Measurement Request frame, or allocated for the FTM session if included in an initial Fine Timing Measurement frame respectively, where the number of burst instances is 2Number of Bursts Exponent. The value 15 in an initial Fine Timing Measurement Request frame indicates no preference by the initiating STA and is valid (indicating 215 burst instances) when set by the responding STA. The Burst Duration field indicates the duration of a burst instance. The value 15 in the initial Fine Timing Measurement Request indicates no preference by the initiating STA and is not used by the responding STA. Table 9-257 shows the encoding of this field. Table 9-257â€”Burst Duration field encoding Value Represents 0-1 Reserved 2 250 Âµs 3 500 Âµs 4 1 ms 5 2 ms 6 4 ms 7 8 ms 8 16 ms 9 32 ms 10 64 ms 11 128 ms 12â€“14 Reserved 15 No preference The Min Delta FTM field indicates the minimum time between consecutive Fine Timing Measurement frames. It is measured from the start of a Fine Timing Measurement frame to the start of following Fine 1112 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Timing Measurement frame, in units of 100 Âµs. The value 0 indicates no preference by the initiating STA and is not used by the responding STA. The Partial TSF Timer field in an initial Fine Timing Measurement frame indicates the partial value of the responding STAâ€™s TSF timer at the start of the first burst instance of an FTM session. The responding STAâ€™s TSF timer at the start of the first burst instance of an FTM session is limited to less than 62/64 of 65 536 TUs (<63 488 TUs) ahead of the TSF time at which the STA transmits the Fine Timing Measurement frame and 1/64 of 65 536 TUs earlier (inclusive) (â‰¥1024 TUs) than the TSF time at which the STA transmits the Fine Timing Measurement frame, as shown in Figure 9-577. The Partial TSF Timer value is derived as follows, so as to have units of TUs: from the 64 TSF timer bits at the start of the first burst instance of an FTM session, where the 10 least significant bits equal 0, remove the most significant 38 bits and the least significant 10 bits. NOTEâ€”1024 TUs out of the full range of the Partial TSF Timer field are not used in order to allow the recipient to resolve ambiguity arising from 1) imperfect synchronization between the initiating and responding STAs, and 2) retries of the initial Fine Timing Measurement Request frame or retransmissions of the initial Fine Timing Measurement frame. The initiating STA indicates a preferred time for the start of the first burst instance by setting the Partial TSF Timer No Preference field to 0 and by setting the Partial TSF Timer field to indicate the preferred start of the first burst instance. Otherwise the Partial TSF Timer No Preference field is set to 1 and the Partial TSF Timer field is reserved. The Partial TSF Timer No Preference field is reserved when the FTM Parameters element is included in an initial Fine Timing Measurement frame. Unused Earlier Ahead (Indicated TSF[10:25] - TSF[10:25]) mod 65536 63488 64511 64512 65535 0 63487 Partial TSF indicated in a) Initial FTM Request frame with ASAP=0 or 1, or b) Initial FTM frame with ASAP=0 Partial TSF indicated in initial FTM frame with ASAP=1 Figure 9-577â€”Calculation of Partial TSF Timer field The ASAP Capable field indicates that the responding STA is capable of sending a Fine Timing Measurement frame as soon as possible; that is, the STA is capable of capturing timestamps associated with an initial Fine Timing Measurement frame and sending them in the following Fine Timing Measurement frame. This field is reserved in the initial Fine Timing Measurement Request frame. The ASAP field indicates the initiating STAâ€™s request to start the first burst instance of the FTM session as soon as possible. When the ASAP field is set to 0 and the Partial TSF Timer No Preference field is set to 0 by an initiating STA, the initiating STA requests the start of the first burst instance specified by the Partial TSF Timer field in the initial Fine Timing Measurement Request frame. When the ASAP field is set to 1 and the Partial TSF Timer No Preference field is set to 0 by an initiating STA, the Partial TSF Timer field in the Fine Timing Measurement Request frame indicates the requested start of the first burst instance if the ASAP field is set to 0 in the initial Fine Timing Measurement frame. The ASAP field is also used by the responding STA to signal whether that request has been honored or not. When the ASAP field is set to 0 by the responding STA, the Partial TSF Timer field in the initial Fine Timing Measurement frame indicates the start time of the first burst instance and the earliest time the Fine Timing Measurement Request frame (see 11.24.6.4) should be sent by the initiating STA. When the ASAP field is set to 1 by the responding STA, the Partial TSF Timer field in the initial Fine Timing Measurement frame indicates the start time of the first burst instance and the earliest time the initial Fine Timing Measurement frame will be sent. The responding 1113 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STA sets the ASAP field to 1 to indicate the STAâ€™s intent to send a Fine Timing Measurement frame as soon as possible. The FTMs per Burst field indicates how many successfully transmitted Fine Timing Measurement frames are requested per burst instance by the initial Fine Timing Measurement Request frame, or allocated by the initial Fine Timing Measurement frame, respectively. The value 0 indicates no preference by the initiating STA and is not used by the responding STA. The Format And Bandwidth field indicates the requested or allocated PPDU format and bandwidth that can be used by Fine Timing Measurement frames in an FTM session and is shown in Table 9-258. The value 0 indicates no preference by the initiating STA in the associated state and is not used by the responding STA.The value 0 is not used by the initiating STA in the unassociated state. Table 9-258â€” Format And Bandwidth field Field value Format Bandwidth (MHz) 0 No preference No preference 1-3 Reserved Reserved 4 Non-HT 5 5 Reserved Reserved 6 Non-HT 10 7 Reserved Reserved 8 Non-HT, 20 excluding Clause 15 and Clause 16 9 HT mixed 20 10 VHT 20 11 HT mixed 40 12 VHT 40 13 VHT 80 14 VHT 80+80 15 VHT (two 160 separate RF LOs) 16 VHT (single RF 160 LO) 17-30 Reserved Reserved 31 DMG 2160 32â€“63 Reserved Reserved NOTEâ€”See 21.3.17.3 regarding the usage of two separate RF LOs. 1114 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Burst Period field indicates the interval between two consecutive burst instances, in units of 100 ms. The value 0 indicates no preference by the initiating STA. This field is reserved when the Number of Bursts Exponent field is set to 0. 9.4.2.169 Device Location element A Device Location element includes the location configuration information (LCI), which contains latitude, longitude, and altitude information. The Device Location element format is shown in Figure 9-578. Element ID Length Device Location Information Body Octets 1 1 16 Figure 9-578â€”Device Location element format The Element ID and Length fields are defined in 9.4.2.1. The format of the Device Location Information Body is defined in 9.4.1.56. 9.4.2.170 White Space Map element The White Space Map element includes available radio frequency information obtained from a GDB. The format of the WSM Information field is determined by the value of the WSM Type field. The format of the White Space Map Announcement element is shown in Figure 9-579. Element ID Length WSM Type WSM Information Octets: 1 1 1 variable Figure 9-579â€”WSM element format The Element ID and Length fields are defined in 9.4.2.1. The format and values of WSM Type and WSM Information fields are defined in 9.4.1.57. 9.4.2.171 Reduced Neighbor Report element The Reduced Neighbor Report element contains channel and other information related to neighbor APs. The format of the Reduced Neighbor Report element is shown in Figure 9-580. Element ID Length Neighbor AP Information Fields Octets: 1 1 variable Figure 9-580â€”Reduced Neighbor Report element format The Element ID and Length fields are defined in 9.4.2.1. The Neighbor AP Information Fields field contains one or more of the Neighbor AP Information field described in 9.4.2.171.1. 1115 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.2.171.1 Neighbor AP Information field The Neighbor AP Information field specifies TBTT and other information related to a group of neighbor APs on one channel. See Figure 9-581. TBTT Infor- Operating Channel TBTT Infor- mation Class Number mation Set Header Octets: 2 1 1 variable Figure 9-581â€”Neighbor AP Information field format The format of TBTT Information Header subfield is defined in Figure 9-582. B0 B1 B2 B3 B4 B7 B8 B15 TBTT Filtered Reserved TBTT TBTT Information Neighbor AP Information Information Field Type Count Length Bits: 2 1 1 4 8 Figure 9-582â€”TBTT Information Header subfield The TBTT Information Field Type subfield is 2 bits in length and defines the structure of the TBTT Information field. Its value is 0. Values 1, 2, and 3 are reserved. The Filtered Neighbor AP subfield is 1 bit in length. It is set to 1 if the SSID of APs in this Neighbor AP Information field matches the specific SSID in the Probe Request frame. It is set to 0 otherwise. This field is valid only in the Reduced Neighbor Report element in a Probe Response frame and is reserved otherwise. The TBTT Information Count subfield is 4 bits in length and contains the number of TBTT Information fields that are included in the Neighbor AP Information field, minus one. A value of 0 indicates one TBTT Information field is present. The TBTT Information Length subfield is 1 octet in length and contains the length in octets of each TBTT Information field that is included in the Neighbor AP Information field. The Operating Class field is 1 octet in length and indicates a channel starting frequency that, together with the Channel Number field, indicates the primary channel of the BSSs of the APs in this Neighbor AP Information field. Values of Operating Class are shown in Table E-4, of which operating classes that, together with the channel number, indicate the primary channel is valid (see 11.44.8). NOTEâ€”The Operating Class field and Channel Number tuple indicate the primary channel in order to assist with passive scanning. The Channel Number field is 1 octet in length and indicates the last known primary channel of the APs in this Neighbor AP Information field. Channel Number is defined within an Operating Class as shown in Table E-4. The TBTT Information Set field contains one or more TBTT Information fields. The TBTT Information field is defined in Figure 9-583. 1116 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Neighbor AP TBTT Offset Octets: 1 Figure 9-583â€”TBTT Information field The Neighbor AP TBTT Offset subfield is 1 octet in length and indicates the offset in TUs, rounded down to nearest TU, to the next TBTT of an AP from the immediately prior TBTT of the AP that transmits this element. The value 254 indicates an offset of 254 TUs or higher. The value 255 indicates an unknown offset value. 9.4.2.172 TVHT Operation element The operation of TVHT STAs in the BSS is controlled by the TVHT Operation element. The format of the TVHT Operation element is defined in Figure 9-584. Element ID Length TVHT Operation Basic VHT-MCS Information And NSS Set Octets: 1 1 4 2 Figure 9-584â€”TVHT Operation element format The Element ID and Length fields are defined in 9.4.2.1. The structure of the TVHT Operation Information field is defined in Figure 9-585. Primary Channel Width Channel Center Channel Center Channel Frequency Seg- Frequency Seg- Number ment0 ment1 Octets: 1 1 1 1 Figure 9-585â€”TVHT Operation Information field The subfields of the TVHT Operation Information field are defined in Table 9-259. Table 9-259â€”TVHT Operation Information subfields Field Definition Encoding Primary Indicates the channel number Channel number of the primary channel. Channel of the primary channel (see Number 11.43). Channel This field defines the BSS Set to 0 for TVHT_W BSS bandwidth. Width bandwidth (see 11.43). Set to 1 for TVHT_2W BSS bandwidth. Set to 2 for TVHT_W+W BSS bandwidth. Set to 3 for TVHT_4W BSS bandwidth. Set to 4 for non-contiguous TVHT_2W+2W BSS bandwidth. Values in the range 5 to 255 are reserved. 1117 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-259â€”TVHT Operation Information subfields (continued) Field Definition Encoding Channel Defines the channel center For TVHT_W or TVHT_2W or TVHT_4W BSS bandwidth, Center frequency for a TVHT_W, indicates the center frequency of the lowest TV channel index Frequency TVHT_2W, and TVHT_4W for the TVHT_W or TVHT_2W or TVHT_4W channel on Segment0 TVHT BSS and the segment which the TVHT BSS operates. 0 channel center frequency For TVHT_W+W or TVHT_2W+2W BSS bandwidth, indicates for a TVHT_W+W and the lowest TV channel index for the TVHT_W or TVHT_2W TVHT_2W+2W TVHT BSS. channel of frequency segment 0 on which the TVHT BSS See 22.3.14. operates. Reserved otherwise. Channel Defines the segment 1 For TVHT_W+W or TVHT_2W+2W BSS bandwidth, indicates Center channel center frequency for the lowest TV channel index in the segment for the TVHT_W or Frequency a TVHT_W+W and TVHT_2W channel of frequency segment 1 on which the TVHT Segment1 TVHT_2W+2W TVHT BSS. BSS operates. See 22.3.14. Reserved otherwise. The Basic VHT-MCS And NSS Set field indicates the MCSs for each spatial stream in VHT PPDU in TVWS bands that are supported by all TVHT STAs in the BSS (including IBSS). The Basic VHT-MCS And NSS Set field is a bitmap of size 16 bits; B8-B9, B10-B11, B12-B13, and B14-B15 are set to 3. For B0-B7, each 2 bits indicates the supported MCS set for N SS from 1 to 4. The Basic VHT-MCS And NSS Set field is defined as B0-B7 of Rx VHT-MCS Map subfield in 9.4.2.158.3. 9.4.2.173 FTM Synchronization Information element The format of the FTM Synchronization Information element is defined in Figure 9-586. Element ID Length Element ID TSF Sync Info Extension Octets: 1 1 1 4 Figure 9-586â€”FTM Synchronization Information element format The Element ID, Length and Element ID Extension fields are defined in 9.4.2.1. The TSF Sync Info field is set to the 4 least significant octets of the value of TSF. 9.4.2.174 Estimated service parameters element The Estimated Service Parameters element is used by a STA to provide information to another STA which can then use the information as input to an algorithm to generate an estimate of throughput between the two STAs. The format of the Estimated Service Parameters element is shown in Figure 9-587. Element ID ESP Information Element ID Length Extension List Octets: 1 1 1 variable Figure 9-587â€”Estimated Service Parameters element format 1118 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Element ID, Length, and Element ID Extension fields are defined in 9.4.2.1. The ESP Information List field contains from 1 to 4 ESP Information fields, each corresponding to an access category for which estimated service parameters information is provided. The format of the ESP Information field is shown in Figure 9-588. B0 B1 B2 B3 B4 B5 B7 B8 B15 B16 B23 Access Estimated Air Data PPDU Category Reserved Data Format BA Window Size Time Fraction Duration Target Bits: 2 1 2 3 8 8 Figure 9-588â€”ESP Information field format The Access Category subfield is two bits in length and indicates the access category to which the remaining parameters of the ESP Information field apply. The encoding of the Access Category subfield is given in Table 9-260. When parameters for more than one access category are present in an Estimated Service Parameters element the ESP Information fields for the access categories appear in order of Access Category subfield value, with the ESP Information field with the lowest Access Category subfield value appearing first. Table 9-260â€”Access Category subfield encoding Access Value Category 0 AC_BK 1 AC_BE 2 AC_VI 3 AC_VO The Data format subfield is two bits in length and has the meaning indicated in Table 9-261. Table 9-261â€”Data Format subfield encoding Value Description 0 No aggregation is expected to be performed for MSDUs or MPDUs with the Type subfield equal to Data for the corresponding AC 1 A-MSDU aggregation is expected to be performed for MSDUs for the corresponding AC, but A-MPDU aggregation is not expected to be performed for MPDUs with the Type subfield equal to Data for the corresponding AC 2 A-MPDU aggregation is expected to be performed for MPDUs with the Type subfield equal to Data for the corresponding AC, but A-MSDU aggregation is not expected to be performed for MSDUs for the corresponding AC 3 A-MSDU aggregation is expected to be performed for MSDUs for the corresponding AC and A-MPDU aggregation is expected to be performed for MPDUs with the Type subfield equal to Data for the corresponding AC 1119 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The BA Window Size subfield is three bits in length and indicates the size of the Block Ack window that is expected for the corresponding access category as defined in Table 9-262. When the Block Ack window size expected to be used by the transmitter of the element does not match any of the values shown in the table, the transmitter uses the next lower value in the table. Table 9-262â€”BA Window Size subfield encoding Value Expected block ack window size 0 Block Ack not expected to be used 1 2 2 4 3 6 4 8 5 16 6 32 7 64 The Estimated Air Time Fraction subfield is 8 bits in length and contains an unsigned integer that represents the predicted percentage of time, linearly scaled with 255 representing 100%, that a new STA joining the BSS will be allocated for PPDUs that contain only MPDUs with the Type subfield equal to Data of the corresponding access category for that STA. The Data PPDU Duration Target field is 8 bits in length and is an unsigned integer that indicates the expected target duration of PPDUs that contain only MPDUs with the Type subfield equal to Data for the corresponding access category in units of 50 Âµs. 9.4.2.175 Future Channel Guidance element Future Channel Guidance element is used by an AP, IBSS STA, mesh STA, or PCP to guide STAs about the likely future channel if the sending STA changes channels of operation. The format of the Future Channel Guidance element is shown in Figure 9-589. Element Length Element New Second- Mesh Wide New ID ID Exten- Channel ary Chan- Channel Band- Transmit sion Number nel Offset Switch width Power element Parame- Channel Envelope ters ele- Switch element ment element Octets: 1 1 1 4 0 or 3 0 or 6 0 or 5 variable Figure 9-589â€”Future Channel Guidance element format The Element ID, Length and Element ID Extension fields are defined in 9.4.2.1. The New Channel Number field is set to the number of the channel to which the STA will be moving in the event of a channel switch (as defined in 17.3.8.4.3). 1120 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Secondary Channel Offset element is defined in 9.4.2.20. This element is present when switching to a 40 MHz or wider channel. It is optionally present when switching to a 20 MHz channel (in which case the Secondary Channel Offset field is set to SCN). See 11.40.4. The Mesh Channel Switch Parameters element is defined in 9.4.2.103. This element is present when a mesh STA performs MBSS channel switch. Otherwise, the Mesh Channel Switch Parameters element is not present. The Wide Bandwidth Channel Switch element is defined in 9.4.2.161. This element is present when switching to a channel width wider than 40 MHz. Each New Transmit Power Envelope element that is present is defined to have the same format as the Transmit Power Envelope element (see 9.4.2.162 and includes a distinct value of the Local Maximum Transmit Power Unit Interpretation subfield. If present, the New Transmit Power Envelope element indicates the local maximum transmit powers for the BSS for the BSS for the indicated bandwidths with an indicated unit interpretation after channel switching (see 11.40.1). The Future Channel Guidance procedure is defined in 11.9.10. 9.4.3 Subelements Subelements are defined to have a common general format consisting of a 1-octet element-specific Subelement ID field, a 1-octet Length field, and a variable-length subelement-specific Data field. Each subelement is assigned a subelement ID that is unique within the containing element or subelement. The Length field specifies the number of octets in the Data field. See Figure 9-590. Subelement ID Length Data Octets: 1 1 variable Figure 9-590â€”Subelement format At the location in this standard that a subelement is defined, the definition might indicate if the subelement is extensible, typically using a table column called â€œExtensibleâ€ in the table in which subelement IDs are defined. A subelement that is indicated as extensible (typically with â€œYesâ€ in the â€œExtensibleâ€ column) might be extended in future revisions or amendments of this standard. A subelement that is indicated as extensible through subelements (typically with â€œSubelementsâ€ in the â€œExtensibleâ€ column) might be extended in future revisions or amendments of this standard by defining (additional) subelements within the subelement. If the definition of a subelement does not indicate whether it is extensible (e.g., there is no â€œExtensibleâ€ column in a table defining it) that subelement is not extensible. A subelement that is not defined as extensible will not be extended in future revisions or amendments of this standard. Subelements within an element are ordered by nondecreasing Subelement ID. See 10.27.9. 1121 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.4 TLV encodings 9.4.4.1 General The following TLV encodings are used to convey parameters within MAC Management frames (9.3.3, 9.4, and 9.6). TLV tuples with type values that are unknown, not specified in this subclause, or specified as â€œreservedâ€ are discarded upon receipt. The form of TLVs is shown in Table 9-263. Table 9-263â€”General TLV format Length Scope/ Name Type Value (octets) Country code The name of the 1 variable Single Octet, Single Value, or Compound TLV TLV tuples. NOTEâ€”This standard is complete regarding the endianness of multi-octet fields as they are covered by 9.2.2. Be aware that most protocols above the MAC operate in the opposite endianness. Name is the name of the TLV tuple. The â€˜m.nâ€™ syntax in the Type field means that the TLV has type n, an unsigned 1-octet integer, and is embedded in the Value field of a TLV of type m. The length of the Type field is 1 octet. The format of the Length field is an unsigned number of size 1 octet, and the value in the Length field specifies the number of octets in the Value field. A single octet TLV has a Value field that is a single octet, a single value TLV has a Value field larger than 1- octet, and a compound TLV has a Value field that represents more than 1-octet fields. When a Scope field entry contains two characters, it identifies the country or other entity to which the STAâ€™s operation is bound. If the two-character value stands for a country or other entity, then the value matches a code defined in ISO 3166-1. When a Scope field entry contains more than two characters, it identifies a scope for the TLV tuple. 9.4.4.2 Common TLVs The general form of common TLVs is shown in Table 9-263 and is used in 9.4.4.2.1 to 9.4.4.2.5. 9.4.4.2.1 Device Class This parameter contains the intended class of device for operation in TVWS band after it receives the available channel list at its location. The Device Class field format is shown in Table 9-264. 1122 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-264â€”Device Class field definition Length Scope/ Name Type Value (octets) Country code Device Class 2 1 The Device Class field contains an integer that CAQ, indicates the deviceâ€™s TVWS band mode of GDDENABLE operation as follows: MENT, WSM 0: GDD non-AP STA 1: GDD geolocated non-AP STA 2: GDD AP 3: GDD fixed STA 4â€“255: Reserved 9.4.4.2.2 Device Identification Information This parameter contains the identification information of the device initiating the channel availability query. The Device Identification Information field format is shown in Table 9-265 and related Device Identification Information Value fields tables in E.2 for specific regulatory domains. Table 9-265â€”Device Identification Information field definition Length Scope/ Name Type Value (octets) Country code Device 3 variable One or more TLV fields as defined in Table E-8 for a CAQ, Identification specific regulatory domain. GDDENABLE Information MENT, CSM 9.4.4.2.3 Device Location Information This parameter contains the location information of the device initiating the channel availability query. The Device Location Information field format is shown in Table 9-266. Table 9-266â€”Device Location Information field definition Length Scope/ Name Type Value (octets) Country code Device Location 10 16 The Device Location Information field contains the CAQ Information latitude, longitude, and altitude information of the device in the format specified by the Device Location Information Body fields in Figure 9-121. When the Device Type subfield (see Table 9-264) is not GDD fixed STA, the altitude information (Altitude Type, Altitude Uncertainty, and Altitude subfields) of the Device Location Information field remain unused. 1123 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.4.2.4 Channel Schedule Descriptor This parameter contains the channel number associated with channel schedule information used for channel schedule management. The Channel Schedule Descriptor Tuple attribute format is shown in Table 9-267 and Table 9-268. Channel Schedule Descriptor field is constructed with either Channel Availability Starting Time field or Channel Availability Starting Timestamp field present or neither of these two fields present. Table 9-267â€”Channel Schedule Descriptor Tuple attribute definition Length Scope/ Name Type Value (octets) Country code Channel 11 variable Compound TLVs in Table 9-268. CSM Schedule Descriptor Table 9-268â€”Channel Schedule Descriptor Value fields Length Scope/ Name Subtype Value (octets) Country code Operating Class 1 1 The Operating Class field is the number of the CSM operating class of the channel, which is defined in E.1. Channel Number 2 1 The Channel Number field is the number of the CSM channel, which is the subject of the value of Channel Schedule Management Mode field. If the Channel Schedule Management Mode field indicates the schedule information is based on WLAN channels, the Channel Number is a channel from the STAâ€™s operating class as defined in E.1; otherwise, the Operating Class compound TLV is not present, and the Channel Number is a positive integer value as defined in D.1 to indicate the available TV channel for WLAN operation. Channel 3 8 The Channel Availability Starting Time field CSM Availability indicates the starting time in Coordinated Universal Starting Time Time (UTC) from when the channel indicated in the Channel Number field is available for operation. When neither this field nor a Channel Availability Starting Timestamp is present, the STA takes the time that the response element is received as the starting time of the channel availability. NOTEâ€”The Channel Availability Starting Time field follows the UTC time definition of the Time Value field of the Time Advertisement element in 9.4.2.61, and the first 6 octets are used to indicate the UTC time until minutes. The left 2 octets are reserved. 1124 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-268â€”Channel Schedule Descriptor Value fields (continued) Length Scope/ Name Subtype Value (octets) Country code Channel 4 8 The Channel Availability Starting Timestamp field CSM Availability indicates the starting timestamp from when the Starting channel indicated in the Channel Number field is Timestamp available for operation. When neither this field nor a Channel Availability Starting Time field is present, the STA takes the time that the response element is received as the starting time of the channel availability. Channel 5 2 The Channel Availability Offset Time field indicates CSM Availability the offset of channel availability time with respect to Offset Time the time that the Channel Schedule Descriptor is received. This field is present when the Channel Availability Starting Time field is not present in the response TLV and the channel is not available at the moment the TLV is received. Channel 6 2 The Channel Availability Duration field indicates the CSM Availability duration in minutes of the availability of the channel Duration that indicated in the Channel Number field. 9.4.4.2.5 WSM information values The format of the WSM information values is shown in Table 9-269. If the value of WSM Type field of the White Space Map element (9.4.1.57) is 1, the WSM Information field specifies available channel information for TVWS, which is country-specific. Table 9-269â€”WSM information values Length Scope/ Name Type Value (octets) Country code WSM 12 variable Single value TLV comprising fields in related table WSM Information in E.2 for a specific regulatory domain. 1125 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The format of the WSM Information Value fields is shown in Table 9-270. Table 9-270â€”WSM Information Value fields Length Scope/ Name Value (octets) Country code Device Class 1 Single octet TLV comprising fields in Table 9-264. WSM Map ID 1 Bit 0: Type bit indicates whether the following channel list is a WSM full channel list or a partial channel list. If the Type bit is 1, the following channel list is a full channel list; and if the Type bit is 0, the following channel list is a partial channel list. Bits 1â€“7: Map version identifies the version of the WSM. Channel Number 1 Channel Number field in related WSM Information Value fields WSM table in E.2. Maximum Power 1 Maximum Power Level field in related WSM Information Value WSM Level fields table in E.2. Validity 1 The Validity field indicates the time duration in minutes for WSM, UK which the Channel Number is available with the allowed maximum power level, where the Validity field is provided for each available Channel Number. Maximum 2 Limits on the maximum contiguous and maximum WSM, UK Channel noncontiguous instantaneous bandwidths of STA specified as Bandwidth n Ã— 0.1 MHz, where n > 0. The Device Class field is defined in 9.4.4.2.1 and identifies the device class used by the WSM. It determines the length of the channel availability tuple consisting of the Channel Number, Maximum Power Level, and Validity fields, which is repeated as indicated by the Length field of the WSM element. If the Device Class field is 0, the Validity field in WSM Information Value field is not present. Otherwise, the Validity field exists in the WSM Information Value field. 1126 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.5 Access network query protocol (ANQP) elements 9.4.5.1 General ANQP-elements are defined to have a common format consisting of a 2-octet Info ID field (information identifier), a 2-octet Length field, and a variable-length ANQP-element-specific Information field. Each element is assigned a unique Info ID as defined in this standard. The ANQP-element format is shown in Figure 9-591. See R.2 for informative text on ANQP usage. Info ID Length Information Octets: 2 2 variable Figure 9-591â€”ANQP-element format Each ANQP-element in 9.4.5 is assigned a unique 2-octet Info ID. The set of valid Info IDs are defined in Table 9-271. The 2-octet Info ID field is encoded following the conventions given in 9.2.2. Table 9-271â€”ANQP-element definitions ANQP-element ANQP-element name InfoID (subclause) Reserved 0â€“255 n/a Query List 256 9.4.5.2 Capability List 257 9.4.5.3 Venue Name 258 9.4.5.4 Emergency Call Number 259 9.4.5.5 Network Authentication Type 260 9.4.5.6 Roaming Consortium 261 9.4.5.7 IP Address Type Availability 262 9.4.5.9 NAI Realm 263 9.4.5.10 3GPP Cellular Network 264 9.4.5.11 AP Geospatial Location 265 9.4.5.12 AP Civic Location 266 9.4.5.13 AP Location Public Identifier URI/FQDN 267 9.4.5.14 Domain Name 268 9.4.5.15 Emergency Alert Identifier URI 269 9.4.5.16 TDLS Capability 270 9.4.5.18 Emergency NAI 271 9.4.5.17 Neighbor Report 272 9.4.5.19 Venue URL 277 9.4.5.20 Advice of Charge 278 9.4.5.21 Local Content 279 9.4.5.22 Network Authentication Type with Timestamp 280 9.4.5.23 1127 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-271â€”ANQP-element definitions (continued) ANQP-element ANQP-element name InfoID (subclause) Reserved 273â€“276, n/a 281â€“ 56 796 Vendor Specific 56 797 9.4.5.8 Reserved 56798â€“65 535 n/a The Length field specifies the number of octets in the Information field and is encoded following the conventions given in 9.2.2. The ANQP-elements that can be configured are shown in Table 9-271. If information is not configured for a particular ANQP-element, then a query for that element will return that element with all optional fields not present. 9.4.5.2 Query List ANQP-element The Query List ANQP-element provides a list of identifiers of ANQP-elements for which the requesting STA is querying; see 11.25.3.3.2. The format of the Query List ANQP-element is provided in Figure 9-592. Info ID Length ANQP Query IDs Octets: 2 2 2 Figure 9-592â€”Query List ANQP-element format The Info ID and Length fields are defined in 9.4.5.1. The ANQP Query IDs field contains one or more 2-octet ANQP Query ID subfields. Each ANQP Query ID subfield value is an Info ID drawn from Table 9-271. Including an Info ID in the Query List ANQP-element declares that the STA performing the ANQP request is requesting the ANQP- element corresponding to that Info ID be returned in the ANQP response. The Info IDs included in the Query List ANQP-element are ordered by monotonically increasing Info ID value. The ANQP response is defined in 11.25.3.3.1. 9.4.5.3 Capability List ANQP-element The Capability List ANQP-element provides a list of information/capabilities that has been configured on a STA. The Capability List ANQP-element is returned in response to a Query List ANQP-element containing the Info ID of the Capability List ANQP-element. The format of the Capability List ANQP-element is provided in Figure 9-593. 1128 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ANQP Vendor Specific Info ID Length Capabilities ANQP-elements Octets: 2 2 variable variable Figure 9-593â€”Capability List ANQP-element format The Info ID and Length fields are defined in 9.4.5.1. The ANQP Capabilities field contains one or more 2-octet ANQP Capability subfields. Each ANQP Capability subfield value is an Info ID drawn from Table 9-271. If included in the Capability List ANQP-element, it declares that a Query List ANQP-element including that Info ID will return the requested ANQP-element. The Info ID for Capability List ANQP-element is always included in the Capability List ANQP-element returned in a GAS Query Response. The list does not include any duplicate Info IDs, except possibly the Info ID for each Vendor Specific ANQP-element. The Info IDs returned in the Capability List ANQP-element are ordered by nondecreasing Info ID value. The Vendor Specific ANQP-elements field contains one or more variable length Vendor Specific ANQP- elements. The Vendor Specific ANQP-element is defined in 9.4.5.8. The Vendor Specific ANQP-element is structured such that the first 2 octets of the Vendor Specific ANQP-element is the Info ID whose value corresponds to the Vendor Specific ANQP-element (see Table 9-271). When a Vendor Specific ANQP-element is present in the Capability List ANQP-element, the Vendor Specific ANQP-element contains the capabilities of that vendor-specific query protocol. 9.4.5.4 Venue Name ANQP-element The Venue Name ANQP-element provides zero or more venue names associated with the BSS. The format of the Venue Name ANQP-element is shown in Figure 9-594. The Venue Name ANQP-element might be used to provide additional metadata on the BSS. For example, the information might be used to assist a user in selecting the appropriate BSS with which to associate. Zero or more Venue Name fields can be included in the same or different languages. Venue Name Info ID Length Venue Info Tuples Octets: 2 2 2 variable Figure 9-594â€”Venue Name ANQP-element format The Info ID and Length fields are defined in 9.4.5.1. The Venue Info field is a 2-octet field and is defined in 9.4.1.35. The Venue Name Tuples field contains zero or more variable length Venue Name Tuple subfields. The format of the Venue Name Tuple subfield is shown in Figure 9-595. â€” The Length field is a 1-octet field whose value is equal to 3 plus the number of octets in the Venue Name field. â€” The Language Code field is a 3-octet ISO 14962:1997 encoded string field that defines the language used in the Venue Name field. The Language Code field is a two or three character language code 1129 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications selected from ISO 639. A two character language code has 0 (â€œnullâ€ in ISO 14962:1997) appended to make it 3 octets in length. â€” The Venue Name field is a variable-length UTF-8 encoded field containing the venueâ€™s name. The maximum length of this field is 252 octets. Length Language Code Venue Name Octets: 1 3 variable Figure 9-595â€”Venue Name Tuple subfield A URL associated with the Venue Name field can be specified by the Venue URL ANQP-element defined in 9.4.5.20. 9.4.5.5 Emergency Call Number ANQP-element The Emergency Call Number ANQP-element provides a list of emergency phone numbers to an emergency responder, such as directed by a public safety answering point (PSAP), that is used in the geographic location of the STA. The format of the Emergency Call Number ANQP-element is provided in Figure 9-596. Info ID Length Emergency Call Number Duples Octets: 2 2 variable Figure 9-596â€”Emergency Call Number ANQP-element format The Info ID and Length fields are defined in 9.4.5.1. The Emergency Call Number Duples field contains zero or more variable length Emergency Call Number Duple subfields. Each Emergency Call Number Duple subfield has the structure shown in Figure 9-597. Length of Emergency Emergency Call Call Number Number Octets: 1 variable Figure 9-597â€”Emergency Call Number Duple subfield format The Length of Emergency Call Number field is a 1-octet field whose value is set to the length of the Emergency Call Number field. The Emergency Call Number field is a variable-length UTF-8 encoded field containing information, used to reach emergency services, from the network (e.g., dialed digits, emergency service URN label [B46]). 9.4.5.6 Network Authentication Type ANQP-element The Network Authentication Type ANQP-element provides a list of authentication types when ASRA is set to 1. The format of the Network Authentication Type ANQP-element is shown in Figure 9-598. 1130 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Network Info ID Length Authentication Type Tuples Octets: 2 2 variable Figure 9-598â€”Network Authentication Type ANQP-element format The Info ID and Length fields are defined in 9.4.5.1. The Network Authentication Type Tuples field contains zero or more variable length Network Authentication Type Tuple subfields. Each Network Authentication Type Tuple subfield has the structure shown in Figure 9-599. Network Authentication Redirect URL Redirect URL Type Indicator Length (optional) Octets: 1 2 variable Figure 9-599â€”Network Authentication Type Tuple subfield format The Network Authentication Type Indicator field is a 1-octet field and has one of the values shown in Table 9-272. Table 9-272â€”Network Authentication Type Indicator definitions Value Meaning 0 Acceptance of terms and conditions 1 On-line enrollment supported 2 http/https redirection 3 DNS redirection 4â€“255 Reserved Each Network Authentication Type Indicator defines additional information that can be communicated. If the Network Authentication Type Indicator is 0, the network requires the user to accept terms and conditions. The Redirect URL can be used by the non-AP STA to obtain the terms and conditions. If the Redirect URL is not present, then, the Redirect URL Length is set to 0. If the Network Authentication Type Indicator is 1, the network supports on-line enrollment. Higher layer protocols on the non-AP STA might indicate to the user that accounts might be created. When the Network Authentication Type Indicator is 1, the Redirect URL Length is set to 0 and the Redirect URL is not present. If the Network Authentication Type Indicator is 2, the network infrastructure performs http/https redirect. The ReDirect URL is used by the non-AP STA to perform additional steps required for network access. 1131 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If the Network Authentication Type Indicator is 3, the network supports DNS redirection. Higher layer software on the non-AP STA exchanges credentials with the network, the Redirect URL Length is set to 0 and the Redirect URL is not present. The Redirect URL Length field is a 2-octet field whose value is the length of the Redirect URL. The value of the Redirect URL Length field is set to 0 whenever the Redirect URL is not present. The Redirect URL field is a variable-length field that is optionally included if the Network Authentication Type Indicator is either 0 or 2. If the Network Authentication Type Indicator is other than 0 or 2, a Redirect URL is not included. The URL is formatted in accordance with IETF RFC 3986. 9.4.5.7 Roaming Consortium ANQP-element The Roaming Consortium ANQP-element provides a list of information about the Roaming Consortium and/ or SSPs whose networks are accessible via this AP. This list can be returned in response to a GAS Query using procedures in 11.25.3.3.3. The format of the Roaming Consortium ANQP-element is provided in Figure 9-600. Info ID Length OI Duples Octets: 2 2 variable Figure 9-600â€”Roaming Consortium ANQP-element format The Info ID and Length fields are defined in 9.4.5.1. OIs contained within the Roaming Consortium element (see 9.4.2.96) are also included in this ANQP- element. The value of the OI subfield(s) in this ANQP-element are equal to the values of the OI(s) in the dot11RoamingConsortiumTable. The OI Duples field contains zero or more variable length OI Duple subfields. The format of the OI Duple subfield is provided in Figure 9-601. â€” The value of the OI Length field is equal to the number of octets in the OI field. â€” The OI field is defined in 9.4.1.32. Each OI identifies a roaming consortium (group of SSPs with inter-SSP roaming agreement) or a single SSP. OI Length OI Octets: 1 variable Figure 9-601â€”OI Duple subfield format 9.4.5.8 Vendor Specific ANQP-element The Vendor Specific ANQP-element is used to query for information not defined in this standard within a single defined format, so that reserved Info IDs are not usurped for nonstandard purposes and interoperability is more easily achieved in the presence of nonstandard information. The ANQP-element is in the format shown in Figure 9-602. 1132 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Info ID Length OI Vendor Specific Content Octets: 2 2 variable variable Figure 9-602â€”Vendor Specific ANQP-element format The Info ID and Length fields are defined in 9.4.5.1. The OI field is defined in 9.4.1.32. The Vendor Specific Content field is a variable-length field whose content is defined by the entity identified in the OI field. 9.4.5.9 IP Address Type Availability ANQP-element The IP Address Type Availability ANQP-element provides STA with the information about the availability of IP address version and type that could be allocated to the STA after successful association. The format of the IP Address Type Availability ANQP-element is shown in Figure 9-603. Info ID Length IP Address Octets: 2 2 1 Figure 9-603â€”IP Address Type Availability ANQP-element The Info ID and Length fields are defined in 9.4.5.1. The format of the IP Address field shown in Figure 9-604. Bits: B0 B1 B2 B7 IPv6 Address IPv4 Address Figure 9-604â€”IP Address field format The IPv6 Address field values are shown in Table 9-273. Table 9-273â€”IPv6 Address field values Address value Meaning 0 Address type not available 1 Address type available 2 Availability of the address type not known 3 Reserved 1133 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The IPv4 Address field values are shown in Table 9-274. Table 9-274â€”IPv4 Address field values Address value Meaning 0 Address type not available 1 Public IPv4 address available 2 Port-restricted IPv4 address available 3 Single NATed private IPv4 address available 4 Double NATed private IPv4 address available 5 Port-restricted IPv4 address and single NATed IPv4 address available 6 Port-restricted IPv4 address and double NATed IPv4 address available 7 Availability of the address type is not known 8â€“63 Reserved 9.4.5.10 NAI Realm ANQP-element The NAI Realm ANQP-element provides a list of network access identifier (NAI) realms corresponding to SSPs or other entities whose networks or services are accessible via this AP; optionally included for each NAI realm is a list of one or more EAP Method subfields, which that NAI realm uses for authentication. The format of the NAI Realm ANQP-element is provided in Figure 9-605. NAI NAI Info ID Length Realm Realm Count Tuples Octets: 2 2 2 variable Figure 9-605â€”NAI Realm ANQP-element format The Info ID and Length fields are defined in 9.4.5.1. The NAI Realm Count field is a 2-octet field that specifies the number of NAI realms included in the NAI Realm ANQP-element. The NAI Realm Tuples field contains zero or more variable length NAI Realm Tuple subfields. The format of the NAI Realm Tuple subfield is shown in Figure 9-606. NAI NAI NAI EAP EAP Realm NAI Data Field Realm Realm Realm Method Method Encoding Length Count Tuples Length Octets: 2 1 1 variable 1 variable Figure 9-606â€”NAI Realm Tuple subfield format 1134 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The NAI Realm Data Field Length is a 2-octet subfield whose value is equal to 3 plus the length of the NAI Realm subfield plus the sum of the lengths of the EAP Method subfields. The NAI Realm Encoding is a 1-octet subfield whose format is shown in Figure 9-607. Bits: B0 B1 B7 NAI Reserved Realm Encoding Type Figure 9-607â€”NAI Realm Encoding subfield format The NAI Realm Encoding Type is a 1-bit subfield. It is set to 0 to indicate that the NAI Realm in the NAI Realm subfield is formatted in accordance with IETF RFC 4282. It is set to 1 to indicate it is a UTF-8 encoded character string that is not formatted in accordance with IETF RFC 4282. NOTEâ€”This encoding is to facilitate roaming consortium or other entities that use nonstandard NAI Realm formats. NAI Realm Length subfield is a 1-octet subfield whose value is the length in octets of the NAI Realm subfield. The NAI Realm subfield is one or more NAI Realms formatted as defined in the NAI Realm Encoding Type bit of the NAI Realm Encoding subfield. If there is more than one NAI Realm in this subfield, the NAI Realms are delimited by a semicolon character (i.e., â€œ;â€, which is encoded in UTF-8 format as 0x3B). All of the realms included in the NAI Realm subfield support all of the EAP methods identified by the EAP Method subfields, if present. The maximum length of this subfield is 255 octets. The EAP Method Count specifies the number of EAP methods subfields for the NAI realm. If the count is 0, there is no EAP method information provided for the NAI realm. The EAP Method Tuples field contains zero or more variable length EAP Method Tuple subfields. The format of the optional EAP Method Tuple subfield is shown in Figure 9-608. Each EAP Method subfield contains a set of Authentication Parameters associated with the EAP-Method. EAP Authentication Authentication Length Parameter Method Count Parameters Octets: 1 1 1 variable Figure 9-608â€”EAP Method Tuple subfield format The Length subfield is a 1-octet subfield whose value is equal to 2 plus the length of the Authentication Parameter subfields. The EAP method subfield is a 1-octet subfield that is set to the EAP Type value as given in IANA EAP Method Type Numbers. The Authentication Parameter Count indicates how many additional Authentication Parameter subfields are specified for the supported EAP Method. If the Authentication Parameters Count subfield is 0, there are no Authentication Parameters subfields present, meaning no additional Authentication Parameters are specified for the EAP Method. 1135 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Authentication Parameters field contains zero or more variable length Authentication Parameter subfields. The format of the Authentication Parameter subfield is shown in Figure 9-609. ID Length Authentication Parameter Value Octets: 1 1 variable Figure 9-609â€”Authentication Parameter subfield format The ID subfield is a 1-octet subfield that indicates the type of authentication information provided. The Length subfield is a 1-octet subfield whose value is set to the length of the Authentication Parameter Value subfield. The Authentication Parameter Value subfield is a variable-length subfield containing the value of the parameter indicated by the ID. The ID and its associated formats are specified in Table 9-275. Each ID indicates a different type of information. Use of multiple Authentication Parameter subfields allows all of the required authentication parameter requirements to be provided. Table 9-275â€”Authentication Parameter types Length Authentication information ID Description (octets) Reserved 0 Expanded EAP Method 1 Expanded EAP Method Subfield 7 Non-EAP Inner 2 Enum (0 - Reserved, 1 - PAP, 2 - CHAP, 1 Authentication Type 3 - MSCHAP, 4 - MSCHAPV2) Inner Authentication EAP 3 Value drawn from IANA EAP Method Type Numbers 1 Method Type Expanded Inner EAP Method 4 Expanded EAP Method Subfield 7 Credential Type 5 Enum (1 - SIM, 2 - USIM, 3 - NFC Secure Element, 4 - 1 Hardware Token, 5 - Softoken, 6 - Certificate, 7 - username/password, 8 - none (See NOTE), 9 - Reserved, 10 - Vendor Specific) Tunneled EAP Method 6 Enum (1 - SIM, 2 - USIM, 3 - NFC Secure Element, 4 - 1 Credential Type Hardware Token, 5 - Softoken, 6 - Certificate, 7 - username/password, 8 - Reserved, 9 - Anonymous, 10 - Vendor Specific) Reserved 7â€“220 Vendor Specific 221 Variable variable Reserved 222â€“255 NOTEâ€”None means server-side authentication only. If the EAP Method type is an Expanded EAP type (the EAP Method value is 254), the Authentication Parameter is used to specify additional information on the EAP method. Table 9-276 describes the 1136 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Authentication Parameter format for the Expanded EAP method; values for the Vendor ID and Vendor Type are specified in IETF RFC 3748. The Vendor ID and Vendor Type fields are expressed in big endian octet order. Table 9-276â€”Authentication Parameter format for the Expanded EAP method Length Parameters (octets) ID 1 Length 1 Vendor ID 3 Vendor Type 4 The Non-EAP Inner Authentication Type is specified as single enumerated value given in Table 9-275. This Authentication Information type is used for non-EAP Inner Authentication methods. The possible values are PAP (as specified in IETF RFC 1334), CHAP (as specified in IETF RFC 1994), MSCHAP (as specified in IETF RFC 2433), and MSCHAPv2 (as specified in IETF RFC 2759). The Inner Authentication EAP Method Type is specified as the EAP number as defined in IANA EAP Method Type Numbers. This Authentication Information type is used when the Inner Authentication method is an EAP method. If the Inner Authentication EAP Method Type is equal to 254 indicating an Expanded EAP Type, then the Expanded EAP Method Authentication Parameter is included. A Credential Type is specified as a single enumerated value as shown in Table 9-275. If the value is equal to the â€œVendor Specificâ€ value, then a Vendor-Specific Authentication Parameter is included. Vendor-Specific Authentication Parameters are specified as shown in Table 9-277. Table 9-277â€”Vendor Specific Authentication Parameters Length Parameters (octets) ID 1 Length 1 OI variable Authentication Parameter Value Vendor-specific content 9.4.5.11 3GPP Cellular Network ANQP-element The 3GPP Cellular Network ANQP-element contains cellular information such as network advertisement information e.g., network codes and country codes to assist a 3GPP non-AP STA in selecting an AP to access 3GPP networks. The format of the 3GPP Cellular Network ANQP-element is shown in Figure 9-610. 1137 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Payload Info ID Length (optional) Octets: 2 2 variable Figure 9-610â€”3GPP Cellular Network ANQP-element format The Info ID and Length fields are defined in 9.4.5.1. The Payload field is a variable-length field and is a generic container. An example of the format and content is defined in Annex H of 3GPP TS 24.302. 9.4.5.12 AP Geospatial Location ANQP-element The AP Geospatial Location ANQP-element provides the APâ€™s location in LCI format; see 9.4.2.22.10. This information is taken from dot11APLCITable. The Z and Usage Rules/Policy subelements are optionally presented in the Location Configuration Report field, when it is used in the AP Geospatial Location ANQP element. The Co-Located BSSID List subelement is present when there is at least one other BSS which is co-located with the reporting BSS. The format of the AP Geospatial Location ANQP-element is provided in Figure 9-611. Location Configuration Info ID Length Report Octets: 2 2 variable Figure 9-611â€”AP Geospatial Location ANQP-element format The Info ID and Length fields are defined in 9.4.5.1. The Location Configuration Report field is of variable length and defined in 9.4.2.22.10. The Z and Usage Rules/Policy subelements are optionally present in the Location Configuration Report field, when it is used in the AP Geospatial Location ANQP element. The Co-Located BSSID List subelement is present when there is at least one other BSS which is co-located with the reporting BSS. 9.4.5.13 AP Civic Location ANQP-element The AP Civic Location ANQP-element provides the APâ€™s location in civic format. The format of the AP Civic Location ANQP-element is provided in Figure 9-612. Info ID Length Location Civic Report Octets: 2 2 variable Figure 9-612â€”AP Civic Location ANQP-element format The Info ID and Length fields are defined in 9.4.5.1. The Location Civic Report is a variable-length field and the format is provided in 9.4.2.22.13. This information is taken from dot11APCivicLocationTable. The Co-Located BSSID List subelement is present when there is at least one other BSS which is co-located with the reporting BSS and the Co-Located BSSID List subelement is not present in the Geospatial Location ANQP-element; this subelement is not present otherwise. 1138 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.5.14 AP Location Public Identifier URI/FQDN ANQP-element The AP Location Public Identifier URI/FQDN ANQP-element provides an indirect reference to the location information for the AP. This list element can be returned in response to a GAS Query using the procedures in 11.25.3.3. The format of the AP Location Public Identifier URI/FQDN ANQP-element is provided in Figure 9-613. Zero or more Info ID Length Public Identifier URI/ FQDN Octets: 2 2 variable Figure 9-613â€”AP Location Public Identifier URI/FQDN ANQP-element format The Info ID and Length fields are defined in 9.4.5.1. The Public Identifier URI/FQDN field is a variable-length field containing zero or more Public Identifier URI/FQDN subelements, as defined in 9.4.2.22.14. 9.4.5.15 Domain Name ANQP-element The Domain Name ANQP-element provides a list of one or more domain names of the entity operating the IEEE 802.11 access network. Domain Names in this ANQP-element are taken from dot11DomainNameTable. The format of the Domain Name ANQP-element is provided in Figure 9-614. Domain Name Info ID Length Duples Octets: 2 2 variable Figure 9-614â€”Domain Name ANQP-element format The Info ID and Length fields are defined in 9.4.5.1. The Domain Name Duples field contains zero or more variable length Domain Name Duple subfields. The format of the Domain Name Duple subfield is shown in Figure 9-615. Length Domain Name Octets: 1 variable Figure 9-615â€”Domain Name Duple subfield format The Length subfield is a 1-octet subfield whose value is set to the length in octets of the Domain Name subfield. The Domain Name subfield is of variable length and contains a domain name compliant with the â€œPreferred Name Syntaxâ€ as defined in IETF RFC 1035. The maximum length of this field is 255 octets. 1139 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.5.16 Emergency Alert URI ANQP-element The Emergency Alert URI ANQP-element provides a URI for EAS message retrieval. The format of the Emergency Alert URI ANQP-element is provided in Figure 9-616. Info ID Length Emergency Alert URI Octets: 2 2 variable Figure 9-616â€”Emergency Alert URI ANQP-element format The Info ID and Length fields are defined in 9.4.5.1. The Emergency Alert URI field is a variable-length field used to indicate the URI at which an EAS message can be retrieved as described in 11.25.7. The Emergency Alert URI field is formatted in accordance with IETF RFC 3986. 9.4.5.17 Emergency NAI ANQP-element The Emergency NAI ANQP-element contains an emergency string, which is available for use by a STA as its identity to indicate emergency access request. The format of the Emergency NAI ANQP-element is provided in Figure 9-617. Info ID Length Emergency NAI Information Octets: 2 2 variable Figure 9-617â€”Emergency NAI ANQP-element format The Info ID and Length fields are defined in 9.4.5.1. The Emergency NAI Information field is a variable-length field encoded using UTF-8 and formatted in accordance with IETF RFC 4282. 9.4.5.18 TDLS Capability ANQP-element The TDLS Capability ANQP-element is used by a STA to discover the TDLS capabilities of a peer STA. The format of the TDLS Capability is provided in Figure 9-618. Info ID Length Peer Information Octets: 2 2 variable Figure 9-618â€”TDLS Capability ANQP-element format The Info ID and Length fields are defined in 9.4.5.1. The Peer Information field is a variable-length field containing information that a STA can use to establish a TDLS link and is defined as an XML schema (see R.6). An example of the peer information is described in 11.25.3.3.10. 1140 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.5.19 Neighbor Report ANQP-element The Neighbor Report ANQP-element provides zero or more neighbor reports about neighboring APs. This is of benefit to a STA in a preassociated state. The format of the Neighbor Report ANQP-element is defined in Figure 9-619. Info ID Length Neighbor Report element (optional) Octets: 2 2 variable Figure 9-619â€”Neighbor Report ANQP-element format The Info ID and Length fields are defined in 9.4.5.1. The format of the Neighbor Report element is shown in Figure 9-295 defined in 9.4.2.37. The Element ID and the Length fields of the Neighbor Report element, as shown in Figure 9-295, are not included. The Co- Located BSSID List subelement is present when there is at least one other BSS which is co-located with the reporting BSS. 9.4.5.20 Venue URL ANQP-element The Venue URL ANQP-element provides a list of one or more URLs which can be used for web page advertising services or providing information, particular to a venueâ€™s BSS, to a STA. The format of the Venue URL ANQP-element is defined in Figure 9-620. Info ID Length Venue URL Duples Octets: 2 2 variable Figure 9-620â€”Venue URL ANQP-element format The Info ID and Length fields are defined in 9.4.5.1. The Venue URL Duples field contains one or more Venue URL Duple fields as shown in Figure 9-621. Venue Length Number Venue URL Octets: 1 1 variable Figure 9-621â€”Venue URL Duple field The Length field is a 1-octet field whose value is set to 1 plus the number of octets in the Venue URL field. The Venue Number field is a 1-octet field whose value corresponds to the implicit returned order value of the corresponding Venue Name Duple returned in a Venue Name ANQP-element, as defined in 9.4.5.4. If no Venue Name Tuple subfield was returned in the Venue Name ANQP-element then this value is 0. The Venue URL field is a variable-length field that indicates the URL at which information relevant to the corresponding Venue Name Tuple subfield, indicated by the Venue Number, might be retrieved. This is further described in 11.25.3.3.11. If no Venue URL is provided this field is left empty. The Venue URL field is formatted in accordance with IETF RFC 3986. 1141 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.4.5.21 Advice of Charge ANQP-element The Advice of Charge ANQP-element provides a list of one or more financial advice of charges related to access to a BSS. The format of the Advice of Charge ANQP-element is defined in Figure 9-622. Info ID Length Advice of Charge Duples Octets: 2 2 variable Figure 9-622â€”Advice of Charge ANQP-element format The Info ID and Length fields are defined in 9.4.5.1. The Advice of Charge Duples field contains one or more Advice of Charge Duple fields as shown in Figure 9-623. NAI NAI NAI Plan Advice of Length Charge Type Realm Realm Realm Information Encoding Length Tuples Octets: 2 1 1 1 variable variable Figure 9-623â€”Advice of Charge Duple field The Length field is a 2-octet field whose value is set to 3 plus the number of octets in the NAI Realm and Plan Information Tuples fields. The Advice of Charge Type field is a 1-octet field with the values defined in Table 9-278. Table 9-278â€”Advice of Charge Type field values Advice of Charge Type Description Value 0 Time-based 1 Data-volume-based 2 Time-and-data-volume-based 3 Unlimited 4â€“255 Reserved The NAI Realm Encoding, NAI Realm Length and NAI Realm fields are defined in 9.4.5.10. The format of the Plan Information Tuples field is defined in Figure 9-624. Length Language Currency Code Plan Information Octets: 2 3 3 variable Figure 9-624â€”Plan Information Tuple field 1142 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Length field is a 2-octet field whose value is set to the number of octets in the Language, Currency Code, and Plan Information fields. The Language Code field is a 3-octet ISO 14962:1997 encoded string field that defines the language used in the Cost Information field. The Language Code field is a two or three character language code selected from ISO 639. A two character language code has 0 (â€œnullâ€ in ISO 14962:1997) appended to make it 3 octets in length. The Currency Code field is a 3-octet string (e.g., â€œUSDâ€) representing an ISO 4217 currency numeric code. The Plan Information field is a variable length UTF-8 formatted field that carries an XML description of an Advice of Charge plan. The schema and semantics of this description are outside the scope of this standard. 9.4.5.22 Local Content ANQP-element The Local Content ANQP-element provides a list of one or more URLs which can be used to display local content related to the BSS. The format of the Local Content ANQP-element is defined in Figure 9-625. Info ID Length Local Content Duples Octets: 2 2 variable Figure 9-625â€”Local Content ANQP-element format The Info ID and Length fields are defined in 9.4.5.1. The Local Content Duples field contains one or more Local Content Duple fields as shown in Figure 9-626. Length State Local Content URL Label Length Label (optional) (optional) Octets: 1 1 variable 0 or 1 variable Figure 9-626â€”Local Content Duple field The Length field is a 1-octet field whose value is set to 1 plus the number of octets in the Local Content URL, Label Length and Label fields. The State field is a 1-octet field whose value is defined in Table 9-279. Table 9-279â€”Local Content State values State Name 0 Not authenticated 1 Authenticated 2 Failure during authentication 3 Incorrect credentials 4 Credentials expired 5â€“255 Reserved 1143 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Local Content URL field is a variable-length field containing a URL that is used for directing the device to local content. The Local Content URL field is formatted in accordance with IETF RFC 3986. The Label Length field is a 1 octet field that contains the value of the length of the Label field in octets. If the Label is not used, this field is also not used. The Label field is a variable-length field containing a description of the URL. It provides the type and potential usage of the URL. This is a UTF-8 formatted string. 9.4.5.23 Network Authentication Type with Timestamp ANQP-element The Network Authentication Type with Timestamp ANQP-element provides similar information to that of the Network Authentication Type as defined in 9.4.5.6. In addition, a timestamp field is optionally provided to indicate to the requesting STA a timestamp corresponding to the time at which the received terms and conditions were most recently modified. With this timestamp, the requesting STA can determine if previously received information is stale. The format of the Network Authentication Type with Time ANQP-element is shown in Figure 9-627. Info ID Length Network Authentication Timestamp Tuples Octets: 2 2 variable Figure 9-627â€”Network Authentication Type with Timestamp ANQP-element format The Info ID and Length fields are defined in 9.4.5.1. The Network Authentication Timestamp Tuples field contains zero or more variable length Network Authentication Timestamp Tuple subfields. Each Network Authentication Timestamp Tuple subfield has the structure shown in Figure 9-628. Network Authentication Redirect URL Redirect URL Time Value Type Indicator Length (optional) (optional) Octets: 1 1 variable 0 or 10 Figure 9-628â€”Network Authentication Timestamp Tuple subfield format The Network Authentication Type Indicator field is defined in 9.4.5.6 The Redirect URL Length field and the Redirect URL field are defined in 9.4.5.6. The Time Value field is defined in Table 9-170 using the Timing Capability equal to 2 encoding. This field is used by the responding STA to set a time of the ANQP response. 9.4.6 Registered location query protocol (RLQP) elements 9.4.6.1 General RLQP-elements are defined to have a common format consisting of a 2-octet Info ID field, a 2-octet Length field, and a variable-length RLQP-element-specific Information field. Each element is assigned a unique Info ID as defined in this standard. The RLQP-element format is shown in Figure 9-629. 1144 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Info ID Length Information Octets: 2 2 variable Figure 9-629â€”RLQP-element format Each RLQP-element in 9.4.6 is assigned a unique 2-octet Info ID. The set of valid Info IDs is defined in Table 9-629. The 2-octet Info ID field is encoded following the conventions given in 9.2.2. The Length field is a 2-octet field that indicates the number of octets in the Information field and is encoded following the conventions given in 9.2.2. The RLQP-elements are shown in Table 9-280. Info ID 56 797 stands for Vendor Specific information. Table 9-280â€”RLQP-element definitions RLQP-element name Info ID RLQP-element (subclause) Reserved 0â€“272 N/A Channel Availability Query 273 9.4.6.2 Channel Schedule Management 274 9.4.6.3 Network Channel Control 275 9.4.6.4 Reserved 276â€“56 796 N/A Vendor Specific 56 797 9.4.6.5 Reserved 56 798â€“65 535 N/A 9.4.6.2 Channel Availability Query RLQP-element The Channel Availability Query element is used to exchange the requests and responses for the channel availability query process using the GAS protocol. The Channel Availability Query RLQP-element is included in a GAS Query Request or returned in a response to a GAS Query Request. The element is in the format shown in Figure 9-630. Info Length Requester Responder Reason Channel Device Device Device WSM ID STA STA Result Query Class Identification Location Information Address Address Code Info Information Information Octets: 2 2 6 6 1 1 variable variable variable variable Figure 9-630â€”Channel Availability Query RLQP-element format The Info ID and Length fields are defined in 9.4.6.1. The RequesterSTAAddress field is the MAC address of the requesting STA that initiates the channel query process. The length of the RequesterSTAAddress field is 6 octets. The ResponderSTAAddress field is the MAC address of the responding STA that responds to the channel query requesting STA. The length of the ResponderSTAAddress field is 6 octets. 1145 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Reason Result Code field is used to indicate the reason that a channel availability query was generated. It also indicates the result of the query as successful or not and the reason when the query is not successful. The length of the Reason Result Code field is 1 octet. The Reason Result Code field values that have been allocated are shown in Table 9-281. Table 9-281â€”Reason Result Code field values Reason Result Name Description Code field value 0 Reserved. 1 Channel availability list requested. 2 SUCCESS Success with the available channel list result for a Device Location Information field. 3 SUCCESS_MULTIPLE Success with an available channel list result for a bounded geographic area defined by multiple Device Location Information fields. 4 REFUSED Request declined. 5 DEVICE_VERIFICATION_ Request not successful because of device identification FAILURE verification failure. NOTEâ€”Failure of providing an authorized identification of the corresponding regulatory organization can cause the responding STA to reject the query and return such a Reason Result Code. 6 Continuation frame This frame continues the fields from the previous CAQ frame. 7â€“255 Reserved. The Channel Query Info field is used to indicate the type of Channel Query request and associated parameters. The format of the Channel Query Info field is shown in Figure 9-631. B0 B1 B3 B4 B7 Device Number of Reserved Identification Device Location Information Information Present Subfields Bits: 1 3 4 Figure 9-631â€”Channel Query Info field format The Device Identification Information Present subfield value is set to 1 to indicate that the Device Identification Information field is present in the Channel Availability Query element; otherwise it is set to 0 to indicate that the Device Identification Information field is not provided. The Number of Device Location Information Subfields subfield indicates the number of device location information subfields presented in the Channel Availability Query element. When no device location is present, the Number of Device Location Information Subfields subfield is set to 0. 1146 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Device Class field is used to indicate the characteristics of STA requesting the channel availability query. The format of the Device Class field is specified in 9.4.4.2.1. The Device Class field is present only when the Reason Result Code field value is 1. The Device Identification Information field is used to indicate the identification of the STA requesting the channel availability query. The format of the Device Identification Information field is specified in 9.4.4.2.2. The Device Location Information field is used to provide the location of the STA requesting the channel availability query, which is provided in the format specified in 9.4.4.2.3. The WSM Information field is defined in the White Space Map element (see 9.4.2.170). The WSM Information field is present only when the Reason Result Code field value is 2 or 3, as the successful result of the query. 9.4.6.3 Channel Schedule Management RLQP-element The Channel Schedule Management element is used by an GDD enabling STA to query the RLSS or another GDD enabling STA for channel schedule information. The element is in the format shown in Figure 9-632. Info ID Length Requester Responder Reason Channel Device Channel STA Address STA Address Result Code Schedule Identification Schedule Management Information Descriptor Mode Octets: 2 2 6 6 1 1 variable variable Figure 9-632â€”Channel Schedule Management RLQP-element format The Info ID and Length fields are defined in 9.4.6.1. The Requester STA Address field is the MAC address of the requesting STA that initiates the channel schedule management process. The Responder STA Address field is the MAC address of the STA that responds to the STA that requested channel schedule management. The remaining fields are as defined in the Channel Schedule Management element (see 9.6.8.26). 9.4.6.4 Network Channel Control RLQP-element The Network Channel Control element is used to request network channel control and respond to network channel requests using the GAS protocol. The element is in the format shown in Figure 9-633. a Network Channel Control triplet Info Length Requester Responder Reason Number of Operating Channel Maximum ID STA STA Result Network Class Number Transmit Address Address Code Channel Power Control Triplets Octets: 2 2 6 6 1 1 1 1 1 Figure 9-633â€”Network Channel Control RLQP-element format The Info ID and Length fields are defined in 9.4.6.1. 1147 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The RequesterSTAAddress field is the MAC address of the requesting STA that initiates the network channel control process. The ResponderSTAAddress field is the MAC address of the STA that responds to the STA that requested network channel control. The Reason Result Code field is used to indicate the reason that a Network Channel Control frame was generated. The length of the Reason Result Code field is 1 octet. The encoding of the Reason Result Code field is shown in Table 9-282. Table 9-282â€”Reason Result Code field values Reason Result Name Description Code field value 0 REQUEST Network channel request. 1 SUCCESS Success. 2 REFUSED Request declined. 3 TOO_MANY_SIMULTA Network channel request denied because the GDD enabling NEOUS_REQUESTS STA is unable to handle additional GDD dependent STAs. 4 Continuation frame This frame continues the fields from the previous NCC frame. 5â€“255 Reserved. The Number of Network Channel Control Triplets field indicates the number of triplets of Operating Class, Channel Number, and Transmit Power Constraint fields. The Operating Class field indicates the channel set for which the network channel control request applies. The Operating Class field and Channel Number field are used together to specify the channel frequency and channel bandwidth for which the network channel control applies. Values for the Operating Class field are shown in E.1. In a request, the Channel Number field of a Network Channel Control frame indicates the channel that the requesting STA intends to operate on. In a response, the Channel Number field in the Network Channel Control frame indicates the channels that the responding STA permits the requesting STA to operate on. The Channel Number is defined within an Operating Class as shown in E.1. The Maximum Transmit Power field gives the intended maximum transmit power in dBm for operation in the request frame and indicates the maximum allowable transmit power in dBm for operation in the response frame. The field is coded as a signed integer in units of 0.5 dBm. The field is set to â€“128 when a requesting STA requests a responding STA to provide a network channel control response without specifying in the request the intended maximum transmit power. 9.4.6.5 Vendor Specific RLQP-element The Vendor Specific RLQP-element is used to carry information not defined in this standard within a single defined format, so that reserved Info IDs are not usurped for nonstandard purposes and so that interoperability is more easily achieved in the presence of nonstandard information. The RLQP-element is in the format shown in Figure 9-634. 1148 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Info ID Length Organization Iden- Vendor-specific tifier content Octets: 2 2 j variable Figure 9-634â€”Vendor Specific RLQP-element format The Info ID and Length fields are defined in 9.4.6.1. The Organization Identifier field identifies (see 9.4.1.32) the entity that has defined the content of the particular Vendor Specific RLQP-element. See 9.4.1.32 for the definition of j. 9.5 Fields used in Management and Extension frame bodies and Control frames 9.5.1 Sector Sweep field The format of the sector sweep (SSW) field is shown in Figure 9-635. B0 B1 B9 B10 B15 B16 B17 B18 B23 Direction CDOWN Sector ID DMG Antenna ID RXSS Length Bits: 1 9 6 2 6 Figure 9-635â€”SSW field format The Direction subfield is set to 0 to indicate that the frame is transmitted by the beamforming initiator and set to 1 to indicate that the frame is transmitted by the beamforming responder. The CDOWN subfield is a down-counter indicating the number of remaining DMG Beacon frame transmissions to the end of the TXSS, or the number of remaining SSW frame transmissions to the end of the TXSS/RXSS. This subfield is set to 0 in the last frame DMG Beacon and SSW frame transmission. Possible values range from 0 to 511. The Sector ID subfield is set to indicate the sector number through which the frame containing this SSW field is transmitted. The DMG Antenna ID subfield indicates the DMG antenna the transmitter is currently using for this transmission. The RXSS Length subfield is valid only when transmitted in a CBAP and is reserved otherwise. The RXSS Length subfield specifies the length of a receive sector sweep as required by the transmitting STA and is defined in units of an SSW frame. The length of the sector sweep is given by RXSS Length + 1 2 . 9.5.2 Dynamic Allocation Info field The format of the Dynamic Allocation Info field is shown in Figure 9-636. The TID subfield identifies the TC or TS for the allocation request or grant. NOTEâ€”Unlike pseudo-static allocations, nonpseudo-static allocations are not labeled with an allocation ID, and are associated to a TID. 1149 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B0 B3 B4 B6 B7 B14 B15 B22 B23 B38 B39 Allocation TID AllocationType Source AID Destination AID Duration Reserved Bits: 4 3 8 8 16 1 Figure 9-636â€”Dynamic Allocation Info field format The AllocationType subfield is defined in 9.4.2.132. The Source AID subfield identifies the STA that is the source of the allocation. The Destination AID subfield identifies the STA that is the destination of the allocation. When the Dynamic Allocation Info field is transmitted within an SPR frame, the Allocation Duration subfield contains the requested duration in microseconds. When the Dynamic Allocation Info subfield is transmitted within a Grant frame by an AP or PCP in an ATI or GP, the Allocation Duration subfield contains the granted duration of the SP or CBAP allocation in microseconds (see 10.36.3, 10.36.7, 10.36.8, and 10.36.9). Possible values range from 0 to 32 767 for an SP allocation and a CBAP allocation. A value of 0 in the Allocation Duration subfield transmitted within a Grant frame means that the STA can transmit one PPDU followed by any relevant acknowledgment plus one RTS/DMG CTS handshake. When the Dynamic Allocation Info subfield is transmitted within a Grant frame in a CBAP, the value of the Allocation Duration field indicates the purpose of the Grant frame transmission. Two purposes are possible: a) Beyond current TXOP: in this case, the Allocation Duration subfield values range from 0 to 32 767. The value of the Allocation Duration field plus the Duration field of the Grant frame indicates the time offset from the PHY-TXEND.indication primitive of the Grant frame when the STA transmitting the Grant frame will attempt to initiate access for communication with the STA indicated by the RA field of the Grant frame. b) Within current TXOP: in this case, the Allocation Duration subfield is set to 32 768. When the Dynamic Allocation Info subfield is transmitted within a Grant frame with RA set to broadcast address by a source or destination STA of an SP, the Allocation Duration subfield values range from 0 to 32 767. When the Dynamic Allocation Info subfield is transmitted within a Grant frame with RA set to unicast address by a source STA of an SP, the Allocation Duration subfield is set to 32 768. 9.5.3 Sector Sweep Feedback field When the SSW Feedback field is transmitted as part of an ISS, the format of the field is as shown in Figure 9-637. Otherwise, the format of the SSW Feedback field is as shown in Figure 9-638. B0 B8 B9 B10 B11 B15 B16 B17 B23 Total Sectors in Number of RX Poll ISS DMG Antennas Reserved Required Reserved Bits: 9 2 5 1 7 Figure 9-637â€”SSW Feedback field format when transmitted as part of an ISS 1150 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B0 B5 B6 B7 B8 B15 B16 B17 B23 DMG Antenna Sector Select Select SNR Report Poll Required Reserved Bits: 6 2 8 1 7 Figure 9-638â€”SSW Feedback field format when not transmitted as part of an ISS The Total Sectors in ISS subfield indicates the total number of sectors that the initiator uses in the ISS, including any repetition performed as part of multi-antenna beamforming. Possible values range from 0 to 511, representing 1 to 512 sectors. The Number of RX DMG Antennas subfield indicates the number of receive DMG antennas the initiator uses during the following RSS. The number of receive DMG antennas used is equal to the value of this subfield plus 1. The Sector Select subfield contains the value of the Sector ID subfield of the SSW field within the frame that was received with best quality in the immediately preceding sector sweep. The determination of which packet was received with best quality is implementation dependent. Possible values of this subfield range from 0 to 63. The DMG Antenna Select subfield indicates the value of the DMG Antenna ID subfield of the SSW field within the frame that was received with best quality in the immediately preceding sector sweep. The determination of which frame was received with best quality is implementation dependent. The SNR Report subfield is set to the value of the SNR from the frame that was received with best quality during the immediately preceding sector sweep, and which is indicated in the Sector Select field. This subfield is encoded as 8-bit 2s complement value of 4Ã—(SNR-19), where SNR is measured in dB. This covers from â€“13 dB to 50.75 dB in 0.25 dB steps. The Poll Required subfield is set to 1 by a non-AP and non-PCP STA to indicate that it requires the AP or PCP to initiate communication with the non-AP and non-PCP. This subfield is set to 0 to indicate that the non-AP and non-PCP has no preference about whether the AP or PCP initiates the communication. This subfield is reserved when transmitted by an AP or PCP. 9.5.4 BRP Request field The BRP Request field is defined in Figure 9-639. B0 B4 B5 B6 B7 B8 B9 B10 B11 B16 B17 B24 B25 B26 B27 B31 TX- Chan- TX L-RX TRN- MID- BC- MID- BC- FBCK- TX Other_AID Antenna Reserved REQ REQ Grant Grant Sector ID REQ CAP ID Bits: 5 1 1 1 1 1 1 6 8 2 5 Figure 9-639â€”BRP Request field format If the MID-REQ subfield is set to 0, the L-RX subfield indicates the compressed number of TRN-R subfields requested by the transmitting STA as part of beam refinement. To obtain the number of TRN-R subfields, the value of the L-RX subfield is multiplied by 4. Possible values range from 0 to 16, corresponding to 0 to 64 TRN-R fields. Other values are reserved. If the subfield is set to 0, the transmitting STA does not need receive training as part of beam refinement. If the MID-REQ subfield is set to 1, the 1151 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications L-RX subfield indicates the compressed number of AWV settings that the STA uses during the MID phase. To obtain the number of AWVs that is used, the value of the L-RX subfield is multiplied by 4. The TX-TRN-REQ subfield is set to 1 to indicate that the STA needs transmit training as part of beam refinement. Otherwise, it is set to 0. A STA sets the MID-REQ subfield to 1 in SSW-Feedback or BRP frames to indicate a request for an I-MID subphase or R-MID subphase; otherwise, the STA sets the subfield to 0 to indicate it is not requesting an I- MID subphase or R-MID subphase. In case an R-MID subphase is requested, the STA can include information on the TX sector IDs to be used by the STA receiving this request. The STA receiving this request sets the MID-grant subfield in SSW-Ack or BRP frames to 1 to grant this request or otherwise sets it to 0. A STA sets the BC-REQ subfield to 1 in SSW-Feedback or BRP frames to indicate a request for an I/R-BC subphase; otherwise, the STA sets the subfield to 0 to indicate it is not requesting an I/R-BC subphase. In case an R-BC subphase is requested, the STA can include information on the TX sector IDs to be used by the STA receiving this request. The STA receiving this request sets the BC-grant subfield in SSW-Ack or BRP frames to 1 to grant this request; otherwise, the STA sets it to 0 to reject the request. The Chan-FBCK-CAP subfield is set to 1 to indicate the STA is capable to return channel measurement during beam refinement. The Chan-FBCK-CAP subfield is set to 0 to indicate the STA is able to return only BS-FBCK during beam refinement. NOTEâ€”Regardless of the value of the Chan-FBCK-CAP subfield, 10.38.6.4 requires a DMG STA to return the SNR values from the last TXSS if it receives a BRP frame with the TXSS-FBCK-REQ field and the SNR Requested subfield within the FBCK-REQ field both set to 1. The TX sector ID subfield indicates the sector ID that is used when transmitting the packet. If the packet is transmitted using a pattern that is not a sector that has been used in the sector sweep, the value of this subfield is set to 0x63. The Other_AID subfield is set to the AID of an additional STA referenced in the BRP procedure as described in 10.38.6.4.4 and 20.10.2.2.6. Otherwise, if the additional STA is not used, this subfield is set to 0. The TX Antenna ID subfield indicates the DMG antenna ID that is used when transmitting the packet. 9.5.5 Beamforming Control field The Beamforming Control field is formatted as shown in Figure 9-640 when both the IsInitiatorTXSS and IsResponderTXSS subfields are equal to 1, and the Beamforming Control field is transmitted in either a Grant or Grant Ack frames. In all other cases, the Beamforming Control field is formatted as shown in Figure 9-641. B0 B1 B2 B3 B9 B10 B11 B12 B15 Number of Beamforming IsInitiatorTXSS IsResponderTXSS Total Number RX DMG Reserved Training of Sectors Antennas Bit: 1 1 1 7 2 4 Figure 9-640â€”BF Control field format when both IsInitiatorTXSS and IsResponderTXSS subfields are equal to 1 and the BF Control field is transmitted in Grant or Grant Ack frames 1152 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B0 B1 B2 B3 B8 B9 B10 B15 Beamforming RXSS Training IsInitiatorTXSS IsResponderTXSS Length RXSSTxRate Reserved Bit: 1 1 1 6 1 6 Figure 9-641â€”BF Control field format in all other cases The Beamforming Training subfield is set to 1 to indicate that the source DMG STA intends to initiate beamforming training with the destination DMG STA at the start of the allocation and is set to 0 otherwise. If the Beamforming Training subfield is set to 0, all other subfields of the Beamforming Control field are reserved. The IsInitiatorTXSS subfield is set to 1 to indicate that the source DMG STA starts the beamforming training with an initiator TXSS. This subfield is set to 0 to indicate that the source DMG STA starts the BF training with an initiator RXSS. The IsResponderTXSS subfield is set to 1 to indicate that the destination DMG STA starts the RSS with a responder TXSS. This subfield is set to 0 to indicate that the destination DMG STA is to initiate the RSS with a responder RXSS. When the Beamforming Control field is transmitted within an Extended Schedule element, either the IsInitiatorTXSS subfield or the IsResponderTXSS subfield is set to 0, but not both. The RXSS Length subfield is valid only if at least one of IsInitiatorTXSS subfield or IsResponderTXSS subfield is equal to 0 and is reserved otherwise. The value represented by the RXSS Length subfield specifies the total number of receive sectors combined over all receive DMG antennas of the STA, including any LBIFS as necessary for DMG antenna switching. The value represented by this subfield is in the range 2 to 128 and is given by (RXSS Length+1)Ã—2. The RXSSTxRate subfield is valid only if the RXSS Length subfield is valid and the value of the RXSS Length subfield is greater than 0. Otherwise, the RXSSTxRate subfield is reserved. The RXSSTxRate subfield is set to 0 to indicate that all frames transmitted as part of the RXSS use the DMG Control modulation class (10.7.7.1). The RXSSTxRate subfield is set to 1 to indicate that only the first frame transmitted as part of the RXSS use the DMG Control modulation class and the remaining frames use MCS 1 of the DMG SC modulation class. If both the IsInitiatorTXSS and IsResponderTXSS subfields are set to 0 and the BF Control field is sent within a Grant frame, the RXSSTxRate subfield refers to the RSS only. If both the IsInitiatorTXSS and IsResponderTXSS subfields are set to 0 and the BF Control field is sent within a Grant Ack frame, the RXSSTxRate subfield refers to the ISS only. When the BF Control field is transmitted in a Grant frame, the Total Number of Sectors subfield indicates the total number of sectors the initiator uses during the ISS, including any LBIFS required for DMG antenna switching (see 10.38). When the BF Control field is transmitted in a Grant Ack frame, the Total Number of Sectors subfield indicates the total number of sectors the responder uses during the RSS. In both cases, the total number of sectors used is equal to the value of this field plus 1. When the BF Control field is transmitted in a Grant frame, the Number of RX DMG Antennas subfield indicates the number of receive DMG antennas the initiator uses during the RSS. When the BF Control field is transmitted in a Grant Ack frame, the Number of RX DMG Antennas subfield indicates the number of receive DMG antennas the responder uses during the ISS. In both cases, the number of receive DMG antennas used is equal to the value of this subfield plus 1. 1153 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications When the BF Control field is transmitted in a Grant Ack frame in response to a Grant frame with the Beamforming Training field equal to 0, the following fields are reserved: IsInitiatorTXSS, IsResponderTXSS, Total Number of Sectors, and Number of RX DMG Antennas. 9.5.6 Beamformed Link Maintenance field The Beamformed Link Maintenance field is shown in Figure 9-642 and provides a DMG STA with the value of dot11BeamLinkMaintenanceTime. B0 B1 B6 B7 BeamLink Maintenance Unit Index BeamLink Maintenance Value BeamLink isMaster Bits: 1 6 1 Figure 9-642â€”Beamformed Link Maintenance field format The encoding of the BeamLink Maintenance Unit Index subfield is specified in Table 9-283. Table 9-283â€”Encoding of BeamLink Maintenance Unit Index BeamLink Maintenance Unit Index BeamLink Maintenance Unit (Âµs) 0 32 1 2000 If the content of the BeamLink Maintenance Value subfield is greater than 0, it is used to calculate dot11BeamLinkMaintenanceTime as follows: dot11BeamLinkMaintenanceTime = BLMU Ã— BLMV where BLMU is the value of the BeamLink Maintenance Unit corresponding to the value of the BeamLink Maintenance Unit Index subfield (see Table 9-283) BLMV is the value of the BeamLink Maintenance Value subfield Otherwise, if the value of the BeamLink Maintenance Value subfield is 0, the dot11BeamLinkMaintenanceTime is left undefined. An undefined value of the dot11BeamLinkMaintenanceTime indicates that the STA does not participate in beamformed link maintenance. The BeamLink isMaster subfield is set to 1 to indicate that the STA is the master of the data transfer and set to 0 if the STA is a slave of the data transfer. The STAs use the BeamLink isMaster subfield to negotiate the dot11BeamLinkMaintenanceTime as specified in Table 9-284. NOTEâ€”In Table 9-284, STA-A and STA-B refer to any of the STAs performing the Beamformed Link Maintenance negotiation procedure in no particular order. 1154 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-284â€”The Beamformed Link Maintenance negotiation BeamLink BeamLink dot11BeamLinkMaintenanceTime isMaster isMaster (STA-A) vs. Result subfield subfield dot11BeamLinkMaintenanceTime (STA-A) (STA-B) (STA-B) 0 0 â‰¥ dot11BeamLinkMaintenanceTime (STA-A) 1 0 >, <, = dot11BeamLinkMaintenanceTime (STA-A) 1 1 = dot11BeamLinkMaintenanceTime (STA-A) 0 or 1 0 or 1 If either Undefined dot11BeamLinkMaintenanceTime (STA-A) or dot11BeamLinkMaintenanceTime (STA-B) is undefined 9.6 Action frame format details 9.6.1 Introduction Subclause 9.6 describes the Action field formats allowed in each of the action categories defined in Table 9- 47 in 9.4.1.11. 9.6.2 Spectrum management Action frames 9.6.2.1 General Five Action frame formats are defined for spectrum management. A Spectrum Management Action field, in the octet field immediately after the Category field, differentiates the five formats. The Spectrum Management Action field values associated with each frame format are defined in Table 9-285. Table 9-285â€”Spectrum Management Action field values Spectrum Management Description Action field value 0 Measurement Request 1 Measurement Report 2 TPC Request 3 TPC Report 4 Channel Switch Announcement 5â€“255 Reserved 1155 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.6.2.2 Measurement Request frame format The Measurement Request frame uses the Action frame body format and is transmitted to request another STA to measure one or more channels. The format of the Measurement Request Action field is shown in Figure 9-643. Spectrum Measurement Category Management Dialog Token Action Request Elements Octets: 1 1 1 variable Figure 9-643â€”Measurement Request frame Action field format The Category field is defined in 9.4.1.11. The Spectrum Management Action field is defined in 9.6.2.1. The Dialog Token field is set to a nonzero value chosen by the STA sending the measurement request to identify the request/report transaction. The Measurement Request Elements field contains one or more of the Measurement Request elements described in 9.4.2.21. The number and length of the Measurement Request elements in a Measurement Request frame are limited by the maximum allowed MMPDU size. 9.6.2.3 Measurement Report frame format The Measurement Report frame uses the Action frame body format and is transmitted in response to a Measurement Request frame or transmitted autonomously providing measurement information. The format of the Measurement Report Action field is shown in Figure 9-644. Spectrum Measurement Category Management Dialog Token Action Report Elements Octets: 1 1 1 variable Figure 9-644â€”Measurement Report frame Action field format The Category field is defined in 9.4.1.11. The Spectrum Management Action field is defined in 9.6.2.1. The Dialog Token field is set to the same value as the Dialog Token field of the corresponding Measurement Request frame. If the Measurement Report frame is not being transmitted in response to a Measurement Request frame, then the dialog token is set to 0. The Measurement Report Elements field contains one or more of the Measurement Report elements described in 9.4.2.22. The number and length of the Measurement Report elements in a Measurement Report frame are limited by the maximum allowed MMPDU size. 9.6.2.4 TPC Request frame format The TPC Request frame uses the Action frame body format and is transmitted requesting another STA for transmit power and link margin information. The format of the TPC Request Action field is shown in Figure 9-645. 1156 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Spectrum Category Management Dialog Token TPC Request element Action Octets: 1 1 1 2 Figure 9-645â€”TPC Request frame Action field format The Category field is defined in 9.4.1.11. The Spectrum Management Action field is defined in 9.6.2.1. The Dialog Token field is set to a nonzero value chosen by the STA sending the request to identify the transaction. The TPC Request element is set as described in 9.4.2.16. 9.6.2.5 TPC Report frame format The TPC Report frame uses the Action frame body format and is transmitted in response to a TPC Request frame. The format of the TPC Report Action field is shown in Figure 9-646. Spectrum TPC Report Category Management Dialog Token Action element Octets: 1 1 1 4 Figure 9-646â€”TPC Report frame Action field format The Category field is defined in 9.4.1.11. The Spectrum Management Action field is defined in 9.6.2.1. The Dialog Token field is set to the value of the Dialog Token field in the corresponding TPC Request frame. The TPC Report element is set as described 9.4.2.17. 9.6.2.6 Channel Switch Announcement frame format The Channel Switch Announcement frame uses the Action frame body format and is transmitted by an AP, IBSS STA, or mesh STA to advertise a channel switch. The format of the Channel Switch Announcement Action field is shown in Figure 9-647. Optional Zero or more Mesh Channel Wide New Transmit Spectrum Channel Switch Secondary Category Management Announcement Channel Switch Bandwidth Power Parameters Channel Switch Envelope Action element Offset element element element element Octets: 1 1 5 0 or 3 0 or 8 0 or 5 variable Figure 9-647â€”Channel Switch Announcement frame Action field format 1157 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Category field is defined in 9.4.1.11. The Spectrum Management Action field is defined in 9.6.2.1. The Channel Switch Announcement element is set as described 9.4.2.19. The Secondary Channel Offset element is defined in 9.4.2.20. This element is present when switching to a 40 MHz or wider channel. It can be present when switching to a 20 MHz channel (in which case the Secondary Channel Offset field is set to SCN); see 11.40.4. The Mesh Channel Switch Parameters element is defined in 9.4.2.103. This element is present when a mesh STA performs MBSS channel switching. Otherwise, the Mesh Channel Switch Parameters element is not present. The Wide Bandwidth Channel Switch element is defined in 9.4.2.161. This element is present when switching to a channel width wider than 40 MHz. Each New Transmit Power Envelope element that is present is defined to have the same format as the Transmit Power Envelope element (see 9.4.2.162) and includes a distinct value of the Local Maximum Transmit Power Unit Interpretation subfield. If present, the New Transmit Power Envelope element indicates the local maximum transmit powers for the BSS for the indicated bandwidths with an indicated unit interpretation after channel switching (see 11.40.1). 9.6.3 QoS Action frame details 9.6.3.1 General Several Action frame formats are defined for QoS purposes. These frames are identified by the single octet QoS Action field, which follows immediately after the Category field. The values of the QoS Action field are defined in Table 9-286. Table 9-286â€”QoS Action field values QoS Action field Meaning value 0 ADDTS Request 1 ADDTS Response 2 DELTS 3 Schedule 4 QoS Map Configure 5 ADDTS Reserve Request 6 ADDTS Reserve Response 7â€“255 Reserved Two variants are defined for the ADDTS frames: a Basic ADDTS frame variant and a DMG ADDTS frame variant. These variants use different TSPEC formats. The variant of the frame is indicated by the Element ID in the fourth field of the ADDTS Request frame Action field format (Table 9-303) and sixth field of the 1158 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ADDTS Response frame Action field format (Table 9-304). The Element ID is the first octet of each of these fields. The encoding of the ADDTS frame variants is shown in Table 9-287 and Table 9-288. Table 9-287â€”Encoding of the ADDTS Request frame variant Element ID of fourth field of ADDTS Request frame ADDTS Request frame variant 13 (TSPEC) Basic ADDTS Request frame 146 (DMG TSPEC) DMG ADDTS Request frame Table 9-288â€”Encoding of the ADDTS Response frame variant Element ID of sixth field of ADDTS Response frame ADDTS Response frame variant 13 (TSPEC) Basic ADDTS Response frame 146 (DMG TSPEC) DMG ADDTS Response frame 9.6.3.2 Basic and DMG ADDTS Request frame format 9.6.3.2.1 Basic ADDTS Request frame variant The ADDTS frames are used to carry TSPEC and optionally TCLAS elements to set up and maintain TSs using the procedures defined in 11.4. The Action field of the ADDTS Request frame contains the information shown in Table 9-289. Table 9-289â€”Basic ADDTS Request frame variant Action field format Order Information Notes 1 Category 2 QoS Action 3 Dialog token 4 TSPEC 5 TCLAS Optional 6 TCLAS Processing Optional 7 U-APSD Coexistence Optional 8 Expedited Bandwidth Request element Optional 9 Intra-Access Category Priority element Optional 10 Higher Layer Stream ID element Only in AP-initiated TS setup 11 Multi-band Optional 12 U-PID Optional 13 Multiple MAC Sublayers Optional 1159 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Category field is defined in 9.4.1.11. The QoS Action field is defined in 9.6.3.1. The values of the Dialog Token, TCLAS, and subsequent fields of this frame are the same as the values of the corresponding parameters in the invocation of the MLME-ADDTS.request primitive that causes the frame to be sent. Some of the TSPEC parameters have the same values as the corresponding parameters in the invocation of the MLME-ADDTS.request primitive, while the values of the other fields (i.e., Surplus Bandwidth Allowance, Minimum Service Interval, Maximum Service Interval, and Minimum PHY Rate) are generated within the MAC. The TSPEC element, defined in 9.4.2.30, and the optional TCLAS element, defined in 9.4.2.31, contain the QoS parameters that define the TS. The TS is identified by the TSID and Direction fields within the TSPEC element. The TCLAS element is optional at the discretion of the STA that sends the ADDTS Request frame, regardless of the setting of the access policy (EDCA, SPCA, or HCCA). There are zero or more TCLAS elements in the ADDTS frame. The TCLAS Processing element is present when there is more than one TCLAS element and is defined in 9.4.2.33. An Expedited Bandwidth Request element is optionally present, which is defined in 9.4.2.94. The U-APSD Coexistence element, defined in 9.4.2.91, contains the coexistence parameters requested by the non-AP STA when using the U-APSD coexistence capability as described in 11.2.3.5.2. The U-APSD Coexistence element is optionally present. An Intra-Access Category Priority element is optionally present, which is defined in 9.4.2.121 and described in 11.4.1. The Higher Layer Stream ID element (9.4.2.125) provides the stream identifier from a higher layer protocol. The Higher Layer Stream ID element is present only in the AP-initiated TS setup (11.4.4.3). When present in an ADDTS Request frame, the Multi-band element indicates the frequency band, operating class, and channel number to which the ADDTS Request frame applies and contains band-specific information. When present in the ADDTS Request frame, the U-PID element indicates the upper layer protocol associated with the TID/TSID specified within the TSPEC element contained in this frame. When present in the ADDTS Request frame, the Multiple MAC Sublayers element is used to establish an MMSL cluster. 9.6.3.2.2 DMG ADDTS Request frame variant The DMG ADDTS Request frame is used by DMG STAs in a PBSS and in an infrastructure BSS. The Action field of the DMG ADDTS Request frame contains the information shown in Table 9-290. Table 9-290â€”DMG ADDTS Request frame variant Action field format Order Information Notes 1 Category 2 Action 3 Dialog Token 1160 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-290â€”DMG ADDTS Request frame variant Action field format (continued) Order Information Notes 4 DMG TSPEC 5 TSPEC Optional 6 TCLAS Optional 7 TCLAS Processing Optional 8 Multi-band Optional 9 U-PID Optional 10 Multiple MAC Sublayers Optional 11 Higher Layer Stream ID Optional The values of the Dialog Token, DMG TSPEC, TSPEC, TCLAS, and subsequent fields of this frame are the same as the values of the corresponding parameters in the invocation of the MLME-ADDTS.request primitive that causes the frame to be sent. The DMG TSPEC element contains the parameters that define an allocation. The allocation uniquely identified by the Source AID, Allocation ID, and Destination AID subfields within the DMG TSPEC element. The optional TSPEC element defines a TS that can use the allocation if the allocation is created successfully. The TCLAS element is optional and can be present only when a TSPEC element is present; it is used to identify the destination non-AP and non-PCP DMG STA of the ADDTS Request frame. There can be one or more TCLAS elements in the DMG ADDTS Request frame. The TCLAS Processing element is present if there is more than one TCLAS element. When present in a DMG ADDTS Request frame, the Multi-band element indicates the frequency band, operating class, and channel number to which the TS identified by the optional TSPEC element applies. When present in the DMG ADDTS Request frame, the U-PID element indicates the upper layer protocol associated with the TS identified by the optional TSPEC element contained in this frame. If a TSPEC element is not present in the frame, the U-PID element is not present in the frame. When present in the DMG ADDTS Request frame, the Multiple MAC Sublayers element is used to establish an MMSL cluster. 9.6.3.3 Basic and DMG ADDTS Response frame format 9.6.3.3.1 Basic ADDTS Response frame variant The ADDTS Response frame is transmitted in response to an ADDTS Request frame. The Action field of the ADDTS Response frame contains the information shown in Table 9-291. 1161 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-291â€”Basic ADDTS Response frame variant Action field format Order Information Notes 1 Category 2 QoS Action 3 Dialog Token 4 Status Code 5 TS Delay 6 TSPEC 7 TCLAS Optional 8 TCLAS Processing Optional 9 Schedule Optionally present if the status code is equal to SUCCESS; otherwise not present 10 Expedited Bandwidth Request Optional 11 Higher Layer Stream ID Only in AP-initiated TS setup 12 Multi-band Optional 13 U-PID Optional 14 Multiple MAC Sublayers Optional The Category field is defined in 9.4.1.11. The QoS Action field is defined in 9.6.3.1. The Status Code field is defined in 9.4.1.9. The values the Dialog Token, TS Delay, TSPEC, TCLAS, and subsequent fields in this frame are the same as the values of the corresponding parameters in the invocation of the MLME-ADDTS.response primitive that causes the frame to be sent. The TS Delay element is present in an ADDTS Response frame only if the status code is equal to REJECTED_FOR_DELAY_PERIOD. The Schedule element, defined in 9.4.2.34, is present in an ADDTS Response frame only if the status code is equal to SUCCESS(i.e., when the TS is admitted). The Higher Layer Stream ID element is present only in AP-initiated TS setup. The Higher Layer Stream ID element (9.4.2.125) contains the stream identifier provided by a higher layer protocol. When present in an ADDTS Response frame, the Multi-band element indicates the frequency band, operating class, and channel number to which the ADDTS Response frame applies and contains band- specific information. When present in the ADDTS Response frame, the U-PID element indicates the upper layer protocol associated with the TID/TSID specified within the TSPEC contained in this frame. When present in the ADDTS Response frame, the Multiple MAC Sublayers element is used to establish an MMSL cluster (see 11.34). 1162 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.6.3.3.2 DMG ADDTS Response frame variant The DMG ADDTS Response frame is used by DMG STAs in a PBSS and in an infrastructure BSS. The Action field of the DMG ADDTS Response frame contains the information shown in Table 9-292. Table 9-292â€”DMG ADDTS Response frame variant Action field format Order Information Notes 1 Category 2 Action 3 Dialog Token 4 Status code 5 TS Delay 6 DMG TSPEC 7 TSPEC Optional 8 TCLAS Optional 9 TCLAS Processing Optional 10 Multi-band Optional 11 U-PID Optional 12 Multiple MAC Sublayers Optional 13 Higher Layer Stream ID Optional The values of the Dialog Token, TS Delay, DMG TSPEC, TSPEC, TCLAS, and subsequent fields in this frame are the same as the values of the corresponding parameters in the invocation of the MLME- ADDTS.response primitive that causes the frame to be sent. The TS Delay element is present in a DMG ADDTS Response frame only if the status code is set to REJECTED_FOR_DELAY_PERIOD (9.4.1.9). When present in a DMG ADDTS Response frame, the Multi-band element indicates the frequency band, operating class, and channel number to which the TS identified by the optional TSPEC element applies. When present in the DMG ADDTS Response frame, the U-PID element indicates the upper layer protocol associated with the TS identified by the optional TSPEC contained in this frame. If a TSPEC element is not present in the frame, the U-PID element is not present in the frame. When present in the DMG ADDTS Response frame, the Multiple MAC Sublayers element is used to establish an MMSL cluster (see 11.34). 9.6.3.4 DELTS frame format The DELTS frame is used to delete a TS or an allocation using the procedures defined in 11.4.9. The Action field of a DELTS frame contains the information shown in Table 9-293. 1163 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-293â€”DELTS frame Action field format Order Information 1 Category 2 QoS Action 3 TS Info 4 Reason Code 5 DMG Allocation Info (optional) 6 Multi-band (optional) The Category field is defined in 9.4.1.11. The QoS Action field is defined in 9.6.3.1. The TS Info field is defined in 9.4.2.30. Either the field identifies an existing TS created using the TSPEC element, or all its subfields are set to 0. The DMG Allocation Info field, defined in 9.4.2.134, is present when an existing DMG allocation is being deleted. When a DMG allocation is being deleted, the DMG Allocation Info field identifies an existing allocation created using the DMG TSPEC element. When a DMG allocation is not being deleted, all subfields in the DMG Allocation Info field are set to 0. The Reason Code field is defined in 9.4.1.7. A DELTS frame is used to delete a TS characterized by the TS Info field or to delete a DMG allocation identified by the DMG Allocation Info field in the frame. A DELTS frame can be sent from the HC or PCP to the source STA of that TS, or vice versa, to indicate an imperative request, to which no response is required from the recipient STA. When present in an DELTS frame, the Multi-band element indicates the frequency band, operating class, and channel number to which the DELTS frame applies. 9.6.3.5 Schedule frame format The Schedule frame is transmitted by the HC to announce the schedule of delivery of data and polls. The Action field of the Schedule frame contains the information shown in Table 9-294. Table 9-294â€”Schedule frame Action field format Order Information 1 Category 2 QoS Action 3 Schedule The Category field is defined in 9.4.1.11. The QoS Action field is defined in 9.6.3.1. The Schedule element is defined in 9.4.2.34. 1164 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.6.3.6 QoS Map Configure frame format The QoS Map Configure frame is used by an AP to provide the QoS Map information to a non-AP STA using the procedures defined in 11.25.9. The Action field of the QoS Map Configure frame contains the information shown in Table 9-295. Table 9-295â€”QoS Map Configure frame Action field format Order Information 0 Category 1 Action 2 QoS Map 3 Intra-Access Category Priority elements (optional) The Category field is defined in 9.4.1.11. The Action field is defined in 9.6.3.1. The QoS Map element is defined in 9.4.2.95. Zero or more Intra-Access Category Priority elements are present, which are defined in 9.4.2.121. 9.6.3.7 ADDTS Reserve Request frame format The ADDTS Reserve Request frame is transmitted by an AP to a non-AP STA in response to a higher layer protocol. See 11.4.4.3. The Action field of the ADDTS Reserve Request frame contains the information shown in Table 9-296. Table 9-296â€”ADDTS Reserve Request frame Action field format Order Information 1 Category 2 QoS Action 3 TSPEC 4 Schedule 5 Higher Layer Stream ID The Category field is defined in 9.4.1.11. The QoS Action field is defined in 9.6.3.1. ADDTS Reserve Request. The TSPEC element contains the QoS parameters that define the TS. The QoS parameters in the TSPEC are equivalent to the QoS parameters of the higher level stream identified by the Higher Level Stream ID. The TS is identified by the TSID and Direction fields within the TSPEC element. 1165 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Schedule element is defined in 9.4.2.34 and set to reflect schedule information corresponding to the TSPEC specification. The Higher Layer Stream ID element (defined in 9.4.2.125) provides the stream identifier from a higher layer protocol. 9.6.3.8 ADDTS Reserve Response frame format An ADDTS Reserve Response frame is used by a non-AP STA to indicate the completion of an AP-initiated TS setup procedure (11.4.4.3). The Action field of the ADDTS Reserve Response frame contains the information shown in Table 9-297. Table 9-297â€”ADDTS Reserve Response frame Action field format Order Information 1 Category 2 QoS Action 3 Higher Layer Stream ID 4 Status Code The Category field is defined in 9.4.1.11. The QoS Action field is defined in 9.6.3.1. representing ADDTS Reserve Response. The Higher Layer Stream ID is defined in 9.4.2.125. The Status Code field is defined in 9.4.1.9. 9.6.4 DLS Action frame details 9.6.4.1 General Several Action frame formats are defined for DLS management purposes. A DLS Action field, in the octet field immediately after the Category field, differentiates the formats. The DLS Action field values associated with each frame format are defined in Table 9-298. Table 9-298â€”DLS Action field values DLS Action field Meaning value 0 DLS Request 1 DLS Response 2 DLS Teardown 3â€“255 Reserved 1166 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.6.4.2 DLS Request frame format The DLS Request frame is used to set up a direct link with a peer MAC. The Action field of the DLS Request frame contains the information shown in Table 9-299, with some fields being optionally present as indicated in the â€œNotesâ€ column of the table. Table 9-299â€”DLS Request frame Action field format Order Information Notes 1 Category 2 DLS Action 3 Destination MACAddress 4 Source MACAddress 5 Capability Information 6 DLS Timeout Value 7 Supported Rates and BSS Membership Selectors 8 Extended Supported Rates and BSS Membership Selectors 9 HT Capabilities The HT Capabilities element is present when dot11HighThroughputOptionImplemented is true. 10 AID The AID element containing the AID of the STA sending the frame is present if dot11VHTOptionImplemented is true. 11 VHT Capabilities The VHT Capabilities element is present if the dot11VHTOptionImplemented is true. The Category field is defined in 9.4.1.11. The DLS Action field is defined in 9.6.4.1. The Destination MAC Address field value is the MAC address of the target destination. The Source MAC Address field value is the MAC address of the initiating STA. The Capability Information field value is the capability information of the originator of the request. The DLS Timeout Value field is defined in 9.4.1.13. The Supported Rates and BSS Membership Selectors and Extended Supported Rates and BSS Membership Selectors fields contain the supported rates information of the originator. 9.6.4.3 DLS Response frame format The DLS Response frame is sent in response to a DLS Request frame. The Action field of a DLS Response frame contains the information shown in Table 9-300, with some fields being optionally present as indicated in the â€œNotesâ€ column of the table. 1167 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-300â€”DLS Response frame Action field format Order Information Notes 1 Category 2 DLS Action 3 Status Code 4 Destination MACAddress 5 Source MACAddress 6 Capability Information 7 Supported Rates and BSS Membership Selectors 8 Extended Supported Rates and BSS Membership Selectors 9 HT Capabilities The HT Capabilities element is present when dot11HighThroughputOptionImplemented is true. 10 AID The AID element containing the AID of the STA sending the frame is present if dot11VHTOptionImplemented is true. 11 VHT Capabilities The VHT Capabilities element is present if the dot11VHTOptionImplemented is true. The Category field is defined in 9.4.1.11. The DLS Action field is defined in 9.6.4.1. The Status Code field is defined in 9.4.1.9. The Destination MAC Address field value and the Source MAC Address field value are copied from the corresponding fields in the DLS Request frame. The Capability Information field is the capability information of the target destination. This information is included only if the DLS result code corresponds to SUCCESS (DLS status code 0). The Supported Rates and BSS Membership Selectors and Extended Supported Rates and BSS Membership Selectors fields contain the supported rates information of the target destination. This information is included only if the DLS result code corresponds to SUCCESS (DLS status code 0). 9.6.4.4 DLS Teardown frame format The DLS Teardown frame is sent to terminate a direct link with a peer MAC. The Action field of the DLS Teardown frame contains the information shown in Table 9-301. 1168 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-301â€”DLS Teardown frame Action field format Order Information 1 Category 2 DLS Action 3 Destination MAC Address 4 Source MAC Address 5 Reason Code The Category field is defined in 9.4.1.11. The DLS Action field is defined in 9.6.4.1. The Destination MAC Address field value is the MAC address of the target destination. The Source MAC Address field value is the MAC address of the initiating STA. The Reason Code field is defined in 9.4.1.7. 9.6.5 Block Ack Action frame details 9.6.5.1 General ADDBA Request and ADDBA Response frames are used to set up or, if a STA is PBAC, to modify Block Ack operation for a specific TC, TS, or GCR group address. A Block Ack Action field, in the octet immediately after the Category field, differentiates the Block Ack Action frame formats. The Block Ack Action field values associated with each frame format within the Block Ack category are defined in Table 9-302. Table 9-302â€”Block Ack Action field values Block Ack Action Meaning field values 0 ADDBA Request 1 ADDBA Response 2 DELBA 3â€“255 Reserved 9.6.5.2 ADDBA Request frame format An ADDBA Request frame is sent by an originator of block ack to another STA. The Action field of an ADDBA Request frame contains the information shown in Table 9-303. 1169 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-303â€”ADDBA Request frame Action field format Order Information 1 Category 2 Block Ack Action 3 Dialog Token 4 Block Ack Parameter Set 5 Block Ack Timeout Value 6 Block Ack Starting Sequence Control 7 GCR Group Address element (optional) 8 Multi-band (optional) 9 TCLAS (optional) 10 ADDBA Extension (optional) The Category field is defined in 9.4.1.11. The Block Ack Action field is defined in 9.6.5.1. The Dialog Token field is set to a nonzero value chosen by the STA. The Block Ack Parameter Set field is defined in 9.4.1.14. The Block Ack Timeout Value field is defined in 9.4.1.15. The Starting Sequence Number subfield of the Block Ack Starting Sequence Control field (see Figure 9-27) contains the sequence number of the first or next (in the case of a renegotiation of a block ack agreement) MSDU to be sent under this block ack agreement. The Fragment Number subfield is set to 0. If the GCR Group Address element is present, the TID field within the Block Ack Parameter Set field is reserved. The GCR Group Address element contains the group address for which a block ack agreement is requested. When present in an ADDBA Request frame, the Multi-band element indicates the frequency band, operating class, and channel number to which the ADDBA Request frame applies and contains band-specific information. The ADDBA Extension element is defined in 9.4.2.139. 9.6.5.3 ADDBA Response frame format The ADDBA Response frame is sent in response to an ADDBA Request frame. The Action field of an ADDBA Response frame contains the information shown in Table 9-304. 1170 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-304â€”ADDBA Response frame Action field format Order Information 1 Category 2 Block Ack Action 3 Dialog Token 4 Status Code 5 Block Ack Parameter Set 6 Block Ack Timeout Value 7 GCR Group Address element (optional) 8 Multi-band (optional) 9 TCLAS (optional) 10 ADDBA Extension (optional) The Category field is defined in 9.4.1.11. The Block Ack Action field is defined in 9.6.5.1. The Dialog Token field value is copied from the corresponding received ADDBA Request frame. The Status Code field is defined in 9.4.1.9. The Block Ack Parameter Set field is defined in 9.4.1.14. The Block Ack Timeout Value field is defined in 9.4.1.15. If the GCR Group Address element is present, the TID field within the Block Ack Parameter Set field is reserved. The GCR Group Address element contains the group address for which a block ack agreement is requested. When present in an ADDBA Response frame, the Multi-band element indicates the frequency band ID, operating class, and channel number to which the ADDBA Response frame applies and contains band- specific information. The ADDBA Extension element is defined in 9.4.2.139. 9.6.5.4 DELBA frame format The DELBA frame is sent by either the originator of the traffic or the recipient to terminate the block ack participation. The Action field of a DELBA frame format contains the information shown in Table 9-305. 1171 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-305â€”DELBA frame Action field format Order Information 1 Category 2 Block Ack Action 3 DELBA Parameter Set 4 Reason Code 5 DELBA GCR Group Address 6 Multi-band (optional) 7 TCLAS (optional) The Category field is defined in 9.4.1.11. The Block Ack Action field is defined in 9.6.5.1. The DELBA Parameter Set field is defined in 9.4.1.16. The Reason Code field is defined in 9.4.1.7. The DELBA GCR Group Address field is defined in 9.4.2.126 and contains the GCR group address whose block ack agreement is being terminated. When present in an DELBA frame, the Multi-band element indicates the frequency band, operating class, and channel number to which the DELBA frame applies. 9.6.6 Vendor-specific action details The Vendor Specific frame is defined for vendor-specific signaling. The format of the Action field of the Vendor Specific frame is shown in Figure 9-648. An Organization Identifier, in the octet field immediately after the Category field, differentiates the vendors (see 9.4.1.32). NOTEâ€”If management frame protection is negotiated, then Vendor Specific Protected Action frames (see Table 9-47) are protected; otherwise they are unprotected. Organization Category Vendor Specific Content Identifier Octets: 1 j variable Figure 9-648â€”Vendor Specific frame Action field format The Category field is defined in 9.4.1.11. The Organization Identifier field contains a organization identifier assigned by the IEEE and is specified in 9.4.1.32. The order of the Organization Identifier field is described in 9.2.2. The Vendor Specific Content field contains vendor-specific field(s). The length of the vendor specific content in a Vendor Specific frame is limited by the maximum allowed MMPDU size. 1172 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.6.7 Radio Measurement action details 9.6.7.1 General Several Action frame formats are defined for radio measurement purposes. A Radio Measurement Action field, in the octet field immediately after the Category field, differentiates the formats. The Radio Measurement Action field values associated with each frame format are defined in Table 9-306. Table 9-306â€”Radio Measurement Action field values Radio Measurement Description Action field value 0 Radio Measurement Request 1 Radio Measurement Report 2 Link Measurement Request 3 Link Measurement Report 4 Neighbor Report Request 5 Neighbor Report Response 6â€“255 Reserved 9.6.7.2 Radio Measurement Request frame format The Radio Measurement Request frame uses the Action frame body format. It is transmitted to another STA to request that it makes one or more measurements on one or more channels. The format of the Action field in the Radio Measurement Request frame is shown in Figure 9-649. Radio Measurement Number of Measurement Request Category Dialog Token Action Repetitions Elements Octets: 1 1 1 2 variable Figure 9-649â€”Radio Measurement Request frame Action field format The Category field is defined in 9.4.1.11. The Radio Measurement Action field is defined in 9.6.7.1. The Dialog Token field is set to a nonzero value chosen by the STA sending the radio measurement request to identify the request/report transaction. The Number of Repetitions field contains the requested number of repetitions for all of the Measurement Request elements in this frame. A value of 0 in the Number of Repetitions field indicates Measurement Request elements are executed once without repetition. A value of 65 535 in the Number of Repetitions field indicates Measurement Request elements are repeated until the measurement is canceled or superseded. The Measurement Request Elements field contains zero or more of the Measurement Request elements described in 9.4.2.21. The number and length of the Measurement Request elements in a Measurement Request frame are limited by the maximum allowed MMPDU size. 1173 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.6.7.3 Radio Measurement Report frame format The Radio Measurement Report frame uses the Action frame body format. It is transmitted in response to a Radio Measurement Request frame or by a STA providing a triggered autonomous measurement report. The format of the Action field in the Radio Measurement Report frame is shown in Figure 9-650. Category Radio Measurement Dialog Token Measurement Action Report Elements Octets: 1 1 1 variable Figure 9-650â€”Radio Measurement Report frame Action field format The Category field is defined in 9.4.1.11. The Radio Measurement Action field is defined in 9.6.7.1. The Dialog Token field is set to the value in the corresponding Radio Measurement Request frame. If the Radio Measurement Report frame is not being transmitted in response to a Radio Measurement Request frame then the dialog token is set to 0. The Measurement Report Elements field contains one or more Measurement Report elements described in 9.4.2.22. The number and length of the Measurement Report elements in a single Radio Measurement Report frame are limited by the maximum allowed MMPDU size. Subclause 11.11.6 describes the required behavior for multiframe Radio Measurement Report frame responses. 9.6.7.4 Link Measurement Request frame format The Link Measurement Request frame is transmitted by a STA to request another STA to respond with a Link Measurement Report frame to enable measurement of link path loss and estimation of link margin. In a non-DMG BSS, a Link Measurement Request frame is an Action frame and in a DMG BSS, a Link Measurement Request frame is an Action or an Action No Ack frame. The format of the Action field in the Link Measurement Request frame is shown in Figure 9-651. Radio Measurement Dialog Transmit Max Transmit Category Action Token Power Used Power Octets: 1 1 1 1 1 Figure 9-651â€”Link Measurement Request frame Action field format The Category field is defined in 9.4.1.11. The Radio Measurement Action field is defined in 9.6.7.1. The Dialog Token field is set to a nonzero value chosen by the STA sending the request to identify the transaction. The Transmit Power Used field is set to the transmit power used to transmit the frame containing the Link Measurement Request, as described in 9.4.1.20. The Max Transmit Power field provides the upper limit on the transmit power as measured at the output of the antenna connector to be used by the transmitting STA on its operating channel. This field is described in 9.4.1.19. The Max Transmit Power field is a 2s complement signed integer and is 1 octet in length, 1174 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications providing an upper limit, in a dBm scale, on the transmit power as measured at the output of the antenna connector to be used by the transmitting STA on its operating channel. The maximum tolerance for the value reported in Max Transmit Power field is Â±5 dB. The value of the Max Transmit Power field is equal to the minimum of the maximum powers at which the STA is permitted to transmit in the operating channel by device capability, policy, and regulatory authority. 9.6.7.5 Link Measurement Report frame format The Link Measurement Report frame is transmitted in response to a Link Measurement Request frame. In a non-DMG BSS, a Link Measurement Report frame is an Action frame and in a DMG BSS, a Link Measurement Report frame is an Action or an Action No Ack frame. The format of the Action field in the Link Measurement Report frame is shown in Figure 9-652. Radio Dialog TPC Receive Transmit DMG DMG Link Category Measurement Report Antenna RCPI RSNI Link Adaptation Action Token element ID Antenna ID Margin Acknowledgment Octets: 1 1 1 4 1 1 1 1 variable variable Figure 9-652â€”Link Measurement Report frame Action field format The Category field is defined in 9.4.1.11. The Radio Measurement Action field is defined in 9.6.7.1. The Dialog Token field is set to the value of the Dialog Token field in the corresponding Link Measurement Request frame. The TPC Report element is set as described in 9.4.2.17. The Receive Antenna ID field contains the identifying number for the antenna(s) used to receive the corresponding Link Measurement Request frame. Antenna ID is defined in 9.4.2.40. The Transmit Antenna ID field contains the identifying number for the antenna(s) used to transmit this Link Measurement Report frame. Antenna ID is defined in 9.4.2.40. RCPI indicates the received channel power of the corresponding Link Measurement Request frame, which is a logarithmic function of the received signal power, as defined in 9.4.2.38. RSNI indicates the received signal-to-noise indication for the corresponding Link Measurement Request frame, as described in 9.4.2.41. The DMG Link Margin field is optionally present. When present, it contains a DMG Link Margin element (see 9.4.2.142). The DMG Link Margin Adaptation Acknowledgment field is optionally present. When present, it contains a DMG Link Margin Adaptation Acknowledgment element (see 9.4.2.143). 9.6.7.6 Neighbor Report Request frame format The Neighbor Report Request frame uses the Action frame body format and is transmitted requesting information in the neighbor report about neighboring APs. The format of the Action field in the Neighbor Report Request frame is shown in Figure 9-653. 1175 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Location Civic Radio Measurement SSID LCI Measurement Measurement Category Dialog Token Request Action (optional) (optional) Request (optional) Octets: 1 1 1 variable variable variable Figure 9-653â€”Neighbor Report Request frame Action field format The Category field is defined in 9.4.1.11. The Radio Measurement Action field is defined in 9.6.7.1. The Dialog Token field is set to a nonzero value chosen by the STA sending the measurement request to identify the request/report transaction. The SSID field is optionally present. If present, it contains an SSID element. The presence of an SSID element in a Neighbor Report Request frame indicates a request for a neighbor list for the specified SSID in the SSID Element. The absence of an SSID element indicates neighbor report for the current ESS. The LCI Measurement Request field is optionally present. If present, it contains a Measurement Request element with Measurement Type field equal to LCI (see Table 9-82), which indicates a request for a Measurement Report subelement with Measurement Type field equal to LCI for each Neighbor Report element (see 11.11.10.2). The Enable bit in the Measurement Request Mode field in the Measurement Request element is set to 0. The Location Subject field in the Measurement Request field of the Measurement Request element is set to Location Subject Remote (see Table 9-94). The Request, Report and Duration Mandatory bits within the Measurement Request Mode field in the Measurement Request element are reserved (see 9.4.2.21.1). The Location Civic Measurement Request field is optionally present. If present, it contains a Measurement Request element with Measurement Type field equal to Location Civic (see Table 9-82). The element indicates a request for a Measurement Report subelement with Measurement Type field equal to Location Civic for each Neighbor Report element (see 11.11.10.2). The Enable bit in the Measurement Request Mode field within the Measurement Request element is set to 0. The Location Subject field in the Measurement Request field of the Measurement Request element is equal to Location Subject Remote (see Table 9-94). The Location Service Interval Units field in the Measurement Request field of the Measurement Request element is set to 0. The Request, Report and Duration Mandatory bits in the Measurement Request Mode field in the Measurement Request element are reserved (see 9.4.2.21.1). 9.6.7.7 Neighbor Report Response frame format The Neighbor Report Response frame uses the Action frame body format and is transmitted in response to a Neighbor Report Request frame. The format of the Action field in the Neighbor Report Response frame is shown in Figure 9-654. Category Radio Measurement Dialog Token Neighbor Report Action Elements Octets: 1 1 1 variable Figure 9-654â€”Neighbor Report Response frame Action field format The Category field is defined in 9.4.1.11. The Radio Measurement Action field is defined in 9.6.7.1. 1176 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Dialog Token field set to the value in the corresponding Neighbor Report Request frame. If the Neighbor Report Response frame is not being transmitted in response to a Neighbor Report Request frame, then the dialog token is set to 0. The Neighbor Report Elements field contains the Neighbor Report elements for validated APs described in 9.4.2.37. If the STA has no information in response to the Neighbor Report Request, the Neighbor Report elements are omitted. The number and length of the Neighbor Report Elements in a Neighbor Report frame is limited by the maximum allowed MMPDU size. NOTEâ€”Under some circumstances, a Neighbor Report element is included for the STA transmitting the frame. See 11.11.10.3. 9.6.8 Public Action details 9.6.8.1 Public Action frames The Public Action frame is defined to allow the following: â€” Inter-BSS and AP to unassociated-STA communications â€” Intra-BSS communication â€” GAS A Public Action field, in the octet immediately after the Category field, differentiates the Public Action frame formats. The defined Public Action frames are listed in Table 9-307. Table 9-307â€”Public Action field values Public Action field value Description 0 20/40 BSS Coexistence Management (see 9.6.8.2) 1 DSE enablement 2 DSE deenablement 3 DSE Registered Location Announcement 4 Extended Channel Switch Announcement 5 DSE measurement request 6 DSE measurement report 7 Measurement Pilot 8 DSE power constraint 9 Vendor Specific 10 GAS Initial Request (see 9.6.8.12) 11 GAS Initial Response (see 9.6.8.13) 12 GAS Comeback Request (see 9.6.8.14) 13 GAS Comeback Response (see 9.6.8.15) 14 TDLS Discovery Response 15 Location Track Notification 1177 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-307â€”Public Action field values (continued) Public Action field value Description 16 QAB Request frame 17 QAB Response frame 18 QMF Policy 19 QMF Policy Change 20 QLoad Request 21 QLoad Report 22 HCCA TXOP Advertisement 23 HCCA TXOP Response 24 Public Key 25 Channel Availability Query 26 Channel Schedule Management 27 Contact Verification Signal 28 GDD Enablement Request 29 GDD Enablement Response 30 Network Channel Control 31 White Space Map Announcement 32 Fine Timing Measurement Request 33 Fine Timing Measurement 25â€“255 Reserved 9.6.8.2 20/40 BSS Coexistence Management frame format The 20/40 BSS Coexistence Management frame is a Public Action frame. The format of its Action field is defined in Table 9-308. Table 9-308â€”20/40 BSS Coexistence Management frame Action field format Order Information Notes 1 Category 2 Public Action 3 20/40 BSS Coexistence (see 9.4.2.60) 4 20/40 BSS Intolerant Channel Report (see 9.4.2.58) Appears zero or more times The Category field is defined in 9.4.1.11. 1178 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Public Action field is defined in 9.6.8.1. 9.6.8.3 Measurement Pilot frame format The Measurement Pilot frame uses the Action frame format. The format of the Action field is shown in Figure 9-655. Public Condensed Condensed Operating Measurement Optional Category Capability Country Channel Action Information String Class Pilot Interval Subelements Octets: 1 1 1 2 1 1 1 variable Figure 9-655â€”Measurement Pilot frame Action field format The Category field is defined in 9.4.1.11. The Public Action field is defined in 9.6.8.1. The Condensed Capability Information field contains two subfields as shown in Figure 9-656. B0 B1 B2 B7 Spectrum Short Slot Time Reserved Management Bits: 1 1 6 Figure 9-656â€”Condensed Capability Information field The Spectrum Management subfield is set to 1 if dot11SpectrumManagementRequired is true; otherwise, it is set to 0. The Short Slot Time subfield is set to 1 if dot11ShortSlotTimeOptionImplemented and dot11ShortSlotTimeOptionActivated are true. Otherwise, the Short Slot Time subfield is set to 0. The Condensed Country String field is set to the first two octets of the value contained in dot11CountryString. If the Wide Bandwidth Channel Switch subelement is not included, the Operating Class field indicates the operating class value for the operating channel. The Country, Operating Class, and Channel Number fields together specify the channel frequency and spacing for the operating channel. Valid operating classes are listed in Annex E, excluding Operating Classes that encompass a primary channel but do not identify the location of the primary channel. The Channel Number field indicates the operating channel. Channel number is defined within an operating class as shown in Annex E. If the Wide Bandwidth Channel Switch subelement is included, the fields in the Wide Bandwidth Channel Switch subelement indicate the operating channel, and the Operating Class and Channel Number together specify the primary channel and primary 40 MHz channel within the channel identified by the Wide Bandwidth Channel Switch subelement. The Measurement Pilot Interval field is set to the value contained in dot11RMMeasurementPilotPeriod. The Optional Subelements field contains zero or more subelements. The subelement format and ordering of subelements are defined in 9.4.3. 1179 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Subelement ID field values for the defined subelements are shown in Table 9-309. Table 9-309â€”Optional subelement IDs for Measurement Pilot frame Subelement ID Name Extensible 0â€“70 Reserved 71 Multiple BSSID Subelements 72â€“162 Reserved 163 Wide Bandwidth Channel Switch Yes 164â€“255 Reserved The Wide Bandwidth Channel Switch subelement has the same format as the corresponding element (see 9.4.2.161) with the constraint that the New Channel Width field indicates an 80 MHz, 160 MHz, or 80+80 MHz BSS bandwidth. The Multiple BSSID and Vendor Specific subelements have the same format as the Multiple BSSID and Vendor Specific elements (see 9.4.2.46 and 9.4.2.36, respectively). Multiple Vendor Specific subelements may be included in the list of optional subelements. 9.6.8.4 DSE Enablement frame format The DSE Enablement frame is an Action frame. It is transmitted as part of enablement. The format of the DSE Enablement frame Action field is shown in Figure 9-657. Requester Responder Reason Enablement Category Public Action STA Address STA Address Result Code Identifier Octets: 1 1 6 6 1 2 Figure 9-657â€”DSE Enablement frame Action field format The Category field is defined in 9.4.1.11. The Public Action field is defined in 9.6.8.1. The RequesterSTAAddress field is the MAC address of the requesting STA that initiates the enablement process. The length of the RequesterSTAAddress field is 6 octets. The ResponderSTAAddress field is the MAC address of the enablement responder. The length of the ResponderSTAAddress field is 6 octets. The Reason Result Code field is used to indicate the reason that a DSE Enablement frame was generated. The length of the Reason Result Code field is 1 octet. The reason result codes that have been allocated are shown in Table 9-310. The Enablement Identifier field is a 16-bit number assigned by an enabling STA to a dependent STA; otherwise, it is 0, set using the procedures defined in 11.12. 1180 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-310â€”Reason Result Code field values Reason Result Name Description Code field value 0 Reserved 1 Reserved 2 Enablement requested 3 SUCCESS Success 4 REFUSED Request declined 5 INVALID_PARAMETERS Request not successful as one or more parameters have invalid values 6 TOO_MANY_ Enablement denied because the enabling STA is SIMULTANEOUS_REQUESTS unable to handle additional dependent STAs 7â€“255 Reserved 9.6.8.5 DSE Deenablement frame format The DSE Deenablement frame is an Action frame. It is transmitted as part of deenablement. The format of the DSE Deenablement frame Action field is shown in Figure 9-658. Requester STA Responder STA Reason Result Category Public Action Address Address Code Octets: 1 1 6 6 1 Figure 9-658â€”DSE Deenablement frame Action field format The Category field is defined in 9.4.1.11. The Public Action field is defined in 9.6.8.1. The RequesterSTAAddress field is the MAC address of the requesting STA that initiates the deenablement process. The length of the RequesterSTAAddress field is 6 octets. The ResponderSTAAddress field is the MAC address of the responding STA that becomes deenabled. The length of the ResponderSTAAddress field is 6 octets. The Reason Result Code field is used to indicate the reason that a DSE Deenablement frame was generated. The length of the Reason Result Code field is 1 octet. The reason result codes that have been allocated are shown in Table 9-311. Table 9-311â€”Reason Result Code field values Reason Result Code field value Description 0 Reserved 1 Reserved 2 Deenablement requested 3â€“255 Reserved 1181 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.6.8.6 DSE Registered Location Announcement frame format The DSE Registered Location Announcement frame is transmitted by a dependent STA to advertise the registered location of its enabling STA. The format of the DSE Registered Location Announcement frame Action field is shown in Figure 9-659. Category Public Action DSE Registered Location Information Octets: 1 1 20 Figure 9-659â€”DSE Registered Location Announcement frame Action field format The Category field is defined in 9.4.1.11. The Public Action field is defined in 9.6.8.1. The DSE Registered Location Information field is defined in 9.4.2.52. 9.6.8.7 Extended Channel Switch Announcement frame format The Extended Channel Switch Announcement frame is transmitted by an AP, IBSS STA, or mesh STA to advertise a channel switch. The format of the Extended Channel Switch Announcement frame Action field is shown in Figure 9-660. Zero or Zero or Zero or one one more Mesh Wide New Channel New New Channel Channel New Bandwidth Transmit Public Category Action Switch Operating Channel Switch Switch Country Channel Power Mode Class Number Count Parameters element Switch Envelope element element element Octets: 1 1 1 1 1 1 0 or 8 variable variable variable Figure 9-660â€”Extended Channel Switch Announcement frame Action field format The Category field is defined in 9.4.1.11. The Public Action field is defined in 9.6.8.1. The Channel Switch Mode, New Operating Class, New Channel Number, and Channel Switch Count fields are as described in the Extended Channel Switch Announcement element (see 9.4.2.53). Mesh Channel Switch Parameters element is defined in 9.4.2.103. This element is present when a mesh STA performs MBSS channel switching. The Mesh Channel Switch Parameters element is not included for channel switching other than for a MBSS channel switch. The New Country element is present when an AP or mesh STA performs extended channel switching to a new Country, new Operating Class Table, or a changed set of operating classes relative to the contents of the Country element sent in the Beacon; otherwise, this element is not present. The format of the New Country element is defined to be the same as the format of the Country element (see 9.4.2.9), except that no Subband Triplet fields are present in the New Country element. The Country String field in the New Country element indicates the Country and Operating Class Table of the BSS after extended channel switching and Operating Triplet fields within the New Country element indicate the operating classes of the BSS after extended channel switching (see 11.40.1). 1182 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This Wide Bandwidth Channel Switch element is present when extended channel switching to a channel width wider than 40 MHz; otherwise, this element is not present. The Wide Bandwidth Channel Switch element is defined in 9.4.2.161. The Wide Bandwidth Channel Switch element indicates the BSS bandwidth after extended channel switching (see 11.40.1). Each New Transmit Power Envelope element that is present is defined to have the same format as the Transmit Power Envelope element (see 9.4.2.162) and includes a distinct value of the Local Maximum Transmit Power Unit Interpretation subfield. If present, the New Transmit Power Envelope element indicates the maximum transmit powers for the BSS for the indicated bandwidths with an indicated unit interpretation after extended channel switching (see 11.40.1). 9.6.8.8 DSE Measurement Request frame format The DSE Measurement Request frame is a Public Action frame requesting a DSE measurement report. It is transmitted using the procedures defined in 11.12. The format of the DSE Measurement Request frame Action field is shown in Figure 9-661. Public Requester Responder Operating Channel Measurement Measurement Category STA STA Action Address Address Class Number Start Time Duration Octets: 1 1 6 6 1 1 8 2 Figure 9-661â€”DSE Measurement Request frame Action field format The Category field is defined in 9.4.1.11. The Public Action field is defined in 9.6.8.1. The RequesterSTAAddress field is the MAC address of the STA that requests the DSE measurement report. The length of the RequesterSTAAddress field is 6 octets. The ResponderSTAAddress field is the MAC address of the responding STA that operates based on the enablement. The length of the ResponderSTAAddress field is 6 octets. The Operating Class field indicates the channel set for which the measurement request applies. The Operating Class and Channel Number fields together specify the channel frequency and channel bandwidth for which the measurement request applies. Valid values for the Operating Class field are shown in Annex E. The Measurement Start Time field is set to the timing synchronization function (TSF) at the time (Â± 1 TU) at which the requested DSE request measurement starts. A value of 0 indicates it starts immediately. The Measurement Duration field is set to the duration of the requested measurement, expressed in number of time units (TUs). 9.6.8.9 DSE Measurement Report frame format The DSE Measurement Report frame is a Public Action frame. It is transmitted using the procedures defined in 11.12. The format of the DSE Measurement Report frame Action field is shown in Figure 9-662. 1183 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Measure Public Requester Responder Operating Channel ment Actual Measurem Reported Category Action STA STA Length Class Number Report Measureme ent DSE LCI Address Address Mode nt Start Time Duration fields Octets: 1 1 6 6 2 1 1 1 8 2 n Ã— 26 Figure 9-662â€”DSE Measurement Report frame Action field format The Category field is defined in 9.4.1.11. The Public Action field is defined in 9.6.8.1. The RequesterSTAAddress field is the MAC address of the STA that requested the DSE measurement report. The length of the RequesterSTAAddress field is 6 octets. The ResponderSTAAddress field is the MAC address of the responding STA that operates based on the enablement. The length of the ResponderSTAAddress field is 6 octets. The Length field indicates the length of the remaining frame fields in octets, and the value is variable. The minimum value of the Length field is 13. The Operating Class field indicates the channel set for which the measurement report applies. The Operating Class and Channel Number fields together specify the channel frequency and spacing for which the measurement request applies. Valid values for the Operating Class field are shown in Annex E. The Measurement Report Mode field is as defined in 9.4.2.22 (see Figure 9-192). The Actual Measurement Start Time field is set to the measuring STAâ€™s TSF timer at the time (Â± 1 TU) at which the DSE measurement started. The Measurement Duration field is set to the duration over which the requested measurement was measured, expressed in number of TUs. The reported DSE LCI fields contain the DSE LCI received at the measuring STA. If the reported DSE LCI fields would cause the frame to exceed the maximum MAC management protocol data unit (MMPDU) size, then the reported DSE LCI fields are truncated so that the last reported DSE LCI field is complete. The DSE LCI field format is shown in Figure 9-663. B0 B47 B48 B53 B54 B87 B88 B93 B94 B127 B128 B131 B132 B137 B138 B167 SA MAC Latitude Longitude Altitude Altitude Latitude Longitude Altitude Address Uncertainty Uncertainty Type Uncertainty Bits: 48 6 34 6 34 4 6 30 B168 B170 B171 B172 B173 B174 B175 B176 B191 B192 B199 B200 B207 RegLoc Dependent Dependent Operating Channel Datum RegLoc DSE Version Enablement Agreement STA Identifier Class Number Bits: 3 1 1 1 2 16 8 8 Figure 9-663â€”DSE LCI field format 1184 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The SA MAC Address field contains the SA MAC address from the Beacon or Public Action frame containing a DSE Registered Location element being reported. The remaining fields are as defined in the DSE Registered Location Information field (see 9.4.2.52). 9.6.8.10 DSE Power Constraint frame format The DSE Power Constraint frame is a Public Action frame requesting that a dependent STA constrain transmit power below the regulatory limit. It is transmitted by an enabling STA as part of enablement. The format of the DSE Power Constraint frame Action field is shown in Figure 9-664. Category Public Action Requester Responder Reason Local Power STA Address STA Address Result Code Constraint Octets: 1 1 6 6 1 1 Figure 9-664â€”DSE Power Constraint frame Action field format The Category field is defined in 9.4.1.11. The Public Action field is defined in 9.6.8.1. The RequesterSTAAddress field is the MAC address of the STA that requests the DSE power constraint. The length of the RequesterSTAAddress field is 6 octets. The ResponderSTAAddress field is the MAC address of the responding STA that initiates the enablement. The length of the ResponderSTAAddress field is 6 octets. The Reason Result Code field is used to indicate the reason that a DSE Power Constraint frame was generated. The length of the Reason Result Code field is 1 octet. The reason result codes that have been allocated are shown in Table 9-312. Table 9-312â€”Reason Result Code field values Reason Result Code Name Description field value 0 Reserved 1 Reserved 2 Power constraint requested 3 SUCCESS Success 4 REFUSED Refused â€” no reason specified 5 INVALID_PARAMETERS Request not successful as one or more parameters have invalid values 6â€“255 Reserved The Local Power Constraint field is coded as an unsigned integer in units of decibels relative to 1 mW. The local maximum transmit power for a channel is thus defined as the maximum transmit power level specified for the channel in the Country element minus the local power constraint specified for the channel in the DSE Power Constraint frame. 1185 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.6.8.11 Vendor Specific Public Action frame format The Vendor Specific Public Action frame is defined for vendor-specific signaling between unassociated STAs. The format of the Action field of the Vendor Specific Public Action frame is shown in Figure 9-665. Category Public Action Organization Vendor Specific Identifier Content Octets: 1 1 variable variable Figure 9-665â€”Vendor Specific Public Action frame Action field format The Category field is defined in 9.4.1.11. The Public Action field is defined in 9.6.8.1. The Organization Identifier field contains a organization identifier assigned by the IEEE and is specified in 9.4.1.32. The order of the Organization Identifier field is described in 9.2.2. The length of the Organization Identifier field is variable, as specified in 9.4.1.32. The Vendor Specific Content field contains vendor-specific field(s). The length of the vendor specific content in a Vendor Specific frame is limited by the maximum allowed MMPDU size. 9.6.8.12 GAS Initial Request frame format The GAS Initial Request frame is a Public Action frame. It is transmitted by a requesting STA to request information from another STA. The format of the GAS Initial Request Action field is shown in Table 9-313. Table 9-313â€”GAS Initial Request Action field format Order Information 0 Category 1 Public Action 2 Dialog Token 3 Advertisement Protocol element 4 Query Request Length 5 Query Request 6 Multi-band (optional) The Category field is defined in 9.4.1.11. The Public Action field is defined in 9.6.8.1. The Dialog Token field is defined in 9.4.1.12 and set by the requesting STA. The Advertisement Protocol element is defined in 9.4.2.93. The Advertisement Protocol element includes exactly one Advertisement Protocol ID. 1186 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Query Request Length field is defined in Figure 9-666. The value of the Query Request Length field is set to the total number of octets in the Query Request field. B0 B15 Query Request length Octets: 2 Figure 9-666â€”Query Request Length field The Query Request field is defined in Figure 9-667. The Query Request field is a generic container whose value is a GAS Query that is formatted in accordance with the protocol identified in the Advertisement Protocol element. Query Request Octets: variable Figure 9-667â€”Query Request field When present in a GAS Initial Request frame, the Multi-band element indicates the frequency band, operating class, and channel number to which the GAS Initial Request frame applies. 9.6.8.13 GAS Initial Response frame format The GAS Initial Response frame is a Public Action frame. It is transmitted responding to a GAS Initial Request frame. The format of the GAS Initial Response Action field is shown in Table 9-314. Table 9-314â€”GAS Initial Response Action field format Order Information 0 Category 1 Public Action 2 Dialog Token 3 Status Code 4 GAS Comeback Delay 5 Advertisement Protocol element 6 Query Response Length 7 Query Response (optional) 8 Multi-band (optional) The Category field is defined in 9.4.1.11. The Public Action field is defined in 9.6.8.1. The Dialog Token field is copied from the corresponding GAS Initial Request frame. 1187 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Status Code values are defined in Table 9-46. The GAS Comeback Delay field specifies the delay time value in TUs. The GAS Comeback Delay field format is provided in Figure 9-668. The behavior is described in 11.25.3.2. The value 0 will be returned by the STA when a Query Response is provided in this frame. B0 B15 GAS Comeback Delay Octets: 2 Figure 9-668â€”GAS Comeback Delay field The Advertisement Protocol element is defined in 9.4.2.93. The Advertisement Protocol element includes exactly one Advertisement Protocol ID. The Query Response Length field is defined in Figure 9-669. The value of the Query Response Length field is set to the total number of octets in the Query Response field. If the Query Response Length field is set to 0, then there is no Query Response included in this Action frame. B0 B15 Query Response Length Octets: 2 Figure 9-669â€”Query Response Length field The Query Response field is defined in Figure 9-670. The Query Response field is a generic container whose value is the response to a GAS Query and is formatted in accordance with the protocol specified in the Advertisement Protocol element. Query Response Octets: variable Figure 9-670â€”Query Response field When present in a GAS Initial Response frame, the Multi-band element indicates the frequency band, operating class, and channel number to which the GAS Initial Response frame applies. 9.6.8.14 GAS Comeback Request frame format The GAS Comeback Request frame is a Public Action frame. It is transmitted by a requesting STA to a responding STA. The format of the GAS Comeback Request Action field is shown in Table 9-315. The Category field is defined in 9.4.1.11. The Public Action field is defined in 9.6.8.1. The Dialog Token field is copied from the corresponding GAS Initial Request frame. When present in a GAS Comeback Request frame, the Multi-band element indicates the frequency band, operating class, and channel number to which the GAS Comeback Request frame applies. 1188 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-315â€”GAS Comeback Request Action field format Order Information 0 Category 1 Public Action 2 Dialog Token 3 Multi-band (optional) 9.6.8.15 GAS Comeback Response frame format The GAS Comeback Response frame is a Public Action frame. It is transmitted by a responding STA to a requesting STA. The format of the GAS Comeback Response Action field is shown in Table 9-316. Table 9-316â€”GAS Comeback Response Action field format Order Information 0 Category 1 Public Action 2 Dialog Token 3 Status Code 4 GAS Query Response Fragment ID 5 GAS Comeback Delay 6 Advertisement Protocol element 7 Query Response Length 8 Query Response (optional) 9 Multi-band (optional) The Category field is defined in 9.4.1.11. The Public Action field is defined in 9.6.8.1. The Dialog Token field is copied from the Dialog Token field of the corresponding GAS Comeback Request frame. The same value of the Dialog Token field is present in all fragments of a multi-fragment query response. The Status Code values are defined in Table 9-46. The same status code value will be present in all fragments of a multi-fragment query response. The GAS Query Response Fragment ID is defined in 9.4.1.34. If the responding STA has not received a response to the query that it posted on behalf of a requesting STA, then the responding STA sets the GAS Query Response Fragment ID to 0. When there is more than one query response fragment, the responding STA sets the GAS Query Response Fragment ID to 0 for the initial fragment and increments it by 1 for each 1189 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications subsequent fragment in a multi-fragment Query Response. The More GAS Fragments field is set to 0 whenever the final fragment of a query response is being transmitted. A GAS Query Response Fragment ID field having a nonzero Fragment ID and the More GAS Fragments field set to 1 indicates to the requesting STA that another GAS Comeback frame exchange should be performed to continue the retrieval of the query response. The GAS Comeback Delay field format is provided in Figure 9-668. A nonzero GAS Comeback Delay value is returned by the responding STA in this frame to indicate that the GAS Query being carried out on behalf of the requesting STA is still in progress. â€” A nonzero value indicates to the requesting STA that another GAS Comeback frame exchange should be performed after the expiration of the GAS Comeback Delay timer in order to retrieve the query response. â€” This field is set to 0 for all GAS Comeback Response frames containing a query response or a fragment of a multi-fragment query response. The Advertisement Protocol element is defined in 9.4.2.93. The Advertisement Protocol element includes exactly one Advertisement Protocol ID. The Query Response Length field is defined in Figure 9-669. The value of the Query Response Length field is the total number of octets in the Query Response field. If the Query Response Length field is set to 0, then there is no Query Response included in this Action frame. The Query Response field is defined in Figure 9-670. The value of the Query Response field is a generic container dependent on the advertisement protocol specified in the Advertisement Protocol element and the query itself. In a multi-fragment query response, the response to the query posted on behalf of a requesting STA is fragmented such that each fragment to be transmitted fits within the MMPDU size limitation. When present in a GAS Comeback Response frame, the Multi-band element indicates the frequency band, operating class, and channel number to which the GAS Comeback Response frame applies. 9.6.8.16 TDLS Discovery Response frame format The format of the TDLS Discovery Response Action field is shown in Table 9-317. Table 9-317â€”TDLS Discovery Response Action field format Order Information Notes 1 Category The Category field is defined in 9.4.1.11. 2 Public Action The Public Action field is defined in 9.6.8.1. 3 Dialog Token The dialog token is copied from the corresponding TDLS Discovery Request frame. The dialog token is specified in 9.4.1.12. 4 Capability The Capability field indicates the capabilities of the STA. The Capability field is defined in 9.4.1.4. 5 Supported Rates and BSS The Supported Rates and BSS Membership Selectors element Membership Selectors indicates the rates which are supported by the STA. The Supported Rates and BSS Membership Selectors element is defined in 9.4.2.3. 6 Extended Supported Rates The Extended Supported Rates and BSS Membership Selectors and BSS Membership element is present whenever there are more than eight supported Selectors rates, and it is optional otherwise. The Extended Supported Rates and BSS Membership Selectors element is defined in 9.4.2.13. 1190 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-317â€”TDLS Discovery Response Action field format (continued) Order Information Notes 7 Supported Channels The Supported Channels element is present if the TDLS channel switching capability field is equal to 1. The Supported Channels element is defined in 9.4.2.18. 8 RSNE The RSNE is optionally present if security is required on the direct link. The RSNE is defined in 9.4.2.25. 9 Extended Capabilities The Extended Capabilities element is optionally present if any of the fields in this element are nonzero. The Extended Capabilities element is defined in 9.4.2.27. 10 FTE The FTE is optionally present if security is required on the direct link. The FTE is defined in 9.4.2.48. 11 Timeout Interval (TPK key The Timeout Interval element contains the TPK key lifetime. lifetime) It is present if security is required on the direct link. The Timeout Interval element is defined in 9.4.2.49. 12 Supported Operating The Supported Operating Classes element is present if the TDLS Classes channel switching capability field is equal to 1. The Supported Operating Classes element is defined in 9.4.2.54. 13 HT Capabilities The HT Capabilities element is present when dot11HighThroughputOptionImplemented is true. The HT Capabilities element is defined in 9.4.2.56. 14 20/40 BSS Coexistence The 20/40 BSS Coexistence element is present when dot112040BSSCoexistenceManagementSupport is true. The 20/40 BSS Coexistence element is defined in 9.4.2.60. 15 Link Identifier The Link Identifier element is defined in 9.4.2.62. 16 Multi-band The Multi-band element is optionally present if dot11MultibandImplemented is true. 17 VHT Capabilities VHT Capabilities element (optional). The VHT Capabilities element is present if the dot11VHTOptionImplemented is true. The VHT Capabilities element is defined in 9.4.2.158. The TDLS Discovery Response frame is transmitted directly (i.e., not via the AP) to the TDLS peer STA that sent the corresponding TDLS Discovery Request frame. See 11.23. 9.6.8.17 Location Track Notification frame format The Location Track Notification frame uses the Action frame body format and is transmitted to allow remote location determination to occur by another STA. The format of the Location Track Notification Action field is shown in Figure 9-671. Public Location Parameters Measurement Report Category Action Element Element (optional) Octets: 1 1 variable variable Figure 9-671â€”Location Track Notification Action field format The Category field is defined in 9.4.1.11. 1191 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Public Action field is defined in 9.6.8.1. The Location Parameters Element field contains the Location Parameters subelements, described in Table 9- 191. Table 9-318 defines the allowed Location Parameters subelements for a Location Parameters element that is included in the frame. Table 9-318â€”Location Parameters Element field for Location Track Notification frame Allowed Subelement Notes subelements ID Location Indication 2 The Location Indication Channels subelement is included in the Location Channels Track Notification frame. Radio Information 4 The Radio subelement is included in the Location Track Notification frame. Motion 5 The Motion subelement is included in the Location Track Notification frame if dot11MotionDetectionActivated is true. Time of Departure 7 The Time of Departure subelement is included in the Location Track Notification frame if dot11TODActivated is true. Location Indication 8 The Location Indication Options subelement is included in the Location Options Track Notification frame if the successful Location Configuration Request frame that configured the STA included a Location Indication Options subelement. The Measurement Report Element field contains a Measurement Report element of type Beacon report as defined in 9.4.2.22.7. The Measurement Report Element field is included in the Location Track Notification frame if the Location Parameters Element field contains a Location Indication Options subelement. The Measurement Report element Measurement Token field is set to the same value of the dialog token in the Location Configuration Request frame that configured the STA. 9.6.8.18 QMF Policy frame format The QMF Policy frame uses the Action frame format and is transmitted by a requesting STA to a receiving STA with the included QMF policy. It is either sent unsolicited by the requesting STA or in response to a QMF Policy Change frame from a receiving STA. The format of the Action field of the QMF Policy frame is shown in Figure 9-672. Category Public Action Dialog Token Status Code QMF Policy element (optional) Octets: 1 1 1 2 0 or 3-257 Figure 9-672â€”QMF Policy frame Action field contents The Category field is defined in 9.4.1.11. The Public Action field is defined in 9.6.8.1. The Dialog Token field is set to the value in the corresponding QMF Policy Change frame. If the QMF Pol- icy frame is not being transmitted in response to a QMF Policy Change frame, then the Dialog Token field is set to 0. 1192 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Status Code field is defined in Table 9.4.1.9. The QMF Policy element is set as described in 9.4.2.120. It indicates the new access categories configured for Management frame(s). This field is included if the Status Code is SUCCESS and this frame is not being transmitted in response to a QMF Policy Change frame, and optionally included if the Status Code is REQUEST_DECLINED. 9.6.8.19 QMF Policy Change frame format The QMF Policy Change frame uses the Action frame format and is transmitted by a requesting STA to request a change to the QMF policy it most recently received from the destination STA. The format of the Action field of the QMF Policy Change frame is shown in Figure 9-673. Category Public Action Dialog Token QMF Policy element Octets: 1 1 1 3-257 Figure 9-673â€”QMF Policy Change Action field contents The Category field is defined in 9.4.1.11. The Public Action field is defined in 9.6.8.1. The Dialog Token field is set to a nonzero value chosen by the STA sending the QMF Policy Change frame to identify the transaction. The QMF Policy element is set as described in 9.4.2.120. It indicates the access categories requested for Management frame(s), including any changes to the QMF policy it most recently received from the destina- tion STA. 9.6.8.20 QLoad Request frame format The QLoad Request frame is transmitted by an AP to request information from another AP. The Action field format of the QLoad Request frame is shown in Table 9-319. Table 9-319â€”QLoad Request frame Action field format Order Information 1 Category 2 Public Action 3 Dialog Token 4 QLoad Report element The Category field is defined in 9.4.1.11. The Public Action field is defined in 9.6.8.1. The Dialog Token field is defined in 9.4.1.12 and set by the requesting STA to a nonzero value that is used for matching action responses with action requests. See 10.27.5. 1193 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The QLoad Report element is defined in 9.4.2.123 and contains the QLoad report corresponding to the AP sending the request. 9.6.8.21 QLoad Report frame format The QLoad Report frame is transmitted by an AP responding to a QLoad Request frame. The Action field format of the QLoad Report frame is shown in Table 9-320. Table 9-320â€”QLoad Report frame Action field format Order Information 1 Category 2 Public Action 3 Dialog Token 4 QLoad Report element The Category field is defined in 9.4.1.11. The Public Action field is defined in 9.6.8.1. The Dialog Token field is defined in 9.4.1.12 and set by the requesting STA to a nonzero value that is used for matching action responses with action requests. See 10.27.5. The Dialog Token field is set to 0 when an unsolicited QLoad Report frame is sent by the AP. The QLoad Report element is defined in 9.4.2.123. 9.6.8.22 HCCA TXOP Advertisement frame The HCCA TXOP Advertisement frame is transmitted by an AP to another AP to inform it of active and pending TXOP reservations. The Action field format of the HCCA TXOP Advertisement frame is shown in Figure 9-674. Number of Number of Active Pending Public Dialog Reported Pending Category Action Token TXOP TXOP TXOP TXOP Reservations Reservations Reservations Reservations Octets: 1 1 1 1 1 variable variable Figure 9-674â€”HCCA TXOP Advertisement frame Action field format The Category field is defined in 9.4.1.11. The Public Action field is defined in 9.6.8.1. The Dialog Token field is defined in 9.4.1.12 and is set by the AP to a nonzero value that is used for matching action responses with action requests. See 10.27.5. 1194 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Number of Reported TXOP Reservations field is 1 octet in length and contains a positive integer that specifies the number of active TXOP reservations reported in this frame. A value of 0 indicates that no TXOP reservations are active. The Number of Pending Reported TXOP Reservations field is 1 octet in length and contains a positive integer that specifies the number of pending TXOP reservations reported in this frame. A value of 0 indicates that no TXOP reservations are in the process of being activated. The Active TXOP Reservation field contains zero or more TXOP Reservation fields as defined in 9.4.1.44. This field indicates active HCCA TXOPs that the AP has scheduled. The Start Time subfield of the TXOP Reservation field is relative to the TSF of the sending AP. The Pending TXOP Reservation field contains zero or more TXOP Reservation fields as defined in 9.4.1.44. This field indicates new HCCA TXOPs that the AP is scheduling. The Start Time subfield of the TXOP Reservation field is relative to the TSF of the sending AP. The use of the HCCA TXOP Advertisement frame is described in 11.28.3. 9.6.8.23 HCCA TXOP Response frame The HCCA TXOP Response frame is transmitted by an AP to another AP to respond to an HCCA TXOP Advertisement frame. The Action field format of the HCCA TXOP Response frame is shown in Figure 9- 675. Public Dialog Schedule Alternate Avoidance Category Action Token Status Code Conflict Schedule Request Octets: 1 1 1 2 0 or 1 0 or 6 0 or 6 Figure 9-675â€”HCCA TXOP Response frame Action field format The Category field is defined in 9.4.1.11. The Public Action field is defined in 9.6.8.1. The Dialog Token field is set to the value of the Dialog Token field from the corresponding HCCA TXOP Advertisement frame. The Status Code field is defined in 9.4.1.9 and is set to either the value SUCCESS or TS_SCHEDULE_CONFLICT. The Schedule Conflict field is present only when the Status Code field is not SUCCESS. The Schedule Conflict field indicates the TXOP reservation from the HCCA TXOP Advertisement frame that conflicts with an existing or in-progress schedule. Its value is between 1 and the summation of the values from the Number of Reported TXOP Reservations and Number of Pending TXOP Reservations fields of the HCCA TXOP Advertisement frame. A value of 1 indicates the first TXOP reservation in the HCCA TXOP Advertisement frame, a value of 2 indicates the second TXOP reservation in the HCCA TXOP Advertisement frame, and so on. The value of zero is reserved. The optional Alternate Schedule field contains a TXOP Reservation field, as defined in 9.4.1.44 and is present only when the Status Code field is not SUCCESS. When the Alternate Schedule field is present, it contains an alternate to the TXOP reservation given in the corresponding HCCA TXOP Advertisement frame. The Start Time subfield of the Alternate Schedule field is relative to the TSF of the destination AP. 1195 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The optional Avoidance Request field contains a TXOP Reservation field, as defined in 9.4.1.44 and is optionally present when the Status Code field is not SUCCESS. When the Avoidance Request field is present, it indicates a TXOP schedule that the AP sending the TXOP Response frame is requesting to be avoided by the AP that is the destination of the TXOP Response frame. The Start Time subfield of the Avoidance Request field is relative to the TSF of the destination AP. The use of the HCCA TXOP Response frame is described in 11.28.3. 9.6.8.24 Public Key frame The Public Key frame is transmitted by an AP to provide its public key to peer APs and to request the peerâ€™s public key. The format of the Public Key Action field is defined in Figure 9-676. Category Public Public Key Group Public Key Action Frame Usage (optional) Octets: 1 1 1 2 variable Figure 9-676â€”Public Key Action field format The Category field is defined in 9.4.1.11. The Public Action field is defined in 9.6.8.1. The Public Key Frame Usage field is set to a number to signify the usage mode of this frame. The Request Types are shown in Table 9-321. Table 9-321â€”Public Key Frame Usage field values Public Key Frame Usage Value Request 0 Response 1 NAK 2 Refused 3 Reserved 4â€“255 The Public Key Frame Usage field is set to â€œRequestâ€ to indicate that a public key is being requested from a peer AP. The Public Key Frame Usage field is set to â€œResponseâ€ to indicate that this frame is in response to a Public Key frame. The Public Key Frame Usage field is set to â€œNAKâ€ to indicate rejection of a received Public Key frame. The Group field is used to indicate which cryptographic group was used when generating the public key and is defined in 9.4.1.43), or the preferred group when the Public Key Frame Usage field is set to â€œNAKâ€. When the Public Key Frame Usage field is set to â€œNAKâ€ or â€œRefusedâ€, the Public Key field is not included. In all other cases, the Public Key field contains the public key of the AP that is sending this Public Key frame encoded as an octet string according to 12.4.7.2.5. 1196 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The use of the Public Key frame is described in 12.11. 9.6.8.25 Channel Availability Query frame format The Channel Availability Query frame is an Action frame. It is transmitted as part of channel query. The format of the Channel Availability Query frame Action field is shown in Figure 9-677. Category Public Requester Responder Reason Length Channel Device Device Device WSM Action STA STA Result Query Class Identifi- Location Informa- Address Address Code Info cation Informa- tion Informa- tion tion Octets: 1 1 6 6 1 1 1 variable variable variable variable Figure 9-677â€”Channel Availability Query frame Action field format The Category field is defined in 9.4.1.11. The Public Action field is defined in 9.6.8.1. The Length field indicates the length of the remaining frame fields in octets, and the value is variable. The remaining fields are as defined in the Channel Availability Query element (see 9.4.6.2) and White Space Map element (see 9.4.2.170). 9.6.8.26 Channel Schedule Management frame format The Channel Schedule Management frame is a Public Action frame. It is transmitted to exchange the channel schedule information as part of the channel schedule management procedure. The format of the Channel Schedule Management frame Action field is shown in Figure 9-678. Category Public Requester Responder Length Reason Channel Device Channel Action STA STA Result Schedule Identifi- Schedule Address Address Code Management cation Descriptor Mode Informa- tion Octets: 1 1 6 6 1 1 1 variable variable Figure 9-678â€”Channel Schedule Management frame Action field format The Category field is defined in 9.4.1.11. The Public Action field is defined in 9.6.8.1. The Requester STA Address field is the MAC address of the requesting STA that initiates the Channel Schedule Management process. The Responder STA Address field is the MAC address of the STA that responds to the STA that requested channel schedule management. The Length field indicates the length of the remaining fields in octets, and the value is variable. The Reason Result Code field indicates the reason for transmitting a query request for channel schedule information. It also indicates the result of a query as successful or not and the reason when the query is not successful. The value of this field is defined in Table 9-322. 1197 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-322â€”Reason Result Code field values Reason Result Description Code field values 0 Request for channel schedule information from a RLSS. 1 Request for channel schedule information from a GDD enabling STA. 2 Success, returning full channel schedule information on the requested channels. 3 Success, returning additional timeslots from the list of the last query on the requested channels. 4 Success, returning timeslots deleted from the list of last query on the requested channels. 5 Success, returning deleted and added timeslots from the list of last query on the requested channels. 6 Success, returning no channel schedule changes from last query. 7 Request declined by the GDD enabling STA for unspecified reason. 8 Request declined by the GDD enabling STA because of no capability for providing schedule information on WLAN channels. 9 Request declined by RLSS for unspecified reason. 10 Request declined by RLSS because of no capability for providing schedule information on WLAN channels. 11 Unknown reason. 12 Continuation frame. This frame continues the fields from the previous CSM frame. 13â€“63 Reserved. The Channel Schedule Management Mode field indicates if the schedule information of the channel availability is based on TV channels or WLAN channels. If the schedule information is based on WLAN channels, the optional Operating Class field is present in the Channel Schedule Descriptor field as defined in E.1. This field also indicates whether the optional Channel Availability Starting Time field is present in the Channel Schedule Descriptor field. The value of this field is defined in Table 9-323. Table 9-323â€”Channel Schedule Management Mode field values Channel Schedule Description Management Mode value 0 The channel schedule information is based on TV channels. The Reason Result Code field is set to either 0 or 1. 1 The channel schedule information is based on WLAN channels. The Reason Result Code field is set to either 0 or 1. 2â€“3 Reserved. 1198 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Device Identification Information field indicates the regulatory identification of the STA that is requesting the schedule information. The Device Identification Information field is present only when Reason Result Code is either 0 or 1. The value of the field is defined in 9.4.4.2.2. The Channel Schedule Descriptor field indicates the channels for which the schedule information is requested, and the channel schedule information is provided in the response. The value of the field is defined in 9.4.4.2.4. The Channel Schedule Descriptor field is repeated, as determined by the Length field. 9.6.8.27 Contact Verification Signal frame format The Contact Verification Signal frame is a Public Action frame that is transmitted by a GDD enabling STA to notify whether the available channel information from the GDB has been updated. The format of the Contact Verification Signal frame Action field is shown in Figure 9-679. Category Public Action Map ID Octets: 1 1 1 Figure 9-679â€”Contact Verification Signal frame Action field format The Category field is defined in 9.4.1.11. The Public Action field is defined in 9.6.8.1. The Map ID field is set to a number that is equal to the Map ID of the recently received WSM. The WSM is defined in Table 9-269 in 9.4.4.2.5. 9.6.8.28 GDD Enablement Request frame format The GDD Enablement Request frame is a Public Action frame. The format of the GDD Enablement Request frame action field is shown in Figure 9-680. Category Public Action Dialog Token Device Class Device Identification Information Octets: 1 1 1 1 variable Figure 9-680â€”GDD Enablement Request frame Action field format The Category field is defined in 9.4.1.11. The Public Action field is defined in 9.6.8.1. The Dialog Token field is a nonzero value chosen by the STA sending the GDD Enablement Request frame to identify the request/response transaction. The Device Class field is used to indicate the characteristic of the STA requesting the GDD Enablement Request frame. The format of the Device Class field is specified in 9.4.4.2.1. The Device Identification Information field is used to indicate the identification of the STA requesting the GDD Enablement Request frame. The format of the Device Identification Information field is specified in 9.4.4.2.2. 1199 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.6.8.29 GDD Enablement Response frame format The GDD Enablement Response frame is a Public Action frame. The format of the GDD Enablement Response frame action field is shown in Figure 9-681. Category Public Action Dialog Token Status Code WSM Information Octets: 1 1 1 2 variable Figure 9-681â€”GDD Enablement Response frame Action field format The Category field is defined in 9.4.1.11. The Public Action field is defined in 9.6.8.1. The Dialog Token field is a nonzero value of the corresponding GDD Enablement Request frame. If a GDD Enablement Response frame is being transmitted other than in response to an GDD Enablement Request frame, then the Dialog Token field is 0. The Status Code field contains the status code in response to a GDD Enablement Request frame as defined in Table 9-46. The remaining field is as defined in the WSM element (see 9.4.2.170). 9.6.8.30 Network Channel Control frame format The Network Channel Control frame is a Public Action frame. It is transmitted by a GDD dependent STA and a GDD enabling STA as part of the procedure that allows a GDD enabling STA to control the frequency usage of a GDD dependent STAâ€™s WLAN network channels. The format of the Network Channel Control frame is shown in Figure 9-682. a Network Channel Control triplet Category Public Length Requester Responder Reason Number of Operating Channel Maximum Action STA STA Result Network Class Number Transmit Address Address Code Channel Power Control Triplets Octets: 1 1 1 6 6 1 1 1 1 1 Figure 9-682â€”Network Channel Control frame Action field format The Category field is defined in 9.4.1.11. The Public Action field is defined in 9.6.8.1. The Length field indicates the length of the remaining frame fields in octets, and the value is variable. The minimum value of the Length field is 14. The Requester STA Address field is the MAC address of the requesting STA that initiates the network channel control process. The Responder STA Address field is the MAC address of the STA that responds to the STA that requested network channel control. 1200 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Reason Result Code field is used to indicate the reason that a Network Channel Control frame was generated. The length of the Reason Result Code field is 1 octet. The encoding of the Reason Result Code field is shown in Table 9-282. The Number of Network Channel Control Triplets field indicates the number of triplets of Operating Class, Channel Number, and Maximum Transmit Power fields. The Operating Class field indicates the channel set for which the network channel control request applies. The Operating Class and Channel Number fields together specify the channel frequency and channel bandwidth for which the network channel control applies. Values for the Operating Class field are shown in E.1. In a request, the Channel Number field of the Network Channel Control frame indicates the channel that the requesting STA intends to operate on. In the response, the Channel Number field in the Network Channel Control frame indicates the channels that the responding STA permits the requesting STA to operate on. The Channel Number is defined within an Operating Class as shown in E.1. The Maximum Transmit Power field gives the intended maximum transmit power in dBm for operation in the request frame and indicates the maximum allowable transmit power in dBm for operation in the response frame. The field contains EIRP per channel bandwidth and is coded as a signed integer in units of 0.5 dBm. The field is set to 0 when a requesting STA requests a responding STA to provide a network channel control response without specifying in the request the intended maximum transmit power. 9.6.8.31 White Space Map Announcement frame format The White Space Map Announcement frame is a Public Action frame. The format of the White Space Map Announcement frame body is shown in Figure 9-683. Category Public Action Reason Result White Space Code Map Octets: 1 1 1 variable Figure 9-683â€”White Space Map Announcement frame Action field format The Category field is defined in 9.4.1.11. The Public Action field is defined in 9.6.8.1. A Reason Result Code value of 1 indicates the Public Action frame is a continuation of the previous WSM Public Action frame, and any other value indicates this is not a continuation of the previous WSM Public Action frame. The White Space Map field contains a White Space Map element (see 9.4.2.170). 9.6.8.32 Fine Timing Measurement Request frame format The format of the Fine Timing Measurement Request Action field is shown in Figure 9-684. 1201 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications LCI Location Civic Fine Timing Public Measurement Measurement Measurement Category Trigger Action Request Request Parameters (optional) (optional) (optional) Octets: 1 1 1 variable variable variable Figure 9-684â€”Fine Timing Measurement Request Action field format The Category field is defined in 9.4.1.11. The Public Action field is defined in 9.6.8.1. The Trigger field set to 1 indicates that the initiating STA requests that the responding STA start or continue sending Fine Timing Measurement frames (see 11.24.6). The Trigger field set to 0 indicates that the initiating STA requests that the responding STA stop sending Fine Timing Measurement frames. Trigger field values 2â€“255 are reserved. The LCI Measurement Request field is optionally present. If present, it contains a Measurement Request element with Measurement Type field equal to LCI (see Table 9-82), which indicates a request for a Measurement Report element with Measurement Type field equal to LCI (see 11.24.6.7). The Enable bit in the Measurement Request Mode field in the Measurement Request element is set to 0. The Location Subject field in the Measurement Request field of the Measurement Request element is set to Location Subject Remote (see Table 9-94). The Request, Report and Duration Mandatory bits in the Measurement Request Mode field in the Measurement Request element are reserved (see 9.4.2.21.1). The Location Civic Measurement Request field is optionally present. If present, it contains a Measurement Request element with Measurement Type field equal to Location Civic (see Table 9-82), which indicates a request for a Measurement Report element with Measurement Type field equal to Location Civic (see 11.24.6.7). The Enable bit in the Measurement Request Mode field in the Measurement Request element is set to 0. The Location Subject field in the Measurement Request field of the Measurement Request element is set to Location Subject Remote (see Table 9-94). The Location Service Interval Units field in the Measurement Request field of the Measurement Request element is set to 0. The Request, Report and Duration Mandatory bits in the Measurement Request Mode field within the Measurement Request element are reserved (see 9.4.2.21.1). The Fine Timing Measurement Parameters field is present in the initial Fine Timing Measurement Request frame (see 11.24.6.3) and its retransmissions and is not present in subsequent Fine Timing Measurement Request frames. If present, it contains a Fine Timing Measurement Parameters element as defined in 9.4.2.168. 9.6.8.33 Fine Timing Measurement frame format The Fine Timing Measurement frame is used to support the FTM procedure described in 11.24.6. The format of the Fine Timing Measurement Action field is shown in Figure 9-685. 1202 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Follow Up Category Public Action Dialog Token Dialog Token TOD TOA Octets: 1 1 1 1 6 6 Fine Timing FTM Location TOD Error TOA Error LCI Report Civic Report Measurement Synchronizatio (optional) Parameters n Information (optional) (optional) (optional) Octets: 2 2 variable variable variable variable Figure 9-685â€”Fine Timing Measurement Action field format The Category field is defined in 9.4.1.11. The Public Action field is defined in 9.6.8.1. The TOD Error field is structured as shown in Figure 9-686. B0 B4 B5 B14 B15 Max TOD Error Reserved TOD Not Continuous Exponent Bits: 5 10 1 Figure 9-686â€”Format of the TOD Error field The TOA Error field is structured as shown in 9-687. B0 B4 B5 B15 Max TOA Error Reserved Exponent Bits: 5 11 Figure 9-687â€”Format of the TOA Error field The Dialog Token field is a nonzero value chosen by the responding STA to identify the Fine Timing Measurement frame as the first of a pair, with the second or follow-up Fine Timing Measurement frame to be sent later. The Dialog Token field is set to 0 to indicate the end of the FTM session (see 11.24.6.6 and 11.24.6.4). The Follow Up Dialog Token field is the nonzero value of the Dialog Token field of the last transmitted Fine Timing Measurement frame to indicate that it is the follow up Fine Timing Measurement frame and that the TOD, TOA, Max TOD Error Exponent and Max TOA Error Exponent fields contain the values of the timestamps captured with the first Fine Timing Measurement frame of the pair. The Follow Up Dialog Token field is 0 to indicate that the Fine Timing Measurement frame is not a follow up to a last transmitted Fine Timing Measurement frame. The value 0 in this field also indicates that TOD, TOA, TOD Error, and TOA Error fields are reserved. See 11.24.6. The TOD and TOA fields are expressed in units of picoseconds. The maximum errors in the TOD and TOA values are represented using the function defined in Equation (9-4). 1203 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications unknown F = 0 Fâ€“1 E max = 2 1 F 30 (9-4) 30 2 F = 31 where F is the Max Error Exponent Emax is the maximum TOD or TOA error, respectively, in units of picoseconds The TOD field contains a timestamp that represents the time, with respect to a time base, at which the start of the preamble of the last transmitted Fine Timing Measurement frame appeared at the transmit antenna connector. The TOA field contains a timestamp that represents the time, with respect to a time base, at which the start of the preamble of the Ack frame to the last transmitted Fine Timing Measurement frame arrived at the receive antenna connector. NOTEâ€”The values specified in the TOD and TOA fields are described in 6.3.70. The Max TOD Error Exponent field contains an upper bound for the error exponent in the value specified in the TOD field. NOTEâ€”For instance, a value of 2 in the Max TOD Error Exponent field indicates that the value in the TOD field has a maximum error of Â± 2 ps. The TOD Not Continuous field indicates that the TOD value is with respect to a different underlying time base than the last transmitted TOA value. It is set to 1 when a discontinuity is present. Otherwise, it is set to 0. The Max TOA Error Exponent field contains an upper bound for the error exponent in the value specified in the TOA field. A value of 0 for the Max TOD Error Exponent or the Max TOA Error Exponent field indicates that the upper bound on the error in the corresponding TOD or TOA value is unknown. A value of 31 indicates that the upper bound on the error is greater than or equal to 1.073 741 824 ms. The LCI Report field is optionally present. If present, it contains a Measurement Report element with Measurement Type field equal to LCI (see Table 9-107), which either indicates the LCI of the transmitting STA and includes the Z and Usage Rules/Policy subelement or indicates an unknown LCI (see 11.24.6.7). The Late, Incapable and Refused bits in the Measurement Report Mode field are set to 0.The Co-Located BSSID List subelement is present in the Measurement Report element with Measurement Type field equal to LCI, when there is at least one other BSS which is co-located withe the reporting BSS. The Location Civic Report field is optionally present. If present, it contains a Measurement Report element with Measurement Type field equal to Location Civic (see Table 9-107), which either indicates the Civic address of the transmitting STA or an unknown Civic address (see 11.24.6.7). The Late, Incapable and Refused bits in the Measurement Report Mode field are set to 0. The Co-Located BSSID List subelement is present in the Measurement Report element with Measurement Type field equal to LCI, when there is at least one other BSS which is co-located withe the reporting BSS. When the LCI Report field contains a Co- Located BSSID List subelement, the Co-Located BSSID List subelement is not present in the Location Civic Report field. 1204 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Fine Timing Measurement Parameters field is present in the initial Fine Timing Measurement Frame and is not present in subsequent Fine Timing Measurement frames. If present, it contains a Fine Timing Measurement Parameters element as defined in 9.4.2.168. The FTM Synchronization Information field is present in the initial Fine Timing Measurement frame and its retransmissions if any, and in the first Fine Timing Measurement frame within each burst and its retransmissions if any; otherwise it is not present. If present, it contains an FTM Synchronization Information element with a TSF Sync Info field containing the 4 least significant octets of the TSF at the responding STA corresponding to the time the responding STA received the last Fine Timing Measurement Request frame with the Trigger field equal to 1. 9.6.8.34 QAB Request frame format The QAB Request frame is transmitted by an AP to another AP to schedule quiet periods that facilitate the detection of other system operating in the same band. The format of the QAB Request frame Action field is shown in Table 9-324. Table 9-324â€”QAB Request frame Action field format Order Information 1 Category 2 Public Action 3 Dialog Token 4 RequesterAP Address 5 ResponderAP Address 6 Quiet Period Request element The Category field is defined in 9.4.1.11. The Public Action field is defined in 9.6.8.1. The Dialog Token field is set to a nonzero value chosen by the AP. The RequesterAP Address field is the MAC address of the AP that initiates the process. The length of this field is 6 octets. The ResponderAP Address field is the MAC address of the responding AP. The length of this field is 6 octets. This field can be set to the broadcast address if the request is sent to multiple APs. The Quiet Period Request element is defined in 9.4.2.150. 9.6.8.35 QAB Response frame format A QAB Response frame is sent in response to a QAB Request frame. The format of a QAB Response frame Action field contains the information shown in Table 9-325. 1205 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-325â€”QAB Response frame Action field format Order Information 1 Category 2 Public Action 3 Dialog Token 4 RequesterAP Address 5 ResponderAP Address 6 Quiet Period Response element The Category field is defined in 9.4.1.11. The Public Action field is defined in 9.6.8.1. The Dialog Token field value is copied from the corresponding received QAB Request frame. The RequesterAP Address field is the MAC address of the AP that initiates the process. The length of this field is 6 octets. The ResponderAP Address field is the MAC address of the responding AP. The length of this field is 6 octets. The Quiet Period Response element is defined in 9.4.2.151. 9.6.9 FT Action frame details 9.6.9.1 General Four Action frame formats are defined to support fast BSS transitions over the DS, which are initiated through the currently associated AP. The FT Action frames are sent over the air between the STA and the current AP. The Action frame is used as a transport mechanism for data that are destined for the target AP. An FT Action field, in the octet immediately after the Category field, differentiates the FT Action frame formats. The FT Action field values associated with each FT Action frame format are defined in Table 9-326. Table 9-326â€”FT Action field values FT Action field value Description 0 Reserved 1 FT Request frames 2 FT Response frames 3 FT Confirm frames 4 FT Ack frames 5â€“255 Reserved 1206 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.6.9.2 FT Request frame The FT Request frame is sent by the STA to its associated AP to initiate an over-the-DS fast BSS transition. Figure 9-688 shows the format of the FT Request frame Action field. Category FT Action STA Target AP FT Request frame body Address Address Octets: 1 1 6 6 variable Figure 9-688â€”FT Request frame Action field format The Category field is defined in 9.4.1.11. The FT Action field is defined in 9.6.9.1. The STA Address field is set to the fast BSS transition originatorâ€™s (FTOâ€™s) MAC address. The Target AP Address field is set to the BSSID value of the target AP. The FT Request frame body contains the information shown in Table 9-327. Table 9-327â€”FT Request frame body Order Information Notes 1 RSN A RSNE is present if dot11RSNAActivated is true. 2 Mobility Domain The MDE is present. 3 Fast BSS Transition An FTE is present if dot11RSNAActivated is true. The usage of these elements is defined in 13.8.2. 9.6.9.3 FT Response frame The FT Response frame is transmitted by the currently associated AP as a response to the STAâ€™s FT Request frame. Figure 9-689 shows the format of the FT Response frame Action field. FT STA Target AP Status Category FT Response frame body Action Address Address Code Octets: 1 1 6 6 2 variable Figure 9-689â€”FT Response frame Action field format The Category field is defined in 9.4.1.11. The FT Action field is defined in 9.6.9.1. The STA Address field is set to the FTOâ€™s MAC address. 1207 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Target AP Address field is set to the BSSID value of the target AP. The Status Code field is a value from the options listed in 9.4.1.9. If the Status Code field is SUCCESS, then the FT Response frame body contains the information shown in Table 9-328. Table 9-328â€”FT Response frame body Order Information Notes 1 RSN The RSNE is present if dot11RSNAActivated is true. 2 Mobility Domain The MDE is present. 3 Fast BSS Transition An FTE is present if dot11RSNAActivated is true. The usage of these elements is defined in 13.8.3. 9.6.9.4 FT Confirm frame The FT Confirm frame in an RSN is confirmation to the target AP of receipt of the ANonce and indicates the liveness of the PTKSA. The FT Confirm frame is optionally used by the FTO to request resources. Figure 9- 690 shows the FT Confirm frame Action field format. STA Target AP Category FT Action FT Confirm frame body Address Address Octets: 1 1 6 6 variable Figure 9-690â€”FT Confirm frame Action field format The Category field is defined in 9.4.1.11. The FT Action field is defined in 9.6.9.1. The STA Address field is set to the FTOâ€™s MAC address. The Target AP Address field is set to the BSSID value of the target AP. The FT Confirm frame body contains the information shown in Table 9-329. Table 9-329â€”FT Confirm frame body Order Information Notes 1 RSN The RSNE is present if dot11RSNAActivated is true. 2 Mobility Domain The MDE is present. 3 Fast BSS Transition An FTE is present if dot11RSNAActivated is true. 4 RIC The RIC Request field is present if resources are being requested. 1208 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The usage of these elements is defined in 13.8.4. 9.6.9.5 FT Ack frame The FT Ack frame is transmitted by the currently associated AP as a response to the STAâ€™s FT Confirm frame. Figure 9-691 shows the FT Ack frame Action field format. FT STA Target Status Category AP FT Ack frame body Action Address Address Code Octets 1 1 6 6 2 variable Figure 9-691â€”FT Ack frame Action field format The Category field is defined in 9.4.1.11. The FT Action field is defined in 9.6.9.1. The STA Address field is set to the FTOâ€™s MAC address. The Target AP Address field is set to the BSSID value of the target AP. The Status Code field is a value from the options listed in 9.4.1.9. If the Status Code field is SUCCESS, then the FT Ack frame body contains the information shown in Table 9-330. Table 9-330â€”FT Ack frame body Order Information Notes 1 RSN The RSNE is present if dot11RSNAActivated is true. 2 Mobility Domain The MDE is present. 3 Fast BSS Transition An FTE is present if dot11RSNAActivated is true. 4 Timeout Interval A TIE containing the reassociation deadline interval is present if (reassociation deadline) resources were requested in the FT Confirm frame and dot11RSNAActivated is false. 5 RIC The RIC Response field is present if resources were requested in the FT Confirm frame. The usage of these elements is defined in 13.8.5. 9.6.10 SA Query Action frame details 9.6.10.1 General Two Action frame formats are defined for the SA Query procedure. A SA Query Action field, in the octet field immediately after the Category field, differentiates the formats. The Action field values associated with each frame format are defined in Table 9-331. 1209 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NOTEâ€”The SA query functionality defined in this standard is used to prevent the Association Lockout problem (defined in 11.3). Table 9-331â€”SA Query Action field values SA Query Action Description field value 0 SA Query Request 1 SA Query Response 9.6.10.2 SA Query Request frame The SA Query Request frame is used to request a SA Query Response from the receiving STA. The format of the Action field is shown in Figure 9-692. Transaction Category SA Query Action Identifier Octets: 1 1 2 Figure 9-692â€”SA Query Request frame Action field format The Category field is defined in 9.4.1.11. The SA Query Action field is defined in 9.6.10.1. The Transaction Identifier field is a 16-bit non-negative counter value set by the STA sending the SA Query Request frame to identify any outstanding request/response transaction. 9.6.10.3 SA Query Response frame The SA Query Response frame is used to respond to an SA Query Request frame from another STA. The format of the Action field is shown in Figure 9-693. Transaction Category SA Query Action Identifier Octets: 1 1 2 Figure 9-693â€”SA Query Response frame Action field format The Category field is defined in 9.4.1.11. The SA Query Action field is defined in 9.6.10.1. The Transaction Identifier field is set to the same value as the Transaction Identifier field in the corresponding SA Query Request frame. 1210 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.6.11 Protected Dual of Public Action frames The Protected Dual of Public Action frame is defined to allow robust STA-STA communications of the same information that is conveyed in Action frames that are not robust (see 9.4.1.11). A Public Action field, in the octet immediately after the Category field, differentiates the Protected Dual of Public Action frame formats. The defined Protected Dual of Public Action frames are listed in Table 9-332. The Protected Dual of Public Action frames have the same format as the corresponding nonprotected Public Action frame. Table 9-332â€”Public Action field values defined for Protected Dual of Public Action frames Public Action field value Description Defined in 0 Reserved 1 Protected DSE Enablement 9.6.8.4 2 Protected DSE Deenablement 9.6.8.5 3 Reserved 4 Protected Extended Channel Switch Announcement 9.6.8.7 5 Protected Measurement Request 9.6.8.8 6 Protected Measurement Report 9.6.8.9 7 Reserved 8 Protected DSE Power Constraint 9.6.8.10 9 Protected Vendor Specific 9.6.8.11 10 Protected GAS Initial Request 9.6.8.12 11 Protected GAS Initial Response 9.6.8.13 12 Protected GAS Comeback Request 9.6.8.14 13 Protected GAS Comeback Response 9.6.8.15 14â€“17 Reserved 16 QAB Request 9.6.8.34 17 QAB Response 9.6.8.35 18 Protected QMF Policy 9.6.8.18 19 Protected QMF Policy Change 9.6.8.19 20 Protected QLoad Request 9.6.8.20 21 Protected QLoad Report 9.6.8.21 22 Protected HCCA TXOP Advertisement 9.6.8.22 23 Protected HCCA TXOP Response 9.6.8.23 24 Reserved 25 Protected Channel Availability Query 9.6.8.25 26 Protected Channel Schedule Management 9.6.8.26 27 Protected Contact Verification Signal 9.6.8.27 28 Protected GDD Enablement Request 9.6.8.28 1211 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-332â€”Public Action field values defined for Protected Dual of Public Action frames (continued) Public Action field value Description Defined in 29 Protected GDD Enablement Response 9.6.8.29 30 Protected Network Channel Control 9.6.8.30 31 Protected White Space Map Announcement 9.6.8.31 32â€“255 Reserved 9.6.12 HT Action frame details 9.6.12.1 HT Action field Several Action frame formats are defined to support HT features. An HT Action field, in the octet immediately after the Category field, differentiates the HT Action frame formats. The HT Action field values associated with each frame format within the HT category are defined in Table 9-333. The frame formats are defined in 9.6.12.2 to 9.6.12.9. Table 9-333â€”HT Action field values HT Action field value Meaning Time priority 0 Notify Channel Width No 1 SM Power Save No 2 PSMP Yes 3 Set PCO Phase Yes 4 CSI Yes 5 Noncompressed Beamforming Yes 6 Compressed Beamforming Yes 7 ASEL Indices Feedback Yes 8â€“255 Reserved â€” 9.6.12.2 Notify Channel Width frame format A STA sends the Notify Channel Width frame to another STA if it wants to change the channel width of frames that the other STA sends to it. See definition in 11.16.2. The format of the Notify Channel Width frame Action field is defined in Table 9-334. This frame can be sent by both non-AP STA and AP. The Category field is defined in 9.4.1.11. The HT Action field is defined in 9.6.12.1. 1212 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-334â€”Notify Channel Width frame Action field format Order Information 1 Category 2 HT Action 3 Channel Width (see 9.4.1.21) 9.6.12.3 SM Power Save frame format The SM Power Save frame is of category HT. The SM Power Save frame is used to manage SM power- saving state transitions as defined in 11.2.6. The Action field of the SM Power Save frame is defined in Table 9-335. Table 9-335â€”SM Power Save frame Action field format Order Information 1 Category 2 HT Action 3 SM Power Control (see 9.4.1.23) The Category field is defined in 9.4.1.11. The HT Action field is defined in 9.6.12.1. 9.6.12.4 PSMP frame format PSMP is an Action frame of category HT. The DA field of this frame is a group address. (See 10.29.2.8.) The PSMP Parameter Set field and PSMP STA Info fields define zero or more PSMP-DTT and PSMP-UTT time allocations that follow immediately after the PSMP frame. The Action field of this frame is defined in Table 9-336. The PSMP Parameter Set field is followed by zero or more PSMP STA Info fields. The Category field is defined in 9.4.1.11. The HT Action field is defined in 9.6.12.1. The PSMP STA Info fields within a PSMP frame are ordered by STA_INFO Type as follows: group addressed (STA_INFO Type=1) and then individually addressed (STA_INFO Type=2). 1213 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-336â€”PSMP frame Action field format Order Information 1 Category 2 HT Action 3 PSMP Parameter Set (see 9.4.1.25) 4 PSMP STA Info (see 9.4.1.26) Repeated N_STA times (N_STA is a subfield of the PSMP Parameter Set field) 9.6.12.5 Set PCO Phase frame format The PCO mechanism is obsolete. Consequently, this subclause might be removed in a later revision of this standard. Set PCO Phase is an Action frame of category HT that announces the phase change between 20 MHz and 40 MHz. The format of its Action field is defined in Table 9-337. The operation of the PCO feature is defined in 11.17. Table 9-337â€”Set PCO Phase frame Action field format Order Information 1 Category 2 HT Action 3 PCO Phase Control (see 9.4.1.24) The Category field is defined in 9.4.1.11. The HT Action field is defined in 9.6.12.1. This frame is sent by a PCO active AP. 9.6.12.6 CSI frame format The CSI frame is an Action or an Action No Ack frame of category HT. The format of its Action field is defined in Table 9-338. Table 9-338â€”CSI frame Action field format Order Information 1 Category 2 HT Action 3 MIMO Control (see 9.4.1.27) 4 CSI Report (see 9.4.1.28) 1214 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Category field is defined in 9.4.1.11. The HT Action field is defined in 9.6.12.1. In a CSI frame, the fields of the MIMO Control field (see 9.4.1.27) are used as described in Table 9-51. The Codebook Information subfield is reserved in this frame. 9.6.12.7 Noncompressed Beamforming frame format The Noncompressed Beamforming frame is an Action or an Action No Ack frame of category HT. The format of its Action field is defined in Table 9-339. Table 9-339â€”Noncompressed Beamforming frame Action field format Order Information 1 Category 2 HT Action 3 MIMO Control (see 9.4.1.27) 4 Noncompressed Beamforming Report (see 9.4.1.29) The Category field is defined in 9.4.1.11. The HT Action field is defined in 9.6.12.1. In a Noncompressed Beamforming frame, the fields of the MIMO Control field (see 9.4.1.27) are used as described in Table 9-51. The Codebook Information subfield is reserved in this frame. 9.6.12.8 Compressed Beamforming frame format The Compressed Beamforming frame is an Action or an Action No Ack frame of category HT. The format of its Action field is defined in Table 9-340. Table 9-340â€”Compressed Beamforming frame Action field format Order Information 1 Category 2 HT Action 3 MIMO Control (see 9.4.1.27) 4 Compressed Beamforming Report (see 9.4.1.30) The Category field is defined in 9.4.1.11. The HT Action field is defined in 9.6.12.1. In a Compressed Beamforming frame, the fields of the MIMO Control field (see 9.4.1.27) are used as described in Table 9-51. The Coefficient Size subfield is reserved in this frame. 1215 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.6.12.9 Antenna Selection Indices Feedback frame format The Antenna Selection Indices Feedback frame is an Action or Action No Ack frame of category HT. The format of its Action field is defined in Table 9-341. Table 9-341â€”Antenna Selection Indices Feedback frame Action field format Order Information 1 Category 2 HT Action 3 Antenna Selection Indices (see 9.4.1.31) The Category field is defined in 9.4.1.11. The HT Action field is defined in 9.6.12.1. 9.6.13 TDLS Action field formats 9.6.13.1 General Several Action field formats are defined to support TDLS. A TDLS Action field, in the octet immediately after the Category field, differentiates the TDLS Action field formats. The TDLS Action field values associated with each Action field format within the TDLS category are defined in Table 9-342. Table 9-342â€”TDLS Action field values Action field value Meaning 0 TDLS Setup Request 1 TDLS Setup Response 2 TDLS Setup Confirm 3 TDLS Teardown 4 TDLS Peer Traffic Indication 5 TDLS Channel Switch Request 6 TDLS Channel Switch Response 7 TDLS Peer PSM Request 8 TDLS Peer PSM Response 9 TDLS Peer Traffic Response 10 TDLS Discovery Request 11â€“255 Reserved References to one of the TDLS Action field values as a frame, e.g., â€œTDLS Setup Request frame,â€ denote a Data frame carrying a TDLS Action field and any vendor-specific elements tunneled as described in 11.23.1. 1216 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.6.13.2 TDLS Setup Request Action field format The Action field of a TDLS Setup Request Action field contains the information shown in Table 9-343. Table 9-343â€”Information for TDLS Setup Request Action field Order Information Notes 1 Category The Category field is defined in 9.4.1.11. 2 TDLS Action The TDLS Action field is defined in 9.6.13.1. 3 Dialog Token The Dialog Token field contains a unique nonzero value for the conversation between the STAs involved in this request. The dialog token is specified in 9.4.1.12. 4 Capability The Capability field indicates the capabilities of the STA. The Capability field is defined in 9.4.1.4. 5 Supported Rates and BSS The Supported Rates and BSS Membership Selectors element Membership Selectors indicates the rates that are supported by the STA. The Supported Rates and BSS Membership Selectors element is defined in 9.4.2.3. 6 Country The Country element is present when dot11MultiDomainCapabilityActivated is true or dot11SpectrumManagementRequired is true. The Country element is defined in 9.4.2.9. 7 Extended Supported Rates The Extended Supported Rates and BSS Membership and BSS Membership Selectors element is present whenever there are more than Selectors eight supported rates, and it is optionally present otherwise. The Extended Supported Rates and BSS Membership Selectors element is defined in 9.4.2.13. 8 Supported Channels The Supported Channels element is present if the TDLS channel switching capability field is equal to 1. The Supported Channels element is defined in 9.4.2.18. 9 RSNE The RSNE is present if security is required on the direct link. The RSNE is defined in 9.4.2.25. 10 Extended Capabilities The Extended Capabilities element is optionally present if any of the fields in this element are nonzero. The Extended Capabilities element is defined in 9.4.2.27. 11 QoS Capability The QoS Capability element is present when dot11QosOptionImplemented is true and not present otherwise. The QoS Capability element is defined in 9.4.2.35. 12 FTE The FTE is present if security is required on the TDLS direct link. The FTE is defined in 9.4.2.48. 13 Timeout Interval (TPK key The Timeout Interval element contains the TPK key lifetime lifetime) and is present if security is required on the direct link. The Timeout Interval element is defined in 9.4.2.49. 14 Supported Operating Classes The Supported Operating Classes element is present if the TDLS channel switching capability field is equal to 1. The Supported Operating Classes element is defined in 9.4.2.54 (optional). 15 HT Capabilities The HT Capabilities element is defined in 9.4.2.56. The HT Capabilities element is present when dot11HighThroughputOptionImplemented is true. 1217 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-343â€”Information for TDLS Setup Request Action field (continued) Order Information Notes 16 20/40 BSS Coexistence The 20/40 BSS Coexistence element is defined in 9.4.2.60. The 20/40 BSS Coexistence element is optionally present. 17 Link Identifier The Link Identifier element is specified in 9.4.2.62. 18 Multi-band The Multi-band element is optionally present if dot11MultibandImplemented is true. 19 AID The AID element containing the AID of the STA sending the frame is present if dot11VHTOptionImplemented is true. 20 VHT Capabilities The VHT Capabilities element is present if the dot11VHTOptionImplemented is true. The TDLS Setup Request Action field is encapsulated in a Data frame and transmitted to the recipient STA through the AP to request the setup of a TDLS direct link. See 11.23. 9.6.13.3 TDLS Setup Response Action field format The Action field of a TDLS Setup Response Action field contains the information shown in Table 9-344. Table 9-344â€”Information for TDLS Setup Response Action field Order Information Notes 1 Category The Category field is defined in 9.4.1.11. 2 TDLS Action The TDLS Action field is defined in 9.6.13.1. 3 Status Code The Status Code is defined in 9.4.1.9. 4 Dialog Token The dialog token is copied from the corresponding TDLS Setup Request. The dialog token is specified in 9.4.1.12. 5 Capability The Capability field indicates the capabilities of the STA and is present when the Status Code is SUCCESS and is not present otherwise. The Capability field is defined in 9.4.1.4. 6 Supported Rates and BSS The Supported Rates and BSS Membership Selectors element Membership Selectors indicates the rates that are supported by the STA and is present when the Status Code is SUCCESS and is not present otherwise.The Supported Rates and BSS Membership Selectors element is defined in 9.4.2.3. 7 Country The Country element is present when Status Code is SUCCESS and either dot11MultiDomainCapabilityActivated is true or dot11SpectrumManagementRequired is true and is not present otherwise. The Country element is defined in 9.4.2.9 8 Extended Supported Rates The Extended Supported Rates and BSS Membership Selectors and BSS Membership element is present when there are more than 8 supported rates and Selectors Status Code is SUCCESS. It is optionally present when there are less than 8 supported rates and Status Code is SUCCESS. Otherwise it is not present. The Extended Supported Rates and BSS Membership Selectors element is defined in 9.4.2.13. 1218 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-344â€”Information for TDLS Setup Response Action field (continued) Order Information Notes 9 Supported Channels The Supported Channels element is defined in 9.4.2.18. It is present if the TDLS channel switching capability bit is equal to 1 and the Status Code is SUCCESS, and not present otherwise. 10 RSNE The RSNE is present if security is required on the TDLS direct link and the Status Code is SUCCESS, and not present otherwise. The RSNE is defined in 9.4.2.25. 11 Extended Capabilities The Extended Capabilities element is present if any of the fields in this element are nonzero and the Status Code is SUCCESS, and not present otherwise. The Extended Capabilities element is defined in 9.4.2.27. 12 QoS Capability The QoS Capability element is present when dot11QosOptionImplemented is true and the Status Code is SUCCESS and not present otherwise. The QoS Capability element is defined in 9.4.2.35. 13 FTE The FTE is present if security is required on the TDLS direct link and the Status Code is SUCCESS, and not present otherwise. The FTE is defined in 9.4.2.48. 14 Timeout Interval (TPK key The Timeout Interval element, containing the TPK key lifetime, lifetime) is present if security is required on the direct link and the Status Code is SUCCESS, and not present otherwise. The Timeout Interval element is defined in 9.4.2.49. 15 Supported Operating Classes The Supported Operating Classes element is present if the TDLS channel switching capability bit is equal to 1 and the Status Code is SUCCESS and not present otherwise. The Supported Operating Classes element is defined in 9.4.2.54. 16 HT Capabilities The HT Capabilities element is present if dot11HighThroughputOptionImplemented is true and the Status Code is SUCCESS and is not present otherwise. The HT Capabilities element is defined in 9.4.2.56. 17 20/40 BSS Coexistence The 20/40 BSS Coexistence element is optionally present if the Status Code is SUCCESS and not present otherwise. The 20/40 BSS Coexistence element is defined in 9.4.2.60. 18 Link Identifier The Link Identifier element is present if the Status Code is SUCCESS and not present otherwise. The Link Identifier is specified in 9.4.2.62. 19 Multi-band The Multi-band element is optionally present if dot11MultibandImplemented is true and the Status Code is SUCCESS and not present otherwise. 20 AID The AID element containing the AID of the STA sending the frame is present if dot11VHTOptionImplemented is true and the Status Code is SUCCESS and not present otherwise. 21 VHT Capabilities The VHT Capabilities element is present if the dot11VHTOptionImplemented is true and the Status Code is SUCCESS and not present otherwise. 22 Operating Mode Notification The Operating Mode Notification element is optionally present if the TDLS Setup Request frame contained an Extended Capabilities element with the Operating Mode Notification field is equal to 1. 1219 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The TDLS Setup Response Action field is encapsulated in a Data frame and transmitted to the TDLS initiator STA through the AP in response to a received TDLS Setup Request Action field. See 11.23. 9.6.13.4 TDLS Setup Confirm Action field format The Action field of a TDLS Setup Confirm Action field contains the information shown in Table 9-345. Table 9-345â€”Information for TDLS Setup Confirm Action field Order Information Notes 1 Category The Category field is defined in 9.4.1.11. 2 TDLS Action The TDLS Action field is defined in 9.6.13.1. 3 Status Code The Status Code is defined in 9.4.1.9. 4 Dialog Token The dialog token is copied from the corresponding TDLS Setup Response. The dialog token is specified in 9.4.1.12. 5 RSNE The RSNE is present if security is required on the TDLS direct link and the Status Code is SUCCESS, and not present otherwise. The RSNE is defined in 9.4.2.25. 6 EDCA Parameter Set The EDCA parameter set is present if QoS is supported on the direct link. The EDCA Parameter Set element is specified in 9.4.2.29. It is present for Status Code SUCCESS. 7 FTE The FTE is defined in 9.4.2.48. The FTE is present if security is required on the TDLS direct link and the Status Code is SUCCESS, and not present otherwise. 8 Timeout Interval (TPK Key The Timeout Interval element is defined in 9.4.2.49. Lifetime) The Timeout Interval, containing the TPK Key Lifetime, is present if security is required on the direct link and the Status Code is SUCCESS, and not present otherwise. 9 HT Operation The HT Operation element is present if dot11HighThroughputOptionImplemented is true, the TDLS Setup Response frame contained an HT Capabilities element, the Status Code is SUCCESS. The HT Operation element is defined in 9.4.2.57. 10 Link Identifier The Link Identifier is specified in 9.4.2.62. It is present if the Status Code is SUCCESS. 11 VHT Operation VHT Operation element (optional). The VHT Operation element is present if the dot11VHTOptionImplemented is true, the TDLS Setup Response frame contained a VHT Capabilities element, the status code is SUCCESS, and the TDLS direct link is not established in the 2.4 GHz band. The VHT Operation element is defined in 9.4.2.159. 12 Operating Mode Notification The Operating Mode Notification element is optionally present if the TDLS Setup Request frame contained an Extended Capabilities element with the Operating Mode Notification field is equal to 1. The TDLS Setup Confirm Action field is encapsulated in a Data frame and transmitted to the TDLS responder STA through the AP in response to a received TDLS Setup Response Action field. See 11.23. 1220 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.6.13.5 TDLS Teardown Action field format The Action field of a TDLS Teardown Action field contains the information shown in Table 9-346. Table 9-346â€”Information for TDLS Teardown Action field Order Information Notes 1 Category The Category field is defined in 9.4.1.11. 2 TDLS Action The TDLS Action field is defined in 9.6.13.1. 3 Reason Code The Reason Code is defined in 9.4.1.7. 4 FTE The FTE is present if a TPK handshake was successful for this session (optional). The FTE is defined in 9.4.2.48. 5 Link Identifier The Link Identifier is specified in 9.4.2.62. The TDLS Teardown Action field is encapsulated in a Data frame and transmitted to the TDLS peer STA directly or through the AP to tear down a TDLS direct link. See 11.23. 9.6.13.6 TDLS Peer Traffic Indication Action field format The Action field of a TDLS Peer Traffic Indication Action field contains the information shown in Table 9-347. Table 9-347â€”Information for TDLS Peer Traffic Indication Action field Order Information Notes 1 Category The Category field is defined in 9.4.1.11. 2 TDLS Action The TDLS Action field is defined in 9.6.13.1. 3 Dialog Token The dialog token is specified in 9.4.1.12. 4 Link Identifier The Link Identifier is specified in 9.4.2.62. 5 PTI Control The PTI Control element is optionally present. It is defined in 9.4.2.65. 6 TPU Buffer Status The TPU Buffer Status element is defined in 9.4.2.66. The TDLS Peer Traffic Indication Action field indicates the state of the power save buffer at the STA supporting TPU that is buffering data for a TDLS peer STA in power save mode. The TPU Buffer Status element indicates the status of the AC buffers at the TPU buffer STA. The PTI Control element is optionally included in the TDLS Peer Traffic Indication Action field (see 11.2.3.15) to identify the latest MPDU transmitted to the TPU sleep STA that is the destination of the TDLS Peer Traffic Indication Action field. The TDLS Peer Traffic Indication Action field is encapsulated in a Data frame and transmitted to the TDLS peer STA through the AP. See 11.2.3.15. 1221 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.6.13.7 TDLS Channel Switch Request Action field format The Action field of the TDLS Channel Switch Request Action field contains the information shown in Table 9-348. Table 9-348â€”Information for TDLS Channel Switch Request Action field Order Information Notes 1 Category The Category field is defined in 9.4.1.11. 2 TDLS Action The TDLS Action field is defined in 9.6.13.1. 3 Target Channel 1 octet field that specifies the channel number of the target channel. See 9.4.1.36. 4 Operating Class 1 octet field that specifies the operating class for the target channel. The Operating Channel field is defined in 9.4.1.37. 5 Secondary Channel Offset The secondary channel offset is present if a switch to a 40 MHz direct link is indicated and is absent otherwise. See 9.4.2.20. 6 Link Identifier The Link Identifier element is specified in 9.4.2.62. 7 Channel Switch Timing The Channel Switch Timing element is specified in 9.4.2.64. 8 Wide Bandwidth Channel Wide Bandwidth Channel Switch element (optional). The Switch Wide Bandwidth Channel Switch element is included when a switch to an 80 MHz, 160 MHz, or 80+80 MHz direct link is indicated. See 9.4.2.161. 9 Country Country element (optional). The Country element is included to change operating classes when a switch to a direct link is indicated. The Country element indicates the same country as the BSS and includes zero Subband Triplet fields. 10 Transmit Power Envelope Transmit Power Envelope element (zero or more). Each Transmit Power Envelope element that is present includes a distinct value of the Local Maximum Transmit Power Unit Interpretation subfield. If present, the New Transmit Power Envelope element indicates the maximum transmit powers for the direct link for the indicated bandwidths with an indicated unit interpretation after a switch to a direct link (see 11.23.6.5.1). The TDLS Channel Switch Request Action field is encapsulated in a Data frame and transmitted directly to the TDLS peer STA to request for the TDLS direct link to be switched to another channel. See 11.23. 9.6.13.8 TDLS Channel Switch Response Action field format The Action field of the TDLS Channel Switch Response Action field contains the information shown in Table 9-349. The TDLS Channel Switch Response Action field is encapsulated in a Data frame and transmitted directly to the TDLS peer STA in response to a received TDLS Channel Switch Request Action field. See 11.23. 1222 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-349â€”Information for TDLS Channel Switch Response Action field Order Information Notes 1 Category The Category field is defined in 9.4.1.11. 2 TDLS Action The TDLS Action field is defined in 9.6.13.1. 3 Status Code The Status Code is defined in 9.4.1.9. 5 Link Identifier The Link Identifier element is specified in 9.4.2.62. It is present if the Status Code is SUCCESS. 6 Channel Switch Timing The Channel Switch Timing element is specified in 9.4.2.64. 9.6.13.9 TDLS Peer PSM Request Action field format The TDLS Peer PSM Request Action field contains the information shown in Table 9-350. Table 9-350â€”Information for TDLS Peer PSM Request Action field Order Information Notes 1 Category The Category field is defined in 9.4.1.11. 2 TDLS Action The TDLS Action field is defined in 9.6.13.1. 3 Dialog Token The Dialog Token field contains a value that is unique among TDLS Peer PSM Request Action fields for which a corresponding TDLS Peer PSM Response Action field has not been received. The dialog token is specified in 9.4.1.12. 4 Link Identifier The Link Identifier element is specified in 9.4.2.62. 5 Wakeup Schedule The Wakeup Schedule element is specified in 9.4.2.63. The TDLS Peer PSM Request Action field is encapsulated in a Data frame and transmitted to the TDLS peer STA, directly or through the AP, to set up or change a periodic wakeup schedule on the TDLS direct link. See 11.2.3.14. 9.6.13.10 TDLS Peer PSM Response Action field format The TDLS Peer PSM Response Action field contains the information shown in Table 9-351. Table 9-351â€”Information for TDLS Peer PSM Response Action field Order Information Notes 1 Category The Category field is defined in 9.4.1.11. 2 TDLS Action The TDLS Action field is defined in 9.6.13.1. 3 Dialog Token The dialog token is set to the value contained in the corresponding TDLS Peer PSM Request Action field. The dialog token is specified in 9.4.1.12. 4 Status Code The Status Code is specified in 9.4.1.9. 1223 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-351â€”Information for TDLS Peer PSM Response Action field (continued) Order Information Notes 5 Link Identifier The Link Identifier element is specified in 9.4.2.62. It is present if the Status Code is SUCCESS. 6 Wakeup Schedule The Wakeup Schedule element is present is present if the status code is set to TDLS_REJECTED_ALTERNATIVE_PROVIDED and is not present otherwise. The Wakeup Schedule is specified in 9.4.2.63. The TDLS Peer PSM Response Action field is encapsulated in a Data frame and transmitted to the TDLS peer STA directly in response to a TDLS Peer PSM Request Action field. See 11.2.3.14. 9.6.13.11 TDLS Peer Traffic Response Action field format The Action field of a TDLS Peer Traffic Response Action field contains the information shown in Table 9-352. Table 9-352â€”Information for TDLS Peer Traffic Response Action field Order Information Notes 1 Category The Category field is defined in 9.4.1.11. 2 TDLS Action The TDLS Action field is defined in 9.6.13.1. 3 Dialog Token The dialog token is specified in 9.4.1.12. 4 Link Identifier The Link Identifier element is specified in 9.4.2.62. The TDLS Peer Traffic Response Action field indicates the receipt of the corresponding TDLS Peer Traffic Indication Action field. The Dialog Token field is set to the nonzero value of the corresponding TDLS Peer Traffic Indication Action field. The Link Identifier field is set to identify the TDLS direct link in relation to which the TDLS Peer Traffic Response Action field is transmitted. The TDLS Peer Traffic Response Action field is encapsulated in a Data frame and transmitted to the TDLS peer STA directly. See 11.2.3.15. 9.6.13.12 TDLS Discovery Request Action field format The TDLS Discovery Request Action field contains the information shown in Table 9-353. The TDLS Discovery Request Action field is encapsulated in a Data frame and transmitted to a TDLS peer STA through the AP, to request TDLS capable STAs in the same BSS to respond with a TDLS Discovery Response frame. See 11.23. 1224 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-353â€”Information for TDLS Discovery Request Action field Order Information Notes 1 Category The Category field is defined in 9.4.1.11. 2 TDLS Action The TDLS Action field is defined in 9.6.13.1. 3 Dialog Token The Dialog Token field can be used to match TDLS Discovery Response frames to the corresponding TDLS Discovery Request frame. The dialog token is specified in 9.4.1.12. 4 Link Identifier The Link Identifier element is specified in 9.4.2.62. 5 Multi-band The Multi-band element is optionally present if dot11MultibandImplemented is true. 9.6.14 WNM Action details 9.6.14.1 WNM Action fields Several Action frame formats are defined for wireless network management (WNM) purposes. A WNM Action field, in the octet field immediately after the Category field, differentiates the formats. The WNM Action field values associated with each frame format are defined in Table 9-354. Table 9-354â€”WNM Action field values WNM Action field value Description 0 Event Request 1 Event Report 2 Diagnostic Request 3 Diagnostic Report 4 Location Configuration Request 5 Location Configuration Response 6 BSS Transition Management Query 7 BSS Transition Management Request 8 BSS Transition Management Response 9 FMS Request 10 FMS Response 11 Collocated Interference Request 12 Collocated Interference Report 13 TFS Request 14 TFS Response 15 TFS Notify 16 WNM Sleep Mode Request 17 WNM Sleep Mode Response 18 TIM Broadcast Request 1225 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-354â€”WNM Action field values (continued) WNM Action field value Description 19 TIM Broadcast Response 20 QoS Traffic Capability Update 21 Channel Usage Request 22 Channel Usage Response 23 DMS Request 24 DMS Response 25 Timing Measurement Request 26 WNM Notification Request 27 WNM Notification Response 28 WNM-Notify Response 29â€“255 Reserved 9.6.14.2 Event Request frame format The Event Request frame uses the Action frame body format and is transmitted to request another STA to report one or more events. The format of the Event Request Action field is shown in Figure 9-694. Destination URI Event Request Category WNM Action Dialog Token Elements Element (optional) Octets: 1 1 1 variable variable Figure 9-694â€”Event Request Action field format The Category field is defined in 9.4.1.11. The WNM Action field is defined in 9.6.14.1. The Dialog Token field is a nonzero value chosen by the STA sending the event request to identify the request/report transaction. The Event Request Elements field contains one or more of the Event Request elements described in 9.4.2.67. The Destination URI element field contains zero or one Destination URI element described in 9.4.2.90. 9.6.14.3 Event Report frame format The Event Report frame uses the Action frame body format and is transmitted in response to an Event Request frame, or autonomously. The format of the Event Report Action field is shown in Figure 9-695. 1226 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Event Report Category WNM Action Dialog Token Elements Octets: 1 1 1 variable Figure 9-695â€”Event Report Action field format The Category field is defined in 9.4.1.11. The WNM Action field is defined in 9.6.14.1. The Dialog Token field is the nonzero value of the corresponding Event Request frame. If the Event Report frame is being transmitted other than in response to an Event Request frame, then the dialog token is 0. The Event Report Elements field contains one or more of the Event Report elements described in 9.4.2.68. 9.6.14.4 Diagnostic Request frame format The Diagnostic Request frame uses the Action frame body format and is transmitted requesting the receiving STA to execute a diagnostic test. The format of the Diagnostic Request Action field is shown in Figure 9-696. WNM Diagnostic Request Destination URI Category Action Dialog Token Elements Element (optional) Octets: 1 1 1 variable variable Figure 9-696â€”Diagnostic Request Action field format The Category field is defined in 9.4.1.11. The WNM Action field is defined in 9.6.14.1. The Dialog Token field is a nonzero value chosen by the STA sending the Diagnostic Request frame to identify the request/report transaction. The Diagnostic Request Elements field contains one or more of the Diagnostic Request elements described in 9.4.2.69. The number and length of the Diagnostic Request elements in a Diagnostic Request frame is limited by the maximum MMPDU size (see 9.3.3.2). The Destination URI element field contains zero or one Destination URI element described in 9.4.2.90. 9.6.14.5 Diagnostic Report frame format The Diagnostic Report frame uses the Action frame body format transmitted by a STA in response to a Diagnostic Request frame. The format of the Diagnostic Report Action field is shown in Figure 9-697. Diagnostic Report Category WNM Action Dialog Token Elements Octets: 1 1 1 variable Figure 9-697â€”Diagnostic Report Action field format 1227 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Category field is defined in 9.4.1.11. The WNM Action field is defined in 9.6.14.1. The Dialog Token field is the nonzero value in any corresponding Diagnostic Request frame. The Diagnostic Report Elements field contains one or more of the Diagnostic Report elements described in 9.4.2.70. The number and length of the Diagnostic Report elements in a Diagnostic Report frame is limited by the maximum MMPDU size (see 9.3.3.2). 9.6.14.6 Location Configuration Request frame format The Location Configuration Request frame uses the Action frame body format and is transmitted to configure another STA to send a Location Track Notification frame on a set of channels periodically for the purposes of determining location of the STA. The format of the Location Configuration Request Action field is shown in Figure 9-698. Category WNM Action Dialog Token Location Parameters Element Octets: 1 1 1 variable Figure 9-698â€”Location Configuration Request Action field format The Category field is defined in 9.4.1.11. The WNM Action field is defined in 9.6.14.1. The Dialog Token field is a nonzero value that is unique among the Location Configuration Request frames sent to each destination MAC address for which a corresponding Location Configuration Response frame has not been received. The Location Parameters Element field contains the location parameters subelements, described in 9.4.2.71. Table 9-355 defines the allowed Location Parameters subelements for a Location Parameters element that is included in the Location Configuration Request frame. Table 9-355â€”Location Parameters Element field for Location Configuration Request frame Allowed subelements Subelement ID Notes Location Indication Parameters 1 The Location Indication Parameters subelement is included in the Location Configuration Request frame. Location Indication Channels 2 The Location Indication Channels subelement is included in the Location Configuration Request frame. Location Indication Broadcast 6 The Location Indication Broadcast Data Rate subelement Data Rate is included in the Location Configuration Request frame. Location Indication Options 8 The Location Indication Options subelement is optionally included in the Location Configuration Request frame. Vendor Specific Information 221 Zero or more Vendor Specific subelements are included in the Location Configuration Request frame. 1228 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.6.14.7 Location Configuration Response frame format The Location Configuration Response frame uses the Action frame body format and is transmitted in response to the receipt of a Location Configuration Request frame. The format of the Location Configuration Response Action field is shown in Figure 9-699. Location Category WNM Action Dialog Token Parameters Element Octets: 1 1 1 variable Figure 9-699â€”Location Configuration Response Action field format The Category field is defined in 9.4.1.11. The WNM Action field is defined in 9.6.14.1. The Dialog Token field is the nonzero value received in the Location Configuration Request frame to identify the request/response transaction. The Location Parameters Element field contains the location parameters subelements, described in 9.4.2.71. Table 9-356 defines the allowed Location Parameters subelements for a Location Parameters element that is included in the Location Configuration Response frame. Table 9-356â€”Location Parameters Element field for Location Configuration Response frame Allowed subelements Subelement ID Notes Location Indication Parameters 1 The Location Indication Parameters subelement is optionally included in the Location Configuration Response frame. Location Indication Channels 2 The Location Indication Channels subelement is optionally included in the Location Configuration Response frame. Location Indication Broadcast 6 The Location Indication Broadcast Data Rate subelement Data Rate is optionally included in the Location Configuration Response frame. Location Indication Options 8 The Location Indication Options subelement is optionally included in the Location Configuration Response frame. Location Status 3 The Location Status subelement is included in the Location Configuration Response frame. If all configuration of the subelements contained in a Location Configuration Request frame was successful, then a single Location Status subelement is included in the Location Configuration Response frame. For each subelement contained in the Location Configuration Request frame that is not successful a Location Status subelement is included in the Location Configuration Response frame that indicates the subelement ID and the unsuccessful status code for that subelement ID. Vendor Specific Information 221 Zero or more Vendor Specific subelements are included in the Location Configuration Response frame. 1229 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.6.14.8 BSS Transition Management Query frame format The BSS Transition Management Query frame uses the Action frame body format and is transmitted to request or provide information on BSS transition candidate APs. The format of the BSS Transition Management Query Action field is shown in Figure 9-700. BSS Transition BSS Transition Candidate List Category WNM Action Dialog Token Query Reason Entries (Optional) Octets: 1 1 1 1 variable Figure 9-700â€”BSS Transition Management Query Action field format The Category field is defined in 9.4.1.11. The WNM Action field is defined in 9.6.14.1. The Dialog Token field is a nonzero value chosen by the STA sending the BSS Transition Management Query frame to identify the query/request/response transaction. The BSS Transition Query Reason field contains the reason code for a BSS transition management query as defined in Table 9-176. The BSS Transition Candidate List Entries field contains zero or more Neighbor Report elements, as described in 9.4.2.37. The Neighbor Report elements are collected by the STA as part of its scanning procedures and provided to the AP as described in 11.24.7.2. The length of the BSS Transition Candidate List Entries field in a BSS Transition Management Query frame is limited by the maximum MMPDU size (see 9.3.3.2). 9.6.14.9 BSS Transition Management Request frame format The BSS Transition Management Request frame uses the Action frame body format and is transmitted by an AP STA in response to a BSS Transition Management Query frame, or autonomously. The format of the BSS Transition Management Request Action field is shown in Figure 9-701. Category WNM Action Dialog Token Request mode Disassociation Timer Octets: 1 1 1 1 2 BSS BSS Transition Termination Session Candidate List Validity Interval Information URL Duration (optional) Entries (optional) (optional) Octets: 1 0 or 12 variable variable Figure 9-701â€”BSS Transition Management Request Action field format The Category field is defined in 9.4.1.11. The WNM Action field is defined in 9.6.14.1. The Dialog Token field is the nonzero value received in the BSS Transition Management Query frame if the BSS Transition Management Request frame is being transmitted in response to a BSS Transition 1230 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Management Query frame. If the BSS Transition Management Request frame is being transmitted other than in response to a BSS Transition Management Query frame, then the Dialog Token field is a nonzero value chosen by the AP STA sending the BSS Transition Management Request frame to identify the request/ response transaction. The Request mode field is defined in Figure 9-702. Preferred Disassociation BSS ESS Candidate List Abridged Termination Disassociation Reserved Included Imminent Included Imminent Bit: 0 1 2 3 4 5- 7 Figure 9-702â€”Request Mode field â€” The Preferred Candidate List Included (bit 0) field indicates whether the BSS transition candidate list included in this frame is a preferred candidate list or a list of known BSS transition candidates. The Preferred Candidate List Included bit set to 0 indicates that the receiving STA can ignore the BSS Transition Candidate List Entries field (see 11.24.7.3). The Preferred Candidate List Included bit set to 1 indicates that the sender expects the receiving STA to process this frame. â€” The Abridged (bit 1) field indicates to the recipient of the frame the intended treatment of all BSSIDs not listed in the BSS Transition Candidate List Entries field. The AP sets the Abridged bit in the Request Mode field to 1 when a preference value of 0 is assigned to all BSSIDs that do NOT appear in the BSS Transition Candidate List. The AP sets the Abridged bit in the Request Mode field to 0 when the AP has no recommendation for or against any BSSID not present in the BSS Transition Candidate List Entries field. â€” The Disassociation Imminent (bit 2) field indicates whether the STA will be disassociated from the current AP. The value 1 in the Disassociation Imminent bit in the Request Mode field indicates that the STA is to be disassociated from the current AP, while the value 0 indicates that disassociation from the AP is not imminent. â€” The BSS Termination Included (bit 3) field indicates that the BSS Termination Duration field is included, the BSS is shutting down and the STA will be disassociated. The AP sets the BSS Termination Included bit in the Request mode field to 1 to indicate that the BSS is shutting down. The BSS Termination Included bit is 0 if no BSS Termination Duration information is included in the BSS Transition Management Request frame. â€” The ESS Disassociation Imminent (bit 4) field indicates that the Session Information URL field is included, and that the STA will be disassociated from the ESS. The value 1 in the ESS Disassociation Imminent bit in the Request Mode field indicates that the STA is to be disassociated from the ESS, while the value 0 indicates that disassociation from the ESS is not imminent. When the ESS Disassociation Imminent bit value is 1, a Session Information URL field is included in the BSS Transition Management Request frame. The Disassociation Timer indicates the time after which the AP issues a Disassociation frame to this STA. The Disassociation Timer field contains the number of beacon transmission times (TBTTs) until the AP sends a Disassociation frame to this STA. A value of 0 indicates that the AP has not determined when it will send a Disassociation frame to this STA. If the Disassociation Imminent field is 0, the Disassociation Timer field is reserved. The format of the Disassociation Timer field is shown in Figure 9-703. 1231 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B0 B15 Disassociation Timer Bits 16 Figure 9-703â€”Disassociation Timer field format The Validity Interval field is the number of beacon transmission times (TBTTs) until the BSS transition candidate list is no longer valid. A value of 0 is reserved. The BSS Termination Duration field contains the BSS Termination Duration subelement (see 9.4.2.37) for the current BSS and is present only when the BSS Termination Included field is 1 in the Request mode field. The format of the optional Session Information URL field is shown in Figure 9-704. This field is present when the ESS Disassociation Imminent field is 1. URL Length URL (optional) Octets: 1 variable Figure 9-704â€”Session Information URL field format The URL Length field is the value of the length of the URL field. The URL Length field is 0 when the URL field is not present. The URL field is a variable-length field formatted in accordance with IETF RFC 3986. The BSS Transition Candidate List Entries field contains zero or more Neighbor Report elements described in 9.4.2.37. If the STA has no information in response to the BSS Transition Management Query frame or in an unsolicited BSS Transition Management Request frame, the Neighbor Report elements are omitted and the Preferred Candidate List Included bit is 0. The length of the BSS Transition Candidate List Entries in a BSS Transition Management Request frame is limited by the maximum MMPDU size (see 9.3.3.2). 9.6.14.10 BSS Transition Management Response frame format The BSS Transition Management Response frame uses the Action frame body format and is optionally transmitted by a STA in response to a BSS Transition Management Request frame. The format of the BSS Transition Management Response Action field is shown in Figure 9-705. BSS BSS Transition Category WNM Dialog BTM Status Termination Target BSSID Candidate List Action Token Code (Optional) Delay Entries (Optional) Octets: 1 1 1 1 1 0 or 6 variable Figure 9-705â€” BSS Transition Management Response Action field format The Category field is defined in 9.4.1.11. The WNM Action field is defined in 9.6.14.1. 1232 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Dialog Token field is the value in the corresponding BSS Transition Management Request frame. The BSS Transition Management Response frame is transmitted in response to a BSS Transition Management Request frame. The BTM Status Code field contains the status code in response to a BSS Transition Management Request frame as defined in Table 9-357. If the STA will transition to another BSS, then the status code is 0 (i.e., Accept). If the STA intends to retain the association with the current BSS, the status code is one of the â€œRejectâ€ status codes. Table 9-357â€”BTM status code definitions Status code Status code description 0 Accept 1 Rejectâ€”Unspecified reject reason. 2 Rejectâ€”Insufficient Beacon or Probe Response frames received from all candidates. 3 Rejectâ€”Insufficient available capacity from all candidates. 4 Rejectâ€”BSS termination undesired. 5 Rejectâ€”BSS termination delay requested. 6 Rejectâ€”STA BSS Transition Candidate List provided. 7 Rejectâ€”No suitable BSS transition candidates. 8 Rejectâ€”Leaving ESS. 9â€“255 Reserved The BSS Termination Delay field is the number of minutes that the responding STA requests the BSS to delay termination. This field is reserved if the Status code field value is not set to 5. The Target BSSID field is the BSSID of the BSS that the non-AP STA transitions to. This field is present if the Status code subfield contains 0, and not present otherwise. The BSS Transition Candidate List Entries field contains zero or more Neighbor Report elements described in 9.4.2.37. The Neighbor Report elements are collected by the STA as part of its scanning procedures and provided to the AP as described in 11.24.7.4. The length of the BSS Transition Candidate List Entries field in a BSS Transition Management Response frame is limited by the maximum MMPDU size (see 9.3.3.2). 9.6.14.11 FMS Request frame format The FMS Request frame is sent by a non-AP STA to the AP to request the specified FMS and to propose delivery intervals for a set of group addressed streams. The FMS Request frame is also sent by a non-AP STA to request a modification to a previous FMS Request. The format of the Action field is shown in Figure 9-706. FMS Request Category WNM Action Dialog Token Element Octets: 1 1 1 variable Figure 9-706â€”FMS Request Action field format 1233 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Category field is defined in 9.4.1.11. The WNM Action field is defined in 9.6.14.1. The Dialog Token field is a nonzero value that is unique among the FMS Request frame sent to each destination MAC address for which a corresponding FMS Report frame has not been received. The FMS Request Element field indicates the group addressed traffic streams that are requested by the non- AP STA. The FMS Request Element field contains one FMS Request element described in 9.4.2.76. 9.6.14.12 FMS Response frame format The FMS Response frame is sent by an AP in response to an FMS Request frame, or sent by the AP to the STA to instruct the non-AP STA to change the delivery interval or data rate. The format of the Action field is shown in Figure 9-707. Category WNM Action Dialog Token FMS Response Element Octets: 1 1 1 variable Figure 9-707â€”FMS Response Action field format The Category field is defined in 9.4.1.11. The WNM Action field is defined in 9.6.14.1. The Dialog Token field is the nonzero value received in the FMS Request frame to identify the request/ response transaction. If an FMS Response frame is being transmitted other than in response to an FMS Request frame, then the Dialog Token field is 0. The FMS Response Element indicates the group addressed traffic streams that the AP supports and the corresponding delivery intervals. The FMS Response Element field contains one FMS Response elements, described in 9.4.2.77. 9.6.14.13 Collocated Interference Request frame format The Collocated Interference Request frame uses the Action frame body format and is transmitted to request collocated interference reports, sent using Collocated Interference Report frames. The format of the Collocated Interference Request Action field is shown in Figure 9-708. Category WNM Action Dialog Token Request Info Octets: 1 1 1 1 Figure 9-708â€”Collocated Interference Request Action field format The Category field is defined in 9.4.1.11. The WNM Action field is defined in 9.6.14.1. The Dialog Token field is any nonzero value to identify the request/response transaction. The Request Info field is shown in Figure 9-709. 1234 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B0 B1 B2 B7 Automatic Report Enabled Report Timeout Bits: 2 6 Figure 9-709â€”Request Info field format The Automatic Report Enabled subfield contains an unsigned integer value. The Automatic Report Enabled subfield set to 0 indicates that the requesting STA cancels the previous requests so that the receiving STA stops sending collocated interference reports. The Automatic Report Enabled subfield set to 1 indicates that the requesting STA requests the receiving STA to send a collocated interference report when the STA knows of a change in the collocated interference, subject to meeting the Report Timeout requirement. The Automatic Report Enabled subfield set to 2 indicates that the requesting STA requests the receiving STA to send a collocated interference report periodically using the period included in the Report Period field in the Collocated Interference Report element; see 9.4.2.85. The Automatic Report Enabled subfield set to 3 indicates that the requesting STA requests the receiving STA to send collocated interference reports periodically using the period included in the Report Period field in the Collocated Interference Report element; see 9.4.2.85, or send a collocated interference report when the STA knows of a change in the collocated interference, subject to meeting the Report Timeout requirement. The Report Timeout field contains a value in units of 200 TUs and indicates the minimum duration between two consecutive Collocated Interference Report frames from the reporting STA. When the Automatic Report Enabled subfield is 0, the Report Timeout field is reserved. 9.6.14.14 Collocated Interference Report frame format The Collocated Interference Report frame uses the Action frame body format and is transmitted in response to Collocated Interference Request frame. The format of the Collocated Interference Report Action field is shown in Figure 9-710. Collocated Interference Category WNM Action Dialog Token Report Elements Octets: 1 1 1 variable Figure 9-710â€”Collocated Interference Report Action field format The Category field is defined in 9.4.1.11. The WNM Action field is defined in 9.6.14.1. The Dialog Token field is the nonzero value received in the corresponding Collocated Interference Request frame to identify the request/response transaction. The Collocated Interference Report Elements field contains one or more Collocated Interference Report elements to indicate the characteristics of the reported collocated interferences, as defined in 9.4.2.85. 1235 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.6.14.15 TFS Request frame format The TFS Request frame is sent by a non-AP STA to the AP to request the specified traffic filtering. The format of TFS Request frame is defined in Figure 9-711. zero or more TFS Request elements TFS Request Category WNM Action Dialog Token Elements Octets: 1 1 1 variable Figure 9-711â€”TFS Request frame format The Category field is defined in 9.4.1.11. The WNM Action field is defined in 9.6.14.1. The Dialog Token field is a value chosen by the STA sending the TFS Request frame to identify the request/ response transaction. The TFS Request Elements field contains one or more TFS Request elements to specify one or more traffic filter sets that are requested by the non-AP STA, as defined in 9.4.2.80, or zero TFS Request elements to cancel all of the existing traffic filter sets (see 11.24.12.2). 9.6.14.16 TFS Response frame format The TFS Response frame is sent by an AP in response to a TFS Request frame. The format of the TFS Response Action field is defined in Figure 9-712. one or more TFS Response elements TFS Response Category WNM Action Dialog Token Elements Octets: 1 1 1 variable Figure 9-712â€”TFS Response Action field format The Category field is defined in 9.4.1.11. The WNM Action field is defined in 9.6.14.1. The Dialog Token field is the value in the corresponding TFS Request frame. The TFS Response Elements field contains one or more TFS Response elements to indicate the status of the filtering parameters that the AP is requested to support, as defined in 9.4.2.81. The number of TFS Response elements in a TFS Response frame is the same as the number of the TFS Request elements in the TFS Request frame with the same dialog token, where the TFS Response elements appear in the same order as the corresponding TFS Request elements in the TFS Request frame with the same dialog token. 1236 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.6.14.17 TFS Notify frame format The TFS Notify frame is sent by an AP to a STA when a frame matching a traffic filter is encountered. The format of the TFS Notify Action field is defined in Figure 9-713. one or more TFS IDs Number of TFS Category WNM Action IDs TFS ID List Octets: 1 1 1 variable Figure 9-713â€”TFS Notify Action field format The Category field is defined in 9.4.1.11. The WNM Action field is defined in 9.6.14.1. The Number of TFS IDs field indicates the number of 1-octet TFS IDs present in the TFS ID List field. The TFS ID field indicates the traffic filter set containing the matched TCLAS element. 9.6.14.18 TFS Notify Response frame format A TFS Notify Response frame is transmitted by a non-AP STA to an AP to request the AP to resume generation of the TFS Notify frame when a frame matches any traffic filter set identified by the TFS ID(s) included in the TFS Notify Response frame. The format of the TFS Notify Response Action field is shown in Figure 9-714. Number of TFS Category WNM Action TFS ID List IDs Octets: 1 1 1 variable Figure 9-714â€”TFS Notify Response Action field format The Category field is defined in 9.4.1.11. The WNM Action field is defined in 9.6.14.1. The Number of TFS IDs field indicates the number of 1-octet TFS IDs present in the TFS ID List field. The TFS ID List field indicates the identifiers of the traffic filter sets. 9.6.14.19 WNM Sleep Mode Request frame format The WNM Sleep Mode Request frame is sent by a non-AP STA to the AP to enter the WNM sleep mode. The format of the WNM Sleep Mode Request frame is defined in Figure 9-715. 1237 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications one or more TFS Request elements Category WNM Dialog WNM Sleep TFS Request Action Token Mode Element Elements Octets: 1 1 1 6 variable Figure 9-715â€”WNM Sleep Mode Request frame format The Category field is defined in 9.4.1.11. The WNM Action field is defined in 9.6.14.1. The Dialog Token field is a nonzero value chosen by the non-AP STA sending the WNM Sleep Mode Request frame to identify the request/response transaction. The WNM Sleep Mode Element field contains a WNM Sleep Mode element that is requested by a non-AP STA, as described in 9.4.2.82. The TFS Request Elements field contains one or more TFS Request elements to specify the traffic filters that are requested by a non-AP STA, as defined in 9.4.2.80. 9.6.14.20 WNM Sleep Mode Response frame format The WNM Sleep Mode Response frame is sent by an AP in response to a WNM Sleep Mode Request frame or is sent without solicitation by an AP to a non-AP STA upon the APâ€™s deletion of all traffic filter sets established according to the traffic filtering agreement between the AP and the non-AP STA. The format of the WNM Sleep Mode Response Action field is defined in Figure 9-716. Category WNM Action Dialog Token Key Data Key Data Length Octets: 1 1 1 2 variable one or more TFS Response elements WNM Sleep TFS Response Mode Element Elements Octets: variable variable Figure 9-716â€”WNM Sleep Mode Response Action field format The Category field is defined in 9.4.1.11. The WNM Action field is defined in 9.6.14.1. When the WNM Sleep Mode Response frame is transmitted as a response to a WNM Sleep Mode Request frame, the Dialog Token field is the value in the corresponding WNM Sleep Mode Request frame. When the WNM Sleep Mode Response frame is transmitted as an unsolicited response, the Dialog Token field is set to 0. 1238 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Key Data Length field is the length of the Key Data field. If the management frame protection is not used, this field is 0. The Key Data field contains zero or more subelements that provide the current GTK and IGTK to the STA. The format of these subelements is given in Figure 9-717 and Figure 9-718. The subelement IDs for these subelements are defined in Table 9-358. Each subelement starts with the ID and Length fields. The Length field in the subelement is the length of the contents of the subelement. When management frame protection is not used, the Key Data field is not present. Table 9-358â€”Optional subelement IDs for WNM Sleep Mode parameters Value Contents of subelement 0 GTK 1 IGTK 2â€“255 Reserved The GTK subelement contains the Group Key as shown in Figure 9-717. Subelement Length Key Info Key Length RSC Key ID Octets: 1 1 2 1 8 5 to 32 Figure 9-717â€”WNM Sleep Mode GTK subelement format The Subelement ID field is set to 0. The Length field is defined in 9.4.3. The Key Info field is defined in Figure 9-319. The Key Length field is the length of the Key field in octets. The RSC field contains the receive sequence counter (RSC) for the GTK being installed. The RSC field gives the current message number for the GTK to allow a STA to identify replayed MPDUs. If the RSC field value is less than 8 octets in length, the remaining octets are set to 0. The least significant octet of the TSC or PN is in the first octet of the RSC field. NOTEâ€”The RSC field value for TKIP is the Transmit Sequence Counter (TSC) and is stored in the first 6 octets; for CCMP it is the Packet Number (PN) and is stored in the first 6 octets; see Table 12-5. The Key field is the GTK being distributed. The IGTK subelement contains the Integrity GTK as shown in Figure 9-718. Subelement Length Key ID PN Key ID Octets: 1 1 2 6 16 Figure 9-718â€”WNM Sleep Mode IGTK subelement format 1239 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Subelement ID field is set to 1. The Length field is defined in 9.4.3. The Key ID field indicates the value of the BIP key identifier. The PN field indicates the receive sequence counter for the IGTK being installed. The PN field gives the current message number for the IGTK, to allow a STA to identify replayed MPDUs. The Key field is the IGTK being distributed. NOTE 1â€”There might be multiple GTK and multiple IGTK subelements if a group rekeying is in process when the non-AP STA wakes up from WNM sleep mode. NOTE 2â€”Management frame protection is used to provide confidentiality, replay, and integrity protection for GTK/ IGTK update in WNM Sleep Mode Response frames. The WNM Sleep Mode Element field contains a WNM Sleep Mode element, as described in 9.4.2.82. The TFS Response Elements field contains one or more TFS Response elements to specify the traffic filters, as defined in 9.4.2.81. 9.6.14.21 TIM Broadcast Request frame format The format of the TIM Broadcast Request Action field is shown in Figure 9-719. Category WNM Action Dialog Token TIM Broadcast Request Element Octets: 1 1 1 3 Figure 9-719â€”TIM Broadcast Request Action field format The Category field is defined in 9.4.1.11. The WNM Action field is defined in 9.6.14.1. The Dialog Token field is a nonzero value chosen by the STA sending the TIM Broadcast Request frame to identify the request/response transaction. The TIM Broadcast Request Element field contains a TIM Broadcast Request Element as specified in 9.4.2.83. 9.6.14.22 TIM Broadcast Response frame format The format of the TIM Broadcast Response Action field is shown in Figure 9-720. Category WNM Action Dialog Token TIM Broadcast Response Element Octets: 1 1 1 3 or 12 Figure 9-720â€”TIM Broadcast Response Action field format The Category field is defined in 9.4.1.11. 1240 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The WNM Action field is defined in 9.6.14.1. The Dialog Token field is the nonzero value of the corresponding TIM Broadcast Request frame. If the TIM Broadcast Response frame is being transmitted other than in response to a TIM Broadcast Request frame, then the dialog token is 0. The TIM Broadcast Response Element field contains a TIM Broadcast Response Element as specified in 9.4.2.84. 9.6.14.23 QoS Traffic Capability Update frame format The QoS Traffic Capability Update frame is sent by a non-AP STA to the AP to update QoS Traffic Capability information. The format of the Action field is shown in Figure 9-721. Category WNM Action QoS Traffic Capability Flags Octets: 1 1 1 Figure 9-721â€”QoS Traffic Capability Update Action field format The Category field is defined in 9.4.1.11. The WNM Action field is defined in 9.6.14.1. The QoS Traffic Capability Flags field is defined in Table 9-359. The QoS Traffic Capability Flags field comprises 1 octet, with the bits 4â€“6 serving as QoS Traffic Capability Flags. Each of the bits 4â€“6 serves as a flag for one of the three user priorities, UP 4â€“6. The field is 1 to indicate the expectation of generating traffic belonging to the corresponding user priority (UP). The field is 0 to indicate that such expectation does not exist. The use of the QoS Traffic Capability Update frame is described in 11.24.10. Table 9-359â€”QoS Traffic Capability Flags definition Bit Description 0â€“3 Reserved 4 UP 4 Traffic 5 UP 5 Traffic 6 UP 6 Traffic 7 Reserved 9.6.14.24 Channel Usage Request frame format The Channel Usage Request frame is sent by a non-AP STA to the AP to request the specified Channel Usage information. The format of the Channel Usage Request Action field is defined in Figure 9-722. 1241 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Supported WNM Dialog Channel Operating Category Usage Action Token Elements Classes Element Octets: 1 1 1 variable variable Figure 9-722â€”Channel Usage Request Action field format The Category field is defined in 9.4.1.11. The WNM Action field is defined in 9.6.14.1. The Dialog Token field is a nonzero value chosen by the non-AP STA sending the Channel Usage Request frame to identify the request/response transaction. The Channel Usage Element field includes one or more Channel Usage elements described in 9.4.2.86 to identify the request Usage Mode. The Supported Operating Classes Element field includes a Supported Operating Classes element to indicate the supported operating classes for the requested network type, consistent with the Country element advertised by the AP. The Supported Operating Classes is described in 9.4.2.54. 9.6.14.25 Channel Usage Response frame format The Channel Usage Response frame is sent by an AP STA in response to a Channel Usage Request frame, or autonomously. The format of the Channel Usage Response Action field is shown in Figure 9-723. Channel Power EDCA Transmit Parameter Power Category WNM Dialog Usage Country Constraint Set Envelope Action Token Element String Element s (optional) Element element (optional) (optional) Octets: 1 1 1 variable 3 0 or 3 0 or 20 variable Figure 9-723â€”Channel Usage Response Action field format The Category field is defined in 9.4.1.11. The WNM Action field is defined in 9.6.14.1. The Dialog Token field is the nonzero value received in the Channel Usage Request frame if the Channel Usage Response frame is being transmitted in response to a Channel Usage Request frame. The Dialog Token field is 0 if the Channel Usage Response frame is being transmitted other than in response to a Channel Usage Request frame. The Channel Usage Element field includes zero or more Channel Usage elements described in 9.4.2.86. The Country String field is the value contained in the dot11CountryString attribute. The Power Constraint Element field includes zero or one Power Constraint elements described in 9.4.2.14. The use of the Power Constraint element included in the Power Constraint Element field is described in 11.24.15. 1242 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The EDCA Parameter Set Element field includes zero or one EDCA Parameter Set elements described in 9.4.2.29. The use of the EDCA Parameter Set element included in the EDCA Parameter Set Element field is described in 11.24.15. The Transmit Power Envelope element field is defined in 9.4.2.162. 9.6.14.26 DMS Request frame format The DMS Request frame is sent by a non-AP STA to the AP to define information about a DMS request to the AP. The format of the DMS Request Action field is defined in Figure 9-724. DMS Category WNM Action Dialog Token Request Elements Octets: 1 1 1 variable Figure 9-724â€”DMS Request Action field format The Category field is defined in 9.4.1.11. The WNM Action field is defined in 9.6.14.1. The Dialog Token field is a nonzero value chosen by the non-AP STA sending the DMS Request frame to identify the request/response transaction. The DMS Request Elements field contains one or more DMS Request elements as specified in 9.4.2.88. 9.6.14.27 DMS Response frame format The DMS Response frame is sent by an AP or a mesh STA in response to a DMS Request frame, or autonomously to terminate a requested DMS stream, or to advertise the current parameters for one or more GCR streams. The format of the DMS Response Action field is shown in Figure 9-725. DMS Response Category WNM Action Dialog Token Elements Octets: 1 1 1 variable Figure 9-725â€”DMS Response Action field format The Category field is defined in 9.4.1.11. The WNM Action field is defined in 9.6.14.1. The Dialog Token field is the nonzero value received in the DMS Request frame if the DMS Response frame is being transmitted in response to a DMS Request frame. The Dialog Token field is 0 if the DMS Response frame is being transmitted autonomously, and not in response to a DMS Request frame. The DMS Response Elements field contains one or more DMS Response elements as specified in 9.4.2.89. 9.6.14.28 Timing Measurement Request frame format The format of the Timing Measurement Request Action field is shown in Figure 9-726. 1243 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Category WNM Action Trigger Octets: 1 1 1 Figure 9-726â€”Timing Measurement Request Action field format The Category field is defined in 9.4.1.11. The WNM Action field is defined in 9.6.14.1. The Trigger field set to the value 1 indicates that the sending STA requests a timing measurement procedure at the receiving STA as defined in 11.24.5. The Trigger field set to the value 0 indicates that the sending STA requests that the receiving STA stop sending Timing Measurement frames. Trigger field values 2â€“255 are reserved. 9.6.14.29 WNM Notification Request frame format The format of the WNM Notification Request Action field is shown in Figure 9-727. Optional Category WNM Action Dialog Token Type Subelements Octets: 1 1 1 1 variable Figure 9-727â€”WNM Notification Request Action field format The Category field is defined in 9.4.1.11. The WNM Action field is defined in 9.6.14.1. The Dialog Token field is set to a nonzero value chosen by the STA sending the WNM notification request to identify the request/response transaction. The Type field indicates the type of WNM notification, as defined in Table 9-360. Table 9-360â€”WNM notification type Value Description 0 Firmware Update Notification 1â€“220 Reserved 221 Vendor Specific 222â€“255 Reserved The Optional Subelements field contains zero or more subelements. The subelement format and ordering of subelements are defined in 9.4.3. The Subelement ID field values for the defined subelements are shown in Table 9-361. 1244 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-361â€”Optional subelement IDs for WNM Notification Request Subelement ID Name Extensible 0 AP Descriptor 1 Firmware Versionâ€”Current 2 Firmware Versionâ€”New 3â€“255 Reserved When the Type field is 0, the AP Descriptor, Firmware Versionâ€”Current, and Firmware Versionâ€”New optional subelements are included in the WNM Notification Request frame. The AP descriptor field format is as defined in Figure 9-374. The Firmware Versionâ€”Current subelement contains the current firmware version, in the Firmware Version subelement format defined in Figure 9-380. The Firmware Versionâ€”New subelement contains the new firmware version, in the Firmware Version subelement format defined in Figure 9-380. 9.6.14.30 WNM Notification Response frame format The format of the WNM Notification Response Action field is shown in Figure 9-728. Response Category WNM Action Dialog Token Status Octets: 1 1 1 1 Figure 9-728â€”WNM Notification Response Action field format The Category field is defined in 9.4.1.11. The WNM Action field is defined in 9.6.14.1. The Dialog Token field is set to the nonzero value of the corresponding WNM Notification Request frame. The Response Status field indicates the Response Status value, as defined in Table 9-362. Table 9-362â€”WNM Notification Response Status Value Description 0 Notification Acknowledged 1â€“255 Reserved 9.6.15 Unprotected WNM Action details 9.6.15.1 Unprotected WNM Action fields Unprotected WNM Action frames are not encapsulated using mechanisms defined for robust Management frames. An Unprotected WNM Action field, in the octet field immediately after the Category field, differentiates the formats. The Unprotected WNM Action field values associated with each frame format is defined in Table 9-363. 1245 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-363â€”Unprotected WNM Action field values Action field value Description 0 TIM 1 Timing Measurement 2â€“255 Reserved 9.6.15.2 TIM frame format The format of the TIM Action field is shown in Figure 9-729. Category Action Check Beacon Timestamp TIM Element Octets: 1 1 1 8 6â€“256 Figure 9-729â€”TIM Action field format The Category field is defined in 9.4.1.11. The Unprotected WNM Action field is defined in 9.6.15.1. The Check Beacon field is defined as an unsigned integer initialized to 0, that increments when a critical update to the Beacon frame has occurred; see 11.2.3.17. The Timestamp field is defined in 9.4.1.10. The field contains a valid TSF timestamp when the TIM Broadcast Response frame contained a Status field set to â€œAccept, valid timestamp present in TIM framesâ€ or â€œOverridden, valid timestamp present in TIM frames.â€ The field is reserved otherwise. The TIM Element field contains a TIM element as specified in 9.4.2.6. The bit corresponding to buffered group addressed frames is reserved for all BSSIDs. 9.6.15.3 Timing Measurement frame format The Timing Measurement frame is used to support the timing measurement procedure described in 11.24.5. The format of the Timing Measurement Action field is shown in Figure 9-730. Follow Up Category Action Dialog Token Dialog Token TOD Octets: 1 1 1 1 4 Max TOD Max TOA TOA Error Error Octets: 4 1 1 Figure 9-730â€”Timing Measurement Action field format The Category field is defined in 9.4.1.11. The Unprotected WNM Action field is defined in 9.6.15.1. 1246 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Dialog Token field is a nonzero value chosen by the sending STA to identify the Timing Measurement frame as the first of a pair, with the second or follow-up Timing Measurement frame to be sent later. The Dialog Token field is set to 0 to indicate that the Timing Measurement frame will not be followed by a subsequent follow-up Timing Measurement frame. The Follow Up Dialog Token field is the nonzero value of the Dialog Token field of the previously transmitted Timing Measurement frame to indicate that it is the follow up Timing Measurement frame and that the TOD, TOA, Max TOD Error and Max TOA Error fields contain the values of the timestamps captured with the first Timing Measurement frame of the pair. The Follow Up Dialog Token field is 0 to indicate that the Timing Measurement frame is not a follow up to a previously transmitted Timing Measurement frame. The value 0 in this field also indicates that the TOD, TOA, Max TOD Error, and Max TOA Error fields are reserved. See 11.24.5. The TOD, TOA, Max TOD Error, and Max TOA Error fields are expressed in units of 10 ns. The TOD field contains a timestamp that represents the time at which the start of the preamble of the previously transmitted Timing Measurement frame appeared at the transmit antenna connector. The TOA field contains a timestamp that represents the time at which the start of the preamble of the Ack frame to the previously transmitted Timing Measurement frame arrived at the receive antenna connector. NOTEâ€”The values specified in the TOD and TOA fields are described in 6.3.57. The Max TOD Error field contains an upper bound for the error in the value specified in the TOD field. For instance, a value of 2 in the Max TOD Error field indicates that the value in the TOD field has a maximum error of Â± 20 ns. The Max TOA Error field contains an upper bound for the error in the value specified in the TOA field. For instance, a value of 2 in the Max TOA Error field indicates that the value in the TOA field has a maximum error of Â± 20 ns. A value of 0 for the Max TOD Error or the Max TOA Error field indicates that the upper bound on the error in the corresponding TOD or TOA value is unknown. A value of 255 indicates that the upper bound on the error is greater than or equal to 2.55 Âµs. 9.6.16 Self-protected Action frame details 9.6.16.1 Self-protected Action fields The Self-protected Action frame is defined to allow robust STA-STA communications of the Action frames that are not robust (see 9.4.1.11). The protocols that use these Action frames are responsible for deciding whether to protect these frames and supporting protection mechanisms for these frames as needed. Self-protected Action frames have a different nature than Public Action frames and robust Action frames. Robust Action frames assume the existence of a completely established security association. Self-protected Action frames typically exist to manage the creation and deletion of security associations, regardless of whether they are completely established. Public Action frames are defined as public for all STAs, including those that are not in the BSS and MBSS. Self-protected Action frames, however, are used for relationship creation and maintenance between two specific STAs. Their public nature is incidental. A Self-protected Action field, in the octet field immediately after the Category field, differentiates the formats. The defined Self-protected Action frames are listed in Table 9-364. 1247 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-364â€”Self-protected Action field values Self-protected Action field value Description 0 Reserved 1 Mesh Peering Open 2 Mesh Peering Confirm 3 Mesh Peering Close 4 Mesh Group Key Inform 5 Mesh Group Key Acknowledge 6â€“255 Reserved The Mesh Peering Open frame, the Mesh Peering Confirm frame, and the Mesh Peering Close frame are referred to as mesh peering Management frames. 9.6.16.2 Mesh Peering Open frame format 9.6.16.2.1 Mesh Peering Open frame self protection Protection of this frame is provided when authenticated mesh peering exchange (AMPE) is enabled. AMPE provides integrity protection of Mesh Peering Open frames. When the Mesh Peering Open frame is used by the mesh peering management (MPM) protocol, integrity protection on the frame is not enabled. 9.6.16.2.2 Mesh Peering Open frame details The Mesh Peering Open frame is used to open a mesh peering using the procedures defined in 14.3.6 and in 14.5.5. The format of the Mesh Peering Open frame Action field is shown in Table 9-365. Table 9-365â€”Mesh Peering Open frame Action field format Order Information Notes 1 Category 2 Self-protected Action 3 Capability 4 Supported Rates and BSS Membership Selectors 5 Extended Supported Rates The Extended Supported Rates and BSS Membership Selectors element and BSS Membership is present if there are more than eight supported rates and is optionally Selectors present otherwise. 6 Power Capability The Power Capability element is present if dot11SpectrumManagementRequired is true. 7 Supported Channels The Supported Channels element is present if dot11SpectrumManagementRequired is true and dot11ExtendedChannelSwitchActivated is false. 1248 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-365â€”Mesh Peering Open frame Action field format (continued) Order Information Notes 8 RSN The RSNE is present if dot11MeshSecurityActivated, dot11ProtectedQLoadReportActivated, or dot11ProtectedTXOPNegotiationActivated is true; otherwise not present. 9 Mesh ID 10 Mesh Configuration 11 Mesh Peering Management The Mesh Peering Management element is set as described in 9.4.2.98. 12 ERP Information The ERP element is present if ERP mesh STA detects NonERP STAs in its vicinity and is optionally present otherwise. 13 Supported Operating The Supported Operating Classes element is present if Classes dot11ExtendedChannelSwitchActivated is true. 14 HT Capabilities The HT Capabilities element is present when dot11HighThroughputOptionImplemented is true. 15 HT Operation The HT Operation element is included when dot11HighThroughputOptionImplemented is true. 16 20/40 BSS Coexistence The 20/40 BSS Coexistence element is optionally present when the element dot112040BSSCoexistenceManagementSupport is true. 17 Extended Capabilities The Extended Capabilities element is optionally present if any of the element fields in this element are nonzero. 18 Interworking The Interworking element is present if dot11InterworkingServiceActivated is true. 19 VHT Capabilities The VHT Capabilities element is present when dot11VHTOptionImplemented is true. 20 VHT Operation The VHT Operation element is present when dot11VHTOptionImplemented is true. 21 Operating Mode The Operating Mode Notification element is optionally present if Notification dot11OperatingModeNotificationImplemented is true. The Category field is defined in 9.4.1.11. The Self-protected Action field is defined in 9.6.16.1. The MIC element appears prior to the Authenticated Mesh Peering Exchange element in the Mesh Peering Open frame. The information following the MIC element through to the end of the Mesh Peering Open frame body is encrypted and authenticated (see 14.5). 9.6.16.3 Mesh Peering Confirm frame format 9.6.16.3.1 Mesh Peering Confirm frame self protection Protection of this frame is provided when authenticated mesh peering exchange (AMPE) is enabled. AMPE provides integrity protection of Mesh Peering Confirm frames. When the Mesh Peering Confirm frame is used by the mesh peering management (MPM) protocol, integrity protection on the frame is not enabled. 1249 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.6.16.3.2 Mesh Peering Confirm frame details The Mesh Peering Confirm frame is used to confirm a mesh peering using the procedures defined in 14.3.7 and 14.5.5. The format of the Mesh Peering Confirm frame Action field is shown in Table 9-366. Table 9-366â€”Mesh Peering Confirm frame Action field format Order Information Notes 1 Category 2 Self-protected Action 3 Capability 4 AID 5 Supported Rates and BSS Membership Selectors 6 Extended Supported Rates The Extended Supported Rates and BSS Membership Selectors element and BSS Membership is present if there are more than eight supported rates and is optionally Selectors present otherwise. 7 RSN The RSNE is present only when dot11MeshSecurityActivated, dot11ProtectedQLoadReportActivated, or dot11ProtectedTXOPNegotiationActivated is true. 8 Mesh ID 9 Mesh Configuration The Mesh Configuration element is present when dot11MeshActivated is true. 10 Mesh Peering Management The Mesh Peering Management element is set as described in 9.4.2.102. 11 HT Capabilities The HT Capabilities element is present when dot11HighThroughputOptionImplemented is true. 12 HT Operation The HT Operation element is included when dot11HighThroughputOptionImplemented is true. 13 20/40 BSS Coexistence The 20/40 BSS Coexistence element is optionally present when the element dot112040BSSCoexistenceManagementSupport is true. 14 Extended Capabilities The Extended Capabilities element is optionally present if any of the element fields in this element are nonzero. 15 VHT Capabilities The VHT Capabilities element is present when dot11VHTOptionImplemented is true. 16 VHT Operation The VHT Operation element is present when dot11VHTOptionImplemented is true. 17 Operating Mode The Operating Mode Notification element is optionally present if Notification dot11OperatingModeNotificationImplemented is true. The Category field is defined in 9.4.1.11. The Self-protected Action field is defined in 9.6.16.1. The MIC element appears prior to the Authenticated Mesh Peering Exchange element in the Mesh Peering Open frame. The information following the MIC element through to the end of the Mesh Peering Confirm frame body is encrypted and authenticated (see 14.5). 1250 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.6.16.4 Mesh Peering Close frame format 9.6.16.4.1 Mesh Peering Close frame self protection Protection of this frame is provided when authenticated mesh peering exchange (AMPE) is enabled. AMPE provides integrity protection of Mesh Peering Close frames. When the Mesh Peering Close frame is used by the mesh peering management (MPM) protocol, integrity protection on the frame is not enabled. 9.6.16.4.2 Mesh Peering Close frame details The Mesh Peering Close frame is used to close a mesh peering using the procedures defined in 14.3.8 and in 14.5.5. The format of the Mesh Peering Close frame Action field is shown in Table 9-367. Table 9-367â€”Mesh Peering Close frame Action field format Order Information Notes 1 Category 2 Self-protected Action 3 Mesh ID 4 Mesh Peering Management The Category field is defined in 9.4.1.11. The Self-protected Action field is defined in 9.6.16.1. The MIC element appears prior to the Authenticated Mesh Peering Exchange element in the Mesh Peering Open frame. The information following the MIC element through to the end of the Mesh Peering Close frame body is encrypted and authenticated (see 14.5). 9.6.16.5 Mesh Group Key Inform frame format 9.6.16.5.1 Mesh Group Key Inform frame self protection The protection of the frames is provided by the mesh group key handshake protocol (see 14.6) that uses Mesh Group Key Inform frames. 9.6.16.5.2 Mesh Group Key Inform frame details The Mesh Group Key Inform frame is used to update a mesh GTK (MGTK) with a peer. The format of the Mesh Group Key Inform frame Action field is shown in Table 9-368. 1251 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-368â€”Mesh Group Key Inform frame Action field format Order Information Notes 1 Category 2 Self-protected Action 3 MIC element 4 Authenticated Mesh Peering Exchange The Category field is defined in 9.4.1.11. The Self-protected Action field is defined in 9.6.16.1. The MIC element is set as defined in 9.4.2.119. The Authenticated Mesh Peering Exchange element is set according to 14.6. The information following the MIC element through to the end of the Mesh Group Key Inform frame body is encrypted and authenticated (see 14.6.2). 9.6.16.6 Mesh Group Key Acknowledge frame format 9.6.16.6.1 Mesh Group Key Acknowledge frame self protection The protection of the frames is provided by the mesh group key handshake protocol (see 14.6) that uses Mesh Group Key Acknowledge frames. 9.6.16.6.2 Mesh Group Key Acknowledge frame details The Mesh Group Key Acknowledge frame is used to acknowledge receipt and processing of a Mesh Group Key Inform frame. The format of the Mesh Group Key Acknowledge frame Action field is shown in Table 9-369. Table 9-369â€”Mesh Group Key Acknowledge frame Action field format Order Information Notes 1 Category 2 Self-protected Action 3 MIC element 4 Authenticated Mesh Peering Exchange The Category field is defined in 9.4.1.11. The Self-protected Action field is defined in 9.6.16.1. The MIC element is set as defined in 9.4.2.119. 1252 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Authenticated Mesh Peering Exchange element is set according to 14.6. The information following the MIC element through to the end of the Mesh Group Key Acknowledge frame body is encrypted and authenticated (see 14.6.2). 9.6.17 Mesh Action frame details 9.6.17.1 Mesh Action fields Several Mesh Action frame formats are defined for mesh BSS operation. A Mesh Action field, in the octet field immediately after the Category field, differentiates the formats. The Mesh Action field values associated with each frame format are defined in Table 9-370. Table 9-370â€”Mesh Action field values Mesh Action field value Description 0 Mesh Link Metric Report 1 HWMP Mesh Path Selection 2 Gate Announcement 3 Congestion Control Notification 4 MCCA Setup Request 5 MCCA Setup Reply 6 MCCA Advertisement Request 7 MCCA Advertisement 8 MCCA Teardown 9 TBTT Adjustment Request 10 TBTT Adjustment Response 11â€“255 Reserved 9.6.17.2 Mesh Link Metric Report frame format The Mesh Link Metric Report frame is transmitted by a mesh STA to a neighbor peer mesh STA to report metric information on the link between the two mesh STAs. It is also transmitted by a mesh STA to a neighbor peer mesh STA to request metric information on the link between the two mesh STAs from the recipient. This frame is transmitted using an individually addressed frame. The format of the Mesh Link Metric Report frame Action field is shown in Table 9-371. Table 9-371â€”Mesh Link Metric Report frame Action field format Order Information Notes 1 Category 2 Mesh Action 3 Mesh Link Metric Report element 1253 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Category field is defined in 9.4.1.11. The Mesh Action field is defined in 9.6.17.1. The Mesh Link Metric Report element is set as described in 9.4.2.100. 9.6.17.3 HWMP Mesh Path Selection frame format The HWMP Mesh Path Selection frame is transmitted by a mesh STA to establish, update or delete paths to other mesh STAs using the HWMP defined in 14.10. This frame is transmitted in an individually or group addressed frame depending on the contained elements and as defined in 14.10.7. The format of the HWMP Mesh Path Selection frame Action field is shown in Table 9-372. The HWMP Mesh Path Selection frame contains one or more of the elements indicated in Table 9-372. Table 9-372â€”HWMP Mesh Path Selection frame Action field format Order Information Notes 1 Category 2 Mesh Action 3 PREQ element A PREQ element is optionally present 4 PREP element A PREP element is optionally present 5 PERR element A PERR element is optionally present 6 RANN element A RANN element is optionally present Usage of the HWMP Mesh Path Selection frame is described in 14.10.7. The Category field is defined in 9.4.1.11. The Mesh Action field is defined in 9.6.17.1. The PREQ element is set as described in 9.4.2.113. It is present in a HWMP Mesh Path Selection frame as described in 14.10.9. The PREP element is set as described in 9.4.2.114. The PERR element is set as described in 9.4.2.115. The RANN element is set as described in 9.4.2.112. 9.6.17.4 Gate Announcement frame format The Gate Announcement frame is transmitted by a mesh gate to announce its presence in the MBSS. This frame is transmitted using group addresses. The format of the Gate Announcement frame Action field is shown in Table 9-373. 1254 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-373â€”Gate Announcement frame Action field format Order Information Notes 1 Category 2 Mesh Action 3 GANN element The Category field is defined in 9.4.1.11. The Mesh Action field is defined in 9.6.17.1. The GANN element is set as described in 9.4.2.111. 9.6.17.5 Congestion Control Notification frame format A mesh STA uses the Congestion Control Notification frame to indicate its congestion status to its neighbor peer mesh STA(s). This frame is transmitted using individual addresses or group addresses. The format of the Congestion Control Notification frame Action field is shown in Table 9-374. Table 9-374â€”Congestion Control Notification frame Action field format Order Information Notes 1 Category 2 Mesh Action 3 Congestion Notification One or more Congestion Notification elements (9.4.2.101) are present. element Repeated N times (N is the number of Congestion Notification elements contained in the frame). The Category field is defined in 9.4.1.11. The Mesh Action field is defined in 9.6.17.1. The Congestion Notification element is set as described in 9.4.2.101. 9.6.17.6 MCCA Setup Request frame format The MCCA Setup Request frame is used to set up an MCCAOP reservation. A mesh STA (whose dot11MCCAActivated is true) transmits the MCCA Setup Request frame to one or more neighbor mesh STAs (whose dot11MCCAActivated values also are true). This frame is transmitted using individual addresses or group addresses. The format of the MCCA Setup Request frame Action field is shown in Table 9-375. The Category field is defined in 9.4.1.11. The Mesh Action field is defined in 9.6.17.1. The MCCAOP Setup Request element is described in 9.4.2.106. 1255 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-375â€”MCCA Setup Request frame Action field format Order Information Notes 1 Category 2 Mesh Action 3 MCCAOP Setup Request element 9.6.17.7 MCCA Setup Reply frame format The MCCA Setup Reply frame is used to reply to an MCCA Setup Request frame. It is transmitted by a mesh STA with dot11MCCAActivated equal to true to a neighbor peer mesh STA with dot11MCCAActivated equal to true. This frame is transmitted using individual addresses. The format of the MCCA Setup Reply frame Action field is shown in Table 9-376. Table 9-376â€”MCCA Setup Reply frame Action field format Order Information Notes 1 Category 2 Mesh Action 3 MCCAOP Setup Reply element The Category field is defined in 9.4.1.11. The Mesh Action field is defined in 9.6.17.1. The MCCAOP Setup Reply element is described in 9.4.2.107. 9.6.17.8 MCCA Advertisement Request frame format The MCCA Advertisement Request frame is transmitted by a mesh STA with dot11MCCAActivated equal to true to a neighbor peer mesh STA with dot11MCCAActivated equal to true in order to request MCCAOP advertisements from the neighbor peer mesh STA. This frame is transmitted using individual addresses. The format of the MCCA Advertisement Request frame Action field is shown in Table 9-377. Table 9-377â€”MCCA Advertisement Request frame Action field format Order Information Notes 1 Category 2 Mesh Action 3 MCCAOP Advertisement An MCCAOP Advertisement Overview element is optionally present. Overview element The Category field is defined in 9.4.1.11. 1256 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Mesh Action field is defined in 9.6.17.1. The MCCAOP Advertisement Overview element is described in 9.4.2.108. 9.6.17.9 MCCA Advertisement frame format The MCCA Advertisement frame is transmitted by a mesh STA with dot11MCCAActivated equal to true to one or more neighbor peer mesh STAs with dot11MCCAActivated equal to true. This frame is transmitted using group addresses or individual addresses. The format of the MCCA Advertisement frame Action field is shown in Table 9-378. Table 9-378â€”MCCA Advertisement frame Action field format Order Information Notes 1 Category 2 Mesh Action 3 MCCAOP Advertisement An MCCAOP Advertisement Overview element is optionally present. Overview element 4 MCCAOP Advertisement If an MCCAOP Advertisement Overview element is present, zero or elements more MCCAOP Advertisement elements are present. If an MCCAOP Advertisement Overview element is not present, one or more MCCAOP Advertisement elements are present. The Category field is defined in 9.4.1.11. The Mesh Action field is defined in 9.6.17.1. The MCCAOP Advertisement Overview element is described in 9.4.2.108. The MCCAOP Advertisement element is described in 9.4.2.109. 9.6.17.10 MCCA Teardown frame format The MCCA Teardown frame is transmitted by a mesh STA with dot11MCCAActivated equal to true to one or more neighbor peer mesh STAs with dot11MCCAActivated equal to true. This frame is transmitted using group addresses or individual addresses. The format of the MCCA Teardown frame Action field is shown in Table 9-379. Table 9-379â€”MCCA Teardown frame Action field format Order Information Notes 1 Category 2 Mesh Action 3 MCCAOP Teardown element The Category field is defined in 9.4.1.11. 1257 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Mesh Action field is defined in 9.6.17.1. The MCCAOP Teardown element is described in 9.4.2.110. 9.6.17.11 TBTT Adjustment Request frame format The TBTT Adjustment Request frame is used to request a particular neighbor peer mesh STA to adjust its TBTT. This frame is transmitted using individual addresses. The format of the TBTT Adjustment Request frame Action field is shown in Table 9-380. Table 9-380â€”TBTT Adjustment Request frame Action field format Order Information Notes 1 Category 2 Mesh Action 3 Beacon Timing element Repeated N_Info times (N_Info is a number of beacon timing information tuples as described in 14.13.4.2.5). The Category field is defined in 9.4.1.11. The Mesh Action field is defined in 9.6.17.1. The Beacon Timing element is set as described in 9.4.2.105. When not all beacon timing information is included in a Beacon Timing element due to the maximum element size limit, multiple Beacon Timing elements are present. The elements are present in the order of Beacon Timing Element Number field value in the Report Control field of the Beacon Timing element. 9.6.17.12 TBTT Adjustment Response frame format The TBTT Adjustment Response frame is used to respond to a TBTT adjustment request. This frame is transmitted using individual addresses. The format of the TBTT Adjustment Response frame Action field is shown in Table 9-381. Table 9-381â€”TBTT Adjustment Response frame Action field format Order Information Notes 1 Category 2 Mesh Action 3 Status Code 4 Beacon Timing element Repeated N_Info times (N_Info is a number of beacon timing (optional) information tuples as described in 14.13.4.2.5). The Category field is defined in 9.4.1.11. The Mesh Action field is defined in 9.6.17.1. 1258 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Status Code field is set as described in 14.13.4.4.2. The Beacon Timing element is set as defined in 9.4.2.105. It is present only if the Status Code is set to CANNOT_FIND_ALTERNATIVE_TBTT (i.e., when the request is not successful due to the neighbor constraint). When not all beacon timing information is included in a Beacon Timing element due to the maximum element size limit, multiple Beacon Timing elements are present. The elements are present in the order of Beacon Timing Element Number field value in the Report Control field of the Beacon Timing element. 9.6.18 Multihop Action frame details 9.6.18.1 Multihop Action fields Several Multihop Action frame formats are defined for mesh BSS operation. A Multihop Action field, in the octet field immediately after the Category field, differentiates the formats. The Multihop Action field values associated with each frame format are defined in Table 9-382. The Mesh Control field is present immediately after the Multihop Action field in all Multihop Action frames. Table 9-382â€”Multihop Action field values Multihop Action field value Description 0 Proxy Update 1 Proxy Update Confirmation 2â€“255 Reserved 9.6.18.2 Proxy Update frame format The Proxy Update frame is used to inform the recipient about new, updated, or deleted proxy information. This frame is transmitted using individual addresses. The format of the Proxy Update frame Action field is shown in Table 9-383. Table 9-383â€”Proxy Update frame Action field format Order Information Notes 1 Category 2 Multihop Action 3 Mesh Control 4 PXU element Repeated N times (N is the number of PXU elements contained in the frame). The Category field is defined in 9.4.1.11. The Multihop Action field is defined in 9.6.18.1. The Mesh Control field is set as defined in 9.2.4.7.3. 1259 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The PXU element is described in 9.4.2.116. The Proxy Update frame allows the inclusion of multiple PXU elements. 9.6.18.3 Proxy Update Confirmation frame format The Proxy Update Confirmation frame is transmitted by a mesh STA in response to a Proxy Update frame. This frame is used to inform that the corresponding PXU element has been properly received and is transmitted using individual addresses. The format of the Proxy Update Confirmation frame Action field is shown in Table 9-384. Table 9-384â€”Proxy Update Confirmation frame Action field format Order Information Notes 1 Category 2 Multihop Action 3 Mesh Control 4 PXUC element Repeated N times (N is the number of PXUC elements contained in the frame). The Category field is defined in 9.4.1.11. The Multihop Action field is defined in 9.6.18.1. The Mesh Control field is set as defined in 9.2.4.7.3. The PXUC element is described in 9.4.2.117. The Proxy Update Confirmation frame allows the inclusion of one or more PXUC elements. 9.6.19 Robust AV Streaming Action frame details 9.6.19.1 General Several Action frame formats are defined to support robust AV streaming. The Robust Action field values associated with each frame format within the robust AV streaming category are defined in Table 9-385. The frame formats are defined in 9.6.19.2 to 9.6.19.5. Table 9-385â€”Robust AV streaming Robust Action field values Robust Action field value Meaning 0 SCS Request 1 SCS Response 2 Group Membership Request 3 Group Membership Response 4â€“255 Reserved 1260 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.6.19.2 SCS Request frame format SCS Request frames are used to request the creation, modification, or deletion of a stream classification using the procedures defined in 11.27.2. The Action field of the SCS Request frame contains the information shown in Figure 9-731. Category Robust Action Dialog Token SCS Descriptor List Octets: 1 1 1 variable Figure 9-731â€”SCS Request frame Action field format The Category field is defined in 9.4.1.11. The Robust Action field is defined in 9.6.19.1. The Dialog Token field is defined in 9.4.1.12 and set by the requesting STA to a nonzero value that is used for matching action responses with action requests. See 10.27.5. The SCS Descriptor List field contains one or more SCS Descriptor elements, as defined in 9.4.2.122. 9.6.19.3 SCS Response frame format The SCS Response frame is sent in response to an SCS Request frame using the procedures defined in 11.27.2. The Action field of an SCS Response frame contains the information shown in Figure 9-732. Category Robust Action Dialog Token SCS Status List Octets: 1 1 1 variable Figure 9-732â€”SCS Response frame Action field format The Category field is defined in 9.4.1.11. The Robust Action field is defined in 9.6.19.1. The Dialog Token field is set to the nonzero value of the corresponding SCS Request frame. If the SCS Report frame is being transmitted for a reason other than in response to an SCS Request frame, then the Dialog Token field is set to 0. The SCS Status List field contains one or more SCS Status duples. The format of the SCS Status duple is defined in Figure 9-733. SCSID Status Octets: 1 2 Figure 9-733â€”SCS Status duple format The SCSID field is set to the value of the SCSID field in the SCS Descriptor element received in the SCS Request frame. 1261 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Status field indicates the status of the requested SCSID, as indicated in Table 9-46. 9.6.19.4 Group Membership Request frame format The Group Membership Request frame is sent to a STA to request the contents of its dot11GroupAddressesTable. The Action field of a Group Membership Request frame contains the information shown in Figure 9-734. Category Robust Action Dialog Token Octets: 1 1 1 Figure 9-734â€”Group Membership Request frame Action field format The Category field is defined in 9.4.1.11. The Robust Action field is defined in 9.6.19.1. The Dialog Token field is defined in 9.4.1.12 and set by the requesting STA to a nonzero value that is used for matching action responses with action requests. See 10.27.5. Usage of the Group Membership Request frame is described in 11.24.16.3.2. 9.6.19.5 Group Membership Response frame format The Group Membership Response frame is sent in response to a Group Membership Request frame or upon a change in the dot11GroupAddressesTable object, using the procedures defined in 11.24.16.3.2. The Action field of a Group Membership Response frame contains the information shown in Figure 9-735. Category Robust Action Dialog Token Address Count Group Address List Octets: 1 1 1 1 variable Figure 9-735â€”Group Membership Response frame Action field format The Category field is defined in 9.4.1.11. The Robust Action field is defined in 9.6.19.1. The Dialog Token field is set to the nonzero value of the corresponding Group Membership Request frame. If the Group Membership Report frame is being transmitted for a reason other than in response to a Group Membership Request frame, the Dialog Token field is set to 0. The Address Count field specifies the number of MAC addresses that are in the Group Address List field. The Group Address List field contains zero or more MAC addresses to indicate the set of group addressed MAC addresses for which the STA receives frames. Each MAC address is 6 octets in length, as described in 9.2.4.3.2. 1262 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.6.20 DMG Action frame details 9.6.20.1 DMG Action field Several Action frame formats are defined to support DMG features. A DMG Action field, in the octet immediately after the Category field, differentiates the DMG Action frame formats. The DMG Action field values associated with each frame format within the DMG category are defined in Table 9-386. Table 9-386â€”DMG Action field values DMG Action field value Meaning 0 Power Save Configuration Request 1 Power Save Configuration Response 2 Information Request 3 Information Response 4 Handover Request 5 Handover Response 6 DTP Request 7 DTP Response 8 Relay Search Request 9 Relay Search Response 10 Multi-Relay Channel Measurement Request 11 Multi-Relay Channel Measurement Report 12 RLS Request 13 RLS Response 14 RLS Announcement 15 RLS Teardown 16 Relay Ack Request 17 Relay Ack Response 18 TPA Request 19 TPA Response 20 TPA Report 21 ROC Request 22 ROC Response 9.6.20.2 Power Save Configuration Request frame format The format of the Power Save Configuration Request (PSC-REQ) frame Action field is shown in Table 9-387. 1263 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-387â€”Power Save Configuration Request frame Action field format Order Information 1 Category 2 DMG Action 3 Dialog Token 4 DMG Power Management 5 DMG Wakeup Schedule element (optional) The Category field is defined in 9.4.1.11. The DMG Action field is defined in 9.6.20.1. The Dialog Token field is set to a value chosen by the STA sending the frame to uniquely identify the transaction. The length of the DMG Power Management (DPM) field is one octet. Setting the DPM field to 0 indicates a transition from power save mode to active mode. Setting the DPM field to 1 indicates a transition from active mode to power save mode. All other values are reserved. The DMG Wakeup Schedule element is defined in 9.4.2.131 (11.2.7.2). 9.6.20.3 Power Save Configuration Response frame format The format of the Power Save Configuration Response (PSC-RSP) frame Action field is shown in Table 9-388. Table 9-388â€”Power Save Configuration Response frame Action field format Order Information 1 Category 2 DMG Action 3 Dialog Token 4 Status Code 5 DMG Wakeup Schedule element (optional) 6 Antenna Sector ID Pattern element (optional) The Category field is defined in 9.4.1.11. The DMG Action field is defined in 9.6.20.1. The Dialog Token field is set to the value of the Dialog Token field in the corresponding PSC-REQ frame. The Status Code field is defined in 9.4.1.9. 1264 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The DMG Wakeup Schedule element is defined in 9.4.2.131. The Antenna Sector ID Pattern element is defined in 9.4.2.157. 9.6.20.4 Information Request frame format The Information Request frame is an Action frame of category DMG. The format of an Information Request frame Action field is shown in Table 9-389. Table 9-389â€”Information Request frame Action field format Order Information 1 Category 2 DMG Action 3 Subject Address 4 Request element 5 Zero or more DMG Capabilities elements 6 Zero or more provided elements 7 Zero or more Extended Request elements The Category field is defined in 9.4.1.11. The DMG Action field is defined in 9.6.20.1. The Subject Address field contains the MAC address of the STA whose information is being requested. If this frame is sent to the PCP and the value of the Subject Address field is the broadcast address, then the STA is requesting information regarding all associated STAs. The Request element field is described in 9.4.2.10. The DMG Capabilities element carries information about the transmitter STA and other STAs known to the transmitter STA. The format of this element is defined in 9.4.2.128. Each provided element is an element as specified in 9.4.2, that the transmitter of this frame is providing to the destination of the frame. The Extended Request element is described in 9.4.2.11. 9.6.20.5 Information Response frame format The Information Response frame is an Action frame of category DMG. The format of an Information Response frame Action field is shown in Table 9-390. This frame is individually addressed to a STA in response to an Information Request frame or it is sent unsolicited and individually addressed to a STA or broadcast to all STAs in the PBSS/infrastructure BSS. If this frame is sent as a broadcast, then this frame is an Action No Ack frame. 1265 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-390â€”Information Response frame Action field format Order Information 1 Category 2 DMG Action 3 Subject Address 4 One or more DMG Capabilities elements 5 Zero or more requested elements 6 Zero or more provided elements The Category field is defined in 9.4.1.11. The DMG Action field is defined in 9.6.20.1. The Subject Address field contains the MAC address of the STA whose information is being provided. If this field is set to the broadcast address, then the STA is providing information regarding all associated STAs. The DMG Capabilities element carries information about the transmitter STA and other STAs known to the transmitter STA. The DMG Capabilities element is described in 9.4.2.128. The requested elements are those returned in response to an Information Request frame, as described in 11.30.1. The provided elements are elements, as described in 9.4.2, that the transmitter of this frame provides to the destination of the frame, either in addition to the requested elements, or in an unsolicited Information Response frame. 9.6.20.6 Handover Request frame format The Handover Request frame is an Action frame of category DMG. The format of the Handover Request frame Action field is shown in Table 9-391. Table 9-391â€”Handover Request frame Action field format Order Information 1 Category 2 DMG Action 3 Handover Reason 4 Handover Remaining BI The Category field is defined in 9.4.1.11. The DMG Action field is defined in 9.6.20.1. 1266 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Handover Reason field is 1 octet in length and indicates the reason that the current PCP intends to do the PCP handover. The Handover Reason field is set to 0 to indicate the PCP is leaving the PBSS, it is set to 1 to indicate low power in the PCP, is set to 2 to indicate that a more qualified PCP handover capable STA is available, and is set to 3 to indicate that the PCP handover capable STA wishes to become a PCP. The other values are reserved. The Handover Remaining BI field is 1 octet in length and indicates the number of beacon intervals, excluding the beacon interval in which this frame is transmitted, remaining until the handover takes effect. 9.6.20.7 Handover Response frame format The Handover Response frame is an Action frame of category DMG. The format of the Handover Response frame Action field is shown in Table 9-392. Table 9-392â€”Handover Response frame Action field format Order Information 1 Category 2 DMG Action 3 Handover Result 4 Handover Reject Reason The Category field is defined in 9.4.1.11. The DMG Action field is defined in 9.6.20.1. The Handover Result field is 1 octet in length and indicates whether the STA accepted the handover request. A value of 0 indicates that the STA accepts the handover request. A value of 1 indicates that the STA does not accept the handover request. If the Handover Result field is set to 0, the Handover Reject Reason field is reserved and set to 0. If the Handover Result field is set to 1, the Handover Reject Reason field indicates the reason the STA rejected the handover request and can be one of the following: 0 for low power, 1 for handover in progress with another STA, 2 for invalid value for Handover Remaining BI field, and 3 for unspecified reason. The length of Handover Reject Reason field is 1 octet. 9.6.20.8 DTP Request frame format The DTP Request frame is transmitted to request DTP information. The format of the DTP Request frame Action field is shown in Figure 9-736. Category DMG Action Dialog Token Octets: 1 1 1 Figure 9-736â€”DTP Request frame Action field format The Category field is defined in 9.4.1.11. 1267 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The DMG Action field is defined in 9.6.20.1. The Dialog Token field is set to a nonzero value chosen by the STA sending the request to identify the transaction. 9.6.20.9 DTP Report frame format The DTP Report frame is transmitted in response to a DTP Request frame. A DTP Report frame can also be sent unsolicited. The format of the DTP Report frame Action field is shown in Figure 9-737. Category DMG Action Dialog Token DTP Report Octets: 1 1 1 34 Figure 9-737â€”DTP Report frame Action field format The Category field is defined in 9.4.1.11. The DMG Action field is defined in 9.6.20.1. The Dialog Token field is set to the value of the Dialog Token field in the corresponding DTP Request frame. If the DTP Report frame is not being transmitted in response to a DTP Request frame, the Dialog Token field is set to 0. The DTP Report element is defined in 9.4.2.146. 9.6.20.10 Relay Search Request frame format The Relay Search Request frame is transmitted by a non-AP and non-PCP STA to the AP or PCP to request a list of RDSs in the BSS. The format of the Relay Search Request frame Action field is shown in Table 9-393. Table 9-393â€”Relay Search Request frame Action field format Order Information 1 Category 2 DMG Action 3 Dialog Token 4 Destination REDS AID The Category field is defined in 9.4.1.11. The DMG Action field is defined in 9.6.20.1. The Dialog Token field is set to a nonzero value chosen by the STA sending the Relay Search Request frame to identify the request/response transaction. The Destination REDS AID field is set to the AID of the target destination REDS. The structure of the field is defined in 9.4.1.8. 1268 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.6.20.11 Relay Search Response frame format The Relay Search Response frame is sent by an AP or PCP in response to a Relay Search Request frame. The format of a Relay Search Response frame Action field is shown in Table 9-394. Table 9-394â€”Relay Search Response frame Action field format Order Information 1 Category 2 DMG Action 3 Dialog Token 4 Status Code 5 Number of Relay Capable STAs 6 Zero or more Relay Capable STA Info fields The Category field is defined in 9.4.1.11. The DMG Action field is defined in 9.6.20.1. The Dialog Token field is set to the value in the corresponding Relay Search Request frame that generated this response. The Status Code field is defined in 9.4.1.9. The Number of Relay Capable STAs field is one octet in length and indicates the number of STAs in the BSS that are relay capable. The value of this field is zero if the Status Code does not indicate success. The Relay Capable STA Info field is defined in 9.4.1.45. This information is included only if the status code indicates successful. The number of Relay Capable STA Info fields that appear in the frame is indicated by the value of the Number of Relay Capable STAs field. 9.6.20.12 Multi-relay Channel Measurement Request frame format The Multi-Relay Channel Measurement Request frame is transmitted by a STA initiating relay operation to the recipient STA in order to obtain Channel Measurements between the recipient STA and the other STA participating in the relay operation. The format of the Multi-Relay Channel Measurement Request frame Action field is shown in Table 9-395. Table 9-395â€”Multi-relay Channel Measurement Request frame Action field format Order Information 1 Category 2 DMG Action 3 Dialog Token 1269 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Category field is defined in 9.4.1.11. The DMG Action field is defined in 9.6.20.1. The Dialog Token field is set to a nonzero value chosen by the STA sending the Multi-Relay Channel Measurement Request frame to identify the request/report transaction. 9.6.20.13 Multi-relay Channel Measurement Report frame format The Multi-Relay Channel Measurement Report frame is sent in response to a Multi-Relay Channel Measurement Request. The format of the Multi-Relay Channel Measurement Report frame Action field is shown in Table 9-396. Table 9-396â€”Multi-relay Channel Measurement Report frame Action field format Order Information 1 Category 2 DMG Action 3 Dialog Token 4 Number of Channel Measurement Info 5 One or more Channel Measurement Info fields The Category field is defined in 9.4.1.11. The DMG Action field is defined in 9.6.20.1. The Dialog Token field is set to the value in any corresponding Multi-Relay Channel Measurement Request frame. If the Multi-Relay Channel Measurement Report frame is not being transmitted in response to a Multi-Relay Channel Measurement Request frame, then the dialog token is set to 0. The Number of Channel Measurement Info field is one octet in length and indicates the number of Channel Measurements Info fields included in the frame. The format of the Channel Measurement Info field is defined in Figure 9-738. The number of Channel Measurement Info fields included in the frame is indicated by the value of the Number of Channel Measurement Info field. Multiple Channel Measurement Info fields can be included if the reporting STA measures the channel for multiple RDSs. B0 B7 B8 B15 B16 B22 B23 B24 B31 Peer STA AID SNR Internal Angle Recommend Reserved Bits: 8 8 7 1 8 Figure 9-738â€”Channel Measurement Info field format The Peer STA AID subfield contains the AID of the STA toward which the reporting STA measures link. 1270 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The SNR subfield indicates the SNR measured in the link toward the STA corresponding to Peer STA AID. This subfield is encoded as 8-bit 2s complement value of 4x(SNR-19), where SNR is measured in dB. This covers from â€“13 dB to 50.75 dB in 0.25 dB steps. The Internal Angle subfield indicates the angle between directions toward the other STAs involved in the relay operation. This covers from 0Â° to 180Â° in 2Â° steps. This subfield uses the degree of the direction from the sector that the feedbacks indicates has highest quality during TXSS if SLS phase of BF is performed and RXSS is not included. The Recommend subfield indicates whether the responding STA recommends relay operation based on the channel measurement with the Peer STA. This subfield is set to 1 when the relay operation is recommended and otherwise is set to 0. 9.6.20.14 RLS Request frame format The RLS Request frame is used to set up a relay link. The format of the RLS Request frame Action field is shown in Table 9-397. Table 9-397â€”RLS Request frame Action field format Order Information 1 Category 2 DMG Action 3 Dialog Token 4 Destination AID 5 Relay AID 6 Source AID 7 Destination Capability Information 8 Relay Capability Information 9 Source Capability Information 10 Relay Transfer Parameter Set The Category field is defined in 9.4.1.11. The DMG Action field is defined in 9.6.20.1. The Dialog Token field is set to a nonzero value chosen by the STA sending the RLS Request frame to identify the request/response transaction. The Destination AID field value is the AID of the target destination. The Relay AID field value is the AID of the selected RDS. The Source AID field value is the AID of the initiating STA. 1271 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Destination Capability Information field indicates the Relay Capability Information field within the Relay Capabilities element of the target destination REDS as defined in 9.4.2.148. The Relay Capability Information field indicates the Relay Capability Information field within the Relay Capabilities element of the selected RDS as defined in 9.4.2.148. The Source Capability Information field indicates the Relay Capability Information field within the Relay Capabilities element of the originator of the request as defined in 9.4.2.148. The Relay Transfer Parameter Set element is defined in 9.4.2.149. 9.6.20.15 RLS Response frame format The RLS Response frame is sent in response to an RLS Request frame. The format of an RLS Response frame Action field is shown in Table 9-398. Table 9-398â€”RLS Response frame Action field format Order Information 1 Category 2 DMG Action 3 Dialog Token 4 Destination Status Code 5 Relay Status Code (optional) The Category field is defined in 9.4.1.11. The DMG Action field is defined in 9.6.20.1. The Dialog Token field is set to the value in any corresponding RLS Request frame. The Destination Status Code field is included when the destination REDS transmits an RLS Response frame as a result of RLS Request. It is defined in 9.4.1.9. The Relay Status Code field is included when the relay REDS transmits an RLS Response frame as a result of RLS Request. It is defined in 9.4.1.9. 9.6.20.16 RLS Announcement frame format The RLS Announcement frame is sent to announce the successful RLS. The format of an RLS Announcement frame Action field is shown in Table 9-399. 1272 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-399â€”RLS Announcement frame Action field format Order Information 1 Category 2 DMG Action 3 Status Code 4 Destination AID 5 Relay AID 6 Source AID The Category field is defined in 9.4.1.11. The DMG Action field is defined in 9.6.20.1. The Status Code field is defined in 9.4.1.9. The Destination AID field value is the AID of the target destination. The Relay AID field value is the AID of the RDS. The Source AID field value is the AID of the initiating STA. 9.6.20.17 RLS Teardown frame format The RLS Teardown frame is sent to terminate a relay operation. The format of the RLS Teardown frame Action field is shown in Table 9-400. Table 9-400â€”RLS Teardown frame Action field format Order Information 1 Category 2 DMG Action 3 Destination AID 4 Relay AID 5 Source AID 6 Reason Code The Category field is defined in 9.4.1.11. The DMG Action field is defined in 9.6.20.1. The Destination AID field value is the AID of the destination REDS. 1273 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Relay AID field value is the AID of the RDS. The Source AID field value is the AID of the source REDS. The Reason Code field is defined in 9.4.1.7. 9.6.20.18 Relay Ack Request frame format The Relay Ack Request frame is sent by a source REDS to an RDS participating in a relay operation in order to determine whether all frames forwarded through the RDS were received by the destination REDS also participating in the relay operation. This frame is used only when the RDS is operated in HD-DF mode and relay operation is link switching. The format of the Relay Ack Request frame Action field is shown in Table 9-401. Table 9-401â€”Relay Ack Request frame Action field format Order Information 1 Category 2 DMG Action 3 BAR Control 4 BlockAck Starting Sequence Control The Category field is defined in 9.4.1.11. The DMG Action field is defined in 9.6.20.1. The BAR Control field and BlockAck Starting Sequence Control fields are defined in 9.3.1.8. 9.6.20.19 Relay Ack Response frame format The Relay Ack Response frame is sent by an RDS to a source REDS participating in a relay operation in order to report which frames have been received by the destination REDS also participating in the relay operation. This frame is used only when the RDS is operated in HD-DF mode and relay operation is link switching. The format of the Relay Ack Response frame Action field is shown in Table 9-402. Table 9-402â€”Relay Ack Response frame Action field format Order Information 1 Category 2 DMG Action 3 BA Control 4 BlockAck Starting Sequence Control 5 BlockAck Bitmap 1274 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Category field is defined in 9.4.1.11. The DMG Action field is defined in 9.6.20.1. The BA Control field is defined in 9.3.1.9. The BlockAck Starting Sequence Control field is defined in 9.3.1.9 and is set to the corresponding value within the immediately previously received Relay Ack Request frame. The BlockAck Bitmap field is defined in 9.3.1.9. 9.6.20.20 TPA Request frame format The TPA Request frame is sent by a destination REDS participating in operation based on link cooperation to both the RDS and source REDS that belong to the same group as the destination REDS in order for them to send back their own TPA Response frames at the separately predefined times. Also, a source REDS sends a TPA Request frame to the RDS that is selected by the source REDS in order for the RDS to feedback its own TPA Response frame at the pre-defined time. The format of the TPA Request frame Action field is shown in Table 9-403. Table 9-403â€”TPA Request frame Action field format Order Information 1 Category 2 DMG Action 3 Dialog Token 4 Timing Offset 5 Sampling Frequency Offset The Category field is defined in 9.4.1.11. The DMG Action field is defined in 9.6.20.1. The Dialog Token field is set to a nonzero value chosen by the STA sending the TPA Request frame to identify the request/response transaction. The Timing Offset field is 2 octets in length and indicates the amount of time, in nanoseconds, that the STA identified in the RA of the frame is required to change the timing offset of its transmissions so that they arrive at the expected time at the transmitting STA. The Sampling Frequency Offset field is 2 octets in length and indicates the amount by which to change the sampling frequency offset of the burst transmission so that bursts arrive at the destination DMG STA with no sampling frequency offset. The unit is 0.01 ppm. 9.6.20.21 TPA Response frame format The TPA Response frame is sent by an RDS or a source REDS participating in relay operation in response to a TPA Request frame from a destination REDS or a source REDS. The RDS or the source REDS that 1275 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications receives a TPA Request frame responds to the destination REDS or the source REDS, as appropriate, with a TPA Response frame at a predetermined time from the end of the TPA Request frame (see 11.36). The format of the TPA Response frame Action field is shown in Table 9-404. Table 9-404â€”TPA Response frame Action field format Order Information 1 Category 2 DMG Action 3 Dialog Token The Category field is defined in 9.4.1.11. The DMG Action field is defined in 9.6.20.1. The Dialog Token field is set to the value of the Dialog Token field of the TPA Request frame that generated this response. 9.6.20.22 TPA Report frame format The TPA Report frame is sent to announce whether a TPA procedure is successful. The format of the TPA Report frame Action field is shown in Table 9-405. Table 9-405â€”TPA Report frame Action field format Order Information 1 Category 2 DMG Action 3 Status code The Category field is defined in 9.4.1.11. The DMG Action field is defined in 9.6.20.1. The Status Code field indicates the result of the current TPA procedure and is defined in 9.4.1.9. 9.6.20.23 ROC Request frame format The ROC Request frame is sent by the source REDS participating in a relay operation in order to request a change in the current relay operation type. The format of the ROC Request frame Action field is shown in Table 9-406. 1276 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-406â€”ROC Request frame Action field format Order Information 1 Category 2 DMG Action 3 Dialog Token 4 Relay Operation Type The Category field is defined in 9.4.1.11. The DMG Action field is defined in 9.6.20.1. The Dialog Token field is set to a nonzero value chosen by the STA sending the ROC Request frame to identify the request/response transaction. The format of the Relay Operation Type field is defined in Figure 9-739. B0 B1 B2 B7 Link Cooperation Relay-link Reserved Bits: 1 1 6 Figure 9-739â€”Relay Operation Type field format The Link Cooperation subfield is set to 0 to request the operation to be changed to link switching and is set to 1 to request the operation to be changed to link cooperation. The Relay-link subfield is set to 0 to indicate that the link switching operation starts at the direct link between the source REDS and destination REDS and set to 1 to indicate that the link switching operation starts with the RDS. If the Link Cooperation subfield is set to 1, the Relay-link subfield is reserved. 9.6.20.24 ROC Response frame format The ROC Response frame is sent by the RDS or the destination DMG STA participating in a relay operation in response to a ROC Request frame from the source DMG STA. The format of the ROC Response frame Action field is shown in Table 9-407. Table 9-407â€”ROC Response frame Action field format Order Information 1 Category 2 DMG Action 3 Dialog Token 4 Status Code 1277 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Category field is defined in 9.4.1.11. The DMG Action field is defined in 9.6.20.1. The Dialog Token field is set to the value received in the corresponding ROC Request frame that generated this response. The Status Code field is defined in 9.4.1.9. 9.6.21 FST Action frame details 9.6.21.1 FST Action field The FST Action field values are defined in Table 9-408. Table 9-408â€”FST Action field values FST Action field value Meaning 0 FST Setup Request 1 FST Setup Response 2 FST Teardown 3 FST Ack Request 4 FST Ack Response 5 On-channel Tunnel Request 9.6.21.2 FST Setup Request frame format The FST Setup Request frame is an Action frame of category FST. The FST Setup Request frame allows an initiating STA to announce to a peer STA whether the initiating STA intends to enable FST for the session between the initiating STA and the peer STA (11.33). The format of the FST Setup Request frame Action field is shown in Table 9-409. Table 9-409â€”FST Setup Request frame Action field format Order Information 1 Category 2 FST Action 3 Dialog Token 4 LLT 5 Session Transition 6 Multi-band (optional) 7 DMG Wakeup Schedule (optional) 1278 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-409â€”FST Setup Request frame Action field format (continued) Order Information 8 Awake Window (optional) 9 Switching Stream (optional) 10 Zero or more additional elements are present, as defined in 11.33.1. Each of these elements is not present more than once in the frame. The Category field is defined in 9.4.1.11. The FST Action field is defined in 9.6.21.1. The Dialog Token field is set to a nonzero value chosen by the STA. The Link loss timeout (LLT) field is 32 bits and indicates the compressed maximum duration counted from the last time an MPDU was received by the initiating STA from the peer STA until the initiating STA decides to initiate FST. The use of this field is described in 11.33. The Session Transition field contains the Session Transition element as defined in 9.4.2.145. The Multi-band field contains the Multi-Band element as defined in 9.4.2.138. The regulatory information contained in the Multi-band element is applicable to all of the fields and elements contained in the frame. The DMG Wakeup Schedule element is defined in 9.4.2.131. The Awake Window element is defined in 9.4.2.137. The Switching Stream element is defined in 9.4.2.144. 9.6.21.3 FST Setup Response frame format The FST Setup Response frame is an Action frame of category FST. This frame is transmitted in response to the reception of an FST Setup Request frame. The format of the frame Action field is shown in Table 9-410. Table 9-410â€”FST Setup Response frame Action field format Order Information 1 Category 2 FST Action 3 Dialog Token 4 Status Code 5 Session Transition 6 Multi-band (optional) 7 DMG Wakeup Schedule (optional) 1279 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-410â€”FST Setup Response frame Action field format (continued) Order Information 8 Awake Window (optional) 9 Switching Stream (optional) 10 Timeout Interval (optional) 11 Zero or more additional elements are present, as defined in 11.33.1. Each of these elements is not present more than once in the frame. The Category field is defined in 9.4.1.11. The FST Action field is defined in 9.6.21.1. The Dialog Token field value is copied from the corresponding received FST Setup Request frame. The Status Code field is defined in 9.4.1.9. The Session Transition field contains the Session Transition element as defined in 9.4.2.145. The Multi-band element is defined in 9.4.2.138. The DMG Wakeup Schedule element is defined in 9.4.2.131. The Awake Window element is defined in 9.4.2.137 The Switching Stream element is defined in 9.4.2.144. The Timeout Interval element is defined in 9.4.2.49. 9.6.21.4 FST Teardown frame format The FST Teardown frame is an Action frame of category FST. This frame is transmitted to delete an established FST session between STAs. The format of the frame Action field is shown in Table 9-411. Table 9-411â€”FST Teardown frame Action field format Order Information 1 Category 2 FST Action 3 FSTS ID The Category field is defined in 9.4.1.11. The FST Action field is defined in 9.6.21.1. 1280 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The FSTS ID field contains the identification of the FST session established between the STAs identified by the TA and RA fields of this frame. The format of the FSTS ID field is as specified 9.4.2.145. 9.6.21.5 FST Ack Request frame format The FST Ack Request frame is an Action frame of category FST. This frame is transmitted in the frequency band an FST session is transferred to and confirms the FST. The format of the frame Action field is shown in Table 9-412. Table 9-412â€”FST Ack Request frame Action field format Order Information 1 Category 2 FST Action 3 Dialog Token 4 FSTS ID The Category field is defined in 9.4.1.11. The FST Action field is defined in 9.6.21.1. The Dialog Token field is set to a nonzero value chosen by the STA sending the FST Ack request to identify the request/report transaction. The FSTS ID field contains the identification of the FST session established between the STAs identified by the TA and RA fields of this frame. The format of the FSTS ID field is as specified in 9.4.2.145. 9.6.21.6 FST Ack Response frame format The FST Ack Response frame is an Action frame of category FST. This frame is transmitted in response to the reception of an FST Ack Request frame. The format of the frame Action field is shown in Table 9-413. Table 9-413â€”FST Ack Response frame Action field format Order Information 1 Category 2 FST Action 3 Dialog Token 4 FSTS ID The Category field is defined in 9.4.1.11. The FST Action field is defined in 9.6.21.1. 1281 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Dialog Token field is set to the value in any corresponding FST Ack Request frame. If the FST Ack Response frame is not being transmitted in response to an FST Ack Request frame, then the dialog token is set to 0. The FSTS ID field contains the identification of the FST session established between the STAs identified in the TA and RA fields of this frame. The format of the FSTS ID field is as specified in 9.4.2.145. 9.6.21.7 On-channel Tunnel Request frame format The On-channel Tunnel Request frame is an Action frame of category FST. The On-channel Tunnel Request frame allows a STA of a multi-band device to encapsulate an MMPDU for transmission to an MLME of a peer STA within the same multi-band device (11.33), which can be used to perform multi-band association and multi-band authentication. The format of the On-channel Tunnel Request frame Action field is shown in Table 9-414. Table 9-414â€”On-channel Tunnel Request frame Action field format Order Information 1 Category 2 FST Action 3 OCT MMPDU 4 Multi-band The Category field is defined in 9.4.1.11. The FST Action field is defined in 9.6.21.1. The OCT MMPDU field is defined in Figure 9-740. MMPDU Length MMPDU Frame Control MMPDU Frame Body Octets: 2 2 Variable Figure 9-740â€”Definition of the OCT MMPDU field The MMPDU Length subfield contains the length in octets of the MMPDU Frame Body subfield. The MMPDU Frame Control subfield carries the content of the Frame Control field of an MMPDU that would be constructed if the MMPDU for the corresponding management frame type were transmitted over the air. The MMPDU Frame Body subfield carries the content of the Frame Body field of an MMPDU that would be constructed if the MMPDU for the corresponding management frame type were transmitted over the air (i.e., all of the octets after the MAC header and up to, but not including, the FCS). The Multi-band field contains the Multi-band element (see 9.4.2.138) of the peer MLME to which the OCT MMPDU is destined to. The channel, frequency band and MAC address contained in this element are used to deliver the OCT MMPDU to the correct MLME within the peer STA. 1282 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.6.22 Unprotected DMG Action frame details 9.6.22.1 Unprotected DMG Action field Unprotected DMG Action frames are not encapsulated using mechanisms defined for robust Management frames. An Action field, in the octet field immediately after the Category field, differentiates the formats. The Action field values associated with each frame format are defined in Table 9-415. Table 9-415â€”Unprotected DMG Action field values Unprotected DMG Action Meaning field value 0 Announce 1 BRP 9.6.22.2 Announce frame format The Announce frame is an Action or an Action No Ack frame of category Unprotected DMG. The format of an Announce frame Action field is shown in Table 9-416. Announce frames can be transmitted during the ATI of a beacon interval and can perform functions including of a DMG Beacon frame, but since this frame does not have to be transmitted as a sector sweep to a STA, it can provide much more spectrally efficient access than using a DMG Beacon frame. Table 9-416â€”Announce frame Action field format Order Information Notes 1 Category The Category field is defined in 9.4.1.11. 2 Unprotected DMG Action The Unprotected DMG Action field is defined in 9.6.22.1. 3 Timestamp The Timestamp field is defined in 9.4.1.10. 4 Beacon Interval The Beacon Interval field is defined in 9.4.1.3 and specifies the duration of the beacon interval of the BSS. 5 SSID The SSID element is defined in 8.4.2.2. The SSID element is optionally present. If present, the SSID element specifies the SSID of the BSS. 6 Extended Schedule The Extended Schedule element is defined in 9.4.2.132. The Extended Schedule element is optionally present. If present, the Extended Schedule element specifies the schedule of the BSS. 7 DMG Capabilities The DMG Capabilities element is defined in 9.4.2.128. The DMG Capabilities element is optionally present. If present, the DMG Capabilities element specifies capabilities of the transmitting STA. 8 RSN The RSNE is defined in 9.4.2.25. The RSNE is optionally present. If present, the RSNE indicates that security is required in the BSS. 1283 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-416â€”Announce frame Action field format (continued) Order Information Notes 9 Multiple BSSID The Multiple BSSID element is defined in 9.4.2.46. The Multiple BSSID element is optionally present. If present, the Multiple BSSID element signals all the BSSIDs in use by the BSS. 10 DMG Operation The DMG Operation element is defined in 9.4.2.129. The DMG Operation element is optionally present. If present, the DMG Operation element specifies the operational parameters of the BSS. 11 Next DMG ATI The Next DMG ATI element is defined in 9.4.2.135. The Next DMG ATI element is optionally present. If present, the Next DMG ATI element specifies the start time of the next ATI at a subsequent beacon interval. 12 Multi-band The Multi-band element is defined in 9.4.2.138. The Multi-band element is optionally present. 13 Awake Window The Awake Window element is defined in 9.4.2.137. The Awake Window element is optionally present. 14 DMG BSS Parameter Change The DMG BSS Parameter Change element is defined in 9.4.2.127. The DMG BSS Parameter Change element is optionally present. 15 BeamLink Maintenance The BeamLink Maintenance element is defined in 9.4.2.152. The BeamLink Maintenance element is optionally present. 16 Multiple MAC Sublayers The Multiple MAC Sublayers element is defined in 9.4.2.153. The Multiple MAC Sublayers element is optionally present. 17 ECAPC Policy The ECAPC Policy element is defined in 9.4.2.155. The ECAPC Policy element is optionally present. 18 Cluster Report The Cluster Report element is defined in 9.4.2.147. The Cluster Report element is optionally present. 19 Next PCP List The Next PCP List element is defined in 9.4.2.140. The Next PCP List element is optionally present. 20 PCP Handover The PCP Handover element is defined in 9.4.2.141. The PCP Handover element is optionally present. 21 STA Availability The STA Availability element is defined in 9.4.2.133. The STA Availability element is optionally present. 22 UPSIM The UPSIM element is defined in 9.4.2.167. The UPSIM element is optionally present. 9.6.22.3 BRP frame format The BRP frame is an Action No Ack frame. The format of a BRP frame Action field is shown in Table 9-417. Table 9-417â€”BRP frame Action field format Order Information 1 Category 2 Unprotected DMG Action 1284 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-417â€”BRP frame Action field format (continued) Order Information 3 Dialog Token 4 BRP Request field 5 DMG Beam Refinement element 6 Zero or more Channel Measurement Feedback elements The Category field is defined in 9.4.1.11. The Unprotected DMG Action field is defined in 9.6.22.1. The Dialog Token field is set to a value chosen by the STA sending the frame to uniquely identify the transaction. The BRP Request field is defined in 9.5.4. The DMG Beam Refinement element is defined in 9.4.2.130. The Channel Measurement Feedback element is defined in 9.4.2.136. The BRP frame contains more than one Channel Measurement Feedback element if the measurement information exceeds 255 octets. The content of each Channel Measurement Feedback element that follows the first one in a single BRP frame is a continuation of the content in the previous element. The Channel Measurement, Tap Delay, and Sector ID Order subfields can be split between several elements. Each Channel Measurement Feedback element that is not the last Channel Measurement Feedback element in the frame is 257 octets long. Channel measurement information for a single channel measurement is always contained within a single BRP frame. NOTEâ€”The length of a BRP frame can limit the choice of channel measurement parameters such as the number of measurements and the number of taps. 9.6.23 VHT Action frame details 9.6.23.1 VHT Action field Several Action frame formats are defined to support VHT functionality. A VHT Action field, in the octet immediately after the Category field, differentiates the VHT Action frame formats. The VHT Action field values associated with each frame format within the VHT category are defined in Table 9-418. Table 9-418â€”VHT Action field values Value Meaning Time priority 0 VHT Compressed Beamforming Yes 1 Group ID Management No 2 Operating Mode Notification No 3â€“255 Reserved 1285 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.6.23.2 VHT Compressed Beamforming frame format The VHT Compressed Beamforming frame is an Action No Ack frame of category VHT. The Action field of a VHT Compressed Beamforming frame contains the information shown in Table 9-419. Table 9-419â€”VHT Compressed Beamforming frame Action field format Order Information 1 Category 2 VHT Action 3 VHT MIMO Control (see 9.4.1.48) 4 VHT Compressed Beamforming Report (see 9.4.1.49) 5 MU Exclusive Beamforming Report (see 9.4.1.51) The Category field is defined in 9.4.1.11. The VHT Action field is defined in 9.6.23.1. The VHT MIMO Control field is always present in the frame. The presence and contents of the VHT Compressed Beamforming Report field and the MU Exclusive Beamforming Report field are dependent on the values of the Feedback Type, Remaining Feedback Segments, and First Feedback Segment subfields of the VHT MIMO Control field (see 9.4.1.48, 9.4.1.49, 9.4.1.51, and 10.34.5). No vendor-specific elements are present in a VHT Compressed Beamforming frame. 9.6.23.3 Group ID Management frame format The Group ID Management frame is an Action frame of category VHT. It is transmitted by the AP to assign or change the user position of a STA for one or more group IDs. The Action field of a Group ID Management frame contains the information shown in Table 9-420. Table 9-420â€”Group ID Management frame Action field format Order Information 1 Category 2 VHT Action 3 Membership Status Array (see 9.4.1.54) 4 User Position Array (see 9.4.1.55) The Category field is defined in 9.4.1.11. The VHT Action field is defined in 9.6.23.1. 1286 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 9.6.23.4 Operating Mode Notification frame format The Operating Mode Notification frame is an Action frame of category VHT. It is used to notify STAs that the transmitting STA is changing one or more of its operating channel width, the maximum number of spatial streams it can receive, and its LDPC receive preference. The Action field of the Operating Mode Notification frame contains the information shown in Table 9-421. Table 9-421â€”Operating Mode Notification frame Action field format Order Information 1 Category 2 VHT Action 3 Operating Mode (see 9.4.1.53) The Category field is defined in 9.4.1.11. The VHT Action field is defined in 9.6.23.1. 9.7 Aggregate MPDU (A-MPDU) 9.7.1 A-MPDU format An A-MPDU consists of a sequence of one or more A-MPDU subframes and a variable amount of EOF padding as shown in Figure 9-741. A-MPDU pre-EOF padding EOF A-MPDU subframe 1 A-MPDU subframe 2 â€¦ A-MPDU subframe n Padding Octets: variable variable variable variable Figure 9-741â€”A-MPDU format The structure of the A-MPDU subframe is shown in Figure 9-743. Each A-MPDU subframe consists of an MPDU delimiter optionally followed by an MPDU. Each nonfinal A-MPDU subframe in an A-MPDU has padding octets appended to make the subframe a multiple of 4 octets in length. The content of these octets is unspecified. In an HT PPDU, the final A-MPDU subframe is not padded. The EOF Padding field is shown in Figure 9-742. This is present only in a VHT PPDU. EOF Padding EOF Padding Octets Subframes Octets: 4n 0â€“3 Figure 9-742â€”EOF Padding field format 1287 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The EOF Padding Subframes subfield contains zero or more EOF padding subframes. An EOF padding subframe is an A-MPDU subframe with 0 in the MPDU Length field and 1 in the EOF field. In a VHT PPDU, the following padding is present, as determined by the rules in 10.13.6: â€” 0â€“3 octets in the Padding subfield of the final A-MPDU subframe (see Figure 9-743) before any EOF padding subframes. The content of these octets is unspecified. â€” Zero or more EOF padding subframes in the EOF Padding Subframes subfield. â€” 0â€“3 octets in the EOF Padding Octets subfield. The content of these octets is unspecified. An A-MPDU pre-EOF padding refers to the contents of the A-MPDU up to, but not including, the EOF Padding field. NOTEâ€”A-MPDU pre-EOF padding includes any A-MPDU subframes with 0 in the MPDU Length field and 0 in the EOF field inserted in order to meet the minimum MPDU start spacing requirement. The maximum length of an A-MPDU in an HT PPDU is 65 535 octets. The maximum length of an A- MPDU in a DMG PPDU is 262 143 octets. The maximum length of an A-MPDU pre-EOF padding in a VHT PPDU is 1 048 575 octets. The length of an A-MPDU addressed to a particular STA can be further constrained as described in 10.13.2. MPDU delimiter MPDU Padding Octets: 4 variable 0â€“3 Figure 9-743â€”A-MPDU subframe format The MPDU delimiter is 4 octets in length. The structure of the MPDU delimiter when transmitted by a non- DMG STA is defined in Figure 9-744. The structure of the MPDU Delimiter field when transmitted by a DMG STA is shown in Figure 9-745. B0 B1 B2 B15 B16 B23 B24 B31 EOF Reserved MPDU Length CRC Delimiter Signature Bits: 1 1 14 8 8 Figure 9-744â€”MPDU delimiter (non-DMG) B0 B2 B3 B15 B16 B23 B24 B31 Reserved MPDU Length CRC Delimiter Signature Bits: 3 13 8 8 Figure 9-745â€”MPDU delimiter (DMG) The fields of the MPDU delimiter when transmitted by a non-DMG STA are defined in Table 9-422. The fields of the MPDU delimiter when transmitted by a DMG STA are defined in Table 9-423. 1288 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-422â€” MPDU delimiter fields (non-DMG) Size Field Description (bits) EOF 1 End of frame indication. Set to 1 in an A-MPDU subframe that has 0 in the MPDU Length field and that is used to pad the A-MPDU in a VHT PPDU as described in 10.13.6. Set to 1 in the MPDU delimiter of a VHT single MPDU as described in 10.13.7. Set to 0 otherwise. Reserved 1 MPDU Length 14 Length of the MPDU in octets. Set to 0 if no MPDU is present. An A-MPDU subframe with 0 in the MPDU Length field is used as defined in 10.13.3 to meet the minimum MPDU start spacing requirement and also to pad the A-MPDU to fill the available octets in a VHT PPDU as defined in 10.13.6. CRC 8 8-bit CRC of the preceding 16 bits. Delimiter Signature 8 Pattern that can be used to detect an MPDU delimiter when scanning for an MPDU delimiter. The unique pattern is 0x4E (see NOTE below). NOTEâ€”The ASCII value of the character â€˜Nâ€™ was chosen as the unique pattern for the value in the Delimiter Signature field. Table 9-423â€”MPDU delimiter fields (DMG) MPDU Delimiter Size Description field (bits) Reserved 3 MPDU Length 13 Length of MPDU in octets CRC 8 8-bit CRC on preceding 16 bits Delimiter Signature 8 Pattern that can be used to detect an MPDU delimiter when scanning for a delimiter. The unique pattern is 0x4E. The format of the MPDU Length field when transmitted by a non-DMG STA is shown in Figure 9-746. The MPDU Length Low subfield contains the 12 low order bits of the MPDU length. In a VHT PPDU, the MPDU Length High subfield contains the two high order bits of the MPDU length. In an HT PPDU, the MPDU Length High subfield is reserved. B0 B1 B2 B13 MPDU Length High MPDU Length Low Bits: 2 12 Figure 9-746â€”MPDU Length field (non-DMG) The MPDU length value is derived from the MPDU Length field subfields as follows: 1289 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications L low + L high 4096 VHT PPDU L MPDU = L low HT PPDU (9-5) L DMG PPDU where Llow is the value of the MPDU Length Low subfield Lhigh is the value of the MPDU Length High subfield L is the value of the MPDU Length field NOTEâ€”The format of the MPDU Length field maintains a common encoding structure for both VHT and HT PPDUs. For HT PPDUs, only the MPDU Length Low subfield is used, while for VHT PPDUs, both subfields are used. The purpose of the MPDU delimiter is to locate the MPDUs within the A-MPDU so that the structure of the A-MPDU can usually be recovered when one or more MPDU delimiters are received with errors. See O.2 for a description of a deaggregation algorithm. 9.7.2 MPDU delimiter CRC field The MPDU delimiter CRC field is an 8-bit CRC value. It is used as a frame check sequence (FCS) to protect the Reserved and MPDU Length fields. The CRC field is the 1s complement of the remainder generated by 8 2 1 the modulo 2 division of the protected bits by the polynomial x x x 1 , where the shift-register state is preset to all 1s. NOTEâ€”The order of transmission of bits within the CRC field is defined in 9.2.2. Figure 9-747 illustrates the CRC calculation for the MPDU delimiter. (MPDU delimiter) B15â€¦..B0 The feedback term is set to 0 during the shifting out of the result. 0 Serial c c c c c c c c Input 7 6 5 4 3 2 1 0 C7=B16 Serial B16...B23 Output (MPDU delimiter) Figure 9-747â€”MPDU delimiter CRC calculation 9.7.3 A-MPDU contents In a non-DMG PPDU, an A-MPDU is a sequence of A-MPDU subframes carried in a single PPDU with one of the following combinations of RXVECTOR or TXVECTOR parameter values: â€” The FORMAT parameter set to VHT â€” The FORMAT parameter set to HT_MF or HT_GF and the AGGREGATION parameter set to 1 In a DMG PPDU, an A-MPDU is a sequence of MPDUs carried in a single PPDU with the TXVECTOR/ RXVECTOR AGGREGATION parameter set to 1. 1290 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications All of the MPDUs within an A-MPDU are addressed to the same RA. All QoS Data frames within an A-MPDU that have a TID for which an HT-immediate block ack agreement exists have the same value for the Ack Policy subfield of the QoS Control field. All protected MPDUs within an A-MPDU have the same Key ID. The Duration/ID fields in the MAC headers of all MPDUs in an A-MPDU carry the same value. The Duration/ID fields in the MAC headers of MPDUs in A-MPDUs carried in the same VHT MU PPDU all carry the same value. NOTEâ€”The reference point for the Duration/ID field is the end of the PPDU carrying the MPDU. Setting the Duration/ ID field to the same value in the case of A-MPDU aggregation means that each MPDU consistently specifies the same NAV setting. An A-MPDU is transmitted in one of the contexts specified in Table 9-424 as defined by the description in the â€œDefinition of contextâ€ column, independently of whether the A-MPDU is contained in a VHT MU PPDU or an SU PPDU. Ordering of MPDUs within an A-MPDU is not constrained, except where noted in these tables. See 10.13.1. Table 9-424â€”A-MPDU contexts Table defining Name of Context Definition of Context permitted contents Data Enabled The A-MPDU is transmitted outside a PSMP sequence by a Table 9-425 Immediate TXOP holder or an RD responder including potential Response immediate responses. Data Enabled No The A-MPDU is transmitted outside a PSMP sequence by a Table 9-426 Immediate TXOP holder that does not include or solicit an immediate Response response. See NOTE. PSMP The A-MPDU is transmitted within a PSMP sequence. Table 9-427 Control Response The A-MPDU is transmitted by a STA that is neither a TXOP Table 9-428 holder nor an RD responder that also needs to transmit one of the following immediate response frames: Ack BlockAck frame with a TID for which an HT-immediate block ack agreement exists VHT single MPDU The A-MPDU is transmitted within a VHT PPDU and Table 9-429 context contains a VHT single MPDU. NOTEâ€”This context includes cases when no response is generated or when a response is generated later by the operation of the delayed block ack rules. A VHT MU PPDU does not carry more than one A-MPDU that contains one or more MPDUs soliciting an immediate response. NOTE 1â€”The TIDs present in a data enabled A-MPDU context are also constrained by the channel access rules (for a TXOP holder; see 10.22.2 and 10.22.3) and the RD response rules (for an RD responder, see 10.28.4). This is not shown in these tables. NOTE 2â€”If a STA supports A-MSDUs of 7935 octets (indicated by the Maximum A-MSDU Length field in the HT Capabilities element), A-MSDUs transmitted by that TA within an A-MPDU carried in a PPDU with FORMAT HT_MF or HT_GF or within an MPDU carried in a non-HT PPDU are constrained so that the length of the QoS Data frame carrying the A-MSDU is no more than 4095 octets. The 4095-octet MPDU length limit does not apply to A-MPDUs carried in VHT or DMG PPDUs. The use of A-MSDU within A-MPDU might be further constrained as described in 9.4.1.14 through the operation of the A-MSDU Supported field. 1291 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-425â€”A-MPDU contents in the data enabled immediate response context MPDU Description Conditions Ack If the preceding PPDU contains an MPDU that requires an Ack frame response, a single Ack frame at the start of the A-MPDU. In a non-DMG STA: at most one of these HT-immediate BlockAck In a non-DMG STA: if the preceding PPDU contains an MPDUs is present. implicit or explicit block ack request for a TID for which an HT-immediate block ack agreement exists, at In a DMG STA: at most most one BlockAck frame for this TID, in which case it one Ack frame is occurs at the start of the A-MPDU. present, and zero or more HT-immediate In a DMG STA: if the preceding PPDU contains an BlockAck frames are implicit or explicit block ack request for a TID for present. which an HT-immediate block ack agreement exists, one or more copies of the same BlockAck for this TID. Delayed BlockAcks BlockAck frames with the BA Ack Policy subfield equal to No Acknowledgment with a TID for which an HT-delayed block ack agreement exists. Delayed block ack data QoS Data frames with a TID that corresponds to a Delayed or HT-delayed block ack agreement. These have the Ack Policy field equal to Block Ack. Action No Ack Action No Ack frames. Delayed BlockAckReqs BlockAckReq frames with a TID that corresponds to an HT-delayed block ack agreement in which the BA Ack Policy subfield is equal to No Acknowledgment. Data frames sent under an HT- QoS Data frames with the same TID, Of these, at most one of the following immediate block ack which corresponds to an HT-immediate is present in a non-DMG BSS: agreement block ack agreement. â€” One or more QoS Data frames See NOTE. with the Ack Policy field equal to QoS Null MPDUs with Ack In a DMG BSS, QoS Null MPDUs with Implicit Block Ack Request Policy set to No Ack Ack Policy set to No Ack. â€” A BlockAckReq frame Immediate BlockAckReq At most one BlockAckReq frame with a Of these, at most one of the following TID that corresponds to an HT- is present in a DMG BSS: immediate block ack agreement. This is the last MPDU in the A-MPDU. â€” One or more QoS Data frames with the Ack Policy field equal to It is not present if any QoS Data frames Implicit Block Ack Request for that TID are present. â€” QoS Null MPDU with Ack Policy set to No Ack â€” A BlockAckReq frame with an optional QoS Null MPDU with Ack Policy set to No Ack NOTEâ€”These MPDUs all have the Ack Policy field equal to the same value, which is either Implicit Block Ack Request or Block Ack. 1292 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-426â€”A-MPDU contents in the data enabled no immediate response context MPDU Description Conditions Delayed BlockAcks BlockAck frames for a TID for which an HT-delayed block ack agreement exists with the BA Ack Policy subfield equal to No Acknowledgment. Delayed Block Ack data QoS Data frames with a TID that corresponds to a Delayed or HT-delayed block ack agreement. These have the Ack Policy field equal to Block Ack. Data without a block ack QoS Data frames with a TID that does not correspond to a block ack agreement. agreement These have the Ack Policy field equal to No Ack and the A-MSDU Present subfield equal to 0. Action No Ack Action No Ack frames. Delayed BlockAckReqs BlockAckReq frames with the BA Ack Policy subfield equal to No Acknowledgment and with a TID that corresponds to an HT-delayed block ack agreement. Table 9-427â€”A-MPDU contents in the PSMP context MPDU Description Conditions Acknowledgment for PSMP data At most one Multi-TID BlockAck frame. Acknowledgment in response to data received with the Ack Policy field equal to PSMP Ack and/or a Multi-TID BlockAckReq frame in the previous PSMP-UTT or PSMP-DTT. Delayed BlockAcks BlockAck frames with the BA Ack Policy subfield equal to No Acknowledgment and with a TID for which an HT-delayed block ack agreement exists. HT-immediate Data QoS Data frames in which the Ack Policy field is equal to PSMP Ack or Block Ack and with a TID that corresponds to an HT-immediate block ack agreement. Delayed Block Ack data QoS Data frames with a TID that An A-MPDU containing corresponds to a Delayed or HT-delayed MPDUs with a block ack block ack agreement. agreement does not also These have the Ack Policy field equal to contain MPDUs without a Block Ack. block ack agreement. Data without a block ack agreement QoS Data frames with a TID that does not correspond to a block ack agreement. These have the Ack Policy field equal to No Ack and the A-MSDU Present subfield is equal to 0. Action No Ack Action No Ack frames. Delayed BlockAckReqs BlockAckReq frames with the BA Ack Policy subfield equal to No Acknowledgment and with a TID that corresponds to an HT-delayed Block Ack. Multi-TID BlockAckReq At most one Multi-TID BlockAckReq frame with the BA Ack Policy subfield equal to No Acknowledgment. 1293 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 9-428â€”A-MPDU contents MPDUs in the control response context MPDU Conditions Ack Ack frame transmitted in response to an MPDU that requires an Ack frame. One of these is present at the start of BlockAck BlockAck frame with a TID that corresponds the A-MPDU. to an HT-immediate block ack agreement. Action No +HTC Action No Ack frames carrying a Management Action Body containing an Ack explicit feedback response or BRP frame. Table 9-429â€”A-MPDU contents in the VHT single MPDU context MPDU Conditions Any MPDU A VHT single MPDU. 1294 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10. MAC sublayer functional description 10.1 Introduction The MAC functional description is presented in this clause. The architecture of the MAC sublayer, including the distributed coordination function (DCF), the point coordination function (PCF), the hybrid coordination function (HCF), the mesh coordination function (MCF), and their coexistence in an IEEE 802.11 LAN are introduced in 10.2. These functions are expanded on in 10.3, 10.4, 10.22, and 10.23. Fragmentation and defragmentation are defined in 10.5 and 10.6. Multirate support is addressed in 10.7. A number of additional restrictions to limit the cases in which MSDUs are reordered or discarded are described in 10.8. Operation across regulatory domains is defined in 10.21. The block ack mechanism is described in 10.24. The No Ack mechanism is described in 10.25. The protection mechanism is described in 10.26. Rules for processing MAC frames are described in 10.27. The PCF mechanism is obsolete. Consequently, the PCF mechanism might be removed in a later revision of the standard. 10.2 MAC architecture 10.2.1 General The MAC architecture is shown in Figure 10-1 and Figure 10-2. Required for Required for Prioritized Parameterized QoS Services QoS Services Required for Contention- Required for Free Services for non-QoS Controlled Mesh Mesh Coordination Function (MCF) STA, optional otherwise Services Hybrid Coordination Function (HCF) Used for Contention Services, basis for PCF, HCF and MCF Point HCF HCF MCF Coordina- Conten- Controlled Controlled tion tion MAC Access Access Function Access extent (HCCA) (MCCA) (PCF) (EDCA) Distributed Coordination Function (DCF) DSSS, OFDM, HR/DSSS, ERP, HT, VHT or TVHT PHY Figure 10-1â€”Non-DMG STA MAC architecture 1295 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Used for Used for Dynamic Contention Allocation Services Services Used for non- Used for data services Scheduled Services Used for beamforming with an AP or PCP Dynamic Allocation CBAP Access (HCF A-BFT ATI SP Contention Access Access Access) Access DCF DMG Channel Access DMG PHY Figure 10-2â€”DMG STA MAC architecture In a non-DMG STA: â€” The MAC provides the PCF, HCF and MCF service using the services of the DCF. â€” The PCF is optionally present in nonmesh STAs and absent otherwise. â€” The HCF is present in QoS STAs and absent otherwise. â€” The MCF is present in mesh STAs and absent otherwise. In a DMG STA: â€” The MAC provides services using the DMG channel access mechanisms. â€” Specific rules apply for access during scheduled periods, which include the association beamforming training (A-BFT) period, announcement transmission interval (ATI), contention based access period (CBAP), and service period (SP). â€” The DCF is used during contention based access periods. â€” Dynamic allocation (10.36.7) is built on service period and contention based access period. 10.2.2 DCF The fundamental access method of the MAC used by non-DMG STAs is a DCF known as carrier sense multiple access with collision avoidance (CSMA/CA). The DCF shall be implemented in all STAs. For a STA to transmit, it shall sense the medium to determine if another STA is transmitting. If the medium is not determined to be busy (see 10.3.2.1), the transmission may proceed. The CSMA/CA distributed algorithm mandates that a gap of a minimum specified duration exists between frame exchange sequences. A transmitting STA shall verify that the medium is idle for this required duration before attempting to transmit. If the medium is determined to be busy, a non-DMG STA shall defer until the end of the current transmission, and a DMG STA may defer until the end of the current transmission. After deferral, or prior to attempting to transmit again immediately after a successful transmission, the STA shall select a random backoff interval and shall decrement the backoff interval counter while the medium is idle. A refinement of the method may be used under various circumstances to further minimize collisionsâ€”here the transmitting and receiving STA exchange short Control frames (RTS and CTS frames for non-DMG STAs, and RTS and DMG CTS frames for DMG STAs) after determining that the medium is idle and after any deferrals or backoffs, prior to data transmission. The details of CSMA/CA, deferrals, and backoffs are described in 10.3. RTS/CTS and RTS/ DMG CTS exchanges are also presented in 10.3. 1296 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.2.3 PCF The PCF mechanism is obsolete. Consequently, this subclause might be removed in a later revision of the standard. The IEEE 802.11 MAC may also incorporate an optional access method called a PCF, which is usable only in infrastructure network configurations. This access method uses a PC, which shall operate at the AP of the BSS, to determine which STA currently has the right to transmit. The operation is essentially that of polling, with the PC performing the role of the polling master. The operation of the PCF might require additional coordination, not specified in this standard, to permit efficient operation when multiple point-coordinated BSSs are operating on the same channel, in overlapping physical space. The PCF uses a virtual carrier sense (CS) mechanism aided by an access priority mechanism. The PCF shall distribute information within Beacon frames to gain control of the medium by setting the NAV in STAs. In addition, all frame transmissions under the PCF may use an interframe space (IFS) that is smaller than the IFS for frames transmitted via the DCF. The use of a smaller IFS implies that point-coordinated traffic has priority access to the medium over STAs in overlapping BSSs operating under the DCF access method. The access priority provided by a PCF may be utilized to create a CF access method. The PC controls the frame transmissions of the STAs so as to eliminate contention for a limited period of time. 10.2.4 Hybrid coordination function (HCF) 10.2.4.1 General The QoS facility includes an additional coordination function called HCF that is usable only in QoS network configurations. The HCF shall be implemented in all QoS STAs except mesh STAs. Instead, mesh STAs implement the MCF. The HCF combines functions from the DCF and PCF with some enhanced, QoS-specific mechanisms and frame subtypes to allow a uniform set of frame exchange sequences to be used for QoS data transfers during both the CP and CFP. The HCF uses both a contention based channel access method, called the enhanced distributed channel access (EDCA) mechanism for contention based transfer and a controlled channel access, referred to as the HCF controlled channel access (HCCA) mechanism, for contention free transfer. A STA may obtain a TXOP using one or both of the channel access mechanisms specified in 10.22. If a TXOP is obtained using the contention based channel access, it is defined as EDCA TXOP. If a TXOP is obtained using the controlled channel access, it is defined as HCCA TXOP. If an HCCA TXOP is obtained due to a QoS (+)CF-Poll frame from the HC, the TXOP is defined as a polled TXOP. Time priority Management frames are transmitted outside of the normal MAC queuing process as per individually described transmission rules. Frames listed in Table 9-333 and Table 9-418 with a value of â€œYesâ€ in the â€œTime priorityâ€ column are time priority Management frames. No other frames are time priority Management frames. 10.2.4.2 HCF contention based channel access (EDCA) The EDCA mechanism provides differentiated, distributed access to the WM for STAs using eight different UPs. The EDCA mechanism defines four access categories (ACs) that provide support for the delivery of traffic with UPs at the STAs. Six transmit queues are defined when dot11AlternateEDCAActivated is true, and four transmit queues otherwise. The transmit queue and AC are derived from the UPs as shown in Table 10-1. NOTEâ€”A DMG STA that implements a single AC (see 10.22.2.1) has all of its UP values in Table 10-1 mapped to AC_BE. 1297 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 10-1â€”UP-to-AC mappings UP Transmit queue IEEE Transmit queue (Same as IEEE (dot11Alternate- Designation (dot11Alternate Priority 802.1D AC EDCAActivated EDCAActivated 802.1D user false or (informative) designation true) priority) not present) Lowest 1 BK AC_BK BK BK Background 2 â€” AC_BK BK BK Background 0 BE AC_BE BE BE Best Effort 3 EE AC_BE BE BE Best Effort 4 CL AC_VI VI A_VI Video (alternate) 5 VI AC_VI VI VI Video (primary) 6 VO AC_VO VO VO Voice (primary) Highest 7 NC AC_VO VO A_VO Voice (alternate) For each AC an enhanced variant of the DCF, called an enhanced distributed channel access function (EDCAF), contends for TXOPs using a set of EDCA parameters. When communicating Data frames outside the context of a BSS (dot11OCBActivated is true), the EDCA parameters are the corresponding default values or are as set by the SME in dot11EDCATable (except for TXOP limits, which shall be set to 0 for each AC). When communicating within a BSS, the EDCA parameters used are from the EDCA Parameter Set element or from the default values for the parameters when no EDCA Parameter Set element is received from the AP of the BSS with which the STA is associated or when the STA is a mesh STA. The parameters used by the EDCAF to control its operation are defined by dot11QAPEDCATable at the AP and by dot11EDCATable at the non-AP STA. The following rules apply for HCF contention based channel access: a) The minimum specified idle duration time is not the constant value (DIFS) defined for DCF, but is a distinct value. This value is specified in table dot11QAPEDCATableAIFSN for an AP and in table dot11EDCATableAIFSN for a non-AP STA; see 10.22.2. The minimum idle duration time is assigned either by a management entity or by an AP. b) The contention window limits aCWmin and aCWmax, from which the random backoff is computed, are not fixed per PHY, as with DCF, but are variable (contained in tables dot11QAPEDCATableCWmin and dot11QAPEDCATableCWmax for an AP and in tables dot11EDCATableCWmin and dot11EDCATableCWmax for a non-AP STA) and assigned by a management entity or by an AP. c) Collisions between contending EDCAFs in a STA are resolved within the STA, so that the Data frames from the higher priority AC receive the TXOP and the Data frames from the lower priority colliding AC(s) behave as if there were an external collision on the WM except that the Retry subfield in the MAC headers of MPDUs at the head of the lower priority ACs is not affected. d) During an EDCA TXOP won by an EDCAF a STA may initiate multiple frame exchange sequences to transmit MMPDUs and/or MSDUs within the same AC. The duration of this EDCA TXOP is bounded, for an AC, by the value dot11QAPEDCATableTXOPLimit for an AP and by dot11EDCATableTXOPLimit for a non-AP STA. A value of 0 for this duration means that the EDCA TXOP is limited as defined by the rule for TXOP limit of 0 found in 10.22.2.8. The QoS AP shall announce the EDCA parameters in selected Beacon frames and in all Probe Response and (Re)Association Response frames by the inclusion of the EDCA Parameter Set element using the information 1298 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications from the MIB entries in dot11ECDATable. If no such element is received, a STA shall use the default values for the parameters. The fields following the QoS Info field in the EDCA Parameter Set element shall be included in all Beacon frames occurring within two (optionally more) delivery traffic indication map (DTIM) periods following a change in AC parameters, which provides all STAs an opportunity to receive the updated EDCA parameters. If any associated STAs are in WNM sleep mode or using FMS, these fields should be included by the AP for as many DTIM periods as needed to exceed the longest interval any STA is expected to not receive Beacon frames. A QoS STA shall update its MIB attributes that correspond to fields in an EDCA Parameter Set element within an interval of time equal to one beacon interval after receiving an updated EDCA parameter set. QoS STAs update the MIB attributes and store the EDCA Parameter Set update count value in the QoS Info field. An AP may change the EDCA access parameters by changing the EDCA Parameter Set element in the Beacon frame, Probe Response frame, and (Re)Association Response frame. However, the AP should change them only rarely. A QoS STA shall use the EDCA Parameter Set Update Count Value subfield in the QoS Capability element of all Beacon frames to determine whether the STA is using the current EDCA Parameter Values. If the EDCA Parameter Set update count value in the QoS Capability element is different from the value that has been stored, the QoS STA shall query the updated EDCA parameter values by sending a Probe Request frame to the AP. In the Beacon frame the EDCA Parameter Set Update Count subfield is initially set by the AP to 0 and is incremented every time any of the AC parameters changes. An AP or PCP may use a different set of EDCA parameter values than it advertises to the STAs in its BSS. A QoS STA that transmits a Management frame determines access category used for medium access in transmission of the Management frame as follows: â€” If dot11QMFActivated is false or not present â€” If the Management frame is individually addressed to a non-QoS STA, category AC_BE should be selected NOTEâ€”Category AC_BE might not be selected when no prior Data frames have been transmitted to the non-QoS STA â€” If category AC_BE was not selected by the previous step, category AC_VO shall be selected NOTEâ€”Selection of AC_VO above is independent of whether the STA is associated with a BSS, or whether there is a QoS facility in the BSS. â€” If dot11QMFActivated is true the STA determines the access category as described in 11.26. BlockAckReq and BlockAck frames shall be sent using the same access category for medium access as the corresponding QoS Data frames. PS-Poll frames shall be sent using the access category AC_BE for medium access (to reduce the likelihood of collision following a Beacon frame). When the first frame in a frame exchange sequence intended to carry a QoS Data, QoS Null or Management frame is an RTS or CTS frame, the RTS or CTS frame shall be transmitted using the access category of the corresponding QoS Data or QoS Null frame or the access category used for medium access of the Management frame. Control Wrapper frames shall be sent using the access category that would apply to the carried Control frame. A beamformer may send a VHT NDP Announcement frame or Beamforming Report Poll frame using any access category and without being restricted by admission control procedures. PS-Poll frames and Management frames are exempted from any and all restrictions on transmissions arising from admission control procedures. 1299 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The operation rules of HCF contention based channel access are defined in 10.22.2. The alternate video (A_VI) and alternate voice (A_VO) transmit queues share the same EDCAF as VI and VO transmit queues, respectively, as shown in Figure 10-25. When dot11AlternateEDCAActivated is true, a scheduling function above the VO EDCAF selects from the primary or alternate transmit queue an MSDU, an A-MSDU, an MMPDU, or set of MSDUs to be the next to be passed to the VO EDCAF (as shown in Figure 10-25) so that the MSDU(s), A-MSDU(s), or MMPDU(s) from the queue with the higher UP are selected with a higher probability than from the queue with the lower UP. When dot11AlternateEDCAActivated is true, a scheduling function above the VI EDCAF selects from the primary or alternate transmit queue an MSDU, an A-MSDU, an MMPDU, or set of MSDUs to be the next to be passed to the VI EDCAF so that the MSDU(s), A-MSDU(s), or MMPDU(s) from the queue with the higher UP are selected with a higher probability than from the queue with the lower UP. The default algorithm to select an MSDU, A-MSDU, or MMPDU from either the A_VI or VI queue and to select an MSDU, A-MSDU, or MMPDU from either the A_VO or VO queue is as follows: a) For each EDCAF, an MSDU, A-MSDU, or MMPDU is selected for transmission using the transmission selection procedures defined in 8.6.8 of IEEE Std 802.1Q-2011 using two queues, the primary and alternate. b) For a given AC, the order in which frames are selected for transmission shall maintain the requirements specified in 10.8 of this standard. Alternative prioritization algorithms that meet the requirements of 10.8 may be used. All MSDUs, A-MSDUs, and MMPDUs passed to the VO EDCAF are transmitted according to AC_VO EDCAF parameters and rules. All MSDUs, A-MSDUs, and MMPDUs passed to the VI EDCAF are transmitted according to AC_VI EDCAF parameters and rules. 10.2.4.3 HCF controlled channel access (HCCA) The HCCA mechanism uses a QoS-aware centralized coordinator, called a hybrid coordinator (HC), and operates under rules that are different from the PC of the PCF. The HC is collocated with the AP of the BSS and uses the HCâ€™s higher priority of access to the WM to initiate frame exchange sequences and to allocate TXOPs to itself and other STAs in order to provide limited-duration CAPs for contention free transfer of QoS data. The HC traffic delivery and TXOP allocation may be scheduled during the CP and any locally generated CFP (generated optionally by the HC) to meet the QoS requirements of a particular TC or TS. TXOP allocations and contention free transfers of QoS traffic might be based on the HCâ€™s BSS-wide knowledge of the amounts of pending traffic belonging to different TS and/or TCs and are subject to BSS-specific QoS policies. An AP may transmit a CF-Poll to a non-QoS STA, thereby providing non-QoS contention free transfers during the CFP. This provisioning of contention free transfers during the CFP to non-QoS STAs, however, is not recommended. Implementers are cautioned that QoS STAs are not required to interpret data subtypes that include QoS +CF-Ack in frames not addressed to themselves unless they set the Q-Ack subfield in the QoS Capability element to 1. QoS STAs are also not required to interpret data subtypes that are non-QoS (+)CF- Poll frames (i.e., Data frames with bits 7, 5, and 4 in the Frame Control field equal to 0, 1, and 0, respectively); therefore, QoS STAs cannot be treated as CF-Pollable STAs. This requires an AP that provides non-QoS CF- polling to adhere to frame exchange sequence restrictions considerably more complex than, and less efficient than, those specified for either PCF or HCF. In addition, the achievable service quality is likely to be degraded when non-QoS STAs are associated and being polled. The HCF protects the transmissions during each CAP using the virtual CS mechanism. 1300 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A STA may initiate multiple frame exchange sequences during a polled TXOP of sufficient duration to perform more than one such sequence. The use of virtual CS by the HC provides improved protection of the CFP, in addition to the protection provided by having all STAs in the BSA setting their NAVs to dot11CFPMaxDuration at the target beacon transmission time (TBTT) of DTIM Beacon frames. The operation rules of the HCCA are defined in 10.22.3. 10.2.5 Mesh coordination function (MCF) The mesh facility includes an additional coordination function called MCF that is usable only in an MBSS. A mesh STA shall implement the MCF only. MCF has both a contention based channel access and contention free channel access mechanism. The contention based mechanism is EDCA and the contention free mechanism is called the MCF controlled channel access (MCCA). MCF uses the default values for the PTKSA, GTKSA and STKSA Replay Counters. The operation rules of the EDCA are defined in 10.22.2. The operation rules of the MCCA are defined in 10.23.3. 10.2.6 Combined use of DCF, PCF, and HCF The DCF and a centralized coordination function (either PCF or HCF) are defined so they may operate within the same BSS. When a PC is operating in a BSS, the PCF and DCF access methods alternate, with a CFP followed by a CP. This is described in greater detail in 10.4. When an HC is operating in a BSS, it may generate an alternation of CFP and CP in the same way as a PC, using the DCF access method only during the CP. The HCF access methods (controlled and contention based) operate sequentially when the channel is in CP. Sequential operation allows the polled and contention based access methods to alternate, within intervals as short as the time to transmit a frame exchange sequence, under rules defined in 10.22. 10.2.7 Fragmentation/defragmentation overview The process of partitioning an MSDU or an MMPDU into smaller MAC level frames, MPDUs, is called fragmentation. Fragmentation creates MPDUs smaller than the original MSDU or MMPDU length to increase reliability, by increasing the probability of successful transmission (as defined in 10.2.2) of the MSDU or MMPDU when channel characteristics limit reception reliability for longer frames. A STA may use fragmentation to use the medium efficiently in consideration of the duration available in granted TXOPs, as long as the rules in 10.5 are followed. Fragmentation is accomplished at each immediate transmitter. The process of recombining MPDUs into a single MSDU or MMPDU is defined as defragmentation. Defragmentation is accomplished at each immediate recipient. An MSDU transmitted under HT-immediate or HT-delayed block ack agreement shall not be fragmented even if its length exceeds dot11FragmentationThreshold. An MSDU or MMPDU transmitted within an A-MPDU that does not contain a VHT single MPDU (see 10.13.8) shall not be fragmented even if its length exceeds dot11FragmentationThreshold. MSDUs or MMPDUs carried in a group addressed MPDU shall not be fragmented even if their length exceeds dot11FragmentationThreshold. NOTE 1â€”A fragmented MSDU or MMPDU transmitted by an HT STA to another HT STA can be acknowledged only using immediate acknowledgment (i.e., transmission of an Ack frame after a SIFS). NOTE 2â€”As specified in 10.12, A-MSDUs are never fragmented. Except as described below, when an individually addressed MSDU is received from the LLC or an individually addressed MMPDU is received from the MLME that would result in an MPDU of length greater than dot11FragmentationThreshold, the MSDU or MMPDU shall be fragmented. An exception applies when an MSDU is transmitted using an HT-immediate or HT-delayed block ack agreement or when the MSDU or MMPDU is carried in an A-MPDU that does not contain a VHT single MPDU, in which case the MSDU or MMPDU is transmitted without fragmentation. Each fragment is a frame no longer than dot11FragmentationThreshold, if security encapsulation is not invoked for the MPDU. If security 1301 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications encapsulation is active for the MPDU, then the fragments shall be expanded by the encapsulation overhead and this may result in a fragment larger than dot11FragmentationThreshold. It is possible that any fragment may be a frame smaller than dot11FragmentationThreshold. An illustration of fragmentation is shown in Figure 10-3. Figure 10-3â€”Fragmentation The MPDUs resulting from the fragmentation of an MSDU or MMPDU are sent as independent transmissions, each of which is separately acknowledged. This permits transmission retries to occur per fragment, rather than per MSDU or MMPDU. The fragments of a single MSDU or MMPDU are either â€” Sent during a CP as individual frames using the DCF, or â€” Sent during a CFP as individual frames obeying the rules of the PC medium access procedure, or â€” Sent as a burst in an EDCA or HCCA TXOP, subject to TXOP limits and medium occupancy limits for the attached PHY. A QoS Data frame with a TID matching an existing block ack agreement may be transmitted outside an A-MPDU with its Ack Policy subfield set to Normal Ack. Transmission of fragmented MPDUs by a DMG STA outside of an A-MPDU depends on setting of the No- Fragmentation field in the ADDBA Extension element within the ADDBA Response frame transmitted during the block ack agreement handshake. The MSDU shall not be fragmented if the No-Fragmentation field in the ADDBA Extension element within the ADDBA Response frame transmitted during the block ack agreement handshake is 1. If the No-Fragmentation field in the ADDBA Extension element within the ADDBA Response frame is 0, the originator may send fragmented nonaggregated MSDU with Normal Ack policy under block ack agreement. 10.2.8 MAC data service The MAC data service provides the transport of MSDUs between MAC peer entities as characterized in 5.1.1. The transmission process is started by the MACâ€™s receipt of an MA-UNITDATA.request primitive containing an MSDU and the associated parameters. This might cause one or more Data frames containing the MSDU to be transmitted following A-MSDU aggregation, fragmentation, and security encapsulation, as appropriate. The MAC generates the MA-UNITDATA.indication primitive in response to one or more received Data frames containing an MSDU following validation, address filtering, decryption, decapsulation, defragmentation, and A-MSDU deaggregation, as appropriate. When dot11SSPNInterfaceActivated is true, an AP shall distribute the group addressed message into the BSS only if dot11NonAPStationAuthSourceMulticast in the dot11InterworkingEntry identified by the source MAC address in the received message is true. When dot11SSPNInterfaceActivated is false, the group addressed message shall be distributed into the BSS. Unless the MPDU is delivered via DMS, the STA originating the message receives the message as a group addressed message (prior to any filtering). Therefore, a STA shall filter out group addressed messages that contain their address as the source address. When dot11SSPNInterfaceActivated is false, group addressed MSDUs shall be propagated throughout the ESS. 1302 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications When dot11SSPNInterfaceActivated is true, group addressed MSDUs shall be propagated throughout the ESS only if dot11NonAPStationAuthSourceMulticast in the dot11InterworkingEntry identified by the source MAC address in the received message is true. The MAC performs address filtering on the Address 1 field of each MPDU contained in a PPDU and on the DA of each MSDU within an A-MSDU. When the Address 1 field or DA field contains a group address, address filtering is performed by comparing the value in the Address 1 field or DA field to all values in the dot11GroupAddressesTable, and the STA also validates the BSSID to verify either that the group addressed frame originated from a STA in the BSS of which the receiving STA is a member, or that it contains the wildcard BSSID value, indicating a Data frame sent outside the context of a BSS (dot11OCBActivated is true in the transmitting STA). A mesh STA also uses the address matching rules described in 10.35.3, when it receives an individually addressed frame. When a mesh STA receives a frame with the Address 1 field equal to a group address, the mesh STA also checks the TA to determine whether the group addressed frame originated from one of its peer mesh STAs; if there is no match, the STA shall discard the frame. A mesh STA also uses the address matching rules described in 10.35.4. If the Address 1 field of an MPDU carrying an A-MSDU does not match any address at a receiving STA, then the entire A-MSDU is discarded. In a QoS STA, the TID parameter of the MA-UNITDATA.request primitive results in a TID being specified for the transmitted MSDU. This TID associates the MSDU with the AC or TS queue for the indicated traffic. 10.3 DCF 10.3.1 General The basic medium access protocol is a DCF that allows for automatic medium sharing between compatible PHYs through the use of CSMA/CA and a random backoff time following a busy medium condition. In addition, all individually addressed traffic uses immediate positive acknowledgment (Ack frame), in which retransmission is scheduled by the sender if no Ack frame is received. The CSMA/CA protocol is designed to reduce the collision probability between multiple STAs accessing a medium, at the point where collisions would most likely occur. Just after the medium becomes idle following a busy medium (as indicated by the CS function) is when the highest probability of a collision exists. This is because multiple STAs could have been waiting for the medium to become available again. This is the situation that necessitates a random backoff procedure to resolve medium contention conflicts. The DCF is modified for use by DMG STAs to allow sharing of the medium between compatible DMG PHYs (see 10.3.4). A DMG STA has no direct knowledge of when it might interfere (collide with the transmission of) another STA. The CS function of a DMG STA might not indicate the medium busy condition due to the predominant nature of directional transmissions and receptions. The transmission of a STA might interfere (collide) with the transmission of another STA even though the CS function at the first STA does not indicate medium busy. The interference (collision) is identified when the expected response frame is not received. SPSH is achieved by the proper combination of the STA antenna configuration during the media access and data transfer phases. CS shall be performed both through physical and virtual mechanisms. 1303 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The virtual CS mechanism is achieved by distributing reservation information announcing the impending use of the medium. The exchange of RTS and CTS frames prior to the actual Data frame is one means of distribution of this medium reservation information. The RTS and CTS frames contain a Duration field that defines the period of time that the medium is to be reserved to transmit the actual Data frame and the returning Ack frame. A STA receiving either the RTS frame (sent by the originating STA) or the CTS frame (sent by the destination STA) shall process the medium reservation. Thus, a STA might be unable to receive from the originating STA and yet still know about the impending use of the medium to transmit a Data frame. Another means of distributing the medium reservation information is the Duration/ID field in individually addressed frames. This field gives the time that the medium is reserved, either to the end of the immediately following Ack frame, or in the case of a fragment sequence, to the end of the Ack frame following the next fragment. The RTS/CTS exchange also performs both a type of fast collision inference and a transmission path check. If the return CTS frame is not detected by the STA originating the RTS, the originating STA may repeat the process (after observing the other medium-use rules) more quickly than if the long Data frame had been transmitted and a return Ack frame had not been detected. An RTS/CTS exchange by VHT STAs also performs fast collision inference on the secondary 20 MHz channel, secondary 40 MHz channel, and secondary 80 MHz channel and helps the VHT STA transmitting the RTS to determine the available bandwidth at the responder. Another advantage of the RTS/CTS mechanism occurs where multiple BSSs utilizing the same channel overlap. The medium reservation mechanism works across the BSS boundaries. The RTS/CTS mechanism might also improve operation in a typical situation in which all STAs are able to receive from the AP, but might not be able to receive from all other STAs in the BSA. Except for MPDUs transmitted via the GCR service, the RTS/CTS mechanism cannot be used for MPDUs with a group addressed immediate destination because there are multiple recipients for the RTS frame, and thus potentially multiple concurrent senders of the CTS frame in response. For MPDUs transmitted via the GCR service, an RTS frame may be used if it is directed to a STA within the GCR group (see 10.22.2.11.2 and 10.24.10). The RTS/CTS mechanism is not used for every Data frame transmission. Because the additional RTS and CTS frames add overhead inefficiency, the mechanism is not always justified, especially for short Data frames. The use of the RTS/CTS mechanism is under control of dot11RTSThreshold. This attribute may be set on a per-STA basis. This mechanism allows STAs to be configured to initiate RTS/CTS either always, never, or only on frames longer than a specified length. NOTEâ€”A STA configured not to initiate the RTS/CTS mechanism updates its virtual CS mechanism with the duration information contained in a received RTS or CTS frame, and responds to an RTS frame addressed to it with a CTS frame if permitted by medium access rules. All non-DMG STAs that are members of a BSS are able to receive and transmit at all of the data rates in the BSSBasicRateSet parameter of the MLME-START.request primitive or BSSBasicRateSet parameter of the SelectedBSS parameter of the MLME-JOIN.request primitive; see 6.3.4.2.4 and 6.3.11.2.4. NOTEâ€”A STAâ€™s operational rate set does not necessarily contain all the mandatory rates. However a STA has to be capable of receiving using a mandatory rate (as required by the rules in 10.7) even if it is not present in this set. All HT STAs that are members of a BSS are able to receive and transmit using all of the MCSs in the Basic HT-MCS Set field of the HT Operation parameter of the MLME-START.request primitive or Basic HT-MCS Set field of the HT Operation parameter of the SelectedBSS parameter of the MLME-JOIN.request primitive; see 6.3.4.2.4 and 6.3.11.2.4. All VHT STAs that are members of a BSS are able to receive and transmit using all of the tuples in the basic VHT-MCS and NSS set (see 11.40.7) except as constrained by the rules of 10.7.12. 1304 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications All DMG STAs that are members of a BSS are able to receive and transmit using all of the MCSs in the OperationalRateSet parameter of the MLME-START.request primitive or OperationalRateSet parameter of the SelectedBSS parameter of the MLME-JOIN.request primitive; see 6.3.4.2.4 and 6.3.11.2.4. To support the proper operation of the RTS/CTS by non-DMG STAs, RTS/DMG CTS by DMG STAs, and the virtual CS mechanism, a non-DMG STA shall be able to interpret Control frames with the Subtype subfield equal to RTS or CTS, and a DMG STA shall be able to interpret Control frames with the Subtype subfield equal to RTS or DMG CTS. A Data frame sent under the DCF shall have the Type subfield set to Data and the Subtype subfield set to Data or Null. A STA receiving a frame with the Type subfield equal to Data shall not indicate the frame to the LLC when the Subtype subfield is equal to Null, but shall indicate the frame to the LLC when the Subtype subfield is equal to Data, even if the frame body contains zero octets. While in the awake state and operating under DCF but not transmitting, a DMG STA can configure its receive antenna to a quasi-omni pattern in order to receive frames transmitted by any STA that is covered by this antenna pattern. 10.3.2 Procedures common to the DCF and EDCAF 10.3.2.1 CS mechanism Physical and virtual CS functions are used to determine the state of the medium. When either function indicates a busy medium, the medium shall be considered busy; otherwise, it shall be considered idle. A physical CS mechanism shall be provided by the PHY. See Clause 8 for how this information is conveyed to the MAC. The details of physical CS are provided in the individual PHY specifications. A virtual CS mechanism shall be provided by the MAC. This mechanism is referred to as the NAV. The NAV maintains a prediction of future traffic on the medium based on duration information that is announced in RTS/ CTS frames by non-DMG STAs and RTS/DMG CTS frames by DMG STAs prior to the actual exchange of data. The duration information is also available in the MAC headers of all frames sent during the CP other than PS-Poll frames, and during the BTI, the A-BFT, the ATI, the CBAP, and the SP. The mechanism for setting the NAV using RTS/CTS or RTS/DMG CTS in the DCF is described in 10.3.2.4, use of the NAV in PCF is described in 10.4.3.3, and use of the NAV in HCF is described in 10.22.2.2 and 10.22.3.4. Additional details regarding NAV use appear in 10.3.2.5, 10.3.2.12, 10.36.10, and 10.26. The CS mechanism combines the NAV state and the STAâ€™s transmitter status with physical CS to determine the busy/idle state of the medium. The NAV may be thought of as a counter, which counts down to 0 at a uniform rate. When the counter is 0, the virtual CS indication is that the medium is idle; when the counter is nonzero, the indication is busy. If a DMG STA supports multiple NAVs as defined in 10.36.10 and all counters are 0, the virtual CS indication is that the medium is idle; when at least one of the counters is nonzero, the indication is busy. The medium shall be determined to be busy when the STA is transmitting. At aRxTxTurnaroundTime + aAirPropagationTime + aRxPHYDelay + 10% Ã— (aSlotTime â€“ aAirPropagationTime) after each MAC slot boundary as defined in 10.3.7 and 10.22.2.4, the MAC shall issue a PHY-CCARESET.request primitive to the PHY, where aAirPropagationTime determined as described in 10.21.5. 10.3.2.2 MAC-level acknowledgments The reception of some frames, as described in 10.3.2.9 and 10.4.4.5, requires the receiving STA to respond with an acknowledgment if the FCS of the received frame is correct. This technique is known as positive acknowledgment. 1305 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Lack of reception of an expected frame containing an acknowledgment indicates to the STA initiating the frame exchange that an error has occurred. Note, however, that the destination STA may have received the frame correctly, and that the error may have occurred in the transfer or reception of the frame containing an acknowledgment. When a frame containing an acknowledgment is lost, the MAC that initiated the frame exchange does not receive a protocol indication of whether the initial frame was correctly received. A correctly received frame is one for which the PHY-RXEND.indication primitive does not indicate an error and the FCS indicates the frame is error free. 10.3.2.3 IFS 10.3.2.3.1 General The time interval between frames is called the IFS. A STA shall determine that the medium is idle through the use of the CS function for the interval specified. Ten different IFSs are defined to provide priority levels for access to the wireless medium. Figure 10-4 shows some of these relationships. All timings are referenced from occurrence of the PHY interface primitives PHY-TXEND.confirm, PHY-TXSTART.confirm, PHY- RXSTART.indication, and PHY-RXEND.indication. AIFS[i] AIFS[i] DIFS PIFS Backoff Time SIFS Busy Medium Backoff Slots Next Frame Slot Time Select backoff time and decrement Defer Access as long as medium is idle Figure 10-4â€”Some IFS relationships The IFSs are as follows: a) RIFS reduced interframe space b) SIFS short interframe space c) PIFS PCF interframe space d) DIFS DCF interframe space e) AIFS arbitration interframe space (used by the QoS facility) f) EIFS extended interframe space g) SBIFS short beamforming interframe space h) BRPIFS beam refinement protocol interframe space i) MBIFS medium beamforming interframe space j) LBIFS long beamforming interframe space The different IFSs shall be independent of the STA bit rate. The IFS timings are defined as time gaps on the medium, and the IFS timings except AIFS are fixed for each PHY (even in multirate-capable PHYs). The IFSs are determined from attributes specified by the PHY. 1306 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.3.2.3.2 RIFS The use of RIFS for a non-DMG STA is obsolete, and support for such use might be subject to removal in a future revision of the standard. A VHT STA shall not transmit frames separated by a RIFS. RIFS is a means of reducing overhead and thereby increasing network efficiency. RIFS may be used in place of SIFS to separate multiple transmissions from a single transmitter, when no SIFS- separated response transmission is expected and either of the following is true: â€” The transmitter is not a DMG STA. â€” The transmitter is a DMG STA, and each transmission occurs with the same transmit antenna configuration. RIFS shall not be used between frames with different RA values. The duration of RIFS is defined by the aRIFS PHY characteristic (see Table 19-25 and Table 20-32). The RIFS is the time from the end of the last symbol of the previous frame to the beginning of the first symbol of the preamble of the subsequent frame as seen on the WM. A STA shall not allow the space between frames that are defined to be separated by a RIFS, as measured on the medium, to vary from the nominal RIFS (aRIFSTime) by more than Â± 10% of aRIFSTime. Two frames separated by a RIFS shall both be HT PPDUs or shall both be DMG PPDUs. An HT STA shall not transmit PPDUs separated by a RIFS unless the beacon or probe response most recently received from the BSSâ€™s AP contains an HT Operation element with RIFS Mode field equal to 1. There are additional restrictions regarding when RIFS may be employed as defined in 10.28 and 10.29. See also 10.26.3.3. 10.3.2.3.3 SIFS The SIFS is the time from the end of the last symbol, or signal extension if present, of the previous frame to the beginning of the first symbol of the preamble of the subsequent frame as seen on the WM. The SIFS shall be used prior to transmission of an Ack frame, a CTS frame, a PPDU containing a BlockAck frame that is an immediate response to either a BlockAckReq frame or an A-MPDU, a DMG CTS frame, a DMG DTS frame, a Grant Ack frame, a response frame transmitted in the ATI, the second or subsequent MPDU of a fragment burst, and by a STA responding to any polling by the PCF. The SIFS may also be within a TXOP or by a PC for any types of frames during the CFP (see 10.4). An IEEE 802.11 implementation of a non-DMG STA shall not allow the space between frames that are defined to be separated by a SIFS, as measured on the medium, to vary from the nominal SIFS by more than Â±10% Ã— (aSlotTime â€“ aAirPropagationTime) for the PHY in use. An implementation of a DMG STA shall not allow the space between frames that are defined to be separated by a SIFS, as measured on the medium, to vary from the nominal SIFS by more than â€“0% or +10% Ã— (aSlotTime â€“ aAirPropagationTime). SIFS is the shortest of the IFSs between transmissions from different STAs. SIFS shall be used when STAs have seized the medium and need to keep it for the duration of the frame exchange sequence to be performed. Using the smallest gap between transmissions within the frame exchange sequence prevents other STAs, which are required to wait for the medium to be idle for a longer gap, from attempting to use the medium, thus giving priority to completion of the frame exchange sequence in progress. When transmitting a response frame immediately following a SIFS, a DMG STA shall set the TXVECTOR parameter LAST_RSSI of the response frame to the power that was measured on the received packet, as reported in the RCPI field of the frame that elicited the response frame. The encoding of the value is as follows: â€” Power values less than or equal to â€“68 dBm are represented as the value of 1. 1307 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” Power values between â€“68 dBm and â€“42 dBm are represented as p â€“ â€“ 71 + 0.5 ------------------------------------ , where p is the power in dBm. 2 â€” Power values greater than or equal to â€“42 dBm are represented as the value 15. â€” For all other cases, the STA shall set the TXVECTOR parameter LAST_RSSI of the transmitted frame to 0. A DMG STA that transmits a PPDU containing at least one individually addressed MPDU shall set the TXVECTOR parameter Turnaround to 1 if the STA is required to listen for an incoming PPDU immediately following the transmission of the PPDU; otherwise, the STA shall set the TXVECTOR parameter Turnaround to 0. The STA shall set the TXVECTOR parameter Turnaround to 0 when it transmits an RTS frame. 10.3.2.3.4 PIFS The PIFS is used to gain priority access to the medium. The PIFS may be used as described in the following list and shall not be used otherwise: â€” A STA operating under the PCF, as described in 10.4 â€” A STA transmitting a Channel Switch Announcement frame, as described in 11.9 or transmitting an Extended Channel Switch Announcement frame, as described in 11.10 â€” A STA transmitting a TIM frame, as described in 11.2.3.17 â€” An HC starting a CFP or a TXOP, as described in 10.22.3.2.3 â€” An HC or a non-AP QoS STA that is a polled TXOP holder recovering from the absence of an expected reception in a CAP, as described in 10.22.3.2.4 â€” An HT STA using dual CTS protection before transmission of the CTS2, as described in 10.3.2.8 â€” A TXOP holder continuing to transmit after a transmission failure, as described in 10.22.2.7 â€” A TXOP holder transmitting an RTS with a bandwidth signaling TA within a multiple frame transmission sequence, as specified in 10.22.2.7 â€” An RD initiator continuing to transmit using error recovery, as described in 10.28.3 â€” An HT AP during a PSMP sequence transmitting a PSMP recovery frame, as described in 10.29.2.3 â€” An HT STA performing clear channel assessment (CCA) in the secondary channel before transmitting a 40 MHz mask PPDU using EDCA channel access, as described in 11.16.9 â€” An AP continuing to transmit in a GCR block ack TXOP after the failure to receive a BlockAck frame, as described in 10.24.10 â€” A VHT STA performing CCA in the secondary 20 MHz, 40 MHz, and 80 MHz channels before transmitting a 40 MHz, 80 MHz, 160 MHz, or 80+80 MHz mask PPDU using EDCA channel access, as described in 10.22.3 â€” An AP or PCP continuing to transmit in the ATI after a transmission failure during the ATI (10.36.3) â€” A source DMG STA of an SP continuing to transmit after a transmission failure, as described in 10.36.6.2 â€” A DMG STA performing EDCA access during an allocated CBAP, as described in 10.36.5 â€” A TVHT STA performing CCA in the secondary TVHT_W and TVHT_2W channels before transmitting a TVHT_2W or TVHT_W+W mask PPDU and TVHT_4W or TVHT_2W+2W mask PPDU, respectively, using EDCA channel access, as defined in 10.22.3 With the exception of performing CCA in the secondary channel (where the timing is defined in 11.16.9), a STA using PIFS starts its transmission after its CS mechanism (see 10.3.2.1) determines that the medium is idle at the TxPIFS slot boundary, as defined in 10.3.7 and 10.22.2.4. 1308 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.3.2.3.5 DIFS The DIFS shall be used by STAs operating under the DCF to transmit Data frames (MPDUs) and Management frames (MMPDUs). A STA using the DCF may transmit if both: â€” After it has correctly received a frame, its CS mechanism (see 10.3.2.1) determines that the medium is idle at the TxDIFS slot boundary as defined in 10.3.7 â€” The STAâ€™s backoff timer has expired. 10.3.2.3.6 AIFS The AIFS shall be used by QoS STAs that access the medium using the EDCAF to transmit: all Data frames (MPDUs) except during the ATI or an SP, all Management frames (MMPDUs) except during the ATI or an SP, all Extension frames except for the DMG Beacon frame, and the following Control frames: â€” PS-Poll â€” SSW (if first transmission by an initiator in a CBAP) â€” Poll (if first transmission and when in a CBAP) â€” Grant (if first transmission and when in a CBAP and not transmitted in response to a SPR frame) â€” SPR (when in a CBAP and not transmitted as a response to a Poll) â€” RTS â€” CTS (when not transmitted as a response to an RTS frame) â€” DMG CTS (when not transmitted as a response to an RTS frame) â€” BlockAckReq â€” BlockAck (when not transmitted as a response to a BlockAckReq frame) A STA using the EDCAF shall obtain a TXOP for an AC if the STAâ€™s CS mechanism (see 10.3.2.1) determines that the medium is idle at the AIFS[AC] slot boundary (see 10.22.2.4), after a correctly received frame, and the backoff timer for that AC has expired. A non-AP and non-PCP QoS STA computes the time periods for each AIFS[AC] from dot11EDCATableAIFSN. In an infrastructure BSS, QoS STAs update their dot11EDCATableAIFSN values using information in the most recent EDCA Parameter Set element of Beacon frames received from the AP of the BSS (see 9.4.2.29) if the STA is a non-DMG STA or the most recent EDCA Parameter Set element of DMG Beacon and Announce frames received from the AP or PCP of the BSS if the STA is a DMG STA. A QoS AP or PCP computes the time periods for each AIFS[AC] from dot11QAPEDCATableAIFSN. 10.3.2.3.7 EIFS A DCF shall use EIFS before transmission, when it determines that the medium is idle following reception of a frame for which the PHY-RXEND.indication primitive contained an error or a frame for which the FCS value was not correct. Similarly, a STAâ€™s EDCA mechanism under HCF shall use the EIFSâ€“DIFS+AIFS[AC] interval. The duration of an EIFS is defined in 10.3.7. The EIFS or EIFSâ€“DIFS+AIFS[AC] interval shall begin following indication by the PHY that the medium is idle after detection of the erroneous frame, without regard to the virtual CS mechanism. The STA shall not begin a transmission until the expiration of the later of the NAV and EIFS or EIFSâ€“DIFS+AIFS[AC]. The EIFS and EIFSâ€“DIFS+AIFS[AC] are defined to provide enough time for another STA to acknowledge what was, to this STA, an incorrectly received frame before this STA commences transmission. Reception of an error-free frame during the EIFS or EIFSâ€“DIFS+AIFS[AC] resynchronizes the STA to the actual busy/idle state of the medium, so the EIFS or EIFSâ€“DIFS+AIFS[AC] is terminated and medium access (using DIFS or AIFS as appropriate and, if necessary, backoff) continues following reception of that frame. At the expiration or termination of the EIFS or EIFSâ€“DIFS+AIFS[AC], the STA reverts to the NAV and physical CS to control access to the medium. 1309 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications EIFS shall not be invoked if the NAV is updated by the frame that would have caused an EIFS. EIFS shall not be invoked for an A-MPDU if one or more of its frames are received correctly. 10.3.2.3.8 SBIFS The SBIFS shall be used to separate multiple transmissions from a single transmitter during a receive sector sweep or when each transmission occurs with a different transmit antenna configuration and no SIFS- separated response transmission is expected. The duration of SBIFS is determined by the aSBIFSTime PHY characteristic. The SBIFS is the time from the end of the last symbol of the previous frame to the beginning of the first symbol of the preamble of the subsequent frame as seen on the WM. A STA shall not allow the space between frames that are defined to be separated by a SBIFS, as measured on the medium, to be less than aSBIFSTime or to be more than aSBIFSTime + aSBIFSAccuracy. Two frames separated by a SBIFS shall both be DMG PPDUs. 10.3.2.3.9 BRPIFS The BRPIFS shall be used by STAs between transmissions of BRP frames. The BRPIFS is the maximum time from the end of the last symbol of the previous PPDU, or training field if present in the PPDU, to the beginning of the first symbol of the preamble of the subsequent PPDU as seen on the WM. The corresponding minimum time is SIFS. BRPIFS is defined to be equal to aBRPIFS+10%. 10.3.2.3.10 MBIFS The MBIFS shall be used between the BTI and the A-BFT and between the ISS, RSS, SSW-Feedback, and SSW-Ack. MBIFS is equal to 3Ã—aSIFSTime. An implementation of a DMG STA shall not allow the space between frames that are defined to be separated by an MBIFS, as measured on the medium, to vary from the nominal MBIFS by more than â€“0% or +10% Ã— (aSlotTime â€“ aAirPropagationTime). 10.3.2.3.11 LBIFS The LBIFS shall be used between transmissions employing different DMG antennas and when the recipient STA is expected to switch DMG antennas. LBIFS is equal to TXTIME(SSW) + 2Ã—SBIFS. An implementation of a DMG STA shall not allow the space between frames that are defined to be separated by an LBIFS, as measured on the medium, to vary from the nominal LBIFS by more than â€“0% or +10% Ã— (aSlotTime â€“ aAirPropagationTime). 10.3.2.4 Setting and resetting the NAV This subclause describes the setting and resetting of the NAV for non-DMG STAs and DMG STAs that support a single NAV. DMG STAs that support multiple NAVs shall update their NAVs according to the procedures described in 10.36.10. A STA that receives at least one valid frame in a PSDU can update its NAV with the information from any valid Duration field in the PSDU. When the received frameâ€™s RA is equal to the STAâ€™s own MAC address, the STA shall not update its NAV. Further, when the received frame is a DMG CTS frame and its TA is equal to the STAâ€™s own MAC address, the STA shall not update its NAV. For all other received frames the STA shall update its NAV when the received Duration is greater than the STAâ€™s current NAV value. Upon receipt of a PS-Poll frame, a STA shall update its NAV settings as appropriate under the data rate selection rules using a duration value equal to the time, in microseconds, required to transmit one Ack frame plus one SIFS, but only when the new NAV value is greater than the current NAV value. If the calculated duration includes a fractional microsecond, that value is rounded up to the next higher integer. Various additional conditions may set or reset the NAV, as described in 10.4.3.3. When the NAV is reset, a PHY- CCARESET.request primitive shall be issued. This NAV update operation is performed when the PHY- RXEND.indication primitive is received. 1310 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Figure 10-5 indicates the NAV for STAs that might receive the RTS frame, while other STAs might receive only the CTS frame, resulting in the lower NAV bar as shown (with the exception of the STA to which the RTS frame was addressed). Figure 10-5â€”RTS/CTS/data/Ack and NAV setting A STA that used information from an RTS frame as the most recent basis to update its NAV setting is permitted to reset its NAV if no PHY-RXSTART.indication primitive is received from the PHY during a NAVTimeout period starting when the MAC receives a PHY-RXEND.indication primitive corresponding to the detection of the RTS frame. In non-DMG BSS, NAVTimeout period is equal to (2 x aSIFSTime) + (CTS_Time) + aRxPHYStartDelay + (2 x aSlotTime). The â€œCTS_Timeâ€ shall be calculated using the length of the CTS frame and the data rate at which the RTS frame used for the most recent NAV update was received. In DMG BSS, NAVTimeout period is equal to (2 x aSIFSTime) + TDMG-CTS + StartDelayCompensation + (2 x aSlotTime), where TDMG-CTS is the duration of a DMG CTS frame calculated using the TXVECTOR TRN- LEN parameter equal to the RXVECTOR TRN-LEN parameter of the received RTS frame and StartDelayCompensation is equal to aSlotTime. NOTEâ€”This value of StartDelayCompensation is a compromise over the possible values of aRxPHYStartDelay, which are dependent on both the implementation and the DMG PHY mode. A STA supporting L-SIG TXOP that used the information from a frame with different L-SIG duration and MAC duration endpoints (characteristics of an L-SIG TXOP initiating frame; see 10.26.5.4 for details) as the most recent basis to update its NAV setting may reset its NAV if no PHY-RXSTART.indication primitive is received from the PHY during a period with a duration of aSIFSTime + aRxPHYStartDelay + 2 aSlotTime starting at the expiration of the L-SIG duration. For details of L-SIG duration, see 10.26.5. 10.3.2.5 RTS/CTS with fragmentation The following is a description of using RTS/CTS for a fragmented MSDU or MMPDU. The RTS/CTS frames define the duration of the following frame and acknowledgment. The Duration/ID field in the Data and Ack frames specifies the total duration of the next fragment and acknowledgment. This is illustrated in Figure 10-6. 1311 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DIFS PIFS NAV (Fragment 0) SIFS NAV (RTS) NAV (Fragment 1) Backoff-Window Other NAV (CTS) NAV (ACK 0) NAV (ACK 1) RTS SIFS SIFS SIFS SIFS SIFS SIFS SIFS Fragment 0 Fragment 1 Fragment 2 Source CTS ACK 0 ACK 1 ACK 3 Destination Figure 10-6â€”RTS/CTS with fragmented MSDU Each frame contains information that defines the duration of the next transmission. The duration information from RTS frames shall be used to update the NAV to indicate busy until the end of Ack frame 0. The duration information from the CTS frame shall also be used to update the NAV to indicate busy until the end of Ack frame 0. Both Fragment 0 and Ack frame 0 shall contain duration information to update the NAV to indicate busy until the end of Ack frame 1. This shall be done by using the Duration/ID field in the Data and Ack frames. This shall continue until the last fragment, which shall have a duration of one Ack time plus one SIFS, and its Ack frame, which shall have its Duration/ID field set to 0. Each fragment and Ack frame acts as a virtual RTS frame and CTS frame; therefore no further RTS/CTS frames need to be generated after the RTS/ CTS that began the frame exchange sequence even though the PSDUs carrying subsequent fragments may be larger than dot11RTSThreshold. In the case where an acknowledgment is sent but not received by the source STA, STAs that heard the fragment, or Ack frame, mark the channel busy for the next frame exchange due to the NAV having been updated from these frames. This is the worst-case situation, and it is shown in Figure 10-7. If an acknowledgment is not sent by the destination STA, STAs that can only hear the destination STA do not update their NAV and may attempt to access the channel when their NAV updated from the previously received frame reaches 0. All STAs that hear the source are free to access the channel after their NAV updated from the transmitted fragment has expired. Figure 10-7â€”RTS/CTS with transmitter priority and missed acknowledgment 1312 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.3.2.6 VHT RTS procedure A VHT STA transmitting an RTS frame carried in non-HT or non-HT duplicate format and addressed to a VHT STA shall set the TA field to a bandwidth signaling TA and shall set the TXVECTOR parameters CH_BANDWIDTH_IN_NON_HT and CH_BANDWIDTH to the same value. If the STA sending the RTS frame is capable of dynamic bandwidth operation (see 10.3.2.7), the STA shall set the TXVECTOR parameter DYN_BANDWIDTH_IN_NON_HT to Dynamic. Otherwise, the STA shall set the TXVECTOR parameter DYN_BANDWIDTH_IN_NON_HT to Static. A VHT STA that initiates a TXOP by transmitting an RTS frame with the TA field set to a bandwidth signaling TA shall not send an RTS frame to a non-VHT STA for the duration of the TXOP. NOTEâ€”A non-VHT STA considers the bandwidth signaling TA as the address of the TXOP holder. If an RTS frame is sent to a non-VHT STA during a TXOP that is initiated by an RTS frame with a bandwidth signaling TA, the non-VHT STA does not recognize the RTS sender as the TXOP holder. 10.3.2.7 CTS and DMG CTS procedure A STA that receives an RTS frame addressed to it considers the NAV in determining whether to respond with CTS, unless the NAV was set by a frame originating from the STA sending the RTS frame (see 10.22.2.2). In this subclause, â€œNAV indicates idleâ€ means that the NAV count is 0 or that the NAV count is nonzero but the nonbandwidth signaling TA obtained from the TA field of the RTS frame matches the saved TXOP holder address. A VHT STA that is addressed by an RTS frame in a non-HT or non-HT duplicate PPDU that has a bandwidth signaling TA and that has the RXVECTOR parameter DYN_BANDWIDTH_IN_NON_HT equal to Static behaves as follows: â€” If the NAV indicates idle and CCA has been idle for all secondary channels (secondary 20 MHz channel, secondary 40 MHz channel, and secondary 80 MHz channel) in the channel width indicated by the RTS frameâ€™s RXVECTOR parameter CH_BANDWIDTH_IN_NON_HT for a PIFS prior to the start of the RTS frame, then the STA shall respond with a CTS frame carried in a non-HT or non-HT duplicate PPDU after a SIFS. The CTS frameâ€™s TXVECTOR parameters CH_BANDWIDTH and CH_BANDWIDTH_IN_NON_HT shall be set to the same value as the RTS frameâ€™s RXVECTOR parameter CH_BANDWIDTH_IN_NON_HT. â€” Otherwise, the STA shall not respond with a CTS frame. A VHT STA that is addressed by an RTS frame in a non-HT or non-HT duplicate PPDU that has a bandwidth signaling TA and that has the RXVECTOR parameter DYN_BANDWIDTH_IN_NON_HT equal to Dynamic behaves as follows: â€” If the NAV indicates idle, then the STA shall respond with a CTS frame in a non-HT or non-HT duplicate PPDU after a SIFS. The CTS frameâ€™s TXVECTOR parameters CH_BANDWIDTH and CH_BANDWIDTH_IN_NON_HT shall be set to any channel width for which CCA on all secondary channels has been idle for a PIFS prior to the start of the RTS frame and that is less than or equal to the channel width indicated in the RTS frameâ€™s RXVECTOR parameter CH_BANDWIDTH_IN_NON_HT. â€” Otherwise, the STA shall not respond with a CTS frame. A non-VHT STA that is addressed by an RTS frame or a VHT STA that is addressed by an RTS frame carried in a non-HT or non-HT duplicate PPDU that has a nonbandwidth signaling TA or a VHT STA that is addressed by an RTS frame in a format other than non-HT or non-HT duplicate behaves as follows: â€” If the NAV indicates idle, the STA shall respond with a CTS frame after a SIFS. â€” Otherwise, the STA shall not respond with a CTS frame. 1313 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The RA field of the CTS frame shall be set to the nonbandwidth signaling TA obtained from the TA field of the RTS frame to which this CTS frame is a response. The Duration field in the CTS frame shall be the duration field from the received RTS frame, adjusted by subtraction of aSIFSTime and the number of microseconds required to transmit the CTS frame at a data rate determined by the rules in 10.7. After transmitting an RTS frame, the STA shall wait for a CTSTimeout interval with a value of aSIFSTime + aSlotTime + aRxPHYStartDelay. This interval begins when the MAC receives a PHY-TXEND.confirm primitive. If a PHY-RXSTART.indication primitive does not occur during the CTSTimeout interval, the STA shall conclude that the transmission of the RTS frame has failed, and this STA shall invoke its backoff procedure upon expiration of the CTSTimeout interval. If a PHY-RXSTART.indication primitive does occur during the CTSTimeout interval, the STA shall wait for the corresponding PHY-RXEND.indication primitive to determine whether the RTS frame transmission was successful. The recognition of a valid CTS frame sent by the recipient of the RTS frame, corresponding to this PHY-RXEND.indication primitive, shall be interpreted as successful response, permitting the frame exchange sequence to continue (see Annex G). The recognition of anything else, including any other valid frame, shall be interpreted as failure of the RTS frame transmission. In this instance, the STA shall invoke its backoff procedure at the PHY-RXEND.indication primitive and may process the received frame. A DMG STA follows the procedure defined in this subclause, except that it uses a DMG CTS frame instead of a CTS frame. A non-DMG STA does not transmit DMG CTS frames. 10.3.2.8 Dual CTS protection 10.3.2.8.1 Dual CTS protection procedure The use of the dual CTS mechanism is deprecated. A VHT STA shall not transmit VHT PPDUs in a TXOP protected by dual CTS protection. A VHT AP shall not transmit an HT Operation element with the Dual CTS Protection field set to 1. If the Dual CTS Protection field of the HT Operation element has value 1 in the Beacon frames transmitted by its AP, a non-AP HT STA shall start every TXOP with an RTS frame addressed to the AP. The RTS frame shall be an STBC frame if the STBC transmit and receive capabilities of the non-AP HT STA allow it to receive and transmit STBC frames using a single spatial stream; otherwise, the RTS frame shall be a non- STBC frame. The AP shall respond with a dual CTS (CTS1 followed by CTS2) separated by PIFS or SIFS. Table 10-2 describes the sequence of CTS frame transmissions and the required timing. Table 10-2â€”Dual CTS rules Type of RTS CTS description Timing RTS CTS1: Same rate or MCS as PIFS shall be used as the interval between CTS1 and CTS2. (non-STBC the RTS frame (non-STBC frame) frame) If the CS mechanism (see 10.3.2.1) indicates that the medium is CTS2: Basic STBC MCS busy at the TxPIFS slot boundary (see Figure 10-26) following (STBC frame) CTS1, CTS2 shall not be transmitted as part of this frame exchange. RTS CTS1: Basic STBC MCS SIFS shall be used as the interval between CTS1 and CTS2. (STBC frame) (STBC frame) The STA resumes transmission a SIFS+CTS2+SIFS after CTS2: Lowest basic rate receiving CTS1, instead of after SIFS. (non-STBC frame) 1314 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The dual CTS response applies only to the AP; a non-AP STA shall respond to an RTS frame with a single CTS frame. If dual CTS Protection is enabled, the AP shall begin each EDCA TXOP with a CTS frame. This CTS frame uses STBC when the immediately following frame uses non-STBC and vice versa. The RA of this CTS frame shall be identical to the RA of the immediately following frame. The AP may continue a PIFS after the CTS frame, only if the CS mechanism (see 10.3.2.1) indicates that the medium is IDLE at the TxPIFS slot boundary (see Figure 10-26) following the transmission of the CTS frame. To avoid the resetting of NAV by STAs that have set their NAV due to the reception of a non-STBC RTS frame that is part of a dual CTS exchange, but then do not hear the CTS2, a non-AP HT STA may create a NAV that is not resettable according to the RTS NAV reset rule defined in 10.3.2.4 at the receiving STAs by initiating the TXOP with a non-STBC CTS addressed to the AP (known as CTS-to-AP). NOTEâ€”Sending a CTS-to-AP allows NAV protection to be established without causing the AP to update its NAV, as opposed to, for example, the sending of a CTS-to-self frame, which would potentially have caused the AP NAV to become set and then prevented it from responding to the subsequent RTS frame. The AP does not set a NAV in the CTS- to-AP case and is able to respond to the following RTS frame. The NAV at receiving STAs is not updated by the RTS frame because its duration does not exceed the duration of the preceding CTS frame, and subsequently, the NAV cannot be reset during CTS2. An STBC CTS addressed to the AP may be transmitted prior to an STBC RTS frame to set a NAV that is not resettable according to the RTS NAV reset rule defined in 10.3.2.4 at receiving STAs. NOTEâ€”When an HT STA sends an RTS frame to the AP that is a non-STBC frame, the AP returns a CTS frame that is a non-STBC frame to the STA and then immediately transmits a CTS frame that is an STBC frame. The original non-AP STA is now free to transmit. But a non-HT STA that has set its NAV based on the original RTS frame might reset its NAV and then decrement its backoff counter, given that a SIFS + the duration of CTS2 is longer than a DIFS (i.e., the STA does not detect PHY-RXSTART.indication primitive within the period specified in 10.3.2.4). Thus, without sending a CTS-to-AP, the NAV reservation might not always work. If dual CTS protection is enabled and a STA obtains a TXOP and does not have any frames to transmit before the expiration of the TXOP duration, the STA may indicate truncation of the TXOP provided that the remaining duration of the TXOP after the transmission of the last frame can accommodate the CF-End frame, a CF-End frame that is an STBC frame duration at the basic STBC MCS, a CF-End frame that is a non-STBC frame at the lowest basic rate, and three SIFSs. The STA indicates truncation of the TXOP by transmitting a CF-End frame with TXVECTOR parameter restrictions as specified in 10.7.6.3. On receiving a CF-End frame from a STA with a matching BSSID, an AP whose last transmitted HT Operation element contained the Dual CTS Protection field equal to 1 shall respond with dual CF-End frames, one CF-End frame that is an STBC frame at the basic STBC MCS and one CF-End frame that is a non-STBC frame at the lowest basic rate, after a SIFS. Dual CF-End frames eliminate unfairness toward STAs that are not of the same mode as the one that owns the TXOP being truncated. If the TXOP is owned by the AP and dual CTS protection is enabled in the system, the AP may send dual CF- End frames if it runs out of frames to transmit, provided that the remaining TXOP duration after the transmission of the last frame can accommodate a STBC CF-End frame duration at the lowest STBC basic rate, a CF-End frame that is a non-STBC frame at the lowest basic rate, and two SIFSs. The spacing between the dual CF-End frames sent by the AP shall be SIFS. The first CF-End frame shall use the same encoding (STBC frame versus non-STBC frame) used for transmissions in the TXOP being truncated, and the second CF-End frame shall use the other encoding. An STBC-capable STA shall choose between control frame operation using either STBC frames or non-STBC frames. In the non-STBC frame case, it discards Control frames that are STBC frames it receives. In the STBC frame case, it discards Control frames that are non-STBC frames received from its own BSS. This choice is a matter of policy local at the STA. 1315 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.3.2.8.2 Dual CTS protection examples Figure 10-8 shows an example of the operation of the dual CTS protection mechanism. In this example, the initiating STA is an STBC non-AP STA. Key: non-AP STA CTS to AP STBC frame CF-End STBC Data RTS Non-STBC frame SIFS SIFS SIFS SIFS â‰¥ SIFS SIFS SIFS Optional CF-End CF-End AP CTS CTS Ack NAV of 3rd-party STBC STA near non-AP STA NAV of 3rd-party STBC STA near AP NAV of 3rd-party non-STBC STA Figure 10-8â€”Example of dual CTS mechanism (STBC initiator) Figure 10-9 shows an example of the operation of the dual CTS protection mechanism. In this example, the initiating STA is a non-STBC non-AP HT STA. Key: non-AP HT Non-STBC CTS to AP STBC frame CF-End STA Data RTS Non-STBC frame SIFS SIFS PIFS SIFS â‰¥ SIFS SIFS SIFS Optional CF-End CF-End AP CTS CTS Ack NAV of 3rd-party STBC STA rd NAV of 3 -party non-STBC STA near non-AP STA NAV of 3rd-party non-STBC not near non-AP STA Figure 10-9â€”Example of dual CTS mechanism (non-STBC initiator) 10.3.2.9 Acknowledgment procedure The cases when an Ack or BlockAck frame can be generated are shown in the frame exchange sequences listed in Annex G. A STA shall not transmit an Ack frame in response to a Management frame of subtype Action No Ack. A non- AP STA shall not transmit an Ack or BlockAck frame in response to a group addressed frame. NOTEâ€”Group addressed MSDUs are sent to an AP in individually addressed frames. 1316 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Otherwise, upon reception of a frame that requires acknowledgment and, for an AP, with the To DS subfield equal to 1, a STA shall transmit an Ack or BlockAck frame after a SIFS, without regard to the busy/idle state of the medium. (See Figure 10-10.) Source Data SIFS Ack/ Destination BA DIFS Other Backoff Slots Defer Access Backoff after Defer Figure 10-10â€”Individually addressed data/Ack/BA frame After transmitting an MPDU that requires an Ack or BlockAck frame as a response (see Annex G), the STA shall wait for an AckTimeout interval, with a value of aSIFSTime + aSlotTime + aRxPHYStartDelay, starting at the PHY-TXEND.confirm primitive. If a PHY-RXSTART.indication primitive does not occur during the AckTimeout interval, the STA concludes that the transmission of the MPDU has failed, and this STA shall invoke its backoff procedure upon expiration of the AckTimeout interval. If a PHY-RXSTART.indication primitive does occur during the AckTimeout interval, the STA shall wait for the corresponding PHY-RXEND.indication primitive to determine whether the MPDU transmission was successful. If the STA recognizes a valid Ack frame addressed to the STA and corresponding to this PHY- RXEND.indication primitive, this recognition shall be interpreted as successful acknowledgment. If the STA does not recognize a valid Ack frame addressed to the STA, this condition shall be interpreted as failure of its MPDU transmission. In this instance, the STA shall invoke its backoff procedure at the PHY- RXEND.indication primitive and may process the received frame. If the STA has transmitted a PS-Poll frame, then the STAâ€™s receipt and recognition of a valid Data or Management frame transmitted by the recipient of the PS-Poll frame shall also be accepted as successful acknowledgment of the PS-Poll frame. NOTE 1â€”The backoff procedure in the specific case of reception of a corrupted Ack or BlockAck frame results in EIFS rather than DIFS or AIFS being used after the AckTimeout interval and subsequent reception of the corrupted Ack or BlockAck frame (see 10.3.4.3 and 10.22.2.4 respectively). NOTE 2â€”The receiver STA performs the acknowledgment procedure on all received frames requiring acknowledgment, even if an MSDU or A-MSDU is carried partly or wholly within the frame and is subsequently discarded due to drop eligibility (see DEI subfield in 9.2.4.6.2). NOTE 3â€”The rules that specify the contents of BlockAck frames are defined in 10.24. 10.3.2.10 MU acknowledgment procedure The acknowledgment procedure performed by a STA that receives MPDUs that were transmitted within a VHT MU PPDU is the same as the acknowledgment procedure for MPDUs that were not transmitted within a VHT MU PPDU. 1317 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NOTEâ€”All MPDUs transmitted within a VHT MU PPDU are contained within A-MPDUs, and the rules specified in 9.7.3 prevent an immediate response to more than one of the A-MPDUs. Responses to A-MPDUs within a VHT MU PPDU that are not immediate responses to the VHT MU PPDU are transmitted in response to explicit BlockAckReq frames by the AP. Examples of VHT MU PPDU frame exchange sequences are shown in Figure 10-11 and Figure 10-12. SIFS SIFS SIFS SIFS SIFS AP VHT MU PPDU BAR BAR STA 1 BA/Ack STA 2 BA/Ack STA 3 BA/Ack Figure 10-11â€”Example of TXOP containing VHT MU PPDU transmission with immediate acknowledgment to VHT MU PPDU SIFS SIFS SIFS SIFS SIFS SIFS AP VHT MU PPDU BAR BAR BAR STA 1 BA/Ack STA 2 BA/Ack STA 3 BA/Ack Figure 10-12â€”Example of TXOP containing VHT MU PPDU transmission with no immediate acknowledgment to VHT MU PPDU Recovery within the TXOP that contains a VHT MU PPDU can be performed according to the rules of 10.22.2.7. BlockAckRequest frames related to A-MPDUs within a VHT MU PPDU can be transmitted in a TXOP separate from the one that contained the VHT MU PPDU. NOTE 1â€”A BlockAck frame or an Ack frame is sent in immediate response to the BlockAckReq frame for HT- immediate or HT-delayed Block Ack, respectively. An Ack frame might be sent in immediate response to a VHT single MPDU in the VHT MU PPDU. NOTE 2â€”A BlockAckRequest frame would typically not be sent to a STA in the case where the A-MPDU to the STA contained no MPDUs requiring acknowledgment. It could be sent if MPDUs in a previous A-MPDU remain unacknowledged. 1318 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.3.2.11 Duplicate detection and recovery 10.3.2.11.1 General Because MAC-level acknowledgments and retransmissions are incorporated into the protocol, there is the possibility that a frame may be received more than once. The procedures defined in this subclause attempt to filter out these duplicates. Additional duplicate filtering is performed during Receive Buffer Operation for frames that are part of a block ack agreement as described in 10.24.4 and 10.24.7. Duplicate frame filtering is facilitated through the inclusion of a Sequence Control field (consisting of a sequence number and fragment number) within Data, Management, and Extension frames, a TID subfield in the QoS Control field within QoS Data frames, and an ACI subfield in the Sequence Number field within QMFs. NOTEâ€”In 10.3.2.11, Data frames with a value of 1 in the QoS subfield of the Subtype subfield are collectively referred to as QoS Data frames. 10.3.2.11.2 Transmitter requirements A STA maintains one or more sequence number spaces that are used when transmitting a frame to determine the sequence number for the frame. When multiple sequence number spaces are supported, the appropriate sequence number space is determined by information from the MAC control fields of the frame to be transmitted. Except as noted below, each sequence number space is represented by a modulo 4096 counter, starting at 0 and incrementing by 1, for each MSDU or MMPDU transmitted using that sequence number space. NOTEâ€”Group addressed retransmissions of BUs use the same sequence number as the initial group addressed transmission of the BU. Unicast retransmissions of a group addressed BU delivered via DMS use the same sequence number as the initial unicast transmission of the BU. When a BU is delivered both using group addressing and unicast (e.g., when DMS is active but there are other associated STAs not using DMS), the sequence number might differ between the group addressed and unicast transmissions of the same BU. MPDUs that are part of the same MSDU or A-MSDU shall have the same sequence number. Different MSDUs or A-MSDUs have (with a high probability) a different sequence number. A transmitting STA shall support the applicable sequence number spaces defined in Table 10-3. Applicability is defined by the â€œapplies toâ€ column. The â€œStatusâ€ column indicates the level of support that is required if â€œApplies toâ€ matches the transmission. The â€œMultiplicityâ€ column indicates whether the sequence number space contains a single counter, or multiple counters and in the latter case identifies any indexes. The â€œTransmitter requirementsâ€ column identifies requirements for the operation of this sequence number space. The referenced requirements are defined at the end of the table. Table 10-3â€”Transmitter sequence number spaces Sequence Sequence number Transmitter number Applies to Status Multiplicity space requirements space identifier SNS1 Baseline A STA transmitting a frame Mandatory Single TR1 that is not covered by any of Instance the other sequence number spaces. SNS2 Individually A STA transmitting an Mandatory Indexed by addressed individually addressed QoS

1319 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 10-3â€”Transmitter sequence number spaces (continued) Sequence Sequence number Transmitter number Applies to Status Multiplicity space requirements space identifier SNS3 Time Priority A QoS STA transmitting a Optional Indexed by Management Time Priority Management

SNS4 QMF A QMF STA transmitting a Mandatory Indexed by TR2 QMF

SNS5 QoS (+)Null A STA transmitting a QoS Mandatory None TR3 (+)Null frame TR1: A transmitting STA should cache the last used sequence number per RA for frames that are assigned sequence numbers from this sequence number space. The STA should check that the successively assigned sequence numbers for frames transmitted to a single RA do not have the same value as is found in the cache for that RA. If the check fails the STA should increment the counter by 2, rather than 1. TR2: The STA shall assign the sequence number from one modulo 1024 counter per

tuple starting at 0 and incrementing by 1 for each MMPDU carried in one or more QMFs with Address 1 and ACI fields matching the

tuple values corresponding to that counter. TR3: Sequence numbers for transmitted QoS (+)Null frames may be set to any value. 10.3.2.11.3 Receiver requirements A STA maintains one or more duplicate detection caches. Table 10-4 defines the conditions under which a duplication detection cache is supported and the rules followed by the receiver for the cache. When a Data, Management or Extension frame is received, a record of that frame is inserted in an appropriate cache. That record is identified by a sequence number and possibly other information from the MAC control fields of the frame. When a Data, Management or Extension frame is received in which the Retry subfield of the Frame Control field is equal to 1, the appropriate cache, if any, is searched for a matching frame. In DMG, when a group addressed frame is received the appropriate cache is searched for a matching frame. If the search is successful, the frame is considered to be a duplicate. Duplicate frames are discarded. NOTEâ€”The receiver STA performs the Ack and (for an AP) PS procedures on all received frames requiring acknowledgment, even if the frame is discarded due to duplicate filtering. There is a small possibility that a frame may be improperly rejected due to such a match; however, this occurrence is rare and simply results in a lost frame (similar to an FCS error in other LAN protocols). A receiving STA shall implement the applicable receiver requirements defined in Table 10-4 with â€œStatusâ€ indicated as â€œMandatoryâ€. A receiving STA should implement the applicable receiver requirements defined in Table 10-4 with â€œStatusâ€ indicated as â€œRecommendedâ€. A receiving STA may implement the applicable receiver requirements defined in Table 10-4 with â€œStatusâ€ indicated as â€œOptionalâ€. Applicability is defined by the â€œapplies toâ€ column. The â€œStatusâ€ column indicates the level of support that is required if â€œApplies toâ€ matches the received frame. The â€œMultiplicity / Cache sizeâ€ column indicates the indexes that identify a cache entry and the number of entries that shall be supported. The â€œReceiver requirementsâ€ column identifies requirements for the operation of this cache. The referenced requirements are defined at the end of the table. The requirements relate to caching information that identifies a cache entry and discarding duplicate MPDUs. 1320 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 10-4â€”Receiver caches Receiver Cache Multiplicity / Cache Receiver cache Applies to Status name size requirements identifier RC1 Not QoS A STA receiving frames Mandatory Indexed by:

. RR5 QoS Data, excluding if supported: At least the most recent RC4 cache entry per RC5

. RC6 RC7 RC8 RC10 RC2 QoS A STA receiving an Mandatory Indexed by:

. frame, excluding RC3, and if supported: At least the most recent RC7, RC8, RC9, and cache entry per RC10

pair in this cache. RC3 QoS A QoS STA receiving a Mandatory None RR4 (+)Null QoS (+)Null frame RC4 Non- A STA receiving an Recommen Indexed by:

RR5 Manage Management frame, ment excluding RC6 if RC6 is At least the most recent supported cache entry per

value. RC5 Time A STA receiving an Supported if Indexed by:

. ment Management frame otherwise not At least the most recent supported cache entry per

value. RC6 QMFs A STA receiving an Mandatory Indexed by:

RR5 The most recent cache entry per

. 1321 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 10-4â€”Receiver caches (continued) Receiver Cache Multiplicity / Cache Receiver cache Applies to Status name size requirements identifier RC7 Nonmes A nonmesh STA Mandatory Indexed by: addressed frame subject to a GCR agreement. One cache entry per tuple for each group address subject to a GCR agreement. RC8 Mesh A mesh STA receiving a Mandatory Indexed by: . agreement. One cache entry per tuple for each group address subject to a GCR agreement. RC9 QoS A non-DMG QoS STA Recommen None RR4 Data receiving a QoS Data ded under frame sent under a BA BA agreement RC10 DMG A DMG STA receiving a Mandatory Indexed by:

The most recent cache entry per

. RR1: A receiving non-DMG STA with dot11QMFActivated false or not present and with dot11RobustAVStreamingImplemented false or not present should omit tuples obtained from group addressed frames from this cache. RR2: A receiving STA should omit tuples obtained from ATIM frames from this cache. RR3: A receiving QMF STA that is a non-DMG STA with dot11RobustAVStreamingImplemented false or not present shall omit from the cache all tuples obtained from group addressed Data frames. RR4: For the purposes of duplicate detection using receiver caches, QoS (+)Null frames and, in a non-DMG BSS, QoS Data frames under a BA agreement, shall be ignored. RR5: The STA shall discard the frame if the Retry subfield of the Frame Control field is 1 and it matches an entry in the cache. RR6: The STA shall discard the frame if it matches an entry in the cache. 10.3.2.12 NAV distribution When a node needs to distribute NAV information, for instance, to reserve the medium for a transmission of a nonbasic rate frame (that might not be heard by other nodes in the BSS), the node may first transmit a CTS frame with the RA field equal to its own MAC address (CTS-to-self) if the node is a non-DMG STA, or it may 1322 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications transmit a DMG CTS frame with the RA field equal to its own MAC address and the TA field equal to the MAC address of the peer STA for which the forthcoming transmission of the node is intended (DMG CTS-to- self) if the node is a DMG STA. A duration value in the frame protects the pending transmission, plus possibly an Ack frame. The CTS-to-self and DMG CTS-to-self NAV distribution mechanisms are lower in network overhead cost than are the RTS/CTS and RTS/DMG CTS NAV distribution mechanisms, respectively, but CTS-to-self and DMG CTS-to-self are less robust against hidden nodes and collisions than RTS/CTS and RTS/DMG CTS-to- self, respectively. STAs employing a NAV distribution mechanism should choose a mechanism that is appropriate for the given network conditions. If errors occur when employing the CTS-to-self or DMG CTS- to-self mechanism, STAs should switch to a more robust mechanism. 10.3.2.13 Operation of aSlotTime A STA in which dot11ShortSlotTimeOptionImplemented is true shall set the MAC variable aSlotTime to the short slot value upon transmission or reception of Beacon, Probe Response, Association Response, and Reassociation Response frames from the BSS that the STA has joined or started and that have the short slot subfield equal to 1. The STA shall set the MAC variable aSlotTime to the long slot value upon transmission or reception of Beacon, Probe Response, Association Response, and Reassociation Response frames from the BSS that the STA has joined or started and that have the short slot subfield equal to 0. A STA in which dot11ShortSlotTimeOptionImplemented is false shall set the MAC variable aSlotTime to the long slot value at all times. A STA in which dot11ShortSlotTimeOptionImplemented is not present, or when the PHY supports only a single slot time value shall set the MAC variable aSlotTime to the slot value appropriate for the attached PHY. 10.3.3 Random backoff time A STA desiring to initiate transfer of Data frames and/or Management frames using the DCF shall invoke the CS mechanism (see 10.3.2.1) to determine the busy/idle state of the medium. If the medium is busy, the STA shall defer until the medium is determined to be idle without interruption for a period of time equal to DIFS when the last frame detected on the medium was received correctly, or after the medium is determined to be idle without interruption for a period of time equal to EIFS when the last frame detected on the medium was not received correctly. After this DIFS or EIFS medium idle time, the STA shall then generate a random backoff period (defined by Equation (10-1)) for an additional deferral time before transmitting, unless the backoff timer already contains a nonzero value, in which case the selection of a random number is not needed and not performed. This process minimizes collisions during contention between multiple STAs that have been deferring to the same event. Backoff Time = Random() aSlotTime (10-1) where Random() = Pseudorandom integer drawn from a uniform distribution over the interval [0,CW], where CW is an integer within the range of values of the PHY characteristics aCWmin and aCW- max, aCWmin CW aCWmax. It is important that designers recognize the need for statistical independence among the random number streams among STAs. The contention window (CW) parameter shall take an initial value of aCWmin. Every STA shall maintain a STA short retry count (SSRC) as well as a STA long retry count (SLRC), both of which shall take an initial value of 0. The SSRC shall be incremented when any short retry count (SRC) associated with any MPDU with the Type subfield equal to Data is incremented. The SLRC shall be incremented when any long retry count (LRC) associated with any MPDU with the Type subfield equal to Data is incremented. The CW shall take the next value in the series every time an unsuccessful attempt to transmit an MPDU causes either STA retry 1323 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications counter to increment, until the CW reaches the value of aCWmax. A retry is defined as the entire sequence of frames sent, separated by SIFSs, in an attempt to deliver an MPDU, as described in Annex G. Once it reaches aCWmax, the CW shall remain at the value of aCWmax until the CW is reset. This improves the stability of the access protocol under high-load conditions. See Figure 10-13. Figure 10-13â€”Example of exponential increase of CW The CW shall be reset to aCWmin after every successful attempt to transmit a frame containing all or part of an MSDU or MMPDU, when SLRC reaches dot11LongRetryLimit, or when SSRC reaches dot11ShortRetryLimit. The SSRC shall be reset to 0 when a CTS frame is received in response to an RTS frame, when a BlockAck frame is received in response to a BlockAckReq frame, when an Ack frame is received in response to the transmission of a frame containing all or part of an MSDU or MMPDU that is contained in a PSDU of length less than or equal to dot11RTSThreshold, or when a frame with a group address in the Address 1 field is transmitted. The SLRC shall be reset to 0 when an Ack frame is received in response to transmission of a frame containing all or part of an MSDU or MMPDU that is contained in a PSDU of length greater than dot11RTSThreshold, or when a frame with a group address in the Address 1 field is transmitted. The set of CW values shall be sequentially ascending integer powers of 2, minus 1, beginning with a PHY- specific aCWmin value, and continuing up to a PHY-specific aCWmax value. 10.3.4 DCF access procedure 10.3.4.1 Introduction The CSMA/CA access method is the foundation of the DCF. The operational rules vary slightly between the DCF and the PCF. 10.3.4.2 Basic access Basic access refers to the core mechanism a STA uses to determine whether it may transmit using the DCF. 1324 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A STA may transmit an MPDU when it is operating under the DCF access method, either in the absence of a PC, or in the CP of the PCF access method, when the STA determines that the medium is idle when a frame is queued for transmission, and remains idle for a period of a DIFS, or an EIFS (10.3.2.3.7) from the end of the immediately preceding medium-busy event, whichever is the greater, and the backoff timer is zero. Otherwise the random backoff procedure described in 10.3.4.3 shall be followed. A DMG STA operating under the DCF access method should transmit frames with its transmit antenna pattern directed toward the intended receiver. A DMG STA operating under the DCF access method that does not operate in a TXOP exchange may configure its receiving antenna array to a quasi-omni antenna pattern to be ready to receive frames from any DMG STA. NOTEâ€”The steady state of the antenna configuration might depend on the actual applications in which a DMG STA is involved. For example, a DMG STA that expects transactions with several STAs during a CBAP configures the receiving antenna to a quasi-omni pattern to be ready to receive transmission from any of the STAs. A DMG STA that expects transactions with a single STA (e.g., AP or PCP) might keep its receiving antenna directed to the peer STA. A DMG STA operating under the DCF access method that is participating in a TXOP exchange should configure its receiving antenna array to be directed toward the other transmitter involved in the TXOP. The basic access mechanism is illustrated in Figure 10-14. Access after DIFS under certain conditions DIFS PIFS Backoff Time DIFS SIFS Busy Medium Backoff Slots Next Frame Slot Time Select backoff time and decrement Defer Access as long as medium is idle Figure 10-14â€”Basic access method 10.3.4.3 Backoff procedure for DCF This subclause describes backoff procedure that is to be invoked when DCF is used. For the backoff procedure when EDCA is used, see 10.22.2.2. A STA shall invoke the backoff procedure to transfer a frame when finding the medium busy as indicated by either the physical or virtual CS mechanism (see Figure 10-15). A transmitting STA shall invoke the backoff procedure when the STA infers a failed transmission as defined in 10.3.2.7 or 10.3.2.9. To begin the backoff procedure, the STA shall set its backoff timer to a random backoff time using the equation in 10.3.3. All backoff slots occur following a DIFS during which the medium is determined to be idle for the duration of the DIFS, or following an EIFS during which the medium is determined to be idle for the duration of the EIFS, as appropriate (see 10.3.2.3) except that no backoff slots for DCF occur during the BTI, the A- BFT, the ATI, and non-CBAP portions of the DTI. A STA performing the backoff procedure shall use the CS mechanism (see 10.3.2.1) to determine whether there is activity during each backoff slot. If no medium activity is indicated for the duration of a particular backoff slot, then the backoff procedure shall decrement its backoff timer by aSlotTime. 1325 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Figure 10-15â€”Backoff procedure If the medium is determined to be busy at any time during a backoff slot, then the backoff procedure is suspended; that is, the backoff timer shall not decrement for that slot. The medium shall be determined to be idle for the duration of a DIFS or EIFS, as appropriate (see 10.3.2.3), before the backoff procedure is allowed to resume. Transmission shall commence when the backoff timer reaches 0. A backoff procedure shall be performed immediately after the end of every transmission with the More Fragments bit equal to 0 of an MPDU with the Type subfield equal to Data, Management, or Control with subtype PS-Poll, even if no additional transmissions are currently queued. In the case of successful acknowledged transmissions, this backoff procedure shall begin at the end of the received Ack frame. In the case of unsuccessful transmissions requiring acknowledgment, this backoff procedure shall begin at the end of the AckTimeout interval (as defined in 10.3.2.9). An unsuccessful transmission is one where an Ack frame is not received from the STA addressed by the RA field of the transmitted frame and the value of the RA field is an individual address. If the transmission is successful, the CW value reverts to aCWmin before the random backoff interval is chosen, and the SSRC and/or SLRC are updated as described in 10.3.3. The result of this procedure is that transmitted frames from a STA are always separated by at least one backoff interval. The effect of this procedure is that when multiple STAs are deferring and go into random backoff, then the STA selecting the smallest backoff time using the random function wins the contention (assuming all of the contending STAs detect the same instances of WM activity at their respective receivers, a situation that is not always true, due to hidden node effects and interference events). The number of DMG STAs that are able to detect each WM transmission is reduced even further due to SPSH. In an IBSS the backoff timer for a pending non-Beacon or non-ATIM transmission shall not decrement in the period from the TBTT until the expiration of the ATIM window, and the backoff timer for a pending ATIM frame shall decrement only within the ATIM window. (See Clause 11.) Within an IBSS a separate backoff interval shall be generated to precede the transmission of a Beacon frame, as described in 11.1.3.5. At the start of an awake window, a DMG STA shall suspend decrementing its backoff timer(s) for any transmission of non-ATIM frames for the duration of the awake window as indicated in the most recently received Awake Window element. At the end of the awake window, the DMG STA shall resume the backoff timer(s) for non-ATIM frames. A DMG STA shall not decrement the backoff timer for a pending ATIM frame outside the awake window. Figure 10-17 describes the backoff procedure for DMG STAs for the example topology shown in Figure 10-16. 1326 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STA C STA A STA E STA B STA D Figure 10-16â€”Example topology of NAV setting in DMG STAs DIFS A Frame to STA E Backoff STA A Ack to STA D Virtual Backoff CS=busy STA B RTS to STA B RTS to STA B CS= Backoff Backoff busy STA C End of DMG CTS DIFS timeout DIFS Data to STA B Backoff STA D Backoff STA E Response to STA A Figure 10-17â€”Backoff procedure for DMG STAs At the time that STA A starts transmitting a frame to STA E and STA E starts receiving the frame, the antennas of both stations are directed to the peer, i.e., the transmitting antennas of STA A are directed to STA E and the receiving antennas of STA E are directed to STA A. At this point, STA B, STA C, and STA D are not involved in any frame exchange; therefore, they are in receiving state and happen to have the configuration of their receiving antenna arrays set to a quasi-omni antenna pattern to be ready to receive frames from any STA. STA B receives the frame transmitted by STA A (to STA E), and CS (physical and virtual) in STA B indicates a busy medium during the exchange between STA A and STA E. STA D is not able to receive the frame transmitted by STA A or the response transmitted by STA E; hence CS in STA D indicates IDLE for the duration of the exchange between STA A and STA E. 1327 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The physical CS function of STA C indicates a medium busy condition when it receives the response sent by STA E, but indicates an idle medium condition during the transmission from STA A. STA A and STA E (which are directly involved in the frame exchange), STA B (which received the frame sent by STA A), and STA C (which received the response sent by STA E) are synchronized at point A, where the transaction between STA A and STA E completes. Since STA D cannot hear the directional transmissions from either STA A or STA C, its physical CS indicates an idle medium condition for the duration of the frame exchange, enabling a frame exchange with STA B at the same time as the frame exchange between STA A and STA E. This is an example of SPSH. Because STA C is unaware of the transmission of the frame from STA A to STA E, STA C transmits an RTS to STA B. But STA C does not receive a DMG CTS from STA B since the CS at STA B is busy when STA B receives the RTS from the STA C. This causes STA C to retry the RTS transmission following the expiration of a backoff count, which occurs after the completion of the exchange between STA A and STA E. 10.3.4.4 Recovery procedures and retransmit limits Under DCF, error recovery is always the responsibility of the STA that initiates a frame exchange sequence (described in Annex G). Many circumstances may cause an error to occur that requires recovery. For example, the CTS frame might not be returned after an RTS frame is transmitted. This may happen due to a collision with another transmission, due to interference in the channel during the RTS or CTS frame, or because the STA receiving the RTS frame has an active virtual CS condition (indicating a busy medium time period). Error recovery shall be attempted by retrying transmissions for frame exchange sequences that the initiating STA infers have failed. Retries shall continue, for each failing frame exchange sequence, until the transmission is successful, or until the relevant retry limit is reached, whichever occurs first. A STA shall maintain a SRC and an LRC for each MSDU or MMPDU awaiting transmission. These counts are incremented and reset independently of each other. After an RTS frame is transmitted, the STA shall perform the CTS procedure, as defined in 10.3.2.7. If the RTS frame transmission fails, the SRC for the MSDU or MMPDU and the SSRC are incremented. This process shall continue until the number of attempts to transmit that MSDU or MMPDU reaches dot11ShortRetryLimit. After transmitting a frame that requires acknowledgment, the STA shall perform the acknowledgment procedure, as defined in 10.3.2.9. The SRC for an MPDU with the Type subfield equal to Data or Management and of length less than or equal to dot11RTSThreshold and the SSRC shall be incremented every time transmission that MPDU fails. This SRC and the SSRC shall be reset when transmission of that MPDU succeeds. The LRC for an MPDU with the Type subfield equal to Data or Management and of length greater than dot11RTSThreshold and the SLRC shall be incremented every time transmission of that MPDU fails. This LRC and the SLRC shall be reset when transmission of that MPDU succeeds. All retransmission attempts for an MPDU with the Type subfield equal to Data or Management that has failed the acknowledgment procedure one or more times shall be made with the Retry subfield set to 1. Retries for failed transmission attempts shall continue until the SRC for the MPDU with the Type subfield equal to Data or Management is equal to dot11ShortRetryLimit or until the LRC for the MPDU with the Type subfield equal to Data or Management is equal to dot11LongRetryLimit. When either of these limits is reached, retry attempts shall cease, and the MPDU with the Type subfield Data (and any MSDU of which it is a part) or Management shall be discarded. A DMG STA, in addition to using random access within a CBAP, may transmit retries in available scheduled SPs. A STA in PS mode, in an infrastructure BSS, initiates a frame exchange sequence by transmitting a PS-Poll frame to request data from an AP. If no Ack, Data, or Management frame is received from the AP in response 1328 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications to a PS-Poll frame, then the STA shall retry the sequence, by transmitting another PS-Poll frame. If the AP sends a Data or Management frame in response to a PS-Poll frame, but fails to receive the Ack frame acknowledging this Data or Management frame, the next PS-Poll frame from the same STA may cause a retransmission of the last MSDU 28. If the AP responds to a PS-Poll frame by transmitting an Ack frame, then responsibility for the Data or Management frame delivery error recovery shifts to the AP because the data are transferred in a subsequent frame exchange sequence, which is initiated by the AP. The AP shall attempt to deliver one buffered BU to the STA that transmitted the PS-Poll frame, using any frame exchange sequence valid for an individually addressed BU. If the PS STA that transmitted the PS-Poll frame returns to doze state after transmitting the Ack frame in response to successful receipt of this BU, but the AP fails to receive this Ack frame, then the AP retries transmission of this BU until the relevant retry limit is reached. See 11.2.3.8 for details on filtering of extra PS-Poll frames. An AP that fails to receive an acknowledgment after the AP transmits a frame with the More Data subfield set to 0 to a non-AP VHT STA that is in TXOP power save mode retransmits the frame within the current TXOP under certain conditions as described in 11.2.3.19. 10.3.4.5 Control of the channel The SIFS is used to provide an efficient MSDU delivery mechanism. Once the STA has contended for the channel, that STA shall continue to send fragments until either all fragments of a single MSDU or MMPDU have been sent or an acknowledgment is not received. Should the sending of the fragments be interrupted due to one of these reasons, when the next opportunity for transmission occurs the STA shall resume transmission. The algorithm by which the STA decides which of the outstanding MSDUs shall next be attempted after an unsuccessful transmission (as defined in 10.3.4.3) attempt is beyond the scope of this standard, but any such algorithm shall comply with the restrictions listed in 10.8. Figure 10-18 illustrates the transmission of a multiple-fragment MSDU using the SIFS. Figure 10-18â€”Transmission of a multiple-fragment MSDU using SIFS When the source STA transmits a fragment, it shall release the channel, then immediately monitor the channel for an acknowledgment as described in 10.3.2.9. When the destination STA has finished sending the acknowledgment, the SIFS following the acknowledgment shall be reserved for the source STA to continue (if necessary) with another fragment. The STA sending the acknowledgment shall not transmit on the channel immediately following the acknowledgment. The process of sending multiple fragments after contending for the channel is defined as a fragment burst. If the source STA does not receive an acknowledgment frame, it shall attempt to retransmit the failed MPDU or another eligible MPDU, as defined in 10.8, after performing the backoff procedure and the contention process. 28 This duplicate MSDU is filtered at the receiving STA using the duplicate frame filtering mechanism. 1329 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications After a STA contends for the channel to retransmit a fragment of an MSDU, it shall start with the last fragment that was not acknowledged. The destination STA shall receive the fragments in order (because the source sends them in order and they are individually acknowledged). It is possible, however, that the destination STA may receive duplicate fragments. It shall be the responsibility of the receiving STA to detect and discard duplicate fragments. A STA shall transmit after the SIFS only under the following conditions during a fragment burst: â€” The STA has just received a fragment that requires acknowledgment. â€” The source STA has received an acknowledgment for a previous fragment and has more fragment(s) for the same MSDU to transmit. The following rules shall also apply: â€” When a STA has transmitted a frame other than an initial or intermediate fragment, that STA shall not transmit on the channel following the acknowledgment for that frame, without performing the backoff procedure. â€” When an MSDU has been successfully delivered or all retransmission attempts have been exhausted, and the STA has a subsequent MSDU to transmit, then that STA shall perform a backoff procedure. 10.3.5 Individually addressed MPDU transfer procedure A STA using the DCF shall use an RTS/CTS exchange for individually addressed frames when the length of the PSDU is greater than the length threshold indicated by dot11RTSThreshold. A STA may also use an RTS/ CTS exchange for individually addressed frames when it is necessary to distribute the NAV or when it is necessary to establish protection (see 10.26). Otherwise a STA using the DCF shall not use the RTS/CTS exchange. If dot11RTSThreshold is 0, all MPDUs shall be delivered with the use of RTS/CTS. If dot11RTSThreshold is larger than the maximum PSDU length, all PSDUs shall be delivered without RTS/CTS exchanges. When an RTS/CTS exchange is used, the PPDU containing the PSDU shall be transmitted starting one SIFS after the end of the CTS frame. NOTEâ€”No regard is given to the busy or idle status of the medium when transmitting this PSDU. When an RTS/CTS exchange is not used, the PSDU shall be transmitted following the success of the basic access procedure. With or without the use of the RTS/CTS exchange procedure, the STA that is the destination of a Data frame shall follow the acknowledgment procedure. 10.3.6 Group addressed MPDU transfer procedure When a STA transmits group addressed MPDUs in which the To DS subfield is 0, the STA shall use the basic access procedure, unless these MPDUs are delivered using PCF or using the group addressed transmission service (GATS). When GATS is not used to deliver group addressed MPDUs, the STA shall not use an RTS/ CTS or RTS/DMG CTS exchange, regardless of the length of the frame. In addition, no recipient of the frame shall transmit an Ack frame. A STA that transmits a group addressed MPDU in which the To DS subfield is 1 shall, in addition to complying with the basic access procedure of CSMA/CA, obey the rules for RTS/CTS exchange and the acknowledgment procedure because the MPDU is directed to the AP. For DMG STAs, the MPDU transmission shall also comply with the access procedures defined in 10.36. There is no MAC-level recovery on group addressed frames, except for the following: â€” Frames in which the To DS subfield is 1 â€” Group addressed frames transmitted via the GATS 1330 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications As a result, the reliability of this traffic is reduced, relative to the reliability of individually addressed traffic, due to the increased probability of lost frames from interference, collisions, or time-varying channel properties. A DMG STA may transmit a copy of the same group addressed MPDU using different antenna configurations. This might be needed to provide a quasi-omni coverage or to enable transmission by an MCS that is higher than MCS 0. If multiple copies of a group addressed MPDU with a To DS subfield equal to 0 are transmitted, the STA shall not transmit a different frame before the completion of the transmission of all copies of the group addressed MPDU. NOTEâ€”The following paragraph addresses the Dual CTS protection mechanism. The use of the Dual CTS protection mechanism is deprecated. An STBC-capable STA shall discard either all received group addressed Data frames that are STBC frames or all received group addressed Data frames that are non-STBC frames. How it makes this decision is outside the scope of this standard. A STA shall discard an MPDU with a group address in the Address 1 field if the value in the Address 1 field does not match any value in the dot11GroupAddressesTable and does not match the Broadcast address value. 10.3.7 DCF timing relations The IFSs are periods of time on the medium. The attributes of the IFSs are determined by the specific PHY (see Figure 10-19). The IFSs apply to transmission under EDCA, too (see Figure 10-25). DIFS PIFS aSIFSTime aSlotTime First backoff slot Medium busy D1 Rx/Tx M1 D2 D2 D2 CCAdel CCAdel CCAdel M2 M2 M2 PHYâ€RXEND.indication Rx/Tx Rx/Tx Rx/Tx aSlotTime aSlotTime aSlotTime MAC slot TxSIFS TxPIFS TxDIFS First backoff boundaries slot boundary slot boundary slot boundary slot boundary D1 = aRxPHYDelay (referenced from the end of the last symbol of a PPDU on the medium) D2 = D1 + aAirPropagationTime Rx/Tx = aRxTxTurnaroundTime (begins with a PHYâ€TXSTART.request) M1 = M2 = aMACProcessingDelay CCAdel = aCCATime â€“ D1 Figure 10-19â€”DCF timing relationships All medium timings that are referenced from the end of the transmission are referenced from the end of the last symbol, or signal extension if present, of the PPDU. The beginning of transmission refers to the first symbol of the preamble of the next PPDU. All MAC timings are referenced from the PHY-TXEND.confirm, PHY- TXSTART.confirm, PHY-RXSTART.indication, and PHY-RXEND.indication primitives. aSIFSTime and aSlotTime are determined per PHY, aSIFSTime is fixed, and aSlotTime can change dynamically as aAirPropagationTime changes (see 10.21.5). 1331 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The STA may employ any non-negative value for each of the parameters: â€” aRxPHYDelay â€” aMACProcessingDelay â€” aTxPHYDelay â€” aTxRampOnTime â€” aCCATime â€” aRxTxSwitchTime provided that the constraints in Equation (10-2), Equation (10-3), and Equation (10-4) are met, and provided that the CCA sensitivity specification for the attached PHY is met (see 15.4.6.5, 16.3.8.5, 17.3.10.6, 18.4.6 and 19.3.19.5, 20.4.4.2.2, 20.6.4.2.2, 21.3.18.5, and 22.3.18.6). aSIFSTime = aRxPHYDelay + aMACProcessingDelay + aRxTxTurnaroundTime (10-2) aSlotTime = aCCATime + aMACProcessingDelay + aRxTxTurnaroundTime + aAirPropagationTime (10-3) aRxTxTurnaroundTime = aTxPHYDelay + aRxTxSwitchTime + aTxRampOnTime (10-4) where aAirPropagationTime is determined as described in 10.21.5 aSlotTime, aSIFSTime and aRxTxTurnaroundTime are the values indicated in the PLME-CHARACTER- ISTICS.confirm primitive the other attribute values are the values implemented The PIFS and DIFS are derived by the Equation (10-5) and Equation (10-6), as illustrated in Figure 10-19. PIFS = aSIFSTime + aSlotTime (10-5) DIFS = aSIFSTime + 2 aSlotTime (10-6) When dot11DynamicEIFSActivated is false or not defined, the EIFS is derived from the SIFS and the DIFS and the length of time it takes to transmit an Ack frame at the lowest PHY mandatory rate by Equation (10-7). EIFS = aSIFSTime + AckTxTime + DIFS (10-7) where AckTxTime is the time expressed in microseconds required to transmit an Ack frame, including preamble, PHY header and any additional PHY dependent information, at the lowest PHY mandatory rate. When dot11DynamicEIFSActivated is true, EIFS is based on an estimated duration of the PPDU that is the possible response to the PPDU that causes the EIFS. When dot11DynamicEIFSActivated is true, if the PPDU that causes the EIFS does not contain a single MPDU with a length equal to 14 or 32 octets, and the modulation of the PPDU that causes the EIFS is included in Table 10-5, then EIFS is determined as shown in Equation (10-8). 1332 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications EIFS = aSIFSTime + EstimatedAckTxTime + DIFS (10-8) where EstimatedAckTxTime is based on an estimated duration of the PPDU that is the possible response to the PPDU that causes the EIFS, as specified in Table 10-5. Table 10-5â€”Determination of the EstimatedAckTxTime based on properties of the PPDU causing the EIFS Modulation of Other properties Presumed Rate/MCS of PPDU Presumed EstimatedAck PPDU causing of PPDU causing response causing EIFS response TxTime (Âµs) EIFS EIFS rate (HR-)DSSS 1 Mb/s Ack 1 Mb/s 304 (HR-)DSSS â‰¥ 2 Mb/s (long Ack 2 Mb/s 248 preamble) (HR-)DSSS â‰¥ 2 Mb/s (short Ack 2 Mb/s 152 preamble) (ERP-)OFDM BPSK Ack 6 Mb/s 44 (ERP-)OFDM QPSK Ack 12 Mb/s 32 (ERP-)OFDM â‰¥16-QAM Ack 24 Mb/s 28 HT BPSK Aggregation = 0 Ack 6 Mb/s 44 HT QPSK Aggregation = 0 Ack 12 Mb/s 32 HT â‰¥16-QAM Aggregation = 0 Ack 24 Mb/s 28 HT BPSK Aggregation = 1 BlockAck 6 Mb/s 68 HT QPSK Aggregation = 1 BlockAck 12 Mb/s 44 HT â‰¥16-QAM Aggregation = 1 BlockAck 24 Mb/s 32 VHT BPSK BlockAck 68 VHT QPSK BlockAck 44 VHT â‰¥16-QAM BlockAck 32 When dot11DynamicEIFSActivated is true and the PPDU that causes the EIFS contains a single MPDU with a length equal to 14 or 32 octets, EIFS is equal to DIFS. This reflects the fact that a 14 or 32 octet MPDU is very likely an Ack or a BlockAck frame, which does not cause a response PPDU to be transmitted. When dot11DynamicEIFSActivated is true and the modulation of the PPDU that causes the EIFS does not occur in Table 10-5, then EIFS is determined as shown in Equation (10-7). Figure 10-19 illustrates the relation between the SIFS, PIFS, and DIFS as they are measured on the medium and the different MAC slot boundaries TxSIFS, TxPIFS, and TxDIFS. These slot boundaries define when the transmitter shall be turned on by the MAC to meet the different IFS timings on the medium, after subsequent detection of the CCA result of the previous slot time. 1333 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Equation (10-9), Equation (10-10) and Equation (10-11) define the MAC slot boundaries using attributes provided by the PHY, which are such that they compensate for implementation timing variations. The starting reference of these slot boundaries is again the end of the last symbol of the previous PPDU. TxSIFS = SIFS â€“ aRxTxTurnaroundTime (10-9) TxPIFS = TxSIFS + aSlotTime (10-10) TxDIFS = TxSIFS + 2 aSlotTime (10-11) NOTEâ€”The tolerance for SIFS is defined in 10.3.2.3.3. 10.3.8 Signal extension Transmissions of frames with TXVECTOR parameter FORMAT of type NON_HT with NON_HT_MODULATION values of ERP-OFDM and NON_HT_DUP_OFDM and transmissions of frames with TXVECTOR parameter FORMAT with values of HT_MF and HT_GF include a period of no transmission of duration aSignalExtension, except for RIFS transmissions. The purpose of this signal extension is to enable the NAV value of Clause 16 STAs to be set correctly. When an HT STA transmits a PPDU using a RIFS and with the TXVECTOR parameter FORMAT equal to NON_HT with the NON_HT_MODULATION parameter equal to one of ERP-OFDM and NON_HT_DUP_OFDM or a PPDU using a RIFS and with the TXVECTOR parameter FORMAT equal to HT_MF or HT_GF, it shall set the TXVECTOR parameter NO_SIG_EXTN to true. Otherwise, it shall set the TXVECTOR parameter NO_SIG_EXTN to false. 10.3.9 Determination of PLME aCWmin characteristics In the case of the Clause 18 ERP, the aCWmin value is dependent on the requesterâ€™s characteristic rate set. The characteristic rate set is equal to the IBSSâ€™s basic rate set when the STA is operating as a member of an IBSS. It is equal to the APâ€™s operational rate set when the STA is associated with an AP. At all other times, it is equal to the STAâ€™s mandatory rate set. The MAC variable aCWmin is set to aCWmin(0) if the characteristic rate set includes only rates in the set 1, 2, 5.5, 11; otherwise, aCWmin is set to aCWmin(1). If the returned value for aCWmin is a scalar, then the MAC always sets the variable aCWmin to the returned scalar value of aCWmin. 10.4 PCF 10.4.1 General The PCF mechanism is obsolete. Consequently, this subclause might be removed in a later revision of the standard. The PCF provides CF frame transfer. It is an option for an AP to be able to become the PC. A non-AP STA shall not become a PC. All STAs inherently obey the medium access rules of the PCF, because these rules are based on the DCF, and all STAs set their NAV at the beginning of each CFP. The operating characteristics of the PCF are such that all STAs are able to operate in the presence of a BSS in which a PC is operating, and, if associated with a point-coordinated BSS, are able to receive frames sent under PCF control. It is also an option for a STA to be able to respond to a CF-Poll received from a PC. A STA that is able to respond to CF-Polls is referred to as being CF-Pollable and may request to be polled by an active PC. CF-Pollable STAs and the PC do not use RTS/CTS in the CFP. When polled by the PC, a CF-Pollable STA may transmit only one MPDU, which might be sent to the PC but may have any destination, and may â€œpiggybackâ€ the acknowledgment of a frame received from the PC using particular data frame subtypes for this transmission. If the Data frame is not in turn acknowledged, the CF-Pollable STA shall not retransmit the frame unless it is polled again by the PC, or it decides to retransmit during the CP. If the addressed recipient of a CF transmission is not CF-Pollable, that 1334 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STA acknowledges the transmission using the DCF acknowledgment rules, and the PC retains control of the medium. A PC may use CF frame transfer solely for delivery of frames to STAs, and never to poll CF-Pollable STAs. A PC may perform a backoff on retransmission of an unacknowledged frame during the CFP. A PC that is maintaining a polling list may retry the unacknowledged frame the next time the particular AID is at the top of the polling list. A PC may retransmit an unacknowledged frame during the CFP after a PIFS. When more than one point-coordinated BSS is operating on the same PHY channel in overlapping space, the potential exists for collisions between PCF transfer activities by the independent PCs. The rules under which multiple, overlapping point-coordinated BSSs may coexist are presented in 10.4.4.3. As shown in Figure 10-1 (in 10.2), the PCF is built on top of the CSMA/CA-based DCF, by utilizing the access priority provisions provided by this scheme. An active PC shall be located at an AP, which restricts PCF operation to infrastructure networks. PCF is activated at a PC-capable AP by setting the CFPMaxDuration parameter in the CF Parameter Set of the MLME-START.request primitive to a nonzero value. Data frames sent by, or in response to polling by, the PC during the CFP shall use the appropriate data subtypes based upon the following usage rules: â€” Data +CF-Poll, Data +CF-Ack +CF-Poll, CF-Poll, and CF-Ack +CF-Poll shall be sent only by a PC. â€” Data, Data +CF-Ack, Null Function, and CF-Ack may be sent by a PC or by any CF-Pollable STA. A STA receiving Data frames shall consider the frame body as the basis of a possible indication to LLC only if the frame is of subtype Data, Data +CF-Ack, Data +CF-Poll, or Data +CF-Ack +CF-Poll. A CF-Pollable STA shall interpret all subtype bits of received Data type frames that contain the BSSID of the current BSS for CF purposes, but shall not inspect the frame body unless the frame is of subtype Data, Data +CF-Ack, Data +CF- Poll, or Data +CF-Ack +CF-Poll. 10.4.2 CFP structure and timing The PCF controls frame transfers during a CFP. The CFP shall alternate with a CP, when the DCF controls frame transfers, as shown in Figure 10-20. Each CFP shall begin with a Beacon frame that contains a DTIM element (referred to as DTIM Beacon frame). The CFPs shall occur at a defined repetition rate, which shall be synchronized with the beacon interval as specified in the following paragraphs. Figure 10-20â€”CFP/CP alternation The PC generates CFPs at the CFP repetition interval (CFPPeriod), which is defined as a number of DTIM intervals. The PC shall determine the CFPPeriod (depicted as a repetition interval in the illustrations in Figure 10-20 and Figure 10-21) to use from dot11CFPPeriod. This value, in units of DTIM intervals, shall be communicated to other STAs in the BSS in the CFPPeriod field of the CF Parameter Set element of Beacon 1335 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications frames. The CF Parameter Set element shall be present only in Beacon and Probe Response frames transmitted by STAs containing an active PC. Figure 10-21â€”Beacon frames and CFPs The length of the CFP is controlled by the PC, with maximum duration specified by dot11CFPMaxDuration. Neither the maximum duration nor the actual duration (signaled by transmission of a Control frame of subtype CF-End or CF-End +CF-Ack by the PC) is constrained to be a multiple of the beacon interval. If the CFP duration is greater than the beacon interval, the PC shall transmit Beacon frames at the appropriate times during the CFP (subject to delay due to traffic at the nominal times, as with all Beacon frames). The CF Parameter Set element in all Beacon frames at the start of, or within, a CFP shall contain a nonzero value in the CFPDurRemaining field. This value, in units of TU, shall specify the maximum time from the most recent TBTT to the end of this CFP. The value of the CFPDurRemaining field shall be 0 in Beacon frames sent during the CP. An example of these relationships is illustrated in Figure 10-21, which shows a case where the CFPPeriod is two DTIM intervals, the DTIM interval is three beacon intervals, and the aCFPMaxDuration value is approximately 2.5 beacon intervals. The PC may terminate any CFP at or before the limit given by dot11CFPMaxDuration, based on available traffic and size of the polling list. Because the transmission of any Beacon frame may be delayed due to a medium busy condition at the TBTT, a CFP may be shortened by the amount of the delay. In the case of a busy medium due to DCF traffic, the Beacon frame shall be delayed for the time required to complete the current DCF frame exchange. When the Beacon frame transmission is delayed, the CFPDurRemaining value in the Beacon frame at the beginning of the CFP shall specify a time that causes the CFP to end no later than TBTT plus the value of aCFPMaxDuration. This is illustrated in Figure 10-22. Target Beacon Transmission Time dot11CFPMaxDuration Beacon frame DCF Traffic Contention Period Nominal CF repetition interval (shortened) Contention-Free Period Max RTS + CTS + MPDU + Ack time Figure 10-22â€”Example of delayed beacon and shortened CFP 1336 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.4.3 PCF access procedure 10.4.3.1 General The CF transfer protocol is based on a polling scheme controlled by a PC operating at the AP of the BSS. The PC gains control of the medium at the beginning of the CFP and attempts to maintain control for the entire CFP by waiting a shorter time between transmissions than the STAs using the DCF access procedure. All STAs that receive Beacon frames containing a CF Parameter Set element, including STAs not associated with the BSS, set their NAVs to the CFPMaxDuration value at the nominal start time of each CFP. This prevents most contention by preventing nonpolled transmissions by STAs regardless of whether they are CF-Pollable. Acknowledgment of frames sent during the CFP may be accomplished using Data +CF-Ack, CF-Ack, Data +CF-Ack +CF-Poll (only on frames transmitted by the PC), or CF-Ack +CF-Poll (only on frames transmitted by the PC) frames when a Data (or Null) frame immediately follows the frame being acknowledged, thereby avoiding the overhead of separate Ack frames. Non-CF-Pollable or unpolled CF-Pollable STAs acknowledge frames during the CFP using the DCF acknowledgment procedure. 10.4.3.2 Fundamental access At the nominal beginning of each CFP, the PC shall sense the medium. When the medium is determined to be idle for one PIFS, the PC shall transmit a Beacon frame containing the CF Parameter Set element and a DTIM element. After the initial Beacon frame, the PC shall wait for one SIFS, and then transmit one of the following: a Data frame, a CF-Poll frame, a Data +CF-Poll frame, a Management frame, or a CF-End frame. If the CFP is null, i.e., no traffic is buffered and no polls exist to send at the PC, a CF-End frame shall be transmitted immediately after the initial Beacon frame. If there are non-GCR-SP buffered group addressed MSDUs/MMPDUs, the PC shall transmit these prior to any individually addressed MSDUs/MMPDUs. STAs receiving individually addressed, error-free frames from the PC are expected to respond after a SIFS, in accordance with the transfer procedures defined in 10.4.4. If the recipient STA is not CF-Pollable, the response to receipt of an error-free Data frame shall be an Ack frame. 10.4.3.3 NAV operation during the CFP The mechanism for handling the NAV during the CFP is designed to facilitate the operation of overlapping CFP coordinated infrastructure BSSs. The mechanism by which infrastructure BSSs coordinate their CFPs is beyond the scope of this standard. Each STA, except the STA with the PC, shall preset its NAV to the CFPMaxDuration value (obtained from the CF Parameter Set element in Beacon frames from this PC) at each TBTT (see Clause 11) at which a CFP is scheduled to start (based on the CFPCount field in the CF Parameter Set element of the Beacon frames from this PC). Each non-PC STA shall update its NAV using the CFPDurRemaining value in the CF Parameter Set element of any error-free Beacon frame that the STA receives. This includes CFPDurRemaining values in CF Parameter Set elements from Beacon frames received from other (overlapping) BSSs. These actions prevent STAs from taking control of the medium during the CFP, which is especially important when the CFP spans multiple medium-occupancy intervals. This setting of the NAV also reduces the risk of hidden STAs determining the medium to be idle for a DIFS during the CFP and possibly corrupting a transmission in progress. A STA joining a BSS operating with a PC shall use the information in the CFPDurRemaining element of the CF parameter set of any received Beacon or Probe Response frames to update its NAV prior to initiating any transmissions. 1337 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The PC shall transmit a CF-End or CF-End +CF-Ack frame at the end of each CFP. A STA that receives either of these frames, from any BSS, shall reset its NAV. 10.4.4 PCF transfer procedure 10.4.4.1 General Frame transfers under the PCF may consist of frames alternately sent from the AP/PC and sent to the AP/PC. During the CFP, the ordering of these transmissions, and the STA allowed to transmit frames to the PC at any given point in time, shall be controlled by the PC. Figure 10-23 depicts frame transfer during a typical CFP. The rules under which this frame transfer takes place are detailed in 10.4.4.2 to 10.4.4.5. Figure 10-23â€”Example of PCF frame transfer MaxMPDUTime is the time to transmit the maximum-sized MAC frame, expanded by security mechanisms, plus the time to transmit the PHY preamble, header, trailer, and expansion bits, if any. 10.4.4.2 PCF transfers when the PC STA is transmitter or recipient The PC shall transmit frames between the Beacon frame that starts the CFP and the CF-End frame using the SIFS except when a transmission by another STA is expected by the PC and a SIFS elapses without the receipt of the expected transmission. In such cases the PC may send its next pending transmission as soon as one PIFS after the end of its last transmission. This permits the PC to retain control of the medium in the presence of an overlapping BSS. The PC may transmit any of the following frame types to CF-Pollable STAs: â€” Data, used to send data from the PC when the addressed recipient is not being polled and there is no previous frame to acknowledge; â€” Data +CF-Ack, used to send data from the PC when the addressed recipient is not being polled or is not CF-Pollable or the DA is a group address and the PC needs to acknowledge the receipt of a frame received from a CF-Pollable STA a SIFS before starting this transmission; â€” Data +CF-Poll, used to send data from the PC when the addressed recipient is the next STA to be permitted to transmit during this CFP and there is no previous frame to acknowledge; â€” Data +CF-Ack +CF-Poll, used to send data from the PC when the addressed recipient is the next STA to be permitted to transmit during this CFP and the PC needs to acknowledge the receipt of a frame received from a CF-Pollable STA a SIFS before starting this transmission; â€” CF-Poll, used when the PC is not sending data to the addressed recipient but the addressed recipient is the next STA to be permitted to transmit during this CFP and there is no previous frame to acknowledge; 1338 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” CF-Ack +CF-Poll, used when the PC is not sending data to the addressed recipient but the addressed recipient is the next STA to be permitted to transmit during this CFP and the PC needs to acknowledge the receipt of a frame from a CF-Pollable STA a SIFS before starting this transmission; â€” CF-Ack, used when the PC is not sending data to, or polling, the addressed recipient, but the PC needs to acknowledge receipt of a frame from a CF-Pollable STA a SIFS before starting this transmission (useful when the next transmission by the PC is a Management frame, such as a Beacon frame); or â€” Any Management frame that is appropriate for the AP to send under the rules for that frame type. The PC may transmit Data or Management frames to a non-CF-Pollable, non-PS STA during the CFP. This STA shall acknowledge receipt with Ack frames after a SIFS, as with the DCF. The PC may also transmit group addressed frames during the CFP. Because the Beacon frame that initiates the CFP contains a DTIM element, if there are associated STAs using PS mode, the buffered group addressed frames that are not delivered via the GCR-SP delivery method shall be sent immediately after any Beacon frame that contains a TIM element whose DTIM Count field is 0. A CF-Pollable STA that receives an individually addressed Data frame of any subtype that includes CF-Poll may transmit one Data frame a SIFS after receiving the CF-Poll. NOTEâ€”A CF-Pollable STA ignores and does not reset its NAV when performing transmissions in response to a CF- Poll. Non-CF-Pollable STAs that receive an individually addressed frame during the CFP shall transmit an Ack frame, but shall not reset their NAV. For frames that require MAC-level acknowledgment, CF-Pollable STAs that received a CF-Poll (of any type) may perform this acknowledgment using the Data +CF-Ack subtype in the response to the CF-Poll. For example, the U1 frame in Figure 10-23 contains the acknowledgment to the preceding D1 frame. The D2 frame contains the acknowledgment to the preceding U1 frame. The PC may use the CF-Ack subtypes to acknowledge a received frame even if the Data frame sent with the CF-Ack subtype is addressed to a different STA than the one being acknowledged. CF-Pollable STAs that are expecting an acknowledgment shall interpret the subtype of the frame (if any) sent by the PC a SIFS after that STAâ€™s transmission to the PC. If a frame that requires MAC-level acknowledgment is received by a non-CF-Pollable STA, that STA shall not interpret the CF-Poll indication (if any), and shall acknowledge the frame by sending an Ack frame after a SIFS. The lengths of the frames may be variable, only bounded by the frame and/or fragment length limitations that apply for the BSS. If a CF-Pollable STA does not respond to a CF-Poll (of any type) within the SIFS following a transmission from the PC, or a non-CF-Pollable STA does not return the Ack frame within a SIFS following a transmission from the PC that requires acknowledgment, then the PC shall resume control and may transmit its next frame after a PIFS from the end of the PCâ€™s last transmission. A CF-Pollable STA shall respond to a frame with any data subtype that includes CF-Poll directed to its MAC address and received without error. If the STA has no frame to send when polled, the response shall be a Null frame. If the STA has no frame to send when polled, but an acknowledgment is required for the frame that conveyed the CF-Poll, the response shall be a CF-Ack (no data) frame. The null response is required to permit a â€œno-trafficâ€ situation to be distinguished from a collision between overlapping PCs. The CFP shall end when the CFPDurRemaining time has elapsed since the Beacon frame originating the CFP or when the PC has no further frames to transmit nor STAs to poll. In either case, the end of the CFP shall be signaled by the transmission of a CF-End frame by the PC. If there is a received frame that requires acknowledgment at the time the CF-End frame is to be transmitted, the PC shall transmit a CF-End +CF-Ack frame instead. A STA receiving a CF-End frame or CF-End +CF-Ack frame shall reset its NAV. 1339 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.4.4.3 Operation with overlapping point-coordinated BSSs Because the PCF operates without the CSMA/CA CW randomization and backoff of the DCF, there is a risk of repeated collisions if multiple, overlapping, point-coordinated BSSs are operating on the same PHY channel, and their CFP Rates and beacon intervals are approximately equal. To minimize the risk of significant frame loss due to CF collisions, the PC shall use a DIFS plus a random backoff delay (with CW in the range 1 to aCWmin) to start a CFP when the initial Beacon frame is delayed because of deferral due to a busy medium. The PC may use this backoff during the CFP prior to retransmitting an unacknowledged, individually addressed Data or Management frame. To further reduce the susceptibility to inter-PC collisions, the PC shall require that the medium be determined as being idle for a DIFS plus a random (over a range of 1 to aCWmin) number of slot times once every dot11MediumOccupancyLimit TU during the CFP. This results in loss of control of the medium to overlapping BSS or hidden STA traffic, because the STAs in this BSS are prevented from transmitting by their NAV setting to CFPMaxDuration or CFPDurRemaining. dot11MediumOccupancyLimit may be set equal to CFPMaxDuration, which provides no protection against PCF collisions. The dot11MediumOccupancyLimit is also useful for compliance in regulatory domains that impose limits on continuous transmission time by a single STA as part of a spectrum etiquette. 10.4.4.4 CFPMaxDuration limit The value of CFPMaxDuration shall be limited to allow coexistence between contention and CF traffic. The minimum value for CFPMaxDuration is two times MaxMPDUTime plus the time required to send the initial Beacon frame and the CF-End frame of the CFP. This may allow sufficient time for the AP to send one Data frame to a STA, while polling that STA, and for the polled STA to respond with one Data frame. The maximum value for CFPMaxDuration is the duration of (BeaconPeriod DTIMPeriod CFPPeriod) minus [MaxMPDUTime plus (2 aSIFSTime) plus (2 aSlotTime) plus (8 AckSize)], expressed in microseconds. MaxMPDUTime is the time to transmit the maximum-sized MAC frame, expanded by security mechanisms, plus the time to transmit the PHY preamble, header, trailer, and expansion bits, if any. This allows sufficient time to send at least one Data frame during the CP. 10.4.4.5 CF usage rules A PC may send group addressed frames, and individually addressed Data or Management frames to any active STA, as well as to CF-Pollable PS STAs. During the CFP, a CF-Pollable STA shall acknowledge after a SIFS, the receipt of each Data +CF-Poll frame or Data +CF-Ack +CF-Poll frame using Data +CF-Ack or CF-Ack (no data) frames, the receipt of each CF-Poll (no data) using Data or Null (no data), and the receipt of all other Data and Management frames using Ack frames. A non-CF-Pollable STA shall acknowledge receipt of Data and Management frames using Ack frames sent after a SIFS. This non-CF-Pollable operation is the same as that already employed by such STAs for DCF operation. When polled by the PCF (Data +CF-Poll, Data +CF-Ack +CF-Poll, CF-Poll, or CF-Ack +CF-Poll) a CF-Pollable STA may send one Data frame to any destination. Such a frame directed to or through the PC STA shall be acknowledged by the PC, using the CF-Ack indication (Data +CF-Ack, Data +CF-Ack +CF-Poll, CF- Ack, CF-Ack +CF-Poll, or CF-End +CF-Ack) sent after a SIFS. Such a frame directed to a non-CF-Pollable STA shall be acknowledged using an Ack frame sent after a SIFS. A polled CF-Pollable STA with neither a Data frame nor an acknowledgment to send shall respond by transmitting a Null frame after a SIFS. A polled CF-Pollable STA with insufficient time before the end of the CFP or current medium occupancy limit to send its queued MPDU and receive an acknowledgment shall respond by transmitting a Null frame, or a CF-Ack frame if polled using Data +CF-Poll or Data +CF-Ack +CF-Poll, after a SIFS. The CF-Pollable STA may set the More Data bit to 1 in its response to permit the PC to distinguish between an empty STA queue and a response due to insufficient time to transfer an MPDU. 1340 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The PC shall not issue frames with a subtype that includes CF-Polls if insufficient time remains in the current CFP to permit the polled STA to transmit a Data frame containing a minimum length MPDU. 10.4.5 CF polling list 10.4.5.1 General If the PC supports use of the CFP for inbound frame transfer as well as for frame delivery, the PC shall maintain a â€œpolling listâ€ for use in selecting STAs that are eligible to receive CF-Polls during CFPs. The polling list functional characteristics are defined below. If the PC supports the use of the CFP solely for frame delivery, the PC does not require a polling list, and shall never generate Data frames with a subtype that includes CF-Poll. The form of CF support provided by the PC is identified in the Capability Information field of Beacon, Association Response, Reassociation Response, and Probe Response frames, which are sent from APs. Any such frames sent by STAs, as in noninfrastructure networks, shall have these bits set to 0. The polling list is used to force the polling of CF-Pollable STAs, regardless of whether the PC has pending traffic to transmit to those STAs. The polling list may be used to control the use of Data +CF-Poll and Data +CF-Ack +CF-Poll types for transmission of Data frames being sent to CF-Pollable STAs by the PC. The polling list is a logical construct, which is not exposed outside of the PC. A minimum set of polling list maintenance techniques are required to in order to provide interoperability of arbitrary CF-Pollable STAs in BSSs controlled by arbitrary APs with active PCs. An AP may also implement additional polling list maintenance techniques that are outside the scope of this standard. 10.4.5.2 Polling list processing The PC shall send a CF-Poll to at least one STA during each CFP when there are entries in the polling list. During each CFP, the PC shall issue polls to a subset of the STAs on the polling list in order by ascending AID value. While time remains in the CFP, all CF frames have been delivered, and all STAs on the polling list have been polled, the PC may generate one or more CF-Polls to any STAs on the polling list. While time remains in the CFP, all CF frames have been delivered, and all STAs on the polling list have been polled, the PC may send Data or Management frames to any STAs. In order to gain maximum efficiency from the CFP, and the ability to piggyback acknowledgments on successor Data frames in the opposite direction, the PC should generally use Data +CF-Poll and Data +CF- Ack +CF-Poll types for each Data frame transmitted while sufficient time for the potential response to the CF- Poll remains in the CFP. 10.4.5.3 Polling list update procedure A STA indicates its CF-Pollability using the CF-Pollable subfield of the Capability Information field of Association Request and Reassociation Request frames. NOTEâ€”A STA might perform a reassociation in order to change the PCâ€™s record of its CF-Pollability. During association, a CF-Pollable STA may request to be placed on the polling list, or to never be polled, by appropriate use of bits in the Capability Information field of the Associate Request or Reassociate Request frame, as shown in Table 9-44 (see 9.4.1.4). CF-Pollable STAs that are not on the polling list, but did not request never to be polled during their most recent association, may be dynamically placed on the polling list by the PC to handle bursts of frame transfer activity by that STA. 1341 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.5 Fragmentation The MAC may fragment and reassemble MSDUs or MMPDUs that are carried in individually addressed MPDUs. The fragmentation and defragmentation mechanisms allow for fragment retransmission. The length of each fragment shall be an equal number of octets for all fragments except the last, which may be smaller. The length of each fragment shall be an even number of octets, except for the last fragment of an MSDU or MMPDU, which may be either an even or an odd number of octets. The length of a fragment shall never be larger than dot11FragmentationThreshold unless security encapsulation is invoked for the MPDU. If security encapsulation is active for the MPDU, then the MPDU shall be expanded by the encapsulation overhead and this may result in a fragment larger than dot11FragmentationThreshold. A fragment is an MPDU, the Frame Body field of which carries all or a portion of an MSDU or MMPDU. When data are to be transmitted, the number of octets in the fragment (before processing by the security mechanism) shall be limited by dot11FragmentationThreshold and the number of octets in the MPDU that have yet to be assigned to a fragment at the instant the fragment is constructed for the first time. Once a fragment is transmitted for the first time, its frame body content and length shall be fixed until it is successfully delivered to the immediate receiving STA. A STA shall be capable of receiving fragments, containing all or part of an MSDU, of arbitrary length that is less than or equal to the maximum MSDU size as defined in 9.2.3, plus any security encapsulation overhead, plus MAC header and FCS. A STA shall be capable of receiving fragments, containing all or part of an MMPDU, of arbitrary length that is less than or equal to the minimum of â€” The maximum MMPDU size as defined in 9.3.3.2, plus any security encapsulation overhead, plus MAC header and FCS â€” Any maximum MPDU length advertised by the STA If a fragment requires retransmission, its frame body content and length shall remain fixed for the lifetime of the MSDU or MMPDU at that STA. Each fragment shall contain a Sequence Control field, which comprises a sequence number and fragment number. When a STA is transmitting an MSDU or MMPDU, the sequence number shall remain the same for all fragments of that MSDU or MMPDU. The fragments shall be sent in order of lowest fragment number to highest fragment number, where the fragment number value starts at 0, and increases by 1 for each successive fragment. The Frame Control field also contains a bit, the More Fragments bit, that is equal to 0 to indicate the last (or only) fragment of the MSDU or MMPDU. The source STA shall maintain a transmit MSDU timer for each MSDU being transmitted. The attribute dot11MaxTransmitMSDULifetime specifies the maximum amount of time allowed to transmit an MSDU. The timer starts on the initial attempt to transmit the first fragment of the MSDU. If the timer exceeds dot11MaxTransmitMSDULifetime, then all remaining fragments are discarded by the source STA and no attempt is made to complete transmission of the MSDU. NOTEâ€”A STA might interleave fragments of MSDUs with different TIDs sent to the same receiver, subject to any constraint caused by the number of replay counters. 10.6 Defragmentation Each fragment contains information to allow the complete MSDU or MMPDU to be reassembled from its constituent fragments. The header of each fragment contains the following information that is used by the destination STA to reassemble the MSDU or MMPDU: â€” Frame type â€” Address of the sender, obtained from the Address 2 field 1342 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” Destination address â€” Sequence Control field: This field allows the destination STA to check that all incoming fragments belong to the same MSDU or MMPDU, and the sequence in which the fragments should be reassembled. The sequence number within the Sequence Control field remains the same for all fragments of an MSDU or MMPDU, while the fragment number within the Sequence Control field increments for each fragment. â€” Traffic identifier, for frames with a QoS Control field. â€” More Fragments indicator: Indicates to the destination STA that this is not the last fragment of the MSDU or MMPDU. Only the last or sole fragment of the MSDU or MMPDU shall have this bit set to 0. All other fragments of the MSDU or MMPDU shall have this bit set to 1. The destination STA shall reconstruct the MSDU or MMPDU by combining the fragments in order of fragment number subfield of the Sequence Control field. If security encapsulation has been applied to the fragment, it shall be deencapsulated and decrypted before the fragment is used for defragmentation of the MSDU or MMPDU. If the fragment with the More Fragments bit equal to 0 has not yet been received, then the destination STA knows that the MSDU or MMPDU is not yet complete. As soon as the STA receives the fragment with the More Fragments bit equal to 0, the STA knows that no more fragments may be received for the MSDU or MMPDU. A STA shall support the concurrent reception of fragments of at least three MSDUs or MMPDUs. A STA should support the concurrent reception of fragments of at least one MSDU per access category. An AP should support the concurrent reception of at least one MSDU per access category per associated STA. Note that a STA receiving more than three fragmented MSDUs or MMPDUs concurrently might experience a significant increase in the number of frames discarded. NOTEâ€”The three MSDUs or MMPDUs might be from different peers (e.g., in an IBSS or MBSS). The destination STA shall maintain a Receive Timer for each MSDU or MMPDU being received, for a minimum of three MSDUs or MMPDUs. The STA may implement additional timers to be able to receive additional concurrent MSDUs or MMPDUs. The receiving STA shall discard all fragments that are part of an MSDU or MMPDU for which a timer is not maintained. There is also dot11MaxReceiveLifetime, that specifies the maximum amount of time allowed to receive an MSDU. The receive MSDU or MMPDU timer starts on the reception of the first fragment of the MSDU or MMPDU. If the receive MSDU timer exceeds dot11MaxReceiveLifetime, then all received fragments of this MSDU or MMPDU are discarded by the destination STA. If additional fragments of an individually addressed MSDU or MMPDU are received after its dot11MaxReceiveLifetime is exceeded, those fragments shall be acknowledged and discarded. To properly reassemble MPDUs into an MSDU or MMPDU, a destination STA shall discard any duplicated fragments received. A STA shall discard duplicate fragments as described in 10.3.2.11. However, an acknowledgment shall be sent in response to a duplicate fragment of an individually addressed MSDU or MMPDU. 10.7 Multirate support 10.7.1 Overview Some PHYs have multiple data transfer rate capabilities that allow implementations to perform dynamic rate switching with the objective of improving performance. The algorithm for performing rate switching is beyond the scope of this standard, but in order to provide coexistence and interoperability on multirate-capable PHYs, this standard defines a set of rules to be followed by all STAs. 1343 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Only the data transfer rates of the mandatory rate set of the attached PHY are guaranteed to be supported when a STA for which dot11OCBActivated is true transmits a Management or Data frame. A higher layer protocol entity within a STA in which dot11OCBActivated is true might negotiate a rate outside the mandatory rate set. A STA that transmits a frame shall select a rate defined by the rules for determining the rates of transmission of protection frames in 10.26 when the following conditions apply: â€” The STAâ€™s protection mechanism for non-ERP receivers is enabled. â€” The frame is a protection mechanism frame. â€” The frame initiates an exchange. Otherwise, a non-DMG STA shall transmit the frame using a rate that is in accordance with rules defined in 10.7.5 and 10.7.6. A DMG STA shall transmit the frame using a rate that is in accordance with rules defined in 10.7.7. For specific PHYs, the value of the Duration/ID field is determined using the PLME-TXTIME.request primitive and the PLME-TXTIME.confirm primitive. These specific PHYs are defined in: â€” Clause 16 for HR/DSSS â€” Clause 17 for OFDM â€” Clause 18 for ERP â€” Clause 19 for HT â€” Clause 20 for DMG â€” Clause 21 for VHT â€” Clause 22 for TVHT The two PLME-TXTIME primitives are defined in the respective PHY specifications: â€” 16.3.4 for HR TXTIME calculation â€” 17.4.3 for OFDM TXTIME calculation â€” 18.5.3.2 for ERP-OFDM TXTIME calculation â€” 19.4.3 for HT TXTIME calculation â€” 20.12.3 for DMG PLME TXTIME calculation â€” 21.4.3 for VHT PLME TXTIME calculation â€” 22.4.3 for TVHT PLME TXTIME calculation The Duration/ID field in a frame transmitted by a QoS STA may cover multiple frames and might involve using the PLME-TXTIME.request primitive several times. 10.7.2 Basic HT-MCS Set field An AP that transmits a frame containing an HT Operation element with either the Dual Beacon field or the Dual CTS Protection field equal to 1 shall include at least one MCS that has only one spatial stream in the Basic HT-MCS Set field of the HT Operation element of that frame. 10.7.3 Basic STBC MCS The basic STBC MCS has the value null when any of the following conditions is true: â€” The Dual Beacon field in the HT Operation element is equal to 0, and the Dual CTS Protection field in the HT Operation element is equal to 0. â€” No HT Operation element is present in the Association Response frame received from the current AP. 1344 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” The Basic HT-MCS Set field of the HT Operation parameter of the MLME-START.request primitive or Basic HT-MCS Set field of the HT Operation parameter of the SelectedBSS parameter of the MLME-JOIN.request primitive is empty or does not exist. â€” The lowest MCS of the Basic HT-MCS Set field of the HT Operation parameter of the MLME- START.request primitive or Basic HT-MCS Set field of the HT Operation parameter of the SelectedBSS parameter of the MLME-JOIN.request primitive has NSS value greater than 1 (the mapping of MCS to NSS is PHY dependent, for the HT PHY see 19.5). If none of the above conditions is true, then the basic STBC MCS is the lowest MCS index of the Basic HT- MCS Set field of the HT Operation parameter of the MLME-START.request primitive or Basic HT-MCS Set field of the HT Operation parameter of the SelectedBSS parameter of the MLME-JOIN.request primitive. When an MCS from the basic STBC MCS is required in 10.7.5 and 10.7.6 but the basic STBC MCS has the value null, the STA shall select a mandatory MCS of the attached PHY. 10.7.4 Basic rate set, basic HT-MCS set, and basic VHT-MCS and NSS set for mesh STA A mesh STA shall not establish a mesh peering with a mesh STA using a different BSSBasicRateSet (see 14.2.7 and 14.2.8). The SME of a Mesh STA should use the mandatory PHY rates as the default BSSBasicRateSet in the MLME-START.request primitive to reduce the risk that a candidate peer mesh STA utilizes a different BSSBasicRateSet. If the mesh STA is also an HT STA, it should adopt the mandatory HT MCSs as the default basic HT-MCS set. If the mesh STA is also a VHT STA, it should adopt tuples formed from the mandatory VHT-MCSs and NSS = 1 as the default basic VHT-MCS and NSS set (see 11.40.7). 10.7.5 Rate selection for Data and Management frames 10.7.5.1 Rate selection for non-STBC Beacon and non-STBC PSMP frames If the BSSBasicRateSet parameter is not empty, a non-STBC PSMP frame or a non-STBC Beacon frame shall be transmitted in a non-HT PPDU using one of the rates included in the BSSBasicRateSet parameter. If the BSSBasicRateSet parameter is empty, the frame shall be transmitted in a non-HT PPDU using one of the mandatory PHY rates. 10.7.5.2 Rate selection for STBC group addressed Data and Management frames When a STA has dot11TxSTBCOptionActivated true, it shall use the basic STBC MCS when it transmits an STBC Beacon frame or when it transmits a group addressed Data or Management frame that is an STBC frame. 10.7.5.3 Rate selection for other group addressed Data and Management frames This subclause describes the rate selection rules for group addressed Data and Management frames, excluding the following: â€” Non-STBC Beacon and non-STBC PSMP frames â€” STBC group addressed Data and Management frames â€” Data frames located in an FMS stream (see 11.24.8) â€” Group addressed frames transmitted to the GCR concealment address (see 11.24.16.3.5) 1345 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If the BSSBasicRateSet parameter is not empty, a Data or Management frame (excluding the frames listed above) with a group address in the Address 1 field shall be transmitted in a non-HT PPDU using one of the rates included in the BSSBasicRateSet parameter or the rate chosen by the AP, described in 11.24.8, if the Data frames are part of an FMS stream. If the BSSBasicRateSet parameter is empty and the Basic HT-MCS Set field of the HT Operation parameter of the MLME-START.request primitive or Basic HT-MCS Set field of the HT Operation parameter of the SelectedBSS parameter of the MLME-JOIN.request primitive is not empty, the frame shall be transmitted in an HT PPDU using one of the MCSs included in the Basic HT-MCS Set field of the HT Operation parameter of the MLME-START.request primitive or Basic HT-MCS Set field of the HT Operation parameter of the SelectedBSS parameter of the MLME-JOIN.request primitive. If the BSSBasicRateSet parameter is empty and the Basic HT-MCS Set field of the HT Operation parameter of the MLME-START.request primitive or Basic HT-MCS Set field of the HT Operation parameter of the SelectedBSS parameter of the MLME-JOIN.request primitive is empty and the basic VHT-MCS and NSS set is not empty, the frame shall be transmitted in a VHT PPDU using one of the tuples included in the basic VHT-MCS and NSS set. If the BSSBasicRateSet parameter, the Basic HT-MCS Set field of the HT Operation parameter of the MLME-START.request primitive or Basic HT-MCS Set field of the HT Operation parameter of the SelectedBSS parameter of the MLME-JOIN.request primitive, and the basic VHT-MCS and NSS set are empty (e.g., a scanning STA that is not yet associated with a BSS), the frame shall be transmitted in a non-HT PPDU using one of the mandatory PHY rates. 10.7.5.4 Rate selection for polling frames A Data frame of a subtype that includes CF-Poll that does not also include CF-Ack and that is sent in the CP shall be transmitted at a rate selected as follows: a) If an initial exchange has already established protection and the Duration/ID field in the frame establishing protection covers the entire TXOP, the rate or MCS is selected according to the rules in 10.7.5.7. b) Otherwise, the Data frame shall be transmitted at a rate or MCS as defined in 10.7.5.3, treating the frame as though it has a group address in the Address 1 field, solely for the purpose of determining the appropriate rate or MCS. 10.7.5.5 Rate selection for +CF-Ack frames For a frame of type (QoS) Data +CF-Ack, (QoS) Data +CF-Poll+CFAck, or (QoS) CF-Poll +CF-Ack, the rate or MCS and TXVECTOR parameter CH_BANDWIDTH used to transmit the frame shall be chosen from among those supported by both the addressed recipient STA and the STA to which the Ack frame is intended. 10.7.5.6 Rate selection for Data frames sent within an FMS stream Data frames sent within an FMS stream are sent at a rate negotiated during the establishment of the FMS stream. See 11.24.8. 10.7.5.7 Rate selection for other individually addressed Data and Management frames A Data or Management frame not identified in 10.7.5.1 through 10.7.5.6 shall be sent using any data rate, MCS, or tuple subject to the following constraints: â€” A STA shall not transmit a frame using a rate or MCS that is not supported by the receiver STA or STAs, as reported in any Supported Rates and BSS Membership Selectors element, Extended 1346 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Supported Rates and BSS Membership Selectors element, or Supported MCS Set field in Management frames transmitted by the receiver STA. â€” A STA shall not transmit a frame using a tuple that is not supported by the receiver STA, as reported in any Supported VHT-MCS and NSS Set field in Management frames transmitted by the receiver STA. â€” If at least one Operating Mode field with the Rx NSS Type subfield equal to 0 was received from the receiver STA: â€” A STA shall not transmit a frame with the number of spatial streams greater than that indicated in the Rx NSS subfield in the most recently received Operating Mode field with the Rx NSS Type subfield equal to 0 from the receiver STA. â€” If at least one Operating Mode field with the Rx NSS Type subfield equal to 1 was received from the receiver STA: â€” A STA shall not transmit an SU PPDU frame using a beamforming steering matrix with the number of spatial streams greater than that indicated in the Rx NSS subfield in the most recently received Operating Mode field with the Rx NSS Type subfield equal to 1 from the receiver STA if the beamforming steering matrix was derived from a VHT Compressed Beamforming report with Feedback Type subfield indicating MU in the VHT Compressed Beamforming frame(s). â€” A STA shall not transmit a frame using a value for the CH_BANDWIDTH parameter of the TXVECTOR that is not supported by the receiver STA, as reported in any HT Capabilities element or VHT Capabilities element received from the intended receiver. â€” An HT STA that is a member of a BSS and that is not a VHT STA shall not transmit a frame using a value for the CH_BANDWIDTH parameter of the TXVECTOR that is not permitted for use in the BSS, as reported in the most recently received HT Operation element, with the exception transmissions on an off-channel TDLS direct link, which follow the rules described in 11.23.6.2 and 11.23.6.3. â€” A VHT STA that is a member of a BSS shall not transmit a frame using a value for the CH_BANDWIDTH parameter of the TXVECTOR that is not permitted for use in the BSS, as reported in the most recently received VHT Operation element with the following exceptions: â€” Transmissions on an off-channel TDLS direct link follow the rules described in 11.23.6.2 and 11.23.6.3. â€” Transmissions by a VHT STA on a TDLS link follow the rules described in 11.23.1 and 11.23.6.5. â€” If at least one Operating Mode field with the Rx NSS Type subfield equal to 0 was received from the receiver STA: â€” A STA shall not transmit a frame using a value for the TXVECTOR parameter CH_BANDWIDTH that is not supported by the receiver STA as reported in the most recently received Operating Mode field with the Rx NSS Type subfield equal to 0 from the receiver STA. When the operational rate set of the receiving STA or STAs is not known, the transmitting STA shall transmit using a rate in the BSSBasicRateSet parameter, or an MCS in the Basic HT-MCS Set field of the HT Operation parameter of the MLME-START.request primitive or Basic HT-MCS Set field of the HT Operation parameter of the SelectedBSS parameter of the MLME-JOIN.request primitive, or a tuple in the basic VHT-MCS and NSS set, or a rate from the mandatory rate set of the attached PHY if the BSSBasicRateSet, the Basic HT-MCS Set field of the HT Operation parameter of the MLME- START.request primitive or Basic HT-MCS Set field of the HT Operation parameter of the SelectedBSS parameter of the MLME-JOIN.request primitive, and the basic VHT-MCS and NSS set are empty. The rules in this subclause also apply to A-MPDUs that aggregate MPDUs with the Type subfield equal to Data or Management with any other types of MPDU. 1347 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.7.6 Rate selection for Control frames 10.7.6.1 General rules for rate selection for Control frames Control frames carried in an A-MPDU that does not contain a VHT single MPDU shall be sent at a rate selected from the rules defined in 10.7.5.7. NOTEâ€”The rules defined in 10.7.6.2 through 10.7.6.5 apply only to Control frames not carried in an A-MPDU that does not contain a VHT single MPDU. The following rules determine whether a Control frame is carried in a non-HT, HT or VHT PPDU: a) A Control frame shall be carried in an HT PPDU when the Control frame contains an L-SIG duration value (see 10.26.5). b) A control response frame shall be carried in an HT PPDU when the Control frame is a response to a frame that meets any of the following conditions: 1) The frame eliciting the response included an HT variant HT Control field with the TRQ field equal to 1 and the HT NDP Announcement subfield equal to 0, and this responder set the Implicit Transmit Beamforming Receiving Capable field to 1 in its last transmitted HT Capabilities element; or 2) The frame eliciting the response was an RTS frame carried in an HT PPDU; or 3) The frame eliciting the response was an STBC frame, and the Dual CTS Protection field was equal to 1 in the last HT Operation element received from its AP or transmitted by the STA (see 10.3.2.8). c) A Control frame may be carried in an HT PPDU when the Control frame meets any of the following conditions: 1) The Control frame contains an HT variant HT Control field with the MRQ subfield equal to 1, or 2) The Control frame contains an HT variant HT Control field with the TRQ field equal to 1. d) A Control frame may be carried in a VHT PPDU when the Control frame contains an HT Control field. e) A Control frame shall be carried in an HT PPDU or a VHT PPDU when the Control frame is sent using an STBC frame. f) A control response frame shall be carried in a VHT PPDU if the eliciting frame was an RTS frame carried in a VHT PPDU that contains an HT Control field with MRQ subfield equal to 1. Otherwise, the Control frame shall be carried in a non-HT PPDU. The requirements specified in 10.30, 10.31.2, and 10.32 further constrain the choice of non-HT, HT, or VHT PPDU. If an Operating Mode field has been received from the intended receiver STA, the following constraints also apply: â€” If at least one Operating Mode field with the Rx NSS Type subfield equal to 0 was received from the receiver STA: â€” A STA shall not transmit a frame with the number of spatial streams greater than that indicated in the Rx NSS subfield in the most recently received Operating Mode field with the Rx NSS Type subfield equal to 0 from the receiver STA. â€” If at least one Operating Mode field with the Rx NSS Type subfield equal to 1 was received from the receiver STA: â€” A STA shall not transmit an SU PPDU frame using a beamforming steering matrix with the number of spatial streams greater than that indicated in the Rx NSS subfield in the most recently received Operating Mode field with the Rx NSS Type subfield equal to 1 from the receiver STA if the beamforming steering matrix was derived from a VHT Compressed Beamforming report with Feedback Type subfield indicating MU in the VHT Compressed Beamforming frame(s). 1348 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Selection of channel width is defined in 10.7.6.6. A control response frame is a Control frame that is transmitted as a response to the reception of a frame a SIFS after the PPDU containing the frame that elicited the response, e.g., a CTS frame in response to an RTS frame reception, an Ack frame in response to a Data frame reception, a BlockAck frame in response to a BlockAckReq frame reception. In some situations, the transmission of a Control frame is not a control response transmission, such as when a CTS frame is used to initiate a TXOP. 10.7.6.2 Rate selection for Control frames that initiate a TXOP This subclause describes the rate selection rules for Control frames that initiate a TXOP and that are either a VHT single MPDU or not carried in an A-MPDU. If a Control frame other than a Basic BlockAckReq or Basic BlockAck frame is carried in a non-HT PPDU, the transmitting STA shall transmit the frame using one of the rates in the BSSBasicRateSet parameter or a rate from the mandatory rate set of the attached PHY if the BSSBasicRateSet is empty. If a Basic BlockAckReq or Basic BlockAck frame is carried in a non-HT PPDU, the transmitting STA shall transmit the frame using a rate supported by the receiver STA, if known (as reported in the Supported Rates and BSS Membership Selectors element and/or Extended Supported Rates and BSS Membership Selectors element in frames transmitted by that STA). If the operational rate set of the receiving STA or STAs is not known, the transmitting STA shall transmit using a rate from the BSSBasicRateSet parameter or using a rate from the mandatory rate set of the attached PHY if the BSSBasicRateSet is empty. NOTEâ€”Because of their utility in resolving contention and in establishing a NAV, most control subtype frames that initiate a frame exchange are subject to explicit limitations regarding the choice of transmission rate with the intent of ensuring maximum possible coverage and receivability of the frame. But the Basic BlockAckReq and Basic BlockAck frames are subject to fewer restrictions because their use at times mimics a typical data-Ack exchange, where no BSSBasicRateSet rate restriction exists on the Data frame. In addition, the Basic BlockAck frame is significantly larger than the other Control frames. When L-SIG TXOP protection is not used for an HT PPDU, an HT STA shall select an MCS from the Basic HT-MCS Set field of the HT Operation parameter of the MLME-START.request primitive or Basic HT- MCS Set field of the HT Operation parameter of the SelectedBSS parameter of the MLME-JOIN.request primitive when protection is required (as defined in 10.26) and shall select an MCS from the SupportedMCSSet parameter of the intended receiver when protection is not required. When L-SIG TXOP protection is used, an HT STA shall select an MCS from the SupportedMCSSet parameter of the intended receiver. When transmitting a VHT PPDU, a STA shall select a tuple from the basic VHT-MCS and NSS set when protection is required (as defined in 10.26) and shall select a tuple from the operational VHT-MCS and NSS set parameter of the intended receiver when protection is not required. 10.7.6.3 Rate selection for CF-End frames If not operating during the 40 MHz phase of PCO, a STA that transmits a CF-End frame that is not at the end of a TXOP that was obtained through the use of the dual CTS mechanism shall transmit the frame using a rate in BSSBasicRateSet or from the mandatory rate set of the attached PHY if the BSSBasicRateSet is empty. If operating during the 40 MHz phase of PCO, a STA that transmits a CF-End frame that is not at the end of a TXOP that was obtained through the use of the dual CTS mechanism shall transmit the frame using an MCS from the Basic HT-MCS Set field of the HT Operation parameter of the MLME-START.request primitive or Basic HT-MCS Set field of the HT Operation parameter of the SelectedBSS parameter of the MLME- JOIN.request primitive. 1349 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A STA that transmits a CF-End frame at the end of a TXOP that was obtained by a non-AP STA through the use of the dual CTS mechanism shall transmit the CF-End frame with the same value for the TXVECTOR parameter STBC, TXVECTOR parameter MCS (if present), and TXVECTOR parameter RATE as was used for the transmission of the matching Control frame at the beginning of the TXOP. The matching Control frame is defined as follows: â€” For the first CF-End frame transmitted in the TXOP, the matching Control frame is the first RTS frame transmitted in the TXOP. â€” For the second CF-End frame transmitted in the TXOP, the matching Control frame is the first CTS frame that follows the first RTS frame transmitted in the TXOP. â€” For the third CF-End frame transmitted in the TXOP, the matching Control frame is the second CTS frame that follows the first RTS frame transmitted in the TXOP. A STA that transmits a CF-End frame at the end of a TXOP that was obtained by an AP through the use of the dual CTS mechanism shall transmit the CF-End frame with the same value for the TXVECTOR parameter STBC, TXVECTOR parameter MCS (if present), and TXVECTOR parameter RATE as was used for the transmission of the matching Control frame at the beginning of the TXOP. The matching Control frame is defined as follows: â€” For the first CF-End frame transmitted in the TXOP, the matching Control frame is the first CTS-to- self frame transmitted in the TXOP. â€” For the second CF-End frame transmitted in the TXOP, the matching Control frame is the first RTS transmitted in the TXOP. 10.7.6.4 Rate selection for Control frames that are not control response frames This subclause describes the rate selection rules for Control frames that are not control response frames, are not the frame that initiates a TXOP, are not the frame that terminates a TXOP, and are either a VHT single MPDU or not carried in an A-MPDU. A frame other than a BlockAckReq or BlockAck that is carried in a non-HT PPDU shall be transmitted by the STA using a rate no higher than the highest rate in the BSSBasicRateSet parameter that is less than or equal to the rate or non-HT reference rate (see 10.7.10) of the previously transmitted frame that was directed to the same receiving STA. If no rate in the BSSBasicRateSet parameter meets these conditions, the Control frame shall be transmitted at a rate no higher than the highest mandatory rate of the attached PHY that is less than or equal to the rate or non-HT reference rate (see 10.7.10) of the previously transmitted frame that was directed to the same receiving STA. A BlockAckReq or BlockAck frame that is carried in a non-HT PPDU shall be transmitted by the STA using a rate supported by the receiver STA, as reported in the Supported Rates and BSS Membership Selectors element and/or Extended Supported Rates and BSS Membership Selectors element in frames transmitted by that STA. When the operational rate set of the receiving STA or STAs is not known, the transmitting STA shall transmit using a rate from the BSSBasicRateSet parameter or from the mandatory rate set of the attached PHY if the BSSBasicRateSet is empty. A frame that is carried in an HT PPDU shall be transmitted by the STA using an MCS supported by the receiver STA, as reported in the Supported MCS Set field in the HT Capabilities element received from that STA. When the supported MCS set of the receiving STA or STAs is not known, the transmitting STA shall transmit using an MCS in the Basic HT-MCS Set field of the HT Operation parameter of the MLME- START.request primitive or Basic HT-MCS Set field of the HT Operation parameter of the SelectedBSS parameter of the MLME-JOIN.request primitive. A frame that is carried in a VHT PPDU shall be transmitted by the STA using a tuple supported by the receiver STA. A tuple is supported if reported as such in the Supported 1350 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications VHT-MCS and NSS Set field in the VHT Capabilities element received from that STA. When the Supported VHT-MCS and NSS set of the receiving STA or STAs is not known, the transmitting STA shall transmit using a tuple in the basic VHT-MCS and NSS set. 10.7.6.5 Rate selection for control response frames 10.7.6.5.1 Introduction Subclauses 10.7.6.5.2 through 10.7.6.5.5 describe the rate selection rules for control response frames that are either a VHT single MPDU or not carried in an A-MPDU. 10.7.6.5.2 Selection of a rate or MCS To allow the transmitting STA to calculate the contents of the Duration/ID field, a STA responding to a received frame transmits its control response frame at a primary rate, or at an alternate rate, or at an MCS, as specified by the following rules: â€” If a CTS or Ack frame is carried in a non-HT PPDU, the primary rate is defined to be the highest rate in the BSSBasicRateSet parameter that is less than or equal to the rate (or non-HT reference rate; see 10.7.10) of the previous frame. If no rate in the BSSBasicRateSet parameter meets these conditions, the primary rate is defined to be the highest mandatory rate of the attached PHY that is less than or equal to the rate (or non-HT reference rate; see 10.7.10) of the previous frame. The STA may select an alternate rate according to the rules in 10.7.6.5.4. The STA shall transmit the non-HT PPDU CTS or Ack frame at either the primary rate or the alternate rate, if one exists. â€” If a BlockAck frame is sent as an immediate response to either an implicit BlockAck request or to a BlockAckReq frame that was carried in an HT or VHT PPDU and the BlockAck frame is carried in a non-HT PPDU, the primary rate is defined to be the highest rate in the BSSBasicRateSet parameter that is less than or equal to the rate (or non-HT reference rate; see 10.7.10) of the previous frame. If no rate in the BSSBasicRateSet parameter meets these conditions, the primary rate is defined to be the highest mandatory rate of the attached PHY that is less than or equal to the rate (or non-HT reference rate; see 10.7.10) of the previous frame. The STA may select an alternate rate according to the rules in 10.7.6.5.4. The STA shall transmit the non-HT PPDU BlockAck frame at either the primary rate or the alternate rate, if one exists. â€” If a Basic BlockAck frame is sent as an immediate response to a BlockAckReq frame that was carried in a non-HT PPDU and the Basic BlockAck frame is carried in a non-HT PPDU, the primary rate is defined to be the same rate and modulation class as the BlockAckReq frame, and the STA shall transmit the Basic BlockAck frame at the primary rate. â€” If a Compressed BlockAck frame is sent as an immediate response to a BlockAckReq frame that was carried in a non-HT PPDU and the Compressed BlockAck frame is carried in a non-HT PPDU, the primary rate is defined to be the highest rate in the BSSBasicRateSet parameter that is less than or equal to the rate (or non-HT reference rate; see 10.7.10) of the previous frame. If no rate in the BSSBasicRateSet parameter meets these conditions, the primary rate is defined to be the highest mandatory rate of the attached PHY that is less than or equal to the rate (or non-HT reference rate; see 10.7.10) of the previous frame. The STA may select an alternate rate according to the rules in 10.7.6.5.4. The STA shall transmit the non-HT PPDU Compressed BlockAck frame at either the primary rate or the alternate rate, if one exists. â€” If the control response frame is carried in an HT or VHT PPDU, then it is transmitted using an MCS or tuple as determined by the procedure defined in 10.7.6.5.3. The modulation class of the control response frame shall be selected according to the following rules: â€” If the received frame is of a modulation class other than HT or VHT and the control response frame is carried in a non-HT PPDU, the control response frame shall be transmitted using the same 1351 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications modulation class as the received frame. In addition, the control response frame shall be sent using the same value for the TXVECTOR parameter PREAMBLE_TYPE as the received frame. â€” If the received frame is of the modulation class HT or VHT and the control response frame is carried in a non-HT PPDU, the control response frame shall be transmitted using one of the ERP-OFDM or OFDM modulation classes. â€” If the control response frame is carried in an HT PPDU, the modulation class shall be HT. â€” If the control response frame is carried in a VHT PPDU, the modulation class shall be VHT. The selection of the value for the channel width (CH_BANDWIDTH parameter of the TXVECTOR) of the response transmission is defined in 10.7.6.6. 10.7.6.5.3 Control response frame MCS computation If a control response frame is to be transmitted within an HT or VHT PPDU, the channel width (CH_BANDWIDTH parameter of the TXVECTOR) shall be selected first according to 10.7.6.6, and then the MCS or tuple shall be selected from a set of MCSs and tuples called the CandidateMCSSet as described in this subclause. If the frame eliciting the response was transmitted by an HT STA that is not a VHT STA, the Rx Supported MCS Set is determined from the Supported MCS Set field in the HT Capabilities element received from the STA as follows: â€” If a bit in the Rx MCS Bitmask subfield is equal to 0, the corresponding MCS is not supported. â€” If a bit in the Rx MCS Bitmask subfield is equal to 1 and the integer part of the data rate (expressed in megabits per second) of the corresponding MCS is less than or equal to the rate represented by the Rx Highest Supported Data Rate subfield, then the MCS is supported by the STA on receive. If the Rx Highest Supported Data Rate subfield is equal to 0 and a bit in the Rx MCS Bitmask is equal to 1, then the corresponding MCS is supported by the STA on receive. If the frame eliciting the response was transmitted by a VHT STA, the Rx Supported MCS Set is determined for VHT PPDUs as described in 10.7.12 and for HT PPDUs from the Supported MCS Set field in the HT Capabilities element received from the STA as follows: â€” If a bit in the Rx MCS Bitmask subfield is equal to 0, the corresponding MCS is not supported. â€” If a bit in the Rx MCS Bitmask subfield is equal to 1 and the integer part of the data rate (expressed in megabits per second) of the corresponding MCS is less than or equal to the rate represented by the Rx Highest Supported Data Rate subfield, then the MCS is supported by the STA on receive. If the Rx Highest Supported Data Rate subfield is equal to 0 and a bit in the Rx MCS Bitmask is equal to 1, then the corresponding MCS is supported by the STA on receive. The CandidateMCSSet is determined using the following rules: â€” If the frame eliciting the response was an STBC frame and the Dual CTS Protection bit is equal to 1, the CandidateMCSSet shall contain only the basic STBC MCS. â€” If the frame eliciting the response had an L-SIG duration value (see 10.26.5) and initiates a TXOP, the CandidateMCSSet is the MCS Set consisting of the intersection of the Rx Supported MCS Set of the STA that sent the frame that is eliciting the response and the set of MCSs that the responding STA is capable of transmitting. â€” If none of the above conditions is true, the CandidateMCSSet is the union of the Basic HT-MCS Set field of the HT Operation parameter of the MLME-START.request primitive or Basic HT-MCS Set field of the HT Operation parameter of the SelectedBSS parameter of the MLME-JOIN.request primitive and the basic VHT-MCS and NSS set. If the frame eliciting the response was an RTS frame carried in a VHT PPDU, then the CandidateMCSSet may additionally include the tuple with the same MCS and number of spatial streams as the VHT PPDU. If the 1352 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications combined Basic HT-MCS Set field of the HT Operation parameter of the MLME-START.request primitive or Basic HT-MCS Set field of the HT Operation parameter of the SelectedBSS parameter of the MLME-JOIN.request primitive is empty, the CandidateMCSSet shall consist of â€” The set of mandatory HT PHY MCSs if the STA eliciting the response is an HT STA that is not a VHT STA â€” The set of mandatory HT MCSs plus the set of tuples corresponding to the mandatory VHT PHY MCSs with NSS = 1 if the STA eliciting the response is a VHT STA MCS values from the CandidateMCSSet that cannot be transmitted with the selected CH_BANDWIDTH parameter value shall be eliminated from the CandidateMCSSet. The choice of a response MCS is made as follows: a) If the frame eliciting the response is within a non-HT PPDU, 1) Eliminate from the CandidateMCSSet all tuples. Eliminate all MCSs that have a data rate greater than the data rate of the received PPDU (the mapping of MCS to data rate is defined in 19.5). 2) Find the highest indexed MCS from the CandidateMCSSet. The index of this MCS is the index of the MCS that is the primary MCS for the response transmission. 3) If the CandidateMCSSet is empty, the primary MCS is the lowest indexed MCS of the mandatory MCSs. b) If the frame eliciting the response is within an HT PPDU, 1) Eliminate from the CandidateMCSSet all tuples. Eliminate all MCSs that have an index that is higher than the index of the MCS of the received frame. Also eliminate all MCSs that have a number of spatial streams greater than that indicated in the Rx NSS subfield in the most recent Operating Mode field with the Rx NSS Type subfield equal to 0 from the intended receiver STA, if at least one Operating Mode field with the Rx NSS Type subfield equal to 0 was received from the intended receiver STA. 2) Determine the highest number of spatial streams (NSS) value of the MCSs in the CandidateMCSSet that is less than or equal to the NSS value of the MCS of the received frame. Eliminate all MCSs from the CandidateMCSSet that have an NSS value that is not equal to this NSS value. The mapping from MCS to NSS is dependent on the attached PHY. For the HT PHY, see 19.5. 3) Find the highest indexed MCS of the CandidateMCSSet for which the modulation value of each stream is less than or equal to the modulation value of each stream of the MCS of the received frame and for which the coding rate is less than or equal to the coding rate of the MCS from the received frame. This MCS is the primary MCS for the response transmission. The mapping from MCS to modulation and coding rate is dependent on the attached PHY. For the HT PHY, see 19.5. For the purpose of comparing modulation values, the following sequence shows increasing modulation values: BPSK, QPSK, 16-QAM, 64-QAM. 4) If no MCS meets the condition in step 3), remove each MCS from the CandidateMCSSet that has the highest value of NSS in the CandidateMCSSet. If the resulting CandidateMCSSet is empty, then set the CandidateMCSSet to the HT PHY mandatory MCSs. Repeat step 3) using the modified CandidateMCSSet. c) If the frame eliciting the response is within a VHT PPDU, 1) Eliminate from the CandidateMCSSet all MCSs and all tuples that meet any of the following conditions: i) Have a data rate that is higher than the data rate of the tuple of the received frame using the largest possible value of CH_BANDWIDTH that is no larger than the value of CH_BANDWIDTH of the received frame 1353 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ii) Have a number of spatial streams greater than that indicated in the Rx NSS subfield in the most recent Operating Mode field with the Rx NSS Type subfield equal to 0 from the intended receiver STA, if at least one Operating Mode field with the Rx NSS Type subfield equal to 0 was received from the intended receiver STA iii) Have a number of spatial streams greater than that indicated in the Rx NSS subfield in the most recent Operating Mode field with the Rx NSS Type subfield equal to 1 from the intended receiver STA if at least one Operating Mode field with the Rx NSS Type subfield equal to 1 was received from the receiver STA and the control response frame is an SU PPDU frame with a beamforming steering matrix and the beamforming steering matrix was derived from a VHT Compressed Beamforming report with Feedback Type subfield indicating MU in the VHT Compressed Beamforming frame(s) 2) Determine the highest number of spatial streams (NSS) value of the MCSs and tuples in the CandidateMCSSet that is less than or equal to the NSS value of the received frame. Eliminate all MCSs from the CandidateMCSSet that have an NSS value that is not equal to this NSS value. The mapping from MCS to NSS is dependent on the attached PHY. For the HT PHY, see 19.5. 3) Find the highest rate MCS or tuple of the CandidateMCSSet for which the modulation value of each stream is less than or equal to the modulation value of each stream of the MCS of the received frame and for which the coding rate is less than or equal to the coding rate of the MCS from the received frame. This MCS or tuple is the primary MCS for the response transmission. The mapping from MCS or tuple to modulation and coding rate is dependent on the attached PHY. For the HT PHY, see 19.5; for the VHT PHY, see 21.5. For the purpose of comparing modulation values, the following sequence shows increasing modulation values: BPSK, QPSK, 16-QAM, 64-QAM, 256-QAM. 4) If no MCS meets the condition in step 3), remove each MCS or tuple from the CandidateMCSSet that has the highest value of NSS in the CandidateMCSSet. If the resulting CandidateMCSSet is empty, then set the CandidateMCSSet to the VHT PHY mandatory MCSs. Repeat step 3) using the modified CandidateMCSSet. Once the primary MCS or tuple has been selected, the STA may select an alternate MCS according to 10.7.6.5.4. The STA shall transmit the control response frame using either the primary MCS or the alternate MCS, if one exists. 10.7.6.5.4 Selection of an alternate rate or MCS for a control response frame An alternate rate may be selected provided that all of the following conditions are met: â€” The duration of frame at the alternate rate is the same as the duration of the frame at the primary rate determined by 10.7.6.5.2. â€” The alternate rate is in either the BSSBasicRateSet parameter or is a mandatory rate of the attached PHY. â€” The modulation class of the frame at the alternate rate is the same class as that of the primary rate selected by 10.7.6.5.2. An alternate MCS may be selected provided that both of the following conditions are met: â€” The duration of the frame at the alternate MCS is the same as the duration of the frame at the primary MCS. â€” The alternate MCS is in the CandidateMCSSet that was generated according to the procedure of 10.7.6.5.3. 1354 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.7.6.5.5 Control response frame TXVECTOR parameter restrictions A STA shall not transmit a control response frame with TXVECTOR parameter GI_TYPE set to SHORT_GI unless it is in response to a reception of a frame with the RXVECTOR parameter GI_TYPE equal to SHORT_GI. A STA shall not transmit a control response frame with TXVECTOR parameter FEC_CODING set to LDPC_CODING unless it is in response to a reception of a frame with the RXVECTOR parameter FEC_CODING equal to LDPC_CODING. A STA shall not transmit a control response frame with the TXVECTOR parameter FORMAT set to HT_GF. 10.7.6.6 Channel Width selection for Control frames The rules in this subclause, combined with the rules in 10.7.6.1, determine the format of control response frames. If a VHT STA transmits to another VHT STA a Control frame that is not an RTS frame or a CF-End frame, if that Control frame elicits a control response frame or a VHT Compressed Beamforming frame, and â€” If the Control frame is transmitted in a non-HT duplicate PPDU (channel width 40 MHz or wider), the transmitting VHT STA shall set the TA field to a bandwidth signaling TA. â€” If the Control frame is transmitted in a non-HT PPDU (channel width 20 MHz), the transmitting VHT STA may set the TA field to a bandwidth signaling TA. If the TA is a bandwidth signaling TA, the transmitting VHT STA shall set the TXVECTOR parameters CH_BANDWIDTH_IN_NON_HT and CH_BANDWIDTH to the same value. NOTE 1â€”Such Control frames are BlockAckReq frames, BlockAck frames in the context of HT-delayed Block Ack, PS-Poll frames, VHT NDP Announcement frames, and Beamforming Report Poll frames. NOTE 2â€”Control Wrapper frames follow the rules pertaining to the carried Control frame (see 10.10). Channel width selection rules for RTS frames are described in 10.3.2.6. A VHT STA that transmits a CF-End frame in a non-HT duplicate PPDU (channel width 40 MHz or wider) addressed to a VHT AP shall set the Individual/Group bit in the BSSID(TA) field to 1. A VHT STA that transmits a CF-End frame in a non-HT PPDU (channel width 20 MHz) addressed to a VHT AP may set the Individual/Group bit in the BSSID(TA) field to 1. If the Individual/Group bit in the BSSID(TA) field of the CF-End frame is set to 1, the transmitting VHT STA shall set the TXVECTOR parameters CH_BANDWIDTH_IN_NON_HT and CH_BANDWIDTH to the same value. A STA that sends a Control frame in response to a frame carried in an HT PPDU or a VHT PPDU shall set the TXVECTOR parameter CH_BANDWIDTH to indicate a channel width that is the same as the channel width indicated by the RXVECTOR parameter CH_BANDWIDTH of the frame eliciting the response. A STA that sends a Control frame in response to a frame carried in a non-HT or non-HT duplicate PPDU with a nonbandwidth signaling TA â€” Should set the TXVECTOR parameter CH_BANDWIDTH to the same value as the RXVECTOR parameter CH_BANDWIDTH for the frame eliciting the response. â€” Shall not set the TXVECTOR parameter CH_BANDWIDTH to a value greater than the RXVECTOR parameter CH_BANDWIDTH for the frame eliciting the response. 1355 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NOTEâ€”According to this rule, a STA can respond with a 20 MHz PPDU if it receives a non-HT duplicate frame but is not able to detect the channel width occupied by the frame (whether by design or because the frame was received over a channel that is narrower than the channel on which it was transmitted). A VHT STA that sends a Control frame that is in response to a non-HT or non-HT duplicate format frame with a bandwidth signaling TA and that is not a CTS shall set the channel width indicated by the TXVECTOR parameter CH_BANDWIDTH to the same value as the channel width indicated by the RXVECTOR parameter CH_BANDWIDTH_IN_NON_HT for the frame eliciting the response. The RA field of a Control frame that is not a CF-End frame and that is sent in response to a Control frame with a bandwidth signaling TA shall be set to a nonbandwidth signaling TA obtained from the TA field of the immediately previous Control frame. For the channel width selection rules for CTS sent in response to an RTS with a bandwidth signaling TA, see 10.3.2.7. A frame that is intended to provide protection is transmitted using a channel width selected by the rules defined in 10.26. An HT STA that uses a non-HT duplicate frame to establish protection of its TXOP shall send any CF-End frame using a non-HT duplicate frame except during the 40 MHz phase of PCO operation. During the 40 MHz phase of PCO operation, the rules in 11.17 apply. The TXOP holder should set the TXVECTOR parameter CH_BANDWIDTH of a CF-End frame to the maximum bandwidth allowed by the rules in 10.22.2.7. NOTEâ€”A CF-End frame transmitted by an AP a SIFS duration after receiving a CF-End frame is considered a control response frame. 10.7.6.7 Control frame TXVECTOR parameter restrictions A STA shall not transmit a Control frame that initiates a TXOP with the TXVECTOR parameter GI_TYPE set to a value of SHORT_GI. A STA shall not transmit a Control frame that initiates a TXOP with the TXVECTOR parameter FEC_CODING set to a value of LDPC_CODING. 10.7.7 Multirate support for DMG STAs 10.7.7.1 Usage of DMG Control modulation class The DMG Control modulation class has only one MCS, which is DMG MCS 0 defined in Clause 20. The DMG Beacon, SSW-Feedback, SSW-Ack, RTS, DMG CTS, DMG CTS-to-self, DMG DTS, CF-End, Grant, SPR, Poll and first BRP packet in beam refinement shall be transmitted using the DMG Control modulation class. In the case of an RXSS that was specified through the Beamforming Control field with the value of the RXSSTxRate subfield equal to 1 and the RXSSTxRate Supported field in the DMG Capabilities element of the STA performing the RXSS is 1, the first SSW frame of the RXSS shall be transmitted using the DMG Control modulation class, and the remaining frames of the RXSS shall be transmitted using MCS 1 of the DMG SC modulation class. In all other cases, the SSW frames shall be transmitted using the DMG Control modulation class. Other DMG beamforming training frames may be transmitted using the DMG Control modulation class or the DMG SC modulation class. 10.7.7.2 Rate selection rules for Control frames transmitted by DMG STAs This subclause describes the rate selection rules for Control frames transmitted by DMG STAs. The rate selection rules apply only for MCSs defined in Clause 20. 1356 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A Control frame that does not have an MCS defined in 10.7.7.1 and that is not a control response frame shall be transmitted using an MCS from the mandatory MCS set of the DMG SC modulation class or DMG Control modulation class. A STA transmitting an Ack or a BlockAck frame that is a response to a frame sent using the DMG low- power SC modulation class shall use an MCS from the DMG low-power SC Supported MCS set of the STA that transmitted the frame that elicited the response as long as (a) the selected MCS has a Data Rate that does not exceed the Data Rate of the frame that elicited the response, and (b) no other MCS satisfying condition (a) results in a shorter frame transmission time. A STA transmitting a Grant Ack frame shall use the DMG Control modulation class or any MCS from the mandatory MCS set of the DMG SC modulation class. A STA transmitting an Ack or a BlockAck frame that is a response to a frame sent using the DMG Control modulation class shall use the DMG Control modulation class. A STA transmitting an Ack frame or a BlockAck frame in response to a frame sent using the DMG SC modulation class or DMG OFDM modulation class shall use an MCS from the mandatory MCS set of the DMG SC modulation class as long as (a) the selected MCS has a Data Rate that does not exceed the Data Rate of the frame that elicited the response, and (b) no other MCS satisfying condition (a) results in a shorter frame transmission time. NOTEâ€”A control response frame is a Control frame that is transmitted within an MPDU as a response to a reception SIFS after the PPDU containing the frame that elicits the response, e.g., a DMG CTS frame in response to an RTS frame reception, an Ack frame in response to a Data frame reception, a BlockAck frame in response to a BlockAckReq frame reception. In some situations, the transmission of some of these Control frames is not a control response transmission, such as when a DMG CTS frame is used to initiate a TXOP. Except in an A-MPDU consisting of one of the combinations listed below, the rules in this subclause do not apply to Control frames that are contained in A-MPDUs that also include at least one MPDU with the Type subfield equal to Data or Management. In the following cases, the rate selection rules are the same as those for a standalone Ack or BlockAck frame: â€” An Ack frame and a QoS Null frame â€” A BlockAck frame and a QoS Null frame â€” A BlockAckReq frame and a QoS Null frame â€” A BlockAck frame, a BlockAckReq frame, and a QoS Null frame 10.7.7.3 Rate selection for group addressed Data and Management frames transmitted by DMG STAs This subclause describes the rate selection rules for group addressed Data and Management frames transmitted by DMG STAs. The rate selection rules apply only for MCSs defined in Clause 20. If the transmit antenna pattern of a single transmission of a group addressed frame covers more than one receiver and the supported MCS set of each of the receivers is known to the sender, then the MCS used for the transmission shall be an MCS common to the supported MCS sets of all of the receivers. If such an MCS is not known, the frame shall be transmitted using an MCS from the mandatory MCS set of the DMG control or SC mode. If the transmit antenna pattern of a single transmission of a group addressed frame covers only one receiver, the frame shall be transmitted following the rate selection rules of individually addressed frames as described in 10.7.7.4. 1357 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.7.7.4 Rate selection for individually addressed Data and Management frames transmitted by DMG STAs This subclause describes the rate selection rules for individually addressed Data and Management frames as transmitted by DMG STAs. The rate selection rules apply only for MCSs defined in Clause 20. An individually addressed Data or Management frame shall be sent using an MCS supported by the receiver STA, as reported in the maximum receive MCS subfields in the Supported MCS Set field in Management frames transmitted by the receiver STA. When the Supported MCS set of the receiving STA is not known, the transmitting STA shall transmit using an MCS from the mandatory MCS set of the DMG control or SC mode. A DMG STA shall transmit a TPA Request frame and a TPA Response frame using MCS 1. The rules in this subclause also apply to A-MPDUs that contain at least one MPDU with Type subfield equal to Control and at least one MPDU with Type subfield equal to Data or Management. 10.7.7.5 Rate selection for BRP packets The first BRP packet transmitted from the initiator to the responder after the SLS phase shall use MCS 0. The first BRP packet transmitted from the responder to the initiator after the SLS phase shall use MCS 0. A BRP packet transmitted during beam refinement at the start of a SP (as defined in 10.36.6.2) should use MCS 0, otherwise a BRP packet transmitted during beam refinement should use MCS 1. A BRP packet transmitted during beam refinement shall not use any MCS greater than MCS 12. BRP packets transmitted during the BRP setup subphase, the MID subphase, and the BC subphase shall use MCS 0. BRP packets transmitted during a BC subphase, as part of a BC subphase only training, may use MCS 0 to MCS 12. BRP packets transmitted during beam tracking may use any MCS. 10.7.8 Multiple BSSID Rate Selection If the multiple BSSID capability is supported, Beacon frames shall be transmitted using any basic rate valid for all of the BSSs supported. If no such rate exists, then Beacon frames shall be transmitted using any mandatory PHY rate for any PHY type that all BSSs have in common. 10.7.9 Modulation classes Table 10-6 defines modulation classes for the rules for response frames in 9.7. 1358 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 10-6â€”Modulation classes Condition that selects this modulation class Description of modulation Clause 15 to Clause 18 Clause 19 PHY Clause 21 PHY PHYs or Clause 20 PHY DSSS and HR/ Clause 15 or Clause 16 FORMAT is NON_HT. N/A DSSS transmission NON_HT_MODULATION is ERP-DSSS or ERP-CCK. ERP-OFDM 18.4 transmission FORMAT is NON_HT. N/A NON_HT_MODULATION is ERP-OFDM. OFDM Clause 17 transmission FORMAT is NON_HT. FORMAT is NON_HT. NON_HT_MODULATION is NON_HT_MODULATION OFDM or is OFDM NON_HT_DUP_OFDM. or NON_HT_DUP_OFDM. HT N/A FORMAT is HT_MF or FORMAT is HT_MF or HT_GF. HT_GF. DMG Control Clause 20 transmission N/A N/A and MCS is 0 DMG SC Clause 20 transmission N/A N/A and 1 MCS 12.6 DMG OFDM Clause 20 transmission N/A N/A and 13 MCS 24 DMG Low-power Clause 20 transmission N/A N/A SC and 25 MCS 31 VHT N/A N/A FORMAT is VHT. 10.7.10 Non-HT basic rate calculation This subclause defines how to convert an HT MCS or a VHT-MCS to a non-HT basic rate for the purpose of determining the rate of the response frame. It consists of two steps as follows: a) Use the modulation and coding rate determined from the HT MCS (defined in 19.5) or VHT-MCS (defined in 21.5) to locate a non-HT reference rate by lookup into Table 10-7.29 In the case of an MCS with UEQM, the modulation of stream 1 is used. b) The non-HT basic rate is the highest rate in the BSSBasicRateSet that is less than or equal to this non-HT reference rate. NOTEâ€”In a TVWS band, the non-HT reference rate is scaled as described in 22.2.4. 29 For example, if an HT PPDU transmission uses 64-QAM and coding rate of 3/4, the related non-HT reference rate is 54 Mb/s. 1359 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 10-7â€”Non-HT reference rate Coding rate Non-HT reference rate Modulation (R) (Mb/s) BPSK 1/2 6 BPSK 3/4 9 QPSK 1/2 12 QPSK 3/4 18 16-QAM 1/2 24 16-QAM 3/4 36 64-QAM 1/2 48 64-QAM 2/3 48 64-QAM 3/4 54 64-QAM 5/6 54 256-QAM 3/4 54 256-QAM 5/6 54 10.7.11 Channel Width in non-HT and non-HT duplicate PPDUs A non-VHT STA shall include neither the CH_BANDWIDTH_IN_NON_HT parameter nor the DYN_BANDWIDTH_IN_NON_HT parameter in either of the TXVECTOR or RXVECTOR for NON_HT PPDUs. A non-VHT STA shall not set the TA field to a bandwidth signaling TA. A VHT STA shall include neither the CH_BANDWIDTH_IN_NON_HT parameter nor the DYN_BANDWIDTH_IN_NON_HT parameter in the TXVECTOR of a non-HT PPDU addressed to a non-VHT STA. A VHT STA shall not set the TA field to a bandwidth signaling TA in a frame addressed to a non-VHT STA. A VHT STA that includes the DYN_BANDWIDTH_IN_NON_HT parameter in the TXVECTOR shall also include the CH_BANDWIDTH_IN_NON_HT parameter in the TXVECTOR. A VHT STA shall not include the DYN_BANDWIDTH_IN_NON_HT parameter in the TXVECTOR for transmitted frames other than RTS frames with bandwidth signaling TA and that are sent in a non-HT PPDU. A STA that transmits an RTS frame with a bandwidth signaling TA shall include the DYN_BANDWIDTH_IN_NON_HT parameter in the TXVECTOR. A VHT STA shall include both the CH_BANDWIDTH_IN_NON_HT and DYN_BANDWIDTH_IN_NON_HT parameters in the RXVECTOR if the detected PPDU format is NON_HT. A bandwidth signaling TA may be included in non-HT and non-HT duplicate PPDUs and shall not be included in other PPDUs. If the TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT is present and a control MPDU other than a CTS is being transmitted, then the TA field shall be set to a bandwidth signaling TA; otherwise, the TA field shall be set to an individual address. NOTEâ€”A CTS frame, even though it does not have a TA field, can also be transmitted with the TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT present. The TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT shall not be present in PPDUs carrying Management or Data frames. 1360 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.7.12 Rate selection constraints for VHT STAs 10.7.12.1 Rx Supported VHT-MCS and NSS Set The Rx Supported VHT-MCS and NSS Set of a first VHT STA is determined by a second VHT STA for each tuple NSS = 1, â€¦, 8 and bandwidth (20 MHz, 40 MHz, 80 MHz, and 160 MHz or 80+80 MHz) from the Supported VHT-MCS and NSS Set field received from the first STA as follows: â€” If support for the VHT-MCS for NSS spatial streams at that bandwidth is mandatory (see 21.5), then the tuple at that bandwidth is supported by the first STA on receive. â€” Otherwise, if the Max VHT-MCS For n SS subfield (n = NSS) in the Rx VHT-MCS Map subfield indicates support and the Rx Highest Supported Long GI Data Rate subfield is equal to 0, then â€” the tuple at that bandwidth is supported by the first STA on receive, except that if dot11VHTExtendedNSSBWCapable of the second STA is true, the supported bandwidth values and NSS values of each tuple are updated according to Table 9-250 if no OMN has been received from the first STA, otherwise, according to Table 9-75, wherein the VHT Capabilities Information field and the Operating Mode field have been transmitted by the first STA. â€” Otherwise, if the Max VHT-MCS For n SS subfield (n = NSS) in the Rx VHT-MCS Map subfield indicates support and the data rate for long GI of the MCS for NSS spatial streams at that bandwidth (expressed as the largest integer in Mb/s that is less than or equal to the data rate) is less than or equal to the rate represented by the Rx Highest Supported Long GI Data Rate subfield, then â€” the tuple at that bandwidth is supported by the first STA on receive, except that if dot11VHTExtendedNSSBWCapable of the second STA is true, the supported bandwidth values and NSS values of each tuple are updated according to Table 9-250 if no OMN has been received from the first STA, otherwise, according to Table 9-75, wherein the VHT Capabilities Information field and the Operating Mode field have been transmitted by the first STA. â€” Otherwise, the tuple at that bandwidth is not supported by the first STA on receive. The tuples excluded by 10.7.12.3 are also eliminated from the Rx Supported VHT-MCS and NSS Set. A VHT STA shall not, unless explicitly stated otherwise, transmit a VHT PPDU unless the tuple and bandwidth used are in the Rx Supported VHT-MCS and NSS Set of the receiving STA(s). NOTE 1â€”Support for a tuple at a given bandwidth implies support for both long GI and short GI on receive, if short GI is supported at that bandwidth. NOTE 2â€”A STA can determine the expected interpretation of its Supported Channel Width Set and Channel Width and 160/80+80 BW and Extended NSS BW Support fields at a recipient by examining the VHT Extended NSS BW Capable field value in the Supported VHT-MCS and NSS Set field of the recipient. 10.7.12.2 Tx Supported VHT-MCS and NSS Set The Tx Supported VHT-MCS and NSS Set of a first VHT STA is determined by a second STA for each tuple NSS = 1, â€¦, 8 and bandwidth (20 MHz, 40 MHz, 80 MHz, and 160 MHz or 80+80 MHz) from the Supported VHT-MCS and NSS Set field received from the first STA as follows: â€” If support for the tuple at that bandwidth is mandatory (see 21.5), then the tuple at that bandwidth is supported by the first STA on transmit. â€” Otherwise, if the Max VHT-MCS for n SS subfield (n = NSS) in the Tx VHT-MCS Map subfield indicates support and the Tx Highest Supported Long GI Data Rate subfield is equal to 0, then 1361 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” the tuple at that bandwidth is supported by the first STA on transmit, except that if dot11VHTExtendedNSSBWCapable of the second STA is true, the supported bandwidth values and NSS values of each tuple are updated according to Table 9-250 if no OMN has been received from the first STA, otherwise, according to Table 9-75, wherein the VHT Capabilities Information field and the Operating Mode field have been transmitted by the first STA. â€” Otherwise, if the Max VHT-MCS for n SS subfield (n = NSS) in the Tx VHT-MCS Map subfield indicates support and the data rate for long GI of the tuple at that bandwidth (expressed as the largest integer in Mb/s that is less than or equal to the data rate) is less than or equal to the rate represented by the Tx Highest Supported Long GI Data Rate subfield, then â€” the tuple at that bandwidth is supported by the first STA on transmit, except that if dot11VHTExtendedNSSBWCapable of the second STA is true, the supported bandwidth values and NSS values of each tuple are updated according to Table 9-250 if no OMN has been received from the first STA, otherwise, according to Table 9-75, wherein the VHT Capabilities Information field and the Operating Mode field have been transmitted by the first STA. â€” Otherwise, the tuple at that bandwidth is not supported by the first STA on transmit. NOTE 1â€”In contrast to reception, support for short GI transmissions by a STA cannot be determined by other STAs. NOTE 2â€”A STA can determine the expected interpretation of its Supported Channel Width Set and Channel Width and 160/80+80 BW and Extended NSS BW Support fields at a recipient by examining the VHT Extended NSS BW Capable field value in the Supported VHT-MCS and NSS Set field of the recipient. 10.7.12.3 Additional rate selection constraints for VHT PPDUs The following apply for a STA that transmits a VHT PPDU with a number of spatial streams (NSS) less than or equal to 4: â€” If the channel width of the PPDU is equal to CBW20 or CBW40, then the STA should not use a tuple if the VHT-MCS is equal to 0, 1, 2, or 3 and the HT MCS with value VHT-MCS + 8 (NSS â€“ 1) is marked as unsupported in the Rx MCS bitmask of the HT Capabilities element of the receiver STA. â€” If the channel width of the PPDU is equal to CBW80, CBW160, or CBW80+80, then the STA should not use a tuple if the VHT-MCS is equal to 0 or 1 and both the HT MCS values 2 VHT-MCS + 8 (NSS â€“ 1) and 2 (VHT-MCS + 1) + 8 (NSS â€“ 1) are marked as unsupported in the Rx MCS bitmask of the HT Capabilities element of the receiver STA. An example tabulation of this behavior is given in Table 10-8. Table 10-8â€”Example of rate selection for VHT PPDUs tuples that tuples that HT MCSs that are are not used for are not used for CBW80, marked as unsupported CBW20 and CBW40 CBW160, and CBW80+80 0, 8, 16 <0, 1>, <0, 2>, <0, 3> â€” 1, 9 <1, 1>, <1, 2> â€” 10 <2, 2> â€” 3 <3, 1> â€” 1362 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 10-8â€”Example of rate selection for VHT PPDUs (continued) tuples that tuples that HT MCSs that are are not used for are not used for CBW80, marked as unsupported CBW20 and CBW40 CBW160, and CBW80+80 0, 1 <0, 1>, <1, 1> <0, 1> 2, 3 <2, 1>, <3, 1> <1, 1> 0, 1, 8, 9 <0, 1>, <1, 1>, <0, 2>, <1, 2> <0, 1>, <0, 2> 10.8 MSDU transmission restrictions To avoid reordering MSDUs between pairs of LLC entities and/or unnecessarily discarding MSDUs, the following restrictions shall be observed by any STA that is able to concurrently process multiple outstanding MSDUs for transmission. The term outstanding refers to an MPDU containing all or part of an MSDU or MMPDU for which transmission has been started, and for which delivery of the MSDU or MMPDU has not yet been completed (i.e., an acknowledgment of the final fragment has not been received and the MSDU or MMPDU has not been discarded due to retries, lifetime, or for some other reason). A STA may have any number (greater than or equal to one) of eligible MSDUs outstanding concurrently, subject to the restrictions below. A non-QoS STA shall not have more than one MSDU or MMPDU from a particular SA to a particular individual RA outstanding at a time. NOTEâ€”A simpler, more restrictive alternative to the rule in the above paragraph that might be used is that no more than one MSDU with a particular individual RA be outstanding at a time. For frames that are not sent within the context of a block ack agreement, a QoS STA shall not have more than one MSDU or A-MSDU for each TID or MMPDU from a particular SA to a particular individual RA outstanding at any time. NOTEâ€”A simpler, more restrictive alternative to the rule in the above paragraph that might be used is that no more than one MSDU or A-MSDU with any particular TID with a particular individual RA be outstanding at any time. In a STA where the optional StrictlyOrdered service class has been implemented, that STA shall not have any group addressed (multidestination) MSDU of the StrictlyOrdered service class outstanding from the SA of any other outstanding MSDU (either individual or group addressed). This is because a group addressed MSDU is implicitly addressed to a collection of peer STAs that could include any individual RA. A STA should select a value of dot11MaxTransmitMSDULifetime that is sufficiently large that the STA does not discard MSDUs or A-MSDUs due to excessive Transmit MSDU timeouts under normal operating conditions. An A-MSDU shall contain only MSDUs of a single service class and inherits that service class for the purpose of the following rules. For MSDUs or A-MSDUs belonging to the service class of QoSAck when the receiver is a QoS STA, set to Normal Ack or Implicit Block Ack Request, PSMP Ack, or Block Ack. For MSDUs or A-MSDUs belonging to the service class of QoSNoAck when the receiver is a QoS STA, the QoS Data frames that are used to send these MSDUs or A-MSDUs shall have the Ack Policy subfield in the QoS Control field set to No Ack. 1363 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.9 HT Control field operation If dot11HTControlFieldSupported is true, a STA shall set the +HTC-HT Support subfield of the HT Extended Capabilities field of the HT Capabilities element to 1 in HT Capabilities elements that it transmits. If dot11VHTControlFieldOptionImplemented is true, a STA shall set the +HTC-VHT Support subfield of the VHT Capabilities Information field of the VHT Capabilities element to 1 in VHT Capabilities elements that it transmits. A STA in which at least one of dot11RDResponderOptionImplemented, dot11MCSFeedbackOptionImplemented, and dot11AlternateEDCAActivated is true shall set dot11HTControlFieldSupported or dot11VHTControlFieldOptionImplemented or both to true. An HT variant HT Control field shall not be present in a frame addressed to a STA unless that STA declares support for +HTC-HT in the HT Extended Capabilities field of its HT Capabilities element (see 9.4.2.56). A VHT variant HT Control field shall not be present in a frame addressed to a STA unless that STA declares support for +HTC-VHT in the VHT Capabilities Information field of its VHT Capabilities element. NOTEâ€”An HT STA that does not support +HTC (HT or VHT variant) that receives a +HTC frame addressed to another STA still performs the CRC on the actual length of the MPDU and uses the Duration/ID field to update the NAV, as described in 10.3.2.4. If the HT Control field is present in an MPDU aggregated in an A-MPDU, then all MPDUs of the same frame type (i.e., having the same value of the Type subfield of the Frame Control field) aggregated in the same A-MPDU shall contain an HT Control field. The HT Control field of all MPDUs containing the HT Control field aggregated in the same A-MPDU shall be set to the same value. If the HT variant HT Control field is present in an MPDU, the DEI subfield provides information on the drop eligibility of the contents of the received MPDU. When there are insufficient resources in a STA, the STA arbitrarily discards frames in order to recover from the lack of resources. With the information from the DEI subfield, a STA may selectively drop frames with the DEI subfield set to 1 in preference to frames with the DEI subfield set to 0, if resources are insufficient. Note that this might not help in the recovery in all conditions, and the STA might still have to fall back to the arbitrary discard strategy. The mechanisms for determining whether resources are insufficient or when to discard MSDUs or A-MSDUs are beyond the scope of this standard. 10.10 Control Wrapper operation A STA supporting the HT Control field that receives a Control Wrapper frame shall process it as though it received a frame of the subtype of the wrapped frame. 10.11 MSDU processing A STA can use the U-PID element transmitted in ADDTS Request, DMG ADDTS Request, ADDTS Response and DMG ADDTS Response frames to indicate the upper layer protocol responsible for handling MSDUs corresponding to the TID indicated within the frame carrying the U-PID element (see 11.4.4.4). A STA that participates in a successful ADDTS exchange that included a U-PID element in the ADDTS Response or DMG ADDTS Response frame with the LLC Header Removed field equal to 1 shall strip the number of octets in the LLC Header Copy field of the U-PID element from the start of an MSDU (received in an MA-UNITDATA.request.primitive) corresponding to the TID indicated in the ADDTS exchange before transmission of the MSDU to the peer STA. The MSDU in the MA-UNITDATA.request.primitive must start with the octets specified in the LLC Header Copy field. 1364 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NOTEâ€”The STA does not verify that the MSDU does indeed start with the octets specified in the LLC Header Copy field. A STA that participates in a successful ADDTS exchange that included a U-PID element in the ADDTS Response or DMG ADDTS Response frame with the LLC Header Removed field equal to 1 and that receives from the peer STA an MSDU corresponding to the TID indicated in the ADDTS exchange shall insert the octets in the LLC Header Copy field of the U-PID element at the start of the MSDU before delivery of the MSDU (in an MA-UNITDATA.indication.primitive). NOTEâ€”If the LLC Header Removed field is equal to 0, the LLC Header Copy field in the U-PID element is ignored, except for possible implementation-dependent local optimizations. 10.12 A-MSDU operation An A-MSDU contains only MSDUs whose DA parameter values map to a single RA value (see 9.3.2.2). An A-MSDU contains only MSDUs whose SA parameter values map to a single TA value (see 9.3.2.2). For the Short A-MSDU case, an A-MSDU contains only MSDUs whose SA and DA parameter values are the same. The Short A-MSDU subframe structure is used only between a pair of STAs that communicate directly (see 9.3.2.1). The Short A-MSDU subframe structure cannot be used for frame forwarding. The constituent MSDUs of an A-MSDU shall all have the same priority parameter value from the corresponding MA-UNITDATA.request primitive. An A-MSDU shall be carried, without fragmentation, within a single QoS Data frame. The Address 1 field of an MPDU carrying an A-MSDU shall be set to an individual address or to the GCR concealment address. The channel access rules for a QoS Data frame carrying an A-MSDU are the same as a Data frame carrying an MSDU (or fragment thereof) of the same TID. The expiration of the A-MSDU lifetime timer occurs only when the lifetime timer of all of the constituent MSDUs of the A-MSDU have expired. NOTE 1â€”This rule implicitly allows an MSDU that is a constituent of an A-MSDU to potentially be transmitted after the expiration of its lifetime. NOTE 2â€”Selecting any other value for the timeout would result in loss of MSDUs. Selecting the maximum value avoids this loss of MSDUs at the cost of transmitting MSDUs that have exceeded their lifetime. The following rules apply to the transmission of an A-MSDU: â€” A non-DMG STA that has a value of false for dot11HighthroughputOptionImplemented shall not transmit an A-MSDU. â€” A non-DMG STA shall not transmit an A-MSDU to a STA from which it has not received a frame containing an HT Capabilities element. A STA shall support the reception of an A-MSDU, where the A-MSDU is carried in a QoS Data frame with Ack Policy equal to Normal Ack in the following cases: â€” By an HT STA when the A-MSDU is not aggregated within an A-MPDU â€” By a VHT STA when the A-MSDU is sent as a VHT single MPDU The use of an A-MSDU carried in a QoS Data frame under a block ack agreement is determined for each block ack agreement. A STA shall not transmit an A-MSDU within a QoS Data frame under a block ack agreement 1365 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications unless the recipient indicates support for A-MSDU by setting the A-MSDU Supported field to 1 in its BlockAck Parameter Set field of the ADDBA Response frame. A STA shall not transmit an A-MSDU to a STA if the A-MSDU length exceeds the value indicated by the Maximum A-MSDU Length field of the HT Capabilities element received from the recipient STA. A VHT STA that sets the value of the Maximum MPDU Length subfield in the VHT Capabilities Information field of the VHT Capabilities element to indicate 3895 octets shall set the Maximum A-MSDU Length in the HT Capabilities element to indicate 3839 octets. A VHT STA that sets the Maximum MPDU Length in the VHT Capabilities element to indicate 7991 octets or 11 454 octets shall set the Maximum A-MSDU Length in the HT Capabilities element to indicate 7935 octets. The length of an A-MSDU transmitted in a VHT PPDU is limited by the maximum MPDU size supported by the recipient STA (see 10.13.5). NOTE 1â€”An A-MSDU that meets the A-MSDU length limit for transmission in a VHT PPDU might exceed the A-MSDU length limit for an HT PPDU, in which case it cannot be retransmitted in an HT PPDU. NOTE 2â€”Support for A-MSDU aggregation does not affect the maximum size of MSDU transported by the MA-UNITDATA primitives. A VHT STA shall not transmit an A-MSDU that includes a number of MSDUs greater than the value indicated by the Max Number Of MSDUs In A-MSDU field in any Extended Capabilities element sent by the recipient STA. An HT STA should not transmit an A-MSDU that includes a number of MSDUs greater than the value indicated by the Max Number Of MSDUs In A-MSDU field in any Extended Capabilities element sent by the recipient STA. A DMG STA shall not transmit an A-MSDU that includes a number of Basic A-MSDU subframes greater than the value indicated by the Maximum Number Of Basic A-MSDU Subframes In A-MSDU subfield in any DMG Capabilities element sent by the recipient STA. A DMG STA shall not transmit an A-MSDU that includes a number of Short A-MSDU subframes greater than the value indicated by the Maximum Number Of Short A-MSDU Subframes In A-MSDU subfield in any DMG Capabilities element sent by the recipient STA. A DMG STA that sets the A-MSDU Subframe subfield to 1 in a DMG Attributes field of TSPEC element (9.4.2.30), which indicates Short A-MSDU subframe support, shall be capable of receiving at least 32 Short A-MSDU subframes in A-MSDU. The transmitter of frames for a TID established using a PTP TSPEC shall use an A-MSDU subframe format that is the result of the PTP TSPEC negotiation for that TID. The A-MSDU subframe format is negotiated using the PTP TSPEC (9.4.2.30): the Short A-MSDU subframe format shall not be used for frames of the corresponding TID if the A-MSDU subframe field of the PTP TSPEC element is 0 either in the ADDTS Request frame or in the ADDTS Response frame used to set up the TID. Prior to PTP TSPEC negotiation, a STA shall use the Basic A-MSDU subframe format if the STA employs MSDU aggregation. A non-PCP DMG STA in a PBSS may use the PCP of the PBSS to forward MSDUs to another non-PCP STA in the PBSS if the value of the PCP Forwarding field within the PCPâ€™s DMG Capabilities element is 1. A non-PCP DMG STA in a PBSS shall not use the PCP to forward MSDUs if the value of the PCP Forwarding field within the PCPâ€™s DMG Capabilities element is 0. To forward an MSDU via the PCP, a non-PCP STA shall encapsulate the MSDU within an individually addressed A-MSDU sent to the PCP. The DA field of the A-MSDU shall be set to the destinationâ€™s individual or group address. 1366 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.13 A-MPDU operation 10.13.1 A-MPDU contents According to its context (defined in Table 9-424), an A-MPDU shall be constrained so that it contains only MPDUs as specified in the relevant table referenced from Table 9-424. When an A-MPDU contains multiple QoS Control fields, bits 4 and 8â€“15 of these QoS Control fields shall be identical. A DMG STA that transmits an A-MPDU shall do so only in the Data Enabled Immediate Response context or the Control Response context, with contents as specified in Table 9-425 and Table 9-428, respectively. 10.13.2 A-MPDU length limit rules A STA indicates in the Maximum A-MPDU Length Exponent field in its HT Capabilities element the maximum A-MPDU length that it can receive in an HT PPDU. A STA indicates in the Maximum A-MPDU Length Exponent field in its VHT Capabilities element the maximum length of the A-MPDU pre-EOF padding that it can receive in a VHT PPDU. A DMG STA indicates in the Maximum A-MPDU Length Exponent field in its DMG Capabilities element the maximum A-MPDU length that it can receive. The encoding of these fields is defined in Table 9-163 for an HT PPDU, in Table 9-249 for a VHT PPDU, and in Table 9-229 for a DMG STA. A VHT STA that sets the Maximum A-MPDU Length Exponent field in its VHT Capabilities element to a value in the range 0 to 3 shall set the Maximum A-MPDU Length Exponent in its HT Capabilities to the same value. A VHT STA that sets the Maximum A-MPDU Length Exponent field in the VHT Capabilities element to a value larger than 3 shall set the Maximum A-MPDU Length Exponent in its HT Capabilities element to 3. Using the Maximum A-MPDU Length Exponent fields in the HT Capabilities and VHT Capabilities elements, the STA establishes at association the maximum length of an A-MPDU pre-EOF padding that can be sent to it. An HT STA shall be capable of receiving A-MPDUs of length up to the value indicated by the Maximum A- MPDU Length Exponent field in its HT Capabilities element. A VHT STA shall be capable of receiving A- MPDUs where the A-MPDU pre-EOF padding length is up to the value indicated by the Maximum A-MPDU Length Exponent field in its VHT Capabilities element. A STA shall not transmit an A-MPDU in an HT PPDU that is longer than the value indicated by the Maximum A-MPDU Length Exponent field in the HT Capabilities element received from the intended receiver. MPDUs in an A-MPDU carried in an HT PPDU shall be limited to a maximum length of 4095 octets. A STA shall not transmit an A-MPDU in a VHT PPDU where the A-MPDU pre-EOF padding length is longer than the value indicated by the Maximum A-MPDU Length Exponent field in the VHT Capabilities element received from the intended receiver. A DMG STA shall not transmit an A-MPDU that is longer than the value indicated by the Maximum A-MPDU Length Exponent field in the DMG Capabilities element received from the intended receiver. 10.13.3 Minimum MPDU Start Spacing field A STA shall not start the transmission of more than one MPDU within the time limit described in the Minimum MPDU Start Spacing field declared by the intended receiver. To satisfy this requirement, the number of octets between the start of two consecutive MPDUs in an A-MPDU, measured at the PHY SAP, shall be equal to or greater than t MMSS r 8 1367 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications where t MMSS is the time (in microseconds) defined in the â€œEncodingâ€ column of Table 9-163 for an HT STA and of Table 9-229 for a DMG STA for the value of the Minimum MPDU Start Spacing field r is the value of the PHY Data Rate (in megabits per second) defined in 19.5 for HT PPDUs, in 21.5 for VHT PPDUs, and in Clause 20 for a DMG STA If necessary, in order to satisfy this requirement, a STA shall add padding between MPDUs in an A-MPDU. Any such padding shall be in the form of one or more MPDU delimiters with the MPDU Length field set to 0. QoS Null frames transmitted by DMG STAs are not subject to this spacing, i.e., no MPDU delimiters with zero length need to be inserted after the MPDU immediately preceding the QoS Null frame in an A-MPDU. 10.13.4 A-MPDU aggregation of group addressed Data frames A STA that is neither an AP nor a mesh STA shall not transmit an A-MPDU containing an MPDU with a group addressed RA. NOTE 1â€”An HT AP and an HT mesh STA can transmit an A-MPDU containing MPDUs with a group addressed RA. NOTE 2â€”As a VHT STA is an HT STA, NOTE 1 also applies to VHT APs and VHT mesh STAs. NOTE 3â€”An AP providing GCR service can transmit an A-MPDU containing MPDUs with a group addressed RA. A STA that is an AP or a mesh STA shall not transmit an A-MPDU containing group addressed MPDUs if the HT Protection field is equal to non-HT mixed mode. A DMG STA may transmit an A-MPDU containing MPDUs with a group addressed RA. When a STA transmits a PPDU containing at least one A-MPDU that contains MPDUs with a group addressed RA, the following shall apply: â€” If the PPDU is an HT PPDU transmitted by an AP, the maximum A-MPDU length exponent value is the minimum value in the Maximum A-MPDU Length Exponent subfield of the A-MPDU Parameters field of the HT Capabilities element of all HT STAs associated with the AP. â€” If the PPDU is an HT PPDU transmitted by a mesh STA, the maximum A-MPDU length exponent value is the minimum value in the Maximum A-MPDU Length Exponent subfield of the A-MPDU Parameters field of the HT Capabilities element of all peer HT mesh STAs. â€” If the PPDU is a VHT PPDU, the value of maximum A-MPDU length exponent that applies is the minimum value in the Maximum A-MPDU Length Exponent subfields of the A-MPDU Parameters fields of the VHT Capabilities elements across all VHT STAs associated with the transmitting AP or across all peer VHT mesh STAs. â€” If the PPDU is a VHT PPDU, the value of minimum MPDU start spacing that applies is the maximum value in the Minimum MPDU Start Spacing subfields of the A-MPDU Parameters fields of the HT Capabilities elements across all VHT STAs associated with the transmitting AP or across all peer VHT mesh STAs of the transmitting mesh STA. â€” If the PPDU is an HT PPDU transmitted by an AP, the minimum MPDU start spacing value that applies is the maximum value in the Minimum MPDU Start Spacing subfield of the A-MPDU Parameters field of the HT Capabilities element of all HT STAs associated with the AP. â€” If the PPDU is an HT PPDU transmitted by a mesh STA, the minimum MPDU start spacing value that applies is the maximum value in the Minimum MPDU Start Spacing subfield of the A-MPDU Parameters field of the HT Capabilities element of all peer HT mesh STAs. â€” If the PPDU is a DMG PPDU, the maximum A-MPDU length exponent value that applies is the minimum value in the Maximum A-MPDU Length Exponent subfield of the A-MPDU Parameters field of the DMG Capabilities element of all DMG STAs associated with the AP or PCP. 1368 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” If the PPDU is a DMG PPDU, the minimum MPDU start spacing value that applies is the maximum value in the Minimum MPDU Start Spacing subfield of the A-MPDU Parameters field of the DMG Capabilities element of all DMG STAs associated with the AP or PCP. 10.13.5 Transport of A-MPDU by the PHY data service An A-MPDU shall be transmitted in a PSDU associated with a PHY-TXSTART.request primitive with the TXVECTOR parameter AGGREGATION set to 1 or the TXVECTOR parameter FORMAT set to VHT. A received PSDU is determined to be an A-MPDU when the associated PHY-RXSTART.indication primitive RXVECTOR parameter AGGREGATION is equal to 1 or the RXVECTOR parameter FORMAT is equal to VHT. 10.13.6 A-MPDU padding for VHT PPDU A VHT STA that transmits a VHT PPDU that contains one or more PSDUs, each of which contains an A-MPDU, shall construct the A-MPDU(s) as described in this subclause. An A-MPDU pre-EOF padding (see 10.13.2) is constructed for each user from any of the following: â€” A-MPDU subframes constructed from the MPDUs available for transmission that have a TID value that maps to the primary AC â€” A-MPDU subframes with 0 in the MPDU Length field and 0 in the EOF field provided that each added subframe and the A-MPDU pre-EOF padding meet all of the following: â€” A-MPDU content constraints (see 10.13.1) for the intended recipient â€” Format and length limit constraints (see 9.7.1 and 10.13.2) for the intended recipient â€” Minimum MPDU start spacing constraints (see 10.13.3) for the intended recipient â€” TXOP duration limits (see 10.22.2.8) for the primary AC The A-MPDU_Length[n] for user n is initialized as the length of the resulting A-MPDU pre-EOF padding. This initial value of A-MPDU_Length[n] for user n is used as the APEP_LENGTH[n] parameter value for the PLME-TXTIME.request primitive (see 6.5.5). The PLME-TXTIME.request primitive is then invoked once for the VHT PPDU. The PLME-TXTIME.confirm primitive (see 6.5.6) provides the TXTIME parameter and PSDU_LENGTH[] parameters for all of the users for the transmission. Subsequently, for each user n, as permitted by the rules for EDCA TXOP Sharing (see 10.22.2.6), a VHT STA may add A-MPDU subframes to the A-MPDU for that user that meets either of the following conditions: â€” Have a TID that maps to an AC that is not the primary AC â€” Have 0 in the MPDU Length field and 0 in the EOF field provided that each added subframe and the resulting A-MPDU meet all of the following: â€” A-MPDU content constraints (see 10.13.1) for the intended recipient â€” Length limit constraints (see 9.7.1 and 10.13.2) for the intended recipient â€” MPDU start spacing constraints (see 10.13.3) for the intended recipient and provided that, after incrementing the A-MPDU_Length[n] with the length of each such added A-MPDU subframe, the relationship A-MPDU_Length[n] PSDU_LENGTH[n] is true. 1369 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Subsequently, for each user n, a VHT STA may add A-MPDU subframes to the A-MPDU for that user that meet the following condition: â€” Have 0 in the MPDU Length field provided that each added subframe and the resulting A-MPDU meet the following condition: â€” Length limit constraints (see 9.7.1 and 10.13.2) for the intended recipient and provided that, after incrementing the A-MPDU_Length[n] with the length of each such added A-MPDU subframe, the relationship A-MPDU_Length[n] PSDU_LENGTH[n] is true. An implementation may reduce the A-MPDU_Length[n] by the amount of padding for user n that was added subsequent to the addition of a subframe for user n that contains 1 in the EOF field. The final value of A-MPDU_Length[] shall be used as APEP_LENGTH[] in the PHY-TXSTART.request primitive for the VHT PPDU. Padding is then added for each user such that the resulting A-MPDU contains exactly PSDU_LENGTH octets for that user as follows: â€” First, while A-MPDU_Length[n] < PSDU_LENGTH[n] and A-MPDU_Length[n] mod 4 0, add an octet to the final A-MPDU subframeâ€™s Padding subfield and increment A-MPDU_Length[n] by 1. â€” Then, while A-MPDU_Length[n] + 4 PSDU_LENGTH[n], add an EOF padding subframe to the EOF Padding Subframes field and increment A-MPDU_Length[n] by 4. â€” Finally, while A-MPDU_Length[n] < PSDU_LENGTH[n], add an octet to the EOF Padding Octets subfield and increment A-MPDU_Length[n] by 1. An A-MPDU subframe with EOF set to 0 shall not be added after any A-MPDU subframe with EOF set to 1. An A-MPDU subframe with EOF set to 1 and with MPDU Length field set to 0 shall not be added before an A- MPDU subframe that contains a VHT single MPDU (see 10.13.7). 10.13.7 Setting the EOF field of the MPDU delimiter The EOF field may be set to 1 in an A-MPDU subframe carried in a VHT PPDU if the subframeâ€™s MPDU Length field is nonzero and the subframe is the only subframe that has a nonzero MPDU Length field. The EOF field of each A-MPDU subframe with an MPDU Length field with a nonzero value that is not the only A- MPDU subframe with MPDU Length field with a nonzero value in the A-MPDU carried in a VHT PPDU shall be set to 0. The EOF field shall be set to 0 in all A-MPDU subframes that are carried in an HT PPDU. An MPDU that is the only MPDU in an A-MPDU and that is carried in an A-MPDU subframe with 1 in the EOF field is called a VHT single MPDU. 10.13.8 Transport of VHT single MPDUs The rules for VHT single MPDU operation are the same as the rules for non-A-MPDU frame operation with other types of non-A-MPDU. NOTEâ€”This affects the following behavior: â€” The frame could carry a fragment of an MSDU or MMPDU (see 10.2.7). â€” Rate selection of control responses (see 10.7). â€” A Data frame cannot indicate an Ack Policy of â€œImplicit Block Ackâ€, and does not generate a BlockAck frame response (see 9.2.4.5.4). â€” A Data frame could indicate an Ack Policy of â€œNormal Ackâ€, which solicits an Ack frame immediate response. No block ack agreement is needed in this case (see 9.2.4.5.4). â€” The frame could be a Management frame that solicits an Ack frame response (see 9.7.3). 1370 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.14 PPDU duration constraint A STA shall not transmit an HT PPDU that has a duration (as determined by the PHY-TXTIME.confirm primitive defined in 6.5.6 that is greater than aPPDUMaxTime defined in Table 19-25. A STA shall not transmit a DMG PPDU that has a duration (as determined by the PHY-TXTIME.confirm primitive defined in 6.5.6 that is greater than aPPDUMaxTime defined in Table 20-32. A STA shall not transmit a VHT PPDU that has a duration (as determined by the PHY-TXTIME.confirm primitive defined in 6.5.6 that is greater than aPPDUMaxTime defined in Table 21-29. A STA shall not transmit a VHT PPDU in TVWS bands that has a duration (as determined by the PHY- TXTIME.confirm primitive defined in 6.5.6 that is greater than aPPDUMaxTime defined in Table 22-25. 10.15 DMG A-PPDU operation A DMG STA is aggregate PPDU (A-PPDU) capable if the A-PPDU supported field within the STAâ€™s DMG Capabilities element is 1. Otherwise, the STA is not A-PPDU capable. A DMG STA shall not transmit an A-PPDU aggregate to a STA that is not A-PPDU capable. An A-PPDU is a sequence of two or more PPDUs transmitted without IFS, preamble, and with a PHY- dependent separation between PPDU transmissions. All PPDUs within an A-PPDU shall have the ADD- PPDU parameter of the TXVECTOR set to ADD-PPDU, except for the last PPDU in the A-PPDU that shall have this parameter set to NO-ADD-PPDU. The value of a TXVECTOR parameter of a PPDU belonging to an A-PPDU might differ from the value of the same TXVECTOR parameter of another PPDU in the same A-PPDU, including the MCS parameter. A PPDU within an A-PPDU shall contain an A-MPDU. All MPDUs within A-MPDUs within an A-PPDU shall have the same values for the TA and RA fields. All QoS Data frames within A-MPDUs within an A- PPDU shall have the same value of the Ack Policy subfield of the QoS Control field. If a frame that requires an immediate response is present within an A-PPDU, it shall be transmitted in the last A-MPDU of the A- PPDU. The transmission duration of an A-PPDU shall be no greater than aPPDUMaxTime (see Table 20-32). 10.16 LDPC operation An HT STA shall not transmit a frame with the TXVECTOR parameter FORMAT set to HT_MF or HT_GF and the TXVECTOR parameter FEC_CODING set to LDPC_CODING unless the RA of the frame corresponds to an HT STA for which the LDPC Coding Capability subfield of the HT Capabilities element received from that STA contained a value of 1 and dot11LDPCCodingOptionActivated is true. A VHT STA shall not transmit a frame with the TXVECTOR parameter FORMAT set to VHT and the TXVECTOR parameter FEC_CODING set to LDPC_CODING unless the RA of the frame corresponds to a VHT STA for which the Rx LDPC subfield of the VHT Capabilities element received from that STA contained a value of 1 and dot11VHTLDPCCodingOptionActivated is true. A VHT STA shall not transmit a frame with the TXVECTOR parameter FORMAT set to VHT and the TXVECTOR parameter FEC_CODING set to LDPC_CODING unless the RA of the frame corresponds to a VHT STA for which the Rx LDPC subfield of the VHT Capabilities element received from that STA contained a value of 1 and dot11VHTLDPCCodingOptionActivated is true. 1371 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A STA should not transmit a frame with the TXVECTOR parameter FORMAT set to HT_MF, HT_GF or VHT and the TXVECTOR parameter FEC_CODING set to LDPC_CODING if the RA of the frame corresponds to a STA from which it has received a frame containing an Operating Mode field and the most recent Operating Mode field it has received from that STA had the No LDPC subfield equal to 1. Further restrictions on TXVECTOR parameter values may apply due to rules found in 10.26 and 10.7. 10.17 STBC operation A STA that has not set the Tx STBC subfield to 1 in the HT Capabilities element shall not transmit HT PPDUs with a TXVECTOR parameter STBC set to a nonzero value. A STA that has not set the Tx STBC subfield to 1 in the VHT Capabilities element shall not transmit VHT SU PPDUs with a TXVECTOR parameter STBC set to a nonzero value. A STA shall not send an HT PPDU with the TXVECTOR parameter STBC set to a nonzero value to a recipient STA unless the recipient STA has indicated in the Rx STBC field of its HT Capabilities element that it supports the reception of PPDUs using STBC with a number of spatial streams greater than or equal to the number of spatial streams in the HT PPDU. A STA shall not send a VHT PPDU with the TXVECTOR parameter STBC set to a nonzero value to a recipient STA unless the recipient STA has indicated in the Rx STBC field of its VHT Capabilities element that it supports the reception of PPDUs using STBC with a number of spatial streams greater than or equal to the number of spatial streams in the VHT PPDU. 10.18 Short GI operation A STA may transmit a frame with TXVECTOR parameters CH_BANDWIDTH set to CBW20 and GI_TYPE set to SHORT_GI only if all of the following conditions are met: â€” The STA is an HT STA. â€” The TXVECTOR parameter FORMAT is equal to HT_MF, HT_GF, or VHT. â€” The RA of the frame corresponds to a STA for which the Short GI for 20 MHz subfield of the HT Capabilities element contained a value of 1. â€” dot11ShortGIOptionInTwentyActivated is present and is true. A STA may transmit a frame with TXVECTOR parameters CH_BANDWIDTH set to CBW40 and GI_TYPE set to SHORT_GI only if all of the following conditions are met: â€” The STA is an HT STA. â€” The TXVECTOR parameter FORMAT is equal to HT_MF, HT_GF, or VHT. â€” The RA of the frame corresponds to a STA for which the Short GI for 40 MHz subfield of the HT Capabilities element contained a value of 1. â€” dot11ShortGIOptionInFortyActivated is present and is true. A STA shall not transmit a frame with TXVECTOR parameters CH_BANDWIDTH set to CBW80 and GI_TYPE set to SHORT_GI unless all of the following conditions are met: â€” The STA is a VHT STA. â€” The TXVECTOR parameter FORMAT is equal to VHT. â€” The RA of the frame corresponds to a STA for which the Short GI for 80 MHz/TVHT_MODE_4C subfield of the VHT Capabilities element contained a value of 1. â€” dot11VHTShortGIOptionIn80Activated is present and is true. 1372 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A STA may transmit a frame with TXVECTOR parameters CH_BANDWIDTH set to CBW160 or CBW80+80 and GI_TYPE set to SHORT_GI only if all of the following conditions are met: â€” The STA is a VHT STA. â€” The TXVECTOR parameter FORMAT is equal to VHT. â€” The RA of the frame corresponds to a STA for which the Short GI for 160 and 80+80 MHz subfield of the VHT Capabilities element contained a value of 1. â€” dot11VHTShortGIOptionIn160and80p80Activated is present and is true. A STA may transmit a frame with TXVECTOR parameters FORMAT set to VHT, NUM_USERS set to greater than 1, and GI_TYPE set to SHORT_GI only if all of the following conditions are met: â€” The STA is a VHT STA. â€” The TXVECTOR parameter FORMAT is equal to VHT. â€” The RAs of all MPDUs in the VHT MU PPDU correspond to STAs for which the Short GI subfield of the following conditions are satisfied: â€” If the TXVECTOR parameter CH_BANDWIDTH is set to CBW20, the Short GI for 20 MHz subfields of the HT Capabilities element contained a value of 1, and dot11ShortGIOptionInTwentyActivated is present and is true. â€” If the TXVECTOR parameter CH_BANDWIDTH is set to CBW40, the Short GI for 40 MHz subfields of the HT Capabilities element contained a value of 1, and dot11ShortGIOptionInFortyActivated is present and is true. â€” If the TXVECTOR parameter CH_BANDWIDTH is set to CBW80, the Short GI for 80 MHz/TVHT_MODE_4C subfields of the VHT Capabilities element contained a value of 1, and dot11VHTShortGIOptionIn80Activated is present and is true. â€” If the TXVECTOR parameter CH_BANDWIDTH is set to CBW160 or CBW80+80, the Short GI for 160 MHz and 80+80 MHz subfields of the VHT Capabilities element contained a value of 1, and dot11VHTShortGIOptionIn160and80p80Activated is present and is true. An HT STA shall not transmit a frame with the TXVECTOR parameter FORMAT set to HT_GF and the GI_TYPE parameter set to SHORT_GI when the MCS parameter indicates a single spatial stream. Further restrictions on TXVECTOR parameter values may apply due to rules found in 10.26 and 10.7. 10.19 Greenfield operation An HT STA shall not transmit a frame with the TXVECTOR parameter FORMAT set to HT_GF unless the RA of the frame corresponds to a STA for which the HT-Greenfield subfield of the HT Capabilities element contained a value of 1 and dot11HTGreenfieldOptionActivated is true. Further restrictions may apply due to rules found in 10.26, 10.7, and 11.9.8.5. 10.20 Group ID and partial AID in VHT PPDUs The partial AID is a nonunique STA identifier defined in Table 10-9. The partial AID is carried in the TXVECTOR parameter PARTIAL_AID of a VHT SU PPDU and is limited to 9 bits. A STA transmitting a VHT SU PPDU carrying one or more group addressed MPDUs or transmitting a VHT NDP intended for multiple recipients shall set the TXVECTOR parameters GROUP_ID to 63 and PARTIAL_AID to 0. The intended recipient of a VHT NDP is defined in 10.34.6. 1373 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A STA transmitting a VHT SU PPDU carrying one or more individually addressed MPDUs or a VHT NDP intended for a single recipient shall set the TXVECTOR parameters GROUP_ID and PARTIAL_AID as shown in Table 10-9. Table 10-9â€”Settings for the TXVECTOR parameters GROUP_ID and PARTIAL_AID Condition GROUP_ID PARTIAL_AID Addressed to AP 0 BSSID[39:47] Addressed to Mesh STA 0 RA[39:47] Sent by an AP and 5 9 addressed to a STA AID + BSSID[44:47] BSSID[40:43] 2 mod 2 (10-12) associated with that AP or 63 sent by a DLS or TDLS STA in a direct path to a DLS or TDLS peer STA Otherwise (see NOTE) 63 0 NOTEâ€”The last row covers the following cases: â€” A PPDU sent to an IBSS STA â€” A PPDU sent by an AP to a non associated STA â€” Any other condition not explicitly listed elsewhere in the table In Table 10-9, BSSID[b:c] and RA[b:c] represent bits b to c inclusive of the BSSID and RA, respectively, with bit 0 being the Individual/Group bit and bit 47 being the last transmitted bit, in which bit position b is 0 câ€“b then scaled by 2 and c by 2 . A STA shall include the values computed in Table 10-9 in the PHYCONFIG_VECTOR parameters PARTIAL_AID_LIST_GID00 and PARTIAL_AID_LIST_GID63. A STA that transmits a VHT PPDU to a DLS or TDLS peer STA obtains the AID for the peer STA from the DLS Setup Request, DLS Setup Response, TDLS Setup Request or TDLS Setup Response frame. An AP should not assign an AID to a STA that results in a 0 value PARTIAL_AID (as computed using Equation (10-12)). A STA transmitting a VHT MU PPDU sets the TXVECTOR parameter GROUP_ID as described in 21.3.11.4. As an example of the GROUP_ID and PARTIAL_AID setting, consider the case of a BSS with BSSID 00-21- 6A-AC-53-5230 that has as a member a non-AP STA assigned AID 5. In VHT PPDUs sent to an AP, the GROUP_ID is set to 0 and the PARTIAL_AID is set to 164. In VHT PPDUs sent by the AP to the non-AP STA associated with that AP, the GROUP_ID is set to 63 and PARTIAL_AID is set to 229. 30As described in IEEE Std 802-2014, the use of hyphens for the BSSID indicates hexadecimal representation rather than bit-reversed representation. 1374 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.21 Operation across regulatory domains 10.21.1 General The PHY of a WLAN is subject to regulations that might vary significantly from one regulatory domain to another. This subclause provides the framework for operation across regulatory domains and describes the mechanism that supports cross-domain mobility and operation in multiple regulatory domains. When this mechanism is active, dot11MultiDomainCapabilityActivated attribute be true. NOTEâ€”This subclause does not eliminate the need to obtain type acceptance, regulatory approval, equipment authorization, or equipment certification in each of the regulatory domains in which the equipment operates. The mechanisms described in this subclause provide the information to the STA to identify the regulatory domain in which it is located and to cease operation while in those domains for which it does not have type approval. It is incumbent upon the implementer to provide proof of compliance to the requirements of individual regulatory agencies. The method for configuring individual STAs is outside the scope of this standard. A STA needs to be properly configured for operation in a particular regulatory domain prior to beginning normal operation. Particular care needs to be taken when operating in an IBSS configuration. 10.21.2 Operation upon entering a regulatory domain A STA that is enabled for operation across regulatory domains uses passive scanning when it has lost connectivity with its ESS. Passive scanning is performed using only the receive capabilities of the STA and is, thus, compatible with regulatory requirements. The timeout for determining the loss of connectivity is system dependent and beyond the scope of this standard. When a STA with dot11MultiDomainCapabilityActivated true enters a regulatory domain, before transmitting, it shall passively scan to learn at least one valid channel, i.e., a channel upon which it detects IEEE 802.11 frames. The Beacon frame transmitted by non-DMG STAs and the DMG Beacon or Announce frame transmitted by DMG STAs contains information on the country code, the maximum allowable transmit power, and the channels that may be used for the regulatory domain. Optionally, these frames may also include in the Country element, on a periodic basis, the regulatory information that would be returned in a Probe Response frame. When DSE dependent STA operation is required in a regulatory domain, a dependent STA may be required to receive a Beacon, DMG Beacon, or an Announce frame signaling dependent enablement (11.12.5), and until one of these frames is received, the STA may continue passive scanning to receive one such frame directly from an enabling STA. Once the STA has acquired the information so that it is able to meet the transmit requirements of the regulatory domain, it shall transmit a Probe Request frame to an AP or PCP to gain the additional necessary regulatory domain information contained in the Probe Response frame, unless the information was previously received in a Beacon, DMG Beacon, or Announce frame. The STA then has sufficient information available to configure its PHY for operation in the regulatory domain. 10.21.3 Operation with operating classes The following, and only the following, are extended spectrum management capable: a VHT STA and a STA that has dot11ExtendedSpectrumManagementImplemented true. A non-VHT STA that has dot11ExtendedSpectrumManagementImplemented true shall indicate that it is extended spectrum management capable using the Extended Spectrum Management Capable field of the Extended Capabilities element. When communicating with a STA that supports global operating classes, all requests and Action frames that convey elements containing operating classes shall use global operating class values. When dot11OperatingClassesImplemented is true, the following statements apply: â€” When dot11OperatingClassesRequired is false, or where operating classes domain information is not present in a STA, that STA is not required to change its operation in response to an element that contains an operating class. 1375 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” When dot11OperatingClassesRequired is true, or where operating classes domain information is present in a STA, the STA shall indicate current operating class information in the Country element and Supported Operating Classes element, except that a VHT STA may omit, from the Country element, any Operating Triplet field for an Operating Class for which the Channel spacing (MHz) column indicates 80 MHz or wider and for which the Behavior limits set column in the applicable table in Annex E contains only a blank entry or either or both of â€œ80+â€ and â€œUseEirpForVHTTxPowEnv.â€ â€” When dot11OperatingClassesRequired and dot11ExtendedChannelSwitchActivated are true and a STA is capable of operating as specified in more than one operating class, the STA shall include the Supported Operating Classes element in Association frames and Reassociation frames. â€” When dot11OperatingClassesRequired is true, or where operating classes domain information is present and the STA parsing a Country element finds an invalid First Channel Number field or Operating Class field with a value that is reserved, the STA shall ignore the remainder of the Country element and shall parse any remaining management frame body for additional elements. â€” When dot11OperatingClassesRequired is true and the STA supports one or more global operating classes, or where global operating classes domain information is present in a STA, the STA shall indicate current operating class information in the Country element and Supported Operating Classes element using the country string for the global operating classes, except that a VHT STA may omit from the Country element any Operating Triplet field for an Operating Class for which the Channel spacing (MHz) column indicates 80 MHz or wider and for which the Behavior limits set column in the applicable table in Annex E contains only a blank entry or either or both of â€œ80+â€ and â€œUseEirpForVHTTxPowEnv.â€ 10.21.4 Operation with the Transmit Power Envelope element A STA that is extended spectrum management capable and that has dot11SpectrumManagementRequired or dot11RadioMeasurementActivated equal to true shall determine a local maximum transmit power from a Transmit Power Envelope element for which the Local Maximum Transmit Power Unit Interpretation subfield indicates EIRP. A STA that sends two or more Transmit Power Envelope elements in a frame shall order the elements by increasing values of their Local Maximum Transmit Power Unit Interpretation subfields. If a STA that is extended spectrum management capable finds an unknown value in the Local Maximum Transmit Power Unit Interpretation subfield in a Transmit Power Envelope element, then the STA shall ignore that and subsequent Transmit Power Envelope elements. A STA that receives two or more Transmit Power Envelope elements in the same frame with known values in their Local Maximum Transmit Power Unit Interpretation subfields shall process all of the elements according to the local regulations known at the STA. NOTEâ€”If a STA receives two Transmit Power Envelope elements, each with a known value in the Local Maximum Transmit Power Unit Interpretation subfield, then the expected possibilities are as follows: â€” The STA complies with either element (shared spectrum), â€” The STA complies with both elements (tightened regulations), or â€” The STA complies with the second element (changed regulations). 10.21.5 Operation with coverage classes The attribute aSlotTime and other MAC timings are based on the PHY timing parameters, as specified in 10.3.2.3, 10.3.7 and 10.22.2.5, and in particular on aAirPropagationTime. If dot11OperatingClassesRequired is true, it is possible to manage the MAC timings of STAs to increase fairness in contending for the medium. Radio waves propagate at ~300 m/Âµs in free space, and, for example, 3 Âµs would be the ceiling for BSS maximum one-way distance of ~450 m (~900 m round trip). The Coverage Class field of the Country element 1376 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications indicates a value of aAirPropagationTime (see Table 9-79), and the MAC can use the value to calculate aSlotTime (as specified in the relevant PHY clause) and other timings. If dot11OperatingClassesRequired is true and a Country element containing a Coverage Class field has been received from the AP of the BSS with which a STA is associated, from the DO of the IBSS of which a STA is a member, or from another mesh STA in the same MBSS, an associated STA, dependent STA, member of an IBSS, or member of an MBSS shall, if the relevant PHY clause specifies that aAirPropagationTime is indicated by the coverage class, use MAC timings that correspond to the value of aAirPropagationTime indicated (as specified in the relevant PHY clause). NOTE 1â€”Some PHYs do not specify a dependency of aSlotTime on aAirPropagationTime. NOTE 2â€”Operation over larger BSS diameters is facilitated by relaxing some PHY timing parameters, while maintaining compatibility with existing implementations in small BSS diameters. aAirPropagationTime is 0 Âµs if: â€” the relevant PHY clause specifies that aAirPropagationTime is indicated by the coverage class, and â€” at least one of the following applies: â€” dot11OperatingClassesRequired is false â€” no Country element containing a Coverage Class field has been received from the AP of the BSS with which a STA is associated, from the DO of the IBSS of which a STA is a member, or from another mesh STA in the same MBSS 10.22 HCF 10.22.1 General Under HCF, the basic unit of allocation of the right to transmit onto the WM is the TXOP. Each TXOP is defined by a starting time and a defined maximum length. In a non-DMG BSS, the TXOP may be obtained by a STA winning an instance of EDCA contention (see 10.22.2) during the CP or by a STA receiving a QoS (+)CF-Poll frame (see 10.22.3) during the CP or CFP. The former is called EDCA TXOP, while the latter is called HCCA TXOP or polled TXOP. In a DMG BSS, the EDCAF operates only during CBAPs. Operation of the EDCAF is suspended at the end of a CBAP and is resumed at the beginning of the following CBAP. See 10.36.5 and 10.36.5 for additional rules regarding contention based access in DMG BSSs. HCCA is not used by DMG STAs. 10.22.2 HCF contention based channel access (EDCA) 10.22.2.1 Reference model The EDCA channel access protocol is derived from the DCF procedures described in 10.3 by adding four independent enhanced distributed channel access functions (EDCAFs) to provide differentiated priorities to transmitted traffic, through the use of four different access categories (ACs). For the case in which dot11AlternateEDCAActivated is false or not present, a model of the reference implementation is shown in Figure 10-24 and for the case in which dot11AlternateEDCAActivated is true, a model is shown in Figure 10-25. These figures illustrate a mapping from frame type or UP to the transmit queues and the four independent EDCAFs. The mapping of UP to the transmit queue and the mapping to AC are described in 10.2.4.2 and Table 10-1. The mapping of frame types to ACs is also described in 10.2.4.2. 1377 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications (MSDU, UP) Mapping to Access Category VO VI BE BK Transmit queues for ACs Per-queue EDCA functions with VO VI BE BK internal collision resolution Figure 10-24â€”Reference implementation model when dot11AlternateEDCAActivated is false or not present (MSDU, UP) Mapping to transmit queue and access category VO A_VO A_VI VI BE BK Transmit queues VO VI BE BK EDCA functions with internal collision resolution Figure 10-25â€”Reference implementation model when dot11AlternateEDCAActivated is true A DMG STA may implement a single AC. If the STA implements a single AC, all UP and frame types shall be mapped to AC_BE. NOTEâ€”A DMG STA that implements a single AC has only one queue in Figure 10-24. 1378 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.22.2.2 EDCA backoff procedure Each EDCAF shall maintain a state variable CW[AC], which shall be initialized to the value of the parameter CWmin[AC], for that EDCAFâ€™s AC. For the purposes of this subclause, transmission failure of an MPDU is defined as follows: â€” After transmitting an MPDU (even if it is carried in an A-MPDU or as part of a VHT MU PPDU that is sent using TXVECTOR parameter NUM_USERS > 1) that requires an immediate response: â€” The STA shall wait for a timeout interval of duration aSIFSTime + aSlotTime + aRxPHYStartDelay, starting when the MAC receives a PHY-TXEND.confirm primitive. If a PHY-RXSTART.indication primitive does not occur during the timeout interval, the transmission of the MPDU has failed. â€” If a PHY-RXSTART.indication primitive does occur during the timeout interval, the STA shall wait for the corresponding PHY-RXEND.indication primitive to recognize a valid response MPDU (see Annex G) that either does not have a TA field or is sent by the recipient of the MPDU requiring a response. If anything else, including any other valid frame, is recognized, the transmission of the MPDU has failed. â€” The nonfinal (re)transmission of an MPDU that is delivered using the GCR unsolicited retry retransmission policy (10.22.2.11.2)) is defined to be a failure. â€” In all other cases, the transmission of the MPDU has not failed. The TXNAV timer is a single timer, shared by the EDCAFs within a STA, that is initialized with the duration from the Duration/ID field in the frame most recently successfully transmitted by the TXOP holder, except for PS-Poll frames. The TXNAV timer begins counting down from the end of the transmission of the PPDU containing that frame. An HT STA may retransmit unacknowledged MPDUs within the same TXOP or in a subsequent TXOP. The Reservation Allocation Vector (RAV) timer for a mesh STA that has dot11MCCAActivated true is initialized with the MCCAOP Duration in the MCCAOP Reservation field at the start of an MCCAOP reservation. The RAV timer begins counting down from the start of an MCCAOP reservation (see 10.23.3.9.2). The backoff procedure shall be invoked by an EDCAF when any of the following events occurs: a) An MA-UNITDATA.request primitive is received that causes a frame with that AC to be queued for transmission such that one of the transmit queues associated with that AC has now become non- empty and any other transmit queues associated with that AC are empty; the medium is busy on the primary channel as indicated by any of the following: â€” physical CS; â€” virtual CS; â€” a nonzero TXNAV timer value; â€” a mesh STA that has dot11MCCAActivated true and a nonzero RAV timer value, and the backoff timer has a value of 0 for that AC. b) The transmission of the MPDU in the final PPDU transmitted by the TXOP holder during the TXOP for that AC has completed and the TXNAV timer has expired, and the AC was a primary AC. (See 10.22.2.6). c) The transmission of an MPDU in the initial PPDU of a TXOP fails, as defined in this subclause, and the AC was a primary AC. d) The transmission attempt collides internally with another EDCAF of an AC that has higher priority, that is, two or more EDCAFs in the same STA are granted a TXOP at the same time. 1379 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications e) The transmission attempt of a STA coordinated by an MM-SME collides internally with another STA coordinated by the same MM-SME (see 11.34), which is indicated to the first MAC entity with a PHY-TXBUSY.indication(BUSY) primitive as response to the PHY-TXSTART.request primitive. In addition, the backoff procedure may be invoked by an EDCAF when: f) The transmission by the TXOP holder of an MPDU in a non-initial PPDU of a TXOP fails, as defined in this subclause. NOTEâ€”A STA can perform a PIFS recovery, as described in 10.22.2.7, or perform a backoff, as described in the previous paragraph, as a response to transmission failure within a TXOP. How it chooses between these two is implementation dependent. A STA that performs a backoff within its existing TXOP shall not extend the TXNAV timer value (see 10.22.2.7). NOTEâ€”In other words, the backoff is a continuation of the TXOP, not the start of a new TXOP. If the backoff procedure is invoked for reason a) above, the value of CW[AC] shall be left unchanged. If the backoff procedure is invoked for reason b) above, the value of CW[AC] shall be reset to CWmin[AC]. If the backoff procedure is invoked for reason c), d), e), or f) above, or the transmission failure of a non-initial frame by the TXOP holder, the value of CW[AC] shall be updated as follows before invoking the backoff procedure: â€” If the QSRC[AC] or the QLRC[AC] has reached dot11ShortRetryLimit or dot11LongRetryLimit respectively, CW[AC] shall be reset to CWmin[AC]. â€” If dot11RobustAVStreamingImplemented is true and either the QSDRC[AC] or the QLDRC[AC] has reached dot11ShortDEIRetryLimit or dot11LongDEIRetryLimit, respectively, CW[AC] shall be reset to CWmin[AC]. â€” Otherwise, â€” If CW[AC] is less than CWmax[AC], CW[AC] shall be set to the value (CW[AC] + 1) Ã— 2 â€“ 1. â€” If CW[AC] is equal to CWmax[AC], CW[AC] shall be left unchanged. 10.22.2.3 EDCA TXOPs There are three modes of EDCA TXOP defined: initiation of an EDCA TXOP, sharing an EDCA TXOP, and multiple frame transmission within an EDCA TXOP. Initiation of the TXOP occurs when the EDCA rules permit access to the medium. Sharing of the EDCA TXOP occurs when an EDCAF within an AP that supports DL-MU-MIMO has obtained access to the medium, making the corresponding AC the primary AC, and includes traffic from queues associated with other ACs in VHT MU PPDUs transmitted during the TXOP. Multiple frame transmission within the TXOP occurs when an EDCAF retains the right to access the medium following the completion of a frame exchange sequence, such as on receipt of an Ack frame. 10.22.2.4 Obtaining an EDCA TXOP Each EDCAF shall maintain a backoff timer, which has a value measured in backoff slots as described below. When the backoff procedure is invoked, the backoff timer is set to an integer value chosen randomly with a uniform distribution taking values in the range 0 to CW[AC]. The duration AIFS[AC] is a duration derived from the value AIFSN[AC] by the relation AIFS[AC] = AIFSN[AC] Ã— aSlotTime + aSIFSTime. 1380 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications In an infrastructure BSS, AIFSN[AC] is advertised by an EDCA AP in the EDCA Parameter Set element in Beacon and Probe Response frames transmitted by the AP. The value of AIFSN[AC] shall be greater than or equal to 2 for non-AP STAs. The value of AIFSN[AC] shall be greater than or equal to 1 for APs. An EDCA TXOP is granted to an EDCAF when the EDCAF determines that it shall initiate the transmission of a frame exchange sequence. Transmission initiation shall be determined according to the following rules: EDCAF operations shall be performed at slot boundaries, defined as follows on the primary channel, for each EDCAF: a) Following AIFSN[AC] Ã— aSlotTime â€“ aRxTxTurnaroundTime of idle medium after SIFS (not necessarily idle medium during the SIFS) after the last busy medium on the antenna that was the result of a reception of a frame with a correct FCS. b) Following EIFS â€“ DIFS + AIFSN[AC] Ã— aSlotTime + aSIFSTime â€“ aRxTxTurnaroundTime of idle medium after the last indicated busy medium as determined by the physical CS mechanism that was the result of a frame reception that has resulted in FCS error, or PHY-RXEND.indication (RXERROR) primitive where the value of RXERROR is not NoError. c) When any other EDCAF at this STA transmitted a frame requiring acknowledgment, the earlier of 1) The end of the AckTimeout interval timed from the PHY-TXEND.confirm primitive, followed by AIFSN[AC] Ã— aSlotTime + aSIFSTime â€“ aRxTxTurnaroundTime of idle medium, and 2) The end of the first AIFSN[AC] Ã— aSlotTime â€“ aRxTxTurnaroundTime of idle medium after SIFS (not necessarily medium idle during the SIFS, the start of the SIFS implied by the length in the PHY header of the previous frame) when a PHY-RXEND.indication primitive occurs as specified in 10.3.2.9. d) Following AIFSN[AC] Ã— aSlotTime â€“ aRxTxTurnaroundTime of idle medium after SIFS (not necessarily medium idle during the SIFS) after the last busy medium on the antenna that was the result of a transmission of a frame for any EDCAF and which did not require an acknowledgment and after the expiration of the TXNAV timer if nonzero, and, if dot11MCCAActivated is true, the expiration of the RAV timer if nonzero. e) Following AIFSN[AC] Ã— aSlotTime + aSIFSTime â€“ aRxTxTurnaroundTime of idle medium after the last indicated busy medium as indicated by the CS mechanism that is not covered by a) to d). f) Following aSlotTime of idle medium, which occurs immediately after any of these conditions, a) to f), is met for the EDCAF. On these specific slot boundaries, each EDCAF shall make a determination to perform one and only one of the following functions: â€” Decrement the backoff timer. â€” Initiate the transmission of a frame exchange sequence. â€” Invoke the backoff procedure due to an internal collision. â€” Do nothing. NOTEâ€”If an EDCAF gains access to the channel and transmits MSDUs, A-MSDUs, or MMPDUs from a secondary AC, the EDCAF of the secondary AC is not affected by this operation. If the EDCAF of a secondary AC experiences an internal collision with the EDCAF that gained access to the channel, it performs the backoff procedure regardless of the transmission of any of its MSDUs, A-MSDUs, or MMPDUs (see 10.22.2.6). At each of the above-described specific slot boundaries, each EDCAF shall decrement the backoff timer if the backoff timer for that EDCAF has a nonzero value. At each of the above-described specific slot boundaries, each EDCAF shall initiate a transmission sequence if â€” There is a frame available for transmission at that EDCAF, and â€” The backoff timer for that EDCAF has a value of 0, and 1381 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” Initiation of a transmission sequence is not allowed to commence at this time for an EDCAF of higher UP. At each of the above-described specific slot boundaries, each EDCAF shall report an internal collision (which is handled in 10.22.2.4) if â€” There is a frame available for transmission at that EDCAF, and â€” The backoff timer for that EDCAF has a value of 0, and â€” Initiation of a transmission sequence is allowed to commence at this time for an EDCAF of higher UP. An example showing the relationship between AIFS, AIFSN, DIFS, and slot times immediately following a medium busy condition (and assuming that medium busy condition was not caused by a frame in error) is shown in Figure 10-26. In this case, with AIFSN = 2, the EDCAF may decrement the backoff counter for the first time at 2 Ã— aSlotTime following the TxSIFS (where TxSIFS is the time at which the MAC responds to the end of the medium busy condition if it is going to respond â€œafter SIFSâ€). If, in this example, the backoff counter contained a value of 1 at the time the medium became idle, transmission would start as a result of an EDCA TXOP on-air at a time aSIFSTime + 3 Ã— aSlotTime following the end of the medium busy condition. Earliest possible transmission on-air when AIFSN = 2 Initial backoff Initial backoff counter value of 0. counter value of 1. DIFS PIFS, or AIFS for AIFSN=1 aSlotTime aSlotTime aSlotTime Medium busy D1 Rx/Tx M1 D2 D2 D2 CCADel CCADel CCADel M2 M2 M2 PHY-RXEND.indication Rx/Tx Rx/Tx Rx/Tx aSlotTime aSlotTime aSlotTime MAC slot TxSIFS TxPIFS and AIFSN = 1 AIFSN = 2 AIFSN = 3 boundaries slot boundary slot boundary slot boundary slot boundary D1 = aRxPHYDelay (referenced from the end of the last symbol of a PPDU on the medium) D2 = D1 + aAirPropagationTime Rx/Tx = aRxTxTurnaroundTime (begins with a PHY-TXSTART.request) Decrement backoff or start rx M1 = M2 = aMACProcessingDelay to tx turnaround if zero when CCAdel = aCCATime â€“ D1 AIF SN=2 Figure 10-26â€”EDCA mechanism timing relationships A STA shall save the TXOP holder address for the BSS in which it is associated, which is the MAC address from the Address 2 field of the frame that initiated a frame exchange sequence except when this is a CTS frame, in which case the TXOP holder address is the Address 1 field. If the TXOP holder address is obtained from a Control frame, a VHT STA shall save the nonbandwidth signaling TA value obtained from the Address 2 field. If a non-VHT STA receives an RTS frame with the RA address matching the MAC address of the STA and the MAC address in the TA field in the RTS frame matches the saved TXOP holder address, then the STA shall send the CTS frame after SIFS, without regard for, and without resetting, its NAV. If a VHT STA receives an RTS frame with the RA address matching the MAC address of the STA and the nonbandwidth signaling TA value obtained from the Address 2 field in the RTS frame matches the saved TXOP holder address, then the STA shall send the CTS frame after SIFS, without regard for, and without 1382 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications resetting, its NAV. When a STA receives a frame addressed to it that requires an immediate response, except for RTS, it shall transmit the response independent of its NAV. The saved TXOP holder address shall be cleared when the NAV is reset or when the NAV counts down to 0. 10.22.2.5 EDCA channel access in a VHT or TVHT BSS If the MAC receives a PHY-CCA.indication primitive with the channel-list parameter present, the channels considered idle are defined in Table 10-10. Table 10-10â€”Channels indicated idle by the channel-list parameter PHY-CCA.indication primitive channel-list Idle channels element primary None secondary Primary 20 MHz channel secondary40 Primary 20 MHz channel and secondary 20 MHz channel secondary80 Primary 20 MHz channel, secondary 20 MHz channel, and secondary 40 MHz channel When a STA and the BSS, of which the STA is a member, both support multiple channel widths, an EDCA TXOP is obtained based solely on activity of the primary channel. â€œIdle mediumâ€ in this subclause means â€œidle primary channel.â€ Likewise â€œbusy mediumâ€ means â€œbusy primary channel.â€ Once an EDCA TXOP has been obtained according to this subclause, further constraints defined in 11.16.9 and 10.22.3 might limit the width of transmission during the TXOP or deny the channel access, based on the state of CCA on secondary channel, secondary 40 MHz channel, or secondary 80 MHz channel. In the following description, the CCA is sampled according to the timing relationships defined in 10.3.7. Slot boundaries are determined solely by activity on the primary channel. â€œChannel idle for an interval of PIFSâ€ means that the STATE parameter of the most recent PHY-CCA.indication primitive was IDLE, and no PHY- CCA.indication(BUSY) occurred during the period of PIFS that ends at the start of transmission, the CCA for that channel was determined to be idle. If a STA is permitted to begin a TXOP (as defined in 10.22.2.4) and the STA has at least one MSDU pending for transmission for the AC of the permitted TXOP, the STA shall perform exactly one of the following actions: a) Transmit a 160 MHz or 80+80 MHz mask PPDU if the secondary channel, the secondary 40 MHz channel, and the secondary 80 MHz channel were idle during an interval of PIFS immediately preceding the start of the TXOP. b) Transmit an 80 MHz mask PPDU on the primary 80 MHz channel if both the secondary channel and the secondary 40 MHz channel were idle during an interval of PIFS immediately preceding the start of the TXOP. c) Transmit a 40 MHz mask PPDU on the primary 40 MHz channel if the secondary channel was idle during an interval of PIFS immediately preceding the start of the TXOP. d) Transmit a 20 MHz mask PPDU on the primary 20 MHz channel. e) Restart the channel access attempt by invoking the backoff procedure as specified in 10.22.2 as though the medium is busy on the primary channel as indicated by either physical or virtual CS and the backoff timer has a value of 0. 1383 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications f) Transmit a TVHT_4W or TVHT_2W+2W mask PPDU if the secondary TVHT_W channel and the secondary TVHT_2W channel were idle during an interval of PIFS immediately preceding the start of the TXOP. g) Transmit a TVHT_2W or TVHT_W+W mask PPDU if the secondary TVHT_W channel was idle during an interval of PIFS immediately preceding the start of the TXOP. h) Transmit a TVHT_W mask PPDU on the primary TVHT_W channel. NOTE 1â€”In the case of rule e), the STA selects a new random number using the current value of CW[AC], and the retry counters are not updated (as described in 10.22.2.7; backoff procedure invoked for event a)). NOTE 2â€”For both an HT and a VHT STA, an EDCA TXOP is obtained based on activity on the primary channel (see 10.22.2.4). The width of transmission is determined by the CCA status of the nonprimary channels during the PIFS interval before transmission (see VHT description in 10.3.2). 10.22.2.6 Sharing an EDCA TXOP This mode applies only to an AP that supports DL-MU-MIMO. The AC associated with the EDCAF that gains an EDCA TXOP becomes the primary AC. TXOP sharing is allowed when primary AC traffic is transmitted in a VHT MU PPDU and resources permit traffic from secondary ACs to be included, targeting up to four STAs. The inclusion of secondary AC traffic in a VHT MU PPDU shall not increase the duration of the VHT MU PPDU beyond that required to transport the primary AC traffic. If a destination is targeted by frames in the queues of both the primary AC and at least one secondary AC, the frames in the primary AC queue shall be transmitted to the destination first, among a series of downlink transmissions within a TXOP. The decision of which secondary ACs and destinations are selected for TXOP sharing, as well as the order of transmissions, are implementation specific and out of scope of this standard. When sharing, the TXOP limit that applies is the TXOP limit of the primary AC. NOTEâ€”An AP can protect an immediate response by preceding the VHT MU PPDU (which might have TXVECTOR parameter NUM_USERS > 1) with an RTS/CTS exchange or a CTS-to-self transmission. An illustration of TXOP sharing is shown in Figure 10-27. In this figure, the AP has frames in queues of three of its ACs. It is assumed that the TXOP was obtained by AC_VI and is shared by AC_VO and AC_BE. It is also assumed that these frames are targeting three STAs, STA-1 to STA-3. 10.22.2.7 Multiple frame transmission in an EDCA TXOP A frame exchange, in the context of multiple frame transmission in an EDCA TXOP, may be one of the following: â€” A frame not requiring immediate acknowledgment (such as a group addressed frame or a frame transmitted with an acknowledgment policy that does not require immediate acknowledgment) or an A-MPDU containing only such frames â€” A frame requiring acknowledgment (such as an individually addressed frame transmitted with an acknowledgment policy that requires immediate acknowledgment) or an A-MPDU containing at least one such frame, followed after SIFS by a corresponding acknowledgment frame â€” Either â€” a VHT NDP Announcement frame followed after SIFS by a VHT NDP followed after SIFS by a PPDU containing one or more VHT Compressed Beamforming frames, or â€” a Beamforming Report Poll frame followed after SIFS by a PPDU containing one or more VHT Compressed Beamforming frames 1384 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications (MSDU, UP) AC_VO AC_VI AC_BE AC_BK (primary) (4) (to S TA-3) (3) (to S TA-2) (3) (to S TA-1) (2) (to S TA-3) (2) (to S TA-1) (1) (to S TA-2) (1) (to S TA-1) (1) (to S TA-2) EDCAF EDCAF EDCAF EDCAF TXOP RA = STA-1, AC_VI (1) pad RA = STA-1, AC_VI (2) RA = STA-1, AC_VI (3) Preamble Preamble Preamble AP RA = STA-2, AC_BE (1) pad RA = STA-2, AC_VO (1) pad RA = STA-2, AC_BE (3) BAR BAR BAR BAR BAR RA = STA-3, AC_VI (4) RA = STA-3, AC_BE (2) pad STA-1 BA BA BA STA-2 BA BA BA STA-3 BA BA Time Figure 10-27â€”Illustration of TXOP sharing and PPDU construction Multiple frames may be transmitted in an EDCA TXOP that was acquired following the rules in 10.22.2.4 if there is more than one frame pending in the primary AC for which the channel has been acquired. However, those frames that are pending in other ACs shall not be transmitted in this EDCA TXOP except when sent in a VHT MU PPDU with TXVECTOR parameter NUM_USERS > 1 and if allowed by the rules in 10.22.2.6. If a TXOP holder has in its transmit queue an additional frame of the primary AC and the duration of transmission of that frame plus any expected acknowledgment for that frame is less than the remaining TXNAV timer value and, if dot11MCCAActivated is true, the remaining RAV timer value, then the TXOP holder may commence transmission of that frame a SIFS (or RIFS, if the conditions defined in 10.3.2.3.2 are met) after the completion of the immediately preceding frame exchange sequence, subject to the TXOP limit restriction as described in 10.22.2.8. A STA shall not commence the transmission of an RTS with a bandwidth signaling TA until at least a PIFS after the immediately preceding frame exchange sequence. An HT STA that is a TXOP holder may transmit multiple MPDUs of the same AC within an A-MPDU as long as the duration of transmission of the A-MPDU plus any expected BlockAck frame response is less than the remaining TXNAV timer value and, if dot11MCCAActivated is true, the remaining RAV timer value. NOTE 1â€”PIFS is used by a VHT STA to perform CCA in the secondary 20 MHz, 40 MHz, and 80 MHz channels before receiving RTS (see 10.3.2). NOTE 2â€”An RD responder can transmit multiple MPDUs as described in 10.28.4. 1385 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications After a valid response (see Annex G) to the initial frame of a TXOP, if the Duration/ID field is set for multiple frame transmission and there is a subsequent transmission failure, the corresponding channel access function may transmit after the CS mechanism (see 10.3.2.1) indicates that the medium is idle at the TxPIFS slot boundary (see Figure 10-26) provided that the duration of that transmission plus the duration of any expected acknowledgment and applicable IFS is less than the remaining TXNAV timer value and, if dot11MCCAActivated is true, the RAV timer. At the expiration of the TXNAV timer and if dot11MCCAActivated is true, the RAV timer, if the channel access function has not regained access to the medium, then the EDCAF shall invoke the backoff procedure that is described in 10.22.2.4. Transmission failure is defined in 10.22.2.11. All other channel access functions at the STA shall treat the medium as busy until the expiration of the TXNAV timer. Note that, as for an EDCA TXOP, a multiple frame transmission is granted to an EDCAF, not to a STA, so that the multiple frame transmission is permitted only for the transmission of a frame of the same AC as the frame that was granted the EDCA TXOP, unless the EDCA TXOP obtained is used by an AP for a PSMP sequence or a VHT MU PPDU with TXVECTOR parameter NUM_USERS > 1. In the case of PSMP, this AC transmission restriction does not apply to either the AP or the STAs participating in the PSMP sequence, but the specific restrictions on transmission during a PSMP sequence described in 10.29 do apply. If a TXOP is protected by an RTS or CTS frame carried in a non-HT or a non-HT duplicate PPDU, the TXOP holder shall set the TXVECTOR parameter CH_BANDWIDTH of a PPDU as follows: â€” To be the same or narrower than RXVECTOR parameter CH_BANDWIDTH_IN_NON_HT of the last received CTS frame in the same TXOP, if the RTS frame with a bandwidth signaling TA and TXVECTOR parameter DYN_BANDWIDTH_IN_NON_HT set to Dynamic has been sent by the TXOP holder in the last RTS/CTS exchange. â€” Otherwise, to be the same or narrower than the TXVECTOR parameter CH_BANDWIDTH of the RTS frame that has been sent by the TXOP holder in the last RTS/CTS exchange in the same TXOP. If there is no RTS/CTS exchange in non-HT duplicate format in a TXOP, and the TXOP includes at least one non-HT duplicate frame exchange that does not include a PS-Poll, then the TXOP holder shall set the CH_BANDWIDTH parameter in TXVECTOR of a PPDU sent after the first non-HT duplicate frame that is not a PS-Poll to be the same or narrower than the CH_BANDWIDTH parameter in TXVECTOR of the initial frame in the first non-HT duplicate frame exchange in the same TXOP. If there is no non-HT duplicate frame exchange in a TXOP, the TXOP holder shall set the TXVECTOR parameter CH_BANDWIDTH of a non-initial PPDU to be the same or narrower than the TXVECTOR parameter CH_BANDWIDTH of the preceding PPDU that it has transmitted in the same TXOP. If a TXOP is protected by a CTS-to-self frame carried in a non-HT or non-HT duplicate PPDU, the TXOP holder shall set the TXVECTOR parameter CH_BANDWIDTH of a PPDU to be the same or narrower than the TXVECTOR parameter CH_BANDWIDTH of the CTS-to-self frame in the same TXOP. Note that when transmitting multiple frames in a TXOP using acknowledgment mechanisms other than Normal Ack, a protective mechanism should be used (such as RTS/CTS or the protection mechanism described in 10.26). A QoS AP or a mesh STA may send group addressed frames without using any protection mechanism. In a QoS IBSS, group addressed frames shall be sent one at a time, and backoff shall be performed after the transmission of each of the group addressed frames. In an MBSS, a mesh STA may send multiple group addressed frames in a TXOP, bounded by the TXOP limit, without performing backoff after the TXOP is obtained. 1386 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.22.2.8 TXOP limits The duration of a TXOP is the time a STA obtaining a TXOP (the TXOP holder) maintains uninterrupted control of the medium, and it includes the time required to transmit frames sent as an immediate response to TXOP holder transmissions. The TXOP holder shall, subject to the exceptions below, ensure that the duration of a TXOP does not exceed the TXOP limit, when nonzero. The TXOP limits are advertised by the AP in the EDCA Parameter Set element in Beacon and Probe Response frames transmitted by the AP. A TXOP limit of 0 indicates that the TXOP holder may transmit or cause to be transmitted (as responses) the following within the current TXOP: a) One of the following at any rate, subject to the rules in 10.7 1) One or more SU PPDUs carrying fragments of a single MSDU or MMPDU 2) An SU PPDU or a VHT MU PPDU carrying a single MSDU, a single MMPDU, a single A-MSDU, or a single A-MPDU 3) A VHT MU PPDU carrying A-MPDUs to different users (a single A-MPDU to each user) 4) A QoS Null frame or PS-Poll frame b) Any required acknowledgments c) Any frames required for protection, including one of the following: 1) An RTS/CTS exchange 2) CTS to itself 3) Dual CTS as specified in 10.3.2.8 d) Any frames required for beamforming as specified in 10.30, 10.34.5 and 10.38. e) Any frames required for link adaptation as specified in 10.31 f) Any number of BlockAckReq frames NOTE 1â€”This is a rule for the TXOP holder. A TXOP responder need not be aware of the TXOP limit nor of when the TXOP was started. NOTE 2â€”This rule prevents the use of RD when the TXOP limit is 0. When dot11OCBActivated is true, TXOP limits shall be 0 for each AC. The TXOP holder may exceed the TXOP limit only if it does not transmit more than one Data or Management frame in the TXOP, and only for the following situations: â€” Retransmission of an MPDU, not in an A-MPDU consisting of more than one MPDU â€” Initial transmission of an MSDU under a block ack agreement, where the MSDU is not in an A- MPDU consisting of more than one MPDU and the MSDU is not in an A-MSDU â€” Transmission of a Control MPDU or a QoS Null MPDU, not in an A-MPDU consisting of more than one MPDU â€” Initial transmission of a fragment of an MSDU or MMPDU, if a previous fragment of that MSDU or MMPDU was retransmitted â€” Transmission of a fragment of an MSDU or MMPDU fragmented into 16 fragments â€” Transmission of an A-MPDU consisting of the initial transmission of a single MPDU not containing an MSDU and that is not an individually addressed Management frame â€” Transmission of a group addressed MPDU, not in an A-MPDU consisting of more than one MPDU â€” Transmission of a null data packet (NDP) 1387 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” Transmission of a VHT NDP Announcement frame and NDP or transmission of a Beamforming Report Poll frame, where these fit within the TXOP limit and it is only the response and the immediately preceding SIFS that cause the TXOP limit to be exceeded. Except as described above, a STA shall fragment an individually addressed MSDU or MMPDU so that the initial transmission of the first fragment does not cause the TXOP limit to be exceeded. NOTEâ€”The TXOP limit is not exceeded for the following situations: â€” Initial transmission of an MPDU containing an unfragmented though fragmentable (see 10.2.7) MSDU/ MMPDU â€” Initial transmission of the first fragment of a fragmented MSDU/MMPDU, except for an MSDU/MMPDU fragmented into 16 fragments â€” Initial transmission of an A-MSDU â€” Initial transmission of a fragment of a fragmented MSDU/MMPDU, if no previous fragment of that MSDU/ MMPDU was retransmitted, except for an MSDU/MMPDU fragmented into 16 fragments â€” Transmission of an A-MPDU consisting of a single MPDU containing an A MSDU or individually addressed Management frame, unless this is a retransmission of that MPDU â€” Transmission of an A-MPDU consisting of more than one MPDU, even if some or all of the MPDUs are retransmissions If the TXOP holder exceeds the TXOP limit, it should use as high a PHY rate as possible to minimize the duration of the TXOP. The duration of a TXOP for a mesh STA that has dot11MCCAActivated true shall not exceed the time between the start of the TXOP and the end of the current MCCAOP reservation. NOTEâ€”The rules in this subclause also apply to priority-downgraded MSDUs and A-MSDUs (see 10.22.4.2. 10.22.2.9 Truncation of TXOP When a STA gains access to the channel using EDCA and empties its transmission queue, it may transmit a CF-End frame provided that the remaining duration is long enough to transmit this frame. By transmitting the CF-End frame, the STA is explicitly indicating the completion of its TXOP. In a DMG BSS, the STA shall not send a CF-End frame with a nonzero value in the Duration/ID field if the remaining duration is shorter than 2Ã—TCF-End + 2Ã—SIFS, where TCF-End is the duration of a CF-End frame. A TXOP holder that transmits a CF-End frame shall not initiate any further frame exchange sequences within the current TXOP. A non-AP STA that is not the TXOP holder shall not transmit a CF-End frame. In a non-DMG BSS, a STA shall interpret the reception of a CF-End frame as a NAV reset, i.e., it resets its NAV to 0 at the end of the PPDU containing this frame. After receiving a CF-End frame with a matching BSSID(TA) without comparing Individual/Group bit, an AP may respond by transmitting a CF-End frame after SIFS. NOTE 1â€”The transmission of a single CF-End frame by the TXOP holder resets the NAV of STAs hearing the TXOP holder. There may be STAs that could hear the TXOP responder that had set their NAV that do not hear this NAV reset. Those STAs are prevented from contending for the medium until the original NAV reservation expires. NOTE 2â€”A CF-End sent by a non-AP VHT STA that is a member of a VHT BSS can include the TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT as defined in 10.7.6.6 in case it elicits a CF-End response. In a DMG BSS, a STA that is not in the listening mode (10.36.6.6) shall interpret the reception of a CF-End frame as a NAV reset, i.e., it resets its NAV to 0 at the end of the time interval indicated in the value of the Duration/ID field of the received frame. The interval starts at PHY-RXEND.indication primitive of the frame reception. The STA shall not transmit during the interval if the RA field of the frame is not equal to the STA 1388 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MAC address. The STA may transmit a CF-End frame if the RA field of the received frame is equal to the STA MAC address and the value of the Duration/ID field in the received frame is not equal to 0. Figure 10-28 shows an example of TXOP truncation. In this example, the STA accesses the medium using EDCA channel access and then transmits a nav-set sequence (e.g., RTS/CTS for non-DMG STAs or RTS/ DMG CTS for DMG STAs) (using the terminology of Annex G). After a SIFS, it then transmits an initiator- sequence, which may involve the exchange of multiple PPDUs between the TXOP holder and TXOP responders. At the end of the second sequence, the TXOP holder has no more data that it can send that fits within the TXOP limit; therefore, it truncates the TXOP by transmitting a CF-End frame. TXOP Duration f o d d n P n e nav-set sequence initiator-sequence E - l O a X F in T C m o N EDCA Channel Access SIFS SIFS Figure 10-28â€”Example of TXOP truncation Non-DMG STAs that receive a CF-End frame reset their NAV and can start contending for the medium without further delay. A DMG STA that receives a CF-End frame can start contending for the medium at the end of the time interval equal to the value in Duration/ID field of the frame if none of its NAVs has a nonzero value (10.36.10). TXOP truncation shall not be used in combination with L-SIG TXOP protection when the HT Protection field of the HT Operation element is equal to nonmember protection mode or non-HT mixed mode. 10.22.2.10 Termination of TXOP A TXOP holder that transmits a PPDU using one of the modulation classes in Table 10-11 should transmit a short control frame as the final transmission in a TXOP, under the conditions specified in Table 10-12. Table 10-11â€”Modulation classes eligible for TXOP termination Modulation classes eligible for TXOP termination (see Table 10-6) DSSS HR/DSSS ERP-OFDM OFDM (20 MHz channel spacing) HT VHT 1389 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 10-12â€”Rate and modulation class of a final transmission in a TXOP Modulation class and data rate of immediately preceding Rate and modulation class of final frame in TXOP transmission DSSS or HR/DSSS with long preamble, data rate > 1 Mb/s 1 Mb/s DSSS HR/DSSS with short preamble, data rate > 2 Mb/s 2 Mb/s HR/DSSS short preamble Other eligible modulation classes, data rate > 6 Mb/s 6 Mb/s OFDM The final transmission can be a CF-End, or a CTS-to-self when no NAV needs to be truncated. NOTEâ€”The final transmission at the lowest data rate within the modulation class is needed because a final transmission at a higher rate can cause spurious EIFSs to occur, because the PHY header of such frames travels farther than the MPDU. 10.22.2.11 Retransmit procedures 10.22.2.11.1 General A QoS STA shall maintain a short retry counter and a long retry counter for each MSDU, A-MSDU, or MMPDU that belongs to a TC that requires acknowledgment. The initial value for the short and long retry counters shall be 0. QoS STAs also maintain a short retry counter and a long retry counter for each AC. They are defined as QSRC[AC] and QLRC[AC], respectively, and each is initialized to a value of 0. When dot11RobustAVStreamingImplemented is true, a QoS STA shall maintain a short drop-eligible retry counter and a long drop-eligible retry counter for each AC. They are defined as QSDRC[AC] and QLDRC[AC], respectively, and each is initialized to a value of zero. APs with dot11RobustAVStreamingImplemented true and mesh STAs with dot11MeshGCRImplemented true, shall maintain an unsolicited retry counter. After an RTS frame is transmitted to protect an MSDU or MMPDU, a QoS STA performs the CTS procedure, as defined in 10.3.2.7. If a valid CTS frame is not received, the short retry counter for the MSDU or MMPDU and the QSRC[AC] for the corresponding AC shall be incremented. If a valid CTS frame is received, the QSRC[AC] for the corresponding AC shall be reset to 0. After transmitting a frame that requires an immediate acknowledgment, the STA shall perform either of the acknowledgment procedures, as appropriate, that are defined in 10.3.2.9 and 10.24.3. The short retry count for an MSDU or A-MSDU that is not part of a block ack agreement or for an MMPDU shall be incremented every time transmission of a frame in a PSDU of length less than or equal to dot11RTSThreshold fails for that MSDU, A-MSDU, or MMPDU. The unsolicited retry counter shall be incremented after the transmission of every A-MSDU that is transmitted using the GCR unsolicited retry retransmission policy. QSRC[AC] shall be incremented every time transmission of an A-MPDU or frame in a PSDU of length less than or equal to dot11RTSThreshold fails, regardless of the presence or value of the DEI field. When dot11RobustAVStreamingImplemented is true, QSDRC[AC] shall be incremented every time transmission of an A-MPDU or frame in which the HT variant HT Control field is present, the DEI field is equal to 1 and the length of the PSDU is less than or equal to dot11RTSThreshold fails. This short retry count and the QoS STA QSRC[AC] shall be reset when an A-MPDU or frame of length in a PSDU less than or equal to dot11RTSThreshold succeeds. When dot11RobustAVStreamingImplemented is true, the QSDRC[AC] shall be reset when an A-MPDU or frame in a PSDU of length less than or equal to dot11RTSThreshold succeeds, regardless of the presence or value of the DEI field. The long retry count for an MSDU or A-MSDU that is not part of a block ack agreement or for an MMPDU shall be incremented every time transmission of a MAC frame in a PSDU of length greater than dot11RTSThreshold fails for that MSDU, A-MSDU, or MMPDU. 1390 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications QLRC[AC] shall be incremented every time transmission of an A-MPDU or frame in a PSDU of length greater than dot11RTSThreshold fails, regardless of the presence or value of the DEI field. This long retry count and the QLRC[AC] shall be reset when an A-MPDU or frame in a PSDU of length greater than dot11RTSThreshold succeeds. When dot11RobustAVStreamingImplemented is true, QLDRC[AC] shall be incremented every time transmission fails for an A-MPDU or frame in a PSDU of length greater than dot11RTSThreshold in which the HT variant HT Control field is present and the DEI field is equal to 1. The QLDRC[AC] shall be reset when an A-MPDU or frame in a PSDU of length greater than dot11RTSThreshold succeeds, regardless of the presence or value of the DEI field. All retransmission attempts by a non-DMG STA for an MPDU with the Type subfield equal to Data or Management that is not sent under a block ack agreement and that has failed the acknowledgment procedure one or more times shall be made with the Retry subfield set to 1. All retransmission attempts by a DMG STA for an MPDU with the Type subfield equal to Data or Management that has failed the acknowledgment procedure one or more times shall be made with the Retry subfield set to 1. Retries for failed transmission attempts shall continue until one or more of the following conditions occurs: â€” The short retry count for the MSDU, A-MSDU, or MMPDU is equal to dot11ShortRetryLimit. â€” The long retry count for the MSDU, A-MSDU, or MMPDU is equal to dot11LongRetryLimit. â€” The short drop-eligible retry count for the MSDU, A-MSDU, or MMPDU is equal to dot11ShortDEIRetryLimit. â€” The long drop-eligible retry count for the MSDU, A-MSDU, or MMPDU is equal to dot11LongDEIRetryLimit. â€” The unsolicited retry count for the A-MSDU is equal to dot11UnsolicitedRetryLimit. When any of these limits is reached, retry attempts shall cease, and the MSDU, A-MSDU, or MMPDU shall be discarded. For internal collisions occurring with the EDCA access method, the appropriate retry counters (short retry counter for MSDU, A-MSDU, or MMPDU and QSRC[AC] or long retry counter for MSDU, A-MSDU, or MMPDU and QLRC[AC]) are incremented. For internal collisions occurring with the EDCA access method where dot11RobustAVStreamingImplemented is true, the appropriate drop-eligible retry counters (QSDRC[AC], and QLDRC[AC]) are incremented when the collision occurs for an MSDU, A-MSDU, or MMPDU that has drop eligibility equal to 1. For transmissions that use block ack, the rules in 10.24.3 also apply. A STA shall retry failed transmissions until the transmission is successful or until the relevant retry limit is reached. With the exception of a frame belonging to a TID for which block ack agreement is set up, a QoS STA shall not initiate the transmission of any Management or Data frame to a specific RA while the transmission of another Management or Data frame with the same RA and having been assigned its sequence number from the same sequence counter has not yet completed to the point of success, retry fail, or other MAC discard (e.g., lifetime expiration). A QoS STA shall maintain a transmit MSDU timer for each MSDU passed to the MAC. dot11EDCATableMSDULifetime specifies the maximum amount of time allowed to transmit an MSDU for a given AC. The transmit MSDU timer shall be started when the MSDU is passed to the MAC. If the value of this timer exceeds the appropriate entry in dot11EDCATableMSDULifetime, then the MSDU, or any remaining, undelivered fragments of that MSDU, shall be discarded by the source STA without any further attempt to complete delivery of that MSDU. When A-MSDU aggregation is used, the HT STA maintains a single timer for the whole A-MSDU. The timer is restarted each time an MSDU is added to the A-MSDU. The result of this procedure is that no MSDU in the A-MSDU is discarded before a period of dot11EDCATableMSDULifetime has elapsed. 1391 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.22.2.11.2 Unsolicited retry procedure When using the GCR unsolicited retry retransmission policy for a group address, an AP or mesh STA may retransmit an MPDU to increase the probability of correct reception at the STAs that are listening to this group address (i.e., the group address is in their dot11GroupAddressesTable). The set of MPDUs that may be retransmitted is dependent upon whether block ack agreements are active with the STAs that are listening to this group address and is defined in 11.24.16.3.6. How an AP or a mesh STA chooses which MPDUs to retransmit is an implementation decision and beyond the scope of this standard. A protective mechanism (such as a mechanism described in 10.26) should be used to reduce the probability of other STAs transmitting during the GCR TXOP. When using a protection mechanism that requires a response from another STA, the AP should select a STA that is a member of the GCR group. The TXOP initiation rules defined in 10.22.2.2 and 10.22.3.3 shall be used for initiating a GCR TXOP. The duration of a GCR TXOP shall be subject to the TXOP limits defined in 10.22.2.8. When transmitting MPDUs using the GCR service with retransmission policy equal to GCR unsolicited retry, the following rules apply: â€” Following a MAC protection exchange that includes a response frame, in all GCR unsolicited retry retransmissions, the STA shall either transmit the frames within a GCR TXOP separated by SIFS or invoke its backoff procedure as defined in 10.22.2.2. The STA shall not transmit an MPDU and a retransmission of the same MPDU within the same GCR TXOP. The final frame transmitted within a GCR TXOP shall follow the backoff procedure defined in 10.22.2.2 â€” Without MAC protection or with MAC protection that lacks a response frame, in all transmissions, the STA shall invoke the backoff procedure defined in 10.22.2.2, using a value of CWmin[AC] for CW, at the PHY-TXEND.confirm primitive that follows the transmission of each unsolicited retry GCR MPDU. â€” All retransmissions of an MPDU shall have the Retry subfield in their Frame Control fields set to 1. â€” During a GCR TXOP, frames may be transmitted within the GCR TXOP that do not use the GCR unsolicited retry retransmission policy. 10.22.3 HCF controlled channel access (HCCA) 10.22.3.1 General The HCCA mechanism manages access to the WM using an HC that has higher medium access priority than non-AP STAs. This allows it to transfer MSDUs to STAs and to allocate TXOPs to STAs. The HC is a type of centralized coordinator, but differs from the PC used in PCF in several significant ways, although it may implement the functionality of a PC. Most important is that HCF frame exchange sequences may be used among STAs associated in an infrastructure BSS during both the CP and the CFP. Another significant difference is that the HC grants a STA a polled TXOP with duration specified in a QoS (+)CF-Poll frame. A STA may transmit multiple frame exchange sequences within given polled TXOPs, subject to the limit on TXOP duration. All STAs inherently obey the NAV rules of the HCF because each frame transmitted under HCF contains a duration value chosen to cause STAs in the BSS to set their NAVs to protect the expected subsequent frames. A non-AP QoS STA shall be able to respond to QoS (+)CF-Poll frames received from an HC with the Address 1 field matching their own addresses. 1392 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The HC shall perform delivery of buffered non-GCR-SP group addressed MSDUs/MMPDUs following DTIM Beacon frames. The HC may also operate as a PC, providing (non-QoS) CF-Polls to associated CF-Pollable STAs using the frame formats, frame exchange sequences, and other applicable rules for PCF specified in 10.4.31 An HC may perform a backoff following an interruption of a frame exchange sequence due to lack of an expected response under the rules described in 10.22.3.2.4, using the parameters dot11HCCWmin, dot11HCCWmax, and dot11HCCAIFSN and the backoff rules in 10.2 and 10.22.2.2. The decision to perform a backoff by the HC is dependent on conditions such as interference from an overlapping BSS. The mechanism to detect the interference from an overlapping BSS and the decision to perform a backoff, DFS (such as in 11.6), or other techniques (such as inter-BSS scheduling) is beyond the scope of this standard. 10.22.3.2 HCCA procedure 10.22.3.2.1 General The HC gains control of the WM as needed to send QoS traffic and to issue QoS (+)CF-Poll frames to STAs by waiting a shorter time between transmissions than the STAs using the EDCA procedures. The duration values used in QoS frame exchange sequences reserve the medium to permit completion of the current sequence. The HC may include a CF Parameter Set element in the Beacon frames it generates. This causes the BSS to appear to be a point-coordinated BSS to STAs. This causes STAs to set their NAVs to the CFPDurRemaining value in the CF Parameter Set element value at TBTT, as specified in 10.4.4.3. This prevents most contention in the CFP by preventing nonpolled transmissions by STAs regardless of whether they are CF-Pollable. 10.22.3.2.2 CFP generation The HC may function as a PC that uses the CFP for delivery, generating a CFP as shown in Figure 10-20, with the restriction that the CFP initiated by an HC shall end with a CF-End frame. The HC may also issue QoS (+)CF-Poll frames to associated STAs during the CFP. However, because the HC can also grant polled TXOPs, by sending QoS (+)CF-Poll frames, during the CP, the HC might not use the CFP for QoS data transfers. Only an AP that also issues non-QoS CF-Poll frames to associated CF-Pollable A STA may end a CFP with a CF-End +CF-Ack frame and only when the CF-End +CF-Ack is acknowledging a reception from a CF- Pollable non-QoS STA. The use of a non-QoS CF-Poll frame by an AP to a QoS STA is deprecated (for further discussion; see 9.4.1.4). 10.22.3.2.3 CAP generation When the HC needs access to the WM to start a CFP or a TXOP in CP, the HC shall sense the WM. When the WM is determined to be idle at the TxPIFS slot boundary as defined in 10.3.7, the HC shall transmit the first frame of any permitted frame exchange sequence, with the duration value set to cover the CFP or the TXOP. An HCCA TXOP shall not extend across a TBTT. The occurrence of a TBTT implies the end of the HCCA TXOP, after which the regular channel access procedure (EDCA or HCCA) is resumed. It is possible that no frame was transmitted during the TXOP. The shortened termination of the HCCA TXOP does not imply an error condition. The first permitted frame in a CFP after a TBTT is the Beacon frame. CAPs along with the CFPs and the CPs are illustrated in Figure 10-29. 31 Attempting to intersperse HCF frame exchange sequences and PCF frame exchange sequences in a single CFP might be extremely complex. 1393 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B B B B e e e e a a a a c c c c o o o o n n n n DTIM DTIM DTIM DTIM CFP CP CFP CFP Repetition Interval CAP EDCA TXOPs and access by legacy STAs using DCF. Figure 10-29â€”CAP/CFP/CP periods After the last frame of all other nonfinal frame exchange sequences (e.g., sequences that convey individually addressed QoS Data or Management frames) during a TXOP, the holder of the current TXOP shall wait for one SIFS before transmitting the first frame of the next frame exchange sequence. The HC may sense the channel and reclaim the channel if the WM is determined to be idle at the TxPIFS slot boundary after the TXOP (see Figure 10-26). A CAP ends when the HC does not reclaim the channel at the TxPIFS slot boundary after the end of a TXOP. 10.22.3.2.4 Recovery from the absence of an expected reception This subclause describes recovery from the absence of an expected reception in a CAP. Note that the recovery rules from the absence of an expected reception are different from EDCA because in this case the NAVs of all of the STAs in the BSS have already been set up by the transmissions by the HC. The recovery rules for the multiple frame transmission are different because a STA may always be hidden and may have not set its NAV due to the transmission by another STA. Finally, since an HC is collocated with the AP, the AP may recover using the rules described in this subclause even if the recovery is from the absence of an expected reception. The beginning of reception of an expected response is detected by the occurrence of PHY- CCA.indication(BUSY,channel-list) primitive at the STA that is expecting the response where the channel-list parameter is absent or, if present, includes â€œprimary.â€ If the beginning of such reception does not occur during the first slot time following a SIFS, then:32 â€” If the transmitting STA is the HC, it may initiate recovery by transmitting at the TxPIFS slot boundary after the end of the HCâ€™s last transmission only if the PHY-CCA state indicates IDLE during the CCAdel period preceding the TxPIFS slot boundary as shown in 10-19. â€” If the transmitting STA is a non-AP QoS STA, and there is an MPDU for transmission, it shall initiate recovery by transmitting at a PIFS after the end of the last transmission if the PHY-CCA state indicates IDLE during the CCAdel period preceding the TxPIFS slot boundary, the polled TXOP limit is nonzero and at least one frame (re)transmissions can be completed within the remaining duration of a nonzero polled TXOP limit. 32 This restriction is intended to avoid collisions due to inconsistent CCA reports in different STAs, not to optimize the bandwidth usage efficiency. 1394 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If the transmitted frame is not of type QoS (+)CF-Poll and the expected response frame is not received correctly, regardless of the occurrence of the PHY-RXSTART.indication primitive, the QoS STA may initiate recovery following the occurrence of PHY-CCA.indication(IDLE) primitive so that a SIFS occurs between the last energy on the WM and the transmission of the recovery frame. When there is a transmission failure within a polled TXOP, the long or short retry counter (as described in 10.22.2.11) corresponding to the AC of the failed MSDU or MMPDU shall be incremented. An MPDU belonging to a TC is subject to the respective retry limit as well as the dot11EDCATableMSDULifetime and is discarded when either of them is exceeded. An MPDU belonging to a TS with a specified delay bound is subject to delay bound and is discarded if the MPDU could not be transmitted successfully since it has been delivered to the MAC. An MPDU belonging to a TS with an unspecified delay is subject to dot11MaxTransmitMSDULifetime and is discarded when it is exceeded. Non-AP STAs that receive a QoS (+)CF-Poll frame shall respond within a SIFS, regardless of the NAV setting. If a response is not received but a PHY-CCA.indication(BUSY) primitive occurs during the slot following a SIFS and is followed by a PHY-RXSTART.indication or PHY-RXEND.indication primitive prior to a PHY-CCA.indication(IDLE) primitive, then the HC assumes that the transmitted QoS (+)CF-Poll frame was received by the polled STA. In the cases of QoS Data +CF-Poll, QoS Data +CF-Ack +CF-Poll, or QoS CF-Ack +CF-Poll, the PHY-CCA.indication(BUSY) primitive is used only to determine whether the transfer of control of the channel has been successful. The PHY-CCA.indication(BUSY) primitive is not used for determining the success or failure of the transmission. If the CF-Poll is piggybacked onto a QoS Data frame, the HC may have to retransmit that QoS Data frame subsequently. If an HC receives a frame from a STA with a duration/ID covering only the response frame, the HC shall assume that the STA is terminating its TXOP, and the HC may initiate other transmissions, send a CF-End frame (see 10.22.3.4), or allow the channel to go into the CP. If a polled QoS STA has no queued traffic to send or if the MPDUs available to send are too long to be transmitted within the specified TXOP limit, the QoS STA shall send a QoS (+)Null frame. In the case of no queued traffic, this QoS (+)Null frame shall have a QoS Control field that reports a queue size of 0 for any TID with the duration/ID set to the time required for the transmission of one Ack frame, plus one SIFS. In the case of insufficient TXOP size, such as when the maximum MSDU size is not specified, this QoS (+)Null frame shall have a QoS Control field that contains the TID and TXOP duration or a nonzero queue size needed to send the MPDU that is ready for transmission. When a queue size is transmitted, the HC shall combine the queue size information with the rate of the received QoS (+)Null frame to determine the required size of the requested TXOP. Within a polled TXOP, the unused portion of TXOPs shall not be used by the STA and may be reallocated by the HC as follows: a) The recipient of the final frame, with the Ack Policy subfield equal to Normal Ack, shall be the HC if there will be time remaining in the TXOP after the transmission of the final frame and its expected Ack frame. If there are no frames to be sent to the HC, then the QoS STA shall send to the HC a QoS Null with the Queue Size subfield in the QoS Control field set to 0. 1) If a PHY-CCA.indication(BUSY) primitive occurs at the STA that is expecting the Ack frame during the first slot following a SIFS after the end of the transmission of the final frame, it shall be interpreted as indicating that the channel control has been successfully transferred and no further frames shall be transmitted by the STA in the TXOP, even though the Ack frame from HC may be incorrectly received.33 2) If the beginning of the reception of an expected Ack frame to the final frame does not occur, detected as the nonoccurrence of the PHY-CCA.indication(BUSY) primitive at the QoS STA 33 Note that while the PHY-CCA.indication(BUSY) primitive is used in this instance to determine the control of the channel, it is not used for determining the success or failure of the transmission. 1395 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications that is expecting the response during the first slot time following a SIFS, the QoS STA shall retransmit the frame or transmit a QoS Null frame, with the Ack Policy subfield set to Normal Ack and the Queue Size subfield set to 0, after PIFS from the end of last transmission, until such time that it receives an acknowledgment or when there is not enough time remaining in the TXOP for sending such a frame.34 b) If there is not enough time within the unused portion of the TXOP to transmit either the QoS Null frame or the frame with the Duration/ID field covering only the response frame, then the STA shall cease control of the channel.35 10.22.3.3 HCCA TXOP structure and timing Any QoS Data frame of a subtype that includes CF-Poll contains a TXOP limit in its QoS Control field. The ensuing polled TXOP is protected by the NAV set by the Duration field of the frame that contained the QoS (+)CF-Poll function, as shown in Figure 10-30. Within a polled TXOP, a STA may initiate the transmission of one or more frame exchange sequences, with all such sequences nominally separated by a SIFS. The STA shall not initiate transmission of a frame unless the transmission and any acknowledgment or other immediate response expected from the peer MAC entity are able to complete prior to the end of the remaining TXOP duration. All transmissions, including response frames, within the polled TXOP are considered to be the part of the TXOP, and the HC shall account for these when setting the TXOP limit. If the TXOP Limit subfield in the QoS Control field of the QoS Data frame that includes CF-Poll is equal to 0, then the STA to which the frame is directed to shall respond with either one MPDU or one QoS Null frame. A TXOP or transmission within a TXOP shall not extend across TBTT, dot11CFPMaxDuration (if during CFP), or dot11CAPLimit. The HC shall verify that the full duration of any granted TXOP meets these requirements so that a STA may use the time prior to the TXOP limit of a polled TXOP without checking for these constraints. Subject to these limitations, all decisions regarding what MSDUs, A-MSDUs, and/or MMPDUs are transmitted during any given TXOP are made by the STA that holds the TXOP.36,37 TXOP limit from QoS CF-Poll TXOP granted by QoS CF -Poll QoS CF-Poll NAV from QoS CF-Poll Figure 10-30â€”Polled TXOP 34 This is to avoid the situation where the HC might not receive the frame and might result in an inefficient use of the channel. 35Inthis case the channel is not accessed until the NAVs expire at all of the STAs. 36In certain regulatory domains, channel sensing needs to be done at periodic intervals (for example, in Japan, this period is 4 ms). This means that the duration of a TXOP in these regulatory domains might not be more than this periodic interval. In order to extend the TXOP beyond the limit implied by this periodic interval, the TXOP holder needs to sense the channel at least once in the limit imposed in the regulatory domain, by waiting for at least for the duration of one PIFS during which it senses the channel. If it does not detect any energy, it may continue by sending the next frame. In other words, the total TXOP size assigned should include an extra time allocated (i.e., n Ã— aSlotTime, where n is the number of times the STA needs to sense the channel) and is given by TXOP limit limit imposed in the regulatory domain . 37 The TID value in the QoS Control field of a QoS Data +CF-Poll frame pertains only to the MSDU or fragment thereof in the Frame Body field of that frame. This TID value does not pertain to the TXOP limit value and does not place any constraints on what frame(s) the addressed STA may send in the granted TXOP. 1396 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.22.3.4 NAV operation of a TXOP under HCCA An HC shall set its own NAV to prevent it from transmitting during a TXOP that it has granted to a STA through an HCCA poll. However, the HC may reclaim the TXOP if a STA is not using it or ends the TXOP early (see 10.22.3.2.4). In a CFP or CP, if the HC has no more STAs to poll and it has no more Data, Management, BlockAckReq, or BlockAck frames to send, it may reset the NAVs of all QoS STAs in the BSS by sending a QoS CF-Poll frame with the RA matching its own MAC address and with the Duration/ID field set to 0. When the AP contains a PC, during the CFP, it may reset the NAVs of all receiving STAs by sending a CF-End frame, regardless of how the NAVs have been originally set. A STA that receives a QoS (+)CF-Poll frame with a MAC address in the Address 1 field that matches the HCâ€™s MAC address and the Duration/ID field value equal to 0 shall reset the NAV value to 0. NOTEâ€”A STA resets its NAV when it receives a CF-End or CF-End +CF-Ack frame according to the procedures described in 10.4.3.3. When a STA receives a QoS (+)CF-Poll frame containing the BSSID of the BSS in which the STA is associated, that STA shall update the NAV if necessary and shall save the TXOP holder address for that BSS, which is the MAC address from the Address 1 field of the frame containing the QoS (+)CF-Poll. If an RTS frame is received with the RA address matching the MAC address of the STA and the MAC address in the TA field in the RTS frame matches the saved TXOP holder address, then the STA shall send the CTS frame after SIFS, without regard for, and without resetting, its NAV. The saved TXOP holder address shall be cleared when the NAV is reset or when the NAV counts down to 0. When a STA receives a frame addressed to it and requires an acknowledgment, it shall respond with an Ack or QoS +CF-Ack frame independent of its NAV. A non-AP STA shall accept a polled TXOP by initiating a frame exchange sequence independent of its NAV. 10.22.3.5 HCCA transfer rules 10.22.3.5.1 General A TXOP obtained by receiving a QoS (+)CF-Poll frame uses the specified TXOP limit consisting of one or more frame exchange sequences with the sole time-related restriction being that the final sequence shall end not later than the TXOP limit. In QoS CF-Poll and QoS CF-Ack +CF-Poll frames, the TID subfield in the QoS Control field indicates the TS for which the poll is intended. The requirement to respond to that TID is nonbinding, and a STA may respond with any frame. Upon receiving a QoS (+)CF-Poll frame, a STA may send any frames, i.e., QoS Data frames belonging to any TID as well as Management frames in the obtained TXOP. MSDUs may be fragmented in order to fit within TXOPs. The QoS CF-Poll frames shall be sent only by an HC. Non-AP STAs are not allowed to send QoS (+)CF-Poll frames. A STA shall not send QoS (+)Data frames in response to any Data frame other than the QoS (+)CF- Poll frames. The TXOP limit is inclusive of the PHY and IFS overhead, and an AP should account for the overhead when granting TXOPs. If a STA has set up at least one TS for which the Aggregation subfield in the associated TSPEC is equal to 0, the AP shall use only QoS CF-Poll or QoS CF-Ack +CF-Poll frames to poll the STA and shall never use QoS (+)Data +CF-Poll to poll the STA. Note that although QoS (+)CF-Poll is a Data frame, but it should be transmitted at one of the rates in the BSSBasicRateSet parameter in order to set the NAV of all STAs that are not being polled (see 10.7). If a CF-Poll is piggybacked with a QoS Data frame, then the frame containing all 1397 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications or part of an MSDU or A-MSDU may be transmitted at a rate that is below the negotiated minimum PHY rate in the TSPEC related to that data. A QoS STA shall use QoS Data frames for all MSDU transfers to another QoS STA. The TID in the QoS Control fields of these frames shall indicate the TC or TS to which the MPDU belongs. Furthermore, either the Queue Size subfield shall indicate the amount of queued traffic present in the output queue that the STA uses for traffic belonging to this TC or TS, or the TXOP Duration Requested subfield shall indicate the duration that the STA requests for use in the next TXOP for traffic belonging to this TC or TS. The queue size value reflects the amount on the appropriate queue not including the present MPDU. The queue size value may remain constant in all QoS Data frames that carry fragments of the same MSDU even if the amount of queued traffic changes as successive fragments are transmitted. In order to inform the HC of queue status, a STA may use the QoS Null frame indicating the TID and the queue size or TXOP duration request (also see 10.22.3.5.2). A QoS STA shall be able to receive QoS +CF-Ack frames. The HC may use QoS Data +CF-Ack frames to send frames to the same STA a SIFS after receiving the final transmission of the previous TXOP. The HC may also use QoS Data +CF-Ack frames to send frames to any other STA a SIFS after receiving the final transmission of the previous TXOP, if the STA that sent the final transmission of the previous TXOP has set the Q-Ack subfield in the QoS Capability element in the (Re)Association Request frame to 1. In both CFP and CP, a STA shall respond to QoS Data frames having the Ack Policy subfield in the QoS Control field equal to Normal Ack with an Ack frame, unless the acknowledgment is piggybacked in which case it shall use a QoS +CF-Ack frame. Piggybacked frames are allowed only in CFP or within TXOPs initiated by the HC. The HC shall not send a QoS Data frame containing a +CF-Ack with an Address 1 that does not correspond to the address of the STA for which the +CF-Ack is intended, unless the STA to which the +CF-Ack is intended, sets the Q-Ack subfield in the QoS Capability element in the (Re)Association Request frame. STAs are not required to be able to transmit QoS Data frames with subtypes that include +CF-Ack. An AP that has dot11QAckOptionImplemented true may allow associations with STAs advertising support for the Q-Ack option. Such associations do not require the AP to employ piggyback acknowledgments directed toward that associated STA in frames that are not directed to that associated STA. A QoS STA shall be able to process received QoS Data frames with subtypes that include +CF-Ack when the STA to which the acknowledgment is directed is the same as the STA addressed by the Address 1 field of that Data frame. A STA that does not set the Q-Ack subfield to 1 in the QoS Capability element in the (Re)Association Request frame is not required to handle the received QoS (+)Data +CF-Ack frames that are addressed to other STAs. The net effect of these restrictions on the use of QoS +CF-Ack frames is that the principal QoS +CF-Ack subtype that is useful is the QoS Data +CF-Ack frame, which can be sent by a STA as the first frame in a polled TXOP when that TXOP was conveyed in a QoS Data +CF-Poll (+CF-Ack) frame and the outgoing frame is directed to the HCâ€™s STA address. QoS (Data +)CF-Poll +CF-Ack frames are useful to allow the HC to grant another TXOP to the same STA a SIFS after receiving the final transmission of that STAâ€™s previous TXOP. QoS (Data+)CF-Poll +CF-Ack frames are also useful to allow the HC to grant another TXOP to a different STA a SIFS after receiving the final transmission of a STAâ€™s previous TXOP, if the STA that sent the final transmission of the previous TXOP has set the Q-Ack subfield in the QoS Capability element in the (Re)Association Request frame to 1. HCF contention based channel access shall not be used to transmit MSDUs belonging to an established TS (with the HCâ€™s acceptance of the associated TSPEC), unless the granted TSPEC indicates it is permitted to do so when the Access Policy subfield of the TS Info field is equal to â€œHCCA, EDCA mixed modeâ€ (HEMM), the polled STA utilized the full TXOP provided by the HC, and it has more MPDUs to send. When this STA sends frames belonging to a TS using contention based channel access, it shall encode the TID subfield in the QoS Data frame with the TID associated with the TS. When the AP grants a TSPEC with the Access Policy subfield equal to HEMM and if the corresponding AC needs admission control, the AP shall include the medium time that specifies the granted time for EDCA access in the ADDTS Response frame. 1398 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.22.3.5.2 TXOP requests STAs may send TXOP requests during polled TXOPs or EDCA TXOPs using the QoS Control field in a QoS Data frame or a QoS Null frame directed to the HC, with the TXOP Duration Requested or Queue Size subfield value and TID subfield value indicated to the HC. APs indicate whether they process TXOP request or queue size in the QoS Info field in the Beacon, Probe Response, and (Re)Association Response frames. An AP shall process requests in at least one format. The AP may reallocate TXOPs if the request belongs to TS or update the EDCA parameter set if the above request belongs to TC. A STA shall use only the request format that the AP indicates it can process. TXOP Duration Requested subfield values are not cumulative. A TXOP duration requested for a particular TID supersedes any prior TXOP duration requested for that TID. A value of 0 in the TXOP Duration Requested subfield may be used to cancel a pending unsatisfied TXOP request when its MSDU is no longer queued for transmission. The TXOP duration requested is inclusive of the PHY and IFS overhead, and a STA should account for this when attempting to determine whether a given transmission fits within a specified TXOP duration. The AP may choose to assign a TXOP duration shorter than that requested in the TXOP Duration Requested subfield. Even if the value of TXOP Duration Requested subfield or Queue Size subfield in a QoS Data frame is 0, the HC shall continue to poll according to the negotiated schedule. 10.22.3.5.3 Use of RTS/CTS In order to provide improved NAV protection, a STA may send an RTS frame as the first frame of any frame exchange sequence, during either the CP or CFP, and without regard for dot11RTSThreshold.38 If a QoS STA sends an RTS frame and does not receive an expected CTS frame, then the recovery rules are as specified in 10.22.3.2.4. In order to provide NAV protection for a transmission to the AP in response to a QoS Data frame with a subtype that includes CF-Poll, the polled STA may send a CTS frame with the RA containing its own MAC. NOTE 1â€”The CTS frame is shorter than a QoS Data frame and has a higher probability that it will be received by other STAs. NOTE 2â€”The transmission of the CTS sets the NAV in its own vicinity without the extra time required to send an RTS frame.39 10.22.3.5.4 HCCA transfer rules for a VHT STA A VHT STA that is a member of a BSS that supports multiple channel widths is granted a TXOP for a specified duration and for a channel width that is equal to the channel width of the frame containing the QoS CF-Poll. 38The sending of an RTS frame during the CFP is usually unnecessary, but might be used to confirm that the addressed recipient QoS STA is within range and awake and to elicit a CTS frame response that sets the NAV at STAs in the vicinity of the addressed recipient. This is useful when there are nearby STAs that are members of other BSSs and are out of range to receive Beacon frames from this BSS. Sending an RTS frame during the CFP is useful only when the recipient is a QoS STA, because a non-QoS STA in the same BSS has its NAV set to protect the CFP, which renders those non-QoS STAs unable to respond. Using the same duration calculation during the CFP as specified for the CP is directly applicable for all cases except when the RTS frame is sent by the HC and the following frame includes a QoS (+)CF-Poll. 39 This is unnecessary because the NAVs in the vicinity of the QoS AP were set by the QoS (+)CF-Poll frame. 1399 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.22.4 Admission control at the HC 10.22.4.1 General An IEEE 802.11 network may use admission control to administer policy or regulate the available bandwidth resources. Admission control is used to attempt to provide a guarantee of the amount of time that a STA has available to access the channel. The HC, which is in the AP, is used to administer admission control in the network. As the QoS facility supports two access mechanisms, there are two distinct admission control mechanisms: one for contention based access and another for controlled access. Admission control, in general, depends on vendorsâ€™ implementation of the scheduler, available channel capacity, link conditions, retransmission limits, and the scheduling requirements of a given stream. All of these criteria affect the admissibility of a given stream. If the HC has admitted no streams that require polling, it might not find it necessary to perform the scheduler or related HC functions. 10.22.4.2 Contention based admission control procedures 10.22.4.2.1 General A non-AP STA may support admission control procedures in 10.22.4.2.3 to send frames in the AC where admission control is mandated; but, if it does not support that procedure and dot11RejectUnadmittedTraffic is false or not present, it shall use EDCA parameters of a lower priority AC, as indicated in Table 10-1, that does not require admission control. When a STA uses the EDCA parameters of a lower AC for this purpose, it affects only the EDCA parameters used for channel access, i.e., it has no effect on the contents of the transmitted frame. An AP shall support admission control procedures, at least to the minimal extent of advertising that admission is not mandatory on its ACs. The AP uses the ACM (admission control mandatory) subfields advertised in the EDCA Parameter Set element to indicate whether admission control is required for each of the ACs. While the CWmin, CWmax, AIFS, and TXOP limit parameters may be adjusted over time by the AP, the ACM bit shall be static for the duration of the lifetime of the BSS. A STA shall transmit an ADDTS Request frame to the HC in order to request admission of traffic in any direction (i.e., uplink, downlink, direct, or bidirectional) employing an AC that requires admission control. The ADDTS Request frame shall contain the UP associated with the traffic and shall indicate EDCA as the access policy. The AP shall associate the received UP of the ADDTS Request frame with the appropriate AC per the UP-to-AC mappings described in 10.2.4.2. The STA may transmit unadmitted traffic for the ACs for which the AP does not require admission control. If dot11RejectUnadmittedTraffic is false, a STA may send data without admission control for an AC that mandates admission control by using the EDCA parameters that correspond to a lower priority AC that does not require admission control. When a STA uses a lower priority AC for this purpose, the lower priority AC affects only the EDCA parameters used for channel access, i.e., it has no effect on the contents of the transmitted frame. All ACs with priority higher than that of an AC with an ACM flag equal to 1 should have the ACM flag set to 1. The HC contained within an AP when dot11SSPNInterfaceActivated is true shall admit a non-AP STAâ€™s request based on dot11NonAPStationAuthAccessCategories stored in that non-AP STAâ€™s dot11InterworkingEntry, which is part of the dot11InterworkingTable. The dot11InterworkingEntry specifies the EDCA access classes and throughput limitations on each access class for which a non-AP STA is permitted to transmit. 10.22.4.2.2 Procedures at the AP Regardless of the ACâ€™s ACM setting, the AP shall respond to an ADDTS Request frame with an ADDTS Response frame that may be to accept or deny the request. On receipt of an ADDTS Request frame from a non- AP STA, the AP shall make a determination about whether to: a) Accept the request, or b) Deny the request. 1400 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The algorithm used by the AP to make this determination is implementation dependent. An AP when dot11SSPNInterfaceActivated is true shall use the policies delivered by the SSPN that are stored in the dot11InterworkingEntry, which is part of the dot11InterworkingTable. If the AP decides to accept the request, the AP shall also derive the medium time from the information conveyed in the TSPEC element in the ADDTS Request frame. The AP may use any algorithm in deriving the medium time, but K.2.2 provides a procedure that may be used. Having made such a determination, the AP shall transmit a TSPEC element to the requesting non-AP STA contained in an ADDTS Response frame. If the AP is accepting the request, the Medium Time field shall be specified. If the AP is accepting a request for a downlink TS, the Medium Time field shall be set to 0. If the AP is accepting a request corresponding to an AC for which ACM is 0 (e.g., the TSPEC is to change APSD behavior), the Medium Time field shall be set to 0. 10.22.4.2.3 Procedure at non-AP STAs Each EDCAF shall maintain two variables: admitted_time and used_time. The admitted_time and used_time shall be set to 0 at the time of (re)association. The STA may subsequently decide to explicitly request medium time for the AC that is associated with the specified priority. In order to make such a request, the STA shall transmit a TSPEC element contained in an ADDTS Request frame with the following fields specified (i.e., nonzero): Nominal MSDU Size, Mean Data Rate, Minimum PHY Rate, Inactivity Interval, and Surplus Bandwidth Allowance. The Medium Time field is not used in the request frame and shall be set to 0. On receipt of a TSPEC element contained in an ADDTS Response frame indicating that the request has been accepted, the STA shall recompute the admitted_time for the specified EDCAF as follows: admitted_time = admitted_time + dot11EDCAAveragingPeriod Ã— medium time of TSPEC. The STA may choose to tear down the explicit request at any time. For the teardown of an explicit admission, the STA shall transmit a DELTS frame containing the TSID and direction that specify the TSPEC to the AP. If the STA sends or receives a DELTS frame, it shall recompute the admitted_time for the specified EDCAF as follows: admitted_time = admitted_time â€“ dot11EDCAAveragingPeriod Ã— medium time of TSPEC. To describe the behavior at the STA, two parameters are defined. The parameter used_time signifies the amount of time used, in units of 32 s, by the STA in dot11EDCAAveragingPeriod. The parameter admitted_time is the medium time allowed by the AP, in units of 32 s, in dot11EDCAAveragingPeriod. The STA shall update the value of used_time: a) At dot11EDCAAveragingPeriod second intervals used_time = max((used_time â€“ admitted_time), 0) b) After each successful or unsuccessful MPDU (re)transmission attempt, used_time = used_time + MPDUExchangeTime The MPDUExchangeTime equals the time required to transmit the MPDU sequence. For the case of an MPDU transmitted with Normal Ack policy and without RTS/CTS protection, this equals the time required to transmit the MPDU plus the time required to transmit the expected response frame plus one SIFS. Frame exchange sequences for Management frames are excluded from the used_time update. If the used_time value reaches or exceeds the admitted_time value, the corresponding EDCAF shall no longer transmit QoS Data frames or QoS Null MPDUs using the EDCA parameters for that AC as specified in the QoS Parameter Set element. However, a STA may choose to temporarily replace the EDCA parameters for that EDCAF with those specified for an AC of lower priority, if no admission control is required for those ACs. 1401 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NOTEâ€”When a frame is transmitted using temporary EDCA parameters, the TID field of that frame is not modified. If, for example, a STA has made and had accepted an explicit admission for a TS and the channel conditions subsequently worsen, possibly including a change in PHY data rate so that it requires more time to send the same data, the STA may make a request for more admitted_time to the AP and at the same time downgrade the EDCA parameters for that AC for short intervals in order to send some of the traffic at the admitted priority and some at the unadmitted priority, while waiting for a response to the admission request. 10.22.4.3 Controlled-access admission control This subclause describes the schedule management of the admitted HCCA streams by the HC. When the HC provides controlled channel access to STAs, it is responsible for granting or denying polling service to a TS based on the parameters in the associated TSPEC. If the TS is admitted, the HC is responsible for scheduling channel access to this TS based on the negotiated TSPEC fields. The HC should not initiate a modification of TSPEC fields of an admitted TS unless requested by the STA. The HC should not tear down a TS unless explicitly requested by the STA or at the expiration of the inactivity timer. The polling service based on admitted TS provides a â€œguaranteed channel accessâ€ from the scheduler in order to have its QoS requirements met. This is an achievable goal when the WM operates free of external interference (such as operation within the channel by other technologies and co-channel overlapping BSS interference). The nature of wireless communications may preclude absolute guarantees to satisfy QoS requirements. The following are rules for the operation of the scheduler: â€” The scheduler shall be implemented so that, under controlled operating conditions, all STAs with admitted TS are offered TXOPs that satisfy the service schedule. â€” Specifically, if a TS is admitted by the HC, then the scheduler shall service the STA during an SP. An SP is a period of time during which a set of one or more downlink individually addressed frames and/or one or more polled TXOPs are granted to the STA. An SP starts at fixed intervals of time specified in Service Interval field. The first SP starts when the lower order 4 octets of the TSF timer equals the value specified in Service Start Time field.40 Additionally, the minimum TXOP duration shall be at least the time to transmit one maximum MSDU size successfully at the minimum PHY rate specified in the TSPEC. If maximum MSDU size is not specified in the TSPEC, then the minimum TXOP duration shall be at least the time to transmit one nominal MSDU size successfully at the minimum PHY rate. The vendors are free to implement any optimized algorithms, such as reducing the polling overheads, increasing the TXOP duration, etc., within the parameters of the transmitted schedule. â€” The HC shall admit its request based on Infrastructure Authorization Information in dot11InterworkingEntry, which is part of the dot11InterworkingTable. The dot11InterworkingEntry specifies whether a non-AP STA is permitted to use HCCA, its throughput limitation and its minimum delay bound. When the HC aggregates the admitted TS, it shall set the Aggregation field in the granted TSPEC to 1. An AP shall schedule the transmissions in HCCA TXOPs and communicate the service schedule to the STA. The HC shall provide an aggregate service schedule if the STA sets the Aggregation field in its TSPEC request. If the AP establishes an aggregate service schedule for a STA, it shall aggregate all HCCA streams for the STA. The service schedule is communicated to the STA in a Schedule element contained in an ADDTS Response frame. In the ADDTS Response frame, the modified service start time shall not exceed the requested service start time, if specified in ADDTS Request frame, by more than one maximum service interval (SI). The HC uses the maximum SI for the initial scheduling only as there might be situations that HC is not be able to service the TS at the scheduled timing, due to an EDCA or DCF transmission or other interferences interrupting the schedule. 40 The lower order 4 octets of the TSF timer cover a span of around 71 min. Due to TSF timer wrapover and due to the possibility of receiving the schedule frame after the indicated start time timer, ambiguity may occur. This ambiguity is resolved by using the nearest absolute TSF timer value in past or future when the lower order 4 octets match the Start Time field in the Schedule element. 1402 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Service Interval field value in the Schedule element shall be greater than the minimum SI. The service schedule could be subsequently updated by an AP as long as it meets TSPEC requirements. The HC may update the service schedule at any time by sending a Schedule element in a Schedule frame. The updated schedule is in effect when the HC receives the Ack frame for the Schedule frame. The service start time in the Schedule element in the Schedule frame shall not exceed the beginning of the immediately previous SP by more than the maximum SI. The service start time shall not precede the beginning of the immediately previous SP by more than the minimum SI. A STA may affect the service schedule by modifying or deleting its existing TS as specified in 11.4. K.3.1 provides guidelines for deriving an aggregate service schedule for a single STA from the STAâ€™s admitted TS. The schedule shall meet the QoS requirements specified in the TSPEC. During any time interval [t1, t2] including the interval that is greater than the specification interval, the cumulative TXOP duration shall be greater than the time required to transmit all MSDUs (of nominal MSDU size) arriving at the mean data rate for the stream, over the period [t1, t2 â€“ D]. The parameter D is set to the specified maximum SI in the TSPEC. If maximum SI is not specified, then D is set to the delay bound in the TSPEC. The HC shall use the minimum PHY rate in calculating TXOPs if the minimum PHY rate is present in the TSPEC field in the ADDTS response. Otherwise, the HC may use an observed PHY rate in calculating TXOPs. A STA may have an operational rate lower than the minimum PHY rate due to varying conditions on the channel for a short time and still may be able to sustain the TS without changing the minimum PHY rate in the TSPEC. A minimum set of TSPEC fields shall be specified during the TSPEC negotiation. The specification of a minimum set of parameters is required so that the scheduler can determine a schedule for the stream that is to be admitted. These parameters are Mean Data Rate, Nominal MSDU Size, Minimum PHY Rate, Surplus Bandwidth Allowance, and at least one of Maximum Service Interval and Delay Bound in the ADDTS Request frame. In the ADDTS Response frame, these parameters are Mean Data Rate, Nominal MSDU Size, Minimum PHY Rate, Surplus Bandwidth Allowance, and Maximum Service Interval and shall be nonzero when a stream is admitted. If any of the elements in the minimum set of parameters does not have the required nonzero value, as specified above in this subclause, in the ADDTS Request frame, the HC may replace the unspecified parameters with nonzero values and admit the stream, or it may reject the stream. If the HC admits the stream with the alternative set of TSPEC fields, these parameters are indicated to the STA through the ADDTS Response frame. If both maximum SI and delay bound are specified, the HC may use only the maximum SI. If any other parameter is specified in the TSPEC element, the scheduler may use it when calculating the schedule for the stream. The HC may also use the UP value in the TS Info field for admission control or scheduling purposes; however, this decision is outside the scope of this standard. The mandatory set of parameters might be set by any higher layer entity or may be generated autonomously by the MAC. If a STA specifies a nonzero minimum SI and if the TS is admitted, the HC shall generate a schedule that conforms to the specified minimum SI. A reference design for a sample scheduler and admission control unit is provided in Annex K. A sample use of the TSPEC for admission control is also described in Annex K. 1403 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.23 Mesh coordination function (MCF) 10.23.1 General Under MCF, the basic unit of allocation of the right to transmit onto the WM is the TXOP. Each TXOP is defined by a starting time and a defined maximum length. There are two types of TXOP in MCF: EDCA TXOPs and MCCA TXOPs. The EDCA TXOP is obtained by a mesh STA winning an instance of EDCA contention (see 10.22.2). The MCCA TXOP is obtained by a mesh STA gaining control of the WM during an MCCAOP. The MCCAOP is an interval of time for frame transmissions that has been reserved by means of the exchange of MCCA frames (see 10.23.3). EDCA TXOPs of a mesh STA that has dot11MCCAActivated true shall not overlap with the time periods of any of its tracked MCCAOP reservations. The process of tracking MCCAOP reservations involves the recording of the MCCAOP reservations and the data that structure the MCCAOP advertisements of these reservations, namely the advertisement set sequence number, advertisement elements bitmap, and the advertisement element indexes, in a local database, and the updating of this database on the basis of received advertisements as described in 10.23.3.7.5. 10.23.2 MCF contention based channel access MCF implements the same EDCA (see 10.22.2) as does HCF. 10.23.3 MCF controlled channel access (MCCA) 10.23.3.1 General MCF controlled channel access (MCCA) is an optional access method that allows mesh STAs to access the WM at selected times with lower contention than would otherwise be possible. This standard does not require all mesh STAs to use MCCA. MCCA might be used by a subset of mesh STAs in an MBSS. However, MCCAOP reservations may be set up among mesh STAs that have dot11MCCAActivated true and that operate on the same channel; MCCAOP reservations shall not be set up otherwise. The performance of MCCA might be impacted by STAs that do not respect MCCAOP reservations. MCCA enabled mesh STAs use Management frames to make reservations for transmissions. The mesh STA transmitting an MCCA Setup Request frame to initiate a reservation becomes the MCCAOP owner of the MCCAOP reservation. The receivers of the MCCA Setup Request frame are the MCCAOP responders. The MCCAOP owner and the MCCAOP responders advertise this MCCAOP reservation to their neighbors via an MCCAOP advertisement. An MCCA enabled neighbor mesh STA shall not transmit during these reserved MCCAOP time periods. During its MCCAOP, the MCCAOP owner obtains a TXOP by winning an instance of EDCA contention. Because of its reservation, the MCCAOP owner experiences no competition from other MCCA enabled neighbor mesh STAs. At the start of an MCCAOP, the EDCAF of the MCCAOP owner replaces the AIFSN, CWmin, and CWmax value of its dot11EDCATable with MCCA access parameters. In order to use MCCA, a mesh STA maintains synchronization with its neighboring mesh STAs. Mesh STAs that use MCCA shall use a DTIM interval with a duration of 2n 100 TU with n being a non-negative integer less than or equal to 17. Additionally, a mesh STA shall track the reservations of its neighboring mesh STAs. 1404 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NOTE 1â€”The DTIM interval of this form was chosen so that the starting times of the reservations do not change relative to each other between consecutive DTIM intervals. The restriction that n be less than or equal to 17 was chosen for compatibility with the maximum DTIM interval as well as the compatibility of the reservationâ€™s MCCAOP offset range (see 9.4.2.106.2) with the maximal DTIM interval length. NOTE 2â€”It is allowed that a different value for the DTIM interval is used for mesh STAs that use MCCA in an MBSS that is centrally controlled and the central authority provides a coordination of the DTIM interval of the mesh STAs that use MCCA in the MBSS. 10.23.3.2 MCCA activation When it receives an MLME-ACTIVATEMCCA.request primitive from its SME, a mesh STA shall set the MCCA Enabled subfield of the Mesh Capability field in the Mesh Configuration element to 1 in Beacon and Probe Response frames it transmits. It shall not initiate or accept MCCA Setup Request frames for dot11MCCAScanDuration TUs after the receipt of the MLME-ACTIVATEMCCA.request primitive. During the dot11MCCAScanDuration waiting period, the mesh STA learns its neighborhood MCCAOP periods by receiving Beacon, Probe Response, or MCCA Advertisement frames from neighboring mesh STAs. After this period, the mesh STA may initiate and accept MCCA Setup Request frames as per 10.23.3.6. 10.23.3.3 MCCAOP reservations An MCCAOP reservation specifies a schedule for frame transmissions. The time periods scheduled for frame transmissions in the reservation are called MCCAOPs. The schedule is set up between an MCCAOP owner and one (for individually addressed frames) or more (for group addressed frames) MCCAOP responders. MCCAOPs are set up by means of the procedure defined in 10.23.3.6. Once an MCCAOP reservation is set: â€” Access to the channel by MCCA enabled mesh STAs is governed by the procedures in 10.23.3.9. â€” The MCCAOP reservation is advertised according to the procedures in 10.23.3.7. The schedule is defined by means of the MCCAOP Reservation field defined in 9.4.2.106.2. An MCCAOP reservation schedules a series of MCCAOPs with a common duration given in the MCCAOP Duration subfield of the MCCAOP Reservation field. This series is started after the first DTIM Beacon following the successful completion of the MCCAOP setup procedure and terminated when the MCCAOP reservation is torn down. The reservation defines a regular schedule of MCCAOPs in the DTIM interval of the MCCAOP owner. The number of MCCAOPs in the DTIM interval is given by the value of the MCCAOP Periodicity subfield of the MCCAOP Reservation field. The MCCAOP Offset subfield specifies the offset of the first scheduled MCCAOP of the transmission schedule relative to the beginning of the DTIM interval of the MCCAOP owner. The following MCCAOPs are separated by a time interval with a duration equal to the length of the DTIM period divided by the value in the MCCAOP Periodicity subfield. An example of an MCCAOP reservation schedule is shown in Figure 10-31. In this example, the MCCAOP Periodicity equals two, so that there are two MCCAOPs in each DTIM interval. As further illustrated in the figure, the MCCAOP Offset value indicates the beginning of the first MCCAOP in each DTIM interval. If a mesh STA adjusts its TBTT, e.g., in response to a TBTT adjustment request, it shall adjust the MCCAOP reservations by modifying the MCCAOP Offset of each MCCAOP reservation. 1405 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DTIM Interval DTIM Interval MCCAOP (DTIM Duration) / Offset (MCCAOP Periodicity) t MCCAOP Duration MCCAOP Figure 10-31â€”Example MCCAOP reservation with MCCAOP Periodicity equal to 2 An MCCAOP reservation is identified by an MCCAOP reservation ID. The MCCAOP owner shall select an MCCAOP reservation ID that is unique among all of its MCCAOP reservations. The MCCAOP reservation ID and MAC address of the MCCAOP owner uniquely identify the MCCAOP reservation in the mesh BSS. The MCCAOP reservation ID is an 8-bit unsigned integer and included in the MCCAOP Reservation ID field of an MCCAOP Setup Request element. If this MCCAOP setup request is for an individually addressed transmission, the MCCAOP Reservation ID is between 0 and 127. If this MCCAOP setup request is for a group addressed transmission, the MCCAOP Reservation ID is between 128 and 254. The value 255 is not used to identify a specific MCCAOP reservation but is reserved for usage in the MCCAOP teardown procedure as described in 10.23.3.8. A mesh STA with dot11MCCAActivated equal to true shall be able to track at least dot11MCCAMinTrackStates MCCAOP reservations, including its own reservations. If the number of tracked MCCAOP reservations is less than dot11MCCAMaxTrackStates, the mesh STA shall be able to track, set up, and accept additional reservations. In this case, the mesh STA shall set the Accept Reservations subfield in the Flags field to 1 in the MCCAOP Advertisement Overview elements it transmits. If the number of tracked MCCAOP reservations is greater than or equal to dot11MCCAMaxTrackStates, the mesh STA shall not track, set up, or accept additional reservations. In this case, the mesh STA shall set the Accept Reservations subfield in the Flags field to 0 in the MCCAOP Advertisement Overview elements it transmits. Moreover, it shall reply to MCCA Setup Request frames with an MCCA Setup Reply frame with the MCCA Reply Code field in the MCCAOP Setup Reply element equal to 3: Reject: MCCAOP track limit exceeded. The tracked MCCAOP reservations are advertised as described in 10.23.3.7. How to access the medium during the tracked MCCAOP reservations is specified in 10.23.3.9. 10.23.3.4 Neighborhood MCCAOP periods at a mesh STA The set of MCCAOP reservations in which a mesh STA is involved as an MCCAOP owner or an MCCAOP responder and that are used for individually addressed transmissions are referred to as the TX-RX periods of this mesh STA. The set of MCCAOP reservations in which a mesh STA is involved as an MCCAOP owner or an MCCAOP responder and that are used for group addressed transmissions are referred to as the broadcast periods of this mesh STA. Optionally, the broadcast periods of a mesh STA includes known Target Beacon Transmission Time of Beacon frames for which this mesh STA is either the transmitter or the receiver, and transmission or reception periods of a STA that is collocated with the reporting mesh STA, for example, beacon or HCCA times of a collocated AP. 1406 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The interference periods of a mesh STA comprise the TX-RX periods and the broadcast periods of its neighbor mesh STAs in which the mesh STA is not involved as the owner or as a responder. The TX-RX periods, the broadcast periods, and the interference periods of a mesh STA shall not be used for a new MCCAOP reservation with the mesh STA as transmissions in these periods might experience interference from the transmissions in the new MCCAOPs or might cause interference to them. The interference periods are directly derived from the TX-RX Periods Report field and Broadcast Periods Report field of the MCCAOP Advertisement elements transmitted by the neighbor mesh STAs. The Interference Periods Report field reflects the latest TX-RX Periods Report and Broadcast Periods Report fields received from the neighbor mesh STAs. The MCCAOP reservations of a mesh STA and its neighbors define a set of MCCAOPs that are already reserved for frame transmissions in the mesh neighborhood of a mesh STA. This set of MCCAOPs is referred to as the neighborhood MCCAOP periods for the mesh STA. Thus, neighborhood MCCAOP periods at a mesh STA include all MCCAOPs for which the mesh STA or one of its neighbors, including neighbors from other MBSSs, is either transmitter or receiver. 10.23.3.5 MCCA access fraction (MAF) The MCCA access fraction at a mesh STA is the ratio of the time reserved for MCCAOPs in the DTIM interval of this mesh STA to the duration of the DTIM interval. This parameter is reported in the MCCA Access Fraction field of the MCCAOP Advertisement Overview elements. The maximum value for the MAF that is allowed at a mesh STA is specified by dot11MAFlimit. The dot11MAFlimit is copied into the MAF Limit field of the MCCAOP Advertisement Overview element as described in 9.4.2.108. The MAF and the MAF Limit may be used to limit the use of MCCA in the mesh neighborhood of a mesh STA, as specified in 10.23.3.6. Before attempting to set up an MCCAOP reservation with a neighbor peer mesh STA, a mesh STA shall verify that the new MCCAOP reservation does not cause its MAF to exceed its MAF Limit and that the new MCCAOP reservation does not cause the MAF of any of its neighbor peer mesh STAs to exceed their MAF Limit. An MCCAOP setup request shall be refused by the intended MCCAOP responder if the MAF limit of one of its neighbors is exceeded due to the new setup. 10.23.3.6 MCCAOP setup procedure The setup of an MCCAOP reservation is initiated by the MCCAOP owner and is accepted or rejected by the MCCAOP responder. The setup procedure for an MCCAOP reservation is as follows: a) The MCCAOP owner shall build a map of the neighborhood MCCAOP periods in the DTIM interval after hearing advertisements from all of its neighbor mesh STAs with the MCCA Enabled subfield of the Mesh Capability field in the Mesh Configuration element equal to 1. It shall request an MCCAOP advertisement, as described in 10.23.3.7.8, from each neighbor mesh STA from which no advertisement was heard in the last dot11MCCAAdvertPeriodMax DTIM intervals. b) The MCCAOP owner shall determine the MCCAOP reservation. The MCCAOP parameters shall be chosen in such a way that they satisfy the following conditions: 1) The reservation shall not overlap with the neighborhood MCCAOP periods of the MCCAOP owner. 2) The reservation shall not overlap with the interference periods of the intended MCCAOP responder or responders. 3) The reservation shall not cause the MAF limit to be exceeded for either itself or its neighbor mesh STAs. 4) The Accept Reservations subfield of the Flags field equals 1 in the most recent MCCAOP Advertisement Overview element received from all intended MCCAOP responders. 1407 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications c) If the conditions in item b) are satisfied, the MCCAOP owner shall transmit an MCCAOP Setup Request element to the intended MCCAOP responder with the chosen MCCAOP parameters. d) The MCCAOP responder shall verify the following conditions: 1) The reservation does not overlap with its neighborhood MCCAOP periods. 2) The reservation does not cause the MAF limit to be exceeded for itself or its neighbor mesh STAs. 3) The number of reservations in its neighborhood MCCAOP periods does not exceed dot11MCCAMaxTrackStates. e) If the conditions in item d) are satisfied, the responder shall send an MCCA Setup Reply frame to the MCCAOP owner with the MCCA Reply Code field in the MCCAOP Setup Reply element equal to 0: Accept, as defined in Table 9-223. f) If the conditions in item d) are satisfied and the MCCAOP request has been intended for group addressed transmissions, the responder shall include the reservation in its MCCAOP advertisement only after the MCCAOP advertisement from the MCCAOP owner is received. g) If not all of the conditions in item d) are satisfied and the MCCAOP request is intended for individually addressed transmissions, the responder shall transmit to the MCCAOP owner an MCCA Setup Reply frame that is constructed as follows: 1) If the condition in item d)1) is not satisfied and both conditions in item d)2) and item d)3) are satisfied, the responder may calculate an alternative MCCAOP reservation and include it in the MCCAOP Reservation field of the MCCAOP Setup Reply element. It shall set the MCCA Reply Code field of the MCCAOP Setup Reply element to 1: Reject: MCCAOP reservation conflict, as defined in Table 9-223. 2) If the condition in item d)2) is not satisfied, it shall set the MCCA Reply Code field of the MCCAOP Setup Reply element to 2: Reject: MAF limit exceeded, as defined in Table 9-223. 3) If the condition in item d)2) is satisfied and the condition in item d)3) is not satisfied, it shall set the MCCA Reply Code field of the MCCAOP Setup Reply element to 3: Reject: MCCAOP track limit exceeded, as defined in Table 9-223. h) If not all of the conditions in item d) are satisfied and the MCCAOP request is intended for group addressed transmissions, the responder shall send an MCCA Setup Reply frame to the MCCAOP owner with the MCCA Reply Code field in the MCCAOP Setup Reply element equal to 1: Reject: MCCAOP reservation conflict. i) If the MCCAOP owner receives an MCCA Setup Reply frame with MCCA Reply Code equal to Accept, the MCCAOP reservation is established. Otherwise, the mesh STA may repeat the MCCAOP setup procedure using a modified MCCAOP Setup Request. If an alternative MCCAOP reservation is included in the MCCAOP Setup Reply element, the mesh STA may consider this alternative in its modified MCCAOP Setup Request. 10.23.3.7 MCCAOP advertisement 10.23.3.7.1 General A mesh STA with dot11MCCAActivated equal to true tracks MCCAOP reservations. The tracked MCCAOP reservations contain the neighborhood MCCAOP periods and optionally other periodic transmission of itself or of neighboring STAs. The MCCAOP advertisement set contains all MCCAOP reservations tracked by the mesh STA. The MCCAOP advertisement set is represented by an MCCAOP Advertisement Overview element and zero (if the MCCAOP advertisement set is empty) or more (if the MCCAOP advertisement set is nonempty) MCCAOP Advertisement elements. An MCCAOP Advertisement element contains one or more tracked MCCAOP reservations. 1408 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The mesh STA advertises its MCCAOP advertisement set to its neighbor mesh STAs. This subclause describes how the mesh STA constructs the MCCAOP Advertisement Overview element and the MCCAOP Advertisement elements. Further, this subclause describes the procedure to advertise an MCCAOP advertisement set, the procedure to request an MCCAOP advertisement from a neighboring mesh STA, and the procedure to process a received MCCAOP advertisement. 10.23.3.7.2 Construction of an MCCAOP advertisement set The following terminology is used in this subclause: â€” TX-RX report: an MCCAOP Reservation field contained in the TX-RX Periods Report field of an MCCAOP Advertisement element â€” Broadcast report: an MCCAOP Reservation field contained in the Broadcast Periods Report field of an MCCAOP Advertisement element â€” Interference report: an MCCAOP Reservation field contained in the Interference Periods Report field of an MCCAOP Advertisement element Each MCCAOP reservation tracked by a mesh STA is one of the following types: â€” TX-RX period: â€” An MCCAOP reservation for individually addressed frames for which the mesh STA is the MCCAOP owner or the MCCAOP responder. â€” Broadcast period: â€” An MCCAOP reservation for group addressed frames for which the mesh STA is the MCCAOP owner or the MCCAOP responder. â€” Optionally, a known Target Beacon Transmission Time of Beacon frames for which the mesh STA is either the transmitter or the receiver. â€” Optionally, a transmission or reception period of a STA that is collocated with the mesh STA, for example, beacon or HCCA times of a collocated AP. â€” Interference period: â€” A TX-RX or a broadcast period reported by a neighbor peer mesh STAs of the mesh STA excluding those periods for which this mesh STA is either the MCCAOP owner or the MCCAOP responder. â€” Optionally, a TX-RX or a broadcast period reported by neighbor nonpeer mesh STAs of the mesh STA. The MCCAOP reservations are grouped into the following sets: â€” MCCAOP TX-RX advertisement set, which includes all TX-RX periods â€” MCCAOP broadcast advertisement set, which includes all broadcast periods â€” MCCAOP interference advertisement set, which includes all interference periods These three sets constitute the MCCAOP advertisement set. The mesh STA uses the MCCAOP Overview element and MCCAOP Advertisement elements to advertise its MCCAOP advertisement set to its neighbor mesh STAs. The mesh STA acts as follows to construct the MCCAOP Overview elements and the MCCAOP Advertisement elements: a) If the MCCAOP advertisement set is nonempty, the mesh STA constructs one or more MCCAOP reports according to the format described in 9.4.2.109.3 as follows: 1409 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 1) If the MCCAOP TX-RX advertisement set is nonempty, the mesh STA constructs one or more TX-RX reports according to the format described in 9.4.2.109.3 such that each reservation in the MCCAOP TX-RX advertisement set occurs exactly in one TX-RX report. 2) If the MCCAOP broadcast advertisement set is nonempty, the mesh STA constructs one or more broadcast reports according to the format described in 9.4.2.109.3 such that each reservation in the MCCAOP broadcast advertisement set occurs exactly in one broadcast report. 3) If the MCCAOP interference advertisement set is nonempty, the mesh STA constructs one or more interference reports according to the format described in 9.4.2.109.3 such that each reservation in the MCCAOP interference advertisement set occurs exactly in one interference report. b) If the MCCAOP advertisement set is nonempty, the mesh STA constructs one or more MCCAOP Advertisement elements as follows: 1) The MCCAOP Advertisement Set Sequence Number field is set to the MCCAOP advertisement set sequence number as explained in 10.23.3.7.3. 2) The MCCAOP Advertisement Element Index subfield is set to an identifier that uniquely identifies the MCCAOP Advertisement element in the MCCAOP advertisement set. 3) Each MCCAOP Advertisement element includes at least one of the TX-RX reports, broadcast reports, or interference reports. Moreover, it includes at most one of the TX-RX reports, at most one of the broadcast reports, and at most one of the interference reports. In case the MCCAOP Advertisement element contains a TX-RX report, the TX-RX Report Present subfield of the MCCAOP Advertisement Element Information field is set to 1; otherwise this subfield is set to 0. In case the MCCAOP Advertisement element contains a broadcast report, the Broadcast Report Present subfield of the MCCAOP Advertisement Element Information field is set to 1; otherwise this subfield is set to 0. In case the MCCAOP Advertisement element contains an interference report, the Interference Report Present subfield of the MCCAOP Advertisement Element Information field is set to 1; otherwise, this subfield is set to 0. 4) Each report as constructed in step a) is present in exactly one MCCAOP Advertisement element. c) The mesh STA constructs one MCCAOP Advertisement Overview element such that 1) The MCCAOP Advertisement Set Sequence Number field is set to the advertisement set sequence number as explained in 10.23.3.7.3. 2) The Medium Access Fraction field is set to the medium access fraction. 3) The MAF limit field is set to dot11MAFlimit. 4) The Accept Reservations field is set to 1 if the number of tracked reservations of this mesh STA is less than dot11MCCAMaxTrackStates, and set to 0 otherwise. 5) Bit i of the Advertisement Elements Bitmap field is set to 1 if an MCCAOP Advertisement element with the MCCAOP Advertisement Element Index subfield equal to i is part of the representation of this MCCAOP advertisement set, and set to 0 otherwise. 10.23.3.7.3 Setting the MCCAOP advertisement set sequence number The MCCAOP advertisement set sequence number identifies an MCCAOP advertisement set. Mesh STAs with dot11MCCAActivated equal to true assign MCCAOP advertisement set sequence numbers from a single modulo 256 counter. The MCCAOP advertisement set sequence number is initialized to 0. The MCCAOP advertisement set sequence number shall be incremented by 1 if one of the following conditions holds: a) The mesh STA sets the bit for an MCCAOP Advertisement element in the Advertisement Elements Bitmap from 0 to 1 and this bit has been set to 1 under the same MCCAOP Advertisement Sequence Number before. 1410 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications b) The bit of the Advertisement Elements Bitmap corresponding to an MCCAOP Advertisement element is equal to 1 and the content of this MCCAOP Advertisement element changes. However, the MCCAOP advertisement set sequence number may remain unchanged if â€” The mesh STA changes a bit in the Advertisement Element Bitmap from 0 to 1 and this bit has not been set to 1 under the same MCCAOP Advertisement Sequence Number before, or â€” The mesh STA changes a bit in the Advertisement Elements Bitmap from 1 to 0. NOTEâ€”The Advertisement Set Sequence Number identifies the current distribution of the MCCAOP advertisement set over the MCCAOP Advertisement elements. Using a new MCCAOP advertisement set sequence number signals a new, (possibly) completely different distribution of the MCCAOP advertisement set over the MCCAOP Advertisement elements, and requires an advertisement of all reservations of the MCCAOP advertisement set. Leaving the MCCAOP advertisement set sequence number unchanged as in the previous MCCAOP Advertisement Overview element indicates MCCAOP Advertisement elements that have previously been advertised are not changed and remain current. This enables a limited advertisement procedure in which only new MCCAOP Advertisement elements are advertised. Additionally, this enables mesh STAs that operate in light or deep sleep mode to request a limited update of the MCCAOP advertisement set of a neighboring mesh STA in which only new MCCAOP Advertisement elements are included. 10.23.3.7.4 Advertisement procedure To advertise its MCCAOP advertisement set, the mesh STA constructs a representation of the MCCAOP advertisement set as described in 10.23.3.7.2. The MCCAOP advertisement set is advertised by transmitting an MCCAOP Advertisement Overview element and zero or more MCCAOP Advertisement elements (see 10.23.3.7.2) to neighbor peer mesh STAs. The MCCAOP Advertisement Overview element and the MCCAOP Advertisement elements are transmitted in Beacon frames, Probe Response frames, or MCCA Advertisement frames. The mesh STA shall advertise its MCCAOP advertisement set according to the following rules: a) The mesh STA shall advertise at least one MCCAOP Advertisement Overview element in every dot11MCCAAdvertPeriodMax DTIM intervals. b) The mesh STA shall advertise its MCCAOP Advertisement Overview element and any new MCCAOP Advertisement elements at the latest with the transmission of its next Beacon frame after its MCCAOP advertisement set has changed. c) The mesh STA shall advertise the requested MCCAOP Advertisement elements as described in 10.23.3.7.8 if the mesh STA receives an MCCA Advertisement Request frame. 10.23.3.7.5 Receipt of an MCCAOP advertisement Upon receipt of an MCCAOP advertisement a mesh STA with dot11MCCAActivated shall compare the Advertisement Set Sequence Number contained in the MCCAOP Advertisement Overview element of the received MCCAOP advertisement with the last advertisement set sequence number that this mesh STA tracked for the sender of the received MCCAOP advertisement. If the tracked advertisement set sequence number does not equal the Advertisement Set Sequence Number of the received MCCAOP advertisement, the mesh STA shall perform the procedure described in 10.23.3.7.6. If the tracked advertisement set sequence number equals the Advertisement Set Sequence Number of the received MCCAOP advertisement, the mesh STA shall compare the Advertisement Elements Bitmap contained in the received MCCAOP Advertisement Overview element with the last Advertisement Elements Bitmap that this mesh STA tracked for the sender of the received MCCAOP advertisement. If the tracked Advertisement Elements Bitmap does not equal the Advertisement Elements Bitmap of the received MCCAOP advertisement, the mesh STA shall perform the procedure described in 10.23.3.7.7. 1411 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NOTEâ€”If both the tracked advertisement set sequence number equals the Advertisement Set Sequence Number of the received MCCAOP advertisement and the tracked Advertisement Elements Bitmap equals the Advertisement Elements Bitmap of the received MCCAOP advertisement, the MCCAOP advertisement set of the sender of the MCCAOP advertisement tracked by the mesh STA is current, and no update of the MCCAOP advertisement set is needed. 10.23.3.7.6 Complete update of the tracked MCCAOP reservations of a neighbor mesh STA The mesh STA performed the steps in 10.23.3.7.5 and detected that the MCCAOP advertisement set sequence number has been updated. Consequently, the mesh STA shall operate as follows. The mesh STA shall discard all MCCAOP reservations that it tracked for the sender of the received MCCAOP advertisement. The mesh STA shall record the Advertisement Set Sequence Number and the source address (SA) of the received MCCAOP advertisement. The mesh STA shall record all reservations in the MCCAOP Advertisement elements of the received MCCAOP advertisement. If the mesh STA does not receive all MCCAOP Advertisement elements of the sender of the MCCAOP advertisement before a frame exchange sequence on the wireless medium causes the mesh STA to set its NAV, the mesh STA shall perform the MCCAOP advertisement request procedure as described in 10.23.3.7.8. 10.23.3.7.7 Partial update of the tracked MCCAOP reservations of a neighbor mesh STA The mesh STA performed the steps in 10.23.3.7.5 and detected that part of the MCCAOP advertisement set of the sender of the MCCAOP advertisement has been updated. Consequently, the mesh STA shall operate as follows for each bit in the Advertisement Elements Bitmap contained in the MCCAOP Advertisement Overview element of the received MCCAOP advertisement. If the bit in position n of the Advertisement Elements Bitmap in the received MCCAOP Advertisement is equal to 0 and if the bit in position n of the Advertisement Elements Bitmap tracked for the sender of the received MCCAOP advertisement is equal to 1, the mesh STA shall delete the reservations with the same Advertisement Sequence Number and the same MCCAOP Advertisement Element Index received from the same sender from its tracked reservations. If the bit in position n of the Advertisement Elements Bitmap in the received MCCAOP Advertisement is equal to 1 and if the bit in position n of the Advertisement Elements Bitmap tracked for the sender of the received MCCAOP advertisement is equal to 0, the mesh STA shall add the reservations of the received MCCAOP Advertisement element with the MCCAOP Advertisement Element Index set to n to its tracked reservations. If the mesh STA does not receive this MCCAOP Advertisement element of the sender of the MCCAOP Advertisement before a frame exchange sequence on the wireless medium causes the mesh STA to set its NAV, the mesh STA shall perform the MCCAOP Advertisement request procedure as described in 10.23.3.7.8. NOTEâ€”If the bit in position n of the received Advertisement Elements Bitmap contained in the received MCCAOP Advertisement is equal to the bit in position n of the Advertisement Elements Bitmap tracked for the sender of the received MCCAOP advertisement, then the Advertisement element with the MCCAOP Advertisement Element Index equal to n is current, and no update of this Advertisement element is needed. 10.23.3.7.8 MCCAOP advertisement request procedure To request all MCCAOP Advertisement elements from a neighbor peer mesh STA, the mesh STA transmits an MCCA Advertisement Request frame without an MCCAOP Advertisement Overview element. To request a subset of the MCCAOP Advertisement elements of a neighbor peer mesh STA, the mesh STA transmits an MCCA Advertisement Request frame including an MCCAOP Advertisement Overview element. The mesh STA shall set the contents of the MCCAOP Advertisement Overview element as follows. The mesh STA sets 1412 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications a) The Advertisement Set Sequence Number field to the Advertisement Sequence Number that it tracks for the recipient of this frame b) In the Advertisement Element Bitmap, the bit to 1 for each MCCAOP Advertisement element that the mesh STA requests from the recipient of this frame c) The Flags field, the MCCA Access Fraction field, and the MAF Limit field to 0 The mesh STA shall discard the MCCA Advertisement Request frame from its frame queue if it receives all of the MCCAOP Advertisement elements that it requests in the MCCAOP Advertisement Request. 10.23.3.8 MCCAOP teardown 10.23.3.8.1 Conditions that trigger an MCCAOP teardown The MCCAOP owner and the MCCAOP responder may initiate a teardown of an MCCAOP reservation, e.g., when the reservation is no longer needed. A mesh STA shall act as follows to resolve conflicts between MCCAOP reservations in its neighborhood MCCAOP periods. If the conflict is caused by overlapping reservations from its TX-RX periods and broadcast periods, it shall select one of these reservations and initiate a teardown for it. If the conflict is caused by an overlap between a reservation from its TX-RX periods or broadcast periods, and another reservation from its interference periods, it shall act as follows. It creates a first unsigned integer by inverting the bit order of its MAC address and a second unsigned integer by inverting the bit order of the lowest of the known MAC addresses of the owner and responder(s) of the reservation in the interference periods. If the first unsigned integer is smaller than the second unsigned integer, it shall initiate a teardown of the reservation in its TX-RX or broadcast periods. Otherwise, it may initiate a teardown of the reservation in its TX-RX or broadcast periods. There are also other conditions that trigger the MCCAOP owner and responder to delete a reservation, without an explicit tear down. An MCCAOP owner shall delete a reservation for an individually addressed transmission when it has not received an acknowledgment for any frame transmission in the MCCAOPs corresponding to the reservation for greater than dot11MCCAOPtimeout time. An MCCAOP responder shall delete a reservation for individually addressed transmission or group addressed transmissions when it has not received a frame transmission in any of the MCCAOPs corresponding to the reservation for greater than dot11MCCAOPtimeout time. 10.23.3.8.2 MCCAOP teardown procedure The teardown is initiated by transmitting an MCCA Teardown frame. The MCCAOP Reservation ID field in the MCCAOP Teardown element is set to the MCCAOP Reservation ID of the reservation that is to be torn down. In case the tear down is initiated by an MCCAOP responder, the MCCAOP Owner field of the MCCAOP Teardown element is set to the MAC address of the MCCAOP owner. The transmitter of the MCCA Teardown frame deletes the reservation after the MCCA Teardown frame has been successfully transmitted. The receiver of the MCCA Teardown frame acts as follows. In case the MCCAOP Reservation ID field corresponds to a reservation for individually addressed transmissions, it deletes the reservation. If the reservation is for group addressed transmissions for which it is the MCCAOP owner, it deletes the reservation if there are no other MCCAOP responders for this reservation. The MCCAOP owner acts as follows when deleting a reservation: â€” It stops executing the access procedure described in 10.23.3.9.1 at the start of the MCCAOPs corresponding to the reservation that was deleted. â€” In case the reservation was for individually addressed frames, it stops advertising the MCCAOP reservation in its TX-RX Periods Report field. 1413 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” In case the reservation was for group addressed frames, it stops advertising the MCCAOP reservation in its Broadcast Periods Report field. The MCCAOP responder acts as follows when deleting a reservation: â€” It stops executing the procedure described in 10.23.3.9.2 during the MCCAOPs corresponding to the reservation that was deleted. â€” In case the reservation was for individually addressed frames, it stops advertising the MCCAOP reservation in its TX-RX Periods Report field. â€” In case the reservation was for group addressed frames, it stops advertising the MCCAOP reservation in its Broadcast Periods Report field. 10.23.3.9 Access during MCCAOPs 10.23.3.9.1 Access by MCCAOP owners At the start of the MCCAOP, the EDCAF of the MCCAOP owner shall set AIFSN[AC] equal to dot11MCCAAIFSN, CWmax[AC] equal to dot11MCCACWmax, CW[AC] equal to dot11MCCACWmin, QSRC[AC] to 0, and QLRC[AC] to 0 for all ACs. The TXOP limit shall specify a duration value no larger than the MCCAOP Duration. During the MCCAOP, the EDCAFs of the ACs operates as specified in 10.22.2, with the following modifications. â€” During the MCCAOP, the EDCAF of each AC shall consider only those frame whose RA matches the MAC address of the MCCAOP responder. â€” When the access to the medium is delayed, the TXOP limit shall specify a duration to end no later than the MCCAOP start time plus the MCCAOP Duration. â€” As specified in 10.23.3.9.2, a neighboring STA shall not access the WM during an MCCAOP, until it receives a frame from either the MCCAOP owner or the MCCAOP responder. With the exception of truncation of an MCCA TXOP by means of a CF-End, standard EDCA TXOP rules apply for the remainder of the MCCAOP. For HT mesh STAs, these include the reverse direction protocol as specified in 10.28. â€” At the end of the MCCAOP, the parameters used by the EDCAF of the MCCAOP owner shall be set to dot11EDCATable, and QSRC[AC] and QLRC[AC] shall be set to 0 for all ACs. The MCCAOP owner may adjust the duration of an MCCAOP by setting the Duration/ID field in the frames it transmits. In particular, if an MCCAOP owner has no data to transmit in an MCCAOP corresponding to an MCCAOP reservation that is intended for individually addressed frames, it may transmit an individually addressed QoS Null frame during the MCCAOP to end the MCCAOP. NOTEâ€”It is recommended to send a QoS Null frame to end the MCCAOP although there might be situations in which the transmission of a QoS Null is not needed or undesirable. If an MCCAOP owner has no data to transmit in an MCCAOP reservation that is intended for group ad- dressed frames, it may transmit a group addressed QoS Null frame during the MCCAOP to end the MCCAOP. 10.23.3.9.2 Access during an MCCAOP by mesh STAs that are not the MCCAOP owner The MAC of a mesh STA with dot11MCCAActivated is true shall provide a Reservation Allocation Vector (RAV) mechanism to indicate a busy medium from the start of an MCCAOP corresponding to a reservation in its interference periods until the receipt of a frame transmitted by either the MCCAOP owner or the MCCAOP responder. The RAV mechanism is provided in addition to the PHY and virtual CS mechanisms described in 10.3.2.1. It is different from the virtual CS mechanism in two aspects. Firstly, a mesh STA 1414 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications might be neighbor to multiple ongoing MCCAOPs corresponding to different reservations and the regular NAV setting and updating rules do not suffice to prevent interference during these reservations. Secondly, the virtual CS mechanism is set immediately upon receipt of a frame, whereas the RAV mechanism is based on reservation frames received at some earlier time instant. When either the CS function provided by the PHY, the virtual CS function provided by the MAC via the NAV, or the RAV mechanism indicate a busy medium during an MCCAOP for which the mesh STA is neither the MCCAOP owner nor the MCCAOP responder, the medium shall be considered busy; otherwise, it shall be considered idle. The RAV mechanism maintains an index of future MCCAOPs based on the reservation information that is available in the interference periods of a mesh STA. At the start of each MCCAOP corresponding to a reservation in the interference periods, a RAV is set to indicate a busy medium for the duration of the MCCAOP given in the MCCAOP Duration subfield of the MCCAOP reservation. At the start of each MCCAOP corresponding to a reservation in the TX-RX or broadcast periods for which the mesh STA is an MCCAOP responder, a RAV is set to indicate a busy medium for the duration of the MCCAOP given in the MCCAOP Duration subfield of the MCCAOP reservation. The RAV may be thought of as a counter, corresponding to an MCCAOP corresponding to a reservation in the interference periods. The RAV counts down to zero at a uniform rate. When the counter is zero, the RAV indication is that the medium is idle; when nonzero, the indication is busy. The mesh STA clears the RAV timer, i.e., sets it to 0, upon receipt of a frame from either the MCCAOP owner or responder. If a mesh STA receives an RTS frame during an MCCAOP for which it is a MCCAOP responder, with the RA address matching its MAC address and with the MAC address in the TA field in the RTS frame matching the MAC address of the MCCAOP owner, then the STA shall send the CTS frame after SIFS, without regard for the NAV and the RAV, and without resetting its NAV. The RAV for an MCCAOP is not cleared upon receipt of a frame originating from stations that are not the MCCAOP owner or responder. Since the NAV is set upon receipt of frames with a Duration/ID field, the MCCAOP owner and responder adjust the reservation period of an MCCAOP to their actual traffic needs by the Duration/ID field in the transmitted frame and obtain protection of the frame transmission via the NAV setting. The RAV mechanism might be represented by a number of counters, where each counter corresponds to one MCCAOP. The number of counters needed at any instant is equal to the number of MCCAOPs at this instant corresponding to reservations in the interference periods of the mesh STA. 10.23.3.10 Interaction with time synchronization If a mesh STA adjusts its TBTT, e.g., in response to a TBTT Adjustment Request, it shall adjust the reservations by modifying the MCCAOP Offset of each of the tracked MCCAOP reservations. If a mesh STA adjusts its timing offset value with respect to a neighbor mesh STA, as specified in 14.13.2.2, it shall adjust the reservations by modifying the MCCAOP Offset of each of the tracked MCCAOP reservations for which this neighbor mesh STA is the owner. In either case, an MCCAOP advertisement of a mesh STA shall always contain the most recent MCCAOP Offsets. 10.24 Block acknowledgment (block ack) 10.24.1 Introduction The block ack mechanism improves channel efficiency by aggregating several acknowledgments into one frame. There are two types of block ack mechanisms: immediate and delayed. Immediate block ack is suitable for high-bandwidth, low-latency traffic while the delayed block ack is suitable for applications that tolerate moderate latency. In this subclause, the STA with data to send using the block ack mechanism is referred to as the originator, and the receiver of that data as the recipient. 1415 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The block ack mechanism is initialized by an exchange of ADDBA Request/Response frames. After initialization, blocks of QoS Data frames may be transmitted from the originator to the recipient. A block may be started within a polled TXOP, within an SP, or by winning EDCA contention. The number of frames in the block is limited, and the amount of state that is to be kept by the recipient is bounded. The MPDUs within the block of frames are acknowledged by a BlockAck frame, which is requested by a BlockAckReq frame. The block ack mechanism does not require the setting up of a TS; however, QoS STAs using the TS facility may choose to signal their intention to use block ack mechanism for the schedulerâ€™s consideration in assigning TXOPs. The block ack mechanism is also used by the GCR service. Acknowledgments of frames belonging to the same TID, but transmitted during multiple TXOPs/SPs, may also be combined into a single BlockAck frame. This mechanism allows the originator to have flexibility regarding the transmission of Data frames. The originator may split the block of frames across TXOPs/SPs, separate the data transfer and the block ack exchange, and interleave blocks of MPDUs carrying all or part of MSDUs or A-MSDUs for different TIDs or RAs. Figure 10-32 illustrates the message sequence chart for the setup, data and block ack transfer, and the teardown of the block ack mechanism, which are discussed in detail in 10.24.2 to 10.24.5. ADDBA Request Ack (a) Setup ADDBA Response Ack QoS Data frame multiple (b) Data & Block Ack times Block A ckReq Block A ck DELB A Request Ack (c) Teardown Originator Recipient Figure 10-32â€”Message sequence chart for block ack mechanism: (a) setup, (b) data and acknowledgment transfer, and (c) teardown All operations on sequence numbers are performed modulo 212. Comparisons between sequence numbers are circular modulo 212, i.e., the sequence number space is considered divided into two parts, one of which is â€œoldâ€ and one of which is â€œnew,â€ by means of a boundary created by adding half the sequence number range to the current start of receive window (modulo 212). 10.24.2 Setup and modification of the block ack parameters An originator that intends to use the block ack mechanism for the transmission of QoS Data frames to an intended recipient should first check whether the intended recipient STA is capable of participating in block ack mechanism by discovering and examining its Delayed Block Ack and Immediate Block Ack capability bits. If the intended recipient STA is capable of participating, the originator sends an ADDBA Request frame indicating the TID for which the block ack agreement is being set up. When a block ack agreement is set up between HT STAs, the Buffer Size and Block Ack Timeout fields in the ADDBA Request frame are advisory. When a block ack agreement is set up between HT or DMG STAs, the Buffer Size and Block Ack Timeout 1416 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications fields in the ADDBA Request frame are advisory. When a block ack agreement is set up between a non-HT non-DMG STA and another STA, the Block Ack Policy and Buffer Size fields in the ADDBA Request frame are advisory. The recipient STA shall respond by an ADDBA Response frame. The recipient STA has the option of accepting or rejecting the request. When the recipient STA accepts, then a block ack agreement exists between the originator and recipient. When the recipient STA accepts, it indicates the type of block ack and the number of buffers that it shall allocate for the support of this block ack agreement within the ADDBA Response frame and the block ack timeout that is used. Each block ack agreement that is established by a STA may have a different buffer allocation. If the intended recipient STA rejects the request, then the originator shall not use the block ack mechanism. When the Block Ack Policy subfield value is set to 1 by the originator of an ADDBA Request frame between HT STAs, then the ADDBA Response frame accepting the ADDBA Request frame shall contain 1 in the Block Ack Policy subfield. For each accepted block ack agreement, the originator shall set the sequence number of the first frame transmitted under the agreement to the value of the Block Ack Starting Sequence Control field of the ADDBA Request frame of the accepted block ack agreement. When a block ack agreement is established between two HT STAs or two DMG STAs, the originator may change the size of its transmission window if the value in the Buffer Size field of the ADDBA Response frame is larger than the value in the ADDBA Request frame. If the value in the Buffer Size field of the ADDBA Response frame is smaller than the value in the ADDBA Request frame, the originator shall change the size of its transmission window (WinSizeO) so that it is not greater than the value in the Buffer Size field of the ADDBA Response frame and is not greater than the value 64. The originator STA may send an ADDBA Request frame in order to update block ack timeout value. If the updated ADDBA Request frame is accepted, both STAs initialize the timer to detect block ack timeout. Even if the updated ADDBA Request frame is not accepted, the original block ack setup remains active. NOTE A block ack associated with a GCR group address does not use an inactivity timer because the GCR originator might switch between the DMS delivery method, the GCR unsolicited retry retransmission policy, and the GCR block ack retransmission policy during the lifetime of a GCR agreement. The A-MSDU Supported field indicates whether an A-MSDU may be sent under the particular block ack agreement. The originator sets this field to 1 to indicate that it might transmit A-MSDUs with this TID. The recipient sets this field to 1 to indicate that it is capable of receiving an A-MSDU with this TID. NOTEâ€”The recipient is free to respond with any setting of the A-MSDU supported field. If the value in the ADDBA Response frame is not acceptable to the originator, it can delete the block ack agreement and transmit data using normal acknowledgment. If the block ack mechanism is being set up for a TS, bandwidth negotiation (using ADDTS Request and Response frames) should precede the setup of the block ack mechanism. If the block ack mechanism is being set up for the GCR service, then the following steps apply: â€” One or more GCR Request/Response exchanges precede the setup of the block ack mechanism. â€” The ADDBA Request and Response frames exchanged to set up the block ack shall include the GCR Group Address element indicating the group address of the GCR service. Once the block ack exchange has been set up, Data and Ack frames are transferred using the procedure described in 10.24.3. 1417 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.24.3 Data and acknowledgment transfer using immediate block ack policy and delayed block ack policy After setting up either an immediate block ack agreement or a delayed block ack agreement following the procedure in 10.24.2, and having gained access to the medium and established protection, if necessary, the originator may transmit a block of QoS Data frames separated by SIFS, with the total number of frames not exceeding the Buffer Size subfield value in the associated ADDBA Response frame and subject to any additional duration limitations based on the channel access mechanism. Each of the frames shall have the Ack Policy subfield in the QoS Control field set to Block Ack. The RA field of the frames that are not delivered using the GCR block ack retransmission policy shall be the recipientâ€™s individual address. The RA field of GCR frames delivered using the GCR block ack retransmission policy shall be set to the GCR concealment address. The originator requests acknowledgment of outstanding QoS Data frames by sending a Basic BlockAckReq frame. The recipient shall maintain a block ack record for the block. Subject to any constraints in this subclause about permitted use of TXOP or SP according to the channel access mechanism used, the originator may â€” Separate the block of QoS data frames and the Basic BlockAckReq frames into separate TXOPs or SPs â€” Split transmission of Data frames sent under block ack policy across multiple TXOPs or SPs â€” Interleave MPDUs with different TIDs within the same TXOP or SP â€” Sequence or interleave MPDUs for different RAs within a TXOP or SP A protective mechanism (such as transmitting using HCCA, RTS/CTS, RTS/DMG CTS, SP, protected period, or the mechanism described in 10.26) should be used to reduce the probability of other STAs transmitting during the TXOP or SP. If no protective mechanism is used, then the first frame that is sent as a block shall have a response frame and shall have the Duration field set so that the NAVs are set to appropriate values at all STAs in the BSS. The originator shall use the block ack starting sequence control to signal the first MPDU in the block for which an acknowledgment is expected. MPDUs in the recipientâ€™s buffer with a sequence control value that precedes the starting sequence control value are called preceding MPDUs. The recipient shall reassemble any complete MSDUs from buffered preceding MPDUs and indicate these to its higher layer. The recipient shall then release any buffers held by preceding MPDUs. The range of the outstanding MPDUs (i.e., the reorder buffer) shall begin on an MSDU boundary. The total number of frames that can be sent depends on the total number of MPDUs in all of the outstanding MSDUs. The total number of MPDUs in these MSDUs shall not exceed the reorder buffer size in the receiver. The recipient of an accepted block ack agreement that did not contain a GCR Group Address element in the ADDBA Request frame shall maintain a block ack record consisting of originator address, TID, and a record of reordering buffer size indexed by the received MPDU sequence control value. This record holds the acknowledgment state of the Data frames received from the originator. The recipient of an accepted block ack agreement that contained a GCR Group Address element in the ADDBA Request frame shall maintain a block ack record consisting of the DA address from the A-MSDU subframe header, TID, and a record of reordering buffer size indexed by the received MPDU sequence control value. This record holds the acknowledgment state of the group addressed Data frames received from the originator. If the immediate block ack policy is used, the recipient shall respond to a Basic BlockAckReq frame with a Basic BlockAck frame. If the recipient sends the Basic BlockAck frame, the originator updates its own record and retries any frames that are not acknowledged in the Basic BlockAck frame, either in another block or individually. If the delayed block ack policy is used, the recipient shall respond to a Basic BlockAckReq frame with an Ack frame. The recipient shall then send its Basic BlockAck frame response in a subsequently obtained TXOP. 1418 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Once the contents of the Basic BlockAck frame have been prepared, the recipient shall send this frame in the earliest possible TXOP using the highest priority AC. The originator shall respond with an Ack frame upon receipt of the Basic BlockAck frame. If delayed block ack policy is used and if the HC is the recipient, then the HC may respond with a +CF-Ack frame if the Basic BlockAckReq frame is the final frame of the polled TXOPâ€™s frame exchange. If delayed block ack policy is used and if the HC is the originator, then the HC may respond with a +CF-Ack frame if the Basic BlockAck frame is the final frame of the TXOPâ€™s frame exchange. The Basic BlockAck frame contains acknowledgments for the MPDUs of up to 64 previous MSDUs. In the Basic BlockAck frame, the STA acknowledges only the MPDUs starting from the starting sequence control value until the MPDU with the highest sequence number that has been received, and the STA shall set bits in the Block Ack Bitmap subfield corresponding to all other MPDUs to 0. The status of MPDUs that are considered â€œoldâ€ and prior to the sequence number range for which the receiver maintains status shall be reported as successfully received (i.e., the corresponding bit in the bitmap shall be set to 1). If the Basic BlockAck frame indicates that an MPDU was not received correctly, the originator shall retry that MPDU subject to that MPDUâ€™s appropriate lifetime limit. A typical block ack sequence using immediate block ack for a single TID is shown in Figure 10-33. Originator Data Block Block Ack Exchange Frame-exchange q a t a t a t a t e a a a a c R for NAV Protection is k c D D D D S S S S a A k o o o o B c Q Q Q Q lo B Recipient k c A k c o l B Ack Policy = Block Ack ic s a B NAV at other STAs Figure 10-33â€”Typical block ack sequence when immediate policy is used A typical block ack sequence using the delayed block ack is shown in Figure 10-34. The subsequent Basic BlockAckReq frameâ€™s starting sequence number shall be higher than or equal to the starting sequence number of the immediately preceding Basic BlockAckReq frame for the same TID. The originator may continue to transmit MPDUs (subject to the negotiated buffer size constraint) to the recipient after transmitting the Basic BlockAckReq frame, but before receiving the Basic BlockAck frame (applicable only to delayed block ack). The bitmap in the Basic BlockAck frame shall include the status of frames received between the start sequence number and the transmission of the Basic BlockAckReq frame. A recipient sending a delayed Basic BlockAck frame may update the bitmap with information on QoS Data frames received between the receipt of the Basic BlockAckReq frame and the transmission of the Basic BlockAck frame. 1419 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Originator Data Block Block Ack Exchange BlockAckReq Frame -exchange QoS Data QoS Data QoS Data QoS Data Basic for NAV Protection Ack NAV due to Recipient recipient Basic BlockAck Ack Ack Policy = Block Ack NAV at other STAs Figure 10-34â€”Typical block ack sequence when delayed policy is used If there is no response (i.e., neither a Basic BlockAck frame nor an Ack frame) to the Basic BlockAckReq frame, the originator may retransmit the Basic BlockAckReq frame within the current TXOP or SP (if time permits) or within a subsequent TXOP or SP. MSDUs that are sent using the block ack mechanism are not subject to retry limits but only to MSDU lifetime. A non-DMG originator does not need to set the Retry subfield to 1 for any possible retransmissions of the MPDUs. A DMG originator shall set the Retry subfield to 1 for any possible retransmissions of the MPDUs. The Basic BlockAckReq frame shall be discarded if all MSDUs referenced by this frame have been discarded from the transmit buffer due to the expiration of their lifetime limit. Under a block ack agreement, the Normal Ack policy may be used in order to improve efficiency. A STA shall respond with an Ack frame to the reception of frames that are covered by a block ack agreement, but that are not part of an A-MPDU and that are received with their Ack Policy subfield in the QoS Control field equal to Normal Ack. The block ack record shall be updated irrespective of the acknowledgment type (Normal or Block Ack) for the TID/TSID with a block ack agreement. The reception of QoS Data frames using Normal Ack policy shall not be used by the recipient as an indication to reset the timer employed in detecting a block ack timeout (see 11.5). The block ack timeout allows the recipient to delete the block ack if the originator does not switch back to using block ack. The frame exchange sequences are provided in Annex G. 10.24.4 Receive buffer operation For each block ack agreement, the recipient maintains a MAC variable NextExpectedSequenceNumber. The NextExpectedSequenceNumber is initialized to the value of the Block Ack Starting Sequence Control field of the ADDBA Request frame of the accepted block ack agreement. Upon the receipt of a QoS Data frame from the originator for which a block ack agreement exists, the recipient buffers the MSDU regardless of the value of the Ack Policy subfield within the QoS Control field of the QoS 1420 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Data frame, unless the sequence number of the frame is older than the NextExpectedSequenceNumber for that block ack agreement, in which case the frame is discarded because it is either old or a duplicate. The recipient flushes received MSDUs from its receive buffer as described in this subclause. If a BlockAckReq frame is received, all complete MSDUs and A-MSDUs with lower sequence numbers than the starting sequence number contained in the BlockAckReq frame shall be passed up to the next MAC process as shown in Figure 5-1. Upon arrival of a BlockAckReq frame, the recipient shall pass up the MSDUs and A-MSDUs starting with the starting sequence number sequentially until there is an incomplete or missing MSDU or A-MSDU in the buffer. If no MSDUs or A-MSDUs are passed up to the next MAC process after the receipt of the BlockAckReq frame and the starting sequence number of the BlockAckReq frame is newer than the NextExpectedSequenceNumber for that block ack agreement, then the NextExpectedSequenceNumber for that block ack agreement is set to the sequence number of the BlockAckReq frame. If, after an MPDU is received, the receive buffer is full, the complete MSDU or A-MSDU with the earliest sequence number shall be passed up to the next MAC process. If, after an MPDU is received, the receive buffer is not full, but the sequence number of the complete MSDU or A-MSDU in the buffer with the lowest sequence number is equal to the NextExpectedSequenceNumber for that block ack agreement, then the MPDU shall be passed up to the next MAC process. Each time that the recipient passes an MSDU or A-MSDU for a block ack agreement up to the next MAC process, the NextExpectedSequenceNumber for that block ack agreement is set to the sequence number of the MSDU or A-MSDU that was passed up to the next MAC process plus one. The recipient shall pass MSDUs and A-MSDUs up to the next MAC process in order of increasing sequence number. 10.24.5 Teardown of the block ack mechanism When the originator has no data to send and the final block ack exchange has completed, it shall signal the end of its use of the block ack mechanism by sending the DELBA frame to its recipient. The recipient does not generate a Management frame in response to the DELBA frame.41 The recipient of the DELBA frame shall release all resources allocated for the block ack transfer. The block ack agreement may be torn down if there are no BlockAck, BlockAckReq, or QoS Data frames (sent under block ack policy) for the block ackâ€™s TID received from the peer within a duration of block ack timeout value (see 11.5.4). The DELBA frame transmitted to release the block ack setup of a GCR service shall include the GCR Group Address element to indicate the group address of the GCR service. 10.24.6 Selection of BlockAck and BlockAckReq variants The Compressed Bitmap subfield of the BA Control field or BAR Control field shall be set to 1 in all BlockAck and BlockAckReq frames sent from one HT STA to another HT STA and shall be set to 0 otherwise. The Multi-TID subfield of the BA Control field shall be set to 1 in all BlockAck frames related to an HT- immediate agreement transmitted inside a PSMP sequence and shall be set to 0 otherwise. The Multi-TID subfield of the BAR Control field shall be set to 1 in all BlockAckReq frames related to an HT-immediate agreement transmitted inside a PSMP sequence and shall be set to 0 otherwise. 41 Normal Ack rules apply. 1421 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications In a DMG BSS, if the Compressed Bitmap subfield of the BAR Control field within a BlockAckReq frame related to an HT-immediate agreement is equal to 1, then all of the following BlockAck and BlockAckReq frames transmitted as part of the HT-immediate agreement shall have the Compressed Bitmap subfield of the BA Control and BAR Control fields set to 1. In this case, the Multi-TID subfield of the BA Control field and BAR Control field shall be set to 0 in all BlockAck and BlockAckReq frames transmitted as part of the HT-immediate agreement. In a DMG BSS, if the Compressed Bitmap subfield of the BAR Control field within a BlockAckReq frame related to an HT-immediate agreement is equal to 0, then all of the following BlockAck and BlockAckReq frames transmitted as part of the HT-immediate agreement shall have the Compressed Bitmap subfield of the BA Control and BAR Control fields set to 0. In this case, the Multi-TID subfield of the BA Control field and BAR Control field shall be set to 1 in all BlockAck and BlockAckReq frames transmitted as part of the HT-immediate agreement. Where the terms BlockAck and BlockAckReq are used within 10.24.7 and 10.24.8, the appropriate variant according to this subclause (e.g., Compressed, Multi-TID) is referenced by the generic term. The GCR subfield of the BAR Control field shall be set to 1 in all BlockAckReq frames where the block ack agreement is for a group address delivered using the GCR block ack retransmission policy and shall be set to 0 otherwise. The GCR subfield of the BA Control field shall be set to 1 in all BlockAck frames where the block ack agreement is for a group address delivered using the GCR block ack retransmission policy and shall be set to 0 otherwise. 10.24.7 HT-immediate block ack extensions 10.24.7.1 Introduction to HT-immediate block ack extensions An HT extension to the block ack feature (defined in 10.24.1 through 10.24.5), called HT-immediate block ack, is defined in 10.24.7.2 through 10.24.7.9. The HT-immediate extensions simplify immediate block ack use with A-MPDUs and reduce recipient resource requirements. An HT STA shall support HT-immediate block ack in the role of recipient. A DMG STA shall support HT-immediate block ack. 10.24.7.2 HT-immediate block ack architecture The HT-immediate block ack rules are explained in terms of the architecture shown in Figure 10-35 and explained in this subclause. The originator contains a transmit buffer control that uses WinStartO and WinSizeO to submit MPDUs for transmission and releases transmit buffers upon receiving BlockAck frames from the recipient. WinStartO is the starting sequence number of the transmit window, and WinSizeO is the number of buffers negotiated in the block ack agreement. The Aggregation control creates A-MPDUs. It may adjust the Ack Policy field of transmitted QoS Data frames according to the rules defined in 10.24.7.7 in order to solicit BlockAck frame responses. 1422 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Originator Recipient Receive Reordering Buffer Control per TA/TID Transmit Buffer Control (WinStartB, WinSizeB) per RA/TID (WinStartO, WinSizeO) Scoreboard Context Control (WinStartR, WinSizeR) Aggregation control Deaggregation control A-MPDU BlockAck (BitMap, SSN) Figure 10-35â€”HT-immediate block ack architecture The recipient contains a receive reordering buffer control per TA/TID, which contains a related control state. The receive reordering buffer is responsible for reordering MSDUs or A-MSDUs so that MSDUs or A-MSDUs are eventually passed up to the next MAC process in order of received sequence number. It is also responsible for identifying and discarding duplicate frames (i.e., frames that have the same sequence number as a currently buffered frame) that are part of this block ack agreement. It maintains its own state independent of the scoreboard context control to perform this reordering as specified in 10.24.7.6. For each HT-immediate block ack agreement, the recipient chooses either full-state or partial-state operation (this choice is known only to the recipient). A STA may simultaneously use full-state operation for some agreements and partial-state operation for other agreements. The scoreboard context control stores an acknowledgment bitmap containing the current reception status of MSDUs or A-MSDUs for HT-immediate block ack agreements. Under full-state operation, status is maintained in statically assigned memory. Under partial-state operation, status is maintained in a cache memory; therefore, the status information is subject to cache replacement. This entity provides the bitmap and the value for the Starting Sequence Number subfield to be sent in BlockAck frame responses to the originator. The deaggregation control entity separates frames contained in an A-MPDU. Each received MPDU is analyzed by the scoreboard context control as well as by the receive reordering buffer control. Each HT-immediate block ack agreement is uniquely identified by a tuple of Address 1, Address 2, and TID from the ADDBA Response frame that successfully established the HT-immediate block ack agreement. The STA that corresponds to Address 1 of the ADDBA Response frame is the originator. The STA that corresponds to Address 2 of the ADDBA Response frame is the recipient. Data frames that contain the same values for Address 1, Address 2, and TID as a successful ADDBA Response frame are related with the HT-immediate block ack agreement that was established by the receipt of that ADDBA Response frame provided that the HT- immediate block ack agreement is still active. 10.24.7.3 Scoreboard context control during full-state operation For each HT-immediate block ack agreement that uses full-state operation, a recipient shall maintain a block acknowledgment record as defined in 10.24.3. This record includes a bitmap, indexed by sequence number; a 12-bit unsigned integer starting sequence number, WinStartR, representing the lowest sequence number position in the bitmap; a variable WinEndR; and the maximum transmission window size, WinSizeR, which is set to the smaller of 64 and the value of the Buffer Size field of the associated ADDBA Response frame that established the block ack agreement. WinEndR is defined as the highest sequence number in the current transmission window. A STA implementing full-state operation for an HT-immediate block ack agreement shall maintain the block acknowledgment record for that agreement according to the following rules: 1423 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications a) At HT-immediate block ack agreement establishment: 1) WinStartR = SSN from the ADDBA Request frame that elicited the ADDBA Response frame that established the HT-immediate block ack agreement. 2) WinEndR = WinStartR + WinSizeR â€“ 1. b) For each received Data frame that is related with a specific full-state operation HT-immediate block ack agreement, the block acknowledgment record for that agreement is modified as follows, where SN is the value of the Sequence Number subfield of the received Data frame: 1) If WinStart R SN WinEnd R , set to 1 the bit in position SN within the bitmap. 11 2) If WinEnd R SN WinStart R +2 , i) Set to 0 the bits corresponding to MPDUs with Sequence Number subfield values from WinEndR+1 to SN â€“ 1. ii) Set WinStartR = SN â€“ WinSizeR + 1. iii) Set WinEndR = SN. iv) Set to 1 the bit at position SN in the bitmap. 11 3) If WinStart R +2 SN WinStart R , make no changes to the record. NOTEâ€”A later-arriving Data frame might validly contain a sequence number that is lower than an earlier-arriving one. This might happen because the transmitter may choose to send Data frames in a nonsequential sequence number order or because a previous Data frame transmission with lower sequence number is not successful and is being retransmitted. c) For each received BlockAckReq frame that is related with a specific full-state operation HT- immediate block ack agreement that is not a protected block ack agreement, the block acknowledgment record for that agreement is modified as follows, where SSN is the value from the Starting Sequence Number subfield of the received BlockAckReq frame: 1) If WinStart R SSN WinEnd R , i) Set WinStartR = SSN. ii) Set to 0 the bits corresponding to MPDUs with Sequence Number subfield values from WinEndR + 1 through WinStartR + WinSizeR â€“ 1. iii) Set WinEndR = WinStartR + WinSizeR â€“ 1. 11 2) If WinEnd R SSN WinStart R +2 , i) Set WinStartR = SSN. ii) Set WinEndR = WinStartR + WinSizeR â€“ 1. iii) Set to 0 bits the corresponding to MPDU with Sequence Number subfield values from WinStartR to WinEndR. 11 3) If WinStart R +2 SSN WinStart R , make no changes to the record. 10.24.7.4 Scoreboard context control during partial-state operation In an HT-immediate block ack agreement that uses partial-state operation, a recipient shall maintain a temporary block acknowledgment record, as defined in 10.24.3. This temporary record includes a bitmap, indexed by sequence number; a 12-bit unsigned integer WinStartR (the lowest sequence number represented in the bitmap); a 12-bit unsigned integer WinEndR (the highest sequence number in the bitmap); the originator address; TID; and the maximum transmission window size, WinSizeR, which is set to the smaller of 64 and the value of the Buffer Size field of the associated ADDBA Response frame that established the block ack agreement. 1424 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications During partial-state operation of scoreboard context control, the recipient retains the current record for an HT- immediate block ack agreement at least as long as it receives data from the same originator. If a frame for an HT-immediate block ack agreement from a different originator is received, the temporary record may be discarded if the resources it uses are needed to store the temporary record corresponding to the newly arriving frame. A STA implementing partial-state operation for an HT-immediate block ack agreement shall maintain the temporary block acknowledgment record for that agreement according to the following rules: a) During partial-state operation, WinStartR is determined by the Sequence Number subfield value of received Data frames and by the Starting Sequence Number subfield value of received BlockAckReq frames as described below. b) For each received Data frame that is related with a specific partial-state operation HT-immediate block ack agreement, when no temporary record for the agreement related with the received Data frame exists at the time of receipt of the Data frame, a temporary block acknowledgment record is created as follows, where SN is the value of the Sequence Number subfield of the received Data frame: 1) WinEndR = SN. 2) WinStartR = WinEndR - WinSizeR + 1. 3) Create a bitmap of size WinSizeR, with the first bit corresponding to sequence number WinStartR and the last bit corresponding to sequence number WinEndR, and set all bits in the bitmap to 0. 4) Set to 1 the bit in the position in the bitmap that corresponds to SN. c) For each received Data frame that is related with a specific partial-state operation HT-immediate block ack agreement, when a temporary record for the agreement related with the received Data frame exists at the time of receipt of the Data frame, the temporary block acknowledgment record for that agreement is modified in the same manner as the acknowledgment record for a full-state agreement described in 10.24.7.3. d) For each received BlockAckReq frame that is related with a specific partial-state operation HT- immediate block ack agreement that is not a protected block ack agreement, when no temporary record for the agreement related with the received frame exists at the time of receipt of the frame, a temporary block acknowledgment record is created as follows, where SSN is the starting value of the Sequence Number subfield of the received BlockAckReq frame: 1) WinStartR = SSN. 2) WinEndR = WinStartR + WinSizeR â€“ 1. 3) Create a bitmap of size WinSizeR, and set all bits in the bitmap to 0. e) For each received BlockAckReq frame that is related with a specific partial-state operation HT- immediate block ack agreement that is not a protected block ack agreement, when a temporary record for the agreement related with the received frame exists at the time of receipt of the frame, the temporary block acknowledgment record for that agreement is modified in the same manner as the acknowledgment record for a full-state agreement described in 10.24.7.3. 10.24.7.5 Generation and transmission of BlockAck frames by an HT STA or DMG STA Except when operating within a PSMP exchange, a STA that receives a PPDU that contains a BlockAckReq frame in which the Address 1 field matches its MAC address during either full-state operation or partial-state operation shall transmit a PPDU containing a BlockAck frame that is separated on the WM by a SIFS from the PPDU that elicited the BlockAck frame as a response. A STA that receives an A-MPDU that contains one or more MPDUs in which the Address 1 field matches its MAC address with the Ack Policy field equal to Normal Ack (i.e., implicit block ack request) during either full-state operation or partial-state operation shall transmit a PPDU containing a BlockAck frame that is separated on the WM by a SIFS from the PPDU that elicited the BlockAck frame as a response. 1425 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications When responding with a BlockAck frame to either a received BlockAckReq frame or a received A-MPDU with Ack Policy equal to Normal Ack (i.e., implicit block ack request) during either full-state operation or partial-state operation, any adjustment to the value of WinStartR according to the procedures defined within 10.24.7.3 and 10.24.7.4 shall be performed before the generation and transmission of the response BlockAck frame. The Starting Sequence Number subfield of the Block Ack Starting Sequence Control subfield of the BlockAck frame shall be set to any value in the range (WinEndR â€“ 63) to WinStartR. The values in the recipientâ€™s record of status of MPDUs beginning with the MPDU for which the Sequence Number subfield value is equal to WinStartR and ending with the MPDU for which the Sequence Number subfield value is equal to WinEndR shall be included in the bitmap of the BlockAck frame. When responding with a BlockAck frame to either a received BlockAckReq frame or a received A-MPDU with Ack Policy equal to Normal Ack (i.e., implicit block ack request) during either full-state or partial-state operation, if the adjusted value of WinStartR is greater than the value of the starting sequence number of the BlockAck frame, within the bitmap of the BlockAck frame, the status of MPDUs with sequence numbers that are less than the adjusted value of WinStartR may be set to any value. When responding with a BlockAck frame to either a received BlockAckReq frame or a received A-MPDU with Ack Policy equal to Normal Ack (i.e., implicit block ack request) during either full-state or partial-state operation, if the adjusted value of WinEndR is less than the value of the starting sequence number of the BlockAck frame plus 63, within the bitmap of the BlockAck frame, the status of MPDUs with sequence numbers that are greater than the adjusted value of WinEndR shall be reported as unsuccessfully received (i.e., the corresponding bit in the bitmap shall be set to 0). If a BlockAckReq frame is received and no matching partial state is available, the recipient shall send a null BlockAck frame in which the bitmap is set to all 0s. 10.24.7.6 Receive reordering buffer control operation 10.24.7.6.1 General The behavior described in this subclause, 10.24.7.6.2, and 10.24.7.6.3 applies to a STA that uses either partial- state operation or full-state operation for an HT-immediate block ack agreement. A receive reordering buffer shall be maintained for each HT-immediate block ack agreement. Each receive reordering buffer includes a record comprising the following: â€” Buffered MSDUs or A-MSDUs that have been received, but not yet passed up to the next MAC process â€” A WinStartB parameter, indicating the value of the Sequence Number subfield of the first (in order of ascending sequence number) MSDU or A-MSDU that has not yet been received â€” A WinEndB parameter, indicating the highest sequence number expected to be received in the current reception window â€” A WinSizeB parameter, indicating the size of the reception window WinStartB is initialized to the Starting Sequence Number subfield value of the ADDBA Request frame that elicited the ADDBA Response frame that established the HT-immediate block ack agreement. WinEndB is initialized to WinStartB + WinSizeB â€“ 1, where WinSizeB is set to the smaller of 64 and the value of the Buffer Size field of the ADDBA Response frame that established the block ack agreement. Any MSDU or A-MSDU that has been passed up to the next MAC process shall be deleted from the receive reordering buffer. 1426 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The recipient shall always pass MSDUs or A-MSDUs up to the next MAC process in order of increasing Sequence Number subfield value. 10.24.7.6.2 Operation for each received Data frame For each received Data frame that is related to a specific HT-immediate block ack agreement, the receive reordering buffer record shall be modified as follows, where SN is the value of the Sequence Number subfield of the received MPDU: a) If WinStart B SN WinEnd B , 1) Store the received MPDU in the buffer, if no MSDU with the same sequence number is already present; otherwise discard the MPDU. 2) Pass MSDUs or A-MSDUs up to the next MAC process if they are stored in the buffer in order of increasing value of the Sequence Number subfield starting with the MSDU or A-MSDU that has SN=WinStartB or if SN>WinStartB, the STA is a DMG STA, and one of the following conditions is met: i) The MPDU is received as non-first frame in the A-MPDU; the bit at position SN=Win- StartR â€“ 1 is set to 1; and all delimiters between the received MPDU and the preceding MPDU (SN=WinStartR â€“ 1) are valid. ii) The MPDU is received as first frame in the A-MPDU; the A-MPDU is received in SIFS or RIFS after an A-MPDU or in SIFS after transmission of a BlockAck frame; the bit at posi- tion SN=WinStartR â€“ 1 is set to 1; and all delimiters after the MPDU(SN=WinStartR â€“ 1) in the preceding A-MPDU are valid. iii) The MPDU is received in SIFS or RIFS after an A-MPDU or in SIFS after transmission of a BlockAck frame; the bit at position SN=WinStartR â€“ 1 is set to 1; and all delimiters after the MPDU (SN=WinStartR â€“ 1) in the preceding A-MPDU are valid. iv) The MPDU is received as first frame in the A-MPDU; the A-MPDU is received in SIFS or RIFS after an MPDU or in SIFS after transmission of an Ack frame; and the bit at position SN=WinStartR â€“ 1 is set to 1. v) The MPDU is received in SIFS or RIFS after the preceding MPDU or in SIFS after trans- mission of an Ack frame; and the bit at position SN=WinStartR â€“ 1 is set to 1. This process is continued sequentially until there is no buffered MSDU or A-MSDU for the next sequential value of the Sequence Number subfield. 3) Set WinStartB to the value of the Sequence Number subfield of the last MSDU or A-MSDU that was passed up to the next MAC process plus one. 4) Set WinEndB = WinStartB + WinSizeB â€“ 1. 11 b) If WinEnd B SN WinStart B +2 , 1) Store the received MPDU in the buffer, if no MSDU with the same sequence number is already present; otherwise discard the MPDU. 2) Set WinEndB = SN. 3) Set WinStartB = WinEndB â€“ WinSizeB + 1. 4) Pass any complete MSDUs or A-MSDUs stored in the buffer with Sequence Number subfield values that are lower than the new value of WinStartB up to the next MAC process in order of increasing Sequence Number subfield value. Gaps may exist in the Sequence Number subfield values of the MSDUs or A-MSDUs that are passed up to the next MAC process. 5) In a non-DMG STA, pass MSDUs or A-MSDUs stored in the buffer up to the next MAC process in order of increasing value of the Sequence Number subfield starting with WinStartB and proceeding sequentially until there is no buffered MSDU or A-MSDU for the next sequential Sequence Number subfield value. For a DMG STA, follow rules defined in item a) 2) above. 1427 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6) Set WinStartB to the Sequence Number subfield value of the last MSDU or A-MSDU that was passed up to the next MAC process plus one. 7) Set WinEndB = WinStartB + WinSizeB â€“ 1. 11 c) If WinStart B +2 SN WinStart B , discard the MPDU (do not store the MPDU in the buffer, and do not pass the MSDU or A-MSDU up to the next MAC process). 10.24.7.6.3 Operation for each received BlockAckReq For each received BlockAckReq frame that is related with a specific HT-immediate block ack agreement, the receive reordering buffer record is modified as follows, where SSN is the Starting Sequence Number subfield value of the received BlockAckReq frame: 11 a) If WinStart B SSN WinStart B +2 , 1) In a block ack agreement that is not a protected block ack agreement, set WinStartB = SSN. See 10.24.9 for a protected block ack agreement. 2) Set WinEndB = WinStartB + WinSizeB â€“ 1. 3) Pass any complete MSDUs or A-MSDUs stored in the buffer with Sequence Number subfield values that are lower than the new value of WinStartB up to the next MAC process in order of increasing Sequence Number subfield value. Gaps may exist in the Sequence Number subfield values of the MSDUs or A-MSDUs that are passed up to the next MAC process. 4) Pass MSDUs or A-MSDUs stored in the buffer up to the next MAC process in order of increasing Sequence Number subfield value starting with SN=WinStartB and proceeding sequentially until there is no buffered MSDU or A-MSDU for the next sequential Sequence Number subfield value. 5) Set WinStartB to the Sequence Number subfield value of the last MSDU or A-MSDU that was passed up to the next MAC process plus one. 6) Set WinEndB = WinStartB + WinSizeB â€“ 1. 11 b) If WinStart B +2 SSN WinStart B , do not make any changes to the receive reordering buffer record. 10.24.7.7 Originatorâ€™s behavior A STA may send a block of data in a single A-MPDU where each Data frame has its Ack Policy field set to Normal Ack. The originator expects to receive a BlockAck frame response immediately following the A-MPDU if at least one Data frame is received without error. Alternatively, the originator may send an A-MPDU where each Data frame has its Ack Policy field set to Block Ack under an HT-immediate block ack agreement if it does not require a BlockAck frame response immediately following the A-MPDU. If the BlockAck frame is lost, the originator may transmit a BlockAckReq frame to solicit an immediate BlockAck frame or it may retransmit the Data frames. A BlockAckReq frame sent using HT-delayed operation may be transmitted within an A-MPDU provided that its BAR Ack Policy subfield is set to No Acknowledgment. The originator may transmit QoS Data frames with a TID matching an established block ack agreement in any order provided that their sequence numbers lie within the current transmission window. The originator may transmit an MPDU with a sequence number that is beyond the current transmission window (SN > WinStartO + WinSizeO â€“ 1), in which case the originatorâ€™s transmission window (and the recipientâ€™s window) is moved forward. The originator should not transmit MPDUs that are lower than (i.e., SN < WinStartO) the current transmission window. 1428 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The originator shall not retransmit an MPDU after that MPDUâ€™s appropriate lifetime limit. The originator may send a BlockAckReq frame for block ack agreement that is not a protected block ack agreement or a robust ADDBA Request frame for protected block ack agreement when a Data frame that was previously transmitted within an A-MPDU that had the Ack Policy field equal to Normal Ack is discarded due to exhausted MSDU lifetime. The purpose of this BlockAckReq or robust ADDBA Request frame is to shift the recipientâ€™s WinStartB value past the hole in the sequence number space that is created by the discarded Data frame and thereby to allow the earliest possible passing of buffered frames up to the next MAC process. An originator that is a DMG STA shall transmit MPDUs sent under a BA agreement such that: â€” MPDUs that need to be retransmitted are transmitted first, in sequential order of sequence number, starting from the oldest MPDU that needs to be retransmitted â€” MPDUs that are being transmitted for the first time are sent after any MPDUs that need to be retransmitted, in sequential order of sequence number, starting from the oldest MPDU that has not been transmitted â€” MPDUs are transmitted with the Ack Policy subfield set to Block Ack if the A-MPDU that contains them is followed after SIFS or RIFS by another A-MPDU An originator that is a DMG STA shall not start a new TXOP or SP with an MPDU or A-MPDU that has an Ack policy other than Normal Ack if at least one frame transmitted by the originator to the recipient in the last PPDU did not require an immediate response. 10.24.7.8 Maintaining block ack state at the originator If an originator successfully receives a BlockAck frame in response to a BlockAckReq frame, the originator shall maintain block ack state as defined in 10.24.3. If the originator receives a BlockAck frame in response to an HT-immediate BlockAckReq frame, it shall, in addition, â€” Not update the status of MPDUs with Sequence Number subfield values between WinStartO and SSN of the received BlockAck frame, and NOTEâ€”It is possible for the Starting Sequence Number subfield value (SSN) of the received BlockAck frame to be greater than WinStartO because of the failed reception of a nonzero number of MPDUs beginning with the MPDU with Sequence Number subfield value equal to WinStartO at a recipient that is using partial-state operation. â€” Not update the status of MPDUs that have been already positively acknowledged. NOTEâ€”This second rule means that if an originator successfully delivered an MPDU and received the BlockAck frame in one TXOP and then receives a BlockAck frame in a later TXOP in which the MPDU is not indicated as successfully received (because the partial state has been reset), the originator knows not to retry the MPDU. 10.24.7.9 Originatorâ€™s support of recipientâ€™s partial state A recipient may choose to employ either full-state operation or partial-state operation for each individual block ack agreement. An originator is unaware of the recipientâ€™s choice of full-state or partial-state operation. NOTEâ€”The originator might solicit a BlockAck frame as the last activity associated with that block ack agreement in the current TXOP to reduce the probability that data are unnecessarily retransmitted due to loss of partial state. 1429 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.24.8 HT-delayed block ack extensions 10.24.8.1 Introduction Subclauses 10.24.8.2 and 10.24.8.3 define an HT extension to the block ack feature to support operation on delayed block ack agreements established between HT STAs. Other than the exceptions noted in 10.24.8.1 through 10.24.8.3, the operation of HT-delayed block ack is the same as is described in 10.24.7. The HT-delayed extensions simplify the use of delayed block ack in an A-MPDU and reduce resource requirements. A DMG STA shall not use HT-delayed block ack. 10.24.8.2 HT-delayed block ack negotiation HT-delayed block ack is an optional feature. An HT STA declares support for HT-delayed block ack in the HT Capabilities element. An HT STA shall not attempt to create a block ack agreement under HT-delayed block ack policy unless the recipient HT STA declares support for this feature. 10.24.8.3 Operation of HT-delayed block ack The BlockAck frame response to an HT-delayed BlockAckReq frame is transmitted after an unspecified delay and when the recipient of the BlockAckReq frame next has the opportunity to transmit. This response may be transmitted in a later TXOP owned by the recipient of the BlockAckReq frame or in the current or a later TXOP owned by the sender of the BlockAckReq frame using the RD feature (see 10.28). The BAR Ack Policy subfield of a BlockAckReq frame and the BA Ack Policy subfield of a BlockAck frame may be set to No Acknowledgment under an HT-delayed block ack agreement. A BlockAckReq or BlockAck frame containing a BAR Ack Policy or BA Ack Policy subfield equal to 1 indicates that no acknowledgment is expected to these Control frames. Otherwise, a response that is an Ack frame is expected after a SIFS. Setting of the BAR Ack Policy and BA Ack Policy subfields may be performed independently for BlockAckReq and BlockAck frames associated with the same HT-delayed block ack agreement. All four combinations of the values of these fields are valid. Setting of the BAR Ack Policy and BA Ack Policy subfields is dynamic and may change from PPDU to PPDU. 10.24.9 Protected block ack agreement A STA indicates support for protected block ack by setting the RSN Capabilities field subfields Management Frame Protection Capable (MFPC), Management Frame Protection Required (MFPR) and PBAC to 1. Such a STA is a PBAC STA; otherwise, the STA is a non-PBAC STA. A block ack agreement that is successfully negotiated between two PBAC STAs is a protected block ack agreement. A block ack agreement that is successfully negotiated between two STAs when either or both of the STAs is not a PBAC STA is a block ack agreement that is not a protected block ack agreement. A PBAC STA may choose to negotiate a block ack agreement with a non-PBAC STA if dot11RSNAPBACRequired is 0; otherwise, it shall negotiate a block ack agreement only with other PBAC 1430 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STAs. If a PBAC STA is communicating with a non-PBAC STA, it shall follow the rules for a nonprotected block ack agreement. A STA that has successfully negotiated a protected block ack agreement shall obey the following rule as a block ack originator in addition to rules specified in 10.24.7.7 and 10.24.7.8: â€” To change the value of WinStartB at the receiver, the STA shall use a robust ADDBA Request frame. A STA that has successfully negotiated a protected block ack agreement shall obey the following rules as a block ack recipient in addition to rules specified in 10.24.7.3 to 10.24.7.6: â€” The recipient STA shall respond to a BlockAckReq frame from a PBAC enabled originator with an immediate BlockAck frame. The Block Ack Starting Sequence Control subfield value shall be ignored for the purposes of updating the value of WinStartB. The Block Ack Starting Sequence Control subfield value may be utilized for the purposes of updating the value of WinStartR. If the Block Ack Starting Sequence Control subfield value is greater than WinEndB or less than WinStartB, dot11PBACErrors shall be incremented by 1. â€” Upon receipt of a valid robust ADDBA Request frame for an established protected block ack agreement whose TID and transmitter address are the same as those of the block ack agreement, the STA shall update its WinStartR and WinStartB values based on the starting sequence number in the robust ADDBA Request frame according to the procedures outlined for reception of BlockAckReq frames in 10.24.7.3, 10.24.7.4, 10.24.7.6.1, and 10.24.7.6.3, while treating the starting sequence number as though it were the SSN of a received BlockAckReq frame. Values in other fields of the ADDBA Request frame shall be ignored. 10.24.10 GCR block ack 10.24.10.1 Introduction Subclause 10.24.10 extends the block ack mechanism to group addressed frames that are transmitted using the GCR block ack retransmission policy. Other than the exceptions noted in 10.24.10.2 through 10.24.10.3, the operation of GCR block ack is the same as is described in 10.24.7. 10.24.10.2 Scoreboard context control during GCR block ack For each GCR block ack agreement, each recipient shall maintain a block acknowledgment record as defined in 10.24.3. This record includes the following information: â€” A bitmap, indexed by sequence number â€” A 12-bit unsigned integer starting sequence number â€” WinStartR, representing the lowest sequence number position in the bitmap â€” A variable WinEndR â€” The maximum transmission window size, WinSizeR WinSizeR is set to the smaller of 64 and the value of the Buffer Size field of the associated ADDBA Response frame that established the block ack agreement. WinEndR is defined as the highest sequence number in the current transmission window. A STA implementing a GCR block ack agreement shall maintain the block acknowledgment record for that agreement according to the following rules: a) At GCR block ack agreement establishment: 1) WinStartR = the Starting Sequence Number subfield value (SSN) from the ADDBA Request frame that elicited the ADDBA Response frame that established the GCR block ack agreement. 2) WinEndR = WinStartR + WinSizeR â€“ 1. 1431 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications b) For each received Data frame that is related with a specific GCR block ack agreement, the block acknowledgment record for that agreement is modified as follows, where SN is the value of the Sequence Number subfield of the received Data frame: 1) If WinStartR â‰¤ SN â‰¤ WinEndR, set to 1 the bit in position SN within the bitmap. 2) If WinEndR < SN < WinStartR + 211, i) Set to 0 the bits corresponding to MPDUs with Sequence Number subfield values from WinEndR + 1 to SN â€“ 1. ii) Set WinStartR = SN â€“ WinSizeR + 1. iii) Set WinEndR = SN. iv) Set to 1 the bit at position SN in the bitmap. 3) If WinStartR +211 â‰¤ SN â‰¤ WinStartR, make no changes to the record. c) For each received BlockAckReq frame that is related with a specific GCR block ack agreement, the block acknowledgment record for that agreement is modified as follows, where SSN is the value from the Starting Sequence Number subfield of the received BlockAckReq frame: 1) If WinStartR < SSN â‰¤ WinEndR, i) Set WinStartR = SSN. ii) Set to 0 the bits corresponding to MPDUs with Sequence Number subfield values from WinEndR + 1 through WinStartR + WinSizeR â€“ 1. iii) Set WinEndR = WinStartR + WinSizeR â€“ 1. 2) If WinEndR < SSN < WinStartR + 211, i) Set WinStartR = SSN. ii) Set WinEndR = WinStartR + WinSizeR â€“ 1. iii) Set to 0 bits the corresponding to MPDU with Sequence Number subfield values from WinStartR to WinEndR. 3) If WinStartR + 211 â‰¤ SSN â‰¤ WinStartR, make no changes to the record. 10.24.10.3 GCR block ack BlockAckReq and BlockAck frame exchanges A protective mechanism (such as transmitting an HCCA CAP, MCCA, or RTS/CTS; setting the Duration field in the first frame and response frames to update the NAVs of STAs in the BSS and OBSS(s); or using another mechanism described in 10.26 and 10.3.2.8) should be used to reduce the probability of other STAs transmitting during the GCR TXOP. When the retransmission policy for a group address is GCR Block Ack, an originator shall not transmit more than the GCR buffer size number of A-MSDUs with RA set to the GCR concealment address and the DA field of the A-MSDU subframe set to the GCR group address before sending a BlockAckReq frame to one of the STAs that has a GCR block ack agreement for this group address. The RA field of the BlockAckReq frame shall be set to the MAC address of the destination STA. Upon reception of the BlockAck frame, an originator may send a BlockAckReq frame to another STA that has a block ack agreement for this group address, and this process may be repeated multiple times. NOTE If the originator sends a BlockAckReq frame to a STA with a MAC address that matches the SA in any of the A-MSDUs transmitted during the GCR TXOP, the Block Ack Bitmap subfield does not indicate the MSDUs sourced from this STA. This is because the STA will have discarded all group addressed MPDUs transmitted by the AP that have the source address equal to their MAC address (see 10.3.6). When a recipient receives a BlockAckReq frame with the GCR Group Address subfield equal to a GCR group address, the recipient shall transmit a BlockAck frame at a delay of SIFS after the BlockAckReq frame. The BlockAck frame acknowledges the STAâ€™s reception status of the block of group addressed frames requested by the BlockAckReq frame. 1432 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Figure 10-36 shows an example of a frame exchange when the GCR block ack retransmission policy is used. The AP sends several A-MSDUs using the GCR block ack retransmission policy. The AP then sends a BlockAckReq frame to group member 1 of the GCR group, waits for the BlockAck frame, and then sends a BlockAckReq frame to group member 2. After receiving the BlockAck frame from GCR group member 2, the AP determines whether any A-MSDUs need to be retransmitted and sends additional A-MSDUs (some of which might be retransmissions of previous A-MSDUs) using the GCR block ack retransmission policy. Block Block Data Data Data AckReq AckReq AP Block Ack GCR group member 1 Block Ack GCR group member 2 GCR group member 3 Figure 10-36â€”Example of frame exchange with GCR block ack retransmission policy After completing the BlockAckReq and BlockAck frame exchanges, the originator determines from the information provided in the BlockAck bitmap and from the missing BlockAck frames which, if any, A-MSDUs need to be retransmitted. An originator adopting the GCR block ack retransmission policy for a GCR group address chooses a lifetime limit for the group address. The originator may vary the lifetime limit for the group address at any time and may use different lifetime limits for different GCR group addresses. The originator transmits and retries each A-MSDU until the appropriate lifetime limit is reached or until each one has been received by all group members to which a BlockAckReq frame has been sent, whichever occurs first. For GCR streams with retransmission policy equal to GCR Block Ack, an originator may regularly send a BlockAckReq frame with the GCR Group Address subfield in the BAR Information field set to the GCR group address and the Block Ack Starting Sequence Control subfield set to the Sequence Number field of the earliest A-MSDU of the GCR stream that has not been acknowledged by all group members and has not expired due to lifetime limits, in order to minimize buffering latency at receivers in the GCR group. NOTE This is because an originator might transmit Management frames, QoS Data frames with a group address in the Address 1 field (including different GCR streams), and non-QoS Data frames intermingled. Since these are transmitted using a single sequence counter, missing frames or frames sent to group addresses absent from a receiving STAâ€™s dot11GroupAddresses table complicate receiver processing for GCR streams with a GCR block ack retransmission policy since the cause of a hole in a receiverâ€™s block ack bitmap is ambiguous: it is due either to an MPDU being lost from the GCR stream or to transmissions of MPDUs not related to the GCR service using the same sequence number counter. If an originator accepts two or more GCR agreements with multiple STAs where the GCR agreements have the same Ethernet classifiers, but different additional classifiers, then each STA receives multiple GCR flows from the originator and sends them to upper layers where the MSDUs irrelevant to the STA are discarded, in the same manner that non-GCR MSDUs irrelevant to the STA are discarded. In the Block Ack Bitmap field sent to the originator, each STA sets bits corresponding to MPDUs received from any of the multiple GCR streams. The originator should not retry MPDUs to the STA for the bit positions that are irrelevant to that STA. 1433 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The beginning of reception of an expected response to a BlockAckReq frame is detected by the occurrence of a PHY-CCA.indication(BUSY, channel-list) primitive at the STA that is expecting the response where the channel-list parameter is absent or, if present, includes â€œprimary.â€ If the beginning of such reception does not occur during the first slot time following a SIFS, then the originator may perform error recovery by retransmitting a BlockAckReq frame PIFS after the previous BlockAckReq frame when both of the following conditions are met: â€” The carrier sense mechanism (see 10.3.2.1) indicates that the medium is idle at the TxPIFS slot boundary (see Figure 10-26) after the expected start of a BlockAck frame, and â€” The remaining duration of the GCR TXOP is longer than the total time required to retransmit the GCR BlockAckReq frame plus one slot time. NOTE If an originator fails to receive a BlockAck frame in response to a BlockAckReq frame and there is insufficient time to transmit a recovery frame, the AP retransmits the BlockAckReq frame in a new TXOP. 10.24.11 DMG block ack with flow control 10.24.11.1 General A DMG STA indicates that it is capable of supporting DMG block ack with flow control by setting the BA with Flow Control field to 1 within the STAâ€™s DMG Capabilities element. A DMG block ack agreement with flow control can be established only when both originator and recipient support this capability. 10.24.11.2 DMG block ack architecture with flow control The DMG block ack rules are explained in terms of the architecture shown in Figure 10-37 and explained in this subclause. Originator Recipient Receive Reordering Buffer Control per RA/TID Transmit Buffer Control (WinTailB, WinHeadB, WinCapacityB, per RA/TID WinStartB , WinEndB, BufSizeB) (WinStartO , WinEndO, BufSizeO, Scoreboard Context WinCapacityO, WinLimitO) Control (WinStartR , WinSizeR) Aggregation Control Deaggregation Control A-MPDU BlockAck {SSN, Bitmap, RBUFCAP} Figure 10-37â€”DMG block ack architecture The originator contains a transmit buffer control that uses WinStartO, BufSizeO, and WinLimitO to submit MPDUs for transmission, and releases transmit buffers upon receiving BlockAck frames from the recipient or when it advances the transmit control buffer window. WinStartO is the starting sequence number of the transmit range, WinLimitO is the last sequence number expected to exhaust the receiver buffer capacity, and BufSizeO is the number of buffers negotiated in the block ack agreement. Figure 10-38 shows the DMG block ack with flow control and its associated parameters from the originator perspective. 1434 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Receiver Buffer seen by Originator WinEndO WinHeadO WinTailO WinStartO What the Transmitter maintains WinStartO = Starting Seq . Number BufSizeO = Receiver Buffer Size negotiated BufSizeO=WinCapacityO WinLimitO = WinEndO Figure 10-38â€”Flow control and its associated parameters as a function of receiver buffer size The Aggregation control creates A-MPDUs. It can adjust the Ack Policy field of transmitted Data frames according to the rules defined in 10.24.7.7 in order to solicit block ack responses. The recipient contains a Receive Reordering Buffer Control per TA/TID, which contains related control state. The receive reordering buffer is responsible for reordering MSDUs or A-MSDUs so that MSDUs or A-MSDUs are eventually passed up to the next MAC process in order of received sequence number (SN). It maintains its own state independent of the scoreboard context control to perform this reordering as specified in 10.24.7.6. The delivery of in order MSDUs or A-MSDUs to the next MAC process is implementation dependent. In some cases, the receiver reordering buffer might be forced to hold on to MSDUs ready for in order delivery due to deferred reception at the next MAC process. This behavior can impose additional buffering requirements on the receiver, causing the actual available buffer capacity to vary dynamically. The reordering buffer is required to manage its lowest and highest (in order) SN, which are marked as WinTailB and WinHeadB, respectively. The scoreboard context control provides the WinCapacityB, actually controlled by the Reordering buffer in addition to the bitmap field and the Starting Sequence Number (SSN) field to be sent in BlockAck frame responses to the originator. 10.24.11.3 Scoreboard context control with flow control The scoreboard context control with flow control is defined in 10.24.7.3 and 10.24.7.4. 10.24.11.4 Receive Reordering Buffer with flow control operation 10.24.11.4.1 General A recipient shall maintain a receive reordering buffer for each DMG block ack agreement. Each receive reordering buffer includes a record comprising the following: â€” Buffered MSDUs or A-MSDUs that have been received, but not yet passed up to the next MAC process â€” A WinStartB parameter, indicating the value of the Sequence Number field (SN) of the first (in order of ascending sequence number) MSDU or A-MSDU that has not yet been received â€” A WinEndB parameter, indicating the highest SN expected to be received in the current reception range â€” A BufSizeB parameter, indicating the size of the reception window 1435 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” A WinTailB parameter, indicating the value of the Sequence Number field (SN) of the first (in order of ascending sequence number) MSDU or A-MSDU that has not yet been delivered to the next MAC process â€” A WinHeadB parameter, indicating the highest SN received in the current reception range WinStartB is initialized to the Starting Sequence Number field value (SSN) of the ADDBA Request frame that elicited the ADDBA Response frame that established the DMG block ack agreement. WinEndB is initialized to WinStartB + BufSizeB â€“ 1, where BufSizeB is set to the value of the Buffer Size field of the ADDBA Response frame that established the block ack agreement. Both WinTailB and WinHeadB are initialized to the preceding Starting Sequence Number field value (SSN â€“ 1), to indicate no MPDU was received, within the current reception window. Any MSDU or A-MSDU that has been passed up to the next MAC process shall be deleted from the receive reordering buffer, advancing the WinTailB. The recipient shall pass MSDUs or A-MSDUs up to the next MAC process in order of increasing Sequence Number field value. 10.24.11.4.2 Operation for DMG block ack agreement initialization At DMG block ack agreement establishment: a) WinStartB = SSN from the ADDBA Request frame that elicited the ADDBA Response frame that established the DMG block ack agreement b) WinEndB = WinStartB + BufSizeB â€“ 1 c) WinCapacityB = BufSizeB d) WinHeadB = SSN â€“ 1, where SSN is taken from the ADDBA Request, similar to WinStartB e) WinTailB = SSN â€“ 1 10.24.11.4.3 Operation for each received Data frame For each received Data frame that is related to a specific DMG block ack agreement, the receive reordering buffer record is modified as follows, where SN is the value of the Sequence Number field of the received MPDU: a) If WinStart B SN WinEnd B 1) Store the received MPDU in the buffer. i) If SN > WinHeadB, Set WinHeadB = SN. ii) If SN > (WinTailB + BufSizeB), 1) All MSDU buffers with sequence numbers from WinTailB to SN â€“ BufSizeB that were received correctly are passed to the next MAC process. 2) Set WinTailB = SN â€“ BufSizeB. iii) Set WinCapacityB = WinTailB + BufSizeB â€“ WinHeadB. 2) Set WinStartB to the value of the Sequence Number field of the first MSDU or A-MSDU that is missing to allow in-order delivery to the next MAC process. 3) Set WinEndB = WinStartB + BufSizeB â€“ 1. b) If WinEndB < SN < WinStartB + 211 1) Store the received MPDU in the buffer. 2) Set WinEndB = SN. 1436 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 3) Set WinStartB = WinEndB â€“ BufSizeB + 1. 4) All MSDU buffers with sequence numbers from WinTailB to SN â€“ BufSizeB that were received correctly are passed to the next MAC process. 5) Set WinTailB = SN â€“ BufSizeB. 6) Set WinHeadB = SN. 7) Set WinCapacityB = WinTailB + BufSizeB â€“ WinHeadB. 11 c) If WinStart B + 2 SN WinStart B , discard the MPDU (do not store the MPDU in the buffer, do not pass the MSDU or A-MSDU up to the next MAC process). d) For each received BlockAckReq frame the block acknowledgment record for that agreement is modified as follows, where SSN is the value from the Starting Sequence Number field of the received BlockAckReq frame: 1) If WinStart B SSN WinEnd B i) Set WinStartB = SSN. ii) Set WinEndB = WinStartB + BufSizeB â€“ 1. iii) If SSN > WinHeadB, set WinHeadB = SSN â€“ 1. iv) If SSN > (WinTailB + BufSizeB), 1) All MSDU buffers with sequence numbers from WinTailB to SSN â€“ BufSizeB, are discarded from the buffer. 2) Set WinTailB = SSN â€“ BufSizeB. v) Set WinCapacityB = WinTailB + BufSizeB â€“ WinHeadB. 2) If WinEndB < SSN < WinStartB + 211 i) Set WinStartB = SSN. ii) Set WinEndB = WinStartB + BufSizeB â€“ 1. iii) Set WinHeadB = SSN â€“ 1. iv) If SSN > (WinTailB + BufSizeB), 1) All MSDU buffers with sequence numbers from WinTailB to SSN â€“ BufSizeB, are discarded from the buffer. 2) Set WinTailB = SSN â€“ BufSizeB. v) Set WinCapacityB = WinTailB + BufSizeB â€“ WinHeadB. 11 3) If WinStart B + 2 SSN WinStart B , make no changes to the record. 10.24.11.4.4 Operation for ongoing release of received MPDUs The reordering buffer shall continue to pass MSDUs or A-MSDUs up to the next MAC process that are stored in the buffer in order of increasing value of the Sequence Number field, starting with the MSDU or A-MSDU that has SN = WinTailB and proceeding sequentially until there is no ready in-order MSDU or A-MSDU buffered for the next sequential value of the Sequence Number field. a) Set WinTailB to the value of the Sequence Number field of the last MSDU or A-MSDU that was passed up to the next MAC process plus one. 10.24.11.5 Generation and transmission of BlockAck frame by a STA with flow control In addition to the behavior specified in 10.24.7.5 when responding with a BlockAck frame, the RBUFCAP field shall be updated with the value of WinCapacityB. 1437 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.24.11.6 Originatorâ€™s behavior with flow control support If the BA with Flow Control field within a recipientâ€™s DMG Capabilities element is equal to 1, the originator shall not transmit an MPDU with a SN that is beyond the current recipientâ€™s buffer capacity (WinLimitO). The BlockAck frame indicates the number of free buffer slots available at the recipient for reception of additional MPDUs. The originator shall update the variable WinLimitO upon reception of a valid BlockAck: â€” Set WinCapacityO to the received value of the RBUFCAP field in the BlockAck frame. â€” Set MostSuccSN to the highest SN of positively acknowledged MPDUs â€” Set WinLimitO = MostSuccSN + WinCapacityO NOTEâ€”Updating the variable WinLimitO limits the transmission of the following MPDUs. Originatorâ€™s support of recipientâ€™s partial state is defined in 10.24.7.9. 10.25 No Acknowledgment (No Ack) When a QoS Data frame is transmitted with the Ack Policy subfield set to No Ack, there is no MAC-level recovery, and the reliability of this traffic is reduced, relative to the reliability of traffic with other acknowledgment policies, due to the increased probability of lost frames from interference, collisions, or time- varying channel parameters. A protective mechanism (such as transmitting using HCCA, RTS/CTS, or the mechanism described in 10.26) should be used to reduce the probability of other STAs transmitting during the TXOP. 10.26 Protection mechanisms 10.26.1 Introduction These protection mechanisms cause a STA that is a potential interferer to defer any transmission for a known period of time. When these mechanisms are used, non-ERP STAs do not interfere with frame exchanges using ERP PPDUs between ERP STAs and non-HT STAs do not interfere with frame exchanges using HT PPDUs between HT STAs. 10.26.2 Protection mechanism for non-ERP receivers The intent of a protection mechanism is to cause a STA not to transmit an MPDU with the Type subfield equal to Data or an MMPDU with an ERP-OFDM preamble and header unless it has attempted to update the NAV of receiving NonERP STAs. The updated NAV period shall be longer than or equal to the total time required to send the Data and any required response frames. An ERP STA shall use protection mechanisms (such as RTS/ CTS or CTS-to-self) for ERP-OFDM MPDUs with the Type subfield equal to Data or an MMPDU when the Use_Protection field of the ERP element is equal to 1 (see the requirements of 10.7). Protection mechanisms frames shall be sent using one of the mandatory Clause 15 or Clause 16 rates and using one of the mandatory Clause 15 or Clause 16 waveforms, so all STAs in the BSA are able to learn the duration of the exchange even if they cannot detect the ERP-OFDM signals using their CCA function. In the case of a BSS composed of only ERP STAs, but with knowledge of a neighboring co-channel BSS having NonERP traffic, the AP might need protection mechanisms to protect the BSSâ€™s traffic from interference. This provides propagation of NAV to all attached STAs and all STAs in a neighboring co-channel BSS within range by messages sent using rates contained in the BSSBasicRateSet parameter. The frames that propagate the NAV throughout the BSS include RTS/CTS/Ack frames, all Data frames with the More 1438 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Fragments field equal to 1, all Data or Management frames sent in response to PS-Poll frame that are not proceeded in the frame exchange sequence by a Data frame with the More Fragments field equal to 1, Beacon frames with nonzero CFDurRemaining, CF-End frames, and CF-End +CF-Ack frames. When RTS/CTS is used as the protection mechanism, cases exist such as NAV resetting (discretionary, as indicated in 10.3.2.4), where a hidden STA may reset its NAV and this may cause a collision. The likelihood of occurrence is low, and it is not considered to represent a significant impairment to overall system operation. A mechanism to address this possible situation would be to use alternative protection mechanisms or to revert to alternative modulation methods. The rules for calculating RTS/CTS NAV fields are unchanged when using RTS/CTS as a protection mechanism. Additionally, if any of the rates in the BSSBasicRateSet parameter of the protection mechanism frame transmitting STAâ€™s BSS are Clause 15 or Clause 16 rates, then the protection mechanism frames shall be sent at one of those Clause 15 or Clause 16 basic rates. The NonERP_Present bit shall be set to 1 when a NonERP STA is associated with the BSS. In an IBSS if a member of an IBSS detects one or more NonERP STAs that are members of the same IBSS the NonERP_Present bit should be set to 1. Examples of when the NonERP present bit may additionally be set to 1 include, but are not limited to, when: a) A NonERP infrastructure BSS or NonERP IBSS is overlapping (a NonERP BSS may be detected by the reception of a Beacon frame where the supported rates contain only Clause 15 or Clause 16 rates). b) In an IBSS if a Beacon frame is received from one of the IBSS participants where the operational rate set contains no Clause 18 rates and no BSS membership selectors. c) A Management frame (excluding a Probe Request) is received where the operational rate set contains no Clause 18 rates and no BSS membership selectors. A NonERP mesh STA shall set the NonERP_Present and Use_Protection bits to 1, when establishing a mesh peering with a mesh STA. When a mesh STA establishes a mesh peering with a NonERP mesh STA, the mesh STA shall set the NonERP_Present bit to 1 and the mesh STA should set the Use_Protection bit to 1. In addition, a mesh STA should set the NonERP_Present bit and the Use_Protection bit to 1 when â€” A mesh STA detects the overlapped presence of either a NonERP BSS, a NonERP IBSS, or a NonERP MBSS, or â€” A Beacon frame is received from a neighbor STA where the operational rate set contains no Clause 18 rates and no BSS membership selectors, or â€” A Management frame (excluding Probe Request) is received where the operational rate set contains no Clause 18 rates and no BSS membership selectors. A mesh STA may set the NonERP_Present and the Use_Protection bits to 1 based on its internal policies, which is beyond the scope of the standard. The Use_Protection bit may be set to 1 when the NonERP_Present bit is 1. If one or more NonERP STAs are associated in the BSS, the Use_Protection bit shall be set to 1 in transmitted ERP elements. In an IBSS the setting of the Use_Protection bit is left to the STA. In an IBSS there is no uniform concept of association; therefore, a typical algorithm for setting the Use_Protection bit takes into account the traffic 1439 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications pattern and history on the network. If a member of an IBSS detects one or more NonERP STAs that are members of the same IBSS or receives a Beacon from a member of the same IBSS with the Use_Protection bit equal to 1, then the Use_Protection bit should be set to 1 in the ERP element of transmitted Beacon and Probe Response frames. An ERP STA shall invoke the use of a protection mechanism after transmission or reception of the Use_Protection bit with a value of 1 in an MMPDU to or from the BSS that the ERP STA has joined or started. An ERP STA may additionally invoke protection mechanism use at other times. An ERP STA may disable protection mechanism use after transmission or reception of the Use_Protection bit with a value of 0 in an MMPDU to or from the BSS that the ERP STA has joined or started. An ERP mesh STA shall invoke the use of a protection mechanism after the transmission of the Use_Protection bit with a value of 1 in an MMPDU. In addition, an ERP mesh STA may invoke protection mechanism at other times. An ERP mesh STA may disable protection mechanism use after transmission of the Use_Protection bit with a value of 0 in an MMPDU. When there are no NonERP STAs associated with the BSS and the ERP element senderâ€™s dot11ShortPreambleOptionImplemented is true, then the Barker_Preamble_Mode bit may be set to 0. The Barker_Preamble_Mode bit shall be set to 1 by the ERP element sender if one or more associated NonERP STAs are not short preamble capable as indicated in their Capability Information field, or if the ERP element senders dot11ShortPreambleOptionImplemented is false. When dot11ShortPreambleOptionImplemented is true and all peer mesh STAs support the short preamble, the mesh STA may set the Barker_Preamble_Mode bit to 0. When dot11ShortPreambleOptionImplemented is false or any of its peer mesh STAs do not support the short preamble, the mesh STA shall set the Barker_Preamble_Mode field to 1. If a member of an IBSS detects one or more nonshort-preamble-capable STAs that are members of the same IBSS, then the Barker_Preamble_Mode bit should be set to 1 in the transmitted ERP element. An ERP STA shall use long preambles when transmitting Clause 15, Clause 16, and Clause 18 frames after transmission or reception of an ERP element with a Barker_Preamble_Mode value of 1 in an MMPDU to or from the BSS that the ERP STA has joined or started, regardless of the value of the short preamble capability bit from the same received or transmitted MMPDU that contained the ERP element. An ERP STA may additionally use long preambles when transmitting Clause 15, Clause 16, and Clause 18 frames at other times. An ERP STA may use short preambles when transmitting Clause 15, Clause 16, and Clause 18 frames after transmission or reception of an ERP element with a Barker_Preamble_Mode value of 0 in an MMPDU to or from the BSS that the ERP STA has joined or started, regardless of the value of the short preamble capability bit from the same received or transmitted MMPDU. A NonERP STA may also follow the rules given in this paragraph. An ERP mesh STA shall use long preambles when transmitting Clause 15, Clause 16, and Clause 18 frames after transmission or reception of an ERP element with a Barker_Preamble_Mode value of 1 in an MMPDU to or from the MBSS to which the ERP mesh STA belongs. A Mesh STA may use long preambles when transmitting Clause 15, Clause 16, and Clause 18 frames at other times. 10.26.3 Protection mechanisms for transmissions of HT PPDUs 10.26.3.1 General Transmissions of HT PPDUs, referred to as HT transmissions, are protected if there are other STAs present that cannot interpret HT transmissions correctly. The HT Protection and Nongreenfield HT STAs Present fields in the HT Operation element within Beacon and Probe Response frames are used to indicate the protection requirements for HT transmissions. 1440 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The HT Protection field may be set to no protection mode only if the following are true: â€” All STAs detected (by any means) in the primary or the secondary channel are HT STAs, and â€” All STAs that are known by the transmitting STA to be a member of this BSS are either â€” 20/40 MHz HT STAs in a 20/40 MHz BSS, or â€” 20 MHz HT STAs in a 20 MHz BSS. The HT Protection field may be set to nonmember protection mode only if the following are true: â€” A non-HT STA is detected (by any means) in either the primary or the secondary channel or in both the primary and secondary channels, that is not known by the transmitting STA to be a member of this BSS, and â€” All STAs that are known by the transmitting STA to be a member of this BSS are HT STAs. The HT Protection field may be set to 20 MHz protection mode only if the following are true: â€” All STAs detected (by any means) in the primary channel and all STAs detected (by any means) in the secondary channel are HT STAs and all STAs that are members of this BSS are HT STAs, and â€” This BSS is a 20/40 MHz BSS, and â€” There is at least one 20 MHz HT STA associated with this BSS. The HT Protection field is set to non-HT mixed mode otherwise. NOTEâ€”The rules stated above allow an HT AP to select non-HT mixed mode at any time. In an IBSS, the HT Protection field is reserved, but an HT STA shall protect HT transmissions as though the HT Protection field were equal to non-HT mixed mode. A STA that is a member of an IBSS shall protect HT- greenfield format PPDUs and RIFS sequences, adhering to the same requirements as described in the line of Table 10-13 labeled â€œUse_Protection = 0 or ERP element is not present (HT Protection field equal to non-HT mixed mode).â€ Table 10-13â€”Protection requirements for HT Protection field values nonmember protection mode and non-HT mixed mode Condition Requirements Use_Protection = 0 or ERP element is not The protection requirements for HT transmissions using HT- present greenfield format are specified in 10.26.3.1. (HT Protection field equal to non-HT mixed mode) The protection requirements for HT transmissions using RIFS within the HT transmission burst are specified in 10.26.3.3. The protection mechanism for other transmissions not already described above is based on one of the sequences defined in Table 10-14. Use_Protection = 1 All HT transmissions shall be protected using mechanisms as (HT Protection field equal to nonmember described in 10.26.2. protection mode or non-HT mixed mode) In an MBSS, the HT Protection field and the Nongreenfield HT STAs Present field are determined as described in 10.26.3.5. In an IBSS and an MBSS, the RIFS Mode field of the HT Operation element is reserved, but an HT STA shall operate as though this field were equal to 1. 1441 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications During the 40 MHz phase of PCO operation, a PCO active STA may act as though the HT Protection field were equal to no protection mode, regardless of the actual value of the HT Protection field transmitted by the AP. When the HT Protection field is equal to no protection mode or 20 MHz protection mode and the Nongreenfield HT STAs Present field is equal to 0, no protection is required since all HT STAs in the BSS are capable of decoding HT-mixed format and HT-greenfield format transmissions. When the HT Protection field is equal to no protection mode or 20 MHz protection mode and the Nongreenfield HT STAs Present field is equal to 1, HT transmissions that use the HT-greenfield format shall be protected. This protection may be established by transmitting a PPDU with the TXVECTOR FORMAT parameter set to HT_MF or any of the methods described in Table 10-14. Table 10-14â€”Applicable HT protection mechanisms HT protection mechanism Control frames such as RTS/CTS or CTS-to-self prior to the HT transmissions: â€” 20 MHz transmissions use the rates defined in Clause 17 or Clause 18 â€” 40 MHz transmissions use non-HT duplicate frames defined in Clause 19 L-SIG TXOP protection As the first PPDU in the TXOP, send one of: â€” a non-HT PPDU containing a frame that requires an immediate response â€” an HT-mixed format at PPDU containing a frame that requires an immediate response in a non-HT PPDU PPDUs after the first PPDU exchange may be HT-greenfield format PPDUs and/or be separated by RIFS. When the HT Protection field is equal to nonmember protection mode and the Use_Protection field in the ERP element is equal to 0, HT transmissions should be protected. When the HT Protection field is equal to nonmember protection mode, the Use_Protection field in the ERP element is equal to 0, and the Nongreenfield HT STAs Present field is equal to 1, HT transmissions using HT-greenfield format shall be protected. When the HT Protection field is equal to nonmember protection mode and the Use_Protection field in the ERP element is equal to 1, HT transmissions shall be protected according to the requirements described in Table 10-13. When the HT Protection field is equal to non-HT mixed mode, HT transmissions shall be protected. The type of protection required depends on the type of transmission as well as the type of the non-HT STAs that are present in the BSS. Protection requirements that apply when the HT Protection field is equal to non-HT mixed mode are described in Table 10-13. If the transmission requires protection and the Use_Protection field within the ERP element is equal to 0 or the ERP element is not present in the Beacon, HT transmissions shall be protected using one of the mechanisms identified in Table 10-14. NOTEâ€”Rules for rate selection for the HT protection mechanisms listed in Table 10-14 are described in 10.7. If the HT Protection field is equal to no protection mode and the Secondary Channel Offset field is equal to SCA or SCB, a STA may transmit a 40 MHz HT PPDU (TXVECTOR parameter CH_BANDWIDTH set to HT_CBW40) to initiate a TXOP provided that the restrictions specified in 10.7 are obeyed. When the HT Protection field is not equal to no protection mode or the Secondary Channel Offset field is equal to SCN, a 1442 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STA shall not transmit a 40 MHz HT PPDU (TXVECTOR parameter CH_BANDWIDTH set to HT_CBW40) to initiate a TXOP. 10.26.3.2 Protection rules for HT STA operating a direct link An HT STA operating a direct link with another HT STA in a non-HT BSS shall operate according to the rules found in 10.26 as though the following fields have the settings indicated: a) The RIFS Mode field of the HT Operation element equal to 1 b) The HT Protection field equal to non-HT mixed mode c) The Nongreenfield HT STAs Present field equal to 1 d) The OBSS Non-HT STAs Present field equal to 1 e) The L-SIG TXOP Full Support field equal to 0 f) The PCO Active field equal to 0 g) The Basic HT-MCS Set field equal to all 0s 10.26.3.3 RIFS protection If the HT Protection field is equal to nonmember protection mode or non-HT mixed mode, the AP may set the RIFS Mode field to 0 according to implementation-specific criteria (i.e., such as to protect overlapping non-HT BSSs in the primary or secondary channels). If the HT Protection field is not equal to nonmember protection mode and it is not equal to non-HT mixed mode, the RIFS Mode field shall be set to 1. If the RIFS Mode field of an APâ€™s HT Operation element is equal to 1: a) A STA that is associated with the AP may protect RIFS sequences when the HT Protection field of the HT Operation element transmitted by the AP is equal to nonmember protection mode. b) A STA that is associated with the AP shall protect RIFS sequences when the HT Protection field of the HT Operation element transmitted by the AP is equal to non-HT mixed mode. 10.26.3.4 Use of OBSS Non-HT STAs Present field The OBSS Non-HT STAs Present field allows HT APs to report the presence of non-HT STAs that are not members of its BSS in the primary channel, the secondary channel, or in both primary and secondary channels. A second HT AP that detects a first HT APâ€™s Beacon frame with the OBSS Non-HT STAs Present field equal to 1 may cause HT-greenfield format and RIFS sequence transmissions of the second APâ€™s BSS to be protected by setting the HT Protection field of its HT Operation element to non-HT mixed mode. If the NonERP_Present field is equal to 1 in the first APâ€™s Beacon frame, the Use_Protection field may also be set to 1 by the second AP. An HT STA may also scan for the presence of non-HT devices either autonomously or, for example, after the STAâ€™s AP transmits an HT Operation element with the HT Protection field equal to nonmember protection mode. Non-HT devices can be detected as follows: â€” Reception of a Management frame that does not carry an HT Capabilities element and the frame is required to carry this element when transmitted by an HT STA, or â€” Reception of a Beacon frame containing an HT Operation element with the OBSS Non-HT STAs Present field equal to 1. When non-HT devices are detected, the STA may enable protection of its HT-greenfield format and RIFS sequence transmissions. 1443 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NOTEâ€”If a non-HT device is detected and the STA determines that its HT-greenfield format or RIFS sequence transmissions are affecting the operation of the non-HT device, then the STA might enable protection of its HT- greenfield format and RIFS sequence transmissions. See also 11.9.8.5, which defines rules for the OBSS Non-HT STAs Present field related to HT-greenfield transmissions in certain operating classes. 10.26.3.5 Protection rules for an HT mesh STA A mesh STA determines the HT Protection and Nongreenfield HT STAs Present fields in the HT Operation element in the transmitting frame as follows: The HT Protection field in a mesh STA may be set to no protection mode only if â€” All STAs detected in the primary or the secondary channel are HT STAs, and â€” All mesh STA members of this MBSS that are one-hop neighbors of the transmitting mesh STA are either: â€” 20/40 MHz HT mesh STAs in a 20/40 MHz MBSS, or â€” 20 MHz HT mesh STAs in a 20 MHz MBSS. The HT Protection field in a mesh STA may be set to nonmember protection mode only if â€” A non-HT STA is detected in either the primary or the secondary channel or in both the primary and secondary channels, that is not known by the transmitting mesh STA to be a member of this MBSS, and â€” All mesh STA members of this MBSS that are one-hop neighbors of the transmitting mesh STA are HT mesh STAs. The HT Protection field in a mesh STA may be set to 20 MHz protection mode only if â€” All STAs detected in the primary and all STAs detected in the secondary channel are HT STAs, and â€” All mesh STA members of this MBSS that are one-hop neighbors of the transmitting mesh STA are HT mesh STAs, and â€” The MBSS is a 20/40 MHz MBSS, and â€” There is at least one 20 MHz HT mesh STA that is one-hop neighbor of the transmitting mesh STA. The HT Protection field in a mesh STA is set to non-HT mixed mode otherwise. If two peer HT mesh STAs report the same protection mode in HT Protection field, the protection mechanisms of the related mode shall be used to protect the transmission between the peer HT mesh STAs. If an HT mesh STA and its peer HT mesh STA report different protection modes in HT Protection field, the following rules shall be used: a) If an HT mesh STA or its peer HT mesh STA reports non-HT mixed mode, the protection mechanisms of non-HT mixed mode shall be used to protect the transmission between the peer HT mesh STAs. b) If an HT mesh STA or its peer HT mesh STA reports nonmember protection mode and non-HT mixed mode is not reported by any of these HT mesh STAs, the protection mechanisms of nonmember protection mode shall be used to protect the transmission between the peer HT mesh STAs. c) If an HT mesh STA or its peer HT mesh STA reports 20 MHz protection mode and neither non-HT mixed mode nor nonmember protection mode is reported by any of these HT mesh STAs, the protection mechanisms of 20 MHz protection mode shall be used to protect the transmission between the peer HT mesh STA. 1444 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If at least one HT peer mesh STA in its mesh neighborhood indicates the Nongreenfield HT STAs Present equal to 1, the protection rules related to Nongreenfield HT STAs Present should also be applied to the communication between HT peer mesh STAs. 10.26.4 L_LENGTH and L_DATARATE parameter values for HT-mixed format PPDUs L_LENGTH and L_DATARATE determine the duration that non-HT STAs do not transmit, equal to the remaining duration of the HT PPDU or the L-SIG duration when L-SIG TXOP protection is used as defined in 10.26.5, following the non-HT portion of the preamble of the HT-mixed format PPDU. The L_DATARATE parameter of the TXVECTOR shall be set to the value 6 Mb/s. A STA that is transmitting a PPDU with the FORMAT parameter of the TXVECTOR equal to HT_MF and that is not operating by the L-SIG TXOP protection rules described in 10.26.5 shall set the value of the L_LENGTH parameter to the value (in octets) given by Equation (10-13): L_LENGTH = TXTIME â€“ Signal Extension â€“ aPreambleLength + aPHYHeaderLength ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- aSymbolLength N OPS â€“ aPHYServiceLength + aPHYConvolutionalTailLength ----------------------------------------------------------------------------------------------------------------------------------- 8 (10-13) where TXTIME is the duration (in microseconds) of the HT PPDU defined in 6.5.5 Signal Extension is 0 Âµs when TXVECTOR parameter NO_SIG_EXTN is true and is aSignalEx- tension as defined in Table 19-25 of 19.4.4 when TXVECTOR parameter NO_SIG_EXTN is false aSymbolLength is the duration of a symbol (in microseconds), defined in 6.5.4 (aPreambleLength + aPHYHeaderLength) is the duration (in microseconds) of the non-HT PHY pream- ble and L-SIG, defined in 6.5.4 N OPS is the number of octets transmitted during a period of aSymbolLength at the rate specified by L_DATARATE aPHYServiceLength is the number of bits in the PHY SERVICE field, defined in 6.5.4 (PLME-CHAR- ACTERISTICS.confirm) aPHYConvolutionalTailLength is the number of bits in the convolutional code tail bit sequence, defined in 6.5.4 NOTE 1â€”The last term of the L_LENGTH definition corrects for the fact that non-HT STAs add the length of the SERVICE field and tail bits (assuming a single convolutional encoder) to the value communicated by the L_LENGTH field. TXTIME â€“ Signal Extension â€“ 20 NOTE 2â€”For a Clause 19 PHY, this equation simplifies to L_LENGTH = ------------------------------------------------------------------------------------------ 3â€“3. - 4 A STA that is operating under L-SIG TXOP protection shall set the L_LENGTH parameter according to rules described in 10.26.5. A STA shall not transmit a PPDU with the FORMAT parameter set to HT_MF in TXVECTOR if the corresponding L_LENGTH value calculated with Equation (10-13) exceeds 4095 octets. NOTEâ€”The transmission of frames with L_LENGTH above 2332 octets (i.e., a Data frame containing an unencrypted 2304 octet MSDU) might be accompanied by a protection mechanism (e.g., RTS/CTS or CTS-to-self protection) if it is determined that the use of L_LENGTH fails to effectively suppress non-HT transmissions. How this is determined is outside the scope of this standard. 1445 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.26.5 L-SIG TXOP protection 10.26.5.1 General rules The L-SIG TXOP protection mechanism is obsolete. Consequently, this subclause might be removed in a later revision of this standard. Figure 10-39 illustrates protection by the SIG Length and Rate fields. The terms used in this figure are defined below and in 19.3.2. aPreambleLength + aPHYHeaderLength L-SIG Duration = (L_LENGTH / L_DATARATE) + Signal Extension SIG L-STF L-LTF L-SIG HT-SIG HT-STF HT-LTF(s) DATA EXT - L_DATARATE - MCS - L_LENGTH - LENGTH SIG Signal Extension Ack EXT Figure 10-39â€”Basic concept of L-SIG TXOP protection The AP determines whether all HT STAs associated with its BSS support L-SIG TXOP protection and indicates this determination in the L-SIG TXOP Protection Full Support field of its HT Operation element. This field shall not be set to 1 unless the L-SIG TXOP Protection field is equal to 1 for all HT STAs in the BSS. Support for L-SIG TXOP protection at an intended recipient can be determined through examination of its HT Capability element. In an IBSS and an MBSS the L-SIG TXOP Protection Full Support field of the HT Operation element is reserved, but an HT STA shall operate as though the field were equal to 0. A VHT AP shall set the HT Operation element HT Operation Information field L-SIG TXOP Protection Full Support subfield to 0. A VHT STA shall set the HT Capabilities element HT Capability Information field L-SIG TXOP Protection Support subfield to 0 during (re)association. A STA shall not transmit a frame using L-SIG TXOP protection directed to a recipient that does not support L- SIG TXOP protection. A STA that transmits an L-SIG TXOP Protected frame should use an MCS from the Basic HT-MCS Set field of the HT Operation parameter of the MLME-START.request primitive or Basic HT-MCS Set field of the HT Operation parameter of the SelectedBSS parameter of the MLME-JOIN.request primitive for the transmission of that frame if â€” The frame initiates a TXOP in an IBSS or in an MBSS, or â€” The L-SIG TXOP Protection Full Support field is equal to 0 by its AP. Under L-SIG TXOP protection operation, the L-SIG field with an HT-mixed format PHY preamble represents a duration value equivalent (except in the case of the initial frame that establishes the TXOP, as described below) to the sum of: a) The value of Duration/ID field contained in the MAC header and b) The duration remaining in the current packet after the L-SIG, which is equal to the duration of the current packet less (aPreambleLength + aPHYHeaderLength) 1446 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A duration value determined from the L_DATARATE and L_LENGTH parameters of the TXVECTOR or RXVECTOR rounded up to a multiple of aSymbolLength that is not equal to the remaining duration of the frame is called an L-SIG duration. The TXVECTOR L_LENGTH (defined in 19.2.2), when L-SIG TXOP protection is used, shall contain the value (in octets) given by Equation (10-14). L_LENGTH = L-SIG Duration â€“ Signal Extension N OPS ------------------------------------------------------------------------------------- aSymbolLength (10-14) â€“ aPHYServiceLength + aPHYConvolutionalTailLength ----------------------------------------------------------------------------------------------------------------------------------- 8 where Signal Extension is defined in 10.26.4 aSymbolLength is the duration of symbol, defined in 6.5.4 N OPS is the number of octets transmitted during a period of aSymbolLength at the rate specified by L_DATARATE aPHYServiceLength is the number of bits in the PHY SERVICE field, defined in 6.5.4 aPHYConvolutionalTailLength is the number of bits in the convolutional code tail bit sequence, defined in 6.5.4 durations are expressed in microseconds L-SIG Duration â€“ Signal Extension NOTEâ€”For a Clause 19 PHY, this equation simplifies to L_LENGTH = ----------------------------------------------------------------------------------------- 3â€“3. 4 Non-HT STAs are not able to receive any PPDUs that start during the L-SIG duration. Therefore, no frame shall be transmitted to a non-HT STA during an L-SIG protected TXOP. See also 10.3.2.4, which describes a rule for resetting a NAV value that was set by an L-SIG TXOP protected frame. 10.26.5.2 L-SIG TXOP protection rules at the TXOP holder Figure 10-40 illustrates an example of how L-SIG durations are set when using L-SIG TXOP protection. MAC Duration MAC Duration F F IG F F IG T T RTS T T S - -L -S S - -L -S DATA CF-End L L L L L L L-SIG Duration L-SIG Duration MAC Duration F F G F F G T T I T T I S - L - -S CTS S - L - -S BA L L L L L L L-SIG Duration Figure 10-40â€”Example of L-SIG duration setting An L-SIG TXOP protected sequence shall start with one of the following: â€” an initial handshake, which is the exchange of two frames (each inside an HT-mixed format PPDU) that establish protection (e.g., RTS/CTS) or â€” an initial frame that establishes protection but generates no response (e.g., a CTS to self) 1447 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications provided that this initial sequence is also valid for the start of a TXOP. The term L-SIG TXOP protected sequence includes these initial frames and any subsequent frames transmitted within the protected duration. Under L-SIG TXOP protection operation, when the initial PPDU that establishes protection requires a response, the L-SIG duration of the initial PPDU shall be as follows: L-SIG Duration = T Init_PPDU â€“ aPreambleLength + aPHYHeaderLength + SIFS + T Res_PPDU where T Init_PPDU is the length in time (in microseconds) of the entire initial PPDU T Res_PPDU is the length in time (in microseconds) of the expected response PPDU aPreambleLength + aPHYHeaderLength is the length in time (in microseconds) of the non-HT PHY header, defined in 6.5.4 When the initial PPDU that establishes protection requires no response, the L-SIG duration shall contain the following value: L-SIG Duration = T Init_MACDur + T Init_PPDU â€“ aPreambleLength + aPHYHeaderLength where T Init_MACDur is the Duration/ID field value carried in the MAC header of the initial PPDU An HT STA using L-SIG TXOP protection should use an accurate prediction of the TXOP duration inside the Duration/ID field of the MAC header to avoid inefficient use of the channel capability. The L-SIG duration of the initial frame shall allow for the longest possible duration of the response frame (i.e., taking into account wrapped +HTC in the case of control response frames). If the actual duration of the response frame is less than this allowed duration, the TXOP holder shall delay transmission of the third PPDU in the L-SIG TXOP protected sequence until a SIFS after this L-SIG duration expires. NOTEâ€”A result of this step is that a non-HT STA sees a SIFS between the end of the first PPDU and the start of the third PPDU. If the initial frame handshake succeeds (i.e., upon reception of a response frame with L-SIG TXOP protection addressed to the TXOP holder), all HT-mixed format PPDUs transmitted inside an L-SIG TXOP protection protected TXOP shall contain an L-SIG duration that extends to the endpoint indicated by the MAC Duration/ ID field. The first PPDU transmitted after a successful initial handshake (i.e., upon reception of a response frame with L-SIG TXOP protection addressed to the TXOP holder) shall have the TXVECTOR FORMAT parameter set to HT_MF. NOTEâ€”The requirement to use HT_MF for the third PPDU arises as follows. A third-party STA receives the first PPDU, but does not receive any MPDU correctly from it. It sets its NAV based on the L-SIG duration. The STA does not receive the second PPDU. It is necessary for the STA to be able to determine either an L-SIG duration or MAC duration value from the third PPDU in order to protect the remaining time in the TXOP. The ability of the STA to make this determination is enabled by sending the third PPDU using HT-mixed format, containing an L-SIG duration as shown in Figure 10-40. The TXOP holder should transmit a CF-End frame starting a SIFS after the L-SIG TXOP protected period. This step enables STAs to terminate the EIFS procedure to avoid potential unfairness or a capture effect. NOTEâ€”This case is not an instance of TXOP truncation, because it is not transmitted to reset the NAV. 1448 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.26.5.3 L-SIG TXOP protection rules at the TXOP responder On receiving a PPDU containing an L-SIG duration addressed to itself, a TXOP responder that set the L-SIG TXOP Protection Support field to 1 on association shall generate an L-SIG TXOP protection response frame with the L-SIG duration equivalent to the following: L-SIG Duration = T MACDur â€“ SIFS â€“ aPreambleLength + aPHYHeaderLength where T MACDur is the Duration/ID field value carried in the MAC header of frame(s) received in the PPDU that generated the response A STA shall not transmit a response frame containing an L-SIG duration unless it is in response to a frame that also contained an L-SIG duration. 10.26.5.4 L-SIG TXOP protection NAV update rule An HT STA that set the L-SIG TXOP Protection Support field to 1 on association that receives a PHY-RXSTART.indication primitive with RXVECTOR parameter FORMAT equal to HT_MF and LSIGVALID equal to true and that receives no valid MPDU from which a Duration/ID field value can be determined shall, when the PHY-RXEND.indication primitive is received, update its NAV to a value equal to the following: L-SIG duration â€“ TXTIME â€“ aPreambleLength + aPHYHeaderLength where TXTIME is the time required to send the entire PPDU 10.26.6 Protection rules for VHT STAs A VHT STA is subject to all of the rules for HT STAs that apply to its operating band, except that a PPDU with the TXECTOR FORMAT parameter set to VHT may be substituted for a PPDU with the TXVECTOR FORMAT parameter set to HT_MF. 10.27 MAC frame processing 10.27.1 Introduction Subclauses 10.27.2 to 10.27.9 describe MAC frame and element processing requirements to provide frame, Action frame, element, and subelement extensibility. 10.27.2 Revision level field processing A MAC entity that receives a frame with a higher revision level than it supports shall discard the frame without indication to the sending STA or to LLC. 10.27.3 Duration/ID field processing When the contents of a received Duration/ID field, treated as an unsigned integer and without regard for address values, type, and subtype (even when type or subtype contain reserved values), are less than 32 768, 1449 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications the duration value is used to update the network allocation vector (NAV) according to the procedures defined in 10.3.2.4, 10.22.3.4, or 10.36.10, as appropriate. When the contents of a received Duration/ID field, treated as an unsigned integer, are greater than 32 768, the contents are interpreted as appropriate for the frame type and subtype or ignored if the receiving MAC entity does not have a defined interpretation for that type and subtype. 10.27.4 Response to an invalid Action frame If a STA receives an individually addressed Action frame with an unrecognized Category field or some other syntactic error and the MSB of the Category field equal to 0, then the STA shall return the Action frame to the source without change except that the MSB of the Category field is set to 1. 10.27.5 Operation of the Dialog Token field A dialog token is an integer value that assists a STA in grouping Management frames sent or received at different times as part of the same dialog. The algorithm by which the integer value for the dialog is selected is implementation specific, but should be selected in a manner that minimizes the probability of a frame associated with one dialog being incorrectly associated with another dialog. 10.27.6 Element parsing A STA that encounters an element with an unknown or reserved element ID value, or an element with an element ID extension whose element ID extension value is unknown or reserved, in a Management frame received without error, shall ignore that element and shall parse any remaining management frame body for additional elements with recognizable element ID (and, if present, element ID extension) values. The MME of a Vendor-Specific Protected Action frame is located at the end of the frame body. NOTEâ€”It is not necessary to be able to parse the vendor-specific content to locate the MME. 10.27.7 Vendor specific element parsing A STA receiving a vendor-specific element that it does not support shall ignore the vendor-specific element. 10.27.8 Extensible element parsing Table 9-77 indicates which elements are considered extensible in future revisions of the standard, by placing a Yes in the Extensible column. A STA that receives an extensible element in which the Length field plus two exceeds the value indicated in Table 9-77 shall discard any part of the element beyond the maximum length indicated in this table and shall otherwise process the element as though this truncated element had been received. 10.27.9 Extensible subelement parsing A subelement has the structure defined in 9.4.3 and is contained within an element or subelement. A STA that encounters an unknown, unsupported, or reserved subelement ID value contained in an element or subelement shall ignore the subelement with that subelement ID value and shall continue to parse any remaining element or subelement body for additional subelements with recognizable subelement ID values. A STA that receives an element or subelement for which a vendor-specific subelement is defined and that contains a vendor-specific subelement that it does not support shall ignore this vendor-specific subelement and 1450 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications shall continue to parse any remaining element or subelement body for additional subelements with recognizable subelement ID values. Subelements are defined locally in each subclause that defines a structure containing subelements. Subelement ID numbering is private to that structure. A STA that receives an extensible subelement that is not extensible using subelements and in which the Length field exceeds the length of the structure of the subelement defined in this standard shall discard any part of the subelement beyond that length and shall otherwise process the subelement as though this truncated subelement had been received. 10.27.10 Extensible TLV parsing A TVHT STA that receives a frame containing a TLV tuple with an unknown Type value shall discard the tuple and continue processing the next tuple. 10.28 Reverse direction protocol 10.28.1 General The RD protocol may be supported by an HT STA and by a DMG STA. A STA receiving an RDG is never required to use the grant. The RD protocol defined in this subclause applies to both types of STAs. An HT STA indicates support of the RD feature as an RD responder using the RD Responder subfield of the HT Extended Capabilities field of the HT Capabilities element. A STA shall set the RD Responder subfield to 1 in frames that it transmits containing the HT Capabilities element if dot11RDResponderOptionImplemented is true. Otherwise, the STA shall set the RD Responder subfield to 0. In an HT STA, the RDG/More PPDU subfield and the AC Constraint subfield are present in the HTC field. A DMG STA indicates support of the RD feature using the Reverse Direction subfield of the DMG STA Capability Information field of the DMG Capabilities element. A STA shall set the Reverse Direction subfield to 1 in frames that it transmits containing the DMG Capabilities element if dot11RDResponderOptionImplemented is true. Otherwise, the STA shall set the Reverse Direction subfield to 0. In a DMG STA, the RDG/More PPDU subfield and the AC Constraint subfield are present in the QoS Control field. 10.28.2 Reverse direction (RD) exchange sequence An RD exchange sequence comprises the following: a) The transmission of a PPDU by a TXOP holder or SP source containing an RD grant (the RDG PPDU), which is indicated by the PPDU containing one or more +HTC or DMG MPDUs in which the RDG/More PPDU subfield is equal to 1. The STA that transmits this PPDU is known as the RD initiator. The rules for an RD initiator apply only during a single RD exchange sequence, i.e., after the transmission of an RDG PPDU and up to the end of the last PPDU in the RD exchange sequence. b) The transmission of one or more PPDUs (the RD response burst) by the STA addressed in the MPDUs of the RDG PPDU. The first (or only) PPDU of the RD response burst contains at most one immediate BlockAck or Ack frame. The last (or only) PPDU of the RD response burst contains any MPDUs requiring a response that is an immediate BlockAck or Ack frame. The STA that transmits the RD response burst is known as the RD responder. The rules for an RD responder apply only during a single RD exchange sequence, i.e., following the reception of an RDG PPDU and up to the transmission of a PPDU by the RD responder in which the RDG/More PPDU subfield is equal to 0. c) The transmission of a PPDU by the RD initiator containing an immediate BlockAck frame or Ack frame (the RD initiator final PPDU), if so required by the last PPDU of the RD response burst. 1451 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NOTE 1â€”An RD initiator might include multiple RD exchange sequences within a single TXOP or SP. Each RD exchange sequence within a single TXOP or SP might be addressed to a different recipient, and any single recipient might be given more than one RDG within a single TXOP or SP. NOTE 2â€”If the RD responder is a VHT AP, the RD response burst can contain VHT MU PPDUs that might have TXVECTOR parameter NUM_USERS > 1. An example of an RD exchange sequence is given in O.3. 10.28.3 Rules for RD initiator An RDG shall not be present unless the MPDU carrying the grant, or every MPDU carrying the grant in an A-MPDU, matches one of the following conditions: â€” A QoS Data frame with the Ack Policy field equal to any value except PSMP Ack (i.e., including Implicit Block Ack Request), or â€” A BlockAckReq frame related to an HT-immediate block ack agreement, or â€” An MPDU not needing an immediate response (e.g., block ack under an HT-immediate block ack agreement, or Action No Ack). An RDG shall not be present within a PSMP sequence. NOTE 1â€”These rules together with the rules in 9.7.3 cause an RDG to be delivered in a PPDU that either requires no immediate response or requires an immediate response that is a BlockAck or Ack frame. NOTE 2â€”An RD initiator is not required to examine the RD Responder field of a potential responder before deciding whether to send a PPDU to that STA in which the RDG/More PPDU subfield is set to 1. NOTE 3â€”An RD initiator is required according to 10.9 to examine the +HTC-HT Support field of a potential responder before deciding whether to send a PPDU to that STA in which the RDG/More PPDU subfield is set to 1. Transmission of a +HTC or DMG frame by an RD initiator with the RDG/More PPDU subfield equal to 1 (either transmitted as a non-A-MPDU frame, as a VHT single MPDU, or within an A-MPDU) indicates that the duration indicated by the Duration/ID field is available for the RD response burst and RD initiator final PPDU (if present). An RD initiator that sets the RDG/More PPDU field to 1 in a +HTC or DMG frame transmitted during a TXOP shall set the AC Constraint subfield to 1 in that frame if the TXOP was gained through the EDCA channel access mechanism and shall otherwise set it to 0. An RD initiator that sets the RDG/More PPDU field to 1 in a DMG frame transmitted during an SP can set the AC Constraint subfield to 1 to limit the Data frames transmitted by the RD responder. An RD initiator shall not transmit a +HTC or DMG frame with the RDG/More PPDU subfield set to 1 that requires a response MPDU that is not one of the following frames: â€” Ack â€” Compressed BlockAck Subject to TXOP or SP constraints, after transmitting an RDG PPDU, an RD initiator may transmit its next PPDU as follows: a) Normal continuation: The RD initiator may transmit its next PPDU a minimum of a SIFS after receiving a response PPDU that meets one of the following conditions: 1) Contains one or more received +HTC or DMG frames with the RDG/More PPDU subfield equal to 0 2) In an HT STA, contains one or more received frames that are capable of carrying the HT Control field but did not contain an HT Control field 3) Contains a received frame that requires an immediate response 1452 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 4) In a DMG STA, none of the correctly received frames in the PPDU carry the QoS Control field b) Error recovery: The RD initiator may transmit its next PPDU when the CS mechanism (see 10.3.2.1) indicates that the medium is idle at the TxPIFS slot boundary (see Figure 10-26) (this transmission is a continuation of the current TXOP or SP). NOTE 1â€”Error recovery of the RDG mechanism is the responsibility of the RD initiator. NOTE 2â€”After transmitting a PPDU containing an RDG, if the response is corrupted so that the state of the RDG/More PPDU subfield is unknown, the RD initiator of the RD exchange is not allowed to transmit after a SIFS. Transmission can occur a PIFS after deassertion of CS. A STA that transmits a QoS +CF-Ack Data frame according to the rules in 10.22.3.5 may also include an RDG in that frame provided that â€” It is a non-A-MPDU frame or VHT single MPDU, and â€” The target of the +CF-Ack is equal to the Address 1 field of the frame. NOTE 1â€”In a non-DMG BSS, the RD initiator can transmit a CF-End frame according to the rules for TXOP truncation in 10.22.2.9 following an RD transmit sequence. An RD responder never transmits a CF-End. NOTE 2â€”In a DMG network, the RD initiator can transmit a CF-End frame according to the rules for TXOP truncation in 10.22.2.9 or SP truncation in 10.36.8, as appropriate, following an RD transmit sequence. An RD responder never transmits a CF-End. 10.28.4 Rules for RD responder An RD responder shall transmit the initial PPDU of the RD response burst a SIFS after the reception of the RDG PPDU. PPDUs in a response burst are separated by SIFS or RIFS. The RIFS rules in the RD are the same as in the forward direction; the use of RIFS is constrained as defined in 10.3.2.3.2 and 10.26.3.3. NOTEâ€”The transmission of a response by the RD responder does not constitute a new channel access but a continuation of the RD initiatorâ€™s TXOP or SP. An RD responder ignores the NAV when responding to an RDG. The recipient of an RDG may decline the RDG by â€” Not transmitting any frames following the RDG PPDU when no response is otherwise required, or â€” Transmitting a control response frame with the RDG/More PPDU subfield set to 0, or â€” Transmitting a control response frame that contains no HT Control field An RD responder that is a non-DMG STA may transmit a +CF-Ack non-A-MPDU frame or +CF-Ack VHT single MPDU in response to a QoS Data +HTC non-A-MPDU frame or VHT single MPDU that has the Ack Policy field equal to Normal Ack and the RDG/More PPDU subfield equal to 1. The RD responder shall ensure that its PPDU transmission(s) and any expected responses fit entirely within the remaining TXOP or SP duration, as indicated in the Duration/ID field of MPDUs within the RDG PPDU. An RD responder shall not transmit an MPDU (either individually or aggregated within an A-MPDU) that is not one of the following frames: â€” Ack â€” Compressed BlockAck â€” Compressed BlockAckReq â€” Extended Compressed BlockAck â€” Extended Compressed BlockAckReq â€” QoS data â€” Management 1453 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If the AC Constraint subfield is equal to 1, the RD responder shall transmit Data frames of only the same AC as the last frame received from the RD initiator. For a BlockAckReq or BlockAck frame, the AC is determined by examining the TID field. For a Management frame, the AC is AC_VO. The RD initiator shall not transmit a +HTC or DMG MPDU with the RDG/More PPDU subfield set to 1 from which the AC cannot be determined. If the AC Constraint subfield is equal to 0, the RD responder may transmit Data frames of any TID. During an RD response burst any PPDU transmitted by an RD responder shall contain at least one MPDU with an Address 1 field that matches the MAC address of the RD initiator, and the inclusion of traffic to STAs other than the RD initiator in a VHT MU PPDU shall not increase the duration of the VHT MU PPDU beyond that required to transport the traffic to the RD initiator. The RD responder shall not transmit any frame causing a response after SIFS with an Address 1 field that does not match the MAC address of the RD initiator. The RD responder shall not transmit any PPDUs with a CH_BANDWIDTH that is wider than the CH_BANDWIDTH of the PPDU containing the frame(s) that delivered the RD grant. If an RDG PPDU also requires an immediate block ack response, the BlockAck frame shall be included in the first PPDU of the response. When a PPDU is not the final PPDU of a response burst, an HT Control field carrying the RDG/More PPDU subfield set to 1 shall be present in every MPDU within the PPDU capable of carrying the HT Control field, or if the PPDU is transmitted in a DMG BSS, the RDG/More PPDU subfield within the QoS Control field shall be set to 1 in every MPDU within the PPDU. The last PPDU of a response burst shall have the RDG/More PPDU subfield set to 0 in all +HTC or DMG MPDUs contained in that PPDU. The RD responder shall not set the RDG/More PPDU subfield to 1 in any MPDU in a PPDU that contains an MPDU that requires an immediate response. NOTEâ€”If the RD responder transmits a PPDU that expects a transmission by the RD initiator after SIFS and no such transmission is detected, the RD responder has to wait for either another RDG or its own TXOP or SP before it can retry the exchange. After transmitting a PPDU containing one or more +HTC or DMG MPDUs in which the RDG/More PPDU subfield is equal to 0, the RD responder shall not transmit any more PPDUs within the current response burst. NOTEâ€”If an RD-capable STA that is not the TXOP holder or SP source receives a PPDU that does not indicate an RDG, there is no difference in its response compared to a STA that is not RD-capable. 10.29 PSMP operation 10.29.1 General A DMG STA shall not use PSMP. 10.29.2 Frame transmission mechanism during PSMP 10.29.2.1 PSMP frame transmission (PSMP-DTT and PSMP-UTT) The attribute aDTT2UTTTime is the minimum time between the end of the PSMP-DTT and the start of a PSMP-UTT addressed to the same STA. This value represents the minimum time the STA is provided to react to Multi-TID BlockAck, BlockAck, Multi-TID BlockAckReq, BlockAckReq, and Data frames received during the PSMP-DTT with data, BlockAck, BlockAckReq, Multi-TID BlockAckReq, and Multi-TID BlockAck frames transmitted in the PSMP-UTT. In a PSMP sequence, if the traffic conditions are such that the time between the PSMP-DTT and PSMP-UTT of a STA would otherwise be less than the value of aDTT2UTTTime, the AP shall delay the start of entire PSMP-UTT phase to meet this requirement. 1454 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A PSMP sequence may be used to transmit non-GCR-SP group addressed frames along with individually addressed frames. Individually addressed frames shall be scheduled after group addressed frames. In a PSMP frame the STA_ID subfields of all its STA Info fields with STA_INFO Type equal to 2 (individually addressed) shall be unique, i.e., each STA identified in the PSMP frame is identified exactly once. Individually addressed entries in the PSMP frame should have their PSMP-DTT and PSMP-UTT start offsets scheduled to minimize the number of on/off transitions or to maximize the delay between their PSMP-DTT and PSMP-UTT periods. Entries that have only PSMP-DTT should be scheduled closer to the start of the PSMP- DTTs. Entries that have only PSMP-UTT should be scheduled toward the end of PSMP-UTTs. Entries that have both PSMP-DTT and PSMP-UTT should be scheduled closer to the transition point from downlink to uplink transmissions. NOTEâ€”For effective resource allocation the AP needs to precisely estimate the PSMP-UTT duration for each STA using the information indicated in a TSPEC, such as Minimum Data Rate, Mean Data Rate, Peak Data Rate, Burst Size, and Delay Bound fields. However, when the traffic characteristic is quite bursty (e.g., a real-time video application), precise estimation of PSMP-UTT duration is difficult without timely and frequent feedback of the current traffic statistics. In order to avoid wasting the available bandwidth by overestimating the PSMP-UTT duration, the AP can allocate the minimum amount of time to each STA using the PSMP-UTT Duration subfield in the PSMP frame, based on the value of the Minimum Data Rate field specified in the TSPEC. When the STA receives the PSMP frame, it decides whether the allocated resource indicated by the PSMP-UTT duration is sufficient for its queued data. If the allocated resource is sufficient, the STA can transmit all of the queued data at the allocated time. Frames of different TIDs may be transmitted within a PSMP-DTT or PSMP-UTT allocation of a PSMP sequence without regard to user priority. Within a PSMP-DTT or PSMP-UTT between HT STAs, BlockAckReq and BlockAck frames for which an HT-immediate block ack agreement exists shall be the multi-TID variants, i.e., Multi-TID BlockAckReq and Multi-TID BlockAck, respectively. Within a PSMP-DTT or PSMP-UTT between STAs where one is not an HT STA, BlockAckReq and BlockAck frames shall be exchanged through the use of an immediate block ack agreement and shall be the basic variants, i.e., Basic BlockAckReq and Basic BlockAck, respectively. 10.29.2.2 PSMP downlink transmission (PSMP-DTT) During a PSMP sequence, a STA shall be able to receive frames during its scheduled PSMP-DTT and is not required to be able to receive frames at other times. The AP shall verify that any transmissions within a PSMP sequence to a STA participating in the PSMP sequence occur wholly within the STAâ€™s PSMP-DTT. The PSMP-DTT may contain one or more PPDUs, each of which may contain either an A-MPDU or a single MPDU. Data may be transmitted using either format, provided that the format is supported by both the transmitter and the receiver. PPDUs within a PSMP-DTT may be separated using RIFS or SIFS. The use of RIFS is limited as defined in 10.3.2.3.2 and 10.26.3.3. Each PSMP-DTT shall contain only frames addressed to the RA signaled by the corresponding STA_INFO field. PPDUs from adjacent PSMP-DTTs shall be separated by at least SIFS. In other words, PPDUs to a different RA are separated by at least SIFS. 10.29.2.3 PSMP uplink transmission (PSMP-UTT) A STA that has frames to send that are valid for transmission within the PSMP-UTT shall start transmission without performing CCA and regardless of NAV at the start of its PSMP-UTT. 1455 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The STA shall complete its transmission within the allocated PSMP-UTT, even if it has more data queued than can be transmitted during its allocated PSMP-UTT. NOTEâ€”PSMP-UTT is a scheduled transmission period for the STA, and transmission within a PSMP-UTT does not imply that the STA is a TXOP holder. This lack of being a TXOP holder disallows a STA from using TXOP truncation during PSMP-UTT. The uplink schedule in a PSMP frame shall include an interval between the end of one PSMP-UTT and the start of the following PSMP-UTT within the same PSMP sequence. This interval shall be either aIUStime or SIFS. The aIUStime value shall not be used unless the use of RIFS is permitted, as defined in 10.26.3.3. The PSMP-UTT Duration subfield in the PSMP frame does not include this interval. PPDUs transmitted within a PSMP-UTT may be separated using RIFS or SIFS. The use of RIFS is limited as defined in 10.3.2.3.2 and 10.26.3.3. An AP may transmit a PSMP frame (called a PSMP recovery frame) during a PSMP-UTT when both of the following conditions are met: â€” The CS mechanism (see 10.3.2.1) indicates that the medium is idle at the TxPIFS slot boundary (see Figure 10-26) after the start of the PSMP-UTT, and â€” The PSMP-UTT duration is longer than the total time of the PSMP recovery frame plus PIFS. The PSMP recovery frame shall not modify the schedule of a STA that is not scheduled to use this PSMP-UTT. The schedules of other STAs shall remain unchanged. The PSMP recovery frame may include: a) A modified PSMP-UTT (and/or PSMP-DTT) for the currently scheduled STA by adjusting the time remaining by a PIFS plus the duration of the PSMP recovery frame, and b) PSMP-UTTs for other STAs that were originally scheduled after this PSMP-UTT in the PSMP sequence in which the PSMP-UTT start offset values are reduced by the time difference between the end of the original PSMP frame and the end of the PSMP recovery frame. If the currently scheduled PSMP-UTT duration is shorter than the total time of PSMP recovery frame plus PIFS, no PSMP recovery frame is transmitted. Figure 10-41 illustrates a PSMP sequence with and without PSMP recovery. 10.29.2.4 PSMP burst After transmission of an initial PSMP sequence, additional PSMP sequences may be transmitted by the AP in order to support resource allocation and error recovery. An initial PSMP sequence followed by one or more PSMP sequences is termed a PSMP burst and is shown in Figure 10-42. A STA shall not transmit a +HTC MPDU in which the RDG/More PPDU subfield is set to 1 during a PSMP burst. An AP may transmit a CF-End frame a SIFS after the end of a PSMP sequence to end the PSMP burst. NOTEâ€”A non-AP STA does not transmit a CF-End frame during the PSMP burst because it is not a TXOP holder during its PSMP-UTT. 1456 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STA 2 and STA3 do not Downlink Phase receive the PSMP frame P P M PSMP- PSMP- PSMP- PSMP- S A P DTT1 DTT2 DTT3 DTT4 (STA1) (STA2) (STA3) (STA4) A PSMP- PSMP- T PSMP-UTT2 PSMP-UTT4 UTT1 UTT3 S (STA2) (STA4) (STA1) (STA3) Uplink Phase (a): PSMP sequence without PSMP recovery PSMP-recovery frame uses the standard PSMP frame. PSMP- recovery frame includes: modified PSMP-UTT transmission schedule of STA2 and unmodified from STA2 does not start schedules of STA3 and STA4. New PSMP-UTT start offsets are specified relative to the end of the Downlink Phase y PSMP-recovery frame (T'). - r P P e M PIFS M v P S PSMP- PSMP- PSMP- PSMP- S o P c A DTT1 DTT2 DTT3 DTT4 P e r (STA1) (STA2) (STA3) (STA4) A PSMP- PSMP- PSMP- T PSMP-UTT4 UTT1 UTT2 UTT3 S (STA4) (STA1) (STA2) (STA3) T' Uplink Phase (b): PSMP sequence with PSMP recovery Figure 10-41â€”Illustration of PSMP sequence with and without PSMP recovery SIFS SIFS Last PSMP sequence Downlink Phase Uplink Phase Block Ack Multi-TID MorePSMP=1 MorePSMP=1 MorePSMP=0 Multi-TID Block (TID1) (TID2) (TID2) Data Data Data A-MPDU Ack (RA2) PSMP PSMP PSMP (RA1) etc... A-MPDU A-MPDU AP (RA2) (RA1) aIUStime or SIFS RIFS or SIFS SIFS Data (TID1) Data (TID2) SIFS Block Ack Multi-TID Multi-TID Block (TA1) Ack (TA1) Multi-TID Block A-MPDU (TID1, TID2) A-MPDU Ack (TA2) STA1 (TA2) (TA1) STA1 STA2 UTT STA2 UTT Figure 10-42â€”PSMP burst 1457 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications During the PSMP-DTT or PSMP-UTT, a STA shall not transmit a frame unless it is one of the following: â€” Multi-TID BlockAck under HT-immediate policy â€” Multi-TID BlockAckReq under HT-immediate policy â€” BlockAck under an immediate policy with the BA Ack Policy subfield set to 1 (representing No Acknowledgment) â€” BlockAckReq under an immediate policy with the BAR Ack Policy subfield set to 1 (representing No Acknowledgment) â€” QoS data â€” PSMP (a PSMP recovery frame as described in 10.29.2.3) â€” BlockAckReq under HT-delayed policy with the BAR Ack Policy subfield set to 1 (representing No Acknowledgment) â€” BlockAck under HT-delayed policy with the BA Ack Policy subfield set to 1 (representing No Acknowledgment) â€” An MPDU that does not require an immediate response (e.g., Action No Ack) NOTEâ€”An AP can gain access to the channel after a PIFS in order to start transmission of a PSMP sequence. 10.29.2.5 Resource allocation within a PSMP burst If the allocated PSMP-UTT duration is not long enough for its queued data, the STA transmits only the part of the queued data that fits within the allocated PSMP-UTT duration and may transmit a resource request to the AP within that PSMP-UTT. The resource request is communicated by setting either the Queue Size field or the TXOP Duration Request field of the QoS Control field that is carried in a QoS Data frame (see Figure 10-43). If a STA receives an PSMP-UTT that is not long enough to transmit data from its queues, it may transmit within the PSMP-UTT a QoS Null frame containing information about the state of its transmit queues. NOTE 1â€”An HT AP might use this information to schedule a PSMP-UTT either in the current PSMP burst or a later PSMP burst. NOTE 2â€”An HT AP might allocate a PSMP-UTT duration in the next PSMP sequence based on the resource request from the STA sufficient to allow transmission of the remaining queued data. NOTE 3â€”The PSMP burst supports retransmission as well as additional resource allocation (see Figure 10-44). Frames transmitted under an HT-immediate block ack agreement during the PSMP-DTT are acknowledged by a Multi-TID BlockAck frame during the PSMP-UTT period of the current PSMP sequence. Frames transmitted under an immediate block ack agreement during the PSMP-DTT are acknowledged by a Basic BlockAck frame during the PSMP-UTT period of the current PSMP sequence. Frames transmitted under an HT-immediate block ack agreement during the PSMP UTT can be acknowledged using a Multi-TID BlockAck frame during the PSMP-DTT period of the next PSMP sequence. Frames transmitted under an immediate block ack agreement during the PSMP-UTT can be acknowledged using a Basic BlockAck frame during the PSMP-DTT period of the next PSMP sequence. Any failed transmissions during the PSMP-DTT or PSMP-UTT periods can be respectively retransmitted during the PSMP-DTT or PSMP-UTT period of the next PSMP sequence. Figure 10-43 and Figure 10-44 illustrate the operation of resource allocation. STA1 requests the AP to provide additional resources in its transmission to the AP. The box labeled â€œQueued dataâ€ represents the duration that would be required to transmit data queued for transmission at the STA. In Figure 10-44, since the AP does not receive an acknowledgment from STA2, the AP retransmits the data addressed to STA2 and also allocates resources to STA2 so that STA2 can transmit in the next PSMP sequence. 1458 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications P U 1 U 2 P D A D A M P T P T M S M S M S S P - o - o P AP A t A t Allocated duration is not enough U U D P Queued D P P A P A M - o t data M - o t STA1 A A Contains Allocated duration a resource is enough request U D P P A M - o t STA2 A Figure 10-43â€”PSMP burst showing resource allocation partially corrupted retransmission 1 2 k 2 k k P U D U D P ID c A U D ID c A P ID c A P M A A T A T T S P T S P T S M S ti-l k c P T S ti-l k c M S ti-l k c M S M - M - u M u u P A o t A o t P lo - A o t lo P lo P AP M B M B M B additional resource allocation kc U D P ID A Queued U D P T P A ti-l kc data P A M - o t u M o t A M lo - A STA1 B Contains a resource U D ck U D ck request D P IT A D P IT A P A -ti k P A -ti k l c l c -M to u o -M to u o STA2 A M lB A M lB partially corrupted retransmission Figure 10-44â€”PSMP burst showing retransmission and resource allocation 10.29.2.6 PSMP-UTT retransmission An AP transmits BlockAck frame or Multi-TID BlockAck frame responses, if any, to a STAâ€™s PSMP-UTT data transmissions under an immediate or HT-immediate block ack agreement, respectively, in the PSMP- DTT of a subsequent PSMP sequence. NOTEâ€”An AP might reserve a PSMP-UTT in a subsequent PSMP sequence to allow a STA to retransmit failed frames. The STA can retransmit failed frames in a PSMP sequence of the current PSMP burst if a PSMP-UTT reservation is present or in a subsequent SP. A STA that cannot complete its retransmissions in the last PSMP sequence of the PSMP burst because not enough time is allocated in its PSMP-UTT may transmit the data outside any PSMP sequence. NOTE 1â€”In the case of uplink frames transmitted outside the scheduled SP, the Multi-TID BlockAck frame that acknowledges these frames is delivered in the PSMP-DTT within the next SP. 1459 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NOTE 2â€”A non-AP STA might transmit data outside the PSMP sequence. The acknowledgment of such frames is based on their Ack Policy field value and whether a block ack agreement has been established, as follows: â€” An Ack Policy of Block Ack, Normal Ack, or Implicit Block Ack Request results in the behavior defined in 9.2.4.5.4. â€” An Ack Policy of PSMP Ack causes the AP to record the received Data frame and results in the transmission of a Multi-TID BlockAck frame in the next PSMP-DTT allocated to the STA. 10.29.2.7 PSMP acknowledgment rules A non-AP STA shall transmit a Multi-TID BlockAck frame during its PSMP-UTT for data received with the Ack Policy field set to PSMP Ack or for TIDs in a received Multi-TID BlockAckReq frame for which a BlockAck frame (Compressed BlockAck or Multi-TID BlockAck) has not yet been transmitted. An AP shall transmit a Multi-TID BlockAck frame during a PSMP-DTT addressed to the STA for the data received from that STA with the Ack Policy field set to PSMP Ack or for TIDs in a Multi-TID BlockAckReq frame received from that STA for which a BlockAck frame (Compressed BlockAck or Multi-TID BlockAck) has not yet been transmitted. Data sent and received by a non-AP STA within a PSMP sequence may be contained in an A-MPDU that contains MPDUs of multiple TIDs. Frames of differing TIDs may be transmitted in the same PSMP-DTT or PSMP-UTT and are not subject to AC prioritization. The subtype subfield of Data frames and the Ack Policy subfield of QoS Data frames transmitted during either PSMP-DTT or PSMP-UTT periods are limited by the following rules: â€” A QoS Data frame transmitted under an immediate or HT-immediate block ack agreement during either a PSMP-DTT or a PSMP-UTT shall have one of the following Ack Policy values: PSMP Ack or Block Ack. â€” A QoS Data frame transmitted under an HT-delayed block ack agreement during either a PSMP- DTT or a PSMP-UTT shall have the Ack Policy field set to Block Ack. â€” A Data frame with the RA field containing an individual address transmitted during either a PSMP- DTT or a PSMP-UTT and for which no block ack agreement exists shall be a QoS data subtype and shall have the Ack Policy field set to No Ack. â€” The Ack Policy field of a QoS Data frame transmitted during a PSMP sequence shall not be set to either Normal Ack or Implicit Block Ack. All TID values within a Multi-TID BlockAck frame or Multi-TID BlockAckReq frame shall identify a block ack agreement that is HT-immediate. QoS Data frames transmitted with Ack Policy field equal to PSMP Ack shall have a TID value that identifies a block ack agreement that is immediate or HT-immediate block ack. NOTEâ€”In this case, HT-immediate relates to the keeping of acknowledgment state for timely generation of a Multi- TID BlockAck frame. It does not imply that there is any response mechanism for sending a Multi-TID BlockAck frame after a SIFS. The timing of any response is determined by the PSMP schedule. Acknowledgment for data transmitted under an immediate or HT-immediate block ack agreement may be requested implicitly using PSMP Ack setting of the Ack Policy field in Data frames or explicitly with a Basic BlockAckReq or Multi-TID BlockAckReq frame. An AP that transmits Data frames with the Ack Policy field equal to PSMP Ack or that transmits a Basic BlockAckReq or Multi-TID BlockAckReq frame addressed to a STA in a PSMP-DTT shall allocate sufficient time for the transmission of a Basic BlockAck frame or Multi- TID BlockAck frame, respectively, in a PSMP-UTT allocated to that STA within the same PSMP sequence. A STA that has received a PSMP frame and that receives a QoS Data frame with the Ack Policy field equal to PSMP Ack or that receives a Basic BlockAckReq or Multi-TID BlockAckReq frame shall transmit a Basic BlockAck frame or Multi-TID BlockAck frame, respectively, in the PSMP-UTT of the same PSMP sequence. NOTE 1â€”If the STA does not receive the PSMP frame, it might still receive the downlink data, in which case it can record the status of the data in its block ack buffer, but it cannot transmit a Multi-TID BlockAck frame. 1460 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NOTE 2â€”A Multi-TID BlockAck frame or Multi-TID BlockAckReq frame might contain any TID related to an HT- immediate block ack agreement regardless of the contents of any prior transmission of Multi-TID BlockAck, Multi-TID BlockAckReq, or QoS Data frames. An AP that receives a QoS Data frame with the Ack Policy field equal to PSMP Ack during a PSMP-UTT shall transmit a response that is a Basic BlockAck frame or Multi-TID BlockAck frame in the next PSMP- DTT that it schedules for that STA, except if it has transmitted a BlockAck frame for such TIDs to the STA outside the PSMP mechanism. NOTE 1â€”The exception might occur if the non-AP STA transmits one or more BlockAckReq frames or QoS Data frames with Ack Policy set to Implicit Block Ack outside the PSMP mechanism. NOTE 2â€”An AP might receive a Multi-TID BlockAck frame in the PSMP-UTT of the current PSMP sequence. If the Multi-TID BlockAck frame indicates lost frames or if the AP does not receive an expected Multi-TID BlockAck frame, the AP might schedule and retransmit those frames in a PSMP sequence within the current PSMP burst or in the next SP. A Multi-TID BlockAck frame shall include all of the TIDs for which data were received with Ack Policy field equal to PSMP Ack and for the TIDs listed in any Multi-TID BlockAckReq frame received during the previous PSMP-DTT (STA) or PSMP-UTT (AP). The originator may ignore the bitmap for TIDs in the Multi-TID BlockAck frame for which the originator has not requested a Multi-TID BlockAck frame to be present either implicitly (by the transmission of Data frames with the Ack Policy field set to PSMP Ack) or explicitly (by the transmission of a Multi-TID BlockAckReq frame). If a BlockAckReq frame for an HT-delayed block ack agreement is transmitted during a PSMP sequence, the BAR Ack Policy subfield of the BlockAckReq frame shall be set to the value representing No Acknowledgment. 10.29.2.8 PSMP group addressed transmission rules 10.29.2.8.1 Rules at the AP This subclause defines rules that shall be followed by a PSMP-capable AP for the transmission of group addressed Data and Management frames during a PSMP sequence. Each separate group address for which frames are transmitted during a PSMP sequence shall have a single STA_INFO record with STA_INFO Type set to 1 (group addressed) present in the PSMP frame and transmit frames with the matching Address 1 field only during the PSMP-DTT indicated in this record. The DA of the PSMP shall be set to the broadcast address, except if the PSMP contains only a single non-null PSMP-DTT and this PSMP-DTT contains frames for a group address, in which case the DA of the PSMP frame may be set to this group address. NOTEâ€”The transmission of a group addressed frame within a PSMP sequence does not change the rules regarding when that frame can be transmitted. In other words, if there is a power-saving STA in the BSS, the group addressed frame is transmitted following a DTIM beacon according to the rules in 11.2.3. 10.29.2.8.2 Rules at the STA This subclause defines rules that shall be followed by a PSMP-capable STA for the reception of group addressed frames during a PSMP sequence. The STA shall be awake to receive during all PSMP-DTTs identified by a group addressed STA_INFO record where the PSMP Group Address ID subfield matches the LSBs of any address within its dot11GroupAddressesTable. 1461 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.29.3 Scheduled PSMP A PSMP session exists while any periodic TS exists that was established by a TSPEC with the APSD field equal to 0 and the Schedule field equal to 1 (representing Scheduled PSMP). The creation of a PSMP session is described in 11.4.6. While one or more PSMP sessions exist with the same SP, the AP shall periodically initiate a PSMP sequence by transmitting a PSMP frame using the SP indicated to the STA in response to the received TSPEC. Under S- PSMP rules, the AP shall not transmit a PSMP frame containing a STA_INFO record addressed to a STA unless the transmission occurs within a SP of that STA. The PSMP-DTT and PSMP-UTT allocated to a STA shall occur within a SP of that STA. NOTEâ€”An AP might simultaneously maintain multiple PSMP sessions with distinct SIs. The SIs of an APâ€™s PSMP sessions are multiples of the SI granularity. An AP might combine the schedule of multiple PSMP sessions into a single PSMP frame if the start times of the PSMP sessions coincide. For example, the schedule carried by a PSMP frame related to a PSMP session at 20 ms and 30 ms SIs can be combined into a single PSMP frame once every 3 SIs of PSMP session at 20 ms or once every 2 SIs of the PSMP session at 30 ms. The start time of a PSMP sequence should be aligned with the start time of the SP. 10.29.4 Unscheduled PSMP An HT AP may start an unscheduled PSMP sequence that includes STAs that are PSMP-capable at any time that these STAs are awake. NOTEâ€”A STA in power save is awake as defined in 11.2.3.5 (U-APSD, S-APSD), as defined in 11.2.3.8 (PS-Poll frame), or during a DTIM period. U-APSD STAs can signal the queue size or TXOP duration required to transmit its queued data to the AP in the QoS Control field of the trigger frame. This information might be used by the AP to estimate the duration of the PSMP-UTT so that the STA can transmit the queued data. All of the behavior defined in 11.2.3.5, 11.2.3.6, and 11.2.3.10 applies to unscheduled PSMP with the following exceptions: â€” PSMP allows the STA to sleep during PSMP-DTTs and PSMP-UTTs in which it has no interest. â€” In addition to the EOSP mechanism, the AP may indicate the end of a SP through the transmission of a PSMP frame with the More PSMP field set to 0 or by transmission of a CF-End frame when a PSMP frame was expected. 10.30 Sounding PPDUs The behavior described in this subclause is specific to the use of the HT variant HT Control field. A sounding PPDU is a PPDU for which the SOUNDING parameter of the corresponding RXVECTOR or TXVECTOR has the value SOUNDING. Sounding PPDUs are transmitted by STAs to enable the receiving STAs to estimate the channel between the transmitting STA and the receiving STA. A STA transmits sounding PPDUs when it operates in the following roles: â€” MFB requester (see 10.31.2) â€” HT beamformee responding to a training request, calibration initiator, or responder involved in implicit transmit beamforming (see 10.32.2.2, 10.32.2.3, and 10.32.2.4) â€” HT beamformer involved in explicit transmit beamforming (see 10.32.3) â€” ASEL transmitter and ASEL sounding-capable transmitter involved in ASEL (see 10.33.2) 1462 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A STA receives sounding PPDUs when it operates in the following roles: â€” MFB responder (see 10.31.2) â€” HT beamformer sending a training request, calibration initiator, or responder involved in implicit transmit beamforming (see 10.32.2.2, 10.32.2.3, and 10.32.2.4) â€” HT beamformee involved in explicit transmit beamforming (see 10.32.3) â€” Transmit ASEL responder and ASEL receiver involved in ASEL (see 10.33.2) When transmitting a sounding PPDU, the transmitting STA follows the rules stated below to determine the maximum number of space-time streams for which channel coefficients can be simultaneously estimated: â€” When transmitting a sounding PPDU that â€” Contains a +HTC frame with the MRQ subfield equal to 1, or â€” Is sent as a response to a +HTC frame with the TRQ field equal to 1, or â€” Is sent during a calibration sounding exchange, or â€” Is sent by an HT beamformer involved in explicit transmit beamforming, or â€” Is sent in transmit or receive ASEL exchanges, â€” Then: â€” If the sounding PPDU is not an NDP sounding PPDU, the NUM_EXTEN_SS parameter in the TXVECTOR shall not be set to a value greater than the limit indicated by the Channel Estimation Capability subfield in the Transmit Beamforming Capabilities field transmitted by the STA that is the intended receiver of the sounding PPDU. NOTEâ€”The maximum number of space-time streams for which channel coefficients can be simultaneously estimated using the HT-LTFs corresponding to the data portion of the packet is limited by the Rx MCS Bitmask subfield of the Supported MCS Set field and by the Rx STBC subfield of the HT Capability Information field. Both fields are part of the HT Capabilities element. â€” If the sounding PPDU is an NDP, the number of spatial streams corresponding to the MCS parameter of the TXVECTOR shall not exceed the limit indicated by the Channel Estimation Capability subfield in the Transmit Beamforming Capabilities field transmitted from the STA that is the intended receiver of the NDP (see 10.34.2 for details on setting the MCS parameter). If a STA sets the Receive Staggered Sounding Capable bit in the Transmit Beamforming Capabilities field to 1, the STA shall set the Channel Estimation Capability bit in the Transmit Beamforming Capabilities field to indicate a dimension that is greater than or equal to the dimension indicated by the Supported MCS Set field of the HT Capabilities element. 10.31 Link adaptation 10.31.1 Introduction To fully exploit MIMO channel variations and transmit beamforming on a MIMO link, a STA can request that another STA provide MIMO channel sounding and MFB. Link adaptation may be supported by immediate response or delayed response as described below. Unsolicited MFB is also possible. â€” Immediate: An immediate response occurs when the MFB responder transmits the response in the TXOP obtained by the TXOP holder. This approach allows the MFB requester to obtain the benefit of link adaptation within the same TXOP. â€” Delayed: A delayed response occurs when the MFB responder transmits the response in the role of a TXOP holder in response to an MRQ in a previous TXOP obtained by the MFB requester. 1463 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” Unsolicited: An unsolicited response occurs when a STA sends MFB independent of any preceding MRQ. 10.31.2 Link adaptation using the HT variant HT Control field The behavior described in this subclause is specific to the HT variant HT Control field. A STA that supports link adaptation using the HT Control field shall set the MCS Feedback field of the HT Extended Capabilities field to Unsolicited or Both, depending on its specific MFB capability, in HT Capabilities elements that it transmits. A STA shall not send an MRQ to a STA that has not set the MCS Feedback subfield to Both in the HT Extended Capabilities field of the HT Capabilities element. A STA whose MCS Feedback field of the HT Extended capabilities field of the HT Capabilities element is equal to Unsolicited or Both may transmit unsolicited MFB in any frame that contains a +HTC field. The MFB requester may set the MRQ subfield to 1 in the MAI subfield of the HT Control field of a +HTC frame to request a STA to provide MFB. In each MRQ, the MFB requester shall set the MSI subfield in the MAI subfield to a value in the range 0 to 6. How the MFB requester chooses the MSI value is implementation dependent. The appearance of more than one instance of an HT Control field with the MRQ subfield equal to 1 within a single PPDU shall be interpreted by the receiver as a single request for MFB. An MFB requester shall transmit +HTC frames with the MRQ subfield equal to 1 in one of the following ways: â€” Within a sounding PPDU, or â€” With the HT NDP Announcement subfield in the +HTC frame set to 1 and following the +HTC frame by an NDP transmission The number of HT-LTFs sent in the sounding PPDU or in the NDP is determined by the total number of spatial dimensions to be sounded, including any extra spatial dimensions beyond those used by the data portion of the frame. An MFB-capable STA (identified by the MCS Feedback field in the Extended HT Capability Information field equal to 3) shall support the following: â€” MFB estimate computation and feedback on the receipt of MRQ (MRQ=1 in +HTC) in a sounding PPDU for which the RXVECTOR NUM_EXTEN_SS parameter contains 0 in the PHY-RXSTART.indication primitive. â€” MFB estimate computation and feedback on the receipt of MRQ (MRQ=1 in +HTC) in a staggered sounding PPDU if this STA declares support for receive staggered sounding by setting the Receive Staggered Sounding Capable subfield of the Transmit Beamforming Capabilities field to 1. â€” MFB estimate computation and feedback on the receipt of NDP (see 10.34) if this STA declares support for receiving NDP sounding by setting the Receive NDP Capable subfield of the Transmit Beamforming Capabilities field to 1. The MFB requester shall set the MRQ subfield to 1 in the frame where the HT NDP Announcement subfield is equal to 1. On receipt of a +HTC frame with the MRQ subfield equal to 1, an MFB responder initiates computation of the MCS estimate based on the associated sounding PPDU and labels the result of this computation with the MSI value. The MFB responder includes the received MSI value in the MFSI field of the corresponding response frame. In the case of a delayed response, this use of MSI and MFSI fields allows the MFB requester to correlate the MFB with the related MRQ. 1464 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The responder may send a response frame with any of the following combinations of MFB and MFSI: â€” MFB = 127, MFSI = 7: no information is provided for the immediately preceding request or for any other pending request. This combination is used when the responder is required to include an HT Control field due to other protocols that use this field (i.e., the reverse direction protocol) and when no MFB is available. It has no effect on the status of any pending MRQ. â€” MFB = 127, MFSI in the range 0 to 6: the responder is not now providing, and will never provide, feedback for the request that had the MSI value that matches the MFSI value. â€” MFB in the range 0 to 126, MFSI in the range 0 to 6: the responder is providing feedback for the request that had the MSI value that matches the MFSI value. â€” MFB in the range 0 to 126, MFSI = 7: the responder is providing unsolicited feedback. Hardware and buffer capability may limit the number of MCS estimate computations that a MFB responder is capable of computing simultaneously. When a new MRQ is received either from a different MFB requester or from the same MFB requester with a different MSI value, and the MFB responder is not able to complete the computation for MRQ, the MFB responder may either discard the new request or may abandon an existing request and initiate an MCS estimate computation for the new MRQ. An MFB responder that discards or abandons the computation for an MRQ should indicate this action to the MFB requester by setting the MFB to the value 127 in the next transmission of a frame addressed to the MFB requester that includes the HT Control field. The value of the MFSI is set to the MSI value of the sounding frame for which the computation was abandoned. When computing the MCS estimate for an MFB requester whose Tx MCS Set Defined field is equal to 1, the number of spatial streams corresponding to the recommended MCS shall not exceed the limit indicated by the Tx Maximum Number Spatial Streams Supported field. The MFB responder shall not recommend an MCS corresponding to UEQM unless the MFB requester supports such modulation, as indicated by the Tx Unequal Modulation Supported bit in the Supported MCS Set field. If the MFB is in the same PPDU as a Noncompressed Beamforming frame or a Compressed Beamforming frame, the MFB responder should estimate the recommended MCS under the assumption that the MFB requester uses the steering matrices contained therein. After the MCS estimate computation is completed, the MFB responder should include the MFB in the MFB field in the next transmission of a frame addressed to the MFB requester that includes an HT Control field. When the MFB requester sets the MRQ subfield to 1 and sets the MSI subfield to a value that matches the MSI subfield value of a previous request for which the responder has not yet provided feedback, the responder shall discard or abandon the computation for the MRQ that corresponds to the previous use of that MSI subfield value. A STA may respond immediately to a current request for MFB with a frame containing an MFSI field value and MFB field value that correspond to a request that precedes the current request. Bidirectional request/responses are supported. A STA may act as both the MFB requester for one direction of a duplex link and the MFB responder for the other direction and include both MRQ and MFB in the same HT Data frame. If an HT beamformer transmits a PPDU with the TXVECTOR EXPANSION_MAT_TYPE set to either COMPRESSED_SV or NON_COMPRESSED_SV, it should use the recommended MCS associated with those matrices reported in a Noncompressed Beamforming frame or a Compressed Beamforming frame. 1465 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.31.3 Link adaptation using the VHT variant HT Control field This subclause applies to frame exchange sequences that include PPDUs containing an HT variant HT Control field. A STA that supports VHT link adaptation using the VHT variant HT Control field shall set the VHT Link Adaptation Capable subfield in the VHT Capabilities Information field in the VHT Capabilities element to Unsolicited or Both, depending on its specific link adaptation feedback capability. A STA shall not send an MRQ to a STA that has not set the VHT Link Adaptation Capable subfield to Both in the VHT Capabilities Information field of the VHT Capabilities element. A STA whose VHT Link Adaptation Capable subfield of the VHT Capabilities Information field of the VHT Capabilities element is either set to Unsolicited or Both may transmit unsolicited MFB in any frame that contains a VHT variant HT Control field. The MFB requester may set the MRQ field to 1 in the VHT variant HT Control field of a frame to request a STA to provide link adaptation feedback. In each request the MFB requester shall set the MSI/STBC field to a value in the ranges 0 to 6, 0 to 2, or 0 to 3, depending on the settings in the Unsolicited MFB and STBC fields (see 9.2.4.6.3). The choice of MSI value is implementation dependent. The appearance of more than one instance of a VHT variant HT Control field with the MRQ field equal to 1 within a single PPDU shall be interpreted by the receiver as a single request for link adaptation feedback. An MFB responder that has set the VHT Link Adaptation Capable subfield to Both in the VHT Capabilities Information field of the VHT Capabilities element shall support both of the following: â€” Computation and feedback of the MFB estimate on the receipt of an MFB request (MRQ equal to 1 in the VHT variant HT Control field) in a PPDU that is not a VHT NDP Announcement frame â€” Computation and feedback of the MFB estimate on the receipt of an MFB request (MRQ equal to 1 in VHT variant HT Control field) in a VHT NDP Announcement frame and the receipt of VHT NDPs (see 10.34) if this STA set the SU Beamformee Capable subfield of the VHT Capabilities Information field of the VHT Capabilities element to 1 On receipt of a VHT variant HT Control field with the MRQ field equal to 1, an MFB responder computes the VHT-MCS, NUM_STS, and SNR estimates based on the PPDU carrying the MRQ or, in the case of a VHT NDP Announcement frame carrying the MRQ, based on the subsequent VHT NDP. The MFB responder labels the result of this computation with the MSI value from the VHT variant HT Control field in the received frame carrying the MRQ. The MFB responder may include the received MSI value in the MFSI field of the corresponding response frame. In the case of a delayed response, this allows the MFB requester to associate the MFB with the soliciting MRQ. An MFB responder that sends a solicited MFB shall set the Unsolicited MFB subfield in VHT variant HT Control field to 0. The MFB responder may send a solicited response frame with any of the following combinations of VHT- MCS, NUM_STS, and MFSI: â€” VHT-MCS = 15, NUM_STS = 7 in the MFB subfield, MFSI = 7: no information is provided for the immediately preceding request or for any other pending request. This combination is used when the responder is required to include a VHT variant HT Control field due to other protocols that use this field (e.g., the Reverse Direction Protocol) and when no MFB is available. It has no effect on the status of any pending MRQ. â€” VHT-MCS = 15, NUM_STS = 7 in the MFB subfield, MFSI in the range 0 to 6: the responder is not now providing, and will never provide, feedback for the request that had the MSI value that matches the MFSI value. â€” VHT-MCS = valid value, NUM_STS = valid value in the MFB subfield, MFSI in the range 0 to 6: the responder is providing feedback for the request that had the MSI value that matches the MFSI value. 1466 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications An MFB responder that discards or abandons the MFB estimates computed in response to an MRQ may indicate that it has done so by setting the VHT-MCS to 15 and NUM_STS to 7 in the MFB subfield in the next frame addressed to the MFB requester that includes the VHT variant HT Control field. The value of the MFSI is set to the value of the MSI/STBC subfield of the frame that contains an MRQ for which the computation was abandoned, regardless of whether the MSI/STBC subfield contains an MSI or a Compressed MSI and STBC Indication subfields. The STA receiving MFB may use the received MFB to compute the appropriate VHT-MCS, SNR, and NUM_STS. A STA sending unsolicited MFB using the VHT variant HT Control field shall set the Unsolicited MFB subfield to 1. Unsolicited VHT-MCS, NUM_STS, BW, and SNR estimates reported in the MFB subfield of a VHT variant HT Control field sent by a STA are computed based on the most recent PPDU received by the STA that matches the description indicated by the GID-L, GID-H, Coding Type, STBC Indication, and FB Tx Type fields in the same VHT variant HT Control field. In an unsolicited MFB response the GID-L, GID-H, Coding Type, STBC Indication, FB Tx Type, and BW fields are set according to the RXVECTOR parameters of the received PPDU from which the VHT-MCS, SNR, BW, and NUM_STS are estimated, as follows: â€” If the VHT-MCS, SNR, BW, and NUM_STS are estimated from a VHT MU PPDU, then the GID-L field is set to the 3 least significant bits and the GID-H field to the 3 most significant bits of the parameter GROUP_ID. â€” If the VHT-MCS, SNR, BW, and NUM_STS are estimated from an SU PPDU, then the GID-L field and GID-H field are set to all 1s. â€” The Coding Type field is set to 0 if the parameter FEC_CODING is equal to BCC_CODING and set to 1 if equal to LDPC_CODING. â€” The STBC Indication field is set to 1 if the parameter STBC is equal to 1 and set to 0 if the STBC parameter is equal to 0. â€” The FB TX Type field is set to 1 if the parameter BEAMFORMED is equal to 1 and set to 0 if equal to 0. â€” The BW field shall indicate a bandwidth less than or equal to the bandwidth indicated by the parameter CH_BANDWIDTH. In an MFB response solicited by an MRQ that was not carried in a VHT NDP Announcement frame, the MFB is computed based on RXVECTOR parameters CH_BANDWIDTH, GROUP_ID, NUM_STS, FEC_CODING, BEAMFORMED, and STBC of the received PPDU that carried the MRQ and might additionally be based on other factors that are not part of the RXVECTOR. The NUM_STS subfield of the MFB subfield of VHT variant HT Control field shall be set to an equal or smaller value than the RXVECTOR parameter NUM_STS of the received PPDU that triggered the MRQ. If the MFB is in the same MPDU as a VHT Compressed Beamforming frame, the MFB responder shall estimate the recommended MFB under the assumption that the beamformer will use the steering matrices contained therein for performing an SU beamformed transmission. In this case the value of the NUM_STS field in the MFB subfield of the VHT variant HT Control field shall be the same as the value of the Nc Index field in the VHT MIMO Control field of the VHT Compressed Beamforming frame and, if the MFB is unsolicited, the Coding Type shall be set to BCC and the FB Tx Type shall be set to 0. Additionally, MFB estimate shall be based on the bandwidth indicated by the Channel Width subfield of the VHT MIMO Control field of the VHT Compressed Beamforming frame. In this case the SNR and BW subfields are reserved and set to 0. 1467 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If an unsolicited MFB is not in the same MPDU as a VHT Compressed Beamforming frame, the NUM_STS subfield of the MFB subfield of the VHT variant HT Control field shall be set to an equal or smaller value than the RXVECTOR parameter NUM_STS of the received PPDU from which the MFB parameters are estimated. If the MFB requester sends the MRQ in a VHT NDP Announcement frame, then the MFB responder shall include the corresponding MFB in (all of) the VHT Compressed Beamforming frame(s) sent in response to the same VHT NDP Announcement frame and NDP sequence. If the value of the NUM_STS subfield of the MFB field (solicited or unsolicited) is a smaller value than the RXVECTOR parameter NUM_STS of the received PPDU on which the MFB is based, the MFB responder shall estimate the recommended VHT-MCS under the assumption that the MFB requester will transmit the first NSTS space-time streams in the corresponding PPDU carrying MRQ. If the MFB is based on an SU PPDU the first NSTS space-time streams correspond to columns 1, ..., NSTS of the spatial mapping matrix Q. If the MFB is based on a VHT MU PPDU, then for the user u the first NSTS space-time streams correspond to columns Mu+1, ..., Mu+NSTS,u of the spatial mapping matrix Q (Mu is defined in 21.3.10.11.1). The VHT-MCS recommendation shall be a value from the peerâ€™s Tx Supported VHT-MCS and NSS Set (see 10.7.12.2). A VHT NDP Announcement frame that contains multiple STA Info fields and that contains a VHT format of HT Control field with the MRQ subfield equal to 1 solicits an MFB response from all of the STAs listed in the STA Info fields. When the MFB requester sets the MRQ subfield to 1 and sets the MSI/STBC subfield to a value that matches the MSI/STBC subfield value of a previous request for which the responder has not yet provided feedback, the responder shall discard or abandon the computation for the MRQ that corresponds to the previous use of that MSI/STBC subfield value and start a new computation based on the new request. A STA may respond immediately to a current request for MFB with a frame containing an MFSI field value and an MFB field value that correspond to a request that precedes the current request. Bidirectional request/responses are supported. A STA may act as both the MFB requester for one direction of a duplex link and the MFB responder for the other direction and include both an MRQ and an MFB in the same VHT variant HT Control field. 10.32 Transmit beamforming 10.32.1 HT steering matrix calculations In order for an HT beamformer to calculate an appropriate steering matrix for transmit spatial processing when transmitting to a specific HT beamformee, the HT beamformer needs to have an accurate estimate of the channel over which it is transmitting. Two methods of calculation are defined as follows: â€” Implicit feedback: When using implicit feedback, the beamformer receives long training symbols transmitted by the HT beamformee, which allow the MIMO channel between the HT beamformee and HT beamformer to be estimated. If the channel is reciprocal, the HT beamformer can use the training symbols that it receives from the HT beamformee to make a channel estimate suitable for computing the transmit steering matrix. Generally, calibrated radios in MIMO systems can improve reciprocity. See 10.32.2. â€” Explicit feedback: When using explicit feedback, the HT beamformee makes a direct estimate of the channel from training symbols sent to the HT beamformee by the HT beamformer. The HT beamformee may prepare CSI or steering feedback based on an observation of these training symbols. The HT beamformee quantizes the feedback and sends it to the HT beamformer. The HT beamformer can use the feedback as the basis for determining transmit steering vectors. See 10.32.3. 1468 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications An HT STA shall not transmit a PPDU with the TXVECTOR EXPANSION_MAT parameter present if dot11BeamFormingOptionActivated is false. 10.32.2 HT transmit beamforming with implicit feedback 10.32.2.1 General The procedures for HT transmit beamforming with implicit feedback use only HT and non-HT PPDUs, and the HT Control field, when present, is the HT variant HT Control field. Transmit beamforming with implicit feedback can operate in a unidirectional or bidirectional manner. In unidirectional implicit transmit beamforming, only the HT beamformer sends beamformed transmissions. In bidirectional implicit transmit beamforming, both STAs send beamformed transmissions, i.e., a STA may act as both HT beamformer and HT beamformee. Calibration of receive/transmit chains should be done to improve performance of transmit beamforming using implicit feedback. Over-the-air calibration is described in 10.32.2.4. For implicit transmit beamforming, only the HT beamformer, which is sending the beamformed transmissions, needs to be calibrated. A STA that advertises itself as being capable of being an HT beamformer and/or HT beamformee using implicit feedback shall support the requirements in Table 10-15. Table 10-15â€”STA type requirements for transmit beamforming with implicit feedback STA capability Required support Beamformer Shall set the Implicit Transmit Beamforming Capable subfield to 1 of the Transmit Beamforming Capability field of the HT Capabilities element in HT Capabilities elements that it transmits. Shall set the Implicit Transmit Beamforming Receiving Capable subfield to 1 of the Transmit Beamforming Capability field of the HT Capabilities element. Shall be capable of receiving a sounding PPDU for which the SOUNDING parameter is SOUNDING and the NUM_EXTEN_SS is equal to 0 in the RXVECTOR in the PHY-RXSTART.indication primitive, independently of the values of the Receive Staggered Sounding Capable and Receive NDP Capable subfields. Shall set the Calibration subfield to 3 of the Transmit Beamforming Capability field of the HT Capabilities element to advertise full calibration support. Beamformee Shall set the Implicit Transmit Beamforming Receiving Capable subfield to 1 of the Transmit Beamforming Capability field of the HT Capabilities element in HT Capabilities elements that it transmits. Shall be capable of setting the SOUNDING parameter to SOUNDING and the NUM_EXTEN_SS to 0 in the TXVECTOR in the PHY-TXSTART.request primitive when transmitting a sounding PPDU, as a response to TRQ=1, independently of the values of the Transmit Staggered Sounding Capable and Transmit NDP Capable subfields. A STA that performs one of the roles related to transmit beamforming with implicit feedback shall support the associated capabilities shown in Table 10-16. 1469 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 10-16â€”Transmit beamforming support required with implicit feedback Role Required support HT beamformee: Shall transmit sounding PPDUs as a response to TRQ=1. A receiver of transmit beamformed PPDUs Beamformer: Can receive sounding PPDUs. A transmitter of Can compute steering matrices from MIMO channel estimates obtained from long beamformed PPDUs training symbols in sounding PPDUs received from the HT beamformee. A responder in a Can receive and transmit sounding PPDUs. calibration exchange Can respond with a CSI frame that contains channel measurement information obtained during reception of a sounding PPDU. An initiator in a Can receive and transmit sounding PPDUs. calibration exchange Can receive a CSI frame sent by a calibration responder. When an HT beamformee transmits a sounding PPDU, the SOUNDING parameter in the TXVECTOR in the PHY-TXSTART.request primitive shall be set to SOUNDING. If the HT beamformee is capable of implicit transmit beamforming and the HT beamformer is capable of receiving implicit transmit beamforming, the sounding PPDU from the HT beamformee may be steered. A PPDU containing one or more +HTC MPDUs in which the TRQ field is equal to 1 shall not be sent to a STA that sets the Implicit Transmit Beamforming Receiving Capable subfield of the Transmit Beamforming field of the HT Capabilities element to 0. If a PPDU containing one or more +HTC MPDUs in which the TRQ field is equal to 1 requires an immediate response, either the response from the HT beamformee shall be included in a sounding PPDU, or the HT NDP Announcement subfield of the HT Control field shall be set to 1 and the PPDU shall be followed by an NDP. If the PPDU in which the TRQ field is equal to 1 does not require an immediate response, either the HT beamformee shall transmit a sounding PPDU in the next TXOP obtained by the HT beamformee, or the HT beamformee shall transmit a PPDU in the next TXOP obtained by the HT beamformee in which the HT NDP Announcement subfield of the HT Control field is set to 1 and that PPDU shall be followed by an NDP. The use of NDP as a sounding PPDU is described in 10.34. NOTEâ€”A STA that acts as an HT beamformer using implicit feedback expects to receive a sounding PPDU in response to a training request. The STA can compute steering matrices from the channel estimates obtained from the received sounding PPDU. At the end of the TXOP the final PPDU from the HT beamformer shall not have the TRQ field set to 1 in a frame that requests an immediate response if there is not enough time left in the TXOP for the HT beamformee to transmit the longest valid sounding PPDU with its response. 10.32.2.2 Unidirectional implicit transmit beamforming Figure 10-45 shows an example of a PPDU exchange used in unidirectional implicit transmit beamforming using the Clause 19 PHY. In this example, sounding PPDUs are used that carry MPDUs (i.e., an example of implicit beamforming using NDPs is not shown here.) STA A is the beamformer that initiates the PPDU exchange, and STA B is the beamformee. 1470 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STA A computes Tx Unsteered steering Steered HT-LTF HT-LTF Unsteered Steered HT Data STA A TRQ Data/TRQ ... Unsteered Unsteered HT-LTF Unsteered HT-LTF Unsteered Sounding PPDU Sounding PPDU STA B Figure 10-45â€”Example PPDU exchange for unidirectional implicit transmit beamforming The PPDU exchange can be summarized as follows: a) STA A initiates the frame exchange sequence by sending an unsteered PPDU to STA B. The PPDU includes a training request (TRQ= 1) in a +HTC MPDU. b) STA B sends a sounding PPDU in response to the training request from STA A. c) On receiving the sounding PPDU, STA A uses the resulting channel estimate to compute steering matrices and uses these matrices to send a steered PPDU back to STA B. d) The steered PPDU transmitted in step c) and subsequent steered PPDUs transmitted by STA A may include training requests (TRQ=1) in a +HTC MPDU. In response to each training request, STA B returns a sounding PPDU to STA A, which enables STA A to update its steering vectors. If the steering vectors resulting from step c) or subsequent sounding PPDUs are deemed stale due to delay, the sequence may be restarted by returning to step a). Step d) in the above PPDU exchange represents steady-state unidirectional transmit beamforming operation. During the PPDU exchange neither the receiving nor the transmitting STA should switch antennas. 10.32.2.3 Bidirectional implicit transmit beamforming Figure 10-46 shows an example of a PPDU exchange used in bidirectional implicit transmit beamforming, using the Clause 19 PHY. In this example, sounding PPDUs are used that carry MPDUs. STA A initiates the frame exchange, and STA A and STA B alternate in the roles of HT beamformer and HT beamformee. The PPDU exchange can be summarized as follows: a) STA A initiates the frame exchange sequence by sending an unsteered PPDU to STA B. The PPDU includes a training request (TRQ= 1) in a +HTC MPDU. b) STA B sends a sounding PPDU in response to the training request. In addition, this PPDU includes a training request in a +HTC MPDU to enable implicit transmit beamforming in the RD. c) On receiving the sounding PPDU, STA A uses the resulting channel estimate to compute steering matrices and uses these matrices to send a steered PPDU back to STA B. This steered PPDU is also a sounding PPDU in response to the training request from STA B. NOTEâ€”Steering matrices with nonorthonormal columns should not be used in transmitting sounding PPDUs for implicit feedback. In general, bidirectional implicit beamforming will not function as described here when the steering matrices have nonorthonormal columns. See 19.3.12.2. d) On receiving the sounding PPDU, STA B uses the resulting channel estimate to compute steering matrices and uses these matrices to send a steered PPDU back to STA A. The steered PPDU transmitted in step c) and subsequent steered PPDUs transmitted by STA A may include training requests in HTC. In response to each training request, STA B returns a sounding PPDU to STA A, 1471 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications which enables STA A to update its steering vectors. If the steering vectors resulting from step c) or subsequent sounding PPDUs are deemed stale due to delay, the sequence may be restarted by returning to step a). e) The steered PPDU transmitted in step d) and subsequent steered PPDUs transmitted by STA B may include training requests in HTC. In response to each training request, STA A returns a sounding PPDU to STA B, which enables STA B to update its steering vectors. If the steering vectors resulting from step d) or subsequent sounding PPDUs are deemed stale due to delay, the sequence may be restarted by returning to step a). Steps d) and e) in the above PPDU exchange represent steady-state bidirectional transmit beamforming operation. During the PPDU exchange neither the receiving nor the transmitting STA should switch antennas. NOTEâ€”The TRQ protocol used with the beamforming training process is not sufficient to permit STA B to transmit Data frames in the RD. In the example shown in Figure 10-46, STA A would additionally have to follow the rules of the reverse direction protocol (see 10.28). STA A computes Tx steering Steered Unsteered HT-LTF HT-LTF Steered HT Data Unsteered Sounding PPDU [TRQ]/Data â€¦â€¦â€¦â€¦â€¦â€¦â€¦... STA A TRQ Unsteered Steered HT-LTF Unsteered HT Data HT-LTF Steered HT Data Sounding PPDU Sounding PPDU STA B TRQ/Data [TRQ]/Data STA B computes Tx steering Figure 10-46â€”Example PPDU exchange for bidirectional implicit transmit beamforming 10.32.2.4 Calibration 10.32.2.4.1 Introduction Differences between transmit and receive chains in a STA degrade the inherent reciprocity of the over-the-air time division duplex channel and cause degradation of the performance of implicit beamforming. Calibration acts to remove or reduce differences between transmit and receive chains and enforce reciprocity in the observed baseband-to-baseband channels between two STAs. A STA acting as an HT beamformer should be calibrated to maximize performance. A STA acting only as an HT beamformee does not need to be calibrated. In order to perform calibration, the STA follows the procedure described below. 1472 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The calibration procedure involves the computation of correction matrices that cause the observed channel matrices in the two directions of the link to be transposes of each other and thus renders the resultant channel reciprocal. See 19.3.12.2 for a more detailed description. If it is able to do so, a STA should calibrate upon association. NOTEâ€”STAs with two or more transmit chains should be calibrated in order to engage in implicit transmit beamforming. STAs with any number of RF chains, including those with a single RF chain, can participate in a calibration exchange as a calibration responder. 10.32.2.4.2 Calibration capabilities A STA that sets the Implicit Transmit Beamforming Capable subfield of the Transmit Beamforming Capabilities field to 1 shall support calibration and shall set the Calibration subfield of the Transmit Beamforming Capabilities field to 3 (indicating full support of calibration) in HT Capabilities elements that it transmits. A STA that does not set the Implicit Transmit Beamforming Capable subfield of the Transmit Beamforming Capabilities field to 1 may support calibration and shall set the Calibration subfield of the Transmit Beamforming Capabilities field to the value that indicates its calibration capability in the Transmit Beamforming Capabilities field in HT Capabilities elements that it transmits (see Table 9-166), when the Transmit Beamforming Capabilities field exists. A STA that is capable of initiating calibration (the Calibration subfield of the Transmit Beamforming Capabilities field is equal to 3) shall set the CSI Max Number of Rows Beamformer Supported subfield to an appropriate value, even if the STA sets the Explicit Transmit Beamforming CSI Feedback subfield to the value 0. In order to support calibration, a STA that advertises that it is capable of responding to a calibration request shall be capable of transmitting a CSI frame in which the value of the Grouping subfield of the MIMO Control field is 0 (no grouping) and the Coefficients Size subfield of the MIMO Control field is 3 (Nb = 8 bits) in response to a CSI feedback request indicated by the CSI/Steering subfield of the HT Control field equal to 1 and the Calibration Position subfield of the HT Control field equal to 3, independently of the advertised values of the Explicit Transmit Beamforming CSI Feedback subfield in the Transmit Beamforming Capabilities field in the HT Capabilities element. A STA that advertises that it is capable of initiating a calibration request shall be capable of receiving a CSI frame in which the value of the Grouping subfield of the MIMO Control field is equal to 0 (no grouping) and the Coefficients Size subfield of the MIMO Control field is equal to 3 (Nb = 8 bits) as a response to CSI feedback request indicated by the CSI/Steering subfield of the HT Control field equal to 1 with the Calibration Position subfield equal to 3, independently of the advertised values of the Explicit CSI Transmit Beamforming Capable subfield in the Transmit Beamforming Capabilities field in the HT Capabilities element. A STA may initiate a calibration training frame exchange sequence with another STA if that STA supports calibration. A STA shall not initiate a calibration training frame exchange with another STA if that STA does not support calibration. If the Receive NDP Capable field is equal to 1, the value of the Calibration field is equal to 1 or 3, and the device supports transmitting sounding PPDUs for which two or more channel dimensions can be estimated (two or more columns of the MIMO channel matrix), then transmission of NDPs shall be supported (and the Transmit NDP Capable bit shall be set to 1). 10.32.2.4.3 Sounding exchange for calibration Figure 10-47 illustrates the calibration PPDU exchange using sounding PPDUs that contain an MPDU. 1473 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications PPDU Type: Sounding Frame Type : QoS Null Frame Type: QoS Null (Data) Ack Policy : Normal Ack Policy : Normal Ack + HTC : TRQ +HTC CSI Feedback Request Cal Position 1: Cal Position 3: STA A Cal Start Sound Complete Ack PPDU Type: Sounding Frame Type: Ack Frame Type: Management Action + HTC : TRQ +HTC Cal Position 2: STA B Cal Sound Ack CSI Step 1 Step 2 Figure 10-47â€”Calibration procedure with sounding PPDU containing an MPDU The calibration procedure begins with a calibration sounding PPDU exchange sequence shown as Step 1 in Figure 10-47. The Calibration Sequence subfield in the HT Control field shall be incremented each time a new calibration procedure is started. STA A (the calibration initiator) shall transmit a Calibration Start frame (Calibration Position subfield set to 1) with the TRQ field in the HT Control field set to 1. This frame initiates a calibration procedure. It shall be a QoS Null frame with the Ack Policy field set to Normal Ack. In response, STA B (the calibration responder) shall transmit a Calibration Sounding Response frame (Calibration Position subfield set to 2), a SIFS after the end of the Calibration Start frame, using a sounding PPDU. This step allows STA A to estimate the MIMO channel from STA B to STA A. In the Calibration Sounding Response frame, the Calibration Sequence subfield in HT Control field shall be set to the same value that is indicated in the Calibration Start frame. The Calibration Sounding Response frame shall have a frame type of Ack+HTC, and the TRQ field in the HT Control field in this frame shall be set to 1. In response, STA A shall transmit a Calibration Sounding Complete frame (Calibration Position subfield set to 3) that contains the CSI/Steering subfield of the HT Control field set to 1, a SIFS after the end of the Calibration Sounding Response frame, using a sounding PPDU. This step allows STA B to estimate the MIMO channel from STA A to STA B. In this Calibration Sounding Complete frame, the Calibration Sequence subfield in the HT Control field shall be set to the same value that is indicated in the Calibration Sounding Response frame. The Calibration Sounding Complete frame shall be a QoS Null+HTC with the Ack Policy field set to Normal Ack. A frame in which the Calibration Position subfield is equal to 2 or 3 shall be transmitted in a sounding PPDU (a PPDU for which the SOUNDING parameter is set to SOUNDING). The number of Long Training fields (LTFs) used to obtain MIMO channel estimation that are sent in the sounding PPDU shall be determined by the number of transmit chains (NTX) used in sending these LTFs at the STA transmitting the sounding PPDU. The transmit chains used at the calibration initiator are those for which calibration is required. The calibration responder may train up to maximum available transmit chains to maximize the quality of the resulting calibration, although the number of space-time streams for data symbols shall be determined by the rule described in 10.7. When transmitting a sounding PPDU during Step 1 of a calibration procedure, if the Receive Staggered Capability subfield in the Transmit Beamforming Capability field of the HT Capabilities element transmitted by the intended receiver is 0, then, 1474 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” If the sounding PPDU is not an NDP, the number of antennas used by the sender shall be less than or equal to the maximum number of space-time streams indicated by the Rx MCS Bitmask subfield of the Supported MCS Set field and the Rx STBC subfield of the HT Capabilities element transmitted by the intended receiver. â€” If the sounding PPDU is an NDP, the number of antennas used by the sender shall be less than or equal to the number indicated by the Channel Estimation Capability subfield in the Transmit Beamforming Capability field of the HT Capabilities element transmitted by the intended receiver. Sounding packets in which the Calibration Position subfield is equal to 2 or 3 shall use the spatial mapping matrices defined in 19.3.12.3. The calibration responder shall not remove the spatial mapping from the CSI to be fed back to the initiator of the frame exchange. NOTEâ€”The calibration initiator of this frame exchange is responsible for accounting for the spatial mapping in both its local channel estimate as well as in the quantized CSI fed back to it. The row order in the CSI feedback matrix transmitted from STA B shall correspond to the association of the rows of the spatial mapping matrix (see Equation (19-75)) to its transmit antennas. For example, the receive antenna at STA B associated with row i in the CSI feedback matrix in each subcarrier is the same as its transmit antenna associated with row i in the spatial mapping matrix used for transmitting the sounding response with Calibration Position equal to 2. Figure 10-48 and Figure 10-49 illustrate the calibration PPDU exchange using NDPs. Frame Type : QoS Data (or RTS or Management) Ack Policy : Normal Ack + HTC : HT NDP Announcement=1 Cal Position: 1 NDP STA A Cal Start 1 Frame Type: Ack (or CTS) Cal Position: 2 NDP STA B Cal Sound 2 Step 1 Step 2 is not shown here Figure 10-48â€”Calibration procedure with NDP The calibration procedure begins with a calibration sounding PPDU exchange sequence, shown as Step 1 in Figure 10-48 and Figure 10-49, when STA B supports transmitting sounding PPDUs for which only one channel dimension can be estimated (i.e., a single column of the MIMO channel matrix). The Calibration Sequence subfield in the HT Control field shall be incremented each time a new calibration procedure is started. NDP transmission within a calibration procedure follows the rules defined in 10.34.1. STA A transmits a Calibration Start frame (i.e., with the Calibration Position subfield set to 1) with the HT NDP Announcement subfield set to 1 and CSI/Steering subfield of the HT Control field set to 1. Only the current TXOP holder may set both the Calibration Position and HT NDP Announcement subfields to 1. This frame initiates a calibration procedure. 1475 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Frame Type : QoS Data (or RTS or Management) Ack Policy : Normal Ack + HTC : HT NDP Announcement=1 Cal Position: 1 NDP STA A Cal Start 1 PPDU Type: Sounding Frame Type: Ack (or CTS) Cal Position: 2 STA B Cal Sound Step 1 Step 2 is not shown here Figure 10-49â€”Calibration procedure with NDP when STA B supports transmitting sounding PPDUs for which only one channel dimension can be estimated (i.e., a single column of the MIMO channel matrix) STA B shall transmit a Calibration Sounding Response frame (i.e., with the Calibration Position subfield set to 2) after a SIFS after the received Calibration Start frame. If STA B supports transmitting sounding PPDUs for which only one channel dimension can be estimated (i.e., a single column of the MIMO channel matrix), this Calibration Sounding Response frame is sent with the SOUNDING parameter of the TXVECTOR set to SOUNDING (see Figure 10-49). As determined by NDP rules a) or b) in 10.34.1, STA A sends the first NDP as a sounding PPDU a SIFS after receiving the Calibration Sounding Response frame. This step allows STA B to estimate the MIMO channel from STA A to STA B. In the Calibration Sounding Response frame, the Calibration Sequence subfield in HT Control field shall be set to the same value that is contained in the Calibration Start frame. The Calibration Sounding Response frame shall contain an HT Control field, and the type and subtype of the frame are determined by the Calibration Start frame. As determined by NDP rule d), STA B might transmit a second NDP as a sounding PPDU a SIFS after receiving the first NDP. This second NDP allows STA A to estimate the channel from STA B to STA A. NOTEâ€”STA B does not transmit an NDP when it supports transmitting sounding PPDUs for which only one channel dimension can be estimated (see Figure 10-49). Otherwise (i.e., if STA B supports transmitting sounding PPDUs for which only one channel dimension can be estimated (single column of the MIMO channel matrix)), the transmission of the sounding PPDU in Calibration Position 2 allows STA A to estimate the channel from STA B to STA A. NDP sounding PPDUs shall use the spatial mapping matrices defined in 19.3.13.3. The calibration responder shall not remove the spatial mapping from the CSI to be fed back to the initiator of the frame exchange. NOTEâ€”The calibration initiator of this frame exchange is responsible for accounting for the spatial mapping in both its local channel estimate as well as in the quantized CSI fed back to it. 10.32.2.4.4 CSI reporting for calibration The remaining message exchange in the calibration procedure is not time critical. The calibration initiator should not transmit any frames that are part of the calibration sequence shown in Step 1 in Figure 10-47 if either of the response frames from the calibration responder (the frames shown as Calibration Position 2 and Ack in Step 1) is not received correctly within an AckTimeout interval (as defined in 10.3.2.9) after the PHY-TXEND.confirm primitive. If the calibration initiator aborts the calibration sequence, 1476 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications it may restart the calibration sequence with a value of the Calibration Sequence subfield in the Calibration Control subfield of the HT Control field that is different (i.e., incremented) from the value used in the aborted sequence. Within a non-NDP calibration sequence, the calibration responder should not transmit any further frames that are part of the calibration sequence shown in Step 1 if the frame having Calibration Position 3 is not received correctly within an AckTimeout interval (as defined in 10.3.2.9) after the PHY-TXEND.confirm primitive. When the MIMO channel measurements become available at STA B, STA B shall send one or more CSI frames that contain the CSI report (Step 2 in Figure 10-47). This CSI report shall have full precision, i.e, Ng=1 (no grouping) and Nb=3 (8 bits). In these CSI frames, the Calibration Sequence subfields in HT Control fields shall be set to the same value that is indicated in the Calibration Sounding Complete frame. These CSI frames shall have a frame type of Management Action +HTC. STA B should finish transmission of the first CSI frame within aMaxCSIMatricesReportDelay (in milliseconds) after the reception of the frame containing the CSI feedback request or HT NDP announcement. NOTEâ€”If necessary, the CSI Report field can be split into up to 8 segments as specified in Table 9-51. A STA that has started but not completed the calibration procedure and that receives some other request that requires the buffering of CSI (such as another calibration initiation frame, MFB request, CSI feedback request for link adaptation, or feedback request for explicit Transmit Beamforming) may ignore the other request. From the beginning of Step 1 of the calibration procedure and continuing through the end of Step 2 of the calibration procedure, neither the receiving nor the transmitting STA should switch antennas. 10.32.3 Explicit feedback beamforming The procedures in this subclause apply only to HT and non-HT PPDUs for which the HT Control field, if present, is the HT variant HT Control field. In this subclause, the terms HT beamformer and HT beamformee refer to STAs that are involved in explicit feedback beamforming. An HT beamformer uses the feedback response that it receives from the HT beamformee to calculate a beamforming feedback matrix for transmit beamforming. This feedback response may have one of three formats: â€” CSI: The HT beamformee sends the MIMO channel coefficients to the HT beamformer. â€” Noncompressed beamforming: The HT beamformee sends calculated beamforming feedback matrices to the HT beamformer. â€” Compressed beamforming: The HT beamformee sends compressed beamforming feedback matrices to the HT beamformer. The supported formats shall be advertised in the HT beamformeeâ€™s HT Capabilities element. NOTEâ€”An HT beamformer might discard the feedback response if the TSF time when the PHY-CCA.indication(IDLE) primitive corresponding to the feedback response frameâ€™s arrival minus the value from the Sounding Timestamp field in the feedback response frame is greater than the coherence time interval of the propagation channel. An HT beamformeeâ€™s responding capabilities shall be advertised in HT Capabilities elements that are transmitted by the HT beamformee. Devices that are capable of acting as an HT beamformee shall advertise one of the following response capabilities in the Explicit Transmit Beamforming CSI Feedback subfield of the Transmit Beamforming Capability field: 1477 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” Immediate: The HT beamformee is capable of sending a feedback response a SIFS after receiving a sounding PPDU and/or is capable of sending a feedback response aggregated in a PPDU that contains a MAC response within the HT beamformerâ€™s TXOP. â€” Delayed: The HT beamformee is not capable of sending the feedback response within the HT beamformerâ€™s TXOP, but it is capable of sending the feedback response in a TXOP that it obtains. â€” Immediate and Delayed: The HT beamformee is capable of sending a feedback response a SIFS after receiving a sounding PPDU, sending a feedback response aggregated in a PPDU that contains a MAC response within the HT beamformerâ€™s TXOP, or sending the feedback response in a TXOP that it obtains. The sounding frame types supported by the HT beamformee, staggered and/or NDP, are advertised in the HT Capabilities element in frames that are transmitted by the HT beamformee. A STA that sets any of the Explicit Transmit Beamforming CSI Feedback Capable, Explicit Noncompressed Beamforming Feedback Capable, or Explicit Compressed Beamforming Feedback Capable fields to 1 shall transmit explicit feedback based on the receipt of a +HTC sounding PPDU in which the CSI/Steering subfield has a nonzero value and that does not contain Extension HT-LTFs (HT-ELTFs). This requirement is independent of the values of the Receive Staggered Sounding Capable and the Receive NDP Capable fields. An HT beamformer shall set the SOUNDING parameter of the TXVECTOR to SOUNDING in the PHY- TXSTART.request primitive corresponding to each packet that is used for sounding. An HT beamformer shall set the response type format indicated in the CSI/Steering subfield of the HT Control field of any sounding frame excluding the NDP and of any PPDU with the NDP Sounding Announcement field equal to 1 to one of the nonzero values (CSI, Compressed Beamforming, or Noncompressed Beamforming) that corresponds to a type that is supported by the HT beamformee. The receipt of a PHY-RXSTART.indication primitive with the RXVECTOR SOUNDING parameter value equal to SOUNDING indicates a sounding packet. A non-NDP request for feedback is a sounding PPDU with a +HTC MPDU that contains a nonzero value of the CSI/Steering subfield and that has the HT NDP Announcement subfield equal to 0. An NDP request for feedback is the combination of a +HTC MPDU that contains a nonzero value of the CSI/ Steering subfield and that has the HT NDP Announcement subfield equal to 1 and the NDP that follows. An HT beamformee that transmits a feedback frame in response to a sounding PPDU sent by an HT beamformer shall transmit a frame of the type (CSI, Compressed Beamforming, or Noncompressed Beamforming) indicated in the CSI/Steering subfield of the HT Control field transmitted by the HT beamformer. The HT beamformee decides on any tone grouping to be used in the explicit Beamforming feedback. The value selected shall be a value supported by the HT beamformer as indicated in the Minimal Grouping subfield of the HT beamformerâ€™s HT Capabilities element. An HT beamformee that sets the Explicit Transmit Beamforming CSI Feedback field of its HT Capabilities element to either 2 or 3 shall transmit Explicit CSI feedback after SIFS or later in the HT beamformerâ€™s TXOP as a response to a non-NDP request for feedback in a frame that is appropriate for the current frame exchange sequence following Table 10-17. An HT beamformee that sets the Explicit Noncompressed Beamforming Feedback Capable field of its HT Capabilities element to either 2 or 3 shall transmit Explicit Noncompressed Beamforming feedback after SIFS or later in the HT beamformerâ€™s TXOP as a response to a non-NDP request for feedback in a frame that is appropriate for the current frame exchange sequence following Table 10-17. 1478 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 10-17â€”Rules for HT beamformee immediate feedback transmission responding to non-NDP sounding Type of response Rule CTS response If the transmission of a CTS is required in response to the non-NDP request for feedback, the transmission of the feedback response frame shall be delayed until the HT beamformeeâ€™s next transmission within the TXOP. This feedback response frame may be aggregated in an A-MPDU with an Ack or BlockAck frame. Acknowledgment If the transmission of an Ack or BlockAck frame is required in response to the non- response NDP request for feedback, both the feedback response frame and the control response frame may be aggregated in an A-MPDU. No control response If the transmission of a control response frame is not required in response to the non- NDP request for feedback, the feedback response frame shall be sent a SIFS after the reception of the sounding PPDU containing the request for feedback. Later aggregation of If the immediate-feedback-capable HT beamformee cannot transmit an aggregated or feedback and immediate CSI/Steering response in a SIFS after the end of the received sounding acknowledgment packet and the HT beamformee is subsequently required to transmit an Ack or BlockAck frame in the same TXOP, it may transmit the feedback response in an A-MPDU with the Ack or BlockAck frame. An HT beamformee that sets the Explicit Compressed Beamforming Feedback Capable field of its HT Capabilities element to either 2 or 3 shall transmit Explicit Compressed Beamforming feedback after SIFS or later in the HT beamformerâ€™s TXOP as a response to a non-NDP request for feedback in a frame that is appropriate for the current frame exchange sequence following Table 10-17. An HT beamformee that sets the Explicit Transmit Beamforming CSI Feedback field of its HT Capabilities element to either 2 or 3 shall transmit the Explicit CSI feedback after SIFS or later in the HT beamformerâ€™s TXOP as a response to an NDP request for feedback in a frame that is appropriate for the current frame exchange sequence following Table 10-18. Table 10-18â€”Rules for HT beamformee immediate feedback transmission responding to NDP sounding Type of response Rule Control response If the transmission of a control response frame is required in response to the NDP request for feedback, the control response frame is transmitted a SIFS after reception of the PPDU that elicited the control response, and the feedback response frame may be transmitted a SIFS after the reception of the NDP. â€” If the feedback response frame is not transmitted a SIFS after the reception of the NDP and the HT beamformee is subsequently required to transmit an Ack or BlockAck frame in the same TXOP, then the feedback response may be aggregated with the Ack or BlockAck frame. â€” If the feedback response frame is not transmitted a SIFS after the reception of the NDP and is not transmitted with an aggregated Ack or BlockAck frame in the same TXOP, then the feedback response frame is delayed until the HT beamformeeâ€™s next transmission within the TXOP. 1479 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 10-18â€”Rules for HT beamformee immediate feedback transmission responding to NDP sounding (continued) Type of response Rule No control If the transmission of a control response frame is not required in response to the NDP request response for feedback, the feedback response frame may be sent a SIFS after the reception of the NDP. â€” If the feedback response frame is not transmitted a SIFS after the reception of the NDP and the HT beamformee is subsequently required to transmit an Ack or BlockAck frame in the same TXOP, then the feedback response may be aggregated with the Ack or BlockAck frame. â€” If the feedback response frame is not transmitted a SIFS after the reception of the NDP and is not transmitted with an aggregated Ack or BlockAck frame in the same TXOP, then the feedback response frame is delayed until the HT beamformeeâ€™s next transmission within the TXOP. An HT beamformee that sets the Explicit Noncompressed Beamforming Feedback Capable field of its HT Capabilities element to either 2 or 3 shall transmit the Explicit Noncompressed Beamforming feedback after SIFS or later in the HT beamformerâ€™s TXOP as a response to an NDP request for feedback in a frame that is appropriate for the current frame exchange sequence following Table 10-18. An HT beamformee that sets the Explicit Compressed Beamforming Feedback Capable field of its HT Capabilities element to either 2 or 3 shall transmit the Explicit Compressed Beamforming feedback after SIFS or later in the HT beamformerâ€™s TXOP as a response to an NDP request for feedback in a frame that is appropriate for the current frame exchange sequence following Table 10-18. When the HT beamformee sets the Explicit Transmit Beamforming CSI Feedback field of its HT Capabilities element to either 2 or 3 and the HT beamformer has transmitted an NDP or an non-NDP Explicit Beamforming CSI feedback request in a frame that does not require immediate control response, the HT beamformer shall not transmit the next packet to the HT beamformee until PIFS after transmitting the sounding request. When the HT beamformee sets the Explicit Noncompressed Beamforming Feedback Capable field of its HT Capabilities element to either 2 or 3 and the HT beamformer has transmitted an NDP or an non-NDP Explicit Noncompressed Beamforming feedback request in a frame that does not require immediate control response, the HT beamformer shall not transmit the next packet to the HT beamformee until PIFS after the sounding request. When the HT beamformee sets the Explicit Compressed Beamforming Feedback Capable field of its HT Capabilities element to either 2 or 3 and the HT beamformer has transmitted an NDP or an non-NDP Explicit Compressed Beamforming feedback request in a frame that does not require immediate control response, the HT beamformer shall not transmit the next packet to the HT beamformee until PIFS after transmitting the sounding request. An HT beamformee shall not transmit a CSI, Compressed Beamforming, or Noncompressed Beamforming frame except in response to a request for feedback. NOTEâ€”Error recovery in a TXOP is not affected by sounding. An HT beamformer that is a TXOP holder and that fails to receive an expected response to a sounding PPDU can continue transmission as specified in 10.22.2.7. An HT beamformee transmitting a feedback response after SIFS or later in the HT beamformerâ€™s TXOP shall use an Action No Ack frame or an Action No Ack +HTC frame (defined in 9.3.3.15). An HT beamformee transmitting delayed feedback response shall use an Action frame or an Action +HTC frame to send this information within a separate TXOP. 1480 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If necessary, the CSI Report field, Noncompressed Beamforming Report field, or Compressed Beamforming Report field may be split into up to 8 frames. The length of each segment shall be equal number of octets for all segments except the last, which may be smaller. NOTEâ€”A STA that has been granted an RDG can act as an HT beamformer during the RDG time period, provided that the RD rules are obeyed. An HT beamformee that advertises itself as delayed-feedback-capable shall not transmit an immediate feedback response unless it also advertises itself as immediate-feedback-capable. An HT beamformer may use the following worst-case parameters to estimate the duration of the expected frame that contains the feedback response: lowest rate in basic HT-MCS set, HT-mixed format, no grouping. An Explicit Feedback Request may be combined with an MRQ. If the response contains a beamforming feedback matrix, the returned MCS shall be derived from the same information that was used to generate this particular beamforming feedback matrix. If the response contains channel coefficients, the returned MCS shall be derived from an analysis of the sounding frame that was used to generate the channel coefficients. The MFB field set to 127 (meaning no feedback) may be used when the HT beamformee is unable to generate the MCS in time for inclusion in the response transmission frame. A CSI-capable STA may be incapable of generating MFB. Explicit feedback shall be calculated only from a sounding PPDU. An HT beamformee that transmits a feedback frame of type Compressed Beamforming in response to a sounding PPDU sent by an HT beamformer shall set the value of Nr in the MIMO Control field of the feedback frame to be the same value as the number of streams in the sounding PPDU. 10.32.4 VHT MU beamforming An MU beamformer may transmit a VHT MU PPDU with a single nonzero TXVECTOR parameter NUM_STS[p], where 0 p 3 . An MU beamformer shall not transmit a VHT MU PPDU with a nonzero TXVECTOR parameter NUM_STS[p], where 0 p 3 , to a STA whose MU Beamformee Capable field is equal to 0. When transmitting a VHT MU PPDU, an MU beamformer shall order the per-user arrays of TXVECTOR parameters so that the per-user USER_POSITION array is in ascending order. 10.33 Antenna selection (ASEL) 10.33.1 Introduction The procedures in this subclause apply only to HT and non-HT PPDUs for which the HT Control field, if present, is the HT variant HT Control field. ASEL is a time-variant mapping of the signals at the RF chains onto a set of antenna elements when the number of RF chains is smaller than the number of antenna elements. The mapping might be chosen based on instantaneous or averaged CSI. ASEL requires the training of the full size channel associated with all antenna elements, which is obtained by transmitting or receiving sounding PPDUs over all antennas. These sounding PPDUs should be sent within a single TXOP. To avoid channel distortions, these sounding PPDUs shall be transmitted consecutively. The training information is exchanged using the HT Control field. When both transmitter and receiver have ASEL capabilities, training of transmit and receive antennas might be done one after another. ASEL supports up to eight antennas and up to four RF chains. 1481 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.33.2 Procedure A STA shall not initiate an ASEL training frame exchange sequence with another STA unless that STA supports ASEL, as determined by the ASEL Capability field (see 9.4.2.56.7). A STA that is capable of supporting ASEL should set each subfield of the ASEL Capability field of the HT Capabilities element to 1 depending on its capabilities in HT Capabilities elements that it transmits (see 9.4.2.56.7). A STA that sets the Explicit CSI Feedback Based Tx ASEL Capable subfield of the ASEL Capability field (see 9.4.2.56.7) to 1 shall set the CSI Max Number of Rows Beamformer Supported subfield of the Transmit Beamforming Capabilities field to an appropriate value, even if the STA sets the Explicit Transmit Beamforming CSI Feedback subfield to the value 0. The frame exchange sequence for transmit ASEL is shown in Figure 10-50, where the term ASEL transmitter identifies the STA that is conducting transmit ASEL, and the term transmit ASEL responder identifies the STA that provides ASEL feedback. The frame exchange comprises the following steps: a) (Optional) A transmit ASEL responder may initiate the transmit ASEL training by sending a +HTC frame with the ASEL Command subfield set to Transmit Antenna Selection Sounding Request (TXASSR). b) The ASEL transmitter sends out consecutive sounding PPDUs separated by SIFS in a TXOP of which it is the TXOP holder with no acknowledgment over different antenna sets, each PPDU containing a +HTC frame with the ASEL Command subfield set to Transmit Antenna Selection Sounding Indication (TXASSI or TXASSI-CSI). Each sounding PPDU is transmitted over one antenna set. If the ASEL transmitter allows antenna indices feedback (by setting the ASEL Command subfield to TXASSI), the antenna sets from which the sounding PPDUs are transmitted shall be disjoint. If the ASEL transmitter uses NDP sounding PPDUs for the ASEL sounding, the spatial mapping matrix Qk shall be set equal to the identity matrix starting with the first NDP. If the ASEL transmitter uses non-NDP sounding PPDUs for the ASEL sounding, the spatial mapping matrix Qk shall be an FFT matrix. An FFT matrix of size N is defined as a square matrix of dimension NxN with entries wim , 1 im i=0,..Nâ€“1, m=0,..Nâ€“1 where w im = -------- exp â€“ j2 ------ . N N The ASEL transmitter shall not include TXASSI-CSI in the command field of the sounding frame if the last received value of the Explicit CSI Feedback Capable subfield of the ASEL Capability field (see 9.4.2.56.7) from the receiver was 0. NOTEâ€”For example, in the case of sounding over all disjointed antenna sets, the number of consecutive sounding PPDUs equals the smallest integer that is greater than or equal to the number of antennas divided by the number of RF chains. These sounding PPDUs need to be sent within a single TXOP in order to minimize the change in the channel during this procedure. c) The transmit ASEL responder estimates the subchannel corresponding to each sounding PPDU. d) If the ASEL Command subfield in the sounding frames is equal to TXASSI-CSI, after receiving all of the sounding PPDUs, the transmit ASEL responder shall respond with the full size CSI in a subsequent TXOP. If the ASEL Command subfield in the sounding frames is equal to TXASSI, after receiving all of the sounding PPDUs, the transmit ASEL responder may either respond with the full size CSI in a subsequent TXOP, or conduct ASEL computation and provide the selected antenna indices in a subsequent TXOP. 1) CSI is transported using the MIMO CSI Matrices frame defined in 9.6.12.6 contained within either an Action No Ack or Action frame. Multiple CSI frames may be required to provide the complete feedback, in which case the value of the Sounding Timestamp field within each of 1482 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications these CSI frames shall correspond to the arrival time of the sounding frame that was used to generate the feedback information contained in the frame. 2) Antenna indices feedback is carried in the Antenna Selection Indices Feedback frame, defined in 9.6.12.9. One octet of the Antenna Selection Indices field is used to carry the selected antenna indices feedback. + HTC frame Consecutive Sounding PPDUs Transmitter ASEL with NDP Announce = 1 TXASSI NDP NDP or SIFS SIFS â€¦ TXASSI TXASSI Responder Transmit SIFS ASEL Segmented Segmented sounding PPDU sounding PPDU TXASSR ASEL Feedback (optional) Transmit Antenna Selection sounding request Figure 10-50â€”Transmit ASEL If the transmit ASEL responder does not correctly receive all of the sounding PPDUs but has correctly received at least one of the preceding sounding PPDUs, it shall send a +HTC frame with the MAI subfield set to the value ASELI (see Table 9-12), the ASEL Command subfield set to No Feedback Due to ASEL Training Failure or Stale Feedback to indicate the failure of the ASEL training process, and the ASEL Data subfield set to either of the following: â€” The integer value corresponding to the number in sequence of the first sounding PPDU that was not properly received, where 0 corresponds to the first sounding PPDU in the ASEL training sequence or â€” The value 0 A transmit ASEL responder that determines that the ASEL feedback is stale shall notify the ASEL transmitter by transmitting a +HTC MPDU with the MAI subfield set to ASELI, the ASEL Command subfield set to No Feedback Due to ASEL Training Failure or Stale Feedback, and the ASEL Data subfield set to 0. If, in response to the transmission of a sequence of sounding PPDUs, the ASEL transmitter receives a +HTC MPDU with the MAI subfield equal to ASELI, the ASEL Command subfield equal to No Feedback Due to ASEL Training Failure or Stale Feedback, and the ASEL Data subfield equal to a nonzero value to indicate a failed ASEL training frame sequence, the ASEL transmitter may perform any of the following actions: â€” Do nothing. â€” Restart the failed ASEL training frame sequence from the point of failure by transmitting a +HTC MPDU with the MAI subfield set to ASELI, the ASEL Command subfield set to TXASSR, and the ASEL Data subfield set to a nonzero value to correspond to the command Transmit Antenna Selection Sounding Resumption (a Resumption MPDU), where the ASEL Data subfield value is the order number (from the original training frame sequence) of the first sounding PPDU transmitted in the restarted ASEL training frame sequence and where 0 corresponds to the first sounding PPDU in the original ASEL training sequence. â€” Execute a new ASEL training frame sequence by transmitting a +HTC MPDU with the MAI subfield set to ASELI, the ASEL Command subfield set to TXASSI or TXASSI-CSI, and the ASEL Data subfield set to a nonzero value. 1483 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If a transmit ASEL responder receives a +HTC MPDU with the MAI subfield equal to ASELI, the ASEL Command subfield equal to TXASSR, and the ASEL Data subfield equal to a nonzero value to correspond to the command Transmit Antenna Selection Sounding Resumption (a Resumption MPDU), the transmit ASEL responder shall respond to the training sequence according to the original command value (i.e., TXASSI or TXASSI-CSI) and shall assume a total number of sounding PPDUs that corresponds to the number of sounding PPDUs from the original command frame. The number of sounding frames that follow the Resumption MPDU is equal to the number of sounding PPDUs from the original command frame minus the order number transmitted in the ASEL Data subfield of the Resumption MPDU. The frame exchange sequence for receive ASEL is shown in Figure 10-51, where the term ASEL receiver identifies the STA that is conducting receive ASEL, and the term ASEL sounding-capable transmitter identifies the STA sending the consecutive sounding PPDUs used for receive ASEL calculations. The frame exchange comprises the following steps: â€” The ASEL receiver transmits a +HTC frame with the MAI subfield set to ASELI, the ASEL Command subfield set to Receive Antenna Selection Sounding Request (RXASSR), and the ASEL Data subfield set to the number of sounding PPDUs required. NOTEâ€” For example, in the case of sounding over all disjointed antenna sets, the number of total consecutive sounding PPDUs or NDPs equals the smallest integer that is greater than or equal to the number of antennas divided by the number of RF chains. â€” The ASEL sounding-capable transmitter responds with the corresponding number of sounding PPDUs in its subsequent TXOP. These PPDUs are separated by SIFS. When using non-NDP sounding, each PPDU contains a +HTC frame in which the MAI subfield is set to ASELI, the ASEL Command subfield is set to Receive Antenna Selection Sounding Indication (RXASSI), and the ASEL Data subfield is set to the remaining number of sounding PPDUs to be transmitted. When using NDP sounding, the PPDU that precedes the first NDP contains a +HTC frame in which the NDP Announce field is set to 1, the MAI subfield is set to ASELI, the ASEL Command subfield is set to RXASSI, and the ASEL Data subfield is set to the remaining number of sounding PPDUs to be transmitted. ASEL Sounding Consecutive Sounding PPDUs + HTC frame Transmitter with NDP Capable announce = 1 RXASSI NDP NDP â€¦ or SIFS SIFS RXASSI RXASSI Receiver SIFS Segmented Segmented ASEL sounding PPDU sounding PPDU RXASSR ASEL Receiver transmits a Receive Antenna Selection Sounding Request Figure 10-51â€”Receive ASEL The ASEL receiver uses different antenna sets to receive these sounding PPDUs, estimates CSI after receiving all these sounding PPDUs, and conducts the ASEL. When transmitting the consecutive sounding PPDUs in transmit and receive ASEL exchanges (illustrated in Figure 10-50 and Figure 10-51), the transmitter shall not change the TXPWR_LEVEL_INDEX parameter of the TXVECTOR. 1484 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications When transmitting a sounding PPDU sent in transmit and receive ASEL exchanges (illustrated in Figure 10-50 and Figure 10-51), if the Receive Staggered Capability subfield of the Transmit Beamforming Capability field of the HT Capabilities element transmitted by the intended receiver is 0, then, â€” If the sounding PPDU is not an NDP, the number of antennas used by the sender, as indicated by the ANTENNA_SET parameter in the TXVECTOR, shall be less than or equal to the maximum number of space-time streams indicated by the Rx MCS Bitmask subfield of the Supported MCS Set field and the Rx STBC subfield of the HT Capabilities element transmitted by the intended receiver. â€” If the sounding PPDU is an NDP, the number of antennas used by the sender, as indicated by the ANTENNA_SET parameter in the TXVECTOR, shall be less than or equal to the number indicated by the Channel Estimation Capability subfield of the Transmit Beamforming Capability field of the HT Capabilities element transmitted by the intended receiver. When both transmitter and receiver have ASEL capabilities, the following constraints apply: â€” During a transmit ASEL frame exchange, the transmit ASEL responder shall use a subset of antennas that does not change during the reception of all of the sounding PPDUs of the ASEL sounding sequence. â€” During a receive ASEL frame exchange, the ASEL sounding-capable transmitter shall use a subset of antennas that does not change during the transmission of all of the sounding PPDUs of the ASEL sounding sequence. NOTEâ€”When a receiver (either a transmit ASEL responder or an ASEL receiver) conducts ASEL computations (for either transmit or receive ASEL), if there is no transmit beamforming conducted at the same time, to achieve the best performance of ASEL, the receiver assumes that the first N STS columns of the same spatial mapping matrix Q k used for transmitting ASEL sounding PPDUs, where N STS is the number of space-time streams, are applied for the spatial mapping at the ASEL transmitter after the ASEL exchange as in Figure 10-50 and Figure 10-51. To achieve the best performance of ASEL, the ASEL transmitter applies the first N STS columns of the same Q k for spatial mapping after the ASEL exchange as in Figure 10-50 and Figure 10-51. 10.34 Null data packet (NDP) sounding 10.34.1 HT NDP sounding protocol Sounding may be accomplished using either staggered sounding PPDU or HT NDP, as described in 19.3.13. The MAC rules associated with sounding using HT NDP are described in 10.34.1 to 10.34.4. An HT STA that has set the Receive NDP Capable field of its HT Capabilities element to 1 during association processes an HT NDP as a sounding packet if the destination of the sounding packet is determined to match itself as described in 10.34.3 and if the source of the sounding packet can be ascertained as described in 10.34.4. An RXVECTOR LENGTH parameter equal to 0 indicates that an HT PPDU is an HT NDP. A STA that is a TXOP holder or an RD responder shall not set both the HT NDP Announcement and RDG/ More PPDU subfields to 1 simultaneously. The Calibration Position subfield shall not be set to any value except 0 and 1 in any +HTC frame in a PPDU that is also an HT NDP announcement. The Calibration Position subfield shall be set to 0 in any +HTC frame in a PPDU that is an HT NDP announcement that also contains any +HTC frame with the MAI subfield equal to ASELI. The Calibration Position subfield shall be set to 0 in all +HTC frames in a PPDU that is an HT NDP announcement and that contains any +HTC frame with the MRQ subfield equal to 1. The TRQ field shall be set to 0 in all +HTC frames in a PPDU that is an HT NDP announcement. An NDP sequence contains at least one HT NDP and at least one PPDU that is not an NDP. Only one PPDU in the NDP sequence may contain an HT NDP announcement. An NDP sequence begins with an HT NDP 1485 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications announcement. The NDP sequence ends at the end of the transmission of the last HT NDP that is announced by the HT NDP announcement. A STA that transmits the first PPDU of an NDP sequence is the NDP sequence owner. In the NDP sequence, only PPDUs carrying HT NDP and PPDUs carrying single MPDU Control frames may follow the NDP sequenceâ€™s starting PPDU. A STA shall transmit only one HT NDP per HT NDP announcement, unless the HT NDP announcement includes a value in the ASEL Data subfield of the ASEL Command subfield of the HTC Control field that is greater than one. Each PPDU in an NDP sequence shall start a SIFS after end of the previous PPDU. A STA shall not transmit a VHT NDP in a NDP sequence that contains an HT NDP announcement. A CTS frame that is a +HTC frame shall not contain the HT NDP Announcement subfield set to 1. NOTEâ€”A CTS frame cannot be used for HT NDP announcement: if the CTS frame is a response to an RTS frame, the optional NAV reset timeout that starts at the end of the RTS frame does not include the additional HT NDP and SIFS (see 10.3.2.4). Also, if the CTS were the first frame of an NDP sequence, it would not be possible to determine the destination address of the HT NDP. A STA shall transmit an HT NDP as follows: a) A SIFS after sending a PPDU that is an HT NDP announcement and that does not contain an MPDU that requires an immediate response. b) A SIFS after successfully receiving a correctly formed and addressed immediate response to a PPDU that is an HT NDP announcement and that contains an MPDU that requires an immediate response. c) A SIFS after transmitting an HT NDP if the HT NDP announcement contains an ASEL Command subfield equal to TXASSI, TXASSI-CSI, or RXASSI and the ASEL Data subfield is equal to a value greater than 0 and if the number of HT NDPs sent before this one is less than the value in the ASEL Data subfield + 1. NOTEâ€”The total number of sent HT NDPs is equal to the value of in the ASEL Data subfield + 1. d) A SIFS after receiving an HT NDP from a STA whose HT NDP announcement contained one or more +HTC frames with the Calibration Position subfield equal to 1, when the receiving STA supports transmitting sounding PPDUs for which more than one channel dimension can be estimated (i.e., more than one column of the MIMO channel matrix). This rule enables the NDP receiver to know that it will receive an HT NDP and can determine the source and destination of the HT NDP. It enables the receiver and transmitter to know when the immediate response and HT NDP will be transmitted relative to the frame containing the HT NDP announcement indication. A STA that has transmitted an HT NDP announcement in a frame that requires an immediate response and that does not receive the expected response shall terminate the NDP sequence at that point (i.e., the STA does not transmit an HT NDP in the current NDP sequence). A STA that has received an HT NDP announcement in a +HTC with the Calibration Position equal to 1 or 2, and that does not receive the HT NDP. expected shall terminate the NDP sequence at that point (i.e., does not transmit an HT NDP in the current NDP sequence) and not transmit any further frames that are a part of this calibration sequence shown in Step 1 of Figure 10-48. Feedback information generated from the reception of an HT NDP is transmitted using any of the feedback rules and signaling as appropriate, e.g., immediate or delayed. 1486 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.34.2 Transmission of an HT NDP A STA that transmits an HT NDP shall set the LENGTH, SOUNDING, STBC, MCS, and NUM_EXTEN_SS parameters of the TXVECTOR as specified in this subclause. â€” LENGTH shall be set to 0. â€” SOUNDING shall be set to SOUNDING. â€” STBC shall be set to 0. â€” MCS shall indicate two or more spatial streams. The number of spatial streams sounded is indicated by the MCS parameter of the TXVECTOR and shall not exceed the limit indicated by the Channel Estimation Capability field in the Transmit Beamforming Capabilities field transmitted by the STA that is the intended receiver of the HT NDP. The MCS parameter may be set to any value, subject to the constraint of the previous sentence, regardless of the value of the Supported MCS Set field of the HT Capabilities field at either the transmitter or recipient of the HT NDP. A STA shall set the NUM_EXTEN_SS parameter of the TXVECTOR to 0 in the PHY-TXSTART.request primitive corresponding to an HT NDP transmission. A STA shall not transmit an HT NDP announcement with an RA corresponding to another STA unless it has received an HT Capabilities element from the destination STA in which the Receive NDP Capable field is equal to 1. 10.34.3 Determination of HT NDP destination The destination of an HT NDP is determined at the NDP receiver by examining the HT NDP announcement as follows: â€” The destination of the first HT NDP in the NDP sequence is equal to the RA of any MPDU within HT NDP announcement. â€” If Calibration Position subfield is equal to 1 in the HT NDP announcement at the NDP receiver, the destination of the second HT NDP is equal to the TA of that frame. Otherwise, the destination of the second and any subsequent HT NDPs is equal to the destination of the previous HT NDP. See O.4 for an illustration of these rules. 10.34.4 Determination of HT NDP source The source of an HT NDP is determined at the NDP receiver by examining the NDP sequencesâ€™s starting PPDU as follows: â€” If any MPDU within the HT NDP announcement contains two or more addresses, the source of the first HT NDP is equal to the TA of that frame. â€” Otherwise (i.e., the HT NDP announcement contains one address), the source of the first HT NDP is equal to the RA of the MPDU to which the HT NDP announcement is a response. â€” If the Calibration Position subfield is equal to 1 in an MPDU in the HT NDP announcement, the source of the second HT NDP is equal to the RA of that MPDU. Otherwise, the source of the second and any subsequent HT NDPs is equal to the source of the previous NDP. See O.4 for an illustration of these rules. 1487 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.34.5 VHT sounding protocol 10.34.5.1 General Transmit beamforming and DL-MU-MIMO require knowledge of the channel state to compute a steering matrix that is applied to the transmitted signal to optimize reception at one or more receivers. The STA transmitting using the steering matrix is called the VHT beamformer, and a STA for which reception is optimized is called a VHT beamformee. An explicit feedback mechanism is used where the VHT beamformee directly measures the channel from the training symbols transmitted by the VHT beamformer and sends back a transformed estimate of the channel state to the VHT beamformer. The VHT beamformer then uses this estimate, perhaps combining estimates from multiple VHT beamformees, to derive the steering matrix. If dot11VHTSUBeamformerOptionImplemented is true, a STA shall set the SU Beamformer Capable field in the VHT Capabilities element to 1. If dot11VHTSUBeamformeeOptionImplemented is true, a STA shall set the SU Beamformee Capable field in the VHT Capabilities element to 1. If dot11VHTMUBeamformerOptionImplemented is true, a STA shall set the MU Beamformer Capable field in the VHT Capabilities element to 1. If dot11VHTMUBeamformeeOptionImplemented is true, a STA shall set the MU Beamformee Capable field in the VHT Capabilities element to 1. If dot11VHTMUBeamformerOptionImplemented is true, a STA shall set dot11VHTSUBeamformerOptionImplemented to true. If dot11VHTMUBeamformeeOptionImplemented is true, a STA shall set dot11VHTSUBeamformeeOptionImplemented to true. A STA is a VHT SU-only beamformer if it sets the SU Beamformer Capable field to 1 but sets the MU Beamformer Capable field to 0 in transmitted VHT Capabilities elements. A STA is an SU-only beamformee if it sets the SU Beamformee Capable field to 1 but sets the MU Beamformee Capable field to 0 in transmitted VHT Capabilities elements. If dot11VHTSUBeamformerOptionImplemented is false, a STA shall not act in the role of a VHT beamformer. If dot11VHTSUBeamformeeOptionImplemented is false, a STA shall not act in the role of a VHT beamformee. 10.34.5.2 Rules for VHT sounding protocol sequences A VHT beamformer shall initiate a sounding feedback sequence by transmitting a VHT NDP Announcement frame followed by a VHT NDP after a SIFS. The VHT beamformer shall include in the VHT NDP Announcement frame one STA Info field for each VHT beamformee that is expected to prepare VHT Compressed Beamforming feedback and shall identify the VHT beamformee by including the VHT beamformeeâ€™s AID in the AID subfield of the STA Info field. The VHT NDP Announcement frame shall include at least one STA Info field. NOTEâ€•A STA that transmits a VHT NDP Announcement frame to a DLS or TDLS peer STA obtains the AID for the peer STA from the DLS Setup Request, DLS Setup Response, TDLS Setup Request, or TDLS Setup Response frame. A VHT beamformer shall not transmit either a VHT NDP Announcement+HTC frame or a Beamforming Report Poll+HTC frame that contains an HT variant HT Control field. A VHT NDP shall be transmitted only following a SIFS after a VHT NDP Announcement frame. A VHT NDP Announcement frame shall be followed by a VHT NDP after SIFS. A VHT beamformer that has not received a VHT Capabilities element from a STA or where the last VHT Capabilities element received from a STA has the SU Beamformee Capable field set to 0 shall not transmit either of the following: 1488 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” A VHT NDP Announcement frame addressed to the STA or that includes the STAâ€™s AID in one of the STA Info fields â€” A Beamforming Report Poll frame addressed to the STA A VHT beamformer that transmits a VHT NDP Announcement frame to a VHT SU-only beamformee shall include only one STA Info field in the VHT NDP Announcement frame and set the Feedback Type subfield of the STA Info field to SU. If the VHT NDP Announcement frame includes more than one STA Info field, the RA of the VHT NDP Announcement frame shall be set to the broadcast address. If the VHT NDP Announcement frame includes a single STA Info field, the RA of the VHT NDP Announcement frame shall be set to the MAC address of the VHT beamformee. A VHT NDP Announcement frame shall not include two or more STA Info fields with same value in the AID subfield. A VHT beamformer that transmits a VHT NDP Announcement frame to a VHT beamformee that is an AP, mesh STA or STA that is a member of an IBSS, shall include a single STA Info field in the VHT NDP Announcement frame and shall set the AID field in the STA Info field to 0. A VHT NDP Announcement frame with more than one STA Info field shall not carry a VHT variant HT Control field, unless all of the STAs listed in the AID field of the STA Info fields have set +HTC-VHT Capable to 1 in the VHT Capabilities Information field. A VHT beamformer that transmits a VHT NDP Announcement frame with more than one STA Info field should transmit any Beamforming Report Poll frames used to retrieve VHT Compressed Beamforming feedback from the intended VHT beamformees in the same TXOP. If the duration of the TXOP that contained the VHT NDP Announcement frame has insufficient duration to accommodate the transmission of all of the feedback reports, the VHT beamformer may poll for the remaining VHT Compressed Beamforming feedback in subsequent TXOPs. A VHT beamformer may use the following worst-case parameters to estimate the duration of the expected frame(s) that contain(s) the feedback response(s): lowest rate in basic VHT-MCS set, no grouping. NOTEâ€”The transmission of the VHT NDP Announcement, VHT NDP, VHT Compressed Beamforming, and Beamforming Report Poll frames is subject to the rules in 10.22.2.7. A VHT beamformer that sets the Feedback Type subfield of a STA Info field to MU shall set the Nc Index subfield of the same STA Info field to a value less than or equal to the minimum of both of the following: â€” The maximum number of supported spatial streams for receive operation according to the combination of the corresponding VHT beamformeeâ€™s Rx VHT-MCS Map subfield in the Supported VHT-MCS and NSS Set field and VHT Capabilities Information field â€” The maximum number of supported spatial streams according to the Rx NSS subfield value and, when the value of the VHT Extended NSS BW Capable subfield received from the VHT beamformee is 1 and dot11ExtendedNSSSupported is equal to true, the 160/80+80 BW subfield value in the Operating Mode field of the most recently received Operating Mode Notification frame or Operating Mode Notification element with the Rx NSS Type subfield equal to 0 from the corresponding VHT beamformee, as computed according to 10.7.12.1 A non-AP VHT beamformee that receives a VHT NDP Announcement frame from a VHT beamformer with which it is associated or has an established DLS or TDLS session and that contains the VHT beamformeeâ€™s AID in the AID subfield of the first (or only) STA Info field and also receives a VHT NDP a SIFS after the VHT NDP Announcement frame shall transmit the PPDU containing its VHT Compressed Beamforming 1489 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications feedback a SIFS after the VHT NDP. A VHT beamformee that is an AP, mesh STA, or STA that is a member of an IBSS, that receives a VHT NDP Announcement frame with the RA matching its MAC address and the AID subfield of the only STA Info field set to 0, and that also receives a VHT NDP a SIFS after the VHT NDP Announcement frame shall transmit the PPDU containing its VHT Compressed Beamforming feedback a SIFS after the VHT NDP. The TXVECTOR parameter CH_BANDWIDTH of the PPDU containing the VHT Compressed Beamforming feedback shall be set to indicate a bandwidth not wider than that indicated in the RXVECTOR parameter CH_BANDWIDTH of the received VHT NDP frame. A STA ignores received VHT NDP Announcement, VHT NDP, and Beamforming Report Poll frames if dot11VHTSUBeamformeeOptionImplemented is false. A VHT beamformee shall indicate the maximum number of space-time streams it can receive in a VHT NDP in the Beamformee STS Capability subfield of the VHT Capabilities Information field of the VHT Capabilities element. If the beamformee is a non-AP STA, this shall be less than or equal to the maximum total number of space-time streams that the STA can receive in a VHT MU PPDU. An example of the VHT sounding protocol with a single VHT beamformee is shown in Figure 10-52. VHT NDP Beamformer Announce- NDP ment VHT Beamformee Compressed SIFS SIFS Beamforming Figure 10-52â€”Example of the sounding protocol with a single VHT beamformee A non-AP VHT beamformee that receives a VHT NDP Announcement frame from a VHT beamformer with which it is associated or has an established DLS or TDLS session and that contains the VHT beamformeeâ€™s AID in the AID subfield of a STA Info field that is not the first STA Info field shall transmit its VHT Compressed Beamforming feedback a SIFS after receiving a Beamforming Report Poll with RA matching its MAC address and a nonbandwidth signaling TA obtained from the TA field matching the MAC address of the VHT beamformer. If the RXVECTOR parameter CH_BANDWIDTH_IN_NON_HT of the received Beamforming Report Poll frame is valid, the TXVECTOR parameter CH_BANDWIDTH of the PPDU containing the VHT Compressed Beamforming feedback shall be set to indicate a bandwidth not wider than that indicated by the RXVECTOR parameter CH_BANDWIDTH_IN_NON_HT of the Beamforming Report Poll frame; otherwise, the TXVECTOR parameter CH_BANDWIDTH of the PPDU containing VHT Compressed Beamforming feedback shall be set to indicate a bandwidth not wider than that indicated by the RXVECTOR parameter CH_BANDWIDTH of the Beamforming Report Poll frame. An example of the VHT sounding protocol with more than one VHT beamformee is shown in Figure 10-8. VHT NDP Beamforming Beamforming SIFS SIFS SIFS SIFS SIFS SIFS Beamformer Announce- NDP Report Poll Report Poll ment VHT Compressed Beamformee 1 Beamforming VHT Compressed Beamformee 2 Beamforming VHT Compressed Beamformee 3 Beamforming Figure 10-53â€”Example of the sounding protocol with more than one VHT beamformee The RA field of the VHT Compressed Beamforming frame(s) of the VHT Compressed Beamforming feedback shall be set to a nonbandwidth signaling TA obtained from the TA field of the VHT NDP Announcement 1490 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications frame or the Beamforming Report Poll frame to which this VHT Compressed Beamforming feedback is a response. If the VHT Beamformee is transmitting VHT Compressed Beamforming frame(s) a SIFS after the VHT NDP, then the VHT Compressed Beamforming frame(s) shall include the VHT Compressed Beamforming Report information and, for the case of MU feedback, the MU Exclusive Beamforming Report information. A VHT beamformee that transmits a VHT Compressed Beamforming frame shall set the Feedback Type field in the VHT MIMO Control field to the same value as the Feedback Type field in the corresponding STA Info field in the VHT NDP Announcement frame. If the Feedback Type field indicates MU, the STA shall send a VHT Compressed Beamforming frame with the Nc Index field value in the VHT MIMO Control field equal to the minimum of all of the following: â€” The Nc Index field value in the corresponding STA Info field in the VHT NDP Announcement Frame â€” The maximum number of supported spatial streams for receive operation according to the combination of its Rx VHT-MCS Map subfield in the Supported VHT-MCS and NSS Set field, VHT Capabilities Information field and Operating Mode field (see 10.7.12.1) â€” The maximum number of supported spatial streams according to the Rx NSS subfield value and, when the value of the most recently transmitted VHT Extended NSS BW Capable subfield is 1, the 160/80+80 BW subfield value in the Operating Mode field of the most recently transmitted Operating Mode Notification frame or Operating Mode Notification element, as computed according to 10.7.12.1 If the Feedback Type indicates SU, the Nc Index field value in the VHT MIMO Control field is determined by the VHT beamformee. The Nr Index field in the VHT MIMO Control field shall be set to the same value as the RXVECTOR parameter NUM_STS of the corresponding VHT NDP. The Nc Index field shall not be set to a value larger than the Nr Index value in the VHT MIMO Control field. A VHT beamformee shall set the value of the Channel Width subfield in the VHT MIMO Control field of a VHT Compressed Beamforming frame to the same value as the RXVECTOR parameter CH_BANDWIDTH of the corresponding VHT NDP frame. A VHT beamformee shall not include MU Exclusive Beamforming Report information in VHT Compressed Beamforming feedback if the Feedback Type subfield in the MIMO Control field of the VHT Compressed Beamforming frame(s) indicates SU. A VHT beamformee shall include both VHT Compressed Beamforming Report information and MU Exclusive Beamforming Report information in VHT Compressed Beamforming feedback if the Feedback Type subfield in the MIMO Control field of the VHT Compressed Beamforming frame(s) indicates MU. A VHT beamformee that transmits VHT Compressed Beamforming feedback shall include neither the VHT Compressed Beamforming Report information and nor the MU Exclusive Beamforming Report information if the transmission duration of the PPDU carrying the VHT Compressed Beamforming Report information and any MU Exclusive Beamforming Report information would exceed the maximum PPDU duration. The value of the Sounding Dialog Token Number subfield in the VHT MIMO Control field shall be set to the same value as the Sounding Dialog Token Number subfield in the Sounding Dialog Token field in the corresponding VHT NDP Announcement frame. NOTE 1â€”The VHT beamformer can use the sounding dialog token in the VHT Compressed Beamforming frame(s) of the VHT Compressed Beamforming feedback to associate the feedback with a prior VHT NDP Announcement frame and thus compute the delay between sounding and receiving the feedback. The VHT beamformer can use this delay time when making a decision regarding the applicability of the feedback for the link. NOTE 2â€”Recovery in the case of a missing response to a VHT NDP Announcement or Beamforming Report Poll frame follows the rules for multiple frame transmission in an EDCA TXOP (see 10.22.2.7). 1491 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications VHT Compressed Beamforming feedback comprises the VHT Compressed Beamforming Report information (see Table 9-69) and the MU Exclusive Beamforming Report information (see Table 9-72). Subclause 9.6.23.2 specifies how VHT Compressed Beamforming feedback is converted into a VHT Compressed Beamforming frame, and it also specifies the rules for the presence or absence of the two fields listed here. In a frame transmitted by a TVHT STA, the TVHT Compressed Beamforming Report field replaces the VHT Compressed Beamforming Report field. In a frame transmitted by a TVHT STA, the TVHT MU Exclusive Beamforming Report field replaces the MU Exclusive Beamforming Report field. 10.34.5.3 Rules for fragmented feedback in VHT sounding protocol sequences VHT Compressed Beamforming feedback shall be transmitted in a single VHT Compressed Beamforming frame unless the result would be a VHT Compressed Beamforming frame that exceeds the VHT beamformerâ€™s maximum MPDU length capability. NOTEâ€”The VHT beamformee might therefore have to transmit an MPDU that is bigger than the VHT beamformee is capable of receiving. If VHT Compressed Beamforming feedback would result in a VHT Compressed Beamforming frame that exceeds the VHT beamformerâ€™s maximum MPDU length capability, the VHT Compressed Beamforming feedback shall be split into up to 8 feedback segments, with each feedback segment sent in a different VHT Compressed Beamforming frame and containing successive portions of the VHT Compressed Beamforming feedback consisting of the VHT Compressed Beamforming Report information followed by any MU Exclusive Beamforming Report information. Each of the feedback segments except the last shall contain the maximum number of octets allowed by the VHT beamformerâ€™s maximum MPDU length capability. The last feedback segment may be smaller. Each feedback segment is identified by the value of the Remaining Feedback Segments subfield and the First Feedback Segment subfield in the VHT MIMO Control field as defined in 9.4.1.48; the other nonreserved subfields of the VHT MIMO Control field shall be the same for all feedback segments. All feedback segments shall be sent in a single A-MPDU and shall be included in the A-MPDU in the descending order of the Remaining Feedback Segments subfield values. NOTEâ€”The feedback segments of a VHT Compressed Beamforming report are not MSDU/MMPDU fragments and can be included in an A-MPDU as described in this subclause. A VHT beamformer, in its first attempt to retrieve VHT Compressed Beamforming feedback from a VHT beamformee that is not the one indicated by the first STA Info field, shall transmit a Beamforming Report Poll frame to poll all possible feedback segments of the VHT Compressed Beamforming feedback from the VHT beamformee, by setting all of the bits in the Feedback Segment Retransmission Bitmap field of the Beamforming Report Poll frame to 1. If a VHT beamformer fails to receive some or all feedback segments of VHT Compressed Beamforming feedback, the VHT beamformer may, subject to the condition on VHT SU-only beamformees described at the end of this subclause, request a selective retransmission of missing feedback segments by transmitting a Beamforming Report Poll frame with the Feedback Segment Retransmission Bitmap field set as described in 9.3.1.21 to indicate the feedback segments requested for retransmission. If the VHT beamformer fails to receive the feedback segment with the First Feedback Segment field set to 1, the VHT beamformer may request a selective retransmission of missing feedback segments assuming the VHT Compressed Beamforming feedback is split into 8 feedback segments. The VHT beamformer may also request the retransmission of all feedback segments by setting all of the bits in the Feedback Segment Retransmission Bitmap field of the Beamforming Report Poll frame to 1. A VHT beamformee that transmits VHT Compressed Beamforming feedback including the VHT Compressed Beamforming Report information and any MU Exclusive Beamforming Report information in response to a 1492 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Beamforming Report Poll frame shall either transmit only the feedback segments indicated in the Feedback Segment Retransmission Bitmap field in the Beamforming Report Poll frame excluding the indicated feedback segments that do not exist at the VHT beamformee or transmit all of the feedback segments that exist at the VHT beamformee disregarding the Feedback Segment Retransmission Bitmap field in the Beamforming Report Poll frame. A VHT beamformer shall not transmit a Beamforming Report Poll frame to a VHT SU-only beamformee unless the VHT beamformer has received at least one feedback segment of the VHT Compressed Beamforming feedback from the VHT beamformee in the current frame exchange sequence. In a frame transmitted by a TVHT STA, the TVHT Compressed Beamforming Report field replaces the VHT Compressed Beamforming Report field. In a frame transmitted by a TVHT STA, the TVHT MU Exclusive Beamforming Report field replaces the MU Exclusive Beamforming Report field. 10.34.6 Transmission of a VHT NDP A VHT NDP shall use the SU PPDU format as described in 21.1.4. A STA shall transmit a VHT NDP using the following TXVECTOR parameters: â€” APEP_LENGTH set to 0 â€” NUM_USERS set to 1 â€” NUM_STS indicates two or more space-time streams â€” CH_BANDWIDTH set to the same value as the TXVECTOR parameter CH_BANDWIDTH in the preceding VHT NDP Announcement frame â€” GROUP_ID and PARTIAL_AID are set as described in 10.20 The number of space-time streams sounded and as indicated by the NUM_STS parameter shall not exceed the value indicated in the Beamformee STS Capability field in the VHT Capabilities element of any intended recipient of the VHT NDP. The NUM_STS parameter may be set to any value, subject to the constraint of the previous sentence, regardless of the value of the Supported VHT-MCS and NSS Set field of the VHT Capabilities element at either the transmitter or recipient of the NDP. The destination of a VHT NDP is equal to the RA of the immediately preceding VHT NDP Announcement frame. The source of a VHT NDP is equal to the TA of the immediately preceding VHT NDP Announcement frame. 10.35 Mesh forwarding framework 10.35.1 General The term mesh forwarding refers to forwarding of MSDUs and MMPDUs on paths determined by the mesh path selection between mesh STAs at the link layer. The mesh paths are contained in the forwarding information. The forwarding information, for instance, the lifetime of a mesh path, may be updated as a consequence of mesh forwarding. The forwarding of MSDUs and MMPDUs within an MBSS is described in 10.35.3, 10.35.4, 10.35.5, and 10.35.8. The forwarding of MSDUs and MMPDUs between the MBSS and the DS at proxy mesh gates is described in 14.11.3. 1493 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.35.2 Forwarding information Forwarding information is created by the active mesh path selection protocol and is utilized for MSDU/ MMPDU forwarding as described in 10.35.3 and 10.35.5.2. The basic forwarding information to a destination mesh STA consists of the destination mesh STA address, the next-hop address, the precursor list, and the lifetime of this forwarding information. An entry in the precursor list contains the precursor mesh STA address and the lifetime of this entry. If an existing entry in a precursor list is updated, the lifetime is the maximum of the current and the updated value. If the lifetime of a precursor expires, it will be deleted from the precursor list. Precursors are used to identify legitimate transmitters of individually addressed frames (see 10.35.3.2) and for the notification of link failures (in case of HWMP, see 14.10.11). The forwarding information shall be considered as invalid if its lifetime has expired. Also, forwarding information is marked as invalid when certain conditions are met in the processing of mesh path selection elements, e.g., path error processing in HWMP (14.10.11.4). The active path selection protocol may define additional parameters in the forwarding information. Details on the additional parameters of the forwarding information constructed by the hybrid wireless mesh protocol (HWMP) are described in 14.10.8.4. 10.35.3 Addressing and forwarding of individually addressed mesh Data frames 10.35.3.1 At source mesh STAs (individually addressed) MSDUs sent by a mesh STA (as a consequence of an MA-UNITDATA.request primitive with an individual destination address) and destined to another mesh STA in the MBSS shall be transmitted using a frame with the four-address MAC header format (with the Address Extension Mode subfield in the Mesh Control field set to â€œNoneâ€ (see Table 9-20)), where the four address fields are set as follows (see row â€œMesh Data (individually addressed)â€ in Table 9-42): â€” Address 1: The address of the next-hop mesh STA (toward the destination mesh STA according to the forwarding informationâ€”see 10.35.2) â€” Address 2: The address of the transmitter mesh STA â€” Address 3: The address of the destination mesh STA â€” Address 4: The address of the source mesh STA MSDUs that are sent by a mesh STA as a consequence of an MA-UNITDATA.request primitive with an individual destination address and are destined to an address that is different from the mesh STA at the end of a mesh path shall be transmitted using a frame with the four-address MAC header format [with the Address Extension Mode subfield in the Mesh Control field set to â€œAddress5&6â€ (see Table 9-20)], where the Mesh Address Extension subfield in the Mesh Control field carries the addresses of the end stations, as specified in row â€œMesh Data (proxied, individually addressed)â€ of Table 9-42. The additional addresses 5 and 6 are defined as follows: â€” Address 5: The address of the destination end mesh STA (may be the same as Address 3 if the destination is the mesh STA at the end of the mesh path) â€” Address 6: The address of the source end mesh STA (may be the same as Address 4 if the source is the mesh STA at the beginning of the mesh path) NOTEâ€”The destination address is distinct from the mesh STA at the end of the mesh path in two cases: 1) when the destination is an external address and 2) when the destination is a mesh STA distinct from the destination mesh STA at the end of the mesh path. The former case is described in 14.11.3. The latter case might occur if a source mesh STA 1494 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications sends the MSDU to another intermediate mesh STA that sends the MSDU on a different mesh path to the destination mesh STA in the MBSS. The Mesh TTL subfield in the Mesh Control field shall be set to dot11MeshTTL.The MSDUs are forwarded multiple hops, limited by the Mesh TTL value. The source mesh STA shall set the Mesh Sequence Number subfield in the Mesh Control field to a value from a modulo 232 counter that is incremented by 1 for each new MSDU transmitted with a Mesh Control field and for each new MMPDU transmitted using a Multihop Action frame. 10.35.3.2 At intermediate and destination mesh STAs (individually addressed) On receipt of an individually addressed mesh Data frame, a mesh STA shall perform the following: a) The mesh STA shall decipher the frame and check it for authenticity. If it is not from a peer mesh STA, the frame shall be silently discarded. b) The mesh STA shall check to see whether the MAC address in the Address 3 field is a known destination address; if it is an unknown destination address, the mesh STA may perform any of the following three actions: 1) Silently discard the frame. 2) Trigger a path discovery procedure depending on the path selection protocol that is currently active in the mesh BSS. For HWMP, see 14.10.9.3 Case A. 3) Inform the mesh STA in Address 2 that the destination is unreachable depending on the path selection protocol that is currently active in the mesh BSS. For HWMP, see 14.10.11.3 Case B. c) If Address 2 is not one of the precursors for this destination mesh STA (see 10.35.2), the frame shall be discarded. If the frame is not discarded and one or more MSDUs are collected from the frame, the mesh STA may detect duplicate MSDUs according to 10.35.6 and discard them. If Address 3 does not match the mesh STAâ€™s own address, but is a known individual destination MAC address in the forwarding information then the following actions are taken: â€” The lifetime of the forwarding information to the destination (Address 3) is set to its initial value. â€” The lifetime of the forwarding information to the source (Address 4) is set to its initial value. â€” The lifetime of the precursor list entry for the precursor to the destination (Address 2) is set to the maximum of the initial value and the current value. â€” The lifetime of the precursor list entry for the precursor to the source (next hop to the destination) is set to the maximum of the initial value and the current value. â€” The Mesh TTL in the corresponding Mesh Control field of the collected MSDU is decremented by 1. If zero has been reached, the MSDU shall be discarded. â€” If the MSDU has not been discarded, the mesh STA shall forward the MSDU via a frame with the Address 1 field set to the MAC address of the next-hop mesh STA as determined from the forwarding information (see 10.35.2) and the Address 2 field set to its own MAC address and queue the frame for transmission. If Address 3 matches the mesh STAâ€™s own MAC address, the following actions are taken: â€” The lifetime of the forwarding information to the source (Address 4) is set to its initial value. â€” The lifetime of the precursor list entry for the precursor to the destination (Address 2) is set to the maximum of the initial value and the current value. 1495 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” If the Address Extension Mode subfield in the Mesh Control field is â€œNoneâ€ (see Table 9-20), the MA-UNITDATA.indication primitive is passed from the MAC sublayer entity to the LLC sublayer entity or entities. â€” If the Address Extension Mode subfield in the Mesh Control field is â€œAddress5&6â€ (see Table 9-20) and Address 5 is equal to Address 3, the mesh STA is the final destination of the MSDU, and the MA-UNITDATA.indication primitive is passed from the MAC sublayer entity to the LLC sublayer entity or entities. â€” If the Address Extension Mode subfield in the Mesh Control field is â€œAddress5&6â€ (see Table 9-20) and Address 5 is a known destination MAC address in the forwarding information (mesh STA), the mesh STA shall forward the MSDU via a frame as described in 10.35.3.1 with the Address 3 field set to the MAC Address of the Address 5 field. â€” If the Address Extension Mode subfield in the Mesh Control field is â€œAddress5&6â€ (see Table 9- 20), the MSDU is forwarded according to 14.11.3.2 in all other cases. If Address 3 matches the group address, the mesh STA shall perform the procedures as given in 10.35.4.2. Note that during the forwarding process at intermediate mesh STAs, the content of the MSDU is not changed. 10.35.4 Addressing and forwarding of group addressed mesh Data frames 10.35.4.1 At source mesh STAs (group addressed) MSDUs sent by a mesh STA (as a consequence of an MA-UNITDATA.request primitive with a group destination address) shall be transmitted using a group addressed mesh Data frame (with the Address Extension Mode subfield in the Mesh Control field set to â€œNoneâ€ (see Table 9-20)) (see row â€œMesh Data (group addressed)â€ in Table 9-42). An implementation may circumvent the unreliability of group addressed transmissions by using multiple individually addressed mesh Data frames, which are individually acknowledged. In such case, the frame may be converted to individually addressed frames and transmitted as individually addressed mesh Data frames to each peer mesh STA as described in 10.35.3.1 with the Address 3 field set to the group address. The circumstances for choosing this method are outside the scope of the standard. In group addressed mesh Data frames, the address fields are set as follows: â€” Address 1: The group address â€” Address 2: The address of the transmitter mesh STA â€” Address 3: The address of the source mesh STA The source mesh STA shall set the Mesh TTL subfield in the Mesh Control field to dot11MeshTTL in order to control the hop count. The MSDUs are forwarded multiple hops, limited by the Mesh TTL value. For example, if the Mesh TTL subfield is 1, MSDUs are delivered only to immediate neighbors. The source mesh STA shall set the Mesh Sequence Number subfield in the Mesh Control field to a value from a modulo 232 counter that is incremented by 1 for each new MSDU transmitted with a Mesh Control field and for each new MMPDU transmitted using a Multihop Action frame. Procedures that enhance the reliability or efficiency of group addressed transmissions are outside the scope of this standard. 1496 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.35.4.2 At recipient mesh STAs (group addressed) On receipt of a group addressed mesh Data frame with Address 1 (DA) equal to the group address, or on receipt of an individually addressed mesh Data frame with Address 3 (Mesh DA) equal to the group address, a mesh STA shall perform the following: a) The mesh STA shall decipher the frame and check it for authenticity. If it is not from a peer mesh STA, the frame shall be silently discarded. b) If the frame is not discarded and one or more MSDUs are collected from the frame, the mesh STA may detect duplicate MSDUs according to 10.35.6 and discard them. c) The mesh STA decrements the Mesh TTL in the Mesh Control field. If the Mesh TTL value has reached zero, the corresponding MSDU shall not be forwarded to other mesh STAs. d) If the Mesh TTL value has not reached zero and if dot11MeshForwarding is true, the mesh STA shall forward the MSDU via a group address mesh Data frame with the Address 2 field set to its own MAC address. e) If the Address Extension Mode is â€œAddress4â€ (see Table 9-20) and the recipient mesh STA is a proxy mesh gate and if the Mesh TTL value has not reached zero and if dot11MeshForwarding is true, the MSDU is forwarded according to 14.11.3.2. When the SA and the Mesh SA are not identical (the source address is therefore an external address), the MSDU shall be forwarded by using a frame with the three-address MAC header format [with the Address Extension Mode subfield in the Mesh Control field set to â€œAddress4â€ (see Table 9-20)] as specified in row â€œMesh Data (proxied, group addressed)â€ of Table 9-42. Otherwise, the MSDU shall be forwarded by using a frame with the three-address MAC header format [with the Address Extension Mode subfield in the Mesh Control field set to â€œNoneâ€ (see Table 9-20)] as specified in row â€œMesh Data (group addressed)â€ of Table 9-42. An implementation may circumvent the unreliability of group addressed transmissions by using multiple individually addressed mesh Data frames, which are individually acknowledged. In such case, the frame may be converted to individually addressed frames and transmitted as an individually addressed mesh Data frame to each peer mesh STAs as described in 10.35.3.2 with the Address 3 field set to the group address. If the Address Extension Mode subfield in the Mesh Control field in the group addressed mesh Data frame is equal to â€œAddress4â€ (see Table 9-20), the Address Extension Mode subfield in the Mesh Control field in the individually addressed mesh Data frames is set to â€œAddress5&6â€ (see Table 9-20), the Address 5 field is set to the group address, and the Address 6 field set to the Source Address contained in the Address 4 field of the group addressed mesh Data frame. The circumstances for choosing this method and the ability to determine all of the addresses of the neighbor peer mesh STAs are beyond the scope of the standard. If one or more MSDUs collected from the frame have not been discarded, the MA-UNITDATA.indication primitive is passed from the MAC sublayer entity to the LLC sublayer entity or entities. 10.35.5 Addressing of Management frames and MMPDU forwarding 10.35.5.1 General All MMPDUs except MMPDUs transmitted using Multihop Action frames are transmitted over only one hop to peer mesh STAs. NOTEâ€”In several cases, the reception and processing of an Action frame leads to the transmission of a new Action frame of the same type that might include an identical or a modified version of the contents from the elements of the received Action frame. This is called propagation in contrast to forwarding. A mesh STA may convert a group addressed Management frame to individually addressed Management frames and transmit them as individually addressed frames to each peer mesh STA, if the frame is intended 1497 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications to be delivered only to its peer mesh STAs. The circumstances for choosing this method are outside the scope of the standard. 10.35.5.2 MMPDU forwarding using individually addressed Multihop Action frames MMPDUs sent by a mesh STA and destined to another mesh STA in the MBSS using individually addressed Multihop Action frames (see 9.6.18) shall be transmitted using a Management frame with the three-address MAC header format (with the Address Extension Mode subfield in the Mesh Control field set to â€œAddress4â€ (see Table 9-20)), where the four address fields are set as follows (see row â€œMultihop Action (individually addressed)â€) in Table 9-42: â€” Address 1: The address of the next-hop mesh STA (toward the destination mesh STA according to the forwarding informationâ€”see 10.35.2. â€” Address 2: The address of the transmitter mesh STA. â€” Address 3: The address of the destination mesh STA. â€” Address 4: The address of the source mesh STA. The source mesh STA shall set the Mesh TTL subfield in the Mesh Control field to dot11MeshTTL, and set the Mesh Sequence Number subfield in the Mesh Control field to a value from a modulo 232 counter that is incremented by 1 for each new MSDU transmitted with a Mesh Control field and for each new MMPDU transmitted using a Multihop Action frame. At intermediate and destination mesh STAs, on receipt of an individually addressed Multihop Action frame, the address matching, the reception procedures, the forwarding information update, and the Mesh TTL decrement are performed as described in 10.35.3.2, and the MMPDU is forwarded according to the forwarding information and the procedures in 10.35.3.2. At intermediate mesh STAs, frame fields following the Mesh Control field are not required to be examined. If the Address 3 in the received Multihop Action frame matches the mesh STAâ€™s own MAC address or the group address, the mesh STA (destination mesh STA) shall process the content of the MMPDU. 10.35.5.3 MMPDU forwarding using group addressed Multihop Action frames MMPDUs sent by a mesh STA and destined to all other mesh STAs in the MBSS using group addressed Multihop Action frames (see 9.6.18) shall be transmitted using a Management frame with the three-address MAC header format (with the Address Extension Mode subfield in the Mesh Control field set to â€œNoneâ€ (see Table 9-20)), where the three address fields are set as follows (see row â€œMultihop Action (group addressed)â€ in Table 9-42): â€” Address 1: The group address â€” Address 2: The address of the transmitter mesh STA â€” Address 3: The address of the source mesh STA An implementation may circumvent the unreliability of group addressed transmissions by using multiple individually addressed Multihop Action frames, which are individually acknowledged. In such case, the frame may be converted to individually addressed frames and transmitted as individually addressed Multihop Action frames to each peer mesh STA as described in 10.35.5.2 with the Address 3 field set to the group address. The circumstances for choosing this method are outside the scope of the standard. The source mesh STA shall set the Mesh TTL subfield in the Mesh Control field to dot11MeshTTL, and set the Mesh Sequence Number subfield in the Mesh Control field to a value from a modulo 232 counter that is incremented by 1 for each new MSDU transmitted with a Mesh Control field and for each new MMPDU transmitted using a Multihop Action frame. 1498 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications At recipient mesh STAs, on receipt of Multihop Action frame, the address matching, the reception procedures, the forwarding information update, and the Mesh TTL decrement are performed as described in 10.35.4.2, and the MMPDU is forwarded according to the forwarding information and the procedures in 10.35.4.2. If the Address 1 in the received Multihop Action frame matches the group address, the mesh STA shall process the content of the MMPDU. Procedures that enhance the reliability or efficiency of group addressed transmissions are outside the scope of this standard. 10.35.6 Detection of duplicate MSDUs/MMPDUs A mesh STA may receive multiple copies of the same MSDU or MMPDU from different neighbor peer mesh STAs. The filtering of such duplicates is facilitated through the inclusion of a Mesh Sequence Number subfield in the Mesh Control field in mesh Data frames and Multihop Action frames as specified in 9.2.4.7.3. The receiving mesh STA shall keep a cache of recently received tuples. The Mesh Source Address (Mesh SA) is contained in Address 4 for individually addressed mesh Data frames and Multihop Action frames. The Mesh Source Address (Mesh SA) is contained in Address 3 for group addressed mesh Data frames. A mesh STA shall reject an MSDU/MMPDU with a Mesh Control field as a duplicate if it matches a tuple of an entry in the cache. The rules in 10.3.2.11 also apply to the filtering of duplicates sent by the same neighbor peer mesh STA. 10.35.7 Mesh STAs that do not forward A mesh STA that has dot11MeshForwarding equal to false does not forward either MSDUs, or Multihop Action frames. The circumstances in which a mesh STA may be allowed to become a non- forwarding entity and the authority to set dot11MeshForwarding to false are beyond the scope of this standard. A mesh STA that does not forward is a special case of a mesh STA. Such mechanism depends on whether the path selection protocol provides a mechanism to allow mesh STAs not to participate in forwarding. The HWMP path selection protocol provides such a mechanism; see 14.10. 10.35.8 MSDU forwarding and unknown destination A source mesh STA in the MBSS might not able to forward an MSDU that it has received as a consequence of an MA-UNITDATA.request primitive with an individual destination address. This is the case if the destination of the MSDU is unknown to the mesh STA. The destination is unknown to a mesh STA if the mesh STA has no forwarding information for this destination or if the destination is not in its proxy information as an external STA (see 14.11.4.2). Note that the procedure to determine that an address is unknown depends on the active path selection protocol. It might require an attempt to establish a path to the destination (see 14.8). If the source mesh STA is not able to forward the MSDU because its destination is unknown, the mesh STA shall assume that the destination is outside the MBSS and shall forward the MSDU to known mesh gates in the MBSS as one or more individually addressed frames according to the procedures for frame addressing and data forwarding of individually addressed frames at source mesh STAs in an MBSS (10.35.3.1). These frame(s) shall be transmitted using the four-address MAC header format (with the Address Extension Mode 1499 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications subfield in the Mesh Control field set to â€œAddress5&6â€ (see Table 9-20)), where the Mesh Address Extension subfield in the Mesh Control field carries the address of the destination end station, as specified in row â€œMesh Data (proxied, individually addressed)â€ of Table 9-42. The address fields are set as follows: â€” Address 1: The address of the next-hop mesh STA (toward the known mesh gate in the MBSS according to the forwarding informationâ€”see 10.35.2). â€” Address 2: The address of the source mesh STA. â€” Address 3: The address of the known mesh STA in the MBSS. â€” Address 4: The address of the source mesh STA. â€” Address 5: The address of the destination end mesh STA, which is the unknown destination address of the MSDU â€” Address 6: The address of the source mesh STA, which is the same as Address 4 If there is no mesh gate available, the mesh STA shall silently discard the MSDU. Discovery of mesh gates by mesh STAs is performed using propagated elements, such as a GANN (14.11.2). Other methods specific to the HWMP path selection protocol are also available, such as the proactive PREQ mechanism (14.10.4.2) or the proactive RANN mechanism (14.10.4.3), when the Gate Announcement subfield in the Flags field in these HWMP elements is set to 1. 10.36 DMG channel access 10.36.1 General Channel access by a DMG STA is related to beacon interval timing and is coordinated using a schedule. A DMG STA operating as an AP or PCP generates the schedule and communicates it to STAs using DMG Beacon and Announce frames. A non-PCP STA that is a non-AP STA and that receives scheduling information accesses the medium during the scheduled periods using the access rules specific to that period. Medium access rules to establish a BSS are defined in 10.37 and 11.1.4. 10.36.2 Access periods within a beacon interval Medium time within a DMG BSS is divided into beacon intervals. Subdivisions within the beacon interval are called access periods. Different access periods within a beacon interval have different access rules. The access periods are described in a schedule that is communicated by the AP or PCP to the non-PCP and non- AP STAs within the BSS. The schedule communicated by the AP or PCP can include the following access periods: â€” BTI: An access period during which one or more DMG Beacon frames is transmitted. Not all DMG Beacon frames are detectable by all non-PCP and non-AP STAs (see 10.38.4). Not all beacon intervals contain a BTI. A non-PCP STA that is a non-AP STA shall not transmit during the BTI of the BSS of which it is a member. â€” A-BFT: An access period during which beamforming training is performed with the STA that transmitted a DMG Beacon frame during the preceding BTI (see 10.38.5. The presence of the A- BFT is optional and signaled in DMG Beacon frames. â€” ATI: A request-response based management access period between the AP or PCP and non-AP and non-PCP STAs (see 10.36.3). The presence of the ATI is optional and signaled in DMG Beacon frames. â€” CBAP: An access period during which frame exchanges between STAs that use the channel access rules described in 10.36.5. â€” SP: An access period during which frame exchanges between STAs use the channel access rules described in 10.36.6.2. 1500 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The BHI comprises the BTI, A-BFT and ATI. The DTI, in turn, comprises contention based access periods (CBAPs) and scheduled service periods (SPs). There is a single BHI and a single DTI per beacon interval. Figure 10-54 illustrates an example of access periods within a beacon interval comprising a BTI, an A-BFT, an ATI, and two CBAPs and SPs within the DTI. Any combination in the number and order of SPs and CBAPs can be present in the DTI. Beacon Interval BHI DTI BTI A-BFT ATI CBAP 1 SP 1 SP 2 CBAP 2 Time Figure 10-54â€”Example of access periods within a beacon interval The details of the access protocol within each of the access periods are described in the remaining subclauses of 10.36 and within 10.38. In the ATI, a non-AP and non-PCP STA shall be ready to receive a transmission from the AP or PCP at least RxAdvanceTime before the expected transmission of a request frame. The destination STA of an SP shall be ready to receive a transmission from the source STA of the SP at least RxAdvanceTime before the start of the SP. A STA that participates in a CBAP shall be ready to receive a transmission within the CBAP at least RxAdvanceTime before the start of the CBAP plus DIFS. In the A-BFT, the AP or PCP should be ready to receive a transmission from a non-AP and non-PCP STA at least RxAdvanceTime before the start of an SSW slot. In all of the preceding rules, RxAdvanceTime is defined as follows: C T DI RxAdvanceTime = Ceil ----------------- - + T P , T TR 6 10 where C is aDMGTSFAccuracy, in ppm TDI is the time elapsed since a synchronizing reference event, in Âµs. The synchronizing event is the reception of the Timestamp field from the AP or PCP TP is aAirPropagationTime, in Âµs TTR is aTSFResolution, in Âµs 10.36.3 ATI transmission rules The presence of an ATI in the current beacon interval is signaled by the ATI Present field set to 1 in the current DMG Beacon frame(9.3.4.2). The Next DMG ATI element (9.4.2.135) transmitted in the Announce frame or in the DMG Beacon frame indicates the earliest start time for the next ATI in a subsequent beacon interval and ATI duration. 1501 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications An example of an ATI is shown in Figure 10-55. ATI AP Request Request Request or Ack 1 2 N PCP: ... Response Response STA: Ack 2 N STA 1 STA 2 STA N Figure 10-55â€”Example of frame exchanges during the ATI During an ATI, request and response frames are exchanged between the AP or PCP and any subset of STAs. The AP or PCP initiates all frame exchanges that occur during the ATI. The ATI shall not start sooner than Max(guard time, MBIFS), where guard time is defined in 10.36.6.5, following the end of the previous A- BFT when an A-BFT is present in the beacon interval or following the end of the previous BTI when an A- BFT is not present but a BTI is present in the beacon interval. The ATI shall not start before TBTT if the ATI is the first period in the beacon interval (the ATI is never the first period in the beacon interval in an infrastructure BSS; see 11.1.2.1). Once the ATI starts, the AP or PCP may start transmission of a request frame immediately or it may delay the transmission of the request frame if the medium is determined by the CCA mechanism to be busy. During each ATI the AP or PCP shall schedule transmissions to a non-AP and non-PCP STA if the non-AP and non-PCP STA Heartbeat field in the STAâ€™s DMG Capabilities element within the Association Request frame of the last successful association attempt is 1. If the non-AP and non-PCP STA does not respond to the frame transmitted by the AP or PCP, the AP or PCP shall use the DMG Control modulation class (10.7.7.1) at its next transmission attempt to the non-AP and non-PCP STA. The AP or PCP shall use the DMG Control modulation class for all subsequent transmissions to the non-AP and non-PCP STA until it receives a valid frame from the non-AP and non-PCP STA. A non-AP and non-PCP STA shall not transmit during the ATI except in response to a received individually addressed frame whose TA field contains the APâ€™s or PCPâ€™s MAC address and whose RA field contains the STAâ€™s MAC address. During the ATI a STA shall not transmit frames that are not request or response frames. Request and response frames transmitted during the ATI shall be one of the following: â€” A Management frame â€” An Ack frame â€” A Grant, Poll, RTS or DMG CTS frame when transmitted as a request frame â€” An SPR or DMG CTS frame when transmitted as a response frame â€” A frame with the Type subfield equal to Data only as part of an authentication exchange to reach a RSNA security association 1502 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NOTEâ€”The Announce frame is designed to be used primarily during the ATI and can perform functions of a DMG Beacon frame. The transmission of Poll frames during the ATI follows the rules described in 10.36.7. The Response Offset field within a Poll frame transmitted during the ATI shall be set to 0. The transmission of Grant frame during the ATI follows the rules described in 10.36.7.3. Individually addressed request frames transmitted during the ATI shall not be sent using Action No Ack frames. During the ATI, after an AP or PCP transmits an individually addressed request frame (such as an Announce frame) to a non-AP and non-PCP STA, and the STA receives that frame, the STA shall transmit a response frame addressed to the AP or PCP. The transmission of the response frame shall commence one SIFS after the reception of the request frame. The AP or PCP shall interpret the receipt of the response frame as an acknowledgment of the request frame. Response frames transmitted by non-AP and non-PCP STAs during the ATI shall be individually addressed to the AP or PCP. NOTEâ€”STAs do not transmit a response frame to the AP or PCP when they receive a request frame from the AP or PCP with the RA equal to a group address (see 10.3.6). The Duration field of a request frame transmitted during the ATI shall be set to cover the remaining duration of the ATI at the end of the request frame transmission. The Duration field of a response frame transmitted during the ATI shall be set to the value of the Duration field within the previously received request frame minus SIFS and minus the duration of the response frame transmission. When a transmission by a STA is expected by an AP or PCP and a SIFS elapses without its receipt, the AP or PCP may either repeat its individually addressed transmission to that STA or, as early as one PIFS after the end of its previous transmission, transmit a frame to any other STA. NOTEâ€”If acknowledgment is required, the AP or PCP transmits an Ack frame to acknowledge the reception of a response frame during the ATI (see Figure 10-55). Multiple request and response frame exchanges between the AP or PCP and a STA might occur during a single ATI. 10.36.4 DTI transmission rules During the DTI, a STA may initiate a frame exchange (following the DMG channel access rules) if any of the following conditions are met: a) During a CBAP for which the STA is identified or included as source or destination (10.36.6.3, 10.36.7, and 10.36.8) b) During an SP for which the STA is identified as source or destination (10.36.6.2 and 10.36.7) and shall not initiate a frame exchange if none of these conditions are met. A STA initiating data transfer shall check that the transaction, including acknowledgments, completes before the end of the CBAP or SP in which it was initiated. When the entire DTI is allocated to CBAP (that is, the CBAP Only field is 1 in the DMG Parameters field), the ATI Present field within the DMG Beacon frame containing the DMG Parameters field shall be set to 0. A DMG STA shall be capable of processing Grant frames. A non-AP and non-PCP DMG STA shall be capable of processing Poll frames and the Extended Schedule element. An AP or PCP shall be capable of processing SPR frames transmitted by a non-AP and non-PCP STA and responding to an SPR frame with a Grant frame. 1503 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The DMG low-power SC mode (20.7) may be used only within SPs that have the LP SC Used subfield within the Extended Schedule element equal to 1 and shall not be used otherwise. A STA supports the DMG low-power SC mode if the Low-Power SC Mode Supported subfield within its DMG Capabilities element is 1. A STA that supports the DMG low-power SC mode shall not initiate a frame exchange using the DMG low-power SC mode unless the STAs identified in the RA field of all MPDUs contained within the PPDU support the DMG low-power SC mode. A STA can use the procedure described in 11.30.1 to discover the capabilities of another STA. A STA that receives a Grant frame and that has the Grant Ack Supported field equal to 1 in the STAâ€™s DMG Capabilities element shall respond with a Grant Ack frame SIFS interval after reception of the Grant frame. In the transmitted Grant Ack frame, the STA shall copy the Source AID, Destination AID, and Beamforming Training fields from the Grant frame that the Grant Ack frame is being sent in response to. A STA that receives a group addressed Grant frame shall not respond with Grant Ack frame. A STA that receives a Grant frame and that does not have the Grant Ack Supported field equal to 1 in the STAâ€™s DMG Capabilities element shall not respond with a Grant Ack frame. 10.36.5 Contention based access period (CBAP) transmission rules The definition of contention based transmission rules used within a CBAP is provided in 10.3 and in 10.22. This subclause specifies additional rules applicable to the CBAP. A STA shall not initiate a frame exchange within a CBAP unless at least one of the following conditions is met: â€” The value of the CBAP Only field is equal to 1 and the value of the CBAP Source field is equal to 0 within the DMG Parameters field of the DMG Beacon frame that allocates the CBAP â€” The STA is an AP or PCP and the value of the CBAP Only field is equal to 1 and the value of the CBAP Source field is equal to 1 within the DMG Parameters field of the DMG Beacon frame that allocates the CBAP â€” The value of the Source AID field of the CBAP is equal to the broadcast AID â€” The STAâ€™s AID is equal to the value of the Source AID field of the CBAP â€” The STAâ€™s AID is equal to the value of the Destination AID field of the CBAP If a STAâ€™s AID is equal to the value of the Source AID field of a CBAP allocation or if a STA performs in the role of AP or PCP and both the CBAP Only and CBAP Source fields are equal to 1 in the DMG Beacon frame that allocates a CBAP, the STA may initiate a frame transmission within the CBAP immediately after the medium is determined to be idle for one PIFS. A BF initiator (10.38) should not initiate an SLS phase within a CBAP if there is not enough time within the CBAP to complete the SLS phase. A STA shall not extend a transmission frame exchange sequence that started during a CBAP beyond the end of that CBAP. A STA that initiates a sequence shall check that the frame exchange sequence, including any control frame responses, completes before the end of the CBAP. Operation of the EDCAF is suspended at the end of a CBAP and is resumed at the beginning of the fol- lowing CBAP. When the EDCAF is being suspended, the values of the backoff and NAVs shall remain unchanged until the start of the following CBAP. A TXOP may be obtained by a DMG STA winning an instance of EDCA contention (see 10.22.2)). At the beginning of a TXOP with a TXOP responder that has the Heartbeat field in the TXOP responderâ€™s DMG Capabilities element equal to 1, the following rules apply: 1504 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” The TXOP holder shall transmit a frame to the TXOP responder using the DMG Control modulation class before it uses any other modulation class for transmission if the time elapsed since the last frame received from the TXOP responder is larger than or equal to the Heartbeat Elapsed Time value computed using the Heartbeat Elapsed Indication field within the TXOP responderâ€™s DMG Capabilities element. â€” The TXOP holder may transmit a frame using a modulation class other than the DMG Control modulation class at the start of the TXOP if the time elapsed since the last frame received from the TXOP responder is shorter than the Heartbeat Elapsed Time value computed using the Heartbeat Elapsed Indication field within the TXOP responderâ€™s DMG Capabilities element. The frame sent by the STA at the beginning of the TXOP may be an RTS frame or a DMG CTS-to-self frame. Within a CBAP a STA with multiple DMG antennas should use only one DMG antenna in its frame transmission, CCA and frame reception, except if it is the initiator or responder in an SLS (10.38). The algorithm to select a DMG antenna and switch the active DMG antenna is implementation dependent. Within CBAPs a STA that changed to a different DMG antenna in order to transmit should perform CCA on that DMG antenna until a frame is detected by which it can set its NAV, or until a period of time equal to the dot11DMGNavSync has transpired, whichever is earlier. 10.36.6 Channel access in scheduled DTI 10.36.6.1 General An AP or PCP schedules each allocation with a specified start time from the TSF and with a fixed duration. An allocation can be an SP, where ownership of channel time is granted to a single STA, or a CBAP, where STAs can compete for channel access. The start time of each allocation is based on the TSF of the AP or PCP. The AP or PCP may schedule SPs or CBAPs only during the DTI of a beacon interval, following the end of an allocated BTI, A-BFT, and ATI when any of these periods are present in the beacon interval. The schedule of the DTI of a beacon interval shall be communicated through the Extended Schedule element. The AP or PCP transmits the Extended Schedule element in either or both an Announce frame or a DMG Beacon frame. The Extended Schedule element shall contain the scheduling information of all allocations in the DTI. The same Allocation field shall not appear more than once in the Extended Schedule element transmitted in a beacon interval. The content of the Extended Schedule element communicated in a beacon interval shall not change if transmitted more than once in the beacon interval, except that if the STA transmitting the Extended Schedule element is a PCP with multiple DMG antennas then the value of the PCP Active field of CBAP allocations within the Extended Schedule element might change when this element is transmitted through different DMG antennas. The AP or PCP should schedule SPs for a STA such that the scheduled SPs do not overlap in time with the traffic scheduling constraints indicated by this STA in the Traffic Scheduling Constraint Set field of the associated DMG TSPEC element. When scheduling a nonpseudo-static allocation or changing the start time of an existing pseudo-static allocation that has a non-AP and non-PCP STA as a source DMG STA or as a destination DMG STA of the allocation, an AP or PCP shall set the start time of the allocation to no less than aMinAllocationDeliveryTime after the last Extended Schedule element containing this allocation is transmitted by the AP or PCP. NOTEâ€”This rule does not apply to the case when an AP or PCP schedules a new pseudo-static allocation. When receiving an Extended Schedule element containing a new pseudo-static allocation in which it is expected to participate, a non-AP and non-PCP STA ignores the allocation if the value of the TSF at the time 1505 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications the frame containing the Extended Schedule element is received is greater than the value of the TSF at the start of the pseudo-static allocation; this allocation is called an obsolete allocation. The value of the TSF at the start of the pseudo-static allocation is constructed using the value of the Allocation Start Time field within the Allocation field for the pseudo-static allocation. An SP or CBAP allocation within an Extended Schedule element may comprise one or more individual allocations. The start time of each individual allocation of an SP or CBAP is given by (Astart + (i â€“ 1) Ã— Aperiod) where Astart is the value of the Allocation Start field for the SP or CBAP Aperiod is the value of the Allocation Block Period field for the SP or CBAP i is an integer greater than 0 and less than or equal to the value of the Number of Blocks field for the SP or CBAP The end of the ith individual SP or CBAP allocation is computed by adding the start time of the ith individual allocation to the value of the Allocation Block Duration field for the corresponding SP or CBAP allocation. If the PCP Active subfield in the Allocation field for an allocation within an Extended Schedule element is 1, the PCP shall be in the receive state for the duration of that allocation, except when transmitting during that allocation. The AP shall set the PCP Active field to 1 for every allocation within an Extended Schedule element transmitted by the AP. 10.36.6.2 Service period (SP) allocation The AP or PCP shall set the AllocationType subfield to 0 in an Allocation field within an Extended Schedule element to indicate an SP allocation. An SP is assigned to the source DMG STA identified in the Source AID subfield in an Allocation field that is not an obsolete allocation within the Extended Schedule element. The source DMG STA shall initiate the frame exchange sequence that takes place during the SP at the start of the SP, except when the source DMG STA intends to establish a DMG protected period in which case the rules described in 10.36.6.6 shall be followed before the source DMG STA initiates the frame exchange in the SP. The SP allocation identifies the TC or TS for which the allocation is made; however, the type of traffic transmitted is not restricted to the specified TC or TS (11.4.1). Except when transmitting a frame as part of the SP recovery procedure (10.36.6.7) or transmitting a response to the source DMG STA or transmitting a PPDU as part of an RD response burst (10.28), the STA identified by the Destination AID field in the Extended Schedule element should be in the receive state for the duration of the SP in order to receive transmissions from the source DMG STA. If the Destination AID field of the scheduled SP is equal to the broadcast AID and if the Source AID field of the scheduled SP is not equal to the broadcast AID, then all STAs on the PBSS/infrastructure BSS should be in the receive state in order to receive transmissions from the source DMG STA for the duration of the SP. Subclause 10.36.7 describes the rules for when the scheduled SP has both the Source and Destination AID fields equal to the broadcast AID. Only a STA identified as the source DMG STA or destination DMG STA of an SP may transmit during the SP, except when the rules in 10.36.7, 10.36.8, or 10.36.9 are used. At the beginning of an SP (except when the source DMG STA intends to establish a DMG protected period, see 10.36.6.6 before the source DMG STA initiates the frame exchange in the SP, a source DMG STA shall 1506 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications transmit a frame to the destination DMG STA using the DMG Control modulation class before it uses any other modulation class for transmission if the Heartbeat field in the destination DMG STAâ€™s DMG Capabilities element is 1. The frame sent by the source STA may be an RTS frame or a DMG CTS-to-self frame. The frame sent by the source STA may be an SSW frame or a BRP packet if the source STA is performing beamforming (10.7.7.5). At the beginning of an SP, a destination DMG STA shall transmit a frame to the source DMG STA using the DMG Control modulation class before it uses any other modulation for transmission if the Heartbeat field in the source DMG STAâ€™s DMG Capabilities element is 1 and the frame sent by the destination DMG STA is the unsolicited DMG DTS as first frame in the SP of the STA performing DMG protected period (10.36.6.6). Any MAC entity coordinated by an MM-SME that belongs to an MMSL cluster identified by the Source AID and Destination AID that are equal to, respectively, the Source AID and Destination AID of the Allocation field that is not an obsolete allocation in the Extended Schedule element that allocates the SP may transmit during the SP, if the STA sent an MMS element to the peer STA and the BeamLink Cluster field within the MMS element is 1. The AP or PCP may create SPs in its beacon interval with the source and destination AID subfields within an Allocation field set to 255 to prevent transmissions during specific periods in the beacon interval. The AP or PCP shall set the Beamforming Training subfield to 1 in the Allocation field for an SP within an Extended Schedule element to indicate that the source DMG STA of this SP initiates beamforming training with the destination DMG STA at the start of that SP. The source DMG STA and destination DMG STA of the SP shall perform beamforming training as described in 10.38. If the PCP Active subfield is 0 in the Allocation field for an SP within an Extended Schedule element, neither the destination DMG STA of the SP nor the source DMG STA of the SP shall transmit to the PCP during the SP if none of the STAs are the PCP. In no case shall the source or destination DMG STA extend a transmission frame exchange sequence that started during an SP beyond the end of that SP. A STA that initiates a sequence shall check that the frame exchange sequence, including any control frame responses, completes before the end of the SP. When scheduling two adjacent SPs, the AP or PCP should allocate the SPs separated by at least aDMGPPMinListeningTime if one or more of the source or destination DMG STAs participate in both SPs. Except for frames used for beamforming as described in 10.38, the source of an SP may retransmit a frame PIFS after the end of the frame transmission in case a response frame is expected from the destination DMG STA and a SIFS elapses without receipt of the expected transmission. The source DMG STA can relinquish the remainder of an SP to the destination DMG STA by sending a Grant frame to the destination DMG STA (10.36.7.3). 10.36.6.3 Contention based access period (CBAP) allocation The AP or PCP shall set the AllocationType subfield to 1, the Source AID subfield to the broadcast AID or to the AID of the source of the CBAP, and the Destination AID subfield to the broadcast AID or to the AID of the destination of the CBAP in an Allocation field within an Extended Schedule element to indicate a CBAP allocation. All CBAPs are allocated by the AP or PCP, except when allocated by a non-AP and non-PCP STA with the transmission of a Grant frame following an SP truncation (10.36.8). Multiple CBAPs may be present in a beacon interval, with the location and duration of each determined by the AP or PCP and announced in the 1507 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Extended Schedule element. When only one CBAP is present and no other allocations exist for the DTI, then the AP or PCP shall announce the presence of the CBAP by setting the CBAP Only field to 1 in the DMG Parameters field of the DMG Beacon. If at least one non-CBAP allocation is present, or more than one CBAP is present, or no allocations are present within a DTI, then the AP or PCP shall set the CBAP Only field to 0 in the DMG Parameters field in the DMG Beacon frame transmitted during the BTI. The AP or PCP shall set the CBAP Only field to 0 in the DMG Parameters field within a transmitted DMG Beacon frame if the DMG Beacon frame contains at least one Extended Schedule element. When the entire DTI is allocated to CBAP through the CBAP Only field in the DMG Parameters field, then that CBAP is pseudo-static and exists for dot11MaxLostBeacons beacon intervals following the most recently transmitted DMG Beacon frame that contained the indication, except if the CBAP is canceled by the transmission by the AP or PCP of a DMG Beacon frame with the CBAP Only field of the DMG Parameters field equal to 0 or an Announce frame with an Extended Schedule element. A guard time (10.36.6.5) precedes a CBAP that is allocated through the CBAP Only field equal to 1. Channel access during a CBAP shall follow the rules described in 10.36.5. 10.36.6.4 Pseudo-static allocations An SP or CBAP allocation is pseudo-static if the Pseudo-static field in the Allocation control field for the SP or CBAP is 1, or when the Extended Schedule element is not used and the CBAP Only field within the DMG Parameters field of the DMG Beacon frame is 1 (10.36.5). A pseudo-static SP or CBAP recurs at the same relative offset to TBTT and with the same duration in up to dot11MaxLostBeacons beacon intervals following the last received Extended Schedule element containing the pseudo-static allocation or DMG Beacon frame with the CBAP Only field equal to 1. A STA might fail to receive up to (dot11MaxLostBeaconsâ€“1) Extended Schedule elements or DMG Beacon frame with the CBAP Only field equal to 1 in consecutive beacon intervals and still may access the channel during the pseudo-static SP or CBAP. The STA shall cease transmission during a pseudo-static allocation if it fails to receive an Extended Schedule element or DMG Beacon frame with the CBAP Only field equal to 1 for dot11MaxLostBeacons consecutive beacon intervals. The AP or PCP may change the offset relative to TBTT or the duration of a pseudo-static allocation by transmitting a modified Allocation field in an Extended Schedule element before dot11MaxLostBeacons beacon intervals from the last transmitted Extended Schedule element. The AP or PCP may delete a pseudo- static allocation by transmitting an Extended Schedule element that does not include an allocation field containing that allocationâ€™s TID, source AID, and destination AID before the completion of dot11MaxLostBeacons beacon intervals from the last transmitted Extended Schedule element. In either case, the AP or PCP should not schedule a new allocation that overlaps with the previous pseudo-static allocation for a minimum of dot11MaxLostBeacons beacon intervals unless both the new and previous allocation are for a CBAP or the new allocation identifies the same source DMG STA as the original pseudo-static allocation. If the destination DMG STA of a pseudo-static allocation receives an Extended Schedule element with an Allocation field that indicates a change in the schedule of the pseudo-static allocation, the STA should enter receive state during the new pseudo-static allocation and may enter receive state during the previous allocation to account for the time it can take the source DMG STA of the allocation to receive the updated schedule. 10.36.6.5 Guard time Guard time is the time between the end of one allocation and the start of the following allocation, provided these allocations are not under spatial sharing (11.32). For the purpose of guard time insertion, an allocation is defined as an SP, a CBAP, and a BTI or A-BFT or ATI that is immediately followed by a CBAP allocated 1508 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications through the CBAP Only field (10.36.6.3). Guard times are used to keep transmissions in adjacent allocations from colliding. Figure 10-56 shows an example of the insertion of the guard time such that the allocations are separated by at least the guard time, in case the STAs participating in the adjacent allocations drift toward each otherâ€™s allocation. Desirable allocation N+1 Desirable allocation N position position Late estimate of allocation N Early estimate of allocation position N+1 position Guard time Figure 10-56â€”The guard time The AP or PCP shall insert a sufficient guard time between adjacent allocations so that transmissions in adjacent allocations do not overlap in time. For each of the adjacent allocations, guard times are calculated based on the worst case drift and the maximum allowed number of lost DMG Beacons. The AP or PCP shall insert a guard time (Tguard) between adjacent allocations that is not shorter than Ai + 1 C Di + Ai + 1 + 1 C Di + 1 T guard = Ceil --------------------------------------------------------------------------------------------------------------- - + SIFS + T P T TR 6 10 where Ai is the value of MLB allocation i, and the value of Ai for each allocation depends on whether the allocation is pseudo-static. Ai is 0 for a nonpseudo-static allocation and is equal to dot11MaxLostBeacons if the allocation is pseudo-static C is aDMGTSFAccuracy, in ppm Di is the time elapsed since a synchronizing reference event, in Âµs. The synchronizing event is the reception of the Timestamp field from the AP or PCP. For a pseudo-static allocation, Di is equal to the beacon interval SIFS in aSIFSTime, in Âµs TP is aAirPropagationTime, in Âµs, which accounts for the propagation delay between the STAs participating in the adjacent allocations TTR is aTSFResolution, in Âµs 10.36.6.6 DMG protected period 10.36.6.6.1 Introduction Communicating STA pairs of neighboring PBSS/infrastructure BSS might be granted SPs that potentially create interference for neighbor PBSS/infrastructure BSS STA pairs. SPs within a PBSS/infrastructure BSS can also experience such interference when spatial diversity conditions change. The intent of DMG protected period is to minimize such interference by allowing any pair of STAs to protect their SP and thereby limit the transmission of frames during the DMG protected period to not more than one pair of potentially interfering pairs of communicating stations. 1509 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A DMG protected period can be created by the source DMG STA during an SP, and shall be created by the source DMG STA if at least one of the following conditions is met: â€” The source DMG STA is the AP or PCP of the BSS, the ECAPC Policy Enforced subfield within the DMG Parameters field of the last DMG Beacon frame transmitted by the source DMG STA is equal to 1, and the Protected Period Enforced field within the ECAPC Policy Detail field of the last ECAPC Policy element transmitted by the source DMG STA is equal to 1. â€” The source DMG STA is not the AP or PCP of the BSS, the ECAPC Policy Enforced subfield within the DMG Parameters field of the last DMG Beacon frame received by the source DMG STA from the AP or PCP of the BSS is equal to 1, and the Protected Period Enforced field within the ECAPC Policy Detail field of the last ECAPC Policy element received by the source DMG STA from the AP or PCP of the BSS is equal to 1. Both the source DMG STA and destination DMG STA of an SP are owners of the DMG protected period. During any DMG protected period, both stations can receive frames from the other participant. A DMG STA that creates a DMG protected period during an SP in which it is a source DMG STA or a destination DMG STA moves to and stays in listening mode during time interval that starts before the start of the SP and remains in the listening mode until it is allowed to use the SP. The actual duration of the time the STA stays in the listening mode is limited by the aDMGPPMinListeningTime parameter. The intent of the listening mode is that the STA listens to other STAs that may have an SP that overlaps with the SP where the STA is a source DMG STA or a destination DMG STA. The NAV mechanism is used to indicate the time occupancy and if the STA is in the listening mode, it updates its NAVs. If the NAVs are not equal to 0, the STA does not use the time of the SP in which it is a source DMG STA or a destination DMG STA. If none of the NAVs has a nonzero value at the start of the SP, the STA is allowed to leave the listening mode and use the SP. If at least one of the NAVs has a nonzero value at the start of the SP, the STA is allowed to leave the listening mode and to use the time remaining in the SP after all NAVs become or already have value zero. Listening mode is a mode of operation during which a DMG STA is in receiving state and meets at least one of the following conditions: a) Its receiving antenna are in the quasi-omni mode. b) Its receiving antenna are directed to the peer STA for which this DMG STA is either the destination or source DMG STA. A DMG protected period is established through an RTS/DMG CTS handshake. To create a DMG protected period, the source DMG STA of an SP sends an RTS, and the recipient STA responds with a DMG CTS. If the recipient STA responds with a DMG CTS, then a DMG protected period is established; otherwise, no DMG protected period has been established. In all cases of DMG protected period establishment, the same antenna configurations that are used by the STAs that establish the DMG protected period are used for the exchange of frames during the DMG protected period. 10.36.6.6.2 DMG protected period establishment and maintenance A DMG STA that attempts to create a DMG protected period during an SP shall transition to listening mode not less than aDMGPPMinListeningTime before the attempt and shall remain in listening mode for at least aDMGPPMinListeningTime before making the attempt. A STA shall not issue an RTS frame to establish a DMG protected period if any of its NAVs is not equal to 0. A DMG STA that transmits an RTS frame to establish a DMG protected period during an SP in which it is a source DMG STA shall not transmit the RTS frame outside of the SP and the value of the Duration field of 1510 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications the RTS frame shall not exceed the duration of the portion of the SP that remains following the RTS frame transmission. In order to maintain STAs that are not aware of the establishment of the DMG protected period because they have begun listening to the medium after the establishment of a DMG protected period, a STA that established a DMG protected period should transmit additional RTSs. An additional RTS frame should be sent at the end of every (aDMGPPMinListeningTime â€“ aRTSTimeoutTime) interval during the DMG protected period if the duration of the RTS/DMG CTS exchange is less than the time remaining in the SP. A DMG STA that transmitted an RTS frame that established a DMG protected period shall use the same antenna configuration as was used for the transmission of the RTS frame during transmission of Data frame(s) during the DMG protected period. A DMG STA should transition to listening mode not less than aDMGPPMinListeningTime before the start of an SP in which it is the destination DMG STA. During an SP in which it is the destination DMG STA, a DMG STA that receives a valid RTS frame with the RA equal to the recipient DMG STA MAC address and the TA corresponding to the source DMG STA of the SP shall respond with a DMG CTS frame if the recipient DMG STA has been in listening mode for aDMGPPMinListeningTime at the start of the reception of the RTS frame and none of its NAVs has a nonzero value. During an SP in which it is the destination DMG STA, a DMG STA that receives a valid RTS frame with the RA equal to the recipient DMG STA MAC address and the TA corresponding to the source DMG STA of the SP shall not respond with a DMG CTS frame if at the start of the reception of the RTS frame the recipient DMG STA has a nonzero value in at least one of its NAVs or the recipient DMG STA has not been in listening mode for at least aDMGPPMinListeningTime. During an SP in which it is the destination DMG STA, a DMG STA that receives a valid RTS frame with the RA equal to the recipient DMG STA MAC address and the TA corresponding to the source DMG STA of the SP may respond with a DMG DTS frame if at the start of the reception of the RTS frame the recipient DMG STA has a nonzero value in at least one of its NAVs. A DMG STA may transmit a DMG DTS frame after the expiration of the aRTSTimeoutTime time following the start of an SP in which it is the destination DMG STA, if any of its NAVs has a nonzero value at that time and no RTS has been received from the source DMG STA of the SP and the STA has been in listening mode for aDMGPPMinListeningTime immediately preceding the start of transmission of the DMG DTS frame. The destination DMG STA shall not transmit a DMG DTS frame if any portion of the DMG DTS frame would be transmitted outside of the SP. The value in the Duration field of a DMG DTS frame shall be calculated by subtracting the DMG DTS frame transmission time from the NAV in the destination DMG STA that has the largest value at the time of the start of the transmission of the DMG DTS frame. The NAV-DA and NAV-SA fields shall be set to the MAC addresses that identify the NAV in the destination DMG STA that was used to determine the Duration field value of the DMG DTS frame. During an SP in which it is the destination DMG STA, a DMG STA that receives a valid RTS frame with the RA equal to the recipient DMG STA MAC address and the TA corresponding to the source DMG STA of the SP may respond with a DMG DTS frame if at the start of the reception of the RTS frame the recipient DMG STA has not been in listening mode for at least aDMGPPMinListeningTime. The value of the Duration field of the DMG DTS frame sent by the recipient DMG STA shall include the difference of aDMGPPMinListeningTime and the elapsed time since the recipient DMG STA has been in listening mode, and the NAV-SA and the NAV-DA fields of the DMG DTS frame shall contain the recipient DMG STA MAC address. 1511 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A destination DMG STA that responds to an RTS frame with a DMG CTS or DMG DTS frame shall transmit the response frame a SIFS interval after the end of the received RTS frame. A destination DMG STA that transmits either a DMG CTS or a DMG DTS frame shall use the same antenna configuration for the subsequent transmission of Ack frames and Data frames within the SP as is used for the transmission of the DMG CTS or DMG DTS frame. The source DMG STA of an SP can send a CF-End frame to the destination DMG STA of the SP to truncate a DMG protected period. Regardless of whether this CF-End frame is sent, a CF-End frame is also sent to the AP or PCP (see 10.36.8). 10.36.6.6.3 NAV update in DMG protected period STAs in the listening mode shall update their NAVs according to the procedures described in 10.36.10. NOTEâ€”Support of multiple NAVs as defined in 10.36.10 is not limited to be used in the listening mode only and is also used in any case a NAV update is performed. When an SP terminates, either through time allocation expiration or truncation, then the source DMG STA of that SP may reset any NAV to 0 that has an associated variable NAV_DTSCANCELABLE with a value of true. 10.36.6.6.4 Interference report A STA that receives an RTS and/or DMG CTS frame that updates the NAV and that overlaps in time with an SP where the STA is destination or source, may report the overlap to the AP or PCP by sending a DMG ADDTS Request frame variant (9.6.3.3.2) and including in the DMG TSPEC element (9.4.2.134) the indication of interference in the Traffic Scheduling Constraint Set field (Figure 9-523). Transmission of the DMG ADDTS Request frame variant shall follow the rules defined in 11.4, with the following exceptions. The Allocation ID subfield of the DMG TSPEC element shall identify the allocation during which the interference was detected. One ADDTS Request frame is generated and transmitted for each allocation during which interference is detected. The Traffic Scheduling Constraint Set field of the DMG TSPEC element may contain one or more Constraint subfields. Each Constraint subfield provides information separately for each overlapping NAV event. The following NAV events should be reported: a) Nonzero NAV at start of SP b) Extension of NAV during the SP, including extension of an initial nonzero NAV and transitioning of the NAV from zero to nonzero value during the SP c) Truncation of the NAV during the SP The TSCONST Start Time field is set to the TSF value at which the NAV event is detected. For event a) above, the TSCONST Start Time field shall be set to the start of the SP. For event b) above, the TSCONST Start Time field shall be set to the time the NAV was updated or initialized to the value reported in the TSCONST Duration field. For event c) above, the TSCONST Start Time field shall be set to the time the NAV was reset. The TSCONST Duration field shall be set to the NAV value at the TSCONST Start Time, which is the value zero for event c). The TSCONST Period shall be set to 0 indicating that the field is not applicable. The Interferer MAC Address shall be set to the NAVDST of the NAV from which the TSCONST Start Time was derived (10.36.10). 1512 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications All values conveyed in the Traffic Scheduling Constraint Set field shall refer to the allocation identified by the value of the Allocation ID subfield of the TSPEC. The value of other fields within the DMG TSPEC element shall comply with the rules specified in 11.4. Use of the information conveyed in the Traffic Scheduling Constraint Set field is outside the scope of this standard. 10.36.6.7 Service period recovery When a non-AP and non-PCP STA fails to receive the Extended Schedule element for a beacon interval, the non-AP and non-PCP STA has no knowledge of the nonpseudo-static SPs allocated during the beacon interval that indicate it is the source DMG STA; therefore, it fails to transmit during those SPs. If the destination of the nonpseudo-static SP is an AP or PCP and it does not receive any frames from the source non-AP and non-PCP STA for the dot11SPIdleTimeout interval from the start of the SP, the AP or PCP may truncate the SP and use the mechanism described in 10.36.7 to reallocate the remaining duration of the SP to the source DMG STA of the SP or other STAs provided that it was a truncatable SP. If the SP is not a truncatable SP, the PCP may stay in awake state or may switch to doze state. If the non-AP and non-PCP STA failed to receive the Extended Schedule element from the AP or PCP for that beacon interval, it may switch to doze state or may direct its receive antenna toward the AP or PCP to receive a grant during nonpseudo-static SPs or CBAPs in the current beacon interval. An AP or PCP may reclaim the entire time allocated in an SP between two non-AP and non-PCP STAs if the following two conditions are met: â€” The SP is announced within an Extended Schedule element transmitted during the ATI. â€” The AP or PCP does not receive a response frame from at least one of the source and destination non-AP and non-PCP STAs of that SP as part of the ATI exchange (10.36.3). In either case described in this subclause, the AP or PCP may reallocate the reclaimed SP time as a CBAP, SP, or take no further action. Otherwise, if none of these conditions apply, no time may be reclaimed. 10.36.7 Dynamic allocation of service period 10.36.7.1 General Dynamic allocation of service period is employed to allocate channel time during scheduled SPs and CBAPs. The procedure includes an optional Polling Period (PP) phase and a Grant Period (GP) phase. Service periods allocated using this mechanism do not persist beyond a beacon interval. Persistent allocations are created using the allocation mechanisms described in 11.4. The PP Available field in the STA Availability element (9.4.2.133) indicates whether a STA participates in the PP phase of the dynamic allocation of service period mechanism. A STA that participates in PP phase of the dynamic allocation of service periods responds to Poll frames during the PP. A STA that participates in dynamic allocation of service periods uses the time allocated through Grant frames during the GP to transmit frames. A STA may set the PP Available field in a transmitted STA Availability element to 0 to indicate that the STA does not respond to Poll frames during the PP and the GP. NOTEâ€”A STA can receive a Grant frame in periods of the beacon interval other than the GP, in which case the STA uses the time allocated through the Grant frame. The AP or PCP shall not transmit Poll frames to a STA whose PP Available field in the STA Availability element is 0. The AP or PCP shall not dynamically allocate a service period to a STA that is in a doze BI (11.2.7). An AP or PCP may transmit Poll frames to a STA from which the AP or PCP has not received a STA Availability element with the PP Available field from the STA equal to 0. 1513 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications An AP or PCP may dynamically allocate Service Periods during a scheduled SP for which both the source and destination AID fields are set to the broadcast AID by setting the Truncatable subfield to 1 within the Allocation field corresponding to the scheduled SP. If a non-AP and non-PCP STA is neither source nor an individually addressed destination during a truncatable SP and the non-AP and non-PCP STA participates in dynamic allocation of service periods and the non-AP and non-PCP STA is in an awake BI, then the non-AP and non-PCP STA should be in the awake state for the duration of the truncatable SP. A non-AP and non-PCP STA that participates in dynamic allocation of service periods shall be in the awake state for dot11MinPPDuration from the start of each truncatable SP for which both the source and the destination AID fields are set to the broadcast AID and that occurs within each awake BI of that STA. Following the expiration of dot11MinPPDuration, the non-AP and non-PCP STA should remain in the awake state until the end of the truncatable SP. A STA shall be in the awake state for dot11MinPPDuration from the start of each scheduled CBAP that occurs within each awake BI of that STA. A STA that enters the doze state at any time during a CBAP and then returns to the awake state later during that same CBAP shall perform CCA until a frame is detected by which it can set its NAV, or until a period of time equal to the ProbeDelay has expired before it initiates a transmission. As described in 10.36.8, a STA that participates in dynamic allocation of service periods and that is neither source nor destination during a truncatable SP can be in the receive state with its receive antennas configured in a quasi-omni antenna pattern for the duration of the truncatable SP. A STA that receives a Grant frame with an SP allocation for which it is either source or destination shall not transmit longer than the time granted to it. Any STA coordinated by an MM-SME that belongs to an MMSL cluster identified by the Source AID and Destination AID that are equal to, respectively, the Source AID and Destination AID of the Dynamic Allocation Info field in the Grant frame may transmit during the allocation, if the STA sent an MMS element to the peer STA and the BeamLink Cluster field within the MMS element is 1. An example of dynamic allocation of service period is shown in Figure 10-57. Polling Period Grant Period Data Transfer in SP (PP) (GP) Time SBIFS SBIFS SIFS SIFS SIFS AP or ... ... Poll1 PollN SPR1 SPRN Grant1 Grant2 PCP: STA: Poll1 ... PollN SPR1 ... SPRN Grant1 Grant2 SBIFS Figure 10-57â€”Example of dynamic allocation of service period mechanism 1514 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.36.7.2 Polling period (PP) An AP or PCP that uses a PP to dynamically allocate an SP within the DTI shall commence the PP at a time instant indicated by at least one of the following: â€” Any time during a scheduled SP for which the source AID and destination AID are equal to the broadcast AID, excluding any time that has been allocated dynamically â€” Any time during a TXOP within a scheduled CBAP for which the destination AID is equal to the broadcast AID, excluding any time that has been allocated dynamically â€” Any time during the relinquished channel time following an SP truncation, excluding any time that has been allocated dynamically The AP or PCP shall not transmit a frame during a PP if any portion of that frame would extend beyond the end of the originally scheduled SP or CBAP. During the PP, the AP or PCP may transmit individually addressed Poll frames to STAs to solicit SPR frames from those STAs. The Duration field within each Poll frame i out of a total of n ( 0 i n ) transmitted Poll frames in the PP shall be calculated as defined by Equation (10-15). D i = D i n + O m + Ceil TXTIME(SPR m) T TR (10-15) where Di,n is the duration of the remaining poll transmissions, in Âµs, given by n Di n = Ceil( TXTIME(Poll k) + SBIFS + A k + S T TR) k = i+1 Om is the offset of SPR transmission m, in Âµs SPRm is SPR transmission m TTR is aTSFResolution, in Âµs The AP or PCP expects an SPR frame in response to each transmitted Poll frame (i.e., m=n). The position of each SPR frame in the sequence of SPR frames is indicated as j. Thus, j=1 refers to the first SPR frame transmission in the sequence of SPR frames, and j=m refers to the last SPR frame transmission in the sequence of SPR frames. Based on this, the Response Offset field within each Poll frame i transmitted in the PP shall be calculated as follows: Response Offseti = Di,n + Oj where Di,n is the duration of the remaining poll transmissions, defined in Equation (10-15). Pollk is Poll transmission k SBIFS is aSBIFSTime, in Âµs Ak is the antenna switching time, in Âµs, which is 0 if the AP or PCP uses the same antenna to transmit frame k and frame k+1 and is equal to dot11AntennaSwitchingTime otherwise S is aSBIFSAccuracy, in Âµs TTR is aTSFResolution, in Âµs 1515 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Oj is the offset of SPR transmission j, given by SIFS j = 1 Oj = O j â€“ 1 + Ceil(TXTIME(SPR j) + SIFS T TR) 2 j m SIFS is aSIFSTime, in Âµs, the time interval between the end of the last Poll frame transmitted by the AP or PCP and the expected start time of the first SPR frame by the non-AP and non- PCP STA SPRj is a SPR transmission j NOTEâ€”The calculation of Oj guarantees that no less than SIFS or SIFS+dot11AntennaSwitchingTime is provided for the AP or PCP to switch antennas when receiving an SPR from different STAs. A STA that receives an individually addressed Poll frame shall respond to the AP or PCP with a single directional and individually addressed SPR frame at the time offset from the end of the Poll frame indicated in the Response Offset field within the received Poll frame. The Duration field within the SPR frame shall be set to the value of the Duration field contained in the received Poll frame, minus the value of the Response Offset field contained in the received Poll frame, minus the time taken to transmit the SPR frame. The PP ends at a time equal to the end of the last Poll frame transmission plus the value of the Response Offset field in that Poll frame plus the expected duration of the SPR transmission that is expected in response to that Poll frame plus SIFS. 10.36.7.3 Grant period (GP) An AP or PCP that intends to dynamically allocate an SP within the DTI shall commence a GP at a time instant indicated by at least one of the following: â€” SIFS interval following the end of a PP if the PP is present â€” Any time during a scheduled SP for which the source AID and destination AID are equal to the broadcast AID if a PP does not precede the GP, excluding any time that has been allocated dynamically â€” Any time during a TXOP within a scheduled CBAP for which the destination AID is equal to the broadcast AID, excluding any time that has been allocated dynamically â€” Any time during the relinquished channel time following an SP truncation if a PP does not precede the GP, excluding any time that has been allocated dynamically The AP or PCP shall not transmit a frame during a GP if any portion of that frame would extend beyond the end of the originally scheduled SP or CBAP, or beyond the end of an immediately following SP if that SP has the broadcast AID as both source and destination AID, whichever is later. A non-AP and non-PCP STA may switch to doze state if it does not receive a Grant frame from the AP or PCP within dot11MinPPDuration from the start of the scheduled SP for which the source AID and destination AID are set to the broadcast AID. To commence the GP, the AP or PCP shall transmit Grant frames to notify the source DMG STA and destination DMG STA about a dynamically allocated service period. The AP or PCP should transmit the last Grant frame within a GP to the source of the dynamically allocated SP if the source of the dynamically allocated SP is not the AP or PCP. In each transmitted Grant frame, the AP or PCP shall set the Duration field within the Grant frame to a time that covers the duration of all remaining Grant frame and Grant Ack frame transmissions, if any, plus all appropriate IFSs (10.3.2.3). In addition, the source AID and destination AID fields shall be set to the source and destination, respectively, of the dynamically allocated SP, the AllocationType field set to indicate the channel access mechanism during the allocation, and the Allocation Duration field set to a value that if added to the value of the Duration field does not overlap in time with another SP that has either the source AID or destination AID different from the broadcast AID. An 1516 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications allocation that is indicated in this manner begins at the time that is equal to the PHY-TXEND.indication primitive of the Grant frame plus the value from the Duration field of the Grant frame. The Dynamic Allocation Info field within Grant frames transmitted as part of the same GP shall be the same. NOTEâ€”This means the AP or PCP can create only one allocation per GP. During an SP between a source DMG STA and a destination DMG STA, the source DMG STA may transmit a Grant frame to the destination DMG STA to relinquish the remainder of the SP to the destination DMG STA. In the Allocation Info field of the transmitted Grant frame, the source DMG STA shall set source AID field to the AID of the destination DMG STA, the destination AID field to the AID of the source DMG STA, the AllocationType field set to indicate SP, and the Allocation Duration field set to a value of 32 768 as defined in 9.5.2. The Duration field in the Grant frame shall be set to the time remaining in the SP minus TXTIME (Grant frame) minus aSIFSTime. Upon transmission of the Grant frame with the Beamforming Training field equal to 0, for the remainder of the SP the roles of source DMG STA and destination DMG STA are swapped between the STAs. During a TXOP between a TXOP holder and a TXOP responder, the TXOP holder may transmit a Grant frame to the TXOP responder to relinquish the remainder of the TXOP to the TXOP responder. In the transmitted Grant frame, the TXOP holder shall set source AID field to the AID of the TXOP responder, the destination AID field to the AID of the TXOP holder, the AllocationType field set to indicate CBAP, and the Allocation Duration field set to a value of 32 768 as defined in 9.5.2. The Duration field in the Grant frame shall be set to the time remaining in the TXOP minus TXTIME (Grant frame) minus aSIFSTime. Upon transmission of the Grant frame with the Beamforming Training field equal to 0, for the remainder the TXOP the roles of TXOP holder and TXOP responder are swapped between the STAs. A STA that receives a Grant frame shall not update its NAV if the value of either the source AID or destination AID fields in the Grant frame are equal to the STAâ€™s AID. The AP or PCP may grant a dynamic allocation of service period to a STA that does not transmit a SPR frame during the PP. 10.36.8 Dynamic truncation of service period A STA truncates an SP to release the remaining time in the SP. The STA can use the CF-End frame to truncate the SP at the peer STA, to reset NAV in third party STAs and to return to the AP or PCP the time left in the SP, thus allowing the AP or PCP to grant any portion of the released time as part of an SP to any other STA or to allocate any portion of it as a CBAP. The STA can use the Grant frame to release any part of the time left in the SP as a CBAP. A STA that is neither source nor destination during a truncatable SP may participate in dynamic allocation of service period by being in the receive state with its receive antenna configured in a quasi-omni antenna pattern for the duration of the truncatable SP. If both the source and destination AID fields of a truncatable SP are set to the broadcast AID, a non-AP and non-PCP STA may direct its receive antenna to its AP or PCP for the duration of the truncatable SP if the non-AP and non-PCP STA does not participate in a frame exchange and the truncatable SP is not dynamically allocated to the non-AP and non-PCP STA. Only the source DMG STA of an SP may truncate the SP, except that the destination DMG STA may truncate the SP if it does not receive an expected transmission from the source DMG STA at the start of the SP as defined in 10.36.6.7. In order to advertise the availability of truncatable SP time for reuse through AP or PCP dynamic allocation, a non-AP and non-PCP STA shall transmit an CF-End frame to the AP or PCP. A STA is not required to truncate an SP if a portion of the SP is unused. 1517 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications In order to enable CBAP access during the time released through SP truncation, the STA shall broadcast a Grant frame with the Source AID and Destination AID set to broadcast AID, the AllocationType field set to indicate CBAP and the Duration field set to the time needed to transmit the Grant frame(s) (the Duration field in a Grant frame does not include duration of that frame) plus SIFS and plus the time needed to transmit the following CF-End frame and the response CF-End frame, if required and appropriate IFS (10.3.2.3) values. The Allocation Duration field shall be set to a value that is not greater than the result of the subtraction of the value in the Duration field from the time remaining in the SP. The CBAP that is indicated in this manner begins at the time that is equal to the PHY-TXEND.indication primitive of the Grant frame plus the value from the Duration field of the Grant frame and continues for the time indicated in the Allocation Duration field of the Grant frame. The STA shall not transmit the Grant frame and shall not transmit the CF-End frame to the AP or PCP if the SP is not indicated as truncatable. After transmission of the CF-End frame to the AP or PCP or after broadcasting a Grant frame, the STA shall transmit a CF-End frame to the peer STA of the SP. The CF-End frame releases any time remaining in the SP at the recipient and resets the NAV in third party STAs. The NAV is reset only if the RA and TA of the CF-End frame match the addresses of the frame that established the NAV (see 10.36.10). The recipient STA may transmit a CF-End frame SIFS after the reception if the Duration field of the received frame is not equal to 0 and the transmission does not extend beyond the end of the originally scheduled SP. A STA shall not initiate SP truncation if there is not enough time left in the SP to complete the frame exchange required for truncation of the SP. After the truncation is completed, the AP or PCP may dynamically allocate any portion of the relinquished channel time that has not been allocated to a CBAP through a transmitted Grant frame (10.36.7). 10.36.9 Dynamic extension of service period A non-AP and non-PCP STA uses dynamic extension of SP to extend the allocated time in the current SP. The additional time can be used to support variable bit rate traffic, for retransmissions or for other purposes. The SPR frame is sent by a non-AP and non-PCP STA to the AP or PCP to request additional SP time in the current beacon interval. Except in response to a Poll frame from the AP or PCP, a non-AP and non-PCP STA shall not transmit an SPR frame within an SP if the current SP is not extendable (see 9.4.2.132). Only the source DMG STA and destination DMG STA of an SP can transmit an SPR frame during that SP. If the AP or PCP is not the source of an extendable SP, it should be in the receive state and with its receive antennas configured in a quasi-omni antenna pattern for the duration of the extendable SP. To request an extension of the current SP, a non-AP and non-PCP STA shall transmit an SPR frame to the AP or PCP. The non-AP and non-PCP STA shall not request extension of the current SP if there is not enough time left in the SP to complete the frame exchange required for the SP extension. In the transmitted SPR frame, the STA shall set the RA field to the address of the AP or PCP, the Duration field to the time left in the SP (not including the SPR transmission time), and the Allocation Duration field to the additional amount of time requested by the STA following the end of the current SP. The AP or PCP may grant the request for an extension of an SP only if the following SP has the broadcast AID as both source and destination AID, and the duration of the following SP is larger than the value of the Allocation Duration field in the received SPR frame. To grant an extension request, the AP or PCP shall transmit a Grant frame with the RA field set to the value of the TA in the received SPR frame, the Duration field set to the value of the Duration field received in the SPR frame minus SIFS and minus the duration of 1518 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications this Grant frame transmission, and the Allocation Duration field set to the amount of additional time granted by the AP or PCP. If a Grant Ack frame is transmitted following reception of the Grant frame, the frame shall be configured as specified in 10.36.4. To decline a request for an extension of an SP, the AP or PCP shall transmit a Grant frame with the RA field set to the value of the TA in the received SPR frame, the Duration field set to the value of the Duration field received in the SPR frame minus SIFS and minus the duration of this Grant frame transmission, and the Allocation Duration field set to 0. The extension request is successful if the non-AP and non-PCP STA receives from the AP or PCP a Grant frame with a nonzero value of the Allocation Duration field SIFS after the SPR. SIFS after the reception of a Grant frame from the AP or PCP with a nonzero value of the Allocation Duration field, the non-AP and non- PCP STA shall transmit a Grant frame to the partner STA of the SP with the Duration field set to the value of the Duration field of the Grant frame received from the AP or PCP minus the duration of this Grant frame transmission minus SIFS, and the Allocation Duration field set to the value of the Allocation Duration field of the Grant frame received from the AP or PCP. An AP or PCP may extend an SP for which it is the source DMG STA by transmitting a Grant frame to the destination DMG STA of the SP. The Grant frame indicates extension of the SP. The Duration field in the transmitted Grant frame shall be set to the remaining time in the SP. The Allocation Duration field of the Grant frame shall be set to the additional channel time allocated by the AP or PCP following the end of the SP. If a Grant Ack frame is transmitted following reception of the Grant frame the frame shall be configured as specified in 10.36.4. 10.36.10 Updating multiple NAVs If a DMG STA supports multiple NAVs, the number of available NAVs within the STA shall be not less than aMinNAVTimersNumber. Each NAV is identified by a pair of MAC addresses, NAVSRC and NAVDST, and has associated variables NAV_RTSCANCELABLE and NAV_DTSCANCELABLE. Each STA also maintains a variable UPDATE_OPTIONAL. When a STA is enabled for operation, all NAVs shall have NULL values for their NAVSRC and NAVDST identifiers, the value of NAV_RTSCANCELABLE shall be false, the value of NAV_DTSCANCELABLE shall be false, and each NAV shall have the value 0. NAV address pairs correspond to the NAV-SA and NAV-DA fields in DMG DTS frames and correspond to the RA and TA fields of all other received frames that are used to update the NAV. Receipt of any frame can cause an update to the NAV whose identifying address pair corresponds to the specified address fields of the received frame according to the rules in this subclause. STAs receiving any valid frame shall perform the following NAV update operation expressed using the following pseudocode: NAV_TIMER_UPDATE(received_frame): UPDATE_OPTIONAL false If (received_frame = DMG DTS) { UPDATE_OPTIONAL true } If (received_frame(RA) This STA MAC address || UPDATE_OPTIONAL = true) { If (received_frame = DMG DTS) { R_DST received_frame(NAV-DA) R_SRC received_frame(NAV-SA) } else if (received_frame = Ack) { 1519 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications R_DST received_frame(RA) R_SRC 0 } else { R_DST received_frame(RA) R_SRC received_frame(TA) } R_DUR received_frame(DUR) N_TIMER -1 // Searching for a matching NAV For (x 0; x < aMinNAVTimersNumber; x++) { If (received_frame = Ack || NAVSRC(x)=R_DST) { If(NAVDST(x) = R_DST) { N_TIMER x Break } } else if (NAVSRC(x) = R_SRC && (NAVDST(x) = R_DST || NAVDST(x) = 0) || (NAVSRC(x)=0 && NAVDST(x) = R_DST) || (NAVDST(x)=R_SRC && NAVSRC(x)=R_DST)) { N_TIMER x Break } } // No NAV has been found that matches the addresses If (N_TIMER < 0) { For (x 0; x < aMinNAVTimersNumber; x++) { If (NAVSRC(x) = NULL && NAVDST(x) = NULL || NAV(x) = 0) { NAVSRC(x) R_SRC NAVDST(x) R_DST N_TIMER x Break } } } // Existing NAV found If (N_TIMER 0) { If (UPDATE_OPTIONAL = false && R_DUR > NAV(N_TIMER) ) { NAV(N_TIMER) R_DUR If (received_frame = RTS) { NAV_RTSCANCELABLE(N_TIMER) true } else { NAV_RTSCANCELABLE(N_TIMER) false } 1520 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications } else if (UPDATE_OPTIONAL = true && R_DUR > NAV(N_TIMER)) { If ((implementation decision to update = true) || (received_frame(RA) = This STA MAC address && This STA MAC address = source DMG STA MAC address for current SP)) ){ NAV_DTSCANCELABLE(N_TIMER) true NAV(N_TIMER) R_DUR } } } } else { No change to NAV } END OF NAV_TIMER_UPDATE A STA that has updated a NAV as a result of the reception of an RTS may reset its NAV(s) as follows. After the NAV update for a duration of NAVTimeout period (10.3.2.4), the STA shall monitor the channel to determine if a PHY-RXSTART.indication primitive is received from the PHY. If such an event has not occurred during this time period, then the STA may reset to 0 any NAV whose NAV_RTSCANCELABLE value is true. After each NAV is updated, it counts down until it reaches 0 or is reset to 0. If a STA receives a valid CF-End frame response with RA and TA values that match the NAVSRC and NAVDST values, in any order, for any NAV, then the STA shall set the associated NAV to the value of the Duration field in the received CF-End frame. If one of NAVSRC or NAVDST of a NAV is 0 and the corresponding NAVDST or NAVSRC, respectively, of the NAV match the RA or the TA value of the received valid CF-End frame, then the STA shall set the associated NAV to the value of the Duration field in the received CF-End frame. If one of NAVSRC or NAVDST of a NAV is 0 and the nonzero NAVDST or NAVSRC of the NAV match either the RA or the TA value of a received valid frame, the NAVSRC or NAVDST that is 0 shall be set to the RA or TA that does not match the nonzero NAVSRC or NAVDST. 10.37 DMG AP or PCP clustering 10.37.1 General An AP or PCP may use the AP or PCP clustering mechanism to improve spatial sharing and interference mitigation with other co-channel DMG BSSs. There are two types of clustering: â€” Decentralized AP or PCP clustering that involves a single S-AP or S-PCP in the BSA of the S-AP or S-PCP â€” Centralized AP or PCP clustering where there can be multiple S-APs in the BSA of any one S-AP, and all S-APs are coordinated via a single centralized coordination service set AP or PCP clustering allows an AP or PCP that is a member of a cluster to schedule transmissions in nonoverlapping time periods with respect to other members of the same cluster since the AP or PCP can receive DMG Beacon and Announce frames containing the Extended Schedule element of other APs and 1521 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications PCPs that are members of the cluster and can also receive the Extended Schedule element from another BSS through associated non-AP and non-PCP STAs (10.37.4). A STA is decentralized AP or PCP clustering capable if it sets the Decentralized AP or PCP Clustering field to 1 within the DMG AP Or PCP Capability Information field in the DMG Capabilities element. A STA is centralized AP or PCP clustering capable if it sets the Centralized AP or PCP Clustering field to 1 within the DMG AP Or PCP Capability Information field in the DMG Capabilities element. The AP or PCP employs the Clustering Control field and ECAPC Policy Enforced field defined in 9.3.4.2 to configure the use of AP or PCP Clustering. A decentralized AP or PCP clustering capable or centralized AP or PCP clustering capable AP or PCP that transmits the Clustering Control field is decentralized clustering enabled or centralized clustering enabled, respectively. An AP or PCP cluster includes one S-AP or S-PCP and zero or more member APs and PCPs. Decentralized clustering enabled APs and PCPs operating on the same channel may form a decentralized AP or PCP cluster. The Cluster ID of the decentralized AP or PCP cluster shall be set to the MAC address of the S-AP or S-PCP. Centralized clustering enabled APs and PCPs operating on the same channel as a S-AP form a centralized AP or PCP cluster as described in 10.37.2.2. The Cluster ID of the centralized AP or PCP cluster shall be set to the MAC address of the S-AP. A clustering enabled AP or PCP that is not a member of any cluster shall set the Cluster Member Role subfield to 0 in transmitted frames that contain the Clustering Control field. Each AP or PCP that is a member of an AP or PCP cluster shall include the Clustering Control field in each DMG Beacon frame it transmits. For each cluster, there exists a set of ClusterMaxMem Beacon SPs. The nth Beacon SP, Beacon SPn, begins at ClusterTimeOffsetn-1 Âµs following the TBTT of the S-AP or S-PCP, where ClusterTimeOffsetn-1 = 1024 Ã— (dot11BeaconPeriod/ClusterMaxMem) Ã— (nâ€“1) and n=2, 3,â€¦, ClusterMaxMem The ClusterTimeOffsetn-1 and Beacon SPn where n equals one is reserved for the S-AP or S-PCP. An AP or PCP that is a member of an AP or PCP cluster shall transmit its DMG Beacon frame during one of the Beacon SPs as specified in 10.37.2. The maximum size of the Beacon SP Duration field transmitted by a S-AP or S-PCP shall be the beacon interval of the S-AP or S-PCP divided by ClusterMaxMem. 10.37.2 Cluster formation 10.37.2.1 Decentralized AP or PCP cluster formation A clustering enabled AP or PCP starts a decentralized AP or PCP cluster by becoming an S-AP or S-PCP, subject to the absence of existing clusters as described below and in 10.37.2.2. A decentralized clustering enabled AP or PCP becomes an S-AP or S-PCP of a decentralized AP or PCP cluster by transmitting a DMG Beacon frame at least once every aMinBTIPeriod beacon intervals that has the ECAPC Policy Enforced subfield in the DMG Parameters field set to 0 and that includes a Clustering Control field with the Beacon SP Duration subfield set to dot11BeaconSPDuration, the Cluster ID subfield set to the S-AP or S-PCP MAC address, and the Cluster Member Role subfield set to the value for an S-AP or S-PCP. The value of ClusterMaxMem subfield shall be chosen to keep the result of (beacon interval length/ClusterMaxMem) as an integer number of microseconds. 1522 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A decentralized clustering enabled AP or PCP that receives a DMG Beacon frame with the ECAPC Policy Enforced subfield in the DMG Parameters field set to 0 from an S-AP or S-PCP on the channel the AP or PCP selects to establish a BSS shall monitor the channel for DMG Beacon frame transmissions during each Beacon SP for an interval of length at least aMinChannelTime. A Beacon SP is empty if no DMG Beacon frame is received during the Beacon SP over an interval of length aMinChannelTime. The AP or PCP shall not become a member of the cluster if no Beacon SP is determined to be empty during aMinChannelTime, in which case, subject to the requirements described in 10.37.2.2, then the AP or PCP may become the S-AP or S-PCP of a new cluster, or may cease its activity on this channel and may attempt operation on a different channel. A decentralized clustering enabled AP or PCP that operates its BSS on a channel on which it discovered an S-AP or S-PCP within a decentralized AP or PCP cluster and at least one empty Beacon SP shall transmit its DMG Beacon frame during an empty Beacon SP. By transmitting its DMG Beacon frame during an empty Beacon SP and by setting the clustering control field appropriately as described in 9.3.4.2, the AP or PCP becomes a member AP or member PCP. The member AP or member PCP shall select a beacon interval length that is equal to the beacon interval length of its S-AP or S-PCP. The member AP or member PCP shall transmit its DMG Beacon frame with the ECAPC Policy Enforced field set to 0, the Beacon SP Duration subfield set to the value of the Beacon SP Duration subfield contained in the S-AP or S-PCP DMG Beacon, the Cluster ID subfield set to the MAC address of the S-AP or S-PCP, the Cluster Member Role subfield set to the member AP or member PCP value, and the ClusterMaxMem subfield set to the value of the ClusterMaxMem field contained in the S-AP or S-PCP DMG Beacon. An AP or PCP with a value of Cluster Member Role that is not zero shall schedule a Beacon SP that is allocated for DMG Beacon frame transmission of other cluster member APs and PCPs within the decentralized AP or PCP cluster at each of ClusterTimeOffsetn, at any time the AP or PCP transmits its own DMG Beacon. The minimum size of the Beacon SP should be equal to the value of the Beacon SP Duration subfield within the S-AP or S-PCP DMG Beacon. An S-AP or S-PCP and a member AP or member PCP of a decentralized AP or PCP cluster should not transmit or schedule transmissions during a Beacon SP that is not its own Beacon SP. Figure 10-58 illustrates, for three APs and PCPs, the Beacon SPs of the S-AP or S-PCP and member APs and PCPs of a decentralized AP or PCP cluster. ClusterTime Beacon Interval Offset (n=1) AP or PCP 1 BTI Rx Rx BTI ... (S-AP or S-PCP) ... ClusterTimeOffset (n=2) AP or PCP 2 Rx BTI Rx Rx ... ... ClusterTimeOffset (n=3) AP or PCP 3 Rx Rx BTI Rx ... ... Figure 10-58â€”Decentralized AP or PCP clustering for 3 APs and PCPs 1523 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.37.2.2 Centralized AP or PCP cluster formation In order to become an S-AP, a centralized clustering enabled STA that is stationary with respect to its local environment shall successfully perform both the following steps in order: â€” Configuration step â€” Verification step Once these steps have been performed successfully, the STA has become an S-AP. â€” Configuration step: The configuration step is defined to be successful if the following occur: â€” The STA obtains the MAC address of the CCSR; and â€” The STA obtains an ECAPC Policy Detail field, beacon interval, ClusterMaxMem, Beacon SP Duration, TXSS CBAP Offset, TXSS CBAP Duration, TXSS CBAP MaxMem, TSF synchronization parameters, Cluster Time Offset availability information, and a nonempty list of excluded channels for the intended operating class of the STA from the CCSR; and â€” Either channel 2 is an allowed channel in the current regulatory domain and the list of excluded channels includes channel 2, or channel 2 is not an allowed channel in the current regulatory domain; and â€” The beacon interval/ClusterMaxMem is an integer number of microseconds; and â€” At least one of beacon interval/TXSS CBAP MaxMem or TXSS CBAP MaxMem/beacon interval is an integer. Otherwise, the configuration step is defined to be unsuccessful. If the configuration step is unsuccessful, then the STA can attempt to resolve the problem or quit attempting to start a centralized AP or PCP cluster. The method by which the STA obtains the configuration information from the CCSR is not defined in this standard. â€” Verification step: The verification step is defined to be the following procedure: â€” The centralized clustering enabled STA monitors the channel for DMG Beacon frames over an interval of at least aMinChannelTime. â€” During this monitoring period, for each distinct Cluster ID received in a DMG Beacon frame that has the ECAPC Policy Enforced field set to 1 in the DMG Parameters field and Cluster Member Role set to 1 (S-AP or S-PCP of the cluster) or 2 (a member AP or member PCP of the cluster), the centralized clustering enabled STA determines if an S-AP with a MAC address equal to the Cluster ID belongs to the same CCSS as the centralized clustering enabled STA, via i) attempting to receive an Announce frame from the S-AP that transmitted the DMG Beacon frame according to the channel access rules described in 10.36 in order to solicit an ECAPC Policy element or ii) any other means. Any such DMG Beacon frame whose transmitter cannot be determined in this way to belong to the same CCSS as the centralized clustering enabled STA is defined to be from another ECAPC. The verification step is defined to be unsuccessful if, at the end of the monitoring period, there are one or more received DMG Beacon frames that are from another ECAPC. Otherwise, the verification step is defined to be successful. If a centralized clustering enabled STA receives at least one DMG Beacon frame that has the ECAPC Policy Enforced field set to 1 and from a member AP, S-AP, or member PCP of another ECAPC during the monitoring period and the STA is not an ECAPC policy blind AP or PCP, the STA â€” Shall cease its activity on this channel and may attempt operation on a different channel, or â€” If one of the received DMG Beacon frames was sent by an S-AP, may elect to unenroll from its current CCSS and join the cluster of the S-AP as a member AP or member PCP. If a centralized clustering enabled STA receives at least one DMG Beacon frame that has the ECAPC Policy Enforced field set to 1 from an S-AP from the same CCSS during the monitoring period and the STA is not 1524 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications an ECAPC policy blind AP or PCP, the STA may elect either to unenroll from its current CCSS and join the cluster of the S-AP as a member AP or member PCP or to continue and become an S-AP in the CCSS. In order to become an S-AP in a centralized AP or PCP cluster, a centralized clustering enabled STA shall take the following actions: â€” Set dot11ChannelUsageImplemented to true â€” Start a BSS as an AP â€” On a channel that is not listed as excluded by the CCSR, and â€” At the start time and with the beacon interval configured by the CCSR â€” Include in transmitted DMG Beacon frames â€” The ECAPC Policy Enforced field set to 1 in the DMG Parameters field, and â€” A Clustering Control field with the ClusterMaxMem subfield set to the values configured by the CCSR, the Beacon SP Duration subfield set to the value most recently configured by the CCSR, the Cluster ID subfield set to the S-AP MAC address, and the Cluster Member Role subfield set to 1 (S-AP or S-PCP of the cluster). An S-AP in a centralized AP or PCP cluster shall set the ECAPC Policy Enforced subfield in the DMG Parameters field to 1 for the lifetime of the BSS. An S-AP within a centralized AP or PCP cluster shall include the ECAPC Policy element in (Re)Association Response, Announce, and Information Response frames with the ECAPC Policy Detail, TXSS CBAP Offset, and TXSS CBAP Duration fields set to the respective values most recently configured by the CCSR for the S-AP, the TXSS CBAP MaxMem subfield set to the policy configured by the CCSR, the CCSR ID subfield set to the MAC address of the CCSR, and bits in the Available Cluster Time Offset Bitmap subfield set to 0 to indicate the Cluster Time Offsets that are determined to be already in use, excluding the recipient if sent within an individually addressed frame. The means by which a Cluster Time Offset is determined to be in use are unspecified. Bits in the Available Cluster Time Offset Bitmap subfield for other Cluster Time Offsets shall be set to 1. An AP or PCP that â€” receives a DMG Beacon frame that has the ECAPC Policy Enforced subfield in the DMG Parameters field set to 1 from an S-AP on a channel and â€” does not receive at least one DMG Beacon frame that has the ECAPC Policy Enforced subfield in the DMG Parameters field set to 1 from S-AP on every channel supported by the AP or PCP in the Operating Class within the next aMinChannelTime and â€” is not an ECAPC policy blind AP or PCP shall either join the cluster of the S-AP as a member AP or member PCP if centralized clustering enabled or cease its activity on this channel and may attempt operation on a different channel. S-APs within a CCSS report the channels unused by the ECAPC via the Channel Usage procedures (see 11.24.15). An AP or PCP within a decentralized AP or PCP cluster that â€” receives a DMG Beacon frame that has the ECAPC Policy Enforced subfield in the DMG Parameters field set to 1 from an S-AP and â€” does not receive at least one DMG Beacon frame that has the ECAPC Policy Enforced subfield in the DMG Parameters field set to 1 from an S-AP on every channel supported by the AP or PCP in the Operating Class within the next aMinChannelTime (i.e., does not become a ECAPC policy blind AP or PCO) and â€” is not already an ECAPC policy blind AP or PCP 1525 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications shall quit the decentralized AP or PCP cluster before the next TBTT + beacon interval length, then the AP or PCP shall either join the cluster of the S-AP as a member AP or member PCP if centralized AP or PCP clustering enabled or cease its activity on this channel and may attempt operation on a different channel. An AP or PCP that receives at least one DMG Beacon frame that has the ECAPC Policy Enforced subfield in the DMG Parameters field set to 1 sent by an S-AP on every channel supported by the AP or PCP in the Operating Class within the most recent aMinChannelTime ignores the ECAPC Policy Enforced subfield (i.e., treats this subfield as though equal to 0) in DMG Beacon frames received from S-APs for 300Ã—aMinChannelTime. During this period, the AP or PCP is called an ECAPC policy blind AP or PCP. NOTEâ€”An AP or PCP within a decentralized AP or PCP cluster does not cease DMG Beacon frame transmission when quitting a decentralized AP or PCP cluster. Hence, data communication is unaffected while performing these procedures. A centralized clustering enabled AP or PCP that attempts to join the centralized AP or PCP cluster of an S- AP as a member AP or member PCP shall be a STA coordinated by an MM-SME that also coordinates a second non-AP and non-PCP STA, and shall successfully perform the following steps in order: â€” The AP or PCP shall monitor the channel for DMG Beacon frames during each Beacon SP over an interval of length at least aMinChannelTime. A Beacon SPn is empty if no DMG Beacon frame is received during the Beacon SPn over an interval of length aMinChannelTime. â€” The second non-AP and non-PCP STA shall attempt to associate with the S-AP and thereby receive an Announce frame from the S-AP. The contents of the Announce frame are passed to the AP or PCP. â€” Upon receiving an Announce frame that includes the ECAPC Policy element, the AP or PCP shall select a Cluster Time Offset index from the intersection of a) the Cluster Time Offset indices of the empty Beacon SPs with b) the indices indicated by the Available Cluster Offset Bitmap field in the ECAPC Policy element. If the intersection is empty, the AP or PCP shall select a Cluster Time Offset index of an empty Beacon SP. The selected Cluster Time Offset index is passed to the second non-AP and non-PCP STA. â€” The second non-AP and non-PCP STA shall respond to the Announce frame with an Information Response frame that includes the Cluster Time Offset element containing the Cluster Time Offset Index set to the selected index. â€” The AP or PCP shall operate its BSS at the selected Cluster Time Offset on the channel of the S-AP and include the AP or PCP clustering control field in transmitted DMG Beacon frames. The AP or PCP shall not become a member of the centralized AP or PCP cluster if no Beacon SP is determined to be empty during aMinChannelTime or if the second non-AP and non-PCP STA did not associate to the S-AP, in which case the AP or PCP may attempt to join the cluster of another S-AP or cease its activity on this channel and may attempt operation on a different channel. A member AP or member PCP within a centralized AP or PCP cluster shall select a beacon interval that is equal to the beacon interval of the S-AP of the cluster. The member AP or member PCP within a centralized AP or PCP cluster shall transmit its DMG Beacon frames with the ECAPC Policy Enforced subfield in the DMG Parameters field set to 1, the Beacon SP Duration subfield in the Clustering Control field set to the value of the Beacon SP Duration subfield contained in the most recently received S-AP DMG Beacon, the Cluster ID subfield set to the MAC address of the S-AP, the Cluster Member Role subfield set to 2 (a member AP or member PCP of the cluster), and the ClusterMaxMem subfields set to the value of the ClusterMaxMem field contained in the S-AP DMG Beacon. A member AP or member PCP within a centralized AP or PCP cluster shall include the ECAPC Policy element in (Re)Association Response, Announce, and Information Response frames with the ECAPC Policy Detail, TXSS CBAP Offset, and TXSS CBAP Duration fields set to the most recently received respective 1526 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications field from the S-AP of the cluster, the TXSS CBAP MaxMem field set to the value of the TXSS CBAP MaxMem field received from the S-AP of the cluster, with the CCSR ID set to the MAC address of the CCSR field received from the S-AP of the cluster, and with the Available Cluster Time Offset Bitmap field reserved. At any time an AP or PCP within a centralized AP or PCP cluster transmits a DMG Beacon frame, the AP or PCP shall schedule a Beacon SP that reserves time for BHI transmission by other APs and PCPs within the centralized AP or PCP cluster at each in use ClusterTimeOffsetn-1 as indicated by the most recently transmitted (if S-AP) or received (if member AP or member PCP) Available Cluster Time Offset Bitmap. The minimum size of the Beacon SP shall be equal to the value of the Beacon SP Duration subfield within the DMG Beacon frame of the S-AP of the centralized AP or PCP cluster. A member AP, S-AP, or member PCP of a centralized AP or PCP cluster shall not transmit or schedule transmissions during a Beacon SP of another member AP, S-AP, or member PCP. 10.37.3 Cluster maintenance 10.37.3.1 General cluster maintenance The TBTT of the S-AP or S-PCP provides a timing reference for the Beacon SPs of the member APs and PCPs. Timing synchronization among the member APs and PCPs facilitates equitable sharing of the common medium among the member APs and PCPs. As long as a member AP or member PCP periodically receives DMG Beacons from the S-AP or S-PCP, the member AP or member PCP is able to maintain synchronization with the S-AP or S-PCP and hence the other member APs and PCPs. 10.37.3.2 Decentralized AP or PCP cluster maintenance In the case when the S-AP or S-PCP of a decentralized AP or PCP cluster is lost, or appears to a member AP or member PCP to have been lost, another AP or PCP needs to become the S-AP or S-PCP of the decentralized AP or PCP cluster in order to allow the remaining member APs and PCPs to maintain synchronization with the cluster. The creation of a new S-AP or S-PCP is called S-AP or S-PCP handover. After an S-AP or S-PCP handover, the cluster might continue to function as before, except with altered membership, or the cluster might no longer exist, or there might be one or more new clusters. A member AP or member PCP of the decentralized AP or PCP cluster shall start an S-AP or S-PCP handover if, within a time period of 4Ã—aMinBTIPeriod beacon intervals, it does not receive a DMG Beacon frame with the ECAPC Policy Enforced field set to 0, with the value of the Cluster ID field equal to the Cluster ID of the cluster of which the AP or PCP is a member and with the Cluster Member Role field set to the S-AP or S-PCP value. This is the first cluster monitoring period. During the next step in the S-AP or S- PCP handover, the member AP or member PCP performs another cluster monitoring period. A cluster monitoring period is a time period of 4Ã—aMinBTIPeriod beacon intervals during which the AP or PCP listens for DMG Beacons while continuing to transmit DMG Beacons using its current Beacon SPn. NOTEâ€”A decentralized clustering enabled AP or PCP does not cease DMG Beacon frame transmission during Cluster Monitoring and S-AP or S-PCP handover. Hence, data communication is unaffected while performing these procedures. If, during a cluster monitoring period, the member AP or member PCP receives a DMG Beacon frame with the value of Cluster Member Role set to the S-AP or S-PCP value, the member AP or member PCP shall follow the rules in 10.37.2 to become a member AP or member PCP of the cluster corresponding to the detected S-AP or S-PCP or cease operation on the channel; in either case, the cluster monitoring period is terminated. If, during a cluster monitoring period, the AP or PCP receives no DMG Beacons with the value of Cluster Member Role set to the S-AP or S-PCP value and one or more DMG Beacons with the ECAPC Policy Enforced field set to 0 and with Cluster ID equal to the Cluster ID of its last S-AP or S-PCP, then at the end of the cluster monitoring period the AP or PCP compares the MAC addresses of all such received DMG 1527 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Beacons with its own MAC address. If its MAC address is the lowest, the AP or PCP shall become an S-AP or S-PCP according to the rules in 10.37.2. If its MAC address is not the lowest, the AP or PCP shall perform a new cluster monitoring period. If the number of cluster monitoring periods performed by the AP or PCP exceeds dot11MaxNumberOfClusteringMonitoringPeriods, the AP or PCP may cease cluster maintenance and initiate cluster formation as described in 10.37.2. If, during a cluster monitoring period, the AP or PCP does not receive a DMG Beacon frame that contains the value of S-AP or S-PCP in the Cluster Member Role field and does not receive a DMG Beacon frame with the ECAPC Policy Enforced field set to 0 and with Cluster ID equal to the Cluster ID of the cluster of which it is currently a member, then at the end of the cluster monitoring period the AP or PCP may become an S-AP or S-PCP according to the rules of 10.37.2, or it may cease its activity on this channel and may attempt operation on a different channel. NOTEâ€”An assumption to allow the establishment of an S-AP or S-PCP in this case is that the APs and PCPs cannot hear each otherâ€™s DMG Beacons. How a STA decides to switch the channel or to establish an S-AP or S-PCP is implementation dependent. If, during a cluster monitoring period, the member AP or member PCP of a decentralized AP or PCP cluster receives no DMG Beacons from clustering enabled STAs, then the AP or PCP shall establish itself as an S- AP or S-PCP according to the rules in 10.37.2. If an S-AP or S-PCP of a decentralized AP or PCP cluster detects the presence of a S-AP or S-PCP of another decentralized AP or PCP cluster on the same channel, it should schedule a Beacon SP for the DMG Beacon frame transmission of the other S-AP or S-PCP if the MAC address of the other S-AP or S-PCP is lower than the MAC address of this S-AP or S-PCP. The S-AP or S-PCP with higher MAC address should become a member AP or member PCP of the cluster corresponding to the S-AP or S-PCP with the lower MAC address according to the rules in 10.37.2. 10.37.3.3 Centralized AP or PCP cluster maintenance A STA, while operating as an S-AP, remains stationary with respect to its local environment. An S-AP within a centralized AP or PCP cluster, upon a change of the Beacon SP Duration field or the ECAPC Policy element configured by the CCSR, shall update the Clustering Control field sent in subsequent frames and shall send individually addressed Announce or Information Response frames to other STAs within the BSS in order notify them of the changes. When a member AP or member PCP is coordinated by an MM-SME and the member AP or member PCP elects to change its S-AP within a centralized AP or PCP cluster, then a second non-AP and non-PCP STA coordinated by the MM-SME of the member AP or member PCP should disassociate from the previous S- AP, and the member AP or member PCP shall perform the steps described in 10.37.2.2 that allow a clustering enabled AP or PCP to join the centralized AP or PCP cluster of an S-AP as a member AP or member PCP. When a member AP or member PCP is coordinated by an MM-SME and the member AP or member PCP elects to change its Cluster Time Offset within a centralized AP or PCP cluster, then the member AP or member PCP shall pass the updated Cluster Time Offset to a second non-AP and non-PCP STA coordinated by the MM-SME of the member AP or member PCP, and the second non-AP and non-PCP STA shall send an Information Response frame that includes a Cluster Time Offset element containing the Cluster Time Offset Index set to the updated index to the S-AP of the centralized AP or PCP cluster. A member AP or member PCP within a centralized AP or PCP cluster, upon a change of the Clustering Control field received from its S-AP, shall update the Clustering Control field sent in subsequent frames. Upon a change of the ECAPC Policy Detail field received from its S-AP, a member AP or member PCP within a centralized AP or PCP cluster shall update the ECAPC Policy element sent in subsequent frames 1528 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications and send individually addressed Announce or Information Response frames to other STAs within the BSS in order notify them of the changes. The member AP or member PCP within the centralized AP or PCP cluster shall attempt to receive a DMG Beacon frame from its S-AP at least once every dot11DMGEcssPolicyDetailUpdateDurationMax TUs. In the case when a member AP or member PCP of a cluster has not received DMG Beacon frames from its S-AP for a duration exceeding 4Ã—aMinBTIPeriod beacon intervals, and the member AP or member PCP intends to continue to operate a BSS on the channel, the AP or PCP shall either a) Stop the current BSS then become an S-AP within the CCSS as described in 10.37.2.2; or b) Monitor the channel for DMG Beacon frames for an interval of length at least aMinChannelTime. During this period 1) if one or more DMG Beacon frames are received with the ECAPC Policy Enforced field set to 1 in the DMG Parameters field and the Cluster Member Role set to 1 (S-AP or S-PCP of clus- ter) from one or more S-APs and the AP or PCP is not an ECAPC policy blind AP or PCP, then the AP or PCP shall join a selected S-AP as a cluster member as described in 10.37.2.2; 2) otherwise, if the AP or PCP is an ECAPC policy blind PCP or AP, then it may join a selected S- AP as a cluster member; 3) otherwise, if, after the period elapses, no DMG Beacon frames are received with the ECAPC Policy Enforced field in the DMG Parameters field set to 1 and the Cluster Member Role set to 1 (S-AP or S-PCP of cluster) and if the AP or PCP is decentralized AP or PCP clustering capable, then the AP or PCP shall attempt to join a decentralized AP or PCP cluster if present as described in 10.37.2.1. If the AP or PCP is not decentralized AP or PCP clustering capable or a decentralized AP or PCP cluster is not present, then the AP or PCP shall set its Cluster Member Role to 0 (not currently participating in a cluster). c) In all three cases, the AP or PCP 1) Shall set the ECAPC Policy Enforced bit to 0 and shall not include the ECAPC Policy element in (Re)Association Response, Announce, or Information Response frames and 2) Should send individually addressed Announce or Information Response frames to other STAs within the BSS to notify them of the changes. 10.37.3.4 Centralized AP or PCP cluster MAC requirements If the most recent ECAPC Policy element transmitted by a member AP, S-AP, or member PCP includes the BHI Enforced field set to 1, the member AP, S-AP, or member PCP shall complete the BTI, A-BFT, and ATI for each subsequent beacon interval before TBTT + (8Ã—Beacon SP duration). The most recently transmitted (if an S-AP) or received (if a member AP, member PCP, or non-AP and non-PCP STA) value of Beacon SP Duration is used. If the most recent ECAPC Policy element transmitted by a member AP, S-AP, or member PCP has the TXSS CBAP Enforced field set to 1, the member AP, S-AP, or member PCP shall complete each of its TXSSs in the DTI within one or more TXSS CBAPs. If the most recent ECAPC Policy element, received by a non-AP and non-PCP STA in a BSS from the member AP, S-AP, or member PCP of the BSS, has the TXSS CBAP Enforced field set to 1, then the non- AP and non-PCP STA shall perform each of its TXSSs in the DTI within one or more TXSS CBAPs. If the non-AP and non-PCP STA is the source DMG STA of an SP and if the non-AP and non-PCP determines that it needs to perform a TXSS before continuing to transmit to the destination DMG STA of the SP, then the non-AP and non-PCP STA should truncate the SP (see 10.36.8). A TXSS CBAP shall last from TStart to TEnd, as defined below, excluding any time that overlaps a BHI or an SP that has source and destination DMG AIDs set to 255 (such as for a Beacon SP). 1529 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications n â€“ 1 1024 T BI T Start = T TBTT + 8 T o + ------------------------------------------------ - 1 n N N n â€“ 1 1024 T BI T End = T TBTT + 8 T o + ------------------------------------------------ -+8 Td 1 n N N where TTBTT is the TBTT To is the TXSS CBAP Offset, in microseconds Td is the TXSS CBAP Duration, in microseconds TBI is the beacon interval, in TU N is TXSS CBAP MaxMem The most recently transmitted (if an S-AP) or received (if a member AP, member PCP, or non-AP and non- PCP STA) value of TXSS CBAP Offset and TXSS CBAP Duration fields are used. The TXSS CBAP is available to all STAs in an ECAPC. A STA may also use the TXSS CBAP for sending frames not related to transmit sector sweeping. Transmission rules during a TXSS CBAP are defined in 10.36.5. NOTEâ€”Frames, such as Data frames, sent in a TXSS CBAP when the TXSS CBAP Enforced field is set to 1 might experience erratically higher interference than frames sent at other times due to the TXSSs of other nearby STAs. Additional centralized AP or PCP cluster requirements are defined in 10.36.6.6 and 11.1.3.3. 10.37.4 Cluster report and re-scheduling A clustering enabled AP or PCP that receives an Extended Schedule element from another clustering enabled AP or PCP may re-schedule SPs and CBAPs in its beacon interval, or move the BTI (11.1.3.3), in an attempt to mitigate any interference with the transmissions indicated in the received Extended Schedule element. The AP or PCP can create SPs in its beacon interval with the source and destination AID set to 255 to prevent transmissions during specific periods in the beacon interval (10.36.6.2). A non-AP and non-PCP STA that is a member of a BSS and that receives a DMG Beacon frame should send a Cluster Report element to its AP or PCP if the received DMG Beacon frame meets all of the following conditions: â€” The DMG Beacon frame is not from the STAâ€™s AP or PCP. â€” The DMG Beacon frame contains the Clustering Control field. â€” Either â€” The value of the Cluster ID field within the Clustering Control field is different from the MAC address of the STAâ€™s AP or PCP; or â€” The value of the Cluster ID field within the Clustering Control field is the same as the MAC address of the STAâ€™s AP or PCP, the TBTTs of the two BSSs are less than dot11BeaconPeriod/ (2Ã—ClusterMemMax) apart in time, and the ECAPC Policy Enforced field in the DMG Beacon frame received most recently from the STAâ€™s AP or PCP is equal to 1. The non-AP and non-PCP STA shall not send a Cluster Report element to its AP or PCP if the received DMG Beacon frame does not meet the preceding conditions. A Cluster Report element meeting the conditions above shall be transmitted in an Announce or Information Response frame sent to the STAâ€™s AP or PCP. Within the transmitted Cluster Report element, the STA shall 1530 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications set the Cluster report subfield to 1. The STA shall set the Clustering Control field within a transmitted Cluster Report element to the corresponding field values within the Clustering Control of the received DMG Beacon, shall set the Reported BSSID field to the BSSID of the received DMG Beacon, and shall set the Reference timestamp field to indicate the DMG Beacon frame reception time. The STA shall set the Schedule present subfield to 1 if the Extended Schedule field is present in the transmitted Cluster Report element; otherwise, it shall set Schedule present subfield to 0. The STA shall set the TSCONST present subfield to 1 if the Traffic Scheduling Constraint Set field is present in the transmitted Cluster Report element; otherwise, it shall set TSCONST present subfield to 0. The STA shall set the ECAPC Policy Enforced field in the Cluster Report Control field to the value of the ECAPC Policy Enforced field in the received DMG Beacon. The STA should attempt to receive an Announce frame from the AP or PCP that transmitted the DMG Beacon frame according to the channel access rules described in 10.36 in order to solicit an ECAPC Policy element. If the STA obtains an ECAPC Policy element from the AP or PCP that transmitted the DMG Beacon, the STA shall set the ECAPC Policy Present subfield to 1 and include the ECAPC Policy element in the transmitted Cluster Report element; otherwise, the STA shall set ECAPC Policy Present subfield to 0 and not include the ECAPC Policy element in the transmitted Cluster Report element. If present, the Extended Schedule Element field within the Cluster Report element shall be set to the corresponding field values within the Extended Schedule element of the received DMG Beacon. If present, the Traffic Scheduling Constraint Set field shall be set to indicate periods of time with respect to the TBTT of the beacon interval of the BSS the STA participates where the transmitting STA experiences poor channel conditions, such as due to interference. If the received DMG Beacon frame contains more than one Extended Schedule element entry, the STA shall repeat the aforementioned procedure and transmit a Cluster Report element corresponding to each Extended Schedule element entry. Upon receiving a Cluster Report element from a non-AP and non-PCP STA with the Cluster report field set to 1, a clustering enabled AP or PCP may re-schedule SPs and CBAPs in its beacon interval, move the BTI if the clustering enabled AP or PCP is an S-AP or S-PCP in a decentralized AP or PCP cluster, or change the Cluster Time Offset if the clustering enabled AP or PCP is a member AP or member PCP, or perform other actions, in an attempt to mitigate any interference with the transmissions indicated in the received Cluster Report element. The clustering enabled AP or PCP may also create SPs in its beacon interval with the source and destination AID set to 255 to prevent transmissions during specific periods in the beacon interval. A member AP or member PCP within a centralized AP or PCP cluster should report new interference information and may report all interference information to the S-AP of the cluster â€” When the member AP or member PCP receives one or more of the following: â€” A DMG Beacon frame from another AP or PCP in another centralized AP or PCP cluster within the same CCSS or another CCSS â€” A Cluster Report element with the Cluster Report field set to 1 from a non-AP and non-PCP STA within the same BSS characterizing an AP or PCP in another centralized AP or PCP cluster within the same CCSS or another CCSS; and â€” If at least dot11DMGEcssClusterReportDurationMin TUs have elapsed since the last report. The report should aggregate the information received from all sources and minimize duplication. The member AP or member PCP passes the report to a second non-AP and non-PCP STA coordinated by the MM-SME of the member AP or member PCP, and the second non-AP and non-PCP STA sends the report in an Information Response frame that includes one or more Cluster Report elements to the S-AP of its centralized AP or PCP cluster. If the member AP or member PCP does not elect to change its Cluster Time Offset at this time, the second non-AP and non-PCP STA includes a Cluster Time Offset element with an unchanged Cluster Time Offset Index field. 1531 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Via unspecified means, the S-AP might aggregate received DMG Beacon frames and Cluster Report elements and send the aggregate to the CCSR. Upon receiving this information, the CCSR might reconfigure the TSF offsets of an S-AP, reconfigure the ECAPC Policy Detail of an S-AP, update the Cluster Time Offset availability information provided in an individually addressed frame by an S-AP to a member AP or member PCP, or perform other actions. 10.37.5 Decentralized AP or PCP cluster request A non-AP and non-PCP STA that is a member of a BSS may transmit a Cluster Report element to its AP or PCP to request that decentralized AP or PCP clustering be enabled in the BSS. The non-AP and non-PCP STA can make this request if, for example, the device containing the non-AP and non-PCP STA intends to initialize another co-channel BSS (11.1) in which it performs the role of AP or PCP and, when performing this role, it wishes to become a member AP or member PCP of the decentralized AP or PCP cluster formed by its current AP or PCP. To request AP or PCP clustering to be enabled in the BSS, the STA shall transmit a Cluster Report element with the Cluster request subfield set to 1 to its AP or PCP. Upon receiving a Cluster Report element with the Cluster request subfield set to 1, the AP or PCP should form and maintain decentralized AP or PCP clustering in the BSS according to the procedures described in 10.37.2 and 10.37.3. In doing that, the AP or PCP should set the minimum duration of the Beacon SP to be equal to the Beacon SP duration. If the non-AP and non-PCP STA does not receive a DMG Beacon frame from its AP or PCP with decentralized AP or PCP clustering enabled after dot11ClusterEnableTime following the transmission to its AP or PCP of a Cluster Report element with the Cluster request subfield set to 1, the non-AP and non-PCP STA may transmit an Announce frame including the last Extended Schedule element transmitted by the AP or PCP. If the Announce frame is transmitted, it shall use MCS 0, and the TA field shall be set to the broadcast address. If a DMG STA receives an Announce frame with the TA field set to the broadcast address and with the BSSID field different from the BSSID of its BSS, the STA may send a Cluster Report element containing the Extended Schedule element within the received Announce frame to its AP or PCP, which might be used by the AP or PCP to reschedule SPs in portions of the beacon interval that are nonoverlapping in time with the SPs contained in the Extended Schedule element reported by the STA. If a non-AP and non-PCP STA becomes a member AP or member PCP of the clustering enabled by its current AP or PCP, the non-AP and non-PCP STA can synchronize scheduled CBAP allocations, if any, between the BSS in which it performs the role of AP or PCP and the BSS of its current AP or PCP. The non- AP and non-PCP STA can disallow STAs in the BSS in which it plays the role of AP or PCP from transmitting during the Beacon SPs of the cluster it is a part of, and this can be done by allocating an SP time-overlapping with each Beacon SP such that each allocated SP has both the source AID and destination AID fields within the Extended Schedule element set to the AID of the non-AP and non-PCP STA. 10.38 DMG beamforming 10.38.1 General Beamforming (BF) is a mechanism that is used by a pair of STAs to achieve the necessary DMG link budget for subsequent communication. BF training is a bidirectional sequence of BF frame transmissions that uses sector sweep and provides the necessary signaling to allow each STA to determine appropriate antenna system settings for both transmission and reception. After the successful completion of BF training, BF is said to be established. A BF frame is an SSW frame, a DMG Beacon frame, an SSW-Feedback frame, an SSW-Ack frame or a BRP frame. Figure 10-59 gives an example of the beamforming training procedure. 1532 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Sector Sweep BRP with final Transmit Sector Sweep Feedback feedback Initiator SSW SSW SSW SSW BRPâ€RX BRPâ€TX SSW SSW SSW SSW BRPâ€RX BRPâ€TX Responder Sector BRP Transmit Sector Sweep Sweep Ack Initiator Sector Sweep Responder Sector Sweep Sector-Level Sweep Beam refinement Figure 10-59â€”An example of beamforming training In this subclause, the STA that initiates BF training through the transmission of a BF frame is referred to as the initiator, and the recipient STA of the BF frame that participates in BF training with the initiator is referred to as the responder. For BF training that occurs within the A-BFT allocation, the AP or PCP is the initiator and a non-AP and non-PCP STA becomes the responder. For BF training that occurs during an SP allocation, the source DMG STA of the SP is the initiator and the destination DMG STA of the SP becomes the responder. For BF training during a CBAP allocation, the TXOP holder is the initiator and the TXOP responder is the responder and the value of the Duration field in the transmitted BF frames does not limit the duration of the BF training procedure. The duration of the BF training procedure is specified in 10.38.6.2 and 10.38.6.4. The link from the initiator to the responder is referred to as the initiator link, and the link from the responder to the initiator is referred to as the responder link. BF training starts with a SLS from the initiator. A beam refinement protocol (BRP) may follow, if requested by either the initiator or the responder. The purpose of the SLS phase is to enable communications between the two participating STAs at the DMG control mode rate or higher MCS. Normally, the SLS phase provides only transmit BF training. The purpose of the BRP phase is to enable receive training and enable iterative refinement of the AWV of both transmitter and receiver at both participating STAs. If one of the participating STAs chooses to use only one transmit antenna pattern, receive training may be performed as part of the SLS. Any BF information obtained by an initiator or a responder during a BF training attempt shall be considered invalid if either or both of the following conditions are satisfied: a) The SLS phase was not completed within dot11MaxBFTime beacon intervals from the start of the SLS phase. b) The BRP phase, if initiated, was not completed within dot11MaxBFTime beacon intervals from the start of the BRP phase. A STA shall abort an SLS if the SLS is not completed within dot11MaxBFTime beacon intervals from the start of the SLS, and shall abort a BRP if the BRP is not completed within dot11MaxBFTime beacon intervals from the start of the BRP. A STA can have one or more DMG antennas. A DMG antenna can be used to create sectors through which a STA can transmit or receive frames. The number of sectors per DMG antenna shall not be greater than 64. The total number of sectors across all DMG antennas in a STA shall not be greater than 128. 1533 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 10-19 shows the mandatory and optional procedures in the beamforming mechanism described in this subclause. Table 10-19â€”Mandatory and optional procedures in the Beamforming mechanism Support Beamforming item Notes mandatory SLS phase (10.38.2, 10.38.6.2) Yes A DMG STA is capable to participate in an SLS with any other STA as described in 10.38.2 and 10.38.6.2 Beamforming in BTI (10.38.4) Yes When operating as an AP or PCP, a DMG STA is capable to perform beamforming in the BTI as described in 10.38.4 Beamforming in A-BFT (10.38.5) Yes When operating as an AP or PCP, a DMG STA is capable to perform beamforming in the A-BFT as described in 10.38.5 BRP setup subphase (10.38.3.2) Yes A DMG STA is capable to negotiate BRP settings with any other STA as described in 10.38.3.2 MIDC subphase MID subphase No A DMG STA does not have to be capable to perform (10.38.6.3) MID as described in 10.38.6.3 BC subphase No A DMG STA does not have to be capable to perform BC as described in 10.38.6.3 BRP phase Feedback = Yes A DMG STA is capable to perform the BRP with (10.38.3, BS-FBCK any other STA as described in 10.38.3 and 10.38.6.4 10.38.6.4) and is capable to return the BS-FBCK Feedback = No A DMG STA is capable to perform the BRP with Channel any other STA as described in 10.38.3 and measurement 10.38.6.4, but does not have to be capable to return channel measurements Beam tracking Feedback = Yes A DMG STA is capable of responding to a receive (10.38.7) BS-FBCK beam tracking request. A DMG STA is capable of responding to a transmit beam tracking request with the BS-FBCK. Feedback = No A DMG STA is capable of responding to a receive Channel beam tracking request. A DMG STA does not have measurement to be capable of responding to a transmit beam tracking request with channel measurements. An SLS between an initiator and a responder is successful for the initiator if, after the completion of the SLS, the initiator receives a response to a frame transmitted to the responder using the sector and antenna selected during the SLS. The SLS is successful for the responder if, after the completion of the SLS, the responder receives a response to a frame transmitted to the initiator using the sector and antenna selected during the SLS. In this subclause, the last negotiated Total Number of Sectors field, Number of RX DMG Antennas field, and RXSS Length field held by the initiator with respect to the responder refer to the last value of the corresponding field received by the initiator from the responder and that the SLS between the initiator and responder using this value was successful for the initiator. Similarly, the last negotiated Total Number of Sectors field, Number of RX DMG Antennas field, and RXSS Length field held by the responder with respect to the initiator refer to the last value of the corresponding field received by the responder from the 1534 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications initiator and that the SLS between the responder and initiator using this value was successful for the responder. Until an SLS is successful between an initiator and a responder, the last negotiated Total Number of Sectors field, Number of RX DMG Antennas field, and RXSS Length field used by the initiator with respect to the responder refer to the value of these fields in the responderâ€™s DMG Capabilities element, and the last negotiated Total Number of Sectors field, Number of RX DMG Antennas field, and RXSS Length field used by the responder with respect to the initiator refer to the value of these fields in the initiatorâ€™s DMG Capabilities element. If an MMSL cluster capable STA has successfully transmitted to a peer STA an MMS element with the BeamLink Cluster field set to 1, then all MAC entities coordinated by the same MM-SME as the MMSL cluster capable STA shall use a single beamformed link for the MMSL cluster. Also, the MAC address used by the MMSL cluster capable STA to initiate the beamforming procedure shall remain the same until the completion of the beamforming procedure. 10.38.2 Sector-level sweep (SLS) phase 10.38.2.1 General The SLS phase can include as many as four components: an initiator sector sweep (ISS) to train the initiator link as described in 10.38.2.2, a responder sector sweep (RSS) to train the responder link as described in 10.38.2.3, an SSW feedback procedure as described in 10.38.2.4, and an SSW ack procedure as described in 10.38.2.5. An initiator shall begin the SLS phase by transmitting the frames of the ISS. A responder shall not begin transmitting the frames of an RSS before the ISS is successfully completed (as defined in 10.38.1), except when the ISS occurs in the BTI (10.38.5). An initiator shall not begin an SSW feedback procedure before the RSS phase is successfully completed (as defined in 10.38.1), except when the RSS occurs in the A-BFT. A responder shall not begin an SSW ack procedure with an initiator in the A-BFT. A responder shall begin an SSW ack procedure with an initiator immediately following the successful completion (as defined in 10.38.1) of the SSW feedback procedure with the initiator. During the SLS phase the only BF frames an initiator may transmit are the DMG Beacon frame, the SSW frame, and the SSW-Feedback frame. During the SLS phase the only BF frames a responder may transmit are the SSW frame and the SSW-Ack frame. If during the SLS the initiator and responder each execute a TXSS, then at the end of the SLS phase both the initiator and the responder possess their own transmit sector. If either the ISS or the RSS employs a receive sector sweep, then the responder or the initiator, respectively, possesses its own receive sector. The following rule applies to all channel access in DMG BSSs. A STA shall not transmit a frame as part of a sector sweep comprising at least two sectors if a response is expected within SIFS interval from the STA identified in the RA field of the transmitted frame. A STA shall not change its transmit power during a sector sweep. A frame transmitted as part of a sector sweep does not include training fields. A STA shall set the TRN-LEN parameter of the TXVECTOR to 0 for a frame transmitted as part of a sector sweep. 1535 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Two examples of the SLS phases are shown in Figure 10-60 and Figure 10-61. Transmit Sector Sweep Sector Sweep Feedback Initiator CDOWN=31 CDOWN=30 CDOWN=29 CDOWN=0 Sector Id=14 Sector Id=10 Sector Id=25 Sector Id=3 CDOWN=31 CDOWN=30 CDOWN=29 CDOWN=0 Sector Id=1 Sector Id=1 Sector Id=1 Sector Id=1 Best Sector=25 Best Sector=25 Best Sector=25 Best Sector=25 Responder Receive Sector Sweep Sector Sweep Ack Initiator Sector Sweep Responder Sector Sweep Figure 10-60â€”An example of SLS Sector Sweep Transmit Sector Sweep Feedback Initiator CDOWN=31 CDOWN=30 CDOWN=29 CDOWN=0 Best Sector=1 Sector Id=14 Sector Id=10 Sector Id=25 Sector Id=3 CDOWN=0 Sector Id=1 Best Sector=25 Responder Transmit Sector Sector Sweep Sweep Ack Initiator Sector Responder Sector Sweep Sweep Figure 10-61â€”An example of SLS In Figure 10-60 the initiator has many sectors, the responder has only one transmit sector and receive sector sweep is used at the responder sector sweep (the responder is transmitting all responder SSW frames through the same transmit sector, the initiator is switching receive antennas at the same time). In Figure 10-61 the initiator has many transmit sectors, the responder has one transmit sector. In this case, receive training for the initiator is performed in the BRP phase. 1536 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.38.2.2 Initiator sector sweep (ISS) 10.38.2.2.1 General An ISS comprises either an initiator TXSS or an initiator RXSS. An initiator RXSS may be performed in an ISS when the initiator chooses to use only one transmit antenna pattern across each of its DMG antennas. An initiator may employ either DMG Beacon frames or SSW frames in the ISS. If the initiator begins an ISS with the transmission of a DMG Beacon frame, it shall use the DMG Beacon frame for all subsequent transmissions during the ISS. Conversely, if the initiator begins an ISS with the transmission of an SSW frame, it shall use the SSW frame for all subsequent transmissions during the ISS. A responder never begins an ISS. The initiator shall set the Direction subfield in the Sector Sweep field to 0 within each DMG Beacon and SSW frame transmitted during an ISS. The initiator shall set the Total Sectors in ISS subfield within the SSW Feedback field to the total number of sectors that it is using in the ISS. The total is computed as the sum of all sectors employed on all antennas in the ISS multiplied by the number of the responderâ€™s receive DMG antennas. For example, if 4 sectors are used on antenna 0, 3 sectors on antenna 1, 5 sectors on antenna 2, and the responder has two receive DMG antennas, then the Total Sectors in ISS subfield is set to 24. 10.38.2.2.2 Initiator TXSS When the IsInitiatorTXSS field for a specific SP is 1 in a received Extended Schedule element (see 9.4.2.132) or Grant frame (see 9.3.1.13) and the Beamforming Training field of the BF Control field for that SP in the same Extended Schedule element or Grant frame is 1, then the SP contains an initiator TXSS, and the initiator shall start an initiator TXSS at the start of the next SP as indicated by the received Extended Schedule element or Grant frame. During the BTI, the initiator shall start an initiator TXSS (see also 10.38.4). During a CBAP, an initiator may obtain a TXOP with an initiator TXSS or use an existent TXOP for the initiator TXSS. If transmission of a Grant frame to the responder is used to initiate the TXSS, the Beamforming Training and IsInitiatorTXSS fields of the BF Control field is set to 1. If a Grant Ack frame is transmitted by the responder, it shall comply with 10.36.4. In the Grant Ack frame, the responder shall set the Beamforming Training field to 1. The initiator starts the initiator TXSS SIFS interval after transmission of the Grant frame or after the reception of the Grant Ack frame if the Grant Ack Supported field in the responderâ€™s DMG Capabilities element is 1 or PIFS interval after the transmission the Grant frame otherwise. During an initiator TXSS, the Sector ID field in each BF frame shall be set to a value that uniquely identifies the transmit antenna sector employed when the BF frame is transmitted. The CDOWN field in each transmitted frame shall contain the total number of transmissions remaining until the end of the initiator TXSS, including any LBIFS if required, such that the last BF frame transmission of the initiator TXSS has the CDOWN field set to 0. Each transmitted BF frame shall be separated by a time interval equal to SBIFS, unless the allocation ends as described in 10.38.6. This is indicated in Figure 10-62. 1537 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications SBIFS (if same DMG antenna) or LBIFS (if switching DMG antenna) BF BF BF BF ... frame frame frame frame CDOWN=N-1 CDOWN=N-2 CDOWN=N-3 CDOWN=0 Figure 10-62â€”Initiator TXSS or initiator RXSS If the initiator has more than one DMG antenna, the initiator transmits the BF frame through a number of sectors equal to the value of the last negotiated Total Number of Sectors field that was transmitted by the initiator to the responder. In each transmitted BF frame, the initiator shall set the Sector ID and DMG Antenna ID fields to uniquely identify the sector and the DMG Antenna ID, respectively, the initiator is using for the frame transmission and shall set the CDOWN field to the total number of transmissions remaining from all of the initiatorâ€™s DMG antennas. If an ISS is outside the BTI and if the responder has more than one DMG antenna, the initiator repeats its initiator sector sweep for the number of DMG antennas indicated by the responder in the last negotiated Number of RX DMG Antennas field that was transmitted by the responder. Repetitions of the initiator sector sweep are separated by an interval equal to LBIFS. In this case CDOWN indicates the number of sectors until the end of transmission from all initiatorâ€™s DMG antennas to all responderâ€™s DMG antennas. At the start of an initiator TXSS, the responder should have its first receive DMG antenna configured to a quasi- omni pattern and should not change its receive antenna configuration for a time corresponding to the value of the last negotiated Total Number of Sectors field transmitted by the initiator multiplied by the time to transmit a single SSW frame, plus appropriate IFSs (10.3.2.3). After this time, the responder may switch to a quasi-omni pattern in another DMG antenna. The initiator TXSS ends at the end time of the BF frame from the initiator with the CDOWN field set to 0. If the responder is unable to receive this frame, the responder shall assume that the initiator TXSS has completed at the expected end time of this frame. 10.38.2.2.3 Initiator RXSS An initiator RXSS may be requested only when an initiator is aware of the capabilities of a responder, which includes the RXSS Length field. An initiator can obtain the capabilities of a responder using the Information Request and Response procedure as described in 11.30.1. When the IsInitiatorTXSS field for a specific SP in a received Extended Schedule element or Grant frame is 0 and the Beamforming Training field of the BF Control field for that SP in the same Extended Schedule element or Grant frame is 1, then the SP shall contain an initiator RXSS, and the initiator shall start an initiator RXSS at the start of the next SP described by the received Extended Schedule element or Grant frame. The initiator never performs an initiator RXSS during the BTI. During a CBAP, an initiator shall not obtain a TXOP with an initiator RXSS. When transmission of a Grant frame to the responder is used to initiate the RXSS the Beamforming Training field set to 1 and the IsInitiatorTXSS field set to 0. If a Grant Ack frame is transmitted by the responder it shall comply with 10.36.4. In the Grant Ack frame, the responder shall set the Beamforming Training field to 1. The initiator starts the initiator RXSS SIFS interval after transmission of the Grant frame or after the reception of the 1538 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Grant Ack frame if the Grant Ack Supported field in the responderâ€™s DMG Capabilities element is 1 or PIFS interval after the transmission the Grant frame otherwise. If the initiator uses more than one transmit sector or more than one transmit DMG antenna to perform beamforming with the responder, the initiator shall perform an initiator TXSS with the responder before participating in an initiator RXSS with the responder. During the initiator RXSS the initiator shall transmit from the DMG antenna and sector that were selected during the preceding TXSS with the responder the number of BF frames indicated by the responder in the last negotiated RXSS Length field transmitted by the responder. Each transmitted BF frame shall be transmitted with the same fixed antenna sector or pattern. The initiator shall set the Sector ID and DMG Antenna ID fields in each transmitted BF frame to a value that uniquely identifies the single sector through which the BF frame is transmitted. The initiator shall set the CDOWN field in each transmitted BF frame to contain the total number of transmissions remaining to the end of the initiator RXSS, such that the last BF frame transmission of the initiator RXSS has the CDOWN field set to 0. Each transmitted BF frame shall be separated by a time interval equal to SBIFS, except if the allocation ends as described in 10.38.6. This is indicated in Figure 10-62. During an initiator RXSS, the responder should have its receive antenna array configured to sweep RXSS Length sectors, including any LBIFS if required, while attempting to receive SSW frames from the initiator. The initiator RXSS ends at the end time of the SSW frame from the initiator with the CDOWN field set to 0. If the responder is unable to receive this frame, the responder shall assume that the initiator RXSS has completed at the expected end time of this frame. 10.38.2.3 Responder sector sweep (RSS) 10.38.2.3.1 General An RSS comprises either a responder TXSS or a responder RXSS. A responder RXSS may be performed in an RSS when the responder chooses to use only one transmit antenna pattern across each of its DMG antennas. The responder initiates an RSS with the transmission of an SSW frame, which is the only frame allowed during an RSS. The responder shall set the Direction subfield in the Sector Sweep field to 1 within each SSW frame transmitted during an RSS. 10.38.2.3.2 Responder TXSS If the DMG Beacon frame immediately preceding an A-BFT contained a value of one in the IsResponderTXSS subfield of the Beacon Interval Control field, then the A-BFT is a responder TXSS A- BFT. When the IsResponderTXSS field for a specific SP in a received Extended Schedule element or Grant frame is 1 and the Beamforming Training field of the BF Control field for that SP in the same Extended Schedule element or Grant frame is 1, then the SP contains a responder TXSS, and the responder shall initiate a TXSS following the completion of the ISS in the SP described by the received Extended Schedule element or Grant frame. 1539 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications When the RXSS Length field within an SSW frame used to obtain a TXOP during a CBAP is 0, the responder shall initiate a TXSS following the completion of the ISS in the TXOP described by the received SSW frame. During a responder TXSS, the responder shall set the Sector ID and the DMG Antenna ID fields in each transmitted SSW frame to a value that uniquely identifies the sector through which the SSW frame is transmitted. The initial value of CDOWN is set to the total number of sectors in the responder (covering all DMG antennas) multiplied by the number of DMG antennas at the initiator minus one. The responder shall set the CDOWN field in each transmitted SSW frame to contain the total number of transmissions remaining to the end of the responder TXSS, including any LBIFS if required, such that the last SSW frame transmission of the responder TXSS has the CDOWN field set to 0. The responder shall transmit from its DMG antennas in increasing order of Antenna ID. Each transmitted SSW frame shall be separated by an interval of time equal to SBIFS. Transmissions are not separated by SBIFS if the allocation ends as described in 10.38.4 and 10.38.6 or if the end of an SSW slot is reached as described in 10.38.5 or when the responder completed a full sweep of all its transmit sectors and is ready to transmit to another DMG antenna of the initiator. In the latter case, the next transmission is separated from the previous transmission by LBIFS interval. This is indicated in Figure 10-63. SBIFS (if same DMG antenna) or LBIFS (if switching DMG antenna) SSW SSW SSW SSW ... frame frame frame frame CDOWN=N-1 CDOWN=N-2 CDOWN=N-3 CDOWN=0 Figure 10-63â€”Responder TXSS or responder RXSS A responder that has more than one DMG antenna and has set the value of the DMG Antenna Reciprocity field in its DMG Capabilities element to 0 transmits sequentially through all of the sectors of all of its DMG antennas. A responder that has more than one DMG antenna and has set the value of the DMG Antenna Reciprocity field in the responderâ€™s DMG Capabilities element to 1 transmits through the DMG antenna from which it had the best reception in the initiator sector sweep. The length of the sector sweep to each of the initiatorâ€™s DMG antennas is not dependent on the value of the DMG Antenna Reciprocity field. A responder that has only one DMG antenna should transmits through all its sectors, regardless of the setting of the DMG Antenna Reciprocity field. The responder shall set the Sector Select field and the DMG Antenna Select field in each transmitted SSW frame to the value of the Sector ID field and DMG Antenna ID field, respectively, of the frame received with the best quality during the ISS. The determination of which frame is received with best quality is implementation dependent and beyond the scope of this standard. The responder shall set the SNR Report field to the SNR measured for the frame indicated by the Sector Select field and DMG Antenna Select field. If the initiator has more than one DMG antenna, the responder repeats its responder sector sweep for the number of DMG antennas indicated by the initiator in the last negotiated Number of RX DMG Antennas field transmitted by the initiator. At the start of a responder TXSS, the initiator should have its receive antenna array configured to a quasi-omni antenna pattern in one of its DMG antennas for a time corresponding to the value of the last negotiated Total Number of Sectors field transmitted by the responder multiplied by the time to transmit a single SSW frame, plus any appropriate IFSs (10.3.2.3). After this time, the initiator may switch to a quasi-omni pattern in another DMG antenna. 1540 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The responder TXSS ends at the end time of the SSW frame from the responder with the CDOWN field set to 0. If the initiator is unable to receive this frame, the initiator shall assume that the responder TXSS has completed at the expected end time of this frame. 10.38.2.3.3 Responder RXSS If the DMG Beacon frame immediately preceding an A-BFT contained a value of zero in the IsResponderTXSS subfield of the Beacon Interval Control field within the DMG Beacon, then the A-BFT is a responder RXSS A-BFT. When the IsResponderTXSS field for a specific SP in a received Extended Schedule element or Grant frame is 0 and the Beamforming Training field of the BF Control field for that SP in the same Extended Schedule element or Grant frame is 1, then the SP contains a responder RXSS, and the responder shall initiate an RXSS following the completion of the ISS in the SP described by the received Extended Schedule element or Grant frame. When the RXSS Length field within an SSW frame used to obtain a TXOP during a CBAP is equal to a nonzero value, the responder shall initiate an RXSS following the completion of the ISS in the TXOP described by the received SSW frame. If the responder chooses to use more than one transmit sector or more than one transmit DMG antenna to perform beamforming with the initiator, the responder shall perform a responder TXSS with the initiator before participating in a responder RXSS with the initiator. During the responder RXSS, the responder shall transmit the number of SSW frames indicated by the initiator in the initiatorâ€™s most recently transmitted RXSS Length field (non-A-BFT) or FSS field (A-BFT) from the DMG antenna and sector that were selected during the preceding TXSS with the initiator. The responder shall set the Sector ID and DMG Antenna ID fields in each transmitted frame to a value that uniquely identifies the sector and DMG antenna, respectively, through which the BF frame is transmitted. The responder shall set the CDOWN field in each transmitted SSW frame to contain the total number of transmissions remaining until the end of the responder RXSS, such that the last SSW frame transmission of the responder RXSS has the CDOWN field equal to 0. Each transmitted SSW frame shall be separated by an interval of time equal to SBIFS, except if the allocation ends as described in 10.38.6 or if the end of an SSW slot is reached as described in 10.38.5. This is indicated in Figure 10-63. The responder shall set the Sector Select field and the DMG Antenna Select field in each transmitted SSW frame to the value of the Sector ID field and the DMG Antenna ID field, respectively, of the frame received with the best quality during the ISS. The determination of which frame is received with best quality is implementation dependent and beyond the scope of this standard. At the start of a responder RXSS, the initiator should have its receive antenna array configured to sweep over RXSS Length sectors, including any LBIFS if required, when it attempts to receive frames from the responder until the completion of the responder RXSS. The responder RXSS ends at the end time of the SSW frame from the responder with the CDOWN field set to 0. If the initiator is unable to receive this frame, the initiator shall assume that the responder RXSS has completed at the expected end time of this frame. 10.38.2.4 Sector sweep (SSW) feedback An SSW feedback procedure occurs following each RSS. During an SSW feedback procedure, the initiator shall transmit an SSW-Feedback frame to the responder. 1541 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications During an SSW feedback procedure, the responder should have its receive antenna array configured to a quasi-omni antenna pattern in the DMG antenna through which it received with the highest quality during the ISS, or to the best antenna configuration it has found during RXSS if RXSS has been performed during the ISS, and should not change its receive antenna configuration when it communicates with the initiator until the expected end of the SSW feedback procedure. When responder TXSS was performed during the preceding RSS, the initiator shall set the Sector Select field and the DMG Antenna Select field in the SSW-Feedback frame it transmits to the value of the Sector ID field and DMG Antenna ID field, respectively, of the frame received with the best quality during the responder TXSS. The determination of which frame is received with the best quality is implementation dependent and beyond the scope of this standard. In addition, the initiator shall set the SNR Report field to the SNR measured for the frame received by the sector and DMG antenna indicated by the Sector Select field and DMG Antenna Select field. The SSW-Feedback frame shall be transmitted through the sector identified by the value of the Sector Select field and DMG Antenna Select field received from the responder during the preceding responder TXSS. When responder RXSS was performed during the preceding RSS, the Sector Select field and the DMG Antenna select field in the transmitted SSW-Feedback frame are reserved. The initiator shall set the SNR Report field to the SNR measured on the frame on the receive sector designated by the RSS. The SSW- Feedback frame shall be transmitted through the sector identified by the value of the Sector Select field received from the responder during its most recently completed RSS with the initiator. The initiator may include transmit training as part of the beam refinement phase by setting the TX-TRN- REQ field to 1 in the SSW Feedback frame and setting the L-RX field to indicate the length of the training sequence it requests the responder to use in the beam refinement phase. The initiator may carry out the MIDC subphase as part of the beam refinement by setting the BC-REQ field to 1 (to request a BC subphase) and setting the MID-REQ field to 1 (to request an MID subphase); in this case, the L-RX field shall be set to indicate the number of receive AWVs the initiator uses during the MID subphase. If the responder receives an SSW-Feedback frame from the initiator before it completes the RSS with the initiator such as described in 10.38.5, the responder may cease the RSS. 10.38.2.5 SSW ack When present, the SSW ack procedure occurs following an SSW feedback procedure. When a responder TXSS is performed during an RSS, the responder shall transmit an SSW-Ack frame to the initiator to perform an SSW ack procedure. The SSW-Ack frame shall be transmitted through the sector identified by the value of the Sector Select field and the DMG Antenna Select field received from the initiator in the last SSW-Feedback frame. When an RXSS was performed during an RSS, an SSW-Ack frame shall be sent by the responder to the initiator. The SSW-Ack frame should be sent using the DMG antenna indicated in the DMG Antenna Select field in the last SSW-Feedback frame. The responder may include transmit training as part of the beam refinement phase by setting the TX-TRN- REQ field to 1 in the SSW-Ack frame and setting the L-RX field to indicate the length of the training sequence it requests the initiator to use in the beam refinement phase, as described in 9.5.4. The responder may carry out a MID subphase by setting the MID-REQ bit to 1 in the BRP Request field of the SSW frame. In this case, it shall also set the L-RX field to indicate the number of receive AWVs it uses during the MID subphase. The responder may carry out a BC subphase by setting the BC-REQ bit to 1. If the initiator has set either the MID-REQ or the BC-REQ fields to 1 in the SSW-Feedback frame, the responder may set the MID-Grant or the BC-Grant fields to 1, or both, to grant the requests. 1542 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications At the start of an SSW ack procedure, the initiator should have its receive antenna array configured to a quasi-omni antenna pattern using the DMG antenna through which it received with the highest quality during the RSS, or the best receive sector if an RXSS has been performed during the RSS, and should not change its receive antenna configuration while it attempts to receive from the responder until the expected end of the SSW ack procedure. 10.38.3 Beam Refinement Protocol (BRP) phase 10.38.3.1 General BRP is a process in which a STA trains its RX and TX antenna array(s) and improves its TX antenna configuration and RX antenna configuration using an iterative procedure. BRP may be used regardless of the antenna configuration a STA supports. The BRP phase is composed of a BRP setup subphase, a Multiple sector ID Detection (MID) subphase, a Beam Combining (BC) subphase, a subset of the previous subphases, and one or more beam refinement transactions. BRP setup allows STAs to exchange beam refinement capability information and to request the execution of the other BRP subphases. MID and BC (collectively, the MIDC subphase) are optionally used to find better initial AWVs for iterative beam refinement than might have been found by SLS due to imperfect quasi-omni receive antenna patterns. In MID, a quasi-omni transmit pattern is tested against a number of receive AWVs; this reverses the scanning roles from the transmit sector sweep. In BC, a small set of transmit and receive AWVs are tested in pairwise combinations, thus avoiding the use of quasi-omni patterns. Finally, given the starting point from SLS or MIDC, STAs can explore a broader set of transmit and receive AWVs using a request/response exchange referred to as a beam refinement transaction. The BRP setup subphase may be skipped if the BRP follows an SSW-Ack frame and no MID or BC subphases were requested during the SLS. MID and BC subphases can be skipped if either STA indicates that the subphase is not needed by setting the MID-REQ and BC-REQ fields to 0 or by setting the MID- Grant and BC-Grant fields to 0. The beam refinement transaction can be skipped if both sides indicate that the transaction is not needed by setting the L-RX and TX-TRN-REQ fields to 0. The BRP setup subphase is defined in 10.38.3.2. The MID subphase is composed of either an R-MID subphase or an I-MID subphase or both, which are composed of one or more transmissions of BRP-RX packets (20.10.2.2), followed by feedback contained in the next BRP frames from the initiator and responder. The BC subphase is composed of either an R-BC subphase or an I-BC subphase or both, which are composed of transmission of BRP-RX packets to select a beam, followed by feedback. A beam refinement transaction is a set of BRP frames consisting of beam refinement requests and responses. A beam refinement request can be either a transmit beam refinement request or a receive beam refinement request or both. A transmit beam refinement request (TX-TRN-REQ field within the BRP Request field set to 1) indicates the need for transmit antenna array training by the transmitting STA. The BRP packet that has the TX-TRN- REQ set to 1 (or the next BRP packet from this STA) shall include transmit training (TRN-T) subfields appended to it. The STA responding to the BRP packet shall include feedback based on measurements it performed during the reception of the BRP packet. The feedback type is dictated by the FBCK-TYPE field within the DMG Beam Refinement element contained in the BRP packet. A receive beam refinement request (L-RX field within the BRP Request field greater than zero) indicates the need of the receive antenna array training for the transmitting STA. The responding STA shall respond with a BRP packet with receive training (TRN-R) subfields appended to it. 1543 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Requests and responses can be combined in the same frame. As an example, the same frame can be both a transmit beam refinement request and a receive beam refinement request. The same frame can also be used as receive beam refinement response and a receive beam refinement request. See the example in Figure 10-64. Transmit BRP BRP train request, response, TX-TRN-REQ=1, RX-Train- Receive BRP response=1 request, L-RX>0 TRN-T TRN-R subfields subfields â‰¥SIFS â‰¥SIFS â‰¥SIFS â‰¤BRPIFS â‰¤BRPIFS â‰¤BRPIFS Transmit BRP Feedback, TX- TRN-R BRP Frame, train-response=1 subfields No requests Receive BRP training, RX-train- response=1 Receive BRP request, L-RX>0 TX-TRN-OK=1 Figure 10-64â€”Example of beam refinement transaction A beam refinement response is separated from a preceding beam refinement request by at least a SIFS interval and at most a BRPIFS interval provided sufficient time is available for the complete transmission of those frames within the SP allocation or TXOP. Similarly, a beam refinement request, if any, is separated from a preceding beam refinement response by at least a SIFS interval and at most a BRPIFS interval provided sufficient time is available for the complete transmission of the beam refinement request within the SP allocation or TXOP. When performing BRP, if a responding STA requires longer than SIFS to transmit a BRP frame as a response for beam refinement training request from a requesting STA, the responding STA should keep the IFS not longer than SIFS by transmitting one or more PPDUs to the requesting STA. When the beam refinement occurs within the same allocation as the SLS, the SLS initiator is the beam refinement initiator. If the beam refinement occurs in a separate allocation, the STA that transmits the first beam refinement request is the beam refinement initiator. The other STA is the beam refinement responder. A beam refinement transaction is complete when one of the following conditions is met: a) the initiator determines that it does not need further training and it has received a BRP frame with no training requests from the beam refinement responder. b) a duration equal to BRPIFS plus aSlotTime has elapsed since the last transmission from the beam refinement initiator to the refinement responder without a response from the beam refinement responder. In Figure 10-64, the first packet (from the initiator) has TX-TRN-REQ=1, the L-RX field has a value greater than zero and TRN-T subfields are appended to the packet. The second packet (from the responder) has a 1544 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications value greater than zero in the L-RX field, the TX-train-response field set to 1, the RX-train-response field set to 1, and TRN-R subfields are appended to the packet. The last packet (from the initiator) has RX-train- response set to 1 and TRN-R subfields are appended to the packet. 10.38.3.2 BRP setup subphase The BRP setup subphase is used to exchange the intent and capabilities to conduct some or all of the subphases and beam refinement transactions in a subsequent BRP phase. The BRP setup subphase is used to set up the MIDC subphase, but can also be used to set up beam refinement transactions. The BRP setup subphase shall be used in the following two cases: â€” When the RSS part of the SLS phase occurred in an A-BFT, in which case the SSW-Ack frame was not part of the SLS. â€” When the initiator set the MID-REQ or BC-REQ fields in the SSW-Feedback frame to 1 or the responder set the MID-REQ or BC-REQ fields in the SSW-Ack frame to 1. The BRP setup subphase starts with the initiator sending a BRP packet with the Capability Request subfield set to 1 and with the remaining subfields within the BRP Request field set according to the initiatorâ€™s need for an MID subphase, a BC subphase, and a beam refinement subphase. The BRP setup subphase can also start when the responder grants a MID-REQ or BC-REQ through the SSW-Ack frame or when the responder requests MID or BC in the SSW-Ack frame. Upon receiving a BRP packet with the Capability Request subfield set to 1, the responder shall respond with a BRP packet with the subfields within the BRP Request field set to indicate the presence of an MID subphase, a BC subphase and a beam refinement subphase. This process is repeated until the responder transmits to the initiator a BRP packet with the Capability Request subfield set to 0 and the initiator sends as a response a BRP packet with the Capability Request subfield also set to 0. The BRP packet from the initiator that initiates the termination of the BRP setup subphase can be the first BRP packet of the BRP phase, either as part of beam refinement or as part of a MID or BC subphase. A DMG STA (either initiator or responder) requests MID and BC subphases (see 10.38.6.3.2) by setting both the MID-REQ and BC-REQ subfields to 1 in the BRP Request field of an SSW-Feedback, SSW-Ack or BRP frame. It shall also set the L-RX subfield in the BRP Request field to the number of RX AWV settings it needs in each BRP-RX packet during the MID subphase. The peer STA grants the request by setting the MID-Grant and BC-Grant subfields to 1 in the BRP Request field within the next SSW-Ack or BRP frame transmitted to the requesting DMG STA. If either the MID or BC were not granted by the peer STA, the MID and BC subphases shall not occur. A DMG STA (either initiator or responder) requests an MID only subphase (see 10.38.6.3.3) by setting the MID-REQ subfield to 1 in the BRP Request field of an SSW-Feedback, SSW-Ack or BRP frame. The STA shall also set the L-RX subfield in the BRP Request field to the number of RX AWV settings it needs in each BRP-RX packet during the MID-subphase. The peer STA grants the request by setting the MID-Grant subfield to 1 in the BRP Request field within the next SSW-Ack or BRP frame transmitted to the requesting DMG STA. The Capability Request subfield and request subfields (TX-TRN-REQ, L-RX, MID-REQ, BC- REQ) within the granting frame shall be set to 0. If the MID-REQ was granted, the requesting STA shall transmit a BRP frame with the SNR Present and Sector ID Order Present subfields set to 1 and with the Number of Measurements field in the FBCK-TYPE field indicating the number of SNR measurements from the last SLS phase. In the Channel Measurement Feedback element, the requesting STA sets the SNR subfields to the SNRs corresponding to the TX sectors received during the SLS phase. In the Sector ID Order subfield, the requesting STA lists the sector IDs of the received sectors. The Capability Request field within the BRP frame shall be set to 0. The MID subphase starts with the transmission of a BRP packet from the peer STA after the reception of the list of sectors. A STA that has granted a MID only request shall not request MID or BC in the response packet. The STA may 1545 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications request MID or BC in the last packet it transmits to the requesting STA as part of the MID. The MID only subphase shall not occur if it was not granted by the peer STA. A DMG STA (either initiator or responder) requests a BC only subphase (see 10.38.6.3.4) by setting the BC- REQ subfield to 1 in the BRP Request field of an SSW-Feedback, SSW-Ack, or BRP frame. The peer STA (either a responder or initiator) grants the request by setting the BC-Grant subfield to 1 in the BRP Request field within the next SSW-Ack or BRP frame transmitted to the requesting STA. The BC subphase shall not occur if the peer STA does not grant the request. A DMG STA indicates that beam refinement transactions (10.38.6.4.2) occur by setting the L-RX field to a value greater than 0 to indicate the need for receive beam refinement or by setting the value of the TX-TRN- REQ field to 1 to indicate the need for transmit beam refinement or by setting both. The beam refinement transactions shall occur if at least one of these conditions is met. If the initiator has requested an MID subphase by setting the MID-REQ subfield or the BC-REQ subfield to 1 and the responder rejected by setting in the response the MID-Grant subfield or the BC-Grant subfield to 0, respectively, the initiator should send a BRP frame with the MID-REQ field set to 0 and the L-RX field set to indicate the number of TRN-R fields the initiator requests for use in the BRP transaction. If the responder has requested an MID subphase by setting the MID-REQ subfield or the BC-REQ subfield to 1 and the initiator rejected by setting in the response the MID-Grant or the BC-Grant subfields to 0, the initiator should send a BRP frame with the Capability Request subfield set to 1. The responder shall respond with a BRP frame with the MID-REQ field set to 0 and the L-RX field set to indicate the number of TRN-R fields the responder requests for use in the BRP transaction. Beam refinement transactions shall occur following a MIDC subphase when one or both of the following conditions are met at the last BRP frame transmitted by either the initiator or responder as part of the MID or BC subphases: a) Either the initiator or the responder set the L-RX field to a value greater than 0. b) Either the initiator or responder has set the value of the TX-TRN-REQ field to 1. If within the appropriate IFS the initiator does not receive a response from the responder to a packet transmitted to the responder, the initiator may retransmit the packet. After the BRP setup subphase, beamforming training shall immediately continue to the next phase (i.e., either MIDC subphase or the beam refinement transactions). Examples of BRP setup subphase procedures are illustrated in Figure 10-65, Figure 10-66, Figure 10-70, Figure 10-71, and Figure 10-77. 1546 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Initiator=1, Capability Request=1 Lâ€RX>0, Initiator=1, TXâ€TRNâ€REQ=1 Capability Request=0 Initiator TXSS Initiator SSWâ€Feedback DMG Beacon DMG Beacon BRP BRP BRP ... SLS (BTI+Aâ€BFT) BRP setup (ATI+DTI) BRP transactions (DTI) SSW SSW BRP BRP ... Responder Responder TXSS Time separation between BRP frame Initiator=0, Capability Request=0, exchanges: â‰¥ SIFS and â‰¤ BRPIFS Lâ€RX>0, TXâ€TRNâ€REQ=1 Figure 10-65â€”Example of BRP setup subphase procedure (SLS in BTI and A-BFT) L-RX>0, TX-TRN- REQ=1 Initiator TXSS Initiator SSW-Feedback BRP setup sub-phase SSW SSW BRP ... is skipped in this case SLS BRP transactions SSW-Ack SSW SSW BRP ... Responder Responder TXSS Time separation between BRP frame L-RX>0, TX-TRN- exchanges: â‰¥ SIFS and â‰¤ BRPIFS REQ=1 Figure 10-66â€”Example of skipping the BRP setup subphase (SLS in DTI) 10.38.4 Beamforming in BTI In the BTI, the AP or PCP performs an initiator TXSS as the first part of the SLS with the transmission of at least one DMG Beacon frame. The AP or PCP does not transmit SSW frames in the BTI (10.38.2.2.1). The AP or PCP may fragment the initiator TXSS over multiple consecutive BTIs by not transmitting a DMG Beacon frame through all sectors available to the AP or PCP in a single BTI. In a BTI with a fragmented initiator TXSS, the AP or PCP shall transmit DMG Beacon frames with the Fragmented TXSS field set to 1. 1547 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Otherwise, the AP or PCP shall set the Fragmented TXSS field to 0. The AP or PCP shall not change the duration of the next BTI if at least one of the DMG Beacon frames transmitted in the current BTI have the Fragmented TXSS field set to 1. The CDOWN field shall be set to the total number of transmissions remaining to the end of the initiator TXSS, such that the last DMG Beacon frame transmission of the initiator TXSS has the CDOWN field set to 0 (i.e., in a fragmented TXSS, the value of the CDOWN field covers the total number of transmissions remaining in the fragmented TXSS). The TXSS Span field shall be set to the total number of beacon intervals it takes the AP or PCP to complete the entire TXSS phase. The Duration field within each transmitted DMG Beacon frame shall be set to the time remaining until the end of the current BTI. When an AP or PCP has more than one DMG antenna, the TXSS shall cover all of the sectors in all DMG antennas. The TXSS Span field indicates the total number of beacon intervals it takes the AP or PCP to cover all sectors in all DMG antennas. The value of the TXSS Span field shall be lower than dot11MaximalSectorScan. The AP or PCP shall not change DMG antennas within a BTI. The AP or PCP has a regular schedule of transmitting through each DMG antenna (see 10.38.5.4). NOTEâ€”If an unassociated responder receives a DMG Beacon frame in the BTI with a fragmented initiator TXSS, the responder may start a responder TXSS in the following A-BFT, or it may scan for the number of beacon intervals indicated in a received TXSS Span field in order to cover a complete initiator TXSS and find a suitable TX sector from the AP or PCP. Each subfield in the Beacon Interval Control field and DMG Parameters field of each DMG Beacon frame transmitted by the AP or PCP shall retain the same value from start to completion of a TXSS phase. 10.38.5 Beamforming in A-BFT 10.38.5.1 Allocation of A-BFT The AP or PCP shall allocate an A-BFT period MBIFS following the end of a BTI that included a DMG Beacon frame transmission with Next A-BFT equal to 0. Following the end of a BTI, the AP or PCP shall decrement the value of the Next A-BFT field by 1 provided it is not equal to 0 and shall announce this value in the next BTI. The AP or PCP may increase the Next A- BFT field value following a BTI in which the Next A-BFT field was equal to 0. A STA shall consider that a BTI is completed at the expiration of the value within the Duration field of the last DMG Beacon frame received in that BTI. All DMG Beacon frames transmitted within the number of beacon intervals specified within the most recently updated TXSS Span field have the same value for each subfield within the Beacon Interval Control field (11.1.3.3). 10.38.5.2 Operation during the A-BFT Beamforming training in the A-BFT consists of the RSS and SSW feedback procedures of the SLS between the AP or PCP and a STA. In the A-BFT, the AP or PCP is the initiator and the STA is the responder in the RSS part of the SLS (10.38.2.3). The BRP phase shall not be performed within the A-BFT. A STA shall not transmit in the A- BFT of a beacon interval if it does not receive at least one DMG Beacon frame during the BTI of that beacon interval. A DMG STA that receives a DMG Beacon frame with the Discovery Mode field equal to 1 may transmit in the A-BFT following the BTI where the DMG Beacon frame is received if at least one of the following conditions is met: 1548 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” The CC Present field within the received DMG Beacon frame is equal to 1 and the STAâ€™s MAC address is equal to the value of the A-BFT Responder Address subfield within the received DMG Beacon frame. â€” The CC Present field within the received DMG Beacon frame is equal to 1, the value of the A-BFT Responder Address subfield within the received DMG Beacon frame is a group address of a group to which the STA belongs, and the responding STAâ€™s role matches the role identified by the value of the BSS Type subfield within the received DMG Beacon frame and the â€œResponding STA roleâ€ column of Table 9-65. â€” The CC Present field within the received DMG Beacon frame is equal to 0 If none of these conditions is met following the reception of a DMG Beacon frame with the Discovery Mode field equal to 1, the STA shall not transmit in the A-BFT. The A-BFT is slotted and the length of the A-BFT is an integer multiple of the sector sweep slot time. The structure of the A-BFT is shown in Figure 10-67. The AP or PCP shall announce the size of the A-BFT in the A-BFT Length subfield of the Beacon Interval Control field (9.3.4.2). The first SSW slot begins at the start of the A-BFT, and the following SSW slots are adjacent and nonoverlapping. An SSW slot (Figure 10-68) is a period of time within the A-BFT that can be used by a responder to transmit at least one SSW frame. An SSW slot has a duration of aSSSlotTime. aSSSlotTime is defined to be aSSSlotTime = aAirPropagationTime + aSSDuration + MBIFS + aSSFBDuration + MBIFS where aAirPropagationTime accounts for the propagation delay between the initiator and the responder aSSDuration (11.39) provides time for a responder to transmit up to the number of SSW frames announced in the FSS subfield of the Beacon Interval Control field in the DMG Beacon aSSFBDuration provides time for the initiator to perform an SSW feedback procedure (see 11.39) The initiator shall set the FSS subfield of the Beacon Interval Control field in the DMG Beacon frame to a value that is no less than aSSFramesPerSlot. If the IsResponderTXSS subfield of the Beacon Interval Control field is equal to 1, the A-BFT shall be used to perform a responder TXSS. Otherwise, the A-BFT shall be used to perform a responder RXSS. In the case of a responder RXSS, the same slotted structure described above is used and the responder shall transmit the number of SSW frames announced in the FSS field in the DMG Beacon. If the AP or PCP allocates the A- BFT as a responder RXSS, it should set the value of the FSS field within the Beacon Interval Control to the number of receive sectors supported by the AP or PCP. The AP or PCP shall allocate the A-BFT as a responder TXSS at least once every dot11ABFTRTXSSSwitch beacon intervals in which an A-BFT is present. At the start of each A-BFT, the responder(s) shall invoke a random backoff procedure to initiate or resume an RSS as follows. The random backoff procedure begins at the start of the A-BFT with the responder selecting a backoff count as a random integer drawn from a uniform distribution [0, A-BFT Length), i.e., 0 to A-BFT Length â€“ 1, where A-BFT Length is the value of the A-BFT Length field in the last received DMG Beacon. The responder shall decrement the backoff count by one at the end of each SSW slot, even if the CS function at the responder indicates the medium busy condition for that SSW slot. The responder may initiate the RSS only at the start of the SSW slot for which the backoff count is 0 at the beginning of the SSW slot. 1549 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Beacon Interval BTI A-BFT ATI DTI BTI aSSSlotTime A-BFT LENGTH = 8 SSW- Feedb ... SSW- Feedb ack ack SBIFS SSW Number of SSW frames transmitted in aSSDuration = Value of the FSS subfield of the Beacon Interval Control field within the DMG Beacon. In the example shown above, the value of FSS is 8. Example of A-BFT with length 8 and with each SSW slot accommodating 8 SSW frames. A possible contention between 3 STAs is shown in the figure below: STAs A, B and C are competing for access. All STAs choose a random value between [0,7]. STA A chooses value = 2, while STAs B and C choose value = 5, which might result in a collision. STA B STA A &C Figure 10-67â€”A-BFT structure e im T n io t a g Responder TXSS or SSW a Responder RXSS Feedback p o r S S P F I F I ir B B A M M a aSSDuration aSSFBDuration aSSSlotTime Figure 10-68â€”SSW slot (aSSSlotTime) definition The responder shall transmit no more SSW frames within an SSW slot than indicated in the value of the FSS subfield in the DMG Beacon. If the responder has more SSW frames to transmit as part of the RSS, but is not allowed to send any more SSW frames in the current SSW slot, then the responder may resume the RSS at the start of the following SSW slot provided that the A-BFT has not ended. If the responder cannot complete the RSS before the end of the A-BFT, it may use the same backoff procedure described above to resume the RSS at the next A-BFT for which the value of the IsResponderTXSS field is the same as the current A-BFT. The initiator shall initiate an SSW feedback procedure to a responder (10.38.2.4) at a time such that the beginning of the first symbol of the SSW-Feedback frame on the WM occurs at aSSFBDuration + MBIFS before the end of the SSW slot. A responder that transmitted at least one SSW frame within an SSW slot shall be in quasi-omni receive mode for a period of aSSFBDuration ending MBIFS before the end of the 1550 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications SSW slot. The initiator may initiate an SSW feedback procedure to the responder at an SSW slot even if the responder did not complete RSS within that SSW slot. If the initiator transmits an SSW-Feedback under this circumstance, it can transmit an Announce frame to the responder in an ATI. Following the reception of the Announce frame, the responder can respond with an SPR frame requesting time for the responder to continue with the RSS. Alternatively, the responder can transmit an SPR frame to the AP or PCP in accordance with the channel access rules. The information contained in an SSW-Feedback frame is based on the SSW frames received during the SSW slot in which the SSW-Feedback frame was transmitted. To communicate with each other following an SLS, an initiator and responder should use the information contained within the SSW-Feedback frame that had the highest value in its SNR Report field and was transmitted or received, respectively, as part of the most recent SLS between the initiator and responder. A responder that receives an SSW-Feedback frame from the initiator during an A-BFT that was allocated with a DMG Beacon frame with Discovery Mode equal to 1 should not attempt to access the following aMaxABFTAccessPeriod A-BFT allocations to redo beamforming with the initiator, unless in the BTI preceding the A-BFT the responder receives a DMG Beacon frame that has the Discovery Mode field equal to 1, the CC Present field equal to 1 and the value of the A-BFT Responder Address subfield equal to the responderâ€™s MAC address. This allows other STAs the opportunity to successfully contend for A-BFT access and perform beamforming with the initiator. The responder may attempt to restart the RSS within the same A-BFT if it does not receive an SSW- Feedback frame from the initiator by the end of the SSW slot in which it completes the RSS. To do this, the responder shall invoke the random backoff procedure beginning at the start of the SSW slot following the completion of the RSS. The responder shall select a backoff count as a random integer drawn from a uniform distribution [0, A-BFT Length), i.e., 0 to A-BFT Length â€“ 1, where A-BFT Length is the value of the A-BFT Length field in the last received DMG Beacon. The responder shall decrement the backoff count by one at the end of each SSW slot, even if the CS function at the responder indicates the medium busy condition for that SSW slot. The responder may restart the RSS at the start of the SSW slot for which the backoff count is 0 at the beginning of the SSW slot provided the A-BFT still has SSW slots available. At the end of an A-BFT the responder shall cancel a backoff procedure that was started during the A-BFT, but has not been completed at the end of the A-BFT. As described above, the responder invokes a random backoff procedure at the start of each A-BFT. Each STA maintains a counter, FailedRSSAttempts, of the consecutive number of times the STA initiates RSS during A-BFTs but does not successfully receive an SSW-Feedback frame as a response. If FailedRSSAttempts exceeds dot11RSSRetryLimit, the STA shall select a backoff count as a random integer drawn from a uniform distribution [0, dot11RSSBackoff), i.e., 0 to dot11RSSBackoff â€“ 1. The responder shall decrement the backoff count by one at the end of each A-BFT period in the following beacon intervals. The responder may re-initiate RSS only during an A-BFT when the backoff count becomes zero. The STA shall set FailedRSSAttempts to 0 upon successfully receiving an SSW-Feedback frame during the A-BFT. In an A-BFT, the responder shall not initiate an SSW ack procedure (10.38.2.5) in response to the reception of an SSW-Feedback frame from the initiator. The SSW ack procedure occurs within the DTI of a beacon interval (10.38.6.2); it does not occur otherwise. If the AP or PCP receives an SSW frame from the responder during the RSS with the Poll Required field within the SSW frame equal to 1 and the TDDTI field within the APâ€™s or PCPâ€™s DMG Capabilities element is 1, the AP or PCP shall allocate time for the responder and the AP or PCP to communicate during the ATI or within an SP of the DTI of at least one of the following aMinBTIPeriod beacon intervals beginning with the beacon interval in which the SSW frame was received. This can be done through the Extended Schedule element or the transmission of a Poll or Grant frame addressed to the responder, and the allocated time can be used for at least one of association, authentication, and service period request. 1551 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications After transmitting an SSW-Feedback frame to the responder, the initiator shall send a BRP frame with the Capability Request subfield within the BRP Request field set to 1 and addressed to the responder. The BRP frame shall be sent in one of the following aMinBTIPeriod beacon intervals beginning with the beacon interval in which the RSS phase with the responder was last completed. The BRP frame shall be transmitted at MCS 0 using the sector identified by the Sector Select field received from the responder during the RSS. In an ATI after the completion of the SSW feedback procedure, a responder should have its receive antenna configured to a quasi-omni antenna pattern in the DMG antenna in which it received the best sector from the initiator during the preceding ISS in order to receive an Announce, Grant, or BRP frame (with the Capability Request subfield within the BRP Request field set to 1) from the initiator, while the initiator should configure its transmit DMG antenna to the value of the Sector Select and the DMG Antenna Select fields received from the responder during the preceding RSS. If the responder does not receive an Announce or Grant frame from the initiator with the RA address equal to the responderâ€™s MAC address until aMinBTIPeriod beacon intervals after the beacon interval in which the SLS phase with the initiator was last attempted, it may retry BF with the initiator in the A-BFT. NOTEâ€”Due to the multiple access nature of RSS in the A-BFT, the AP or PCP might not receive the best sector for communication with the STA. The AP or PCP might schedule an SP to perform BF again with the STA to find the best sector for communication with the STA. 10.38.5.3 STA Beamforming after A-BFT The initiator shall either initiate BRP execution with the responder in the next CBAP or shall schedule time in the DTI for BRP execution with the responder if the initiator needs BRP training or the responder indicated a need for training (by setting any of the L-RX, TX-TRN-REQ, MID-REQ, or BC-REQ fields to a nonzero value) as a response to an SSW-Feedback or BRP frame with Capability Request subfield within the BRP Request field set to 1. The responder may initiate BRP in a CBAP by sending a BRP frame with any of the training request fields (i.e., L-RX, TX-TRN-REQ, MID-REQ, BC-REQ) set to 1. To schedule time in the DTI for BRP execution with a responder, the initiator may use any of the following methods: 1) Allocate an SP with the Beamforming Training subfield set to 1 in the Allocation field within an Extended Schedule element. The source of the SP shall be the initiator and the destination of the SP shall be the responder. The Extended Schedule element is carried in DMG Beacon or Announce frames, as defined in 10.36.4. The source AID of the allocation shall be set to the AID of the initiator. The destination AID of the allocation shall be set to the AID of the responder or the broadcast AID. 2) Allocate a CBAP in which the initiator or responder may start beamforming training with each other. The CBAP allocation is announced in an Extended Schedule element carried in a DMG Beacon or an Announce frame, as defined in 10.36.4. The source AID of the CBAP shall be set to the AID of the initiator or to the broadcast AID. The destination AID of the CBAP may be set to the AID of the responder or to the broadcast AID. 3) Use a Grant frame to allocate either a CBAP or an SP in which the initiator or responder may start beamforming with each other. In the Grant frame, the initiator shall set the RA field to the MAC address of the responder and the TA field to the MAC address of the initiator. In the Dynamic Allocation Info field of the Grant frame, the AllocationType field shall be set to indicate CBAP or SP, the source AID field shall be set to the AID of the initiator, the destination AID field shall be set to the AID of the responder or the broadcast AID, and the Allocation Duration field shall be set to the expected duration of the BRP phase. 4) Allocate a DTI as CBAP only as defined in 10.36.4. 1552 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications At least one of the above allocations shall occur during one of the following aMinBTIPeriod beacon intervals beginning with the beacon interval in which the SLS phase with the responder was last completed. The duration of the allocation, as specified in the Allocation Block Duration (see 9.4.2.132), shall cover at least the expected duration of the BRP phase. If the initiator receives at least one SSW frame from a responder within an A-BFT but did not transmit an SSW-Feedback frame to the responder within that A-BFT, the initiator may schedule time in the DTI to perform the ISS and RSS. To do that, the initiator may use one of the methods above. The Allocation Block Duration field shall be set to cover at least the ISS and RSS. The initiator may transmit an Announce frame to the responder during the ATI to announce a CBAP allocation in the beacon interval. If the responder receives the Announce frame with a CBAP allocation, the responder may contend for a TXOP during a CBAP to perform the BRP execution with the initiator or continue the RSS with the initiator. Any Announce or Grant frame the initiator sends to a responder after initiating beamforming with the responder in the A-BFT but before beamforming with the responder is completed shall be transmitted at MCS 0 using the sector identified by the Sector Select field received from the responder in the RSS. The execution of the beamforming procedure in an allocation in the DTI is described in 10.38.6. 10.38.5.4 Beamforming in A-BFT with multiple DMG antennas An AP or PCP shall receive through a quasi-omni antenna pattern from a single DMG antenna throughout an A-BFT unless RXSS is used in the A-BFT, in which case it switches through antenna patterns as described in 10.38.5.2. An AP or PCP shall have an A-BFT every k beacon intervals, where k is the value indicated by the N BIs A- BFT subfield in the Beacon Interval Control field. In an A-BFT, the AP or PCP shall receive in a quasi-omni antenna pattern using the DMG antenna indicated by the value of the DMG Antenna ID subfield within the SSW field transmitted in the DMG Beacon. An AP or PCP with multiple DMG antennas has a regular schedule of receiving through each DMG antenna corresponding to the DMG antenna in which a DMG Beacon frame is transmitted through. The AP or PCP shall switch RX DMG antenna every l allocations, where l is the value of the N A-BFT in Ant subfield within the Beacon Interval Control field. In each DMG Beacon, the A-BFT Count subfield in the Beacon Interval Control field indicates the number of A-BFTs that have passed since the AP or PCP last switched RX DMG antennas. 10.38.6 Beamforming in DTI 10.38.6.1 General An initiator and responder may perform BF training within an SP or CBAP. An initiator shall determine the capabilities of the responder prior to initiating BF training with the responder if the responder is associated. A STA may obtain the capabilities of other STAs through the Information Request and Information Response frames (11.30.1) or following a STAâ€™s association with the PBSS/infrastructure BSS. The initiator should use its own capabilities and the capabilities of the responder to compute the required allocation size and TXOP duration to perform BF training and BF training related timeouts. An initiator may request the AP or PCP to schedule an SP to perform BF training with a responder by setting the Beamforming Training subfield in the BF Control field of the DMG TSPEC element or SPR frame to 1. 1553 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The AP or PCP shall set the Beamforming Training subfield to 1 in the Allocation field of the Extended Schedule element if the Beamforming Training subfield in the BF Control field of the DMG TSPEC element or SPR frame that generated this Allocation field is equal to 1. The AP or PCP should set the Beamforming Training subfield in an Allocation field of the Extended Schedule element to 0 if this subfield was equal to 1 when the allocation was last transmitted by the AP or PCP in an Extended Schedule element and if, since that last transmission, the AP or PCP did not receive a DMG TSPEC element for this allocation with the Beamforming Training subfield equal to 1. 10.38.6.2 SLS phase execution For BF training in the DTI, both the initiator and responder shall use the SSW frame for the ISS and RSS. The initiator shall begin an ISS (10.38.2.2) at the start of an SP allocation or TXOP with an initiator TXSS, except in the case of an SP allocation that has the IsInitiatorTXSS field for this SP is equal to 0 in which case the initiator shall begin an ISS with an initiator RXSS. If the responder has more than one DMG antenna, the initiator shall repeat its ISS k+1 times, where k is the value indicated by the responder in the last negotiated Number of RX DMG Antennas field transmitted by the responder. Repetitions of the ISS are separated by an interval equal to LBIFS. The value of the CDOWN field within SSW frames transmitted in the ISS indicates the number of sectors until the end of transmissions from all of the initiatorâ€™s DMG antennas to all of the responderâ€™s DMG antennas. The ISS phase shall not be fragmented across multiple allocations. The RSS comprises a responder TXSS unless the allocation is an SP and the IsResponderTXSS field for this SP is equal to 0 or the allocation is a CBAP and the RXSS Length field within the SSW frame received by the responder during the ISS is equal to a nonzero value. The responder shall begin an RSS (10.38.2.3) MBIFS following the completion of an ISS, provided the responder received an SSW frame from the initiator during the ISS and there is sufficient time in the allocation for the responder to transmit all SSW frames necessary to complete the RSS phase. The responder shall not begin or continue the RSS phase in a different allocation from the allocation that contained the ISS phase. NOTEâ€”The responder can begin an RSS if there is not sufficient time in the allocation to complete the RSS phase. The RSS phase does not continue in a subsequent allocation in this case. The initiator shall begin an SSW feedback procedure (10.38.2.4) MBIFS following the completion of an RSS, provided the initiator received an SSW frame from the responder during the RSS and there is sufficient time left in the allocation to complete the SSW feedback procedure followed by an SSW ack procedure (10.38.2.5) from the responder in an MBIFS. If there is not sufficient time left in the allocation for the completion of the SSW feedback and SSW ack procedures, the initiator may begin the SSW feedback procedure in the following allocation between the initiator and the responder. The responder shall begin an SSW ack procedure (10.38.2.5) to the initiator an MBIFS following the reception of an SSW-Feedback frame from the initiator. The initiator may restart the SSW feedback procedure up to dot11BFRetryLimit times if it does not receive an SSW-Ack frame from the responder an MBIFS following the completion of the SSW feedback procedure. The initiator shall restart the SSW feedback procedure PIFS following the expected end of the SSW-Ack frame by the responder, provided there is sufficient time left in the allocation for the initiator to begin the SSW feedback procedure followed by an SSW ack procedure from the responder in an MBIFS. If there is not sufficient time left in the allocation for the completion of the SSW feedback and SSW ack procedures, the initiator may restart the SSW feedback procedure in the following allocation between the initiator and the responder. Once started, the initiator and responder shall complete the SLS phase before any additional frame exchange takes place between these STAs. 1554 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.38.6.3 Multiple sector ID capture (MIDC) subphase 10.38.6.3.1 General In practice, the quasi-omni RX antenna patterns used in the SLS phase might exhibit imperfections that lead to an incorrect choice of the best TX sector and consequently a sub-optimal starting point for beam refinement in the BRP phase. To remedy this, a multiple sector ID capture (MIDC) subphase may be used. Instead of selecting the starting point for the beam refinement transactions (i.e., the best TX sector) based on information obtained with quasi-omni RX antenna patterns from the SLS phase, the MIDC subphase enables the use of additional information based on the trial of multiple transmit and receive sectors. The MIDC subphase can be implemented in two ways. The first option is to conduct a trial between a small set of transmit and receive AWV settings with wide (e.g., quasi-omni) antenna patterns. The second option is to carry out a trial between a small set of TX sectors and a set of RX AWV settings, chosen by the receiver in an implementation dependent manner, that maximizes the probability of determining the RX AWVs that best match the chosen set of TX sectors. Note that this may involve using a set of RX AWVs that correspond to the â€œfull setâ€ of RX sectors (from the SLS phase). The set of TX sectors are chosen from a TX sector sweep with a quasi-omni RX antenna pattern. With either option, the end result from the MIDC subphase can be the better starting point transmit and receive sector pair for further beam refinement. For the first option above, the MIDC subphase consists of a MID subphase and a BC subphase. This is further elaborated upon in 10.38.6.3.2, and a sample time allocation is illustrated in Figure 10-69. For the second option, the MIDC subphase consists only of a MID subphase. This is further elaborated upon in 10.38.6.3.3, and a sample time allocation is illustrated in Figure 10-70. BTI Aâ€BFT ATI DTI SLS BRP SSWâ€ 1st BRP iteration BRP FBCK 2nd BRP Nth BRP Iâ€TXSS Râ€TXSS Setup subphase Râ€ MID Iâ€MID BRPâ€ BRPâ€ FBCK FBCK Râ€BC Iâ€BC BRPâ€ BRPâ€ FBCK FBCK iteration ... iteration MIDC subphase Figure 10-69â€”Example of time allocation for the MIDC subphase with MID and BC subphases BTI Aâ€BFT ATI DTI SLS BRP SSWâ€ st 1 BRP iteration BRP FBCK 2nd BRP Nth BRP Iâ€TXSS Râ€TXSS Setup Râ€ Râ€ Râ€ Iâ€ Iâ€ Iâ€ Iâ€ BRPâ€ BRPâ€ subphase MID MID MID MID MID MID MID FBCK FBCK iteration ... iteration MIDC subphase Figure 10-70â€”Example of time allocation for the MIDC subphase with the MID subphase only Prior to the beginning of the MIDC subphase, a BRP setup subphase is carried out as specified in 10.38.3.2. This subphase enables the two DMG STAs involved to negotiate whether and how the MIDC subphase is carried out. 1555 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications In 10.38.6.3 the following terminology is used: â€” Nbeam: the value of the Number of Beams subfield of the FBCK-TYPE field â€” Nbeam(Link Type,Antenna Type): represents a combination of Nbeam, Link Type (I for Initiator, R for Responder), and Antenna Type (TX for Transmitter, RX for Receiver) â€” Number of Measurements: the value of the Number of Measurements subfield of the FBCK-TYPE field. Examples of how the MIDC subphase is set up, depending on whether beamforming is initiated in the BTI and A-BFT or in the DTI, are illustrated in Figure 10-71 and Figure 10-72, respectively. Note that the MIDC subphase is applicable only when both the initiator and the responder have the ability to switch among their sectors. Capability Request=1, Nmeas, SNR Present=1, Capability Request=1, Sector ID Order Present=1, MID/BCâ€REQ=1, MID/BCâ€Grant=1, TXSSâ€FBCKâ€REQ=1, Nbeam(R,RX) Lâ€RX>0 SNR Requested=1 Capability Request=0 Nbeam(R,TX), MID/BCâ€REQ=1 Sector ID Order Present=1 Initiator TXSS Iâ€MID Iâ€BC Initiator DMG Beacon DMG Beacon BRP frame(s) SSWâ€Feedback BRP BRP BRP BRP BRP BRP BRP ... ... SLS (BTI+Aâ€BFT) BRP setup (ATI+DTI) MID (DTI) BC (DTI) BRP frame(s) SSW SSW BRP BRP BRP BRP BRP BRP ... ... Responder Responder TXSS Râ€MID Râ€BC Nbeam(I,RX) Capability Request=1, MID/BCâ€Grant=1, Capability Request=0, TXSSâ€FBCKâ€REQ=1, SNR Requested=1, Nmeas, SNR Present=1, Sector ID Order Present=1 Nbeam(I,TX), MID/BCâ€REQ=1, Lâ€RX>0 Sector ID Order Present=1 Time separation between BRP frame exchanges: â‰¥ SIFS and â‰¤ BRPIFS Figure 10-71â€”Example of using BRP setup subphase to set up subsequent MIDC subphase in A-BFT and DTI 1556 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Capability Request=1, MID/BC-Grant=1, TX-FBCK-REQ=1, Capability Request=1, Nbeam(R,RX) SNR Requested=1 Nmeas, SNR Present=1, Sector ID Order Present=1, Nbeam(R,TX), MID/BC- Capability Request=0 Sector ID Order REQ=1, Present=1 L-RX>0 Initiator TXSS I-MID I-BC Initiator SW-Feedback BRP frame(s) .. .. SSW SSW BRP BRP BRP BRP BRP BRP BRP . . SLS (DTI) BRP setup (DTI) MID (DTI) BC (DTI) SSW-Ack BRP frame(s) SSW SSW .. .. BRP BRP BRP BRP BRP BRP . . Responder Responder TXSS R-MID R-BC Nbeam(I,RX) MID/BC-Grant=1, Capability Request=0 MID/BC-REQ=1, L-RX>0 Nbeam(I,TX), Sector ID Order Capability Request=1, Present=1 Nmeas, SNR Present=1, Sector ID Order Present=1, Time separation between BRP frame exchanges: TXSS-FBCK-REQ=1, SNR â‰¥ SIFS and â‰¤ BRPIFS Requested=1 Figure 10-72â€”Example of using BRP setup subphase to set up subsequent MIDC subphase in DTI 10.38.6.3.2 MIDC subphase with MID and BC subphases The MIDC subphase can be implemented such that small subsets of TX sector IDs and RX AWVs are first chosen, followed by trials between these subsets to determine the optimal starting TX sector ID and RX AWV pair. The set of TX sectors is chosen from an a priori TX sector sweep with a quasi-omni RX antenna pattern (in the SLS phase). To enable the selection of the RX sectors, and the subsequent trial between the transmit and receive sectors, the MIDC subphase consists of an MID subphase and a BC (or beam combining) subphase. In the MID subphase, a wide TX beam (e.g., quasi-omni) is used while the receiver sweeps through its choice of AWV settings to determine the set of RX AWVs with the highest link quality. This is followed by the BC subphase, which involves testing the multiple RX AWVs together with multiple TX AWVs. This is conceptually illustrated in Figure 10-73. Note that the consecutive numbering of TX sector IDs (e.g., TX sector ID1, TX sector ID2, â€¦) or RX AWVs is just used for representation purposes. It is used to indicate the subset of TX sector IDs without placing any restrictions on how these sector IDs are selected (i.e., consecutive numbering of TX sector IDs does not mean that the selected TX sector IDs should be those that are consecutively numbered). 1557 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Best TX Sector IDs up to Nbeam(I, TX) STA2 TX Sector ID 1 TX Sector ID 2 STA1 TX Sector IDNbeam(I, TX) (a) Initiator TXSS in SLS Best RX Sector IDs up to Nbe am(I, RX) RX Sector/AWV 1 STA1 RX Sector/AWV 2 STA2 RX Sector /AWV Nbeam(I, RX) (b) I-MID Verification by 49(max) beam formed trials TX Sector ID1 RX Sector/AWV 1 TX Sector ID2 RX Sector/AWV 2 STA1 STA2 TX Sector IDNbeam(I, TX) RX Sector /AWV Nbeam(I, RX) (c) I- BC (Beam Combining) Figure 10-73â€”Conceptual flow of sample MIDC subphase execution with MID and BC subphases for initiator link a) Setting up the MID and BC subphases: To request a MIDC subphase with the MID and the BC subphases, the initiator shall transmit an SSW-Feedback or BRP frame with the MID-REQ and the BC-REQ fields set to 1 in the BRP Request field. The responder may grant this request by setting the MID-Grant and the BC-Grant fields to 1 in the BRP Request field within the next SSW-Ack or BRP frame transmitted to the initiator. The R-MID and R-BC subphases are performed if the request is granted and are not performed otherwise. The responder shall transmit an SSW-Ack or BRP frame to request a MIDC subphase, with the I- MID and I-BC subphases. It shall do so by setting the MID-REQ and the BC-REQ fields to 1 in the BRP Request field within the transmitted frame. The initiator may grant this request by setting the MID-Grant and the BC-Grant fields to 1 in the BRP Request field within the next BRP frame transmitted to the responder. The I-MID and I-BC subphases are performed if the request is granted and are not performed otherwise. If all of R-MID, R-BC, I-MID, and I-BC subphases are performed, the MID subphases are performed before the BC subphases. Within the MID subphase, R-MID is performed before I-MID. Within the BC subphase, R-BC is performed before I-BC (see Figure 10-69 and Figure 10-70). In addition to the MID-REQ, BC-REQ, MID-Grant and BC-Grant fields, the responder (and/or initiator) needs to obtain the number of RX AWV settings to be appended to BRP-RX packets in the R/I-MID subphase. To do this, the initiator (and/or responder) should use the L-RX field in the BRP Request field to convey this information. Similarly, the responder (and/or initiator) needs to obtain the IDs and SNRs of the TX sectors received during the SLS phase for use in the R-BC and I-BC subphases. To do this, the responder (and/or initiator) shall send a BRP packet with the TXSS- FBCK-REQ subfield and SNR Requested subfield set to 1 in the FBCK-REQ field of the DMG 1558 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Beam Refinement element. In response, the initiator (and/or responder) should send a BRP frame with both the SNR Present subfield and the Sector ID Order Present subfield set to 1. The Number of Measurements subfield in the FBCK-TYPE field is set to indicate the number of sectors received during the last SLS for which an SNR measurement is included. In the Channel Measurement field, the initiator (or responder) should set the SNR subfield to the SNRs corresponding to the TX sectors trialled during the SLS phase. In the Sector ID subfield, it should list the sector IDs of the received sectors. The responder (and/or initiator) should then use the SNR information, and any additional information such as angular separation between sectors, to determine the TX sectors for use in the BC subphase. The responder (or initiator) shall inform the initiator (or responder) of the number of TX sectors using the Number of Beams subfield in the FBCK-TYPE field during the BRP setup subphase. After the R/I-MID subphases, the same field is used to exchange information about the number of RX AWVs to be trialled during the BC subphase. b) Executing the MID subphase: If R-MID was requested and granted during the SLS and/or subsequent BRP setup subphase, then after the BRP setup subphase, the R-MID shall be initiated by the responder sending a BRP frame with TRN-R fields (as requested in the BRP setup subphase). This packet may be transmitted using a wide pattern, approaching an omni transmit pattern, or using a sector antenna pattern. The receiver may use the TRN-R fields for receive training. If the MID Extension field in the packet is equal to 1, the responder shall transmit another BRP-RX packet, which may be transmitted using another transmit pattern. It may continue transmitting BRP- RX packets as long as the MID Extension field in all of them is equal to 1. The last BRP-RX packet transmitted by the responder shall have the MID Extension field set to 0. If the initiator does not receive a BRP-RX packet within BRPIFS after transmitting the last packet of the BRP setup subphase, it may retransmit the last packet of the BRP setup subphase. After the initiator receives a BRP-RX packet with the MID Extension field set to 0, it shall respond with a BRP frame with the appropriate feedback. This BRP frame should be sent using the best TX sector as determined in the SLS phase, while the responder should use a quasi-omni pattern to receive this frame. The feedback included in this BRP frame is the number of RX AWVs to be tested in the subsequent R-BC subphase using the Number of Beams subfield in the FBCK-TYPE field. If I-MID was granted in addition to R-MID, the initiator shall send a BRP frame with TRN-R fields (as requested in the BRP setup subphase). The initiator shall continue to send BRP packets if the MID Extension was set to 1 as in the R-MID. After the responder receives a BRP-RX packet with the MID Extension set to 0, it shall respond by sending a BRP frame with feedback. This BRP frame should be sent using the best TX sector as determined in the SLS phase, while the initiator should use a quasi-omni pattern to receive this frame. The feedback included in this BRP frame is the number of RX AWVs to be tested in the subsequent I-BC subphase using the Number of Beams subfield in the FBCK-TYPE field. The initiator shall respond with a BRP frame with the TX-TRN-OK field set to 1 as an acknowledgment. The R-BC subphase then follows. If I-MID does not follow R-MID, the BC subphase follows immediately. c) Executing the BC subphase: The execution of an I-BC subphase is used as an example. In an I-BC subphase, the initiator shall transmit Nbeam(I,TX) BRP-RX frames using the number of TX sectors specified during the BRP setup subphase. Each BRP-RX frame shall be appended with Nbeam(I,RX) TRN-R subfields, and shall include the Sector ID subfield of the TX sector used. While receiving these TRN-R subfields, the responder shall switch through the RX AWVs selected during the prior I-MID subphase. To conclude the I-BC subphase, the responder shall feed back to the initiator a BRP frame with (a) the BS-FBCK field set to the TX sector ID of the BRP-RX packet received with the highest link quality, and (b) the ordered list of transmit sectors (based on received link quality during the I-BC) using the Sector ID Order subfield in the Channel Measurement Feedback element. This BRP frame should be sent using the best TX sector as determined in the SLS phase, while the initiator should use a quasi-omni pattern to receive this frame. The complete procedure is illustrated in Figure 10-74, while Figure 10-75 depicts the beam combining subphase. 1559 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications BRP- RX BRP frame BRP- RX BRP with packet with feedback packets feedback Responder R- MID R-BC MID Extension=0 MID Extension=0 I- MID I-BC Initiator BRP- RX BRP frame BRP-RX BRP with packet with feedback packets feedback (a) Normal process: one MID and BC for each initiator and responder link (the initiator and responder use a quasiâ€omni TX pattern) BRP-RX BRP-RX BRP frame BRP- RX BRP frame packet packet with feedback packets with feedback Responder R- MID R- MID R-BC MID Extension=1 MID Extension=0 MID Extension=1 MID Extension= 0 I- MID I- MID I-BC Initiator BRP- RX BRP- RX BRP frame BRP- RX BRP frame packet packet with feedback packets with feedback (b) The MID for both the initiator and responder are repeated twice: each TX beam is wider than a TX sector, but narrower than a quasiâ€omni pattern and covers a different direction BRP-RX BRP- RX BRP frame BRP- RX BRP frame packet packet with feedback packets with feedback Responder R- MID R- MID R-BC MID Extension =1 MID Extension=0 I- MID I-BC Initiator MID Extension=0 BRP frame BRP- RX BRP frame with feedback packets with feedback (c) The MID for the initiator is repeated twice: each TX beam is wider than a TX sector, but narrower than a quasiâ€omni pattern and covers a different direction Figure 10-74â€”Examples of using MID Extension field during execution of MID subphase 1560 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â‰¥ SIFS â‰¥ SIFS SBIFS â‰¤ BRPIFS SBIFS â‰¤ BRPIFS BRP with feedback Responder BRP-RX BRP-RX BRP-RX (R, Tx) 1 2 Nbeam BRP-RX BRP-RX BRP-RX BRP Initiator (I , Tx) 1 2 Nbeam (R,Rx) N be am R x be ams are tested whi le receiving each B RP -RX packe t. â‰¥ SIFS â‰¤ BRPIFS (I,Rx) N be am R x be ams are tested whi le receiving each B RP- RX packe t. Figure 10-75â€”Beam combining 10.38.6.3.3 MIDC subphase with MID subphase only The MIDC subphase may also be implemented such that multiple TX sectors, obtained from the TXSS in the SLS phase, are used instead of wide TX beams. Here, the receiver employs multiple RX AWVs for each TX sector chosen by the transmitter. Based on this joint trial of transmit and receive AWVs, the optimal starting transmit and receive AWV pair is chosen for further refinement in the BRP phase. In this case, the MIDC subphase consists only of the MID subphase. This is conceptually illustrated in Figure 10-76. Best TX Sector IDs up to N beam(I, TX) STA2 TX Sector ID 1 TX Sector ID 2 STA1 (I, TX) TX Sector ID Nbeam (a) I - TXSS in SLS Verification by Nbeam(I, TX) x N RX beamformed trials st TX Sector ID 1 1 RX sector/AWV nd STA1 STA2 TX Sector ID 2 2 RX sector/AWV MID extension Total number of RX sectors/AVWs; N RX ( I, TX) TX Sector ID Nbeam (NRX) -th RX sector/AWV (b) I-MID Figure 10-76â€”Conceptual flow of sample MIDC subphase execution with only MID subphase for initiator link 1561 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications a) Setting up the MID subphase: The procedure of setting up the MID-subphase is described in 10.38.3.2. In the example of Figure 10-77, the initiator transmits an SSW-Feedback frame with the MID-REQ subfield set to 1 and the BC-REQ subfield set to 0 in the BRP Request field, thus requesting an MIDC with only the R-MID subphase. The responder grants the MID-REQ by setting the MID- Grant subfield to 1 in the SSW-Ack frame. The initiator then sends a frame with the SNR Present and Sector ID Order Present subfields both set to 1, the Number of Measurement subfield in the FBCK-TYPE field indicating the number of SNR measurements from the last SLS phase, and the SNR and Sector ID subfields with the SNRs measured during the SLS phase and the list of received sectors, respectively. The L-RX subfield is set according to the number of training fields the initiator needs in each packet as part of the R-MID. The responder then starts the R-MID process by transmitting BRP-RX packets. SLS BRP setup BRP MID SNR Present =1 Sector ID Order Present = 1 Nmeas = 7 BS-FBCK = best from all L-RX > 0 SNR Present =1(optional) BC-REQ = 0 Sector ID Order Present = 1(optional) Initiator =1 Nmeas = 3 (optional) MID-REQ = 1 BRP BRP Initiator SSW- frame frame Feedback (sector list) (FBCK) â‰¥ SIFS â‰¥ SIFS MBIFS â‰¤ BRPIFS SIFS â‰¤ BRPIFS MID BRP MID BRP MID BRP Responder SSW- Ack NTx (1) NTx (2) ... NTx (Nbeam) MID-REQ = 0 MID-Grant=1 Tx Sector ID = NTx (1) Tx Sector ID = NTx (2) Tx Sector ID = NTx (Nbeam) MID Extension = 1 MID Extension = 1 MID Extension = 0 Figure 10-77â€”Example of using BRP setup subphase to set up subsequent R-MID subphase b) Executing the MID subphase: The execution of the MID subphase for the responder link (i.e., R- MID) is used as an example. Execution of the MID subphase for the initiator link (i.e., I-MID) is similar, except for a change in the direction of the corresponding frames. In an R-MID subphase, the responder shall transmit one BRP-RX packet each from one of the chosen TX sectors. In each packet, it shall indicate the sector ID of the TX sector used using the Sector ID field in the BRP Request field. Each transmitted BRP-RX packet should be appended with multiple TRN-R subfields such that the initiator can train its receiver antenna during the R-MID subphase. The initiator shall train its receiver antenna by cycling through its choice of RX AWVs while receiving the TRN-R subfields. The initiator shall indicate to the responder the number of TRN-R subfields to be appended using the L-RX field in the BRP Request field during the SLS phase or the BRP setup subphase. For all BRP-RX packets except the last one, the responder shall also set the MID Extension field to 1. In the R-MID subphase, the initiator shall send a BRP frame with feedback. This BRP frame should be sent using the best TX sector as determined in the SLS phase, while the responder should use a quasi-omni pattern to receive this frame. The feedback included in this BRP frame should be (a) the BS-FBCK field set to the TX sector ID of the BRP-RX packet received with the highest link quality, and (b) the ordered list of transmit sectors (based on received link quality during the R-MID) using the Sector ID Order subfield. 1562 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.38.6.3.4 MIDC subphase with BC subphase only An MIDC subphase with only the BC subphase is carried out when the MID and BC subphases have been carried out earlier. In this case, the initiator and responder keep track of the transmit and receive sectors, for use in the BC subphase, from earlier iterations. Since the best transmit and receive sectors (in terms of link quality) are kept track of, this information can be used to deal with link blockage events. STAs can utilize only the chosen set of TX sectors in the SLS phase to reduce beamforming training time, and jump to the BC subphase directly without executing the MID subphase. In this manner, fast recovery is possible when some of the backup links are available after partial blockage around the STA. To carry out the MIDC subphase with the BC subphase only, the MID-REQ field is set to 0 and the BC-REQ field is set to 1 in SSW-Feedback or SSW-Ack or BRP frames, and the BC-Grant field is set to 1 in the following SSW-Ack or BRP frame. The BC subphase can include an I-BC and/or an R-BC (10.38.6.3.2). 10.38.6.4 BRP phase execution 10.38.6.4.1 General Beam refinement is a request/response based process. A STA requests receive beam refinement training by sending a BRP frame with a nonzero value in the L-RX field. The STA that receives the BRP frame shall respond with a BRP packet (20.10.2.2) including as many TRN-R fields as indicated in the value of the L- RX field within the received BRP frame and with the RX-train-response field in the DMG Beam Refinement element set to 1. A STA requests transmit beam refinement training by sending a BRP frame as follows. In the BRP Request field, the TX-TRN-REQ field is set to 1, and the FBCK-REQ field indicates the feedback type. In the PHY header, the Packet Type and the Training Length fields are set to indicate the number of AGC and TRN-T fields appended to the packet. The responding STA shall reply to the transmit beam refinement training with a BRP frame containing a DMG Beam Refinement element with the TX-TRN-OK field and TX-train-response field both set to 1 and the BS-FBCK field set to indicate the TRN-T field on which the responding STA received the best signal (the determination of best signal is implementation dependent). The FBCK-TYPE field shall be set to according to the format of the Channel Measurement Feedback element, if one is included in the frame. If the SNR Present and Channel Measurement Present subfields of this FBCK-TYPE field are set to 0, the Channel Measurement Feedback element shall not be included. The number of taps indicated in the FBCK- TYPE field shall be less than or equal to the number of taps indicated in the FBCK-REQ field of the request frame. If a STA requests transmit beam refinement training, but does not send TRN-T fields, the responding STA shall reply with a BRP frame containing a DMG Beam Refinement element with the TX-TRN-OK field set to 1. In this case (i.e., when the TX-train-response field is equal to 0), the responding STA shall set L-RX field to 0. The requesting STA shall then transmit a BRP packet with TRN-T fields. The responding STA shall then respond with a BRP frame with the TX-train-response field set to 1 and the BS-FBCK and Channel Measurement Feedback element as above. 1563 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Beam refinement can be performed following SLS (10.38.6.4.3). If the responder receives an SSW- Feedback frame from the AP or PCP in an A-BFT, the AP or PCP allocates an SP for the beam refinement if required (see 10.38.5.3). A STA may transmit a BRP packet to another STA whenever the STA transmits a frame to that STA, provided that the transmitting STA knows that the recipient STAâ€™s receive antennas are directed to it or are in a quasi-omni antenna pattern. A STA shall set the Initiator field to 1 within a DMG Beam Refinement element if the previous received frame was not a BRP frame, or the last packet the STA transmitted was a BRP frame with the Initiator field set to 1. A STA that has transmitted a BRP frame with the Initiator field set to 1 and has not received a response BRPIFS after the transmission may retransmit the frame. A STA may request a TXSS sector list feedback by sending a BRP frame with the TXSS-FBCK-REQ field set to 1, the SNR Requested subfield within the FBCK-REQ field set to 1 and the remaining subfields within the FBCK-REQ field set to 0. The responding STA shall respond with a BRP frame with the SNR Present subfield within the FBCK-TYPE field set to 1 and Sector ID Order Present subfield set to 1, with a list of sector IDs indicating the sector IDs of the received SSW frames or DMG Beacon frames, and with the SNR values with which those frames were received in the last TXSS. The Number of Measurements subfield in the FBCK-TYPE field is set to indicate the number of sectors received during the last SLS for which an SNR measurement is included. A STA shall not set the TXSS-FBCK-REQ and the TX-TRN-REQ fields to 1 in the same BRP frame. Two or more BRP frames shall not be aggregated in the same A-MPDU. A BRP frame may be aggregated with another frame in the same A-MPDU only if the other frame is a single Ack, BA or QoS Null frame. The Duration field within each BRP frame is set to the time remaining until the end of the current allocation, when transmitted within an SP. Otherwise it is set to the time remaining until the end of the TXOP. 10.38.6.4.2 Beam refinement transaction A beam refinement transaction is a set of BRP frames composed of request and responses. A beam refinement transaction starts with the beamforming initiator STA sending a BRP frame with the Initiator field set to 1. A beam refinement responder is a STA that receives a BRP frame (which is directed to it) with the Initiator field set to 1. A beam refinement transaction participant shall respond to a BRP frame with a BRP frame. If the beam refinement transaction initiator received a BRP frame from the responder with no training requests, the initiator may terminate the transaction by not transmitting any further BRP packets. 1564 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Figure 10-78, Figure 10-79, and Figure 10-80 show examples of beam refinement transactions. Receive beam refinement training Transmit Training Request â€“ request, L-RX â‰ 0 Transmit Training Request â€“ TX-TRN-REQ=1, TX-TRN-REQ=1 TRN-T field present Initiator Initiator Responder Responder Receive beam refinement response, RX-Train-response=1, TRN-R field Transmit Training response Transmit Training response present TX-TRN-OK=1 TX-Train-response=1 Figure 10-78â€”Example beam Figure 10-79â€”Example beam refinement transaction refinement transaction (receive training) (transmit training) Receive Response, RX-Train-response=1, Receive Beam TRN-R field present, TX training, TRN-T field present, refinement training TX training response, TX-TRN-OK=1, Transmit training response+FBCK, Req â€“ L-RX â‰ 0 Transmit training request, TX-TRN-REQ=1 Receive training request Initiator Responder RX training, RX-train-response=1, Receive Response, RX-Train-response=1, TX training, TRN-T field present, TRN-R field present, TRN-R field present, Transmit training request, TX-TRN-OK=1 Transmit training response+FBCK Transmit training request, TX-TRN-REQ=1, Receive request, L-RX>0 Figure 10-80â€”Example beam refinement transaction (combination of receive and transmit training) 10.38.6.4.3 Beam refinement transaction after SLS If either L-RX or TX-TRN-REQ is nonzero within the BRP Request field in the SSW-Ack frame of the most recent SLS phase execution, no MID or BC was granted during the BRP setup subphase, and no beam refinement transaction has been done since the most recent SLS phase execution, then the initiator shall initiate the beam refinement transaction with the responder by sending a BRP frame to the responder. If the value of the L-RX field is greater than 0 in the SSW-Ack frame, the first BRP frame the initiator transmits to the responder is a BRP-RX frame. If the value of the L-RX field is 0 and the value of the TX-TRN-REQ 1565 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications field is 1, the first BRP frame the initiator transmits to the responder shall have either the TX-TRN-OK field set to 1 or the L-RX field greater than 0. 10.38.6.4.4 Antenna configuration setting during a beam refinement transaction A STA that has requested beam refinement receive training shall, except when receiving TRN-R fields, set its receive antenna configuration to the best known receive antenna configuration based on previous beam refinement receive training or RXSS. If the STA has not received a BRP frame since the last SLS and the SLS did not include an RXSS, the STA should set its receive antenna configuration to a quasi-omni antenna pattern in the DMG antenna through which the STA received the best sector during the SLS. A STA that has received a beam refinement transmit training request shall send the response frame and then set its antenna configuration to the best known receive antenna configuration based on previous beam refinement receive training or RXSS, except if both the initiator STA and responder STA support the Other_AID subfield as indicated through the Supports Other_AID field set to 1 within the STAâ€™s DMG Capabilities element and the value of the Other_AID subfield within the BRP Request field is different from 0, in which case the STA sets its antenna configuration to the best known receive antenna configuration for receiving from the STA with AID equal to the value of the Other_AID subfield within the BRP Request field. If the STA has not received a BRP frame since the last SLS and the SLS did not include an RXSS, the STA should set its antennas to a quasi-omni antenna pattern. In a BRP-RX packet, all TRN-R fields shall be transmitted using the same TX AWV configuration as the preamble and data fields of the packet, except if both the transmitting and receiving STAs support the Other_AID subfield as indicated through the Supports Other_AID field set to 1 within the STAâ€™s DMG Capabilities element and the value of the Other_AID subfield within the BRP Request field is different from 0, in which case the TRN-R fields shall be transmitted using the best known TX AWV configuration for transmitting to the STA with AID equal to the value of the Other_AID subfield within the BRP Request field. A STA that has the DMG Antenna Pattern Reciprocity subfield within the DMG STA Capability Information field of the DMG Capabilities element equal to 1 and that has received a BRP-RX packet from a peer STA that also has the DMG Antenna Pattern Reciprocity subfield within the DMG STA Capability Information field of the peer STAâ€™s DMG Capabilities element equal to 1 shall use the same AWV that was configured with the BRP-RX packet in subsequent transmissions and receptions with the peer STA during the DTI. This allows STAs that use reciprocity to shorten the beamforming training time. 10.38.7 Beam tracking A STA (beam tracking initiator) may request a peer STA (beam tracking responder) to perform receive beam tracking by setting, in a transmitted packet, the TXVECTOR parameter BEAM_TRACKING_REQUEST to Beam Tracking Requested, TRN-LEN to the number of requested TRN fields as described in 20.10.2.2.3 and packet type to TRN-R-PACKET. Otherwise, the BEAM_TRACKING_REQUEST parameter shall be set to Beam Tracking Not Requested. A beam tracking responder that receives a packet with the Beam Tracking Request field in the PHY header equal to 1 (corresponding to the BEAM_TRACKING_REQUEST parameter in the RXVECTOR set to Beam Track Requested) and the Packet Type field in the PHY header equal to 0 (corresponding to PACKET-TYPE field in the RXVECTOR set to TRN-R-PACKET) shall follow the rules described in 20.10.2.2 and shall include a beam refinement AGC field and TRN-R subfields appended to the following packet transmitted to the initiator in the same allocation, with an MCS index greater than 0. The value of TRN-LEN in the following packet from the responder to the initiator shall be equal to the value of the TRN- LEN parameter in the RXVECTOR of the packet from the initiator. A responder may ignore a request for beam tracking within an allocation if no packets with an MCS index greater than 0 are transmitted from the responder to the initiator within the allocation. 1566 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A beam tracking initiator requesting transmit beam tracking shall set the BEAM_TRACKING_REQUEST parameter in the TXVECTOR to Beam Tracking Requested, Packet Type to TRN-T-PACKET, TRN-LEN to the number of TRN-Units as described in 20.10.2.2.3, and append an AGC field and TRN-T subfields to the packet. The beam tracking responder may append the feedback to any packet from the responder to the initiator. The initiator may allocate time for the feedback through a reverse direction grant, provided the reverse direction protocol is supported by both the initiator and responder. The feedback type shall be the same as the feedback type in the last BRP frame that was transmitted from the initiator to the responder with TX-TRN-REQ equal to 1. If the responder has never received a BRP frame from the initiator with TX-TRN- REQ equal to 1, the responder shall respond with all subfields of the FBCK-TYPE field equal to 0 and set the BS-FBCK field to the index of the TRN-T subfield that was received with the best quality. A beam tracking initiator may also request a beam tracking responder to perform receive beam tracking by setting, in the PHY header of a transmitted packet, the Beam Tracking Request field to 0, the Training Length field to a nonzero value, the Packet Type field to 0, and append an AGC field and TRN-R subfields to the transmitted packet. A beam tracking responder that receives a packet with the Beam Tracking Request field in the PHY header equal to 0, the Training Length field in the PHY header equal to a nonzero value and the Packet Type field in the PHY header equal to 0 shall follow the rules described in 20.10.2.2 and may use the beam refinement AGC field and TRN-R subfields appended to the received packet to perform receive beam training. BRP frames transmitted during beam tracking may be aggregated within A-MPDUs. Figure 10-81 illustrates a beam tracking frame exchange sequence when the beam tracking initiator requests TRN-R fields, while Figure 10-82 illustrates a beam tracking frame exchange sequence when the beam tracking initiator requests TRN-T fields. TRN-R fields Beam appended Tracking Responder Data Data Data Ack Ack Ack Beam Tracking Initiator Beam Tracking Requested Packet Type = TRN-R TRN-LEN>0 Figure 10-81â€”Example of beam tracking procedure with initiator requesting TRN-R A beam tracking initiator may transmit to the beam tracking responder a PPDU requesting transmit beam tracking if at least one of the following conditions is met: â€” The time duration since the last PPDU it transmitted to the beam tracking responder that requested transmit beam tracking is greater than dot11BeamTrackingTimeLimit plus BRPIFS. â€” A BRP frame with the channel measurement feedback from the beam tracking responder has been received. 1567 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Beam Tracking Requested Packet Type = TRN-T TRN-T fields Beam TRN-LEN>0 appended Tracking Initiator Data Data Data BRP Ack Ack Ack Beam frame Tracking Responder BRP frame with feedback Figure 10-82â€”Example of beam tracking procedure with initiator requesting TRN-T If the beam tracking initiator does not receive the expected feedback from the beam tracking responder within a time period that is less than dot11BeamTrackingTimeLimit of the last request, the beam tracking request has failed. If the initiator receives the expected feedback from the responder within time that is greater than or equal to dot11BeamTrackingTimeLimit of the last request, the beam tracking initiator should ignore it. The time of arrival of the beam tracking responderâ€™s feedback is indicated by the PHY-RXEND.indication primitive of PPDU that contains the BRP MMPDU. The time of transmit completion of the beam tracking initiatorâ€™s PPDU is indicated by the PHY- TXEND.confirm primitive. The beam tracking responder shall not transmit a BRP frame with feedback to the beam tracking initiator if the time period between PHY-RXEND.indication primitive of the PPDU that contains the beam tracking request and of PHY-TXEND.confirm primitive of the response BRP frame is longer than dot11BeamTrackingTimeLimit. 10.38.8 State machines Figure 10-83 depicts an example state machine of the SLS phase for the initiator, and Figure 10-84 illustrates an example state machine of the SLS phase for the responder. These state machines describe the behavior of the initiator and responder during BF and are applicable for any period of the beacon interval where BF is performed. 1568 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11BFRetryLimit not exceeded or (start of BTI and STA is AP or PCP) -> Perform Initiator TXSS Sector SSW frame Idle received Selector (Timeout (T1 or T2) and DTI) or (end of A-BFT and STA is AP or PCP) Sector selected and DTI -> Perform SSW Feedback TXSS Phase Complete SSW acknowledg- ment Timeout (MBIFS) and dot11BFRetryLimit not T1 = dot11BFTXSSTime exceeded -> Perform SSW Feedback T2 = dot11MaxBFTime Figure 10-83â€”SLS phase state machine (initiator) BF frame Idle Sector Selector received Timeout (T2) SSW frame received SSW frame Sector selected -> received Perform Responder TXSS Timeout (T2) or (end SSW slot (A- BFT) and no backoff) SSW-Feedback frame SSW-Feedback frame received -> End SSW slot (A-BFT) and TXSS Phase received and DTI -> SSW Perform SSW backoff within A-BFT -> Pre-Complete Perform SSW Feedback acknowledgment Perform Responder TXSS acknowledgment TXSS Phase Complete T2 = dot11MaxBFTime Figure 10-84â€”SLS phase state machine (responder) 1569 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.39 DMG link adaptation 10.39.1 General A STA may transmit a Link Measurement Request frame to request a STA indicated in the RA field of the frame to respond with a Link Measurement Report frame (9.6.7.5). If the Link Measurement Request frame is sent within a PPDU defined in Clause 20, the Link Measurement Report frame shall contain the DMG Link Margin element. The requesting STA may use values of the MCS, of the SNR and of the Link Margin to transmit frames to the STA indicated in the RA field of the Link Measurement Request frame. The requesting STA may aggregate a Link Measurement Request frame in an A-MPDU as defined in Table 9-425 and Table 9-428. If the Dialog Token field in the Link Measurement Request frame is equal to a nonzero value, the responding STA shall perform the measurement on the next frame received from the requesting STA and shall send back a Link Measurement Report frame corresponding to the received frame. The responding STA may aggregate a Link Measurement Report frame in a A-MPDU as defined in Table 9- 425 and Table 9-428. The DMG STA whose MAC address equals the value of the Link Measurement Request frame RA field shall transmit a Link Measurement Report frame addressed to the requesting STA. The RA field of the Link Measurement Report frame shall be equal to the TA field of the Link Measurement Request frame. If the Dialog Token field in the Link Measurement Report frame is equal to the nonzero Dialog Token field of the Link Measurement Request frame, then the MCS, SNR, and Link Margin fields of the Link Measurement Report frame shall be computed using the measurements of the PPDU that is the next frame received from the requesting STA. If the Dialog Token field in the Link Measurement Request frame is equal to 0, the responding STA may set the MCS field in the Link Measurement Report frame to the MCS value computed based on any of the received frames from the requesting STA. The SNR field and Link Margin field in the Link Measurement Report frame shall indicate the corresponding measurements based on the reception of the PPDU that was used to generate the MCS feedback contained in the same Link Measurement Report frame. The Link Measurement Request and Report frames can be used to obtain link margin information, which can be used to determine appropriate action by the requesting STA (e.g., change MCS or control transmit power or initiate FST). A STA may send an unsolicited Link Measurement Report frame with the Dialog Token field set to 0. 10.39.2 DMG TPC A DMG STA that receives a Link Measurement Report frame containing a DMG Link Margin element that indicates increase or decrease transmit power behaves according to the following rules: â€” If the STA implements the recommendation indicated in the Activity field of the Link Measurement Report, it shall send a Link Measurement Report frame containing a DMG Link Adaptation Acknowledgment element. The Activity field of the DMG Link Adaptation Acknowledgment element shall be set to the value of the Activity field in the received DMG Link Margin Subelement. â€” If the STA does not implement the recommendation indicated in the Activity field of the Link Measurement Report, it may send a Link Measurement report containing a DMG Link Adaptation 1570 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Acknowledgment element. The Activity field of the DMG Link Adaptation Acknowledgment element shall be set to 0, indicating that the STA did not change its transmit power. â€” A STA shall not send a Link Measurement Report later than 2Ã—aPPDUMaxTime after it acknowledged the reception of the Link Measurement report. A DMG STA shall not include the DMG Link Adaptation Acknowledgment element in a Link Measurement Report frame, unless the frame is being transmitted in response to a received Link Measurement Report frame whose Activity field is equal to increase or decrease transmit power. 10.39.3 Fast link adaptation A STA indicates support for fast link adaptation by setting the Fast Link Adaptation field in the STAâ€™s DMG Capabilities element to 1. A STA that does not support fast link adaptation sets the Fast Link Adaptation field in the STAâ€™s DMG Capabilities element to 0. A STA that supports fast link adaptation shall not initiate fast link adaptation with a peer STA that does not support fast link adaptation. A STA that supports fast link adaptation shall support the reverse direction protocol (see 10.28). The STA that transmits a Link Measurement Request frame as part of fast link adaptation shall be the RD initiator and the STA that responds with a Link Measurement Report frame shall be the RD responder. Transmission of Link Measurement Request, Link Measurement Report and the frames defined below shall follow the rules of the reverse direction protocol. A STA initiates fast link adaptation by transmitting a Link Measurement Request frame that is of subtype Action No Ack and has its Dialog Token field set to 0. The PPDU containing the frame shall have the AGGREGATION parameter in the TXVECTOR set to AGGREGATED, shall not contain any other frame that requires immediate response, and shall have a duration (as determined by the PHY-TXTIME.confirm primitive defined in 6.5.6) that is greater than aMinPPDUDurationForDMGMeasurement. NOTEâ€”The PPDUs have the AGGREGATION parameter in the TXVECTOR set to AGGREGATED to allow padding of the PSDUs with MPDU delimiters of size 0, therefore meeting the transmission duration requirement. A STA that supports fast link adaptation and receives a Link Measurement Request frame of subtype Action No Ack, with the Dialog Token field equal to 0 and contained in a PPDU with the AGGREGATION parameter in the RXVECTOR equal to AGGREGATED shall respond with a Link Measurement Report frame in no longer than BRPIFS from the reception of the Link Measurement Request frame. The TPC Report element, DMG Link Margin element and other fields transmitted in the Link Measurement Report frame shall reflect measurements on the PPDU that contained the last received Link Measurement Request frame from the initiating STA. The STA responding with the Link Measurement Report frame shall keep the IFS not longer than SIFS by transmitting PPDUs that do not contain frames requiring immediate response and that have a duration that is greater than aMinPPDUDurationForDMGMeasurement. All transmitted PPDUs should use the same MCS and the same transmit power. The transmitted Link Measurement Report frame shall be of subtype Action No Ack, shall be sent using MCS 1, and shall be sent within a PPDU with the AGGREGATION parameter in the TXVECTOR set to AGGREGATED. In addition, the PPDU shall not contain any frame that requires immediate response and shall have a duration that is greater than aMinPPDUDurationForDMGMeasurement. If at least one of the conditions above for the transmission of the Link Measurement Report frame is not met, the STA may follow the rules in 10.39.1 to respond to the received Link Measurement Request frame. A STA that supports fast link adaptation and that receives a Link Measurement Report frame should respond with an unsolicited Link Measurement Report frame in no longer than BRPIFS from the reception of the 1571 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Link Measurement Report frame. The TPC Report element, DMG Link Margin element and other fields transmitted in the unsolicited Link Measurement Report frame shall reflect measurements taken on one or more of the PPDUs received by the STA transmitting the unsolicited Link Measurement Report frame, starting with the received Link Measurement Report frame itself. If the unsolicited Link Measurement Report frame is transmitted longer than SIFS from the reception of the Link Measurement Report frame, the STA transmitting the unsolicited Link Measurement Report frame shall keep the IFS not longer than SIFS by transmitting one or more PPDUs before issuing the unsolicited Link Measurement Report frame. An example of the fast link adaptation procedure is shown in Figure 10-85. Initiating STA SIFS < Computation time < BRPIFS Link unsolicited Link Measurement PPDU Measurement Request Report Link Responding STA PSDU PPDU ... PPDU Measurement Report BRPIFS SIFS 5.27us Figure 10-85â€”Example of fast link adaptation procedure 10.40 DMG dynamic tone pairing (DTP) A pair of communicating STAs shall employ DTP modulation only if both STAs support DTP as indicated through the DTP Supported field within the STAâ€™s DMG Capabilities element. A DTP capable STA may use DTP with another DTP capable STA by setting the DTP_TYPE in the TXVECTOR to dynamic; otherwise, the DTP_TYPE is set to static. The transmitting STA may stop using DTP by setting the DTP_TYPE in the TXVECTOR to static. A transmitting STA requests a DTP report from a receiving STA by sending a DTP Request frame to that STA. Upon receiving a DTP Request frame, the receiving STA shall respond with a DTP Report frame carrying the DTP configuration. The DTP Report frame should be sent no later than dot11BeaconPeriod TUs after the receiving STA transmits an Ack frame in response to the reception of the DTP Request frame. If the transmitting STA does not receive a DTP Report frame from the receiving STA within dot11BeaconPeriod TUs from the transmitting STAâ€™s reception of the Ack frame corresponding to its most recent DTP Request frame transmission to the receiving STA, the transmitting STA may retransmit the DTP Request frame to the receiving STA. The Dialog Token field of the DTP Report frame is set to the value of the Dialog Token field in the corresponding DTP Request frame. The transmitting STA should switch to the updated DTP configuration after a DTP Report frame is received. If a STA transmits a DTP Report frame in response to the reception of a DTP Request frame, the STA shall not send an updated DTP Report frame unless it receives another DTP Request frame. A STA that transmits an unsolicited DTP Report frame should not send a new unsolicited updated DTP Report frame unless the STA has received a frame from the peer STA indicating that the peer STA has switched to the DTP configuration last sent. Both the transmitting and receiving STAs maintain two copies of DTP configurations: the current configuration that is in use for transmission and an updated configuration, if any, received after the current configuration. The transmitting STA determines when to switch from the current to the updated DTP 1572 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications configuration. The transmitting STA shall indicate the switch from the current configuration to the updated configuration by toggling the DTP Indicator bit field in the PHY header. The value of the DTP Indicator field shall be kept unchanged until the transmitting STA decides to switch to the new DTP configuration. By receiving an Ack frame in response to a Data frame from the receiving STA, the switching operation is completed. The transmitting STA may send another DTP Request frame to a receiving STA even if it decided not to switch to the DTP configuration indicated by the receiving STAâ€™s last transmitted, if any, DTP Report frame. If the Beam link cluster field is 0, then the links within the MMSL cluster that use DTP may maintain independent DTP configurations. 10.41 DMG relay operation 10.41.1 General The DMG relay procedures are specified in 11.36. This subclause specifies the supported types of DMG relay. DMG relay operation is not supported by an IBSS STA. An IBSS STA shall set dot11RelayActivated to false. A source REDS, a destination REDS and an RDS can establish two types of relay operation: â€” Link switching (10.41.2): If the direct link between the source REDS and destination REDS is disrupted, the source REDS redirects the transmission of frames addressed to the destination REDS via the RDS. The RDS forwards frames received from the source REDS to the destination REDS and from the destination REDS to the source REDS. Direct communication between the source REDS and destination REDS might resume after the direct link between them is recovered. â€” Link cooperation (10.41.3): In this case, the RDS is actively involved in the direct communication between the source REDS and the destination REDS. A frame transmission from the source REDS to the destination REDS is simultaneously repeated by the RDS, which might possibly increase the signal quality received at the destination REDS. 10.41.2 Link switching 10.41.2.1 General A source REDS that has successfully completed an RLS procedure with a destination REDS for which the value of the Cooperation-Mode subfield within the negotiated Relay Transfer Parameter Set element is 0 may use the selected RDS between the source REDS and destination REDS for the purpose of link switching. This is described in this subclause. 10.41.2.2 SP request and allocation The source REDS uses the procedures described in 11.4 to request an SP allocation between itself and the destination REDS. Upon receiving an ADDTS Request frame for which the source AID and the destination AID fields within the DMG TSPEC element are equal to a pair of a source REDS and a destination REDS, respectively, that have successfully completed the RLS procedure defined in 11.36.2.4, the AP or PCP schedules an SP with the source DMG STA as the source REDS and the destination DMG STA as the destination REDS. 1573 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications An RDS shall check the value of the source AID and the destination AID fields of each SP allocation within an Extended Schedule element it receives in a DMG Beacon or Announce frame from the AP or PCP. If the value of the source AID and the destination AID fields of an SP allocation correspond to a source REDS and a destination REDS, respectively, that have successfully completed the RLS setup procedure (11.36.2), the RDS shall operate as an RDS during that SP allocation. 10.41.2.3 Usage of RDS In link switching, an RDS operates either in FD-AF mode or in HD-DF mode. An RDS capable of FD-AF relaying shall be in one of two frame transmission modes: â€” Normal mode: A pair of source REDS and destination REDS exchange frames via either the direct link or the relay link until this link is determined to become unavailable due to, for example, blockage or channel degradation. â€” Alternation mode: A source REDS and a destination REDS exchange frames via two separate links, where the use of each link alternates at each link change interval. The link change interval specifies the time instants at which a source REDS is allowed to change the link used for a frame transmission to the destination REDS as specified in 9.4.2.149. An RDS that supports only HD-DF shall operate in the Normal mode. The frame transmission mode is indicated in the Relay Transfer Parameter Set element exchanged by the source REDS, destination REDS, and RDS during the RLS procedure. A source REDS or destination REDS may change the transmission mode used in a relay link following a successful exchange of RLS Request and RLS Response frames as described in 11.36.2.4. An RDS shall start to operate as RDS at the start of an SP for which the value of the source AID and destination AID fields for that SP are equal to the source REDS and destination REDS, respectively, for which the RDS has successfully completed the RLS procedure. The RDS can determine the SPs for which it operates as an RDS upon the reception of an Extended Schedule element. 10.41.2.4 Relay frame exchange rules 10.41.2.4.1 General Following the completion of the RLS procedure and SP allocation, each of the source REDS, destination REDS, and RDS have a direct link with one another. The values of link change interval and data sensing time are indicated within the Relay Transfer Parameter Set transmitted by the source REDS to the destination REDS during the RLS procedure. Either the link change interval period or the first period begins at the start of an SP between the source REDS and the destination REDS, and any transmission by the source REDS, destination REDS, and RDS within a link change interval period shall use the same link that is used at the start of the link change interval period. A new link change interval period starts immediately after another link change interval period, but shall not exceed the end of the SP. In the normal mode, a source REDS shall use the direct link to initiate frame transmission to the destination REDS at the start of the first SP allocated between the source REDS and destination REDS for a particular TID. At the start of the following SP allocations for that same TID, the source REDS uses the last link in which a frame transmission to the destination REDS via this link was successful. In the alternation mode, the source DMG STA shall alternate the frame transmission to the destination REDS between direct frame transmission to the destination REDS and frame transmission through the RDS. The source REDS shall alternate the link used for a frame transmission at the start of each link change interval. 1574 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If a source REDS transmits a frame to the destination REDS via the direct link but does not receive an expected Ack frame or BlockAck frame from the destination REDS during a link change interval period, the source REDS should change the link used for frame transmission at the start of the following link change interval period and use the RDS to forward frames to the destination REDS. If a source REDS transmits a frame to the destination REDS via the RDS but does not receive an expected Ack frame or BlockAck frame from the RDS during a link change interval period or a first period, the source REDS should change the link used for frame transmission at the start of the following link change interval period or the following first period and transmit frames directly to the destination REDS. 10.41.2.4.2 Additional frame exchange rules for FD-AF RDS If the source REDS decides to change the link at the start of the following link change interval period and the Normal mode is used, the source REDS shall start its frame transmission after data sensing time from the start of the following link change interval period. If the Alternation mode is used, the source REDS alternates the link used for frame transmission at the start of each link change interval period, and the value of data sensing time is ignored. In the Normal mode, if the destination REDS does not receive a valid frame from the source REDS within data sensing time after the start of a link change interval, the destination REDS shall immediately change the link to attempt to receive frames from the source REDS through the RDS. If the More Data subfield in the last frame received from the source REDS is equal to 0, then the destination REDS shall not switch to the link in the next link change interval period even if it does not receive a frame during the data sensing time. An example of frame transfer under Normal mode with FD-AF RDS is illustrated in Figure 10-86. Data frame to Ack frame to Data frame to Ack frame to direct link direct link relay link relay link Link Change Interval SP SP SP S D S D S D S R D S R D S R D Data Sensing SIFS Time Figure 10-86â€”Example of Normal mode operation with FD-AF relay In the Alternation mode, if the destination REDS receives an out of order frame, the destination REDS shall remain at the current link. If the More Data subfield in the last frame received from the source REDS is equal to 0, then the destination REDS shall not switch links in the next link change interval period. If the source REDS uses either the direct or the relay link and decides to resume alternate frame transmission, the source REDS should transmit a frame to the other link data sensing time after the next link change interval to inform the destination REDS that operation on the other link has been resumed. Note that this is the only situation when data sensing time is used in the Alternation mode. 1575 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.41.2.4.3 Additional frame exchange rules for HD-DF RDS When the RDS is operating as a HD-DF RDS and the RDS is used in the frame exchange between the source REDS and the destination REDS, the frame exchange is performed in two periods, which are repeated for as long as the RDS is used. In the first period, the source REDS shall transmit a frame to the RDS and then the RDS responds after SIFS if needed. In the second period, the RDS shall forward the frame received from the source REDS to the destination REDS, and then the destination REDS responds after SIFS if needed. The duration of the first period and the second period are specified in the last Relay Transfer Parameter Set element transmitted from the source REDS. The first period and second period are valid only when the source REDS and destination REDS exchange frames via the RDS. The link change interval is valid only when the source REDS and destination REDS exchange frames via the direct link. The first period begins at the end of the link change interval when a change to the relay link occurs. The link change interval begins at the end of the second period when a change to the direct link occurs. The source REDS may transmit a Relay Ack Request frame to the RDS to determine whether all frames forwarded through the RDS were received by the destination REDS. Upon reception of a Relay Ack Request frame, the RDS shall respond with a Relay Ack Response frame and set the BlockAck Bitmap field to indicate which frames have been received by the destination REDS. If the source REDS decides to change to the relay link at the start of the following link change interval period, the source REDS shall start its frame transmission at the start of the following link change interval period. If the current link is the direct link and the destination REDS does not receive a valid frame from the source REDS within data sensing time after the start of each link change interval, the destination REDS shall change the link and consider the first period to begin at the start of the link change interval. If a link change to the direct link occurs, the source REDS shall start to transmit a frame using the direct link at the end of the second period when the link change interval begins. The destination REDS shall switch to the direct link at each first period and listen to the medium toward the source REDS. If the destination REDS receives a valid frame from the source REDS, the destination REDS shall remain on the direct link and consider the link change interval to begin at the start of the first period. Otherwise, the destination REDS shall change the link at the start of the next second period and attempt to receive frames from the source REDS through the RDS. If the active link is the relay link and the More Data subfield in the last frame received from the RDS is equal to 0, then the destination REDS shall not switch to the direct link even if it does not receive any frame during the second period. The source REDS that intends to use the block ack mechanism through the RDS shall perform the block ack setup procedure with the RDS using the same TID as it is used for the direct communication between the source REDS and the destination REDS. Similarly, the RDS shall perform the block ack setup procedure with the destination REDS before transmitting data using the block ack mechanism. Upon reception of an ADDBA Request frame from the source REDS, the RDS shall send an ADDBA Request frame to the destination REDS with the same content for all corresponding fields as the ADDBA Request frame received from the source REDS, except for Buffer Size field, which contains the buffer size of the RDS. Following the reception of the ADDBA Response frame from the destination REDS, the RDS shall send an ADDBA Response frame to the source REDS. The ADDBA Response frame shall have the same content for all corresponding fields as the ADDBA Response frame received from the destination REDS, except for the Buffer Size field, which shall be set to the minimum between the buffer size of the RDS and the destination REDS. 1576 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications An example of frame transfer with HD-DF RDS is illustrated in Figure 10-87. Data frame to BAR frame to BA frame to Data frame to BAR frame to BA frame to Relay Ack Relay Ack direct link direct link direct link relay link relay link relay link request response Link change interval 1st Period 2nd Period 1st Period SP SP S D S D S D S R S R S R R D R D R D S R SIFS Data sensing time Figure 10-87â€”Example of operation with HD-DF relay 10.41.2.4.4 Operation of FD-AF RDS In an SP allocated for relay operation, a FD-AF RDS operates in an amplify-and-forward manner. This means that for each frame detected at the RF in the receive state within an SP in which it operates as a FD- AF RDS, the RDS amplifies the received signal and simultaneously retransmits it via the RF in transmit state. At the start of the SP where it operates as a FD-AF RDS, the RDS shall initiate an RF antenna module in the receive state directed toward the source REDS and another RF antenna module in transmit state directed toward the destination REDS. For each frame received at the RDS during the SP, the RDS shall follow the same rules for frame exchange sequences as described in Annex G and 10.36. This includes switching the state of each RF available to the RDS from receive to transmit, and vice-versa, depending upon the frame type and its ack policy. 10.41.2.5 Link monitoring After a link change, the source REDS might periodically monitor the quality of the previous link. To do that, the source REDS can use the link change mechanism described in 10.41.2.4. If the previous link is the relay link, the source REDS can acquire the channel status by using relay link measurement mechanism as described in 10.41.4. If the previous link is the direct link, the source REDS can acquire the channel status via the link adaptation mechanism defined in 10.39. If the channel quality of the previous link is better than the one on the current link, which is an implementation dependent decision, the source REDS may switch to the previous link. 10.41.3 Link cooperation 10.41.3.1 TPA procedure A source REDS, a destination REDS, and an RDS use the common relay setup procedure defined in 11.36.2 to set up a link cooperation relay. In addition, to establish a link cooperation relay, the source REDS, destination REDS, and RDS shall perform the TPA procedure described in this subclause and shown in Figure 10-88. 1577 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications SBIFS dTDR : Propagation delay from D to R dTDS : Propagation delay from D to S TPA TPA dTSR : Propagation delay from S to R TPA Request Request Request frame frame frame Destination (D R) (D S) (D R) dTDS-dTDR REDS (â€˜Dâ€™) dTDR dTSR dTDR TPA TPA TPA Response Response Response aDtime frame frame frame (R D) (R S) (R D) RDS (â€˜Râ€™) dTDS TPA TPA Response Request frame frame Source (S D) (S R) REDS (â€˜Sâ€™) SBIFS Figure 10-88â€”TPA mechanism The TPA procedure is triggered by the destination REDS following the common relay setup procedure with the source REDS and RDS. First, the destination REDS uses the procedures described in 11.4 to request the allocation of an SP to perform TPA, wherein the source of the SP is the destination REDS and the destination of the SP is the source REDS. If the value of a source AID and the destination AID fields of an SP allocation correspond to a destination REDS and a source REDS, respectively, that have successfully completed the RLS setup procedure, a STA that performs as an RDS in that SP allocation shall operate during the allocation as a non-RDS-capable DMG STA. Within the allocated SP, the destination REDS sends a TPA Request frame to the RDS and sets the Timing Offset field to 0 (see Figure 10-88). SBIFS interval following the end of the first TPA Request frame transmission, the destination REDS shall send the second TPA Request frame to the source REDS and set the Timing Offset field to 0. aDtime interval (11.39) following the reception of the first TPA Request frame, the RDS shall transmit a TPA Response frame back to the destination REDS. Upon receiving the TPA Response frame from the RDS, the destination REDS shall estimate the TPA value of the RDS and the time deviation (i.e., 2Ã—dTDR) between the expected Dtime and the actual arrival time of the TPA Response frame. aDtime interval following the reception of the second TPA Request frame, the source REDS shall transmit a TPA Response frame back to the destination REDS. The destination REDS shall repeat the same procedure upon reception of the TPA Response frame received from the source REDS. SBIFS interval following the end of the transmission of the TPA Response frame to the destination REDS, the source REDS shall send a TPA Request frame to the RDS and set the Timing Offset field to 0. aDtime interval following the reception of the TPA Request frame, the RDS shall transmit a TPA Response frame back to the source REDS. Upon reception of the TPA Response frame from the RDS, the source REDS shall estimate the TPA value of the RDS and the time deviation (i.e., 2Ã—dTSR) between aDtime and the actual arrival time of the TPA Response frame. At aRelayTPATime (11.39) from the end of the last TPA Request frame transmitted by the destination REDS to the source REDS, the destination REDS shall send a TPA Request frame to the RDS and set the Timing Offset field to dTDSâ€“dTDR. Upon reception of the TPA Request frame, the RDS shall transmit a TPA Response frame to the destination REDS at aDtime+dTDR+(dTDSâ€“dTDR) from the end of the TPA Request frame. Upon reception of the TPA Response frame, the destination REDS shall estimate the time deviation (i.e., 2Ã—dTDR+(dTDSâ€“dTDR)) between aDtime and the actual arrival time of the TPA Response frame. If the destination REDS determines that the estimated deviation is equal to 2Ã—dTDR+(dTDSâ€“dTDR), then the destination REDS considers that the TPA procedure was successful. As the last step of the TPA procedure, the destination REDS shall send a TPA Report frame to the source REDS that includes the information regardless of whether the last TPA procedure succeeded. 1578 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If it is not successful, the TPA procedure is repeated until it is successful or upon the decision of the destination REDS to stop performing the TPA procedure. The TPA procedure includes the estimation of the sampling frequency-offset (SFO), in order for the source REDS and RDS to adjust their SFOs. 10.41.3.2 Frame exchange operation 10.41.3.2.1 General A source REDS that has successfully completed an RLS procedure with a destination REDS for which the value of the Cooperation-Mode subfield within the negotiated Relay Transfer Parameter Set element is equal to 1 and has successfully completed the TPA procedure shall use the selected RDS between the source REDS and destination REDS for the purpose of link cooperation. This is described in this subclause. 10.41.3.2.2 Cooperative transmission SP request and allocation If the source REDS receives a TPA Report frame that indicates the successful completion of the TPA procedure with the RDS and the destination REDS, the source REDS uses the procedure in 11.4 to request an SP allocation with the destination REDS. The source REDS might use the SP allocation for communication with the destination REDS with the assistance of the RDS. 10.41.3.2.3 Data transmission rules As shown in the example of Figure 10-89, in the allocated SP the first time interval (T1) and the second time interval (T2) for a cooperative Data frame transfer are determined by the packet transmission time at each transmission from the source REDS to the destination REDS within the SP. Pre-determined time = Ptime The period for one cooperative data frame transfer Data frame from S R Normal Ack frame beamformed from D S T1 T2 T1 T2 T1 T2 S R R D S R R D R D S R S D S D S D Ptime SIFS Ptime SIFS Ptime SIFS The SP period allocated Figure 10-89â€”Example of data transmission in SP with link cooperation relay The data transmission rules are as follows. At the start of each time T1, the source REDS transmits a frame with its transmit antenna pattern directed toward the RDS and with the TA and the RA fields in the MAC header set to the MAC address of the source REDS and destination REDS, respectively. After Ptime+dTSR from the start of T2, the source REDS retransmits the same frame sent to the RDS during the previous time T1 but now with its transmit antenna pattern directed toward the destination REDS. Similarly, after Ptime+(dTDSâ€“dTDR) from the start of T2, the RDS retransmits the same frame it received from the source REDS during the previous time T1. So that the destination REDS might take advantage of the improved received signal level from both of these transmissions, the destination REDS should set its receive antenna pattern during T2 such that it simultaneously covers the links toward both the source REDS and the RDS. 1579 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 10.41.4 Relay link adaptation When a relay link is used for communication between a source REDS and a destination REDS, the link qualities of the S-R link, the R-D link, and the S-D link might be required. The source REDS, destination REDS, and RDS use the procedure described in 10.39 to request and report the link quality among themselves with the following exception. In the Link Measurement Report frame the RDS transmits to the source REDS, the RDS shall include two Link Margin elements in this order: â€” The first Link Margin element shall report the link quality between the source REDS and the RDS. â€” The second Link Margin element shall report the link quality between the RDS and the destination REDS. Upon reception of a Link Measurement Report frame, the source REDS might take several actions including changing the MCS it uses for frame transmission to the RDS and destination REDS. 1580 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11. MLME 11.1 Synchronization 11.1.1 General STAs in a single infrastructure BSS, PBSS, or IBSS are synchronized to a common clock using the mechanisms defined in 11.1. STAs in mesh BSSs use a synchronization method that is part of the extensible synchronization framework. The synchronization in an MBSS is described in 14.13. A STA for which dot11OCBActivated is true is not a member of a BSS and, therefore, is not required to synchronize to a common clock or to use these mechanisms. A timing synchronization function (TSF) keeps the timers for all STAs in the same BSS synchronized. All STAs in which dot11OCBActivated is false maintain a local TSF timer. STAs in which dot11OCBActivated is true may maintain a TSF timer for purposes other than synchronization. A multi-band capable device (11.33) shall maintain a local TSF timer for each channel in which the STA operates. 11.1.2 Basic approach 11.1.2.1 TSF for an infrastructure BSS or a PBSS In an infrastructure BSS or in a PBSS, the AP in the infrastructure BSS or the PCP in the PBSS shall be the timing master for the TSF. In a non-DMG BSS, the AP shall periodically transmit frames called Beacon frames. In a DMG BSS, the AP or PCP shall periodically transmit frames called DMG Beacon frames and Announce frames, which provide a similar function to the Beacon frame in a non-DMG BSS. Beacon, DMG Beacon, and Announce frames contain the value of the APâ€™s or PCPâ€™s TSF timer in order to synchronize the TSF timers of other STAs in a BSS. A receiving STA shall accept the timing information in Beacon, DMG Beacon, and Announce frames sent from the AP or PCP servicing its BSS. If a STAâ€™s TSF timer is different from the timestamp in the received Beacon, DMG Beacon, or Announce frame, the receiving STA shall set its local TSF timer to the received timestamp value. In a non-DMG BSS, Beacon frames shall be generated for transmission by the AP once every dot11BeaconPeriod TUs. NOTEâ€”The beacon interval, and hence the valid values of dot11BeaconPeriod, is constrained for APs in which dot11PublicHCCATXOPNegotiationActivated is true or dot11ProtectedHCCATXOPNegotiationActivated is true as specified in 11.28.4.1. In a DMG infrastructure BSS, zero or more DMG Beacon frames shall be generated for transmission by the AP every dot11BeaconPeriod TUs (see 11.1.3.3). The AP shall transmit at least one DMG Beacon frame through each sector available to the AP within a time interval that is not longer than dot11BeaconPeriod Ã— dot11MaxLostBeacons TUs. The TXSS Span field in the DMG Beacon frame shall be set to a value that is less than or equal to dot11MaxLostBeacons. In a PBSS, the value of the TSF timer is delivered to the STA by the DMG Beacon frames generated at each BTI and by the Announce frames generated during the ATI. In a PBSS, at TBTTs that do not start with a BTI, the PCP begins a beacon interval with an ATI sequence (see 11.1.3.3.2). The time interval in between two consecutive BTIs shall be an integer multiple of dot11BeaconPeriod TUs. The PCP shall transmit at least one DMG Beacon frame to each associated STA within a time interval that is not longer than 1581 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11BeaconPeriod Ã— dot11MaxLostBeacons TUs. The PCP shall transmit at least one DMG Beacon frame through each possible antenna configuration in a full-coverage set of antenna configurations within the number of beacon intervals specified within the most recently updated TXSS Span field. 11.1.2.2 TSF for an IBSS The TSF in an IBSS is implemented via a distributed algorithm that is performed by all of the members of the BSS. Each STA in the IBSS shall transmit Beacon frames according to the algorithm described in this clause. Each IBSS STA shall adopt the TSF value received from any Beacon frame or probe response from the IBSS of which it is a member and which has a TSF value later than its own TSF timer. 11.1.2.3 TSF for an MBSS The TSF in an MBSS is provided by the MBSSâ€™s active synchronization method. A mesh STA shall initialize its TSF timer according to the MBSSâ€™s active synchronization method. The mesh STA shall periodically transmit Beacon frames that contain the value of its TSF timer to announce its local time reference. Mesh STAs receiving a Beacon frame use the timing information in the Beacon frame as specified by the MBSSâ€™s active synchronization method. See 14.13.2 for details. 11.1.3 Maintaining synchronization 11.1.3.1 General Each STA shall maintain a TSF timer with modulus 264 counting in increments of microseconds. STAs expect to receive Beacon frames at a nominal rate. In a non-DMG infrastructure BSS, the interval between Beacon frames is defined by dot11BeaconPeriod. In a DMG infrastructure BSS, the STAs expect to receive at least one DMG Beacon frame every dot11BeaconPeriod Ã— dot11MaxLostBeacons TUs. In a PBSS, STAs expect to receive at least one DMG Beacon frame or one Announce frame every dot11BeaconPeriod Ã— dot11MaxLostBeacons TUs. A STA sending a Beacon frame shall set the value of the Beacon frameâ€™s timestamp so that it equals the value of the STAâ€™s TSF timer at the time that the data symbol containing the first bit of the timestamp is transmitted to the PHY plus the transmitting STAâ€™s delays through its local PHY from the MAC-PHY interface to its interface with the WM [e.g., antenna]. A STA sending a DMG Beacon or an Announce frame shall set the value of the frameâ€™s timestamp field to equal the value of the STAâ€™s TSF timer at the time that the transmission of the data symbol containing the first bit of the MPDU is started on the WM (which can be derived from the PHY-TXHEADEREND.indication primitive), including any transmitting STAâ€™s delays through its local PHY from the MAC-PHY interface to its interface with the WM. 11.1.3.2 Beacon generation in non-DMG infrastructure networks The AP shall define the timing for the entire BSS by transmitting Beacon frames according to dot11BeaconPeriod. This defines a series of TBTTs exactly dot11BeaconPeriod TUs apart. Time 0 is defined to be a TBTT with the Beacon frame being a DTIM. At each TBTT, the AP shall schedule a Beacon frame as the next frame for transmission according to the medium access rules specified in Clause 10. NOTEâ€”To achieve this requirement, the AP suspends any pending transmissions until the beacon has been transmitted. In the case of a DTIM, the AP also suspends any pending individually addressed transmissions until any pending group addressed transmissions have been performed (see 11.2.3.4). The beacon period is included in Beacon and Probe Response frames, and a STA shall adopt that beacon period when joining the BSS, i.e., the STA sets dot11BeaconPeriod to that beacon period. NOTEâ€”Though the transmission of a Beacon frame might be delayed because of CSMA deferrals, subsequent Beacon frames are scheduled at the undelayed nominal beacon interval. This is shown in Figure 11-1. 1582 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Figure 11-1â€”Beacon transmission on a busy network If a STA that does not support short slot time associates with an AP that supports Clause 18 operation, and the AP is using short slot time, the AP shall use long slot time beginning at the first Beacon frame subsequent to the association of the long slot time STA. An AP whose last transmitted values for the Tx STBC subfield and Rx STBC subfield of the HT Capability Information field of the HT Capabilities element are both nonzero may transmit an STBC Beacon frame and group addressed traffic using the basic STBC MCS, as defined in 10.7.3. An AP that transmits an STBC Beacon frame shall set the Dual Beacon field to 1 in transmitted HT Operation elements. A VHT AP shall set the Dual Beacon field to 0 in transmitted HT Operation elements. The STBC Beacon field shall be set to 1 to identify an STBC Beacon frame. The TBTT for the STBC Beacon frame shall be offset by half of a beacon interval from the TBTT of the non-STBC Beacon frame. Except for the setting of the STBC Beacon field, TIM field, and TSF field, all other fields inside the STBC Beacon frame shall be identical to the non- STBC Beacon frame. The use of the dual beacon mechanism is deprecated. 11.1.3.3 Beacon generation in a DMG infrastructure BSS and in a PBSS 11.1.3.3.1 General A DMG STA acting as an AP or PCP follows the DMG channel access procedures (see 10.36) and the rules described in this subclause to transmit DMG Beacon frames. Each DMG Beacon frame transmitted by a PCP and by a DMG AP shall have the Discovery Mode field within the DMG Beacon frame set to 0. The Duration field of each transmitted DMG Beacon frame shall be set to the time remaining until the end of the current BTI. A PCP and a DMG AP establish a series of Target Beacon Transmission Times (TBTTs) spaced dot11BeaconPeriod TUs apart. The period between two TBTTs is referred to as the beacon interval. The beacon interval length shall be no more than aMaxBIDuration. Time value zero of the TSF is defined to be a TBTT. The length of the beacon interval is included in the DMG Beacon, Announce, and Probe Response frames, and a DMG STA shall adopt that beacon interval when joining the BSS. A PCP and a DMG AP that move the TBTT (11.31.2) or change the beacon interval duration (11.31.3) shall reestablish the TBTT by resetting the TSF to 0 at the time the BSS parameter change takes effect in the BSS. At each BTI, a PCP and a DMG AP schedule DMG Beacon frames for transmission according to the procedure specified in 10.38.4. Subject to this constraint, the AP or PCP may delay the DMG Beacon frame transmission if the medium is determined by the CCA mechanism to be busy. When delaying a DMG 1583 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Beacon frame transmission, the AP or PCP shall check that the BTI, A-BFT, and ATI do not overlap in time with pseudo-static SPs for which the AP or PCP is not the source DMG STA and, if AP or PCP clustering is in use, that the DMG Beacon frame transmission follows the additional rules described in 10.37. An AP or PCP may transmit DMG Beacon frames through different antenna configurations during the BTI, but shall not transmit more than one DMG Beacon frame through the same antenna configuration during the BTI of any beacon interval. For any beacon interval that does not include a DMG Beacon frame transmission in the BTI, the AP shall begin the beacon interval with an ATI, and the PCP may begin the beacon interval with an ATI (11.2.7.3). When the DMG Beacon frame transmission is performed as multiple directional transmissions, an AP or PCP should change the sequence of directions through which a DMG Beacon frame is transmitted after it has transmitted a DMG Beacon frame through each direction in the current sequence of directions. When the ECAPC Policy Enforced field is equal to 1 in the DMG Beacon frame most recently transmitted by an AP or PCP, then â€” When the AP or PCP transmits a DMG Beacon frame as multiple directional transmissions, the AP or PCP shall change the sequence of directions through which a DMG Beacon frame is transmitted after it has transmitted a DMG Beacon frame through each direction in the current sequence of directions. â€” When the AP or PCP transmits a DMG Beacon frame as a single transmission, the AP or PCP shall randomly delay the transmission of the DMG Beacon frame by up to min(4Ã—TXTIME(DMG Beacon), 1024Ã—dot11MinBHIDuration) Âµs after the TBTT. This is done to randomize and potentially minimize interference to/from the DMG Beacon. One such example is indicated in Figure 11-2. If the sequence of directions is changed, the sequence of directions shall be pseudorandomly chosen from a sequence of directions covering the full set of directions available to an AP or PCP. Beacon Interval 0 Beacon Interval 1 Beacon Interval N-1 Beacon Interval N BTI BTI ... BTI BTI ... 0 1 ... N-1 2 N-1 ... 1 N-2 0 ... 2 0 1 ... N-1 Figure 11-2â€”Example of DMG beacon transmission by an AP or PCP during the BTI NOTEâ€”An AP or PCP operating in a DMG BSS can transmit Announce frames during the ATI (10.36.3). An Announce frame can perform the function of a DMG Beacon frame, can be transmitted as an individually addressed frame directed to a STA, and can provide a much more spectrally efficient access than using a DMG Beacon frame. A DMG STA that is an AP or a PCP shall include a DMG Operation element within a transmitted DMG Beacon frame if the CBAP Only field within the DMG Beacon frame is equal to 1. A DMG STA that is an AP or a PCP shall include a DMG Operation element within a transmitted DMG Beacon frame if the CBAP Only field within the DMG Beacon frame is equal to 0 and the Extended Schedule element is included in the DMG Beacon frame. A DMG STA that is an AP or a PCP shall include a DMG Operation element within a transmitted Announce frame if the Extended Schedule element is included in the Announce frame. 11.1.3.3.2 Beacon generation in a PBSS In a PBSS, every beacon interval shall start with a BTI or ATI, except in PCP power save (PPS) mode, where a PCP doze BI may not start with a BTI or ATI. 1584 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A PCP that transmits a DMG Beacon frame with the CBAP Only field equal to 1 within a BTI shall include a BTI in any following beacon intervals until the completion of the TXSS of which the DMG Beacon frame is a part. 11.1.3.3.3 Beacon generation in a DMG infrastructure BSS A DMG AP shall set dot11MaxLostBeacons to the value of the aMinBTIPeriod parameter. 11.1.3.4 DMG beacon generation before establishment of a BSS A DMG STA can transmit DMG Beacon frames before establishment of a BSS to discover and perform beamforming during the A-BFT with another DMG STA so that the following frame exchanges between these STAs do not have to be done as a sector sweep (see 11.1.4.3.3). A DMG STA that transmits DMG Beacon frames before establishment of a BSS shall set the Discovery Mode field in each transmitted DMG Beacon frame to 1 to indicates that the establishment of a BSS procedure defined in 11.1.4.4 has not been performed. In addition, the STA shall set the Next A-BFT field to 0. Before establishment of a BSS, the spacing between TBTTs can change, and the time to the next TBTT is contained in each DMG Beacon frame transmitted at the last BTI. At each TBTT, the STA should generate a random value for the Beacon Interval field within the DMG Beacon frame from a uniform distribution between [10 TUs, 200 TUs), i.e., 10 TUs to 199 TUs. Every DMG Beacon frame transmission in the same BTI shall have the same value in its Beacon Interval field. The TSF shall be set to 0 at the first TBTT for which the Discovery Mode field within the DMG Beacon frame is equal to 1. After that, the TSF shall be set to 0 at the TBTT of the beacon interval in which the STA changes the value of the Beacon Interval field. A STA shall transmit the first DMG Beacon frame of the next BTI at the time indicated by the start of the transmission of the first DMG Beacon frame within the last BTI and the value of the Beacon Interval field contained in the DMG Beacon frame transmitted within the last BTI, unless the medium is determined by the CCA mechanism to be busy in which case the STA may delay the transmission of the first DMG Beacon frame transmission. A STA that transmits a DMG Beacon frame with the Discovery Mode field equal to 1 may indicate the STA(s) that is allowed to respond in the A-BFT following the BTI where the DMG Beacon frame is transmitted. To do that, in the DMG Beacon frame the STA shall set the CC Present field to 1 and shall set the A-BFT Responder Address subfield to an individual address or to a group address of a group that includes the STA(s) that is allowed to respond in the A-BFT. A DMG STA that is transmitting DMG Beacon frames with the Discovery Mode field equal to 1 should configure its receive antenna to a quasi-omni antenna pattern and stay in receiving state during portions of the DTI defined by the DMG Beacon frame transmissions. This enables the STA to receive frames transmitted by any STA that is covered by this antenna pattern. A STA that is transmitting DMG Beacon frames with the Discovery Mode field equal to 1 should cease transmitting these beacons when it has received a DMG Beacon frame from another STA, or when it has received acknowledgment of a transmitted Probe Response frame. If a BSS is not initialized as a result of the channel scanning, the STA can resume transmitting DMG Beacon frames with the Discovery Mode field equal to 1. 1585 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The procedure of TBTT change described in the preceding paragraph is applicable for DMG Beacon frame generation before establishment of a BSS, whereas the procedures defined in 11.31.2 and 11.31.3 are used to change the DMG BSS parameters after an infrastructure BSS or PBSS has been established. A STA shall set the Duration field of each transmitted DMG Beacon frame to the time remaining until the end of the current BTI. 11.1.3.5 Beacon generation in an IBSS Beacon generation in an IBSS is distributed. The beacon period is included in Beacon, Announce, and Probe Response frames, and a STA shall adopt that beacon period when joining the IBSS. All members of the IBSS participate in beacon generation. Each STA shall maintain its own TSF timer that is used for dot11BeaconPeriod timing. The beacon interval within an IBSS is established by the STA at which the MLME-START.request primitive is performed to create the IBSS. This defines a series of TBTTs exactly dot11BeaconPeriod TUs apart. Time zero is defined to be a TBTT. At each TBTT the STA shall a) Suspend the decrementing of the backoff timer for any pending transmission that is not a Beacon or DMG Beacon frame, b) Calculate a random delay uniformly distributed in the range between zero and twice aCWmin aSlotTime when the STA is a non-DMG STA, and between zero and the result of two multiplied by aCWminDMGIBSS multiplied by the duration of the STAâ€™s following BTI when the STA is a DMG STA, c) Wait for the period of the random delay, decrementing the random delay timer using the same algorithm as for backoff, except that SIFS + aSlotTime should be used as the initial medium idle period within the backoff procedure. If the ATIM window in use within the IBSS is greater than 0 and the end of the ATIM window occurs before the random delay timer expires, cancel the remaining random delay and pending Beacon frame transmission and proceed to step f), d) Cancel the remaining random delay and the pending Beacon frame transmission or BTI (DMG only), if a Beacon frame arrives from the IBSS of which the STA is a member before the random delay timer has expired, e) Send a Beacon frame in a non-DMG BSS or DMG Beacon frame(s) in a DMG BSS if the random delay has expired and no Beacon frame in a non-DMG BSS or no DMG Beacon frame in a DMG BSS has arrived from the IBSS of which the STA is a member during the delay period, f) If the ATIM window in use within the IBSS is greater than 0, then 1) Resume decrementing the backoff timer for any pending transmission allowed inside the ATIM window and 2) At the end of the ATIM window duration resume the backoff for any pending frames intended for transmission outside the ATIM window, g) If the ATIM window in use within the IBSS is 0, then resume decrementing the backoff timer for any pending transmissions. Figure 11-3 illustrates beacon transmission in an IBSS. 11.1.3.6 Beacon generation in an MBSS Beacon generation in an MBSS is described in 14.13.3.1. 1586 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Figure 11-3â€”Beacon transmission in an IBSS 11.1.3.7 Beacon reception A STA shall use information from the CF Parameter Set element of all received Beacon frames, without regard for the BSSID, to update their NAV as specified in 10.4.3.3. STAs in an infrastructure network or PBSS shall use information that is not in the CF Parameter Set element in received Beacon frames, DMG Beacon frames, or Announce frames only if the BSSID field is equal to the MAC address currently in use by the STA contained in the AP of the BSS or to the MAC address currently in use by the PCP of the PBSS. A non-AP STA in an infrastructure BSS and a non-PCP STA in a PBSS that supports the Multiple BSSID capability shall use other information in received Beacon or DMG Beacon frames only if the BSSID field of the non-AP or non-PCP STA is equal to the MAC address currently in use by the STA contained in the AP or PCP, respectively, of the BSS corresponding to the transmitted BSSID or if the BSSID field of the non-AP or non-PCP STA is equal to one of the nontransmitted BSSIDs. STAs in a non-DMG IBSS shall use information that is not in the CF Parameter Set element in any received Beacon frame for which the IBSS subfield of the Capability field is 1, the content of the SSID element is equal to the SSID of the IBSS, and the TSF value is later than the receiving STAâ€™s TSF timer. Use of this information is specified in 11.1.5. STAs in an MBSS shall use information in received Beacon frames as described in 14.13.3.2. A non-AP STA in which dot11MultiBSSIDActivated is true shall support frame filtering for up to two BSSIDs; one for the transmitted BSSID and one for the nontransmitted BSSID. The STA, when associated with a BSS corresponding to a nontransmitted BSSID, shall discard all Data and Management frames that use the transmitted BSSID as the transmit address, except for Beacon, Probe Response, and TIM broadcast frames. DMG IBSS STAs shall use other information in any received DMG Beacon (excluding those with the Discovery Mode field equal to 1) and Announce frames for which the BSS Type subfield is 1, the content of 1587 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications the SSID element is equal to the SSID of the IBSS, and the TSF value is later than the receiving STAâ€™s TSF timer. Use of this information is specified in 11.1.5. A STA shall ignore the BSS Type field contained in a received DMG Beacon frame if the Discovery Mode field within the DMG Beacon frame is 1. An active DMG STA operating in a BSS shall be ready to receive from its AP or PCP for a period of time of at least dot11MinBHIDuration following the TBTT or expected ATI start time as specified in the last Next DMG ATI element (9.4.2.135) transmitted by the AP or PCP. An active DMG STA that is receive beamforming trained with the AP or PCP shall direct its receive antenna pattern toward the AP or PCP or use a quasi-omni antenna pattern during this time. A non-PCP STA that receives a DMG Beacon frame from a PCP in which the PCP Association Ready field is 0 shall not transmit an Association Request frame addressed to the PCP that transmitted the received DMG Beacon. A non-PCP STA that receives a DMG Beacon frame from a PCP with the PCP Association Ready field set to 1 may transmit an Association Request frame addressed to the PCP that transmitted the received DMG Beacon. 11.1.3.8 Multiple BSSID procedure Implementation of the Multiple BSSID capability is optional for a WNM STA and for a DMG STA. A STA that implements the Multiple BSSID capability has dot11MultiBSSIDImplemented equal to true. When dot11MultiBSSIDImplemented is true, dot11WirelessManagementImplemented shall be equal to true except for a DMG STA, in which case it may be equal to false. A STA in which dot11MultiBSSIDActivated is true is defined as a STA that supports the Multiple BSSID capability. The STA shall set to 1 the Multiple BSSID field of the Extended Capabilities elements that it transmits. The nontransmitted BSSID profile shall include the SSID element (see 9.4.2.2) and Multiple BSSID-Index element (see 9.4.2.74) for each of the supported BSSIDs. The AP or PCP may include all other elements in the nontransmitted BSSID profile. The AP or PCP may include two or more Multiple BSSID elements containing elements for a given BSSID index in one Beacon frame or DMG Beacon frame. If two or more are given, the profile is considered to be the complete set of all elements given in all such Multiple BSSID elements sharing the same BSSID index. Since the Multiple BSSID element is also present in Probe Response frames, an AP or PCP may choose to advertise the complete or a partial profile of a BSS corresponding to a nontransmitted BSSID only in the Probe Response frames. In addition, the AP or PCP may choose to include only a partial list of nontransmitted BSSID profiles in the Beacon frame or DMG Beacon frame or to include different sets of nontransmitted BSSID profiles in different Beacon frames or DMG Beacon frames. When a station receives a Beacon frame or DMG Beacon frame with a Multiple BSSID element that consists of a nontransmitted BSSID profile with only the mandatory elements, it may inherit the complete profile from a previously received Beacon frame, DMG Beacon frame, or Probe Response frame, or it may send a Probe Request frame to obtain the complete BSSID profiles. Each Beacon element not transmitted in a nontransmitted BSSID subelement is inherited from previous Beacon, DMG Beacon, or Probe Response frame in which the element is present, except for the Quiet element, which shall take effect only in the Beacon frame or DMG Beacon frame that contains it and not carry forward as a part of the inheritance. An AP or PCP is not required to include all supported nontransmitted BSSID profiles in a Probe Response frame, and may choose to only include a subset based on any criteria. When a nontransmitted BSSID profile is present in the Multiple BSSID element of the Probe Response frame, the AP or PCP shall include all elements that are specific to this BSS. If any of the optional elements are not present in a nontransmitted BSSID profile, the corresponding values are the element values of the transmitted BSSID. A non-AP and non-PCP STA derives its nontransmitted BSSID value according to 9.4.2.46 and 9.4.2.74. 1588 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Partial Virtual Bitmap field in the transmitted BSSID Beacon frame or DMG Beacon frame shall indicate the presence or absence of traffic to be delivered to all stations associated to a transmitted or nontransmitted BSSID. The first 2n bits of the bitmap are reserved for the indication of group addressed frame for the transmitted and all nontransmitted BSSIDs. The AID space is shared by all BSSs and the lowest AID value that shall be assigned to a station is 2n (see 9.4.2.6). Operation in a non-DMG BSS is subject to the following additional rules. If the Contention Free Period is supported and if more than one BSSâ€™s CFPCount becomes 0 in the same Beacon frame, the AP shall concatenate the Contention Free Periods of all CFPs that coincide and shall not transmit a CF-End or CF- End+Ack frame until the end of the concatenated CFP, indicated with a single CF-End or CF-End+Ack frame, if required. The CF Parameter Set in the transmitted BSSID contains times that are an aggregate of CFP times of the nontransmitted BSSIDs. Multiple BSSID rate selection is defined in 10.7.8. 11.1.3.9 TSF timer accuracy A non-DMG STAâ€™s TSF timer shall be accurate to within Â±100 ppm. A DMG STAâ€™s TSF timer shall be accurate to within Â±20 ppm. NOTEâ€”The worst-case drift between two non-DMG STAs is, therefore, Â±200 ppm, and between two DMG STAs, Â±40 ppm. Upon receiving a Beacon, a DMG Beacon, or an Announce frame for the BSS, as described in 11.1.3.7, a STA shall update its TSF timer according to the following algorithm â€” Non-DMG STA: The received timestamp value shall be adjusted by adding an amount equal to the receiving STAâ€™s delay through its local PHY components plus the time since the first bit of the timestamp was received at the MAC/PHY interface. In the case of an infrastructure BSS, the STAâ€™s TSF timer shall then be set to the adjusted value of the timestamp. â€” DMG STA: The received timestamp value shall be adjusted by adding an amount equal to the receiving STAâ€™s delay through its local PHY components plus the time since the last data symbol of the PHY header, excluding any guard interval, was received as indicated by the PHY-RXSTART.indication primitive. In the case of an infrastructure BSS or a PBSS, the STAâ€™s TSF timer shall then be set to the adjusted value of the timestamp. In the case of an IBSS, the STAâ€™s TSF timer shall be set to the adjusted value of the received timestamp, if the adjusted value of the timestamp is later than the value of the STAâ€™s TSF timer. When a STA is associated to a BSS with a nontransmitted BSSID, it shall use the TSF from the transmitted BSSID Beacon frame. 11.1.4 Acquiring synchronization, scanning 11.1.4.1 General A STA shall operate in either a Passive Scanning mode or an Active Scanning mode depending on the current value of the ScanMode parameter of the MLME-SCAN.request primitive. NOTEâ€”Active scanning is restricted in some frequency bands and regulatory domains. Upon receipt of the MLME-SCAN.request primitive, a STA shall perform scanning. The SSID parameter indicates the SSID for which to scan. The SSID List parameter indicates one or more SSIDs for which to scan. 1589 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications To become a member of a particular ESS using passive scanning, a STA shall scan for Beacon and DMG Beacon frames containing that ESSâ€™s SSID, returning all Beacon and DMG Beacon frames matching the desired SSID in the BSSDescriptionSet parameter of the corresponding MLME-SCAN.confirm primitive with the appropriate bits in the Capability Information field or DMG Capabilities field indicating whether the Beacon frame or DMG Beacon frame came from an infrastructure BSS, PBSS, or IBSS. If dot11RM- MeasurementPilotActivated is greater than 1, the STA shall additionally scan for Measurement Pilot frames, returning in the BSSDescriptionFromMeasurementPilotSet parameter all Measurement Pilot frames that equal the requested BSSID of the corresponding MLME-SCAN.request primitive and are not already mem- bers of the BSSDescriptionSet. To actively scan, the STA shall transmit Probe Request frames containing the desired SSID or one or more SSID List elements, but a DMG STA might also have to transmit DMG Beacon frames or perform beam- forming training prior to the transmission of Probe Request frames. When the SSID List element is present in the Probe Request frame, one or more of the SSID elements may include a wildcard SSID (see 9.4.2.2). The exact procedure for determining the SSID or SSID List values in the MLME-SCAN.request primitive is not specified in this standard. When a STA scans for a BSS whose AP does not support the SSID List ele- ment, or for a BSS for which AP support of the SSID List element is unknown, the SSID element with an SSID or wildcard SSID shall be included in the MLME-SCAN.request primitive. NOTEâ€”MLME-SCAN.request primitives and resulting Probe Request frames might include a Request element or Extended Request element(s) that can be used to request radio measurement information from the scanned BSSs. Requested radio measurement information from the scanned BSSs is included in the Probe Response frames and in the MLME-SCAN.confirm primitive. Upon completion of scanning, an MLME-SCAN.confirm primitive is issued by the MLME indicating all of the BSS information received. In DMG BSSs, the Active Scan procedure (11.1.4.3) can be used for device discovery prior to initializing or joining a BSS. Upon receipt of an MLME-JOIN.request primitive, the nonmesh STA shall use the synchronization procedure described in 11.1.4.5. The MLME-JOIN.request primitive is not used to start synchronization in an MBSS. The synchronization in an MBSS is described in 14.13. Upon receipt of an MLME-SCAN.request primitive with the SSID parameter equal to the wildcard SSID, the STA shall passively scan for any Beacon, DMG Beacon, or Measurement Pilot frames, or actively transmit Probe Request or DMG Beacon frames containing the wildcard SSID, as appropriate depending upon the value of ScanMode. If a STAâ€™s scanning does not result in finding a BSS with the target SSID and of the target type, or does not result in finding any BSS, the STA may start an IBSS upon receipt of the MLME-START.request primitive. NOTEâ€”Starting an IBSS is restricted in some frequency bands and regulatory domains. When scanning MBSSs, the STA shall process the procedures described in 14.2. When a STA starts a BSS, that STA shall determine the BSSID of the BSS. If the BSSType indicates an infrastructure BSS, then the STA shall start an infrastructure BSS and the BSSID shall be equal to the STAâ€™s dot11StationID. If the BSSType indicates a PBSS, then the STA shall start a PBSS. For both the infrastructure BSS and the PBSS, the value of the BSSID shall remain unchanged, even if dot11StationID is changed after the completion of the MLME-START.request primitive. If the BSSType indicates an IBSS, the STA shall start an IBSS, and the BSSID shall be an individual locally administered IEEE MAC address as defined in Clause 8 of IEEE Std 802-2014. The remaining 46 bits of that MAC address shall be a number selected in a manner that minimizes the probability of STAs generating the same number, even when those STAs are subjected to the same initial conditions. The value SSID parameter shall be used as the SSID of the 1590 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications new BSS. It is important that designers recognize the need for statistical independence among the random number streams among STAs. 11.1.4.2 Passive scanning 11.1.4.2.1 Passive scanning for non-DMG STAs If the ScanType parameter indicates a passive scan, the STA shall listen to each channel scanned for no longer than a maximum duration defined by the MaxChannelTime parameter. 11.1.4.2.2 Passive scanning for DMG STAs Upon receipt of the MLME-SCAN.request primitive with the ScanType parameter set to Passive, a DMG STA shall passively scan for transmissions on each channel specified within the ChannelList parameter of the MLME-SCAN.request primitive. The channel traversal order during passive scanning is implementation specific. That is, the STA shall be in the receive state scanning for a period of time in a channel no less than MinChannelTime and return information on all DMG Beacon frames received matching a particular BSSID or SSID parameters specified in the MLME-SCAN.request primitive. If no DMG beacon scan parameters are specified in the request, then the STA shall return information on all received DMG Beacon frames. If at any time during the scan the STA detects a frame that is not a DMG Beacon frame, the STA shall continue to scan the current channel until the scanning timer expires. After scanning one channel, the STA shall initiate scanning in another channel if at least one channel within the ChannelList parameter has not yet been scanned. When the STA has completed scanning all indicated channels, it returns the scan results via the MLME- SCAN.confirm primitive. 11.1.4.3 Active scanning 11.1.4.3.1 Introduction Active scanning involves the generation of Probe Request frames and the subsequent processing of received Probe Response frames. The details of the active scanning procedures are as specified in the following subclauses. 11.1.4.3.2 Active scanning procedure for a non-DMG STA Upon receipt of the MLME-SCAN.request primitive with ScanType indicating an active scan, a STA shall use the following procedure. For each channel to be scanned: a) Wait until the ProbeDelay time has expired or a PHY-RXSTART.indication primitive has been received. b) Perform the basic access procedure as defined in 10.3.4.2. c) Send a probe request to the broadcast destination address. The probe request is sent with the SSID and BSSID from the received MLME-SCAN.request primitive. d) When the SSID List is present in the invocation of the MLME-SCAN.request primitive, send zero or more Probe Request frames, to the broadcast destination address. Each probe request is sent with an SSID indicated in the SSID List and the BSSID from the MLME-SCAN.request primitive. The basic access procedure (10.3.4.2) is performed prior to each probe request transmission. 1591 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications e) Initialize a timer to 0 and start it running. f) If a PHY-CCA.indication (BUSY) primitive is not received before the timer reaches MinChannelTime, proceed to step h). g) Process all probe responses received until the timer reaches MaxChannelTime, constructing BSSDescriptions corresponding to the probe responses that match the criteria specified in the MLME-SCAN.request primitive. h) Set the NAV to 0 and scan the next channel. See Figure 11-4 for non-DMG STAs. Figure 11-4â€”Probe response When all channels in the ChannelList have been scanned, the MLME shall issue an MLME-SCAN.confirm primitive with the BSSDescriptionSet containing all the BSSDescriptions constructed during the scan. 11.1.4.3.3 Active scanning procedure for a DMG STA Upon receipt of the MLME-SCAN.request primitive with ScanType indicating an active scan, a DMG STA shall use the following procedure. For each channel to be scanned: a) Wait until the ProbeDelay time has expired or a PHY-RXSTART.indication primitive has been received. b) Initialize a timer to 0 and start it running. c) If the DiscoveryMode parameter of the MLME-SCAN.request primitive is equal to 1, generate DMG Beacon frames as (described in 11.1.3.4) for a period no longer than MaxChannelTime. d) If a DMG Beacon frame is received before the timer reaches MaxChannelTime and beamforming training is required (see 10.38), perform beamforming training defined in 10.38.5. e) Perform the basic access procedure defined in 10.3.4.2 f) If an SSW-Feedback frame is transmitted or received in step d), then: 1) Send a probe request to the broadcast destination address or â€” Following the transmission of an SSW-Feedback frame, send a probe request to the MAC address of the STA addressed by the SSW-Feedback frame. â€” Optionally, following the reception of an SSW-Feedback frame, send a probe request to the MAC address of the STA that transmitted the SSW-Feedback frame. 1592 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications In all probe requests sent under step f) 1), the probe request is sent with the SSID and BSSID from the received MLME-SCAN.request primitive and includes the DMG Capabilities element. The basic access procedure (10.3.4.2) is performed prior to the probe request transmission. 2) When the SSID List is present in the invocation of the MLME-SCAN.request primitive, send zero or more probe requests to the broadcast destination address. Each probe request is sent with an SSID indicated in the SSID List and the BSSID from the received MLME- SCAN.request primitive and includes the DMG Capabilities element. The basic access procedure (10.3.4.2) is performed prior to each probe request transmission. g) If an SSW-Feedback frame is neither transmitted nor received in step d), then: 1) Optionally send a probe request to the broadcast destination address. The probe request is sent with the SSID and BSSID from the received MLME-SCAN.request primitive and includes the DMG Capabilities element. The basic access procedure (10.3.4.2) is performed prior to the probe request transmission. 2) When the SSID List is present in the invocation of the MLME-SCAN.request primitive, send zero or more probe requests to the broadcast destination address. Each probe request is sent with an SSID indicated in the SSID List and the BSSID from the MLME-SCAN.request primitive and includes the DMG Capabilities element. The basic access procedure (10.3.4.2) is performed prior to each probe request transmission. h) Process all probe responses received until the timer reaches MaxChannelTime, constructing BSSDescriptions corresponding to the probe responses that match the criteria specified in the MLME-SCAN.request primitive. i) Set the NAV to 0 and scan the next channel. When all channels in the ChannelList have been scanned, the MLME shall issue an MLME-SCAN.confirm primitive with the BSSDescriptionSet containing all the BSSDescriptions constructed during the scan. See Figure 11-5 for DMG STAs that generate DMG Beacon frames with the Discovery Mode field set to 1. STA A STA B DMG Beacon (Discovery Mode = 1) Beacon DMG Beacon interval length DMG Beacon (Discovery Mode = 1) is randomized (Discovery Mode = 1) SLS (and BRP (optional)) STA found Probe Request Ack Single TX in Single TX in STA B Probe Response STA A direction Ack direction Figure 11-5â€”Active scanning for DMG STAs 1593 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.1.4.3.4 Criteria for sending a probe response A STA that receives a Probe Request frame shall not respond if any of the following apply: a) The STA does not match any of the following criteria: 1) The STA is an AP. 2) The STA is an IBSS STA. 3) The STA is a mesh STA. 4) The STA is a DMG STA that is not a member of a PBSS and that is performing active scan as defined in 11.1.4.3.3. 5) The STA is a PCP. b) The Address 1 field of the Probe Request frame contains an individual address that is not the MAC address of the STA. c) The STA is a non-AP STA in an infrastructure BSS and the Address 1 field of the Probe Request frame contains the broadcast address. d) The STA is a non-PCP STA in a PBSS and the Address 1 field of the Probe Request frame contains the broadcast address. e) The STA is in an IBSS and did not transmit a Beacon or DMG Beacon frame since the last TBTT, and the Address 1 field of the Probe Request frame contains the broadcast address. f) The STA is a mesh STA and either of the following criteria are met: 1) The Probe Request frame does not contain a Mesh ID element. 2) The Mesh ID element in the Probe Request frame is present but does not contain the wildcard Mesh ID and does not match the Mesh ID of the MBSS with which the STA is peered. g) The STA is not a mesh STA and none of the following criteria are met: 1) The SSID in the Probe Request frame is the wildcard SSID. 2) The SSID in the Probe Request frame matches the SSID of the STAâ€™s. 3) The SSID List element is present in the Probe Request frame and includes the SSID of the STAâ€™s BSS. h) The STA is not a mesh STA and the Address 3 field of the Probe Request frame does not contain a wildcard BSSID and does not match the BSSID of the STAâ€™s BSS. i) The STA has dot11InterworkingServiceActivated equal to true and the Probe Request frame con- tains an Interworking element and an Extended Capabilities element whose Interworking field con- tains the value 1, and at least one of the following criteria is not met: 1) The HESSID field of the Interworking element is absent, or is present and contains the wildcard HESSID or matches the HESSID field of the InterworkingInfo parameter of the last MLME-START.request or MLME-JOIN.request primitive. 2) The Access Network Type field of the Interworking element contains the wildcard access network type or matches the access network type of the STA. j) The STA has dot11RadioMeasurementActivated equal to true and the Probe Request frame contains a DSSS Parameter Set element in which the Current Channel field contains a value that is not the same as dot11CurrentChannel. k) The STA is a DMG STA and the transmit antenna of the DMG STA is not trained to transmit to the STA from which the Probe Request frame was received. An AP shall remain in the awake state, and shall respond to probe requests, subject to the criteria above. An IBSS STA that sent a Beacon or DMG Beacon frame shall remain in the awake state, and shall respond to probe requests, subject to the criteria above, until a Beacon or DMG Beacon frame with the BSSID of the STAâ€™s IBSS is received. 1594 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A mesh STA or PCP that is awake shall respond to probe requests, subject to the criteria above. NOTEâ€”A result of the procedures defined in this subclause is that: â€” Infrastructure BSS: the AP is always awake to respond to probe requests. â€” IBSS: at least one STA will be awake to respond to probe requests. More than one STA might respond to any given probe request, particularly when more than one STA transmitted a Beacon or DMG Beacon frame following the most recent TBTT, either due to not receiving successfully a previous Beacon or DMG Beacon frame or due to collisions between beacon transmissions. â€” MBSS or PBSS: At any given time it might be the case that no STA is awake to respond to probe requests. 11.1.4.3.5 Contents of a probe response A STA that responds to a Probe Request frame according to 11.1.4.3.4 shall transmit a Probe Response frame individually addressed to the STA that transmitted the Probe Request frame. If there was a Request element or Extended Request element in the Probe Request frame, then: â€” Each element that is listed in the Request element or Extended Request element(s) and that is supported by the STA shall be included in the Probe Response frame. An element that is listed in a Request element or Extended Request element and that is not supported by the STA shall not be included. â€” Elements that would not have been included otherwise shall be included after all of the elements that would have been included even in the absence of the Request element or Extended Request element. â€” Elements that would have been included even in the absence of the Request element or Extended Request element shall be included in their normal position (see Table 9-34), and may be included again after all of the elements that would have been included even in the absence of the Request element. NOTEâ€”An element that would necessarily be included anyway is not expected to be requested. â€” Elements after all of the elements that would have been included even in the absence of the Request element or Extended Request element shall be included in the order that they appear in the (Extended) Request element(s) of the Probe Request frame. â€” If dot11RadioMeasurementActivated is true and the RCPI element was requested, an RCPI element containing the RCPI of the Probe Request frame shall be included. If no measurement result is available, the RCPI value shall be set to indicate â€œMeasurement not availableâ€ (see Table 9-154). â€” If dot11RadioMeasurementActivated is true and the RSNI element was requested, an RSNI element containing the RSNI of the Probe Request frame shall be included. If no measurement result is available, the RSNI value shall be set to indicate that a measurement is not available. (see 9.4.2.41). 11.1.4.3.6 PCP selection in a PBSS The PCP selection procedure is performed by the SME when: â€” An MLME-SCAN.confirm primitive is received in response to an MLME-SCAN.request primitive with the value of the ScanType parameter equal to ACTIVE and BSSType parameter equal to PERSONAL â€” There is a PCP handover (see 11.29.2) The decision of whether a STA or its peer STA is the PCP depends on a comparison of their respective PCP factors (self_PCP_factor and peer_PCP_factor).The PCP factor, defined in Figure 11-6, is the concatenation of the value of some of the fields from the DMG Capabilities element transmitted by the STA (see 9.4.2.128). NOTEâ€”According to convention, the least significant bit is the leftmost bit (B0). 1595 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B0 B6 B7 B14 B15 B21 B22 B23 B24 B25 B26 B31 MAX Pseudo- Decentrali Associate Total Static zed AP or Power Reserved Number of TDDTI Reserved d STA Sectors Allocation PCP Source Number s clustering Bits: 7 8 7 1 1 1 1 6 Figure 11-6â€”PCP factor for a DMG STA For each peer STA reported as part of an MLME-SCAN.confirm primitive or considered as part of a PCP handover, the STA proceeds as follows. If the STAâ€™s value of self_PCP_factor is greater than the value of peer_PCP_factor or if the values are equal and the MAC address of the STA is greater than (see 12.7.1 for MAC address comparison) the MAC address of the peer STA contained in the peer STAâ€™s DMG Capabilities element, the STA becomes a candidate PCP. Otherwise, the STA does not become a candidate PCP. Subclause 11.1.4.4.2 specifies the rules followed by the SME of a candidate PCP to start a PBSS. 11.1.4.4 Initializing a BSS 11.1.4.4.1 General Upon receipt of an MLME-START.request primitive, a STA shall determine the BSSâ€™s BSSID (as described in 11.1.4), select channel synchronization information, select a beacon period, initialize and start its TSF timer, and begin transmitting Beacon frames if the STA is a non-DMG STA or DMG Beacon frames if the STA is a DMG STA. See 9.3.3.3 for the description of a Beacon frame, and see 9.3.4.2 for the description of a DMG Beacon frame. 11.1.4.4.2 Initializing a DMG BSS Prior to choosing a suitable operating channel and starting a BSS, the SME of a DMG STA should perform a channel scan to ascertain the quality of each channel that the STA supports. The rules for choosing a suitable operating channel are implementation specific and might be subject to regulatory requirements. When a STAâ€™s MAC receives an MLME-START.request primitive, the MAC shall attempt to start a BSS. The STA may listen for a duration of aMinChannelTime, the listening duration, in the channel specified by the SME in the request. If the STA determines the channel is suitable for BSS operation at the end of this listening duration, the STA initializes the BSS by commencing transmission of DMG Beacon frames according to 11.1.3.3 in the case of a PBSS or an infrastructure BSS and according to 11.1.3.5 in the case of an IBSS. If AP or PCP clustering is in use on the selected channel, the DMG Beacon frame transmission by an AP or PCP commences following the additional rules described in 10.37. If the STA determines that no channels are suitable or available, it responds with an MLME- START.confirm primitive with a ResultCode of NOT_SUPPORTED. Otherwise, the MLME shall respond with an MLME-START.confirm primitive with a ResultCode of SUCCESS. The SME should issue an MLME-START.request primitive with BSSType parameter equal to PERSONAL for at least one network in which the STA becomes a candidate PCP as defined in 11.1.4.3.6. If the STA becomes a candidate PCP of more than one network, the SME may issue an MLME-START.request primitive with BSSType parameter equal to PERSONAL for any of the remaining networks. In either case, the MLME-START.request primitive should be issued no later than 4Ã—aMaxBIDuration after the MAC receives an MLME-SCAN.confirm primitive. 1596 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The SME should not issue an MLME-START.request primitive with BSSType parameter equal to PERSONAL for networks in which the STA does not become a candidate PCP as defined in 11.1.4.3.6. If the SME issues the MLME-START.request primitive under this circumstance, it shall not be issued if less than 4Ã—aMaxBIDuration has elapsed since the MAC received the MLME-SCAN.confirm primitive. 11.1.4.5 Synchronizing with a BSS Upon receipt of an MLME-JOIN.request primitive, a STA shall adopt the BSSID in the request. Upon receipt of a Beacon frame from the BSS, a STA shall adopt the TSF timer value of the parameters in the Beacon frame using the algorithm described in 11.1.3.9, and the MLME shall issue an MLME- JOIN.confirm primitive indicating the operation was successful. In addition to these synchronization parameters, a STA joining an infrastructure BSS adopts each of the parameters found in the SelectedBSS parameter of the MLME-JOIN.request primitive except Local time, Capability Information, BSSBasicRateSet parameters, and HT Capabilities element. Local time is not adopted but is used as a local variable in adopting the TSF as described in 11.1.3.9. The Capability Information reflects the capabilities of the sender and is not adopted but may be used to determine local configuration or behavior. The BSSBasicRateSet parameter is not adopted but may determine if the STA can join the BSS. If the JoinFailureTimeout timer expires prior to the receipt of a Beacon frame from the BSS, the MLME shall issue an MLME-JOIN.confirm primitive indicating the operation was unsuccessful. If dot11MultiDomainCapabilityActivated is true, a STA that is joining an infrastructure BSS and receives a Beacon or Probe Response frame containing a Country element shall adopt the applicable parameters included in that Country element, and the dot11RegDomainsSupportedEntry shall be set to Other. In addition to adopting the synchronization parameters as described in the first paragraph of this subclause, a STA joining an IBSS shall adopt each of the parameters found in the SelectedBSS parameter of the MLME- JOIN.request primitive according to the rule found for that parameter in the â€œIBSS adoptionâ€ column of the matching row of the BSSDescription table found in 6.3.3.3.2 when those parameters exist at the STA. Parameters adopted by a STA when joining an IBSS shall not be changed by the STA except when adopting parameters following the reception of a Beacon frame with a later timestamp as described in 11.1.5. When an IBSS contains STAs with a mix of STA capabilities, e.g., non-HT and HT, a STA in the IBSS adopts the behavioral parameters of the last beacon with the highest TSF (e.g., a HT STA does not continue use of HT and does not include an HT Operations element in its beacons). In addition to the table entries in 6.3.3.3.2, if dot11MultiDomainCapabilityActivated is true, a STA that is joining an IBSS and receives a Beacon or Probe Response frame containing a Country element shall adopt the applicable parameters included in that Country element, and the dot11RegDomainsSupportedEntry shall be set to Other. A DMG STA shall be capable of transmitting DMG Beacon frames. A DMG STA obtains the operational parameters in use by its AP or PCP through the DMG Operation Information field of the DMG Operation element. A DMG STA shall update the value of its local MIB variables with the corresponding field value transmitted by its AP or PCP within the DMG BSS Parameter Configuration field of the DMG Operation element (9.4.2.129). Except for the prefix â€œdot11â€ used in the MIB variable naming convention, the name of the field is the same as the name of the corresponding MIB variable. 11.1.4.6 Operation of Supported Rates and BSS Membership Selectors element and Extended Supported Rates and BSS Membership Selectors element The Supported Rates and BSS Membership Selectors element and Extended Supported Rates and BSS Membership Selectors element in Beacon and Probe Response frames is used by STAs in order to avoid 1597 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications associating with a BSS if they do not support all of the data rates in the BSSBasicRateSet parameter or all of the BSS membership requirements in the BSSMembershipSelectorSet parameter. If the combined total of the number of rates in the OperationalRateSet parameter and the number of BSS membership selectors does not exceed eight, the Extended Supported Rates and BSS Membership Selectors element is optional for inclusion in all of the frame types that include the Supported Rates and BSS Membership Selectors element. If the combined total of the number of rates in the OperationalRateSet parameter and the number of BSS membership selectors exceeds eight, an Extended Supported Rates and BSS Membership Selectors element shall be included to specify the remaining supported rates and BSS membership selectors in all of the frame types that include the Supported Rates and BSS Membership Selectors element. The Supported Rates and BSS Membership Selectors element in Beacon and Probe Response frames is delivered to the management entity in a STA via the BSSBasicRateSet parameter in the MLME- SCAN.confirm primitive. The BSS membership selector information in Beacon and Probe Response frames is delivered to the management entity in a STA via the BSSMembershipSelectorSet parameter in the MLME-SCAN.confirm primitive. Together, these parameters are used by the management entity in a STA to avoid associating with a BSS if the STA cannot receive and transmit all of the data rates in the BSSBasicRateSet parameter or does not support all of the features represented in the BSSMembershipSelectorSet parameter. NOTEâ€”A STA that was implemented before the existence of the BSSMembershipSelectorSet parameter interprets each BSS membership selector in the Supported Rates and BSS Membership Selectors element that is contained in the BSSMembershipSelectorSet parameter of the transmitting STA as though it were a rate from the BSSBasicRateSet parameter. The value of each BSS membership selector does not match a rate that is known to the STA and, therefore, the management entity in the STA avoids associating with the BSS because it determines that the STA cannot receive or transmit at what appears to be a required rate. A STA that is implemented after the existence of the BSSMembershipSelectorSet parameter includes each octet of the Supported Rates and BSS Membership Selectors element that is encoded with the MSB (bit 7) equal to 1 and that it does not recognize as a rate in its BSSMembershipSelectorSet parameter. The STA then determines if it can support all of the features represented in its BSSMembershipSelectorSet parameter before attempting to join the network. If some BSSMembershipSelectorSet parameter values are not recognized by the STA, the STA does not attempt to join the network. 11.1.5 Adjusting STA timers A STA in an infrastructure BSS or PBSS shall adopt the TSF timer value in a Beacon, Probe Response, DMG Beacon, or Announce frame transmitted by the BSSâ€™s AP or PCP. The STA shall use the algorithm specified in 11.1.3.9. To response to an MLME-JOIN.request primitive, a STA joining an IBSS shall initialize its TSF timer to 0 and shall not transmit a Beacon, Probe Response, or DMG Beacon frame until it receives from a member of the IBSS a Beacon, Probe Response or DMG Beacon frame that has a matching SSID. Consequently, the STA joining an IBSS adopts the timer from the next Beacon, Probe Response, or DMG Beacon frame from its IBSS. All Beacon, Probe Response, DMG Beacon, and Announce frames carry a Timestamp field. A STA receiving such a frame from another IBSS STA with the same SSID shall compare the Timestamp field with its own TSF time. If the Timestamp field of the received frame is later than its own TSF timer, a non-DMG STA in the IBSS shall adopt all parameters contained in the Beacon frame according to the rule for that parameter found in the â€œIBSS adoptionâ€ column of the matching row of the BSSDescription table found in 6.3.3.3.2. A DMG IBSS STA shall adopt each parameter contained in the DMG Beacon or Announce frames. Parameters adopted by a STA due to the receipt of a later timestamp shall not be changed by the 1598 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STA except when adopting parameters due to a subsequently received Beacon, DMG Beacon, or Announce frame with a later timestamp. 11.1.6 Terminating a BSS At any time an infrastructure BSS or PBSS may be terminated. At any time a STA may cease support for an IBSS that it formed. Upon receipt of an MLME-STOP.request primitive, a STA shall stop transmitting Beacon, Probe Response, DMG Beacon, and Announce frames and deauthenticate all associated STAs. 11.1.7 Supported rates and extended supported rates advertisement A STA shall include the rates from its OperationalRateSet parameter and the rates from the BSSBasicRateSet parameter and the BSS membership selectors from the BSSMembershipSelectorSet parameter in frames it transmits containing Supported Rates and BSS Membership Selectors elements and Extended Supported Rates and BSS Membership Selectors elements according to the rules described in this subclause, except that a non-AP STA may omit the HT and VHT BSS membership selectors, as the (V)HT capabilities are indicated through the presence of a (V)HT Capabilities element. A STA that supports a combined total of eight or fewer data rates and BSS membership selectors may include the Extended Supported Rates and BSS Membership Selectors element in all of the frame types that include the Supported Rates and BSS Membership Selectors element. A STA that supports a combined total of the number of rates in the OperationalRateSet parameter and the number of BSS membership selectors that exceeds eight shall generate an Extended Supported Rates and BSS Membership Selectors element to specify the supported rates and BSS membership selectors that are not included in the Supported Rates and BSS Membership Selectors element. If the BSSMembershipSelectorSet parameter contains at least one BSS membership selector, then the STA shall include at least one BSS membership selector value from the BSSMembershipSelectorSet parameter in the Supported Rates and BSS Membership Selectors element. NOTEâ€”Inclusion of at least one BSS membership selector in the Supported Rates and BSS Membership Selectors element causes a receiving STA that does not process the Extended Supported Rates and BSS Membership Selectors element to still receive a BSS membership selector (which it considers to be a basic rate) that it does not support. Any values from the BSSMembershipSelectorSet parameter that are not transmitted in the Supported Rates and BSS Membership Selectors element are transmitted in the Extended Supported Rates and BSS Membership Selectors element. 11.2 Power management 11.2.1 General A STA can be in one of two power states: â€” Awake: STA is fully powered. â€” Doze: STA is not able to transmit or receive and consumes very low power. The manner in which a STA transitions between power states is determined by its power management mode and reflected in dot11PowerManagementMode. The power management mode of a STA is selected by the PowerManagementMode parameter of the MLME-POWERMGT.request primitive or MLME-MESHPOWERMGT.request primitive. Once the STA updates its power management mode, the MLME shall issue an MLME-POWERMGT.confirm primitive or MLME-MESHPOWERMGT.confirm primitive respectively indicating the success of the operation. 1599 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications When MSDUs or A-MSDUs are buffered for power management purposes, the information in the MAC service tuple(s) for the MSDU(s) shall be maintained (and reordered) as a unit. 11.2.2 Bufferable MMPDUs MMPDUs are categorized as bufferable or nonbufferable, as shown in Table 11-1. Bufferable MMPDUs are eligible to be queued for delivery using a power-saving mechanism. Nonbufferable MMPDUs are delivered without reference to a power-saving mechanism. Table 11-1â€”Bufferable/nonbufferable classification of MMPDUs Description Classification An MMPDU that is carried in one or more Action (except for Fine Timing Bufferable Measurement frame and Fine Timing Measurement Request frame), Disassociation, or Deauthentication frame An individually addressed MMPDU that is carried in one or more Probe Bufferable Response frames and that is sent in an IBSS in response to an individually addressed Probe Request frame. All other MMPDUs. Nonbufferable 11.2.3 Power management in a non-DMG infrastructure network 11.2.3.1 General A STA that is associated with an AP and that changes power management mode shall inform the AP of this fact using the Power Management subfield within the Frame Control field of transmitted frames. The STA shall remain in its current power management mode until it informs the AP of a power management mode change via a frame exchange that includes an acknowledgment from the AP. Power management mode shall not change during any single frame exchange sequence, as described in Annex G. NOTEâ€”This means the Power Management subfield is the same for all MPDUs in an A-MPDU. The AP shall buffer individually addressed BUs addressed to STAs operating in a PS mode. These buffered BUs shall be transmitted only at designated times. If any STA in its BSS is in PS mode, the AP shall buffer all non-GCR-SP group addressed BUs and deliver them to all STAs immediately following the next Beacon frame containing a DTIM transmission. The STAs that currently have buffered BUs (excluding those BUs for a STA associated with ACs that are U- APSD delivery-enabled when not all ACs are delivery-enabled by that STA) within the AP are identified in a TIM, which shall be included as an element within all Beacon frames generated by the AP. A STA shall determine that a BU is buffered for it by receiving and interpreting a TIM. A STA operating in PS mode that is not in WNM sleep mode shall periodically listen for Beacon frames, as determined by the ListenInterval parameter of the MLME-ASSOCIATE.request or MLME- REASSOCIATE.request primitive and the ReceiveDTIMs parameter of the MLME-POWERMGT.request primitive. WNM sleep mode enables an extended power save mode for non-AP STAs in which a non-AP STA need not listen for every DTIM Beacon frame, and need not perform GTK/IGTK updates. STAs in WNM sleep 1600 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications mode can wake up as infrequently as once every WNM sleep interval to check whether the corresponding TIM bit is set or group addressed traffic is pending. NOTEâ€”A STA may use both WNM sleep mode and PS mode simultaneously. The Power Management subfield of the Frame Control field may be set to 0 or 1 within a frame sent by a STA in WNM sleep mode. When a STA is in WNM sleep mode and in PS mode, the AP buffers unicast frames according to the traffic filtering agreement established between the AP and STA, as specified in 11.24.12.2. When a STA is in WNM sleep mode but not in PS mode, the traffic filtering agreement between the AP and STA and the timer for the WNM sleep interval remain in place, and the AP queues for nonbuffered delivery all matched frames (i.e., matched by the traffic filtering agreement) destined to the STA. In a BSS operating under the DCF or EDCA, or during the CP of a BSS using the PCF, upon determining that a BU is currently buffered in the AP, a STA operating in the normal (non-APSD) PS mode transmits a PS-Poll frame to the AP, which responds with the corresponding buffered BU immediately, or acknowledges the PS-Poll frame and responds with the corresponding BU at a later time. If the TIM indicating the buffered BU is sent during a CFP, a CF-Pollable STA operating in the PS mode does not send a PS-Poll frame, but remains active until the buffered BU is received (or the CFP ends). A non-AP QoS STA may be in PS mode before the setup of DLS or block ack. Once DLS is set up, both of the QoS STAs associated with a DLS link suspend the PS mode and shall be awake. BUs for a TID without a schedule are sent using Normal Ack following a PS-Poll frame as described in rest of 11.2.3. Uplink block ack agreements, block ack agreements for any TID with a schedule, and any block ack agreements to APSD STAs continue to operate normally. NOTEâ€”When a STA is in normal (non-APSD) PS mode, the rules described in 11.2.3.6 for PS-Poll operation apply to any downlink block ack agreement without an associated schedule. An (A-)MSDU delivered for this block ack agreement in response to the PS-Poll frame might be delivered in an A-MPDU. 11.2.3.2 STA power management modes A non-AP STA can be in one of two power management modes: â€” Active mode: The STA receives and transmits frames at any time. The STA remains in the awake state. â€” Power save (PS) mode: The STA enters the awake state to receive or transmit frames. The STA remains in the doze state otherwise. A non-AP STA shall be in active mode upon (re)association. A STA that has transmitted a frame to an AP with which it is not associated and from which it expects a response shall remain in the awake state until such a response is received or until the procedure has timed out. To change power management modes a STA shall inform the AP by completing a successful frame exchange (as described in Annex G) that is initiated by the STA. This frame exchange shall include a Management frame, Extension frame or Data frame from the STA, and an Ack or a BlockAck frame from the AP. The Power Management subfield(s) in the Frame Control field of the frame(s) sent by the STA in this exchange indicates the power management mode that the STA shall adopt upon successful completion of the entire frame exchange, except where the Power Management subfield is reserved (see 9.2.4.1.7). A non-AP STA shall not change power management mode using a frame exchange that does not receive an Ack or BlockAck frame from the AP, or using a BlockAckReq frame. NOTE 1â€”A PS-Poll frame exchange does not necessarily result in an Ack frame from the AP, so a non-AP STA cannot change power management mode using a PS-Poll frame. 1601 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NOTE 2â€”The Power Management subfield is ignored in frame exchanges initiated by the AP. A STA that is changing from doze to awake state in order to transmit shall perform CCA until a frame is detected by which it can set its NAV, or until a period of time indicated by the NAVSyncDelay from the MLME-JOIN.request primitive has transpired. To change power management mode, a STA that is coordinated by an MM-SME shall inform the AP through a successful frame exchange initiated by the STA. The Power Management subfield in the Frame Control field of the frame sent by the STA in this exchange indicates the power management mode that the STAs coordinated by the MM-SME and advertised in the MMS element sent by the STA shall adopt upon successful completion of the entire frame exchange. To change the power management mode of the coordinated STA, the frame may be sent using any of the MMSLs within the MMSL cluster established with the AP. 11.2.3.3 AP TIM transmissions The TIM shall identify the STAs for which traffic is pending and buffered in the AP. This information is coded in a partial virtual bitmap, as described in 9.4.2.6. In addition, the TIM contains an indication whether group addressed traffic is pending. Every STA is assigned an AID by the AP as part of the association process. AID 0 (zero) is reserved to indicate the presence of buffered non-GCR-SP group addressed BUs. The AP shall identify those STAs for which it is prepared to deliver42 buffered BUs by setting bits in the TIMâ€™s partial virtual bitmap that correspond to the appropriate AIDs. 11.2.3.4 TIM types Two different TIM types are distinguished: TIM and DTIM. After a DTIM, the AP shall transmit buffered non-GCR-SP group addressed BUs, before transmitting any individually addressed frames. The AP shall transmit a TIM with every Beacon frame. Every dot11DTIMPeriod, a TIM of type DTIM is transmitted within a Beacon frame, rather than an ordinary TIM. Figure 11-7 illustrates the AP and STA activity under the assumptions that no PCF is operating and that a DTIM is transmitted once every three TIMs. The top line in Figure 11-7 represents the time axis, with the beacon interval shown together with a DTIM Interval of three beacon intervals. The second line depicts AP activity. The AP schedules Beacon frames for transmission every beacon interval, but the Beacon frames may be delayed if there is traffic at the TBTT. This is indicated as â€œbusy mediumâ€ on the second line. For the purposes of this figure, the important fact about Beacon frames is that they contain TIMs, some of which are DTIMs. Note that the second STA with ReceiveDTIMs equal to false does not power-on its receiver for all DTIMs. The third and fourth lines in Figure 11-7 depict the activity of two STAs operating with different power management requirements. Both STAs power-on their receivers when they need to listen for a TIM. This is indicated as a ramp-up of the receiver power prior to the TBTT. The first STA, for example, powers up its receiver and receives a TIM in the first Beacon frame; that TIM indicates the presence of a buffered BU for the receiving STA. The receiving STA then generates a PS-Poll frame, which elicits the transmission of the buffered BU from the AP. Non-GCR-SP group addressed BUs are sent by the AP subsequent to the transmission of a Beacon frame containing a DTIM. The DTIM is indicated by the DTIM count field of the TIM element having a value of 0. 42 How the AP or mesh STA determines the traffic it is prepared to deliver is outside the scope of this standard. 1602 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Figure 11-7â€”Infrastructure power management operation (no PCF operating) 11.2.3.5 Power management with APSD 11.2.3.5.1 Power management with APSD procedures QoS APs capable of supporting automatic power save delivery (APSD) shall signal this capability through the use of the APSD subfield in the Capability Information field in Beacon, Probe Response, and (Re)Association Response frames. QoS STAs use the Power Management subfield in the Frame Control field of a frame to indicate whether it is in active or PS mode. As APSD is a mechanism for the delivery of downlink BUs to power-saving STAs, the frames transmitted by a STA in PS mode that is using APSD have the Power Management subfield in the Frame Control field set to 1, thereby causing buffering to take place at the AP. APSD defines two delivery mechanisms, namely unscheduled APSD (U-APSD) and scheduled APSD (S-APSD). STAs may use U-APSD to have some or all of their BUs delivered during unscheduled SPs. STAs may use S-APSD to schedule delivery of some or all of their BUs during scheduled SPs. If there is no unscheduled SP in progress, the unscheduled SP begins when the AP receives a trigger frame from a STA, which is a QoS Data or QoS Null frame using an AC the STA has configured to be trigger- enabled. An A-MPDU that contains one or more trigger frames acts as a trigger frame. An unscheduled SP ends after the AP has attempted to transmit at least one BU using a delivery-enabled AC and destined for the STA, but no more than the number indicated in the Max SP Length field of the QoS Capability element of the STAâ€™s (Re)Association Request frame if the field has a nonzero value. NOTEâ€”The transmission of one or more fragments of a BU counts as the transmission of one BU for the purposes of the constraint indicated by the Max SP Length field. By setting the EOSP subfield to 1 in the last frame sent during the SP, an unscheduled SP may be terminated before the maximum number of BUs in the SP has been reached. The times at which an AP may transmit during an unscheduled SP might be constrained by the U-APSD coexistence mechanism (see 11.2.3.5.2). In order to configure an AP to deliver BUs during an unscheduled SP, a STA designates one or more of its ACs to be delivery-enabled and one or more of its AC to be trigger-enabled. A STA may configure an AP to use U-APSD using two methods. First, the STA may set individual U-APSD Flag bits in the QoS Info subfield of the QoS Capability element carried in (Re)Association Request frames. When a U-APSD Flag bit is 1, it indicates that the corresponding AC is both delivery- and trigger-enabled. When all four U-APSD 1603 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Flag subfields are equal to 1 in (Re)Association Request frames, all of the ACs associated with the STA are trigger- and delivery-enabled during (re)association. When all four U-APSD Flag subfields are equal to 0 in (Re)Association Request frames, none of the ACs associated with the STA is trigger- or delivery-enabled during (re)association. Alternatively, the STA may designate one or more AC as trigger-enabled and one or more AC as delivery- enabled by sending an ADDTS Request frame per AC to the AP with the APSD subfield set to 1 and the Schedule subfield set to 0 in the TS Info field in the TSPEC element. APSD settings in a TSPEC request take precedence over the static U-APSD settings carried in the QoS Capability element. In other words, a TSPEC request overwrites any previous U-APSD setting of an AC. NOTEâ€”Such an ADDTS Request frame can be sent regardless of the ACM setting of the AC. A STA may set an AC to be trigger- or delivery-enabled for its own use by setting up TSPECs with the APSD subfield set to 1 and the Schedule subfield set to 0 in the uplink or downlink direction, respectively. An uplink TSPEC plus a downlink TSPEC, or a bidirectional TSPEC with the APSD subfield equal to 1 and the Schedule subfield equal to 0, makes an AC both trigger- and delivery-enabled. An uplink TSPEC plus a downlink TSPEC, or a bidirectional TSPEC with the APSD and the Schedule subfields both equal to 0, makes an AC neither trigger- nor delivery-enabled. A scheduled SP starts at fixed intervals of time specified in the Service Interval field.The following rules describe scheduled SP operation: a) If the scheduled Service Interval field equals 0 (for example, with the GCR-A delivery method), the scheduled SP starts from the service start time without a fixed delivery interval. b) To use a scheduled SP for a TS when the access policy is controlled channel access, a STA shall send an ADDTS Request frame to the AP with the APSD subfield of the TS Info field in the TSPEC element set to 1. c) To use a scheduled SP for a TS for an AC when the access policy is contention based channel access, a STA shall send an ADDTS Request frame to the AP with the APSD and Schedule subfields of the TS Info field in the TSPEC element both set to 1. If the APSD mechanism is supported by the AP and the AP accepts the corresponding ADDTS Request frame from the STA, the AP shall respond to the ADDTS Request frame with a response containing the Schedule element indicating that the requested service can be accommodated by the AP. d) When the access policy is contention based channel access for a GCR group addressed stream, a scheduled SP is set up according to 11.24.16.3.3. The first scheduled SP starts when the lower order 4 octets of the TSF timer equals the value specified in the Service Start Time field. e) If the SI is nonzero, a STA using scheduled SP shall first wake up at the service start time to receive downlink individually addressed and/or GCR-SP group addressed BUs buffered and/or to receive polls from the AP/HC. The STA shall wake up subsequently at a fixed time interval equal to the SI. f) The AP may modify the non-GCR service start time by indicating so in the Schedule element in a successful ADDTS Response frame (which is sent in response to an ADDTS Request frame) and in Schedule frames (which are sent at other times). g) The AP may modify the GCR service start time by indicating so in the Schedule element in the GCR Response subelements (see 9.4.2.89 and 11.24.16.3.4). h) In both non-GCR and GCR cases, the service start time shall be updated (using the previously described service start time modification procedures) whenever the upper 4 octets of the TSF timer change. A scheduled SP begins at the scheduled wakeup time that corresponds to the SI and the service start time indicated in the Schedule element sent in response to a TSPEC or GCR Request. If the SI is nonzero, the STA shall wake up at a subsequent time when 1604 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications (TSF â€“ Tservice-start) mod SImin = 0. where Tservice-start is the service start time SImin is the minimum SI. If the SI is nonzero, a scheduled SP for a GCR group ends after the AP has attempted to transmit at least one BU associated with the GCR group but no more than the number indicated in the Max SP Length field of the QoS Capability element of the STAâ€™s (Re)Association Request frame. The last frame of the GCR SP shall have the EOSP subfield set to 1. NOTEâ€”The transmission of one or more fragments of a BU counts as the transmission of one BU for the purposes of the constraint indicated by the Max SP Length field. If a scheduled SP overlaps the period during which the AP is required to transmit non-GCR-SP group addressed frames and individually addressed frames to STAs in PS mode that follow a DTIM beacon that has at least 1 bit set to 1 in the partial virtual bitmap of its TIM, the scheduled SP shall be deferred until the AP has transmitted all such buffered frames. When the GCR-A delivery method is used, the scheduled Service Interval field is 0. If a STA has a GCR agreement with an AP for a group address using the GCR-A delivery method, there is no defined end of the scheduled SP. The STA in PS mode shall enter the awake state and shall remain awake in order to receive the buffered group addressed BUs until the AP changes the delivery method of the stream to a method other than GCR-A or until the GCR agreement is canceled. If scheduled SPs are supported in a BSS, a STA may use both unscheduled and scheduled APSD on different ACs at the same time. The GCR-SP delivery method may be used on any AC, irrespective of any non-GCR unscheduled or scheduled APSD flows. When a STA establishes scheduled delivery for an AC the AP shall not transmit BUs using that AC during an SP that is initiated by a trigger frame, and it shall not treat BUs using the AC that are received from the STA as trigger frames. The AP shall decline any ADDTS Request frame that indicates the use of both scheduled and unscheduled APSD to be used on non-GCR-SP frames of the same AC at the same time. APSD shall be used only to deliver individually addressed BUs and GCR-SP BUs to a STA. Non-GCR and non-GCR-SP group addressed BU delivery shall follow the frame delivery rules defined for group addressed BUs as defined in 11.2.3.7. 11.2.3.5.2 U-APSD coexistence A non-AP STA that uses U-APSD might not be able to receive all AP transmitted frames during the service period due to interference observed at the non-AP STA. Although the AP might not observe the same interference, it is able to determine that the frames were not received correctly by the non-AP STA. The U- APSD coexistence capability enables the non-AP STA to indicate a requested transmission duration to the AP for use during U-APSD service periods. Use of the transmission duration enables the AP to transmit frames during the service period and improve the likelihood that the non-AP STA receives the frames when the non-AP STA is experiencing interference. The U-APSD coexistence capability reduces the likelihood that the AP transmits frames during the service period that are not received successfully. A STA whose dot11UAPSDCoexistenceActivated is true shall support U-APSD coexistence and shall set to 1 the U-APSD Coexistence field of the Extended Capabilities elements that it transmits. Otherwise it shall set this field to 0. 1605 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A non-AP STA that is associated to an AP where both have previously advertised support for the U-APSD coexistence capability may transmit ADDTS Request frames including the U-APSD Coexistence element to the AP. The content of the ADDTS Request frame excluding the U-APSD Coexistence element is referred to in subsequent text as the base ADDTS request. Upon reception of the ADDTS Request frame, the AP shall process the content of the base ADDTS request as described in 11.2.3.5. If the AP determines that the base ADDTS request cannot be granted it shall respond as described in 11.2.3.5, without processing the U-APSD Coexistence element. If the AP determines the base ADDTS request can be granted, it shall process the U- APSD Coexistence element. If the AP supports transmission of frames during the U-APSD service period for the duration value specified in the U-APSD Coexistence element Interval/Duration field, it shall grant the ADDTS request as described in 11.2.3.5. Otherwise, it shall deny the ADDTS Request. If the AP has previously granted an ADDTS request with U-APSD coexistence, a non-AP STA that continues using QoS services provided by an ADDTS Request frame without U-APSD coexistence may terminate the use of U-APSD coexistence by transmitting an ADDTS Request frame without the U-APSD Coexistence element. A non-AP STA may terminate use of all QoS services (including U-APSD coexistence) resulting from an ADDTS Request frame by transmitting a DELTS Request frame to the AP. The non-AP STA may transmit multiple ADDTS Request frames to the AP where the last received ADDTS Request frame will override any previously received ADDTS Request frame. An AP that supports U-APSD coexistence and accepts an ADDTS request limits the U-APSD coexistence service period according to the parameters specified in the ADDTS frame U-APSD Coexistence element, and shall transmit frames to the requesting non-AP STA according to the rules in 10.2.4.2 and the following rules: â€” If the non-AP STA specified a nonzero TSF 0 Offset value in the U-APSD Coexistence element, the AP should not transmit frames to the non-AP STA outside of the U-APSD Coexistence Service Period, which begins when the AP receives the U-APSD trigger frame and ends after the transmission period specified by the result of the following calculation: End of transmission period = T + (Interval â€“ ((T â€“ TSF 0 Offset) mod Interval)) where T is the time the U-APSD trigger frame was received at the AP Interval is the UAPSD Coexistence element Duration/Interval field value (see 9.4.2.91) or upon the successful transmission of a frame with the EOSP subfield set to 1, whichever is earlier. â€” If the non-AP STA specified a TSF 0 Offset value of 0 in the U-APSD Coexistence element, the AP should not transmit frames to the non-AP STA outside of the U-APSD coexistence service period, which begins when the AP receives a U-APSD trigger frame and ends after the transmission period specified by the result of the following calculation: End of transmission period = T + Duration where T is the time the U-APSD trigger frame was received at the AP Duration is the UAPSD Coexistence element Duration/Interval field value (see 9.4.2.91) or upon the successful transmission of a frame with the EOSP subfield set to 1, whichever is earlier. Throughout the U-APSD coexistence service period, the AP shall set the More bit to 1 if it has more frames to be transmitted and it can determine the frame might be received successfully before the service period expires. 1606 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The AP should set the EOSP subfield to 1 in the frame that it expects to be the last frame transmitted to the non-AP STA during the U-APSD coexistence duration. If the last frame expected to be transmitted cannot be successfully transmitted to the non-AP STA before the termination of the U-APSD SP, or does not have QoS Control field, the AP should transmit a QoS Null frame with the EOSP subfield set to 1. The non-AP STA may enter doze state at the end of the U-APSD coexistence service period. 11.2.3.6 AP operation during the CP An AP shall maintain for each currently associated STA a Power Management status that indicates in which power management mode the STA is currently operating. APs that implement and signal their support of APSD shall maintain for each currently associated STA an APSD and an access policy status that indicates whether the STA is presently using APSD and shall maintain the schedule (if any) for the STA. An AP shall, depending on the power management mode of the STA, temporarily buffer BUs destined to the STA. An AP implementing APSD shall, if a STA is using APSD and is in PS mode, temporarily buffer BUs destined to that STA. No BUs addressed directly to STAs operating in the active mode shall be buffered for power management reasons. The following rules describe operation during the CP: a) BUs destined for PS STAs shall be temporarily buffered in the AP. The algorithm to manage this buffering is beyond the scope of this standard, with the exception that if the AP is QoS-enabled, it shall preserve the order of arrival of frames on a per-TID, per-STA basis. b) Nonbufferable MMPDUs and BUs destined for STAs in the active mode shall be directly transmitted to those STAs. c) At every beacon interval, the AP shall assemble the partial virtual bitmap containing the buffer status per destination for STAs in the PS mode and shall send this out in the TIM field of the Beacon frame. At every beacon interval, the APSD-capable AP shall assemble the partial virtual bitmap containing the buffer status of nondelivery-enabled ACs (if there exists at least one nondelivery- enabled AC) per destination for STAs in PS mode and shall send this out in the TIM field of the Beacon frame. When all ACs are delivery-enabled, the APSD-capable AP shall assemble the partial virtual bitmap containing the buffer status for all ACs per destination. If FMS is enabled, the AP shall include the FMS Descriptor element in every Beacon frame. The FMS Descriptor element shall indicate all FMS group addressed frames that the AP buffers. d) If a STA has set up a scheduled SP, it shall automatically wake up at each SP. Therefore, the APSD- capable AP shall transmit frames associated with admitted traffic with the APSD subfield equal to 1 in the TSPECs buffered for the STA during a scheduled SP. If the STA has set up to use unscheduled SPs, the AP shall buffer BUs using delivery-enabled ACs until it has received a trigger frame using a trigger-enabled AC from the non-AP STA, which indicates the start of an unscheduled SP. A trigger frame received by the AP from a STA that already has an unscheduled SP underway shall not trigger the start of a new unscheduled SP. The AP transmits BUs destined for the STA and using delivery-enabled ACs during an unscheduled SP. The bit for AID 0 (zero) in the Bitmap Control field of the TIM element shall be set to 1 when non-GCR-SP group addressed traffic is buffered, according to 9.4.2.6. e) If any associated STAs are in PS mode, the AP shall buffer all non-GCR-SP group addressed BUs, except those that have the StrictlyOrdered service class. f) When dot11FMSActivated is false, the AP shall transmit all buffered non-GCR-SP group addressed BUs immediately after every DTIM. When dot11FMSActivated is true and the AP has established an FMS delivery interval for a multicast stream, the AP shall transmit all non-GCR-SP group addressed BUs belonging to particular FMS stream immediately after the DTIM that has the Current Count field value of the FMS Counter field set to 0 for that particular FMS stream. 1607 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The More Data subfield of each group addressed frame shall be set to indicate the presence of further buffered non-GCR-SP group addressed BUs. If the AP is unable to transmit all of the buffered non-GCR-SP group addressed BUs before the primary or secondary TBTT following the DTIM, the AP shall set the bit for AID 0 (zero) in the TIM element to 1 for a single BSSID or set the corresponding group address bit to 1 for multiple BSSIDs, as defined in 9.4.2.6, and when dot11FMSActivated is true, shall set the appropriate bits in the FMS Descriptor element as described in 9.4.2.75 to indicate for which non-GCR-SP group addresses there are still buffered BUs, until all buffered non-GCR-SP group addressed BUs have been transmitted. When the AP transmits an STBC DTIM or TIM Beacon frame, the AP shall retransmit all non- GCR-SP group addressed BUs that were transmitted following the non-STBC DTIM or TIM Beacon frame except that they are transmitted using the basic STBC MCS. It may be the case that a complete set of buffered non-GCR-SP group addressed BUs is sent over a period of time during which non-STBC and STBC transmissions are interleaved, but the transition from non-STBC group addressed transmissions to STBC group addressed transmissions shall be preceded by the transmission of an STBC Beacon frame and the transition from STBC group addressed transmissions to non-STBC group addressed transmissions shall be preceded by the transmission of a non-STBC Beacon frame. g) When the AP receives a PS-Poll frame from a STA that is in PS mode, it shall forward to the STA a single buffered BU. The AP shall respond after a SIFS either with a Data or Management frame, or with an Ack frame; in which case the corresponding Data or Management frame is delayed. Until the transmission of this BU either has succeeded or is presumed failed (when maximum retries are exceeded), the AP shall acknowledge but ignore all PS-Poll frames from the same STA. This prevents a retried PS-Poll frame from being treated as a new request to deliver a buffered BU. For a STA using U-APSD, the AP transmits one BU destined for the STA from any AC that is not delivery-enabled in response to PS-Poll frame from the STA. The AP should transmit the BU from the highest priority AC that is not delivery-enabled and that has a buffered BU. When all ACs associated with the STA are delivery-enabled, the AP transmits one BU from the highest priority AC that has a BU. For a STA in PS mode and not using U-APSD, the AP shall set the More Data subfield of the response Data or Management frame to 1 to indicate the presence of further buffered BUs (not including the BU currently being transmitted) for the polling STA. For a STA using U-APSD, the AP shall set the More Data subfield to 1 to indicate the presence of further buffered BUs (not including the BU currently being transmitted) that do not use delivery- enabled ACs. When all ACs associated with the STA are delivery-enabled, the AP shall set the More Data subfield to 1 to indicate the presence of further buffered BUs (not including the BU currently being transmitted) using delivery-enabled ACs. If there are buffered BUs to transmit to the STA, the AP may set the More Data bit in a QoS +CF- Ack frame to 1 in response to a QoS Data frame to indicate that it has one or more pending BUs buffered for the PS STA identified by the RA in the QoS +CF-Ack frame. An AP may also set the More Data bit in an Ack frame to 1 in response to a QoS Data frame to indicate that it has one or more pending BUs buffered for the PS STA identified by the RA in the Ack frame, if that PS STA has set the More Data Ack subfield in the QoS Capability element to 1. Unless indicated above, the AP shall set the More Data bit to 0. h) At each scheduled APSD SP for a STA, the APSD-capable AP (i.e., an AP for which dot11APSDOptionImplemented is true) shall attempt to transmit at least one BU, using admitted TSPECs with the APSD and Schedule subfields both set to 1, that are destined for the STA. At each unscheduled SP for a STA, the AP shall attempt to transmit at least one BU, but no more than the value specified in the Max SP Length field in the QoS Capability element from delivery-enabled ACs, that are destined for the STA. NOTEâ€”The transmission of one or more fragments of a BU counts as the transmission of one BU for the purposes of the constraint indicated by the Max SP Length field. 1608 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The AP shall set to 1 the More Data bit of an individually addressed MPDU containing all or part of a BU, using a delivery-enabled AC and destined for that STA, to indicate that more BUs (not including the BU currently being transmitted) are buffered for the delivery-enabled ACs. The AP shall set to 1 the More Data bit of an individually addressed MPDU containing all or part of a BU, using a nondelivery-enabled AC and destined for that STA, to indicate that more BUs (not including the BU currently being transmitted) are buffered for the nondelivery-enabled ACs. In all frames except for the final frame of the SP, the AP shall set the EOSP subfield, if present, to 0 to indicate the continuation of the SP. An AP may also set the More Data bit to 1 in a QoS +CF-Ack frame in response to a QoS Data frame to indicate that it has one or more pending BUs buffered for the target STA identified by the RA in the QoS +CF-Ack frame. If the QoS Data frame is using a delivery-enabled AC, the AP shall set the More Data bit in the QoS +CF-Ack frame to 1 to indicate more BUs (not including the BU currently being transmitted) are buffered for the delivery-enabled ACs. If the QoS Data frame is not using a delivery-enabled AC, the AP shall set the More Data bit in the QoS +CF-Ack frame to 1 to indicate more BUs (not including the BU currently being transmitted) are buffered for the ACs that are not delivery-enabled. Unless indicated above, the AP shall set the More Data bit to 0. The AP considers an APSD STA to be in awake state after it has sent a QoS +CF-Ack frame, with the EOSP subfield equal to 0, to the APSD STA. If necessary, the AP may generate an extra QoS Null frame, with the EOSP subfield set to 1. When the AP has transmitted an individually addressed frame to the STA with the EOSP subfield set to 1 during the SP except for retransmissions of that frame, the AP shall not transmit any more frames to that STA using this mechanism until the next SP. The AP shall set the EOSP subfield to 1 to indicate the end of the SP in APSD. NOTEâ€”Management frames do not have an EOSP subfield and so the end of the SP cannot be indicated in a Management frame. If the SP is to end after a Management, a QoS Null frame is used to indicate this. The AP should not set the EOSP field to 1 in a frame that is not an individually addressed Data frame that requires acknowledgment. i) If the AP does not receive an acknowledgment to an individually addressed MPDU containing all or part of a BU sent to a STA in PS mode following receipt of a PS-Poll frame from that STA, it may retransmit the frame for at most the lesser of the maximum retry limit and dot11QAPMissingAckRetryLimit times before the next Beacon frame, but it shall retransmit that frame at least once before the next Beacon frame, time permitting and subject to its appropriate lifetime limit. If an acknowledgment to the retransmission is not received, it may wait until after the next Beacon frame to further retransmit that frame subject to its appropriate lifetime limit. j) If the AP does not receive an acknowledgment in response to a non-A-MPDU frame that is an individually addressed Data frame that is sent with the EOSP subfield equal to 1, and that requires acknowledgment, it shall retransmit that frame at least once within the same SP, subject to applicable retry or lifetime limits. If the AP does not receive a Block Ack frame in response to an A- MPDU that contains one or more individually addressed Data frames that are sent with the EOSP subfield equal to 1, and that require acknowledgment, it shall retransmit at least one of those frames at least once within the same SP, subject to applicable retry or lifetime limits. The maximum number of retransmissions within the same SP is the lesser of the maximum retry limit and dot11QAPMissingAckRetryLimit. If the AP does not receive an acknowledgment to an individually addressed Data or Management frame that requires acknowledgment and that is not the initial attempt in this SP to send a frame with the EOSP subfield equal to 1, it may retransmit that frame in the next SP, subject to applicable retry or lifetime limits. An AP that transmits an A-MPDU containing Data frames in which the EOSP subfield is equal to 1 and that receives a BlockAck frame that does not acknowledge all of those MPDUs should not transmit any missed Data frames within the current service period because the destination STA might now be asleep. 1609 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications k) An AP may delete buffered BUs for implementation dependent reasons (subject to 11.2.3.12), including the use of an aging function and availability of buffers. The AP may base the aging function on the listen interval indicated by the STA in its (Re)Association Request frame or the WNM sleep interval specified by the non-AP STA in the WNM Sleep Mode Request frame. l) When an AP is informed that a STA has changed to the active mode, then the AP shall send buffered BUs (if any exist) to that STA without waiting for a PS-Poll frame. When an AP is informed that an APSD-capable STA is not using APSD, then the AP shall send buffered BUs (if any exist) to that STA according to the rules corresponding to the current PS mode of the STA. 11.2.3.7 AP operation during the CFP An AP shall maintain for each currently associated CF-Pollable STA a Power Management status that indicates the STAâ€™s current power management mode. An AP shall, for STAs in PS mode, temporarily buffer BUs addressed to the STA. The following rules describe operation during the CFP: a) BUs destined for PS STAs shall be temporarily buffered in the AP. The algorithm to manage this buffering is beyond the scope of this standard. b) Nonbufferable MMPDUs and all BUs destined to STAs in the active mode shall be transmitted as defined in Clause 10. c) Prior to every CFP, and at each beacon interval within the CFP, the AP shall assemble the partial virtual bitmap containing the buffer status per destination for STAs in the PS mode, set to 1 the bits in the partial virtual bitmap for STAs the PC is intending to poll during this CFP, and shall send this out in the TIM field of the DTIM. The bit for AID 0 (zero) in the Bitmap Control field of the TIM element shall be set to 1 when group addressed traffic is buffered, according to 9.4.2.6. d) All non-GCR-SP group addressed MSDUs except those with a service class of StrictlyOrdered shall be buffered if any associated STAs are in the PS mode, regardless of whether those STAs are CF- Pollable. e) When dot11FMSActivated is false, the AP shall transmit all buffered non-GCR-SP group addressed BUs immediately after every DTIM (Beacon frame with DTIM Count field of the TIM element equal to 0). When dot11FMSActivated is true and the AP has set up an FMS delivery interval for a multicast stream, the AP shall send all non-GCR-SP group addressed BUs belonging to a particular FMS stream immediately after the DTIM with the Current Count field value of the FMS Counter field set to 0 for that particular FMS stream. The More Data subfield shall be set to 1 in the headers of all but the final frame containing one of these buffered non-GCR-SP group addressed BUs to indicate the presence of further buffered group addressed BUs. If the AP is unable to transmit all of the buffered non-GCR-SP group addressed BUs before the non-STBC or STBC TBTT following the DTIM, the AP shall set the bit for AID 0 (zero) in the TIM element to 1 for a single BSSID or set the corresponding group addressed bit to 1 for multiple BSSIDs, as defined in 9.4.2.6, and when dot11FMSActivated is true, shall set the appropriate bits in the FMS Descriptor element as described in 9.4.2.75 to indicate for which non- GCR-SP group addresses there are still buffered BUs, until all buffered non-GCR-SP group addressed BUs have been transmitted. When the AP transmits an STBC DTIM or TIM Beacon frame, the AP shall retransmit all non- GCR-SP group addressed BUs that were transmitted following the non-STBC DTIM or TIM Beacon frame except that they are transmitted using the basic STBC MCS. It may be the case that a complete set of buffered non-GCR-SP group addressed BUs is sent over a period of time during which non-STBC and STBC transmissions are interleaved, but the transition from non-STBC group addressed transmissions to STBC group addressed transmissions shall be preceded by the transmission of a STBC Beacon frame and the transition from STBC group addressed transmissions 1610 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications to non-STBC group addressed transmissions shall be preceded by the transmission of a non-STBC Beacon frame. f) Buffered BUs for STAs in the PS mode shall be forwarded to the CF-Pollable STAs under control of the PC. Transmission of these buffered BUs as well as CF-Polls to STAs in the PS mode that were indicated in the DTIM in accordance with paragraph c) of this subclause shall begin immediately after transmission of buffered non-GCR-SP group addressed frames (if any), and shall occur in order by increasing AID of CF-Pollable STAs. A CF-Pollable STA for which the TIM element of the most recent Beacon frame indicated buffered BUs shall be in the awake state at least until the receipt of an individually addressed frame from the AP in which the Frame Control field does not indicate the existence of more buffered BUs. After acknowledging the last of the buffered BUs, the CF-Pollable STA operating in the PS mode may enter the doze state until the next DTIM is expected. g) An AP shall have an aging function to delete pending traffic buffered for an excessive time period. The exact specification of the aging function is beyond the scope of this standard. h) When an AP detects that a CF-Pollable STA has changed from the PS mode to the active mode, then the AP shall queue any buffered BUs addressed to that STA for transmission to that CF-Pollable STA as directed by the APâ€™s PC. 11.2.3.8 Receive operation for STAs in PS mode during the CP A STA in PS mode shall operate as follows to receive a BU from the AP when no PC is operating and during the CP when a PC is operating. The following rules describe operation of a STA in PS mode during the CP: a) The STA shall wake up early enough to be able to receive the first Beacon frame scheduled for transmission at the time corresponding to the last TBTT for which the STA was awake plus the time interval indicated by the ListenInterval parameter of the MLME-ASSOCIATE.request or MLME REASSOCIATE.request primitive. NOTEâ€”The STA might wake for a TBTT that is earlier than this deadline. In that case the previous requirement is reset based on a new â€œlast TBTTâ€. b) When the STA detects that the bit corresponding to its AID is 1 in the TIM, the STA shall issue a PS-Poll frame, or a trigger frame if the STA is using U-APSD and all ACs are delivery-enabled, to retrieve the buffered BU. The PS-Poll or trigger frame shall be transmitted after a random delay uniformly distributed between zero and aCWmin slots following a DIFS. c) The STA shall remain in the awake state until it receives the BU in response to its poll or it receives another Beacon frame whose TIM indicates that the AP does not have any BUs buffered for this STA. If the bit corresponding to the STAâ€™s AID is 1 in the subsequent TIM, the STA shall issue another PS-Poll frame to retrieve the buffered BU. When a STA that is using U-APSD and has all ACs delivery-enabled detects that the bit corresponding to its AID is 1 in the TIM, the STA shall issue a trigger frame or a PS-Poll frame to retrieve the buffered BU. d) If the More Data subfield in the MPDU(s) containing the BU indicates that more traffic for that STA is buffered, the STA, at its convenience, shall poll until no more BUs are buffered for that STA. e) When dot11FMSActivated is false and ReceiveDTIMs is true, the STA shall wake up early enough to be able to receive either every non-STBC DTIM or every STBC DTIM sent by the AP of the BSS. When dot11FMSActivated is true and ReceiveDTIMs is true and the STA has been granted by the AP an alternate delivery interval for a multicast stream, the STA shall wake up before the non-STBC DTIM or STBC DTIM having Current Count of FMS Counter field set to 0 for that particular FMS stream. A STA that stays awake to receive group addressed BUs shall elect to receive all group addressed non-STBC transmissions or all group addressed STBC transmissions and remain awake until the More Data subfield of the appropriate type (non-STBC or STBC) of group addressed BUs indicates 1611 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications there are no further buffered group addressed BUs of that type, or until a TIM is received indicating there are no more buffered group addressed BUs of that type, or until an FMS Descriptor element is received indicating that there are no further buffered group addressed BUs for which the STA has previously received an FMS Response element in a frame that has a value in Address 1 that matches its MAC address or that has an Address 1 value that is a group address corresponding to a group of which it is a member and that was transmitted by the AP with which it is associated and which had an Element Status value in the FMS Status subelement of â€œAcceptâ€. If a STA receives a QoS +CF- Ack frame from its AP with the More Data bit equal to 1, then the STA shall operate exactly as if it received a TIM with its AID bit equal to 1. If a STA has set the More Data Ack subfield in QoS Capability element to 1, then if it receives an Ack frame from its AP with the More Data bit equal to 1, the STA shall operate exactly as if it received a TIM with its AID bit equal to 1. For example, a STA that is using the PS-Poll delivery method shall issue a PS-Poll frame to retrieve a buffered BU. See also 10.3.6. 11.2.3.9 Receive operation for STAs in PS mode during the CFP A STA in PS mode that is associated as CF-Pollable shall operate as follows in a BSS with an active PC to receive BUs from the AP during the CFP: a) The STA shall enter the awake state so as to receive the Beacon frame (which contains a DTIM) at the start of each CFP. b) To receive group addressed BUs, the STA shall wake up early enough to be able to receive either every non-STBC DTIM or every STBC DTIM that may be sent during the CFP. A STA receiving group addressed BUs shall elect to receive all group addressed non-STBC transmissions or all group addressed STBC transmissions and remain awake until the More Data subfield of the frames containing the group addressed BUs indicates there are no further buffered group addressed BUs of that type, or until a TIM is received indicating there are no more group addressed BUs of that type buffered or until an FMS Descriptor element is received indicating that there are no further buffered group addressed BUs for which the STA has previously received an FMS Response element in a frame that has an Address 1 value that matches its MAC address or that has an Address 1 value that is a group address corresponding to a group of which it is a member and that was transmitted by the AP with which it is associated and which had an Element Status value in the FMS Status subelement of â€œAcceptâ€. See also 10.3.6. c) When the STA detects that the bit corresponding to its AID is 1 in the DTIM at the start of the CFP (or in a subsequent TIM during the CFP), the STA shall remain in the awake state for at least that portion of the CFP through the time that the STA receives an individually addressed BU from the AP carried in a frame with the More Data subfield in the Frame Control field indicating that no further traffic is buffered. d) If the More Data subfield in the Frame Control field of the last MPDU containing all or part of the BU received from the AP indicates that more traffic for the STA is buffered, then, when the CFP ends, the STA may remain in the awake state and transmit PS-Poll frames during the CP to request the delivery of additional buffered BUs, or may enter the doze state during the CP (except at TBTTs for DTIMs expected during the CP), awaiting the start of the next CFP. 11.2.3.10 Receive operation using APSD A STA using APSD shall operate as follows to receive a BU from the AP: a) If a scheduled SP has been set up, the STA wakes up at its scheduled start time. (The STA shall wake up early enough to receive transmissions at the scheduled SP.) b) If the STA is initiating an unscheduled SP, the STA wakes up and transmits a trigger frame to the AP. When one or more ACs are not delivery-enabled, the STA may retrieve BUs using those ACs by sending PS-Poll frames to the AP. 1612 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications c) The STA shall remain awake until it receives a QoS Data frame or QoS Null frame addressed to it, with the EOSP subfield equal to 1. d) The STA may send additional PS-Poll frames if the More Data subfield is 1 in a downlink individu- ally addressed MPDU containing all or part of a BU that does not use a delivery-enabled AC. The STA may send additional trigger frames if the More Data subfield is 1 in a downlink individually addressed MPDU containing all or part of a BU that uses a delivery-enabled AC. For receive operation using the U-APSD coexistence mechanism, see additional procedures in 11.2.3.5.2. 11.2.3.11 STAs operating in the active mode A STA operating in this mode shall have its receiver activated continuously; such STAs do not need to interpret the TIM elements in Beacon frames. 11.2.3.12 AP aging function Any AP aging function shall not cause the buffered BU to be discarded after any period that is shorter than that indicated by the STA for which the BUs are buffered, in the Listen Interval field of its (Re)Association Request frame. The exact specification of the aging function is beyond the scope of this standard. NOTEâ€”This aging function is independent of (i.e., in addition to) other causes of MSDU discard within the MAC, such as due to the operation of a per-TS MSDU lifetime, or related to dot11QAPEDCATableMSDULifetime. 11.2.3.13 PSMP power management An AP transmits a PSMP frame containing a schedule only for STAs that are awake. A STA with an established PSMP session (see 11.4.6) shall be awake at the start of the sessionâ€™s SP and shall remain awake until the end of the SP unless permitted to return to sleep as described in this subclause. NOTEâ€”A STA in power save mode can also be determined to be awake following receipt of a trigger frame according to the operation of the U-APSD protocol (as defined in 11.2.3.5), following receipt of a PS-Poll frame (as defined in 11.2.3.8), or following a DTIM Beacon (as defined in 11.2.3.8). The AP may signal the end of the SP for all awake associated PSMP-capable STAs by setting the More PSMP field to 0 or by sending CF-End frame instead of the next PSMP frame. NOTE 1â€”The AP can also signal the end of an SP on a per-STA basis using the EOSP subfield set to 1 in the QoS Control field, as defined in 9.2.4.5.3 and 11.2.3.6. This field remains set to 1 for any retransmissions of the same frame, and no more new frames are sent to this particular STA in the current SP. NOTE 2â€”If a STA is awake at the start of a scheduled PSMP session, the operation of the More Data subfield in the Frame Control field and the TIM element are defined by the S-APSD rules in 11.2.3.5, 11.2.3.6, and 11.2.3.10. A STA shall wake up at the start of the next PSMP frame if the More PSMP field is equal to 1 in the current PSMP frame, unless the STA has been permitted to return to sleep through the reception of a frame addressed to it with the EOSP subfield equal to 1 or the maximum SP interval has elapsed. Within a PSMP sequence, a PPDU containing MPDUs addressed to a STA shall not start after the expiration of the STAâ€™s PSMP-DTT. A STA completes the reception of any PPDU that starts before the end of the PSMP-DTT. If no frames addressed to a STA begin within a PSMP-DTT, it can assume that no frame addressed to it will arrive during this PSMP sequence. The STA shall be awake to receive at the start of the PSMP-DTT determined from a STA_INFO field that has the STA_INFO Type subfield equal to 2 and the AID field matching the STAâ€™s AID where the PSMP- DTT Duration subfield is not equal to 0. 1613 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.2.3.14 TDLS peer power save mode TDLS peer power save mode (TDLS peer PSM) is a power save mechanism that can be used between TDLS peer STAs, and which is based on a periodic wakeup schedule. A STA supports TDLS peer PSM if dot11TDLSPeerPSMActivated is true. A STA supporting this capability may indicate support through any TDLS Setup Request frame or TDLS Setup Response frame. A STA indicating this support shall signal this by setting the TDLS Peer PSM Support subfield in the Extended Capabilities element included in the TDLS Setup Request frame or TDLS Setup Response frame to 1. A station that signals support for this capability is capable of acting in both the TDLS peer PSM initiator and the TDLS peer PSM responder role. A STA that intends to enter TDLS peer PSM (TDLS peer PSM initiator) shall send a TDLS Peer PSM Request frame to the TDLS peer STA (TDLS peer PSM responder), including a proposed periodic Wakeup Schedule. A TDLS Peer PSM Request frame shall not be transmitted to a STA that did not indicate support for TDLS peer PSM. When the TDLS peer PSM responder accepts the proposed Wakeup Schedule, it shall respond with a TDLS Peer PSM Response frame indicating status code SUCCESS. Otherwise, the TDLS peer PSM responder shall respond with a TDLS Peer PSM Response frame indicating the appropriate status code for rejecting the schedule. An alternative schedule shall be included in the TDLS Peer PSM Response frame when the status code is equal to TDLS_REJECTED_ALTERNATIVE_PROVIDED. The alternative schedule may be used by the TDLS peer PSM initiator to generate a new TDLS Peer PSM Request frame. After successfully transmitting or receiving a TDLS Peer PSM Response frame indicating status code SUCCESS, the TDLS peer PSM initiator and TDLS peer PSM responder have established a periodic wakeup schedule between them. The wakeup schedule remains valid until one of the following occurs: â€” The TDLS direct link is torn down; â€” The STAs explicitly update the existing wakeup schedule; or â€” No MPDUs containing data have been exchanged for Idle Count consecutive Awake Windows. A STA transmitting a TDLS Peer PSM Request frame shall remain in the awake state until it received the corresponding TDLS Peer PSM Response frame. A TDLS Peer PSM Request frame may be transmitted via the AP path or via the direct path (which is up to the implementer to decide). A TDLS Peer PSM Response frame shall be transmitted over the direct path. The timing of the periodic schedule of the TDLS Peer PSM Awake Windows is based on the Offset field, the Interval field, the Awake Window Slots field, and the Maximum Awake Window Duration field of the Wakeup Schedule element that is contained in the TDLS Peer PSM Request frame that established TDLS peer PSM operation on the link. Awake Windows begin at TSF values that satisfy the equation TSF mod Interval = Offset. The interval between the start of two successive Awake Windows is equal to the time in microseconds of the Interval field. The periodic wakeup schedule may be unrelated to the target beacon transmission time (TBTT) or the beacon interval. Awake Windows end when the Awake Window Slot Counter reaches 0 or when the Maximum Awake Window Duration has been reached, whichever comes first. The Awake Window Slot Counter counts down backoff slots that are determined using AIFS[AC_BE] in the same manner that normal backoff slots are determined according to 10.22.2.4. The initial value of the Awake Window Slot Counter at the start of the Awake Window shall be equal to the value in the Awake Window Slots field of the Wakeup Schedule element that is contained in the TDLS Peer PSM Request frame that established TDLS peer PSM operation on the link. The Awake Window Slot Counter begins counting at the beginning of the Awake Window and stops counting when it reaches 0. 1614 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A value of 0 in the Maximum Awake Window Duration field of the Wakeup Schedule element that is contained in the TDLS Peer PSM Request frame that established TDLS peer PSM operation on the link means that the end of the Awake Window duration is determined only by the Awake Window Slot Counter. A value of 0 in the Awake Window Slots field of the Wakeup Schedule element that is contained in the TDLS Peer PSM Request frame that established TDLS peer PSM operation on the link means that the duration of the Awake Window is determined only by the Maximum Awake Window Duration. The Maximum Awake Window Duration field and the Awake Window Slots field shall not both be set to 0 in a TDLS Peer PSM Request frame. The Awake Window Slots field in a TDLS Peer PSM Request frame should be set to a value that is larger than CWmin[AC_BE]. A TDLS peer PSM service period is a period of time during which one or more individually addressed frames are transmitted between two TDLS peer STAs when at least one STA employs TDLS peer PSM. A TDLS peer PSM service period may be initiated during an Awake Window. A TDLS peer STA in power save mode may enter a doze state when it has successfully transmitted to and received from the corresponding TDLS peer STA in power save mode a QoS frame with the EOSP subfield equal to 1, ending the TDLS peer PSM service period. A TDLS peer STA in power save mode may enter a doze state when it has successfully received from the corresponding TDLS peer STA in active mode a QoS frame with the EOSP subfield equal to 1. Either STA may update an existing schedule by initiating a TDLS Peer PSM Request/Response exchange. If the TDLS Peer PSM Response frame indicates status code SUCCESS, a new wakeup schedule is established for the TDLS direct link. Otherwise, the existing schedule still applies. The new schedule takes effect after the termination of the current TDLS peer PSM service period. After the successful PSM setup, a STA informs its TDLS peer STA that it will enter power save mode per direct link by setting the Power Management subfield to 1 in an MPDU requiring acknowledgment. The STA enters power save mode after successful transmission of the MPDU. The power save status on one direct link is independent of the power save status on other links (direct or with the AP) the STA may have. If a TDLS peer STA enters power save mode when a Wakeup Schedule is active, it shall be awake at the beginning of each scheduled periodic Awake Window, and stay awake for the duration of the Awake Window or until the end of a TDLS peer PSM service period. Otherwise, it may enter a doze state, depending on the current requirements to be awake, imposed by other links. A TDLS peer STA that did not enter power save mode shall remain in the awake state. When both TDLS peer STAs set the More Data Ack subfield in their QoS Capability element to 1, then the More Data subfield inside an Ack frame set to 0 shall have the same function as the EOSP subfield inside a QoS frame set to 1. Transmission of an Ack frame with the More Data subfield set to 0 under these conditions is equivalent to a successful transmission of a QoS frame with the EOSP subfield set to 1. When waking up at the beginning of an Awake Window, if a STA has no buffered BU to send to a TDLS Peer STA that had the More Data Ack subfield in its QoS Capability element equal to 1 during the TDLS setup exchange, the TDLS STA may send a QoS Null frame with the EOSP subfield of the QoS Control field set to 1, and the More Data subfield of the Frame Control field set to 0. If the TDLS peer STA that is the recipient of this QoS Null frame also has no buffered BU to deliver either, and it had the More Data Ack subfield in its QoS Capability element equal to 1 during the TDLS setup exchange, then the TDLS peer STA shall respond with an Ack frame that has the More Data subfield set to 0. The STA may discard the QoS Null frame if it has not been successfully transmitted at the end of the Awake Window. Before the successful transmission of the QoS Null frame, if a Data or QoS Null frame with an EOSP subfield equal to 1615 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 1 is received from the TDLS peer STA the STA may cancel the pending transmission of the QoS Null frame after the transmission of an Ack frame with the More Data subfield set to 0. To keep track of the connectivity over the direct link and to maintain the wakeup schedule, a TDLS peer STA may start an acknowledged frame exchange at least once per Idle Count consecutive Awake Windows, as a keepalive. For instance a QoS Null frame may be used as a keepalive frame. When a TDLS Peer PSM Response frame was successfully transmitted or received and no subsequent TDLS peer PSM service period has started for Idle Count consecutive wakeup periods, a TDLS peer STA shall delete the wakeup schedule for this link, which means that the related periodic wakeup no longer occurs (i.e., the TDLS peer STA no longer has to wake up during this period) and that a wakeup schedule no longer exists for this link. When traffic arrives at a TDLS peer STA in TDLS peer PSM mode for a link with no existing wakeup schedule, the STA shall send a TDLS Peer PSM Request frame through the AP path to the TDLS peer STA to activate a new wakeup schedule. When both TDLS peer STAs enter active mode while a wakeup schedule is active, no more TDLS peer PSM service periods will occur, causing the wakeup schedule to be deleted. If a TDLS peer STA does not receive an acknowledgment to an individually addressed QoS frame sent with the EOSP subfield equal to 1 that terminates a TDLS peer PSM service period, it shall retransmit that frame at least once within the same service period, subject to the applicable retry or lifetime limit. The maximum number of retransmissions within the same service period is the lesser of the maximum retry limit and dot11TDLSPeerSTAMissingAckRetryLimit. If an acknowledgment to the retransmission of this last frame in the same service period is not received, the TDLS peer STA may wait until the next Awake Window to further retransmit that frame, subject to its applicable retry or lifetime limit. When the TDLS peer STA has transmitted an individually addressed frame that terminates a TDLS peer PSM service period then, except for retransmissions of that frame, the TDLS peer STA shall not transmit any more frames to the TDLS peer STA until the next Awake Window. A TDLS peer STA that has an active Wakeup Schedule shall not decrement a backoff count outside the Awake Windows, if that backoff precedes a frame that is destined for transmission on the related TDLS direct link. At the start of an Awake Window, the backoff procedure shall be invoked at an EDCAF if there is a frame available for transmission at that EDCAF, and the backoff timer for that EDCAF has been 0 for at least one backoff slot. Outside of its Awake Windows, and during Awake Windows when on the base channel, a TDLS peer STA can engage in communications with the AP. 11.2.3.15 TDLS peer U-APSD (TPU) 11.2.3.15.1 General A STA supports the TPU buffer STA function if dot11TDLSPeerUAPSDBufferSTAActivated is true. A non-QoS STA shall set dot11TDLSPeerUAPSDBufferSTAActivated to false. A STA supporting this capability may indicate support through any TDLS Setup Request frame or TDLS Setup Response frame. A STA indicates support by setting the TPU Buffer STA Support subfield in the Extended Capabilities element included in the TDLS Setup Request frame or TDLS Setup Response frame to 1. Support for the TPU buffer STA function means that the STA has the capability to buffer BUs destined to the TPU sleep STA, and to deliver them during unscheduled service periods. To operate as the TPU sleep STA in TPU, a STA shall configure its TPU capable TDLS peer STA by setting one or more U-APSD Flag subfields inside the QoS Info subfield of the QoS Capability element carried in a TDLS Setup Response frame to 1, or by setting one or more U-APSD Flag subfields inside the QoS Info subfield of the EDCA Parameter Set element carried in a TDLS Setup Confirm frame to 1. 1616 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A STA that configured TPU at a TDLS peer STA enters power save mode on a TDLS direct link after the successful transmission to the TDLS peer STA over the direct link of an acknowledged MPDU with the Power Management subfield equal to 1. The STA that transmitted the frame with the Power Management subfield equal to 1 is then referred to as a TPU sleep STA. The STA that received the frame with the Power Management subfield equal to 1 is referred to as a TPU buffer STA. A TPU sleep STA may be a TPU buffer STA at the same time and on the same link, by sending a frame to the TDLS peer STA with the Power Management subfield of the Frame Control field set to 1 (this transmission will be preceded by the transmission of a Peer Traffic Indication frame and the subsequent receipt of a trigger frame that starts a service period). The power save status on one direct link is independent of the power save status on other links (direct or with the AP) the STA may have. The procedure to trigger and terminate an unscheduled SP between TPU buffer STA and a TPU sleep STA are described in 11.2.3.5 and 11.2.3.6, where the TPU buffer STA shall take the role of the AP and the TPU sleep STA shall take the role of the non-AP STA using U-APSD, except that a frame with the EOSP subfield equal to 1 shall not act as a trigger frame. 11.2.3.15.2 TPU at the TPU buffer STA BUs at a TPU buffer STA destined for a TPU sleep STA shall be temporarily buffered at the TPU buffer STA. The algorithm to manage this buffering is beyond the scope of this standard, except that the TPU buffer STA shall preserve the order of buffered BUs on a per-TID, per-STA basis. A TPU buffer STA shall transmit an individually addressed TDLS Peer Traffic Indication frame to a TPU sleep STA, through the AP, if and only if all of the following conditions are met: â€” A BU destined for a TPU sleep STA was placed into a buffer at the TPU buffer STA; â€” The buffer into which the BU was placed contained no other frames with the same RA; and â€” One or more periods of dot11TDLSPeerUAPSDIndicationWindow beacon intervals have expired after the last service period. The TDLS Peer Traffic Indication frame shall be transmitted through the AP path. The transmitted TDLS Peer Traffic Indication frame shall indicate the nonempty AC(s), by setting the corresponding AC Traffic Available subfield of the TDLS Peer Traffic Indication frame to 1. A PTI Control element may be included in the TDLS Peer Traffic Indication frame, to allow the TPU sleep STA to not start a service period when the indicated traffic has already been received by the TPU sleep STA. The TID field contained in the PTI Control element (if included) shall be set to the TID of the latest MPDU that has been transmitted over the TDLS direct link to the TPU sleep STA that is the destination of the TDLS Peer Traffic Indication frame that contains the PTI Control element. The Sequence Control field contained in the PTI Control element (if included) shall be set to the sequence number of the latest MPDU that has been transmitted over the TDLS direct link to the TPU sleep STA that is the destination of the TDLS Peer Traffic Indication frame that contains the PTI Control element. After transmitting a TDLS Peer Traffic Indication frame without a PTI Control element, the TPU buffer STA shall stay awake at least until the corresponding or a subsequent TDLS Peer Traffic Response frame is received. After transmitting a TDLS Peer Traffic Indication frame without a PTI Control element, the TPU buffer STA shall stay awake at least until the MPDU following the MPDU indicated in the Sequence Control field of the PTI Control element is successfully transmitted. 1617 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications When no corresponding TDLS Peer Traffic Response frame has been received within dot11TDLSResponseTimeout after sending a TDLS Peer Traffic Indication frame, the STA shall tear down the direct link. 11.2.3.15.3 TPU at the TPU sleep STA When a TPU sleep STA receives a TDLS Peer Traffic Indication frame without a PTI Control element, the TPU sleep STA shall initiate a service period with the TPU buffer STA during which it shall transmit at least a TDLS Peer Traffic Response frame. The TDLS Peer Traffic Response frame shall echo the values of the Dialog Token and Link Identifier fields from the corresponding TDLS Peer Traffic Indication frame. The TDLS Peer Traffic Response frame shall be sent via the direct path. When a TPU sleep STA receives a TDLS Peer Traffic Indication frame with a PTI Control element, and the TPU sleep STA has not received from the TPU buffer STA the MPDU following the MPDU that is indicated in the TDLS Peer Traffic Indication frame, the TPU sleep STA shall initiate a service period with the TPU buffer STA to retrieve the buffered traffic for the AC(s) for which no unscheduled SP is currently active. 11.2.3.16 FMS power management 11.2.3.16.1 General Implementation of FMS is optional for a WNM STA. A STA whose dot11FMSActivated is true shall support FMS and shall set to 1 the FMS field of the Extended Capabilities elements that it transmits. 11.2.3.16.2 FMS general procedures When dot11FMSActivated is true at the AP, the AP shall include the FMS Descriptor element in every Beacon frame. The FMS Descriptor indicates the FMS group addressed buffered BUs at the AP. If there are no buffered BUs for FMS streams accepted by the AP, the AP shall set the Length field in the FMS Descriptor element to 1. The AP shall include the FMS Descriptor element for a nontransmitted BSSID in the Multiple BSSID element sent in a Beacon frame. When dot11FMSActivated is true at the AP, the AP shall support from one to eight different FMS Stream delivery intervals for any number of FMS streams. Corresponding to these eight delivery intervals are eight FMS counters. More than one FMSID may have the same delivery interval and therefore will share the same FMS Counter. An FMS Counter corresponds to each unique delivery interval of one or more FMS Streams. Each FMS counter decrements once per DTIM beacon and when the FMS counter reaches 0, buffered group addressed BUs assigned to that particular interval are scheduled for delivery immediately following the next Beacon frame containing the DTIM transmission. After transmission of the buffered group addressed BUs, the AP shall reset the FMS counter to the delivery interval for the FMS streams associated with that FMS counter. A non-AP STA that does not use FMS wakes every DTIM interval and follows group addressed BU reception rules as defined in 11.2.3.8. A STA that supports FMS shall be capable of supporting a delivery interval of 1 for any stream. 11.2.3.16.3 FMS Request procedures A non-AP STA that supports FMS may request use of FMS by sending an FMS Request frame or Reassociation Request frame that includes one or more FMS Request elements to an AP that supports FMS. Each FMS Request element includes one or more FMS subelements. Each FMS subelement identifies an 1618 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications FMS stream, the requested delivery interval and the maximum delivery interval for that stream. The FMS delivery interval shall be an integer multiple of the DTIM period. Upon reception of an FMS Request frame or Reassociation Request frame, the AP shall transmit a corresponding single FMS Response frame or Reassociation Response frame that contains a corresponding FMS Response element for each FMS Request element in the same order received. Each FMS Response element shall contain an FMS Status subelement and zero or more other subelements drawn from Table 9- 197 that corresponds to each FMS subelement in the FMS Request element, in the same order. For each FMS subelement, the following rules apply: If the AP accepts the FMS subelement and the requested delivery interval, the Element Status in the corresponding FMS Status subelement shall be set to â€œAcceptâ€ and the FMSID is assigned to a nonzero value. In addition: â€” If the FMS stream identified in the FMS subelement matches a delivery interval already in use at the AP, the AP shall assign the FMS stream to use the FMS Counter ID assigned for that delivery interval. â€” When an FMS Stream is accepted by the AP, the Current Count value for that FMS Stream is decremented by 1 for each DTIM Beacon frame in which the Current Count field appears. â€” The AP may reschedule transmission of the FMS Stream identified by an FMSID to align the transmission time of the FMS stream to the transmission time of other FMS streams that the STA is already receiving at the same delivery interval. The AP has the following two options: â€” Notify the STAs using that FMS Stream. The AP shall keep the nonzero Current Count value the same across two consecutive Beacon frames in which the Current Count field appears. The algorithm by which the AP chooses to align or offset the different FMS counters is unspecified. â€” Transmit an unsolicited FMS Response frame to the group address included in the original FMS Response frame for the stream with the updated Delivery Interval field when the Current Count field value reaches 0. Since the AP transmits this FMS Response frame as a group addressed frame, the frame will be scheduled for delivery at the appropriate DTIM interval when all non-AP STAs are awake to receive the frame. â€” An AP may terminate the use of FMS and resume default (non-FMS) transmission rules for any FMS stream identified by FMSID for any reason. To terminate the FMS stream, the AP shall send an unsolicited FMS Response frame to the group address included in the original FMS Response frame with Delivery Interval set to 0 and the Element Status in the FMS Status subelement set to one of â€œTerminate, due to AP policy changeâ€, â€œTerminate, due to lack of resources of AP,â€ and â€œTerminate, due to other FMS stream with higher priorityâ€. â€” If the FMS subelement contained a nonzero delivery interval and the non-AP STA specified a maximum delivery interval as part of the FMS request, the AP shall not modify the delivery interval for the stream greater than the maximum delivery interval specified by the non-AP STA. â€” An AP shall transmit MSDUs belonging to the same FMSID in the same order that they were received at the MAC Data SAP. MSDUs belonging to the different FMSIDs are transmitted by the AP at the appropriate DTIM in the order received at the MAC data SAP based on the interval configured for the FMS stream. If the AP denies the FMS subelement for any reason, including requested delivery interval, maximum delivery interval and TCLAS, the Element Status in the corresponding FMS Status subelement shall be set to one of â€œDeny, due to request format error or ambiguous classifierâ€, â€œDeny, due to lack of resources on APâ€, â€œDeny, due to requested classifier(s) matching 2 or more existing streams on different intervals,â€ â€œDeny, by policy, requested stream or filter is not permitted to participate in the serviceâ€, and â€œDeny, reason unspecifiedâ€. 1619 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If the AP selects an alternate delivery interval or alternate maximum delivery interval from the value specified in the FMS Request, the Element Status field in the corresponding FMS Status subelement shall be set to one of â€œAlternate proposed, due to existing stream with different delivery intervalâ€, â€œAlternate proposed, due to policy limits on APâ€, â€œAlternate proposed, because the AP changed the delivery intervalâ€, and â€œAlternate proposed, because the AP changed the maximum delivery intervalâ€ and the FMS subelement shall indicate the AP selected value(s). To terminate the use of FMS for an FMS Stream identified by FMSID, the non-AP STA shall transmit an FMS Request frame with an FMS Request element and FMS subelement with the FMSID matching the FMS stream and the delivery interval set to 0. The AP shall respond to a malformed FMS Request frame or Reassociation Request frame with an FMS Response frame or Reassociation Response frame that denies all FMS Request elements by including an FMS Status code â€œDeny, due to request format error or ambiguous classifierâ€ in the Element Status field in each FMS Status subelement in the FMS Response element. 11.2.3.16.4 FMS Response procedures Upon reception of an FMS Response element in a frame that has a value in Address 1 that matches its MAC address or that is a group address corresponding to a group of which it is a member and that was transmitted by the AP with which it is associated, a non-AP STA that supports FMS shall use the following procedures, based on the value of the Element Status value in the FMS Status subelement in the received FMS Response element. â€” If the Element Status value in the FMS Status subelement is â€œAcceptâ€: â€” The AP has accepted the FMS subelement contained within the FMS Request element. If the FMS Request element specified a nonzero delivery interval, the AP will deliver the requested streams at the delivery interval as specified by the non-AP STA in the FMS Request element. â€” After receiving the FMS Response element, the non-AP STA shall be awake for the next DTIM beacon so that the non-AP STA can synchronize with the FMS Current Count for the requested FMS Stream. Once synchronized with the FMS Current Count, the non-AP STA need not wake up at every DTIM interval to receive group addressed BUs. â€” If the Element Status value in the FMS Status subelement is one of â€œDeny, due to request format error or ambiguous classifierâ€, â€œDeny, due to lack of resources on APâ€, â€œDeny, due to requested classifier(s) matching 2 or more existing streams on different intervalsâ€, â€œDeny, by policy, requested stream or filter is not permitted to participate in the serviceâ€, and â€œDeny, reason unspecifiedâ€: â€” The AP does not deliver the requested streams at the delivery interval as specified by the non- AP STA in the FMS Request element. The AP delivers the requested stream at every DTIM interval. â€” If the Element Status value in the FMS Status subelement is one of â€œAlternate proposed, due to existing stream with different delivery intervalâ€, â€œAlternate proposed, due to policy limits on APâ€, â€œAlternate proposed, because the AP changed the delivery intervalâ€, and â€œAlternate proposed, because the AP changed the maximum delivery intervalâ€: â€” The AP does not deliver the requested streams at the delivery interval and maximum delivery interval as specified by the non-AP STA in the FMS Request element. The FMS Status subelement specifies a delivery interval and a maximum delivery interval that the AP is willing to accept for the specified streams if the non-AP STA sends another FMS Request with that delivery interval and maximum delivery interval specified. â€” The non-AP STA may submit a new FMS Request that includes the delivery interval value received from the AP. If the AP accepts this new FMS Request, it shall respond as described in 11.2.3.16.2. 1620 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” If the Element Status value in the FMS Status subelement is â€œAlternate proposed, because the AP is unable to provide requested TCLAS-based classifiersâ€: â€” The AP does not deliver the requested streams at the delivery interval as specified by the non- AP STA in the FMS Request element. The TCLAS element(s) or TCLAS Processing element in the TCLAS Status subelement contains one or more fields or subfields whose values have been modified by the AP. The AP may include fewer TCLAS elements in the FMS Response element than were present in the request; when the APâ€™s response includes a single TCLAS element, it does not include a TCLAS Processing element. If the AP changes a TCLAS elementâ€™s Classifier Type field in the FMS Response element but is unable to suggest a value for the Classifier Mask field, it shall set that field to 0. If the AP changes a TCLAS elementâ€™s Classifier Type field or Classifier Mask field in the FMS Response element but is unable to suggest values for one or more Classifier Parameter subfields, it shall set those fields to 0. â€” A non-AP STA receiving a modified TCLAS element having a Classifier Mask field equal to 0 or Classifier Parameter subfields equal to 0 shall interpret these values as meaning that no suggested value has been provided by the AP. â€” If the Element Status value in the FMS Status subelement is one of â€œTerminate, due to AP policy changeâ€, â€œTerminate, due to lack of resources of APâ€, and â€œTerminate, due to other FMS stream with higher priorityâ€: â€” The AP will terminate the use of FMS transmission rules for any FMS stream identified by FMSID. If the AP terminates the usage of FMS for a particular stream, the stream is transmitted at DTIM interval. â€” The non-AP STA shall wake up at every DTIM interval to receive group addressed BUs after receiving the FMS Response element. 11.2.3.17 TIM Broadcast Implementation of TIM Broadcast is optional for a WNM STA. A STA that implements TIM Broadcast has dot11TIMBroadcastImplemented equal to true. When dot11TIMBroadcastImplemented is true, dot11WirelessManagementImplemented shall be true. A STA whose dot11TIMBroadcastActivated value is true shall support TIM Broadcast and shall set to 1 the TIM Broadcast field of the Extended Capabilities elements that it transmits. This subclause describes TIM broadcast procedures for STAs whose dot11TIMBroadcastActivated is true. TIM frames have shorter duration than Beacon frames and are potentially transmitted at a higher data rate. TIM Broadcast allows a non-AP STA to receive a TIM element without receiving a Beacon frame that may reduce the required wake time in a power save mode. The shorter receive time reduces the power consumption for non-AP STAs in a power save mode. The shorter receive time may reduce the power consumption for stations in a standby mode. A non-AP STA may activate the TIM broadcast service by including a TIM Broadcast Request element in a TIM Broadcast Request frame, Association Request frame or Reassociation Request frame that is transmitted to the AP, which specifies the requested interval between TIM frame transmissions (the TIM broadcast interval). On receipt of a properly formatted TIM Broadcast Request element in a TIM Broadcast Request frame, Association Request frame or Reassociation Request frame, the AP shall include a TIM Broadcast Response element in the corresponding TIM Broadcast Response frame, Association Response frame or Reassociation Response frame, when dot11TIMBroadcastActivated is true. When the requested TIM broadcast interval is acceptable, the AP shall include a TIM Broadcast Response element specifying the requested TIM broadcast interval and a Status field indicating â€œAcceptâ€ when no valid TSF timestamp is present in the TIM frames, or â€œAccept, valid timestamp present in TIM framesâ€ when a valid TSF timestamp is present in the TIM frames. When the AP overrides the requested TIM broadcast interval, it shall include a TIM Broadcast Response element specifying a different TIM broadcast interval and a Status field indicating â€œOverriddenâ€ when no valid TSF timestamp is present in the TIM frames, or â€œOverridden, valid timestamp present in TIM framesâ€ when a valid TSF timestamp is present in the TIM frames, and include in the TIM 1621 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Broadcast Response element the smallest TIM broadcast interval that is currently active. Otherwise, the AP shall include a TIM Broadcast Response element with a Status field indicating â€œDenied.â€ The Status field in a TIM Broadcast Response element that is included in an Association Response frame or Reassociation Response frame has implications only for the TIM Broadcast negotiation. NOTEâ€”The STA might ignore the TIM Broadcast Interval field in the TIM Broadcast Response element if the Status field indicates â€œAcceptâ€ or â€œAccept, valid timestamp present in TIM framesâ€, because the TIM broadcast interval is the requested one. An AP transmitting a TIM frame with a valid TSF timestamp shall set the value of the TIM frame timestamp as defined in 11.1.3, for the Beacon frame timestamp. If the AP accepted at least one TIM Broadcast Request with a nonzero TIM Broadcast Interval field, and at least one non-AP STA in PS mode still associated with the AP received in its latest TIM Broadcast Response a status field value equal to 0 (Accepted) in response to a TIM Broadcast Request with a nonzero TIM Broadcast Interval field, the AP shall transmit one or two TIM frames per TIM Broadcast Interval. The AP shall not transmit TIM frames otherwise. When TIM broadcast intervals overlap, a transmitted TIM frame serves both intervals and does not need to be duplicated. If the AP transmits two TIM frames per TIM Broadcast Interval, the AP shall transmit the high data rate TIM frame first, followed by the low data rate TIM frame. The AP shall transmit the low data rate TIM frame at the same data rate or MCS as the Beacon frame. The AP shall transmit the high data rate TIM frame at a higher data rate or using an MCS that corresponds to a higher data rate. For Clause 18 and Clause 19 PHYs, if the Beacon frame is transmitted using ERP-DSSS/ CCK, the AP shall transmit the high data rate TIM frame and shall transmit it using ERP-OFDM. Otherwise, transmitting the high data rate TIM frame is optional. If the high data rate TIM is not transmitted, the AP shall set the High Data Rate TIM field to 0 in the TIM Broadcast Response element. The value of the TIM Broadcast Interval field from the latest received TIM Broadcast Response element (N_TBI) together with dot11BeaconPeriod define a series of target TIM transmission times (TTTTs) N_TBI dot11BeaconPeriod TUs apart. Time 0 is a TTTT. A non-AP STA may use the information in the High Rate TIM Rate and Low Rate TIM Rate fields to determine which of the two TIM frames they will be receiving. The first TIM frame per TIM broadcast interval is scheduled to be transmitted at the TTTT plus the indicated TIM broadcast offset. The offset may have a negative value that allows the TIM frame(s) to be transmitted before the TBTT. The value of the offset shall not be changed as long as an associated non-AP STA is using the TIM broadcast service. The AP should accept new TIM broadcast interval requests if this implies transmitting TIM frames more frequently. For instance, if the AP currently transmits TIM frames every fourth beacon period and it receives a new request for every 3 beacon periods, then the AP should accept the new request and transmit TIM frames both every 3 and every 4 beacon periods. The AP may override incongruent requests once available resources (such as counters) have been depleted. An incongruent request is a request that contains an interval that is not an integer divide or a multiple of a currently active TIM Broadcast interval. The AP shall accept a TIM broadcast interval of 1. NOTEâ€”The DTIM Period subfield in a TIM element in a TIM frame indicates the period for DTIM Beacon frames and is unrelated to any TIM Broadcast Interval(s). The AP shall increase the value (modulo 256) of the Check Beacon field in the next transmitted TIM frame(s) when a critical update occurs to any of the elements inside the Beacon frame. The following events shall classify as a critical update: a) Inclusion of a Channel Switch Announcement element b) Inclusion of an Extended Channel Switch Announcement element 1622 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications c) Modification of the EDCA parameters element d) Inclusion of a Quiet element e) Modification of the DSSS Parameter Set f) Modification of the CF Parameter Set element g) Modification of the HT Operation element h) Inclusion of a Wide Bandwidth Channel Switch element i) Inclusion of a Channel Switch Wrapper element j) Inclusion of an Operating Mode Notification element k) Inclusion of a Quiet Channel element l) Modification of the VHT Operation element An AP may classify other changes in the Beacon frame as critical updates. The non-AP STA shall attempt to receive the next Beacon frame when it receives a Check Beacon field that contains a value that is different from the previously received Check Beacon field. When dot11MultiBSSIDActivated is true, the bitmap of the TIM element is interpreted as specified in 9.4.2.6. When dot11MultiBSSIDActivated is true, the A1 field of the TIM frame is the Broadcast address, the A2 field and the A3 field are set to the transmitted BSSID. 11.2.3.18 WNM sleep mode 11.2.3.18.1 WNM sleep mode capability Implementation of the WNM sleep mode capability is optional for a WNM STA. A STA that implements WNM sleep mode has dot11WNMSleepModeImplemented equal to true. When dot11WNMSleepModeImplemented is true, dot11WirelessManagementImplemented shall be true. A STA where dot11WNMSleepModeActivated is true is defined as a STA that supports WNM sleep mode. A STA supporting WNM sleep mode shall set the WNM Sleep Mode field of the Extended Capabilities element to 1. When dot11WNMSleepModeActivated is true, dot11TFSActivated shall be true. A STA in which dot11WNMSleepModeActivated is true may send a WNM Sleep Mode Request or WNM Sleep Mode Response frame to a STA within the same infrastructure BSS whose last received Extended Capabilities element contained a value of 1 for the WNM Sleep Mode field in the Extended Capabilities field. WNM sleep mode is a service that may be provided by an AP to its associated STAs. The WNM sleep mode is not supported in an IBSS. WNM sleep mode enables an extended power save mode for non-AP STAs in which a non-AP STA need not listen for every DTIM Beacon frame, and need not perform GTK/IGTK updates. A non-AP STA can sleep for extended periods as indicated by the WNM Sleep Interval field of the WNM Sleep Mode element, which is present in WNM Sleep Mode Request frames transmitted by the non-AP STA. 11.2.3.18.2 WNM sleep mode non-AP STA operation To use the WNM sleep mode service, the non-AP STAâ€™s SME shall issue an MLME-SLEEPMODE.request primitive to send a WNM Sleep Mode Request frame. The MLME-SLEEPMODE.request primitive shall include a valid SleepMode parameter with a WNM Sleep Mode element. The Action Type field in the WNM Sleep Mode element shall be set to â€œEnter WNM sleep modeâ€ and the WNM Sleep Interval field shall be included. The WNM Sleep Interval field shall be less than the BSS max idle period (see 11.24.13). The 1623 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MLME-SLEEPMODE.request primitive shall also include a valid TFSRequest parameter as defined in the TFS Request element that the AP shall use as triggers to set the STAâ€™s TIM bit. When a traffic filter for group addressed frames is enabled at the AP, the STA may request a notification frame (see 11.24.12.2) be sent when requesting the establishment of the traffic filtering agreement. The receipt of an MLME-SLEEPMODE.confirm primitive with a valid SleepMode parameter indicates to the STAâ€™s SME that the AP has processed the corresponding WNM Sleep Mode Request frame. The content of the WNM sleep mode parameter in the WNM Sleep Mode Response frame provides the status of WNM Sleep Mode elements processed by the AP. The non-AP STA shall delete the GTKSA if the response indicates success. If RSN is used with management frame protection, the non-AP STA shall delete the IGTKSA if the response indicates success. While in WNM sleep mode, the non-AP STA need not wake up every DTIM interval for group addressed frames. The STA wakes up at intervals not longer than the value indicated by the WNM Sleep Interval field to check whether the corresponding TIM bit is set or group addressed traffic is pending. The non-AP STA does not participate in GTK/IGTK updates. To exit WNM sleep mode, the non-AP STAâ€™s SME shall issue an MLME-SLEEPMODE.request primitive to send a WNM Sleep Mode Request frame with an Action Type field in the WNM Sleep Mode element set to â€œExit WNM sleep modeâ€ If a STA receives an unsolicited WNM Sleep Mode Response frame with the WNM Sleep Mode Response status value (see Table 9-204) equal to 1, the STA exits WNM sleep mode. 11.2.3.18.3 WNM sleep mode AP operation When an APâ€™s SME receives an MLME-SLEEPMODE.indication primitive with a valid SleepMode parameter and an Action Type in the WNM Sleep Mode element of â€œEnter WNM sleep modeâ€ it shall issue an MLME-SLEEPMODE.response primitive with SleepMode parameters indicating the status of the request.The value of the Action Type field of the WNM Sleep Mode element in the WNM Sleep Mode Response frame shall be set to â€œEnter WNM sleep modeâ€. When WNM sleep mode is enabled for an associated STA, the AP shall stop sending all individually addressed MPDUs to the non-AP STA. The AP may disassociate or deauthenticate the STA at any time for any reason while the non-AP STA is in WNM sleep mode. An AP shall perform the TFS AP operation, as specified in 11.24.12 for non-AP STAs for which it has received TFS Request elements. The AP shall set the TIM bit corresponding to the AID of the associated STA for which the AP has queued either a TFS Notify frame or matching frame. An AP shall not perform GTK/IGTK updates for the STAs in WNM sleep mode. When an APâ€™s SME receives an MLME-SLEEPMODE.indication primitive with a valid SleepMode parameter and an Action Type in the WNM Sleep Mode element of â€œExit WNM sleep modeâ€ the AP shall disable WNM sleep mode service for the requesting STA, and the APâ€™s SME shall issue an MLME- SLEEPMODE.response primitive with a SleepMode parameter indicating the status of the associated request. When all traffic filter sets established for a STA are deleted upon frame matches, the AP shall also disable the WNM sleep mode service and transmit to the STA an unsolicited WNM Sleep Mode Response frame with the WNM Sleep Mode Response status value (see Table 9-204) set to 1. If RSN is used with management frame protection and a valid PTK is configured for the STA, the current GTK and IGTK shall be included in the WNM Sleep Mode Response frame. If a GTK/IGTK update is in progress, the pending GTK and IGTK shall be included in the WNM Sleep Mode Response frame. If RSN is used without management frame protection and a valid PTK is configured for the STA, the current GTK shall be sent to the STA using a group key handshake (see 12.7.7) immediately following the WNM Sleep Mode Response frame. 1624 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.2.3.19 VHT TXOP power save A VHT AP supports the operation of non-AP VHT STAs in TXOP power save mode in a BSS when the dot11VHTTXOPPowerSaveOptionImplemented at the AP is true. Non-AP VHT STAs that are in active mode and have dot11VHTTXOPPowerSaveOptionImplemented equal to true operate in TXOP power save mode. A STA that has dot11VHTTXOPPowerSaveOptionImplemented equal to true shall set the TXOP PS field in the VHT Capabilities element to 1; otherwise, the STA shall set the field to 0. A VHT AP may allow non-AP VHT STAs in TXOP power save mode to enter the doze state during a TXOP, which the AP does by transmitting a VHT PPDU with the TXVECTOR parameter TXOP_PS_NOT_ALLOWED set to 0. The value of this parameter in the TXVECTOR of all VHT PPDUs transmitted by the VHT AP may be changed from 1 to 0 during the TXOP to enable TXOP power save mode for the remainder of the TXOP. The value of this parameter in the TXVECTOR of all VHT PPDUs transmitted by VHT AP shall not be changed from 0 to 1 during the TXOP. If the dot11VHTTXOPPowerSaveOptionImplemented at VHT AP is false then the VHT AP shall set the TXOP_PS_NOT_ALLOWED to 1 in the TXVECTOR of the frames with FORMAT VHT. If the AP allows non-AP VHT STAs to enter doze state during a TXOP, then a non-AP VHT STA that is in TXOP power save mode may enter the doze state until the end of that TXOP when one of the following conditions is met: â€” On receipt of a VHT MU PPDU, the STA determines that it is not a member of the group indicated by the RXVECTOR parameter GROUP_ID. â€” On receipt of an SU PPDU, the STA determines that the RXVECTOR parameter PARTIAL_AID is not equal to 0 nor does it match the STAâ€™s partial AID. â€” The STA finds that the PARTIAL_AID in the RXVECTOR matches its partial AID but the RA in the MAC header of the corresponding frame that is received correctly does not match the MAC address of the STA. â€” The STA receives a frame with an RXVECTOR parameter NUM_STS equal to 0 if it is a member of group indicated by RXVECTOR GROUP_ID. â€” In a received VHT NDP Announcement frame, the STA finds that the RXVECTOR parameter PARTIAL_AID is 0 and the AID in the STA Info field is not its AID. â€” The STA receives a frame intended for it with the More Data subfield equal to 0 and the Ack Policy subfield in the QoS Control field is equal to No Ack or sends an acknowledgment if Ack Policy subfield is not equal to No Ack. The VHT AP shall include a nav-set sequence (e.g., RTS/CTS) (see G.4 at the beginning of such a TXOP with the Duration/ID value set to the remainder of the TXOP duration. A VHT AP shall not transmit frames to a non-AP VHT STA that has been allowed to enter doze state according to the conditions above for the remainder of the TXOP. NOTEâ€”A VHT AP does not transmit VHT SU PPDUs in the current TXOP if the AP has already transmitted a VHT PPDU with the TXVECTOR parameter TXOP_PS_NOT_ALLOWED set to 0 in the same TXOP and does not want the STAs that are in awake state to enter the doze state. If a VHT AP truncates the TXOP in which it allowed STAs to enter doze state, then the VHT AP shall not transmit frames to the STAs that were allowed to enter the doze state until the NAV set at the start of the TXOP has expired. Under all of the following conditions: â€” an AP transmitted a PPDU; â€” the PPDU contains individually addressed frame that contains all or part of an MSDU, A-MSDU or MMPDU; â€” the frame is addressed to a non-AP VHT STA that is in TXOP power save mode; 1625 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” the value of the frameâ€™s More Data subfield is 0; â€” the transmitted PPDUâ€™s TXVECTOR parameter TXOP_PS_NOT_ALLOWED is 0; â€” the AP did not receive an acknowledgment to this transmission; then the AP shall retransmit that frame one or more times within the same TXOP, subject to applicable transmission restrictions. These restrictions include retry and lifetime limits, the TXOP limit and the rules on TXOP sharing (see 10.22.2.6). If an acknowledgment to the retransmission of this last frame in the same TXOP is not received, it may wait until the next TXOP to further retransmit that frame, subject to its applicable retry or lifetime limit. NOTEâ€”An AP that receives from a VHT STA in TXOP power save mode a BlockAck frame that is a response to an A- MPDU containing MPDUs with the More Data subfield equal to 0 cannot expect to receive a response to subsequent MPDUs retransmitted in the same TXOP because the VHT STA might be in the doze state. A VHT STA that is in TXOP power save mode and has entered doze state shall continue to operate its NAV during doze state and shall transition into awake state on the expiration of the NAV. NOTEâ€”The STA can contend for access to the medium immediately on the expiration of the NAV. 11.2.4 Power management in an IBSS 11.2.4.1 Introduction Subclause 11.2.4 specifies the power management mechanism for use within an IBSS. 11.2.4.2 Basic approach A STA can be in one of two power management modes: â€” Active mode: The STA receives and transmits frames at any time. The STA remains in the awake state. â€” Power save (PS) mode: The STA enters the awake state to receive or transmit frames. The STA remains in the doze state otherwise. The basic approach is similar to the infrastructure case in that the STAs are synchronized, and group addressed BUs and the BUs that are to be transmitted to a power-conserving STA are first announced during a period when all STAs are awake. The announcement is done via an ATIM frame sent in an ATIM window. A STA in the PS mode shall listen for these announcements to determine if it needs to remain in the awake state. The presence of the ATIM window in the IBSS indicates if the STA may use PS mode. To maintain correct information on the power save state of other IBSS STAs, a STA needs to remain awake during the ATIM window. At other times the STA may enter the doze state except as indicated in the following procedures. When a BU is to be transmitted to a destination STA that is in a PS mode, the transmitting STA first transmits an ATIM frame during the ATIM window, in which all of the STAs including those operating in a PS mode are awake. The ATIM window is defined as a specific period of time, defined by the value of the ATIM Window field in the IBSS Parameter Set supplied to the MLME-START.request primitive, following a TBTT, during which only Control frames that are RTS, CTS, or Ack frames; Management frames that are Beacon or ATIM frames; or (QoS) Null frames shall be transmitted. ATIM frame transmission times are randomized, after a Beacon frame is either transmitted or received by the STA, using the backoff procedure with the CW equal to aCWmin. Individually addressed ATIM frames shall be acknowledged. If a STA transmitting an individually addressed ATIM frame does not receive an acknowledgment, the STA shall execute the backoff procedure for retransmission of the ATIM frame. Group addressed ATIM frames shall not be acknowledged. 1626 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If a STA receives an individually addressed ATIM frame during the ATIM window, it shall acknowledge the individually addressed ATIM frame and stay awake to receive the announced BUs for the entire beacon interval or until it has completed successful transmission to and reception from the source STA of the received ATIM frame, a frame with the EOSP subfield equal to 1. If a STA does not receive an ATIM frame, it may enter the doze state at the end of the ATIM window. Transmissions of BUs announced by ATIM frames are randomized after the ATIM window, using the backoff procedure described in Clause 10. It is possible that an ATIM frame may be received from more than one STA, and that a STA that receives an ATIM frame may receive more than a single BU from the transmitting STA. ATIM frames are only addressed to the destination STA of the BU. An ATIM frame for a BU shall have a destination address identical to that of the BU. After the ATIM interval, only individually addressed BUs that have been successfully announced with an acknowledged ATIM frame and group addressed BUs that have been announced with an ATIM frame shall be transmitted to STAs in the PS mode. These frames shall be transmitted using the DCF (for non-QoS STAs) or EDCAF (for QoS STAs). Figure 11-8 illustrates the basic PS operation. Figure 11-8â€”Power management in an IBSSâ€”basic operation The estimated power-saving state of another STA may be based on the power management information transmitted by that STA and on additional information available locally, such as a history of failed transmission attempts. The use of RTS/CTS in an IBSS may reduce the number of transmissions to a STA that is in PS mode. If an RTS frame is sent and a CTS frame is not received, the transmitting STA may assume that the destination STA is in PS mode. The method of estimating the power management state of other STAs in the IBSS is outside the scope of this standard. 1627 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.2.4.3 Initialization of power management within an IBSS The following procedure shall be used to initialize power management within a new IBSS, or to learn about the power management being used within an existing IBSS: a) A STA joining an existing IBSS by the procedure in 11.1.4.4 shall update its ATIM window with the value contained in the ATIM Window field of the IBSS Parameter Set element within the Beacon or Probe Response frame received during the scan procedure. b) A STA creating a new IBSS by the procedure in 11.1.4.4 shall set the value of the ATIM Window field of the IBSS Parameter Set element within the Beacon frames transmitted to the value of its ATIM window. c) The start of the ATIM window shall be the TBTT, defined in 11.1.3.5. The end of the ATIM window shall be defined as TSF timer mod dot11BeaconPeriod = ATIMWindow, where ATIMWindow is the value of the ATIM Window field of the IBSS Parameter Set from the MLME-START.request or MLME-JOIN.request primitives. d) The ATIM window period shall be static during the lifetime of the IBSS. e) An ATIM window value of 0 shall indicate that power management is not usable within the IBSS. 11.2.4.4 STA power state transitions A STA may enter PS mode if the value of the ATIM window in use within the IBSS is greater than 0. A STA shall not enter PS mode if the value of the ATIM window in use within the IBSS is equal to 0. A STA shall indicate its power management mode in the Power Management subfield of the Frame Control field of frames containing all or part of a BU or individually addressed Probe Request frame, or (QoS) Null frames, that it transmits. A STA in PS mode shall transition between awake state and doze state according to the following rules: a) If a STA is operating in PS mode, it shall enter the awake state prior to each TBTT. b) If a STA receives a group addressed ATIM frame during the ATIM window, the STA shall remain in the awake state until either the STA receives a group addressed frame from the source STA with the EOSP subfield equal to 1 or the end of the next ATIM window, whichever occurs first. c) If a STA receives at least one individually addressed ATIM frame containing the STAâ€™s individual address in the RA field during the ATIM window then the STA shall remain in the awake state at least until the earlier of the completion of the successful transmission to and reception from the source STA of each received ATIM frame, a frame with the EOSP subfield equal to 1, and the end of the next ATIM window. d) If a STA transmits at least one individually addressed ATIM frame containing a STAâ€™s individual address in the RA field during the ATIM window then the STA shall remain in the awake state at least until the earlier of the completion of the successful transmission to and reception from the destination STA of each transmitted ATIM frame, a frame with the EOSP subfield equal to 1, and the end of the next ATIM window. e) If a STA transmits a Beacon, the STA shall remain in the awake state until the end of the next ATIM window. f) If the STA has not transmitted an ATIM frame and does not receive either an individually addressed ATIM frame containing the STAâ€™s individual address, or a group addressed ATIM frame during the ATIM window, the STA may return to the doze state following the end of the current ATIM window. 1628 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.2.5 Power management in an MBSS Power management in an MBSS is described in 14.14. 11.2.6 SM power save A STA consumes power on all active receive chains, even though they are not necessarily required for the actual frame exchange. The SM power save feature allows a non-AP HT STA in an infrastructure BSS to operate with only one active receive chain for a significant portion of time. The STA controls which receive chains are active through the PHY-RXCONFIG.request primitive specifying a PHYCONFIG_VECTOR parameter ACTIVE_RXCHAIN_SET that indicates which of its receive chains should be active. In dynamic SM power save mode, the STA enables its multiple receive chains when it receives the start of a frame exchange sequence addressed to it. Such a frame exchange sequence shall start with a single-spatial stream individually addressed frame that requires an immediate response and that is addressed to the STA in dynamic SM power save mode. An RTS/CTS sequence may be used for this purpose. The STA shall, subject to its spatial stream capabilities (see 9.4.2.56.4 and 9.4.2.158.3) and operating mode (see 11.42), be capable of receiving a PPDU that is sent using more than one spatial stream a SIFS after the end of its response frame transmission. The STA switches to the multiple receive chain mode when it receives the frame addressed to it and switches back immediately when the frame exchange sequence ends. NOTEâ€”A STA in dynamic SM power save mode cannot distinguish between an RTS/CTS sequence that precedes a MIMO transmission and any other RTS/CTS and, therefore, always enables its multiple receive chains when it receives the RTS addressed to it. The STA can determine the end of the frame exchange sequence through any of the following: â€” It receives an individually addressed frame addressed to another STA. â€” It receives a frame with a TA that differs from the TA of the frame that started the TXOP. â€” The CS mechanism (see 10.3.2.1) indicates that the medium is idle at the TxPIFS slot boundary (defined in 10.3.7). In static SM power save mode, the STA maintains only a single receive chain active. The STA may use the SM Power Save frame to communicate its SM power save state. The STA may also use SM Power Save subfield in the HT Capabilities element of its (Re)Association Request frame to achieve the same purpose. The latter allows the STA to use only a single receive chain immediately after (re)association. A STA that has one or more DLS or TDLS links shall not operate in SM power save mode. Changes to the number of active receive chains are made only after the SM power save mode indication has been successfully delivered (i.e., by acknowledgment of a frame carrying the HT Capabilities element or by acknowledgment of a SM Power Save frame). The SM power save mode indication shall be transmitted using an individually addressed frame. 1629 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.2.7 Power management in a PBSS and DMG infrastructure BSS 11.2.7.1 General Power save mechanisms in this subclause enable non-AP STAs to sleep for one or more beacon intervals or for parts of a beacon interval. The non-AP and non-PCP STA power save mechanisms defined in 11.2.7.2 enable a non-AP and non-PCP STA to sleep after signaling the AP or PCP, or to sleep according to a periodic schedule that is negotiated with the AP or PCP. A non-AP and non-PCP STA may use both mechanisms in conjunction to increase its power save opportunity. Similarly, the PCP power save mechanisms defined in 11.2.7.3 enable a PCP to sleep after signaling at least one non-AP and non-PCP STA, or to sleep according to a wakeup schedule that is available to all STAs associated with the PCP. A non-AP STA can be in one of two power management modes: â€” Active mode: The STA does not use any of the scheduled or unscheduled power save mechanisms defined in this subclause and operates in the awake state, except during time intervals that it determines it is not the target of any transmission by other STAs, where it may operate in doze state. â€” Power save (PS) mode: The STA uses at least one of the scheduled or unscheduled power save mechanisms defined in this subclause and switches between awake and the doze states. A non-AP STA shall be in active mode upon (re)association. For scheduled power save, the DMG Wakeup Schedule element (9.4.2.131) is used to communicate the sleep and wakeup pattern of a DMG STA, referred to as the STA wakeup schedule (WS). A STA wakeup schedule defines a periodic routine of cycling between a set of contiguous beacon intervals referred to as awake BIs and a set of contiguous beacon intervals referred to as doze BIs. The rules for alternating between awake and doze power states during awake BIs and doze BIs are defined in 11.2.7.2.3 and 11.2.7.3.3. An overview of these rules is given in Table 11-2 and Table 11-3. A STA in PS mode that is following a wakeup schedule and has also exercised unscheduled power save shall follow the doze BI rules in this subclause and shall follow the ATIM rules in 11.2.7.4 for a non-AP STA without wakeup schedule. An AP or PCP keeps track of the wakeup schedules of all associated non-AP and non-PCP STAs. A non-AP and non-PCP STA keeps track of the wakeup schedule of all associated non-AP and non-PCP STAs that it is communicating with. There is no end time to a wakeup schedule. Once a STA enters PS mode according to its wakeup schedule it stays indefinitely in PS mode until it leaves the PS mode through mechanisms defined in this subclause. Once a STA is made aware of the wakeup schedule of another STA, it is able to keep track of the wakeup schedule on its own. Each STA delivers traffic to a peer STA only when the peer STA is in awake state. A STA that has transmitted a frame to an AP or PCP with which it is not associated and from which it expects a response shall remain in the awake state until such a response is received or until the procedure has timed out. An AP shall buffer BUs addressed to non-AP STAs in doze state. The buffered BUs shall be transmitted only at designated times (11.2.7.2). A non-AP STA shall defer delivery of BUs addressed to other non-AP STAs in doze state. The BUs shall be transmitted only at designated times (11.2.7.2). 1630 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If a PCP sets the BSS Type field within a transmitted DMG Beacon frame to PBSS or the AP or PCP includes a Nontransmitted BSSID Capability element in a transmitted DMG Beacon, Announce, or Probe Response frames and the BSS Type field within the Nontransmitted BSSID Capability element is equal to PBSS, then the AP or PCP shall follow the PCP power management rules described in 11.2.7.3 if the AP or PCP chooses to employ power management. An AP or PCP may include an Antenna Sector ID Pattern element in Power Save Configuration Response and Probe Response frames transmitted to a non-AP and non-PCP STA. If a non-AP and non-PCP STA uses the information contained in the Antenna Sector ID Pattern element received from its AP or PCP, then during the BTI of an awake BI, the STA might stay awake just to receive DMG Beacon frames transmitted through specific DMG antenna and sector and switch to doze state during other periods in the BTI. Table 11-2 lists the power states for a non-AP and non-PCP STA in PS mode and a PCP in PS mode during an awake BI. Each entry indicates the state, either awake or doze, for the non-AP and non-PCP STA or the PCP in PS mode at various times during the awake BI. Table 11-2â€”Power states for an awake BI PS non-AP and Portion of the beacon interval PPS PCP non-PCP STA BHI BTI Awake Awake or doze A-BFT Awake Awake or doze ATI Awake Awake DTI CBAP with the PCP Active field set to 1 in the schedule Awake or doze Awake or doze CBAP with the PCP Active field set to 0 in the schedule Doze Awake or doze SP with Destination AID set to broadcast AID Awake Awake Nontruncatable or nonextensible SP with non-PCP STA as Awake or doze Awake or doze Source AID or Destination AID Truncatable SP or extensible SP with non-AP and non-PCP Awake Awake or doze STA (excluding the PS STA) as Source AID or Destination AID SPs allocated to itself Awake or doze Awake or doze All other SPs Awake or doze Awake or doze Awake window Awake Awake DTI with CBAP Only subfield set to 1 Awake or doze Awake or doze Destination AID field of a CBAP equal to the broadcast AID Awake or doze Awake or doze in the schedule Table 11-3 lists the power states for a non-AP and non-PCP STA in PS mode and a PCP in PS mode during a doze BI. Each entry indicates the state, either awake or doze, for the non-AP and non-PCP STA or the PCP in PS mode at various times during the doze BI. 1631 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 11-3â€”Power states for a doze BI PS non-AP and Portion of the beacon interval PPS PCP non-PCP STA BHI BTI N/A Awake or doze A-BFT N/A Awake or doze ATI Awake Awake DTI CBAP with the PCP Active field set to 1 in the schedule Doze Doze CBAP with the PCP Active field set to 0 in the schedule Doze Doze SP with Destination AID set to broadcast AID Doze Doze SP with individually addressed destination AID Doze Awake Nontruncatable or nonextensible SP with non-PCP STA as Doze Doze Source AID or Destination AID Truncatable SP or extensible SP with non-AP and non-PCP Doze Doze STA (excluding the PS STA) as Source AID or Destination AID SPs allocated to itself Doze Doze All other SPs Doze Doze DTI with CBAP Only subfield set to 1 Doze Doze Destination AID field of a CBAP equal to the broadcast AID Doze Doze in the schedule The source DMG STA and the destination DMG STA of a nontruncatable SP or allocated CBAP with individually addressed destination AID may go to doze state within the SP or within the CBAP, respectively, after the source DMG STA transmitted a frame to the destination DMG STA of the SP or the CBAP, respectively, with the EOSP subfield set to 1 and received the following response frame from the destination DMG STA of the SP or the CBAP, respectively. If the MM-SME Power Mode field within the MMS element sent by an MM-SME coordinated STA is 1, all STAs advertised in the MMS element shall switch to the doze state when the wakeup schedule of any one STA or a successful frame exchange as described in Annex G brings the STA to the doze state. If the MM-SME Power Mode field within the MMS element sent by an MM-SME coordinated STA is 0, all STAs advertised in the MMS element shall switch to the awake state when the wakeup schedule of any one STA or a successful frame exchange as described in Annex G brings the STA to the awake state. 11.2.7.2 Non-AP and non-PCP STA power management mode 11.2.7.2.1 General The power management mode of a non-AP and non-PCP STA is selected by the PowerManagementMode parameter of the MLME-POWERMGT.request primitive. Once the STA updates its power management mode, the MLME shall issue an MLME-POWERMGT.confirm primitive indicating the result of the operation. While the STA is in PS mode it may exercise the unscheduled and scheduled power save mechanisms described in this subclause. 1632 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Figure 11-9 illustrates a finite state machine that shows the state transition of a STA in active and PS mode, and also the transition between active and PS modes when the non-AP and non-PCP STA has set up a wakeup schedule. NOTEâ€”In Figure 11-9, the notations PSC-REQ(X) and PSC-RSP(Y) indicate that the PSC-REQ and PSC-RSP frames, respectively, are transmitted with the setting as indicated by their corresponding X and Y parameters. The transitions shown â€œAs per T1â€ are defined in Table 11-2. The transitions shown â€œAs per T2â€ are defined in Table 11-3. As per STA o p e r a t io n P S C â€R E Q (D P M = 1 , W S ) S c h e d u le d a n d w it h o u t a & & P S C â€ R S P (R e je c t , A c t iv e S c h e d u le d U n s c h e d u le d U n s c h e d u le d P S w akeu p W S_new ) m ode P S C â€ R E Q (D P M = 1 ,W S ) PS m ode PS m ode m ode s c h e d u le & & P S C â€R S P As per W S e le m e n t U n s c h e d u le d A w ake BI D oze BI PS m ode BI As per W S e le m e n t As per A T IM fr a m e u s a g e fo r As per T1 pow er m anagem ent of L o c a l d e c is io n As per T2 n o n â€A P S T A s A w ake D oze Aw ake D oze pow er pow er A w ake D oze A w ake D oze pow er pow er sta te sta te pow er pow er pow er pow er sta te sta te sta te sta te sta te sta te As per T1 As per T2 As per L o c a l d e c is io n A T IM f r a m e u s a g e fo r p o w e r m anagem ent of n o n â€A P S T A s Figure 11-9â€”State transition diagram of non-AP and non-PCP STA in active and PS modes 11.2.7.2.2 Non-AP and non-PCP STA operation without a wakeup schedule To change its power state without a wakeup schedule, a non-AP and non-PCP STA shall inform the AP or PCP by completing a successful frame exchange (as described in Annex G) that is initiated by the STA and that includes a Management frame, Extension frame or Data frame, and also an Ack or a BlockAck frame from the AP or PCP. The Power Management subfield(s) in the Frame Control field of the frame(s) sent by the STA in this exchange that contain a BU or are QoS Null frame indicate the power state that the STA shall adopt upon successful completion of the entire frame exchange. A non-AP and non-PCP STA shall not change its power state using a frame exchange that does not receive an Ack or BlockAck frame from the AP or PCP, or using a BlockAckReq frame. A non-AP and non-PCP STA in doze state shall limit the frames it transmits to the following: â€” A Management, Extension or Data frame that triggers an Ack or a BlockAck frame from the AP or PCP, with the Power Management subfield in the Frame Control field of the frame set to 0, i.e., a frame to indicate the STA intent to transition out of unscheduled PS mode. â€” A Management, Extension or Data frame that triggers an Ack or a BlockAck frame from the AP or PCP, plus Ack and Block Ack frames that respond to the frames sent by the AP or PCP during the reverse direction grant, if the following conditions apply: â€” the Power Management subfield in the Frame Control field of the frame sent by the non-AP and non-PCP STA is set to 1 1633 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” the AP or PCP has transmitted a Capability Information field in which the Triggered Unscheduled PS subfield is equal to 1 â€” An RTS, DMG CTS-to-self, CF-End, Grant, BRP, SSW or SSW-Feedback frame. NOTEâ€”A DMG STA in doze state may need to perform beamforming to restore its links with other DMG STAs. As long as there is at least one STA that has entered doze state through the unscheduled power save mechanism, the AP or PCP shall establish an awake window by transmitting an Awake Window element, and shall include a UPSIM element in every DMG Beacon and Announce frame it transmits. The AP or PCP may establish an awake window and/or include a UPSIM element in a DMG Beacon or Announce frame it transmits even if no STA is in doze state. The absence of a UPSIM element in a DMG Beacon or Announce frame is equivalent to presence of the UPSIM element in the frame with all bits of the Power Save Indication Bitmap field in the UPSIM element set to 0. The UPSIM element in every DMG Beacon or Announce frame transmitted by the AP or PCP shall indicate the power state of all STAs at the time of frame transmission. NOTEâ€”Transmitting a DMG Beacon frame with the Discovery Mode subfield set to 0, or an Announce frame, without including the UPSIM element in the frame, indicates that no STA is in unscheduled PS mode at the time of the frame transmission. A non-AP and non-PCP STA may also indicate its power state to another non-AP and non-PCP STA through the Power Management subfield in the Frame Control field of any frame that contains all or part of a BU. The non-AP and non-PCP STA shall indicate its correct power state in the Frame Control field of any frame it transmits that contains all or part of a BU. When a non-AP and non-PCP STA that has not set up a wakeup schedule with the AP or PCP enters PS mode, every beacon interval shall be an awake BI for that STA. A non-AP and non-PCP STA that has not set up a wakeup schedule with the AP or PCP and that is in PS mode shall be awake during any allocated SP for which the STA is either the source DMG STA or destination DMG STA during an awake BI. During an awake BI, a non-AP and non-PCP STA that has not set up a wakeup schedule with the AP or PCP and that is in PS mode shall be awake during any allocated CBAP for which the STA is the source DMG STA or destination DMG STA, or the source AID of the CBAP is equal to the broadcast AID or the destination AID of the CBAP is equal to the broadcast AID. A non-PCP and non-AP STA that has used unscheduled power save to enter doze state may offer an RDG to its AP or PCP if the following conditions apply: â€” the AP or PCP has transmitted a Capability Information field in which the Triggered Unscheduled PS field is equal to 1 â€” the non-AP and non-PCP has transmitted a Capability Information field in which the Reverse Direction subfield is equal to 1 The AP or the PCP may use the offered RDG to transmit one or more BUs to the non-PCP and non-AP STA using the reverse direction protocol defined in 10.28. The non-PCP and non-AP STA should continue to offer an RDG to the AP or to the PCP within the current TXOP while the Buffered AC subfield of the QoS Control field in frames transmitted by the AP or by the PCP indicates that one or more BUs are buffered for the AC for which the TXOP was gained. 11.2.7.2.3 Non-AP and non-PCP STA operation with a wakeup schedule To transition from active mode to PS mode, a non-AP and non-PCP STA that is associated with an AP or PCP shall establish a wakeup schedule (WS) with the AP or PCP. A WS is established with the AP or PCP following the successful transmission of a PSC-REQ frame to the AP or PCP with the DPM field set to 1 and an acknowledged receipt of the corresponding PSC-RSP frame from the AP or PCP provided that the PSC- RSP frame contained a status code indicating success. After receiving a PSC-RSP frame from the AP or PCP with a status code indicating success and responding with an acknowledgment, the STA switches to the 1634 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications PS mode at the instant specified by the BI Start Time field of the DMG Wakeup Schedule element transmitted to the AP or PCP. In PS mode, the STA shall cycle between awake BIs and doze BIs following the WS that the STA has established with the AP or PCP. As long as there is at least one STA that is in PS mode, the AP or PCP shall establish an awake window. The AP or PCP may include an Awake Window element in a DMG Beacon or Announce frame it transmits even if no STA in the BSS has entered PS mode. A DMG Wakeup Schedule element shall be included in any PSC-REQ frame that the STA transmits to the AP or PCP as an explicit request for a WS. An Awake Window element may also be included in the same PSC-REQ frame to indicate a requested duration for the awake window. If the AP or PCP accepts the proposed WS and the optionally present awake window duration in the PSC-REQ frame, it shall reply with a PSC-RSP frame indicating a status code of SUCCESS. Otherwise, it shall respond with a PSC-RSP frame with a status code indicating the reason for rejecting the request. The AP or PCP may suggest an alternative WS and optionally an awake window duration in the PSC-RSP frame and set the status code to REJECT_WITH_SCHEDULE. If the STA accepts the alternative WS, it shall include this WS in a subsequently transmitted PSC-REQ frame. If the non-AP and non-PCP STA does not accept the alternative WS, it shall not send a PSC-REQ frame for dot11PSRequestSuspensionInterval beacon intervals following the receipt of the PSC-RSP frame from the AP or PCP. NOTE 1â€”The AP or PCP can recommend an alternative WS, for example to align the awake BIs of some or all non-AP and non-PCP STAs. NOTE 2â€”The awake window duration sent by the AP or PCP in a PSC-RSP frame is to assist the STA for awake window planning. The awake window duration is always set by the Awake Window element in the most recent DMG Beacon or Announce frame received from the AP or PCP. If a non-AP and non-PCP STA has established a WS with the AP or PCP and the non-AP and non-PCP STA is in PS mode, the non-AP and non-PCP STA shall have m successive awake BIs repeating every n beacon interval, where n is the value of the Sleep Cycle field of the DMG Wakeup Schedule element contained in the PSC-RSP frame received from the AP or PCP during the frame exchange that established the WS, and m is the value of the Number of Awake BIs field in the DMG Wakeup Schedule element contained in that PSC-RSP frame. During each of its awake BIs, the non-AP and non-PCP STA shall be awake during the awake window if it is present, and during all allocated SPs in which it is either the source or destination DMG STA. An AP or PCP may send an unsolicited PSC-RSP frame without a WS and indicating a status code of success to a non-AP and non-PCP STA in PS mode. Upon receiving the unsolicited PSC-RSP frame meeting these conditions, the non-AP and non-PCP STA shall switch to active mode. 11.2.7.2.4 Non-AP and non-PCP STA operation with or without a wakeup schedule A non-AP and non-PCP STA in PS mode shall stay awake for dot11MinBHIDuration starting from the beginning of each awake BI and may switch to the doze state after the expiration of this time. The only exception is when the Power Save Configuration Response or Probe Response frame received from the AP or PCP includes an Antenna Sector ID Pattern element, in which case the non-AP and non-PCP STA may use the Antenna Sector ID Pattern element to receive DMG Beacon frames transmitted through a specific DMG antenna and sector, and may switch to doze state during other periods in the BTI. An AP or PCP shall transmit SP allocation announcements for STAs in PS mode during each of the STAsâ€™ awake BIs and may transmit those SP allocation announcements in other beacon intervals. New SPs shall be allocated to begin either within or after the later awake BI of the source DMG STA and destination DMG STA of the SP. To transition from PS mode to active mode, a non-AP and non-PCP STA that has an established WS with the AP or PCP shall send a PSC-REQ frame with the DPM field set to 0 to the AP or PCP and enter active 1635 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications mode following the reception of the Ack frame response. The AP or PCP shall not send a PSC-RSP frame if the DPM field is 0 in the PSC-REQ frame. In order for a STA to learn the WS of another STA within the BSS, the STA may send an Information Request frame to the other STA or to the AP or PCP as defined in 11.30.1. The AP or PCP maintains a WS distribution table for the lifetime of the BSS, and upon receiving an Information Request frame that contains a request for the WS of a STA identified by the Subject Address field within the frame, shall add an entry to the WS distribution table made up of the STA that transmitted the Information Request frame (the requesting STA) and the STA identified by the Subject Address field within the Information Request frame (the target STA). If the AP or PCP moves the TBTT, changes the duration of the beacon interval, or resets the TSF, the AP or PCP shall transmit an unsolicited Information Response frame with the updated DMG Wakeup Schedule element. When transmitting the DMG Wakeup Schedule element for a STA that is in PS mode, the transmitting STA shall use a value for the BI Start Time field that points to a TBTT that is earlier, but not more than 231 Âµs minus aDMGDWSValidPeriod earlier, than the TBTT of the beacon interval during which the BI Start Time field is transmitted, so that the receiving STA can correctly identify the power management mode of the STA the WS belongs to. If the Information Request frame is transmitted to the AP or PCP and the STA indicated in the Information Requestâ€™s Subject Address field does not have an established WS with the AP or PCP, the AP or PCP shall set the length of the DMG Wakeup Schedule element to 0 in the Information Response frame. 11.2.7.3 PCP power management mode 11.2.7.3.1 General The power management mode of a PCP is selected by the PowerManagementMode parameter of the MLME-POWERMGT.request primitive. Once the PCP updates its power management mode, the MLME shall issue an MLME-POWERMGT.confirm primitive indicating the result of the operation. While the PCP is in PS mode it may exercise the unscheduled and scheduled power save mechanisms described in this subclause. 11.2.7.3.2 PCP operation without a wakeup schedule To change its power state without a wakeup schedule, the PCP shall include a UPSIM element in or remove the UPSIM element from every DMG Beacon frame with the Discovery Mode subfield set to 0 and Announce frame that it transmits, and shall indicate its new power state in the UPSIM element if it is included in the frame NOTEâ€”The UPSIM element in a DMG Beacon frame with the Discovery Mode subfield set to 0, or in an Announce frame, includes the power state of the PCP at the time of the frame transmission. Transmitting a DMG Beacon frame with the Discovery Mode subfield set to 0 or an Announce frame, without including the UPSIM element in the frame, indicates that no STA (including the PCP) is in unscheduled PS mode at the time of the frame transmission. Alternatively, to change its power state without a wakeup schedule, the PCP shall inform all associated STAs by completing a successful frame exchange (as described in Annex G) that is initiated by the PCP and that includes a Management frame, Extension frame or Data frame, and also an Ack or a BlockAck frame from the associated STA. The Power Management subfield(s) in the Frame Control field of the frame(s) sent by the PCP in this exchange that contain a BU or are QoS Null frame indicate the power state that the PCP shall adopt upon successful completion of the entire frame exchange. The PCP shall not change its power state using a frame exchange that does not receive an Ack or BlockAck frame from the associated STA, or using a BlockAckReq frame. When attempting to enter doze state, the PCP shall not enter doze state unless it has received an Ack or BlockAck from each associated STA. When attempting to leave doze state, the PCP shall enter awake state as soon as it receives an Ack or BlockAck from one associated STA. 1636 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A PCP in doze state shall limit the frames it transmits to the following: â€” A Management, Extension or Data frame that triggers an Ack or a BlockAck frame from a non-AP and non-PCP STA, with the Power Management subfield in the Frame Control field of the frame set to 0, i.e., a frame to indicate the PCP intent to transition out of unscheduled PS mode. â€” A Management, Extension or Data frame that triggers an Ack or a BlockAck frame from a non-AP and non-PCP STA, plus Ack and BlockAck frames that respond to the frames sent by the non- AP and non-PCP STA during the reverse direction grant, if the following conditions apply: â€” the Power Management subfield in the Frame Control field of the frame sent by the PCP is set to 1 â€” the non-AP and non-PCP STA has transmitted a Capability Information field in which the Triggered Unscheduled PS subfield is equal to 1 â€” An RTS, DMG CTS-to-self, CF-End, Grant, BRP, SSW or SSW-Feedback frame. NOTEâ€”A DMG STA in doze state may need to perform beamforming to restore its links with other DMG STAs. The PCP shall indicate the correct power state in the Frame Control field of any frame it transmits to an associated STA that contains all or part of a BU. 11.2.7.3.3 PCP operation with a wakeup schedule A PCP in PPS mode (PPS PCP) may enter the doze state for one or more consecutive beacon intervals in order to minimize its energy consumption. Figure 11-10 illustrates a finite state machine that shows the state transition of the PCP power management mode. NOTEâ€”Figure 11-10 uses the following terminology: â€œAs per T1â€ means that the transitions are specified in Table 11-2, â€œAs per T2â€ means that the transitions are specified in Table 11-3. As per STA operation Scheduled and without a Active Scheduled Unscheduled DMG Wakeup Schedule Unscheduled PS wakeup mode PS mode PS mode element in DMG Beacon or mode schedule Announce frames As per WS element Unscheduled Awake BI Doze BI PS mode BI As per WS element As per ATIM frame usage for As per T1 power management of As per T2 nonâ€AP STAs Awake Doze power power Awake Doze Awake Doze state state power power power power state state state state As per T1 As per T2 As per ATIM frame usage for power management of nonâ€AP STAs Figure 11-10â€”State transition diagram of PCP power management mode 1637 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications To enter PPS mode, or to modify an established WS, the PCP announces a WS through a DMG Wakeup Schedule element (9.4.2.131) included in a DMG Beacon, Announce, or any Action frame. The PCP can assume that all associated STAs have received a WS and the Awake Window element that can optionally be transmitted with the WS at the earlier of the following events: â€” The PCP has transmitted the DMG Wakeup Schedule element in DMG Beacon or Announce frames for at least dot11MaxLostBeacons successive beacon intervals. â€” The PCP has confirmed that each associated STA has received the DMG Wakeup Schedule element by receiving an ACK or a response frame from each associated STA in response to a request frame that includes the DMG Wakeup Schedule element. The first PCP Awake BI of a sleep cycle in a WS starts at the instant specified by the value of the BI Start Time field of the announced DMG Wakeup Schedule element, and the number of successive PCP Awake BIs is specified by the Number of Awake BIs field of the DMG Wakeup Schedule element.Once in PPS mode, the PCP transitions between awake BI and doze BI according to the WS it has established. NOTEâ€”The PCP may need to behave as it is in active mode or in an awake BI to some associated STAs for a number of planned successive PCP doze BIs if it has not been able to confirm the reception of its WS by each associated STA, and it has not transmitted its WS through DMG Beacon or Announce frames over dot11MaxLostBeacons successive beacon intervals. In order to transition from PPS mode to active mode, the PCP stops including the DMG Wakeup Schedule element in DMG Beacon and Announce frames. A DMG STA that has received a PCP WS shall assume the PCP WS is in effect until it either receives a DMG Beacon or Announce frame that does not include a DMG Wakeup Schedule element or receives a different PCP WS. In a PCP doze BI, the PCP should schedule a BTI or ATI. If scheduling an ATI, the PCP should transmit an Announce frame during the ATI to associated STAs. NOTEâ€”The PCP provides the PBSS timing synchronization function (TSF). Transmitting frequent TSF information through DMG Beacon or Announce frames is important when there are non-PCP STAs in the PBSS that rely on TSF information to communicate directly with each other. The PCP may include in the Extended Schedule element the schedule for the beacon intervals during the PCP doze BIs. The PCP may schedule a SP or CBAP within a doze BI by setting the Allocation Start field of the new SP or CBAP in the Extended Schedule element to a value within a doze BI. If the Extended Schedule element is transmitted, the PCP shall transmit it at least dot11MaxLostBeacons times before the PPS PCP enters the doze state. The PCP shall check that the schedule of pseudo-static allocations transmitted in the last Extended Schedule element before the PCP entered PPS mode is valid during the PCP doze BIs. Thus, a STA participating in such a pseudo-static allocation assumes that the allocation is present during the following consecutive PCP doze BIs. The PCP may enter and remain in the doze state for any portion of an SP if it is not a source or a destination of the SP. The PCP shall remain in the awake state for any portion of a truncatable or extendable SP (9.4.2.132). The availability of the PCP during a CBAP in the awake BI shall be announced by setting the PCP Active subfield within the Allocation Control field to 1 for a CBAP allocation made through the Extended Schedule element. NOTEâ€”A PCP that indicates availability during a CBAP that includes an awake window can exchange ATIM frames with non-AP and non-PCP STAs during the awake window and possibly enter the doze state for the remainder of the CBAP outside the awake window (see 11.2.7.4). Figure 11-11 shows an example of the basic operation of a PCP in PPS mode when the PCP sleep interval equals one beacon interval (i.e., PCP sleeps every other beacon interval) and the PCP sleep interval starts 1638 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications right after the first beacon interval. In this example, the first beacon interval and the second beacon interval have the same schedule, but the third beacon interval and the fourth beacon interval have different schedules. The first beacon interval is the awake BI in which the PPS PCP is in the awake state to serve non- PCP STAs. In the first beacon interval, the PCP transmits the Extended Schedule element for the current beacon interval with the pseudo-static subfield set to 1 for all allocations within the Extended Schedule element to indicate that the schedule of the first beacon interval also applies to the second beacon interval. In addition, the PCP transmits the DMG Wakeup Schedule element with the information of the start time and the length of the PCP sleep interval, and the STA Availability element to indicate the availability of the PCP for the CBAP of the awake BI. Following the CBAP of the first beacon interval, the PCP enters the doze state and sleeps for more than one beacon interval. The PCP switches from the doze state to the awake state after sleeping through the remainder of the first beacon interval and through the entire second beacon interval, which is the start of the third beacon interval in Figure 11-11. Since in this example the schedule of the third beacon interval and the fourth beacon interval are different, the PCP transmits the Extended Schedule element containing the individual allocations for the third beacon interval and fourth beacon interval. The PCP enters the doze state after it completes all exchanges in the third beacon interval and wakes up at the start of the fifth beacon interval. Beacon or Announce Applied to both Beacon or Announce Applied to both beacon intervals beacon intervals Extended Schedule element Extended Schedule element DMG Wakeup Schedule element DMG Wakeup Schedule element STA Availability element STA Availability element SP CBAP SP CBAP SP CBAP SP CBAP PCP doze interval PCP doze interval Awake BI = 1 beacon interval Awake BI = 1 beacon interval PCP AWAKE PCP DOZE PCP AWAKE PCP DOZE Figure 11-11â€”Example operation of PPS mode 11.2.7.4 ATIM frame usage for power management of non-AP STAs An awake window is present within the first CBAP of a beacon interval that is scheduled through the Extended Schedule element and has the Source AID and Destination AID fields in that Extended Schedule element equal to the broadcast AID, or in a CBAP that is scheduled through the CBAP Only field in the DMG Parameters field (9.4.1.47) set to 1, for dot11MaxLostBeacons beacon intervals following the most recent transmission of the Awake Window element (9.4.2.137) by the AP or PCP with the Awake Window Duration field set to a nonzero value. NOTEâ€”Transmission rules during the awake window are the same as the transmission rules for the CBAP that the awake window belongs to. A non-AP and non-PCP STA delivers the Awake Window element to an AP or PCP as defined in 11.2.7.2.3. An AP or PCP delivers the Awake Window element to a non-AP and a non-PCP STA as defined 11.2.7.3. If present, the awake window starts from the beginning of a CBAP and has a duration that is defined by the value of the Awake Window Duration field in the Awake Window element or the CBAP duration, whichever is smaller. During the awake window, a STA shall transmit only ATIM frames. A DMG STA in PS mode shall be in the awake state during each awake window that lies within each awake BI for that STA. BUs that are to be transmitted to a STA that is in PS mode are first announced through ATIM frames during the awake window. A STA in PS mode that is awake during an awake window shall listen for these announcements to determine if it needs to change its power state. If during the awake window the STA does not receive or transmit an ATIM frame with BSSID equal to the BSSID of the BSS of the STA is a member, 1639 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications then it may enter the doze state at the end of the awake window. If a STA receives an ATIM frame during the awake window, it shall acknowledge the ATIM frame. Any two STAs that successfully complete an ATIM frame exchange with each other during the awake window become peer STAs. A STA that is in PS mode and following a wakeup schedule and has not performed unscheduled power save to enter doze state and receives an ATIM frame during the awake window shall be awake during allocations within the current beacon interval that have the Source AID equal to broadcast AID or have a Source AID that identifies a STA whose MAC address is equal to the TA field of the received ATIM frame, or during any DTI that is scheduled through the CBAP Only field in the DMG Parameters field (9.4.1.47) set to 1. If a STA transmits an ATIM frame during the awake window, it shall attempt to deliver its BUs during allocations within the current beacon interval that have a Destination AID equal to broadcast AID or have a Destination AID that identifies a STA whose MAC address is equal to the RA field of the transmitted ATIM frame, or during any DTI that is scheduled through the CBAP Only field in the DMG Parameters field (9.4.1.47) set to 1. A STA that receives or transmits an ATIM frame during the awake window may enter the doze state when it has successfully transmitted to and received from all corresponding peer STAs for this beacon interval a QoS Data frame with the EOSP subfield set to 1; otherwise it shall stay active until the end of the current beacon interval. ATIM frame transmissions and MSDU transmissions follow the rules defined in 11.2.8. NOTEâ€”A STA that has performed unscheduled power save to enter doze state and receives an ATIM frame during an awake window can use the unscheduled power save mechanism to leave doze state following the procedure in 11.2.7.2.2or 11.2.7.3.2. Figure 11-12 illustrates an example of a DMG STA response to an ATIM frame. For illustration purposes the 5 beacon intervals shown in the figure are numbered from 0 to 4. The PCP is following a wakeup schedule, with 1 awake BI out of every 4 beacon intervals. The non-PCP STA A is also following a wakeup schedule, with 1 awake BI out of every 2 beacon intervals. In addition, STA A performs unscheduled power save during BI 0, and also during BI 2 through BI 4. STA A is required to stay awake during the following CBAP after receiving an ATIM frame in BI 2. An ATIM frame received during BI 4 however serves as a traffic indication and PCP will transmit frames to STA A only after STA A has performed unscheduled power save to leave doze state. Wakeup Schedule: Number of Awake BIs = 1, Sleep Cycle = 4 PCP BI 0: Awake BI BI 1: Awake BI BI 2: Awake BI BI 3: Doze BI BI 4: Awake BI Following a wakeup Awake Awake Awake Awake BTI CBAP BTI CBAP BTI CBAP BTI CBAP window window window window schedule STA can skip PM=1 PM=0 PM=1 PM=0 ATIM ATIM ATIM ATIM Ack Ack Ack Ack Ack Ack Ack Ack transmitting ATIM to PCP if it receives the ATIM from PCP first STA in scheduled PS mode STA in scheduled and unscheduled PS mode STA in scheduled and unscheduled PS mode Non-PCP BI 0: Awake BI BI 1: Doze BI BI 2: Awake BI BI 3: Doze BI BI 4: Awake BI STA Following a Awake Awake Awake BTI CBAP BTI CBAP BTI CBAP wakeup window window window schedule and STA in unscheduled PS also Wakeup Schedule: Number of Awake BIs = 1, Sleep Cycle = 2 mode can be in doze state performing despite receiving an ATIM unscheduled frame from PCP power save Awake Doze Awake Doze Awake Doze Awake Doze Awake Figure 11-12â€”Example of ATIM frame response behavior in PS mode The ATIM frame transmission result and EOSP notification result between a MAC address pair can be used for other MAC pairs that are members of the same MMSL cluster. 1640 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.2.8 ATIM frame and frame transmission in IBSS, DMG infrastructure BSS, and PBSS If power management is in use within an IBSS, a STA shall buffer individually addressed BUs for STAs that are known to be in PS mode. The following rules describe operation of the ATIM frame and frame transmission to STAs in PS mode in an IBSS, DMG infrastructure BSS and PBSS: a) Following the reception or transmission of the Beacon frame in a non-DMG IBSS, during the ATIM window, the STA shall queue for transmission an individually addressed ATIM frame to each STA for which it has one or more buffered individually addressed BUs and for which an ATIM frame is not already queued. Following the BTI or ATI in a DMG BSS, during the Awake Window, the STA shall queue for transmission an individually addressed ATIM frame to each STA for which it has one or more buffered individually addressed BUs and for which an ATIM frame is not already queued. If the STA has one or more buffered group addressed MSDUs (excluding those with a service class of StrictlyOrdered) or has one or more buffered group addressed MMPDUs, it shall queue for transmission an appropriately addressed group addressed ATIM frame if such an ATIM frame is not already queued. b) In a non-DMG IBSS, a STA shall use the backoff procedure defined in 10.3.4.3 for transmission of the first ATIM frame following the Beacon frame. In a DMG BSS, a STA shall use the backoff procedure defined in 10.3.4.3 for transmission of the first ATIM frame following the BTI or ATI. All remaining ATIM frames shall be transmitted using the DCF (for non-QoS STAs) or the EDCAF (for QoS STAs). c) ATIM frames shall be transmitted only during the ATIM window/Awake Window. d) A non-DMG STA shall transmit no frame types other than RTS, CTS, Ack, Beacon, ATIM and (QoS) Null frames during the ATIM window. e) Individually addressed ATIM frames shall be acknowledged. If no acknowledgment is received, the ATIM frame shall be retransmitted using either the DCF (for non-QoS STAs) or the EDCAF (for QoS STAs). Group addressed ATIM frames shall not be acknowledged. f) If a STA is unable to transmit an ATIM frame during the ATIM window/Awake Window, for example due to contention with other STAs, the STA should retain the buffered BUs and either discard the ATIM frame or attempt to transmit the ATIM frame during the next ATIM window/ Awake Window. g) Immediately following the ATIM window/Awake Window, a STA shall begin transmission of any buffered group addressed frames for which an ATIM frame was previously transmitted. Following the transmission of any group addressed frames, any BUs addressed to STAs for which an acknowledgment for a previously transmitted ATIM frame was received shall be transmitted. A STA shall use the backoff procedure defined in 10.3.4.3 for transmission of the first frame following the ATIM window/Awake Window. All remaining frames shall be transmitted using either the DCF (for non-QoS STAs) or the EDCAF (for QoS STAs). h) If a buffered BU is transmitted using fragmentation and if the BU has been partially transmitted when the next Beacon frame is sent in a non-DMG IBSS or when the next beacon interval begins in a DMG BSS, the STA shall retain the buffered BU and announce the remaining fragments by transmitting an ATIM frame during the next ATIM window/Awake Window. i) If a STA is unable to transmit a buffered BU during the beacon interval in which it was announced, for example due to contention with other STAs, the STA shall retain the buffered BU and announce the BU again by transmitting an ATIM frame during the next ATIM window/Awake Window. j) Following the transmission of all buffered BUs, a STA may transmit BUs without announcement to STAs that are known to be in the awake state for the current beacon interval. k) A STA may discard BUs buffered for later transmission to power-saving STAs if the STA determines that the BU has been buffered for an excessive amount of time or if other conditions internal to the STA implementation make it desirable to discard buffered BUs (e.g., buffer 1641 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications starvation). A BU should not be discarded that has been buffered for less than dot11BeaconPeriod. The algorithm to manage this buffering is beyond the scope of this standard. l) In order to indicate its intent to change power management modes, a STA shall transmit individually addressed or group addressed (QoS) Null frames within the ATIM window. The STA shall not transition into or out of PS mode unless it has received acknowledgments from all recipients to which individually addressed (QoS) Null frames have been transmitted or after it has transmitted a sufficient number of group addressed (QoS) Null frames. NOTEâ€”The choice between individually addressed and group addressed transmissions, the peer STAs addressed for individually addressed transmissions, and the number of transmissions for group addressed transmissions are implementation choices outside the scope of the standard. A STA might base its choices on factors such as the number of peer STAs it is aware of in the IBSS, the expected traffic from each of these peer STAs, and the reliability of frame exchanges with these peer STAs. 11.3 STA authentication and association 11.3.1 State variables A STA (local) for which dot11OCBActivated is false keeps an enumerated state variable for each STA (remote) with which direct communication via the WM is needed. In this context, direct communication refers to the transmission of any Class 2 or Class 3 frame with an Address 1 field that matches the MAC address of the remote STA. A STA for which dot11MeshActivated is true (i.e., a mesh STA) does not use procedures described in 11.3.5. Instead, a mesh STA uses a mesh peering management protocol (MPM) or a authenticated mesh peering exchange (AMPE) to manage states and state variables for each peer STA. See 14.3 and 14.5 for details. A STA for which dot11OCBActivated is true does not use MAC sublayer authentication or association and does not keep this state variable. For nonmesh STAs, this state variable expresses the relationship between the local STA and the remote STA. It takes on the following values: â€” State 1: Initial start state for non-DMG STAs and for DMG STAs that perform IEEE 802.11 authentication. Unauthenticated and unassociated. â€” State 2: Initial start state for DMG STAs that do not perform IEEE 802.11 authentication. Authenticated (except DMG STAs that do not perform IEEE 802.11 authentication, which are unauthenticated) but unassociated. â€” State 3: Authenticated (except DMG STAs that did not perform IEEE 802.11 authentication, which are unauthenticated) and associated (Pending RSNA Authentication). The IEEE 802.1X Controlled Port is blocked. â€” State 4: Authenticated (except DMG STAs that did not perform IEEE 802.11 authentication, which are unauthenticated) and associated (RSNA Established or Not Required). The IEEE 802.1X Controlled Port is unblocked, or not present. The state variable is kept within the MLME (i.e., is written and read by the MLME). The SME may also read this variable using the MLME-GETAUTHASSOCIATE.request primitive. Mesh STAs manage the state variable as described in 14.3.2. 1642 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.3.2 State transition diagram for nonmesh STAs Figure 11-13 shows the state transition diagram for nonmesh STA states. Note that only events causing state changes are shown. The state of the sending STA given by Figure 11-13 is with respect to the intended receiving STA. NOTEâ€”A transition to State 1 might occur for other reasons such as no frames having been received from a STA for a period of time. State 1 Unauthenticated, Unassociated Class 1 Frames Successful IEEE Std 802.11 authentication 1. Successful (Re)Association â€“ No RSNA Required Deauthentication (except DMG STAs that 2. Fast BSS Transition State 2 did not perform IEEE Std 802.11 authentication) Authenticated (except DMG STAs that do 3. PBSS 4-way handshake not perform IEEE Std 802.11 authentication, Successful which are unauthenticated), Unassociated Class 1 & 2 Frames Successful (Re)Association â€“ RSNA Required 1. Unsuccessful (Re)Association (Non-AP and non-PCP STA) State 3 2. Disassociation Authenticated (except DMG STAs that did not perform IEEE Std 802.11 authentication, Deauthentication which are unauthenticated), Associated (except DMG STAs that (Pending RSNA Authentication) did not perform IEEE Std 802.11 Class 1, 2 & 3 Frames authentication) IEEE 802.1X Controlled Port Blocked 4-way handshake Successful 1. Unsuccessful (Re)Association (Non-AP and non-PCP STA) State 4 2. Disassociation Authenticated (except DMG STAs that did not perform IEEE Std 802.11 authentication, which are unauthenticated), Associated (RSNA Established or Not Required) Deauthentication (except DMG STAs that did not Class 1, 2, & 3 Frames perform IEEE Std 802.11 IEEE 802.1X Controlled Port Unblocked authentication) Figure 11-13â€”Relationship between state and services between a given pair of nonmesh STAs 11.3.3 Frame filtering based on STA state The current state existing between the transmitter and receiver STAs determines the IEEE 802.11 frame types that may be exchanged between that pair of STAs (see Clause 9). A unique state exists for each pair of transmitter and receiver STAs. The allowed frame types are grouped into classes and the classes correspond to the STA state. In State 1, only Class 1 frames are allowed. In State 2, either Class 1 or Class 2 frames are 1643 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications allowed. In State 3 and State 4, all frames are allowed (Classes 1, 2, and 3). In the definition of frame classes, the following terms are used: â€” Within an infrastructure BSS: both the transmitting STA and the recipient STA participate in the same infrastructure BSS â€” Within a PBSS: both the transmitting STA and the recipient STA participate in the same PBSS â€” Within an IBSS: both the transmitting STA and the recipient STA participate in the same IBSS â€” dot11RSNAActivated: reference to the setting of dot11RSNAActivated at the STA that needs to determine whether a transmission or reception is permitted. NOTEâ€”The phrase â€œwithin a BSSâ€ comprises â€œwithin a PBSS,â€ â€œwithin an IBSS,â€ â€œwithin a MBSS,â€ or â€œwithin an infrastructure BSS.â€ STA A participates in the same infrastructure BSS as STA B if at least one of the following conditions is met: â€” STA A is associated with STA B, and either STA A or STA B is an AP. â€” STA A receives a frame with the value of its TA field equal to the MAC address of STA B and with the value of its BSSID field equal to the BSSID of the BSS with which STA A is associated. â€” STA A receives an Information Response frame from the AP with which it is associated containing an explicit indication that STA B is a member of the BSS with which STA A is associated. STA A participates in the same PBSS as STA B if at least one of the following conditions is met: â€” STA A is associated with STA B, and either STA A or STA B is a PCP. â€” STA A receives a frame with the value of its TA field equal to the MAC address of STA B and with the value of its BSSID field equal to the BSSID of the PBSS that STA A has joined or started. â€” STA A receives a frame, i.e., an Information Response frame, from its PCP containing an explicit indication that STA B is a member of the PBSS that STA A has joined. STA A participates in the same IBSS as STA B if STA A receives a frame with the value of its TA field equal to the MAC address of STA B and with the value of its BSSID field equal to the BSSID of the IBSS that STA A has joined or started. The frame classes are defined as follows: a) Class 1 frames 1) Control frames i) RTS ii) CTS iii) DMG Clear to send (DMG CTS) iv) Ack v) Grant vi) SSW vii) SSW-Feedback viii) SSW-Ack ix) Grant Ack x) CF-End +CF-Ack xi) CF-End xii) In an IBSS and in a PBSS when dot11RSNAActivated is false, Block Ack (BlockAck) xiii) In an IBSS and in a PBSS when dot11RSNAActivated is false, Block Ack Request (BlockAckReq) 1644 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 2) Management frames i) Probe Request/Response ii) Beacon iii) Authentication iv) Deauthentication v) ATIM vi) Public Action vii) Self-protected Action viii) In an IBSS, all Action frames and all Action No Ack frames vi) Unprotected DMG Action frames vii) In a DMG BSS, Link Measurement Request and Link Measurement Report frames viii) In a PBSS when dot11RSNAActivated is false, all Action and Action No Ack frames except the following frames: 1) ADDTS Request 2) ADDTS Response 3) DELTS 3) Data frames i) Data frames between IBSS STAs ii) Data frames between peers using DLS iii) Data frames within a PBSS 4) Extension frames i) DMG Beacon b) Class 2 frames 1) Management frames i) Association Request/Response ii) Reassociation Request/Response iii) Disassociation c) Class 3 frames 1) Data frames i) Data frames between STAs in an infrastructure BSS or in an MBSS 2) Management frames i) In an infrastructure BSS, an MBSS, or a PBSS, all Action and Action No Ack frames except those that are declared to be Class 1 or Class 2 frames 3) Control frames i) PS-Poll ii) Poll iii) SPR iv) DMG DTS v) Block Ack (BlockAck), except those that are declared to be Class 1 vi) Block Ack Request (BlockAckReq), except those that are declared to be Class 1 (above) Class 2 and Class 3 frames are not allowed in an IBSS. If an IBSS STA receives a Class 2 or Class 3 frame, it shall ignore the frame. 1645 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A STA shall not transmit Class 2 frames unless in State 2 or State 3 or State 4. A STA shall not transmit Class 3 frames unless in State 3 or State 4. A multi-band capable device that uses OCT to move from State 2 to either State 3 or State 4 shall not transmit frames before the transmitting STA becomes over-the-WM enabled (see 11.33.4). The use of the word â€œreceiveâ€ in 11.3 refers to a frame that meets all of the filtering criteria specified in Clause 12 and Clause 10. 11.3.4 Authentication and deauthentication 11.3.4.1 General This subclause describes the procedures used for IEEE 802.11 authentication and deauthentication. The states used in this description are defined in 11.3.1. Successful authentication sets the STAâ€™s state to State 2, if it was in State 1. Unsuccessful authentication leaves the STAâ€™s state unchanged. Deauthentication notification sets the STAâ€™s state to State 1. Deauthentication notification when in State 3 or 4 implies disassociation as well. A STA may deauthenticate a peer STA at any time, for any reason. If STA A in an infrastructure BSS receives a Class 2 or Class 3 frame from STA B that is not authenticated with STA A (i.e., the state for STA B is State 1), STA A shall discard the frame. If the frame has an individual address in the Address 1 field, the MLME of STA A shall send a Deauthentication frame to STA B. Authentication is optional in an IBSS. In a non-DMG infrastructure BSS, authentication is required. In a DMG infrastructure BSS and PBSS, the Open System authentication algorithm is not used (see 12.3.3.1). APs do not initiate authentication. 11.3.4.2 Authenticationâ€”originating STA Upon receipt of an MLME-AUTHENTICATE.request primitive that is part of an on-channel tunneling (see 11.33.4), the originating STA shall follow the rules in 11.33.4 in addition to the authentication procedure described below. Upon receipt of an MLME-AUTHENTICATE.request primitive, the originating STA shall authenticate with the indicated STA using the following procedure: a) If the STA is in an IBSS, the SME shall delete any PTKSA, GTKSA, IGTKSA and temporal keys held for communication with the indicated STA by using the MLME-DELETEKEYS.request primitive (see 12.6.18). b) The STA shall execute one of the following: 1) For the Open System or Shared Key authentication algorithm, the authentication mechanism described in 12.3.3.2 or 12.3.3.3, respectively. 2) For the fast BSS transition (FT) authentication algorithm in an ESS, the authentication mechanism described in 13.5, or, if resource requests are included, 13.6. 3) For SAE authentication in an infrastructure BSS, IBSS, or MBSS, the authentication mechanism described in 12.4. 1646 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications c) If the authentication was successful within the AuthenticateFailureTimeout, the state for the indicated STA shall be set to State 2 if it was State 1; the state shall remain unchanged if it was other than State 1. d) The MLME shall issue an MLME-AUTHENTICATE.confirm primitive to inform the SME of the result of the authentication. 11.3.4.3 Authenticationâ€”destination STA Upon receipt of an Authentication frame with authentication transaction sequence number equal to 1, the destination STA shall authenticate with the originating STA using the following procedure: a) If Open System or Shared Key authentication algorithm is being used, the STA shall execute the procedure described in 12.3.3.2 or 12.3.3.3, respectively. These result in the generation of an MLME-AUTHENTICATE.indication primitive to inform the SME of the authentication request. b) If FT authentication is being used, the MLME shall issue an MLME-AUTHENTICATE.indication primitive to inform the SME of the authentication request, including the FT Authentication Elements, and the SME shall execute the procedure as described in 13.5 or 13.6. c) If SAE authentication is being used in an infrastructure BSS, IBSS, or MBSS, the MLME shall issue an MLME-AUTHENTICATE.indication primitive to inform the SME of the authentication request, including the SAE authentication elements, and the SME shall execute the procedure as described in 12.4 d) If the STA is in an IBSS and management frame protection was not negotiated when the PTKSA(s) were created, the SME shall delete any PTKSA, GTKSA, IGTKSA and temporal keys held for communication with the originating STA by using the MLME-DELETEKEYS.request primitive (see 12.6.18). e) Upon receipt of an MLME-AUTHENTICATE.response primitive, if the ResultCode is not SUCCESS, the MLME shall transmit an Authentication frame with the corresponding status code, as defined in 9.4.1.9, and the state for the originating STA shall be left unchanged. The Authentication frame is constructed using the appropriate procedure in 12.3.3.2, 12.3.3.3, 13.5 or 13.6. f) Upon receipt of an MLME-AUTHENTICATE.response primitive, if the ResultCode is SUCCESS, the MLME shall transmit an Authentication frame that is constructed using the appropriate procedure in 12.3.3.2, 12.3.3.3, 13.5 or 13.6, with a status code of SUCCESS, and the state for the originating STA shall be set to State 2 if it was in State 1. If the STA is in an IBSS, if the SME decides to initiate an RSNA, and if the SME does not know the security policy of the peer, it may issue an individually addressed Probe Request frame to the peer by invoking an MLME-SCAN.request primitive to discover the peerâ€™s security policy. 11.3.4.4 Deauthenticationâ€”originating STA The originating STA shall deauthenticate with the indicated STA using the following procedure: a) The SME shall generate an MLME-DEAUTHENTICATE.request primitive containing the appropriate reason code for the STA deauthentication, as defined in Table 9-45 of 9.4.1.7. b) On receipt of the MLME-DEAUTHENTICATE.request primitive, if the state for the indicated STA is State 2, State 3, or State 4, the MLME shall generate a Deauthentication frame to be transmitted to the indicated STA. NOTEâ€”As the Deauthentication frame is a bufferable MMPDU, the transmission of this frame might be delayed by the operation of a power-saving protocol. The AID and the PTKSA are maintained (when applicable) until the frame is acknowledged or attempts to transmit the frame are abandoned. c) The state for the indicated STA shall be set to State 1. 1647 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications d) Once the Deauthentication frame is acknowledged or attempts to transmit the frame are abandoned, the MLME shall issue an MLME-DEAUTHENTICATE.confirm primitive to inform the SME of the deauthentication. e) The SME, upon receipt of an MLME-DEAUTHENTICATE.confirm primitive, shall delete any PTKSA, GTKSA, IGTKSA and temporal keys held for communication with the indicated STA by using the MLME-DELETEKEYS.request primitive (see 12.6.18) and by generating an MLME- SETPROTECTION.request(None) primitive. f) If the STA is contained within an AP, its SME, upon receipt of an MLME- DEAUTHENTICATE.confirm primitive, shall release the AID assigned for the indicated STA, if the state for the indicated STA was State 3 or State 4. g) If the STA is contained within an AP, its SME shall inform the DS of the disassociation, if the state for the indicated STA was State 3 or State 4. h) If the STA is a mesh STA, its SME shall inform the mesh peering instance controller (see 14.3.4) of the deauthentication. 11.3.4.5 Deauthenticationâ€”destination STA A DMG STA in State 2, State 3 or State 4 that receives a Deauthentication frame shall remain in the same state if it did not perform an IEEE 802.11 authentication exchange. Otherwise, upon receipt of a Deauthentication frame from a STA for which the state is State 2, State 3, or State 4, the destination STA shall deauthenticate with the originating STA using the following procedure: a) If management frame protection was not negotiated when the PTKSA(s) were created, or if management frame protection is in use and the frame is not discarded per management frame protection processing, the MLME shall issue an MLME-DEAUTHENTICATE.indication primitive to inform the SME of the deauthentication, and set the state for the originating STA to State 1. b) Upon receiving an MLME-DEAUTHENTICATE.indication primitive, the SME shall 1) Delete any PTKSA, GTKSA, IGTKSA and temporal keys held for communication with the originating STA by using the MLME-DELETEKEYS.request primitive (see 12.6.18) and by generating an MLME-SETPROTECTION.request(None) primitive. 2) If the STA is contained within an AP, release the AID assigned for the indicated STA and shall inform the DS of the disassociation, if the state for the originating STA was State 3 or State 4. 3) If the STA is a mesh STA, inform the mesh peering instance controller (see 14.3.4) of the deauthentication. 11.3.5 Association, reassociation, and disassociation 11.3.5.1 General Subclause 11.3.5 describes the procedures used for IEEE 802.11 association, reassociation and disassociation. The states used in this description are defined in 11.3.1. Successful association enables a STA to exchange Class 3 frames. Successful association sets the STAâ€™s state to State 3 or State 4. Successful reassociation enables a STA to exchange Class 3 frames. Unsuccessful reassociation when not in State 1 leaves the STAâ€™s state unchanged (with respect to the AP or PCP that was sent the Reassociation Request (which may be the current STA)). Successful reassociation sets the STAâ€™s state to State 3 or State 4 (with respect to the AP or PCP that was sent the Reassociation Request). Successful reassociation when not 1648 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications in State 1 sets the STAâ€™s state to State 2 (with respect to the current AP or PCP, if this is not the AP or PCP that was sent the Reassociation Request). Reassociation shall be performed only if the originating STA is already associated in the same ESS. Disassociation notification when not in State 1 sets the STAâ€™s state to State 2. The STA shall become associated again prior to sending Class 3 frames. A STA may disassociate a peer STA at any time, for any reason. If non-DMG STA A in an infrastructure BSS receives a Class 3 frame from STA B that is authenticated but not associated with STA A (i.e., the state for STA B is State 2), STA A shall discard the frame. If the frame has an individual address in the Address 1 field, the MLME of STA A shall send a Disassociation frame to STA B. If DMG STA A in an infrastructure BSS receives a Class 3 frame from STA B that is not associated with STA A (i.e., the state for STA B is State 2), STA A shall discard the frame. If the frame has an individual address in the Address 1 field, the MLME of STA A shall send a Disassociation frame to STA B. If an MM-SME coordinated STA receives an Association Response frame with a result code equal to SUCCESS and with the value of the Single AID field within MMS element equal to 1, then â€” For each of its MAC entities advertised within the MMS element and for which dot11RSNAActivated is true, the state is set to State 3. Progress from State 3 to State 4 occurs independently in each such MAC entity. â€” For each of its MAC entities advertised within the MMS element and for which dot11RSNAActivated is false, the state is set to State 4. If the MM-SME coordinated STA in State 3 is assigned an AID for only the MAC entity identified by the RA field of the Association Response with result code equal to SUCCESS, the MM-SME may repeat the association procedure for any other MAC entity coordinated by the MM-SME. Association is not applicable in an IBSS. In an infrastructure BSS, association is required. In a PBSS, association is optional. APs do not initiate association. 11.3.5.2 Non-AP and non-PCP STA association initiation procedures The SME shall delete any PTKSA, GTKSA, IGTKSA and temporal keys held for communication with the AP or PCP by using MLME-DELETEKEYS.request primitive (see 12.6.18) before invoking MLME- ASSOCIATE.request primitive. If dot11InterworkingServiceActivated is true, the STA does not have credentials for the AP, and the STA is initiating an emergency services association procedure, the SME shall submit the MLME- ASSOCIATE.request primitive with EmergencyServices parameter set to true. The MM-SME of a non-AP and non-PCP STA may include an MMS element in an MLME- ASSOCIATE.request primitive. The MM-SME shall include in the MMS element the MAC address associated with the MLME SAP instance to which the primitive is submitted. Upon receipt of an MLME-ASSOCIATE.request primitive that is part of an on-channel tunneling (see 11.33.4), a non-AP and non-PCP STA shall follow the rules in 11.33.4 in addition to the association procedures described below. Upon receipt of an MLME-ASSOCIATE.request primitive, a non-AP and non-PCP STA shall associate with an AP or PCP using the following procedure: 1649 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications a) If the state for the AP is State 1, the MLME shall inform the SME of the failure of the association by issuing an MLME-ASSOCIATE.confirm primitive, and this procedure ends. b) The MLME shall transmit an Association Request frame to the AP or PCP. If the MLME- ASSOCIATE.request primitive contained an RSNE with only one pairwise cipher suite and only one authenticated key suite, this RSNE shall be included in the Association Request frame. If the MLME-ASSOCIATE.request primitive contained the EmergencyServices parameter equal to true, an Interworking element with the UESA field set to 1 shall be included in the Association Request frame. c) If an Association Response frame is received with a status code of SUCCESS, a DMG STA shall write to each of the following MIB attributes the value of the corresponding subfield of the DMG BSS Parameter Configuration field of the DMG Operation element received from the AP or PCP to which it requested association: 1) dot11PSRequestSuspensionInterval from the PSRequestSuspensionInterval subfield 2) dot11MinBHIDuration from the MinBHIDuration subfield 3) dot11BroadcastSTAInfoDuration from the BroadcastSTAInfoDuration subfield 4) dot11AssocRespConfirmTime from the AssocRespConfirmTime subfield 5) dot11MinPPDuration from the MinPPDuration subfield 6) dot11SPIdleTimeout from the SPIdleTimeout subfield 7) dot11MaxLostBeacons from the MaxLostBeacons subfield d) If an Association Response frame is received with a status code of SUCCESS, the state for the AP or PCP shall be set to State 4 or, if dot11RSNAActivated is true, State 3. The state for any other AP or PCP which is State 3 or State 4 prior to the association request shall be set to State 2, and the MLME shall issue an MLME-ASSOCIATE.confirm primitive to inform the SME of the successful completion of the association. e) An MM-SME coordinated STA that receives an Association Response frame with a status code of SUCCESS containing an MLME element with the Single AID field equal to 1, all of the STAs coordinated by the MM-SME are associated with the AP or PCP (i.e., shall be set to State 4 or, if dot11RSNAActivated is true, State 3). f) If an Association Response frame is received with a status code other than SUCCESS or the association fails to complete within dot11AssociationResponseTimeout the state for the AP or PCP shall be set to State 2, and the MLME shall issue an MLME-ASSOCIATE.confirm primitive to inform the SME of the failure of the association. The status code returned in the Association Response frame indicates the cause of the failed association attempt. Any misconfiguration or parameter mismatch, e.g., data rates required as basic rates that the STA did not indicate as supported in the STAâ€™s Supported Rates and BSS Membership Selectors element, shall be corrected before the SME issues an MLME-ASSOCIATE.request primitive for the same AP or PCP. If the status code indicates the association failed because of a reason that is not related to configuration (e.g., the AP or PCP is unable to support additional associations) and the Association Response frame does not include a Timeout Interval element with Timeout Interval Type equal to 3 the SME shall not issue an MLME-ASSOCIATE.request primitive for the same AP or PCP until a period of at least 2 s has elapsed. If the status code indicates the association failed and the Association Response frame contains a Timeout Interval element with Timeout Interval Type equal to 3, the SME shall not issue an MLME-ASSOCIATE.request primitive for the same AP or PCP until the period specified in the Timeout Interval element has elapsed. g) If an MLME-ASSOCIATE.confirm primitive is received with a ResultCode of SUCCESS, and RSNA is required, then the SME shall perform a 4-way handshake to establish an RSNA. As a part of a successful 4-way handshake, the SME enables protection by generating an MLME- SETPROTECTION.request(Rx_Tx) primitive. h) Upon receipt of the MLME-SETPROTECTION.request(Rx_Tx) primitive, the MLME shall set the state of the STA to State 4. 1650 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.3.5.3 AP or PCP association receipt procedures Upon receipt of an Association Request frame from a STA the AP or PCP shall use the following procedure: a) The MLME shall issue an MLME-ASSOCIATE.indication primitive to inform the SME of the association request. The SME shall issue an MLME-ASSOCIATE.response primitive addressed to the STA identified by the PeerSTAAddress parameter of the MLME-ASSOCIATE.indication primitive. If the association is not successful, the SME shall indicate a specific reason for the failure to associate in the ResultCode parameter. Upon receipt of the MLME-ASSOCIATE.response primitive, the MLME shall transmit an Association Response frame. b) If the state for the STA is 1 and the STA is a non-DMG STA, the SME shall refuse the association request by issuing an MLME-ASSOCIATE.response primitive with ResultCode NOT_AUTHENTICATED. c) AP with dot11InterworkingServiceActivated true only: If the MLME-ASSOCIATE.indication primitive has the EmergencyServices parameter set to true and the RSN parameter does not include an RSNE, the SME shall not reject the association request on the basis that dot11RSNAActivated is true, thereby granting access, using unprotected frames (see 9.2.4.1.9), to the network for emergency services purposes. d) Otherwise, in an RSNA the SME shall check the values received in the RSN parameter to see whether the values received match the security policy. If they do not, the SME shall refuse the association by issuing an MLME-ASSOCIATE.response primitive with a ResultCode indicating the security policy mismatch. e) Otherwise, if the state for the STA is 4, the STA has a valid security association, the STA has negotiated management frame protection, and there has been no earlier, timed out SA Query procedure with the STA (which would have allowed a new association process to be started, without an additional SA Query procedure): 1) The SME shall refuse the association request by issuing an MLME-ASSOCIATE.response primitive with ResultCode REFUSED_TEMPORARILY and TimeoutInterval containing a Timeout Interval element with the Timeout Interval Type field set to 3 (Association Comeback time). If the SME is in an ongoing SA Query with the STA, the Timeout Interval Value field shall be set to the remaining SA Query period, otherwise it shall be set to dot11AssociationSAQueryMaximumTimeout. 2) The state for the STA shall be left unchanged. 3) Following this, if the SME is not in an ongoing SA Query with the STA, the SME shall issue one MLME-SA-QUERY.request primitive addressed to the STA every dot11AssociationSAQueryRetryTimeout TUs until an MLME-SA-QUERY.confirm primitive for the STA is received or dot11AssociationSAQueryMaximumTimeout TUs from the beginning of the SA Query procedure have passed. The SME shall increment the TransactionIdentifier by 1 for each MLME-SA-QUERY.request primitive, rolling it over the value to 0 after the maximum allowed value is reached. 4) If no MLME-SA-QUERY.confirm primitive for the STA is received within the dot11AssociationSAQueryMaximumTimeout period, the SME shall allow a subsequent association process with the STA to be started without starting an additional SA Query procedure, except that the SME may deny a subsequent association process with the STA if an MSDU was received from the STA within this period. NOTEâ€”Reception of an MSDU implies reception of a valid protected frame, which obviates the need for the SA Query procedure. f) The SME shall refuse an association request from a STA that does not support all of the rates in the BSSBasicRateSet parameter in the MLME-START.request primitive. 1651 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications g) The SME shall refuse an association request from an HT STA that does not support all of the MCSs in the Basic HT-MCS Set field of the HT Operation parameter in the MLME-START.request primitive. h) The SME shall refuse an association request from a VHT STA that does not support all of the tuples indicated by the Basic VHT-MCS And NSS Set field of the VHT Operation parameter in the MLME-START.request primitive. i) The SME shall generate an MLME-ASSOCIATE.response primitive with the PeerSTAAddress parameter set to the MAC address of the STA identified by the PeerSTAAddress parameter of the MLME-ASSOCIATE.indication primitive. If the ResultCode in the MLME-ASSOCIATE.response primitive is SUCCESS, the SME has an existing SA with the STA, and an SA Query procedure with that STA has failed to receive a valid response (i.e., has not received an MLME-SA- QUERY.confirm primitive within the dot11AssociationSAQueryMaximumTimeout period), the SME shall issue an MLME-DISASSOCIATE.request primitive addressed to the STA with ReasonCode INVALID_AUTHENTICATION. NOTEâ€”This MLME-DISASSOCIATE.request primitive generates a protected Disassociation frame. If the association request was genuine, the STA has deleted the PTKSA by this point and so the protected Disassociation frame is ignored. The purpose is to inform a STA which has for some reason failed to respond to an SA Query procedure triggered by a forged association request. j) If the ResultCode in the MLME-ASSOCIATE.response primitive is SUCCESS, the SME shall delete any PTKSA, GTKSA, IGTKSA and temporal keys held for communication with the STA by using the MLME-DELETEKEYS.request primitive (see 11.5.18 (RSNA security association termination)). k) If the MLME-ASSOCIATE.indication primitive includes an MMS parameter, the AP or PCP shall generate the MLME-ASSOCIATE.response primitive directed to the MLME of the STA identified by the PeerSTAAddress parameter of the MLME-ASSOCIATE.request primitive and take the following additional action, as appropriate: 1) If the Single AID field in the MMS parameter of the MLME-ASSOCIATE.indication primitive is equal to 1, the AP or PCP may allocate a single AID for all of the STAs included in the MMS element. If the AP or PCP allocates the same AID to each STA whose MAC address was included in the MMS element, it shall include the MMS element received from the MM-SME coordinated STA in the MLME-ASSOCIATION.response primitive. 2) If the Single AID field is 0, the AP or PCP shall allocate a distinct AID for each STA specified in the MMS element. l) If an Association Response frame with a status code of SUCCESS is acknowledged by the STA, the state for the STA shall be set to State 4 or, if dot11RSNAActivated is true, State 3. m) If the ResultCode in the MLME-ASSOCIATE.response primitive is not SUCCESS and management frame protection is in use the state for the STA shall be left unchanged. If the ResultCode is not SUCCESS and management frame protection is not in use the state for the STA shall be set to State 3 if it was State 4. n) If the ResultCode in the MLME-ASSOCIATE.response primitive is SUCCESS and RSNA establishment is required, the SME shall attempt a 4-way handshake. Upon a successful completion of a 4-way handshake, the SME shall enable protection by issuing an MLME- SETPROTECTION.request(Rx_Tx) primitive and the state for the STA shall be set to State 4. o) AP only: The SME shall inform the DS of any changes in the state of the STA. 11.3.5.4 Non-AP and non-PCP STA reassociation initiation procedures Except when the association is part of a fast BSS transition, the SME shall delete any PTKSA, GTKSA, IGTKSA and temporal keys held for communication with the AP or PCP by using the MLME- DELETEKEYS.request primitive (see 12.6.18) before invoking an MLME-REASSOCIATE.request primitive. 1652 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If dot11InterworkingServiceActivated is true and the STA was associated to the ESS for unsecured access to emergency services, the SME shall submit the MLME-REASSOCIATE.request primitive with EmergencyServices parameter set to true. The MM-SME of a non-AP and non-PCP STA may include an MMS element in an MLME- REASSOCIATE.request primitive. The MM-SME shall include in the MMS element the MAC address associated with the MLME SAP instance to which the primitive is submitted. Upon receipt of an MLME-REASSOCIATE.request primitive that is part of an on-channel tunneling (see 11.33.4), a non-AP and non-PCP STA shall follow the rules in 11.33.4 in addition to the reassociation procedures described below. Upon receipt of an MLME-REASSOCIATE.request primitive, a non-AP and non-PCP STA shall reassociate with an AP or PCP using the following procedure: a) If the STA is not associated in the same ESS or the state for the new AP is State 1, the MLME shall inform the SME of the failure of the reassociation by issuing an MLME-REASSOCIATE.confirm primitive, and this procedure ends. b) The MLME shall transmit a Reassociation Request frame to the new AP or PCP. If the MLME- REASSOCIATE.request primitive contained an RSNE with only one pairwise cipher suite and only one authenticated key suite, this RSNE shall be included in the Reassociation Request frame. If the MLME-REASSOCIATE.request primitive contained the EmergencyServices parameter equal to true, an Interworking element with the UESA field set to 1 shall be included in the Reassociation Request frame. c) If a Reassociation Response frame is received with a status code of SUCCESS, the state variable for the new AP or PCP shall be set to State 4 or to State 3 if dot11RSNAActivated is true and the FT protocol is not used with respect to the new AP or PCP and, unless the old AP or PCP and new AP or PCP are the same, to State 2 with respect to the old AP or PCP, and the MLME shall issue an MLME-REASSOCIATE.confirm primitive to inform the SME of the successful completion of the reassociation. If the MLME-REASSOCIATION.request primitive has the new APâ€™s MAC address in the CurrentAPAddress parameter (reassociation to the same AP), the following states, agreements and allocations shall be deleted or reset to initial values: 1) All EDCAF state 2) Any block ack agreements 3) Sequence number 4) Packet number 5) Duplicate detection caches 6) Anything queued for transmission 7) Fragmentation and reassembly buffers 8) Power management mode 9) WNM sleep mode 10) SMKSAs, STKSAs and TPKSAs established with any peers. The following states, agreements and allocations are not affected by the reassociation procedure: 1) PSMP sessions 2) Enablement/Deenablement 3) GDD enablement 4) STSL, DLS and TDLS agreements 5) MMSLs 1653 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 6) GCR agreements 7) DMS agreements 8) TFS agreements 9) FMS agreements 10) Triggered autonomous reporting agreements 11) FTM sessions 12) DMG SP and CBAP allocations. d) If a Reassociation Response frame is received with a status code of SUCCESS, a DMG STA shall write to each of the following MIB attributes the value of the corresponding subfield of the DMG BSS Parameter Configuration field of the DMG Operation element received from the AP or PCP to which it requested reassociation: 1) dot11PSRequestSuspensionInterval from the PSRequestSuspensionInterval subfield 2) dot11MinBHIDuration from the MinBHIDuration subfield 3) dot11BroadcastSTAInfoDuration from the BroadcastSTAInfoDuration subfield 4) dot11AssocRespConfirmTime from the AssocRespConfirmTime subfield 5) dot11MinPPDuration from the MinPPDuration subfield 6) dot11SPIdleTimeout from the SPIdleTimeout subfield 7) dot11MaxLostBeacons from the MaxLostBeacons subfield e) An MM-SME coordinated STA that receives a Reassociation Response frame with a status code of SUCCESS containing an MLME element with the Single AID field equal to 1, all of the STAs coordinated by the MM-SME are reassociated with the AP or PCP (i.e., shall be set to State 4 or, if dot11RSNAActivated is true, State 3). f) If a Reassociation Response frame is received with a status code other than SUCCESS or the reassociation fails to complete within dot11AssociationResponseTimeout: 1) Except when the association is part of a fast BSS transition, the state for the AP or PCP shall be set to State 2 with respect to the new AP or PCP. 2) The MLME shall issue an MLME-REASSOCIATE.confirm primitive to inform the SME of the failure of the reassociation. The ResultCode returned in the MLME- REASSOCIATE.confirm primitive indicates the cause of the failed reassociation attempt. Any misconfiguration or parameter mismatch, e.g., data rates required as basic rates that the STA did not indicate as supported in the STAâ€™s Supported Rates and BSS Membership Selectors element, shall be corrected before the SME issues an MLME-REASSOCIATE.request primitive for the same AP or PCP. If the status code indicates the reassociation failed because of a reason that is not related to configuration (e.g., the AP or PCP is unable to support additional associations) and the Reassociation Response frame does not include a Timeout Interval element with Timeout Interval Type equal to 3 the SME shall not issue an MLME- REASSOCIATE.request primitive for the same AP or PCP until a period of at least 2 s has elapsed. If the status code indicates the reassociation failed and the Reassociation Response frame contains a Timeout Interval element with Timeout Interval Type equal to 3, the SME shall not issue an MLME-REASSOCIATE.request primitive for the same AP or PCP until the period specified in the Timeout Interval element has elapsed. g) If an MLME-REASSOCIATE.confirm primitive is received with a ResultCode of SUCCESS, and RSNA is required, and the STA is in State 3, then the SME shall perform a 4-way handshake to establish an RSNA. As a part of a successful 4-way handshake, the SME shall enable protection by generation an MLME-SETPROTECTION.request(Rx_Tx) primitive h) Upon receipt of the MLME-SETPROTECTION.request(Rx_Tx), the MLME shall set the state of the STA to State 4. 1654 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.3.5.5 AP or PCP reassociation receipt procedures Upon receipt of a Reassociation Request frame from a STA the AP or PCP shall use the following procedure: a) The MLME shall issue an MLME-REASSOCIATE.indication primitive to inform the SME of the reassociation request. The SME shall issue an MLME-REASSOCIATE.response primitive addressed to the STA identified by the PeerSTAAddress parameter of the MLME- REASSOCIATE.indication primitive. If the reassociation is not successful, the SME shall indicate a specific reason for the failure to reassociate in the ResultCode parameter. Upon receipt of the MLME-REASSOCIATE.response primitive, the MLME shall transmit a Reassociation Response frame. b) If the state for the STA is 1 and the STA is a non-DMG STA, the SME shall refuse the reassociation request by issuing an MLME REASSOCIATE.response primitive with ResultCode NOT_AUTHENTICATED. c) AP with dot11InterworkingServiceActivated true only: If the MLME-REASSOCIATE.indication primitive has the EmergencyServices parameter set to true and the RSN parameter does not include an RSNE, the SME shall not reject the reassociation request on the basis that dot11RSNAActivated is true and dot11PrivacyInvoked is true thereby granting access, using unprotected frames (see 9.2.4.1.9), to the network for emergency services purposes. d) Otherwise, in an RSNA the SME shall check the values received in the RSN parameter to see whether the values received match the security policy. If they do not, SME shall refuse the reassociation by issuing an MLME-REASSOCIATE.response primitive with a ResultCode indicating the security policy mismatch. e) Otherwise, if the state for the STA is 4, the STA has a valid security association, the STA has negotiated management frame protection, the reassociation is not a part of a fast BSS transition, and there has been no earlier, timed out SA Query procedure with the STA (which would have allowed a new reassociation process to be started, without an additional SA Query procedure): 1) The SME shall refuse the reassociation request by issuing an MLME- REASSOCIATE.response primitive with ResultCode REFUSED_TEMPORARILY and TimeoutInterval containing a Timeout Interval element with the Timeout Interval Type field set to 3 (Association Comeback time). If the SME is in an ongoing SA Query with the STA, the Timeout Interval Value field shall be set to the remaining SA Query period, otherwise it shall be set to dot11AssociationSAQueryMaximumTimeout. 2) The state for the STA shall be left unchanged. 3) Following this, if the SME is not in an ongoing SA Query with the STA, the SME shall issue one MLME-SA-QUERY.request primitive addressed to the STA every dot11AssociationSAQueryRetryTimeout TUs until an MLME-SA-QUERY.confirm primitive for the STA is received or dot11AssociationSAQueryMaximumTimeout TUs from the beginning of the SA Query procedure have passed. The SME shall increment the TransactionIdentifier by 1 for each MLME-SA-QUERY.request primitive, rolling it over to 0 after the maximum allowed value is reached. 4) If no MLME-SA-QUERY.confirm primitive for a STA is received within the dot11AssociationSAQueryMaximumTimeout period, the SME shall allow a subsequent reassociation process to be started without starting an additional SA Query procedure, except that the SME may deny a subsequent reassociation process with the STA if an MSDU was received from the STA within this period. NOTEâ€”Reception of an MSDU implies reception of a valid protected frame, which obviates the need for the SA Query procedure. f) The SME shall refuse a reassociation request from a STA that does not support all the rates in the BSSBasicRateSet parameter in the MLME-START.request primitive. 1655 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications g) The SME shall refuse a reassociation request from an HT STA that does not support all of the MCSs in the Basic HT-MCS Set field of the HT Operation parameter in the MLME-START.request primitive. h) The SME shall refuse a reassociation request from a VHT STA that does not support all of the tuples indicated by the Basic VHT-MCS And NSS Set field of the VHT Operation parameter in the MLME-START.request primitive. i) If the ResultCode in the MLME-REASSOCIATE.response primitive is SUCCESS, the SME has an existing SA with the STA, and an SA Query procedure with that STA has failed to receive a valid response (i.e., has not received an MLME-SA-QUERY.confirm primitive within the dot11AssociationSAQueryMaximumTimeout period), the SME shall issue an MLME- DISASSOCIATE.request primitive addressed to the STA with ReasonCode INVALID_AUTHENTICATION. NOTEâ€”This MLME-DISASSOCIATE.request primitive generates a protected Disassociation frame. If the reassociation request was genuine, the STA has deleted the PTKSA by this point and so the protected Disassociation frame is ignored. The purpose is to inform a STA which has for some reason failed to respond to an SA Query procedure triggered by a forged reassociation request. j) If the ResultCode in the MLME-REASSOCIATE.response primitive is SUCCESS and the reassociation is not part of a fast BSS transition, the SME shall delete any PTKSA, GTKSA, IGTKSA and temporal keys held for communication with the STA by using the MLME- DELETEKEYS.request primitive (see 11.5.18 (RSNA security association termination)). k) If the MLME-REASSOCIATE.indication primitive includes an MMS parameter, the AP or PCP shall take the following additional action, as appropriate: 1) If the Single AID field in the MMS parameter of the MLME-REASSOCIATE.indication primitive is equal to 1, the AP or PCP may allocate a single AID for all of the STAs included in the MMS element. If the AP or PCP allocates the same AID to all STAs whose MAC address was included in the MMS element, it shall include the MMS element received from the MM- SME coordinated STA in the MLME-REASSOCIATE.response primitive. 2) If the Single AID field is 0, the AP or PCP shall allocate a distinct AID for each STA specified in the MMS element. l) If a Reassociation Response frame with a status code of SUCCESS is acknowledged by the STA, the state for the STA shall be set to State 4, or to State 3 if dot11RSNAActivated is true and the reassociation is not part of a fast BSS transition. m) If the ResultCode in the MLME-REASSOCIATE.response primitive is not SUCCESS and management frame protection is in use the state for the STA shall be left unchanged. If the ResultCode is not SUCCESS, management frame protection is not in use, and the reassociation is part of a fast BSS transition, the state for the STA shall be left unchanged. If the ResultCode is not SUCCESS, management frame protection is not in use, and the reassociation is not part of a fast BSS transition, the state for the STA shall be set to State 3 if it was State 4. n) If the ResultCode in the MLME-REASSOCIATE.response primitive is SUCCESS, RSNA establishment is required, and the reassociation is not part of a fast BSS transition, the SME shall attempt a 4-way handshake. Upon a successful completion of a 4-way handshake, the SME shall enable protection by issuing an MLME-SETPROTECTION.request(Rx_Tx) primitive and the state for the STA shall be set to State 4. o) AP only: The SME shall inform the DS of any changes in the state of the STA. p) If the ResultCode in the MLME-REASSOCIATE.response primitive is SUCCESS and the CurrentAPAddress parameter in the MLME-REASSOCIATION.indication primitive had the new APâ€™s MAC address in the CurrentAPAddress parameter (reassociation to the same AP), the AP shall match the non-AP STAs treatment of the listed agreements and allocations as described in 11.3.5.4 list item c). The AP deletes or resets to initial values those items that the non-AP STA is required in 1656 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.3.5.4 list item c) to delete or reset to initial values, and the AP does not modify the states, agreements and allocations that are listed as not affected by the reassociation procedure. 11.3.5.6 Non-AP and non-PCP STA disassociation initiation procedures The SME shall issue an MLME-DISASSOCIATE.request primitive that includes an appropriate Reason Code as defined in Table 9-45 of 9.4.1.7. Upon receipt of an MLME-DISASSOCIATE.request primitive, a non-AP and non-PCP STAâ€™s MLME shall disassociate from an AP or PCP using the following procedure: a) If the state for the AP or PCP is State 3 or State 4, the MLME shall transmit a Disassociation frame to the AP or PCP. b) The state for the AP or PCP shall be set to State 2 if it was not State 1. In the case of an MM-SME coordinated STA, the MLME shall perform this for each STA whose address was included in the MMS parameter of the MLME-ASSOCIATE.request or MLME-REASSOCIATE.request primitive that established the association. c) The MLME shall issue an MLME-DISASSOCIATE.confirm primitive to inform the SME of the successful completion of the disassociation. d) Upon receiving an MLME-DISASSOCIATE.confirm primitive, the SME shall delete any PTKSA, GTKSA, IGTKSA and temporal keys held for communication with the AP or PCP by using the MLME-DELETEKEYS.request primitive (see 12.6.18) and by invoking an MLME- SETPROTECTION.request(None) primitive. In the case of an MM-SME coordinated STA, the MLME shall perform this for each STA whose address was included in the MMS parameter of the MLME-ASSOCIATE.request or MLME-REASSOCIATE.request primitive that established the association. 11.3.5.7 Non-AP and non-PCP STA disassociation receipt procedure Upon receipt of a Disassociation frame from an AP or PCP for which the state is State 3 or State 4, if management frame protection was not negotiated when the PTKSA(s) were created, or if management frame protection is in use and the frame is not discarded per management frame protection processing, a non-AP and non-PCP STA shall disassociate from the AP or PCP using the following procedure: a) The state for the AP or PCP shall be set to State 2. b) The MLME shall issue an MLME-DISASSOCIATE.indication primitive to inform the SME of the disassociation. c) Upon receiving the MLME-DISASSOCIATE.indication primitive, the SME shall delete any PTKSA, GTKSA, IGTKSA and temporal keys held for communication with the AP or PCP by using the MLME-DELETEKEYS.request primitive (see 12.6.18) and by invoking an MLME- SETPROTECTION.request(None) primitive. The MM-SME shall perform this process for each STA whose address was included in the MMS parameter of the MLME-ASSOCIATE.request or MLME-REASSOCIATE.request primitive that established the association. d) If the reason code indicates a configuration or parameter mismatch as the cause of the disassociation, the SME shall not attempt to associate or reassociate with the AP or PCP until the configuration or parameter mismatch has been corrected. e) If the reason code indicates the STA was disassociated for a reason other than configuration or parameter mismatch, the SME shall not attempt to associate or reassociate with the AP or PCP until a period of 2 s has elapsed. 1657 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.3.5.8 AP or PCP disassociation initiation procedure The SME shall issue an MLME-DISASSOCIATE.request primitive that includes an appropriate Reason Code as defined Table 9-45 of 9.4.1.7. Upon receipt of an MLME-DISASSOCIATE.request primitive, an AP or PCP shall disassociate a STA using the following procedure: a) If the state for the STA is State 3 or State 4, the AP or PCP shall generate a Disassociation frame to be transmitted to the indicated STA. NOTEâ€”As the Disassociation frame is a bufferable MMPDU, the transmission of this frame might be delayed by the operation of a power-saving protocol. The AID and the PTKSA are maintained (when applicable) until the frame is acknowledged or attempts to transmit the frame are abandoned. b) The state for the STA shall be set to State 2, if it was not State 1. The MM-SME shall perform this process for each STA whose address was included in the MMS parameter of the MLME- ASSOCIATE.request or MLME-REASSOCIATE.request primitive that established the association. c) Once the Disassociation frame is acknowledged or attempts to transmit the frame are abandoned, the MLME shall issue an MLME-DISASSOCIATE.confirm primitive to inform the SME of the disassociation. d) Upon receiving an MLME-DISASSOCIATE.confirm primitive, the SME shall delete any PTKSA, GTKSA, IGTKSA and temporal keys held for communication with the STA by using the MLME-DELETEKEYS.request primitive (see 12.6.18) and by invoking an MLME- SETPROTECTION.request(None) primitive. The MM-SME shall perform this process for each STA whose address was included in the MMS parameter of the MLME-ASSOCIATE.request or MLME-REASSOCIATE.request primitive that established the association. e) Upon receiving an MLME-DISASSOCIATE.confirm primitive, the SME shall release the AID assigned for the indicated STA, if the state for the indicated STA was State 3 or State 4. f) AP only: The SME shall inform the DS of the disassociation. 11.3.5.9 AP or PCP disassociation receipt procedure Upon receipt of a Disassociation frame from a STA for which the state is State 3 or State 4, if management frame protection was not negotiated when the PTKSA(s) were created, or if management frame protection is in use and the frame is not discarded per management frame protection processing, the AP or PCP shall disassociate the STA using the following procedure: a) The state for the STA shall be set to State 2. The MM-SME shall perform this process for each STA whose address was included in the MMS parameter of the MLME-ASSOCIATE.request or MLME- REASSOCIATE.request primitive that established the association. b) The MLME shall issue an MLME-DISASSOCIATE.indication primitive to inform the SME of the disassociation. c) Upon receiving an MLME-DISASSOCIATE.indication primitive the SME shall delete any PTKSA, GTKSA, IGTKSA and temporal keys held for communication with the STA by using the MLME-DELETEKEYS.request primitive (see 12.6.18) and by invoking an MLME- SETPROTECTION.request(None) primitive. The MM-SME shall perform this process for each STA whose address was included in the MMS parameter of the MLME-ASSOCIATE.request or MLME-REASSOCIATE.request primitive that established the association. d) AP only: The SME shall inform the DS of the disassociation. e) The SME shall release the AID assigned for the indicated STA. 1658 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.3.5.10 PBSS procedures for nonassociated STAs In a PBSS, there are four types of relationships between a PCP and the members of a PBSS: â€” Nonassociated, non-RSNA (when dot11RSNAActivated is false) â€” Associated, non-RSNA (when dot11RSNAActivated is false) â€” Associated, RSNA (when dot11RSNAActivated is true) â€” Nonassociated, RSNA (when dot11RSNAActivated is true) The following rules apply in the last case: a) In a PBSS, when a STA is in State 2 and dot11RSNAActivated is true, successful RSNA establishment changes the STA to State 4. Unsuccessful RSNA establishment leaves the state unchanged. b) In a PBSS, when a STA is in State 4, the STAâ€™s receipt of a disassociation notification changes the state to State 2. 11.3.6 Additional mechanisms for an AP collocated with a mesh STA If a STA to AP mapping is added to the DS with the STA being a non-AP STA in an infrastructure BSS and the AP being an access point that interconnects through a DS with a mesh gate (that is, AP and mesh gate are collocated; see Figure 4-10), this mesh gate shall verify that the MAC address of the STA does not belong to a mesh STA in the MBSS. See 4.5.3.3 and Clause 7 for association and STA to AP mapping in the DS. If the mesh gate determines that the authenticated STA has a MAC address that is a MAC address of a mesh STA in the MBSS, then the collocated access point shall deauthenticate the STA with Reason Code UNSPECIFIED_REASON or MACADDRESS-ALREADY-EXISTS-IN-MBSS. The mechanism for verifying the MAC address of the authenticated STA depends on the active path selection protocol and might be vendor specific. See 14.10.13 when HWMP is the active path selection protocol. 11.3.7 Communicating PBSS information Following the association or security association of a STA with a PCP, the PCP shall send an unsolicited Information Response frame (9.6.20.5 to all STAs associated with the PCP. The PCP shall send a broadcast Information Response frame and/or shall send individually addressed Information Response frames to each STA associated with the PCP. The PCP shall set the Subject Address field of the Information Response frame to the broadcast address and shall include in the Information Response frame the DMG Capabilities element for the PCP and each STA associated with the PCP. This process is referred to as PBSS information distribution. The PCP shall perform a PBSS information distribution at least once every dot11BroadcastSTAInfoDuration beacon intervals. 11.3.8 Neighbor report information upon rejection with suggested BSS transition An AP may provide neighbor report information to a STA that requests authentication or association by responding with an Authentication or (Re)Association Response frame that has the Reason Code field set to REJECTED_WITH_SUGGESTED_BSS_TRANSITION and that includes one or more Neighbor Report elements. 1659 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.4 TS operation 11.4.1 Introduction There are three types of traffic specifications: the TSPEC, the DMG TSPEC, and the PTP TSPEC. A TSPEC describes the traffic characteristics and the QoS requirements of a TS. The main purpose of the TSPEC is to reserve resources within the HC and, in the case of HCCA and HEMM access policies, to modify the HCâ€™s scheduling behavior. It also allows other parameters to be specified that are associated with the TS, such as a traffic classifier and acknowledgment policy. The DMG TSPEC (9.4.2.134) describes an allocation (also known as DMG allocation) within either a PBSS or a DMG infrastructure BSS. The purpose of the DMG TSPEC is to create or modify an allocation for the transmission of frames between DMG STAs that are members of a PBSS or that are members of an infrastructure BSS (10.36.6). To communicate between STAs in a PBSS or between non-AP DMG STAs in an infrastructure BSS, a TSPEC (as defined in 9.4.2.30) is used to create or modify a TS between those STAs. This TSPEC is referred to as a PTP TSPEC. In a DMG BSS, a TSPEC includes parameters that are associated with the TS such as maximum MSDU size, delay bound, and optionally the allocation carrying the TS. A single allocation can carry multiple TSs. Each TS is carried in one allocation, except when â€” The TS has an access policy of EDCA, where it can use all CBAP allocations with Source AID equal to the broadcast AID, all CBAP allocations with Source AID matching the source STA of the TS, and all CBAP allocations with Destination AID matching the destination STA of the TS; or â€” The TS has an access policy of SEMM, where it can use exactly one SP allocation as well as all CBAP allocations with Source AID equal to the broadcast AID, all CBAP allocations with Source AID matching the source STA of the TS, and all CBAP allocations with Destination AID matching the destination STA of the TS. A TS may have one or more TCLAS (within the discretion of the STA that sets up the stream) associated with it. A DMG STA or AP uses the parameters in the TCLAS elements to filter the MSDUs belonging to this TS for delivery as part of the TS. An Intra-Access Category Priority element may be associated with a TS by the inclusion of an Intra-Access Category Priority element in an ADDTS Request frame. The User Priority subfield of the Intra-Access Category Priority element shall be set to the same UP as specified in the User Priority subfield of the TS Info field. If dot11AlternateEDCAActivated is true, the Alternate Queue subfield is used to select the appropriate EDCA transmit queue when the Access Policy subfield of the TS Info field in the TSPEC is EDCA or HEMM. When an Intra-Access Category Priority element is associated with a TS, the Drop Eligibility subfield is used to indicate the drop eligibility of the MSDUs of this TS. TS may have zero or one Expedited Bandwidth Request (EBR) element associated with it. An AP uses the parameters in the EBR to understand the precedence level requested by a non-AP STA (see R.5.4). For example, the precedence level may be used to convey to the AP that the requested TS is for the purposes of placing an emergency call. Support for precedence levels greater than 18 is optional for STAs. TSPEC, PTP TSPEC, optional TCLAS, optional EBR, and optional Intra-Access Category Priority elements are transported over the WM by the ADDTS Request frame and the ADDTS Response frame, and across the MLME SAP by the MLME-ADDTS primitives. In addition, a TS could be created if a STA sends a resource request to an AP or PCP prior to initiating a transition to that AP or PCP, as part of performing FST (11.33), or in the Reassociation Request frame to that AP or PCP. 1660 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The DMG TSPEC is transported over the air within DMG ADDTS Request and DMG ADDTS Response frames and across the MLME SAP by the MLME-ADDTS primitives. Following a successful negotiation, a TS is created, identified within the non-AP STA by its TSID and direction, and identified within the HC by a combination of TSID, direction, and STA address. Following a successful negotiation of a DMG TSPEC in a PBSS or in a DMG infrastructure BSS, a new allocation is created, or an existing allocation is modified. Within a PBSS or infrastructure BSS, each allocation is uniquely identified by a combination of allocation ID, source AID, and destination AID. Following a successful negotiation of a PTP TSPEC or a TSPEC in a DMG BSS, the frames corresponding to the PTP TSPEC or TSPEC are identified within the STA by the combination of TSID, requesting non-AP DMG STA address, and responding non-AP DMG STA address and direction. It is always the responsibility of the non-AP STA to initiate the creation of a TS regardless of its direction. A STA that is not a DMG STA shall not transmit a PTP TSPEC or a DMG TSPEC. A non-AP DMG STA that is not the source DMG STA of a specific TS shall not initiate the exchange of a TSPEC to the AP DMG STA or PCP DMG STA to create that TS. Any non-AP DMG STA can issue a PTP TSPEC to any other non-AP DMG STA to create a TS. In the direct-link or TDLS direct-link case, it is the responsibility of the STA that is going to send the data to create the TS. In this case, the STA negotiates with the HC to gain TXOPs that it uses to send the data. There is no negotiation between the originator and recipient STAs concerning the TS: the originator can discover the capabilities of the recipient (rates, Block Ack) using the DLS. In the case of traffic relayed by an AP or PCP, the sending and receiving non-AP and non-PCP STAs may both create individual TS for the traffic. In an infrastructure BSS, any traffic classifier created for the downlink TS applies equally regardless of whether the source is in the same BSS or reached through the DS. In a non-DMG infrastructure BSS, a non-AP STA may simultaneously support up to eight TSs from the HC to itself and up to eight TSs from itself to other STAs, including the HC. The actual number it supports may be less due to implementation restrictions. In a non-DMG infrastructure BSS, an HC may simultaneously support up to eight downlink TSs and up to eight uplink TSs per associated STA. The actual number it supports may be less due to implementation restrictions. In a DMG BSS there may be up to 16 TSs from a source DMG STA to a destination DMG STA. An additional 16 TSs may be created between the two DMG STAs by reversing the roles of source and destination. The actual number supported in any direction may be less due to implementation restrictions in either the source or destination DMG STA. In a non-DMG BSS, the traffic admitted in the context of a TSPEC can be sent using EDCA, HCCA, or HEMM. This depends on the access policy set in the TS Info field in the TSPEC. A TSPEC request may be set so that both HCCA and EDCA mechanisms (i.e., HEMM) are used. In a DMG BSS, the traffic admitted in the context of a PTP TSPEC or TSPEC is sent according to the access policy set in the TS Info field of the PTP TSPEC or TSPEC, respectively. Specifically, the traffic is sent during one or more CBAP allocations if the access policy is EDCA, during an SP allocation if the access policy is SPCA, and during one SP allocation as well as zero or more CBAP allocations if the access policy is SEMM. A DMG STA transmitting a DMG TSPEC shall set the LP SC Used subfield within the DMG TSPEC to 1 to indicate that the low-power SC mode described in 21.7 is used during the allocation. All frames sent during 1661 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications such an allocation shall use the low-power SC mode. The STA shall set the LP SC Used subfield to 1 only if the STA identified in the Destination AID field within the DMG TSPEC supports the low-power SC mode (9.4.2.128.2). In all other cases, the LP SC Used subfield shall be set to 0. When dot11SSPNInterfaceActivated is true, TSPEC processing by the HC may be subject to limitations received from the SSPN interface. The SSPN may limit access to certain QoS priorities, and further restrict the data rate and delay used with any priority. 11.4.2 TSPEC construction TSPECs and DMG TSPECs are constructed at the SME, from application requirements supplied via the SME, and with information specific to the MAC layer. The value of the Minimum PHY Rate in a TSPEC shall satisfy the following constraints: a) For an uplink TS, it â€” Is included in dot11SupportedDataRatesTxTable and in the APâ€™s operational rate set, or â€” Corresponds to an HT MCS included in dot11SupportedMCSTxTable, if present, and in the APâ€™s operational HT MCS set, if defined, at a bandwidth and guard interval supported by the non-AP STA on transmission and permitted in the BSS, or â€” Corresponds to a VHT-MCS and NSS for which support is indicated by the combination of the Tx VHT-MCS Map subfield in the VHT Operation parameter of the MLME- (RE)ASSOCIATE.request primitive, if present, and the APâ€™s operational VHT-MCS and NSS set, if defined, and the VHT Capabilities Information field, at a bandwidth and guard interval supported by the non-AP STA on transmission and permitted in the BSS. b) For a downlink TS, it â€” Is included in the OperationalRateSet parameter of the MLME-JOIN.request primitive and supported by the AP on transmission,43 or â€” Corresponds to an HT MCS included in dot11SupportedMCSRxTable, if present, and supported by the AP on transmission, at a bandwidth and guard interval supported by the non- AP STA on reception and permitted in the BSS,44 or â€” Corresponds to a VHT-MCS and NSS for which support is indicated by the Rx VHT-MCS Map subfield in the VHT Operation parameter of the MLME-(RE)ASSOCIATE.request primitive, if present, and the Tx VHT-MCS Map subfield of the VHT Operation element advertised by the AP, if present, and the VHT Capabilities Information field, at a bandwidth and guard interval supported by the non-AP STA on reception and permitted in the BSS. c) For a bidirectional TS, it satisfies both a) and b) above. See K.4 for a description of the parameter choice for the TSPEC. NOTEâ€”This standard states no requirements on how a DMG TSPEC is to be generated. 11.4.3 TS life cycle Figure 11-14 summarizes the TS life cycle (using the HMSC syntax defined in ITU-T Recommendation Z.120 (2004). 43How a non-AP STA determines an APâ€™s non-HT rate transmission support is implementation dependent. The non-AP STA might conservatively use the basic rate set, or it might use knowledge of past transmissions by the AP, or it might use other means. 44 How a non-AP STA determines an APâ€™s HT MCS transmission support, if the Tx MCS Set subfield in the HT Capabilities element advertised by the AP is equal to 0 or if the Tx Rx MCS Set Not Equal subfield in that element is equal to 1, is implementation depen- dent. The non-AP STA might conservatively use the basic HT-MCS set, or it might use knowledge of past transmissions by the AP, or it might use other means. 1662 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Inactive FT Resource Failed TS Setup Request Reassociation Accepted TS Setup Deadline Reassociation Active Failed TS Suspension TS Renegotiation TS Renegotiation Rx: Frame Suspended TS Timeout TS Deletion Figure 11-14â€”TS life cycle Initially a TS is inactive. A STA shall not transmit any QoS Data frames in which the TID subfield of the QoS Control field matches an inactive TS. A TS may be established by a Resource Request appearing in a message as part of a fast BSS transition from a STA. Such a TS is created in the accepted state. If the STA subsequently reassociates with this AP, then the TS becomes active. If the STA does not reassociate prior to the expiration of the reassociation timeout, then the TS becomes inactive. Unless stated otherwise, in a DMG BSS, the owner of an SP is the source DMG STA for that SP, and the owner of a TXOP is the TXOP holder. A STA that owns an SP or a TXOP is said to have the ownership of the SP or the TXOP, respectively. The rules applicable to an SP or TXOP owner are defined in 10.36 and 11.4. 1663 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Following a successful TS setup initiated by a non-AP STA, the TS becomes active, and either the non-AP STA or the HC may transmit QoS Data frames whose TID contains this TSID (according to the Direction field). In the case of EDCA, the TID contains the UP value. While the TS is active, the non-AP STA can attempt to renegotiate the parameters of the TSPEC characterizing the TS or the parameters of the DMG TSPEC characterizing the allocation carrying the TS. An active TS becomes inactive following a TS deletion process initiated at either non-AP STA or HC. It also becomes inactive following a TS timeout detected at the HC, or if the HC within an AP when dot11SSPNInterfaceActivated is true determines as defined in 11.25.5 that the non-AP STAâ€™s TS has exceeded the transmitted MSDU limit for the access category in which the TS was admitted. In a DMG BSS, a TS timeout is detected at a non-AP STA and causes the TS deletion process to be initiated at the non-AP STA. When an active TS becomes inactive, all of the resources allocated for the TS are released. An active TS may become suspended if no activity is detected for a duration of a suspension interval. Upon detection of activity, the TS may be reinstated. While the TS is in the suspended state, the HC shall not reclaim the resources assigned to the TS. In a DMG BSS, a TS in which both the source and destination are non-AP and non-PCP STAs shall not be suspended. 11.4.4 TS setup 11.4.4.1 General A TS setup may be initiated by a non-AP STA or an AP. 11.4.4.2 Non-AP-STA-initiated TS setup Figure 11-15 shows the sequence of messages occurring at a TS setup initiated by a non-AP STA. This message sequence in this figure and in the subsequent figures does not show the acknowledgment. non-AP STA non-AP STA HC/non-AP STA HC/non-AP STA SME MAC MAC SME loop <1,n> MLME - ADDTS . request ADDTS Request MLME - ADDTS . indication MLME - ADDTS . response ADDTS Response MLME ADDTS . confirm Figure 11-15â€”TS setup 1664 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.4.4.3 AP-initiated TS setup Figure 11-16 shows the sequence of messages occurring at a TS setup initiated by the AP. This message sequence in this figure and in the subsequent figures does not show the acknowledgments. Non-AP Non-AP STA SME STA MAC HC MAC HC SME Higher Layer QoS Reservation Request (includes Higher layer Stream ID) MLME.ADDTS Reserve Request ADDTS Reserve Request MLME.ADDTS Reserve Indication loop <0,n> ADDTS Request ADDTS Response MLME.ADDTS Reserve ADDTS Reserve Response MLME.ADDTS Response Reserve Confirm Higher Layer QoS Reservation Response Frame includes Higher Layer Stream ID Figure 11-16â€”TS setup when initiated by the AP TS setup may be initiated by an AP in response to a request originating from higher layer protocols. An AP in which dot11RobustAVStreamingImplemented is true shall not send ADDTS Reserve Request frames to an associated STA that has set the RobustAVStreaming bit in the Extended Capabilities element in its (Re)Association Request frame to 0. The higher layer stream ID is defined by the higher layer protocol. The Higher Layer Stream ID element shall be included in the ADDTS Reserve Request frame sent by the AP to the non-AP STA. This Higher Layer Stream ID is used in the TS setup procedure between the AP and the non-AP STA. The AP initiates the TS setup by sending an ADDTS Reserve Request frame that includes the Higher Layer Stream ID element to the non-AP STA. On receipt of the ADDTS Reserve Request frame from the AP, the non-AP STA shall perform one of the following: a) Complete the AP-initiated TS setup procedure by sending an ADDTS Reserve Response frame that includes the Higher Layer Stream ID corresponding to the AP-initiated TS setup procedure and with the status code set to â€œSUCCESS.â€ 1665 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications b) Send an ADDTS Reserve Response frame with a status code not equal to SUCCESS and abort the AP-initiated TS setup. The Higher Layer Stream ID field in this ADDTS Reserve Response frame shall be set to the Higher Layer Stream ID corresponding to the AP-initiated TS setup procedure. c) Send an ADDTS Request frame to the AP. There might be multiple ADDTS Request/ADDTS Response exchanges between the non-AP STA and the AP, as described in 11.4.4.4, to negotiate the TSPEC parameters. The Higher Layer Stream ID shall be included in all frames corresponding to the AP-initiated TS setup procedure that are exchanged between the non-AP STA and the AP. The AP-initiated TS setup procedure is completed by sending an ADDTS Reserve Response frame that includes the Higher Layer Stream ID corresponding to the AP-initiated TS setup procedure and with the status code set to indicate the result of the TSPEC negotiation. NOTE 1 Stream Reservation Protocol (SRP) as described in Clause 35 of IEEE Std 802.1Q-2011 is an example of a higher layer protocol. The IEEE 802.11 subsystem at a non-AP STA does not interpret the SRP reservation request but simply sends it to the AP with which it is associated. A higher layer agent called Designated Multiple Stream Registration Protocol (MSRP) Node (DMN) is co-located with the AP in the device that supports SRP. All incoming SRP reservation requests are forwarded to the MSRP DMN. The MSRP DMN interprets the SRP reservation request and invokes appropriate IEEE 802.11 primitives in order for the AP to invoke the MLME-ADDTSRESERVE.request primitive. The MSRP DMN responds to the originator of the SRP Reservation request with the outcome of the AP-initiated TS setup procedure. The procedures performed by the MSRP DMN are described in C.3 of IEEE Std 802.1Q-2011. NOTE 2 If the higher layer SRP Reservation Request message is lost within the IEEE 802.11 subsystem, the corresponding retry/recovery procedure is the responsibility of the SRP protocol. These procedures are described in Clause 35 of IEEE Std 802.1Q-2011. 11.4.4.4 TS setup procedures for both AP and non-AP STA initiation The non-AP STAâ€™s SME decides that a TS needs to be created. How it does this, and how it selects the TSPEC or DMG TSPEC parameters, is beyond the scope of this standard. The SME generates an MLME- ADDTS.request primitive containing a TSPEC or DMG TSPEC. A TSPEC or DMG TSPEC may also be generated autonomously by the MAC without any initiation by the SME. NOTEâ€”Such a TPSEC or DMG TPSEC might be overridden as a result of a subsequent MLME-ADDTS.request primitive from the SME (see 11.4.4.5) The STAâ€™s MLME transmits the TSPEC or DMG TSPEC in an ADDTS Request frame to the HC/non-AP STA. If the non-AP STAâ€™s MLME is in power save mode, the STA shall include its DMG Wakeup Schedule element in the ADDTS Request frame variant and in the DMG ADDTS Request frame variant. The HC/non-AP STAâ€™s MLME receives this Management frame and generates an MLME- ADDTS.indication primitive to its SME containing the TSPEC or DMG TSPEC. The SME in the HC/non-AP STA decides whether to admit the TSPEC or DMG TSPEC with its associated TCLAS element(s) (if present) and TCLAS Processing element (if present), as specified, refuse the TSPEC or DMG TSPEC, or not admit but suggest an alternative TSPEC, DMG TSPEC, or TCLAS element(s), or TCLAS Processing element. A DMG STA that responds with an ADDTS Response frame and an HC may change the value of parameters that have been set unspecified by the STA to any value that it deems appropriate, including leaving them unspecified. If the TSPEC or DMG TSPEC is received from a non-AP STA by an AP when dot11SSPNInterfaceActivated is true, the HC shall use the permissions stored in dot11InterworkingEntry for that STA in the decision to admit or deny the request (see 11.25.5.3). The SME then generates an MLME- ADDTS.response primitive containing the TSPEC or DMG TSPEC, zero or more TCLAS element(s) (only if present in the request) and TCLAS Processing element (only if present in the request) and a ResultCode value. The contents of the TSPEC or DMG TSPEC field, TCLAS element(s) (if present), TCLAS 1666 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Processing element (if present), and ResultCode field contain values specified in 6.3.26.5.2. The SME may include fewer TCLAS elements in the MLME-ADDTS.response primitive than were present in the request; when the SMEâ€™s response includes a single TCLAS element, it shall not include a TCLAS Processing element. If the SME changes a TCLAS elementâ€™s Classifier Type field in the MLME-ADDTS.response primitive but is unable to suggest a value for the Classifier Mask field, it shall set that field to 0. If the SME changes a TCLAS elementâ€™s Classifier Type field or Classifier Mask field in the MLME-ADDTS.response primitive but is unable to suggest values for one or more Classifier Parameter subfields, it shall set those subfields to 0. When the HC in an AP that has dot11SSPNInterfaceActivated equal to true receives a TSPEC, the AP shall inspect it to determine the requested access policy, user priority, and mean data rate as follows: a) The access category shall be determined from the user priority according to Table 10-1. For a TS to be admitted when the requested access policy is EDCA, both of the following shall be true: 1) The field corresponding to this access category in dot11NonAPStationAuthAccessCategories from the non-AP STAâ€™s dot11InterworkingEntry is equal to 1. 2) The sum of the mean data rate of all of the requesting STAâ€™s active TSs in this access category plus the mean data rate in the TSPEC is less than or equal to the non-AP STAâ€™s dot11InterworkingEntry for dot11NonAPStationAuthMaxVoiceRate, dot11NonAPStation- AuthMaxVideoRate, dot11NonAPStationAuthMaxBestEffortRate, or dot11NonAPStation- AuthMaxBackgroundRate depending on whether the derived access category is AC_VO, AC_VI, AC_BE or AC_BK, respectively. b) For a TS to be admitted when the requested access policy is HCCA, all of the following shall be true: 1) The dot11NonAPStationAuthHCCAHEMM value is true. 2) The sum of the mean data rate of all of the requesting STAâ€™s active TSs having access policy set to HCCA plus the mean data rate in the TSPEC is less than or equal to dot11NonAPStationAuthMaxHCCAHEMMRate in the non-AP STAâ€™s dot11InterworkingEntry. 3) The delay bound that will be provided by the HC in the TSPEC response is less than or equal to dot11NonAPStationAuthHCCAHEMMDelay in the non-AP STAâ€™s dot11InterworkingEntry. If the DMG TSPEC is admitted, the AP or PCP shall set the ResultCode to SUCCESS_STA_IN_PS_MODE if the STA identified by destination AID is in power save mode and shall include in the ADDTS Response frame the DMG Wakeup Schedule element of the destination DMG STA if one is established. In this case, the AP or PCP should defer including the TS schedule in the Extended Schedule element until both source DMG STA and destination DMG STA are in active mode. The HC/non-AP STAâ€™s MLME transmits an ADDTS Response frame containing this TSPEC or DMG TSPEC and status. The encoding of the ResultCode values to Status Code field values is defined in Table 9-46. The AP or PCP shall transmit the ADDTS Response frame to the STAs identified as source and destination AID of the DMG TSPEC contained in the ADDTS Request frame if the ADDTS request is sent by a non-AP and non-PCP STA. If the ResultCode is SUCCESS, the AP or PCP shall announce the creation of the allocation by setting the Allocation ID subfield in the TSPEC element sent in the ADDTS Response frame to a nonzero value and also by delivering the Extended Schedule element as defined in 10.36.6. In an AP when dot11SSPNInterfaceActivated is true, the HC shall set the dot11NonAPStationAddtsResultCode in the non-AP STAâ€™s dot11InterworkingEntry equal to the ResultCode. The STAâ€™s MLME receives this Management frame. It generates an MLME-ADDTS.confirm primitive to its SME containing the TSPEC or DMG TSPEC and status. The SME decides whether the response meets its needs. How it does this is beyond the scope of this standard. A SME receiving a modified TCLAS element having a Classifier Mask field equal to 0 or 1667 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Classifier Parameter subfields equal to 0 should regard these values as meaning that no suggested value has been provided by the HC. â€” If the result code is SUCCESS, the TS enters into an active state. â€” If the result code is REJECTED_WITH_SUGGESTED_BSS_TRANSITION, the non-AP STA may try to transition to other BSSs. In case that the non-AP STA is recommended to transition to other BSSs, it should do so according to the process defined in 11.24.7. Once the transition is completed, it should proceed with a TS setup process with the new HC. â€” Otherwise, the whole process can be repeated using the same TSID and direction, a modified TSPEC or DMG TSPEC, optional TCLAS element(s), and an optional TCLAS Processing element until the SME decides that the granted medium time is adequate or inadequate and cannot be improved. The above rules also apply to the negotiation of the PTP TSPEC and to the negotiation of the DMG TSPEC. The parameters that are set for a TS may be renegotiated in a similar manner (see 11.4.4.5). If the HC/PCP grants medium time for an ADDTS Request frame with the Ack Policy subfield equal to Block Ack and the Direction field equal to either downlink or bidirectional, then it shall initiate a block ack negotiation by sending an ADDBA Request frame to the STA that originated the ADDTS Request frame. If a non-DMG STA is granted medium time for an ADDTS Request frame with the Ack Policy subfield equal to Block Ack and the Direction field equal to other than downlink, then it shall initiate a block ack negotiation by sending an ADDBA Request frame to the recipient of the TS. In a non-DMG BSS, the combination of the TSID and Direction subfields identify the TS, in the context of the STA, to which the TSPEC applies. A bidirectional link request is equivalent to a downlink TS and an uplink TS, each with the same TSID and parameters. In a DMG BSS, the combination of the TSID, source DMG STA AID, destination DMG STA AID, and Direction subfields identifies the TS, in the context of the non-AP STA, to which the TSPEC applies. The same TSID may be used for multiple TSs at different STAs. A STA can use the same TSID subfield value for a downlink TSPEC and either an uplink or a direct-link TSPEC at the same time. In a non-DMG BSS, a non-AP STA shall not use the same TSID for both uplink and direct-link TS. In a DMG BSS, a non- AP STA as a source DMG STA can use the TSID subfield value for an uplink PTP TSPEC, and at the same time the non-AP STA as a destination DMG STA can use the same TSID subfield value for a downlink PTP TSPEC. If the TS Info Ack Policy subfield of a TSPEC or DMG TSPEC element is Block Ack and the type of Block Ack policy is unknown to the HC, the HC assumes, for TXOP scheduling, that the immediate block ack policy is being used (see 10.24). An HC shall be capable of receiving an ADDTS Request frame that contains a TCLAS element and capable of generating an indication that contains this as a parameter. When a STA requests service at a higher priority than authorized by its dot11InterworkingTableEntry, the HC may provide a suggested TSPEC or DMG TSPEC with a data rate and lower priority that would be authorized. Usage of the TSPEC in an Interworking environment is described in Annex K. A STA may include a U-PID element in ADDTS Request, DMG ADDTS Request, ADDTS Response and DMG ADDTS Response frames it transmits. The U-PID element is used to indicate the upper layer protocol responsible for handling MSDUs corresponding to the TID indicated within the frame carrying the U-PID element. If a U-PID element is not included in an ADDTS Request, DMG ADDTS Request, ADDTS Response or DMG ADDTS Response frame, MSDUs corresponding to the TID contain an LLC header that is used for upper layer protocol identification. 1668 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A U-PID element shall not be included in an ADDTS Response or DMG ADDTS Response frame if a U- PID element was not included in the corresponding ADDTS Request or DMG ADDTS Request frame. If a U-PID element was included in an ADDTS Request or DMG ADDTS Request frame, the same U-PID element shall be included in the corresponding ADDTS Response or DMG ADDTS Response frame if that frame has a Status Code of SUCCESS. The Status Code field shall be set to REJECT_U-PID_SETTING in the ADDTS Response or DMG ADDTS Response frame if the request is rejected frame due to the setting of the U-PID element received; this frame may contain an alternative U-PID element that is acceptable to the STA sending the ADDTS Response or DMG ADDTS Response frame. 11.4.4.5 TS renegotiation A non-AP STA may attempt to modify the parameters of a TSPEC or DMG TSPEC by transmitting an ADDTS Request or DMG ADDTS Request frame. If the Status Code in the corresponding ADDTS Response or DMG ADDTS Response frame is SUCCESS, then any TSPEC with the same TSID or DMG TSPEC with the same allocation ID is overridden with the TSPEC or DMG TSPEC in that frame, the HC and non-AP STA shall reset the inactivity interval timer, and the HC shall reset the suspension interval timer. 11.4.5 TS setup by resource request during a fast BSS transition A QoS STA may transmit a TSPEC as part of a RIC-Request in a resource request message. The SME in the hybrid coordinator (HC) decides whether to accept the TSPEC as specified, or refuse the TSPEC, or not accept but suggest an alternative TSPEC. It then generates a RIC-Response, according to the procedures given in 13.11. Each TS established by this resource request is placed in the accepted state. This state is an intermediate state between inactive and active. In the accepted state, the inactivity and suspension timers shall not be started for the TS. For a TS based on hybrid coordination function (HCF) controlled channel access (HCCA), the HC shall not generate CF-Poll for the TS. The SME may take the resource/timing requirements of the TS in the accepted state into consideration before assigning any further resources to any other admitted or accepted TS, and in calculating the available admission capacity for the BSS Load element. The TS is moved to the active state once the STA performs a reassociation to the AP (see 13.11.3). Once the TS becomes active, the inactivity and suspension timers are started. In an AP when dot11SSPNInterfaceActivated is true, the HC shall set the dot11NonAPStationAddtsResultCode in the non- AP STAâ€™s dot11InterworkingEntry equal to the Status Code in the corresponding RDE. If the reassociation timer times out and the TS is not yet in the active state, the TS goes back to the inactive state. 11.4.6 PSMP management A STA may attempt to create a scheduled PSMP session with its AP only if the AP has the S-PSMP Support field in the Extended Capabilities element equal to 1. The TSPEC reserves resources within the AP and modifies the APâ€™s scheduling behavior. The parameters in the TSPEC can be grouped into two categories: PSMP scheduling and PSMP reservation. The scheduling parameters are used by the AP to schedule a suitable SI. The reservation parameters are used by the AP to reserve time in the PSMP-UTT and PSMP-DTT. The service start time and SI specify the PSMP schedule in the responseâ€™s Schedule element. All other parameters result in a reservation for the PSMP-UTT and PSMP-DTT within the scheduled PSMP sequence. 1669 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications An AP shall terminate the PSMP session only when the last TS associated with the particular PSMP session is terminated. Once created, a PSMP session can be extended by another TSPEC setup. A STA that has an established PSMP session may issue an additional TSPEC request with the following: â€” The Aggregation field set to 1 â€” The Scheduled field set to 1 and APSD field set to 0 (S-PSMP) â€” The Minimum Service Interval and Maximum Service Interval fields both set to the Service Interval field value from the Schedule element specified when the PSMP session was established The AP shall return an identical Schedule element for all TSPEC response frames related to the same PSMP session. NOTEâ€”A STA that does not have an established PSMP session might send a TSPEC request specifying S-PSMP session with the same SI. The AP is free to choose between aggregating this request with an existing PSMP session of the same SI or creating a new PSMP session. The parameters of a TS already associated with the PSMP session may be changed; however, the SI shall not be changed. The start time of existing STAs in the PSMP schedule shall not be changed by the addition of a TSPEC from a new STA. A TSPEC that reserves resources for a STA under scheduled PSMP shall have the APSD and Scheduled fields set to indicate Scheduled PSMP as defined in Table 9-142. The non-AP STAâ€™s SME decides that a PSMP session needs to be established. How it makes this decision and how it selects the related TSPEC parameters are beyond the scope of this standard. The Minimum Service Interval field of the TSPEC element of an ADDTS Request frame shall be a multiple of the SI granularity indicated by the AP in its Extended Capabilities element. 11.4.7 Failed TS setup There are three possible types of failed TS setup: a) The transmission of ADDTS Request frame failed. b) No ADDTS Response frame is received from the HC/non-AP STA (e.g., because of delay due to congestion or because the response frame cannot be transmitted). c) An ADDTS Response frame is received that contains the Status Code field equal to REJECTED_FOR_DELAY_PERIOD. In this case, if the Delay field of the TS Delay element of the ADDTS Response frame is nonzero, the STA that transmitted the ADDTS Request frame shall not transmit another ADDTS Request frame to the same AP until the time indicated by the Delay field has elapsed. Figure 11-17 summarizes the two cases. In either case in a non-DMG BSS, if the request is not for an existing TS, the SME shall issue a DELTS.request to the HC specifying the TSID and direction of the failed request just in case the HC had received the request and it was the response that was lost. In either case in a DMG BSS, if the request is not for an existing allocation or TS, the SME shall issue a DELTS.request to the non-AP STA specifying the allocation ID or TSID and destination DMG STA of the failed request just in case the AP or PCP had received the request and it was the response that was lost. 1670 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications non-AP non-AP HC/non-AP STA HC/non-AP STA STA SME STA MAC MAC SME MLME-ADDTS.request ADDTS Request Failed ADDTS Request MLME-DELTS.request Failed DELTS Request MLME-DELTS.indication (a) case 1 non-AP non-AP HC/non-AP STA HC/non-AP STA STA SME STA MAC MAC SME MLME-ADDTS.request ADDTS Request MLME-ADDTS.indication MLME-ADDTS.response ADDTS Response Failed MLME-DELTS.request DELTS Request MLME-DELTS.indication (b) case 2 Figure 11-17â€”Failed TS setup detected within non-AP STAâ€™s MLME 11.4.8 Data transfer After the setup of a TSPEC or PTP TSPEC, MSDUs are classified above the MAC and are sent to the MAC through the MAC SAP using the MA-UNITDATA.request primitive with the priority parameter encoded to the TID. In a DMG BSS, MSDUs are transmitted using QoS Data frames. During each CBAP allocation, the MAC delivers MSDUs based on the priority of the transmitted QoS Data frames. The MAC can transmit all MSDUs having a TSID with an associated TSPEC with an access policy of EDCA or SEMM, provided that the source AID of the CBAP allocation is equal to the source AID of the TS, or the source AID of the CBAP allocation is equal to broadcast AID, or the destination AID of the CBAP matches the destination AID of the TS. During each SP allocation, the MAC delivers MSDUs whose TSIDs identify TSPECs that have been set up to use the SP allocation. Relative prioritization of multiple TSPECs mapped to the same SP allocation is implementation dependent and outside the scope of this standard. 1671 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications When an MSDU arrives from the MAC SAP with a TSID for which there is no associated TSPEC, the MSDUs shall be sent using EDCA with the access category AC_BE. The generation of the associated TID is done by a classifier above the MAC, and it may use the associated TCLAS elements if any are present. When there are multiple TCLAS elements and if the Processing subfield of TCLAS Processing element is 0, the priority parameter in the associated MA- UNITDATA.request primitive is set to TID if the classifier matches the parameters in all of the TCLAS elements associated with the TS. When there are multiple TCLAS elements and if the Processing subfield of the TCLAS Processing element is 1, the priority parameter in the associated MA-UNITDATA.request primitive is set to TID if the classifier matches the parameters in at least one of the TCLAS elements associated with the TS. When there is no TCLAS element and if the Processing subfield of the TCLAS Processing element is 2, the priority parameter in the associated MA-UNITDATA.request primitive is set to TID if the classifier cannot match the parameters to any of the TCLAS elements. An incoming MSDU that is not classified to a particular TS may be classified to another active TS based on the frame classifier for that TS. If, however, all of the frame classifiers for the active TS have been exhausted, the MSDU does not belong to any active TS and is classified to be a best-effort MSDU. See 5.1.1.3 for the treatment of an MSDU with a TSID for which there is no associated TSPEC. When an MSDU is classified using a TCLAS element, the original UP cannot be recovered by the receiver. If dot11AlternateEDCAActivated is true, if an Intra-Access Category Priority element was provided when the TS was created, and if the Access Policy subfield of the TS Info field in the TSPEC is EDCA or HEMM, the value from the Alternate Queue subfield is used to select the appropriate EDCA transmit queue. If an Intra-Access Priority element was provided when the TS was created, the Drop Eligibility subfield is used to determine the drop eligibility of the MSDU. 11.4.9 TS deletion 11.4.9.1 Deletion of a TS established between an HC, DMG AP, or PCP and a non-AP and non-PCP STA The STA may delete a TS in either of two ways: using non-PCP / non-AP STA initiation or using HC, DMG AP or PCP initiation. In both methods, the SME entity above the MAC generates an MLME-DELTS.request primitive specifying the TS to be deleted and the reason for deleting the TS. This causes the MAC to send a DELTS frame. The encoding of ReasonCode values to Reason Code field values is defined in Table 9-45. Having transmitted a DELTS frame, the initiating MAC deletes the TS identified in the DELTS frame when it receives an Ack frame that responds to this DELTS frame. There is no Management frame response. Figure 11-18 shows the case of TS deletion initiated by a non-PCP and non-AP STA and the case of TS deletion initiated by an HC, DMG AP, or PCP. An HC should not delete a TSPEC without a request from the SME, except for inactivity (see 11.4.10) or an HC service change that precludes the HC from continuing to meet the requirements of the TSPEC. All TSPECs that have been set up shall be deleted upon disassociation and reassociation. Reassociation causes the non-PCP and non-AP STA and HC, DMG AP, or PCP to clear their states, and the non-PCP and non-AP STA may then reinitiate the setup. 1672 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Non-PCP and Non-AP Non-PCP and Non-AP HC, DMG AP, or PCP HC, DMG AP, or PCP STA SME STA MAC MAC SME MLME - DELTS . request DELTS Request MLME - DELTS . indication (a) Initiated by non-PCP and non-AP STA HC, DMG AP, or PCP HC, DMG AP, or PCP Non-PCP and Non-AP Non-PCP and Non-AP SME MAC STA MAC STA SME MLME - DELTS . request DELTS Request MLME - DELTS . indication (b) Initiated by HC, DMG AP, or PCP Figure 11-18â€”TS deletion 11.4.9.2 Peer-to-peer TS deletion and deletion of an allocation This subclause describes deletion of a TS established between non-AP and non-PCP DMG STAs (i.e., established using a PTP TSPEC) and deletion of an allocation (i.e., established using a DMG TSPEC). In this subclause the following procedures for deletion of an allocation or TS are described: â€” Deletion of a TS established using a PTP TSPEC by either source or destination STAs â€” Deletion of an allocation by either source or destination STAs of that allocation, which might result in the deletion of one or more associated TSs â€” Deletion of an allocation (either SP or CBAP) by the AP or PCP The SME entity above the MAC generates an MLME-DELTS.request primitive specifying either the TS or the allocation to be deleted and the reason for deleting the TS or allocation, respectively. If generated within a non-AP and non-PCP STA, this primitive causes the MAC to send a single DELTS frame. If generated within an AP or PCP, this primitive causes the MAC to send one or two DELTS frames, as described below. The encoding of ReasonCode values to Reason Code field (see 9.4.1.7) values is defined in Table 9-45. A STA that receives an MLME-DELTS.request primitive for a TS that was established using a PTP TSPEC causes the MAC to send a DELTS frame to the peer STA of the TS. This is shown in Figure 11-19. NOTEâ€”The AP or PCP is unaware of the deletion of the TS. 1673 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Non-PCP/Non-AP Non-PCP/Non-AP Non-PCP/Non-AP Non-PCP/Non-AP STA SME STA MAC STA MAC STA SME MLME - DELTS . request DELTS Request MLME - DELTS . indication Figure 11-19â€”Deletion of a TS established using a PTP TSPEC A non-AP and non-PCP STA that receives an MLME-DELTS.request primitive for an allocation causes the MAC to send a DELTS frame to the AP or PCP. If it is transmitted by the STA identified by the Source AID of the allocation and if the Destination AID of the allocation is different from the broadcast AID, the AP or PCP shall send a DELTS frame to the STA identified by the Destination AID of the allocation. If it is transmitted by the STA identified by the Destination AID of the allocation and if the Source AID of the allocation is different from the broadcast AID, the AP or PCP shall send a DELTS frame to the STA identified by the Source AID of the allocation. The AP or PCP shall also delete the scheduling information corresponding to the allocation, identified by the DMG Allocation Info field of the DELTS frame. Figure 11-20 shows the deletion of an allocation in which both Source AID and Destination AID are not the broadcast AID. Source or Source or Peer Peer Destination Destination Non-AP/ Non-AP/ Non-AP/ Non-AP/ AP/PCP AP/PCP Non-PCP Non-PCP Non-PCP Non-PCP MAC HC SME STA MAC STA SME STA SME STA MAC MLME-DELTS.request (allocation) DELTS Request DELTS Request (allocation) (allocation) MLME-DELTS.indication MLME-DELTS.indication (allocation) (allocation) STA deletes any resources associated with STA deletes any resources associated with STA deletes any resources associated with allocation allocation allocation Figure 11-20â€”Deletion of an allocation in which both Source AID and Destination AID are not the broadcast AID An AP or PCP that receives an MLME-DELTS.request primitive for an allocation causes the MAC to send one or two DELTS frames. If the Destination AID of the allocation is different from the broadcast AID, the AP or PCP shall send a DELTS frame to the STA identified by the Destination AID of the allocation. If the Source AID of the allocation is different from the broadcast AID, the AP or PCP shall send a DELTS frame to the STA identified by the Source AID of the allocation. The AP or PCP shall also delete the scheduling information corresponding to the allocation, identified by the DMG Allocation Info field of the DELTS frame. An SME that deletes an allocation (using a MLME-DELTS.request primitive) or is notified that an allocation has been deleted (by receiving an MLME-DELTS.indication primitive) also locally deletes (i.e., updates it own resources, but does not cause any MAC frames to be transmitted) any TS that is dependent on that allocation as follows: 1674 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” Deleting an SP allocation shall also locally delete any TS with access policy SPCA or SEMM using the allocation. â€” Deleting a CBAP allocation with Source AID different from the broadcast AID shall also locally delete any TS with access policy EDCA using the allocation. â€” Deleting a CBAP allocation with Source AID equal to the broadcast AID shall also locally delete any TS with access policy EDCA using the allocation, unless there is another CBAP allocation the TS could use. A non-AP and non-PCP STA that associates, disassociates or reassociates (except for reassociation to the same AP) shall locally delete all existing allocations and all TSs that have been established using a PTP TSPEC. An AP or PCP that receives an MLME-ASSOCIATE.indication, MLME-REASSOCIATE.indication (except when the MLME-REASSOCIATE.indication primitive has this APâ€™s MAC address in the CurrentAPAddress parameter) or MLME-DISASSOCIATE.indication primitive from a STA (the â€œresettingâ€ STA) with which it has an existing association shall locally delete all allocations that have been established by the resetting STA using a PTP TSPEC. When deleting an allocation in which the Source AID or Destination AID correspond to the resetting STA and the peer STA is not identified by the broadcast AID, the AP or PCP shall send a DELTS to the peer STA to delete that allocation. NOTEâ€”If both Source AID and Destination AID are equal to the broadcast AID, the AP or PCP transmits no DELTS frames. It deletes scheduling information corresponding to the allocation, which is reflected in its subsequent transmission of frames containing an Extended Schedule element. A STA that generates an MLME-ASSOCIATE.request, MLME-REASSOCIATE.request (except when the MLME-REASSOCIATE.request primitive has the target APâ€™s MAC address in the CurrentAPAddress parameter) or MLME-DISASSOCIATE.request primitive shall locally delete all allocations and all TSs that have been established using a PTP TSPEC. NOTEâ€”Reassociation causes a STA to clear any state related to allocations and TSs that have been established using a PTP TSPEC. A non-PCP and non-AP STA might need to repeat the establishment of any allocations or TSs after reassociation needed to support applications active before the reassociation. In all of the cases listed above, the TS or allocation is deleted within the initiating MAC when the Ack frame to the Action frame is received. No Action frame response is generated. 11.4.10 TS timeout TS timeout is detected within the HC/non-AP STAâ€™s MAC when no traffic is detected on the TS within the inactivity timeout specified when the TS was created. For an uplink TS in a non-DMG BSS or for a TS that has the AP or PCP as the destination DMG STA in a DMG BSS, the timeout is based on the arrival of received MSDUs that belong to the TS, after any decryption and reassembly. For a downlink TS in a non-DMG BSS or for a TS that has the AP or PCP as the source DMG STA in a DMG BSS, the timeout is based on the following: â€” Arrival of valid MA-UNITDATA.request primitives using this TS at the MAC SAP when the QoS Data frames are sent with the Ack Policy subfield equal to No Ack â€” Confirmation of correctly sent MSDUs that belong to the TS within the MAC when the QoS Data frames are sent with the Ack Policy subfield set other than to No Ack In a DMG BSS and in the case of a TS that is established between non-AP STAs (PTP TSPEC), the timeout of the recipient is based on the arrival of MSDUs that belong to the TS within the MAC after any decryption, A-MSDU unpacking, and reassembly. 1675 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications In a TS established between non-AP STAs (PTP TSPEC), the timeout of the originator is based on the following: â€” Arrival of valid MA-UNITDATA.request primitives using this TS at the MAC SAP when the QoS Data frames are sent with the Ack Policy subfield set to No Ack â€” Confirmation of correctly sent MSDUs that belong to the TS within the MAC when the QoS Data frames are sent with the Ack Policy subfield set other than to No Ack In a direct-link TS in a non-DMG BSS, inactivity is considered to have happened if one of the two following events occurs: â€” The HC transmits a QoS CF-Poll frame and the polled STA returns a QoS Null immediately after a SIFS that contains a QoS Control field in which the Queue Size subfield contains 0. â€” The HC transmits a QoS CF-Poll frame, and no QoS Null frame is received within the granted TXOP duration that indicates the queue size for the related TSID. This is to confirm that the STA is actually using the assigned TXOP for the given TSID. In a non-DMG BSS, any other use of a polled TXOP delivered to the STA is considered to be activity on all direct-link TS associated with that STA. Detection of inactivity of this type is optional. In response to an inactivity timeout, an HC shall send a DELTS frame to the STA with the Reason Code set to TIMEOUT and inform its SME using the MLME-DELTS.indication primitive. In response to an inactivity timeout, a DMG AP shall send a DELTS frame to the non-AP DMG STA with the result code set to TIMEOUT and inform its SME using the MLME-DELTS.indication primitive. In response to an inactivity timeout, a PCP shall send a DELTS frame to the non-PCP DMG STA with the result code set to TIMEOUT and inform its SME using the MLME-DELTS.indication primitive. In a DMG BSS when a TS is established between non-AP STAs (PTP TSPEC), then in response to a TS timeout detected within the originator non-AP STA the non-AP STA shall send a DELTS frame to the recipient non-AP STA with the result code set to TIMEOUT and inform its SME using the MLME- DELTS.indication primitive. If the TS timeout is detected within the recipient non-AP STA, the STA shall send a DELTS frame to the originator non-AP STA with the result code set to TIMEOUT and inform its SME using the MLME-DELTS.indication primitive. The case of uplink TS timeout is shown in Figure 11-21. 11.4.11 TS suspension TS suspension occurs within the HCâ€™s MAC when no traffic is detected on the TS within the suspension interval specified when the TS was created. In the suspended state, the generation of QoS (+)CF-Poll frames is stopped for the related TS. 11.4.12 TS reinstatement A suspended TS may be reinstated following activity for that TS. For uplink and direct link, a suspended TS may be reinstated by a STA by sending a QoS Data or QoS Null frame. This frame may be sent at the highest priority using EDCA. The generation of successive QoS (+)CF- Poll frames shall then be resumed by the HC. For downlink, a suspended TS is reinstated by the HC when the AP receives an MSDU from a higher layer. 1676 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications non - AP non - AP HC STA HC STA STA SME STA MAC MAC SME QoS CF - poll I na ctivity Ti me r QoS CF -poll QoS CF - poll DELTS QoS Action Request MLME -DELTS.indication MLME -DELTS.indication (a) No response from STA non -AP non -AP HC STA HC STA STA SME STA MAC MAC SME QoS CF - poll Inactiv ity QoS DATA Tim er Ack QoS Null QoS CF - poll QoS Null QoS CF -poll QoS Null DELTS QoS Action Request MLME -DELTS.indication MLME -DELTS.indication (b) No Data frames from STA Figure 11-21â€”TS timeout 1677 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.4.13 DMG allocation formats 11.4.13.1 General A DMG STA manages allocations and TSs as described in 11.4.1 to 11.4.14. Using the DMG TSPEC, a DMG STA can indicate two types of allocation scheduling: isochronous and asynchronous. It should establish an isochronous allocation if it needs periodic access to the channel and does not expect to change the amount of time allocated frequently. It should establish an asynchronous allocation if it expects to make requests for channel time and wishes to reserve a minimum amount of channel time to satisfy for those requests when they occur. 11.4.13.2 Isochronous allocations In order to request the setup of an isochronous allocation, a DMG STA shall set the Allocation Format field in the DMG TSPEC element to 1. Following the successful admittance of a DMG TSPEC with an isochronous allocation, the AP or PCP should allocate time in the beacon interval to meet the periodicity and minimum allocation requirements specified in the DMG TSPEC element. Referring to fields in the DMG TSPEC element, the AP or PCP should check that over each Allocation Period the sum of the time allocations is at least the Minimum Allocation. In addition, the AP or PCP should check that each individual allocation has a minimum duration of at least Minimum SP Duration. See 9.4.2.134, 10.36.6, and 10.36.6.4. With an isochronous DMG TSPEC, the allocation period defines the period over which the channel time allocation repeats. The scheduler should check that at least the minimum allocation is made within each allocation period. The allocation may be composed of multiple SPs. The scheduler also checks that each SP making up the allocation is no shorter than the minimum SP duration. The scheduler is free to position the SPs that make up the allocation anywhere in the allocation period. The scheduler may allocate up to the maximum allocation each allocation period if resources permit. 11.4.13.3 Asynchronous allocations A DMG STA uses the SPR frame to request channel time for asynchronous traffic. For each TID, source DMG STA, and destination DMG STA tuple, the AP or PCP can maintain the amount of outstanding channel time that needs to be allocated. Each time it receives an SPR frame, the amount of outstanding channel time is set to the value received in the SPR frame from the source DMG STA for the identified TID and destination DMG STA. The amount of outstanding channel time is decreased by the amount allocated when channel time is scheduled for that TID, source DMG STA, and destination DMG STA tuple. A DMG STA may also use a DMG TSPEC to reserve resources for asynchronous traffic. In this case, the STA shall set the Allocation Format field in the DMG TSPEC element to 0. The AP or PCP should admit an asynchronous DMG TSPEC only if it is able to meet the minimum allocation requirements specified in the DMG TSPEC element. With an asynchronous DMG TSPEC, a DMG STA registers the minimum allocation it expects within the allocation period while an SP request is in effect that is greater than the minimum allocation specified. In addition, the STA expects that each allocation is at least of duration specified by the Minimum Duration field of the DMG TSPEC, provided the outstanding SP request is at least that long. In admitting a DMG TSPEC, the AP or PCP should check that there are sufficient resources available to meet the TSPEC requirements. 1678 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.4.14 PTP TS operation The ADDTS Request frame containing the PTP TSPEC may be sent to the peer non-AP DMG STA directly or through a DMG AP or PCP. A non-AP DMG STA may add TSs to an existing allocation with a peer non-AP DMG STA. To do this, the non-AP DMG STA transmits an ADDTS Request frame to the peer STA to include the additional TS. The ADDTS Request frame shall contain a PTP TSPEC with the Allocation ID subfield set to indicate the allocation for the additional TS. A TS with EDCA access policy does not need to be added to any CBAP allocation and can use any CBAP allocation as long as the source AID of the CBAP allocation matches the source AID of the TS, or the source AID of the CBAP allocation is equal to the broadcast AID, or the destination AID of the CBAP matches the destination AID of the TS. A non-AP DMG STA transmits an ADDTS Request frame to a peer non-AP DMG STA to add a TS to an existing allocation and to possibly communicate traffic-specific parameters such as A-MSDU subframe and Maximum MSDU Size with the peer non-AP DMG STA. The non-AP DMG STA may transmit the ADDTS Request frame directly to the peer STA or to the AP or PCP. In the latter case, the ADDTS Request frame shall contain a TCLAS element with the classifier type set to Ethernet parameters; the Source Address field shall contain the address of the STA that sends the ADDTS Request frame; and the Destination Address field shall contain the address of the peer STA, which is used by the AP or PCP to forward to the peer STA. The AP STA or PCP STA shall forward the received ADDTS Request frame to the STA with Address equal to the Destination Address field of the Classifier. If an ADDTS Response frame is received by the AP STA or PCP STA in response to the forwarded ADDTS Request frame, then the AP STA or PCP STA shall forward the ADDTS Response frame to the STA with Address equal to the Source Address field of the Classifier. The AP DMG STA and the PCP DMG STA shall not change the content of the elements included in the ADDTS Request and ADDTS Response frames. If a STA sets the Direction field to a value equal to downlink in the PTP TSPEC included in the ADDTS Request frame, the parameters apply to the STA as the destination DMG STA of that TS. For example, in this case, the Maximum MSDU Size field indicates that the STA is not able to receive MSDUs longer than the value presented in the MSDU Size field. Similarly, if the Direction field indicates uplink, the parameters apply to the STA as the source DMG STA of that TS. In this case, the STA that issued the ADDTS Request frame does not send MSDUs longer than the value of the Maximum MSDU Size field. 11.5 Block ack operation 11.5.1 Introduction Block ack may be set up at the MAC (see 10.24.2) or by the initiation of SME. The setup and deletion of block ack at the initiation of the SME is described in this subclause. 11.5.2 Setup and modification of the block ack parameters 11.5.2.1 General The procedures for setting up and modifying the block ack parameters are described in 11.5.2.2 and 11.5.2.3, respectively, and illustrated in Figure 11-22. 1679 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Originator Recipient STA SME STA MAC STA MAC STA SME MLME - ADDBA . request ADDBA Request MLME - ADDBA . indication MLME - ADDBA . response ADDBA Response MLME - ADDBA . confirm Figure 11-22â€”Block ack setup 11.5.2.2 Procedure at the originator Upon receipt of an MLME-ADDBA.request primitive, an initiating STA that intends to send QoS Data frames under the block ack mechanism shall set up the Block Ack using the following procedure: a) If the initiating STA is an HT STA, is a member of an IBSS, and has no other existing block ack agreement with the recipient STA, then the initiating STA shall transmit a Probe Request frame to the recipient STA and shall not transmit an ADDBA Request frame unless it receives a Probe Response frame from the recipient. NOTEâ€”When the block ack agreement is being established between a non-AP STA and its AP, then the originator and the recipient have exchanged capability information during the association exchange that allows them to determine whether the other STA is an HT STA. If the STA is establishing a block ack agreement with another STA through DLS, then the DLS setup procedure includes the exchange of capability information that allows both STAs to determine whether the other STA is an HT STA. b) If the peer STA is a non-DMG STA, check whether the intended peer STA is capable of participating in the block ack mechanism by discovering and examining its Delayed Block Ack and Immediate Block Ack capability bits. If the recipient is capable of participating, the originator sends an ADDBA Request frame indicating the TID and the buffer size. If the recipient is capable of participating and the GCRGroupAddress parameter of the MLME-ADDBA.request primitive is present, the originator sends an ADDBA Request frame that includes a GCR Group Address element. All DMG STAs are capable of participating in the block ack mechanism. c) If an ADDBA Response frame is received with the matching dialog token and the TID and with a status code equal to SUCCESS, the STA has established a block ack mechanism with the recipient STA; and the MLME shall issue an MLME-ADDBA.confirm primitive indicating the successful completion of the Block Ack setup. d) If an ADDBA Response frame is received with the matching dialog token and the TID and with a status code not equal to SUCCESS, the STA has not established a block ack mechanism with the recipient STA; and the MLME shall issue an MLME-ADDBA.confirm primitive indicating the failure of the Block Ack setup. 1680 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.5.2.3 Procedure at the recipient A recipient shall operate as follows in order to support Block Ack initialization and modification: a) When an ADDBA Request frame is received from another STA, the MLME shall issue an MLME- ADDBA.indication primitive. b) Upon receipt of the MLME-ADDBA.response primitive, the STA shall respond by an ADDBA Response frame with a result code as defined in 9.6.5.3. 1) If the result code is SUCCESS, the block ack agreement is considered to be established with the originator. Contained in the frame are the type of Block Ack and the number of buffers that have been allocated for the support of this block. 2) If the result code is REFUSED, the block ack agreement is not considered to have been established. The encoding of ResultCode values to Status Code field values is defined in Table 9-46. 11.5.2.4 Procedure common to both originator and recipient Once a block ack agreement has been successfully established between two STAs, the type of agreement thus established is dependent on the capabilities of the STAs and the contents of the ADDBA Request and ADDBA Response frames used to establish this agreement as defined in Table 11-4 for non-DMG STAs and in Table 11-5 for DMG STAs. Table 11-4â€”Types of block ack agreement based on capabilities and ADDBA conditions for non-DMG STAs Type of block ack Capabilities condition ADDBA condition agreement One or both of the STA are non-HT. Block Ack Policy subfield equal to 1 Immediate See NOTE 1. Block Ack Policy subfield equal to 0 Delayed Both STAs are HT STAs. Block Ack Policy subfield equal to 1 HT-immediate Both STAs are HT STAs, and both of the Block Ack Policy subfield equal to 0 HT-delayed STAs set the HT-delayed Block Ack subfield See NOTE 2. of the HT Capabilities element to 1. Both STAs are HT STAs, and at least one of Block Ack Policy subfield equal to 0 Delayed the STAs sets the HT-delayed Block Ack subfield of the HT Capabilities element to 0. Both STAs are robust AV streaming STAs, Block Ack Policy subfield equal to 1 GCR Block Ack and the agreement was established using ADDBA Request/Response frames that included GCR Group Address elements. NOTE 1â€”Non-HT block ack agreement is obsolete. Support for this mechanism might be removed in a later revision of the standard. NOTE 2â€”HT-delayed block ack agreement is obsolete. Support for this mechanism might be removed in a later revision of the standard. NOTEâ€”If the BlockAckReq and BlockAck variant is Extended Compressed and the Type of block ack agreement is HT-immediate, use of the RBUFCAP field is implementation dependent. 1681 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 11-5â€”Types of block ack agreement based on capabilities and ADDBA conditions for DMG STAs Type of BlockAckReq ADDBA Type of block Capabilities condition and condition ack agreement BlockAck variant Both STAs have the BlockAck with Flow Control field in Block Ack Compressed HT-immediate the DMG Capabilities element equal to 1. Policy subfield set to 0 At least one of the STAs has the BlockAck with Flow Block Ack Compressed HT-immediate Control field in the DMG Capabilities element equal to 0. Policy subfield set to 0 At least one of the STAs has the BlockAck with Flow Block Ack Extended HT-immediate Control field in the DMG Capabilities element equal to 0. Policy subfield Compressed set to 1 Both STAs have the BlockAck with Flow Control field in Block Ack Extended HT-immediate the DMG Capabilities element equal to 1. Policy subfield Compressed + flow control set to 1 11.5.3 Teardown of the block ack mechanism 11.5.3.1 General The procedure at the two STAs is described in 11.5.3.2 and 11.5.3.3 and illustrated in Figure 11-23. Initiator of deletion Responder STA SME STA MAC STA MAC STA SME MLME - DELBA . request DELBA Request MLME - DELBA . indication Figure 11-23â€”Block ack deletion 11.5.3.2 Procedure at the initiator of the block ack teardown Upon receipt of an MLME-DELBA.request primitive, the MLME shall tear down the block ack by transmitting a DELBA frame. The encoding of ReasonCode values to Reason Code field (see 9.4.1.7) values is defined in Table 9-45. 11.5.3.3 Procedure at the recipient of the DELBA frame A STA shall issue an MLME-DELBA.indication primitive with the parameter ReasonCode having a value of REQUESTED when a DELBA frame is received. 1682 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.5.4 Error recovery upon a peer failure Every STA shall maintain an inactivity timer for every negotiated block ack setup, unless the block ack agreement is set up for a GCR group address. The inactivity timer at a recipient is reset when MPDUs corresponding to the TID for which the block ack policy is set are received and the Ack Policy subfield in the QoS Control field of that MPDU header is Block Ack or Implicit Block Ack Request. The inactivity timer is not reset when MPDUs corresponding to other TIDs are received. The inactivity timer at the recipient is also reset when a BlockAckReq frame corresponding to the TID for which the block ack policy is set is received. The inactivity timer at the originator is reset when a BlockAck frame corresponding to the TID for which the block ack policy is set is received. When a timeout of BlockAckTimeout is detected, the STA shall send a DELBA frame to the peer STA with the Reason Code field set to TIMEOUT and shall issue an MLME-DELBA.indication primitive with the ReasonCode parameter having a value of TIMEOUT. The procedure is illustrated in Figure 11-24. STA SME STA MAC STA MAC STA SME QoS DATA BlockAck QoS DATA QoS DATA BlockAckReq BlockAckReq MLME DELBA . indication DELBA MLME DELBA . indication (a) At the originator STA SME STA MAC STA MAC STA SME Inactivity QoS DATA Timer MLME MLME DELBA DELBA . indication DELBA . indication (b) At the recipient Figure 11-24â€”Error recovery by the receiver upon a peer failure 1683 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications When a recipient does not have an active block ack for a TID, but receives Data frames with the Ack Policy subfield equal to Block Ack, it shall discard them and shall send a DELBA frame within its own TXOP. If such a STA receives a BlockAckReq frame, it may respond with an Ack frame and shall respond with a DELBA frame within its own TXOP. The originator may attempt to set up the use of block ack or may send the MPDUs using an alternative acknowledgment mechanism. When the recipient transmits a DELBA frame, it shall set the last sequence number received value to the sequence number of the last received MPDU, regardless of the acknowledgment policy used in that frame. When the originator receives a DELBA frame, it shall a) Discard any MPDU that has been transmitted and not acknowledged, with the possible exception if it was the last MPDU to be sent and it was not a retransmission, and b) Set the sequence number to either that of the last MPDU that is sent if it intends to retransmit or one beyond the last MPDU sent. 11.6 Higher layer timer synchronization 11.6.1 Introduction Higher layer timer synchronization is beyond the scope of this standard. However, explanation of how the constructs in this standard might be used to support such capabilities might be useful to the designer. One way to accomplish synchronization across a BSS is by multicasting synchronization (Sync) packets from the higher layers containing a time stamp and a sequence number. These packets would be opaque to the MAC and would be transported in the same way as any other MSDU (most likely addressed to the group address). Sync packets would be treated as a type of management packet by the higher layers. The time stamp in the Sync packet would contain the higher layer clock value at the time when the previous Sync packet was transmitted. The sequence number parameter has a value equal to the sequence number of the MSDU in which the time stamp is provided. The reason the packet would contain the time stamp for the previous Sync packet (rather than the current packet) is that hardware and layering constraints would prohibit the ability to provide a time stamp for the exact instant the current packet is transmitted within that packet. However, an MLME-HL-SYNC.indication primitive allows the transmitting STA to know exactly when each Sync packet is transmitted. A receiving STA might note the time when each Sync packet is received as well as the sequence number for that frame. The receiving STA would save this receive time indication for each packet along with its sequence number and compare the indication of the previously received Sync packet to the time stamp in the most currently received packet. This comparison allows the STA to compute an offset, which can be used to adjust its time reference to match that of the synchronization source. A check of the sequence number verifies that the correct packet is being used for time stamp comparison. It is possible a packet is lost; in this case, the received time stamp for the lost packet should be discarded. The last symbol of the Sync frame is indicated by the PHY using the PHY-TXEND.confirm and PHY- RXEND.indication primitives in the transmitter and receiver of the Sync frame, respectively. Practical limits on the coincidence of this indication and the last symbol of the Sync frame are implementation dependent. The accuracy of this technique also depends on the propagation delay between the source and receiving channel. However, both the time difference (between the PHY indication and the last symbol of the Sync frame) and the propagation delay can be considered as fixed-delay components. Therefore, they contribute only to the fixed time difference between the transmitter and receiver STAsâ€™ clocks and do not contribute to jitter. An implementation dependent scheme might be used to cancel or minimize this fixed time difference. The Sync frame may also be relayed through the AP. In this case, the STA that generates the time stamps notes the reception of the group addressed Sync frame from the AP as the indication to save the higher clock value for the next Sync frame. Receiving STAs would also similarly note the time when each Sync packet is 1684 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications received from the AP. The sequence number would include a value corresponding to the frame received from the AP. This is an example implementation using the higher layer timer synchronization feature. Other implementations are possible. 11.6.2 Procedure at the STA In order to determine whether to provide an MLME-HL-SYNC.indication primitive for a particular Data frame, a MAC that supports MLME-HL-SYNC primitives compares the Address 1 field in a Data frameâ€™s MAC header to a list of group addresses previously registered by an MLME-HL-SYNC.request primitive. If the MAC and the transmitter of the Sync frame are collocated within the same STA, the MLME-HL- SYNC.indication primitive shall occur when the last symbol of the PPDU carrying a matching Data frame is transmitted. Otherwise, the indication shall occur when the last symbol of the PPDU carrying the matching Data frame is received. In both cases, the MLME-HL-SYNC.indication primitive provided is simultaneous (within implementation dependent delay bounds) with the indication provided to other STAs within the BSS for the same Data frame. 11.7 DLS operation 11.7.1 General The STSL mechanism is obsolete. Consequently, the DLS protocol might be removed in a later revision of the standard. DLS is a protocol that enables a STA in an infrastructure network to transmit frames directly to another STA in the same infrastructure network. The need for this protocol is motivated by the fact that the intended recipient may be in PS mode, in which case it can be awakened only by the AP. The second feature of DLS is to exchange rate set and other information between the sender and the receiver. A DMG STA shall not use the DLS protocol. This protocol prohibits the STAs going into PS mode for the duration of the direct stream as long as there is an active DLS between the two STAs. DLS does not apply in an IBSS, where frames are always sent directly from one STA to another. DLS does not apply in an MBSS, because frames in an MBSS are always sent directly from one mesh STA to another. The handshake involved in the setup is illustrated in Figure 11-25. AP STA-1 STA-2 Figure 11-25â€”The four steps involved in direct-link handshake 1685 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The handshake involves the following steps: a) A STA, STA-1, that intends to exchange frames directly with another non-AP STA and dot11DLSAllowed is true, STA-2, invokes DLS and sends a DLS Request frame to the AP (step 1a in Figure 11-25). This request contains the rate set, capabilities of STA-1, and the MAC addresses of STA-1 and STA-2. If STA-1 is an HT STA, this request also contains the HT capabilities of STA-1. If STA-1 is a VHT STA, this response also contains a VHT Capabilities element representing the VHT capabilities of STA-1. b) If STA-2 is associated in the BSS, direct streams are allowed in the policy of the BSS (as determined by dot11DLSAllowedInQBSS), and STA-2 is indeed a QoS STA, then the AP forwards the DLS Request frame, independently of whether the AP is capable of decoding all of the fields in the body of the frame, to the recipient, STA-2 (step 1b in Figure 11-25). c) If STA-2 has dot11DLSAllowed true and accepts the direct stream, it sends a DLS Response frame to the AP (step 2a in Figure 11-25), which contains the rate set, (extended) capabilities of STA-2, and the MAC addresses of STA-1 and STA-2. If STA-2 is an HT STA, this response also contains an HT Capabilities element representing the HT capabilities of STA-2. If STA-2 is a VHT STA, this response also contains a VHT Capabilities element representing the VHT capabilities of STA-2. d) The AP forwards the DLS Response frame to STA-1 (step 2b in Figure 11-25), independently of whether the AP is capable of decoding all of the fields in the body of the frame. e) If the DLS Response frame contained a status code of SUCCESS, the direct link becomes active and frames may be sent from STA-1 to STA-2 and from STA-2 to STA-1. When a STA transitions to a different AP after a DLS is set up, the DLS shall be torn down as described in 11.7.5. 11.7.2 DLS procedures 11.7.2.1 General The DLS message flow is illustrated in Figure 11-26. Initiating STA AP Recipient STA SME MAC MAC SME MAC SME MLME- DLS.request DLS request DLS request MLME- DLS.indication DLS response DLS response MLME- DLS.confirm Figure 11-26â€”DLS message flow 1686 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.7.2.2 Setup procedure at the QoS STA A STA shall maintain a list of all STAs with which a direct link has been established. Upon receipt of an MLME-DLS.request primitive from the SME, the STA shall do one of the following actions: â€” Issue an MLME-DLS.confirm primitive with a result code of SUCCESS if the peer MAC address of MLME-DLS.request primitive is in the list of STAs with which direct link has been established; or â€” Initiate the setup of the direct link by sending the DLS Request frame to the AP (step 1a in Figure 11-25). Upon receipt of the DLS Request frame from the AP (step 1b in Figure 11-25), the MLME shall send to the AP a DLS Response frame (step 2a in Figure 11-25) with a result code of â€” SUCCESS if the STA is willing to participate in the direct link with the source STA. The STA shall also issue an MLME-DLS.indication primitive to the SME and shall add the source STA to the list of the STAs, if not already present, with which direct link has been established. â€” REFUSED if the STA is not willing to participate in the direct link. Upon receipt of the DLS Response frame from the AP (step 2b in Figure 11-25), the STA shall issue an MLME-DLS.confirm primitive. â€” If the result code is SUCCESS, the direct link is considered to be established with the destination STA in the DLS Response frame, and the MAC shall add the destination STA to the list of STAs with which direct link has been established. â€” If the result code is REFUSED, the direct links is not considered to have been established. 11.7.2.3 Setup procedure at the AP Upon receipt of the DLS Request frame (step 1a in Figure 11-25), the AP shall â€” Send DLS Response frame to the STA that sent the DLS Request frame with a result code of Not Allowed in the BSS, if direct links are not allowed in the BSS (step 2b in Figure 11-25), or for the AP with dot11SSPNInterfaceActivated equal to true with a result code of Not Allowed by SSP if the dot11NonAPStationAuthDls in either of the non-AP STAâ€™s dot11InterworkingTable is false. â€” Send DLS Response frame to the STA that sent the DLS Request frame with a result code of Not Present, if the destination STA is not present in the BSS (step 2b in Figure 11-25). â€” Send DLS Response frame to the STA that sent the DLS Request frame with a result code of Not a QoS STA, if the destination STA does not have QoS facility (step 2b in Figure 11-25). â€” Send the DLS Request frame, with all fields having the same value as the DLS Request frame received by the AP, to the destination STA (step 1b in Figure 11-25), independently of whether the AP is capable of decoding all of the fields in the body of the frame. Upon receipt of the DLS Response frame from a STA (step 2a in Figure 11-25), the AP shall send DLS Response frame to the source STA (step 2b in Figure 11-25). The mapping of Status Code field values to ResultCode parameter values in an MLME-DLS.confirm primitive is defined in Table 9-46. 11.7.2.4 Operation of the DLS Timeout Value field The DLS Timeout Value field within the DLS Request frame contains the duration, in seconds, after which the direct link is terminated, if there are no frame exchanges within this duration with the peer. A value of 0 implies that the direct link is never to be terminated based on a timeout. 1687 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.7.3 Data transfer after setup For each active direct link, a STA shall record the MAC and PHY features, rates, and MCSs that are supported by the other STA participating in the direct link, according to the Supported Rates and BSS Membership Selectors, Extended Supported Rates and BSS Membership Selectors, Capability Information, HT Capabilities, and VHT Capabilities fields within the DLS Request and DLS Response frames that were used to establish the direct link. A STA transmitting frames within a direct link shall not transmit frames using features, rates, or MCSs that are not supported by the other STA in the direct link. After establishing protection as required by 10.26 or 10.3.2.8, STAs may use features, rates, or MCSs that are supported by both of the STAs in the direct link, even when the AP does not support those features, except for transmission of a 40 MHz mask PPDU, which is governed by the rules found in 11.16.4. STAs participating in a direct link may set up a block ack agreement, if needed. The STAs may set up TSs with the HC to provide enough bandwidth or use polled TXOPs for data transfer. A protective mechanism (such as transmitting using HCCA, RTS/CTS, or the mechanism described in 10.26) should be used to reduce the probability of other STAs interfering with the direct-link transmissions. 11.7.4 DLS teardown 11.7.4.1 General The DLS teardown procedure is divided into STA-initiated and AP-initiated DLS teardown. The STA- initiated DLS teardown message flow is illustrated in Figure 11-27. Initiating STA AP Recipient STA SME MAC MAC SME MAC SME MLME-DLS- TEARDOWN.request DLS Teardown DLS Teardown MLME- DLS- TEARDOWN .indication Figure 11-27â€”STA-initiated DLS teardown message flow 11.7.4.2 STA-initiated DLS teardown procedure Upon receipt of MLME-DLS-TEARDOWN.request primitive from the SME, the STA shall initiate the teardown of the direct link by sending the DLS Teardown frame to the AP. The applicable values of ReasonCode are defined in Table 11-6. The encoding of the Reason Code field is defined in Table 9-45. Upon receipt of the DLS Teardown frame (from the AP), the STA shall issue an MLME-DLS- TEARDOWN.indication primitive to the SME and shall delete the STA from the list of the STAs with which direct link has been established. 1688 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 11-6â€”ReasonCode values for DLS teardown ReasonCode Applicable at STA_LEAVING Non-AP STA END_DLS Non-AP STA UNKNOWN_DLS Non-AP STA TIMEOUT Non-AP STA PEERKEY_MISMATCH AP PEER_INITIATED AP and Non-AP STA AP_INITIATED Non-AP STA The DLS teardown procedure shall apply to a specific DLS session, as each STA may have multiple simultaneous DLS sessions with other STAs. Prior to disassociation/deauthentication from the AP, the STA (STA1) shall initiate the teardown of any direct links it has by sending a DLS Teardown frame to the AP. If the DLS Teardown frameâ€™s Max Retry Limit was reached with no response from the AP, the STA shall send a DLS Teardown frame to its peer DLS STA (STA2). A recipient STA (STA2), on receipt of a DLS Teardown frame with ReasonCode equal to PEER_INITIATED (from STA1), shall send a DLS Teardown frame to the AP with ReasonCode set to PEER_INITIATED. An AP that receives a DLS Teardown frame with ReasonCode equal to PEER_INITIATED should send a DLS Teardown frame to any STAs that have a DLS link established with STA1. NOTEâ€”The failed STA can reestablish its DLS link according to 11.7. 11.7.4.3 Teardown procedure at the AP Upon receipt of the DLS Teardown frame from a STA, the AP shall send a DLS Teardown frame to the destination STA. Upon receipt of MLME-DLS-TEARDOWN.request primitive from the SME, the AP shall announce the tearing down of the direct link by sending the DLS Teardown frame to the two STAs using the direct link. The only applicable values of the ReasonCode are PEERKEY_MISMATCH and STA_LEAVING. The encoding to Reason Code field values is defined in Table 11-6. 11.7.4.4 AP-initiated DLS teardown procedure The AP-initiated DLS teardown procedure may be used when the STA is unable to initiate the DLS teardown. The AP should initiate a DLS teardown procedure when the AP detects that either end of a DLS link has left the BSS without teardown of the DLS link, e.g., through receipt of a Deauthentication frame or receipt of a Disassociation frame. If there are one or more STAs with open DLS connections with the STA being removed, the AP shall send a DLS Teardown frame to each such STA with ReasonCode AP_INITIATED. NOTEâ€”The AP can also initiate DLS teardown for implementation dependent reasons. 1689 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.7.5 Error recovery upon a peer failure Every STA shall maintain an inactivity timer for every negotiated direct link (i.e., STAs on both sides of the link maintain these timers). The DLS inactivity timer shall be reset for every successful frame transmission or reception for that direct link. The DLS timeout value is set according to the value of the DLS Timeout Value field in the DLS Request frame that initiated the direct link. If, for the period of time specified by the DLS timeout value, no frames are exchanged as part of the direct link, then the direct link becomes inactive. When the direct link becomes inactive due to timeout, the MLME issues an MLME-DLS- TEARDOWN.indication primitive to the SME and sends a DLS Teardown frame to the AP, with the peer MAC address as the destination MAC address and the reason code set to TIMEOUT. All frames shall henceforth be sent via the AP. If there has been a TS setup for the data transfer, it is the responsibility of the STAs to renegotiate the parameters of the TSPEC with the HC. When two STAs have set up a direct link, either STA may send DLS Request frames in order to update the DLS timeout value. If the updated DLS Request frame is accepted, both STAs initialize the timer to detect DLS timeout. Even if the updated DLS Request frame is not accepted, the original direct link remains active. 11.7.6 Secure DLS operation PeerKey handshake, defined in 12.7.8, is used to establish the keys needed to enable secure DLS. The PeerKey message exchange shall start after the DLS establishment and completed prior to initiation of the DLS Data frame exchange. The STKSA remains valid even if the STA disassociates from the originating AP, but the STKSA shall be deleted before a STA attempts another (re)association. If an AP transmits a Deauthenticate or Disassociate frame to a STA, the AP shall also initiate teardowns for any existing DLS. The DLS STKs shall be deleted when the DLS Teardown frames are sent or received. 11.8 TPC procedures 11.8.1 General Regulations that apply to the 5 GHz band in most regulatory domains require RLANs operating in the 5 GHz band to use transmitter power control, involving specification of a regulatory maximum transmit power and a mitigation requirement for each allowed channel. This standard describes such a mechanism, referred to as transmit power control (TPC). This subclause describes TPC procedures intended to satisfy needs in many regulatory domains and other frequency bands. These procedures might be useful for other purposes (e.g., reduction of interference, range control, reduction of power consumption). A STA shall use the TPC procedures defined in 11.8 if dot11SpectrumManagementRequired is true. dot11SpectrumManagementRequired shall be set to true when regulatory authorities require TPC. It may also be set to true in other circumstances. The TPC procedures provide for the following: â€” Association of STAs with an AP or PCP in a BSS based on the STAsâ€™ power capability (see 11.8.2) â€” Peering of mesh STAs based on the mesh STAsâ€™ power capability (see 11.8.3) â€” Specification of regulatory and local maximum transmit power levels for the current channel (see 11.8.5) â€” Selection of a transmit power for each transmission in a channel within constraints imposed by regulatory and local requirements (see 11.8.6) 1690 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” Adaptation of transmit power based on a range of information, including path loss and link margin estimates (see 11.8.7) If dot11SpectrumManagementRequired is true, a non-DMG STA shall not join an infrastructure BSS, MBSS or IBSS unless the Spectrum Management bit is 1 in the Capability Information field in Beacon frames and Probe Response frames or in the Condensed Capability Information field in Measurement Pilot frames received from other STAs in the BSS, with the following exceptions: â€” A STA may operate when the Spectrum Management bit is 0 if the STA determines that it is in a regulatory domain that does not require TPC or determines that it meets regulatory requirements even if TPC is not employed. Potential methods for determining the regulatory domain include receiving a country indication in the Beacon frame, Measurement Pilot frame, user confirmation, or configuration information within the device. Potential methods to meet regulations even if TPC is not employed include using a transmit power that is below the legal maximum (including any mitigation factor). â€” A STA shall set dot11SpectrumManagementRequired to true before associating with a BSS in which the Spectrum Management bit is 1 in the Capability Information field in Beacon frames and Probe Response frames or in the Condensed Capability Information field in Measurement Pilot frames received from the BSS. â€” An AP may allow association of devices that do not have the Spectrum Management bit equal to 1 in the Capability Information field in Association Request frames and Reassociation Request frames received from the STA to account for the existence of legacy devices that do not support TPC, but do meet regulatory requirements. A mesh STA shall set dot11SpectrumManagementRequired to true before becoming a member of an MBSS in which the Spectrum Management bit is equal to 1 in the Capability Information field in Beacon frames and Probe Response frames received from the MBSS. 11.8.2 Association based on transmit power capability A STA shall inform an AP or PCP of its minimum and maximum transmit power capability for the current channel when associating or reassociating, using a Power Capability element in (Re)Association Request frames. An AP or PCP might use the minimum and maximum transmit power capability of associated STAs as an input into an algorithm used to determine the local transmit power constraint for any BSS it maintains. The specification of the algorithm is beyond the scope of this standard. An AP or PCP may reject a (re)association request from a STA if it considers the STAâ€™s minimum or maximum transmit power capability to be unacceptable. For example, a STAâ€™s power capability might be unacceptable if it violates local regulatory constraints or increases the probability of hidden STAs by a significant degree. The criteria for accepting or rejecting a (re)association on the basis of transmit power capability are beyond the scope of this standard. If a STA sends a Country element, a Power Constraint element, and a Transmit Power Envelope element, where the interpretation of the Maximum Transmit Power Level field in the Country element for a 20 MHz or 40 MHz Subband Triplet field is the same as the Local Maximum Transmit Power Unit Interpretation subfield, then at least one of local power constraints indicated by the Local Maximum Transmit Power For 20 MHz and Local Maximum Transmit Power For 40 MHz fields in the Transmit Power Envelope element shall be the same as the indicated local power constraint expressed by the combination of Country element and Power Constraint element. NOTEâ€”An example of the interpretation of the Maximum Transmit Power Level field in the Country element for a 20 MHz or 40 MHz Subband Triplet field being the same as the Local Maximum Transmit Power Unit Interpretation subfield is when both are EIRP. 1691 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.8.3 Peering based on transmit power capability A mesh STA shall provide a candidate peer mesh STA with its minimum and maximum transmit power capability for the current channel when becoming a member of an MBSS, using a Power Capability element in Mesh Peering Open frames. A mesh STA may use the minimum and maximum transmit power capability of a neighbor peer mesh STA as an input into the algorithm used to determine the local transmit power constraint. The specification of the algorithm is beyond the scope of this standard. A mesh STA may reject a Mesh Peering Open request from a candidate mesh STA if it considers the candidate mesh STAâ€™s minimum or maximum transmit power capability to be unacceptable. For example, a candidate mesh STAâ€™s power capability might be unacceptable if it violates local regulatory constraints. The criteria for establishing or rejecting a Mesh Peering Open request on the basis of transmit power capability are beyond the scope of this standard. If a STA sends a Country element, a Power Constraint element, and a Transmit Power Envelope element, where the interpretation of the Maximum Transmit Power Level field in the Country element for a 20 MHz or 40 MHz Subband Triplet field is the same as the Local Maximum Transmit Power Unit Interpretation subfield, then at least one of the local power constraints indicated by a) the Local Maximum Transmit Power For 20 MHz field or b) Local Maximum Transmit Power For 40 MHz field in the Transmit Power Envelope element shall be the same as the indicated local power constraint expressed by the combination of Country element and Power Constraint element. 11.8.4 Interpretation of transmit power capability As regards the units of the Minimum Transmit Power Capability and Maximum Transmit Power Capability fields within the Power Capability element sent in a STAâ€™s (Re)Association Request frame to an AP, if all of the following apply â€” The STA is extended spectrum management capable. â€” The STA has dot11SpectrumManagementRequired or dot11RadioMeasurementActivated equal to true. â€” A Beacon or Probe Response frame has been received from the AP by the STA. â€” The Beacon or Probe Response frame includes one or more Transmit Power Envelope elements. then â€” The units shall be interpreted according to the Local Maximum Transmit Power Unit Interpretation subfield in the Transmit Power Information field in the Transmit Power Envelope element (see 9.4.2.162) sent in the most recently received Beacon or Probe Response frame. otherwise â€” The units shall be interpreted as EIRP. If the Beacon or Probe Response frame most recently received from a neighbor mesh STA by a mesh STA that is extended spectrum management capable and that has dot11SpectrumManagementRequired or dot11RadioMeasurementActivated equal to true includes one or more Transmit Power Envelope elements, then the units of the Minimum Transmit Power Capability and Maximum Transmit Power Capability fields within the Power Capability element sent in the Mesh Peering Open frame to the neighbor mesh STA shall be interpreted according to the Local Maximum Transmit Power Unit Interpretation subfield in the Transmit Power Information field in the Transmit Power Envelope element (see 9.4.2.162) sent in the most recently received Beacon or Probe Response frame. Otherwise, the units of the Minimum Transmit Power Capability 1692 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications and Maximum Transmit Power Capability fields within the Power Capability element sent in the mesh STAâ€™s Mesh Peering Open frame to the neighbor mesh STA shall be interpreted as EIRP. 11.8.5 Specification of regulatory and local maximum transmit power levels A STA shall determine a regulatory maximum transmit power for the current channel by selecting the minimum of the following: â€” Any regulatory maximum transmit power received in a Country element from the AP in its BSS, PCP in its PBSS, another STA in its IBSS, or a neighbor peer mesh STA in its MBSS â€” Any regulatory maximum transmit power for the channel in the current regulatory domain known by the STA from other sources A STA shall determine a local maximum transmit power for the current channel by selecting the minimum of the following: â€” Unless the STA is extended spectrum management capable and has received a Transmit Power Envelope element for a channel width of 20 MHz and 40 MHz, any local maximum transmit power received in the combination of a Country element and a Power Constraint element from the AP in its BSS, PCP in its PBSS, another STA in its IBSS, or a neighbor peer mesh STA in its MBSS â€” If the STA is extended spectrum management capable, any local maximum transmit power received in a Transmit Power Envelope element from the AP in its BSS, another STA in its IBSS, or a neighbor peer mesh STA in its MBSS â€” Any local maximum transmit power for the channel regulatory domain known by the STA from other sources The Local Power Constraint field of any transmitted Power Constraint element and each Local Maximum Transmit Power For X MHz field (where X = 20, 40, 80, or 160/80+80) in the Transmit Power Envelope element shall each be set to its respective value that allows the mitigation requirements to be satisfied in the current channel. NOTEâ€”The local maximum transmit power for the channel needs to meet the mitigation requirements for the channel in the current regulatory domain. The conservative approach is to set the local maximum transmit power level equal to the regulatory maximum transmit power level minus the mitigation requirement. However, it might be possible to satisfy the mitigation requirement using a higher local maximum transmit power level. A lower local maximum transmit power level might be used for other purposes (e.g., range control, reduction of interference). The regulatory and local maximum transmit powers may change in a STA during the life of an infrastructure BSS and an MBSS. However, network stability needs to be considered when deciding how often or by how much these maximums are changed. The regulatory and local maximum transmit powers shall not change during the life of an IBSS. An AP, IBSS STA, or mesh STA shall advertise the regulatory maximum transmit power for that STAâ€™s operating channel in Beacon frames and Probe Response frames using a Country element. An AP, IBSS STA or mesh STA shall advertise the local maximum transmit power for that STAâ€™s operating channel in Beacon frames and Probe Response frames using the combination of a Country element and a Power Constraint element. If an AP, IBSS STA, or mesh STA is extended spectrum management capable, it shall advertise the local maximum transmit power for that STAâ€™s operating channel in Beacon frames and Probe Response frames using one Transmit Power Envelope element for each distinct value of the Local Maximum Transmit Power Unit Interpretation subfield that is supported by the BSS, IBSS, or MBSS, respectively. Each Transmit Power Envelope element shall include a local power constraint for all channel widths supported by the BSS. STAs that are extended spectrum management capable and have dot11RadioMeasurementActivated equal to true should be able to reduce their EIRP to 0 dBm. 1693 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NOTEâ€”When the local maximum transmit power is set by an AP for radio resource management, a typical low value for the local power constraint is 0 dBm. A STA that cannot reduce its transmit power to this level or below will not be able to associate to the AP. The PCP in a PBSS shall advertise both the regulatory maximum transmit power and the local maximum transmit power for its operating channel in Announce and Probe Response frames (using a Country element for the regulatory maximum and a combination of a Country element and a Power Constraint element for the local maximum). In addition, it should advertise both regulatory and local maximum transmit power in DMG Beacon frames. When dot11SpectrumManagementRequired is false and dot11RadioMeasurementActivated is true, an AP or a PCP may include a Power Constraint element and a Transmit Power Envelope element in Beacon, DMG Beacon, Announce, and Probe Response frames. 11.8.6 Transmit power selection A STA may select any transmit power for transmissions in a channel within the following constraints: â€” A STA shall determine a regulatory maximum transmit power and a local maximum transmit power for a channel in the current regulatory domain before transmitting in the channel. â€” An AP shall use a transmit power less than or equal to the regulatory maximum transmit power level for the channel. The AP shall also meet any regulatory mitigation requirement. â€” A non-AP STA shall use a transmit power less than or equal to the local maximum transmit power level for the channel. 11.8.7 Transmit power adaptation A STA may use any criteria, and in particular any path loss and link margin estimates, to dynamically adapt the transmit power for transmissions of an MPDU to another STA. The adaptation methods or criteria are beyond the scope of this standard. A STA may use a TPC Request frame to request another STA to respond with a TPC Report frame reporting link margin and transmit power information. A STA that receives a TPC Request frame shall respond with a TPC Report frame that contains a TPC Report element in which the Transmit Power field indicates the power used to transmit the response and the Link Margin field indicates the estimated link margin. A DMG STA may also use the link measurement procedure and the DMG Link Margin element to exchange TPC information. An AP, PCP, or IBSS STA shall autonomously include a TPC Report element with the Link Margin field set to 0 in Beacon frames, DMG Beacon frames, Announce frames, or Probe Response frames. 11.9 DFS procedures 11.9.1 General Regulations that apply to the 5 GHz band in most regulatory domains require RLANs operating in the 5 GHz band to implement a mechanism to avoid co-channel operation with radar systems and to uniformly utilize available channels. This standard describes such a mechanism, referred to as dynamic frequency selection (DFS). This subclause describes DFS procedures that can be used to satisfy these and similar future regulatory requirements. The procedures might also satisfy comparable needs in other frequency bands and might be useful for other purposes. For example, some of the procedures described in this subclause could be used for channel selection in a DMG BSS. 1694 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A STA shall use the DFS procedures defined in 11.9.1 to 11.9.9 if dot11SpectrumManagementRequired is true. A STA shall use the DFS procedures defined in 11.9.10 if dot11SpectrumManagementRequired and dot11FutureChannelGuidanceActivated are true. Attribute dot11SpectrumManagementRequired shall be set to true when regulatory authorities require DFS. It may also be set to true in other circumstances. The DFS procedures provide for the following: â€” Associating STAs with an AP based on the STAsâ€™ supported channels (see 11.9.2) â€” Quieting the current channel so it can be tested for the presence of radar with less interference from other STAs (see 11.9.3) â€” Testing channels for radar before using a channel and while operating in a channel (see 11.9.4) â€” Discontinuing operations after detecting radar in the current channel to avoid further interference with radar (see 11.9.5) â€” Detecting radar in the current and other channels, based on regulatory requirements (see 11.9.6) â€” Requesting and reporting measurements in the current and other channels (see 11.9.7) â€” Selecting and advertising a new channel to assist the migration of a BSS after radar is detected (see 11.9.8) â€” Guiding STAs about the likely future channel should the AP leave this channel (see 11.9.10). In a DMG BSS, the following DFS procedures apply: â€” Associating a STA with an AP or a PCP based on the STAâ€™s supported channels (see 11.9.2) â€” Quieting the current channel so it can be tested for interference with less interference from associated STAs (see 11.9.3) â€” Requesting and reporting measurements in the current and other channels (see 11.9.7) â€” Selecting and advertising a new channel to assist the migration of an infrastructure BSS, IBSS, or PBSS (see 11.9.8) For the purposes of DFS in a non-DMG BSS, the following statements apply: â€” A STA with dot11SpectrumManagementRequired true shall not operate in a BSS unless the Spectrum Management bit is 1 in the Capability Information field in Beacon frames and Probe Response frames received from other STAs in the BSS, with the following exception. â€” A STA may operate when the Spectrum Management bit is 0 if the STA determines that it is in a regulatory domain that does not require DFS or determines that it meets regulatory requirements even if DFS is not employed. Potential methods for determining the regulatory domain include receiving a country indication in the Beacon frame, user confirmation, or configuration information within the device. Potential methods to enable regulations to be met even if DFS is not employed include independently detecting radar and ceasing operation on channels on which radar is detected. â€” A STA shall set dot11SpectrumManagementRequired to true before associating with an infrastructure BSS, IBSS, or MBSS in which the Spectrum Management bit is 1 in the Capability Information field in Beacon frames and Probe Response frames received from the infrastructure BSS, IBSS, or MBSS. â€” An AP may allow association of devices that do not have the Spectrum Management bit equal to 1 in the Capability Information field in Association Request frames and Reassociation Request frames received from a STA to account for the existence of legacy devices that do not support DFS, but do meet regulatory requirements. 1695 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.9.2 Association based on supported channels 11.9.2.1 Association based on supported channels in a non-DMG BSS A STA shall provide an AP with a list of the channels in which the STA can operate when associating or reassociating by including a Supported Channels element in its (Re)Association Request frames. An AP may use the supported channels list for associated STAs as an input into an algorithm used to select a new channel for the BSS. The specification of this algorithm is beyond the scope of this standard. An AP may reject an (re)association request from a STA if it considers the STAâ€™s supported channel list to be unacceptable. For example, a STAâ€™s supported channel list might be unacceptable if it can operate only in a limited number of channels. The criteria for accepting or rejecting (re)associations are beyond the scope of this standard. 11.9.2.2 Providing supported channels upon association in a DMG BSS An AP or PCP may advertise the regulatory domain in which it is located via a Country element in the DMG Beacon, Announce, or Information Response frames if dot11MultiDomainCapabilityActivated is true. When it (re)associates, the STA shall provide to the AP or PCP a list of channels in which the STA can operate. The STA does this by including a Supported Channels element in the Information Request or (Re)Association frames that it transmits. An AP or PCP can use the supported channels list for associated STAs as an input into an algorithm used to select a new channel for the BSS. The specification of this algorithm is beyond the scope of this standard. The AP or PCP may advertise the supported channels of associated STAs via an Information Response frame with Subject Address field set to the broadcast address and a Supported Channels element that lists the intersection of channels supported by STAs associated with the BSS, as indicated by their Supported Channels elements. 11.9.3 Quieting channels for testing When the AP Quiet Mode field of a Quiet Channel element has the value 1, the Quiet Channel element is called a mode set Quiet Channel element. An AP may schedule quiet intervals by transmitting one or more mode set Quiet Channel elements or one or more Quiet elements in Beacon frames and Probe Response frames. A mesh STA may schedule quiet intervals by transmitting one or more Quiet elements in Beacon frames and Probe Response frames. A non-VHT AP shall not transmit a Quiet Channel element. An AP shall not transmit a Quiet Channel element with the AP Quiet Mode field value equal to 0 in frames that do not include at least one Quiet element. An AP shall not transmit more than one Quiet Channel element with the AP Quiet Mode field equal to 0. An AP shall not transmit a Quiet Channel element if the BSS bandwidth is neither 160 MHz nor 80+80 MHz. An AP may stop scheduling quiet intervals, or may transmit Quiet elements with changes in the Quiet Period, Quiet Duration and Quiet Offset fields, or may transmit mode set Quiet Channel elements. A mesh STA may stop scheduling quiet intervals, or may transmit Quiet elements with changes in the Quiet Period, Quiet Duration and Quiet Offset fields. Only the most recently received Beacon frame or Probe Response frame defines all future quiet intervals; therefore, all schedules for quiet intervals based on older Beacon frames or Probe Response frames shall be discarded. 1696 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications An AP or PCP in a DMG BSS may measure one or more channels itself, or the AP or PCP may request associated non-AP and non-PCP STAs in the same BSS to measure one or more channels, either in a dedicated measurement interval or during normal operation. The AP or PCP in a DMG BSS may schedule a service period allocated to itself to quiet the associated STAs and use the self-allocated SP for measurement. An IBSS STA may schedule quiet intervals only if it is the DFS owner. In order to set a quiet interval schedule, the STA transmits one or more Quiet elements in the first Beacon frame establishing the IBSS. All IBSS STAs shall continue these quiet interval schedules by including appropriate Quiet elements in any transmitted Beacon frames or Probe Response frames. Multiple independent quiet intervals may be scheduled, so that not all quiet intervals have the same timing relationship to TBTT, by including multiple Quiet elements or, in an infrastructure BSS, mode set Quiet Channel elements in Beacon frames or Probe Response frames. Control of the channel is lost at the start of a quiet interval, and the following quieting rules apply: â€” The NAV is set by all of the non-VHT STAs in the BSS for the length of the quiet interval established by a Quiet element. â€” The NAV is set by all of the VHT STAs in the BSS for the duration of the quiet interval established by a Quiet element if a Quiet Channel element was not sent or received with the Quiet element. â€” A VHT STA in the BSS shall not transmit PPDUs that occupy the secondary 80 MHz channel or, in an infrastructure BSS, transmit PPDUs to the AP during the quiet interval established by a Quiet element if a Quiet Channel element with the AP Quiet Mode field equal to 0 was sent or received with the Quiet element. â€” A VHT STA in an infrastructure BSS shall not transmit PPDUs that occupy the secondary 80 MHz channel during the quiet interval established by a Quiet Channel element with the AP Quiet Mode field in the Quiet Channel element equal to 1. â€” Transmission by any non-VHT STA in the BSS of any MPDU and any associated acknowledgment within either the primary channel or the secondary channel (if present) shall complete before the start of the quiet interval. â€” Transmission by any VHT STA in the BSS of any MPDU and any associated acknowledgment of the BSS shall complete before the start of the quiet interval established by a Quiet element if a Quiet Channel element was not sent or received with the Quiet element. â€” Transmission by any VHT STA in the BSS of any PPDUs that occupy the secondary 80 MHz channel or, in an infrastructure BSS, are directed to the AP, and any associated acknowledgment of the BSS, shall complete before the start of the quiet interval established by a Quiet element if a Quiet Channel element with the AP Quiet Mode field equal to 0 was sent or received with the Quiet element. â€” Transmission by any VHT STA in the infrastructure BSS of any PPDUs that occupy the secondary 80 MHz channel and any associated acknowledgment of the BSS shall complete before the start of the quiet interval established by a Quiet Channel element with the AP Quiet Mode field in the Quiet Channel element equal to 1. Before starting transmission of an MPDU, a STA shall check if there is enough time for the exchange to complete within the time allowed by the quieting rules. If there is not enough time, the STA shall defer the transmission by selecting a random backoff time, using the present CW (without advancing to the next value in the series). The short retry counter and long retry counter for the MSDU or A-MSDU are not affected. 11.9.4 Testing channels for radar A STA does not transmit in a channel unless the channel has been tested for the presence of radar transmissions according to regulatory requirements. 1697 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.9.5 Discontinuing operations after detecting radar If a STA is operating in a channel and detects radar operating in the channel or accepts that another STA has detected radar operating in the channel, then the STA discontinues transmissions according to regulatory requirements. 11.9.6 Detecting radar The methods that satisfy regulatory requirements to detect radar transmissions are beyond the scope of this standard. 11.9.7 Requesting and reporting of measurements The response to a Basic request is a Basic report. A STA in an infrastructure BSS or PBSS shall generate a Basic report in response to a Basic request if the request is received from the AP or PCP with which it is associated, except as specified in this subclause. A STA may measure one or more channels itself or a STA may request other STAs in the same BSS to measure one or more channels on its behalf. These measurements may occur either during a quiet interval or during normal operation. In order to request other STAs to measure one or more channels, a STA shall use a Measurement Request frame containing one or more Measurement Request elements. The measurement request may be sent to an individual or group destination address. Addressing requests to multiple STAs should be used with care to avoid a reply storm. The measurement requests effectively allowed by these rules are shown in Table 11-7. Table 11-7â€”Allowed measurement requests Source of Destination of Type of measurement request Service set request request allowed BSS AP STA Individual or group STA AP Individual only STA STA None IBSS, MBSS STA STA Individual or group PBSS PCP Non-PCP STA Individual or group Non-PCP STA PCP Individual Non-PCP STA Non-PCP STA None A STA that successfully requests another STA to perform a measurement on another channel should not transmit MSDUs, A-MSDUs, or MMPDUs to that STA during the interval defined for the measurement plus any required channel switch intervals. In determining this period, a STA shall assume that any required channel switches take dot11ChannelSwitchTime per switch. 1698 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A STA that receives an individually addressed Measurement Request frame from a STA in its BSS shall parse the frameâ€™s Measurement Request elements in order, with measurements starting at the times specified by the Measurement Request elements. Any result of a measurement request shall be returned without undue delay to the requesting STA in Measurement Report elements using one or more Measurement Report frames. The result may be the completed measurement or an indication that the STA is unable to complete the measurement request. A STA shall report it is too late to undertake a measurement request if it receives the request after the specified starting time for the measurement. A STA shall report it is refusing a measurement request if all of the following conditions exist: â€” The STA is capable of undertaking a measurement request. â€” The STA does not want to undertake the measurement request at this time. â€” The measurement request is not mandatory. NOTEâ€”Measurements are specified as mandatory or optional in 9.4.2.21). A STA shall report it is incapable of performing a measurement request if any of the following conditions exists: â€” The STA is incapable of undertaking an optional measurement request. â€” The STA does not support the channel specified in a mandatory measurement request. â€” The STA does not support any requested parallel measurements in the same or different channels. A Measurement Report frame shall contain the same value in its Dialog Token field as the value of the Dialog Token field in the corresponding Measurement Request frame, and each Measurement Report element shall contain the same value in its Measurement Token field as the value of the Measurement Token field in the corresponding Measurement Request element. A STA may autonomously report measurements to another STA in its BSS by transmitting a Measurement Report frame that includes a Dialog Token field set to 0 and one or more Measurement Report elements. An IBSS STA may also autonomously report measurements to other STAs in the IBSS using the Channel Map field in the IBSS DFS element in a Beacon frame or Probe Response frame. A STA may enable or disable measurement requests or autonomous measurement reports from another STA by transmitting Measurement Request elements with the Enable bit set to 1 and the Request bit and Report bit set to 0 or 1, as appropriate. These elements do not require a corresponding Measurement Report element in a Measurement Report frame. All measurement requests and reports shall be enabled by default. An AP or PCP may ignore a request to disable a mandatory measurement request. All other such requests shall be honored. The measurement request and report procedures are defined in 11.11. 11.9.8 Selecting and advertising a new channel 11.9.8.1 General A channel switch is an attempt to move a BSS to a new operating channel. It is an objective that disruption to the BSS be minimized in this process, although it should be recognized that a channel switch might not successfully move all STAs. Two procedures are defined for switching channels: the channel switching procedure, which is defined in 11.9.8 and 11.9.9, and the extended channel switching procedure, which is defined in 11.10. 1699 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications It should also be stressed that both the channel switching procedure and the extended channel switching procedure are distinct from the regulatory requirement to cease transmission on a particular channel in the presence of radar. 11.9.8.2 Selecting and advertising a new channel in a non-DMG infrastructure BSS This subclause describes operation in an infrastructure BSS that is a non-DMG BSS. For a DMG infrastructure BSS, see 11.9.8.6. The decision to switch to a new operating channel in an infrastructure BSS shall be made only by the AP. An AP may make use of the information in Supported Channel elements and the results of measurements undertaken by the AP and other STAs in the BSS to assist the selection of the new channel. The algorithm to choose a new channel is beyond the scope of this standard. The AP shall attempt to select a new channel that is supported by all associated STAs. An AP shall inform associated STAs that the AP is moving to a new channel and shall maintain the association by advertising the switch using Channel Switch Announcement elements in Beacon frames, Probe Response frames, and Channel Switch Announcement frames until the intended channel switch time. The AP may force STAs in the BSS to stop transmissions until the channel switch takes place by setting the Channel Switch Mode field in the Channel Switch Announcement element to 1. The channel switch should be scheduled so that all STAs in the BSS, including STAs in power save mode, have the opportunity to receive at least one Channel Switch Announcement element before the switch. The AP may send the Channel Switch Announcement frame in a BSS without performing a backoff, after determining the WM is idle for one PIFS (see 10.3.2.3). If a Channel Switch Announcement element in a Beacon or Probe Response frame is used to announce a switch to a 20 MHz BSS bandwidth, then a Wide Bandwidth Channel Switch subelement in a Channel Switch Wrapper element shall not be present in the same frame. If a Channel Switch Announcement element in a Beacon or Probe Response frame is used to announce a switch to a 40 MHz BSS bandwidth, then a Wide Bandwidth Channel Switch subelement in a Channel Switch Wrapper element shall also be present in the same frame if the STA sending the frame is extended spectrum management capable. A Channel Switch Wrapper element shall not be included in Beacons and Probe Response frames if the element contains zero subelements. A STA that receives a Channel Switch Announcement element may choose not to perform the specified switch, but to take alternative action. For example, it may choose to move to a different BSS. A non-AP STA in an infrastructure BSS shall not transmit the Channel Switch Announcement element. 11.9.8.3 Selecting and advertising a new channel in an IBSS DFS in an IBSS is complicated by the following: â€” There is no central AP function for collating measurements or coordinating a channel switch. If STAs make independent decisions to switch channel in the presence of radar, there is a danger that all STAs announce switches to different channels if several of them detect the radar. â€” There is no association protocol that can be used to â€” Exchange supported channel information â€” Determine membership of the IBSS at a given instant for requesting measurements. 1700 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” Beaconing is a shared process; therefore, there is no guarantee that a STA that has something to send (e.g., a channel switch message) will be the next STA to transmit a Beacon frame. â€” A 20/40 MHz IBSS cannot be changed to a 20 MHz IBSS, and a 20 MHz IBSS cannot be changed to a 20/40 MHz IBSS. The DFS owner service, IBSS DFS element, and Channel Switch Announcement frame address these complications: â€” The DFS owner service provides a central point of coordination for a channel switch. It attempts to minimize the probability that multiple STAs concurrently decide to switch to different channels. The DFS Owner field and DFS Recovery Interval field in the IBSS DFS element support the DFS owner service. â€” Each STA shall include a Channel Map field in the IBSS DFS elements that it transmits. The channel map communicates the STA-supported channel set and basic measurement reports for that STA. â€” Each STA shall have the ability to send a Channel Switch Announcement element in a Management frame other than a Beacon frame or Probe Response frame. The potential for hidden nodes within an IBSS means that an IBSS channel switching procedure might not move all STAs. In some regulatory domains, each STA in an IBSS is required by regulation to detect radar and cease transmission, after a required interval, on any channel on which the presence of radar is detected. A STA at which an IBSS is started shall be a DFS owner in that IBSS. That STA shall include its MAC address in the DFS Owner field of the IBSS DFS element and DFS Recovery Interval field from the MLME.START.request primitive parameter. The purpose of the DFS owner is to coordinate a channel switch. All STAs in an IBSS shall have the ability to become DFS owner. Each IBSS STA shall adopt the DFS Owner field and the DFS Recovery Interval field from any valid IBSS DFS element when the received frame contains a matching SSID and the value of the timestamp is later than the STAâ€™s TSF timer. The STA shall include the adopted values in the IBSS DFS elements it transmits. Because all IBSS STAs participate in sending Beacon frames, this process always, over a number of beacon intervals, results in a unified view of one DFS owner throughout the IBSS. In order to attempt a channel switch using the DFS owner, a STA that detects radar shall broadcast one or more Measurement Report frames indicating the presence of the radar. A DFS owner receiving a Measurement Report frame indicating the presence of radar in the current channel shall select and advertise a new operating channel (including the possibility of no change). The DFS owner may make use of information received in Channel Map fields and from measurements undertaken by other members of the IBSS to assist the selection of the new channel. The algorithm to choose a new channel is beyond the scope of this standard, but shall satisfy any regulatory requirements, including uniform spreading rules and channel testing rules. The DFS owner shall attempt to select a new channel that is supported by all members of the IBSS. Note that this process might be imperfect in that the DFS owner might have incomplete knowledge and there might not be a suitable channel. The DFS owner shall attempt to make the members of the IBSS aware of the new operating channel by broadcasting at least one Channel Switch Announcement frame. The DFS owner may transmit the Channel Switch Announcement frame in an IBSS without performing a backoff, after determining that the WM is idle for one PIFS (see 10.3.2.3). The DFS owner shall also include the Channel Switch Announcement element in all Beacon frames, Probe Response frames, or Channel Switch Announcement frames until the intended channel switch time. A STA that receives a valid Channel Switch Announcement element that is not a superseded Channel Switch Announcement element (see 11.16.3.3) shall repeat this element in all Beacon frames and Probe Response frames that it transmits. The DFS owner may attempt to silence STAs in the IBSS until the channel switch takes place using the Channel Switch Mode field in the Channel Switch 1701 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Announcement element. If possible, the channel switch should be scheduled so that all STAs in the IBSS, including STAs in power save mode, have the opportunity to receive at least one Channel Switch Announcement element before the switch. If a STA does not receive a valid Channel Switch Announcement element from the DFS owner within the DFS recovery time, then it shall enter DFS recovery mode. DFS recovery time is measured from the end of the frame that first announced radar presence, whether that frame was transmitted by the STA or received from another STA. In DFS recovery mode the STA shall assume the role of DFS owner, shall select a new operating channel, and shall advertise the new channel by transmitting a Channel Switch Announcement frame using the contention resolution algorithm defined for beacon transmission at TBTT in 11.1.3.5. The STA shall also include the Channel Switch Announcement element in all Beacon frames and Probe Response frames until the intended channel switch time. A STA that is not the DFS owner shall not initiate a channel switch. If the STA receives a valid Channel Switch Announcement element that is not a superseded Channel Switch Announcement element (see 11.16.3.3 from another member of the IBSS, the STA shall leave DFS owner recovery mode prior to the channel switch and adopt the received channel switch information. If the Channel Switch Announcement element was in a Beacon frame or Probe Response frame, the STA shall also adopt the STA identified by the DFS owner address of the IBSS DFS element as the DFS owner. If the Channel Switch Announcement element was in a Channel Switch Announcement frame, the receiving STA shall adopt the STA that transmitted the frame as the DFS owner. There are several circumstances when DFS owner recovery is needed (e.g., if the original DFS owner has left the network or if the original measurement report was not received by the initial DFS owner). Note that DFS owner recovery might temporarily give rise to more than one DFS owner in the IBSS. This risk is mitigated by the random nature of the IBSS DFS recovery mechanism. However, because all IBSS STAs participate in sending Beacon frames, over a number of beacon periods, there will be convergence from multiple DFS owners to one DFS owner. 11.9.8.4 MBSS channel switching 11.9.8.4.1 General A mesh channel switch might be triggered by the need to avoid interference to a detected radar signal, or to reassign mesh STA channels to maintain MBSS connectivity. A mesh STA may make use of the information in Supported Channel elements, Supported Operating Classes elements, and the results of measurements undertaken by the mesh STAs in the MBSS to assist the selection of the new channel. The algorithm for choosing a new channel is beyond the scope of this standard. A 20/40 MHz MBSS may be changed to a 20 MHz MBSS and a 20 MHz MBSS may be changed to a 20/40 MHz MBSS. When an MBSS switches from a 20 MHz MBSS to a 20/40 MHz MBSS or switches from a 20/40 MHz MBSS to a 20 MHz MBSS, a mesh STA might need to do path maintenance to find an optimized path. 11.9.8.4.2 Initiating MBSS channel switch A mesh STA shall not initiate a new channel switch attempt if there is an ongoing channel switch attempt by this mesh STA. A mesh STA shall inform each of the peer mesh STAs that the mesh STA is moving to a new channel while maintaining mesh peerings by including Channel Switch Announcement elements together with the Mesh Channel Switch Parameters element in all Beacon frames, Probe Response frames, and Channel Switch 1702 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Announcement frames that it transmits until the intended channel switch time. The channel switch should be scheduled so that all mesh STAs in the MBSS, including mesh STAs in power save mode, have the opportunity to receive at least one Channel Switch Announcement element before the switch. The fields in the Channel Switch Announcement element are set as follows: â€” The Channel Switch Count field shall be set to the time period until the mesh STA sending the Channel Switch Announcement element switches to the new channel. â€” The Channel Switch Mode field is reserved. â€” The New Channel Number field shall be set to the number of the channel to which the mesh STA is moving. The fields in the Mesh Channel Switch Parameters element are set as follows: â€” The Precedence Value field shall be set to a random value selected from a uniform distribution in the range 0 to 65 535. â€” The mesh STA may force mesh STAs in the MBSS to stop transmissions of frames (except frames containing Channel Switch Announcement element) until the channel switch takes place by setting the Transmit Restrict subfield of the Flags field to 1. â€” The Reason subfield in the Flags field shall be set to 1 to indicate that the content of the Reason Code field (as defined in Table 9-45) is valid. The Reason Code field shall be set to MESH- CHANNEL-SWITCH-REGULATORY-REQUIREMENTS when the channel switch is initiated to meet regulatory requirement; otherwise, the Reason Code field shall be set to MESH-CHANNEL- SWITCH-UNSPECIFIED. â€” The Initiator subfield of the Flag field shall be set to 1. â€” The Time To Live field should be set to the maximum number of hops (e.g., dot11MeshHWMPnetDiameter) for which this Channel Switch attempt is intended. 11.9.8.4.3 Processing channel switch announcement Upon receipt of a Channel Switch Announcement frame or Extended Channel Switch Announcement frame, a mesh STA shall not accept and shall not process the received Channel Switch Announcement element or Extended Channel Switch Announcement element, if any of the following is true: â€” The Mesh Channel Switch Parameters element is not present in the received frame containing the Channel Switch Announcement element or the Extended Channel Switch Announcement element. â€” The Time To Live field in the received Mesh Channel Switch Parameters element is 0. â€” A mesh channel switch is already running and the mesh STA has not yet moved into the new channel and/or operating class and the current precedence value is greater than or equal to the value of the received Precedence Value field. A mesh STA that receives a Channel Switch Announcement element may choose not to perform the specified switch, but to take alternative action. For example, it may choose to move to a different MBSS. When a mesh STA accepts a channel switch, it shall adopt the information received in the Channel Switch Announcement element and the Mesh Channel Switch Parameters element. The mesh STA shall schedule the channel switch according to this information. If the Time To Live field value in the received Mesh Channel Switch Parameters element is greater than 1, the mesh STA shall transmit a Channel Switch Announcement frame and shall include a Channel Switch Announcement element together with a Mesh Channel Switch Parameters element in the Beacon and Probe Response frames until the intended channel switch time. The Channel Switch Mode and New Channel Number fields in the transmitted Channel Switch Announcement element(s) are set to the same values as in the received Channel Switch Announcement element. The Channel Switch Count field is set to indicate the time remaining until the channel switch, as specified in 9.4.2.19. The Reason Code and Precedence Value fields in the transmitted Mesh Channel Switch Parameters element(s) are set to the same values as in the received Mesh Channel Switch Parameters 1703 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications element. The Time to Live and Flags fields are set as specified in 9.4.2.103. The Time To Live field shall be set to the received Time To Live field minus 1. The Initiator field shall be set to 0. The Transmit Restrict field shall be set to 1 when the mesh STA requires neighboring mesh STAs not to transmit (until the scheduled channel switch occurs) further frames that do not contain the Channel Switch Announcement element on the current channel. The Transmit Restrict subfield shall be set to 0 otherwise. It is possible that a channel switch is not successful in moving all of the mesh STAs in MBSS to the new operating channel. Transitioning to a new channel does not tear down mesh peerings and, as long as the mesh peers move to the new operating channel, their peerings are maintained in the new channel. After moving into a new operating channel, the mesh STA shall perform CCA until a frame is detected by which it can set its NAV, or until a period of time indicated by the NAVSyncDelay parameter from the most recent MLME-START.request primitive has transpired. 11.9.8.4.4 Channel switch across an operating class When dot11OperatingClassesImplemented is true and the mesh STA is capable of operation in more than one operating class, the mesh STA shall include the Supported Operating Classes element within its Mesh Peering Open frames. The Supported Operating Classes element announces the operating classes that the mesh STA supports. When dot11OperatingClassesImplemented is true, a mesh STA may switch from the operating channel to a channel in a different operating class. 11.9.8.5 HT-greenfield transmissions in operating classes that include a behavior limit of DFS_50_100_Behavior The requirements described in this subclause apply only when an HT STA is operating in an operating class for which the behavior limits set listed in Annex E includes the value DFS_50_100_Behavior; i.e., the operating class is subject to DFS with 50â€“100 Âµs radar pulses. A non-HT OBSS scan operation is a passive or active scan of the primary channel and of the secondary channel if the STA conducting the scan is in a 20/40 MHz BSS that the STA currently uses or intends to use. During a non-HT OBSS scan operation, the channel scan duration shall be a minimum of dot11OBSSScanPassiveTotalPerChannel TUs when scanning passively and a minimum of dot11OBSSScanActiveTotalPerChannel TUs when scanning actively. Before an HT STA starts a BSS with the OBSS Non-HT STAs Present field of the HT Operation element equal to 0, the HT STA shall perform a non-HT OBSS scan in order to search for any existing non-HT OBSSs. When an HT STA detects that there are one or more non-HT OBSSs, and if the HT STA starts a BSS on that channel, then the HT STA shall set to 1 the OBSS Non-HT STAs Present field of the HT Operation element it transmits; otherwise, the HT STA may set to 0 the OBSS Non-HT STAs Present field of the HT Operation element it transmits. NOTEâ€”Detection of a non-HT OBSS can be achieved by the reception of a Beacon or Probe Response frame that does not contain an HT Capabilities element or HT Operation element. An HT AP shall not transmit a PPDU with the FORMAT parameter of the TXVECTOR set to HT_GF if the OBSS Non-HT STAs Present field of the HT Operation element is equal to 1 in the most recently transmitted Management frame that contained that element. 1704 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications An HT non-AP STA shall not transmit a PPDU with the FORMAT parameter of the TXVECTOR set to HT_GF if the most recent frame received from its AP containing an HT Operation element has the OBSS Non-HT STAs Present field equal to 1. NOTEâ€”This requirement applies also to PPDUs transmitted on a direct link between two non-AP STAs. When moving the BSS to a new channel or set of channels and before completing a non-HT OBSS scan of the new channel or set of channels, an HT AP shall set to 1 the OBSS Non-HT STAs Present field of the HT Operation element it transmits. After the HT AP completes one non-HT OBSS scan of the new channel or set of channels and if the HT AP has detected that there are zero non-HT OBSSs, then the HT AP may set to 0 the OBSS Non-HT STAs Present field of the HT Operation element it transmits. 11.9.8.6 Selecting and advertising a new channel in a DMG BSS The decision to switch to a new operating channel in a DMG BSS shall be made only by an AP or PCP. An AP or PCP may make use of the information in received Supported Channel elements and the results of measurements undertaken by the AP or PCP and other STAs in the BSS to assist the selection of the new channel. The algorithm to choose a new channel is beyond the scope of this standard. An AP or PCP shall inform associated STAs that the AP or PCP is changing to a new channel and shall maintain the association by advertising the switch using the Extended Channel Switch Announcement element in its transmitted DMG Beacon frames, Announce frames, and Information Response frames until the intended channel switch time. The channel switch should be scheduled so that all non-AP and non-PCP STAs in the BSS, including STAs in power save mode, have the opportunity to receive at least one Extended Channel Switch Announcement element before the switch. A STA may ignore the Channel Switch Mode field and either cease transmissions or attempt new transmissions in the operating channel until the channel change occurs. A STA that receives an Extended Channel Switch Announcement element may choose not to perform the specified switch, but to take alternative action. For example, it may choose to move to a different BSS. A non-AP and non-PCP STA in an infrastructure BSS or PBSS shall not transmit the Extended Channel Switch Announcement element. 11.9.9 Channel Switch Announcement element operation If a non-DMG STA in a BSS that is not an IBSS receives a Channel Switch Mode field that has the value 1, it shall not transmit any more frames on the channel until the scheduled channel switch occurs. An IBSS STA may treat a Channel Switch Mode field equal to 1 as advisory. A Channel Switch Mode equal to 0 does not impose any requirement on the STA that receives the Channel Switch Announcement frame. 11.9.10 Future Channel Guidance operation This subclause defines a mechanism to create, communicate and act on the Future Channel Guidance element. When dot11FutureChannelGuidanceActivated is true, a STA shall follow these procedures for future channel guidance operation. A STA transmitting Beacon frames transmits the Future Channel Guidance element in (Re)Association Response frames and optionally in Beacon frames. In some bands, the channel clearing time will be much less than one second for all STAs, and future channel guidance permits all STAs know what channels will be used if the current channels are cleared. 1705 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications In some bands, Beacon frames are an enabling signal, and some STAs are not allowed to transmit in the band before receiving an enabling signal. When Beacon frame reception stops, some STAs are no longer enabled to transmit in the band. In these bands, when Beacon frame reception stops, it is an implicit message to switch from current channels to other channels according to prior future channel guidance. Future channel guidance indicates future channels that the Beaconing STA switches to while maintaining associations and mesh peering relationships (see 11.9.8.2, 11.9.8.3, 11.9.8.4.2, 11.9.8.6, 11.10.3.2, 11.10.3.3 and 11.10.3.4). A STA receiving the Future Channel Guidance element shall retain the information until it receives a different Future Channel Guidance element from the same STA, it receives a Channel Switch Announcement element or a Channel Switch Announcement frame from the same STA, or it chooses alternative action. For example, it may choose to move to a different BSS. 11.10 Extended channel switching (ECS) 11.10.1 General This subclause describes ECS procedures that change the BSS operating channel frequency and bandwidth. When the STAâ€™s dot11ExtendedChannelSwitchActivated value is true, the enabling STAs (see 11.12), APs, DFS owners, and mesh STAs may construct and transmit frames that contain Extended Channel Switch Announcement elements. A STA shall use the ECS procedures defined in this subclause if dot11ExtendedChannelSwitchActivated is true. To indicate that it can perform ECS procedures, a STA shall set dot11ExtendedChannelSwitchActivated, dot11MultiDomainCapabilityActivated and dot11OperatingClassesRequired to true and shall set to 1 the value of the Extended Channel Switching field in the Extended Capabilities elements it transmits. When dot11ExtendedChannelSwitchActivated is false, the STA shall not use ECS procedures. When an AP is switching to a different channel and one or more of its associated STAs do not support extended channel switching capability, then both the Extended Channel Switch Announcement and the Channel Switch Announcement elements and frames may be used. If dot11ExtendedChannelSwitchActivated and dot11LCIDSERequired are true, frames containing Channel Switch Announcement elements shall not be transmitted. An enabling STA may send frames containing Extended Channel Switch Announcement elements to dependent STAs (see 11.12.5). If dot11DSERequired is true, a STA shall perform ECS procedures to switch at the time indicated by the channel switch count, or the STA shall change its enablement state for the enabling STA to unenabled. 11.10.2 Advertising supported operating classes When dot11ExtendedChannelSwitchActivated is true, the Current Operating Class field in the Supported Operating Classes element shall indicate the operating class in use for transmission and reception. The Operating Classes field shall list all operating classes with which the STA is capable of operating for the country that is specified in the Country element (9.4.2.9). 11.10.3 Selecting and advertising a new channel and/or operating class 11.10.3.1 General An attempt may be made to move a BSS to a new operating channel and/or new operating class using extended channel switching. An objective during this process is to minimize disruption to the BSS. It is 1706 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications possible, however, that an extended channel switch is not successful in moving all STAs to the new channel and/or operating class. 11.10.3.2 Selecting and advertising a new channel in an infrastructure BSS When an AP with dot11DSERequired true receives frames containing Extended Channel Switch Announcement elements from the enabling STA, it shall advertise an extended channel switch with the same channel switch mode, new operating class, new channel number, and channel switch count as received in the Extended Channel Switch Announcement elements. The decision to switch to a new operating channel and/or operating class in an infrastructure BSS is made by the AP when dot11DSERequired is false. An AP may make use of the information in the Supported Channels element, Supported Operating Classes element, and the results of measurements undertaken by the AP and other STAs in the BSS to assist the selection of the new channel and/or operating class. A method to make the decision and to select a new channel is defined in 11.9.8.2. When an AP is switching to a different operating class and dot11ExtendedChannelSwitchActivated is true, then the AP shall use the Extended Channel Switch Announcement element and frame. In addition, the AP may also send Channel Switch Announcement elements and frames when the requirements signified by the new operating class are met by all associated STAs. When an AP is switching to a new channel within the same operating class and dot11ExtendedChannelSwitchActivated is true, then the AP shall send the Extended Channel Switch Announcement element and frame, or both the Extended Channel Switch Announcement and the Channel Switch Announcement elements and frames. If dot11ExtendedChannelSwitchActivated is false, the AP shall send the Channel Switch Announcement element and frame, or both the Extended Channel Switch Announcement and the Channel Switch Announcement elements and frames. When dot11ExtendedChannelSwitchActivated is true, an AP shall inform associated STAs that the AP is moving to a new channel and/or operating class and maintain the association by advertising the switch using Extended Channel Switch Announcement elements in any transmitted Beacon frames, Probe Response frames, and Extended Channel Switch Announcement frames until the intended channel switch time. The AP may request STAs in the BSS to stop transmissions until the channel switch takes place by setting the Extended Channel Switch Mode field to 1 in the Extended Channel Switch Announcement element. If possible, the channel switch should be scheduled so that all STAs in the BSS, including STAs in power save mode, have the opportunity to receive at least one Extended Channel Switch Announcement element before the switch. The AP may send the Extended Channel Switch Announcement frame without performing a backoff, after determining the WM is idle for one PIFS (see 10.3.2.3). When both the Extended Channel Switch Announcement and the Channel Switch Announcement elements are transmitted in Public Action frames, they shall be sent in separate frames. If an Extended Channel Switch Announcement element in a Beacon or Probe Response frame is used to announce a switch to a 40 MHz BSS bandwidth, then a Wide Bandwidth Channel Switch subelement in a Channel Switch Wrapper element may be present in the same frame if the STA sending the frame is extended spectrum management capable. When a STA with dot11DSERequired equal to false receives an Extended Channel Switch Announcement element, it may choose not to perform the specified switch, but to take alternative action. For example, it might choose to move to a different BSS. A non-AP STA in an infrastructure BSS shall not transmit the Extended Channel Switch Announcement element. 1707 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.10.3.3 Selecting and advertising a new channel in an IBSS When a DFS owner with dot11DSERequired true receives frames containing Extended Channel Switch Announcement elements from the enabling STA, it shall advertise an extended channel switch with the same channel switch mode, new operating class, new channel number, and channel switch count as received in the Extended Channel Switch Announcement elements. The DFS owner that advertises a channel switch shall follow the rules defined in 11.9.8.3 with the following extensions: a) If a DFS owner is switching to a new channel or to the same channel in a different operating class and dot11ExtendedChannelSwitchActivated is true, then the DFS owner shall use the Extended Channel Switch Announcement element and frame. Alternatively, both the Extended Channel Switch Announcement and the Channel Switch Announcement elements and frames may be used when Channel Switch Announcement elements and frames are permitted for operation in the band signified by the new operating class. b) If a DFS owner is switching to a new channel within the same operating class and dot11ExtendedChannelSwitchActivated is true, then the DFS owner shall send the Extended Channel Switch Announcement element and frame, or both the Extended Channel Switch Announcement and the Channel Switch Announcement elements and frames. If dot11ExtendedChannelSwitchActivated is false, the DFS owner shall send the Channel Switch Announcement element and frame, or both the Extended Channel Switch Announcement and the Channel Switch Announcement elements and frames. c) If both the Extended Channel Switch Announcement and the Channel Switch Announcement elements are transmitted in Public Action frames, they shall be sent in separate frames. The DFS owner may transmit the Extended Channel Switch Announcement frame in an IBSS without performing a backoff, after determining that the WM is idle for one PIFS (see 10.3.2.3). 11.10.3.4 Selecting and advertising a new channel in an MBSS A mesh STA may make use of the information in the Supported Channels element, Supported Operating Classes element, and the results of measurements undertaken by this mesh STA and other mesh STAs in the MBSS to assist the selection of the new channel and/or operating class. If dot11ExtendedChannelSwitchActivated is true, the mesh STA that advertises a channel switch shall follow the rules defined in 11.9.8.4 with the following extensions: a) If a mesh STA is switching to a different operating class, then the mesh STA shall use the Extended Channel Switch Announcement element and frame. Alternatively, both the Extended Channel Switch Announcement and the Channel Switch Announcement elements and frames may be used when Channel Switch Announcement elements and frames are permitted for operation in the band signified by the new operating class. b) If a mesh STA is switching to a new channel within the same operating class, then the mesh STA shall send the Channel Switch Announcement element and frame, or both the Extended Channel Switch Announcement and the Channel Switch Announcement elements and frames. c) If both the Extended Channel Switch Announcement and the Channel Switch Announcement elements are transmitted in Public Action frames, they shall be sent in separate frames. d) The Extended Channel Switch Announcement element shall be included in the Beacon and Probe Response frames until the intended channel switch time. 1708 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.11 Radio measurement procedures 11.11.1 General This subclause describes the radio measurements and the procedures for requesting and reporting radio measurements between STAs. When a STA implements support for one or more of the procedures described in this subclause, it shall set dot11RadioMeasurementActivated to true. When dot11RadioMeasurementActivated is true, dot11MultiDomainCapabilityImplemented, dot11MultiDomainCapabilityActivated, dot11OperatingClassesImplemented, and dot11OperatingClassesRequired shall be true. NOTEâ€”A key issue in radio measurement is network operation and management, considering each STAâ€™s service load, power state, and operating conditions. Timely measurement reports might be more important than percentage of wireless capacity or STA capacity used by radio measurements. The measurement requester might consider traffic load and application requirements, regulatory requirements, and specific measurement states from every STA in support of wireless network management. There are no typical scenarios that describe IEEE 802.11 operation in all bands. Off- channel measurements are desirable to gather timely information about the channel to which to switch BSS operation, and the noisier the operating environment, the more urgent the need for radio measurements off the serving channel. In any case, the measuring STA might refuse any measurement request. 11.11.2 Measurement on operating and nonoperating channels Measurements on nonoperating channels might need the measuring STA to interrupt its data services on the operating channel, switch channels, and make measurements. Measurements on the operating channel might not require the STA to interrupt its data services. All stations are responsible for maintaining data services and an association or membership with the BSS on the operating channel while performing measurements on nonoperating channels. A STA shall determine the time between successive nonoperating channel measurements. This time may be a fixed length, or it may be determined by the STA using application-specific (or other) knowledge. 11.11.3 Measurement start time A Radio Measurement Request frame may contain a single Measurement Request element or a sequence of Measurement Request elements. A STA that accepts the first or only measurement request within a Radio Measurement Request frame shall start the measurement as soon as practical after receiving the request. Subsequent measurement requests in the Radio Measurement Request frame that are accepted shall start as soon as practical after processing the previous request in the frame. Such measurement start times shall be subject to any specified randomization interval. The radio measurement category permits a randomization interval to be specified for measurement start times. The intent of this is to avoid traffic storms that could arise with synchronized group addressed measurements. Prior to making each measurement in the requested sequence, the STA shall calculate a random delay distributed uniformly in the range 0 to the randomization interval specified in the measurement request. The STA shall not start the measurement until this delay has expired. Randomization interval is specified in units of TUs. A randomization interval field value of 0 in a measurement request indicates that no random delay is to be used. NOTEâ€”It is important that designers recognize the need for statistical independence among the pseudorandom number streams among STAs. A number of repetitions may be specified in the Radio Measurement Request frame. In this case, the measurements in the frame are repeated as detailed further in 11.11.7. Each time a measurement is repeated, the STA shall recalculate the random delay as described above. 1709 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications When a Measurement Start Time field is present in a measurement report, the measuring STA shall report the value of its TSF timer at the time the measurement started to an accuracy of Â±1 TU. 11.11.4 Measurement Duration The values of Request Measurement Duration and Duration Mandatory in the received measurement request and the dot11RMMaxMeasurementDuration setting in the receiving STA determine if the receiving STA accepts the measurement request and for how long the measurement is performed. dot11RMMaxMeasurementDuration indicates a measurement duration using the following formula: Maximum Measurement Duration in TUs = 2(dot11RMMaxMeasurementDuration â€“ 4) BeaconInterval Table 11-8 describes how a STA responds to a measurement request depending on the values of dot11RMMaxMeasurementDuration, Measurement Duration, and Duration Mandatory. Table 11-8â€”Measurement Duration Measurement dot11RMMaxMeasure Duration Duration in the Notes mentDuration Mandatory Measurement Request 0 Any value 1 The STA shall perform measurements for the requested measurement duration. 0 Any value 0 The STA may perform measurements for a duration shorter than the requested measurement duration Nonzero Any value 0 The STA shall perform measurements for a maximum duration that is equal to the minimum of the requested measurement duration and the dot11RMMaxMeasurementDuration. Nonzero Requested measurement 1 The STA shall reject the measurement duration > Maximum request with the Measurement Report Measurement Duration in Mode set to â€œrefused.â€ TUs Nonzero Requested measurement 1 The STA shall perform the measurement duration Maximum for the requested duration. Measurement Duration in TUs Measurement duration on nonoperating channels is defined by dot11RMNonOperatingChannelMaxMeasurementDuration. If this attribute is 0, the STA does not support RM measurements on nonoperating channels; on receipt of a Measurement Request frame requesting a measurement on nonoperating channels, the STA shall reject the measurement request by returning a Measurement Report element in which the Incapable bit in the Measurement Report Mode field is 1. The interpretation rules defined in Table 11-8 also apply for all nonzero values of dot11RMNonOperatingChannelMaxMeasurementDuration for measurements on nonoperating channels. NOTEâ€”Measurement duration on nonoperating channels is subject to further limitations due to maximum off-operating channel time. If the Duration Mandatory bit is 1 in the Measurement Request mode field of a measurement request, the requested STA, if it accepts the request, shall perform the measurement over the Measurement Duration 1710 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications specified in the request. If the STA is unable to commit to making the measurement over the requested duration, it shall refuse the request by sending a measurement report in which the refused bit in the Measurement Report Mode field is set to 1. The measurement duration in the measurement report is equal to the requested measurement duration. If the Duration Mandatory bit is 0 in the Measurement Request mode field of a measurement request, the requested STA, if it accepts the request, shall attempt a measurement using the requested duration as a maximum measurement duration, and may report results with an actual measurement duration less than the requested duration. The duration over which the measurement was made will be included in the measurement duration field of the measurement report. Each separate measurement within the Radio Measurement Request frame shall be performed over a continuous measurement duration time period. In Measurement Request frames the requested Measurement Duration value shall not be set to 0 except when the request frame is a Beacon request in which the Measurement Mode field value is Beacon Table, or is a STA Statistics request, or is a request for triggered autonomous measurements. 11.11.5 Station responsibility for conducting measurements A radio measurement-capable STA shall decode and interpret each Radio Measurement Request frame that it receives and shall assess the contents against its capabilities and the impact on its own performance. A measurement request may be refused by the receiving STA by sending a Radio Measurement Report frame in which the refused bit in the Measurement Report Mode field is set to 1. The reasons for refusing a measurement request are outside the scope of this standard but may include reduced quality of service, unacceptable power consumption, measurement scheduling conflicts, or other significant factors. In assessing the performance impact of each Measurement Request element, a STA may use application- specific knowledge or other knowledge to limit the time it spends away from the operating channel. In doing so, the STA may either: â€” Reject any Measurement Request element in which the Duration Mandatory bit is 1 and that has a mandatory measurement duration exceeding the maximum allowed off-operating channel time, or â€” Measure for a reduced duration if the Duration Mandatory bit is 0. A STA shall cancel all in-process radio measurements and shall delete all pending, unprocessed radio measurement requests upon receipt of a Disassociation frame or upon (re)association with a BSSID different from its most recent association. 11.11.6 Requesting and reporting of measurements A STA may perform radio measurements on one or more channels itself or a STA may request STAs in the same BSS to perform measurements on its behalf. A STA advertises its radio measurement capability using the RM Enabled Capabilities element. If a STA advertises that it is capable of a measurement, it shall not reject a request for the corresponding measurement by sending a Radio Measurement Report frame in which the Incapable bit in the Measurement Report Mode field is set to 1, except as specified in 11.11.9.7. Measurement requests for radio measurements that the STA has advertised it is not capable of shall be rejected, and the corresponding report shall have the Incapable bit in the Measurement Report Mode field set to 1. When requesting other STAs to measure one or more channels, a STA shall use a Radio Measurement Request frame containing one or more Measurement Request elements. The measurement request may be sent to an individual or group destination address. The permitted measurement requests are shown in Table 11-9. 1711 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 11-9â€”Allowed measurement requests Destination of Receiver address of Measurement Service set Source of request request Request frame Infrastructure BSS AP Non-AP STA Individual or group Non-AP STA AP Individual only Non-AP STA Non-AP STA Individual only for Direct Link within a BSS served by QoS AP, otherwise not allowed IBSS Non-AP STA Non-AP STA Individual or group PBSS PCP STA Individual or group STA PCP Individual only STA STA None The source and destination of a measurement request shall both be a member of the same infrastructure BSS, a member of the same PBSS, or a member of the same IBSS. Measurement requests with an individual Receiver Address shall be sent only to STAs that have indicated radio measurement capability. The set of requested measurements received in the most recently received Radio Measurement Request frame of highest precedence is active. The precedence order for measurement requests shall be as follows (highest precedence first): â€” Measurement requests received in individually addressed Radio Measurement Request frames â€” Measurement requests received in Multicast-group addressed Radio Measurement Request frames â€” Measurement requests received in Broadcast addressed Radio Measurement Request frames The Measurement Request elements shall be processed in sequence by default, with certain Measurement Request elements processed in parallel according to the parallel bit field setting: see 9.4.2.21. A STA shall accept a measurement request with the parallel bit field enabled if dot11RMParallelMeasurementsActivated is true; otherwise, the STA shall reject the Measurement Request by returning a Measurement Report with the Incapable bit in the Measurement Report Mode field set to 1. If dot11RMParallelMeasurementsActivated is true and if measurement resources are available, the STA processes each element by setting up and making the specified measurement. If measurement resources are not available to perform the requested parallel measurements, the STA shall return a Measurement Report with the Refused bit in the Measurement Report Mode field set to 1. The Measurement Request elements within a Radio Measurement Request frame may specify multiple measurement types across multiple channels. A STA may receive another Radio Measurement Request frame while the measurements requested in a previous Radio Measurement Request frame are pending or in progress. If this request is accepted, the set of measurement requests in the new frame supersedes any previous requests received in a Radio Measurement Request frame of the same or lower precedence. The measuring STA shall report the results of any completed measurements and terminate any pending or in-progress measurements. Results from a terminated in-progress measurement may be valid and reported if Duration Mandatory was not equal to 1 in the corresponding request. It is permissible for the superseding Radio Measurement Request frame to contain no new measurement requests. This has the effect of canceling all pending or in-progress measurements of the same or lower priority. If a station receives a Radio Measurement Request frame with 1712 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications lower precedence than the currently active Radio Measurement Request frame, the station shall discard the measurement requests in the new Radio Measurement Request frame. Measurement Request elements that have the Enable bit equal to 1 shall be processed in all received Radio Measurement Request frames regardless of these precedence rules. If a STA receives a Measurement Request frame with Measurement Type field equal to 0 (Basic request), this shall take priority over any pending or in-progress radio measurements. A STA that issues a radio measurement request to another STA to perform a measurement on the operating channel may continue to transmit MPDUs and MMPDUs to that STA while the measurement is being processed. A STA that issues a radio measurement request to another STA to perform a measurement on a nonoperating channel is not required to take any special action to suspend traffic to that STA. All stations shall maintain state information such that data services and association or membership with the BSS continue when returning from a nonoperating channel measurement. A single Measurement Request element may generate a large quantity of measurement report data. The measurement report data may be reported using multiple measurement report elements in multiple measurement report frames. The result of each measurement requested in a Measurement Request element shall be reported in one or more Measurement Report elements of type corresponding to the request. Each Measurement Report element returned shall have the same Measurement Token as in the corresponding Measurement Request element, and the same Actual Measurement Start Time field, if present, as in the first returned Measurement Report element. The results of each measurement should be returned without undue delay to the requesting STA. Measurement Report elements shall be returned to the requesting STA in one or more Radio Measurement Report frames. Each Radio Measurement Report frame shall contain the same Dialog Token field value as the corresponding Radio Measurement Request frame, and the same Actual Measurement Start Time field, if present, as in the first returned Measurement Report element. When a STA is permanently unable to make a requested measurement, the STA shall respond to such a measurement request received within an individually addressed Radio Measurement Request frame with a measurement report indicating that it is incapable of completing the measurement request. A STA shall not respond to requests received in group addressed frames in this manner. Examples of when a response of incapable is appropriate are: â€” The requested measurement type is not supported. â€” The measuring STA cannot support requested parallel measurements due to the requests relating to different channels. A STA that receives a response with an incapable indication shall not make the same request to the responding STA during the lifetime of the current association, or IBSS membership. This is logically the same as the responding STA using the Enable and Request bits in a measurement request to indicate that it does not accept measurement requests of a certain type. A STA that has indicated an incapable response to a requesting STA may discard further requests of the same type from that STA without responding. A STA may refuse to make any requested measurement. A STA refusing a measurement request within an individually addressed Radio Measurement Request frame shall respond with a measurement report indicating that it is refusing the measurement request. A STA shall not respond to measurement requests received in Radio Measurement Request frames in this manner. By default, a STA may send a radio measurement request of any defined measurement type. A STA that receives a Measurement Request element with the Enable bit equal to 1 and the Request bit equal to 0 shall 1713 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications not issue a measurement request of the type specified in the request to the STA from which the element was received. Since measurements on nonoperating channels interrupt normal operation on the operating channel, the requesting STA should consider each STAâ€™s service load, power state, and operating conditions. Since measurements on the operating channel execute concurrently with normal traffic processing, operating channel measurements can be requested more frequently and for longer durations. 11.11.7 Repeated Measurement Request frames Radio Measurement Request frames contain a field specifying the number of repetitions for the Radio Measurement Request frame. If the Radio Measurement Request frame includes a nonzero value for the Number of Repetitions and dot11RMRepeatedMeasurementsActivated is false, the STA shall reject the measurement request by returning a Measurement Report with the Incapable bit in the Measurement Report Mode field set to 1. If the Radio Measurement Request frame includes a nonzero value for the Number of Repetitions and dot11RMRepeatedMeasurementsActivated is true, the STA shall iterate (repeat) the processing of all of the Measurement Request elements in the frame as specified by the value in the Number of Repetitions field. A value of 0 in the Number of Repetitions field indicates Measurement Request elements are executed once without repetition; a value of 1 in the Number of Repetitions field indicates Measurement Request elements are executed twice, one initial execution and one repetition; and so on. When completing the initial processing of the last Measurement Request element in the frame, the STA shall begin processing of the first Measurement Request element in the frame to repeat the frame until the number of iterations reaches the value in the Number of Repetitions field. Measurement Request elements with the Enable bit equal to 1 shall be processed once regardless of the value in the Number of Repetitions in the measurement request. Each repeated measurement result shall include the same Measurement Token value as in the Measurement Token field of the corresponding Measurement request element and the same value of the Dialog Token field as in the Dialog Token field of the corresponding Radio Measurement Request frame. Measurement results shall be reported for each repetition of a repeated measurement request subject to any conditional reporting requirement. STAs responding with incapable or refused indications to measurement requests within a Radio Measurement Request frame with a nonzero value for Number of Repetitions shall respond only once. 11.11.8 Triggered autonomous reporting Autonomous reporting is defined for spectrum management measurements supporting DFS; see 11.9.7. It allows a STA to report the results of measurements to a peer STA for which there was no explicit measurement request. In this case, the transmission of autonomous reports shall be entirely the decision of the STA at which such reporting has been enabled. An example of this use would be to report a change in conditions at the STA observed as a result of background measurement, e.g., the presence of a radar signal. In radio measurement, triggered autonomous reporting shall be subject to trigger conditions set by the enabling STA that determine when measurement reports are issued. Triggered autonomous reporting provides a method for conditional reporting during continuous background measurements. An example of the use of triggered autonomous measurement is for reporting problem conditions in continuous, noninvasive statistical monitoring. Triggered autonomous reporting is defined for the Transmit Stream/Category Measurement measurement type; see 11.11.9.8. When dot11MulticastDiagnosticsActivated is true, triggered autonomous reporting is 1714 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications used for Multicast Diagnostics reports (11.11.19). When dot11TriggerSTAStatisticsActivated is true, triggered autonomous reporting is used for STA Statistics reports (11.11.9.5). If dot11RMTriggeredTransmitStreamCategoryMeasurementActivated is true, a STA indicates that it wishes to accept triggered autonomous reports by sending a Measurement Request element with the Enable and Report bits set to 1; see 9.4.2.21. The type of measurement is indicated in the Measurement Type field. Trigger conditions that determine when measurement reports are to be generated shall be specified in the Measurement Request field. A Measurement Request element that is being used to control triggered autonomous reporting shall be sent within a Radio Measurement Request frame. Measurement Request elements being used to request measurements may also appear in the same Radio Measurement Request frame. The Radio Measurement Request frame may be sent to a group receiver address to enable triggered autonomous reports at more than one STA. A STA shall not send autonomous reports for radio measurement types having triggered autonomous reporting enabled without a requested trigger condition having been met. If a request to enable triggered autonomous reporting is sent to an individual address and the recipient STA does not support measurements of the type indicated or the recipient STA has dot11RMTriggeredTransmitStreamCategoryMeasurementActivated equal to false, a Measurement Report element shall be returned to the requesting STA with the Incapable bit set to 1. A STA may also refuse to enable triggered autonomous reporting. In this case a Measurement Report element shall be returned to the requesting STA with the refused bit set to 1. Such responses shall not be issued if the request to enable triggered autonomous reporting was sent to a group address. A STA receiving a request to enable triggered autonomous reporting from another STA may send reports of the appropriate type, addressed to the individual address of the STA that sent the enable request. Autonomous reports shall be sent only to the individual addresses of STAs from which a valid enable request has been received and shall be issued only when a requested trigger condition has been met. The Measurement Token in each Measurement Report element and the value of the Dialog Token field in the Measurement Report frame shall both be set to 0 in a triggered autonomous report. A STA may update the trigger conditions set for triggered autonomous reports by issuing a new Measurement Request element with the Enable and Report bits both set to 1, the Measurement Type field set to the appropriate type and the Measurement Request field indicating the new trigger conditions. A STA disables all triggered autonomous measurement reports by sending a Measurement Request element with the Enable bit set to 1 and the Report bit set to 0; see 9.4.2.21. A STA in an infrastructure BSS or PBSS shall cease all triggered autonomous reporting if it disassociates, or reassociates to a different BSS (reassociation to the same BSS shall not affect triggered reporting). An IBSS STA shall cease all triggered autonomous reporting if it leaves the BSS. Triggered autonomous reporting and requested measurements are independent: a STA may request measurements from another STA even if it has enabled triggered autonomous reporting from that STA. All Measurement Request elements received in Radio Measurement Request frames that have the Enable bit equal to 1 shall be processed without regard for the measurement precedence rules for requested measurements in 11.11.6. A number of triggered measurements may run concurrently at a non-AP STA. The number of simultaneous triggered measurements supported is outside the scope of the standard. Each triggered measurement is logically separate; reporting conditions such as Trigger Timeout periods apply only to the measurement for which they are established. 1715 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.11.9 Specific measurement usage 11.11.9.1 Beacon report If a STA accepts a Beacon request it shall respond with a Radio Measurement Report frame containing Beacon reports for all observed BSSs matching the BSSID and SSID in the Beacon request, at the level of detail requested in the Reporting Detail. If the Reporting Detail is 1 and the optional Request subelement is included in the Beacon request, the corresponding Beacon report shall include the list of elements listed in the Request subelement. The RCPI in the Beacon report indicates the power level of the received Beacon, Measurement Pilot, or Probe Response frame. For repeated measurements (when the Measurement Request frame contains a nonzero value for the Number of Repetitions field), the transmission of the Beacon report may be conditional on the measured RCPI or RSNI value. If the Measurement Request frame contains a 0 value for the Number of Repetitions field, the Beacon Reporting subelement shall not be included in the Beacon request. If the Measurement Request frame contains a nonzero value for the Number of Repetitions field, and if both dot11RMBeaconMeasurementReportingConditionsActivated and dot11RMRepeatedMeasurementsActivated are true, and if a Beacon Reporting subelement is included in a Beacon request, the STA shall respond with a Beacon report if the indicated Beacon reporting condition is true. Otherwise, the STA shall not respond with a Beacon report. Table 9-89 lists the reporting conditions that are based on the measured RCPI or RSNI levels. If the requested Beacon report includes the Supported Operating Classes element, then the channel number, operating class, and/or reported frame information for that measurement may be included in the beacon report; otherwise these fields shall be set to 255 in the beacon report. The STA shall use the Reporting Detail specified in the measurement request to determine the data to be included in the measurement report. If the STA has no beacon information available then the STA may either refuse the request or send an empty Beacon report. If dot11RMBeaconPassiveMeasurementActivated is true and the Measurement Mode in the measurement request is Passive, the measuring STA shall perform the following procedure (or an equivalent procedure) on the requested channel: â€” Set a measurement duration timer. â€” At the end of the measurement duration, process all received Beacons or Probe Response frames with the requested SSID and BSSID to compile the measurement report. The STA shall use the Reporting Detail specified in the measurement request to determine the data to be included in the measurement report. If no Beacon or Probe Response frames with the requested SSID and BSSID were received in the measurement duration, then process all Measurement Pilot frames with the requested BSSID to compile the measurement report. Otherwise, compile an empty Beacon report. If dot11RMBeaconPassiveMeasurementActivated is false and the Measurement Mode in the measurement request is Passive, the measuring STA shall reject the measurement request by returning a Beacon report with the Incapable bit in the Measurement Report Mode field set to 1. If dot11RMBeaconActiveMeasurementActivated is true and the Measurement Mode in the measurement request is Active, the measuring STA shall perform the following procedure (or an equivalent procedure) on the requested channel: â€” If the channel is not the operating channel, wait for dot11RMMeasurementNavSync, or until a PHY- RXSTART.indication primitive has been received. â€” Using the basic access protocol in 10.3.4.2, send a Probe Request frame to the broadcast destination address (DA). The BSSID field in the Probe Request frame shall be set to the BSSID field in the measurement request. The SSID element in the Probe Request frame shall be set to the SSID element in the measurement request. â€” Set a measurement duration timer. 1716 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” At the end of the measurement duration, process all received Probe Response and Beacon frames with the requested SSID and BSSID to compile the measurement report. The STA shall use the Reporting Detail specified in the measurement request to determine the data to be included in the measurement report. If no Beacons or Probe Response frames were received in the measurement duration and Measurement Pilot frames with the requested BSSID were received in the measurement duration, then process all these Measurement Pilot frames to compile the measurement report. Otherwise, compile an empty Beacon report. If dot11RMBeaconActiveMeasurementActivated is false and the Measurement Mode in the measurement request is Active, the measuring STA shall reject the measurement request by returning a Beacon report with the Incapable bit set in the Measurement Report Mode field. When more than one Beacon or Probe Response from a BSS is received in the measurement duration, the contents of the Beacon report shall be based on the latest received. If only Measurement Pilot frames were received in the measurement duration, the contents of the Beacon report shall be based on the latest Measurement Pilot frame received. If the BSSID field in the Measurement Request contains a wildcard BSSID, all observed BSSs with the requested SSID shall be reported in a separate Beacon report for each BSSID. If the SSID subelement is not included in the Beacon request, all observed BSSs shall be reported in a separate Beacon report for each BSSID. In active mode, Probe Response frames shall be evaluated regardless of whether the Probe Response frame was triggered by the measuring STAâ€™s Probe Request. On accepting an active or passive mode Beacon request, a STA shall conduct measurements as follows: â€” If the Channel Number is 0 and the Operating Class identifies the location of the primary channel, then a STA shall conduct iterative measurements on all supported channels in the specified Operating Class where the measurement is permitted on the channel and the channel is valid for the current regulatory domain. â€” If the Channel Number is 0 and if the Operating Class encompasses a primary channel but does not identify the location of the primary channel, then a STA shall conduct iterative measurements on all primary channel positions within all requested and supported channels where the measurement is permitted on the channel and the channel is valid for the current regulatory domain. â€” If the Channel Number is 255, the Operating Class identifies the location of the primary channel, and the Beacon request includes AP Channel Report subelements, a STA shall conduct iterative measurements on all supported channels listed in the AP Channel Report subelements that are valid for the current regulatory domain. If there is no AP Channel Report subelement included in the Beacon request, a STA shall conduct iterative measurements on all supported channels listed in the latest AP Channel Report received from the serving AP that are valid for the current regulatory domain. If there are no AP Channel Report subelements included in the Beacon request, and no AP Channel Report included in last received AP Beacon frame, the STA shall reject the Beacon request. â€” If the Channel Number is 255, the Operating Class encompasses a primary channel but does not identify the location of the primary channel, and the Beacon request includes AP Channel Report subelements, then a STA shall conduct iterative measurements on all primary channel positions within all requested (in the AP Channel Report) and supported channels that are valid for the current regulatory domain. If there are no AP Channel Report subelements included in the Beacon request, the STA shall reject the Beacon request. â€” If the Channel Number is a value other than 0 or 255, a STA shall conduct iterative measurements on the requested channel, where the measurement is permitted on the channel and the channel is valid for the current regulatory domain. Except when the Measurement Mode field is equal to Beacon Table, measurements shall be made using the specified Measurement Duration with the time between each consecutive measurement as defined in 1717 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.11.2. Iterative measurements shall cease when all channels have been measured. While the STA is processing a Beacon request for iterative channel measurements, the STA shall not begin processing the next measurement request in the Measurement Request frame. If dot11RMBeaconTableMeasurementActivated is true and the Measurement Mode in the measurement request is Beacon Table, the measuring STA shall return a Beacon report containing the current contents of any stored beacon information for any supported channel with the requested SSID and BSSID without performing additional measurements. The receiving STA shall ignore the channel and measurement duration specified in the Beacon request when the Measurement Mode field contains Beacon Table. The beacon information accumulated may be the result of any operation that caused the STA to acquire these results. If the stored beacon information is based on a measurement made by the reporting STA, and if the actual measurement start time, measurement duration, and Parent TSF are available for this measurement, then the beacon report shall include the actual measurement start time, measurement duration, and Parent TSF; otherwise the actual measurement start time, measurement duration, and Parent TSF shall be set to 0. The RCPI and RSNI for that stored beacon measurement may be included in the beacon report; otherwise the beacon report shall indicate that RCPI and RSNI measurements are not available. If dot11RMBeaconTableMeasurementActivated is false and the Measurement Mode in the measurement request is Beacon Table, the measuring STA shall reject the measurement request by returning a Beacon report with the Incapable bit set in the Measurement Report Mode field. For repeated measurements, the Beacon request may include a Beacon Reporting subelement that determines when the measuring STA is to send a Beacon report for a measured Beacon, Measurement Pilot, or Probe Response frame with the requested SSID and BSSID. When the requested Reporting Condition value is nonzero, and dot11RMBeaconMeasurementReportingConditionsActivated is true, the STA shall create and transmit a Beacon report for that measured frame if the condition indicated in Table 9-89 is true. Otherwise, the STA shall not transmit a Beacon report for that measured frame. If multiple Beacons, Measurement Pilots, or Probe Response frames with the requested specific BSSID are received during the measurement duration, the reporting condition shall be applied only to the latest received Beacon, Measurement Pilot, or Probe Response frame. If multiple Beacons, Measurement Pilots, or Probe Response frames are received during the measurement duration when a wildcard BSSID is requested, the STA shall generate one Beacon report for each BSSID occurring in frames that satisfy the reporting condition; the Beacon report shall be based on the latest received Beacon, Measurement Pilot, or Probe Response frame for that specific BSSID. For reporting conditions 5â€“10, the serving APâ€™s reference RCPI level and the serving APâ€™s reference RSNI level referred to in Table 9-89 are average values of the RCPI or RSNI of the 16 most recent Beacon frames received from the measuring STAâ€™s serving AP. The serving APâ€™s reference RCPI level and the serving APâ€™s reference RSNI level are so averaged to provide a more accurate and stable indication of the signal level from the serving AP. For reporting conditions 5â€“10, the STA shall use the serving APâ€™s reference RCPI level or reference RSNI level (with offset, if any) to test the measured RCPI or RSNI to determine whether to create and send a Beacon report for this measured Beacon, Measurement Pilot, or Probe Response frame. The STA shall return a Beacon report with the Incapable bit set in the Measurement Report Mode field in the following cases: â€” Reporting Condition in the Beacon request is nonzero and dot11ReportingConditionsActivated is false, â€” Reporting Condition in the Beacon request is nonzero and the Number of Repetitions in the Measurement Request frame is 0. NOTEâ€”Reporting conditions described here for repeated Beacon request measurements are distinct from the conditions defined elsewhere for triggered measurements. A STA that is not extended spectrum management capable shall not include a Wide Bandwidth Channel Switch subelement in a Beacon request or Beacon report. A STA shall not include a Wide Bandwidth 1718 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Channel Switch subelement in a Beacon request or Beacon report sent to a STA that is not extended spectrum management capable. If the Wide Bandwidth Channel Switch subelement is included in a Beacon request or Beacon report, then the Operating Class shall indicate a 40 MHz channel spacing. If N (where N 1) AP Channel Report subelements containing an Operating Class with an 80+ behavior limit (the 80+ behavior limit is defined in Table D-2, the operating classes that might use this limit are defined in E.1) are included contiguously in a Beacon request, then the N subelements shall be followed by one AP Channel Report subelement containing an Operating Class without an 80+ behavior limit (as defined in Annex E). All N+1 Channel List fields in each of these subelements shall contain the same number L of channel numbers. This sequence of N+1 AP Channel Report subelements indicates a list of L noncontiguous channels comprising N+1 frequency segments, where the lth channel number in the nth Channel List field identifies the channel center frequency of the nth frequency segment. NOTEâ€”To identify the BSS bandwidth, the Beacon request might include a Request subelement listing the element IDs of the HT Operation and VHT Operation elements. The Beacon report would then include the requested elements, which contain fields defining the BSS bandwidth. 11.11.9.2 Frame report If dot11RMFrameMeasurementActivated is true, and a station accepts a Frame request, it shall respond with a Radio Measurement Report frame containing one or more Measurement Report elements with the Measurement Type field set to Frame. (See 9.4.2.22.8.) If the MAC Address field included in the Frame request was not set to the broadcast address, a Frame Report Entry field where Transmitter Address (TA) matching the MAC address field value shall be included in the Frame report if at least one Data or Management frame was received with this Transmitter Address during the measurement duration. If the MAC address field included in the Frame request was set to the broadcast address, the measuring station shall report all Data or Management frames received during the measurement duration in one or more Frame reports. If the Frame Request Type of the corresponding Frame request equals 1, then each Frame report contains one Frame Count subelement that contains in turn one or more Frame Report Entries.The measuring station shall count the number of individually addressed Data and Management frames received from one transmit address during the measurement duration and shall summarize this traffic in a frame report entry. Each Frame Report Entry field contains the Transmit Address, BSSID, PHY Type, Average RCPI, Last RSNI, Last RCPI, Antenna ID, and Frame Count for the frames counted in this Frame Report Entry field. The reported Average RCPI shall be an average of the RCPI values of frames received and counted in the Frame Report Entry field. If there are up to 32 frames, then the Average RCPI indicates the mean of the RCPI of each of the frames. If there are more than 32 frames, then the Average RCPI indicates an exponentially weighted average, initialized by the mean RCPI of the first 32 frames and exponentially updated by new RCPI values. The averaging is calculated as depicted as follows. If the number of frames received is less than or equal to 32: Average RCPI = Sum of RCPI values / Number of frames For 33 received frames and above: Average RCPI = (Last Average RCPI 31 / 32) + (Current frame RCPI / 32) The Last RCPI shall be the RCPI value of the most recently received frame counted in the Frame Report Entry field. The Antenna ID field contains the identifying number for the antenna(s) used to receive the most recently received frame included in this Frame Report Entry field as defined in 9.4.2.40. If different 1719 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications antennas are used to receive the frame preamble and the frame body, this Antenna ID shall contain the identifying number for the antenna(s) used to receive the frame body. If dot11RMFrameMeasurementActivated is false, a station shall reject the received Frame request by returning a Frame report in which the Incapable bit in the Measurement Report Mode field is 1. A STA that is not extended spectrum management capable shall not include a Wide Bandwidth Channel Switch subelement in a Frame request or Frame report. A STA shall not include a Wide Bandwidth Channel Switch subelement in a Frame request or Frame report sent to a STA that is not extended spectrum management capable. If the Wide Bandwidth Channel Switch subelement is included in a Frame request or Frame report, then the Operating Class shall include a 40 MHz channel spacing. 11.11.9.3 Channel load report If dot11RMChannelLoadMeasurementActivated is true and a station accepts a Channel Load request, it shall respond with a Radio Measurement Report frame containing one Measurement (Channel Load) Report element. The Channel Load field is defined as the percentage of time, linearly scaled with 255 representing 100%, the STA sensed the medium was busy, as indicated by either the virtual carrier sense mechanism or the physical carrier sense mechanism over the requested channel width (together referred to as the CS mechanism). This percentage is computed using the following formula: channel busy time Channel Load = ----------------------------------------------------------------------- - 255 MeasurementDuration 1024 where channel busy time is defined to be the number of microseconds during which the CS mechanism, as defined in 10.3.2.1, has indicated a channel busy indication for the requested channel width. If dot11RMChannelLoadMeasurementActivated is false, a station shall reject the received Channel Load request by returning a Channel Load report with the Incapable bit in the Measurement Report Mode field set to 1. If dot11RMChannelLoadMeasurementActivated is true and if a Channel Load Reporting subelement is included in a Channel Load request, the STA shall respond with a Channel Load report if the indicated channel load reporting condition is true. Otherwise, the STA shall not respond with a Channel Load report. A STA that is not extended spectrum management capable shall not include a Wide Bandwidth Channel Switch subelement in a Channel Load request or Channel Load report. A STA shall not include a Wide Bandwidth Channel Switch subelement in a Channel Load request or Channel Load report sent to a STA that is not extended spectrum management capable. If the Wide Bandwidth Channel Switch subelement is included in a Channel Load request or a Channel Load report, then the Operating Class shall indicate a 40 MHz channel spacing. 11.11.9.4 Noise Histogram report If dot11RMNoiseHistogramMeasurementActivated is true and a station accepts a Noise Histogram request, it shall respond with a Radio Measurement Report frame containing one Measurement (Noise Histogram) Report element. The Noise Histogram report shall contain the IPI densities observed in the channel for the IPI levels defined in Table 9-110. To compute the IPI densities, a STA shall measure the amount of time, in microseconds, during which the IPI is in each IPI range specified in Table 9-110. These IPI measurements shall be taken over the entire associated channel bandwidth, and during the requested measurement duration except for those time intervals during which the NAV is not equal to 0 (when virtual CS mechanism indicates channel busy), or 1720 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications during which frame transmission or reception is occurring. The IPI densities are then computed for each of the nine possible IPI values using: 255 D IPI IPI Density = Integer ------------------------------------------------------------------------------ - 1024 D M â€“ T NAV â€“ T TX â€“ T RX where DIPI is the duration receiving at the specified IPI value ( s) DM is the measurement duration (TU) TNAV is the total time that NAV is nonzero during the Measurement Duration ( s) TTX is the frame transmission time during the Measurement Duration ( s) TRX is the frame reception time during the Measurement Duration ( s) The sum of the IPI densities is approximately 255. If either the NAV is nonzero, or if there is frame transmission, or if there is frame reception throughout the entire measurement duration period, no reportable IPI values are measured, and all IPI Densities shall be set to 0 in the Measurement Report element. A STA shall include in the Noise Histogram report an average noise power indicator (ANPI) value representing the average noise plus interference power on the measured channel at the antenna connector during the measurement duration. The STA may use Noise Histogram IPI density values to calculate ANPI. The IPI densities in the Noise Histogram report may be used to calculate an average noise power for the channel during the measurement duration. This calculated average IPI power value may be reported as the value for ANPI. Any equivalent method to measure ANPI may also be used. ANPI power is defined in dBm using the same accuracy as defined for RCPI. ANPI may be calculated over any period and for any received frame. ANPI may be calculated in any period and at any time by filtering all PHY IPI values in a MAC filter to exclude IPI values received when NAV is nonzero. These filtered IPI values represent idle channel noise and may be stored in a first-in-first-out (FIFO) buffer to facilitate ANPI calculation over a fixed number of IPI samples. ANPI may be so calculated upon receipt of any frame and may be used with RCPI to calculate RSNI for any received frame. Any equivalent method to measure ANPI may also be used to calculate RSNI for any received frame. If dot11RMNoiseHistogramMeasurementActivated is false, a station shall reject the received Noise Histogram request by returning a Noise Histogram report with the Incapable bit in the Measurement Report Mode field set to 1. If dot11RMNoiseHistogramMeasurementActivated is true and if a Noise Histogram Reporting subelement is included in a Noise Histogram request, the STA shall respond with a Noise Histogram report if the indicated noise histogram reporting condition is true. Otherwise the STA shall not respond with a Noise Histogram report. A STA that is not extended spectrum management capable shall not include a Wide Bandwidth Channel Switch subelement in a Noise Histogram request or Noise Histogram report. A STA shall not include a Wide Bandwidth Channel Switch subelement in a Noise Histogram request or Noise Histogram report sent to a STA that is not extended spectrum management capable. If the Wide Bandwidth Channel Switch subelement is included in a Noise Histogram request or a Noise Histogram report, then the Operating Class shall indicate a 40 MHz channel spacing. 11.11.9.5 STA Statistics report If dot11RMStatisticsMeasurementActivated is true and a station accepts a STA Statistics request, it shall respond with a Radio Measurement Report frame including one STA Statistics report. If the Requested 1721 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Measurement Duration value is 0, the STA shall report the current values for the requested Statistics Group Data. If the Requested Measurement Duration value is greater than 0, the STA Statistics report reports the change in the requested Statistics Group Data measured within that nonzero Measurement Duration. The reported change in data value shall be the value of the data at the end of the actual Measurement Duration minus the value of the data at the beginning of the actual Measurement Duration. If a STA accepts a STA Statistics request measurement with nonzero, positive Measurement Duration, the STA shall perform the measurement over the requested Measurement Duration without regard to the Duration Mandatory bit in the Measurement Request Mode field. If a STA cannot measure over the requested Measurement Duration, the STA shall refuse the Statistics request measurement. If dot11RMStatisticsMeasurementActivated is false, a station shall reject the received STA Statistics request by returning a Statistics Measurement Report with the Incapable bit in the Measurement Report Mode field set to 1. A STA may request that a STA Statistics report be sent when statistics of interest reach a threshold as defined in the Measurement Request element of the STA Statistics request frame (see 9.4.2.21.9). This is termed a triggered STA Statistics measurement. Implementation of Triggered STA Statistics Reporting is optional for a WNM STA. A STA that implements Triggered STA Statistics Reporting has dot11TriggerSTAStatisticsImplemented equal to true. When dot11TriggerSTAStatisticsImplemented is true, dot11WirelessManagementImplemented shall be true. A triggered STA Statistic measurement shall be requested by setting the Enable and Report bits to 1 within a Measurement Request element with the Measurement Type field set to STA Statistics. The Measurement Request field shall contain a STA Statistics request with the trigger conditions specified in the Triggered Reporting subelement, as defined in 9.4.2.21.9. One or more trigger conditions shall be set with specified thresholds. See 11.11.8. To prevent generation of too many triggered reports, the value of the Trigger Timeout field shall be set to a value greater or equal to dot11MinTriggerTimeout. If the value of the Trigger Timeout field is less than dot11MinTriggerTimeout, the STA shall reject the measurement request by returning a report where the Measurement Report Mode field is â€œIncapable.â€ A STA accepting a triggered STA Statistics measurement shall measure the requested statistics. If a trigger condition occurs, the measuring STA shall send a STA Statistics measurement report to the requesting STA. The measuring STA shall not send further triggered STA Statistics reports for that trigger condition to the requesting STA until the Trigger Timeout period specified in the request frame has expired. The STA Statistics measurement report is defined in 9.4.2.21.9. If the number of MPDUs or MSDUs indicated in the Measurement Count field are transmitted or received without any of the counted statistics meeting the corresponding trigger threshold then the measuring STA shall restart measuring for another measurement count window. If a STA receives a STA Statistics request from the same STA for which a triggered STA Statistics measurement is in progress, the in-progress triggered measurement shall be terminated. STA Statistics reported in a triggered STA Statistics report shall be the values accumulated over the number of transmitted or received MSDUs or MPDUs before the trigger condition is met. Measurement duration shall not be specified when requesting a triggered STA statistics measurement and the Measurement Duration field in the corresponding Measurement Request shall be set to 0. All triggered STA Statistics measurements shall be terminated at a measuring STA by receiving a STA Statistics request with the Enable bit equal to 1 and the Report bit equal to 0. A STA requesting a triggered STA Statistics measurement may update the trigger conditions by sending a STA Statistics request specifying the new trigger conditions. 1722 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Once accepted by a measuring STA, a triggered STA Statistics measurement continues to be active until the measurement request is superseded by a STA Statistics request from the requesting STA or the measuring STA disassociates or reassociates. 11.11.9.6 LCI report (Location configuration information report) If dot11RMLCIMeasurementActivated is true, a STA that receives an LCI request for location information that is not available shall respond with a Radio Measurement Report frame including a Radio Measurement Report element with the Refused bit set to 1. If dot11RMLCIMeasurementActivated is true and a STA accepts an LCI request that does not include an azimuth request, it shall respond with a Radio Measurement Report frame including one LCI subelement (LCI report). If both dot11RMLCIMeasurementActivated and dot11RMLCIAzimuthActivated are true, and the STA accepts an LCI request that includes an azimuth request, it shall respond with a Radio Measurement Report frame that includes one LCI subelement (LCI report) and the requested Azimuth Report, if available. If dot11RMLCIAzimuthActivated is false, a STA that receives an LCI request that includes an azimuth request shall respond with a Radio Measurement Report frame including an Radio Measurement Report element with the Incapable bit set to 1. The Datum value shall be 1 (World Geodetic System 1984), unless another datum is required for operation in the regulatory domain. If the Altitude Type is 2 (Floors of Altitude), the value reported shall be as required for operation in the regulatory domain. An LCI request shall indicate a location request for the requesting STA, the reporting STA, or a third STA with the MAC address specified in the Target MAC Address subelement, by setting the LCI request Location Subject field to indicate a Local, a Remote, or a third-party request, respectively. Local LCI request is used by the requesting STA to obtain its own location by asking â€œWhere am I?â€ Remote LCI request is used by requesting STA to obtain location of reporting STA by asking â€œWhere are you?â€ Third- party location request is used by requesting STA to obtain location of a STA with the MAC address specified in the Target MAC Address subelement. The Latitude, Longitude, and Altitude fields of the LCI report shall be reported at their best known resolutions unless otherwise configured. If the STA receiving an LCI request has no location information about the requested LCI subjectâ€™s physical location, the STA shall send a LCI subelement indicating an unknown LCI (see 9.4.2.22.10). If the STA receiving an LCI request has no location information about the requested Azimuth, the STA shall omit the Azimuth Report subelement. If the STA receiving an LCI request that contains a Maximum Age subelement has already determined the requested LCI within the indicated maximum age, the STA may respond with its already determined LCI; otherwise, the STA shall update its LCI before the STA responds with its LCI. The method by which the physical location and azimuth information in the LCI report is generated is outside the scope of this standard. A STA that receives an LCI report that contains a Usage Rules/Policy subelement shall process the LCI information in compliance with the retransmission and retention permissions in the Usage-rules subelement. NOTEâ€”A STA that requested an LCI including an Azimuth Request, and received an LCI report in which the Incapable bit is 1 might alternatively request the LCI with no Azimuth requested. If dot11RM3rdPartyMeasurementActivated is false, a STA that receives an LCI request that includes an LCI request with the Location Subject field equal to 2 shall respond with a Radio Measurement Report frame including an Radio Measurement Report element with the Incapable bit set to 1. 1723 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications It is optional for a STA to support an LCI request and an LCI report with the Location Subject field equal to 2. If dot11RM3rdPartyMeasurementActivated is true and a STA supports LCI request and LCI report, the following procedure shall be followed: â€” When a non-AP STA requests the geospatial location of a STA with the MAC address specified in the Target MAC address field, it shall also include its own MAC address in the Originator Requesting STA MAC address field. When an AP receives an LCI request with the Location Subject field value equal to 2, the AP shall generate an LCI request to the STA with the MAC address specified in the Target MAC address field. If the AP does not have an association with the STA with the MAC address specified in the Target MAC address field, the AP shall reject the received LCI request by returning an LCI report where the Incapable bit is set in the MeasurementReport Mode field. The AP shall copy the Originator Requesting STA MAC address and Target MAC address fields into the request from the received LCI request. â€” When a STA receives an LCI request with the Location Subject field value equal to 2, the STA may generate an LCI report if the MAC address in the Target MAC address field is its own MAC address; it shall not generate an LCI report otherwise. When an LCI report is generated, the reporting STA shall include its MAC address into the Target MAC address field and the MAC address present in the Originator Requesting STA MAC address field of the corresponding LCI request into the Originator Requesting STA MAC address field. When an AP receives an LCI report with an Originator Requesting STA MAC address field present, the AP shall generate an LCI report to the associated STA with the MAC address specified in the Originator Requesting MAC address field. The AP shall copy the Originator Requesting STA MAC address and Target MAC address fields into the LCI report being transmitted to the originating requesting STA. If dot11RMLCIMeasurementActivated is false, a station shall reject the received LCI request by returning an LCI report with the Incapable bit in the Measurement Report Mode field set to 1. If dot11RMLCIMeasurementActivated is true and a STA has its own location configured in LCI format excluding an unknown LCI as defined in 9.4.2.21.10, the STA shall set dot11RMLCIConfigured to true. NOTEâ€”It is recommended that User Applications not send location information to other stations without the express permission of the user. User agents acquire permission through a user interface, unless they have prearranged trust relationships with users. Those permissions that are acquired through the user interface and that are preserved beyond the current browsing session (i.e., beyond the time when the BSS connection is terminated) are revocable and receiving stations should respect revoked permissions. Some user applications might have prearranged trust relationships that do not require such user interfaces. For example, while a social networking application might present a user interface when a friend performs a location request, a VOIP telephone might not present any user interface when using location information to perform an E911 function. 11.11.9.7 Measurement Pause A measurement pause is used within a Measurement Request frame to provide a time delay between the processing of two other Measurement Request elements within the sequence of Measurement Request elements in that frame. If a STA accepts a Measurement Pause request it shall delay processing of the next measurement request in the Measurement Request frame. If the Measurement Pause request is the last Measurement Request element in a repeated Measurement Request frame, the STA shall delay processing the first Measurement Request element in the Measurement Request frame for the next repeat. In each case the delay shall be no less than the Pause Time value specified in the Measurement Pause request. NOTEâ€”Measurement pause is always supported by a STA implementing radio measurements. A measurement pause shall not be sent as the only Measurement Request element in a Measurement Request frame. A measurement pause shall not be included as the last Measurement Request element in a Measurement Request frame that has the Number of Repetitions field equal to 0. 1724 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A measurement pause cannot be processed in parallel to other measurements. If the Parallel bit is 1 in the Measurement Request element immediately prior to a measurement pause, an incapable response shall be returned even if dot11RMParallelMeasurementsActivated is true. There is no measurement report associated with a Measurement Pause request. 11.11.9.8 Transmit Stream/Category Measurement report The Transmit Stream/Category Measurement applies to TIDs for Traffic Streams associated with TSPECs and also to TIDs for Traffic Categories for QoS traffic without TSPECs. If dot11RMTransmitStreamCategoryMeasurementActivated is true and has no resource constraint that prevents it from being able to make the requested measurement, a QoS STA receiving a Transmit Stream/ Category Measurement request shall respond with a Radio Measurement Report frame containing one Measurement (Transmit Stream/Category Measurement) Report element. If the traffic stream (TS) that is corresponding to the Traffic Identifier is deleted, either by a DELTS frame or by disassociation, the STA shall cease sending Radio Measurement Reports. If dot11RMTransmitStreamCategoryMeasurementActivated is false, a STA shall reject the received Transmit Stream/Category Measurement request by returning a Transmit Stream/Category Measurement report with the Incapable bit in the Measurement Report Mode field set to 1. The transmit stream/category measurement shall be made on traffic that is transmitted from the measuring QoS STA to the peer QoS STA and TID indicated in the request. The Peer STA Address may be the MAC address of the QoS STA from which the Measurement Request was sent, the MAC address of another QoS STA within the BSS, or the broadcast address. This enables a QoS AP to query Transmit Stream/Category Measurement metrics for DLS links. A broadcast address shall be used only with a TID corresponding to a TC. In the case of a broadcast address, measurement shall be made on all traffic for the specified TC. Depending on policy, a QoS AP may disallow transmit stream/category measurement requests for traffic to other QoS STAs in the BSS. In this case the QoS AP shall respond with a matching Measurement Report frame with the Incapable subfield of the Measurement Report Mode field set to 1. If, during the course of a Transmit Stream/Category Measurement, any counter that is included in the Transmit Stream/Category Measurement report increments to a value of 232â€“1, the Transmit Stream/ Category Measurement shall terminate, and the Transmit Stream/Category Measurement report shall indicate the shortened, actual measurement duration. If the measurement request included multiple transmit stream/category measurement requests for multiple TIDs, the corresponding measurement report shall include a transmit stream/category measurement report for each unique TID in the request that has been admitted. If the measurement request is for a TID that has not been admitted yet, a report is generated only after the TID becomes admitted. The requesting and reporting STAs are QoS STAs. A non-QoS STA receiving a Transmit Stream/Category Measurement request shall reject the request by returning an indication of incapable. A QoS STA may request that a measuring QoS STA send a transmit stream/category measurement report when the number of TID-specified MSDUs are discarded or delayed reaches a specified threshold. This is termed a triggered transmit stream/category measurement and shall be requested by setting the Enable and Report bits to 1 within a Measurement Request element containing the Transmit Stream/Category Measurement Type. The Measurement Request field shall contain a Transmit Stream/Category Measurement request with the trigger conditions specified in the Triggered Reporting subelement. One or more trigger conditions may be set with specified thresholds. See 9.4.2.21.11. 1725 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Depending on policy, a QoS AP might not permit the establishment of triggered transmit stream/category measurement. Such a QoS AP receiving a triggered transmit stream/category measurement request shall give an incapable indication. The number of simultaneous triggered transmit stream/category measurements supported at a QoS STA is outside the scope of the standard. A STA shall respond to further requests with a refused indication if the number of simultaneous triggered QoS measurements supported by the STA is reached. If dot11RMTriggeredTransmitStreamCategoryMeasurementActivated is true, a QoS STA shall accept a triggered Transmit Stream/Category Measurement and shall reject it otherwise. A QoS STA accepting a triggered QoS measurement shall measure the requested TC or TS. If a trigger condition occurs, the measuring QoS STA shall send a Transmit Stream/Category Measurement report to the requesting QoS STA. The measuring QoS STA shall not send further triggered QoS reports until the Trigger Timeout period specified in the request has expired or new trigger conditions have been requested. Measurement of transmit stream/category metrics shall continue during the reporting timeout period. Reporting shall resume following the Trigger Timeout period, or immediately following the acceptance of new trigger conditions. If a QoS STA receives a Transmit Stream/Category Measurement request for a TC, or TS that is already being measured using a triggered transmit stream/category measurement, the triggered traffic stream measurement shall be suspended for the duration of the requested traffic stream measurement. When triggered measurement resumes, the traffic stream metrics shall be reset. Traffic stream metrics reported in a triggered transmit stream/category measurement report shall be the values accumulated over the number of successfully and unsuccessfully transmitted MSDUs prior to the trigger event given in the Measurement Count field of the transmit stream/category measurement request that established the trigger condition. It is possible that a consecutive or delay trigger event occurs after acceptance of a triggered transmit stream/category measurement but before the number of MSDUs in Measurement Count has been transmitted. In this case the report shall be the values accumulated since measurement started. The measurement count value appears in the Transmitted MSDU Count field of a triggered transmit stream/category measurement report. Measurement duration shall not be used in triggered QoS measurement, and the Measurement Duration field in both the Measurement Request and any Measurement Report shall be set to 0. The Measurement Start Time field of a triggered transmit stream/category measurement report shall contain the value of the QoS STA TSF timer at the time the trigger condition occurred to an accuracy of 1 TU. Once accepted by a measuring QoS STA, a triggered QoS measurement continues to be active until â€” The relevant TS is deleted, â€” The measuring QoS STA or QoS STA that requested the measurement disassociates or successfully reassociates, or â€” The measurement is terminated by the requesting QoS STA. All triggered QoS measurements shall be terminated at a measuring QoS STA by receiving a triggered transmit stream/category measurement request with the Enable bit equal to 1 and the Report bit equal to 0. A triggered QoS measurement request with no trigger conditions specified in the Trigger Conditions field shall terminate a triggered QoS measurement for the TC or TS specified in the request. A QoS STA requesting a triggered QoS measurement may update the trigger conditions by sending a triggered transmit stream/ category measurement request specifying the new trigger conditions. 11.11.9.9 Location Civic report If dot11RMCivicMeasurementActivated is true and civic location information is not available, the STA shall reject a Location Civic request by returning a Measurement Report frame including a Measurement Report element with the Refused bit set to 1. If dot11RMCivicMeasurementActivated is true and civic 1726 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications location information is available, the STA shall respond with a Measurement Report frame including one Location Civic report. A Location Civic request shall indicate a location request for the requesting STA, the reporting STA, or a third STA with the MAC address specified in the Target MAC address field, by setting the Location Civic request Location Subject field to indicate a Local, a Remote, or a third-party request respectively. Local Location Civic request is used by requesting STA to obtain its own location by asking â€œWhere am I?â€ Remote Location Civic request is used by requesting STA to obtain location of the reporting STA by asking â€œWhere are you?â€ Third-party Location request is used by requesting STA to obtain location of a STA with the MAC address specified in the Target MAC address field. If dot11RMCivicMeasurementActivated is false, a STA that receives the received Location Civic request shall respond with a Location Civic report where the Incapable bit is set in the Measurement Report Mode field. If dot11RM3rdPartyMeasurementActivated is false, a STA shall reject any LCI request that includes an LCI request with the Location Subject field equal to 2 by returning a Radio Measurement Report frame including an Radio Measurement Report element with the Incapable bit set to 1. It is optional for a STA to support a Location Civic request and a Location Civic report with the Location Subject field equal to 2. If dot11RM3rdPartyMeasurementActivated is true and a STA supports Location Civic request and Location Civic report, the following procedure shall be followed: â€” When a non-AP STA requests the civic location of a STA with the MAC address specified in the Target MAC address field, it shall also include its own MAC address in the Originator Requesting STA MAC address field. When an AP receives a Location Civic request with the Location Subject field value equal to 2, the AP shall generate a Location Civic request to the STA with the MAC address specified in the Target MAC address field. If the AP does not have an association with the STA with the MAC address specified in the Target MAC address field, the AP shall reject the received Location Civic request by returning a Location Civic report where the Incapable bit is set in the Measurement Report Mode field. The AP shall copy the Originator Requesting STA MAC address and Target MAC address fields into the request from the received Location Civic request. â€” When a STA receives a Location Civic request with the Location Subject field value equal to 2, the STA may generate a Location Civic report if the MAC address in the Target MAC address field is its own MAC address; it shall not generate a Location Civic report otherwise. When a Location Civic report is generated, the reporting STA shall include its MAC address into the Target MAC address field and the MAC address present in the Originator Requesting STA MAC address field of the corresponding Location Civic request into the Originator Requesting STA MAC address field. When an AP receives a Location Civic report with an Originator Requesting STA MAC address field present, the AP shall generate a Location Civic report to the associated STA with the MAC address specified in the Originator Requesting MAC address field. The AP shall copy the Originator Requesting STA MAC address and Target MAC address fields into the Location Civic report being transmitted to the originating requesting STA. When a STA receives a Location Civic request with the subject field equal to 2, but does not support third- party location, it shall respond with a Radio Measurement Report frame including a Radio Measurement Report element with the Incapable bit set to 1. If dot11RMCivicMeasurementActivated is true and a STA has its own location configured in civic format, excluding an unknown civic location as defined in 9.4.2.22.13, the STA shall set dot11RMCivicConfigured to true. 1727 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If dot11RMCivicMeasurementActivated is true and a STA has its own location available in one or more location formats, as defined in Table 9-100, and includes Civic Location Type field value 0, indicating â€œIETF RFC 4776,â€ it shall set the Civic Location field to 1 in the Extended Capabilities element. NOTEâ€”The Location Civic fieldâ€™s size limit constrains the amount of information that can be carried. If the Location Civic report contains the Location Reference and Location Shape subelements, the receiving STA may use the information specified in those subelements in combination with the Civic Location field value for additional granularity on the position reported in the Civic Location field. If the Location Civic report contains the Map Image subelement, the receiving STAâ€™s SME can retrieve the floor plan specified by the Map URL field. The method to retrieve the floor plan specified by the Map URL field is out of scope of this document. 11.11.9.10 Location Identifier report The Location Identifier report provides the ability for a STA to receive one or more: â€” Indirect URI references and forward a subset of those references to an external agent for the purposes of that agent gathering the STAâ€™s location value. The protocol used to query for a location report based on the Public Identifier URI/FQDN provided in the Location Identifier report is indicated by the URI/FQDN Descriptor field. â€” FQDNs, one per location server, that can be used to discover the location server and establish communications with it. The protocol used with the location server is indicated by the URI/FQDN Descriptor field. If dot11RMIdentifierMeasurementActivated is true and location information is not available, the STA that receives a Location Identifier request shall respond with a Measurement Report frame including a Measurement Report element with the Incapable bit set to 1. If dot11RMIdentifierMeasurementActivated is true and location information is available, the STA shall respond with a Measurement Report frame including one Measurement Report element containing a Location Identifier report that carries one or more Public Identifier URI/FQDN subelements. A Location Identifier request shall indicate a location request for the requesting STA, the reporting STA, or a third-party STA with the MAC address specified in the Target MAC address field, by setting the Location Identifier request Location Subject field to indicate a Local, a Remote, or a Third-party request respectively. Local Location Identifier request is used by requesting STA to obtain its own location by asking â€œWhere am I?â€ Remote Location Civic request is used by requesting STA to obtain location of the reporting STA by asking â€œWhere are you?â€ Third-party Location request is used by requesting STA to obtain location of a STA with the MAC address specified in the Target MAC address field. If dot11RM3rdPartyMeasurementActivated is false, a STA that receives an LCI request that includes an LCI request with the Location Subject field equal to 2 shall respond with a Radio Measurement Report frame including an Radio Measurement Report element with the Incapable bit set to 1. It is optional for a STA to support a Location Identifier request and a Location Identifier report with the Location Subject field equal to 2. If dot11RM3rdPartyMeasurementActivated is true and a STA supports Location Identifier request and Location Identifier report, the following procedure shall be followed: â€” When a non-AP STA requests the location identifier of a STA with the MAC address specified in the Target MAC address field, it shall also include its own MAC address in the Originator Requesting STA MAC address field. When an AP receives a Location Identifier request with the Location Subject field value equal to 2, the AP shall generate a Location Identifier request to the STA with the MAC address specified in the Target MAC address field. If the AP does not have an association with the STA with the MAC address specified in the Target MAC address field, the AP shall reject the received Location Identifier request by returning a Location Identifier report where 1728 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications the Incapable bit is set in the Measurement Report Mode field. The AP shall copy the Originator Requesting STA MAC address and Target MAC address fields into the request from the received Location Identifier request. â€” When a STA receives a Location Identifier request with the Location Subject field value equal to 2, the STA may generate a Location Identifier report if the MAC address in the Target MAC address field is its own MAC address; it shall not generate a Location Identifier report otherwise. When a Location Identifier report is generated, the reporting STA shall include its MAC address into the Target MAC address field and the MAC address present in the Originator Requesting STA MAC address field of the corresponding Location Identifier request into the Originator Requesting STA MAC address field. When an AP receives a Location Identifier report with an Originator Requesting STA MAC address field present, the AP shall generate a Location Identifier report to the associated STA with the MAC address specified in the Originator Requesting MAC address field. The AP shall copy the Originator Requesting STA MAC address and Target MAC address fields into the Location Identifier report being transmitted to the originating requesting STA. When a STA receives an Location Identifier request with the subject field equal to 2, but does not support third-party location, it shall respond with a Radio Measurement Report frame including a Radio Measurement Report element with the Incapable bit set to 1. If dot11RMIdentifierMeasurementActivated is false, a STA shall reject the received Location Identifier request by returning a Location Identifier report where the Incapable bit is set in the Measurement Report Mode field. If dot11RMIdentifierMeasurementActivated is true and a STA has its own location available in one or more location formats, as defined in Table 9-100, and includes Civic Location Type field value 0, indicating â€œIETF RFC 4776â€ or geospatial format that can be referenced by a location identifier, it shall set the Identifier Location field to 1 in the Extended Capabilities element. 11.11.9.11 Fine Timing Measurement Range report The Fine Timing Measurement Range report provides a means for a requesting STA to request a responding STA that advertises FTM Range Report Capability Enabled equal to true in the RM Enabled Capabilities element to measure and report the ranges between the responding STA and other nearby APs where the ranges are determined using the FTM procedure (see 11.24.6). If dot11RMFineTimingMsmtRangeRepActivated is true, dot11FineTimingMsmtInitActivated shall be true also. If dot11RMFineTimingMsmtRangeRepActivated is false, a STA shall reject any Fine Timing Measurement Range request by responding with a Radio Measurement Report frame that includes a Measurement Report element with the Incapable field set to 1. If a responding STA with dot11RMFineTimingMsmtRangeRepActivated equal to true accepts a Fine Timing Measurement Range request, then: â€” If the request includes a maximum age subelement, and the STA has already determined FTM ranges to C APs listed in the Neighbor Report subelements field in the Measurement Request field within the indicated Maximum Age, then the STA may use these ranges instead of initiating new FTM procedures with the C APs.Define Csub as the subset of APs selected by the STA from the C eligible APs. â€” Considering the remaining listed APs in the Neighbor Report subelements field in the Measurement Request field, if Minimum AP Count exceeds Csub, the responding STA shall wait a random delay up to the value of Randomization Interval field in the Measurement Request element (see 11.11.3) then initiate the FTM procedure with at least Minimum AP Count â€“ Csub remaining listed APs. The 1729 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications responding STA should initiate the FTM procedure with the remaining listed APs until either the responding STA has successfully measured the range between the responding STA with at least Minimum AP Count APs or has attempted the FTM procedure with all remaining listed APs. For each FTM procedure that is attempted with a remaining listed AP without success, the responding STA shall record an error entry. For procedures related to listed APs that operate on non-operating channels, see 11.11.2. The responding STA shall transform the measurements obtained from each FTM procedure with an AP into a range and a maximum error between itself and the AP, while accounting for any clock offsets between the responding STA and the AP. At the completion of all of the FTM procedures and transformations, the responding STA shall send the all computed range information between itself and other APs, and all error entries, to the requesting STA using a Measurement Report element with Measurement Type field set to Fine Timing Measurement Range in a Measurement Report frame. A requesting STA may request a single set of range measurements by setting the Number of Repetitions field to 0 in the Measurement Request frame, or request a regular sequence of range measurements by â€” setting the Number of Repetitions field greater than 0 in the Measurement Request frame, and â€” including a Measurement Request element with Measurement Type field equal to Fine Timing Measurement Range and a Measurement Request element with Measurement Type field equal to Measurement Pause (see 11.11.9.7). 11.11.10 Usage of the neighbor report 11.11.10.1 General A neighbor report is sent by an AP and it contains information on neighboring APs that are members of ESSs requested in the neighbor report request. A neighbor report might not be exhaustive either by choice, or due to the fact that there might be neighbor APs not known to the AP. The neighbor report contents are derived from the NeighborListSet parameter of the MLME-NEIGHBORREPRESP.request primitive. The mechanism by which the contents of this table are determined is outside the scope of this standard, but it may include information from measurement reports received from the STAs within the BSS, information obtained via a management interface, or the DS. NOTEâ€”The purpose of the neighbor report is to enable the STA to optimize aspects of neighbor service set transition and ESS operation. A Neighbor Report element contains information on APs that the STA might use as candidates for a service set transition. Since the information in the neighbor report might be stale, it is advisory; information obtained by the report recipient through a scan or other sources might also be considered, possibly overriding information in the neighbor report. For example, where information contained within a neighbor report is contradicted by information in a Measurement Pilot, Beacon, or Probe Response frame, that response information needs to take precedence. An AP in which dot11RMNeighborReportActivated is false shall not transmit a Fine Timing Measurement Range request. An AP in which dot11RMNeighborReportActivated is false should not transmit a Measurement Request with the Measurement Type field equal to LCI and the Location Subject field of the LCI request set to Location Subject Remote. 11.11.10.2 Requesting a neighbor report A STA requesting a neighbor report from an AP shall send a Neighbor Report Request frame to its associated AP. A STA can request LCI information of an AP and its neighboring APs, if the AP advertises the FTM responder capability (Extended Capabilities element with the Fine Timing Measurement Responder field set to 1), the geospatial location capability (Extended Capabilities element with the Geospatial Location field set to 1), and the neighbor report capability (RM Enabled Capabilities element with the Neighbor Report 1730 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Capability Enabled field set to 1). A STA can request Civic Location information of an AP and its neighboring APs, if the AP advertises the FTM responder capability (Extended Capabilities element with the Fine Timing Measurement Responder field set to 1), the location civic capability (Extended Capabilities element with the Civic Location field set to 1), and the neighbor report capability (RM Enabled Capabilities element with the Neighbor Report Capability Enabled field set to 1). To request the LCI of neighboring APs, the STA shall transmit a Neighbor Report Request frame that includes a Measurement Request element with the value of its Measurement Type field equal to LCI. To request the location civic of neighboring APs, the STA shall transmit a Neighbor Report Request frame that includes a Measurement Request element with the value of its Measurement Type field equal to Location Civic. 11.11.10.3 Responding to a neighbor report request If dot11RMNeighborReportActivated is true, an AP receiving a neighbor report request shall respond with a Neighbor Report Response frame containing zero or more Neighbor Report elements. If an SSID element is specified in the corresponding Neighbor Report Request frame, the Neighbor Report element(s) shall contain information only concerning neighbor APs that are members of the current ESS identified by the SSID element contained within the neighbor report request. If the SSID element is omitted, the Neighbor Report element(s) shall contain information concerning neighbor APs that belong to the same ESS as the requesting STA. If the wildcard SSID element is specified in the corresponding Neighbor Request frame, the Neighbor Report element(s) shall contain information concerning all neighbor APs. If there are no neighbor APs available, the AP shall send a Neighbor Report Response frame with no Neighbor Report elements. If dot11RMNeighborReportActivated is true and dot11FineTimingMsmtRespActivated is true, an AP receiving a neighbor report request shall respond with a Neighbor Report Response frame containing one or more Neighbor Report elements. If dot11RMNeighborReportActivated is false in an AP receiving a neighbor report request, it shall ignore the request. A serving AP shall include a TSF subelement in the Neighbor Report element if it is able to guarantee an accumulated error of 1.5 TU or better on the TSF Offset subfield. Otherwise, the AP shall not include a TSF subelement in the Neighbor Report element. When the SSID element is omitted, the SSID element is specified by the wildcard SSID, or the SSID element is present and indicates the APâ€™s own SSID and either of the following is true: â€” An AP that has both dot11FineTimingMsmtRespActivated and dot11RMLCIConfigured equal to true receives a Measurement Request element with Measurement Type field equal to LCI. â€” An AP that has both dot11FineTimingMsmtRespActivated and dot11RMCivicConfigured equal to true receives a Measurement Request element with Measurement Type field equal to Location Civic. within a Neighbor Report Request frame then the AP shall include a Neighbor Report element for the APâ€™s own BSSID in the Neighbor Report Response frame (i.e., in this case the Neighbor Report Response frame contains one or more Neighbor Report elements). If dot11RMLCIConfigured is equal to true, the Neighbor Report element shall include a Measurement Report subelement with the Measurement Type field equal to LCI. If dot11RMCivicConfigured is equal to true, the Neighbor Report element shall include a Measurement Report sub element with the Measurement Type field equal to Location Civic. When both of the following are true: â€” the SSID element specified in the Neighbor Report Request does not include the APâ€™s own SSID and an AP that has at least one of dot11FineTimingMsmtRespActivated and 1731 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11RMLCIConfigured equal to false receives a Measurement Request element with the Measurement Type field equal to LCI within a Neighbor Report Request frame â€” an AP that has at least one of dot11LciCivicInNeighborReport and dot11RMLCIConfigured equal to false receives a Neighbor Report Request frame then the AP shall not include a Neighbor Report element containing a Measurement Report subelement with the Measurement Type field set to LCI describing the reporting AP in the Neighbor Report Response frame. In this case the Neighbor Report Response frame contains zero or more Neighbor Report elements. When both of the following are true: â€” the SSID element specified in the Neighbor Report request does not include the APâ€™s own SSID and an AP that has at least one of dot11FineTimingMsmtRespActivated and dot11RMCivicConfigured equal to false receives a Measurement Request element with the Measurement Type field equal to Location Civic within a Neighbor Report Request frame â€” an AP that has at least one of dot11LciCivicInNeighborReport and dot11RMCivicConfigured equal to false receives a Neighbor Report Request frame then the AP shall not include a Neighbor Report element containing a Measurement Report subelement with Measurement Type set to Location Civic describing the reporting AP in the Neighbor Report Response frame (i.e., in this case the Neighbor Report Response frame contains zero or more Neighbor Report elements). In this case the Neighbor Report Response frame contains zero or more Neighbor Report elements. NOTEâ€”The Neighbor Report Response frame includes a list Neighbor Report elements one for each neighbor. The criteria for the selection of an AP as a neighbor AP is beyond the scope of this specification. The Neighbor Report Response frame shall also include a Neighbor Report element for each neighbor AP. When either of the following is true in a neighbor AP of the AP (reporting AP) that receives a Measurement Request element with the Measurement Type field equal to LCI within a Neighbor Report Request frame: â€” the neighbor AP has both FTM responder capability (Extended Capabilities element with the Fine Timing Measurement Responder field set to 1) and LCI measurement capability (RM Enabled Capabilities element with the LCI Measurement Capability Enabled field set to 1) â€” the reporting AP has dot11LciCivicInNeighborReport equal to true and the neighbor AP has LCI measurement capability (RM Enabled Capabilities element with the LCI Measurement Capability Enabled field set to 1) then the reporting AP shall include a Neighbor Report element in the Neighbor Report Response frame. In addition if the neighbor AP has Geospatial Location capability (Extended Capabilities element with the Geospatial Location field set to 1), the Neighbor Report element shall include a Measurement Report subelement with Measurement Type equal to LCI. If the maximum horizontal or vertical location error of the neighbor AP relative to a reference AP is known to the AP and this relative error is smaller than the absolute error indicated in the LCI subelement, then the AP may include a Relative Location Error subfield in the Measurement Report field. When either of the following is true in a neighbor AP of the AP (reporting AP) that receives a Measurement Request element with the Measurement Type equal to Location Civic within a Neighbor Report Request frame: â€” The neighbor AP has both FTM responder capability (Extended Capabilities element with the Fine Timing Measurement Responder field set to 1) and civic location measurement capability (RM Enabled Capabilities element with Civic Location Measurement Capability Enabled set to 1) â€” The reporting AP has dot11LciCivicInNeighborReport equal to true and the neighbor AP has civic location measurement capability (RM Enabled Capabilities element with Civic Location Measurement Capability Enabled set to 1) 1732 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications then the reporting AP shall include a Neighbor Report element in the Neighbor Report Response frame. In addition if the neighbor AP has Civic Location (Extended Capabilities element with the Civic Location field set to 1), the Neighbor Report element shall include a Measurement Report subelement with the Measurement Type field equal to Location Civic. Each Measurement Report subelement returned shall have the same Measurement Token value as in the Measurement Token field of the corresponding Measurement Request element, or if there is no corresponding Measurement Request then the Measurement Token value shall be set to 0. If an AP determines that the LCI and/or civic location of a neighboring AP changes, the AP may send an unsolicited Neighbor Report Response frame containing complete neighbor information including the updated neighboring AP location information. The Dialog Token field is set to 0 as defined in 9.6.7.7. A STA that receives an LCI report that contains a Usage Rules/Policy subelement shall process the LCI information in compliance with the retransmission and retention permissions in the Usage-rules subelement. The Wide Bandwidth Channel subelement shall not be included in the Neighbor Report element when either the HT Operation subelement or the VHT Operation subelement is included in the Neighbor Report element. A VHT AP in which dot11FineTimingMsmtRespActivated is true that transmits a Neighbor Report element containing an HT Operation subelement shall include a VHT Operation subelement in the Neighbor Report element. A non-DMG AP in which dot11FineTimingMsmtRespActivated is true that transmits a Neighbor Report element containing neither an HT Operation subelement nor a VHT Operation subelement shall include a Wide Bandwidth Channel subelement in the Neighbor Report element. 11.11.11 Link Measurement A STA may use a Link Measurement Request frame to request another STA to respond with a Link Measurement Report frame containing a TPC report element. If dot11RMLinkMeasurementActivated is true, a STA receiving a Link Measurement Request frame shall respond with a Link Measurement Report frame containing a TPC Report element indicating the power used to transmit the Link Measurement report. The Link Measurement report also contains antenna ID and signal quality (RCPI and RSNI). If dot11RMLinkMeasurementActivated is false in an AP or PCP receiving a Link Measurement Request, it shall ignore the request. 11.11.12 Measurement of the RPI histogram To compute RPI densities for an RPI Histogram report (see 9.4.2.22.4), the STA shall measure the received power level on the specified channel, as detected at the antenna connector, as a function of time over the measurement duration. The maximum tolerance of the received power measurements shall be Â± 5 dB. Furthermore, the received signal power measurement should be a monotonic function of the actual power at the antenna. The time resolution of the received power measurements is in microseconds. The received power measurements are converted to a sequence of RPI values by quantizing the measurements according to Table 9-108. The RPI densities are then computed for each of the eight possible RPI values using 255 D RPI RPI Density = --------------------------- 1024 D M 1733 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications where DRPI is the duration receiving at the specified RPI value ( s) DM is the measurement duration (TU). The sum of the RPI densities is approximately 255, but could be up to 262 because of rounding effects. 11.11.13 Operation of the Max Transmit Power field The maximum tolerance for the value reported in Max Transmit Power field shall be 5 dB. The value of the Max Transmit Power field shall be less than or equal to the Max Regulatory Power value for the current channel. 11.11.14 Multiple BSSID set A multiple BSSID set is characterized as follows: â€” All members of the set use a common operating class, channel, Channel Access Functions, and antenna connector. â€” The set has a maximum range of 2n for at least one n, where 1 n 46. â€” Members of the set have the same 48-n MSBs in their BSSIDs. â€” All BSSIDs within the multiple BSSID set are assigned in a way that they are not available as MAC addresses for STAs using a different operating class, channel or antenna connector. NOTEâ€”For example, if the APs within BSSs with BSSIDs 16, 17, and 27 share the operating class, channel and antenna connector, and the range of MAC addresses from 16â€“31 inclusive are not assigned to other STAs using a different antenna connector, then the BSSIDs 16, 17, and 27 are members of a multiple BSSID set. The set is described by n = 4 (2n = 16) with BSSIDs in the range 0x00000000001X. The set cannot be described by n = 8 for instance since at least one of the BSSIDs in the range 0x0000000000XX might be used as a BSSID by an AP that does not share the same operating class, channel, and antenna connector. When the multiple BSSID set contains two or more members, the transmission of Measurement Pilots is constrained as described in 11.11.15. A Multiple BSSID element, with or without optional subelements, indicates that all APs and PCPs within the indicated range of BSSIDs transmit using a common class, channel, and antenna connector. A single Beacon frame may contain elements for the multiple BSSID set members; see 11.1.3.8. 11.11.15 Measurement Pilot frame generation and usage 11.11.15.1 General The Measurement Pilot frame is a compact Action frame transmitted pseudo-periodically by an AP at a small interval relative to a Beacon Interval. The Measurement Pilot frame provides reduced information relative to a Beacon frame to allow for the required small interval. The purpose of the Measurement Pilot frame is to assist a STA with the following functions: â€” Rapid discovery of the existence of a BSS via passive scanning â€” Rapid collection of neighbor AP signal strength measurements via passive scanning â€” Enable transmission of a Probe Request frame A STAâ€™s dot11RMMeasurementPilotActivated determines the level of support for measurement pilot at the STA. Table 11-10 describes permitted values for dot11RMMeasurementPilotActivated and what they signify. 1734 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 11-10â€”Measurement pilot activated definition dot11RM- Device function MeasurementPilot Notes Activated AP and non-AP 0 If the STA is contained within an AP, it does not generate MPs and if STA the device is a non-AP STA, it ignores the MPs it receives AP and non-AP 1 If the STA is contained within an AP, it can transmit MPs, and if the STA device is a non-AP STA, it can receive the MPs and can use the information contained in MPs. Non-AP STA 2 The non-AP STA is making use of the MPs it receives or would receive if they were being transmitted. Non-AP STA 3â€“7 Reserved AP The AP is transmitting MPs and using the information contained in them, and the AP is actively transmitting MPs with MP interval set to a value within the range as shown below. MP Interval with respect to Beacon Interval: 2 > 3% and < 5% of Beacon Interval 3 5% and < 10% 4 10% and < 15% 5 15% and < 20% 6 20% and < 25% 7 25% and < 50% 11.11.15.2 Measurement Pilot frame generation by an AP The AP shall determine if it is a member of a multiple BSSID set with two or more members. If so, at most one AP of the multiple BSSID set shall have dot11RMMeasurementPilotActivated set to a value between 2 and 7. How this occurs is out of scope of this standard. If dot11RMMeasurementPilotActivated is between 2 and 7, the following statements apply: â€” If the AP is a member of a multiple BSSID set with two or more members, then the BSSIDs of all members of the multiple BSSID set shall be indicated in the Beacon and Probe Response frames by the Multiple BSSID subelement. â€” The AP shall maintain a Measurement Pilot frame generation function, which transmits Measurement Pilot frames at a basic rate according to dot11RMMeasurementPilotPeriod. â€” The AP defines a series of TMPTTs exactly dot11RMMeasurementPilotPeriod apart. A TMPTT arrives when the APâ€™s local TSF timer (in Âµs) modulo the Measurement Pilot Interval equals 0. â€” At each TMPTT, the AP shall schedule a Measurement Pilot frame as the next frame for transmission ahead of other queued frames using the AC_VO EDCA parameters unless the TMPTT satisfies: T MPP T MPP TBTT â€“ ------------ TMPTT TBTT + ------------ 2 2 where TMPP is dot11RMMeasurementPilotPeriod, for any TBTT of members of the multiple BSSID set, in which case the AP shall not generate the Measurement Pilot. This is illustrated in 1735 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Figure 11-28. How the AP determines the TBTTs of members of the multiple BSSID set is out of scope of this standard. TBTT of Multiple BSSID Set member #1 TBTT of Multiple BSSID Set member #2 TBTT of Multiple BSSID Set member #3 TMPTT of Multiple BSSID Set member Allowed Measurement Pilot transmissions Figure 11-28â€”Example of Measurement Pilot frame scheduling In case the medium is determined by the carrier-sense mechanism (see 10.3.2.1) to be unavailable at the TMPTT, the AP shall delay the actual transmission of a Measurement Pilot frame according to the basic medium access rules specified in Clause 10 for a maximum period of one dot11RMMea- surementPilotPeriod and drop the delayed Measurement Pilot frame at the next TMPTT. In this way, a continuously busy medium causes multiple successive Measurement Pilots to be delayed, then dropped. An AP shall transmit Measurement Pilots to the broadcast address. An AP shall not retransmit or buffer Measurement Pilots as part of the PSP mechanisms. â€” If the AP is a member of a multiple BSSID set with two or more members, then the BSSIDs of all members of the multiple BSSID set shall be indicated in the Measurement Pilot frame using the Multiple BSSID subelement. NOTE 1â€”APs are advised to enable Measurement Pilots judiciously due to the possibility of excessive medium time being consumed by Measurement Pilots from multiple overlapping APs. For instance dot11RMMeasurementPilotTransmissionInformationActivated might be set to false: a) When enabling Measurement Pilots would cause: 1) More than 10% of the medium time at the AP to be consumed by beacons and Measurement Pilots transmitted by any source, or 2) More than 5% of the medium time at the AP to be consumed by Measurement Pilots transmitted by any source. b) When STAs are not expected to be using Measurement Pilots. How this is determined is out of the scope of this standard, but may depend upon many STAs setting the Measurement Pilot Capability field in the RM Enabled Capabilities element to 0 or 1 upon association at any member of the multiple BSSID set recently or at similar times in the past. c) When all members of the multiple BSSID set are within ESSs that contain one BSS only. d) When the APâ€™s operating regulatory domain is not subject to DFS regulations. e) When the APâ€™s operating regulatory domain is subject to DFS regulations but compliance with the regulations is impaired by Measurement Pilots. f) When the number of channels valid for the APâ€™s operating regulatory domain or frequency band is small. g) When no members of the multiple BSSID set are located at ingress or egress points of an ESS, so are less useful for roaming between an IEEE 802.11 ESS and other networks. NOTE 2â€”For efficient use of the medium, it is recommended that Measurement Pilots not be sent using a PHY specified in Clause 15 or Clause 16. An AP that is not extended spectrum management capable shall not include a Wide Bandwidth Channel Switch subelement in a Measurement Pilot frame. If the Wide Bandwidth Channel Switch subelement is included in a Measurement Pilot frame, then the Operating Class shall include a 40 MHz channel spacing. 1736 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.11.15.3 Measurement pilot usage by a STA Whenever testing a requested BSSID for equality against the BSSID of a Measurement Pilot, the following statements apply: â€” If the Measurement Pilot frame does not contain the Multiple BSSID element, then equality shall be true if the requested BSSID equals the BSSID of the Measurement Pilot frame, and otherwise false. â€” If the Measurement Pilot frame contains the Multiple BSSID element, and the requested BSSID is a non-wildcard BSSID, then equality shall be true if the requested BSSID equals any BSSID indicated by the Multiple BSSID element present in the Measurement Pilot, and otherwise false. â€” If the Measurement Pilot frame contains the Multiple BSSID element, and the requested BSSID is the wildcard BSSID, then equality shall be true. NOTEâ€”STAs are advised that due to considerations such as those noted in the prior subclause, APs might not transmit Measurement Pilots at all times or in all bands. 11.11.16 Access Delay Measurement Access delay is measured by the APâ€™s or PCPâ€™s MAC layer being the average medium access delay for transmitted frames measured from the time the MPDU is ready for transmission (i.e., begins CSMA/CA access or SP access, as appropriate) until the actual frame transmission start time. Access delay measurement results are included in the BSS Average Delay element and in the BSS AC Access Delay element. For the BSS Average Delay measurement, the AP or PCP shall measure and average the medium access delay for all transmit frames using the DCF or EDCAF over a continuous 30 s measurement window. For the infrastructure BSS AC Access Delay measurement, the QoS AP or PCP shall measure and average the medium access delay for all transmit frames of the indicated AC (see Figure 9-308) using EDCA mechanism over a continuous 30 s measurement window. The accuracy for the average medium access delay shall be Â± 100 Âµs or better when averaged over at least 200 frames. Accuracy is not defined for measurements averaged over less than 200 frames. 11.11.17 BSS Available Admission Capacity BSS Available Admission Capacity provides a means for an AP to advertise admission capacity available for explicit admission control in any UP or AC. This information may assist STAs in making service set transition decisions. The transmitted BSS Available Admission Capacity value represents a proportion of time on the wireless medium scaled linearly in units of 32 Âµs/s from 0 (0% available time) to 31 250 (100% available time). If an AP transmits a BSS Load element, the values for any transmitted BSS Available Admission Capacity values shall be less than or equal to the Available Admission Capacity field value of the BSS Load value. If an AP transmits a BSS Available Admission Capacity element, the transmitted values should be current or recently calculated. The AP recalculates Available Admission Capacity values according to local policy. An Available Admission Capacity value of 0 transmitted in the BSS Available Admission Capacity element indicates that no admission capacity is available at the calculation time and that no explicit admissions can be granted by the AP for that UP or AC unless additional capacity becomes available. An AP that receives a TSPEC admission request for total medium time (in both directions, if applicable) that is less than or equal to the current available admission capacity for the requested UP or AC local policy may apply additional local policy before admitting the requested TSPEC. NOTE 1â€”Available Admission Capacity values are dynamic in a BSS and the transmitted values cannot always reflect the actual values currently used by the AP for explicit admission control. Thus an AP should recalculate the Available Admission Capacity values regularly or after changes in the environment or the admitted capacity. NOTE 2â€”STAs are advised that requesting admission for any TSPEC at an UP or AC that requires more medium time than is reported as available for the requested UP or AC is possible yet unlikely to be successful. 1737 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.11.18 AP Channel Report The AP Channel Report element contains a list of channels in an operating class where a STA is likely to receive the Beacon or Probe Response frames sent by an AP, excluding the AP transmitting the AP Channel report. An AP Channel Report element only includes channels that are valid for the regulatory domain in which the AP transmitting the element is operating and consistent with the Country element in the frame in which it appears. One AP Channel Report element is included in the Beacon frame for each regulatory domain, which includes channels on which a STA is likely to receive the Beacon or Probe Response frames sent by an AP. The contents of the AP Channel Report elements may be compiled from the list of unique operating/channel pairs found in the neighbor report. The contents of the AP channel report may be configured or obtained by other means beyond the scope of this standard. 11.11.19 Multicast diagnostic reporting Multicast diagnostic reporting enables an AP to collect statistics on group addressed traffic at associated STAs. The method an AP uses to determine the multicast groups to which an associated STA is a member of is outside the scope of the standard and is typically performed by higher layer protocols. The Multicast Diagnostic request and Multicast Diagnostic report are defined in 9.4.2.21.13 and 9.4.2.22.12, respectively. A STA whose dot11MulticastDiagnosticsActivated is true shall support multicast diagnostics reporting and shall set to 1 the Multicast Diagnostics field of the Extended Capabilities elements that it transmits. When the Multicast Diagnostics field in the Extended Capabilities field is 1, the Incapable bit in the Measurement Report Mode field of a Multicast Diagnostic report shall not be set to 1. Multicast diagnostic reporting may use the triggered autonomous reporting capability described in 11.11.8. The Measurement Start Time field of a triggered diagnostic report shall contain the value of the STA TSF Timer at the time the trigger condition started to occur to an accuracy of Â±1 TU. An AP may send a Multicast Diagnostic request consisting of one or more Multicast Diagnostic requests in a Radio Measurement Request frame to a non-AP STA that has indicated support of the multicast diagnostic capability or to a multicast group address if all associated non-AP STAs support the multicast diagnostic capability. If the STA accepts the request it shall count the number of received MSDUs with the specified group address and the STA shall record the maximum observed PHY data rate of the frames that contained these MSDUs during the requested Measurement Duration. These two values shall be returned in a Multicast Diagnostic report in a Radio Measurement Report frame, as defined in 9.4.2.22.12. A non-AP STA shall not transmit a Radio Measurement Request frame containing a Multicast Diagnostic request. A STA shall not respond to a Radio Measurement Request frame containing a Multicast Diagnostic request received from a STA other than the AP with which it is associated. An AP may request that triggered multicast diagnostic reporting be enabled at associated non-AP STAs that have indicated support of the multicast diagnostic capability. To enable multicast diagnostic reporting, the AP shall send a Measurement Request element containing the Request Type field set to Multicast Diagnostics and with the Enable and Report bits set to 1 within a Radio Measurement Request frame. See 11.11.8. For triggered multicast diagnostic reporting, the Multicast MAC Address and trigger conditions for diagnostic reporting shall be specified in the request. Multicast diagnostic reporting may be requested for broadcast traffic by setting the Multicast MAC Address field to the broadcast address. A non-AP STA accepting a request for triggered multicast diagnostic reporting shall send a Multicast Diagnostics report to the requesting STA if the specified trigger condition occurs. The measuring non-AP 1738 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STA shall not send further triggered Multicast Diagnostics reports until the period specified in the Reactivation Delay field in the Multicast Diagnostic Request has expired, or the non-AP STA receives a revised trigger condition from a Multicast Diagnostic Request. To prevent generation of too many triggered reports, the minimum value of the Reactivation Delay field shall be set to a value greater or equal to A STAâ€™s MinTriggerTimeout. Once accepted, Multicast Diagnostic reporting continues to be active for the specified Multicast MAC address until one of the following occurs: â€” The STA receives a Measurement Request element containing a Multicast Diagnostic Request Type and with the Enable bit equal to 1 and the Report bits equal to 0 within a Radio Measurement Request frame. â€” Receipt of a Measurement Request element containing a Multicast Diagnostic Request Type, with the Enable and Report bits equal to 1, but with no trigger conditions. â€” The STA leaves the Multicast Group or disassociates. â€” The STA sends a Measurement Report element with the Measurement Result bit set to 1. The STA shall maintain an inactivity timer for every multicast diagnostic request accepted by the STA in which the Inactivity Timeout Request field is 1. When a timeout of the inactivity timer is detected, the STA shall send a multicast diagnostic report with the inactivity Timeout Trigger field in the Multicast Reporting Reason field set to 1. The inactivity timer at a recipient is reset when MSDUs corresponding to the monitored group address are received. A STA that declines a request for triggered multicast diagnostic reporting sends a Measurement Report element (as described in 9.4.2.22) in a Radio Measurement Report frame (as described in 9.6.2.3) with the Measurement Report Mode field set appropriately to indicate the reason for a failed or rejected request. 11.11.20 CCA request and report The response to a CCA request is a CCA report. A STA may support the generation of a CCA report. A STA may generate a CCA report in response to a CCA request. 11.11.21 RPI Histogram request and report The response to an RPI Histogram request is an RPI histogram report. A STA may support the generation of an RPI histogram. A STA may generate an RPI histogram report in response to an RPI Histogram request. 11.12 DSE procedures 11.12.1 General Regulations that apply to the U.S. 3650 MHz band require enabling STAs to implement a mechanism to enable mobile and portable STA operation. Similar regulations exist in other regulatory domains. This standard describes such a mechanism, referred to as dependent STA enablement (DSE). Subclause 11.12 describes DSE procedures that can be used to satisfy the U.S. 3650 MHz band and similar regulatory requirements. Regulations that apply to the U.S. 3650 MHz band require fixed STAs and enabling STAs to have their operating locations registered. Licensees with STAs suffering or causing harmful interference are expected to cooperate and resolve problems by mutually satisfactory arrangements. The DSE procedures provide the location of the enabling STA and unique identifiers to assist licensees in the resolution of interference issues. The DSE procedures might also satisfy needs in other frequency bands and be useful for other purposes. 1739 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A STA shall use the DSE procedures defined in this subclause if dot11LCIDSERequired is true. dot11DSERequired and dot11ExtendedChannelSwitchActivated shall be true when regulatory authorities require DSE, with the following exceptions: dot11DSERequired shall be set to false to configure STAs to operate as registered STAs, and dot11ExtendedChannelSwitchActivated may be set to false when operating as a fixed STA. A summary of STA attributes and these MIB attributes are shown in Table 11-11. Table 11-11â€”DSE STA attributes dot11Extended Registered dot11LCIDSERequired and dot11DSERe Type of STA ChannelSwitch STA dot11LCIDSEImplemented quired Activated Fixed STA Yes true true or false false Enabling STA Yes true true false Dependent STA No true true true A fixed STA is a registered STA that broadcasts its registered location and is restricted from enabling other STAs (see 11.12.3). An enabling STA is a registered STA that broadcasts its registered location, and regulatory authorities permit it to enable operation of unregistered STAs (see 11.12.4). A dependent STA is an unregistered STA that operates under the control of an enabling STA (see 11.12.5). When management frame protection is negotiated, stations shall use Protected Dual of Public Action frames instead of individually addressed Public Action frames for DSE procedures. The DSE procedures provide for the following: â€” Registered STA operation â€” Creation of a DSE service area for dependent STA operation â€” Dependent STA operation with DSE 11.12.2 Enablement and deenablement 11.12.2.1 General This subclause describes the procedures used for IEEE 802.11 enablement and deenablement. A STA keeps a state variable for each STA with which enablement communication is needed: â€” Enablement state with a value of unenabled or â€” Enablement state with a value of enabled NOTEâ€”Refer to 11.12.5 for description of dependent STA operation in either enablement state. Enablement utilizes a two-frame transaction sequence. The first frame asserts identity and requests enablement. The second frame returns the enablement result. In the description in 11.12.2.2 and 11.12.2.3, the STA initiating the enablement is referred to as enablement requester, and the STA to which the initial frame in the exchange is addressed is referred to as enablement responder. The specific items in each of the frames described in the following subclauses are defined in 9.6.8.4 and 9.6.8.5. An enabling STA may decline to enable a requesting STA. If the result is â€œsuccessful,â€ the requesting STA shall be enabled. Deenablement utilizes a one-frame transaction sequence. In the description in 11.12.2.4 and 11.12.2.5, the STA initiating the deenablement is referred to as deenablement requester, and the STA to which the frame is addressed is referred to as deenablement responder. 1740 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.12.2.2 Enablement requester STA Upon receipt of an MLME-ENABLEMENT.request primitive, the enablement requester STA shall perform the following procedure: a) Construct and transmit a DSE Enablement frame requesting enablement. 1) Specific information items in the enablement frame are as follows. i) STA identity assertion (in RequesterSTAAddress) ii) Enabling STA identity assertion (in ResponderSTAAddress) iii) Reason result code = 2 iv) Enablement identifier = 0 2) Specific items in the enablement frame sent by the enablement responder STA are described in 11.12.2.3. b) On receipt of a matching DSE Enablement frame (i.e., the Requester STA Address and Responder STA Address match the pending request) that acknowledges the DSE Enablement frame, issue an MLME-ENABLEMENT.confirm primitive to inform the SME of the result of the enablement. 1) The primitive may contain information from an DSE Enablement frame received from the enabling STA (see 11.12.2.3), or it may be issued for another reason (see 9.6.8.4). 2) The reason result code in the enablement confirmation frame indicates when the enablement is successful. 3) If the enablement was successful, the enablement state variable for the enablement responder STA shall be set to Enabled. c) If no matching DSE Enablement frame is received for the DSE Enablement frame within a period of EnablementTimeLimit TUs measured from the receipt of the MLME-ENABLEMENT.request primitive, issue an MLME-ENABLEMENT.confirm primitive with ResultCode set to TIMEOUT. 11.12.2.3 Enablement responder STA Upon receipt of a Public Action DSE Enablement frame with a reason result code of 2, the enablement responder STA may enable the enablement requester STA using the following procedure: a) Create and transmit a response frame with the enablement status as defined in 9.6.8.4 set in the Reason Result Code field and with a dependent enablement identifier chosen to be unique among all dependent enablement identifiers that have been assigned if enablement was successful. The enablement responder shall transmit the ResultCode parameter from the .confirm primitive mapped as specified in Table 9-310 of 9.6.8.4 to indicate the result of the enablement request. 1) Specific information items in the enablement frame response are as follows: i) STA identity assertion (in RequesterSTAAddress) ii) Enabling STA identity assertion (in ResponderSTAAddress) iii) The result of the requested enablement as defined in 9.6.8.4 iv) Enablement identifier b) Issue an MLME-ENABLEMENT.indication primitive to inform the SME of the enablement. 1) If the enablement is successful, the enablement state variable for the enablement requester STA shall be set to Enabled. 11.12.2.4 Deenablement requester STA Upon receipt of an MLME-DEENABLEMENT.request primitive, the deenablement requester STA shall create and transmit a DSE Deenablement frame to the deenablement responder STA. Specific information items in the deenablement frame are as follows: a) Enabling STA identity assertion (in RequesterSTAAddress) 1741 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications b) STA identity assertion (in ResponderSTAAddress) c) Reason result code = 2 11.12.2.5 Deenablement responder STA Upon receipt of a DSE Deenablement frame, the deenablement responder STA shall deenable with the deenablement requester STA by issuing an MLME-DEENABLEMENT.indication primitive to inform the SME of the deenablement. The enablement state variable for the deenablement requester STA shall be set to Unenabled. 11.12.3 Registered STA operation A registered STA shall have dot11DSERequired equal to false. They shall transmit the DSE Registered Location element in every Beacon frame and shall set the Dependent STA bit in the DSE Registered Location element to 0. If the registered STA is located within a national policy area, such as a Fixed Satellite Service exclusion zone, or within an international agreement area near a national border, the RegLoc Agreement bit in the DSE Registered Location element shall be set to 1, signifying to other STAs that additional restrictions on STAs with directional antennas may apply; otherwise, it shall be set to 0. The Latitude, Longitude, and Altitude fields of the DSE Registered Location element shall be reported at their best known resolutions, which might exceed the resolutions required by regulatory authorities. The Altitude Type field value shall be 3 (i.e., height above ground is in meters or, in other words, the altitude is in meters above adjacent terrain), unless another altitude type is required for operation in the regulatory domain. The Datum field value shall be 1 (World Geodetic System 1984), unless another datum is required for operation in the regulatory domain. An enabling STA is a registered STA that broadcasts its registered location, and regulatory authorities permit it to enable operation of unregistered STAs (see 11.12.4). A dependent STA is an unregistered STA that operates under the control of an enabling STA (see 11.12.5). A fixed STA is a registered STA that broadcasts its registered location and is restricted from enabling other STAs. A fixed STA shall have dot11LCIDSERequired set to true, and dot11ExtendedChannelSwitchActivated may be true or false. A fixed STA shall set dot11RegLocDSE to false and the RegLoc DSE bit in the DSE Registered Location element to 0, signifying that it is not creating a DSE service area. A fixed STA may operate in an infrastructure BSS or IBSS. A registered STA that is not an enabling STA may operate as an AP and relay Public Action frames (specifically, DSE Enablement, DSE Deenablement, DSE Measurement Request, DSE Measurement Report, DSE Power Constraint) from a dependent STA to its enabling STA. The specification of the algorithm by which Public Action frames are relayed is beyond the scope of this standard. Note that the enabling signal is not a Public Action frame and is not relayed (see 11.12.4). 11.12.4 Enabling STA operation with DSE A registered STA may create and manage a DSE service area for dependent STA operation where regulatory requirements permit. A registered STA operating in this manner is referred to as an enabling STA. An enabling STA sets dot11RegLocDSE to true and signifies the creation of a DSE service area by setting the RegLoc DSE bit in the DSE Registered Location element to 1. Dependent STA transmission of any frames is conditional on receiving directly over the air and decoding a DSE Registered Location element with RegLoc DSE bit equal to 1, sent from an enabling STA. Before attempting enablement with any one enabling STA, a dependent STA may have detected several enabling STAs, may attempt enablement with one and fail, and then attempt enablement with another. An enabling STA shall assign dependent enablement identifiers in a way that makes them unique among STAs enabled by this enabling STA to help identify sources of interference. 1742 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications An enabling STA may issue a DSE measurement request to any of its dependent STAs in order to receive a DSE measurement report that may have reported DSE LCI fields received from nearby STAs. The licensed operator may be able to use these reports to identify interfering STAs or map overlapping coverage in a multiple BSS situation. Because reported DSE LCI fields may refer to any destination address, a single DSE report may contain elements received from STAs that are not yet associated with a BSS. An enabling STA may issue an ECS announcement to any of its dependent STAs in order to have their radio operation changed in frequency, channel bandwidth, and other operational parameters. A dependent AP or DFS owner with dot11DSERequired true and receiving an ECS announcement from its enabling STA shall perform the extended channel switching procedure as specified in 11.10. An enabling STA may issue a DSE power constraint announcement to any of its dependent STAs in order to have their transmit power reduced from the regulatory limit. A dependent AP or DFS owner with dot11DSERequired true and receiving a DSE power constraint announcement from its enabling STA shall perform the power constraint procedure as specified in 11.12.5. 11.12.5 Dependent STA operation with DSE A dependent STA shall set dot11DSERequired to true. A typical state machine implementation of dependent STA operation with DSE is provided in Figure 11-29. Unenabled Enablement attempt failed Wait Enabling frame received dot11EnablementFailHoldTime Becoming enabled Failed enablement within dot11DSEEnablementTimeLimit Receive DSE(MDR) Deenablement frame from the enabling STA with which it is attempting to become enabled Become enabled within dot11DSEEnablementTimeLimit Enabled Receive DSE(MDR) Deenablement frame from the enabling STA with which it is enabled Failure to receive Enabling Signal from the enabling STA with which it is enabled within dot11DSERenewalTime Figure 11-29â€”Dependent STA state machine 1743 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications For DSE, the following statements apply: â€” A STA with dot11DSERequired true shall not transmit any frames unless it has received a Beacon frame from an enabling STA with the Spectrum Management bit equal to 1 in the Capability Information field and with the RegLocDSE bit equal to 1 in the DSE Registered Location element. A dependent STA that is not enabled shall not transmit, except to attain enablement with an enabling STA, unless such action is mandated to be allowed in the regulatory domain (e.g., emergency services). â€” A dependent STA shall not attempt enablement with an enabling STA unless the enabling STA is transmitting Beacon frames with the RegLoc DSE bit equal to 1 in the DSE Registered Location element. â€” A dependent STA creates a dependent DSE Registered Location element containing the enabling STAâ€™s DSE Registered Location element and having the RegLoc DSE bit set to 0 and the Dependent STA bit set to 1. Before enablement, the Dependent Enablement Identifier field shall be set to 0. Upon attaining enablement, the Dependent Enablement Identifier field shall be set to the dependent enablement identifier value received by the dependent STA from the enabling STA in the MLME- ENABLEMENT.response primitive. â€” The dependent STA shall send a Public Action DSE Registered Location Announcement frame to the broadcast address whenever the sum of dot11TransmittedFragmentCount, dot11GroupTransmittedFrameCount, and dot11ReceivedFragmentCount, modulo dot11DSETransmitDivisor equals 0, possibly delayed by the completion of the sending of the frames of the current MSDU or MMPDU or by the completion of the current transmission opportunity (TXOP). â€” A dependent STA that has not attained enablement shall not transmit beyond dot11DSEEnablement- TimeLimit (in seconds), measured from the time of the first PHY-TXSTART.request primitive, while attempting to attain enablement. Then if it is not enabled, it shall not transmit for dot11DSEEnablementFailHoldTime (in seconds), before it again attempts to attain enablement. â€” A dependent STA receiving a DSE Deenablement frame with the RequesterSTAAddress field matching the enabling STA with which it last attempted enablement and the ResponderSTAAddress field matching its own IEEE MAC address shall change its enablement state with the enabling STA to unenabled and set all fields of its DSE Registered Location Information field (see 9.4.2.52) to 0. â€” A dependent STA shall return a DSE measurement report in response to a DSE measurement request if the request is received from the AP with which it is associated or the enabling STA with which it last attempted enablement and the ResponderSTAAddress field matches its own IEEE MAC address. The result may be the completed measurement or an indication that the STA is unable to complete the measurement request. A STA shall report it is too late to undertake a measurement request if it receives the request after the specified starting time for the measurement. The Measurement Report Mode field of a frame that is sent in response to a DSE Measurement Request frame shall not contain a value of 1 for the Incapable subfield and shall not contain a value of 1 for the Refused subfield of the Measurement Report Mode field of the DSE measurement report. â€” A dependent STA receiving an ECS frame from the enabling STA with which it last attempted enablement or an ECS element from the AP with which it is associated shall perform the ECS procedure (see 11.10.3). â€” A dependent STA receiving a DSE Power Constraint frame with the RequesterSTAAddress field matching the enabling STA with which it last attempted enablement and the ResponderSTAAddress field matching its own IEEE MAC address shall constrain its transmit power to be less than or equal to the maximum transmit power level specified for the current channel in the Country element minus the local power constraint specified in the DSE Power Constraint frame. â€” An enabled dependent STA shall cease transmission within dot11DSERenewalTime (in seconds) if it has not received either a Beacon frame or a Probe Response frame from its enabling STA with the RegLoc DSE bit equal to 1 in the DSE Registered Location element. It shall then change its 1744 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications enablement state with the enabling STA to unenabled and set all fields of its DSE Registered Location Information field (see 9.4.2.52) to 0. 11.13 Group addressed robust management frame procedures When management frame protection is negotiated, the MLME shall provide an encapsulation service for group addressed robust Management frames. All group addressed robust Management frames shall be submitted to this service for encapsulation and transmission. For group addressed Management frames that are specified with â€œYesâ€ in the â€œGroup Addressed Privacyâ€ column of Table 9-47, the group addressed frame protection service shall take the following actions: â€” The frames shall be encapsulated and protected with the MGTK using the group cipher negotiated during the AMPE exchange. For all other group addressed Management frames, the group addressed frame protection service shall take the following actions: â€” Management frame protection for multicast/broadcast shall be set using the MLME- SETPROTECTION.request primitive with the Protectlist including a Key Type value of IGTK. A non-AP STA shall also set the Protect Type value to Rx. In an IBSS, a STA shall set the ProtectType value to Rx_Tx. An AP shall set the Protect Type value to Tx. â€” The IGTK shall be installed using the MLME-SETKEYS.request primitive with the value IGTK for the Key Type subfield in the Key Information field in the IEEE 802.11 Key Descriptor. â€” The frames shall be encapsulated and protected using BIP (see 12.5.4). 11.14 SA Query procedures If dot11RSNAProtectedManagementFramesActivated is true, then the STA shall support the SA Query procedure. To send an SA Query Request or SA Query Response frame to a peer STA, the SME shall issue an MLME- SA-QUERY.request or MLME-SA-QUERY.response primitive respectively. Reception of an SA Query Request or SA Query Response frame is signaled to the SME with an MLME-SA-QUERY.indication or MLME-SA-QUERY.confirm primitive respectively. A STA that supports the SA Query procedure and receives an SA Query Request frame shall respond with an SA Query Response frame unless either of the following are true: â€” the STA is not currently associated to the STA that sent the SA Query Request frame â€” the STA has sent a (Re)Association Request frame within dot11AssociationResponseTimeOut but has not received a corresponding (Re)Association Response frame NOTEâ€”A non-AP and non-PCP STA does not respond if it is trying to reassociate with the AP or PCP that sent the SA Query Request frame (since, except in the case of FT to the same AP, it no longer has the PTKSA) or to another AP or PCP (it could maintain the old association and PTKSA until the reassociation is completed). There is no such restriction for an AP or PCP. If a non-AP and non-PCP STA that has an SA with its AP or PCP for an association that negotiated management frame protection receives an unprotected Deauthentication or Disassociation frame with reason code INVALID_CLASS2_FRAME or INVALID_CLASS3_FRAME from the AP or PCP, the non-AP and non-PCP STA may use this as an indication that there might be a mismatch in the association state between itself and the AP or PCP. In such a case, the non-AP and non-PCP STAâ€™s SME may initiate the SA Query procedure with the AP or PCP to verify the validity of the SA by issuing one MLME-SA-QUERY.request primitive every dot11AssociationSAQueryRetryTimeout TUs until a matching 1745 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MLME-SA-QUERY.confirm primitive is received or dot11AssociationSAQueryMaximumTimeout TUs from the beginning of the SA Query procedure has passed. If the AP or PCP responds to the SA Query request with a valid SA Query response, the non-AP STA should continue to use the SA. If no valid SA Query response is received, the non-AP and non-PCP STAâ€™s SME may delete the SA and temporal keys held for communication with the STA by issuing an MLME-DELETEKEYS.request primitive and the non- AP and non-PCP STA may move into State 1 (or State 2, for a DMG STA) with the AP. 11.15 HT BSS Operation An HT STA that is creating or joining a BSS shall be able to receive and transmit at each of the MCS values listed in the Basic HT-MCS Set field of the HT Operation parameter of the MLME-START.request primitive or Basic HT-MCS Set field of the HT Operation parameter of the SelectedBSS parameter of the MLME-JOIN.request primitive. A STA that transmits a frame that contains both an HT Operation element and a DSSS Parameter Set element shall set the Primary Channel field in the HT Operation element to the same value as the Current Channel field in the DSSS Parameter Set element. 11.16 20/40 MHz BSS operation 11.16.1 Rules for operation in 20/40 MHz BSS The rules described in 11.16.1 through 11.16.12 are applicable to STAs that are either a STA 5G or a STA 2G4. A 40MC STA shall support 20/40 BSS coexistence management. NOTEâ€”A 40MC HT STA that transmits a frame containing an Extended Capabilities element sets the 20/40 BSS Coexistence Management Support field of this element to 1. An HT STA 2G4 that is a member of an IBSS and that transmits a frame containing an HT Operation element or Secondary Channel Offset element shall set the Secondary Channel Offset field of this element to SCN. 11.16.2 Basic 20/40 MHz BSS functionality An HT AP declares its channel width capability (20 MHz only or 20/40 MHz) in the Supported Channel Width Set subfield of the HT Capabilities element. An HT AP shall set the STA Channel Width field to 1 in frames in which it has set the Secondary Channel Offset field to SCA or SCB. An HT AP shall set the STA Channel Width field to 0 in frames in which it has set the Secondary Channel Offset field to SCN. A non-AP HT STA declares its channel width capability (non-40MC HT STA or 40MC HT STA) in the Supported Channel Width Set subfield in the HT Capabilities element. NOTE 1â€”A 20/40 MHz BSS might include any mixture of 40MC HT STAs, non-40MC HT STAs, and non-HT STAs. Protection requirements for mixed networks are defined in 10.26. NOTE 2â€”A non-AP HT STA can switch between 40MC HT STA and non-40MC HT STA operation by disassociation followed by association. An HT STA shall not indicate support for 40 MHz unless it supports reception and transmission of 40 MHz PPDUs using all MCSs within the Basic HT-MCS Set field of the HT Operation parameter of the MLME-START.request primitive or Basic HT-MCS Set field of the HT Operation parameter of the 1746 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications SelectedBSS parameter of the MLME-JOIN.request primitive and all MCSs that are mandatory for the attached PHY. An HT STA shall not transmit a 20 MHz PPDU containing one or more Data frames using the secondary channel of a 20/40 MHz BSSs. The Notify Channel Width frame may be used by a STA to notify another STA that the STA wishes to receive frames in the indicated channel width. An HT STA that is a member of an IBSS adopts the value of the Secondary Channel Offset field in received frames according to the rules in 11.1.5 and shall not transmit either of the following: â€” A value in the Secondary Channel Offset field that differs from the most recently adopted value â€” An operating class in the Extended Channel Switch Announcement frame or element with a different behavior than the currently adopted PrimaryChannelLowerBehavior or PrimaryChannelUpperBehavior 11.16.3 Channel scanning and selection methods for 20/40 MHz operation 11.16.3.1 General An HT STA shall set the following MIB attributes to true: dot11OperatingClassesImplemented, dot11OperatingClassesRequired, and dot11ExtendedChanneSwitchActivated. An AP operating a 20/40 MHz BSS, on detecting an OBSS whose primary channel is the APâ€™s secondary channel, switches to 20 MHz BSS operation and may subsequently move to a different channel or pair of channels. A DFS owner (DO) operating a 20/40 MHz IBSS, on detecting an OBSS whose primary channel is the DOâ€™s secondary channel, may choose to move to a different pair of channels. NOTEâ€”The setting up of a 40 MHz off-channel TDLS direct link is specified in 11.23.6.3. 11.16.3.2 Scanning requirements for a 20/40 MHz BSS Before an AP or DO starts a 20/40 MHz BSS, it shall perform a minimum of dot11BSSWidthChannelTransitionDelayFactor OBSS scans (see 11.16.5) to search for existing BSSs. If the AP or DO starts a 20/40 MHz BSS in the 5 GHz band and the BSS occupies the same two channels as any existing 20/40 MHz BSSs, then the AP or DO shall select a primary channel of the new BSS that is identical to the primary channel of the existing 20/40 MHz BSSs and a secondary channel of the new 20/40 MHz BSS that is identical to the secondary channel of the existing 20/40 MHz BSSs, unless the AP discovers that on these two channels are existing 20/40 MHz BSSs with different primary and secondary channels. If an AP or DO starts a 20/40 MHz BSS in the 5 GHz band, the selected secondary channel should correspond to a channel on which no beacons are detected during the dot11BSSWidthChannelTransition- DelayFactor OBSS scan time performed by the AP or DO, unless there are beacons detected on both the selected primary and secondary channels. NOTEâ€”The 20/40 MHz channel sets and their corresponding behavior limits (i.e., choice of primary and secondary channels) permissible in each operating class are defined in Annex E and Annex D, respectively. An HT AP or a DO that is also an HT STA should not start a 20 MHz BSS in the 5 GHz band on a channel that is the secondary channel of a 20/40 MHz BSS. The AP or DO may continue to periodically scan after the BSS has been started. Information obtained during such scans is used as described within this subclause and within 11.16.2. 1747 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications After starting a 20 MHz BSS, a 40MC HT AP 2G4 shall perform a minimum of dot11BSSWidthChannelTransitionDelayFactor OBSS scans, either by itself or through its associated STAs before making a transition from a 20 MHz BSS to a 20/40 MHz BSS. When the AP performs the scanning and the secondary channel for the 20/40 MHz BSS has been selected, then the scan shall be performed over the set of channels that are allowed operating channels within the current operational regulatory domain and whose center frequency falls within the affected frequency range given by Equation (11-1). When the AP performs the scanning without an intended secondary channel for the 20/40 MHz BSS or when the APâ€™s associated STA(s) perform the scanning, then the scan shall be performed on all channels in the frequency band. NOTEâ€”A 40MC HT AP can change from operating a 20 MHz BSS to a 20/40 MHz BSS while maintaining associations by making a change to the transmitted value of the Secondary Channel Offset field. fP + fS fP + fS affected frequency range = [ -------------- â€“ 25 MHz, -------------- + 25 MHz] (11-1) 2 2 where fP is the center frequency of channel P fS is the center frequency of channel S A 40MC HT AP 2G4 shall maintain a local boolean variable 20/40 Operation Permitted that can have either the value true or false. The initial value of 20/40 Operation Permitted shall be false. The value of 20/40 Operation Permitted is recomputed according to Equation (11-2) whenever a BSS channel width trigger event is detected or whenever a period of time has elapsed with no BSS channel width triggers being detected and no overlap being reported, as defined in 11.16.12. 20/40 Operation Permitted = (P == OPi for all values of i) AND (P == OTi for all values of i) AND (S == OSi for all values of i) (11-2) where P is the operating or intended primary channel of the 20/40 MHz BSS S is the operating or intended secondary channel of the 20/40 MHz BSS OPi is member i of the set of channels that are members of the channel set C and that are the primary operating channel of at least one 20/40 MHz BSS that was detected within the APâ€™s BSA during the previous dot11BSSWidthChannelTransitionDelayFactor Ã— dot11BSSWidthTriggerScanInterval seconds OSi is member i of the set of channels that are members of the channel set C and that are the secondary operating channel of at least one 20/40 MHz BSS that was detected within the APâ€™s BSA during the previous dot11BSSWidthChannelTransitionDelayFactor Ã— dot11BSSWidthTriggerScanInterval seconds OTi is member i of the set that comprises all channels that are members of the channel set C that were listed at least once in the Channel List fields of 20/40 BSS Intolerant Channel Report elements received during the previous dot11BSSWidthChannelTransitionDelayFactor Ã— dot11BSSWidthTriggerScanInterval seconds and all channels that are members of the channel set C and that are the primary operating channel of at least one 20 MHz BSS that was detected within the APâ€™s BSA during the previous dot11BSSWidthChannelTransitionDelayFactor Ã— dot11BSSWidthTriggerScanInterval seconds C is the set of all channels that are allowed operating channels within the current operational regulatory domain and whose center frequency falls within the affected frequency range given by Equation (11-1) If either side of â€œ==â€ above is the empty set or has a null value, then the expression is defined to have a boolean value of true. 1748 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A 40MC HT AP 2G4 shall not start a 20/40 MHz BSS in the 2.4 GHz band if the value of the local variable 20/40 Operation Permitted is false (see Equation (11-2)). A 40MC HT AP 2G4 may transmit a frame containing a Secondary Channel Offset field set to a value of SCA or SCB only if 20/40 Operation Permitted is true. In addition to information obtained by the 40MC HT AP 2G4 through its own scanning, a 40MC HT AP 2G4 shall use 20/40 BSS Intolerant Channel Report element information from received 20/40 BSS Coexistence Management frames with a value of the Address 1 field that matches the 40MC HT AP 2G4 using either individual or group addressing, but with no qualification of the Address 3 value, when determining if 20/40 Operation Permitted is true or false. The information from the Channel List fields of received 20/40 BSS Intolerant Channel Report elements is used in generating the OT set for Equation (11-2). After initial establishment of the 20/40 MHz BSS, if the value of 20/40 Operation Permitted becomes false, the 40MC HT AP 2G4 reverts to 20 MHz BSS operation (see 11.16.12). The 40MC HT AP 2G4 might subsequently move the BSS to a pair of channels where the value of 20/40 Operation Permitted evaluates to true. 11.16.3.3 Channel management at the AP and in an IBSS While operating a 20/40 MHz BSS, a DO or an AP may move its BSS, and an AP may switch the BSS to 20 MHz operation either alone or in combination with a channel move. These channel moving or BSS width switching operations might occur if, for example, another BSS starts to operate in either or both of the primary or secondary channels, or if radar is detected in either or both of the primary or secondary channels, or for other reasons that are beyond the scope of this standard. Specifically, the AP or DO may move its BSS to a different pair of channels, and the AP may separately, or in combination with the channel switch, change from a 20/40 MHz BSS to a 20 MHz BSS using either the primary channel of the previous channel pair or any other available 20 MHz channel. While operating a 20 MHz BSS, a DO or an AP may move its BSS, and an AP may switch the BSS to a 20/40 MHz BSS, either alone or in combination with a channel move. When switching a 20/40 MHz BSS to 20 MHz BSS mode, the AP may recalculate the TS bandwidth budget and may delete one or more active TSs by invoking the MLME-DELTS.request primitive with a ReasonCode value of SERVICE_CHANGE_PRECLUDES_TS. An AP switches between 20/40 MHz BSS and 20 MHz BSS as follows: â€” By changing the value of the Secondary Channel Offset field of the HT Operation element in the Beacon frame, and/or â€” By changing the value of the Secondary Channel Offset field of the Secondary Channel Offset element, and/or â€” Through the New Operating Class field of transmitted Extended Channel Switch Announcement elements. In order to maintain existing associations and/or minimize disruption to communications with other STAs while making a channel width change or while performing a channel pair relocation, an AP may inform HT STAs within its BSS that it is making the change by including an Extended Channel Switch Announcement element in Beacon, Probe Response, and Extended Channel Switch Announcement frame transmissions until the intended channel switch time. A DO may inform HT STAs within its BSS that it is performing a channel pair relocation by including an Extended Channel Switch Announcement element in Beacon, Probe Response, and Extended Channel Switch Announcement frame transmissions until the intended channel switch time. The New Channel Number field of the Extended Channel Switch Announcement element represents the new channel (when the BSS after relocation/width change will be a 20 MHz BSS) or the primary channel of the new pair of channels (when the BSS after relocation/width change will 1749 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications be a 20/40 MHz BSS). When changing to a new pair of channels, the New Operating Class field specifies the position of the secondary channel relative to the new primary channel, i.e., either above or below. When transmitting HT Operation elements, Channel Switch Announcement elements, and/or Extended Channel Switch Announcement elements, the AP moving the BSS or changing its channel width selects a combination of operating parameters from any single row of any one of the tables in Annex E that is appropriate for the current operating domain of the AP. Similarly, when transmitting HT Operation elements, Channel Switch Announcement elements, and/or Extended Channel Switch Announcement elements, the DO moving the BSS selects a combination of operating parameters from any single row of any one of the tables in Annex E that is appropriate for the current operating domain of the DO. The AP or DO selects one channel number from the â€œChannel setâ€ column of the selected row. The AP or DO includes the selected information in subsequently transmitted frames that contain any combination of the following four elements: â€” HT Operation element â€” Channel Switch Announcement element â€” Extended Channel Switch Announcement element â€” Secondary Channel Offset element The AP or DO shall set the Secondary Channel Offset field of transmitted HT Operation elements and transmitted Secondary Channel Offset elements to SCA if the Behavior limits set column of the selected row contains the value PrimaryChannelLowerBehavior. The AP or DO shall set the Secondary Channel Offset field of transmitted HT Operation elements and transmitted Secondary Channel Offset elements to SCB if the Behavior limits set column of the selected row contains the value PrimaryChannelUpperBehavior. The AP or DO shall set the Secondary Channel Offset field of transmitted HT Operation elements and transmitted Secondary Channel Offset elements to SCN if the Behavior limits set column of the selected row contains neither the value PrimaryChannelLowerBehavior nor the value PrimaryChannelUpperBehavior. The AP or DO shall set the New Channel Number field of transmitted Channel Switch Announcement elements and Extended Channel Switch Announcement elements to the value of the selected channel from the selected row. The AP or DO shall set the New Operating Class field of transmitted Extended Channel Switch Announcement elements to the value of the â€œOperating classâ€ column of the selected row. Movement of a 20/40 MHz BSS from one channel pair to a different channel pair and changing between 20 MHz and 20/40 MHz operation should be scheduled so that all STAs in the BSS, including STAs in power save mode, have the opportunity to receive at least one Extended Channel Switch Announcement element or Channel Switch Announcement element before the switch. When the Extended Channel Switch Announcement element and Extended Channel Switch Announcement frame are transmitted in bands where dot11SpectrumManagementRequired is true, the Channel Switch Announcement element and Channel Switch Announcement frame may also be transmitted. A STA that announces a channel switch using both the Extended Channel Switch Announcement element and the Channel Switch Announcement element shall set the New Channel Number field of both elements to the same value. An HT STA that receives a channel switch announcement through both the Extended Channel Switch Announcement element and the Channel Switch Announcement element ignores the received Channel Switch Announcement element; this is called a superseded Channel Switch Announcement element. For 20 MHz operation when the new operating class signifies 40 MHz channel spacing, the 20 MHz channel is the primary channel of the 40 MHz channel. 1750 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.16.4 40 MHz PPDU transmission restrictions 11.16.4.1 Fields used to determine 40 MHz PPDU transmission restrictions Several fields from various frames are used to convey information between STAs regarding the support for 40 MHz PPDU transmission and reception and regarding any current prohibition against the transmission and reception of 40 MHz PPDUs. The rules defined in 11.16.4.2, 11.16.4.3, and 11.16.4.4 describe the behavior that accompanies those fields. The fields that are used to determine the status of the transmission and reception of 40 MHz PPDUs are as follows: â€” The Supported Channel Width Set subfield of the HT Capabilities element â€” The Secondary Channel Offset field of the HT Operation element â€” The STA Channel Width field of the HT Operation element â€” The Channel Width field of the Notify Channel Width frame â€” The Extended Channel Switch Announcement element The Supported Channel Width Set subfield is used to indicate whether the transmitting STA is capable of transmitting and receiving 40 MHz PPDUs. NOTEâ€”The Supported Channel Width Set subfield transmitted by an AP is constant for the lifetime of its BSS as it is a parameter of the MLME-START.request primitive. In addition to the restrictions on transmission of 40 MHz mask PPDUs found in 11.16.4.1 through 11.16.4.4, if a STA operating in the 2.4 GHz industrial, scientific, and medical (ISM) band has no means of determining the presence of non-IEEE-802.11 communication devices operating in the area, then the STA shall not transmit any 40 MHz mask PPDUs. In addition to the restrictions on transmission of 40 MHz mask PPDUs found in 11.16.4.1 through 11.16.4.4, if a STA operating in the 2.4 GHz ISM band has a means of determining the presence of non-IEEE-802.11 communication devices operating in the area and determines either that no non- IEEE-802.11 communication device is operating in the area or that non-IEEE-802.11 communication devices are operating in the area but the STA implements a coexistence mechanism for these non- IEEE-802.11 communication devices, then the STA may transmit 40 MHz mask PPDUs; otherwise, the STA shall not transmit any 40 MHz mask PPDUs. 11.16.4.2 Infrastructure non-AP STA restrictions A STA that is associated with an AP shall not transmit a value in the Supported Channel Width Set subfield that differs from a previously transmitted value during its current association. The Secondary Channel Offset field is used to indicate whether the BSS is occupying a 40 MHz wide pair of channels and, when a secondary channel exists, whether it is above or below the primary channel in frequency. The Extended Channel Switch Announcement frame and the Extended Channel Switch Announcement element can each be used to indicate a transition from 20/40 MHz BSS operation to 20 MHz BSS operation and vice versa and to indicate whether a secondary channel, when it exists, is above or below the primary channel in frequency. A 40MC HT STA shall maintain a local boolean variable 40MHzOperatingClass as described here. The initial value of 40MHzOperatingClass shall be false. The value of 40MHzOperatingClass is recomputed according to the rules in this subclause at every TBTT and following the reception of a frame transmitted by the AP associated with the STA when that frame contains either of the following fields: 1751 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” Current Operating Class field â€” New Operating Class field The local boolean variable 40MHzOperatingClass becomes true upon reception of a frame transmitted by the associated AP if the frame contained a Current Operating Class field with a value that corresponds to an operating class that corresponds to a channel spacing value of 40 MHz, as specified in Annex E. The local boolean variable 40MHzOperatingClass becomes false upon reception of a frame transmitted by the associated AP if the frame contained a Current Operating Class field with a value that corresponds to an operating class that does not correspond to a channel spacing value of 40 MHz. The local boolean variable 40MHzOperatingClass becomes true at the nth TBTT following reception of a frame transmitted by the associated AP that contains an Extended Channel Switch Announcement element with a value of n in the Channel Switch Count field and a value in the New Operating Class field that corresponds to an operating class that corresponds to a channel spacing value of 40 MHz provided that the frame is the most recently received frame meeting the above conditions. The local boolean variable 40MHzOperatingClass becomes false at the nth TBTT following reception of a frame transmitted by the associated AP that contains an Extended Channel Switch Announcement element with a value of n in the Channel Switch Count field and a value in the New Operating Class field that corresponds to an operating class that does not correspond to a channel spacing value of 40 MHz provided that the frame is the most recently received frame meeting the above conditions. A STA can choose to dynamically constrain its operating channel width to 20 MHz while being a member of a 20/40 MHz BSS. Transitions to and from this constrained state are indicated using the transmission of a frame that carries the Channel Width field. A Channel Width field value of 0 indicates that the transmitting STA is not currently able to receive 40 MHz PPDUs, beginning at the end of the transmission of the frame that contained the Channel Width field. A STA shall not transmit a frame containing a STA Channel Width field or a Channel Width field set to 1 if the value of its Supported Channel Width Set subfield is 0. A STA that is associated with an infrastructure BSS (STA1) shall not transmit a 40 MHz PPDU containing one or more frames addressed to another STA (STA2) unless the following three conditions are true: â€” The Supported Channel Width Set subfield of the HT Capabilities element of both STAs is equal to 1 â€” The Secondary Channel Offset field of the most recently received HT Operation element sent by the AP of the BSS has a value of SCA or SCB â€” The local boolean variable 40MHzOperatingClass is true. If the above three conditions are met, STA1 should not transmit a 40 MHz PPDU containing one or more frames addressed to STA2 unless the following two conditions are true: â€” Either STA1 has not received a Notify Channel Width frame that was transmitted by STA2, or the Channel Width field of the most recently received Notify Channel Width frame at STA1 that was transmitted by STA2 is nonzero. â€” If STA2 is an AP, the STA Channel Width field of the most recently received HT Operation element that was transmitted by STA2 is equal to 1. 11.16.4.3 AP restrictions An AP shall not transmit a 40 MHz PPDU containing one or more frames addressed to another STA unless the following three conditions are true: 1752 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” The Supported Channel Width Set subfield of the HT Capabilities element of the AP and all associated STAs are equal to a nonzero value. â€” The Secondary Channel Offset field of the APâ€™s most recently transmitted HT Operation element has a value of SCA or SCB â€” The local boolean variable 40MHzOperatingClass is true. If the above three conditions are met, the AP should not transmit a 40 MHz PPDU containing frames addressed to another STA unless either the AP has not received a Notify Channel Width frame that was transmitted by the STA or the Channel Width field of the most recently received Notify Channel Width frame at the AP that was transmitted by the STA is nonzero. An AP shall not transmit a 40 MHz PPDU containing one or more frames with a group address in the Address 1 field unless the following three conditions are true: â€” The Supported Channel Width Set subfield of the HT Capabilities element of the AP is equal to 1 â€” The Secondary Channel Offset field of the APâ€™s most recently transmitted HT Operation element has a value of SCA or SCB â€” The local boolean variable 40MHzOperatingClass is true. If the above three conditions are met, the AP should not transmit a 40 MHz PPDU containing one or more frames with a group address in the Address 1 field unless either the AP has not received a Notify Channel Width frame from any STA in the BSS or the Channel Width field of the most recently received Notify Channel Width frame from each STA that transmitted a Notify Channel Width frame is nonzero. 11.16.4.4 Restrictions on non-AP STAs that are not infrastructure BSS members An HT STA 2G4 that is not a member of an infrastructure BSS shall not transmit a 40 MHz mask PPDU. An HT STA 5G that is not associated with an infrastructure BSS (STA1) shall not transmit a 40 MHz PPDU containing frames addressed to another STA (STA2) unless the following three conditions are true: â€” The Supported Channel Width Set subfield of the HT Capabilities element of both STAs is equal to 1 â€” The Secondary Channel Offset field of the most recently received HT Operation element sent by STA2 has a value of SCA or SCB â€” The Secondary Channel Offset field of the most recently transmitted HT Operation element sent by STA1 has a value of SCA or SCB If the above three conditions are met, STA1 should not transmit a 40 MHz PPDU containing one or more frames addressed to STA2 unless STA1 has not received a STA Channel Width field that was transmitted by STA2 or the value of the most recently received STA Channel Width field at STA1 that was transmitted by STA2 is nonzero. An HT STA 5G that is not associated with an infrastructure BSS (STA1) shall not transmit a 40 MHz PPDU containing one or more frames with a group address in the Address 1 field unless the following two conditions are true: â€” The Supported Channel Width Set subfield of the HT Capabilities element transmitted by STA1 is equal to 1. â€” The Secondary Channel Offset field of the HT Operation element most recently transmitted by STA1 has a value of SCA or SCB. 1753 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If the above two conditions are met, STA1 should not transmit a 40 MHz PPDU containing one or more frames with a group address in the Address 1 field unless the most recently received STA Channel Width field for each other known member of the BSS of which STA1 is a member is equal to 1. 11.16.5 Scanning requirements for 40-MHz-capable STA An OBSS scan operation is a passive or active scan of a set of channels that are potentially affected by 20/40 MHz BSS operation, i.e., the 20 MHz channels that wholly or partly overlap the 40 MHz signal. Each channel in the set may be scanned more than once during a single OBSS scan operation. OBSS scans are performed by STAs that are 40MC HT STA 2G4. STAs that are 40MC HT STA 5G are not required to perform OBSS scan operations. NOTEâ€”STAs that perform OBSS scans report discovered BSSs and received 20/40 BSS coexistence information to their associated AP (see 11.16.12). During an individual scan within an OBSS scan operation, the minimum per-channel scan duration is dot11OBSSScanPassiveDwell TU (when scanning passively) or dot11OBSSScanActiveDwell TU (when scanning actively). During an OBSS scan operation, each channel in the set is scanned at least once per dot11BSSWidthTriggerScanInterval seconds, and the minimum total scan time (i.e., the sum of the scan durations) per channel within a single OBSS scan operation is dot11OBSSScanPassiveTotalPerChannel TU for a passive scan and dot11OBSSScanActiveTotalPerChannel TU for an active scan. NOTEâ€”The values provided in the previous paragraph indicate the minimum requirements. For some combinations of parameter values, it is necessary to exceed the minimum values of some parameters in order to meet the minimum value constraints of all parameters. When an AP transmits an Overlapping BSS Scan Parameters element, the value of each of the fields of the element shall be set to the value of the MIB attribute from the transmitting APâ€™s MIB according to the mapping between the frame fields and MIB attributes as defined in 9.4.2.59. Upon receipt of a frame containing an Overlapping BSS Scan Parameters element from the AP with which a 40MC HT STA 2G4 is associated, the MLME of the receiving 40MC HT STA 2G4 shall update each of the values of the MIB attributes used during OBSS scanning operations according to the mapping between the frame fields and MIB attributes as defined in 9.4.2.59. A 40MC HT AP 2G4 may transmit frames containing an Overlapping BSS Scan Parameters element to any or all associated STAs in order to provide OBSS scan parameter values that are different from the default values. A 40MC HT STA 2G4 that is associated with a 40MC HT AP 2G4 shall perform at least one OBSS scan every dot11BSSWidthTriggerScanInterval seconds, unless the 40MC HT STA 2G4 satisfies the conditions described in 11.16.6. 11.16.6 Exemption from OBSS scanning A 40MC HT STA 2G4 shall maintain a local variable ActivityFraction. The value of ActivityFraction is defined by Equation (11-3). T ACTIVE ActivityFraction = ------------------------------------- - (11-3) T MEASURE-ACTIVE where T ACTIVE is the total duration of transmitted MSDUs and received individually addressed MSDUs during the previous T MEASURE-ACTIVE seconds 1754 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications T MEASURE-ACTIVE is dot11BSSWidthChannelTransitionDelayFactor Ã— dot11BSSWidthTriggerScan- Interval seconds. A 40MC HT STA 2G4 may transmit to its associated AP a 20/40 BSS Coexistence Management frame with the Scanning Exemption Request field in the 20/40 Coexistence element set to 1. If the last 20/40 BSS Coexistence Management frame received by a 40MC HT STA 2G4 in an individually addressed frame from its associated AP has the Scanning Exemption Grant field equal to 1, the STA is exempted from scanning whenever the value of its local variable ActivityFraction is less than dot11OBSSScanActivityThreshold/10 000. A 40MC HT AP 2G4 shall not transmit a 20/40 BSS Coexistence Management frame with the Scanning Exemption Grant field set to 1 addressed to a 40MC HT STA if the following condition is true: â€” The 40MC HT STA has transmitted one or more channel report elements and is the only STA in the BSS that has indicated one or more channels on which a STA has found conditions that disallow the use of a 20/40 MHz BSS. If there is more than one 40MC HT STA in the BSS that has indicated conditions that disallow the use of 20/40 MHz BSS on a specific channel, then the following apply: â€” If all of the 40MC HT STAs that have indicated unavailability of a channel have also requested to be exempt from scanning, the AP shall disallow at least one of the 40MC HT STA to be exempt from scanning. â€” If, from the group of 40MC HT STAs that have indicated unavailability of a channel, there is at least one 40MC HT STA that has not requested to be exempt from scanning, the AP may allow all of the STAs that have requested to be exempt from scanning to be exempted from scanning. 11.16.7 Communicating 20/40 BSS coexistence information In addition to the 20/40 BSS Coexistence Management frame, a STA can include the 20/40 BSS Coexistence element in transmitted Beacon, Probe Request, Probe Response, (Re)Association Request, and (Re)Association Response frames. 11.16.8 Support of DSSS/CCK in 40 MHz Transmission and reception of PPDUs using DSSS/CCK by 40MC HT STAs is managed using the DSSS/ CCK Mode in 40 MHz subfield of the HT Capability Information field in the HT Capabilities element (see 9.4.2.56.2). An HT STA declares its capability to use DSSS/CCK rates while it has a 40 MHz operating channel width through the DSSS/CCK Mode in 40 MHz subfield of its (Re)Association Request frames. If the DSSS/CCK Mode in 40 MHz subfield is equal to 1 in Beacon and Probe Response frames, an associated HT STA in a 20/40 MHz BSS may generate DSSS/CCK transmissions. If the subfield is equal to 0, then the following apply: â€” An associated HT STA shall not generate DSSS/CCK transmissions. â€” The AP shall not include an ERP element in its Beacon and Probe Response frames. â€” The AP shall not include DSSS/CCK rates in the Supported Rates and BSS Membership Selectors element. â€” The AP shall refuse association requests from a STA that includes only DSSS/CCK rates in its Supported Rates and BSS Membership Selectors element and Extended Supported Rates and BSS Membership Selectors element. 1755 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A STA not operating in the 2.4 GHz band shall set the DSSS/CCK Mode in 40 MHz subfield to 0. 11.16.9 STA CCA sensing in a 20/40 MHz BSS This subclause defines CCA sensing rules for an HT STA that is not a VHT STA. For rules related to a VHT STA, see 10.3.2.6, 10.22.2.6, and 10.22.3. A STA may transmit a 20 MHz mask PPDU in the primary channel following the rules in 10.22.2. A STA transmitting a 40 MHz mask PPDU that begins a TXOP using EDCA as described in 10.22.2.4 or that is using a PIFS as permitted in 10.3.2.3.4 shall sense CCA on both the 20 MHz primary channel and the 20 MHz secondary channel before the 40 MHz mask PPDU transmission starts. Unless explicitly stated otherwise, a STA may treat a PHY-CCA.indication(BUSY) primitive as a PHY- CCA.indication(IDLE) primitive in the following cases: â€” If the channel-list parameter is present and equal to {secondary} and the STA is transmitting a 20 MHz mask PPDU on the primary channel, or â€” If the channel-list parameter is present and equal to {primary} and the STA is transmitting a 20 MHz mask PPDU on the secondary channel. NOTEâ€”Transmission of PPDUs on the secondary channel is also subject to constraints in 11.16.2. At the specific slot boundaries (see Figure 10-26) determined by the STA based on the 20 MHz primary channel CCA, when the transmission begins a TXOP using EDCA (as described in 10.22.2.4), the STA may transmit a pending 40 MHz mask PPDU only if the secondary channel has also been idle during the times the primary channel CCA is performed (defined in 10.22.2.4) during an interval of a PIFS for the 5 GHz band and DIFS for the 2.4 GHz band immediately preceding the expiration of the backoff counter. If a STA was unable to transmit a 40 MHz mask PPDU because the secondary channel was occupied during this interval, it may take one of the following steps: a) Transmit a 20 MHz mask PPDU on the primary channel. b) Restart the channel access attempt. In this case, the STA shall invoke the backoff procedure as specified in 10.22.2 as though the medium is busy as indicated by either physical or virtual CS and the backoff timer has a value of 0. NOTEâ€”As a result of this rule, the STA selects a new random number using the current value of CW[AC], and the retry counters are not updated. When a TXOP is obtained for a 40 MHz PPDU, the STA may transmit 40 MHz PPDUs and/or 20 MHz PPDUs during the TXOP. When the TXOP is obtained by the exchange of 20 MHz PPDUs only in the primary channel, the STA shall not transmit 40 MHz PPDUs during the TXOP. 11.16.10 NAV assertion in 20/40 MHz BSS An HT STA shall update its NAV using the Duration/ID field value in any frame received in a 20 MHz PPDU in the primary channel or received in a 40 MHz PPDU and that does not have an RA matching the STAâ€™s MAC address. NOTEâ€”A STA need not set its NAV in response to 20 MHz frames received on the secondary channel or any other channel that is not the primary channel, even if it is capable of receiving those frames. 11.16.11 Signaling 40 MHz intolerance An HT STA 2G4 shall set the Forty MHz Intolerant field to 1 in transmitted HT Capabilities elements if dot11FortyMHzIntolerant is true; otherwise, the field shall be set to 0. 1756 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A STA 2G4 shall set the Forty MHz Intolerant field to 1 in transmitted 20/40 BSS Coexistence fields if dot11FortyMHzIntolerant is true; otherwise, the field shall be set to 0. A STA 2G4 that is not an HT STA 2G4 shall include a 20/40 BSS Coexistence element in Management frames in which the element may be present if dot11FortyMHzIntolerant is present and dot11FortyMHzIntolerant is true. A STA 5G shall set the Forty MHz Intolerant field to 0 in transmitted HT Capabilities elements and 20/40 BSS Coexistence fields. 11.16.12 Switching between 40 MHz and 20 MHz A VHT STA is not required to perform any of the behavior described in this subclause associated with Information Request and 20 MHz BSS Width Request. The following events are defined to be BSS channel width trigger events (TEs): â€” TE-A: On any of the channels of the channel set defined in Clause 18, reception of a Beacon frame that does not contain an HT Capabilities element. â€” TE-B: On any of the channels of the channel set defined in Clause 18, reception of a 20/40 BSS Coexistence Management, Beacon, Probe Request, or Probe Response frame that contains a value of 1 in a Forty MHz Intolerant field and that has the Address 1 field equal to the receiving STAâ€™s address or to a group address value, with no further addressing qualifications. â€” TE-C: Reception of a 20/40 BSS Coexistence Management frame with the 20 MHz BSS Width Request field equal to 1 and with a value of the Address 1 field that matches the receiving STA using either individual or group addressing and with a value of the TA field that corresponds to the MAC address of a STA with which the receiver is associated. â€” TE-D: Reception of a 20/40 BSS Coexistence Management frame containing at least one 20/40 BSS Intolerant Channel Report element with a nonzero length and with a value of the Address 1 field equal to the receiving STAâ€™s address or to a group address value, but with no qualification of the Address 3 value. A 40MC HT AP 2G4 shall reevaluate the value of the local variable 20/40 Operation Permitted (see 11.16.3.2) when either of the following events occurs: â€” A BSS channel width trigger event TE-A is detected. â€” A BSS channel width trigger event TE-D is detected. A 40MC HT AP 2G4 may reevaluate the value of the local variable 20/40 Operation Permitted (see 11.16.3.2) when either of the following situations occurs: â€” No BSS channel width trigger events TE-A are detected for a period of time equal to dot11BSSWidthChannelTransitionDelayFactor Ã— dot11BSSWidthTriggerScanInterval seconds. â€” No BSS channel width trigger events TE-D are detected for a period of time equal to dot11BSSWidthChannelTransitionDelayFactor Ã— dot11BSSWidthTriggerScanInterval seconds. A 40MC HT AP 2G4 that detects either BSS channel width trigger event TE-B or TE-C or that determines that the value of its variable 20/40 Operation Permitted has changed from true to false shall set the Secondary Channel Offset field to SCN in transmitted HT Operation elements beginning at the next DTIM or next TBTT if no DTIMs are transmitted to indicate that no secondary channel is present (i.e., that the BSS operating width is 20 MHz). A 40MC HT AP 2G4 shall not set the Secondary Channel Offset field to a value of SCA or SCB in transmitted HT Operation elements unless the following two conditions have been met: â€” A period of dot11BSSWidthChannelTransitionDelayFactor Ã— dot11BSSWidthTriggerScanInterval seconds have elapsed during which no BSS channel width trigger events TE-B or TE-C are detected. â€” The value of the local variable 20/40 Operation Permitted (see 11.16.3.2) is true. 1757 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications To request an update of the status of the 20 MHz BSS Width Request field, a 40MC HT AP 2G4 can transmit a 20/40 BSS Coexistence Management frame with a value of 1 in the Information Request field as described in 11.18. A 40MC HT STA 2G4 that is associated with a 40MC HT AP 2G4 shall maintain a record of detected BSS channel width trigger events as follows: â€” For each detected BSS channel width trigger event TE-A: â€” If a DSSS Parameter Set field is present in the received Beacon frame, the channel of the BSS channel width trigger event is the value of the Current Channel field of the DSSS Parameter Set field; otherwise, the channel of the BSS channel width trigger event is the channel on which the detecting STA received the Beacon frame. â€” If a Supported Operating Classes element is present in the received Beacon frame, the operating class of the BSS channel width trigger event is the value of the Current Operating Class field of the Supported Operating Classes element of the received Beacon frame; otherwise, the operating class of the BSS channel width trigger event is â€œunknown.â€ â€” For each detected BSS channel width trigger event TE-A of a unique combination of operating class and channel, the 40MC HT STA 2G4 shall maintain a record containing two variables: â€” The operating class of the BSS channel width trigger event â€” The channel of the BSS channel width trigger event NOTEâ€”If a BSS channel width trigger event TE-A is detected for an operating class and channel combination for which no record exists, the STA creates such a record. If a BSS channel width trigger event TE-A is detected for an operating class and channel combination for which a record already exists, the information in that record shall be updated with the information determined from the new trigger event. For all BSS channel width trigger events TE-B, the 40MC HT STA 2G4 shall maintain a single record containing an indication of whether one or more trigger events TE-B have been detected. At the completion of an OBSS scan operation (i.e., at the end of the period of time equal to dot11BSSWidthTriggerScanInterval) or when it receives a 20/40 BSS Coexistence Management frame from its associated AP that contains a value of 1 in the Information Request field, a 40MC HT STA 2G4 that is associated with a 40MC HT AP 2G4 shall create a 20/40 BSS Coexistence Management frame by including a value of 0 for all fields of a 20/40 BSS Coexistence Management frame and then transferring information from the BSS channel width trigger event TE-A and TE-B records to the frame according to the following four steps: â€” For each unique operating class that is stored in the set of BSS channel width trigger event TE-A records, the STA shall create a 20/40 BSS Intolerant Channel Report element for inclusion in the frame and include all of the unique channels associated with the operating class in the channel list of that element. â€” The STA sets the Forty MHz Intolerant field of the 20/40 BSS Coexistence element based on A STAâ€™s FortyMHzIntolerant (see 11.16.11). â€” The STA shall set to 1 the 20 MHz BSS Width Request field of the 20/40 BSS Coexistence element for inclusion in the frame if a record for BSS channel width trigger event TE-B exists and indicates that at least one trigger event TE-B has been detected. â€” The STA may set to 1 the Information Request field. Upon completion of these four steps, the 40MC HT STA 2G4 shall delete all records for trigger events TE- A and TE-B. Subsequently detected trigger events cause the creation of new records as necessary to be used in subsequently generated 20/40 BSS Coexistence Management frames. Following the record deletion, the 1758 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 40MC HT STA 2G4 shall transmit to its associated 40MC HT AP 2G4 the 20/40 BSS Coexistence Management frame if any of the following conditions is true: â€” At least one 20/40 BSS Intolerant Channel Report element with the Length field equal to a nonzero value is included. â€” The Forty MHz Intolerant field is equal to 1. â€” The 20 MHz BSS Width Request field is equal to 1. â€” The Information Request field is equal to 1. â€” The frame was created in response to the reception of an Information Request field that was equal to 1. 11.17 Phased coexistence operation (PCO) 11.17.1 General description of PCO The PCO mechanism is obsolete. Consequently, this subclause might be removed in a later revision of this standard. PCO is an optional coexistence mechanism in which a PCO active AP divides time into alternating 20 MHz and 40 MHz phases (see Figure 11-30). The PCO active AP reserves the 20 MHz primary channel and the 20 MHz secondary channel in turn to start the 40 MHz phase and resets the NAV in the 20 MHz channels in the opposite order to start the 20 MHz phase. Due to the protection of the 40 MHz period in both channels, it is tolerant of OBSSs on both 20 MHz halves of a 40 MHz channel. Beacon Set PCO or CTS-to-self CF-End CF-End Phase Set PCO Phase 20 MHz ch_a phase 40 MHz (primary) phase ch_b (secondary) 20 MHz STA NAV in ch_a 20 MHz STA NAV in ch_b PCO active STA NAV NAV Figure 11-30â€”Phased coexistence operation (PCO) A PCO active STA that does not know the current PCO phase shall transmit using a 20 MHz PPDU. During the 40 MHz phase, a PCO active STA shall transmit Data frames using a 40 MHz HT PPDU and Control frames using a non-HT duplicate or a 40 MHz HT PPDU, with the following exceptions: â€” Any CF-End frame shall be sent using only a 40 MHz HT PPDU. â€” A PCO active AP may transmit 20 MHz group addressed frames as defined in 10.7.5.3. A PCO active STA shall transmit Management frames in 20 MHz or 40 MHz PPDUs according to 10.7.5 during the 40 MHz phase, except that Set PCO Phase frames shall be sent following the rules specified in 11.17.2. 1759 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications During the 40 MHz phase, a PCO active STA may act as though the HT Protection field were equal to no protection mode, as defined in 10.26.3.1. During the 20 MHz phase, a PCO active STA shall not transmit frames using a 40 MHz (HT or non-HT duplicate) PPDU. The protection of a PCO active STA during the 20 MHz phase is the same as protection in a 20 MHz BSS. During the 20 MHz phase, a STA may transmit a 40 MHz mask PPDU that is not also a 40 MHz PPDU. NOTEâ€”This rule allows a STA to transmit 20 MHz PPDUs without requiring it to change to a 20 MHz transmit mask. A PCO-capable AP may set the PCO Active field to 1 only if it is in a 20/40 MHz BSS. NOTEâ€”A non-PCO-capable 20/40 STA regards the PCO active BSS as a PCO inactive BSS. A non-PCO-capable 20/40 STA that associates with a PCO active BSS protects its transmissions as though the BSS were a PCO inactive BSS. The value indicated by the PCO Transition Time field in the HT Extended Capabilities field is measured from the end of the PPDU carrying the Set PCO Phase frame. The PCO active STA shall be able to receive a PPDU using the new channel width no later than the value specified by the PCO Transition Time field after the end of the PPDU carrying the Set PCO Phase frame. A VHT STA shall not transmit VHT PPDUs during a PCO 40 MHz phase. 11.17.2 Operation at a PCO active AP A PCO-capable AP activates PCO if it decides that PCO active BSS is more appropriate than either PCO inactive BSS or 20 MHz BSS in the current circumstances. The algorithm for making this decision is beyond the scope of this standard.45 A PCO active AP shall set the PCO Active field in the HT Operation element to 1. When a PCO active AP detects that PCO is not providing a performance benefit, the PCO active AP may deactivate PCO and operate in either a PCO inactive BSS or 20 MHz BSS. A PCO-capable AP shall set the PCO Active field in the HT Operation element to 0 when PCO operation is disabled. Since the AP advertises the current mode in its Beacon and Probe Response frames, its associated STAs are informed of the mode change. Values of the PCO Transition Time field in the HT Extended Capabilities field from 1 to 3 indicate the maximum time the PCO active STA takes to switch between a 20 MHz channel width and a 40 MHz channel width. A PCO active AP may set the PCO Transition Time field to 0 when it requires the associated PCO active STAs to be able to receive 40 MHz frames and respond with 40 MHz frames during the 20 MHz phase. The PCO active AP shall increase the value of the PCO Transition Time field if the PCO active AP accepts the association of a PCO-capable STA whose value of the PCO Transition Time field exceeds the one currently used by the PCO active AP. If the PCO active AP decides not to extend its transition time to meet the value of the requesting STA, the PCO active AP shall deny the association. The AP may choose to continue PCO when a non-PCO-capable 20/40 STA requests association, and in such cases, the PCO active AP shall be able to receive 40 MHz frames and respond using 40 MHz frames during the 20 MHz phase. 45 A PCO-capable AP might consider the performance impact, e.g., throughput and jitter, caused by and given to STAs based on their capabilities, traffic types, or load to determine the BSSâ€™s PCO mode. STAs under consideration might be not only associated STAs but also those that were detected in OBSSs. 1760 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A PCO active AP that indicates a switch to the 40 MHz phase by a PCO Phase field in a Beacon frame or by a PCO Phase Control field in a Set PCO Phase frame and that transmits a nonzero value of the PCO Transition Time field shall wait for at least the transition time specified by the PCO Transition Time field before sending a CF-End frame in the 40 MHz channel to start the 40 MHz operating phase. When switching to the 40 MHz phase, a PCO active AP indicates a NAV duration either in the CF Parameter Set element of a Beacon frame or in the Duration/ID field of a Set PCO Phase frame sent on the primary channel that shall protect up to the end of the intended 40 MHz phase plus a transition time. A PCO active AP may continue the CFP after the 40 MHz phase by setting a longer duration for the CFP. The value of the Duration/ID field in a CTS-to-self frame sent to protect a 40 MHz phase shall be set to protect up to the intended end of the 40 MHz phase plus a transition time. The CTS-to-self frame shall be sent in a non- HT duplicate PPDU. The transmission of the CTS-to-self frame shall be delayed until the secondary channel CCA has indicated idle for at least a PIFS. It need not sense the primary channel because it is already reserved by a Beacon frame or a Set PCO Phase frame. If the PCO Transition Time field is nonzero, a PCO active AP shall start a timer with a timeout value equal to the time specified by the PCO Transition Time field after transmitting a Beacon frame or a Set PCO Phase frame. If this timer expires while attempting to reserve the secondary channel, the AP shall transmit a Set PCO Phase frame indicating a switch back to the 20 MHz phase and shall transmit a CF-End frame on the primary channel. NOTEâ€”If this timer expires while attempting to reserve the secondary channel, the AP abandons switching to the 40 MHz phase to avoid an unexpectedly long delay. A PCO active AP may transmit a Set PCO Phase frame in a non-HT duplicate PPDU followed by a CF-End frame in a 40 MHz HT PPDU to reserve both the primary and secondary channels again for the 40 MHz phase or to extend the 40 MHz phase. The value of the Duration/ID field in a Set PCO Phase frame contained in a non-HT duplicate PPDU for this intent shall protect up to the end of the intended 40 MHz phase plus the transition time. To start the 20 MHz phase, a PCO active AP shall send a Set PCO Phase frame in a 40 MHz HT PPDU or in a non-HT duplicate PPDU with the Duration/ID field set to cover the transition time. It may also send a CF-End frame in both primary and secondary channels following the Set PCO Phase frame, where a CF-End frame in the primary channel shall be sent out at least after the transition time. The Duration/ID field of the Set PCO Phase frame for this case shall cover the transition time plus the duration of a CF-End frame. A PCO active AP may broadcast a Set PCO Phase frame to advertise the current PCO phase to PCO active STAs. Although PCO improves throughput in some circumstances, PCO might also introduce jitter. To minimize the jitter, the maximum duration of 40 MHz phase and 20 MHz phase is dot11PCOFortyMaxDuration and dot11PCOTwentyMaxDuration, respectively. Also in order for the PCO active AP to give opportunities for each STA to send frames, the minimum duration of 40 MHz phase and 20 MHz phase is dot11PCOFortyMinDuration and dot11PCOTwentyMinDuration, respectively. 11.17.3 Operation at a PCO active non-AP STA If the PCO field in the Association Request frame to a PCO active AP is equal to 1 and the association succeeds, the STA shall operate in PCO mode. When requesting association, a PCO-capable STA shall set the PCO Transition Time field to 0 if the PCO active AP has set the PCO Transition Time field to 0. A PCO- capable STA may attempt to associate with a transition time that is larger than one currently advertised by the PCO active AP. If such an association fails, the PCO-capable non-AP STA may regard the BSS as a PCO inactive BSS and may attempt an association as a non-PCO-capable 20/40 STA. 1761 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NOTEâ€”A STA that does not support the PCO transition time indicated by an AP might still attempt association with that AP. The AP will either refuse the association based on PCO transition time or respond by adjusting its PCO transition time to suit the STA. A PCO active non-AP STA may transmit a Probe Request frame to the associated PCO active AP to determine the current PCO phase. A PCO active STA associated with a PCO active AP shall switch its operating phase from 20 MHz channel width to 40 MHz channel width when it receives from its AP a Beacon frame or a Probe Response frame that contains the PCO Phase field equal to 1 or a Set PCO Phase frame with the PCO Phase Control field equal to 1. The value of the CFP DurRemaining field in the CF Parameter Set element of a Beacon frame or the value of the Duration/ID field of a Set PCO Phase frame shall be interpreted as the duration of the PCO 40 MHz phase. A PCO active STA associated with a PCO active AP shall switch its operating phase from 40 MHz channel width to 20 MHz channel width when it receives a Beacon frame or a Probe Response frame that contains the PCO Phase field equal to 0 or a Set PCO Phase frame with the PCO Phase Control field equal to 0. It also may switch from 40 MHz channel width to 20 MHz channel width based on the expiration of the value in the Duration/ID field of a Set PCO Phase frame that indicated a 40 MHz phase or based on the expiration of the value in the CFP DurRemaining field of the CF Parameter Set element of a Beacon frame that indicated a 40 MHz phase. A PCO active STA shall halt PCO operation if it receives an HT Operation element from its AP with the PCO Active field equal to 0. NOTEâ€”An HT STA might change its PCO capabilities by disassociating followed by associating with an AP. 11.18 20/40 BSS Coexistence Management frame usage A STA that supports the 20/40 BSS Coexistence Management frame type shall set the 20/40 BSS Coexistence Management Support field to 1 in transmitted Extended Capabilities elements. A STA that supports the 20/40 BSS Coexistence Management frame type shall include an Extended Capabilities element in transmitted Beacon, (Re)Association Request, (Re)Association Response, Probe Request, and Probe Response frames. A STA shall not transmit to another STA a 20/40 BSS Coexistence Management frame with an individual address in the Address 1 field if the Extended Capabilities element from the recipient STA contained a value of 0 in the 20/40 BSS Coexistence Management Support field. A STA that transmits a 20/40 BSS Coexistence Management frame may set the Address 1 field to a group address. NOTEâ€”A 20/40 BSS Coexistence Management frame is a Class 1 frame and, therefore, can be sent to a STA that supports reception of such frames and that is not a member of the same BSS as the transmitting STA. In such a case, the BSSID of the frame is set to the wildcard BSSID value, regardless of whether the Address 1 field contains an individual or group address value. A STA may transmit a 20/40 BSS Coexistence Management frame that contains a value of 1 for the Request Information field to another STA that supports the transmission of and reception of the 20/40 BSS Coexistence Management frame, except when the frame is a response to a 20/40 BSS Coexistence Management frame that contains a value of 1 for the Request Information field. A non-VHT STA that receives a 20/40 BSS Coexistence element with the Information Request field equal to 1, a value of the Address 1 field that matches the receiving STA using an individual address, and a nonwildcard BSSID field that matches the STAâ€™s BSS shall immediately queue for transmission a 20/40 BSS Coexistence Management frame with the transmitting STA as the recipient. 1762 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.19 RSNA A-MSDU procedures When dot11RSNAActivated is true, a STA indicates support for payload protected A-MSDUs (PP A-MSDUs) or signaling and payload protected A-MSDUs (SPP A-MSDUs) during (re)association. On either (re)association, the associating STA and its peer STA both determine and maintain a record of whether an encrypted A-MSDU sent to its peer is to be a PP A-MSDU or an SPP A-MSDU based on the value of the SPP A-MSDU Capable and SPP A-MSDU Required subfields of the RSN Capabilities field of the RSNE (see 9.4.2.25.4). Table 11-12 defines behavior related to the transmission and reception of individually addressed A-MSDUs of a first HT STA (STA1) that has successfully negotiated an RSNA (re)association with a second HT STA (STA2). Reception and transmission of A-MSDUs using a non-RSN association is unaffected by the values of the SPP A-MSDU Capable and SPP A-MSDU Required subfields. Table 11-12â€”A-MSDU STA behavior for RSN associations STA1 state STA2 state SPP SPP SPP SPP STA1 action with respect to STA2 A-MSDU A-MSDU A-MSDU A-MSDU capable required capable required 0 0 X 0 May transmit PP A-MSDU. Shall not transmit SPP A-MSDU. Shall receive PP A-MSDU. Received SPP A-MSDU MIC fails. 0 0 X 1 Shall not transmit PP A-MSDU. Shall not transmit SPP A-MSDU. Shall discard received (PP and SPP) A-MSDU. 0 1 X X Shall not transmit PP A-MSDU. Shall not transmit SPP A-MSDU. Shall discard received (PP and SPP) A-MSDU. 1 0 0 0 May transmit PP A-MSDU. Shall not transmit SPP A-MSDU. Shall receive PP A-MSDU. Received SPP A-MSDU MIC fails. 1 0 0 1 Shall not transmit PP A-MSDU. Shall not transmit SPP A-MSDU. Shall discard received (PP and SPP) A-MSDU. 1 X 1 X Shall not transmit PP A-MSDU. May transmit SPP A-MSDU. Received PP A-MSDU MIC fails. Shall receive SPP A-MSDU. 1 1 0 X Shall not transmit PP A-MSDU. Shall not transmit SPP A-MSDU. Shall discard received (PP and SPP) A-MSDU. NOTEâ€”X = Not significant. An AP may transmit an SPP A-MSDU for a GCR group address if it has successfully negotiated RSNA (re)associations with all associated STAs that have an active GCR agreement for this group address. 1763 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.20 Public Action frame addressing A STA that is a member of a BSS and that transmits an individually addressed Public Action frame to a STA that is not a member of the same BSS shall set the BSSID field of the frame as follows: â€” If the recipient STA is known to be a member of another BSS (including being an AP) and that BSSâ€™s BSSID is known, the BSSID field shall be set to the BSSâ€™s BSSID or the wildcard BSSID value. â€” Otherwise, the BSSID field of the frame shall be set to the wildcard BSSID value. A STA that is a member of a BSS and that transmits a group addressed Public Action frame shall set the BSSID field of the frame to the BSSâ€™s BSSID or the wildcard BSSID value. A STA that is a member of a BSS and that transmits an individually addressed Public Action frame to a STA that is a member of the same BSS shall set the BSSID field of the frame to the BSSâ€™s BSSID. A STA that is not a member of a BSS and that transmits a Public Action frame shall set the BSSID field of the frame as follows: â€” If the frame is individually addressed, the recipient STA is known to be a member of a BSS (including being an AP), and that BSSâ€™s BSSID is known, the BSSID field shall be set to the BSSâ€™s BSSID or the wildcard BSSID value. â€” Otherwise, the BSSID field of the frame shall be set to the wildcard BSSID value. 11.21 STAs communicating Data frames outside the context of a BSS When dot11OCBActivated is true in a STA: a) Synchronization, authentication, association, and frame classes as defined in 11.1 and 11.3 are not used. Data confidentiality as defined in Clause 12 is not used. The STA may send Action frames and, if the STA maintains a TSF Timer, Timing Advertisement frames. b) The STA may send Control frames, except those of subtype PS-Poll, CF-End, and CF-End +CF- Ack. c) The STA may send Data frames of subtype Data, Null, QoS Data, and QoS Null. d) The STA shall set the BSSID field in all Management and Data frames to the wildcard BSSID value. A STA with dot11OCBActivated equal to true shall not join or start a BSS. Whenever MAC sublayer and PHY parameters are changed in a STA in which dot11OCBActivated is true, MAC sublayer and PHY operation shall resume with the appropriate MIB attributes in less than 2 TU. A STA shall use information from the CF Parameter Set element of all received Beacon frames, without regard for the BSSID, to update its NAV as specified in 10.4.3.3. 11.22 Timing Advertisement 11.22.1 Introduction A STA that sends a Timing Advertisement frame shall maintain a TSF Timer in order to set the Timestamp field in this frame. When a STA transmits the Timing Advertisement, Probe Response, or Beacon frame, the Timestamp shall be set to the value of the STAâ€™s TSF timer at the time that the data symbol containing the first bit of the Timestamp is transmitted to the PHY plus the transmitting STAâ€™s delays through its local PHY from the MAC-PHY interface to its interface with the WM (e.g., antenna). 1764 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A STA may advertise a time standard by transmitting a Timing Advertisement element in one of the following frames: Timing Advertisement, Probe Response, or Beacon. As defined in 9.4.2.61 the Time Advertisement element contains two estimates. The Time Value field contains an estimate of the difference between a time standard and the timestamp included in the same frame. The Time Error field contains an estimate of the standard deviation of the error in the estimate in the Time Value field. The time standard might be derived from an external time source. A STA with an external time source might implement an estimator in a variety of ways, which are beyond the scope of this standard. 11.22.2 Timing advertisement frame procedures The SME provides the Time Advertisement element to the MLME when it requests the MLME to send a Timing Advertisement frame. When a Timing Advertisement frame is received by a STA, its MLME reports the Timestamp, Local Time, Time Advertisement element, and estimates of propagation delay to the SME. For a STA that maintains a TSF Timer and receives a Timing Advertisement frame, Local Time is the value of the STAâ€™s TSF timer at the start of reception of the first octet of the Timestamp field of the frame. Otherwise, the Local Time is unspecified. The receiving STAâ€™s SME might use the Timestamp, Local Time, and Time Advertisement element to align its estimate of the time standard to the transmitting STAâ€™s estimate of the corresponding time standard. 11.22.3 UTC TSF Offset procedures When dot11UTCTSFOffsetActivated is true, the Time Advertisement and Time Zone elements shall be included in all Probe Response frames, and the Time Advertisement element shall be included in the Beacon frame every dot11TimeAdvertisementDTIMInterval DTIMs. When the dot11UTCTSFOffsetActivated is false, the Time Advertisement and Time Zone elements shall not be included in Beacon and Probe Response frames. The AP should periodically synchronize to a UTC reference clock [B51] so that the UTC TSF offset can account for drift. The AP shall increment the Time Update Counter field value in the Time Advertisement element each time the synchronization occurs. The method the AP uses to synchronize with a UTC reference clock is out of scope of the standard. 11.23 Tunneled direct-link setup 11.23.1 General Tunneled direct-link setup (TDLS) is characterized by encapsulating setup frames in Data frames, which allows them to be transmitted through an AP transparently. Therefore, the AP does not need to be direct- link capable, nor does it have to support the same set of capabilities that are used on the direct link between the two TDLS peer STAs. TDLS also includes power saving, in the form of TDLS peer PSM (scheduled) and TPU (unscheduled). STAs that set up a TDLS direct link remain associated with their BSS, but have the option of transmitting frames directly to the other TDLS peer STA. Transmitting a TDLS frame through the AP means that the frameâ€™s RA is set to the BSSID. Transmitting a frame over the direct path means that the frameâ€™s RA is set to the MAC address of the TDLS peer STA. To set up and maintain a direct link, both TDLS peer STAs shall be associated with the same infrastructure BSS. A DMG STA shall not use the TDLS protocol. A TDLS peer STA may be involved in direct links with multiple TDLS peer STAs at the same time. Simultaneous operation of DLS and TDLS between the same pair of STAs is not allowed. A DLS Request 1765 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications frame shall not be transmitted to a STA with which a TDLS direct link is currently active. A DLS Request frame received from a STA with which a TDLS direct link is currently active shall be discarded. The channel on which the AP operates is referred to as the base channel. If the AP operates in a 40 MHz channel, then the base channel refers to the primary channel. If the direct link is switched to a channel that is not the base channel, then this channel is referred to as the off-channel. Features, excluding PCO, that are not supported by the BSS but that are supported by both TDLS peer STAs may be used on a TDLS direct link between those STAs. An example is the use of an HT MCS on a TDLS direct link between HT STAs when these STAs are associated with a non-HT BSS. Features that are supported by the BSS shall follow the BSS rules when they are used on a TDLS direct link on the base channel. The channel width of a TDLS direct link on the base channel shall not exceed the channel width of the BSS to which the TDLS peer STAs are associated, except when the TDLS Wider Bandwidth subfield in the Extended Capabilities element of the TDLS Setup Request frame or the TDLS Setup Response frame is 1 for both TDLS peer STAs. A VHT STA with a TDLS link that is not an off-channel direct link shall use as its primary channel the primary channel or the only channel of its BSS. The channel width of a VHT TDLS link shall not be wider than the maximum channel width supported by either the TDLS initiator STA or the TDLS responder STA. A 160 MHz bandwidth is defined to be identical to an 80+80 MHz bandwidth (i.e., one bandwidth is not wider than the other). A STA shall not participate in a TDLS direct link with the same primary 80 MHz channel as the infrastructure BSS or another TDLS direct link of the STA but with a different secondary 80 MHz channel. When admission control is required for an AC on the base channel, then the TDLS peer STA that intends to use this AC for direct-link transmissions on the base channel is responsible for setting up a TS with Direction of â€˜Direct Linkâ€™ with the AP, as defined in 10.22.4.2. A non-AP STA may act as TDLS initiator STA or TDLS responder STA when dot11TunneledDirectLinkSetupImplemented is true. TDLS frames shall use the formatting as specified in 11.23.2 when they are transmitted through the AP and when they are transmitted over the TDLS direct link. A STA shall not transmit a TDLS Action field in a frame with the Type field of the frame set to Management. A received TDLS Action field in a frame with the Type field equal to Management shall be discarded. Note that the TDLS Discovery Response frame is not a TDLS frame but a Public Action frame. TDLS shall not be used in an IBSS. TDLS shall not be used in an MBSS. Security is available on the TDLS direct link only when both TDLS peer STAs have an RSNA with the BSS. TDLS shall not be used when the TDLS Prohibited subfield included in the Extended Capability element of the Association Response frame or Reassociation Response frame that led to the current association is equal to 1. The HT Operation element shall be present in a TDLS Setup Confirm frame when both STAs are HT capable. 1766 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The VHT Operation element shall be present in a TDLS Setup Confirm frame when both STAs are VHT capable and the TDLS direct link is not established in the 2.4 GHz band. When the TDLS Setup Confirm frame includes a VHT Operation element, the Basic VHT-MCS And NSS Set field is reserved. 11.23.2 TDLS payload TDLS uses Ethertype 89-0d frames, as defined in Annex H. The TDLS payload contains a TDLS Action field as is specified in 9.6.13. The UP shall be AC_VI, unless otherwise specified. 11.23.3 TDLS Discovery To discover TDLS capable STAs in the same BSS, a TDLS initiator STA may send a TDLS Discovery Request frame to an individual DA, through the AP. The TDLS responder STA Address field contained in the Link Identifier element of the TDLS Discovery Request frame shall be set to the Destination Address of the TDLS Discovery Request frame. A TDLS capable STA that receives a TDLS Discovery Request frame with a matching BSSID in the Link Identifier element shall send a TDLS Discovery Response frame to the requesting STA, via the direct path. The TDLS responder STA Address field contained in the Link Identifier element of the TDLS Discovery Response frame shall be set to the MAC address of the STA sending the TDLS Discovery Response frame. A TDLS Discovery Request frame shall not be sent within dot11TDLSDiscoveryRequestWindow DTIM intervals after transmitting TDLS Discovery Request frame. A TDLS STA may send an individually addressed TDLS Discovery Response frame via the direct path without prior reception of a TDLS Discovery Request frame. A TDLS STA that receives such an unsolicited TDLS Discovery Response frame may respond with an individually addressed TDLS Discovery Response frame. A TDLS Discovery Request frame shall not be sent to a group address. A TDLS Discovery Response frame shall not be sent to a group address. A TDLS STA may also send a TDLS Setup Request frame to a STA in the same BSS to discover whether the TDLS peer STA is TDLS capable or not. A TDLS Setup Response frame transmitted in response to TDLS Setup Request frame indicates that the TDLS peer STA sending the TDLS Setup Response frame is TDLS capable. An alternative mechanism to discover TDLS capable STAs in the same BSS, is provided by the TDLS Capability ANQP-element, as described in 11.25.3.3.10. This mechanism allows the ANQP request/ response frames to use the direct path between the peer STAs. 11.23.4 TDLS direct-link establishment To establish a TDLS direct link, the TDLS initiator STA shall send a TDLS Setup Request frame to the intended TDLS responder STA. TDLS Setup Request frames, TDLS Setup Response frames, and TDLS Setup Confirm frames shall be transmitted through the AP and shall not be transmitted to a group address. Upon receipt of a TDLS Setup Request frame, the following options exist at the TDLS responder STA: a) The TDLS responder STA accepts the TDLS Setup Request frame, in which case the TDLS responder STA shall respond with a TDLS Setup Response frame with status code SUCCESS. b) The TDLS responder STA declines the TDLS Setup Request frame, in which case the TDLS responder STA shall respond with a TDLS Setup Response frame with status code REQUEST_DECLINED. A TDLS setup request shall be declined when the BSSID in the received Link Identifier does not match the BSSID of the TDLS responder STA. 1767 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications c) The TDLS Setup Request frame is received after sending a TDLS Setup Request frame and before receiving the corresponding TDLS Setup Response frame, and the source address of the received TDLS Setup Request frame is higher than its own MAC address, in which case the TDLS responder STA shall discard the frame and the TDLS responder STA shall send no TDLS Setup Response frame. d) The TDLS Setup Request frame is received after sending a TDLS Setup Request frame and before receiving the corresponding TDLS Setup Response frame, and the source address of the received TDLS Setup Request frame is lower than its own MAC address. In this case, the TDLS responder STA shall terminate the TDLS setup it initiated. The TDLS responder STA shall send a response according to item a) or item b) above in this case. e) If a TDLS Setup Request frame is received from a TDLS responder STA with which a currently active TDLS session exists, then the receiving STA shall tear down the existing TDLS direct link as if a TDLS Teardown frame was received, and respond with a TDLS Setup Response frame. If no TDLS Setup Response frame is received within dot11TDLSResponseTimeout, or if a TDLS Setup Response frame is received with a status code not equal to SUCCESS, the TDLS initiator STA shall terminate the setup procedure and discard the TDLS Setup Response frame. Otherwise, the TDLS initiator STA shall send a TDLS Setup Confirm frame to the TDLS responder STA to confirm the receipt of the TDLS Setup Response frame. When the BSS does not support EDCA, EDCA may be used on the direct link (on the base channel and on the off-channel), with the default EDCA Parameter Set, per 10.2.4.2. If the STA has security enabled on the link with the AP, then the TPK handshake messages are included in the TDLS Setup frames, as follows: â€” TPK handshake message 1 shall be included in the TDLS Setup Request frame. â€” TPK handshake message 2 shall be included in the TDLS Setup Response frame. â€” TPK handshake message 3 shall be included in the TDLS Setup Confirm frame. When the TDLS setup handshake has been completed, the TDLS initiator STA and the TDLS responder STA are TDLS peer STAs. A TDLS peer STA shall accept Data frames received from the respective TDLS peer STA directly and Data frames destined for the respective TDLS peer STA may be transmitted over the direct link. Subsequent to the successful completion of the TPK handshake, all frames transmitted and received on the TDLS direct link shall be protected using the TPKSA, per the procedures defined in Clause 12. To avoid possible reordering of MSDUs, a TDLS initiator STA shall cease transmitting MSDUs to the TDLS responder STA through the AP after sending a TDLS Setup Request frame, and a TDLS responder STA shall cease transmitting MSDUs to the TDLS initiator STA through the AP after sending a TDLS Setup Response frame indicating status code SUCCESS. The TDLS Setup Request frame and the TDLS Setup Response frame shall be transmitted using the lowest AC that was used for transmitting MSDUs to the respective TDLS peer STA during the previous dot11TDLSACDeterminationInterval seconds, or at AC_BK. When no MSDUs were transmitted during the previous dot11TDLSACDeterminationInterval seconds, then the TDLS Setup Request frame and the TDLS Setup Response frame may be sent at any AC, subject to applicable Admission Control rules. If no TDLS Setup Response frame is received within dot11TDLSResponseTimeout, or if a TDLS Setup Response frame is received with status code other than SUCCESS, the TDLS initiator STA may resume transmitting MSDUs to the TDLS responder STA through the AP. 1768 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If a TDLS Setup Confirm frame is transmitted with a status code other than SUCCESS, the TDLS initiator STA may resume transmitting MSDUs to the TDLS responder STA through the AP. If a TDLS Setup Confirm frame is received with a status code other than SUCCESS, the TDLS responder STA may resume transmitting MSDUs to the TDLS initiator STA through the AP. A TDLS peer STA shall not transmit MSDUs over the direct link before transmitting or receiving a TDLS Setup Confirm frame with status code SUCCESS. 11.23.5 TDLS direct-link teardown To tear down a direct link, a TDLS peer STA shall send a TDLS Teardown frame to the respective TDLS peer STA. A TDLS peer STA shall disable the direct link and delete the related security parameters after successfully transmitting TDLS Teardown frame. If the STA has security enabled on the link with the AP, then the FTE shall be included in the TDLS Teardown frame. The TDLS Teardown frame shall be sent over the direct path and the reason code shall be set to TDLS_UNSPECIFIED_REASON except when the TDLS peer STA is unreachable via the TDLS direct link, in which case, the TDLS Teardown frame shall be sent through the AP and the reason code shall be set to TDLS_PEER_UNREACHABLE. If the direct link is on an off-channel when this condition occurs, then the TDLS peer STA may switch back to the base channel without initiating a channel switch frame exchange, before transmitting the TDLS Teardown frame. If present, the contents of the FTE in the TDLS Teardown frame shall be the same as that included in the TPK handshake message 3 with the exception of the MIC field. The MIC shall be calculated on the concatenation, in the following order, of: â€” Link Identifier element â€” Reason Code â€” Dialog token that was used in the MIC calculation for TPK handshake message 3 â€” Transaction Sequence number (1 octet) which shall be set to the value 4 â€” FTE, with the MIC field of the FTE set to 0 The MIC shall be calculated using the TPK-KCK and the AES-128-CMAC algorithm. The output of the AES-128-CMAC shall be 128 bits. If the TPK handshake was successful for this TDLS session, then a receiving STA shall validate the MIC in the TDLS Teardown frame prior to processing the TDLS Teardown frame; a TDLS Teardown frame in which the MIC validation fails is called an invalid TDLS Teardown frame. A TDLS peer STA that receives a TDLS Teardown frame that is not an invalid TDLS Teardown frame shall disable the direct link and delete the related security parameters. When a TDLS direct link gets torn down, any related TSs shall be deleted by the TDLS peer STAs. A TDLS Teardown frame with Reason Code LEAVING_NETWORK_DEAUTH shall be transmitted to all TDLS peer STAs (via the AP or via the direct path) prior to transmitting a Disassociation frame or a Deauthentication frame to the AP. After receiving a Deauthentication frame or a Disassociation frame from the AP, a Deauthentication frame with Reason Code LEAVING_NETWORK_DEAUTH shall be transmitted via the direct path to all TDLS peer STAs that are in the awake state, if robust management frame protection has not been negotiated on the TDLS direct link. 1769 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.23.6 TDLS channel switching 11.23.6.1 General When a STA enables support for TDLS channel switching, it shall set dot11TDLSChannelSwitching- Activated, dot11MultiDomainCapabilityActivated and dot11ExtendedChannelSwitchActivated to true. When TDLS channel switching is enabled, the STA may set TDLS Channel Switching capability field to 1. The STA shall include a Supported Channels element and a Supported Operating Classes element in all TDLS Setup Request and TDLS Setup Response frames that have a TDLS Channel Switching capability field equal to 1. The STA shall include only channels in the Supported Channels element for which it can adhere to the local power constraint. A channel switch shall not be initiated by a STA when the TDLS peer STA did not set the TDLS Channel Switching capability field to 1 in the transmitted TDLS Setup Request frame or the TDLS Setup Response frame that caused the TDLS direct link to be set up. TDLS Channel Switch Request frames and TDLS Channel Switch Response frames shall be transmitted over the TDLS direct link. TDLS channel switching is different from (I)BSS channel switching as defined in 11.9.8. The target channel is the destination channel of an intended channel switch. The target channel is specified by the STA that initiates a channel switch, from the set of operating classes supported by both TDLS peer STAs. The target channel and operating class are specified in the TDLS Channel Switch Request frame. The Country and Coverage Class settings on the target channel are the same as in the BSS to which both TDLS peer STAs are currently associated. Both STAs are entitled to request a channel switch. The events occurring for a channel switch are illustrated in Figure 11-31. In Figure 11-31, the TDLS peer STAs (STA1 and STA2) are operating on an initial channel. After contending for the medium, STA1 transmits a TDLS Channel Switch Request frame to STA2, via the direct link, indicating a requested switch to a target channel. STA2 transmits an Ack frame (denoted ACK1 in Figure 11-31) after SIFS, and processes the TDLS Channel Switch Request frame. After contending for the medium, STA2 transmits a TDLS Channel Switch Response frame to STA1, possibly also after entering power save mode with the AP. STA1 responds with an Ack frame (denoted ACK2 in Figure 11-31) after SIFS. If the TDLS Channel Switch Response frame indicated with status code REQUEST_DECLINED, then both STAs continue to operate on the current channel. If the TDLS Channel Switch Response frame indicated with status code SUCCESS, then both STAs shall be listening on the target channel not later than SwitchTime after the end of the last symbol of ACK2, as measured on the WM. After switching channels, each TDLS peer STA shall perform a clear channel assessment (CCA) on the target channel, until a frame is detected by which it can set its NAV, or until a period of time equal to at least dot11TDLSNavSync has transpired (this combined event is indicated as â€œProbeTimeâ€ in Figure 11-31). The first transmission on the target channel shall be preceded by a random backoff, which shall start at the end of the ProbeTime. The first transmission on the new channel shall not start before the end of SwitchTime. The initiator of the channel switch shall transmit a Data frame on the target channel, unless the SwitchTimeout has expired or the responder to the channel switch transmitted a Data frame on the target channel. If no successful frame exchange has occurred on an off-channel within SwitchTimeout after the end of the last symbol of ACK2, as measured on the WM, a STA shall go back to the base channel, where they shall be listening not later than SwitchTime after the end of the SwitchTimeout. After changing channels (either from the base channel to the off-channel or from the off-channel to the base channel), a TDLS peer STA shall perform CCA until a frame is detected by which it can set its NAV, or until a period of time equal to the ProbeTime has transpired. 1770 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Figure 11-31â€”Events occurring for a TDLS direct-link channel switch 1771 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Both the TDLS Channel Switch Request frame and the TDLS Channel Switch Response frame shall contain a Channel Switch Timing element. The SwitchTime and SwitchTimeout values in the TDLS Channel Switch Timing element included in the TDLS Channel Switch Request frame shall specify the values required at the STA sending the TDLS Channel Switch Request frame. The SwitchTime and SwitchTimeout values specified in the TDLS Channel Switch Timing element included in the TDLS Channel Switch Response frame shall meet the requirements at the STA sending the TDLS Channel Switch Response frame and shall be equal to or larger than the values specified in the TDLS Channel Switch Request frame. The timing parameters specified in the Channel Switch Timing element included in the TDLS Channel Switch Response frame shall be used for the TDLS channel switching procedure. This procedure causes the larger of the two switch times to become the value that is transmitted in the TDLS Channel Switch Response frame. The TDLS peer STA shall be in PS mode with the AP and shall not be involved in an active Service Period with the AP before sending a TDLS Channel Switch Request frame or a TDLS Channel Switch Response frame with Status Code set to SUCCESS. The TDLS peer STA that receives a TDLS Channel Switch Request frame may enter PS mode with the AP prior to sending the TDLS Channel Switch Response frame. Because there is at least a backoff between the TDLS Channel Switch Request frame and the TDLS Channel Switch Response frame, there is a (small) probability that two STAs issue a TDLS Channel Switch Request frame at more or less the same time. To reduce the probability for this event to occur, a TDLS peer STA should not transmit a TDLS Channel Switch Request frame when a TDLS Channel Switch Request frame is received and no TDLS Channel Switch Response has been transmitted in response. If a TDLS Channel Switch Request frame is received from the TDLS peer STA to which a pending TDLS Channel Switch Request frame was previously sent before receiving TDLS Channel Switch Response, the TDLS initiator STA shall not reply to the TDLS Channel Switch Request frame and the TDLS responder STA shall reply to the TDLS Channel Switch Request frame. If a TDLS Channel Switch Response frame does not imply a channel switch because the STAs already are on the requested channel, then the SwitchTime and ProbeTime may be skipped and both TDLS peer STAs continue to operate on the requested channel. To cross means that a TDLS Channel Switch Request frame is received from a peer STA after transmitting a TDLS Channel Switch Request frame to the TDLS peer STA, instead of the expected TDLS Channel Switch Response frame. When a TDLS peer STA does not receive an acknowledgment to a TDLS Channel Switch Response frame, it may retransmit the frame but the number of retransmissions shall be lesser of the maximum retry limit and dot11TDLSPeerSTAMissingAckRetryLimit. A channel switch from an off-channel to the base channel may be accomplished by sending a TDLS Channel Switch Response frame indicating the base channel as the target channel, without prior TDLS Channel Switch Request frame. The Channel Switch Timing element shall be the same as contained in the Channel Switch Response frame that caused the switch to the off-channel. TDLS Channel Switching shall not be used when the TDLS Channel Switching Prohibited subfield included in the Extended Capability element of the Association Response frame or Reassociation Response frame that led to the current association is equal to 1. 11.23.6.2 General behavior on the off-channel If dot11SpectrumManagementRequired is true, a TDLS peer STA shall not transmit a TDLS Channel Switch request specifying an off-channel where radar detection is required, unless the STA has tested that channel for the presence of radar, according to regulatory requirements. If a TDLS peer STA that is operating in such a channel detects radar, the TDLS peer STA shall discontinue transmissions according to regulatory requirements, and it shall send a TDLS Channel Switch Request frame indicating a switch to the base channel. The channel switch avoids an interruption on the direct link. 1772 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The TDLS peer STA initiating the switch to the channel where radar detection is required by regulation shall be the DFS owner. The secondary channel of an existing 40 MHz network shall not be selected as an off-channel. On an off-channel, the TDLS peer STAs remain associated with their BSS, so the BSSID remains the same. It is recommended that in general TDLS STAs propose target channels that have no detectable medium occupancy. If no such channel is available, then it is recommended that the TDLS STA propose a target channel where beacons are detected but with little or no additional medium occupancy. It is further recommended that TDLS STAs do not propose a target channel where the presence of beacons indicate that ACM bits are set, unless little or no additional medium occupancy is detected. 11.23.6.3 Setting up a 40 MHz direct link 11.23.6.3.1 General A 40 MHz off-channel direct link may be started if both TDLS peer STAs indicated 40 MHz support in the Supported Channel Width Set field of the HT Capabilities element (which is included in the TDLS Setup Request frame and the TDLS Setup Response frame). Switching to a 40 MHz off-channel direct link is achieved by including the following information in the TDLS Channel Switch Request frame: â€” Operating Class field indicating 40 MHz Channel Spacing â€” Secondary Channel Offset field indicating SCA or SCB A 40 MHz off-channel direct link shall not be established in the 2.4 GHz band. The TDLS peer STA initiating the switch to the 40 MHz off-channel shall be the DO. 11.23.6.3.2 Basic 40 MHz functionality TDLS peer STAs may transmit 40 MHz PPDUs on a 40 MHz direct link. A TDLS peer STA shall not transmit a 20 MHz PPDU in the secondary channel of its 40 MHz direct link. 11.23.6.3.3 Channel selection for a 40 MHz direct link If a TDLS peer STA chooses to start a 40 MHz direct link that occupies the same two channels as an existing 40 MHz network (i.e., a 20/40 MHz BSSs or a 40 MHz direct link), then it shall select primary and secondary channels of the new direct link that are identical to the primary and secondary channels of the existing 40 MHz network, unless the TDLS peer STA discovers that on these two channels there are existing 40 MHz networks with different primary and secondary channels. If a TDLS peer STA chooses to start a 40 MHz direct link, the selected secondary channel should correspond to a channel on which no beacons are detected. 11.23.6.3.4 Switching from a 40 MHz to a 20 MHz direct link Switching from a 40 MHz off-channel direct link to a 20 MHz off-channel direct link is established through a TDLS channel switch. When on a 40 MHz off-channel direct link, a requested switch to a 20 MHz direct link shall always be accepted. 1773 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.23.6.3.5 CCA sensing and NAV assertion in a 40 MHz direct link When active on a 40 MHz direct link, a TDLS peer STA shall follow the CCA rules as defined in 11.16.9 and the NAV rules as defined in 11.16.10. 11.23.6.4 TDLS channel switching and power saving A TDLS direct link shall not be switched to an off-channel during a TPU service period. While on an off- channel, a TDLS peer STA shall not enter TPU power save mode. A TDLS direct link may be switched to an off-channel when TDLS peer PSM is active on the link. The wakeup windows occur on the off-channel in the same way they would have occurred had the STAs remained on the base channel. Suspension of the wakeup windows implies a switch back to the base channel. 11.23.6.5 Setting up a wide bandwidth off-channel direct link 11.23.6.5.1 General A wideband off-channel TDLS direct link is a 40 MHz, 80 MHz, 160 MHz, or 80+80 MHz off-channel TDLS direct link. A wideband off-channel TDLS direct link may be started if both TDLS peer STAs indicated wideband support in the VHT Capabilities element VHT Capabilities Information field included in the TDLS Setup Request frame or the TDLS Setup Response frame. Switching to a wideband off-channel direct link is achieved by including any of the following information in the TDLS Channel Switch Request frame: â€” An Operating Class element indicating 40 MHz Channel Spacing and a Secondary Channel Offset element indicating SCA or SCB â€” A Wide Bandwidth Channel Switch element indicating 80 MHz, 160 MHz, or 80+80 MHz channel width The operating class in TDLS Channel Switch Request frame shall have a value representing 5 GHz for the channel starting frequency. A TDLS peer STA that is extended spectrum management capable and that announces new TPC parameters that come into effect at the same time as the switch to an off-channel direct link, shall include at least one Transmit Power Envelope element in the transmitted the TDLS Channel Switch Request frame. The recipient TDLS peer STA that is extended spectrum management capable and that has dot11SpectrumManagementRequired or dot11RadioMeasurementActivated equal to true shall use the parameters in these received element(s) in the recipient STAâ€™s TPC calculations for the off-channel direct link. When announcing new operating classes or both a new operating class table index and new operating classes that come into effect at the same time as the switch to the direct link and that express new regulatory requirements, the TDLS peer VHT STA initiating the switch shall include a Country element in a transmitted TDLS Channel Switch Request frame. The Country element shall contain all of the Operating Classes for the off-channel direct link in Operating Triplet fields and zero Subband Triplet fields. The Country element shall include one Operating Triplet field that contains the same Operating Class as the Operating Class field in the same frame. The country indicated by the Country string in the TDLS Channel Switch Request frame shall be equal to the country indicated by the Country string of the BSS. The recipient TDLS peer VHT STA that has dot11MultiDomainCapabilityActivated, 1774 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11SpectrumManagementRequired, or dot11RadioMeasurementActivated equal to true shall use the parameters in the received Country element in the TDLS Channel Switch Request frame in order to maintain regulatory compliance. The TDLS peer STA initiating the switch to the wideband off-channel shall be the DO on that channel. 11.23.6.5.2 Basic wideband functionality TDLS peer STAs may transmit up to 40 MHz, 80 MHz, 160 MHz, or 80+80 MHz PPDUs on a 40 MHz, 80 MHz, 160 MHz, or 80+80 MHz direct link, respectively. A TDLS peer STA shall not transmit a 20 MHz PPDU in the nonprimary channel of its 80 MHz, 160 MHz, or 80+80 MHz direct link. A TDLS peer STA shall not transmit a 40 MHz PPDU that does not use the primary 40 MHz channel of its 80 MHz, 160 MHz, or 80+80 MHz direct link. A TDLS peer STA shall not transmit an 80 MHz PPDU that does not use the primary 80 MHz channel of its 160 MHz or 80+80 MHz direct link. 11.23.6.5.3 Channel selection for a wideband off-channel direct link If a TDLS peer STA chooses to start a wideband direct link, the TDLS peer STA shall follow the primary channel selection rules defined in 11.40.2 and 11.24.15 and the secondary 80 MHz channel rule defined in 11.23.1. 11.23.6.5.4 Switching from a wideband to a 20 MHz direct link Switching from a wideband off-channel direct link to a 20 MHz off-channel direct link is established through a TDLS channel switch. A STA operating on a wideband off-channel direct link shall accept a requested switch to a 20 MHz direct link. 11.23.6.5.5 CCA sensing and NAV assertion in a 20 MHz, 40 MHz, 80 MHz, 160 MHz, or 80+80 MHz direct link TDLS peer VHT STAs shall follow the CCA rules defined in 10.3.2.6, 10.22.2.7, and 10.22.3 and the NAV rules defined in 11.40.5. 11.24 Wireless network management procedures 11.24.1 Wireless network management dependencies When dot11WirelessManagementImplemented is true, the STA is a WNM STA and dot11ExtendedChannelSwitchActivated and dot11RadioMeasurementActivated shall be true. This subclause describes WNM procedures for requesting and reporting WNM capabilities between STAs that support WNM procedures. When dot11WirelessManagementImplemented is true, and one or more of bit 7 to bit 27 in the Extended Capabilities element have the value 1, the Extended Capabilities element shall be included in Beacon frames, Association Request and Response frames, Reassociation Request and Response frames, and Probe Request and Response frames. When dot11WirelessManagementImplemented is true, for each bit 7 to bit 27 in the received Extended Capabilities element that is 0, a STA shall not request the corresponding feature from the sending STA. A WNM STA receiving a request for a WNM feature from another STA shall reject the request if the receiving WNM STA has not advertised support for the corresponding WNM feature. 1775 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.24.2 Event request and report procedures 11.24.2.1 Event request and event report The Event Request and Event Report frames enable network real-time diagnostics. A STA whose dot11EventsActivated is true shall support event requests and reports and shall set to 1 the Event field of the Extended Capabilities elements that it transmits. If dot11EventsActivated is true, a STA shall log all Transition, RSNA, peer-to-peer, and WNM log events, including the corresponding TSF, UTC Offset and Event Time Error. The STA log of events shall not be cleared as a result of BSS transitions. However, if the STA moves to a different ESS or IBSS, the STA shall delete all event log entries. A STA that supports event reporting may send an Event Request or Event Report frame to a STA within the same infrastructure BSS or the same IBSS whose last received Extended Capabilities element contained a value of 1 for the Event bit in the Extended Capabilities field; it shall not send an Event Request or Event Report frame otherwise. If the STA receives an Event Request frame without error and it supports event reporting, it shall respond with an Event Report frame that includes a value of the Dialog Token field that matches the one in the Event Request frame. The permitted source and destination STAs for an Event Request frame are shown in Table 11-9. An AP may include zero or more Event Request elements in an Event Request frame. Each Event Request element contains an Event Token that associates this Event Request with any subsequent Event Report elements. When sending Event Report elements, a STA shall use the same Event Token that was included in the original request. Only a single Event Request frame from a STA is outstanding at a given STA at any time. If a STA that supports event reporting receives a subsequent Event Request frame with a different dialog token before completing the Event Report for the previous request from the requesting STA, the receiving STA may respond to the most recent request frame; it shall not respond to a request frame that is not the most recent one. Upon a BSS transition, the STA shall cancel any event requests in the latest Event Request frame. The Event Request elements can contain conditions that specify events to be reported and conditions that establish event reporting when a STA experiences problems or failures. A STA sends an Event Request frame containing one or more Event Request elements, each of which contains zero or more subelements. Subelements are defined for each event type. A STA shall include in the corresponding Event Report element only those events that meet the specified event conditions within the current ESS or IBSS. In each Event Report element, a STA shall include a Status field that indicates the result of the event request/ report transaction. If the STA is able to return one or more Event Report elements, then the STA shall return a value of â€œSuccessfulâ€ in the Event Report element. If the STA has no logged events of the requested type, the STA shall return a value of Successful in the Event Report element without an event included in the Event Report field. If the STA is unable to process the request at that time, the STA shall return a value of â€œRequest failedâ€ in the Event Report element. If a STA refuses an event request, the STA shall return a value of â€œRequest refusedâ€ in the Event Report element. The reasons for refusing an event request are outside the scope of this standard but may include reduced quality of service, unacceptable power consumption, measurement scheduling conflicts, or other significant factors. If the STA is incapable of generating an Event Report of the type specified in the Event Request frame, the STA shall return a value of â€œRequest incapableâ€ indicating that the requester should not request again. 1776 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If the Event Report elements do not fit into a single MMPDU, the reporting STA shall send the remaining elements in additional Event Report frames until all Event Report elements have been returned to the requesting STA. In any subsequent Event Report frame and for all remaining Event Report elements a reporting STA shall include the same values of the Dialog Token and Event Token fields, respectively, that was sent in the corresponding Event Request frame. When multiple MMPDUs are required, the non-AP STA shall include complete Event Report elements and shall not fragment an element across multiple MMPDUs. A STA shall transmit both the Event Request frame and the Event Report frame only with an individually addressed destination address. In an infrastructure BSS, only an AP shall transmit an Event Request frame to a non-AP STA. An AP that supports event reporting shall discard received Event Request frames. When a STA transmits an Event Request frame to another STA it shall indicate the types of events requested by setting the Event Type field and shall indicate the maximum number of logged events to report by using the Event Response Limit field in each included Event Request element. If the number of available logged events of the requested type exceeds the Event Response Limit, the STA shall report an Event Response Limit number of the most recent events. If there are no available logged events of the type specified in the Event Request frame, the STA shall send the Event Report frame without any Event Report element. The reporting STA shall send all available Event Report elements for the requested Event Type when the Event Request field is not present in the Event Request element. A STA may include a Destination URI element in the Event Request frame. The AP includes the URI in the Destination URI element that the reporting non-AP STA may use to send Event Reports, upon the loss or interruption of connectivity to the BSS. On receipt of an Event Request frame with an Destination URI element, the reporting non-AP STA SME may send the Event Report to the AP using the Destination URI with another network interface (if available). The non-AP STA SME shall not send the Event Report to the URI contained in the Destination URI element except after detecting loss of BSS connection. The non-AP STA shall determine loss of connection to the AP that issued the Event Request frame when it has not detected any Beacon frames from the AP for a period no less than the ESS Detection Interval. If the BSS connection is reestablished to the AP that transmitted the Event Request frame, the non-AP STA shall transmit the corresponding Event Report frame to the AP without using the Destination URI. When the non-AP STA uses the Destination URI mechanism, it shall transport the Frame Body field of the Event Report frame using the URI given in the Destination URI Element. An example use of the Destination URI is given in Annex Q. 11.24.2.2 Transition event request and report The Transition Event report provides information on the previous transition events for a given non-AP STA. The Transition Event request and report are only permitted in the infrastructure BSS. Each STA supporting the Transition Event shall log up to the last five Transition events occurring since the STA associated to the ESS. A STA may log more than five of the most recent Transition events. Upon receipt of an Event Request frame containing an Event Request element including a Transition Event request, the non-AP STA shall respond with an Event Report frame that includes available Event Report elements within the current ESS for the Transition event type. Transition Event Request subelements are used to specify conditions for reporting of transition events. If any Transition Event Request subelements are present in the Event Request frame, the reporting non-AP 1777 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STA shall include in the Event Report frame only those available Transition Event Report elements that meet the transition event reporting condition(s) specified in the Event Request frame. If no transition event subelements are present in the Event Request field, the reporting STA shall include all available Transition Event Report elements. A Frequent Transition subelement in an Event Request frame defines conditions for frequent transition. Frequent transition occurs when the number of BSS transitions exceeds the value of the Frequent Transition Count Threshold within the indicated Time Interval value as defined in the Frequent Transition subelement in 9.4.2.67.2. A STA that receives a Frequent Transition subelement shall, at each BSS transition, apply the conditions for frequent transition to the log of transition events. If the logged transition events meet the conditions for frequent transition, the STA shall send an Event Report frame including a Transition Event Report element with Event Report Status set to Detected Frequent Transition and include in that Event Report element the last logged transition event. For transition logging and reporting purposes, the transition time is defined as the time difference between the starting time and the ending time of a transition between APs, even if the transition results in remaining on the same AP. The starting time is one of the following items: â€” The start of a search for an AP, when the transition reason is 4 (first association to WLAN). â€” The latest time that a frame could have been transmitted or received on the source BSS. â€” The start of a search for an AP, after determination that a transition has failed. The ending time is one of the following items: â€” The earliest time that a Data frame can be transmitted or received on the target BSS, after completion of RSN, IEEE 802.1X, or other authentication and key management transmissions, when such are required by the target BSS. â€” The time that a determination is made that the transition has failed. 11.24.2.3 RSNA event request and report The RSNA Event Report provides authentication events for a given non-AP STA. The RSNA Event Request and Report are only permitted in an infrastructure BSS. Each STA supporting the RSNA Event shall log up to the last five RSNA events occurring since the STA associated to the ESS. A STA may log more than five of the most recent RSNA events. Upon receipt of an Event Request frame containing an Event Request element including an RSNA Event request, the non-AP STA shall respond with an Event Report frame that includes available Event Report elements within the current ESS for the RSNA event type. If an RSNA Event Request subelement is present in the Event Request field, the reporting non-AP STA shall include available Event Report elements that meet the specified condition for the RSNA event type. If no RSNA Event Request subelement is present in the Event Request field, the reporting STA shall include all available RSNA Event Report elements. 11.24.2.4 Peer-to-peer link event request and report The peer-to-peer link event report provides peer-to-peer connectivity events for a given non-AP STA. A peer-to-peer event occurs when a peer-to-peer link is initiated or terminated. 1778 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Each STA supporting the peer-to-peer event shall log up to the last five peer-to-peer events occurring since the STA associated to the ESS or IBSS. A STA may log more than five of the most recent peer-to-peer events. When a link is initiated, a STA shall log and record the TSF time of the peer-to-peer event without a connection time. When a peer-to-peer link is terminated, a STA shall log the peer-to-peer link event including the connection time for the terminated link and shall delete from the log any initiation event for the same peer-to-peer link. Upon receipt of an Event Request frame containing an Event Request element including a peer-to-peer link event request, the non-AP STA shall respond with an Event Report frame that includes available Event Report elements within the current ESS or IBSS for the peer-to-peer event type. When a STA includes a Peer-to-Peer Event Report element for a link initiation, the STA shall include a connection time for the event report element which indicates the time difference from the event timestamp to the current time. If a Peer-to-Peer Link Event Request subelement is present in the Event Request field, the reporting non-AP STA shall include available Event Report elements that meet the specified condition for the Peer-to-Peer event type. If no Peer-to-Peer Link Event Request subelements are present in the Event Request field, the reporting STA shall include all available Peer-to-Peer Event Report elements. 11.24.2.5 WNM log event request and report The WNM log event report is intended to capture PHY and MAC layer events related to the operation of those layers in vendor-specific, human-readable (ASCII text) form. The WNM log is a general reporting mechanism that can apply to configuration or monitoring behavior for PHY and MAC. The WNM log is particularly useful for logging success or failure events across areas such as driver status, IEEE 802.11 or IEEE 802.1X authentication, authorization, status changes while associated or unassociated. For example: <0>Oct 03 17:47:00 00:01:02:03:04:05 Adapter DLL Service initialized <1>Oct 03 17:48:40 00:01:02:03:04:05 Authentication started <1>Oct 03 17:48:46 00:01:02:03:04:05 IEEE 802.1X Authentication Failed, credential failure <1>Oct 03 17:49:00 00:01:02:03:04:05 Authentication success A non-AP STA that supports event reporting may be queried at any time for its current set of WNM log messages. The WNM log messages returned by the non-AP STA may provide insight into the trouble being experienced by non-AP STA. Upon receipt of an Event Request frame containing an Event Request element including a WNM log event request, the non-AP STA shall respond with an Event Report frame that includes WNM Log Event Report elements. 11.24.2.6 Vendor Specific event request and report The procedures for use of the Vendor Specific Event Request and Report are vendor specific and are not part of this standard. 11.24.3 Diagnostic request and report procedures 11.24.3.1 Diagnostic request and diagnostic report The Diagnostic Request and Diagnostic Report protocol provides a tool to diagnose and debug complex network issues. A STA whose dot11DiagnosticsActivated is true shall support diagnostic reporting and shall set to 1 the Diagnostics field of the Extended Capabilities elements that it transmits. 1779 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A STA that supports diagnostics reporting shall send a Diagnostics Request or Diagnostics Report frame to a STA within the same infrastructure BSS or the same IBSS whose last received Extended Capabilities element contained a value of 1 for the Diagnostics bit in the Extended Capabilities field; it shall not send a Diagnostics Request or Diagnostics Report frame otherwise. The Diagnostic Request frame contains a unique Dialog Token. A value of the Dialog Token field of 0 is a reserved value and shall not be used. The source and destination of a Diagnostic Request frame shall both be members of the same BSS. The permitted source and destination STAs for a Diagnostic Request frame are shown in Table 11-9. A STA may include one or more Diagnostic Request elements in a Diagnostic Request frame. Each Diagnostic Request element contains a unique Diagnostic Token that identifies the element within the Diagnostic Request frame. If a STA that supports diagnostic reporting receives a Diagnostic Request frame without error, the STA shall respond with a Diagnostic Report frame that includes a value of the Dialog Token field that matches the one in the Diagnostic Request frame. Each Diagnostic Report element that corresponds to the Diagnostic Request element shall contain the same Diagnostic Token that was included in the original request. Only a single Diagnostic Request frame from a STA is outstanding at a given STA at any time. If a STA receives a subsequent Diagnostic Request frame with a different dialog token before completing the Diagnostic Report for the previous request from the requesting STA, the STA shall respond to the most recent Diagnostic Request frame; the STA shall not respond to a Diagnostic Request frame that is not the most recent one. All outstanding diagnostic requests, as indicated by received MLME-DIAGREQUEST.indication primitives, are canceled upon a BSS transition, except when the BSS transition occurs as a result of responding to or initiating a diagnostic request. All outstanding diagnostic requests, as indicated by received MLME-DIAGREQUEST.indication primitives, are canceled after the time indicated in the Diagnostic Timeout field, in the Diagnostic Request frame. When a STA that supports diagnostic reporting receives a Diagnostic Request frame with a Diagnostic Request Type of Cancel Diagnostic Request, the STA cancels all outstanding diagnostic requests, and discards all pending diagnostic reports, as indicated by received MLME-DIAGREQUEST.indication primitives. All Diagnostic Report elements shall include a Status field that indicates the overall result of the transaction. If the STA is able to complete the diagnostic request made in the Diagnostic Request element, then a value of â€œSuccessfulâ€ shall be returned. If the STA is unable to process the request at that time a value of â€œFailâ€ shall be returned. If the STA is incapable of generating a report of the type specified, it shall return a value of â€œIncapable.â€ If the STA cannot support the request for any other reason, the value of Refused shall be returned. A STA shall transmit both the Diagnostic Request frame and the Diagnostic Report frame with an individually addressed destination address. A STA may include a Destination URI element in the Event Request frame. The AP includes the URI in the Destination URI element that the reporting non-AP STA may use to send Diagnostic Reports, upon the loss or interruption of connectivity to the BSS. On receipt of an Diagnostic Request frame with an Destination URI element, the reporting non-AP STA SME may send the Diagnostic Report to the AP using the Destination URI with another network interface (if available). The non-AP STA shall determine loss of connection to the AP that issued the Diagnostic Request frame when it has not detected any Beacon frames from the AP for a period no less than the ESS Detection Interval. 1780 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If the BSS connection is reestablished to the AP that transmitted the Diagnostic Request frame, the non-AP STA shall transmit the corresponding Diagnostic Report frame to the AP without using the Destination URI. When the non-AP STA uses the Destination URI mechanism, it shall transport the payload of the Diagnostic Report frame using the URI given in the Destination URI Element. An example use of the Destination URI is given in Annex Q. If a non-AP STA that receives an Destination URI subelement in an Diagnostic Request fails to detect any Beacon frames, belonging to the AP that issued the request for a Diagnostic report, for the period specified by the ESS detection interval, it may use the URI specified in the Destination URI subelement to transport the Diagnostic Report to the AP. If the Diagnostic Report elements do not fit into a single MMPDU, the reporting STA shall send the remaining elements in additional frames until all Diagnostic Report elements have been returned to the requesting STA. A STA shall include the same values of the Dialog Token and Diagnostic Token fields that were transmitted in the corresponding Diagnostic Request frame in each subsequent Diagnostic Report frame and Diagnostic Report elements. When multiple MMPDUs are required, the STA shall include complete Diagnostic Report elements and shall not fragment an element across multiple MMPDUs. A STA that supports diagnostic reporting may cancel a previously sent Diagnostic Request frame for which it has not yet received a Diagnostic Report frame by sending a Diagnostic Request frame with the Diagnostic Request Type field value of 0, indicating â€œCanceled,â€ to the STA to which it previously sent the Diagnostic Request frame. A STA that supports diagnostic reporting shall inform a STA from which it has previously received a Diagnostic Request frame that the request has been locally canceled by sending a Diagnostic Report frame with the Diagnostic Status field set to a value of 4, indicating â€œCanceled,â€ to the requesting STA. In a Diagnostic Request frame with the Diagnostic Request Type field value of 0, and a Diagnostic Report frame with the Diagnostic Status field set to a value of 4, no Diagnostic subelements are included in the Diagnostic Request or Response element. 11.24.3.2 Configuration Profile report The Configuration Profile report enables an AP to discover the current profile in use for an associated device, and additional profiles for the current ESS. A non-AP STA that supports diagnostic reporting and receives a Configuration Profile report request type shall respond with a Diagnostic Report frame that includes all available Diagnostic elements allowed for the type. Devices that support multiple configuration profiles for an ESS may include multiple Diagnostic Report elements in a single Diagnostic Report frame (or multiple frames if required). Each Diagnostic Report element shall contain a Profile ID element that uniquely identifies the configuration profile(s) for the current ESS that are available on the device. 11.24.3.3 Manufacturer information STA report The Manufacturer Information STA Report enables an AP to discover static manufacturer specific data about an associated STA device. A non-AP STA that supports diagnostic reporting and receives a Manufacturer Information STA Report request type shall respond with a Diagnostic Report frame that includes all available Diagnostic elements allowed for the type. When more than one Antenna Type/Antenna Gain pair is enabled, multiple Antenna Type subelements shall be included in the Manufacturer Information STA Report Diagnostic Report element. When more than one Collocated Radio Type, or Device Type is supported, multiple Collocated Radio Type subelements, or Device Type subelements shall be included in the Manufacturer Information STA Report 1781 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Diagnostic Report element. If the existence or the type of collocated radio is unknown, no Collocated Radio Type subelements shall be included. 11.24.3.4 Association diagnostic The purpose of the association diagnostic is to determine that a STA is able to associate with a designated BSS. This test directs an association to be completed with a specific AP. To initiate the test, an AP that supports diagnostic reporting shall send a Diagnostic Request frame containing a Diagnostic Request Type field set to 3 (i.e., Association Diagnostic) to a STA that supports diagnostic reporting. The AP shall not send an association diagnostic request with a designated BSS that is not part of the ESS and the STA receiving an association diagnostic request shall reject requests to perform diagnostics on a BSS that is not part of the ESS. All parameters required to complete the association are included in the Diagnostic Request element. Upon receipt of the Diagnostic Request frame containing a Diagnostic Request element specifying an association request, the STA determines whether to accept the request. If the STA declines the request, it shall send a Diagnostic Report frame with the Status field of a Diagnostic Report element set to Refused. If the STA accepts the request, it shall cause an authentication to occur to the AP indicated in the Diagnostic Request element and the STAâ€™s SME shall issue an MLME-DIAGREPORT.request primitive, indicating the results of the diagnostic. One means to cause an authentication to occur is for the STAâ€™s SME to issue an MLME- DEAUTHENTICATE.request primitive to deauthenticate from the current AP, and an MLME- AUTHENTICATE.request primitive to authenticate to the AP indicated in the Diagnostic Request element. If successful, the STA shall issue an MLME-(RE)ASSOCIATE.request primitive to associate with the AP indicated in the Diagnostic Request element. If successful, the STAâ€™s SME shall then issue an MLME- DEAUTHENTICATE.request primitive to deauthenticate from the AP indicated in the Diagnostic Request element, reassociate with the AP from which it received the Diagnostic Request, and issue an MLME- DIAGREPORT.request primitive, indicating the results of the diagnostic. 11.24.3.5 IEEE 802.1X authentication diagnostic The purpose of the IEEE 802.1X authentication diagnostic is to determine that the STA is able to complete an IEEE 802.1X authentication with a designated BSS. This test directs an association and IEEE 802.1X authentication to be completed with a specific AP. If a STA that supports diagnostic reporting also supports RSN, the STA shall support the IEEE 802.1X authentication diagnostic. To initiate the test, an AP that supports diagnostic reporting shall send a Diagnostic Request frame containing a Diagnostic Request Type field set to 4 (i.e., IEEE 802.1X Authentication Diagnostic) to a STA that supports diagnostic reporting. A STA that supports diagnostic reporting in an IBSS or an AP that supports diagnostic reporting shall not send an IEEE 802.1X authentication diagnostic request with a designated BSS that is not part of the ESS, or IBSS and a STA that supports diagnostic reporting which receives a diagnostic request shall reject requests to perform diagnostics on other networks. The AP, EAP method and credential type values included in the AP Descriptor, EAP Method and Credential Type subelements in the Diagnostic Request element shall be used to complete the association and IEEE 802.1X authentication. Upon receipt of the Diagnostic Request frame containing a Diagnostic Request element specifying an IEEE 802.1X Authentication Diagnostic request, the STA determines whether to accept the request. If the STA declines the request, it shall send a Diagnostic Report frame with the Status field of a Diagnostic Report element set to Refused. If the STA accepts the request, it shall cause an IEEE 802.1X authentication to occur to the AP indicated in the Diagnostic Request element and the STAâ€™s SME shall issue an MLME- DIAGREPORT.request primitive indicating the results of the diagnostic. 1782 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications One means to cause an authentication to occur is for the STAâ€™s SME to issue an MLME- DEAUTHENTICATE.request primitive to deauthenticate from the current AP, and an MLME- AUTHENTICATE.request primitive to authenticate to the AP indicated in the Diagnostic Request element. If successful, the STA shall issue an MLME-(RE)ASSOCIATE.request primitive to the AP indicated in the Diagnostic Request element. If (re)association succeeds, the STA shall try to complete IEEE 802.1X authentication using parameters specified in the Diagnostic Request element. The STA shall then issue an MLME-DEAUTHENTICATE.request primitive to deauthenticate from the AP indicated in the Diagnostic Request element, reassociate with the AP from which it received a diagnostic request, and issue an MLME- DIAGREPORT.request primitive, indicating the results of the diagnostic. 11.24.4 Location track procedures 11.24.4.1 Location track configuration procedures A STA whose dot11LocationTrackingActivated is true shall support location tracking and shall set to 1 the Location field of the Extended Capabilities elements that it transmits. In an infrastructure BSS, a non-AP STA shall not transmit Location Configuration Request frames. A STA that supports location may configure another STA to transmit Location Track Notification frames for the purpose of tracking the receiving STAâ€™s location by sending Location Indication Channels, Location Indication Interval and Location Indication Broadcast Data Rate subelements in a Location Parameters element in a Location Configuration Request frame. The minimum Normal and In-Motion Report Interval in a Location Configuration Request frame is 500 ms. A STA may transmit the Location Configuration Request frame as a broadcast or individually addressed frame. A STA that supports location and receives a broadcast Location Configuration Request frame shall send a Location Configuration Response frame if the STA does not accept the parameters included in the Location Configuration request; the STA shall not send a Location Configuration Response frame if it accepts the parameters included in the Location Configuration request. A STA that supports location and receives an individually addressed Location Configuration Request frame shall respond with a Location Configuration Response frame. Upon reception of a new Location Configuration Request frame, the STA shall override any information from a previously received Location Configuration Request frame with the new frame. If all Location Parameter subelements included in the Location Configuration Request frame are successfully configured on the receiving STA, then the STA shall include in the Location Configuration Response frame a single Location Status subelement indicating success. Upon successful configuration, the receiving STA shall start transmitting the Location Track Notification frames based on the Location Configuration Request frame parameters, as described in 11.24.4.2. If one or more Location Parameter subelements are unsuccessfully configured, then the STA shall include in the Location Configuration Response frame a Location Status subelement for each failed subelement indicating the subelement ID, the status value and the corresponding Location Parameter subelement as described in the paragraphs that follow. The Location Status subelement has four possible status values: Success, Fail, Refused and Incapable. When the requesting STA receives a Location Configuration Response frame with Location Status indicating anything other than Success, the requesting STA shall assume the original request was not processed and no configuration took effect on the receiving STA and the requesting STA should take appropriate action based on the status value returned. 1783 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications For Location Status Fail: â€” If the receiving STA has been configured successfully prior to the current Location Configuration Request and continues to transmit Location Track Notification frames based on those parameters, the STA shall respond with its current Location Parameters subelements values. â€” If the STA has no previously configured value, the STA shall respond with its minimum Location Parameters subelements that it is capable of supporting. â€” The configuring STA may either retry the original request or send an alternate request. For Location Status Incapable: â€” The STA responding to the configuration request may include the minimum Location Parameters subelements that it is capable of supporting. â€” The configuring STA shall not send another configuration request matching the previous configuration request while the reporting STA is associated to the same BSS. â€” The configuring STA may send an alternate request. For Location Status Refuse: â€” The STA responding to the configuration request may include the minimum Location Parameters subelements that it is capable of supporting. â€” The configuring STA may send an alternate request. The location configuration methods, from highest to lowest precedence, are as follows: 1) an individually addressed Location Configuration Request frame, 2) broadcast Location Configuration Request frame. When a STA receives a new Location Configuration frame at the same or higher precedence than the previous it shall cancel the previous configuration and begin using the newest configuration. The Location Indication Broadcast Data Rate subelement included in Location Configuration Request frames indicates the target data rate at which the STA shall transmit Location Track Notification frames. The Location Indication Broadcast Data Rate included in the Location Configuration Request frame should be a data rate defined in the basic data rate set. The Indication Multicast Address field configured in the Location Indication Parameters subelement shall be a multicast locally administered IEEE MAC address as defined in IEEE Std 802 that is shared across all APs in the same ESS. The STA shall transmit Location Track Notification frames to the Indication Multicast Address with the BSSID field set to the wildcard BSSID. An AP shall discard Location Track Notification frames that are not addressed to the Indication Multicast Address field configured for the ESS. A non-AP STA shall terminate the transmission of Location Track Notification frames for any of the following reasons: â€” The non-AP STA receives a Location Configuration Request frame from the STA to which it is currently associated that includes a Location Parameters element with a Location Indication Parameters subelement specifying an interval of 0. â€” The non-AP STA fails to detect any Beacon frames, belonging to the same ESS that originally configured the non-AP STA, for the period specified by the essDetectionInterval value included in the Location Parameters element transmitted in the Location Configuration Request frame. â€” dot11LocationTrackingActivated is false. â€” The non-AP STA is disassociated for any reason from the ESS that configured it, including power off, or is configured by a different ESS. â€” In an IBSS when the STA detects that it is no longer connected to the other STA that formed the IBSS. 1784 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NOTEâ€”All Public Action frames, including the Location Track Notification frames, are Class 1 frames and the treatment of Public Action frames upon reception by STAs is defined in 11.3. 11.24.4.2 Location track notification procedures Implementation of location track notification is optional for a WNM STA. A STA that implements location track notification has dot11LocationTrackingImplemented equal to true. When dot11LocationTrackingImplemented is true, dot11WirelessManagementImplemented shall be true. A STA in which dot11LocationTrackingActivated is true is defined as a STA that supports location track notification. When location track notification is supported, a STA configured by another STA as described in the previous subclause shall transmit Location Track Notification frames as shown in the informative diagram in Figure 11-32. Normal Transmit Interval Channel 1 Normal Number of Frames per Burst Channel Interframe or â€œburstâ€ Interval Channel 6 Channel 11 Figure 11-32â€”STA transmission on three channels, three frames per channel with Normal Report Interval Implementation of Motion Detection or the Time of Departure reporting is optional for a WNM STA. A STA that implements motion detection shall set dot11MotionDetectionImplemented to true. When dot11MotionDetectionImplemented is true, dot11WirelessManagementImplemented shall be true. A STA whose dot11MotionDetectionActivated is true shall support motion detection. A STA that implements the time of departure capability shall set its dot11TODImplmented to true. When dot11TODImplemented is true, dot11WirelessManagementImplemented shall be true. A STA whose dot11TODActivated is true shall support time of departure for location tracking. The STA transmits Location Track Notification frames based on the following parameters and procedures described in 11.24.4.1: a) Location Indication Channels. This subelement indicates the channels on which the STA shall transmit Location Track Notification frames. b) Indication Multicast Address 1) A non-IBSS STA shall transmit the Location Track Notification frames to the Indication Multi- cast Address field in the Location Indication Parameters subelement configured by the Loca- tion Configuration Request frame. 2) An AP shall discard any Location Track Notification frame received from a STA that does not match the Indication Multicast Address field value for the APâ€™s ESS. 1785 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 3) An IBSS STA shall transmit the Location Track Notification frames to the destination address of the STA that configured the STA using Location Configuration Request frames. c) Location Indication Interval 1) When the STA is stationary or dot11MotionDetectionActivated is false, the STA shall transmit a sequence of groups of Location Track Notification frames on each channel. Each group of frames shall contain Normal Number of Frames Per Channel field frames. The first frame in each group of Location Track Notification frames shall be separated from the first frame in the previous group of Location Track Notification frames by a minimum time duration indicated by the value of the Normal Report Interval field times the value of the Normal Report Interval Units field. 2) When the STA is in motion and dot11MotionDetectionActivated is true, the STA shall transmit a sequence of groups of Location Track Notification frames on each channel. Each group of frames shall contain In-Motion Number of Frames Per Channel field frames. The first frame in each group of Location Track Notification frames shall be separated from the first frame in the previous group of Location Track Notification frames by a minimum time duration indicated by the value of the In-Motion Report Interval times the value of the In-Motion Report Interval Units field. 3) If a STA is configured to transmit on multiple channels, the STA shall transmit the frames on a single channel before continuing onto the next channel in the configured list of channels. 4) All Location Track Notification frames transmitted on a single channel shall be transmitted with a minimum gap specified by the Burst Interframe Interval field. 5) A STA can never be stationary and in-motion at the same time, and therefore only the Normal Interval field or the In-Motion Interval field apply at any given moment. d) Tracking Duration 1) The STA shall transmit Location Track Notification frames until the Tracking Duration duration is reached. 2) The duration starts as soon as the STA sends a Configuration Location Response frame with a Location Status value of Success. 3) If the Tracking Duration is a nonzero value the STA shall transmit Location Track Notification frames, based on the Normal and In-Motion Report Interval field values, until the duration ends or is configured to terminate transmission as described in 11.24.4.1. 4) If the Tracking Duration is 0 the STA shall continuously transmit Location Track Notification frames as defined by Normal and In-Motion Report Interval field values until configured to terminate transmission as described 11.24.4.1. e) ESS Detection 1) The ESS Detection Interval field is specified in the Location Indication Parameters subelement configured by the Location Configuration Request frame. The ESS Detection Interval defines how often the STA should check for beacons transmitted by one or more APs belonging to the same ESS that configured the STA. 2) If no beacons from the ESS are received during this interval, the STA shall terminate transmission of Location Track Notification frames. f) Location Indication Options 1) The RM Enabled Capabilities element contained in (Re)Association Request frames indicates the STAâ€™s ability to perform radio measurements as described in 9.4.2.45. The Location Indication Options subelement Options Used field Beacon Measurement Mode Used bit shall be set to 0 by the AP when the RM Enabled Capabilities element bits (defined in Table 9-157), Beacon Passive Measurement Capability Enabled, Beacon Active Measurement Capability Enabled and Beacon Table Measurement Capability Enabled are all set to 0. If any of RM Enabled Capabilities element bits Beacon Passive Measurement capability enabled, Beacon Active Measurement Capability Enabled or Beacon Table Measurement Capability Enabled are 1786 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications equal to 1 then the Location Indication Options subelement Options Used field Beacon Measurement Mode Used bit may be set to 1. 2) If the Location Indication Options subelement is included and the Options Used field with the Beacon Measurement Mode Used bit equal to 1 in the most recently received Location Configuration Request frame, the STA shall include in the Location Track Notification frames, the result of the most recent successful beacon measurement that was performed using the requested Beacon Measurement Mode contained in the Location Indications Options subelement. 3) If the STA has never performed a successful beacon measurement using the requested Beacon Measurement Mode prior to transmission of the Location Track Notification frame, the STA shall perform the beacon measurement using the requested Beacon Measurement Mode and include the results of that measurement in Location Track Notification frames. 4) After a successful Location Configuration Request frame that included the Location Indication Options subelement and Options Used field with Beacon Measurement Mode Used bit equal to 1, a STA should continue to perform beacon measurement as defined by the Beacon Measure- ment Mode periodically. How often and under what circumstances the STA performs this mea- surement is out of scope of this standard. 5) Whenever a STA includes the beacon measurement in the Location Track Notification frames, the STA shall set the Measurement Token field in the Measurement Report element to the same value as the Dialog Token field in the Location Configuration Request frame that initiated the transmission of the location track notification frames by the STA. 6) If the Location Indication Options subelement is not included in the most recently received Location Configuration Request frame or the Location Indication Options subelement is included with the Options Used field with Beacon Measurement Mode Used bit equal to 0, the STA shall not include any beacon measurements in the Location Track Notification frame g) Location Indication Broadcast Data Rate. The STA shall transmit Location Track Notification frames at the data rate specified in this subelement. h) Time of Departure 1) If dot11TODActivated is true, the STA shall transmit this subelement in the Location Track Notification frame. 2) In all location tracking frames transmitted by a STA following a successful configuration, the Time of Departure subelement TOD Clock Rate field shall be set to the same value. 3) If the STA has multiple antennas, it shall transmit using an approximation to an omnidirectional pattern. NOTEâ€”The values of the fields in the Time of Departure subelement are measured by the PHY in real time, then passed without real-time requirements to the MAC via the TXSTATUS parameter of the PHY-TXSTART.confirm primitive. The diagram in Figure 11-32 shows an example of Location Track Notification frame transmission, for a STA configured to transmit on three channels, with three frames per channel. In this example, a Normal Transmit Interval and Normal number of frames per channel are shown. When a STA is capable of motion detection and is in motion, the In-Motion Report Interval and In-Motion number of frames per channel would apply. 11.24.5 Timing measurement procedure Implementation of timing measurement is optional for a WNM STA. A STA in which dot11TimingMsmtActivated is true is defined as a STA that supports timing measurement. A STA in which dot11TimingMsmtActivated is true shall set the Timing Measurement field of the Extended Capabilities element to 1. 1787 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A STA in which dot11TimingMsmtActivated is false shall set the Timing Measurement field of the Extended Capabilities element to 0. A STA that supports the timing measurement procedure may transmit a Timing Measurement Request frame to a peer STA to request it to initiate or to stop an ongoing timing measurement procedure, depending on the value of the Trigger field in the request frame. See Figure 11-33. t1 = ToD(M) Action frame M contains: t2 = ToA (M) Dialog Token = n Follow On Dialog Token = 0 t3 = ToD(Ack) t4 = ToA(Ack) Action frame M Contains: t1 and t4 are known Dialog Token = m â‰ (0, n) Follow On Dialog Token = n ToD Timestamp = t1 SME at receiving STA estimates TOA Timestamp = t4 offset of the local clock relative to that at sending STA using: [(t2 â€“ t1) â€“ (t4 â€“ t3)]/2 . . Sending Receiving STA . STA Figure 11-33â€”Timing measurement procedure A STA that supports the timing measurement procedure may transmit Timing Measurement frames addressed to a peer STA that also supports the timing measurement procedure. One higher-layer protocol for synchronizing a local clock time between STAs using this feature is specified in IEEE Std 802.1AS. For non-DMG STAs, both the Timing Measurement frame and the corresponding Ack frame shall be transmitted using a single transmit chain. A sending STA transmits Timing Measurement frames in overlapping pairs. The first Timing Measurement frame of a pair contains a nonzero value in the Dialog Token field. The follow up Timing Measurement frame contains a Follow Up Dialog Token field set the value of the Dialog Token field in the first frame of the pair. With the first Timing Measurement frame, both STAs capture timestamps. The sending STA captures the time at which the Timing Measurement frame is transmitted (t1). The receiving STA captures the time at which the Timing Measurement frame arrives (t2) and the time at which the Ack frame response is transmitted (t3). The sending STA captures the time at which the Ack frame arrives (t4). See Figure 6-16 in 6.3.57. In the follow up Timing Measurement frame, the sending STA transfers the timestamp values it captured (t1 and t4) to the receiving STA. 1788 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NOTEâ€”A Timing Measurement frame can contain nonzero values in both the Dialog Token and Follow Up Dialog Token fields, meaning that the Action frame contains follow up information from a previous measurement, and new Timestamp values are captured to be sent in a future follow up Timing Measurement frame. The offset of the clock at the receiving STA with respect to the clock at the sending STA is calculated using Equation (11-4) (assuming a symmetric wireless channel). See Figure 6-16 in 6.3.57. Clock offset at receiving STA relative to sending STA = [(t2 â€“ t1) â€“ (t4 â€“ t3)]/2 (11-4) NOTEâ€”An example of state machines and other computations for synchronizing a local clock time between IEEE 802.11 STAs using the values of t1, t2, t3, and t4 provided by the Timing Measurement feature is found in Clause 12 of IEEE Std 802.1AS. The acknowledgment procedure for Timing Measurement frames is the same as that for other Management frames (see 10.3.2.9). If the Ack frame for a transmitted Timing Measurement frame is not received, the sending STA may retransmit the frame. The sending STA shall capture a new set of timestamps for the retransmitted frame and its Ack frame. On receiving a Timing Measurement frame with a Dialog Token for which timestamps have previously been captured, the receiving STA shall discard previously captured timestamps and capture a new set of timestamps. 11.24.6 Fine timing measurement (FTM) procedure 11.24.6.1 Overview The FTM procedure allows a STA to determine its distance from another STA. In order for a STA to obtain its location, the STA may perform this procedure with multiple STAs whose locations are known. An FTM session is an instance of a FTM procedure between an initiating STA and a responding STA along with the associated scheduling and operational parameters of that instance (see 9.4.2.168). An FTM session is composed of a negotiation, measurement exchange and termination. A STA might have multiple concurrent FTM sessions. Concurrent FTM sessions might occur with responding STAs that are members of different BSSs and possibly different ESSs, or possibly outside of a BSS, each session using its own scheduling, channel and operational parameters. A responding STA might be required to establish overlapping FTM sessions with a large number of initiating STAs (e.g., an AP providing measurements to STAs at a mall or a store). On the other hand, an initiating STA might have multiple ongoing FTM sessions on the same or different channels with different responding STAs, while being associated with an AP for the exchange of data or signaling. To support the constraints of both the initiating and responding STAs, during the negotiation phase the initiating STA initially requests a preferred periodic time window allocation. The responding STA subsequently responds by accepting or overriding the allocation request based on its resource availability and capability. Since some of the initiating STAâ€™s activities may be nondeterministic and might have higher precedence than the FTM session (e.g., data transfer interaction with an associated AP), a conflict might prevent the initiating STA from being available at the beginning of the burst instance determined by the responding STA. Figure 11-34 shows an example of such scheduling conflicts. 1789 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Responding STA 1 Responding STA 2 Initiating STA Channel A Channel B Legend: Scheduled burst instance Conflicting duration of burst instances FTM Frame exchange Figure 11-34â€”Concurrent FTM sessions The initiating STA in Figure 11-34 establishes sessions with responding STA 1 and responding STA 2 on different channels. The sessionsâ€™ burst instance periodicity might be different as well as the STAsâ€™ clock offsets and thus, over time, some temporal conflicts may occur. To overcome this, during each burst instance the initiating STA indicates its availability by transmitting a Fine Timing Measurement Request frame (see 11.24.6.4). During each burst instance, the responding STA transmits one or more Fine Timing Measurement frames as negotiated. 11.24.6.2 FTM capabilities Implementation of FTM is optional for a WNM STA. A STA in which dot11FineTimingMsmtRespActivated is true is defined as a STA that supports FTM as a responder. A STA in which dot11FineTimingMsmtInitActivated is true is defined as a STA that supports FTM as an initiator. When dot11FineTimingMsmtRespActivated is true, dot11WirelessManagementImplemented shall be true. When dot11FineTimingMsmtInitActivated is true, dot11WirelessManagementImplemented shall be true. A STA in which dot11FineTimingMsmtRespActivated is true shall set the Fine Timing Measurement Responder field of the Extended Capabilities element to 1. 1790 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A STA in which dot11FineTimingMsmtInitActivated is true shall set the Fine Timing Measurement Initiator field of the Extended Capabilities element to 1. A STA in which dot11FineTimingMsmtRespActivated is false shall set the Fine Timing Measurement Responder field of the Extended Capabilities element to 0. A STA in which dot11FineTimingMsmtInitActivated is false shall set the Fine Timing Measurement Initiator field of the Extended Capabilities element to 0. 11.24.6.3 Fine timing measurement procedure negotiation In order to initiate a FTM procedure, a STA that supports the FTM procedure as an initiator (referred to as an initiating STA) shall transmit a Fine Timing Measurement Request frame. This frame is called the initial Fine Timing Measurement Request frame. After transmission of this frame, the initiating STA shall be ready to receive a Fine Timing Measurement frame. A STA that supports the FTM procedure as a responder (referred to as a responding STA) shall not transmit Fine Timing Measurement frames addressed to a peer STA unless the responding STA has received an initial Fine Timing Measurement Request frame from the peer STA. The initial Fine Timing Measurement Request frame shall have: â€” the Trigger field set to 1, â€” a set of scheduling parameters in a Fine Timing Measurement Parameters element that describe the initiating STAâ€™s availability for measurement exchange. The first Fine Timing Measurement frame in the FTM session is called the initial Fine Timing Measurement frame. The responding STA should transmit an initial Fine Timing Measurement frame within 10 ms in response to the initial Fine Timing Measurement Request frame. This initial Fine Timing Measurement frame shall include the Fine Timing Measurement Parameters element. The value of the Status Indication field indicates the outcome of the request. NOTEâ€”In an initial Fine Timing Measurement frame, the responding STA might indicate that the request for an FTM session is successful, even if the initial Fine Timing Measurement frame includes at least one of â€” A Measurement Report element that indicates an unknown LCI or â€” A Measurement Report element that indicates an unknown civic location. In the case of requests for 160 MHz bandwidth, the initiating STA shall indicate in the Format And Bandwidth field whether it uses a single or two separate RF LOs. In the cases when the responding STA indicates use of 160 MHz bandwidth, the responding STA shall indicate in the Format And Bandwidth field whether it uses a single or two separate RF LOs. The initiating STA shall indicate, in the Format and Bandwidth field, a format and bandwidth that it supports. The responding STA shall indicate, in the Format and Bandwidth field, a format and bandwidth that it supports. The responding STA should indicate the same format and bandwidth in the Format and Bandwidth field as that requested by the initiating STA, if the responding STA supports this. The responding STA shall not indicate a bandwidth wider than requested. The responding STA shall not indicate a VHT format if DMG, HT-mixed or non-HT format was requested. The responding STA shall not indicate an HT format if DMG or non-HT format was requested. The responding STA shall not indicate a DMG format if VHT, HT-mixed or non-HT format was requested. If the request was successful â€” The initiating STA shall indicate, in the Format and Bandwidth field, a format and bandwidth it supports. The responding STA shall indicate, in the Format and Bandwidth field, a format and 1791 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications bandwidth that it supports. The responding STA should indicate the same format and bandwidth in the Format and Bandwidth field as that requested by the initiating STA, if the responding STA supports this. The responding STA shall not indicate a bandwidth wider than requested. The responding STA shall not indicate a VHT format if DMG, HT-mixed or non-HT format was requested. The responding STA shall not indicate a DMG format if VHT, HT-mixed or non-HT format was requested. â€” An initiating STA performing a FTM procedure with a responding STA that is an AP shall support non-ASAP operation. â€” A responding STA that is an AP shall support and select non-ASAP operation when so requested by an initiating STA. â€” An initiating STA performing a FTM procedure with a responding STA that is not an AP shall support ASAP operation. â€” A responding STA that is not an AP shall support and select ASAP operation when so requested by an initiating STA. â€” If the responding STA is ASAP capable, the responding STAâ€™s selection of ASAP should be the same as that requested by the initiating STA. â€” The responding STAâ€™s selection of the Min Delta FTM field value shall be greater than or equal to the value requested by the initiating STA. â€” The responding STAâ€™s selection of the Number of Bursts Exponent field value shall be 0 if the initiating STA requested it to be 0. â€” The responding STAâ€™s selection of the Burst Duration field value should be less than or equal to the one requested by the initiating STA if the requested FTMs per Burst field value is set to a value indicating no preference, subject the recommendations below and the responding STAâ€™s policy on the maximum and minimum Burst Duration field values. â€” If the Number of Bursts Exponent field is set to 0 and the ASAP field is set to 1, the Burst Duration field value should be set to indicate the value BD1, defined as follows: BD 1 = N FTMPB K+1 â€“1 T MDFTM + T FTM + aSIFSTime + T Ack where NFTMPB is the value of the FTMs per Burst field K is the maximum number of Fine Timing Measurement frame retransmissions the responding STA might attempt TMDFTM is the duration indicated by the Min Delta FTM field of the Fine Timing Measurement Parameters field of the initial Fine Timing Measurement frame (FTM_1) TFTM is the duration of the initial Fine Timing Measurement frame if the FTMs per Burst field of the Fine Timing Measurement Parameters field of FTM_1 is set to 1, and the duration of the non initial Fine Timing Measurement frame otherwise TAck is the duration of the Ack frame expected as a response â€” Otherwise, the Burst Duration field value should be set to indicate a value greater than or equal to the following value: BD 1 + T FTMR + aSIFSTime + T Ack + T ACCESS_FTM where TFTMR is the duration of a Fine Timing Measurement Request frame without a Measurement Request element and without a Fine Timing Measurement Parameters element 1792 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications TACCESS_FTM is the estimated medium access time for the first FTM frame in a burst â€” The responding STAâ€™s selection of the value of the FTMs per Burst field should be the same as the one requested by the initiating STA if the requested value of the Burst Duration field is set to a value indicating no preference (see Table 9-257), subject to the responding STAâ€™s policy on the maximum value of the FTMs per Burst field. â€” The responding STAâ€™s selection of Burst Period shall be greater than or equal the responding STAâ€™s selection of Burst Duration. NOTEâ€”Apart from the Status Indication, Value, ASAP, Number of Bursts Exponent, Min Delta FTM, and Burst Period fields, the other fields in the Fine Timing Measurement Parameters element in the initial Fine Timing Measurement frame have no constraints. When the responding STA cannot support the initiatorâ€™s Min Delta FTM or Number of Bursts Exponent constraints, the responding STA shall set the Status Indication field to Request incapable and the FTM session ends. When the responding STA is unable to fulfill the request by the initiating STA, the responding STA shall set the Status Indication field to Request failed and the FTM session ends. 11.24.6.4 Measurement exchange Fine Timing Measurement frames are sent during time windows called burst instances. The timing of the burst instances is defined by the following parameters: â€” Partial TSF Timer â€“ The partial TSF timer, as defined in 9.4.2.168, at the beginning of the first burst instance â€” Burst Duration â€“ The duration of each burst instance starting at the boundary of a burst period â€” Burst Period â€“ The interval from the beginning of one burst instance to the beginning of the following burst instance. The initiating STA shall transmit a Fine Timing Measurement Request frame without a Measurement Request element, without a Fine Timing Measurement Parameters element and with the Trigger field set to 1 as soon as it is available on channel during a burst instance. This indicates to the responding STA its availability for the remainder of the burst instance. In response, the responding STA shall transmit an Ack frame and should transmit FTMs per Burst Fine Timing Measurement frames before the end of the burst instance. In addition, the initiating STA shall be ready to receive a Fine Timing Measurement frame. The first Fine Timing Measurement frame and its retransmissions in the burst instance from the responding STA shall include an FTM Synchronization Information element in the FTM Synchronization Information field. The TSF Sync Info field in the FTM Synchronization Information element contained in the Fine Timing Measurement frame might be used by the initiating STA to synchronize its TSF with the responding STAâ€™s in order to determine the start of subsequent burst instances. Subsequent Fine Timing Measurement frames within the burst instance shall not include a Fine Timing Measurement Parameters element and shall not include an FTM Synchronization Information field (for additional constraints on the Fine Timing Measurement frame see 11.24.6.7). Consecutive Fine Timing Measurement frames to a given peer STA shall be spaced at least Min Delta FTM apart. Within a burst instance the initiating STA shall perform FTM on each Fine Timing Measurement frame addressed to it, except the last Fine Timing Measurement frame. The initiating STA may perform FTM on the last Fine Timing Measurement frame in a burst instance. NOTEâ€”If the initiating STA successfully transmits a non-initial Fine Timing Measurement Request frame late in a burst instance, fewer than FTMs per burst might be successfully transmitted by the responding STA in the burst instance. If a Fine Timing Measurement frame, except for the initial Fine Timing Measurement frame in the ASAP=0 case, is sent outside a burst instance, it might not be acknowledged. The first burst instance shall start at the value indicated by the value of the Partial TSF Timer field in the initial Fine Timing Measurement frame, regardless of the ASAP fieldâ€™s value. When ASAP is set to 1 by the responding STA, the Partial TSF Timer field value shall be set to a value less than 10 ms from the reception of the most recent initial Fine Timing Request frame. 1793 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The scheduling parameters of an FTM session are illustrated in Figure 11-35. Responding STA Initiating STA <= 10 ms (recommended) NOTE 1 â€“ TSF (Responding STA) [10:25] = Partial TSF Timer See NOTE 1 t1_2 t2_2 Burst t4_2 t3_2 Duration Burst >= Min Delta Period FTM t1_3 t2_3 t4_3 t3_3 t1_4 t2_4 Burst t4_4 t3_4 Duration t1_5 t2_5 t4_5 t3_5 Figure 11-35â€”Example negotiation and measurement exchange sequence, ASAP=0, and FTMs per Burst = 2 1794 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The initiating STA can request the responding STA to start the burst instances â€œas soon as possibleâ€ by setting the ASAP field to 1. The scheduling in this case is illustrated in Figure 11-36. Responding STA Initiating STA NOTE 1 â€“ TSF (Responding STA) [10:25] = Partial TSF Timer < 10 ms <= 10 ms (recommended) See NOTE 1 t1_1 t2_1 >=Min t3_1 Delta t4_1 FTM t1_2 t2_2 Burst t3_2 Duration Burst t4_2 Period t1_3 t2_3 Burst t4_3 t3_3 Duration t1_4 t2_4 t4_4 t3_4 Figure 11-36â€”Example negotiation and measurement exchange sequence, ASAP=1, and FTMs per Burst = 2 1795 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The initiating STA may also request a single burst of FTMs to be taken as soon as possible, in which case it sets the Number of Bursts Exponent field to 0 and the ASAP field to 1. This is illustrated in Figure 11-37. Responding STA Initiating STA <= 10 ms < 10 ms (recommended) See NOTE 1 t1_1 t2_1 >= Min t4_1 t3_1 NOTE 1 â€“ Delta FTM Burst TSF (Responding STA) [10:25] = Duration Partial TSF Timer t1_2 t2_2 t3_2 t4_2 NOTE 2 â€“ See NOTE 2 Initiating STA can compute an RTT and a clock offset t1_3 t2_3 t4_3 t3_3 Figure 11-37â€”Example negotiation and measurement exchange sequence for a single burst instance, ASAP=1, and FTMs per Burst = 3 For non-DMG STAs, both the Fine Timing Measurement frame and the corresponding Ack frame shall be transmitted using a single transmit chain. The responding STA shall not transmit Fine Timing Measurement frames using Clause 15 or Clause 16 formats, MCS 32 format, or HT-greenfield format. The responding STA should transmit Fine Timing Measurement frames with the format and bandwidth it indicated. For the Fine Timing Measurement frames transmitted during the FTM session: â€” The responding STA shall not use a bandwidth wider than that indicated by the STA in the initial Fine Timing Measurement frame. â€” The responding STA shall not use a VHT format if the STA indicated HT-mixed or non-HT format in the initial Fine Timing Measurement frame. â€” The responding STA shall not use an HT format if the STA indicated non-HT format in the initial Fine Timing Measurement frame. The ASAP Capable field shall be set to 1 in the initial Fine Timing Measurement frame if a responding STA is ASAP-capable; otherwise it shall be set to 0. A responding STA transmits Fine Timing Measurement frames in overlapping pairs of consecutive frames. For example, in Figure 11-36, FTM_1 and FTM_2, FTM_2 and FTM_3, and FTM_3 and FTM_4 are overlapping pairs of consecutive frames. The first Fine Timing Measurement frame of a pair of consecutive Fine Timing Measurement frames contains a nonzero value in the Dialog Token field. The follow up Fine Timing Measurement frame contains a Follow Up Dialog Token field set to the value of the Dialog Token field in the first frame of the consecutive pair. Dialog Token field values of consecutive Fine Timing 1796 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Measurement frames shall be consecutive, except when the value wraps around to 1 or in the last Fine Timing Measurement frame in an FTM session. With the first Fine Timing Measurement frame, both STAs capture timestamps. The responding STA captures the time at which the Fine Timing Measurement frame is transmitted (t1). The initiating STA captures the time at which the Fine Timing Measurement frame arrives (t2) and the time at which the Ack response is transmitted (t3). The responding STA captures the time at which the Ack frame arrives (t4). See Figure 6-17. In the follow up Fine Timing Measurement frame, in the same or the subsequent burst, the responding STA transfers the timestamp values it captured (t1 and t4) to the initiating STA. In this follow up Fine Timing Measurement frame, the timestamp values (t1 and t4) shall be the measurement according to the responding STAâ€™s clock (i.e., without applying any frequency offset correction to the time bases). NOTEâ€”A Fine Timing Measurement frame can contain nonzero values in both the Dialog Token and Follow Up Dialog Token fields, meaning that the Action frame contains follow up information from a previous measurement, and new Timestamp values are captured to be sent in a future follow up Fine Timing Measurement frame. When the ASAP field is set to 0 by a responding STA, the Follow Up Dialog Token, TOD, TOA, TOD Error, and TOA Error fields in the Fine Timing Measurement frame following the initial Fine Timing Measurement frame shall be reserved. When the ASAP field is set to 1 by a responding STA, the timestamps for the initial Fine Timing Measurement frame shall be captured and sent in the following Fine Timing Measurement frame. In the Fine Timing Measurement frame following the initial Fine Timing Measurement frame, the TOD and TOA fields shall be set to the timestamps associated with the initial Fine Timing Measurement frame. The round trip time (RTT) is defined by Equation (11-5). RTT = [(t4' â€“ t1') â€“ (t3 â€“ t2)] (11-5) where t1' and t4' are the time at which the Fine Timing Measurement frame was transmitted and the time at which the Ack was received, respectively, as determined by the initiating STA. At the initiating STA, the mechanism by which t1' and t4' are derived from the TOD and TOA fields is implementation dependent. The Fine Timing Measurement protocol can also be used to synchronize a local clock between STAs. One higher-layer protocol for synchronizing a local clock time between STAs is specified in IEEE Std 802.1AS. The SME at the initiating STA may estimate the offset of the local clock relative to that at the responding STA using clock offset as defined by Equation (11-6). clock offset = [(t2 - t1') - (t4' - t3)]/2 (11-6) NOTEâ€”The initiating STA might track this clock offset over time to derive an estimate of the difference between the initiating STAâ€™s time base and the responding STAâ€™s time base, and thereby improve the accuracy of its derivation of t1' and t4' from the TOD and TOA fields. If the Ack frame for a transmitted Fine Timing Measurement frame is not received, the responding STA shall not retry the frame. In order to send the frame again, the responding STA shall send a Fine Timing Measurement frame with the same Action frame body as the Fine Timing Measurement frame for which the Ack was not received, except for updating the Dialog Token if it was nonzero. The Sequence Number in the MAC header is also updated. This is called an FTM retransmission. A responding STA that transmits a Fine Timing Measurement frame with the ASAP field set to 0 shall set the Partial TSF Timer field to an offset value DTSF from the partial value of the responding STAâ€™s TSF timer at the time of the transmission of the Ack to the last Fine Timing Measurement Request frame from the initiating STA, subject to 1797 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DTSF >= K_1 x TMDFTM + TFTM_1 + aSIFSTime + TAck + TACCESS_FTM1 where K_1 is the maximum number of initial Fine Timing Measurement frame (FTM_1) retransmissions the responding STA might attempt. TMDFTM is the value of the Min Delta FTM field of the Fine Timing Measurement Parameters field of FTM_1. TFTM_1 is the duration of the FTM_1. TAck is the duration of the Ack frame expected as a response. TACCESS_FTM1 is the estimated medium access time for FTM_1. NOTEâ€”This value of the Partial TSF Timer field ought to result in the Fine Timing Measurement Request frame not being transmitted before a successful transmission of FTM_1. When neither an Ack to the initial Fine Timing Measurement frame nor a Fine Timing Measurement Request frame has been received by the responding STA, the responding STA shall not terminate the FTM session before the time indicated by the Partial TSF timer plus the Burst Duration. The responding STA shall set the Follow Up Dialog Token field to 0 in the initial Fine Timing Measurement frame and its FTM retransmissions. The responding STA shall set the Dialog Token field to 0 in the last Fine Timing Measurement frame and its FTM retransmissions. 11.24.6.5 Fine timing measurement parameter modification During an FTM session, an initiating STA may terminate the current session and request a new session with modified session parameters by transmitting a Fine Timing Measurement Request frame with Trigger field set to 1 and including a new Fine Timing Measurement Parameters element. The existing FTM session is terminated upon reception of such a Fine Timing Measurement Request frame. This Fine Timing Measurement Request frame is an initial Fine Timing Measurement Request frame for the new FTM session, which follows the behavior described in 11.24.6.3. 11.24.6.6 Fine timing measurement termination An FTM session terminates after the last burst instance, as indicated in the Number of Bursts Exponent, Burst Duration, FTMs per Burst and Burst Period fields in the initial Fine Timing Measurement frame. An FTM session may be terminated before then through one of the following: â€” At any time during the FTM session when the responding STA is permitted to transmit a Fine Timing Measurement frame (see 11.24.6.4), the responding STA sends a Fine Timing Measurement frame with the Dialog Token field set to 0. â€” At any time during the FTM session when the initiating STA is permitted to transmit a Fine Timing Measurement frame (see 11.24.6.4), the initiating STA sends a Fine Timing Measurement Request frame with the Trigger field set to 0. This frame shall not include: â€” a Measurement Request element â€” a Fine Timing Measurement Parameters element â€” At any time during the FTM session when the initiating STA is permitted to transmit a Fine Timing Measurement frame (see 11.24.6.4), the initiating STA terminates the current session and requests a new session with modified Fine Timing Measurement parameters (see 11.24.6.5). 1798 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” After the number of burst instances indicated in the Number of Bursts Exponent field in the initial Fine Timing Measurement frame has been reached. 11.24.6.7 LCI and Location Civic retrieval using FTM procedure Within the FTM procedure, a STA, to request the LCI of a responding STA that transmits an Extended Capabilities element with the Fine Timing Measurement Responder field set to 1, shall include a Measurement Request element with Measurement Type field equal to LCI within the Fine Timing Measurement Request frame. Within the FTM procedure, a STA, to request the Location Civic of a responding STA that transmits an Extended Capabilities element with the Fine Timing Measurement Responder field set to 1, shall include a Measurement Request element with Measurement Type field equal to Location Civic within the Fine Timing Measurement Request frame. A Measurement Request element with Measurement Type field equal to LCI shall not be included in a Fine Timing Measurement Request frame unless the Fine Timing Measurement Request frame also includes a Fine Timing Measurement Parameters element. A Measurement Request element with Measurement Type field equal to Location Civic shall not be included in a Fine Timing Measurement Request frame unless the Fine Timing Measurement Request frame also includes a Fine Timing Measurement Parameters element. When a responding STA that has both dot11FineTimingMsmtRespActivated and dot11RMLCIConfigured equal to true receives a Measurement Request element with Measurement Type field equal to LCI within an initial Fine Timing Measurement Request frame, the responding STA shall include a Measurement Report element with Measurement Type field equal to LCI in the initial Fine Timing Measurement frame. If the maximum horizontal or vertical location error of the responding STA relative to a reference STA is known and this relative error is smaller than the absolute error indicated in the LCI subelement, then the responding STA may include a Relative Location Error subfield in the Measurement Report field. The responding STA shall not include a Measurement Report element with Measurement Type field equal to LCI in the Fine Timing Measurement frame in the current FTM session unless the responding STAâ€™s LCI has changed since the last time it was reported to the initiating STA. When a responding STA that has at least one of dot11FineTimingMsmtRespActivated and dot11RMLCIConfigured equal to false receives a Measurement Request element with Measurement Type field equal to LCI within a Fine Timing Measurement Request frame, the responding STA shall include a Measurement Report element with the Incapable field set to 1 in the initial Fine Timing Measurement frame. When a responding STA that has both dot11FineTimingMsmtRespActivated and dot11RMCivicConfigured equal to true receives a Measurement Request element with Measurement Type field equal to Location Civic within an initial Fine Timing Measurement Request frame, the responding STA shall include a Measurement Report element with Measurement Type field equal to Location Civic in the initial Fine Timing Measurement frame. The responding STA shall not include a Measurement Report element with Measurement Type field equal to Location Civic in the Fine Timing Measurement frame in the current FTM session unless the responding STAâ€™s civic location has changed since the last time it was reported to the initiating STA. When a responding STA that has at least one of dot11FineTimingMsmtRespActivated and dot11RMCivicConfigured equal to false receives a Measurement Request element with Measurement Type equal to Location Civic within a Fine Timing Measurement Request frame, the responding STA shall include a Measurement Report element with the Incapable field set to 1 in the initial Fine Timing Measurement frame. Each Measurement Report element returned shall have the same Measurement Token value as in the Measurement Token field of the corresponding Measurement Request element. The Fine Timing 1799 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Measurement frame containing the Measurement Report element(s) should be returned without undue delay to the STA. A STA that receives an LCI report that contains a Usage Rules/Policy subelement shall process the LCI information in compliance with the retransmission and retention permissions in the Usage Rules/Policy subelement. 11.24.7 BSS transition management for network load balancing 11.24.7.1 BSS transition capability The BSS transition capability enables improved throughput, effective data rate and/or QoS for the aggregate of STAs in a network by shifting (via transition) individual STA traffic loads to more appropriate points of association within the ESS. In addition, the BSS transition capability provides accounting session control information to a non-AP STA, which might be used to provide an alert to the non-AP STAâ€™s user that the STAâ€™s session is almost over and the STA will be disassociated from the ESS. The BSS Transition Management Query, BSS Transition Management Request, BSS Transition Management Response frames provide a means and a protocol to exchange the information needed to enable an AP to inform associated STAs that the BSS will be terminated and to enable a network to manage BSS loads by influencing STA transition decisions. A STA may provide neighbor report information to its associated AP for BSSs that it considers to be transition targets. This information enables the AP to request that the STA transition to a BSS that the STA also prefers. Implementation of BSS transition management is optional for a WNM STA. A STA that implements BSS transition management has dot11BSSTransitionImplemented equal to true. When dot11BSSTransitionImplemented is true, dot11WirelessManagementImplemented shall be true. A STA whose dot11BSSTransitionActivated is true shall support BSS transition management and shall set to 1 the Transition field of the Extended Capabilities elements that it transmits. The provisions in this clause for BSS transition management and network load balancing do not apply in an IBSS. 11.24.7.2 BSS transition management query A non-AP STA supporting BSS transition management may request a BSS Transition Candidate list by sending a BSS Transition Management Query frame to its associated AP if the associated AP indicates that it supports the BSS Transition capability in the Extended Capabilities element. A non-AP STA should include the BSS Transition Candidate List Entries field in the BSS Transition Management Query frame to indicate the non-AP STAâ€™s transition preferences. If the non-AP STA transmits a BSS Transition Query frame only to provide transition preferences to the AP, then the BSS Transition Query Reason field of the BSS Transition Management Query frame shall be set to a value of 19, indicating â€œPreferred BSS Transition Candidate List Included.â€ The BSS Transition Candidate List Entries field of a BSS Transition Management Query frame contains zero or more Neighbor Report elements describing the non-AP STAâ€™s preferences for target BSS candidates. The Preference field value of a Neighbor Report element used in a BSS Transition Management Query frame shall be between 1 and 255. The value of 0 is reserved. The values between 1 and 255 provide the indication of order, with 255 indicating the most preferred BSS within the given candidate list, decreasing numbers representing decreasing preference relative only to entries with lower values of the Preference field, and equal numbers representing equal preference. 1800 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.24.7.3 BSS transition management request An AP that supports BSS transition management shall respond to a BSS Transition Management Query frame with a BSS Transition Management Request frame. The AP may send an unsolicited BSS Transition Management Request frame to a non-AP STA at any time if the non-AP STA indicates in the Extended Capabilities element that it support BSS transition management; otherwise the AP shall not send an unsolicited BSS Transition Management Request frame to the STA. The AP may transmit a group addressed BSS Transition Management Request frame to associated non-AP STAs if all associated non-AP STAs support the BSS transition management; otherwise the AP shall not transmit a group addressed BSS Transition Management Request frame. When the BSS Transition Management Request frame is transmitted as a group addressed frame, a receiving non-AP STA shall not respond with a BSS Transition Management Response frame. A non-AP STA that supports BSS transition management shall respond to an individually addressed BSS Transition Management Request frame with a BSS Transition Management Response frame. The AP shall include the BSS Transition Candidate List Entries field in the BSS Transition Management Request frame if the AP has information in response to the BSS Transition Management Query frame. The BSS Transition Candidate List Entries field contains zero or more Neighbor Report elements describing the preferences for target BSS candidates. A Preference field value of 0 indicates that the BSS listed is an excluded BSS. The STA should refrain from associating to an AP corresponding to an excluded BSS. The Preference field values are used to establish the relative order of entries within the given list at the given time, and for the given AP. The values between 1 and 255 provide the indication of order, with 255 indicating the most preferred BSS within the given candidate list, decreasing numbers representing decreasing preference relative only to entries with lower values of the Preference field, and equal numbers representing equal preference. The Preference field value is valid only before the validity interval has expired. The AP may include zero or more subelements in the BSS Transition Candidate List Entries field. Upon reception of a BSS Transition Management Query frame or BSS Transition Response frame from a non-AP STA that contains a nonempty BSS Transition Candidate List Entries field, the AP should include at least one BSS candidate from that list with a nonzero Preference field value in the BSS Transition Candidate List Entries field of any subsequent BSS Transition Management Request frame with the Preferred Candidate List Included field set to 1 transmitted to the non-AP STA. The AP shall evaluate the BSSs indicated in the BSS Transition Candidate List Entries field in the latest BSS Transition Management Query frame or BSS Transition Management Response frame received from the non-AP STA as BSS transition candidate(s) for the non-AP STA. The means by which the AP evaluates and determines BSS transition candidates is outside the scope of this standard. A STA that receives a BSS Transition Management Request frame with the Preferred Candidate List Included subfield of the Request Mode field equal to 0 may ignore the BSS Transition Candidate List Entries field of the frame. A non-AP STA that receives the Abridged bit with a value of 1 shall treat any BSSID in the current ESS that does not appear in the BSS Transition Candidate List as if it were present in the BSS Transition Candidate List with a Preference value of 0. The AP may include one BSS Termination Duration subelement for each BSS in the BSS Transition Candidate List Entry field, including the BSS Termination Duration value and a BSS Termination TSF value. The BSS Termination Duration value may be different for each BSS. When the AP transmits a BSS Transition Management Request frame with the Disassociation Imminent field set to 1 to a non-AP STA, the Disassociation Timer field in the BSS Transition Management Request frame shall be set to 0 or set to the number of TBTTs that will occur prior to the AP disassociating the 1801 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications non-AP STA. The AP shall start a timer for the non-AP STA with the initial timer value set to the Disassociation Timer field value. The AP shall decrement the timer by one after transmitting each Beacon frame until the timer has value of 0. In subsequent BSS Transition Management Request frames that the AP transmits to the non-AP STA, the Disassociation Timer field shall be set to the value of the timer. If the most recent BSS Transition Management Request frame that an AP has transmitted to a non-AP STA has the Disassociation Imminent field set to 1, then the AP shall not transmit a Disassociation frame to the non-AP STA unless the timer for the non-AP STA has value of 0. An APâ€™s SME may have accounting session control information, such as a notice of session expiration. The means by which the APâ€™s SME obtains accounting session control information is out of scope of this standard. Accounting session control information might include a time duration after which the non-AP STA will be disassociated from the ESS and an optional session information URL at which information may be obtained to extend the accounting session. When an APâ€™s SME has accounting session control information, it shall issue an MLME-BTM.request primitive to the APâ€™s MLME and shall encode the time to session expiration in the Disassociation Timer parameter and shall encode the URL, if available, in the SessionInformationURL parameter. A non-AP STAâ€™s SME that has received an MLME-BTM.indication primitive forwards the MLME-BTM.indication parameters to the appropriate entity within the device (e.g., web browser) to inform the end user; the means and protocol by which the SME accomplishes this is outside the scope of this standard. A STAâ€™s SME receiving an MLME-BTM.indication primitive containing the BSS Transition Candidate List Entries field should use this list of candidates, with individual transition preference values, to make BSS transition decisions. Upon receiving an MLME-BTM.indication primitive, the STAâ€™s SME shall disregard any previous MLME-BTM.indication primitive received from the same AP. The STA shall not use the corresponding BSS Transition Candidate List Entries field information after the indicated validity interval. The STA may send a BSS Transition Management Query frame at any time to obtain an updated BSS Transition Candidate List Entries field or to indicate the STAâ€™s BSS transition candidates. A STAâ€™s SME receiving an MLME-BTM.indication primitive containing a nonzero value of the Disassociation Timer field should attempt to find a suitable AP with which to reassociate before the indicated disassociation time. 11.24.7.4 BSS transition management response When the STAâ€™s SME receives an MLME-BTM.indication primitive, it may issue an MLME- BTM.response primitive. The STAâ€™s SME may include the result of its BSS transition decision in the Target BSSID field and BTM Status Code field in the MLME-BTM.response primitive. A BTM Status Code field set to a value of 0 (i.e., Accept) indicates the STA will transition from the current BSS. The STAâ€™s SME receiving an MLME- BTM.indication primitive may issue an MLME-BTM.response primitive with a valid status code not equal to a value of 0 (i.e., Accept) indicating rejection if it is unable to comply with this BSS transition management request. When a non-AP STAâ€™s SME receives an MLME-BTM.indication primitive with the BSS Termination Included field in the Request Mode field equal to 1 it may issue an MLME-BTM.response primitive with the BTM Status Code field set to one of the following values: â€” 0 â€“ Accept. Accept the BSS Termination request. â€” 4 â€“ Reject, BSS Termination Undesired. Request for deferral of BSS Termination, interval not specified. â€” 5 â€“ Reject, BSS Termination Delay. Request for deferral of BSS Termination interval specified in the BSS Termination Delay field in the BSS Transition Management Response frame. 1802 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The APâ€™s SME may terminate or delay BSS Termination based on policies that are out of the scope of this standard. The MLME-RESET.request primitive is invoked to terminate the BSS. The AP shall disassociate all STAs immediately prior to termination of the BSS. When a non-AP STAâ€™s SME receives an MLME-BTM.indication primitive with both the Disassociation Imminent and Preferred Candidate List Included fields equal to 0, the non-AP STAâ€™s SME shall issue an MLME-BTM.response primitive with the BTM Status Code field set to one of the following values: â€” 0 â€“ Accept. â€” 2 â€“ Reject, Insufficient Beacon or Probe Response frames received from all candidates. â€” 3 â€“ Reject, Insufficient available capacity from all candidates. â€” 6 â€“ Reject, STA BSS Transition Candidate List provided. â€” 7 â€“ Reject, No suitable BSS transition candidates. â€” 8 â€“ Reject, Leaving ESS. When an APâ€™s SME receives an MLME-BTM.confirm primitive with the BTM Status Code field equal to a value of 2, indicating â€œReject, Insufficient Beacon or Probe Response frames received from all candidates,â€ the APâ€™s SME should generate an MLME-BTM.request primitive with both the Disassociation Imminent and Preferred Candidate List Included fields set to 0 after providing sufficient time for the non-AP STA to perform its scanning procedures. If the BTM Status Code field is a value of 6, indicating â€œReject, STA BSS Transition Candidate List provided,â€ the non-AP STA shall include a nonempty BSS Transition Candidate List Entries field in the BSS Transition Management Response frame to indicate the non-AP STAâ€™s transition preferences. The BTM Status Code field is a value of 8, indicating â€œReject, Leaving ESSâ€ if the non-AP STA intends to disassociate from the ESS. The BSS Transition Candidate List Entries field of a BSS Transition Management Response frame contains zero or more Neighbor Report elements describing the non-AP STAâ€™s preferences for target BSS candidates. The Preference field value of a Neighbor Report element used in a BSS Transition Management Response frame shall be between 1 and 255. The value of 0 is reserved. The values between 1 and 255 provide the indication of order, with 255 indicating the most preferred BSS within the given candidate list, decreasing numbers representing decreasing preference relative only to entries with lower values of the Preference field, and equal numbers representing equal preference. The non-AP STA should not list any BSS that is not considered as a target BSS candidate. When a non-AP STA receives a BSS Transition Management Request frame that has both the Disassociation Imminent and Preferred Candidate List Included fields equal to 1 and a nonempty BSS Transition Candidate List Entries field, if the non-AP STA transmits a BSS Transition Management Response frame to the AP with the BTM Status Code field set to 0 (Accept), then the non-AP STA shall either disassociate from the AP or attempt to (re)associate with an AP corresponding to one of the nonexcluded BSSs in the BSS Transition Candidate List Entries field of the received BSS Transition Management Request frame. Prior to transitioning to an excluded BSS listed in the BSS Transition Candidate List Entries field of a received BSS Transition Management Request frame, the non-AP STA shall transmit a BSS Transition Management Response frame to the AP indicating the reject reason. 11.24.8 FMS multicast rate processing An AP that supports FMS indicates its ability to deliver group addressed frames at alternate delivery intervals by its advertisement of the FMS capability. A STA that supports FMS includes the FMS Request element in FMS Request frames to indicate a request to use the FMS service, including use of a higher 1803 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications multicast rate. The AP selects the TXVECTOR parameters to use with the STA and indicates the rate that these parameters produce and the multicast address in the FMS Response element in the FMS Response frame. The AP selects TXVECTOR parameters that will be used for transmission to the currently associated STAs requesting FMS service from the AP for the same FMS stream identified by FMSID (the â€œexisting STAsâ€), and to the requesting STA subject to the following constraints: â€” The rate shall not be higher than the lowest rate value provided by the existing STAs and the requesting STA â€” The selection of the following TXVECTOR parameters shall be compatible with capabilities declared by the existing STAs and the requesting STA: â€” FORMAT â€” NON_HT_MODULATION â€” PREAMBLE_TYPE â€” MCS â€” CH_BANDWIDTH â€” STBC â€” FEC_CODING â€” GI_TYPE The STAâ€™s SME may request membership in a multicast group or changes in multicast data rate by issuing an MLME-FMS.request primitive. Upon receipt of an FMS Request frame at the APâ€™s SME as indicated by reception of the MLME-FMS.indication primitive the APâ€™s SME shall issue an MLME-FMS.response primitive, indicating the FMS Request element, including the multicast address. The AP may send an FMS Response frame to the STA to change the STAâ€™s multicast rate. When the AP sends an FMS Response frame to the STA with an Element Status field, indicating â€œMulticast rate changes not allowed,â€ the STA shall not send further FMS Request frames to request a change in the multicast rate while the STA is associated to the AP. 11.24.9 Collocated interference reporting Collocated interference may cause degradation of IEEE 802.11 STA performance either periodically or continuously. Collocated interference reporting allows a requesting STA to receive information concerning the collocated interference being experienced by another STA that is operating on the same channel as the requesting STA. Such interference might be due to an interaction between radios where a reporting STA is collocated with another radio device. Collocated interference information might be used by the requesting STA to manage communication to the reporting STA such that the effect of the interference might be limited. Implementation of Collocated interference reporting is optional for a WNM STA. A STA that implements Collocated Interference reporting has dot11CoLocIntfReportingImplemented equal to true. When dot11CoLocIntfReportingImplemented is true, dot11WirelessManagementImplemented shall be true. A STA whose dot11CoLocIntfReportingActivated is true shall support collocated interference reporting and shall set to 1 the Collocated Interference Reporting field of the Extended Capabilities elements that it transmits. A requesting STA may request that collocated interference reporting is enabled at another STA that has indicated support for the interference reporting capability. To enable collocated interference reporting, the STA shall send a Collocated Interference Request frame with Automatic Response Enabled bit set to the value representing the requested reporting type; see 9.6.14.13. A STA accepting a request for collocated interference reporting shall send the first report when it has knowledge of collocated interference. 1804 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Subsequently, a STA accepting a request with the Automatic Response Enabled subfield equal to 1 shall send a collocated interference report when the temporal characteristics of the interference or the level of the interference caused by collocated interferer significantly change to provide updated information, subject to meeting the Report Timeout requirement. A STA accepting a request with the Automatic Response Enabled subfield equal to 2 or 3 shall send the collocated interference reports periodically using the period included in the Report Period field in the Collocated Interference Reporting element in the report frames. In addition to sending reports periodically, a STA accepting a request with the Automatic Response Enabled field equal to 3 shall send a collocated interference report when the temporal characteristics of the interference or the level of the interference caused by collocated interferer significantly change, subject to meeting the Report Timeout requirement. The criteria a reporting STA uses for determining significant changes are internal to the reporting STA and outside the scope of this standard. When the reporting STA sends a collocated interference report, it shall restart the Report Period timer for periodic reporting. For either periodic reporting or reporting due to the changes in collocated interference, the reporting STA shall not generate collocated interference reports more frequently than indicated by the Report Timeout field in Interference Request field in the Collocated Interference Request frame. The requesting STA may disable reporting by sending a Collocated Interference Request frame with the Automatic Response Enabled subfield set to 0. The collocated interference reporting shall be terminated on receipt of a Collocated Interference Request frame with the Automatic Response Enabled subfield equal to 0. All outstanding collocated interference requests are canceled upon a BSS transition and/or channel switch. A new collocated interference request included in the new collocated Interference Request frame supersedes any previously received requests sent by the same STA. A STA that supports collocated interference reporting may send a Collocated Interference Request frame to another STA that supports collocated interference reporting immediately after they are associated, so that the reporting STA can send a collocated interference report as soon as it has knowledge of collocated interference. The Dialog Token field is the nonzero value received in the corresponding Collocated Interference Request frame which was used to enable reporting. The reporting STA shall use the Interference Index field in the Collocated Interference Report frame to indicate different types of interference. The reporting STA shall select a unique interference index value for each collocated interference source. For example if the reporting STA has knowledge of collocated interference originating from two interference sources the reporting STA shall report both type of interference using separate Collocated Interference Report elements having separate Interference Index field. Both Collocated Interference Report elements can be sent in the same Collocated Interference Report frame and both can have the same report period. A report with the Interference Index field in the Collocated Interference Report element equal to 0 indicates that no collocated interference is present. The characteristics of the interference are known a priori without requiring interference detection, measurement, and characterization by the IEEE 802.11 STA. The methods used by a reporting STA to know the periodicity, level of interference, accuracy of the reported interference level, interference center frequency and interference bandwidth are outside the scope of this standard. 11.24.10 QoS Traffic capability procedure Implementation of the QoS Traffic capability is optional for a WNM STA. A STA that implements QoS Traffic capability has dot11QoSTrafficCapabilityImplemented equal to true. When dot11QoSTrafficCapabilityImplemented is true, dot11WirelessManagementImplemented shall be true. A STA whose dot11QoSTrafficCapabilityActivated is true shall support QoS traffic capability and shall set to 1 the QoS Traffic Capability field of the Extended Capabilities elements that it transmits. 1805 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If dot11QoSTrafficCapabilityActivated is true, a QoS AP may use the QoS Traffic Capability field values received from a non-AP QoS STA as one of the factors when determining association, reassociation, and the BSS transition of the STA. A non-AP STA in which dot11QoSTrafficCapabilityActivated is true may send an Association Request, a Reassociation Request or QoS Traffic Capability Update frame to an AP whose last received Extended Capabilities element contained a value of 1 for the QoS Traffic Capability bit in the Extended Capabilities field. If dot11QoSTrafficCapabilityActivated is true, a non-AP QoS shall construct the QoS Traffic Capability Flags as specified in 9.4.2.78 and 9.6.14.23. QoS Traffic Capability Flags are constructed at the SME of the non-AP QoS STA, from application requirements supplied to the SME. The QoS Traffic Capability Flags are constructed from two application requirements: whether generation of traffic is required for applications and whether a specific UP is required for the generated traffic. If such requirements are supplied to the SME, the SME shall set the flag corresponding to the specific UP to 1. NOTEâ€”The requirements might be known before the traffic is actually generated. For example, a phone application might configured to generate UP 6 traffic upon the initiation of a voice session. Unless application requirements for a specific UP are supplied to the SME, the SME shall set the flag corresponding to the UP to 0. If dot11QoSTrafficCapabilityActivated is true, a non-AP QoS STA shall include the QoS Traffic Capability element in an Association Request frame or in a Reassociation Request frame when it is sending such a frame to associate or reassociate with an AP. If there is any change in QoS Traffic Capability Flags while associated with an AP, the non-AP STA shall send a QoS Traffic Capability Update frame (see 9.6.14.23) including the updated QoS Traffic Capability Flags to the AP. 11.24.11 AC Station Count Implementation of AC Station Count is optional for a WNM STA. A STA that implements AC Station Count has dot11ACStationCountImplemented equal to true. When dot11ACStationCountImplemented is true, dot11WirelessManagementImplemented and dot11QoSTrafficCapabilityImplemented shall be true. When dot11ACStationCountActivated is true, the STA shall set the AC Station Count field to 1 in the Extended Capabilities element to indicate that the STA supports the AC station count capability. When dot11ACStationCountActivated is false, the STA shall set the AC Station Count field in the Extended Capabilities element to 0 to indicate that the STA does not support this capability. If dot11ACStationCountActivated is true, a QoS AP shall construct the QoS Traffic Capability Bitmask and AC STA Count list as specified in 9.4.2.78. The AP shall construct the STA Count List value based on the UP-to-AC mappings as defined in Table 10-1, the QoS Traffic Capability Bitmask/Flags of the non-AP STAs that are currently associated with it, and additional information. If dot11ACStationCountActivated is true, a QoS AP shall include the QoS Traffic Capability element in a Probe Response frame and in a Beacon frame. If dot11ACStationCountActivated is true, a non-AP QoS STA may use the STA Count field values as one of the factors when determining association, reassociation, and the BSS transition. If dot11ACStationCountActivated is false, a non-AP QoS STA shall not use the STA Count field values as one of the factors when determining association, reassociation, and the BSS transition. 11.24.12 TFS procedures 11.24.12.1 TFS capability Implementation of the TFS capability is optional for a WNM STA. A STA that implements TFS shall set dot11TFSImplemented to true. If dot11TFSImplemented value is true, then 1806 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11WirelessManagementImplemented shall be true. A STA whose dot11TFSActivated is true shall support TFS and shall set to 1 the TFS field in the Extended Capabilities elements that it transmits. A STA in which dot11TFSActivated is true may send a TFS Request, TFS Response, TFS Notify frame, or TFS Notify Response frame to a STA within the same infrastructure BSS whose last received Extended Capabilities element contained a value of 1 for the TFS bit in the Extended Capabilities field. The traffic filtering service is not supported in an IBSS. A traffic filtering agreement is established using a TFS Request frame transmitted from a non-AP STA to an AP STA and a TFS Response frame transmitted from the AP STA to the non-AP STA. At most one traffic filtering agreement can exist at any one time between a STA and its associated AP. A traffic filtering agreement comprises one or more traffic filter sets, with a logical OR operation on the match conditions of each traffic filter set. A traffic filter set contains one or more traffic filters, with a logical AND operation on the match conditions of each traffic filter, and also includes a traffic filter set action. The traffic filter set action defines the actions taken at the AP when a frame match occurs. A frame match occurs when a frame matches to the filtering parameters for a TFS traffic filter set. NOTEâ€”The frame match can occur when the matched frames are either individually addressed or group addressed. A TFS Request frame contains one or more TFS Request elements. Each traffic filter set is conveyed by one TFS Request element, within a TFS Request frame. One TFS Request element contains one or more TFS Request subelements. A TFS Request subelement might be a TFS subelement, in which case it contains the filtering parameters for one traffic filter. A TFS subelement contains one or more TCLAS elements and an optional TCLAS Processing element that defines the relationship among multiple TCLAS elements within the TFS subelement. The TCLAS Processing element shall be present if more than one TCLAS element is included in the TFS subelement. A TFS Response frame contains the status of the traffic filters requested in the corresponding TFS Request frame. An AP may propose alternative filtering parameters by returning a TFS subelement in the corresponding TFS Response subelement. (See 11.24.12.2 and 11.24.12.3). When an AP proposes alternative filtering parameters it shall ensure that the TFS subelements related to the traffic filter set specified by a single TFS Request element all fit within a single TFS Response element. When an AP transmits a TFS Response frame to a STA in which the Status for all traffic filter requests is â€œAcceptâ€, it shall enable TFS for the STA. The previously established filter parameters, if any, remain in effect when the AP transmits a TFS Response frame with any other Status. When a traffic filter for group addressed frames is enabled at the AP, the group addressed frames are still delivered, without regard to the frames matching the traffic filter, since other associated STAs may also receive these frames. Because a STA using TFS can be in power save mode for an extended period of time, group addressed frames that match the traffic filter might be delivered before the STA is aware that the traffic filter has been matched. It is likely (but not guaranteed) that the STA does not receive those group addressed frames matching the traffic filter at the scheduled group addressed delivery time. To detect when this might have happened, the STA can request a notification frame be sent when requesting the establishment of the traffic filter. If negotiated with the AP, a frame match is indicated to the non-AP STA via a notification frame. 1807 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.24.12.2 TFS non-AP STA operation To use the TFS, the non-AP STAâ€™s SME that supports TFS shall issue an MLME-TFS.request primitive to send a TFS Request frame. The MLME-TFS.request primitive shall include a valid TFSRequest parameter as defined in the TFS Request elements. The receipt of an MLME-TSF.confirm primitive with a valid TFSResponse parameter indicates to the STAâ€™s SME that the AP has processed the corresponding TFS request. The content of the TFSResponse parameter provides the status of each of the TFS Request elements processed by the AP. A TFSResponse parameter optionally contains modified filtering parameters for the corresponding TFS request. A TFS Response frame in which the Status for all traffic filter requests is â€œAcceptâ€ indicates to the non-AP STA that the filtering operation at the AP has started. Otherwise, the STA might use the information in the TFS Response frame to form a new TFS request. In order to request the AP to delete a traffic filter set (identified by a unique TFS ID) when a frame matches to the traffic filter set, a non-AP STA shall set the Delete After Match subfield of the TFS Action Code field of the TFS Request element in the TFS Request frame to 1. In order to request a TFS Notify frame to be sent by the AP upon a frame match, a non-AP STA shall set the Notify subfield of the TFS Action Code field of the TFS Request element in the TFS Request frame to 1. After receiving a TFS Notify frame, in order to request the AP to resume generation of the TFS Notify frame upon a future frame match, a non-AP STA shall transmit to the AP a TFS Notify Response frame containing one or more TFS IDs. The non-AP STA may indicate that it is no longer using a particular TFS Request element by transmitting a TFS Request frame without that TFS Request element. The AP shall send a TFS Response frame with the corresponding Status field value set to Accept, upon receipt of the TFS Request frame. The non-AP STA may choose to terminate use of the TFS service by sending a TFS Request frame with no TFS Request elements in the request thereby canceling all traffic filters at the AP. 11.24.12.3 TFS AP operation When an APâ€™s SME receives an MLME-TFS.indication primitive with a valid TFSRequest parameter, it shall issue an MLME-TFS.response primitive with a TFSResponse parameter indicating the status of the associated request. An AP establishes a traffic filtering agreement and starts the filtering operation defined by that traffic filtering agreement when it receives a MLME-TFS.response primitive in which the Status for all traffic filter requests is â€œAcceptâ€. When the AP establishes a traffic filtering agreement for a requesting STA, the AP shall add to the traffic filtering agreement a traffic filter set that matches individually addressed EAPOL-Key frames addressed to the requesting STA, with bits 0 and 1 of the TFS Action Code field set to 0, without any status indication for this traffic filter set in the TFS Response frame. When an APâ€™s SME receives an MLME-TFS.indication primitive with a valid TFSRequest parameter having a requested TCLAS-based classifier which it is unable to provide, the SME shall issue an MLME- TFS.response primitive indicating the status of the corresponding request and may include a TFSResponse parameter having a suggested alternative TCLAS-based classifier. 1808 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications When a traffic filtering agreement is established for a STA, the AP shall discard all individually addressed frames destined for the STA until a frame is found that matches one or more traffic filter sets within the traffic filtering agreement. When a frame is found that matches one or more of the traffic filter sets within the traffic filtering agreement (a matching frame), the AP shall perform the following actions: â€” If the traffic filter set action specifies both Delete After Match and Notify, then the AP shall generate a single individually addressed TFS Notify frame for the frames matching to the traffic filter set identified by the corresponding TFS ID. Subsequently, the AP shall delete the traffic filtering agreement. â€” If the traffic filter set action specifies Notify but not Delete After Match, then the AP shall generate a single individually address TFS Notify frame for all frames matching to the traffic filter set identified by the corresponding TFS ID. All traffic filter sets established at the AP for the non-AP STA remain to be effective upon a match. If the AP receives a TFS Notify Response frame from the corresponding non-AP STA, the AP resumes generation of a single individually addressed TFS Notify frame for the next frame matching to the traffic filter sets identified by the TFS IDs included in the TFS Notify Response frame. Otherwise, the AP shall not send additional TFS Notify frames upon frame matches. NOTEâ€”Due to the operation of group addressed frame delivery, a group addressed frame that matches a traffic filter might result in the STA receiving indication of the group addressed frame either before or after the group addressed frame is transmitted by the AP, if the TFS Notify frame is queued in the STAâ€™s power save queue. This might result in the STA receiving the group addressed frame in some cases and not receiving it in other cases. Upon receiving an MLME-TFS.indication primitive, the APâ€™s SME shall disregard any previous MLME- TFS.indication primitive received from the same STA. The AP shall terminate any TFS operation for a STA when no traffic filters remain for a STA or if the APâ€™s SME receives an MLME-TFS.indication primitive with a null TFSRequest. 11.24.13 BSS max idle period management If dot11BssMaxIdlePeriod is a nonzero, the STA shall include the BSS Max Idle Period element in the Association Response frame or the Reassociation Response frame. Otherwise, the STA shall not include the BSS Max Idle Period element in the Association Response frame or the Reassociation Response frame. A STA may send protected or unprotected keepalive frames, as indicated in the Idle Options field. The Max Idle Period field of the BSS Max Idle Period element indicates the time period during which a STA can refrain from transmitting frames to its associated AP without being disassociated. A non-AP STA is considered inactive if the AP has not received a Data frame, PS-Poll frame, or Management frame (protected or unprotected as specified in this paragraph) of a frame exchange sequence initiated by the STA for a time period greater than or equal to the time specified by the Max Idle Period field. If the Idle Options field requires protected keepalive frames, then the AP may disassociate the STA if no protected frames are received from the STA for a period indicated by the Max Idle Period field of the BSS Max Idle Period element. If the Idle Options field allows unprotected or protected keepalive frames, then the AP may disassociate the STA if no protected or unprotected frames are received from the STA for a duration indicated by the Max Idle Period field of the BSS Max Idle Period element. NOTEâ€”The AP can disassociate or deauthenticate the STA at any time for other reasons even if the STA satisfies the keep-alive frame transmission requirements. 11.24.14 Proxy ARP (including Proxy Neighbor Discovery) service Implementation of the proxy ARP service is optional for a WNM STA. A STA that implements the proxy ARP service has dot11ProxyARPImplemented equal to true. When dot11ProxyARPImplemented is true, dot11WirelessManagementImplemented shall be true. When dot11ProxyARPActivated is true, the Proxy ARP Service bit in the Extended Capabilities field shall be set to 1 to indicate that the AP supports the proxy 1809 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ARP service. When dot11ProxyARPActivated is false, the Proxy ARP Service bit shall be set to 0 to indicate that the AP does not support the proxy ARP service. When the AP sets the Proxy ARP field to 1 in the Extended Capabilities element, the AP shall maintain a Hardware Address to Internet Address mapping for each associated station, and shall update the mapping when the Internet Address of the associated station changes. When the IPv4 address being resolved in the ARP request packet (IETF RFC 826) is used by a non-AP STA currently associated to the BSS, the proxy ARP service shall respond on behalf of the STA to an ARP request (IETF RFC 925) or an ARP Probe (IETF RFC 5227). When an AP receives an ARP Request from one associated STA or from the DS with a Target IP Address that corresponds to a second associated STA, the AP shall insert the second STA MAC address as the Senderâ€™s MAC Address in the ARP Response packet. When an IPv6 address is being resolved, the Proxy Neighbor Discovery service shall respond with a Neighbor Advertisement message (Section 4.4, IETF RFC 4861) on behalf of an associated STA to an Internet Control Message Protocol version 6 (ICMPv6) Neighbor Solicitation message (Section 4.3, IETF RFC 4861). When MAC address mappings change, the AP may send unsolicited Neighbor Advertisement Messages on behalf of a STA. NOTEâ€”The Neighbor Solicitation message is used for both address discovery and duplicate address detection (IETF RFC 4862). 11.24.15 Channel usage procedures Channel Usage information is a set of channels provided by an AP to non-AP STAs for operation of a noninfrastructure network or an off-channel TDLS direct link. The Channel Usage information provided by the AP to the non-AP STA is to advise the STA on how to co-exist with the infrastructure network. Implementation of Channel Usage is optional for a WNM STA. A STA that implements Channel Usage has dot11ChannelUsageImplemented equal to true. When dot11ChannelUsageImplemented is true, dot11WirelessManagementImplemented shall be true, or the STA shall be capable of acting as an S-AP within a CCSS. A STA whose dot11ChannelUsageActivated is true shall support channel usage and shall set to 1 the Channel Usage field of the Extended Capabilities elements that it transmits. A non-AP STA that supports Channel Usage and is not associated to an AP prior to using a noninfrastructure network or an off channel TDLS direct link may transmit a Probe Request frame including both Supported Operating Classes and Channel Usage elements. A non-AP STA supporting Channel Usage may send a Channel Usage Request frame at any time after association to the AP that supports the use of Channel Usage to request the Channel Usage information for supported operating classes. Upon receipt of a Channel Usage element in the Probe Request frame, the AP supporting Channel Usage shall send a Probe Response frame including one or more Channel Usage elements. Upon receiving a Channel Usage Request frame, the AP supporting Channel Usage shall send a Channel Usage Response frame including one or more Channel Usage elements. Channel Usage elements shall include channels that are valid for the regulatory domain in which the AP transmitting the element is operating and consistent with the Country element in the Beacon or Probe Response frame; the Channel Usage elements shall not include any other channels. When the Channel Usage element in a received Probe Request or Channel Usage Request frame includes one or more Operating Class/Channel Pair fields, the Operating Class/Channel Pair field(s) indicate(s) the requested non-AP STA operating class/channels for the usage mode indicated in the frame. The AP may send an unsolicited group addressed or individually addressed Channel Usage Response frame to the STAs that have requested Channel Usage information if the corresponding Channel Usage information needs to be updated. The Country element shall be included in the unsolicited and/or group 1810 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications addressed Channel Usage Response frame. The AP may include the Power Constraint information and EDCA Parameter in the Channel Usage Response frame. The values of the fields in the Power Constraint and EDCA Parameter Set elements included in the Channel Usage Response frame shall be the same values of the fields in the Power Constraint and EDCA Parameter Set elements that are transmitted by the AP. Upon receipt of a Channel Usage element in the Probe Response or Channel Usage Response frame, the receiving STA may use the following: â€” The channel usage information as part of channel selection processing to start a noninfrastructure network or an off-channel TDLS direct link â€” The Power Constraint element, if present, as part of determining its maximum transmit power for transmissions for the noninfrastructure network or an off-channel TDLS direct link â€” The EDCA Parameter Set element, if present, as part of determining its EDCA parameters for transmissions for the noninfrastructure network or an off-channel TDLS direct link â€” The QMF Policy element, if present and dot11QMFActivated is true, as part of determining its classification of Management frames for transmissions for the noninfrastructure network or an off-channel TDLS direct link If either a recommended operating class, or a recommended channel, or both are not supported or understood by the recipient, or if the operating country of the sender is unknown, the recipient shall discard the corresponding channel usage recommendation. A STA that has not requested Channel Usage information shall discard an unsolicited group addressed Channel Usage Response frame. 11.24.16 Group addressed transmission service 11.24.16.1 General The group addressed transmission service provides delivery of group addressed frames and comprises the two services, DMS and GCR. DMG STAs do not use GCR. 11.24.16.2 DMS procedures In this subclause, the following terms are used: â€” DMS provider: An AP, PCP, or DMG STA associated with a PCP that provides DMS. â€” DMS recipient: A non-AP STA that uses DMS. Directed multicast service (DMS) is a service that may be provided by a DMS provider to its associated DMS recipients that support DMS, where the DMS provider transmits group addressed MSDUs as individually addressed A-MSDUs. In a PBSS, DMS is a service that may be provided by any STA to other STAs associated in the same PBSS that support DMS, where the STA transmits group addressed MSDUs as individually addressed A-MSDUs. If the PCP of the PBSS has the PCP Forwarding field within the PCPâ€™s DMG Capabilities element set to 0, a non-PCP STA in the PBSS shall not use the PCP as a DMS provider in the PBSS. Implementation of DMS is optional for a WNM STA and mandatory for a robust AV streaming STA (as defined in 11.27.1). A STA that implements DMS has dot11DMSImplemented equal to true. When dot11DMSImplemented is true, at least one of dot11WirelessManagementImplemented and dot11RobustAVStreamingImplemented shall be true When dot11DMSImplemented is true, either dot11HighThroughputOptionImplemented or dot11DMGOptionImplemented shall be true. A STA whose dot11DMSActivated is true shall support DMS and shall set to 1 the DMS field of the Extended Capabilities elements that it transmits. 1811 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A DMS recipient that supports DMS may request use of DMS of one or more flows by sending a DMS Request frame or Reassociation Request frame that includes a DMS Request element containing one or more DMS Descriptors with the Request Type field set to â€œAddâ€ per flow. Each DMS Descriptor field in the DMS Request element identifies group addressed frames that shall be transmitted to the requesting DMS recipient as individually addressed frames in addition to the group address frame transmission. In the TCLAS element, the Classifier Type subfield shall be set to the value 0, 1, or 4, and the Destination Address or Destination IP Address subfield shall be set to the multicast address of the flow that the STA requests to receive as individually addressed frames. In the TSPEC element, the STA may define the characteristics and QoS expectations of the corresponding traffic flow. Upon receipt of a DMS Request frame or Reassociation Request frame from a DMS recipient, the DMS provider shall respond with a corresponding DMS Response frame or Reassociation Response frame. The response frame shall contain a matching (i.e., as the same DMSID) DMS Status field for each received DMS Descriptor field preserving the order present in the request frame. NOTEâ€”There is no requirement that the number of DMS Request elements and the number of DMS Response elements match. There is no requirement that the number of DMS Descriptor fields within any DMS Request element matches the number of DMS Status fields within any DMS Response element. If the DMS provider accepts a DMS request identified by a DMS Descriptor, the Response Type field of the corresponding DMS Status field in the DMS Response element shall be set to â€œAcceptâ€ and a nonzero DMSID is assigned. A Response Type value of â€œDenyâ€ shall be set in the corresponding Response Type field of the DMS Status field in the DMS Response element when the DMS provider denies a DMS request identified by a DMS Descriptor, and the DMSID shall be set to 0. If the Response Type field is set to â€œAcceptâ€ or â€œDenied,â€ then the TCLAS Elements, TCLAS Processing Element, TSPEC Element and Optional Subelements fields of a DMS Status field in a DMS Response element shall be copied from the respective TCLAS Elements, TCLAS Processing Element, TSPEC Element and Optional Subelements fields of the corresponding DMS request. When one or more STAs send a DMS request to an DMS provider, containing a DMS descriptor with a set of TCLAS element and TCLAS Processing elements that are identical irrespective of ordering to another successfully received DMS request that is not yet terminated, the DMS provider shall assign the same DMSID as was assigned to the previous DMS request. When the DMS provider denies the DMS Request, it may suggest an alternative TCLAS-based classifier by including one or more TCLAS elements and an optional TCLAS Processing element. The DMS provider may include fewer TCLAS elements in the DMS Response element than were present in the request; when the DMS providerâ€™s response includes a single TCLAS element, it shall not include a TCLAS Processing element. If the DMS provider changes a TCLAS elementâ€™s Classifier Type field in the DMS Response element but is unable to suggest a value for the Classifier Mask field, it shall set that field to 0. If the DMS provider changes a TCLAS elementâ€™s Classifier Type field or Classifier Mask field in the DMS Response element but is unable to suggest values for one or more Classifier Parameter subfields, it shall set those subfields to 0. A DMS recipient receiving a DMS Response frame containing a modified TCLAS element having a Classifier Mask field equal to 0 or having one or more Classifier Parameter subfields equal to 0 shall interpret the values of 0 to mean that no suggested value has been provided by the DMS provider. If the requested DMS is accepted by the DMS provider, the DMS provider shall send subsequent group addressed MSDUs that match the frame classifier specified in the DMS Descriptors to the requesting STA as A-MSDU subframes within an individually addressed A-MSDU frame (see 9.3.2.2 and 10.12). The A-MSDU shall be formatted as specified in 9.3.2.2 which includes the A-MSDU subframe headersâ€™ DA address set to the multicast address for the corresponding MSDUs. The DMS provider shall continue to transmit the matching frames as group addressed frames (see 10.3.6, and 11.2.3.16) if at least one associated STA has not requested DMS for these frames. 1812 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A DMS recipient may request modification of the traffic characteristics or attributes of one or more accepted DMS traffic flows by sending a DMS Request frame or Reassociation Request frame containing one or more DMS Descriptors with the Request Type set to â€œChangeâ€ and with the DMSIDs that identify the DMS traffic flows to be modified. If the Request Type of a DMS Descriptor is set to â€œChange,â€ then the values of at least one of the TSPEC Element and Optional Subelement fields shall be different from those of the accepted DMS traffic flow corresponding to the DMSID. If the DMS provider accepts a DMS change request identified by a DMS Descriptor, the Response Type field of the corresponding DMS Status field in the DMS Response element shall be set to â€œAcceptâ€ and the DMSID shall be set to that of the DMS Descriptor. If the DMS provider denies a DMS change request identified by a DMS Descriptor, the Response Type field of the corresponding DMS Status field in the DMS Response element shall be set to â€œDenyâ€ and the DMSID shall be set to that of the DMS Descriptor. When the DMS provider denies a DMS change request identified by a DMS Descriptor, the existing DMS traffic flow of the corresponding DMSID shall remain unchanged. The DMS recipient may request removal of one or more accepted DMS traffic flows by sending a DMS Request frame or Reassociation Request frame that includes a DMS Request element containing one or more DMS Descriptors with the Request Type set to â€œRemoveâ€ and the DMSID field set to that the DMSID of the accepted DMS traffic flow to be removed. The DMS Length field in this DMS Descriptor is set to 1. The TLCAS Elements, TCLAS Processing Element TSPEC Element and Optional Subelements fields shall not be included in the DMS Descriptor if the Request Type is set to â€œRemove.â€ The DMS provider shall terminate individually addressed frame delivery for the requested group addressed frames identified by the DMSID for the requesting DMS recipient upon receipt of a DMS Request frame or Reassociation Request frame with the Request Type field equal to â€œRemove.â€ The DMS provider shall respond to the termination request by sending a DMS Response frame including the corresponding DMSID and a Response Type value of â€œTerminateâ€ in the Response Type field of the corresponding DMS Status field. The DMS Length field in this DMS Status field is set to 3. The TLCAS Elements, TCLAS Processing Element, TSPEC Element and Optional Subelement fields shall not be included in the DMS Status field if the Response Type field is set to â€œTerminate.â€ The DMS provider may send an unsolicited DMS Response frame at any time to cancel a granted DMS identified by the DMSID by including the DMSID and a Response Type value of â€œTerminateâ€ in the DMS Status field. The DMS provider may reject a new DMS or cancel a granted DMS at any time based on network condition, for example the number of associated STAs and channel load. The DMS recipient shall keep a list of group addresses for which the DMS recipient has requested DMS and that have been accepted by the DMS provider. The requesting STA shall discard group addressed frames that match a group address in this list until the DMS has been terminated. When the DMS is terminated, and if the sequence number value is provided in the Last Sequence Control field in the DMS Response frame, using the value of the Last Sequence Control field, the DMS recipient shall discard the group addressed frames that are the duplicates of the individually addressed frames. NOTEâ€”When the Last Sequence Control field in the DMS Response frame is not supported at the DMS provider (i.e., the sequence number value is not provided in the field), and a multicast MSDU that has sent using both individually addressed and group addressed frame transmission, termination of the DMS stream by the DMS provider might result in a DMS recipient receiving undetectable duplicate MSDUs that are not filtered out by the MAC. If the length of the DMS Descriptors exceeds 255 octets, then multiple DMS Request elements shall be included, each containing only those DMS Descriptors that are completely contained within 255 octets. If the length of the DMS status fields exceeds 255 octets, then multiple DMS Response elements shall be included, each containing only those DMS Status fields that are completely contained within the first 255 octets. 1813 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If the DMS recipient supports both DMS and FMS, the DMS recipient shall not request both services for the same group addressed frames simultaneously. The DMS recipient may request the different service (DMS vs. FMS) for different group addressed frames. If the DMS provider supports both DMS and TFS, the DMS provider shall first apply TFS to the frame and then apply DMS. 11.24.16.3 GCR procedures 11.24.16.3.1 Overview Groupcast with retries (GCR) is a flexible service to improve the delivery of group addressed frames while optimizing for a range of criteria. GCR service may be provided by the AP to associated STAs in an infrastructure BSS or by a mesh STA to its peer mesh STAs in a mesh BSS. GCR uses the setup, modification, and termination procedures defined 11.24.16.2. The differences between GCR procedures and DMS procedures are as follows: a) A GCR agreement applies to a single group address and, if a TCLAS Processing element is present, it has the Processing subfield value set to 0, whereas a DMS flow is not restricted to a single group address. b) DMS offers multicast-to-unicast conversion only, whereas GCR includes several retransmission policies and delivery methods. A non-DMG STA with dot11RobustAVStreamingImplemented true shall implement the GCR procedures defined in 11.24.16.3.2 to 11.24.16.3.6. When dot11RobustAVStreamingImplemented is true, dot11DMSImplemented and dot11HighThroughputOptionImplemented shall be true. A STA that implements advanced GCR supports GCR block ack (11.24.16.3.7) and GCR-SP (11.24.16.3.8) and has dot11AdvancedGCRImplemented equal to true. When dot11AdvancedGCRImplemented is true, dot11RobustAVStreamingImplemented shall be true. In a mesh BSS, a STA that implements GCR has dot11MeshGCRImplemented equal to true. When dot11MeshGCRImplemented is true, dot11HighThroughputOptionImplemented shall be true. DMS allows the transmission of group addressed MSDUs as individually addressed A-MSDUs and is particularly suited to small numbers of group members. It provides a high level of reliability but has low scalability as the efficiency decreases and delay increases proportionally to the number of group members. GCR employs the DMS Request and DMS Response elements with the addition of GCR Request and Response subelements, respectively, for administering the announcement, setup, modification, and teardown of GCR services between an AP and non-AP STAs or between peer mesh STAs. The DMS procedures and state machine of 11.24.16.2 shall apply to GCR with the extensions and constraints specific to GCR described below in 11.24.16.3.3 to 11.24.16.3.8. Along with the No-Ack/No-Retry or non-GCR (defined in 10.3.6) and the DMS (defined in 11.24.16.2) retransmission mechanisms, GCR defines two additional retransmission policies for group addressed frames: â€” GCR unsolicited retry â€” GCR block ack When using the GCR unsolicited retry retransmission policy for a group address, the STA providing GCR service retransmits an MSDU one or more times (subject to applicable retry or lifetime limits) to increase the probability of correct reception at STAs that are listening to this group address. The decision to retransmit these MSDUs is implementation dependent. GCR unsolicited retry is particularly suited to use with large numbers of group members as it has moderate delay, efficiency, and reliability, but high scalability. 1814 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The GCR block ack retransmission policy extends the block acknowledgment mechanism to group addressed frames. The STA providing the GCR service initiates block ack agreements with each STA receiving GCR frames that supports GCR block ack for a particular group address. Once this block ack agreement is in place, the STA providing GCR service regularly sends BlockAckReq frames to the STAs receiving the frames to ascertain the reception status of MSDUs related to this group address, as described in 10.24.10. This allows the STA providing GCR service to discover MSDUs that have not been received and to schedule their retransmission. GCR block ack is particularly suited to use with moderate numbers of group members as it has moderate delay, high efficiency, and moderate scalability and reliability. The GCR service has two delivery methods for group addressed frames: â€” Non-GCR-SP â€” GCR-SP (see 11.24.16.3.8) The non-GCR-SP delivery method may be provided using one or more of the following: â€” FMS (see 11.2.3.16) â€” Transmit frames in a GCR stream after the DTIM Beacon frame if any STA in the GCR group is in PS mode â€” Transmit frames at any time if all STAs in the GCR group are in active mode in an infrastructure BSS â€” In accordance with 14.14 in a mesh BSS GCR-SP transmits GCR group addressed frames at intervals, where the interval between transmissions might be smaller than the beacon interval. Compared to non-GCR-SP, GCR-SP might provide lower delay and jitter. 11.24.16.3.2 GCR group membership procedures The procedures described in 11.24.16.3.3 to 11.24.16.3.8 depend upon the AP or mesh STA knowing the membership of the multicast groups of STAs that support GCR. One method for an AP to discover the multicast groups that its associated STAs are receiving or for a mesh STA to discover the multicast groups that its peer mesh STAs are receiving is to use the Group Membership Request frame (as defined in 9.6.19.4) to request the contents of the dot11GroupAddressesTable of its associated STAs or peer mesh STAs. Other methods of group membership detection are also possible, using information that is outside the scope of this standard. For example, group membership detection could be achieved by inspecting the protocol messages of IETF RFC 3376.46 An AP may transmit a Group Membership Request frame as an individually addressed frame to an associated STA that has indicated that it supports robust AV streaming (as indicated by the Robust AV Streaming bit equal to 1 in the Extended Capabilities element) to request the associated STAâ€™s dot11GroupAddressesTable. An AP shall not send a Group Membership Request frame to an associated STA that has the Robust AV Streaming bit equal to 0 in its Extended Capabilities element. A STA for which dot11GCRActivated or dot11MeshGCRActivated is true shall reply to a Group Membership Request frame by sending a Group Membership Response frame with the Dialog Token field set to the value from the Group Membership Request frame, the Address Count field set to the number of entries in the dot11GroupAddressesTable, and the Group Address List field set to the group MAC addresses in the dot11GroupAddressesTable. A STA for which dot11GCRActivated or dot11MeshGCRActivated is 46 IETF RFC 3376, Internet Group Management Protocol (IGMP). 1815 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications true shall set dot11GCRGroupMembershipAnnouncementActivated to true upon reception of a Group Membership Request frame. A STA for which dot11GCRGroupMembershipAnnouncementActivated and at least one of dot11MeshGCRActivated and dot11GCRActivated are true shall send an unsolicited Group Membership Response frame with the Dialog Token field set to 0, the Address Count field set to the number of entries in the dot11GroupAddressesTable, and the Group Address List field set to the group MAC addresses in the dot11GroupAddressesTable, every time the contents of the dot11GroupAddressesTable is modified. If an unsolicited Group Membership Response frame is sent by an associated STA, the frame shall be transmitted as an individually addressed frame to the AP with which it is associated. If an unsolicited Group Membership Response frame is sent by a mesh station in a mesh BSS, the frame shall be transmitted as a broadcast frame. 11.24.16.3.3 GCR setup procedures An AP with dot11GCRActivated true may transmit to an associated non-AP STA an unsolicited individually addressed DMS Response frame that contains one DMS Status field with a GCR Response subelement per group address, if it detects that the associated non-AP STA meets all of the following conditions: â€” Robust AV Streaming was equal to 1 in the Extended Capabilities element in the most recently received (Re)Association Request frame from the non-AP STA. â€” The non-AP STA is receiving one or more group addresses for which there is an active GCR service. â€” The non-AP STA does not have a GCR agreement for one or more of these group addresses. A mesh STA with dot11MeshGCRActivated true may transmit to a peer mesh STA an unsolicited individually addressed DMS Response frame that contains one DMS Status field with a GCR Response subelement per group address, if it detects that the peer mesh STA meets all of the following conditions: â€” Mesh GCR was equal to 1 in the Extended Capabilities element in the most recently received mesh beacon from the peer mesh STA. â€” The peer mesh STA is receiving one or more group addresses for which there is an active GCR service. â€” The peer mesh STA does not have a GCR agreement for one or more of these group addresses. Each DMS Status field includes a TCLAS element to identify the GCR group address, the DMSID corresponding to this GCR traffic flow, and other associated parameters. The Status subfield of this DMS Status field shall be set to â€œGCR Advertise.â€ A STA that receives this DMS Response frame from its AP may initiate a GCR agreement for one or more of the group addresses contained in the frame. A STA requests use of the GCR service for a group address by sending a DMS Descriptor (as described in 11.24.16.2) with the following modifications: â€” The DMS Descriptor shall contain one TCLAS element with the frame classifier type equal to 0 (Ethernet parameters), one TSPEC element, and one GCR Request subelement. â€” In addition, the DMS Descriptor may contain other TCLAS elements. â€” When there are multiple TCLAS elements, a TCLAS Processing element shall be present, and the Processing subfield in the TCLAS Processing element shall be set to 0. Otherwise, no TCLAS Processing elements shall be present in the DMS Descriptor. â€” The TSID subfield within the TS Info field of the TSPEC element shall be reserved. Since the AP might choose a delivery method of GCR-SP, the non-AP STA should set the Minimum Service Interval, Maximum Service Interval, and Service Start Time fields in the TSPEC element to indicate the STAâ€™s preferred wakeup schedule. In a mesh BSS, the Delivery Method field shall not be set to â€œGCR-SP.â€ 1816 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” The GCR Request subelement specifies the retransmission policy and delivery method requested by the non-AP STA for the group addressed stream. A STA shall not request transmission of a group address via the GCR service while it has an active DMS for this group address. A STA shall not request transmission of a group address via DMS while it has an active GCR service for this group address. An AP or mesh STA accepts a GCR request by sending a DMS Response frame with a DMS Response element that contains a DMS Status field with the Response Type field set to â€œAcceptâ€ (as described in 11.24.16.2) with the following modifications: â€” The DMS Status field shall include a GCR Response subelement indicating the retransmission policy, delivery method, and GCR concealment address for the group addressed stream. The Retransmission Policy field shall not be set to â€œNo Preference.â€ The Delivery Method field shall not be set to â€œNo Preference.â€ The GCR Concealment Address field of the GCR Response subelement shall be set to dot11GCRConcealmentAddress. In a mesh BSS, the Delivery Method field shall not be set to â€œGCR-SP.â€ â€” If the GCR group addressed stream is subject to the GCR-SP delivery method, then the AP shall also include a Schedule element in the DMS Status field indicating the wakeup schedule for the group addressed stream. â€” If a TSPEC Element is included, the TSID subfield shall be set to 0. For each GCR Request subelement, the AP or mesh STA may â€” Adopt the requested retransmission policy and delivery method, or â€” Maintain its existing retransmission policy and delivery method, or â€” Select an alternate retransmission policy and delivery method, or â€” Deny GCR service for the group addressed stream. In an infrastructure BSS, the retransmission policy shall not be GCR block ack for a GCR group address while the AP has a GCR agreement for the group address with a non-AP STA that had the Advanced GCR field equal to 0 in the Extended Capabilities element in the (Re)Association Request frame most recently received by the AP. In a mesh BSS, the retransmission policy shall not be GCR block ack for a GCR group address while the mesh STA has a GCR agreement for the group address with a peer mesh STA that had the Mesh GCR field equal to 0 in the Extended Capabilities element. An AP or mesh STA denies a GCR request by sending a DMS Response frame with a DMS Response element that contains a DMS Status field with â€” The Response Type field set to â€œDenyâ€ (as described in 11.24.16.2) and â€” An empty GCR Response subelement. If an AP or mesh STA denies a GCR request, it may suggest an alternative TCLAS-based classifier by including one or more TCLAS elements and an optional TCLAS Processing element (as described in 9.4.2.33). One TCLAS element shall be included in the DMS Descriptor with the frame classifier type equal to 0 (Ethernet parameters). Other TCLAS elements may be included in the DMS Descriptor, but, if present, a TCLAS Processing element with the Processing subfield equal to 0 shall also be included. If a STA requesting GCR service determines that one or more GCR Response subelements are unacceptable, then the STA shall discard any received ADDBA Request frames for the unacceptable GCR streams and shall send a new DMS Request frame containing a DMS Request element with one DMS Descriptor for each 1817 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications unacceptable GCR stream. The DMSID fields shall be set to the DMSIDs of the unacceptable streams, and the Request Type field shall be set to â€œRemove.â€ In an infrastructure BSS, if the non-AP STA accepts the response to its GCR request, the non-AP STA shall set dot11GCRConcealmentAddress to the value contained in the GCR Concealment Address field of the GCR Response subelement. In a mesh BSS, if a STA requesting GCR service accepts the response to its GCR request, it shall add to dot11GroupAddressesTable the value contained in the GCR Concealment Address field of the GCR Response subelement. In a mesh BSS, a GCR agreement instance is identified by a GCR agreement instance identifier. The mesh GCR agreement instance consists of the DMSID, localMAC, peerMAC, and concealment address. For each group addressed stream requested by the non-AP STA and accepted by the AP, the AP shall immediately initiate a block ack negotiation if both of the following conditions are true: â€” The AP advertised an Advanced GCR field equal to 1 in its Extended Capabilities element. â€” The non-AP STA advertised an Advanced GCR field equal to 1 in the Extended Capabilities element in the (Re)Association Request frame most recently received by the AP. For each group addressed stream requested by a mesh STAâ€™s peer (STA1), the mesh STA (STA2) receiving the request shall immediately initiate a block ack negotiation if STA2 transmitted a Mesh GCR field equal to 1 in the Extended Capabilities element in its mesh Beacon frame and STA2 received a mesh Beacon frame from STA1 in which the Mesh GCR field in the Extended Capabilities element is equal to 1. If all of the above conditions are true, the AP or mesh STA shall immediately initiate a block ack negotiation by sending an ADDBA Request frame to the STA that originated the GCR request. The Block Ack Policy subfield in the Block Ack Parameter Set field within the ADDBA Request frame shall not be set to 0. The TID subfield in the Block Ack Parameter Set field within the ADDBA Request frame shall be set to 0. The A-MSDU Supported subfield within the ADDBA Request frame shall be set to 1 (A-MSDU permitted). The Starting Sequence Number field within the ADDBA Request frame shall be greater than (modulo 4096) the last sequence number of the last group address frame transmitted before the ADDBA Request frame. A STA shall maintain this block ack agreement for the duration of its GCR agreement, irrespective of whether GCR block ack is the current retransmission policy. While the retransmission policy of the GCR group addressed stream is DMS, the STA receiving GCR frames shall suspend its block ack processing for the group addressed stream. NOTE Having a block ack agreement with all members of a GCR group address allows the AP or mesh STA to change the GCR retransmission policy dynamically. For each GCR agreement, there shall be only one retransmission policy and delivery method active at any time. A GCR agreement between a non-AP STA and an AP or between peer mesh STAs shall begin when the STA providing GCR service successfully transmits an individually addressed DMS Response frame with a DMS Response element containing a DMS Status field that has the Status field set to â€œAcceptâ€ (as described in 11.24.16.2) with the DMS Status field including a GCR Response subelement. 11.24.16.3.4 GCR frame exchange procedures In an infrastructure BSS, a GCR block ack agreement exists between a non-AP STA and an AP for a group addressed stream from when the non-AP STA successfully transmits an ADDBA Response frame until one of the following situations occurs: â€” The AP or non-AP STA successfully transmits a DELBA frame to the other party. â€” The GCR agreement no longer exists. 1818 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications In a mesh BSS, a GCR block ack agreement exists between a mesh STA and its peer mesh STA for a group addressed stream from the time when the mesh STA successfully transmits an ADDBA Response frame to the peer mesh STA until one of the following situations occurs: â€” The mesh STA or the peer mesh STA successfully transmits a DELBA frame to the other party. â€” This GCR block ack agreement expires (see 10.24.5). â€” The GCR agreement is terminated. An AP or a mesh STA may transmit a group addressed stream via the No-Ack/No-Retry (non-GCR; see 10.3.6) service and GCR service simultaneously. Each frame shall be transmitted via the No-Ack/No-Retry retransmission policy before it is transmitted via the GCR service, except when using the GCR-SP delivery method. The AP may transmit each frame via the No-Ack/No-Retry retransmission policy before or after it transmits the frame via the GCR service when using the GCR-SP delivery method. A STA providing GCR service may switch between the DMS, GCR block ack, or GCR unsolicited retry retransmission policies, but only one delivery mode may be active at any given time for each GCR group address. An AP or mesh STA shall transmit a frame belonging to a group address via the GCR service if any associated STA or peer mesh STA has a GCR agreement for the group address and, otherwise, does not transmit the frame via the GCR service. In an infrastructure BSS, an AP shall transmit a frame belonging to a group address via the No-Ack/No- Retry service if one or more of the following situations occur: â€” The group address is the broadcast address. â€” The group address is not the broadcast address, and at least one associated STA has the Robust AV Streaming bit equal to 0 in the Extended Capabilities element of the STAâ€™s most recent (Re)Association Request frame and has been determined by the AP to be a member of the group address (how this determination is made is out of the scope of this standard). â€” The group address is not the broadcast address, at least one non-AP STA has a block ack agreement for the group address, and the frame precedes the start of the block ack agreement (the sequence number of the frame is less than the starting sequence number of the block ack agreement, as described in 10.24.2). In a mesh BSS, a mesh STA providing GCR service shall transmit a frame belonging to a group address via the No-Ack/No-Retry service if one or more of the following situations occur: â€” The group address is the broadcast address. â€” The group address is not the broadcast address, and at least one peer mesh STA has the Mesh GCR bit equal to 0 in the Extended Capabilities element of the STAâ€™s most recent mesh Beacon frame and has been determined to be a member of the group address (how this determination is made is out of the scope of this standard). â€” The group address is not the broadcast address, at least one peer mesh STA has a block ack agreement for the group address, and the frame precedes the start of the block ack agreement (the sequence number of the frame is less than the starting sequence number of the block ack agreement, as described in 10.24.2). When the AP updates the retransmission policy, the AP shall set the Last Sequence Control field in the GCR Response subelement to the sequence number of the MPDU corresponding to the GCR traffic flow that is being updated that was delivered prior to the change in retransmission policy. To avoid undetected retries being passed up at a receiverâ€™s MAC SAP, duplicate detection and removal for group addressed frames is required in STAs with dot11RobustAVStreamingImplemented true or dot11MeshGCRImplemented true (see 10.3.2.11). GCR frames shall be QoS Data frames (with QoS subfield of the Subtype subfield set to 1). 1819 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If the block ack agreement is successfully established for the group addressed stream and the delivery method for the group addressed stream is GCR-SP, then the non-AP STA is awake for subsequent SPs (see 11.24.16.3.8). A STA may request a change of GCR service for a group addressed stream by sending a DMS Descriptor with the DMSID identifying the group address and the Request Type field set to â€œChangeâ€ (as described in 11.24.16.2) with the following modifications: â€” The DMS Descriptor shall contain zero TCLAS elements, zero TCLAS Processing elements, one TSPEC element, and one GCR Request subelement. â€” The TSPEC element and GCR Request subelement of this DMS Descriptor shall together contain at least one field that is different from the original TSPEC element and GCR Request subelement identified by the DMSID. An AP or mesh STA may update the retransmission policy, delivery method, and schedule for any reason, such as the size of the group changes, the capabilities of the members of the group change, GCR Request subelements for the group are received, or multicast diagnostics are needed. The AP or mesh STA advertises the current settings upon a change and periodically by either of the following methods: â€” Transmitting an unsolicited DMS Response frame with the current settings addressed to the GCR concealment address. This DMS Response frame shall be scheduled for delivery at the appropriate DTIM interval or SP in which all STAs within the group are awake to receive the frame. One TCLAS element shall be included with the frame classifier type equal to 0 (Ethernet parameters). Other TCLAS elements may be present, but if present, a TCLAS Processing element with the Processing subfield equal to 0 shall also be included. One TSPEC element and one GCR subelement shall be included per DMS Descriptor in the DMS Response element of the DMS Response frame to identify each GCR stream. The DMSID that identifies the GCR stream shall be included in the DMS Descriptor. Each Status field in the DMS Status fields included in the frame shall be set to â€œGCR Advertise.â€ â€” Transmitting unsolicited DMS Response frames with the current settings individually addressed to each GCR group member. Each GCR stream is identified by the DMSID in a DMS Status field in the DMS Response element of the DMS Response frame. These DMS Status fields shall not include a TCLAS element, TSPEC element, or GCR subelement. Each Status field in the DMS Status fields included in the frame shall be set to â€œGCR Advertise.â€ A STA receiving GCR frames shall recover from missing group addressed DMS Response frames containing GCR Response subelements that advertise a changed retransmission policy or delivery method according to Table 11-13 or Table 11-14, respectively. Table 11-13â€”STA recovery procedures for a changed retransmission policy Actual retransmission Current retransmission policy being used by the policy state at STA Recovery procedure AP or mesh STA receiving GCR frames providing GCR service GCR unsolicited retry or No-Ack/No-Retry A STA receiving GCR frames shall cancel the GCR GCR block ack service for the group address by sending a DMS Response frame that contains a DMS Descriptor with the Request Type set to â€œRemoveâ€ when no frames for the group address are received via the GCR service after a period of dot11GCRPolicyChangeTimeout. 1820 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 11-13â€”STA recovery procedures for a changed retransmission policy (continued) Actual retransmission Current retransmission policy being used by the policy state at STA Recovery procedure AP or mesh STA receiving GCR frames providing GCR service DMS GCR unsolicited retry or A STA receiving GCR frames shall update its current GCR block ack retransmission policy of the GCR stream to GCR unsolicited retry upon receiving an A-MSDU for the DMS group address concealed via the GCR concealment address. GCR unsolicited retry or DMS A STA receiving GCR frames shall update its current GCR block ack retransmission policy of the GCR stream to DMS upon receiving an A-MSDU with the RA field equal to the non-AP STAâ€™s individual address and the DA field of the A-MSDU subframe equal to the GCR group address. GCR unsolicited retry GCR block ack A STA receiving GCR frames shall update its current retransmission policy of the GCR stream to GCR block ack upon receiving a BlockAckReq frame with a GCR Group Address subfield equal to the GCR group address. GCR block ack GCR unsolicited retry A STA receiving GCR frames shall update its current retransmission policy of the GCR stream to GCR unsolicited retry if MSDUs for the GCR group address concealed via the GCR concealment address are being received yet no BlockAckReq frames for the GCR group address are received after a period of dot11GCRPolicyChangeTimeout. Table 11-14â€”Non-AP STA recovery procedures for a changed delivery method Current delivery method Actual delivery method Recovery procedure state at non-AP STA being used by the AP Non-GCR-SP GCR-SP A non-AP STA shall update the current delivery method state of the GCR stream to GCR-SP if a) No frames with the More Data subfield in the Frame Control field equal to 1 for the GCR stream are received for a period of dot11GCRPolicyChangeTimeout, and b) At least one frame for the GCR stream with the More Data subfield in the Frame Control field equal to 0 is received. Note that upon detecting condition a), the STA should enter the awake state in order to assist with detecting condition b). GCR-SP Non-GCR-SP A non-AP STA shall update the current delivery method of the GCR stream to Non-GCR-SP if no frames with the More Data subfield in the Frame Control field equal to 0 for the GCR stream are received for a period of dot11GCRPolicyChangeTimeout and at least one frame for the GCR stream with the More Data subfield in the Frame Control field equal to 1 is received. 1821 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A GCR agreement between a non-AP STA and an AP or between peer mesh STAs shall end (as described in 11.24.16.2) when one of the following situations occurs: â€” In an infrastructure BSS, the AP deauthenticates or disassociates the non-AP STA, or â€” In a mesh BSS, the mesh STA providing GCR service tears down the peer link to the mesh STA receiving GCR frames, or â€” The non-AP STA or mesh STA receiving GCR frames successfully transmits a DMS Request frame to the AP or mesh STA providing GCR service containing a DMS Request element that has a DMS Descriptor with the DMSID identifying the group addressed stream and the Request Type field set to â€œRemove,â€ or â€” The AP or a mesh STA providing GCR service successfully transmits an individually addressed DMS Response frame with a DMS Response element containing a DMS Status field with the DMSID identifying the group addressed stream that has the Status field set to â€œTerminate.â€ A GCR agreement between a non-AP STA and an AP or between peer mesh STAs shall end (as described in 11.24.16.2) with the following modifications: â€” The DMS Status field shall include a GCR Response subelement. â€” The DMS Response frame may be transmitted by an AP to the GCR concealment address or as an individually addressed frame to each STA that has an active GCR agreement for this GCR group address. The DMS Response frame shall be transmitted by a non-AP STA or mesh STA as an individually addressed frame to the STA that it has an active GCR agreement for this GCR group address. A cancellation of a GCR agreement shall also cause the block ack agreement to be canceled for the GCR stream. 11.24.16.3.5 Concealment of GCR transmissions Concealment prevents group addressed frames transmitted via the GCR unsolicited retry or GCR block ack retransmission policies from being passed up through the MAC SAPs of GCR-incapable STAs. GCR group addressed MSDUs shall be sent in an A-MSDU when â€” Retransmitted via the GCR unsolicited retry or GCR block ack retransmission policies or â€” Transmitted via the GCR-SP delivery method. The MPDU containing this A-MSDU shall have the Address 1 field set to dot11GCRConcealmentAddress and the Retry subfield of the Frame Control field set to 1. The DA field in the A-MSDU subframe shall contain the GCR group address that is being concealed (i.e., the same value as the DA field for non-GCR group addressed delivery). One A-MSDU subframe shall be contained within one A-MSDU frame. GCR group addressed MSDUs retransmitted via the GCR unsolicited retry or GCR block ack retransmission policies shall set the Sequence Control field of the MPDU containing this A-MSDU to the same value as the Sequence Control field of the frame that contained the corresponding MSDU that was transmitted with the Retry subfield equal to 0. The first transmission attempt of a GCR group addressed MSDU transmitted via the GCR-SP delivery method shall set the Sequence Control field of the MPDU containing this A-MSDU according to the procedures defined in 10.3.2.11. A STA with dot11RobustAVStreamingImplemented true or dot11MeshGCRImplemented true shall not use its GCR concealment address for any purpose other than the transmission of GCR streams. A STA with dot11RobustAVStreamingImplemented true or dot11MeshGCRImplemented true and with a GCR agreement shall add the GCR concealment address from the GCR Response subelement to the STAâ€™s dot11GroupAddressesTable. 1822 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications An AP with dot11RobustAVStreamingImplemented true shall not send an MSDU to the DS that has the DA field set to the GCR concealment address. The Individual/Group Address bit (LSB of octet 0) of dot11GCRConcealmentAddress shall be set to 1. 11.24.16.3.6 GCR unsolicited retry A STA supports the GCR unsolicited retry retransmission policy if dot11RobustAVStreamingImplemented or dot11MeshGCRImplemented is true; otherwise, the STA does not support the GCR service with retransmission policy equal to GCR unsolicited retry. An AP or a mesh STA adopting the GCR unsolicited retry retransmission policy for a GCR group address chooses a lifetime limit for the group address. The AP or a mesh STA may vary the lifetime limit for the group address at any time and may use different lifetime limits for different GCR group addresses. An AP adopting the GCR unsolicited retry retransmission policy for a GCR group address shall transmit each MSDU according to 11.24.16.3.5, subject to the lifetime and retry limits. Transmission uses the backoff procedure described in 10.22.2.11.2. If a block ack agreement has successfully been established for a group addressed stream that is delivered using the GCR unsolicited retry retransmission policy, the STA shall follow the duplicate detection procedures defined in 10.3.2.11 and 10.24.4. If a block ack agreement has successfully been established for all STAs receiving a GCR group address, for a group delivered using the GCR unsolicited retry retransmission policy, the AP may retransmit any of the last m A-MSDUs that have the DA field in the A-MSDU subfield set to the GCR group address, where m is GCR buffer size (as defined in 11.24.16.3.7), subject to the lifetime limits. If there is a STA with an active GCR agreement for a group address that does not have an active block ack agreement, the AP shall not retransmit a preceding A-MSDU for that group address. A preceding A-MDSU is defined as an A-MSDU with a sequence number value that precedes, using the modulo 212 rules defined in 10.24.1, the sequence number value of the last transmitted A-MSDU for the GCR group address. 11.24.16.3.7 GCR block ack A STA supports the GCR block ack retransmission policy if dot11AdvancedGCRImplemented is true or dot11MeshGCRImplemented is true; otherwise, the STA does not support the GCR service with retransmission policy equal to GCR Block Ack. The AP shall maintain a set of the most recently received values of the Buffer Size subfield from the Block Ack Parameter Set field in the ADDBA Response frame received from each member of a specific group address. The minimum of that set of values is defined to be the GCR buffer size for that group address (see 10.24.10). 11.24.16.3.8 GCR-SP The GCR-SP delivery method transmits GCR group addressed frames at intervals that might be smaller than the beacon interval. A STA supports the GCR-SP delivery method if dot11AdvancedGCRImplemented is true; otherwise, the STA does not support the GCR service with the delivery method equal to GCR-SP. NOTE Group addressed traffic transmitted at the end of a DTIM beacon might be an impediment to providing QoS for uplink transmissions and in OBSSs. Therefore, APs in an overlapped environment are advised to make use of GCR-SP for group addressed traffic that consumes appreciable medium time. 1823 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Group addressed MSDUs shall not be transmitted via the GCR-SP delivery method policy if a non-GCR-SP delivery method is active for that group address. All MSDUs transmitted via the GCR-SP delivery method shall be concealed using the procedures described in 11.24.16.3.5. A STA receiving group addressed MSDUs transmitted via the GCR-SP delivery method shall discard all nonconcealed MSDUs for this group address. An AP advertises that a group addressed stream is subject to GCR-SP within a GCR Response subelement. The subelement indicates the start of each SP. See 11.2.3.5. When the Service Interval field in the Schedule element of the DMS Response frame is greater than 0, at every scheduled SP, the AP schedules for transmission buffered GCR-SP group addressed frames assigned to that particular group address. An AP shall not establish both a GCR-SP and an FMS agreement for a group addressed stream with a single non-AP STA. An AP may use the GCR-SP delivery method for an accepted GCR service when all of the non-AP STAs that requested the GCR service for the group address have the Robust AV Streaming bit in the Extended Capabilities element equal to 1 and the Advanced GCR bit in the Extended Capabilities element equal to 1. Otherwise, the AP shall not use the GCR-SP delivery method for the accepted GCR service. When the Service Interval field in the Schedule element of the DMS Response frame is 0, the AP may transmit group addressed frames that are subject to this GCR agreement at any time without regard to the power state of non-AP STAs in the group. This delivery method is called GCR-A, where all members of the group need to stay in the awake state to receive these group addressed frames. 11.24.17 WNM notification Implementation of the WNM notification capability is optional for a WNM STA. A STA that implements the WNM notification capability has dot11WNMNotificationImplemented equal to true. When dot11WNMNotificationImplemented is true, dot11WirelessManagementImplemented shall be true. A STA in which dot11WNMNotificationActivated is true is defined as a STA that supports WNM notification. The STA shall set to 1 the WNM Notification field of the Extended Capabilities elements that it transmits. A STA that supports WNM notification reporting may send a WNM Notification Request or Response frame to a STA within the same infrastructure BSS or the same IBSS whose last received Extended Capabilities element contained a value of 1 for the WNM Notification field in the Extended Capabilities field; it shall not send a WNM Notification Request or Response frame otherwise. A STA shall transmit both the WNM Notification Request frame and the WNM Notification Response frame with an individually addressed destination address. The WNM notification capability enables a STA to indicate management information, including information about its firmware to a peer STA. Use of the information provided is outside the scope of this standard. A non-AP STA that supports WNM notification and receives a WNM Notification Request frame with the Type field equal to 0 shall respond with a WNM Notification Response frame with the Response Status field set to 0. 11.25 WLAN interworking with external networks procedures 11.25.1 General This subclause describes the actions and the procedures that provide interworking capabilities between IEEE 802.11 infrastructure and external networks. 1824 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.25.2 Interworking capabilities and information STAs indicate their support for interworking service by setting dot11InterworkingServiceActivated to true. When dot11InterworkingServiceActivated is true, STAs include the Interworking element in Beacon and Probe Response frames, and non-AP STAs include the Interworking element in Probe Request frames. When dot11InterworkingServiceActivated and dot11ExtendedChannelSwitchActivated are both true in an infrastructure BSS, the AP may provide its operating channel and operating class to an Interworked SSPN using the values from dot11OperatingClassesTable. In an infrastructure BSS, the Interworking element contains signaling for Homogeneous ESSs. The HESSID is a 6-octet MAC address that identifies the homogeneous ESS. The HESSID value shall be identical to one of the BSSIDs in the homogeneous ESS. Thus, it is a globally unique identifier that, in conjunction with the SSID, may be used to provide network identification for an SSPN. NOTEâ€”This standard assumes that the HESSID field in the Interworking element is administered consistently across all BSSs in a homogeneous ESS. The Interworking element also provides an access network type in Beacon and Probe Response frames to assist the non-AP STA with network discovery and selection. 11.25.3 Interworking procedures: generic advertisement service (GAS) 11.25.3.1 Introduction This subclause describes the actions and procedures that are used to invoke GAS. GAS may be used to enable network selection for STAs when dot11InterworkingServiceActivated is true. GAS provides transport mechanisms for advertisement services while STAs are in the unassociated state as well as the associated state. This is accomplished via the use of Public Action frames, which are Class-1 frames. GAS information shall be transmitted using individually addressed Public Action frames. When management frame protection is negotiated, stations shall use individually addressed Protected Dual of Public Action frames instead of individually addressed Public Action frames. A GAS frame exchange may take place between two STAs; one STA transmits a GAS Query Request and the other STA transmits the GAS Query Response as described in 11.25.3.2. The Advertisement Protocol transported by the GAS is one of the query protocols in Table 9-215. GAS shall be supported by a STA when dot11InterworkingServiceActivated is true. ANQP shall be supported by a STA when dot11InterworkingServiceActivated is true. Other advertisement protocols shall be supported when the corresponding dot11GASAdvertisementID is present. A STA shall not transmit a GAS Query for any Advertisement Protocol unless that Advertisement Protocol ID is included in the Advertisement Protocol element in a Beacon or Probe Response frame. The Advertisement Protocol element specifies the Advertisement Protocols that a STA may use to communicate with Advertisement Servers, which may be collocated with a STA or in an external network. The Advertisement Protocol identifies the query language used by the Advertisement Server. The GAS protocol, which is used to transport Queries and Query Responses, is transparent to the Advertisement Protocol. 1825 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.25.3.2 GAS Protocol 11.25.3.2.1 General The presence of the Interworking element in Beacon or Probe Response frames indicates support for the GAS protocol. The presence of the Advertisement Protocol element in Beacon or Probe Response frames indicates the Advertisement Protocol IDs supported in the BSS or IBSS. A STA transmits a GAS Query Request in a GAS Initial Request frame and the responding STA provides the GAS Query Response or information on how to receive the GAS Query Response in a GAS Initial Response frame. The GAS Query Response shall be delivered in a single GAS Initial Response frame or in one or more GAS Comeback Response frames; the GAS Query Response shall not be split between a GAS Initial Response frame and one or more GAS Comeback Response frames. The GAS message sequence diagrams are shown in Figure 11-38, Figure 11- 39, and Figure 11-40. Figure 11-38 describes the GAS frame exchange sequence when dot11GASPauseForServerResponse is true and the result of the GAS query fits within one MMPDU. Requesting Responding Advertisement STA STA Server GAS Initial Request Query Request Query Response GAS Initial Response Outside the scope of this standard Figure 11-38â€”GAS frame sequence with dot11GASPauseForServerResponse equal to true 1826 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Figure 11-39 describes the GAS frame exchange sequence when dot11GASPauseForServerResponse is true and the result of the GAS query is too large to fit in one MMPDU and GAS fragmentation is used for delivery. The number of GAS Comeback Request and GAS Comeback Response frames depends on the number of GAS fragments required for delivery of the result of the GAS query. Requesting Responding Advertisement STA STA Server GAS Initial Request Query Request GAS Initial Response Query Response Comeback delay = 1TU GAS Comeback Request GAS Comeback Response GAS Comeback Request GAS Comeback Response GAS Comeback Request GAS Comeback Response Optional GAS frame Outside the scope of this standard Figure 11-39â€”GAS frame sequence with GAS fragmentation and dot11GASPauseForServerResponse equal to true 1827 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Figure 11-40 describes the GAS frame exchange sequence when dot11GASPauseForServerResponse is false. The number of GAS Comeback Request and GAS Comeback Response frames depends on the number of GAS fragments required for delivery of the GAS Query Response. Requesting Responding Advertisement STA STA Server GAS Initial Request Query Request GAS Initial Response Comeback delay Query Response GAS Comeback Request GAS Comeback Response GAS Comeback Request GAS Comeback Response GAS Comeback Request GAS Comeback Response Optional GAS frame Outside the scope of this standard Figure 11-40â€”GAS frame sequence with GAS fragmentation and dot11GASPauseForServerResponse equal to false 11.25.3.2.2 STA procedures to transmit a GAS Query Upon receipt of an MLME-GAS.request primitive, the requesting STA shall engage in the following procedure to transmit a query: a) The requesting STA sends a GAS Query by transmitting a GAS Initial Request frame containing a Dialog Token, an Advertisement Protocol element containing an Advertisement Protocol ID and the GAS Query in the Query Request field. If the GAS Initial Request frame requests information relating to a frequency band different from the frequency band in which the frame is transmitted, the STA shall include a Multi-band element in the GAS Initial Request frame with the Band ID, Operating Class, and Channel Number fields set to indicate to which frequency band the GAS Initial Request frame applies, with other fields in the Multi-band element being reserved. If the frame requests information relating to the frequency band in which the frame is transmitted, a Multi-band element shall not be included in the frame. 1828 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications b) Upon transmission of the GAS Initial Request frame, the STA shall set a timer, referred to as the dot11GASResponseTimer, equal to dot11GASResponseTimeout or the QueryFailureTimeout parameter provided in the MLME-GAS.request primitive. If both values are present, the timer shall be set to the lesser of the two values. c) If the requesting STA is not in the associated state, it shall remain in active mode until the receipt of a GAS Initial Response frame with the same value of the Dialog Token field as in the GAS Initial Request frame or until the expiration of the timer, whichever occurs first. If the requesting STA is in the associated state, it may go into power save state until the GAS Initial Response frame is available for receipt or the timer expiration, whichever occurs first. d) If the dot11GASResponseTimer expires before a GAS Initial Response frame is received, the GAS Query was not successful and the MLME shall issue an MLME-GAS.confirm primitive with ResultCode equal to GAS_QUERY_TIMEOUT and shall set the Query Response Length field to 0. 11.25.3.2.3 STA procedures to post a GAS Query to an Advertisement Server Upon receipt of a GAS Initial Request frame, an MLME-GAS.indication primitive shall be issued to the STAâ€™s SME. Upon receipt of an MLME-GAS.response primitive, the STA shall transmit a GAS Initial Response frame to the requesting STA according to the following procedures. If the requesting STA is in the associated state and in the power save mode, the responding STA shall buffer the MMPDU for transmission according to the procedures in 11.2.3; otherwise the STA shall queue the MMPDU for transmission as follows: a) If the Advertisement Protocol ID in the Advertisement Protocol element does not equal the value contained in any dot11GASAdvertisementID, then the STA shall not post the query to an Advertisement Server. The STA shall transmit an individually addressed GAS Initial Response frame to the requesting STA containing a dialog token whose value is identical to the dialog token in the GAS Initial Request frame, a Status Code equal to GAS_ADVERTISEMENT_PROTOCOL_NOT_SUPPORTED (see Table 9-46), an Advertisement Protocol element containing the Advertisement Protocol ID used in the GAS Initial Request frame and a Comeback Delay and Query Response Length both set to 0. b) If the query request corresponds to an Advertisement Protocol whose server is currently unreachable, the responding STA shall transmit an individually addressed GAS Initial Response frame to the requesting STA containing a dialog token whose value is identical to the dialog token in the GAS Initial Request frame, a Status Code equal to SERVER_UNREACHABLE, an Advertisement Protocol element containing an Advertisement Protocol ID equal to the Advertisement Protocol ID contained in the GAS Initial Request frame and a Comeback Delay and Query Response Length both set to 0. The method used by the AP to determine the server is unreachable is out of scope of this standard. A STA receiving a status code indicating SERVER_UNREACHABLE should wait at least 1 minute before transmitting any further queries using the same Advertisement Protocol ID to the responding STA. c) If the Advertisement Protocol ID in the Advertisement Protocol element equals the value contained in any dot11GASAdvertisementID, then the STA shall initialize a timer, referred to as the PostReplyTimer, to the value in dot11GASResponseTimeout and post the query to the Advertisement Server identified by the Advertisement Protocol ID. The methods and protocols the STA uses to post the query are outside the scope of this standard. d) If dot11GASPauseForServerResponse is false, the responding STA shall transmit an individually addressed GAS Initial Response frame to the requesting STA containing a dialog token whose value is identical to the dialog token in the GAS Initial Request frame, a Status Code set to SUCCESS, an Advertisement Protocol element containing the Advertisement Protocol ID used in the GAS Initial Request frame, a GAS Comeback Delay set to the value in dot11GASComebackDelay for this Advertisement Protocol and a Query Response Length set to 0. e) If dot11GASPauseForServerResponse is true, the GAS Query Response is delivered as defined in 11.25.3.2.4. 1829 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.25.3.2.4 STA procedures for transmitting the GAS Query Response After receiving a query response from the Advertisement Server, the responding STA shall buffer the query response for a minimum of dot11GASResponseBufferingTime after the expiration of the GAS Comeback Delay or until the query response is delivered. If the responding STA does not receive a GAS Comeback Request frame whose source MAC address and dialog token match the source MAC address and value of the Dialog Token field respectively of the corresponding GAS Initial Response frame within this time, it may drop the query response. If the query response received from the Advertisement Server is larger than dot11GASQueryResponseLengthLimit for the matching dot11GASAdvertisementID or is larger than the value of the Query Response Length Limit field received from the requesting STA, the responding STA shall discard the response and instead return a status code of GAS_QUERY_RESPONSE_TOO_ LARGE in the GAS Comeback Response frame. This behavior helps to prevent abuses of the medium that may be caused by overly general queries, which evoke a very large query response. The GAS protocol supports Query Responses whose length is greater than the IEEE 802.11 maximum MMPDU size by the STAâ€™s use of the GAS Query Response Fragment ID field in the GAS Comeback Response frame; the Query Response Fragment ID shall be set to 0 for the initial fragment and incremented by 1 for each subsequent fragment in a multi-fragment query response. If the Query Response is a multi- fragment response (i.e., contains more than 1 fragment), the STA shall transmit all fragments that belong to the same Query Response until all fragments are exhausted. The STA shall set the More GAS Fragments field of the GAS Query Response Fragment ID to 0 when the transmitted fragment is the final fragment. If the GAS Initial Request frame that initiated the GAS transaction contains a Multi-band element, but the GAS Initial Response frame transmitted as a response does not contain a copy of the same Multi-band element, the Status Code in the GAS Initial Response frame shall be set to REQUEST_DECLINED. Otherwise, the requesting and responding STAs shall include a copy of the same Multi-band element in all subsequent GAS Initial Response, GAS Comeback Request, and GAS Comeback Response frames transmitted as part of the GAS transaction. Inclusion of the Multi-band element indicates to which frequency band the GAS transaction applies. If the GAS Initial Request frame that initiated the GAS transaction does not contain a Multi-band element, then none of the subsequent GAS Initial Response, GAS Comeback Request, and GAS Comeback Response frames transmitted as part of the GAS transaction shall include a Multi-band element. The following procedures shall be used by the responding STA to deliver the query response to the requesting STA: a) If dot11GASPauseForServerResponse is true: 1) If the PostReplyTimer expires before the GAS Query Response is received from the Advertisement Server, then the responding STA shall transmit an individually addressed GAS Initial Response frame to the requesting STA containing a dialog token whose value is identical to the dialog token in the GAS Initial Request frame, a Status Code set to GAS_QUERY_TIMEOUT (see Table 9-46), an Advertisement Protocol element containing the Advertisement Protocol ID used in the GAS Initial Request frame, a GAS Comeback Delay set to 0 and a Query Response Length set to 0. If the query response is subsequently received from the Advertisement Server, it shall be dropped by the responding STA. 2) If the Query Response received from the Advertisement Server is larger than dot11GASQueryResponseLengthLimit or requires more than 128 fragments for transmission to the requesting STA, it shall be dropped by the responding STA. Then the responding STA shall transmit an individually addressed GAS Initial Response frame to the requesting STA containing a dialog token whose value is identical to the dialog token in the GAS Initial Request frame, a Status Code set to GAS_QUERY_RESPONSE_TOO_ LARGE (see Table 9- 46), an Advertisement Protocol element containing the Advertisement Protocol ID used in the GAS Initial Request frame, a GAS Comeback Delay set to 0 and a Query Response Length set to 0. 1830 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 3) If the query responseâ€™s length is less than or equal to the maximum MMPDU size, the STA shall transmit an individually addressed GAS Initial Response frame to the requesting STA containing a dialog token whose value is identical to the dialog token in the GAS Initial Request frame, a Status Code set to SUCCESS, an Advertisement Protocol element containing the Advertisement Protocol ID used in the GAS Initial Request frame, a GAS Comeback Delay set to 0, the Query Response and a Query Response Length set to the query response length. This completes the GAS Query and GAS Query Response exchange. 4) If the query responseâ€™s length is larger than the maximum MMPDU size, the responding STA shall transmit an individually addressed GAS Initial Response frame to the requesting STA containing a dialog token whose value is identical to the dialog token in the GAS Initial Request frame, a Status Code set to SUCCESS, an Advertisement Protocol element containing the Advertisement Protocol ID used in the GAS Initial Request frame, a GAS Comeback Delay set to 1 TU, and a Query Response Length set to 0; this indicates the query response will be transmitted using GAS Comeback Request and Response frames that support GAS fragmentation as follows. b) If dot11GASPauseForServerResponse is false: 1) If the PostReplyTimer expires before the GAS Query Response is received from the Advertisement Server then the responding STA shall buffer for transmission a GAS Comeback Response frame with a status code equal to GAS_QUERY_TIMEOUT (see Table 9-46). If the query response is subsequently received from the Advertisement Server, it shall be dropped by the STA. 2) If the Query Response received from the Advertisement Server is larger than dot11GASQue- ryResponseLengthLimit, it shall be dropped by the responding STA. Then the STA shall buffer for transmission a GAS Comeback Response frame with status code set to GAS_QUERY_RE- SPONSE_TOO_ LARGE. c) If the Query Response is received before the expiration of the PostReplyTimer and its length is less than dot11GASQueryResponseLengthLimit, then the Query Response shall be buffered in one or more GAS Comeback Response frames with status code set to SUCCESS. The responding STA transmits one GAS Comeback Response frame in response to each GAS Comeback Request frame. If the Query Response received from the Advertisement Server is less than or equal to the maximum MMPDU size, then the GAS Query Response Fragment ID shall be set to 0 and the More GAS Fragments field in the GAS Query Response Fragment ID shall be set to 0. If the Query Response received from the Advertisement Server is greater than the maximum MMPDU size, then the GAS Query Response Fragment ID shall be set to 0 if this is the first fragment of the Query Response transmitted; otherwise it shall be incremented by 1; the More GAS Fragments field in the GAS Query Response Fragment ID shall be set to 1 if there are more fragments of the Query Response to be transmitted; otherwise it shall be set to 0 (i.e., this fragment is the last fragment of the Query Response). d) If a responding STA receives a GAS Comeback Request frame whose source MAC address and dialog token match the destination MAC address and value of the Dialog Token field respectively of an outstanding GAS Initial Response frame and the query response has not been received from the Advertisement Server and the PostReplyTimer has not expired, the responding STA shall transmit a GAS Comeback Response frame with status code equal to GAS_RESPONSE_NOT_RECEIVED_FROM _SERVER (see Table 9-46) and GAS Comeback Delay set to the value in dot11GASComebackDelay for this Advertisement Protocol to indicate when the requesting STA should come back to obtain its Query Response. e) If a responding STA receives a GAS Comeback Request frame whose source MAC address and Dialog Token do not match the destination MAC address and value of the Dialog Token field respectively of an outstanding GAS Initial Response frame, the STA should transmit a GAS Comeback Response frame with a status code equal to NO_OUTSTANDING_GAS_REQUEST. 1831 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A requesting STA shall transmit a GAS Comeback Request frame including the Dialog Token (drawn from the corresponding GAS Initial Response frame) immediately after the expiration of the GAS Comeback Delay. In response, the responding STA provides the Query Response in one or more GAS Comeback Response frames with the corresponding Dialog Token. If a requesting STA receives a GAS Comeback Response frame with status equal to QUERY_RESPONSE_OUTSTANDING, the requesting STA shall wait for the GAS Comeback Delay from that frame and upon expiration of the GAS Comeback Delay, transmit another GAS Comeback Request frame. If the requesting STAâ€™s dot11GASResponseTimer (set in 11.25.3.2.2 step b) expires prior to receiving a GAS Comeback Response frame whose source MAC address and dialog token match those in the corresponding GAS Initial Response frame, the STA shall issue an MLME-GAS.confirm primitive with ResultCode equal to GAS_QUERY_TIMEOUT and shall set the Query Response Length to 0. If a requesting STA receives a GAS Comeback Response frame with status equal to SUCCESS and the More GAS Fragments field in the GAS Query Response Fragment ID equal to 1, it shall transmit another GAS Comeback Request frame in order to retrieve the next GAS fragment of a multi-fragment query response. If a requesting STA receives a GAS Comeback Response frame with status equal to SUCCESS and the More GAS Fragments field in the GAS Query Response Fragment ID equal to 0, the requesting STAâ€™s MLME shall determine that all fragments have been received by confirming that all fragment IDs from 0 to the value in the GAS Query Response Fragment ID when the More GAS Fragments field was equal to 0 have been received. Upon receipt of the first GAS Comeback Response frame and every GAS Comeback Response frame thereafter, the dot11GASResponseTimer shall be reset. If all of the query response fragments were received before the expiration of the dot11GASResponseTimer, then the MLME shall issue an MLME-GAS.confirm primitive with result code set to SUCCESS along with the query response. If not all of the query response fragments were received before the expiration of the dot11GASResponseTimer, then the MLME shall issue an MLME-GAS.confirm primitive with ResultCode equal to GAS_QUERY_TIMEOUT and shall set the Query Response Length to 0. After a requesting STA receives the first GAS fragment of a multi-fragment query response, it shall continue retrieving the query response until all GAS fragments are received or until a transmission failure is detected; the requesting STA shall not commence the retrieval of a another GAS Query Response from the same STA until all GAS fragments are received or until a transmission failure is detected on the first GAS Query Response. If a requesting STA receives a GAS Comeback Response with status equal to GAS_QUERY_TIMEOUT or GAS_QUERY_RESPONSE_TOO_ LARGE then the MLME shall issue an MLME-GAS.confirm primitive with result code so indicating and shall set the Query Response Length to 0. If a requesting STA receives a GAS Comeback Response with status equal to NO_OUTSTANDING_GAS_REQUEST, then the MLME shall issue an MLME-GAS.confirm primitive with result code set to NO_OUTSTANDING_GAS_REQUEST and shall set the Query Response Length to 0. 11.25.3.2.5 GAS procedures interaction with multiple BSSID set Non-AP STAs in the unassociated state may use GAS procedures to query Advertisement Servers for information. As described in 11.25.3.2, APs indicate their support for a particular GAS Advertisement Protocol by including an Advertisement protocol element with that Advertisement protocol ID in Beacon and Probe Response frames as described in 9.3.3.3 and 9.3.3.11 respectively. Non-AP STAs receiving Beacon or Probe Response frames from different APs may choose to engage in GAS frame exchange sequences with one or more of these APs. In some deployment scenarios, these APs may be operating as a multiple BSSID set (as defined in 11.11.14) and may relay the GAS queries to the same Advertisement 1832 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Server. Depending on the configuration of the IEEE 802.11 access network, the external network and the Advertisement Server, a query response from the Advertisement Server might or might not be dependent on the BSSID used in the GAS frame exchange sequence and thus the STA from which the query was relayed. If the GAS Query Response is dependent on the BSSID, a requesting STA may choose to post queries using GAS procedures to more than one STA and expect possibly different Query Responses. If the Query Response is not dependent on the BSSID, then a requesting STA may choose to post queries using GAS procedures to only one STA in the multiple BSSID set (i.e., posting the same query to another member of the multiple BSSID set would yield the same response). When a Multiple BSSID (as defined in 11.11.14) set contains two or more members and dot11InterworkingServiceActivated is true and dot11GASAdvertisementID is present and a query to the Advertisement Server corresponding to dot11GASAdvertisementID is not dependent on the BSSID value used in the GAS frame exchange sequence to post the query, then the PAME-BI bit in the Advertisement Protocol tuple of the Advertisement Protocol element corresponding to dot11GASAdvertisementID shall be set to 1; otherwise this bit shall be set to 0. 11.25.3.3 ANQP procedures 11.25.3.3.1 General A STA may use ANQP to retrieve information as defined in Table 9-271 from a peer STA. A non-AP STA shall not transmit an ANQP request to an AP for any ANQP-element unless the ANQP Advertisement Protocol ID is included in the Advertisement Protocol element in a Beacon or Probe Response frame from that AP. The ANQP request consists of one or more ANQP elements drawn from Table 9-271 having an element type of Q in Table 11-15 and shall be ordered by nondecreasing Info ID. A Query List ANQP-element included in an ANQP request is formed as described in 11.25.3.2.2. The ANQP request is transported in the Query Request field of GAS Request frames as described in 11.25.3.2.4. The ANQP response should consist of ANQP elements having Info IDs present in the Query List ANQP- element response (if present) plus zero or more responses to other query elements; these ANQP elements shall be chosen from among those listed in Table 9-271 having an element type of S in Table 11-15 and shall be ordered by non-decreasing Info ID. The ANQP response is transported in the Query Response field of GAS Response frames, as described in 11.25.3.2.4. Table 11-15â€”ANQP usage BSS IBSS ANQP-element ANQP- ANQP-element name (subclause) element type Non-AP AP STA STA Query List 9.4.5.2 Q T, R T, R T, R Capability List 9.4.5.3 S T, R T, R T, R Venue Name 9.4.5.4 S T R â€” Emergency Call Number 9.4.5.5 S T R â€” Network Authentication Type 9.4.5.6 S T R â€” Roaming Consortium 9.4.5.7 S T R â€” 1833 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 11-15â€”ANQP usage (continued) BSS IBSS ANQP-element ANQP- ANQP-element name (subclause) element type Non-AP AP STA STA Vendor Specific 9.4.5.8 Q, S T, R T, R T, R IP Address Type Availability 9.4.5.9 S T, R T, R T, R NAI Realm 9.4.5.10 S T R T, R 3GPP Cellular Network 9.4.5.11 S T R â€” AP Geospatial Location 9.4.5.12 S T R T, R AP Civic Location 9.4.5.13 S T R T, R AP Location Public Identifier 9.4.5.14 S T R T, R URI/FQDN Domain Name 9.4.5.15 S T R â€” Emergency Alert Identifier URI 9.4.5.16 S T R T, R TDLS Capability 9.4.5.18 Q, S T,R T,R T, R Emergency NAI 9.4.5.17 S T R â€” Neighbor Report 9.4.5.19 S T R â€” Venue URL 9.4.5.20 S T T â€” Advice of Charge 9.4.5.21 S T T â€” Local Content 9.4.5.22 S T T â€” Network Authentication Type 9.4.5.23 S T R â€” with Timestamp Symbols Q element is an ANQP request S element is an ANQP response T ANQP-element may be transmitted by MAC entity R ANQP-element may be received by MAC entity â€” ANQP-element is neither transmitted nor received by MAC entity ANQP usage for infrastructure BSSs and IBSSs shall be in accordance with Table 11-15. ANQP usage defines the entities permitted to transmit and receive particular ANQP-elements. A STA having dot11InterworkingServiceActivated equal to true shall be capable of using the Query List ANQP-element to request the Capability List ANQP-element; support for all other ANQP-elements is optional. A STA that encounters an unknown or reserved ANQP Info ID value in a GAS frame (see 9-307) received without error shall ignore that ANQP Info ID and shall parse any remaining ANQP Info IDs. A STA that encounters an unknown vendor-specific OI field or subfield in a GAS frame (see 9-307) received without error shall ignore that field or subfield respectively, and shall parse any remaining fields or subfields for additional information with recognizable field or subfield values. 1834 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.25.3.3.2 Query list procedure The Query List ANQP-element is used by a requesting STA to perform an ANQP request using the procedures defined in 11.25.3.3.1. The requesting STA may include Info IDs in the Query List ANQP- element that have the sole ANQP-element type of S as shown in Table 11-15; the STA shall not include other Info IDs. A responding STA that encounters an unknown or reserved ANQP Info ID value in an Query List ANQP- element received without error shall ignore that ANQP Info ID and shall parse any remaining ANQP Info IDs. 11.25.3.3.3 Roaming Consortium procedure The Roaming Consortium ANQP-element, which contains a set of OIs, can be retrieved from an AP by a non-AP STA using the query list procedure defined in 11.25.3.3.2. The list of OIs included in the Roaming Consortium ANQP-element shall be those OIs in the dot11RoamingConsortiumTable. An AP may include an OI in the dot11RoamingConsortiumTable, if in conjunction with an AS, it is capable of successfully authenticating a non-AP STA having valid security credentials for the SSPN identified by that OI; the AP shall not include an OI otherwise. Methods used by the AP to authenticate the non-AP STA include, but are not limited to, RSNA algorithms and Open System authentication. Each OI identifies an SSP or group of SSPs (i.e., a roaming consortium). An SSP or group of SSPs can register for and obtain an OI using the procedures described in [B19]. A non-AP STA might have a locally stored binding between an OI and a set of security credentials with which it can authenticate to the network identified by the OI, that is, the SSPN. The method by which this binding is obtained is outside the scope of this standard. A non-AP STA can select from that list of credentials when authenticating to the BSS. 11.25.3.3.4 AP procedure for advertising EAP Method associated with an NAI Realm When dot11RSNAActivated is true, NAI realms along with their supported authentication methods may be advertised using the NAI Realm ANQP-element (see 9.4.5.10). Each realm may be optionally associated with a set of EAP methods. Each EAP method may be optionally associated with a set of Authentication Parameters. The NAI realm ANQP-element provides a hint on the methods a STA might use to establish an association in an RSN IEEE 802.1X environment. If the non-AP STA recognizes the NAI realm, it may attempt authentication even if it believes the EAP methods are incorrect. When dot11RSNAActivated is false and the Network Authentication Type (see 9.4.5.6) contains a Network Authentication Type Unit having a Network Authentication Type Indicator field equal to http/https redirection or DNS redirection, NAI realms without supported authentication methods may be advertised using the NAI Realm ANQP-element (see 9.4.5.10). A non-AP STA having dot11InterworkingServiceActivated equal to true may process the NAI Realm ANQP-element. The selection of the NAI realm the non-AP STA uses for authentication is outside the scope of this standard. A non-AP STA requests the NAI Realm ANQP-element using Query List procedures defined in 11.25.3.3.2. A non-AP STA having dot11InterworkingServiceActivated equal to true may process the EAP Method list as follows: â€” The EAP Method list provided by the AP shall be in priority order (the most preferred EAP Method is listed first). â€” The credential types help the STA to determine what credentials to use for authentication. 1835 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” The STA should confirm the GAS advertisement after an RSNA is established by performing a GAS Query for the NAI Realm ANQP-element using Protected Dual of Public Action frames. NOTEâ€”The advertisements should be confirmed after the RSNA is established to avoid downgrade attacks. The policy that determines whether a non-AP STA should attempt authentication and/or association with any particular IEEE 802.11 Access Network is outside the scope of this standard. 11.25.3.3.5 3GPP Cellular Network procedure A STA may retrieve 3GPP Cellular Network information using the Query List procedure in 11.25.3.3.2. Realms referenced in the 3GPP Cellular Network ANQP-element should not be included in the NAI Realm ANQP-element (see 9.4.5.10). 11.25.3.3.6 AP Geospatial Location procedure A STA may retrieve an APâ€™s geospatial location using the Query List procedure in 11.25.3.3.2. A STA in the associated state should retrieve Geospatial location information from the AP using the procedures in 11.11.9.6. 11.25.3.3.7 AP Civic Location procedure A STA may retrieve an APâ€™s civic location using the Query List procedure in 11.25.3.3.2. A STA in the associated state should retrieve civic location information from the AP using the procedures in 11.11.9.9. 11.25.3.3.8 AP Location Public Identifier URI/FQDN procedures A STA when dot11InterworkingServiceActivated is true may retrieve an APâ€™s Location Public Identifier URI or a location serverâ€™s FQDN using ANQP procedures in 11.25.3.3. A STA in the associated state should retrieve Location Public Identifier URI/FQDN information from the AP using the procedures in 11.11.9.10. Due to security concerns, there are some URI schemes that should be cautiously processed when received by a STA. For example, URIs using the scheme names â€œdata:â€ and â€œhttp:â€ may direct applications (e.g., a browser) on the STA to Internet pages that contain active scripts. Therefore, URIs received via this ANQP procedure should not be processed in a general manner, as these scripts may be inadvertently activated. Instead of listing all of the types of URIs that might be misused or potentially have harmful affects, Section 3.3 IANA registers acceptable URI schemes. 11.25.3.3.9 Emergency NAI procedure A STA that does not have valid credentials to authenticate to a network may use the information in the Emergency NAI ANQP-element as its EAP identity. The Emergency NAI ANQP-element can be retrieved from the AP using the Query List procedure in 11.25.3.3.2. The STA uses the emergency NAI procedure to indicate its intention to access the network without peer authentication by using the emergency NAI information as its identity in the authentication process, as described in IETF RFC 5216. 11.25.3.3.10 TDLS Capability procedure A STA may use the TDLS Capability ANQP-element (see 9.4.5.18) to discover TDLS capabilities of another TDLS capable STA using the Query List procedure in 11.25.3.3.2. 1836 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications An example of TDLS capability discovery using ANQP is given in Figure 11-41. STA1 STA2 Both STAs are currently in the same BSS ANQP request (TDLS Capability({Mode=TDLS; BSSID= 00-01-02-03-04-05; MAC= 00-01-02-03-04-05; DHCP=No; IP=192.168.2.1; Netmask=255.255.255.253}) ANQP response(TDLS Capability({Mode=TDLS; BSSID= 00-01-02-03-04-05; MAC= 00-01-02-03-04-06; DHCP=No; IP=192.168.2.2; Netmask=255.255.255.253}) STA1 Initiates a TDLS link to STA2 Figure 11-41â€”Example TDLS Capability discovery using ANQP The mechanism shall work as follows: a) STA1 determines the MAC address of STA2. b) STA1 sends an ANQP request to STA2. The ANQP request includes a TDLS Capability ANQP- element. c) STA2 receives the ANQP request and updates the TDLS Capability ANQP-element based on its own capabilities that is returned in the ANQP response to STA1. 11.25.3.3.11 Venue URL procedure The Venue URL ANQP-element is used to provide web page advertising services or information particular to the venue. This ANQP-element is to be used in conjunction with the Venue Name ANQP-element, to provide extra information about the venue. Typical operation is to use the Venue Name ANQP-element to determine the list of available venues advertised by a STA, and then the Venue URL ANQP-element is used, if required, to determine a list of Venue URLs, each entry corresponding to the Venue Name entry in the list returned by the Venue Name ANQP-element. 11.25.3.3.12 Advice of Charge procedure The Advice of Charge ANQP-element is used to provide financial cost advertisements in the form of Advice of Charge plan information. The plan information is provided on a per NAI realm basis, so that each authentication realm can advertise the charge associated with obtaining network access. This information might assist with a decision about proceeding with access. The use and operation of the Plan information schema is outside the scope of this standard. As ANQP-elements are transmitted in the clear, prior to STA association, one or more protected dual of public action frames should be used after association to verify this information. 1837 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.25.3.3.13 Local Content procedure The Local Content ANQP-element is used to provide local content URLs. Each URL points to local content information that might be relevant, for example by providing information about terms and conditions for BSS access, when automated login procedures are being used. Several URLs can be provided in the Local Content ANQP-element, each corresponding to a separate state. This allows the STA to display differing local content (e.g., terms and conditions, failure warning information, help page), through the STA association procedure. For example, the Local Content ANQP-element may return two Local Content Duple fields with values of the State field corresponding to â€œNot authenticatedâ€ and â€œFailure during authentication.â€ The requesting STA may display the contents of the local web page indicated by the first URL (â€œNot authenticatedâ€) showing terms and conditions of BSS access. If a subsequent association fails, then the requesting STA may display the contents of the local web-page indicated by the second URL (â€œFailure during authenticationâ€) showing a help page. 11.25.3.4 Registered location query protocol (RLQP) procedures When dot11GDDActivated is true, a STA may use RLQP to retrieve information as defined in Table 9-215 from a peer STA that has transmitted an Advertisement Protocol element indicating support for RLQP (see 9.4.2.93) in a Beacon or Probe Response frame. If information is not configured for a particular RLQP-element, then a query for that element returns that element with no optional fields. When RLQP is transmitted between the GDD enabling STA and the RLSS, it uses Ethertype 89-0d frames, as defined in Annex H. The RLQP payload contains RLQP-elements as specified in 9.4.6 and the Advertising Protocol element with an Advertising Protocol tuple whose Advertisement Protocol ID is set to the value of RLQP specified in Table 9-215. When RLQP is transmitted between the GDD dependent STA and its GDD enabling STA, it uses protected Action frames, but does not use Ethertype 89-0d frames. In some regulatory domains, the GDD enabling STA may be required to have secured connection with the RLSS. When security is required by regulation, the Ethertype 89-0d frame body may employ corresponding security features. Alternatively, various security protocols may also be selected by setting the Ethertype field to respective values. A webpage maintained by the IEEE Registration Authority Committee allowing search of the public values of the Ethertype field is found at http://standards.ieee.org/develop/regauth/ethertype/ public.html. 11.25.4 Interworking procedures: IEEE 802.21 MIH support IEEE Std 802.21-2008, the â€œMIH standard,â€ supports handovers across heterogeneous networks. STAs with dot11InterworkingServiceActivated equal to true and dot11GasAdvertisementId equal to MIH Information Service (see Table 9-215) shall support the transmission and reception of IEEE 802.21 MIIS queries for STAs in all states. STAs with dot11InterworkingServiceActivated equal to true and dot11GasAdvertisementId equal to MIH Command and Event Services Capability Discovery (see Table 9-215) shall provide support for IEEE 802.21 MICS/MIES capability discovery for non-AP STAs in all states. Additionally, support for IEEE 802.21 MIIS query and IEEE 802.21 MICS/MIES capability discovery to non-AP STAâ€™s in the associated state is provided by the STA forwarding IP datagrams destined for the MIH point of service to the IEEE 802.21 MIIS server. 1838 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A non-AP STA discovers support for these services by receiving Beacon or Probe Response frames with an Advertisement Protocol element having Advertisement Protocol ID(s) for MIH Information Service and/or IEEE 802.21 MICS/MIES capability discovery. A non-AP STA forms an IEEE 802.21 IS query by creating its query request according to the procedures defined in IEEE Std 802.21-2008 and formatting that request into an IEEE 802.21 MIH protocol frame as defined in 8.4 of IEEE Std 802.21-2008. The non-AP STA, using the procedures in 11.25.3.2, posts the query to an IEEE 802.21 IS server by transmitting the MIH formatted frame in the Query Request field of a GAS Initial Request frame. The Advertisement Protocol ID field in the GAS Initial Request frame is set to the value of IEEE 802.21 MIH Information Service (Table 9-215). Non-AP STAs in the unauthenticated or unassociated or associated states can use GAS procedures to discover MIH Command and Event Services Capability as specified in Table 9-215. A non-AP STA forms an IEEE 802.21 MIH Command and Event Service discovery request by encapsulating an MIH_Capability_Discover request (see IEEE Std 802.21-2008) into an MIH protocol frame as defined in 8.4 of IEEE Std 802.21-2008. The non-AP STA, using the procedures in 11.25.3.2, posts the discovery request to the network by transmitting the MIH formatted frame in the Query Request field of a GAS Initial Request frame. The Advertisement Protocol ID field in the GAS Initial Request frame is set to the value of MIH Command and Event Services Capability Discovery (Table 9-215). The method by which the AP relays the discovery request to the network is defined in IEEE Std 802.21-2008 and is outside the scope of this standard. A non-AP STA retrieves the IEEE 802.21 MIH Command and Event Service discovery response according to the procedures in 11.25.3.2. The discovery response is an MIH protocol frame as defined in 8.4 of IEEE Std 802.21-2008. 11.25.5 Interworking procedures: interactions with SSPN 11.25.5.1 General operation To provide SSPN Interface services, the IEEE 802.11 network interacts with the SSPN corresponding to the user of the non-AP STA either directly or via a roaming relationship. As part of setting up the RSN security association, user policies are communicated to the AP. If dot11SSPNInterfaceActivated is true, these permissions shall be stored in the APâ€™s dot11InterworkingTableEntry for that STA. Thereafter, the AP shall use the dot11InterworkingTableEntry for controlling the service provision to that non-AP STA. User policies from the SSPN affect authentication, authorization, and admission control decisions at the AP. In addition, the AP collects statistics about the non-AP STA and reports the statistics to the SSPN when requested. The SSPN may also send service provision instructions to the AP, e.g., to terminate the connection to a non-AP STA. Non-AP STAs do not support the SSPN Interface. Network deployments typically provide that the AP and the server in the SSPN have a trustworthy channel that can be used to exchange information, without exposure to or influence by any intermediate parties. The establishment of this secure connection between the IEEE 802.11 infrastructure and the SSPN is outside the scope of this standard. 11.25.5.2 Authentication and cipher suites selection with SSPN When the non-AP STA initiates IEEE 802.1X authentication, the EAP messages are forwarded to the SSPN based on the home realm information provided by the non-AP STA. If the IEEE 802.11 infrastructure is unable to forward the EAP message, the AP when dot11SSPNInterfaceActivated is true shall disassociate the non-AP STA with Reason Code NO_SSP_ROAMING_AGREEMENT. 1839 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications In addition to the EAP messages, the IEEE 802.11 infrastructure also provides extra information regarding the non-AP STA to the SSPN as defined in R.4.2, e.g., the Cipher Suite supported by non-AP STA, the location of the AP to which the non-AP STA is associated, etc. Such information may be used by the SSPN to make authentication and service provisioning decisions. In the SSPN Interface Service, the SSPN uses more information than is carried over EAP to decide on the authentication result. The SSPN might reject a connection request if the cipher suites supported by non-AP STA does not meet its security requirements. In this situation, the SME of the AP when dot11SSPNInterfaceActivated is true shall invoke a disassociation procedure as defined in 11.3.5.8 by issuing the MLME-DISASSOCIATE.request primitive. The AP disassociates the corresponding non-AP STA with Reason Code BAD_CIPHER_OR_AKM. The SSPN might reject the association request based on the location of the non-AP STA, e.g., if the non-AP STA is requesting association to an AP or associated to an AP located in a forbidden zone. In this situation, the SME of the AP when dot11SSPNInterfaceActivated is true shall invoke a disassociation procedure as defined in 11.3.5.8 by issuing the MLME-DISASSOCIATE.request primitive. The AP disassociates the corresponding non-AP STA with Reason Code NOT_AUTHORIZED_THIS_LOCATION. 11.25.5.3 Reporting and session control with SSPN An AP with dot11SSPNInterfaceActivated equal to true shall create a dot11InterworkingEntry in its dot11InterworkingTable for each STA that successfully associates. Permissions received from the SSPN for each associated STA shall be populated into the table; if no permissions are received from the SSPN for a particular non-AP STA, then the default permissions or an APâ€™s locally defined policy may be used for that STAâ€™s dot11InterworkingEntry. If the APâ€™s local policy is more restrictive than an objectâ€™s permission value received from the SSPN Interface, then the APâ€™s local policy may be enforced instead. In an AP when dot11SSPNInterfaceActivated is equal to true, the following procedure occurs: â€” The non-AP STAâ€™s state contained in the dot11InterworkingEntry shall be transmitted to the new AP after a successful transition. The state definition and the protocol used to transfer the state are beyond the scope of this standard. The new AP shall not forward any frames for that non-AP STA until it receives the dot11InterworkingEntry from the prior AP. â€” After the state is successfully transmitted to the new AP, the dot11InterworkingEntry for that non- AP STA shall be deleted from the prior APâ€™s dot11InterworkingTable. An AP with dot11SSPNInterfaceActivated equal to true shall delete the dot11InterworkingEntry for a non- AP STA when it disassociates from the BSS. An AP with dot11SSPNInterfaceActivated equal to true shall enforce the dot11InterworkingEntry limits for a particular non-AP STA by comparing the values of octet counters to authorized access limits: â€” dot11NonAPStationVoiceOctetCount is compared to dot11NonAPStationAuthMaxVoiceOctets. When the value of the authorized maximum octet count is exceeded, if the ACM field for AC_VO is equal to 1 then the HC shall delete all admitted TSs on this access category and deny all subsequent ADDTS Request frames with TID set 6 or 7, or if the ACM field for AC_VO is equal to 0 then the non-AP STA shall be disassociated using the MLME-DISASSOCIATE.request primitive with a reason code of PEER_INITIATED. â€” dot11NonAPStationVideoOctetCount is compared to dot11NonAPStationAuthMaxVideoOctets. When the value of the authorized maximum octet count is exceeded, if the ACM field for AC_VI is equal to 1 then the HC shall delete all admitted TSs on this access category and deny all subsequent ADDTS Request frames with TID set 4 or 5, or if the ACM field for AC_VI is equal to 0 then the non-AP STA shall be disassociated using the MLME-DISASSOCIATE.request primitive with a reason code of PEER_INITIATED. 1840 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” dot11NonAPStationBestEffortOctetCount is compared to dot11NonAPStationAuthMaxBestEffort- Octets. When the value of the authorized maximum octet count is exceeded, if the ACM field for AC_BE is equal 1 then the HC shall delete all admitted TSs on this access category and deny all subsequent ADDTS Request frames with TID set 0 or 3, or if the ACM field for AC_BE is equal 0 then the non-AP STA shall be disassociated using the MLME-DISASSOCIATE.request primitive with a reason code of PEER_INITIATED. â€” dot11NonAPStationBackgroundOctetCount is compared to dot11NonAPStationAuthMaxBackgroundOctets. When the value of the authorized maximum octet count is exceeded, if the ACM field for AC_BK is equal 1 then the HC shall delete all admitted TSs on this access category and deny all subsequent ADDTS Request frames with TID set 1 or 2, or if the ACM field for AC_BK is equal 0 then the non-AP STA shall be disassociated using the MLME- DISASSOCIATE.request primitive with a reason code of PEER_INITIATED. â€” dot11NonAPStationHCCAHEMMOctetCount is compared to dot11NonAPStationAuthMaxHCCAHEMMOctets. When the value of the authorized maximum octet count is exceeded, then the HC shall delete all admitted TSs with access policy of HCCA or HEMM and deny all subsequent ADDTS Request frames with access policy equal HCCA or HEMM. â€” The sum of dot11NonAPStationVoiceOctetCount, dot11NonAPStationVideoOctetCount, dot11NonAPStationBestEffortOctetCount, dot11NonAPStationAuthMaxBackgroundOctets, and dot11NonAPStationHCCAHEMMOctetCount is compared to dot11NonAPStationAuthMaxTotal- Octets. When the value of the authorized maximum octet count is exceeded, the non-AP STA shall be disassociated using the MLME-DISASSOCIATE.request primitive with a reason code of PEER_INITIATED. 11.25.6 Interworking procedures: emergency services support Emergency services support provides STAs with the ability to contact authorities in an emergency situation. The following procedures allow the STA to determine whether emergency services are supported by the AP or mesh STA, and whether unauthenticated emergency service access is allowed. In an AP, when dot11ESNetwork is true, the network is dedicated and limited to accessing emergency services. When dot11ESNetwork is true, the Access Network Type field in the Interworking element shall be set to the value for â€œEmergency services only networkâ€ (see Table 9-214). When dot11ESNetwork is false, the network is not limited to accessing emergency services, and the Access Network Type field in the Interworking element shall be set to a value other than â€œEmergency services only network.â€ See Table 11-16. Table 11-16â€”ESR and UESA field settings Description ESR UESA It is unspecified whether emergency services are reachable. 0 0 Emergency services are only reachable for authenticated STAs. 1 0 Reserved 0 1 Emergency services are reachable for STAs. 1 1 When an AP is located in a regulatory domain that requires emergency location capabilities, the ESR field shall be set to 1; otherwise the ESR field shall be set to 0. When an AP is located in a regulatory domain that requires emergency location capabilities and location capability is enabled on the AP, the Network Type shall be set to â€œEmergency services only networkâ€ (see Table 9-214), if location capability is enabled on the AP; 1841 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications otherwise the ESR field shall not be set to 1 and the Network Type shall not be set to â€œEmergency services only networkâ€. In Beacon and Probe Response frames, location capability is advertised when the Civic Location or Geo Location field in the Extended Capabilities Element is set to 1. In an MBSS, if location capability is supported, the mesh STA shall report its location for emergency services. When dot11ESNetwork is true in a mesh STA, the ESR shall be set to 1. When that mesh STA receives a Mesh Peering Open frame that includes the Interworking element with the ASRA field equal to 1, it allows access to emergency services and forwards MSDUs to an emergency server. NOTEâ€”The ASRA bit set to 1, informs the mesh STA to prioritize resources for the emergency call, to proactively find a better path before the link conditions deteriorate below a certain threshold, and/or to change some of the mesh STAâ€™s behavior (for example, to disable any power save features). When dot11ESNetwork is false in a mesh STA, the ESR shall be set to 0. When that mesh STA receives a Mesh Peering Open frame that includes the Interworking element with the ASRA field equal to 1, it is unable to support the mesh peering of emergency services and does not forward MDSUs to an emergency server. 11.25.7 Interworking procedures: emergency alert system (EAS) support The EAS provides alerts, typically issued by authorities. The Interworking Procedures EAS support enables the alerts to be transmitted upon request from APs to non-AP STAs. Subsequent to advertisement in Beacon and Probe Response frames, a non-AP STA uses GAS queries to retrieve an EAS message from the network according to the following procedures. When dot11EASActivated is true, EAS operation shall be supported. When EAS operation is not supported, dot11EASActivated shall be equal to false. When the IEEE 802.11 infrastructure is informed of the availability of an EAS message (the mechanism by which is outside the scope of this standard), an AP with dot11EASActivated equal true shall advertise the availability of the EAS message by including an Emergency Alert Identifier element (see 9.4.2.97) for that message in its Beacon and Probe Response frames. The AP shall include one instance of an Emergency Alert Identifier element in its Beacon and Probe Response frames for each active EAS Message. The Emergency Alert Identifier element provides an Alert Identifier Hash value, a unique indicator of the EAS Message of the alert to the non-AP STA. The Alert Identifier Hash value allows the non-AP STA to determine whether this is a new alert. NOTEâ€”The same value of hash will be computed by each AP in an ESS and by each AP in different ESSs. Thus a non- AP STA, which can download emergency alert messages when in a preassociated state, can unambiguously determine that it has already downloaded the message, avoiding unnecessary duplicates. When an EAS Message has expired (the mechanism by which is outside the scope of this standard), an AP with dot11EASActivated equal true shall remove the corresponding instance of an Emergency Alert Identifier element from its Beacon and Probe Response frames. The Alert Identifier Hash in the Emergency Alert Identifier element shall be computed using HMAC-SHA- 1-64 hash algorithm as shown in 9.4.2.97. After receiving an Alert Identifier Hash value for an EAS Message that has not already been retrieved from the network, a non-AP STA having dot11EASActivated equal true can retrieve the EAS message from the AP as follows â€” The procedures defined in 11.25.3.2, transmit the Alert Identifier Hash of the desired message in the Query request field of a GAS Initial Request frame. The Advertisement Protocol ID field in the GAS Initial Request frame is set to the value for EAS (see Table 9-215). â€” The Query response is a message formatted in accordance with OASIS EDXL. 1842 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” A URI is formed by concatenating the Emergency Alert URI with the hexadecimal numerals of the Alert Identifier Hash converted to lowercase ASCII encoded characters and the â€œ.xmlâ€ file extension. For example, if the Emergency Alert URI is http://eas.server.org and the Alert Identifier Hash is 0x1234567890abcdef, then the URI would be http://eas.server.org/1234567890abcdef.xml (the mechanism by which the URI is retrieved is outside the scope of this standard). The XML file is formatted in accordance with OASIS EDXL. The non-AP STA retrieves the Emergency Alert URI (see 9.4.5.16) using an ANQP request according to the procedures in 11.25.3.3. This method is recommended for non-AP STAs in the associated state. 11.25.8 Interworking procedures: support for the advertisement of roaming consortiums APs can assist non-AP STAs performing network discovery and selection through the advertisement of a Roaming Consortium element. The Roaming Consortium element contains information identifying an SSP or group of SSPs (i.e., a roaming consortium) whose security credentials might be used to authenticate with the AP transmitting this element. An SSP or group of SSPs can register for and obtain an OI using the procedures described in [B19]. Note that a non-AP STA may also use GAS procedures defined in 11.25.3.3.3 to retrieve a Roaming Consortium ANQP-element, which might contain more OIs than the Roaming Consortium element. APs having dot11InterworkingServiceActivated equal true and having one or more entries in the dot11RoamingConsortiumTable shall include the Roaming Consortium element in Beacon and Probe Response frames. An AP shall only include an OI in the dot11RoamingConsortiumTable, if, in conjunction with an AS, the AP is capable of successfully authenticating a non-AP STA that holds valid security credentials for the SSPN identified by that OI. Methods used by the AP to authenticate the non-AP STA include, but are not limited to, RSNA algorithms and Open System authentication. A non-AP STA might have a locally stored binding between an OI and a set of security credentials with which it can authenticate to the network identified by the OI, that is, the SSPN. The method by which this binding is obtained is outside the scope of this standard. A non-AP STA might select from that list of credentials when authenticating to the BSS. 11.25.9 Interworking procedures: support for QoS mapping from external networks Maintaining proper end-to-end QoS is an important factor when providing interworking service. This is because the external networks might employ different network-layer (Layer 3) QoS practices. For example, the use of a particular differentiated services code point (DSCP) for a given service might be different between different networks. To provide proper QoS over-the-air in the IEEE 802.11 infrastructure, the mapping from DSCP to UP for the corresponding network needs to be identified and made known to the STAs. If an inconsistent mapping is used then: â€” Admission control at the AP may incorrectly reject a service request, because the non-AP STA used the incorrect UP. â€” Non-AP STAs might use the incorrect value for User Priority in TSPEC and TCLAS elements. â€” The user might be given a different QoS over the IEEE 802.11 network than expected, e.g., a lower QoS might be provided than the STA expected. Therefore, APs with dot11QosMapActivated equal true shall set the QoS Map field in the Extended Capabilities element to 1; APs with dot11QosMapActivated equal false shall set the QoS Map field in the Extended Capabilities element to 0. The APâ€™s SME causes the QoS mapping to be available to higher layer protocols or applications so they will be able to set the correct priority in an MA-UNITDATA.request primitive. 1843 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications For frames transmitted by an AP belonging to an admitted TS, the UP obtained from the TSâ€™s TCLAS element shall be used instead of the UP derived from the QoS mapping. For frames transmitted by an AP belonging to an admitted TS not having a TCLAS element, the UP shall be derived from the QoS mapping. Non-AP STAs when dot11QosMapActivated is equal true shall set the QoS Map field in the Extended Capabilities element to 1. An AP receiving an Association Request frame or Reassociation Request frame when the QoS Map field in the Extended Capabilities element is equal 1 shall include the QoS Map element in the corresponding Association Response frame or Reassociation Response frame as defined in 9.3.3.7 or 9.3.3.9 respectively. Upon receiving the QoS Map element, the non-AP STAâ€™s SME causes the QoS mapping to be available to higher layer protocols or applications so they will be able to set the correct priority in an MA-UNITDATA.request primitive. When the APâ€™s SME detects a change in the QoS mapping information, it shall update the non-AP STA with the new QoS Map element. It accomplishes this update by invoking the MLME-QOS-MAP.request primitive. When the MAC entity at the non-AP STA receives a QoS Map Configure frame from the AP, the MLME shall issue an MLME-QOS-MAP.indication primitive to its SME. When the non-AP STAâ€™s SME receives the QoS Map response, it shall make the QoS Map available to higher layers so that in turn, they can invoke the MA-UNITDATA.request primitive with the correct priority. 11.26 Quality-of-service management frame (QMF) 11.26.1 General 11.26.1.1 Overview A QMF STA shall set dot11QMFActivated and dot11QosOptionImplemented to true. The QMF STA shall assign an access category to each Management frame according to the access category assignments indicated in the QMF policy that has been configured using the configuration procedures described in 11.26.2. A QMF STA shall set the QMFActivated subfield in the Extended Capabilities element to 1. A Management frame shall be transmitted as an IQMF when all five of the following conditions are met: â€” The RA of the Management frame corresponds to an individual MAC address. â€” The frame is transmitted by a QMF STA. â€” The transmitting STA has previously received an Extended Capabilities element from the STA corresponding to the RA of the frame being transmitted. â€” The most recently received such Extended Capabilities element indicated that the STA is a QoS STA and has the value of 1 in the QMFActivated subfield. â€” The frame is not a time priority Management frame. A QMF AP shall transmit a Management frame as a GQMF when all three of the following conditions are met: â€” The RA of the Management frame corresponds to a group MAC address. â€” The transmitting STA has received an Extended Capabilities element that has the QMFActivated subfield equal to 1 from every member of the BSS corresponding to the BSSID of the Management frame. â€” The frame is not a time priority Management frame. 1844 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A non-AP QMF STA shall transmit a Management frame as a GQMF when all three of the following conditions are met: â€” The RA of the Management frame corresponds to a group MAC address. â€” The transmitting STA has received an Extended Capabilities element that has the QMFActivated subfield equal to 1 from its associated AP. â€” The frame is not a time priority Management frame. A Management frame shall not be transmitted as an IQMF or GQMF, except as defined above. NOTEâ€”This standard assumes that all APs in an ESS are configured consistently for QMF service when GQMF has been enabled for use by associated non-AP STAs. When the QMFActivated subfield is zero in the most recently received Extended Capabilities element from a destination STA, or when an Extended Capabilities element has not been received from a destination STA, a transmitting QMF STA shall transmit individually addressed Management frames to that destination STA using access category AC_VO. If the QMFActivated subfield in the most recently received Extended Capabilities element from a destination QMF STA is equal to 1, but no QMF Policy element has been received from the destination QMF STA, and, if associated, no QMF Policy element has been received from the QMF AP with which the STA is associated, then a QMF STA shall transmit all IQMFs to the destination QMF STA using the default QMF policy access categories defined in Table 11-17. Otherwise, the QMF STA shall transmit individually addressed Management frames as defined in the QMF policy included in the QMF Policy element accepted from the destination QMF STA. In either case, the transmitted Management frames are IQMFs, and the transmitting QMF STA shall indicate the access category used to transmit the frame in the ACI subfield of the sequence number field. A QMF STA in an unassociated state shall transmit all group-addresses Management frames as non-QMF. An associated QMF STA shall follow the QMF policy dictated by its associated AP for transmitting GQMFs as described in 11.26.2. The specific access category assignments of different Management frames in a nondefault QMF policy are beyond the scope of this document. The transmitting QMF STA shall indicate the access category used to transmit GQMFs in the ACI subfield of the sequence number field. Time-priority Management frames, when not sent as an immediate response, shall be transmitted using AC_VO. 11.26.1.2 Default QMF policy The default QMF policy is as defined in Table 11-17. It defines the access category of each Management frame based on management subtype value, category value, and action value. QMFs not included in this table shall be assigned an access category AC_BE. Table 11-17â€”Default QMF policy Management Frame Category value QMF access Description Subtype value from Action field from Table 9-47 category Table 9-1 (Re)Association Request/ 0000â€“0011 N/A N/A AC_VO Response Probe Request 0100 N/A N/A AC_VO (individually addressed 1845 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 11-17â€”Default QMF policy (continued) Management Frame Category value QMF access Description Subtype value from Action field from Table 9-47 category Table 9-1 Probe Request (group 0100 N/A N/A AC_BE addressed) Probe Response 0101 N/A N/A AC_BE Timing Advertisement 0110 N/A N/A AC_BE Beacon, ATIM, 1000â€“1100 N/A N/A AC_VO Disassociation, Authentication, Deauthentication Spectrum management 1101 0 0â€“3 AC_BE Spectrum managementâ€” 1101 0 4 AC_VO channel switch announcement QoS 1101 1 0â€“3 AC_VO DLS 1101 2 0â€“2 AC_BE Block Ack 1101 3 0â€“2 AC_VO Public 1101 4 0, 1, 3, 5â€“6, AC_BE 8â€“9 Publicâ€”DSE 1101 4 2, 4 AC_VO deenablement, extended channel switch announcement Publicâ€”measurement 1101 4 7 AC_VO pilot Publicâ€”TDLS 1101 4 14 AC_VO Discovery Response Publicâ€”Fine Timing 1101 4 32 AC_VO Measurement Request Publicâ€”Fine Timing 1101 4 33 AC_VO Measurement Radio measurement 1101 5 0â€“5 AC_BE Fast BSS Transition 1101 6 0â€“4 AC_VO HT 1101 7 0â€“3 AC_VO HT 1101, 1110 7 4â€“7 AC_VO SA Query 1101 8 0â€“1 AC_VO Protected Dual of Public 1101 9 1â€“2, 5â€“6, AC_BE Action 8â€“9 Protected Dual of Public 1101 9 4 AC_VO Actionâ€”extended channel switch announcement WNM 1101 10 0â€“24 AC_BE 1846 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 11-17â€”Default QMF policy (continued) Management Frame Category value QMF access Description Subtype value from Action field from Table 9-47 category Table 9-1 Unprotected WNM 1101 11 0â€“1 AC_BE Mesh Actionâ€”HWMP 1101 13 1 AC_VO Mesh Path Selection Mesh Actionâ€” 1011 13 3 AC_VO Congestion Control Mesh Action 1101 13 0, 2, 4â€“10 AC_BE Multihop Action 1101 14 0â€“1 AC_BE Self Protected 1101 15 0â€“5 AC_VI DMG 1101 16 0â€“22 AC_BE Reserved (used by (used 1101 17 All AC_BE by the Wi-Fi Alliance a)) Fast Session Transfer 1101 18 0â€“5 AC_VO Robust AV Streaming 1101 19 0â€“3 AC_BE Unprotected DMG 1101 20 0â€“1 AC_VO VHT 1101, 1110 21 0â€“2 AC_VO Vendor-specific Protected 1101 126 N/A AC_BE Vendor-specific 1101 127 N/A AC_BE aSee http://www.wi-fi.org. 11.26.2 QMF policy advertisement and configuration procedures 11.26.2.1 Overview QMF policies are exchanged and implemented between two QMF STAs. A STAâ€™s QMF policy is advertised and exchanged using the QMF Policy element described in 9.4.2.120. A non-AP QMF STA operating in a BSS shall not transmit a QMF Policy frame to an AP. The access category for a QMF that is transmitted by a non-AP QMF STA to a peer QMF STA shall be determined from the QMF policy received from the peer if a QMF policy has been received from the peer. Otherwise, the default policy shall be used. The access category for a QMF that is transmitted by a QMF AP is determined from the QMF policy configured at that AP. In a BSS or MBSS, the access category for any Management frame may be reconfigured. For example, vendor-specific and vendor-specific protected Management frames might be reconfigured to suit the vendor application requirements. 1847 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.26.2.2 QMF policy change in an infrastructure BSS or in an MBSS A QMF Policy Change frame is transmitted by a QMF STA to request a change to the QMF policy that the requesting QMF STA will use for transmitting Management frames to the peer QMF STA in an infrastruc- ture BSS or in an MBSS. A STA may transmit a QMF Policy Change frame to request a change in the QMF policy for transmitting to a peer STA. A non-AP QMF STA that receives a QMF Policy Change frame may either accept or reject the request. An associated non-AP QMF STA may transmit a QMF Policy Change to the QMF AP in its BSS only if the Extended Capabilities element received from the AP has its QMFReconfigurationActivated subfield equal to 1. If the AP rejects the request, the associated QMF STA shall not request the same policy reconfiguration from the AP during the lifetime of its association. An AP shall respond to a QMF Policy Change frame received from an associated STA by transmitting a QMF Policy frame. If the QMFReconfigurationActivated subfield is zero in the Extended Capabilities element in the Beacon frame, an AP that receives a QMF Policy Change frame from an associated STA shall respond with a QMF Policy frame, with Status Code set to REQUEST_DECLINED. If the QMFReconfigurationActivated subfield is 1 in the Extended Capabilities element in the Beacon frame, an AP that receives a QMF Policy Change frame from an associated STA shall evaluate the QMF Policy included in the frame, and shall respond to the request with the resulting QMF Policy element and Status Code set to SUCCESS if it accepts the policy change, or REQUEST_DECLINED if it rejects the policy change. A QMF AP may transmit a QMF Policy frame with Status Code set to SUCCESS to an associated QMF STA without having first received a QMF Policy Change frame from that STA. If an accept status is received in a QMF Policy frame within dot11QMFPolicyChangeTimeout of having transmitted a QMF Policy Change frame with the same dialog token to the STA that transmitted the QMF Policy frame, then the requesting QMF STA shall transmit any subsequently queued Management frames to the peer QMF STA in accordance with the changes to the QMF policy that were indicated in the QMF Policy Change frame. If a reject status is received in a QMF Policy frame within dot11QMFPolicyChangeTimeout of having transmitted a QMF Policy Change frame with the same dialog token to the STA that transmitted the QMF Policy frame as a response to a QMF Policy Change frame, then the configuration change request is rejected and the requesting QMF STA shall continue to transmit Management frames to the peer QMF STA in accordance with the previously configured QMF policy. The requesting QMF STA shall not transmit a QMF Policy Change frame with a previously rejected QMF policy to a peer QMF STA within dot11QMFPolicyChangeTimeout from the time the requesting STA received the rejection frame. If the requesting STA does not receive a QMF Policy frame in response to a QMF Policy Change frame within dot11QMFPolicyChangeTimeout, then the requesting STA shall continue to transmit frames according to the previously configured QMF policy. If a QMF STA has received an Extended Capabilities element with the QMFReconfigurationActivated subfield equal to 0 or has not received an Extended Capabilities element from a destination QMF STA, the QMF STA shall not transmit a QMF Policy Change frame to the destination QMF STA. A QMF mesh STA or a QMF AP may set dot11QMFReconfigurationActivated to true or false. A non-AP QMF STA in an infrastructure BSS shall set dot11QMFReconfigurationActivated to true and shall set the QMFReconfigurationActivated subfield to 1 in transmitted (re)association requests. A non-AP QMF STA with dot11QMFReconfigurationActivated equal to true shall accept any received QMF Policy frame from its associated AP. A QMF STA with dot11QMFReconfigurationActivated equal to false shall respond with a QMF Policy frame, with the current QMF Policy element and Status Code set to REQUEST_DECLINED. 1848 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The QMFReconfigurationActivated subfield shall be set to one in the Extended Capabilities element when dot11QMFReconfigurationActivated is true. The QMFReconfigurationActivated subfield shall be set to 0 in the Extended Capabilities element when dot11QMFReconfigurationActivated is false. The SME of a peer QMF STA uses the MLME-QMFPOLICY primitives (see 6.3.85.2 to 6.3.85.3) to transmit a QMF Policy frame to a peer STA. The SME of a peer STA uses the MLME- QMFPOLICY.request primitive to transmit a QMF Policy frame to a peer STA. The MLME of a peer QMF STA shall set the dialog token to 0 and set the Status Code to SUCCESS when the QMF Policy frame is transmitted unsolicited to the peer STA. The SME of a peer QMF STA uses the MLME-QMFPOLICYCHANGE primitives (see 6.3.85.4 to 6.3.85.7) to exchange the QMF Policy Change and QMF Policy frames. The SME of a peer STA uses the MLME-QMFPOLICYCHANGE.request primitive to transmit a QMF Policy Change frame to a peer STA. The value of the dialog token in the MLME-QMFPOLICYCHANGE.request primitive shall be set to a value in the range 1 to 255. The SME of the peer STA evaluates the QMF policy and uses the MLME- QMFPOLICYCHANGE.response primitive to transmit a QMF Policy frame to the STA including the result of the QMF policy change. The value of the dialog token in the MLME-QMFPOLICYCHANGE.response primitive shall be set to the value of the dialog token received in the corresponding MLME- QMFPOLICYCHANGE.indication primitive. When the QMF STA SME receives an MLME-QMFPOLICYCHANGE.confirm primitive or MLME- QMFPOLICY.indication primitive with Result Code of SUCCESS, it shall set the new QMF policy using the MLME-QMFPOLICYSET.request primitive. An AP for which dot11AlternateEDCAActivated is true shall not use the alternate video (A_VI) nor alternate voice (A_VO) transmit queues in its QMF policy. 11.26.2.3 QMF policy configuration in an infrastructure BSS A QMF AP shall include the QMF Policy element in Beacon frames that it transmits. Non-AP QMF STAs acquire QMF policy configuration information from QMF Policy elements received in Beacon, Association Response, Reassociation Response, Probe Response, and QMF Policy frames. The interpretation of the QMF Policy element is described in 11.26.3. An associated QMF STA transmitting QMFs shall transmit those frames in accordance with the QMF policy received from its associated AP in the following order of precedence, from highest to lowest: â€” QMF policy defined in an unsolicited QMF Policy frame from the associated QMF AP or the QMF Policy Change frame that resulted in a successful response QMF Policy frame from the associated AP, whichever occurred most recently â€” QMF policy defined in the QMF Policy element received in the successful (Re)Association Response frame All unassociated QMF STAs transmitting Management frames to a QMF AP shall transmit those frames to the AP in accordance with the QMF policy in the most recently received Beacon or Probe Response frame from that AP. If no frame containing a QMF Policy element has been received from the AP prior to the transmission of the Management frame(s), then the Management frame(s) shall be transmitted using the access categories of the default QMF policy defined in Table 11-17. A QMF STA shall transmit all Management frames that are individually addressed to non-QMF STAs using access category AC_VO. 1849 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A QMF AP shall set a QMF policy for the transmission of QMFs to its associated STAs. The QMF policy used by the AP for transmission of QMFs to associated STAs is not required to be the same as the QMF policy it advertises. If the QMFReconfigurationActivated subfield is equal to 1 in the Extended Capabilities element of the Beacon or Probe Response frame transmitted by the AP, an associated QMF STA may use the QMF Policy Change frame to request a change in its existing QMF policy. 11.26.2.4 QMF policy configuration in an IBSS or OCB QMF STAs in an IBSS or OCB shall use the default QMF policy for all individually addressed Management frames transmitted to other QMF STAs in the IBSS or OCB. 11.26.2.5 QMF policy configuration in an MBSS A QMF STA operating in an MBSS shall set the QMFActivated subfield in the Extended Capabilities element to true. The Mesh Beacon frame shall not include a QMF Policy element. The QMF in an MBSS policy shall be set on a per link basis between two QMF STAs. The QMF Policy Change and QMF Policy frames are used by QMF STAs in an MBSS to configure QMF policy. See 11.26.2.2. A QMF STA shall always accept the QMF policy from the QMF Policy frame transmitted by the peer QMF STA and shall transmit all individually addressed Management frames destined to the peer QMF STA using the received QMF policy. A QMF STA may request a change in the QMF policy from a peer QMF STA by transmitting a QMF Policy Change to the peer QMF STA. The peer QMF STA may accept or reject this change request. If the peer QMF STA accepts the change, it shall respond with a QMF Policy frame with Status Code set to SUCCESS and the QMF STA shall transmit IQMFs using the new QMF policy to the peer QMF STA. If the peer QMF STA rejects the change, it shall respond with QMF Policy frame with Status Code set to REQUEST_DECLINED and the QMF STA shall continue transmitting IQMFs according to the previously configured QMF policy. If a QMF STA does not receive a QMF Policy frame from a peer QMF STA, it shall transmit Management frames to that peer STA using the default QMF policy. QMF STAs in an MBSS shall not include policies for group addressed Management frames in the QMF Policy Config Request. 11.26.3 Interpreting QMF access categories The QMF Policy element, as defined in 9.4.2.120, indicates the transmit access categories of different Management frames. A QMF Policy element with Length field of value 1 means that the access category of all Management frames is as defined in the default QMF policy in Table 11-17. When the value of the Individually Addressed subfield is 1, then the QACM applies to IQMFs. When the value of the Group Addressed subfield is 1, then the QACM applies to GQMFs. A STA shall not transmit a QMF Policy element with both the Individually Addressed and Group Addressed subfields set to 0 in any of the included QACM subfields. The QMF Policy element contains zero or more QACM fields. When included in the QMF Policy element, each QACM field indicates the access category of a group of Management frames. Using the description from Table 11-18, access categories for all Management frames belonging to either a given subtype or a 1850 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications given action category may be indicated in a single QACM field. When multiple Action frames of the same Category are to be mapped to the same Access Category, this is indicated by setting multiple bits in the Action Value Bitmap. For example, setting Bit 0 and Bit 1 indicates Event Request/Response frames when the Management Frame Subtype subfield refers to Management frames of subtype Action and the Category Value subfield refers to the WNM category. The QACM field also may be used to indicate the access category of a single management frame subtype. A QMF STA that received a QMF Policy element from its associated QMF AP shall discard any previously received QMF Policy elements. If a Management frame is indicated in multiple QACM fields, the access category of the Management frame is determined by the access category defined in the last QACM field in the QMF Policy that contains the access category assignment of the corresponding Management frame. For example, if an QACM field sets the entire WNM category to access category AC_BE and a later QACM field sets Event Request/Report of WNM category to AC_BK, then all Action frames of WNM category are transmitted using access category AC_BE with the exception of Event Requests/Reports, which are transmitted using access category AC_BK. Table 11-18â€”QMF policy description for valid combination of optional fields in the QACM field QACM field Action frame Action Value Length Description category Bitmap subfield subfield 0 Not included Not included Policy to be applied to all Management frames of the corresponding subtype 1 Included Not included Policy to be applied to all Action frames of corresponding category value 2 Included Included Policy to be applied only to Action frames indicated via the action value bitmap for Management frames of the subtype indicated in the Management Frame Subtype subfield and the category value indicated in the Action Frame Category subfield in the corresponding QACM field 11.27 Robust AV streaming 11.27.1 Robust AV streaming dependencies When dot11RobustAVStreamingImplemented is true, the STA is a robust AV streaming STA. The attribute dot11QosOptionImplemented shall be true in a robust AV streaming STA. 11.27.2 SCS procedures The stream classification service (SCS) is a service that may be provided by an AP to its associated STAs that support SCS. In SCS, the AP classifies incoming unicast MSDUs based upon parameters provided by the non-AP STA. The classification allows the UP, drop eligibility, and EDCA transmit queue to be selected for all MSDUs matching the classification. 1851 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Implementation of SCS is optional for a STA. A STA that implements SCS shall set its dot11SCSImplemented to true. A STA whose dot11SCSActivated value is true shall support stream classification and shall set to 1 the SCS field of the Extended Capabilities elements that it transmits. If dot11SCSActivated is true, dot11SCSImplemented shall be true. A non-AP STA that supports SCS may request use of SCS by sending an SCS Request frame that includes an SCS Descriptor element with the Request Type field set to â€œAddâ€ or â€œChange.â€ The SCS Descriptor List field in the SCS Descriptor element identifies how MSDUs are classified and the priority to assign to MSDUs that match this classification. If the TCLAS Processing element is present in an SCS Descriptor element, the Processing subfield shall have a value of 0 or 1. An AP shall decline any SCS Request frame where a TCLAS Processing element is present and the Processing subfield does not have a value of 0 or 1. Each SCS stream is identified by an SCSID. This SCSID is used by a non-AP STA to request creation, modification, or deletion of an SCS stream. The SCSID is used by an AP to identify an SCS stream in SCS responses. Upon receipt of an SCS Request frame from an associated non-AP STA, the AP shall respond with a corresponding SCS Response frame. A value of â€œSUCCESSâ€ shall be set in the corresponding Status field of the SCS Status duple in the SCS Response frame when the AP accepts the SCS request for the requested SCSID. A value of â€œREQUEST_DECLINED,â€ â€œREQUESTED_TCLAS_NOT_SUPPORTED_BY_AP,â€ or â€œINSUFFICIENT_TCLAS_PROCESSING_RESOURCESâ€ shall be set in the corresponding SCS Status field of the SCS Status duple in the SCS Response frame when the AP denies the SCS request for the requested SCSID. If the AP declines a request to change a previously accepted SCSID, the previously accepted classification for this SCSID continues to operate. If the requested SCS is accepted by the AP, the AP shall process subsequent incoming unicast MSDUs from the DS or WM that match the TCLAS elements and optional TCLAS Processing element classifier specified in the SCS Descriptor element. A match of the classifier is defined as follows: â€” When the Processing subfield of the TCLAS Processing element is 0, the classifier matches all of the parameters in the TCLAS elements in the SCS Descriptor element. â€” When the Processing subfield of the TCLAS Processing element is 1 or the TCLAS Processing element is not present, the classifier matches if the parameters match at least one of the TCLAS elements in the SCS Descriptor element. The processing of matching MSDUs depends upon the access policy assigned to the MSDU: â€” For matching MSDUs that are not part of a TS (as described in 11.4), the User Priority subfield of the Intra-Access Category Priority element is used as the UP of these MSDUs. â€” For matching MSDUs that are part of a TS (as described in 11.4), the TID and UP classification of these MSDUs shall follow the rules specified in 11.4.8. â€” If dot11AlternateEDCAActivated is true, for matching MSDUs that are not part of a TS (as described in 11.4) or for MSDUs that are part of a TS that uses EDCA or HEMM as the access policy, the Alternate Queue subfield of the Intra-Access Category Priority element is used to select whether the primary EDCA transmit queue or alternate EDCA transmit queue is used for these MSDUs. â€” All matching MSDUs have their DEI set using the value from the Drop Eligibility subfield of the Intra-Access Category Priority element in the DEI subfield of the HT Control field, as defined in 9.2.4.6. 1852 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A non-AP STA may request the termination of an accepted SCS stream by sending an SCS Request frame with the Request Type field set to â€œRemoveâ€ and the requested SCSIDs in the SCS Descriptor element. The Length field of the SCS Descriptor element is set to 0; and no Intra-Access Priority, TCLAS, or TCLAS Processing elements shall be included in the SCS Descriptor element. Upon reception of a request to terminate a previously accepted SCS stream, the AP shall cease to apply the classifier related to this SCSID. The AP shall send an SCS Response frame to confirm the termination of the SCS stream identified by the SCSID, by including the SCSID and a value of â€œTerminateâ€ in the Status field of an SCS Status duple in an SCS Response frame and the dialog token in the SCS Response frame set to the value from the SCS Request frame that requested termination. The AP may send an unsolicited SCS Response frame at any time to cancel a granted SCS stream identified by the SCSID, by including the SCSID and a value of â€œTerminateâ€ in the Status field of an SCS Status duple in an SCS Response frame and the dialog token in the SCS Response frame set to 0. 11.28 Procedures to manage OBSS 11.28.1 General QLoad Report elements, HCCA TXOP Update Count elements, HCCA TXOP Advertisement action frames, and HCCA TXOP Response frames are designed to mitigate the effects of OBSSs and provide the means to â€” Advertise QoS load information for channel selection â€” Extend the admission control and scheduled mechanisms to a distributed environment â€” Enable the coordination of scheduled HCCA TXOPs between HCs operating with OBSSs OBSS APs are APs that are using the same primary channel and that are able to receive or obtain frames from each other, including Beacon frames. These frames are received directly or via associated STAs that support the Beacon request capability (as indicated by the Beacon Passive Measurement Capability Enabled bit or the Beacon Active Measurement Capability Enabled bit being set in the RM Enabled Capabilities element in the (Re)Association frame). An AP might scan other channels as part of its channel selection process or might request associated STAs that support the Beacon request capability to perform an off- channel Beacon request measurement, and these procedures might provide QLoad Report elements received from APs operating on other channels. Subclause T.3 provides an example of using QLoad Reports from adjacent channels. NOTE 1 These OBSS procedures might use unauthenticated Beacon frames and Public Action frames. Implementations might choose to use additional heuristics (e.g., a history of collaboration and traffic monitoring) to determine the authenticity of this information. NOTE 2 These OBSS procedures are intended for stationary and portable APs (see 4.2.4). 11.28.2 QLoad Report element 11.28.2.1 Introduction The QLoad Report element is contained in QLoad Report frames or Protected QLoad Report frames that are provided by an AP and, optionally, periodically in the Beacon frame. The QLoad Report frame is transmitted, upon the receipt of a QLoad Request frame by an AP for which dot11QLoadReportActivated is true, to the STA that sent the QLoad Request frame. An AP shall not send a QLoad Request frame or Protected QLoad Request frame to another AP that has QLoad Report field set to 0 in its Extended Capability element. The Protected QLoad Report frame is transmitted, upon the receipt of a Protected QLoad Request frame when dot11ProtectedQLoadReportActivated is true, to the STA that sent the Protected QLoad Request frame. An AP for which dot11ProtectedQLoadReportActivated is false shall discard any received Protected QLoad Request or Protected QLoad Report frames. 1853 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Whenever there is a change in the contents of the QLoad Report element and there is no pending delay period for an unsolicited QLoad Report frame, an unsolicited QLoad Report frame should be transmitted with the RA field set to the broadcast address, after a randomly selected delay between 1 and dot11QLoadReportDelay seconds. After this delay, the AP shall transmit an unsolicited QLoad Report frame that contains the most recently available QLoad information. When dot11QLoadReportActivated is true, the QLoad Report element shall be included in the Beacon frame every dot11QLoadReportIntervalDTIM DTIMs. When dot11QLoadReportActivated is false, the QLoad Report element shall not be included in Beacon frames. 11.28.2.2 Calculating field values The value of the Potential Traffic Self field represents the potential QoS traffic of this BSS; therefore, the value in the Mean subfield shall always be greater than or equal to the value of the Mean subfield in the Allocated Traffic Self field. The AP shall include in the Allocated Traffic Self field all accepted and not deleted TSPECs as they are sent by non-AP STAs. At the deletion of each such TSPEC, the AP shall remove the TSPEC from its Allocated Traffic Self field. The number of active AC_VI and AC_VO streams shall be provided in the Allocated Traffic Self field. For each admitted admission control TSPEC, the AP calculates a medium time, as described in K.2.2. This medium time, however, does not include the medium access overhead that, in turn, is related to the number of streams. This access overhead is further discussed in T.2.7, and a recommendation is given for its value. An example of a method of calculating the values for the Mean and Standard Deviation subfields in the Potential Traffic Self field is given in T.2.3. The Sharing Policy field is used to indicate the currently active policy for sharing the medium with OBSSs. Setting the Sharing Policy field to â€œStaticâ€ indicates that the share of the total available medium time of an AP does not change when the value of the Allocated Traffic Shared field changes. Setting the Sharing Policy field to â€œDynamicâ€ indicates that the share of the total available medium time of an AP might change when the value of the Allocated Traffic Shared field changes. If the Sharing Policy field has the value â€œVendor Specific,â€ then the QLoad Report element shall contain a Vendor Specific subelement. If the value of the Overlap field changes, the share of the total available medium time of an AP might change for both static and dynamic sharing policies. The value of the Potential Traffic Self field represents the potential QoS traffic of this AP and, therefore, shall always be greater than or equal to the values represented by the Allocated Traffic Self field. The Allocated Traffic Self field contains the mean and standard deviation values of the total EDCA admission control and HCCA traffic that the AP has allocated at any one time and contains the number of AC_VI and AC_VO EDCA admission control streams. As each stream is added or deleted, the AP shall calculate the new value of the Allocated Traffic Self field. A recommended method for calculating the Allocated Traffic Self field mean and standard deviation values is given in T.2.4. The Allocated Traffic Shared field is calculated from the Allocated Traffic Self field values for all APs that overlap with the AP performing the calculation, including the Allocated Traffic Self field value of the AP performing the calculation. A recommended method for summing the Allocated Traffic Self field values is given in T.2.4. The EDCA Access Factor is the total traffic bandwidth requirement for all of the OBSSs expressed as a fraction that may be greater than 1. An implementation might calculate the EDCA Access Factor from the summation of the Potential Traffic Self field values of all of the APs that are overlapping, as follows: 1854 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications a) Sum all of the Potential Traffic Self field values for all OBSSs, including self, in order to calculate the peak traffic requirement in multiples of 32 Âµs per second. As the Potential Traffic Self field value is expressed in terms of mean and standard deviations, it is possible to sum the Potential Traffic Self field values as a composite stream. A suggested method for this summation is given in T.2.3. b) Sum all of the HCCA Peak field values from all OBSSs, including self, in order to calculate the peak HCCA traffic requirement, in multiples of 32 Âµs per second. c) Subtract the value derived in step b) from the value derived in step a). This value is the EDCA traffic. d) Sum the AC_VO and AC_VI streams reported in its own QLoad report and all of the QLoad reports of OBSSs. Based upon the number of EDCA streams, an EDCA Overhead Factor can be estimated to account for the medium access time requirements. EDCA Overhead Factor is further discussed in T.2.3, and a recommendation is given for its value. e) Multiply together the EDCA traffic from step c) and the EDCA Overhead Factor to obtain a value that represents the total peak bandwidth requirement for the OBSSs. This value is in multiples of 32 Âµs per second. f) Convert the total peak bandwidth requirement to a fraction that is rounded down to a multiple of 1/64 (8 bits). This value is the EDCA Access Factor. An example for this conversion is given in T.2.6. The HCCA Peak field value is the sum of the all of the medium times of active TS that use the HCCA or HEMM access policy over a 1 s period for all of the HCCA TSPECs included in the QLoad field. The TXOP time, scheduled by the HC, multiplied by the reciprocal of its SI, is termed the HCCA medium time. The HCCA Peak field value is the summation of the HCCA medium times that the HC has scheduled, in multiples of 32 Âµs. The HCCA Access Factor is the total HCCA TXOP medium time requirement for all of the OBSSs expressed as a fraction that may be greater than 1. An implementation might calculate the HCCA Access Factor from the summation of the HCCA Peak field values of all of the APs that in an OBSS, by summation of all of the HCCA Peak field values for all APs in OBSSs and converting this summation to a fraction that is rounded down to 1/64 (8 bits). An example for this conversion is given in T.2.8. 11.28.2.3 Requesting QLoad Reports using radio measurement requests If an AP has associated STAs that support passive or active beacon measurement (as indicated by the Beacon Passive Measurement Capability Enabled bit or the Beacon Active Measurement Capability Enabled bit being set in the RM Enabled Capabilities element), it may use the neighbor report capability of these associated STAs to attempt to retrieve QLoad Report elements from APs with which the AP is unable to exchange frames directly. The AP sends a Radio Measurement Request frame that contains a Measurement Request element to an associated STA that supports neighbor reporting and beacon reporting. This Measurement Request element has the Measurement Type field set to â€œBeacon requestâ€ (as defined in Table 9-82), and the BSSID field of the Measurement Request field of the Beacon request frame (as defined in Figure 9-156) is set to the wildcard BSSID. There shall be a Request subelement in the Measurement Request field of the Beacon request frame that contains the Element ID of the QLoad Report element (as defined in Table 9-77) and may contain other element IDs. The SSID subelement shall not be included in the Request subelement of the Measurement Request field of the Beacon request. Depending upon the signaled enabled radio measurement capabilities of the associated STA, the AP may use either the passive or active measurement mode. The Channel Number field should be set to the primary 1855 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications channel number that is currently being used by the AP, but may be set to other values if off-channel beacon measurement is supported by the STA to which the measurement request is to be sent. If the measurement request is accepted, the requested STA performs the measurement request (as described in 11.11). The subsequent Radio Measurement Report frame contains beacon reports for successful measurements. These beacon reports might contain QLoad Report elements inside a Reported Frame Body subelement, if the reporting STA received QLoad Report elements from the Beacon or Probe Response frames that it received from neighboring APs. The contents of these QLoad Report elements can then be used in calculating Allocated Traffic Shared, EDCA Access Factor, and HCCA Access Factor field values as described in 11.28.2.2. 11.28.3 HCCA TXOP negotiation The procedures described in this subclause allow HCCA APs to cooperatively create new HCCA schedules that do not collide. When sharing with at least one other HCCA AP, each sharing AP for which dot11RobustAVStreamingImplemented is true shall set its dot11HCCWmax to a value of at least 3. HCCA APs that are able to directly exchange frames without the use of a third-party STA and signal support for unprotected or protected TXOP negotiation (as indicated by the Unprotected TXOP Negotiation or Protected TXOP Negotiation field equal to 1 in the Extended Capabilities element in Beacon frames) coordinate their TXOP schedules using HCCA TXOP Advertisement and HCCA TXOP Response frames. In this subclause, an HCCA AP in an OBSS that is able to directly exchange frames without the use of a third-party STA is referred to as a collaboration candidate. The HCCA TXOP Update Count element is included in the Beacon frame to indicate that an HCCA TXOP schedule has changed. The Update Count field of the HCCA TXOP Update Count element is incremented (modulo 256) each time a TS with an access policy of HCCA or HEMM is created or deleted. An HCCA AP for which dot11PublicHCCATXOPNegotiationActivated is true or dot11ProtectedHCCATXOPNegotiationActivated is true shall advertise the Duration, Service Interval, and Start Time subfields for each HCCA TXOP reservation in a TXOP Reservation field as described in 9.4.1.44. An HCCA AP for which dot11PublicTXOPNegotiationActivated is true or dot11ProtectedTXOPNegotiationActivated is true shall be able to maintain one or more dot11APCEntry(s) for each collaboration candidate in the dot11APCTable. These fields indicate the schedules that the AP should try to avoid using when creating schedules for new TS requests. Before accepting a TSPEC request that has the Access Policy subfield of the TSPEC element equal to â€œHCCAâ€ or â€œHEMM,â€ an HC for which dot11PublicTXOPNegotiationActivated is true or dot11ProtectedTXOPNegotiationActivated is true should examine all dot11APCEntry(s) that are present in the dot11APCTable. When an AP with dot11PublicHCCATXOPNegotiationActivated true or with dot11ProtectedHCCATXOPNegotiationActivated true receives a TSPEC request that has the Access Policy subfield of the TSPEC element equal to â€œHCCAâ€ or â€œHEMM,â€ it shall send an HCCA TXOP advertisement to each collaboration candidate. These HCCA TXOP advertisements shall have the TXOP Reservation field set to the TXOP that the AP is attempting to schedule. An AP with dot11ProtectedTXOPNegotiationActivated true shall send the HCCA TXOP advertisement using a Protected HCCA TXOP Advertisement frame to each collaboration candidate that indicates support for protected HCCA TXOP negotiation (as indicated by the Protected TXOP Negotiation field equal to 1 in the Extended Capabilities element in Beacon frames from the collaboration candidate). 1856 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications An AP with dot11PublicTXOPNegotiationActivated true shall send the HCCA TXOP advertisement using an HCCA TXOP Advertisement frame to each collaboration candidate that indicates support for unprotected HCCA TXOP negotiation (as indicated by the Unprotected TXOP Negotiation field equal to 1 in the Extended Capabilities element in Beacon frames from the collaboration candidate) unless the HCCA TXOP advertisement has already been transmitted to this collaboration candidate using a Protected HCCA TXOP Advertisement frame. NOTE When peer APs have both unprotected and protected TXOP negotiation activated, protected TXOP negotiation is used. The AP shall not send an ADDTS Response frame to the requesting STA until one of the following conditions occurs: a) The AP has received an HCCA TXOP Response frame, with the Status field equal to â€œSUCCESS,â€ from all of the APs to which HCCA TXOP advertisements were sent. b) At least two Beacon frames have been received from all of the APs to which HCCA TXOP advertisements were sent. c) A Beacon frame containing the HCCA TXOP Update Count element is received from all of the APs to which HCCA TXOP advertisements were sent. d) A period of three dot11BeaconPeriod TU has elapsed. If an AP receives another TSPEC request while waiting for one of the above conditions to occur, it shall delay processing this additional TSPEC request until one of the above conditions occurs. An AP with dot11PublicTXOPNegotiationActivated false shall discard any received HCCA TXOP Advertisement frames. An AP with dot11ProtectedTXOPNegotiationActivated true shall discard any received unprotected HCCA TXOP Advertisement frames from a peer AP with which it has an active security association. Upon reception of an unprotected HCCA TXOP Advertisement frame, an AP with dot11PublicTXOPNegotiationActivated true shall discard all dot11APCEntry(s) from the dot11APCTable that have dot11APCEntryMACAddress equal to the MAC address of the AP that sent the HCCA TXOP Advertisement frame and shall prepare a response using the procedures below. An AP with dot11ProtectedTXOPNegotiationActivated false shall discard any received Protected HCCA TXOP Advertisement frames. An AP with dot11ProtectedTXOPNegotiationActivated true that does not have an active security association with a peer AP that indicates support for protected HCCA TXOP negotiation shall use the AP PeerKey protocol (as defined in 12.11.2) and authenticated mesh peering exchange (AMPE) (as defined in 13.5) to negotiate security parameters and create a new SMKSA and STKSA to secure the Protected HCCA TXOP Advertisement frames. The use of AMPE proves possession of the PMK (generated using the procedures described in 12.11.2) and implicitly the private key that corresponds to the peerâ€™s public key. Upon reception of a valid Protected HCCA TXOP Advertisement frame, an AP with dot11ProtectedTXOPNegotiationActivated true shall discard all dot11APCEntry(s) from the dot11APCTable that have dot11APCEntryMACAddress equal to the MAC address of the AP that sent the Protected HCCA TXOP Advertisement frame and shall prepare a response using the procedures below. If the (Protected) HCCA TXOP Advertisement frame has not been discarded due to the procedures above, the AP shall create a dot11APCEntry in the dot11APCTable for each TXOP reservation in the Active TXOP Reservations field of the (Protected) HCCA TXOP Advertisement frame. 1857 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If the (Protected) HCCA TXOP Advertisement frame has not been discarded due to the procedures above, the AP shall inspect its HCCA schedule to check whether the TXOP reservations number given in the Pending TXOP Reservations field of the HCCA TXOP Advertisement frame is in conflict with an existing accepted HCCA TXOP, allocated by itself. If there is no conflict, the AP shall send an HCCA TXOP Response frame with the Status field set to â€œSUCCESSâ€ and create a dot11APCEntry for each TXOP reservation in the Pending TXOP Reservations field in the HCCA TXOP Advertisement frame. If the HCCA advertisement was sent using an unprotected Public Action frame, the HCCA TXOP response shall be sent using an unprotected Public Action frame. If the HCCA advertisement was sent using a Protected HCCA TXOP Advertisement frame, the HCCA TXOP response shall be sent using a Protected HCCA TXOP Response frame. If the AP detects that the TXOP given in the (Protected) HCCA TXOP Advertisement frame is in conflict with an existing accepted HCCA TXOP and this AP is not itself currently processing an ADDTS request, it shall send a (Protected) HCCA TXOP Response frame with the Status field set to â€œTS_SCHEDULE_CONFLICT,â€ the Alternate Schedule field set to a period of time that does not conflict with any currently accepted HCCA TXOPs, and the Avoidance Request field absent. The Duration subfield of the Alternate Schedule field should be greater than or equal to the Duration subfield of the Schedule field in the (Protected) HCCA TXOP Advertisement frame. The Duration subfield of the Alternate Schedule field may be less than the Duration subfield of the Schedule field in the (Protected) HCCA TXOP Advertisement frame when there is an insufficient period of time that does not conflict with currently accepted HCCA TXOPs. If the AP detects that the TXOP given in the (Protected) HCCA TXOP Advertisement frame is in conflict with an in-progress ADDTS request for an HCCA TXOP for which HCCA TXOP Response frames have not been received, it shall send a (Protected) HCCA TXOP Response frame with the Status field set to â€œTS_SCHEDULE_CONFLICTâ€ and the Alternate Schedule and Avoidance Request fields set according to the following rules: â€” If MIX(MACr) < MIX(MACi), the Alternate Schedule field is set to a value that does not conflict with any accepted HCCA TXOPs and also does not conflict with the TXOP of the in-progress ADDTS request. The Avoidance Request field is set to the TXOP of the in-progress ADDTS request. â€” If MIX(MACr) > MIX(MACi), the Alternate Schedule field is set to the value from the TXOP Reservation field from the HCCA TXOP Advertisement frame. The Avoidance Request field is set to a time period that does not conflict with any accepted HCCA TXOPs nor the TXOP in the Alternate Schedule field and has sufficient duration and service interval to meet the requirements of the in-progress ADDTS request. where MACr is the MAC address of the AP that received the HCCA TXOP Advertisement frame MACi is the MAC address of the AP that sent the HCCA TXOP Advertisement frame The MIX function takes the 6 octets of a MAC address and computes a new 6 octet value: MIX(MAC) = MAC[4] || MAC[5] || MAC[0] || MAC[1] || MAC[2] || MAC[3] For the purpose of the comparisons shown above, the resulting 6 octet value is converted to a positive integer treating the first octet as the most significant octet of the integer. 1858 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 11-19 provides a summary of the values used in an HCCA TXOP Response frame. Table 11-19â€”Contents of HCCA TXOP Response frame Alternate Schedule Avoidance Request Case Status code field field No conflict with SUCCESS Not present Not Present existing or in-progress schedules Conflicts with existing TS_SCHEDULE_ Period of time that does not Not Present schedule; no ADDTS CONFLICT conflict with any currently request in progress accepted HCCA TXOPs Conflict with TS_SCHEDULE_ Period of time that does not Schedule of in-progress in-progress schedules, CONFLICT conflict with any currently ADDTS request MIX(MACr) < accepted HCCA TXOPs nor MIX(MACi) the in-progress ADDTS request Conflict with TS_SCHEDULE_ Same schedule that was in Period of time that does not in-progress schedules, CONFLICT the HCCA TXOP conflict with any currently MIX(MACr) > Advertisement frame accepted HCCA TXOPs nor MIX(MACi) the period given in the Alternate Schedule field The AP shall keep a record of the TXOP proposed in the Alternate Schedule field in a TXOP avoidance record and should avoid scheduling any new HCCA TXOPs in this proposed period until any of the following conditions occurs: â€” A period of dot11HCCATXOPBeaconTimeout multiplied by dot11BeaconPeriod TUs has elapsed. â€” The AP with dot11PublicTXOPNegotiationActivated true receives an unprotected HCCA TXOP Advertisement frame from the AP to which the unprotected HCCA TXOP Response frame was sent. â€” The AP with dot11ProtectedTXOPNegotiationActivated true receives a Protected HCCA TXOP Advertisement frame from the AP to which the Protected HCCA TXOP Response frame was sent. If an AP with dot11PublicTXOPNegotiationActivated true receives an unprotected HCCA TXOP Response frame with the Status field equal to â€œTS_SCHEDULE_CONFLICT,â€ the AP should create a new schedule for the TSPEC request using the suggestion provided in the HCCA TXOP Response frame. If an AP with dot11ProtectedTXOPNegotiationActivated true receives a Protected HCCA TXOP Response frame with the Status field equal to â€œTS_SCHEDULE_CONFLICT,â€ the AP should create a new schedule for the TSPEC request using the suggestion provided in the Protected HCCA TXOP Response frame. If an AP creates a new schedule in response to a (Protected) HCCA TXOP Response frame, it shall send a new HCCA TXOP advertisement to each collaboration candidate, using the procedures previously defined in this subclause. After one or more HCCA TXOP Advertisement frame transmissions that cause the reception of an HCCA TXOP Response frame with the Status field equal to â€œTS_SCHEDULE_CONFLICT,â€ the AP may terminate the HCCA TXOP advertisement procedure and respond to the ADDTS Request frame with a status code not equal to SUCCESS (decline the ADDTS Request) or a status code equal to SUCCESS (accept the ADDTS request regardless of potential HCCA TXOP conflicts). 1859 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.28.4 HCCA AP timing synchronization for HCCA TXOP advertisement 11.28.4.1 General HCCA APs in OBSSs for which dot11PublicHCCATXOPNegotiationActivated is true or dot11ProtectedHCCATXOPNegotiationActivated is true synchronize their TSF timing so that the HCCA TXOP advertisement scheme does not suffer from time differences between the clocks of the overlapping APs. In order to use HCCA TXOP advertisement, the AP maintains synchronization with its APs in OBSSs. HCCA APs that use HCCA TXOP advertisement shall use a DTIM interval with a duration of 2n Ã— 100 TU where n a non-negative integer less than or equal to 5. NOTEâ€”The DTIM interval of the form 2n Ã— 100 TU has been chosen to facilitate the verification that HCCA TXOP reservations do not overlap. The restriction that n be less than or equal to 5 has been chosen so that the range of the HCCA TXOP start time in the reservation (see 9.4.1.44) is compatible with the maximal DTIM interval length. 11.28.4.2 Timing offset An HCCA AP with dot11PublicHCCATXOPNegotiationActivated true or dot11ProtectedHCCATXOPNegotiationActivated true shall update the timing offset value based on time stamps from the received Beacon frames from HCCA APs that have an entry in the dot11APCTable. The timing offset value is calculated using Equation (11-7). Toffset = TT â€“ TR (11-7) where Toffset is the timing offset value TT is the value in the Timestamp field in the received Beacon frame from the overlapping HCCA AP TR is the Beacon frame reception time measured using the HCCA APâ€™s TSF timer The offset value is represented as 2s complement. The unit of the offset value is microseconds. The HCCA AP shall keep the Toffset value calculated from the latest Beacon frame received from each AP in an OBSS. 11.28.4.3 Clock drift adjustment When dot11RobustAVStreamingImplemented is true and dot11PublicHCCATXOPNegotiationActivated is true, the HCCA AP shall examine the reception time of the Beacon frames from overlapping HCCA APs with which it maintains synchronization and adjust its TSF timer to compensate the relative timing error among overlapping HCCA APs caused by the clock drift. The HCCA AP adjusts its TSF so that its TSF counting frequency is aligned to the AP with the lowest TSF counting frequency. The HCCA AP shall operate the following clock drift compensation procedure: a) If the HCCA AP does not have a valid Toffset value obtained from the previous Beacon frame reception from a particular overlapping HCCA AP, it shall not operate the clock drift compensation for that AP. b) When the HCCA AP receives a Beacon frame from one of the overlapping HCCA APs with which it maintains synchronization, the HCCA AP shall calculate the clock drift amount TClockDrift by comparing the Toffset obtained previously for this overlapping HCCA AP and the Toffset obtained from the Beacon frame reception. See Equation (11-8). TClockDrift = Toffset,1 â€“ Toffset,0 (11-8) 1860 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications where TClockDrift is the clock drift amount represented as 2s complement, in microseconds Toffset,1 is the Toffset obtained from the previous reception Toffset,0 is the Toffset obtained from the current frame reception c) The HCCA AP shall calculate the TClockDrift value for all overlapping HCCA APs with which it maintains synchronization and select the largest TClockDrift value. If the largest TClockDrift is greater than zero, it shall suspend its TSF timer for the duration of the largest TClockDrift. The HCCA AP shall suspend its TSF timer frequently enough that the delay during a single beacon period does not exceed 0.08% of its beacon interval. NOTEâ€”This clock drift compensation procedure is not intended to maintain a strict synchronization. It aims to stop TBTT drifting away among overlapping HCCA APs to allow some jitter of TSF timer. 11.29 DMG beamformed link and BSS maintenance 11.29.1 Beamformed link maintenance A pair of DMG STAs that have established a beamformed link can maintain this link. This subclause describes procedures that allow a pair of DMG STAs to maintain a beamformed link that was established between them. A beamformed link is established as a result of the most recent success of the procedures specified in 10.38.2 if the STAs completed the SLS phase or as a result of the most recent success of the procedures specified in 10.38.6.4 if the STAs completed the BRP phase. A DMG STA shall negotiate the value of dot11BeamLinkMaintenanceTime using the procedures specified in 10.38.6.2 or may leave it undefined as specified in 9.5.6. If the dot11BeamLinkMaintenanceTime has been defined as described in 9.5.6, a DMG STA shall implement a beam link maintenance timer to control each beamformed link. The STA shall keep one beam link maintenance timer per beamformed link. After it is set, the beam link maintenance timer shall count down. The timer shall be stopped when it reaches the value zero. The beam link maintenance timer of a beamformed link shall be halted during the following periods of time: â€” BTI and A-BFT of a beacon interval â€” SPs and CBAPs in which the STA does not participate â€” When any of the STAs involved in the beamformed link is in doze state The beam link maintenance timer shall be set to dot11BeamLinkMaintenanceTime when the source DMG STA and destination DMG STA successfully complete the BRP if the beam refinement phase is performed (10.36.3) or the source DMG STA and destination DMG STA successfully complete the SLS (10.38.2) if the beam refinement phase is skipped as defined in 10.36.3. A DMG AP or PCP shall set the beam link maintenance timer to dot11BeamLinkMaintenanceTime when it receives a response from the non-AP and non-PCP DMG STA during the ATI or when it receives an SPR frame as a response to a Poll frame, if these frames are received using the beamformed link established with the non-AP and non-PCP DMG STA. The non-AP and non-PCP DMG STA shall set the beam link maintenance timer to the dot11BeamLinkMaintenanceTime when it receives a request from the DMG AP or PCP during the ATI or when it receives a Poll or a Grant frame, if these frames are received using the beamformed link established with the DMG AP or PCP. 1861 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The initiator DMG STA shall set the beam link maintenance timer to the dot11BeamLinkMaintenanceTime when an immediate response or acknowledgment (Ack, BlockAck, DMG CTS, DMG DTS) has been received from the recipient DMG STA of the beamformed link. The recipient DMG STA shall set the beam link maintenance timer to the dot11BeamLinkMaintenanceTime after the transmission of the immediate response or acknowledgment (Ack, BlockAck, DMG CTS, DMG DTS) has been completed to the initiator DMG STA of the beamformed link. To prevent expiration of the beam link maintenance timer when a DMG STA does not have MSDUs to send, the STA shall transmit QoS Null frames to maintain a beamformed link. Following the expiration of the beamlink maintenance time (specified by the current value of dot11BeamLinkMaintenanceTime), the destination DMG STA of the SP shall configure its receive antenna to a quasi-omni antenna pattern for the remainder of the SP and during any SP following the expiration of the beamlink maintenance time. Any time after dot11BeamLinkMaintenanceTime has elapsed, the source DMG STA of the SP may initiate an ISS to restore the beamformed link with the destination DMG STA of the SP following the rules defined in 10.38.2. The source DMG STA may initiate the ISS before expiration of dot11BeamLinkMaintenanceTime. The responder DMG STA of the beamformed link in the CBAP shall configure its receive antenna to a quasi-omni antenna pattern following the expiration of dot11BeamLinkMaintenanceTime except when it is involved in a frame exchange with another STA. Any time after dot11BeamLinkMaintenanceTime has elapsed, the initiator DMG STA of the beamformed link in the CBAP may initiate an ISS to restore the beamformed link with the responder STA following the rules defined in 10.38.2. The initiator STA may initiate the ISS before expiration of dot11BeamLinkMaintenanceTime. If a DMG STA detects degradation in the link quality between itself and another STA, the STA can use beam tracking or beam refinement to improve the link quality. The STA can request the AP or PCP to schedule an SP to perform BF with the other STA or use a CBAP to perform BF. The STA can use the A- BFT to perform BF if the other STA is its AP or PCP. A DMG AP or PCP can perform BF with a non-AP and non-PCP STA during a CBAP or by scheduling an SP between the AP or PCP and the non-AP and non- PCP STA through an Extended Schedule element transmitted in a DMG Beacon or Announce frame. If the link quality between a DMG AP or PCP and a non-AP and non-PCP DMG STA degrades, but the STA can still receive DMG Beacon frames with the Next A-BFT field equal to 0, the STA should improve the link quality by performing RSS during the A-BFT period as described in 10.38.5. A DMG STA may use the value of the parameter LAST_RSSI in the RXVECTOR of a received frame to decide to initiate beamforming with a peer STA if the value of the LAST_RSSI parameter is different from zero (10.3.2.3.3). Figure 11-42 illustrates the operation of the beam link maintenance timer for an example involving STA-A and STA-B. In beacon interval n, STA-A and STA-B successfully perform beamforming and set up the beam link maintenance timer. In beacon interval n+1, the STAs have two SPs established between them. The beam link maintenance timer is halted and released according to the rules described above. Once the timer beam link maintenance timer expires, the STAs redo beamforming. 1862 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications beacon interval n beacon interval n+1 STA-A & STA-B SP (STA-A, BTI A-BFT SP (STA-A, STA-B) beamforming STA-B) Beam Link Last successful Ack/BA, Maintenance Timer beamformed link broken Ack/BA transmitted and 0 received Time Setup and halt Beam Link Release Beam Link Maintenance Timer Maintenance Timer Setup and Release Beam Link Halt Beam Link Maintenance Timer Maintenance Timer Release Beam Link Maintenance Timer Beam Link Maintenance Timer expires. Re-beamforming starts. Figure 11-42â€”Example of beamformed link maintenance 11.29.2 PCP Handover 11.29.2.1 General A STA is PCP handover capable if the PCP Handover field in the STAâ€™s DMG Capabilities element (9.4.2.128) is 1. The STA is PCP handover incapable otherwise. The PCP handover process allows the information pertinent to the operation of the PBSS to be distributed to suitable PCP handover capable STA(s) and for a PCP handover capable STA to take over the PCP responsibilities from the PCP explicitly or implicitly. The information pertinent to the operation of a PBSS includes STA information and pseudo-static scheduling information. The STA information comprises the STAâ€™s AID, MAC address, and DMG Capabilities element. The PCP may relay the information to all STAs in the PBSS by using the Information Response frame. The pseudo-static scheduling information comprises pseudo-static SP and CBAP allocations carried in the Extended Schedule element (9.4.2.132). A PCP handover capable STA supports two types of PCP Handover, explicit and implicit. In explicit PCP handover, the PCP explicitly selects and schedules the transfer of PCP responsibilities to another PCP handover capable STA as described in 11.29.2.2. In implicit PCP handover the PCP distributes the Next PCP List element (9.4.2.140) in its DMG Beacon or Announce frames and maintains the content of the NextPCP List element to facilitate the implicit handover process described in 11.29.2.3. The PCP may determine the priority of next PCPs and update the next PCP list based on information contained within a STAâ€™s DMG Capabilities element. 1863 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If there is at least one PCP handover capable STA in the PBSS, the NextPCP List element contains an ordered list of one or more PCP handover capable STAs that can take over the role of the PCP during implicit handover. The ordering of STAs in the NextPCP List is specified in decreasing priority order and the criteria for updating the NextPCP List are implementation specific. The PCP shall increment the Token field of the NextPCP List by 1 every time the list is changed. If there are no PCP handover capable STAs in the PBSS, the length of the NextPCP List element is 0, and implicit PCP handover cannot be performed. When a PCP handover capable STA takes over the PCP responsibilities of a PBSS, the pseudo-static scheduling information shall remain unchanged. Any outstanding request for resource allocation is lost and STAs that have outstanding requests for allocation may re-request the resource allocation. In explicit PCP handover, the PCP shall use the value of the PCP factor when selecting the candidate PCP (see 11.1.4.3.6). Following a PCP handover, a non-PCP STA shall attempt to transmit a frame to the new PCP within dot11MaxLostBeacons beacon intervals. If the new PCP does not receive at least one frame from an associated non-PCP STA for dot11MaxLostBeacons beacon intervals following a PCP handover, it should disassociate the STA from the PBSS. 11.29.2.2 Explicit handover procedure The PCP may transmit a Handover Request frame to a non-PCP STA that is handover capable. Upon receiving a Handover Request, a non-PCP STA becomes the candidate PCP. If the handover request is accepted, the candidate PCP shall transmit a Handover Response frame to the PCP with the Handover Result field set to 0. If the handover request is rejected, the candidate PCP shall transmit a Handover Response frame to the PCP with the Handover Result field set to 1, 2, or 3 and cease to be the candidate PCP. A non-PCP STA that is handover capable may transmit a Handover Request frame to the PCP of the PBSS if the PCP is handover capable. Upon transmission of the Handover Request frame, the non-PCP STA becomes the candidate PCP. If the handover request is accepted, the PCP shall transmit a Handover Response frame to the candidate PCP with the Handover Result field set to 0. If the handover request is rejected, the PCP shall transmit a Handover Response frame to the candidate PCP with the Handover Result field set to 1, 2, or 3, and the candidate PCP shall cease to be a candidate PCP. Following the transmission or reception of a successful Handover Response frame, a candidate PCP should request STA information and pseudo-static scheduling information from the PCP using an Information Request frame within the next dot11NbrOfChangeBeacons beacon intervals. The candidate PCP should also request SPs to perform beamforming and, if appropriate, establish a security association with other associated STAs prior to the completion of PCP handover. Following the reception or transmission of a Handover Response frame, the PCP shall transmit a PCP Handover element within every DMG Beacon or Announce frame for each of the next dot11NbrOfChangeBeacons beacon intervals with the Old BSSID field set to the BSSID of the PBSS, the New PCP Address field set to the MAC address of the candidate PCP, and the Remaining BIs field set to the number of beacon intervals remaining until the candidate PCP takes over the role of PCP for the PBSS. The initial value of the Remaining BIs field shall be equal to the Remaining BI field value last transmitted by the PCP in a Handover Request frame to the candidate PCP or equal to the Remaining BI field value last received by the PCP in a Handover Request frame from the candidate PCP, whichever is later. A non-PCP STA receiving a DMG Beacon or Announce frame containing the PCP Handover element shall set the STAâ€™s local countdown counter to the value of the Remaining BIs field contained in the PCP Handover element. The STA shall then decrease the local countdown counter by one at each TBTT, and shall use the candidate PCPâ€™s address contained in the New PCP Address field within the PCP Handover element as the new beacon filter address once the STAâ€™s local countdown reaches zero. When the countdown timer equals zero, the candidate PCP shall assume the role of PCP. 1864 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.29.2.3 Implicit handover procedure Upon receiving the NextPCP List element, a PCP handover capable STA that finds its AID as the AID entry i in the NextPCP List element received from the PCP becomes the implicit candidate PCP i. Upon detecting a Token value contained in the NextPCP List element that is different from the value of the last Token received from the PCP, each implicit candidate PCP should request STA information and pseudo-static scheduling information from the PCP by transmitting an Information Request frame addressed to the PCP (11.30.1). The implicit handover process is triggered at the implicit candidate PCP i when the implicit candidate PCP i fails to receive a DMG Beacon or Announce frames from the PCP for (i Ã— dot11ImplicitHandoverLostBeacons) beacon intervals. When triggered, the implicit candidate PCP i shall send at least one DMG Beacon frame during each of the next dot11MaxLostBeacons BTIs if the following conditions are met: â€” No DMG Beacon or Announce frames are received from the PCP. â€” No DMG Beacon frame carrying a PCP Handover element with the value of the Old BSSID field equal to the BSSID of the PBSS is received from an implicit candidate PCP with a smaller index on the NextPCP List. Each DMG Beacon frame sent by the implicit candidate PCP i shall contain a PCP Handover element with the Old BSSID field set to the BSSID of the PBSS from which control is being taken, i.e., the previous PBSS, the New PCP Address field set to its MAC address, and the Remaining BIs field initially set to dot11MaxLostBeacons and decremented by 1 at each TBTT. A member non-PCP STA of the PBSS, after failing to receive a DMG Beacon or Announce frame for dot11MaxLostBeacons beacon intervals, should associate with the new PCP sending a DMG Beacon frame containing the PCP Handover element with Old BSSID field equal to the BSSID of the previous PBSS and the smallest Remaining BIs field value. The implicit candidate PCP that successfully transmits a DMG Beacon frame with the Remaining BIs field within the PCP Handover element equal to 0 completes the implicit handover by scheduling, if appropriate, pseudo-static SPs between its member STAs following the pseudo-static scheduling information it obtained from the previous PBSS. To avoid disruptions to pseudo-static SPs due to implicit handover, the value of dot11ImplicitHandoverLostBeacons should be lower than dot11MaxLostBeacons. 11.30 DMG BSS peer and service discovery 11.30.1 Information Request and Response A STA may request information about either a single STA in the BSS or about all of the STAs in the BSS by sending an Information Request frame (9.6.20.4). If the STA is requesting information about only a single STA in the BSS, it shall set the Subject Address field in the Information Request frame to the MAC address of that STA. If the STA is requesting information about all of the STAs in the Infrastructure BSS and PBSS, it shall set the Subject Address field in the Information Request frame to the broadcast address and shall transmit the Information Request frame to the AP and PCP. A STA may transmit an Information Request frame with the Length field of the Request element set to 0 and with no Extended Request element present to another STA in the BSS to determine if the destination DMG STA is still present in the PBSS and is within range of the sending STA. A STA may transmit an Information Request frame including its STA Capability element and other elements. A non-PCP and non-AP STA shall not include in the Information Request frame the capability information corresponding to another STA. 1865 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The STA may transmit an Information Response frame (9.6.20.4) either unsolicited or as a response to an Information Request frame. If a STA is providing information about a single STA in the BSS, it shall set the Subject Address field in the Information Response frame to the MAC address of that STA. If a STA is providing information about all of the STAs in the PBSS, it shall set the Subject Address field in the Information Response frame to the broadcast address. A STA processes a received Information Request frame as follows: â€” Each element that is listed in a Request element or Extended Request element and that is supported by the STA shall be included in the Information Response frame. An element that is listed in a Request element or Extended Request element and that is not supported by the STA shall not be included. â€” If dot11RadioMeasurementActivated is true and the RCPI element was requested, an RCPI element containing the RCPI of the Probe Request frame shall be included. If no measurement result is available, the RCPI value shall be set to indicate â€œMeasurement not availableâ€ (see Table 9-154). â€” If dot11RadioMeasurementActivated is true and the RSNI element was requested, an RSNI element containing the RSNI of the Probe Request frame shall be included. If no measurement result is available, the RSNI value shall be set to indicate that a measurement is not available (see 9.4.2.41). A STA shall send an Information Response frame with no requested or provided elements in response to a received Information Request frame that solicits information about a single target STA, as identified by the Subject Address field within the Information Request frame, if â€” The target STA is not a member of the PBSS and the STA sending the Information Response frame is the PCP of the PBSS, or AP of the Infrastructure BSS and PBSS, or â€” The STA sending the Information Response frame is a non-PCP and non-AP STA and is not the target STA. In all other cases, the STA shall send the Information Response frame with the information requested by the requesting STA. 11.30.2 Peer Service Discovery An AP or PCP may provide different types of information to a non-AP and non-PCP STA upon request. To query available services in a BSS, a non-AP and non-PCP STA shall send either an Information Request frame or a Probe Request frame to the AP or PCP (11.30.1). The Information Request and Information Response frames are robust Management frames, while the Probe Request and Probe Response frames are not. Upon receiving the Information Request frame, the AP or PCP shall respond with an Information Response frame only if all of the following three criteria are true: a) The SSID in the Information Request frame is the wildcard SSID or the specific SSID of the AP or PCP. b) The BSSID field in the Information Request frame is the wildcard BSSID or the BSSID of the AP or PCP. c) The DA field in the Information Request frame is the MAC address of the AP or PCP. The AP or PCP transmits the Information Response frame to the address of the non-AP and non-PCP STA that generated the Information Request. The Information Response frame may include vendor-specific elements. 1866 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.31 Changing DMG BSS parameters 11.31.1 General This subclause describes the methods used by the AP or PCP to change certain key characteristics of the BSS. It also describes a method for a non-AP and non-PCP STA to make a recommendation on those characteristics to the AP or PCP. The AP or PCP delivers the DMG BSS Parameter Change element to STAs holding pseudo-static SPs and STAs in power save mode before a DMG BSS parameter change. The AP or PCP shall initiate a DMG BSS parameter change by including a DMG BSS Parameter Change element (9.4.2.127) in its DMG Beacon or Announce frames. The AP or PCP places the DMG BSS Parameter Change element in every DMG Beacon or Announce frame after the DMG BSS Parameter Change element is first included in the frame, stopping in the DMG Beacon or Announce frame immediately after the DMG BSS parameter change takes effect. 11.31.2 Moving the TBTT The AP or PCP may move the TBTT and hence move the entire beacon interval. Moving the beacon interval means that except for the beacon interval in which the change takes effect, the beacon interval duration is unchanged while the position of the TBTT is moved. The TBTT shall not be moved by an amount that is larger than the value in the Beacon Interval field present in DMG Beacon and Announce frames in which the DMG BSS Parameter Change element is sent. To move the TBTT to an intended new TBTT, the AP or PCP shall insert the DMG BSS Parameter Change element in DMG Beacon frames and/or Announce frames with the Move field set to 1 (9.4.2.127). The DMG Beacon frames and/or the Announce frames containing the DMG BSS Parameter Change element shall be sent at each TBTT dot11NbrOfChangeBeacons times before the TBTT is changed as indicated in the TBTT offset field. At each transmission of the DMG BSS Parameter Change element, the TBTT Offset field shall be set to a value equal to the lower order 4 octets of the intended new TBTT. The value of dot11NbrOfChangeBeacons shall be greater than dot11MaxLostBeacons. NOTEâ€”As defined in 11.1.2.1, the PCP transmits at least one DMG Beacon frame to each associated STA within a time interval that is not longer than dot11BeaconPeriod Ã— dot11MaxLostBeacons TUs. Announce frames shall be used to deliver the DMG BSS Parameter Change element to all STAs participating in pseudo-static SPs. The value of the Beacon Interval field of DMG Beacon frames and the Announce frames sent at the dot11NbrOfChangeBeacons+1 TBTT shall be set to the difference of the intended new TBTT and the TBTT where the DMG Beacon or Announce frames were sent. STAs associated with an AP or PCP that moves the TBTT shall not transmit during the beacon interval that precedes a new TBTT if the transmission time ends at the TBTT or later, even if the SP or the CBAP were scheduled in the beacon interval. At the intended new TBTT that is dot11NbrOfChangeBeacons+2 TBTTs after the DMG BSS Parameter Change element is first transmitted, the TSF timer is reset to 0 as defined in 11.1.3.3. 1867 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications An AP or PCP member of an AP or PCP cluster that wishes to move its TBTT shall set the TBTT Offset field to an empty Beacon SP allocated by its S-AP or S-PCP as defined in 10.37. Figure 11-43 illustrates the process in moving the TBTT position. DMG BSS parameter change Beacon interval duration First announcement of TBTT position change New TBTT Figure 11-43â€”Moving the TBTT position 11.31.3 Changing beacon interval duration The AP or PCP may change the duration of its beacon interval during the BSS operation. To change its beacon interval, the AP or PCP shall insert the DMG BSS Parameter Change element into DMG Beacon frames and/or Announce frames with the Size field set to 1 and the BI Duration field set to the duration of the beacon interval following this DMG BSS parameter change. The TBTT Offset field shall be set to the lower order 4 octets of the TBTT at dot11NbrOfChangeBeacons+1 TBTT position when this DMG BSS parameter change takes effect. The DMG Beacon frames and/or the Announce frames shall be sent at each TBTT dot11NbrOfChangeBeacons times before the beacon interval is changed as indicated in the BI Duration field of the DMG BSS Parameter Change element. At each transmission of the DMG BSS Parameter Change element the TBTT Offset field shall be set to a value equal to the lower order 4 octets of the intended TBTT. The value of dot11NbrOfChangeBeacons shall be greater than dot11MaxLostBeacons. Announce frames shall be used to deliver the DMG BSS Parameter Change element to all STAs participating in pseudo-static SPs. The AP or PCP that shortens the beacon interval shall not schedule SP and CBAP allocations that use more time than allowed in the beacon interval indicated in the BI Duration field of the DMG BSS Parameter Change element. The value of the beacon interval shall be set to the BI Duration field of the DMG BSS Parameter Change element at the dot11NbrOfChangeBeacons+1 TBTT. At this TBTT, the TSF timer is reset to 0 as defined in 11.1.3.3. If the AP or PCP sets the Move and the Size fields to 1 in the same DMG BSS Parameter Change element, it shall set the TBTT Offset field and proceed as defined in 11.31.2. The value of the beacon interval shall be set to the BI Duration field of the DMG BSS Parameter Change element at the new TBTT as defined in 11.31.2. Figure 11-44 illustrates the process in changing the beacon interval duration. 1868 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Old beacon New beacon interval duration interval duration First announcement of TBTT beacon interval duration change Figure 11-44â€”Changing beacon interval duration 11.31.4 Maintaining synchronization in an AP or PCP cluster A S-AP or S-PCP shall update the Clustering Control field transmitted in the DMG Beacon frame if the DMG BSS parameter change modifies the allocation of the Beacon SPs (10.37). If the Clustering Control field is modified as a result of a DMG BSS parameter change, the S-AP or S-PCP shall transmit the updated Clustering Control field in every DMG Beacon frame in which the DMG BSS Parameter Change element is transmitted. An AP or PCP member of an AP or PCP cluster receiving a S-AP or S-PCP DMG Beacon frame with a DMG BSS Parameter Change element indicating a change in the beacon interval duration or TBTT time shall immediately insert the appropriate DMG BSS Parameter Change element into its DMG Beacons if the S-AP or S-PCPâ€™s DMG BSS parameter change causes a modification in the allocation of the Beacon SPs. If an AP or PCP is required to change the beacon interval or/and TBTT to participate in an AP or PCP cluster or to change the beacon interval or/and TBTT as a result of its S-APâ€™s or S-PCPâ€™s parameters change (see 10.37), it shall follow the procedures in 11.31.2 and 11.31.3. 11.31.5 Recommending DMG BSS parameters to the AP or PCP A non-AP and non-PCP STA may make a recommendation for DMG BSS parameters to the AP or PCP by including a DMG BSS Parameter Change element in an Information Request or Information Response frame sent to the AP or PCP. A non-AP and non-PCP STA may recommend a shift in TBTT by setting the Move subfield in the Change Type Bitmap field of the DMG BSS Parameter Change element to 1 and setting the TBTT Offset field to the lower order 4 octets of the non-AP and non-PCP STAâ€™s TSF timer at the recommended first changed TBTT. The non-AP and non-PCP should select a value for the TBTT Offset field that gives the AP or PCP enough time to exercise the change. Similarly, a non-AP and non-PCP STA may recommend a beacon interval duration to the AP or PCP by setting the Size subfield in the Change Type Bitmap field of the DMG BSS Parameter Change element to 1 and setting the BI Duration field to the recommended beacon interval duration in TUs. An AP or PCP that receives an Information Request frame or an unsolicited Information Response frame from a non-AP and non-PCP STA containing a DMG BSS Parameter Change element may use the information within the element to change the DMG BSS parameters. When receiving an Information Request frame that includes the DMG BSS Parameter Change element, AP or PCP responds with an Information Response frame as specified in 11.30.1. If the AP or PCP changes the BSS parameters in the transmitted Information Response frame, the AP or PCP shall include a DMG BSS Parameter Change element reflecting the BSS parameter changes and shall use the procedure defined in 11.31.2 and 11.31.3, as appropriate, to change the BSS parameters. If the AP or PCP decides not to change the BSS parameters, it shall not include a DMG BSS Parameter Change element in the transmitted Information Response frame. 1869 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.32 Spatial sharing and interference mitigation for DMG STAs 11.32.1 General This subclause describes mechanisms to enable spatial sharing and interference mitigation within a PBSS/ infrastructure BSS and in a uncoordinated OBSS environment. Spatial sharing mechanisms allow SPs belonging to different STAs in the same spatial vicinity to be scheduled concurrently over the same channel, and for interference mitigation. Alternatively, the AP or PCP can use CBAPs to mitigate interference. The SPSH and Interference Mitigation field in the DMG Capabilities element indicates whether a STA supports spatial sharing. A STA that supports spatial sharing, as indicated in the SPSH and Interference Mitigation field equal to 1 in the STAâ€™s DMG Capabilities element, shall support the directional channel quality measurements described in 9.4.2.21.16 and 9.4.2.22.15. 11.32.2 Spatial sharing and interference assessment The AP or PCP should request STAs to perform and report spectrum and radio resource measurements described in 11.11 to assess the possibility to perform spatial sharing and for interference mitigation. The AP or PCP should use the directional channel quality described in 9.4.2.21.16 and 9.4.2.22.15 to assess the possibility for spatial sharing of SPs. An SP to be assessed for spatial sharing with other scheduled (existing) SPs or considered to be reallocated in the beacon interval is hereby termed as a candidate SP. There might be multiple candidate and existing SPs at one time, and an SP may simultaneously assume the role of candidate and existing SP depending upon the context it is used for spatial sharing and interference assessment. STAs that participate in an SP and that support spatial sharing should perform beamforming training with each other before engaging in any other communication or performing any measurements described in this subclause. The AP or PCP should request source DMG STA and destination DMG STA involved in a candidate SP to perform measurements for the purpose of spatial sharing with an existing SP only after the STAs have beamforming trained with each other. The AP or PCP can infer that the STAs in a candidate SP have a beamformed link with each other if the Beamforming Training field within the DMG TSPEC used to set up the candidate SP was set to 1 and at least one beacon interval has elapsed since the candidate SP was first scheduled. If the AP or PCP transmits a Directional Channel Quality request to a STA involved in a candidate SP to assess the possibility for spatial sharing with another existing SP, it shall set the Target STA to the corresponding peer STAâ€™s MAC address involved in the candidate SP and shall set the Measurement Method field to indicate ANIPI. If the candidate SP has already been allocated channel time, the AP or PCP should additionally transmit a Directional Channel Quality request to the STAs involved in the existing SP to assess the possibility for spatial sharing with the candidate SP. In the Directional Channel Quality request, the AP or PCP shall set the Target STA to the corresponding peer STA involved in the existing SP and shall set the Measurement Method field to indicate ANIPI. 1870 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NOTEâ€”When the AP or PCP transmits a Directional Channel Quality request to a STA of an existing SP, it intends to assess the channel quality during transmission by STAs belonging to the candidate SP. Similarly, when the AP or PCP transmits a Directional Channel Quality request to a STA of a candidate SP, it intends to assess the channel quality during transmission by STAs belonging to the existing SP. If a recipient STA that receives a Directional Channel Quality request frame is already beamformed trained with the target STA specified by the AID field within the frame, then the recipient STA shall carry out the measurement employing the same receive antenna configuration as is used by the recipient STA when receiving frames from the target STA. If the AID field is set to the broadcast AID or an unknown AID, then the recipient STA shall perform the measurements using a quasi-omni antenna pattern. Figure 11-45 illustrates an example of spatial sharing assessment between two SPs. In this example, SP1 is the existing SP and SP2 is the candidate SP. The AP or PCP transmits a Directional Channel Quality request to STAs C and D to measure over SP1â€™s channel allocation, and transmits a Directional Channel Quality request to STAs A and B to measure over SP2â€™s channel allocation. The relation of the Measurement Start Time and Measurement Duration fields in the Directional Channel Quality request message is shown in Figure 11-45, while the field Number of Time Blocks is the ratio (Measurement Duration/Measurement Unit). STAs C and D measure STAs A and B measure during the existing during the candidate reservation (SP1) reservation (SP2) STA STA STA STA C D A B Measurement Duration Measurement Duration SP1 (Existing): SP2 (Candidate): BTI ATI STA A <-> STA B STA C <-> STA D Time Measurement Measurement unit unit Measurement Measurement Start Time Start Time Figure 11-45â€”Example of spatial sharing assessment If a non-AP and non-PCP STA receives a Directional Channel Quality request from its AP or PCP, it should perform the measurements as indicated in the request and shall report back to the AP or PCP using the Directional Channel Quality report. The report shall be formatted and transmitted as per specified in the Directional Channel Quality request. The non-AP and non-PCP STA shall set the Report Mode field (9.4.2.22) in the report frame to indicate whether it performed the measurement as requested by the AP or PCP. 11.32.3 Achieving spatial sharing and interference mitigation An AP or PCP can estimate the channel quality across STAs participating in the BSS and implement spatial sharing and interference mitigation based on the results of the measurements performed by the STAs associated with the AP or PCP. An AP or PCP should schedule a candidate SP that overlaps with an existing SP in its beacon interval only after it receives a Directional Channel Quality report from the STAs involved in the candidate SP. 1871 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If a candidate SP is already scheduled in the beacon interval, the AP or PCP should schedule this candidate SP time-overlapping with an existing SP in its beacon interval only after it receives a Directional Channel Quality report from the STAs involved in the existing SP. The AP or PCP should schedule a candidate SP during a period of time in the beacon interval where the PBSS/infrastructure BSS performance is expected to be maximized. The determination of performance maximization should be based on measurement reports received by the AP or PCP, but is implementation dependent and beyond the scope of this standard. The decision process at the AP or PCP to perform spatial sharing of a candidate and an existing SP is implementation dependent and beyond the scope of this standard. The candidate SP is referred to as a time-overlapped SP following the allocation by the AP or PCP of a candidate SP overlapping in time with an existing SP. Figure 11-46 illustrates an example of the resulting SP schedule in the beacon interval for the spatial sharing between the two SPs shown in Figure 11-45. SP1: BTI ATI STA A STA B SP2: Time STA C STA D Figure 11-46â€”Example of spatial sharing between SP1 and SP2 The AP or PCP should periodically transmit a Directional Channel Quality request to each spatial sharing capable STA involved in a time-overlapped and existing SP scheduled under spatial sharing. In the Directional Channel Quality request that the AP or PCP transmits to each STA, the AP or PCP shall set the Target STA to the peer STA involved in the same SP and shall set the Measurement Method field to indicate RSNI. If a spatial sharing capable non-AP and non-PCP STA receives a Directional Channel Quality request from its AP or PCP, it should perform the measurements as indicated in the request and shall report the results back to the AP or PCP using the Directional Channel Quality report. The report shall be formatted and transmitted as per specified in the corresponding Directional Channel Quality request. The AP or PCP should stop the spatial sharing of two or more SPs if it determines that the link quality of any of the links involved in the spatial sharing has dropped below acceptable levels. This determination should be based on Directional Channel Quality reports received by the AP or PCP, but is implementation dependent and beyond the scope of this standard. The STA may include the Traffic Scheduling Constraint Set field with the ADDTS Request frame sent to the AP or PCP for the purpose of interference mitigation. The AP or PCP should consider the information in the Traffic Scheduling Constraint Set field specified by a STA in its SP schedule. Specific algorithms to realize spatial sharing and interference mitigation among SPs between different STAs is implementation dependent and beyond the scope of this standard. 1872 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.32.4 PBSS and infrastructure BSS stability in OBSS scenarios Except when performing FST (11.33), the AP or PCP limits the frequency with which it changes the operating PBSS/infrastructure BSS channel to alleviate the instability and ripple effect that might result from frequent channel changes in OBSS scenarios. Upon a channel switch, the AP or PCP of a PBSS/ infrastructure BSS shall select a random number, N, uniformly distributed between [0, SwitchInterval-1] and shall not attempt a new channel switch until N beacon intervals have elapsed since the preceding channel switch. The initial value of SwitchInterval is aMinSwitchInterval and it is doubled upon every new channel switch up to a maximum value of aMaxSwitchInterval. The AP or PCP resets SwitchInterval to aMinSwitchInterval if it remains on the same operating channel for a minimum of aMaxSwitchInterval consecutive beacon intervals. NOTEâ€”The AP or PCP can keep the SP schedule stable across beacon intervals and minimize schedule changes. This is to allow for STAs to associate with the PBSS/infrastructure BSS or add or modify their SP reservations. Stability in the allocation schedule in a beacon interval allows a PBSS/infrastructure BSS to assess the interference pattern produced by OBSSs and adapt to the environment by scheduling SPs over periods of time in the beacon interval when less interference is expected. 11.33 Multi-band operation 11.33.1 General A device is multi-band capable if the value of dot11MultibandImplemented is true. A multi-band capable device is said to be a member of a BSS when one or more of the STAs in the device is a member of the BSS. A STA that is part of a multi-band capable device advertises the capability by including the Multi-band element in Beacon, DMG Beacon, (Re)Association Request, (Re)Association Response, Information Request, Information Response, Probe Request, Probe Response, Announce, FST Setup Request, FST Setup Response, TDLS Discovery Request, TDLS Discovery Response, TDLS Setup Request, and TDLS Setup Response frames. Except for the FST Setup Request and FST Setup Response frames, which shall not include more than one Multi-band element, a STA may include more than one Multi-band element in any one of these frames if it is part of a device that supports more than two bands or channels. If an AP or PCP includes one or more Multi- band elements within a (Re)Association Response frame with Status Code equal to DENIED_WITH_SUGGESTED_BAND_AND_CHANNEL or a Probe Response frame, the order in which these elements appear in the frame indicate the order, in terms of frequency band and channel number, that the device that includes the STA addressed by the frame should attempt join the BSS following the rules applicable to the respective frequency band and channel (see 11.1). For each Multi-band element contained in the frame starting from the first one and proceeding in increasing order, the STA should attempt to join the BSS using the BSSID indicated by the BSSID field, frequency band indicated by the Band ID field and channel number indicated by the Channel Number field provided the Beacon Interval and the Channel Number fields in the Multi-band element are both nonzero. NOTEâ€”The first Multi-band element in the frame can refer to the current operating frequency band and channel. A multi-band capable device shall set the Band ID and Operating Class fields within a Multi-band element to specify a frequency band it supports. If the multi-band capable device is or intends to operate in the band indicated within the Multi-band element, it shall set the Channel Number field to indicate the channel of operation within that band. If the multi-band capable device is a member of a BSS both on the channel indicated in the Channel Number field within the Multi-band element and also in the channel on which this element is transmitted, then the multi-band capable device shall set the TSF Offset field within a Multi-band element to the difference between the TSF of the BSS of which the STA is member on the channel indicated in the Channel Number field of this element and the TSF of the BSS corresponding to the BSSID indicated in the Address 3 field of the MPDU in which this element is transmitted. In all other cases, the TSF Offset field shall be set to 0. 1873 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The FST session transition is managed by the FST session setup protocol. A multi-band capable device participates as an initiator or as a responder in the FST session setup. Depending on the STAâ€™s behavior during the FST session setup, the FST session can be operational in one band, or may be transferred to another band or channel in the same band, or can be operational in multiple bands and/or channels simultaneously and in this case MSDUs can be transmitted in different bands and/or channels any time an MSDU arrives at the MAC SAP. If a multi-band capable device is operational in more than one band/ channel simultaneously, the STA may use the FST session setup protocol to change the operation to a single channel. An FST session between an initiator and a responder is identified by an FSTS ID. The value of the FSTS ID is allocated by the initiator of an FST session and shall remain unchanged whether the FST session is operational in one band or more than one band simultaneously. The value of the FSTS ID shall be unique for an initiator and responder pair, and there shall be no more than one FST session between an initiator and responder pair. An initiator or responder may change the FSTS ID of its existing FST session by tearing down the existing FST session (11.33.3) and setting up a new one with a different FSTS ID value. In each band/channel, a multi-band capable device may use the same or different MAC addresses. When the STA MAC Address Present field is equal to 1 in a Multi-band element, the STA MAC Address field in the Multi-band element specifies the MAC address that the STA uses in the band and channel that are indicated in the Multi-band element. If the STA MAC Address Present field is 0, the MAC address that the STA uses in the frequency band and channel that are indicated in the Multi-band element is the same as the address the STA uses in the current operating band and channel. The FST session addressing mode is transparent if both initiator and responder of the FST session use the same MAC address in the frequency bands/channels involved in the FST. The FST session addressing mode is nontransparent if either the initiator or responder use different MAC addresses in the different frequency bands/channels involved in the FST session. When transparent FST is used, the STA shall present a single MAC SAP to higher layers for all frequency bands/channels in which it uses that MAC address. An FST is allowed if the FST Setup Request and FST Setup Response frames are permitted to be transmitted as indicated in 11.3.3. A multi-band capable device should deliver all fragments, if any, of an MSDU of an FST session before it transfers the FST session. A multi-band capable device shall include, in any transmitted FST Setup Request frame and in any transmitted FST Setup Response frame, the Capabilities element, the Operation element, the EDCA Parameter Set element, Supported Rates and BSS Membership Selectors element, Extended Supported Rates and BSS Membership Selectors element, and Supported Channels element that are applicable to the band and channel number indicated within its most recently transmitted Multi-band element that was transmitted on the same band and channel number on which it is transmitting the FST Setup Request or FST Setup Response frames. If a Multi-band element is present in the transmitted FST Setup Request or FST Setup Response frames, the Multi-band element is considered as the most recently transmitted Multi-band element. If a Session Transition element and a Multi-band element are present in the same frame and the values of the Operating Class and Channel Number fields within the Multi-band element are both nonzero, the value of the Band ID field related to the new band within the Session Transition element shall be the same as the Band ID field within the Multi-band element. 1874 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.33.2 FST setup protocol 11.33.2.1 General The FST setup protocol comprises four states and rules for how to move from one state to the next. The states are Initial, Setup Completed, Transition Done, and Transition Confirmed. In the Initial state, the FST session is operational in one or both bands/channels. In the Setup Completed state, both initiator and responder are ready to change their currently operating band(s)/channel(s). An FST session can be fully or partially transferred to another band/channel. The Transition Done state enables both initiator and responder to operate in the other band/channel if the value of the LLT was zero. Both initiator and responder have to successfully communicate in the new band/channel to reach the Transition Confirmed state. The state transition diagram of the FST setup protocol is shown in Figure 11-48. Figure 11-47 depicts the procedure of the FST setup protocol that drives the state machine shown in Figure 11-48. The figure is an example of only the basic procedure and is not meant to be exhaustive of all possible uses of the protocol. In the figure, MLME 1 and MLME 2 represent any two MLMEs of a multi- band capable device according to the reference model described in 4.9.4. The FST Setup Request and FST Setup Response frame exchange is repeated as necessary until both the FST initiator and FST responder successfully move to the Setup Completed state, as described below. Figure 11-47 illustrates this behavior. FST initiator STA FST responder STA SME MLME 1 MLME 2 MLME 2 MLME 1 SME loop <1, inf> MLME-FST- FST Setup MLME-FST- SETUP.request Request frame SETUP.indication Process FST Setup Request action MLME-FST- FST Setup MLME-FST- SETUP.confirm Response frame SETUP.response Process FST Setup Response action Decision to perform Decision to perform FST FST MLME-FST- MLME-FST- INCOMING.request INCOMING.request MLME- FST Ack MLME- FST-ACK.request Request frame FST-ACK.indication Process FST Ack Request action MLME- FST Ack MLME- FST-ACK.confirm Response frame FST-ACK.response Figure 11-47â€”Procedure of the FST setup protocol 1875 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications To establish an FST session in the Initial state and transfer it to the Setup Completed state of the FST setup protocol (Figure 11-48), an initiator and responder shall exchange FST Setup Request and FST Setup Response frames. An FST session exists in Setup Completed state, Transition Done state, or Transition Confirmed state. In the Initial and in the Setup Completed states, the old band/channel represents the frequency band/channel from which the FST session is to be transferred, and the new band/channel represents the frequency band/channel to which the FST session is to be transferred. In the Transition Done state, the new band/channel represents the frequency band/channel on which the FST Ack Request and FST Ack Response frames, if any, are transmitted, and the old band/channel represents the frequency band/ channel from which the FST session is being transferred. Status â‰ 0 or Operation (New Band)=0 Initial state Transition Confirmed state New Band/Channel becomes Communicating in Old Band/ Old Band/Channel Full connectivity in New Band/ Channel Channel Timeout, rejection or FST Ack Request, FST Ack Response, FST Setup Request, FST Tear Down; or successful frame exchange FST Setup Response initiated by any STA (excluding FST Tear Down) Setup Completed state Transition Done state LLT=0 in FST Setup Request Communicating in Old Band/ or Communicating in New Band/ Channel LLT transitions from one to zero Channel LLT>0 Figure 11-48â€”States of the FST setup protocol The responder shall set the Status Code field to SUCCESS if it accepts the FST Setup Request, shall set the Status Code to REJECTED_WITH_SUGGESTED_CHANGES (see 9.4.1.9) to indicate that one or more parameters of the FST Setup Request frame are invalid and shall suggest alternative parameters, shall set the Status Code to PENDING_ADMITTING_FST_SESSION or PENDING_GAP_IN_BA_WINDOW to indicate that an FST setup request is pending, and shall set the Status Code field to REQUEST_DECLINED to reject an FST Setup Request frame. A responder that is also an enabling STA (see 11.12) may set the Status Code to REJECT_DSE_BAND to indicate that the FST Setup Request frame is rejected because it was initiated by a dependent STA (see 11.12) that is requesting transition to a frequency band subject to DSE procedures. In this case, if the responder is the enabling STA for the dependent STA, the responder may include a Timeout Interval element in the FST Setup Response frame to indicate the period in TUs before which it initiates an FST Setup with the dependent STA. The Timeout Interval Type field within the Timeout Interval element shall 1876 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications be set to 4. The responder can use the parameters in the FST Setup Request frame received from the dependent STA to initiate an FST Setup with the initiator. A responder that is also a dependent STA and not enabled shall reject all received FST Setup Request frames for transitioning to a frequency band subject to DSE procedures, except if the transmitter of the FST Setup Request frame is the enabling STA of the dependent STA. 11.33.2.2 Transitioning between states A state transition within the FST setup protocol is controlled by the State Transition Timer (STT). Each STA maintains an STT for each FST session. A STA shall move to the Initial state when the STT moves from 1 to 0 (other than set to 0) or upon reception or transmission of an FST Teardown frame. The initiator shall set the STT to the value of the FSTSessionTimeout field at successful transmission of an FST Setup Request frame and at each Ack frame sent in response to a received FST Setup Response frame with the Status Code field equal to PENDING_ADMITTING_FST_SESSION or PENDING_GAP_IN_BA_WINDOW. The initiator shall set the STT to 0 at the transmission of an Ack frame sent in response to a received FST Setup Response frame with the value of the Status Code field equal to SUCCESS. The responder shall set the STT to the value of the FSTSessionTimeout field at successful transmission of an FST Setup Response frame. The responder shall set the STT to 0 at each transmission of an Ack frame sent in response to the reception of an FST Setup Request. The responder should send an FST Setup Response frame no later than FSTSessionTimeout after the transmission of an Ack frame sent in response to a received FST Setup Request frame or successful transmission of an FST Setup Response frame with the status code field equal to PENDING_ADMITTING_FST_SESSION or PENDING_GAP_IN_BA_WINDOW. In the latter case, the responder shall transmit the unsolicited FST Setup Response frame to the initiator. There might be multiple FST Setup Request and FST Setup Response frame transmissions by the initiator and the responder, respectively, until the FST session between these STAs becomes established. At each transition, or attempt to transition, from the Initial state to the Setup Completed state, the initiator and responder shall perform the following procedure: a) The initiator sends an FST Setup Request frame to the responder. b) Upon receipt of an FST Setup Request frame, the responder shall respond with an FST Setup Response frame unless it has a pending FST Setup Request frame addressed to the initiator and the responder has a numerically larger MAC address (see 12.7.1.1 for comparison of MAC addresses) than the initiatorâ€™s MAC address, in which case, the responder shall ignore the received FST Setup Request. c) If, after the reception of the acknowledgment to the initiatorâ€™s FST Setup Request frame, the initiator receives an FST Setup Request frame from the responder, the initiator shall not respond with an FST Setup Response frame if its MAC address is numerically larger (see 12.7.1.1 for comparison of MAC addresses and see 11.1.4.3.6) than the responderâ€™s MAC address. Otherwise, if its MAC address is numerically smaller than the responderâ€™s MAC address, it becomes the responder and shall respond with an FST Setup Response frame and shall not send the FST Setup Request frame during the current FST session transition. d) The initiator shall not move to the Setup Completed state if at least one of the following conditions is met: 1) The initiator does not successfully receive an FST Setup Response frame from the responder within the STT. 2) The value of the Status Code field in the received FST Setup Response frame from the responder is different from SUCCESS. 3) A state-specific exception in Table 11-20 takes place. 1877 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications e) The initiator shall move to the Setup Completed state if none of conditions d(1), d(2), and d(3) is met. f) The responder shall not move to the Setup Completed state if at least one of the following conditions is met: 1) The responder does not receive the acknowledgment to its transmitted FST Setup Response frame 2) The value of the Status Code field in the FST Setup Response frame it transmitted to the initiator was different from SUCCESS 3) The value of the Setup and Operation subfields within the Session Transition element in the transmitted FST Setup Response frame results in a status different from any of the rows shown in Figure 11-21, in which case the responder shall set the Status Code field with the transmitted FST Setup Response frame to REQUEST_DECLINED. 4) The resulting status of the Operation subfield in the New Band field is 0. g) The responder shall move to the Setup Completed state if none of conditions f(1), f(2), f(3) and f(4) is met. Table 11-20â€”Exceptions for the initiator State Condition Meaning Next state Initial FST Setup Response frame Pending, responder in process of admitting Initial with Status Code FST session. PENDING_ADMITTING_F ST_SESSION Initial FST Setup Response frame Pending, block ack window at the responder Initial with Status Code has gaps. PENDING_GAP_IN_BA_WI NDOW Initial FST Setup Response frame One or more parameters of the FST Setup Initial with Status Code Request frame is invalid and the responder REJECTED_WITH_SUGGE suggests alternative parameters. STED_CHANGES Initial FST Setup Response frame Responder rejects the request. One particular Initial with Status Code case is that values of the operating class and REQUEST_DECLINED channel number fields within the Multi-band element, if any, received in the FST Setup Request frame is different from the value of the corresponding fields within the Multi- band element, if any, transmitted in the following FST Setup Response. Initial FST Setup Response frame Responder rejects the request since the Initial with Status Code initiator is a dependent STA and the request REJECT_DSE_BAND is for transitioning to a frequency band subject to DSE procedures. In the rejection, the responder can include a Timeout Interval element. Initial Resulting status is different The responder is not able to complete the Initial from shown in Table 11-21 setup. Initial Resulting status of the The operation in the new band is disabled. Initial Operation field in the New Band field is 0 in Table 11-21 1878 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 11-20â€”Exceptions for the initiator (continued) State Condition Meaning Next state Setup FST Setup Response frame The STA is ready to switch to the new band if Setup Completed with Status Code SUCCESS the link is lost in the old band. Completed and value of the LLT field within the FST Setup Request frame is greater than zero Setup Transmission or reception of Termination of FST session. Initial Completed FST Teardown frame If, upon transition to the Setup Completed state, the value of the LLT field within the last successful FST Setup Request frame received by the responder or transmitted by the initiator was equal to 0, the initiator and responder shall immediately move to the Transition Done state. If, upon transition to the Setup Completed state, the value of the LLT field within the last successful FST Setup Request frame received by the responder or transmitted by the initiator was greater than 0, the initiator and responder shall proceed as follows: â€” If the last FST Setup Request or FST Setup Response frames exchanged between the initiator and responder included a Switching Stream element, then all of the streams within the Switching Stream element that have the LLT Type field set to 1 shall be switched using the Stream-based Link Loss Countdown, and all of the streams within the Switching Stream element that have the LLT Type field set to 0 shall be switched using the STA-based Link Loss Countdown. â€” If the neither the FST Setup Request nor the FST Setup Response frames exchanged between the initiator and responder included a Switching Stream element, then the streams shall be switched using the STA-based Link Loss Countdown. The FST transition for the STA, if STA-based, or the stream, if stream-based, from the Setup Completed state to the Transition Done state shall occur immediately after the corresponding Link Loss countdown timer transitions from 1 to 0 within any of the initiator or responder of the FST session. An initiator and responder shall perform the STA-based and stream-based Link Loss Countdown as follows: â€” STA-based Link Loss Countdown: Both initiator and responder shall remain in the Setup Completed state and start a Link Loss countdown timer with an initial value of LLTÃ—32 Âµs. The Link Loss countdown is reloaded with the value of LLTÃ—32 Âµs every time that an individually addressed frame is received from the peer STA of the FST session. â€” Stream-based Link Loss Countdown: Both the initiator and responder shall start a Link Loss countdown timer with an initial value of LLTÃ—32 Âµs for each stream identified within the Switching Stream element. The Link Loss countdown for a stream is reloaded with the value of LLTÃ—32 Âµs every time that an individually addressed frame for that stream is received from the peer STA of the FST session. Before leaving the Setup Completed state, an initiator and/or responder that is performing a full FST may transmit an FST Setup Response frame in the old band/channel with the Status Code field set to PERFORMING_FST_NOW and with the RA field set to the broadcast address to notify other STAs in the BSS of the STAâ€™s forthcoming full FST. Table 11-21 shows the FST session status at each state transition. The Setup and Operation subfields shown in Table 11-21 are present within the Session Transition element. When the value of a subfield in the FST Setup Request frame is different from the value of that same subfield in the following FST Setup Response 1879 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications frame, the resulting status shall be the logical AND of the value of the corresponding subfields in both the FST Setup Request and the FST Setup Response frames. Table 11-21â€”FST status at state transition Old band resulting New band resulting status status From State To State Definition Setup Operation Setup Operation Initial 1 1 0 0 Initial New band setup and operation are disabled. Initial 1 1 1 0 Initial New band operation is disabled, the setup is kept alive. Initial 0 0 1a 1 Setup FST session is Completed operational in new band. Initial 1a 1 1a 1 Setup FST session is Completed operational in both bands. Initial 1 0 1a 1 Setup FST session is Completed operational in new band; FST session in old band is kept alive. Setup Unchanged Unchanged Unchanged Unchanged Transition No status changes. Completed Done Transition Unchanged Unchanged Unchanged Unchanged Transition No status changes. Done Confirmed a The value of this field remains unchanged during the FST session transition. Upon transition to the Transition Done state and if transparent FST is used, the association state (see 11.3.1) of the STA corresponding to the old band/channel is transferred to the STA corresponding to the new band/ channel. To transition from the Transition Done state to the Transition Confirmed state, the initiator and responder shall perform the following procedure within the channel number of the operating class and band ID specified in the Multi-band element negotiated during the FST session setup: a) The State transition is controlled by the State Transition Timer (STT). Each STA of the FST session has its own STT. The initiator shall transition to the Initial state when its STT transitions from 1 to 0, but not when the STT is set to 0. The responder shall transition to the Initial state when its STT transitions from 1 to 0, but not when the STT is set to 0. The initiator shall set the STT to the value of the FSTSessionTimeout field at successful transmission of an FST Ack Request frame or at transmission of any individually addressed MPDU to the responder. The initiator shall set the STT to 0 at the transmission of an Ack frame sent in response to a received FST Ack Response from the responder or at reception of an Ack frame received in response to a frame sent to the responder. The responder shall set the STT to FSTSessionTimeout at transmission of an FST Ack Response frame or at transmission of any other individually addressed MPDU to the initiator. The responder shall set the STT to 0 at the reception of an Ack frame received in response to a transmitted FST Ack 1880 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Response frame or at the reception of any individually addressed frame sent by the initiator. The responder shall transmit an FST Ack Response frame to the initiator no later than FSTSessionTimeout after the transmission of an Ack frame sent in response to a received FST Ack Request from the initiator. b) The SME of both the initiator and responder generates an MLME-FST-INCOMING.request primitive that includes the parameters of the FST. This primitive shall be generated to the MLME associated with the channel number, operating class, and band ID specified in the Multi-band element negotiated during the FST session setup. This primitive notifies the MLME of an impending FST. c) The initiator shall send an FST Ack Request frame or may send any other individually addressed MPDU to the responder. NOTEâ€”Depending on the BSS configuration in the new band/channel, the initiator might have to associate and/or authenticate with the BSS before it is allowed to transmit a frame to the responder. d) Upon receipt of an FST Ack Request frame, the responder shall respond to the initiator with an FST Ack Response frame. NOTEâ€”Depending on the BSS configuration in the new band/channel, the responder might have to associate and/or authenticate with the BSS before it is allowed to transmit a frame to the initiator. e) The initiator shall move to the Transition Confirmed state 1) Upon transmission of an Ack frame sent in response to any individually addressed frame, including an FST Ack Response frame, received from the responder; or 2) When the initiator receives an Ack frame from the responder to any non-FST Ack Request frame the initiator transmitted to the responder. f) The responder shall move to the Transition Confirmed state 1) When the responder receives an Ack frame in response to any individually addressed frame, including an FST Ack Response frame, sent to the initiator; or 2) Upon transmission of an Ack frame sent in response to any individually addressed non-FST Ack Request frame. Following the transition to the Transition Confirmed state, a STA shall adopt the role indicated in the STA Role field corresponding to the channel number, operating class and band ID that was last transmitted to the peer STA within the Multi-band element. If the STA was operating within a PBSS, was the initiator of the FST session, and the new role of the STA is as an IBSS STA, then the STA shall be a DFS Owner of the IBSS. In case the transition to the Transition Confirmed state was the result of a Stream-based Link Loss Countdown, the stream shall remain in the Transition Confirmed state until all of the streams included within the corresponding Switching Stream element reach the Transition Confirmed state. Once all streams within the corresponding Switching Stream element reach the Transition Confirmed state or the FST session ceases to exist, the STA moves to the Initial state. If neither the initiator nor the responder perform in the role of AP or PCP as indicated through the STA Role field within the Multi-band element corresponding to the new band for that STA, one of the STAs can initialize a new BSS (11.1) on the new band for communication between the STAs. If the value of the Switch intent field in the last Session Transition element transmitted to a responder is 1, an initiator may switch to the new band and channel indicated in the last transmitted FST Setup Request frame and Multi-band element, respectively, if at least one of the following conditions is satisfied: â€” The value of the Status Code field within the FST Setup Response frame received in response to the transmitted FST Setup Request frame is equal to REQUEST_DECLINED. 1881 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” The initiator moves to the Initial state due to the STT at the initiator moving from 1 to 0. â€” The initiator moves to the Initial state due to the reception of an FST Teardown frame from the responder. Immediately before an initiator switches to a new band and/or channel, the initiator shall disassociate and delete all TS and block ack agreement(s) it has with a responder for which at least one of the above conditions is met. Following the successful FST transition to a new band, the STA of the FST session shall follow the medium access rules applicable to the new band. 11.33.2.3 FST TS switching If a STA transmitting an FST Setup Request frame or an FST Setup Response frame does not intend to switch all its streams, then the STA shall include the Switching Stream element in the transmitted frame to indicate which streams are requested to be transferred to the other band/channel. If the FST Setup Request frame includes a Switching Stream element, the FST Setup Response frame should include a Switching Stream element. If the FST Setup Request frame does not include a Switching Stream element, the FST Setup Response frame may include a Switching Stream element. If the STA transmitting the Switching Stream element has not set up a stream in the band indicated in the New Band ID field within this element, it shall set the Stream ID In New Band Valid field to 0. A STA may set up a stream in any band/channel by transmitting ADDBA Request or ADDTS Request frames that include the Multi-band element. If a STA transmits an ADDTS Request frame to another STA with which it has established an FST session and the ADDTS Request frame is transmitted in a band or channel different from the band or channel to which the ADDTS request is intended to apply, the ADDTS Request frame shall include the Multi-band element with the Band ID, Operating Class, and Channel Number fields set to indicate to which channel the ADDTS Request frame applies. In addition, if these STAs use the nontransparent mode for FST, the STA transmitting the ADDTS Request frame sets the STA MAC Address Present field to 1 and the STA MAC Address field to the MAC address that the STA uses in the band and channel number that are indicated in the Multi-band element contained in the ADDTS Request frame. Similar to the ADDTS Request frame, the Multi-band element shall be included in the ADDBA Request, ADDTS Response, ADDBA Response, DELTS, and DELBA frames when these frames are transmitted in a band or channel different from the band or channel to which they are intended to apply. When using transparent mode to transfer an FST session corresponding to a TID/TSID, the Direction subfield within the TSPEC element, if any, used to set up the TID/TSID should not be set to indicate a bidirectional link. This enables the SME to use the TID/TSID in conjunction with the source and destination MAC addresses in both the old and new frequency band/channel to uniquely identify the FST session. If any of the ADDTS variants is used to switch the TS, then the PTP TSPEC or the DMG TSPEC shall be used when the TS is being established to operate in a DMG BSS, and the Basic TSPEC shall be used when the TS is being established to operate in a non-DMG BSS irrespective of the band and channel used to communicate the ADDTS frames and the DMG ADDTS frames. The rules defined below apply when the ADDTS frames or the DMG ADDTS frames are used to switch TS. When the ADDTS frames and the DMG ADDTS frames are used, then the ADDTS requester and the ADDTS responder provide the functions defined for the ADDBA originator and the ADDBA recipient, respectively. If the ADDBA recipient includes the Switching Stream element in any of the FST Setup Request or FST Setup Response frames and if the Stream ID In New Band Valid field within the Switching Stream element is 0, the ADDBA originator should issue the DELBA frame to reject the BlockAck agreements indicated in 1882 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications the Stream ID In Old Band field. If the originator intends to establish new BlockAck agreements in the band indicated in the Multi-band element sent by the recipient and with the recipient MAC address indicated in the Multi-band element sent by the recipient, the originator shall transmit an ADDBA Request frame addressed to the recipient. The originator may include the Multi-band element and the Ethernet type TCLAS element in the ADDBA Request frame. If the MAC Addresses of the originator and recipient to be used in the new band are different from the MAC addresses used in the old band, then the ADDBA Request frame sent in the old band to establish a block ack agreement in the new band shall include the Multi-band and the TCLAS elements. The resulting block ack agreement, if established, applies to the band and channel identified in the Multi-band element included in the ADDBA Request frame. The BlockAck is identified by the TID/TSID and MAC addresses of the originator and the recipient used in the band and channel indicated in the Multi-band element included in ADDBA Request and ADDBA Response frames. The ADDBA Request frame may be issued in the old band and channel, and the corresponding ADDBA Response frame may be transmitted in the band and channel indicated in the Multi-band element within the ADDBA Request frame. The following rules for establishment of a multi-band block ack agreement shall apply: a) If the TA and/or the RA fields of the ADDBA Request frame are different from the originator MAC address and/or the recipient MAC address, respectively, used in the channel and band where the block ack agreement should operate, then the originator shall set the Source Address field and the Destination Address field of the classifier to the originator MAC address and the recipient MAC address, respectively, to be used in the band and channel indicated in the Multi-band element included in the ADDBA Request frame. b) If the TA and RA are equal to the originator MAC address and the recipient MAC address, respectively, then the Multi-band element, if any, included in the ADDBA Request frame shall indicate the band and channel over which the established block ack agreement is operating. The TCLAS element shall not be included in this ADDBA Request frame. c) The Multi-band element should not be included in the ADDBA Request frame if in the case b) the ADDBA Request frame is issued in the same band and channel over which the block ack agreement shall operate. d) If the TA and/or the RA fields of the ADDBA Response frame are different from the recipient MAC address and/or the originator MAC address, respectively, to be used in the channel and band where the block ack agreement should operate, then the recipient shall set the Source Address field and the Destination Address field of the classifier to the recipient MAC Address and the originator MAC address, respectively, to be used in the band and channel indicated in the Multi-band element included in the ADDBA Response frame. The indicated band and channel shall be equal to the band and channel indicated in the Multi-band element of the ADDBA Request frame. e) If the TA and RA fields are equal to the recipient MAC address and the originator MAC address, respectively, then the Multi-band element, if any, included in the ADDBA Response frame shall indicate the band and channel over which the established block ack agreement is operating. The indicated band and channel shall be equal to the band and channel indicated in the Multi-band element of the ADDBA Request frame. The TCLAS element shall not be included in the ADDBA Response frame. f) The Multi-band element should not be included in the ADDBA Response frame if in case e) the ADDBA Response frame is issued in the same band and channel over which the block ack agreement, if established, shall operate. 1883 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.33.3 FST teardown At the Setup Completed state or Transition Done state, a STA may transmit an FST Teardown frame to its peer STA of the FST session in order to tear down an FST session that was previously set up using the FST Setup Request/Response frame exchange. Upon transmission or reception of an FST Teardown frame, the initiator and responder move to the Initial state (11.33.2). When moving to the Initial state and if the value of the Switch intent field in the last Session Transition element transmitted to a responder is 1, the initiator behaves as described in 11.33.2.2. 11.33.4 On-channel Tunneling (OCT) operation OCT allows a STA of a multi-band capable device to transmit an MMPDU that was constructed by a different STA of the same device. An MMPDU transmitted this way is referred to as an OCT MMPDU. The MLME of the nontransmitting STA that constructs or is the destination of an OCT MMPDU is referred to as an NT-MLME. The MLME of the STA that transmits or receives an OCT MMPDU over the air is referred to as a TR-MLME. NOTEâ€”OCT can be used in conjunction with or independent from the FST setup protocol. Figure 11-49 depicts the overall OCT procedure. In this figure, refers to the name of any of the MLME primitives defined in 6.3 that meets all of the following conditions: â€” Defines request, indication, response, and confirm primitives, or just request and indication primitives. â€” Includes a peer Multi-band element. The peer Multi-band element is used to identify the peer NT- MLME. â€” Includes a local Multi-band element. The local Multi-band element is used to identify the local NT-MLME. Multi-band capable device Multi-band capable device SME NT-MLME TR-MLME TR-MLME NT-MLME SME MLME- .req (Tunnel=TR-MLME) MLME- OCTunnel.req (tunneled MMPDU) On-channel Tunnel Request frame MLME- OCTunnel.ind (tunneled MMPDU) MLME- .ind (Tunnel=TR-MLME) MLME- .rsp MLME- (Tunnel=TR-MLME) OCTunnel.rsp (tunneled MMPDU) On-channel Tunnel Response MLME- frame OCTunnel.cfm (tunneled MMPDU) MLME- .cfm (Tunnel=TR-MLME) Figure 11-49â€”On-channel tunneling procedure An MLME primitive meeting all of the above conditions is referred to as an OCT MLME primitive. NOTEâ€”MLME-AUTHENTICATE, MLME-ASSOCIATE, and MLME-REASSOCIATE are examples of primitives that are OCT MLME primitives. 1884 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications To transmit a tunneled MMPDU, the SME of a multi-band capable device generates an OCT MLME request primitive that includes the peer Multi-band element and the local Multi-band element. A NT-MLME receiving an OCT MLME request primitive shall â€” As defined in this standard, process the request and construct an OCT MMPDU corresponding to the primitive in question. The NT-MLME shall not transmit any frame as a result of this primitive. â€” Generate an MLME-OCTunnel.request primitive with parameters including the OCT MMPDU and the peer Multi-band element. The MLME-OCTunnel.request primitive shall be generated to the TR- MLME identified by the local Multi-band element which is contained within the OCT MMPDU. A TR-MLME receiving an MLME-OCTunnel.request primitive shall transmit an On-channel Tunnel Request frame addressed to the peer TR-MLME and which includes the tunneled MMPDU. A TR-MLME receiving an On-channel Tunnel Request frame shall generate an MLME- OCTunnel.indication primitive. The MLME-OCTunnel.indication primitive shall be generated to the NT- MLME identified by the peer Multi-band element contained within the received On-channel Tunnel Request frame. A NT-MLME receiving an MLME-OCTunnel.indication primitive shall â€” As defined in this standard, process the OCT MMPDU parameter of the primitive as if the MMPDU had been received over the air. â€” Generate an OCT MLME indication primitive corresponding to the frame type of tunneled MMPDU. This primitive is generated to the SME of the STA, which processes the MMPDU as defined in this standard. In the case of a .request/.indication primitive, the process stops here. Otherwise, the process continues as described below. The peer SME responds to the reception of an OCT MLME indication primitive by generating the corresponding OCT MLME response primitive. This response includes the peer Multi-band element and the local Multi-band element. A NT-MLME receiving an OCT MLME response primitive shall â€” As defined in this standard, process the response and construct an OCT MMPDU corresponding to the primitive in question. The NT-MLME shall not transmit any frame as a result of this primitive. â€” Generate an MLME-OCTunnel.request primitive with parameters including the OCT MMPDU and the peer Multi-band element. The MLME-OCTunnel.request primitive shall be generated to the TR- MLME identified by the local Multi-band element which is contained within the OCT MMPDU. A TR-MLME receiving an MLME-OCTunnel.request primitive transmits an On-channel Tunnel Request frame addressed to the peer TR-MLME that includes the tunneled MMPDU. A TR-MLME receiving an On-channel Tunnel Request frame generates an MLME-OCTunnel.indication primitive. The MLME-OCTunnel.indication primitive is generated to the NT-MLME identified by the peer Multi-band element contained within the received On-channel Tunnel Request frame. A NT-MLME receiving an MLME-OCTunnel.indication primitive â€” Processes the OCT MMPDU parameter of the primitive as if the MMPDU had been received over the air. â€” Generates an OCT MLME confirm primitive corresponding to the frame type of the OCT MMPDU. This primitive is directed at the SME. 1885 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.33.5 FST payload When FST action frames are forwarded by an AP, FST uses Ethertype 89-0d frames as defined in Annex H. In this case, the FST payload contains an FST Action frame body as is specified in 9.6.21. 11.34 MMSL cluster operation 11.34.1 Introduction A STA is MMSL cluster capable if it includes an MMS element in its most recent transmission of (Re)Association Request, (Re)Association Response, ADDTS Request, ADDTS Response, Probe Request, Probe Response, Information Request, or Information Response frames. An MM-SME coordinated STA shall be MMSL cluster capable, except for an MM-SME that coordinates two STAs where one STA is a member AP or member PCP in a centralized AP or PCP cluster and the other STA is associated to the S-AP of the centralized AP or PCP cluster. NOTEâ€”In the centralized clustering case, the two STAs in the MM-SME are communicating with different MAC entities with different SMEs, so there is no individual link for MMSL. A non-MM-SME coordinated STA may be MMSL cluster capable. An MMSL cluster capable STA shall include an MMS element in transmitted (Re)Association Request and (Re)Association Response frames. As described in 4.9.3, an MM-SME may coordinate multiple MACs (and their respective STAs). Each STA coordinated by the same MM-SME may be used for the MMSL cluster setup and maintenance. The PCP may deliver an MMS element that includes a MAC address that is equal to the BSSID and other MAC addresses that are not equal to the BSSID. The MAC addresses that are not the BSSID shall not be used to request and respond to association, reassociation, probing, and scheduling services provided by the PCP. If a non-AP and non-PCP STA has delivered an MMS element to the AP or PCP, the non-AP and non-PCP STA shall not send an ADDTS Request frame to the AP or PCP with the TA field equal to a MAC address that was not included in the delivered MMS element. If an MM-SME coordinated STA is associated with an AP or PCP that allocates one single AID to all STAs advertised in the MMS element sent by the MM-SME coordinated STA, the AID can be also used to identify the MMSL cluster. If the AID is provided for one of the advertised STAs of the MM-SME coordinated STA, then the same AID applies to all STAs whose addresses are referenced in the delivered MMS element and the Single AID field is set as per Table 9-247. Table 11-22 covers the possible cases of the AID use for MMSL cluster identification. 1886 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 11-22â€”Setting of Single AID field Is the Single Is the Single AID allocated to AID allocated to AID MMSL cluster configuration the MM-SME the MM-SME identification of coordinated coordinated MMSL cluster STA A? STA B? Non-AP and non-PCP MM-SME coordinated STA Yes Yes Yes A is associated to PCP MM-SME coordinated STA B. Non-AP and non-PCP MM-SME coordinated STA Yes Yes Yes A and non-AP and non-PCP MM-SME coordinated STA B are both associated to the same BSS. Non-AP and non-PCP MM-SME coordinated STA Yes No No A is associated to a BSS and non-AP and non-PCP MM-SME coordinated STA B is not associated to the BSS. Non-AP and non-PCP MM-SME coordinated STA Yes NA Yes A and non-AP and non-PCP STA B are both associated to the same BSS. Non-AP and non-PCP MM-SME coordinated STA Yes NA Yes A is associated to a BSS and one MAC entity of non-AP and non-PCP MM-SME coordinated STA B is associated to the same BSS. 11.34.2 MMSL cluster setup 11.34.2.1 General To establish an MMSL cluster, an MMS element of an MM-SME coordinated STA that lists its advertised STAs shall be delivered to the peer STA. The peer STA may be an MM-SME coordinated STA or a non- MM-SME coordinated STA. An MMSL cluster is identified by one of the following: a) Advertised MAC addresses of the MAC entities of two MM-SME coordinated STAs b) Advertised MAC addresses of the MAC entities of an MM-SME coordinated STA and of a non- MM-SME coordinated STA In both cases, the MMS element shall be exchanged between the STAs to set up the MMSL cluster agreement. If an MMSL cluster capable non-MM-SME coordinated STA receives an ADDTS Request frame that includes an MMS element, the SME of the non-MM-SME coordinated STA shall include the received MMS element in the MLME-ADDTS.response primitive used to send the ADDTS Response frame if the SME accepts the MMSL cluster setup. The SME of the non-MM-SME coordinated STA may set the MMS Element Owner field to â€œno Ownerâ€ in the MMS element included in an MLME-ASSOCIATE.request primitive and MLME-ADDTS.request primitive to establish the MMSL cluster with an MM-SME coordinated STA. The MMS element shall be exchanged between the STAs of the MMSL cluster only once per MMSL cluster setup. 1887 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.34.2.2 MMSL cluster setup of non-AP and non-PCP MM-SME coordinated STA with AP or PCP The Association Request and Response frames are used to establish an MMSL cluster between a non-AP and non-PCP MM-SME coordinated STA and an AP or PCP. If the AP or PCP is not an MM-SME coordinated STA, the AP or PCP shall include the MMS element received from the non-AP and non-PCP MM-SME coordinated STA in the Association Response frame sent as response. If the AP or PCP is an MM-SME coordinated STA, the AP or PCP should include its own MMS element that contains its advertised MAC entities in the Association Response frame and shall not include the MMS element received from the non-AP and non-PCP MM-SME coordinated STA in the Association Response frame. The AP or PCP shall not respond with any MMS element if it is not MMSL cluster capable. The setup of the MMSL cluster fails if the Association Response frame does not contain the MMS element. 11.34.2.3 MMSL cluster setup of non-AP and non-PCP STA with another non-AP and non- PCP STA If a non-AP and non-PCP MM-SME coordinated STA associated with an AP or PCP has established an AID identified MMSL cluster with the AP or PCP, the non-AP and non-PCP MM-SME coordinated STA shall not use a MAC address that was not included in the MMS element delivered to the AP or PCP to establish an MMSL cluster with another non-AP and non-PCP MM-SME coordinated STA associated with the same AP or PCP. An ADDTS Request/Response frame exchange with a PTP TSPEC shall be used to establish the MMSL cluster between non-AP and non-PCP MM-SME coordinated STAs and between a non-AP and non-PCP MM-SME coordinated STA and a non-AP and non-PCP non-MM-SME coordinated STA. A non-AP and non-PCP MM-SME coordinated STA shall include an MMS element that contains its advertised MAC entities in transmitted ADDTS Request frames. If the non-AP and non-PCP STA is not an MM-SME coordinated STA, the non-AP and non-PCP STA should include the MMS element with the MMS Element Owner field set to â€œno Ownerâ€ in the ADDTS Request frame. The non-AP and non-PCP MM-SME coordinated STA shall include its own MMS element that contains its advertised MAC entities in transmitted ADDTS Response frames. The non-MM-SME coordinated STA may include the MMS element of the MM-SME coordinated STA from which it received an ADDTS Request frame in the ADDTS Response frame sent as response. The non-MM-SME coordinated STA shall not respond with any MMS element if it is not MMSL cluster capable. The setup of the MMSL cluster fails if the ADDTS Response frame does not contain the MMS element. 11.35 DMG coexistence with non-IEEE-802.11 systems This subclause describes the features available in this standard to improve coexistence with other DMG systems, including IEEE Std 802.15.3câ„¢. The same common channelization that is defined in other DMG standards and specifications is adopted (20.3.1). In regulatory domains where 2 or more channels are defined, a DMG STA should support at least 2 channels. An AP should not start an infrastructure BSS on a channel where the signal level is at or above aDMGDetectionThres or upon detecting a valid IEEE 802.15.3câ„¢ CMS preamble at a receive level greater than or equal to â€“60 dBm. 1888 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If a DMG STA is capable of performing directional channel measurements (11.32) to detect non-IEEE-Std- 802.11 transmissions on a channel, it can report the results of the measurements to the STAâ€™s AP or PCP. If a DMG STA detects a non-IEEE-802.11 transmission on its channel or if the AP or PCP receives a report (11.11) from a DMG STA on a non-IEEE-802.11 transmission, the following mechanisms might be used to mitigate interference: â€” Change operating channel (11.9) â€” Beamforming (10.38) â€” Reduce transmit power (11.8) â€” Perform FST (11.33) â€” Move the TBTT (11.31.2), and thus the beacon interval, in the case of an AP or PCP â€” Change the schedule of SPs and CBAPs in the beacon interval (9.4.2.132) in the case of an AP or PCP â€” Defer transmission for a later time â€” For periods of time in the beacon interval where the STA experiences poor channel quality, the STA can use the Traffic Scheduling Constraint Set field within the DMG TSPEC element (9.4.2.134) to request its AP or PCP to avoid scheduling an SP for that DMG STA during those periods of time in the beacon interval. 11.36 DMG relay procedures 11.36.1 General Relaying allows a source relay endpoint DMG STA (REDS) to transmit frames to a destination REDS with the assistance of another DMG STA called the relay DMG STA (RDS). Relaying can improve the reliability of communication in a DMG BSS in case the direct link between the source REDS and the destination REDS is disrupted. A STA is a REDS if both dot11REDSActivated and dot11RelayActivated are true. A REDS shall set the Relay Client field within its Relay Capabilities element to 1. A STA is an RDS if both dot11RDSActivated and dot11RelayActivated are true. An RDS shall set the Relay Supporter field within its Relay Capabilities element to 1. A STA is relay capable if dot11RelayActivated is true and it is either a REDS or an RDS or both, and it is relay incapable otherwise. A relay capable STA shall advertise its capability by including the Relay Capabilities element in (Re)Association Request, (Re)Association Response, Probe Request, Probe Response, Information Request, and Information Response frames. An AP or relay capable PCP may include the Relay Capabilities element in DMG Beacon frames. For a STA to operate as a REDS or an RDS in an Infrastructure BSS or PBSS, the following conditions shall be met: â€” The STA is a member of the Infrastructure BSS or PBSS. â€” The TDDTI field within the DMG STA Capabilities element of the AP or PCP of the BSS is 1. â€” The Relay permission field within the Relay Capabilities element of the AP or PCP of the BSS is 1. A source REDS, a destination REDS and an RDS can establish the types of relay operation as specified in 10.40. 1889 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications As needed, in the following subclauses, source REDS, RDS, and destination REDS are expressed as â€˜Sâ€™, â€˜Râ€™, and â€˜Dâ€™, respectively. Also, a direct link between STA S and STA D can be simply referred to as S-D link. 11.36.2 Common relay setup procedures 11.36.2.1 Introduction This subclause describes the procedures that a source REDS, a destination REDS, and an RDS employ to set up a relay operation among these STAs. These procedures are used for both link switching and link cooperation relays, and shall be performed in the order shown in this subclause. 11.36.2.2 Relay capabilities and RDS discovery procedures A source REDS can obtain the capabilities of other STAs in the BSS following the STAâ€™s association with the BSS or with the transmission of an Information Request frame as described in 11.30.1. A source DMG STA that intends to set up relay operation with a destination DMG STA shall obtain the capabilities of the destination DMG STA prior to initiating the relay setup procedure with the destination DMG STA. The source DMG STA may attempt to set up relay operation with the destination DMG STA only if both the source DMG STA and destination DMG STA are REDS, and there exists at least one RDS in the BSS. Upon receiving an MLME-RELAY-SEARCH.request primitive, the source DMG STA can discover a list of RDSs in the BSS by transmitting a Relay Search Request frame to the AP or PCP with the destination REDS AID field set to the AID of the destination DMG STA. The MLME of the AP or PCP receiving a Relay Search Request frame shall generate an MLME-RELAY-SEARCH.indication primitive. Upon receiving an MLME-RELAY-SEARCH.response primitive, the AP or PCP shall transmit a Relay Search Response frame addressed to the requesting STA and shall include in the transmitted frame a list of RDSs in the BSS. The MLME of the source DMG STA receiving a Relay Search Response frame shall generate an MLME- RELAY-SEARCH.confirm primitive. After the transmission of the Relay Search Response frame to the source DMG STA, the AP or PCP shall transmit an unsolicited Relay Search Response frame to the destination DMG STA with the Relay Capable STA Info field of the source DMG STA and the list of RDSs that the AP or PCP included in the last Relay Search Response frame transmitted to the source DMG STA. 11.36.2.3 RDS selection procedure Following the transmission of a Relay Search Response frame, the AP or PCP should schedule within its Extended Schedule element two SPs for each RDS included in the transmitted Relay Search Response frame: â€” An SP having as source DMG STA the source REDS and as destination DMG STA the RDS, and with the Beamforming Training field set to 1. The duration of the SP should be such that the source REDS and RDS can complete BF as described in 10.38. â€” An SP having as source DMG STA the RDS and as destination DMG STA the destination REDS, and with the Beamforming Training field set to 1. The duration of the SP should be such that the RDS and the destination REDS can complete BF as described in 10.38. After the RDS completes BF with both the source REDS and destination REDS, the source REDS shall send a Multi-Relay Channel Measurement Request frame to the RDS, which shall respond with the transmission of a Multi-Relay Channel Measurement Report frame back to the source REDS. Following the reception of this frame, the source REDS should perform BF with the destination REDS as described in 10.38, and once BF is completed the source REDS shall transmit a Multi-Relay Channel Measurement Request frame to the destination REDS. In response, the destination REDS shall transmit a Multi-Relay Channel Measurement 1890 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Report frame to the source REDS including the channel measurement information between the destination REDS and all RDSs known to the destination REDS. To shorten the time it takes to complete this procedure, STAs can limit BF to the SLS phase only. Once this procedure is completed, the source REDS becomes aware of all the channel measurement information between the source REDS and zero or more RDSs and between the destination REDS and zero or more RDSs. The source REDS shall then select a single STA to operate as the RDS between the source REDS and the destination REDS. The selection of the RDS is implementation dependent, and it can be based on information contained within an RDSâ€™s Relay Capabilities element and channel measurements. 11.36.2.4 RLS procedure Following the selection of the RDS to be used between the source REDS and the destination REDS, the source REDS receiving an MLME-RLS.request primitive initiates the RLS procedure by sending an RLS Request frame to the selected RDS. The RLS Request frame includes the capabilities and the AIDs of the source REDS, the destination REDS, and the RDS, and the relay transfer parameter set. Upon receiving the RLS Request frame, the RDS shall transmit an RLS Request frame to the destination REDS containing the same information as received within the frame body of the source REDSâ€™s RLS Request frame. The MLME of the destination REDS receiving a Relay Search Request frame shall generate an MLME- RLS.indication primitive. Upon receiving an MLME-RLS.response primitive, the destination REDS shall transmit an RLS Response frame to the RDS with the destination status code field set to SUCCESS if the destination REDS is willing to participate in the RLS, and set to REQUEST_DECLINED if the destination REDS is not willing to participate in the RLS. Upon receiving the RLS Response frame, the RDS shall transmit an RLS Response frame to the source REDS containing the same information as received within the destination REDSâ€™s RLS Response frame, with the exception that the RDS shall set the relay status code field to SUCCESS if the RDS is willing to participate in the RLS, and shall set it to REQUEST_DECLINED if the RDS is not willing to participate in the RLS. The MLME of the source DMG STA receiving an RLS Response frame from the RDS shall generate an MLME-RLS.confirm primitive. Upon receiving an RLS Response frame with the destination status code and relay status code fields set to SUCCESS, the source DMG STA may transmit an RLS Announcement frame to the AP or PCP to indicate that the RLS procedure was successfully completed. If either or both of the destination status code and relay status code fields are nonzero, the RLS procedure is unsuccessful. Upon the completion of RLS procedure, the source REDS, the destination REDS, and the RDS can redo BF among them. 11.36.3 Relay operation-type change procedure The source REDS may change the relay operation type from link switching to link cooperation, and vice- versa, if either one of S-D, or S-R, or R-D links becomes unavailable or for other reasons. Link unavailability can be determined by the source DMG STA not receiving expected frames from the destination REDS. To assist in this decision, the source REDS can use the link adaptation procedure (10.41.4) to obtain the quality of a link. To change the relay operation type within an SP from link cooperation to link switching in a case that the S- D link becomes unavailable, the source REDS shall transmit a ROC Request frame to the RDS with the Link Cooperation subfield set to 0 and the relay-link subfield set to 1. Upon receiving a ROC Request frame, the RDS shall transmit a ROC Request frame to the destination REDS containing the same information as received within the frame body of the source REDSâ€™s ROC Request frame. Following the reception of a ROC Request frame, the destination REDS shall respond with a ROC Response frame to the RDS with the status code field set to SUCCESS if the destination REDS accepts to change the operation into link switching, and set to REQUEST_DECLINED if the destination REDS rejects the request. Upon receiving 1891 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications the ROC Response frame, the RDS shall transmit a ROC Response frame to the source REDS with the status code field set to SUCCESS only if the RDS accepts to change the operation into link switching and the status code field set to SUCCESS in the ROC Response frame received from destination REDS. Otherwise, the RDS shall set the status code field to REQUEST_DECLINED. Upon reception of a ROC Response from the RDS with the status code field set to SUCCESS, the source REDS immediately starts to transmit frames to the destination REDS via the RDS relay link. To change the relay operation type from link cooperation to link switching in other case that the S-R link becomes unavailable, the source REDS shall a ROC Request frame to the destination REDS with the Link Cooperation subfield set to 0 and the relay-link subfield set to 0. Following the reception of a ROC Request frame, the destination REDS shall respond with a ROC Response frame to the source REDS with the status code field indicating the acceptance or rejection of the request. Upon reception of a ROC Response from the destination REDS with the status code field set to SUCCESS, the source REDS starts to transmit frames to the destination REDS via the direct link in link switching. To change the relay operation type within an SP from link switching to link cooperation, the source REDS shall transmit a ROC Request frame to the destination REDS via the RDS with the Link Cooperation subfield set to 1. Following the reception of a ROC Request frame from the RDS, the destination REDS shall respond with a ROC Response frame to the source REDS via the RDS with the status code field indicating the acceptance or rejection of the request. Upon reception of a ROC Response frame from the RDS with the status code field set to SUCCESS, the source REDS immediately starts to transmit frames to the destination REDS using the RDS in link cooperation. If a TPA procedure was not performed beforehand since the link switching operation has been continued from the start of relay operation, the STA shall perform the TPA procedure before transmitting using link cooperation. NOTEâ€”As described in 10.40, during the SP in link cooperation operation the destination REDS has its receive antenna pattern such that it simultaneously covers the links toward both the source REDS and the RDS. 11.36.4 Relay teardown A source REDS that has successfully completed the RLS procedure with a destination REDS may teardown the relay operation between the source REDS, destination REDS and RDS. To do that, the source REDS shall transmit an RLS Teardown frame to the RDS, destination REDS and AP or PCP of the BSS. Within the RLS Teardown frame, the source REDS shall set the source AID field to the AID of the source REDS, the destination AID field to the AID of the destination REDS and the relay AID field to the AID of the RDS. A RDS may teardown the relay operation between the source REDS, destination REDS and RDS. To do that, the RDS shall transmit an RLS Teardown frame to the source REDS, destination REDS and AP or PCP of the BSS. Within the RLS Teardown frame, the RDS shall set the source AID field to the AID of the source REDS, the destination AID field to the AID of the destination REDS and the relay AID field to the AID of the RDS. 11.37 Quieting adjacent DMG BSSs 11.37.1 General An AP that supports QAB shall set the QAB Capability field within the APâ€™s Extended Capabilities element to 1 and shall set the QAB Capability field to 0 otherwise. In addition, if an AP supports QAB, the AP shall also support scheduling SPs as defined in 10.36.6. 1892 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.37.2 Procedure at the requester AP Upon receipt of an MLME-QAB.request primitive, an AP shall perform the following procedure to start the Quiet Adjacent BSS operation (Figure 11-50): a) If both the requester and responder APs are QAB capable as indicated by the QAB Capability field within the Extended Capabilities element, the requester AP sends a QAB Request frame indicating the duration, period, offset, and number of the quiet intervals. The requester AP may include multiple Quiet Period Request elements in one frame targeting multiple responder APs. b) If a QAB Response frame is received with the matching dialog token and request token with a status code set to a value of SUCCESS, the AP has confirmed the responder AP has scheduled the requested quiet periods, and the MLME shall issue an MLME-QAB.confirm primitive indicating the success of the procedure. c) If a QAB Response frame is received with the matching dialog and request token with a status code set to a value other than SUCCESS, the procedure is considered to have failed, and the MLME shall issue an MLME-QAB.confirm primitive indicating the failure of the procedure. NOTEâ€”The GAS protocol can be used by an AP to verify the capabilities of another AP. 11.37.3 Procedure at the responder AP A responder AP shall operate as follows (Figure 11-50): a) When a QAB Request frame matching the BSSID is received from another AP, the MLME shall issue an MLME-QAB.indication primitive. b) Upon receipt of the MLME-QAB.response primitive, the AP shall respond by transmitting a QAB Response frame. 1) If the result code is SUCCESS, the request is accepted. The AP shall use SPs to schedule the quiet period(s) according to the accepted request. The SPs shall have the AP as both source and destination and the AP shall not transmit during the SP. The QAB procedure shall be terminated if the number of quiet intervals exceeds the value of the Repetition Count field specified. Contained in the transmitted QAB Response frame is the copy of the request token and the BSSID of the AP. 2) If the result code is REJECTED, the request has not been fulfilled. AP SME AP MAC AP MAC AP SME MLME-QAB.request QAB Request MLME- QAB.indication MLME- QAB.response QAB Response MLME-QAB.confirm Figure 11-50â€”Quieting adjacent BSS operation 1893 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.38 DMG beamforming Upon receipt of an MLME-BF-TRAINING.request primitive, a STA shall undertake beamforming training with the STA indicated by the PeerSTAAddress parameter according to the procedures defined in 10.38. This training shall start with the SLS and shall include the BRP if and only if the RequestBRP parameter of the MLME-BF-TRAINING.request primitive is true. A STA receiving MLME-BF-TRAINING.request primitive may act as either initiator or responder in the beamforming training. If the STA indicated by the PeerSTAAddress parameter of a received MLME-BF-TRAINING.request primitive is an AP or PCP of a BSS in which a STA is a member, the STA receiving the MLME-BF- TRAINING.request primitive may perform beamforming training during the A-BFT as described in 10.38.5. Alternatively, the STA receiving the MLME-BF-TRAINING.request primitive may use an SP or a TXOP to perform ISS as described in 10.38.2.2. A STA receiving the MLME-BF-TRAINING.request primitive shall issue an MLME-BF- TRAINING.confirm primitive on completion of the requested beamforming training or on timeout as specified in 10.38. A STA that performs beamforming training with a peer STA at the request of the peer STA shall issue an MLME-BF-TRAINING.indication primitive on completion of that beamforming training, or on timeout as specified in 10.38. Figure 11-51 illustrates an example of the beamforming training procedure in the DTI for a case where the STA receiving the MLME-BF-TRAINING.request primitive acts as initiator. Figure 11-52 illustrates an example of the beamforming training procedure in the context of a non-AP and non-PCP STA joining an infrastructure BSS or PBSS. In this scenario, the MLME-BF-TRAINING.request primitive is issued by the STA attempting to associate in order that the link be trained to a degree that allows the over-the-air exchanges necessary for association to succeed. 1894 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications SME MAC Peer MAC Peer SME MLME-BF-TRAINING.request SSW SSW . ISS . . SSW SSW SSW . RSS . . SSW SSW-Feedback SSW-Ack If BRP requested BRP frame BRP frame . . . BRP frame MLME-BF-TRAINING.confirm MLME-BF-TRAINING.indication Figure 11-51â€”Beamforming training procedure in the DTI Non-AP and Non-AP and AP or PCP MAC AP or PCP SME non-PCP SME non-PCP MAC MLME-SCAN.request Scan detects an AP or PCP of interest MLME-SCAN.confirm MLME-JOIN.request MLME-JOIN.confirm DMG Beacon DMG Beacon MLME-BF-TRAINING.request . . . SLS (possibly as responder using initiator TXSS from BTI and with RSS in A-BFT or DTI), followed by BRP if requested by either side. MLME-BF-TRAINING.confirm MLME-BF-TRAINING.indication MLME-ASSOCIATE.request Association Request MLME-ASSOCIATE.indication MLME-ASSOCIATE.confirm Association Response MLME-ASSOCIATE.response Figure 11-52â€”Beamforming training when joining an infrastructure BSS or PBSS 1895 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.39 DMG MAC sublayer attributes The attributes that define some of the MAC characteristics are given in Table 11-23. Table 11-23â€”DMG MAC sublayer attribute values Attribute Value aMaxBIDuration 1000 TUs aMinChannelTime aMaxBIDuration aMinBTIPeriod 4 aMinSwitchInterval 2Ã—aMinBTIPeriod aMaxSwitchInterval 16Ã—aMinSwitchInterval aTSFResolution 1 Âµs aDMGPPMinListeningTime 150 Âµs aSSFramesPerSlot 4 aSSDuration (FSS â€“ 1) Ã— SBIFS + FSS Ã— TXTIME(SSW) aSSFBDuration TXTIME(SSW-Feedback) aRTSTimeoutTime TXTIME(RTS) + aAirPropagationTime + aRxPHYDelay + aMACProcessingDelay aDMGTSFAccuracy 20 ppm aMinNAVTimersNumber 2 aCWminDMGIBSS 3 aMinAllocationDeliveryTime 300 Âµs aMaxABFTAccessPeriod 2 aDtime aSBIFSTime+TXTIME(TPA Request frame) aRelayTPATime aSBIFSTime+2Ã—aAirPropagationTime+2Ã—aDtime+ TXTIME(TPA Request frame)+2Ã—TXTIME(TPA Response frame) aMinPPDUDurationForDMGMeasurement 5.27 Âµs aDMGDWSValidPeriod 60 seconds 11.40 VHT BSS operation 11.40.1 Basic VHT BSS functionality A VHT STA has dot11VHTOptionImplemented equal to true. A STA that is starting a VHT BSS shall be able to receive and transmit at each of the tuple values indicated by the Basic VHT-MCS And NSS Set field of the VHT Operation parameter of the MLME-START.request primitive and shall be able to receive at each of the tuple values indicated by the Supported VHT-MCS and NSS Set field of the VHT Capabilities parameter of the MLME- START.request primitive. 1896 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A STA for which dot11VHTOptionImplemented is true shall set dot11HighThroughputOptionImplemented to true. A STA that is a VHT AP or a VHT mesh STA declares its channel width capability in the VHT Capabilities element VHT Capabilities Information field as described in Table 9-249. A VHT STA shall set the Supported Channel Width Set subfield in its HT Capabilities element HT Capability Information field to 1, indicating that both 20 MHz operation and 40 MHz operation are supported. At a minimum, a VHT STA sets the Rx MCS Bitmask of the Supported MCS Set field of its HT Capabilities element according to the setting of the Rx VHT-MCS Map subfield of the Supported VHT-MCS and NSS Set field of its VHT Capabilities element as follows: for each subfield Max VHT-MCS For n SS, 1 n 4 , of the Rx VHT-MCS Map field with a value other than 3 (no support for that number of spatial streams), the STA shall indicate support for MCSs 8(nâ€“1) to 8(nâ€“1)+7 in the Rx MCS Bitmask, where n is the number of spatial streams, except for those MCSs marked as unsupported as described in 10.7.12.3. A STA that is a VHT AP or a VHT mesh STA shall set the STA Channel Width subfield in the HT Operation element HT Operation Information field and the Channel Width, Channel Center Frequency Segment 0 and Channel Center Frequency Segment 1 subfields in the VHT Operation element VHT Operation Information field to indicate the BSS bandwidth as defined in Table 11-24. Table 11-24â€”VHT BSS bandwidth HT Operation VHT Operation VHT Operation element element STA element Channel Channel Center Frequency BSS bandwidth Channel Width Width field Segment 1 subfield field 0 0 0 20 MHz 1 0 0 40 MHz 1 1 0 80 MHz 1 1 CCFS1 > 0 and 160 MHz | CCFS1 - CCFS0 | = 8 1 1 CCFS1 > 0 and 80+80 MHz | CCFS1 - CCFS0 | > 16 1 2 0 160 MHz (deprecated) 1 3 CCFS1 > 0 and 80+80 MHz | CCFS1 - CCFS0 | > 16 (deprecated) NOTE 1â€”CCFS0 represents the value of the Channel Center Frequency Segment 0 subfield. NOTE 2â€”CCFS1 represents the value of the Channel Center Frequency Segment 1 subfield. The setting of the Channel Center Frequency Segment 0 and Channel Center Frequency Segment 1 subfields is shown in Table 11-25. A VHT STA shall determine the channelization using the combination of the information in the HT Operation element Primary Channel field and the VHT Operation element VHT Operation Information field Channel Center Frequency Segment 0 and Channel Center Frequency Segment 1 subfields (see 21.3.14). 1897 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 11-25â€”Setting of Channel Center Frequency Segment 0, Channel Center Frequency Segment 1, and Channel Center Frequency Segment 2 subfields VHT Setting of the Setting of the Operation BSS Setting of the Channel Center Frequency Channel Center Channel Center element bandwidth Segment 0 subfield Frequency Segment Frequency Segment Channel 1 subfield 2 subfield Width field 20, 40 MHz 0 dot11CurrentChannelCenterFrequencyIndex0 0 0 80 MHz 1 dot11CurrentChannelCenterFrequencyIndex0 0 0 160 MHz 1 if dot11CurrentPrimaryChannel is greater dot11CurrentChanne 0 (At least than lCenterFrequencyIn Max VHT dot11CurrentChannelCenterFrequencyIndex0 dex0 NSS then support) dot11CurrentChannelCenterFrequencyIndex0 + 8, else dot11CurrentChannelCenterFrequencyIndex0 â€“8 160 MHz 1 if dot11CurrentPrimaryChannel is greater 0 dot11CurrentChanne (Less than than lCenterFrequencyIn Max VHT dot11CurrentChannelCenterFrequencyIndex0 dex0 NSS then support) dot11CurrentChannelCenterFrequencyIndex0 + 8, else dot11CurrentChannelCenterFrequencyIndex0 â€“8 80+80 MHz 1 dot11CurrentChannelCenterFrequencyIndex0 dot11CurrentChanne 0 (At least lCenterFrequencyIn Max VHT dex1 NSS support) 80+80 MHz 1 dot11CurrentChannelCenterFrequencyIndex0 0 dot11CurrentChanne (Less than lCenterFrequencyIn Max VHT dex1 NSS support) 160 MHz 2 dot11CurrentChannelCenterFrequencyIndex0 0 0 (deprecated) 80+80 MHz 3 dot11CurrentChannelCenterFrequencyIndex0 dot11CurrentChanne 0 (deprecated) lCenterFrequencyIn dex1 NOTE 1â€”â€œAt least Max VHT NSS supportâ€ means that the NSS support at 160 or 80+80 MHz is at least Max VHT NSS, and therefore the secondary 80 or 160 MHz channel center frequency is signaled through CCFS1. NOTE 2â€”â€œLess than Max VHT NSS supportâ€ means that the NSS support at 160 or 80+80 MHz is less than Max VHT NSS, and therefore the secondary 80 or 160 MHz channel center frequency is signaled through CCFS2. NOTE 3â€”For NSS support, see Table 9-75 and Table 9-250. A VHT AP or a VHT mesh STA shall set the HT Operation element HT Operation Information field Secondary Channel Offset subfield to indicate the secondary 20 MHz channel as defined in Table 9-168, if the BSS bandwidth is more than 20 MHz. A VHT STA that is a member of a VHT BSS shall not transmit a 20 MHz VHT PPDU on a channel other than the primary 20 MHz channel, except for a 20 MHz VHT PPDU transmission on an off-channel TDLS direct link as constrained by 11.23.6.5.2. 1898 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A VHT STA that is a member of a VHT BSS with a 40 MHz, 80 MHz, 160 MHz, or 80+80 MHz BSS bandwidth shall not transmit a 40 MHz VHT PPDU that does not use the primary 40 MHz channel, except for a 40 MHz VHT PPDU transmission on an off-channel TDLS direct link. A VHT STA that is a member of a VHT BSS with an 80 MHz, 160 MHz, or 80+80 MHz BSS bandwidth shall not transmit an 80 MHz VHT PPDU that does not use the primary 80 MHz channel, except for an 80 MHz VHT PPDU transmission on an off-channel TDLS direct link. A VHT STA that is a member of a VHT BSS with a 160 MHz or 80+80 MHz BSS bandwidth shall not transmit a 160 MHz or 80+80 MHz VHT PPDU that does not use the primary 80 MHz channel and the secondary 80 MHz channel, except for a 160 MHz or 80+80 MHz VHT PPDU transmission on an off- channel TDLS direct link. A VHT STA shall not transmit to a second VHT STA using a bandwidth that is not indicated as supported in the Supported Channel Width Set subfield in the HT Capabilities element or in the VHT Capabilities Information field of the VHT Capabilities element received from that VHT STA. A STA shall not transmit an MPDU in a VHT PPDU to a STA that exceeds the maximum MPDU length capability indicated in the VHT Capabilities element received from the recipient STA. A VHT AP shall set the RIFS Mode field in the HT Operation element to 0. VHT BSS operation with less than Max VHT NSS support is enabled as defined in Table 11-26 and disabled otherwise, in which case the Channel Center Frequency Segment 2 subfield of the HT Operation element shall be 0. Table 11-26â€”Extended NSS channel width HT Operation VHT Operation VHT Operation element STA HT Operation element Extended NSS element Channel element CCFS1 Channel Width CCFS2 field channel width Width field field field CCFS2 > 0 and 1 1 0 |CCFS2 â€“ CCFS0| = 8 160 MHz (40 MHz apart) CCFS2 > 0 and 1 1 0 |CCFS2 - CCFS0| > 16 80+80 MHz (> 80 MHz apart) CCFS2 > 0 and 1 1 0 |CCFS2 â€“ CCFS0| < 8 Reserved (< 40 MHz apart) CCFS2 > 0 and 8 < |CCFS2 â€“ CCFS0| â‰¤ 16 1 1 0 Reserved (> 40 MHz and â‰¤ 80 MHz apart) NOTE 1â€”CCFS0 represents the value of the Channel Center Frequency Segment 0 subfield of the VHT Operation element. NOTE 2â€”CCFS2 represents the value of the Channel Center Frequency Segment 2 subfield of the HT Operation element. 1899 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications When VHT BSS operation with less than Max VHT NSS support is enabled, the NSS support is determined based on the Extended NSS channel width and the VHT Capabilities element per Table 9-250 and Table 9-75. 11.40.2 Channel selection methods for a VHT BSS Before a STA starts a VHT BSS, the STA shall perform a minimum of dot11VHTOBSSScanCount OBSS scan operations to search for existing BSSs (see 11.40.3). If an AP or a mesh STA starts a VHT BSS that occupies some or all channels of any existing BSSs, the AP or mesh STA may select a primary channel of the new VHT BSS that is identical to the primary channel of any one of the existing BSSs. If an AP or a mesh STA selects a primary channel for a new VHT BSS with a 40 MHz, 80 MHz, 160 MHz, or 80+80 MHz BSS bandwidth from among the channels on which no beacons are detected during the OBSS scans, then the selected primary channel meets the following conditions: â€” It shall not be identical to the secondary 20 MHz channel of any existing BSSs with a 40 MHz, 80 MHz, 160 MHz, or 80+80 MHz BSS bandwidth. â€” It should not overlap with the secondary 40 MHz channel of any existing BSSs with a 80 MHz, 160 MHz or 80+80 MHz BSS bandwidth. A STA that is an AP or mesh STA should not start a VHT BSS with a 20 MHz BSS bandwidth on a channel that is the secondary 20 MHz channel of any existing BSSs with a 40 MHz, 80 MHz, 160 MHz, or 80+80 MHz BSS bandwidth, or is overlapped with the secondary 40 MHz channel of any existing BSSs with a 160 MHz or 80+80 MHz BSS bandwidth. NOTEâ€”An AP or a mesh STA operating a VHT BSS with a 40 MHz, 80 MHz, 160 MHz, or 80+80 MHz BSS bandwidth, on detecting an OBSS whose primary channel is the APâ€™s or the mesh STAâ€™s secondary 20 MHz channel, might switch to 20 MHz BSS operation and/or move to a different channel. 11.40.3 Scanning requirements for VHT STA An OBSS scan operation is a passive or active scan of a set of channels that are potentially affected by VHT BSS operation (see 11.1.4.1). Each channel in the set may be scanned more than once during a single OBSS scan operation. OBSS scans are performed by STAs that start a VHT BSS. During an individual scan within an OBSS scan operation, the minimum per-channel scan duration is dot11OBSSScanPassiveDwell TUs (for a passive scan) or dot11OBSSScanActiveDwell TUs (for an active scan). During an OBSS scan operation, each channel in the set is scanned at least once per dot11BSSWidthTriggerScanInterval seconds, and the minimum total scan time (i.e., the sum of the scan durations) per channel within a single OBSS scan operation is dot11OBSSScanPassiveTotalPerChannel TUs (for a passive scan) or dot11OBSSScanActiveTotalPerChannel TUs (for an active scan). NOTEâ€”The values provided in the previous paragraph are minimum requirements. For some combinations of parameter values the minimum might be exceeded for some parameters in order to meet the minimum value constraints of other parameters. 11.40.4 Channel switching methods for a VHT BSS A VHT AP announces a switch of operating channel by either of the following: â€” Using the Channel Switch Announcement element, Channel Switch Announcement frame, or both, following the procedure described in 11.9.8.2 â€” Using the Extended Channel Switch Announcement element, Extended Channel Switch Announcement frame, or both, following the procedure described in 11.10 1900 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A VHT mesh STA announces a switch attempt of operating channel by either of the following: â€” Using the Channel Switch Announcement element, Channel Switch Announcement frame, or both, following the procedure described in 11.9.8.4 â€” Using the Extended Channel Switch Announcement element, Extended Channel Switch Announcement frame, or both, following the procedure described in 11.10 A VHT AP or a VHT mesh STA may also announce a switch of BSS bandwidth, a new Country String field (possibly including a new Operating Class table number), new operating classes, or new TPC parameters for the BSS that come into effect at the same time as the switch of operating channel. The New Channel Number field in the Channel Switch Announcement element, Extended Channel Switch Announcement element, Channel Switch Announcement frame, or Extended Channel Switch Announcement frame identifies the primary 20 MHz channel after the switch. The value of the New Channel Number field is set to the value that dot11CurrentPrimaryChannel (see 21.3.14) will have after the switch. If a Channel Switch Announcement frame is used to announce a switch to a 20 MHz BSS bandwidth, then neither a Wide Bandwidth Channel Switch element nor a Secondary Channel Offset element shall be present in the frame, except that a Secondary Channel Offset element may be present in a Channel Switch Announcement frame if the Secondary Channel Offset field within the Secondary Channel Offset element is set to SCN. If a Channel Switch Announcement element is used to announce a switch to a 20 MHz BSS bandwidth, then a Wide Bandwidth Channel Switch subelement in a Channel Switch Wrapper element shall not be present in the same frame. If an Extended Channel Switch Announcement element in a Beacon or Probe Response frame or an Extended Channel Switch Announcement frame is used to announce a switch to a 20 MHz BSS bandwidth, then neither a Wide Bandwidth Channel Switch element nor a Wide Bandwidth Channel Switch subelement shall be present in the same frame. NOTEâ€”A Secondary Channel Offset element is never present with the Extended Channel Switch Announcement element or in the Extended Channel Switch Announcement frame. Instead, the indicated operating class within the Extended Channel Switch Announcement element or frame is used to differentiate between a BSS BSS bandwidth of 20 MHz and a BSS bandwidth greater than 20 MHz as well as indicate the location of the secondary 20 MHz channel. For a switch to a 20 MHz BSS bandwidth, the operating class indicated within the Extended Channel Switch Announcement element or frame has a channel spacing of 20 MHz. For a switch to an BSS bandwidth greater than 20 MHz, the operating class indicated within the Extended Channel Switch Announcement element or frame has a channel spacing of 40 MHz. If a Channel Switch Announcement frame is used to announce a switch to a 40 MHz BSS bandwidth, then the following apply: â€” The Secondary Channel Offset element shall be present in the frame. â€” The Wide Bandwidth Channel Switch shall not be present in the frame. If a Channel Switch Announcement element in a Beacon or Probe Response frame is used to announce a switch to a 40 MHz BSS bandwidth, then the Wide Bandwidth Channel Switch subelement in the Channel Switch Wrapper element shall also be present in the same frame. If an Extended Channel Switch Announcement element in a Beacon or Probe Response frame is used to announce a switch to a 40 MHz BSS bandwidth, then the Wide Bandwidth Channel Switch subelement in the Channel Switch Wrapper element may be present in the same frame. 1901 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NOTEâ€”The indicated operating class within the Extended Channel Switch Announcement element identifies the bandwidth and the relative position of the primary 20 MHz and secondary 20 MHz channels. Hence a Wide Bandwidth Channel Switch subelement is unnecessary when the Extended Channel Switch Announcement element is used for a channel switch to a 40 MHz bandwidth. If a Channel Switch Announcement frame is used to announce a switch to an 80 MHz, 80+80 MHz, or 160 MHz BSS bandwidth, then both the Secondary Channel Offset element and the Wide Bandwidth Channel Switch element shall be present in the frame. If a Channel Switch Announcement element or an Extended Channel Switch Announcement element is used to announce a switch to an 80 MHz, 80+80 MHz, or 160 MHz BSS bandwidth, then a Wide Bandwidth Channel Switch subelement in the Channel Switch Wrapper element shall be present in the same frame. If an Extended Channel Switch Announcement frame is used to announce a switch to an 80 MHz, 80+80 MHz, or 160 MHz BSS bandwidth, then the Wide Bandwidth Channel Switch element shall be present in the frame. If an Extended Channel Switch Announcement element or Extended Channel Switch Announcement frame is used to announce a switch to an 80 MHz, 80+80 MHz, or 160 MHz BSS BSS bandwidth, then â€” The value of the New Operating Class field identifies the primary 40 MHz channel, and â€” The Operating Triplet fields within the New Country subelement or element, respectively, shall indicate all of the operating classes for the switched BSS. If new BSS TPC parameters are announced that come into effect at the same time as the channel switch, then if an AP, IBSS STA or mesh STA is extended spectrum management capable, it shall include â€” At least one New Transmit Power Envelope element in a transmitted Channel Switch Announcement frame or Extended Channel Switch Announcement frame and â€” At least one New Transmit Power Envelope subelement in a transmitted Channel Wrapper element in Beacon and Probe Response frames. A recipient STA in the BSS that is extended spectrum management capable and that has dot11SpectrumManagementRequired or dot11RadioMeasurementActivated equal to true and that maintains association with the BSS after the switch shall use the parameters in these received elements and subelements in the recipient STAâ€™s TPC calculations for the new operating channel and BSS bandwidth (see 11.8). If both New Transmit Power Envelope elements and New Transmit Power Envelope subelements are transmitted for the switch, the set of New Transmit Power Envelope elements and set of subelements shall contain the same set of values for the Local Maximum Transmit Power Unit Interpretation subfield, and New Transmit Power Envelope elements and subelements that have the same value of the Local Maximum Transmit Power Unit Interpretation subfield shall also have the same values for their other fields. If a new country string, new operating classes or both, are coming into effect at the same time as the channel switch, then if an AP, IBSS STA or mesh STA is extended spectrum management capable, it shall include â€” A New Country element in a transmitted Extended Channel Switch Announcement frame and â€” A New Country subelement in a transmitted Channel Wrapper element. The New Country element or subelement shall contain all of the Operating Classes for the BSS after the switch. The New Country element or subelement, transmitted in an Extended Channel Switch Announcement frame or in the same frame as an Extended Channel Switch Announcement element, respectively, shall include one Operating Triplet field that contains the same Operating Class as the New Operating Class field in the Extended Channel Switch Announcement frame or Extended Channel Switch Announcement element. A recipient STA in the BSS that is extended spectrum management capable and that has dot11MultiDomainCapabilityActivated, dot11SpectrumManagementRequired, or dot11RadioMeasurementActivated equal to true and that maintains association with the BSS after the switch 1902 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications shall use the parameters in these received elements and subelements in order to maintain regulatory compliance. If both New Country elements and New Country subelements are transmitted for the switch, their fields shall be the same. A Channel Switch Wrapper element shall not be included in Beacon or Probe Response frames if the element contains zero subelements. NOTEâ€”Channel Switch Wrapper is not defined to carry subelements in the case of a switch to 20 MHz and when no change to the country string, operating classes or TPC parameters are announced. A VHT STA uses only the Transmit Power Envelope element, not the Power Constraint element, for TPC of 80 MHz, 160 MHz, and 80+80 MHz transmissions. In the Country element, a VHT STA shall include zero Subband Triplet fields in an Operating/Subband Sequence field that contains an Operating Class field for which the â€œChannel Spacing (MHz)â€ column in the applicable table in Annex E equals 80 or 160. An AP that switches the BSS to a lower BSS bandwidth may recalculate the TS bandwidth budget and may delete one or more active TSs by invoking the MLME-DELTS.request primitive with a ReasonCode value of SERVICE_CHANGE_PRECLUDES_TS. A VHT STA that is a member of an IBSS shall not transmit values in the Wide Bandwidth Channel Switch element that change the frequency ordering of the primary 40 MHz channel and the secondary 40 MHz channel from the ordering of the most recently adopted operating channel, if the operating channel includes a secondary 40 MHz channel. A VHT STA that is a member of an IBSS shall not transmit values in the Wide Bandwidth Channel Switch element that change the frequency ordering of the primary 80 MHz channel and the secondary 80 MHz channel from the ordering of the most recently adopted operating channel, if the operating channel includes a secondary 80 MHz channel. 11.40.5 NAV assertion in a VHT BSS A VHT STA shall update its NAV as described in 10.3.2.4 using the Duration/ID field value in any frame that does not have an RA matching the STAâ€™s MAC address and that was received in a 20 MHz PPDU in the primary 20 MHz channel or received in a 40 MHz PPDU in the primary 40 MHz channel or received in an 80 MHz PPDU in the primary 80 MHz channel or received in a 160 MHz or 80+80 MHz PPDU. NOTEâ€”The PHY might filter out a PPDU as described in 21.3.20 or not receive a PPDU due to VHT TXOP power saving described in 11.2.3.19. If so, frames in the PPDU are not received by the MAC and have no effect on the NAV. 11.40.6 VHT STA antenna indication A VHT STA that does not change its Rx antenna pattern after association shall set the Rx Antenna Pattern Consistency subfield in the VHT Capabilities Information field to 1; otherwise, the STA shall set the Rx Antenna Pattern Consistency subfield in the VHT Capabilities Information field to 0. A VHT STA that does not change its Tx antenna pattern after association shall set the Tx Antenna Pattern Consistency subfield in the VHT Capabilities Information field to 1; otherwise, the STA shall set the Tx Antenna Pattern Consistency subfield in the VHT Capabilities Information field to 0. 11.40.7 Basic VHT-MCS and NSS set operation The basic VHT-MCS and NSS set is the set of tuples that are supported by all VHT STAs that are members of a VHT BSS. It is established by the STA that starts the VHT BSS, indicated by the Basic VHT-MCS And NSS Set field of the VHT Operation parameter in the MLME-START.request primitive. Other VHT STAs determine the basic VHT-MCS and NSS set from the Basic VHT-MCS And NSS Set field of the VHT Operation element in the BSSDescription derived through the scan mechanism (see 11.1.4.1). 1903 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A VHT STA shall not attempt to join (MLME-JOIN.request primitive) a BSS unless it supports (i.e., is able to both transmit and receive using) all of the tuples in the basic VHT-MCS and NSS set. NOTEâ€”A VHT STA does not attempt to (re)associate with a VHT AP unless the STA supports (i.e., is able to both transmit and receive using) all of the tuples in the Basic VHT-MCS And NSS Set field in the VHT Operation element transmitted by the AP because the MLME-JOIN.request primitive is a necessary precursor to (re)association. 11.40.8 Extended NSS BW Support Signaling If dot11VHTExtendedNSSBWCapable is false, a STA shall set the Extended NSS BW Support subfield of the VHT Capabilities Information field to 0 in VHT Capability elements that it transmits, otherwise, the subfield may be set to 1, 2 or 3 as indicated in 9.4.2.158.2. If dot11VHTExtendedNSSBWCapable is false, a STA shall set the VHT Extended NSS BW Capable subfield of the Supported VHT-MCS and NSS Set field to 0 in VHT Capability elements that it transmits, otherwise, the subfield shall be set to 1. 11.41 Group ID management operation An AP determines the possible combinations of STAs that can be addressed by a VHT MU PPDU by assigning STAs to groups and to specific user positions within those groups. Assignments or changes of user positions corresponding to one or more Group IDs shall be performed using a Group ID Management frame defined in 9.6.23.3. A STA may be assigned to multiple groups by setting multiple subfields of the Membership Status Array field (see 9.4.1.54) to 1 in the Group ID Management frame addressed to that STA. A STAâ€™s user position in each group of which the STA is a member is indicated by the associated subfield in the User Position Array field (see 9.4.1.55) in the Group ID Management frame addressed to the STA. For each Group ID, an AP may assign the same user position to multiple STAs. A STA shall have only one user position in each group of which the STA is a member. An AP may transmit a Group ID Management frame only if dot11VHTOptionImplemented is true. A Group ID Management frame shall not be sent to a VHT STA that does not have the MU Beamformee Capable field in the VHT Capabilities element equal to 1. A Group ID Management frame shall be sent as an individually addressed frame. A STAâ€™s MLME that receives a Group ID Management frame with a RA matching its MAC address shall issue a PHYCONFIG_VECTOR primitive with the GROUP_ID_MANAGEMENT parameter based on the content of the received Group ID Management frame in order to configure the following lookup tables in the PHY: a) group ID to Membership Status, denoted by MembershipStatusInGroupID[g] for 1 g 62 b) group ID to User Position, denoted by UserPositionInGroupID[g] for 1 g 62 Group ID values of 0 and 63 are used for SU PPDU and the PHY filtering of such PPDUs is controlled by the PHYCONFIG_VECTOR primitive LISTEN_TO_GID00 and LISTEN_TO_GID63 parameters. The User Position in Group ID information is interpreted by a STA receiving a VHT MU PPDU as explained in 21.3.11.4. Transmission of a Group ID Management frame to a STA and any associated acknowledgment from the STA shall complete before the transmission of a VHT MU PPDU to the STA. 1904 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A VHT MU PPDU shall be transmitted to a STA based on the content of the Group ID Management frame most recently transmitted to the STA and for which an acknowledgment was received. 11.42 Notification of operating mode changes A STA in which dot11OperatingModeNotificationImplemented is true shall set the Operating Mode Notification field in the Extended Capabilities element to 1. A VHT STA shall set dot11OperatingModeNotificationImplemented to true. A STA in which dot11OperatingModeNotificationImplemented is true is referred to as operating mode notification capable. A STA that is operating mode notification capable and that transmits an Association Request, Reassociation Request, TDLS Setup Response, TDLS Setup Confirm, Mesh Peering Open, or Mesh Peering Confirm frame to a STA that is operating mode notification capable should notify the recipient STA of a change in its operating mode by including the Operating Mode Notification element in the frame. A first STA that is operating mode notification capable should notify a second STA that is operating mode notification capable of a change in its operating mode by transmitting an Operating Mode Notification frame to the second STA if the first STA has established any of the following with a second STA: â€” An association with an AP â€” A TDLS link â€” A DLS link â€” A Mesh Peer relationship NOTEâ€”Notify Channel Width frames and elements are used to signal STA operating channel width changes to and from STAs that are not operating mode notification capable. The Operating Mode field in the Operating Mode Notification frame or the Operating Mode Notification element together with the Supported Channel Width set field and the Extended NSS BW Support field of the VHT Capabilities element indicates the transmitting STAâ€™s receive bandwidth and NSS capabilities. See 10.7.12.1. The notification of a change in supported spatial streams should occur prior to a decrease in the maximum number of spatial streams and following an increase in the maximum number of spatial streams. The notification of a change in operating bandwidth should occur prior to a decrease in the operating channel width and following an increase in the operating channel width. A STA shall not transmit an individually addressed frame that contains the Operating Mode field unless the recipient is operating mode notification capable. An AP should notify associated STAs of a change in the maximum number of spatial streams it is able to receive through one or more of the following mechanisms: â€” Using individually addressed Operating Mode Notification frames â€” Including the Operating Mode Notification element in Beacon frames for a period of time to allow STAs in PS mode to receive the notification NOTEâ€”An AP cannot change the maximum number of spatial streams it is able to receive from HT STAs that are not operating mode notification capable. The notification should occur prior to a decrease in the maximum number of spatial streams and following an increase in the maximum number of spatial streams. 1905 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications An AP should notify associated STAs of a change in its operating channel width through one or more of the following mechanisms: â€” Using the Channel Switch Announcement element, Channel Switch Announcement frame or both following the procedure defined in 11.9.8.2 â€” Using the Extended Channel Switch Announcement element, Extended Channel Switch Announcement frame or both, following the procedure described in 11.10 â€” Using individually addressed Operating Mode Notification frames and/or Notify Channel Width frames â€” Using the STA Channel Width field in the HT Operation element and/or Channel Width field in the VHT Operation element The notification should occur prior to a decrease in the operating channel width and following an increase in the operating channel width. A VHT AP that has at least one VHT STA associated and that indicates a channel width change using management action frame(s) shall transmit Operating Mode Notification frame(s) to signal the channel width change. A VHT AP that has at least one non-VHT HT STA associated and that indicates a channel width change using management action frame(s) shall transmit Notify Channel Width frame(s) to signal the channel width change. A VHT STA shall not transmit an individually addressed Notify Channel Width frame to a VHT STA. A VHT STA associated with a VHT AP shall ignore Notify Channel Width frames received from the VHT AP. An HT AP that is not a VHT AP that changes its operating channel width shall indicate the new operating channel width in the STA Channel Width field in the HT Operation element. A VHT AP that changes its operating channel width shall indicate the new operating channel width in the Channel Width field in the VHT Operation element and STA Channel Width field in the HT Operation element (see Table 11-24). An AP shall not include the Operating Mode Notification element in Beacon, Probe Response, Association Response, and Reassociation Response frames when not changing the maximum number of spatial streams the AP is able to receive. A STA shall not transmit an Operating Mode field with the value of the Rx NSS subfield indicating a number of spatial streams not supported by the recipient STA. The number of spatial streams supported by the recipient STA is reported in the Supported Rates and BSS Membership Selectors element, Extended Supported Rates and BSS Membership Selectors element, Supported MCS Set, or Supported VHT-MCS and NSS Set field transmitted in Management frames by the recipient STA. A STA shall not transmit an Operating Mode field with the value of the Channel Width subfield indicating a bandwidth not supported by the STA, as reported in the Supported Channel Width Set subfield in the HT Capability Information field or in the VHT Capabilities Information field in Management frames transmitted by the STA. A STA that is operating mode notification capable shall not transmit a PPDU to a STA that uses a bandwidth that is greater than the channel width indicated in the most recently received Operating Mode Notification element or Operating Mode Notification frame from that STA. A STA that is operating mode notification capable shall not transmit a PPDU to a STA that uses a greater number of spatial streams than indicated in the most recently received Operating Mode Notification element or Operating Mode Notification frame received from that STA. NOTE 1â€”The number of spatial streams might be further restricted if the receiving STA is in SM power save mode (see 11.2.6). 1906 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NOTE 2â€”To avoid possible frame loss, a VHT STA that sends an individually addressed Operating Mode Notification frame to a second VHT STA indicating reduced operating channel width and/or reduced active receive chains can continue with its current operating channel width and active receive chains until it infers that the second STA has processed this notification. The first VHT STA might make this inference from either of the following: â€” By receiving a frame addressed to itself from the second VHT STA in a PPDU with a bandwidth and NSS that are less than or equal to the channel width and NSS, respectively, indicated in the Operating Mode Notification frame â€” Based on the passage of time in some implementation dependent way, which is outside the scope of this standard NOTE 3â€”It might take a long time for a STA to change its operating mode following the transmission of the Operating Mode Notification frame and during that time the STA might not be able to receive frames resulting in frame loss. If a non-AP STA cannot tolerate frame loss during that period it can set the Power Management subfield of the Frame Control field of the Operating Mode Notification frame to 1 to indicate that the STA has entered power save. When the non-AP STA has completed its operating mode change, it can send another frame (such as a QoS Null) with the Frame Control Power Management subfield set to 0 to indicate that the STA has exited power save. 11.43 Basic TVHT BSS functionality The STA that is creating a TVHT BSS shall be able to receive and transmit at each of the tuple values indicated by the Basic VHT-MCS And NSS Set field of the VHT Operation parameter of the MLME-START.request primitive and shall be able to receive at each of the tuple values indicated by the Supported VHT-MCS and NSS Set field of the VHT Capabilities parameter of the MLME-START.request primitive. A STA for which dot11TVHTOptionImplemented is true shall set dot11VHTOptionImplemented to true. A TVHT AP declares its channel width capability in the VHT Capabilities element VHT Capabilities Information field, as defined in 9.4.2.158. A TVHT AP shall set the Channel Width subfield in the TVHT Operation Information field to indicate the BSS bandwidth and transmitted PPDU type as defined in Table 11-27. Table 11-27â€”TVHT BSS bandwidth TVHT Operation element Channel Width BSS bandwidth PPDU type field 0 TVHT_W TVHT_MODE_1 1 TVHT_2W TVHT_MODE_1 TVHT_MODE_2C 2 TVHT_W+W TVHT_MODE_1 TVHT_MODE_2N 3 TVHT_4W TVHT_MODE_1 TVHT_MODE_2C TVHT_MODE_4C 4 TVHT_2W+2W TVHT_MODE_1 TVHT_MODE_2C TVHT_MODE_4N 1907 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A TVHT non-AP STA that receives a frame containing a TVHT Operation element shall determine the channelization based on the Channel Center Frequency Segment0, Channel Center Frequency Segment1, and Primary Channel Number subfields of the TVHT Operation Information field (see 22.3.14). A TVHT STA that is a member of a TVHT BSS shall transmit a TVHT_MODE_1 PPDU only on the primary TVHT_W channel, except for a TVHT_MODE_1 PPDU transmission on an off-channel TDLS direct link. A TVHT STA that is a member of a TVHT BSS with a TVHT_2W, TVHT_4W, or TVHT_W+W BSS bandwidth shall not transmit a TVHT_MODE_2C or TVHT_MODE_2N PPDU that does not use the primary TVHT_W channel and the secondary TVHT_W channel, except for a TVHT_MODE_2C, TVHT_MODE_4C, or TVHT_MODE_2N PPDU transmission on an off-channel TDLS direct link. A TVHT STA that is a member of a TVHT BSS with a TVHT_4W or TVHT_2W+2W BSS bandwidth shall not transmit a TVHT_MODE_4C or TVHT_MODE_4N PPDU that does not use the primary TVHT_2W channel and the secondary TVHT_2W channel, except for a TVHT_MODE_4C or TVHT_MODE_4N PPDU transmission on an off-channel TDLS direct link. A TVHT STA shall not transmit to a TVHT STA using a bandwidth that is not indicated as supported in the VHT Capabilities element or Operating Mode Notification frame recently received from that TVHT STA. In a TVHT BSS, the primary TVHT_W channel is the primary channel. 11.44 Operation under the control of a GDB 11.44.1 General When a STA implements support for one or more of the procedures described in this subclause, it shall set dot11TVHTOptionImplemented to true. When dot11TVHTOptionImplemented is true and a STA is initialized for operation in a band that requires GDB control, then dot11GDDActivated shall be true. In some regulatory domains, STAs shall consult a GDB to determine permissible operating frequencies and parameters before transmitting. Such STAs may operate as geolocation database dependent (GDD) enabling STAs, which are required by regulation to provide their identification, geolocation, and other information to the GDB as specified by regulatory authorities. Other STAs are permitted to transmit when enabled by a GDD enabling STA. Such STAs operate as GDD dependent STAs. Subclause 11.44 describes procedures for STAs when they are operating under the control of a GDB to satisfy regulatory requirements. For operation under such restrictions, GDD dependent STAs operate according to the control procedures of a GDD enabling STA that enables their operation. The frame exchange sequence between GDD enabling STA and GDD dependent STAs for enabling their operation occurs in State 4 (see 11.3.1). A GDD enabling STA is a STA that is able to access a GDB and to obtain the information about the permitted frequencies and other information for use in its location. A GDD enabling STA or geolocated non- AP STA populates its dot11STALCITable with location information by a means that has received regulatory approval and is outside the scope of this standard. When location information is set in dot11STALCITable, 1908 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications the STA sets dot11GeolocationCapabilityActivated. The current dot11STALCITable allows management access to the location information that is the basis for operation. A GDD enabling STA may transmit a GDD enabling signal and may enable operations of GDD dependent STAs. A GDD dependent STA is a STA that is under the control of a GDD enabling STA. The GDD enablement procedure for GDD dependent STAs and the operating rules for GDD enabling and GDD dependent STAs are defined in the following subclauses. 11.44.2 GDD enabling STA operation A GDD enabling STA may transmit a GDD enabling signal in-band on an available frequency to indicate that it offers GDD enablement service. The GDD enabling signal is a Beacon frame with an Extended Capabilities element that contains a Geodatabase Inband Enabling Signal field with a value of â€˜1â€™. A GDD dependent STA shall not transmit any frames before it receives a GDD enabling signal over the air directly from a GDD enabling STA. In some regulatory domains the GDD enabling STA may be required to have secure authentication or association with the GDD dependent STA before it sends the GDD Enablement Response frame. If required by regulation, the GDD enabling STA may contact a GDB to verify that the requesting GDD dependent STA is authorized to operate in the frequency band. Upon receipt of a GDD Enablement Request frame from a GDD dependent STA, the GDD enabling STA sends a GDD Enablement Response frame with either of the following results: a) The Status Code field set to SUCCESS to indicate the successful enablement of the requesting GDD dependent STA b) The Status Code field set to ENABLEMENT DENIED or INVALID_PARAMETERS or RESTRICTION FROM AUTHORIZED GDB, in which case the GDD enablement request has been denied A GDD enabling STA may issue an unsolicited GDD Enablement Response frame with a Status Code AUTHORIZATION DEENABLED to notify a GDD dependent STA to cease its transmissions and change its GDD enablement state to Unenabled. When an unsolicited GDD Enablement Response frame with a Status Code AUTHORIZATION DEENABLED is transmitted, the WSM element is not included. 11.44.3 GDD dependent STA operation A GDD dependent STA is configured with a GDD enablement state variable which is set to one of the following three states: Unenabled, AttemptingGDDEnablement, or GDDEnabled. A GDD dependent STA begins operation by setting its GDD enablement state variable to Unenabled and operates in receive-only mode within the band, passively scanning channels for a GDD enabling signal from a GDD enabling STA. A typical state machine implementation of GDD dependent STA operation under GDD is provided in Figure 11-53. 1909 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Unenabled Receive GDD enabling signal and Wait for transmit GDD Enablement Request frame dot11GDDEnablementFailHoldTime Receive GDD Enablement Response frame with Status AttemptingGDDEnablement ENABLEMENT DENIED, RESTRICTION FROM AUTHORIZED GDB, INVALID_PARAMETERS, or otherwise failed enablement attempt within dot11GDDEnablementTimeLimit Receive GDD Enablement Response frame with Status Code SUCCESS Receive GDD Enablement Response frame with Status Code AUTHORIZATION DEENABLED dot11GDDEnablementValidityTimer has expired GDDEnabled Figure 11-53â€”GDD dependent STA state transition diagram A GDD dependent STA shall not transmit any frames unless it has received a valid GDD enabling signal from a GDD enabling STA. A GDD dependent STA that is able to receive a valid GDD enabling signal, but has not been enabled by a GDD enabling STA shall not transmit, except to perform GDD enablement with a GDD enabling STA transmitting the GDD enabling signal. A GDD dependent STA shall not transmit any frames other than GDD enablement-related frames and authentication and association frames before it performs the following GDD enablement procedure: a) The GDD dependent STA changes its GDD enablement state variable to AttemptingGDDEnablement after receiving a GDD enabling signal. b) After authentication and association, the GDD dependent STA securely sends a GDD Enablement Request frame to a GDD enabling STA from which it has received a GDD enabling signal. Based on the input received from the GDD dependent STA, the GDD enabling STA responds with a GDD Enablement Response frame indicating the result for the enablement request. c) When a GDD dependent STA receives a GDD Enablement Response frame with the Status Code SUCCESS within dot11GDDEnablementTimeLimit, the GDD enablement state variable of the GDD dependent STA is set to GDDEnabled. Once it becomes enabled, the GDD dependent STA maintains a GDD enablement validity timer, which is initialized to dot11ContactVerificationSignalInterval. 1910 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A GDD dependent STA that has not attained GDD enablement from a GDD enabling STA shall not transmit beyond dot11GDDEnablementTimeLimit, measured from the time of the first PHY-TXSTART.request primitive, while attempting to attain GDD enablement. Then, when the GDD enablement attempt fails within the allowed maximum time, it shall not transmit for dot11GDDEnablementFailHoldTime, before it may again attempt to attain GDD enablement. NOTEâ€”A GDD dependent STA might detect several GDD enabling STAs. If the GDD dependent STA is unable to obtain a GDD Enablement Response frame from one GDD enabling STA, it might make further attempts with additional GDD enabling STAs within the maximum time limit of dot11GDDEnablementTimeLimit. Once in GDDEnabled state, the following rules apply to a GDD dependent STA during its operations: â€” The GDD dependent STA shall maintain a GDD enablement validity timer by decrementing dot11GDDEnablementValidityTimer. The procedures for maintaining the GDD enablement validity timer are defined in 11.44.9, 11.44.6, and 11.44.4. â€” A GDD dependent STA shall cease all transmission when the dot11GDDEnablementValidityTimer has expired. It then changes its GDD enablement state to Unenabled. â€” A GDD dependent STA shall immediately cease all transmission if it receives an unsolicited GDD Enablement Response frame with a Status Code of AUTHORIZATION DEENABLED from the GDD enabling STA that enabled its operation. 11.44.4 Channel availability query (CAQ) procedure 11.44.4.1 Introduction This subclause describes a channel availability query procedure that can be used to obtain the list of available channels for the operation of a GDD STA. A STA shall not use the CAQ procedure specified here unless dot11GDDActivated is true. A GDD dependent STA sends the channel availability query request to a GDD enabling STA to obtain the list of available channels. The CAQ procedure might be initiated by the GDD dependent STA in order to remain in the GDDEnabled state during its normal operational mode, as specified in 11.44.3. The GDD dependent STA sends the Channel Availability Query frame to obtain the new channel availability information when it receives an indication of change in the available channel list for its use, such as from a recent CVS signal (see 11.44.6). Once the GDD dependent STA successfully receives the response for its Channel Availability Query frame from the GDD enabling STA, it reinitializes the dot11GDDEnablementValidityTimer to dot11ContactVerificationSignalInterval. A GDD STA that acquires its geolocation position with the accuracy required by the regulatory domain sets dot11GeolocationCapabilityActivated to true. Any STA that operates as a GDD enabling STA might have its geolocation position before it initiates the CAQ procedure. Such a STA might transmit a channel availability query request to another GDD enabling STA. The responding STA generates the CAQ response after communicating to the RLSS, if the Channel Availability Query frame was received in a Channel Availability Query RLQP-element. NOTEâ€”A GDD enabling STA can send the Channel Availability Query frame to another GDD enabling STA. The responding GDD enabling STA, in such a case, can contact a GDB with the location and identifying parameters sent by the requesting STA. A GDD enabling STA performs the CAQ procedure to update its channel availability when it determines that its geolocation position has moved beyond the permitted distance or beyond the validity time since its last query, as required by regulation. 1911 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STAs might transmit a channel availability query request in the protected dual of a CAQ Public Action frame (see 9.6.8.25, or in a GAS Initial Request frame containing an Channel Availability Query RLQP- element (see 9.4.6.2). The procedures for channel availability query requesting STA and channel availability query responding STA are specified in 11.44.4.2 and 11.44.4.3. In some regulatory domains, CAQ procedures may be conducted in other bands with properly implemented security to meet regulatory requirements. In such cases, CAQ RLQP rather than CAQ protected duals of Public Action frames shall be used. 11.44.4.2 CAQ requesting STA A GDD dependent STA or a GDD enabling STA may initiate a CAQ procedure as a CAQ requesting STA. A CAQ requesting STA may use RLQP to transmit a CAQ request when it detects RLQP support by its intended CAQ responder in a Beacon or Probe Response frame and to transmit a CAQ request to a STA with which it is associated when the requesting STA detects RLQP support. Upon receipt of the MLME-GAS.request primitive with an AdvertisementProtocolID value of RLQP and Query parameters with the values of the fields in the RLQP Channel Availability Query element, the requesting STA performs the procedure specified in 11.25.3.2.2 to transmit a GAS Initial Request frame that contains the Channel Availability Query RLQP-element. The specific information items in the Query Request field of the GAS Initial Request frame are defined in 9.4.6.2. The CAQ requesting STA may send the protected dual of a Channel Availability Query frame where the CAQ responding STA does not support RLQP capability. Upon receipt of the MLME- CHANNELAVAILABILITYQUERY.request primitive with Reason Result Code of 1, the MLME schedules for transmission a Channel Availability Query frame. The specific information items in the protected dual of a CAQ Public Action are defined in 9.6.8.25. The CAQ requesting STA sets the Reason Result Code field to 1 and provides the Query Info field, as shown in Figure 9-631, to indicate if the Device Identification or Location Information fields are included in the Channel Availability Query frame. A GDD enabling STA sending the Channel Availability Query frame should provide its device identification information in a format specified in 9.4.4.2.2. A GDD enabling STA with dot11GeolocationCapabilityActivated equal to true should provide one or more Location Information fields in its Channel Availability Query frame. A CAQ requesting STA may request a common channel list applicable to a bounded geographic area by providing more than one Device Location Information field in the Channel Availability Query frame. The bounded geographic area is defined by the area surrounded by the given sets of geographic coordinates in the multiple Device Location Information fields. 11.44.4.3 CAQ responding STA A GDD enabling STA that receives the Channel Availability Query frame performs the role of the CAQ responding STA. 1912 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications When a GDD enabling STA that has dot11RLSSActivated true receives a Channel Availability Query RLQP-element request, it generates and transmits the Channel Availability Query RLQP-element response to the requesting STA. Upon receipt of the MLME-GAS.response primitive with ResponseInfo parameter having a value of the corresponding field in the CAQ element, the responding STA transmits a Channel Availability Query RLQP-element response. The CAQ responding STA generates the response to the CAQ requesting STA based on the result obtained from the RLSS. The specific information items in the Channel Availability Query RLQP-element response are defined in 9.4.6.2 and are set as follows: â€” Requester STA Address field set to the MAC address of the STA from which the query was received. â€” If no security method is enabled on the connection between the CAQ requesting STA and the CAQ responding STA, the Reason Result Code field is set to 4 (REFUSED). â€” Reason Result Code field set to 2 or 3 for successful result or to 4 or 5 for failure, as defined in 9.4.6.2. â€” WSM Information field, as defined in 9.4.4.2.5 when the Reason Result Code is set to 2 or 3. NOTEâ€”For the CAQ process, the RLSS provides the list of available channels for the location(s) provided by the requesting STA in the Query Response. In some regulatory domains, the RLSS can perform access to a GDB to derive its response for channel query request and the associated information it provides in its Query Response. A CAQ responding STA might receive a Channel Availability Query frame or its protected dual. Upon receipt of the MLME-CHANNELAVAILABILITYQUERY.response primitive, the MLME schedules for transmission of the response in a Channel Availability Query frame. The Channel Availability Query frame or its protected dual is generated based on the ResultCode and other parameters received from the SME for the Channel Availability Query frame, as follows: â€” Requester STA Address field set to the value of the PeerSTAAddress parameter. â€” If no security method is enabled on the connection between the CAQ framing STA and the CAQ responding STA, the Reason Result Code field is set to 4 (REFUSED). â€” Reason Result Code field set to 2 or 3 for successful result or to 4 or 5 for failure, as defined in 9.4.6.2. â€” WSM Information field, as defined in 9.4.4.2.5 when the Reason Result Code is set to 2 or 3. When a CAQ Responding STA receives the Channel Availability Query frame from a GDD dependent STA, it sets the Reason Result Code field to 2 when the query is successful and provides the WSM information it has obtained for its own location. When a CAQ Responding STA receives the Channel Availability Query frame from another GDD enabling STA that includes one or more Device Location Information fields in the Channel Availability Query frame, it sets the Reason Result Code field to 2 or 3 when the query is successful and provides the WSM information that is valid for the location of the requesting STA. When the Channel Availability Query frame contains multiple Device Location Information fields, the WSM information in the CAQ response is applicable for any location within the bounded area defined by the multiple locations. When the Channel Availability Query frame contains two Device Location Information fields, the WSM information in the CAQ response is applicable for any location within the bounded area determined by the uncertainty values of the coordinates of the second Device Location Information field. If no common channels are available to the bounded geographic area defined by multiple locations, CAQ responding STA responds with Reason Result Code field set to 2 (Success with the available 1913 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications channel list result for Device Location Information field) and WSM information applicable to the first Device Location Information field in the Channel Availability Query frame. If one or more common channels are available to the bounded geographic area defined by multiple locations, the CAQ responding STA responds with Reason Result Code field set to 3 (Success with an available channel list result for a bounded geographic area defined by multiple Device Location Information fields) and a corresponding WSM Information field. When a CAQ responding STA receives the protected Channel Availability Query frame, the response shall be sent using the protected Channel Availability Query frame. 11.44.5 Channel schedule management (CSM) procedures 11.44.5.1 Introduction This subclause describes a channel schedule management procedure that can be used to obtain the list of available channels for the operation of a GDD STA. STAs can use the CSM procedure specified here when dot11GDDActivated is true. Upon receipt of MLME-CHANNELSCHEDULEMANAGEMENT.request primitive, the MLME schedules transmission for a CSM request frame. If the parameter Protected of the MLME- CHANNELSCHEDULEMANAGEMENT.request primitive has the value true, then the CSM request frame as defined in 9.6.8.26 is transmitted in a Protected Dual of Public Action frame; otherwise the CSM request frame is transmitted in a Public Action frame. Upon receipt of MLME-GAS.request primitive with an AdvertisementProtocolID parameter value of RLQP and Query parameter for a Channel Schedule Management RLQP-element, the requesting STA performs the procedure specified in 11.25.3.2.2 to transmit a GAS Initial Request frame that contains the Channel Schedule Management RLQP-element. A GDD enabling STA transmits a CSM request to a RLSS to query the schedule information on TV channels. By default, a RLSS is able to provide channel schedule information on TV channels. However, the RLSS may reject the request by responding with Reason Result Code field set to the value for â€œRequest declined by RLSS for unspecified reason.â€ A GDD enabling STA transmits a CSM request to a RLSS to query the schedule information on WLAN channels. The RLSS maps channel schedule information from TV channels to WLAN channels and provides the schedule information, as defined in 9.4.4.2.4, to the GDD enabling STA that sent the query to facilitate WLAN operation. A RLSS that is not capable of providing WLAN channel schedule information responds to a request using the CSM response with the Reason Result Code field set to the value for â€œRequest declined by RLSS because of no capability for providing schedule information on WLAN channels.â€ A GDD enabling STA transmits a CSM request to another GDD enabling STA that is capable of database access as indicated in the GDD enabling signal. The GDD enabling STA that is capable of database access is able to access the RLSS and obtain the channel schedule information on TV channels. The GDD enabling STA may respond to a request by sending the CSM response with Reason Result Code field set to the value for â€œRequest Declined by the GDD enabling STA because of no capability for providing schedule information on WLAN channels.â€ A GDD enabling STA may transmit a CSM request to query WLAN channel information from another GDD enabling STA. A GDD enabling STA responds to a CSM request using a CSM response with the Reason Result Code field set to the value for â€œSuccessâ€ if it is capable of providing channel schedule information on WLAN channels obtained from a RLSS and responds with the Reason Result Code field set 1914 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications to the value for â€œRequest declined by the GDD enabling STA because of no capability for providing schedule information on WLAN channels,â€ otherwise. When the information in a CSM response is identical to the information in the most recently transmitted CSM response to the same requesting STA, the responding STA can set the Reason Result Code field value CSM element in a query response to â€œSuccessfulâ€ with no channel schedule changes from the last query of the RLSS and omit both the Channel Schedule Management Mode and Channel Schedule Descriptor fields. A GDD enabling STA with dot11ChannelScheduleManagementActivated true may send a CSM frame to update the channel schedule information of another GDD enabling STA that receives an available channel list from it. The GDD dependent STA shall not transmit a CSM request. The details of requesting and responding with CSM are provided in 11.44.5.2 and 11.44.5.3. 11.44.5.2 CSM requesting STA A STA employing RLQP uses the GAS protocol for its CSM procedure with a RLSS. Upon receipt of the MLME-GAS.request primitive with an AdvertisementProtocolID value of RLQP and Query parameter with the value of Channel Schedule Management RLQP-element, the CSM requesting STA transmits an RLQP- element with RLQP ID for CSM in the Query Request field in a GAS Initial Request frame. The specific information items in the Query Request field of the GAS Initial Request frame are generated as follows: â€” Reason Result Code field = 0 or 1 as defined in 9.6.8.26. â€” Channel Schedule Management Mode field = 0 or 1 as defined in 9.6.8.26. â€” Channel Schedule Descriptor field, as defined in 9.4.4.2.4, containing the channel that the STA wants to query. A STA uses the CSM Public Action frame or its protected dual to query another STA for channel schedule information. Upon receipt of the MLME-CHANNELSCHEDULEMANAGEMENT.request primitive with the CSM parameter of CSM element, the requesting STA transmits a CSM frame. The request frame is generated as follows: â€” Reason Result Code field = 0 or 1 as defined in 9.6.8.26. â€” Channel Schedule Management Mode field = 0 or 1 as defined in 9.6.8.26. â€” Channel Schedule Descriptor field, as defined in 9.4.4.2.4, contains only the channel that the STA wants to query. 11.44.5.3 CSM responding STA A STA employing RLQP uses the GAS protocol for its CSM procedure with a RLSS. Upon receipt of the MLME-GAS.request primitive with an ResponseInfo parameter value of Channel Schedule Management RLQP-element, the CSM responding STA transmits a RLQP-element with RLQP ID for CSM in the Query Response field in a GAS Initial Response frame or one or more GAS Comeback Response frames. The responding RLQP CSM shall be transmitted in a Protected Dual of Public Action frame if the received CSM is protected. The specific information items in the Query Response field of the GAS Initial Response frame are generated as follows: â€” Reason Result Code field = values 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, or 12 as defined in 9.6.8.26. â€” Channel Schedule Descriptor field, as defined in 9.4.4.2.4, contains the channel and related channel schedule information. 1915 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A STA uses CSM Public Action frame or its protected dual to respond to another STA with channel schedule information. Upon receipt of the MLME-CHANNELSCHEDULEMANAGEMENT.request primitive with CSM parameter value of CSM element, the CSM responding STA transmits a CSM frame in response. The responding CSM shall be transmitted in a Protected Dual of Public Action frame if the received CSM is protected. The CSM response frame is generated as follows: â€” Reason result code field = values 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, or 12 as defined in 9.6.8.26. â€” Channel Schedule Descriptor field, as defined in 9.4.4.2.4, contains the channel and related channel schedule information. 11.44.6 Contact verification signal (CVS) The Contact Verification Signal frame is transmitted by a GDD enabling STA to establish that its GDD dependent STAs are within the reception range of the GDD enabling STA and to validate the available channel list. A GDD enabling STA with dot11ContactVerificationSignalActivated true shall transmit an individually addressed Protected CVS frame (see 9.6.8.27) to its GDD dependent STAs. A GDD dependent STA receives a CVS frame transmitted from its GDD enabling STA that provided the WSMs to verify that it is within reception range of that GDD enabling STA. The CVS frame has a Map ID field that indicates whether the WSM has been changed. A GDD dependent STA compares values of the Map ID field in the CVS frame with the Map ID of its existing WSM. If they are the same, then the GDD dependent STA assumes that its WSM is valid, and it sets dot11GDDEnablementValidTimer equal to dot11ContactVerificationSignalInterval. If they are different, the WSM is invalid because WSM information has changed. The STA should transmit a Channel Availability Query frame and receive a response in a Channel Availability Query frame that contains an updated WSM. If the GDD dependent STA fails to retrieve the updated WSM, it shall change its GDD enablement state to unenabled and stop transmitting over the air after dot11GDDEnablementValidTimer has expired. 11.44.7 Network channel control (NCC) procedures 11.44.7.1 Introduction This subclause describes network channel control procedures that can be used to manage channels for operation of a GDD STA. A STA may use the NCC procedures specified here when dot11GDDActivated is true. Network channel control utilizes a two-message transaction sequence to allow an NCC responding STA to control the frequency usage in TV bands of an NCC requesting STAâ€™s WLAN network channels. The first MMPDU sent by the NCC requesting STA asserts identity and requests NCC information. The NCC requesting STA may select its preferred frequencies from its WSM and request usage. The MMPDU sent by the NCC responding STA returns the NCC result. The NCC responding STA might grant permission to use the selected frequencies for multiple WLAN network channels to the NCC requesting STA by responding with a Network Channel Control frame (see 9.6.8.30). When responding, the NCC responding STA provides the confirmed WLAN network channels and the transmit power constraints as well. The WLAN network channels that the NCC responding STA confirms might be the same as or a subset of the network channels listed in the Network Channel Control frame received from the NCC requesting STA. An NCC requesting STA employing RLQP may send an Network Channel Control frame to the RLSS to request its preferred frequencies given by the WSM for WLAN network channels. The NCC requesting STA accomplishes this by transmitting an RLQP-element with the RLQP ID for NCC in the Query Request field in a GAS Initial Request frame. After it receives this frame the NCC responding STA forwards the NCC request to the RLSS. After receiving the NCC request, the RLSS responds and sends an NCC response via 1916 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications the NCC responding STA to the NCC requesting STA. When responding, the RLSS also provides the confirmed WLAN network channels and the transmit power constraints. The WLAN network channels that the RLSS confirms might be the same as or a subset of the network channels listed in the Network Channel Control request frame received from the NCC requesting STA. Whenever the WSM has changed due to the update of the database information or detection of the primary service signals, an NCC requesting STAs may transmit a new Network Channel Control frame. 11.44.7.2 NCC requesting STA An NCC requesting STA may be a GDD dependent STA. An NCC requesting STA employing RLQP may use the GAS protocol for its NCC procedure with a RLSS. Upon receipt of the MLME-GAS.request primitive with an AdvertisementProtocolID value of RLQP and Query parameter with the value of Network Channel Control RLQP-element, the NCC requesting STA transmits an RLQP-element with Info ID for NCC in the Query Request field in a GAS Initial Request frame. The specific information items in the Query Request field of the GAS Initial Request frame are generated as follows: â€” The Requester STA Address field is set to the MAC address of the NCC requesting STA. â€” The Responder STA Address field is set to the MAC address of the NCC responding STA. â€” The Reason Result code is REQUEST, as defined in 9.4.6.4. â€” The Number of Network Channel Control Triplets field, as defined in 9.4.6.4, gives the number of triplets of Operating Class, Channel Number, and Transmit Power Constraint fields. â€” The Operating Class and Channel Number fields, with the values defined in E.1, together specify the channel frequency and channel bandwidth for WLAN network channels selected by the NCC requesting STA. â€” The Maximum Transmit Power field, as defined in 9.4.6.4, is set to the intended maximum transmit power in dBm for operation of the requesting STA. An NCC Requesting STA might use the Network Channel Control frame or its protected dual to query another STA to request frequency usage in TV bands for WLAN network channels. Upon receipt of the MLME-NETWORKCHANNELCONTROL.request primitive, the requesting STA transmits a (protected) Network Channel Control frame. The request frame is generated as follows: â€” The Requester STA Address field is set to the MAC address of the NCC requesting STA. â€” The Responder STA Address field is set to the MAC address of the NCC responding STA. â€” The Reason Result Code is REQUEST, as defined in 9.4.6.4. â€” The Number of Network Channel Control Triplets field, as defined in 9.4.6.4, gives the number of triplets of Operating Class, Channel Number, and Transmit Power Constraint fields. â€” The Operating Class and Channel Number fields, with the values defined in E.1, together specify the channel frequency and channel bandwidth for WLAN network channels selected by the NCC requesting STA. â€” The Maximum Transmit Power field, as defined in 9.4.6.4, is set to the intended maximum transmit power in dBm for operation of the requesting STA. 1917 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 11.44.7.3 NCC responding STA An NCC responding STA may be a GDD enabling STA. An NCC responding STA employing RLQP may use the GAS protocol for its NCC procedure with a RLSS. Upon receipt of the MLME-GAS.response primitive with a ResponseInfo parameter value of Network Channel Control RLQP-element, the NCC responding STA transmits a RLQP-element with Info ID for NCC in the Query Response field in a GAS Initial Response frame or one or more GAS Comeback Response frames. The specific information items in the Query Response field of the GAS Initial Response frame are generated as follows: â€” Requester STA Address field set to the MAC address of the NCC requesting STA. â€” Responder STA Address field set to the MAC address of the NCC responding STA. â€” Reason Result Code field = values SUCCESS, REFUSED, TOO_MANY_SIMULTANEOUS_REQUESTS, or Continuation frame as defined in 9.4.6.4. â€” The Number of Network Channel Control Triplets field, as defined in 9.4.6.4, gives the number of triplets of Operating Class, Channel Number, and Transmit Power Constraint fields. â€” The Operating Class and Channel Number fields, with the values defined in E.1, together specify the channel frequency and channel bandwidth that the NCC responding STA has granted permission to the NCC requesting STA for WLAN operation. â€” The Maximum Transmit Power field, as defined in 9.4.6.4, sets to maximum allowable transmit power in dBm of the requesting STAâ€™s WLAN operation. An NCC responding STA may use an Network Channel Control frame or its protected dual to respond to another STA with NCC information. Upon receipt of the MLME- NETWORKCHANNELCONTROL.response primitive with NCC parameter value of NCC element, the NCC responding STA transmits a Network Channel Control frame containing an NCC element. The response frame is generated as follows: â€” Requester STA Address field set to the MAC address of the NCC requesting STA. â€” Responder STA Address field set to the MAC address of the NCC responding STA. â€” Reason Result Code = values SUCCESS, REFUSED, TOO_MANY_SIMULTANEOUS_REQUESTS, or Continuation frame as defined in 9.4.6.4. â€” The Number of Network Channel Control Triplets field, as defined in 9.4.6.4, gives the number of triplets of Operating Class, Channel Number, and Transmit Power Constraint fields. â€” The Operating Class and Channel Number fields, with the values defined in E.1, together specify the channel frequency and channel bandwidth that the NCC responding STA has granted permission to the NCC requesting STA for WLAN operation. â€” The Maximum Transmit Power field, as defined in 9.4.6.4, sets to maximum allowable transmit power in dBm of the requesting STAâ€™s WLAN operation. 11.44.8 Reduced neighbor report In Beacon and Probe Response frames, a Reduced Neighbor Report element may be transmitted by an AP with dot11TVHTOptionImplemented true. A Reduced Neighbor Report element contains information on neighbor APs. A Reduced Neighbor Report element might not be exhaustive either by choice or by the fact that there may be neighbor APs not known to the AP. The Reduced Neighbor Report element contains a list of operating classes and primary channels along with TBTT information for the reported neighbor APs on each operating class and primary channel. The operating class is selected from values in Table E-4 filtered by the requirement that, together with the Channel Number field, the primary channel be identifiable. 1918 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NOTEâ€”For instance, this excludes operating class 128â€“130. When the reporting AP cannot obtain an operating class that, together with the Channel Number field, identifies the primary channel from the neighboring AP, then the reporting AP shall report an operating class that, together with a channel number, identifies the primary channel of the reported BSS. Given a choice of operating classes that preserve the identification of the primary channel, the reporting AP should select an operating class that preserves as many behavior limits as possible are known to the reporting AP. NOTEâ€”An operating class might be unavailable because the neighboring AP does not transmit an operating class or the transmitted operating class does not indicate a primary channel. A Reduced Neighbor Report element includes only channels that are consistent with the Country element in the frame in which the Reduced Neighbor Report element appears. The Reduced Neighbor Report element contents may be derived from the NeighborListSet parameter of the MLME-NEIGHBORREPRESP.request primitive. The contents of the Reduced Neighbor Report element might also be configured or obtained by other means beyond the scope of this standard. If the Supported Operating Classes element of the STA is included in the Probe Request frame, the reduced neighbor report contains information on neighbor APs whose current operating class matches the supported operating classes in the Probe Request frame. The Reduced Neighbor Report element shall include the information on neighbor APs whose SSID matches the specific SSID in the Probe Request frame if the Filtered Neighbor AP bit in the Neighbor AP Information field is set to 1. A serving AP shall include a value less than 255 in the Neighbor AP TBTT Offset subfield if it is able to guarantee an accumulated error of 1.5 TU or better. A STA receiving a Reduced Neighbor Report element may use the report to schedule passive scanning for faster AP discovery. The scheduling process is beyond the scope of this standard. A STA receiving a Reduced Neighbor Report element with an unknown subelement identifier shall ignore the unknown subelement and continue to process the remaining subelements. 11.44.9 White space map (WSM) This subclause describes WSM procedures that can be used to obtain lists of available channels for operation of a GDD STA. STAs can use the WSM procedure specified here when dot11GDDActivated is true. When dot11WhiteSpaceMapActivated is true, a GDD STA shall follow the procedures in this subclause. If dot11WhiteSpaceMapActivated is true, a GDD enabling STA transmits a WSM, and a GDD dependent STA can transmit frames only on the available channels indicated in its valid WSM. GDBs can be different according to each regulatory domain and its regulatory requirements. A WSM Type field value of 1 indicates that the WSM is generated from the GDB and the WSM Information field of the WSM element specifies the available information for TVWS, which is country-specific and defined in 9.4.4.2.5. A GDD enabling STA contacts a GDB to obtain the permissible frequencies and operating parameters before it begins its transmissions. After receiving the WSM information from a GDB, a GDD enabling STA operates in TVWS only in the frequencies that the GDB indicates are available. The GDD enabling STA generates WSMs based on the information from the GDB. It may update WSMs when STAs perform a measurement or receive a measurement report in which a primary service signal is measured on a channel, which is indicated as available from the GDB. 1919 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A WSM element includes a list of identified available channels and corresponding maximum allowed transmission powers for each available channel. When a GDD enabling STA retrieves updated available frequency information, it is able to transmit individually addressed Protected WSM Announcement frames with an updated WSM element to its GDD dependent STAs. A GDD dependent STA receiving a WSM element operates on the channels indicated in the WSM. A GDD dependent STA that receives an updated WSM from its GDD enabling STA shall move its channel of operation if it is operating on a channel that has become unavailable in the updated WSM. A GDD enabling STA transmits a WSM within a GDD Enablement Response frame, CAQ response frame, and WSM Announcement frame. A Device Class field of a WSM in a GDD Enablement Response frame and CAQ response frame is set to a value of a Device Class field in a GDD Enablement Request frame and Channel Availability Query frame, respectively. A Device Class field of WSM in a WSM Announcement frame is set to a value of the Device Class field of a WSM in a GDD Enablement Request frame. The value of the Map version bits in the Map ID field is increased by 1 (modulo 127) whenever the GDD enabling STA transmits the updated WSM. The most recently received WSM is used by the WSM receiving STAs. A WSM with a Map version value of 127 indicates that the WSM is informative and it does not affect the GDD enablement states of a GDD dependent STA. If the Type bit in the Map ID field is set to 1, the following channel list is a full channel list; and if the Type bit is set to 0, the following channel list is a partial channel list. If a STA receives several WSMs with the same Map version and the Type bit is equal to 0, the STA should construct the whole channel list using the multiple WSMs having the same Map version. GDD dependent STAs receiving a WSM should scan for existing BSSs on the available channels identified within received WSM element. In TVWS a GDD dependent STA receiving a WSM element shall operate on the channels indicated in the WSM. A GDD dependent STA that has previously received a WSM and that receives an updated WSM from its AP or GDD enabling STA shall move its channel of operation if it is operating on a channel that has become unavailable in the updated WSM. If dot11WhiteSpaceMapActivated is true, then the enabled GDD dependent STA may send a Probe Request frame on any channel identified in the received WSM element. An AP that has dot11WhiteSpaceMapActivated true and that receives a Probe Request frame should respond with a Probe Response frame containing a WSM element. 11.45 Beacon RSSI Upon receiving a Beacon frame, a STA measures the received signal strength of the Beacon frame (dot11BeaconRssi). If the Beacon frame is received using multiple receive chains, the Beacon RSSI is averaged in linear domain over all active receive chains. The Beacon RSSI is reported in dBm. When operating in frequency bands below 6 GHz, the Beacon RSSI has an accuracy of Â± 5 dB (95% confidence interval) within the specified dynamic range of the receiver. Beacon RSSI may be averaged over time using a vendor specific smoothing function. 11.46 Estimated throughput A STA that has a value of true for dot11EstimatedServiceParametersOptionImplemented is an estimated service parameters (ESP) STA. 1920 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Entities outside the scope of this standard that might control the traffic steering decision of a device benefit by being able to predict the throughput that might be obtained through a link with a STA. Those same entities also need to know what the current estimate of throughput is for network selection purposes (by comparing an estimated throughout with existing throughout). The MLME-ESTIMATED- THROUGHPUT.request and MLME-ESTIMATED-THROUGHPUT.confirm primitives together provide an interface to allow such entities, operating through the SME, to obtain an estimate of throughput for MSDUs sent between the STA that corresponds to the PeerMACAddress indicated in the parameter list of the MLME-ESTIMATED-THROUGHPUT.request primitive and this STA. When an MLME-ESTIMATED-THROUGHPUT.request primitive is received at the MLME, the MLME can use the parameters provided in the primitive plus the following information to create estimates of throughput per access category to deliver to the SME in the EstimatedThroughputOutbound parameter of the MLME-ESTIMATED-THROUGHPUT.confirm primitive: â€” RSSI measured during reception of Beacon or Probe Response frames transmitted by the STA that corresponds to the MAC entity with the MAC address equal to the PeerMACAddress in the MLME- ESTIMATED-THROUGHPUT.request primitive to this STA â€” Number of spatial streams that is expected to be supported on the link between this STA and the STA â€” Channel bandwidth â€” Estimated air fractional time â€” Block ack window size If the MLME is incapable of determining a value for the EstimatedThroughputOutbound or EstimatedThroughputInbound parameter for any access category, then the MLME shall return a value of 0 for the value of that parameter for that access category in the MLME-ESTIMATED- THROUGHPUT.confirm primitive. If the AverageMSDUSizeOutbound parameter for an access category is equal to â€“1 in the MLME-ESTIMATED-THROUGHPUT.request primitive, the STA shall include a value of 0 in the EstimatedThroughputOutbound parameter for the corresponding access category in the MLME- ESTIMATED-THROUGHPUT.confirm primitive. If the AverageMSDUSizeOutbound parameter for an access category is equal to 0 in the MLME-ESTIMATED-THROUGHPUT.request primitive, the STA may use any value for the average MSDU size used in calculating the estimated throughput to be included in the corresponding access category in the EstimatedThroughputOutbound parameter of the MLME- ESTIMATED-THROUGHPUT.confirm primitive, but should use a value of 1500 octets. If the AverageMSDUSizeInbound parameter for an access category is equal to â€“1 in the MLME-ESTIMATED- THROUGHPUT.request primitive, the STA shall include a value of 0 in the EstimatedThroughputInbound parameter for the corresponding access category in the MLME-ESTIMATED-THROUGHPUT.confirm primitive. If the AverageMSDUSizeInbound parameter for an access category is equal to 0 in the MLME- ESTIMATED-THROUGHPUT.request primitive, the STA may use any value for the average MSDU size used in calculating the estimated throughput to be included in the corresponding access category in the EstimatedThroughputInbound parameter of the MLME-ESTIMATED-THROUGHPUT.confirm primitive, but should use a value of 1500 octets. An ESP STA should determine a value for EstimatedThroughputOutbound for each AC of a current or potential link with a STA using the equation found in R.7. An ESP STA or a mesh STA may include a Request element that includes the element ID of the Estimated Service Parameters element in transmitted Probe Requests. 1921 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications An ESP STA that is an AP or a mesh STA shall include the Estimated Service Parameters element within Probe Response frames transmitted in response to a Probe Request frame that included a Request element that includes the element ID of the Estimated Service Parameters element. An ESP STA that is not an AP may include the Estimated Service Parameters element within Probe Response frames transmitted in response to a Probe Request frame that included a Request element that includes the element ID of the Estimated Service Parameters element. An ESP STA may include the Estimated Service Parameters element within Probe Response frames transmitted in response to a Probe Request frame that did not include a Request element, or included a Request element that did not include the element ID of the Estimated Service Parameters element. An ESP STA that is an AP or a mesh STA shall include the Estimated Service Parameters element within Beacon frames. An ESP STA that is not an AP may include the Estimated Service Parameters element within Beacon frames. 1922 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 12. Security 12.1 Conventions Reserved fields and subfields are set to 0 upon transmission and are ignored upon reception. ASCII strings are defined in 9.2.2. 12.2 Framework 12.2.1 Classes of security algorithm This standard defines two classes of security algorithms for IEEE 802.11 networks: â€” Algorithms for creating and using an RSNA, called RSNA algorithms â€” Pre-RSNA algorithms NOTEâ€”This standard does not prohibit STAs from simultaneously operating pre-RSNA and RSNA algorithms. The use of WEP for confidentiality, authentication, or access control is deprecated. The WEP algorithm is unsuitable for the purposes of this standard. The use of TKIP is deprecated. The TKIP algorithm is unsuitable for the purposes of this standard. 12.2.2 Security methods Pre-RSNA security comprises the following algorithms and procedures: â€” WEP, described in 12.3.2 â€” IEEE 802.11 entity authentication, described in 12.3.3 RSNA security comprises the following algorithms and procedures: â€” TKIP, described in 12.5.2 â€” CCMP, described in 12.5.3 â€” GCMP, described in 12.5.5 â€” BIP, described in 12.5.4 â€” RSNA establishment and termination procedures, including use of IEEE 802.1X authentication, described in 12.6 and SAE authentication described in 12.4 â€” Key management procedures, described in 12.7 12.2.3 RSNA STA capabilities When dot11RSNAActivated is true, an RSNA STA shall include the RSNE in Beacon, Probe Response, Information Response, and (Re)Association Request frames and in message 2 and message 3 of the 4-way handshake; shall set the DMG Privacy subfield to 1 within transmitted DMG Beacons; and may include the RSNE in DMG Beacon and Announce frames. A pre-RSNA STA is not capable of creating RSNAs. All STAs implementing RSNA shall support the RSNE described in 9.4.2.25. 12.2.4 RSNA establishment An SME establishes an RSNA in one of six ways: 1923 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications a) If an RSNA uses authentication negotiated over IEEE Std 802.1X in an infrastructure BSS, an RSNA-capable STAâ€™s SME establishes an RSNA as follows: 1) It identifies the AP as RSNA-capable from the APâ€™s Beacon, DMG Beacon, Announce, Information Response, or Probe Response frames. 2) It shall invoke Open System authentication if the STA is a non-DMG STA. 3) It negotiates cipher suites during the association process, as described in 12.6.2 and 12.6.3. 4) It uses IEEE Std 802.1X-2010 to authenticate, as described in 12.6.10 and 12.6.11. 5) It establishes one or more temporal keys by executing a key management algorithm, using the protocol defined by 12.7 or 13. 6) It protects the data link by programming the negotiated cipher suites and the established temporal key into the MAC and then invoking protection. See, for example, 12.5.3 for a description of the RSNA data protection mechanisms. 7) If the STAs negotiate management frame protection, the SME programs the TK and pairwise cipher suite into the MAC for protection of individually addressed robust Management frames. It also installs the IGTK and IPN for protection of group addressed robust Management frames. b) If an RSNA is based on a PSK or password in an infrastructure BSS, the SME establishes an RSNA as follows: 1) It identifies the AP as RSNA-capable from the APâ€™s Beacon, DMG Beacon, Announce, Information Response, or Probe Response frames. 2) If the RSNA-capable AP advertises support for SAE authentication in its Beacon or Probe Response frames, and the STA has a group defined in the dot11RSNAConfigDLCGroupTable and a password for the AP in the dot11RSNAConfigPasswordValueTable, the STA shall invoke SAE authentication to establish a PMK. If the RSNA-capable AP does not advertise support for SAE authentication in its Beacon and Probe Response frames but advertises support for the alternate form of PSK authentication (see 4.10.3.4), and the STA also supports the alternate form of PSK authentication, the non-DMG STA may invoke Open System authentication and use the PSK as the PMK with the key management algorithm in step 4) below. 3) It negotiates cipher suites during the association process, as described in 12.6.2 and 12.6.3. 4) It establishes one or more temporal keys by executing a key management algorithm, using the protocol defined by 12.7. 5) It protects the data link by programming the negotiated cipher suites and the established temporal key into the MAC and then invoking protection. 6) If the STAs negotiate management frame protection, the STA programs the TK and pairwise cipher suite into the MAC for protection of individually addressed robust Management frames. It also installs the IGTK and IPN for protection of group addressed robust Management frames. c) If an RSNA is based on a PSK or password in an IBSS the SME executes the following sequence of procedures: 1) It identifies the peer as RSNA-capable from the peerâ€™s Beacon, DMG Beacon, Announce, Information Response, or Probe Response frames. NOTEâ€”STAs might respond to a Data frame from an unrecognized STA by sending a Probe Request frame to find out whether the unrecognized STA is RSNA-capable. 2) If the RSNA-capable peer advertises support for SAE authentication in its Beacon and Probe Response frames and the STA has a group defined in the dot11RSNAConfigDLCGroupTable and a password for the peer in the dot11RSNAConfigPasswordValueTable, the STA shall invoke SAE authentication and establish a PMK. If the RSNA-capable peer does not advertise support for SAE authentication but advertises support for the alternate form of PSK authentication (see 4.10.3.4), and the STA also supports the alternate form of PSK 1924 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications authentication the STA may invoke Open System authentication if the STA is a non-DMG STA and use a PSK as the PMK with the alternate form of PSK authentication. 3) Each STA uses the procedures in 12.7, to establish one or more temporal keys and to negotiate cipher suites. Note that two peer STAs might follow this procedure simultaneously. See 12.6.15. 4) It protects the data link by programming the negotiated cipher suites and the established temporal key and then invoking protection. d) If an RSNA uses authentication negotiated over IEEE Std 802.1X in an IBSS, an RSNA-capable STAâ€™s SME establishes an RSNA as follows: 1) It identifies the peer as RSNA-capable from the peerâ€™s Beacon, DMG Beacon, Announce, Information Response, or Probe Response frames. NOTEâ€”STAs might respond to a Data frame from an unrecognized STA by sending a Probe Request frame to find out whether the unrecognized STA is RSNA-capable. 2) It may invoke Open System authentication if the STA is a non-DMG STA. 3) Each STA uses IEEE Std 802.1X-2010 to authenticate with the AS associated with the other STAâ€™s Authenticator, as described in 12.6.10 and 12.6.11. NOTEâ€”Two peer STAs might follow this procedure simultaneously. 4) Each SME establishes one or more temporal keys by executing a key management algorithm, using the protocol defined in 12.7. Hence two such key management algorithms are happening in parallel between any two STAâ€™s Supplicants and Authenticators. 5) Both STAs use the agreed-upon temporal key portion of the PTK and pairwise cipher suite from one of the exchanges to protect the link. Each STA uses the GTK established by the exchange it initiated to protect the group addressed frames it transmits. e) In order to associate with a PCP in a PBSS, an RSNA-capable STAâ€™s SME establishes an RSNA with the PCP following the RSNA establishment steps in an infrastructure BSS in accordance with method a) and b) above, as appropriate, with the PCP taking the role of the AP. f) When an RSNA-capable STA chooses not to associate with a peer in a PBSS, its SME establishes an RSNA with the peer following the RSNA establishment steps in an IBSS in accordance with method c) or d) above, as appropriate, with the caveat that the RSNA authentication and key management algorithm is executed only once between the peers. The time a security association takes to set up shall be less than dot11RSNAConfigSATimeout. The security association setup starts when initiated by the SME and completes when the MLME- SETPROTECTION.request primitive is invoked. The action the STA takes on the timeout is a policy decision. Some options include retrying the security association setup or trying another STA. This timeout allows recovery when one of the STAs setting up a security association fails to respond correctly to setting up the security association. It also allows recovery in IBSS when one of the two security associations fails because of a security association timeout. Only Authentication frames with the authentication algorithm equal to Open System authentication or FT authentication may be used within an RSNA. An RSNA STA shall not associate if Shared Key authentication was invoked prior to RSN association. 12.2.5 RSNA PeerKey Support The STSL mechanism is obsolete. Consequently, the PeerKey protocol components that do not support the AP PeerKey protocol might be removed in a later revision of the standard. 1925 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The PeerKey protocol provides mutual authentication, session identification, and data confidentiality for a station-to-station connection. A PeerKey association, composed of an SMKSA and an STKSA, shall be allowed only within the context of an existing RSNA by both peers with a common AP, or between peer APs that implement the AP PeerKey protocol. An initiator STA or peer STA shall not initiate an STSL master key (SMK) handshake and STSL transient key (STK) handshake if dot11RSNAActivated is false. An initiator STA or peer STA shall not establish a security association if dot11RSNAActivated is false. A STSL session may chose to allow unprotected communication between STAs. In this case, the PeerKey protocol is not used. 12.2.6 RSNA assumptions and constraints An RSNA assumes the following: a) Each STA can generate cryptographic-quality random numbers. This assumption is fundamental, as cryptographic methods require a source of randomness. See J.5 for suggested hardware and software methods to achieve randomness suitable for this purpose. b) When IEEE 802.1X authentication is used, the specific EAP method used performs mutual authentication. This assumption is intrinsic to the design of RSN in IEEE 802.11 LANs and cannot be removed without exposing both the STAs to man-in-the-middle attacks. EAP-MD5 is an example of an EAP method that does not meet this constraint (see IETF RFC 3748 [B42]). Furthermore, the use of EAP authentication methods where server and client credentials are not differentiated reduces the security of the method to that of a PSK due to the fact that malicious insiders might masquerade as servers and establish a man-in-the-middle attack. In particular, the mutual authentication requirement implies an unspecified prior enrollment process (e.g., a long-lived authentication key or establishment of trust through a third party such as a certification authority), as the STA needs to be able to identify the ESS or IBSS as a trustworthy entity and vice versa. The STA shares authentication credentials with the AS utilized by the selected AP or, in the case of PSK, the selected AP. The SSID provides an unprotected indication that the selected APâ€™s authentication entity shares credentials with the STA. Only the successful completion of the IEEE 802.1X EAP or PSK authentication, after association, validates any such indication that the AP is connected to an authorized network or service provider. c) The mutual authentication method needs to be strong, meaning impersonation attacks are computationally infeasible when based on the information exposed by the authentication. This assumption is intrinsic to the design of RSN. d) The AP and AS have a trustworthy channel between them that can be used to exchange cryptographic keys without exposure to any intermediate parties. e) An IEEE 802.1X AS never exposes the common symmetric key to any party except the AP with which the STA is currently communicating. This is a very strong constraint. It implies that the AS itself is never compromised. It also implies that the IEEE 802.1X AS is embedded in the AP or that the AP is physically secure and the AS and the AP lie entirely within the same administrative domain. This assumption follows from the fact that if the AP and the AS are not collocated or do not share pairwise key encryption keys directly, then it is impossible to assure the non-AP STA that its key, which is distributed by the AS to the AP, has not been compromised prior to use. f) Similarly, a STA never shares with a third party a common symmetric key that it shares with a peer. Doing so destroys the utility of the key for detecting MPDU replay and forgery. g) The Supplicant and the Authenticator generate a different, fresh PTK for each session between the pair. This assumption is fundamental, as reuse of any PTK would enable compromise of all the data protected by that key. h) The destination STA chosen by the transmitter is the correct destination. For example, Address Resolution Protocol (ARP) and Internet Control Message Protocol (ICMP) are methods of determining the destination STAâ€™s MAC address that are not secure from attacks by other members 1926 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications of the ESS. One of the possible solutions to this problem might be for the STA to send or receive only frames whose final DA or SA are the AP and for the AP to provide a network layer routing function. However, such solutions are outside the scope of this standard. An HT STA shall not use either of the pairwise cipher suite selectors: â€œUse group cipher suiteâ€ or TKIP to communicate with another HT STA. NOTEâ€”Because a VHT STA is also an HT STA, the elimination of TKIP also applies to VHT STAs. 12.2.7 Requirements for the Protected Frame field The Protected Frame field shall be set to 1 in: â€” Data frames that are protected using the mechanisms specified in Clause 12. â€” Individually addressed robust Management frames. â€” Authentication frames with Authentication Algorithm Number field equal to 1 (Shared Key) and Authentication Transaction Sequence Number field equal to 3. It shall be set to 0 in all other frames. 12.2.8 Requirements for robust management frame protection The robust Management frames are Disassociation, Deauthentication, and robust Action frames. Action frames specified with â€œNoâ€ in the â€œRobustâ€ column of Table 9-47 are not robust Management frames and shall not be protected. When management frame protection is negotiated, all group addressed robust Management frames shall be encapsulated using the procedures defined in 11.13. 12.2.9 Emergency service establishment in an RSN An AP or mesh STA that supports RSNAs and has the ESR bit set to 1 and the UESA bit set to 1 in the Interworking element in Beacon and Probe Response frames supports both RSNAs and emergency services associations (see 11.3.5.2) simultaneously. In an infrastructure BSS, the STAs with emergency services association should discard all group addressed frames they receive, as they do not possess the Group Key and therefore are not able to decrypt group addressed frames. In an RSNA enabled BSS that has one or more STAs associated with an emergency services association, an AP should avoid transmitting unprotected group addressed frames in order not to disturb the operation of STAs that are in possession of Group Key. One possible way of achieving this is to support Proxy-ARP in the AP, as defined in 11.24.14. In addition, it is recommended that an AP supporting emergency services association should also support DMS to convert group addressed frames to individually addressed frames and transmit them to STAs associated using the emergency services association. STAs using emergency services association might request DMS if needed. 12.3 Pre-RSNA security methods 12.3.1 Status of Pre-RSNA security methods Except for Open System authentication, all pre-RSNA security mechanisms are obsolete. Support for them might be removed in a later revision of the standard. Open System Authentication and Open System Deauthentication shall not be used between mesh STAs. 1927 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 12.3.2 Wired equivalent privacy (WEP) 12.3.2.1 WEP overview WEP-40 was defined as a means of protecting (using a 40-bit key) the confidentiality of data exchanged among authorized users of a WLAN from casual eavesdropping. Implementation of WEP is optional. The same algorithms have been widely used with a 104-bit key instead of a 40-bit key in fielded implementations; this is called WEP-104. The WEP cryptographic encapsulation and decapsulation mechanics are the same whether a 40-bit or a 104-bit key is used. The term WEP by itself refers to either WEP-40 or WEP-104. 12.3.2.2 WEP MPDU format Figure 12-1 depicts the encrypted frame body as constructed by the WEP algorithm. Encrypted(Note) IV Data ICV 4 â‰¥1 4 Sizes in Octets Init. Vector 1 octet 3 Pad Key ID 6 bits 2 bits Figure 12-1â€”Construction of expanded WEP MPDU The WEP ICV field shall be 32 bits in length. The expanded frame body shall start with a 32-bit IV field. This field shall contain three subfields: a 3-octet subfield that contains the IV, a 2-bit Key ID subfield, and a 6-bit Pad subfield. The ordering conventions defined in 9.2.2 apply to the IV field and its subfields and to the ICV field. The Key ID subfield contents select one of four possible secret key values for use in decrypting this frame body. When key-mapping keys are used, the Key ID field is reserved. Interpretation of these bits is discussed further in 12.3.2.3. The contents of the Pad subfield shall be 0. The Key ID subfield occupies the 2 MSBs of the last octet of the IV field, while the Pad subfield occupies the 6 LSBs of this octet. 12.3.2.3 WEP state WEP uses encryption keys only; it performs no data authentication. Therefore, it does not have data integrity keys. WEP uses two types of encryption keys: key-mapping keys and default keys. A key-mapping key is an unnamed key corresponding to a distinct transmitter address-receiver address pair. Implementations shall use the key-mapping key if it is configured for a pair. In other words, the key-mapping key shall be used to WEP-encapsulate or -decapsulate MPDUs transmitted by TA to RA, regardless of the presence of other key types. When a key-mapping key for an address pair is present, the WEP Key ID subfield in the MPDU is reserved. 1928 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A default key is an item in a four-element MIB array called dot11WEPDefaultKeys, named by the value of a related array index called dot11WEPDefaultKeyID. If a key-mapping key is not configured for a WEP MPDUâ€™s pair, WEP shall use a default key to encapsulate or decapsulate the MPDU. On transmit, the key selected is the element of the dot11DefaultKeys array given by the index dot11WEPDefaultKeyIDâ€”a value of 0, 1, 2, or 3â€”corresponding to the first, second, third, or fourth element, respectively, of dot11WEPDefaultKeys. The value the transmitter encodes in the WEP Key ID subfield of the transmitted MPDU shall be the dot11WEPDefaultKeyID value. The receiver shall use the Key ID subfield of the MPDU to index into dot11WEPDefaultKeys to obtain the correct default key. All WEP implementations shall support default keys. NOTEâ€”Many implementations also support 104-bit WEP keys. These are used exactly like 40-bit WEP keys: a 24-bit WEP IV is prepended to the 104-bit key to construct a 128-bit WEP seed, as explained in 12.3.2.4.3. The resulting 128- bit WEP seed is then consumed by the ARC4 stream cipher. This construction based on 104-bit keys affords no more assurance than the 40-bit construction, and its implementation and use are in no way condoned by this standard. Rather, the 104-bit construction is noted only to document de facto practice. The default value for all WEP keys shall be null. WEP implementations shall discard the MSDU and generate an MA-UNITDATA-STATUS.indication primitive with transmission status indicating that a frame shall not be encapsulated with a null key in response to any request to encapsulate an MPDU with a null key. 12.3.2.4 WEP procedures 12.3.2.4.1 WEP ICV algorithm The WEP ICV shall be computed using the CRC-32, as defined in 9.2.4.7, calculated over the plaintext MPDU Data (PDU) field. 12.3.2.4.2 WEP encryption algorithm A WEP implementation shall use the ARC4 stream cipher from RSA Security, Inc., as its encryption and decryption algorithm. ARC4 uses a pseudorandom number generator (PRNG) to generate a key stream that it exclusive-ORs (XORs) with a plaintext data stream to produce cipher text or to recover plaintext from a cipher text. 12.3.2.4.3 WEP seed construction A WEP implementation shall construct a per-MPDU key, called a seed, by concatenating an encryption key to an IV. For WEP-40, bits 0â€“39 of the WEP key correspond to bits 24â€“63 of the seed, and bits 0â€“23 of the IV correspond to bits 0â€“23 of the seed, respectively. The bit numbering conventions in 9.2.2 apply to the seed. The seed shall be the input to ARC4, in order to encrypt or decrypt the WEP Data and ICV fields. NOTEâ€”For WEP-104, bits 0â€“103 of the WEP key correspond to bits 24â€“127 of the seed, and bit 0â€“23 of the IV correspond to bits 0â€“23 of the seed, respectively. The WEP implementation encapsulating an MPDUâ€™s plaintext data should select a new IV for every MPDU it WEP-protects. The IV selection algorithm is unspecified. The algorithm used to select the encryption key used to construct the seed is also unspecified. The WEP implementation decapsulating an MPDU shall use the IV from the received MPDUâ€™s Init Vector subfield. See 12.3.2.4.5 for the specification of how the decapsulator selects the key to use to construct the per-MPDU key. 1929 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 12.3.2.4.4 WEP MPDU cryptographic encapsulation WEP shall apply three transformations to the plaintext MPDU to effect the WEP cryptographic encapsulation. WEP computes the ICV over the plaintext data and appends this after the MPDU data. WEP encrypts the MPDU plaintext data and ICV using ARC4 with a seed constructed as specified in 12.3.2.4.3. WEP encodes the IV and key identifier into the IV field, prepended to the encrypted Data field. Figure 12-2 depicts the WEP cryptographic encapsulation process. The ICV shall be computed and appended to the plaintext data prior to encryption, but the IV encoding step may occur in any order convenient for the implementation. IV Initialization Seed ARC4 Key Stream Vector (IV) || PRNG Cipher WEP Key text Plaintext || CRC-32 Integrity Check Value (ICV) Message Figure 12-2â€”WEP encapsulation block diagram 12.3.2.4.5 WEP MPDU decapsulation WEP shall apply three transformations to the WEP MPDU to decapsulate its payload. WEP extracts the IV and key identifier from the received MPDU. If a key-mapping key is present for the pair, then this shall be used as the WEP key. Otherwise, the key identifier is extracted from the Key ID subfield of the WEP IV field in the received MPDU, identifying the default key to use. WEP uses the constructed seed to decrypt the Data field of the WEP MPDU; this produces plaintext data and an ICV. Finally WEP recomputes the ICV and bitwise compares it with the decrypted ICV from the MPDU. If the two are bitwise identical, then WEP removes the IV and ICV from the MPDU, which is accepted as valid. If they differ in any bit position, WEP generates an error indication to MAC management. MSDUs with erroneous MPDUs (due to inability to decrypt) shall not be passed to LLC. Figure 12-3 depicts a block diagram for WEP decapsulation. Unlike cryptographic encapsulation, the decapsulation steps shall be in the indicated order. WEP Key Key || Seed Plaintext ARC4 Stream PRNG IV ICV' Integrity algorithm ICV' = ICV? Cipher ICV text Message Figure 12-3â€”WEP decapsulation block diagram 1930 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 12.3.3 Pre-RSNA authentication 12.3.3.1 Overview In an infrastructure BSS, a non-DMG STA shall complete an IEEE 802.11 authentication exchange prior to association. A DMG STA not in an IBSS shall complete an IEEE 802.11 authentication exchange prior to association when an authentication algorithm other than the Open System authentication algorithm is requested. A DMG STA shall not perform an IEEE 802.11 authentication exchange using the Open System authentication algorithm. An IEEE 802.11 authentication exchange is optional in an IBSS. All Authentication frames shall be individually addressed, as IEEE 802.11 authentication is performed between pairs of STAs, i.e., group addressed authentication is not allowed. Deauthentication frames are advisory and may be sent as group addressed frames. Shared Key authentication is deprecated and should not be implemented except for backward compatibility with pre-RSNA STAs. 12.3.3.2 Open System authentication 12.3.3.2.1 General Open System authentication is a null authentication algorithm. Any non-DMG STA requesting Open System authentication can be authenticated if dot11AuthenticationAlgorithmsTable at the peer STA includes an entry with dot11AuthenticationAlgorithm equal to openSystem and dot11AuthenticationAlgorithmActivated equal to true. A STA may decline to authenticate with another requesting STA. Open System authentication is the default authentication algorithm for a pre-RSNA STA. Open System authentication utilizes a two-message authentication transaction sequence. The first message asserts identity and requests authentication. The second message returns the authentication result. If the result is â€œsuccessful,â€ the STAs shall be declared mutually authenticated. In the description in 12.3.3.2.2 and 12.3.3.2.3, the STA initiating the authentication exchange is referred to as the requester, and the STA to which the initial frame in the exchange is addressed is referred to as the responder. The specific items in each of the messages described in the following subclauses are defined in 9.3.3.12, Table 9-35, and Table 9-36. 12.3.3.2.2 Open System authentication (first frame) Upon receipt of an Open System MLME-AUTHENTICATE.request primitive, the requester shall construct an Open System authentication request carried in an Authentication frame and transmit it to the responder. 12.3.3.2.3 Open System authentication (final frame) Upon receipt of an Authentication frame requesting Open System authentication, the responder may authenticate the requester using the following procedure: a) Issue an MLME-AUTHENTICATE.indication primitive to inform the SME of the authentication request. b) Construct and transmit a response carried in an Authentication frame with the fields as defined in 9.3.3.12 and the status field as defined in 9.4.1.9. 1931 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If dot11AuthenticationAlgorithmTable does not include an entry with dot11AuthenticationAlgorithm equal to openSystem and dot11AuthenticationAlgorithmActivated equal to true, the result code shall not take the value â€œsuccessful.â€ 12.3.3.3 Shared Key authentication 12.3.3.3.1 General Shared Key authentication seeks to authenticate STAs as either a member of those who know a shared secret key or a member of those who do not. Shared Key authentication may be used if WEP has been selected and shall not be used otherwise. This mechanism uses a shared key delivered to participating STAs via a secure channel that is independent of IEEE Std 802.11. This shared key is set in a write-only MIB attribute with the intent to keep the key value internal to the STA. A STA shall not initiate a Shared Key authentication exchange unless dot11PrivacyOptionImplemented is true. In the description in 12.3.3.3.2 to 12.3.3.3.6, the STA initiating the authentication exchange is referred to as the requester, and the STA to which the initial frame in the exchange is addressed is referred to as the responder. The specific items in each of the messages described in the following subclauses are defined in 9.3.3.12, Table 9-35, and Table 9-36. 12.3.3.3.2 Shared Key authentication (first frame) Upon receipt of a Shared Key MLME-AUTHENTICATE.request primitive, the requester shall construct a Shared Key authentication request carried in an Authentication frame and transmit it to the responder. 12.3.3.3.3 Shared Key authentication (second frame) Upon receipt of an Authentication frame requesting Shared Key authentication, the responder may authenticate the requester using the procedure here and in the following two frames: a) Issue an MLME-AUTHENTICATE.indication primitive to inform the SME of the authentication request. b) Before sending the second frame in the Shared Key authentication sequence, the responder shall use WEP to generate a string of octets to be used as the authentication challenge text. c) Construct and transmit to the requester a response carried in an Authentication frame with the fields as defined in 9.3.3.12 and the status field as defined in 9.4.1.9. If the status code is not SUCCESS, this shall be the last frame of the transaction sequence; and the content of the challenge text field is unspecified. If the status code is SUCCESS, the following additional information items shall have valid contents: â€” Authentication algorithm dependent information = The challenge text â€” This authentication result shall be of fixed length of 128 octets. The field shall be filled with octets generated by the WEP PRNG. The actual value of the challenge field is unimportant, but the value shall not be a static value. 1932 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 12.3.3.3.4 Shared Key authentication (third frame) The requester shall copy the challenge text from the second frame into a third Authentication frame. The third frame shall be transmitted to the responder after cryptographic encapsulation by WEP, as defined in 12.3.2, using the shared key. 12.3.3.3.5 Shared Key authentication (final frame) The responder shall WEP-decapsulate the third frame as described in 12.3.2. If the WEP ICV check is successful, the responder shall compare the decrypted contents of the Challenge Text field with the challenge text sent in second frame. If they are the same, then the responder shall transmit an Authentication frame to the requester with a successful status code in the final frame of the sequence. If the WEP ICV check fails or challenge text comparison fails, the responder shall respond with an unsuccessful status code in final frame. 12.3.3.3.6 Shared key MIB attributes To transmit a Management frame of subtype Authentication, with an Authentication Transaction Sequence Number field value of 2, the MAC shall operate according to the following decision tree: if dot11PrivacyOptionImplemented is false then the MMPDU is transmitted with a sequence of 0 octets in the Challenge Text field and a status code value of UNSUPPORTED_AUTH_ALGORITHM else the MMPDU is transmitted with a sequence of 128 octets generated using the WEP PRNG and a key whose value is unspecified and beyond the scope of this standard and a randomly chosen IV value (note that this is typically selected by the same mechanism for choosing IV values for transmitted Data frames) in the Challenge Text field and a status code value of SUCCESS (the IV used is immaterial and is not transmitted). Note that there are cryptographic issues involved in the choice of key/IV for this process as the challenge text is sent unencrypted and, therefore, provides a known output sequence from the PRNG. endif To receive a Management frame of subtype Authentication, with an Authentication Transaction Sequence Number field value of 2, the MAC shall operate according to the following decision tree: if the Protected Frame subfield of the Frame Control field is 1 then respond with a status code value of CHALLENGE_FAILURE else if dot11PrivacyOptionImplemented is true then if there is a mapping in dot11WEPKeyMappings matching the MSDUâ€™s TA then if that key is null then respond with a frame whose Authentication Transaction Sequence Number field is 3 that contains the appropriate authentication algorithm number, a status code value of CHALLENGE_FAILURE, and no Challenge Text field, without encrypting the contents of the frame else respond with a frame whose Authentication Transaction Sequence Number field is 3 that contains the appropriate authentication algorithm number, a status code value of SUCCESS, and the identical Challenge Text field, encrypted using that key, and setting the Key ID subfield in the IV field to 0 endif else if dot11WEPDefaultKeys[dot11WEPDefaultKeyID] is null then 1933 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications respond with a frame whose Authentication Transaction Sequence Number field is 3 that contains the appropriate authentication algorithm number, a status code value of CHALLENGE_FAILURE, and no Challenge Text field, without encrypting the contents of the frame else respond with a frame whose Authentication Transaction Sequence Number field is 3 that contains the appropriate authentication algorithm number, a status code value of SUCCESS, and the identical Challenge Text field, WEP-encapsulating the frame under the key dot11WEPDefaultKeys[dot11WEPDefaultKeyID], and setting the Key ID subfield in the IV field to dot11WEPDefaultKeyID endif endif else respond with a frame whose Authentication Transaction Sequence Number field is 3 that contains the appropriate authentication algorithm number, a status code value of UNSUPPORTED_AUTH_ALGORITHM, and no Challenge Text field, without encrypting the contents of the frame endif endif When receiving a Management frame of subtype Authentication, with an Authentication Transaction Sequence Number field value of 3, the MAC shall operate according to the following decision tree: if the Protected Frame subfield of the Frame Control field is 0 then respond with a status code value of CHALLENGE_FAILURE else if dot11PrivacyOptionImplemented is true then if there is a mapping in dot11WEPKeyMappings matching the MSDUâ€™s TA then if that key is null then respond with a frame whose Authentication Transaction Sequence Number field is 4 that contains the appropriate authentication algorithm number and a status code value of CHALLENGE_FAILURE without encrypting the contents of the frame else WEP-decapsulate with that key, incrementing dot11WEPICVErrorCount and responding with a status code value of CHALLENGE_FAILURE if the ICV check fails endif else if dot11WEPDefaultKeys[dot11WEPDefaultKeyID] is null then respond with a frame whose Authentication Transaction Sequence Number field is 4 that contains the appropriate authentication algorithm number and a status code value of CHALLENGE_FAILURE without encrypting the contents of the frame else WEP-decapsulate with dot11WEPDefaultKeys[dot11WEPDefaultKeyID], incrementing dot11WEPICVErrorCount and responding with a status code value of CHALLENGE_FAILURE if the ICV check fails endif endif else respond with a frame whose Authentication Transaction Sequence Number field is 4 that contains the appropriate authentication algorithm number and a status code value of CHALLENGE_FAILURE 1934 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications endif endif dot11PrivacyInvoked shall not take the value of true if dot11PrivacyOptionImplemented is false. Setting dot11WEPKeyMappings to a value that includes more than dot11WEPKeyMappingLengthImplemented entries is illegal and shall have an implementation-specific effect on the operation of the data confidentiality service. Note that dot11WEPKeyMappings may contain from zero to dot11WEPKeyMappingLengthImplemented entries, inclusive. The values of the attributes in the aPrivacygrp should not be changed during the authentication sequence, as unintended operation may result. 12.4 Authentication using a password 12.4.1 SAE overview STAs, both AP STAs and non-AP STAs, may authenticate each other by proving possession of a password. Authentication protocols that employ passwords need to be resistant to off-line dictionary attacks. Simultaneous authentication of equals (SAE) is a variant of Dragonfly, a password-authenticated key exchange based on a zero-knowledge proof. SAE is used by STAs to authenticate with a password; it has the following security properties: â€” The successful termination of the protocol results in a PMK shared between the two STAs. â€” An attacker is unable to determine either the password or the resulting PMK by passively observing an exchange or by interposing itself into the exchange by faithfully relaying messages between the two STAs. â€” An attacker is unable to determine either the password or the resulting shared key by modifying, forging, or replaying frames to an honest, uncorrupted STA. â€” An attacker is unable to make more than one guess at the password per attack. This implies that the attacker cannot make one attack and then go offline and make repeated guesses at the password until successful. In other words, SAE is resistant to dictionary attack. â€” Compromise of a PMK from a previous run of the protocol does not provide any advantage to an adversary attempting to determine the password or the shared key from any other instance. â€” Compromise of the password does not provide any advantage to an adversary in attempting to determine the PMK from the previous instance. Unlike other authentication protocols SAE does not have a notion of an â€œInitiatorâ€ and â€œResponderâ€ or of a â€œSupplicantâ€ and â€œAuthenticator.â€ The parties to the exchange are equals, with each side being able to initiate the protocol. Each side may initiate the protocol simultaneously such that each side views itself as the â€œinitiatorâ€ for a particular run of the protocol. Such a peer-to-peer protocol may be used in a traditional client-server (or Supplicant/Authenticator) fashion but the converse does not hold. This requirement is necessary to address the unique nature of MBSSs. The parties involved are called STA-A and STA-B. They are identified by their MAC addresses, STA- A-MAC and STA-B-MAC, respectively. STAs begin the protocol when they discover a peer by receiving Beacon or Probe Response frame(s), or when they receive an Authentication frame indicating SAE authentication from a peer. SAE is an RSNA authentication protocol and is selected according to 12.6.2. SAE shall be implemented on all mesh STAs to facilitate and promote interoperability. 1935 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 12.4.2 Assumptions on SAE SAE uses various functions and data to accomplish its task and assumes certain properties about each function. These are as follows: â€” H is an â€œextractorâ€ function (see IETF RFC 5869) that concentrates potentially dispersed entropy from an input to create an output that is a cryptographically strong, pseudorandom key. This function takes as input a non-secret â€œsaltâ€ and a secret input keying material â€œikmâ€ and produces a fixed-length output. â€” CN is a confirmation function that takes a secret key and data to confirm and bind to the exchange. â€” A finite cyclic group is negotiated for which solving the discrete logarithm problem is computationally infeasible. When used with AKMs 00-0F-AC:8 or 00-0F-AC:9 from Table 9-133, H is instantiated as HMAC- SHA-256: H(salt, ikm) = HMAC-SHA-256(salt, ikm) When used with AKMs 00-0F-AC:8 or 00-0F-AC:9 from Table 9-133, CN is instantiated as a function that takes a key, a counter, and a sequence of data. Each piece of data is converted to an octet string and concatenated together before being concatenated to the counter and passed, along with the key, to HMAC- SHA-256: CN(key, counter, X, Y, Z, â€¦) = HMAC-SHA-256(key, counter || D2OS(X) || D2OS(Y) || D2OS(Z) || â€¦) where D2OS() represents the data to octet string conversion functions in 12.4.7.2. Each invocation of CN() specifies the format of the counter. Other instantiations of functions H and CN require creation of a new AKM identifier. 12.4.3 Representation of a password Passwords are used in SAE to deterministically compute a secret element in the negotiated group, called a password element. The input to this process needs to be in the form of a binary string. For the protocol to successfully terminate, it is necessary for each side to produce identical binary strings for a given password, even if that password is in character format. There is no canonical binary representation of a character and ambiguity exists when the password is a character string. To eliminate this ambiguity, a STA shall represent a character-based password as an ASCII string. Representation of a character-based password in another character set or use of a password preprocessing technique (to map a character string to a binary string) may be agreed upon, in an out-of-band fashion, prior to beginning SAE. If the password is already in binary form (e.g., it is a binary preshared key) no character set representation is assumed. The binary representation of the password, after being transformed from a character representation or directly if it is already in binary form, is stored in the dot11RSNConfigPasswordValueTable. When a â€œpasswordâ€ is called for in the description of SAE that follows the credential from the dot11RSNConfigPasswordValueTable is used. 12.4.4 Finite cyclic groups 12.4.4.1 General SAE uses discrete logarithm cryptography to achieve authentication and key agreement. Each party to the exchange derives ephemeral public and private keys with respect to a particular set of domain parameters that define a finite cyclic group. Groups may be based on either Finite Field Cryptography (FFC) or on Elliptic Curve Cryptography (ECC). Each component of a group is referred to as an element. Groups are negotiated using an identifying number from a repository maintained by IANA as â€œGroup Descriptionâ€ 1936 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications attributes for IETF RFC 2409 (IKE) [B17][B31]. The repository maps an identifying number to a complete set of domain parameters for the particular group. For the purpose of interoperability, a STA shall support group 19, an ECC group defined over a 256-bit prime order field. More than one group may be configured on a STA for use with SAE by using the dot11RSNAConfigDLCGroup table. Configured groups are prioritized in ascending order of preference. If only one group is configured, it is, by definition, the most preferred group. NOTEâ€”The preference of one group over another is a local policy issue. SAE uses three arithmetic operators defined for both FFC and ECC groups, an operation that takes two elements to produce a third element (called the element operation), an operation that takes an integer (called scalar) and an element to produce a second element (called the scalar operation), and an operation that takes an element to produce a second element (called the inverse operation). The convention used here is to represent group elements in uppercase bold italic and scalar values in lowercase italic. The element operation takes two elements, X and Y, to produce a third element, Z, and is denoted Z = elem-op(X,Y); the scalar operation takes a scalar, x, and an element, Y, to produce a second element Z and is denoted Z = scalar-op(x,Y); the inverse operation takes an element, X, to produce a second element, Z, and is denoted Z = inverse-op(X). scalar-op(x,Y) is defined as successive iterations of elem-op(Y, Y). That is, it is possible to define scalar- op(1, Y) = Y and for x > 1, scalar-op(x, Y) = elem-op(scalar-op(x-1, Y), Y). The specific definition of elem- op(X,Y) depends on the type of group, either ECC or FFC. 12.4.4.2 Elliptic curve cryptography (ECC) groups 12.4.4.2.1 ECC group definition ECC groups used by SAE are defined by the sextuple (p, a, b, G, r, h) where p is a prime number, a and b specify the elliptic curve defined by the equation, y2 = x3 + ax + b mod p, G is a generator (a base point on the elliptic curve), r is the prime order of G, and h is the co-factor. Elements in ECC groups are the points on the elliptic curve defined by their coordinatesâ€”(x, y)â€”that satisfy the equation for the curve and the identity element, the so-called â€œpoint at infinity.â€ The IANA registry used to map negotiated numbers to group domain parameters includes some ECC groups defined over a characteristic 2 finite field and may include some ECC groups with a co-factor greater than 1. These groups shall not be used with SAE. Only ECC groups defined over an odd prime finite field with a co- factor equal to 1 shall be used with SAE. The element operation in an ECC group is addition of two points on the curve resulting in a third point on the curve. For example, the point X is added to the point Y to produce the point Z: Z = X + Y = elem-op(X,Y) The scalar operation in an ECC group is multiplication of a point on the curve by a scalar resulting in a second point on the curve. For example, the point Y is multiplied by the scalar x to produce the point Z: Z = xY = scalar-op(x,Y) The inverse operation in an ECC group is inversion of a point on a curve resulting in a second point on the curve. A point on an elliptic curve is the inverse of a different point if their sum is the â€œpoint at infinity.â€ In other words: elem-op(X, inverse(X)) = â€œpoint at infinityâ€ 1937 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ECC groups make use of a mapping function, F, that maps a point (x, y) that satisfies the curve equation to its x-coordinateâ€”i.e., if P = (x, y) then F(P) = x. Function F is not defined with the identity element as input. NOTEâ€”SAE protocol operations preclude function F from ever being called with the identity element, i.e., the â€œpoint at infinity.â€ 12.4.4.2.2 Generation of the password element with ECC groups The password element of an ECC group (PWE) shall be generated in a random hunt-and-peck fashion. The password and a counter, represented as a single octet and initially set to 1, are used with the peer identities to generate a password seed. The password seed shall then be stretched using the key derivation function (KDF) from 12.7.1.7.2 to a length equal to the bit length of the prime number, p, from the elliptic curve domain parameters with the Label being the string â€œSAE Hunting and Peckingâ€ and with the Context being the prime number. If the resulting password value is greater than or equal to the prime number, the counter shall be incremented, a new password seed shall be derived and the hunting-and-pecking shall continue. Otherwise, it shall be used as the x-coordinate of a candidate point (x, y) on the curve satisfying the curve equation, if such a point exists. If no solution exists, the counter shall be incremented, a new password-seed shall be derived and the hunting-and-pecking shall continue. Otherwise, there are two possible solutions: (x, y) and (x, p â€“ y). The password seed shall be used to determine which one to use: if the least-significant bit (LSB) of the password seed is equal to that of y, the PWE shall be set to (x, y); otherwise, it shall be set to (x, p â€“ y). In order to minimize the possibility of side-channel attacks that attempt to determine the number of interactions of the â€œhunting-and-peckingâ€ loop required for a given tuple, implementations should perform at least k iterations regardless of whether PWE is discovered or not. The value k may be set to any non-negative value and should be set to a sufficiently large number to effectively guarantee the discovery of PWE in less than k iterations. If PWE is discovered in less than k iterations a random â€œpasswordâ€ can be used in subsequent iterations to further obfuscate the true cost of discovering PWE. NOTEâ€”The probability that one requires more than n iterations of the â€œhunting and peckingâ€ loop to find PWE is roughly (r/2p)n, which rapidly approaches 0 as n increases. Algorithmically this process is described as follows: found = 0; counter = 1 Length = len(p) base = password do { pwd-seed = H(MAX(STA-A-MAC, STA-B-MAC) || MIN(STA-A-MAC, STA-B-MAC), base || counter) pwd-value = KDF-Hash-Length(pwd-seed, â€œSAE Hunting and Peckingâ€, p) if (pwd-value < p) then if (pwd-value3 + a Ã— pwd-value + b) is a quadratic residue modulo p then if (found==0) then x = pwd-value save = pwd-seed found = 1 base = a new random number fi fi fi 1938 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications counter = counter + 1 } while ((counter <= k) or (found==0)) y = sqrt(x3 + ax + b) mod p if (LSB(save) == LSB(y)) then PWE = (x, y) else PWE = (x, p â€“ y) fi where KDF-Hash-Length is the key derivation function defined in 12.7.1.7.2 using the hash algorithm iden- tified by the AKM suite selector (see Table 9-133) len() returns the length of its argument in bits Checking whether a value is a quadratic residue modulo a prime can leak information that can be used in launching a side-channel attack. Therefore, a STA should use this blinding technique in determining a quadratic residue to address the possibility of a side-channel attack. The blinding technique involves multiplication of the value with a random number so the value being checked for quadratic residue modulo a prime can take on all numbers between 1 and pâ€“1 with equal probability. The blinded value is multiplied by a quadratic residue or quadratic non-residue depending on the value of a coin flip and the result is checked whether the result is a quadratic residue or quadratic non- residue, respectively. This technique involves creation of a quadratic residue, qr, and quadratic non-residue, qnr, prior to beginning of the hunting-and-pecking loop. These values can be chosen at random by checking their legendre symbol: do { qr = random() mod p } while ( LGR(qr | p) is not equal to â€“1) do { qnr = random() mod p } while ( LGR(qnr | p) is not equal to 1) The blinding technique of determining whether a value, v, is a quadratic residue modulo a prime, p, is then: r = (random() mod (p â€“ 1)) + 1 num = (v Ã— r Ã— r) mod p if (LSB(r) == 1) then num = (num Ã— qr) mod p if (LGR(num | p) == 1) then v is a quadratic residue modulo p fi else num = (num Ã— qnr) mod p if (LGR(num | p) == â€“1) then v is a quadratic residue modulo p 1939 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications fi fi v is a quadratic non-residue modulo p The values qr and qnr may be used for all loops in the hunting-and-pecking process but a new value for r shall be generated each time a quadratic residue is checked. 12.4.4.3 Finite field cryptography (FFC) groups 12.4.4.3.1 FFC group definition FFC groups used by SAE are defined by the triple (p, G, r), where p is a prime number, G is a generator, and r is the prime order of G mod p. An element, B, in an FFC group satisfies B = Gi mod p for some integer i. This special property differentiates elements from scalars, even though both elements and scalars can be represented as non-negative integers less than the prime modulus p. The notation convention of 12.4.4 signifies this difference between an element and a scalar in an FFC group. The identity element for an FFC group is the value 1 mod p. The element operation in an FFC group is modular multiplication of two elements of this group resulting in a third element of this group. For example, the element X is multiplied by the element Y to product the element Z: Z = (XY) mod p = elem-op(X,Y) The scalar operation in an FFC group is modular exponentiation of an element of this group by a scalar resulting in a second element of this group. For example, the point Y is raised to the power x to produce the element Z: Z = Yx mod p = scalar-op(x,Y) Some FFC groups in the IANA repository are based on safe primes, i.e., a prime, p, of the form p = 2q + 1, where q is also a prime number. For these FFC groups, the group generated by G always has order r = (p â€“ 1)/2 and thus is uniquely derived from context. For other FFC groups, the parameter r shall be explicitly stated as part of the domain parameters. The inverse operation in an FFC group is modular inversion of an element of this group producing a second element in this group. An element Z is the inverse of a second element X of this group if their modular product is the identity element of the FFC group. In other words: elem-op(X, inverse(X)) = 1 mod p In contrast to ECC groups, FFC groups do not need a mapping function that maps an element of the FFC group to an integer (since those elements are already non-negative integers less than the prime number, p). However, for sake of uniform protocol definition, function F with FFC groups is defined as the identity functionâ€”i.e., if x is an element of the FFC group then F(x) = x. 12.4.4.3.2 Generation of the password element with FFC groups The password element of an FFC group (PWE) shall be generated in a random hunt-and-peck fashion similar to the technique for an ECC group. The password and a counter, represented as a single octet and initially set to 1, are used with the two peer identities to generate a password seed. The password seed shall then be stretched using the key derivation function (KDF) from 12.7.1.7.2 to a length equal to the bit length 1940 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications of the prime number, p, from the group domain parameters with the Label being the string â€œSAE Hunting and Peckingâ€ and the Content being the prime number. If the resulting password value is greater than or equal to the prime number, the counter shall be incremented, a new password seed shall be derived, and the hunting-and-pecking shall continue. Otherwise, it shall be raised to the power (p â€“ 1) / r (where p is the prime number and r is the order) modulo the prime number to produce a candidate PWE. If the candidate PWE is greater than 1, the candidate PWE becomes the PWE; otherwise, the counter shall be incremented, a new password seed shall be derived, and the hunting-and-pecking shall continue. Algorithmically this process is described as follows: found = 0; counter = 1 Length = len(p) do { pwd-seed = H(MAX(STA-A-MAC, STA-B-MAC) || MIN(STA-A-MAC, STA-B-MAC), password || counter) pwd-value = KDF-Hash-Length(pwd-seed, â€œSAE Hunting and Peckingâ€, p) if (pwd-value < p) then PWE = pwd-value(p-1)/r mod p if (PWE > 1) then found = 1 fi fi counter = counter + 1 } while (found==0) where KDF-Hash-Length is the key derivation function defined in 12.7.1.7.2 using the hash algorithm iden- tified by the AKM suite selector (see Table 9-133) len() returns the length of its argument in bits 12.4.5 SAE protocol 12.4.5.1 Message exchanges The protocol consists of two message exchanges, a commitment exchange and a confirmation exchange. The commitment exchange is used to force each party to the exchange to commit to a single guess of the password. The confirmation exchange is used to prove that the password guess was correct. Authentication frames are used to perform these exchanges (see 9.3.3.12 and 12.4.7.3). The rules for performing these exchanges are specified by the finite state machine in 12.4.8. When a party has sent its message in the commit exchange it is said to have committed and when it has sent its message in the confirmation exchange it has confirmed. The following rules are ascribed to the protocol: â€” A party may commit at any time â€” A party confirms after it has committed and its peer has committed â€” A party accepts authentication after a peer has confirmed â€” The protocol successfully terminates after each peer has accepted 1941 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 12.4.5.2 PWE and secret generation Prior to beginning the protocol message exchange, the secret element PWE and two secret values are generated. First, a group is selected, either the most preferred group if the STA is initiating SAE to a peer, or the group from a received SAE Commit message if the STA is responding to a peer. The PWE shall be generated for that group (according to 12.4.4.2.2 or 12.4.4.3.2, depending on whether the group is ECC or FFC, respectively) using the identities of the two STAs and the configured password. After generation of the PWE, each STA shall generate a secret value, rand, and a temporary secret value, mask, each of which shall be chosen randomly such that 1 < rand < r and 1 < mask < r and (rand + mask) mod r is greater than 1, where r is the (prime) order of the group. If their sum modulo r is not greater than 1, they shall both be irretrievably deleted and new values shall be randomly generated. The values rand and mask shall be random numbers produced from a quality random number drawn from a uniform distribution generator. These values shall never be reused on distinct protocol runs. 12.4.5.3 Construction of an SAE Commit message An SAE Commit message consists of a scalar and an element that shall be produced using the PWE and secrets generated in 12.4.5.2, as follows: commit-scalar = (rand + mask) mod r COMMIT-ELEMENT = inverse(scalar-op(mask, PWE)) This message shall be transmitted to the peer as described in 12.4.7. The temporary secret mask may be deleted at this point. 12.4.5.4 Processing of a peerâ€™s SAE Commit message Upon receipt of a peerâ€™s SAE Commit message both the scalar and element shall be verified. If the scalar value is greater than 0 and less than the order, r, of the negotiated group, scalar validation succeeds; otherwise, it fails. Element validation depends on the type of group. For FFC groups, the element shall be an integer greater than 1 and less than the prime number p minus 1, (p â€“ 1), and the scalar operation of the element and the order of the group, r, shall equal 1 modulo the prime number p. If either of these conditions does not hold, element validation fails; otherwise, it succeeds. For ECC groups, both the x- and y- coordinates of the element shall be non-negative integers less than the prime number p, and the two coordinates shall produce a valid point on the curve satisfying the groupâ€™s curve definition, not being equal to the â€œpoint at the infinity.â€ If either of those conditions does not hold, element validation fails; otherwise, element validation succeeds. If either scalar validation or element validation fails, the STA shall reject the peerâ€™s authentication. If both the scalar and element from the peerâ€™s SAE Commit message are successfully validated, a shared secret element, K, shall be derived using the scalar and element (peer-commit-scalar and PEER-COMMIT- ELEMENT, respectively) from the peerâ€™s SAE Commit message and the STAâ€™s secret value. K = scalar-op(rand, (elem-op(scalar-op(peer-commit-scalar, PWE), PEER-COMMIT-ELEMENT))) If the shared secret element, K, is the identity element for the negotiated group (the value one for an FFC group or the point-at-infinity for an ECC group) the STA shall reject the peerâ€™s authentication. Otherwise, a secret value, k, shall be computed as: k = F(K) 1942 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The entropy of k shall then be extracted using H to produce keyseed. The key derivation function from 12.7.1.7.2 shall then be used with the hash algorithm identified by the AKM suite selector (see Table 9-133) to derive a key confirmation key, KCK, and a pairwise master key, PMK, from keyseed. When used with AKMs 8 or 9, the salt shall consist of thirty-two (32) octets of the value 0 (indicated below as <0>32) and both the KCK and PMK shall be 256 bits in length, and therefore the length of keying material derived is 512. Use of other AKMs require definition of the lengths of the salt, the KCK, and the PMK. keyseed = H(<0>32, k) kck_and_pmk = KDF-Hash-512(keyseed, â€œSAE KCK and PMKâ€, (commit-scalar + peer-commit-scalar) mod r) KCK = L(kck_and_pmk, 0, 256) PMK = L(kck_and_pmk, 256, 256) where KDF-Hash-512 is the key derivation function defined in 12.7.1.7.2 using the hash algorithm defined by the negotiated AKM in Table 9-133. The PMK identifier is defined as follows: PMKID = L((commit-scalar + peer-commit-scalar) mod r, 0, 128) 12.4.5.5 Construction of an SAE Confirm message A peer generates an SAE Confirm message by passing the KCK, the current value of the send-confirm counter (see 9.4.1.38), the scalar and element from the sent SAE Commit message, and the scalar and element from the received SAE Commit message to the confirmation function CN. confirm = CN(KCK, send-confirm, commit-scalar, COMMIT-ELEMENT, peer-commit-scalar, PEER-COMMIT-ELEMENT) The send-confirm counter shall be in the format specified in subclause 9.2.2 in the order in which it is transmitted over the air. The message shall be transmitted to the peer as described in 12.4.7. 12.4.5.6 Processing of a peerâ€™s SAE Confirm message Upon receipt of a peerâ€™s SAE Confirm message a verifier is computed, which is the expected value of the peerâ€™s confirmation, peer-confirm, extracted from the received an SAE Confirm message. The verifier is computed by passing the KCK, the peerâ€™s send-confirm counter from the received an SAE Confirm message (see 9.4.1.38), the scalar and element from the received SAE Commit message, and scalar and element from the sent SAE Commit message to the confirmation function CN. verifier = CN(KCK, peer-send-confirm, peer-commit-scalar, PEER-COMMIT-ELEMENT, commit-scalar, COMMIT-ELEMENT) The peer-send-confirm shall be in the format in subclause 9.2.2, as extracted out of the received frame. If the verifier equals peer-confirm, the STA shall accept the peerâ€™s authentication and set the lifetime of the PMK to the value dot11RSNAConfigPMKLifetime. If the verifier differs from the peer-confirm, the STA shall reject the peerâ€™s authentication and delete the PMK. 12.4.6 Anti-clogging tokens A STA is required to do a considerable amount of work upon receipt of an SAE Commit message. This opens up the possibility of a distributed denial-of-service attack by flooding a STA with bogus SAE Commit 1943 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications messages from forged MAC addresses. To prevent this from happening, a STA shall maintain an Open counter in its SAE state machine indicating the number of open and unfinished protocol instances (see 12.4.5.1). When that counter hits or exceeds dot11RSNASAEAntiCloggingThreshold, the STA shall respond to each SAE Commit message with a rejection that includes an Anti-Clogging Token statelessly bound to the sender of the SAE Commit message. The sender of the SAE Commit message shall then include this Anti-Clogging Token in a subsequent SAE Commit message. The Anti-Clogging Token is a variable-length value that statelessly binds the MAC address of the sender of an SAE Commit message. The length of the Anti-Clogging Token needs not be specified because the generation and processing of the Anti-Clogging Token is solely up to one peer. To the other peer in the SAE protocol, the Anti-Clogging Token is merely an opaque blob whose length is insignificant. It is suggested that an Anti-Clogging Token not exceed 256 octets. NOTEâ€”A suggested method for producing Anti-Clogging Tokens is to generate a random secret value each time the state machine variable hits dot11RSNASAEAntiCloggingThreshold and pass that secret and the MAC address of the sender of the SAE Commit message to the random function H to generate the token. As long as the state machine variable Open is greater than or equal to dot11RSNASAEAntiCloggingThreshold all SAE Commit messages that do not include a valid Anti- Clogging Token shall be rejected with a request to repeat the SAE Commit message and include the token (see 12.4.5.1). Since the Anti-Clogging Token is of fixed size and the size of the peer-commit-scalar and PEER- COMMIT-ELEMENT are inferred from the finite cyclic group being used, it is straightforward to determine whether a received SAE Commit message includes an Anti-Clogging Token or not. Encoding of the Anti-Clogging Token and its placement with respect to the peer-commit-scalar and PEER- COMMIT-ELEMENT is described in 12.4.7.4. 12.4.7 Framing of SAE 12.4.7.1 General SAE Commit messages and SAE Confirm messages are sent and received by a SAE protocol using Authentication frames. 12.4.7.2 Data type conversion 12.4.7.2.1 General This protocol requires elements in finite cyclic groups to be converted to octet strings prior to transmission and back again upon receipt. To convert an element into an octet string, the first step is to represent the element in integer format and then employ an integer-to-octet string conversion prior to transmission. To convert an octet string into an element requires an octet string to integer conversion and then representing the integer(s) as an element. 12.4.7.2.2 Integer to octet string conversion An integer, x, shall be converted into an octet string of length m such that 28m > x by first representing x in its binary form and then converting the result to an octet-string. Given x, m, represent x as a sequence of xm-i base 28: x = xm-1 28(m-1) + xm-2 28(m-2) + â€¦ + x1 28 + x 0 1944 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications then let the octet Mi have the value xi for 0 i mâ€“1, and the octet string shall be Mm-1 || Mm-2 || ... || M1 || M0. 12.4.7.2.3 Octet string to integer conversion An octet string shall be converted into an integer by viewing the octet string as the base 28 representation of the integer. m x= 28(m-i) Mm-i i=1 12.4.7.2.4 Element to octet string conversion For ECC groups, each element, except the â€œpoint at infinity,â€ is a point on the elliptic curve satisfying the curve equation and consists of two components: an x-coordinate and a y-coordinate. To convert this point to an octet string, each component shall be treated as an integer and converted into an octet string whose length is the smallest integer m such that 28m > p, where p is the prime number specified by the elliptic curve domain parameters, according to 12.4.7.2.2. The point shall be represented as the concatenation of the x- coordinate and the y-coordinate, each represented as an octet string of length m octets, and is 2m octets long. For FFC groups each element is a non-negative integer less than the prime number p specified by the FFC domain parameters. To convert this element into an octet string, it shall be treated directly as an integer and converted into an octet string whose length is the smallest integer m such that 28m > p, where p is the prime number specified by the domain parameters, according to 12.4.7.2.2. 12.4.7.2.5 Octet string to element conversion To convert an octet string into a point on an elliptic curve it is necessary to divide it into two octet strings of equal length m. If the length of the octet string does not evenly divide by two, conversion shall fail. Each octet string of length m shall be converted to an integer according to 12.4.7.2.3. The first octet string conversion produces an integer that becomes the x-coordinate of the point and the second octet string conversion produces an integer that becomes the y-coordinate of the point. If either integer equals 0 or is greater than or equal to p, the prime from the elliptic curve domain parameters, conversion shall fail. If the resulting (x, y) point does not satisfy the equation of the curve, or produces the â€œpoint at infinity,â€ conversion shall fail. To convert an octet string into an element in a prime modulus group the octet string shall be converted into an integer according to 12.4.7.2.3 and the integer shall be used directly as the group element. 12.4.7.3 Authentication transaction sequence number for SAE An SAE Commit message shall use authentication transaction sequence number 1. an SAE Confirm message shall use authentication transaction sequence number 2. 12.4.7.4 Encoding and decoding of SAE Commit messages An SAE Commit message shall be encoded as an Authentication frame with an Authentication Algorithm Number field set to 3, a Transaction Sequence Number of 1 and a Status Code of SUCCESS Status codes not equal to SUCCESS indicate a rejection of a peerâ€™s SAE Commit message and are described in 12.4.7.6. An SAE Commit message shall consist of a Finite Cyclic Group field (9.4.1.43) indicating a group, a Scalar field (9.4.1.40) containing the scalar, and an FFE field containing the element (9.4.1.41). If the SAE Commit 1945 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications message is in response to an Anti-Clogging Token request (see 12.4.7.6), the Anti-Clogging Token is present (see 9.4.1.39). When transmitting an SAE Commit message, the scalar and element shall be converted to octet strings and placed in the Scalar field and FFE field, respectively. The scalar shall be treated as an integer and converted into an octet string of length m such that 28m > r, where r is the order of the group, according to 12.4.7.2.2, and the element shall be converted into (an) octet string(s) according to 12.4.7.2.4. When receiving an SAE Commit message the component octet strings in the Scalar field and Element field shall be converted into a scalar and element, respectively, according to 12.4.7.2.3 and 12.4.7.2.5, respectively. 12.4.7.5 Encoding and decoding of SAE Confirm messages An SAE Confirm message shall be encoded as an Authentication frame with an Authentication Algorithm Number field set to 3, a Transaction Sequence Number of 2 and a Status Code of SUCCESS. Status codes not equal to SUCCESS indicate rejection of a peerâ€™s SAE Confirm message and are described in 12.4.7.6. An SAE Confirm message shall consist of a Send-Confirm field (9.4.1.38) and a Confirm field (9.4.1.42) containing the output of the random function as described in 12.4.5.5. When transmitting an SAE Confirm message the output of the random function shall be treated as an integer and converted into an octet string of length m, where m is the block size of the random function, according to 12.4.7.2.2 and placed in the Confirm field. When receiving an SAE Confirm message, the octet string in the Confirm field shall be converted into an integer representing the peerâ€™s Confirm according to 12.4.7.2.3. 12.4.7.6 Status codes An SAE Commit message with a status code not equal to SUCCESS shall indicate that a peer rejects a previously sent SAE Commit message. An unsupported finite cyclic group is indicated with a status code of UNSUPPORTED_FINITE_CYCLIC_GROUP, â€œAuthentication is rejected because the offered finite cyclic group is not supported.â€ An Anti-Clogging Token is requested by transmitting an SAE Commit message with a status code of ANTI_CLOGGING_TOKEN_REQUIRED, â€œAnti-Clogging Token Requested,â€ with the Anti-Clogging Token occupying the Token field of the Authentication frame. An SAE Confirm message, with a status code not equal to SUCCESS, shall indicate that a peer rejects a previously sent SAE Confirm message. An SAE Confirm message that was not successfully verified is indicated with a status code of CHALLENGE_FAILURE. 12.4.8 SAE finite state machine 12.4.8.1 General The protocol is instantiated by the finite state machine in Figure 12-4. Each instance of the protocol is identified by a tuple consisting of the local MAC address and the peer MAC address. The model in which SAE is defined consists of a parent process, managed by the SME, which receives messages, and dispatches them to the appropriate protocol instance, also managed by the SME. The parent process manages a database of protocol instances indexed by the peer identity. Protocol instances maintain state, receive events from the parent process, send events to itself, and output data. NOTEâ€”Figure 12-4 does not show all state machine transitions. A full description of the SAE finite state machine is in 12.4.8.6.2 to 12.4.8.6.6. The parent process instantiates protocol instances upon receipt of SAE messages and initiation by SME. The parent process also maintains a counter of the number of protocol instances created. 1946 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications (Com,BadGrp)/(1(77),Del) Rej(76)/Del Rej(77)/Del Init/(zero(Sync), zero(Sc), Zero(Rc), 1(0), set(t0)) Nothing (Com,!BadGrp)/zero(Sync), zero(Sc), zero(Rc),inc(Sc), 1(0),2,set(t0)) (Com,BadGrp, !big(Sync))/ big(Sync)/Del (1(77), inc(Sync), (Com,!big(Sync)/(inc(Sc), set(t0)) Rej(77), big(sync)/Del inc(Sync), 1(0),2,set(t0)) (Rej(77),moregroups)/ !moregroups/Del (zero(Sync), Rej(76)/ 1(0), set(t0)) set(t0) (Con,BadAuth)/Del (Con,!big(Sync))/ (inc(Sync), Committed Confirmed 1(0),set(t0)) (fire(t0),!big(Sync)/ (inc(Sync),1(0),set(t0)) (Com,!BadGrp,!DiffGrp)/ Rej(76)/ (fire(t0),!big(Sync))/ (inc(Sc), (Com,DiffGrp,highmac)/ (zero(Sync), (inc(Sc),inc(Sync),2,set(t0)) 2,set(t0)) (1(0), set(t0)) 1(0),set(t0)) (Com,DiffGrp,lowmac)/ (zero(Sync), inc(Sc), 1(0),2,set(t0)) (Con,!BadAuth)/set(t1)) Accepted big(Sync)/Del (Con,!Big(Rc),!big(Sync))/ - fire(t1)/Del (Con,!BadAuth,!big(Sync))/ (inc(Sync), 2) Figure 12-4â€”SAE finite state machine 12.4.8.2 States 12.4.8.2.1 Parent process states The parent process is in a continuous quiescent state. 12.4.8.2.2 Protocol instance states Each protocol instance is in one of the following four states: â€” Nothingâ€”The Nothing state represents the initial state of a freshly allocated protocol instance or the terminal state of a soon-to-be deallocated protocol instance. Freshly created protocol instances will immediately transition out of Nothing state depending on the reason for their creation. Protocol instances that transition into Nothing state shall immediately be irretrievably deleted. â€” Committedâ€”In the Committed state, the finite state machine has sent an SAE Commit message and is awaiting an SAE Commit message and an SAE Confirm message from the peer. â€” Confirmedâ€”In the Confirmed state, the finite state machine has sent both an SAE Commit message and an SAE Confirm message and received an SAE Commit message. It awaits an SAE Confirm message. â€” Acceptedâ€”In the Accepted state, the protocol instance has both sent and received an SAE Commit message and an SAE Confirm message and the protocol instance has finished. 1947 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 12.4.8.3 Events and output 12.4.8.3.1 Parent process events and output The parent process receives events from three sources: the SME, protocol instances, and received frames. The SME signals the following events to the parent SAE process: â€” Initiateâ€”An Initiate event is used to instantiate a protocol instance to begin SAE with a designated peer. â€” Killâ€”A Kill event is used to remove a protocol instance with a designated peer. Protocol instances send the following events to the SAE parent process: â€” Failâ€”The peer failed to be authenticated. â€” Authâ€”The peer was successfully authenticated. â€” Delâ€”The protocol instance has had a fatal event. Receipt of frames containing SAE messages signals the following events to the SAE parent process: â€” Authentication frame with Transaction Sequence number 1â€”This event indicates that an SAE Commit message has been received from a peer STA. â€” Authentication frame with Transaction Sequence number 2â€”This event indicates that an SAE Confirm message has been received from a peer STA. The parent process generates Authentication frames with Authentication transaction sequence 1 and a Status of 76 indicating rejection of an Authentication attempt because an Anti-Clogging Token is required. 12.4.8.3.2 Protocol instance events and output The protocol instance receives events from the parent SAE process. â€” Comâ€”Indicates receipt of an SAE Commit message (authentication transaction sequence number 1) with a status of 0. â€” Conâ€”Indicates receipt of an SAE Confirm message (authentication transaction sequence number 2) with a status of 0. â€” Initâ€”Indicates that the protocol instance should begin negotiation with a specified peer. â€” Rej(N)â€”Indicates receipt of a rejected SAE Commit message with status N. In addition, protocol instances receive fire(X) events indicating the expiration of timer X. Upon expiration of a timer and generation of a fire() event, the expired timer is not reset. The protocol instance generates output from the following events: â€” 1(N)â€”Indicates generation of an SAE Commit message (authentication transaction sequence number 1) with status N. â€” 2â€”Indicates generation of an SAE Confirm message (authentication transaction sequence number 2). 12.4.8.4 Timers The parent SAE process does not use timers. Each protocol instance can set timers that result in fire() events to be sent to itself. The following timers can be set: â€” t0â€”A retransmission timer. â€” t1â€”A PMK expiration timer. 1948 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Timers are set by the protocol instance issuing a set() for the particular timer. 12.4.8.5 Variables 12.4.8.5.1 Parent process variables The parent SAE process maintains a counter, Open, which indicates the number of protocol instances in either Committed or Confirmed state. When the parent SAE process starts up, Open is set to 0. The parent process maintains a database of protocol instances. NOTEâ€”Depending on how Anti-Clogging Tokens (see 12.4.6) are constructed, the parent SAE process might also maintain a random secret used for token creation. 12.4.8.5.2 Protocol instance variables Each protocol instance maintains the following three variables: â€” Syncâ€”The number of state resynchronizations that have occurred. â€” Scâ€”The number of SAE Confirm messages that have been sent. This is the send-confirm counter used in the construction of SAE Confirm messages (see 12.4.5.5). â€” Rcâ€”The received value of the send-confirm counter in the last received SAE Confirm message. In other words, this is the value of the peerâ€™s send-confirm counter. Function zero(X) assigns the value 0 to the variable X, inc(X) increments the variable X, and big(X) indicates that the variable X has exceeded a maximum value. In addition, protocol instances maintain the following six indicators that are not maintained as state variables but, instead, indicate the cause of certain behavior. â€” BadGrpâ€”The group specified in an SAE Commit message is not supported. â€” DiffGrpâ€”The group specified in an SAE Commit message is supported but differs from the one offered. â€” BadConfâ€”The contents of a confirm frame were incorrect. â€” highmacâ€”The peer identity is numerically less than the local identity. â€” lowmacâ€”The peer identity is numerically greater than the local identity. â€” moregroupsâ€”There are finite cyclic groups in the configuration that have not been offered to the peer. A negative indication is shown with an exclamation point (!)â€”e.g., â€œthe group specified in an SAE Commit message is supportedâ€ would be !BadGrp, which is read as â€œnot BadGrp.â€ 12.4.8.6 Behavior of state machine 12.4.8.6.1 Parent process behavior For any given peer identity, there shall be only one protocol instance in Committed or Confirmed state. Similarly, for any given peer identity, there shall be only one protocol instance in Accepted state. The parent process creates protocol instances based upon different actions. Creating a protocol instance entails allocation of state necessary to maintain the protocol instance state machine, putting the protocol instance in Nothing state, incrementing the Open counter, and inserting the protocol instance into its database indexed by the MAC address of the peer with whom the protocol instance will communicate. 1949 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The parent process shall delete protocol instances irretrievably. Upon receipt of an Initiate event, the parent process shall check whether there exists a protocol instance for the peer MAC address (from the Init event) in either Committed or Confirmed state. If there is, the Initiate event shall be ignored. Otherwise, a protocol instance shall be created, and an Init event shall be sent to the protocol instance. Upon receipt of a Kill event, the parent process shall delete all protocol instances indexed by the peer MAC address (from the Kill event) in its database. For each protocol instance in Committed or Confirmed state, the Open counter shall be decremented. Upon receipt of a Sync, Del, or Fail event from a protocol instance, the parent process shall decrement the Open counter and deletes the protocol instance. Upon receipt of an Auth event from a protocol instance, the parent process shall decrement the Open counter. If another protocol instance exists in the database indexed by the same peer identity as the protocol instance that sent the Auth event, the other protocol instance shall be deleted. Upon receipt of an SAE Commit message, the parent process checks whether a protocol instance for the peer MAC address exists in the database. If one does, and it is in either Committed state or Confirmed state the frame shall be passed to the protocol instance. If one does and it is in Accepted state, the scalar in the received frame is checked against the peer-scalar used in authentication of the existing protocol instance (in Accepted state). If it is identical, the frame shall be dropped. If not, the parent process checks the value of Open. If Open is greater than dot11RSNASAEAntiCloggingThreshold, the parent process shall check for the presence of an Anti-Clogging Token. If an Anti-Clogging Token exists and is correct, the parent process shall create a protocol instance. If the Anti-Clogging Token is incorrect, the frame shall be silently discarded. If Open is greater than or equal to dot11RSNASAEAntiCloggingThreshold and there is no Anti- Clogging Token in the received frame, the parent process shall construct a response as an Authentication frame with the Authentication Transaction Sequence Number field set to 1, the Status Code field set to ANTI_CLOGGING_TOKEN_REQUIRED, and the body of the frame consisting of an Anti-Clogging Token (see 12.4.6). If Open is less than dot11RSNASAEAntiCloggingThreshold, the parent process shall create a protocol instance and the frame shall be sent to the protocol instance as a Com event. Upon receipt of an SAE Confirm message, the parent process checks whether a protocol instance for the peer MAC address (as indicated by the SA in the received frame) exists in the database. If there is a single protocol instance, the frame shall be passed to it as a Con event. If there are two protocol instances indexed by that peer MAC address, the frame shall be passed, as a Con event, to the protocol instance that is not in Accepted state. If there are no protocol instances indexed by that peer MAC address, the frame shall be dropped. 12.4.8.6.2 Protocol instance behaviorâ€”General State machine behavior is illustrated in Figure 12-4. The protocol instance receives events from the parent process and from itself. It generates SAE messages that are transmitted to a peer and sends events to itself and the parent process. The semantics of the state diagram are â€œoccurrence/behaviorâ€ where â€œoccurrenceâ€ is a comma-separated list of events and/or indicators, or the special symbol â€œâ€”â€ indicating no occurrence; and, â€œbehaviorâ€ is a comma-separated list of outputs and/or functions, or the special symbol â€œâ€”â€ indicating no behavior. When the state machine calls for the t0 (retransmission) timer to be set, it shall be set to dot11RSNASAERetransPeriod. When the state machine calls for the t1 (key expiration) timer to be set, it shall be set to dot11RSNAConfigPMKLifetime. 1950 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 12.4.8.6.3 Protocol instance behavior - Nothing state In Nothing state a protocol instance has just been allocated. Upon receipt of an Init event, the protocol instance shall zero its Sync variable, Rc, and Sc variables, select a group from local configuration and generate the PWE and the secret values according to 12.4.5.2, generate an SAE Commit message (see 12.4.5.3), and set its t0 (retransmission) timer. The protocol instance transitions into Committed state. Upon receipt of a Com event, the protocol instance shall check the Status of the Authentication frame. If the Status code is not SUCCESS, the frame shall be silently discarded and a Del event shall be sent to the parent process. Otherwise, the frame shall be processed by first checking the finite cyclic group field to see if the requested group is supported. If not, BadGrp shall be set and the protocol instance shall construct and transmit a an Authentication frame with Status code UNSUPPORTED_FINITE_CYCLIC_GROUP indicating rejection with the finite cyclic group field set to the rejected group, and shall send the parent process a Del event. If the group is supported, the protocol instance shall zero the Sc and Rc counters and it shall generate the PWE and the secret values according to 12.4.5.2. It shall then process the received SAE Commit message (see 12.4.5.4). If validation of the received SAE Commit message fails, the protocol instance shall send a Del event to the parent process; otherwise, it shall construct and transmit an SAE Commit message (see 12.4.5.3) followed by an SAE Confirm message (see 12.4.5.5). The Sync counter shall be set to 0 and the t0 (retransmission) timer shall be set. The protocol instance transitions to Confirmed state. NOTEâ€”A protocol instance in Nothing state will never receive an SAE Confirm message due to state machine behavior of the parent process. 12.4.8.6.4 Protocol instance behavior - Committed state In Committed state, a protocol instance has sent its peer an SAE Commit message but has yet to receive (and accept) anything. Upon receipt of a Com event, the t0 (retransmission) timer shall be canceled. Then the following is performed: â€” The protocol instance shall check the Status code of the Authentication frame. If the Status code is ANTI_CLOGGING_TOKEN_REQUIRED, a new SAE Commit message shall be constructed with the Anti-Clogging Token from the received Authentication frame, and the commit-scalar and COMMIT-ELEMENT previously sent. The new SAE Commit message shall be transmitted to the peer, Sync shall be zeroed, and the t0 (retransmission) timer shall be set. â€” If the Status code is UNSUPPORTED_FINITE_CYCLIC_GROUP, the protocol instance shall check the finite cyclic group field being rejected. If the rejected group does not match the last offered group the protocol instance shall silently discard the message and set the t0 (retransmission) timer. If the rejected group matches the last offered group, the protocol instance shall choose a different group and generate the PWE and the secret values according to 12.4.5.2; it then generates and transmits a new SAE Commit message to the peer, zeros Sync, sets the t0 (retransmission) timer, and remains in Committed state. If there are no other groups to choose, the protocol instance shall send a Del event to the parent process and transitions back to Nothing state. â€” If the Status is some other nonzero value, the frame shall be silently discarded and the t0 (retransmission) timer shall be set. â€” If the Status is zero, the finite cyclic group field is checked. If the group is not supported, BadGrp shall be set and the value of Sync shall be checked. â€” If Sync is greater than dot11RSNASAESync, the protocol instance shall send a Del event to the parent process and transitions back to Nothing state. â€” If Sync is not greater than dot11RSNASAESync, Sync shall be incremented, an SAE Commit message with Status code equal to UNSUPPORTED_FINITE_CYCLIC_GROUP indicating 1951 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications rejection, and the Algorithm identifier set to the rejected algorithm shall be sent to the peer, the t0 (retransmission) timer shall be set and the protocol instance shall remain in Committed state. â€” If the group is supported but does not match that used when the protocol instance constructed its SAE Commit message, DiffGrp shall be set and the local identity and peer identity shall be checked. â€” The mesh STA, with the numerically greater of the two MAC addresses, drops the received SAE Commit message, retransmits its last SAE Commit message, and shall set the t0 (retransmission) timer and remain in Committed state. â€” The mesh STA, with the numerically lesser of the two MAC addresses, zeros Sync, shall increment Sc, choose the group from the received SAE Commit message, generate new PWE and new secret values according to 12.4.5.2, process the received SAE Commit message according to 12.4.5.4, generate a new SAE Commit message and SAE Confirm message, and shall transmit the new Commit and Confirm to the peer. It shall then transition to Confirmed state. â€” If the group is supported and matches that used when the protocol instance constructed its SAE Commit message, the protocol instance checks the peer-commit-scalar and PEER-COMMIT- ELEMENT from the message. If they match those sent as part of the protocol instanceâ€™s own SAE Commit message, the frame shall be silently discarded (because it is evidence of a reflection attack) and the t0 (retransmission) timer shall be set. If the received element and scalar differ from the element and scalar offered, the received SAE Commit message shall be processed according to 12.4.5.4, the Sc counter shall be incremented (thereby setting its value to one), the protocol instance shall then construct an SAE Confirm message, transmit it to the peer, and set the t0 (retransmission) timer. It shall then transition to Confirmed state. If the t0 (retransmission) timer fires, the value of the Sync counter is checked. If Sync is greater than dot11RSNASAESync, the protocol instance shall send a Del event to the parent process and transition back to Nothing state. If Sync is not greater than dot11RSNASAESync, the Sync counter shall be incremented, the last message sent shall be sent again, and the t0 (retransmission) timer shall be set. Upon receipt of a Con event, the t0 (retransmission) timer shall be canceled. Then the protocol instance checks the value of Sync. If it is greater than dot11RSNASAESync, the protocol instance shall send a Del event to the parent process and transition back to Nothing state. If Sync is not greater than dot11RSNASAESync, the protocol instance shall increment Sync, transmit the last SAE Commit message sent to the peer, and set the t0 (retransmission) timer. 12.4.8.6.5 Protocol instance behavior - Confirmed state In Confirmed state, a protocol instance has sent its peer an SAE Commit message and SAE Confirm message. It has received an SAE Commit message from its peer. Rejection frames received in Confirmed state shall be silently discarded. Upon receipt of a Com event, the t0 (retransmission) timer shall be canceled. If the Status is nonzero, the frame shall be silently discarded, the t0 (retransmission) timer set, and the protocol instance shall remain in the Confirmed state. If Sync is greater than dot11RSNASAESync, the protocol instance shall send the parent process a Del event and transitions back to Nothing state. If Sync is not greater than dot11RSNASAESync, the protocol instance shall verify that the finite cyclic group is the same as the previously received Commit frame. If not, the frame shall be silently discarded. If so, the protocol instance shall increment Sync, increment Sc, and transmit its Commit and Confirm (with the new Sc value) messages. It then shall set the t0 (retransmission) timer. Upon receipt of a Con event, the t0 (retransmission) timer shall be canceled and the SAE Confirm message shall be processed according to 12.4.5.6. If processing is successful and the SAE Confirm message has been 1952 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications verified, the Rc variable shall be set to the send-confirm portion of the frame, Sc shall be set to the value 216 â€“ 1, the t1 (key expiration) timer shall be set, and the protocol instance shall transition to Accepted state. If the t0 (retransmission) timer fires, the value of the Sync counter shall be checked. If Sync is greater than dot11RSNASAESync, the protocol instance shall send a Del event to the parent process and transition back to Nothing state. If Sync is not greater than dot11RSNASAESync, the Sync counter shall be incremented, Sc shall be incremented, and the protocol instance shall create a new Confirm (with the new Sc value) Message, transmit it to the peer, and set the t0 (retransmission) timer. 12.4.8.6.6 Protocol instance behavior - Accepted state In Accepted state, a protocol instance has sent an SAE Commit message and an SAE Confirm message to its peer and received an SAE Commit message and SAE Confirm message from the peer. Unfortunately, there is no guarantee that the final SAE Confirm message sent by the STA was received by the peer. Upon receipt of a Con event, the Sync counter shall be checked. If the value is greater than dot11RSNASAESync, the protocol instance shall send a Del event to the parent process and shall transition to Nothing state. If the value of Sync is not greater than dot11RSNASAESync, the value of send-confirm shall be checked. If the value is not greater than Rc or is equal to 216 â€“ 1, the received frame shall be silently discarded. Otherwise, the Confirm portion of the frame shall be checked according to 12.4.5.6. If the verification fails, the received frame shall be silently discarded. If the verification succeeds, the Rc variable shall be set to the send-confirm portion of the frame, the Sync shall be incremented and a new SAE Confirm message shall be constructed (with Sc set to 216 â€“ 1) and sent to the peer. The protocol instance shall remain in Accepted state. If the t1 (key expiration) timer fires, the protocol instance shall send the parent process a Del event and transition to Nothing state. 12.5 RSNA confidentiality and integrity protocols 12.5.1 Overview This standard defines the following RSNA data confidentiality and integrity protocols: TKIP, CCMP, and GCMP. This standard defines one integrity protocol for Management frames: BIP. Implementation of TKIP is optional for an RSNA and used only for the protection of Data frames. A design aim for TKIP was that the algorithm should be implementable within the capabilities of most devices supporting only WEP, so that many such devices would be field-upgradable by the supplier to support TKIP. BIP is a mechanism that is used only when management frame protection is negotiated. BIP provides integrity protection for group addressed robust Management frames. BIP is used only to protect Management frames within the BSS. 12.5.2 Temporal key integrity protocol (TKIP) 12.5.2.1 TKIP overview 12.5.2.1.1 General The TKIP is a cipher suite enhancing WEP on pre-RSNA hardware. TKIP modifies WEP as follows: a) A transmitter calculates a keyed cryptographic message integrity code (MIC) over the MSDU SA and DA, the MSDU priority (see 12.5.2.3), and the MSDU plaintext data. TKIP appends the computed MIC to the MSDU data prior to fragmentation into MPDUs. The receiver verifies 1953 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications the MIC after decryption, ICV checking, and defragmentation of the MPDUs into an MSDU and discards any received MSDUs with invalid MICs. TKIPâ€™s MIC provides a defense against forgery attacks. b) Because of the design constraints of the TKIP MIC, it is still possible for an adversary to compromise message integrity; therefore, TKIP also implements countermeasures. The countermeasures bound the probability of a successful forgery and the amount of information an attacker can learn about a key. c) TKIP uses a per-MPDU TKIP sequence counter (TSC) to sequence the MPDUs it sends. The receiver drops MPDUs received out of order, i.e., not received with increasing sequence numbers. This provides replay protection. TKIP encodes the TSC value from the sender to the receiver as a WEP IV and extended IV. d) TKIP uses a cryptographic mixing function to combine a temporal key, the TA, and the TSC into the WEP seed. The receiver recovers the TSC from a received MPDU and utilizes the mixing function to compute the same WEP seed needed to correctly decrypt the MPDU. The key mixing function is designed to defeat weak-key attacks against the WEP key. TKIP defines additional MIB variables; see Annex C. 12.5.2.1.2 TKIP cryptographic encapsulation TKIP enhances the WEP cryptographic encapsulation with several additional functions, as depicted in Figure 12-5. W E P seed(s) TA (represented as W E P P hase 1 TTA K IV TK key + A R C 4 key) m ixing IV P hase 2 ARC 4 key TS C key m ixing C iphertext W EP M P D U (s) DA + SA + E ncapsulation P riority + P laintext M S D U Fragm ent(s) D ata M ichael P laintext M IC K ey MSDU + M IC Figure 12-5â€”TKIP encapsulation block diagram a) TKIP MIC computation protects the MSDU Data field and corresponding SA, DA, and Priority fields. The computation of the MIC is performed on the ordered concatenation of the SA, DA, Priority, and MSDU Data fields. The MIC is appended to the MSDU Data field. TKIP discards any MIC padding prior to appending the MIC. b) If needed, the MSDU with MIC is fragmented into one or more MPDUs. TKIP assigns a monotonically increasing TSC value to each MPDU, taking care that all of the MPDUs generated from the same MSDU have the same value of extended IV (see 12.5.2.2). c) For each MPDU, TKIP uses the key mixing function to compute the WEP seed. d) TKIP represents the WEP seed as a WEP IV and ARC4 key and passes these with each MPDU to WEP for generation of the ICV (see 9.2.4.7), and for encryption of the plaintext MPDU, including all or part of the MIC, if present. WEP uses the WEP seed as a WEP default key, identified by a key identifier associated with the temporal key. 1954 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NOTEâ€”When the TSC space is exhausted, the choices available to an implementation are to replace the temporal key with a new one or to end communications. Reuse of any TSC value compromises already sent traffic. Note that retransmitted MPDUs reuse the TSC without any compromise of security. The TSC is large enough, however, that TSC space exhaustion is not expected to be an issue. In Figure 12-5, the TKIP-mixed transmit address and key (TTAK) denotes the intermediate key produced by Phase 1 of the TKIP mixing function (see 12.5.2.5). 12.5.2.1.3 TKIP decapsulation TKIP enhances the WEP decapsulation process with the following additional steps: a) Before WEP decapsulates a received MPDU, TKIP extracts the TSC sequence number and key identifier from the WEP IV and the extended IV. TKIP discards a received MPDU that violates the sequencing rules (see 12.5.2.6) and otherwise uses the mixing function to construct the WEP seed. b) TKIP represents the WEP seed as a WEP IV and ARC4 key and passes these with the MPDU to WEP for decapsulation. c) If WEP indicates the ICV check succeeded, the implementation reassembles the MPDU into an MSDU. If the MSDU defragmentation succeeds, the receiver verifies the TKIP MIC. If MSDU defragmentation fails, then the MSDU is discarded. d) The MIC verification step recomputes the MIC over the MSDU SA, DA, Priority, and MSDU Data fields (but not the TKIP MIC field). The calculated TKIP MIC result is then compared bitwise to the received MIC. e) If the received and the locally computed MIC values are identical, the verification succeeds, and TKIP shall deliver the MSDU to the upper layer. If the two differ, then the verification fails; the receiver shall discard the MSDU and shall engage in appropriate countermeasures. Figure 12-6 depicts this process. MIC Key TA Phase 1 key mixing TK TTAK Phase 2 WEP Seed key mixing TKIP TSC Unmix TSC DA + SA + Priority Michael TSC + Plaintext MSDU WEP MIC' Reassemble In-sequence Decapsulation MPDU Plaintext MIC Ciphertext MPDU MIC = MPDU MIC'? MSDU with failed Out-of-sequence TKIP MIC MPDU Countermeasures Figure 12-6â€”TKIP decapsulation block diagram 1955 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 12.5.2.2 TKIP MPDU formats TKIP reuses the pre-RSNA WEP MPDU format. It extends the MPDU by 4 octets to accommodate an extension to the WEP IV, denoted by the Extended IV field, and extends the MSDU format by 8 octets to accommodate the new MIC field. TKIP inserts the Extended IV field immediately after the WEP IV field and before the encrypted data. TKIP appends the MIC to the MSDU Data field; the MIC becomes part of the encrypted data. Once the MIC is appended to the MSDU data, the added MIC octets are considered part of the MSDU for subsequent fragmentation. Figure 12-7 depicts the layout of the encrypted MPDU when using TKIP. Note that the figure only depicts the case when the MSDU can be encapsulated in a single MPDU. Key ID Figure 12-7â€”Construction of expanded TKIP MPDU The ExtIV bit in the Key ID octet indicates the presence or absence of an extended IV. If the ExtIV bit is 0, only the nonextended IV is transferred. If the ExtIV bit is 1, an extended IV of 4 octets follows the original IV. For TKIP the ExtIV bit shall be set to 1, and the Extended IV field shall be supplied. The ExtIV bit shall be 0 for WEP frames. The Key ID field shall be set to the key index supplied by the MLME- SETKEYS.request primitive for the key used in cryptographic encapsulation of the frame. TSC5 is the most significant octet of the TSC, and TSC0 is the least significant. Octets TSC0 and TSC1 form the IV sequence number and are used with the TKIP Phase 2 key mixing. Octets TSC2â€“TSC5 are used in the TKIP Phase 1 key hashing and are in the Extended IV field. When the lower 16-bit sequence number rolls over (0xFFFF 0x0000), the extended IV value, i.e., the upper 32 bits of the entire 48-bit TSC, shall be incremented by 1. NOTEâ€”The rationale for this construction is as follows: â€” Aligning on word boundaries eases implementation on legacy devices. â€” Adding 4 octets of extended IV eliminates TSC exhaustion as a reason to rekey. â€” Key ID octet changes. Bit 5 indicates that an extended IV is present. The receiver/transmitter interprets the 4 octets following the Key ID as the extended IV. The receiving/transmitting STA also uses the value of octets TSC0 and TSC1 to detect that the cached TTAK needs to be updated. The Extended IV field shall not be encrypted. WEPSeed[1] is not used to construct the TSC, but is set to (TSC1 | 0x20) & 0x7f. TKIP shall encrypt all of the MPDUs generated from one MSDU under the same temporal key. 1956 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 12.5.2.3 TKIP MIC 12.5.2.3.1 General Flaws in the IEEE 802.11 WEP design cause it to fail to meet its goal of protecting data traffic content from casual eavesdroppers. Among the most significant WEP flaws is the lack of a mechanism to defeat message forgeries and other active attacks. To defend against active attacks, TKIP includes a MIC, called michael. This MIC offers only weak defenses against message forgeries, but it constitutes the best that can be achieved with the majority of legacy hardware. TKIP uses different MIC keys depending on the direction of the transfer as described in 12.8.1 and 12.8.2. Annex J contains an implementation of the TKIP MIC. It also provides test vectors for the MIC. 12.5.2.3.2 Motivation for the TKIP MIC Before defining the details of the MIC, it is useful to review the context in which this mechanism operates. Active attacks enabled by the original WEP design include the following: â€” Bit-flipping attacks â€” Data (payload) truncation, concatenation, and splicing â€” Fragmentation attacks â€” Iterative guessing attacks against the key â€” Redirection by modifying the MPDU DA or RA field â€” Impersonation attacks by modifying the MPDU SA or TA field The MIC makes it more difficult for any of these attacks to succeed. All of these attacks remain at the MPDU level with the TKIP MIC. The MIC, however, applies to the MSDU, so it blocks successful MPDU-level attacks. TKIP applies the MIC to the MSDU at the transmitter and verifies it at the MSDU level at the receiver. If a MIC check fails at the MSDU level, the implementation shall discard the MSDU and invoke countermeasures (see 12.5.2.4). Informative Figure 12-8 depicts different peer layers communicating. Figure 12-8â€”TKIP MIC relation to IEEE 802.11 processing (informative) This figure depicts an architecture where the MIC is logically appended to the raw MSDU in response to the MA-UNITDATA.request primitive. The TKIP MIC is computed over â€” The MSDU DA â€” The MSDU SA â€” The MSDU Priority â€” The entire unencrypted MSDU data (payload) 1957 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The DA field, SA field, three reserved octets, and a 1-octet Priority field are used only for calculating the MIC. The Priority field refers to the priority parameter of the MA-UNITDATA.request primitive. The fields in Figure 12-9 are treated as an octet stream using the conventions described in 9.2.2. 6 6 1 3 M 1 1 1 1 1 1 1 1 octets DA SA Priority 0 Data M M M M M M M M 0 1 2 3 4 5 6 7 Figure 12-9â€”TKIP MIC processing format TKIP appends the MIC at the end of the MSDU. The MIC is 8 octets in size for michael. The IEEE 802.11 MAC then applies its normal processing to transmit this MSDU-with-MIC as a sequence of one or more MPDUs. In other words, the MSDU-with-MIC can be partitioned into one or more MPDUs, the WEP ICV is calculated over each MPDU, and the MIC can even be partitioned to lie in two MPDUs after fragmentation. The TKIP MIC augments, but does not replace, the WEP ICV. Because the TKIP MIC is a weak construction, TKIP protects the MIC with encryption, which makes TKIP MIC forgeries more difficult. The WEP ICV helps to prevent false detection of MIC failures that would cause countermeasures to be invoked. The receiver reverses this procedure to reassemble the MSDU; and, after the MSDU has been logically reassembled, the IEEE 802.11 MAC verifies the MIC prior to delivery of the MSDU to upper layers. If the MIC validation succeeds, the MAC delivers the MSDU. If the MIC validation fails, the MAC shall discard the MSDU and invoke countermeasures (see 12.5.2.4). NOTEâ€”TKIP calculates the MIC over the MSDU rather than the MPDU, because doing so increases the implementation flexibility with preexisting WEP hardware. Note that a MIC alone cannot provide complete forgery protection, as it cannot defend against replay attacks. Therefore, TKIP provides replay detection by TSC sequencing and ICV validation. Furthermore, if TKIP is utilized with a GTK, an insider STA can masquerade as any other STA belonging to the group. 12.5.2.3.3 Definition of the TKIP MIC Michael generates a 64-bit MIC. The michael key consists of 64 bits, represented as an 8-octet sequence, k0...k7. This is converted to two 32-bit words, K0 and K1. Throughout this subclause, all conversions between octets and 32-bit words shall use the little endian conventions, given in 9.2.2. Michael operates on each MSDU including the Priority field, 3 reserved octets, SA field, and DA field. An MSDU consists of octets m0...mnâ€“1 where n is the number of MSDU octets, including SA, DA, Priority, and Data fields. The message is padded at the end with a single octet with value 0x5a, followed by between 4 and 7 zero octets. The number of zero octets is chosen so that the overall length of the padded MSDU is a multiple of four. The padding is not transmitted with the MSDU; it is used to simplify the computation over the final block. The MSDU is then converted to a sequence of 32-bit words M0 ...MNâ€“1, where N = (n+5)/ 4 . By construction, MNâ€“1 = 0 and MNâ€“2 0. The MIC value is computed iteratively starting with the key value (K0 and K1) and applying a block function b for every message word, as shown in Figure 12-10. The algorithm loop runs a total of N times (i takes on the values 0 to Nâ€“1 inclusive), where N is as above, the number of 32-bit words composing the padded MSDU. The algorithm results in two words (l and r), which are converted to a sequence of 8 octets using the least-significant-octet-first convention: â€” M0 = l & 0xff â€” M1 = (l/0x100) & 0xff â€” M2 = (l/0x10000) & 0xff â€” M3 = (l/0x1000000) & 0xff 1958 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” M4 = r & 0xff â€” M5 = (r/0x100) & 0xff â€” M6 = (r/0x10000) & 0xff â€” M7 = (r/0x1000000) & 0xff This is the MIC value. The MIC value is appended to the MSDU as data to be sent. Input: Key (K0, K1) and padded MSDU (represented as 32-bit words) M0 ... MNâ€“1 Output: MIC value (V0, V1) MICHAEL((K0, K1) , (M0, ... , MN)) (l,r) (K0, K1) for i = 0 to Nâ€“1 do l I Mi (l,r) b(l,r) return (l,r) Figure 12-10â€”Michael message processing Figure 12-11 defines the michael block function b. It is a Feistel-type construction with alternating additions and XOR operations. It uses <<< to denote the rotate-left operator on 32-bit values, >>> for the rotate-right operator, and XSWAP for a function that swaps the position of the 2 least significant octets. It also uses the position of the two most significant octets in a word. In p u t: (l,r) O u tp u t: ( l,r) b ( L ,R ) r r (l < < < 1 7 ) l (l + r ) m o d 2 32 r r X S W A P (l ) l (l + r ) m o d 2 32 r r (l < < < 3 ) l (l + r ) m o d 2 32 r r (l > > > 2 ) l (l + r ) m o d 2 32 re tu r n (l , r ) Figure 12-11â€”Michael block function 12.5.2.4 TKIP countermeasures procedures 12.5.2.4.1 General The TKIP MIC trades off security in favor of implementability on pre-RSNA STAs. Michael provides only weak protection against active attacks. A failure of the MIC in a received MSDU indicates a probable active attack. A successful attack against the MIC would mean an attacker could inject forged Data frames and perform further effective attacks against the encryption key itself. If TKIP implementation detects a probable active attack, TKIP shall take countermeasures as specified in this subclause. These countermeasures accomplish the following goals: â€” MIC failure events should be logged as a security-relevant matter. A MIC failure is an almost certain indication of an active attack and warrants a follow-up by the system administrator. â€” The rate of MIC failures needs to be kept below two per minute. This implies that STAs and APs detecting two MIC failure events within 60 s need to disable all receptions using TKIP for a period of 60 s. The slowdown makes it difficult for an attacker to make a large number of forgery attempts in a short time. 1959 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” As an additional security feature, the PTK and, in the case of the Authenticator, the GTK should be changed. Before verifying the MIC, the receiver shall check the FCS, ICV, and TSC for all related MPDUs. Any MPDU that has an invalid FCS, an incorrect ICV, or a TSC value that is less than or equal to the TSC replay counter shall be discarded before checking the MIC. This avoids unnecessary MIC failure events. Checking the TSC before the MIC makes countermeasure-based denial-of-service attacks harder to perform. While the FCS and ICV mechanisms are sufficient to detect noise, they are insufficient to detect active attacks. The FCS and ICV provide error detection, but not integrity protection. A single counter or timer shall be used to log MIC failure events. These failure events are defined as follows: â€” In an Authenticator: â€” Detection of a MIC failure on a received individually addressed frame. â€” Receipt of Michael MIC Failure Report frame. â€” In a Supplicant: â€” Detection of a MIC failure on a received individually addressed or group addressed frame. â€” Attempt to transmit a Michael MIC Failure Report frame. The number of MIC failures is accrued independent of the particular key context. Any single MIC failure, whether detected by the Supplicant or the Authenticator and whether resulting from a group MIC key failure or a pairwise MIC key failure, shall be treated as cause for a MIC failure event. The Supplicant uses a single Michael MIC Failure Report frame to report a MIC failure event to the Authenticator. A Michael MIC Failure Report is an EAPOL-Key frame with the following Key Information field bits set to 1: MIC bit, Error bit, Request bit, Secure bit. The Supplicant protects this message with the current PTK; the Supplicant uses the KCK portion of the PTK to compute the IEEE 802.1X EAPOL MIC. The MLME-MICHAELMICFAILURE.indication primitive is used by the IEEE 802.11 MAC to attempt to indicate a MIC failure to the local IEEE 802.1X Supplicant or Authenticator. MLME-EAPOL.request primitive is used by the Supplicant to send the EAPOL-Key frame containing the Michael MIC Failure report. MLME-EAPOL.confirm primitive indicates to the Supplicant when the EAPOL-Key frame has been transmitted. The first MIC failure shall be logged, and a timer initiated to enable enforcement of the countermeasures. If the MIC failure event is detected by the Supplicant, it shall also report the event to the AP by sending a Michael MIC Failure Report frame. If a subsequent MIC failure occurs within 60 s of the most recent previous failure, then a STA whose IEEE 802.1X entity has acted as a Supplicant shall deauthenticate (as defined in 11.3.4.4) itself or deauthenticate all of the STAs with a security association if its IEEE 802.1X entity acted as an Authenticator. In an IBSS STA, both Supplicant and Authenticator actions shall be taken. Furthermore, the device shall not receive or transmit any TKIP-encrypted Data frames, and shall not receive or transmit any unencrypted Data frames other than IEEE 802.1X messages, to or from any peer for a period of at least 60 s after it detects the second failure. If the device is an AP, it shall disallow new associations using TKIP during this 60 s period; at the end of the 60 s period, the AP shall resume normal operations and allow STAs to (re)associate. If the device is an IBSS STA, it shall disallow any new security associations using TKIP during this 60 s period. If the device is a Supplicant, it shall first send a Michael MIC Failure Report frame prior to revoking its PTKSA and deauthenticating itself. The aMICFailTime attribute shall contain the sysUpTime value at the time the MIC failure was logged. 1960 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 12.5.2.4.2 TKIP countermeasures for an Authenticator The countermeasures used by an Authenticator are depicted in Figure 12-12 and described as follows: Wait for Michael MIC failure Wait for MIC failure Timer Timer No < Timer Timer==00 60ssec Logevent 60 Logevent Yes Disassociate all STAs Deauthenticate if notifan all STAs IBSS not an IBSS Revoke RevokeallallPTKs PTKs and GTK and GTK Generate GeneratenewnewGTKGTK Wait 60 Sec Wait 60 s Plumb new new Configure GTK GTK Enable associations Enable associations if not anan if not IBSS IBSS Figure 12-12â€”Authenticator MIC countermeasures a) In an Authenticatorâ€™s STA that receives a frame with a MIC error, 1) Discard the frame. 2) Increment the MIC failure counter, dot11RSNAStatsTKIPLocalMICFailures. 3) Generate an MLME-MICHAELMICFAILURE.indication primitive. b) In an Authenticator that receives an MLME-MICHAELMICFAILURE.indication primitive or a Michael MIC Failure Report frame, 1) If it is a Michael MIC Failure Report frame, then increment dot11RSNAStatsTKIP- RemoteMICFailures. 2) If this is the first MIC failure within the past 60 s, initialize the countermeasures timer. 3) If less than 60 s have passed since the most recent previous MIC failure, the Authenticator shall deauthenticate and delete all PTKSAs for all STAs using TKIP. If the current GTKSA uses TKIP, that GTKSA shall be discarded, and a new GTKSA constructed, but not used for 60 s. The Authenticator shall refuse the construction of new PTKSAs using TKIP as one or more of the ciphers for 60 s. At the end of this period, the MIC failure counter and timer shall be reset, and creation of PTKSAs accepted as usual. 4) If the Authenticator is using IEEE 802.1X authentication, the Authenticator shall transition the state of the IEEE 802.1X Authenticator state machine to the INITIALIZE state. This restarts the IEEE 802.1X state machine. If the Authenticator is instead using PSKs, this step is omitted. Note that a Supplicantâ€™s STA may deauthenticate with a reason code of MIC_FAILURE if it is an ESS STA. The Authenticator shall not log the deauthenticate as a MIC failure event to prevent denial-of-service attacks through deauthentications. The Supplicantâ€™s STA reports the MIC failure event through the Michael MIC Failure Report frame so that the AP can log the event. 1961 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The requirement to deauthenticate all STAs using TKIP includes those using other pairwise ciphers if they are using TKIP as the group cipher. 12.5.2.4.3 TKIP countermeasures for a Supplicant The countermeasures used by a Supplicant are depicted in Figure 12-13 and described as follows: Wait for MIC failure Send Michael MIC Failure Report frame Timer No < Timer = 0 60 s Logevent Yes Stop receiving Class 3 frames if not an IBSS Stop receiving Class 1 frames if in an IBSS Wait for MLME-EAPOL.confirm Deauthenticate the AP if not in IBSS Revoke PTK and GTK Wait 60 s before associating to same AP or roam to a new AP if not IBSS, or sending data in an IBSS Figure 12-13â€”Supplicant MIC countermeasures a) In a Supplicantâ€™s STA that receives a frame with a MIC error, 1) Increment the MIC failure counter, dot11RSNAStatsTKIPLocalMICFailures. 2) Discard the offending frame. 3) Generate an MLME-MICHAELMICFAILURE.indication primitive. b) In a Supplicant that receives an MLME-MICHAELMICFAILURE.indication primitive from its STA, 1) Send a Michael MIC Failure Report frame to the AP. 2) If this is the first MIC failure within the past 60 s, initialize the countermeasures timer. 3) If less than 60 s have passed since the most recent previous MIC failure, delete the PTKSA and GTKSA. Deauthenticate from the AP and wait for 60 s before (re)establishing a TKIP association with the same AP. A TKIP association is any IEEE 802.11 association that uses TKIP for its pairwise or group cipher suite. c) If a STA receives a deauthenticate frame with the reason code MIC_FAILURE it is unable to verify that the frame has not been forged, since the frame does not contain a MIC. The STA may attempt association with this, or another, AP. If the frame was genuine, then it is probable that attempts to 1962 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications associate with the same AP requesting the use of TKIP will fail because the AP is conducting countermeasures. 12.5.2.5 TKIP mixing function 12.5.2.5.1 General Annex J defines a C-language reference implementation of the TKIP mixing function. It also provides test vectors for the mixing function. The mixing function has two phases. Phase 1 mixes the appropriate temporal key (pairwise or group) with the TA and TSC. A STA may cache the output of this phase to reuse with subsequent MPDUs associated with the same temporal key and TA. Phase 2 mixes the output of Phase 1 with the TSC and temporal key (TK) to produce the WEP seed, also called the per-frame key. The WEP seed may be precomputed before it is used. The two-phase process may be summarized as follows: TTAK := Phase1 (TK, TA, TSC) WEP seed := Phase2 (TTAK, TK, TSC) 12.5.2.5.2 S-Box Both Phase 1 and Phase 2 rely on an S-box, defined in this subclause. The S-box substitutes one 16-bit value with another 16-bit value. This function may be implemented as a table look up. NOTEâ€”The S-box is a nonlinear substitution. The table look-up is be organized as either a single table with 65 536 entries and a 16-bit index (128K octets of table) or two tables with 256 entries and an 8-bit index (1024 octets for both tables). When the two smaller tables are used, the high-order octet is used to obtain a 16-bit value from one table, the low-order octet is used to obtain a 16-bit value from the other table, and the S-box output is the XOR of the two 16-bit values. The second S-box table is an octet-swapped replica of the first. #define _S_(v16) (Sbox[0][Lo8(v16)] ^ Sbox[1][Hi8(v16)]) /* 2-byte by 2-byte subset of the full AES S-box table */ const u16b Sbox[2][256]= /* Sbox for hash (can be in ROM) */ { { 0xC6A5,0xF884,0xEE99,0xF68D,0xFF0D,0xD6BD,0xDEB1,0x9154, 0x6050,0x0203,0xCEA9,0x567D,0xE719,0xB562,0x4DE6,0xEC9A, 0x8F45,0x1F9D,0x8940,0xFA87,0xEF15,0xB2EB,0x8EC9,0xFB0B, 0x41EC,0xB367,0x5FFD,0x45EA,0x23BF,0x53F7,0xE496,0x9B5B, 0x75C2,0xE11C,0x3DAE,0x4C6A,0x6C5A,0x7E41,0xF502,0x834F, 0x685C,0x51F4,0xD134,0xF908,0xE293,0xAB73,0x6253,0x2A3F, 0x080C,0x9552,0x4665,0x9D5E,0x3028,0x37A1,0x0A0F,0x2FB5, 0x0E09,0x2436,0x1B9B,0xDF3D,0xCD26,0x4E69,0x7FCD,0xEA9F, 0x121B,0x1D9E,0x5874,0x342E,0x362D,0xDCB2,0xB4EE,0x5BFB, 0xA4F6,0x764D,0xB761,0x7DCE,0x527B,0xDD3E,0x5E71,0x1397, 0xA6F5,0xB968,0x0000,0xC12C,0x4060,0xE31F,0x79C8,0xB6ED, 0xD4BE,0x8D46,0x67D9,0x724B,0x94DE,0x98D4,0xB0E8,0x854A, 0xBB6B,0xC52A,0x4FE5,0xED16,0x86C5,0x9AD7,0x6655,0x1194, 0x8ACF,0xE910,0x0406,0xFE81,0xA0F0,0x7844,0x25BA,0x4BE3, 0xA2F3,0x5DFE,0x80C0,0x058A,0x3FAD,0x21BC,0x7048,0xF104, 0x63DF,0x77C1,0xAF75,0x4263,0x2030,0xE51A,0xFD0E,0xBF6D, 0x814C,0x1814,0x2635,0xC32F,0xBEE1,0x35A2,0x88CC,0x2E39, 0x9357,0x55F2,0xFC82,0x7A47,0xC8AC,0xBAE7,0x322B,0xE695, 0xC0A0,0x1998,0x9ED1,0xA37F,0x4466,0x547E,0x3BAB,0x0B83, 0x8CCA,0xC729,0x6BD3,0x283C,0xA779,0xBCE2,0x161D,0xAD76, 0xDB3B,0x6456,0x744E,0x141E,0x92DB,0x0C0A,0x486C,0xB8E4, 0x9F5D,0xBD6E,0x43EF,0xC4A6,0x39A8,0x31A4,0xD337,0xF28B, 0xD532,0x8B43,0x6E59,0xDAB7,0x018C,0xB164,0x9CD2,0x49E0, 1963 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 0xD8B4,0xACFA,0xF307,0xCF25,0xCAAF,0xF48E,0x47E9,0x1018, 0x6FD5,0xF088,0x4A6F,0x5C72,0x3824,0x57F1,0x73C7,0x9751, 0xCB23,0xA17C,0xE89C,0x3E21,0x96DD,0x61DC,0x0D86,0x0F85, 0xE090,0x7C42,0x71C4,0xCCAA,0x90D8,0x0605,0xF701,0x1C12, 0xC2A3,0x6A5F,0xAEF9,0x69D0,0x1791,0x9958,0x3A27,0x27B9, 0xD938,0xEB13,0x2BB3,0x2233,0xD2BB,0xA970,0x0789,0x33A7, 0x2DB6,0x3C22,0x1592,0xC920,0x8749,0xAAFF,0x5078,0xA57A, 0x038F,0x59F8,0x0980,0x1A17,0x65DA,0xD731,0x84C6,0xD0B8, 0x82C3,0x29B0,0x5A77,0x1E11,0x7BCB,0xA8FC,0x6DD6,0x2C3A, }, { /* second half of table is byte-reversed version of first! */ 0xA5C6,0x84F8,0x99EE,0x8DF6,0x0DFF,0xBDD6,0xB1DE,0x5491, 0x5060,0x0302,0xA9CE,0x7D56,0x19E7,0x62B5,0xE64D,0x9AEC, 0x458F,0x9D1F,0x4089,0x87FA,0x15EF,0xEBB2,0xC98E,0x0BFB, 0xEC41,0x67B3,0xFD5F,0xEA45,0xBF23,0xF753,0x96E4,0x5B9B, 0xC275,0x1CE1,0xAE3D,0x6A4C,0x5A6C,0x417E,0x02F5,0x4F83, 0x5C68,0xF451,0x34D1,0x08F9,0x93E2,0x73AB,0x5362,0x3F2A, 0x0C08,0x5295,0x6546,0x5E9D,0x2830,0xA137,0x0F0A,0xB52F, 0x090E,0x3624,0x9B1B,0x3DDF,0x26CD,0x694E,0xCD7F,0x9FEA, 0x1B12,0x9E1D,0x7458,0x2E34,0x2D36,0xB2DC,0xEEB4,0xFB5B, 0xF6A4,0x4D76,0x61B7,0xCE7D,0x7B52,0x3EDD,0x715E,0x9713, 0xF5A6,0x68B9,0x0000,0x2CC1,0x6040,0x1FE3,0xC879,0xEDB6, 0xBED4,0x468D,0xD967,0x4B72,0xDE94,0xD498,0xE8B0,0x4A85, 0x6BBB,0x2AC5,0xE54F,0x16ED,0xC586,0xD79A,0x5566,0x9411, 0xCF8A,0x10E9,0x0604,0x81FE,0xF0A0,0x4478,0xBA25,0xE34B, 0xF3A2,0xFE5D,0xC080,0x8A05,0xAD3F,0xBC21,0x4870,0x04F1, 0xDF63,0xC177,0x75AF,0x6342,0x3020,0x1AE5,0x0EFD,0x6DBF, 0x4C81,0x1418,0x3526,0x2FC3,0xE1BE,0xA235,0xCC88,0x392E, 0x5793,0xF255,0x82FC,0x477A,0xACC8,0xE7BA,0x2B32,0x95E6, 0xA0C0,0x9819,0xD19E,0x7FA3,0x6644,0x7E54,0xAB3B,0x830B, 0xCA8C,0x29C7,0xD36B,0x3C28,0x79A7,0xE2BC,0x1D16,0x76AD, 0x3BDB,0x5664,0x4E74,0x1E14,0xDB92,0x0A0C,0x6C48,0xE4B8, 0x5D9F,0x6EBD,0xEF43,0xA6C4,0xA839,0xA431,0x37D3,0x8BF2, 0x32D5,0x438B,0x596E,0xB7DA,0x8C01,0x64B1,0xD29C,0xE049, 0xB4D8,0xFAAC,0x07F3,0x25CF,0xAFCA,0x8EF4,0xE947,0x1810, 0xD56F,0x88F0,0x6F4A,0x725C,0x2438,0xF157,0xC773,0x5197, 0x23CB,0x7CA1,0x9CE8,0x213E,0xDD96,0xDC61,0x860D,0x850F, 0x90E0,0x427C,0xC471,0xAACC,0xD890,0x0506,0x01F7,0x121C, 0xA3C2,0x5F6A,0xF9AE,0xD069,0x9117,0x5899,0x273A,0xB927, 0x38D9,0x13EB,0xB32B,0x3322,0xBBD2,0x70A9,0x8907,0xA733, 0xB62D,0x223C,0x9215,0x20C9,0x4987,0xFFAA,0x7850,0x7AA5, 0x8F03,0xF859,0x8009,0x171A,0xDA65,0x31D7,0xC684,0xB8D0, 0xC382,0xB029,0x775A,0x111E,0xCB7B,0xFCA8,0xD66D,0x3A2C, } }; 12.5.2.5.3 Phase 1 Definition The inputs to Phase 1 of the temporal key mixing function shall be a temporal key (TK), the TA, and the TSC. The temporal key shall be 128 bits in length. Only the 32 MSBs of the TSC and all of the temporal key are used in Phase 1. The output, TTAK, shall be 80 bits in length and is represented by an array of 16-bit values: TTAK0 TTAK1 TTAK2 TTAK3 TTAK4. The description of the Phase 1 algorithm treats all of the following values as arrays of 8-bit values: TA0..TA5, TK0..TK15. The TA octet order is represented according to the conventions from 9.2.2, and the first 3 octets represent the OUI. 1964 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The XOR operation, the bitwise-and (&) operation, and the addition (+) operation are used in the Phase 1 specification. A loop counter, i, and an array index temporary variable, j, are also employed. One function, Mk16, is used in the definition of Phase 1. The function Mk16 constructs a 16-bit value from two 8-bit inputs as Mk16(X,Y) = (256 X)+Y. Two steps make up the Phase 1 algorithm. The first step initializes TTAK from TSC and TA. The second step uses an S-box to iteratively mix the keying material into the 80-bit TTAK. The second step sets the PHASE1_LOOP_COUNT to 8. See Figure 12-14. Input: transmit address TA0â€¦TA5, Temporal Key TK0..TK15, and TSC0..TSC5 Output: intermediate key TTAK0..TTAK4 PHASE1-KEY-MIXING(TA0â€¦TA5, TK0..TK15, TSC0..TSC5) PHASE1_STEP1: TTAK0 MK16(TSC3, TSC2) TTAK1 MK16(TSC5, TSC4) TTAK2 Mk16(TA1,TA0) TTAK3 Mk16(TA3,TA2) TTAK4 Mk16(TA5,TA4) PHASE1_STEP2: for i = 0 to PHASE1_LOOP_COUNT-1 j 2 (i & 1) TTAK0 TTAK0 + S[TTAK4 Mk16(TK1+j,TK0+j)] TTAK1 TTAK1 + S[TTAK0 Mk16(TK5+j,TK4+j)] TTAK2 TTAK2 + S[TTAK1 Mk16(TK9+j,TK8+j)] TTAK3 TTAK3 + S[TTAK2 Mk16(TK13+j,TK12+j)] TTAK4 TTAK4 + S[TTAK3 Mk16(TK1+j,TK0+j)] + i Figure 12-14â€”Phase 1 key mixing NOTE 1â€”The TA is mixed into the temporal key in Phase 1 of the hash function. Implementations might achieve a significant performance improvement by caching the output of Phase 1. The Phase 1 output is the same for 216 = 65 536 consecutive frames from the same temporal key and TA. Consider the simple case where a STA communicates only with an AP. The STA performs Phase 1 using its own address, and the TTAK is used to protect traffic sent to the AP. The STA performs Phase 1 using the AP address, and it is used to unwrap traffic received from the AP. NOTE 2â€”The cached TTAK from Phase 1 needs to be updated when the lower 16 bits of the TSC wrap and the upper 32 bits need to be updated. 12.5.2.5.4 Phase 2 definition The inputs to Phase 2 of the temporal key mixing function shall be the output of Phase 1 (TTAK) together with the temporal key and the TSC. The TTAK is 80 bits in length. Only the 16 LSBs of the TSC are used in Phase 2. The temporal key is 128 bits. The output is the WEP seed, which is a per-frame key, and is 128 bits in length. The constructed WEP seed has an internal structure compliant with the WEP specification. In other words, the first 24 bits of the WEP seed shall be transmitted in plaintext as the WEP IV. As such, these 24 bits are used to convey lower 16 bits of the TSC from the sender (encryptor) to the receiver (decryptor). The rest of the TSC shall be conveyed in the Extended IV field. The temporal key and TTAK values are represented as in Phase 1. The WEP seed is treated as an array of 8-bit values: WEPSeed0â€¦WEPSeed15. The TSC shall be treated as an array of 8-bit values: TSC0 TSC1 TSC2 TSC3 TSC4 TSC5. The pseudocode specifying the Phase 2 mixing function employs one variable: PPK, which is 96 bits long. The PPK is represented as an array of 16-bit values: PPK0..PPK5. The pseudocode also employs a loop counter, i. As detailed in this subclause, the mapping from the 16-bit PPK values to the 8-bit WEPseed values is explicitly little endian to match the endian architecture of the most common processors used for this application. 1965 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The XOR ( ) operation, the addition (+) operation, the AND (&) operation, the OR (|) operation, and the right bit shift (>>) operation are used in the specification of Phase 2. See Figure 12-15. Input: intermediate key TTAK0â€¦TTAK4, TK, and TKIP sequence counter TSC Output: WEP Seed WEPSeed0â€¦WEPSeed15 PHASE2-KEY-MIXING(TTAK0â€¦TTAK4, TK0â€¦TK15, TSC0â€¦TSC5) PHASE2_STEP1: PPK0 TTAK0 PPK1 TTAK1 PPK2 TTAK2 PPK3 TTAK3 PPK4 TTAK4 PPK5 TTAK4 + Mk16(TSC1, TSC0) PHASE2_STEP2: PPK0 PPK0 + S[PPK5 Mk16(TK1,TK0)] PPK1 PPK1 + S[PPK0 Mk16(TK3,TK2)] PPK2 PPK2 + S[PPK1 Mk16(TK5,TK4)] PPK3 PPK3 + S[PPK2 Mk16(TK7,TK6)] PPK4 PPK4 + S[PPK3 Mk16(TK9,TK8)] PPK5 PPK5 + S[PPK4 Mk16(TK11,TK10)] PPK0 PPK0 + RotR1(PPK5 Mk16(TK13,TK12)) PPK1 PPK1 + RotR1(PPK0 Mk16(TK15,TK14)) PPK2 PPK2 + RotR1(PPK1) PPK3 PPK3 + RotR1(PPK2) PPK4 PPK4 + RotR1(PPK3) PPK5 PPK5 + RotR1(PPK4) PHASE2_STEP3: WEPSeed0 TSC1 WEPSeed1 (TSC1 | 0x20) & 0x7F WEPSeed2 TSC0 WEPSeed3 Lo8((PPK5 Mk16(TK1,TK0)) >> 1) for i = 0 to 5 WEPSeed4+(2 i) Lo8(PPKi) WEPSeed5+(2 i) Hi8(PPKi) end return WEPSeed0â€¦WEPSeed15 Figure 12-15â€”Phase 2 key mixing The algorithm specification relies on four functions: â€” The first function, Lo8, references the 8 LSBs of the 16-bit input value. â€” The second function, Hi8, references the 8 MSBs of the 16-bit value. â€” The third function, RotR1, rotates its 16-bit argument 1 bit to the right. â€” The fourth function, Mk16, is already used in Phase 1, defined by Mk16(X,Y) = (256 X)+Y, and constructs a 16-bit output from two 8-bit inputs. NOTEâ€”The rotate and addition operations in STEP2 make Phase 2 particularly sensitive to the endian architecture of the processor, although the performance degradation due to running this algorithm on a big endian processor is expected to be minor. Phase 2 comprises three steps: â€” STEP1 makes a copy of TTAK and brings in the TSC. â€” STEP2 is a 96-bit bijective mixing, employing an S-box. â€” STEP3 brings in the last of the temporal key TK bits and assigns the 24-bit WEP IV value. The WEP IV format carries 3 octets. STEP3 of Phase 2 determines the value of each of these three octets. The construction was selected to preclude the use of known ARC4 weak keys. The recipient can reconstruct 1966 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications the 16 LSBs of the TSC used by the originator by concatenating the third and first octets, ignoring the second octet. The remaining 32 bits of the TSC are obtained from the Extended IV field. 12.5.2.6 TKIP replay protection procedures TKIP implementations shall use the TSC field to defend against replay attacks by implementing the following rules: a) Each MPDU shall have a unique TKIP TSC value. b) Each transmitter shall maintain a single TSC (48-bit counter) for each PTKSA, GTKSA, and STKSA. c) The TSC shall be implemented as a 48-bit strictly increasing counter, initialized to 1 when the corresponding TKIP temporal key is initialized or refreshed. d) The WEP IV format carries the 16 LSBs of the 48-bit TSC, as defined by the TKIP mixing function (Phase 2, STEP3). The remainder of the TSC is carried in the Extended IV field. e) A receiver shall maintain a separate set of TKIP TSC replay counters for each PTKSA, GTKSA, and STKSA. f) TKIP replay detection takes place after the MIC verification and any reordering required by ack processing. Thus, a receiver shall delay advancing a TKIP TSC replay counter until an MSDU passes the MIC check, to prevent attackers from injecting MPDUs with valid ICVs and TSCs, but invalid MICs. NOTEâ€”This works because if an attacker modifies the TSC, then the encryption key is modified and hence both the ICV and MIC decrypt incorrectly, causing the received MPDU to be dropped. g) For each PTKSA, GTKSA, and STKSA, the receiver shall maintain a separate replay counter for each frame priority and shall use the TSC in a received frame to detect replayed frames, subject to the limitations on the number of supported replay counters indicated in the RSN Capabilities field, as described in 9.4.2.25. A replayed frame occurs when the TSC in a received frame is less than or equal to the current replay counter value for the frameâ€™s priority. A transmitter shall not reorder TKIP protected frames with different priorities without ensuring that the receiver supports the required number of replay counters. The transmitter shall not reorder TKIP protected frames within a replay counter, but may reorder TKIP protected frames across replay counters. One possible reason for reordering frames is the IEEE 802.11 MSDU priority. h) A receiver shall discard any MPDU that is received out of order and shall increment dot11RSNAStatsTKIPReplays for this key. i) For MSDUs sent using the block ack feature, reordering of received MSDUs according to the block ack receiver operation (described in 10.24.4) is performed prior to replay detection. 12.5.3 CTR with CBC-MAC protocol (CCMP) 12.5.3.1 General Subclause 12.5.3 specifies all variants of CCMP, which provides data confidentiality, authentication, integrity, and replay protection. A non-DMG RSNA STA shall support CCMP-128. CCMP is based on the CCM of the AES encryption algorithm. CCM combines CTR for data confidentiality and CBC-MAC for authentication and integrity. CCM protects the integrity of both the MPDU Data field and selected portions of the IEEE 802.11 MPDU header. The AES algorithm is defined in FIPS PUB 197. AES processing used within CCMP uses AES with either a 128-bit key (CCMP-128) or a 256-bit key (CCMP-256). 1967 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications CCM is defined in IETF RFC 3610. CCM is a generic mode that can be used with any block-oriented encryption algorithm. CCM has two parameters (M and L). CCMP-128 uses the following values for the CCM parameters: â€” M = 8; indicating that the MIC is 8 octets. â€” L = 2; indicating that the Length field is 2 octets, which is sufficient to hold the length of the largest possible IEEE 802.11 MPDU, expressed in octets. CCMP-256 uses the following values for the CCM parameters: â€” M = 16; indicating that the MIC is 16 octets. â€” L = 2; indicating that the Length field is 2 octets, which is sufficient to hold the length of the largest possible IEEE 802.11 MPDU, expressed in octets. CCM requires a fresh temporal key for every session. CCM also requires a unique nonce value for each frame protected by a given temporal key, and CCMP uses a 48-bit packet number (PN) for this purpose. Reuse of a PN with the same temporal key voids all security guarantees. Annex J provides a test vector for CCM. When CCMP is selected as the RSN pairwise cipher and management frame protection is negotiated, individually addressed robust Management frames and the group addressed Management frames that receive â€œGroup Addressed Privacyâ€ as indicated in Table 9-47 shall be protected with CCMP. 12.5.3.2 CCMP MPDU format Figure 12-16 depicts the MPDU when using CCMP. Encrypted CCMP Header Data (PDU) MIC FCS MAC Header 8 octets â‰¥ 1 octet variable 4 octets Ext Key PN0 PN1 Rsvd Rsvd PN2 PN3 PN4 PN5 IV ID B0 B4 B5 B6 B7 Key ID octet Figure 12-16â€”Expanded CCMP MPDU CCMP-128 processing expands the original MPDU size by 16 octets, 8 octets for the CCMP Header field and 8 octets for the MIC field. CCMP-256 processing expands the original MPDU size by 24 octets, 8 octets for the CCMP Header field, and 16 octets for the MIC field. The CCMP Header field is constructed from the PN, ExtIV, and Key ID subfields. PN is a 48-bit PN represented as an array of 6 octets. PN5 is the most significant octet of the PN, and PN0 is the least significant. Note that CCMP does not use the WEP ICV. The ExtIV subfield (bit 5) of the Key ID octet signals that the CCMP Header field extends the MPDU header by a total of 8 octets, compared to the 4 octets added to the MPDU header when WEP is used. The ExtIV bit (bit 5) is always set to 1 for CCMP. Bits 6â€“7 of the Key ID octet are for the Key ID subfield. 1968 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 12.5.3.3 CCMP cryptographic encapsulation 12.5.3.3.1 General The CCMP cryptographic encapsulation process is depicted in Figure 12-17. Key ID Figure 12-17â€”CCMP encapsulation block diagram CCMP encrypts the Frame Body field of a plaintext MPDU and encapsulates the resulting cipher text using the following steps: a) Increment the PN, to obtain a fresh PN for each MPDU, so that the PN never repeats for the same temporal key. Note that retransmitted MPDUs are not modified on retransmission. b) Use the fields in the MPDU header to construct the additional authentication data (AAD) for CCM. The CCM algorithm provides integrity protection for the fields included in the AAD. MPDU header fields that may change when retransmitted are muted by being masked to 0 when calculating the AAD. c) Construct the CCM Nonce block from the PN, A2, and the priority value of the MPDU where A2 is MPDU Address 2. If the Type field of the Frame Control field is 10 (Data frame) and there is a QoS Control field present in the MPDU header, the priority value of the MPDU is equal to the value of the QC field TID (bits 0 to 3 of the QC field). If the Type field of the Frame Control field is 00 (Management frame), and the frame is a QMF, the priority value of the MPDU is equal to the value in the ACI subfield of the Sequence Number field. Otherwise, the priority value of the MPDU is equal to the fixed value 0. d) Place the new PN and the key identifier into the 8-octet CCMP header. e) Use the temporal key, AAD, nonce, and MPDU data to form the cipher text and MIC. This step is known as CCM originator processing. f) Form the encrypted MPDU by combining the original MPDU header, the CCMP header, the encrypted data and MIC, as described in 12.5.3.2. The CCM reference describes the processing of the key, nonce, AAD, and data to produce the encrypted output. See 12.5.3.3.2 to 12.5.3.3.6 for details of the creation of the AAD and nonce from the MPDU and the associated MPDU-specific processing. 12.5.3.3.2 PN processing The PN is incremented by a positive number for each MPDU. The PN shall be incremented in steps of 1 for constituent MPDUs of fragmented MSDUs and MMPDUs. The PN shall never repeat for a series of encrypted MPDUs using the same temporal key. 1969 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NOTEâ€”When a group addressed MSDU is retransmitted using GCR, it is concealed from non-GCR capable STAs using the procedures described in 11.24.16.3.5. The MPDU containing this concealed A-MSDU has a different PN from the MPDU that contained the original transmission of the group addressed MSDU. 12.5.3.3.3 Construct AAD The format of the AAD is shown in Figure 12-18. FC A1 A2 A3 SC A4 QC Octets: 2 6 6 6 2 6 2 Figure 12-18â€”AAD construction The length of the AAD varies depending on the presence or absence of the QC and A4 fields and is shown in Table 12-1. Table 12-1â€”AAD length AAD length QC field A4 field (octets) Absent Absent 22 Present Absent 24 Absent Present 28 Present Present 30 The AAD is constructed from the MPDU header. The AAD does not include the header Duration field, because the Duration field value might change due to normal IEEE 802.11 operation (e.g., a rate change during retransmission). The AAD includes neither the Duration/ID field nor the HT Control field because the contents of these fields might change during normal operation (e.g., due to a rate change preceding retransmission). The HT Control field might also be inserted or removed during normal operation (e.g., retransmission of an A-MPDU where the original A-MPDU included an MRQ that has already generated a response). For similar reasons, several subfields in the Frame Control field are masked to 0. AAD construction is performed as follows: a) FC â€“ MPDU Frame Control field, with 1) Subtype subfield (bits 4 5 6) in a Data frame masked to 0 2) Retry subfield (bit 11) masked to 0 3) Power Management subfield (bit 12) masked to 0 4) More Data subfield (bit 13) masked to 0 5) Protected Frame subfield (bit 14) always set to 1 6) +HTC/Order subfield (bit 15) as follows: i) Masked to 0 in all Data frames containing a QoS Control field ii) Unmasked otherwise b) A1 â€“ MPDU Address 1 field. c) A2 â€“ MPDU Address 2 field. d) A3 â€“ MPDU Address 3 field. 1970 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications e) SC â€“ MPDU Sequence Control field, with the Sequence Number subfield (bits 4â€“15 of the Sequence Control field) masked to 0. The Fragment Number subfield is not modified. f) A4 â€“ MPDU Address field, if present. g) QC â€“ QoS Control field, if present, a 2-octet field that includes the MSDU priority. The QC TID is used in the construction of the AAD. When in a non-DMG BSS and both the STA and its peer have their SPP A-MSDU Capable fields equal to 1, bit 7 (the A-MSDU Present field) is used in the construction of the AAD. The remaining QC fields are masked to 0 for the AAD calculation (bits 4 to 6, bits 8 to 15, and bit 7 when either the STA or its peer has the SPP A-MSDU Capable field equal to 0). When in a DMG BSS, the A-MSDU Present bit 7 and A-MSDU Type bit 8 are used in the construction of the AAD, and the remaining QC fields are masked to 0 for the AAD calculation (bits 4 to 6, bits 9 to 15). 12.5.3.3.4 Construct CCM nonce The Nonce field occupies 13 octets, and its structure is shown in Figure 12-19. The structure of the Nonce Flags subfield of the Nonce field is shown in Figure 12-20. Nonce Flags A2 PN Octets: 1 6 6 Figure 12-19â€”Nonce construction B0 B3 B4 B5 B7 Priority Management Zeros Bits: 4 1 3 Figure 12-20â€”Nonce Flags subfield The Nonce field has an internal structure of Nonce Flags || A2 || PN, where â€” The Priority subfield of the Nonce Flags field shall be set to the priority value of the MPDU. â€” When management frame protection is negotiated, the Management field of the Nonce Flags field shall be set to 1 if the Type field of the Frame Control field is 00 (Management frame); otherwise it shall be set to 0. â€” Bits 5 to 7 of the Nonce Flags field shall be set to 0. â€” MPDU address A2 field occupies octets 1â€“6. This shall be encoded with the octets ordered with A2 octet 0 at octet index 1 and A2 octet 5 at octet index 6. â€” The PN field occupies octets 7â€“12. The octets of PN shall be ordered so that PN0 is at octet index 12 and PN5 is at octet index 7. 12.5.3.3.5 Construct CCMP header The format of the 8-octet CCMP header is given in 12.5.3.2. The header encodes the PN, Key ID, and ExtIV field values used to encrypt the MPDU. 12.5.3.3.6 CCM originator processing CCM is a generic authenticate-and-encrypt block cipher mode, and in this standard, CCM is used with the AES block cipher. 1971 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications There are four inputs to CCM originator processing: a) Key: the temporal key (16 octets). b) Nonce: the nonce (13 octets) constructed as described in 12.5.3.3.4. c) Frame body: the plaintext frame body of the MPDU. d) AAD: the AAD (22â€“30 octets) constructed from the MPDU header as described in 12.5.3.3.3. The CCM originator processing provides authentication and integrity of the frame body and the AAD as well as data confidentiality of the frame body. The output from the CCM originator processing consists of the encrypted data and an encrypted MIC (see Figure 12-16). The PN values sequentially number each MPDU. Each transmitter shall maintain a single PN (48-bit counter) for each PTKSA, GTKSA, and STKSA. The PN shall be implemented as a 48-bit strictly increasing integer, initialized to 1 when the corresponding temporal key is initialized or refreshed. A transmitter shall not use an IEEE 802.11 MSDU or A-MSDU priority if this would cause the total number of priorities used during the lifetime of the SA to exceed the number of replay counters supported by the receiver (for a pairwise SA) or all the receivers (for a group SA) for that SA. The transmitter shall not reorder CCMP protected frames that are transmitted to the same RA within a replay counter, but may reorder frames across replay counters. One possible reason for reordering frames is the IEEE 802.11 MSDU or A-MSDU priority. The transmitter shall preserve the order of protected robust Management frames that are transmitted to the same DA without the QMF service. When the QMF service is used, the transmitter shall not reorder robust IQMFs within an AC when the frames are transmitted to the same RA. A CCMP protected individually addressed robust Management frame shall be protected using the same TK as a Data frame. 12.5.3.4 CCMP decapsulation 12.5.3.4.1 General Figure 12-21 depicts the CCMP decapsulation process. Figure 12-21â€”CCMP decapsulation block diagram 1972 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications CCMP decrypts the Frame Body field of a cipher text MPDU and decapsulates a plaintext MPDU using the following steps: a) The encrypted MPDU is parsed to construct the AAD and nonce values. b) The AAD is formed from the MPDU header of the encrypted MPDU. c) The Nonce value is constructed from the A2, PN, and Nonce Flags fields. d) The MIC is extracted for use in the CCM integrity checking. e) The CCM recipient processing uses the temporal key, AAD, nonce, MIC, and MPDU cipher text data to recover the MPDU plaintext data as well as to check the integrity of the AAD and MPDU plaintext data. f) The received MPDU header and the MPDU plaintext data from the CCM recipient processing are concatenated to form a plaintext MPDU. g) The decryption processing prevents replay of MPDUs by validating that the PN in the MPDU is greater than the replay counter maintained for the session. See 12.5.3.4.2 to 12.5.3.4.4 for details of this processing. When the received frame is a CCMP protected individually addressed robust Management frame, contents of the MMPDU body after protection is removed shall be delivered to the SME via the MLME primitive designated for that MMPDU rather than through the MA-UNITDATA.indication primitive. 12.5.3.4.2 CCM recipient processing CCM recipient processing uses the same parameters as CCM originator processing. A CCMP protected individually addressed robust Management frame shall use the same TK as a Data frame. There are four inputs to CCM recipient processing: â€” Key: the temporal key (16 octets). â€” Nonce: the nonce (13 octets) constructed as described in 12.5.3.3.4. â€” Encrypted frame body: the encrypted frame body from the received MPDU. The encrypted frame body includes the MIC. â€” AAD: the AAD (22â€“30 octets) that is the canonical MPDU header as described in 12.5.3.3.3. The CCM recipient processing checks the authentication and integrity of the frame body and the AAD as well as decrypting the frame body. The plaintext is returned only if the MIC check is successful. There is one output from error-free CCM recipient processing: â€” Frame body: the plaintext frame body, which is 8 octets (CCMP-128) or 16 octets (CCMP-256) smaller than the encrypted frame body. 12.5.3.4.3 Decrypted CCMP MPDU The decapsulation process succeeds when the calculated MIC matches the MIC value obtained from decrypting the received encrypted MPDU. The original MPDU header is concatenated with the plaintext data resulting from the successful CCM recipient processing to create the plaintext MPDU. 12.5.3.4.4 PN and replay detection To effect replay detection, the receiver extracts the PN from the CCMP header. See 12.5.3.2 for a description of how the PN is encoded in the CCMP header. The following processing rules are used to detect replay: 1973 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications a) The receiver shall maintain a separate set of replay counters for each PTKSA, GTKSA, and STKSA. The receiver initializes these replay counters to 0 when it resets the temporal key for a peer. The replay counter is set to the PN value of accepted CCMP MPDUs. b) For each PTKSA, GTKSA, and STKSA, the recipient shall maintain a separate replay counter for each TID, subject to the limitation of the number of supported replay counters indicated in the RSN Capabilities field (see 9.4.2.25), and shall use the PN from a received frame to detect replayed frames. A replayed frame occurs when the PN from a received frame is less than or equal to the current replay counter value for the frameâ€™s MSDU or A-MSDU priority and frame type. c) If dot11RSNAProtectedManagementFramesActivated is true, the recipient shall maintain a single replay counter for received individually addressed robust Management frames that are received with the To DS subfield equal to 0 and shall use the PN from the received frame to detect replays. If dot11QMFActivated is also true, the recipient shall maintain an additional replay counter for each ACI for received individually addressed robust Management frames that are received with the To DS subfield equal to 1. The QMF receiver shall use the ACI encoded in the Sequence Number field of the received frame to select the replay counter to use for the received frame, and shall use the PN from the received frame to detect replays. A replayed frame occurs when the PN from the frame is less than or equal to the current value of the management frame replay counter that corresponds to the ACI of the frame. d) The receiver shall discard any Data frame that is received with its PN less than or equal to the value of the replay counter that is associated with the TA and priority value of the received MPDU. The receiver shall discard MSDUs and MMPDUs whose constituent MPDU PN values are not incrementing in steps of 1. If dot11RSNAProtectedManagementFramesActivated is true, the receiver shall discard any individually addressed robust Management frame that is received with its PN less than or equal to the value of the replay counter associated with the TA of that individually addressed Management frame. e) When discarding a frame, the receiver shall increment by 1 dot11RSNAStatsCCMPReplays for Data frames or dot11RSNAStatsRobustMgmtCCMPReplays for robust Management frames. f) For MSDUs or A-MSDUs sent using the block ack feature, reordering of received MSDUs or A-MSDUs according to the block ack receiver operation (described in 10.24.4) is performed prior to replay detection. 12.5.4 Broadcast/multicast integrity protocol (BIP) 12.5.4.1 BIP overview BIP provides data integrity and replay protection for group addressed robust Management frames after successful establishment of an IGTKSA (see 12.6.1.1.9). BIP-CMAC-128 provides data integrity and replay protection, using AES-128 in CMAC Mode with a 128- bit integrity key and a CMAC TLen value of 128 (16 octets). BIP-CMAC-256 provides data integrity and replay protection, using AES-256 in CMAC Mode with a 256-bit integrity key and a CMAC TLen value of 128 (16 octets). NIST Special Publication 800-38B defines the CMAC algorithm, and NIST SP 800-38D defines the GMAC algorithm. BIP processing uses AES with a 128-bit or 256-bit integrity key and a CMAC TLen value of 128 (16 octets). The CMAC output for BIP-CMAC-256 is not truncated and shall be 128 bits (16 octets). The CMAC output for BIP-CMAC-128 is truncated to 64 bits: MIC = Truncate-64(CMAC Output). BIP-GCMP-128 uses AES with a 128-bit integrity key, and BIP-GCMP-256 uses AES with a 256-bit integrity key. The authentication tag for both BIP-GCMP-128 and BIP-GCMP-256 is not truncated and shall be 128 bits (16 octets). 1974 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications BIP uses the IGTK to compute the MMPDU MIC. The authenticator shall distribute one new IGTK and IGTK PN (IPN) whenever it distributes a new GTK. The IGTK is identified by the MAC address of the transmitting STA plus an IGTK identifier that is encoded in the MME Key ID field. 12.5.4.2 BIP MMPDU format The Management MIC element shall follow all of the other elements in the management frame body but precede the FCS. See 9.4.2.55 for the format of the Management MIC element. Figure 12-22 shows the BIP MMPDU. IEEE 802.11 Header Management Frame Body including MME FCS Figure 12-22â€”BIP Encapsulation 12.5.4.3 BIP AAD construction The BIP Additional Authentication Data (AAD) shall be constructed from the MPDU header. The Duration field in the AAD shall be masked to 0. The AAD construction shall use a copy of the IEEE 802.11 header without the SC field for the MPDU, with the following exceptions: a) FCâ€”MPDU Frame Control field, with: 1) Retry subfield (bit 11) masked to 0 2) Power Management subfield (bit 12) masked to 0 3) More Data subfield (bit 13) masked to 0 b) A1â€”MPDU Address 1 field. c) A2â€”MPDU Address 2 field. d) A3â€”MPDU Address 3 field. Figure 12-23 depicts the format of the AAD. The length of the AAD is 20 octets. FC A1 A2 A3 Octets: 2 6 6 6 Figure 12-23â€”BIP AAD Construction 12.5.4.4 BIP replay protection The MME Sequence Number field represents a sequence number whose length is 6 octets. When management frame protection is negotiated, the receiver shall maintain a 48-bit replay counter for each IGTK. The receiver shall set the receive replay counter to the value of the IPN in the IGTK key data encapsulation (KDE) (see 12.7.2) provided by the Authenticator in either the 4-way handshake, FT 4-way handshake, FT handshake, or group key handshake. The transmitter shall maintain a single IPN for each IGTK. The IPN shall be implemented as a 48-bit strictly increasing integer, initialized to 1 when the corresponding IGTK is initialized. The transmitter may reinitialize the sequence counter when the IGTK is refreshed. See 12.5.4.5 and 12.5.4.6 for per packet BIP processing. NOTEâ€”When the IPN space is exhausted, the choices available to an implementation are to replace the IGTK or to end communications. When dot11QMFActivated is true, the receiver shall maintain an additional replay counter for each ACI for received group addressed robust Management frames that use QMF. The receiver shall use the ACI encoded in the Sequence Number field of received GQMFs protected by BIP to select the replay counter to use for the received frame, and shall use the IPN from the received frame to detect replays. 1975 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If dot11RSNAProtectedManagementFramesActivated is true and dot11MeshSecurityActivated is true, the recipient shall maintain a single replay counter for received group addressed robust Management frames that do not use the QMF service and shall use the PN from the received frame to detect replays. If dot11QMFActivated is also true, the recipient shall maintain an additional replay counter for each ACI for received group addressed robust Management frames that use the QMF service. The QMF receiver shall use the ACI encoded in the Sequence Number field of the received frame to select the replay counter to use for the received frame, and shall use the PN from the received frame to detect replays. A replayed frame occurs when the PN from the frame is less than or equal to the value of the management frame replay counter that corresponds to the ACI of the frame. The transmitter shall preserve the order of protected robust Management frames transmitted to the same DA without the QMF service. When the QMF service is used, the transmitter shall not reorder robust GQMFs within an AC when the frames are transmitted to the same RA. 12.5.4.5 BIP transmission When a STA transmits a protected group addressed robust Management frame, it shall a) Select the IGTK currently active for transmission of frames to the intended group of recipients and construct the MME (see 9.4.2.55) with the MIC field masked to 0 and the Key ID field set to the corresponding IGTK Key ID value. If the frame is not a GQMF, the transmitting STA shall insert a strictly increasing integer into the MME IPN field. If the frame is a GQMF, then the transmitting STA shall maintain a 48-bit counter for use as the IPN, the counter shall be incremented for each GQMF until the two least significant bits of the counter match the ACI of the AC that is used to transmit the frame, and the counter value shall be inserted into the MME IPN field of the frame. For BIP-GMAC-128 and BIP-GMAC-256, the initialization vector passed to GMAC shall be a concatenation of Address 2 from the MAC header of the MPDU and the non-negative integer inserted into the MMP IPN field. b) Compute AAD as specified in 12.5.4.3. c) Compute an integrity value over the concatenation of AAD and the management frame body includ- ing MME, and insert the output into the MME MIC field. For BIP-CMAC-128, the integrity value is 64 bits and is computed using AES-128-CMAC; for BIP-CMAC-256, the integrity value is 128 bits and is computed using AES-256-CMAC; for BIP-GMAC-128, the integrity value is 128 bits and is computed using AES-128-GMAC; and, for BIP-GMAC-256, the integrity value is 128 bits and is computed using AES-256-GMAC. d) Compose the frame as the IEEE 802.11 header, management frame body, including MME, and FCS. The MME shall appear last in the frame body. e) Transmit the frame. 12.5.4.6 BIP reception When a STA with management frame protection negotiated receives a group addressed robust Management frame protected by BIP-CMAC-128, BIP-CMAC-256, BIP-GMAC-128, or BIP-GMAC-256, it shall a) Identify the appropriate IGTK and associated state based on the MME Key ID field. If no such IGTK exists, silently drop the frame and terminate BIP processing for this reception. b) Perform replay protection on the received frame. The receiver shall interpret the MME IPN field as a 48-bit unsigned integer. 1) If the frame is not a GQMF, the receiver shall compare this MME IPN integer value to the value of the receive replay counter for the IGTK identified by the MME Key ID field. If the integer value from the received MME IPN field is less than or equal to the replay counter value for this IGTK, the receiver shall discard the frame and increment the dot11RSNAStatsCMACReplays counter by 1. 1976 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 2) If the frame is a GQMF, the receiver shall compare this MME IPN integer value to the value of the receive replay counter for the IGTK identified by the MME Key ID field and the AC represented by the value of the ACI subfield of the received frame. If the integer value from the received MME IPN field is less than or equal to the replay counter value for this IGTK and AC, the receiver shall discard the frame and increment the dot11RSNAStatsCMACReplays counter by 1. c) Compute AAD for this Management frame, as specified in 12.5.4.3. For BIP-GMAC-128 and BIP- GMAC-256, an initialization vector for GMAC is constructed as the concatenation of Address 2 from the MAC header of the MPDU and the 48-bit unsigned integer from the MME IPN field. d) Extract and save the received MIC value, and compute a verifier over the concatenation of AAD, the management frame body, and MME, with the MIC field masked to 0 in the MME. For BIP-CMAC- 128, the integrity value is 64 bits and is computed using AES-128-CMAC; for BIP-CMAC-256, the integrity value is 128 bits and is computed using AES-256-CMAC; for BIP-GMAC-128, the integ- rity value is 128 bits and is computed using AES-128-GMAC; and, for BIP-GMAC-256, the integ- rity value is 128 bits and is computed using AES-256-GMAC. If the result does not match the received MIC value, then the receiver shall discard the frame, increment the dot11RSNAStatsBIP- MICErrors counter by 1, and terminate BIP processing for this reception. e) If the frame is not a GQMF, update the replay counter for the IGTK identified by the MME Key ID field with the integer value of the MME IPN field. f) If the frame is a GQMF, update the replay counter for the IGTK identified by the MME Key ID field and the AC represented by the value of the ACI subfield of the received frame with the integer value of the MME IPN field. If management frame protection is negotiated, group addressed robust Management frames that are received without BIP protection shall be discarded. 12.5.5 GCM protocol (GCMP) 12.5.5.1 GCMP overview Subclause 12.5.5 specifies the GCMP, which provides data confidentiality, authentication, integrity, and replay protection. A DMG RSNA STA shall support GCMP-128. GCMP is based on the GCM of the AES encryption algorithm. GCM protects the integrity of both the MPDU Data field and selected portions of the MPDU header. The AES algorithm is defined in FIPS PUB 197. All AES processing used within GCMP uses AES with a 128-bit key (GCMP-128) or a 256-bit key (GCMP-256). GCM is defined in NIST Special Publication 800-38D. GCM is a generic mode that can be used with any block-oriented encryption algorithm. GCM requires a fresh temporal key for every session. GCM also requires a unique nonce value for each frame protected by a given temporal key, and GCMP uses a 96-bit nonce that includes a 48-bit packet number (PN) for this purpose. Reuse of a PN with the same temporal key voids all security guarantees. GCMP uses a 128-bit MIC. Annex J provides test vectors for GCM. When GCMP is selected as the RSN pairwise cipher and management frame protection is negotiated, individually addressed robust Management frames and the group addressed Management frames that receive â€œGroup Addressed Privacyâ€ as indicated in Table 9-47 shall be protected with GCMP. 1977 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 12.5.5.2 GCMP MPDU format Figure 12-24 shows the MPDU format when using GCMP. Encrypted GCMP Header Data (PDU) MIC FCS MAC Header 8 octets â‰¥ 1 octets 16 octets 4 octets Ext Key PN0 PN1 Rsvd Rsvd PN2 PN3 PN4 PN5 IV ID b0 b4 b5 b6 b7 Key ID octet Figure 12-24â€”Expanded GCMP MPDU GCMP processing expands the original MPDU size by 24 octets, 8 octets for the GCMP Header field and 16 octets for the MIC field. The GCMP Header field is constructed from the PN and Key ID subfields. The 48- bit PN is represented as an array of 6 octets. PN5 is the most significant octet of the PN, and PN0 is the least significant. The ExtIV subfield (bit 5) of the Key ID octet is always set to 1 for GCMP. Bits 6â€“7 of the Key ID octet are for the Key ID subfield. The remaining bits of the Key ID octet are reserved. 12.5.5.3 GCMP cryptographic encapsulation 12.5.5.3.1 General The GCMP cryptographic encapsulation process is depicted in Figure 12-25. MAC Header Construct AAD Plaintext MPDU Encrypted A2 Encrypted Construct GCM Data, MIC || MPDU Nonce encryption Data TK PN Increment PN Construct Key ID GCMP header Figure 12-25â€”GCMP encapsulation block diagram GCMP encrypts the Frame Body field of a plaintext MPDU and encapsulates the resulting cipher text using the following steps: a) Increment the PN, to obtain a fresh PN for each MPDU, so that the PN never repeats for the same temporal key. NOTEâ€”Retransmitted MPDUs are not modified on retransmission. 1978 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications b) Use the fields in the MPDU header to construct the additional authentication data (AAD) for GCM. The GCM algorithm provides integrity protection for the fields included in the AAD. MPDU header fields that may change when retransmitted are masked to 0 when calculating the AAD. c) Construct the GCM Nonce block from the PN and A2, where A2 is MPDU Address 2. d) Place the new PN and the key identifier into the 8-octet GCMP Header. e) Use the temporal key, AAD, nonce, and MPDU data to form the cipher text and MIC. This step is known as GCM originator processing. f) Form the encrypted MPDU by combining the original MPDU header, the GCMP header, the encrypted data and MIC, as described in 12.5.5.2. The GCM reference describes the processing of the key, nonce, AAD, and data to produce the encrypted output. See 12.5.5.3.2 to 12.5.5.3.6 for details of the creation of the AAD and nonce from the MPDU and the associated MPDU-specific processing. 12.5.5.3.2 PN processing The PN is incremented by a positive number for each MPDU. The PN shall be incremented in steps of 1 for constituent MPDUs of fragmented MSDUs and MMPDUs. The PN shall never repeat for a series of encrypted MPDUs using the same temporal key. If the PN is larger than dot11PNExhaustionThreshold, an MLME-PN-EXHAUSTION.indication primitive shall be generated. NOTEâ€”When a group addressed MSDU is retransmitted using GCR, it is concealed from non-GCR capable STAs using the procedures described in 11.24.16.3.5. The MPDU containing this concealed A-MSDU has a different PN from the MPDU that contained the original transmission of the group addressed MSDU. 12.5.5.3.3 Construct AAD The AAD construction is as defined in 12.5.3.3.3. 12.5.5.3.4 Construct GCM nonce The Nonce field occupies 12 octets, and its structure is shown in Figure 12-26. A2 PN Octets: 6 6 Figure 12-26â€”Nonce construction The Nonce field has an internal structure of A2 || PN, where â€” MPDU address A2 field occupies octets 0 to 5. This shall be encoded with the octets ordered with A2 octet 0 at octet index 0 and A2 octet 5 at octet index 5. â€” The PN field occupies octets 6 to 11. The octets of PN shall be ordered so that PN0 is at octet index 11 and PN5 is at octet index 6. 12.5.5.3.5 Construct GCMP header The format of the 8-octet GCMP Header is given in 12.5.5.2. The header encodes the PN and Key ID field values used to encrypt the MPDU. 1979 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 12.5.5.3.6 GCM originator processing GCM is a generic authenticate-and-encrypt block cipher mode, and in this standard, GCM is used with the AES block cipher. There are four inputs to GCM originator processing: a) Key: the temporal key (16 octets). b) Nonce: the nonce (12 octets) constructed as described in 12.5.5.3.4. c) Frame body: the plaintext frame body of the MPDU. d) AAD: the AAD (22-30 octets) constructed from the MPDU header as described in 12.5.5.3.3. The GCM originator processing provides authentication and integrity of the frame body and the AAD as well as data confidentiality of the frame body. The output from the GCM originator processing consists of the encrypted data and 16 additional octets of encrypted MIC (see Figure 12-24). The PN values sequentially number each MPDU. Each transmitter shall maintain a single PN (48-bit counter) for each PTKSA, GTKSA, and STKSA. The PN shall be implemented as a 48-bit strictly increasing integer, initialized to 1 when the corresponding temporal key is initialized or refreshed. A transmitter shall not use IEEE 802.11 MSDU or A-MSDU priorities without ensuring that the receiver supports the required number of replay counters. The transmitter shall not reorder GCMP protected frames that are transmitted to the same RA within a replay counter, but may reorder frames across replay counters. One possible reason for reordering frames is the IEEE 802.11 MSDU or A-MSDU priority. The transmitter shall preserve the order of protected robust Management frames that are transmitted to the same DA without the QMF service. When the QMF service is used, the transmitter shall not reorder robust IQMFs within an AC when the frames are transmitted to the same RA. A GCMP protected individually addressed robust Management frame shall be protected using the same TK as a Data frame. 12.5.5.4 GCMP decapsulation 12.5.5.4.1 General Figure 12-27 shows the GCMP decapsulation process. MAC Header Construct Encrypted AAD MPDU || MIC Plaintext A2 Construct GCM Data PN Nonce decryption Data Key Plaintext PN* Replay MPDU check Figure 12-27â€”GCMP decapsulation block diagram 1980 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications GCMP decrypts the Frame Body field of a cipher text MPDU and decapsulates a plaintext MPDU using the following steps: a) The encrypted MPDU is parsed to construct the AAD and nonce values. b) The AAD is formed from the MPDU header of the encrypted MPDU. c) The Nonce value is constructed from the A2 and PN fields. d) The MIC is extracted for use in the GCM integrity checking. e) The GCM recipient processing uses the temporal key, AAD, nonce, MIC, and MPDU cipher text data to recover the MPDU plaintext data as well as to check the integrity of the AAD and MPDU plaintext data. f) The received MPDU header and the MPDU plaintext data from the GCM recipient processing are concatenated to form a plaintext MPDU. g) The decryption processing prevents replay of MPDUs by validating that the PN in the MPDU is greater than the replay counter maintained for the session. See 12.5.5.4.2 to 12.5.5.4.4 for details of this processing. When the received frame is a GCMP protected individually addressed robust Management frame, the contents of the MMPDU body after protection is removed and shall be delivered to the SME via the MLME primitive designated for that MMPDU rather than through the MA-UNITDATA.indication primitive. 12.5.5.4.2 GCM recipient processing GCM recipient processing shall use the same parameters as GCM originator processing. A GCMP protected individually addressed robust Management frame shall use the same TK as a Data frame. There are four inputs to GCM recipient processing: â€” Key: the temporal key (16 octets). â€” Nonce: the nonce (12 octets) constructed as described in 12.5.5.3.4. â€” Encrypted frame body: the encrypted frame body from the received MPDU. The encrypted frame body includes a 16-octet MIC. â€” AAD: the AAD (22-30 octets) that is the canonical MPDU header as described in 12.5.5.3.3. The GCM recipient processing checks the authentication and integrity of the frame body and the AAD as well as decrypting the frame body. The plaintext is returned only if the MIC check is successful. There is one output from error-free GCM recipient processing: â€” Frame body: the plaintext frame body, which is 16 octets smaller than the encrypted frame body. 12.5.5.4.3 Decrypted GCMP MPDU The decapsulation process succeeds when the calculated MIC matches the MIC value obtained from decrypting the received encrypted MPDU. The original MPDU header is concatenated with the plaintext data resulting from the successful GCM recipient processing to create the plaintext MPDU. 12.5.5.4.4 PN and replay detection To effect replay detection, the receiver extracts the PN from the GCMP header. See 12.5.5.2 for a description of how the PN is encoded in the GCMP header. The following processing rules are used to detect replay: 1981 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications a) The receiver shall maintain a separate set of replay counters for each PTKSA, GTKSA, and STKSA. The receiver initializes these replay counters to 0 when it resets the temporal key for a peer. The replay counter is set to the PN value of accepted GCMP MPDUs. b) For each PTKSA, GTKSA, and STKSA, the recipient shall maintain a separate replay counter for each TID, subject to the limitation of the number of supported replay counters indicated in the RSN Capabilities field (see 9.4.2.25), and shall use the PN from a received frame to detect replayed frames. A replayed frame occurs when the PN from a received frame is less than or equal to the current replay counter value for the frameâ€™s MSDU or A-MSDU priority and frame type. c) If dot11RSNAProtectedManagementFramesActivated is true, the recipient shall maintain a single replay counter for received individually addressed robust Management frames that are received with the To DS subfield equal to 0 and shall use the PN from the received frame to detect replays. If dot11QMFActivated is also true, the recipient shall maintain an additional replay counter for each ACI for received individually addressed robust Management frames that are received with the To DS subfield equal to 1. The QMF receiver shall use the ACI encoded in the Sequence Number field of the received frame to select the replay counter to use for the received frame, and shall use the PN from the received frame to detect replays. A replayed frame occurs when the PN from the frame is less than or equal to the current value of the management frame replay counter that corresponds to the ACI of the frame. d) The receiver shall discard any Data frame that is received with its PN less than or equal to the value of the replay counter that is associated with the TA and priority value of the received MPDU. The receiver shall discard MSDUs and MMPDUs whose constituent MPDU PN values are not incrementing in steps of 1. If dot11RSNAProtectedManagementFramesActivated is true, the receiver shall discard any individually addressed robust Management frame that is received with its PN less than or equal to the value of the replay counter associated with the TA of that individually addressed Management frame. e) When discarding a frame, the receiver shall increment by 1 dot11RSNAStatsGCMPReplays for Data frames or dot11RSNAStatsRobustMgmtGCMPReplays for robust Management frames. f) For MSDUs or A-MSDUs sent using the block ack feature, reordering of received MSDUs or A-MSDUs according to the block ack receiver operation (described in 10.24.4) is performed prior to replay detection. 12.6 RSNA security association management 12.6.1 Security associations 12.6.1.1 Security association definitions 12.6.1.1.1 General IEEE Std 802.11 uses the notion of a security association to describe secure operation. Secure communications are possible only within the context of a security association, as this is the context providing the stateâ€”cryptographic keys, counters, sequence spaces, etc.â€”needed for correct operation of the IEEE 802.11 cipher suites. A security association is a set of policy(ies) and key(s) used to protect information. The information in the security association is stored by each party of the security association, needs to be consistent among all parties, and needs to have an identity. The identity is a compact name of the key and other bits of security association information to fit into a table index or an MPDU. The following types of security associations are supported by an RSNA STA: â€” PMKSA: A result of a successful IEEE 802.1X exchange, SAE authentication, or preshared PMK information. A PMKSA can be cached. 1982 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” PMK-R0 security association: A result of a successful FT initial mobility domain association. â€” PMK-R1 security association: A result of a successful FT initial mobility domain association or FT authentication sequence. â€” Mesh PMKSA: A result of successful completion of the active authentication protocol. â€” PTKSA: A result of a successful 4-way handshake, FT 4-way handshake, or FT authentication sequence. â€” Mesh TKSA: A result of a successful authenticated mesh peering exchange (AMPE). â€” GTKSA: A result of a successful group key handshake, 4-way handshake, FT 4-way handshake, or FT authentication sequence. â€” IGTKSA: A result of a successful group key handshake, successful 4-way handshake, FT 4-way handshake, or the Reassociation Response frame of the fast BSS transition protocol. â€” Mesh GTKSA: A result of a successful AMPE or mesh group key handshake. â€” SMKSA: A result of a successful initial SMK handshake. â€” STKSA: A result of a successful 4-way STK handshake following the initial SMK handshake or subsequent rekeying. In order to set up a security association to a peer STA, a SME that does not know the security policy of the peer should send a Probe Request frame to the peer STA to find its security policy before setting up a security association to the peer STA. In order to set up a security association to a peer STA, a STA that received a 4-way handshake but does not know the security policy of the peer should send a Probe Request frame to the peer STA to find its security policy before setting up a security association to the peer STA. 12.6.1.1.2 PMKSA When the PMKSA is the result of a successful IEEE 802.1X authentication, it is derived from the EAP authentication and authorization parameters provided by the AS. When the PMKSA is the result of a successful SAE authentication, it is generated as a result of the successful completion of the SAE exchange. This security association is bidirectional. In other words, both parties use the information in the security association for both sending and receiving. The PMKSA is created by the Supplicantâ€™s SME when the EAP authentication completes successfully or the PSK is configured. The PMKSA is created by the Authenticatorâ€™s SME when the PMK is created from the keying information transferred from the AS, when IEEE 802.1X authentication is utilized, when the SAE exchange successfully completes, or when the PSK is configured. The PMKSA is used to create the PTKSA. PMKSAs have a certain lifetime. The PMKSA consists of the following: â€” PMKID, as defined in 12.7.1.3. The PMKID identifies the security association. â€” Authenticatorâ€™s or peerâ€™s MAC address. For multi-band RSNA, the MAC address is associated with the operating band in use when the PMKSA is established. â€” PMK. â€” Lifetime, as defined in 12.7.1.3. â€” AKMP. â€” All authorization parameters specified by the AS or local configuration. This might include parameters such as the STAâ€™s authorized SSID. 12.6.1.1.3 PMK-R0 security association The PMK-R0 security association is the result of a successful completion of the IEEE 802.1X authentication, SAE authentication, or use of PSK during the FT initial mobility domain association. This security association is bidirectional. It consists of the following: 1983 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” SSID â€” Mobility domain identifier (MDID) â€” PMK-R0 â€” R0KH-ID â€” PMKR0Name â€” S0KH-ID â€” PMK-R0 lifetime â€” Pairwise cipher suite selector â€” All authorization parameters specified by the AS or local configuration 12.6.1.1.4 PMK-R1 security association The PMK-R1 security association is the result of â€” A successful completion of the IEEE 802.1X authentication, SAE authentication, or use of PSK during the FT initial mobility domain association or â€” A successful completion of the authentication phase in the fast BSS transition to the target AP This security association is bidirectional. It consists of the following: â€” SSID â€” MDID â€” PMK-R1 â€” PMK-R1 lifetime â€” PMKR1Name â€” R1KH-ID â€” R0KH-ID â€” PMKR0Name â€” S0KH-ID â€” S1KH-ID â€” Pairwise cipher suite selector â€” All authorization parameters specified by the AS or local configuration 12.6.1.1.5 Mesh PMKSA The mesh PMKSA is the result of successful completion of the active authentication protocol. This security association is bidirectional. The two authenticated parties use the information in the security association for both sending and receiving. The mesh PMKSA is created by the Mesh STAâ€™s SME when the active authentication protocol completes successfully with the peer mesh STA. The mesh PMKSA is used to create the mesh TKSA. Mesh PMKSAs have a certain lifetime. Mesh PMKSAs contain the following, and are identified by their PMKID. â€” PMKID, as defined in 12.4.5.4 â€” Mesh STAâ€™s MAC address â€” Peer mesh STAâ€™s MAC address â€” PMK â€” AEK, as defined in 14.5.7 â€” Lifetime, as defined in 12.7.1.3 â€” Selected AKM suite (see 9.4.2.25.3) 1984 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 12.6.1.1.6 PTKSA The PTKSA is a result of the 4-way handshake, FT 4-way handshake, FT protocol, or FT resource request protocol. This security association is also bidirectional. PTKSAs have the same lifetime as the PMKSA or PMK-R1 security Association, whichever comes first. Because the PTKSA is tied to the PMKSA or to a PMK-R1 security association, it only has the additional information from the 4-way handshake or FT Protocol authentication. For the PTKSA derived as a result of the 4-way handshake, there shall be only one PTKSA per band (see 12.6.19) with the same Supplicant and Authenticator MAC addresses. For the PTKSA derived as a result of an initial mobility domain association or fast BSS transition, there shall be only one PTKSA with the same STAâ€™s MAC address and BSSID. During the 4-way handshake defined in 12.7.6.5 and the FT 4-way handshake defined in 13.4.2, there is state created between message 1 and message 3 of the handshake. This does not create a PTKSA until message 3 is validated by the Supplicant and message 4 is validated by the Authenticator. During the FT authentication sequence defined in 13.8, the PTKSA is validated when message 3 is validated by the R1KH and message 4 is validated by the S1KH. The PTKSA consists of the following: â€” PTK â€” Pairwise cipher suite selector â€” Supplicant MAC address or STAâ€™s MAC address â€” Authenticator MAC address or BSSID â€” Key ID â€” If FT key hierarchy is used, â€” R1KH-ID â€” S1KH-ID â€” PTKName 12.6.1.1.7 Mesh TKSA The mesh TKSA is a result of the AMPE. This security association is also bidirectional. The mesh TKSA shall be deleted when the lifetime expires. The mesh TKSA contains the following: â€” MTK, as defined in 14.5.7 â€” PMKID â€” Local mesh STA MAC address â€” Peer mesh STA MAC address â€” Local Link ID â€” Peer Link ID â€” Local nonce â€” Peer nonce â€” Lifetime as defined in 12.6.16 â€” Pairwise cipher suite selector 12.6.1.1.8 GTKSA The GTKSA results from a successful 4-way handshake, FT 4-way handshake, FT protocol, FT resource request protocol or the group key handshake and is unidirectional. In an infrastructure BSS, there is one GTKSA, used exclusively for encrypting group addressed MPDUs that are transmitted by the AP and for 1985 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications decrypting group addressed transmissions that are received by the STAs. In an IBSS or in a PBSS, each STA defines its own GTKSA, which is used to encrypt its group addressed transmissions, and stores a separate GTKSA for each peer STA so that encrypted group addressed traffic received from other STAs may be decrypted. A GTKSA is created by the Supplicantâ€™s SME when message 3 of the 4-way handshake is received, when message 1 of the group key handshake is received, or when the Reassociation Response frame of the FT handshake is received. The GTKSA is created by the Authenticatorâ€™s SME when the SME changes the GTK and has sent the GTK to all STAs with which it has a PTKSA. A GTKSA consists of the following: â€” Direction vector (whether the GTK is used for transmit or receive). â€” Group cipher suite selector. â€” GTK. â€” Authenticator MAC address. â€” Key ID. â€” All authorization parameters specified by local configuration. This might include parameters such as the STAâ€™s authorized SSID. When the GTK is used to encrypt individually addressed traffic (the selectable cipher suite is â€œUse group cipher suiteâ€), the GTKSA is bidirectional. 12.6.1.1.9 IGTKSA When management frame protection is enabled, a non-AP STAâ€™s SME creates an IGTKSA when it receives a valid message 3 of the 4-way handshake or FT 4-way handshake, the Reassociation Response frame of the fast BSS transition protocol with a status code indicating success, a Mesh Peering Open Message of the Authenticated Mesh Peering Exchange (AMPE) protocol, or a valid message 1 of the group key handshake. The Authenticatorâ€™s SME creates an IGTKSA when it establishes or changes the IGTK with all STAs to which it has a valid PTKSA or mesh TKSA. An IGTKSA consists of the following: â€” Direction vector (whether the IGTK is used for transmit or receive) â€” Key ID â€” IGTK â€” Authenticator MAC address 12.6.1.1.10 Mesh GTKSA The mesh GTKSA results from a successful AMPE or mesh group key handshake and is unidirectional. In an MBSS, each mesh STA defines its own â€œtransmit mesh GTKSA,â€ which is used to encrypt its group addressed transmissions. Also, each mesh STA stores a separate â€œreceive mesh GTKSAâ€ for each peer mesh STA so that encrypted group addressed traffic received from the peer mesh STAs may be decrypted. A transmit mesh GTKSA is created by a mesh STA after the SME has changed the mesh GTK (MGTK) and the new MGTK has been sent to all peer mesh STAs. A receive mesh GTKSA is created by a mesh STA after successfully completing the AMPE in which a wrapped MGTK has been received, or after receiving a valid message 1 of the mesh group key handshake. The receive mesh GTKSA shall be deleted when the lifetime expires or a new receive mesh GTKSA is created with the same Key ID for the same MGTK source mesh STA. See 14.6.1. The MGTK and the GTK shall be independently selected from a uniform distribution. The MGTK source mesh STA MAC address in the mesh GTKSA shall not be the same as the Authenticator MAC address in the GTKSA. 1986 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NOTEâ€”The use of a distinct Transmit MGTK and ESS GTK with identical transmit MAC addresses is precluded by limitations on key rollover and reception by STAs in an infrastructure BSS (see 14.11.5 for collocated mesh STA rules). If the distinct MGTKs were to use different Key IDs, then rollover would be impossible. Since Key ID 0 is reserved for individually addressed frame transmission, there are at most three available Key IDs (only two if extended Key IDs for individually addressed frames are in use), and the different MGTKs would contend for the single remaining Key ID upon rollover. If the distinct MGTKs were to use the same Key IDs, then STAs would incorrectly attempt to decrypt mesh broadcast traffic using the ESS GTK, causing error counters (such as dot11RSNAStatsCCMPDecryptErrors) to continuously increment. (See 12.9.2.6 for a description of the procedure for receiving encrypted frames.) The mesh GTKSA contains the following: â€” MGTK â€” MGTK source mesh STA MAC address (mesh STA that uses this GTK to encrypt transmissions) â€” Group cipher suite selector â€” Direction vector (whether this is a receive mesh GTKSA or transmit mesh GTKSA) â€” Key Index 12.6.1.1.11 SMKSA An SMKSA is the result of a successful SMK handshake by the initiator STA (described in 12.7.8 and 12.11). It is derived from parameters provided by the STAs and AP. This security association is bidirectional between the initiator and the peer STA. In other words, both parties use the information in the security association for both sending and receiving. The SMKSA is created as a result of a successful SMK handshake (see 12.7.8 and 12.11). The SMKSA is used to create the STKSA. The SMKSA consists of the following: â€” SMKID, as defined in 12.7.8. The SMKID identifies the security association. â€” BSSID â€” Initiator MAC address â€” Peer MAC address â€” SMK â€” Lifetime, as defined in 12.7.8. â€” Pairwise cipher suite selector list, as proposed by initiator STA â€” Pairwise cipher suite selector, as selected by peer STA 12.6.1.1.12 STKSA The STKSA is a result of successful completion of the 4-way STK handshake. This security association is bidirectional between the initiator and the peer STAs. The STKSA is used to create session keys to protect this STSL. STKSAs have the same lifetime as the SMKSA or the STSL, whichever comes first. There shall be only one STKSA with the same initiator STA and peer MAC addresses at any one time. STKSA is created as a result of PeerKey handshake (see 12.7.8) or the AP PeerKey protocol (see 12.11). The STKSA consists of the following: â€” STK â€” Pairwise cipher suite selector â€” Initiator MAC address â€” Peer MAC address â€” Key ID 12.6.1.2 TPKSA The TPKSA results from a successful completion of the TPK handshake. This security association is bidirectional between the TDLS initiator STA and the TDLS responder STA. The TPKSA is used to create 1987 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications session keys to protect this TDLS session. The TPKSA has the lifetime indicated in the TPK handshake or the lifetime of the TDLS direct link, whichever comes first. The TPKSA consists of the following: â€” MAC addresses of the TDLS initiator STA and the TDLS responder STA â€” Pairwise cipher suite selector â€” TPK Lifetime â€” TPK â€” Link Identifier 12.6.1.3 Security association life cycle 12.6.1.3.1 General A STA can operate in an ESS, an IBSS, an MBSS, or a PBSS, and a security association has a distinct life cycle for each. A STA that operates OCB does not have a security association life cycle. 12.6.1.3.2 Security association in an ESS In an ESS there are two cases: â€” Initial contact between the STA and the ESS â€” Roaming by the STA within the ESS A STA and AP establish an initial security association via the following steps: a) The STA selects an authorized ESS by selecting among APs that advertise an appropriate SSID. b) The STA then performs IEEE 802.11 authentication followed by association to the chosen AP. Confirmation of security parameters takes place during association. A STA performing IEEE 802.1X authentication uses Open System authentication. A STA performing password-based authentication can use SAE authentication. NOTE 1â€”It is possible for more than one PMKSA to exist. As an example, a second PMKSA might come into existence through PMKSA caching. A STA might leave the ESS and flush its cache. Before its PMKSA expires in the APâ€™s cache, the STA returns to the ESS and establishes a second PMKSA from the APâ€™s perspective. NOTE 2â€”An attack altering the security parameters is detected by the key derivation procedure. NOTE 3â€”IEEE 802.11 Open System authentication provides no security, but is included to maintain backward compatibility with the IEEE 802.11 state machine (see 11.3). c) SAE authentication provides mutual authentication and derivation of a PMK. If Open System authentication is chosen instead, the Authenticator or the Supplicant initiates IEEE 802.1X authentication. The EAP method used by IEEE Std 802.1X-2010 needs to support mutual authentication, as the STA needs assurance that the AP is a legitimate AP. NOTE 1â€”Prior to the completion of IEEE 802.1X authentication and the installation of keys, the IEEE 802.1X Controlled Port in the AP blocks all Data frames. The IEEE 802.1X Controlled Port returns to the unauthorized state and blocks all Data frames before invocation of an MLME-DELETEKEYS.request primitive. The IEEE 802.1X Uncontrolled Port allows IEEE 802.1X frames to pass between the Supplicant and Authenticator. Although IEEE Std 802.1X-2010 does not require a Supplicant Controlled Port, this standard assumes that the Supplicant has a Controlled Port in order to provide the needed level of security. Supplicants without a Controlled Port compromise RSN security and are not used. NOTE 2â€”Any secure network cannot support promiscuous association, e.g., an unsecured operation of IEEE Std 802.11. A trust relationship is needed between the STA and the AS of the targeted SSID prior to association and secure operation, in order for the association to be trustworthy. The reason is that an attacker can deploy a rogue AP just as easily as a legitimate network provider can deploy a legitimate AP, so some sort of prior relationship is necessary to establish credentials between the ESS and the STA. 1988 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications d) The last step is key management. The authentication process, whether SAE authentication utilizing Authentication frames or IEEE 802.1X authentication utilizing Data frames post association, creates cryptographic keys shared between the cryptographic endpointsâ€”the AP and STA, or the IEEE 802.1X AS and the STA, when using SAE or IEEE Std 802.1X, respectively. When using IEEE Std 802.1X, the AS transfers these keys to the AP, and the AP and STA uses one of the key confirmation handshakes, e.g., the 4-way handshake or FT 4-way handshake, to complete security association establishment. When using SAE authentication there is no AS and therefore no key transfer; the 4-way handshake is performed directly between the AP and STA. The key confirmation handshake indicates when the link has been secured by the keys and is ready to allow normal data traffic and protected robust Management frames. When FT is not enabled, a STA roaming within an ESS establishes a new PMKSA by one of the four schemes: â€” In the case of (re)association followed by IEEE 802.1X or PSK authentication, the STA repeats the same actions as for an initial contact association, but its Supplicant also deletes the PTKSA when it roams from the old AP. The Supplicant also deletes the PTKSA when it disassociates/ deauthenticates from all BSSIDs in the ESS. â€” In the case of SAE authentication followed by (re)association, the STA repeats the same actions as for initial contact association, but the non-AP STA also deletes the PTKSA when it roams from the old AP. Note that a STA can take advantage of the fact that it can perform SAE authentication to multiple APs while maintaining a single association with one AP, and then use any of the PMKSAs created during authentication to effect a fast BSS transition. â€” A STA (AP) can cache PMKSAs for APs (STAs) in the ESS to which it has previously performed a full IEEE 802.1X authentication or SAE authentication. If a STA wishes to roam to an AP for which it has cached one or more PMKSAs, it can include one or more PMKIDs in the RSNE of its (Re)Association Request frame. An AP that has retained the PMK for one or more of the PMKIDs can proceed with the 4-way handshake. The AP shall include the PMKID of the selected PMKSA in message 1 of the 4-way handshake. If none of the PMKIDs of the cached PMKSAs matches any of the supplied PMKIDs, or if the AKM of the cached PMKSA differs from that offered in the (Re)Association Request, then the Authenticator, in the case of Open System authentication, shall perform another IEEE 802.1X authentication and, in the case of SAE authentication, shall transmit a Deauthentication frame to the STA. Similarly, if the STA fails to send a PMKID, the STA and AP need to perform a full IEEE 802.1X authentication. â€” A STA already associated with the ESS can request its IEEE 802.1X Supplicant to authenticate with a new AP before associating to that new AP. The normal operation of the DS via the old AP provides the communication between the STA and the new AP. The SME delays reassociation with the new AP until IEEE 802.1X authentication completes via the DS. If IEEE 802.1X authentication completes successfully, then PMKSAs shared between the new AP and the STA are cached, thereby enabling the possible usage of reassociation without requiring a subsequent full IEEE 802.1X authentication procedure. The MLME-DELETEKEYS.request primitive deletes the temporal key(s) established for the security association so that they cannot be used to protect subsequent IEEE 802.11 traffic. An SME uses this primitive when it deletes a PTKSA, GTKSA, or IGTKSA. 12.6.1.3.3 Security association in an IBSS In an IBSS utilizing IEEE 802.11 Open System authentication and IEEE Std 802.1X, when a STAâ€™s SME establishes a security association with a peer STA, it creates both an IEEE 802.1X Supplicant and Authenticator for the peer. A STA in such an IBSS might also receive IEEE 802.1X messages from a previously unknown MAC address. 1989 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications In an IBSS utilizing IEEE 802.11 SAE authentication, a STA creates a security association for a peer upon successful SAE authentication. Any IBSS STA may decline to form a security association with a STA joining the IBSS. An attempt to form a security association may also fail because, for example, the peer uses a different PSK or password from what the STA expects. In an IBSS each STA defines its own group key, i.e., GTK, to secure its group addressed transmissions. Each STA shall use either the 4-way handshake or the group key handshake to distribute its transmit GTK to its new peer STA. When the STA generates a new GTK, it also uses the group key handshake to distribute the new GTK to each established peer. 12.6.1.3.4 Security association in an MBSS In order to create a secure peering, mesh STAs first authenticate each other and create a mesh PMKSA. This can be done using either SAE or IEEE Std 802.1X. A mesh STA shall support SAE authentication (see 12.4). A mesh STA may support IEEE 802.1X authentication (see 4.10). When dot11MeshActiveAuthenticationProtocol is sae (1), the scanning mesh STA shall initiate SAE to the candidate mesh STA. If SAE terminates unsuccessfully, the scanning mesh STA shall terminate the peering establishment procedure. Otherwise, the PMK that results from successful SAE authentication shall be used to create a mesh PMKSA. When dot11MeshActiveAuthenticationProtocol is ieee8021x (2), then the scanning mesh STA shall initiate the MPM protocol to establish a peering. If the MPM protocol fails then the scanning mesh STA shall terminate the peering establishment procedure. Otherwise, IEEE 802.1X authentication shall be performed between the two peers according to the following: a) If only one mesh STA has the Connected to AS field set to 1, that STA shall act as the IEEE 802.1X Authenticator and the other STA shall act as the IEEE 802.1X Supplicant; b) If both mesh STAs have the Connected to AS field set to 1, then the mesh STA with the higher MAC address shall act as the IEEE 802.1X Authenticator and the other mesh STA shall act as the IEEE 802.1X Supplicant (see 12.7.1 for MAC address comparison). If IEEE 802.1X authentication fails, the peering establishment procedure shall be terminated and the peering established between the two mesh STAs shall be closed. Otherwise, the peering established between the two mesh STAs shall be closed and a mesh PMKSA shall be created using the PMK that resulted from the successful IEEE 802.1X authentication. 12.6.1.3.5 Security association in a PBSS A STA and a peer establish an initial security association via the following steps: a) The STA selects an authorized PBSS by identifying a peer from a DMG Beacon, Announce, Probe Response, or Information Response frames. b) A STA may associate with a peer if the peer is a PCP. c) If authentication is required, the STA or the peer initiates IEEE 802.1X authentication. The EAP method used by IEEE Std 802.1X-2010 shall support mutual authentication. d) The last step is key management. The authentication process creates cryptographic keys shared between the IEEE 802.1X AS and the STA. The AS transfers these keys to the peer and the peer and the STA use one of the key confirmation handshakes, e.g., the 4-way handshake or FT 4-way handshake, to complete security association establishment. The key confirmation handshake indicates when the link has been secured by the keys and is ready to allow data traffic and protected robust Management frames. 1990 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 12.6.2 RSNA selection A STA prepared to establish RSNAs shall advertise its capabilities by including the RSNE in Beacon, Information Response, and Probe Response frames and may also include the RSNE in DMG Beacon and Announce frames. The included RSNE shall specify all of the authentication and cipher suites enabled by the STAâ€™s policy. A STA shall not advertise any authentication or cipher suite that is not enabled. The SME shall utilize the MLME-SCAN.request primitive to identify neighboring STAs that assert robust security and advertise an SSID identifying an authorized ESS, PBSS, or IBSS. A STA may decline to communicate with STAs that fail to advertise an RSNE in their Beacon, Information Response, and Probe Response frames or that do not advertise an authorized SSID. A STA may also decline to communicate with other STAs that do not advertise authorized authentication and cipher suites within their RSNEs. A STA shall advertise the same RSNE in its Beacon, DMG Beacon, Announce, Information Response, and Probe Response frames. NOTEâ€”Whether a STA with robust security enabled attempts to communicate with a STA that does not include the RSNE is a matter of policy. A STA shall observe the following rules when processing an RSNE: â€” A STA shall advertise the highest version it supports. â€” A STA shall request the highest Version field value it supports that is less than or equal to the version advertised by the peer STA. â€” Two peer STAs without overlapping supported Version field values shall not use RSNA methods to secure their communication. â€” A STA shall ignore suite selectors that it does not recognize. 12.6.3 RSNA policy selection in an infrastructure BSS RSNA policy selection in an infrastructure BSS utilizes the normal IEEE 802.11 association procedure. RSNA policy selection is performed by the associating STA. The STA does this by including an RSNE in its (Re)Association Requests. In an RSN, an AP shall not associate with pre-RSNA STAs, i.e., with STAs that fail to include the RSNE in the (Re)Association Request frame. An SME initiating an association shall insert an RSNE into its (Re)Association Request via the MLME- ASSOCIATE.request or MLME-REASSOCIATE.request primitive, when the targeted AP indicates RSNA support. The initiating STAâ€™s RSNE shall include one authentication and pairwise cipher suite from among those advertised by the targeted AP in its Beacon and Probe Response frames. It shall also specify the group cipher suite specified by the targeted AP. If at least one RSNE field from the APâ€™s RSNE fails to overlap with any value the STA supports, the STA shall decline to associate with that AP. An HT STA shall eliminate TKIP as a choice for the pairwise cipher suite if CCMP is advertised by the AP or if the AP included an HT Capabilities element in its Beacon and Probe Response frames. The elimination of TKIP as a choice for the pairwise cipher suite may result in a lack of overlap of the remaining pairwise cipher suite choices, in which case the STA shall decline to create an RSN association with that AP. If an RSNA-capable AP receives a (Re)Association Request frame that includes an RSNE and if it chooses to accept the association as a secure association, then it shall use the authentication and pairwise cipher suites in the (Re)Association Request frame, unless the AP includes an optional second RSNE in message 3 of the 4-way handshake. If the second RSNE is supplied in message 3, then the pairwise cipher suite used by the security association, if established, shall be the pairwise cipher from the second RSNE. 1991 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications In order to accommodate local security policy, a STA may choose not to associate with an AP that does not support any pairwise cipher suites. An AP may indicate that it does not support any pairwise keys by advertising 00-0F-AC:0 (Use group cipher suite) as the pairwise cipher suite selector. NOTEâ€”When an ESS uses PSKs, STAs negotiate a pairwise cipher. However, any STA in the ESS can derive the pairwise keys of any other that uses the same PSK by capturing the first two messages of the 4-way handshake. This provides malicious insiders with the ability to eavesdrop as well as the ability to establish a man-in-the-middle attack. An RSNA-enabled AP shall use Table 12-2 and the values of the Management Frame Protection Capable (MFPC) and Management Frame Protection Required (MFPR) bits advertised in the RSNEs to determine if it may associate with a non-AP STA. An RSNA enabled non-AP STA shall use Table 12-2 and the values of the Management Frame Protection Capable and Management Frame Protection Required bits advertised in the RSNEs to determine if it may associate with an AP. Management frame protection is enabled when dot11RSNAProtectedManagementFramesActivated is set to 1. Management frame protection is negotiated when an AP and non-AP STA set the Management Frame Protection Capable field to 1 in their respective RSNEs in the (re)association procedure, and both parties confirm the Management Frame Protection Capable bit set to 1 in the 4-way handshake, FT 4-way handshake, or the FT fast BSS transition protocol. Table 12-2â€”Robust management frame selection in an infrastructure BSS AP AP STA STA AP action STA action MFPC MFPR MFPC MFPR 0 0 0 0 The AP may associate with the The STA may associate with the STA AP 1 0 0 0 The AP may associate with the The STA may associate with the STA AP 1 0 or 1 1 0 or 1 The AP may associate with the The STA may associate with the STA AP 1 1 0 0 The AP shall reject associations The STA shall not associate from the STA with the Status with the AP Code ROBUST_MANAGEMENT_P OLICY_VIOLATION 0 0 1 1 No action The STA shall not try to associate with the AP 0 0 1 0 The AP may associate with the The STA may associate with the STA AP 1 0 or 1 0 1 The STA advertises an invalid The STA shall not try to setting. The AP shall reject associate with the AP associations from the STA with the Status Code ROBUST_MANAGEMENT_P OLICY_VIOLATION 0 1 1 0 or 1 No action The AP advertises an invalid setting. The STA shall not try to associate with the AP 12.6.4 TSN policy selection in an infrastructure BSS In a TSN, an RSNA STA shall include the RSNE in its (Re)Association Requests. 1992 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications An RSNA-capable AP configured to operate in a TSN shall include the RSNE and may associate with both RSNA and pre-RSNA STAs. In other words, an RSNA-capable AP shall respond to an associating STA that includes the RSNE just as in an RSN. If an AP operating within a TSN receives a (Re)Association Request frame without an RSNE, its IEEE 802.1X Controlled Port shall initially be blocked. The SME shall unblock the IEEE 802.1X Controlled Port when WEP has been enabled. 12.6.5 RSNA policy selection in an IBSS and for DLS In an IBSS all STAs use a single group cipher suite, and all STAs support a common subset of pairwise cipher suites. However, the SMEs of any pair of non-HT STAs may negotiate to use any common pairwise cipher suite they both support. Each STA shall include the group cipher suite and its list of pairwise cipher suites in its Beacon and Probe Response frames. Two STAs shall not establish a PMKSA unless they have advertised the same group cipher suite. Similarly, the two STAs shall not establish a PMKSA if the STAs have advertised disjoint sets of pairwise cipher suites. An HT STA that is in an IBSS or that is transmitting frames through a direct link shall eliminate TKIP as a choice for the pairwise cipher suite if CCMP is advertised by the other STA or if the other STA included an HT Capabilities element in any of its Beacon, Probe Response, DLS Request, or DLS Response frames. NOTEâ€”The elimination of TKIP as a choice for the pairwise cipher suite might result in a lack of overlap of the remaining pairwise cipher suite choices, in which case the STAs do not exchange encrypted frames. In order to set up a security association with a peer STA, the SME of an IBSS STA that does not know the peerâ€™s policy needs first to obtain the peerâ€™s security policy using a Probe Request frame. The SME entities of the two STAs select the pairwise cipher suites using one of the 4-way handshakes. The SMEs of each pair of STAs within an IBSS may use the EAPOL-Key 4-way handshake to select a pairwise cipher suite. As specified in 12.7.2, message 2 and message 3 of the 4-way handshake convey an RSNE. The message 2 RSNE includes the selected pairwise cipher suite, and message 3 includes the RSNE that the STA would send in a Probe Response frame. If the 4-way handshake is successfully completed, then the pair of STAs shall use the pairwise cipher suite specified in message 2 of the 4-way handshake initiated by the Authenticator STA with the higher MAC address (see 12.7.1). The SME shall check that the group cipher suite and AKMP match those in the Beacon and Probe Response frames for the IBSS. NOTE 1â€”The RSNEs in message 2 and message 3 are not the same as in the Beacon frame. The group cipher and AKMP are the same, but the pairwise ciphers might differ because Beacon frames from different STAs might advertise different pairwise ciphers. Thus, IBSS STAs use the same AKM suite and group cipher, while different pairwise ciphers might be used between STA pairs. NOTE 2â€”When an IBSS uses PSKs, STAs can negotiate a pairwise cipher. However, any STA in the IBSS can derive the PTKs of any other that uses the same PSK by capturing the first two messages of the 4-way handshake. This provides malicious insiders with the ability to eavesdrop as well as the ability to establish a man-in-the-middle attack. To establish a connection with a peer STA, an RSNA enabled STA that implements management frame protection shall use Table 12-3 and the MFPC and MFPR values advertised in the RSNEs exchanged in the 4-way handshake initiated by the Authenticator of the STA with the larger MAC address to determine if the communication is allowed. Management frame protection is enabled when dot11RSNAProtectedManagementFramesActivated is set to 1. The STAs negotiate protection of Management frames when the both STAs set the Management Frame Protection Capable subfield to 1 during the 4-way handshake. 1993 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 12-3â€”Robust management frame selection in an IBSS Peer Peer MFPC MFPR STA STA STA action MFPC MFPR 0 0 0 0 The STA may exchange data with the peer STA. 1 0 0 0 The STA may exchange data with the peer STA. 1 0 or 1 1 0 or 1 The STA may exchange data with the peer STA. 1 1 0 0 The STA shall not exchange data with the peer STA and shall reject security association attempts from the peer STA with the Status Code ROBUST_MANAGEMENT_POLICY_VIOLATION. 0 0 1 1 The STA shall not exchange data with the peer STA and shall reject security association attempts from the peer STA with the Status Code ROBUST_MANAGEMENT_POLICY_VIOLATION. 0 0 1 0 The STA may establish a security association with the peer STA. 1 0 or 1 0 1 The STA shall not establish a security association with the peer STA and shall reject security association attempts from the peer STA with the Status Code ROBUST_MANAGEMENT_POLICY_VIOLATION because the peer STA is advertising an invalid setting. The STA shall not exchange data with the peer STA. 0 1 1 0 or 1 The peer STA shall not establish a security association with the peer STA and shall reject security association attempts from the STA with the Status Code ROBUST_MANAGEMENT_POLICY_VIOLATION because the STA is advertising an invalid setting. 12.6.6 TSN policy selection in an IBSS Pre-RSNA STAs generate Beacon and Probe Response frames without an RSNE and ignore the RSNE because it is unknown to them. This allows an RSNA STA to identify the pre-RSNA STAs from which it has received Beacon and Probe Response frames. If an RSNA STAâ€™s SME instead identifies a possible IBSS member on the basis of a received group addressed message, via MLME-PROTECTEDFRAMEDROPPED.indication primitive, it cannot identify the peerâ€™s security policy directly. The SME might attempt to obtain the peer STAâ€™s security policy via a Probe Request frame. 12.6.7 RSNA policy selection in an MBSS RSNA policy is advertised in Beacon frames and Probe Response frames. A mesh STA identifies a candidate peer by parsing its neighbor STAâ€™s Beacon frames and Probe Response frames (see 14.2). An HT mesh STA shall eliminate TKIP as a choice for the pairwise cipher suite if CCMP is advertised by the peer or if the peer included an HT Capabilities element in any of its Beacon or Probe Response frames. All mesh STAs in an MBSS use the same group cipher suite. Mesh STAs establish authenticated peerings with each other using the AMPE protocol (see 14.5). In AMPE, mesh STAs negotiate a pairwise cipher suite, and establish a mesh TKSA, to protect individually addressed frames and state a group cipher suite and establish a mesh GTKSA to process incoming group addressed frames from a peer. 1994 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The AMPE performs key confirmation of a secret, authenticated, and shared PMK derived by an authenticated key management protocol (see 12.4) and derives pairwise symmetric keys. 12.6.8 RSNA policy selection in a PBSS RSNA policy selection in a PBSS utilizes the association procedure (11.3.1) if the initiating STA chooses to associate with a PCP. RSNA policy selection is performed by the associating STA. The STA does this by including an RSNE in its (Re)Association Requests. The STA follows the procedures in 12.5.3 to select RSNA policy with the PCP, with the PCP taking the role of the AP. If the initiating STA chooses not to associate with a peer in a PBSS, it follows the procedures in 12.5.5 to select RSNA policy with the peer. 12.6.9 RSN management of the IEEE 802.1X Controlled Port When the policy selection process chooses IEEE 802.1X authentication, this standard assumes that IEEE 802.1X Supplicants and Authenticators exchange protocol information via the IEEE 802.1X Uncontrolled port. The IEEE 802.1X Controlled Port is blocked from passing general data traffic between the STAs until an IEEE 802.1X authentication procedure completes successfully over the IEEE 802.1X Uncontrolled Port. The security of an RSNA depends on this assumption being true. In an infrastructure BSS or PBSS, if the STA associates with the AP or PCP, the STA indicates the IEEE 802.11 link is available by invoking the MLME-ASSOCIATE.confirm or MLME- REASSOCIATE.confirm primitive. This signals the Supplicant that the MAC has transitioned from the disabled to enabled state. At this point, the Supplicantâ€™s Controlled Port is blocked, and communication of all non-IEEE-802.1X MSDUs sent or received via the port is not authorized. In an infrastructure BSS or PBSS, if the AP or PCP associates with a STA, the AP or PCP indicates that the IEEE 802.11 link is available by invoking the MLME-ASSOCIATE.indication or MLME- REASSOCIATE.indication primitive. At this point the Authenticatorâ€™s Controlled Port corresponding to the STAâ€™s association is blocked, and communication of all non-IEEE-802.1X MSDUs sent or received via the Controlled Port is not authorized. In an IBSS the STA shall block all IEEE 802.1X ports at initialization. Communication of all non- IEEE 802.1X MSDUs sent or received via the Controlled Port is not authorized. In a PBSS, if a STA chooses not to associate with the PCP, the STA shall block all IEEE 802.1X ports at initialization. Communication of all non-IEEE-802.1X MSDUs sent or received via the Controlled Port is not authorized. This standard assumes each Controlled Port remains blocked until the IEEE 802.1X state variables portValid and keyDone both become true. This assumption means that the IEEE 802.1X Controlled Port discards MSDUs sent across the IEEE 802.11 channel prior to the installation of cryptographic keys into the MAC. This protects the STAâ€™s host from forged MSDUs written to the channel while it is still being initialized. The MAC does not distinguish between MSDUs for the Controlled Port, and MSDUs for the Uncontrolled Port. In other words, EAPOL-Start frames and EAPOL-Key frames are encrypted only after invocation of the MLME-SETPROTECTION.request primitive. This standard assumes that IEEE Std 802.1X-2010 does not block the Controlled Port when authentication is triggered through reauthentication. During IEEE 802.1X reauthentication, an existing RSNA can protect all MSDUs exchanged between the STAs. Blocking MSDUs is not required during reauthentication over an RSNA. 1995 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 12.6.10 RSNA authentication in an infrastructure BSS 12.6.10.1 General When establishing an RSNA in a non-FT environment or during an FT initial mobility domain association, a STA shall use IEEE 802.11 SAE authentication or Open System authentication prior to (re)association. SAE authentication is initiated when a STAâ€™s MLME-SCAN.confirm primitive finds another AP within the current ESS that advertises support for SAE in its RSNE. IEEE 802.1X authentication is initiated by any one of the following mechanisms: â€” If a STA negotiates to use IEEE 802.1X authentication during (re)association, the STAâ€™s management entity may respond to the MLME-ASSOCIATE.confirm (or indication) or MLME- REASSOCIATE.confirm (or indication) primitive by requesting the Supplicant (or Authenticator) to initiate IEEE 802.1X authentication. Thus, in this case, authentication is driven by the STAâ€™s decision to associate and the APâ€™s decision to accept the association. â€” If a STAâ€™s MLME-SCAN.confirm primitive finds another AP within the current ESS, a STA may signal its Supplicant to use IEEE Std 802.1X-2010 to preauthenticate with that AP. NOTEâ€”A roaming STAâ€™s IEEE 802.1X Supplicant can initiate preauthentication by sending an EAPOL-Start frame via its old AP, through the DS, to a new AP. â€” If a STA receives an IEEE 802.1X message, it delivers this to its Supplicant or Authenticator, which may initiate a new IEEE 802.1X authentication. 12.6.10.2 Preauthentication and RSNA key management Preauthentication allows a STA to perform RSNA authentication with an AP prior to attempting (re)association. This might reduce the time that the IEEE 802.1X port is not valid. A STA shall not use preauthentication except when pairwise keys are employed. A STA shall not use preauthentication within the same mobility domain if AKM suite type 00-0F-AC:3 or 00-0F-AC:4 is used in the current association. Preauthentication shall not be used unless the new AP advertises the preauthentication capability in the RSNE. When preauthentication is used, then: a) Authentication is independent of roaming. b) The Supplicant may authenticate with multiple APs at a time. NOTEâ€”Preauthentication might be useful as a performance enhancement, as reassociation does not include the protocol overhead of a full reauthentication when it is used. Preauthentication uses the IEEE 802.1X protocol and state machines with EtherType 88-C7, rather than the EtherType 88-8E. Only IEEE 802.1X frame types EAP-Packet and EAPOL-Start are valid for preauthentication. A Supplicant may initiate preauthentication when it has completed the 4-way handshake and configured the required temporal key(s). To effect preauthentication, the Supplicant sends an EAPOL-Start frame with the DA being the BSSID of a targeted AP and the RA being the BSSID of the AP with which it is associated. The target AP shall use a BSSID equal to the MAC address of its Authenticator. As preauthentication frames do not use the IEEE 802.1X EAPOL EtherType field, the AP with which the STA is currently associated need not apply any special handling. The AP and the MAC in the STA shall handle these frames in the same way as other frames with arbitrary EtherType field values that require distribution via the DS. 1996 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications An APâ€™s Authenticator that receives an EAPOL-Start frame via the DS may initiate IEEE 802.1X authentication to the STA via the DS. The DS forwards this message to the AP with which the STA is associated. The result of preauthentication may be a PMKSA, if the IEEE 802.1X authentication completes successfully. The AKM shall be set to 00-0F-AC:1 in the PMKSA that results from preauthentication. If preauthentication produces a PMKSA, then, when the Supplicantâ€™s STA associates with the preauthenticated AP, the Supplicant may use the PMKSA with the 4-way handshake. Successful completion of EAP authentication over IEEE Std 802.1X establishes a PMKSA at the Supplicant. The Authenticator has the PMKSA when the AS completes the authentication, passes the keying information (the master session key (MSK), a portion of which is the PMK) to the Authenticator, and the Authenticator creates a PMKSA using the PMK. The PMKSA is inserted into the PMKSA cache. Therefore, if the Supplicant and Authenticator lose synchronization with respect to the PMKSA, the 4-way handshake fails. In such circumstances, dot11RSNA4WayHandshakeFailures shall be incremented. A Supplicant may initiate preauthentication with any AP within its present ESS with preauthentication enabled regardless of whether the targeted AP is within radio range. Even if a STA has preauthenticated, it is still possible that it may have to undergo a full IEEE 802.1X authentication, as the APâ€™s Authenticator may have purged its PMKSA due to, for example, unavailability of resources, delay in the STA associating, etc. 12.6.10.3 Cached PMKSAs and RSNA key management In a non-FT environment, a STA might cache PMKSAs it establishes as a result of previous authentication. The PMKSA shall not be changed while cached. The PMKSA in the PMKSA is used with the 4-way handshake to establish fresh PTKs. If a STA in an infrastructure BSS has determined it has a valid PMKSA with an AP to which it is about to (re)associate, it performs Open System authentication to the AP, and then it includes the PMKID for the PMKSA in the RSNE in the (Re)Association Request. When the PMKSA was not created using pre- authentication, the AKM indicated in the RSNE by the STA in the (Re)Association Request shall be identical to the AKM used to establish the cached PMKSA in the first place. Upon receipt of a (Re)Association Request frame with one or more PMKIDs, an AP checks whether its Authenticator has cached a PMKSA for the PMKIDs and whether the AKM in the cached PMKSA matches the AKM in the (Re)Association Request; and if so, it shall assert possession of that PMKSA by beginning the 4-way handshake after association has completed. If the Authenticator does not have a PMKSA for the PMKIDs in the (Re)Association Request, its behavior depends on how the PMKSA was established. If SAE authentication was used to establish the PMKSA, then the AP shall reject (re)association by sending a (Re)Association Response frame with status code STATUS_INVALID_PMKID. Note that this allows the non-AP STA to fall back to full SAE authentication to establish another PMKSA. If IEEE 802.1X authentication was used to establish the PMKSA, the AP begins a full IEEE 802.1X authentication after association has completed. If both sides assert possession of a cached PMKSA, but the 4-way handshake fails, both sides may delete the cached PMKSA for the selected PMKID. If the lifetime of a cached PMKSA expires, the STA shall delete the expired PMKSA. If a STA roams to an AP with which it is preauthenticating and the STA does not have a PMKSA for that AP, the STA needs to initiate a full IEEE 802.1X EAP authentication. 1997 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 12.6.11 RSNA authentication in an IBSS When authentication is used in an IBSS, it is driven by each STA wishing to establish communications. The management entity of this STA chooses a set of STAs with which it might need to authenticate and then may cause the MAC to send an IEEE 802.11 Open System authentication message to each targeted STA. Candidate STAs can be identified from Beacon frames, Probe Response frames, and Data frames from the same BSSID. Before communicating with STAs identified from Data frames, the security policy of the STAs may be obtained, e.g., by sending a Probe Request frame to the STA and obtaining a Probe Response frame. Targeted STAs that wish to respond may return an IEEE 802.11 Open System authentication message to the initiating STA. When IEEE 802.1X authentication is used, the STA management entity requests its local IEEE 802.1X entity to create a Supplicant PAE for the peer STA. The Supplicant PAE initiates the authentication to the peer STA by sending an EAPOL-Start frame to the peer. The STA management entity also requests its local IEEE 802.1X entity to create an Authenticator PAE for the peer STA on receipt of the EAPOL-Start frame. The Authenticator initiates authentication to the peer STA by sending an EAP-Request message or, if PSK mode is in effect, message 1 of the 4-way handshake. Upon initial authentication between any pair of STAs, Data frames, other than IEEE 802.1X messages, are not allowed to flow between the pair of STAs until both STAs in each pair of STAs have successfully completed AKM and have provided the supplied encryption keys. Upon the initiation of an IEEE 802.1X reauthentication by any STA of a pair of STAs, Data frames continue to flow between the STAs while authentication completes. Upon a timeout or failure in the authentication process, the Authenticator of the STA initiating the reauthentication shall cause a Deauthentication message to be sent to the Supplicant of the STA targeted for reauthentication. The Deauthentication message causes both STAs in the pair of STAs to follow the deauthentication procedure defined in 11.3.4.4 and 11.3.4.5. The IEEE 802.1X reauthentication timers in each STA are independent. If the reauthentication timer of the STA with the higher MAC address (see 12.7.1 for MAC comparison) triggers the reauthentication via its Authenticator, its Supplicant shall send an EAPOL-Start frame to the authenticator of the STA with the lower MAC address (see 12.7.1 for MAC comparison) to trigger reauthentication on the other STA. This process keeps the pair of STAs in a consistent state with respect to derivation of one or more fresh temporal keys upon an IEEE 802.1X reauthentication. When it receives an MLME-AUTHENTICATE.indication primitive due to an Open System authentication request, the IEEE 802.11 management entity on a targeted STA shall, if it intends to set up a security association with the peer STA, request its Authenticator to begin IEEE 802.1X authentication, i.e., to send an EAP-Request/Identity message or message 1 of the 4-way handshake to the Supplicant. The EAPOL-Key frame is used to exchange information between the Supplicant and the Authenticator to negotiate a fresh PTK. The 4-way handshake produces a single PTK from the PMK. The 4-way handshake and group key handshake use the PTK to protect the GTK as it is transferred to the receiving STA. Password or PSK authentication may also be used in an IBSS. When a single password or PSK is shared among the IBSS STAs, an SAE capable STA wishing to establish communication with a STA that advertises support for SAE in Beacon and Probe Response frames invokes SAE authentication, and upon successful conclusion of SAE, sends 4-way handshake message 1 to the target STA. If the STA does not support SAE authentication or the target STA does not advertise support for SAE in Beacon and Probe Response frames, the STA may use the PSK as a PMK and initiate the 4-way handshake by sending a 4-way handshake message 1 to the target STA. In either case, the targeted STA responds to message 1 with message 2 of the 4-way handshake and begins its 4-way handshake by sending message 1 to the initiating STA. The two 4-way handshakes establish PTKSAs and GTKSAs to be used between the initiating STA and 1998 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications the targeted STA. PSK PMKIDs have security vulnerabilities when used with low-entropy keys and should be used only after taking this into account. The model for security in an IBSS is not general. In particular, it assumes the following: a) The sets of use cases for which the authentication procedures described in this subclause are valid are as follows: 1) Password or PSK-based authentication using SAE to perform mutual authentication and generation of a shared PMK. 2) An alternate form of PSK-based authentication, typically managed by the pass-phrase hash method as described in J.4. This method has security vulnerabilities and should only be used when SAE authentication is not possible. 3) EAP-based authentication, using credentials that have been issued and preinstalled on the STAs within a common administrative domain, such as a single organization b) All of the STAs are in direct radio communication. In particular, there is no routing, bridging, or forwarding of traffic by a third STA to effect communication. This assumption is made, because the model makes no provision to protect IBSS topology information from tampering by one of the members. 12.6.12 RSNA authentication in an MBSS When establishing an RSNA in an MBSS, a mesh STA shall use IEEE 802.11 SAE authentication (see 12.4), or optionally IEEE 802.1X authentication, prior to establishment of an authenticated peering. An RSNA security association, called a mesh PMKSA, is created upon successful completion of authentication. The mesh PMKSA is used with the AMPE to create a mesh TKSA. A mesh PMKSA may be cached and used with the AMPE to establish a fresh mesh TKSA. A STA includes the PMKID for the PMKSA in the Mesh Peering Open frame. If the PMKID in a received Mesh Peering Open frame is unknown, the AMPE handshake fails. If both sides assert possession of a cached mesh PMKSA but the AMPE handshake fails, a STA may delete the cached mesh PMKSA for the selected PMKID. A mesh PMKSA shall not be changed while cached. Authentication using IEEE 802.11 SAE authentication is based on a password. A password is required to be shared between two mesh STAs in order to successfully complete authentication. This password can be pairwise â€“ each pair of mesh STAs in an MBSS has a unique password â€“ or it can be shared-all mesh STAs in the MBSS share the same password. Due to the security properties of IEEE 802.11 SAE authentication, an adversary has no greater possibility in determining a shared password than in determining a pairwise password. The potential for misuse, though, is greater if a shared password becomes known to an adversary because an unlimited number of mesh STAs under the control of the adversary can be added to the MBSS. 12.6.13 RSNA authentication in a PBSS IEEE 802.11 Open System authentication is not used in a PBSS. When establishing an RSNA with a PCP, a STA may associate to the PCP and initiate RSNA authentication with the PCP following the procedures of 12.6.10, with the PCP taking the role of the AP. When a STA chooses not to associate to a peer, it initiates RSNA authentication with the peer following the procedures of 12.6.11 with the following caveat: if both peers simultaneously initiate RSNA authentication, the peer with the lower MAC address shall abandon the authentication it initiated in favor of the authentication initiated by the peer with the higher MAC address. 1999 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 12.6.14 RSNA key management in an infrastructure BSS When the IEEE 802.1X authentication completes successfully, this standard assumes that the STAâ€™s IEEE 802.1X Supplicant and the IEEE 802.1X AS share a secret, called a PMK. In a non-FT environment, the AS transfers the PMK, within the MSK, to the AP, using a technique that is outside the scope of this standard; the derivation of the PMK from the MSK is EAP-method-specific. With the PMK in place, the AP initiates a key confirmation handshake with the STA. The key confirmation handshake sets the IEEE 802.1X state variable portValid (as described in IEEE Std 802.1X-2010) to true. When SAE authentication completes, both STAs share a PMK. With this PMK in place, the AP initiates the key confirmation handshake with the STA. The key confirmation handshake is implemented by the 4-way handshake. The purposes of the 4-way handshake are as follows: a) Confirm the existence of the PMK at the peer. b) Ensure that the security association keys are fresh. c) Synchronize the installation of one or more temporal keys into the MAC. d) Transfer the GTK from the Authenticator to the Supplicant. e) Confirm the selection of cipher suites. NOTE 1â€”It is possible to forge message 1 of the 4-way handshake. However, the forgery attempt is detected in the failure of the 4-way handshake. NOTE 2â€”Neither the AP nor the STA can use the PMK for any purpose but the one specified herein without compromising the key. If the AP uses it for another purpose, then the STA can masquerade as the AP; similarly if the STA reuses the PMK in another context, then the AP can masquerade as the STA. The Supplicant and Authenticator signal the completion of key management by utilizing the MLME- SETKEYS.request primitive to configure the agreed-upon temporal pairwise key into the IEEE 802.11 MAC and by calling the MLME-SETPROTECTION.request primitive to enable its use. A second key exchange, the group key handshake, is also defined. It distributes a subsequent GTK. The APâ€™s Authenticator can use the group key handshake to update the GTK at the Supplicant. The group key handshake uses the EAPOL-Key frames for this exchange. When it completes, the Supplicant can use the MLME-SETKEYS.request primitive to configure the GTK into the IEEE 802.11 MAC. 12.6.15 RSNA key management in an IBSS To establish a security association between two IBSS STAs, each STAâ€™s SME has an accompanying IEEE 802.1X Authenticator and Supplicant. Each SME initiates the 4-way handshake from the Authenticator to the peer STAâ€™s Supplicant (see 12.6.11). Two separate 4-way handshakes are conducted. The 4-way handshake is used to negotiate the pairwise cipher suites, as described in 12.6.5. The IEEE 802.11 SME configures the temporal key portion of the PTK into the IEEE 802.11 MAC. Each Authenticator uses the KCK and KEK portions of the PTK negotiated by the exchange it initiates to distribute its own GTK and if management frame protection is enabled, its own IGTK. Each Authenticator generates its own GTK and if management frame protection is enabled, its own IGTK, and uses either the 4- way handshake or the group key handshake to transfer the GTK and if management frame protection is negotiated, the IGTK, to other STAs with whom it has completed a 4-way handshake. The pairwise key used between any two STAs shall be the pairwise key from the 4-way handshake initiated by the STA with the highest MAC address. A STA joining an IBSS is required to adopt the security configuration of the IBSS, which includes the group cipher suite, pairwise cipher suite, AKMP, and if management frame protection is enabled, group 2000 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications management cipher suite (see 12.6.5). The STA shall not set up a security association with any STA having a different security configuration. The Beacon and Probe Response frames of the various STAs within an IBSS need to reflect a consistent security policy, as the beacon initiation rotates among the STAs. A STA joining an IBSS shall support and advertise in the Beacon frame the security configuration of the IBSS, which includes the group cipher suite, advertised pairwise cipher suite, AKMP, and if management frame protection is enabled, group management cipher suite (see 12.6.5). The STA may use the Probe Request frame to discover the security policy of a STA, including additional individual cipher suites the STA supports. If enabled, management frame protection shall only be used as a required feature (MFPR) in an IBSS. NOTEâ€”Because of the requirement for a STA joining an IBSS to support the security configuration of the IBSS, all Beacon frames transmitted in an IBSS have the same security policy. 12.6.16 RSNA key management in an MBSS Upon successful completion of the AMPE, a secure mesh peering is established between two mesh STAs. This secure mesh peering includes a mesh PMKSA and a mesh TKSA. Multiple mesh TKSAs may be created using a single mesh PMKSA (a limit to that number is a policy decision outside the scope of this standard). A mesh TKSA is logically a child of the mesh PMKSA. A mesh TKSA shall be deleted if the corresponding mesh PMKSA, which was used by the AMPE to create it, is deleted. Mesh PMKSAs are limited by their lifetime (see 12.7.1.3). 12.6.17 RSNA key management in a PBSS Upon successful association and authentication in a PBSS, a STA performs a key confirmation handshake with the PCP, following the procedures in 12.6.14 with the PCP taking the role of the AP. If a STA chooses not to associate to a peer, after successful authentication, it performs a key confirmation handshake with the peer following the procedures in 12.6.15 with the following caveat: if both peers simultaneously initiate the key confirmation handshake, the peer with the lower MAC address shall abandon the handshake it initiated in favor of the handshake initiated by the peer with the higher MAC address. 12.6.18 RSNA security association termination When a non-AP STAâ€™s SME receives a successful MLME-ASSOCIATE.confirm or MLME- REASSOCIATE.confirm primitive that is not part of a fast BSS transition or receives or invokes an MLME Disassociation or Deauthentication primitive, it deletes some security associations. Similarly, when an APâ€™s SME â€” receives an MLME-ASSOCIATE.indication or MLME-REASSOCIATE.indication primitive from a STA that has not negotiated management frame protection, or â€” receives an MLME-ASSOCIATE.indication or MLME-REASSOCIATE.indication primitive from a STA that has negotiated management frame protection that a) has resulted in an MLME (re)association response that is successful, and b) is not part of a fast BSS transition, or receives an MLME-DEAUTHENTICATE.indication or MLME-DISASSOCIATE.indication primitive or issues an MLME-DEAUTHENTICATE.request or MLME-DISASSOCIATE.request primitive, it deletes some security associations. In the case of an ESS, the non-AP STAâ€™s SME shall delete the PTKSA, GTKSA, IGTKSA, SMKSA, any TPKSA, and any STKSA, and the APâ€™s SME shall delete the PTKSA and invoke an STSL application teardown procedure for any of its STKSAs. An example of an STSL application teardown procedure is described in 11.7.4. In the case of an IBSS, the SME shall delete the PTKSA and the receive GTKSA and IGTKSA. Once the security associations have been deleted, the SME then invokes 2001 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MLME-DELETEKEYS.request primitive to delete all temporal keys associated with the deleted security associations. If a STA loses key state synchronization, it can apply the following rules to recover: a) Any protected frame(s) received shall be discarded, and MLME- PROTECTEDFRAMEDROPPED.indication primitive is invoked. b) If the STA is RSNA-enabled and has joined an IBSS, the SME shall execute the authentication procedure as described in 11.3.4.2. c) If the STA is RSNA-enabled and has joined an ESS, the SME shall execute the deauthentication procedures as described in 11.3.4.4. However, if the STA has initiated the RSN security association, but has not yet invoked the MLME-SETPROTECTION.request primitive, then no additional action is required. NOTE 1â€”There is a race condition between when MLME-SETPROTECTION.request primitive is invoked on the Supplicant and when it is invoked on the Authenticator. During this time, the STA might receive an MPDU that it is unable to decrypt; and the MPDU is discarded without a deauthentication occurring. NOTE 2â€”Because the IEEE 802.11 Null frame does not derive from an MA-UNITDATA.request primitive, it is not protected. If the selected AKMP fails between a STA and an AP that are associated, then both the STA and the AP shall invoke the MAC deauthentication procedure described in 11.3.4.4. If the SMK handshake fails between a pair of associated STAs and AP, then the STAs and the AP shall invoke an STSL application teardown procedure. When a STAâ€™s SME receives an MLME-PN-EXHAUSTION.indication primitive and the PN is associated with a PTKSA, the STAâ€™s SME shall invoke an MLME-DISASSOCIATE.request primitive and delete the PTKSA. When a STAâ€™s SME receives an MLME-PN-EXHAUSTION.indication primitive and the PN is associated with a GTKSA, the STAâ€™s SME shall delete the GTKSA. When a STAâ€™s SME receives an MLME-PN-EXHAUSTION.indication primitive and the PN is associated with a STKSA, the STAâ€™s SME shall invoke a STSL application teardown procedure for the STKSA and delete the STKSA. Once the security associations have been deleted, the SME then invokes MLME-DELETEKEYS.request primitive to delete all temporal keys associated with the deleted security associations. 12.6.19 Protection of robust Management frames This subclause defines rules that shall be followed by STAs that implement Management Frame protection and have dot11RSNAActivated equal to true. A STA with dot11RSNAProtectedManagementFramesActivated equal to false shall transmit and receive unprotected individually addressed robust Management frames to and from any associated STA and shall discard protected individually addressed robust Management frames received from any associated STA. A STA with dot11RSNAProtectedManagementFramesActivated equal to true and dot11RSNAUnprotectedManagementFramesAllowed equal to true shall transmit and receive unprotected individually addressed robust Management frames to and from any associated STA that advertised MFPC = 0 and shall discard protected individually addressed robust Management frames received from any associated STA that advertised MFPC = 0. 2002 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A STA with dot11RSNAProtectedManagementFramesActivated equal to true and dot11RSNAUnprotectedManagementFramesAllowed equal to true shall transmit and receive protected individually addressed robust Management frames to and from any associated STA that advertised MFPC = 1, shall discard unprotected individually addressed robust Action frames received from any STA that advertised MFPC = 1, and shall discard unprotected individually addressed Disassociation and Deauthentication frames received from a STA that advertised MFPC = 1 after the PTK and IGTK have been installed. The receiver shall process unprotected individually addressed Disassociation and Deauthentication frames before the PTK and IGTK are installed. A STA with dot11RSNAProtectedManagementFramesActivated equal to true and dot11RSNAUnprotectedManagementFramesAllowed equal to false shall transmit and receive protected individually addressed robust Action frames to and from any STA, shall not transmit unprotected individually addressed robust Action frames to any STA, and shall discard unprotected individually addressed robust Action frames received from a STA after the PTK and IGTK have been installed. The receiver shall process unprotected individually addressed Disassociation and Deauthentication frames before the PTK and IGTK are installed. A STA with dot11RSNAProtectedManagementFramesActivated equal to true shall protect transmitted group addressed robust Management frames using the group management cipher suite. A STA with dot11RSNAProtectedManagementFramesActivated equal to true shall discard group addressed robust Management frames received from any associated STA that advertised MFPC = 1 if the frames are unprotected or if a matching IGTK is not available. A STA with dot11RSNAProtectedManagementFramesActivated equal to true and dot11RSNAUnprotectedManagementFramesAllowed equal to false shall discard received group addressed robust Management frames that are unprotected or for which a matching IGTK is not available. A STA with dot11RSNAProtectedManagementFramesActivated equal to false shall transmit group addressed robust Management frames unprotected and shall ignore the protection on received group addressed robust Management frames. NOTEâ€”BIP does not provide protection against forgery by associated and authenticated STAs. A STA that has left the group can successfully forge Management frames until the IGTK is updated. Protection of group addressed robust Management frames shall be provided by a service in the MLME as described in 11.13. Robust management frame protection cannot be applied until the PTK and IGTK has been established with the STA. A STA shall not transmit robust Action frames until it has installed the PTK for the peer STA, or in the case of group addressed frames, has installed the IGTK. The STA shall discard any robust Action frames received before the PTK and IGTK are installed. 12.6.20 Robust management frame selection procedure A STA with dot11RSNAProtectedManagementFramesActivated equal to true shall negotiate robust management frame protection with a STA that advertised MFPC = 1. When a Public Action frame is transmitted for which a Protected Dual of Public Action frame is defined, (see 9.6.11), which variant (i.e., protected or not protected) is used depends on the setting of the â€œProtectedâ€ parameter of the corresponding MLME .request or .confirm primitive. Where there is no such parameter, the protected variant is used when management frame protection has been negotiated. 2003 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 12.6.21 RSNA rekeying When a PTKSA is deleted, a non-AP and non-PCP STA may reassociate with the same AP or PCP and/or establish a new RSNA with the AP or PCP. If the non-AP and non-PCP STA has cached one or more PMKSAs, it may skip the PMKSA establishment and proceed with the creation of a new PTKSA by using 4- way handshake. When a GTKSA is deleted, an originating STA may create a new GTKSA by using 4-way handshake or group key handshake. When a STKSA is deleted, the STA_I may establish a new STSL with the STA_P. If the SMK between the STA pair has not expired, the STA_I may initiate a 4-way handshake and create a new STKSA with STA_P. If the SMK has expired, the STA_I shall create both a new SMKSA and a new STKSA with the STA_P. An Authenticator/STA_I may initiate a 4-way handshake for the purpose of renewing the key associated with a PTKSA or STKSA. A supplicant/STA_P may send an EAPOL request message to the authenticator/ STA_I to request rekeying. In addition, if both the Authenticator and the Supplicant support multiple keys for individually addressed traffic, a smooth switchover to the new key is possible using the following procedure. The IEEE 802.11 MAC shall issue an MLME-PN-WARNING.indication primitive when the Packet Number assignment for a particular PTKSA, GTKSA, or STKSA reaches or exceeds the threshold that is defined in dot11PNWarningThresholdLow and dot11PNWarningThresholdHigh for the first time. The indication shall be issued only once for a given PTKSA, GTKSA, or STKSA. The SME may use the indication as a trigger to establish a new PTKSA, GTKSA, or STKSA before the Packet Number space is exhausted. A PTKSA or STKSA has a limited lifetime, either in absolute time or due to exhausting the PN space. To maintain an uninterrupted security association, a STA should establish a new PTKSA or STKSA prior to the expiration of the old PTKSA or STKSA. When both ends of the link support extended Key IDs for individually addressed frames, it is possible to install the new PTKSA or STKSA without data loss, provided the new PTKSA or STKSA uses a different Key ID from the old PTKSA or STKSA. Data loss might occur if the same Key ID is used because it is not possible to precisely coordinate (due to software processing delays) when the new key is used for transmit at one end and when it is applied to receive at the other end. If a different Key ID is used for the new PTKSA or STKSA, then provided the new key is installed at the receive side prior to its first use at the transmit side there is no need for precise coordination. During the transition, received packets are unambiguously identified using the Key ID as belonging to either the old or new PTKSA or STKSA. 12.6.22 Multi-band RSNA 12.6.22.1 General A STA is multi-band capable and RSNA-capable if the values of both dot11MultibandImplemented and dot11RSNAActivated are true. A STA that is multi-band capable and RSNA-capable shall set the Pairwise Cipher Suite Present field of the Multi-band element to 1 and shall include the Pairwise Cipher Suite Count field and the Pairwise Cipher Suite List field in the Multi-band element. The STA may include the RSNE and the Multi-band element in the DMG Beacon and Announce frames and shall include the RSNE and the Multi-band element in Beacon, Probe Response, and Information Response frames. The included RSNE shall specify all of the authentication and cipher suites enabled by the STAâ€™s policy for the band where this element is transmitted, and the included Multi-band element shall specify all of the pairwise cipher suites enabled by the STAâ€™s 2004 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications policy for the band specified within the Multi-band element. A STA shall not advertise any cipher suite that is not enabled. A multi-band capable and RSNA-capable STA shall include the Multi-band element in the (Re)Association Request frame and in message 2 and message 3 of the 4-way handshake. In order to set up an RSNA with a peer STA for a supported band/channel, a STA that does not know the peerâ€™s policy for the band/channel shall first obtain the peer STAâ€™s policy for the supported band/channel by using a Probe Request frame or Information Request frame. The STA initiating RSNA establishment for a supported band/channel is called RSNA initiator, and the targeted STA of the RSNA establishment is called RSNA responder. A multi-band capable device can create its own group key(s) for one or more supported bands/channels. If the STA uses different MAC addresses in different bands/channels, different GTKSAs shall be created for different bands. If the STA uses a same MAC address in all supported bands/channels, a single GTKSA shall be created for all supported bands/channels. If the pairwise and group cipher suites used by a pair of multi-band capable devices to communicate with each other in the current operating band/channel is also supported after the transfer to another band/channel that was performed using transparent FST, the devices shall continue using the same cipher suites to communicate with each other after the transfer. In all other cases, a separate RSNA has to be established for the other band/channel (see 12.6.22). 12.6.22.2 Nontransparent multi-band RSNA An RSNA initiator can establish a nontransparent (11.33) multi-band RSNA with an RSNA responder for a supported band/channel other than the current operating band/channel. The two STAs use the same PMKSA for both the supported band/channel and the current operating band/channel and create different PTKSAs for different bands/channels. If the RSNA initiator does not have an existing PMKSA with the RSNA responder, the RSNA initiator shall first establish a PMKSA with the RSNA responder in the current operating band/channel and then use the PMKSA to create a PTKSA with the RSNA responder for the supported band/channel. If the RSNA initiator has already established a PMKSA with the RSNA responder, the PMKSA shall be used to create a PTKSA between the two STAs for the supported band/channel. With the PMK in place, the RSNA initiator and RSNA responder can proceed in two ways depending on the setting of the Joint Multi-band RSNA subfield within the RSN Capabilities field in the RSNE of both STAs. If the Joint Multi-band RSNA subfield within the RSN Capabilities field of either the RSNA initiator or RSNA responder is 0, the STA pair uses a 4-way handshake to establish a PTKSA for the current band/ channel and may start a separate 4-way handshake in the current operating band/channel to negotiate a pairwise cipher suite for the supported band/channel and establish a PTKSA for the supported band/channel. As specified in 12.7.6, message 2 and message 3 of the 4-way handshake convey the Multi-band element associated with the supported band/channel. The Multi-band element in message 2 includes the selected pairwise cipher suite for the supported band/channel. message 3 includes the Multi-band element that the STA would send in a Beacon, DMG Beacon, Announce, Probe Response, or Information Response frame. message 3 may include a second Multi-band element that indicates the STAâ€™s pairwise cipher suite assignment for the supported band/channel. If the Joint Multi-band RSNA subfield within the RSN Capabilities field is 1 for both the RSNA initiator and the RSNA responder and at least one of the STAs uses different MAC addresses for different bands/ channels, the STAs shall use a single 4-way handshake to negotiate pairwise cipher suites and establish PTKSAs for both the current operating band/channel and the other supported band(s)/channel(s). As 2005 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications specified in 12.7.6, message 2 and message 3 of the 4-way handshake convey the RSNE and the Multi-band element(s). The RSNE in message 2 includes the selected pairwise cipher suite for the current operating band/channel, and the Multi-band element(s) in message 2 includes the selected pairwise cipher suite(s) for the other supported band(s)/channel(s). message 3 includes the RSNE and the Multi-band element(s) that the STA would send in a Beacon, DMG Beacon, Announce, Probe Response, or Information Response frame. message 3 may include a second RSNE and Multi-band element(s) that indicate the STAâ€™s pairwise cipher suite assignments for the current operating band/channel and the other supported band(s)/channel(s). KCK and KEK associated with the current operating band/channel shall be used in the 4-way handshake. 12.6.22.3 Transparent multi-band RSNA An RSNA initiator can establish a transparent (11.33) multi-band RSNA with an RSNA responder for both the current operating band/channel and the other supported band(s)/channel(s) if a) Both STAs use the same MAC address in the current operating band/channel and the other supported band(s)/channel(s); and b) At least one common pairwise cipher suite is supported by both STAs in the current operating band/ channel and the other supported band(s)/channel(s). Two STAs that establish a transparent multi-band RSNA create one PMKSA and one PTKSA for both the current operating band/channel and other supported band(s)/channel. A STA shall use a single PN counter (12.5.3.3 and 12.5.5.3) for transmission in both the current operating band and the other supported band(s) when transparent multi-band RSNA is used. If the RSNA initiator does not have an existing PMKSA with the RSNA responder, the RSNA initiator shall first establish a PMKSA with the RSNA responder in the current operating band/channel and then use the PMKSA to create a PTKSA with the RSNA responder for all involved bands/channels. If the RSNA initiator has already established a PMKSA with the RSNA responder, the PMKSA shall be used to create a PTKSA between the two STAs for all involved bands/channels. With the PMK in place, the STA pair shall use a single 4-way handshake in the current operating band/ channel to negotiate a pairwise cipher suite for all involved bands/channels and also establish a single PTKSA for all involved bands/channels. As specified in 12.7.6, message 2 and message 3 of the 4-way handshake convey the RSNE and the Multi-band element(s). The RSNE and the Multi-band element(s) in message 2 include one selected pairwise cipher suite for all involved bands/channels. message 3 includes the RSNE and the Multi-band element(s) that the STA would send in a Beacon, DMG Beacon, Announce, Probe Response, or Information Response frame. message 3 may include a second RSNE and Multi-band element(s) that indicate the STAâ€™s pairwise cipher suite assignment for all involved bands/channels. 12.6.22.4 Multi-band RSNA with TDLS in a non-DMG BSS When two multi-band capable devices operate in a non-DMG BSS and set up a TDLS direct link in the BSS, the TPK handshake protocol can be used to create a PTKSA for use in another supported band/channel that is supported by both STAs and that was indicated in the Multi-band element in each of the STAs. Only TK in PTKSA is required for the supported band/channel and it shall be equal to the TPK-TK of the TPK. If at least one of the peer STAs has a different MAC address in the supported band/channel from that of the current operating band/channel, the TPK handshake protocol may be used to establish a PTKSA for the supported band/channel. In this case, the TPK creation method shall be used to calculate a different PTKSA in the supported band/channel: the TDLS peer MAC addresses and cipher suite shall be replaced by the MAC addresses and cipher suite indicated within the corresponding Multi-band elements contained in the TDLS Setup Request and TDLS Setup Response frames used to establish the PTKSA for the supported band/channel. 2006 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If two TDLS peer STAs use the same MAC addresses and pairwise cipher suites in the operating band/ channel and in the supported band/channel, the TPKSA that is acquired by the successful completion of the TPK handshake protocol may be used as the PTKSA for the supported band/channel. 12.7 Keys and key distribution 12.7.1 Key hierarchy 12.7.1.1 General RSNA defines the following key hierarchies: a) Pairwise key hierarchy, to protect individually addressed traffic b) GTK, a hierarchy consisting of a single key to protect group addressed traffic NOTEâ€”Pairwise key support with enhanced data cryptographic encapsulation mechanisms allows a receiving STA to detect MAC address spoofing and data forgery. The RSNA architecture binds the transmit and receive addresses to the pairwise key. If an attacker creates an MPDU with the spoofed TA, then the decapsulation procedure at the receiver generates an error. GTKs do not have this property. c) Integrity GTK (IGTK), a hierarchy consisting of a single key to provide integrity protection for group addressed robust Management frames The description of the key hierarchies uses the pseudorandom function producing n bits of output, PRF-n, defined in 12.7.1.2. In an infrastructure BSS, the IEEE 802.1X Authenticator MAC address (AA) and the APâ€™s MAC address are the same, and the Supplicantâ€™s MAC address (SPA) and the STAâ€™s MAC address are equal. For the purposes of comparison, the MAC address is encoded as 6 octets, taken to represent an unsigned integer. The first octet of the MAC address shall be used as the most significant octet. The bit numbering conventions in 9.2.2 shall be used within each octet. This results in a 48-bit unsigned integer labeled B0 (least significant) to B47 (most significant), where the I/G bit is in B40. An RSNA STA shall support at least one pairwise key for any pair for use with enhanced data cryptographic encapsulation mechanisms. The identifies the pairwise key, which does not correspond to any WEP key identifier. In a a mixed environment, an AP may simultaneously communicate with some STAs using WEP with shared WEP keys and to STAs using enhanced data cryptographic encapsulation mechanisms with pairwise keys. The STAs running WEP use default keys 0â€“3 for shared WEP keys; the important point here is that WEP can still use WEP default key 0. The AP might be configured to use the WEP key in WEP default key 0 for WEP; if the AP is configured in this way, STAs that cannot support WEP default key 0 simultaneously with a TKIP pairwise key shall specify the No Pairwise subfield in the RSN Capabilities field. If an AP is configured to use WEP default key 0 as a WEP key and a â€œNo Pairwiseâ€ STA associates, the AP shall not set the Install bit in the 4-way handshake. In other words, the STA does not install a pairwise temporal key and instead uses WEP default key 0 for all traffic. NOTEâ€”The behavior of â€œNo Pairwiseâ€ STAs is intended only to support the migration of WEP to RSNA. TKIP STAs in a mixed environment are expected to support a single pairwise key either by using a key mapping key or by mapping to default key 0. The AP uses a pairwise key for individually addressed traffic between the AP and the STA. If a key mapping key is available, the pair identifies the key; if there is no key mapping key, then the default key 0 is used because the key index in the message is 0. 2007 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A STA that cannot support TKIP keys and WEP default key 0 simultaneously advertises this deficiency by setting the No Pairwise subfield in the RSNE it sends in the (Re)Association Request frame to the AP. In response, the AP sets the Install bit to 0 in message 3 of the 4-way handshake to notify the STA not to install the pairwise key. The AP instead sends the WEP shared key to the STA to be plumbed as the WEP default key 0; this key is then used with WEP to send and receive individually addressed traffic between the AP and the STA. The TKIP STA that has this limitation might not know that it will be forced to use WEP for all transmissions until it has associated with the AP and been given the keys to use. (The STA cannot know that the AP has been configured to use WEP default key 0 for WEP communication.) If this does not satisfy the security policy configured at the STA, the STAâ€™s only recourse is to disassociate and try a different AP. STAs using enhanced data cryptographic encapsulation mechanisms in a TSN shall support pairwise keys and WEP default key 0 simultaneously. It is invalid for the STA to negotiate the No Pairwise subfield when an enhanced data cryptographic encapsulation mechanism other than TKIP is one of the configured ciphers. 12.7.1.2 PRF A PRF is used in a number of places in this standard. Depending on its use, it may need to output 128, 192, 256, 384, 512, or 704 bits. This subclause defines six functions: â€” PRF-128, which outputs 128 bits â€” PRF-192, which outputs 192 bits â€” PRF-256, which outputs 256 bits â€” PRF-384, which outputs 384 bits â€” PRF-512, which outputs 512 bits â€” PRF-704, which outputs 704 bits In the following, K is a key; A is a unique label for each different purpose of the PRF, treated as an ASCII string; B is a variable-length string; Y is a single octet containing 0; X is a single octet containing the loop parameter i: H-SHA-1(K, A, B, X) HMAC-SHA-1(K, A || Y || B || X) PRF(K, A, B, Len) for i 0 to Len --------- do 160 R R || H-SHA-1(K, A, B, i) return L(R, 0, Len) PRF-128(K, A, B) = PRF(K, A, B, 128) PRF-192(K, A, B) = PRF(K, A, B, 192) PRF-256(K, A, B) = PRF(K, A, B, 256) PRF-384(K, A, B) = PRF(K, A, B, 384) PRF-512(K, A, B) = PRF(K, A, B, 512) When the negotiated AKM is 00-0F-AC:5, 00-0F-AC:6, or 00-0F-AC:11, the KDF specified in 12.7.1.7.2 shall be used instead of the PRF construction defined here. In this case, A is used as the KDF label and B as the KDF Context, and the PRF functions are defined as follows: PRF-128(K, A, B) = KDF-SHA-256-128(K, A, B) PRF-192(K, A, B) = KDF-SHA-256-192(K, A, B) 2008 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications PRF-256(K, A, B) = KDF-SHA-256-256(K, A, B) PRF-384(K, A, B) = KDF-SHA-256-384(K, A, B) PRF-512(K, A, B) = KDF-SHA-256-512(K, A, B) When the negotiated AKM is 00-0F-AC:12, the KDF specified in 12.7.1.7.2 shall be used instead of the PRF construction defined here. In this case, A is used as the KDF label and B as the KDF Context, and the PRF function is defined as follows: PRF-704(K, A, B) = KDF-SHA-384-704(K, A, B) When the negotiated AKM is 00-0F-AC:13, the KDF specified in 12.7.1.7.2 shall be used instead of the PRF construction defined here. In this case, A is used as the KDF label and B as the KDF Context, and the PRF functions are defined as follows: PRF-384(K, A, B) = KDF-SHA-384-384(K, A, B) PRF-512(K, A, B) = KDF-SHA-384-512(K, A, B) PRF-704(K, A, B) = KDF-SHA-384-704(K, A, B) 12.7.1.3 Pairwise key hierarchy Except when preauthentication is used, the pairwise key hierarchy utilizes PRF-384, PRF-512, or PRF-704 to derive session-specific keys from a PMK, as depicted in Figure 12-28. When using AKM suite selector 00-0F-AC:12, the length of the PMK, PMK_bits, shall be 384 bits. With all other AKM suite selectors, the length of the PMK, PMK_bits, shall be 256 bits. The pairwise key hierarchy takes a PMK and generates a PTK. The PTK is partitioned into KCK, KEK, and a temporal key, which is used by the MAC to protect individually addressed communication between the Authenticatorâ€™s and Supplicantâ€™s respective STAs. PTKs are used between a single Supplicant and a single Authenticator. Pairwise Master Master KeyKey (PMK) (PMK) PRF-Length(PMK, â€œPairwise key expansionâ€ , Min(AA,S P A) || Max(AA,SP Max(AA,SPA) || Min(ANonce ,SNonce ) || Max(ANonce ,SNonce)) Pairwise Transient Transient KeyKey (PTK) (PTK) (Length bits) EAPOL- Key EAPOL- Key Temporal Key Key Key Encryption L(PTK,KCK_bits+KEK_bits,TK_bits) Confirmation Key (TK) Key L(PTK,KCK_bits, L(PTK,128,128) L(PTK,0,KCK_bits) L(PTK,0,128) KEK_bits) (KCK) (KEK) (KEK) Figure 12-28â€”Pairwise key hierarchy When not using a PSK, the PMK is derived from the MSK. The PMK shall be computed as the first PMK_bits bits (bits 0 to PMK_bitsâ€“1) of the MSK: PMK L(MSK, 0, PMK_bits). 2009 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The PTK shall not be used longer than the PMK lifetime as determined by the minimum of the PMK lifetime indicated by the AS, e.g., Session-Timeout + dot1xAuthTxPeriod or from dot11RSNAConfigPMK- Lifetime. When RADIUS is used and the Session-Timeout attribute is not in the RADIUS Accept message, and if the key lifetime is not otherwise specified, then the PMK lifetime is infinite. NOTE 1â€”If the protocol between the Authenticator (or AP) and AS is RADIUS, then the MS-MPPE-Recv-Key attribute (vendor-id = 17; see Section 2.4.3 in IETF RFC 2548 [B32]) is available to be used to transport the first 32 octets of the MSK to the AP, and the MS-MPPE-Send-Key attribute (vendor-id = 16; see Section 2.4.2 in IETF RFC 2548 [B32]) is available to be used to transport the remaining 32 octets of the MSK. NOTE 2â€”When reauthenticating and changing the pairwise key, a race condition might occur when using TKIP. If a frame is received while MLME-SETKEYS.request primitive is being processed, the received frame might be decrypted with one key and the MIC checked with a different key. Two possible options to avoid this race condition are as follows: the frame might be checked against the old MIC key, and the received frames might be queued while the keys are changed. NOTE 3â€”If the AKMP is RSNA-PSK, then a 256-bit PSK might be configured into the STA and AP or a pass-phrase might be configured into the Supplicant or Authenticator. The method used to configure the PSK is outside this standard, but one method is via user interaction. If a pass-phrase is configured, then a 256-bit key is derived and used as the PSK. In any RSNA-PSK method, the PSK is used directly as the PMK. Implementations might support different PSKs for each pair of communicating STAs. Here, the following assumptions apply: â€” SNonce is a random or pseudorandom value contributed by the Supplicant; its value is taken when a PTK is instantiated and is sent to the PTK Authenticator. â€” ANonce is a random or pseudorandom value contributed by the Authenticator. â€” The PTK shall be derived from the PMK by PTK = PRF-Length(PMK, â€œPairwise key expansionâ€, Min(AA,SPA) || Max(AA,SPA) || Min(ANonce,SNonce) || Max(ANonce,SNonce)) where Length = KCK_bits + KEK_bits + TK_bits. The values of KCK_bits and KEK_bits are AKM suite dependent and are listed in Table 12-8. The value of TK_bits is cipher-suite dependent and is defined in Table 12-4. The Min and Max operations for IEEE 802 addresses are with the address converted to a positive integer treating the first transmitted octet as the most significant octet of the integer. The nonces are encoded as specified in 9.2.2. NOTEâ€”The Authenticator and Supplicant normally derive a PTK only once per association. A Supplicant or an Authenticator use the 4-way handshake to derive a new PTK. Both the Authenticator and Supplicant create a new nonce value for each 4-way handshake instance. â€” The KCK shall be computed as the first KCK_bits bits (bits 0 to KCK_bitsâ€“1) of the PTK: KCK= L(PTK, 0, KCK_bits) The KCK is used by IEEE Std 802.1X-2010 to provided data origin authenticity in the 4-way handshake and group key handshake messages. â€” The KEK shall be computed as the next KEK_bits bits of the PTK: KEK = L(PTK, KCK_bits, KEK_bits) The KEK is used by the EAPOL-Key frames to provide data confidentiality in the 4-way handshake and group key handshake messages. â€” The temporal key (TK) shall be computed as the next TK_bits bits of the PTK: TK = L(PTK, KCK_bits+KEK_bits, TK_bits) The EAPOL-Key state machines (see 12.7.10 and 12.7.11) use the MLME-SETKEYS.request primitive to configure the temporal key into the STA. The STA uses the temporal key with the pairwise cipher suite; interpretation of this value is cipher-suite-specific. 2010 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications When the negotiated AKM is 00-0F-AC:5 or 00-0F-AC:6, the PMK identifier is defined as PMKID = Truncate-128(HMAC-SHA-256(PMK, "PMK Name" || AA || SPA)) When the negotiated AKM is 00-0F-AC:11, the PMK identifier is defined as PMKID = Truncate-128(HMAC-SHA-256(KCK, "PMK Name" || AA || SPA)) When the negotiated AKM is 00-0F-AC:12, and the PMK identifier is defined as PMKID = Truncate-128(HMAC-SHA-384(KCK, "PMK Name" || AA || SPA)) Otherwise, the PMK identifier is defined as PMKID = Truncate-128(HMAC-SHA-1(PMK, "PMK Name" || AA || SPA)) In all these cases, â€œPMK Nameâ€ is treated as an ASCII string. When the PMKID is calculated for the PMKSA as part of preauthentication, the AKM has not yet been negotiated. In this case, the HMAC-SHA-1 based derivation is used for the PMKID calculation. 12.7.1.4 Group key hierarchy The group temporal key (GTK) shall be a random number. The following is an example method for deriving a random GTK. Any other pseudorandom function, such as that specified in 12.7.1.2, could also be used. A group master key (GMK) is an auxiliary key that may be used to derive a GTK at a time interval configured into the AP to reduce the exposure of data if the GMK is ever compromised. The Authenticator might update the GTK for a number of reasons: â€” The Authenticator might change the GTK on disassociation or deauthentication of a STA. â€” An event within the SME might trigger a group key handshake. Figure 12-29 depicts an example of a relationship among the keys of the group key hierarchy. In this model, the group key hierarchy takes a GMK and generates a GTK. The GTK is a temporal key, which is used to protect group addressed communication. GTKs are used between a single Authenticator and all Supplicants authenticated to that Authenticator. The Authenticator derives new GTKs when it needs to update the GTKs. In this example, the following assumptions apply: a) Group nonce (GNonce) is a random or pseudorandom value contributed by the IEEE 802.1X Authenticator. b) The GTK is derived from the GMK by c) GTK PRF-Length(GMK, â€œGroup key expansionâ€, AA || GNonce) d) Length = TK_bits. The value of TK_bits is cipher-suite dependent and is defined in Table 12-4. AA is represented as an IEEE 802 address and GNonce as a bit string as defined in 9.2.2. e) The temporal key (TK) is bits 0 to (TK_bits â€“ 1) of the GTK: TK L(GTK, 0, TK_bits) f) The EAPOL-Key state machines (see 12.7.10 and 12.7.11) configure the temporal key into a STA via the MLME-SETKEYS.request primitive. Its interpretation is cipher-suite-specific. 2011 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Group Master Key (GMK) PRF-Length (GMK ,â€œGroup key expansionâ€,, AA || GNonce ) Group Temporal Key (GTK) (Length bits ) Temporal Key Temporal Key L(GTK, 0, TK_bits) CCMP: L(GTK, 0, 128) Figure 12-29â€”Group key hierarchy (informative) 12.7.1.5 Integrity group key hierarchy The Authenticator shall select the IGTK as a random value each time it is generated. The Authenticator may update the IGTK for any reason, including: a) The disassociation or deauthentication of a STA. b) An event within the SME that triggers a group key handshake. The IGTK is configured via the MLME-SETKEYS.request primitive; see 6.3.19. IGTK configuration is described in the EAPOL-Key state machines; see 12.7.10 and 12.7.11. The IPN is used to provide replay protection. 12.7.1.6 PeerKey key hierarchy The station-to-station key hierarchy utilizes PRF-384 or PRF-512 to derive session-specific keys from an SMK, as depicted in Figure 12-30. The SMK shall be 256 bits. The pairwise key hierarchy takes an SMK and generates an STK. The STK is partitioned into SKCK, SKEK, and a temporal key, which is used by the MAC to protect individually addressed communication between the initiator and peer STAs. STKs are used between a single initiator STA and a single peer STA. 2012 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STSL Master Key (SMK) PRF-Length(SMK, â€œPeer key expansionâ€, Min(MAC_I,MAC_P) || Max(MAC_I,MAC_P) Min(INonce,PNonce) || Max(INonce,PNonce)) STSL Transient Key (STK) (Length bits) EAPOL-Key Key EAPOL-Key Key Temporal Key Confirmation Key Encryption Key L(STK, 256, TK_bits) L(STK, 0, 128) L(STK, 128, 128) (TK) SKCK SKEK Figure 12-30â€”PeerKey hierarchy The following apply and are depicted in Figure 12-30: a) INonce is a random or pseudorandom value contributed by the initiator STA. b) PNonce is a random or pseudorandom value contributed by the peer STA. c) The STK shall be derived from the SMK by STK PRF-Length(SMK, "Peer key expansion", Min(MAC_I,MAC_P) || Max(MAC_I,MAC_P) || Min(INonce,PNonce) || Max(INonce,PNonce)) where Length = 256 + TK_bits. The value of TK_bits is cipher-suite dependent and is defined in Table 12-4. The Min and Max operations for IEEE 802 addresses are with the address converted to a positive integer treating the first transmitted octet as the most significant octet of the integer. For the Min and Max operations, nonces are encoded as specified in 9.2.2. d) The SKCK shall be computed as the first 128 bits (bits 0â€“127) of the STK: SKCK L(STK, 0, 128) The SKCK is used to provide data origin authenticity in the 4-way STK handshake. e) The SKEK shall be computed as bits 128â€“255 of the STK: SKEK L(STK, 128, 128) The SKEK is used by the EAPOL-Key frames to provide confidentiality in the 4-way STK handshake. f) The temporal key (TK) shall be computed as bits 256 to (255 + TK_bits) of the STK: TK L(STK, 256, TK_bits) The EAPOL-Key state machines (see 12.7.10 and 12.7.11) use the MLME-SETKEYS.request primitive to configure the temporal key into the STA. The STA uses the temporal key with the pairwise cipher suite; interpretation of this value is cipher-suite-specific. 2013 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications When the negotiated AKM is 00-0F-AC:5 or 00-0F-AC:6, the SMK identifier is defined as SMKID = Truncate-128(HMAC-SHA-256(SMK, "SMK Name" || PNonce || MAC_P || INonce || MAC_I)) Otherwise, the SMK identifier is defined as SMKID = Truncate-128(HMAC-SHA-1(SMK, "SMK Name" || PNonce || MAC_P || INonce || MAC_I)) In both these cases, â€œSMK Nameâ€ is treated as an ASCII string. 12.7.1.7 FT key hierarchy 12.7.1.7.1 Overview This subclause describes the FT key hierarchy and its supporting architecture. The FT key hierarchy is designed to allow a STA to make fast BSS transitions between APs without the need to perform an SAE or IEEE 802.1X authentication at every AP within the mobility domain. The FT key hierarchy can be used with SAE, IEEE 802.1X authentication, or PSK authentication. A three-level key hierarchy provides key separation between the key holders. The FT key hierarchy for the Authenticator is shown in Figure 12-31. An identical key hierarchy exists for the Supplicant, and identical functions are performed by the corresponding S0KH and S1KH. The FT key hierarchy shown in Figure 12-31 consists of three levels whose keys are derived using the key derivation function (KDF) described in 12.7.1.7.2 as follows: a) PMK-R0 â€“ the first-level key of the FT key hierarchy. This key is derived as a function of the master session key (MSK) or PSK. It is stored by the PMK-R0 key holders, R0KH and S0KH. b) PMK-R1 â€“ the second-level key of the FT key hierarchy. This key is mutually derived by the S0KH and R0KH. c) PTK â€“ the third-level key of the FT key hierarchy that defines the IEEE 802.11 and IEEE 802.1X protection keys. The PTK is mutually derived by the PMK-R1 key holders, R1KH and S1KH. As shown in Figure 12-31, the R0KH computes the PMK-R0 from the key obtained from SAE authentication (for the purposes of FT this key is identified as the Master PMK, or MPMK), from the PSK, or from the MSK resulting (per IETF RFC 3748 [B42]) from a successful IEEE 802.1X authentication between the AS and the Supplicant. Upon a successful authentication, the R0KH shall delete any prior PMK-R0 security association for this mobility domain pertaining to this S0KH. The R0KH shall also delete all PMK-R1 security associations derived from that prior PMK-R0 security association. The PMK-R1s are generated by the R0KH and are assumed to be delivered from the R0KH to the R1KHs within the same mobility domain. The PMK-R1s are used for PTK generation. Upon receiving a new PMK-R1 for an S0KH, an R1KH deletes the prior PMK-R1 security association and PTKSAs derived from the prior PMK-R1. It is assumed by this standard that the PSK is specific to a single S0KH and a single R0KH. The lifetime of the PMK-R0, PMK-R1, and PTK are bound to the lifetime of the MPMK, PSK, or MSK from which it was derived. For example, the AS may communicate the MSK lifetime with the MSK. If such an attribute is provided, the lifetime of the PMK-R0 shall be not more than the lifetime of the MSK. The lifetime of the PTK and PMK-R1 is the same as that of the PMK-R0. When the key lifetime expires, each key holder shall delete its respective PMK-R0, PMK-R1 or PTKSA. The FT key hierarchy derives its keys using the KDF defined in 12.7.1.7.2 with separate labels to further distinguish derivations. 2014 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Authentication Server SAE Authentication (IEEE 802.1X Authentication only) MSK PSK MPMK R0 Key Holder (R0KH) R0KH-ID Derives PMK-R0 Derives PMK-R1s PMK-R1A PMK-R1B R1 Key Holder (R1KH) R1 Key Holder (R1KH) R1KH-IDA R1KH-IDB Derives PTKA Derives PTKB PTK Key Holder PTK Key Holder BSSIDA BSSIDB Figure 12-31â€”FT key hierarchy at an Authenticator During a fast BSS transition, a STA shall negotiate the same pairwise cipher suite with target APs as was negotiated in the FT initial mobility domain association. Using the pairwise cipher suite selector value in the PMK-R1 security association received from the R0KH, the target AP shall verify that the same pairwise cipher suite selector is being used. The distribution of keys from the R0KH to the R1KHs is outside the scope of this standard. It is assumed that the PMK-R1s are distributed from the R0KH to the R1KHs following the requirements specified in 13.2.2. The PMK-R0 may be deleted by the R0KH after PMK-R1s have been derived. When the PMK-R0 is deleted, the R0KH needs only to maintain the PMK-R1 security associations. 12.7.1.7.2 Key derivation function (KDF) The KDF is a variant of the pseudorandom function (PRF) defined in 12.7.1.2 and is defined as follows: Output KDF-Hash-Length (K, Label, Context) where Input: K, a derivation key whose length equals the block size of the hash function Hash, a cryptographically strong hash function Label, a string identifying the purpose of the keys derived using this KDF, treated as an ASCII string Context, a bit string that provides context to identify the derived key Length, the length of the derived key in bits Output: a Length-bit derived key 2015 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications result "" iterations Length Hashlen do i = 1 to iterations result result || HMAC-Hash(K, i || Label || Context || Length) od return first Length bits of result, and irretrievably delete the other bits where i and Length are encoded as 16-bit unsigned integers, represented using the bit ordering conventions of 9.2.2 K, Label, and Context are bit strings and are represented using the ordering conventions of 9.2.2 Hashlen is the length, in bits, of the digest produced by Hash 12.7.1.7.3 PMK-R0 The first-level key in the FT key hierarchy, PMK-R0, is derived using the KDF defined in 12.7.1.7.2. The PMK-R0 is the first level keying material used to derive the next level keys (PMK-R1s): R0-Key-Data = KDF-Hash-Length(XXKey, "FT-R0", SSIDlength || SSID || MDID || R0KHlength || R0KH-ID || S0KH-ID) PMK-R0 = L(R0-Key-Data, 0, Q) PMK-R0Name-Salt = L(R0-Key-Data, Q, 128) Length = Q + 128 where â€” KDF-Hash-Length is the KDF as defined in 12.7.1.7.2 using the hash algorithm identified by the AKM suite selector (see Table 9-133). â€” If the AKM negotiated is 00-0F-AC:3, then Q shall be 256, and XXKey shall be the second 256 bits of the MSK (which is derived from the IEEE 802.1X authentication), i.e., XXKey = L(MSK, 256, 256). If the AKM negotiated is 00-0F-AC:4, then Q shall be 256, and XXKey shall be the PSK. If the AKM negotiated is 00-0F-AC:9, then Q shall be 256, and XXKey shall be the MPMK generated as the result of SAE authentication. If the AKM negotiated is 00-0F-AC:13, then Q shall be 384, and XXKey shall be the first 384 bits of the MSK (which is derived from the IEEE 802.1X authentication), i.e., XXKey = L(MSK, 0, 384). â€” SSIDlength is a single octet whose value is the number of octets in the SSID. â€” SSID is the service set identifier, a variable-length sequence of octets, as it appears in the Beacon and Probe Response frames. â€” MDID is the Mobility Domain Identifier field from the Mobile Domain element (MDE) that was used during FT initial mobility domain association. â€” R0KHlength is a single octet whose value is the number of octets in the R0KH-ID. â€” R0KH-ID is the identifier of the holder of PMK-R0 in the Authenticator. â€” S0KH-ID is the Supplicantâ€™s MAC address (SPA). The PMK-R0 is referenced and named as follows: PMKR0Name = Truncate-128(SHA-256("FT-R0N" || PMK-R0Name-Salt)) where â€” "FT-R0N" is treated as an ASCII string. 2016 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The PMKR0Name is used to identify the PMK-R0. 12.7.1.7.4 PMK-R1 The second-level key in the FT key hierarchy, PMK-R1, is a key used to derive the PTK. The PMK-R1 is derived using the KDF defined in 12.7.1.7.2: PMK-R1 = KDF-Hash-Length(PMK-R0, "FT-R1", R1KH-ID || S1KH-ID) where â€” KDF-Hash-Length is the KDF as defined in 12.7.1.7.2 using the hash algorithm identified by the AKM suite selector (see Table 9-133) to generate a key whose length is equal to the length of the hash algorithmâ€™s digest. â€” PMK-R0 is the first level key in the FT key hierarchy. â€” R1KH-ID is a MAC address of the holder of the PMK-R1 in the Authenticator of the AP. â€” S1KH-ID is the SPA. The PMK-R1 is referenced and named as follows: PMKR1Name = Truncate-128(SHA-256(â€œFT-R1Nâ€ || PMKR0Name || R1KH-ID || S1KH-ID)) where â€” "FT-R1N" is treated as an ASCII string. PMKR1Name is used to identify the PMK-R1. 12.7.1.7.5 PTK The third-level key in the FT key hierarchy is the PTK. This key is mutually derived by the S1KH and the R1KH used by the target AP, with the key length being a function of the negotiated cipher suite as defined by Table 12-4 in 12.7.2. Using the KDF defined in 12.7.1.7.2, the PTK derivation is as follows: PTK = KDF-Hash-Length(PMK-R1, "FT-PTK", SNonce || ANonce || BSSID || STA-ADDR) where â€” KDF-Hash-Length is the KDF as defined in 12.7.1.7.2 using the hash algorithm identified by the AKM suite selector (see Table 9-133). â€” PMK-R1 is the key that is shared between the S1KH and the R1KH. â€” SNonce is a 256-bit random bit string contributed by the S1KH. â€” ANonce is a 256-bit random bit string contributed by the R1KH. â€” STA-ADDR is the non-AP STAâ€™s MAC address. â€” BSSID is the BSSID of the target AP. â€” Length is the total number of bits to derive, i.e., number of bits of the PTK. The length is dependent on the negotiated cipher suites and AKM suites as defined by Table 12-4 in 12.7.2 and Table 12-8 in 12.7.3. 2017 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Each PTK has three component keys, KCK, KEK, and a temporal key, derived as follows: The KCK shall be computed as the first KCK_bits bits (bits 0 to KCK_bitsâ€“1) of the PTK: KCK = L(PTK, 0, KCK_bits). The KCK is used to provide data origin authenticity in EAPOL-Key frames, as defined in 12.7.2, and in the FT authentication sequence, as defined in 13.8. The KEK shall be computed as the next KEK_bits of the PTK: KEK = L(PTK, KCK_bits, KEK_bits) The KEK is used to provide data confidentiality for certain fields (KeyData) in EAPOL-Key frames, as defined in 12.7.2, and in the FT authentication sequence, as defined in 13.8. The temporal key (TK) shall be computed as the next TK_bits (see Table 12-4) bits of the PTK: TK = L(PTK, KCK_bits+KEK_bits, TK_bits) For vendor-specific cipher suites, the length of the temporal key (and the value of Length) depend on the vendor-specific algorithm. The temporal key is configured into the STA by the SME through the use of the MLME-SETKEYS.request primitive. The STA uses the temporal key with the pairwise cipher suite; interpretation of this value is specific to the cipher suite. The PTK is referenced and named as follows: PTKName = Truncate-128(SHA-256(PMKR1Name || â€œFT-PTKNâ€ || SNonce || ANonce || BSSID || STA-ADDR)) where â€” "FT-PTKN" is treated as an ASCII string. The PTKName is used to identify the PTK. 12.7.2 EAPOL-Key frames IEEE Std 802.11 uses EAPOL-Key frames to exchange information between STAsâ€™ Supplicants and Authenticators. These exchanges result in cryptographic keys and synchronization of security association state. EAPOL-Key frames are used to implement three different exchanges: â€” 4-way handshake, to confirm that the PMK between associated STAs is the same and live and to transfer the GTK to the STA. â€” Group key handshake, to update the GTK at the STA. â€” PeerKey initial SMK handshake to deliver the SMK and final 4-way STK handshake to deliver the STK to the initiating and peer STAs. When priority processing of Data frames is supported, an SME should send EAPOL-Key frames at the highest priority. 2018 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The RSNA key descriptor used by IEEE Std 802.11 maps to the IEEE 802.1X Key Descriptor as described in this subclause. The bit and octet convention for fields in the EAPOL-Key frame are defined in 11.2 of IEEE Std 802.1X- 2010. EAPOL-Key frames containing invalid field values shall be silently discarded. Figure 12-32 depicts the format of an EAPOL-Key frame. Protocol Packet Type Packet Body Length Version â€“ 1 octet â€“ 2 octets â€“ 1 octet Descriptor Type â€“ 1 octet Key Information â€“ 2 Key Length â€“ 2 octets octets Key Replay Counter â€“ 8 octets Key Nonce â€“ 32 octets EAPOL - Key IV â€“ 16 octets Key RSC â€“ 8 octets Reserved - 8 octets Key MIC â€“ variable Key Data Length â€“ 2 Key Data â€“ n octets octets Figure 12-32â€”EAPOL-Key frame The fields of an EAPOL-Key frame body are as follows: a) Descriptor Type. This field is 1 octet and has a value defined by IEEE Std 802.1X-2010, identifying the IEEE 802.11 key descriptor. b) Key Information. This field is 2 octets and specifies characteristics of the key. See Figure 12-33. B0 B2 B3 B4 B5 B6 B7 B8 B9 B10 B11 B12 B13 B14 B15 Key Key Reserved Install Key Key Se- Error Request Encrypted SMK Reserved Descriptor Type Ack MIC cure Key Data Message Version Figure 12-33â€”Key Information bit layout The bit convention used is as in 11.2 of IEEE Std 802.1X-2010. The subfields of the Key Information field are as follows: 1) Key Descriptor Version (bits 0â€“2) shall be set to 0 on all transmitted EAPOL-Key frames except under the following circumstances: i) The value 1 shall be used for all EAPOL-Key frames to a STA when the negotiated AKM is 00-0F-AC:1 or 00-0F-AC:2 and the pairwise cipher is TKIP or "Use group cipher suite" for Key Descriptor 1. This value indicates the following: â€” HMAC-MD5 is the EAPOL-Key MIC. â€” ARC4 is the EAPOL-Key encryption algorithm used to protect the Key Data field. â€” The MIC is 16 octets. ii) The value 2 shall be used for all EAPOL-Key frames to a STA when the negotiated AKM is 00-0F-AC:1 or 00-0F-AC:2 and either the pairwise or the group cipher is an enhanced 2019 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications data cryptographic encapsulation mechanism other than TKIP for Key Descriptor 2. This value indicates the following: â€” HMAC-SHA-1-128 is the EAPOL-Key MIC. HMAC is defined in IETF RFC 2104; and SHA-1, by FIPS PUB 180-4. The output of the HMAC-SHA-1 shall be truncated to its 128 MSBs (octets 0â€“15 of the digest output by HMAC-SHA-1), i.e., the last four octets generated shall be irretrievably deleted). â€” The NIST AES key wrap is the EAPOL-Key encryption algorithm used to protect the Key Data field. IETF RFC 3394 defines the NIST AES key wrap algorithm. â€” The MIC is 16 octets. iii) The value 3 shall be used for all EAPOL-Key frames to a STA when the negotiated AKM is 00-0F-AC:3, 00-0F-AC:4, 00-0F-AC:5, or 00-0F-AC:6. This value indicates the follow- ing: â€” AES-128-CMAC is the EAPOL-Key MIC. AES-128-CMAC is defined by NIST Special Publication 800-38B and also found in IETF RFC 4493. The output of the AES-128-CMAC shall be 128 bits. â€” The NIST AES key wrap is the EAPOL-Key encryption algorithm used to protect the Key Data field. IETF RFC 3394 defines the NIST AES key wrap algorithm. â€” The MIC is 16 octets. 2) Key Type (bit 3) specifies whether this EAPOL-Key frame is part of a 4-way handshake deriving a PTK. i) The value 0 (Group/SMK) indicates the message is not part of a PTK derivation. ii) The value 1 (Pairwise) indicates the message is part of a PTK derivation. 3) Reserved (bits 4â€“5). 4) Install (bit 6). i) If the value of Key Type (bit 3) is 1, then for the Install bit, â€” The value 1 means the IEEE 802.1X component shall configure the temporal key derived from this message into its IEEE 802.11 STA. â€” The value 0 means the IEEE 802.1X component shall not configure the temporal key into the IEEE 802.11 STA. ii) If the value of Key Type (bit 3) is 0, then this bit is reserved. 5) Key Ack (bit 7) is set to 1 in messages from the Authenticator if an EAPOL-Key frame is required in response to this message and is 0 otherwise. The Supplicantâ€™s response to this message shall use the same replay counter as this message. 6) Key MIC (bit 8) is set to 1 if a MIC is in this EAPOL-Key frame and is set to 0 if this message contains no MIC. 7) Secure (bit 9) is set to 1 once the initial key exchange is complete. The Authenticator shall set the Secure bit to 0 in all EAPOL-Key frames sent before the Supplicant has the PTK and the GTK. The Authenticator shall set the Secure bit to 1 in all EAPOL-Key frames it sends to the Supplicant containing the last key needed to complete the Supplicantâ€™s initialization. The Supplicant shall set the Secure bit to 0 in all EAPOL-Key frames it sends before it has the PTK and the GTK and before it has received an EAPOL-Key frame from the Authenticator with the Secure bit equal to 1 (this should be before receiving message 3 of the 4-way handshake). The Supplicant shall set the Secure bit to 1 in all EAPOL-Key frames sent after this until it loses the security association it shares with the Authenticator. 8) Error (bit 10) is set by a Supplicant to report that a MIC failure occurred in a TKIP MSDU or SMK handshake failure. In case of a MIC failure, a Supplicant shall set this bit to 1 only when 2020 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications the Request (bit 11) is 1. When the SMK Message bit is 1, Error shall be set to 1 to indicate the key data field contains an Error KDE. 9) Request (bit 11) is set to 1 by a Supplicant to request that the Authenticator initiate either a 4- way handshake or group key handshake, is set to 1 by a Supplicant in a Michael MIC Failure Report, and is set to 1 by the STSL peer STA to request initiator STA rekeying of the STK. The Supplicant shall not set this bit to 1 in on-going 4-way handshakes, i.e., the Key Ack bit (bit 7) shall not be set to 1 in any message in which the Request bit is 1. The Authenticator shall never set this bit to 1. In a Michael MIC Failure Report, setting the bit is not a request to initiate a new handshake. However, the recipient may initiate a new handshake on receiving such a message. If an EAPOL-Key frame in which the Request bit is 1 has a key type of Pairwise, the Authenticator shall initiate a 4-way handshake. If the EAPOL-Key frame in which the Request bit is 1 has a key type of Group/SMK, the Authenticator shall change the GTK, initiate a 4-way handshake with the Supplicant, and then execute the group key handshake to all Supplicants. If an EAPOL-Key frame in which the Request bit is 1 has the SMK Message bit equal to 1, the initiator STA shall take appropriate action to create a new STK (based on 12.7.8). 10) Encrypted Key Data (bit 12) is set to 1 if the Key Data field is encrypted and is set to 0 if the Key Data field is not encrypted. This subfield shall be set to 1, and the Key Data field shall be encrypted, if any key material (e.g., GTK or SMK) is included in the frame. 11) SMK Message (bit 13) specifies whether this EAPOL-Key frame is part of an SMK handshake. If the SMK handshake is not supported, the SMK Message subfield is reserved. 12) Reserved (bits 14â€“15). c) Key Length. This field is 2 octets in length, represented as an unsigned integer. The value defines the length in octets of the pairwise temporal key. See Table 12-4. Table 12-4â€”Cipher suite key lengths Key length TK_bits Cipher suite (octets) (bits) WEP-40 5 40 WEP-104 13 104 TKIP 32 256 CCMP-128 16 128 BIP-CMAC-128 16 128 GCMP-128 16 128 GCMP-256 32 256 CCMP-256 32 256 BIP-GMAC-128 16 128 BIP-GMAC-256 32 256 BIP-CMAC-256 32 256 d) Key Replay Counter. This field is 8 octets, represented as an unsigned integer, and is initialized to 0 when the PMK is established. The Supplicant shall use the key replay counter in the received 2021 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications EAPOL-Key frame when responding to an EAPOL-Key frame. It carries a sequence number that the protocol uses to detect replayed EAPOL-Key frames. The Supplicant and Authenticator shall track the key replay counter per security association. The key replay counter shall be initialized to 0 on (re)association. The Authenticator shall increment the key replay counter on each successive EAPOL-Key frame. When replying to a message from the Authenticator, the Supplicant shall use the Key Replay Counter field value from the last valid EAPOL-Key frames received from the Authenticator. The Authenticator should use the key replay counter to identify invalid messages to silently discard. The Supplicant should also use the key replay counter and ignore EAPOL-Key frames with a Key Replay Counter field value smaller than or equal to any received in a valid message. The local Key Replay Counter field should not be updated until after the EAPOL-Key MIC is checked and is found to be valid. In other words, the Supplicant never updates the Key Replay Counter field for message 1 in the 4-way handshake, as it includes no MIC. This implies the Supplicant needs to allow for retransmission of message 1 when checking for the key replay counter of message 3. The Supplicant shall maintain a separate key replay counter for sending EAPOL-Key request frames to the Authenticator; the Authenticator also shall maintain a separate replay counter to filter received EAPOL-Key request frames. NOTEâ€”The key replay counter does not play any role beyond a performance optimization in the 4-way handshake. In particular, replay protection is provided by selecting a never-before-used nonce value to incorporate into the PTK. It does, however, play a useful role in the group key handshake. e) Key Nonce. This field is 32 octets. It conveys the ANonce from the Authenticator and the SNonce from the Supplicant. It may contain 0 if a nonce is not required to be sent. f) EAPOL-Key IV. This field is 16 octets. It contains the IV used with the KEK. It shall contain 0 when an IV is not required. It should be initialized by taking the current value of the global key counter (see 12.7.11) and then incrementing the counter. Note that only the lower 16 octets of the counter value are used. g) Key RSC. This field is 8 octets in length. It contains the receive sequence counter (RSC) for the GTK being installed. It is used in message 3 of the 4-way handshake and message 1 of the group key handshake, where it is used to synchronize the IEEE 802.11 replay state. It may also be used in the Michael MIC Failure Report frame, to report the TSC field value of the frame experiencing a MIC failure. It shall contain 0 in other messages. The Key RSC field gives the current message number for the GTK, to allow a STA to identify replayed MPDUs. If the Key RSC field value is less than 8 octets in length, the remaining octets shall be set to 0. The least significant octet of the TSC or PN should be in the first octet of the Key RSC field. The encoding of the Key RSC field is defined in Table 12-5. Table 12-5â€”Key RSC field KeyRSC 0 KeyRSC 1 KeyRSC 2 KeyRSC 3 KeyRSC 4 KeyRSC 5 KeyRSC 6 KeyRSC 7 TSC0 TSC1 TSC2 TSC3 TSC4 TSC5 0 0 PN0 PN1 PN2 PN3 PN4 PN5 0 0 For WEP, the Key RSC field is reserved. h) Key MIC. The EAPOL Key MIC is a MIC of the EAPOL-Key frames, from and including the EAPOL protocol version field to and including the Key Data field, calculated with the Key MIC field set to 0. If the Encrypted Key Data subfield (of the Key Information field) is 1, the Key Data field is encrypted prior to computing the MIC. The length of this field depends on the negotiated AKM as defined in 12.7.3. 2022 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications i) Key Data Length. This field is 2 octets in length, taken to represent an unsigned integer. This represents the length of the Key Data field in octets. If the Encrypted Key Data subfield (of the Key Information field) is 1, the length is the length of the Key Data field after encryption, including any padding. j) Key Data. This field is a variable-length field that is used to include any additional data required for the key exchange that is not included in the fields of the EAPOL-Key frame. The additional data may be zero or more element(s) (such as the RSNE) and zero or more key data cryptographic encapsulation(s) (KDEs) (such as GTK(s) or PMKID(s)). Elements sent in the Key Data field include the Element ID and Length subfields. KDEs shall be encapsulated using the format in Figure 12-34. Type (0xdd) Length OUI Data Type Data Octets: 1 1 3 1 (Length â€“ 4) Figure 12-34â€”KDE format The Type field shall be set to 0xdd. The Length field specifies the number of octets in the OUI, Data Type, and Data fields. The OUI field contains either an OUI or CID. The order of the OUI field is described in 9.2.2. Table 12-6 lists the KDE selectors defined by this standard. Table 12-6â€”KDE OUI Data type Meaning 00-0F-AC 0 Reserved 00-0F-AC 1 GTK KDE 00-0F-AC 2 Reserved 00-0F-AC 3 MAC address KDE 00-0F-AC 4 PMKID KDE 00-0F-AC 5 SMK KDE 00-0F-AC 6 Nonce KDE 00-0F-AC 7 Lifetime KDE 00-0F-AC 8 Error KDE 00-0F-AC 9 IGTK KDE 00-0F-AC 10 Key ID KDE 00-0F-AC 11 Multi-band GTK KDE 00-0F-AC 12 Multi-band Key ID KDE 00-0F-AC 13â€“255 Reserved Other OUI or CID Any Vendor specific A STA shall ignore any elements and KDEs it does not understand. If the Encrypted Key Data subfield (of the Key Information field) is 1, the entire Key Data field shall be encrypted. If the Key Data field uses the NIST AES key wrap, then the Key Data field shall be padded before encrypting if the key data length is less than 16 octets or if it is not a multiple of 8. 2023 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The padding consists of appending a single octet 0xdd followed by zero or more 0x00 octets. When processing a received EAPOL-Key frame, the receiver shall ignore this trailing padding. Key Data fields that are encrypted, but do not contain the GroupKey or SMK KDE, shall be accepted. If the GroupKey or SMK KDE is included in the Key Data field, but the Key Data field is not encrypted, the EAPOL-Key frames shall be ignored. The format of the GTK KDE is shown in Figure 12-35 Key ID Tx Reserved Reserved GTK bits 0â€“1 bit 2 bit 3â€“7 1 octet (Length â€“ 6) octets Figure 12-35â€”GTK KDE format If the value of the Tx field is 1, then the IEEE 802.1X component shall configure the temporal key derived from this KDE into its IEEE 802.11 STA for both transmission and reception. If the value of the Tx field is 0, then the IEEE 802.1X component shall configure the temporal key derived from this KDE into its IEEE 802.11 STA for reception only. The format of the MAC address KDE is shown in Figure 12-36. MAC Address Octets: 6 Figure 12-36â€”MAC address KDE format The format of the PMKID KDE is shown in Figure 12-37. PMKID Octets: 16 Figure 12-37â€”PMKID KDE format The format of the SMK KDE is shown in Figure 12-38. SMK Key Nonce Octets: 32 32 Figure 12-38â€”SMK KDE format The format of the Nonce KDE is shown in Figure 12-39. Key Nonce Octets: 32 Figure 12-39â€”Nonce KDE format The format of the Lifetime KDE is shown in Figure 12-40. The Key Lifetime value is expressed in seconds and uses big endian octet order. 2024 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Key Lifetime (in seconds) Octets: 4 Figure 12-40â€”Lifetime KDE format The format of the Error KDE is shown in Figure 12-41. The Error Type field is in big endian octet order. Table 12-7 shows different values of SMK error types. Reserved Error Type Octets: 2 2 Figure 12-41â€”Error KDE format Table 12-7â€”SMK error types Error name Error type Error meaning ERR_STA_NR 1 STA is not reachable from AP. See 12.7.8.5.2. ERR_STA_NRSN 2 STA to AP secure network not present. See 12.7.8.5.3. ERR_CPHR_NS 3 Cipher suites not supported. See 12.7.8.5.4. ERR_NO_STSL 4 No STSL session present. See 12.7.8.5.5. The format of the IGTK KDE is shown in Figure 12-42. The IPN corresponds to the last packet number used by the broadcast/multicast transmitter, and it is used by the receiver as the initial value for the BIP replay counter. Key ID IPN IGTK Octets: 2 6 (Length â€“ 12) Figure 12-42â€”IGTK KDE format The following EAPOL-Key frames are used to implement the three different exchanges: â€” 4-way handshake message 1 is an EAPOL-Key frame with the Key Type subfield equal to 1. The Key Data field shall contain a PMKID for the PMK that is being used in this key derivation and need not be encrypted. â€” 4-way handshake message 2 is an EAPOL-Key frame with the Key Type subfield equal to 1. The Key Data field shall contain an RSNE and need not be encrypted. An ESS Supplicantâ€™s SME shall insert the RSNE it sent in its (Re)Association Request frame. The RSNE is included as transmitted in the Management frame. On receipt of message 2, the Authenticatorâ€™s SME shall validate the selected security configuration against the RSNE received in the IEEE 802.11 (Re)Association Request. An IBSS Supplicantâ€™s SME shall insert an RSNE containing a selected pairwise cipher suite. The Authenticatorâ€™s SME shall validate that the pairwise cipher suite selected is one of its configured cipher suites and that the group cipher suite and AKM are consistent. 2025 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” 4-way handshake message 3 is an EAPOL-Key frame with the Key Type subfield equal to 1. The Key Data field shall contain one or two RSNEs. If a group cipher has been negotiated, this field shall also include a GTK. This field shall be encrypted if a GTK is included. An Authenticatorâ€™s SME shall insert the RSNE it sent in its Beacon or Probe Response frame. The Supplicantâ€™s SME shall validate the selected security configuration against the RSNE received in message 3. If the second optional RSNE is present, the STA shall either use that cipher suite with its pairwise key or deauthenticate. In either case, if the values do not match, then the receiver shall consider the RSNE modified and shall use the MLME-DEAUTHENTICATE.request primitive to break the association. A security error should be logged at this time. It may happen, for example, that a Supplicant selects a pairwise cipher suite which is advertised by an AP, but which policy disallows for this particular STA. An Authenticator may, therefore, insert a second RSNE to overrule the STAâ€™s selection. An Authenticatorâ€™s SME shall insert the second RSNE, after the first RSNE, only for this purpose. The pairwise cipher suite in the second RSNE included shall be one of the ciphers advertised by the Authenticator. All other fields in the second RSNE shall be identical to the first RSNE. A GTK shall be included and the unencrypted length of the GTK is six less than the length of the GTK KDE in octets. The entire Key Data field shall be encrypted as specified by the Key Descriptor Version. â€” 4-way handshake message 4 is an EAPOL-Key frame with the Key Type subfield equal to 1. The Key Data field can be empty. â€” Group key handshake message 1 is an EAPOL-Key frame with the Key Type subfield equal to 0. The Key Data field shall contain a GTK KDE and shall be encrypted. â€” Group key handshake message 2 is an EAPOL-Key frame with the Key Type subfield equal to 0. The Key Data field can be empty. PeerKey handshake messages use EAPOL-Key frames as defined in 12.7.8. The key wrap algorithm selected depends on the negotiated AKM as defined in 12.7.3. The format of the Key ID KDE is shown in Figure 12-43. B0 B1 B2 B15 Key ID Reserved Bits: 2 14 Figure 12-43â€”Key ID KDE The Key ID field contains the Authenticator selected Key ID. The format of the Multi-band GTK KDE is shown in Figure 12-44. B0 B1 B2 B3 B7 B8 B15 B16 B63 Key ID Tx Reserved Band ID GTK Bits: 2 1 5 8 48 Figure 12-44â€”Multi-band GTK KDE The definitions of the Key ID, Tx, and GTK fields are the same as in the GTK KDE described above. The Band ID field contains the identification of the frequency band (see 9.4.1.46). 2026 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The format of the Multi-band Key ID KDE is shown in Figure 12-45. B0 B1 B2 B7 B8 B15 Key ID Reserved Band ID Bits: 2 6 8 Figure 12-45â€”Multi-band Key ID KDE The definitions of the Key ID and Band ID fields are the same as in the Multi-band GTK KDE described above. 12.7.3 EAPOL-Key frame construction and processing EAPOL-Key frames are constructed and processed according to the AKM negotiated at association time. The negotiated AKM determines what algorithm is used to construct and verify a MIC, the size of the MIC, and the algorithm used to wrap and unwrap the Key Data field. Table 12-8 indicates the particular algorithms to use when constructing and processing EAPOL-Key frames. The AKM of â€œDeprecatedâ€ indicates an AKM of 00-0F-AC:1 or 00-0F-AC:2 when either TKIP or â€œUse group cipher suiteâ€ is the negotiated pairwise cipher. For all other AKMs the negotiated pairwise cipher suite does not influence the algorithms used to process EAPOL-Key frames. Table 12-8â€”Integrity and key-wrap algorithms Integrity Key-wrap AKM KCK_bits Size of MIC KEK_bits algorithm algorithm 00-0F-AC:1 HMAC-SHA-1-128 128 16 NIST AES Key 128 Wrap 00-0F-AC:2 HMAC-SHA-1-128 128 16 NIST AES Key 128 Wrap 00-0F-AC:3 AES-128-CMAC 128 16 NIST AES Key 128 Wrap 00-0F-AC:4 AES-128-CMAC 128 16 NIST AES Key 128 Wrap 00-0F-AC:5 AES-128-CMAC 128 16 NIST AES Key 128 Wrap 00-0F-AC:6 AES-128-CMAC 128 16 NIST AES Key 128 Wrap 00-0F-AC:8 AES-128-CMAC 128 16 NIST AES Key 128 Wrap 00-0F-AC:9 AES-128-CMAC 128 16 NIST AES Key 128 Wrap 00-0F-AC:11 HMAC-SHA-256 128 16 NIST AES Key 128 Wrap 00-0F-AC:12 HMAC-SHA-384 192 24 NIST AES Key 256 Wrap 00-0F-AC:13 HMAC-SHA-384 192 24 NIST AES Key 256 Wrap 2027 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 12.7.4 EAPOL-Key frame notation The following notation is used throughout the remainder of 12.7 and 13.4 to represent EAPOL-Key frames: EAPOL-Key(S, M, A, I, K, SM, KeyRSC, ANonce/SNonce, MIC, DataKDs) where S means the initial key exchange is complete. This is the Secure bit of the Key Informa- tion field. M means the MIC is available in message. This should be set in all messages except message 1 of a 4-way handshake. This is the Key MIC bit of the Key Information field. A means a response is required to this message. This is used when the receiver should respond to this message. This is the Key Ack bit of the Key Information field. I is the Install bit: Install/Not install for the pairwise key. This is the Install bit of the Key Information field. K is the key type: P (Pairwise), G (Group/SMK). This is the Key Type bit of the Key Information field. SM is the SMK Message bit: indicates that this message is part of SMK handshake. KeyRSC is the key RSC. This is the Key RSC field. ANonce/SNonce is the Authenticator/Supplicant nonce. This is the Key Nonce field. MIC is the integrity check, which is generated using the KCK. This is the Key MIC field. DataKDs is a sequence of zero or more elements and KDEs, contained in the Key Data field, which may contain the following: RSNE is described in 9.4.2.25. RSNE[KeyName] is the RSNE, with the PMKID field set to KeyName. GTK[N] is the GTK, with the key identifier field set to N. The key identifier specifies which index is used for this GTK. Index 0 shall not be used for GTKs, except in mixed environments, as described in 12.7.1. FTE is the Fast BSS Transition element, described in 9.4.2.48 MDE is the Mobility Domain element, described in 9.4.2.47 TIE[IntervalType] is a Timeout Interval element of type IntervalType, as described in 9.4.2.49, containing e.g., for type KeyLifetime, the lifetime of the FT key hierarchy. IGTK[M] is the IGTK, with key identifier field set to M. IPN is the current IGTK replay counter value provided by the IGTK KDE PMKID is of type PMKID KDE and is the key identifier used during 4-way PTK handshake for PMK identification and during 4-way STK handshake for SMK identification. Lifetime is the key lifetime KDE used for sending the expiration timeout value for SMK used during PeerKey handshake for SMK identification. Initiator MAC is the Initiator MAC KDE used during PeerKey handshake Peer MAC is the Peer MAC KDE used during PeerKey handshake Initiator Nonce is the Initiator Nonce KDE used during PeerKey handshake. This is used when multiple nonces need to be sent. Peer Nonce is the Peer Nonce KDE used during PeerKey handshake. This is used when multiple nonces need to be sent. SMK KDE is the SMK during SMK handshake. Error KDE is an error KDE used when error bit E is equal to 1 during PeerKey hand- shake. 12.7.5 Nonce generation The following is an informative description of Nonce generation. 2028 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications All STAs contain a global key counter, which is 256 bits in size. It should be initialized at system boot-up time to a fresh cryptographic-quality random number. Refer to J.5 on random number generation. It is recommended that the counter value is initialized to the following: PRF-256(Random number, â€œInit Counterâ€, Local MAC Address || Time) The local MAC address should be AA on the Authenticator and SPA on the Supplicant. The random number is 256 bits in size. Time should be the current time from Network Time Protocol (NTP) or another time in NTP format whenever possible. This initialization causes different initial key counter values to occur across system restarts regardless of whether a real-time clock is available. The key counter can be used as additional input data for nonce generation. A STA derives a random nonce for each new use. 12.7.6 4-way handshake 12.7.6.1 General RSNA defines a protocol using EAPOL-Key frames called the 4-way handshake. The handshake completes the IEEE 802.1X authentication process. The information flow of the 4-way handshake is as follows: Message 1: Authenticator Supplicant: EAPOL-Key(0,0,1,0,P,0,0,ANonce,0,DataKD_M1) where DataKD_M1 = 0 or PMKID for PTK generation, or PMKID KDE (for sending SMKID) for STK generation Message 2: Supplicant Authenticator: EAPOL-Key(0,1,0,0,P,0,0,SNonce,MIC,DataKD_M2) where DataKD_M2 = RSNE for creating PTK generation or peer RSNE, Lifetime KDE, SMKID KDE (for sending SMKID) for STK generation Message 3: Authenticator Supplicant: EAPOL-Key(1,1,1,1,P,0,KeyRSC,ANonce,MIC,DataKD_M3) where DataKD_M3 = RSNE,GTK[N] for creating PTK generation or initiator RSNE, Lifetime KDE for STK generation Message 4: Supplicant Authenticator: EAPOL-Key(1,1,0,0,P,0,0,0,MIC,DataKD_M4) where DataKD_M4 = 0. The FT initial mobility domain association uses the FT 4-way handshake to establish an initial PTKSA, GTKSA and, if management frame protection is enabled, an IGTKSA, that is based on this protocol. The FT 4-way handshake protocol is described in 13.4. Here, the following assumptions apply: â€” EAPOL-Key( ) denotes an EAPOL-Key frame conveying the specified argument list, using the notation introduced in 12.7.4. â€” ANonce is a nonce that the Authenticator contributes for PTK generation or that the initiator STA contributes for STK generation. ANonce has the same value in message 1 and message 3. â€” SNonce is a nonce from the Supplicant for PTK generation or from the peer STA for STK generation. â€” P means the pairwise bit is set. â€” The MIC is computed over the body of the EAPOL-Key frame (with the Key MIC field first zeroed before the computation) using the KCK defined in 12.7.1.3 for PTK generation or SKCK defined in 12.7.1.6. â€” RSNE represents the appropriate RSNEs. â€” GTK[N] represents the GTK with its key identifier. â€” SMKID represents the SMKID key identifier used during STK generation. â€” Lifetime represents the expiration timeout used for exchanging SMK expiration value. 2029 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NOTEâ€”While the MIC calculation is the same in each direction, the Key Ack bit is different in each direction. It is set in EAPOL-Key frames from the Authenticator and 0 in EAPOL-Key frames from the Supplicant. 4-way handshake requests from the Supplicant have the Request bit equal to 1. The Authenticator and Supplicant need to check these bits to stop reflection attacks. It is important that message 1 contents not be used to update state, in particular the keys in use, until the data are validated with message 3. 12.7.6.2 4-way handshake message 1 Message 1 uses the following values for each of the EAPOL-Key frame fields: Descriptor Type = N â€“ see 12.7.2 Key Information: Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap with HMAC-SHA-1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all other cases 0 Key Type = 1 (Pairwise) SMK Message = 0 Install = 0 Key Ack = 1 Key MIC = 0 Secure = 0 Error = 0 Request = 0 Encrypted Key Data = 0 Reserved = 0 â€“ unused by this protocol version Key Length = Cipher-suite-specific; see Table 12-4 Key Replay Counter = n â€“ to allow Authenticator or initiator STA to match the right message 2 from Supplicant or peer STA Key Nonce = ANonce EAPOL-Key IV = 0 Key RSC = 0 Key MIC = 0 Key Data Length = length of Key Data field in octets Key Data = PMKID for the PMK being used during PTK generation or SMKID for SMK being used during STK generation Processing for PTK generation is as follows: The Authenticator sends message 1 to the Supplicant at the end of a successful IEEE 802.1X authentication, after (re)association completes for a STA that has authenticated with SAE or PSK authentication is negotiated, when a cached PMKSA is used, or after a STA requests a new key. On reception of message 1, the Supplicant determines whether the Key Replay Counter field value has been used before with the current PMKSA. If the Key Replay Counter field value is less than or equal to the current local value, the Supplicant discards the message. Otherwise, the Supplicant: a) Generates a new nonce SNonce. b) Derives PTK. c) Constructs message 2. Processing for STK generation is as follows: 2030 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The initiator STA (STA_I) sends message 1 to the peer STA (STA_P) at the end of a successful SMK handshake, when SMKSA is created. On reception of message 1, the STA_P determines whether the Key Replay Counter field value has been used before with the current SMKSA. If the Key Replay Counter field value is less than or equal to the current local value, the STA_P discards the message. Otherwise, the STA_P a) Generates a 256-bit random number following the recommendations of 12.7.5. That number is sent as a peer nonce as part of the Key Nonce field. This Nonce is different from the peer nonce generated as part of the SMK handshake message 3. b) Derives STK. c) Constructs message 2. 12.7.6.3 4-way handshake message 2 Message 2 uses the following values for each of the EAPOL-Key frame fields: Descriptor Type = N â€“ see 12.7.2 Key Information: Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap with HMAC-SHA-1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all other cases 0 â€“ same as message 1 Key Type = 1 (Pairwise) â€“ same as message 1 SMK Message = 0 â€“ same as message 1 Install = 0 Key Ack = 0 Key MIC = 1 Secure = 0 â€“ same as message 1 Error = 0 â€“ same as message 1 Request = 0 â€“ same as message 1 Encrypted Key Data = 0 Reserved = 0 â€“ unused by this protocol version Key Length = 0 Key Replay Counter = n â€“ to let the Authenticator or initiator STA know to which message 1 this corresponds Key Nonce = SNonce EAPOL-Key IV = 0 Key RSC = 0 Key MIC = MIC(KCK, EAPOL) â€“ MIC computed over the body of this EAPOL-Key frame with the Key MIC field first initialized to 0 Key Data Length = length of Key Data field in octets Key Data = â€” included RSNE â€“ the sending STAâ€™s RSNE for PTK generation or peer RSNE for the current operating band, and when this message 2 is part of a fast BSS transition initial mobility domain association or an association started through the FT protocol, the PMKR1Name calculated by the S1KH according to the procedures of 12.7.1.7.4 is included in the PMKID field of the RSNE and the FTE and MDE are also included, or; â€” The sending STAâ€™s Multi-band element for PTK generation for a supported band other than the current operating band if dot11MultibandImplemented is true, or; â€” The sending STAâ€™s RSNE and Multi-band element(s) for generating a single PTK for all involved bands, if dot11MultibandImplemented is true and both the Authenticator and the 2031 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Supplicant use the same MAC address in the current operating band and the other supported band(s); or; â€” The sending STAâ€™s RSNE and Multi-band element(s) for generating a different PTK for each involved band, if dot11MultibandImplemented is true and the Joint Multi-band RSNA subfield of the RSN capabilities field is 1 for both the Authenticator and the Supplicant, and either the Authenticator or the Supplicant uses different MAC addresses for different bands. â€” Lifetime of SMK and SMKID for STK generation. Processing for PTK generation is as follows: The Supplicant sends message 2 to the Authenticator. On reception of message 2, the Authenticator checks that the key replay counter corresponds to the outstanding message 1. If not, it silently discards the message. Otherwise, the Authenticator: a) Derives PTK. b) Verifies the message 2 MIC. 1) If the calculated MIC does not match the MIC that the Supplicant included in the EAPOL-Key frame, the Authenticator silently discards message 2. 2) If the MIC is valid and this message 2 is part of a fast BSS transition initial mobility domain association or an association started through the FT protocol, the Authenticator checks that all fields of the RSNE other than the PMKID field bitwise matches the fields from the (Re)Association Request frame and that the FTE and MDE are the same as those provided in the APâ€™s (Re)Association Response frame. If the MIC is valid and this message 2 is not part of a fast BSS transition initial mobility domain association and this message 2 is not part of an association started through the FT protocol, the Authenticator checks that the RSNE bitwise matches that from the (Re)Association Request frame. i) If these are not exactly the same, the Authenticator uses MLME-DEAUTHENTI- CATE.request primitive to terminate the association. ii) If they do match bitwise, the Authenticator constructs message 3. c) If management frame protection is being negotiated, the AP initializes the SA Query Transaction Identifier to an implementation-specific non-negative integer value, valid for the current pairwise security association. Processing for STK generation is as follows: The STA_P sends message 2 to the STA_I. On reception of message 2, the STA_I checks that the key replay counter corresponds to message 1. If not, it silently discards the message. Otherwise, the STA_I a) Derives the STK. b) Verifies the message 2 MIC using the SKCK. If the calculated MIC does not match the MIC that the STA_P included in the EAPOL-Key frame, the STA_I silently discards message 2. c) If the MIC is valid, the STA_I checks that the RSNE bitwise matches that from the SMK handshake message 5. If these are not exactly the same, STA_I silently discards the message and restarts the 4- way handshake after deleting the existing 4-way handshake states. d) If they do match bitwise, the STA_I checks SMKID with the value of SMKID in the SMKSA. If these are not exactly the same, STA_I silently discards the message and restarts the 4-way handshake after deleting the existing 4-way handshake states. e) If they do match, the STA_I constructs message 3. It also compares the Key Lifetime value from the KDE with value in its SMKSA. If value in its SMKSA is less, it discards the value received in message 2. Otherwise, it updates the value in the SMKSA with value in message 2. 2032 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 12.7.6.4 4-way handshake message 3 Message 3 uses the following values for each of the EAPOL-Key frame fields: Descriptor Type = N â€“ see 12.7.2 Key Information: Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap with HMAC-SHA-1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all other cases 0 â€“ same as message 1 Key Type = 1 (Pairwise) â€“ same as message 1 SMK Message = 0 - same as message 1 Install = 0/1 â€“ For PTK generation, 0 only if the AP does not support key mapping keys, or if the STA has the No Pairwise bit (in the RSN Capabilities field) equal to 1and only the group key is used. For STK generation, this bit is set to 1. Key Ack = 1 Key MIC = 1 Secure = 1 (keys installed) Error = 0 â€“ same as message 1 Request = 0 â€“ same as message 1 Encrypted Key Data = 1 Reserved = 0 â€“ unused by this protocol version Key Length = Cipher-suite-specific; see Table 12-4 Key Replay Counter = n+1 Key Nonce = ANonce â€“ same as message 1 EAPOL-Key IV = 0 (Version 2) or random (Version 1) Key RSC = For PTK generation, starting TSC or PN that the Authenticatorâ€™s STA uses in MPDUs protected by GTK. For STK generation, this is set to 0. Key MIC = MIC(KCK, EAPOL) or MIC(SKCK, EAPOL) â€“ MIC computed over the body of this EAPOL-Key frame with the Key MIC field first initialized to 0 Key Data Length = length of Key Data field in octets of included RSNEs and GTK Key Data = â€” For PTK generation for the current operating band, the APâ€™s Beacon/Probe Response frameâ€™s RSNE for the current operating band, and, optionally, a second RSNE that is the Authenticatorâ€™s pairwise cipher suite assignment for the current operating band, and, if a group cipher has been negotiated, the GTK and the GTKâ€™s key identifier (see 12.7.2) for the current operating band, and if management frame protection is negotiated, the IGTK KDE, and when this message 3 is part of a fast BSS transition initial mobility domain association or an association started through the FT protocol, the PMKR1Name calculated according to the procedures of 12.7.1.7.4 in the PMKID field of the RSNE and the FTE with the same contents as in the (Re)Association Response frame, the MDE with the same contents as in the (Re)Association Response frame, the reassociation deadline timeout set to the minimum of dot11FTReassociationDeadline and the key lifetime in the TIE[ReassociationDeadline], and the PTK lifetime in the TIE[KeyLifetime]; or â€” For PTK generation for a supported band other than the current operating band, the Authenticatorâ€™s Beacon/DMG Beacon/Announce/Probe Response/Information Response frameâ€™s Multi-band element associated with the supported band, and optionally a second Multi-band element that indicates the Authenticatorâ€™s pairwise cipher suite assignment for the supported band, and, if group cipher for the supported band is negotiated, the Multi- band GTK KDE for the supported band if dot11MultibandImplemented is true, or; 2033 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” For generating a single PTK for all involved bands, the Authenticatorâ€™s Beacon/DMG Beacon/Announce/Probe Response/Information Response frameâ€™s RSNE and Multi-band element(s), and optionally, additional RSNE and Multi-band element(s) that indicate the Authenticatorâ€™s assignment of one pairwise cipher suite for all involved bands; if a group cipher for all involved bands is negotiated, the GTK and the GTKâ€™s key identifier for all involved bands, if dot11MultibandImplemented is true and both the Authenticator and the Supplicant use the same MAC address in the current operating band and the other supported band(s), or; â€” For generating different PTKs for the current operating band and other supported band(s), the Authenticatorâ€™s Beacon/DMG Beacon/Announce/Probe Response/Information Response frameâ€™s RSNE and Multi-band element(s), and optionally, additional RSNE and Multi-band elements that are the Authenticatorâ€™s pairwise cipher suite assignments for one or more involved bands; if group ciphers for the involved bands are negotiated, the Multi- band GTK KDEs for the involved bands, if dot11MultibandImplemented is true and the Joint Multi-band RSNA subfield is 1 for both the Authenticator and Supplicant, and either the Authenticator or the Supplicant uses different MAC addresses for different bands. â€” For STK generation Initiator RSNE, Lifetime of SMK is used. â€” If the Extended Key ID for Individually Addressed Frames subfield of the RSN Capabilities field is 1 for both the Authenticator/STA_I and Supplicant/STA_P, then the Authenticator/STA_I includes the Key ID KDE with the assigned key identifier for the current operating band; or the Authenticator includes the Multi-band Key ID KDE(s) with the assigned key identifier(s) for one or more supported bands if dot11MultibandImplemented is true. Processing for PTK generation is as follows: If the Extended Key ID for Individually Addressed Frames subfield of the RSN Capabilities field is 1 for both the Authenticator and the Supplicant, then the Authenticator assigns a new Key ID for the PTKSA in the range 0 to 1 that is different from the Key ID assigned in the previous handshake and uses the MLME- SETKEYS.request primitive to install the new key to receive individually addressed MPDUs protected by the PTK with the assigned Key ID. Otherwise Key ID 0 is used and installation of the key is deferred until after message 4 has been received. The Authenticator sends message 3 to the Supplicant. NOTEâ€”If an existing PTK is still in effect, the Authenticator IEEE 802.11 MAC continues to transmit protected, individually addressed MPDUs (if any) using the existing key. With the installation of the new key for receive, the Authenticator is able to receive protected, individually addressed MPDUs using either the old key (if present) or the new key. On reception of message 3, the Supplicant silently discards the message if the Key Replay Counter field value has already been used or if the ANonce value in message 3 differs from the ANonce value in message 1. The Supplicant also: a) Verifies the RSNE. If this message 3 is part of a fast BSS transition initial mobility domain association or an association started through the FT protocol, the Supplicant verifies that the PMKR1Name in the PMKID field of the RSNE is identical to the value it sent in message 2 and verifies that all other fields of the RSNE are identical to the fields in the RSNE present in the Beacon or Probe Response frames and verifies that the FTE and MDE are the same as in the (Re)Association Response frame. Otherwise, the Supplicant verifies that the RSNE is identical to that the STA received in the Beacon or Probe Response frame. If any of these verification steps indicates a mismatch, the STA shall disassociate or deauthenticate. If a second RSNE is provided in the message, the Supplicant uses the pairwise cipher suite specified in the second RSNE or deauthenticates. b) Verifies the message 3 MIC. If the calculated MIC does not match the MIC that the Authenticator included in the EAPOL-Key frame, the Supplicant silently discards message 3. 2034 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications c) Updates the last-seen value of the Key Replay Counter field. d) If the Extended Key ID for Individually Addressed Frames subfield of the RSN Capabilities field is 1 for both the Authenticator and Supplicant: Uses the MLME-SETKEYS.request primitive to configure the IEEE 802.11 MAC to receive individually addressed MPDUs protected by the PTK with the assigned Key ID. e) Constructs message 4. f) Sends message 4 to the Authenticator. g) Uses the MLME-SETKEYS.request primitive to configure the IEEE 802.11 MAC to send and, if the receive key has not yet been installed, to receive individually addressed MPDUs protected by the PTK. The GTK is also configured by MLME-SETKEYS primitive. Processing for STK generation is as follows: If the Extended Key ID for Individually Addressed Frames subfield of the RSN Capabilities field is set to 1 for both the STA_I and the STA_P, then the Authenticator assigns a new Key ID for the STKSA in the range 0 to 1 that is different from the Key ID assigned in the previous handshake and uses the MLME- SETKEYS.request primitive to install the new key to receive individually addressed MPDUs protected by the STK with the assigned Key ID. Otherwise Key ID 0 is used and installation of the key is deferred until after message 4 has been received. The STA_I sends message 3 to the STA_P. NOTEâ€”If an existing STK is still in effect, the STA_I IEEE 802.11 MAC continues to transmit protected, individually addressed MPDUs (if any) using the existing key. With the installation of the new key for receive, the STA_I is able to receive protected, individually addressed MPDUs using both the old key (if present) or the new key. On reception of message 3, the STA_P silently discards the message if the Key Replay Counter field value has already been used or if the INonce value in message 3 differs form the INonce value in message 1. Otherwise, a) The STA_P verifies the message 3 MIC using the SKCK in the SMKSA. If the calculated MIC does not match the MIC that the STA_P included in the EAPOL-Key frame, the STA_I silently discards message 3. b) If the MIC is valid, the STA_P checks that the RSNE bitwise matches that from the 4-way handshake message 2. If these are not exactly the same, STA_P silently discards the message and deletes existing 4-way handshake states. c) If they do match, the STA_P constructs message 4. It also compares the Key Lifetime value from KDE with value in its SMKSA. If value in the SMKSA is less, it discards the value received in message 3. Otherwise, it updates the value in the SMKSA with value in message 3. d) If the Extended Key ID for Individually Addressed Frames subfield of the RSN Capabilities field is 1 for both the Authenticator and Supplicant then prior to sending message 4, STA_P uses the MLME-SETKEYS.request primitive to configure the IEEE 802.11 MAC to receive individually addressed MPDUs protected by the STK with the assigned Key ID. e) After sending message 4, STA_P uses the MLME-SETKEYS.request primitive to configure the IEEE 802.11 MAC to send and, if the receive key has not yet been installed, to receive individually addressed MPDUs protected by the STK with the assigned Key ID. 12.7.6.5 4-way handshake message 4 Message 4 uses the following values for each of the EAPOL-Key frame fields: Descriptor Type = N â€“ see 12.7.2 Key Information: Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap with HMAC-SHA-1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all other cases 0 â€“ same as message 1 2035 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Key Type = 1 (Pairwise) â€“ same as message 1 SMK Message = 0 - same as message 1 Install = 0 Key Ack = 0 â€“ this is the last message Key MIC = 1 Secure = 1 Error = 0 Request = 0 Encrypted Key Data = 0 Reserved = 0 â€“ unused by this protocol version Key Length = 0 Key Replay Counter = n+1 Key Nonce = 0 EAPOL-Key IV = 0 Key RSC = 0 Key MIC = MIC(KCK, EAPOL) or MIC(SKCK, EAPOL) â€“ MIC computed over the body of this EAPOL-Key frame with the Key MIC field first initialized to 0 Key Data Length = length of Key Data field in octets Key Data = none required Processing for PTK generation is as follows: The Supplicant sends message 4 to the Authenticator. Note that when the 4-way handshake is first used, message 4 is sent in the clear. On reception of message 4, the Authenticator verifies that the Key Replay Counter field value is one that it used on this 4-way handshake; if it is not, it silently discards the message. Otherwise: a) The Authenticator checks the MIC. If the calculated MIC does not match the MIC that the Supplicant included in the EAPOL-Key frame, the Authenticator silently discards message 4. b) If the MIC is valid, the Authenticator uses the MLME-SETKEYS.request primitive to configure the IEEE 802.11 MAC to send and, if the receive key has not yet been installed, to receive protected, individually addressed MPDUs using for the new PTK. c) The Authenticator updates the Key Replay Counter field so that it uses a fresh value if a rekey becomes necessary. Processing for STK generation is as follows: The STA_P sends message 4 to the STA_I. On reception of message 4, the STA_I verifies that the Key Replay Counter field value is one that it used on this 4-way handshake; if it is not, it silently discards the message. Otherwise, a) The STA_I checks the MIC. If the calculated MIC does not match the MIC that the STA_P included in the EAPOL-Key frame, the STA_I silently discards message 4. b) If the MIC is valid, the STA_I uses the MLME-SETKEYS.request primitive to configure the IEEE 802.11 MAC to send and, if the receive key has not yet been installed, to receive protected, individually addressed MPDUs using for the new STK. c) The STA_I updates the Key Replay Counter field so that it uses a fresh value if a rekey becomes necessary. 2036 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 12.7.6.6 4-way handshake implementation considerations When the 4-way handshake is used as part of the STK handshake, the initiator STA acts as Authenticator and peer STA acts as Supplicant. If the Authenticator does not receive a reply to its messages, it shall attempt dot11RSNAConfigPairwiseUpdateCount transmits of the message, plus a final timeout. The retransmit timeout value shall be 100 ms for the first timeout, half the listen interval for the second timeout, and the listen interval for subsequent timeouts. If there is no listen interval or the listen interval is zero, then 100 ms shall be used for all timeout values. If it still has not received a response after these retries, then for PTK generation the Authenticator should deauthenticate the STA, and for STK generation the STAs should delete the SMKSA and initiate an STSL application teardown procedure. For PTK generation, if the STA does not receive message 1 within the expected time interval (prior to IEEE 802.1X timeout), it should disassociate, deauthenticate, and try another AP/STA. For STK generation, if the peer STA does not receive message 1 or message 3 within the expected time interval (prior to dot11RSNAConfigSATimeout as specified in 12.7.8), it deletes the SMKSA and invokes an STSL application teardown procedure. The Authenticator should ignore EAPOL-Key frames it is not expecting in reply to messages it has sent or EAPOL-Key frames in which the Ack bit is 1. This stops an attacker from sending the first message to the Supplicant who responds to the Authenticator. An implementation should save the KCK and KEK beyond the 4-way handshake, as they are needed for group key handshakes, STK Rekeying, and recovery from TKIP MIC failures. The Supplicant uses the MLME-SETKEYS.request primitive to configure the temporal key from 12.7.1 into its STA after sending message 4 to the Authenticator. If the RSNE check for message 2 or message 3 fails, the SME should log an error and deauthenticate the peer. 12.7.6.7 Sample 4-way handshake The following is an informative sample of a 4-way handshake for illustration. After IEEE 802.1X authentication completes by the AP sending an EAP-Success, the AP initiates the 4-way handshake. See Figure 12-46. The 4-way handshake consists of the following steps: a) The Authenticator sends an EAPOL-Key frame containing an ANonce. b) The Supplicant derives a PTK from ANonce and SNonce. c) The Supplicant sends an EAPOL-Key frame containing SNonce, the RSNE from the (Re)Association Request frame, and a MIC. d) The Authenticator derives PTK from ANonce and SNonce and validates the MIC in the EAPOL- Key frame. e) The Authenticator sends an EAPOL-Key frame containing ANonce, the RSNE from its Beacon or Probe Response frames, the MIC, the GTK, an indication of whether to install the temporal keys, and if management frame protection is negotiated, the IGTK. f) The Supplicant sends an EAPOL-Key frame to confirm whether the temporal keys were installed. 2037 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications IEEE Std 802.11 Station IEEE Std 802.11Access Point IEEE Std 802.1X Supplicant IEEE Std 802.1X Authenticator SNonce = Random ANonce = Random Calculate PTK using ANonce and SNonce EAPOL-Key (0, 1, 0, 0, P, 0, 0, SNonce, MIC, RSNE) Calculate PTK using ANonce and SNonce EAPOL-Key (1, 1, 0, 0, P, 0, 0,0, MIC, 0) Set Temporal Encryption Key and (TKIP Set Temporal Encryption Key and (TKIP only) only) MIC Key MIC Key Set GTK for KeyIDGTK, IGTK for KeyIDIGTK Figure 12-46â€”Sample 4-way handshake 12.7.6.8 4-way handshake analysis The following is an informative analysis of the 4-way handshake. This subclause makes the trust assumptions used in this protocol explicit. The protocol assumes the following: â€” The PMK is known only by the Supplicantâ€™s STA and the Authenticatorâ€™s STA. â€” The Supplicantâ€™s STA uses IEEE 802 address SPA. â€” The Authenticatorâ€™s STA uses IEEE 802 address AA. In many instantiations the RSNA architecture immediately breaks the first assumption because the IEEE 802.1X AS also knows the PMK. Therefore, additional assumptions are required: â€” The AS does not expose the PMK to other parties. â€” The AS does not masquerade as the Supplicant to the Authenticator. â€” The AS does not masquerade as the Authenticator to the Supplicant. â€” The AS does not masquerade as the Supplicantâ€™s STA. â€” The AS does not masquerade as the Authenticatorâ€™s STA. The protocol also assumes this particular Supplicant-Authenticator pair is authorized to know this PMK and to use it in the 4-way handshake. If any of these assumptions are broken, then the protocol fails to provide any security guarantees. The protocol also assumes that the AS delivers the correct PMK to the AP with IEEE 802 address AA and that the STA with IEEE 802 address SPA hosts the Supplicant that negotiated the PMK with the AS. None 2038 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications of the protocols defined by this standard and IEEE Std 802.1X-2010 permit the AS, the Authenticator, the Supplicant, or either STA to verify these assumptions. The PTK derivation step PTK PRF-Length(PMK, â€œPairwise key expansionâ€, Min(AA,SPA) || Max(AA,SPA) || Min(ANonce,SNonce) || Max(ANonce,SNonce)) performs a number of functions: â€” Including the AA and SPA in the computation â€” Binds the PTK to the communicating STAs and â€” Prevents undetected man-in-the-middle attacks against 4-way handshake messages between the STAs with these two IEEE 802 addresses. â€” If ANonce is randomly selected, including ANonce â€” Guarantees the STA at IEEE 802 address AA that PTK is fresh, â€” Guarantees that message 2 and message 4 are live, and â€” Uniquely identifies PTK as . â€” If SNonce is randomly selected, including SNonce â€” Guarantees the STA at IEEE 802 address SPA that PTK is fresh, â€” Guarantees that message 3 is live, and â€” Uniquely identifies PTK as . Choosing the nonces randomly helps prevent precomputation attacks. With unpredictable nonces, a man-in- the-middle attack that uses the Supplicant to precompute messages to attack the Authenticator cannot progress beyond message 2, and a similar attack against the Supplicant cannot progress beyond message 3. The protocol might execute further before an error if predictable nonces are used. Message 1 delivers ANonce to the Supplicant and initiates negotiation for a new PTK. It identifies AA as the peer STA to the Supplicantâ€™s STA. If an adversary modifies either of the addresses or ANonce, the Authenticator detects the result when validating the MIC in message 2. Message 1 does not carry a MIC, as it is impossible for the Supplicant to distinguish this message from a replay without maintaining state of all security associations through all time (PMK might be a static key). Message 2 delivers SNonce to the Authenticator so it can derive the PTK. If the Authenticator selected ANonce randomly, message 2 also demonstrates to the Authenticator that the Supplicant is live, that the PTK is fresh, and that there is no man-in-the-middle attack, as the PTK includes the IEEE 802 MAC addresses of both. Inclusion of ANonce in the PTK derivation also protects against replay. The MIC prevents undetected modification of message 2 contents. Message 3 confirms to the Supplicant that there is no man-in-the-middle attack. If the Supplicant selected SNonce randomly, it also demonstrates that the PTK is fresh and that the Authenticator is live. The MIC again prevents undetected modification of message 3. While message 4 serves no cryptographic purpose, it serves as an acknowledgment to message 3. It is required to inform the Authenticator that the Supplicant has installed the PTK and GTK and hence can receive encrypted frames. The PTK and GTK are installed by using MLME-SETKEYS.request primitive after message 4 is sent. The PTK is installed before the GTK. 2039 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Then the 4-way handshake uses a correct, but unusual, mechanism to guard against replay. As noted earlier in this subclause, ANonce provides replay protection to the Authenticator, and SNonce to the Supplicant. In most session initiation protocols, replay protection is accomplished explicitly by selecting a nonce randomly and requiring the peer to reflect the received nonce in a response message. The 4-way handshake instead mixes ANonce and SNonce into the PTK, and replays are detected implicitly by MIC failures. In particular, the Key Replay Counter field serves no cryptographic purpose in the 4-way handshake. Its presence is not detrimental, however, and it plays a useful role as a minor performance optimization for processing stale instances of message 2. This replay mechanism is correct, but its implicit nature makes the protocol harder to understand than an explicit approach. It is critical to the correctness of the 4-way handshake that at least one bit differs in each message. Within the 4-way handshake, message 1 can be recognized as the only one in which the Key MIC bit is 0, meaning message 1 does not include the MIC, while message 2 to message 4 do. Message 3 differs from message 2 by not asserting the Ack bit and from message 4 by asserting the Ack Bit. Message 2 differs from message 4 by including the RSNE. Request messages are distinct from 4-way handshake messages because the former asserts the Request bit and 4-way handshake messages do not. Group key handshake messages are distinct from 4-way handshake messages because they assert a different key type. 12.7.7 Group key handshake 12.7.7.1 General The Authenticator uses the Group key handshake to send a new GTK and, if management frame protection is negotiated, a new IGTK to the Supplicant. The Authenticator may initiate the exchange when a Supplicant is disassociated or deauthenticated. Message 1: Authenticator Supplicant: EAPOL-Key(1,1,1,0,G,0,Key RSC,0, MIC,GTK[N],IGTK[M]) Message 2: Supplicant Authenticator: EAPOL-Key(1,1,0,0,G,0,0,0,MIC,0) Here, the following assumptions apply: â€” Key RSC denotes the last TSC or PN sent using the GTK. â€” GTK[N] denotes the GTK with its key identifier as defined in 12.7.2 using the KEK defined in 12.7.1.3 and associated IV. â€” IGTK[M], when present, denotes the IGTK with its key identifier as defined in 12.7.2 using the KEK defined in 12.7.1.3 and associated IV. â€” The MIC is computed over the body of the EAPOL-Key frame (with the MIC field zeroed for the computation) using the KCK defined in 12.7.1.3. The Supplicant may trigger a group key handshake by sending an EAPOL-Key frame with the Request bit set to 1 and the type of the Group Key bit. An Authenticator shall do a 4-way handshake before a group key handshake if both are required to be done. NOTEâ€”The Authenticator cannot initiate the group key handshake until the 4-way handshake completes successfully. 2040 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 12.7.7.2 Group key handshake message 1 Message 1 uses the following values for each of the EAPOL-Key frame fields: Descriptor Type = N â€“ see 12.7.2 Key Information: Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap with HMAC-SHA-1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all other cases 0 Key Type = 0 (Group/SMK) SMK Message = 0 Install = 0 Key Ack = 1 Key MIC = 1 Secure = 1 Error = 0 Request = 0 Encrypted Key Data = 1 Reserved = 0 Key Length = 0 Key Replay Counter = n+2 Key Nonce = 0 EAPOL-Key IV = 0 (Version 2) or random (Version 1) Key RSC = last TSC or PN for the GTK Key MIC = MIC(KCK, EAPOL) Key Data Length = Cipher-suite-specific; see Table 12-4 Key Data = encrypted, encapsulated â€” GTK and the GTKâ€™s key identifier (see 12.7.2) â€” When present, IGTK, IGTKâ€™s key identifier, and IPN (see 12.7.2) The Authenticator sends message 1 to the Supplicant. On reception of message 1, the Supplicant: a) Verifies that the Key Replay Counter field value has not yet been seen before, i.e., its value is strictly larger than that in any other EAPOL-Key frame received thus far during this session. b) Verifies that the MIC is valid, i.e., it uses the KCK that is part of the PTK to verify that there is no data integrity error. c) Uses the MLME-SETKEYS.request primitive to configure the temporal GTK and, when present, IGTK into its IEEE 802.11 MAC. d) Responds by creating and sending message 2 of the group key handshake to the Authenticator and incrementing the replay counter. NOTEâ€”The Authenticator increments and uses a new Key Replay Counter field value on every message 1 instance, even retries, because the message 2 responding to an earlier message 1 might have been lost. If the Authenticator did not increment the replay counter, the Supplicant discards the retry, and no responding message 2 ever arrives. 2041 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 12.7.7.3 Group key handshake message 2 Message 2 uses the following values for each of the EAPOL-Key frame fields: Descriptor Type = N â€“ see 12.7.2 Key Information: Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap with HMAC-SHA-1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all other cases 0 â€“ same as message 1 Key Type = 0 (Group/SMK) â€“ same as message 1 Install = 0 Key Ack = 0 Key MIC = 1 Secure = 1 Error = 0 Request = 0 Encrypted Key Data = 0 Reserved = 0 Key Length = 0 Key Replay Counter = n+2 â€“ same as message 1 Key Nonce = 0 EAPOL-Key IV = 0 Key RSC = 0 Key MIC = MIC(KCK, EAPOL) Key Data Length = 0 Key Data = none required On reception of message 2, the Authenticator: a) Verifies that the Key Replay Counter field value matches one it has used in the group key handshake. b) Verifies that the MIC is valid, i.e., it uses the KCK that is part of the PTK to verify that there is no data integrity error. 12.7.7.4 Group key handshake implementation considerations If the Authenticator does not receive a reply to its messages, its shall attempt dot11RSNAConfigGroupUpdateCount transmits of the message, plus a final timeout. The retransmit timeout value shall be 100 ms for the first timeout, half the listen interval for the second timeout, and the listen interval for subsequent timeouts. If there is no listen interval or the listen interval is zero, then 100 ms shall be used for all timeout values. If it still has not received a response after this, then the Authenticatorâ€™s STA should use the MLME-DEAUTHENTICATE.request primitive to deauthenticate the STA. 12.7.7.5 Sample group key handshake The following is an informative sample of a group key handshake for illustration. The state machines in 12.7.10 and 12.7.11 change the GTK and, when present, IGTK in use by the network. See Figure 12-47. 2042 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications IEEE Std 802.11 Station IEEE Std 802.11Access Point IEEE Std 802.1X Supplicant IEEE Std 802.1X Authenticator Gnonce = Get Next Key Counter EAPOL-Key( 1,1,1,0,GNonce,0, KeyRSC, 0, MIC, GTK[KeyIDGTK], IGTK[KeyIDIGTK]) Decrypt GTK and set KeyIDGTK Decrypt IGTK and set KeyIDIGTK EAPOL-Key( 1,1,0,0,GNonce,0, 0, 0, MIC,0) Set GTK in KeyIDGTK Set IGTK in KeyIDIGTK Figure 12-47â€”Sample group key handshake The following steps occur: a) The Authenticator generates a new GTK and when management frame protection has been negotiated, a new IGTK. It encapsulates the GTK and, as necessary, the IGTK, and sends an EAPOL-Key frame containing the GTK and IGTK (message 1), along with the last TSC or PN used with the GTK (RSC) and the last IPN used with the IGTK. b) On receiving the EAPOL-Key frame, the Supplicant validates the MIC, decapsulates the GTK and, when present, the IGTK, and uses the MLME-SETKEYS.request primitive to configure the GTK, PN, IGTK, RSC, and IPN in its STA. c) The Supplicant then constructs and sends an EAPOL-Key frame in acknowledgment to the Authenticator. d) On receiving the EAPOL-Key frame, the Authenticator validates the MIC. If the GTK and, if present, the IGTK are is not already configured into IEEE 802.11 MAC, after the Authenticator has delivered the GTK and IGTK to all associated STAs, it uses the MLME-SETKEYS.request primitive to configure the GTK and IGTK. 12.7.8 PeerKey handshake 12.7.8.1 General The PeerKey handshake occurs after any other STSL setup procedures and is used to create an STKSA providing data confidentiality between the two STAs. The AP establishes an RSNA with each STA prior to PeerKey setup. The initiator STA starts the PeerKey handshake, at the conclusion of which a key is established to secure the connection. STSL security PeerKey handshake is used to establish security for Data frames passed directly between two STAs associated with the same AP. The AP establishes an RSNA with each STA prior to the PeerKey handshake. After the STAs establish the STSL, the initiator STA starts the PeerKey handshake, at the conclusion of which a key is established to secure the connection. The PeerKey handshake is used to create an STKSA between the two STAs. The PeerKey EAPOL-Key exchange provides a mechanism for obtaining the keys to be used for direct station-to-station communication. The initiator STA shall start a timer when it sends the first EAPOL-Key 2043 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications frame, and the peer STA shall do the same on receipt of the first EAPOL-Key frame. On expiration of this timer, the STA shall transition to the STKINIT state. A STA should use the PeerKey handshake prior to transferring any direct station-to-station Data frames. The STKSA should be deleted when the station-to-station connection is terminated. Here, the following assumptions apply: â€” EAPOL-Key() denotes an EAPOL-Key frame conveying the specified argument list, using the notation introduced in 12.7.4. â€” STA_I is the initiator STA. â€” STA_P is the peer STA. â€” AP is the access point with which both the STA_I and the STA_P are associated. â€” MAC_I is the MAC address of the STA_I. â€” MAC_P is the MAC address of the STA_I. â€” INonce is the nonce generated by the STA_I. â€” PNonce is the nonce generated by the STA_P. The PeerKey handshake has two components: a) SMK handshake: This handshake is initiated by the initiator STA, and as a result of this handshake, the SMKSA is installed in both the STAs. This message exchange goes through the AP and is protected using the PTK. b) 4-way STK handshake: Using the installed SMKSA, the initiator STA initiates the 4-way handshake (per 12.7.6), and as a result of this, the STKSA gets installed in both the STAs. The STKSA is used for securing data exchange between the initiator STA and the peer STA. The 4-way handshake analysis described in 12.7.6.8 applies to the 4-way STK handshake. 12.7.8.2 SMK handshake 12.7.8.2.1 General The initiator STA initiates the SMK handshake by sending the first message to the AP to establish an SMKSA between itself and another STA associated with the same AP. Unlike the 4-way handshake and the group key handshake, the SMK handshake is initiated by the initiator STA. Message 1: Initiator STA AP: EAPOL-Key(1,1,0,0,0,1,0, INonce, MIC, RSNE_I, MAC_P KDE) Message 2: AP Peer STA: EAPOL-Key(1,1,1,0,0,1,0, INonce, MIC, RSNE_I, MAC_I KDE) Message 3: Peer STA AP: EAPOL-Key(1,1,0,0,0,1,0, PNonce, MIC, RSNE_P, MAC_I KDE, Initiator Nonce KDE) Message 4: AP Peer STA: EAPOL-Key(1,1,0,1,0,1,0, PNonce, MIC, MAC_I KDE, Initiator Nonce KDE, SMK KDE, Lifetime KDE) Message 5: AP Initiator STA: EAPOL-Key(1,1,0,0,0,1,0, INonce, MIC, RSNE_P, MAC_P KDE, Peer Nonce KDE, SMK KDE, Lifetime KDE) 12.7.8.2.2 SMK handshake message 1 The initiator STA creates the RSNE (see 9.4.2.25) by including the Element ID, length, version, and pairwise cipher suite list fields. Since the group cipher suit field is before the pairwise cipher suite list field (so the STA needs to include it), the STA includes any value in this field, and the receiving STA ignores it. The initiator STA also generates a 256-bit random number following the recommendations of 12.7.5. That number is sent in the Key Nonce field. 2044 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Message 1 uses the following values for each of the EAPOL-Key frame fields: Descriptor Type = N â€“ see 12.7.2 Key Information: Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap with HMAC-SHA-1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all other cases 0 Key Type = 0 (Group/SMK) SMK Message = 1 (SMK) Install = 0 Key Ack = 0 Key MIC = 1 Secure = 1 Error = 0 Request = 1 Encrypted Key Data = 0 Reserved = 0 Key Length = 0 Key Replay Counter = request EAPOL replay counter of initiating STA Key Nonce = INonce EAPOL-Key IV = 0 Key RSC = 0 Key MIC = MIC (initiating STAâ€™s KCK, EAPOL) Key Data Length = Length of Key Data field in octets Key Data = Initiator RSNE, peer MAC address KDE The STA_I sends message 1 to the AP. On receipt of message 1, the AP checks that the key replay counter corresponds to message 1. If not, it silently discards the message. Otherwise: a) The AP verifies the message 1 MIC using the STA_I PTKSA. If the calculated MIC does not match the MIC that the STA_I included in the EAPOL-Key frame, the AP silently discards message 1. b) If the MIC is correct, the AP checks if the STA_P is reachable. If it is not reachable, the AP shall send an error EAPOL-Key frame to STA_I per 12.7.8.5.2. After sending the message, AP silently discards message 1. c) The AP checks if the AP has a secure connection with STA_P. If not, the AP shall send an error EAPOL-Key frame to STA_I per 12.7.8.5.3. After sending the message, AP silently discards message 1. d) If all checks succeed, the AP creates message 2 using the STA_P PTKSA. The AP copies the contents of message 1 to create message 2. 12.7.8.2.3 SMK handshake message 2 Message 2 uses the following values for each of the EAPOL-Key frame fields: Descriptor Type = N â€“ see 12.7.2 Key Information: 2045 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap with HMAC-SHA-1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all other cases 0 Key Type = 0 (Group/SMK) SMK Message = 1 (SMK) Install = 0 Key Ack = 1 Key MIC = 1 Secure = 1 Error = 0 Request = 0 Encrypted Key Data = 0 Reserved = 0 Key Length = 0 Key Replay Counter = request EAPOL replay counter of AP and STA_P Key Nonce = INonce EAPOL-Key IV = 0 Key RSC = 0 Key MIC = MIC (KCK of the STA_P, EAPOL) Key Data Length = Length of Key Data field in octets Key Data = Initiator RSNE, initiator MAC address KDE The AP sends message 2 to the STA_P. On receipt of message 2, the STA_P checks that the key replay counter corresponds to message 2. If not, it silently discards the message. Otherwise, a) The STA_P verifies the message 2 MIC using the STA_P PTKSA. If the calculated MIC does not match the MIC that the AP included in the EAPOL-Key frame, the STA_P silently discards message 2. b) If the MIC is correct, the STA_P checks if it supports at least one cipher suites proposed by the STA_I. If it does not, the STA_P shall send an error EAPOL-Key frame to STA_I through the AP per 12.7.8.5.4. After sending the error message, the STA_P silently discards message 2. c) STA_O checks if it has already created an STSL with STA_I. If it has not, STA_P shall send an error EAPOL-Key frame to STA_I through the AP per 12.7.8.5.5. After sending the error message, the STA_P silently discards message 2. d) If all checks succeed, the STA_P creates the state of PeerKey handshake and stores the INonce and the RSNE received in message 2. e) STA_P selects a support cipher suite from the cipher suite list proposed by the STA_I and creates the peer RSNE, which is sent with message 3. f) STA_P generates a 256-bit random number following the recommendations of 12.7.5. That number is sent as the peer Nonce KDE with message 3. g) Using all the information, STA_P creates message 3. 12.7.8.2.4 SMK handshake message 3 Message 3 uses the following values for each of the EAPOL-Key frame fields: Descriptor Type = N â€“ see 12.7.2 Key Information: 2046 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap with HMAC-SHA-1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all other cases 0 Key Type = 0 (Group/SMK) SMK Message = 1 (SMK) Install = 0 Key Ack = 0 Key MIC = 1 Secure = 1 Error = 0 Request = 0 Encrypted Key Data = 0 Reserved = 0 Key Length = 0 Key Replay Counter = request EAPOL replay counter of peer STA Key Nonce = PNonce EAPOL-Key IV = 0 Key RSC = 0 Key MIC = MIC (KCK of STA_I, EAPOL) Key Data Length = Length of Key Data field in octets Key Data = Peer RSNE, initiator MAC address KDE, initiator Nonce KDE The STA_P sends message 3 to the AP. On receipt of message 3, the AP checks that the key replay counter corresponds to message 3. If not, it silently discards the message. Otherwise, a) The AP verifies the message 1 MIC using the STA_I PTKSA. If the calculated MIC does not match the MIC that the STA_P included in the EAPOL-Key frame, the AP silently discards message 1. b) If MIC is correct, the AP checks if the STA_I is reachable. If it is not reachable, the AP shall send an error EAPOL-Key frame to the STA_P per 12.7.8.5.2. After sending the message, the AP silently discards message 3. c) The AP checks if the AP has secure connection with STA_I. If it does not, the AP shall send an error EAPOL-Key frame to STA_P per 12.7.8.5.3. After sending the message, the AP silently discards message 3. d) If all checks succeed, the AP generates a 256-bit random number drawn from a uniform distribution that is used as the SMK, which is sent with message 4 and message 5 as SMK KDEs. e) Depending on the strength of random number generator, the AP sets the lifetime of the SMK, which is sent with message 4 and message 5 as Lifetime KDEs. f) Using all the information, the AP creates message 4 and message 5. 12.7.8.2.5 SMK handshake message 4 Message 4 uses the following values for each of the EAPOL-Key frame fields: Descriptor Type = N â€“ see 12.7.2 Key Information: Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap with HMAC-SHA-1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all other cases 0 Key Type = 0 (Group/SMK) 2047 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications SMK Message = 1 (SMK) Install = 1 Key Ack = 0 Key MIC = 1 Secure = 1 Error = 0 Request = 0 Encrypted Key Data = 1 Reserved = 0 Key Length = Cipher-suite-specific; see Table 12-4 Key Replay Counter = request EAPOL replay counter of AP Key Nonce = PNonce EAPOL-Key IV = 0 Key RSC = 0 Key MIC = MIC (KCK of the STA_I, EAPOL) Key Data Length = Length of Key Data field in octets Key Data = Encrypted initiator MAC address KDE, Initiator Nonce KDE, SMK KDE (contains SMK and PNonce), Lifetime KDE The AP sends message 4 to the STA_P. On receipt of message 4, the STA_P checks that the key replay counter corresponds to message 4. If it does not, STA_P silently discards the message. Otherwise, a) The STA_P verifies the message 4 MIC using STA_P PTKSA. If the calculated MIC does not match the MIC that the AP included in the EAPOL-Key frame, the STA_P silently discards message 4. b) If the MIC is correct, STA_P identifies the PeerKey session using the PNonce sent as part of the Key Nonce field of message 4. If STA_P has an existing PeerKey state for this session, i.e., STA_P has received message 2 and this message is a follow-up to that. If STA_P has an existing PeerKey state for this session, STA_P silently discards message 4. c) If all checks succeed, STA_P decrypts the Key Data field of message 4 and extracts the MAC_I, the INonce, the PNonce, the SMK, and the lifetime from message 4. The STA_P verifies the extracted INonce against the INonce originally received as part of message 2. d) The STA_P calculates the SMKID per 12.7.1.6. e) The STA_P checks the value of the lifetime with the maximum value it can support. If the lifetime suggested by the AP is too long, the STA_P selects a lower value that it can support. f) Using all the information, the STA_P creates the SMKSA for this PeerKey session. 12.7.8.2.6 SMK handshake message 5 Message 5 uses the following values for each of the EAPOL-Key frame fields: Descriptor Type = N â€“ see 12.7.2 Key Information: Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap with HMAC-SHA-1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all other cases 0 Key Type = 0 (Group/SMK) SMK Message = 1 (SMK) Install = 0 2048 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Key Ack = 0 Key MIC = 1 Secure = 1 Error = 0 Request = 0 Encrypted Key Data = 1 Reserved = 0 Key Length = Cipher-suite-specific; see Table 12-4 Key Replay Counter = request EAPOL replay counter of AP Key Nonce = INonce EAPOL-Key IV = 0 Key RSC = 0 Key MIC = MIC (KCK of the STA_I, EAPOL) Key Data Length = Length of Key Data field in octets Key Data = Encrypted peer RSNE, peer MAC address KDE, peer Nonce KDE, SMK KDE (contains SMK and INonce), Lifetime KDE The AP sends message 5 to the STA_I. On receipt of message 5, the STA_I checks that the key replay counter corresponds to message 5. If it does not, the STA_I silently discards the message. Otherwise, a) STA_I verifies the message 4 MIC using STA P PTKSA. If the calculated MIC does not match the MIC that the AP included in the EAPOL-Key frame, the STA_I silently discards message 5. b) If the MIC is correct, the STA_I identifies the PeerKey session using the INonce sent as part of the Key Nonce field of message 5. If STA_I has an existing PeerKey state for this session, i.e., STA_I has initiated this message exchange using message 1 and this message is a follow-up to that. If STA_I has an existing PeerKey state for this session, STA_I shall silently discard message 5. c) If all checks succeed, STA_I decrypts the Key Data field of message 5 and extracts the peer RSNE, the MAC_P, the INonce, the PNonce, the SMK, and the lifetime from message 5. d) The STA_I verifies that the peer RSNE includes a valid cipher (i.e., one that was included in an initiator RSNE). If not, STA_I discards the message and sends an Error KDE ERR_CPHR_NS. e) The STA_I calculates SMKID per 12.7.1.6. f) The STA_I checks the value of the lifetime with the maximum value it can support. If the lifetime suggested by the AP is too long, STA_I selects a lower value that can support. g) Using all the information, the STA_I creates the SMKSA for this PeerKey session. 12.7.8.3 PeerKey setup and handshake error conditions If the STA_P does not receive a valid SMK message 2 or a 4-way STK message 1 after sending the EAPOL- Key request frame to initiate the PeerKey rekey within a 200 ms timeout, the STA_P shall invoke an STSL application teardown procedure. If the STA_I does not receive an SMK message 5 from the AP, the STA_I shall attempt dot11RSNAConfigSMKUpdateCount transmits of the SMK handshake message 1 plus a final timeout. If the STA_I still has not received a response after these retries, it shall invoke an STSL application teardown procedure. The retransmit timeout value shall be 200 ms for the first timeout, the listen interval for the second timeout, and twice the listen interval for subsequent timeouts. If there is no listen interval or the listen interval is zero, then 200 ms shall be used for all timeout values. 2049 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications There is no specific recovery mechanism at the AP if the SMK message 3 is dropped. This results in a timeout by the STA_I after nonreceipt of SMK message 5, as described in the preceding paragraph. If the SMK message 4 is not received by the STA_P, a failure is detected during the 4-way STK handshake. In this case, the STA_P discards the EAPOL-Key frames without the proper key. This failure is covered by behavior described in 12.7.6.6 and results in teardown of the STSL. Upon receipt of the SMK message 5, the STA_I transmits message 1 of the 4-way STK handshake to the STA_P. If the STA_I does not receive message 2 of the 4-way STK handshake from the STA_P, it shall attempt dot11RSNAConfigSMKUpdateCount transmits of 4-way STK handshake message 1, plus a final timeout. If STA_I still has not received a response after these retries, it shall invoke an STSL application teardown procedure. The retransmit timeout value shall be 100 ms for the first timeout, half the listen interval for the second timeout, and the listen interval for subsequent timeouts. If there is no listen interval or the listen interval is zero, then 100 ms shall be used for all timeout values. There is no specific recovery mechanism at the STA_P if the SMK message 3 is lost. This results in a timeout on the STA_I, as described in the preceding paragraph, and a subsequent reinitiation of the SMK handshake. The STA_P shall allow reinitiation of the SMK handshake at any point prior to receipt of SMK message 4. 12.7.8.4 STKSA rekeying Rekeying is always initiated by the STA_I. When needed, the STA_P sends an EAPOL-Key request frame to the STA_I to request rekeying. The STA_P shall wait a minimum of one half the IEEE 802.1X timeout after the STSL setup before initiating a PeerKey rekey procedure. To perform rekeying, there are two cases: a) If SMK timer has not expired, the STAs initiate a 4-way handshake to create a new STK. The 4-way handshake is always initiated by the STA_I. In this case, the STA_P should not delete any existing STKSA prior to verifying message 3 of the 4-way handshake with STA_I for this session. b) If the SMK has expired, the STA_I shall not use an existing STKSA and shall start the SMK handshake followed by a 4-way handshake to create new keys. The format of the EAPOL-Key request frame in case a) from STA_P to STA_I is as follows: Request message: STA_P STA_I: EAPOL-Key(1,1,0,0,1,0,0,0, MIC, PMKID KDE) The request message uses the following values for each of the EAPOL-Key frame fields: Descriptor Type = N â€“ see 12.7.2 Key Information: Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap with HMAC-SHA-1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all other cases 0 Key Type = 1 (PTK) SMK Message = 0 Install = 0 Key Ack = 0 Key MIC = 1 Secure = 1 Error = 0 Request = 1 Encrypted Key Data = 0 2050 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Reserved = 0 Key Length = 0 Key Replay Counter = request replay counter of peer STA Key Nonce = 0 EAPOL-Key IV = 0 Key RSC = 0 Key MIC = MIC computed over the body of this EAPOL-Key frame Key Data Length = Length of Key Data field in octets Key Data = SMKID in SMKID KDE 12.7.8.5 Error reporting 12.7.8.5.1 General Error reporting messages are defined in this subclause and used to report errors whenever STAs or an AP detect an error during the SMK handshake. The AP, upon receiving the error messages defined in this subclause or upon generating the error messages defined in this subclause, should log the error. The STA, upon receipt of the error messages defined in this subclause, shall tear down the STSL with the other STA and clear all of the PeerKey states. The format of EAPOL-Key request frame for reporting an error message is as follows: Error message: EAPOL-Key(1,1,0,0,0,1,0, 0, MIC, Error KDE, MAC Address KDE). The request message uses the following values for each of the EAPOL-Key frame fields: Descriptor Type = N â€“ see 12.7.2 Key Information: Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap with HMAC-SHA-1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all other cases 0 Key Type = 0 (Group/SMK) SMK Message = 1 (SMK) Install = 0 Key Ack = 0 Key MIC = 1 Secure = 1 Error = 1 Request = 1 when the message is going from the STA to an AP or 0 when the message is going from an AP to the STA Encrypted Key Data = 0 Reserved = 0 Key Length = 0 Key Replay Counter = request EAPOL replay counter Key Nonce = 0 EAPOL-Key IV = 0 Key RSC = 0 2051 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Key MIC = MIC computed over the body of this EAPOL-Key frame Key Data Length = Length of Key Data field in octets Key Data = Error KDE (different types defined in Table 12-7), MAC Address KDE 12.7.8.5.2 Error ERR_STA_NR This error message is sent whenever an AP finds that the STA to which it needs to send a message is not reachable. In response to this error, the AP creates an Error KDE with error type ERR_STA_NR and sends the message back to the other STA involved in the handshake. The MAC address KDE contains the MAC address of the unreachable STA. 12.7.8.5.3 Error ERR_STA_NRSN This error message is sent whenever the AP finds that the STA to which it needs to send the message does not have a secure RSNA connection. In response of this error, the AP creates an Error KDE with error type ERR_STA_NRSN and sends the message back to the STA from which it received the last message. The MAC address KDE contains the MAC address of the STA with which the AP does not have a secure RSNA connection. 12.7.8.5.4 Error ERR_CPHR_NS This error message is sent whenever a STA finds that it does not support any of the cipher suites proposed by the other STA. In response to this error, the STA creates an Error KDE with error type ERR_CPHR_NS and sends the message back to the other STA. The MAC address KDE contains the MAC address of the other STA. 12.7.8.5.5 Error ERR_NO_STSL This error message is sent whenever a STA finds that it does not have an existing STSL with the other STA. In response of this error, the STA creates an Error KDE with error type ERR_NO_STSL and sends the message back to the other STA. The MAC address KDE contains the MAC address of the other STA. 12.7.9 TDLS PeerKey (TPK) security protocol 12.7.9.1 General The TPK security protocol is executed between the two non-AP STAs that intend to establish an RSNA for direct-link communication. If any security method (pre-RSNA or RSNA) is enabled on the connection between a STA and the AP, the STA shall require that the TPK security protocol complete successfully before using a direct link. If no security method is enabled on the connection between a STA and the AP, the STA shall not use the TPK security protocol on the direct link. A STA may refuse to set up a TDLS link when the protection on the STA link to the AP is secured with a weak algorithm or when the link between the STA and the AP is not using any security. 12.7.9.2 TPK handshake The TPK handshake occurs as part of the TDLS direct-link setup procedure. The TPKSA is the result of the successful completion of the TPK handshake protocol, which derives keys for providing confidentiality and data origin authentication. In order to maintain TPK confidentiality, both the TDLS initiator STA and the TDLS responder STAs establish an RSNA with their common AP prior to executing the TPK handshake. To meet this criterion, a STA may refuse to initiate the TDLS direct link if: 2052 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications a) The AP does not include an RSNE in its Beacon and Probe Response frames to advertise the availability of security; b) The APâ€™s RSNE indicates that WEP-40 (OUI 00-0F-AC:1) or WEP-104 (OUI 00-0F-AC:5) are enabled as either pairwise or group cipher suites; or c) The APâ€™s RSNE indicates that Use group cipher suite (00-0F-AC:0) is used as the pairwise cipher suite. Violation of any of these cases would cause the TPK handshake to leak the TPK. The TDLS initiator STA and the TDLS responder STA perform the following exchange to set up a TPK: TDLS PMK handshake message 1: TDLS initiator STA TDLS responder STA: Link Identifier element, RSNE, Timeout Interval element, FTE TDLS PMK handshake message 2: TDLS responder STA TDLS initiator STA: Link Identifier element, RSNE, Timeout Interval element, FTE TDLS PMK handshake message 3: TDLS initiator STA TDLS responder STA: Link Identifier element, RSNE, Timeout Interval element, FTE where The TDLS initiator STA Address field of the Link Identifier element is the MAC address of the TDLS ini- tiator STA The TDLS responder STA Address field of the Link Identifier element is the MAC address of the TDLS responder STA The PairwiseCipherSuite field of the RSNE identifies the cipher suite used to protect the Data frames sent over the direct link The AKM suite list of the RSNE identifies which Authentication Method was used The TimeoutIntervalType field of the Timeout Interval element is the key lifetime The SNonce field of the FTE is a 256 bit value randomly generated by the TDLS initiator STA The ANonce field of the FTE is a 256 bit value randomly generated by the TDLS responder STA (set to 0 in message 1) The MIC field of the FTE is 0 for message 1 and computed as described in 12.7.9.4.3 and 12.7.9.4.4 for messages 2 and 3 respectively The TDLS PMK handshake message 1 shall be transmitted in the TDLS Setup Request frame. TDLS PMK handshake message 2 shall be transmitted in the TDLS Setup Response frame. TDLS PMK handshake message 3 shall be transmitted in the TDLS Setup Confirm frame. The TPK shall be derived as follows: TPK-Key-Input = Hash(min (SNonce, ANonce) || max (SNonce, ANonce)) TPK = KDF-Hash-Length(TPK-Key-Input, "TDLS PMK", min (MAC_I, MAC_R) || max (MAC_I, MAC_R) || BSSID) where Hash is the hash algorithm identified by the negotiated AKM suite selector specified in Table 9-133 KDF-Hash-Length is the key derivation function defined in 12.7.1.7.2 that uses Hash to generate a key whose length is TK_bits + 128 TK_bits is cipher-suite specific and specified in Table 12-4 2053 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MAC_I and MAC_R are the MAC addresses of the TDLS initiator STA and the TDLS responder STA, respectively SNonce and ANonce are the nonces generated by the TDLS initiator STA and TDLS responder STA, respectively, for this instance of the TPK handshake. The BSSID is set to the BSSID of the current association of the TDLS initiator STA. Each TPK has two component keysâ€”TPK-KCK and TPK-TK, defined as follows: The Key Confirmation Key (KCK) shall be computed as the first 128 bits (bits 0â€“127) of the TPK TPK-KCK = L(TPK, 0, 128) The KCK is used to provide data origin authenticity in TDLS Setup Response and TDLS Setup Confirm frames. The temporal key (TK) shall be computed as the remaining bits (for CCMP-128, the second 128 bits, i.e., bits 128â€“255) of the TPK TPK-TK = L(TPK, 128, Length â€“ 128) The TPK-TK is used to provide confidentiality for direct-link data. The temporal key is configured into the STA by the SME through the use of the MLME-SETKEYS.request primitive. 12.7.9.3 TPK handshake security assumptions The security of the TDLS PMK handshake depends on the following: a) The TDLS initiator STA and the TDLS peer STA each have an RSNA established with the AP that is being used for TDLS Setup. b) The AP does not expose the nonces exchanged by the TDLS initiator STA and the TDLS responder STA to any external party. c) The AP does not use these nonces to derive the TPK and attack the TDLS direct-link instance. d) TDLS message security (encryption and integrity computations) processing at the AP is protected from illegal eavesdropping, alterations, insertions and substitutions. e) The TDLS initiator STA and TDLS responder STAs do not expose SNonce, ANonce, or the derived key to a third party. f) The TDLS initiator STA and the TDLS peer STA are associated to the same AP. 12.7.9.4 TPK Security Protocol handshake messages 12.7.9.4.1 Overview The TPK handshake consists of three messages. Each message comprises a number of elements and is included in the TDLS Setup Request, TDLS Setup Response, and TDLS Setup Confirm. In an RSN, these handshake messages serve to provide a session identifier, are identified by the nonces, and are used as association instance identifiers. These nonces are chosen randomly or pseudorandomly, and are used to generate the TPK. 2054 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 12.7.9.4.2 TPK handshake message 1 If the TDLS initiator STA has security enabled on the link with the AP, it shall add an RSNE, FTE, and Timeout Interval element to its TDLS Setup Request frame. The elements shall be formatted as follows: The RSNE, if present, shall be set as follows: Version shall be set to 1. The pairwise cipher suite list field indicating the pairwise cipher suites the TDLS initiator STA is willing to use with the TPKSA. WEP-40, WEP-104, and TKIP shall not be included in this list. The group cipher suite shall be set to 00-0F-AC:7. The AKM suite count field shall be set to 1. The AKM suite list field shall be set to indicate TPK handshake (00-0F-AC:7). In the RSN Capabilities field, the No Pairwise subfield shall be set to 0 and the PeerKey Enabled subfield shall be set to 1. PMKID Count subfield, if present, shall be set to 0. PMKID list shall not be present. The Group Management Cipher Suite subfield, if present, shall be set to 00-0F-AC:7. The Timeout Interval element indicates the lifetime of the TPKSA. The Lifetime Interval Type shall be set to â€˜2â€™ (Key Lifetime Interval). The minimum lifetime shall be 300 seconds. The FTE shall be set as follows: SNonce shall be set to a value chosen randomly by the TDLS initiator STA, following the recommendations of 12.7.5. All other fields shall be set to 0. The TDLS initiator STA sends message 1 to the TDLS responder STA. On reception of message 1, the TDLS responder STA checks whether the RSNE is present. If the TDLS responder STA does not have security enabled on the link with the AP, it shall reject the request with status code SECURITY_DISABLED. If the TDLS responder STA has security enabled on the link with the AP, it checks whether the request includes an RSNE and FTE. If not, the TDLS responder STA shall reject the request with status code INVALID_PARAMETERS. If the version field of the RSNE is 0, then the TDLS responder STA shall reject the request with status code UNSUPPORTED_RSNE_VERSION. Otherwise, the TDLS responder STA processes the message as follows: If the contents of the RSNE do not indicate AKM of TPK handshake (suite type 00-0F-AC:7), the TDLS responder STA shall reject the request with status code STATUS_INVALID_AKMP. If none of the pairwise cipher suites are acceptable, or pairwise ciphers include WEP-40, WEP- 104, or TKIP, then the TDLS responder STA shall reject the TDLS Setup Request frame with status code STATUS_INVALID_PAIRWISE_CIPHER. If the RSN Capabilities field has not set the subfields according to the described rules for this message, then the TDLS responder STA rejects with status code INVALID_RSNE_CAPABILITIES. If the suggested lifetime is unacceptable or below the default value, the TDLS responder STA shall reject the TDLS Setup Request frame with status code UNACCEPTABLE_LIFETIME. If the contents of the FTE are not as per specified for this message, then the TDLS responder STA shall reject the TDLS Setup Request frame with status code STATUS_INVALID_FTE. 2055 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The TDLS responder STA shall ignore the remaining fields in the RSNE, FTE, and Timeout Interval element. Otherwise, the TDLS responder STA shall respond as specified in 11.23.4. 12.7.9.4.3 TPK handshake message 2 If the TDLS responder STA validates the TPK handshake message 1 for this TDLS instance, the TDLS responder STA may respond with TPK handshake message 2. To do so, the TDLS responder STA shall add an RSNE, FTE, and Timeout Interval element to its TDLS Setup Response frame. The elements shall be formatted as follows: The RSNE shall include the following: Include a pairwise cipher suite from one of those presented in RSNE of message 1 of this sequence in the pairwise cipher suite list, and set the pairwise cipher suite count to 1. The version number shall be the minimum of the maximum version supported by the TDLS responder STA and the version number received in the RSNE of message 1. All other RSNE fields shall be same as those received in message 1. The Timeout Interval element shall be the same as that received in the TPK handshake message 1. The FTE shall include the following: ANonce shall be set to a value chosen randomly by the TDLS responder STA, following the recommendations of 12.7.5. SNonce shall be same as that received in message 1 of this sequence The MIC shall be calculated on the concatenation, in the following order, of: TDLS initiator STA MAC address (6 octets) TDLS responder STA MAC address (6 octets) Transaction Sequence number (1 octet) which shall be set to the value 2 Link Identifier element RSNE Timeout Interval element FTE, with the MIC field of the FTE set to 0. The MIC shall be calculated using the TPK-KCK and the AES-128-CMAC algorithm. The output of the AES-128-CMAC shall be 128 bits. All other fields shall be set to 0. The TDLS responder STA shall use the MLME-SETKEYS.request primitive to configure the Temporal Key into its STA prior to sending message 2. The TDLS responder STA sends message 2 to the TDLS initiator STA. The TDLS initiator STA shall process message 2 as follows: If the TDLS initiator STA Address and TDLS responder STA Address of the Link Identifier element do not match those for an outstanding TDLS Setup Request, the TDLS initiator STA shall silently discard the received TDLS Setup Response frame. If the SNonce field of the FTE does not match that of an outstanding request to the TDLS responder STA, then the TDLS initiator STA shall silently discard the received TDLS Setup Response frame. Otherwise, the TDLS initiator STA shall compute the TPK and then validate the MIC in the FTE as specified in MIC calculation procedure for TPK handshake message 2. If invalid, the TDLS initiator STA shall discard the message. 2056 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If the version of the RSNE is 0 or is greater than the version of the RSNE sent in message 1, then the TDLS initiator STA shall reject the response with status code UNSUPPORTED_RSNE_VERSION. Otherwise, If the contents of the RSNE, with the exception of the pairwise cipher suite count and pairwise cipher suite list are not the same as those sent by the TDLS initiator STA in message 1 of this sequence, then the TDLS initiator STA shall reject the response with status code INVALID_RSNE. If the pairwise cipher suite count is other than 1, then the TDLS initiator STA shall reject the response with status code STATUS_INVALID_PAIRWISE_CIPHER. If the selected pairwise cipher suite was not included in the Initiatorâ€™s request, then the TDLS initiator STA shall reject the TDLS Setup Response frame with status code STATUS_INVALID_PAIRWISE_CIPHER. If the Timeout Interval element is not the same as that sent in message 1, the TDLS initiator STA shall reject the TDLS Setup Response frame with status code UNACCEPTABLE_LIFETIME. If the BSSID in the Link Identifier element is different from the one sent in message 1, then the TDLS initiator STA shall reject the response with status code NOT_IN_SAME_BSS. If the TDLS initiator STA validates TDLS message 2, the TDLS initiator STA shall create a TPKSA and respond with message 3 as defined in 11.23.4. The TDLS initiator STA shall use the MLME- SETKEYS.request primitive to configure the Temporal Key into its STA prior to sending message 3. 12.7.9.4.4 TPK handshake message 3 If the TDLS initiator STA responds to message 2 for this TDLS instance, the TDLS initiator STA shall add an RSNE, FTE, and Timeout Interval element to its TDLS Setup Confirm frame. The elements shall be formatted as follows: The RSNE shall be the same as the RSNE received in message 2. The Timeout Interval element shall be the same as that received in the TPK handshake message 2. With the exception of the MIC field, the contents of the FTE shall be the same as the FTE received in message 2. The MIC shall be calculated on the concatenation, in the following order, of: TDLS initiator STA MAC address (6 octets) TDLS responder STA MAC address (6 octets) Transaction Sequence number (1 octet), which shall be set to the value 3 Link Identifier element RSNE Timeout Interval element FTE, with the MIC field of the FTE set to 0. The MIC shall be calculated using the TPK-KCK and the AES-128-CMAC algorithm. The output of the AES-128-CMAC shall be 128 bits. All other fields shall be set to 0. The TDLS initiator STA sends message 3 to the TDLS responder STA. The TDLS responder STA shall process message 3 as follows: If the Source and Destination Addresses of the Link Identifier element do not match those for an outstanding TDLS Setup Request, the TDLS responder STA shall discard the message. If the ANonce and SNonce fields of the FTE do not match that of an outstanding request to the TDLS initiator STA, then the TDLS responder STA shall discard the message. 2057 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Otherwise, the TDLS responder STA shall validate the MIC in the FTE as specified in the MIC calculation procedure for TPK handshake message 3. If invalid, the TDLS responder STA shall discard the message. The TDLS responder STA shall discard the message, the TDLS responder STA shall abandon the TPK handshake identified by the combination, and delete existing TPK handshake key state for this sequence if any of the following checks fail: The contents of the RSNE are not the same as that sent by the TDLS responder STA in message 2 The Timeout Interval element is not the same as that sent in message 2 The BSSID from the Link Identifier element is not the same as that sent in message 2 On successful processing of message 3, the TPK handshake is considered successful. The TPKSA shall be deleted by the TDLS responder STA if it does not receive a valid TPK handshake message 3 from the TDLS Initiator STA within dot11TDLSResponseTimeout. 12.7.9.5 Supplicant state machine procedures The following list summarizes the procedures used by the Supplicant state machine: â€” STADisconnect â€“ The Supplicant invokes this procedure to disassociate and deauthenticate its STA from the AP. â€” MIC(x) â€“ The Supplicant invokes this procedure to compute a MIC of the data x. â€” CheckMIC() â€“ The Supplicant invokes this procedure to verify a MIC computed by the MIC() function. â€” StaProcessEAPOL-Key â€“ The Supplicant invokes this procedure to process a received EAPOL- Key frame. The pseudocode for this procedure is as follows: StaProcessEAPOL-Key (S, M, A, I, K, RSC, ANonce, RSC, MIC, RSNE, GTK[N], IGTK[M], IPN) TPTK PTK TSNonce 0 PRSC 0 UpdatePTK 0 State UNKNOWN if M = 1 then if Check MIC(PTK, EAPOL-Key frame) fails then State FAILED else State MICOK endif endif if K = P then if State FAILED then if PSK exists then â€“ PSK is a preshared key PMK PSK else PMK L(MSK, 0, PMK_bits) endif TSNonce SNonce if ANonce PreANonce then TPTK Calc PTK(PMK, ANonce, TSNonce) PreANonce ANonce endif 2058 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications if State = MICOK then PTK TPTK UpdatePTK I if UpdatePTK = 1 then if no GTK then PRSC RSC endif if MLME-SETKEYS.request(0, true, PRSC, PTK) fails then invoke MLME- DEAUTHENTICATE.request endif MLME-SETPROTECTION.request(TA, Rx) endif if GTK then if (GTK[N] Decrypt GTK) succeeds then if MLME-SETKEYS.request(N, 0, RSC, GTK[N]) fails then invoke MLME-DEAUTHENTICATE.request endif else State FAILED endif endif if IGTK then if (IGTK[M] Decrypt IGTK) succeeds then if MLME-SETKEYS.request(M, 0, IPN, IGTK[M]) fails then invoke MLME-DEAUTHENTICATE.request endif else State FAILED endif endif endif endif else if KeyData = GTK then if State = MICOK then if (GTK[N] Decrypt GTK) succeeds then if MLME-SETKEYS.request(N, T, RSC, GTK[N]) fails then invoke MLME-DEAUTHENTICATE.request endif else State FAILED endif if (IGTK[M] Decrypt IGTK) succeeds then if MLME-SETKEYS.request(M, T, IPN, IGTK[M]) fails then invoke MLME-DEAUTHENTICATE request endif else State FAILED endif else State FAILED endif endif if A = 1 && State Failed then 2059 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Send EAPOL-Key(0,1,0,0,K,0,0,TSNonce,MIC(TPTK),RSNE) endif if UpdatePTK = 1 then MLME-SETPROTECTION.request(TA, Rx_Tx) endif if State = MICOK && S = 1 then MLME-SETPROTECTION.request(TA, Rx_Tx) if IBSS then keycount++ if keycount = 2 then 802.1X::portValid true endif else 802.1X::portValid true endif endif Here UNKNOWN, MICOK, and FAILED are values of the variable State used in the Supplicant pseudocode. State is used to decide how to do the key processing. MICOK is set to 1 when the MIC of the EAPOL-Key has been checked and is valid. FAILED is used when a failure has occurred in processing the EAPOL-Key frame. UNKNOWN is the initial value of the variable State. When processing 4-way handshake message 3, the GTK and IGTK are decrypted from the EAPOL- Key frame and installed. The PTK shall be installed before the GTK and IGTK. The Key Replay Counter field used by the Supplicant for EAPOL-Key frames that are sent in response to a received EAPOL-Key frame shall be the received Key Replay Counter field. Invalid EAPOL-Key frames such as invalid MIC, GTK without a MIC, etc., shall be ignored. NOTE 1â€”TPTK is used to stop attackers changing the PTK on the Supplicant by sending the first message of the 4-way handshake. An attacker can still affect the 4-way handshake while the 4-way handshake is being carried out. NOTE 2â€”The PMK is supplied by the authentication method used with IEEE Std 802.1X-2010 if preshared mode is not used. NOTE 3â€”A PTK is configured into the encryption/integrity engine depending on the Tx/Rx bit, but if configured, is always a transmit key. A GTK is configured into the encryption/integrity engine independent of the state of the Tx/Rx bit, but whether the GTK is used as a transmit key is dependent on the state of the Tx/Rx bit. â€” CalcGTK(x) â€“ Generates the GTK. â€” DecryptGTK(x) â€“ Decrypt the GTK from the EAPOL-Key frame. â€” DecryptIGTK(x) â€“ Decrypt the IGTK from the EAPOL-Key frame. 12.7.9.6 Supplicant PeerKey state machine states Figure 12-48 depicts the PeerKey handshake Supplicant key management state machine. The following list summarizes the states the Supplicant state machine uses to support the PeerKey handshake: â€” STKINIT: This state is the idle state and is entered when the IEEE 802.1X Supplicant completes successful Authentication. â€” SMKNEGOTIATING1: This state is entered when the MLME-STKSTART.request primitive is received for the SMK handshake by the initiator STA. â€” SMKNEGOTIATING2: This state is entered when the first EAPOL-Key frame of the SMK handshake is received by the peer STA. â€” SMKNEGOTIATING3: This state is entered when the fifth EAPOL-Key frame of the SMK handshake is received by the initiator STA. â€” SMKNEGOTIATING4: This state is entered when the fourth EAPOL-Key frame of the SMK handshake is received by the peer STA. 2060 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications PeerKeyInit STKINIT TimeoutCtr=0 MLME-PEERKEY-START EAPOLKeyReceived && .request (STA_P, RSNE) SMKMesgNo == 2 && MICVerified TimeoutEvt SMKNEGOTIATING1 SMKNEGOTIATING2 TimeoutCtr >N Send EAPOL-Key (SMKMesgNo=1) Send EAPOL-Key(SMKMesgNo=3) TimeoutCtr++ to StkInit EAPOLKeyReceived&& EAPOLKeyReceived&& SMKMesgNo == 5 && SMKMesgNo== 4 && MICVerified MICVerified SMKNEGOTIATING3 SMKNEGOTIATING4 Install SMKSA Install SMKSA TimeoutCtr=0 EAPOLKeyReceived && TimeoutEvt UCT STKMesgNo== 1 STKCALCNEGOTIATING1 STKSTART TimeoutCtr >N Send EAPOL-Key (STKMesgNo=1) STKKey = Calc STK( INonce, TimeoutCtr++ PNonce) to StkInit EAPOLKeyReceived && STKMesgNo== 2 && UCT MICVerified STKCALCNEGOTIATING3 STKCALCNEGOTIATING STKKey = Calc STK( INonce, PNonce) Send EAPOL-Key (STKMesgNo=2) TimeoutCtr= 0 EAPOLKeyReceived&& TimeoutEvt UCT STKMesgNo == 3 && MICVerified STKCALCNEGOTIATING2 TimeoutCtr>N Send EAPOL-Key (STKMesgNo=3) TimeoutCtr++ STKCALCNEGOTIATING4 to StkInit Send EAPOL-Key (STKMesgNo=4) EAPOLKeyReceived && STKMesgNo== 4 && UCT MICVerified STKINITDONE If ( Initiator STA ) MLME- SETKEYS. request ( STKKey, length, 0, STA_P, 0, Initiator, RSNE) MLME- SETPROTECTION . request( STA_P, Rx_Tx, STK) Else MLME- SETKEYS. request( STKKey, length, 0, STA_I, 0, Peer, RSNE) MLME- SETPROTECTION . request( STA_I, Rx_ Tx, STK) Figure 12-48â€”PeerKey handshake Supplicant key management state machine 2061 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” STKSTART: Once the SMKSA is created, the initiator STA enters this state. This is the start of 4-Way STK handshake. â€” STKCALCNEGOTIATING: This state is entered when the second EAPOL-Key frame of the 4-Way STK handshake is received by the initiator STA and the MIC is verified. â€” STKCALCNEGOTIATING1: This state is entered when the first EAPOL-Key frame of the 4-Way STK handshake is received by the peer STA and the MIC is verified. â€” STKCALCNEGOTIATING2: This state is entered unconditionally by the initiator STA. â€” STKCALCNEGOTIATING3: This state is entered unconditionally by the peer STA. â€” STKCALCNEGOTIATING4: This state is entered when the third EAPOL-Key frame of the 4-Way STK handshake is received by the peer STA and the MIC is verified. â€” STKINITDONE: This state is entered by the initiator STA when the fourth EAPOL-Key frame of the 4-way STK handshake is received. This state is entered by the peer STA when the fourth EAPOL-Key frame of the 4-way STK handshake is sent. 12.7.9.7 Supplicant PeerKey state machine variables The following list summarizes the variables used by the Supplicant state machine: â€” PeerKeyInit â€“ This variable is used to initialize the PeerKey state machine. â€” TimeoutEvt â€“ This variable is set to true if the EAPOL-Key frame sent fails to obtain a response from the Supplicant. The variable may be set by management action or set by the operation of a timeout while in the different states. â€” TimeoutCtr â€“ This variable maintains the count of EAPOL-Key receive timeouts. It is incremented each time a timeout occurs on EAPOL-Key receive event and is initialized to 0. The Key Replay Counter field value for the EAPOL-Key frame shall be incremented on each transmission of the EAPOL-Key frame. â€” MICVerified â€“ This variable is set to true if the MIC on the received EAPOL-Key frame is verified and is correct. Any EAPOL-Key frames with an invalid MIC are dropped and ignored. â€” SMKMesgNo â€“ This variable indicates SMK handshake EAPOL-Key frame types. Details for each message type (1-5) are provided in 12.7.8. â€” STKMesgNo â€“ This variable indicates 4-way STK handshake EAPOL-Key frame types. Details for each message type (1-4) are provided in 12.7.6. â€” STA_P â€“ This variable indicates the MAC address of the peer STA participating in the PeerKey handshake. â€” STA_I â€“ This variable indicates the MAC address of the initiator STA participating in the PeerKey handshake. â€” STKKey â€“ The STK generated as a result of the 4-way STK handshake. â€” EAPOLKeyReceived â€“ The Supplicant sets this variable to true when it receives an EAPOL-Key frame. 12.7.10 RSNA Supplicant key management state machine 12.7.10.1 General The Supplicant shall reinitialize the Supplicant state machine whenever its system initializes. A Supplicant enters the AUTHENTICATION state on an event from the MAC that requests another STA to be authenticated. A Supplicant enters the STAKEYSTART state on receiving an EAPOL-Key frame from the Authenticator. If the MIC or any of the EAPOL-Key frames fails, the Supplicant silently discards the frame. Figure 12-49 depicts the RSNA Supplicant state machine. 2062 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications AuthenticationFailed dot11RSNAConfigSALifetime timeout DeauthenticationRequest || Init AuthenticationRequest DISCONNECTED AUTHENTICATION AuthenticationFailed = false AuthenticationRequest = false STADisconnect() SNonce = Random UCT PTK = GTK[0...N] = 0 IGTK[0...M] = 0 INITIALIZE 802.1X::portValid = false 802.1X::portControl = Auto Keycount = 0 802.1X::portEnable = true Init = false DeauthenticationRequest = false MSK = 0 802.1X::portEnable = false PeerKeyInit MLME-DELETEKEYS.request( PTK ) MLME-DELETEKEYS.request( GTK[0...N] ) MLME-DELETEKEYS.request( IGTK[0...M] ) 802.1X::portValid = false Figure 12-49â€”RSNA Supplicant key management state machine Unconditional transfer (UCT) means the event triggers an immediate transition. This state machine does not use timeouts or retries. The IEEE 802.1X state machine has timeouts that recover from authentication failures, etc. In order to authenticate an Authenticator, the management entity sends an authentication request event. This might be before or after the STA associates to the AP. In an IBSS environment, the event is generated when a Probe Response frame is received. 12.7.10.2 Supplicant state machine states The following list summarizes the states of the Supplicant state machine: â€” AUTHENTICATION: A Supplicant enters this state when it sends an IEEE 802.1X AuthenticationRequest to authenticate to an SSID. â€” DISCONNECTED: A Supplicant enters this state when IEEE 802.1X authentication fails. The Supplicant executes StaDisconnect and enters the INITIALIZE state. â€” INITIALIZE: A Supplicant enters this state from the DISCONNECTED state, when it receives Disassociation or Deauthentication messages or when the STA initializes, causing the Supplicant to initialize the key state variables. â€” STAKEYSTART: A Supplicant enters this state when it receives an EAPOL-Key frame. All the information to process the EAPOL-Key frame is in the message and is described in the StaProcessEAPOL-Key procedure. 12.7.10.3 Supplicant state machine variables The following list summarizes the variables used by the Supplicant state machine: â€” DeauthenticationRequest â€“ The Supplicant sets this variable to true if the Supplicantâ€™s STA reports it has received Disassociation or Deauthentication messages. â€” AuthenticationRequest â€“ The Supplicant sets this variable to true if its STAâ€™s IEEE 802.11 management entity reports that an SSID is to be authenticated. This might be on association or at other times. 2063 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” AuthenticationFailed â€“ The Supplicant sets this variable to true if the IEEE 802.1X authentication failed. The Supplicant uses the MLME-DISASSOCIATE.request primitive to cause its STA to disassociate from the Authenticatorâ€™s STA. â€” EAPOLKeyReceived â€“ The Supplicant sets this variable to true when it receives an EAPOL-Key frame. â€” IntegrityFailed â€“ The Supplicant sets this variable to true when its STA reports that a fatal data integrity error (e.g., michael failure) has occurred. NOTEâ€”A michael failure is not the same as MICVerified because IntegrityFailed is generated if the michael integrity check fails; MICVerified is generated from validating the EAPOL-Key integrity check. Note also the STA does not generate this event for ciphers other than TKIP because countermeasures are not required. â€” MICVerified â€“ The Supplicant sets this variable to true if the MIC on the received EAPOL-Key frame verifies as correct. The Supplicant silently discards any EAPOL-Key frame received with an invalid MIC. â€” SNonce â€“ This variable represents the Supplicantâ€™s nonce. â€” PTK â€“ This variable represents the current PTK. â€” TPTK â€“ This variable represents the current PTK until message 3 of the 4-way handshake arrives and is verified. â€” GTK[] â€“ This variable represents the current GTKs for each group key index. â€” IGTK[] â€“ This variable represents the current IGTKs for each group management key index. â€” PMK â€“ This variable represents the current PMK. â€” keycount â€“ This variable is used in IBSS mode to decide when all of the keys have been delivered and an IBSS link is secure. â€” 802.1X::XXX â€“ This variable denotes another IEEE 802.1X state variable XXX not specified in this standard. 12.7.11 RSNA Authenticator key management state machine 12.7.11.1 General There is one state diagram for the Authenticator. In an infrastructure BSS, the Authenticator is always on the AP; and in an IBSS environment, the Authenticator is on every STA. The state diagram shown in parts in Figure 12-50 to Figure 12-53 consists of the following states: a) The AUTHENTICATION, AUTHENTICATION2, INITPMK, INITPSK, PTKSTART, PTKCALCNEGOTIATING, PTKCALCNEGOTIATING2, PTKINITNEGOTIATING, PTKINIT- DONE, DISCONNECT, DISCONNECTED, and INITIALIZE states. These states handle the initialization, 4-way handshake, teardown, and general clean-up. These states are per associated STA. b) The IDLE, REKEYNEGOTIATING, KEYERROR, and REKEYESTABLISHED states. These states handle the transfer of the GTK to the associated client. These states are per associated STA. c) The GTK_INIT, SETKEYS, and SETKEYSDONE states. These states change the GTK when required, trigger all of the PTK group key state machines, and update the IEEE 802.11 MAC in the Authenticatorâ€™s AP when all STAs have the updated GTK. These states are global to the Authenticator. Because there are two GTKs, responsibility for updating these keys is given to the group key state machine (see Figure 12-52). In other words, this state machine determines which GTK is in use at any time. 2064 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications AuthenticationRequest AUTHENTICATION GNoStations++ PTK = 0 802.1X::portControl = Auto 802.1X::portEnable = true AuthenticationRequest = false UCT ReAuthenticationRequest AUTHENTICATION2 ANonce = Random ReAuthenticationRequest= false ! PSK && PSK && 802. 1X:: keyRun 802.1X:: keyRun INITPMK INITPSK ! 802.1X:: keyAvailable PMK = PMK = PSK L( MSK, 0, PMK_bits ) to DISCONNECT 802.1X:: keyAvailable 802.1X:: keyAvailable TimeoutEvt PTKSTART Send EAPOL-Key( 0, 0, 1, 0, P, 0, 0, ANonce, 0, 0) TimeoutCtr > N TimeoutCtr++ TimeoutEvt to DISCONNECT EAPOLKeyReceived && EAPOLKeyReceived && ! Request && K == Pairwise ! Request&& K == Pairwise PTKCALCNEGOTIATING PTK = Calc PTK( ANonce , SNonce ) MICVerified PTKCALCNEGOTIATING2 TimeoutCtr = 0 UCT TimeoutEvt PTKINITNEGOTIATING Send EAPOL-Key(1,1,1,Pair,P,0,RSC,ANonce,MIC(PTK),RSNE,GTK[N],IGTK[M]) TimeoutCtr> N TimeoutCtr ++ to KEYERROR EAPOLKeyReceived && ! Request && K == Pairwise && MICVerified PTKINITDONE if Pair == true MLME-SETKEYS.request . (0 , Tx/ Rx , PTK) MLME-SETPROTECTION.request . . ( TA , Tx , Rx ) if IBSS == true then keycount ++ if keycount == 2 then 802.1X:: PortValid = true else 802.1X:: PortValid = true endif 802.1X :: keyDone = true Figure 12-50â€”Authenticator state machines, part 1 2065 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Disconnect dot11RSNAConfigSALifetime timeout from INITPMK, PTKSTART DISCONNECT DeauthenticationRequest STADisconnect() Disconnect = false UCT DISCONNECTED GNoStationsâ€” DeauthenticationRequest = false Init UCT INITIALIZE Keycount = 0 If GUpdateStationKeys == true GKeyDoneStationâ€” GUpdateStationKeys = false If Unicast cipher supported by Authenticator AND (ESS OR ((IBSS or (FromDS==1 AND ToDS ==1)) and Local AA > Remote AA))) Pair = true IEEE 802.1X::portEnable = false MLME-DELETEKEYS.request(PTK) IEEE 802.1X::portValid = false TimeoutCtr = 0 Figure 12-51â€”Authenticator state machines, part 2 Init IDLE GTimeoutCtr = 0 UCT GUpdateStationKeys TimeoutEvt REKEYNEGOTIATING Send EAPOL-Key (1, 1, 1, !Pair, G , 0, RSC, GNonce,MIC (PTK), GTK [GN]) GTimeoutCtr ++ EAPOLKeyReceived &&! Request GTimeoutCtr > N && K == Group && MICVerified UCT REKEYESTABLISHED KEYERROR GKeyDoneStations â€” GUpdateStationKeys= false GUpdateStationKeys= false GKeyDoneStations â€“- Disconnect = true MLME-SETPROTECTION.request(TA, Rx_Tx) Figure 12-52â€”Authenticator state machines, part 3 2066 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications GInit GTK_INIT GTK[0...N] = 0 GN = 1 GM = 2 GTK[GN] = CalcGTK() IGTK[ 0... M] = 0 GN_igtk = 4 GM_igtk = 5 IGTK[ GN_igtk] = random key GTKAuthenticator SETKEYSDONE MLME-SETKEYS .request (GN, Tx/Rx, GTK[ GN]) MLME-SETKEYS .request (GN_igtk, IGTK, IGTK[ GN_igtk] ) MLME-SETPROTECTION .request ( Rx_Tx, IGTK) GTKRekey GKeyDoneStations == 0 SETKEYS GTKReKey = false Swap( GM. GN) GKeyDoneStations = GNoStations GTK[ GN] = CalcGTK() For each STA if STA is in WNM sleep mode GKeyDoneStations -- else GUpdateStationsKeys = true GTKRekey Swap(GM_igtk, GN_igtk ) IGTK[GN_igtk ] = random key Figure 12-53â€”Authenticator state machines, part 4 When a second STA associates, the group key state machine is already initialized, and a GTK is already available and in use. When the GTK is to be updated the variable GTKReKey is set to 1. The SETKEYS state updates the GTK and triggers all of the PTK group key state machines that currently existâ€”one per associated STA. Each PTK group key state machine sends the GTK to its STA. When all of the STAs have received the GTK (or failed to receive the key), the SETKEYSDONE state is executed which updates the APs encryption/integrity engine with the new key. Both the PTK state machine and the PTK group key state machine use received EAPOL-Key frames as an event to change states. The PTK state machine only uses EAPOL-Key frames with the Key Type field equal to Pairwise, and the PTK group key state machine only uses EAPOL-Key frames with the Key Type field equal to Group. 2067 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 12.7.11.2 Authenticator state machine states 12.7.11.2.1 Authenticator state machine: 4-way handshake (per STA) The following list summarizes the states the Authenticator state machine uses to support the 4-way handshake: â€” AUTHENTICATION: This state is entered when an AuthenticationRequest is sent from the management entity to authenticate a BSSID. â€” AUTHENTICATION2: This state is entered from the AUTHENTICATION state or from the PTKINITDONE state. â€” DISCONNECT: This state is entered if an EAPOL-Key frame is received and fails its MIC check. It sends a Deauthentication message to the STA and enters the INITIALIZE state. â€” DISCONNECTED: This state is entered when Disassociation or Deauthentication messages are received. â€” INITIALIZE: This state is entered from the DISCONNECTED state, when a deauthentication request event occurs, or when the STA initializes. The state initializes the key state variables. â€” INITPMK: This state is entered when the IEEE 802.1X backend AS completes successfully. If a PMK is supplied, it goes to the PTKSTART state; otherwise, it goes to the DISCONNECTED state. â€” INITPSK: This state is entered when a PSK is configured. â€” PTKCALCNEGOTIATING: This state is entered when the second EAPOL-Key frame for the 4-way handshake is received with the key type of Pairwise. â€” PTKCALNEGOTIATING2: This state is entered when the MIC for the second EAPOL-Key frame of the 4-way handshake is verified. â€” PTKINITNEGOTIATING: This state is entered when the MIC for the second EAPOL-Key frame for the 4-way handshake is verified. When message 3 of the 4-way handshake is sent in state PTKINITNEGOTIATING, the encrypted GTK shall be sent at the end of the data field, and the GTK length is put in the GTK Length field. â€” PTKINITDONE: This state is entered when the last EAPOL-Key frame for the 4-way handshake is received with the key type of Pairwise. This state may call SetPTK; if this call fails, the AP should detect and recover from the situation, for example, by doing a disconnect event for this association. â€” PTKSTART: This state is entered from INITPMK or INITPSK to start the 4-way handshake or if no response to the 4-way handshake occurs. 12.7.11.2.2 Authenticator state machine: group key handshake (per STA) The following list summarizes the states the Authenticator state machine uses to support the group key handshake: â€” IDLE: This state is entered when no group key handshake is occurring. â€” KEYERROR: This state is entered if the EAPOL-Key acknowledgment for the group key handshake is not received. â€” REKEYESTABLISHED: This state is entered when an EAPOL-Key frame is received from the Supplicant with the Key Type subfield equal to Group. â€” REKEYNEGOTIATING: This state is entered when the GTK is to be sent to the Supplicant. NOTEâ€”The Rx_Tx flag for sending a GTK is always the opposite of whether the pairwise key is used for data encryption/integrity or not. If a pairwise key is used for encryption/integrity, then the STA never transmits with the GTK; otherwise, the STA uses the GTK for transmit. 2068 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 12.7.11.2.3 Authenticator state machine: group key handshake (global) The following list summarizes the states the Authenticator state machine uses to coordinate a group key update of all STAs: â€” GTK_INIT: This state is entered on system initialization. â€” SETKEYS: This state is entered if the GTK is to be updated on all Supplicants. â€” SETKEYSDONE: This state is entered if the GTK has been updated on all Supplicants. NOTEâ€”SETKEYSDONE calls SetGTK to set the GTK for all associated STAs that are not in WNM sleep mode. If this fails, all communication via this key fails, and the AP needs to detect and recover from this situation. A STA that is in WNM sleep mode will not have the current GTK installed when it wakes up and will need to get new GTK as described in the WNM sleep mode procedures in 11.2.3.18. 12.7.11.3 Authenticator state machine variables The following list summarizes the variables used by the Authenticator state machine: â€” AuthenticationRequest â€“ This variable is set to true by the STAâ€™s IEEE 802.11 management entity in order to authenticate an association. This can be set to true when the STA associates or at other times. â€” ReAuthenticationRequest â€“ This variable is set to true if the IEEE 802.1X Authenticator received an eapStart or 802.1X::reAuthenticate is 1. â€” DeauthenticationRequest â€“ This variable is set to true if a Disassociation or Deauthentication message is received. â€” Disconnect â€“ This variable is set to true when the STA should initiate a deauthentication. â€” EAPOLKeyReceived â€“ This variable is set to true when an EAPOL-Key frame is received. EAPOL- Key frames that are received in response to an EAPOL-Key frame sent by the Authenticator shall contain the same Key Replay Counter field value as the Key Replay Counter field in the transmitted message. EAPOL-Key frames that contain different Key Replay Counter field values should be discarded. An EAPOL-Key frame that is sent by the Supplicant in response to an EAPOL-Key frame from the Authenticator shall not have the Ack bit set to 1. EAPOL-Key frames sent by the Supplicant not in response to an EAPOL-Key frame from the Authenticator shall have the Request bit set to 1. EAPOL-Key frames with a key type of Pairwise and a nonzero key index should be ignored. EAPOL-Key frames with a key type of Group and an invalid key index should be ignored. NOTEâ€”When an EAPOL-Key frame in which the Ack bit is 0 is received, then it is expected as a reply to a message that the Authenticator sent, and the replay counter is checked against the replay counter used in the sent EAPOL-Key frame. When an EAPOL-Key frame in which the Request bit is 1 is received, then a replay counter for these messages is used that is a different replay counter than the replay counter used for sending messages to the Supplicant. â€” GTimeoutCtr â€“ This variable maintains the count of EAPOL-Key receive timeouts for the group key handshake. It is incremented each time a timeout occurs on EAPOL-Key receive event and is initialized to 0. Annex C details the timeout values. The Key Replay Counter field value for the EAPOL-Key frame shall be incremented on each transmission of the EAPOL-Key frame. â€” GInit â€“ This variable is used to initialize the group key state machine. This is a group variable. â€” Init â€“ This variable is used to initialize per-STA state machine â€” TimeoutEvt â€“ This variable is set to true if the EAPOL-Key frame sent out fails to obtain a response from the Supplicant. The variable may be set to 1 by management action or set to 1 by the operation of a timeout while in the PTKSTART and REKEYNEGOTIATING states. â€” TimeoutCtr â€“ This variable maintains the count of EAPOL-Key receive timeouts. It is incremented each time a timeout occurs on EAPOL-Key receive event and is initialized to 0. Annex C contains details of the timeout values. The Key Replay Counter field value for the EAPOL-Key frame shall be incremented on each transmission of the EAPOL-Key frame. 2069 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” MICVerified â€“ This variable is set to true if the MIC on the received EAPOL-Key frame is verified and is correct. Any EAPOL-Key frames with an invalid MIC are dropped and ignored. â€” GTKAuthenticator â€“ This variable is set to true if the Authenticator is on an AP or it is the designated Authenticator for an IBSS. â€” GKeyDoneStations â€“ Count of number of STAs left to have their GTK updated. This is a global variable. â€” GTKRekey â€“ This variable is set to true when a group key handshake is required. This is a global variable. â€” GUpdateStationKeys â€“ This variable is set to true when a new GTK is available to be sent to Supplicants. â€” GNoStations â€“ This variable counts the number of Authenticators so it is known how many Supplicants need to be sent the GTK. This is a global variable. â€” ANonce â€“ This variable holds the current nonce to be used if the STA is an Authenticator. â€” GN, GM â€“ These are the current key indices for GTKs. Swap(GM, GN) means that the global key index in GN is swapped with the global key index in GM, so now GM and GN are reversed. â€” PTK â€“ This variable is the current PTK. â€” GTK[] â€“ This variable is the current GTKs for each GTK index. â€” PMK â€“ This variable is the buffer holding the current PMK. â€” 802.1X::XXX â€“ This variable is the IEEE 802.1X state variable XXX. â€” keycount â€“ This variable is used in IBSS mode to decide when all of the keys have been delivered and an IBSS link is secure. â€” WNM sleep mode â€“ This variable is true when the non-AP STA is in the WNM sleep mode, as described in 11.2.3.18. Otherwise, it is false. 12.7.11.4 Authenticator state machine procedures The following list summarizes the procedures used by the Authenticator state machine: â€” STADisconnect() â€“ Execution of this procedure deauthenticates the STA. â€” CalcGTK(x) â€“ Generates the GTK. â€” MIC(x) â€“ Computes a MIC over the plaintext data. 12.8 Mapping EAPOL keys to IEEE 802.11 keys 12.8.1 Mapping PTK to TKIP keys See 12.7.1.3 for the definition of the EAPOL temporal key derived from PTK. A STA shall use bits 0â€“127 of the temporal key as its input to the TKIP Phase 1 and Phase 2 mixing functions. A STA shall use bits 128â€“191 of the temporal key as the michael key for MSDUs from the Authenticatorâ€™s STA to the Supplicantâ€™s STA. A STA shall use bits 192â€“255 of the temporal key as the michael key for MSDUs from the Supplicantâ€™s STA to the Authenticatorâ€™s STA. 12.8.2 Mapping GTK to TKIP keys See 12.7.1.4 for the definition of the EAPOL temporal key derived from GTK. 2070 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A STA shall use bits 0â€“127 of the temporal key as the input to the TKIP Phase 1 and Phase 2 mixing functions. A STA shall use bits 128â€“191 of the temporal key as the michael key for MSDUs from the Authenticatorâ€™s STA to the Supplicantâ€™s STA. A STA shall use bits 192â€“255 of the temporal key as the michael key for MSDUs from the Supplicantâ€™s STA to the Authenticatorâ€™s STA. 12.8.3 Mapping PTK to CCMP keys See 12.7.1.3 for the definition of the EAPOL temporal key derived from PTK. A STA shall use the temporal key as the CCMP key for MPDUs between the two communicating STAs. 12.8.4 Mapping GTK to CCMP keys See 12.7.1.4 for the definition of the EAPOL temporal key derived from GTK. A STA shall use the temporal key as the CCMP key. 12.8.5 Mapping GTK to WEP-40 keys See 12.7.1.4 for the definition of the EAPOL temporal key derived from GTK. A STA shall use bits 0â€“39 of the temporal key as the WEP-40 key. 12.8.6 Mapping GTK to WEP-104 keys See 12.7.1.4 for the definition of the EAPOL temporal key derived from GTK. A STA shall use bits 0â€“103 of the temporal key as the WEP-104 key. 12.8.7 Mapping IGTK to BIP keys See 12.7.1.5 for the definition of the IGTK. A STA shall use bits 0â€“127 of the IGTK as the AES-128-CMAC key, bits 0â€“127 of the IGTK as the AES-128-GMAC key, and bits 0â€“255 of the IGTK as the AES-256- GMAC key. 12.8.8 Mapping PTK to GCMP keys See 12.7.1.3 for the definition of the EAPOL temporal key derived from PTK. A STA shall use the temporal key as the GCMP key for MPDUs between the two communicating STAs. 12.8.9 Mapping GTK to GCMP keys See 12.7.1.4 for the definition of the EAPOL temporal key derived from GTK. A STA shall use the temporal key as the GCMP key. 2071 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 12.9 Per-frame pseudocode 12.9.1 WEP frame pseudocode A WEP-encapsulated MPDU is called a WEP MPDU. All other MPDUs are called non-WEP MPDUs. A STA shall not transmit WEP MPDUs when dot11PrivacyInvoked is false. This MIB variable does not affect the reception of frames containing all or part of an MSDU or MMPDU. if dot11PrivacyInvoked is false then the MPDU is transmitted without WEP cryptographic encapsulation else if (the MPDU has an individual RA and there is an entry in dot11WEPKeyMappings for that RA) then if that entry has WEPOn equal to false then the MPDU is transmitted without WEP cryptographic encapsulation else if that entry contains a key that is null then discard the MPDUâ€™s entire MSDU and generate an MA-UNITDATA- STATUS.indication primitive to notify LLC that the MSDU was undeliverable due to a null WEP key else encrypt the MPDU using that entryâ€™s key, setting the Key ID subfield of the IV field to 0 endif endif else if (the MPDU has a group RA and the Privacy subfield of the Capability Information field in this BSS is 0) then the MPDU is transmitted without WEP cryptographic encapsulation else if dot11WEPDefaultKeys[dot11WEPDefaultKeyID] is null then discard the MPDUâ€™s entire MSDU and generate an MA-UNITDATA- STATUS.indication primitive to notify LLC that the MSDU was undeliverable due to a null WEP key else WEP-encapsulate the MPDU using the key dot11WEPDefaultKeys- [dot11WEPDefaultKeyID], setting the Key ID subfield of the IV field to dot11WEPDefaultKeyID endif endif endif endif When the boolean dot11ExcludeUnencrypted is true, MPDUs with the Type subfield equal to Data and the Protected Frame subfield of the Frame Control field equal to 0 shall not be indicated at the MAC service interface, and only MSDUs successfully reassembled from successfully decrypted MPDUs shall be indicated at the MAC service interface. When receiving a frame with the Type subfield equal to Data, the values of dot11PrivacyOptionImplemented, dot11WEPKeyMappings, dot11WEPDefaultKeys, dot11WEPDefaultKeyID, and dot11ExcludeUnencrypted in effect at the time the PHY- RXSTART.indication primitive is received by the MAC shall be used according to the following decision tree: if the Protected Frame subfield of the Frame Control field is 0 then if dot11ExcludeUnencrypted is true then 2072 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications discard the frame body without indication to LLC and increment dot11WEPExcludedCount else receive the frame without WEP decapsulation endif else if dot11PrivacyOptionImplemented is true then if (the MPDU has individual RA and there is an entry in dot11WEPKeyMappings matching the MPDUâ€™s TA) then if that entry has WEPOn equal to false then discard the frame body and increment dot11WEPUndecryptableCount else if that entry contains a key that is null then discard the frame body and increment dot11WEPUndecryptableCount else WEP-decapsulate with that key, incrementing dot11WEPICVErrorCount if the ICV check fails endif endif else if dot11WEPDefaultKeys[Key ID] is null then discard the frame body and increment dot11WEPUndecryptableCount else WEP-decapsulate with dot11WEPDefaultKeys[Key ID], incrementing dot11WEPICVErrorCount if the ICV check fails endif endif else discard the frame body and increment dot11WEPUndecryptableCount endif endif 12.9.2 RSNA frame pseudocode 12.9.2.1 General STAs transmit protected MSDUs, A-MSDUs, and robust Management frames to an RA when a temporal key has been configured with a MLME-SETKEYS.request primitive and an MLME- SETPROTECTION.request primitive has been invoked with ProtectType parameter Tx or Rx_Tx to that RA. STAs expect to receive protected MSDUs, A-MSDUs, and robust Management frames from a TA when a temporal key has been configured with a MLME-SETKEYS.request primitive and an MLME-SET- PROTECTION.request primitive has been invoked with ProtectType parameter Rx or Rx_Tx from that TA. MSDUs, A-MSDUs, and robust Management frames that do not match these conditions are sent in the clear and are received in the clear. 12.9.2.2 Per-MSDU/Per-A-MSDU Tx pseudocode if dot11RSNAActivated = true then if MSDU or A-MSDU has an individual RA and Protection for RA is off for Tx then transmit the MSDU or A-MSDU without protections else if (MPDU has individual RA and Pairwise key exists for the MPDUâ€™s RA) or (MPDU has a group addressed RA and network type is IBSS/PBSS and IBSS/PBSS GTK exists for MPDUâ€™s TA) then // If we find a suitable Pairwise or GTK for the mode we are inâ€¦ 2073 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications if key is a null key then discard the entire MSDU or A-MSDU and generate one or more MA-UNITDATA- STATUS.indication primitives to notify LLC that the MSDUs were undeliverable due to a null key else // Note that it is assumed that no entry in the key // mapping table is of an unsupported cipher type Set the Key ID subfield of the IV field to 0. if cipher type of entry is AES-CCM then Transmit the MSDU or A-MSDU, to be protected after fragmentation using AES-CCM else if cipher type of entry is AES-GCM then Transmit the MSDU or A-MSDU, to be protected after fragmentation using AES-GCM else if cipher type of entry is TKIP then Compute MIC using michael algorithm and entryâ€™s Tx MIC key. Append MIC to MSDU Transmit the MSDU, to be protected with TKIP else if cipher type of entry is WEP then Transmit the MSDU, to be protected with WEP endif endif else // Else we did not find a key but we are protected, so handle the default key case or discard if GTK entry for Key ID contains null then discard the MSDU or A-MSDU and generate one or more MA-UNITDATA- STATUS.indication primitives to notify the LLC that the MSDUs were undeliverable due to a null GTK else if GTK entry for Key ID is not null then Set the Key ID subfield of the IV field to the Key ID. if MPDU has an individual RA and cipher type of entry is not TKIP then discard the entire MSDU or A-MSDU and generate one or more MA- UNITDATA-STATUS.indication primitives to notify the LLC that the MSDUs were undeliverable due to a null key else if cipher type of entry is AES-CCM then Transmit the MSDU or A-MSDU, to be protected after fragmentation using AES-CCM else if cipher type of entry is AES-GCM then Transmit the MSDU or A-MSDU, to be protected after fragmentation using AES-GCM else if cipher type of entry is TKIP then Compute MIC using michael algorithm and entryâ€™s Tx MIC key. Append MIC to MSDU Transmit the MSDU, to be protected with TKIP else if cipher type of entry is WEP then Transmit the MSDU, to be protected with WEP endif endif endif endif 12.9.2.3 Per-MMPDU Tx pseudocode if ((dot11RSNAActivated = true) and (frame is a robust Management frame)) then 2074 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications if ((dot11RSNAProtectedManagementFramesActivated = false) then Transmit the MMPDU without protection else // dot11RSNAProtectedManagementFramesActivated = true if (dot11RSNAUnprotectedManagementFramesAllowed = true) then if (MMPDU has an individual RA) then if (peer STA advertised MFPC = 1) then if (Pairwise key exists for the MMPDUâ€™s RA) then // Note that it is assumed that no entry in the key // mapping table is of an unsupported cipher. Transmit the MMPDU, to be protected after fragmentation // see 12.9.2.5 else if (robust Action frame) then // pairwise key was not found Discard the MMPDU and generate an MLME.confirm primitive to notify the SME that the MMPDU was not delivered else // Disassociation or Deauthentication Transmit the MMPDU without protection endif else // (peer STA didnâ€™t advertised MFPC = 1) Transmit the MMPDU without protection endif else // MMPDU has a group RA if (IGTK exists) then // if we find a suitable IGTK Transmit the MMPDU with protection // See 12.9.2.5 else if (MMPDU is Disassociate ||Deauthenticate ||(not a robust Action frame)) then Transmit the MMPDU without protection else Discard the MMPDU and generate an MLME.confirm primitive to notify the SME that the MMPDU was undeliverable endif endif else // dot11RSNAUnprotectedManagementFramesAllowed = false if (MMPDU has an individual RA) then if (peer STA advertised MFPC = 1) then if (Pairwise key exists for the MMPDUâ€™s RA) then // Note that it is assumed that no entry in the key // mapping table is of an unsupported cipher. Transmit the MMPDU, to be protected after fragmentation // see 12.9.2.5 else if (robust Action frame) then // pairwise key was not found 2075 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Discard the MMPDU and generate an MLME.confirm primitive to notify the SME that the MMPDU was not delivered else // FrameControlSubType is Disassociation or Deauthentication Transmit the MMPDU without protection endif else // peer STA didnâ€™t advertise MFPC = 1 Discard the MMPDU and generate an MLME.confirm primitive to notify the SME that the MMPDU was not delivered endif else // MMPDU has a group RA if (IGTK exists) then // if we find a suitable IGTK Transmit the MMPDU with protection // See 12.9.2.5 else if (MMPDU is Disassociate || Deauthenticate || (not a robust Action frame)) then Transmit the MMPDU without protection else Discard the MMPDU and generate an MLME.confirm primitive to notify the SME that the MMPDU was undeliverable endif endif endif endif else // (dot11RSNAActivated = false) or (not a robust Management frame) Use 12.9.2.2 to transmit the frame endif 12.9.2.4 Per-MPDU Tx pseudocode if dot11RSNAActivated = true then if MPDU is member of an MSDU that is to be transmitted without protections transmit the MPDU without protections else if MSDU or A-MSDU that MPDU is a member of is to be protected using AES-CCM Protect the MPDU using entryâ€™s key and AES-CCM Transmit the MPDU else if MSDU or A-MSDU that MPDU is a member of is to be protected using AES-GCM Protect the MPDU using entryâ€™s key and AES-GCM Transmit the MPDU else if MSDU that MPDU is a member of is to be protected using TKIP Protect the MPDU using TKIP encryption Transmit the MPDU else if MSDU that MPDU is a member of is to be protected using WEP Encrypt the MPDU using entryâ€™s key and WEP Transmit the MPDU else // should not arrive here endif 2076 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications endif 12.9.2.5 Per-MPDU Tx pseudocode for MMPDU if ((dot11RSNAActivated = true) then if (MPDU is member of an MMPDU that is to be transmitted without protection) then Transmit the MPDU without protection else if (MPDU has an individual RA) then Protect the MPDU using entryâ€™s TK and selected cipher from RSNE Transmit the MPDU else // MPDU has a group RA Protect the MPDU using IGTK and BIP Transmit the MPDU endif endif 12.9.2.6 Per-MPDU Rx pseudocode if dot11RSNAActivated = true then if the Protected Frame subfield of the Frame Control field is 0 then if Protection for TA is off for Rx then Receive the unencrypted MPDU without protections else discard the frame body without indication to LLC and increment dot11WEPExcludedCount endif else if Protection is true for TA then if ((MPDU has individual RA and Pairwise key exists for the MPDUâ€™s TA) or (MPDU has a group addressed RA and network type is IBSS/PBSS and IBSS/PBSS GTK exists for MPDUâ€™s RA)) then if MPDU has individual RA then lookup pairwise key using Key ID from MPDU else lookup group key using Key ID from MPDU endif if key is null then discard the frame body and increment dot11WEPUndecryptableCount else if entry has an AES-CCM key then decrypt frame using AES-CCM key discard the frame if the integrity check fails and increment dot11RSNAStats- CCMPDecryptErrors else if entry has an AES-GCM key then decrypt frame using AES-GCM key discard the frame if the integrity check fails else if entry has a TKIP key then prepare a temporal key from the TA, TKIP key and PN decrypt the frame using ARC4 discard the frame if the ICV fails and increment dot11RSNAStatsTKIPLocal- MicFailures else if entry has a WEP key then 2077 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications decrypt the frame using WEP decryption discard the frame if the ICV fails and increment dot11WEPICVErrorCount else discard the frame body and increment dot11WEPUndecryptableCount endif else if GTK for the Key ID does not exist then discard the frame body and increment dot11WEPUndecryptableCount else if GTK for the Key ID is null then discard the frame body and increment dot11WEPUndecryptableCount else if the GTK for the Key ID is a CCM key then decrypt frame using AES-CCM key discard the frame if the integrity check fails and increment dot11RSNAStatsCCMP- DecryptErrors else if the GTK for the Key ID is a GCM key then decrypt frame using AES-GCM key else if the GTK for the Key ID is a TKIP key then prepare a temporal key from the TA, TKIP key and PN decrypt the frame using ARC4 discard the frame if the ICV fails and increment dot11RSNAStatsTKIPICVErrors else if the GTK for the Key ID is a WEP key then decrypt the frame using WEP decryption discard the frame if the ICV fails and increment dot11WEPICVErrorCount endif else MLME-PROTECTEDFRAMEDROPPED.indication discard the frame body and increment dot11WEPUndecryptableCount endif endif 12.9.2.7 Per-MPDU Rx pseudocode for an MMPDU if ((dot11RSNAActivated = true) and (frame is a robust Management frame)) then if ((dot11RSNAProtectedManagementFramesActivated = false) then if (Protected Frame subfield of the Frame Control field is equal to 1) then Discard the frame else Receive the MMPDU endif else // dot11RSNAProtectedManagementFramesActivated = true if (dot11RSNAUnprotectedManagementFramesAllowed = true) then if (STA with frame TA advertised MFPC = 0) then if (Protected Frame subfield of the Frame Control field is equal to 1) then Discard the frame else Make frame available for further processing endif else // STA with frame TA advertised MFPC = 1 if (MMPDU has an individual RA) then if (Pairwise key does not exist) then 2078 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications if (frame is a Disassociation or Deauthentication) then if (Protected Frame subfield of the Frame Control field is equal to 0) then Make the MPDU available for further processing else // encrypted Discard the frame endif else // frame is not a Disassociation or Deauthenticate Discard the frame endif else if (security association has an AES-CCM key) then if (Protected Frame subfield of the Frame Control field is equal to 0) then //unprotected frame Discard the frame else // frame is encrypted if (PN is not sequential) then Discard the MPDU as a replay Increment dot11RSNAStatsCCMPReplays else Decrypt frame using AES-CCM key if (the integrity check fails) then Discard the frame Increment dot11RSNAStatsCCMPDecryptErrors else Make the MPDU available for further processing endif endif endif else if (security association has AES-GCM key) then if (Protected Frame subfield of the Frame Control field is equal to 0) then //unprotected frame Discard the frame else //frame is encrypted if (PN is not sequential) then Discard the MPDU as a replay Increment dot11RSNAStatsGCMPReplays else Decrypt frame using AES-GCM key If (the integrity check fails) then Discard the frame else Make the MPDU available for further processing endif endif 2079 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications endif else // key for some other cipherâ€”for future expansion endif else // MMPDU has a group RA if (IGTK does not exist) then if (Disassociation or Deauthentication) then Make frame available for further processing else Discard the frame endif else // IGTK exists if (MME is not present) then Discard the frame else // MME is present if (AES-128-CMAC IGTK) then if (IPN is not valid) then Discard the frame as a replay Increment dot11RSNAStatsCMACReplay else if (integrity check fails) then Discard the frame Increment dot11RSNAStatsCMACICVError else Make frame available for further processing endif else // some other kind of keyâ€”for the future endif endif endif endif endif else // dot11RSNAUnprotectedManagementFramesAllowed = false if (MMPDU has an individual RA) then if (peer STA advertised MFPC = 1) then if (Pairwise key exists for the MMPDUâ€™s RA) then if (security association has an AES-CCM key) then if (Protected Frame subfield of the Frame Control field is equal to 0) then Discard the frame else // frame is encrypted if (PN is not sequential) then Discard the MPDU as a replay Increment dot11RSNAStatsCCMPReplays else Decrypt frame using AES-CCM key 2080 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications if (the integrity check fails) then Discard the frame Increment dot11RSNAStatsCCMPDecryptErrors else Make the MPDU available for further processing endif endif endif else // key for some other cipherâ€”for future expansion endif else if (Protected Frame subfield of the Frame Control field is set to 1) then Discard the frame else if (Deauthenticate || Disassociate) then Make frame available for processing else Discard the frame endif else // peer STA didnâ€™t advertise MFPC = 1 Discard the frame endif else // MMPDU has a group RA if (IGTK exists) then if (MME is not present) then Discard the frame else // MME is present if (AES-128-CMAC IGTK) then if (PN is not valid) then Discard the frame as a replay Increment dot11RSNAStatsCMACReplay else if (security association has an AES-128-CMAC IGTK) then Discard the frame Increment dot11RSNAStatsCMACICVError else Make frame available for further processing endif else // some other kind of keyâ€”for the future endif endif else // IGTK does not exist if (Disassociation or Deauthentication) then Make frame available for further processing else Discard the frame 2081 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications endif endif endif endif endif else // (dot11RSNAActivated = false) or (not a robust Management frame) Use 12.9.2.6 to receive the frame endif 12.9.2.8 Per-MSDU/Per-A-MSDU Rx pseudocode if dot11RSNAActivated = true then if the frame was not protected then Receive the MSDU or A-MSDU unprotected Make MSDU(s) available to higher layers else if Address 1 has an individual RA then // Have a protected MSDU or A-MSDU if Pairwise key is an AES-CCM key then Accept the MSDU or A-MSDU if its MPDUs had sequential PNs (or if it consists of only one MPDU), otherwise discard the MSDU or A-MSDU as a replay attack and increment dot11RSNAStatsCCMPReplays Make MSDU(s) available to higher layers else if Pairwise key is an AES-GCM key then Accept the MSDU or A-MSDU if its MPDUs had sequential PNs (or if it consists of only one MPDU), otherwise discard the MSDU or A-MSDU as a replay attack and increment dot11RSNAStatsGCMPReplays else if Pairwise key is a TKIP key then Compute the MIC using the michael algorithm Compare the received MIC to the computed MIC discard the frame if the MIC fails increment dot11RSNAStatsTKIPLocalMIC- Failures and invoke countermeasures if appropriate compare TSC to replay counter, if replay check fails increment dot11RSNA- StatsTKIPReplays otherwise accept the MSDU Make MSDU available to higher layers else if dot11WEPKeyMappings has a WEP key then Accept the MSDU since the decryption took place at the MPDU Make MSDU available to higher layers endif else // Have a group addressed MSDU or A-MSDU if GTK for the Key ID does not exist then discard the frame body and increment dot11WEPUndecryptableCount else if GTK for the Key ID is null then discard the frame body and increment dot11WEPUndecryptableCount else if GTK for the Key ID is a CCM key then Accept the MSDU or A-MSDU if its MPDUs had sequential PNs (or if it consists of only one MPDU), otherwise discard the MSDU or A-MSDU as a replay attack and increment dot11RSNAStatsCCMPReplays Make MSDU(s) available to higher layers else if GTK for the Key ID is a GCM key then Accept the MSDU or A-MSDU if its MPDUs have sequential PNs (or if it consists of only one MPDU), otherwise discard the MSDU or A-MSDU as a replay attack and increment dot11RSNAStatsGCMPReplays 2082 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications else if GTK for the Key ID is a TKIP key then Compute the MIC using the michael algorithm Compare the received MIC to the computed MIC discard the frame if the MIC fails increment dot11RSNAStatsTKIPLocalMICFailures and invoke countermeasures if appropriate compare TSC to replay counter, if replay check fails increment dot11RSNAStatsTKIPReplays otherwise accept the MSDU Make MSDU available to higher layers else if GTK for the Key ID is a WEP key then Accept the MSDU since the decryption took place at the MPDU Make MSDU available to higher layers endif endif endif 12.9.2.9 Per-MMPDU Rx pseudocode if (dot11RSNAActivated = true) then if (dot11RSNAProtectedManagementFramesActivated = true) then if (the MPDU was not protected) then Receive the MMPDU unprotected Make the MMPDU available to higher layers else //Have a protected MMPDU if ((MMPDU has individual RA) and (security association has an AES-CCM key)) then if (the MPDU has only one MPDU or multiple MPDUs with sequential PNs) then Receive the MMPDU protected Make the MMPDU available to higher layers else Discard the MMPDU as a replay Increment dot11RSNAStatsRobustMgmtCCMPReplays endif else if ((MMPDU has individual RA) and (security association has an AES-GCM key)) then if (the MPDU has only one MPDU or multiple MPDUs with sequential PNs) then Receive the MMPDU protected Make the MMPDU available to higher layers else Discard the MMPDU as a replay Increment dot11RSNAStatsRobustMgmtGCMPReplays else if ((MPDU has group addressed RA) and (security association has an AES-128- CMAC IGTK)) then Receive the MMPDU Make the MMPDU available to higher layers 2083 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications else if (any other cipher exists) then Process the frame using other cipher else Discard the frame endif endif endif endif endif 12.10 Authenticated mesh peering exchange (AMPE) The authenticated mesh peering exchange is defined in 14.5. 12.11 AP PeerKey support 12.11.1 AP PeerKey overview The AP PeerKey protocol provides session identification and creation of an AP PeerKey association to provide for security of OBSS management communication between two APs. The result of a successful run of the AP PeerKey protocol is an AP PeerKey association. An AP PeerKey association is composed of a mesh PMKSA and a mesh TKSA. Two APs perform the AP PeerKey protocol in order to protect HCCA TXOP Advertisement frames in an OBSS. The AP PeerKey protocol is unauthenticated (neither peer has a verified identity of the other peer) but an AP knows that only the peer AP that completed the AP PeerKey protocol is able to send protected HCCA TXOP Advertisement frames protected by the resulting AP PeerKey association. This allows an AP to determine whether a peer AP honors the HCCA TXOP avoidance schedule that is negotiated. In this manner, an AP is able to honor the negotiated schedule of trusted peer APs and ignore peer APs that are not trustworthy. This allows trustworthy APs to negotiate mutually beneficial schedules while allowing an AP to not disadvantage itself in an OBSS in the presence of untrustworthy APs. AP PeerKey uses various functions and data to accomplish its task and assumes certain properties about each function as follows: â€” H is an â€œextractorâ€ function (see IETF RFC 5869) that concentrates potentially dispersed entropy from an input to create an output that is a cryptographically strong, pseudorandom key. This function takes as input a non-secret â€œsaltâ€ and a secret input and produces a fixed-length output. â€” A finite cyclic group is negotiated for which solving the discrete logarithm problem is computationally infeasible. When using AKM suite selector 00-0F-AC:10 to indicate AP PeerKey, H shall be instantiated as HMAC- SHA-256, taking as input a non-secret â€œsaltâ€ and a secret input keying material â€œikmâ€: H(salt, ikm) = HMAC-SHA-256(salt, ikm) Other instantiations of function H require creation of a new AKM identifier. 2084 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 12.11.2 AP PeerKey protocol AP PeerKey uses the same discrete logarithm cryptography as SAE (as described in 12.4) to achieve key agreement. Each party to the exchange has a public and private key with respect to a particular set of domain parameters that define a finite cyclic group. Groups may be based on elliptic curve cryptography (ECC) or finite field cryptography (FFC). Each component of a group is referred to as an element. Groups are negotiated using an identifying number from a repository maintained by IANA as â€œGroup Descriptionâ€ attributes for IETF RFC 2409 (IKE) [B17][B31]. The repository maps an identifying number to a complete set of domain parameters for the particular group. For the purpose of interoperability, APs that have dot11ProtectedHCCATXOPNegotiationImplemented true or dot11ProtectedQLoadReportImplemented true shall support group 19, an ECC group defined over a 256-bit prime order field. AP PeerKey uses one arithmetic operator that takes one element and one scalar value to produce another element (called the scalar operation). The convention used here is to represent group elements in uppercase bold italic and scalar values in lowercase italic. The scalar operation takes an element and a scalar and is denoted scalar-op(x,Y). The private key d shall be chosen randomly so that 1 < d < r, where r is the order of the group. The public key Q shall be produced using Equation (12-1). Q = scalar-op(d,G) (12-1) where G is the generator (also known as the base point) of the group An AP for which dot11ProtectedTXOPNegotiationActivated is true or dot11ProtectedQLoadReportActivated is true shall support at least one public key from cyclic group nineteen and may support multiple public keys from multiple cyclic groups. An AP that supports the Multiple BSSID capability and has dot11ProtectedTXOPNegotiationActivated true or dot11ProtectedQLoadReportActivated true may use one public key across multiple BSSIDs, or it may choose to generate a public key for each supported BSSID. The AP PeerKey protocol consists of an exchange of public keys from an AP and a peer AP. An AP requests the public key of a peer AP by sending a Public Key frame with the Public Key Frame Usage field set to â€œRequest.â€ This frame contains the public key of the initiating AP. The initiating AP awaits a response to its request. The peer AP responds to the â€œRequestâ€ from the initiating AP with a Public Key frame with the Public Key Frame Usage field set to â€œResponseâ€, indicating an acceptable group was sent by the initiating AP, or set to â€œNAKâ€ indicating that the group sent by the initiating AP was unacceptable. It is possible for multiple runs of the AP PeerKey protocol to be performed by an AP but there shall be only one instance at a time of the AP PeerKey protocol to a peer AP for a particular group. The state associated with each run of the AP PeerKey protocol is the group and the two public keys of the participating APs. An AP for which dot11ProtectedTXOPNegotiationActivated is true or dot11ProtectedQLoadReportActivated is true shall reply to a Public Key frame. An AP that has both dot11ProtectedTXOPNegotiationActivated is false and dot11ProtectedQLoadReportActivated is false shall drop all received Public Key frames. If the responding AP refuses to perform the AP PeerKey protocol with the initiating AP it shall respond with a Public Key frame, setting the Public Key Frame Usage field to â€œRefusedâ€. Otherwise, if the Group field in the public key request is a group that is supported by the responding AP, the AP shall reply with a public key of the same group as the request, generating such a key pair if required, and setting the Public Key Frame Usage field to â€œResponseâ€. The receiving AP shall 2085 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications generate a PMK and a mesh PMKSA, see below, and terminate the PeerKey protocol. If the group field in the public key request is not supported by the responding AP, the responding AP shall respond with a Public Key frame, setting the Public Key Frame Usage field to â€œNAKâ€ and the group set to a group acceptable by the receiving AP. If the initiating AP does not receive a response to its request after five seconds, it should retransmit its request. The initiating AP should attempt such retransmission a minimum of five times. If the initiating AP receives a Public Key frame from a peer AP with the Public Key Frame Usage field set to â€œNAKâ€, the initiating AP inspects the group field in the received â€œNAKâ€. If the group is supported, the initiating AP should initiate to the peer AP using the indicated group. If the group is not supported, the AP may choose to initiate to the peer AP using a different group from the dot11RSNAConfigDLCGroup table. Receipt of a Public Key frame from a peer AP with the Public Key Frame Usage field set to â€œNAKâ€ terminates the PeerKey protocol. If the initiating AP receives a Public Key frame from a peer AP with the Public Key Frame Usage field set to â€œRefusedâ€, the initiating AP shall terminate the PeerKey protocol. An initiating AP that receives a refusal should delay sending another request for at least 5 seconds, and should perform exponential back-off on all subsequent requests by doubling the delay with each subsequent refusal. NOTEâ€”This standard does not specify a limit on the number of attempts an initiating AP makes to communicate with another AP. If the initiating AP receives a Public Key frame from a peer AP with the Public Key Frame Usage field set to â€œResponseâ€ and the group set to the value in the initiating APâ€™s â€œRequestâ€, the initiating AP shall generate a PMK and a mesh PMKSA. This terminates the PeerKey protocol. If the initiating AP receives a Public Key frame from a peer AP with the Public Key Frame Usage field set to â€œRequestâ€ prior to receiving a â€œResponseâ€, it checks the Group field in the request. If the Group in the received â€œRequestâ€ is the same as the Group the initiating AP sent it its request, the AP shall construct a Public Key frame with the Public Key Frame Usage field set to â€œResponseâ€ containing the public key it sent in its â€œRequestâ€ and transmit it to the peer. The AP shall then generate a PMK and a mesh PMKSA, see below, and terminate the PeerKey protocol. If the Group field differs and the group indicated is supported, the AP shall respond to the peer AP by replying with a public key from that group, generating a key pair if required, and setting the Public Key Frame Usage field to â€œResponseâ€. The AP shall generate a PMK and a mesh PMKSA, see below, and terminate this run of the PeerKey protocol. Once the AP and peer AP have exchanged public keys from the same finite cyclic group they can compute the Diffie-Hellman shared secret using scalar-op() and function F from 12.4.4: k = F(scalor-op(d,Qp)) (12-2) where d is the private key of the AP that is calculating k Qp is the public key of the peer AP Entropy of the shared secret shall then be extracted using function H to produce keyseed using Equation (12- 3). keyseed = H(<0>32, k) (12-3) 2086 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications where <0>32 denotes 32 octets of the value zero The PMK shall be derived according to Equation (12-4), and the PMKID shall be derived according to Equation (12-5). PMK = KDF-Hash-256(keyseed, "AP Peerkey Protocol", 0x00 || Max(LOCAL-MAC, PEER-MAC) || Min(LOCAL-MAC, PEER-MAC) ) (12-4) PMKID = Truncate-128(SHA-256(Q1 || Q2 || Max(LOCAL-MAC, PEER-MAC) || Min(LOCAL-MAC, PEER-MAC)) (12-5) where KDF-Hash-256 is the key derivation function defined in 12.7.1.7.2 using the hash algorithm identified by the AKM suite selector (see Table 9-133) 0x00 is a single octet with a value of zero LOCAL-MAC is the APâ€™s MAC address PEER-MAC is the peer APâ€™s MAC address Q1 is the public key used by AP1 in the AP PeerKey protocol encoded as an octet stream using the Element to Octet string conversion from 12.4.7.2.3. Q2 is the public key used by AP2 in the AP PeerKey protocol encoded as an octet stream using the Element to Octet string conversion from 12.4.7.2.3. AP1 is the AP whose MAC address equals Max(LOCAL-MAC, PEER-MAC) AP2 is the AP whose MAC address equals Min(LOCAL-MAC, PEER-MAC) The Max and Min operations for IEEE 802 addresses are with the address converted to a positive integer treating the first octet as the most significant octet of the integer. keyseed shall be irretrievably deleted after the PMK is generated. The lifetime of the mesh PMKSA shall be set to the value dot11RSNAConfigPMKLifetime. Upon creation of the PMK, an AEK shall be created per 14.5.7. The mesh PMKSA for this instance of the AP PeerKey protocol shall then be created using the APâ€™s MAC address as the STAâ€™s MAC address, the peer APâ€™s MAC address as the peer STAâ€™s MAC address, the AEK, the lifetime, and the PMKID. If a mesh PMKSA created by a prior run of the AP PeerKey protocol exists it shall be deleted upon creation of the new PMKSA. All mesh TKSAs created by the old mesh PMKSA shall also be deleted. Upon creation of the mesh PMKSA, the APME protocol (as defined in 14.5 shall be used to prove possession of the PMK (and implicitly the private key that corresponds to the peerâ€™s public key) and generate the mesh TKSA. Note that it is possible for two APs which simultaneously initiated to each other with different, but acceptable, groups to end up with two mesh PMKSAs. In this unlikely case, the mesh PMKSA from a group with the largest prime in its domain parameter set shall be used with the AMPE protocol. The other mesh PMKSA shall be deleted. 2087 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If the AMPE protocol completes successfully, Protected HCCA TXOP Advertisement frames and Protected HCCA TXOP Response frames may be used in the HCCA TXOP negotiation procedures, as defined in 11.28.3 using the MTK from the mesh TKSA. If the AMPE procedure completes successfully, Protected QLoad Request frames and Protected QLoad Report frames may be used in the QLoad report procedures, as defined in 11.28.2 using the MTK from the mesh TKSA. If the AMPE protocol fails, the peerâ€™s public key, PMK, and PMKSA shall be deleted. NOTEâ€”The PMK, as well as any key derived from it, is not authenticated in any way nor is it bound to any identity. This protocol protects an AP that cooperates in scheduling its HCCA TXOPs using Protected HCCA TXOP Advertisement frames because no other entity knows its private key and cannot forge Protected HCCA TXOP Advertisement frames. An AP that receives a Protected HCCA TXOP Advertisement frame is assured it was sent by the holder of a particular private key, and no one else, and can, therefore, establish which APs are cooperating in their HCCA TXOP scheduling. An AP that receives a Protected QLoad Report frame is assured it was sent by the holder of a particular private key, and no other STA, and can, therefore, establish which APs are correctly reporting their QoS load. 2088 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 13. Fast BSS transition 13.1 Overview Fast BSS transition seeks to reduce the length of time that connectivity is lost between a STA and the DS during a BSS transition. The FT protocols are part of the reassociation service and only apply to STA transitions between APs within the same mobility domain within the same ESS. The FT protocols require information to be exchanged during the initial association (or a later reassociation) between a STA (known as the FT Originator (FTO)) and AP. The initial exchange is referred to as the FT initial mobility domain association. Subsequent reassociations to APs within the same mobility domain may make use of the FT protocols. Two FT protocols are defined: â€” FT protocol. This protocol is executed when an FTO makes a transition to a target AP and does not require a resource request prior to its transition. â€” FT resource request protocol. This protocol is executed when an FTO requires a resource request prior to its transition. For an FTO to move from its current AP to a target AP utilizing the FT protocols, the message exchanges are performed using one of two methods: â€” Over-the-Air. The FTO communicates directly with the target AP using IEEE 802.11 authentication with the FT authentication algorithm. â€” Over-the-DS. The FTO communicates with the target AP via the current AP. The communication between the FTO and the target AP is carried in FT Action frames between the FTO and the current AP. Between the current AP and target AP, communication is via an encapsulation method described in 13.10.3. The current AP converts between the two encapsulations. APs advertise both capabilities and policies for supporting the FT protocols and methods. Throughout this clause, the notation Authentication-Request refers to an Authentication frame with the Authentication Transaction Sequence Number field equal to 1; Authentication-Response refers to an Authentication frame with the Authentication Transaction Sequence Number field equal to 2; Authentication-Confirm refers to an Authentication frame with the Authentication Transaction Sequence Number field equal to 3; Authentication-Ack refers to an Authentication frame with the Authentication Transaction Sequence Number field equal to 4. The first parameter to the above four messages is the authentication algorithm, such as Open System authentication algorithm (i.e., Open in figures in this clause) or FT authentication algorithm (i.e., FTAA in figures in this clause). 13.2 Key holders 13.2.1 Introduction The FT key holder architecture, shown in Figure 13-1, describes the FT key management entities and is defined in the context of the IEEE 802.11 basic reference model (see Figure 4-19 in 4.9). The R0KH and R1KH are part of APâ€™s SME RSNA key management. The computation of PMK-R0 and PMK-R1, and all of the intermediate results in the computations, shall be restricted to the R0KH. The computation of PTK, and all intermediate results in its computation, shall be restricted to the R1KH. 2089 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications RSNA Key Management R0KH/S0KH R1KH/S1KH Figure 13-1â€”FT key holder architecture The S0KH and S1KH are part of the FTOâ€™s SME RSNA key management. The computation of PMK-R0 and PMK-R1, and all of the intermediate results in the computations, shall be restricted to the S0KH. The computation of PTK, and all intermediate results in its computation, shall be restricted to the S1KH. 13.2.2 Authenticator key holders The R0KH and R1KH are responsible for the derivation of keys in the FT key hierarchy. For fast BSS transition, the functions of the IEEE 802.1X Authenticator are distributed among the R0KH and R1KHs. The R0KH interacts with the IEEE 802.1X Authenticator to receive the MSK resulting from an EAP authentication. The R1KH interacts with the IEEE 802.1X Authenticator to open the Controlled Port. Both the R0KH and R1KH interactions with the IEEE 802.1X Authenticator occur within the SME. The R0KH derives the PMK-R0 for use in the mobility domain utilizing the MSK (when the AKM negotiated is 00-0F-AC:3), the PSK (when the AKM negotiated is 00-0F-AC:4) or the PMK (when the AKM negotiated is 00-0F-AC:9). The R0KH shall be responsible for deriving a PMK-R1 for each R1KH within the mobility domain. The R1KH and S1KH each derive the PTK. Each R0KH-ID and R1KH-ID is assumed to be expressed as a unique identifier within the mobility domain. This identifier is communicated to the FTO and other key holders. The R0KH-ID is bound into the PMK-R0 derivation and the R1KH-ID is bound into the PMK-R1 derivation. The R0KH shall meet the following requirements: â€” The R0KH shall be collocated with the network access server (NAS) Client functionality of the IEEE 802.1X Authenticator. â€” The R0KH-ID shall be set to the identity of the co-resident NAS Client (e.g., NAS-Identifier as defined in IETF RFC 2865 if RADIUS is used as the backend protocol). R0KH-ID shall not be longer than 48 octets to fit in the length limitation of the FTE. â€” When the PMK-R0 lifetime expires, the R0KH shall delete the PMK-R0 security association and shall revoke within the R0KH all PMK-R1s derived from the PMK-R0. â€” The R0KH shall not expose the PMK-R0 to other parties. â€” The R0KH shall not expose the PMK-R1 to parties other than the authorized R1KH. 2090 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The R1KH shall meet the following requirements: â€” The R1KH-ID shall be set to a MAC address of the physical entity that stores the PMK-R1 and uses it to generate the PTK. That same MAC address shall be used to advertise the PMK-R1 identity to the STA and the R0KH. â€” The R1KH shall derive and distribute the GTK and IGTK to all connected STAs. â€” When the PMK-R1 lifetime expires, the R1KH shall delete the PMK-R1 PMKSA and shall revoke all PTKSAs derived from the PMK-R1 using the MLME-DELETEKEYS primitive. â€” The R1KH shall not expose the PMK-R1 to other parties. dot11FTR0KeyHolderID and dot11FTR1KeyHolderID shall contain the values of R0KH-ID and R1KH-ID as defined in this clause, respectively. The R0KH and the R1KH are assumed to have a secure channel between them that can be used to exchange cryptographic keys without exposure to any intermediate parties. The cryptographic strength of the secure channel between the R0KH and R1KH is assumed to be greater than or equal to the cryptographic strength of the channels for which the keys are used. This standard assumes that the key transfer includes the PMK- R1, the PMK-R1 PMKSA, the PMK-R1 context, and the associated key authorizations. The protocol for distribution of keying material from the R0KH to the R1KH is outside the scope of this standard. The PMK-R1 distribution from the R0KH to the R1KHs within the same mobility domain shall satisfy the following assumptions: â€” The R0KH authenticates a potential R1KH with the same identity as is included in the PMK-R1 derivation. The cryptographic strength of the authentication is assumed to be greater than or equal to the cryptographic strength of the authentication between the Supplicant and AS. â€” The authorization of holding a PMK-R1 is based on the authentication of the R1KH. â€” The protected channel provides confidentiality and integrity protection. 13.2.3 Supplicant key holders The S0KH and S1KH are responsible for the derivation of keys in the FT key hierarchy. The S0KH and S1KH are entities that are assumed to physically reside in the Supplicant. The S0KH interacts with the IEEE 802.1X functional block (see Figure 4-19 in 4.9) to receive the MSK resulting from an EAP authentication. The S1KH interacts with the IEEE 802.1X entity to open the Controlled Port. Both the S0KH and S1KH interactions with the IEEE 802.1X entity occur within the SME of a STA. The S0KH derives the PMK-R0 for use in the mobility domain utilizing the MSK (when the AKM negotiated is 00-0F-AC:3), the PSK (when the AKM negotiated is 00-0F-AC:4) or the PMK (when the AKM negotiated is 00-0F-AC:9). The S1KH shall derive the PTK mutually with the R1KH. The S0KH and S1KH shall be identified by the SPA. The S0KH shall not expose the PMK-R0 to other parties and shall not expose the PMK-R1 to parties other than the authorized S1KH. The S1KH shall not expose the PMK-R1 to other parties. 2091 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 13.3 Capability and policy advertisement The FT capability is advertised in the Beacon and Probe Response frames by including the MDE. The MDE is advertised in the Beacon and Probe Response frames to indicate the MDID, FT capability, and the FT policy. The MDID field shall be dot11FTMobilityDomainID. The Fast BSS Transition Policy bits in the MDE, i.e., Fast BSS Transition over DS subfield and Resource Request Protocol Capability subfield, shall be set by dot11FTOverDSActivated and dot11FTResourceRequestSupported, respectively. NOTEâ€”It is assumed by this standard that the Fast BSS Transition Policy bits in the MDE are administered consistently across the mobility domain. The capability is advertised in the Neighbor Report element. See 11.11 and 9.4.2.37. If an FTE is included in a Request element in a Probe Request frame, the FTE in the Probe Response frame shall contain the R0KH-ID and R1KH-ID (from dot11FTR0KeyHolderID and dot11FTR1KeyHolderID), and all other fields shall be set to 0. 13.4 FT initial mobility domain association 13.4.1 Overview The FT initial mobility domain association is the first (re)association in the mobility domain, where the SME of the STA enables its future use of the FT procedures. FT initial mobility domain association is typically the first association within the ESS. In addition to Association frames, Reassociation frames are supported in the initial mobility domain association to enable both FT and non-FT APs to be present in a single ESS. 13.4.2 FT initial mobility domain association in an RSN A STA indicates its support for the FT procedures by including the MDE in the (Re)Association Request frame and indicates its support of security by including the RSNE. The AP responds by including the FTE, MDE, and RSNE in the (Re)Association Response frame. After a successful IEEE 802.1X authentication (if needed) or SAE authentication, the STA and AP perform an FT 4-way handshake. At the end of the sequence, the IEEE 802.1X Controlled Port is opened, and the FT key hierarchy has been established. The message flow is shown in Figure 13-2. A non-DMG STA initiates the FT initial mobility domain association procedures by performing an IEEE 802.11 authentication using the Open System authentication algorithm. STA AP: Authentication-Request (Open System authentication algorithm) AP STA: Authentication-Response (Open System authentication algorithm, Status) A DMG STA initiates the FT initial mobility domain association procedures by performing an IEEE 802.11 authentication using the SAE algorithm. STA AP: Authentication-Request (SAE algorithm) AP STA: Authentication-Response (SAE algorithm, Status) The SME of the STA initiates the authentication exchange, through the use of the MLME- AUTHENTICATE.request primitive, and the SME of the AP responds with MLME- AUTHENTICATE.response primitive. See 11.3.4. 2092 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STA AP 802.11 Authentication-Request (Open) 802.11 Authentication-Response (Open) (Re)Association Request (MDE, RSNE) (Re)Association Response (MDE, FTE[R1KH-ID, R0KH-ID]) 802.1X EAP Authentication (bypassed if PSK is used) EAPOL-Key (0, 0, 1, 0, P, 0, ANonce, 0) EAPOL-Key (0, 1, 0, 0, P, 0, SNonce, MIC, RSNE[PMKR1Name], MDE, FTE) EAPOL-Key (1, 1, 1, 1, P, 0, ANonce, MIC, RSNE[PMKR1Name], MDE, GTK[N], IGTK[M], FTE, TE[ReassociationDeadline], TE[KeyLifetime]) EAPOL-Key (1, 1, 0, 0, P, 0, 0, MIC) 802.1X Controlled Port Unblocked, Successful (Secure) Session & Data Transmission QoS Resource Allocations Figure 13-2â€”FT initial mobility domain association in an RSN Upon successful IEEE 802.11 Open System authentication, (if the suite type is 00-0F-AC:3 or 00-0F-AC:4) or SAE authentication (if the suite type is 00-0F-AC:9), the STA shall send a (Re)Association Request frame to the AP that includes the MDE. The contents of the MDE shall be the values advertised by the AP in its Beacon or Probe Response frames. Additionally, the STA includes its security capabilities in the RSNE. STA AP: (Re)Association Request (MDE, RSNE) AP STA: (Re)Association Response (MDE, FTE[R1KH-ID, R0KH-ID]) The SME of the STA initiates the (re)association through the use of the MLME-ASSOCIATE.request or MLME-REASSOCIATE.request primitive. The SME of the AP responds to the indication with MLME- ASSOCIATE.response or MLME-REASSOCIATE.response primitive. See 11.3.5. If the contents of the MDE received by the AP do not match the contents advertised in the Beacon and Probe Response frames, the AP shall reject the (Re)Association Request frame with status code STATUS_INVALID_MDE. If an MDE is present in the (Re)Association Request frame and the contents of the RSNE do not indicate a negotiated AKM of fast BSS transition (suite type 00-0F-AC:3, 00-0F-AC:4, or 00-0F-AC:9), the AP shall reject the (Re)Association Request frame with status code STATUS_INVALID_AKMP. The (Re)Association Response frame from the AP shall contain an MDE, with contents as presented in Beacon and Probe Response frames. The FTE shall include the key holder identities of the AP, the R0KH-ID and R1KH-ID, set to the values of dot11FTR0KeyHolderID and dot11FTR1KeyHolderID, respectively. The FTE shall have a MIC element count of zero (i.e., no MIC present) and have ANonce, SNonce, and MIC fields set to 0. On successful (re)association, the S0KH on the STA and the R0KH on the AP then proceed with an IEEE 802.1X authentication using EAPOL frames carried in IEEE 802.11 Data frames if SAE authentication was not performed (i.e., if the suite type is not 00-0F-AC:9). The S0KH shall use the value of 2093 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications R0KH-ID as the endpoint identifier of the NAS Client (NAS-Identifier if RADIUS is used) in the exchange as defined in IETF RFC 3748 [B42]. If IEEE 802.1X authentication was performed, then upon successful completion of authentication, the R0KH receives the MSK and authorization attributes. If SAE authentication was performed, the R0KH receives the PMK, resulting in the successful completion of SAE. If a key hierarchy already exists for this STA belonging to the same mobility domain (i.e., having the same MDID), the R0KH shall delete the existing PMK-R0 security association and PMK-R1 security associations. It then calculates the PMK-R0, PMKR0Name, and PMK-R1 and makes the PMK-R1 available to the R1KH of the AP with which the STA is associated. If the SME of the STA cannot authenticate the AS, then it shall disassociate with an MLME- DISASSOCIATE.request primitive. If the AS signals the Authenticator that the STA cannot be authenticated, then the SME of the AP shall disassociate with an MLME-DISASSOCIATE.request primitive. If the MSK lifetime attribute is provided by the AS, the lifetime of the PMK-R0 shall not be more than the lifetime of the MSK. If the MSK lifetime attribute is not provided, the PMK-R0 lifetime shall be dot11FTR0KeyLifetime. For PSK, the PMK-R0 lifetime shall be dot11FTR0KeyLifetime. The lifetime of the PMK-R1s and PTK shall be the same as the lifetime of PMK-R0. When the key lifetime expires, each key holder shall delete its respective PMK-R0, PMK-R1, and PTK SAs. The R1KH and S1KH then perform an FT 4-way handshake. The EAPOL-Key frame notation is defined in 12.7.4. R1KH S1KH: EAPOL-Key(0, 0, 1, 0, P, 0, 0, ANonce, 0) S1KH R1KH: EAPOL-Key(0, 1, 0, 0, P, 0, 0, SNonce, MIC, RSNE[PMKR1Name], MDE, FTE) R1KH S1KH: EAPOL-Key(1, 1, 1, 1, P, 0, 0, ANonce, MIC, RSNE[PMKR1Name], MDE, GTK[N], IGTK[M], FTE, TIE[ReassociationDeadline], TIE[KeyLifetime]) S1KH R1KH: EAPOL-Key(1, 1, 0, 0, P, 0, 0, 0, MIC) The message sequence is described in 12.7.6. It is assumed by this standard that the reassociation deadline is administered consistently across the mobility domain. The mechanism for such consistent administration is outside the scope of this standard. The PTK shall be calculated by the R1KH and S1KH according to the procedures given in 12.7.1.7.5. Upon completion of a successful FT 4-way handshake, the IEEE 802.1X Controlled Port shall be opened on both the non-AP STA and the AP. Subsequent EAPOL-Key frames shall use the key replay counter to detect replayed messages. Upon completion of a successful FT 4-way handshake, the PTK lifetime timer is initiated. The operation of this timer prevent the PTKSA being used for longer than the value provided in the TIE[KeyLifetime] sent in message 3. Once the PTKSA key lifetime expires, as indicated by the TIE[KeyLifetime], to continue its association in the mobility domain the STA shall perform the FT initial mobility domain association procedures. If the AP sends a Deauthentication or Disassociation frame to the STA with reason code INVALID_AUTHENTICATION, then to continue its association in the mobility domain, the STA shall perform the FT initial mobility domain association procedures with any AP in the mobility domain. If the Supplicant EAPOL state machines are triggered to send an EAPOL-Start frame after a successful initial mobility domain association, the STA shall perform the FT initial mobility domain association procedures. 2094 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 13.4.3 FT initial mobility domain association in a non-RSN In this sequence, the STA utilizes the FT procedures by including the MDE in the (Re)Association Request frame. The AP responds by including the MDE in the (Re)Association Response frame. The message flow is shown in Figure 13-3. STA AP 802.11 Authentication-Request (Open) 802.11 Authentication-Response (Open) (Re)Association Request (MDE) (Re)Association Response (MDE) Successful Session & Data Transmission QoS Resource Allocations Figure 13-3â€”FT initial mobility domain association in a non-RSN The STA initiates the FT initial mobility domain association procedures by performing an IEEE 802.11 authentication using the Open System authentication algorithm. STA AP: Authentication-Request (Open System authentication algorithm) AP STA: Authentication-Response (Open System authentication algorithm, Status) The SME of the STA initiates the authentication exchange through the use of the primitive MLME- AUTHENTICATE.request primitive, and the SME of the AP responds with MLME- AUTHENTICATE.response primitive. See 11.3.4. Upon successful IEEE 802.11 Open System authentication, the STA shall send a (Re)Association Request frame to the AP and shall include the MDE. The contents of the MDE shall be the values advertised by the AP in its Beacon or Probe Response frames. STA AP: (Re)Association Request (MDE) AP STA: (Re)Association Response (MDE) The SME of the STA initiates the (re)association through the use of the MLME-ASSOCIATE.request or MLME-REASSOCIATE.request primitive. The SME of the AP responds to the indication with MLME- ASSOCIATE.response or MLME-REASSOCIATE.response primitive. See 11.3.5. If the contents of the MDE received by the AP do not match the contents advertised in the Beacon and Probe Response frames, the AP shall reject the (Re)Association Request frame with status code STATUS_INVALID_MDE. The (Re)Association Response frame from the AP shall contain an MDE, with contents as presented in Beacon and Probe Response frames. 2095 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications On successful (re)association, the AP and the non-AP STA shall transition to State 4 (as defined in 11.3) to enable Data frame transmission. 13.5 FT protocol 13.5.1 Overview STAs with dot11FastBSSTransitionActivated equal to true shall support the FT protocol. The FT protocol supports resource requests as part of the reassociation. The optional FT resource request protocol (see 13.6) supports resource requests prior to reassociation. A STA shall not use any authentication algorithm except the FT authentication algorithm when using the FT protocol. 13.5.2 Over-the-air FT protocol authentication in an RSN The over-the-air FT protocol in an RSN is shown in Figure 13-4. Current Target FTO AP AP Successful (secure) session & Data transmission FTO determines it needs to transition to the Target AP 802.11 Authentication-Request (FTAA, RSNE[PMKR0Name], MDE, FTE[SNonce, R0KH-ID]) 802.11 Authentication-Response (FTAA, RSNE[PMKR0Name], MDE, FTE[ANonce, SNonce, R1KH-ID, R0KH-ID]) A successful Reassociation occurs only when the time between the Authentication-Request and the Reassociation Request does not exceed the Reassociation Deadline Time Reassociation Request (RSNE[PMKR1Name], MDE, FTE[MIC, ANonce, SNonce, R1KH-ID, R0KH-ID], RIC-Request) Reassociation Response (RSNE[PMKR1Name], MDE, FTE[MIC, ANonce, SNonce, R1KH-ID, R0KH-ID, GTK[N]], IGTK[M], RIC-Response) 802.1X Controlled Port Unblocked, Successful (Secure) Session & Data Transmission Figure 13-4â€”Over-the-air FT protocol in an RSN The FTO and AP use the FT authentication sequence to specify the PMK-R1 security association and to provide values of SNonce and ANonce that enable a liveness proof, replay protection, and PTK separation. This exchange enables a fresh PTK to be computed in advance of reassociation. The PTKSA is used to protect the subsequent reassociation transaction, including the optional RIC-Request. 2096 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications To perform an over-the-air fast BSS transition to a target AP, the FTO and target AP shall perform the following exchange: FTO Target AP: Authentication-Request (FTAA, 0, RSNE[PMKR0Name], MDE, FTE[SNonce, R0KH-ID]) Target AP FTO: Authentication-Response (FTAA, Status, RSNE[PMKR0Name], MDE, FTE[ANonce, SNonce, R1KH-ID, R0KH-ID]) The SME of the FTO initiates the authentication exchange, through the use of the MLME- AUTHENTICATE.request primitive, and the SME of the AP responds with an MLME- AUTHENTICATE.response primitive. See 11.3.4. The MLME primitives for Authentication when the FT authentication algorithm is selected use only authentication transaction sequence number values 1 and 2. In the Authentication-Request frame, the SA field of the message header shall be set to the MAC address of the FTO, and the DA field of the message header shall be set to the BSSID of the target AP. The elements in the frame, and their required contents, shall be as given in 13.8.2. If the contents of the MDE received by the AP do not match the contents advertised in the Beacon and Probe Response frames, the AP shall reject the authentication request with status code STATUS_INVALID_MDE. If the Authentication-Request frame contains an authentication algorithm equal to FT authentication and the contents of the RSNE do not indicate a negotiated AKM of fast BSS transition (suite type 00-0F-AC:3 or 00- 0F-AC:4), the AP shall reject the authentication request with status code STATUS_INVALID_AKMP. If the FTE in the FT Request frame contains an invalid R0KH-ID, the AP shall reject the FT Request frame with status code STATUS_INVALID_FTE. If the RSNE in the Authentication-Request frame contains an invalid PMKR0Name and the AP has determined that it is an invalid PMKR0Name, the AP shall reject the authentication request with status code STATUS_INVALID_PMKID. If the requested R0KH is not reachable, the AP shall respond to the authentication request with status code R0KH_UNREACHABLE. If the FTO selects a pairwise cipher suite in the RSNE that is different from the ones used in the Initial mobility domain association, then the AP shall reject the authentication request with status code STATUS_INVALID_PAIRWISE_CIPHER. Subsequent to a rejection of an authentication request, the FTO may retry the authentication request. In the Authentication-Response frame, the SA field of the message header shall be set to the BSSID of the target AP, and the DA field of the message header shall be set to the MAC address of the FTO. The Status Code field shall be a value from the options listed in 9.4.1.9. The elements in the frame, and their required contents, shall be as given in 13.8.3. The R1KH of the target AP uses the value of PMKR0Name and other information in the frame to calculate PMKR1Name. If the target AP does not have the key identified by PMKR1Name, it may retrieve that key from the R0KH identified by the FTO. See 13.2. Upon receiving a new PMK-R1 for a STA, the target AP shall delete the prior PMK-R1 security association and PTKSAs derived from the prior PMK-R1. The FTO and the target AP compute the PTK and PTKName using the PMK-R1, PMKR1Name, ANonce, and SNonce, as specified in 12.7.1.7.5. The PTKSA shall be deleted by the target AP if it does not receive a Reassociation Request frame from the FTO within the reassociation deadline timeout value. If the FTO does not receive a response to the Authentication-Request frame, it may reissue the request following the restrictions given for Authentication frames in 11.3. If the Status Code field value returned by the target AP is SUCCESS, the FTO and target AP transition to State 2 (as defined in 11.3); the FTO may continue with reassociation (13.7.1). Handling of errors returned in the Status Code field shall be as specified in 11.3. 2097 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 13.5.3 Over-the-DS FT protocol in an RSN A STA shall not initiate an over-the-DS FT authentication to a target AP whose MDE contains the Fast BSS Transition over DS bit equal to 0. The over-the-DS FT protocol in an RSN is shown in Figure 13-5. Current Target FTO AP AP Successful (secure) session & Data transmission FTO determines it needs to transition to the Target AP FT Request (FTO, TargetAP, RSNE[PMKR0Name], MDE, FTE[SNonce, R0KH-ID]) FT Response (FTO, TargetAP, RSNE[PMKR0Name], MDE, FTE[ANonce, SNonce, R1KH-ID, R0KH-ID]) A successful Reassociation occurs only when the time between the FT Request and the Reassociation Request does not exceed the Reassociation Deadline Time Reassociation Request (RSNE[PMKR1Name], MDE, FTE[MIC, ANonce, SNonce, R1KH-ID, R0KH-ID], RIC-Request) Reassociation Response(RSNE[PMKR1Name], MDE, FTE[MIC, ANonce, SNonce, R1KH-ID, R0KH-ID, GTK[N]], IGTK[M], RIC-Response) 802.1X Controlled Port Unblocked, Successful (Secure) Session & Data Transmission Figure 13-5â€”Over-the-DS FT protocol in an RSN To perform an over-the-DS fast BSS transition to a target AP, the FTO and the target AP (through the current AP) shall perform the following exchange: FTO Target AP: FT Request (FTO address, TargetAP address, RSNE[PMKR0Name], MDE, FTE[SNonce, R0KH-ID]) Target AP FTO: FT Response (FTO address, TargetAP address, Status, RSNE[PMKR0Name], MDE, FTE[ANonce, SNonce, R1KH-ID, R0KH-ID]) The SME of the FTO initiates the FT Request frame to the target AP by issuing an MLME-REMOTE- REQUEST.request primitive with parameters including the contents of the FT Request frame (FT Action frame with an FT Action field value indicating FT Request) to be sent. The MAC of the FTO transmits this Action frame. For processing at the current AP and target AP, see 13.10. When the MAC of the FTO receives the FT Response frame (FT Action frame with an FT Action field value indicating FT Response), it passes it to the SME by use of MLME-REMOTE-REQUEST.indication primitive, with parameters including the contents of the received Action frame. The MLME interfaces on the FTO, current AP, and the target AP for executing the over-the-DS fast BSS transition are shown in Figure 13-6. The STA Address field of the FT Request frame shall be set to the MAC address of the FTO, and the Target AP Address field of the FT Request frame shall be set to the BSSID of the target AP. The elements in the FT Request frame, and their required contents, shall be as given in 13.8.2. 2098 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications FTO Current AP Target AP SME MAC MAC SME MAC SME MLME-REMOTE-REQUEST.request FT Action Request (elements) MLME-REMOTE-REQUEST.indication RemoteRequest (elements) Target AP processes RemoteResponse (elements) the request FT Action Response MLME-REMOTE-REQUEST.request (elements) MLME-REMOTE-REQUEST.indication MLME-REASSOCIATE.request Reassociation Request (elements) MLME-REASSOCATE.indication Reassociation Response MLME-REASSOCATE.response (elements) MLME-REASSOCIATE.confirm Figure 13-6â€”MLME interfaces for over-the-DS FT protocol messages If the contents of the MDE received by the target AP do not match the contents advertised in the Beacon and Probe Response frames, the target AP shall reject the FT Request frame with status code STATUS_INVALID_MDE. If the contents of the RSNE do not indicate a negotiated AKM of fast BSS transition (suite type 00-0F-AC:3, 00-0F-AC:4, or 00-0F-AC:9), the AP shall reject the FT Request frame with status code STATUS_INVALID_AKMP. If the FTE in the FT Request frame contains an invalid R0KH-ID, the AP shall reject the FT Request frame with status code STATUS_INVALID_FTE. If the RSNE in the FT Request frame contains an invalid PMKR0Name, and the AP has determined that it is an invalid PMKR0Name, the AP shall reject the authentication request with status code STATUS_INVALID_PMKID. If the requested R0KH is not reachable, the AP shall respond to the FT Request frame with status code R0KH_UNREACHABLE. The AP may reject the FT Request frame for limiting the FTOâ€™s reassociation to this AP by using the status code REQUEST_DECLINED. If the FTO selects a pairwise cipher suite in the RSNE that is different from the ones used in the initial mobility domain association, then the AP shall reject the FT Request frame with status code STATUS_INVALID_PAIRWISE_CIPHER. The STA Address field of the FT Response frame shall be set to the MAC address of the FTO, and the Target AP Address field of the FT Response frame shall be set to the BSSID of the target AP. The elements in the FT Response frame, and their required contents, shall be as given in 13.8.3. The Status Code field shall be a value from the options listed in 9.4.1.9. The R1KH of the target AP uses the value of PMKR0Name and other information from the frame to calculate PMKR1Name. If the target AP does not have the key identified by PMKR1Name, it may retrieve that key from the R0KH identified by the STA. See 13.2. Upon receiving a new PMK-R1 for a STA, the target AP shall delete the prior PMK-R1 security association and PTKSAs derived from the prior PMK-R1. 2099 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The FTO and the target AP compute the PTK and PTKName using the PMK-R1, PMKR1Name, ANonce, and SNonce, as specified in 12.7.1.7.5. The PTKSA shall be deleted by the target AP if it does not receive a Reassociation Request frame from the FTO within the reassociation deadline timeout value. If the FTO does not receive a response to the FT Request frame, it may reissue the request following the restrictions given for Authentication frames in 11.3. If the Status Code field value returned by the target AP is SUCCESS, the FTO and target AP transition to State 2 (as defined in 11.3); the FTO may continue with reassociation (13.7.1). Handling of errors returned in the Status Code field shall be as specified for Authentication frames in 11.3. 13.5.4 Over-the-air FT protocol in a non-RSN The over-the-air FT protocol in a non-RSN is shown in Figure 13-7. Current Target FTO AP AP Successful session & Data transmission FTO determines it needs to transition to the Target AP 802.11 Authentication-Request (FTAA, MDE) 802.11 Authentication-Response (FTAA, MDE) Reassociation Request (MDE, RIC-Request) Reassociation Response (MDE, RIC-Response) Successful Session & Data Transmission Figure 13-7â€”Over-the-air FT protocol in a non-RSN To perform an over-the-air fast BSS transition to a target AP in a non-RSN, the FTO and target AP shall perform the following exchange: FTO Target AP: Authentication-Request (FTAA, 0, MDE) Target AP FTO: Authentication-Response (FTAA, Status, MDE) In the Authentication-Request frame, the SA field of the message header shall be set to the MAC address of the FTO, and the DA field of the message header shall be set to the BSSID of the target AP. The elements in the frame, and their required contents, shall be as given in 13.8.2. If the contents of the MDE received by the target AP do not match the contents advertised in the Beacon and Probe Response frames, the target AP shall reject the authentication request with status code STATUS_INVALID_MDE. In the Authentication-Response frame, the SA field of the message header shall be set to the BSSID of the target AP, and the DA field of the message header shall be set to the MAC address of the FTO. The Status Code field shall be a value from the options listed in 9.4.1.9. The elements in the frame, and their required contents, shall be as given in 13.8.3. 2100 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If the FTO does not receive a response to the Authentication-Request frame, it may reissue the request following the restrictions given for Authentication frames in 11.3. If the Status Code field value returned by the target AP is SUCCESS, the FTO and target AP transition to State 2 (as defined in 11.3); the FTO may continue with reassociation (13.7.2). Handling of errors returned in the Status Code field shall be as specified in 11.3. 13.5.5 Over-the-DS FT protocol in a non-RSN The over-the-DS FT protocol in a non-RSN is shown in Figure 13-8. Current Target FTO AP AP Successful session & Data transmission FTO determines it needs to transition to the Target AP FT Request (FTO, Target AP, MDE) FT Response (FTO, Target AP, MDE) Reassociation Request (MDE, RIC-Request) Reassociation Response (MDE, RIC-Response) Successful Session & Data Transmission Figure 13-8â€”Over-the-DS FT protocol in a non-RSN To perform an over-the-DS fast BSS transition to a target AP in a non-RSN, the FTO and the target AP (through the current AP) shall perform the following exchange: FTO Target AP: FT Request(FTO, TargetAP, MDE) Target AP FTO: FT Response(FTO, TargetAP, Status, MDE) The STA Address field of the FT Request frame shall be set to the MAC address of the FTO, and the Target AP Address field of the FT Request frame shall be set to the BSSID of the target AP. The elements in the FT Request frame, and their required contents, shall be as given in 13.8.2. If the contents of the MDE received by the target AP do not match the contents advertised in the Beacon and Probe Response frames, the target AP shall reject the FT Request frame with status code STATUS_INVALID_MDE. The STA Address field of the FT Response frame shall be set to the MAC address of the FTO, and the Target AP Address field of the FT Response frame shall be set to the BSSID of the target AP. The elements in the FT Response frame, and their required contents, shall be as given in 13.8.3. The Status Code field shall be a value from the options listed in 9.4.1.9. If the FTO does not receive a response to the FT Request frame, it may reissue the request following the restrictions given for Authentication frames in 11.3. If the Status Code field value returned by the target AP 2101 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications is SUCCESS, the FTO and target AP transition to State 2 (as defined in 11.3); the FTO may continue with reassociation (13.7.2). Handling of errors returned in the Status Code field shall be as specified for Authentication frames in 11.3. 13.6 FT resource request protocol 13.6.1 Overview The FT resource request protocol involves an additional message exchange after the Authentication- Request/Response frame, or FT Request/Response frame, and prior to reassociation. APs capable of fast BSS transition may allow FTOs to request resources prior to reassociation. Availability of the FT resource request protocol is advertised by the target AP in the MDE. If the Resource Request Protocol Capability subfield is 0, then the FTO shall not send an Authentication-Confirm nor FT Confirm frame to the AP. An AP that receives an Authentication-Confirm or FT Confirm frame from a STA and does not support the FT resource request protocol shall respond with status code INVALID_PARAMETERS. The additional message exchange for the FT resource request protocol shall be performed using the same method (over-the-air or over-the-DS) as was used for the Authentication-Request/Response frame or FT Request/Response frame. An AP that receives an FT Confirm frame that did not previously receive an FT Request frame from the same STA shall reject the request with status code STATUS_INVALID_FT_ACTION_FRAME_COUNT. An AP that receives an Authentication-Confirm frame that did not previously receive an Authentication-Request frame from the same STA shall reject the request with status code TRANSACTION_SEQUENCE_ERROR. 13.6.2 Over-the-air fast BSS transition with resource request The over-the-air FT resource request protocol in an RSN is shown in Figure 13-9. The over-the-air FT resource request protocol in a non-RSN is shown in Figure 13-10. To perform an over-the-air FT resource request protocol to a target AP, after completing the Authentication- Request/Response frame exchange given in 13.5.2 or 13.5.4, the FTO and target AP shall perform the following exchange: FTO Target AP: Authentication-Confirm (FTAA, 0, RSNE[PMKR1Name], MDE, FTE[MIC, ANonce, SNonce, R1KH-ID, R0KH-ID], RIC-Request) Target AP FTO: Authentication-Ack (FTAA, Status, RSNE[PMKR1Name], MDE, FTE[MIC, ANonce, SNonce, R1KH-ID, R0KH-ID], RIC-Response) The SME of the FTO initiates the resource request exchange through the use of the primitive MLME- RESOURCE-REQUEST.request primitive, and the SME of the AP responds with MLME-RESOURCE- REQUEST.response primitive. In the Authentication-Confirm frame, the SA field of the message header shall be set to the MAC address of the FTO, and the DA field of the message header shall be set to the BSSID of the target AP. In a non-RSN, the FTE and RSNE shall not be present. The elements in the frame, the element contents, and MIC calculation shall be as given in 13.8.4. If the contents of the MDE received by the target AP do not match the contents advertised in the Beacon and Probe Response frames, the target AP shall reject the Authentication-Confirm frame with status code STATUS_INVALID_MDE. 2102 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Current Target FTO AP AP Successful (secure) session & Data transmission FTO determines it needs to transition to the Target AP 802.11 Authentication-Request (FTAA, RSNE[PMKR0Name], MDE, FTE[SNonce, R0KH-ID]) 802.11 Authentication-Response (FTAA, RSNE[PMKR0Name], MDE, FTE[ANonce, SNonce, R1KH-ID, R0KH-ID]) 802.11 Authentication-Confirm (FTAA, RSNE[PMKR1Name], MDE, FTE[MIC, ANonce, SNonce, R1KH-ID, R0KH-ID], RIC-Request) 802.11 Authentication-Ack(FTAA, RSNE[PMKR1Name], MDE, FTE[MIC, ANonce, SNonce, R1KH-ID, R0KH-ID], RIC-Response) A successful Reassociation occurs only when the time between the Authentication-Request and the Reassociation Request does not exceed the Reassociation Deadline Time Reassociation Request (RSNE[PMKR1Name], MDE, FTE[MIC, ANonce, SNonce, R1KH-ID, R0KH-ID]) Reassociation Response (RSNE[PMKR1Name], MDE, FTE[MIC, ANonce, SNonce, R1KH-ID, R0KH-ID, GTK[N]], IGTK[M]) 802.1X Controlled Port Unblocked, Successful (Secure) Session & Data Transmission Figure 13-9â€”Over-the-air FT resource request protocol in an RSN Current Target FTO AP AP Successful session & Data transmission FTO determines it needs to transition to the Target AP 802.11 Authentication-Request (FTAA, MDE) 802.11 Authentication-Response (FTAA, MDE) 802.11 Authentication-Confirm (FTAA, MDE, RIC-Request) 802.11 Authentication-Ack(FTAA, MDE, TIE(ReassociationDeadline), RIC-Response) A successful Reassociation occurs only when the time between the Authentication-Request and the Reassociation Request does not exceed the Reassociation Deadline Time Reassociation Request (MDE) Reassociation Response (MDE) Successful Session & Data Transmission Figure 13-10â€”Over-the-air FT resource request protocol in a non-RSN 2103 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications In an RSN, the R1KH of the target AP verifies the MIC in the FTE in the Authentication-Confirm frame and shall discard the request if it is incorrect. If the FTE in the Authentication-Confirm frame contains a different R0KH-ID, R1KH-ID, ANonce, or SNonce, the AP shall reject the Authentication-Confirm frame with status code STATUS_INVALID_FTE. If the RSNE in the Authentication-Confirm frame contains an invalid PMKR1Name, the AP shall reject the Authentication-Confirm frame with status code STATUS_INVALID_PMKID. In the Authentication-Ack frame, the SA field of the message header shall be set to the BSSID of the target AP, and the DA field of the message header shall be set to the MAC address of the FTO. In a non-RSN, the FTE and RSNE shall not be present. The Status Code field shall be a value from the options listed in 9.4.1.9. The elements in the frame, the element contents, and MIC calculation shall be as given in 13.8.5. In an RSN, the S1KH of the FTO verifies the MIC in the FTE in the Authentication-Ack frame and shall discard the response if the MIC is incorrect. The FTO may make a request for resources by including a RIC-Request (see 13.11) in the Authentication- Confirm frame. The RIC-Request is generated by the procedures of 13.11.3.1, and the RIC-Response is generated by the procedures of 13.11.3.2. If the value of the Status Code field returned by the target AP in the Authentication-Ack frame is not SUCCESS, then the FTO shall abandon this transition attempt. In an RSN, on successful completion of the FT authentication exchange of the FT resource request protocol, the PTKSA has been established and proven live. The key replay counter shall be initialized to 0, and the subsequent EAPOL-Key frames (e.g., GTK and IGTK updates) shall use the key replay counter to detect and discard replays. The PTKSA shall be deleted by the target AP if it does not receive a Reassociation Request frame from the FTO within the reassociation deadline timeout value. In a non-RSN, the Authentication-Ack frame contains a TIE with a reassociation deadline. If the FTO does not send a Reassociation Request frame to the target AP within that interval, the FTO shall abandon this transition attempt. The exchange between the FTO and the target AP may continue with reassociation (13.7.1 or 13.7.2). 13.6.3 Over-the-DS fast BSS transition with resource request The over-the-DS FT resource request protocol in an RSN is shown in Figure 13-11. The over-the-DS FT resource request protocol in a non-RSN is shown in Figure 13-12. To perform an Over-the-DS FT resource request protocol to a target AP, after completing the FT Request/ Response frame exchange given in 13.5.3 or 13.5.5, the FTO and target AP (through the current AP) shall perform the following exchange, using the mechanism described in 13.10: FTO Target AP: FT Confirm (FTO, TargetAP, RSNE[PMKR1Name], MDE, FTE[MIC, ANonce, SNonce, R1KH-ID, R0KH-ID], RIC-Request) Target AP FTO: FT Ack (FTO, TargetAP, Status, RSNE[PMKR1Name], MDE, FTE[MIC, ANonce, SNonce, R1KH-ID, R0KH-ID], TIE[ReassociationDeadline], RIC-Response) 2104 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Current Target FTO AP AP Successful (secure) session & Data transmission FTO determines it needs to transition to the Target AP FT Request (FTO, TargetAP, RSNE[PMKR0Name], MDE, FTE[SNonce, R0KH-ID]) FT Response (FTO, TargetAP, RSNE[PMKR0Name], MDE, FTE[ANonce, SNonce, R1KH-ID, R0KH-ID]) FT Confirm (FTO, TargetAP, RSNE[PMKR1Name], MDE, FTE[MIC, ANonce, SNonce, R1KH-ID, R0KH-ID], RIC-Request) FT ACK (FTO, TargetAP, RSNE[PMKR1Name], MDE, FTE[MIC, ANonce, SNonce, R1KH-ID, R0KH-ID], TIE(ReassociationDeadline), RIC-Response) , A successful Reassociation occurs only when the time between the FT Request and the Reassociation Request does not exceed the Reassociation Deadline Time Reassociation Request (RSNE[PMKR1Name], MDE, FTE[MIC, ANonce, SNonce, R1KH-ID, R0KH-ID]) Reassociation Response (RSNE[PMKR1Name], MDE, FTE[MIC, ANonce, SNonce, R1KH-ID, R0KH-ID, GTK[N]]) 802.1X Controlled Port Unblocked, Successful (Secure) Session & Data Transmission Figure 13-11â€”Over-the-DS FT resource request protocol in an RSN Current Target FTO AP AP Successful session & Data transmission FTO determines it needs to transition to the Target AP FT Request (FTO, TargetAP, MDE) FT Response (FTO, TargetAP, MDE) FT Confirm (FTO, TargetAP, MDE, RIC-Request) FT ACK (FTO, TargetAP, MDE, TIE(ReassociationDeadline), RIC-Response) , A successful Reassociation occurs only when the time between the FT Request and the Reassociation Request does not exceed the Reassociation Deadline Time Reassociation Request (MDE) Reassociation Response (MDE) Successful Session & Data Transmission Figure 13-12â€”Over-the-DS FT resource request protocol in a non-RSN 2105 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The SME of the FTO initiates the FT Confirm frame to the target AP by issuing an MLME-REMOTE- REQUEST.request primitive with parameters including the contents of the FT Confirm frame (FT Action frame with an FT Action field value indicating FT Confirm) to be sent. The MAC of the FTO transmits this Action frame. For processing at the current AP and target AP, see 13.10. When the MAC of the FTO receives the FT Ack frame (FT Action frame with an FT Action field value indicating FT Ack), it passes it to the SME by use of an MLME-REMOTE-REQUEST.indication primitive, with parameters including the contents of the received Action frame. The STA Address field of the FT Confirm frame shall be set to the MAC address of the FTO, and the Target AP Address field of the FT Confirm frame shall be set to the BSSID of the target AP. The elements in the FT Confirm frame, the element contents, and the MIC calculation shall be as given in 13.8.4. In a non-RSN, the FTE and RSNE shall not be present. If the contents of the MDE received by the target AP do not match the contents advertised in the Beacon and Probe Response frames, the target AP shall reject the FT Confirm frame with status code STATUS_INVALID_MDE. In an RSN, the R1KH of the target AP verifies the MIC in the FTE and shall discard the request if it is incorrect. If the FTE in the FT Confirm frame contains a different R0KH-ID, R1KH-ID, ANonce, or SNonce from the values sent in the FT Response frame, the AP shall reject the FT Confirm frame with status code STATUS_INVALID_FTE. If the RSNE in the FT Confirm frame contains an invalid PMKR1Name, the AP shall reject the FT Confirm frame with status code STATUS_INVALID_PMKID. The STA Address field of the FT Ack frame shall be set to the MAC address of the FTO, and the Target AP Address field of the FT Ack frame shall be set to the BSSID of the target AP. The elements in the FT Ack frame, the element contents, and the MIC calculation shall be as given in 13.8.5. In a non-RSN, the FTE and RSNE shall not be present. The Status Code field value shall be a value from the options listed in 9.4.1.9, and a TIE may appear. In an RSN, the S1KH of the FTO verifies the MIC in the FTE in the FT Ack frame and shall discard the response if the MIC is incorrect. The FTO may make a request for resources by including a RIC-Request (see 13.11) in the FT Confirm frame. The RIC-Request is generated by the procedures of 13.11.3.1, and the RIC-Response is generated by the procedures of 13.11.3.2. In order to recover from over-the-DS packet losses, the FTO may retransmit the FT Confirm frame until the reassociation deadline time is reached. If the FTO does not receive a response to the FT Confirm frame or if the value of the Status Code field returned by the target AP in the FT Ack frame is not SUCCESS, then the FTO shall abandon this transition attempt. In an RSN, on successful completion of the FT Confirm/Acknowledgment frame exchange, the PTKSA has been established and proven live. The key replay counter shall be initialized to 0, and the subsequent EAPOL-Key frames (e.g., GTK and IGTK updates) shall use the key replay counter to detect and discard replays. The PTKSA shall be deleted by the target AP if it does not receive a Reassociation Request frame from the FTO within the reassociation deadline timeout value. Resource request procedures are specified in 13.11. In a non-RSN, the FT Ack frame contains a TIE with a reassociation deadline. If the FTO does not send a Reassociation Request frame to the target AP within that interval, the FTO shall abandon this transition attempt. The exchange between the FTO and the target AP may continue with reassociation (13.7.1 or 13.7.2). 2106 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 13.7 FT reassociation 13.7.1 FT reassociation in an RSN If the FTO does not send a Reassociation Request frame to the target AP within the reassociation deadline interval received during the FT initial mobility domain association, the target AP may delete the PTKSA, and the FTO shall abandon this transition attempt. The FTO shall perform a reassociation directly with the target AP via the following exchange: FTO Target AP: Reassociation Request(RSNE[PMKR1Name], MDE, FTE[MIC, ANonce, SNonce, R1KH-ID, R0KH-ID], RIC-Request) Target AP FTO: Reassociation Response(RSNE[PMKR1Name], MDE, FTE[MIC, ANonce, SNonce, R1KH-ID, R0KH-ID, GTK[N], IGTK[M]], RIC-Response) The SME of the FTO initiates the reassociation through the use of the MLME-REASSOCIATE.request primitive. The SME of the AP responds to the indication with MLME-REASSOCIATE.response primitive. See 11.3.5. In the Reassociation Request frame, the SA field of the message header shall be set to the MAC address of the FTO, and the DA field of the message header shall be set to the BSSID of the target AP. The elements in the frame, the element contents, and the MIC calculation shall be as given in 13.8.4. The R1KH of the target AP verifies the MIC in the FTE in the Reassociation Request frame and shall discard the request if the MIC is incorrect. If the contents of the MDE received by the target AP do not match the contents advertised in the Beacon and Probe Response frames, the target AP shall reject the Reassociation Request frame with status code STATUS_INVALID_MDE. If the FTE in the Reassociation Request frame contains a different R0KH-ID, R1KH-ID, ANonce, or SNonce, the AP shall reject the Reassociation Request frame with status code STATUS_INVALID_FTE. If the RSNE in the Reassociation Request frame contains an invalid PMKR1Name, the AP shall reject the Reassociation Request frame with status code STATUS_INVALID_PMKID. In the Reassociation Response frame, the SA field of the message header shall be set to the BSSID of the target AP, and the DA field of the message header shall be set to the MAC address of the FTO. The Status Code field shall be a value from the options listed in 9.4.1.9. The elements in the frame, the element contents, and the MIC calculation shall be as given in 13.8.5. The S1KH of the FTO verifies the MIC in the FTE in the Reassociation Response frame and shall discard the response if the MIC is incorrect. If an FTO is performing a reassociation exchange as part of the FT resource request protocol, then the FTO shall not include the RIC-Request in the Reassociation Request frame, and the AP shall not include the RIC- Response in the Reassociation Response frame. If the reassociation exchange is part of the FT resource request protocol and the AP is unable to honor the resources that have been placed in the accepted state for that FTO, then the AP shall reject the Reassociation Request frame and may use status code DENIED_INSUFFICIENT_BANDWIDTH. If the FTO did not utilize the FT resource request protocol, the FTO may make a request for resources by including a RIC-Request (see 13.11) in the Reassociation Request frame. The RIC-Request is generated by the procedures of 13.11.3.1, and the RIC-Response is generated by the procedures of 13.11.3.2. 2107 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If the Status Code field value returned by the target AP in the response is REFUSED_REASON_UNSPECIFIED, TRANSACTION_SEQUENCE_ERROR, or REJECTED_SEQUENCE_TIMEOUT, then the FTO shall abandon this transition attempt. Handling of other errors returned in the Status Code field shall be as specified in 11.3. Upon a successful reassociation, the PTKSA has been established and proven live. The SME of the AP shall open the IEEE 802.1X Controlled Port. The FTO shall transition to State 4 (as defined in 11.3). If the target AP is distinct from the previous AP, the FTO shall enter State 1 with respect to the previous AP. Upon a successful reassociation, the FTO shall delete any corresponding PTKSA with its previous AP. The SME of the FTO shall issue an MLME-DELETEKEYS.request primitive to delete the pairwise keys with the previous AP, and the FTO and the AP shall issue an MLME-SETKEYS.request primitive and MLME- SETPROTECTION.request primitive to install the pairwise keys. The PTK lifetime timer shall be initialized with the value calculated as the difference between the TIE[KeyLifetime] sent in message 3 of the FT initial mobility domain association and the time since the completion of the FT 4-way handshake during the FT initial mobility domain association. When the IEEE 802.1X Controlled Port is opened, the EAPOL-Key frame replay counter shall be initialized to 0. The R1KH shall increment the key replay counter on each successive EAPOL-Key frame that it transmits. 13.7.2 FT reassociation in a non-RSN The FTO shall perform a reassociation with the target AP via the following exchange: FTO Target AP: Reassociation Request(MDE, RIC-Request) Target AP FTO: Reassociation Response(MDE, RIC-Response) The SME of the FTO initiates the reassociation through the use of the MLME-REASSOCIATE.request primitive. The SME of the AP responds to the indication with MLME-REASSOCIATE.response primitive. See 11.3.5. In the Reassociation Request frame, the SA field of the message header shall be set to the MAC address of the FTO, and the DA field of the message header shall be set to the BSSID of the target AP. The elements in Reassociation Request frame, and their required contents, shall be as given in 13.8.4. If the contents of the MDE received by the target AP do not match the contents advertised in the Beacon and Probe Response frames, the target AP shall reject the Reassociation Request frame with status code STATUS_INVALID_MDE. In the Reassociation Response frame, the SA field of the message header shall be set to the BSSID of the target AP, and the DA field of the message header shall be set to the MAC address of the FTO. The elements in Reassociation Response frame, and their required contents, shall be as given in 13.8.5. The Status Code field shall be a value from the options listed in 9.4.1.9. If the FTO is performing a reassociation exchange as part of the FT resource request protocol, then the FTO shall not include the RIC-Request in the Reassociation Request frame, and the AP shall not include the RIC- Response in the Reassociation Response frame. If the FTO did not utilize the FT resource request protocol, the FTO may make a request for resources by including a RIC-Request (see 13.11) in the Reassociation Request frame. The RIC-Request is generated by the procedures of 13.11.3.1, and the RIC-Response is generated by the procedures of 13.11.3.2. 2108 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If the Status Code field value returned by the target AP in the response is REFUSED_REASON_UNSPECIFIED, TRANSACTION_SEQUENCE_ERROR, or REJECTED_SEQUENCE_TIMEOUT, then the FTO shall abandon this transition attempt. Handling of other errors returned in the Status Code field shall be as specified in 11.3. If the AP has dot11RSNAActivated equal to true, upon a successful reassociation, the SME shall open the IEEE 802.1X Controlled Port. Upon a successful reassociation, the target AP and the FTO shall transition to State 4 (as defined in 11.3). If the target AP is distinct from the previous AP, then the FTO shall enter State 1 with respect to the previous AP. 13.8 FT authentication sequence 13.8.1 Overview The FT authentication sequence comprises four sets of FT elements. Each set of FT elements is referred to in 13.8 as a message. These messages are included in the FT Protocol frames or FT Resource Request Protocol frames to initiate a fast BSS transition. The FT authentication sequence is always initiated by the FTO and responded to by the target AP. In an RSN, the first two messages in the sequence allow the FTO and target AP to provide association instance identifiers, SNonce and ANonce, respectively. SNonce and ANonce are chosen randomly or pseudorandomly and are used to generate a fresh PTK. The first two messages also enable the target AP to provision the PMK-R1 and the FTO and target AP to compute the PTK. The third and fourth messages demonstrate liveness of the peer, authenticate the elements, and enable an authenticated resource request. When an FTO invokes the FT protocol, then the first two messages of the sequence are both carried in Authentication frames or both carried in Action frames, and these messages are described in 13.8.2 and 13.8.3. The third and fourth messages in the sequence are carried in the Reassociation Request and Reassociation Response frames and are described in 13.8.4 and 13.8.5. When the FTO invokes the FT resource request protocol, then the first four messages of the sequence are all carried in Authentication frames or all carried in Action frames, and these messages are described in 13.8.2 to 13.8.5. The fifth and sixth frames of the FT resource request protocol are carried in the Reassociation Request frame and Reassociation Response frame and are described in 13.8.4 and 13.8.5. Regardless of the transport mechanism, the information contained in the FT authentication sequence consists of the set of elements shown in Table 13-1. The first message is used by the FTO to initiate a fast BSS transition. When RSNA is enabled, the FTO shall include the R0KH-ID and the SNonce in the FTE and the PMKR0Name in the RSNE. The target AP can use the PMKR0Name to derive the PMKR1Name, and if the target AP does not have the PMK-R1 identified by PMKR1Name, it may attempt to retrieve that key from the R0KH identified by R0KH-ID. See 13.2. The FTO includes a fresh SNonce as its contribution to the association instance identifier and to provide key separation of the derived PTK; it is selected randomly to serve as a challenge that demonstrates the liveness of the peer in the fourth message. The second message is used by the target AP to respond to the requesting FTO. The target AP provides the key holder identifiers and key names used to generate the PTK. The target AP also includes a fresh ANonce as its contribution to the association instance identifier and to provide key separation of the derived PTK. The response includes a status code. 2109 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 13-1â€”FT authentication elements Information Presence in Authentication Sequence messages Description RSN The RSNE is present if dot11RSNAActivated is true. 9.4.2.25 Mobility Domain The Mobility Domain element is present. 9.4.2.47 Fast BSS Transition The Fast BSS Transition element is present if 9.4.2.48 dot11RSNAActivated is true. Timeout Interval The Timeout Interval element is optionally present in the 9.4.2.49 (reassociation fourth message of the sequence if dot11RSNAActivated is not deadline) true. RIC The RIC Data element is optionally present in the third and 9.4.2.50 fourth messages. In an RSN, the third message is used by the FTO to assert to the target AP that it has a valid PTK. If no resources are required, then the FTO omits inclusion of the RIC. The fourth message is used by the target AP to respond to the requesting FTO. This message serves as final confirmation of the transition, establishes that the AP possesses the PMK-R1 and is participating in this association instance, and protects against downgrade attacks. Note, however, that the RIC is absent if no resources were requested in the third message. This also includes a status code and may include a reassociation deadline. 13.8.2 FT authentication sequence: contents of first message The RSNE shall be present only if dot11RSNAActivated is true. If present, the RSNE shall be set as follows: â€” Version field shall be set to 1. â€” PMKID Count field shall be set to 1. â€” PMKID List field shall contain the PMKR0Name. â€” All other fields shall be as specified in 9.4.2.25 and 12.6.3. The MDE shall contain the MDID field and the FT Capability and Policy field settings obtained from the target AP, as advertised by the target AP in Beacon and Probe Response frames. The MDID shall be identical to that obtained during the FT initial mobility domain association exchange. The FTE shall be present only if dot11RSNAActivated is true. If present, the FTE shall be set as follows: â€” R0KH-ID shall be the value of R0KH-ID obtained by the FTO during its FT initial mobility domain association exchange. â€” SNonce shall be set to a value chosen randomly by the FTO, following the recommendations of 12.7.5. â€” All other fields shall be set to 0. 13.8.3 FT authentication sequence: contents of second message If the status code is SUCCESS, then the following rules apply. The RSNE shall be present only if dot11RSNAActivated is true. If present, the RSNE shall be set as follows: â€” Version field shall be set to 1. â€” PMKID Count field shall be set to 1. 2110 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” PMKID List field shall be set to the value contained in the first message of this sequence. â€” All other fields shall be identical to the contents of the RSNE advertised by the AP in Beacon and Probe Response frames. The MDE shall contain the MDID and FT Capability and Policy fields. This element shall be the same as the MDE advertised by the target AP in Beacon and Probe Response frames. The FTE shall be present only if dot11RSNAActivated is true. If present, the FTE shall be set as follows: â€” R0KH-ID shall be identical to the R0KH-ID provided by the FTO in the first message. â€” R1KH-ID shall be set to the R1KH-ID of the target AP, from dot11FTR1KeyHolderID. â€” ANonce shall be set to a value chosen randomly by the target AP, following the recommendations of 12.7.5. â€” SNonce shall be set to the value contained in the first message of this sequence. â€” All other fields shall be set to 0. 13.8.4 FT authentication sequence: contents of third message The RSNE shall be present only if dot11RSNAActivated is true. If present, the RSNE shall be set as follows: â€” Version field shall be set to 1. â€” PMKID Count field shall be set to 1. â€” PMKID field shall contain the PMKR1Name. â€” All other fields shall be as specified in 9.4.2.25 and 12.6.3. The MDE shall contain the MDID and FT Capability and Policy fields. This element shall be identical to the MDE contained in the first message of this sequence. The FTE shall be present only if dot11RSNAActivated is true. If present, the FTE shall be set as follows: â€” ANonce, SNonce, R0KH-ID, and R1KH-ID shall be set to the values contained in the second message of this sequence. â€” The Element Count field of the MIC Control field shall be set to the number of elements protected in this frame (variable). â€” When the negotiated AKM is 00-0F-AC:3, 00-0F-AC:4, or 00-0F-AC:9, the MIC shall be calculated using the KCK and the AES-128-CMAC algorithm. The output of the AES-128-CMAC shall be 128 bits. â€” The MIC shall be calculated on the concatenation of the following data, in the order given here: â€” FTOâ€™s MAC address (6 octets) â€” Target APâ€™s MAC address (6 octets) â€” Transaction sequence number (1 octet), which shall be set to the value 5 if this is a Reassociation Request frame and, otherwise, set to the value 3 â€” RSNE â€” MDE â€” FTE, with the MIC field of the FTE set to 0 â€” Contents of the RIC-Request (if present) â€” All other fields shall be set to 0. If resources are being requested by the FTO, then a sequence of elements forming the RIC-Request shall be included. 2111 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 13.8.5 FT authentication sequence: contents of fourth message If the status code is SUCCESS, then the following rules apply. The RSNE shall be present only if dot11RSNAActivated is true. If present, the RSNE shall be set as follows: â€” Version field shall be set to 1. â€” PMKID Count field shall be set to 1. â€” PMKID field shall contain the PMKR1Name â€” All other fields shall be identical to the contents of the RSNE advertised by the target AP in Beacon and Probe Response frames. The MDE shall contain the MDID and FT Capability and Policy fields. This element shall be identical to the MDE contained in the second message of this sequence. The FTE shall be present only if dot11RSNAActivated is true. If present, the FTE shall be set as follows: â€” ANonce, SNonce, R0KH-ID, and R1KH-ID shall be set to the values contained in the second message of this sequence. â€” The Element Count field of the MIC Control field shall be set to the number of elements protected in this frame (variable). â€” When this message of the authentication sequence appears in a Reassociation Response frame, the Optional Parameter(s) field in the FTE may include the GTK and IGTK subelements. If a GTK or an IGTK are included, the Key field of the subelement shall be encrypted using KEK and the NIST AES key wrap algorithm. The Key field shall be padded before encrypting if the key length is less than 16 octets or if it is not a multiple of 8. The padding consists of appending a single octet 0xdd followed by zero or more 0x00 octets. When processing a received message, the receiver shall ignore this trailing padding. Addition of padding does not change the value of the Key Length field. Note that the length of the encrypted Key field can be determined from the length of the GTK or IGTK subelement. â€” When the negotiated AKM is 00-0F-AC:3, 00-0F-AC:4, or 00-0F-AC:9, the MIC shall be calculated using the KCK and the AES-128-CMAC algorithm. The output of the AES-128-CMAC algorithm shall be 128 bits. â€” The MIC shall be calculated on the concatenation of the following data, in the order given here: â€” FTOâ€™s MAC address (6 octets) â€” Target APâ€™s MAC address (6 octets) â€” Transaction sequence number (1 octet), which shall be set to the value 6 if this is a Reassociation Response frame or, otherwise, set to the value 4 â€” RSNE â€” MDE â€” FTE, with the MIC field of the FTE set to 0 â€” Contents of the RIC-Response (if present) â€” All other fields shall be set to 0. If this message is other than a Reassociation Response frame and dot11RSNAActivated is false, a TIE may appear. If this message is other than a Reassociation Response frame, includes a RIC-Response, and dot11RSNAActivated is false, then a timeout interval shall appear. If it appears, it shall be set as follows: â€” Timeout Interval Type field shall be set to 1 (reassociation deadline) â€” Timeout Interval Value field shall be set to the reassociation deadline time. If resources were requested by the FTO, then a RIC-Response shall be included. 2112 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 13.9 FT security architecture state machines 13.9.1 Introduction The FT state machines describe the interaction between the RSNA key management and IEEE 802.11 architectural components. RSNA key management uses the MA-UNITDATA service primitives to send/receive EAPOL-Key frames for FT initial association; MLME interfaces described below for FT methods; and MLME-SETKEYS, MLME-DELETEKEYS, and MLME-SETPROTECTION primitives. FT key management uses the following primitives for key management delivery and reception: â€” The MLME-REMOTE-REQUEST primitives for FT key management over the DS â€” The MLME-AUTHENTICATE primitives for FT key management over the air â€” The MLME-RESOURCE-REQUEST primitives for FT resource request over the air â€” The MLME-REASSOCIATE primitives for FT key management over the air and over the DS Some of the state machine design considerations are as follows: â€” Details of error handling are not included in the state machines. See 13.4, 13.5, and 13.6. â€” Retransmission of FT Authentication and (Re)Association frames are not included in the state machines; see 13.5 and 13.6. Various signals are used to communicate between the R0KH and the R1KH state machines. Note that these interactions may be between separate entities, rather than within a single SME. These interactions are as follows: â€” In the R0KH state machine, FT-PMKR1-SA (PMKR1-SA) sends a PMK-R1 PMKSA to the R1KH. â€” In the R1KH state machine, FT-FULL-AUTH (R1KH-ID) requests a key from the R0KH. â€” In the R1KH state machine, FT-Transition-Auth (R1KH-ID) requests a key from the R0KH that was used for the initial mobility domain association. The interactions between the R0KH and IEEE Std 802.1X, between the R1KH and IEEE Std 802.1X, and between the S1KH and IEEE Std 802.1X occur within the SME. At both the target AP and at the FTO, the R1KH and S1KH initialize the IEEE 802.1X EAPOL state machines in the respective SMEs. The Controlled Port is opened without an EAP exchange when the reassociation completes. 13.9.2 R0KH state machine 13.9.2.1 General There is one R0KH state machine, which includes FT key management. The state diagram in Figure 13-13 consists of a set of states that handle R0KH functions including key hierarchy instantiation, key generation, and cleanup. This state machine interacts with the R1KH state machine. 2113 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications FT-Full-Auth(R1KH-ID), from FT-INIT-GET-R1_SA FT-R0-AUTH Initial-Assoc = true (802.1X::keyAvailable && 802.1X::keyRun) || PSK CALC-PMK-R0 Derive-key-PMK-R0() Invalidate previous PMK-R0-SA UCT CALC-PMK-R0-IDLE PMK-R0-lifetime-expire Check PMK-R0 lifetime !PMK-R0-lifetime-expire !PMK-R0-lifetime-expire && && Initial-Assoc FT-Transition-Auth(R1KH-ID) from R1 SM && Authorized(R1KH-ID) CALC-PMK-R1 FT-R0-AUTH-CLEANUP Remove PMK-R0-SA Initial-Assoc = false !Push-PMK-R1 Push-PMK-R1 FT-R0-SEND-PMKR1SA FT-PMK-R1-SA-PUSH Derive-Key-PMK-R1() For each List-R1KH-ID: FT-PMKR1-SA(PMK-R1-SA) to R1 SM Derive-Key-PMK-R1() UCT Distribute(List-R1KH-IDs, PMK-R1-SA) UCT Figure 13-13â€”R0KH state machine 13.9.2.2 R0KH state machine states The following list summarizes the states of the R0KH state machine: â€” CALC-PMK-R0: This state is entered after the MSK from EAP authentication or PSK is available. â€” CALC-PMK-R0-IDLE: This state is an intermediate state for the R0KH to wait for new requests from R1KHs. â€” CALC-PMK-R1: For FT initial association, this state is entered as an unconditional transfer. For FT methods, this state is entered through the event from an R1KH state machine. â€” FT-PMK-R1-SA-PUSH: This state is entered if Push-PMK-R1 is true. PMK-R1s are derived and distributed to all of the configured R1KHs. â€” FT-R0-AUTH-CLEANUP: This state is entered when the PMK-R0 lifetime expires. â€” FT-R0-AUTH: This state is entered through the event from the R1KH state machine. The R1KH state machine sends this event when it determines that a new PMK-R0 is needed. â€” FT-R0-SEND-PMKR1SA: This state is entered from CALC-PMK-R1 when a request for the PMK-R1 security association is received from an R1KH. PMK-R1 security association is derived and distributed to the requesting R1KH. 2114 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 13.9.2.3 R0KH state machine variables The following list summarizes the variables used by the R0KH state machine: â€” Initial-Assoc â€“ This variable is used to indicate whether the current authentication is the initial association, in order to trigger the initial derivation of PMK-R1. â€” List-R1KH-IDs â€“ This variable contains a list of all of the R1KH-IDs in the mobility domain. This list is populated by the key distribution protocol as required in 13.2. â€” PMK-R0-lifetime-expire â€“ This variable is set to true when PMK-R0 lifetime is deemed expired. â€” PSK â€“ This variable is set to true when authentication is performed by use of a preshared key. â€” Push-PMK-R1 â€“ This variable is set to true when R0KH can push the PMK-R1 security associations to R1KHs. 13.9.2.4 R0KH state machine procedures The following list summarizes the procedures used by the R0KH state machine: â€” Authorized(R1KH-ID) â€“ This procedure returns a value of true if the R1KH is a known key holder in the mobility domain. â€” Distribute (List-R1KH-IDs, PMK-R1 PMKSA) â€“ Distributes the PMK-R1-SAs for the current instance of the key hierarchy to the list of R1KH-IDs. â€” Derive-Key-PMK-R0() â€“ This procedure derives the PMK-R0 from the MSK or PSK, derives the PMKR0Name (as described in 12.7.1.7.3), and creates PMK-R0 security association. â€” Derive-Key-PMK-R1 (R1KH-ID) â€“ From the PMK-R0, and the R1KH-ID (as described in 12.7.1.7.4) for the R1KH identified by R1KH-ID, this procedure derives the PMK-R1 and creates a PMK-R1 security association. 13.9.3 R1KH state machine 13.9.3.1 General The R1KH state machine includes functions for FT initial association and FT protocols. The R1KH states performing FT initial association and the R1KH states performing FT protocol exchanges interact differently with the R0KH state machine. The R1KH state machine and other portions of the SME are defined in Figure 13-14 and Figure 13-15 and consist of a set of states that handle FT initial mobility domain association, PMK-R1 reception, PTK handshake and session establishment, FT protocols (including resource requests), and cleanup. This state machine interacts with the R0KH state machine to generate a fresh FT key hierarchy for the initial mobility domain association and to get the PMK-R1 security association (PMK-R1 PMKSA) for the FT protocols. While the figures show the over-the-air message exchanges, the over-the-DS exchanges are handled similarly. A new instance of the R1KH state machine is created each time initial mobility domain association or fast BSS transition is initiated. 2115 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Init R1-START MLME-AUTHENTICATE.indication(FTAA, SNonce,R0KH-ID, PMKR0Name) MLME-AUTHENTI CATE.indication(Open) To FT-AUTH FT-INIT-AUTH MLME-AUTHENTICATE.res pons e(Open) MLME-ASSOCIATE.indication || MLME-REASSOCIATE.indication FT-INIT-ASSOC 802.1X::portControl = Auto 802.1X::portValid = false 802.1X::portEnabled = true MLME-ASSOCIATE.res pons e() or MLME-REASSOCIATE.res pons e() Reass ocdeadlinetimerexpEv t UCT FT-INIT-GET-R1_SA R0-TimeoutEvt ReAuthenticationR equest = false FT-Full-Auth(R1KH-ID), to FT-R0-AUTH R0KH SM FT-PMKR1-SA(PMK-R1-SA) PTK-RekeyRequest FT-INIT-R1_SA Calculate ANonce TimeoutCtr = 0 TimeoutEvt && PTK-Rekey Request = false TimeoutCtr â‰¤ N UCT FT-PTK-START TimeoutEvt && TimeoutCtr > N Send EAPOL-Key (0, 0, 1, 0, P, 0, ANonce, 0) TimeoutCtr++ EAPOLKeyReceiv ed && EAPOLKeyReceiv ed && !Request && !Request && K == Pairwise K == Pairwise FT-PTK-CALC-NEGOTIATING PTK= Calc FT-PTK () TimeoutCtr = 0 TimeoutEvt MIC-Verified FT-PTK-CALC-NEGOTIATING3 Send EAPOL-Key (1, 1, 1, 1, P, 0, ANonce, MIC, RSNE[PMKR1Name], MDE, GTK[N], IGTK[M], FTE, TE[ReassociationDeadline], TE[KeyLifetime])) TimeoutCtr > N TimeoutCtr ++ EAPOLKeyReceiv ed && !Request && K == Pairwise && MIC-Verified DISCONNECT FT-PTK-INIT-DONE Deauthenticate the STA MLME-SETKEYS.request(Pairwise) Invalidate PT K MLME-SETPROTECTION.request(STA,Rx_Tx, pairwise) MLME-DELETEKEYS.request(PTK) 802.1X::portEnabled = true 802.1X:portEnabled = false 802.1X::portValid = true 802.1X:portValid = false 802.1X::keyAvailable = false 802.1X::portControl = Auto 802.1X::keyDone = true Figure 13-14â€”R1KH state machine, including portions of the SME (part 1) 2116 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications R1-START MLME-AUTHENTICATE.indication(Open) to FT-INIT-AUTH MLME-AUTHENTICATE.indication(FTAA, SNonce,R0KH-ID, PMKR0Name) FT-AUTH FT-GET-PMK-R1-SA 802.1X::portControl = Auto 802.1X::portValid-= false !PMK-R1-SA FT-Transition-Auth(R1KH-ID) to 802.1X::portEnabled = false CALC-PMK-R0-IDLE R0KH SM R0-TimeoutEvt PMK-R1-SA To DISCONNECT FT-PMK-R1-SA-RECD Calc. ANonce FT-PMKR1-SA(PMK-R1-SA) from FT-R0-SEND- Reassocdeadlinetimerexp = Reassoc-deadline PMKR1SA R0KH SM && PMK-R1-SA MLME-AUTHENTICATE.response(FTAA, ANonce, SNonce, MD-ID, R1KH-ID, PMK-R1-Name) PTK= Calc FT-PTK () MLME-RESOURCE_REQUEST.indication MLME-SETKEYS.request(Pairwise) (ANonce, SNonce, MD-ID, RSNE, PMKR1Name, RIC-Req) && MIC-Verified MLME-SETPROTECTION.request(FTO,Rx_Tx, Pairwise) FT-RV-HANDSHAKE-NEGOTIATING MLME-REASSOCIATE.indication(ANonce, SNonce, MD-ID, Resv-Flow = true R0KH-ID, R1KH-ID, PMK-R1Name, RIC) && MIC-Verified MLME-RESOURCE_REQUEST.response (ANonce, SNonce, MD-ID, RSNE, PMKR1Name, RIC-Resp) FT-HANDSHAKE-DONE MLME-REASSOCIATE.response(ANonce, SNonce, MD-ID, MLME-REASSOCIATE.indication(ANonce, R0KH-ID, R1KH-ID, PMK-R1-Name, GTK, IGTK, RIC-Resp) SNonce, MD-ID, R0KH-ID, R1KH-ID, PMK- (If Resv-Flow, then do not include RIC-Resp in this msg) R1Name) && MIC-Verified 802.1X::portEnabled = true 802.1X::portValid = true 802.1X::eapRestart SKIP-EAP 802.1X::eapRestart = false 802.1X::eapSuccess = true 802.1X::eapFail = false Figure 13-15â€”R1KH state machine, including portions of the SME (part 2) 13.9.3.2 R1KH state machine states The following list summarizes the states of the R1KH state machine: â€” DISCONNECT: This state is entered when the current session ends or when errors occur. â€” FT-AUTH: This state is entered upon receipt of an indication that an FT protocol or FT resource request protocol is invoked. â€” FT-GET-PMK-R1-SA: This state is entered when R1KH sends a message to the R0KH to get the PMK-R1-SA. â€” FT-HANDSHAKE-DONE: This state is entered when reassociation indication parameters are validated. The Reassociation Response frame is then sent. â€” FT-INIT-ASSOC: This state is entered upon receipt of a (Re)Association Request frame during initial mobility domain association. 2117 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” FT-INIT-AUTH: This state is entered upon receipt of an indication that initial association is invoked. â€” FT-INIT-GET-R1_SA: This state is entered when the R1KH determines that a new key hierarchy is required. â€” FT-INIT-R1_SA: This state is entered on receiving the PMK-R1-SA from the R0KH and when rekeying the PTK. â€” FT-PMK-R1-SA-RECD: This state is entered on receiving the PMK-R1-SA from the R0KH. An FT Authenticate response is sent in this state. This state then calculates the PTK and delivers the key to the MAC. â€” FT-PTK-INIT-DONE: This state is entered on successful validation of the fourth EAPOL-Key frame. In this state, keys are provided to the MAC. â€” FT-PTK-CALC-NEGOTIATING: This state is entered when a second EAPOL-Key frame is received. â€” FT-PTK-CALC-NEGOTIATING3: This state is entered on successful validation of the second EAPOL-Key frame. In this state, the third EAPOL-Key frame is sent. â€” FT-PTK-START: This state is entered when the PMK-R1-SA is present. This state is the beginning of the 4-way handshake to derive a fresh PTK. â€” FT-RV-HANDSHAKE-NEGOTIATING: This state is entered when an FT resource request is received. The FT resource response is sent. â€” R1-START: This is the start of the R1KH state machine. â€” SKIP-EAP: This state is entered after successful completion of the FT protocol. In this state, the EAPOL state machine is triggered to open the IEEE 802.1X port. 13.9.3.3 R1KH state machine variables The following list summarizes the variables used by the R1KH state machine: â€” Init â€“ This variable is set to true to initialize the R1KH the state machine. â€” EAPOLKeyReceived â€“ This variable is set to true when an EAPOL-Key frame is received. â€” K â€“ This variable is one of the values of the Key Type bit in the EAPOL-Key frame received and is either Pairwise or Group. â€” MIC-Verified â€“ This variable is set to true when the message authentication code integrity check passes. â€” Pairwise â€“ This variable is one of the values of the Key Type bit in the EAPOL-Key frame. â€” PMK-R1-SA â€“ This variable is set to true when a valid PMK-R1-SA is present at the R1KH. â€” PTK-RekeyRequest â€“ This variable is set to true when a PTK rekey request is received. â€” Reassocdeadlinetimerexp â€“ This variable contains the reassociation deadline timer value. â€” ReassocdeadlinetimerexpEvt â€“ This variable is set to true when the reassociation deadline timer expires. â€” Request â€“ This variable is the value of the Request bit in the Key Information field in the EAPOL- Key frame. â€” Resv-flow â€“ This variable is set to true when an indication of an FT resource request protocol is received. â€” R0-TimeoutEvt â€“ This variable is set to true when the timeout for R0KH authentication expires (e.g., when the EAP authentication session timeout expires). â€” TimeoutCtr â€“ This variable contains the number of successive timeouts waiting for protocol responses. â€” TimeoutEvt â€“ This variable is set to true when a timeout for receiving EAPOL-Key response expires. 2118 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 13.9.3.4 R1KH state machine procedures The following list summarizes the procedure used by the R1KH state machine: â€” Calc-FT-PTK() â€“ This procedure calculates the PTK. 13.9.4 S0KH state machine 13.9.4.1 General There is one S0KH state machine within the Supplicant, defined in Figure 13-16, which incorporates the FT initial association and key management. FT-Full-Auth(R1KH-ID) from FT-INIT-START S1KH SM FT-R0-AUTH Initial-Assoc = true 802.1X::suppKeyAvailable && PSK 802.1X::keyRun CALC-PMK-R0 Derive-Key-PMK-R0() Invalidate previous PMK-R0-SA UCT CALC-PMK-R0-IDLE Check PMK-R0 lifetime expiration FT-Transition-Auth(R1KH-ID) from Initial-Assoc FT-START S1KH SM CALC-PMK-R1 Derive-Key-PMK-R1() Initial-Assoc = false FT-PMKR1-SA(PMK-R1-SA) to FT-INIT-R1-SA S1KH SM UCT Figure 13-16â€”S0KH state machine 13.9.4.2 S0KH state machine states The following list summarizes the states of the S0KH state machine: â€” CALC-PMK-R0: This state is entered after the key is received, either from the EAP authentication or from the PSK. â€” CALC-PMK-R0-IDLE: This state is entered after the PMK-R0 has been calculated and either continues with initial association or waits for requests from an S1KH for a PMK-R1. 2119 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” CALC-PMK-R1: For FT initial association, this state is entered as an unconditional transfer. For FT protocols, this state is entered through the event from the S1KH state machine. In this state, the PMK-R1 is sent to the S1KH. â€” FT-R0-AUTH: This state is entered when the FT-Full-Auth event occurs during initial association in the S1KH state machine. The S1KH state machine sends this event when it determines that a new PMK-R0 is needed. 13.9.4.3 S0KH state machine variables The following list summarizes the variables used by the S0KH state machine: â€” Initial-Assoc â€“ This variable is used to indicate whether the current authentication is the initial association, in order to trigger the initial derivation of PMK-R1. â€” PSK â€“ This variable is set to true when authentication is performed by use of a preshared key. 13.9.4.4 S0KH state machine procedures The following list summarizes the procedures used by the S0KH state machine: â€” Derive-Key-PMK-R0() â€“ This procedure derives the PMK-R0 and PMKR0Name and creates PMK-R0 security association. â€” Derive-Key-PMK-R1 (R1KH-ID) â€“ This procedure derives the PMK-R1 and PMKR1Name from PMK-R0 for the indicated R1KH and creates PMK-R1 security association. 13.9.5 S1KH state machine 13.9.5.1 General The S1KH state machine includes functions for fast BSS transitions, including initial association. The S1KH state machine and other portions of the SME are defined in Figure 13-17 and Figure 13-18 and consist of a set of states that handle FT initial association, PTK handshake and session establishment, resource requests, cleanup, and teardown. This state machine interacts with the S0KH state machine to generate a fresh key hierarchy. 13.9.5.2 S1KH state machine states The following list summarizes the states of the S1KH state machine: â€” DISCONNECT: This state is entered when the current session expires. â€” FT-AIR-REQUEST: This state is entered when it is determined that an over-the-air FT method is to be executed. This state sends the Authentication-Request frame over the air. â€” FT-DONE: This state is entered when a Reassociation Response frame is received. â€” FT-DS-REQUEST: This state is entered when it is determined that an over-the-DS FT method is to be executed. This state sends the Authentication-Request frame over the DS. â€” FT-INIT: This state is entered when an FT method is initiated. â€” FT-INIT-ASSOC: This state is entered when authentication for initial mobility domain association has been completed. â€” FT-INIT-AUTH: This state is entered when an FT initial association event is initiated. â€” FT-INIT-START: This state is entered when association for initial mobility domain association has been completed. â€” FT-INIT-R1-SA: This state is entered on receiving the PMK-R1-SA from the S0KH and when the Authenticator is starting PTK rekeying by sending out EAPOL-Key frame 1. 2120 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Init R1-START !FT-Initial-Association To FT-INIT FT-Initial-Association FT-INIT-AUTH MLME-AUTHENTICATE.request(Open) MLME-AUTHENTICATE.confirm() FT-INIT-ASSOC MLME-ASSOCIATE.request() or MLME-REASSOCIATE.request() Reassocdeadlinetimerexp MLME-ASSOCIATE.confirm() || MLME-REASSOCIATE.confirm() FT-INIT-START 802.1X::portControl = Auto 802.1X::portValid = false 802.1X::portEnabled = true FT-Full-Auth(R1KH-ID) to S0KH SM FT-PMKR1-SA(PMK-R1-SA) from FT-R0-SEND-PMKR1SA FT-INIT-R1-SA EAPOL-Key Received && !Request && MesgNo == 1 Calculate SNonce && !Initial-Assoc EAPOL-Key Received && !Request && MesgNo == 1 FT-PTK-START Process EAPOL-Key frame EAPOL-Key Received && TPTK = Calc-FT-PTK() !Request && MesgNo == 1 Send EAPOL-Key (0, 1, 0, 0, P, 0, SNonce, MIC-KCK, RSNE[PMKR1Name], MDE, FTE) EAPOL-Key Received && !Request && MIC-Verified && MesgNo == 3 FT-PTK-CALC-NEGOTIATING EAPOL-Key Received && PTK = TPTK !Request && MIC-Verified Send EAPOL-Key (1, 1, 0, 0, P, 0, 0, && MesgNo == 3 MIC-KCK) UCT FT-PTK-INIT-DONE DISCONNECT MLME-SETKEYS.request(Pairwise) Deauthenticate the FTO MLME-SETPROTECTION.request(FTO,Rx_Tx, Pairwise) Invalidate PTK 802.1X::portEnabled = true MLME-DELETEKEYS.request(PTK) 802.1X::portValid = true 802.1X::portEnable = false 802.1X::suppKeyAvailable = false 802.1X::portValid = false 802.1X::keyDone = true Initial-Assoc = false Figure 13-17â€”S1KH state machine, including portions of the SME (part 1) 2121 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Init R1- START FT-Initial- Association to FT- INIT - AUTH !FT-Initial - Association FT- INIT 802.1X:: portValid = false 802.1X:: portEnabled= false 802.1X:: portControl= Auto UCT FT- START Calculate SNonce 802.1X:: portEnabled= true TimeoutCtr=0 Over-the- Air && FT- PMK-R1- SA from S0KH SM Over-the- DS && FT- PMK-R1-SA from S0 KH SM TimeoutEvt && TimeoutEvt && FT-AIR - REQUEST FT-DS - REQUEST TimeoutCtr > N TimeoutCtr> N MLME- AUTHENTICATE. request MLME- REMOTE- REQUEST. request TimeoutEvt ( FTAA, MDE, FTE [SNonce], TimeoutEvt ( FTAA,MDE,FTE[ SNonce],RSNE && TimeoutCtr RSNE [ PMKR0Name ] ,R0KH-ID) && TimeoutCtr [ PMKR0Name ], R0KH-ID) â‰¤N â‰¤N TimeoutCtr ++ TimeoutCtr ++ MLME- AUTHENTICATE.confirm MLME-REMOTE-REQ UEST.indication FT- PTK -CALC ! PTK- Lifetime- Valid || ! PMK-R1- lifetime- Valid Reassocdeadlinetimer = Reassoc deadline To DISCONNECT FT - Transition-Auth(R1KH-ID ) to CALC-PMK-R 1 S0KH SM Calc-FT- PTK() , TimeoutCtr =0 MLME-SETKEYS. request (P airwise) MLME-SETPROTECTION.request (AP , Rx_Tx, Pairwise ) Resource- Request && Over- the- Air Resource - Request && Over- the- DS ! Resource- Request FT- RV- AIR- CONFIRM FT- RV- DS- CONFIRM MLME-RESOURCE - REQ UEST.request MLME-REMOTE- REQ UEST. request TimeoutCtr TimeoutCtr >N ( ANonce, SNonce, MDE, RSNE, ( ANonce, SNonce, MDE, RSNE, >N PMK-R1 Name, RIC- Req) PMK-R1 Name, RIC- Req) TimeoutCtr ++ TimeoutCtr ++ TimeoutEvt TimeoutEvt MLME- RESOURCE- REQ UEST.confirm ( ANonce, MLME-REMOTE- REQ UEST.indication SNonce, MDE, RSNE, PMK-R1 Name, RIC- Resp) ( ANonce, SNonce, MDE, RSNE, && MIC - Verified FT- RESERVE PMK-R1 Name, RIC- Resp) && MIC- TimeoutCtr=0 Verified UCT FT- NO- RV- CONFIRM FT- RESERVE -2 TimeoutCtr MLME - REASSOCIATE. request ( MDE, MLME- REASSOCIATE. request( MDE, TimeoutCtr >N FTE( ANonce, SNonce, R0KH-ID , FTE( ANonce, SNonce,R0KH-ID , >N PMK-R1 Name, MIC, RSNE, RIC- Req ) PMK-R1 Name, MIC, RSNE) TimeoutCtr++ TimeoutCtr++ MLME -REASSOCIATE. confirm ( ANonce, MLME- REASSOCIATE. confirm( ANonce, SNonce, MDE, R0KH-ID , R1KH-ID , PMK- TimeoutEvt TimeoutEvt SNonce, MDE, R0KH-ID , R1KH-ID , PMK- R1 Name, RIC- Resp) && MIC- Verified R1 Name) && MIC- Verified FT- DONE To 802.1X:: portEnabled = true 802.1X:: portValid = true 802.1X:: eapolEap = true DISCON - 802.1X:: eapRestart NECT To SKIP-EAP DISCONNECT 802.1X:: eapolEap = false 802.1X:: eapSuccess = true 802.1X:: eapNoResp = true 802.1X:: eapRestart = false 802.1X:: eapFail = false Figure 13-18â€”S1KH state machine, including portions of the SME (part 2) 2122 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” FT-NO-RV-CONFIRM: This state is entered when performing FT protocol (i.e., not the FT resource request protocol). This state is entered for both over-the-air and over-the-DS processing. This state sends the Reassociation Request frame. â€” FT-PTK-CALC: This state is entered when the over-the-air Authentication-Response frame is received if an over-the-air Authentication-Request frame was sent or when over-the-DS FT Response frame is received if an over-the-DS FT Request frame was sent. The PTK is calculated and installed in the MAC. â€” FT-PTK-INIT-DONE: This state is entered after sending the fourth EAPOL-Key frame. This state establishes the PTK into the MAC. â€” FT-PTK-CALC-NEGOTIATING: This state is entered when a valid, third EAPOL-Key frame is received. This state sends the fourth EAPOL-Key frame. â€” FT-PTK-START: This state is entered to derive a new PTK when the PMK-R1-SA is present and when the EAPOL-Key 4-way handshake message 1 is received. This state sends the EAPOL-Key 4- way handshake message 2. â€” FT-RESERVE: This state is entered when the over-the-air Authentication-Ack frame is received if an over-the-air Authentication-Confirm frame was sent or when over-the-DS FT Ack frame is received if an over-the-DS FT Confirm frame was sent. â€” FT-RESERVE-2: The Reassociation Request frame is sent in this state after completion of FT resource request. â€” FT-RV-AIR-CONFIRM: This state is entered for over-the-air FT resource request protocol processing. The Authentication-Confirm frame containing the FT resource request is sent. â€” FT-RV-DS-CONFIRM: This state is entered for over-the-DS FT resource request protocol processing. The Authentication-Confirm frame containing the FT resource request is sent. â€” FT-START: This state is entered when all FT parameters are validated and FT needs to be initiated. â€” R1-START: This is the start of the S1KH state machine. â€” SKIP-EAP: This state is entered after successful completion of the FT protocol. In this state, the EAPOL state machine is triggered to open the IEEE 802.1X port. 13.9.5.3 S1KH state machine variables The following list summarizes the variables used by the S1KH state machine: â€” EAPOLKeyReceived â€“ This variable is set to true when an EAPOL-Key frame is received. â€” FT-Initial-Association â€“ This variable is set to true when the S1KH is performing an initial association. â€” Init â€“ This variable is set to true to initialize the S1KH state machine. In addition, this variable is used to restart the state machine when transitioning to a new AP. â€” MesgNo â€“ In conjunction with EAPOLKeyReceived, this variable indicates which message in the 4- way handshake has been received. â€” MIC-Verified â€“ This variable is set to true when the message authentication integrity check is valid. â€” N â€“ This variable contains the limit of timeout events before considering the transition a failure. â€” Over-the-Air â€“ This variable is set to true when the FT protocol is to be exchanged over the air. Note that both Over-the-Air and Over-the-DS cannot be equal to true at the same time. â€” Over-the-DS â€“ This variable is set to true when the FT protocol is to be exchanged over the DS. Note that both Over-the-Air or Over-the-DS cannot be equal to true at the same time. â€” PMK-R1-Lifetime-Valid â€“ This variable is set to true when the PMK-R1 lifetime is valid. â€” PTK-Lifetime-Valid â€“ This variable is set to true when the PTK lifetime is valid. â€” Reassocdeadlinetimer â€“ This variable contains the reassociation deadline timer value. 2123 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” ReassocdeadlinetimerExp â€“ This variable is set to true when the reassociation deadline timer expires. â€” Resource-request â€“ This variable is set to true when the FT resource request protocol is to be executed. â€” TimeoutCtr â€“ This variable contains the number of successive timeouts waiting for protocol responses. â€” TimeoutEvt â€“ This variable is set to true when a timeout event occurs. â€” TPTK â€“ This variable contains the newly calculated PTK, which is installed after receipt of message 3 of the 4-way handshake. 13.9.5.4 S1KH state machine procedures The following list summarizes the procedure used by the S1KH state machine: â€” Calc-FT-PTK() â€“ This procedure calculates the PTK. 13.10 Remote request broker (RRB) communication 13.10.1 Overview The RRB mechanism allows the FTO to communicate with a target AP through the FTOâ€™s existing association (with the current AP). The FTO transmits an FT Action frame (including the address of the FTO and the BSSID of the target AP) to the current AP. The current AP includes the contents of the FT Action frame (Request or Confirm) inside a Remote Request frame and transmits it to the target AP over the DS. The target AP processes the remote request and responds to the FTO by sending an FT Action frame (Response or Acknowledgment) through the current AP. The SME of the FTO initiates an exchange with a target AP by issuing an MLME-REMOTE- REQUEST.request primitive with parameters including the contents of the FT Action frame to be sent. The MAC of the FTO transmits this Action frame. When the MAC of the current AP receives an FT Action frame, it passes it to the RRB by use of an MLME-REMOTE-REQUEST.indication primitive, with parameters including the contents of the received Action frame. When the RRB of the current AP has received a response from the target AP, it uses the MLME-REMOTE- REQUEST.request primitive to send the response, as an FT Action frame, to the requesting FTO. The MAC of the current AP transmits this Action frame. When the MAC of the FTO receives an FT Action frame, the MAC passes the Action frame to the SME by use of an MLME-REMOTE-REQUEST.indication primitive, with parameters including the contents of the received Action frame. 13.10.2 Remote request broker (RRB) The RRB resides in the SME on the APs and acts as a forwarding agent (at the current AP) and termination point (at the target AP) for protocol messages over the DS. The RRB allows APs that are part of the same mobility domain to exchange information over the DS. APs that advertise the same MDID shall be reachable over the DS and support the over-the-DS communication. As a termination point, when the RRB at the target AP receives a request frame from the current AP, it interacts with the MAC and other parts of the SME to process the request and respond with a Remote Response frame, through the RRB on the current AP, back to the requesting FTO. As a forwarding agent, when the RRB at the current AP receives a request from an FTO directed to another AP in the same mobility domain, the current AP forwards the request to that target AP. The RRB on the 2124 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications current AP converts Action frames into Remote Request frames and converts Remote Response frames into Action frames. The target AP and the current AP need to reside in the same mobility domain to successfully exchange Remote Request frames. The RRB on the current AP shall transmit Remote Request frames to the target AP based on the BSSID of the target AP (supplied in the FT Action frames) using the same procedures as preauthentication, as described in 12.6.10.2. The message flow for a resource request over the DS is given in Figure 13-19. The FTO indicates the destination target AP BSSID as part of the FT Action frame. The RRB on the current AP encapsulates the FT Action frame and supplies the current AP BSSID in the Remote Request frame. FTO Current AP Target AP Successful (secure) session & Data transmission FT Action Request (Request elements) RemoteRequest ( current AP Address, FT Action Request ) The Request is forwarded Target AP from current AP to target AP. processes RemoteResponse ( current AP Address, request FT Action Response ) FT Action Response (Response elements) FT Action Confirm (Confirm elements) RemoteRequest ( current AP Address, FT Action Confirm ) Target AP processes RemoteResponse ( current AP Address, confirmation. FT Action Acknowledge ) FT Action Acknowledgment (Acknowledgment elements) Figure 13-19â€”Sample message flow for over-the-DS resource request 13.10.3 Remote Request/Response frame definition This subclause defines a mechanism to transport the remote request and remote response between the current AP and the target AP. Any other mechanism may be used. The Remote Request frame is transmitted over the DS from the current AP to the target AP. The Payload for the Remote Request/Response frame is given in Table 13-2. Remote Request/Response frames shall use an Ethertype of 89-0d, as specified in Annex H. The Remote Request/Response frame contains Version, Type, and Length fields, along with the AP Address. 2125 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 13-2â€”Remote Request/Response Payload format Size Information 1 FT Packet Type 2 FT Action Length 6 AP Address Variable FT Action Frame The FT Packet Type field shall be set to 0 for remote request and to 1 for remote response. The FT Action Length field shall be set to an unsigned number representing the length in octets of the FT Action Frame field, following the bit ordering conventions of 9.2.2. The AP Address field shall be set to the BSSID of the current AP. The target AP shall use this address as the destination address when sending the Remote Response frame as a response to the Remote Request. The FT Action Frame field shall be set to the contents of the FT Action frame, from the Category field to the end of the Action frame body. 13.11 Resource request procedures 13.11.1 General When using the resource request procedure, the FTO has the option to request a resource allocation at the target AP. To request resources, the FTO creates a resource information container (RIC) and inserts it in an appropriate request message to the target AP. The request message is sent to the target AP either directly (over the air), or via the current AP (over the DS), according to the FT procedures described in 13.5 and 13.6. In an RSNA, resource requests and responses are exchanged only after the establishment of the PTK and are protected by MICs. The RIC contains a complete list of resources requested by the FTO. An AP that receives a resource request from an FTO shall discard any previous resource request from that FTO. In an RSN, this resource request shall first be authenticated by the AP through checking of the MIC before the AP discards any previous resource request. If an FTO is performing a fast BSS transition according to the FT protocol, described in 13.5, it shall generate a RIC and process the RIC-Response according to the procedures of 13.11.3.1, performing the exchange in the Reassociation Request/Response frames. If an FTO is performing a fast BSS transition according to the FT resource request protocol, described in 13.6, it shall generate a RIC and process the RIC-Response according to the procedures of 13.11.3.1, performing the exchange in the Authentication-Confirm/Authentication-Ack frames (over the air) or FT Confirm/FT Ack frames (over the DS). 13.11.2 Resource information container (RIC) The RIC refers to a collection of elements that are used to express a resource request or response. When used in making a request, a RIC has one or more Resource Requests, as shown in Figure 13-20. 2126 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Resource Request Resource Request Resource Request Figure 13-20â€”RIC-Request format Each Resource Request consists of an RDE followed by one or more alternative Resource Descriptors. An example of a Resource Request is shown in Figure 13-21. RDE Resource Descriptor Figure 13-21â€”Resource Request format Each Resource Descriptor consists of one or more elements. The possible Resource Descriptors that may appear in a RIC, and the elements that they contain, are given in Table 13-3. Table 13-3â€”Resource types and resource descriptor definitions Resource type Resource Descriptor definition Notes 802.11 QoS In a request: TSPEC (see 9.4.2.30), followed May be sent by a QoS STA that is an FTO to a by zero or more TCLAS (see 9.4.2.31), QoS AP. Definition of TSPEC elements shall followed by zero or one TCLAS Processing be as given in 11.4. Definition of TCLAS, (see 9.4.2.33), followed by zero or one TCLAS Processing, Expedited Bandwidth Expedited Bandwidth Request elements Request, and Schedule elements, and the rules (see 9.4.2.94). for including them in requests and responses, shall be as given in 11.4. Resource request In a response: a TSPEC element (see procedures shall be as given in 11.4. 9.4.2.30), followed by zero or one Schedule elements (see 9.4.2.34), followed by zero or more Delay elements (see 9.4.2.32), followed by other optional elements as specified in 11.4. Block Ack In a request: RIC Descriptor (see 9.4.2.51), Resource request procedures shall be as given Parameters containing a Resource Type field identifying in 11.5. Block Ack. In a response: RIC Descriptor (see 9.4.2.51), containing a Resource Type field identifying Block Ack. Vendor Specific RDE is followed by any vendor-specific elements required to specify this resource. If there are multiple Resource Descriptors, then they are treated as choices by the target AP. The AP attempts to allocate whatever is specified in the first Resource Descriptor; if this fails, the AP attempts to allocate whatever is specified in the next Resource Descriptor instead, and so on until a successful allocation or the AP reaches the end of the Resource Descriptor list. Thus, an OR relationship exists between Resource Descriptors that follow an RDE, with the Resource Descriptors appearing in order of preference. An example of a Resource Request consisting of two alternative Resource Descriptors is shown in Figure 13-22. RDE Resource Descriptor Resource Descriptor Figure 13-22â€”Resource Request example #1 2127 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications For example, when the resource being requested is QoS for downstream traffic, a TSPEC element may be followed by one or more TCLAS elements and, when multiple TCLAS elements are present, a TCLAS Processing element and an Expedited Bandwidth Request (EBR) element. Such an example Resource Request with two alternative TSPECs, the second of which has an EBR, is shown in Figure 13-23. RDE TSPEC TCLAS TCLAS TCLAS TSPEC TCLAS TCLAS TCLAS EBR Processing Processing Figure 13-23â€”Resource Request example #2 An example of a RIC with two resource requests, each with a single TSPEC, is given in Figure 13-24. RDE TSPEC RDE TSPEC Figure 13-24â€”RIC-Request example #1 An example of a RIC with one resource request, with a choice of two TSPECs, is given in Figure 13-25. This indicates that the target AP can select one of the two TSPECs. RDE TSPEC TSPEC Figure 13-25â€”RIC-Request example #2 An example of a RIC with a RIC Descriptor is given in Figure 13-26. The target AP can acknowledge if the resource specified in the RIC Descriptor is available. RDE RIC Descriptor (BlockAck) Figure 13-26â€”RIC-Request example #3 When sent by an AP in response to a RIC-Request, the RIC-Response consists of a list of one or more Resource Responses including one response for each of the Resource Requests that was contained in the RIC-Request. The basic format of a RIC-Response is shown in Figure 13-27. Resource Response Resource Response Resource Response Figure 13-27â€”RIC-Response format Each Resource Response consists of an RDE with the RDE identifier matching the RDE identifier in the request, in the same order as the RDEs appeared in the request. The RDE is followed by zero or one Resource Descriptors. If the request was not successful (as indicated in the RDE status), then the AP may include a suggestion that could have been successful. If the resource request was successful, then the particular Resource Descriptor (of the alternatives given by the FTO) is included in the response, as modified by the AP during the processing of the resource request. For example, when the resource being requested is QoS for upstream traffic, the TSPEC element may be followed by a Schedule element. An example of a RIC-Response with two QoS resource responses, each with a single TSPEC and Schedule element, is given in Figure 13-28. RDE TSPEC Schedule RDE TSPEC Schedule Figure 13-28â€”Example QoS RIC-Response 2128 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 13.11.3 Creation and handling of a resource request 13.11.3.1 FTO procedures The resource request enables an FTO to request resources based on specified Resource Descriptors (e.g., TSPECs) before or at the time the FTO associates with the target AP. In using TSPECs for requesting QoS resources, the TSPECs in the request need not belong to only active TSs; the FTO can send TSPECs for any TS that it intends to use after the transition and request the same resources that would be requested by a later ADDTS exchange. For each resource, the FTO may provide the AP with a choice of Resource Descriptors in order of preference, any one of which meets the needs of the application. The FTO shall construct the RIC with a number of Resource Requests, each delineated by an RDE. The FTO shall indicate the resources required at the target AP. For QoS resources, each TS shall be requested by a separate RDE and associated TSPEC(s). The RDE Identifier field in the RDE shall be an arbitrary value chosen by the FTO that uniquely identifies the RDE within the RIC. The Status Code field shall be set to SUCCESS, and the Resource Count field shall be set to the number of alternative Resource Descriptors that follow. Following each RDE, the FTO shall include one or more Resource Descriptors that define the resources required for this TS. When multiple TSPECs follow an RDE as part of a single QoS resource request, a logical â€œORâ€ relationship exists between them, and at most one of these TSPECs shall be accepted by the AP. The FTO shall order the Resource Descriptors in decreasing order of preference. In generating the RDE for QoS resources for a TS, the procedures of 11.4 shall be followed for the generation of TSPECs and inclusion of TCLAS, TCLAS Processing, and Expedited Bandwidth Request elements. If the TS is a downstream flow, then the RDE may also include one or more TCLAS element(s) (defined in 9.4.2.31) and a TCLAS Processing element (defined in 9.4.2.33) if multiple TCLAS elements are included, and an optional Expedited Bandwidth Request (EBR) element, defined in 9.4.2.94. If present, the TCLAS shall appear after the corresponding TSPEC. If present, an EBR element shall appear after the corresponding TSPEC, TCLAS, and TCLAS Processing elements of the TSPEC. A resource request is considered successful if the status code SUCCESS is returned in each RDE. If the frame containing the response to the resource request contains a status code other than SUCCESS, the FTO considers that the request has failed and that no resources are being held at the target AP. The response from the target AP contains a RIC-Response, with the RDEs in the response indicating which resources were considered by the target AP and the setting of the status code indicating which Resource Descriptors were accepted by the AP. The RDE Identifier field in the RDE enables the FTO to match the response with the RDE in the request. The value of the Status Code field is interpreted as follows: â€” Status code = SUCCESS indicates that the request has been accepted. The RDE may be followed by the Resource Descriptor that was accepted. â€” Status code = not SUCCESS (one of the values from 9.4.1.9) indicates that the resources could not be accepted. The RDE may be followed by a suggested Resource Descriptor that could have been accepted. A response to a successful resource request (other than in a Reassociation Request frame) may contain a reassociation deadline. If the FTO does not initiate a Reassociation Request frame with the target AP within the reassociation deadline (if appropriate), then the AP releases resources held for that FTO. 2129 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 13.11.3.2 AP procedures When a RIC appears in a request message, the AP shall check its ability to allocate one resource for each RDE in the RIC in the order appearing in the RIC. In a Reassociation Request frame, the QoS Capability element shall be processed prior to the QoS resource requests in the RIC. The behavior of the AP shall be identical to that described in the flowchart in Figure 13-29. Start Select first RDE Select first Resource Descriptor Able to accept this resource No request? More Select next Yes Resource Resource Descriptors? Yes Descriptor Set status value to 0 Skip rest of this RDE No Set status to an appropriate value given in 9.4.1.9 More RDEs? No Yes Select next Exit RDE Figure 13-29â€”Overview of RIC processing at an AP As shown in Figure 13-29, the Resource Descriptors are examined by the AP in the order presented, and the first that could have been allocated is accepted. Thus the preference ordering by the FTO is honored. 2130 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The target APâ€™s SME examines the resource requests in the RIC. For requests that require processing by the MAC sublayer, the SME generates an MLME-RESOURCE-REQUEST-LOCAL.request primitive. The MAC shall respond with MLME-RESOURCE-REQUEST-LOCAL.confirm primitive that indicates whether the MAC has accepted the resource request. The SME may also send these resource requests to an external entity such as a backend QoS module for its consideration; these procedures are beyond the scope of this standard. The acceptance of a TSPEC by the target AP results in the resource allocation for a TS at the target AP. In response to a RIC-Request, the AP shall construct a RIC-Response. The RIC-Response shall contain one RDE for each RDE in the RIC-Request. The RDEs shall be in the same order as in the request, and the RDE Identifier field in each RDE shall be the value of the RDE Identifier field in the corresponding RDE in the request. The Status Code field in the RDE shall be set according to the result of the allocation request as follows: â€” Status code = SUCCESS indicates that the resource request has been accepted. The RDE shall also be followed by the Resource Descriptor that was accepted. â€” Status code = not SUCCESS indicates that the resources could not be accepted. The Status Code field contains a value from 9.4.1.9 indicating the reason for the failure. In this case, the AP may include a single Resource Descriptor following the RDE indicating a suggested resource that could have been accepted. The Resource Count field shall be set to 0 or 1 depending whether the suggested Resource Descriptor is attached. A not SUCCESS status code in an RDE shall not cause a not SUCCESS status code in the frame containing the RIC. If the resource request included QoS resources and is successful, then the procedures for handling of TSPEC, TCLAS, TCLAS Processing and Expedited Bandwidth Request elements shall be as specified in 11.4, and the AP shall place the TSs into the accepted state. The RIC-Response shall contain the updated accepted TSPEC. Each RDE may also include a Schedule element (as defined in 9.4.2.34) after the accepted TSPEC. Upon reassociation, AP shall move all of the TSs from the accepted state into the active state. If the FTO does not invoke a reassociation within the reassociation deadline, then the TSs that had been accepted shall become inactive, and the resources shall be released. At the point that the FTO reassociates with the target AP (within the reassociation deadline, if appropriate), the TSs are put into the active state. This may be immediate if the RIC-Request was part of a Reassociation Request frame. 2131 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 14. MLME mesh procedures 14.1 Mesh STA dependencies When dot11MeshActivated is true, the STA is a mesh STA. When dot11MeshActivated is true, following MIB attributes shall be true. â€” dot11QosOptionImplemented â€” dot11ExtendedChannelSwitchActivated (only when dot11SpectrumManagementRequired is true) When dot11MeshActivated is true, following MIB attributes shall be false. â€” dot11OCBActivated â€” dot11FastBSSTransitionActivated A mesh STA does not support functionalities that depend on AP or are only available in an infrastructure BSS, such as HCCA, traffic specifications (TSPECs), traffic stream (TS) management, admission control, automatic power save delivery (APSD), direct-link setup (DLS), or tunneled direct-link setup (TDLS). An HT mesh STA does not support PSMP, STBC, or PCO. When dot11DMGOptionImplemented is true, dot11MeshActivated shall be false. 14.2 Mesh discovery 14.2.1 General A mesh STA shall perform either active scanning or passive scanning to discover an operating mesh BSS using the MLME-SCAN.request primitive (see 6.3.3). A mesh profile, a set of parameters identifying the mesh BSS configuration, is also obtained through the scanning process, and it is used to determine the scanning mesh STAâ€™s active mesh profile. Based on the result of the scan, the mesh STA may establish a new mesh BSS or become a member of the existing mesh BSS, using the START primitive (see 6.3.11). The MLME-START.request primitive triggers beaconing that facilitates the discovery of the mesh STA by the neighbor mesh STAs. A mesh STA that becomes a member of a mesh BSS should establish a mesh peering with one or more neighbor mesh STAs that are in the same mesh BSS. 14.2.2 Mesh identifier The Mesh ID is an identifier of an MBSS. The Mesh ID may be installed in mesh capable devices by a variety of means that are beyond the scope of this standard. For example, the Mesh ID might be set by the user, e.g., â€œMikeâ€™s Mesh.â€ A mesh STA shall include the Mesh ID element (see 9.4.2.99) in its Beacon and Probe Response frames, in order to advertise its identity. The mesh STA shall also include the Mesh ID element in its Mesh Peering Open frames, Mesh Peering Confirm frames, and Mesh Peering Close frames. The mesh STA shall set the SSID element (see 9.4.2.2) in Beacon, Probe Request, and Probe Response frames to the wildcard SSID. NOTEâ€”The wildcard SSID is used to notify nonmesh STAs that the mesh STA is neither a part of an infrastructure BSS nor an IBSS, so that the nonmesh STAs do not try to join the mesh BSS. 2132 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 14.2.3 Mesh profile A mesh profile is a set of parameters that specifies the attributes of a mesh BSS. A mesh profile consists of the following: a) A Mesh IDâ€”specified by dot11MeshID b) A path selection protocol identifierâ€”specified by dot11MeshActivePathSelectionProtocol c) A path selection metric identifierâ€”specified by dot11MeshActivePathSelectionMetric d) A congestion control mode identifierâ€”specified by dot11MeshActiveCongestionControlMode e) A synchronization method identifierâ€”specified by dot11MeshActiveSynchronizationMethod f) An authentication protocol identifierâ€”specified by dot11MeshActiveAuthenticationProtocol In a mesh BSS all mesh STAs use the same mesh profile. Two mesh profiles are considered to be the same if all of their parameters match. Before establishing a mesh BSS or becoming a member of a mesh BSS, a mesh STA shall configure one mesh profile. The mesh STA shall not change its mesh profile unless it leaves the mesh BSS of which it is a member. When the mesh STA leaves the mesh BSS of which it is a member, it should explicitly close all of its active mesh peerings using Mesh Peering Close frames (see 14.3.8) and shall discard all session information obtained while the mesh profile was active, such as local forwarding information, security associations (and related keys), etc. The MLME receives the mesh STAâ€™s mesh profile from the SME upon receipt of the MLME-START.request primitive. The mesh profile is signaled by means of the Mesh ID element and the Mesh Configuration element. The mesh profile is included in the Beacon and Probe Response frames, so that the mesh profile can be obtained by its neighbor mesh STAs through scanning. Mesh Peering Open and Mesh Peering Confirm frames also contain a mesh profile. 14.2.4 Mesh STA configuration The mesh STA configuration consists of the mesh profile (see 14.2.3), the Supported Rates and BSS Membership Selectors element, the Extended Supported Rates and BSS Membership Selectors element, the HT Operations element (if present), and the VHT Operations element (if present). Mesh STA configurations are identical if the following conditions hold: â€” The mesh profiles are identical. â€” The BSSBasicRateSet parameter of the MLME-START.request is identical to the basic rate set indicated by the Supported Rates and BSS Membership Selectors element and Extended Supported Rates and BSS Membership Selectors element, if present, received in the MLME- MESHPEERINGMANAGEMENT.indication. â€” For HT mesh STAs, the Basic HT-MCS Set field of the HT Operation parameter of the MLME- START.request is identical to the HT Operation element received in the MLME- MESHPEERINGMANAGEMENT.indication. â€” For VHT mesh STAs, the Basic VHT-MCS and NSS fields in the VHT Operation element of the MLME-START.request are identical to the Basic VHT-MCS and NSS fields in the VHT Operation element received in the MLME-MESHPEERINGMANAGEMENT.indication. 14.2.5 Supplemental information for the mesh discovery A mesh STA shall signal whether it is able to establish additional mesh peerings. A mesh STA signals its ability to establish additional mesh peerings by setting the Accepting Additional Mesh Peerings subfield in the Mesh Capability field in the Mesh Configuration element to 1 (see 9.4.2.98.8). 2133 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The mesh STA sets the Accepting Additional Mesh Peerings subfield in the Mesh Capability field in the Mesh Configuration element to 0 when it is not able to accept new mesh peerings. This parameter is dynamically controlled by the SME and given to the MLME by dot11MeshAcceptingAdditionalPeerings. NOTEâ€”This control is driven by internal policies. When the Accepting Additional Mesh Peering subfield is 1, the mesh STA is assumed to have sufficient internal resources to accommodate more mesh peerings. The internal policy is outside the scope of this standard. For instance, a mesh STA might be configured to be able to maintain only two mesh peerings. A mesh STA shall announce its topological information through the Mesh Formation Info field in the Mesh Configuration element. The contents of the Mesh Formation Info field shall be coded to reflect the current configuration. 14.2.6 Scanning mesh BSSs A mesh STA shall perform active scanning or passive scanning, depending on the value of the ScanMode parameter of the MLME-SCAN.request primitive (see 11.1.4), to discover neighbor mesh STAs. Upon receipt of an MLME-SCAN.request primitive with the Mesh ID parameter set to the wildcard Mesh ID, the STA shall passively scan for any Beacon frames, or actively transmit Probe Request frames containing the wildcard Mesh ID, as appropriate, depending on the value of ScanMode. Upon completion of scanning, an MLME-SCAN.confirm primitive is issued by the MLME indicating all of the discovery information received. Further, a mesh STA shall comply with the passive scan procedure as described in 11.1.4.2 and the active scan procedure as described in 11.1.4.3. 14.2.7 Candidate peer mesh STA When a mesh STA discovers a neighbor mesh STA through the scanning process and the discovered mesh STA is considered a candidate peer mesh STA, it may become a member of the mesh BSS of which the discovered mesh STA is a member and establish a mesh peering with the neighbor mesh STA. The discovered neighbor mesh STA shall be considered a candidate peer mesh STA if and only if all of the following conditions are met: a) The mesh STA uses the same mesh profile as the received Beacon or Probe Response frame indicates for the neighbor mesh STA. NOTEâ€”If the scanning mesh STA has not become a member of any MBSS yet, it might simply activate the same mesh profile as the discovered neighbor mesh STAâ€™s profile to fulfill this condition. b) The Accepting Additional Mesh Peerings subfield in the Mesh Capability field in the received Beacon or Probe Response frame equals 1. c) The mesh STA supports the data rates indicated by the BSSBasicRateSet of the received Beacon or Probe Response frame. d) If both the scanning mesh STA and the discovered neighbor STA are HT STAs, the STA has the same value in the Basic HT-MCS Set field of the HT Operation parameter of the MLME- START.request primitive as the received Beacon or Probe Response frame indicates for the neigh- bor mesh STA. e) If both the scanning mesh STA and the discovered neighbor STA are VHT STAs, the mesh STA uses the same value for the Basic VHT-MCS And NSS Set field in its VHT Operation element as received in the Beacon or Probe Response frame from the neighbor mesh STA. f) If the scanning mesh STA has dot11MeshSecurityActivated equal to true and the dot11MeshActiveAuthenticationProtocol is ieee8021x (2), either the scanning mesh STA has an active connection to an AS or the discovered mesh STA has the Connected to AS subfield in the Mesh Formation field in the Mesh Configuration element equal to 1 in the received Beacon or Probe Response frame. 2134 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 14.2.8 Establishing or becoming a member of a mesh BSS The Mesh Formation Info field in the Mesh Configuration element is available to assist scanning mesh STAs in choosing the mesh BSS of which to become a member. The details of the usage of this information are beyond the scope of this standard. NOTEâ€”Selection of the mesh BSS of which the scanning mesh STA becomes a new member is outside the scope of this standard. That is, the mesh STA might freely select the mesh BSS of a candidate peer mesh STA of which it becomes a new member. After the determination of the active mesh profile, the mesh STA may establish a new mesh BSS or become a new member to an existing mesh BSS. When dot11MBCAActivated is true, the mesh STA shall perform the TBTT selection procedure described in 14.13.4.3 using TimeStamp, Local Time, Beacon Period, and Beacon Timing in the BSSDescriptionSet parameter given by the MLME-SCAN.confirm primitive, before starting its beaconing. When dot11MCCAActivated is true, the mesh STA shall choose a DTIM interval with a duration of 2n 100 TU with n a non-negative integer less than or equal to 17. NOTEâ€”It is allowed that a different value for the DTIM interval is used for mesh STAs that use MCCA in an MBSS that is centrally controlled and the central authority provides a coordination of the DTIM interval of mesh STAs that use MCCA in the MBSS. The mesh STA establishes a new mesh BSS by activating a mesh profile that is different from any mesh profile discovered during the scanning of mesh BSSs (see 14.2.6). The mesh STA becomes a new member of an existing mesh BSS by activating the same mesh profile as received from a candidate peer mesh STA of this mesh BSS (see 14.2.6 and 14.2.7). In either case, the mesh STA shall start beaconing using the START primitive. Upon receipt of the MLME- START.request primitive, the mesh STA shall initialize and start its TSF timer as specified by its active synchronization method as described in 14.13.2, and begin transmitting Beacon frames as described in 14.13.3. If the mesh STA has become a new member of an existing mesh BSS, it should establish a mesh peering with one or more candidate peer mesh STAs of this mesh BSS (see 14.2.9) in order to form the MBSS. If the mesh STA has become a new member of an existing mesh BSS, it shall adopt the BSSBasicRateSet parameter from a candidate peer mesh STA of this mesh BSS. After establishing or becoming a member of an MBSS, the mesh STA may continue the discovery procedure described in 14.2.6 to discover other candidate peer mesh STAs. 14.2.9 Establishing mesh peerings Mesh peerings shall be established only with candidate mesh STAs that are members of the same MBSS. A mesh peering is established between the mesh STA and the candidate peer mesh STA after the successful completion of the mesh peering management (MPM) protocol (see 14.3) or of the authenticated mesh peering exchange (AMPE) (see 14.5). When establishing a secure mesh peering, mesh STAs authenticate each other and create a mesh PMKSA before processing the AMPE (see 14.3.3). A candidate peer mesh STA becomes a peer mesh STA when a mesh peering is established between the two mesh STAs. 2135 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications When dot11MeshActiveSynchronizationMethod is neighborOffsetSynchronization (1), a mesh STA may establish mesh peerings with up to dot11MeshNbrOffsetMaxNeighbor mesh STAs (see 14.13.2.2.1). 14.3 Mesh peering management (MPM) 14.3.1 General The mesh peering management (MPM) protocol is used to establish, maintain, and close mesh peerings between mesh STAs when dot11MeshSecurityActivated is false. When dot11MeshSecurityActivated is true, the peers establish an authenticated mesh peering using the authenticated mesh peering exchange (AMPE) protocol. The AMPE protocol requires an existing mesh PMKSA. If a mesh PMKSA with the candidate peer mesh STA exists, the AMPE shall use that mesh PMKSA. If no mesh PMKSA exists, the peers shall first authenticate to establish a mesh PMKSA; see 14.5. Figure 14-1 shows the logical flow of protocol interactions in the peering management framework. Candidate peer discovery N Security enabled? Y N MPM Shared PMK N N MPM N API is SAE? succeeds? exists? succeeds? Y Y Y Y SAE N authentication succeeds? Y IEEE 802.1X N authentication succeeds? Y AMPE N succeeds? Y Mesh peering Mesh peering security association Figure 14-1â€”Logical flowchart of protocol interaction in the mesh peering management framework 2136 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The MPM protocol uses Mesh Peering Open frames, Mesh Peering Confirm frames, and Mesh Peering Close frames to establish, manage, and tear down a mesh peering. The protocol succeeds in establishing a mesh peering when the following requirements are satisfied: 1) both mesh STAs have sent and received (and correctly processed) a Mesh Peering Open frame for this mesh peering; 2) both mesh STAs have sent and received (and correctly processed) a corresponding Mesh Peering Confirm frame for this mesh peering. A mesh STA that receives and accepts a Mesh Peering Open frame (see 14.3.6.2) shall assign a unique AID among its neighbor peer mesh STAs to the transmitter of the frame. Since the AID is used in the encoding of the TIM element in the Beacon frame (see 9.4.2.6), the setting of the AID value is constrained as described in 9.4.1.8. AID 0 (zero) is reserved to indicate the presence of buffered group addressed MSDUs and MMPDUs (see 14.14.4). 14.3.2 State variable management A mesh STA keeps an enumerated state variable (see 11.3.1) for each neighbor STA with which direct communication via the WM is needed. This state variable expresses the relationship between the local STA and a neighbor STA that varies depending on the active authentication protocol. It takes on the values shown in Table 14-1. Table 14-1â€”State variables for mesh STAs Active authentication State None SAE IEEE Std 802.1X State 1 Initial start state, mesh peering Initial start state, Initial start state, not established unauthenticated, mesh peering unauthenticated, mesh peering not established not established State 2 N/A Authenticated, mesh peering N/A not established State 3 Mesh peering established Authenticated, mesh peering Unauthenticated, mesh established peering established (Pending IEEE 802.1X authentication) State 4 N/A N/A Authenticated, mesh peering established The state transitions in accordance with the protocol interaction shown in Figure 14-1. The current state existing between the neighbor STAs determines the IEEE 802.11 frame types that may be exchanged between that pair of STAs (see Clause 9). The allowed frame types are grouped into classes and the classes correspond to the STA state. The allowed frame types and the frame classes in each state are defined in 11.3.3. A mesh STA shall not transmit frames other than the ones used for candidate peer mesh STA discovery, MPM, and SAE to a neighboring mesh STA until a mesh peering has been established with the mesh STA. 14.3.3 Mesh authentication See 12.6.1.3.4. 2137 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 14.3.4 Mesh peering instance controller 14.3.4.1 Overview A mesh STA uses a mesh peering instance controller to manage all mesh peering instances. The mesh peering instance controller performs the following functions: â€” Create and delete MPM finite state machines and AMPE finite state machines â€” Manage instance identifiers for each mesh peering instance â€” Manage mesh TKSAs for each mesh peering instance when dot11MeshSecurityActivated is true â€” Preprocess the incoming mesh peering Management frames and pass the frames to the finite state machine with matching instance identifier â€” Pass internal commands to the finite state machine with matching instance identifier A mesh peering instance is identified by a mesh peering instance identifier. The mesh peering instance identifier is the set of localLinkID, localMAC, and peerMAC. A mesh peering instance consists of its identifier (the localLinkID, localMAC, peerMAC), a peerLinkID (an integer generated by the peer mesh STA or candidate peer mesh STA), and the configuration and capability negotiated and agreed upon by exchanging Mesh Peering Open frames (see 9.6.16.2) and Mesh Peering Confirm frames (see 9.6.16.3). If dot11MeshSecurityActivated is true, the mesh peering instance also contains a PMKID identifying the shared PMKSA, a localNonce chosen by the mesh STA and a peerNonce chosen by the peer mesh STA or candidate peer mesh STA. The localMAC is the MAC address of the mesh STA that is managing this mesh peering instance. The peerMAC is the MAC address of the peer mesh STA or the candidate peer mesh STA. The localLinkID is an integer generated by the mesh STA. The localLinkID shall be unique among all existing link identifiers used by the mesh STA for its MPM finite state machines. The mesh STA selects the localLinkID to provide high assurance that the same number has not been used to identify a recent MPM finite state machine. The peerLinkID is the localLinkID of the peer mesh STA or candidate peer mesh STA and is supplied in the Mesh Peering Management element (see 9.4.2.102) of the Mesh Peering Open and Mesh Peering Confirm frames. A mesh peering instance is controlled by an MPM finite state machine (see Table 14-2 in 14.4.5) or an AMPE finite state machine (see Table 14-3 in 14.5.6.3). 14.3.4.2 Creating a new mesh peering instance The mesh peering instance controller creates a new mesh peering instance after either of the following two events: â€” The receipt of a Mesh Peering Open frame from a candidate peer mesh STA according to the rules of 14.3.5 â€” The receipt of an MLME-MESHPEERINGMANAGEMENT.request primitive with a Mesh Peering Open frame A unique localLinkID shall be generated for the mesh peering instance. If the mesh peering instance is established by AMPE, a random local nonce shall also be generated. A mesh STA may create multiple mesh peering instances to establish a peering with the same candidate peer mesh STA. 2138 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 14.3.4.3 Deleting mesh peering instances The mesh peering instance controller deletes a mesh peering instance after either: â€” Expiration of a holding timer (see 14.4.4). â€” The acceptance of a peerâ€™s response to an existing request to close the peering (see 14.4.3). â€” Indication from the SME that the peer mesh STA, or candidate peer mesh STA, has deauthenticated. When the deletion occurs, the mesh TKSA that is bound to the mesh peering shall be deleted. 14.3.5 Mesh peering instance selection The content of a mesh peering Management frame received from a candidate peer mesh STA, and the set of mesh peering instances in the mesh peering instance controller determine whether â€” A new mesh peering instance is created (see 14.3.4.2); or, â€” An existing mesh peering instance is updated If dot11MeshSecurityActivated is true and the mesh STA shares a PMK with the candidate peer mesh STA but the Mesh Peering Protocol Identifier field in the Mesh Peering Management element of the frame indicates â€œmesh peering management protocol,â€ the frame shall be silently discarded. If dot11MeshSecurityActivated is true and the mesh STA shares a PMK with the candidate peer mesh STA but either the Mesh Peering element or the MIC element are not present in the frame, the frame shall be silently discarded. If dot11MeshSecurityActivated is false but the Mesh Peering Protocol Identifier field in the Mesh Peering Management element of the received frame indicates â€œauthenticated mesh peering exchange,â€ the frame shall be silently discarded. If dot11MeshSecurityActivated is false but either the Mesh Peering element or the MIC element is present in the frame, the frame shall be silently discarded. If the frame contains a group address in TA or RA, it shall be silently discarded. If the incoming mesh peering Management frame is for AMPE and the Chosen PMK from the received frame contains a PMKID that does not identify a valid mesh PMKSA, the frame shall be silently discarded. If the mesh peering Management frame has not been silently discarded, the mesh peering instance controller attempts to locate a matching mesh peering instance identifier. A match is determined by comparing the contents of the mesh peering Management frame with each peering instance. A match is found if all of the following conditions are true: â€” The transmitterâ€™s MAC address (Address 2) is the same as the peerMAC of the mesh peering instance â€” The receiverâ€™s MAC address (Address 1) is the same as the localMAC of the mesh peering instance â€” The value of the Peer Link ID field is the same as the localLinkID of the mesh peering instance If the incoming frame is a Mesh Peering Open frame and no matching peering instance was found, a new mesh peering instance is created (and a new Mesh TSKA if dot11MeshSecurityActivated is true). See 14.3.4.2. If the incoming frame is a Mesh Peering Confirm or Mesh Peering Close frame and no matching mesh peering instance is found, it shall be silently discarded. 2139 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If the incoming mesh peering Management frame is for AMPE and has not been discarded it shall be further processed as follows: â€” If the Peer Nonce field is present in the received frame, and the localNonce in the mesh peering instance is different from the Peer Nonce field of the received frame, the frame shall be dropped. â€” If the peerNonce in the mesh peering instance exists and is different from the Local Nonce field of the received frame, the frame shall be dropped. 14.3.6 Mesh peering open 14.3.6.1 Generating Mesh Peering Open frames A Mesh Peering Open frame is generated as a result of a sendOpen() action (see 14.4.3). The contents of the frame are described in 9.6.16.2.2. 14.3.6.2 Mesh Peering Open frame processing The mesh STA checks that the Mesh ID element and Mesh Configuration element of the Mesh Peering Open frame is identical to its own mesh STA configuration as specified in 14.2.3 and 14.2.4. If a mismatch is found the frame shall be rejected with a reason code of MESH-CONFIGURATION-POLICY-VIOLATION and the mesh peering establishment attempt shall be terminated. When the mesh STA has established a mesh PMKSA with the candidate peer mesh STA, the mesh peering instance controller shall silently discard the Mesh Peering Open frame in the following two conditions: â€” The Mesh Peering Open frame supports MPM protocol and the negotiated active authentication is SAE, or â€” The Mesh Peering Open frame supports AMPE but the PMKID in the Chosen PMK field in the Authenticated Mesh Peering Exchange element does not identify a mesh PMKSA. If the Mesh Peering Open frame is not discarded, the mesh peering instance controller actively rejects or accepts the mesh peering open request (see 14.4). If dot11MeshAcceptingAdditionalPeerings is set to 0 the Mesh Peering Open request shall be rejected with reason code MESH-MAX-PEERS. If the peerLinkID in the mesh peering instance has not been set, the Local Link ID field of the Mesh Peering Open request shall be copied into the peerLinkID in the mesh peering instance. If the incoming Mesh Peering Open frame is for AMPE and the peerNonce in the mesh peering instance has not been set, the Local Nonce field in the incoming Mesh Peering Open frame shall be copied into the peerNonce in the mesh peering instance. The mesh peering open request may be rejected due to an internal reason with a reason code of MESH- PEERING-CANCELED. NOTEâ€”Example internal reasons to reject new mesh peering request could be the mesh STA is configured to reject mesh peering request from another specific peer mesh STA. If the Mesh Peering Open request is rejected, the REQ_RJCT event shall be passed with the specified reason code to the protocol finite state machine to actively reject the mesh peering open request. 14.3.7 Mesh peering confirm 14.3.7.1 Generating Mesh Peering Confirm frames A Mesh Peering Confirm frame is generated as a result of a sendConfirm() action (see 14.4.3). 2140 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The contents of the frame are described in 9.6.16.3.2. 14.3.7.2 Mesh Peering Confirm frame processing The mesh STA shall check that the Mesh ID element and Mesh Configuration element of the Mesh Peering Confirm frame match its own mesh STA configuration as specified in 14.2.3 and 14.2.4. If a mismatch is found, the frame shall be rejected with the reason code of MESH-INCONSISTENT-PARAMETERS. If the Mesh Peering Confirm frame is rejected, the REQ_RJCT event shall be passed with the specified reason code to the protocol finite state machine to actively reject the mesh peering confirm. Otherwise, the mesh STA accepts the Mesh Peering Confirm frame and performs the actions described in 14.4. If the peerLinkID in the mesh peering instance has not been set, the Local Link ID field of the Mesh Peering Confirm request shall be copied into the peerLinkID in the mesh peering instance. If the incoming Mesh Peering Confirm frame is for AMPE and the peerNonce in the mesh peering instance has not been set, the Local Nonce field in the incoming Mesh Peering Confirm frame shall be copied into the peerNonce in the mesh peering instance. 14.3.8 Mesh peering close 14.3.8.1 Generating Mesh Peering Close frames A Mesh Peering Close frame is generated as a result of a sendClose() action (see 14.4.3). The contents of the frame are described in 9.6.16.4.2. When the Mesh Peering Close is generated as a result of a CNCL event, the reason code is MESH- PEERING-CANCELED. When the Mesh Peering Close is generated as a result of a CLS_ACPT event, the reason code is MESH-CLOSE-RCVD. 14.3.8.2 Mesh Peering Close frame processing The mesh STA shall reject the Mesh Peering Close frame if the value in the Mesh ID element is not the same as the mesh STAâ€™s mesh profile. Otherwise, the mesh STA accepts the Mesh Peering Close frame and performs the actions described in 14.4. 14.4 Mesh peering management finite state machine (MPM FSM) 14.4.1 General Each mesh peering instance, including its states and resource, are managed by a mesh peering management finite state machine (MPM FSM). The MPM FSM uses MLME primitives to control the mesh STA to send and receive mesh peering Management frames. 14.4.2 States The MPM FSM uses the following six states: â€” IDLEâ€”IDLE state is a terminal state. In the IDLE state, the MPM FSM is ready to start a new mesh peering instance by either passively listening for an incoming Mesh Peering Open frame or actively initiating a mesh peering instance. 2141 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” OPN_SNTâ€”In the OPN_SNT state, the finite state machine has sent a Mesh Peering Open frame and is waiting for a Mesh Peering Open frame and Mesh Peering Confirm frame from the candidate peer mesh STA. â€” CNF_RCVDâ€”In the CNF_RCVD state, the finite state machine has received a Mesh Peering Confirm frame, but has not received a Mesh Peering Open frame. The mesh STA has not sent the corresponding Mesh Peering Confirm frame yet. â€” OPN_RCVDâ€”In the OPN_RCVD state, the finite state machine has received only the Mesh Peering Open frame but not the Mesh Peering Confirm. The mesh STA has also sent a Mesh Peering Confirm frame upon receiving a Mesh Peering Open frame. â€” ESTABâ€”In the ESTAB state, the finite state machine has received both the Mesh Peering Open and Mesh Peering Confirm frames. The mesh STA has also sent both the Mesh Peering Open frame and Mesh Peering Confirm frame. The mesh peering is established and configured for exchanging frames with the peer mesh STA in the ESTAB state. â€” HOLDINGâ€”In the HOLDING state, the finite state machine is closing the mesh peering instance with the peer mesh STA or the candidate peer mesh STA. 14.4.3 Events and actions The finite state machine uses three types of events: 1) events for state machine transitions; 2) external events generated by frame processing; and 3) events associated with internal timers. The events for state machine transitions are as follows: â€” CNCL(localLinkID, peerMAC, ReasonCode)â€”Used to instruct the mesh peering instance to cancel the mesh peering with the peer mesh STA. localLinkID identifies the MPM FSM for the corresponding mesh peering instance. peerMAC is the MAC address of the peer mesh entity. ReasonCode is used to inform the reason to cancel the mesh peering instance. See 14.3.8.2. â€” ACTOPN(peerMAC, localLinkID)â€”The SME uses this event to create a new mesh peering instance to actively initiate the mesh peering establishment with the candidate peer mesh STA whose MAC address is peerMAC. localLinkID identifies the MPM FSM. The events generated by frame processing are as follows: â€” OPN_ACPTâ€”PeeringOpen_Accept(peerMAC, peerLinkID) event indicates that a Mesh Peering Open frame meeting the correctness criteria of 14.3.6 has been received from peerMAC for the mesh peering instance identified by peerLinkID. â€” OPN_RJCTâ€”PeeringOpen_Reject(peerMAC, peerLinkID, meshConfiguration, reasonCode) event indicates that a Mesh Peering Open frame from peerMAC for the mesh peering instance identified by peerLinkID is rejected due to incomplete or erroneous mesh STA configuration (see 14.2.4), as indicated by meshConfiguration, with reasonCode being the specific reason for rejection of the Mesh Peering Open frame. See 14.3.6.2. â€” CNF_ACPTâ€”PeeringConfirm_Accept(peerMAC, localLinkID, peerLinkID) event indicates that a Mesh Peering Confirm frame meeting the correctness criteria of 14.3.7 has been received from peerMAC for the mesh peering instance identified by localLinkID and peerLinkID. â€” CNF_RJCTâ€”PeeringConfirm_Reject(peerMAC, localLinkID, peerLinkID, reasonCode) event indicates that a Mesh Peering Confirm frame from peerMAC for the mesh peering instance identified by localLinkID and peerLinkID is rejected due to incomplete or erroneous configuration, and reasonCode is the specific reason for rejection of the Confirm frame. See 14.3.7.2. â€” CLS_ACPTâ€”PeeringClose_Accept(peerMAC, localLinkID, peerLinkID, reasonCode) event indicates that a Mesh Peering Close frame meeting the correctness criteria of 14.3.8 has been received from peerMAC for the mesh peering instance identified by localLinkID and peerLinkID. The reasonCode specifies the reason that caused the generation of the Mesh Peering Close frame. See 14.3.8.2. 2142 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” REQ_RJCTâ€”PeeringRequest_Reject(peerMAC, peerLinkID, reasonCode) event indicates a special incidence that the mesh STA rejects the incoming Mesh Peering Open frame requesting to set up a new mesh peering for some specified reason. The incoming request is identified by the peerMAC, peerLinkID is the peerLinkID received from the Mesh Peering Open frame, and reasonCode is the specific reason for rejection of the Mesh Peering Open frame. See 14.3.6.2. The finite state machine may take an action triggered by an event. It uses two types of actions: sending a mesh peering Management frame and handling a timer. Actions related to sending a mesh peering Management frame are as follows: â€” sndOPNâ€”sendOpen(peerMAC, localLinkID, meshConfiguration) is the action that the mesh STA takes to send its localLinkID and mesh STA Configuration in a Mesh Peering Open frame to the candidate peer mesh STA, whose MAC address is peerMAC. The MLME- MESHPEERINGMANAGEMENT.request primitive shall be invoked to send the frame to the peer mesh entity. â€” sndCNFâ€”sendConfirm(peerMAC, localLinkID, peerLinkID, meshConfiguration) is the action that the mesh STA takes to send its localLinkID and meshConfiguration in a Mesh Peering Confirm frame to the candidate peer mesh STA, whose MAC address is peerMAC. peerLinkID is the peerLinkID received from the Mesh Peering Open frame. The MLME- MESHPEERINGMANAGEMENT.request primitive shall be invoked to send the frame to the peer mesh entity. â€” sndCLSâ€”sendClose(peerMAC, localLinkID, peerLinkID, reasonCode) is the action that the mesh STA takes to send its localLinkID in a Mesh Peering Close frame to the peer mesh STA or candidate peer mesh STA, whose MAC address is peerMAC. peerLinkID is the peerLinkID received from the Mesh Peering Open frame, and reasonCode is the specific reason for closing the mesh peering. The MLME-MESHPEERINGMANAGEMENT.request primitive shall be invoked to send the frame to the peer mesh entity. 14.4.4 Timers The following three timers are used by the finite state machine: a) The retryTimer triggers a resend of the Mesh Peering Open frame when a Mesh Peering Confirm frame was not received as a response. The retryTimer is set to the dot11MeshRetryTimeout. b) The confirmTimer signals that a link establishment attempt should be aborted because a Mesh Peering Confirm frame responding to a Mesh Peering Open frame was never received. The confirm- Timer is set to dot11MeshConfirmTimeout. c) The holdingTimer signals that its mesh peering instance may be completely closed and facilitates graceful shutdown. The holdingTimer is set to dot11MeshHoldingTimeout. The events associated with internal timers are represented in the state machine table as acronyms that indicate timer expiration. With each timer event there is an associated action. â€” TOR1â€”This event indicates that the retryTimer has expired and dot11MeshMaxRetries has not been reached. The Mesh Peering Open frame shall be resent, an action represented in the state machine table by setR. â€” TOR2â€”This event indicates that the retryTimer has expired and dot11MeshMaxRetries has been reached. The mesh peering instance shall be closed when TOR2 occurs. â€” TOCâ€”This event indicates that the confirmTimer has expired. When TOC event occurs, the mesh peering instance shall be closed, an action represented in the state machine table as setC. â€” TOHâ€”This event indicates that the holdingTimer has expired. When TOH occurs, the mesh peering instance shall be closed and the finite state machine shall transition to IDLE state, an action represented in the state machine table as setH. 2143 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 14.4.5 State transitions Table 14-2 and Figure 14-2 summarize the state transitions for the MPM protocol. In Table 14-2, each row represents state transitions from the state to all other states. A blank entry indicates an impossible transition. Table 14-2â€”MPM finite state machine To State IDLE OPN_SNT CNF_RCVD OPN_RCVD ESTAB HOLDING IDLE REQ_RJCT ACTOPN / OPN_ACPT / sndCLS (sndOPN, / (sndOPN, setR) sndCNF, setR) OPN_SNT TOR1 / CNF_ACPT OPN_ACPT CLS_ACPT, (sndOPN, / (clR, setC) / (sndCNF) OPN_RJCT, setR) CNF_RJCT, TOR2, CNCL / (sndCLS, clR, setH) CNF_RCV OPN_ACPT CLS_ACPT, D / (clC, OPN_RJCT, sndCNF) CNF_RJCT, CNCL / (sndCLS, clC, setH) TOC / From State (sndCLS, setH) OPN_RCV OPN_ACPT CNF_ACPT CLS_ACPT, D / sndCNF / clR OPN_RJCT, TOR1 / CNF_RJCT, (sndOPN, TOR2, setR) CNCL / (sndCLS, clR, setH) ESTAB OPN_ACPT CLS_ACPT, / sndCNF OPN_RJCT, CNF_RJCT, CNCL / (sndCLS, setH) HOLDING TOH / â€”, OPN_ACPT, CLS_ACPT CNF_ACPT, / clH OPN_RJCT, CNF_RJCT / sndCLS 2144 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications In Figure 14-2, each arrow represents a state transition. REQ_RJCT / sndCLS IDLE TOH / --, , R ) PN CLS_ACPT / clH AC et O TO , s snd PN NF / ( dC T /( OPN_ACPT / sndCNF sn ACP sn dO _ PN TOR1 / (sndOPN, setR) PN TOR1 / (sndOPN, setR) O ,s et R) OPN_RCV OPN_ACPT / sndCNF OPN_SNT D CNF_ACPT / CNF_ACPT / clR (clR, setC) OPN_ACPT / sndCNF OPN_ACPT / (clC, sndCNF) ESTAB CNF_RCVD T, CLS_ACPT, CLS_ACPT, etH JC CL OPN_RJCT, OPN_RJCT, , s _R S_ CNF_RJCT, ) CNF_RJCT, ) clC NF etH AC TOR2, S, T, C TOR2, PT S, s CNCL / CNCL / , O CN , se nd RJC dCL (sndCLS, clR, setH) (sndCLS, clR, ( sn PN CL tH) / (s N _ setH) CL / (sn dC _R / CL OP LS JC TOC CN PT, T, CN AC F_ S_ RJ CL CT , HOLDING OPN_ACPT, CNF_ACPT, OPN_RJCT, CNF_RJCT / sndCLS Figure 14-2â€”Finite state machine of the MPM protocol The event/action representation is defined as the following. â€œE/Aâ€ string represents that the action A is taken given that the event E occurs. â€œE1, E2/Aâ€ string represents that the action A is taken given that the event E1 or event E2 occurs. â€œE/(A1, A2)â€ string represents that the action A1 and A2 are taken at a time when event E occurs. Note that Table 14-2 and Figure 14-2 are used for illustration purposes. The protocol behavior is in the following subclauses. 14.4.6 IDLE state IDLE is a quiescent state the finite state machine enters prior to establishing a new mesh peering. When ACTOPN event occurs, the mesh STA shall set the retryCounter to 0, and perform a sndOPN action. The retryTimer shall be set and the finite state machine shall transition to OPN_SNT state. 2145 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications When an OPN_ACPT event occurs, the mesh STA shall perform a sndOPN action and sndCNF action, and set the retryTimer. The finite state machine shall transition to OPN_RCVD state. When an REQ_RJCT event occurs, a Mesh Peering Close frame shall be sent to reject the mesh peering open request. The reason code in the Mesh Peering Close frame shall be set to the reason code in REQ_RJCT event. The finite state machine shall stay in the IDLE state. All other events are ignored in this state. 14.4.7 OPN_SNT state In the OPN_SNT state, the mesh STA waits for a Mesh Peering Confirm frame. In this state, the retryTimer is set. When a CNCL event occurs, the mesh STA shall clear the retryTimer, perform a sndCLS using the reason code specified by the CNCL event, and set the holdingTimer. The finite state machine shall transition to HOLDING state. When a CLS_ACPT event occurs, the mesh STA shall clear the retryTimer, perform a sndCLS using the reason code specified by the CLS_ACPT event, and set the holdingTimer. The finite state machine shall transition to HOLDING state. When an OPN_ACPT event occurs, the mesh STA shall send perform a sndCNF action. The finite state machine shall transition to OPN_RCVD state. NOTEâ€”The retryTimer is still in effect after the state transition. When an OPN_RJCT event occurs, the mesh STA shall clear the retryTimer, perform a sndCLS using the reason code specified by the OPN_RJCT event, and set the holdingTimer. The finite state machine shall transition to HOLDING state. When a CNF_ACPT event occurs, the mesh STA shall clear the retryTimer and shall set the confirmTimer and the finite state machine shall transition to CNF_RCVD state. When a CNF_RJCT event occurs, the mesh STA shall clear the retryTimer, perform a sndCLS action using the reason code specified by the CNF_RJCT event, and set the holdingTimer. The finite state machine shall transition to HOLDING state. When a TOR1 event occurs, the Mesh STA shall perform a sndOPN action and the retryCounter shall be incremented. The retryTimer shall be and the finite state machine shall stay in the OPN_SNT state. When a TOR2 event occurs, the mesh STA shall perform a sndCLS action using the reason code MESH- MAX-RETRIES. The holdingTimer shall be set, and the finite state machine shall transition to HOLDING state. All other events shall be ignored in this state. 14.4.8 CNF_RCVD state In the CNF_RCVD state, the mesh STA has received a Mesh Peering Confirm frame and is waiting for a Mesh Peering Open frame. 2146 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications When a CNCL event occurs, the mesh STA shall clear the confirmTimer, perform a sndCLS action using the reason code MESH-PEERING-CANCELED, and set the holdingTimer. The finite state machine shall transition to HOLDING state. When a CLS_ACPT event occurs, the mesh STA shall clear the confirmTimer, perform a sndCLS using the reason code MESH-CLOSE-RCVD, and set the holdingTimer. The finite state machine shall transition to HOLDING state. When an OPN_ACPT event occurs, the mesh STA shall clear the confirmTimer and shall perform a sndCNF action. The finite state machine shall transition to ESTAB state. When an OPN_RJCT event occurs, the mesh STA shall clear the confirmTimer, perform a sndCLS action using the reason code as specified by the OPN_RJCT event, and set the holdingTimer. The finite state machine shall transition to HOLDING state. When a CNF_RJCT event occurs, the mesh STA shall clear the confirmTimer, perform a sndCLS action using the reason code as specified by the CNF_RJCT event, and set the holdingTimer The finite state machine shall transition to HOLDING state. When TOC event occurs, the mesh STA shall perform a sndCLS action using the reason code MESH- CONFIRM-TIMEOUT and set the holdingTimer. The finite state machine shall transition to HOLDING state. All other events shall be ignored in this state. 14.4.9 OPN_RCVD state In the OPN_RCVD state, the mesh STA has received a Mesh Peering Open frame and sent a Mesh Peering Open frame and the corresponding Mesh Peering Confirm frame. An incoming Mesh Peering Confirm is expected. When a CNCL event occurs, the mesh STA shall clear the retryTimer, perform a sndCLS action using the reason code MESH-PEERING-CANCELED, and set the holdingTimer. The finite state machine shall transition to HOLDING state. When a CLS_ACPT event occurs, the mesh STA shall clear the retryTimer, perform a sndCLS action, and set the holdingTimer. The finite state machine shall transition to HOLDING state. When an OPN_ACPT event occurs, the mesh STA shall perform a sndCNF action. The finite state machine shall stay in the OPN_RCVD state. When an OPN_RJCT event occurs, the mesh STA shall clear the retryTimer, perform a sndCLS action using the reason code as specified by the OPN_RJCT event, and set the holdingTimer. The finite state machine shall transition to HOLDING state. When a CNF_ACPT event occurs, the retryTimer shall be cleared. The finite state machine shall transition to ESTAB state. When a CNF_RJCT event occurs, the mesh STA shall clear the retryTimer, perform a sndCLS action using the reason code as specified by the CNF_RJCT event, and set the holdingTimer. The finite state machine shall transition to HOLDING state. When a TOR1 event occurs, the Mesh STA shall perform a sndOPN action, increment the retryCounter, and set the retryTimer. The finite state machine shall stay in the OPN_RCVD state. 2147 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications When a TOR2 event occurs, the mesh STA shall perform a sndCLS action using the reason code MESH- MAX-RETRIES. The holdingTimer shall be set, and the finite state machine shall transition to HOLDING state. All other events shall be ignored in this state. 14.4.10 ESTAB state In the ESTAB state, mesh peering has been successfully established with the peer mesh STA. When a CNCL event occurs, the mesh STA shall perform a sndCLS action using the reason code MESH- PEERING-CANCELED, and set the holdingTimer. The finite state machine shall transition to HOLDING state. When a CLS_ACPT event occurs, the mesh STA shall perform a sndCLS action using the reason code MESH-CLOSE-RCVD, and set the holdingTimer. The finite state machine shall transition to HOLDING state. When an OPN_ACPT event occurs, the mesh STA shall respond by performing a sndCNF action. The finite state machine shall stay in the ESTAB state. All other events shall be ignored in this state. 14.4.11 HOLDING state In HOLDING state, the mesh STA is closing the mesh peering. The holdingTimer has been set according to the value of dot11MeshHoldingTimeout. When a CLS_ACPT event occurs, the holdingTimer shall be cleared. The finite state machine shall transition to IDLE state. When any of the following four events occursâ€”OPN ACPT, CNF_ACPT, OPN_RJCT, CNF_RJCTâ€”the mesh STA shall send a Mesh Peering Close frame. The finite state machine shall stay in the HOLDING state. When a TOH event occurs, the finite state machine shall transition to IDLE state. All other events are ignored in this state. 14.5 Authenticated mesh peering exchange (AMPE) 14.5.1 Overview The authenticated mesh peering exchange (AMPE) establishes an authenticated mesh peering between the mesh STAs, under the assumption that mesh PMKSA has already been established before the initiation of the protocol. An authenticated mesh peering includes a mesh peering, corresponding mesh TKSA, and the two mesh STAs mesh GTKSAs. The AMPE is also used to establish an authenticated peering between two APs that support the AP PeerKey protocol (as defined in 12.11) under the assumption that a PMK and PMKID have already been established before the initiation of the AMPE exchange. 2148 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The AMPE uses mesh peering Management frames. Parameters are exchanged via the RSNE, the Authenticated Mesh Peering Exchange element, and the MIC element. The major functions provided by AMPE are security capabilities selection, key confirmation, and key management. â€” The security capabilities selection function (specified in 14.5.2) is performed by agreeing on the security parameters used for the protocol instance. â€” Key confirmation using the shared PMK is performed by verifying that the protection on the mesh peering Management frame is correct. â€” Key management (specified in 14.5.7) is performed by the derivation of the temporal key in the mesh TKSA and the exchange of each mesh STAâ€™s MGTK. During the AMPE handshake, the mesh STAs generate nonces and transmit them via mesh peering Management frames. The mesh STA shall generate a random value for its localNonce, as specified in 12.7.5. The candidate peer mesh STA is expected to generate a random value for the peerNonce, which the mesh STA receives from the candidate peer mesh STA in Confirm and Close Action frames. Mesh peering Management frames used in the AMPE are protected using the deterministic authenticated encryption mode of AES-SIV (IETF RFC 5297). 14.5.2 Security capabilities selection 14.5.2.1 Instance Pairwise Cipher Suite selection Pairwise cipher suite selectors WEP-40, WEP-104, and TKIP shall not be used as the pairwise cipher suite when dot11MeshSecurityActivated, dot11ProtectedTXOPNegotiationActivated, or dot11ProtectedQLoadReportActivated is true. If the pairwise cipher suite has not been selected, a STA shall attempt to reach the agreement on the pairwise cipher suite using the following procedure in four steps: a) The STA shall announce the list of pairwise cipher suites it supports using an ordered list in the RSNE in the Mesh Peering Open frame. The first value in the list is the STAâ€™s most preferred cipher suite, and the last value the least preferred. b) If the STA receives a Mesh Peering Open frame from the candidate peer STA, the STA shall make its decision on the selected pairwise cipher suite based on the intersection of its own ordered list and the received ordered list. 1) If the intersection is empty, the pairwise cipher suite selection fails and the STA generates the failure reason code MESH-INVALID-SECURITY-CAPABILITY and then takes the corresponding actions specified in 14.5.6. 2) If the intersection contains more than one value, the selected cipher suite shall be the entry in the intersection list most preferred by the STA that has the largest MAC address in the lexicographic ordering. c) If the STA receives a Mesh Peering Confirm frame from the candidate peer STA before receiving a Mesh Peering Open frame, the STA shall verify that it supports the pairwise cipher suite chosen by the candidate peer STA. Otherwise, the selection fails and the STA shall generate the failure reason code MESH-INVALID-SECURITY-CAPABILITY. Furthermore, upon receiving a Mesh Peering Open frame, the STA shall verify that the accepted selected pairwise cipher suite matches the pairwise cipher suite chosen in step b). If they do not match, the selection fails and the STA shall generate the failure reason code MESH-INVALID- SECURITY-CAPABILITY. Otherwise, the pairwise cipher suite selection succeeds, and the STA shall proceed to step d). 2149 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications d) If the STA is generating a Mesh Peering Confirm frame, it shall set the Selected Pairwise Cipher Suite to the selected pairwise cipher suite upon successful pairwise cipher suite selection. 14.5.2.2 Group cipher suite selection Group cipher suite selectors WEP-40, WEP-104, and TKIP shall not be used as the group cipher suite when dot11MeshSecurityActivated is true. The mesh STA shall not use a different group cipher suite than the one used by the peer mesh STA or candidate peer mesh STA in the same MBSS. A mesh STA shall announce in a Mesh Peering Open frame the group cipher suite it uses for broadcast protection. When it receives a Mesh Peering Open frame from a candidate peer, it shall verify that it supports the candidateâ€™s announced group cipher suite. In addition, if the mesh STA receives a Mesh Peering Confirm frame, it shall verify that it supports the group cipher suite listed in that frame. If either selection fails, the mesh STA shall issue the appropriate reply frame with the MESH-INVALID-SECURITY-CAPABILITY reason code. 14.5.3 Construction and processing AES-SIV-protected mesh peering Management frames AES-SIV performs deterministic authenticated encryption and takes additional data that is authenticated but not encrypted (AAD). When encrypting and authenticating, AES-SIV takes a key, plaintext data to protect, and multiple distinct components of AAD, to produce a synthetic initialization vector and a cipher text. When verifying encrypted and authenticated data AES-SIV takes a key, a synthetic initialization vector, cipher text data to decrypt and verify, and AAD, to produce either plaintext or the symbol â€œFAIL,â€ indicating failure to decrypt and verify. Note that the AAD used in the encryption process shall be identical to the AAD used in the decryption process and the synthetic initialization vector produced by the encryption process shall be used in the decryption process. When the mesh STA constructs a mesh peering Management frame, it shall follow the following procedure: â€” The input key shall be the AEK â€” The input plaintext shall be the Authenticated Mesh Peering element (see 9.6.16.2, 9.6.16.3, 9.6.16.4) â€” The input AAD shall be three distinct components consisting of 1) The localMAC 2) The peerMAC 3) The contents of the mesh peering Management frame from the category (inclusive) to the MIC element (exclusive) â€” The output synthetic initialization vector shall be copied into the MIC field of the MIC element in the mesh peering Management frame â€” The output cipher text shall become the remainder of the mesh peering Management frame after the MIC element When the mesh STA verifies a mesh peering Management frame, it shall follow the following procedure: â€” The input key shall be the AEK â€” The input synthetic initialization vector shall be the MIC field of the MIC element in the mesh peering Management frame â€” The input cipher text shall be the part of the mesh peering Management frame following the MIC element â€” The input AAD shall be three distinct components consisting of 2150 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 1) The peerMAC 2) The localMAC 3) The contents of the mesh peering Management frame from the category (inclusive) to the MIC element (exclusive) â€” If AES-SIV returns the symbol â€œFAILâ€ processing of the frame shall be deemed a failure with a behavior dependent on the type of mesh peering Management frame â€” If AES-SIV returns plaintext it shall be treated as the components of the mesh peering Management frame and processed accordingly 14.5.4 Distribution of group transient keys in an MBSS The MGTK shall be a random or pseudorandom number. The mesh STA shall distribute the MGTK to the peer mesh STA using the Mesh Peering Open frame during the AMPE. Upon successful completion of AMPE, each mesh STA shall establish states for the peer mesh STAâ€™s mesh GTKSA. The GTKData subfield in the Authenticated Mesh Peering Exchange element shall contain the MGTK concatenated by the Key RSC and the GTKExpirationTime (as specified in 9.4.2.118). When dot11RSNAProtectedManagementFramesActivated is true, a mesh STA shall distribute the IGTK to the peer mesh STA using the Mesh Peering Open frame during the AMPE. Upon successful completion of AMPE, each mesh STA shall establish an IGTKSA (see 12.6.1.1.9) with the mesh peer. 14.5.5 Mesh peering Management frames for AMPE 14.5.5.1 General The AMPE is inclusive of the mesh peering management (MPM) protocol. mesh peering Management frames for AMPE have additional processing and construction requirements on top of those for mesh peering Management frames. The mesh peering Management frames shall be generated with additional information using the RSNE and the Authenticated Mesh Peering Exchange element to support AMPE. 14.5.5.2 Mesh peering open for AMPE 14.5.5.2.1 Generating Mesh Peering Open frames for AMPE In addition to contents for establishing a mesh peering as specified in 14.3.6.1, the Mesh Peering Open frame, when used for the AMPE, shall contain the following: â€” In the Mesh Peering Management element, the Mesh Peering Protocol Identifier shall be set to 1 â€œauthenticated mesh peering exchange protocol.â€ â€” In the Mesh Peering Management element, the Chosen PMK field shall be set to PMKID that identifies the mesh PMKSA the mesh STA established with the candidate peer mesh STA. â€” The RSNE shall be identical to the RSNE in the STAâ€™s Beacon and Probe Response frames. â€” In the Authenticated Mesh Peering Exchange element: â€” The Selected Pairwise Cipher Suite field shall be set to the first cipher suite selector in the Pairwise Cipher Suite List field in RSNE. â€” The Local Nonce field shall be set to the localNonce value generated by the mesh STA for identifying the current mesh peering instance. â€” The Peer Nonce field shall be set to 0. â€” If dot11MeshSecurityActivated is true, the GTKdata field shall be present and shall contain the data for the mesh STAâ€™s MGTK. The GTKdata field shall not be present when AMPE is being 2151 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications used as part of the AP PeerKey protocol (12.11.2). The components of the GTKdata field are specified in 14.5.4. The Mesh Peering Open frame shall be protected using AES-SIV as specified in 14.5.3. 14.5.5.2.2 Processing Mesh Peering Open frames for AMPE On receiving a Mesh Peering Open frame, the mesh STA shall verify the received frame. If AES-SIV returns the symbol â€œFAILâ€ the OPN_RJCT event shall be invoked to the corresponding AMPE finite state machine and the reason code â€œMESH-INVALID-GTKâ€ is generated. Otherwise, processing continues. The received frame shall be rejected if the security capability selection fails (see 14.5.2). The OPN_RJCT event shall be invoked to the corresponding AMPE finite state machine. The peer mesh STAâ€™s MGTK extracted from the Mesh Peering Open frame shall be added to the Receive MGTK SA in which the peerâ€™s MAC address equals the MGTK Source mesh STA MAC address. If all operations succeed, the mesh STA shall proceed to process the Mesh Peering Open frame on basic parameters as specified in 14.3.6.2. 14.5.5.3 Mesh peering confirm for AMPE 14.5.5.3.1 Generating Mesh Peering Confirm frames for AMPE In addition to contents for establishing a mesh peering as specified in 14.3.7.1, the Mesh Peering Confirm frame, when used with the AMPE, shall contain the following: â€” In the Mesh Peering Management element, the Mesh Peering Protocol Identifier shall be set to 1 â€œauthenticated mesh peering exchange protocol.â€ â€” The RSNE shall be the same as sent in the Mesh Peering Open frame. â€” In the Authenticated Mesh Peering Exchange element: â€” The Selected Pairwise Cipher Suite field shall be set to the cipher suite selector that indicates the successfully selected pairwise cipher suite (specified in 14.5.2.1). â€” The Peer Nonce field shall be set to the nonce value chosen by the peer mesh STA as received in the Local Nonce field in the Mesh Peering Open frame from the candidate peer mesh STA. â€” The GTKdata field shall not be present. â€” The IGTKdata field shall not be present. â€” The rest of fields are set to the same values sent in the Mesh Peering Open frame. The Mesh Peering Confirm frame shall be protected using AES-SIV as specified in 14.5.3. 14.5.5.3.2 Processing Mesh Peering Confirm frames for AMPE On receiving a Mesh Peering Confirm frame, the mesh STA shall verify the received frame. The received frame shall be discarded if AES-SIV returns the symbol â€œFAIL.â€ If AES-SIV returns plaintext, the following operations shall be performed in order: a) The Selected Pairwise Cipher Suite is checked. If the security capability selection has been done and the received value from Chosen Pairwise Cipher Suite field is not the same as the agreed pairwise cipher suite, the STA shall reject the received frame and the CNF_RJCT event is invoked to the cor- responding AMPE finite state machine with the failure reason code MESH-INVALID-SECURITY- CAPABILITY. 2152 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications b) If dot11MeshSecurityActivated is true the group cipher suite is checked. If the received group cipher suite is not supported by the mesh STA, the mesh STA shall reject the received Mesh Peering Con- firm frame and the CNF_RJCT event is invoked to the corresponding AMPE finite state machine with the failure reason code MESH-INVALID-SECURITY-CAPABILITY. If none of the cases is true, the mesh STA shall proceed to process the Mesh Peering Confirm Action frame on basic parameters as specified in 14.3.7.2. 14.5.5.4 Mesh peering close for AMPE 14.5.5.4.1 Generating Mesh Peering Close frames for AMPE In addition to contents for closing a mesh peering as specified in 14.3.8.1, the Mesh Peering Close frame, when used for the AMPE, shall contain the following: â€” In the Mesh Peering Management element, the Mesh Peering Protocol Identifier shall be set to 1 â€œauthenticated mesh peering exchange protocol.â€ â€” In the Mesh Peering Management element, the Chosen PMK field shall be set to the same value as sent in the Mesh Peering Open frame. â€” In the Authenticated Mesh Peering Exchange element: â€” The Selected Pairwise Cipher Suite field shall be set to the same value as sent in the Mesh Peering Open frame. NOTEâ€”If the reason for sending the Mesh Peering Close is the pairwise cipher suite selection failure, the information in this field is used to inform the candidate peer mesh STA what was announced by the mesh STA for the mesh peering instance. â€” The Local Nonce field shall be set to the same value as sent in the Mesh Peering Open frame. â€” The Peer Nonce field shall be set to the same value as received in the Local Nonce field of the Authenticated Mesh Peering Exchange element of the incoming mesh peering Management frame from the candidate peer mesh STA. The Mesh Peering Close frame shall be protected using AES-SIV as specified in 14.5.3. 14.5.5.4.2 Processing Mesh Peering Close frames for AMPE On receiving a Mesh Peering Close frame, the mesh STA shall verify the received frame. The received frame shall be discarded if AES-SIV returns the symbol â€œFAIL.â€ If AES-SIV returns plaintext, the mesh STA shall proceed to process the Mesh Peering Close frame on basic parameters as specified in 14.3.8.2. 14.5.6 AMPE finite state machine 14.5.6.1 Overview The finite state machine for AMPE supports all of the states, events, and actions defined for the finite state machine for the MPM protocol. In addition, new events, actions, and state transitions are added to specify the security functions for AMPE. When a finite state machine is generated and activated for an AMPE instance, the localNonce shall be generated and used together with a new localLinkID to identify the instance. 2153 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 14.5.6.2 Additional events and actions to MPM FSM All events for rejecting or ignoring received Action frames shall report the corresponding reason code related to AMPE functions as described in 14.5.5. In addition, there is one new event as follows: â€” TOR3â€”This event indicates that the retryTimer has expired, the dot11MeshMaxRetries has been reached, the AMPE is enabled, but the mesh STA failed to confirm the selection of the shared mesh PMKSA. When this event triggers, the protocol instance shall be closed, but no Mesh Peering Close frame shall be sent. The actions of sending mesh peering Management frames are updated as the following: â€” sndOPNâ€”Generate a Mesh Peering Open frame for the current AMPE protocol instance (as specified in 14.5.5.2.1) and send it to the candidate peer mesh STA. â€” sndCNFâ€”Generate a Mesh Peering Confirm frame for the current AMPE protocol instance (as specified in 14.5.5.3.1) and send it to the candidate peer mesh STA. â€” sndCloseâ€”Generate a Mesh Peering Close frame for the current AMPE protocol instance (as specified in 14.5.5.4.1) and send it to the candidate peer mesh STA. 14.5.6.3 State transitions All state transitions specified in MPM FSM shall be used for AMPE finite state machine. In OPN_SNT state, the following are additional state transitions and actions: When TOR3 event occurs, the retryTimer shall be cleared and the holdingTimer shall be set. The finite state machine shall transition to HOLDING state. In OPN_RCVD state, the following are the additional actions: When CNF_ACPT event occurs, in addition to the actions for MPM protocol, the mesh STA shall signal the completion of key management by utilizing the MLME-SETKEYS.request primitive to configure the agreed-upon mesh temporal pairwise key into the IEEE 802.11 MAC and by calling the MLME-SETPROTECTION.request primitive to enable its use. In CNF_RCVD state, the following are the additional actions: When OPN_ACPT event occurs, in addition to the actions for MPM protocol, the mesh STA shall signal the completion of key management by utilizing the MLME-SETKEYS.request primitive to configure the agreed-upon mesh temporal pairwise key into the IEEE 802.11 MAC and received MGTK and by calling the MLME-SETPROTECTION.request primitive to enable the usage. Table 14-3 and Figure 14-3 specify the state transitions of the finite state machine for AMPE. 2154 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 14-3â€”AMPE finite state machine To State IDLE OPN_SNT CNF_RCVD OPN_RCVD ESTAB HOLDING IDLE REQ_RJCT / ACTOPN / OPN_ACPT / sndCLS (sndOPN, (sndOPN, setR) sndCNF, setR) OPN_SNT TOR1 / CNF_ACPT / OPN_ACPT / CLS_ACPT, (sndOPN, (clR, setC) (sndCNF) OPN_RJCT, setR) CNF_RJCT, TOR2, CNCL / (sndCLS, clR, setH) TOR3 / (clR, setH) CNF_RCVD OPN_ACPT / CLS_ACPT, (clC, sndCNF) OPN_RJCT, CNF_RJCT, CNCL / (sndCLS, clC, setH) From State TOC / (sndCLS, setH) OPN_RCV TOR1 / CNF_ACPT / CLS_ACPT, D (sndOPN, clR OPN_RJCT, setR) CNF_RJCT,T OPN_ACPT / OR2, CNCL / sndCNF (sndCLS, clR, setH) ESTAB OPN_ACPT / CLS_ACPT, sndCNF OPN_RJCT, CNF_RJCT, CNCL / (sndCLS, setH) HOLDING TOH / â€”, OPN_ACPT, CLS_ACPT / CNF_ACPT, clH- OPN_RJCT, CNF_RJCT / sndCLS 2155 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications REQ_RJCT / sndCLS IDLE TOH / --, , R) PN CLS_ACPT / clH AC et O TO , s snd PN NF / ( /( dC T OPN_ACPT / sndCNF sn ACP sn dO N_ PN TOR1 / (sndOPN, setR) TOR1 / (sndOPN, setR) OP , se tR ) OPN_RCV OPN_ACPT / sndCNF OPN_SNT D CNF_ACPT / CNF_ACPT / clR (clR, setC) OPN_ACPT / sndCNF OPN_ACPT / (clC, sndCNF) ESTAB CNF_RCVD CLS_ACPT, OPN_RJCT, CNF_RJCT, T, CLS_ACPT, etH C TOR2, CL OPN_RJCT, , s _RJ S_ CNF_RJCT, CNCL / ) ) etH clC CNF AC TOR2, (sndCLS, clR, P S, s CNCL / setH) T, CL JCT, OP CNC , setH dCL (sndCLS, clR, setH) S, ( sn / (s N_R TOR3 / N_ L / / (sn dC (clR, setH) RJ nd CL OP LS CT TOC CN Pt, ,C AC NF ) S_ _R CL JC T, HOLDING OPN_ACPT, CNF_ACPT, OPN_RJCT, CNF_RJCT / sndCLS Figure 14-3â€”Finite state machine of the AMPE protocol 14.5.7 Keys and key derivation algorithm for the authenticated mesh peering exchange (AMPE) To execute the AMPE and mesh group key handshake with a candidate peer STA, the local STA shall derive an authenticated encryption key (AEK) and a mesh temporal key (MTK) using the PMK it shares with the candidate peer STA. The AEK is derived statically from the shared PMK. The MTK is derived from the shared PMK and dynamic information provided by the STA and candidate peer STA. The AEK is mutually derived by the local STA and the peer STA once a new PMK has been selected. The AEK shall be derived from the PMK by 2156 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications AEK KDF-Hash-256(PMK, â€œAEK Derivationâ€, Selected AKM Suite || min(localMAC, peerMAC) || max(localMAC, peerMAC)) where KDF-Hash-256 is the key derivation function defined in 12.7.1.7.2 using the hash algorithm identified by the AKM suite selector (see Table 9-133) Selected AKM Suite is a four octet string formed by concatenating the OUI or CID and suite type The temporal key (MTK) shall be derived from the PMK by MTK KDF-Hash-Length(PMK, â€œTemporal Key Derivationâ€, min(localNonce, peerNonce) || max(localNonce, peerNonce) || min(localLinkID, peerLinkID) || max(localLinkID, peerLinkID) || Selected AKM Suite || min(localMAC, peerMAC) || max(localMAC, peerMAC)) where KDF-Hash-Length is the key derivation function defined in 12.7.1.7.2 using the hash algorithm identified by the AKM suite selector (see Table 9-133) Length is cipher-suite dependent and is defined by the TK_bits value in Table 12-4. Selected AKM Suite is a four octet string formed by concatenating the OUI or CID and suite type â€œminâ€ and â€œmaxâ€ operations for IEEE 802 addresses are with the address converted to a positive integer, treating the first transmitted octet as the most significant octet of the integer as speci- fied in 12.7.1.3 â€œminâ€ and â€œmaxâ€ operations for nonces are encoded as specified in 9.2.2 â€œminâ€ and â€œmaxâ€ operations for LinkIDs select the minimum and maximum, respectively, of the two unsigned integers. In the KDF context, LinkIDs are encoded as 16-bit unsigned inte- gers, represented using the bit ordering conventions of 9.2.2. The MTK is used to protect communications between two peer STAs. The local STA and peer STA derive an MTK per peering instance and may rekey the MTK using AMPE. 14.6 Mesh group key handshake 14.6.1 General The mesh group key handshake may be used by either mesh STA, after a secure mesh peering has been established, to update the MGTK that it uses to protect group addressed MPDUs that it transmits to its peer mesh STAs. The mesh STA may update its MGTK when a mesh peering is terminated. To update the MGTK, the mesh STA shall execute the mesh group key handshake with each of its current peer mesh STAs. The â€œMGTK sourceâ€ is the mesh STA that is sending the MGTK to a peer mesh STA using this protocol. A â€œMGTK recipientâ€ is a mesh STA receiving the MGTK being sent by the MGTK Source. The mesh group key handshake shall include the following two messages: â€” Message 1: Mesh Group Key Inform frame â€” Message 2: Mesh Group Key Acknowledge frame Mesh Group Key Inform frame and Mesh Group Key Acknowledge frame are conventionally referred to as mesh group key handshake frames. 2157 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The mesh STA shall do an AMPE handshake before a mesh group key handshake if both are required to be done. NOTEâ€”It is impossible that the MGTK source initiates the mesh group key handshake before the AMPE completes successfully. 14.6.2 Protection on mesh group key handshake frames Mesh group key handshake frames used in mesh group key handshake are protected using the deterministic authenticated encryption mode of AES-SIV (IETF-RFC 5297) when dot11MeshSecurityActivated is true. When constructing protection on mesh group handshake frames, the following procedure shall be used: â€” The key shall be the AEK from the current active security association with the peer mesh STA that receives the mesh group key handshake frame. â€” The input plaintext shall be the AMPE Authenticated Mesh Peering element (see 9.6.16.5 and 9.6.16.6). â€” The plaintext shall be the Authenticated Mesh Peering Exchange element. â€” AAD shall be three distinct components as follows: 1) The localMAC 2) The peerMAC 3) The contents of the mesh group key handshake frame from the category (inclusive) to the MIC element (exclusive) â€” The synthetic initialization vector produced by AES-SIV shall be copied into the MIC field of the MIC element in the frame. â€” The produced cipher text shall become the remainder of the mesh group key handshake frame after the MIC element. When verifying the protection on the mesh group handshake frames, the following procedure shall be used: â€” The key shall be the AEK from the current active security association with the peer mesh STA that receives the mesh group key handshake frame. â€” AAD shall be three distinct components as follows: 1) The peerMAC 2) The localMAC 3) The contents of the mesh group key handshake frame from the category (inclusive) to the MIC element (exclusive) â€” The synthetic initialization vector shall be the MIC field of the MIC element in the frame. â€” The cipher text shall be the content after the MIC element in the frame. â€” If AES-SIV validation function takes above input. â€” If the function returns the special symbol â€œFAIL,â€ the frame shall be discarded. â€” If the plaintext is returned successfully, the produced plaintext shall be treated as the contents after the MIC element in the frame. 14.6.3 Mesh Group Key Inform frame construction and processing Mesh Group Key Inform frame shall be constructed as follows: â€” The Authenticated Mesh Peering Exchange element shall be set as the following: â€” The Selected Pairwise Cipher Suite field shall be set to four octets of zero. â€” The Local Nonce field shall be set to the same value as sent in the Mesh Peering Open frame that established the mesh peering instance. 2158 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” The Peer Nonce field shall be set to the same value as received in the Local Nonce field of the Authenticated Mesh Peering Exchange element of the incoming Mesh Peering Open frame that established the peering instance. â€” The Key Replay Counter field shall be set to the mesh STAâ€™s local replay counter value, incremented by 1, for the mesh peering. After setting this field, the local replay counter shall also be incremented by 1. â€” The GTKdata field shall be present and shall contain the data for the MGTK from MGTK source. The components of the GTKdata are specified in 14.5.4. â€” If management frame protection is used, the IGTKdata field shall be present and shall contain the data for the IGTK from IGTK source. The components of the IGTKdata are specified in 9.4.2.118. â€” The MIC element shall be set according to the protection mechanism in 14.6.2. The construction of AES-SIV protection on Mesh Group Key Inform frame shall use the construction procedure as in 14.6.2. The MGTK source sends the Mesh Group Key Inform frame to the MGTK recipient. On reception of Mesh Group Key Inform frame, the MGTK recipient shall use the verification procedure in 14.6.2 to validate the AES-SIV construction. â€” If the validation recovers the plaintext successfully, the MGTK recipient shall proceed with the following procedure: â€” Verify that values in the Local Nonce field and the Peer Nonce field in the Authenticated Mesh Peering Exchange element are the same as in the current valid mesh TKSA that the MGTK recipient established with the sender of the Mesh Group Key Inform frame. If there is any mismatch, the received Mesh Group Key Inform frame shall be discarded and no further action shall be taken. â€” Verify that the Key Replay Counter has not yet been seen before, i.e., its value is strictly larger than that in any other mesh Group Key Inform frame received thus far during this security association. If this verification fails, the received Mesh Group Key Inform frame shall be discarded and no further action shall be taken. â€” Use the MLME-SETKEYS.request primitive to configure the temporal MGTK into its IEEE 802.11 MAC. â€” Respond by constructing and sending mesh group key handshake acknowledge to the MGTK source and incrementing the replay counter. NOTEâ€”The MGTK source increments and uses a new Key Replay Counter field value on every Mesh Group Key Inform frame, even retries, because the Mesh Group Key Acknowledge frame responding to an earlier Mesh Group Key Inform frame might have been lost. If the MGTK source did not increment the replay counter, the MGTK receiver discards the retry, and no responding Mesh Group Key Acknowledge frame will ever arrive. â€” If the AES-SIV validation returns a special symbol â€œFAIL,â€ the Mesh Group Key Inform frame shall be discarded. No further action shall be taken. 14.6.4 Mesh Group Key Acknowledge frame construction and processing Mesh Group Key Acknowledge frame shall be constructed as follows: â€” The Authenticated Mesh Peering Exchange element shall be set as follows: â€” The Selected Pairwise Cipher Suite field shall be set to four octets of zero. â€” The Local Nonce field shall be set to the same value as sent in the Mesh Peering Open frame that established the mesh peering instance. 2159 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” The Peer Nonce field shall be set to the same value as received in the Local Nonce field of the Authenticated Mesh Peering Exchange element of the incoming Mesh Peering Open frame that established the peering instance. â€” The Key Replay Counter shall be set to the same value as received in the Mesh Group Key Inform frame. â€” The GTKdata field shall not be present. â€” The IGTKdata field shall not be present. â€” The MIC element shall be set according to the protection mechanism in 14.6.2. The construction of AES-SIV protection on Mesh Group Key Acknowledge frame shall use the construction procedure as in 14.6.2. The MGTK recipient sends the Mesh Group Key Acknowledge frame to the MGTK source. On reception of Mesh Group Key Acknowledge frame, the MGTK source shall use the verification procedure in 14.6.2 to validate the AES-SIV construction. â€” If the validation recovers the plaintext successfully, the MGTK source shall set the content of the Authenticated Mesh Peering Exchange element using the recovered plaintext and proceed with the following procedure: â€” Verify that values in the Local Nonce field and the Peer Nonce field in the Authenticated Mesh Peering Exchange element are the same as in the current valid mesh TKSA that the MGTK source established with the sender of the Mesh Group Key Acknowledge frame. If there is any mismatch, the received Mesh Group Key Acknowledge frame shall be discarded and no further action shall be taken. â€” Verify that the Key Replay Counter value matches the one that it has used for the mesh group key handshake. If this verification fails, the received Mesh Group Key Acknowledge frame shall be discarded and the MGTK source may invoke a retry to send a new Mesh Group Key Inform frame with a new Key Replay Counter value. â€” If the validation returns a special symbol â€œFAIL,â€ the Mesh Group Key Acknowledge frame shall be discarded and the MGTK source may invoke a retry to send a new Mesh Group Key Inform frame with a new Key Replay Counter value. 14.6.5 Mesh group key implementation considerations If the MGTK source does not receive a Mesh Group Key Acknowledge frame to its Mesh Group Key Inform frames, it shall attempt dot11MeshConfigGroupUpdateCount additional transmissions of the Mesh Group Key Inform frame. The retransmit timeout value shall be 100 ms for the first timeout, half the listen interval for the second timeout, and the listen interval for subsequent timeouts. If there is no listen interval or the listen interval is zero, then 100 ms shall be used for all timeout values. If it still has not received a response after this, then the MGTK source shall tear down the mesh peering and mesh TKSA with this MGTK recipient, by generating a CNCL event for the peering instance, and pass the event to the mesh peering instance controller. 14.7 Mesh security During the AMPE, the peers negotiate, and agree upon, a pairwise ciphersuite and a group cipher suite. They also establish a mesh TKSA and mesh GTKSA to be used with the pairwise cipher suite and group cipher suite, respectively. When dot11MeshSecurityActivated is true, all individually addressed mesh Data frames and individually addressed robust Management frames (see 12.2.8) shall be protected by the mesh TKSA, and all group 2160 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications addressed Data frames and group addressed Action frames that are indicated as â€œGroup Addressed Privacyâ€ in Table 9-47 shall be protected by the mesh GTKSA. When dot11RSNAProtectedManagementFramesActivated is true, group addressed robust Management frames that are not protected by the mesh GTKSA shall be protected using BIP (see 11.13). 14.8 Mesh path selection and metric framework 14.8.1 General The term mesh path selection is used to describe selection of multi-hop paths between mesh STAs at the link layer. Mesh path selection creates forwarding information that is utilized for MSDU/MMPDU forwarding as described in 10.35. 14.8.2 Extensible path selection framework This standard allows for alternative and flexible implementations of path selection protocols and metrics. A mesh STA may include multiple protocol implementations (that is, the default protocol, vendor-specific protocols, etc.) as well as multiple metric implementations, but only one path selection protocol and only one path selection metric shall be used by a mesh STA at a time. As described in 14.2.3 and 14.2.7, mesh STAs use the Mesh Configuration element (9.4.2.98) to announce the active path selection protocol and active path selection metric of the MBSS. This allows a neighbor mesh STA to identify if it should become a member of the MBSS and how it should establish mesh peerings with its members. This standard does not force an existing MBSS that is using a protocol other than the default protocol to switch to the default protocol when a new mesh STA requests mesh peering establishment. While it is possible, in principle, to implement such behavior, an algorithm to coordinate such reconfiguration is beyond the scope of this standard. Path selection protocol and path selection metric are identified by a unique identifier as defined in 9.4.2.98.2 and 9.4.2.98.3, respectively. Also, each path selection protocol and each path selection metric specifies the following: â€” Data type of metric values â€” Length of the metric field â€” Operator for aggregation of link metrics to a path metric; the symbol is used to identify an arbitrary operator for aggregation â€” Comparison operator for determining a better or worse path; how this is performed depends on the actual comparison operator â€” Initial value of the path metric (path selection metric only) The standard defines a default path selection protocol (HWMP, 14.10) and a default path selection metric (airtime link metric, 14.9). Both shall be implemented on all mesh STAs. 14.8.3 Link metric reporting A mesh STA may submit a link metric report to or request a link metric report from its neighbor peer mesh STA by transmitting a Mesh Link Metric Report frame. A mesh STA receiving a Mesh Link Metric Report element with the Request subfield of the Flags field equal to 1 shall reply with a Mesh Link Metric Report frame containing the link metric value for the corresponding link. 2161 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Upon reception of a Mesh Link Metric Report frame, the mesh STA may update its local link metric information using the link metric information received. The procedure to update the local link metric information with the link metric information received from a neighbor peer mesh STA is outside the scope of the standard. 14.9 Airtime link metric This subclause defines a default link metric that may be used by a path selection protocol to identify an efficient radio-aware path. The extensibility framework allows this metric to be overridden by any path selection metric as specified in the mesh profile. Airtime reflects the amount of channel resources consumed by transmitting the frame over a particular link. This measure is approximate and designed for ease of implementation and interoperability. The airtime for each link is calculated as follows: B 1 c a = O + -----t ------------- r 1 â€“ ef where O and Bt are constants listed in Table 14-4 input parameter r is the data rate (in Mb/s) input parameter ef is the frame error rate for the test frame size Bt rate r represents the data rate at which the mesh STA would transmit a frame of standard size Bt based on current conditions, and its estimation is dependent on local implementation of rate adaptation frame error rate ef is the probability that when a frame of standard size Bt is transmitted at the current transmission bit rate r, the frame is corrupted due to transmission error; its estimation is a local implementation choice. Frame failures due to exceeding Mesh TTL should not be included in this estimate as they are not correlated with link performance. The airtime link metric shall be encoded as an unsigned integer in units of 0.01 TU. Table 14-4â€”Airtime cost constants Parameter Recommended value Description O Varies depending on Channel access overhead, which includes frame headers, training PHY sequences, access protocol frames, etc. Bt 8192 Number of bits in test frame Table 14-5 gives the parameters of the airtime link metric for the extensible path selection framework. An example of the airtime link metric is shown in S.5. 2162 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 14-5â€”Parameters of the airtime link metric for extensible path selection framework Parameter Notes Path Selection Metric ID See Table 9-218 in 9.4.2.98.3 Data type Unsigned integer, 0 metric value < 4 294 967 296 Length of metric field 4 octets Operator for metric aggregation addition (+) Comparison operator less than, equal to, greater than as used with integers â€” metric a is better than metric b iff a < b â€” metric a is equal to metric b iff a = b â€” metric a is worse than metric b iff a > b Initial value of path metric 0 14.10 Hybrid wireless mesh protocol (HWMP) 14.10.1 General The hybrid wireless mesh protocol (HWMP) is a mesh path selection protocol that combines the flexibility of on-demand path selection with proactive topology tree extensions. The combination of reactive and proactive elements of HWMP enables efficient path selection in a wide variety of mesh networks (with or without access to the infrastructure). HWMP uses a common set of protocol elements, generation and processing rules inspired by Ad Hoc On- Demand Distance Vector (AODV) protocol (IETF RFC 3561 [B38]) adapted for MAC address-based path selection and link metric awareness. HWMP is completely specified herein and does not require reference to AODV specifications or descriptions. HWMP supports two modes of operation depending on the configuration. These modes provide different levels of functionality as follows: â€” On-demand mode: The functionality of this mode is always available, independent of whether a root mesh STA is configured in the MBSS or not. It allows mesh STAs to communicate using peer-to- peer paths. â€” Proactive tree building mode: In this mode, additional proactive tree building functionality is added to the on-demand mode. This can be performed by configuring a mesh STA as root mesh STA using either the proactive PREQ mechanism or proactive RANN mechanism. The proactive PREQ mechanism creates paths from the mesh STAs to the root, using only group addressed communication. The RANN mechanism creates paths between the root and each mesh STA using acknowledged communication. These modes are not exclusive. On-demand and proactive modes are used concurrently, because the proactive modes are extensions of the on-demand mode. NOTEâ€”One example of concurrent usage of on-demand and proactive mode is for two mesh STAs that are part of the same mesh BSS (or STAs that are proxied by mesh STAs in the same MBSS) to begin communicating using the proactively built tree but subsequently to perform an on-demand discovery for a direct path. This type of concurrent usage of the proactive and on-demand modes allows communication to begin immediately (by forwarding all traffic to the root, which knows all mesh STAs and addresses proxied by mesh STAs in the MBSS) while an on-demand discovery finds a shorter path between two mesh STAs (or STAs that are proxied by mesh STAs in the same MBSS). 2163 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications All HWMP modes of operation utilize common processing rules and primitives. HWMP elements are the PREQ (path request) element, PREP (path reply) element, PERR (path error) element, and RANN (root announcement) element. The metric cost of the links determines which paths HWMP builds. In order to propagate the metric information between mesh STAs, a Metric field is used in the PREQ, PREP, and RANN elements. Path selection in HWMP uses a sequence number mechanism to enable mesh STAs to distinguish current path information from stale path information at all times in order to maintain loop-free connectivity. Each mesh STA maintains its own HWMP SN, which is propagated to other mesh STAs in the HWMP elements. Rules for maintaining HWMP SNs are given in 14.10.8.3. 14.10.2 Terminology This subclause describes terminology for HWMP, especially for the process of path discovery. Terms such as Path Originator or Path Target designate very specific entities within the path discovery process. They stay with the same assigned entity for the whole path discovery process and other procedures related to this path discovery. Figure 14-4 illustrates an example utilizing this terminology. Forward path Path Intermediate Intermediate Intermediate Path originator 1 2 3 target Reverse path Figure 14-4â€”Illustration of definitions NOTEâ€”Both the path target and path originator are a path destination for the forward path and the reverse path respectively. The following terms are used within the context of a single PREQ element / PREP element pair, a so-called HWMP path discovery: â€” path originator: The path originator is the mesh STA that triggers the path discovery. â€” path originator address: The MAC address of the path originator. â€” path target: The path target is the entity to which the path originator attempts to establish a path. NOTEâ€”When an originator mesh STA initially attempts to establish a path to a target, it does not know whether the target is a mesh STA in the mesh BSS or not. Only when the Originator receives a PREP element does it learn if the target is a mesh STA in the mesh BSS or not. If the target is in the mesh BSS, it is referred to as a target mesh STA. If the target is outside the mesh BSS, the term target proxy mesh gate refers to the mesh gate proxying for the target. â€” path target address: The MAC address of the path target. â€” intermediate mesh STA: The intermediate mesh STA is the mesh STA that participates in path selection and is neither path originator nor path target. â€” intermediate mesh STA address: The MAC address of the intermediate mesh STA. â€” forward path: The forward path is the mesh path to the path target, set up at the path originator and intermediate mesh STAs. â€” reverse path: The reverse path is the mesh path to the path originator, set up at the path target and intermediate mesh STAs. 2164 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” HWMP sequence number (HWMP SN): Each mesh HWMP path selection element contains an HWMP SN that allows recipients to distinguish newer from stale information. An HWMP SN is specific to a mesh STA. See also 14.10.8.3. â€” forwarding information: The forwarding information maintained by an originator mesh STA, an intermediate mesh STA, or a target mesh STA that allows the mesh STA to perform its path selection and forwarding functions. The terminology used when discussing forwarding information is relative to the mesh STA (reference mesh STA, given mesh STA or local mesh STA) and a particular mesh destination of the path. The following terms are specific to a given instance of the forwarding information: â€” destination mesh STA: The end station (mesh STA) of a (forward or reverse) path. â€” destination mesh STA address: The MAC address of the destination mesh STA. â€” destination HWMP SN: The HWMP SN of the destination mesh STA. â€” next-hop mesh STA: The next-hop mesh STA is the next peer mesh STA on the mesh path to the destination mesh STA. â€” next-hop mesh STA address: The MAC address of the next-hop mesh STA. â€” precursor mesh STA: A precursor mesh STA is a neighbor peer mesh STA on the mesh path that identifies a given mesh STA as the next-hop mesh STA to the destination mesh STA. â€” precursor mesh STA address: The MAC address of the precursor mesh STA. â€” lifetime: The time during which forwarding information remains active (see 14.10.8.4) â€” unreachable destination: A destination mesh STA is considered unreachable by a source mesh STA or an intermediate mesh STA if the link to the next hop of the mesh path to this destination mesh STA, as derived from its forwarding information, is no longer usable. â€” element time to live (Element TTL): An integer number that is used to limit the number of hops an HWMP element may be processed and propagated. Note that this Element TTL is different from the Mesh TTL in the Mesh Control field (see 9.2.4.7.3). â€” root mesh STA: A root mesh STA is configured to originate proactive PREQ elements or RANN elements. It is the root of a path selection tree. Table 14-6 and Table 14-7 show the roles of the various mesh STAs in the forward path and reverse path generated as a result of the full PREQ element and PREP element processing as shown in Figure 14-4. Each row in the table contains the roles of a forward/reverse path from the reference mesh STAâ€™s perspective. Table 14-6â€”Precursor and next hop examples (forward path) Forward path (to Path Target) Reference mesh Precursor mesh Next-hop mesh Destination mesh STA STA STA STA Path Originator N/A Intermediate 1 Path Target Intermediate 2 Intermediate 1 Intermediate 3 Path Target Path Target Intermediate 3 N/A Path Target 2165 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 14-7â€”Precursor and next hop examples (reverse path) Reverse path (to Path Originator) Reference mesh Precursor mesh Next-hop mesh Destination mesh STA STA STA STA Path Originator Intermediate 1 N/A Path Originator Intermediate 2 Intermediate 3 Intermediate 1 Path Originator Path Target N/A Intermediate 3 Path Originator 14.10.3 On-demand path selection mode If a source mesh STA needs to find a path to a destination mesh STA using the on-demand path selection mode, it broadcasts a PREQ element with the path target specified in the list of targets and the metric field initialized to the initial value of the active path selection metric. When a mesh STA receives a new PREQ element, it creates or updates its path information to the originator mesh STA and propagates the PREQ element to its neighbor peer mesh STAs if the PREQ element contains a greater HWMP SN, or the HWMP SN is the same as the current path and the PREQ element offers a better metric than the current path. Each mesh STA may receive multiple copies of the same PREQ element that originated at the originator mesh STA, each PREQ element traversing a unique path. Whenever a mesh STA propagates a PREQ element, the metric field in the PREQ element is updated to reflect the cumulative metric of the path to the originator mesh STA. If the mesh STA that received a PREQ element is the target mesh STA, it sends a PREP element back to the originator mesh STA after creating or updating a path to the originator mesh STA. The PREQ element provides the TO (Target Only) subfield that allows path selection to take advantage of existing paths to the target mesh STA by allowing an intermediate mesh STA to return a PREP element to the originator mesh STA. If the TO (Target Only) subfield is 1, only the target mesh STA responds with a PREP element. The effect of setting the TO (Target Only) subfield to 0 is the quick establishment of a path using the PREP element generated by an intermediate mesh STA, allowing the forwarding of MSDUs with a low path selection delay. In order to select (or validate) the best path during the path selection procedure, the intermediate mesh STA that responded with a PREP element propagates the PREQ element with the TO (Target Only) subfield set to 1. This prevents all other intermediate mesh STAs on the way to the target from sending a PREP element. Intermediate mesh STAs create a path to the target mesh STA on receiving the PREP element, and also forward the PREP element toward the originator. When the originator receives the PREP element, it creates a path to the target mesh STA. If the target mesh STA receives further PREQ elements with a better metric, then the target updates its path to the originator with the new path and also sends a new PREP element to the originator along the updated path. A bidirectional, best metric end-to-end path is established between the originator and target mesh STA. 14.10.4 Proactive tree building mode 14.10.4.1 General There are two mechanisms for proactively disseminating path selection information for reaching the root mesh STA. The first method uses a proactive PREQ element and is intended to create paths between all 2166 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications mesh STAs and the root mesh STA in the network proactively. The second method uses a RANN element and is intended to distribute path information for reaching the root mesh STA but there is no forwarding information created. A mesh STA configured as root mesh STA sends either proactive PREQ elements or proactive RANN elements periodically. 14.10.4.2 Proactive PREQ mechanism The PREQ tree building process begins with a proactive PREQ element sent by the root mesh STA, with the Target Address set to all 1s and the TO subfield set to 1. The PREQ element contains the path metric (set to the initial value of the active path selection metric by the root mesh STA) and an HWMP SN. The proactive PREQ element is sent periodically by the root mesh STA, with increasing HWMP SNs. A mesh STA receiving a proactive PREQ element creates or updates its forwarding information to the root mesh STA, updates the metric and hop count of the PREQ element, records the metric and hop count to the root mesh STA, and then transmits the updated PREQ element. Information about the presence of and distance to available root mesh STA(s) is disseminated to all mesh STAs in the network. Each mesh STA may receive multiple copies of a proactive PREQ element, each traversing a unique path from the root mesh STA to the mesh STA. A mesh STA updates its current path to the root mesh STA if and only if the PREQ element contains a greater HWMP SN, or the HWMP SN is the same as the current path and the PREQ element offers a better metric than the current path to the root mesh STA. The processing of the proactive PREQ element is the same as the processing of the PREQ element in the on-demand mode described in 14.10.3. If the proactive PREQ element is sent with the Proactive PREP subfield set to 0, the recipient mesh STA may send a proactive PREP element. A proactive PREP element is necessary, for example, if the mesh STA has data to send to the root mesh STA, thus requiring the establishment of a forward path from the root mesh STA. During the time the forward path is required, the recipient mesh STA shall send a proactive PREP element even if the Proactive PREP subfield is set to 0. Guidance on controlling the generation of proactive PREQ elements in such a case is given in S.6. If the PREQ element is sent with a Proactive PREP subfield set to 1, the recipient mesh STA shall send a proactive PREP element. The proactive PREP element establishes the path from the root mesh STA to the mesh STA. 14.10.4.3 Proactive RANN mechanism The root mesh STA periodically propagates a RANN element into the network. The information contained in the RANN element is used to disseminate path metrics to the root mesh STA, but reception of a RANN element does not establish a path. Upon reception of a RANN element, each mesh STA that has to create or refresh a path to the root mesh STA sends an individually addressed frame containing a PREQ element to the root mesh STA via the mesh STA from which it received the RANN element. The root mesh STA sends a PREP element in response to each PREQ element. The individually addressed frame containing a PREQ element creates the reverse path from the root mesh STA to the originator mesh STA, while the PREP element creates the forward path from the mesh STA to the root mesh STA. 2167 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 14.10.5 Collocated STAs HWMP terminology strictly refers to a STA whose address is used for destination mapping (i.e., the originator address, the intermediate mesh STA address, or the target address). HWMP terminology does not make any assumption about the address used for communication over the WM (i.e., the Transmitter Address and the Receiver Address). For example, there is no requirement that the Path Originator or the Path Target of an HWMP path are the same as the address used for transmitting the first and receiving the last (respectively) HWMP Mesh Path Selection frame containing a PREQ element. The corollary to this is that the first hop of a PREQ element may have a transmitter address that is not the same as the Originator address in the PREQ element and that the first hop may have a transmitter address that is not the same as the source address. In order to determine whether a transmission is a first hop or not, mesh STAs should not compare the source and transmitter addresses. Instead, this determination can be made by looking at the hop count field of the PREQ element (which is not used as an acceptance criterion). 14.10.6 Parameters for extensible path selection framework Table 14-8 gives the parameters of HWMP for the extensible path selection framework (see 14.8.2). Table 14-8â€”Parameters of HWMP for extensible path selection framework Parameter Notes Path Selection Protocol ID See Table 9-217 in 9.4.2.98.2 Data type of metric field As defined by active path selection metric Length of metric field 4 octets Operator for metric aggregation As defined by active path selection metric Comparison operator As defined by active path selection metric Initial value of path metric As defined by active path selection metric 14.10.7 Addressing of HWMP Mesh Path Selection frame All HWMP elements are sent in an HWMP Mesh Path Selection frame (see 9.6.17.3). The RANN element may also be sent in a Beacon frame. â€œCasesâ€ refer to the different conditions that trigger the transmission of an HWMP Mesh Path Selection frame. PREQ element cases are specified in 14.10.9.3. PREP element cases are specified in 14.10.10.3. PERR element cases are specified in 14.10.11.3. RANN element cases are specified in 14.10.12.3. Note that the PREQ Addressing Mode subfield in the Flags field identifies the propagation mode of the PREQ element; an Addressing Mode subfield equal to 0 indicates that the PREQ element is group addressed, an Addressing Mode subfield equal to 1 indicates that the PREQ element is individually addressed. The addresses of the HWMP Mesh Path Selection frame shall be as follows: â€” PREQ element group addressedâ€”Addressing Mode subfield = 0 [Case A: Path Discovery (Original transmission), Case B: Path Maintenance (Original transmission), Case C: Proactive PREQ element (Original transmission), and Case E: PREQ element Propagation]: â€” Address 1: Group address â€” Address 2: Address of the mesh STA sending the PREQ element â€” Address 3: Same as Address 2 2168 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” PREQ element individually addressedâ€”Addressing Mode subfield = 1 [Case D: Root Path Confirmation (Original transmission)]: â€” Address 1: Address 2 of the frame containing the RANN element that triggered the PREQ element â€” Address 2: Address of the mesh STA sending the PREQ element â€” Address 3: Same as Address 2 â€” PREQ element individually addressedâ€”Addressing Mode subfield = 1 [Case E: PREQ element Propagation]: â€” Address 1: Next-hop MAC address to the mesh STA identified as the Target MAC address in the PREQ element â€” Address 2: Address of the mesh STA sending the PREQ element â€” Address 3: Same as Address 2 â€” PREP element Case A: Original transmission, Case C: Intermediate reply, Case D: Proactive PREP element in Proactive PREQ element mode: â€” Address 1: Address of the next hop to the Originator Mesh STA Address in the PREQ element that triggered the PREP element â€” Address 2: Address of the mesh STA sending the PREP element â€” Address 3: Same as Address 2 â€” PREP element Case B: PREP element Propagation: â€” Address 1: Address of the next hop to the Originator Mesh STA Address in the PREP element that triggered the PREP element â€” Address 2: Address of the mesh STA sending the PREP element â€” Address 3: Same as Address 2 â€” PERR element individually addressed [Case A: Original transmissionâ€”next hop is unusable]: â€” Address 1: Address of each one of the precursors for which the active forwarding information has been invalidated [see Case A, 14.10.11.3] â€” Address 2: Address of the mesh STA sending the PERR element â€” Address 3: Same as Address 2 â€” PERR element individually addressed [Case B: Original transmissionâ€”missing forwarding information]: â€” Address 1: Address of the transmitter of the frame that triggered the PERR element (see Case B, 14.10.11.3) â€” Address 2: Address of the mesh STA sending the PERR element â€” Address 3: Same as Address 2 â€” PERR element individually addressed [Case C: Original transmission (proxy information is unusable)]: â€” Address 1: Address of each one of the neighbor peer mesh STAs â€” Address 2: Address of the mesh STA sending the PERR element â€” Address 3: Same as Address 2 â€” PERR element individually addressed [Case D: PERR element propagation]: â€” Address 1: Address of each one of the precursors for which the active forwarding information has been invalidated (see 14.10.11.4.3) â€” Address 2: Address of the mesh STA sending the PERR element â€” Address 3: Same as Address 2 â€” PERR element group addressed [all cases]: â€” Address 1: Group address â€” Address 2: Address of the mesh STA sending the PERR element â€” Address 3: Same as Address 2 2169 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” RANN element all cases: â€” Address 1: Group address â€” Address 2: Address of the mesh STA sending the RANN element â€” Address 3: Same as Address 2 Multiple HWMP elements may be sent in the same HWMP Mesh Path Selection frame if they share the same intended Address 1. 14.10.8 General rules for processing HWMP elements 14.10.8.1 General This subclause describes the rules for the processing of the following components of the HWMP elements: â€” HWMP SN â€” Element TTL â€” Metric 14.10.8.2 HWMP propagation The term propagate is used to describe the means by which elements are not transmitted â€œas isâ€ across the network but are processed and modified along the way. Many HWMP elements are intended to be processed and propagated across an MBSS by mesh STAs. Each propagation is subject to certain rules or limitations as explained in the following subclauses. Certain parameters in the HWMP elements are updated during the propagation. See 14.10.9, 14.10.10, 14.10.11, and 14.10.12. The originator of an HWMP element sets the initial value of the Element TTL. The mesh STA that receives the HWMP element shall propagate it if the received value of Element TTL is greater than 1. Before propagating the HWMP element, the mesh STA decrements the Element TTL value. In general, the propagation of an HWMP element is not subject to a delay. Exception exists for the RANN element as described in 14.10.12. 14.10.8.3 HWMP sequence numbering HWMP uses sequence numbers to prevent the creation of path loops and to distinguish stale and fresh path information. Each mesh STA keeps its own HWMP SN that it increments, uses in HWMP elements, and processes according to the HWMP rules. HWMP SNs for other mesh STAs are maintained in the forwarding information (see 14.10.8.4). An HWMP SN is included in the PREQ, PREP, PERR, and RANN elements. The HWMP SN in the forwarding information is updated whenever a mesh STA receives new (i.e., not stale) information about the HWMP SN from a PREQ, PREP, or PERR element that may be received relative to that originator mesh STA, target mesh STA, or destination mesh STA. HWMP depends on each mesh STA in the network to own and maintain its HWMP SN to guarantee the loop-freedom of all paths toward that mesh STA. A mesh STA increments its own HWMP SN in the following two circumstances: â€” If it is an originator mesh STA, it shall increment its own HWMP SN immediately before it starts a path discovery. This prevents conflicts with previously established reverse paths toward the originator mesh STA. However, it might be advantageous not to increment the HWMP SN too frequently. An optional mechanism for achieving this is described in 14.10.8.6. 2170 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” If it is a target mesh STA, it shall update its own HWMP SN to maximum (current HWMP SN, target HWMP SN in the PREQ element) + 1 immediately before it generates a PREP element in response to a PREQ element. The target HWMP SN of the PREQ element is relevant when a link was broken along the path and the stored sequence number was increased at an intermediate mesh STA. Comparing HWMP SNs is done using a circular modulo 232 comparison. In general, when a mesh STA receives an element with an HWMP SN that is less than the HWMP SN in the corresponding forwarding information, it discards the received element. If they are the same, the outcome (element processed or not) depends on the type of the element and some additional conditions. These cases are noted in the applicable element descriptions. The only circumstance in which a mesh STA may change the HWMP SN of another mesh STA in the forwarding information independently of the reception of an HWMP element originated by this mesh STA is in response to a broken or no longer usable link to the next hop toward that destination mesh STA. The mesh STA determines which destinations use a particular next hop by consulting its forwarding information. In this case, for each destination that uses the next hop, the mesh STA increments the HWMP SN in the forwarding information and marks the path as invalid (see also 14.10.11). Whenever any forwarding information containing an HWMP SN greater than the recorded HWMP SN for an affected destination is received by a mesh STA that has marked that recorded forwarding information as invalid, the mesh STA shall update its forwarding information according to the information contained in the update. 14.10.8.4 Forwarding information In addition to the parameters contained in the basic forwarding information as described in 10.35.2, the forwarding information to a destination defined by HWMP also contains at least the destination HWMP SN, the path metric, and the number of hops. PREQ elements and PREP elements create or update the forwarding information of the mesh STAs that process these elements as follows: â€” The mesh STA may create or update its forwarding information to the transmitter of the element if the path metric improves. â€” The mesh STA shall create or update its forwarding information to the originator mesh STA, if it received a PREQ element, and one of the following conditions is met: â€” The Originator HWMP SN > HWMP SN in the forwarding information for this originator mesh STA, or â€” The Originator HWMP SN = HWMP SN in the forwarding information for this originator mesh STA AND the updated path metric is better than the path metric in the forwarding information. â€” The mesh STA shall create or update its forwarding information to the target mesh STA, if it received a PREP element, and one of the following conditions is met: â€” The Target HWMP SN > HWMP SN in the forwarding information for this target mesh STA, or â€” The Target HWMP SN = HWMP SN in the forwarding information for this target mesh STA AND the updated path metric is better than the path metric in the forwarding information. Table 14-9 defines the values to be stored in the different fields of the forwarding information after a PREQ element or PREP element has been received. Changes to the forwarding information in other situations, for instance, when processing a PERR element (see 14.10.11), are described in the corresponding clauses. 2171 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 14-9â€”Data for creation and update of forwarding information due to PREQ element and PREP element Received PREQ element Received PREP element Field of forwarding Forwarding Forwarding Forwarding Forwarding information information for information for information for information for transmitter of originator mesh transmitter of target mesh STA PREQ element STA PREP element HWMP SN Invalid if created, no PREQ element Invalid if created, no PREP element change if updated field change if updated field Target HWMP Originator HWMP Sequence Number Sequence Number Next hop Transmitter address Transmitter address Transmitter address Transmitter address of the Management of the Management of the Management of the Management frame containing the frame containing the frame containing the frame containing the PREQ element PREQ element PREP element PREP element Path metric Accumulation of the Accumulation of the Accumulation of the Accumulation of the initial value of the value of PREQ initial value of the value of PREP path metric with the element field path metric with the element field metric of the link to Metric with the metric of the link to Metric with the the transmitter of metric of the link to the transmitter of metric of the link to the PREQ element the transmitter of the PREP element the transmitter of the PREQ element the PREP element Number of hops 1 Value of PREQ 1 Value of PREP element field Hop element field Hop Count + 1 Count + 1 Precursor list No change No change except in No change See 14.10.10.4.3 case of an step d) intermediate reply [see 14.10.9.4.3 step f)] Lifetime The longer one of The longer one of The longer one of The longer one of the lifetime of the the lifetime of the the lifetime of the the lifetime of the stored forwarding stored forwarding stored forwarding stored forwarding information and the information and the information and the information and the value of PREQ value of PREQ value of PREP value of PREP element field element field element field element field Lifetime Lifetime Lifetime Lifetime 14.10.8.5 Repeated attempts at path discovery Repeated attempts by a mesh STA at path discovery toward a single target shall be limited to dot11MeshHWMPmaxPREQretries. The minimum waiting time for the repeated attempt at path discovery to a single target is 2 dot11MeshHWMPnetDiameterTraversalTime. For each attempt, the HWMP SN is incremented and a new Path Discovery ID is chosen. 2172 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 14.10.8.6 Limiting the rate of HWMP SN increments In order to improve path stability (and further reduce overhead), a mesh STA may use the same originator HWMP SN for a certain time interval. In this case, the originator HWMP SN shall not be incremented until at least dot11MeshHWMPnetDiameterTraversalTime has elapsed since the previous increment. This mechanism prevents mesh STAs from changing the path frequently to the originator mesh STA every time the originator mesh STA sends a burst of PREQ elements within a very short time. This element of the protocol allows an originator mesh STA to immediately initiate on-demand path discovery to a new target without affecting recently refreshed paths to the originator in other mesh STAs. 14.10.9 Path request (PREQ) mechanism 14.10.9.1 General This subclause describes the function, generation, and processing of the PREQ element. 14.10.9.2 Function The PREQ element, described in 9.4.2.113, is used for the following purposes: â€” Discovering a path to one or more target mesh STAs â€” Maintaining a path (optional) â€” Building a proactive (reverse) path selection tree to the root mesh STA â€” Confirming a path to a target mesh STA (optional) 14.10.9.3 Conditions for generating and sending a PREQ element A mesh STA shall send a PREQ element in an HWMP Mesh Path Selection frame, as defined in 9.6.17.3, in the following cases: Case A: Path Discovery (Original Transmission) All of the following conditions apply: â€” The mesh STA needs to establish an on-demand path to one or more targets for which there is no ongoing path discovery initiated by this mesh STA. â€” The mesh STA has not sent a PREQ element for the target mesh STAs less than dot11MeshHWMPpreqMinInterval TUs ago. If this is the case, the transmission of the PREQ element has to be postponed until this condition becomes true. â€” The mesh STA has not made more than (dot11MeshHWMPmaxPREQretries â€“ 1) repeated attempts at path discovery toward the target of the PREQ element. The content of a PREQ element in Case A shall be as shown in Table 14-10. 2173 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 14-10â€”Contents of a PREQ element in Case A Field Value Element ID Value given in Table 9-77 for the PREQ element Length 26 + N 11 (if Bit 6 (AE subfield) in the Flags field = 0) 32 + N 11 (if Bit 6 (AE subfield) in the Flags field = 1) Flags Bit 0: 0 (gate announcement not applicable) Bit 1: 0 (group addressed) Bit 2: 0 (no proactive PREP element applicable) Bit 3â€“5: Reserved Bit 6: (1 â€“ if external address present, 0 â€“ otherwise) Bit 7: Reserved Hop Count 0 Element TTL Maximum number of hops allowed for this element, e.g., dot11MeshHWMPnetDiameter. Path Discovery ID New unique Path Discovery ID, for instance, previous Path Discovery ID + 1 Originator Mesh STA Address MAC address of the path originator Originator HWMP Sequence Previous Originator HWMP SN + 1. See 14.10.8.6 Number Originator External Address Present only if Bit 6 in Flags field = 1. This value is set to the external address, which is the source address of the MSDU (from outside the mesh BSS) that triggered the path discovery at the originator. Lifetime The time for which mesh STAs receiving the PREQ element consider the forwarding information to be valid, e.g., dot11MeshHWMPactivePathTimeout. Metric Initial value of active path selection metric Target Count N (N â‰¥ 1) Per Target Per Target Bit 0 (TO): dot11MeshHWMPtargetOnly Flags Bit 1: Reserved Bit 2 (USN): 0 if forwarding information for Target Address with valid HWMP SN exists, 1 otherwise Bit 3â€“7: Reserved Target Address MAC address of requested target Target HWMP If Per Target Flags Bit 2 (USN) is 0, the latest HWMP SN stored by Sequence the originator mesh STA for the target mesh STA from the Number forwarding information (see 14.10.8.4). Otherwise, reserved. 2174 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Case B: Path Maintenance (Original Transmission) (optional) All of the following conditions apply: â€” The mesh STA has a path to a given target mesh STA that is not a root mesh STA. â€” The last PREQ element to this target was sent dot11MeshHWMPmaintenanceInterval TUs (or more) ago. The content of a PREQ element in Case B shall be as shown in Table 14-11. Table 14-11â€”Contents of a PREQ element in Case B Field Value Element ID Value given in Table 9-77 for the PREQ element Length 26 + N 11 Flags Bit 0: 0 (gate announcement not applicable) Bit 1: 0 (group addressed) Bit 2: 0 (no proactive PREP element applicable) Bit 3â€“5: Reserved Bit 6: 0 (no address extension) Bit 7: Reserved Hop Count 0 Element TTL Maximum number of hops allowed for this element, e.g., dot11MeshHWMPnetDiameter Path Discovery ID New unique Path Discovery ID, for instance, previous Path Discovery ID + 1 Originator Mesh STA Address MAC address of the originator of the PREQ element Originator HWMP Sequence Originator HWMP SN + 1. See 14.10.8.6 Number Originator External Address Field not present Lifetime The time for which mesh STAs receiving the PREQ element consider the forwarding information to be valid, e.g., dot11MeshHWMPactivePathTimeout. Metric Initial value of active path selection metric Target Count N (N â‰¥ 1) Per Target Per Target Bit 0 (TO): 1 (target only) Flags Bit 1: Reserved Bit 2 (USN): 0 Bit 3â€“7: Reserved Target Address MAC Address of target mesh STA Target HWMP The latest HWMP SN for this target known to the originator mesh Sequence STA. Number 2175 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Case C: Proactive PREQ element (Original Transmission) All of the following conditions apply: â€” The root mesh STA is configured as root mesh STA using proactive PREQ elements ([dot11MeshHWMProotMode = proactivePREQnoPREP (2)] OR [dot11MeshHWMProotMode = proactivePREQwithPREP (3)]). â€” The root mesh STA sent its previous proactive PREQ element dot11MeshHWMProotInterval TUs ago. The contents of a PREQ element in Case C shall be as shown in Table 14-12. Table 14-12â€”Contents of a PREQ element in Case C Field Value Element ID Value given in Table 9-77 for the PREQ element Length 37 Flags Bit 0: 1 if dot11MeshGateAnnouncements is true (gate announcement), 0 otherwise Bit 1: 0 (group addressed) Bit 2: 0 if dot11MeshHWMProotMode = proactivePREQnoPREP(2), 1 if dot11MeshHWMProotMode = proactivePREQwithPREP(3) (proactive PREP) Bit 3â€“5: Reserved Bit 6: 0 (no address extension) Bit 7: Reserved Hop Count 0 Element TTL Maximum number of hops allowed for this element, e.g., dot11MeshHWMPnetDiameter. Path Discovery ID New unique Path Discovery ID, for instance, previous Path Discovery ID + 1 Originator Mesh STA Address MAC address of the root mesh STA Originator HWMP Sequence Originator HWMP SN + 1. See 14.10.8.6 Number Originator External Address Field not present Lifetime dot11MeshHWMPactivePathToRootTimeout Metric Initial value of active path selection metric Target Count 1 Per Target Per Target Bit 0 (TO): 1 Flags Bit 1: Reserved Bit 2 (USN): 1 Bit 3â€“7: Reserved Target Address Broadcast address Target HWMP 0 Sequence Number 2176 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Case D: Root Path Confirmation (Original Transmission) One of the following conditions applies: â€” The mesh STA has received a RANN element and the metric (RANN metric metric to the transmitter of the RANN element) is better than the metric to the root in the current forwarding information. â€” The mesh STA has a path to a root mesh STA and the last PREQ element to the root mesh STA was sent dot11MeshHWMPconfirmationInterval TUs (or more) ago. The content of a PREQ element in Case D shall be as shown in Table 14-13. Table 14-13â€”Contents of a PREQ element in Case D Field Value Element ID Value given in Table 9-77 for the PREQ element Length As required Flags Bit 0: 0 (gate announcement not applicable) Bit 1: 1 (individually addressed) Bit 2: 0 (no proactive PREP element applicable) Bit 3â€“5: Reserved Bit 6: 0 (no address extension) Bit 7: Reserved Hop Count 0 Element TTL Maximum number of hops allowed for this element, e.g., dot11MeshHWMPnetDiameter Path Discovery ID Not used Originator Mesh STA Address MAC address of the originator mesh STA Originator HWMP Sequence Originator HWMP SN + 1. See 14.10.8.6 Number Originator External Address Field not present Lifetime The time for which mesh STAs receiving the PREQ element consider the forwarding information to be valid, e.g., dot11MeshHWMPactivePathToRootTimeout. Metric Initial value of active path selection metric Target Count 1 Per Target Per Target Bit 0 (TO): 1 Flags Bit 1: Reserved Bit 2 (USN): 0 Bit 3â€“7: Reserved Target Address Root mesh STA MAC Address Target HWMP The latest HWMP SN for this target known to the originator mesh Sequence STA Number 2177 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Case E: PREQ element Propagation Case E1 (target count = 1, no PREP element generation as intermediate mesh STA): All of the following conditions apply: â€” The mesh STA has received and accepted a PREQ elementâ€”see 14.10.9.4.2. â€” dot11MeshForwarding is true. â€” [The active forwarding information for the Originator Mesh STA was created or updated according to the rules defined in 14.10.8.4] OR [{the Originator HWMP SN of the accepted PREQ element = HWMP SN in the forwarding information for this originator mesh STA} AND {the mesh STA has not previously received a PREQ element with the same Originator Mesh STA Address and the same Path Discovery ID}]. â€” The Element TTL field is greater than 1â€”see 14.10.8.2. â€” Target Count = 1. â€” [The mesh STA is not the target of the PREQ element)] OR [the target of the PREQ element is the MAC broadcast address (all 1s)]. â€” The mesh STA is not the proxy of the target address. â€” [The TO (Target Only) subfield of the target in the PREQ element is set (TO = 1)] OR [{the TO (Target Only) subfield of the target in the PREQ element is not set (TO = 0)} AND {mesh STA has no active forwarding information for the requested target}]. The content of a PREQ element in Case E1 shall be as shown in Table 14-14. Table 14-14â€”Contents of a PREQ element in Case E1 Field Value Element ID Value given in Table 9-77 for the PREQ element Length As received Flags As received Hop Count As received + 1 Element TTL As received â€“ 1 Path Discovery ID As received Originator Mesh STA Address As received Originator HWMP Sequence As received Number Originator External Address As received. This field is present if Bit 6 of the Flags field (AE subfield) is 1; it is not present otherwise. Lifetime As received Metric As received own metric toward transmitter of received PREQ element Target Count 1 2178 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 14-14â€”Contents of a PREQ element in Case E1 (continued) Field Value Per Target Per Target As received Flags Target MAC As received Address Target HWMP As received Sequence Number Case E2 (target count = 1, PREP element generation as intermediate mesh STA): All of the following conditions apply: â€” The mesh STA has received and accepted a PREQ elementâ€”see 14.10.9.4.2. â€” dot11MeshForwarding is true. â€” [The active forwarding information for the Originator Mesh STA was created or updated according to the rules defined in 14.10.8.4] OR [{the Originator HWMP SN of the accepted PREQ element = HWMP SN in the forwarding information for this originator mesh STA} AND {the mesh STA has not previously received a PREQ element with the same Originator Mesh STA Address and the same Path Discovery ID}]. â€” The Element TTL field is greater than 1â€”see 14.10.8.2. â€” Target Count = 1. â€” The mesh STA is not the target of the PREQ element. â€” The mesh STA is not the proxy of the target address. â€” The mesh STA has active forwarding information for the requested target. â€” [The TO (Target Only) subfield of the target in the PREQ element is not set (TO = 0)] AND [the mesh STA has active forwarding information for the requested target]. The contents of a PREQ element in Case E2 shall be as shown in Table 14-15. Table 14-15â€”Contents of a PREQ element in Case E2 Field Value Element ID Value given in Table 9-77 for the PREQ element Length As received Flags As received Hop Count As received + 1 Element TTL As received â€“ 1 Path Discovery ID As received Originator Mesh STA Address As received Originator HWMP Sequence As received Number 2179 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 14-15â€”Contents of a PREQ element in Case E2 (continued) Field Value Originator External Address As received. This field is present if Bit 6 of the Flags field (AE subfield) is 1; it is not present otherwise. Lifetime As received Metric As received own metric toward transmitter of received PREQ element Target Count 1 Per Target Per Target Bit 0 (TO): 1 (target only because mesh STA sent a PREP element) Flags Bit 1: Reserved Bit 2 (USN): As received Bit 3â€“7: Reserved Target MAC As received Address Target HWMP As received Sequence Number Case E3 (target count > 1): All of the following conditions apply: â€” The mesh STA has received and accepted a PREQ elementâ€”see 14.10.9.4.2. â€” dot11MeshForwarding is true. â€” [The active forwarding information for the Originator Mesh STA was created or updated according to the rules defined in 14.10.8.4 OR [{the Originator HWMP SN of the accepted PREQ element = HWMP SN in the forwarding information for this originator mesh STA} AND {the mesh STA has not previously received a PREQ element with the same Originator Mesh STA Address and the same Path Discovery ID}]. â€” The Element TTL field is greater than 1â€”see 14.10.8.2. â€” Target Count > 1. â€” There is at least one requested target that is neither the recipient MAC address nor an external MAC address proxied by the recipient. The contents of a PREQ element in Case E3 shall be as shown in Table 14-16. Table 14-16â€”Contents of a PREQ element in Case E3 Field Value Element ID Value given in Table 9-77 for the PREQ element Length 26 + N 11 Flags As received Hop Count As received + 1 Element TTL As received â€“ 1 2180 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 14-16â€”Contents of a PREQ element in Case E3 (continued) Field Value Path Discovery ID As received Originator Mesh STA Address As received Originator HWMP Sequence As received Number Originator External Address As received. This field is present if Bit 6 of the Flags field (AE subfield) is set to 1; it is not present otherwise. Lifetime As received Metric As received own metric toward the transmitter of the received PREQ element Target Count 1 target count received target count received target count less the number of requested destinations, for which the processing mesh STA â€” is the target mesh STA or â€” is the target proxy mesh gate Per Target #A Per Target As received Flags #A Target MAC As received Address #A Target HWMP As received Sequence Number #A Per Target #B Per Target Bit 0 (TO): 1 (target only because mesh STA sent PREP element) Flags #B Bit 1: As received Bit 2 (USN): As received Bit 3â€“7: As received Target MAC As received Address #B Target HWMP As received Sequence Number #B For the per target fields (Per Target Flags, Target Address, Target HWMP Sequence Number) assume the following: â€” Target #A: If target A would have been the only requested target, it would generate a PREQ element for propagation according to case E1. â€” Target #B: If target B would have been the only requested target, it would generate a PREQ element for propagation according to case E2. 2181 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 14.10.9.4 PREQ element processing 14.10.9.4.1 General Received PREQ elements are subject to certain acceptance criteria. Processing and actions taken depend on the contents of the PREQ element and the information available to the receiving mesh STA. See also 14.10.8. 14.10.9.4.2 Acceptance criteria The PREQ element shall not be accepted (and shall not be processed as described in 14.10.9.4.3) if any of the following is true: â€” (The target address of the PREQ element is neither the recipient MAC address, broadcast address, nor an external MAC address proxied by the recipient) AND (dot11MeshForwarding is false) â€” (Bit 1 (Addressing Mode subfield) of the Flags field in the PREQ element is equal to 1) AND (there is no valid forwarding information with the destination mesh STA address equal to the Target Address of the PREQ element) Otherwise, the PREQ element is accepted. See also 14.10.8. 14.10.9.4.3 Effect of receipt A mesh STA receiving a PREQ element according to the acceptance criteria in 14.10.9.4.2 shall record the Path Discovery ID and the Originator Mesh STA Address. The receiving mesh STA shall create or update the active forwarding information it maintains for the originator mesh STA of the PREQ element according to the rules defined in 14.10.8.4. If the active forwarding information for the Originator Mesh STA was created or updated according to the rules defined in 14.10.8.4 or if the Target HWMP SN of the PREQ element is the same as the HWMP SN in the forwarding information for the Target Mesh STA and there has been no record of the Originator Mesh STA and Path Discovery ID, the following applies: a) If the mesh STA is the target of the PREQ element or is the proxy of the target MAC address it shall initiate the transmission of a PREP element to the originator mesh STA (14.10.10.3 Case A). If the PREQ element carries an external address (indicated by the AE subfield in the Flags field), the mesh STA shall update its proxy information with the Originator External Address as external address, the PREQ element Originator Mesh STA Address as the corresponding proxy, the HWMP Sequence Number as proxy information sequence number, and for the proxy lifetime the longer one of the value of the PREQ element Lifetime field and the proxy lifetime if the proxy information already exists (see also 14.11.4.3). b) If step a) was not applicable for the mesh STA and the AE subfield in the Flags field in the PREQ element is 1, the mesh STA may update its proxy information with the Originator External Address as external address, the PREQ element Originator Mesh STA Address as the corresponding proxy, the HWMP Sequence Number as proxy information sequence number, and for the proxy lifetime the longer one of the value of the PREQ element Lifetime field and the proxy lifetime if the proxy information already exists (see also 14.11.4.3). c) If the mesh STA has valid forwarding information to any of the requested targets and the TO (Target Only) subfield for such a target is not set (TO = 0), it initiates the transmission of a PREP element for each of these targets (see 14.10.10.3 Case C). d) If the mesh STA is initiating a PREP element transmission on behalf of another target according to step c) (intermediate reply), it shall process all of the following: â€” Update the precursor list in its forwarding information for the target mesh STA with the next hop from the forwarding information of the originator mesh STA. 2182 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” Update the lifetime for this precursor that is the longer one of the lifetime of the forwarding information of the target mesh STA. â€” Update the lifetime of the precursor list entry in case it already exists. â€” Update the precursor list in its forwarding information for the originator mesh STA with the next hop toward the target mesh STA. â€” Update the lifetime for this precursor that is the longer one of the lifetime of the forwarding information of the originator mesh STA. â€” Update the lifetime of the precursor list entry in case it already exists. e) If the received PREQ element is a proactive PREQ element [target address is set to all 1s, TO subfield is set (TO = 1)], the mesh STA generates a proactive PREP element to the root mesh STA (see 14.10.10.3 Case D) depending on the setting of the Proactive PREP subfield. If the Proactive PREP subfield is 1, a proactive PREP element is generated, if it is 0, a proactive PREP element is generated only if a bidirectional path to the root mesh STA is required (see S.6). f) If there are individually addressed targets in the PREQ element that have not been processed in step a) or that have been processed in step c) or in step e), the receiving mesh STA shall propagate the PREQ element as defined in 14.10.9.3 Case E. 14.10.10 Path reply (PREP) mechanism 14.10.10.1 General Subclause 14.10.10 describes the function, generation, and processing of the PREP element. 14.10.10.2 Function The PREP element is transmitted in individually addressed frames and is described in 9.4.2.114. The purpose of the PREP element is as follows: â€” To establish the forward path to a target mesh STA or target proxy mesh gate. â€” To confirm the reverse path to the originator. 14.10.10.3 Conditions for generating and sending a PREP element A mesh STA sends out a PREP element in an HWMP Mesh Path Selection frame, as defined in 9.6.17.3, in the following cases: Case A: Path Discovery (Original Transmission) A PREP element is transmitted if the mesh STA has received and accepted a PREQ element (see 14.10.9.4.2) fulfilling any one of the following conditions: â€” The Target Address of the PREQ element is the same as MAC address of the receiving mesh STA. â€” The Target Address of the PREQ element is an external address currently proxied by the mesh STA. The content of the generated PREP element in Case A shall be as shown in Table 14-17. 2183 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 14-17â€”Contents of a PREP element in Case A Field Value Element ID Value given in Table 9-77 for the PREP element Length As required Flags Bit 0â€“5: Reserved Bit 6 (AE): (1 = external address present, 0 = otherwise) Bit 7: Reserved Hop Count 0 Element TTL Maximum number of hops allowed for this element Target Mesh STA Address MAC address of the target mesh STA or target proxy mesh gate Target HWMP Sequence Number HWMP SN of the target mesh STA or target proxy mesh gate after it has been updated according to 14.10.8.3 Target External Address External target address on behalf of which the PREP element is sent. Present only if Bit 6 (AE subfield) in the Flags field is 1 Lifetime As per the PREQ element that triggered the transmission of this PREP element Metric Initial value of active path selection metric Originator Mesh STA Address MAC address of the originator mesh STA Originator HWMP Sequence HWMP SN of the originator mesh STA Number Case B: PREP element propagation A PREP element is propagated if all of the following conditions apply: â€” The mesh STA has received and accepted the PREP elementâ€”see 14.10.10.4.2. â€” The mesh STA is not the path originator. The contents of a PREP element in Case B shall be as shown in Table 14-18. Table 14-18â€”Contents of a PREP element in Case B Field Value Element ID Value given in Table 9-77 for the PREP element Length As received Flags As received Hop Count As received + 1 Element TTL As received â€“ 1 Target Mesh STA Address As received Target HWMP Sequence Number As received Target External Address As received 2184 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 14-18â€”Contents of a PREP element in Case B (continued) Field Value Lifetime As received Metric As received own metric toward the transmitting mesh STA Originator Mesh STA Address As received Originator HWMP Sequence As received Number Case C: Intermediate reply (Original Transmission) A PREP element is transmitted if the mesh STA has received a PREQ element fulfilling all of the following conditions: â€” The TO (Target Only) subfield in the corresponding Per Target Flags field in the PREQ element is not set (TO = 0) â€” The receiving mesh STA has active forwarding information with a)A destination that is the same as the Target Address of the PREQ element b)An HWMP SN that is greater than or equal to the Target HWMP SN of the PREQ element c)A nonzero lifetime The content of the generated PREP element in Case C shall be as shown in Table 14-19. Table 14-19â€”Contents of a PREP element in Case C Field Value Element ID Value given in Table 9-77 for the PREP element Length 31 Flags Bit 0â€“5: Reserved Bit 6 (AE): 0 Bit 7: Reserved Hop Count 0 Element TTL Maximum number of hops allowed for this element Target Mesh STA Address Target MAC address from the PREQ element Target HWMP Sequence Number HWMP SN of the stored forwarding information of the Target of the PREQ element Target External Address Not present Lifetime As per the PREQ element that triggered the transmission of this PREP element Metric Value of path metric taken from the active forwarding information for the target address of the PREQ element Originator Mesh STA Address MAC address of the originator mesh STA Originator HWMP Sequence Number HWMP SN of the originator mesh STA 2185 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Case D: Proactive PREP element in Proactive PREQ element mode (Original Transmission) One of the following conditions applies: â€” The mesh STA has received a proactive PREQ element with the Proactive PREP subfield set to 0 AND the mesh STA needs to establish or update a bidirectional path to the root mesh STA. â€” The mesh STA has received a proactive PREQ element with the Proactive PREP subfield set to 1. Note that a proactive PREQ element is a PREQ element with a Target Address set to all 1s and its TO subfield set (TO=1). The content of the generated PREP element in Case D shall be as shown in Table 14-20. Table 14-20â€”Contents of a PREP element in Case D Field Value Element ID Value given in Table 9-77 for the PREP element Length 31 Flags Bit 0â€“5: Reserved Bit 6 (AE): 0 Bit 7: Reserved Hop Count 0 Element TTL Maximum number of hops allowed for this element Target Mesh STA Address MAC address of the mesh STA Target HWMP Sequence Number HWMP SN of the mesh STA Target External Address Not present Lifetime Lifetime of the PREQ element that triggered the transmission of this PREP element Metric Initial value of active path selection metric Originator Mesh STA Address MAC address of the root mesh STA (originator mesh STA of the PREQ element) Originator HWMP Sequence HWMP SN of the root mesh STA (originator HWMP SN of the PREQ Number element) 14.10.10.4 PREP element processing 14.10.10.4.1 General Received PREP elements are subject to certain acceptance criteria. Processing and actions taken depend on the contents of the PREP element and the information available to the receiving mesh STA. 14.10.10.4.2 Acceptance criteria The PREP element shall not be accepted (and shall not be processed as described in 14.10.10.4.3) if any of the following is true: â€” (The Originator Mesh STA Address of the PREP element is neither the recipient MAC address nor an external MAC address proxied by the recipient) AND (dot11MeshForwarding is false). 2186 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Otherwise, the PREP element shall be accepted. 14.10.10.4.3 Effect of receipt A mesh STA receiving a PREP element according to the acceptance criteria in 14.10.10.4.2 shall create or update the active forwarding information it maintains for the target mesh STA of the PREP element (according to the rules defined in 14.10.8.4). If the conditions for creating or updating the forwarding information have not been met in those rules, no further steps are applied to the PREP element. If the active forwarding information was created or updated according to the rules defined in 14.10.8.4, the following apply: a) If the receiving mesh STA is not the final destination of the PREP element (originator mesh STA) and the field Element TTL > 1, the PREP element is propagated as defined in 14.10.10.3 Case B. b) If the receiving mesh STA is the final destination of the PREP element (originator mesh STA) and its AE subfield in the Flags field is 1, the mesh STA shall store the Target External Address, the Target Mesh STA Address, and the HWMP Sequence Number as proxy information sequence number in its proxy information. The proxy lifetime is the longer one of the value of the PREP element Lifetime field and the proxy lifetime if the proxy information already exists (see also 14.11.4.3). c) If the receiving mesh STA is not the final destination of the PREP element (originator mesh STA) and its AE subfield in the Flags field is 1, the mesh STA may store the Target External Address, the Target Mesh STA Address, and the HWMP Sequence Number as proxy information sequence number in its proxy information. The proxy lifetime is the longer one of the value of the PREP element Lifetime field and the proxy lifetime if the proxy information already exists (see also 14.11.4.3). d) If the mesh STA propagates the PREP element, the precursor list for the Target Mesh STA Address is updated by adding the next-hop mesh STA to which the PREP element is propagated. In addition, at the mesh STA the precursor list for the originator mesh STA address is updated by adding the next-hop mesh STA toward the Target Address. The lifetimes of these entries in the precursor lists are the values of the lifetimes of the corresponding forwarding information. 14.10.11 Path error (PERR) mechanism 14.10.11.1 General Subclause 14.10.11 describes the function, generation, and processing of the PERR element. 14.10.11.2 Function The PERR element is used for announcing one or more unreachable destination(s). The announcement is sent to all traffic sources that have a known active path to the destination(s). The active forwarding information associated with the unreachable destination(s) should no longer be used for forwarding. A PERR element may be either group addressed (if there are many precursors), individually addressed (if there is only one precursor), or individually addressed iteratively to all precursors (see 14.10.7, item â€œPERR element individually addressedâ€). The PERR element is processed as a single element when iteratively individually addressed to several precursors. The PERR element contains the destinations that are unreachable. A PERR element is propagated by mesh STAs receiving a PERR element if certain conditions are met. A mesh STA generating or receiving a PERR element may attempt to establish paths to unreachable destinations using any of the available HWMP mechanisms. 2187 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 14.10.11.3 Conditions for generating and sending a PERR element A mesh STA shall send out a PERR element in an HWMP Mesh Path Selection frame, as defined in 9.6.17.3, in the following cases: Case A: Original transmission (next hop is unusable) The mesh STA has not sent a PERR element less than dot11MeshHWMPperrMinInterval TUs ago, and the following condition applies: â€” The mesh STA determines that the link to the next hop of an active path in its forwarding information is no longer usable. NOTEâ€”The detection might be triggered by the fact that a mesh STA is unable to forward an MSDU/MMPDU to a next-hop mesh STA. The HWMP SN in the forwarding information of all unreachable destinations announced in this PERR element is incremented by 1. The forwarding information for each unreachable destination announced in this PERR element is invalidated. The contents of a PERR element in Case A shall be as shown in Table 14-21. Table 14-21â€”Contents of a PERR element in Case A Field Value Element ID Value given in Table 9-77 for the PERR element Length 2+N 13 Element TTL The maximum number of hops the element is propagated before being discarded. Number of Destinations Number of announced unreachable destinations in the PERR element. Flags #1 Bit 0â€“5: Reserved Bit 6 (AE): 0 Bit 7: Reserved Destination Address #1 MAC address of unreachable destination #1. HWMP Sequence Number #1 HWMP SN for Destination Address #1 from the forwarding information after above increment. Reason Code #1 â€œMESH-PATH-ERROR-DESTINATION-UNREACHABLEâ€ (see 9.4.1.7). ... ... 2188 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Case B: Original transmission (missing forwarding information) The mesh STA has not sent a PERR element less than dot11MeshHWMPperrMinInterval TUs ago, and one of the following conditions applies: â€” The mesh STA receives an individually addressed frame with a destination address not matching its own MAC address for which it has no forwarding information. â€” The mesh STA receives an individually addressed frame with a destination address not matching its own MAC address and dot11MeshForwarding is false. The contents of a PERR element in Case B shall be as shown in Table 14-22. Table 14-22â€”Contents of a PERR element in Case B Field Value Element ID Value given in Table 9-77 for the PERR element. Length 2+N 13 Element TTL The maximum number of hops the element is propagated before being discarded. Number of Destinations Number of announced destinations with missing forwarding information in the PERR element. Flags #1 Bit 0â€“5: Reserved Bit 6 (AE): 0 Bit 7: Reserved Destination Address #1 MAC address of destination with missing forwarding information #1. This is Address 3 of the received individually addressed frame. HWMP Sequence Number #1 Reserved Reason Code #1 â€œMESH-PATH-ERROR-NO-FORWARDING-INFORMATIONâ€ (see 9.4.1.7). ... ... 2189 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Case C: Original transmission (proxy information is unusable) The mesh STA has not sent a PERR element less than dot11MeshHWMPperrMinInterval TUs ago, and the following condition applies: â€” The mesh STA is a proxy mesh gate and determines that an active proxy information where the mesh STA is the proxy mesh gate is no longer usable. The contents of a PERR element in Case C shall be as shown in Table 14-23. Table 14-23â€”Contents of a PERR element in Case C Field Value Element ID Value given in Table 9-77 for the PERR element. Length 2+N 19 Element TTL The maximum number of hops the element is propagated before being discarded. Number of Destinations Number of announced unreachable external destinations in the PERR element. Flags #1 Bit 0â€“5: Reserved Bit 6 (AE): 1 Bit 7: Reserved Destination Address #1 MAC address of proxy mesh gate #1 with unusable active proxy information. HWMP Sequence Number #1 Last used HWMP SN for Destination Address #1. Destination External Address #1 External MAC address of the active proxy information that is not longer usable and for which the mesh STA is the proxy mesh gate. Reason Code #1 â€œMESH-PATH-ERROR-NO-PROXY-INFORMATIONâ€ (see 9.4.1.7. ... ... 2190 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Case D: PERR element propagation The mesh STA has not sent a PERR element less than dot11MeshHWMPperrMinInterval TUs ago, and all of the following conditions apply: â€” The mesh STA received a PERR element from a neighbor peer mesh STA. â€” A destination in the PERR element is the same as one of the destinations in the active forwarding information of the mesh STA where the next hop is the transmitter of the received PERR element, and the forwarding information or the proxy information has been invalidated according to conditions in 14.10.11.4.3 case b), case c), or case d). â€” dot11MeshForwarding is true. â€” The Element TTL field in the received PERR element is greater than 1. The contents of a PERR element in Case D shall be as shown in Table 14-24. Table 14-24â€”Contents of a PERR element in Case D Field Value Element ID Value given in Table 9-77 for the PERR element Length if AE subfield = 0: 2 + N 13 if AE subfield = 1: 2 + N 19 Element TTL Element TTL in received PERR element â€“ 1 Number of Destinations 1 number of destinations in the PERR element received value Received number of destinations less the number of received destinations for which the transmitter of the PERR element is not the next hop Flags #1 As received Destination Address #1 MAC address of unreachable destination #1, as received HWMP Sequence Number #1 If Reason Code #1 = â€œMESH-PATH-ERROR-NO-FORWARDING- INFORMATIONâ€ and received value = 0, then HWMP SN for Destination Address #1 from the forwarding information after the increment of 14.10.10.4.3 step b). Otherwise, as received. Destination External Address #1 As received This field is present if Bit 6 (AE subfield) of the Flags field #1 is 1; it is not present otherwise. Reason Code #1 As received ... ... 2191 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 14.10.11.4 PERR element processing 14.10.11.4.1 General Received PERR elements are subject to certain acceptance criteria. Processing and actions taken depend on the contents of the PERR element and the information available to the receiving mesh STA. See also 14.10.8. 14.10.11.4.2 Acceptance criteria The PERR element shall be accepted (and shall be processed as described in 14.10.11.4.3) if the following applies: â€” The mesh STA that receives the PERR element has forwarding information stored where â€” The destination is contained in the list of unreachable destinations of the PERR element and â€” The next hop is the transmitter of the received PERR element Otherwise, the PERR element shall be discarded. 14.10.11.4.3 Effect of receipt The following applies only to a PERR element that was accepted according to the acceptance criteria in 14.10.11.4.2: a) The mesh STA creates a list of unreachable destinations consisting of those destinations from the received PERR element for which the next hop in the local active forwarding information is the transmitter of the PERR element. Step b) through step e) are applied to the destinations in this list. b) If the Reason Code is â€œMESH-PATH-ERROR-NO-FORWARDING-INFORMATIONâ€ and the HWMP Sequence Number is 0, the receiving mesh STA increments the HWMP SN in the forwarding information of the listed unreachable destination by 1 and invalidates the forwarding information. c) If the Reason Code is â€œMESH-PATH-ERROR-NO-FORWARDING-INFORMATIONâ€ and the HWMP Sequence Number is not 0 or the Reason Code is â€œMESH-PATH-ERROR- DESTINATION-UNREACHABLEâ€ and the received HWMP SN for a listed unreachable destination is higher than the current HWMP SN in the forwarding information for that destination, the receiving mesh STA shall consider that destination unreachable and shall set the HWMP SN in the forwarding information to the HWMP SN received in the PERR element and shall invalidate the forwarding information associated with this unreachable destination. d) If the Reason Code is â€œMESH-PATH-ERROR-NO-PROXY-INFORMATION,â€ the receiving mesh STA shall consider the corresponding Destination External Address unreachable and shall invalidate the proxy information associated with this unreachable external destination (proxy mesh gate is the Destination Address of the PERR element, external MAC address is the Destination External Address of the PERR element, proxy information sequence number is the HWMP Sequence Number). e) A PERR element is propagated according to the conditions defined in 14.10.11.3 Case D â€œPERR element propagation.â€ 14.10.12 Root announcement (RANN) mechanism 14.10.12.1 General Subclause 14.10.12 describes the function, generation, and processing of the RANN element. 2192 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 14.10.12.2 Function The RANN element, described in 9.4.2.112, is used for announcing the presence of a mesh STA configured as root mesh STA using the proactive RANN mechanism. RANN elements are sent out periodically by the root mesh STA. The RANN element propagates path metric information across the network so that each mesh STA can select a best metric path to the announced root mesh STA. This mechanism allows bidirectional trees to be built, using a robust procedure based on individually addressed frames initiated by the mesh STAs. This procedure makes the root mesh STA aware of all mesh STAs. A receiving mesh STA shall propagate the RANN element as described in 14.10.12.3 Case B. 14.10.12.3 Conditions for generating and sending a RANN element A mesh STA sends out a RANN element in an HWMP Mesh Path Selection frame, as defined in 9.6.17.3, in the following cases: Case A: Original transmission All of the following conditions apply: â€” The mesh STA is configured as a root mesh STA using the proactive RANN mechanism [dot11MeshHWMProotMode = rann (4)]. â€” The root mesh STA sent its previous RANN element dot11MeshHWMPrannInterval TUs ago. The contents of a RANN element in Case A shall be as shown in Table 14-25. Table 14-25â€”Contents of a RANN element in Case A Field Value Element ID Value given in Table 9-77 for the RANN element Length 21 Flags Bit 0: set to 1 if dot11MeshGateAnnouncements is true, set to 0 otherwise. Bit 1â€“7: Reserved Hop Count 0 Element TTL Maximum number of hops allowed for this element Root Mesh STA Address MAC address of the root mesh STA HWMP Sequence Number Last used HWMP SN of the root mesh STA + 1 Interval dot11MeshHWMPrannInterval Metric Initial value of active path selection metric 2193 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Case B: Propagation All of the following conditions apply: â€” The mesh STA has valid forwarding information to a root mesh STA using the proactive RANN mechanism [dot11MeshHWMProotMode = rann (4)]. â€” The mesh STA sent its previous RANN element dot11MeshHWMPrannInterval TUs ago. â€” dot11MeshForwarding is true. â€” The Element TTL field is greater than 1â€”see 14.10.8.2. The contents of a RANN element in Case B shall be as shown in Table 14-26. Table 14-26â€”Contents of a RANN element in Case B Field Value Element ID Value given in Table 9-77 for the RANN element Length As received Flags As received Hop Count As received + 1 Element TTL As received â€“ 1 Root Mesh STA Address As received HWMP Sequence Number As received Interval As received Metric As received own link metric toward the transmitting mesh STA 14.10.12.4 RANN element reception 14.10.12.4.1 General Received RANN elements are subject to certain acceptance criteria. Processing and actions taken depend on the content of the RANN element and the forwarding information maintained by the receiving mesh STA. See also 14.10.8. 14.10.12.4.2 Acceptance criteria The RANN element shall not be accepted (and shall not be processed as described in 14.10.12.4.3) if any of the following is true: â€” The HWMP Sequence Number < previous HWMP SN from this originating root mesh STA â€” (The HWMP Sequence Number = previous HWMP SN) AND (updated path metric is worse than previous path metric) Otherwise, the RANN element shall be accepted. 2194 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 14.10.12.4.3 Effect of receipt The following applies only to a RANN element that was accepted according to the acceptance criteria in 14.10.12.4.2: a) The receiving mesh STA shall set dot11MeshHWMPrannInterval to the value of the Interval field of the received RANN element. b) The receiving mesh STA may initiate a PREQ element / PREP element exchange with the root mesh STA to set up or update a path to the root mesh STA. See 14.10.9.3 Case D. c) The receiving mesh STA may record the Root Mesh STA Address, together with the HWMP Sequence Number, Hop Count, and Metric in order to assist in executing 14.10.9.3 Case D. The receiving mesh STA shall transmit a RANN element if the conditions defined in 14.10.12.3 Case B are true. 14.10.13 Considerations for support of STAs without mesh functionality The verification, by the mesh STA collocated with the AP, of disjunct MAC addresses between a non-AP STA without mesh functionality and mesh STAs during authentication/association of the non-AP STA without mesh functionality (see 11.3.6) may be done by issuing a PREQ element for the MAC address of the non-AP STA without mesh functionality by the mesh STA collocated with the AP. The TO (Target Only) subfield of the Per Target Flags field of the PREQ element shall be set to 1. The MAC address of the non-AP STA already exists in the MBSS if the AP with mesh functionality receives a PREP element for the MAC address of the non-AP STA and it can be derived from the PREP element that the requested MAC address is originated from a mesh STA. (The AE subfield of the Flags field of the PREP element is set to 0; see 9.4.2.114.) 14.11 Interworking with the DS 14.11.1 Overview of interworking between a mesh BSS and a DS A mesh STA that has access to a DS is called a mesh gate. Mesh STAs in an MBSS access the DS via the mesh gate. An MBSS functions like an IEEE 802 LAN segment that is compatible with IEEE Std 802.1D. The MBSS appears as a single access domain. An MBSS may contain two or more mesh gates. When multiple mesh gates in an MBSS have access to the same DS, the MBSS has more than one â€œportâ€ (in the sense of IEEE Std 802.1D-2004, for example) through which it accesses the DS. Accordingly, broadcast loops may occur. Therefore, mesh gates should implement a loop preventing protocol in the DS. NOTEâ€”In the DS a typical implementation uses the Rapid Spanning Tree Protocol (RSTP) as specified in IEEE Std 802.1D-2004. With RSTP the resulting active DS topology forms a tree. Then, even if multiple mesh gates connect with the same DS, the MBSS only accesses the DS through a single mesh gate. When dot11MeshGateAnnouncements is true, the mesh gate announces its presence to other mesh STAs in the MBSS. The mesh gate uses the gate announcement protocol (see 14.11.2) or alternatively one of the HWMP proactive path selection methods with the Gate Announcement field equal to 1: â€” The proactive PREQ mechanism (see 14.10.4.2), with the Gate Announcement field equal to 1 (see 14.10.9.3) â€” The proactive RANN mechanism (see 14.10.4.3), with the Gate Announcement field equal to 1 (see 14.10.12.3) 2195 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications When the mesh gate uses one of the HWMP proactive path selection methods, the gate announcement protocol is not used. A mesh STA discovers the presence of a mesh gate with access to the external network by receiving GANN elements (or PREQ element and RANN element with the Gate Announcement field equal to 1 if using such mechanisms). Mesh STAs propagate these elements to neighbor mesh STAs in order to propagate the information throughout the MBSS. NOTEâ€”The decision to set dot11MeshGateAnnouncements to true is beyond the scope of the standard. In general, the mesh gate announces that it has access to a broader network beyond the MBSS, using gate announcement protocol or HWMP proactive path selection methods with the Gate Announcement field equal to 1. One example of this configuration is that the mesh gate has access to a portal through the DS. When a mesh gate has access to IEEE 802 STAs outside the mesh BSS (a mesh STA collocated with an AP, another mesh STA that belongs to another MBSS, etc.), the mesh gate acts as an intermediary for the IEEE 802 STAs outside the MBSS so that the forwarding information inside the MBSS only contains addresses that belong to the MBSS. The mesh gate acting as an intermediary for external STAs is termed proxy mesh gate. When the end station of an IEEE 802 communication is an external STA, mesh STAs handle addresses of the end-to-end IEEE 802 communication as depicted in Figure 9-64. Proxy mesh gate operation is described in 14.11.4. 14.11.2 Gate announcement (GANN) 14.11.2.1 General Subclause 14.11.2 describes the function, generation, and processing of the GANN element. 14.11.2.2 Function The GANN element, described in 9.4.2.111, is used to announce the presence of a mesh gate with dot11MeshGateAnnouncements equal to true in the mesh BSS. Gate announcements allow mesh STAs to discover such a mesh gate and, if necessary, to build a path toward it. 14.11.2.3 Conditions for generating and sending a GANN element A mesh STA shall send a GANN element in a Gate Announcement frame, as defined in 9.6.17.4, in the following cases: Case A: Original transmission The mesh STA is a mesh gate not sending PREQ element or RANN element with the Gate Announcement field equal to 1 and dot11MeshGateAnnouncements is true. The mesh STA shall transmit the Gate Announcement frame at every dot11MeshGateAnnouncementInterval. The content of a GANN element in Case A shall be as shown in Table 14-27. The mesh gate shall assign the GANN Sequence Number from a single modulo 232 counter, starting at 0 and incrementing by 1 for each GANN element transmission. 2196 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 14-27â€”Contents of a GANN element in Case A Field Value Element ID Value given in Table 9-77 for the GANN element Length 15 Flags Reserved Hop Count 0 Element TTL Maximum number of hops allowed for the gate announcement Mesh Gate Address Mesh STA MAC address GANN Sequence Number Previous GANN sequence number + 1 Interval dot11MeshGateAnnouncementInterval Case B: Propagation All of the following conditions are met: â€” The mesh STA has received and accepted a gate announcement. â€” The decremented Element TTL of the gate announcement is greater than or equal to 1. â€” dot11MeshForwarding is true. The content of a GANN element in Case B shall be as shown in Table 14-28. Table 14-28â€”Contents of a GANN element in Case B Field Value Element ID Value given in Table 9-77 for the GANN element Length 15 Flags As received Hop Count As received + 1 Element TTL As received â€“ 1 Mesh Gate Address As received GANN Sequence Number As received Interval As received 2197 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 14.11.2.4 GANN element processing 14.11.2.4.1 General A received gate announcement is subject to certain acceptance criteria. Processing depends on the contents of the gate announcement and the information available at the receiving mesh STA. 14.11.2.4.2 Acceptance criteria The GANN element shall not be accepted (and shall not be processed as described in 14.11.2.4.3) if the GANN Sequence Number of the gate announcement is equal or lower than the GANN Sequence Number of the most recently accepted gate announcement with the same Mesh Gate Address. 14.11.2.4.3 Effect of receipt The following applies only to a GANN element that was accepted according to the acceptance criteria in 14.11.2.4.2. The receiving mesh STA shall transmit a gate announcement as described in 14.11.2.3, Case B. The Mesh Gate Address field of the GANN contains the address of the mesh gate, and may be stored for the purpose of determining paths to the mesh gates. Paths to mesh gates allow mesh STAs to forward MSDUs to addresses for which no path could be determined (see 10.35.8). 14.11.3 Data forwarding at proxy mesh gates 14.11.3.1 General Forwarding of MSDUs from the DS into the MBSS by a proxy mesh gate follows the procedures given in 10.35.2. Forwarding of MSDUs from the MBSS into the DS by a proxy mesh gate follows the procedures that apply for the specific collocated network. A proxy mesh gate learns the addresses of the other proxy mesh gates in the MBSS and of external addresses proxied by them through the receipt of path selection messages and messages carrying proxy information (for example, see 9.4.2.116). 14.11.3.2 Forwarding of MSDUs from the MBSS to the DS On receipt of an individually addressed mesh Data frame from the MBSS with Address Extension Mode equal to â€œAddress5&6â€ (see Table 9-20), a proxy mesh gate shall perform the following: â€” If Address 5 is a known destination MAC address in the proxy information (external address) and proxied by the proxy mesh gate, the proxy mesh gate forwards the MSDU to the external address through the DS. â€” If Address 5 is a known destination MAC address in the proxy information (external address) and proxied by a different proxy mesh gate, the MSDU is forwarded through the MBSS to the proxy mesh gate that proxies the external address. The MSDU is sent into the MBSS according to the procedures in 10.35.3.1 as an individually addressed mesh Data frame with Address 3 set to the MAC address of the proxy mesh gate of the proxy information proxying Address 5, Address 4 set to the MAC address of this proxy mesh gate, and Address 5 and Address 6 kept unchanged. â€” If Address 5 is unknown to the proxy mesh gate, the mesh gate forwards the MSDU to the DS. The mesh gate may send an error notification to the mesh source of the MSDU. In HWMP, this is done by sending a PERR element as described in 14.10.11.3 Case C. On receipt of group addressed mesh Data frame from the MBSS with Address Extension Mode equal to â€œAddress4â€ (see Table 9-20), a proxy mesh gate shall forward the MSDU to the DS using a group addressed frame. 2198 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 14.11.3.3 Forwarding of MSDUs from the DS to the MBSS On receipt of an individually addressed MSDU from the DS, a proxy mesh gate shall perform the following depending on the possible destination: a) If the destination of the MSDU is a mesh STA address that the mesh gate knows to be inside the MBSS, the mesh gate forwards the MSDU according to the procedures for frame addressing and data forwarding at source mesh STAs in an MBSS (10.35.3.1). The MSDU shall be transmitted using a frame with the four-address MAC header format (with the Address Extension Mode subfield in the Mesh Control field set to â€œAddress5&6â€ (see Table 9-20)), where the Mesh Address Extension subfield in the Mesh Control field carries the addresses of the end stations, as specified in row â€œMesh Data (proxied, individually addressed)â€ of Table 9-42. The address fields are set as follows: â€” Address 1: The address of the next-hop mesh STA (toward the destination mesh STA according to the forwarding informationâ€”see 10.35.2) â€” Address 2: The address of the proxy mesh gate â€” Address 3: The address of the destination mesh STA â€” Address 4: The address of the proxy mesh gate â€” Address 5: The address of the destination end mesh STA that is the same as Address 3 â€” Address 6: The address of the source end mesh STA that is the source address of the MSDU received from the DS b) If the destination of the MSDU is an external address that is proxied by another proxy mesh gate in the MBSS, the mesh gate forwards the MSDU according to the procedures for frame addressing and data forwarding at source mesh STAs in an MBSS (10.35.3.1). The MSDU shall be transmitted using a frame with the four-address MAC header format [with the Address Extension Mode subfield in the Mesh Control field set to â€œAddress5&6â€ (see Table 9-20)], where the Mesh Address Exten- sion subfield in the Mesh Control field carries the addresses of the end stations, as specified in row â€œMesh Data (proxied, individually addressed)â€ of Table 9-42. The address fields are set as follows: â€” Address 1: The address of the next-hop mesh STA (toward the proxy mesh gate of the destination of the MSDU as derived from the proxy information (see 14.11.4.2) and according to the forwarding informationâ€”10.35.2) â€” Address 2: The address of this proxy mesh gate â€” Address 3: The address of the proxy mesh gate of the destination of the MSDU as derived from the proxy information (see 14.11.4.2) â€” Address 4: The address of this proxy mesh gate â€” Address 5: The address of the destination end mesh STA that is the destination address of the MSDU received from the DS â€” Address 6: The address of the source end mesh STA that is the source address of the MSDU received from the DS c) If the MSDU has a destination address that is unknown to the mesh gate, the mesh gate forwards the MSDU to other known mesh gates in the MBSS as an individually addressed frame according to the procedures for frame addressing and data forwarding of individually addressed frames at source mesh STAs in an MBSS (10.35.3.1). The MSDU shall be transmitted using a frame with the four- address MAC header format [with the Address Extension Mode subfield in the Mesh Control field set to â€œAddress5&6â€ (see Table 9-20)], where the Mesh Address Extension subfield in the Mesh Control field carries the addresses of the end stations, as specified in row â€œMesh Data (proxied, indi- vidually addressed)â€ of Table 9-42. The address fields are set as follows: â€” Address 1: The address of the next-hop mesh STA (toward the other known mesh gate in the MBSS according to the forwarding informationâ€”see 10.35.2) â€” Address 2: The address of this proxy mesh gate â€” Address 3: The address of the other known mesh gate in the MBSS â€” Address 4: The address of this proxy mesh gate 2199 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” Address 5: The address of the destination end mesh STA that is the unknown destination address of the MSDU received from the DS â€” Address 6: The address of the source end mesh STA that is the source address of the MSDU received from the DS Note that the procedure to determine that an address is unknown depends on the active path selection protocol. It might require an attempt to establish a path to the destination (see 14.8). On receipt of a group addressed MSDU from the DS, the mesh gate forwards the MSDU according to the procedures for frame addressing and data forwarding of group addressed frames at source mesh STAs in an MBSS (10.35.4.1). The MSDU shall be transmitted using a frame with the three-address MAC header format [with the Address Extension Mode subfield in the Mesh Control field set to â€œAddress4â€ (see Table 9- 20)], where the Mesh Address Extension subfield in the Mesh Control field carries the address of the source end stations, as specified in row â€œMesh Data (proxied, group addressed)â€ of Table 9-42. The address fields are set as follows: â€” Address 1: The group address â€” Address 2: The address of the proxy mesh gate â€” Address 3: The address of the proxy mesh gate â€” Address 4: The address of the source external STA 14.11.4 Proxy information and proxy update 14.11.4.1 General Forwarding information of mesh STAs only contains addresses of mesh STAs that belong to the MBSS. However, the end station of the IEEE 802 communication may be an IEEE 802 station outside the MBSS, and such station is called external STA. Examples of external STAs are as follows: â€” STAs that are associated with an AP that is collocated with a mesh STA â€” STAs that are behind a mesh gate Mesh STAs forward MSDUs to external STAs by treating MAC addresses of the external STAs as external addresses. The mesh STAs that are the destination mesh STAs of the messages destined to external STAs are called proxy mesh gates, and their MAC addresses are called proxy addresses. NOTEâ€”External STAs are reached using mesh services solely, i.e., they are not part of an MBSS. The mechanism by which the proxy mesh gate bridges the MBSS and the external STAs is beyond the scope of the standard. However, the standard describes the method by which mesh STAs use the external addresses that are discovered and bridged by the proxy mesh gate. 14.11.4.2 Proxy information Proxy mesh gates and source mesh STAs of MSDUs destined to external STAs maintain proxy information. Proxy information contains the external address, the corresponding proxy address, the sequence number of the proxy information, and the corresponding proxy information lifetime. Mesh STAs can learn the addresses of proxy mesh gates and of the external stations proxied by these proxy mesh gates through the receipt of proxy update messages or path selection messages carrying proxy information. Particularly, proxy information is updated in the following circumstances: â€” A mesh STA receives and processes a proxy update (see 14.11.4.3) â€” A mesh STA receives and processes an element of the active path selection protocol containing proxy information. In HWMP, these are PREQ elements (see 14.10.9.4.3), PREP elements (see 14.10.10.4.3), and PERR elements (see 14.10.11.4.3) Additionally, proxy mesh gates may also proactively maintain proxy information on external STAs. 2200 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications When the proxy information lifetime is specified, a mesh STA shall maintain the proxy information as valid information until the lifetime expires. Details of the lifetime are described in 14.11.4.3.4. The sequence number of the proxy information and the proxy mesh gate address define a chronological order of the proxy information of an external STA at a specific proxy mesh gate. When the proxy information is created at the proxy mesh gate, the proxy sequence number is initialized to an arbitrary value. The proxy information sequence number in the proxy information at the proxy mesh gate is incremented by 1 before the transmission of the proxy information to another mesh station. The proxy information sequence number shall be incremented if the proxy information is invalidated. If proxy information is transmitted in HWMP elements (PREQ, PREP, and PERR), the proxy information sequence number is set to the HWMP SN of the HWMP element containing this proxy information. Comparison of the proxy information sequence numbers is performed using a circular modulo 232 comparison. Valid proxy information is used to determine and set Address 5 and Address 6 in individually addressed mesh Data frames, or Address 4 in group addressed mesh Data frames. 14.11.4.3 Proxy update (PXU) 14.11.4.3.1 General Subclause 14.11.4.3 describes the function, generation, and processing of the PXU element. 14.11.4.3.2 Function A mesh STA generates a PXU element to inform a destination mesh STA about proxy information of external addresses that are reachable through the proxy mesh gate specified in the PXU element. NOTEâ€”Typically, a proxy mesh gate generates and sends a PXU element to another proxy mesh gate in the MBSS or a mesh STA that originates traffic to the external stations proxied by the proxy mesh gate. However, the standard also allows other usage of the PXU element. The PXU element is transmitted in a Proxy Update frame (an individually addressed frame). The Proxy Update frame may contain multiple PXU elements when needed (for instance, the proxy mesh gate has a large number of proxy information). 14.11.4.3.3 Conditions for generating and sending a PXU element A proxy mesh gate may transmit a PXU when it adds, updates, or deletes an external address to (or from) its proxy information. A proxy mesh gate may also transmit a PXU at periodic intervals. A mesh STA that holds proxy information of a proxy mesh gate in the MBSS may also transmit a PXU. A mesh STA may retransmit the same PXU element repeatedly until the mesh STA receives a PXUC element from the destination mesh STA. See 14.11.4.4. The content of a PXU element shall be as shown in Table 14-29. The proxy mesh gate shall assign the PXU ID from a single modulo 256 counter, starting at 0 and incrementing by 1 for each PXU element. 2201 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 14-29â€”Contents of a PXU element Field Value/description Element ID Value given in Table 9-77 for the PXU element Length 8 + length of N Proxy Information fields PXU ID Previous PXU ID + 1 PXU Originator MAC MAC address of the originator of the PXU Address Number of Proxy Information Number of proxy information reported to the destination mesh STA (N â‰¥ 1). (N) Per Proxy Flags Bit 0: 0: add proxy information; 1: delete proxy information Information Bit 1: 0: Proxy MAC Address field present; 1: Proxy MAC Address = PXU Originator MAC Address, Proxy MAC Address field not present Bit 2: 0: Proxy Information Lifetime field not present; 1: Proxy Information Lifetime field present. If Bit 0 is 1, Bit 1 shall be set to 0. Bit 3â€“7: Reserved External MAC address of the STA proxied by the proxy mesh gate. MAC Address Proxy Proxy information sequence number of the proxy information after being Information incremented. See 14.11.4.2. Sequence Number Proxy MAC MAC address of the proxy mesh gate. This field is present if Bit 1 of the Address Flags field is 0; it is not present otherwise. Proxy The proxy information lifetime of this proxy information as taken from the Information proxy information of the originator of the PXU. Lifetime 14.11.4.3.4 Effect of receipt of a PXU element A mesh STA that receives the PXU element shall update its proxy information with the list of proxy information reported in the PXU under the following conditions: â€” Proxy information for the external MAC address and the proxy mesh gate reported in the Proxy Information field of the PXU does not exist at the mesh STA. â€” Proxy information for the external MAC address and the proxy mesh gate reported in the Proxy Information field of the PXU does exist at the mesh STA and the value of the Proxy Information Sequence Number subfield in the received PXU is larger than the value of the proxy information sequence number in the proxy information at the mesh STA. When multiple PXU elements are contained in the received Proxy Update frame, the recipient mesh STA shall process all of the PXU elements in the frame. The MAC address of the proxy mesh gate is taken from the Proxy MAC Address subfield in the Proxy Information field when bit 1 in the Flags subfield is equal to 0, and from the PXU Originator MAC Address field in the PXU element when bit 1 in the Flags subfield is equal to 1. The MAC address of the external STA is taken from the External MAC Address subfield of the corresponding Proxy Information field in the received PXU element. 2202 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The sequence number of the proxy information is taken from the Proxy Information Sequence Number subfield of the corresponding Proxy Information field in the received PXU element. If the Proxy Information Lifetime subfield is present (the Lifetime subfield in the Flags subfield is 1) and there is already proxy information stored for the proxy mesh gate and external address reported in the proxy information of the PXU element, the mesh STA shall set the proxy lifetime to the larger one of the proxy lifetime reported by the PXU and the stored proxy information. If the Proxy Information Lifetime subfield is present (bit 2 of the Flags subfield is 1) and there is proxy information stored for the proxy mesh gate and external address reported in the proxy information of the PXU element, the mesh STA shall set the proxy information lifetime to the value in the Proxy Information Lifetime subfield. If the Proxy Information Lifetime subfield is not present, the lifetime of the proxy information is the same as the lifetime of the path to the proxy address. Alternatively, the lifetime of the proxy information may be set to a value representing infinity. The destination mesh STA that received the PXU shall send a PXUC element to the originator mesh STA of the PXU as described in 14.11.4.4.3. 14.11.4.4 Proxy update confirmation (PXUC) 14.11.4.4.1 General Subclause 14.11.4.4 describes the function, generation, and processing of the PXUC element. 14.11.4.4.2 Function A PXUC element is generated by the destination mesh STA of a PXU to inform the sender of the PXU that the PXU has been properly received. The PXUC element is transmitted in a Proxy Update Confirmation frame (an individually addressed frame). The Proxy Update Confirmation frame may contain multiple PXUC elements in order to confirm the reception of multiple PXU elements to the destination of the Proxy Update Confirmation frame. 14.11.4.4.3 Conditions for generating and sending a PXUC element The destination mesh STA of a Proxy Update frame containing a PXU element shall send a PXUC element to the originator mesh STA of the PXU element. The content of a PXUC element shall be as shown in Table 14-30. Table 14-30â€”Contents of a PXUC element Field Value/description Element ID Value given in Table 9-77 for the PXUC element Length 7 PXU ID PXU ID of the PXU that is being confirmed Destination mesh STA MAC address of the originator of the PXUC Address 2203 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 14.11.4.4.4 Effect of receipt of PXUC element If a mesh STA receives a PXUC element in a PXUC frame in response to a PXU element it originated, the mesh STA shall no longer send any PXUs with the same PXU ID as given in the received PXUC element. 14.11.5 Mesh STA collocation A mesh STA collocated with another STA shall use a MAC address that is different from the one used by the collocated STA. This precludes ambiguities relating to the presence of the Mesh Control field in the Frame Body (see 9.2.4.7), GTK use (see 12.6.1.1.10), and proxy information (see 14.11.4.2). Path selection with collocated mesh STAs using HWMP is described in 14.10.5. 14.12 Intra-mesh congestion control 14.12.1 General Intra-mesh congestion control is based on the following three main mechanisms: a) Local congestion monitoring and congestion detection b) Congestion control signaling c) Local rate control A mesh STA shall activate a congestion control protocol specified by dot11MeshActiveCongestionControlMode. At any given time, there is only one congestion control protocol active in a particular MBSS, signaled in the Congestion Control Mode Identifier field of the Mesh Configuration element. This standard specifies the congestion control signaling protocol that shall be available in any MBSS with an activated congestion control. NOTEâ€”This standard allows for inclusion of more advanced or alternative congestion control schemes through the Congestion Control Mode Identifier in the Mesh Configuration element. 14.12.2 Congestion control signaling protocol When dot11MeshActiveCongestionControlMode is congestionControlSignaling (1), the mesh STA activates the congestion control signaling protocol. The congestion control signaling protocol specifies the signaling messages used with intra-mesh congestion control. Specific algorithms for local congestion monitoring and congestion detection are beyond the scope of the congestion control signaling protocol. The congestion control signaling protocol is triggered after congestion is detected at a mesh STA. A mesh STA that detects congestion, and the traffic destination causing this congestion, may transmit a Congestion Control Notification frame to the mesh STAs of the traffic source and other neighboring mesh STAs. The frame contains one or more Congestion Notification elements, each of which specifies the traffic destination causing the congestion and the expected duration of the congestion per AC per mesh destination as estimated by the congested mesh STA. Upon receipt of a Congestion Notification frame a mesh STA may stop forwarding, or reduce the rate of forwarding, traffic to the destinations listed in the Congestion Notification elements via the mesh STA reporting congestion for the duration specified in the Congestion Notification element. It may also send its own Congestion Control Notification frame to mesh STAs that are the source of the reported congestion, and other neighboring mesh STAs. Any time difference between receipt of the original Congestion Control Notification frame and the transmission of this new Congestion Control Notification frame should be reflected in the duration indicated in the new congestion control notification in such a way that any timers 2204 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications set by mesh STAs in response to the first report of congestion for a given destination all expire at the same time. If the Destination MAC Address field in a received Congestion Notification element is the group address, it should be interpreted to mean that communication with the transmitter of this frame should be stopped, or reduced, for the duration specified in the Congestion Notification element. This event should not result in the transmission of a Congestion Notification element with a Destination MAC Address field set to the group address to any neighbor mesh STAs. When the duration of a traffic congestion report has expired, a mesh STA should resume forwarding traffic to the destinations that were listed in the traffic congestion report via the mesh STA that reported congestion. NOTE 1â€”Local policies/mechanisms implemented in a mesh STA might be required to achieve timely transmission of the congestion control signaling messages and to avoid transmission of stale messages that might reduce network efficiency. NOTE 2â€”A mesh STA that receives a Congestion Control Notification frame might choose to adjust its frame rate, defined by the number of transmitted frames per a unit of time, to the sender of the Congestion Control Notification frame in the identified congested AC(s) for the duration specified in the Congestion Notification element. The reduction of the frame rate to a congested mesh STA avoids waste of the mesh resources for transmission of packets that with high probability will not be handled/forwarded by the congested mesh STA. 14.13 Synchronization and beaconing in MBSSs 14.13.1 TSF for MBSSs A mesh STA shall initialize and update its TSF timer according to the MBSSâ€™s active synchronization method. Each mesh STA shall maintain a TSF timer as described in 11.1.3.1, and comply with the TSF timer accuracy as described in 11.1.3.9. 14.13.2 Extensible synchronization framework 14.13.2.1 General This standard introduces an extensible framework to enable the implementation of multiple synchronization methods for mesh STAs. Within the extensible synchronization framework, the neighbor offset synchronization method is defined as the default mandatory synchronization method in order to enable minimal synchronization capabilities and interoperability between mesh STAs that use MCCA, MBCA, or operate in light or deep sleep mode. The framework allows the integration of other synchronization methods into MBSSs. A vendor may implement any synchronization method using this framework to meet special application needs. Although a mesh STA may include multiple implementations of synchronization methods, only one synchronization method at a time shall be used by a mesh STA. All mesh STAs in an MBSS use the same synchronization method; see 14.2.7 item a). The MBSSâ€™s active synchronization method is controlled by the SME and given to the MLME by dot11MeshActiveSynchronizationMethod. A mesh STA shall announce the MBSSâ€™s active synchronization method using the Synchronization Method Identifier field in the Mesh Configuration element in their Beacon and Probe Response frames. 14.13.2.2 Neighbor offset synchronization method 14.13.2.2.1 General When dot11MeshActiveSynchronizationMethod is neighborOffsetSynchronization (1), the mesh STA shall use the neighbor offset synchronization method as its active synchronization method, and maintain the timing offset value between its own TSF timer and the TSF timer of each neighbor STA with which it 2205 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications synchronizes. The mesh STA shall set the Synchronization Method Identifier field in the Mesh Configuration element to 1. The mesh STA shall maintain synchronization with all of its neighbor peer mesh STAs up to dot11MeshNbrOffsetMaxNeighbor mesh STAs. The mesh STA should maintain synchronization with additional neighbor mesh STAs that are in the same MBSS up to a total of dot11MeshNbrOffsetMaxNeighbor mesh STAs and also, additional neighbor mesh STAs that are outside of the MBSS up to a total of dot11MeshNbrOffsetMaxNeighbor mesh STAs. Upon receipt of an MLME-MESHNEIGHBOROFFSETSYNCSTART.request primitive, the MLME shall start synchronization using the neighbor offset synchronization method with the specified peer STA. Upon receipt of an MLME-MESHNEIGHBOROFFSETSYNCSTOP.request primitive, the MLME shall stop synchronization using the neighbor offset synchronization method with the specified peer STA. A mesh STA that utilizes the neighbor offset synchronization method may start its TSF timer independently of other mesh STAs. The mesh STA shall calculate the timing offset value with respect to the neighbor STA with which it maintains synchronization, as described in 14.13.2.2.2. The mesh STA shall adjust its TSF timer based on time stamps received in Beacon or Probe Response frames from neighbor STAs with which it maintains synchronization, as described in 14.13.2.2.3. When the mesh STA alternates awake state and doze state, it might not always listen to the Beacon frames of a neighbor mesh STA with which it maintains synchronization. However, it shall comply with the clock drift compensation procedures and TSF jitter allowance as described in 14.13.2.2.3. See S.3.6 for more guidelines. 14.13.2.2.2 Timing offset calculation When dot11MeshActiveSynchronizationMethod is neighborOffsetSynchronization (1), the mesh STA shall calculate the timing offset value with respect to the neighbor STA with which it maintains synchronization. The calculation of the timing offset value is based on time stamps from the received Beacon and Probe Response frames as follows: Toffset = Tt â€“ Tr where Toffset is the timing offset value Tt is the value in the Timestamp field in the received frame Tr is the frame reception time measured in the TSF timer of the mesh STA The offset value is represented as a signed integer. The unit of the offset value is Âµs. The mesh STA shall keep the Toffset value calculated from the latest Beacon or Probe Response frame received from each neighbor STA with which it maintains synchronization. A mesh STA may translate the time measured in the TSF of the neighbor STA into the time base of its own TSF as follows: Tself = Tneighbor â€“ Toffset where Tself is the translated time in its own TSF Tneighbor is the time measured in the TSF timer of the neighbor STA 2206 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Upon receipt of an MLME-MESHNEIGHBOROFFSETCALCULATE.request primitive, the MLME shall receive a Beacon or Probe Response frame from the specified neighbor STA, calculate the Toffset from the received frame, and report the calculated Toffset to the SME by responding with an MLME- MESHNEIGHBOROFFSETCALCULATE.confirm primitive. Toffset is used to provide the timing reference of neighbor STAs. 14.13.2.2.3 Clock drift adjustment When dot11MeshActiveSynchronizationMethod is neighborOffsetSynchronization (1), the mesh STA shall examine the reception time of the Beacon frames from neighbor STAs with which it maintains synchronization and adjust its TSF timer to compensate the relative timing error among neighbor mesh STAs caused by the clock drift. The mesh STA adjusts its TSF so that its TSF counting is aligned to the most delayed neighbor STA. When the mesh STA receives a Beacon frame or a Probe Response frame from one of the neighbor STAs with which it maintains synchronization, the mesh STA shall perform the following measurement procedure: a) The mesh STA checks if the transmitter of the Beacon frame or Probe Response frame is in the process of the TBTT adjustment (see 14.13.4.4.3). If the received frame contains the Mesh Configuration element and the TBTT Adjusting subfield in the Mesh Configuration field is 1, the mesh STA shall invalidate the Toffset value for this neighbor STA and shall not perform the following steps. b) The mesh STA checks if it has a valid Toffset value obtained from the previous Beacon or Probe Response frame reception from the transmitter of the received frame. If it does not have the valid Toffset value, it shall not perform the following steps. c) The mesh STA calculates the clock drift amount TClockDrift by comparing the Toffset,p,the offset value obtained previously for this neighbor STA, and the Toffset,c, the offset value obtained from the current frame reception. TClockDrift = Toffset, p â€“ Toffset, c where TClockDrift is the clock drift amount in Âµs represented as a signed integer. d) The mesh STA shall compare the TClockDrift value with the TMaxClockDrift, the largest TClockDrift value obtained from other neighbor STA within this beacon period. If the TClockDrift value for this neighbor STA is greater than the TMaxClockDrift value, the mesh STA replaces the TMaxClockDrift value with the TClockDrift value, in order to determine the largest TClockDrift value among neighbor STAs. When the previous TClockDrift values have been stable for a neighbor mesh STA, the mesh STA may substitute the previous TClockDrift value for the TClockDrift value in the measurement procedure and process the step d), at the time of a TBTT of the neighbor STA, without receiving a Beacon frame. Before the mesh STA transmits a Beacon frame, it shall perform the following adjustment procedure: â€” The mesh STA checks if the current TMaxClockDrift value is greater than zero. If the TMaxClockDrift value is greater than zero, it shall continue the following steps. Otherwise, it shall initialize the TMaxClockDrift with zero and shall not perform the following step. â€” If the TMaxClockDrift value is smaller than 0.04% of its beacon interval, the mesh STA shall adjust its TSF timer so that the next TBTT will be delayed for the duration of the TMaxClockDrift and initialize the TMaxClockDrift value with zero. Otherwise, it shall adjust its TSF timer so that the next TBTT will be delayed for the duration of 0.04% of its beacon interval and subtract the value of 0.04% of its beacon interval from the TMaxClockDrift. The mesh STA may adjust its TSF timer only to slow the counting. The mesh STA may adjust its TSF timer within the range of 0.04% in a beacon period. 2207 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications When the delay amount at each beacon period is not stable, the mesh STA should frequently listen to neighbor STAsâ€™ Beacon frames. An implementation might reduce TSF timer jitter caused by the adjustment procedure by making additional adjustments to the TMaxClockDrift , as long as the mesh STAâ€™s TSF count is aligned to the most delayed neighbor mesh STA. The means of making these additional adjustments is beyond the scope of this standard. NOTEâ€”This clock drift compensation procedure does not intend to maintain a strict synchronization. It aims to stop TBTT drifting away among neighbor mesh STAs, allowing some jitter of TSF timer. 14.13.3 Beaconing 14.13.3.1 Beacon generation in MBSSs A mesh STA transmits Beacon frames that are specific to an MBSS. Beacon frames for MBSS, infrastructure BSS, or IBSS are differentiated by the Capability Information field in the Beacon frame as specified in 9.4.1.4. A mesh STA that collocates with an AP generates Beacon frames for the MBSS independently of the AP. The mesh STA shall define a series of TBTTs exactly dot11BeaconPeriod TUs apart. Time zero is defined to be a TBTT with the Beacon frame containing a DTIM. At each TBTT, the mesh STA shall schedule a Beacon frame as the next frame for transmission according to the medium access rules specified in Clause 10. NOTEâ€”To achieve this requirement, the mesh STA suspends any pending transmissions until the beacon has been transmitted. In the case of a DTIM, the mesh STA also suspends any pending individually addressed transmissions until any pending group addressed transmissions have been performed (see 14.14.5). The beacon period is included in Beacon and Probe Response frames. The mesh STA shall start beaconing upon the receipt of the MLME-START.request primitive. 14.13.3.2 Beacon reception for mesh STA A mesh STA shall use information from the Timestamp field without regard to the BSSID or Mesh ID in order to obtain information necessary for synchronization, if the mesh STA maintains synchronization with the transmitter of the Beacon frame. A mesh STA may use information from the Beacon Interval field and the Beacon Timing element without regard for the Mesh ID in order to obtain information necessary for MBCA, if the mesh STA maintains synchronization with the transmitter of the Beacon frame and dot11MBCAActivated is true. A mesh STA may use information from the MCCAOP Advertisement Overview element and MCCAOP Advertisement element without regard for the Mesh ID in order to obtain information necessary for MCCA, if the mesh STA maintains synchronization with the transmitter of the Beacon frame and dot11MCCAActivated is true. A mesh STA in a mesh BSS shall use information that is not in the CF Parameter Set element, the Timestamp field, the Beacon Interval field, the Beacon Timing element, the MCCAOP Advertisement Overview element, or the MCCAOP Advertisement element in received Beacon frames only if the mesh STA maintains a mesh peering with the transmitter of the Beacon frame. 14.13.4 Mesh beacon collision avoidance (MBCA) 14.13.4.1 Overview Mesh STAs use the mesh beacon collision avoidance (MBCA) protocol to detect and mitigate collisions among Beacon frames transmitted by other STAs (including mesh STAs, IBSS APs, and IBSS STAs) on the same channel within the range of 2 hops. MBCA mitigates hidden node problems with respect to Beacon frames. 2208 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NOTEâ€”Beacon frames are transmitted without acknowledgment and might collide with other frames. In a mesh BSS, multiple STAs transmit Beacon frames periodically, and mesh STAs might be located out of range of each other. This implies that Beacon frames might suffer from the so-called hidden node problem and might not be received by neighbor STAs. Once Beacon frames from hidden STAs start to collide, Beacon frames keep on colliding if these hidden STAs transmit Beacon frames at the same beacon interval that is a typical operation. MBCA provides a set of rules to mitigate this problem. When dot11MBCAActivated is true, the mesh STA shall set the MBCA Enabled subfield in the Mesh Capability field of the Mesh Configuration element to 1. MBCA is composed of beacon timing advertisements, TBTT selection, and TBTT adjustment. When dot11MBCAActivated is true, the mesh STA advertises the TBTT and beacon interval of its neighbor STAs through the Beacon Timing element as described in 14.13.4.2. Upon reception of the Beacon Timing element, the mesh STA obtains the beacon timing information of its neighbor mesh STAs and uses this information for its TBTT selection and TBTT adjustment as described in 14.13.4.3 and 14.13.4.4. The mesh STA may also perform additional procedures described in 14.13.4.5 and 14.13.4.6. When dot11MBCAActivated is true, the mesh STA that alternates awake state and doze state should listen to Beacon frames from its neighbor STAs, with which it maintains synchronization, often, in order to advertise and obtain the recent TBTT information. 14.13.4.2 Beacon timing advertisement 14.13.4.2.1 General When dot11MBCAActivated is true, the mesh STA shall contain Beacon Timing element in Beacon and Probe Response frames in order to advertise its beacon timing information. The mesh STA calculates the TBTT of its neighbor STAs with which it maintains synchronization as described in 14.13.4.2.2, and composes beacon timing information as described in 14.13.4.2.3. The mesh STA collects the beacon timing information from each neighbor STA with which it maintains synchronization. The collection of the beacon timing information is termed â€œbeacon timing information set.â€ The mesh STA contains whole or part of the beacon timing information set in the Beacon Timing element as described in 14.13.4.2.5. The mesh STA also maintains the status number of the beacon timing information set and contains the status number in the Beacon Timing element as described in 14.13.4.2.4. The receiver of the Beacon Timing element uses the received beacon timing information as described in 14.13.4.2.6. 14.13.4.2.2 Calculation of neighbor STAâ€™s TBTT When a Beacon frame is received from one of its neighbor STAs with which the mesh STA maintains synchronization, the mesh STA shall calculate the TBTT of the received Beacon frame as follows: TTBTT = Tr â€“ (Tt mod (TBeaconInterval 1024)) where TTBTT is the calculated TBTT Tr is the frame reception time measured in the TSF timer of the receiving mesh STA Tt is the value in the Timestamp field in the received frame TBeaconInterval is the value in the Beacon Interval field in the received frame The TTBTT is used as described in 14.13.4.2.3. Further, the mesh STA shall calculate the time difference between the TBTT of the received Beacon frame and the time predicted from the past TBTT as follows: 2209 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications TDelta = | TTBTT, c â€“ (TTBTT, p + (TBeaconInterval NCount)) | where TDelta is the time difference TTBTT, c is the TBTT calculated from the received Beacon frame TTBTT, p is the TBTT calculated for the first time after the latest status number update (see 14.13.4.2.4) TBeaconInterval is the value in the Beacon Interval field in the received Beacon frame NCount is the number of TBTTs since TTBTT, p has been calculated TDelta is used to maintain the status number described in 14.13.4.2.4. 14.13.4.2.3 Beacon timing information The mesh STA shall keep the latest TTBTT together with the beacon interval contained in the received frame and the identifier of the neighbor STA as the beacon timing information with respect to the neighbor STA. When the elapsed time since the latest Beacon frame reception is smaller than 524 288 TU, the beacon timing information is valid. NOTEâ€”The beacon timing information provides the time reference for a series of the TBTTs of the corresponding STA. Using the beacon timing information, a mesh STA is able to predict future TBTTs by adding the reported beacon interval to the reported TBTT. The mesh STA shall collect the valid beacon timing information from each neighbor STA with which it maintains synchronization and keep the collection as the beacon timing information set. The beacon timing information set is advertised to its neighbor mesh STAs through the Beacon Timing element as described in 14.13.4.2.5. When the amount of neighbors, for which valid beacon timing information is kept, is large, the beacon timing information set may be divided into multiple tuples of beacon timing information. In such case, a tuple of beacon timing information is included in the Beacon Timing element (see 14.13.4.2.5). 14.13.4.2.4 Maintenance of the status number The mesh STA shall maintain the status number of the beacon timing information set. The status number is set to a value from a single modulo 16 counter, starting at 0 and incrementing by 1 for each transmission of a frame containing the Beacon Timing element after the mesh STA encountered any of the following events: a) It starts or stops maintaining synchronization with a neighbor STA. b) It receives a Beacon frame from a neighbor STA with which it maintains synchronization and the calculated TDelta (see 14.13.4.2.2) is larger than 255 Âµs. c) It completes the TBTT adjustment procedure described in 14.13.4.4.3. The mesh STA shall set the Status Number subfield in the Report Control field in the Beacon Timing element to the status number. The Status Number subfield in the Report Control field facilitates the detection of the changes in the beacon timing information set. 14.13.4.2.5 Transmitterâ€™s procedure When dot11MBCAActivated is true, the mesh STA shall report the TBTT and beacon interval of its neighbor STAs through the Beacon Timing element as described in this subclause. The Beacon Timing element reports on timing information of the Beacon frames that are received from the neighbor STAs with which the mesh STA maintains synchronization on the operating channel. The mesh 2210 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STA shall include the Beacon Timing element in Probe Response frames and in TBTT Adjustment Request frames. The mesh STA shall also include the Beacon Timing element in Beacon frames as specified by dot11MeshBeaconTimingReportInterval and dot11MeshBeaconTimingReportMaxNum. The Beacon Timing element is present in a Beacon frame when the DTIM Count value in the Beacon frame is zero or equal to an integer multiple of dot11MeshBeaconTimingReportInterval. The maximum number of Beacon Timing Information fields contained in a Beacon Timing element is limited to dot11MeshBeaconTimingReportMaxNum for Beacon frames, or is limited by the maximum element size for other frames. When the number of neighbors, for which valid beacon timing information is kept, is equal or smaller than the limit, the mesh STA shall include all the beacon timing information in a single Beacon Timing element, setting both Beacon Timing Element Number and More Beacon Timing Elements subfield in the Report Control field to 0. When the number of neighbors, for which valid beacon timing information is kept, exceeds the limit, the mesh STA shall divide the beacon timing information set into multiple tuples and assign each tuple with an index number starting from 0. When the beacon timing information set is divided, the mesh STA shall include the successive tuples of beacon timing information in the Beacon Timing elements. In this case, the mesh STA shall set the Beacon Timing Element Number subfield in the Report Control field to the index number of the tuple. The mesh STA shall set the More Beacon Timing Elements subfield in the Report Control field to 1 when it has one or more beacon timing information tuples with a larger index number. The mesh STA shall divide the beacon timing information set into no more than Ninfo tuples, where Ninfo = N v N max , Nv is the number of valid beacon timing information fields Nmax is the maximum number of Beacon Timing Information fields in the Beacon Timing element The mesh STA may update the combination of the tuples only when the status number described in 14.13.4.2.4 is updated. The mesh STA shall include newly updated beacon timing information (i.e., beacon timing information that causes an update of the status number as described in 14.13.4.2.4) in the tuple with a smaller index number. When the status number is updated, the mesh STA shall include the tuple of beacon timing information indexed as 0 in the Beacon Timing element in the subsequent Beacon frame. Successive tuples shall be transmitted in ascending order of the index number in the successive Beacon frames. NOTEâ€”The standard does not impose mesh STAs to advertise a fragmented beacon timing information set sequentially in its Beacon frames at all times. This implies that the mesh STA might advertise tuples with a smaller index number more frequently, which is useful to notify new beacon timing information efficiently. When the mesh STA receives a Probe Request frame containing a Beacon Timing element ID in its Request element, it shall respond with a Probe Response frame containing the Beacon Timing element. If all beacon timing information cannot be contained in a Beacon Timing element, the mesh STA shall include multiple Beacon Timing elements containing successive tuples of beacon timing information in the order of the Request element (see Table 9-34) so that all tuples are transmitted. 14.13.4.2.6 Receiverâ€™s procedure A mesh STA with dot11MBCAActivated equal to true that receives a Beacon Timing element obtains the beacon timing information of its neighbor mesh STA and uses it for its TBTT selection and TBTT adjustment as described in 14.13.4.3 and 14.13.4.4. When a mesh STA receives a Beacon frame with a Beacon Timing element that contains only a subset of the beacon timing information set, the mesh STA may transmit a Probe Request frame containing a Beacon Timing element ID in its Request element to the transmitter of the Beacon Timing element, in order to request the rest of the beacon timing information. NOTE 1â€”The Report Control field in the Beacon Timing element facilitates the detection of the missing beacon timing information. 2211 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NOTE 2â€”Once the entire beacon timing information set with a particular Status Number is obtained, the mesh STA does not need to retrieve beacon timing information as long as the Status Number remains the same. A mesh STA that receives the Beacon Timing element shall record the reported TBTT and its successive TBTTs as neighborâ€™s essential beacon reception timing if the MSB of the Neighbor STA ID field in the corresponding Beacon Timing Information field is 0. The essential beacon reception timing is used to control the transmission of frames as described in 14.13.4.5. A mesh STA can also check if its neighbor mesh STAs received its Beacon frame successfully by checking whether the Beacon Timing elements received from its neighbor mesh STAs contain beacon timing information of the mesh STA. When the Beacon Timing element is received from one of the peer mesh STAs, the mesh STA checks if the MSB of the Neighbor STA ID subfield is set to 0 and the rest of the field matches with the 7 LSBs of the AID value assigned to the mesh STA through the mesh peering establishment. When the Beacon Timing element is received from a nonpeer mesh STA, the mesh STA checks if the MSB of the Neighbor STA ID subfield is set to 1 and the rest of the field matches with the 7 LSBs of its own MAC address (taking the I/G bit as the MSB). If the matching is verified, the corresponding beacon timing information represents the correct beacon reception by the neighbor mesh STA. If a Beacon frame is received from a neighbor peer mesh STA that is either in active mode or in light sleep mode, the Beacon Timing element is present in the frame, and all beacon timing information is contained in the Beacon Timing element, the mesh STA shall verify whether the neighbor peer mesh STA received its Beacon frame. If the Beacon Timing element does not contain beacon timing information of the mesh STA or the Neighbor TBTT subfield of the corresponding beacon timing information does not reflect the recent TBTT of the mesh STA, the mesh STA considers the previous Beacon frame was not received by the neighbor peer mesh STA. 14.13.4.3 TBTT selection When dot11MBCAActivated is true, the mesh STA performs the TBTT selection described herein before it starts beaconing (see 14.2.8). The mesh STA selects its TBTTs and its beacon interval so that its Beacon frames do not collide with Beacon frames transmitted by other STAs in its 2 hop range. Before the mesh STA starts beaconing, it performs scanning and discovered neighbor STAs are reported through an MLME-SCAN.confirm primitive (see 14.2.6). Using TimeStamp, Local Time, and Beacon Period in the BSSDescriptionSet parameter provided by the MLME-SCAN.confirm primitive, the mesh STA shall obtain the TBTT and beacon interval of its neighbor STAs operating on the same channel as the mesh STA starts to operate. The mesh STA shall also collect the beacon timing information contained in the Beacon Timing elements received on the channel through Beacon Timing in the BSSDescriptionSet parameter provided by the MLME-SCAN.confirm primitive, in order to obtain the TBTT and beacon interval of STAs in 2 hop range. After obtaining this information, the mesh STA shall look for a timing of its beacon transmissions so that its Beacon frames are likely not to collide with Beacon frames transmitted by other STAs in its 2 hop range. The mesh STA shall update its TSF timer and select its beacon interval to set its TBTTs to the appropriate timing, and then it shall start beaconing using the MLME-START.request primitive. 14.13.4.4 TBTT adjustment 14.13.4.4.1 Self-determined TBTT adjustment When dot11MBCAActivated is true, the mesh STA checks if it does not transmit Beacon frames during the beacon transmissions of other STAs within its 2 hop range using the Beacon Timing element received from its neighbor peer mesh STA. 2212 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications When the mesh STA discovers that its Beacon frames repeatedly collide with the Beacon frames of a neighbor or a neighborâ€™s neighbor and its TBTT comes later than the TBTT of the colliding STA at the time of collision, it shall perform the TBTT scanning procedure described in 14.13.4.4.3. If the mesh STA finds an alternative TBTT, it shall start the TBTT adjustment procedure as described in 14.13.4.4.3. 14.13.4.4.2 Requested TBTT adjustment When a mesh STA discovers that Beacon frames from two or more neighbor STAs are colliding repeatedly or a series of TBTTs are close enough to trigger frequent beacon collisions, the mesh STA may transmit a TBTT Adjustment Request frame to the neighbor mesh STA of which the TBTT comes last at a particular collision timing in order to request this neighbor mesh STA to adjust its TBTT. The TBTT Adjustment Request frame may be transmitted only if the following conditions hold: â€” The recipient of the TBTT Adjustment Request frame is a peer mesh STA and has set the MBCA Enabled subfield in the Mesh Capability field of the Mesh Configuration element to 1. â€” The other colliding STA does not include the Mesh Configuration element in its Beacon frames or the TBTT Adjusting field in the Mesh Configuration element is 0. When dot11MBCAActivated is true, the mesh STA that receives a TBTT Adjustment Request frame shall perform the TBTT scanning procedure described in 14.13.4.4.3, and determine if it can find an appropriate alternative timing for its TBTTs. After the completion of the TBTT scanning procedure, the mesh STA that receives the TBTT Adjustment Request frame shall respond with a TBTT Adjustment Response frame containing the result of the TBTT scanning in the Status Code field. If the mesh STA finds an alternative TBTT, it shall agree with the request. If it agrees with the request, the Status Code field is set to SUCCESS in the TBTT Adjustment Response frame, and it shall complete the TBTT adjustment procedure described in 14.13.4.4.3. If it does not agree with the request, it shall indicate the reason in the Status Code field in the TBTT Adjustment Response frame. A mesh STA may set the Status Code to either SUCCESS, REFUSED_REASON_UNSPECIFIED, or CANNOT_FIND_ALTERNATIVE_TBTT in the TBTT Adjustment Response frame. 14.13.4.4.3 TBTT scanning and adjustment procedures When a mesh STA is in need of TBTT adjustment, it tries to find an alternative TBTT first. The mesh STA shall perform the TBTT scanning procedure as follows: â€” The mesh STA checks if its beacon timing information and collected neighborâ€™s beacon timing information are sufficiently new. If the mesh STA did not receive a Beacon frame from a neighbor STA with which it maintains synchronization at the latest TBTT, it shall receive a Beacon or Probe Response frame from the neighbor STA and obtain the TBTT of the neighbor STA and the beacon timing information contained in the Beacon Timing element. NOTEâ€”This is particularly important if the mesh STA is in deep sleep mode for a neighbor peer mesh STA. â€” Using the latest TBTT of its neighbor STAs and the latest beacon timing information of neighbor mesh STAs, the mesh STA shall look for an alternative TBTT that does not cause beacon collision among the STAs in its 2 hop range. If an alternative TBTT is not available, the mesh STA terminates the procedure. If an alternative TBTT is available, the mesh STA shall start the TBTT adjustment procedure as follows: â€” The mesh STA shall set the TBTT Adjusting field in the Mesh Configuration element to 1 in order to announce that the TBTT adjustment procedure is ongoing. â€” The mesh STA shall suspend its TSF timer for a period of time, no longer than half of the Group Delivery Idle Time (defined in 14.14.5) within a single beacon period, to slow its TSF. â€” The mesh STA shall adjust TBTT information of the neighbor STAs (see 14.13.4.2.3), that are to be contained in the Beacon Timing element, accordingly by subtracting the delay amount. 2213 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” When dot11MCCAActivated is true, the mesh STA shall adjust the MCCAOP reservations accordingly by modifying the MCCAOP Offset of each MCCAOP reservation. See 10.23.3.3. â€” The mesh STA shall repeat suspending its TSF timer over multiple beacon periods until its TBTT is set to the alternative TBTT. â€” Upon completion of the TBTT adjustment, the mesh STA shall update the status number as described in 14.13.4.2.4 and shall set the TBTT Adjusting field in the Mesh Configuration element to 0. NOTEâ€”A mesh STA in deep sleep mode might interpret its neighbor mesh STAâ€™s TBTT adjustment as a large TSF jitter. When a mesh STA in deep sleep mode observes a large TSF jitter and the Status Number in the Report Control field in the Beacon Timing element of the received Beacon frame (or Probe Response frame) has been updated, the mesh STA in deep sleep mode should not take this jitter as clock drift and listen to the next Beacon frame to verify if the clock drift is large. 14.13.4.5 Frame transmission across reported TBTT When dot11MBCAActivated is true, the mesh STA should not extend its transmissions across TBTT of its neighbor STAs with which it maintains synchronization. Further, the mesh STA should not extend its transmissions, other than Beacon frames, across all essential beacon reception timing (see 14.13.4.2.6) reported from its neighbor mesh STAs with which it maintains synchronization. This operation helps in reducing the hidden STA interference with beacon reception at its neighbor mesh STAs. When both dot11MBCAActivated and dot11MCCAActivated are true, the mesh STA shall not extend its transmissions across TBTT of its neighbor STAs with which it maintains synchronization. Further, the mesh STA shall not extend its transmissions, other than Beacon frames, across all beacon reception timing reported from its neighbor mesh STAs with which it maintains synchronization. After silencing for dot11MeshAverageBeaconFrameDuration Âµs from the reported neighborâ€™s TBTT, the mesh STA may start transmitting frames again. 14.13.4.6 Delayed beacon transmissions A mesh STA may occasionally delay its Beacon frame transmission from its TBTT for a pseudorandom time. This attribute is specified by dot11MeshDelayedBeaconTxInterval, dot11MeshDelayedBeaconTxMinDelay, and dot11MeshDelayedBeaconTxMaxDelay. When dot11MeshDelayedBeaconTxInterval is set to nonzero value, the mesh STA shall delay its Beacon frame transmission from TBTT, once every dot11MeshDelayedBeaconTxInterval. When the mesh STA transmits a Beacon frame with delay from its TBTT, the delay time shall be randomly selected between dot11MeshDelayedBeaconTxMinDelay and dot11MeshDelayedBeaconTxMaxDelay Âµs. NOTEâ€”Delayed beacon transmission allows mesh STAs to discover Beacon frames that are transmitted from multiple mesh STAs with TBTTs close to each other. It is recommended to set dot11MeshDelayedBeaconTxMaxDelay to a time longer than the typical duration of Beacon frames. 14.14 Power save in a mesh BSS 14.14.1 General A mesh STA may use mesh power management modes to reduce its power consumption. A mesh STA manages each of its mesh peerings with a peer-specific mesh power management mode as described in 14.14.2.2. A mesh STA may set the mesh power management mode for a mesh peering independently of the mesh power management modes for its other mesh peerings. A mesh STA also manages a nonpeer mesh power management mode as described in 14.14.2.3. When a mesh STA is in light sleep mode or in deep sleep mode for a mesh peering, the mesh STA shall maintain its mesh awake window as described in 14.14.6. 2214 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A mesh STA shall have the capability to buffer frames and to perform mesh power management mode tracking for the peer-specific mesh power management modes of its peer mesh STAs, as described in 14.14.7. A mesh STA shall use mesh peer service periods for individually addressed frame transmissions to neighbor peer mesh STAs that are either in light sleep mode or in deep sleep mode toward this mesh STA, as described in 14.14.9. A mesh STA transmits group addressed frames after the Beacon frame containing DTIM when any of its peer mesh STAs is in light sleep mode or deep sleep mode for the mesh peering with the mesh STA (see 14.14.4 and 14.14.5). These capabilities are referred to as support for power save. 14.14.2 Mesh power management modes 14.14.2.1 General The manner in which a mesh STA transitions between power states is determined by its peer-specific mesh power management modes and its nonpeer mesh power management mode. A mesh STA shall be in awake state if any of the conditions specified in 14.14.8.6 is not fulfilled. A mesh STA maintains peer-specific mesh power management modes for each of its mesh peerings as described in 14.14.2.2. A mesh STA may have a different peer-specific mesh power management mode for each mesh peering. A mesh STA maintains a nonpeer mesh power management mode for nonpeer mesh STAs that is described in 14.14.2.3. An example illustration of the use of peer specific and nonpeer mesh power management modes is shown in Figure 14-5. Mesh STA A is in Mesh STA B is active mode in light sleep towards mesh mode towards STA B mesh STA A mesh STA B mesh STA A Mesh STA B is in deep sleep Mesh STA A is in active mode mode towards nonpeer mesh towards nonpeer mesh STAs STAs Mesh STA A is in Mesh STA B is in active mode towards deep sleep mode mesh STA C towards mesh STA C Mesh STA C is in deep mesh STA C Mesh STA C is in deep sleep mode towards sleep mode towards Mesh STA C is in deep sleep mesh STA A mesh STA B mode towards nonpeer mesh STAs Figure 14-5â€”Example of mesh power management mode usage 14.14.2.2 Peer-specific mesh power management modes The peer-specific mesh power management mode specifies the activity level of the mesh STA for the corresponding mesh peering. Three mesh power management modes are defined: active mode, light sleep mode, and deep sleep mode. The peer-specific mesh power management modes are defined as follows: â€” Active mode: The mesh STA shall be in awake state all the time. â€” Light sleep mode: The mesh STA alternates between awake state and doze state, as specified in 14.14.8.4. The mesh STA shall listen to all of the Beacon frames from the corresponding peer mesh STA. 2215 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” Deep sleep mode: The mesh STA alternates between awake state and doze state, as specified in 14.14.8.5. The mesh STA may choose not to listen to the Beacon frames from the corresponding peer mesh STA. The combination of the Power Management subfield in the Frame Control field and the Mesh Power Save Level subfield in the QoS Control field contained in mesh Data frames indicates the peer-specific mesh power management mode as shown in the Table 14-31. Table 14-31â€”Peer-specific mesh power management mode definition Peer-specific mesh Power Management Mesh Power Save Level Activity level power management subfield subfield mode Highest Active mode 0 Reserved Light sleep mode 1 0 Deep sleep mode 1 1 Lowest 14.14.2.3 Nonpeer mesh power management modes The nonpeer mesh power management mode indicates the mesh power management mode of the mesh STA toward the nonpeer mesh STAs. Two nonpeer mesh power management modes are defined: active mode and deep sleep mode. The nonpeer mesh power management mode is indicated by the Power Management subfield in the Frame Control field in group addressed frames, Management frames transmitted to nonpeer neighbor STAs, and in Probe Response frames. When the Power Management subfield in the Frame Control field is set to 1, the nonpeer mesh power management mode is deep sleep mode. When the Power Management subfield in the Frame Control field is set to 0, the nonpeer mesh power management mode is active mode. A mesh STA may send Probe Request and Mesh Peering Open Request frames to a nonpeer mesh STA that sets its nonpeer mesh power management mode to deep sleep mode only during the mesh awake window of the mesh STA. 14.14.3 Mesh power management mode indications and transitions 14.14.3.1 General When a mesh STA is in active mode for a mesh peering, it shall set the Power Management subfield in the Frame Control field to 0 in all individually addressed Mesh Data or QoS Null frames transmitted to the corresponding peer mesh STA. When a mesh STA is in light sleep mode for a mesh peering, it shall set the Power Management subfield in the Frame Control field to 1 and the Mesh Power Save Level subfield in the QoS Control field to 0 in all individually addressed Mesh Data or QoS Null frames transmitted to the corresponding peer mesh STA. When a mesh STA is in deep sleep mode for a mesh peering, it shall set the Power Management subfield in the Frame Control field to 1 and the Mesh Power Save Level subfield in the QoS Control field to 1 in all individually addressed Mesh Data or QoS Null frames transmitted to the corresponding mesh STA. 2216 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications When a mesh STA is in deep sleep mode for any of its mesh peerings, the Mesh Power Save Level subfield in the QoS Control field in group addressed mesh Data frames and the Mesh Power Save Level subfield in the Mesh Capability field in the Mesh Configuration element shall be set to 1. When a mesh STA is not in deep sleep mode for any of its mesh peerings, these subfields shall be set to 0. To change peer-specific mesh power management modes, a mesh STA shall inform its peer mesh STAs through a successful frame exchange initiated by the mesh STA. The Power Management subfield in the Frame Control field and the Mesh Power Save Level subfield in the QoS Control field of the frame sent by the mesh STA in this exchange indicates the peer-specific mesh power management mode that the STA shall adopt upon successful completion of the entire frame exchange. The algorithm to trigger the change of a peer-specific mesh power management mode is beyond the scope of this standard. The nonpeer mesh power management mode is determined by the peer-specific mesh power management modes of the mesh STA. When a mesh STA is in light sleep mode or deep sleep mode for at least one mesh peering, it shall set the nonpeer mesh power management mode to deep sleep mode. When a mesh STA is in active mode for nonpeer STAs, it shall set the Power Management subfield in the Frame Control field to 0 in group addressed frames, in Management frames transmitted to nonpeer mesh STAs, and in Probe Response frames. When a mesh STA is in deep sleep mode for nonpeer STAs, it shall set the Power Management subfield in the Frame Control field to 1 in group addressed frames, in Management frames transmitted to nonpeer mesh STAs, and in Probe Response frames. 14.14.3.2 Transition to a higher activity level A mesh STA may use group addressed or individually addressed Mesh Data or QoS Null frames to change its mesh power management mode to a higher activity level, for example; from deep sleep to light sleep or to active mode; or from light sleep to active mode. Individually addressed frames may be used to temporarily raise the activity level of the mesh STA for a mesh peering. NOTEâ€”This is useful in cases when a link temporarily requires efficient data transmission with the peer mesh STA and the mesh STA is attempting to transit back to lower activity level without performing the mesh power management mode transition signaling with all peer mesh STAs. 14.14.3.3 Transition to a lower activity level A mesh STA shall use acknowledged individually addressed Mesh Data or QoS Null frames to change its peer-specific mesh power management mode to a lower activity level, for example; from active mode to light or deep sleep mode; or from light sleep to deep sleep mode. 14.14.4 TIM transmissions in an MBSS The TIM element identifies the peer mesh STAs for which traffic is pending and buffered in the reporting mesh STA. This information is coded in a partial virtual bitmap, as described in 9.4.2.6. In addition, the TIM contains an indication whether group addressed traffic is pending. Every neighbor peer mesh STA is assigned an AID by the reporting mesh STA as part of the mesh peering establishment process (see 14.3.1). The mesh STA shall identify those peer mesh STAs for which it is prepared to deliver47 buffered MSDUs and MMPDUs by setting bits in the TIMâ€™s partial virtual bitmap that correspond to the appropriate AIDs. 47 How the AP or mesh STA determines the traffic is prepared to deliver is outside the scope of this standard. 2217 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 14.14.5 TIM types There are two different TIM types: TIM and DTIM. A mesh STA shall transmit a TIM with every Beacon frame. Every DTIMPeriod, a TIM of type DTIM is transmitted with a Beacon frame. After transmitting a Beacon frame containing a DTIM, the mesh STA shall send the buffered group addressed MSDUs and MMPDUs, before transmitting any individually addressed frames. The More Data subfield of each group addressed frame shall be set to indicate the presence of further buffered group addressed MSDUs and MMPDUs. The mesh STA sets the More Data subfield to 0 in the last transmitted group addressed frame following the transmission of the DTIM Beacon frame. While waiting to receive a group addressed frame that was previously indicated in a TIM element or More Data subfield, a mesh STA that detects CCA is IDLE for the duration of the PHY specific Group Delivery Idle Time may assume that no more frames destined to group addresses will be transmitted and may return to doze state. The Group Delivery Idle Time is identical to the TXOP limit for AC_VI specified by the default EDCA Parameter Set shown in Table 9-137. 14.14.6 Mesh awake window A mesh STA shall be in awake state when its mesh awake window is active. A mesh awake window is active after the Beacon and Probe Response frames containing the Mesh Awake Window element. A mesh STA shall include the Mesh Awake Window element in its DTIM Beacon frames and may include the Mesh Awake Window element in its TIM Beacon and Probe Response frames. A mesh STA that operates in light sleep mode or deep sleep mode for any of its mesh peerings shall include the Mesh Awake Window element in its Beacon frame if the Beacon frame indicates buffered traffic for at least one peer mesh STA. The start of the mesh awake window is measured from the end of the Beacon or Probe Response frame transmission. The duration of the mesh awake window period is specified by dot11MeshAwakeWindowDuration. A mesh STA shall set the Mesh Awake Window field in the Mesh Awake Window element to dot11MeshAwakeWindowDuration. If the Mesh Awake Window element is not contained in the Beacon frame of a mesh STA, the duration of the mesh awake window period following this beacon is zero. If the mesh STA that has its mesh awake window active transmits frames destined to group addresses, the duration of the mesh awake window is extended by an additional PostAwakeDuration. The PostAwakeDuration follows the group address frame, and the mesh STA that has its mesh awake window active shall stay in awake state until it has transmitted all of its group addressed frames and the PostAwakeDuration has expired. The PostAwakeDuration is equal to duration of the mesh awake window. A mesh STA may send a frame to a peer mesh STA that is in light sleep mode or deep sleep mode for the corresponding mesh peering during the mesh awake window of this peer mesh STA. When a peer trigger frame is successfully transmitted it initiates a mesh peer service period as described in 14.14.9. A mesh STA may send Class 1 or Class 2 frames, such as Probe Request or Mesh Peering Open frames, to a nonpeer mesh STA that is in deep sleep mode for nonpeer mesh STAs during the mesh awake window of this nonpeer mesh STA. 14.14.7 Power save support As described in 14.14.2, a mesh STA indicates its peer-specific mesh power management modes and performs mesh power management mode tracking of the peer-specific mesh power management modes of its peer mesh STAs. A mesh STA shall not arbitrarily transmit frames to mesh STAs operating in a light or deep sleep mode, but shall buffer frames and only transmit them at designated times. A mesh STA may transmit frames to a mesh STA operating in a light or deep sleep mode if the recipient mesh STA is in the awake state as defined in 14.14.8.4, 14.14.8.5, and 14.14.9; otherwise, the mesh STA shall not transmit frames and shall buffer frames. 2218 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications As described in 14.14.4, a mesh STA indicates the presence of buffered traffic in TIM elements for all peer mesh STAs that operate in light or deep sleep mode toward the mesh STA. The mesh STA sets the bit for AID 0 (zero) in the Bitmap Control field of the TIM element to 1 when group addressed traffic is buffered, according to 9.4.2.6. As described in 14.14.5, a mesh STA transmits its group addressed frames after its DTIM beacon if any of its peer mesh STA is in light or deep sleep mode toward the mesh STA. As described in 14.14.9, mesh peer service periods are used for frame transmissions toward a mesh STA that operates in light or deep sleep mode. Mesh peer service periods are not used in frame exchanges toward active mode mesh STAs. A mesh STA may initiate a mesh peer service period with a peer mesh STA in deep or light sleep mode by transmitting a peer trigger frame when the mesh awake window of the peer mesh STA is active. 14.14.8 Operation in peer-specific and nonpeer mesh power management modes 14.14.8.1 General Detailed operations of mesh STA in each mesh power management mode are described in the following subclauses. Figure 14-6 depicts example power state transitions of mesh STAs, when three mesh STAs are in the mesh power management modes shown in the Figure 14-5. DTIM interval of mesh STA A Beacon interval of mesh STA A TIM (in Beacon) DTIM TIM TIM TIM DTIM TIM mesh STA A Data DTIM interval (= Beacon interval) Trigger of mesh STA B Ack DTIM (in Beacon) DTIM Activity mesh STA B Mesh Mesh awake awake Data window window DTIM interval (= Beacon interval) Ack of mesh STA C Activity DTIM DTIM mesh STA C Mesh Mesh awake awake window window Figure 14-6â€”Mesh power management operation 14.14.8.2 Operation in active mode When a mesh STA is in active mode for a mesh peering or for nonpeer mesh STAs, it shall be in awake state. Mesh peer service periods are not used in frame exchanges toward mesh STAs that are in active mode. An active mode mesh STA may receive peer trigger frames from a peer mesh STA in light or deep sleep mode when there is no mesh peer service period ongoing between the peer mesh STAs. 14.14.8.3 Operation in deep sleep mode for nonpeer mesh STAs If a mesh STA is in deep sleep mode for nonpeer mesh STAs, it shall enter the awake state prior to every TBTT of its own and shall remain in awake state after the beacon transmission for the duration of the mesh 2219 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications awake window and the duration of its group addressed frame transmissions. The mesh STA may receive frames during its mesh awake window as described in 14.14.6. When receiving a frame initiating a mesh peering management procedure, an authentication procedure, or a passive scanning procedure, a mesh STA in deep sleep mode for nonpeer mesh STAs shall operate in awake state at least until the completion of the mesh peering management procedure (see 14.3 and 14.5), until the completion of the authentication procedure (see 14.3.1 and 14.3.3), or the transmission of the Probe Response frame. If a mesh STA receives a peer trigger frame initiating a mesh peer service period from a peer mesh STA, the mesh STA shall remain in awake state until the mesh peer service period is terminated as defined in 14.14.9.4. A mesh STA may return to doze state after its mesh awake window if no frame initiating a response transaction or a mesh peer service period is received during the mesh awake window. 14.14.8.4 Operation in light sleep mode for a mesh peering If a mesh STA is in light sleep mode for a mesh peering, it shall enter the awake state prior to every TBTT of the corresponding peer mesh STA to receive the Beacon frame from the peer mesh STA. The mesh STA may return to the doze state after the beacon reception from this peer mesh STA, if the peer mesh STA did not indicate buffered individually addressed or group addressed frames. If an indication of buffered individually addressed frames is received, the light sleep mode mesh STA shall send a peer trigger frame with the RSPI field set to 1 to initiate a mesh peer service period with the mesh STA that transmitted the Beacon frame (see 14.14.9.2). If an indication of buffered group addressed frames is received, the light sleep mode mesh STA shall remain in awake state after the DTIM Beacon reception to receive group addressed frames The mesh STA shall remain awake state until the More Data subfield of a received group addressed frame is set to 0 or if no group addressed frame is received within the PHY specific Group Delivery Idle Time. (See 14.14.5.) NOTEâ€”When a mesh STA is in light sleep mode for a mesh peering, it sets its nonpeer mesh power management mode to deep sleep mode. This implies that a mesh STA operating in light sleep mode a mesh peering is required to comply with the rules described in 14.14.8.3. 14.14.8.5 Operation in deep sleep mode for a mesh peering A mesh STA operating in deep sleep mode for a mesh peering might not receive Beacon frames from the corresponding peer mesh STA. The logic of how the mesh STA in deep sleep mode maintains synchronization among neighbors is beyond the scope of this standard. Guidance for the synchronization maintenance by the mesh STA in deep sleep mode is given in S.3.6. NOTEâ€”When a mesh STA is in deep sleep mode for a mesh peering, it sets its nonpeer mesh power management mode to deep sleep mode. This implies that a mesh STA operating in deep sleep mode for a mesh peering is required to comply with the rules described in 14.14.8.3. 14.14.8.6 Conditions for doze state A mesh STA may enter doze state if all of the following conditions are fulfilled: â€” The mesh STA operates in light sleep mode or deep sleep mode for all of its mesh peerings, as described in 14.14.8.4 or 14.14.8.5 â€” The mesh STA has no mesh peer service period ongoing, as described in 14.14.9 â€” The mesh STA has no pending transaction of mesh peering management, authentication, nor passive scanning (see 14.14.8.3) â€” The mesh awake window indicated by the mesh STA has expired, as described in 14.14.6 2220 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” The mesh STA has terminated its group addressed frames delivery sequence after its DTIM Beacon frame, as described in 14.14.5 Guidance for using the power save in mesh BSS and default parameter values are given in S.3. 14.14.9 Mesh peer service periods 14.14.9.1 General Mesh peer service periods are used for individually addressed frame exchanges between neighbor peer mesh STAs in which at least one of the mesh STAs is in light or deep sleep mode for the corresponding mesh peering. A mesh peer service period is a period of time during which one or more individually addressed frames are transmitted between two peer mesh STAs. Within a mesh peer service period, a mesh STA may obtain multiple TXOPs. A mesh peer service period is directional. One mesh STA is the owner of the mesh peer service period. It obtains TXOPs in order to transmit Data frames or Management frames to the recipient in the mesh peer service period. At the end of the frame transmissions, the owner of the mesh peer service period terminates the mesh peer service period. The other mesh STA operates as the recipient of the mesh peer service period and does not obtain TXOPs for transmitting Data frames or Management frames to the owner of the mesh peer service period. A mesh STA may have multiple mesh peer service periods concurrently toward multiple neighbor peer mesh STAs. At most, one mesh peer service period is set up in each direction with each peer mesh STA. A mesh peer service period is initiated by a peer trigger frame. A peer trigger frame may initiate two mesh peer service periods. This enables both the transmitter and the receiver of the peer trigger frame to become the owner of a mesh peer service period. An example mesh peer service period between two mesh STAs in light or deep sleep mode is shown in Figure 14-7. The numbering on the left-hand-side describes the phase of the operation: 1 indicates the Initiation phase, 2 indicates the data transmission phase, and 3 indicates the termination phase of the mesh peer service period. Mesh Data frame, RSPI=1, EOSP=0 1. Ack Mesh Data frame, RSPI=0, EOSP=0 The mesh STA is the owner in 2. Ack the mesh peer service period Mesh Data frame, RSPI=0, EOSP=1 The mesh STA is the recipient 3. Ack in the mesh peer service period Mesh Data frame, RSPI=0, EOSP=1 Ack mesh STA A mesh STA B Figure 14-7â€”Mesh peer service period 14.14.9.2 Initiation of a mesh peer service period A mesh Data frame or a QoS Null frame that requires acknowledgment are used as a peer trigger frame. The RSPI and the EOSP subfields in the QoS Control field control the initiation of a mesh peer service period. 2221 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 14-32 lists how mesh peer service periods shall be initiated with different combinations of RSPI and EOSP subfield values. Table 14-32â€”Mesh peer service period triggering with RSPI and EOSP subfield combina- tions in peer trigger frame RSPI EOSP Mesh peer service period triggering 0 0 One mesh peer service period is initiated. The transmitter of the trigger frame is the owner in the mesh peer service period. 0 1 No mesh peer service period is initiated. 1 0 Two mesh peer service periods are initiated. Both mesh STAs are owners in a mesh peer service period. 1 1 One mesh peer service period is initiated. The receiver of the trigger frame is the owner in the mesh peer service period. Mesh peer service periods are not used in frame transmissions toward active mode mesh STAs. The mesh peer service period may be initiated in the following cases: â€” A mesh STA in light or deep sleep mode receives a peer trigger frame during its mesh awake window as described in 14.14.6 â€” A mesh STA in active mode receives a peer trigger frame from the peer mesh STA in light or deep sleep mode as described in 14.14.8.2 â€” A mesh STA receives a peer trigger frame from the peer mesh STA in light sleep mode as described in 14.14.8.4 In addition, when a mesh STA uses MCCA with a neighbor peer mesh STA while in a light sleep mode for the corresponding mesh peering, a scheduled service period begins at the each MCCAOP start time as described in 14.14.10. A mesh STA in a light or deep sleep mode shall enter the awake state prior to the start time of scheduled service period. 14.14.9.3 Operation during a mesh peer service period During the mesh peer service period, the owner and the recipient of the mesh peer service period shall operate in awake state. The mesh peer service period may contain one or more TXOPs. Reverse direction grant (RDG) shall not be used when the receiver of the TXOP operates in light or deep sleep mode for the link and there is no mesh peer service period ongoing toward the TXOP holder. 14.14.9.4 Termination of a mesh peer service period The mesh peer service period is terminated after a successfully acknowledged QoS Null or mesh Data frame with the EOSP subfield set to 1 from the owner of the mesh peer service period. If the mesh STA does not receive an acknowledgment to a frame that requires an acknowledgment and that is sent with the EOSP subfield set to 1, the mesh STA shall retransmit that frame at least once within the same mesh peer service period, subject to applicable retry or lifetime limits. The maximum number of retransmissions within the same mesh peer service period is the lesser of the Max Retry Limit and dot11MeshSTAMissingAckRetryLimit. 2222 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NOTEâ€”If an acknowledgment to the retransmission of this last frame in the same mesh peer service period is not received, the mesh STA might use the next mesh peer service period to further retransmit that frame subject to the applicable retry or lifetime limit. 14.14.10 MCCA use by power saving mesh STA When dot11MCCAActivated is true and the mesh STA establishes MCCAOPs, the mesh STA shall be in active mode or light sleep mode toward the neighbor peer mesh STAs with which it has established MCCAOPs. A scheduled mesh peer service period begins at the MCCAOP start time, if the MCCAOP responder operates in light sleep mode for the MCCAOP owner. The MCCAOP owner is the owner of the scheduled mesh peer service period. The MCCAOP responder is the recipient of the scheduled mesh peer service period. Scheduled mesh peer service periods are not used if the MCCAOP responder is in active mode for the MCCAOP owner. The scheduled mesh peer service period continues until it is successfully terminated by the acknowledged QoS Null or mesh Data frame with the EOSP subfield set to 1 from the owner of the mesh peer service period to the recipient of the mesh peer service period as described in 14.14.9. 2223 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 15. DSSS PHY specification for the 2.4 GHz band designated for ISM applications 15.1 Overview 15.1.1 General The PHY for the DSSS system is described in this clause. The RF LAN system is aimed for the 2.4 GHz band designated for ISM applications. The DSSS system provides a WLAN with both a 1 Mb/s and a 2 Mb/s data payload communication capability. The DSSS system uses baseband modulations of differential binary phase shift keying (DBPSK) and differential quadrature phase shift keying (DQPSK) to provide the 1 Mb/s and 2 Mb/s data rates, respectively. 15.1.2 Scope The PHY services provided to the IEEE 802.11 WLAN MAC by the 2.4 GHz DSSS system are described in this clause. The DSSS PHY consists of the following protocol functions: a) A function that defines a method of mapping the IEEE 802.11 MPDUs into a framing format suitable for sending and receiving user data and management information between two or more STAs. b) A function that defines the characteristics of, and method of transmitting and receiving data through, a WM between two or more STAs each using the DSSS system. 15.1.3 DSSS PHY functions 15.1.3.1 General The 2.4 GHz DSSS PHY architecture is depicted in the reference model shown in Figure 4-19 (in 4.9). The DSSS PHY contains two functional entities: the PHY function and the layer management function. Each of these functions is described in detail in the following subclauses. The DSSS PHY service shall be provided to the MAC through the PHY service primitives described in Clause 8. 15.1.3.2 PLME The PLME performs management of the local PHY functions in conjunction with the MLME. 15.1.4 Service specification method and notation The models represented by figures and state diagrams are intended to be illustrations of functions provided. It is important to distinguish between a model and a real implementation. The models are optimized for simplicity and clarity of presentation, but do not necessarily reflect any particular implementation. The service of a layer or sublayer is a set of capabilities that it offers to a user in the next-higher layer (or sublayer). Abstract services are specified here by describing the service primitives and parameters that characterize each service. This definition is independent of any particular implementation. 2224 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 15.2 DSSS PHY specific service parameter list 15.2.1 Introduction The architecture of the IEEE 802.11 MAC is intended to be PHY independent. Some PHY implementations require medium management state machines running in the MAC sublayer in order to meet certain PHY requirements. These PHY-dependent MAC state machines reside in a sublayer defined as the MLME. In certain PHY implementations, the MLME may need to interact with the PLME as part of the normal PHY SAP primitives. These interactions are defined by the PLME parameter list currently defined in the PHY service primitives as TXVECTOR and RXVECTOR. The list of these parameters, and the values they may represent, are defined in the specific PHY specifications for each PHY. Subclause 15.2 addresses the TXVECTOR and RXVECTOR for the DSSS PHY. 15.2.2 TXVECTOR parameters 15.2.2.1 General The parameters in Table 15-1 are defined as part of the TXVECTOR parameter list in the PHY- TXSTART.request primitive. 15.2.2.2 TXVECTOR LENGTH The LENGTH parameter provided in the TXVECTOR is in octets and is converted to microseconds for inclusion in the PHY LENGTH field. 15.2.2.3 TXVECTOR DATARATE The DATARATE parameter describes the bit rate at which the PHY shall transmit the PSDU. Its value takes any of the rates defined in Table 15-1. Table 15-1â€”TXVECTOR parameters Parameter Value LENGTH 0 to 212 â€“ 1 DATARATE 1, 2 Mb/s SERVICE Null TXPWR_LEVEL_IN- 1 to 8 DEX TIME_OF_ false, true. When true, the MAC entity requests that the PHY entity measures and DEPARTURE_ reports time of departure parameters corresponding to the time when the first frame REQUESTED energy is sent by the transmitting port; when false, the MAC entity requests that the PHY entity neither measures nor reports time of departure parameters. TX_ANTENNA 1 to 256 15.2.2.4 TXVECTOR SERVICE The SERVICE parameter shall be null. 2225 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 15.2.2.5 TXVECTOR TXPWR_LEVEL_INDEX The allowed values for the TXPWR_LEVEL_INDEX parameter are in the range 1 to 8. This parameter is used to indicate which of the available TxPowerLevel attributes defined in the MIB shall be used for the current transmission. 15.2.2.6 TXVECTOR TIME_OF_DEPARTURE_REQUESTED The allowed values are false or true. A parameter value of true indicates that the MAC sublayer is requesting that the PHY entity provides measurement of when the first frame energy is sent by the transmitting port and reporting within the PHY-TXSTART.confirm(TXSTATUS) primitive. A parameter value of false indicates that the MAC sublayer is requesting that the PHY entity not provide time of departure measurement nor reporting in the PHY-TXSTART.confirm(TXSTATUS) primitive. 15.2.2.7 TXVECTOR TX_ANTENNA Selects the antenna used by the PHY for transmission (when diversity is disabled), in the range 1 to 256. 15.2.3 RXVECTOR parameters 15.2.3.1 General The parameters listed in Table 15-2 are defined as part of the RXVECTOR parameter list in the PHY- RXSTART.indication primitive. Table 15-2â€”RXVECTOR parameters Parameter Value LENGTH 0 to 212 â€“ 1 RSSI 0â€“255 SIGNAL 1, 2 Mb/s SERVICE 1, 2 Mb/s RCPI 0â€“255 (see NOTE) SQ 0â€“255 RX_ANTENNA 1â€“256 RX_START_OF_FRAME_OFFSET 0 to 232â€“ 1. An estimate of the offset (in 10 ns units) from the point in time at which the start of the preamble corresponding to the incoming frame arrived at the receive antenna connector to the point in time at which this primitive is issued to the MAC. NOTEâ€”Parameter is present only when dot11RadioMeasurementActivated is true. 15.2.3.2 RXVECTOR LENGTH The MPDU length in octets (calculated from the LENGTH field in microseconds). 2226 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 15.2.3.3 RXVECTOR RSSI This parameter is a measure by the PHY of the energy observed at the antenna used to receive the current PPDU. RSSI shall be measured during the reception of the PHY preamble. RSSI is intended to be used in a relative manner, and it shall be a monotonically increasing function of the received power. 15.2.3.4 RXVECTOR SIGNAL SIGNAL shall represent the data rate at which the current PPDU was received. 15.2.3.5 RXVECTOR SERVICE The SERVICE parameter shall be null. 15.2.3.6 RXVECTOR RCPI The allowed values for the RCPI parameter are in the range 0 to 255, as defined in 9.4.2.38. This parameter is a measure by the PHY of the received channel power. The performance requirements for the measurement of RCPI are defined in 15.4.6.6. 15.2.3.7 RXVECTOR SQ SQ provides to the MAC entity the signal quality of the DSSS PHY PN code correlation. The SQ shall be sampled when the DSSS PHY achieves code lock and shall be held until the next code lock acquisition. The SQ may be used in conjunction with RSSI as part of a CCA scheme. 15.2.3.8 RXVECTOR RX_ANTENNA RX_ANTENNA reports the antenna used by the PHY for reception of the most recent packet. 15.2.4 TXSTATUS parameters 15.2.4.1 General The parameters listed in Table 15-3 are defined as part of the TXSTATUS parameter list in the PHY- TXSTART.confirm primitive. 15.2.4.2 TXSTATUS TIME_OF_DEPARTURE The allowed values for the TIME_OF_DEPARTURE parameter are integers in the range 0 to 232- 1. This parameter is used to indicate when the first frame energy is sent by the transmitting port in units equal to 1/ TIME_OF_DEPARTURE_ClockRate. TIME_OF_DEPARTURE may be included in the transmitted frame in order for recipients on multiple channels to determine the time differences of air propagation times between transmitter and recipients and hence to compute the location of the transmitter. 15.2.4.3 TXSTATUS TIME_OF_DEPARTURE_ClockRate TIME_OF_DEPARTURE_ClockRate indicates the clock rate used for TIME_OF_DEPARTURE. 2227 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 15-3â€”TXSTATUS parameters Parameter Value TIME_OF_DEPARTURE 0 to 232â€“ 1. The locally measured time when the first frame energy is sent by the transmitting port, in units equal to 1/ TIME_OF_DEPARTURE_ClockRate. This parameter is present only if TIME_OF_DEPARTURE_REQUESTED is true in the corresponding request. TIME_OF_DEPARTURE_ClockRate 0 to 216â€“ 1. The clock rate, in units of MHz, is used to generate the TIME_OF_DEPARTURE value. This parameter is present only if TIME_OF_DEPARTURE_REQUESTED is true in the corresponding request. TX_START_OF_FRAME_OFFSET 0 to 232â€“ 1. An estimate of the offset (in 10 ns units) from the point in time at which the start of the preamble corresponding to the frame was transmitted at the transmit antenna connector to the point in time at which this primitive is issued to the MAC. 15.3 DSSS PHY 15.3.1 Overview Subclause 15.3 provides a convergence procedure in which MPDUs are converted to and from PPDUs. During transmission, the MPDU shall be prepended with a PHY preamble and header to create the PPDU. At the receiver, the PHY preamble and header are processed to aid in demodulation and delivery of the MPDU. 15.3.2 PPDU format Figure 15-1 shows the format for the PPDU including the DSSS PHY preamble, the DSSS PHY header, and the MPDU. The PHY preamble contains the following fields: SYNC and SFD. The PHY header contains the following fields: Signaling (SIGNAL), Service (SERVICE), length (LENGTH), and CRC-16 (CRC). Each of these fields is described in detail in 15.3.3. SYNC SFD SIGNAL SERVICE LENGTH CRC 128 bits 16 bits 8 bits 8 bits 16 bits 16 bits PHY Preamble PHY Header MPDU 144 bits 48 bits PPDU Figure 15-1â€”PPDU format 2228 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 15.3.3 PHY field definitions 15.3.3.1 General The entire PHY preamble and header shall be transmitted using the 1 Mb/s DBPSK modulation described in 15.4.5. All transmitted bits shall be scrambled using the feedthrough scrambler described in 15.3.4. 15.3.3.2 PHY SYNC field The SYNC field shall consist of 128 bits of scrambled 1s. This field shall be provided so that the receiver can perform the necessary operations for synchronization. 15.3.3.3 PHY SFD The SFD shall be provided to indicate the start of PHY-dependent parameters within the PHY preamble. The SFD shall be a 16-bit field, X'F3A0' (MSB to LSB). The LSB shall be transmitted first in time. 15.3.3.4 PHY SIGNAL field The 8-bit SIGNAL field indicates to the PHY the modulation that shall be used for transmission (and reception) of the MPDU. The data rate shall be equal to the signal field value multiplied by 100 kb/s. The DSSS PHY currently supports two mandatory modulation services given by the following 8-bit words, where the LSB shall be transmitted first in time: a) X'0A' (MSB to LSB) for 1 Mb/s DBPSK b) X'14' (MSB to LSB) for 2 Mb/s DQPSK The DSSS PHY rate change capability is described in 15.3.5. This field shall be protected by the CRC-16 FCS described in 15.3.3.7. 15.3.3.5 PHY SERVICE field The 8-bit SERVICE field is reserved for future use; it shall be set to 0 on transmission and ignored on reception. The LSB shall be transmitted first in time. This field shall be protected by the CRC-16 FCS described in 15.3.3.7. 15.3.3.6 PHY LENGTH field The PHY LENGTH field shall be an unsigned 16-bit integer that indicates the number of microseconds required to transmit the MPDU. The transmitted value shall be determined from the LENGTH parameter in the TXVECTOR issued with the PHY-TXSTART.request primitive described in 8.3.5.5. The LENGTH field provided in the TXVECTOR is in octets and is converted to microseconds for inclusion in the PHY LENGTH field. The LSB shall be transmitted first in time. This field shall be protected by the CRC-16 FCS described in 15.3.3.7. 2229 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 15.3.3.7 PHY CRC field The SIGNAL, SERVICE, and LENGTH fields shall be protected with a CRC-16 FCS. The CRC-16 FCS shall be the 1s complement of the remainder generated by the modulo 2 division of the protected PHY fields by the polynomial: x16 + x12 + x5 + 1 The protected bits shall be processed in transmit order. All FCS calculations shall be made prior to data scrambling. As an example, the SIGNAL, SERVICE, and LENGTH fields for a DBPSK signal with a packet length of 192 Âµs (24 octets) would be given by the following: 0101 0000 0000 0000 0000 0011 0000 0000 (leftmost bit transmitted first in time) The 1s complement FCS for these protected PHY preamble bits would be the following: 0101 1011 0101 0111 (leftmost bit transmitted first in time) Figure 15-2 depicts this example. 1s 1s 1s 1s Figure 15-2â€”CRC-16 implementation 2230 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications An illustrative example of the CRC-16 FCS using the information from Figure 15-2 follows in Figure 15-3. Data CRC registers MSB LSB 1111111111111111 ; initialize preset to 1s 0 1110111111011111 1 1101111110111110 0 1010111101011101 1 0101111010111010 0 1011110101110100 0 0110101011001001 0 1101010110010010 0 1011101100000101 0 0110011000101011 0 1100110001010110 0 1000100010001101 0 0000000100111011 0 0000001001110110 0 0000010011101100 0 0000100111011000 0 0001001110110000 0 0010011101100000 0 0100111011000000 0 1001110110000000 0 0010101100100001 0 0101011001000010 0 1010110010000100 1 0101100100001000 1 1010001000110001 0 0101010001000011 0 1010100010000110 0 0100000100101101 0 1000001001011010 0 0001010010010101 0 0010100100101010 0 0101001001010100 0 1010010010101000 0101101101010111 ; 1s complement, result = CRC FCS parity Figure 15-3â€”Example CRC calculation 15.3.4 PHY/DSSS PHY data scrambler and descrambler The polynomial G(z) = z â€“7 + z â€“4 + 1 shall be used to scramble all bits transmitted by the DSSS PHY. The feedthrough configuration of the scrambler and descrambler is self-synchronizing, which requires no prior knowledge of the transmitter initialization of the scrambler for receive processing. Figure 15-4 and Figure 15-5 show typical implementations of the data scrambler and descrambler, but other implementations are possible. The scrambler should be initialized to any state except all 1s when transmitting. Figure 15-4â€”Data scrambler 2231 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Figure 15-5â€”Data descrambler 15.3.5 PHY data modulation and modulation rate change The PHY preamble shall be transmitted using the 1 Mb/s DBPSK modulation. The SIGNAL field shall indicate the modulation that shall be used to transmit the MPDU. The transmitter and receiver shall initiate the modulation indicated by the SIGNAL field starting with the first symbol (1 bit for DBPSK or 2 bits for DQPSK) of the MPDU. The MPDU transmission rate shall be set by the DATARATE parameter in the TXVECTOR issued with the PHY-TXSTART.request primitive described in 15.2.2. 15.3.6 Transmit PHY The transmit PHY is shown in Figure 15-6. PHYâ€DATA. PHYâ€TXEND.request PHYâ€TXSTART. PHYâ€TXSTART. request or length count met MAC request confirm (TXVECTOR) (TXSTATUS) (DATA) PHYâ€TXEND.confirm PHY SFD SFD Signal, Service, Length CRC MPDU Scramble start CRC16 CRC16 Rate change start TX Power TX Power RAMP start end RAMP Off Figure 15-6â€”Transmit PHY In order to transmit data, PHY-TXSTART.request primitive shall be issued so that the PHY entity shall be in the transmit state. Further, the PHY shall be set to operate at the appropriate channel through STA management via the PLME. Other transmit parameters such as DATARATE, TX antenna, and TX power are set via the PHY SAP with the PHY-TXSTART.request(TXVECTOR) primitive as described in 15.2.2. Based on the state of CCA indicated by the PHY-CCA.indication primitive, the MAC assesses that the channel is clear. A clear channel shall be indicated by a PHY-CCA.indication(IDLE) primitive. If the channel is clear, transmission of the PPDU shall be initiated by issuing the PHY-TXSTART.request(TXVECTOR) primitive. The TXVECTOR elements for the PHY-TXSTART.request primitive are the PHY header parameters SIGNAL (DATARATE), SERVICE, LENGTH, TX_ANTENNA, TXPWR_LEVEL_INDEX, and TIME_OF_DEPARTURE_REQUESTED. The PHY header parameter LENGTH is calculated from the TXVECTOR element by multiplying by 8 for 1 Mb/s and by 4 for 2 Mb/s. The PHY is configured with the TXVECTOR elements TX_ANTENNA, DATARATE, and TXPWR_LEVEL_INDEX. The PHY entity shall immediately initiate data scrambling and transmission of 2232 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications the PHY preamble based on the parameters passed in the PHY-TXSTART.request primitive. The time required for transmit power-on ramp described in 15.4.5.8 shall be included in the PHY SYNC field. Once the PHY preamble transmission is complete, data shall be exchanged between the MAC and the PHY by a series of PHY-DATA.request(DATA) primitives issued by the MAC and PHY-DATA.confirm primitives issued by the PHY. The modulation rate change, if any, shall be initiated with the first data symbol of the MPDU as described in 15.3.5. The PHY proceeds with MPDU transmission through a series of data octet transfers from the MAC. Transmission can be prematurely terminated by the MAC through the PHY- TXEND.request primitive. PHY-TXSTART shall be disabled by the issuance of the PHY-TXEND.request primitive. Normal termination occurs after the transmission of the final bit of the last MPDU octet according to the number supplied in the TXVECTOR LENGTH field. The packet transmission shall be completed and the PHY entity shall enter the receive state (i.e., PHY-TXSTART shall be disabled). It is recommended that chipping continue during power-down. Each PHY-TXEND.request primitive is acknowledged with a PHY- TXEND.confirm primitive from the PHY. A typical state machine implementation of the transmit PHY is provided in Figure 15-7. PHYâ€TXSTART.request(TXVECTOR) Initialize TX MPDU OCTET PHYâ€DATA.request set Tx parameters (DATA) get octet from MAC set octet bit count TX SYNC PATTERN TX SYMBOL TX 128 scrambled 1s PHYâ€TXSTART.confirm (TXSTATUS) Decrement Bit decrement bit count TX HEADER by bits per symbol bit count â‰ 0 TX 16 bit SFD bit count = 0 TX 8 bit SIGNAL Decrement Length TX 8 bit SERVICE TX 16 bit LENGTH decrement length length â‰ 0 TX 16 bit CRC count length = 0 SETUP MPDU TX Switch to RX STATE set rate A set length count A At any stage in the above flow diagram, if a PHYâ€TXEND.request primitive is received. Figure 15-7â€”PHY transmit state machine 2233 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 15.3.7 Receive PHY The receive PHY is shown in Figure 15-8. PH Yâ€RXEN D.indication PH Yâ€CCA .indication PH Yâ€D ATA.indication(D ATA) (RXERRO R ,RXVECTO R ) (BU SY) M AC PH Yâ€RXSTART.indication(RXVECTO R) PH Yâ€CCA .indication(ID LE) PH Y SYN C SFD Signal, Service, Length CRC M PD U D escram ble start CRC start CRC end Rate change start Figure 15-8â€”Receive PHY In order to receive data, PHY-TXSTART.request primitive shall be disabled so that the PHY entity is in the receive state. Further, through STA management via the PLME, the PHY is set to the appropriate channel and the CCA method is chosen. Other receive parameters such as RSSI, RCPI, signal quality (SQ), and indicated DATARATE may be accessed via the PHY SAP. Upon receiving the transmitted energy, according to the selected CCA mode, A PHY- CCA.indication(BUSY) primitive shall be issued for energy detection (ED) and/or code lock prior to correct reception of the PHY header. The PHY measures the RSSI and SQ and the parameters are reported to the MAC in the RXVECTOR. After a PHY-CCA.indication primitive is issued, the PHY entity shall begin searching for the SFD field. Once the SFD field is detected, CRC-16 processing shall be initiated and the PHY SIGNAL, SERVICE and LENGTH fields are received. The CRC-16 FCS shall be processed. If the CRC-16 FCS check fails, the PHY receiver shall return to the RX IDLE state as depicted in Figure 15-9. Should the status of CCA return to the IDLE state during reception prior to completion of the full PPDU processing, the PHY receiver shall return to the RX IDLE state. If the PHY header reception is successful (and the SIGNAL field is completely recognizable and supported), a PHY-RXSTART.indication(RXVECTOR) primitive shall be issued. If dot11TimingMsmtActivated is true, the PHY shall do the following: â€” Complete receiving the PHY header and verify the validity of the PHY Header. â€” If the PHY header reception is successful (and the SIGNAL field is completely recognizable and supported), a PHY-RXSTART.indication(RXVECTOR) primitive shall be issued and RX_START_OF_FRAME_OFFSET parameter within the RXVECTOR shall be forwarded (see 15.2.3). NOTEâ€”The RX_START_OF_FRAME_OFFSET value is used as described in 6.3.57 in order to estimate when the start of the preamble for the incoming frame was detected on the medium at the receive antenna connector. The RXVECTOR associated with this primitive includes the SIGNAL field, the SERVICE field, the MPDU length in octets (calculated from the LENGTH field in microseconds), the antenna used for receive (RX_ANTENNA), RSSI, RCPI, and SQ. The received MPDU bits are assembled into octets and presented to the MAC using a series of PHY- DATA.indication(DATA) primitive exchanges. The rate change indicated in the SIGNAL field shall be initiated with the first symbol of the MPDU as described in 15.3.5. The PHY proceeds with MPDU 2234 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications reception. After the reception of the final bit of the last MPDU octet, as indicated by the PHY preamble LENGTH field, the receiver shall be returned to the RX IDLE state as shown in Figure 15-9. A PHY- RXEND.indication(NoError) primitive shall be issued. A PHY-CCA.indication(IDLE) primitive shall be issued following a change in PHY carrier sense (PHYCS) and/or PHY energy detection (PHYED) according to the selected CCA method. In the event that a change in PHYCS or PHYED would cause the status of CCA to return to the IDLE state before the complete reception of the MPDU, as indicated by the PHY LENGTH field, the error condition shall be reported to the MAC using a PHY-RXEND.indication(CarrierLost) primitive. The CCA of the DSSS PHY shall indicate a busy medium for the intended duration of the transmitted packet. If the PHY header is successful, but the indicated rate in the SIGNAL field is not receivable, a PHY- RXSTART.indication primitive shall not be issued. The PHY shall indicate the error condition by issuing a PHY-RXEND.indication(UnsupportedRate) primitive. If the PHY header is successful, but the SERVICE field is out of IEEE 802.11 DSSS specification, a PHY-RXSTART.indication primitive shall not be issued. The PHY shall indicate the error condition by issuing a PHY-RXEND.indication(FormatViolation) primitive. Also, in both cases, the CCA of the DSSS PHY shall indicate a busy medium for the intended duration of the transmitted frame as indicated by the LENGTH field. The intended duration is indicated by the LENGTH field (length 1 Âµs). Figure 15-9 shows the flow of a typical state machine implementation of the receive PHY. 15.4 DSSS PLME 15.4.1 PLME SAP sublayer management primitives Table 15-4 lists the MIB attributes that may be accessed by the PHY entities and intralayer of higher level LMEs. These attributes are accessed via the PLME-GET, PLME-SET, and PLME-RESET primitives defined in Clause 6. 15.4.2 DSSS PHY MIB All DSSS PHY MIB attributes are defined in Clause 8, with specific values defined in Table 15-4. 15.4.3 DSSS PHY The static DSSS PHY characteristics, provided through the PLME-CHARACTERISTICS service primitive, are shown in Table 15-5. The definitions of these characteristics are in 6.5.4. 15.4.4 PHY operating specifications, general 15.4.4.1 General Subclause 15.4.4 provides general specifications for the DSSS PHY sublayer. These specifications apply to both the Receive and the Transmit functions and general operation of a DSSS PHY. 15.4.4.2 Operating frequency range The DSSS PHY shall operate in the frequency range of 2.4 GHz to 2.4835 GHz as allocated by regulatory bodies in the China, United States and Europe or in the 2.471 GHz to 2.497 GHz frequency band as allocated by regulatory authority in Japan. 2235 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications RX Idle State perform CS/CCA RX SYMBOL PHYâ€DATA.indication Detect SFD pattern CCA(IDLE) CCA(BUSY) Wait until SFD is Signal not valid Decrement length PHYâ€CCA. detected indication PHYâ€RXEND. decrement length indication count by 1 length â‰ 0 (IDLE) (carrier lost) microsecond RX PHY Fields Octet assimilation PHYâ€CCA. RX 8 bit SIGNAL indication RX 8 bit SERVICE Increment bit count (IDLE) set octet bit count RX 16 bit LENGTH Wait for intended end of MPDU PHYâ€DATA. indication (DATA) PHYâ€CCA. indication (IDLE) RX PHY CRC length = 0 or CRC fail RX and Test CRC END OF MPDU RX PHYâ€CCA. PHYâ€RXEND. indication CRC correct length = 0 indication (IDLE) PHYâ€CCA. (No_Error) VALIDATE PPDU indication (IDLE) Decrement Length PHYâ€CCA. indication (IDLE) decrement length Check PPDU count PHY Fields out of specification PPDU correct SETUP MPDU RX set Rate set length count set octet bit count PHYâ€ RXSTART.indication (RXVECTOR) Figure 15-9â€”PHY receive state machine 15.4.4.3 Channel Numbering of operating channels When dot11OperatingClassesRequired is true, channel numbering shall be as specified in 17.3.8.4.2 and channelization shall be as specified in 17.3.8.4.3. When dot11OperatingClassesDefined is false or not defined, the channel center frequencies and CHNL_ID numbers shall be as shown in Table 15-6. In a multiple cell network topology, overlapping and/or adjacent cells using different channels can operate simultaneously without interference if the distance between the center frequencies is at least 30 MHz. 2236 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 15-4â€”MIB attribute default values/ranges Operational Managed object Default value/range semantics dot11PhyOperationComplianceGroup dot11PHYType DSSSâ€“2.4 (02) Static dot11RegDomainsSupported Implementation dependent Static dot11CurrentRegDomain Implementation dependent Static dot11PhyRateGroup dot11SupportedDataRatesTx X'02', X'04' Static dot11SupportedDataRatesRx X'02', X'04' Static dot11PhyAntennaComplianceGroup dot11CurrentTxAntenna Implementation dependent Dynamic dot11DiversitySupportImplemented Implementation dependent Static dot11CurrentRxAntenna Implementation dependent Dynamic dot11PhyTxPowerComplianceGroup dot11NumberSupportedPowerLevelsImplemented Implementation dependent Static dot11TxPowerLevel1 Implementation dependent Static dot11TxPowerLevel2 Implementation dependent Static dot11TxPowerLevel3 Implementation dependent Static dot11TxPowerLevel4 Implementation dependent Static dot11TxPowerLevel5 Implementation dependent Static dot11TxPowerLevel6 Implementation dependent Static dot11TxPowerLevel7 Implementation dependent Static dot11TxPowerLevel8 Implementation dependent Static dot11CurrentTxPowerLevel Implementation dependent Dynamic dot11PhyDSSSComplianceGroup dot11CurrentChannel Implementation dependent Dynamic dot11CCAModeSupported Implementation dependent Static dot11CurrentCCAMode Implementation dependent Dynamic dot11EDThreshold Implementation dependent Dynamic 2237 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 15-4â€”MIB attribute default values/ranges (continued) Operational Managed object Default value/range semantics dot11AntennasListEntry dot11TxAntennaImplemented Implementation dependent Static dot11RxAntennaImplemented Implementation dependent Static dot11DiversitySelectionRxImplemented Implementation dependent Dynamic NOTEâ€”The column titled â€œOperational semanticsâ€ contains two types: static and dynamic. Static MIB attributes are fixed and cannot be modified for a given PHY implementation. MIB attributes defined as dynamic can be modified by some management entities. Table 15-5â€”DSSS PHY characteristics Characteristic Value aSlotTime If dot11OperatingClassesRequired is false, 20 Âµs If dot11OperatingClassesRequired is true, 20 Âµs plus any coverage-class-depen- dent aAirPropagationTime (see Table 9-79) aSIFSTime 10 Âµs aCCATime Implementation dependent, see 10.3.7. aRxPHYStartDelay 192 Âµs aRxTxTurnaroundTime Implementation dependent, see 10.3.7. aTxPHYDelay Implementation dependent, see 10.3.7. aRxPHYDelay Implementation dependent, see 10.3.7. aRxTxSwitchTime Implementation dependent, see 10.3.7. aTxRampOnTime Implementation dependent, see 10.3.7. aAirPropagationTime As indicated by the coverage class (see 10.21.5). aMACProcessingDelay Implementation dependent, see 10.3.7. aPreambleLength 144 Âµs aPHYHeaderLength 48 Âµs aPSDUMaxLength 212 â€“ 1 octets aCWmin 31 aCWmax 1023 2238 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 15-6â€”DSSS PHY frequency channel plan Frequency CHNL_ID (MHz) 1 2412 2 2417 3 2422 4 2427 5 2432 6 2437 7 2442 8 2447 9 2452 10 2457 11 2462 12 2467 13 2472 14 2484 15.4.4.4 Spreading sequence The following 11-chip Barker sequence shall be used as the PN code sequence: +1, â€“1, +1, +1, â€“1, +1, +1, +1, â€“1, â€“1, â€“1 The leftmost chip shall be output first in time. The first chip shall be aligned at the start of a transmitted symbol. The symbol duration shall be exactly 11 chips long. 15.4.4.5 Modulation and channel data rates Two modulation formats and data rates are specified for the DSSS PHY: a basic access rate and an enhanced access rate. The basic access rate shall be based on 1 Mb/s DBPSK modulation. The DBPSK encoder is specified in Table 15-7. The enhanced access rate shall be based on 2 Mb/s DQPSK. The DQPSK encoder is specified in Table 15-8. (In the tables, +j shall be defined as counterclockwise rotation.) Table 15-7â€”1 Mb/s DBPSK encoding table Bit input Phase change (+j ) 0 0 1 2239 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 15-8â€”2 Mb/s DQPSK encoding table Dibit pattern (d0,d1) Phase change (+j ) d0 is first in time 00 0 01 /2 11 10 3 /2 (â€“ /2) 15.4.4.6 Transmit and receive in-band and out-of-band spurious emissions The DSSS PHY shall comply with in-band and out-of-band spurious emissions as set by the appropriate regulatory bodies. 15.4.4.7 TX-to-RX turnaround time The TX-to-RX turnaround time shall be less than 10 Âµs, including the power-down ramp specified in 15.4.5.8. The TX-to-RX turnaround time shall be measured on the WM from the trailing edge of the last transmitted symbol to valid CCA detection of the incoming signal. The CCA should occur within 25 Âµs (10 Âµs for turnaround time plus 15 Âµs for energy detect) or by the next slot boundary occurring after 25 Âµs has elapsed (refer to 15.4.6.5). A receiver input signal 3 dB above the ED threshold described in 15.4.6.5 shall be present at the receiver. 15.4.4.8 RX-to-TX turnaround time The RX-to-TX turnaround time shall be measured at the MAC/PHY interface, using the PHY- TXSTART.request primitive and shall be 5 Âµs. This includes the transmit power-on ramp described in 15.4.5.8. 15.4.4.9 Slot time The value of the slot time is found in Table 15-5. 15.4.4.10 Transmit and receive antenna connector impedance The impedance at the transmit and receive antenna connector(s) shall be 50 if the connector is exposed. 15.4.5 PHY transmit specifications 15.4.5.1 Introduction The transmit functions and parameters associated with the PHY sublayer are described in 15.4.5.2 to 15.4.5.10. 15.4.5.2 Transmit power levels The maximum allowable output power is measured in accordance with practices specified by the appropriate regulatory bodies. 2240 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 15.4.5.3 Minimum transmitted power level The minimum transmitted power shall be no less than 1 mW. 15.4.5.4 Transmit power level control Power control shall be provided for transmitted power greater than 100 mW. A maximum of four power levels may be provided. At a minimum, a radio capable of transmission greater than 100 mW shall be capable of switching power back to 100 mW or less. 15.4.5.5 Transmit spectrum mask The transmitted spectral products shall be less than â€“30 dBr (decibel relative to the SINx/x peak) for fc â€“ 22 MHz < f < fc â€“11 MHz, fc +11 MHz < f < fc + 22 MHz, â€“50 dBr for f < fc â€“22 MHz, and f > fc + 22 MHz, where fc is the channel center frequency. The transmit spectral mask is shown in Figure 15-10. The measurements shall be made using 100 kHz resolution bandwidth and a 30 kHz video bandwidth. Figure 15-10â€”Transmit spectrum mask Channel 14 is unique. The Japanese standard ARIB RCR-STD 33 (5.0) [B7] states that B90/2 normalized to the â€˜transmission speed of modulation signalâ€™ shall be > 10, where B90 is the 90% occupied channel bandwidth. Therefore, for channel 14, B90/2 > 13.75 MHz for CCK spreading and >10.0 MHz for Barker spreading. 15.4.5.6 Transmit center frequency tolerance The transmitted center frequency tolerance shall be Â±25 ppm maximum. 15.4.5.7 Chip clock frequency tolerance The PN code chip clock frequency tolerance shall be Â±25 ppm maximum. 15.4.5.8 Transmit power-on and power-down ramp The transmit power-on ramp for 10% to 90% of maximum power shall be no greater than 2 Âµs. The transmit power-on ramp is shown in Figure 15-11. 2241 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Figure 15-11â€”Transmit power-on ramp The transmit power-down ramp for 90% to 10% maximum power shall be no greater than 2 Âµs. The transmit power-down ramp is shown in Figure 15-12. Figure 15-12â€”Transmit power-down ramp The transmit power ramps shall be constructed such that the DSSS PHY emissions comply with the spurious frequency product specification defined in 15.4.4.6. 15.4.5.9 RF carrier suppression The RF carrier suppression, measured at the channel center frequency, shall be at least 15 dB below the peak sin(x)/x power spectrum. The RF carrier suppression shall be measured while transmitting a repetitive 01 data sequence with the scrambler disabled using DQPSK modulation. A 100 kHz resolution bandwidth shall be used to perform this measurement. 2242 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 15.4.5.10 Transmit modulation accuracy The transmit modulation accuracy requirement for the DSSS PHY shall be based on the difference between the actual transmitted waveform and the ideal signal waveform. Modulation accuracy shall be determined by measuring the peak vector error magnitude measured during each chip period. Worst-case vector error magnitude shall not exceed 0.35 for the normalized sampled chip data. The ideal complex I and Q constellation points associated with DQPSK modulation (0.707, 0.707), (0.707, â€“0.707), (â€“0.707, 0.707), (â€“0.707, â€“0.707) shall be used as the reference. These measurements shall be from baseband I and Q sampled data after recovery through a reference receiver system. Figure 15-13 illustrates the ideal DQPSK constellation points and range of worst-case error specified for modulation accuracy. Figure 15-13â€”Modulation accuracy measurement example Error vector measurement requires a reference receiver capable of carrier lock. All measurements shall be made under carrier lock conditions. The distortion induced in the constellation by the reference receiver shall be calibrated and measured. The test data error vectors described below shall be corrected to compensate for the reference receiver distortion. The IEEE 802.11 vendor compatible radio shall provide an exposed TX chip clock, which shall be used to sample the I and Q outputs of the reference receiver. The measurement shall be made under the conditions of continuous DQPSK transmission using scrambled all 1s. The eye pattern of the I channel shall be used to determine the I and Q sampling point. The chip clock provided by the vendor radio shall be time delayed such that the samples fall at a 1/2 chip period offset from the mean of the zero crossing positions of the eye (see Figure 15-14). This is the ideal center of the eye and might not be the point of maximum eye opening. 2243 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Figure 15-14â€”Chip clock alignment with baseband eye pattern Using the aligned chip clock, 1000 samples of the I and Q baseband outputs from the reference receiver are captured. The vector error magnitudes shall be calculated as follows: Calculate the dc offsets for I and Q samples. 1000 I mean = I n 1000 n=1 1000 Q mean = Q n 1000 n=1 Calculate the dc corrected I and Q samples for all n =1000 sample pairs. Idc(n) = I(n) â€“ Imean Qdc(n) = Q(n) â€“ Qmean Calculate the average magnitude of I and Q samples. 1000 I mag = I dc n 1000 n=1 1000 Q mag = Q dc n 1000 n=1 Calculate the normalized error vector magnitude for the Idc(n)/Qdc(n) pairs. 2 2 1 2 V err(n) = I dc(n) â€“ I mag + Q dc(n) â€“ Q mag 2244 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications where the average power of the constellation is 1 NOTEâ€”A correction factor might be needed to compensate for the error induced by a test reference receiver system. For all n =1000 samples, the following condition shall be met: Verr(n) < 0.35 15.4.5.11 Time of Departure accuracy The Time of Departure accuracy test evaluates TIME_OF_DEPARTURE against aTxPHYTxStartRMS and aTxPHYTxStartRMS against TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH as defined Annex P with the following test parameters: â€” MULTICHANNEL_SAMPLING_RATE is 22 fH â€“ fL sample/s 10 6 1 + ------------------- 22 MHz where fH is the nominal center frequency in Hz of the highest channel in the channel set fL is the nominal center frequency in Hz of the lowest channel in the channel set, the channel set is the set of channels upon which frames providing measurements are transmitted, the channel set comprises channels uniformly spaced across fH â€“ fL 50 MHz â€” FIRST_TRANSITION_FIELD is the SYNC field. â€” SECOND_TRANSITION_FIELD is the SFD field. â€” TRAINING_FIELD is the concatenation of the SYNC and SFD fields, using a chip pulse that should approximate a rectangular pulse of duration 1/ 11 MHz convolved with a brick-wall low pass filter of bandwidth 11 MHz. â€” TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH is 80 ns. NOTEâ€”The indicated chip pulse applies to the time of departure accuracy test equipment, and not the transmitter or receiver. 15.4.6 PHY receiver specifications 15.4.6.1 Introduction The receive functions and parameters associated with the PHY sublayer are described in 15.4.6.2 to 15.4.6.5. 15.4.6.2 Receiver minimum input level sensitivity The FER shall be less than 8 10â€“2 at an MPDU length of 1024 octets for an input level of â€“80 dBm measured at the antenna connector. This FER shall be specified for 2 Mb/s DQPSK modulation. The test for the minimum input level sensitivity shall be conducted with the ED threshold set â€“80 dBm. 15.4.6.3 Receiver maximum input level The receiver shall provide a maximum FER of 8 10â€“2 at an MPDU length of 1024 octets for a maximum input level of â€“4 dBm measured at the antenna. This FER shall be specified for 2 Mb/s DQPSK modulation. 2245 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 15.4.6.4 Receiver adjacent channel rejection Adjacent channel rejection is defined between any two channels with 30 MHz separation in each channel group defined in 15.4.4.3. The adjacent channel rejection shall be 35 dB with an FER of 8 10â€“2 using 2 Mb/s DQPSK modulation described in 15.4.4.5 and an MPDU length of 1024 octets. The adjacent channel rejection shall be measured using the following method: Input a 2 Mb/s DQPSK modulated signal at a level 6 dB greater than specified in 15.4.6.2. In an adjacent channel ( 30 MHz separation as defined by the channel numbering), input a signal modulated in a similar fashion that adheres to the transmit mask specified in 15.4.5.5 to a level 41 dB above the level specified in 15.4.6.2. The adjacent channel signal shall be derived from a separate signal source. It shall not be a frequency shifted version of the reference channel. Under these conditions, the FER shall be less than or equal to 8 10â€“2. 15.4.6.5 CCA The DSSS PHY shall provide the capability to perform CCA according to both: A â€” at least one of the following options: â€” CCA Mode 1: Energy above threshold. CCA shall report a busy medium upon detection of any energy above the ED threshold. â€” CCA Mode 2: CS only. CCA shall report a busy medium only upon detection of a DSSS signal. This signal may be above or below the ED threshold. â€” CCA Mode 3: CS with energy above threshold. CCA shall report a busy medium upon detection of a DSSS signal with energy above the ED threshold. and B â€” CCA Mode 6: CCA shall report a busy medium upon detection of any energy above â€“62 dBm. A busy channel shall be indicated by issuing a PHY-CCA.indication(BUSY) primitive. A clear channel shall be indicated by issuing a PHY-CCA.indication(IDLE) primitive. The value of dot11CCAModeSupported shall indicate the appropriate operation modes. The PHY shall be configured according to dot11CurrentCCAMode. The CCA shall indicate a clear channel if there is no energy detect or CS. The CCA parameters are subject to the following criteria: a) The ED threshold shall be â€“80 dBm for TX power > 100 mW, â€“76 dBm for 50 mW < TX power 100 mW, and â€“70 dBm for TX power 50 mW. b) With a valid signal (according to the CCA mode of operation) present at the receiver antenna within 5 Âµs of the start of a MAC slot boundary, the PHY-CCA.indication(BUSY) primitive shall be generated before the end of the slot time. Refer to Figure 10-19 (in 10.3.7) and Figure 10-26 for a definition of slot boundary. c) In the event that a correct PHY header is received, the DSSS PHY shall not generate a PHY- CCA.indication (IDLE) primitive until the end of the PPDU as determined by TXTIME in 16.4.7. 2246 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Compliance to DSSS PHY CCA shall be demonstrated by applying a DSSS signal, above the appropriate ED threshold (item a), so that all conditions described in item b and item c are demonstrated. 15.4.6.6 Received Channel Power Indicator Measurement The RCPI is a measure of the received RF power in the selected channel for a received frame. This parameter shall be a measure by the PHY of the received RF power in the channel measured over the entire received frame or by other equivalent means that meet the specified accuracy. The encoding of received power to RCPI is defined in 9.4.2.38. RCPI shall equal the received RF power within an accuracy of Â±5 dB (95% confidence interval) within the specified dynamic range of the receiver. The received RF power shall be determined assuming a receiver noise equivalent bandwidth equal to the channel bandwidth multiplied by 1.1. 15.4.6.7 DSSS PHY TXTIME calculation The value of the TXTIME parameter returned by the PLME-TXTIME.confirm primitive shall be calculated according to the following equations: TXTIME = PreambleLength + PHYHeaderTime + LENGTH --------------------------------8- DATARATE where LENGTH and DATARATE are values from the TXVECTOR parameter of the corresponding PLME-TXTIME.request primitive LENGTH is in units of octets DATARATE is in units of Mb/s The value of PreambleLength is 144 s The value of PHYHeaderTime is 48 s. 2247 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 16. High rate direct sequence spread spectrum (HR/DSSS) PHY specification 16.1 Overview 16.1.1 General This clause specifies the high rate extension of the PHY for the DSSS system (see Clause 15), hereinafter known as the HR/DSSS PHY for the 2.4 GHz band designated for ISM applications. This extension of the DSSS system builds on the data rate capabilities, as described in Clause 15, to provide 5.5 Mb/s and 11 Mb/s payload data rates in addition to the 1 Mb/s and 2 Mb/s rates. To provide the higher rates, 8-chip complementary code keying (CCK) is employed as the modulation scheme. The chipping rate is 11 MHz, which is the same as the DSSS system described in Clause 15, thus providing the same occupied channel bandwidth. The basic new capability described in this clause is called HR/DSSS. One mode of the HR/DSSS PHY uses the same PHY preamble and header as the DSSS PHY, so both PHYs can co-exist in the same BSS and can use the rate switching mechanism as provided. In addition to providing higher speed extensions to the DSSS system, a number of optional features allow the performance of the RF LAN system to be improved as technology allows the implementation of these options to become cost effective. Another optional mode is provided that allows data throughput at the higher rates (2, 5.5, and 11 Mb/s) to be significantly increased by using a shorter PHY preamble. This mode is called HR/DSSS/short. This short preamble mode can coexist with DSSS, HR/DSSS under limited circumstances, such as on different channels or with appropriate CCA mechanisms. 16.1.2 Scope This clause specifies the PHY entity for the HR/DSSS extension and explains how this standard accommodates the HR/DSSS PHY. The HR/DSSS PHY consists of the following two protocol functions: a) A PHY function that defines a method for mapping the MPDUs into a framing format suitable for sending and receiving user data and management information between two or more STAs. The PHY exchanges PPDUs that contain PSDUs. The MAC uses the PHY service, so each MPDU corresponds to a PSDU that is carried in a PPDU. b) A function that defines the characteristics of, and method of transmitting and receiving data through, a WM between two or more STAs, each using the HR/DSSS PHY system. 16.1.3 HR/DSSS PHY functions 16.1.3.1 General The HR/DSSS PHY contains two functional entities: the PHY function and the layer management function. Each of these functions is described in detail in 16.2 and 16.3. The HR/DSSS PHY service shall be provided to the MAC through the PHY service primitives described in Clause 8. 2248 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 16.1.3.2 PLME The PLME performs management of the local PHY functions in conjunction with the MLME. 16.1.4 Service specification method and notation The models represented by figures and state diagrams are intended to be illustrations of functions provided. It is important to distinguish between a model and a real implementation. The models are optimized for simplicity and clarity of presentation, but do not necessarily reflect any particular implementation. The service of a layer or sublayer is a set of capabilities that it offers to a user in the next-higher layer (or sublayer). Abstract services are specified here by describing the service primitives and parameters that characterize each service. This definition is independent of any particular implementation. 16.2 HR/DSSS PHY 16.2.1 Overview Subclause 16.2 provides a convergence procedure for the 2 Mb/s, 5.5 Mb/s, and 11 Mb/s specification, in which PSDUs are converted to and from PPDUs. During transmission, the PSDU shall be appended to a PHY preamble and header to create the PPDU. Two different preambles and headers are defined: the mandatory supported long preamble and header, which interoperates with the current 1 Mb/s and 2 Mb/s DSSS specification, and an optional short preamble and header. At the receiver, the PHY preamble and header are processed to aid in demodulation and delivery of the PSDU. The optional short preamble and header provides maximum throughput when interoperability with legacy and nonshort-preamble-capable STAs is not a consideration. That is, it is expected to be used only in networks of STAs that support the optional mode. 16.2.2 PPDU format 16.2.2.1 General Two different preambles and headers are defined: the mandatory supported long preamble and header, which is interoperable with the current 1 Mb/s and 2 Mb/s DSSS specification, and an optional short preamble and header. 16.2.2.2 Long PPDU format Figure 16-1 shows the format for the interoperable (long) PPDU, including the HR/DSSS PHY preamble, the HR/DSSS PHY header, and the PSDU. The PHY preamble contains the following fields: SYNC and SFD. The PHY header contains the following fields: signaling (SIGNAL), service (SERVICE), length (LENGTH), and CRC-16. Each of these fields is described in detail in 16.2.3. The format for the PPDU, including the long HR/DSSS PHY preamble, the long HR/DSSS PHY header, and the PSDU, does not differ from the format for 1 Mb/s and 2 Mb/s. The only exceptions are: a) The encoding of the rate in the SIGNAL field; b) The use of a bit in the SERVICE field to resolve an ambiguity in PSDU length in octets, when the length is expressed in whole microseconds; c) The use of a bit in the SERVICE field to indicate that the transit frequency and bit clocks are locked. 2249 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Scrambled 1s SYNC SFD SIGNAL SERVICE LENGTH CRC 1 Mb/s DBPSK 128 bits 16 bits 8 bits 8 bits 16 bits 16 bits PHY Preamble PHY Header PSDU 144 bits 48 bits 192 s 1 DBPSK PPDU 2 DQPSK 5.5 or 11 Mb/s Figure 16-1â€”Long PPDU format 16.2.2.3 Short PPDU format The short PHY preamble and header (HR/DSSS/short) is optional. The short preamble and header may be used to minimize overhead and, thus, maximize the network data throughput. The format of the PPDU, with HR/DSSS/short, is depicted in Figure 16-2. A Clause 18 STA shall support the short PPDU format. Scrambled 0s Backward SFD shortSYNC shortSFD 56 bits 16 bits DBPSK SIGNAL SERVICE LENGTH CRC 8 bits 8 bits 16 bits 16 bits 2 Mb/s Short PHY Preamble Short PHY Header PSDU 72 bits at 1 Mb/s 48 bits at 2 Mb/s Variable at 2, 5.5, or 11 Mb/s 96 s PPDU Figure 16-2â€”Short PPDU format A transmitter using the short PPDU is interoperable with only another receiver that is also capable of receiving this short PPDU. To interoperate with a receiver that is not capable of receiving a short preamble and header, the transmitter shall use the long PHY preamble and header. The short PHY preamble uses the 1 Mb/s Barker code spreading with DBPSK modulation. The short PHY header uses the 2 Mb/s Barker code spreading with DQPSK modulation, and the PSDU is transmitted at 2 Mb/s, 5.5 Mb/s, or 11 Mb/s. 2250 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 16.2.3 PPDU field definitions 16.2.3.1 General In the PHY field definition subclauses (16.2.3.2 to 16.2.3.15), the definitions of the long (Clause 15) PHY fields are given first, followed by the definitions of the short PHY fields. The names for the short PHY fields are preceded by the term short. 16.2.3.2 Long PHY SYNC field The SYNC field shall consist of 128 bits of scrambled 1 bits. This field is provided so the receiver can perform the necessary synchronization operations. The initial state of the scrambler (seed) shall be [1101100], where the leftmost bit specifies the value to put in the first delay element (Z1) in Figure 16-5 (in 16.2.4), and the rightmost bit specifies the value to put in the last delay element in the scrambler. To support the reception of DSSS signals generated with implementations based on Clause 15, the receiver shall also be capable of synchronization on a SYNC field derived from any nonzero scrambler initial state. 16.2.3.3 Long PHY SFD The SFD shall be provided to indicate the start of PHY-dependent parameters within the PHY preamble. The SFD shall be a 16-bit field, [1111 0011 1010 0000], where the rightmost bit shall be transmitted first in time. 16.2.3.4 Long PHY SIGNAL field The 8-bit SIGNAL field indicates to the PHY the modulation that shall be used for transmission (and reception) of the PSDU. The data rate shall be equal to the SIGNAL field value multiplied by 100 kb/s. The high rate PHY supports four mandatory rates given by the following 8-bit words, which represent the rate in units of 100 kb/s, where the LSB shall be transmitted first in time: a) Xâ€™0Aâ€™ (MSB to LSB) for 1 Mb/s; b) Xâ€™14â€™ (MSB to LSB) for 2 Mb/s; c) Xâ€™37â€™ (MSB to LSB) for 5.5 Mb/s; d) Xâ€™6Eâ€™ (MSB to LSB) for 11 Mb/s. The HR/DSSS PHY rate change capability is described in 16.2.3.15. This field shall be protected by the CRC-16 FCS described in 16.2.3.7. 16.2.3.5 Long PHY SERVICE field Two bits have been defined in the SERVICE field to support the high rate extension; see Table 16-1. The rightmost bit (bit 7) shall be used to supplement the LENGTH field described in 16.2.3.6. Bit 2 shall be used to indicate that the transmit frequency and symbol clocks are derived from the same oscillator. This locked clocks bit shall be set by the PHY based on its implementation configuration. The SERVICE field shall be transmitted B0 first in time, and shall be protected by the CRC-16 FCS described in 16.2.3.7. B0, B1, B3, B4, B5, and B6 are reserved and shall be set to 0 on transmission and ignored on reception. Table 16-1â€”SERVICE field definitions B0 B1 B2 B3 B4 B5 B6 B7 Reserved Reserved Locked clocks bit Reserved Reserved Reserved Reserved Length 0 = not locked extension 1 = locked bit 2251 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 16.2.3.6 Long PHY LENGTH field The PHY LENGTH field shall contain an unsigned 16-bit integer that indicates the number of microseconds required to transmit the PSDU. The transmitted value shall be determined from the LENGTH and DATARATE parameters in the TXVECTOR issued with the PHY-TXSTART.request primitive described in 16.3.5. The LENGTH field provided in the TXVECTOR is in octets and is converted to microseconds for inclusion in the PHY LENGTH field. The LENGTH field is calculated as follows. Because there is an ambiguity in the number of octets that is described by a length in integer microseconds for any data rate over 8 Mb/s, a length extension bit is present in the SERVICE field to indicate when the smaller potential number of octets is correct as follows: 8 â€” 5.5 Mb/s CCK LENGTH = number of octets ------- . 5.5 8- â€” 11 Mb/s CCK LENGTH = ----- number of octets ; the length extension bit shall be set to 0 11 if (LENGTH â€“ (number of octets 8/11)) < 8/11 and shall be set to 1 otherwise. The length extension bit is reserved when the data rate is not 11 Mb/s. At the receiver, the number of octets in the MPDU is calculated as follows: 5.5 â€” 5.5 Mb/s CCK number of octets = LENGTH ------- . 8 11 â€” 11 Mb/s CCK number of octets = LENGTH ------ , minus 1 if the length extension bit is a 1. 8 An example for an 11 Mb/s calculation described in pseudocode form is shown below. At the transmitter, the values of the LENGTH field and length extension bit are calculated as follows: LENGTH' = (number of octets 8) / R LENGTH = LENGTH' If (R = 11) and ((LENGTHâ€“LENGTH') 8/11) then length extension = 1 else length extension = 0 where R is the data rate (Mb/s) 2252 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications At the receiver, the number of octets in the MPDU is calculated as follows: number of octets = LENGTH R â€“ length extension ---------------------------------- 8 where R is the data rate (Mb/s) Table 16-2 shows an example calculation for several packet lengths of CCK at 11 Mb/s. Table 16-2â€”Example of LENGTH calculations for CCK Octets 8 Length LENGTH 11 LENGTH 11 TX octets ------------------------- LENGTH extension -------------------------------------- -------------------------------------- RX octets 11 bit 8 8 1023 744 744 0 1023 1023 1023 1024 744.7273 745 0 1024.375 1024 1024 1025 745.4545 746 0 1025.75 1025 1025 1026 746.1818 747 1 1027.125 1027 1026 This example illustrates why normal rounding or truncation of the number does produce the right result. The LENGTH field is defined in units of microseconds and corresponds to the actual length, and the number of octets is exact. The LSB shall be transmitted first in time. This field shall be protected by the CRC-16 FCS described in 16.2.3.7. 16.2.3.7 PHY CRC (CRC-16) field The SIGNAL, SERVICE, and LENGTH fields shall be protected with a CRC-16 FCS. The CRC-16 FCS shall be the 1s complement of the remainder generated by the modulo 2 division of the protected PHY fields by the polynomial 16 12 5 x +x +x +1 The protected bits shall be processed in transmit order. All FCS calculations shall be made prior to data scrambling. A schematic of the processing is shown in Figure 16-3. As an example, the SIGNAL, SERVICE, and LENGTH fields for a DBPSK signal with a PPDU length of 192 s (24 octets) would be given by the following: 0101 0000 0000 0000 0000 0011 0000 0000 [leftmost bit (B0) transmitted first in time] B0.................................................................B48 The 1s complement FCS for these protected PHY preamble bits would be the following: 0101 1011 0101 0111 [leftmost bit (B0) transmitted first in time] B0.........................B16 2253 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Figure 16-3 depicts this example. TRANSMIT AND RECEIVE PHY HEADER CRC-16 CALCULATOR SERIAL DATA SERIAL DATA INPUT CRC-16 OUTPUT PRESET TO 1S 1. Preset to all 1s 2. Shift signal, service length fields through the shift register 3. Take 1s complement of the remainder 4. Transmit out serial X15 first CRC-16 POLYNOMIAL: G(x) = X16 + X12 + X5 + 1 SERIAL DATA INPUT + X15 X14 X13 X12 + X11 X10 X9 X8 X7 X6 X5 + X4 X3 X2 X1 X0 SERIAL DATA OUTPUT 1S COMPLEMENT (X15 FIRST) Figure 16-3â€”CRC-16 implementation 2254 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications An illustrative example of the CRC-16 FCS using the information from Figure 16-3 is shown in Figure 16-4. Data CRC Registers MSB LSB 1111111111111111 ; Initialize preset to 1s 0 1110111111011111 1 1101111110111110 0 1010111101011101 1 0101111010111010 0 1011110101110100 0 0110101011001001 0 1101010110010010 0 1011101100000101 0 0110011000101011 0 1100110001010110 0 1000100010001101 0 0000000100111011 0 0000001001110110 0 0000010011101100 0 0000100111011000 0 0001001110110000 0 0010011101100000 0 0100111011000000 0 1001110110000000 0 0010101100100001 0 0101011001000010 0 1010110010000100 1 0101100100001000 1 1010001000110001 0 0101010001000011 0 1010100010000110 0 0100000100101101 0 1000001001011010 0 0001010010010101 0 0010100100101010 0 0101001001010100 0 1010010010101000 0101101101010111 ; 1s complement, result = CRC FCS parity Figure 16-4â€”Example of CRC calculation 16.2.3.8 Long PHY data modulation and modulation rate change The long PHY preamble and header shall be transmitted using the 1 Mb/s DBPSK modulation. The SIGNAL field indicates the rate that is used to transmit the PSDU. The transmitter and receiver shall initiate the rate indicated by the SIGNAL field, starting with the first octet of the PSDU. The PSDU transmission rate shall be set by the DATARATE parameter in the TXVECTOR, issued with the PHY- TXSTART.request primitive described in 16.3.5. 16.2.3.9 Short PHY synchronization (shortSYNC) The shortSYNC field shall consist of 56 bits of scrambled 0 bits. This field is provided so the receiver can perform the necessary synchronization operations. The initial state of the scrambler (seed) shall be [001 1011], where the left end bit specifies the value to place in the first delay element (Z1) in Figure 16-5 (in 16.2.4), and the right end bit specifies the value to place in the last delay element (Z7). 16.2.3.10 Short PHY SFD field (shortSFD) The shortSFD shall be a 16-bit field and be the time reverse of the field of the SFD in the long PHY preamble (16.2.3.3). The field is the bit pattern 0000 0101 1100 1111. The right end bit shall be transmitted first in time. A receiver not configured to use the short header option does not detect this SFD. 2255 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 16.2.3.11 Short PHY SIGNAL field (shortSIGNAL) The 8-bit SIGNAL field of the short header indicates to the PHY the data rate that shall be used for transmission (and reception) of the PSDU. A PHY operating with the HR/DSSS/short option supports three mandatory rates given by the following 8-bit words, where the LSB shall be transmitted first in time and the number represents the rate in units of 100 kb/s: a) Xâ€™14â€™ (MSB to LSB) for 2 Mb/s; b) Xâ€™37â€™(MSB to LSB) for 5.5 Mb/s; c) Xâ€™6Eâ€™ (MSB to LSB) for 11 Mb/s. 16.2.3.12 Short PHY SERVICE field (shortSERVICE) The SERVICE field in the short header shall be the same as the SERVICE field described in 16.2.3.5. 16.2.3.13 Short PHY LENGTH field (shortLENGTH) The LENGTH field in the short header shall be the same as the LENGTH field described in 16.2.3.6. 16.2.3.14 Short CRC-16 field (shortCRC) The CRC in the short header shall be the same as the CRC field defined in 16.2.3.7. The CRC-16 is calculated over the shortSIGNAL, shortSERVICE, and shortLENGTH fields. 16.2.3.15 Short PHY data modulation and modulation rate change The short PHY preamble shall be transmitted using the 1 Mb/s DBPSK modulation. The short PHY header shall be transmitted using the 2 Mb/s modulation. The SIGNAL field indicates the rate that is used to transmit the PSDU. The transmitter and receiver shall initiate the rate indicated by the SIGNAL field, starting with the first octet of the PSDU. The PSDU transmission rate shall be set by the DATARATE parameter in the TXVECTOR, issued with the PHY-TXSTART.request primitive described in 16.3.5. 16.2.4 PHY/HR/DSSS PHY data scrambler and descrambler The polynomial G(z) = z â€“7 + z â€“4 + 1 shall be used to scramble all bits transmitted. The feedthrough configuration of the scrambler and descrambler is self-synchronizing, which requires no prior knowledge of the transmitter initialization of the scrambler for receive processing. Figure 16-5 and Figure 16-6 show typical implementations of the data scrambler and descrambler, but other implementations are possible. SCRAMBLER POLYNOMIAL: G(z) = Z-7 +Z-4 +1 SERIAL DATA OUTPUT SERIAL DATA INPUT Z 1 Z2 Z 3 Z 4 Z 5 Z 6 Z7 Figure 16-5â€”Data scrambler 2256 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DESCRAMBLER POLYNOMIAL: G(z) = Z-7 +Z-4 +1 SERIAL DATA INPUT Z 1 Z 2 Z 3 Z4 Z 5 Z6 Z 7 SERIAL DATA OUTPUT Figure 16-6â€”Data descrambler The scrambler shall be initialized as specified in 16.2.3.9 for the short PPDU format and 16.2.3.2 for the long PPDU format. For a long preamble, this shall result in the scrambler registers Z1 to Z7 in Figure 16-5 having the data pattern [1101100] (i.e., Z1= 1... Z7= 0) when the scrambler is first started. The scrambler shall be initialized with the reverse pattern [0011011] when transmitting the optional short preamble. 16.2.5 Transmit PHY The transmit procedures for a HR/DSSS PHY using the long PPDU format are the same as the transmit procedures described in 15.3.6 and 15.3.7 and do not change apart from the ability to transmit 5.5 Mb/s and 11 Mb/s. The procedures for a transmitter employing HR/DSSS/short are the same except for length and rate changes. The decision to use the long or short PPDU format is beyond the scope of this standard. The transmit PHY is shown in Figure 16-7. A PHY-TXSTART.request(TXVECTOR) primitive is issued by the MAC to start the transmission of a PPDU. In addition to parameters DATARATE and LENGTH, other transmit parameters such as PREAMBLE_TYPE are set via the PHY SAP with the PHY-TXSTART.request(TXVECTOR) primitive, as described in 16.3.5. The SIGNAL, SERVICE, and LENGTH fields of the PHY header are calculated as described in 16.2.3. The PHY is configured with the TXVECTOR elements TX_ANTENNA, DATARATE, and TXPWR_LEVEL_INDEX. The PHY entity shall immediately initiate data scrambling and transmission of the PHY preamble based on the parameters passed in the PHY-TXSTART.request primitive. The time required for transmit power-on ramp, described in 16.3.7.7, shall be included in the PHY SYNC field. Once the PHY preamble transmission is complete, data shall be exchanged between the MAC and the PHY by a series of PHY-DATA.request(DATA) primitives issued by the MAC and PHY-DATA.confirm primitives issued by the PHY. The modulation and rate change, if any, shall be initiated with the first data symbol of the PSDU, as described in 16.2.3.8 and 16.2.3.15. The PHY proceeds with PSDU transmission through a series of data octet transfers from the MAC. Transmission can be prematurely terminated by the MAC through the PHY-TXEND.request primitive. PHY-TXSTART shall be disabled by the issuance of the PHY-TXEND.request primitive. Normal termination occurs after the transmission of the final bit of the last PSDU octet, calculated from the number supplied in the PHY preamble LENGTH and SERVICE fields using the equations specified in 16.2.3.6. The PPDU transmission shall be completed and the PHY entity shall enter the receive state (i.e., PHY-TXSTART shall be disabled). It is recommended that modulation 2257 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications continue during power-down to prevent radiating a continuous wave carrier. Each PHY-TXEND.request primitive is acknowledged with a PHY-TXEND.confirm primitive from the PHY. MAC PHY PHY-TXSTART.request (TXVECTOR) TX Power RAMP on Scramble Start SYNC PHY-TXSTART.confirm (TXSTATUS) PHY-DATA.request SFD CRC-16 Start SIGNAL, SERVICE Time LENGTH CRC-16 End CRC PHY-DATA.confirm PSDU ......... PHY-TXEND.request TX Power RAMP Off PHY-TXEND.confirm Figure 16-7â€”Transmit PHY 16.2.6 Receive PHY The receive procedures for receivers configured to receive the mandatory and optional PHYs, rates, and modulations are described in this subclause. A receiver that supports this high rate extension of the standard is capable of receiving 5.5 Mb/s and 11 Mb/s, in addition to 1 Mb/s and 2 Mb/s. If the PHY implements the short preamble option, it shall detect both short and long preamble formats and indicate which type of preamble was received in the RXVECTOR. The receiver shall implement the CCA procedure as defined in 16.3.8.5. Upon receiving a PPDU, the receiver shall distinguish between a long and short 2258 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications header format by the value of the SFD, as specified in 16.2.2. The receiver shall demodulate a long PHY header using BPSK at 1 Mb/s. The receiver shall demodulate a short PHY header using QPSK at 2 Mb/s. The receiver shall use the SIGNAL and SERVICE fields of the PHY header to determine the data rate and modulation of the PSDU. The receive PHY is shown in Figure 16-8. In order to receive data, the PHY-TXSTART.request primitive shall be disabled so that the PHY entity is in the receive state. Further, through station management via the PLME, the PHY shall be set to the appropriate channel and the CCA method chosen. Other receive parameters, such as RSSI, RCPI, SQ, and indicated DATARATE, may be accessed via the PHY SAP. MAC PHY PHY-CCA.indication(BUSY) Descrambler Start Time SYNC SFD Rate Change Start CRC Start SIGNAL, SERVICE LENGTH CRC End CRC PHY-RXSTART.indication Modulation and Rate (RXVECTOR) Change Start PHY-DATA.indication(DATA) PSDU PHY-RXEND.indication (RXERROR,RXVECTOR)/ PHY-CCA.indication(IDLE) Figure 16-8â€”Receive PHY Upon receiving the transmitted energy, according to the selected CCA mode a PHY-CCA.indication(BUSY) primitive shall be issued for ED and/or code lock prior to correct reception of the PHY header. The PHY measures the SQ, RSSI, and RCPI parameters and these are reported to the MAC in the RXVECTOR. After a PHY-CCA.indication primitive is issued, the PHY entity shall begin searching for the SFD field. Once the SFD field is detected, CRC-16 processing shall be initiated and the PHY SIGNAL, SERVICE, and LENGTH fields shall be received. The CRC-16 FCS shall be processed. If the CRC-16 FCS check fails, the 2259 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications PHY receiver shall return to the RX IDLE state, as depicted in Figure 16-9. Should the status of CCA return to the IDLE state during reception prior to completion of the full PPDU processing, the PHY receiver shall return to the RX IDLE state. If the PHY header reception is successful (and the SIGNAL field is completely recognizable and supported), a PHY-RXSTART.indication(RXVECTOR) primitive shall be issued. The RXVECTOR associated with this primitive includes: a) The SIGNAL field b) The SERVICE field c) The PSDU length in octets (calculated from the LENGTH field in microseconds and the DATARATE in Mb/s, in accordance with the formula in 16.2.3.6) d) RXPREAMBLE_TYPE (which is an enumerated type taking on values SHORTPREAMBLE or LONGPREAMBLE) e) ANT_STATE (the antenna used for receive), RSSI, RCPI, and SQ If dot11TimingMsmtActivated is true, the PHY shall do the following: â€” Complete receiving the PHY header and verify the validity of the PHY Header. â€” If the PHY header reception is successful (and the SIGNAL field is completely recognizable and supported), a PHY-RXSTART.indication(RXVECTOR) primitive shall be issued and RX_START_OF_FRAME_OFFSET parameter within the RXVECTOR shall be forwarded (see 16.3.5). NOTEâ€”The RX_START_OF_FRAME_OFFSET value is used as described in 6.3.57 in order to estimate when the start of the preamble for the incoming frame was detected on the medium at the receive antenna connector. The received PSDU bits are assembled into octets and presented to the MAC using a series of PHY- DATA.indication(DATA) primitive exchanges. The rate and modulation change indicated in the SIGNAL field shall be initiated with the first symbol of the PSDU, as described in 16.2.5. The PHY proceeds with PSDU reception. After reception of the final bit of the last PSDU octet, as indicated by the PHY preamble LENGTH field, the receiver shall be returned to the RX IDLE state shown in Figure 16-9. A PHY-RXEND.indication(NoError) primitive shall be issued. A PHY-CCA.indication(IDLE) primitive shall be issued following a change in PHYCS and/or PHYED according to the selected CCA method. In the event that a change in PHYCS or PHYED would cause the status of CCA to return to the IDLE state before the complete reception of the PSDU, as indicated by the PHY LENGTH field, the error condition shall be reported to the MAC using a PHY-RXEND.indication(CarrierLost) primitive. The CCA of the HR/ DSSS PHY shall indicate a busy medium for the intended duration of the transmitted PPDU. If the PHY header is successful, but the indicated rate or modulation in the SIGNAL and SERVICE fields is not within the capabilities of the receiver, a PHY-RXSTART.indication primitive shall not be issued. The PHY shall indicate the error condition by issuing a PHY-RXEND.indication(UnsupportedRate) primitive. If the PHY header is invalid, a PHY-RXSTART.indication primitive shall not be issued, and the PHY shall indicate the error condition using a PHY-RXEND.indication(FormatViolation) primitive. Also, in both cases, the CCA of the HR/DSSS PHY shall indicate a busy medium for the intended duration of the transmitted PSDU, as indicated by the LENGTH field. The intended duration is indicated by the LENGTH field (LENGTH 1 s). A typical state machine implementation of the receive PHY is shown in Figure 16-9. 2260 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications RESET RX IDLE state perform CS/CCA RX SYMBOL PHY-DATA.indication DETECT SYNC PATTERN CCA(IDLE) CCA(BUSY) Wait Until SFD is Detected SIGNAL NOT VALID DECREMENT LENGTH PHY-CCA PHY-RXEND.indication Decrement count .indication (IDLE) (carrier lost) by 1 s SET RXPHY FIELDS RX 8 bit SIGNAL DECREMENT TIME OCTET ASSIMILATION RX 8 bit SERVICE PHY-CCA Wait for Intended Increment Bit Count RX 16 bit LENGTH .indication End of PSDU Set Octet Bit Count Length â‰ 0 (IDLE) PHY-DATA.indication (DATA) Time = 0 PHY-CCA Length = 0 .indication RX PHY CRC (IDLE) or END OF WAIT END OF PSDU RX RX and Test CRC CRC FAIL PHY-RXEND.indication PHY-CCA.indication (IDLE) (No_Error) PHY-CCA.indication PHY-CCA.indication Length = 0 (IDLE) CRC Correct (IDLE) DECREMENT LENGTH VALIDATE PPDU Decrement Check PPDU Length Count PPDU Correct PHY field Out of Spec SETUP PSDU RX Set RATE Set Length Count Set Octet Bit Count PHY-RXSTART.indication (RXVECTOR) Figure 16-9â€”PHY receive state machine 16.3 HR/DSSS PLME 16.3.1 PLME SAP sublayer management primitives Table 16-3 lists the MIB attributes that may be accessed by the PHY entities and intralayer or higher level LMEs. These attributes are accessed via the PLME-GET, PLME-SET, and PLME-RESET primitives defined in Clause 6. 16.3.2 HR/DSSS PHY MIB All HR/DSSS PHY MIB attributes are defined in Annex C, with specific values defined in Table 16-3. 2261 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 16-3â€”MIB attribute default values/ranges Operational Managed object Default value/range semantics dot11PhyOperationTable dot11PHYType High rateâ€“2.4 (Xâ€˜05â€™) Static dot11CurrentRegDomain Implementation dependent Static dot11PhyHRDSSSEntryTable dot11ShortPreambleOptionImplemented Implementation dependent Static dot11PhyAntennaTable dot11CurrentTxAntenna Implementation dependent Dynamic dot11DiversitySupportImplemented Implementation dependent Static dot11CurrentRxAntenna Implementation dependent Dynamic dot11PhyTxPowerTable dot11NumberSupportedPowerLevelsImplemented Implementation dependent Static dot11TxPowerLevel1 Implementation dependent Static dot11TxPowerLevel2 Implementation dependent Static dot11TxPowerLevel3 Implementation dependent Static dot11TxPowerLevel4 Implementation dependent Static dot11TxPowerLevel5 Implementation dependent Static dot11TxPowerLevel6 Implementation dependent Static dot11TxPowerLevel7 Implementation dependent Static dot11TxPowerLevel8 Implementation dependent Static dot11CurrentTxPowerLevel Implementation dependent Dynamic dot11PhyDSSSTable dot11CurrentChannel Implementation dependent Dynamic dot11HRCCAModeSupported Implementation dependent Static dot11CurrentCCAMode Implementation dependent Dynamic dot11EDThreshold Implementation dependent Dynamic dot11AntennasListTable dot11SupportedTxAntenna Implementation dependent Static dot11SupportedRxAntenna Implementation dependent Static dot11DiversitySelectionRxImplemented Implementation dependent Dynamic dot11RegDomainsSupportedTable dot11RegDomainsImplementedValue Implementation dependent Static dot11SupportedDataRatesTx Table Tx Xâ€™02â€™, Xâ€™04â€™, Xâ€™0Bâ€™, Xâ€™16â€™ Static dot11SupportedDataRatesRx Table Rx Xâ€™02â€™, Xâ€™04â€™, 'Xâ€™0Bâ€™, Xâ€™16â€™ Static NOTEâ€”The column titled â€œOperational semanticsâ€ contains two types: static and dynamic. Static MIB attributes are fixed and cannot be modified for a given PHY implementation. Dynamic MIB attributes can be modified by some management entities. 2262 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 16.3.3 HR/DSSS PHY The static HR/DSSS PHY characteristics, provided through the PLME-CHARACTERISTICS service primitive, are shown in Table 16-4. The definitions of these characteristics are in 6.5.4. Table 16-4â€”HR/DSSS PHY characteristics Characteristic Value aSlotTime If dot11OperatingClassesRequired is false, 20 Âµs If dot11OperatingClassesRequired is true, 20 Âµs plus any coverage-class- dependent aAirPropagationTime (see Table 9-79) aSIFSTime 10 s aCCATime Implementation dependent, see 10.3.7. aRxPHYStartDelay 192 s for long preamble and 96 s for short preamble aRxTxTurnaroundTime Implementation dependent, see 10.3.7. aTxPHYDelay Implementation dependent, see 10.3.7. aRxPHYDelay Implementation dependent, see 10.3.7. aRxTxSwitchTime Implementation dependent, see 10.3.7. aTxRampOnTime Implementation dependent, see 10.3.7. aAirPropagationTime As indicated by the coverage class (see 10.21.5). aMACProcessingDelay Implementation dependent, see 10.3.7. aPreambleLength 72 s aPHYHeaderLength 24 s aPSDUMaxLength 212 â€“ 1 octets aCWmin 31 aCWmax 1023 16.3.4 HR/DSSS TXTIME calculation The value of the TXTIME parameter returned by the PLME-TXTIME.confirm primitive shall be calculated according to the following equation: TXTIME = PreambleLength + PHYHeaderTime + LENGTH 8 --------------------------------- DATARATE where LENGTH and DATARATE are values from the TXVECTOR parameter of the corresponding PLME-TXTIME.request primitive LENGTH is in units of octets DATARATE is in units of Mb/s The value of PreambleLength is 144 s if the TXPREAMBLE_TYPE value from the TXVECTOR parameter indicates â€œLONGPREAMBLE,â€ or 72 s if the TXPREAMBLE_TYPE value from the TXVECTOR parameter indicates â€œSHORTPREAMBLEâ€ 2263 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The value of PHYHeaderTime is 48 s if the TXPREAMBLE_TYPE value from the TXVECTOR parameter indicates â€œLONGPREAMBLE,â€ or 24 s if the TXPREAMBLE_TYPE value from the TXVECTOR parameter indicates â€œSHORTPREAMBLEâ€ 16.3.5 Vector descriptions Several service primitives include a parameter vector. These vectors are a list of parameters as described in Table 16-5. DATARATE and LENGTH are described in 8.3.4.4. The remaining parameters are considered to be management parameters and are specific to this PHY. Table 16-5â€”Parameter vectors Parameter Associated vector Value DATARATE RXVECTOR, The rate used to transmit the PSDU in Mb/s. TXVECTOR LENGTH RXVECTOR, The length of the PSDU in octets. TXVECTOR PREAMBLE_TYPE RXVECTOR, The preamble used for the transmission of this PPDU. This TXVECTOR is an enumerated type that takes the value SHORTPREAMBLE or LONGPREAMBLE. ANT_STATE RXVECTOR 1â€“256 TX_ANTENNA TXVECTOR Selects which of the available antennas should be used for transmit, in the range 1 to 256. RSSI RXVECTOR 0â€“8 bits of RSSI RCPI RXVECTOR 0â€“255 (see NOTE) SQ RXVECTOR 0â€“8 bits of SQ TIME_OF_DEPAR- TXVECTOR false, true. When true, the MAC entity requests that the TURE_REQUESTED PHY entity measures and reports time of departure parameters corresponding to the time when the first frame energy is sent by the transmitting port; when false, the MAC entity requests that the PHY entity neither measures nor reports time of departure parameters. TIME_OF_DEPARTURE TXSTATUS 0 to 232â€“ 1. The time when the first frame energy is sent by the transmitting port, measured by the local PHY entity, in units equal to 1/TIME_OF_DEPARTURE_ClockRate. This parameter is present only if TIME_OF_DEPARTURE_REQUESTED is true in the corresponding request. TIME_OF_DEPARTURE_- TXSTATUS 0 to 216â€“ 1. The clock rate, in units of MHz, is used to ClockRate generate the TIME_OF_DEPARTURE value. This parameter is present only if TIME_OF_DEPARTURE_REQUESTED is true in the corresponding request. TX_START_OF_- TXSTATUS 0 to 232â€“ 1. An estimate of the offset (in 10 ns units) from FRAME_OFFSET the point in time at which the start of the preamble corresponding to the frame was transmitted at the transmit antenna connector to the point in time at which this primitive is issued to the MAC. 2264 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 16-5â€”Parameter vectors (continued) Parameter Associated vector Value RX_START_OF_- RXVECTOR 0 to 232â€“ 1. An estimate of the offset (in 10 ns units) from FRAME_OFFSET the point in time at which the start of the preamble corre- sponding to the incoming frame arrived at the receive antenna connector to the point in time at which this primi- tive is issued to the MAC. NOTEâ€”RCPI is present only when dot11RadioMeasurementActivated is true. 16.3.6 PHY operating specifications, general 16.3.6.1 General General specifications for the HR/DSSS PHY sublayer are provided in 16.3.6.2 to 16.3.6.11. These specifications apply to both the receive and transmit functions and general operation of a HR/DSSS PHY. WLANs implemented in accordance with this standard are subject to equipment certification and operation requirements established by regional and national regulatory administrations. The PHY specification establishes minimum technical requirements for interoperability, based upon established regulations at the time this standard was issued. These regulations are subject to revision, or may be superseded. Requirements that are subject to local geographic regulations are annotated within the PHY specification. Regulatory requirements that do not affect interoperability are not addressed in this standard. Implementers are referred to the following regulatory sources for further information. Operation in countries within defined regulatory domains may be subject to additional regulations. 16.3.6.2 Operating frequency range The HR/DSSS PHY shall operate in the 2.4â€“2.4835 GHz frequency range, as allocated by regulatory bodies in the China, United States, Europe, and Japan, or in the 2.471â€“2.497 GHz frequency range, as allocated by regulatory authority in Japan. 16.3.6.3 Channel Numbering of operating channels When dot11OperatingClassesRequired is true, channel numbering shall be as specified in 17.3.8.4.2 and channelization shall be as specified in 17.3.8.4.3. When dot11OperatingClassesDefined is false or not defined, the channel center frequencies and CHNL_ID numbers shall be as shown in Table 16-6. Table 16-6â€”HR/DSSS PHY frequency channel plan Frequency CHNL_ID (MHz) 1 2412 2 2417 3 2422 4 2427 5 2432 6 2437 7 2442 2265 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 16-6â€”HR/DSSS PHY frequency channel plan (continued) Frequency CHNL_ID (MHz) 8 2447 9 2452 10 2457 11 2462 12 2467 13 2472 14 2484 In a multiple cell network topology, overlapping and/or adjacent cells using different channels can operate simultaneously without interference if the distance between the center frequencies is at least 25 MHz. Channel 14 shall be designated specifically for operation in Japan. 16.3.6.4 Modulation and channel data rates Four modulation formats and data rates are specified for the HR/DSSS PHY. The basic access rate shall be based on 1 Mb/s DBPSK modulation. The enhanced access rate shall be based on 2 Mb/s DQPSK. The extended direct sequence specification defines two additional data rates. The HR/DSSS access rates shall be based on the CCK modulation scheme for 5.5 Mb/s and 11 Mb/s. 16.3.6.5 Spreading sequence and modulation for 1 Mb/s and 2 Mb/s The following 11-chip Barker sequence shall be used as the PN code sequence for the 1 Mb/s and 2 Mb/s modulation: +1, â€“1, +1, +1, â€“1, +1, +1, +1, â€“1, â€“1, â€“1 The leftmost chip shall be output first in time. The first chip shall be aligned at the start of a transmitted symbol. The symbol duration shall be exactly 11 chips long. The DBPSK encoder for the basic access rate is specified in Table 16-7. The DQPSK encoder is specified in Table 16-8. (In these tables, +j shall be defined as counterclockwise rotation.) Table 16-7â€”1 Mb/s DBPSK encoding table Bit input Phase change (+j ) 0 0 1 2266 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 16-8â€”2 Mb/s DQPSK encoding table Dibit pattern (d0,d1) Phase change (+j ) (d0 is first in time) 00 0 01 /2 11 10 3 /2 (â€“ /2) 16.3.6.6 Spreading sequences and modulation for CCK modulation at 5.5 Mb/s and 11 Mb/s 16.3.6.6.1 General For the CCK modulation modes, the spreading code length is 8 and is based on complementary codes. The chipping rate is 11 Mchip/s. The symbol duration shall be exactly 8 complex chips long. The following formula shall be used to derive the CCK codewords that shall be used for spreading both 5.5 Mb/s and 11 Mb/s j 1 + 2 + 3 + 4 j 1 + 3 + 4 j 1 + 2 + 4 c = e ,e ,e , : j 1 + 4 j 1 + 2 + 3 j 1 + 3 j 1 + 2 j 1 (16-1) â€“e ,e ,e , â€“e ,e where C is the codeword C = {c0 to c7} The terms 1, 2, 3, and 4 are defined in 16.3.6.6.3 for 5.5 Mb/s and 16.3.6.6.4 for 11 Mb/s. This formula creates 8 complex chips (c0 to c7), where c0 is transmitted first in time. This is a form of the generalized Hadamard transform encoding, where 1 is added to all code chips, 2 is added to all odd code chips, 3 is added to all odd pairs of code chips, and 4 is added to all odd groups of four code chips. The term 1 modifies the phase of all code chips of the sequence and shall be DQPSK encoded for 5.5 Mb/s and 11 Mb/s. This shall take the form of rotating the whole symbol by the appropriate amount relative to the phase of the preceding symbol. Note that the chip c7 of the symbol defined above is the chip that indicates the symbolâ€™s phase and is transmitted last. 16.3.6.6.2 Cover code for CCK The fourth and seventh chips are rotated 180 by a cover sequence to optimize the sequence correlation properties and minimize dc offsets in the codes. This explains the minus sign on the fourth and seventh terms in Equation (16-1). 16.3.6.6.3 CCK 5.5 Mb/s modulation At 5.5 Mb/s, 4 bits (d0 to d3; d0 first in time) are transmitted per symbol. The data bits d0 and d1 encode 1 based on DQPSK. The DQPSK encoder is specified in Table 16-8. (In the table, +j shall be defined as counterclockwise rotation.) The phase change for 1 is relative to the phase 1 of the preceding symbol. For the header to PSDU transition, the phase change for 1 is relative to the phase 2267 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications of the preceding DQPSK (2 Mb/s) symbol. That is, the phase of the last symbol of the CRC-16 is the reference phase for the first symbol generated from the PSDU octets. (See the definition in 16.3.6.5 for the reference phase of this Barker coded symbol.) A â€œ+1â€ chip in the Barker code shall represent the same carrier phase as a â€œ+1â€ chip in the CCK code. All odd-numbered symbols generated from the PSDU octets shall be given an extra 180Â° ( ) rotation, in addition to the standard DQPSK modulation as shown in Table 16-9. The symbols of the PSDU shall be numbered starting with 0 for the first symbol, for the purposes of determining odd and even symbols. That is, the PSDU transmission starts on an even-numbered symbol. Table 16-9â€”DQPSK encoding table Dibit pattern (d0, d1) Even symbols Odd symbols (d0 is first in time) phase change (+j phase change (+j ) 00 0 01 /2 3 /2 (â€“ /2) 11 0 10 3 /2 (â€“ /2) /2 The data dibits d2 and d3 CCK encode the basic symbol, as specified in Table 16-10. This table is derived from the formula above by setting 2 = (d2 ) + /2, 3 = 0, and 4 = d3 . In this table, d2 and d3 are in the order shown, and the complex chips are shown c0 to c7 (left to right), with c0 transmitted first in time. Table 16-10â€”5.5 Mb/s CCK encoding table d2, d3 c1 c2 c3 c4 c5 c6 c7 c8 00 1j 1 1j â€“1 1j 1 â€“1j 1 01 â€“1j â€“1 â€“1j 1 1j 1 â€“1j 1 10 â€“1j 1 â€“1j â€“1 â€“1j 1 1j 1 11 1j â€“1 1j 1 â€“1j 1 1j 1 16.3.6.6.4 CCK 11 Mb/s modulation At 11 Mb/s, 8 bits (d0 to d7; d0 first in time) are transmitted per symbol. The first dibit (d0, d1) encodes 1 based on DQPSK. The DQPSK encoder is specified in Table 16-8. The phase change for 1 is relative to the phase 1 of the preceding symbol. In the case of header to PSDU transition, the phase change for 1 is relative to the phase of the preceding DQPSK symbol. All odd- numbered symbols of the PSDU are given an extra 180Â° ( ) rotation, in accordance with the DQPSK modulation shown in Table 16-8. Symbol numbering starts with 0 for the first symbol of the PSDU. The data dibits (d2, d3), (d4, d5), and (d6, d7) encode 2, 3, and 4, respectively, based on QPSK as specified in Table 16-11. Note that this table is binary (not Gray) coded. 2268 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 16-11â€”QPSK encoding table Dibit pattern [di, d(i+1)] Phase (di is first in time) 00 0 01 /2 10 11 3 /2 (â€“ /2) 16.3.6.7 Transmit and receive in-band and out-of-band spurious emissions The HR/DSSS PHY shall comply with in-band and out-of-band spurious emissions as set by the appropriate regulatory bodies. 16.3.6.8 TX-to-RX turnaround time The TX-to-RX turnaround time shall be less than 10 s, including the power-down ramp specified in 16.3.7.7. The TX-to-RX turnaround time shall be measured on the WM from the trailing edge of the last transmitted symbol to the valid CCA detection of the incoming signal. The CCA should occur within 25 s (10 s for turnaround time, plus 15 s for energy detect), or by the next slot boundary occurring after the 25 s has elapsed (see 16.3.8.5). A receiver input signal 3 dB above the ED threshold described in 16.3.8.5 shall be present at the receiver. 16.3.6.9 RX-to-TX turnaround time The RX-to-TX turnaround time shall be measured at the MAC/PHY interface using the PHY-TXSTART.request primitive, and shall be 5 s. This includes the transmit power-on ramp described in 16.3.7.7. 16.3.6.10 Slot time The value of the slot time is found in Table 16-4. 16.3.6.11 Transmit and receive impedance at the antenna connector The impedance at the transmit and receive antenna connector(s) shall be 50 if the connector is exposed. 16.3.7 PHY transmit specifications 16.3.7.1 Introduction The transmit functions and parameters associated with the PHY sublayer are described in 16.3.7.2 to 16.3.7.9. 16.3.7.2 Transmit power levels The maximum allowable output power is measured in accordance with practices specified by the appropriate regulatory bodies. 2269 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 16.3.7.3 Transmit power level control Power control shall be provided for transmitted power greater than 100 mW. A maximum of four power levels may be provided. As a minimum, a radio capable of transmission greater than 100 mW shall be capable of switching power back to 100 mW or less. 16.3.7.4 Transmit spectrum mask The transmitted spectral products shall be less than â€“30 dBr (decibel relative to the SINx/x peak) for fc â€“ 22 MHz < f < fc â€“11 MHz and fc + 11 MHz < f < fc + 22 MHz and shall be less than â€“50 dBr for f < fc â€“ 22 MHz and f > fc + 22 MHz where fc is the channel center frequency The transmit spectral mask is shown in Figure 16-10. The measurements shall be made using a 100 kHz resolution bandwidth and a 100 kHz video bandwidth. Figure 16-10â€”Transmit spectrum mask 16.3.7.5 Transmit center frequency tolerance The transmitted center frequency tolerance shall be Â±25 ppm maximum. 16.3.7.6 Chip clock frequency tolerance The PN code chip clock frequency tolerance shall be Â±25 ppm maximum. It is highly recommended that the chip clock and the transmit frequency be locked (coupled) for optimum demodulation performance. If these clocks are locked, it is recommended that bit 2 of the SERVICE field be set to 1, as indicated in 16.2.3.5. 2270 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 16.3.7.7 Transmit power-on and power-down ramp The transmit power-on ramp for 10% to 90% of maximum power shall be no greater than 2 s. The transmit power-on ramp is shown in Figure 16-11. Max Tx Power Transmit Power 90% MAX Output 10% MAX 0 1 2 3 4 Time s Figure 16-11â€”Transmit power-on ramp The transmit power-down ramp for 90% to 10% maximum power shall be no greater than 2 s. The transmit power-down ramp is shown in Figure 16-12. Max Tx Power Transmit 90% MAX Power Output 10% MAX 0 1 2 3 4 Time s Figure 16-12â€”Transmit power-down ramp The transmit power ramps shall be constructed such that the HR/DSSS PHY emissions comply with spurious frequency product specification defined in 16.3.6.7. 16.3.7.8 RF carrier suppression The RF carrier suppression, measured at the channel center frequency, shall be at least 15 dB below the peak sin(x)/x power spectrum. The RF carrier suppression shall be measured while transmitting a repetitive 01 data sequence with the scrambler disabled using DQPSK modulation. A 100 kHz resolution bandwidth shall be used to perform this measurement. 2271 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 16.3.7.9 Transmit modulation accuracy The transmit modulation accuracy requirement for the HR/DSSS PHY shall be based on the difference between the actual transmitted waveform and the ideal signal waveform. Modulation accuracy shall be determined by measuring the peak vector error magnitude during each chip period. Worst-case vector error magnitude shall not exceeded 0.35 for the normalized sampled chip data. The ideal complex I and Q constellation points associated with DQPSK modulation, (0.707, 0.707), (0.707, â€“0.707), (â€“0.707, 0.707), (â€“0.707, â€“0.707), shall be used as the reference. These measurements shall be from baseband I and Q sampled data after recovery through a reference receiver system. Figure 16-13 illustrates the ideal DQPSK constellation points and range of worst-case error specified for modulation accuracy. Figure 16-13â€”Modulation accuracy measurement example Error vector measurement requires a reference receiver capable of carrier lock. All measurements shall be made under carrier lock conditions. The distortion induced in the constellation by the reference receiver shall be calibrated and measured. The test data error vectors described below shall be corrected to compensate for the reference receiver distortion. The IEEE Std 802.11-compatible radio shall provide an exposed TX chip clock, which shall be used to sample the I and Q outputs of the reference receiver. The measurement shall be made under the conditions of continuous DQPSK transmission using scrambled all 1s. The eye pattern of the I channel shall be used to determine the I and Q sampling point. The chip clock provided by the vendor radio shall be time delayed, such that the samples fall at a 1/2 chip period offset from the mean of the zero crossing positions of the eye (see Figure 16-14). This is the ideal center of the eye and might not be the point of maximum eye opening. 2272 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 1 Chip Period Amplitude Geometric Center Ideal Sample Points (1/2 chip period) Time Vendor Chip Clock Figure 16-14â€”Chip clock alignment with baseband eye pattern Using the aligned chip clock, 1000 samples of the I and Q baseband outputs from the reference receiver are captured. The vector error magnitudes shall be calculated as follows: Calculate the dc offsets for I and Q samples 999 I mean = I n 1000 n=0 999 Q mean = Q n 1000 n=0 Calculate the dc corrected I and Q samples for all n = 1000 sample pairs Idc(n) = I(n) â€“ Imean Qdc(n) = Q(n) â€“ Qmean Calculate the average magnitude of I and Q samples 999 I mag = I dc n 1000 n=0 999 Q mag = Q dc n 1000 n=0 2273 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Calculate the normalized error vector magnitude for the Idc(n)/Qdc(n) pairs --1- 2 2 2 V err n = I dc n â€“ I mag + Q dc n â€“ Q mag â€“ V correction where the average power of the constellation is 1 Vcorrection is the error induced by the reference receiver system For all n = 1000 samples, the following condition shall be met: Verr(n) < 0.35 16.3.7.10 Time of Departure accuracy The Time of Departure accuracy test evaluates TIME_OF_DEPARTURE against aTxPHYTxStartRMS and aTxPHYTxStartRMS against TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH as defined in Annex P with the following test parameters: fH â€“ fL â€” MULTICHANNEL_SAMPLING_RATE is 22 10 6 1 + ------------------- - sample/s 22 MHz where fH is the nominal center frequency in Hz of the highest channel in the channel set fL is the nominal center frequency in Hz of the lowest channel in the channel set, the channel set is the set of channels upon which frames providing measurements are transmitted, the channel set comprises channels uniformly spaced across fH â€“ fL 50 MHz â€” FIRST_TRANSITION_FIELD is the SYNC field. â€” SECOND_TRANSITION_FIELD is the SFD field. â€” TRAINING_FIELD is the concatenation of the appropriate short or long SYNC and SFD fields, using a chip pulse which should approximate a rectangular pulse of duration 1/ 11 MHz convolved with a brick-wall low pass filter of bandwidth 11 MHz. â€” TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH is 80 ns. NOTEâ€”The indicated chip pulse applies to the time of departure accuracy test equipment, and not the transmitter or receiver. 16.3.8 PHY receiver specifications 16.3.8.1 Introduction The receive functions and parameters associated with the PHY sublayer are described in 16.3.8.2 to 16.3.8.5. 16.3.8.2 Receiver minimum input level sensitivity The FER shall be less than 8 10â€“2 at a PSDU length of 1024 octets for an input level of â€“76 dBm measured at the antenna connector. This FER shall be specified for 11 Mb/s CCK modulation. The test for the minimum input level sensitivity shall be conducted with the ED threshold set less than or equal to â€“76 dBm. 2274 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 16.3.8.3 Receiver maximum input level The receiver shall provide a maximum FER of 8 10â€“2 at a PSDU length of 1024 octets for a maximum input level of â€“10 dBm measured at the antenna. This FER shall be specified for 11 Mb/s CCK modulation. 16.3.8.4 Receiver adjacent channel rejection Adjacent channel rejection is defined between any two channels with 25 MHz separation in each channel group, as defined in 16.3.6.3. The adjacent channel rejection shall be greater than or equal to than 35 dB, with an FER of 8 10â€“2 using 11 Mb/s CCK modulation described in 16.3.6.4 and a PSDU length of 1024 octets. The adjacent channel rejection shall be measured using the following method. Input an 11 Mb/s CCK modulated signal at a level 6 dB greater than specified in 16.3.8.2. In an adjacent channel ( 25 MHz separation as defined by the channel numbering), input a signal modulated in a similar fashion, which adheres to the transmit mask specified in 16.3.7.4, to a level 41 dB above the level specified in 16.3.8.2. The adjacent channel signal shall be derived from a separate signal source. It shall not be a frequency shifted version of the reference channel. Under these conditions, the FER shall be less than or equal to 8 10â€“2. 16.3.8.5 CCA The HR/DSSS PHY shall provide the capability to perform CCA according to both: A â€” At least one of the following options: â€” CCA Mode 1: Energy above threshold. CCA shall report a busy medium upon detecting any energy above the ED threshold. â€” CCA Mode 4: CS with timer. CCA shall start a timer whose duration is 3.65 ms and report a busy medium only upon the detection of a HR/DSSS PHY signal. CCA shall report an IDLE medium after the timer expires and no HR/DSSS PHY signal is detected. The 3.65 ms timeout is the duration of the longest possible 5.5 Mb/s PSDU. â€” CCA Mode 5: A combination of CS and energy above threshold. CCA shall report busy at least while a HR/DSSS PPDU is being received with energy above the ED threshold at the antenna. and B â€” CCA Mode 6: CCA shall report a busy medium upon detection of any energy above â€“62 dBm. A busy channel shall be indicated by issuing a PHY-CCA.indication(BUSY) primitive. A clear channel shall be indicated by issuing a PHY-CCA.indication(IDLE) primitive. dot11HRCCAModeSupported shall indicate the appropriate operation modes. The PHY shall be configured through dot11CurrentCCAMode. The CCA shall indicate a clear channel if there is no energy detect or CS. The CCA parameters are subject to the following criteria: a) If a valid HR/DSSS signal is detected during its preamble within the CCA window, the ED threshold shall be less than or equal to â€“76 dBm for TX power > 100 mW; â€“73 dBm for 50 mW < TX power 100 mW; and â€“70 dBm for TX power 50 mW. 2275 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications b) With a valid signal (according to the CCA mode of operation) present at the receiver antenna within 5 s of the start of a MAC slot boundary, the PHY-CCA.indication(BUSY) primitive shall be generated before the end of the slot time. Refer to Figure 10-19 (in 10.3.7) and Figure 10-26 for a definition of slot boundary. c) In the event that a correct PHY header is received, the HR/DSSS PHY shall not generate a PHY- CCA.indication (IDLE) primitive until the end of the PPDU as determined by TXTIME in 16.3.4. Upon reception of a correct PHY header, the timer of CCA Mode 4 shall be overridden by this requirement. Compliance to the HR/DSSS PHY CCA shall be demonstrated by applying an equivalent HR/DSSS signal above the appropriate ED threshold (item a) so that all conditions described in item b and item c are demonstrated. 16.3.8.6 Received Channel Power Indicator Measurement The RCPI indicator is a measure of the received RF power in the selected channel for a received frame. This parameter shall be a measure by the PHY of the received RF power in the channel measured over the entire received frame or by other equivalent means that meet the specified accuracy. The RCPI encoding is defined in 9.4.2.38. RCPI shall equal the received RF power within an accuracy of Â±5 dB (95% confidence interval) within the specified dynamic range of the receiver. The received RF power shall be determined assuming a receiver noise equivalent bandwidth equal to the channel bandwidth multiplied by 1.1. 2276 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 17. Orthogonal frequency division multiplexing (OFDM) PHY specification 17.1 Introduction 17.1.1 General This clause specifies the PHY entity for an orthogonal frequency division multiplexing (OFDM) system. The OFDM system provides a WLAN with data payload communication capabilities of 6, 9, 12, 18, 24, 36, 48, and 54 Mb/s. The support of transmitting and receiving at data rates of 6, 12, and 24 Mb/s is mandatory. The system uses 52 subcarriers that are modulated using binary or quadrature phase shift keying (BPSK or QPSK) or using 16- or 64-quadrature amplitude modulation (16-QAM or 64-QAM). Forward error correction coding (convolutional coding) is used with a coding rate of 1/2, 2/3, or 3/4. The OFDM system also provides a â€œhalf-clockedâ€ operation using 10 MHz channel spacings with data communications capabilities of 3, 4.5, 6, 9, 12, 18, 24, and 27 Mb/s. The support of transmitting and receiving at data rates of 3, 6, and 12 Mb/s is mandatory when using 10 MHz channel spacing. The half- clocked operation doubles symbol times and clear channel assessment (CCA) times when using 10 MHz channel spacing. The regulatory requirements and information regarding use of this OFDM PHY are in Annex D and Annex E. The OFDM system also provides a â€œquarter-clockedâ€ operation using 5 MHz channel spacing with data communication capabilities of 1.5, 2.25, 3, 4.5, 6, 9, 12, and 13.5 Mb/s. The support of transmitting and receiving at data rates of 1.5, 3, and 6 Mb/s is mandatory when using 5 MHz channel spacing. The quarter- clocked operation quadruples symbol times and CCA times when using 5 MHz channel spacing. The regulatory requirements and information regarding use of this OFDM PHY are in Annex D and Annex E. 17.1.2 Scope Subclause 17.1 describes the PHY services provided to the IEEE 802.11 WLAN MAC by the OFDM PHY. The OFDM PHY consists of the following protocol functions: a) A function that defines a method of mapping the IEEE 802.11 PSDUs into a framing format suitable for sending and receiving user data and management information between two or more STAs. b) A function that defines the characteristics and method of transmitting and receiving data through a WM between two or more STAs, each using the OFDM system. 17.1.3 OFDM PHY functions 17.1.3.1 General The OFDM PHY architecture is depicted in the reference model shown in Figure 4-19 (in 4.9). The OFDM PHY contains two functional entities: the PHY function and the layer management function. Each of these functions is described in detail in 17.3 and 17.4. The OFDM PHY service is provided to the MAC through the PHY service primitives described in Clause 8. 17.1.3.2 PLME The PLME performs management of the local PHY functions in conjunction with the MLME. 2277 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 17.1.3.3 Service specification method The models represented by figures and state diagrams are intended to be illustrations of the functions provided. It is important to distinguish between a model and a real implementation. The models are optimized for simplicity and clarity of presentation, but do not necessarily reflect any particular implementation. The service of a layer or sublayer is the set of capabilities that it offers to a user in the next higher layer (or sublayer). Abstract services are specified here by describing the service primitives and parameters that characterize each service. This definition is independent of any particular implementation. 17.2 OFDM PHY specific service parameter list 17.2.1 Introduction The architecture of the IEEE 802.11 MAC is intended to be PHY independent. Some PHY implementations require medium management state machines running in the MAC sublayer in order to meet certain PHY requirements. These PHY-dependent MAC state machines reside in a sublayer defined as the MLME. In certain PHY implementations, the MLME may need to interact with the PLME as part of the normal PHY SAP primitives. These interactions are defined by the PLME parameter list currently defined in the PHY service primitives as TXVECTOR and RXVECTOR. The list of these parameters, and the values they may represent, are defined in the specific PHY specifications for each PHY. Subclause 17.2 addresses the TXVECTOR and RXVECTOR for the OFDM PHY. 17.2.2 TXVECTOR parameters 17.2.2.1 General The parameters in Table 17-1 are defined as part of the TXVECTOR parameter list in the PHY-TXSTART.request primitive. Table 17-1â€”TXVECTOR parameters Parameter Associated primitive Value LENGTH PHY-TXSTART.request 1â€“4095 (TXVECTOR) DATATRATE PHY-TXSTART.request 6, 9, 12, 18, 24, 36, 48, and 54 Mb/s for 20 MHz channel (TXVECTOR) spacing (Support of 6, 12, and 24 Mb/s data rates is mandatory.) 3, 4.5, 6, 9, 12, 18, 24, and 27 Mb/s for 10 MHz channel spacing (Support of 3, 6, and 12 Mb/s data rates is mandatory.) 1.5, 2.25, 3, 4.5, 6, 9, 12, and 13.5 Mb/s for 5 MHz channel spacing (Support of 1.5, 3, and 6 Mb/s data rates is mandatory.) SERVICE PHY-TXSTART.request Null (TXVECTOR) TXPWR_LEVEL_IN PHY-TXSTART.request 1â€“8 DEX (TXVECTOR) 2278 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 17-1â€”TXVECTOR parameters (continued) Parameter Associated primitive Value TIME_OF_ PHY-TXSTART.request false, true. When true, the MAC entity requests that the PHY DEPARTURE_ (TXVECTOR) entity measures and reports time of departure parameters REQUESTED corresponding to the time when the first frame energy is sent by the transmitting port; when false, the MAC entity requests that the PHY entity neither measures nor reports time of departure parameters. CH_BANDWIDTH_ PHY-TXSTART.request If present, CBW20, CBW40, CBW80, CBW160, or IN_NON_HT (TXVECTOR) CBW80+80 DYN_BANDWIDTH PHY-TXSTART.request If present, Static or Dynamic _IN_NON_HT (TXVECTOR) 17.2.2.2 TXVECTOR LENGTH The allowed values for the LENGTH parameter are in the range 1 to 4095. This parameter is used to indicate the number of octets in the MPDU which the MAC is currently requesting the PHY to transmit. This value is used by the PHY to determine the number of octet transfers that will occur between the MAC and the PHY after receiving a request to start the transmission. 17.2.2.3 TXVECTOR DATARATE The DATARATE parameter describes the bit rate at which the PHY shall transmit the PSDU. Its value takes any of the rates defined in Table 17-1. Data rates of 6, 12, and 24 Mb/s shall be supported for 20 MHz channel spacing, data rates of 3, 6, and 12 Mb/s shall be supported for 10 MHz channel spacing, and data rates of 1.5, 3, and 6 Mb/s shall be supported for 5 MHz channel spacing; other rates may also be supported. 17.2.2.4 TXVECTOR SERVICE The SERVICE parameter shall be null. 17.2.2.5 TXVECTOR TXPWR_LEVEL_INDEX The allowed values for the TXPWR_LEVEL_INDEX parameter are in the range 1 to 8. This parameter is used to indicate which of the available TxPowerLevel attributes defined in the MIB shall be used for the current transmission. 17.2.2.6 TXVECTOR TIME_OF_DEPARTURE_REQUESTED The allowed values are false or true. A parameter value of true indicates that the MAC sublayer is requesting that the PHY entity provides measurement of when the first frame energy is sent by the transmitting port and reporting within the PHY-TXSTART.confirm(TXSTATUS) primitive. A parameter value of false indicates that the MAC sublayer is requesting that the PHY entity not provide time of departure measurement nor reporting in the PHY-TXSTART.confirm(TXSTATUS) primitive. 17.2.2.7 TXVECTOR CH_BANDWIDTH_IN_NON_HT If present, the allowed values for CH_BANDWIDTH_IN_NON_HT are CBW20, CBW40, CBW80, CBW160, and CBW80+80. If present, this parameter is used to modify the first 7 bits of the scrambling sequence to indicate the bandwidth of the non-HT duplicate PPDU. 2279 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NOTEâ€”The CH_BANDWIDTH_IN_NON_HT parameter is not present when the frame is transmitted by a non-VHT STA. The CH_BANDWIDTH_IN_NON_HT parameter is not present when the frame is transmitted by a VHT STA to a non-VHT STA. See 10.7.11. 17.2.2.8 TXVECTOR DYN_BANDWIDTH_IN_NON_HT If present, the allowed values for DYN_BANDWIDTH_IN_NON_HT are Static and Dynamic. If present, this parameter is used to modify the first 7 bits of the scrambling sequence to indicate if the transmitter is capable of Static or Dynamic bandwidth operation. If DYN_BANDWIDTH_IN_NON_HT is present, then CH_BANDWIDTH_IN_NON_HT is also present. NOTEâ€”The DYN_BANDWIDTH_IN_NON_HT parameter is not present when the frame is transmitted by a non- VHT STA. The DYN_BANDWIDTH_IN_NON_HT parameter is not present when the frame is transmitted by a VHT STA to a non-VHT STA. See 10.7.11. 17.2.3 RXVECTOR parameters 17.2.3.1 General The parameters listed in Table 17-2 are defined as part of the RXVECTOR parameter list in the PHY-RXSTART.indication primitive. Table 17-2â€”RXVECTOR parameters Parameter Associated primitive Value LENGTH PHY- 1â€“4095 RXSTART.indication RSSI PHY- 0â€“RSSI maximum RXSTART.indication (RXVECTOR) DATARATE PHY-RXSTART.request 6, 9, 12, 18, 24, 36, 48, and 54 Mb/s for 20 MHz channel (RXVECTOR) spacing (Support of 6, 12, and 24 Mb/s data rates is mandatory.) 3, 4.5, 6, 9, 12, 18, 24, and 27 Mb/s for 10 MHz channel spacing (Support of 3, 6, and 12 Mb/s data rates is mandatory.) 1.5, 2.25, 3, 4.5, 6, 9, 12, and 13.5 Mb/s for 5 MHz channel spacing (Support of 1.5, 3, and 6 Mb/s data rates is mandatory.) SERVICE PHY-RXSTART.request Null (RXVECTOR) RCPI PHY- 0â€“255 (see NOTE) RXSTART.indication (RXVECTOR) PHY-RXEND.indication (RXVECTOR) ANT_STATE PHY- 0â€“255 (see NOTE) RXSTART.indication (RXVECTOR) PHY-RXEND.indication (RXVECTOR) 2280 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 17-2â€”RXVECTOR parameters (continued) Parameter Associated primitive Value RX_START_OF_FRAM PHY- 0 to 232â€“ 1. An estimate of the offset (in 10 ns units) E_OFFSET RXSTART.indication from the point in time at which the start of the preamble (RXVECTOR) corresponding to the incoming frame arrived at the receive antenna connector to the point in time at which this primitive is issued to the MAC. CH_BANDWIDTH PHY-RXSTART.request If present, CBW20, CBW40, CBW80, CBW160, or _IN_NON_HT (RXVECTOR) CBW80+80 DYN_BANDWIDTH PHY-RXSTART.request If present, Static or Dynamic _IN_NON_HT (RXVECTOR) NOTEâ€”Parameter is present only when dot11RadioMeasurementActivated is true. 17.2.3.2 RXVECTOR LENGTH The allowed values for the LENGTH parameter are in the range 1â€“4095. This parameter is used to indicate the value contained in the LENGTH field which the PHY has received in the PHY header. The MAC and PHY use this value to determine the number of octet transfers that will occur between the two sublayers during the transfer of the received PSDU. 17.2.3.3 RXVECTOR RSSI The allowed values for the RSSI parameter are in the range 0 to RSSI maximum. This parameter is a measure by the PHY of the energy observed at the antenna used to receive the current PPDU. RSSI shall be measured during the reception of the PHY preamble. RSSI is intended to be used in a relative manner, and it shall be a monotonically increasing function of the received power. 17.2.3.4 RXVECTOR DATARATE DATARATE shall represent the data rate at which the current PPDU was received. The allowed values of the DATARATE are 6, 9, 12, 18, 24, 36, 48, or 54 Mb/s for 20 MHz channel spacing; 3, 4.5, 6, 9, 12, 18, 24, or 27 Mb/s for 10 MHz channel spacing; and 1.5, 2.25, 3, 4.5, 6, 9, 12, or 13.5 Mb/s for 5 MHz channel spacing. 17.2.3.5 RXVECTOR SERVICE The SERVICE parameter shall be null. 17.2.3.6 RXVECTOR RCPI The allowed values for the RCPI parameter are in the range 0 to 255, as defined in 17.3.10.7. This parameter is a measure by the PHY of the received channel power. RCPI indications of 8 bits are supported. RCPI shall be measured over the entire received frame or by other equivalent means that meet the specified accuracy. 17.2.3.7 RXVECTOR CH_BANDWIDTH_IN_NON_HT If present, the allowed values for CH_BANDWIDTH_IN_NON_HT are CBW20, CBW40, CBW80, CBW160, and CBW80+80. If present and valid, this parameter indicates the bandwidth of the non-HT duplicate PPDU. This parameter is used by the MAC only when valid (see 10.3.2.7 and 10.7.6.6). 2281 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NOTEâ€”The CH_BANDWIDTH_IN_NON_HT parameter is not present when the frame is received by a non-VHT STA (see 10.7.11). 17.2.3.8 RXVECTOR DYN_BANDWIDTH_IN_NON_HT If present, the allowed values for DYN_BANDWIDTH_IN_NON_HT are Static and Dynamic. If present and valid, this parameter indicates whether the transmitter is capable of Static or Dynamic bandwidth operation. This parameter is used by the MAC only when valid (see 10.3.2.7 and 10.7.6.6). If DYN_BANDWIDTH_IN_NON_HT is present, then CH_BANDWIDTH_IN_NON_HT is also present. NOTEâ€”The DYN_BANDWIDTH_IN_NON_HT parameter is not present when the frame is received by a non-VHT STA (see 10.7.11). 17.2.4 TXSTATUS parameters 17.2.4.1 General The parameters listed in Table 17-3 are defined as part of the TXSTATUS parameter list in the PHY- TXSTART.confirm primitive. Table 17-3â€”TXSTATUS parameters Parameter Associated primitive Value TIME_OF_DEPARTURE PHY- 0 to 232â€“ 1. The locally measured time when TXSTART.confirm the first frame energy is sent by the (TXSTATUS) transmitting port, in units equal to 1/ TIME_OF_DEPARTURE_ClockRate. This parameter is present only if TIME_OF_DEPARTURE_REQUESTED is true in the corresponding request. TIME_OF_DEPARTURE_ClockRate PHY- 0 to 216â€“ 1. The clock rate, in units of MHz, is TXSTART.confirm used to generate the TIME_OF_DEPARTURE (TXSTATUS) value. This parameter is present only if TIME_OF_DEPARTURE_REQUESTED is true in the corresponding request. TX_START_OF_FRAME_OFFSET PHY- 0 to 232â€“ 1. An estimate of the offset (in 10 ns TXSTART.confirm units) from the point in time at which the start (TXSTATUS) of the preamble corresponding to the frame was transmitted at the transmit antenna connector to the point in time at which this primitive is issued to the MAC. 17.2.4.2 TXSTATUS TIME_OF_DEPARTURE The allowed values for the TIME_OF_DEPARTURE parameter are integers in the range 0 to 232â€“ 1. This parameter is used to indicate when the first frame energy is sent by the transmitting port in units equal to 1/ TIME_OF_DEPARTURE_ClockRate. TIME_OF_DEPARTURE may be included in the transmitted frame in order for recipients on multiple channels to determine the time differences of air propagation times between transmitter and recipients and hence to compute the location of the transmitter. 17.2.4.3 TXSTATUS TIME_OF_DEPARTURE_ClockRate TIME_OF_DEPARTURE_ClockRate indicates the clock rate used for TIME_OF_DEPARTURE. 2282 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 17.3 OFDM PHY 17.3.1 Introduction Subclause 17.3 provides a convergence procedure in which PSDUs are converted to and from PPDUs. During transmission, the PSDU shall be provided with a PHY preamble and header to create the PPDU. At the receiver, the PHY preamble and header are processed to aid in demodulation and delivery of the PSDU. 17.3.2 PPDU format 17.3.2.1 General Figure 17-1 shows the format for the PPDU including the OFDM PHY preamble, OFDM PHY header, PSDU, tail bits, and pad bits. The PHY header contains the following fields: LENGTH, RATE, a reserved bit, an even parity bit, and the SERVICE field. In terms of modulation, the LENGTH, RATE, reserved bit, and parity bit (with 6 zero tail bits appended) constitute a separate single OFDM symbol, denoted SIGNAL, which is transmitted with the most robust combination of BPSK modulation and a coding rate of R = 1/2. The SERVICE field of the PHY header and the PSDU (with 6 zero tail bits and pad bits appended), denoted as DATA, are transmitted at the data rate described in the RATE field and may constitute multiple OFDM symbols. The tail bits in the SIGNAL symbol enable decoding of the RATE and LENGTH fields immediately after the reception of the tail bits. The RATE and LENGTH fields are required for decoding the DATA part of the packet. In addition, the CCA mechanism is augmented by predicting the duration of the packet from the contents of the RATE and LENGTH fields, even if the data rate is not supported by the STA. Each of these fields is described in detail in 17.3.3, 17.3.4, and 17.3.5. PHY Header RATE Reserved LENGTH Parity Tail SERVICE Tail Pad Bits PSDU 4 bits 1 bit 12 bits 1 bit 6 bits 16 bits 6 bits Coded/OFDM Coded/OFDM (BPSK, r = 1/2) (RATE is indicated in SIGNAL) PHY Preamble SIGNAL DATA 12 Symbols One OFDM Symbol Variable Number of OFDM Symbols Figure 17-1â€”PPDU format 17.3.2.2 Overview of the PPDU encoding process The encoding process is composed of many detailed steps, which are described fully in later subclauses, as noted below. The following overview intends to facilitate understanding the details of the convergence procedure: a) Produce the PHY Preamble field, composed of 10 repetitions of a â€œshort training sequenceâ€ (used for AGC convergence, diversity selection, timing acquisition, and coarse frequency acquisition in the receiver) and two repetitions of a â€œlong training sequenceâ€ (used for channel estimation and fine frequency acquisition in the receiver), preceded by a guard interval (GI). Refer to 17.3.3 for details. b) Produce the PHY header field from the RATE, LENGTH, and SERVICE fields of the TXVECTOR by filling the appropriate bit fields. The RATE and LENGTH fields of the PHY header are encoded by a convolutional code at a rate of R = 1/2, and are subsequently mapped onto a single BPSK 2283 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications encoded OFDM symbol, denoted as the SIGNAL symbol. In order to facilitate a reliable and timely detection of the RATE and LENGTH fields, 6 zero tail bits are inserted into the PHY header. The encoding of the SIGNAL field into an OFDM symbol follows the same steps for convolutional encoding, interleaving, BPSK modulation, pilot insertion, Fourier transform, and prepending a GI as described subsequently for data transmission with BPSK-OFDM modulated at coding rate 1/2. The contents of the SIGNAL field are not scrambled. Refer to 17.3.4 for details. c) Calculate from RATE field of the TXVECTOR the number of data bits per OFDM symbol (NDBPS), the coding rate (R), the number of bits in each OFDM subcarrier (NBPSC), and the number of coded bits per OFDM symbol (NCBPS). Refer to 17.3.2.3 for details. d) Append the PSDU to the SERVICE field of the TXVECTOR. Extend the resulting bit string with zero bits (at least 6 bits) so that the resulting length is a multiple of NDBPS. The resulting bit string constitutes the DATA part of the packet. Refer to 17.3.5.4 for details. e) If the TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT is not present, initiate the scrambler with a pseudorandom nonzero seed and generate a scrambling sequence. If the TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT is present, construct the first 7 bits of the scrambling sequence from CH_BANDWIDTH_IN_NON_HT, DYN_BANDWIDTH_IN_NON_HT (if present), and a pseudorandom integer constrained such that the first 7 bits of the scrambling sequence are not all 0s; then set the scrambler state to these 7 bits and generate the remainder of the scrambling sequence. XOR the scrambling sequence with the extended string of data bits. Refer to 17.3.5.5 for details. f) Replace the six scrambled zero bits following the data with six nonscrambled zero bits. (Those bits return the convolutional encoder to the zero state and are denoted as tail bits.) Refer to 17.3.5.3 for details. g) Encode the extended, scrambled data string with a convolutional encoder (R = 1/2). Omit (puncture) some of the encoder output string (chosen according to â€œpuncturing patternâ€) to reach the â€œcoding rateâ€ corresponding to the TXVECTOR parameter RATE. Refer to 17.3.5.6 for details. h) Divide the encoded bit string into groups of NCBPS bits. Within each group, perform an â€œinterleavingâ€ (reordering) of the bits according to a rule corresponding to the TXVECTOR parameter RATE. Refer to 17.3.5.7 for details. i) Divide the resulting coded and interleaved data string into groups of NBPSC bits. For each of the bit groups, convert the bit group into a complex number according to the modulation encoding tables. Refer to 17.3.5.8 for details. j) Divide the complex number string into groups of 48 complex numbers. Each such group is associated with one OFDM symbol. In each group, the complex numbers are numbered 0 to 47 and mapped hereafter into OFDM subcarriers numbered â€“26 to â€“22, â€“20 to â€“8, â€“6 to â€“1, 1 to 6, 8 to 20, and 22 to 26. The subcarriers â€“21, â€“7, 7, and 21 are skipped and, subsequently, used for inserting pilot subcarriers. The 0 subcarrier, associated with center frequency, is omitted and filled with the value 0. Refer to 17.3.5.10 for details. k) Four subcarriers are inserted as pilots into positions â€“21, â€“7, 7, and 21. The total number of the subcarriers is 52 (48 + 4). Refer to 17.3.5.9 for details. l) For each group of subcarriers â€“26 to 26, convert the subcarriers to time domain using inverse Fourier transform. Prepend to the Fourier-transformed waveform a circular extension of itself thus forming a GI, and truncate the resulting periodic waveform to a single OFDM symbol length by applying time domain windowing. Refer to 17.3.5.10 for details. m) Append the OFDM symbols one after another, starting after the SIGNAL symbol describing the RATE and LENGTH fields. Refer to 17.3.5.10 for details. n) Upconvert the resulting â€œcomplex basebandâ€ waveform to an RF according to the center frequency of the operating channel and transmit. Refer to 17.3.2.5 and 17.3.8.2 for details. 2284 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications An illustration of the transmitted frame and its parts appears in Figure 17-4 (in 17.3.3). 17.3.2.3 Modulation-dependent parameters The modulation parameters dependent on the data rate used shall be set according to Table 17-4. Table 17-4â€”Modulation-dependent parameters Coded Data bits Data rate Data rate Data rate Coded bits Coding bits per per (Mb/s) (Mb/s) (Mb/s) per Modulation rate OFDM OFDM (20 MHz (10 MHz (5 MHz subcarrier (R) symbol symbol channel channel channel (NBPSC) (NCBPS) (NDBPS) spacing) spacing) spacing) BPSK 1/2 1 48 24 6 3 1.5 BPSK 3/4 1 48 36 9 4.5 2.25 QPSK 1/2 2 96 48 12 6 3 QPSK 3/4 2 96 72 18 9 4.5 16-QAM 1/2 4 192 96 24 12 6 16-QAM 3/4 4 192 144 36 18 9 64-QAM 2/3 6 288 192 48 24 12 64-QAM 3/4 6 288 216 54 27 13.5 17.3.2.4 Timing-related parameters Table 17-5 is the list of timing parameters associated with the OFDM PHY. Table 17-5â€”Timing-related parameters Value Value Value Parameter (20 MHz channel (10 MHz channel (5 MHz channel spacing) spacing) spacing) NSD: Number of data subcarriers 48 48 48 NSP: Number of pilot subcarriers 4 4 4 NST: Number of subcarriers, 52 (NSD + NSP) 52 (NSD + NSP) 52 (NSD + NSP) total F: Subcarrier frequency 0.3125 MHz 0.156 25 MHz 0.078 125 MHz spacing (=20 MHz/64) (= 10 MHz/64) (= 5 MHz/64) TFFT: Inverse Fast Fourier 3.2 s (1/ F) 6.4 Âµs (1/ F) 12.8 Âµs (1/ F) Transform (IFFT) / Fast Fourier Transform (FFT) period TPREAMBLE: PHY preamble 16 s (TSHORT + TLONG) 32 Âµs (TSHORT + TLONG) 64 Âµs (TSHORT + TLONG) duration 2285 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 17-5â€”Timing-related parameters (continued) Value Value Value Parameter (20 MHz channel (10 MHz channel (5 MHz channel spacing) spacing) spacing) TSIGNAL: Duration of the 4.0 s (TGI + TFFT) 8.0 Âµs (TGI + TFFT) 16.0 Âµs (TGI + TFFT) SIGNAL BPSK-OFDM symbol TGI: GI duration 0.8 s (TFFT/4) 1.6 Âµs (TFFT/4) 3.2 Âµs (TFFT/4) TGI2: Training symbol GI 1.6 s (TFFT/2) 3.2 Âµs (TFFT/2) 6.4 Âµs (TFFT/2) duration TSYM: Symbol interval 4 s (TGI + TFFT) 8 Âµs (TGI + TFFT) 16 Âµs (TGI + TFFT) TSHORT: Short training sequence 8 s (10 TFFT /4) 16 Âµs (10 Ã— TFFT/4) 32 Âµs (10 Ã— TFFT/4) duration TLONG: Long training sequence 8 s (TGI2 + 2 TFFT) 16 Âµs (TGI2 + 2 Ã— TFFT) 32 Âµs (TGI2 + 2 Ã— TFFT) duration 17.3.2.5 Mathematical conventions in the signal descriptions The transmitted signals are described in a complex baseband signal notation. The actual transmitted signal is related to the complex baseband signal by the following relation: r RF t = Re{r t exp j2 f c t } (17-1) where fc denotes the carrier center frequency The transmitted baseband signal is composed of contributions from several OFDM symbols. r PACKET t = r PREAMBLE t + r SIGNAL t â€“ t SIGNAL + r DATA t â€“ t DATA (17-2) The subframes of which Equation (17-2) are composed are described in 17.3.3, 17.3.4, and 17.3.5.10. The time offsets tSUBFRAME determine the starting time of the corresponding subframe; tSIGNAL is equal to 16 s for 20 MHz channel spacing, 32 s for 10 MHz channel spacing, and 64 s for 5 MHz channel spacing, and tDATA is equal to 20 s for 20 MHz channel spacing, 40 s for 10 MHz channel spacing, and 80 s for 5 MHz channel spacing. All of the subframes of the signal are constructed as an inverse Fourier transform of a set of coefficients, Ck, with Ck defined later as data, pilots, or training symbols in 17.3.3 to 17.3.5. N ST 2 r SUBFRAME t = w TSUBFRAME t C k exp j2 k f t â€“ T GUARD (17-3) k = â€“ N ST 2 The parameters F and NST are described in Table 17-5. The resulting waveform is periodic with a period of TFFT = 1/ F. Shifting the time by TGUARD creates the â€œcircular prefixâ€ used in OFDM to avoid ISI from the previous frame. Three kinds of TGUARD are defined: for the short training sequence (= 0 s), for the long training sequence (= TGI2), and for data OFDM symbols (= TGI). (Refer to Table 17-5.) The boundaries of 2286 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications the subframe are set by a multiplication by a time-windowing function, wTSUBFRAME(t), which is defined as a rectangular pulse, wT(t), of duration T, accepting the value TSUBFRAME. The time-windowing function, wT(t), depending on the value of the duration parameter, T, may extend over more than one period, TFFT. In particular, window functions that extend over multiple periods of the FFT are utilized in the definition of the preamble. Figure 17-2 illustrates the possibility of extending the windowing function over more than one period, TFFT, and additionally shows smoothed transitions by application of a windowing function, as exemplified in Equation (17-4). In particular, window functions that extend over multiple periods of the FFT are utilized in the definition of the preamble. 2 sin --- 0.5 + t T â€“T 2 t T 2 2 TR TR TR w T t = 1 T TR 2 t Tâ€“T TR 2 (17-4) 2 sin --- 0.5 â€“ t â€“ T T Tâ€“T 2 t T+T 2 2 TR TR TR In the case of vanishing TTR, the windowing function degenerates into a rectangular pulse of duration T. This standard describes transmitted waveforms using a rectangular pulse shape. In a typical implementation, a higher TTR is used in order to smooth the transitions between consecutive subsections. This creates a small overlap between them, of duration TTR, as shown in Figure 17-2. The transition time, TTR, is about 100 ns. Smoothing the transition is required in order to reduce the spectral sidelobes of the transmitted waveform. However, the binding requirements are the spectral mask and modulation accuracy requirements, as detailed in 17.3.9.3 and 17.3.9.7. Time domain windowing, as described here, is just one way to achieve those objectives. The implementer may use other methods to achieve the same goal, such as frequency domain filtering. Therefore, the transition shape and duration of the transition are informative parameters. T = TGI+TFFT TGUARD =TGI TFFT (a) TTR TTR T = TGI2+2TFFT TGUARD =TGI2 TFFT TFFT (b) TTR TTR Figure 17-2â€”Illustration of OFDM frame with cyclic extension and windowing for (a) single reception or (b) two receptions of the FFT period 2287 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 17.3.2.6 Discrete time implementation considerations The following descriptions of the discrete time implementation are informational. In a typical implementation, the windowing function is represented in discrete time. As an example, when a windowing function with parameters T = 4.0 s and a TTR = 100 ns is applied, and the signal is sampled at 20 Msample/s, it becomes 1 1 n 79 w T n = w T nT S = 0.5 0 80 (17-5) 0 otherwise The common way to implement the inverse Fourier transform, as shown in Equation (17-3), is by an IFFT algorithm. If, for example, a 64-point IFFT is used, the coefficients 1 to 26 are mapped to the same numbered IFFT inputs, while the coefficients â€“26 to â€“1 are copied into IFFT inputs 38 to 63. The rest of the inputs, 27 to 37 and the 0 (dc) input, are set to 0. This mapping is illustrated in Figure 17-3. After performing an IFFT, the output is cyclically extended and the resulting waveform is windowed to the required OFDM symbol length. Null 0 0 #1 1 1 #2 2 2 . . . . #26 26 IFFT 26 Null 27 27 Null . Time Domain Outputs Null 37 37 #-26 38 38 . . . . #-2 62 62 #-1 63 63 Figure 17-3â€”Inputs and outputs of inverse Fourier transform 17.3.3 PHY preamble (SYNC) The PHY Preamble field is used for synchronization. It consists of 10 short symbols and two long symbols that are shown in Figure 17-4 and described in this subclause. The timings described in this subclause and shown in Figure 17-4 are for 20 MHz channel spacing. They are doubled for half-clocked (i.e., 10 MHz) channel spacing and are quadrupled for quarter-clocked (i.e., 5 MHz) channel spacing. Figure 17-4 shows the OFDM training structure (PHY preamble), where t1 to t10 denote short training symbols and T1 and T2 denote long training symbols. The PHY preamble is followed by the SIGNAL field and DATA. The total training length is 16 s. The dashed boundaries in the figure denote repetitions due to the periodicity of the inverse Fourier transform. 2288 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 8 + 8 = 16 s 10 0.8 = 8 s 2 0.8 + 2 3.2 = 8.0 s 0.8 +3.2 = 4.0 s 0.8 + 3.2 = 4.0 s 0.8 + 3.2 = 4.0 s t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 GI2 T1 T2 GI SIGNAL GI Data 1 GI Data 2 Signal Detect, Coarse Freq. RATE Channel and Fine Frequency SERVICE + DATA DATA AGC, Diversity Offset Estimation Offset Estimation LENGTH Selection timing synchronize Figure 17-4â€”OFDM training structure A short OFDM training symbol consists of 12 subcarriers, which are modulated by the elements of the sequence S, given by Sâ€“26, 26 = (13/6) {0, 0, 1+j, 0, 0, 0, â€“1â€“j, 0, 0, 0, 1+j, 0, 0, 0, â€“1â€“j, 0, 0, 0, â€“1â€“j, 0, 0, 0, 1+j, 0, 0, 0, 0, 0, 0, 0, â€“1â€“j, 0, 0, 0, â€“1â€“j, 0, 0, 0, 1+j, 0, 0, 0, 1+j, 0, 0, 0, 1+j, 0, 0, 0, 1+j, 0,0} (17-6) The multiplication by a factor of (13/6) is in order to normalize the average power of the resulting OFDM symbol, which utilizes 12 out of 52 subcarriers. The signal shall be generated according to the following equation: N ST 2 r SHORT t = w TSHORT t S k exp j2 k Ft (17-7) k = â€“ N ST 2 The fact that only spectral lines of Sâ€“26:26 with indices that are a multiple of 4 have nonzero amplitude results in a periodicity of TFFT/4 = 0.8 s. The interval TSHORT is equal to ten 0.8 s periods (i.e., 8 s). Generation of the short training sequence is illustrated in Table I-2. A long OFDM training symbol consists of 53 subcarriers (including the value 0 at dc), which are modulated by the elements of the sequence L, given by Lâ€“26, 26 = {1, 1, â€“1, â€“1, 1, 1, â€“1, 1, â€“1, 1, 1, 1, 1, 1, 1, â€“1, â€“1, 1, 1, â€“1, 1, â€“1, 1, 1, 1, 1, 0, 1, â€“1, â€“1, 1, 1, â€“1, 1, â€“1, 1, â€“1, â€“1, â€“1, â€“1, â€“1, 1, 1, â€“1, â€“1, 1, â€“1, 1, â€“1, 1, 1, 1, 1} (17-8) A long OFDM training symbol shall be generated according to the following equation: N ST 2 r LONG t = w TLONG t L k exp (j2 k F t â€“ T G 12 ) (17-9) k = â€“ N ST 2 where TG 12 = 1.6 s Two periods of the long sequence are transmitted for improved channel estimation accuracy, yielding TLONG = 1.6 + 2 3.2 = 8 s. 2289 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications An illustration of the long training sequence generation is given in Table I-5. The sections of short repetitions and long repetitions shall be concatenated to form the preamble r PREAMBLE t = r SHORT t + r LONG t â€“ T SHORT (17-10) 17.3.4 SIGNAL field 17.3.4.1 General The OFDM training symbols shall be followed by the SIGNAL field, which contains the RATE and the LENGTH fields of the TXVECTOR. The RATE field conveys information about the type of modulation and the coding rate as used in the rest of the packet. The encoding of the SIGNAL single OFDM symbol shall be performed with BPSK modulation of the subcarriers and using convolutional coding at R = 1/2. The encoding procedure, which includes convolutional encoding, interleaving, modulation mapping processes, pilot insertion, and OFDM modulation, follows the steps described in 17.3.5.6, 17.3.5.7, and 17.3.5.9, as used for transmission of data with BPSK-OFDM modulated at coding rate 1/2. The contents of the SIGNAL field are not scrambled. The SIGNAL field shall be composed of 24 bits, as illustrated in Figure 17-5. The four bits 0 to 3 shall encode the RATE. Bit 4 shall be reserved for future use. Bits 5â€“16 shall encode the LENGTH field of the TXVECTOR, with the LSB being transmitted first. RATE LENGTH SIGNAL TAIL (4 bits) (12 bits) (6 bits) R1 R2 R3 R4 R LSB MSB P â€œ0â€ â€œ0â€ â€œ0â€ â€œ0â€ â€œ0â€ â€œ0â€ 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 Transmit Order Figure 17-5â€”SIGNAL field bit assignment The process of generating the SIGNAL OFDM symbol is illustrated in I.1.4. 17.3.4.2 RATE field The bits R1â€“R4 shall be set, dependent on RATE, according to the values in Table 17-6. Table 17-6â€”Contents of the SIGNAL field Rate (Mb/s) Rate (Mb/s) Rate (Mb/s) R1â€“R4 (20 MHz channel (10 MHz channel (5 MHz channel spacing) spacing) spacing) 1101 6 3 1.5 1111 9 4.5 2.25 0101 12 6 3 0111 18 9 4.5 1001 24 12 6 2290 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 17-6â€”Contents of the SIGNAL field (continued) Rate (Mb/s) Rate (Mb/s) Rate (Mb/s) R1â€“R4 (20 MHz channel (10 MHz channel (5 MHz channel spacing) spacing) spacing) 1011 36 18 9 0001 48 24 12 0011 54 27 13.5 17.3.4.3 PHY LENGTH field The PHY LENGTH field shall be an unsigned 12-bit integer that indicates the number of octets in the PSDU that the MAC is currently requesting the PHY to transmit. This value is used by the PHY to determine the number of octet transfers that will occur between the MAC and the PHY after receiving a request to start transmission. The transmitted value shall be determined from the LENGTH parameter in the TXVECTOR issued with the PHY-TXSTART.request primitive described in 8.3.5.5. The LSB shall be transmitted first in time. This field shall be encoded by the convolutional encoder described in 17.3.5.6. 17.3.4.4 Parity (P), Reserved (R), and SIGNAL TAIL fields Bit 4 is reserved. It shall be set to 0 on transmit and ignored on receive. Bit 17 shall be a positive parity (even parity) bit for bits 0â€“16. The bits 18â€“23 constitute the SIGNAL TAIL field, and all 6 bits shall be set to 0. 17.3.5 DATA field 17.3.5.1 General The DATA field contains the SERVICE field, the PSDU, the TAIL bits, and the PAD bits, if needed, as described in 17.3.5.3 and 17.3.5.4. All bits in the DATA field are scrambled, as described in 17.3.5.5. 17.3.5.2 SERVICE field The SERVICE field has 16 bits, which shall be denoted as bits 0â€“15. The bit 0 shall be transmitted first in time. The bits from 0â€“6 of the SERVICE field, which are transmitted first, are set to 0s and are used to synchronize the descrambler in the receiver. The remaining 9 bits (7â€“15) of the SERVICE field shall be reserved for future use. All reserved bits shall be set to 0 on transmission and ignored on reception. Refer to Figure 17-6. Scrambler Initialization Reserved SERVICE Bits R: Reserved â€œ0â€ â€œ0â€ â€œ0â€ â€œ0â€ â€œ0â€ â€œ0â€ â€œ0â€ R R R R R R R R R 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Transmit Order Figure 17-6â€”SERVICE field bit assignment 2291 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 17.3.5.3 PPDU TAIL field The PPDU TAIL field shall be six bits of 0, which are required to return the convolutional encoder to the zero state. This procedure improves the error probability of the convolutional decoder, which relies on future bits when decoding and which may be not be available past the end of the message. The PPDU TAIL field shall be produced by replacing six scrambled zero bits following the message end with six nonscrambled zero bits. 17.3.5.4 Pad bits (PAD) The number of bits in the DATA field shall be a multiple of NCBPS, the number of coded bits in an OFDM symbol (48, 96, 192, or 288 bits). To achieve that, the length of the message is extended so that it becomes a multiple of NDBPS, the number of data bits per OFDM symbol. At least 6 bits are appended to the message, in order to accommodate the TAIL bits, as described in 17.3.5.3. The number of OFDM symbols, NSYM; the number of bits in the DATA field, NDATA; and the number of pad bits, NPAD, are computed from the length of the PSDU (LENGTH) as follows: N SYM = 16 + 8 LENGTH + 6- ------------------------------------------------------ (17-11) N DBPS NDATA = NSYM NDBPS (17-12) NPAD = NDATA â€“ (16 + 8 LENGTH + 6) (17-13) The appended bits (â€œpad bitsâ€) are set to 0 and are subsequently scrambled with the rest of the bits in the DATA field. An example of a DATA field that contains the SERVICE field, DATA, tail, and pad bits is given in I.1.5.1. 17.3.5.5 PHY DATA scrambler and descrambler The DATA field, composed of SERVICE, PSDU, tail, and pad parts, shall be scrambled with a length-127 PPDU-synchronous scrambler. The octets of the PSDU are placed in the transmit serial bit stream, bit 0 first and bit 7 last. The PPDU synchronous scrambler uses the generator polynomial S(x) as follows and is illustrated in Figure 17-7: 7 4 S x = x +x +1 (17-14) During bits 0-6 of Scrambling Sequence when CH_BANDWIDTH_IN_NON_HT is First 7 bits of Scrambling present Sequence as defined in Table 17-7 Data In X7 X6 X5 X4 X3 X2 X 1 Scrambled Data Out Figure 17-7â€”Data scrambler 2292 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The 127-bit sequence generated repeatedly by the scrambler shall be (leftmost used first), 00001110 11110010 11001001 00000010 00100110 00101110 10110110 00001100 11010100 11100111 10110100 00101010 11111010 01010001 10111000 1111111, when the all 1s initial state is used. The same scrambler is used to scramble transmit data and to descramble receive data. If the TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT is not present, when transmitting, the initial state of the scrambler shall be set to a pseudorandom nonzero state. If the TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT is present, â€” The first 7 bits of the scrambling sequence shall be set as shown in Table 17-7 (with field values defined in Table 17-8 and Table 17-10) and shall be also used to initialize the state of the scrambler â€” The scrambler with this initialization shall generate the remainder (i.e., after the first 7 bits) of the scrambling sequence as shown in Figure 17-7 â€” CH_BANDWIDTH_IN_NON_HT is transmitted LSB first. For example, if CBW80 has a value of 2, which is â€˜10â€™ in binary representation, then B5=0 and B6=1 Table 17-7â€”Contents of the first 7 bits of the scrambling sequence First 7 bits of scrambling sequence B0 B3 B4 B5 B6 Parameter Condition Transmit order TXVECTOR CH_BANDWIDTH_I 5-bit pseudorandom nonzero integer if CH_BANDWIDTH_ N_NON_HT is CH_BANDWIDTH_IN_NON_HT equals CBW20 IN_NON_HT present and and a 5-bit pseudorandom integer otherwise DYN_BANDWIDTH _IN_NOT_HT is not present in TXVECTOR TXVECTOR CH_BANDWIDTH_I 4-bit pseudorandom DYN_BANDWIDTH N_NON_HT is nonzero integer if _IN_NON_HT present and CH_BANDWIDTH_IN_ DYN_BANDWIDTH NON_HT equals CBW20 _IN_NOT_HT is and present in DYN_BANDWIDTH_IN TXVECTOR _NON_HT equals Static, and a 4-bit pseudorandom integer otherwise RXVECTOR CH_BANDWIDTH_I â€” DYN_BANDWIDTH CbwInNonHtTemp is N_NON_HT and _IN_NON_HT set to this subfield of DYN_BANDWIDTH first 7 bits of _IN_NOT_HT are scrambling sequence; present in then RXVECTOR CbwInNonHtTemp is mapped according to Table 17-9 to CH_BANDWIDTH_ IN_NON_HT 2293 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 17-8â€”TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT values Enumerated value Value CBW20 0 CBW40 1 CBW80 2 CBW160 or CBW80+80 3 During reception by a VHT STA, the CbwInNonHtTemp variable shall be set to selected bits in the scrambling sequence as shown in Table 17-7 and then mapped as shown in Table 17-9 to the RXVECTOR parameter CH_BANDWIDTH_IN_NON_HT. During reception by a VHT STA, the RXVECTOR parameter DYN_BANDWIDTH_IN_NON_HT shall be set to selected bits in the scrambling sequence as shown in Table 17-7. The fields shall be interpreted as being sent LSB-first. Table 17-9â€”RXVECTOR parameter CH_BANDWIDTH_IN_NON_HT values CbwInNonHtTemp dot11CurrentChannelCenter RXVECTOR parameter (see Table 17-7) FrequencyIndex1 CH_BANDWIDTH_IN_NON_HT 0 0 CBW20 1 0 CBW40 2 0 CBW80 3 0 CBW160 3 1 to 200 CBW80+80 Table 17-10â€”DYN_BANDWIDTH_IN_NON_HT values Enumerated value Value Static 0 Dynamic 1 NOTE 1â€”The receiving PHY cannot determine whether the CH_BANDWIDTH_IN_NON_HT and DYN_BANDWIDTH_IN_NON_HT parameters were present in the TXVECTOR of the transmitting PHY; therefore, the receiving PHY in a VHT STA always includes values for the CH_BANDWIDTH_IN_NON_HT and DYN_BANDWIDTH_IN_NON_HT parameters in the RXVECTOR if the detected PPDU is a non-HT PPDU. It is the responsibility of the MAC to determine the validity of the RXVECTOR parameters CH_BANDWIDTH_IN_NON_HT and DYN_BANDWIDTH_IN_NON_HT. NOTE 2â€”The receiving PHY cannot determine whether the TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT was present, but it does not matter since descrambling the DATA field is the same either way. 2294 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The seven LSBs of the SERVICE field shall be set to all 0s prior to scrambling to enable estimation of the initial state of the scrambler in the receiver. An example of the scrambler output is illustrated in I.1.5.2 with CH_BANDWIDTH_IN_NON_HT not present. 17.3.5.6 Convolutional encoder The DATA field, composed of SERVICE, PSDU, tail, and pad parts, shall be coded with a convolutional encoder of coding rate R = 1/2, 2/3, or 3/4, corresponding to the TXVECTOR parameter RATE. The convolutional encoder shall use the industry-standard generator polynomials, g0 = 1338 and g1 = 1718, of rate R = 1/2, as shown in Figure 17-8. The bit denoted as â€œAâ€ shall be output from the encoder before the bit denoted as â€œB.â€ Higher rates are derived from it by employing â€œpuncturing.â€ Puncturing is a procedure for omitting some of the encoded bits in the transmitter (thus reducing the number of transmitted bits and increasing the coding rate) and inserting a dummy â€œzeroâ€ metric into the convolutional decoder on the receive side in place of the omitted bits. The puncturing patterns are illustrated in Figure 17-9. Decoding by the Viterbi algorithm is recommended. An example of encoding operation is shown in I.1.6.1. Figure 17-8â€”Convolutional encoder (k = 7) 2295 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Punctured Coding (r = 3/4) Source Data X0 X1 X2 X3 X4 X5 X6 X7 X8 A0 A1 A2 A3 A4 A5 A6 A7 A8 Encoded Data Stolen Bit B0 B1 B2 B3 B4 B5 B6 B7 B8 Bit Stolen Data (sent/received data) A0 B0 A1 B2 A3 B3 A4 B5 A6 B6 A7 B8 A0 A1 A2 A3 A4 A5 A6 A7 A8 Bit Inserted Data Inserted Dummy Bit B0 B1 B2 B3 B4 B5 B6 B7 B8 Decoded Data y0 y1 y2 y3 y4 y5 y6 y7 y8 Punctured Coding (r = 2/3) Source Data X0 X1 X2 X3 X4 X5 A0 A1 A2 A3 A4 A5 Encoded Data Stolen Bit B0 B1 B2 B3 B4 B5 Bit Stolen Data (sent/received data) A0 B0 A1 A2 B2 A3 A4 B4 A5 A0 A1 A2 A3 A4 A5 Bit Inserted Data Inserted Dummy Bit B0 B1 B2 B3 B4 B5 Decoded Data y0 y1 y2 y3 y4 y5 Figure 17-9â€”Example of the bit-stealing and bit-insertion procedure (r = 3/4, 2/3) 2296 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 17.3.5.7 Data interleaving All encoded data bits shall be interleaved by a block interleaver with a block size corresponding to the number of bits in a single OFDM symbol, NCBPS. The interleaver is defined by a two-step permutation. The first permutation causes adjacent coded bits to be mapped onto nonadjacent subcarriers. The second causes adjacent coded bits to be mapped alternately onto less and more significant bits of the constellation and, thereby, long runs of low reliability (LSB) bits are avoided. The index of the coded bit before the first permutation shall be denoted by k; i shall be the index after the first and before the second permutation; and j shall be the index after the second permutation, just prior to modulation mapping. The first permutation is defined by the rule i = (NCBPS/16) (k mod 16) + k 16 k = 0,1,â€¦,NCBPS â€“ 1 (17-15) The second permutation is defined by the rule -i + i + N CBPS â€“ --------------- j= s 16 i mod s i = 0,1,â€¦ NCBPS â€“ 1 (17-16) s N CBPS The value of s is determined by the number of coded bits per subcarrier, NBPSC, according to s = max(NBPSC/2,1) (17-17) The deinterleaver, which performs the inverse relation, is also defined by two permutations. Here the index of the original received bit before the first permutation shall be denoted by j; i shall be the index after the first and before the second permutation; and k shall be the index after the second permutation, just prior to delivering the coded bits to the convolutional (Viterbi) decoder. The first permutation is defined by the rule i = s 16 j- j s + j + -------------- mod s j = 0,1,â€¦ NCBPS â€“ 1 (17-18) N CBPS where s is defined in Equation (17-17). This permutation is the inverse of the permutation described in Equation (17-16). The second permutation is defined by the rule k = 16 i â€“ N CBPS â€“ 1 16 i- , i = 0,1,â€¦ N -------------- CBPS â€“ 1 (17-19) N CBPS This permutation is the inverse of the permutation described in Equation (17-15). An example of interleaving operation is illustrated in I.1.6.2. 2297 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 17.3.5.8 Subcarrier modulation mapping The OFDM subcarriers shall be modulated by using BPSK, QPSK, 16-QAM, or 64-QAM, depending on the RATE requested. The encoded and interleaved binary serial input data shall be divided into groups of NBPSC (1, 2, 4, or 6) bits and converted into complex numbers representing BPSK, QPSK, 16-QAM, or 64-QAM constellation points. The conversion shall be performed according to Gray-coded constellation mappings, illustrated in Figure 17-10, with the input bit, B0, being the earliest in the stream. The output values, d, are formed by multiplying the resulting (I+jQ) value by a normalization factor KMOD, as described in Equation (17-20). d = (I + jQ) KMOD (17-20) The normalization factor, KMOD, depends on the base modulation mode, as prescribed in Table 17-11. Note that the modulation type can be different from the start to the end of the transmission, as the signal changes from SIGNAL to DATA, as shown in Figure 17-1. The purpose of the normalization factor is to achieve the same average power for all mappings. In practical implementations, an approximate value of the normalization factor may be used, as long as the device complies with the modulation accuracy requirements described in 17.3.9.7. Table 17-11â€”Modulation-dependent normalization factor KMOD Modulation KMOD BPSK 1 QPSK 1/ 2 16-QAM 1/ 10 64-QAM 1/ 2 2298 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications BPSK Q 16-QAM Q B0 B1 B2 B3 B0 +1 00 10 01 10 11 10 10 10 0 1 +3 â€“1 +1 I â€“1 00 11 01 11 11 11 10 11 +1 â€“3 â€“1 +1 +3 I QPSK 00 01 01 01 11 01 10 01 Q B0 B1 â€“1 01 11 +1 00 00 01 00 11 00 10 00 â€“3 â€“1 +1 00 10 I â€“1 64-QAM Q B0B1B2 B3B4B5 000 100 001 100 011 100 010 100 110 100 111 100 101 100 100 100 +7 000 101 001 101 011 101 010 101 110 101 111 101 101 101 100 101 +5 000 111 001 111 011 111 010 111 110 111 111 111 101 111 100 111 +3 000 110 001 110 011 110 010 110 110 110 111 110 101 110 100 110 +1 â€“7 â€“5 â€“3 â€“1 +1 +3 +5 +7 000 010 001 010 011 010 010 010 110 010 111 010 101 010 100 010 I â€“1 000 011 001 011 011 011 010 011 110 011 111 011 101 011 100 011 â€“3 000 001 001 001 011 001 010 001 110 001 111 001 101 001 100 001 â€“5 000 000 001 000 011 000 010 000 110 000 111 000 101 000 100 000 â€“7 Figure 17-10â€”BPSK, QPSK, 16-QAM, and 64-QAM constellation bit encoding 2299 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications For BPSK, B0 determines the I value, as illustrated in Table 17-12. For QPSK, B0 determines the I value and B1 determines the Q value, as illustrated in Table 17-13. For 16-QAM, B0B1 determines the I value and B2B3 determines the Q value, as illustrated in Table 17-14. For 64-QAM, B0B1B2 determines the I value and B3B4B5 determines the Q value, as illustrated in Table 17-15. Table 17-12â€”BPSK encoding table Input bit (B0) I-out Q-out 0 â€“1 0 1 1 0 Table 17-13â€”QPSK encoding table Input bit (B0) I-out Input bit (B1) Q-out 0 â€“1 0 â€“1 1 1 1 1 Table 17-14â€”16-QAM encoding table Input bits (B0 B1) I-out Input bits (B2 B3) Q-out 00 â€“3 00 â€“3 01 â€“1 01 â€“1 11 1 11 1 10 3 10 3 Table 17-15â€”64-QAM encoding table Input bits (B0 B1 B2) I-out Input bits (B3 B4 B5) Q-out 000 â€“7 000 â€“7 001 â€“5 001 â€“5 011 â€“3 011 â€“3 010 â€“1 010 â€“1 110 1 110 1 111 3 111 3 101 5 101 5 100 7 100 7 2300 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 17.3.5.9 Pilot subcarriers In each OFDM symbol, four of the subcarriers are dedicated to pilot signals in order to make the coherent detection robust against frequency offsets and phase noise. These pilot signals shall be put in subcarriers â€“21, â€“7, 7, and 21. The pilots shall be BPSK modulated by a pseudo-binary sequence to prevent the generation of spectral lines. The contribution of the pilot subcarriers to each OFDM symbol is described in 17.3.5.10. 17.3.5.10 OFDM modulation The stream of complex numbers is divided into groups of NSD = 48 complex numbers. This shall be denoted by writing the complex number dk,n, which corresponds to subcarrier k of OFDM symbol n, as follows: dk n d k + N SD n, k = 0, ... NSD â€“ 1, n = 0, ... NSYM â€“ 1 (17-21) The number of OFDM symbols, NSYM, was introduced in 17.3.5.4. An OFDM symbol, rDATA,n(t), is defined as N SD â€“ 1 r DATA n t = w TSYM t d k n exp (j2 M k F t â€“ T GI (17-22) k=0 N ST 2 + pn + 1 P k exp j2 k F t â€“ T GI k = â€“ N ST 2 where the function, M(k), defines a mapping from the logical subcarrier number 0 to 47 into frequency offset index â€“26 to 26, while skipping the pilot subcarrier locations and the 0th (dc) subcarrier. k â€“ 26 0 k 4 k â€“ 25 5 k 17 M k = k â€“ 24 18 k 23 (17-23) k â€“ 23 24 k 29 k â€“ 22 30 k 42 k â€“ 21 43 k 47 The contribution of the pilot subcarriers for the nth OFDM symbol is produced by inverse Fourier transform of sequence P, given by Pâ€“26, 26 = {0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, â€“1, 0, 0, 0, 0, 0} (17-24) 2301 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The polarity of the pilot subcarriers is controlled by the sequence, pn, which is a cyclic extension of the 127 elements sequence and is given by p0..126v = {1,1,1,1, â€“1,â€“1,â€“1,1, â€“1,â€“1,â€“1,â€“1, 1,1,â€“1,1, â€“1,â€“1,1,1, â€“1,1,1,â€“1, 1,1,1,1, 1,1,â€“1,1, 1,1,â€“1,1, 1,â€“1,â€“1,1, 1,1,â€“1,1, â€“1,â€“1,â€“1,1, â€“1,1,â€“1,â€“1, 1,â€“1,â€“1,1, 1,1,1,1, â€“1,â€“1,1,1, â€“1,â€“1,1,â€“1, 1,â€“1,1,1, â€“1,â€“1,â€“1,1, 1,â€“1,â€“1,â€“1, â€“1,1,â€“1,â€“1, 1,â€“1,1,1, 1,1,â€“1,1, â€“1,1,â€“1,1, â€“1,â€“1,â€“1,â€“1, â€“1,1,â€“1,1, 1,â€“1,1,â€“1, 1,1,1,â€“1, â€“1,1,â€“1,â€“1, â€“1,1,1,1, â€“1,â€“1,â€“1,â€“1, â€“1,â€“1,â€“1} (17-25) The sequence pn is generated by the scrambler defined by Figure 17-7 when the all 1s initial state is used, and by replacing all 1s with â€“1 and all 0s with 1. Each sequence element is used for one OFDM symbol. The first element, p0, multiplies the pilot subcarriers of the SIGNAL symbol, while the elements from p1 on are used for the DATA symbols. The subcarrier frequency allocation is shown in Figure 17-11. To avoid difficulties in D/A and A/D converter offsets and carrier feedthrough in the RF system, the subcarrier falling at DC (0th subcarrier) is not used. d0 d4 Pâ€“21 d5 d17Pâ€“7 d18 d23DC d24 d29 P7 d30 d42 P21 d43 d47 â€“26 â€“21 â€“7 0 7 21 26 Subcarrier Numbers Figure 17-11â€”Subcarrier frequency allocation The concatenation of NSYM OFDM symbols is written as N SYM â€“ 1 r DATA t = r DATA n t â€“ nT SYM (17-26) n=0 An example of mapping into symbols is shown in I.1.6.3, as well as the scrambling of the pilot signals (see I.1.7). The final output of these operations is also shown in I.1.8. 17.3.6 CCA The PHY shall provide the capability to perform CCA and report the result to the MAC. The CCA mechanism shall detect a â€œmedium busyâ€ condition with requirements specified in 17.3.10.6 and 17.3.12. The PHY issues the PHY-CCA.indication primitive to provide this medium status report to the MAC. 17.3.7 PHY data modulation and modulation rate change The PHY preamble shall be transmitted using an OFDM modulated fixed waveform. The SIGNAL field, BPSK-OFDM modulated with coding rate 1/2, shall indicate the modulation and coding rate that shall be used to transmit the MPDU. The transmitter (receiver) shall initiate the modulation (demodulation) constellation and the coding rate according to the RATE indicated in the SIGNAL field. The MPDU transmission rate shall be set by the DATARATE parameter in the TXVECTOR, issued with the PHY- TXSTART.request primitive described in 17.2.2. 2302 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 17.3.8 PHY operating specifications (general) 17.3.8.1 General General specifications for the BPSK OFDM, QPSK OFDM, 16-QAM OFDM, and 64-QAM OFDM PHY sublayers are provided in 17.3.8.2 to 17.3.8.7. These specifications apply to both the receive and transmit functions and general operation of the OFDM PHY. 17.3.8.2 Outline description The general block diagram of the transmitter and receiver for the OFDM PHY is shown in Figure 17-12. Major specifications for the OFDM PHY are listed in Table 17-16. Interleaving+ Symbol FEC IFFT GI Wave I/Q Coder Mapping Addition Mod. Shaping HPA AGC Amp I/Q Remove Demapping+ FEC Det. FFT Deinterleaving GI Decoder LNA Rx Lev. Det. AFC Clock Recovery Figure 17-12â€”Transmitter and receiver block diagram for the OFDM PHY Table 17-16â€”Major parameters of the OFDM PHY 6, 9, 12, 18, 24, 36, 48, 3, 4.5, 6, 9, 12, 18, 24, 1.5, 2.25, 3, 4.5, 6, 9, 12, and 54 Mb/s and 27 Mb/s and 13.5 Mb/s (6, 12, and 24 Mb/s are (3, 6, and 12 Mb/s are (1.5, 3, and 6 Mb/s are Information data rate mandatory) mandatory) mandatory) (20 MHz channel (10 MHz channel (5 MHz channel spacing) spacing) spacing) Modulation BPSK OFDM BPSK OFDM BPSK OFDM QPSK OFDM QPSK OFDM QPSK OFDM 16-QAM OFDM 16-QAM OFDM 16-QAM OFDM 64-QAM OFDM 64-QAM OFDM 64-QAM OFDM Error correcting code K = 7 (64 states) K = 7 (64 states) K = 7 (64 states) convolutional code convolutional code convolutional code Coding rate 1/2, 2/3, 3/4 1/2, 2/3, 3/4 1/2, 2/3, 3/4 Number of subcarriers 52 52 52 OFDM symbol duration 4.0 Âµs 8.0 Âµs 16.0 Âµs GI 0.8 Âµsa (TGI) 1.6 Âµs (TGI) 3.2 Âµs (TGI) Occupied bandwidth 16.6 MHz 8.3 MHz 4.15 MHz aRefer to 17.3.2.5. 2303 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 17.3.8.3 Regulatory requirements WLANs implemented in accordance with this standard are subject to equipment certification and operating requirements established by regional and national regulatory administrations. The PHY specification establishes minimum technical requirements for interoperability, based upon established regulations at the time this standard was issued. These regulations are subject to revision, or may be superseded. Requirements that are subject to local geographic regulations are annotated within the PHY specification. Regulatory requirements that do not affect interoperability are not addressed in this standard. Implementers are referred to the regulatory sources in Annex D for further information. Operation in countries within defined regulatory domains may be subject to additional or alternative national regulations. 17.3.8.4 Operating channel frequencies 17.3.8.4.1 Operating frequency range The OFDM PHY shall not operate in frequency bands not allocated by a regulatory body in its operational region. Regulatory requirements for a given frequency band are set by the regulatory authority responsible for spectrum management in a given geographic region or domain. The particular channelization to be used for this standard is dependent on such allocation, as well as the associated regulations for use of the allocations. These regulations are subject to revision, or may be superseded. In some regulatory domains, several frequency bands may be available for OFDM PHY-based WLANs. These bands may be contiguous or not, and different regulatory limits may be applicable. An OFDM PHY shall support at least one frequency band in at least one regulatory domain. The support of specific regulatory domains, and bands within the domains, shall be indicated by PLME attributes dot11RegDomainsImplementedValue and dot11FrequencyBandsImplemented. The PHYCONFIG_VECTOR carried in a PHY-CONFIG.request primitive for an OFDM PHY contains an OPERATING_CHANNEL parameter, which identifies the operating channel. The PHY shall set dot11CurrentFrequency to the value of this parameter. 17.3.8.4.2 Channel numbering Channel center frequencies are defined at every integer multiple of 5 MHz above the channel starting frequency. The relationship between center frequency and channel number is given by Equation (17-27): Channel center frequency = Channel starting frequency + 5 nch (MHz) (17-27) where nch = 1,â€¦200. Channel starting frequency is defined as dot11ChannelStartingFactor Ã— 500 kHz or is defined as 5 GHz for systems where dot11OperatingClassesRequired is false or not defined. For example, dot11ChannelStartingFactor = 10000 indicates that Channel 0 center frequency is 5.000 GHz. A channel center frequency of 5.000 GHz shall be indicated by dot11ChannelStartingFactor = 8000 and nch = 200. An SME managing multiple channel sets can change the channel set being managed by changing dot11ChannelStartingFactor. This definition provides a unique numbering system for all channels with 5 MHz between center frequencies, as well as the flexibility to define channelization sets for all current and future regulatory domains. 2304 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 17.3.8.4.3 Channelization The set of valid operating channel numbers by regulatory domain is defined in Annex E. As shown in Figure 17-11, no subcarrier is allocated on the channel center frequency. 17.3.8.5 Transmit and receive in-band and out-of-band spurious emissions The OFDM PHY shall comply with in-band and out-of-band spurious emissions as set by regulatory bodies. 17.3.8.6 Slot time The value of the slot time is found in Table 17-21. 17.3.8.7 Transmit and receive impedance at the antenna connector The impedance at the transmit and receive antenna connector(s) shall be 50 if the connector is exposed. 17.3.9 PHY transmit specifications 17.3.9.1 General The transmit specifications associated with the PHY sublayer are described in 17.3.9.2 to 17.3.9.8. 17.3.9.2 Transmit power levels The maximum allowable output power is measured in accordance with practices specified by the appropriate regulatory bodies. 17.3.9.3 Transmit spectrum mask The transmit spectrum mask by regulatory domain is defined in Annex D and Annex E. NOTE 1â€”In the presence of additional regulatory restrictions, the device needs to meet both the regulatory requirements and the mask defined here, i.e., its emissions need to be no higher at any frequency offset than the minimum of the values specified in the regulatory and default masks. NOTE 2â€”For rules regarding TX center frequency leakage levels by VHT STAs, see 21.3.17.4.2. For operation using 20 MHz channel spacing, the transmitted spectrum shall have a 0 dBr (dB relative to the maximum spectral density of the signal) bandwidth not exceeding 18 MHz, â€“20 dBr at 11 MHz frequency offset, â€“28 dBr at 20 MHz frequency offset, and the maximum of â€“40 dBr and â€“53 dBm/MHz at 30 MHz frequency offset and above. The transmitted spectral density of the transmitted signal shall fall within the spectral mask, as shown in Figure 17-13. The measurements shall be made using a 100 kHz resolution bandwidth and a 30 kHz video bandwidth. For operation using 10 MHz channel spacing, the transmitted spectrum shall have a 0 dBr bandwidth not exceeding 9 MHz, â€“20 dBr at 5.5 MHz frequency offset, â€“28 dBr at 10 MHz frequency offset, and the maximum of â€“40 dBr and â€“50 dBm/MHz at 15 MHz frequency offset and above. The transmitted spectral density of the transmitted signal shall fall within the spectral mask, as shown in Figure 17-14. The measurements shall be made using a 100 kHz resolution bandwidth and a 30 kHz video bandwidth. 2305 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Power Spectral Density (dB) Transmit Spectrum Mask (not to scale) â€“20 dBr Typical Signal Spectrum â€“28 dBr (an example) â€“40 dBr â€“30 â€“20 â€“11 â€“9 fc 9 11 20 30 Frequency (MHz) Figure 17-13â€”Transmit spectrum mask for 20 MHz transmission Power Spectral Density (dB) Transmit Spectrum Mask (not to scale) â€“20 dBr Typical Signal Spectrum â€“28 dBr (an example) â€“40 dBr â€“15 â€“10 â€“5.5 -4.5 fc 4.5 5.5 10 15 Frequency (MHz) Figure 17-14â€”Transmit spectrum mask for 10 MHz transmission For operation using 5 MHz channel spacing, the transmitted spectrum shall have a 0 dBr bandwidth not exceeding 4.5 MHz, â€“20 dBr at 2.75 MHz frequency offset, â€“28 dBr at 5 MHz frequency offset, and the maximum of â€“40 dBr and â€“47 dBm/MHz at 7.5 MHz frequency offset and above. The transmitted spectral density of the transmitted signal shall fall within the spectral mask, as shown in Figure 17-15. The measurements shall be made using a 100 kHz resolution bandwidth and a 30 kHz video bandwidth. 2306 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Power Spectral Density (dB) Transmit Spectrum Mask (not to scale) â€“20 dBr Typical Signal Spectrum â€“28 dBr (an example) â€“40 dBr â€“7.5 â€“5 â€“2.75 â€“2.25 fc 2.25 2.75 5 7.5 Frequency (MHz) Figure 17-15â€”Transmit spectrum mask for 5 MHz transmission 17.3.9.4 Transmission spurious Spurious transmissions shall comply with national regulations. 17.3.9.5 Transmit center frequency tolerance The transmitted center frequency tolerance shall be Â±20 ppm maximum for 20 MHz and 10 MHz channels and shall be Â±10 ppm maximum for 5 MHz channels. The transmit center frequency and the symbol clock frequency shall be derived from the same reference oscillator. 17.3.9.6 Symbol clock frequency tolerance The symbol clock frequency tolerance shall be Â±20 ppm maximum for 20 MHz and 10 MHz channels, and shall be Â±10 ppm maximum for 5 MHz channels. The transmit center frequency and the symbol clock frequency shall be derived from the same reference oscillator. 17.3.9.7 Modulation accuracy 17.3.9.7.1 Introduction Transmit modulation accuracy specifications are described in 17.3.9.7. The test method is described in 17.3.9.8. 17.3.9.7.2 Transmitter center frequency leakage For VHT STAs, the requirements on transmitter center frequency leakage are defined in 21.3.17.4.2; otherwise, the requirements are defined in this subclause. Certain transmitter implementations may cause leakage of the center frequency component. Such leakage (which manifests itself in a receiver as energy in the center frequency component) shall not exceed â€“15 dB relative to overall transmitted power or, equivalently, +2 dB relative to the average energy of the rest of the subcarriers. The data for this test shall be derived from the channel estimation phase. 2307 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 17.3.9.7.3 Transmitter spectral flatness The average energy of the constellations in each of the spectral lines â€“16.. â€“1 and +1.. +16 shall deviate no more than Â± 4 dB from their average energy. The average energy of the constellations in each of the spectral lines â€“26.. â€“17 and +17.. +26 shall deviate no more than +4/â€“6 dB from the average energy of spectral lines â€“16.. â€“1 and +1.. +16. The data for this test shall be derived from the channel estimation step. 17.3.9.7.4 Transmitter constellation error The relative constellation RMS error, averaged over subcarriers and OFDM PPDUs, shall not exceed a data- rate dependent value according to Table 17-17. Table 17-17â€”Allowed relative constellation error versus data rate Relative constellation error Coding rate Modulation (dB) (R) â€“5 BPSK 1/2 â€“8 BPSK 3/4 â€“10 QPSK 1/2 â€“13 QPSK 3/4 â€“16 16-QAM 1/2 â€“19 16-QAM 3/4 â€“22 64-QAM 2/3 â€“25 64-QAM 3/4 17.3.9.8 Transmit modulation accuracy test The transmit modulation accuracy test shall be performed by instrumentation capable of converting the transmitted signal into a stream of complex samples at 20 Msample/s or more, with sufficient accuracy in terms of I/Q arm amplitude and phase balance, dc offsets, phase noise, etc. A possible embodiment of such a setup is converting the signal to a low IF with a microwave synthesizer, sampling the signal with a digital oscilloscope and decomposing it digitally into quadrature components. The sampled signal shall be processed in a manner similar to an actual receiver, according to the following steps, or an equivalent procedure: a) Start of frame shall be detected. b) Transition from short sequences to channel estimation sequences shall be detected, and fine timing (with one sample resolution) shall be established. c) Coarse and fine frequency offsets shall be estimated. d) The packet shall be derotated according to estimated frequency offset. e) The complex channel response coefficients shall be estimated for each of the subcarriers. f) For each of the data OFDM symbols: transform the symbol into subcarrier received values, estimate the phase from the pilot subcarriers, derotate the subcarrier values according to estimated phase, and divide each subcarrier value with a complex estimated channel response coefficient. 2308 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications g) For each data-carrying subcarrier, find the closest constellation point and compute the Euclidean distance from it. h) Compute the RMS average of all errors in a packet. It is given by LP 52 2 2 Nf I i j k â€“ I0 i j k + Q i j k â€“ Q0 i j k =1 k=1 j---------------------------------------------------------------------------------------------------------------------------------------------------- - 52L P P 0 =1 Error RMS = i------------------------------------------------------------------------------------------------------------------------------------------------------------------ - (17-28) Nf where LP is the length of the packet; Nf is the number of frames for the measurement; (I0(i,j,k), Q0(i,j,k))denotes the ideal symbol point of the ith frame, jth OFDM symbol of the frame, kth sub- carrier of the OFDM symbol in the complex plane; (I(i,j,k), Q(i,j,k))denotes the observed point of the ith frame, jth OFDM symbol of the frame, kth subcarrier of the OFDM symbol in the complex plane (see Figure 17-16); P0 is the average power of the constellation. The vector error on a phase plane is shown in Figure 17-16. The test shall be performed over at least 20 frames (Nf), and the RMS average shall be taken. The packets under test shall be at least 16 OFDM symbols long. Random data shall be used for the symbols. Q Measurement Symbol (I(i, j, k), Q(i, j, k)) Error Vector Magnitude (EVM) Ideal Symbol (I0(i, j, k), Q0(i, j, k)) Mean Power of Ideal Symbol (P0 = 1) I Figure 17-16â€”Constellation error 17.3.9.9 Time of Departure accuracy The Time of Departure accuracy test evaluates TIME_OF_DEPARTURE against aTxPHYTxStartRMS and aTxPHYTxStartRMS against TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH as defined Annex P with the following test parameters: 2309 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications fH â€“ fL â€” MULTICHANNEL_SAMPLING_RATE is 20 10 6 1 + ------------------- sample/s 20 MHz where fH is the nominal center frequency in Hz of the highest channel in the channel set fL is the nominal center frequency in Hz of the lowest channel in the channel set, the channel set is the set of channels upon which frames providing measurements are transmitted, the channel set comprises channels uniformly spaced across fH â€“ fL 50 MHz â€” FIRST_TRANSITION_FIELD is the Short symbols. â€” SECOND_TRANSITION_FIELD is the Long symbols. â€” TRAINING_FIELD is the Long symbols windowed in a manner which should approximate the win- dowing described in 17.3.2.5 with TTR = 100 ns for 20 MHz channel spacing, TTR = 200 ns for 10 MHz channel spacing and TTR = 400 ns for 5 MHz channel spacing. â€” TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH is 80 ns. NOTEâ€”The indicated windowing applies to the time of departure accuracy test equipment, and not the transmitter or receiver. 17.3.10 PHY receiver specifications 17.3.10.1 Introduction The receive specifications associated with the PHY sublayer are described in 17.3.10.2 to 17.3.10.6. 17.3.10.2 Receiver minimum input sensitivity The packet error ratio (PER) shall be 10% or less when the PSDU length is 1000 octets and the rate- dependent input level is as shown in Table 17-18. The minimum input levels are measured at the antenna connector (noise factor of 10 dB and 5 dB implementation margins are assumed). Table 17-18â€”Receiver performance requirements Minimum Minimum Minimum Alternate Adjacent sensitivity sensitivity sensitivity Coding adjacent channel (dBm) (dBm) (dBm) Modulation rate channel rejection (20 MHz (10 MHz (5 MHz (R) rejection (dB) channel channel channel (dB) spacing) spacing) spacing) BPSK 1/2 16 32 â€“82 â€“85 â€“88 BPSK 3/4 15 31 â€“81 â€“84 â€“87 QPSK 1/2 13 29 â€“79 â€“82 â€“85 QPSK 3/4 11 27 â€“77 â€“80 â€“83 16-QAM 1/2 8 24 â€“74 â€“77 â€“80 16-QAM 3/4 4 20 â€“70 â€“73 â€“76 64-QAM 2/3 0 16 â€“66 â€“69 â€“72 64-QAM 3/4 â€“1 15 â€“65 â€“68 â€“71 2310 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 17.3.10.3 Adjacent channel rejection The adjacent channel rejection shall be measured by setting the desired signalâ€™s strength 3 dB above the rate- dependent sensitivity specified in Table 17-18 and raising the power of the interfering signal until 10% PER is caused for a PSDU length of 1000 octets. The difference in power between the signals in the interfering channel and the desired channel is the corresponding adjacent channel rejection. The interfering signal in the adjacent channel shall be a signal compliant with the OFDM PHY, unsynchronized with the signal in the channel under test. In an OFDM PHY the corresponding rejection shall be no less than specified in Table 17-18. An optional enhanced performance specification is provided for systems requiring improved immunity to out-of-channel interfering emissions. If a STA has dot11ACRType equal to 2, the adjacent channel rejection shall be no less than specified in Table 17-19. The interfering signal in the adjacent channel shall be a signal compliant with the OFDM PHY, using transmit mask M (see D.2.4), unsynchronized with the signal in the channel under test. The corresponding minimum receiver sensitivities for each modulation and coding rate are the same as in Table 17-18. NOTEâ€”Transmit mask M is equivalent to class C (see D.2.2). Table 17-19â€”Optional enhanced receiver performance requirements Coding Adjacent channel Nonadjacent Modulation rate rejection channel rejection (R) (dB) (dB) BPSK 1/2 28 42 BPSK 3/4 27 41 QPSK 1/2 25 39 QPSK 3/4 23 37 16-QAM 1/2 20 34 16-QAM 3/4 16 30 64-QAM 2/3 12 26 64-QAM 3/4 11 25 17.3.10.4 Nonadjacent channel rejection The nonadjacent channel rejection shall be measured by setting the desired signalâ€™s strength 3 dB above the rate-dependent sensitivity specified in Table 17-18, and raising the power of the interfering signal until a 10% PER occurs for a PSDU length of 1000 octets. The difference in power between the signals in the interfering channel and the desired channel is the corresponding nonadjacent channel rejection. The interfering signal in the nonadjacent channel shall be a signal compliant with the OFDM PHY, unsynchronized with the signal in the channel under test. In an OFDM PHY, the corresponding rejection shall be no less than specified in Table 17-18. 2311 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications An optional enhanced performance specification is provided for systems requiring improved immunity to out-of-channel interfering emissions. If a STA has dot11ACRType equal to 2, the nonadjacent channel rejection shall be no less than specified in Table 17-19. The interfering signal in the nonadjacent channel shall be a signal compliant with the OFDM PHY, using transmit mask M (see D.2.4), unsynchronized with the signal in the channel under test. The corresponding minimum receiver sensitivities for each modulation and coding rate are the same as in Table 17-18. 17.3.10.5 Receiver maximum input level The receiver shall provide a maximum PER of 10% at a PSDU length of 1000 octets, for a maximum input level of â€“30 dBm measured at the antenna for any baseband modulation. 17.3.10.6 CCA requirements The PHY shall indicate a medium busy condition by issuing a PHY-CCA.indication primitive when the carrier sense/clear channel assessment (CS/CCA) mechanism detects a channel busy condition. For the operating classes requiring CCA-Energy Detect (CCA-ED), the PHY shall also indicate a medium busy condition when CCA-ED detects a channel busy condition. The start of a valid OFDM transmission at a receive level greater than or equal to the minimum modulation and coding rate sensitivity (â€“82 dBm for 20 MHz channel spacing, â€“85 dBm for 10 MHz channel spacing, and â€“88 dBm for 5 MHz channel spacing) shall cause CS/CCA to detect a channel busy condition with a probability > 90% within 4 s for 20 MHz channel spacing, 8 s for 10 MHz channel spacing, and 16 s for 5 MHz channel spacing. NOTEâ€”CS/CCA detect time is based on finding the short sequences in the preamble, so when TSYM doubles, so does CS/CCA detect time. Additionally, the CS/CCA mechanism shall detect a medium busy condition within 4 s of any signal with a received energy that is 20 dB above the minimum modulation and coding rate sensitivity (minimum modulation and coding rate sensitivity + 20 dB resulting in â€“62 dBm for 20 MHz channel spacing, â€“65 dBm for 10 MHz channel spacing, and â€“68 dBm for 5 MHz channel spacing). For improved spectrum sharing, CCA-ED is required in some bands. The behavior class indicating CCA-ED is given in Table D-2. The operating classes requiring the corresponding CCA-ED behavior class are given in E.1. The PHY of a STA that is operating within an operating class that requires CCA-ED shall operate with CCA-ED. CCA-ED shall detect a channel busy condition when the received signal strength exceeds the CCA-ED threshold as given by dot11OFDMEDThreshold. The CCA-ED thresholds for the operating classes requiring CCA-ED are subject to the criteria in D.2.5. NOTEâ€”The requirement to detect a channel busy condition for any signal 20 dB above the minimum modulation and coding rate sensitivity (minimum modulation and coding rate sensitivity + 20 dB resulting in â€“62 dBm for 20 MHz channel spacing, â€“65 dBm for 10 MHz channel spacing, and â€“68 dBm for 5 MHz channel spacing) is a mandatory energy detect requirement on all Clause 17 receivers. Support for CCA-ED is an additional requirement that relates specifically to the sensitivities described in D.2.5. 17.3.10.7 Received Channel Power Indicator Measurement The RCPI indicator is a measure of the received RF power in the selected channel for a received frame. This parameter shall be a measure by the PHY of the received RF power in the channel measured over the entire received frame or by other equivalent means that meet the specified accuracy. 2312 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The RCPI encoding is defined in 15.4.6.6. RCPI shall equal the received RF power within an accuracy of Â±5 dB (95% confidence interval) within the specified dynamic range of the receiver. The received RF power shall be determined assuming a receiver noise equivalent bandwidth equal to the channel bandwidth multiplied by 1.1. 17.3.11 Transmit PHY The transmit PHY is shown in Figure 17-17. In order to transmit data, the PHY-TXSTART.request primitive shall be enabled so that the PHY entity shall be in the transmit state. Further, the PHY shall be set to operate at the appropriate frequency through STA management via the PLME. Other transmit parameters, such as DATARATE and TX power, are set via the PHY SAP with the PHY- TXSTART.request(TXVECTOR) primitive, as described in 17.2.2. PHY-TXSTART.confirm PHY-TXEND.confirm PHY-TXEND.request PHY-TXSTART.request PHY-DATA.request PHY-DATAconfirm PHY-DATA.request PHY-DATAconfirm (TXVECTER) (TXSTATUS) MAC MPDU Tail Bit Bit Padding if Needed Header PSDU Scrambled + Encoded Training Symbols Header C-PSDU RATE Reserved LENGTH Parity Tail SERVICE Tail Pad bits 4 bits 1 bit 12 bits 1 bit 6 bits 16 bits PSDU 6 bits PHY PHY Preamble SIGNAL DATA 12 Symbols One OFDM Symbol Variable Number of OFDM Symbols Coded/OFDM Coded/OFDM (BPSK, r = 1/2) (RATE is indicated in SIGNAL) Figure 17-17â€”Transmit PHY 2313 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The PHY shall indicate a clear channel by issuing a PHY-CCA.indication(IDLE) primitive. The MAC considers this indication before issuing the PHY-TXSTART.request primitive. Transmission of the PPDU shall be initiated after receiving the PHY-TXSTART.request(TXVECTOR) primitive. The TXVECTOR elements for the PHY-TXSTART.request primitive are the PHY header parameters DATARATE, SERVICE, and LENGTH and the PHY parameters TXPWR_LEVEL_INDEX and TIME_OF_DEPARTURE_REQUESTED. The PHY is configured with the TXVECTOR elements DATARATE and TXPWR_LEVEL_INDEX. Transmission of the PHY preamble and PHY header, based on the parameters passed in the PHY- TXSTART.request primitive, shall be immediately initiated. Once PHY preamble transmission is started, the PHY entity shall immediately initiate PHY header encoding then data scrambling and data encoding, where the data shall be exchanged between the MAC and the PHY through a series of PHY-DATA.request(DATA) primitives issued by the MAC, and PHY-DATA.confirm primitives issued by the PHY. The modulation rate change, if any, shall be initiated from the SERVICE field data of the PHY header, as described in 17.3.2. The PHY proceeds with PSDU transmission through a series of data octet transfers from the MAC. The PHY header parameter, SERVICE, and PSDU are encoded by the convolutional encoder with the bit- stealing function described in 17.3.5.6. Transmission can be prematurely terminated by the MAC through the PHY-TXEND.request primitive. PHY-TXSTART shall be disabled by the issuance of the PHY- TXEND.request primitive. Normal termination occurs after the transmission of the final bit of the last PSDU octet, according to the number supplied in the OFDM PHY preamble LENGTH field. The packet transmission shall be completed and the PHY entity shall enter the receive state (i.e., PHY- TXSTART shall be disabled). Each PHY-TXEND.request primitive is acknowledged with a PHY-TXEND.confirm primitive from the PHY. If the coded PSDU (C-PSDU) length is not a multiple of the OFDM symbol length NCBPS, the PSDU is padded prior to scrambling and coding (see 17.3.5.4). In the PHY, the GI shall be inserted in every OFDM symbol as a countermeasure against severe delay spread. A typical state machine implementation of the transmit PHY is provided in Figure 17-18. Requests (.request) and confirmations (.confirm) are issued once with designated states. 2314 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications TX PSDU OCTET PHY-TXSTART.request(TXVECTOR) PHY-DATA.request Get octet from (DATA) MAC and encoding PHY-DATA.confirm Initialize length > 1 length = 1 set TX parameters TAIL APPEND Tail bits are appended TX Preamble TX training symbols BIT PADDING followed by the SIGNAL Bit padding if needed field, which consists of: 4 bits RATE, 1 bit Reserved, 12 bits LENGTH and TX SYMBOL 1 bit Parity PHY-TXSTART.confirm Set symbol bit count (TXSTATUS) TX PHYDATA Decrement Bit Change coding rate and modulation type, if Decrement bit count necessary by bits per symbol bit count > 0 TX encoded PHY header bit count = 0 includes: 16 bits SERVICE Decrement Length Decrement length count length > 0 SETUP MPDU TX PHY-TXSTART.confirm PHY-DATA.request length = 0 Set length count (DATA) Switch RX STATE A A At any stage in the above flow diagram, if a PHY-TXEND.request primitive is received. Figure 17-18â€”PHY transmit state machine 17.3.12 Receive PHY The receive PHY is shown in Figure 17-19. In order to receive data, the PHY-TXSTART.request primitive shall be disabled so that the PHY entity is in the receive state. Further, through STA management (via the PLME) the PHY is set to the appropriate frequency. Other receive parameters, such as RSSI, RCPI, and indicated DATARATE, may be accessed via the PHY SAP. 2315 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications (RXERROR,RXVECTOR) RX State PHY-RXEND.indication CS/CCA State PHY-DATA.indication PHY-DATA.indication PHY-CCA.indication PHY-CCA.indication PHY-RXSTART.indication (STATE=busy) (RXVECTOR) MAC (IDLE) MPDU Tail Bit Header PSDU Viterbi Decoding Delay Bit Removing Decoded+descrambled if Needed Header C-PSDU Measure RSSI RATE Reserved LENGTH Parity Tail SERVICE Tail Pad bits 4 bits 1 bit 12 bits 1 bit 6 bits 16 bits PSDU 6 bits PHY PHY Preamble SIGNAL DATA 12 Symbols One OFDM Symbol Variable Number of OFDM Symbols Coded/OFDM Coded/OFDM (BPSK, r = 1/2) (RATE is indicated in SIGNAL) Figure 17-19â€”Receive PHY Upon receiving the transmitted PHY preamble, the PHY measures the received signal strength level. This indicates activity to the MAC via PHY-CCA.indication primitive. A PHY-CCA.indication(BUSY) primitive shall be issued for reception of a signal prior to correct reception of the PPDU. The RSSI parameter reported to the MAC in the RXVECTOR. After a PHY-CCA.indication primitive is issued, the PHY entity shall begin receiving the training symbols and searching for the SIGNAL in order to set the length of the data stream, the demodulation type, and the decoding rate. If the PHY header reception is successful (and the SIGNAL field is completely recognizable and supported), a PHY-RXSTART.indication(RXVECTOR) primitive shall be issued. If dot11TimingMsmtActivated is true, the PHY shall do the following: â€” Complete receiving the PHY header and verify the validity of the PHY Header. â€” If the PHY header reception is successful (and the SIGNAL field is completely recognizable and supported), a PHY-RXSTART.indication(RXVECTOR) primitive shall be issued and RX_START_OF_FRAME_OFFSET parameter within the RXVECTOR shall be forwarded (see 17.2.3). A VHT STA shall include the CH_BANDWIDTH_IN_NON_HT and DYN_BANDWIDTH_IN_NON_HT parameters in the RXVECTOR within the PHY-RXSTART.indication(RXVECTOR) primitive. 2316 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NOTEâ€”The RX_START_OF_FRAME_OFFSET value is used as described in 6.3.57 in order to estimate when the start of the preamble for the incoming frame was detected on the medium at the receive antenna connector. The RXVECTOR associated with this primitive includes the SIGNAL field, the SERVICE field, the PSDU length in octets, and the RSSI. Also, in this case, the CCA of the OFDM PHY shall indicate a busy medium for the intended duration of the transmitted frame, as indicated by the LENGTH field. The received PSDU bits are assembled into octets, decoded, and presented to the MAC using a series of PHY-DATA.indication(DATA) primitive exchanges. The rate change indicated in the SIGNAL field shall be initiated from the SERVICE field data of the PHY header, as described in 17.3.2. The PHY shall proceed with PSDU reception. After the reception of the final bit of the last PSDU octet indicated by the PHY preamble LENGTH field, the receiver shall be returned to the RX IDLE state, as shown in Figure 17-19. A PHY-RXEND.indication(NoError) primitive shall be issued. In the event that a change in the RSSI causes the status of the CCA to return to the IDLE state before the complete reception of the PSDU, as indicated by the PHY LENGTH field, the error condition shall be reported to the MAC using a PHY-RXEND.indication(CarrierLost) primitive and the PHY receiver shall return to the RX IDLE state. The CCA of the OFDM PHY shall indicate a busy medium for the intended duration of the transmitted packet. If the indicated rate in the SIGNAL field is not receivable, a PHY-RXSTART.indication primitive shall not be issued. The PHY shall indicate the error condition by issuing a PHY- RXEND.indication(UnsupportedRate) primitive and hold CCA busy for the calculated duration of the PPDU. If the PHY header is receivable, but the parity check of the PHY header is not valid, a PHY- RXSTART.indication primitive shall not be issued. The PHY shall indicate the error condition using a PHY- RXEND.indication(FormatViolation) primitive. Any data received after the indicated data length are considered pad bits (to fill out an OFDM symbol) and should be discarded. A typical state machine implementation of the receive PHY is given in Figure 17-20. 17.4 OFDM PLME 17.4.1 PLME SAP sublayer management primitives Table 17-20 lists the MIB attributes that may be accessed by the PHY entities and the intralayer of higher level LMEs. These attributes are accessed via the PLME-GET, PLME-SET, PLME-RESET, and PLME- CHARACTERISTICS primitives defined in 6.5. 17.4.2 OFDM PHY MIB All OFDM PHY MIB attributes are defined in Annex C, with specific values defined in Table 17-20. The column titled â€œOperational semanticsâ€ in Table 17-20 contains two types: static and dynamic. Static MIB attributes are fixed and cannot be modified for a given PHY implementation. Dynamic MIB attributes can be modified by some management entity. 2317 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications RX IDLE state CS/CCA PHY-CCA.indication(BUSY) Detect PHY Preamble RX SYMBOL SIGNAL invalid Receive the SIGNAL or PHY-CCA symbol .indication (IDLE) SIGNAL Valid PHY-CCA.indication PHY-CCA.indication RX SIGNAL Parity (IDLE) (BUSY) Signal Not Valid Decode Symbol Parity Fail RX and test parity PHY-RXEND Descramble and Parity Correct .indication decode symbol (Carrier Lost) RX PHY fields Change demodulation type and decoding rate PHY-CCA according to SIGNAL data Decrement Time Decrement Length .indication (IDLE) RX 12 bits LENGTH PHY-DATA.indication RX 4 bits RATE Wait for intended (DATA) end of PSDU (bit removing if needed) length â‰ 0 Decrement length count Predicted duration expires and PHY-CCA.indication(IDLE) Time=0 length = 0 Wait until end of PHY field VALIDATE PPDU PPDU Out of Spec. End of Wait End of PSDU RX If unsupported RATE, Check PPDU predict duration Unsupported RATE PHY-RXEND PPDU Correct PHY-CCA.indication .indication (No Error) (IDLE) PHY-CCA.indication(IDLE) SETUP PSDU RX Set length count PHY-RXSTART .indication (RXVECTOR) Figure 17-20â€”PHY receive state machine Table 17-20â€”MIB attribute default values/ranges Managed object Default value/range Operational semantics dot11 PHY Operation Table dot11PHYtype OFDM-5. (04) Static dot11CurrentRegDomain Implementation dependent Dynamic dot11 PHY Antenna Table dot11CurrentTxAntenna Implementation dependent Dynamic dot11DiversitySupportImplemented Implementation dependent Static dot11CurrentRxAntenna Implementation dependent Dynamic 2318 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 17-20â€”MIB attribute default values/ranges (continued) Managed object Default value/range Operational semantics dot11 PHY Tx Power Table dot11NumberSupportedPowerLevelsI Implementation dependent Static mplemented dot11TxPowerLevel1 Implementation dependent Static dot11TxPowerLevel2 Implementation dependent Static dot11TxPowerLevel3 Implementation dependent Static dot11TxPowerLevel4 Implementation dependent Static dot11TxPowerLevel5 Implementation dependent Static dot11TxPowerLevel6 Implementation dependent Static dot11TxPowerLevel7 Implementation dependent Static dot11TxPowerLevel8 Implementation dependent Static dot11CurrentTxPowerLevel Implementation dependent Dynamic dot11 Reg Domains Supported Table dot11RegDomainsImplementedValue Implementation dependent Static dot11FrequencyBandsSupported Implementation dependent Static dot11 PHY Antennas List Table dot11SupportedTxAntenna Implementation dependent Static dot11SupportedRxAntenna Implementation dependent Static dot11DiversitySelectionRx Implementation dependent Dynamic dot11 Supported Data Rates Tx Table dot11ImplementedDataRatesTxValue 6, 9, 12, 18, 24, 36, 48, and Static 54 Mb/s for 20 MHz channel spacing (Mandatory rates: 6, 12, and 24) 3, 4.5, 6, 9, 12, 18, 24, and 27 Mb/s for 10 MHz channel spacing (Mandatory rates: 3, 6, and 12) 1.5, 2.25, 3, 4.5, 6, 9, 12, and 13.5 Mb/s for 5 MHz channel spacing (Mandatory rates: 1.5, 3, and 6) 2319 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 17-20â€”MIB attribute default values/ranges (continued) Managed object Default value/range Operational semantics dot11 Supported Data Rates Rx Table dot11ImplementedDataRatesRxValue 6, 9, 12, 18, 24, 36, 48, and Static 54 Mb/s for 20 MHz channel spacing (Mandatory rates: 6, 12, and 24) 3, 4.5, 6, 9, 12, 18, 24, and 27 Mb/s for 10 MHz channel spacing (Mandatory rates: 3, 6, and 12) 1.5, 2.25, 3, 4.5, 6, 9, 12, and 13.5 Mb/s for 5 MHz channel spacing (Mandatory rates: 1.5, 3, and 6) dot11 PHY OFDM Table dot11CurrentFrequency Implementation dependent Dynamic dot11TIThreshold Implementation dependent Dynamic dot11ChannelStartingFactor Implementation dependent Dynamic dot11OFDMEDThreshold Implementation dependent Dynamic dot11ACRType Implementation dependent Dynamic 17.4.3 OFDM TXTIME calculation The value of the TXTIME parameter returned by the PLME-TXTIME.confirm primitive shall be calculated according to the following equation: TXTIME = TPREAMBLE + TSIGNAL + TSYM NSYM (17-29) where TPREAMBLE is defined in Table 17-5 TSIGNAL is defined in Table 17-5 TSYM is defined in Table 17-5 NSYM is given by Equation (17-11). 17.4.4 OFDM PHY characteristics The static OFDM PHY characteristics, provided through the PLME-CHARACTERISTICS service primitive, are shown in Table 17-21. The definitions for these characteristics are given in 6.5. 2320 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 17-21â€”OFDM PHY characteristics Value Value Value Characteristics (20 MHz channel (10 MHz channel (5 MHz channel spacing) spacing) spacing) aSlotTime If If If dot11OperatingClassesReq dot11OperatingClassesReq dot11OperatingClassesReq uired is false, 9 Âµs uired is false, 13 Âµs uired is false, 21 Âµs If If If dot11OperatingClassesReq dot11OperatingClassesReq dot11OperatingClassesReq uired is true, 9 Âµs plus any uired is true, 13 Âµs plus any uired is true, 21 Âµs plus any coverage-class-dependent coverage-class-dependent coverage-class-dependent aAirPropagationTime (see aAirPropagationTime (see aAirPropagationTime (see Table 9-79) Table 9-79) Table 9-79) aSIFSTime 16 Âµs 32 Âµs 64 Âµs aCCATime Implementation dependent, see 10.3.7. aRxPHYStartDelay 20 Âµs 40 Âµs 80 Âµs aRxTxTurnaroundTime Implementation dependent, see 10.3.7. aTxPHYDelay Implementation dependent, see 10.3.7. aRxPHYDelay Implementation dependent, see 10.3.7. aRxTxSwitchTime Implementation dependent, see 10.3.7. aTxRampOnTime Implementation dependent, see 10.3.7. aAirPropagationTime As indicated by the coverage class (see 10.21.5). aMACProcessingDelay Implementation dependent, see 10.3.7. aPreambleLength 16 Âµs 32 Âµs 64 Âµs aPHYHeaderLength 4 Âµs 8 Âµs 16 Âµs aPSDUMaxLength 4095 octets 4095 octets 4095 octets aCWmin 15 15 15 aCWmax 1023 1023 1023 2321 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 18. Extended Rate PHY (ERP) specification 18.1 Overview 18.1.1 General This clause specifies further rate extension of the PHY for the DSSS system of Clause 15 and the extensions of Clause 16. Hereinafter the PHY defined in this clause is known as the ERP. This PHY operates in the 2.4 GHz ISM band. 18.1.2 Introduction The ERP builds on the payload data rates of 1 and 2 Mb/s, as described in Clause 15, that use DSSS modulation and builds on the payload data rates of 1, 2, 5.5, and 11 Mb/s, as described in Clause 16, that use DSSS and CCK. The ERP draws from Clause 17 to provide additional payload data rates of 6, 9, 12, 18, 24, 36, 48, and 54 Mb/s. Of these rates, transmission and reception capability for 1, 2, 5.5, 6, 11, 12, and 24 Mb/ s data rates is mandatory. 18.1.3 Operational modes The radio portion of all Clause 18 systems implements all mandatory modes of Clause 17 and Clause 16, except it uses the 2.4 GHz frequency band and channelization plan specified in 16.3.6. The ERP has the capability to decode Clause 15, Clause 16 and ERP PPDUs. An ERP shall be capable of sending and receiving the short preamble that is (and remains) optional for Clause 16 PHYs. The ERP has the capability to detect ERP and Clause 16 preambles whenever a CCA is requested. Because protection mechanisms are not required in all cases, the ERP CCA mechanisms for all preamble types shall be active at all times. An ERP BSS is capable of operating in any combination of available ERP modes (Clause 18 PHYs) and NonERP modes (Clause 15 or Clause 16 PHYs). For example, a BSS could operate in an ERP-OFDM-only mode, a mixed mode of ERP-OFDM and ERP-DSSS/CCK, or a mixed mode of ERP-DSSS/CCK and NonERP. When options are enabled, combinations are also allowed. The changes to other parts of this standard required to implement the ERP are summarized as follows: a) ERP-DSSS/CCK 1) The PHY uses the capabilities of Clause 16 with the following exceptions: i) Support of the short PPDU header format capability of 16.2.2.3 is mandatory. ii) CCA (see 16.3.8.5) has a mechanism that detects all mandatory Clause 18 sync symbols. iii) The maximum input signal level (see 16.3.8.3) is â€“20 dBm. iv) Locking the transmit center frequency and the symbol clock frequency to the same reference oscillator is mandatory. b) ERP-OFDM 1) The PHY uses the capabilities of Clause 17 with the following exceptions: i) The frequency plan is in accordance with 16.3.6.2 and 16.3.6.3 instead of 17.3.8.4. ii) CCA has a mechanism that detects all mandatory Clause 18 sync symbols. iii) The frequency accuracy (see 17.3.9.5 and 17.3.9.6) is Â±25 ppm. iv) The maximum input signal level (see 17.3.10.5) is â€“20 dBm. 2322 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications v) The value of the slot time is found in Table 18-5. vi) SIFS is 10 Âµs in accordance with 16.3.3. See 18.3.2.4 for more detail. The 2.4 GHz ISM band is a shared medium, and coexistence with other devices such as Clause 15 and Clause 16 STAs is an important issue for maintaining high performance in Clause 18 (ERP) STAs. The ERP modulation (ERP-OFDM) has been designed to coexist with existing Clause 15 and Clause 16 STAs. This coexistence is achieved by several means, including virtual CS (RTS/CTS or CTS-to-self), CSMA/CA protocols, and MSDU fragmentation. 18.1.4 Scope This clause specifies the ERP entity and the deviations from earlier clauses to accommodate it. It is organized by reference to the relevant earlier clauses to avoid excessive duplication. The ERP consists of the following protocol functions: a) A function that defines a method for mapping the MPDUs into a framing format suitable for sending and receiving user data and management information between two or more STAs using the associated PHY system. The PHY exchanges PPDUs that contain PSDUs. The MAC uses the PHY service, so each MPDU corresponds to a PSDU that is carried in a PPDU. b) A function that defines the characteristics and method of transmitting and receiving data through a WM between two or more STAs; each using the ERP. 18.1.5 ERP functions The ERP contains two functional entities: the PHY function and the layer management function. The ERP service is provided to the MAC through the PHY service primitives described in Clause 8. Interoperability is addressed by use of the CS mechanism specified in 10.3.2.1 and the protection mechanism in 10.26. This mechanism allows NonERP STAs to know of ERP traffic that they cannot demodulate so that they may defer the medium to that traffic. 18.2 PHY-specific service parameter list The architecture of the IEEE 802.11 MAC is intended to be PHY independent. Some PHY implementations require PHY-dependent MAC state machines running in the MAC sublayer in order to meet certain PHY requirements. The PHY-dependent MAC state machine resides in a sublayer defined as the MLME. In certain PHY implementations, the MLME may need to interact with the PLME as part of the normal PHY SAP primitives. These interactions are defined by the PLME parameter list currently defined in the PHY service primitives as TXVECTOR, TXSTATUS, and RXVECTOR. The list of these parameters and the values they may represent are defined in the specific PHY specifications for each PHY. This subclause addresses the TXVECTOR, TXSTATUS, and RXVECTOR for the ERP. The service parameters for TXVECTOR, TXSTATUS, and RXVECTOR shall follow 17.2.2, 17.2.4, and 17.2.3, respectively. Several service primitives include a parameter vector. DATARATE and LENGTH are described in 8.3.4.4. The remaining parameters are considered to be management parameters and are specific to this PHY. The parameters in Table 18-1 are defined as part of the TXVECTOR parameter list in the PHY- TXSTART.request and PLME-TXTIME.request primitives. 2323 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 18-1â€”TXVECTOR parameters Parameter Value DATARATE The rate used to transmit the PSDU in Mb/s. Allowed value depends on value of MODULATION parameter: ERP-DSSS: 1 and 2 ERP-CCK: 5.5 and 11 ERP-OFDM: 6, 9, 12, 18, 24, 36, 48, and 54 LENGTH The length of the PSDU in octets. Range: 1â€“4095 PREAMBLE_TYPE The preamble used for the transmission of the PPDU. Enumerated type for which the allowed value depends on value of MODULATION parameter: ERP-OFDM: null ERP-DSSS, ERP-CCK: SHORTPREAMBLE, LONGPREAMBLE MODULATION The modulation used for the transmission of this PSDU. Enumerated type: ERP-DSSS, ERP-CCK, ERP-OFDM SERVICE The scrambler initialization vector. Null. TXPWR_LEVEL_INDE The transmit power level index. The definition of these levels is up to the X implementer. 1â€“8 TIME_OF_DEPARTURE false, true. When true, the MAC entity requests that the PHY entity measures and _REQUESTED reports time of departure parameters corresponding to the time when the first frame energy is sent by the transmitting port; when false, the MAC entity requests that the PHY entity neither measures nor reports time of departure parameters. The parameters in Table 18-2 are defined as part of the TXSTATUS parameter list in the PHY-TXSTART. confirm service primitive. Table 18-2â€”TXSTATUS parameters Parameter Value TIME_OF_DEPARTURE 0 to 232â€“ 1. The locally measured time when the first frame energy is sent by the transmitting port, in units equal to 1/ TIME_OF_DEPARTURE_ClockRate. This parameter is present only if TIME_OF_DEPARTURE_REQUESTED is true in the corresponding request. TIME_OF_DEPARTURE_ClockRate 0 to 216â€“ 1. The clock rate, in units of MHz, is used to generate the TIME_OF_DEPARTURE value. This parameter is present only if TIME_OF_DEPARTURE_REQUESTED is true in the corresponding request. TX_START_OF_FRAME_OFFSET 0 to 232â€“ 1. An estimate of the offset (in 10 ns units) from the point in time at which the start of the preamble corresponding to the frame was transmitted at the transmit antenna connector to the point in time at which this primitive is issued to the MAC. 2324 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The parameters in Table 18-3 are defined as part of the RXVECTOR parameter list in the PHY- RXSTART.indication primitive. When implementations require the use of these vectors, some or all of these parameters may be used in the vectors. Table 18-3â€”RXVECTOR parameters Parameter Value DATARATE The rate at which the PSDU was received in Mb/s. Allowed value depends on value of MODULATION parameter: ERP-DSSS: 1 and 2 ERP-CCK: 5.5 and 11 ERP-OFDM: 6, 9, 12, 18, 24, 36, 48, and 54 LENGTH The length of the PSDU in octets. Range: 1â€“4095 PREAMBLE_TYPE The preamble type detected during reception of the PPDU. Enumerated type for which the allowed value depends on value of MODULATION parameter: ERP-OFDM: null ERP-DSSS, ERP-CCK: SHORTPREAMBLE, LONGPREAMBLE. MODULATION The modulation used for the reception of this PSDU. Enumerated types: ERP-DSSS, ERP-CCK, ERP-OFDM SERVICE Null. RSSI The RSSI is a measure of the RF energy received by the ERP. The 8-bit value is in the range 0 to RSSI maximum as described in 17.2.3.3. RCPI The RCPI is a measure of the received channel power and is included when dot11RadioMeasurementActivated is true. The 8-bit RCPI value is described in 17.2.3.6 and 16.3.8.6. RX_START_OF_FRAME 0 to 232â€“ 1. An estimate of the offset (in 10 ns units) from the point in time at which _OFFSET the start of the preamble corresponding to the incoming frame arrived at the receive antenna connector to the point in time at which this primitive is issued to the MAC. 18.3 Extended Rate PHY sublayer 18.3.1 Introduction Subclause 18.3 provides a PHY for the ERP. The convergence procedure specifies how PSDUs are converted to and from PPDUs at the transmitter and receiver. The PPDU is formed during data transmission by appending the PSDU to the Extended Rate PHY preamble and header. At the receiver, the PHY preamble and header are processed to aid in the demodulation and delivery of the PSDU. 18.3.2 PPDU format 18.3.2.1 General An ERP STA shall support three different preamble and header formats. The first is the long preamble and header described in 18.3.2.2 (and based on 16.2.2.2 with redefinition of reserved bits defined therein). This PPDU provides interoperability with Clause 16 STAs when using the 1, 2, 5.5, and 11 Mb/s data rates. The second is the short preamble and header described in 18.3.2.3 (and based on 16.2.2.3 where it is optional). 2325 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The short preamble supports the rates 2, 5.5, and 11 Mb/s. The third is the ERP-OFDM preamble and header specified in 18.3.2.4 (and based on 17.3.2). 18.3.2.2 Long preamble PPDU format Figure 16-1 of 16.2.2.2 shows the basic format for the long preamble PPDU. This preamble is appropriate for use with the 1, 2, 5.5, and 11 Mb/s (Clause 16) modes and is compatible with BSSs using these modes. The SERVICE field is defined in 16.2.3.5. An ERP STA shall set the Locked clocks bit to 1, when transmitting at a data rate described in Clause 16. 18.3.2.3 Short preamble PPDU format Figure 16-2 of 16.2.2.3 shows the basic format for the short preamble PPDU. For the ERP, support for this preamble is mandatory. The short preamble is appropriate for use with 2, 5.5, and 11 Mb/s modes. The bits of the Short PHY SERVICE field and RATE field are the same as for the Long PHY SERVICE field and RATE field and are defined in 18.3.2.2. 18.3.2.4 ERP-OFDM PPDU format The format, preamble, and headers for the ERP-OFDM PPDU are described in 17.3.2 to 17.3.5. For the ERP-OFDM modes, the DATA field that contains the SERVICE field, the PSDU, the TAIL bits, and the PAD bits shall follow 17.3.5. For ERP-OFDM modes, an ERP packet is followed by a period of no transmission with a duration of aSignalExtension called the signal extension. The purpose of this extension is to make the TXTIME calculation in 18.5.3 result in a transmission duration interval that includes an additional duration of aSignalExtension. The SIFS for Clause 17 packets is 16 Âµs, and the SIFS for Clause 16 packets is 10 Âµs. The longer SIFS in Clause 17 is to allow extra time for the convolutional decode process to finish. As Clause 18 packets use a SIFS of 10 Âµs, this extra aSignalExtension length extension causes the transmitter to compute the Duration field in the MAC header incorporating the aSignalDuration of â€œidle timeâ€ following each ERP- OFDM transmission, which causes the NAV value of Clause 16 STAs to be set correctly. The â€œCS mechanismâ€ described in 10.3.2.1 combines the NAV state and the STAâ€™s transmitter status with physical CS to determine the busy/idle state of the medium. The time interval between frames is called the IFS. A STA shall determine that the medium is idle through the use of the CCA mechanism for the interval specified. The starting reference of slot boundaries is the end of the last symbol of the previous frame on the medium. For ERP-OFDM frames, this includes the length extension. For ERP-OFDM frames, a STA shall generate the PHY-RXEND.indication aSignalDuration after the end of the last symbol of the previous frame on the medium. This adjustment shall be performed by the STA based on local configuration information set using the PLME SAP. 18.3.3 PHY data modulation and rate change 18.3.3.1 Long and short preamble formats The long and short PHY preamble and the long PHY header shall be transmitted using the 1 Mb/s DBPSK modulation. The short PHY header shall be transmitted using the 2 Mb/s modulation. The SIGNAL and SERVICE fields combined shall indicate the modulation and rate that shall be used to transmit the PSDU. The transmitter and receiver shall initiate the modulation and rate indicated by the SIGNAL and SERVICE fields, starting with the first octet of the PSDU. The PSDU transmission rate shall be set by the DATARATE parameter in the TXVECTOR, issued with the PHY-TXSTART.request primitive described in 16.3.5. 2326 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Four modulation formats are mandatory, 1 Mb/s and 2 Mb/s ERP-DSSS and 5.5 Mb/s and 11 Mb/s ERP-CCK, and they are specified in 16.3.6.4. 18.3.3.2 ERP-OFDM format PHY modulation and rate change for the ERP-OFDM frame format follows 17.3.7. 18.3.4 CCA The PHY shall provide the capability to perform a CCA and report the results of the assessment to the MAC. The CCA mechanism shall detect a â€œmedium busyâ€ condition for all supported preamble and header types. That is, the CCA mechanism shall detect that the medium is busy for the PPDUs specified in 17.3.2 and 16.2.2. The CCA mechanism performance requirements are given in 18.4.6. The ERP shall provide the capability to perform CCA according to the following method: CCA Mode (ED and CS): A combination of CS and energy above threshold. CCA shall have a mechanism for CS that detects all mandatory Clause 18 sync symbols. This CCAâ€™s modeâ€™s CS shall include both Barker code sync detection and OFDM sync symbol detection. CCA shall report busy at least while a PPDU is being received with energy above the ED threshold at the antenna. The PHY shall indicate a busy channel by issuing a PHY-CCA.indication(BUSY) primitive and shall indicate a clear channel by issuing a PHY-CCA.indication(IDLE) primitive. 18.3.5 PHY receive procedure This subclause describes the procedure used by receivers of the ERP. An ERP receiver shall be capable of receiving 1, 2, 5.5, and 11 Mb/s PPDUs using either the long or short preamble formats described in Clause 16 and shall be capable of receiving 6, 12, and 24 Mb/s using the modulation and preamble described in Clause 17. The PHY may also implement the ERP-OFDM modulations at rates of 9, 18, 36, 48, and 54 Mb/s. The receiver shall be capable of detecting the preamble type (ERP-OFDM, short preamble, or long preamble) and the modulation type. These values shall be reported in the RXVECTOR (see 18.2). Upon the receipt of a PPDU, the receiver shall first distinguish between the ERP-OFDM preamble and the single carrier modulations (long or short preamble). In the case where the preamble is an ERP-OFDM preamble, the PHY receive procedure shall follow the procedure described in 17.3.12. Otherwise, the receiver shall then distinguish between the long preamble and short preamble as specified in 16.2.2. The receiver shall then demodulate the SERVICE field to determine the modulation type as specified in 18.3.2.2 or 18.3.2.3. For short preamble and long preamble using ERP-DSSS or ERP-CCK, the receiver shall then follow the receive procedure described in 16.2.6. 18.4 ERP operating specifications (general) 18.4.1 Introduction Subclauses 18.4.2 to 18.4.7 provide general specifications for the ERP sublayers. These specifications are based on 17.3.8 except where noted. 18.4.2 Regulatory requirements All systems shall comply with the appropriate regulatory requirements for operation in the 2.4 GHz band. 2327 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 18.4.3 Operating channel frequencies The ERP shall operate in the frequency ranges specified in 16.3.6.3, as allocated by regulatory bodies in the United States, Europe, and Japan. The channel numbering and the number of operating channels shall follow Table 16-6 of 16.3.6.3. 18.4.4 Transmit and receive in-band and out-of-band spurious emissions The ERP shall comply with in-band and out-of-band spurious emissions as set by the appropriate regulatory bodies for the 2.4 GHz band. 18.4.5 SIFS The ERP shall use a SIFS of 10 Âµs. 18.4.6 CCA performance The CCA shall indicate true if there is no CCA â€œmedium busyâ€ indication. The CCA parameters are subject to the following criteria: a) When the start of a valid ERP-OFDM signal or valid ERP-DSSS/CCK sync symbols at a receive level greater than or equal to â€“82 dBm at the receiver antenna connector are present at the start of the PHY slot, the receiverâ€™s CCA indicator shall report the channel busy with probability CCA_Detect_Probability within a aCCATime. CCA_Detect_Probabilty is the probability that the CCA does respond correctly to a valid signal and shall be at least 99% for the long slot time and at least 90% for the short slot time. The values for the other parameters are found in Table 18-5. Note that the CCA Detect Probability and the power level are performance requirements. b) In the event that a correct PHY header is received, the ERP shall hold the CCA signal inactive (channel busy) for the full duration, as indicated by the PHY LENGTH field. Should a loss of CS occur in the middle of reception, the CCA shall indicate a busy medium for the intended duration of the transmitted PPDU. c) CCA shall report a busy medium upon detection of any energy above â€“62 dBm. 18.4.7 PHY transmit specifications 18.4.7.1 General The PHY transmit specifications shall follow 17.3.9 with the exception of the transmit power level (17.3.9.2), the transmit center frequency tolerance (17.3.9.5), the symbol clock frequency tolerance (17.3.9.6), and the time of departure accuracy (17.3.9.9). Regulatory requirements may have an effect on the combination of maximum transmit power and spectral mask if the resulting signals violate restricted band emission limits. 18.4.7.2 Transmit power levels The maximum transmit power level shall meet the requirements of the local regulatory body. 18.4.7.3 Transmit spectral mask The transmit spectral mask for the ERP-OFDM modes shall follow 17.3.9.3 and is shown in Figure 17-13 therein. The transmit spectral mask for the ERP-DSSS modes shall follow 16.3.7.4 and is shown in Figure 16-10 therein. 2328 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 18.4.7.4 Transmit center frequency tolerance The transmit center frequency tolerance shall be Â± 25 ppm maximum. The transmit center frequency and symbol clock frequency shall be derived from the same reference oscillator (locked). 18.4.7.5 Symbol clock frequency tolerance The symbol clock frequency tolerance shall be Â± 25 ppm maximum. The transmit center frequency and symbol clock frequency shall be derived from the same reference oscillator (locked oscillators). This means that the error in ppm for the carrier and the symbol timing shall be the same. 18.4.7.6 Time of Departure accuracy The time of departure specifications shall follow 17.3.9.9 for PPDUs transmitted using ERP-OFDM format and 16.3.7.10 for PPDUs transmitted using ERP-DSSS/CCK. 18.4.8 PHY receive specifications 18.4.8.1 General Subclause 18.4.8 describes the receive specifications for the PHY sublayer. The receive specification for the ERP-OFDM modes shall follow 17.3.10 with the exception of the receiver maximum input level (17.3.10.5) and the adjacent channel rejection (17.3.10.3). The receive specifications for the ERP-DSSS modes shall follow 16.3.8 with the exception of the receiver maximum input level (16.3.8.3). 18.4.8.2 Receiver minimum input level sensitivity The PER of the ERP-OFDM modes shall be less than 10% at a PSDU length of 1000 octets for the input levels of Table 17-18 of 17.3.10. Input levels are specific for each data rate and are measured at the antenna connector. A noise figure of 10 dB and an implementation loss of 5 dB are assumed. The PER of the ERP- DSSS modes shall be as specified in 16.3.8.2. 18.4.8.3 Adjacent channel rejection Adjacent channels at 2.4 GHz are defined to be at Â± 25 MHz spacing. The adjacent channel rejection shall be measured by setting the desired signalâ€™s strength 3 dB above the rate-dependent sensitivity specified in Table 17-18 of 17.3.10 and raising the power of the interfering signal until 10% PER is caused for a PSDU length of 1000 octets. The difference in power between the signals in the interfering channel and the desired channel is the corresponding adjacent channel rejection. The interfering signal in the adjacent channel shall be a signal compliant with the ERP, unsynchronized with the signal in the channel under test. In an ERP the corresponding rejection shall be no less than specified in Table 17-18 of 17.3.10. The alternative adjacent channel rejection of Table 17-18 shall not be required for the ERP. The adjacent channel rejection of the ERP-DSSS modes shall follow 16.3.8.4. 18.4.8.4 Receive maximum input level capability The PER shall be less than 10% at a PSDU length of 1000 octets for an input level of â€“20 dBm measured at the antenna connector for any supported modulation signal or data rate (i.e., 1, 2, 5.5, 6, 9, 11, 12, 18, 22, 24, 33, 36, 48, 54 Mb/s). 2329 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 18.5 ERP PLME 18.5.1 PLME SAP Table 18-4 lists the additional MIB attributes that may be accessed by the PHY entities and the intralayer of higher LMEs. These attributes are accessed via the PLME-GET, PLME-SET, PLME-RESET, and PLME- CHARACTERISTICS primitives defined in 6.5. 18.5.2 MIB HR/DSSS PHY MIB attributes are defined in Annex C with additions from this supplement and with specific values defined in Table 18-4. Table 18-4â€”MIB attribute default values/ranges Managed object Default value/range Operational semantics dot11 PHY Operation Table dot11PHYtype ERP (X'06') Static dot11CurrentRegDomain Implementation dependent Static dot11 PHY Antenna Table dot11CurrentTxAntenna Implementation dependent Dynamic dot11DiversitySupportImplemented Implementation dependent Static dot11CurrentRxAntenna Implementation dependent Dynamic dot11 PHY Tx Power Table dot11NumberSupportedPowerLevelsImpleme Implementation dependent Static nted dot11TxPowerLevel1 Implementation dependent Static dot11TxPowerLevel2 Implementation dependent Static dot11TxPowerLevel3 Implementation dependent Static dot11TxPowerLevel4 Implementation dependent Static dot11TxPowerLevel5 Implementation dependent Static dot11TxPowerLevel6 Implementation dependent Static dot11TxPowerLevel7 Implementation dependent Static dot11TxPowerLevel8 Implementation dependent Static dot11CurrentTxPowerLevel Implementation dependent Dynamic dot11 Phy DSSS Table dot11CurrentChannel Implementation dependent Dynamic dot11 Reg Domains Supported Table dot11RegDomainsImplementedValue(s) Implementation dependent Static dot11 PHY Antennas List Table dot11TxAntennaImplemented Implementation dependent Static dot11RxAntennaImplemented Implementation dependent Static dot11DiversitySelectionRxImplemented Implementation dependent Dynamic 2330 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 18-4â€”MIB attribute default values/ranges (continued) Managed object Default value/range Operational semantics dot11 Supported Data Rates Tx Table dot11SupportedDataratesTxValue X'02' = 1 Mb/s Static X'04' = 2 Mb/s X'0B' = 5.5 Mb/s X'16' = 11 Mb/s X'0C' = 6 Mb/s X'12' = 9 Mb/s X'18' = 12 Mb/s X'24' = 18 Mb/s X'30' = 24 Mb/s X'48' = 36 Mb/s X'60' = 48 Mb/s X'6C' = 54 Mb/s dot11 Supported Data Rates Rx Table dot11ImplementedDataRatesRxValue X'02' = 1 Mb/s Static X'04' = 2 Mb/s X'0B' = 5.5 Mb/s X'16' = 11 Mb/s X'0C' = 6 Mb/s X'12' = 9 Mb/s X'18' = 12 Mb/s X'24' = 18 Mb/s X'30' = 24 Mb/s X'48' = 36 Mb/s X'60' = 48 Mb/s X'6C' = 54 Mb/s dot11 HRDSSS PHY Table dot11ShortPreambleOptionImplemented true/Boolean Static dot11 PHY ERP Table dot11ShortSlotTimeOptionImplemented false/Boolean Static dot11ShortSlotTimeOptionActivated false/Boolean Dynamic 18.5.3 TXTIME 18.5.3.1 General The value of TXTIME is calculated for each modulation type based on parameters in the TXVECTOR. For the 1, 2, 5.5, and 11 Mb/s modes with DSSS and CCK modulation formats, the value shall be calculated as described in 16.3.4. 18.5.3.2 ERP-OFDM TXTIME calculations The value of the TXTIME parameter returned by the PLME-TXTIME.confirm primitive shall be calculated using the ERP-OFDM TXTIME calculation as shown in Equation (18-1). TXTIME = T PREAMBLE + T SIGNAL + T SYM 16 + 8 LENGTH + 6 + T (18-1) ------------------------------------------------------- SE N DBPS 2331 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications where TPREAMBLE, TSIGNAL, and TSYM are defined in Table 17-5 in 17.3.2.4 NDBPS is the number of data bits per symbol and is derived from the DATARATE parameter in Table 17-4 in 17.3.2.3 TSE is aSignalExtension 18.5.4 ERP characteristics The ERP characteristics in Table 18-5 shall be used for the ERP for the purposes of MAC timing calculations. Table 18-5â€”ERP characteristics Characteristic Value aSlotTime If dot11OperatingClassesRequired is false: Long = 20 Âµs Short = 9 Âµs If dot11OperatingClassesRequired is true: Long = 20 Âµs plus any coverage-class-dependent aAirPropagationTime (see Table 9-79) Short = 9 Âµs plus any coverage-class-dependent aAirPropagationTime (see Table 9-79) aSIFSTime 10 Âµs aSignalExtension 6 Âµs aCCATime Implementation dependent, see 10.3.7. aRxPHYStartDelay 20 Âµs for ERP-OFDM, 192 Âµs for ERP-DSSS/CCK with long preamble, and 96 Âµs for ERP-DSSS/CCK with short preamble aRxTxTurnaroundTime Implementation dependent, see 10.3.7. aTxPHYDelay Implementation dependent, see 10.3.7. aRxPHYDelay Implementation dependent, see 10.3.7. aRxTxSwitchTime Implementation dependent, see 10.3.7. aTxRampOnTime Implementation dependent, see 10.3.7. aAirPropagationTime As indicated by the coverage class (see 10.21.5). aMACProcessingDelay Implementation dependent, see 10.3.7. aPreambleLength 16 Âµs for ERP-OFDM, 144 Âµs for ERP-DSSS/CCK with long preamble, 72 Âµs for ERP-DSSS/CCK with short preamble aPHYHeaderLength 4 Âµs for ERP-OFDM, 48 Âµs for ERP-DSSS/CCK with long preamble, 24 Âµs for ERP-DSSS/CCK with short preamble aPSDUMaxLength 4095 octets aCWmin(0) 31 aCWmin(1) 15 ACWmin The set aCWmin() aCWmax 1023 2332 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The long slot time indicated in Table 18-5 shall be used unless the BSS consists only of ERP STAs that support the Short Slot Time option. STAs indicate support for a short slot time by setting the Short Slot Time subfield to 1 when transmitting Association Request and Reassociation Request frames. If the BSS consists of only ERP STAs that support the Short Slot Time option, an optional short slot time may be used. APs indicate usage of the short slot time indicated in Table 18-5 by setting the Short Slot Time subfield to 1 in all Beacon, Probe Response, Association Response, and Reassociation Response frame transmissions as described in 9.4.1.4. A STA shall use short slot if the BSS indicates short slot. 2333 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 19. High-throughput (HT) PHY specification 19.1 Introduction 19.1.1 Introduction to the HT PHY Clause 19 specifies the PHY entity for a high-throughput (HT) orthogonal frequency division multiplexing (OFDM) system. In addition to the requirements found in Clause 19, an HT STA shall be capable of transmitting and receiving frames that are compliant with the mandatory PHY specifications defined as follows: â€” In Clause 17 when the HT STA is operating in a 20 MHz channel width in the 5 GHz band â€” In Clause 16 and Clause 18 when the HT STA is operating in a 20 MHz channel width in the 2.4 GHz band The HT PHY is based on the OFDM PHY defined in Clause 17, with extensibility up to four spatial streams, operating in 20 MHz bandwidth. Additionally, transmission using one to four spatial streams is defined for operation in 40 MHz bandwidth. These features are capable of supporting data rates up to 600 Mb/s (four spatial streams, 40 MHz bandwidth). The HT PHY data subcarriers are modulated using binary phase shift keying (BPSK), quadrature phase shift keying (QPSK), 16-quadrature amplitude modulation (16-QAM), or 64-QAM. Forward error correction (FEC) coding (convolutional coding) is used with a coding rate of 1/2, 2/3, 3/4, or 5/6. LDPC codes are added as an optional feature. Other optional features at both transmit and receive sides are 400 ns (short) guard interval (GI), transmit beamforming, HT-greenfield format, and STBC. The maximum HT PSDU length is 65 535 octets. 19.1.2 Scope The services provided to the MAC by the HT PHY consist of the following protocol functions: a) A function that defines a method of mapping the PSDUs into a framing format (PPDU) suitable for sending and receiving PSDUs between two or more STAs. b) A function that defines the characteristics and method of transmitting and receiving data through a wireless medium between two or more STAs. Depending on the PPDU format, these STAs support a mixture of HT PHY and Clause 15, Clause 17, Clause 16, or Clause 18 PHYs. 19.1.3 HT PHY functions 19.1.3.1 General The HT PHY contains two functional entities: the PHY and the layer management function (i.e., the PLME). Both of these functions are described in detail in 19.3 and 19.4. The HT PHY service is provided to the MAC through the PHY service primitives defined in Clause 8. 19.1.3.2 PHY management entity (PLME) The PLME performs management of the local PHY functions in conjunction with the MLME. 2334 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 19.1.3.3 Service specification method The models represented by figures and state diagrams are intended to be illustrations of the functions provided. It is important to distinguish between a model and a real implementation. The models are optimized for simplicity and clarity of presentation, but do not necessarily reflect any particular implementation. The service of a layer or sublayer is the set of capabilities that it offers to a user in the next higher layer (or sublayer). Abstract services are specified here by describing the service primitives and parameters that characterize each service. This definition is independent of any particular implementation. 19.1.4 PPDU formats The structure of the PPDU transmitted by an HT STA is determined by the TXVECTOR FORMAT, CH_BANDWIDTH, CH_OFFSET, and MCS parameters as defined in Table 19-1. The effect of the CH_BANDWIDTH, CH_OFFSET, and MCS parameters on PPDU format is described in 19.2.4. The FORMAT parameter determines the overall structure of the PPDU as follows: â€” Non-HT format (NON_HT): Packets of this format are structured according to the Clause 17 (OFDM) or Clause 18 (ERP) specification. Support for non-HT format is mandatory. â€” HT-mixed format (HT_MF): Packets of this format contain a preamble compatible with Clause 17 and Clause 18 receivers. The non-HT-STF (L-STF), the non-HT-LTF (L-LTF), and the non-HT SIGNAL field (L-SIG) are defined so they can be decoded by non-HT Clause 17 and Clause 18 STAs. The rest of the packet cannot be decoded by Clause 17 or Clause 18 STAs. Support for HT- mixed format is mandatory. â€” HT-greenfield format (HT_GF): HT packets of this format do not contain a non-HT compatible part. Support for HT-greenfield format is optional. An HT STA that does not support the reception of an HT-greenfield format packet shall be able to detect that an HT-greenfield format packet is an HT transmission (as opposed to a non-HT transmission). In this case, the receiver shall decode the HT-SIG and determine whether the HT-SIG cyclic redundancy check (CRC) passes. 19.2 HT PHY service interface 19.2.1 Introduction The PHY interfaces to the MAC through the TXVECTOR, TXSTATUS, RXVECTOR, and PHYCONFIG_VECTOR. Using the TXVECTOR, the MAC supplies the PHY with per-PPDU transmit parameters. Status of the transmission is reported from PHY to MAC by parameters within TXSTATUS. Using the RXVECTOR, the PHY informs the MAC of the received packet parameters. Using the PHYCONFIG_VECTOR, the MAC configures the PHY for operation, independent of frame transmission or reception. This interface is an extension of the generic PHY service interface defined in 8.3.4. 19.2.2 TXVECTOR and RXVECTOR parameters The parameters in Table 19-1 are defined as part of the TXVECTOR parameter list in the PHY-TXSTART.request primitive and/or as part of the RXVECTOR parameter list in the PHY-RXSTART.indication primitive. 2335 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 19-1â€”TXVECTOR and RXVECTOR parameters RXVECTOR TXVECTOR Parameter Condition Value See NOTE 1 Determines the format of the PPDU. Y Y Enumerated type: NON_HT indicates Clause 15, Clause 17, Clause 16, or Clause 18 FORMAT PPDU formats or non-HT duplicate PPDU format. In this case, the modulation is determined by the NON_HT_MODULATION parameter. HT_MF indicates HT-mixed format. HT_GF indicates HT-greenfield format. FORMAT is Enumerated type: Y Y NON_HT_ MODULATION NON_HT ERP-DSSS ERP-CCK ERP-OFDM OFDM NON_HT_DUP_OFDM Otherwise Not present FORMAT is Indicates the length of the PSDU in octets in the range 1 to 4095. This Y Y NON_HT value is used by the PHY to determine the number of octet transfers that occur between the MAC and the PHY. L_LENGTH FORMAT is HT_MF Indicates the value in the Length field of the L-SIG in the range 1 to 4095. Y Y This use is defined in 10.26.4. This parameter may be used for the protection of more than one PPDU as described in 10.26.5. FORMAT is HT_GF Not present N N FORMAT is Indicates the rate used to transmit the PSDU in megabits per second. Y Y NON_HT Allowed values depend on the value of the NON_HT_MODULATION parameter as follows: ERP-DSSS: 1 and 2 L_DATARATE ERP-CCK: 5.5 and 11 ERP-OFDM, NON_HT_DUP_OFDM: 6, 9, 12, 18, 24, 36, 48, and 54 OFDM: 6, 9, 12, 18, 24, 36, 48, and 54 FORMAT is HT_MF Indicates the data rate value that is in the L-SIG. This use is defined in Y Y 10.26.4. FORMAT is HT_GF Not present N N FORMAT is HT_MF true if L-SIG Parity is valid N Y LSIGVALID false if L-SIG Parity is not valid Otherwise Not present N N 2336 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 19-1â€”TXVECTOR and RXVECTOR parameters (continued) RXVECTOR TXVECTOR Parameter Condition Value See NOTE 1 FORMAT is Scrambler initialization, null Y N NON_HT and NON_HT_MODUL ATION is one of SERVICE â€” ERP-OFDM â€” OFDM FORMAT is HT_MF Scrambler initialization, null Y N or HT_GF Otherwise Not present N N The allowed values for the TXPWR_LEVEL_INDEX parameter are in the Y N TXPWR_LEVEL_INDEX range 1 to 8. This parameter is used to indicate which of the available TxPowerLevel attributes defined in the MIB shall be used for the current transmission. The allowed values for the RSSI parameter are in the range 0 to RSSI N Y maximum. This parameter is a measure by the PHY of the power observed at the antennas used to receive the current PPDU. RSSI shall be measured RSSI during the reception of the PHY preamble. In HT-mixed format, the reported RSSI shall be measured during the reception of the HT-LTFs. RSSI is intended to be used in a relative manner, and it shall be a monotonically increasing function of the received power. FORMAT is Enumerated type: Y Y PREAMBLE_TYPE NON_HT and SHORTPREAMBLE NON_HT_MODUL LONGPREAMBLE ATION is one of â€” ERP-DSSS â€” ERP-CCK Otherwise Not present N N FORMAT is HT_MF Selects the modulation and coding scheme used in the transmission of the Y Y or HT_GF packet. The value used in each MCS is the index defined in 19.5. MCS Integer: range 0 to 76. Values of 77 to 127 are reserved. The interpretation of the MCS index is defined in 19.5. Otherwise Not present N N FORMAT is HT_MF Indicates the MCS that the STAâ€™s receiver recommends. N O REC_MCS or HT_GF Otherwise Not present N N 2337 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 19-1â€”TXVECTOR and RXVECTOR parameters (continued) RXVECTOR TXVECTOR Parameter Condition Value See NOTE 1 FORMAT is HT_MF Indicates whether the packet is transmitted using 40 MHz or 20 MHz Y Y CH_BANDWIDTH or HT_GF channel width. Enumerated type: HT_CBW20 for 20 MHz and 40 MHz upper and 40 MHz lower modes HT_CBW40 for 40 MHz FORMAT is Enumerated type: Y Y NON_HT NON_HT_CBW40 for non-HT duplicate format NON_HT_CBW20 for all other non-HT formats Indicates which portion of the channel is used for transmission. Refer to Y N Table 19-2 for valid combinations of CH_OFFSET and CH_BANDWIDTH. CH_OFFSET Enumerated type: CH_OFF_20 indicates the use of a 20 MHz channel (that is not part of a 40 MHz channel). CH_OFF_40 indicates the entire 40 MHz channel. CH_OFF_20U indicates the upper 20 MHz of the 40 MHz channel CH_OFF_20L indicates the lower 20 MHz of the 40 MHz channel. FORMAT is HT_MF Indicates the length of an HT PSDU in the range 0 to 65 535 octets. A Y Y LENGTH or HT_GF value of 0 indicates a NDP that contains no data symbols after the HT preamble (see 19.3.9). Otherwise Not present N N FORMAT is HT_MF Indicates whether frequency domain smoothing is recommended as part of Y Y or HT_GF channel estimation. (See NOTE 2.) SMOOTHING Enumerated type: SMOOTHING_REC indicates that smoothing is recommended. SMOOTHING_NOT_REC indicates that smoothing is not recommended. Otherwise Not present N N FORMAT is HT_MF Indicates whether this packet is a sounding packet. Y Y SOUNDING or HT_GF Enumerated type: SOUNDING indicates this is a sounding packet. NOT_SOUNDING indicates this is not a sounding packet. Otherwise Not present N N FORMAT is HT_MF Indicates whether the PSDU contains an A-MPDU. Y Y AGGREGATION or HT_GF Enumerated type: AGGREGATED indicates this PSDU has A-MPDU aggregation. NOT_AGGREGATED indicates this PSDU does not have A-MPDU aggregation. Otherwise Not present N N 2338 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 19-1â€”TXVECTOR and RXVECTOR parameters (continued) RXVECTOR TXVECTOR Parameter Condition Value See NOTE 1 FORMAT is HT_MF Indicates the difference between the number of space-time streams ( N STS ) Y Y or HT_GF and the number of spatial streams ( N SS ) indicated by the MCS as follows: 0 indicates no STBC ( N STS = N SS ). STBC 1 indicates N STS â€“ N SS = 1 . 2 indicates N STS â€“ N SS = 2 . Value of 3 is reserved. Otherwise Not present N N FORMAT is HT_MF Indicates which FEC encoding is used. Y Y FEC_CODING or HT_GF Enumerated type: BCC_CODING indicates binary convolutional code. LDPC_CODING indicates low-density parity check code. Otherwise Not present N N FORMAT is HT_MF Indicates whether a short guard interval is used in the transmission of the Y Y or HT_GF packet. GI_TYPE Enumerated type: LONG_GI indicates short GI is not used in the packet. SHORT_GI indicates short GI is used in the packet. Otherwise Not present N N FORMAT is HT_MF Indicates the number of extension spatial streams that are sounded during Y Y NUM_EXTEN_SS or HT_GF the extension part of the HT training in the range 0 to 3. Otherwise Not present N N FORMAT is HT_MF Indicates which antennas of the available antennas are used in the O N ANTENNA_SET or HT_GF transmission. The length of the field is 8 bits. A 1 in bit position n, relative to the LSB, indicates that antenna n is used. At most 4 bits out of 8 may be set to 1. This field is present only if ASEL is applied. Otherwise Not present N N FORMAT is HT_MF The N_TX parameter indicates the number of transmit chains. Y N N_TX or HT_GF Otherwise Not present N N 2339 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 19-1â€”TXVECTOR and RXVECTOR parameters (continued) RXVECTOR TXVECTOR Parameter Condition Value See NOTE 1 EXPANSION_MAT Contains a set of compressed beamforming feedback matrices as defined Y N _TYPE is in 19.3.12.3.6. The number of elements depends on the number of spatial COMPRESSED_SV streams and the number of transmit chains. EXPANSION_MAT Contains a set of noncompressed beamforming feedback matrices as Y N EXPANSION_MAT _TYPE is defined in 19.3.12.3.5. The number of complex elements is N ST N r N c NON_COMPRESSE where N ST is the total number of subcarriers, N c is the number of D_SV columns, and N r is the number of rows in each matrix. EXPANSION Contains a set of CSI matrices as defined in 19.3.12.3.2. The number of Y N _MAT_TYPE is complex elements is N ST N r N c where N ST is the total number of CSI_MATRICES subcarriers, N c is the number of columns, and N r is the number of rows in each matrix. Otherwise Not present N N EXPANSION_MAT Enumerated type: Y N EXPANSION_MAT_TYPE is present COMPRESSED_SV indicates that EXPANSION_MAT is a set of compressed beamforming feedback matrices. NON_COMPRESSED_SV indicates that EXPANSION_MAT is a set of noncompressed beamforming feedback matrices. CSI_MATRICES indicates that EXPANSION_MAT is a set of channel state matrices. Otherwise Not present N N CHAN_MAT_TYPE Contains a set of compressed beamforming feedback matrices as defined N Y is in 19.3.12.3.6 based on the channel measured during the training symbols COMPRESSED_SV of the received PPDU. The number of elements depends on the number of spatial streams and the number of transmit chains. CHAN_MAT_TYPE Contains a set of noncompressed beamforming feedback matrices as N Y is defined in 19.3.12.3.5 based on the channel measured during the training NON_COMPRESSE symbols of the received PPDU. The number of complex elements is CHAN_MAT D_SV N ST N r N c where N ST is the total number of subcarriers, N c is the number of columns, and N r is the number of rows in each matrix. CHAN_MAT_TYPE Contains a set of CSI matrices as defined in 19.3.12.3.2 based on the N Y is CSI_MATRICES channel measured during the training symbols of the received PPDU. The number of complex elements is N ST N r N c where N ST is the total number of subcarriers, N c is the number of columns, and N r is the number of rows in each matrix. Otherwise Not present N N 2340 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 19-1â€”TXVECTOR and RXVECTOR parameters (continued) RXVECTOR TXVECTOR Parameter Condition Value See NOTE 1 FORMAT is HT_MF Enumerated type: N Y CHAN_MAT_TYPE or HT_GF COMPRESSED_SV indicates that CHAN_MAT is a set of compressed beamforming vector matrices. NON_COMPRESSED_SV indicates that CHAN_MAT is a set of noncompressed beamforming vector matrices. CSI_MATRICES indicates that CHAN_MAT is a set of channel state matrices. Otherwise Not present N N Is a measure of the received RF power averaged over all of the receive N Y RCPI chains in the data portion of a received frame. Refer to 19.3.19.6 for the definition of RCPI. CHAN_MAT_TYPE Is a measure of the received SNR per chain. SNR indications of 8 bits are N Y is CSI_MATRICES supported. SNR shall be the decibel representation of linearly averaged values over the tones represented in each receive chain as described in 9.4.1.28 SNR CHAN_MAT_TYPE Is a measure of the received SNR per stream. SNR indications of 8 bits are N Y is supported. SNR shall be the sum of the decibel values of SNR per tone COMPRESSED_SV divided by the number of tones represented in each stream as described in or 9.4.1.29 and 9.4.1.30 NON_COMPRESSE D_SV FORMAT is HT_MF Indicates whether signal extension needs to be applied at the end of Y N or HT_GF transmission. NO_SIG_EXTN Or Boolean values: true indicates no signal extension is present. FORMAT is false indicates signal extension may be present depending on other NON_HT and TXVECTOR parameters (see 19.2.2). NON_HT_MODUL ATION is NON_HT_ DUP_OFDM Otherwise Not present N N 2341 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 19-1â€”TXVECTOR and RXVECTOR parameters (continued) RXVECTOR TXVECTOR Parameter Condition Value See NOTE 1 Enumerated type: TIME_OF_DEPARTURE_REQUESTED O N true indicates that the MAC entity requests that the PHY entity measures and reports time of departure parameters corresponding to the time when the first frame energy is sent by the transmitting port. false indicates that the MAC entity requests that the PHY entity neither measures nor reports time of departure parameters. 0 to 232â€“ 1. An estimate of the offset (in 10 ns units) from the point in time N O RX_START_OF_FRAME_OFFSET at which the start of the preamble corresponding to the incoming frame arrived at the receive antenna connector to the point in time at which this primitive is issued to the MAC. NOTE 1â€”In the â€œTXVECTORâ€ and â€œRXVECTORâ€ columns, the following apply: Y = Present; N = Not present; O = Optional. NOTE 2â€”Setting the smoothing bit is defined in 19.3.11.11.2. 19.2.3 PHYCONFIG_VECTOR parameters The PHYCONFIG_VECTOR carried in a PHY-CONFIG.request primitive for an HT PHY contains an OPERATING_CHANNEL parameter, which identifies the operating or primary channel. The PHY shall set dot11CurrentPrimaryChannel to the value of this parameter. The PHYCONFIG_VECTOR carried in a PHY-CONFIG.request primitive for an HT PHY contains a SECONDARY_CHANNEL_OFFSET parameter, which takes one of the following values: â€” SECONDARY_CHANNEL_NONE if no secondary channel is present; in this case the PHY shall set dot11CurrentSecondaryChannel to 0. â€” SECONDARY_CHANNEL_ABOVE if the secondary channel is above the primary channel; in this case the PHY shall set dot11CurrentSecondaryChannel to dot11CurrentPrimaryChannel + 4. 2342 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” SECONDARY_CHANNEL_BELOW if the secondary channel is below the primary channel; in this case the PHY shall set dot11CurrentSecondaryChannel to dot11CurrentPrimaryChannel â€“ 4. 19.2.4 Effect of CH_BANDWIDTH, CH_OFFSET, and MCS parameters on PPDU format The structure of the PPDU transmitted by an HT STA is determined by the TXVECTOR FORMAT, CH_BANDWIDTH, CH_OFFSET, and MCS parameters as defined in Table 19-1. The effect of the FORMAT parameter is described in 19.1.4. The operation of the PHY in the frequency domain is determined by the FORMAT, CH_BANDWIDTH, and CH_OFFSET parameters. Table 19-2 shows the valid combinations of FORMAT, CH_BANDWIDTH, and CH_OFFSET and the corresponding PPDU format. Other combinations are reserved. Table 19-2â€”Interpretation of FORMAT, CH_BANDWIDTH, and CH_OFFSET parameters FORMAT CH_BANDWIDTH CH_OFFSET HF_MF, HT_CBW20 CH_OFF_20: 20 MHz HT formatâ€”The STA has a 20 MHz operating HF_GF channel width and transmits an HT-mixed or HT-greenfield format PPDU of 20 MHz bandwidth. CH_OFF_20U: 40 MHz HT upper formatâ€”The STA transmits an HT-mixed or HT-greenfield format PPDU of 20 MHz bandwidth in the upper 20 MHz of a 40 MHz channel. CH_OFF_20L: 40 MHz HT lower formatâ€”The STA transmits an HT- mixed or HT-greenfield format PPDU of 20 MHz bandwidth in the lower 20 MHz of a 40 MHz channel. HT_MF, HT_CBW40 CH_OFF_40: 40 MHz HT formatâ€”The STA transmits an HT-mixed HT_GF or HT-greenfield format PPDU of 40 MHz bandwidth. NON_HT NON_HT_CBW20 and CH_OFF_20: 20 MHz non-HT formatâ€”The STA has a 20 MHz the operating channel width and transmits an ERP-DSSS, ERP-CCK, SECONDARY_CHANN ERP-OFDM, or OFDM format PPDU. EL_OFFSET parameter of the PHYCONFIG_VECTOR is SECONDARY_CHANN EL_NONE NON_HT NON_HT_CBW20 and CH_OFF_20U: 40 MHz non-HT upper formatâ€”The STA transmits an the ERP-DSSS, ERP-CCK, ERP-OFDM, or OFDM format PPDU, in the SECONDARY_CHANN upper 20 MHz of a 40 MHz channel. EL_OFFSET parameter of the PHYCONFIG_VECTOR is SECONDARY_CHANN EL_BELOW 2343 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 19-2â€”Interpretation of FORMAT, CH_BANDWIDTH, and CH_OFFSET parameters (continued) FORMAT CH_BANDWIDTH CH_OFFSET NON_HT NON_HT_CBW20 and CH_OFF_20L: 40 MHz non-HT lower formatâ€”The STA transmits an the ERP-DSSS, ERP-CCK, ERP-OFDM, or OFDM format PPDU, in the SECONDARY_CHANN lower 20 MHz of a 40 MHz channel. EL_OFFSET parameter of the PHYCONFIG_VECTOR is SECONDARY_CHANN EL_ABOVE NON_HT NON_HT_CBW40 CH_OFF_40: Non-HT duplicate formatâ€”The STA transmits an ERP- OFDM or OFDM format PPDU in each of the 20 MHz channels of a 40 MHz channel. The upper channel (higher frequency) is rotated by +90Â° relative to the lower channel. See 19.3.11.12. NOTEâ€”Support of 20 MHz non-HT format and 20 MHz HT format with one and two spatial streams is mandatory at APs. Support of 20 MHz non-HT format and 20 MHz HT format with one spatial stream is mandatory at non-AP STAs. 19.2.5 Support for NON_HT formats When the FORMAT parameter is equal to NON_HT, the behavior of the HT PHY is defined in other clauses as shown in Table 19-3, dependent on the operational band. In this case, the PHY-TXSTART.request primitive is handled by mapping the TXVECTOR parameters as defined in Table 19-3 and following the operation as defined in the referenced clause. Likewise the PHY-RXSTART.indication primitive emitted when a non-HT PPDU is received is defined in the referenced clauses, with mapping of RXVECTOR parameters as defined in Table 19-3. Table 19-3â€”Mapping of the HT PHY parameters for NON_HT operation 2.4 GHz operation 2.4 GHz operation 2.4 GHz operation 5.0 GHz operation HT PHY defined by defined by defined by defined by parameter Clause 15 Clause 16 Clause 18 Clause 17 L_LENGTH LENGTH LENGTH LENGTH LENGTH L_DATARATE DATARATE DATARATE DATARATE DATARATE LSIGVALID â€” â€” â€” â€” TXPWR_LEVEL_I TXPWR_LEVEL_I TXPWR_LEVEL_I TXPWR_LEVEL_I TXPWR_LEVEL_I NDEX NDEX NDEX NDEX NDEX RSSI RSSI RSSI RSSI RSSI FORMAT â€” â€” â€” â€” PREAMBLE_TYP â€” â€” PREAMBLE_TYP â€” E E NON_HT_MODUL â€” â€” MODULATION â€” ATION SERVICE SERVICE SERVICE SERVICE SERVICE MCS â€” â€” â€” â€” 2344 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 19-3â€”Mapping of the HT PHY parameters for NON_HT operation (continued) 2.4 GHz operation 2.4 GHz operation 2.4 GHz operation 5.0 GHz operation HT PHY defined by defined by defined by defined by parameter Clause 15 Clause 16 Clause 18 Clause 17 CH_BANDWIDTH â€” â€” â€” â€” CH_OFFSET â€” â€” â€” â€” LENGTH â€” â€” â€” â€” SMOOTHING â€” â€” â€” â€” SOUNDING â€” â€” â€” â€” AGGREGATION â€” â€” â€” â€” STBC â€” â€” â€” â€” FEC_CODING â€” â€” â€” â€” GI_TYPE â€” â€” â€” â€” NUM_EXTEN_SS â€” â€” â€” â€” ANTENNA_SET â€” â€” â€” â€” EXPANSION_MAT â€” â€” â€” â€” EXPANSION_MAT â€” â€” â€” â€” _TYPE CHAN_MAT â€” â€” â€” â€” CHAN_MAT_TYP â€” â€” â€” â€” E N_TX â€” â€” â€” â€” RCPI RCPI RCPI RCPI RCPI REC_MCS â€” â€” â€” â€” NO_SIG_EXTN â€” â€” â€” â€” TIME_OF_DEPART TIME_OF_DEPART TIME_OF_DEPART TIME_OF_DEPART TIME_OF_DEPART URE_REQUESTED URE_REQUESTED URE_REQUESTED URE_REQUESTED URE_REQUESTED NOTEâ€”A dash (â€”) in an entry above indicates that the related parameter is not present. Non-HT format PPDUs structured according to Clause 15, Clause 17, Clause 16, or Clause 18 are transmitted â€” Within the limits of the transmit spectrum mask specified in the respective clauses, or â€” As non-HT duplicate PPDUs within the limits of the 40 MHz transmit spectrum mask defined in 19.3.18.1, or â€” As 20 MHz format non-HT PPDUs, within the limits of the 40 MHz transmit spectrum mask defined in 19.3.18.1, in the upper (CH_BANDWIDTH of value NON_HT_CBW20 and CH_OFFSET of value CH_OFF_20U) or lower (CH_BANDWIDTH of value NON_HT_CBW20 and CH_OFFSET of value CH_OFF_20U) 20 MHz of the 40 MHz channel Non-HT PPDUs transmitted using the 40 MHz transmit spectrum mask are referred to as 40 MHz mask non- HT PPDUs. Refer to 11.16.9 for CCA sensing rules for transmission of 40 MHz mask non-HT PPDUs. 2345 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 19.2.6 TXSTATUS parameters The parameters listed in Table 19-4 are defined as part of the TXSTATUS parameter list in the PHY- TXSTART.confirm(TXSTATUS) service primitive. Table 19-4â€”TXSTATUS parameter Parameter Value TIME_OF_DEPARTURE 0 to 232â€“ 1. The locally measured time when the first frame energy is sent by the transmitting port, in units equal to 1/ TIME_OF_DEPARTURE_ClockRate. This parameter is present only if TIME_OF_DEPARTURE_REQUESTED is true in the corresponding request. TIME_OF_DEPARTURE_ClockRate 0 to 216â€“ 1. The clock rate, in units of MHz, is used to generate the TIME_OF_DEPARTURE value. This parameter is present only if TIME_OF_DEPARTURE_REQUESTED is true in the corresponding request. TX_START_OF_FRAME_OFFSET 0 to 232â€“ 1. An estimate of the offset (in 10 ns units) from the point in time at which the start of the preamble corresponding to the frame was transmitted at the transmit antenna connector to the point in time at which this primitive is issued to the MAC. 19.3 HT PHY 19.3.1 Introduction Subclause 19.3 provides a procedure in which PSDUs are converted to and from PPDUs. During transmission, the PSDU is processed (i.e., scrambled and coded) and appended to the PHY preamble to create the PPDU. At the receiver, the PHY preamble is processed to aid in demodulation and delivery of the PSDU. Two preamble formats are defined. For HT-mixed format operation, the preamble has a non-HT portion and an HT portion. The non-HT portion of the HT-mixed format preamble enables detection of the PPDU and acquisition of carrier frequency and timing by both HT STAs and STAs that are compliant with Clause 17 and/or Clause 18. The non-HT portion of the HT-mixed format preamble also consists of the SIGNAL field defined in Clause 17 and is thus decodable by STAs compliant with Clause 17 and Clause 18 as well as HT STAs. The HT portion of the HT-mixed format preamble enables estimation of the MIMO channel to support demodulation of the HT data by HT STAs. The HT portion of the HT-mixed format preamble also includes the HT-SIG field, which supports HT operation. The SERVICE field is prepended to the PSDU. For HT-greenfield operation, compatibility with Clause 17 and Clause 18 STAs is not required. Therefore, the non-HT portions of the preamble are not included in the HT-greenfield format preamble. 19.3.2 PPDU format Two formats are defined for the PPDU: HT-mixed format and HT-greenfield format. These two formats are called HT formats. Figure 19-1 shows the non-HT format48 and the HT formats. There is also an MCS 32 format (specified in 19.3.11.11.5) used for MCS 32 that provides the lowest rate in a 40 MHz channel. In 48 The non-HT format is shown related to the terminology of this subclause. The non-HT PPDU format is defined in 17.3.3 and 17.3.2. 2346 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications addition to the HT formats, there is a non-HT duplicate format (specified in 19.3.11.12) that duplicates the 20 MHz non-HT packet in two 20 MHz halves of a 40 MHz channel. Format of Data field SERVICE Scrambled 6Â·NES Pad (non LDPC case only) 16 bits PSDU Tail bits bits Non-HT PPDU 8 Âµs 8 Âµs 4 Âµs L- L-STF L-LTF Data SIG HT-mixed format PPDU Data HT-LTFs Extension HT-LTFs 8 Âµs 8 Âµs 4 Âµs 8 Âµs 4 Âµs 4 Âµs per LTF 4 Âµs per LTF L- HT- HT- HT- HT- HT- L-STF L-LTF HT-SIG Data SIG STF LTF LTF LTF LTF HT-greenfield format PPDU Data HT-LTFs Extension HT-LTFs 8 Âµs 8 Âµs 8 Âµs 4 Âµs per LTF 4 Âµs per LTF HT- HT- HT- HT- HT-GF-STF HT-LTF1 HT-SIG Data LTF LTF LTF LTF Figure 19-1â€”PPDU format The elements of the PPDU are summarized in Table 19-5. Table 19-5â€”Elements of the HT PPDU Element Description L-STF Non-HT Short Training field L-LTF Non-HT Long Training field L-SIG Non-HT SIGNAL field HT-SIG HT SIGNAL field HT-STF HT Short Training field HT-GF-STF HT-Greenfield Short Training field HT-LTF1 First HT Long Training field (Data) HT-LTFs Additional HT Long Training fields (Data and Extension) Data The Data field includes the PSDU The HT-SIG, HT-STF, HT-GF-STF, HT-LTF1, and HT-LTFs exist only in HT packets. In non-HT packets only the L-STF, L-LTF, L-SIG, and Data fields exist. In both HT-mixed format and HT-greenfield format frames, there are two types of HT-LTFs: Data HT-LTFs (HT-DLTFs) and Extension HT-LTFs (HT-ELTFs). HT-DLTFs are always included in HT PPDUs to provide the necessary reference for the receiver to form a channel estimate that allows it to demodulate the data 2347 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications portion of the frame. The number of HT-DLTFs, N HT - DLTF , may be 1, 2, or 4 and is determined by the number of space-time streams being transmitted in the frame (see Table 19-13). HT-ELTFs provide additional reference in sounding PPDUs so that the receiver can form an estimate of additional dimensions of the channel beyond those that are used by the data portion of the frame. The number of HT-ELTFs, N HT - ELTF , may be 0, 1, 2, or 4 (see Table 19-14). PHY preambles in which HT-DLTFs are followed by HT-ELTFs are referred to as staggered preambles. The HT-mixed format and HT-greenfield format frames shown in Figure 19-1 both contain staggered preambles for illustrative purposes. Transmissions of frames with TXVECTOR parameter NO_SIG_EXTN equal to false are followed by a period of no transmission for a duration of aSignalExtension. See 10.3.8. A Signal Extension shall be present in a transmitted PPDU, based on the parameters of the TXVECTOR, when the NO_SIG_EXTN parameter is equal to false and either of the following is true: â€” The FORMAT parameter is equal to HT_MF or HT_GF. â€” The FORMAT parameter is equal to NON_HT, and the NON_HT_MODULATION parameter is equal to ERP-OFDM, or NON_HT_DUP_OFDM. A Signal Extension shall be assumed to be present (for the purpose of timing of PHY-RXEND.indication and PHY-CCA.indication primitives, as described below and in 19.3.21) in a received PPDU when either of the following is true, based on the determined parameter values of the RXVECTOR: â€” The FORMAT parameter is equal to HT_MF or HT_GF. â€” The FORMAT parameter is equal to NON_HT, and the NON_HT_MODULATION parameter is equal to ERP-OFDM, or NON_HT_DUP_OFDM. A PPDU containing a Signal Extension is called a signal extended PPDU. When transmitting a signal extended PPDU, the PHY-TXEND.indication primitive shall be emitted a period of aSignalExtension after the end of the last symbol of the PPDU. When receiving a signal extended PPDU, the PHY- RXEND.indication primitive shall be emitted a period of aSignalExtension after the end of the last symbol of the PPDU. 19.3.3 Transmitter block diagram HT-mixed format and HT-greenfield format transmissions can be generated using a transmitter consisting of the following blocks: a) Scrambler scrambles the data to reduce the probability of long sequences of 0s or 1s; see 19.3.11.3. b) Encoder parser, if BCC encoding is to be used, demultiplexes the scrambled bits among NES (number of BCC encoders for the Data field) BCC encoders, in a round robin manner. c) FEC encoders encode the data to enable error correction. An FEC encoder may include a binary convolutional encoder followed by a puncturing device, or it may include an LDPC encoder. d) Stream parser divides the outputs of the encoders into blocks that are sent to different interleaver and mapping devices. The sequence of the bits sent to an interleaver is called a spatial stream. e) Interleaver interleaves the bits of each spatial stream (changes order of bits) to prevent long sequences of adjacent noisy bits from entering the BCC decoder. Interleaving is applied only when BCC encoding is used. f) Constellation mapper maps the sequence of bits in each spatial stream to constellation points (complex numbers). g) STBC encoder spreads constellation points from N SS spatial streams into N STS space-time streams using a space-time block code. STBC is used only when N SS N STS ; see 19.3.11.9.2. 2348 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications h) Spatial mapper maps space-time streams to transmit chains. This may include one of the following: 1) Direct mapping: Constellation points from each space-time stream are mapped directly onto the transmit chains (one-to-one mapping). 2) Spatial expansion: Vectors of constellation points from all of the space-time streams are expanded via matrix multiplication to produce the input to all of the transmit chains. 3) Beamforming: Similar to spatial expansion, each vector of constellation points from all of the space-time streams is multiplied by a matrix of steering vectors to produce the input to the transmit chains. i) Inverse discrete Fourier transform (IDFT) converts a block of constellation points to a time domain block. j) Cyclic shift (CSD) insertion is where the insertion of the cyclic shifts prevents unintentional beamforming. CSD insertion may occur before or after the IDFT. There are three cyclic shift types as follows: 1) A cyclic shift specified per transmitter chain with the values defined in Table 19-9 (a possible implementation is shown in Figure 19-2). 2) A cyclic shift specified per space-time stream with the values defined in Table 19-10 (a possible implementation is shown in Figure 19-3). 3) A cyclic shift M CSD k that may be applied as a part of the spatial mapper; see 19.3.11.11.2. k) GI insertion prepends to the symbol a circular extension of itself. l) Windowing optionally smooths the edges of each symbol to increase spectral decay. Figure 19-2 and Figure 19-3 show example transmitter block diagrams. In particular, Figure 19-2 shows the transmitter blocks used to generate the HT-SIG of the HT-mixed format PPDU. These transmitter blocks are also used to generate the non-HT portion of the HT-mixed format PPDU, except that the BCC encoder and interleaver are not used when generating the L-STF and L-LTFs. Figure 19-3 shows the transmitter blocks used to generate the Data field of the HT-mixed format and HT-greenfield format PPDUs. A subset of these transmitter blocks consisting of the constellation mapper and CSD blocks, as well as the blocks to the right of, and including, the spatial mapping block, are also used to generate the HT-STF, HT-GF-STF, and HT-LTFs. The HT-greenfield format SIGNAL field is generated using the transmitter blocks shown in Figure 19-2, augmented by additional CSD and spatial mapping blocks. 19.3.4 Overview of the PPDU encoding process The encoding process is composed of the steps described below. The following overview is intended to facilitate an understanding of the details of the convergence procedure: a) Determine the number of transmit chains, N TX , from the N_TX field of the TXVECTOR. Produce the PHY preamble training fields for each of the N TX transmit chains based on the FORMAT, NUM_EXTEN_SS, CH_BANDWIDTH, and MCS parameters of the TXVECTOR. The format and relative placement of the PHY preamble training fields vary depending on the frame format being used, as indicated by these parameters. Apply cyclic shifts. Determine spatial mapping to be used for HT-STF and HT-LTFs in HT-mixed format frame and HT-GF-STF and HT-LTFs in HT-greenfield format frame from the EXPANSION_MAT parameter of the TXVECTOR. Refer to 19.3.9 for details. b) Construct the PHY preamble SIGNAL fields from the appropriate fields of the TXVECTOR by adding tail bits, applying convolutional coding, formatting into one or more OFDM symbols, applying cyclic shifts, applying spatial processing, calculating an inverse Fourier transform for each OFDM symbol and transmit chain, and prepending a cyclic prefix or GI to each OFDM symbol in each transmit chain. The number and placement of the PHY preamble SIGNAL fields depend on the frame format being used. Refer to 19.3.9.3.5, 19.3.9.4.3, and 19.3.9.5.4. 2349 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Insert Analog GI and and RF Window Insert Analog BCC Encoder Constellation CSD GI and and RF Interleaver Window Mapper IDFT Insert Analog CSD GI and and RF Window Insert Analog CSD GI and and RF Window Single Spatial Stream NTX Transmit Chains Figure 19-2â€”Transmitter block diagram 1 Insert Constellation GI Analog Interleaver IDFT mapper and and RF Window FEC encoder Insert Constellation Analog Interleaver CSD IDFT GI and mapper and RF Window Stream Parser Spatial Mapping Encoder Parser Scrambler STBC Insert Constellation Analog Interleaver CSD IDFT GI and mapper and RF Window FEC encoder Insert Constellation Analog Interleaver CSD IDFT GI and mapper and RF Window NSS Spatial Streams NSTS Spaceâ€time NTX Transmit Chains NOTES Streams â€”There might be 1 or 2 FEC encoders when BCC encoding is used. â€”The stream parser might have 1, 2, 3 or 4 outputs. â€”When LDPC encoding is used, the interleavers are not used â€”When STBC is used, the STBC block has more outputs than inputs. â€”When spatial mapping is used, there might be more transmit chains than space-time streams. â€”The number of inputs to the spatial mapper might be 1, 2, 3, or 4. Figure 19-3â€”Transmitter block diagram 2 2350 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications c) Concatenate the PHY preamble training and SIGNAL fields for each transmit chain one field after another, in the appropriate order, as described in 19.3.2 and 19.3.7. d) Use the MCS and CH_BANDWIDTH parameters of the TXVECTOR to determine the number of data bits per OFDM symbol ( N DBPS ), the coding rate ( R ), the number of coded bits in each OFDM subcarrier ( N BPSC ), and the number of coded bits per OFDM symbol ( N CBPS ). Determine the number of encoding streams ( N ES ) from the MCS, CH_BANDWIDTH, and FEC_CODING parameters of the TXVECTOR. Refer to 19.3.11.4 for details. e) Append the PSDU to the SERVICE field (see 19.3.11.2). If BCC encoding is to be used, as indicated by the FEC_CODING parameter of the TXVECTOR, tail bits are appended to the PSDU. If a single BCC encoder is used (i.e., when the value of N ES is 1), the bit string is extended by 6 zero bits. If two BCC encoders are used (i.e., when the value of N ES is 2), the bit string is extended by 12 zero bits. The number of symbols, N SYM , is calculated according to Equation (19-32), and if necessary, the bit string is further extended with zero bits so that the resulting length is a multiple of N SYM N DBPS , as described in 19.3.11. If LDPC encoding is to be used, as indicated by the FEC_CODING parameter of the TXVECTOR, the resulting bit string is padded, if needed, by repeating coded bits rather than using zero bits, as given in the encoding procedure of 19.3.11.7.5. The number of resulting symbols is given by Equation (19-41), and the number of repeated coded bits used for padding is given by Equation (19-42). The resulting bit string constitutes the DATA part of the packet. f) Initiate the scrambler with a pseudorandom nonzero seed, generate a scrambling sequence, and exclusive-OR (XOR) it with the string of data bits, as described in 17.3.5.5. g) If BCC encoding is to be used, replace the scrambled zero bits that served as tail bits (6 bits if the value of N ES is 1, or 12 bits if the value of N ES is 2) following the data with the same number of nonscrambled zero bits, as described in 17.3.5.3. (These bits return the convolutional encoder to the zero state.) h) If BCC encoding is to be used and the value of N ES is 2, divide the scrambled data bits between two BCC encoders by sending alternating bits to the two different encoders, as described in 19.3.11.5. i) If BCC encoding is to be used, encode the extended, scrambled data string with a rate 1/2 convolutional encoder (see 17.3.5.6). Omit (puncture) some of the encoder output string (chosen according to puncturing pattern) to reach the coding rate, R, corresponding to the TXVECTOR parameters MCS or L_DATARATE. Refer to 19.3.11.6 for details. If LDPC encoding is to be used, encode the scrambled data stream according to 19.3.11.7.5. j) Parse the coded bit stream that results from the BCC encoding or LDPC encoding into N SS spatial streams, where the value of N SS is determined from the MCS parameter of the TXVECTOR. See 19.3.11.8.2 for details. k) Divide each of the N SS encoded and parsed spatial streams of bits into groups of N CBPSS i bits. If BCC encoding is to be used, within each spatial stream and group, perform an interleaving (reordering) of the bits according to a rule corresponding to N BPSCS i , where i is the index of the spatial stream. Refer to 19.3.6 for details. l) For each of the N SS encoded, parsed, and interleaved spatial streams, divide the resulting coded and interleaved data string into groups of N BPSCS i bits, where i is the index of the spatial stream. For each of the bit groups, convert the bit group into a complex number according to the modulation encoding tables. Refer to 17.3.5.8 for details. 2351 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications m) Divide the complex number string for each of the resulting N SS spatial streams into groups of N SD complex numbers, where the value of N SD is determined from the CH_OFFSET parameter of TXVECTOR and the CH_BANDWIDTH parameter of TXVECTOR. Each such group is associated with one OFDM symbol in one spatial stream. In each group, the complex numbers are indexed 0 to N SD â€“ 1 , and these indices have an associated one-to-one correspondence with subcarrier indices r via the mapping function M k as described in 19.3.11.11, 19.3.11.11.3, 19.3.11.11.4, 19.3.11.11.5, and 19.3.11.12. n) If STBC is to be applied, as indicated by the STBC parameter in the TXVECTOR, operate on the complex number associated with each data subcarrier in sequential pairs of OFDM symbols as described in 19.3.11.9.2 to generate N STS OFDM symbols for every N SS OFDM symbols associated with the N SS spatial streams. If STBC is not to be used, the number of space-time streams is the same as the number of spatial streams, and the sequences of OFDM symbols in each space-time stream are composed of the sequences of OFDM symbols in the corresponding spatial stream. In each group of N SD resulting complex numbers in each space-time stream, the complex numbers indexed 0 to N SD â€“ 1 are mapped onto OFDM subcarriers via the mapping function r M k as described in 19.3.11.11, 19.3.11.11.3, 19.3.11.11.4, 19.3.11.11.5, and 19.3.11.12. o) Determine whether 20 MHz or 40 MHz operation is to be used from the CH_BANDWIDTH parameter of the TXVECTOR. Specifically, when CH_BANDWIDTH is HT_CBW20 or NON_HT_CBW20, 20 MHz operation is to be used. When CH_BANDWIDTH is HT_CBW40 or NON_HT_CBW40, 40 MHz operation is to be used. For 20 MHz operation (with the exception of non-HT formats), insert four subcarriers as pilots into positions â€“21, â€“7, 7, and 21. The total number of the subcarriers, N ST , is 56. For 40 MHz operation (with the exception of MCS 32 and non-HT duplicate format), insert six subcarriers as pilots into positions â€“53, â€“25, â€“11, 11, 25, and 53, resulting in a total of N ST = 114 subcarriers. See 19.3.11.11.5 for pilot locations when using MCS 32 and 19.3.11.12 for pilot locations when using non-HT duplicate format. The pilots are modulated using a pseudorandom cover sequence. Refer to 19.3.11.10 for details. For 40 MHz operation, apply a +90Â° phase shift to the complex value in each OFDM subcarrier with an index greater than 0, as described in 19.3.11.11.4, 19.3.11.11.5, and 19.3.11.12. p) Map each of the complex numbers in each of the N ST subcarriers in each of the OFDM symbols in each of the N STS space-time streams to the N TX transmit chain inputs. For direct-mapped operation, N TX = N STS , and there is a one-to-one correspondence between space-time streams and transmit chains. In this case, the OFDM symbols associated with each space-time stream are also associated with the corresponding transmit chain. Otherwise, a spatial mapping matrix associated with each OFDM subcarrier, as indicated by the EXPANSION_MAT parameter of the TXVECTOR, is used to perform a linear transformation on the vector of N STS complex numbers associated with each subcarrier in each OFDM symbol. This spatial mapping matrix maps the vector of N STS complex numbers in each subcarrier into a vector of N TX complex numbers in each subcarrier. The sequence of N ST complex numbers associated with each transmit chain (where each of the N ST complex numbers is taken from the same position in the N TX vector of complex numbers across the N ST subcarriers associated with an OFDM symbol) constitutes an OFDM symbol associated with the corresponding transmit chain. For details, see 19.3.11.11. Spatial mapping matrices may include cyclic shifts, as described in 19.3.11.11.2. q) If the CH_BANDWIDTH and CH_OFFSET parameters of the TXVECTOR indicate that upper or lower 20 MHz are to be used in 40 MHz, move the complex numbers associated with subcarriers â€“28 to 28 in each transmit chain to carriers 4 to 60 in the upper channel or â€“60 to â€“4 in the lower 2352 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications channel. Note that this shifts the signal in frequency from the center of the 40 MHz channel to +10 MHz or â€“10 MHz offset from the center of the 40 MHz channel. The complex numbers in the other subcarriers are set to 0. r) For each group of N ST subcarriers and each of the N TX transmit chains, convert the subcarriers to time domain using IDFT. Prepend to the Fourier-transformed waveform a circular extension of itself, thus forming a GI, and truncate the resulting periodic waveform to a single OFDM symbol length by applying time domain windowing. Determine the length of the GI according to the GI_TYPE parameter of the TXVECTOR. Refer to 19.3.11.11 and 19.3.11.12 for details. When beamforming is not used, it is sometimes possible to implement the cyclic shifts in the time domain. s) Append the OFDM symbols associated with each transmit chain one after another, starting after the final field of the PHY preamble. Refer to 19.3.2 and 19.3.7 for details. t) Upconvert the resulting complex baseband waveform associated with each transmit chain to an RF signal according to the center frequency of the desired channel and transmit. Refer to 19.3.7 for details. The transmit chains are connected to antenna elements according to ANTENNA_SET of the TXVECTOR if ASEL is applied. 19.3.5 Modulation and coding scheme (MCS) The MCS is a value that determines the modulation, coding, and number of spatial channels. It is a compact representation that is carried in the HT-SIG. Rate-dependent parameters for the full set of MCSs are shown in Table 19-27 through Table 19-41 (in 19.5). These tables give rate-dependent parameters for MCSs with indices 0 to 76. MCSs with indices 0 to 7 and 32 have a single spatial stream; MCSs with indices 8 to 31 have multiple spatial streams using equal modulation (EQM) on all of the streams; MCSs with indices 33 to 76 have multiple spatial streams using unequal modulation (UEQM) on the spatial streams. MCS indices 77 to 127 are reserved. Table 19-27 through Table 19-30 show rate-dependent parameters for EQM MCSs for one, two, three, and four streams for 20 MHz operation. Table 19-31 through Table 19-34 show rate-dependent parameters for EQM MCSs in one, two, three, and four streams for 40 MHz operation. The same EQM MCSs are used for 20 MHz and 40 MHz operation. Table 19-35 shows rate-dependent parameters for the 40 MHz, 6 Mb/s MCS 32 format. The remaining tables, Table 19-36 to Table 19-41, show rate-dependent parameters for the MCSs with UEQM of the spatial streams for use with NSS > 1. UEQM MCSs are detailed in the following tables: â€” Table 19-36 through Table 19-38 are for 20 MHz operation. â€” Table 19-39 through Table 19-41 are for 40 MHz operation. An HT STA shall support all equal modulation (EQM) rates for one spatial stream (MCSs 0 to 7) using a 20 MHz channel width. An HT AP that is not a VHT AP shall support all EQM rates for two spatial streams (MCSs 8 to 15) using a 20 MHz channel width. All other MCSs and modes are optional, specifically including transmit and receive support of 400 ns GI, operation in 40 MHz, and support of MCSs with indices 16 to 76. 2353 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 19.3.6 Timing-related parameters Table 19-6 defines the timing-related parameters. Table 19-6â€”Timing-related constants TXVECTOR CH_BANDWIDTH HT_CBW40 or Parameter NON_HT_CBW40 NON_HT_CBW20 HT_CBW_20 HT MCS 32 and format non-HT duplicate NSD: Number of complex 48 52 108 48 data numbers NSP: Number of pilot 4 4 6 4 values NST: Total number of 52 56 114 104 subcarriers See NOTE 1 NSR: Highest data 26 28 58 58 subcarrier index F : Subcarrier frequency 312.5 kHz 312.5 kHz 312.5 kHz spacing (20 MHz/64) (40 MHz/128) TDFT: IDFT/DFT period 3.2 Âµs 3.2 Âµs 3.2 Âµs TGI: Guard interval 0.8 Âµs= TDFT/4 0.8 Âµs 0.8 Âµs duration TGI2: Double guard 1.6 Âµs 1.6 Âµs 1.6 Âµs interval TGIS: Short guard interval N/A 0.4 Âµs = TDFT/8 0.4 Âµs duration See NOTE 2 TL-STF: Non-HT short 8 Âµs=10Ã— TDFT/4 8 Âµs 8 Âµs training sequence duration THT-GF-STF: HT-greenfield N/A 8 Âµs=10Ã— TDFT/4 8 Âµs short training field duration See NOTE 2 TL-LTF: Non-HT long 8 Âµs=2Ã— TDFT+TGI2 8 Âµs 8 Âµs training field duration TSYM: Symbol interval 4 Âµs= TDFT+TGI 4 Âµs 4 Âµs TSYMS: Short GI symbol N/A 3.6 Âµs = TDFT+TGIS 3.6 Âµs interval See NOTE 2 TL-SIG: Non-HT SIGNAL 4 Âµs= TSYM 4 Âµs 4 Âµs field duration THT-SIG: HT SIGNAL field N/A 8 Âµs= 2TSYM 8 Âµs duration See NOTE 2 THT-STF: HT short training N/A 4 Âµs 4 Âµs field duration See NOTE 2 2354 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 19-6â€”Timing-related constants (continued) TXVECTOR CH_BANDWIDTH HT_CBW40 or Parameter NON_HT_CBW40 NON_HT_CBW20 HT_CBW_20 HT MCS 32 and format non-HT duplicate THT-LTF1: First HT long N/A 4 Âµs in HT-mixed 4 Âµs in HT-mixed format, 8 Âµs in training field duration format, 8 Âµs in HT- HT-greenfield format greenfield format See NOTE 2 THT-LTFs: Second, and N/A 4 Âµs 4 Âµs subsequent, HT long See NOTE 2 training fields duration NOTE 1â€”NST = NSD + NSP except in the cases of MCS 32 and non-HT duplicate, where the number of data subcarriers differs from the number of complex data numbers, and the number of pilot subcarriers differs from the number of pilot values. In those cases, data numbers and pilot values are replicated in upper and lower 20 MHz portions of 40 MHz signal to make a total of 104 subcarriers. NOTE 2â€”Not applicable in non-HT formats. NOTE 3â€”N/A = Not applicable. Table 19-7 defines parameters used frequently in Clause 19. Table 19-7â€”Frequently used parameters Symbol Explanation N CBPS Number of coded bits per symbol N CBPSS i Number of coded bits per symbol per the i-th spatial stream N DBPS Number of data bits per symbol N BPSC Number of coded bits per single carrier N BPSCS i Number of coded bits per single carrier for spatial stream i N RX Number of receive chains N STS Number of space-time streams N SS Number of spatial streams N ESS Number of extension spatial streams N TX Number of transmit chains N ES Number of BCC encoders for the Data field N HT-LTF Number of HT Long Training fields (see 19.3.9.4.6) N HT-DLTF Number of Data HT Long Training fields N HT-ELTF Number of Extension HT Long Training fields R Coding rate 2355 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 19.3.7 Mathematical description of signals For the description of the convention on mathematical description of signals, see 17.3.2.5. In the case of either a 20 MHz non-HT format (TXVECTOR parameter FORMAT equal to NON_HT, MODULATION parameter equal to one of {ERP-OFDM, OFDM}) transmission or a 20 MHz HT format (TXVECTOR parameter FORMAT equal to HT_MF or HT_GF, CH_BANDWIDTH equal to HT_CBW_20) transmission, the channel is divided into 64 subcarriers. In the 20 MHz non-HT format, the signal is transmitted on subcarriers â€“26 to â€“1 and 1 to 26, with 0 being the center (dc) carrier. In the 20 MHz HT format, the signal is transmitted on subcarriers â€“28 to â€“1 and 1 to 28. In the case of the 40 MHz HT format, a 40 MHz channel is used. The channel is divided into 128 subcarriers. The signal is transmitted on subcarriers â€“58 to â€“2 and 2 to 58. In the case of 40 MHz HT upper format or 40 MHz HT lower format, the upper or lower 20 MHz is divided into 64 subcarriers. The signal is transmitted on subcarriers â€“60 to â€“4 in the case of a 40 MHz HT lower format transmission and on subcarriers 4 to 60 in the case of a 40 MHz HT upper format transmission. In the case of the MCS 32 and non-HT duplicate formats, the same data are transmitted over two adjacent 20 MHz channels. In this case, the 40 MHz channel is divided into 128 subcarriers, and the data are transmitted on subcarriers â€“58 to â€“6 and 6 to 58. The transmitted signal is described in complex baseband signal notation. The actual transmitted signal is related to the complex baseband signal by the relation shown in Equation (19-1). r RF t = Re r t exp j2 f c t (19-1) where fc is the center frequency of the carrier The transmitted RF signal is derived by modulating the complex baseband signal, which consists of several fields. The timing boundaries for the various fields are shown in Figure 19-4. HT- HT- HT- HT- HT-mixed Format L-STF L-LTF L-SIG HT-SIG STF LTF1 LTF2 ... LTFn Data Data tL-LTF tL-SIG tHT-SIG tHT-STF tHT-LTF tHT-Data HT-greenfield HT- HT- Format HT-GF-STF HT-LTF1 HT-SIG LTF2 ... LTFn Data Data tHT-LTF1 tHT-SiG tHT-LTFs tHT-Data Figure 19-4â€”Timing boundaries for PPDU fields The time offset, t Field , determines the starting time of the corresponding field. In HT-mixed format, the signal transmitted on transmit chain i TX shall be as shown in Equation (19-2). 2356 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications iTX TX i TX i r PPDU t = r L-STF t + r L-LTF t â€“ t L-LTF (19-2) i TX i TX i TX + r L-SIG t â€“ t L-SIG + r HT-SIG t â€“ t HT-SIG + r HT-STF t â€“ t HT-STF N HTLTF i i TX LTF TX i + r HT-LTF t â€“ t HT-LTF â€“ i LTF â€“ 1 T HT-LTFs + r HT-DATA t â€“ t HT-DATA i LTF = 1 where t L-LTF = T L-STF t L-SIG = t L-LTF + T L-LTF t HT-SIG = t L-SIG + T L-SIG t HT-STF = t HT-SIG + T HT-SIG t HT-LTF = t HT-STF + T HT-STF t HT-Data = t HT-LTF + N HT - LTF T HT-LTFs In the case of HT-greenfield format, the transmitted signal on transmit chain iTX shall be as shown in Equation (19-3). iTX i i r PPDU t = r HTTXâ€“ GF â€“ STF t + r HTTXâ€“ LTF 1 t â€“ t HT â€“ LTF 1 i + r HTTXâ€“ SIG t â€“ t HT â€“ SIG (19-3) N HTLTF i i + r HTTXâ€“ LTF LTF t â€“ t HT â€“ LTFs â€“ i LTF â€“ 2 T HT â€“ LTFs i LTF = 2 i + r HTTXâ€“ DATA t â€“ t HT â€“ DATA where t HT â€“ LTF 1 = T HT â€“ GF â€“ STF t HT-SIG = t HT-LTF1 + T HT-LTF1 t HT-LTFs = t HT-SIG + T HT-SIG t HT-Data = t HT-LTFs + N HT - LTF â€“ 1 T HT-LTFs TX i Each baseband waveform, r Field t , is defined via the discrete Fourier transform (DFT) per OFDM symbol as shown in Equation (19-4). i TX 1 i TX r Field t = ------------------------------- w TField t k Xk exp j2 k Ft (19-4) Tone N Field N TX k 2357 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This general representation holds for all fields. A suggested definition of the windowing function, w TField t , i is given in 17.3.2.5. The frequency domain symbols X k TX represent the output of any spatial processing in subcarrier k for transmit chain i TX required for the field. The function k is used to represent a rotation of the upper tones in a 40 MHz channel as shown in Equation (19-5) and Equation (19-6). = 1 k 0 in a 40 MHz channel (19-5) k j k 0 in a 40 MHz channel k = 1 in a 20 MHz channel (19-6) Tone The 1 N Field N TX scale factor in Equation (19-4) causes the total power of the time domain signal as summed over all transmit chains to be either 1 or lower than 1 when required. Table 19-8 summarizes the Tone various values of N Field . Tone Table 19-8â€”Value of tone scaling factor N Field Tone N Field , see NOTE 1 Field 20 MHz 40 MHz L-STF 12 24 HT-GF-STF 12 24 L-LTF 52 104 L-SIG 52 104 HT-SIG 52/56, see NOTE 2 104/114, see NOTE 2 HT-STF 12 24 HT-LTF 56 114 HT-DATA 56 114 MCS 32 â€” 104 Non-HT Duplicate â€” 104 Tone NOTE 1â€”The numbers in the table refer only to the value of N Field as it appears in Equation (19-4) and in subsequent specification of various fields. This value might be different from the actual number of tones being transmitted. NOTE 2â€”The values 56 and 114 are for HT-greenfield format; the values 52 and 104 are for HT-mixed format. 19.3.8 Transmission in the upper/lower 20 MHz of a 40 MHz channel When transmitting in the upper/lower 20 MHz portion of a 40 MHz channel, the mathematical definition of transmission shall follow that of a 20 MHz channel with f c in Equation (19-1) replaced by f c 10 MHz . 2358 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This rule applies to 20 MHz HT transmission in the upper/lower 20 MHz of a 40 MHz channel (TXVECTOR primitive CH_BANDWIDTH equal to HT_CBW20 and CH_OFFSET primitive equal to CH_OFF_20U or CH_OFF_20L) and to 20 MHz non-HT transmission in the upper/lower 20 MHz of a 40 MHz channel (TXVECTOR primitive CH_BANDWIDTH equal to NON_HT_CBW20 and CH_OFFSET primitive equal to CH_OFF_20U or CH_OFF_20L). 19.3.9 HT preamble 19.3.9.1 Introduction The HT preambles are defined in HT-mixed format and in HT-greenfield format to carry the required information to operate in a system with multiple transmit and multiple receive antennas. In the HT-mixed format, to provide compatibility with non-HT STAs, specific non-HT fields are defined so that they can be received by non-HT STAs compliant with Clause 17 or Clause 18 followed by the fields specific to HT STAs. In the HT-greenfield format, all of the non-HT fields are omitted. The specific HT fields used are as follows: â€” One HT-GF-STF for automatic gain control convergence, timing acquisition, and coarse frequency acquisition, â€” One or several HT-LTFs, provided as a way for the receiver to estimate the channel between each spatial mapper input and receive chain. The first HT-LTFs (HT-DLTFs) are necessary for demodulation of the HT-Data portion of the PPDU and are followed, for sounding packets only, by optional HT-LTFs (HT-ELTFs) to sound extra spatial dimensions of the MIMO channel, â€” HT-SIG, which provides all the information required to interpret the HT packet format. In the case of multiple transmit chains, the HT preambles use cyclic shift techniques to prevent unintentional beamforming. 19.3.9.2 HT-mixed format preamble In HT-mixed format frames, the preamble has fields that support compatibility with Clause 17 and Clause 18 STAs and fields that support HT operation. The non-HT portion of the HT-mixed format preamble enables detection of the PPDU and acquisition of carrier frequency and timing by both HT STAs and STAs that are compliant with Clause 17 or Clause 18. The non-HT portion of the HT-mixed format preamble contains the SIGNAL field (L-SIG) defined in Clause 17 and is thus decodable by STAs compliant with Clause 17 and Clause 18 as well as HT STAs. The HT portion of the HT-mixed format preamble enables estimation of the MIMO channel to support demodulation of the data portion of the frame by HT STAs. The HT portion of the HT-mixed format preamble also contains the HT-SIG field that supports HT operation. 19.3.9.3 Non-HT portion of the HT-mixed format preamble 19.3.9.3.1 Introduction The transmission of the non-HT training fields and the L-SIG as part of an HT-mixed format packet is described in 19.3.9.3.2 through 19.3.9.3.5. 19.3.9.3.2 Cyclic shift definition The cyclic shift values defined in this subclause apply to the non-HT fields in the HT-mixed format preamble and the HT-SIG in the HT-mixed format preamble. 2359 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Cyclic shifts are used to prevent unintentional beamforming when the same signal or scalar multiples of one signal are transmitted through different spatial streams or transmit chains. A cyclic shift of duration TCS on a signal s t on interval 0 t T is defined as follows, where T is defined as T DFT as referenced in Table 19-6. With T CS 0 , replace s t with s t â€“ T CS when 0 t T + T CS and with s t â€“ T CS â€“ T when T + T CS t T . The cyclic-shifted signal is defined as shown in Equation (19-7). s t â€“ T CS 0 t T + T CS s CS t ;T CS = (19-7) T CS 0 s t â€“ T CS â€“ T T + T CS t T The cyclic shift is applied to each OFDM symbol in the packet separately. Table 19-9 specifies the values for the cyclic shifts that are applied in the L-STF (in an HT-mixed format packet), the L-LTF, and L-SIG. It also applies to the HT-SIG in an HT-mixed format packet. Table 19-9â€”Cyclic shift for non-HT portion of packet i T CSTX values for non-HT portion of packet Cyclic shift for Cyclic shift for Cyclic shift for Cyclic shift for Number of transmit chain 1 transmit chain 2 transmit chain 3 transmit chain 4 transmit chains (ns) (ns) (ns) (ns) 1 0 â€” â€” â€” 2 0 â€“200 â€” â€” 3 0 â€“100 â€“200 â€” 4 0 â€“50 â€“100 â€“150 With more than four transmit chains, each cyclic shift on the additional transmit chains shall be between â€“200 ns and 0 ns inclusive. 19.3.9.3.3 L-STF definition The L-STF is identical to the Clause 17 short training symbol. The non-HT short training OFDM symbol in the 20 MHz channel width is shown in Equation (19-8). S â€“ 26,26 = 1 2 0 0 1 + j 0 0 0 â€“ 1 â€“ j 0 0 0 1 + j 0 0 0 â€“1 â€“ j 0 0 0 â€“ 1 â€“ j 0 0 0 1 + j 0 0 0 (19-8) 0 0 0 0 â€“1â€“j 0 0 0 â€“1â€“j 0 0 0 1+j 0 0 0 1+j 0 0 0 1+j 0 0 0 1+j 0 0 The normalization factor 1 2 is the QPSK normalization. The non-HT short training OFDM symbol in a 40 MHz channel width is given by Equation (19-9), after rotating the tones in the upper subchannel (subcarriers 6â€“58) by +90Â° (see Equation (19-10)). 2360 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications S â€“58,58 = 1 2 0 0 1+j 0 0 0 â€“ 1 â€“ j 0 0 0 1 + j 0 0 0 â€“1 â€“ j 0 0 0 â€“ 1 â€“ j 0 0 0 1 + j 0 0 0 0 0 0 0 â€“1â€“j 0 0 0 â€“1â€“j 0 0 0 1+j 0 0 0 1+j 0 0 0 1+j 0 0 0 1+j 0 0 0 0 0 (19-9) 0 0 0 0 0 0 0 0 0 0 1+j 0 0 0 â€“1â€“j 0 0 0 1+j 0 0 0 â€“1â€“j 0 0 0 â€“1â€“j 0 0 0 1+j 0 0 0 0 0 0 0 â€“1â€“j 0 0 0 â€“1â€“j 0 0 0 1+j 0 0 0 1+j 0 0 0 1+j 0 0 0 1+j 0 0 In HT-mixed format, the L-STF on transmit chain i TX shall be as shown in Equation (19-10). N SR i TX 1 i TX r L â€“ STF t = ------------------------------------ w TL â€“ STF t k S k exp j2 k F t â€“ T CS (19-10) Tone N TX N L â€“ STF k = â€“ N SR where i TX T CS represents the cyclic shift for transmit chain i TX and takes values from Table 19-9 k is defined in Equation (19-5) and Equation (19-6) The L-STF has a period of 0.8 Âµs. The entire STF includes ten such periods, with a total duration of T L-STF = 8 Âµs. 19.3.9.3.4 L-LTF definition The non-HT long training OFDM symbol is identical to the Clause 17 long training OFDM symbol. In the 20 MHz channel width, the long training OFDM symbol is given by Equation (19-11). L â€“26,26 = 1 1 â€“1 â€“1 1 1 â€“1 1 â€“1 1 1 1 1 1 1 â€“1 â€“1 1 1 â€“1 1 â€“1 1 1 1 1 0 (19-11) 1 â€“1 â€“1 1 1 â€“1 1 â€“1 1 â€“1 â€“1 â€“1 â€“1 â€“ 1 1 1 â€“ 1 â€“1 1 â€“ 1 1 â€“ 1 1 1 1 1 The non-HT long training OFDM symbol in a 40 MHz channel width is given by Equation (19-12), after rotating the tones in the upper subchannel (subcarriers 6â€“58) by +90Â° (see Equation (19-13)). L â€“ 58,58 = 1 1 â€“1 â€“1 1 1 â€“1 1 â€“1 1 1 1 1 1 1 â€“1 â€“1 1 1 â€“1 1 â€“1 1 1 1 1 0 (19-12) 1 â€“1 â€“1 1 1 â€“1 1 â€“1 1 â€“1 â€“1 â€“1 â€“1 â€“1 1 1 â€“ 1 â€“ 1 1 â€“ 1 1 â€“ 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 1 1 â€“1 â€“1 1 1 â€“1 1 â€“1 1 1 1 1 1 1 â€“1 â€“1 1 1 â€“1 1 â€“1 1 1 1 1 0 1 â€“1 â€“1 1 1 â€“ 1 1 â€“ 1 1 â€“ 1 â€“1 â€“1 â€“1 â€“1 1 1 â€“1 â€“1 1 â€“1 1 â€“1 1 1 1 1 The subcarriers at Â± 32 in 40 MHz, which are the dc subcarriers for the non-HT 20 MHz transmission, are both nulled in the L-LTF. Such an arrangement allows proper synchronization of a 20 MHz non-HT STA. The L-LTF waveform shall be as shown in Equation (19-13). N SR i 1 i r L TX â€“ LTF t = ------------------------------------ w TL â€“ LTF t k L k exp j2 k F TX t â€“ T GI 2 â€“ T CS (19-13) Tone N TX N L â€“ LTF k = â€“ N SR where T GI 2 is 1.6 s i TX T CS represents the cyclic shift for transmit chain i TX and takes values specified in Table 19-9 2361 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications k is defined in Equation (19-5) and Equation (19-6) The entire LTF includes two 3.2 Âµs IDFT/DFT periods and an additional 1.6 Âµs double GI. The entire LTF is modulated with the L-LTF waveform. 19.3.9.3.5 L-SIG definition The L-SIG is used to communicate rate and length information.The structure of the L-SIG is shown in Figure 19-5. Rate Length Tail (4 bits) (12 bits) (6 bits) R P R1 R2 R3 R4 â€œ0â€ â€œ0â€ â€œ0â€ â€œ0â€ â€œ0â€ â€œ0â€ 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 Figure 19-5â€”L-SIG structure The value in the Rate field is obtained from the L_DATARATE field of the TXVECTOR. The value in the Length field is obtained from the L_LENGTH field of the TXVECTOR. The Length field is transmitted LSB first. The reserved bit shall be set to 0. The parity field has the even parity of bits 0â€“16. The L-SIG shall be encoded, interleaved and mapped, and it shall have pilots inserted following the steps described in 17.3.5.6, 17.3.5.7, and 17.3.5.9. The stream of 48 complex numbers generated by the steps described in 17.3.5.7 is denoted by d k k = 0 47 . The time domain waveform of the L-SIG in 20 MHz transmission shall be as given by Equation (19-14). 26 i 1 i r L TX t = ------------------------------------ w TSYM t TX â€“ SIG D k + p 0 P k exp j2 k F t â€“ T GI â€“ T CS (19-14) Tone N TX N L â€“ SIG k = â€“ 26 In a 40 MHz transmission the time domain waveform of the L-SIG shall be as given by Equation (19-15). 26 i 1 r L TX â€“ SIG t = ------------------------------------ w TSYM t Dk + p0 Pk Tone N TX N L â€“ SIG k = â€“ 26 (19-15) TX i i TX exp j2 k â€“ 32 F t â€“ T GI â€“ T CS + j exp j2 k + 32 F t â€“ T GI â€“ T CS where 0 k = 0 7 21 Dk = d Mr k otherwise 2362 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications k + 26 â€“ 26 k â€“ 22 k + 25 â€“ 20 k â€“ 8 r M k = k + 24 â€“6 k â€“1 k + 23 1 k 6 k + 22 8 k 20 k + 21 22 k 26 Pk is defined in 17.3.5.10 p0 is the first pilot value in the sequence defined in 17.3.5.10 Tone N L â€“ SIG has the value given in Table 19-8 i TX T CS represents the cyclic shift for transmit chain i TX and is defined by Table 19-9 for HT-mixed format PPDUs NOTEâ€” D k exists for â€“ N SR k N SR and takes the values from dk that exists for 0 k N SD â€“ 1 . M r k is a â€œreverseâ€ function of the function M k defined in 17.3.5.10. 19.3.9.4 HT portion of HT-mixed format preamble 19.3.9.4.1 Introduction When an HT-mixed format preamble is transmitted, the HT preamble consists of the HT-STF, the HT-LTFs, and the HT-SIG. 19.3.9.4.2 Cyclic shift definition The cyclic shift values defined in this subclause apply to the HT-STF and HT-LTFs of the HT-mixed format preamble. The cyclic shift values defined in 19.3.9.3.2 apply to the HT-SIG in an HT-mixed format preamble. Throughout the HT portion of an HT-mixed format preamble, cyclic shift is applied to prevent beamforming when similar signals are transmitted in different space-time streams. The same cyclic shift is applied to these streams during the transmission of the data portion of the frame. The values of the cyclic shifts to be used during the HT portion of the HT-mixed format preamble (with the exception of the HT_SIG) and the data portion of the frame are specified in Table 19-10. Table 19-10â€”Cyclic shift values of HT portion of packet iSTS T CS values for HT portion of packet Number of Cyclic shift for Cyclic shift for Cyclic shift for Cyclic shift for space-time space-time stream 1 space-time stream 2 space-time stream 3 space-time stream 4 streams (ns) (ns) (ns) (ns) 1 0 â€” â€” â€” 2 0 â€“400 â€” â€” 3 0 â€“400 â€“200 â€” 4 0 â€“400 â€“200 â€“600 2363 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 19.3.9.4.3 HT-SIG definition The HT-SIG is used to carry information required to interpret the HT packet formats. The fields of the HT-SIG are described in Table 19-11. Table 19-11â€”HT-SIG fields Number Field Explanation and coding of bits Modulation and 7 Index into the MCS table. Coding Scheme See NOTE 1. CBW 20/40 1 Set to 0 for 20 MHz or 40 MHz upper/lower. Set to 1 for 40 MHz. HT Length 16 The number of octets of data in the PSDU in the range 0 to 65 535. See NOTE 1 and NOTE 2. Smoothing 1 Set to 1 indicates that channel estimate smoothing is recommended. Set to 0 indicates that only per-carrier independent (unsmoothed) channel estimate is recommended. See 19.3.11.11.2. Not Sounding 1 Set to 0 indicates that PPDU is a sounding PPDU. Set to 1 indicates that the PPDU is not a sounding PPDU. Reserved 1 Set to 1. Aggregation 1 Set to 1 to indicate that the PPDU in the data portion of the packet contains an A- MPDU; otherwise, set to 0. STBC 2 Set to a nonzero number, to indicate the difference between the number of space- time streams ( N STS ) and the number of spatial streams ( N SS ) indicated by the MCS. Set to 00 to indicate no STBC ( N STS = N SS ). See NOTE 1. FEC Coding 1 Set to 1 for LDPC. Set to 0 for BCC. Short GI 1 Set to 1 to indicate that the short GI is used after the HT training. Set to 0 otherwise. Number of 2 Indicates the number of extension spatial streams ( N ESS ). Extension Spatial Set to 0 for no extension spatial stream. Streams Set to 1 for 1 extension spatial stream. Set to 2 for 2 extension spatial streams. Set to 3 for 3 extension spatial streams. See NOTE 1. CRC 8 CRC of bits 0â€“23 in HT-SIG1 and bits 0â€“9 in HT-SIG2. See 19.3.9.4.4. The first bit to be transmitted is bit C7 as explained in 19.3.9.4.4. Tail Bits 6 Used to terminate the trellis of the convolution coder. Set to 0. NOTE 1â€”Integer fields are transmitted in unsigned binary format, LSB first. NOTE 2â€”A value of 0 in the HT Length field indicates a PPDU that does not include a data field, i.e., NDP. NDP transmissions are used for sounding purposes only (see 10.34.2). The packet ends after the last HT-LTF or the HT-SIG. 2364 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The structure of the HT-SIG1 and HT-SIG2 fields is defined in Figure 19-6. CBW 20/40 Modulation and Coding HT Length Scheme LSB MSB LSB MSB 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 HT-SIG1 Number of Extension Spatial Not Sounding FEC Coding Aggregation Smoothing Reserved CRC Tail Bits Streams Short GI STBC C7 C0 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 HT-SIG2 LSB LSB Figure 19-6â€”Format of HT-SIG1 and HT-SIG2 The HT-SIG is composed of two parts, HT-SIG1 and HT-SIG2, each containing 24 bits, as shown in Figure 19-6. All of the fields in the HT-SIG are transmitted LSB first, and HT-SIG1 is transmitted before HT-SIG2. The HT-SIG parts shall be encoded at R = 1/2, interleaved, and mapped to a BPSK constellation, and they have pilots inserted following the steps described in 17.3.5.6, 17.3.5.7, 17.3.5.8, and 17.3.5.9, respectively. The BPSK constellation is rotated by 90Â° relative to the L-SIG in order to accommodate detection of the start of the HT-SIG. The stream of 96 complex numbers generated by these steps is divided into two groups of 48 complex numbers: d k n 0 k 47 n = 0 1 . The time domain waveform for the HT-SIG in an HT- mixed format packet in a 20 MHz transmission shall be as shown in Equation (19-16). 1 i TX 1 r HT â€“ SIG t = --------------------------------------- w TSYM t â€“ nT SYM Tone N TX N HT â€“ SIG n=0 (19-16) 26 iTX jD k n + p n + 1 P k exp j2 k F t â€“ nT SYM â€“ T GI â€“ T CS k = â€“ 26 2365 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications In a 40 MHz transmission the time domain waveform shall be as shown in Equation (19-17). 1 i TX 1 r HT â€“ SIG t = --------------------------------------- w TSYM t â€“ nT SYM Tone N TX N HT â€“ SIG n=0 26 i TX (19-17) jD k n + p n + 1 P k exp j2 k â€“ 32 F t â€“ nT SYM â€“ T GI â€“ T CS k = â€“ 26 i TX + j exp j2 k + 32 F t â€“ nT SYM â€“ T GI â€“ T CS where 0 k = 0 7 21 Dk n = d Mr k n otherwise r M k is defined in 19.3.9.3 P k and p n are defined in 17.3.5.10 Tone N HT â€“ SIG has the value given in Table 19-8 i TX T CS represents the cyclic shift for transmit chain i TX and is defined by Table 19-9 for HT-mixed format PPDUs. NOTEâ€”This definition results in a quadrature binary phase shift keying (QBPSK) modulation in which the constellation of the data tones is rotated by 90Â° relative to the L-SIG in HT-mixed format PPDUs and relative to the first HT-LTF in HT-greenfield format PPDUs (see Figure 19-7). In HT-mixed format PPDUs, the HT-SIG is transmitted with the same number of subcarriers and the same cyclic shifts as the preceding non-HT portion of the preamble. This is done to accommodate the estimation of channel parameters needed to robustly demodulate and decode the information contained in the HT-SIG. Q Q L-SIG HT-SIG +1 +1 1 0 1 I I â€“1 +1 â€“1 +1 â€“1 â€“1 0 Figure 19-7â€”Data tone constellations in an HT-mixed format PPDU 19.3.9.4.4 CRC calculation for HT-SIG The CRC protects bits 0â€“33 of the HT-SIG (bits 0â€“23 of HT-SIG1 and bits 0â€“9 of HT-SIG2). The value of the CRC field shall be the 1s complement of 2366 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 8 crc D = M D I D D mod G D (19-18) where 33 32 M D = m0 D + m1 D + + m 32 D + m 33 is the HT-SIG represented as a polynomial where m0 is bit 0 of HT-SIG1 m 33 is bit 9 of HT-SIG2 33 i I D = D are initialization values that are added modulo 2 to the first 8 bits of HT-SIG1 i = 26 8 2 G D = D + D + D + 1 is the CRC generating polynomial 7 6 crc D = c 0 D + c 1 D + + c6 D + c7 The CRC field is transmitted with c7 first. Figure 19-8 shows the operation of the CRC. First, the shift register is reset to all 1s. The bits are then passed through the XOR operation at the input. When the last bit has entered, the output is generated by shifting the bits out of the shift register, C7 first, through an inverter. m33 to The feedback term is set to 0 during the shifting out of the result. m0 0 Serial c c c c c c c c Input 7 6 5 4 3 2 1 0 Serial Output Figure 19-8â€”HT-SIG CRC calculation As an example, if bits m 0 m 33 are given by {1 1 1 1 0 0 0 1 0 0 1 0 0 1 1 0 0 0 0 0 0 0 0 0 1 1 1 0 0 0 0 0 0 0}, the output bits B 7 B 0 , where B7 is output first, are {1 0 1 0 1 0 0 0}. 19.3.9.4.5 HT-STF definition The purpose of the HT-STF is to improve automatic gain control estimation in a MIMO system. The duration of the HT-STF is 4 Âµs. In a 20 MHz transmission, the frequency sequence used to construct the HT-STF is identical to L-STF. In a 40 MHz transmission, the HT-STF is constructed from the 20 MHz version by duplicating and frequency shifting and by rotating the upper subcarriers by 90Â°. The frequency sequences are shown in Equation (19-19) and Equation (19-20). 2367 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications For 20 MHz: HTS â€“28,28 = 1 2 (19-19) 0 0 0 0 1 + j 0 0 0 â€“ 1 â€“ j 0 0 0 1 + j 0 0 0 â€“1 â€“ j 0 0 0 â€“ 1 â€“ j 0 0 0 1 + j 0 0 0 0 0 0 0 â€“1â€“j 0 0 0 â€“1â€“j 0 0 0 1+j 0 0 0 1+j 0 0 0 1+j 0 0 0 1+j 0 0 0 0 For 40 MHz: HTS â€“58,58 = 1 2 (19-20) 0 0 1+j 0 0 0 â€“ 1 â€“ j 0 0 0 1 + j 0 0 0 â€“1 â€“ j 0 0 0 â€“ 1 â€“ j 0 0 0 1 + j 0 0 0 0 0 0 0 â€“1â€“j 0 0 0 â€“1â€“j 0 0 0 1+j 0 0 0 1+j 0 0 0 1+j 0 0 0 1+j 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1+j 0 0 0 â€“1â€“j 0 0 0 1+j 0 0 0 â€“1â€“j 0 0 0 â€“1â€“j 0 0 0 1+j 0 0 0 0 0 0 0 â€“1â€“j 0 0 0 â€“1â€“j 0 0 0 1+j 0 0 0 1+j 0 0 0 1+j 0 0 0 1+j 0 0 The time domain representation of the transmission in transmit chain i TX shall be as shown in Equation (19-21). i TX 1 r HT â€“ STF t = ----------------------------------------- w T HT â€“ STF t Tone N STS N HT â€“ STF (19-21) N SR N STS iSTS Qk i TX i STS k HTS k exp j2 k F t â€“ T CS k = â€“ N SR i STS = 1 where i STS T CS represents the cyclic shift for the space-time stream i STS and takes the values given in Table 19-10 Qk is defined in 19.3.11.11.2 k is defined in Equation (19-5) and Equation (19-6) 19.3.9.4.6 HT-LTF definition The HT-LTF provides a means for the receiver to estimate the MIMO channel between the set of QAM mapper outputs (or, if STBC is applied, the STBC encoder outputs) and the receive chains. If the transmitter is providing training for exactly the space-time streams (spatial mapper inputs) used for the transmission of the PSDU, the number of training symbols, N LTF , is equal to the number of space-time streams, N STS , except that for three space-time streams, four training symbols are required. If the transmitter is providing training for more space-time streams (spatial mapper inputs) than the number used for the transmission of the PSDU, the number of training symbols is greater than the number of space-time streams. This latter case happens in a sounding PPDU. The HT-LTF portion has one or two parts. The first part consists of one, two, or four HT-LTFs that are necessary for demodulation of the HT-Data portion of the PPDU. These HT-LTFs are referred to as HT-DLTFs. The optional second part consists of zero, one, two, or four HT-LTFs that may be used to sound extra spatial dimensions of the MIMO channel that are not utilized by the HT-Data portion of the PPDU. These HT-LTFs are referred to as HT-ELTFs. If a receiver has not advertised its ability to receive HT-ELTFs, it shall either issue a PHY-RXEND.indication(UnsupportedRate) primitive upon reception of a frame that includes HT-ELTFs or decode that frame. (When an HT packet includes one or more HT-ELTFs, it is 2368 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications optional for a receiver that has not advertised its capability to receive HT-ELTFs to decode the data portion of the PPDU.) The number of HT-DLTFs is denoted N HT - DLTF . The number of HT-ELTFs is denoted N HT - ELTF . The total number of HT-LTFs is shown in Equation (19-22). N HT - LTF = N HT - DLTF + N HT - ELTF (19-22) N HT - LTF shall not exceed 5. Table 19-12 shows the determination of the number of space-time streams from the MCS and STBC fields in the HT-SIG. Table 19-13 shows the number of HT-DLTFs as a function of the number of space-time streams ( N STS ). Table 19-14 shows the number of HT-ELTFs as a function of the number of extension spatial streams ( N ESS ). N STS plus N ESS is less than or equal to 4. In the case where N STS equals 3, N ESS cannot exceed one; if N ESS equals one in this case then N LTF equals 5. Table 19-12â€”Determining the number of space-time streams Number of Spatial Number of Streams (from MCS) STBC field space-time N SS streams N STS 1 0 1 1 1 2 2 0 2 2 1 3 2 2 4 3 0 3 3 1 4 4 0 4 Table 19-13â€”Number of HT-DLTFs required for data space-time streams N STS N HTDLTF 1 1 2 2 3 4 4 4 2369 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 19-14â€”Number of HT-ELTFs required for extension spatial streams N ESS N HT-ELTF 0 0 1 1 2 2 3 4 The HT-LTF sequence shown in Equation (19-23) is transmitted in the case of 20 MHz operation. HT-LTF -28,28 = 1 1 1 1 â€“ 1 â€“ 1 1 1 â€“ 1 1 â€“ 1 1 1 1 1 1 1 â€“ 1 â€“ 1 1 1 â€“ 1 1 â€“ 1 1 1 1 1 0 1 â€“ 1 â€“ 1 1 1 â€“ 1 1 â€“ 1 1 â€“ 1 â€“1 â€“1 â€“1 â€“1 1 1 â€“ 1 â€“ 1 1 â€“ 1 1 â€“ 1 1 1 1 1 â€“ 1 â€“ 1 (19-23) NOTEâ€”This sequence is an extension of the L-LTF where the four extra subcarriers are filled with +1 for negative frequencies and â€“1 for positive frequencies. In 40 MHz transmissions, including MCS 32 format frames, the sequence to be transmitted is shown in Equation (19-24). HT-LTF -58,58 = 1 1 â€“ 1 â€“ 1 1 1 â€“ 1 1 â€“ 1 1 1 1 1 1 1 â€“ 1 â€“ 1 1 1 â€“ 1 1 â€“ 1 1 1 1 1 1 1 â€“ 1 â€“ 1 1 1 â€“ 1 1 â€“ 1 1 â€“ 1 â€“ 1 â€“ 1 â€“ 1 â€“1 1 1 â€“ 1 â€“ 1 1 â€“ 1 1 â€“ 1 1 1 1 1 â€“1 â€“1 â€“1 1 0 0 0 â€“1 1 1 â€“1 1 1 â€“1 â€“1 1 1 â€“1 1 â€“1 1 1 1 1 1 1 â€“1 â€“1 1 1 â€“1 1 â€“1 1 1 1 1 1 (19-24) 1 â€“1 â€“1 1 1 â€“1 1 â€“1 1 â€“1 â€“1 â€“1 â€“1 â€“1 1 1 â€“1 â€“1 1 â€“1 1 â€“1 1 1 1 1 NOTEâ€”This sequence is also constructed by extending the L-LTF in the following way: first, the L-LTF is duplicated and shifted as explained in 19.3.9.3.4 for the non-HT duplicate format; then the missing subcarriers [â€“32, â€“5, â€“4, â€“3, â€“2, 2, 3, 4, 5, 32] are filled with the values [1, â€“1, â€“1, â€“1, 1, â€“1, 1, 1, â€“1, 1], respectively. This sequence, occupying 114 tones, is used even if the data portion is transmitted with MCS 32 format, which uses 104 tones. NOTEâ€”This sequence uses 114 tones when MCS 32 format is used to retain consistency with other 40 MHz formats and to facilitate channel estimation for beamforming and link adaptation. In an HT-mixed format preamble, each HT-LTF consists of a single occurrence of the sequence plus a GI insertion and has a duration of 4 Âµs. In case of multiple space-time streams, cyclic shift is invoked as specified in Table 19-10. The generation of HT-DLTFs is shown in Figure 19-9. The generation of HT-ELTFs is shown in Figure 19-10. In these figures, and in the following text, the following notational conventions are used: â€” X m n indicates the element in row m and column n of matrix X â€” X N indicates a matrix consisting of the first N columns of matrix X â€” X M:N indicates a matrix consisting of columns M to N of matrix X where M N X is either Q k or P HT - LTF 2370 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications [PHT-LTF]1,n HT-LTFk x IFFT CSD Qk N STS IFFT x [PHT-LTF] NSTS , n Figure 19-9â€”Generation of HT-DLTFs [PHT-LTF]1, n-NHT-DLTF HT-LTFk x IFFT Qk CSD N STS 1:N STS N ESS IFFT x [PHT-LTF] NESS, n-NHT-DLTF Figure 19-10â€”Generation of HT-ELTFs The mapping between space-time streams and transmit chains is defined by the columns of an antenna map matrix Q k for subcarrier k. The first N STS columns define the space-time streams used for data transmission, and the next N ESS columns (up to N TX â€“ N STS columns) define the extension spatial streams. Thus, for the purpose of defining HT-LTFs, Q k is an N TX N STS + N ESS dimension matrix. Columns 1 N STS of Q k are excited by the HT-DLTFs, and columns N STS + 1 N STS + N ESS are excited by the HT- ELTFs, where N STS + N ESS N TX is the total number of spatial streams being probed by the HT-LTFs. Possible forms of Q k and other limitations on Q k are specified in 19.3.11.11.2. P HT - LTF is defined in Equation (19-27). 2371 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The time domain representation of the waveform transmitted on transmit chain i TX during HT-DLTF n, where 1 n N HT - DLTF , shall be as shown in Equation (19-25). n i TX 1 r HT â€“ LTF t = ------------------------------------------ w THT â€“ LTFs t (19-25) Tone N STS N HT â€“ LTF N SR N STS i STS Qk i TX i STS P HT - LTF i STS n k HT-LTF k exp j2 k F t â€“ T GI â€“ T CS k = â€“ N SR i STS = 1 For the HT-ELTFs N HT - DLTF n N HT - LTF , it shall be as shown in Equation (19-26). n i 1 r HTTXâ€“ LTF t = ------------------------------------------ w THT â€“ LTFs t (19-26) Tone N HT â€“ LTF N ESS N SR N ESS Qk i TX N STS + i ESS P HT - LTF i ESS n â€“ N HTDLTF k HT-LTF k k = â€“ N SR i ESS = 1 ESS i exp j2 k F t â€“ T GI â€“ T CS where i STS T CS cyclic shift values are given in Table 19-10 i ESS T CS cyclic shift values are given in Table 19-10 with i ESS = i STS Qk is defined in 19.3.11.11.2 k is defined in Equation (19-5) and Equation (19-6) P HT - LTF the HT-LTF mapping matrix, is given by Equation (19-27) 1 â€“1 1 1 P HT - LTF = 1 1 â€“1 1 (19-27) 1 1 1 â€“1 â€“1 1 1 1 2372 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 19.3.9.5 HT-greenfield format preamble 19.3.9.5.1 General For HT-greenfield operation, compatibility with Clause 17 and Clause 18 STAs is not required. Therefore, the portions of the preamble that are compatible with Clause 17 and Clause 18 STAs are not included. The result is a shorter and more efficient PHY frame format that includes a STF, LTF(s), and an HT-SIG. 19.3.9.5.2 Cyclic shift definition for HT-greenfield format preamble Throughout the HT-greenfield format preamble, cyclic shift is applied to prevent beamforming when similar signals are transmitted on different spatial streams. The same cyclic shift is applied to these streams during the transmission of the data portion of the frame. The values of the cyclic shift to be used during the HT- greenfield format preamble, as well as the data portion of the HT-greenfield format frame, are specified in Table 19-10. 19.3.9.5.3 HT-GF-STF definition The HT-GF-STF is placed at the beginning of an HT-greenfield format frame. The time domain waveform for the HT-GF-STF on transmit chain i TX shall be as shown in Equation (19-28). i 1 r HTTXâ€“ GF â€“ STF t = ---------------------------------------------------- w THT â€“ GF â€“ STF t Tone N STS N HT â€“ GF â€“ STF (19-28) N SR N STS iSTS Qk i TX i STS P HT - LTF i STS 1 k S k exp j2 k F t â€“ T CS k = â€“ N SR i STS = 1 where i STS T CS represents the cyclic shift for the space-time stream i STS and takes values from Table 19-10 Qk is defined in 19.3.11.11.2 P HT - LTF is defined in Equation (19-27) Sk is defined in non-HT-STF (L-STF), Equation (19-8) for 20 MHz operation and Equation (19- 9) for 40 MHz operation k is defined in Equation (19-5) and Equation (19-6) The waveform defined by Equation (19-28) has a period of 0.8 Âµs, and the HT-GF-STF includes ten such periods, with a total duration of T HT â€“ GF â€“ STF = 8 Âµs. 19.3.9.5.4 HT-greenfield format HT-SIG The content and format of the HT-SIG of an HT-greenfield format frame is identical to the HT-SIG in an HT-mixed format frame, as described in 19.3.9.4.3. The placement of the HT-SIG in an HT-greenfield format frame is shown in Figure 19-1. In HT-greenfield format frames, the HT-SIG is transmitted with the same cyclic shifts and the same spatial mapping as the preceding portions of the preamble. This use of the same cyclic shifts and spatial mapping is done to accommodate the estimation of channel parameters needed to robustly demodulate and decode the information contained in the HT-SIG. 2373 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The time domain waveform for the HT-SIG on transmit chain i TX with 20 MHz operation shall be as shown in Equation (19-29). 1 i TX 1 r HT â€“ SIG t = ----------------------------------------- w TSYM t â€“ nT SYM Tone N STS N HT â€“ SIG n=0 26 N STS (19-29) Qk i TX i STS P HT - LTF i STS 1 jD k n + p n P k k = â€“ 26 i STS = 1 i STS exp j2 k F t â€“ nT SYM â€“ T GI â€“ T CS where P k and p n are defined in 17.3.5.10 Dk n is defined in 19.3.9.4.3 i STS T CS represents the cyclic shift for space-time stream i STS and takes values from Table 19-10 Qk is defined in 19.3.11.11.2 P HT - LTF is defined in Equation (19-27) The time domain waveform for the HT-SIG on transmit chain i TX with 40 MHz operation shall be as shown in Equation (19-30). 1 i TX 1 r HT â€“ SIG t = ----------------------------------------- w TSYM t â€“ nT SYM Tone N STS N HT â€“ SIG n=0 26 N STS P HT - LTF i STS 1 jD k n + p n P k k = â€“ 26 i STS = 1 (19-30) i STS Q k â€“ 32 i TX i STS exp j2 k â€“ 32 F t â€“ nT SYM â€“ T GI â€“ T CS STS i + j Q k + 32 i TX i STS exp j2 k + 32 F t â€“ nT SYM â€“ T GI â€“ T CS where p n and P k are defined in 17.3.5.10 Dk n is defined in 19.3.9.4.3 i STS T CS represents the cyclic shift for space-time stream i STS and takes values from Table 19-10 Qk is defined in 19.3.11.11.2 P HT - LTF is defined in Equation (19-27) 2374 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 19.3.9.5.5 HT-greenfield format LTF The format of the LTF portion of the preamble in an HT-greenfield format frame is similar to that of the HT-LTF in an HT-mixed format frame, as described in 19.3.9.4.6, with the difference that the first HT-LTF (HT-LTF1) is twice as long (8 s) as the other HT-LTFs. The time domain waveform for the long training symbol on transmit chain iTX for the first HT-LTF in an HT-greenfield format frame shall be as shown in Equation (19-31). 1 i 1 r HTTXâ€“ LTF t = ------------------------------------------ w THT â€“ LTF1 t (19-31) Tone N STS N HT â€“ LTF N SR N STS iSTS Qk i TX i STS P HT - LTF i STS 1 k HT-LTF k exp j2 k F t â€“ T GI 2 â€“ T CS k = â€“ N SR i STS = 1 where i STS T CS represents the cyclic shift for space-time stream i STS and takes values from Table 19-10 Qk is defined in 19.3.11.11.2 P HT - LTF is defined in Equation (19-27) The first HT-LTF (HT-LTF1) consists of two periods of the long training symbol, preceded by a double- length (1.6 s) cyclic prefix. The placement of the first and subsequent HT-LTFs in an HT-greenfield format frame is shown in Figure 19-1. 19.3.10 Transmission of NON_HT format PPDUs with more than one transmit chain When an HT device transmits a NON_HT format PPDU with the MODULATION parameter equal to OFDM or ERP-OFDM using more than one transmit chain, it shall apply the cyclic shifts defined in Table 19-9 to the transmission in each chain. 19.3.11 Data field 19.3.11.1 General When BCC encoding is used, the Data field consists of the 16-bit SERVICE field, the PSDU, either six or twelve tail bits, depending on whether one or two encoding streams are represented, and pad bits. When LDPC encoding is used, the Data field consists of the 16-bit SERVICE field and the PSDU, processed by the procedure in 19.3.11.7.5. The number of OFDM symbols in the data field when BCC encoding is used is computed as shown in Equation (19-32). 8 length + 16 + 6 N ES N SYM = m STBC ---------------------------------------------------------- - (19-32) m STBC N DBPS 2375 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications where m STBC is 2 if STBC is used and 1 otherwise (making sure that the number of symbols is even when STBC is used) length is the value of the HT Length field in the HT-SIG field defined in Table 19-11 N DBPS takes the values defined in Table 19-27 through Table 19-41 The number of â€œzeroâ€ pad bits is thus NSYM Ã— NDBPS â€“ 8 Ã— length â€“ 16 â€“ 6 Ã— NES. The number of symbols in the data field when LDPC encoding is used is described in 19.3.11.7. For LDPC encoding, the number of encoded data bits, N avbits , is given by Equation (19-39); the number of OFDM symbols, N SYM , is given by Equation (19-41); and the number of repeated encoded bits for padding, N rep , is given by Equation (19-42), in 19.3.11.7.5. 19.3.11.2 SERVICE field The SERVICE field is used for scrambler initialization. The SERVICE field is composed of 16 bits, all set to 0 before scrambling. In non-HT PPDUs, the SERVICE field is the same as in 17.3.5.2. In HT PPDUs, the SERVICE field is composed of 16 zero bits, scrambled by the scrambler, as defined in 19.3.11.3. 19.3.11.3 Scrambler The data field shall be scrambled by the scrambler defined in 17.3.5.5. The Clause 17 TXVECTOR parameters CH_BANDWIDTH_IN_NON_HT and DYN_BANDWIDTH_IN_NON_HT shall not be present; therefore, the initial state of the scrambler shall be set to a pseudorandom nonzero seed. 19.3.11.4 Coding The Data field shall be encoded using either the BCC defined in 17.3.5.6 or the LDPC code defined in 19.3.11.7. The encoder is selected by the FEC coding field in the HT-SIG, as described in 19.3.9.4.3. A single FEC encoder is always used when LDPC coding is used. When the BCC FEC encoder is used, a single encoder is used, except that two encoders are used when the selected MCS has a PHY rate greater than 300 Mb/s (see 19.5). To determine whether to use one or two BCC FEC encoders, the rate is calculated based on the use of an 800 ns GI. The operation of the BCC FEC is described in 19.3.11.6. The operation of the LDPC coder is described in 19.3.11.7. Support for the reception of BCC-encoded Data field frames is mandatory. 19.3.11.5 Encoder parsing operation for two BCC FEC encoders If two BCC encoders are used, the scrambled data bits are divided between the encoders by sending alternating bits to different encoders. Bit with index i sent to the encoder j, denoted xi(j), is shown in Equation (19-33). j xi = b NES i+j ; 0 j N ES â€“ 1 (19-33) Following the parsing operation, 6 scrambled â€œzeroâ€ bits following the end of the message bits in each BCC input sequence are replaced by unscrambled â€œzeroâ€ bits, as described in 17.3.5.3. The replaced bits are shown in Equation (19-34). 2376 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications j length 8 + 16 length 8 + 16 xi : 0 j N ES â€“ 1 ; ------------------------------------ i ------------------------------------ + 5 (19-34) N ES N ES 19.3.11.6 Binary convolutional coding and puncturing When BCC encoding is used, the encoder parser output sequences {xi0}, and {xi1} where applicable, are each encoded by the rate 1/2 convolutional encoder defined in 17.3.5.6. After encoding, the encoded data shall be punctured by the method defined in 17.3.5.7 to achieve the rate selected by the MCS. If rate 5/6 coding is selected, the puncturing scheme is defined in Figure 19-11. Source Data X0 X1 X2 X3 X4 Encoded data A0 A1 A2 A3 A4 B0 B1 B2 B3 B4 Bit Stolen data A0 B0 A1 B2 A3 B4 A0 A1 A2 A3 A4 Bit inserted data B0 B1 B2 B3 B4 Decoded data Y0 Y1 Y2 Y3 Y4 Figure 19-11â€”Puncturing at rate 5/6 19.3.11.7 LDPC codes 19.3.11.7.1 Introduction HT LDPC codes are described in 19.3.11.7.2 through 19.3.11.7.6. These codes are optionally used in the HT system as a high-performance error correcting code instead of the convolutional code (19.3.11.6). The LDPC encoder shall use the rate-dependent parameters in Table 19-27 through Table 19-41, with the exception of the NES parameter. Support for LDPC codes is optional. 2377 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 19.3.11.7.2 LDPC coding rates and codeword block lengths The supported coding rates, information block lengths, and codeword block lengths are described in Table 19-15. Table 19-15â€”LDPC parameters Coding rate LDPC information block length LDPC codeword block length (R) (bits) (bits) 1/2 972 1944 1/2 648 1296 1/2 324 648 2/3 1296 1944 2/3 864 1296 2/3 432 648 3/4 1458 1944 3/4 972 1296 3/4 486 648 5/6 1620 1944 5/6 1080 1296 5/6 540 648 19.3.11.7.3 LDPC encoder For each of the three available codeword block lengths, the LDPC encoder supports rate 1/2, rate 2/3, rate 3/4, and rate 5/6 encoding. The LDPC encoder is systematic, i.e., it encodes an information block, c=(i0,i1,..., i(kâ€“1)), of size k, into a codeword, c, of size n, c=(i0,i1,... i(kâ€“1), p0, p1,â€¦, p(nâ€“kâ€“1)), by adding nâ€“k parity bits obtained so that HÃ—cT = 0, where H is an (nâ€“k)Ã—n parity-check matrix. The selection of the codeword block length (n) is achieved via the LDPC PPDU encoding process described in 19.3.11.7.5. 19.3.11.7.4 Parity-check matrices Each of the parity-check matrices is partitioned into square subblocks (submatrices) of size Z Ã— Z. These submatrices are either cyclic-permutations of the identity matrix or null submatrices. The cyclic-permutation matrix Pi is obtained from the Z Ã— Z identity matrix by cyclically shifting the columns to the right by i elements. The matrix P0 is the Z Ã— Z identity matrix. Figure 19-12 illustrates examples (for a subblock size of 8 Ã— 8) of cyclic-permutation matrices Pi. Table F-1 displays the â€œmatrix prototypesâ€ of parity-check matrices for all four coding rates at block length n=648 bits. The integer i denotes the cyclic-permutation matrix Pi, as illustrated in Figure 19-12. Vacant entries of the table denote null (zero) submatrices. 2378 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 00 0 0 1 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 00 0 0 0 1 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 00 0 0 0 0 1 P0 = 0 0 0 1 0 0 0 0 P = 0 0 0 0 1 1 0 0 0 P = 1 00 0 5 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 10 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 01 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 00 1 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 00 0 1 0 0 0 Figure 19-12â€”Examples of cyclic-permutation matrices with Z=8 Table F-2 displays the matrix prototypes of parity-check matrices for block length n=1296 bits, in the same fashion. Table F-3 displays the matrix prototypes of parity-check matrices for block length n=1944 bits, in the same fashion. 19.3.11.7.5 LDPC PPDU encoding process To encode an LDPC PPDU, step a) through step g) shall be performed in sequence: a) Compute the number of available bits, N avbits , in the minimum number of OFDM symbols in which the Data field of the packet may fit. N pld = length 8 + 16 (19-35) N pld N avbits = N CBPS m STBC ---------------------------------------------- (19-36) N CBPS R m STBC where mSTBC is 2 if STBC is used and 1 otherwise length is the value of the HT Length field in the HT-SIG field defined in Table 19-11 N pld is the number of bits in the PSDU and SERVICE field b) Compute the integer number of LDPC codewords to be transmitted, NCW, and the length of the codewords to be used, LLDPC from Table 19-16. Table 19-16â€”PPDU encoding parameters Range of Navbits Number of LDPC codewords LDPC codeword length LLDPC (bits) (NCW) (bits) N avbits 648 1 1296, if N avbits N pld + 912 Ã— (1-R) 648, otherwise 648 N avbits 1296 1 1944, if N avbits N pld + 1464 Ã— (1-R) 1296, otherwise 1296 N avbits 1944 1 1944 2379 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 19-16â€”PPDU encoding parameters (continued) Range of Navbits Number of LDPC codewords LDPC codeword length LLDPC (bits) (NCW) (bits) 1944 N avbits 2592 2 1944, if N avbits N pld + 2916 Ã— (1-R) 1296, otherwise 2592 < Navbits N pld 1944 ------------------- - 1944 R c) Compute the number of shortening bits, N shrt , to be padded to the Npld data bits before encoding, as shown in Equation (19-37). N shrt = max 0 N CW L LDPC R â€“ N pld (19-37) When N shrt = 0 , shortening is not performed. (Note that N shrt is inherently restricted to be non- negative due to the codeword length and count selection of 19-16). When N shrt 0 , shortening bits shall be equally distributed over all N CW codewords with the first Nshrt mod NCW codewords shortened 1 bit more than the remaining codewords. Define N spcw = N shrt N CW . Then, when N shrt 0 , the shortening is performed by setting information bits i k â€“ Nspcw â€“ 1 i k â€“ 1 to 0 in the first Nshrt mod NCW codewords and setting information bits i k â€“ N spcw i k â€“ 1 to 0 in the remaining codewords. For all values of N shrt , encode each of the N CW codewords using the LDPC encoding technique described in 19.3.11.7.2 through 19.3.11.7.4. When N shrt 0 , the shortened bits shall be discarded after encoding. d) Compute the number of bits to be punctured, N punc , from the codewords after encoding, as shown in Equation (19-38). N punc = max 0 N CW L LDPC â€“ N avbits â€“ N shrt (19-38) R If N punc 0.1 N CW L LDPC 1â€“R AND N shrt 1.2 N punc ------------ is true OR if 1â€“R N punc 0.3 N CW L LDPC 1â€“R is true, increment Navbits and recompute Npunc by the following two equations once: Navbits = Navbits + NCBPS Ã— mSTBC (19-39) N punc = max 0 N CW L LDPC â€“ N avbits â€“ N shrt (19-40) The punctured bits shall be equally distributed over all NCW codewords with the first Npunc mod NCW codewords punctured 1 bit more than the remaining codewords. Define N ppcw = N punc N CW . When N ppcw 0 , the puncturing is performed by discarding parity bits p n â€“ k â€“ N ppcw â€“ 1 p n â€“ k â€“ 1 of the first Npunc mod NCW codewords and discarding parity bits p n â€“ k â€“ Nppcw pn â€“ k â€“ 1 of the remaining codewords after encoding. The number of OFDM symbols to be transmitted in the PPDU is computed as shown in Equation (19-41). 2380 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NSYM = Navbits / NCBPS (19-41) e) Compute the number of coded bits to be repeated, N rep , as shown in Equation (19-42). N rep = max 0 N avbits â€“ N CW L LDPC 1 â€“ R â€“ N pld (19-42) The number of coded bits to be repeated shall be equally distributed over all NCW codewords with one more bit repeated for the first Nrep mod NCW codewords than for the remaining codewords. NOTEâ€”When puncturing occurs, the coded bits are not repeated, and vice versa. The coded bits to be repeated for any codeword shall be copied only from that codeword itself, starting from information bit i0 and continuing sequentially through the information bits and, when necessary, into the parity bits, until the required number of repeated bits is obtained for that codeword. Note that these repeated bits are copied from the codeword after the shortening bits have been removed. If for a codeword the required number of repeated bits are not obtained in this manner (i.e., repeating the codeword once), the procedure is repeated until the required number is achieved. These repeated bits are then concatenated to the codeword after the parity bits in their same order. This process is illustrated in Figure 19-13. In this figure, the outlined arrows indicate the encoding procedure steps, while the solid arrows indicate the direction of puncturing and padding with repeated bits. LDPC Encoding (concatenate parity) (c) Data Data Shortened Data Shortened Parity Bits Bits Bits Bits Bits Bits (Discard Shortened Bits) (Discard Punctured Bits) (d) (e) Data Parity Data Parity Data Parity Repeat Bits Bits Bits Bits Bits Bits Bits Copy Repeat Bits Figure 19-13â€”LDPC PPDU encoding padding and puncturing of a single codeword f) For each of the NCW codewords, process the data using the number of shortening bits per codeword as computed in step c) for encoding, and puncture or repeat bits per codeword as computed per step d) and step e), as illustrated in Figure 19-13. g) Aggregate all codewords and parse as defined in 19.3.11.7.6. 19.3.11.7.6 LDPC parser The succession of LDPC codewords that result from the encoding process of 19.3.11.7.5 shall be converted into a bitstream in sequential fashion. Within each codeword, bit i0 is ordered first. The parsing of this encoded data stream into spatial streams shall follow exactly the parsing rules defined for the BCC encoder, as defined in 19.3.11.8.1. However, the frequency interleaver of 19.3.11.8.3 is bypassed. 2381 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 19.3.11.8 Data interleaver 19.3.11.8.1 Overview After coding and puncturing, the data bit streams at the output of the FEC encoders are rearranged into blocks of N CBPSS i SS bits, where i SS = 1 2 N SS is the spatial stream index. This operation is referred to as stream parsing and is described in 19.3.11.8.2. If BCC encoding was used, each of these blocks is then interleaved by an interleaver that is a modification of the Clause 17 interleaver. 19.3.11.8.2 Stream parser The number of bits assigned to a single axis (real or imaginary) in a constellation point in spatial stream iSS is denoted by Equation (19-43). N BPSCS i SS s i SS = max 1 ----------------------------- (19-43) 2 N SS The sum of these over all streams is S = s i SS . i SS = 1 NOTEâ€”If equal MCS is used for all spatial streams, this sum becomes N SS s , where s is the number of bits for an axis common to all streams. Consecutive blocks of s i SS bits are assigned to different spatial streams in a round robin fashion. If two encoders are present, the output of each encoder is used alternately for each round robin cycle, i.e., at the beginning S bits from the output of first encoder are fed into all spatial streams, and then S bits from the output of second encoder are used, and so on. j Input k to spatial stream i SS shall be y i , which is output bit i of the encoder j, where j = k ------------- mod N ES (19-44) s i SS i SS â€“ 1 i = s i' + S k --------------------------- + k mod s i SS (19-45) N ES s i SS i' = 1 1 i SS N SS For i SS = 1 , the first term in Equation (19-45) has a value of 0. 19.3.11.8.3 Frequency interleaver MCS 32 interleaving shall be as defined in 17.3.5.7. Interleaving for all other MCSs is defined in this subclause. 2382 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The bits at the output of the stream parser are divided into blocks of N CBPSS i SS , i SS = 1 2 N SS bits; and if BCC encoding was used, each block shall be interleaved by an interleaver based on the Clause 17 interleaver. This interleaver, which is based on entering the data in rows and reading them out in columns, has a different number of columns and rows depending on whether a 20 MHz channel or a 40 MHz channel is used. Table 19-17 defines the interleaver parameters. If LDPC encoding was used, no frequency interleaving is performed; hence the parsed streams are immediately mapped to symbols as defined in 19.3.11.9. Table 19-17â€”Number of rows and columns in the interleaver Parameter 20 MHz 40 MHz NCOL 13 18 NROW 4 N BPSCS i SS 6 N BPSCS i SS NROT 11 29 If more than one spatial stream exists after the operations based on the Clause 17 interleaver have been applied, a third operation called frequency rotation shall be applied to the additional spatial streams. The parameter for the frequency rotation is NROT. The interleaving is defined using three permutations. The first permutation is defined by the rule shown in Equation (19-46). i = N ROW k mod N COL + k N COL , k = 0 1 N CBPSS i SS â€“ 1 (19-46) The second permutation is defined by the rule shown in Equation (19-47). j = s i SS i s i SS + i + N CBPSS i SS â€“ N COL i N CBPSS i SS mod s i SS ; (19-47) i = 0 1 N CBPSS i SS â€“ 1 The value of s i SS is determined by the number of coded bits per subcarrier as shown in Equation (19-48). s i SS = max N BPSCS i SS 2 1 (19-48) If more than one spatial stream exists, a frequency rotation is applied to the output of the second permutation as shown in Equation (19-49). i SS â€“ 1 r = jâ€“ i SS â€“ 1 2 mod 3 + 3 -------------- - N ROT N BPSCS i SS mod N CBPSS i SS ; (19-49) 3 j = 0 1 N CBPSS i SS â€“ 1 where i SS = 1 2 N SS is the index of the spatial stream on which this interleaver is operating The deinterleaver uses the following operations to perform the inverse rotation. The index of the bit in the received block (per spatial stream) is denoted by r. The first permutation reverses the third (frequency rotation) permutation of the interleaver as shown in Equation (19-50). 2383 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications i SS â€“ 1 j = r+ i SS â€“ 1 2 mod 3 + 3 -------------- - N ROT N BPSCS i SS mod N CBPSS i SS ; (19-50) 3 r = 0 1 N CBPSS i SS â€“ 1 The second permutation reverses the second permutation in the interleaver as shown in Equation (19-51). i = s i SS j s i SS + j + N COL j N CBPSS i SS mod s i SS ; (19-51) j = 0 1 N CBPSS i SS â€“ 1 where s i SS is defined in Equation (19-48). The third permutation reverses the first permutation of the interleaver as shown in Equation (19-52). k = N COL i â€“ N CBPSS i SS â€“ 1 i N ROW i = 0 1 N CBPSS i SS â€“ 1 (19-52) 19.3.11.9 Constellation mapping 19.3.11.9.1 General The mapping between bits at the output of the interleaver and complex constellation points for BPSK, QPSK, 16-QAM, and 64-QAM follows the rules defined in 17.3.5.8. The streams of complex numbers are denoted as shown in Equation (19-53). dk l n 0 k N SD â€“ 1 ;1 l N SS ;0 n N SYM â€“ 1 (19-53) 19.3.11.9.2 Space-time block coding (STBC) This subclause defines a set of optional robust transmission formats that are applicable only when N STS is greater than N SS . In this case, N SS spatial streams are mapped to N STS space-time streams, which are mapped to N TX transmit chains. These formats are based on STBC. When the use of STBC is indicated in the STBC field of the HT-SIG, a symbol operation shall occur between the constellation mapper and the spatial mapper (see Figure 19-3) as defined in this subclause. If STBC is applied, the stream of complex numbers, d k i n ;k = 0 N SD â€“ 1 ;i = 1 N SS ;n = 0 N SYM â€“ 1 , generated by the constellation mapper, is the input of the STBC encoder, which produces as output the stream of complex numbers dÌƒ k i n ;k = 0 N SD â€“ 1 ;i = 1 N STS ;n = 0 N SYM â€“ 1 . For given values of k and i, STBC processing operates on the complex modulation symbols in sequential pairs of OFDM symbols so that the value of dÌƒ k i 2m depends on d k i 2m and d k i 2m + 1 , and dÌƒ k i 2m + 1 also depends on d k i 2m and dk i 2m + 1 , as defined in Table 19-18. If STBC is not applied, dÌƒ k i n = dk i n and N SS = N STS . NOTE 1â€”The specific STBC schemes for single spatial streams ( N SS = 1 ) with N TX 3 are not detailed in this subclause since they are covered through the use of spatial expansion as detailed in 19.3.11.11.2. NOTE 2â€”STBC is applied only for the HT-SIG MCS field values specified in Table 19-18 and is not used with MCS 32. 2384 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 19-18â€”Constellation mapper output to spatial mapper input for STBC HT-SIG HT-SIG MCS STBC field NSTS field (bits 0â€“6 NSS iSTS dÌƒ k i 2m dÌƒ k i 2m + 1 (bits 4â€“5 in in HT-SIG1) HT-SIG2) 1 dk dk 1 2m 1 2m + 1 2 0â€“7 1 1 2 * * â€“dk 1 2m + 1 dk 1 2m 1 dk dk 1 2m 1 2m + 1 2 * * 3 8â€“15, 33â€“38 2 1 â€“dk 1 2m + 1 dk 1 2m 3 dk dk 2 2m 2 2m + 1 1 dk dk 1 2m 1 2m + 1 2 * * â€“dk 1 2m + 1 dk 1 2m 4 8â€“15 2 2 3 dk dk 2 2m 2 2m + 1 4 * * â€“dk 2 2m + 1 dk 2 2m 1 dk dk 1 2m 1 2m + 1 2 * * â€“dk 1 2m + 1 dk 1 2m 16â€“23, 39, 41, 4 3 1 43, 46, 48, 50 3 dk dk 2 2m 2 2m + 1 4 dk dk 3 2m 3 2m + 1 NOTEâ€”The â€˜*â€™ operator represents the complex conjugate. 19.3.11.10 Pilot subcarriers In a 20 MHz transmission four pilot tones shall be inserted in the same subcarriers used in Clause 17, i.e., in subcarriers â€“21, â€“7, 7, and 21. The pilot sequence for the nth symbols and iSTSth space-time stream shall be as shown in Equation (19-54). -28,28 N STS N STS i STS n = 0 0 0 0 0 0 0 i STS n mod 4 0 0 0 0 0 0 0 0 0 0 0 0 0 i STS n + 1 mod 4 0 0 0 0 0 0 0 (19-54) N STS N STS 0 0 0 0 0 0 i STS n + 2 mod 4 0 0 0 0 0 0 0 0 0 0 0 0 0 i STS n + 3 mod 4 0 0 0 0 0 0 0 In a 40 MHz transmission (excluding MCS 32; see 19.3.11.11.5), pilot signals shall be inserted in subcarriers â€“53, â€“25, â€“11, 11, 25, and 53. The pilot sequence for symbol n and space-time stream iSTS shall be as shown in Equation (19-55). 2385 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications -58,58 N STS P i STS n = 0 0 0 0 0 i STS n mod 6 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 N STS N STS 0 0 i STS n + 1 mod 6 0 0 0 0 0 0 0 0 0 0 0 0 0 i STS n + 2 mod 6 0 0 0 0 0 0 0 0 0 N STS N STS (19-55) 0 0 0 0 0 0 0 0 0 0 0 0 i STS n + 3 mod 6 0 0 0 0 0 0 0 0 0 0 0 0 0 i STS n + 4 mod 6 N STS 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 i STS n + 5 mod 6 0 0 0 0 0 N STS where the patterns i STS n are defined in Table 19-19 and Table 19-20. NOTEâ€”For each space-time stream, there is a different pilot pattern, and the pilot patterns are cyclically rotated over symbols. The basic patterns are also different according to the total number of space-time streams for the packet. Table 19-19â€”Pilot values for 20 MHz transmission N STS N STS N STS N STS NSTS iSTS i STS 0 i STS 1 i STS 2 i STS 3 1 1 1 1 1 â€“1 2 1 1 1 â€“1 â€“1 2 2 1 â€“1 â€“1 1 3 1 1 1 â€“1 â€“1 3 2 1 â€“1 1 â€“1 3 3 â€“1 1 1 â€“1 4 1 1 1 1 â€“1 4 2 1 1 â€“1 1 4 3 1 â€“1 1 1 4 4 â€“1 1 1 1 Table 19-20â€”Pilots values for 40 MHz transmission (excluding MCS 32) N STS N STS N STS N STS N STS N STS NSTS iSTS i STS 0 i STS 1 i STS 2 i STS 3 i STS 4 i STS 5 1 1 1 1 1 â€“1 â€“1 1 2 1 1 1 â€“1 â€“1 â€“1 â€“1 2 2 1 1 1 â€“1 1 1 3 1 1 1 â€“1 â€“1 â€“1 â€“1 3 2 1 1 1 â€“1 1 1 3 3 1 â€“1 1 â€“1 â€“1 1 2386 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 19-20â€”Pilots values for 40 MHz transmission (excluding MCS 32) (continued) N STS N STS N STS N STS N STS N STS NSTS iSTS i STS 0 i STS 1 i STS 2 i STS 3 i STS 4 i STS 5 4 1 1 1 â€“1 â€“1 â€“1 â€“1 4 2 1 1 1 â€“1 1 1 4 3 1 â€“1 1 â€“1 â€“1 1 4 4 â€“1 1 1 1 â€“1 1 19.3.11.11 OFDM modulation 19.3.11.11.1 General The time domain signal is composed from the stream of complex numbers as shown in Equation (19-56) dÌƒ k l n 0 k N SD â€“ 1 ;1 l N STS ;0 n N SYM â€“ 1 (19-56) and from the pilot signals. In a 40 MHz transmission, the upper subcarriers are rotated 90Â° relative to the lower subcarriers. 19.3.11.11.2 Spatial mapping The transmitter may choose to rotate and/or scale the constellation mapper output vector (or the space-time block coder output, if applicable). This rotation and/or scaling is useful in the following cases: â€” When there are more transmit chains than space-time streams, N STS N TX â€” As part of (an optional) sounding packet â€” As part of (an optional) calibration procedure â€” When the packet is transmitted using one of the (optional) beamforming techniques i If the data to be transmitted on subcarrier k on space-time stream i STS are X k STS , the transmitted data on the transmit chain i TX shall be as shown in Equation (19-57). N SR N STS i TX 1 i STS i r Field = ----------------------------------- w TField t Qk i TX i STS X k exp j2 k F STS t â€“ T CS (19-57) Tone N STS N Field k = â€“ N SR i STS = 1 where Qk i TX i STS is the element in row i TX and column i STS in a matrix Q k with N TX rows and N STS columns; Q k may be frequency dependent Field is any field, as defined in 19.3.7, excluding L-STF, L-LTF, L-SIG, and HT-SIG in HT_MF format PPDU Below are examples of spatial mapping matrices that might be used. There exist many other alternatives; implementation is not restricted to the spatial mapping matrices shown. The examples are: 2387 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications a) Direct mapping: Q k is a diagonal matrix of unit magnitude complex values that takes one of two forms: 1) Q k = I , the identity matrix 2) A CSD matrix in which the diagonal elements represent cyclic shifts in the time domain: i i Qk i i = exp â€“ j2 k F CS , where CS i = 1 N TX represents the CSD applied. b) Indirect mapping: Q k may be the product of a CSD matrix and a unitary matrix such as the Hadamard matrix or the Fourier matrix. c) Spatial expansion: Q k is the product of a CSD matrix and a square matrix formed of orthogonal columns. As an illustration: 1) The spatial expansion may be performed by duplicating some of the N STS streams to form the N TX streams, with each stream being scaled by the normalization factor N STS N TX . The spatial expansion may be performed by using, for instance, one of the following matrices, denoted D, left-multiplied by a CSD matrix, denoted M CSD k , and/or possibly multiplied by any unitary matrix. The resulting spatial mapping matrix is then Q k = M CSD k D , where D may take on one of the following values: 1 T i) NTX=2, NSTS=1, D = ------- 1 1 2 1 T ii) NTX=3, NSTS=1, D = ------- 1 1 1 3 1 T iii) NTX=4, NSTS=1, D = --- 1 1 1 1 2 1 0 iv) NTX=3, NSTS=2, D = 2 --- 0 1 3 1 0 1 0 1 0 1 v) NTX=4, NSTS=2, D = ------- 2 1 0 0 1 1 0 0 3 vi) NTX=4, NSTS=3, D = ------- 0 1 0 2 0 0 1 1 0 0 2) Different spatial expansion over subcarriers should be used in HT-mixed format only and with the smoothing bit equal to 0: T T i) NTX=2, NSTS=1, Q k N STS = 1 0 or Qk N STS = 0 1 1 0 1 0 0 0 ii) NTX=3, NSTS=2, Q k N STS = 0 0 0 1 or 1 0 0 1 0 0 0 1 2388 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 1 0 1 0 0 0 0 0 iii) NTX=4, NSTS=2, Q k N STS = 0 0 0 0 1 0 or 1 0 0 0 0 1 0 0 0 1 0 1 0 0 0 1 0 0 1 0 0 1 0 0 iv) NTX=4, NSTS=3, Q k N STS = 0 1 0 or 0 0 0 0 0 0 0 1 0 0 0 1 0 0 1 d) Beamforming steering matrix: Q k is any matrix that improves the reception in the receiver based on some knowledge of the channel between the transmitter and the receiver. With transmit beamforming with explicit feedback, the steering matrix Q k is determined using either H eff for CSI feedback or V k for noncompressed and compressed matrices feedback from the STA to which the beamformed packet is addressed. When there are fewer space-time streams than transmit chains, the first N STS columns of the matrices above that are square might be used. The same matrix Q k shall be applied to subcarrier k during all parts of the packet in HT-greenfield format and all parts of the packet following and including the HT-STF field in an HT-mixed format packet. This operation is transparent to the receiver. If at least 95% of the sum of the energy from all impulse responses of the time domain channels between all space-time streams and all transmit chain inputs, induced by the CSD added according to Table 19-10 and the frequency-dependence in the matrix Q k , is contained within 800 ns, the smoothing bit should be set to 1. Otherwise, it shall be set to 0. The CSD of Table 19-10 shall be applied at the input of the spatial mapper. For the identity matrix direct mapping, the smoothing bit should be set to 1. If no spatial mapping is applied, the matrix Q k is equal to the identity matrix and N STS = N TX . Sounding PPDUs using spatial expansion shall use an orthonormal column matrix Q k . When the number of rows and columns is equal, the orthonormal column matrix becomes a unitary matrix. 19.3.11.11.3 Transmission in 20 MHz HT format For 20 MHz HT transmissions, the signal from transmit chain i TX 1 i TX N TX shall be as shown in Equation (19-58). 2389 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications N SYM â€“ 1 i TX 1 r HT â€“ DATA t = --------------------------------------------- w TSYM t â€“ nT SYM Tone N STS N HT â€“ DATA n=0 N SR N STS k (19-58) Qk i TX i STS DÌƒ k i STS n + pn + z P i STS n k = â€“ N SR i STS = 1 i STS exp j2 k F t â€“ nT SYM â€“ T GI â€“ T CS where z is 3 in an HT-mixed format packet and 2 in an HT-greenfield format packet pn is defined in 17.3.5.10 0 k=0 7 21 DÌƒ k i STS n = dÌƒ Mr k i STS n otherwise k + 28 â€“ 28 k â€“ 22 k + 27 â€“ 20 k â€“ 8 M k = r k + 26 â€“6 k â€“1 k + 25 1 k 6 k + 24 8 k 20 k + 23 22 k 28 k P i STS n is defined in Equation (19-54) 19.3.11.11.4 Transmission in 40 MHz HT format For 40 MHz HT transmissions, the signal from transmit chain i TX shall be as shown in Equation (19-59). N SYM â€“ 1 i TX 1 r HT â€“ DATA t = --------------------------------------------- w TSYM t â€“ nT SYM Tone N STS N HT â€“ DATA n=0 N SR N STS k (19-59) Qk i TX i STS DÌƒ k i STS n + pn + z P i STS n k k = â€“ N SR i STS = 1 i STS exp j2 k F t â€“ nT SYM â€“ T GI â€“ T CS where z is 3 in an HT-mixed format packet and 2 in an HT-greenfield format packet pn is defined in 17.3.5.10 2390 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 0 k=0 1 11 25 53 DÌƒ k i STS n = dÌƒ Mr k i STS n otherwise k + 58 â€“ 58 k â€“ 54 k + 57 â€“ 52 k â€“ 26 k + 56 â€“ 24 k â€“ 12 r M k = k + 55 â€“ 10 k â€“ 2 k + 52 2 k 10 k + 51 12 k 24 k + 50 26 k 52 k + 49 54 k 58 k P i STS n is defined in Equation (19-55) NOTEâ€”The 90Â° rotation that is applied to the upper part of the 40 MHz channel is applied in the same way to the HT-STF, HT-LTF, and HT-SIG. The rotation applies to both pilots and the data in the upper part of the 40 MHz channel. 19.3.11.11.5 Transmission in MCS 32 format MCS 32 format provides the lowest transmission rate in 40 MHz. It is used only for one spatial stream and only with BPSK modulation and rate 1/2 coding. In the MCS 32 format, the signal shall be as shown in Equation (19-60). N SYM â€“ 1 i TX 1 r HT â€“ DATA t = ----------------------------------- w TSYM t â€“ nT SYM (19-60) Tone N HT â€“D uplicate n=0 N SR Dk n + pn + z Pk Q k â€“ 32 i TX 1 exp j2 k â€“ 32 F t â€“ nT SYM â€“ T GI k = â€“ N SR + j Q k + 32 i TX 1 exp j2 k + 32 F t â€“ nT SYM â€“ T GI where z is defined in 19.3.11.11.3 P k and p n are defined in 17.3.5.10 Dk n is defined in 19.3.9.4.3 N SR has the value defined for non-HT 20 MHz transmission Qk i TX 1 is an element from a vector of length N TX , which may be frequency dependent Tone N HT â€“ Duplicate is defined in Table 19-8 The rules of spatial expansion CSD limitation, as specified in 19.3.11.11.2, shall apply to Q k i TX 1 . 2391 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 19.3.11.11.6 Transmission with a short GI Short GI is used in the data field of the packet when the Short GI field in the HT-SIG is equal to 1. When it is used, the same formula for the formation of the signal shall be used as in 19.3.11.11.3, 19.3.11.11.4, and 19.3.11.11.5, with T GI replaced by T GIS and T SYM replaced by T SYMS . NOTEâ€”Short GI is not used in HT-greenfield format with one spatial stream, in which case the HT-SIG is immediately followed by data. It is very difficult to parse the HT-SIG in time to demodulate these data with the correct GI length if the GI length is not known in advance. 19.3.11.12 Non-HT duplicate transmission Non-HT duplicate transmission is used to transmit to Clause 17 STAs, Clause 18 STAs, and Clause 19 STAs that may be present in either the upper or lower halves of the 40 MHz channel. The L-STF, L-LTF, and L-SIG shall be transmitted in the same way as in the HT 40 MHz transmission. The HT-SIG, HT-STF, and HT-LTF are not transmitted. Data transmission shall be as defined in Equation (19-61). N SYM â€“ 1 i TX 1 r LEG â€“ DUP t = --------------------------------------- w TSYM t â€“ nT SYM (19-61) Tone N Non-HT Duplicate n=0 26 iTX D k n + p n + 1 P k exp j2 k â€“ 32 F t â€“ nT SYM â€“ T GI â€“ T CS k = â€“ 26 iTX + j exp j2 k + 32 F t â€“ nT SYM â€“ T GI â€“ T CS where P k and p n are defined in 17.3.5.10 Dk n is defined in 19.3.9.4.3 iTX T CS represents the cyclic shift of the transmit chain i TX and is defined in Table 19-9 Tone N Non-HT Duplicate is defined in Table 19-8 19.3.12 Beamforming 19.3.12.1 General Beamforming is a technique in which the beamformer utilizes the knowledge of the MIMO channel to generate a steering matrix Q k that improves reception in the beamformee. The equivalent complex baseband MIMO channel model is one in which, when a vector T T xk = x1 x2 x NTX is transmitted in subcarrier k, the received vector y k = y 1 y 2 y NRX is modeled as shown in Equation (19-62). yk = Hk xk + n (19-62) 2392 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications where Hk is channel matrix of dimensions N RX N TX n is white (spatially and temporally) Gaussian noise as illustrated in Figure 19-14 HAB STA A STA B HBA BTX , BRX ATX , ARX Figure 19-14â€”Beamforming MIMO channel model (3x2 example) When beamforming is used, the beamformer replaces x k , which in this case has N STS N TX elements, with Q k x k , where Q k has N TX rows and N STS columns, so that the received vector is as shown in Equation (19-63). yk = Hk Qk xk + n (19-63) The beamforming steering matrix that is computed (or updated) from a new channel measurement replaces the existing Q k for the next beamformed data transmission. There are several methods of beamforming, differing in the way the beamformer acquires the knowledge of the channel matrices H k and on whether the beamformer generates Q k or the beamformee provides feedback information for the beamformer to generate Q k . 19.3.12.2 Implicit feedback beamforming Implicit feedback beamforming is a technique that relies on reciprocity in the time division duplex channel to estimate the channel over which a device is transmitting based on the MIMO reference that is received from the device to which it plans to transmit. This technique allows the transmitting device to calculate a set of transmit steering matrices, Q k , one for each subcarrier, which are intended to optimize the performance of the link. Referring to Figure 19-14, beamforming transmissions from STA A to STA B using implicit techniques are enabled when STA B sends STA A a sounding PPDU, the reception of which allows STA A to form an estimate of the MIMO channel from STA B to STA A, for all subcarriers. In a TDD channel in which the forward and reverse channels are reciprocal, the channel from STA A to STA B in subcarrier k is the matrix transpose of the channel from STA B to STA A in subcarrier k to within a complex scaling factor, i.e., T H AB k = H BA k . Here H AB k is the MIMO channel matrix from STA A to STA B at subcarrier k , and 2393 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications H BA k is the channel matrix from STA B to STA A at subcarrier k . STA A uses this relationship to compute transmit steering matrices that are suitable for transmitting to STA B over H AB k . NOTEâ€”In order for the recipient of the sounding to compute steering matrices when steered or unsteered sounding is used, the steering matrices need to have the property H k Q k H k Q k H = H k H Hk , where X H indicates the conjugate transpose of the matrix X . While the over-the-air channel between the antenna(s) at one STA and the antenna(s) at a second STA is reciprocal, the observed baseband-to-baseband channel used for communication might not be, as it includes the transmit and receive chains of the STAs. Differences in the amplitude and phase characteristics of the transmit and receive chains associated with individual antennas degrade the reciprocity of the over-the- air channel and cause degradation of performance of implicit beamforming techniques. The over-the-air calibration procedure described in 10.32.2.4 may be used to restore reciprocity. The procedure provides the means for calculating a set of correction matrices that can be applied at the transmit side of a STA to correct the amplitude and phase differences between the transmit and receive chains in the STA. If this correction is done at least at the STA that serves as the beamformer, there is sufficient reciprocity for implicit feedback in the baseband-to-baseband response of the forward link and reverse channel. Figure 19-15 illustrates the observed baseband-to-baseband channel, including reciprocity correction. Spatial mapping matrices Q A k and Q B k are assumed to be identity matrices here for simplicity of illustration. H AB KA ATX HAB BRX STA A STA B ARX HBA BTX KB H BA Figure 19-15â€”Baseband-to-baseband channel NOTEâ€”Spatial mapping matrix for sounding PPDUs are specified in 19.3.13.3. The amplitude and phase responses of the transmit and receive chains can be expressed as diagonal matrices with complex valued diagonal entries, of the form A TX k and A RX k at STA A. The relationship between the baseband-to-baseband channel, HÌƒ AB k , and the over-the-air channel, H AB k , is shown in Equation (19-64). HÌƒ AB k = B RX k H AB k A TX k (19-64) Similarly, the relationship between HÌƒ BA k and H BA k is shown in Equation (19-65). 2394 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications HÌƒ BA k = A RX k H BA k B TX k (19-65) As an example, consider the case where calibration is performed at both STA A and STA B. The objective is to compute correction matrices, K A k and K B k , that restore reciprocity so that Equation (19-66) is true. T HÌƒ AB k K A k = HÌƒ BA k K B k (19-66) The correction matrices are diagonal matrices with complex valued diagonal entries. The reciprocity condition in Equation (19-66) is enforced when Equation (19-67) and Equation (19-68) are true. â€“1 KA k = A k A TX k A RX k (19-67) and â€“1 KB k = B k B TX k B RX k (19-68) where A k and B k are complex valued scaling factors. Using these expressions for the correction matrices, the calibrated baseband-to-baseband channel between STA A and STA B is expressed as shown in Equation (19-69). HÌ‚ AB k = HÌƒ AB k K A k = A k B RX k H AB k A RX k (19-69) If both sides apply the correction matrices, the calibrated baseband-to-baseband channel between STA A and STA B is expressed as shown in Equation (19-70). B k T HÌ‚ BA k = B k A RX k H BA k B RX k = ---------- - HÌ‚ AB k (19-70) A k Focusing on STA A, the procedure for estimating K A k is as follows: a) STA A sends STA B a sounding PPDU, the reception of which allows STA B to estimate the channel matrices HÌƒ AB k . b) STA B sends STA A a sounding PPDU, the reception of which allows STA A to estimate the channel matrices HÌƒ BA k . c) STA B sends the quantized estimates of HÌƒ AB k to STA A. d) STA A uses its local estimates of HÌƒ BA k and the quantized estimates of HÌƒ AB k received from STA B to compute the correction matrices K A k . NOTEâ€”When a nonidentity matrix is used for Q A k , STA A is responsible for accounting for the spatial mapping in its local channel estimate as well as in the quantized CSI fed back since the channel feedback received in step c) is actually HÌƒ AB k Q A k and not HÌƒ AB k . Furthermore, since Q B k is defined in 19.3.13.3, additional steps might be taken in STA A to remove the effect of Q B k when computing the correction matrix K A k . Steps a) and b) occur over a short time interval to so the channel changes as little as possible between measurements. A similar procedure is used to estimate K B k at STA B. The details of the computation of the correction matrices is implementation specific and beyond the scope of this standard. 2395 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 19.3.12.3 Explicit feedback beamforming 19.3.12.3.1 General In explicit beamforming, in order for STA A to transmit a beamformed packet to STA B, STA B measures the channel matrices and sends STA A either the effective channel, H eff k , or the beamforming feedback matrix, V k , for STA A to determine a steering matrix, Q steer, k = Q k V k , with V k found from H k Q k , where Q k is the orthonormal spatial mapping matrix that was used to transmit the sounding packet that elicited the V k feedback. The effective channel, H eff k = H k Q k , is the product of the spatial mapping matrix used on transmit with the channel matrix. When new steering matrix Q steer k is found, Q steer k may replace Q k for the next beamformed data transmission. NOTEâ€” Q steer k is a mathematical term to update a new steering matrix for Q k in the next beamformed data transmission. 19.3.12.3.2 CSI matrices feedback In CSI matrices feedback, the beamformer receives the quantized MIMO channel matrix, H eff , from the beamformee. The beamformer then may use this matrix to compute a set of transmit steering matrices, Q k . The CSI matrix, H eff , shall be determined from the transmitter spatial mapper input to the receiver FFT outputs. The beamformee shall remove the CSD in Table 19-10 from the measured channel matrix. The matrices H eff k , where k is the subcarrier index, are encoded so that applying the procedure in 19.3.12.3.3 optimally reconstructs the matrix. 19.3.12.3.3 CSI matrices feedback decoding procedure q The received, quantized matrix H eff k (of a specific subcarrier, k ) shall be decoded as follows: q R q I a) The real and imaginary parts of each element of the matrix, H eff m l k and H eff m l k , are decoded as a pair of 2s complement numbers to create the complex element, where 1 m N r and 1 l Nc . b) Each element in the matrix of subcarrier k is then scaled using the value in the carrier matrix amplitude field (3 bits), M H k , interpreted as a positive integer, in decibels, as follows: 1) Calculate the linear value as defined in Equation (19-71). 2) Calculate decoded values of the real and imaginary parts of the matrix element as defined in Equation (19-72) and Equation (19-73). MH k 20 r k = 10 (19-71) q R H eff m l k Re HÌƒ eff m l k = -------------------------- - (19-72) r k q I H eff m l k Im HÌƒ eff m l k = -------------------------- - (19-73) r k 2396 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 19.3.12.3.4 Example of CSI matrices feedback encoding The following is an example of an encoding process: a) The maximums of the real and imaginary parts of each element of the matrix in each subcarrier are found, as defined by Equation (19-74). m = Nr l = Nc m = Nr l = Nc m H k = max max Re H eff m l k m=1 l=1 max Im H eff m l k m=1 l=1 (19-74) b) The scaling ratio is calculated and quantized to 3 bits as defined by Equation (19-75). A linear scaler is given by Equation (19-76). z = N SR max m H z z = â€“N M H k = min 7 20log 10 ----------------------------------------------- - SR (19-75) mH k where z=N lin max m H z z = â€“NSR MH k = ----------------------------------------------- - SR (19-76) M H k 20 10 c) The real and imaginary parts of each element in the matrix H eff m l k are quantized to N b bits in 2s complement encoding as defined by Equation (19-77) and Equation (19-78). q R Re H eff m l k N â€“1 H eff m l k = ---------------------------------------- lin 2 b â€“ 1 + 0.5 (19-77) MH k q I Im H eff m l k N â€“1 H eff m l k = ---------------------------------------- lin 2 b â€“ 1 + 0.5 (19-78) MH k Each matrix is encoded using 3 + 2 Nb Nr N c bits, where N r and N c are the number of rows and columns, respectively, in the channel matrix estimate computed by the receiving station and where N b may have the value of 4, 5, 6, or 8 bits. 19.3.12.3.5 Noncompressed beamforming feedback matrix In noncompressed beamforming feedback matrix, the beamformee shall remove the space-time stream CSD in Table 19-10 from the measured channel before computing a set of matrices for feedback to the beamformer. The beamforming feedback matrices, V k , found by the beamformee are sent to the beamformer in the order of real and imaginary components per tone as specified in 9.4.1.29. The beamformer might use these matrices to determine the steering matrices, Q k . The beamformee shall encode the matrices V k so a beamformer applying the procedure below optimally reconstructs the matrix. q The received matrix V k (of a specific subcarrier k ) shall be decoded as follows: 2397 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications q R q I a) The real and imaginary parts of each element of the matrix, V m l and V m l , shall be decoded as a pair of 2s complement numbers to create the complex element, where 1 m N r and 1 l Nc . b) The dimensions of the beamforming feedback matrices are N r N c , where N r and N c are the number of rows and columns, respectively, in the beamforming feedback matrix computed by the receiving station. Each matrix is encoded using 2 N b N r N c bits. N b may have the value of 2, 4, 6, or 8 bits. c) Columns 1 N c of the beamforming feedback matrix correspond to spatial streams 1 Nc , respectively. The mapping of spatial stream to modulation is defined in the MCS tables in 19.5. A transmitter shall not reorder the columns of the beamforming feedback matrices. 19.3.12.3.6 Compressed beamforming feedback matrix In compressed beamforming feedback matrix, the beamformee shall remove the space-time stream CSD in Table 19-10 from the measured channel before computing a set of matrices for feedback to the beamformer. The beamforming feedback matrices, V k , found by the beamformee are compressed in the form of angles, which are sent to the beamformer. The beamformer might use these angles to decompress the matrices and determine the steering matrices Q k . The matrix V per tone shall be compressed as follows: The N r N c beamforming feedback orthonormal column matrix V found by the beamformee shall be represented as shown in Equation (19-79). When the number of rows and columns is equal, the orthonormal column matrix becomes a unitary matrix. min(N c N r â€“ 1) Nr j j N â€“1 i i i r T V = Di 1i â€“ 1 e e 1 G li li IÌƒ Nr Nc (19-79) i=1 l = i+1 j j N â€“1 i i i r The matrix D i 1 i â€“ 1 e e 1 is an N r N r diagonal matrix, where 1 i â€“ 1 represents a sequence of 1s with length of iâ€“1, as shown in Equation (19-80). Ii â€“ 1 0 0 j i i j 0 e 0 0 j i i Nr â€“ 1 i D 1i â€“ 1 e e 1 = 0 0 0 (19-80) j N â€“1 i 0 e r 0 0 0 0 0 1 The matrix G li is an N r N r Givens rotation matrix as shown in Equation (19-81). Ii â€“ 1 0 0 0 0 0 cos 0 sin 0 G li = 0 0 Il â€“ i â€“ 1 0 0 (19-81) 0 â€“ sin 0 cos 0 0 0 0 0 I Nr â€“ l 2398 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications where each I m is an m m identity matrix, and cos and sin are located at row l and column i. IÌƒ Nr Nc is an identity matrix padded with 0s to fill the additional rows or columns when N r Nc . For example, a 4Ã—2 V matrix has the representation shown in Equation (19-82). j T T T e 11 0 0 0 cos 21 sin 21 0 0 cos 0 sin 0 cos 0 0 sin 31 31 41 41 0 e j 21 0 0 â€“ sin 21 cos 21 0 0 0 1 0 0 0 1 0 0 V = j 31 0 0 1 0 â€“ sin 31 0 cos 31 0 0 0 1 0 0 0 e 0 0 0 0 1 0 0 0 1 â€“ sin 41 0 0 cos 41 0 0 0 1 (19-82) T T 1 0 0 0 1 0 0 0 1 0 0 0 1 0 j 0 e 22 0 0 0 cos 32 sin 32 0 0 cos 42 0 sin 42 0 1 0 0 e 0 j 32 0 â€“ sin 32 cos 32 0 0 0 1 0 0 0 0 0 0 1 0 0 0 1 0 â€“ sin 42 0 cos 42 0 0 The procedure for finding a compressed V matrix is described as follows: A Nr N c beamforming feedback orthonormal column matrix V is column-wise phase invariant because the steering matrix needs a reference in phase per each column. When the number of rows and columns is equal, the orthonormal column matrix becomes a unitary matrix. In other words, V is equivalent to VÌƒDÌƒ , j j j Nc 1 2 where DÌƒ is a column-wise phase shift matrix such as DÌƒ = diag e e e . When the beamformee estimates the channel, it may find VÌƒ for the beamforming feedback matrix for the beamformer, but it should send VÌƒDÌƒ back to the beamformer, where V = VÌƒDÌƒ . The angle, i, in DÌƒ is found to make the last row of VÌƒDÌƒ to be non-negative real numbers. j j N â€“1 1 * 11 r The angles 1 1 Nr â€“ 1 1 in the diagonal matrix D 1 e e 1 shall satisfy the * constraint that all elements in the first column of D 1 V are non-negative real numbers. Now, the first * T column of G Nr 1 G 31 G 21 D 1 V can be 1 0 0 by the Givens rotations G l 1 such as shown in Equation (19-83). * j cos Nr 1 0 0 sin Nr 1 cos 31 0 sin 31 0 cos 21 sin 21 0 0 e 11 0 0 0 1 0 0 0 0 1 0 0 0 1 0 0 â€“ sin cos 0 0 0 0 0 0 21 21 V = (19-83) 0 0 1 0 â€“ sin 31 0 cos 31 0 0 0 1 0 j Nr â€“ 1 1 0 V2 0 0 e 0 â€“ sin Nr 1 0 0 cos N r 1 0 0 0 1 0 0 0 1 0 0 0 0 1 For a new N r â€“ 1 N c â€“ 1 submatrix V 2 , this process is applied in the same way. Then, the angles j j N â€“1 2 * 22 r 2 2 Nr â€“ 1 2 in the diagonal matrix D 2 1 e e 1 shall satisfy the constraint that all 2399 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications * elements in the second column of D 2 diag(1,V 2 are non-negative real numbers. Now, the first two * * columns of G Nr 2 G 32 D 2 G Nr 1 G 31 G 21 D 1 V can be IÌƒ Nr 2 by the Givens rotations G l 2 such as shown in Equation (19-84). * 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 j 0 cos Nr 2 0 sin N r 2 0 cos 32 sin 32 0 0 e 22 0 0 * 0 1 0 0 GN 1 G 31 G 21 D 1 V = (19-84) 0 0 1 0 0 â€“ sin cos 0 j N â€“1 2 0 0 32 32 0 0 e r 0 V3 0 â€“ sin Nr 2 0 cos N r 2 0 0 0 1 0 0 0 0 0 1 This process continues until the first N c columns of the right side matrix become IÌƒ Nr Nc . When N c Nr , this process does not need to continue because V Nc + 1 is nulled out by IÌƒ Nr Nc . Then, by multiplying the complex conjugate transpose of the products of the D i and G li matrices on the left, V can be expressed as shown in Equation (19-85). T T T T T T T T T V = D 1 G 21 G 31 G Nr 1 D 2 G 32 G 42 G Nr 2 Dp Gp + 1 p Gp + 2 p G Nr p IÌƒ Nr NC (19-85) where p = min N c N r â€“ 1 , which can be written in short form as in Equation (19-79). The angles found from the decomposition process above, e.g., the values of i j and k l, are quantized as described in 9.6.12.8. Columns 1 N c of the beamforming feedback matrix correspond to spatial streams 1 N c , respectively. The mapping of spatial stream to modulation is defined in the MCS tables in 19.5. A transmitter shall not reorder the columns of the beamforming feedback matrices in determining steering matrices. 19.3.13 HT Preamble format for sounding PPDUs 19.3.13.1 General The MIMO channel measurement takes place in every PPDU as a result of transmitting the HT-LTFs as part of the PHY preamble. The number of HT-LTFs transmitted shall be determined by the number of space-time streams transmitted unless additional dimensions are optionally sounded using HT-ELTFs and these are transmitted using the same spatial transformation that is used for the Data field of the HT PPDU. The use of the same spatial transformation enables the computation of the spatial equalization at the receiver. When the number of space-time streams, N STS , is less than the number of transmit antennas, or less than min N TX N RX , sending only N STS HT-LTFs does not allow the receiver to recover a full characterization of the MIMO channel, even though the resulting MIMO channel measurement is sufficient for receiving the Data field of the HT PPDU. However, it is often desirable to obtain as full a characterization of the channel as possible. This involves the transmission of a sufficient number of HT-LTFs to sound the full dimensionality of the channel, which is in some cases N TX and in other cases min N TX N RX . These cases of MIMO channel measurement are referred to as MIMO channel sounding. A sounding packet may be used to sound available channel dimensions. A sounding PPDU is identified by setting the Not Sounding field in the HT-SIG to 0. A sounding PPDU may have any allowed number of HT-LTFs satisfying N HT - LTF N STS . In general, if the 2400 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Not Sounding field in the HT-SIG is equal to 0 and N HT - LTF N STS , HT-ELTFs are used, except where N SS = 3 and N HT - LTF = 4 or in an NDP. 19.3.13.2 Sounding with a NDP A STA may sound the channel using a NDP (indicated by the HT Length field in the HT-SIG equal to 0) with the Not Sounding field equal to 0. The number of LTFs is the number implied by the MCS, which shall indicate two or more spatial streams. The last HT-LTF of an NDP shall not be followed by a Data field (see Figure 19-16). It is optional for a STA to process an NDP. HT- HT-GF-STF HT-LTF1 HT-SIG LTF2 Figure 19-16â€”Example of an NDP used for sounding 19.3.13.3 Sounding PPDU for calibration In the case of a bidirectional calibration exchange, two STAs exchange sounding PPDUs, the exchange of which enables the receiving STA to compute an estimate of the MIMO channel matrix H k for each subcarrier k. In general, in an exchange of calibration messages, the number of spatial streams is less than the number of transmit antennas. In such cases, HT-ELTFs are used. In the case of sounding PPDUs for calibration, the antenna mapping matrix shall be as shown in Equation (19-86). Q k = C CSD k P CAL (19-86) where C CSD k is a diagonal cyclic shift matrix in which the diagonal elements carry frequency domain representation of the cyclic shifts given in Table 19-9 P CAL is one of the following unitary matrices: For N TX = 1 P CAL = 1 2 For N TX = 2 P CAL = ------- 1 â€“ 1 2 1 1 1 1 1 3 For N TX = 3 P CAL = ------- 1 e â€“ j 2 3 e â€“j 4 3 3 â€“j 4 3 â€“j 2 3 1 e e 1 â€“1 1 1 1 1 1 â€“1 1 For N TX = 4 P CAL = --- 2 1 1 1 â€“1 â€“1 1 1 1 2401 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 19.3.13.4 Sounding PPDU for channel quality assessment In response to the reception of an MRQ, sent by STA A to STA B, the responding STA B returns to the requesting STA A an MCS selection that STA B determines to be a suitable MCS for STA A to use in subsequent transmissions to STA B. In determining the MCS, STA B performs a channel quality assessment, which entails using whatever information STA B has about the channel, such as an estimate of the MIMO channel derived from the sounding PPDU that carries the MRQ. To enable this calculation, the MRQ is sent in conjunction with a sounding PPDU. The STA sending the MRQ (STA A) determines how many HT-LTFs to send, and whether to use HT-ELTFs or an NDP, based on the Transmit Beamforming Capabilities field, number of space-time streams used in the PPDU carrying the MRQ, the number of transmit chains it is using ( N TX ), whether the transmit and receive STAs support STBC, and in some cases, the number of receive chains at the responding STA ( N RX ). The maximum number of available space-time streams is set by the number of transmit and receive chains and the STBC capabilities of the transmitter and receiver, as is shown in Table 19-21. While the number of receive chains is not communicated in a capabilities indicator, the maximum number of space-time streams supported may be inferred from the MCS capabilities and the STBC capabilities of the receiving STA. When the number of receive chains is known at the transmitter, the number of HT-LTFs sent to obtain a full channel quality assessment is determined according to the maximum number of space-time streams indicated in Table 19-21. The number of HT-LTFs to use in conjunction with the indicated number of space- time streams is determined according to 19.3.9.4.6. Table 19-21â€”Maximum available space-time streams N STS max N STS max N TX N RX without STBC with STBC 1 1 1 N/A 2 1 1 2 3 1 1 2 3 2 2 3 4 1 1 2 4 2 2 4 If the requesting STA A sends an MRQ in a PPDU that uses fewer space-time streams in the data portion than the maximum number of space-time streams possible given the number of antennas at STA A and the responding STA B, the channel quality assessment made by STA B may be based on the HT-DLTFs alone. In this case, the MFB is limited to MCSs using the number of streams used in the Data field of the HT PPDU, or fewer. To determine whether an MCS should be chosen that uses more spatial streams than the PPDU containing the MRQ, it is necessary for the requesting STA A to either use HT-ELTFs (i.e., send the MRQ in a staggered sounding PPDU) or use an NDP (i.e., send the MRQ in conjunction with an NDP). The sounding PPDU may have nonidentity spatial mapping matrix Q k . For different receiving STAs, Q k may vary. 2402 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 19.3.14 Regulatory requirements Wireless LANs (WLANs) implemented in accordance with this standard are subject to equipment certification and operating requirements established by regional and national regulatory administrations. The PHY specification establishes minimum technical requirements for interoperability, based upon established regulations at the time this standard was issued. These regulations are subject to revision or may be superseded. Requirements that are subject to local geographic regulations are annotated within the PHY specification. Regulatory requirements that do not affect interoperability are not addressed in this standard. Implementers are referred to the regulatory sources in Annex D for further information. Operation in countries within defined regulatory domains may be subject to additional or alternative national regulations. 19.3.15 Channel numbering and channelization 19.3.15.1 General The STA may operate in the 5 GHz band and/or 2.4 GHz band. When using 20 MHz channels, it uses channels defined in 17.3.8.4 (5 GHz band) or 16.3.6 (2.4 GHz band). When using 40 MHz channels, it can operate in the channels defined in 19.3.15.2 and 19.3.15.3. The set of valid operating channel numbers by regulatory domain is defined in Annex E. 19.3.15.2 Channel allocation in the 2.4 GHz Band Channel center frequencies are defined at every integer multiple of 5 MHz in the 2.4 GHz band. The relationship between center frequency and channel number is given by Equation (19-87). Channel center frequency = 2407 + 5 n ch (MHz) (19-87) where n ch = 1 2 13 19.3.15.3 Channel allocation in the 5 GHz band Channel center frequencies are defined at every integer multiple of 5 MHz above 5 GHz. The relationship between center frequency and channel number is given in Equation (19-88). Channel center frequency = Channel starting frequency + 5 n ch (MHz) (19-88) where n ch = 1 200 Channel starting frequency is defined as dot11ChannelStartingFactor Ã— 500 kHz or is defined as 5.000 GHz for systems where dot11OperatingClassesRequired is false or not defined. A channel center frequency of 5.000 GHz shall be indicated by dot11ChannelStartingFactor = 8000 and nch = 200. 19.3.15.4 40 MHz channelization The set of valid operating channel numbers by regulatory domain is defined in Annex E. 2403 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The 40 MHz channels are specified by two fields: (Nprimary_ch, Secondary). The first field represents the channel number of the primary channel, and the second field indicates whether the secondary channel is above or below the primary channel (1 indicates above, â€“ 1 indicates below). The secondary channel number shall be Nprimary_ch + Secondary 4. For example, a 40 MHz channel consisting of 40 MHz channel number 36 and Secondary 1 specifies the primary channel is 36 and the secondary channel is 40. 19.3.16 Slot time The slot time shall follow 17.3.8.6 for 5 GHz bands and 18.5.4 for 2.4 GHz bands. The slot time for 40 MHz channel spacing shall be the same as that for 20 MHz channel spacing. 19.3.17 Transmit and receive impedance at the antenna connector The impedance at the transmit and receive antenna connector(s) for each transmit and receive antenna shall follow 17.3.8.7. 19.3.18 PHY transmit specification 19.3.18.1 Transmit spectrum mask NOTE 1â€”In the presence of additional regulatory restrictions, the device has to meet both the regulatory requirements and the mask defined in this subclause, i.e., its emissions can be no higher at any frequency offset than the minimum of the values specified in the regulatory and default masks. NOTE 2â€”The transmit spectral mask figures in this subclause are not drawn to scale. NOTE 3â€”For rules regarding TX center frequency leakage levels by VHT STAs, see 21.3.17.4.2. For the 2.4 GHz band, when transmitting in a 20 MHz channel, the transmitted spectrum shall have a 0 dBr (dB relative to the maximum spectral density of the signal) bandwidth not exceeding 18 MHz, â€“20 dBr at 11 MHz frequency offset, â€“28 dBr at 20 MHz frequency offset, and the maximum of â€“45 dBr and â€“53 dBm/ MHz at 30 MHz frequency offset and above. The transmitted spectral density of the transmitted signal shall fall within the spectral mask, as shown in Figure 19-17. The measurements shall be made using a 100 kHz resolution bandwidth and a 30 kHz video bandwidth. PSD 0dBr â€“20dBr â€“28dBr â€“45dBr Freq [MHz] â€“30 â€“20 â€“11 â€“9 9 11 20 30 Figure 19-17â€”Transmit spectral mask for 20 MHz transmission in the 2.4 GHz band 2404 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications For the 2.4 GHz band, when transmitting in a 40 MHz channel, the transmitted spectrum shall have a 0 dBr bandwidth not exceeding 38 MHz, â€“20 dBr at 21 MHz frequency offset, â€“28 dBr at 40 MHz offset, and the maximum of â€“45 dBr and â€“56 dBm/MHz at 60 MHz frequency offset and above. The transmitted spectral density of the transmitted signal shall fall within the spectral mask, as shown in Figure 19-18. PSD 0dBr â€“20dBr â€“28dBr â€“45dBr Freq [MHz] â€“60 â€“40 â€“21 â€“19 0 19 21 40 60 Figure 19-18â€”Transmit spectral mask for a 40 MHz channel in the 2.4 GHz band For the 5 GHz band, when transmitting in a 20 MHz channel, the transmitted spectrum shall have a 0 dBr (dB relative to the maximum spectral density of the signal) bandwidth not exceeding 18 MHz, â€“20 dBr at 11 MHz frequency offset, â€“28 dBr at 20 MHz frequency offset, and the maximum of â€“40 dBr and â€“53 dBm/ MHz at 30 MHz frequency offset and above. The transmitted spectral density of the transmitted signal shall fall within the spectral mask, as shown in Figure 19-19. The measurements shall be made using a 100 kHz resolution bandwidth and a 30 kHz video bandwidth. PSD 0dBr â€“20dBr â€“28dBr â€“40dBr Freq [MHz] â€“30 â€“20 â€“11 â€“9 9 11 20 30 Figure 19-19â€”Transmit spectral mask for 20 MHz transmission in the 5 GHz band For the 5 GHz band, when transmitting in a 40 MHz channel, the transmitted spectrum shall have a 0 dBr bandwidth not exceeding 38 MHz, â€“20 dBr at 21 MHz frequency offset, â€“28 dBr at 40 MHz offset, and the maximum of â€“40 dBr and â€“56 dBm/MHz at 60 MHz frequency offset and above. The transmitted spectral density of the transmitted signal shall fall within the spectral mask, as shown in Figure 19-20. 2405 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications PSD 0dBr â€“20dBr â€“28dBr â€“40dBr Freq [MHz] â€“60 â€“40 â€“21 â€“19 0 19 21 40 60 Figure 19-20â€”Transmit spectral mask for a 40 MHz channel in the 5 GHz band Transmission with CH_OFF_20U, CH_OFF_20L, or CH_OFF_40 shall comply with the same mask that is used for the 40 MHz channel. 19.3.18.2 Spectral flatness In a 20 MHz channel and in corresponding 20 MHz transmission in a 40 MHz channel, the average energy of the constellations in each of the subcarriers with indices â€“16 to â€“1 and +1 to +16 shall deviate no more than Â± 4 dB from their average energy. The average energy of the constellations in each of the subcarriers with indices â€“28 to â€“17 and +17 to +28 shall deviate no more than +4/â€“6 dB from the average energy of subcarriers with indices â€“16 to â€“1 and +1 to +16. In a 40 MHz transmission (excluding PPDUs in MCS 32 format and non-HT duplicate format), the average energy of the constellations in each of the subcarriers with indices â€“42 to â€“2 and +2 to +42 shall deviate no more than Â± 4 dB from their average energy. The average energy of the constellations in each of the subcarriers with indices â€“43 to â€“58 and +43 to +58 shall deviate no more than +4/â€“6 dB from the average energy of subcarriers with indices â€“42 to â€“2 and +2 to +42. In MCS 32 format and non-HT duplicate format, the average energy of the constellations in each of the subcarriers with indices â€“42 to â€“33, â€“31 to â€“6, +6 to +31, and +33 to +42 shall deviate no more than Â± 4 dB from their average energy. The average energy of the constellations in each of the subcarriers with indices â€“43 to â€“58 and +43 to +58 shall deviate no more than +4/â€“6 dB from the average energy of subcarriers with indices â€“42 to â€“33, â€“31 to â€“6, +6 to +31, and +33 to +42. The tests for the spectral flatness requirements may be performed with spatial mapping Q k = I (see 19.3.11.11.2). 19.3.18.3 Transmit power The maximum allowable output power is measured in accordance with practices specified by the appropriate regulatory bodies. 2406 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 19.3.18.4 Transmit center frequency tolerance The transmitter center frequency tolerance shall be Â± 20 ppm maximum for the 5 GHz band and Â± 25 ppm maximum for the 2.4 GHz band. The different transmit chain center frequencies (LO) and each transmit chain symbol clock frequency shall all be derived from the same reference oscillator. 19.3.18.5 Packet alignment If no signal extension is required (see 19.3.2), the receiver shall emit a PHY-CCA.indication(IDLE) primitive (see 8.3.5.12) at the 4 Âµs boundary following the reception of the last symbol of the packet. If a signal extension is required, the receiver shall emit a PHY-CCA.indication(IDLE) primitive a duration of aSignalExtension after the 4 Âµs boundary following the reception of the last symbol of the packet. This situation is illustrated for an HT-greenfield format packet using short GI in Figure 19-21. If no signal extension is required, the transmitter shall emit a PHY-TXEND.confirm primitive (see 8.3.5.8) at the 4 Âµs boundary following the trailing boundary of the last symbol of the packet on the WM. If a signal extension is required, the transmitter shall emit a PHY-TXEND.confirm primitive (see 8.3.5.8) a duration of aSignalExtension after the 4 Âµs boundary following the trailing boundary of the last symbol of the packet on the WM. This situation is illustrated in Figure 19-21. 8 Âµs 8 Âµs 8 Âµs 4 Âµs 3.6 Âµs 3.6 Âµs 3.6 Âµs 4 Âµs aSignalExtension Âµs boundary HT- Data Data Data HT-GF-STF HT-LTF1 HT-SIG Signal Extension LTF2 Sym 1 Sym 2 Sym 3 Note that Signal Extension field is only PHY-TXEND.confirm present in some PPDU formats. See and 19.3.2. PHY-CCA.indication(IDLE) Figure 19-21â€”Packet alignment example (HT-greenfield format packet with short GI) 19.3.18.6 Symbol clock frequency tolerance The symbol clock frequency tolerance shall be Â± 20 ppm maximum for 5 GHz bands and Â± 25 ppm for 2.4 GHz bands. The transmit center frequency and the symbol clock frequency for all transmit antennas shall be derived from the same reference oscillator. 19.3.18.7 Modulation accuracy 19.3.18.7.1 Introduction to modulation accuracy tests Transmit modulation accuracy specifications are described in 19.3.18.7.2 and 19.3.18.7.3. The test method is described in 19.3.18.7.4. 19.3.18.7.2 Transmit center frequency leakage For VHT STAs the requirements on transmitter center frequency leakage are defined in 21.3.17.4.2; otherwise, the requirements are defined in this subclause. The transmitter center frequency leakage shall follow 17.3.9.7.2 for all transmissions in a 20 MHz channel width. For transmissions in a 40 MHz channel width, the center frequency leakage shall not exceed â€“20 dB relative to overall transmitted power, or, equivalently, 0 dB relative to the average energy of the rest of the subcarriers. For upper or lower 20 MHz transmissions in a 40 MHz channel, the center frequency leakage 2407 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications (center of a 40 MHz channel) shall not exceed â€“17 dB relative to overall transmitted power, or, equivalently, 0 dB relative to the average energy of the rest of the subcarriers. The transmit center frequency leakage is specified per antenna. 19.3.18.7.3 Transmitter constellation error The relative constellation frame-averaged RMS error, calculated first by averaging over subcarriers, OFDM frames, and spatial streams, shall not exceed a data-rate-dependent value according to Table 19-22. The number of spatial streams under test shall be equal to the number of utilized transmitting STA antenna (output) ports and also equal to the number of utilized testing instrumentation input ports. In the test, N SS = N STS with EQM MCSs shall be used. Each output port of the transmitting STA shall be connected through a cable to one input port of the testing instrumentation. The same requirement applies both to 20 MHz channels and 40 MHz channels. Table 19-22â€”Allowed relative constellation error versus constellation size and coding rate Relative constellation error Modulation Coding rate (dB) BPSK 1/2 â€“5 QPSK 1/2 â€“10 QPSK 3/4 â€“13 16-QAM 1/2 â€“16 16-QAM 3/4 â€“19 64-QAM 2/3 â€“22 64-QAM 3/4 â€“25 64-QAM 5/6 â€“27 19.3.18.7.4 Transmitter modulation accuracy (EVM) test The transmit modulation accuracy test shall be performed by instrumentation capable of converting the transmitted signals into a streams of complex samples at 40 Msample/s or more, with sufficient accuracy in terms of I/Q arm amplitude and phase balance, dc offsets, phase noise, and analog-to-digital quantization noise. Each transmit chain is connected directly through a cable to the setup input port. A possible embodiment of such a setup is converting the signals to a low intermediate frequency with a microwave synthesizer, sampling the signal with a digital oscilloscope, and decomposing it digitally into quadrature components. The sampled signal shall be processed in a manner similar to an actual receiver, according to the following steps, or an equivalent procedure: a) Detect the start of frame. b) Detect the transition from short sequences to channel estimation sequences, and establish fine timing (with one sample resolution). c) Estimate the coarse and fine frequency offsets. d) Derotate the frame according to estimated frequency offset. e) Estimate the complex channel response coefficients for each of the subcarriers and each of the transmit chains. 2408 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications f) For each of the data OFDM symbols, transform the symbol into subcarrier received values, estimate the phase from the pilot subcarriers in all spatial streams, derotate the subcarrier values according to estimated phase, group the results from all of the receiver chains in each subcarrier to a vector, multiply the vector by a zero-forcing equalization matrix generated from the channel estimated during the channel estimation phase. g) For each data-carrying subcarrier in each spatial stream, find the closest constellation point and compute the Euclidean distance from it. h) Compute the average of the RMS of all errors in a frame. It is given by Equation (19-89). N SYM N SS N ST 2 2 I i f i s i ss i sc â€“ I 0 i f i s i ss i sc + Q i f i s i ss i sc â€“ Q 0 i f i s i ss i sc Nf i s = 1 i ss = 1 i sc = 1 (19-89) ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- N SYM N SS N ST P 0 if = 1 Error RMS = -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Nf where Nf is the number of frames for the measurement I 0 i f i s i ss i sc Q 0 i f i s i ss i sc denotes the ideal symbol point in the complex plane in subcarrier isc, spatial stream iss, and OFDM symbol is of frame if I i f i s i ss i sc Q i f i s i ss i sc denotes the observed symbol point in the complex plane in subcarrier isc, spatial stream iss, and OFDM symbol is of frame if P0 is the average power of the constellation The vector error on a phase plane is shown in Figure 17-16. The test shall be performed over at least 20 frames (Nf), and the average of the RMS shall be taken. The frames under test shall be at least 16 OFDM symbols long. Random data shall be used for the symbols. 19.3.18.8 Time of Departure accuracy The Time of Departure accuracy test evaluates TIME_OF_DEPARTURE against aTxPHYTxStartRMS and aTxPHYTxStartRMS against TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH as defined in Annex P with the following test parameters: â€” MULTICHANNEL_SAMPLING_RATE is: fH â€“ fL 20 10 6 1 + ------------------- - sample/s, for a CH_BANDWIDTH parameter equal to HT_CBW20 20 MHz fH â€“ fL 40 10 6 1 + ------------------- - sample/s, for a CH_BANDWIDTH parameter equal to HT_CBW40 40 MHz where fH is the nominal center frequency in Hz of the highest channel in the channel set fL is the nominal center frequency in Hz of the lowest channel in the channel set, the channel set is the set of channels upon which frames providing measurements are transmitted, the channel set comprises channels uniformly spaced across fH â€“ fL 50 MHz â€” FIRST_TRANSITION_FIELD is L-STF (for HT-mixed format) or HT-GF-STF (for HT-greenfield format) â€” SECOND_TRANSITION_FIELD is L-LTF (for HT-mixed format) or HT-GF-LTF1 (for HT- greenfield format) 2409 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” TRAINING_FIELD is L-LTF (for HT-mixed format) or HT-LTF1 (for HT-greenfield format) windowed in a manner which should approximate the windowing described in 17.3.2.5 with TTR = 100 ns. â€” TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH is 80 ns (for a CH_BANDWIDTH parameter equal to HT_CBW20) or 80 ns (for a CH_BANDWIDTH parameter equal to HT_CBW40). NOTEâ€”The indicated windowing applies to the time of departure accuracy test equipment, and not the transmitter or receiver. 19.3.19 HT PHY receiver specification 19.3.19.1 Receiver minimum input sensitivity The packet error ratio (PER) shall be less than 10% for a PSDU length of 4096 octets with the rate- dependent input levels listed in Table 19-23 or less. The minimum input levels are measured at the antenna connectors and are referenced as the average power per receive antenna. The number of spatial streams under test shall be equal to the number of utilized transmitting STA antenna (output) ports and also equal to the number of utilized device under test input ports. Each output port of the transmitting STA shall be connected through a cable to one input port of the device under test. The test in this subclause and the minimum sensitivity levels specified in Table 19-23 apply only to non-STBC modes, MCSs 0â€“31, 800 ns GI, and BCC. Table 19-23â€”Receiver minimum input level sensitivity Adjacent Nonadjacent Minimum sensitivity Minimum sensitivity Rate channel channel (20 MHz (40 MHz Modulation (R) rejection rejection channel spacing) channel spacing) (dB) (dB) (dBm) (dBm) BPSK 1/2 16 32 â€“82 â€“79 QPSK 1/2 13 29 â€“79 â€“76 QPSK 3/4 11 27 â€“77 â€“74 16-QAM 1/2 8 24 â€“74 â€“71 16-QAM 3/4 4 20 â€“70 â€“67 64-QAM 2/3 0 16 â€“66 â€“63 64-QAM 3/4 â€“1 15 â€“65 â€“62 64-QAM 5/6 â€“2 14 â€“64 â€“61 19.3.19.2 Adjacent channel rejection For all transmissions in a 20 MHz channel width, the adjacent channel rejection shall be measured by setting the desired signalâ€™s strength 3 dB above the rate-dependent sensitivity specified in Table 19-23 and raising the power of an interfering signal of 20 MHz bandwidth until 10% PER is caused for a PSDU length of 4096 octets. The difference in power between the signals in the interfering channel and the desired channel is the corresponding adjacent channel rejection. The adjacent channel center frequencies shall be separated by 20 MHz when operating in the 5 GHz band, and the adjacent channel center frequencies shall be separated by 25 MHz when operating in the 2.4 GHz band. 2410 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications For all transmissions in a 40 MHz channel width, the adjacent channel rejection shall be measured by setting the desired signalâ€™s strength 3 dB above the rate-dependent sensitivity specified in Table 19-23 and raising the power of an interfering signal of 40 MHz bandwidth until 10% PER is caused for a PSDU length of 4096 octets. The difference in power between the signals in the interfering channel and the desired channel is the corresponding adjacent channel rejection. The adjacent channel center frequencies shall be separated by 40 MHz. The interfering signal in the adjacent channel shall be a signal compliant with the HT PHY, unsynchronized with the signal in the channel under test. The corresponding rejection shall be no less than specified in Table 19-23. The interference signal shall have a minimum duty cycle of 50%. The test in this subclause and the adjacent channel rejection levels specified in Table 19-23 apply only to non-STBC modes, MCSs 0â€“31, 800 ns GI, and BCC. 19.3.19.3 Nonadjacent channel rejection For all transmissions in a 20 MHz channel width in the 5 GHz band, the nonadjacent channel rejection shall be measured by setting the desired signalâ€™s strength 3 dB above the rate-dependent sensitivity specified in Table 19-23 and raising the power of an interfering signal of 20 MHz bandwidth until a 10% PER occurs for a PSDU length of 4096 octets. The difference in power between the signals in the interfering channel and the desired channel is the corresponding nonadjacent channel rejection. The nonadjacent channel center frequencies shall be separated by 40 MHz or more. For all transmissions in a 40 MHz channel width in the 5 GHz band, the nonadjacent channel rejection shall be measured by setting the desired signalâ€™s strength 3 dB above the rate-dependent sensitivity specified in Table 19-23 and raising the power of an interfering signal of 40 MHz bandwidth until a 10% PER occurs for a PSDU length of 4096 octets. The difference in power between the signals in the interfering channel and the desired channel is the corresponding nonadjacent channel rejection. The nonadjacent channel center frequencies shall be separated by 80 MHz or more. The interfering signal in the nonadjacent channel shall be a signal compliant with the HT PHY, unsynchronized with the signal in the channel under test. The corresponding rejection shall be no less than specified in Table 19-23. The interference signal shall have a minimum duty cycle of 50%. The nonadjacent channel rejection for transmissions in a 20 MHz or 40 MHz channel width is applicable only to 5 GHz band. The test in this subclause and the nonadjacent channel rejection level specified in Table 19-23 apply only to non-STBC modes, MCSs 0â€“31, 800 ns GI, and BCC. 19.3.19.4 Receiver maximum input level The receiver shall provide a maximum PER of 10% at a PSDU length of 4096 octets, for a maximum input level of â€“30 dBm in the 5 GHz band and â€“20 dBm in the 2.4 GHz band, measured at each antenna for any baseband modulation. 19.3.19.5 CCA sensitivity 19.3.19.5.1 CCA-Energy Detect (CCA-ED) For the operating classes requiring CCA-Energy Detect (CCA-ED), the PHY shall also indicate a medium busy condition when CCA-ED detects a channel busy condition. For improved spectrum sharing, CCA-ED is required in some bands. The behavior class indicating CCA-ED is given in Table D-2. The operating classes requiring the corresponding CCA-ED behavior class are given 2411 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications in E.1. The PHY of a STA that is operating within an operating class that requires CCA-ED shall operate with CCA-ED. CCA-ED shall detect a channel busy condition when the received signal strength exceeds the CCA-ED threshold as given by dot11OFDMEDThreshold for the primary 20 MHz channel and dot11OFDMEDThreshold for the secondary 20 MHz channel (if present). The CCA-ED thresholds for the operating classes requiring CCA-ED are subject to the criteria in D.2.5. NOTEâ€”The requirement to detect a channel busy condition as stated in 19.3.19.5.2, 19.3.19.5.3, and 19.3.19.5.4 is a mandatory energy detection requirement on all Clause 19 receivers. Support for CCA-ED is an additional requirement that relates specifically to the sensitivities described in D.2.5. 19.3.19.5.2 CCA sensitivity for non-HT PPDUs CCA sensitivity requirements for non-HT PPDUs in the primary channel are described in 17.3.10.6 and 18.4.6. 19.3.19.5.3 CCA sensitivity in 20 MHz For an HT STA with the operating channel width equal to 20 MHz, the start of a valid 20 MHz HT signal at a receive level greater than or equal to the minimum modulation and coding rate sensitivity of â€“82 dBm shall cause the PHY to set PHY-CCA.indication(BUSY) with a probability > 90% within 4 s. The receiver shall indicate a channel busy condition for any signal 20 dB or more above the minimum modulation and coding rate sensitivity (â€“82 + 20 = â€“62 dBm) in the 20 MHz channel. An HT STA that does not support the reception of HT_GF format PPDUs shall indicate a channel busy condition (PHY-CCA.indication(BUSY)) for any valid HT_GF signal in the 20 MHz channel at a receive level greater than or equal to â€“72 dBm. 19.3.19.5.4 CCA sensitivity in 40 MHz This subclause describes the CCA sensitivity requirements for an HT STA with the operating channel width equal to 40 MHz. The receiver of a 20/40 MHz STA with the operating channel width equal to 40 MHz shall provide CCA on both the primary and secondary channels. When the secondary channel is idle, the start of a valid 20 MHz HT signal in the primary channel at a receive level greater than or equal to the minimum modulation and coding rate sensitivity of â€“82 dBm shall cause the PHY to generate a PHY-CCA.indication(BUSY, {primary}) primitive with a probability > 90% within 4 s. The start of a valid 40 MHz HT signal that occupies both the primary and secondary channels at a receive level greater than or equal to the minimum modulation and coding rate sensitivity of â€“79 dBm shall cause the PHY to generate a PHY-CCA.indication(BUSY, {primary, secondary}) primitive for both the primary and secondary channels with a probability per channel > 90% within 4 s. An HT STA that does not support the reception of HT_GF format PPDUs shall indicate a {primary} channel busy condition (PHY-CCA.indication(BUSY, {primary}) primitive) for any valid HT_GF signal in the primary channel at a receive level greater than or equal to â€“72 dBm when the secondary channel is idle. An HT STA that does not support the reception of HT_GF format PPDUs shall indicate a {primary, secondary} channel busy condition (PHY-CCA.indication(BUSY, {primary, secondary}) primitive) for any valid 40 MHz HT_GF signal in both the primary and secondary channels at a receive level greater than or equal to â€“69 dBm. The receiver shall indicate a {primary} channel busy condition for any signal at or above â€“62 dBm in the 20 MHz primary channel. This level is 20 dB above the minimum modulation and coding rate sensitivity for 2412 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications a 20 MHz PPDU. When the primary channel is idle, the receiver indicate a {secondary} channel busy condition for any signal at or above â€“62 dBm in the 20 MHz secondary channel. The receiver shall indicate a {primary, secondary} channel busy condition for any signal present in both the primary and secondary channels that is at or above â€“62 dBm in the primary channel and at or above â€“62 dBm in the secondary channel. 19.3.19.6 Received channel power indicator (RCPI) measurement The RCPI is a measure of the received RF power in the selected channel. This parameter shall be a measure by the PHY of the received RF power in the channel measured over the data portion of the received frame. The received power shall be the average of the power in all active receive chains. The RCPI encoding is defined in 15.4.6.6. RCPI shall equal the received RF power within an accuracy of Â± 5 dB (95% confidence interval) within the specified dynamic range of the receiver. The received RF power shall be determined assuming a receiver noise equivalent bandwidth equal to the channel width multiplied by 1.1. 19.3.19.7 Reduced interframe space (RIFS) The receiver shall be able to decode a packet that was transmitted with a RIFS separation from the previous packet. 19.3.20 PHY transmit procedure There are three options for the transmit PHY procedure. The first two options, for which typical transmit procedures are shown in Figure 19-22 and Figure 19-23, are selected if the FORMAT field of the PHY-TXSTART.request(TXVECTOR) primitive is equal to HT_MF or HT_GF, respectively. These transmit procedures do not describe the operation of optional features, such as LDPC or STBC. The third option is to follow the transmit procedure in Clause 17 or Clause 18 if the FORMAT field is equal to NON_HT. Additionally, if the FORMAT field is equal to NON_HT, CH_BANDWIDTH indicates NON_HT_CBW20, and NON_HT_MODULATION indicates OFDM, follow the transmit procedure in Clause 17. If the FORMAT field is equal to NON_HT, CH_BANDWIDTH indicates NON_HT_CBW20, and NON_HT_MODULATION indicates other than OFDM, follow the transmit procedure in Clause 18. And furthermore, if the FORMAT field is equal to NON_HT and CH_BANDWIDTH indicates NON_HT_CBW40, follow the transmit procedure in Clause 17, except that the signal in Clause 17 is generated simultaneously on each of the upper and lower 20 MHz channels that constitute the 40 MHz channel as defined in 19.3.8 and 19.3.11.12. In all these options, in order to transmit data, the PHY- TXSTART.request primitive shall be enabled so that the PHY entity shall be in the transmit state. Further, the PHY shall be set to operate at the appropriate frequency through station management via the PLME, as specified in 19.4. Other transmit parameters, such as MCS coding types and transmit power, are set via the PHY SAP with the PHY-TXSTART.request(TXVECTOR) primitive, as described in 19.2.2. A clear channel shall be indicated by issuing a PHY-CCA.indication(IDLE) primitive. Note that under some circumstances, the MAC uses the latest value of the PHY-CCA.indication primitive before issuing the PHY- TXSTART.request primitive. Transmission of the PPDU shall be initiated after receiving the PHY-TXSTART.request(TXVECTOR) primitive. The TXVECTOR elements for the PHY- TXSTART.request primitive are specified in Table 19-1. Transmission of the PHY preamble may start if TIME_OF_DEPARTURE_REQUESTED is false, and shall start immediately if TIME_OF_DEPARTURE_REQUESTED is true, based on the parameters passed in the PHY-TXSTART.request primitive. 2413 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications PHY-TXEND.request PHY-TXEND.confirm PHY-TXSTART.confirm PHY-DATA.request PHY-DATA.confirm PHY-TXSTART.request PHY-DATA.request PHY-DATA.confirm (TXSTATUS) (TXVECTOR) â€¦â€¦â€¦â€¦..â€¦â€¦â€¦â€¦ MAC MPDU Tail Bits (if BCC) L-SIG HT-SIG PSDU Bit Padding IF needed Scrambling + encoding PHY Non-HT L-SIG HT-SIG HT-Training Data (Variable number of OFDM symbols) Signal Extension (if Preamble present) Coded Coded OFDM OFDM Coded OFDM, MCS indicated in HT-SIG BPSK, QBPSK, Rate 1/2 Rate 1/2 NOTEâ€”This procedure does not describe the operation of optional features, such as LDPC or STBC Figure 19-22â€”PHY transmit procedure (HT-mixed format PPDU) PHY-TXEND.request PHY-TXEND.confirm PHY-TXSTART.confirm PHY-DATA.request PHY-DATA.confirm PHY-TXSTART.request PHY-DATA.request PHY-DATA.confirm (TXSTATUS) (TXVECTOR) â€¦â€¦â€¦â€¦..â€¦â€¦â€¦â€¦ MAC MPDU Tail Bits (if BCC) HT-SIG PSDU Bit Padding IF needed Scrambling + encoding HT-Training Signal Extension PHY Part I HT-SIG HT-Training Data (Variable number of OFDM symbols) (if present) Coded OFDM Coded OFDM, MCS indicated in HT-SIG QBPSK, Rate 1/2 NOTEâ€”This procedure does not describe the operation of optional features, such as LDPC or STBC. Figure 19-23â€”PHY transmit procedure (HT-greenfield format PPDU) The data shall then be exchanged between the MAC and the PHY through a series of PHY- DATA.request(DATA) primitives issued by the MAC and PHY-DATA.confirm primitives issued by the PHY. Once PHY preamble transmission is started, the PHY entity shall immediately initiate data scrambling and data encoding. The encoding method shall be based on the FEC_CODING, CH_BANDWIDTH, and 2414 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MCS parameter of the TXVECTOR. A modulation rate change, if any, shall be initiated starting with the SERVICE field data, as described in 19.3.2. The PHY proceeds with PSDU transmission through a series of data octet transfers from the MAC. The SERVICE field and PSDU are encoded by the encoder selected by the FEC_CODING, CH_BANDWIDTH, and MCS parameters of the TXVECTOR as described in 19.3.3. Transmission can be prematurely terminated by the MAC through the primitive PHY-TXEND.request primitive. PHY-TXSTART shall be disabled by receiving a PHY-TXEND.request primitive. Normal termination occurs after the transmission of the final bit of the last PSDU octet, according to the number supplied in the LENGTH field. The packet transmission shall be completed, and the PHY entity shall enter the receive state (i.e., PHY- TXSTART shall be disabled). Each PHY-TXEND.request primitive is acknowledged with a PHY- TXEND.confirm primitive from the PHY. If the length of the coded PSDU is not an integer multiple of the OFDM symbol length, bits shall be stuffed to make the coded PSDU length an integer multiple of the OFDM symbol length. The GI shall be inserted in every OFDM symbol as a countermeasure against delay spread. In some PPDU formats (as defined in 19.3.2), a signal extension is present. When no signal extension is present, the PHY-TXEND.confirm primitive is generated at the end of last symbol of the PPDU. When a signal extension is present, the PHY-TXEND.confirm primitive is generated at the end of the signal extension. A typical state machine implementation of the transmit PHY is provided in Figure 19-24. Requests (.request) and confirmations (.confirm) are issued once per state as shown. This state machine does not describe the operation of optional features, such as LDPC or STBC. 19.3.21 PHY receive procedure Typical PHY receive procedures are shown in Figure 19-25 and Figure 19-26. The receive procedures correspond to HT-mixed format and HT-greenfield format, respectively. A typical state machine implementation of the receive PHY is given in Figure 19-27. These receive procedures and state machine do not describe the operation of optional features, such as LDPC or STBC. If the detected format indicates a non-HT PPDU format, refer to the receive procedure and state machine in Clause 17 or Clause 18. Further, through station management (via the PLME), the PHY is set to the appropriate frequency, as specified in 19.4. Other receive parameters, such as RSSI and indicated DATARATE, may be accessed via the PHY SAP. Upon receiving the transmitted PHY preamble, the PHY measures a receive signal strength. This indicates activity to the MAC via the PHY-CCA.indication primitive. A PHY-CCA.indication(BUSY, channel-list) primitive shall also be issued as an initial indication of reception of a signal. The channel-list parameter of the PHY-CCA.indication primitive is determined as follows: â€” It is absent when the operating channel width is 20 MHz. â€” It is set to {primary} when the operating channel width is 40 MHz and the signal is present only in the primary channel. â€” It is set to {secondary} when the operating channel width is 40 MHz and the signal is present only in the secondary channel. â€” It is set to {primary, secondary} when the operating channel width is 40 MHz and the signal is present in both the primary and secondary channels. The RSSI parameter is reported to the MAC in the RXVECTOR. 2415 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications PHY-TXSTART.request (TXVECTOR) TX PSDU OCTET PHY-DATA. request(DATA) Get octet from MAC and encoding Initialize PHY-DATA.confirm Length >1 Length =1 Set TX parameters FORMAT=HT_MF OR TAIL APPEND FORMAT=NON_HT Tails bits are appended BIT PADDING FORMAT=HT_GF Tails bits are appended TX GF HT-Preamble TX L-Preamble TX SYMBOL Tx HT Training Part I TX HT-SIG in TX Training Symbols Set symbol bit count QBPSK rate 1/2 TX L-SIG in BPSK rate 1/2 TX HT Training Bit Count > 0 PHY-TXSTART.confirm FORMAT= (TXSTATUS) FORMAT= HT_MF NON_HT Decrement Bit Refer to Decrement bit count TX HT-Preamble clause 17 or 18 by bits per symbol Change Modulation to QBPSK, Bit Count = 0 TX HT-SIG TX HT Training Symbols Decrement Length Decrement Length count Length >0 Length = 0 TX Data Wait TX_END Change coding rate and modulation type TX encoded 16 bit service field signal extension Add Signal Extension no signal extension Wait for duration of SETUP MPDU TX signal extension PHY-DATA. request(DATA) PHY-TXSTART.confirm Set length count Switch RX state NOTEâ€”This state machine A At any stage in the does not describe the operation above flow diagram, if A of optional features, such as a PHY- TXEND.request is LDPC or STBC. received. Figure 19-24â€”PHY transmit state machine 2416 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications CS/CCA state RX state PHY-RXSTART.indication PHY-CCA.indication PHY-RXEND.indication (NoError, RXVECTOR) PHY-DATA.indication PHY-DATA.indication PHY-CCA.indication (STATE=busy) (RXVECTOR) (IDLE) MAC MPDU Tail Bits (if BCC used) Decoding Delay L-SIG HT-SIG PSDU Issued at the same Measure Decoded and time RSSI Bit removing descrambled IF needed PHY L-STF L-LTF L-SIG HT-SIG HT-Training Data (Variable number of OFDM symbols) Signal Extension (if present) Coded Coded OFDM OFDM Coded OFDM, MCS indicated in HT-SIG BPSK, QBPSK, Rate 1/2 Rate 1/2 NOTEâ€”This procedure does not describe the operation of optional features, such as LDPC or STBC. Figure 19-25â€”PHY receive procedure for HT-mixed format PPDU format CS/CCA state RX state PHY-RXSTART.indication PHY-CCA.indication PHY-RXEND.indication (NoError, RXVECTOR) PHY-DATA.indication PHY-DATA.indication PHY-CCA.indication (STATE=busy) (RXVECTOR) (IDLE) MAC Tail Bits MPDU (if BCC used ) Measure HT-SIG PSDU RSSI Issued at the Decoded and same time Bit removing descrambled IF needed PHY HT-Training Part I HT-SIG HT-Training Data (Variable number of OFDM symbols ) Signal Extension (if present ) Coded OFDM Coded OFDM , MCS indicated in HT -SIG QBPSK , Rate 1/2 NOTE â€”This procedure does not describe the operation of optional features , such as LDPC or STBC. Figure 19-26â€”PHY receive procedure for HT-greenfield format PPDU 2417 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications RX IDLE state CS/CCA Set PHY-CCA.indication(BUSY) End of Wait Detect SIG A RX Symbol Set PHY-CCA. Determine type of HT_SIG (GF preamble) indication(IDLE) SIG field when receive level drops below L-SIG (MF or non-HT threshold (missed preamble) preamble) Carrier lost Valid Signal Detect L-SIG Carrier Lost Receive L-SIG Set PHY-RXEND field Signal Not Valid Decode Symbol .indication(CarrierLost) Signal Valid Set RxEndStatus Decode and = (CarrierLost, descramble RX L-SIG Null) symbol RX and test Parity Not HT-SIG: Refer to 16.2.3 or Decrement Time Decrement Length Detect HT-SIG 19.3.5 PHY-DATA Carrier Lost Determine Wait for intended .indication(DATA) Set PHY-RXEND whether HT-SIG end of PSDU (bit removing if needed) Length Decrement length count .indication follows L-SIG >0 (CarrierLost) HT_SIG Time=0 Length=0 RX HT-SIG CRC Fail: End of Wait End of PSDU RX Set PHY-RXEND RX and test CRC .indication Set RxEndStatus = Check for Signal (NoError,RXVECTOR) (FormatViolation) Extension Check for Signal CRC OK Extension End of Wait Check Preamble Unsupported Type no signal signal signal no signal Set PHY-CCA Preamble: extension extension Check for HT_GF extension extension .indication(IDLE) Set PHY- when receive RXSTART.indica or HT_MF tion preamble type level drops below Signal Extension (RXVECTOR) threshold then set PHY- (minimum RXEND Supported Preamble CS/CCA Wait for duration of modulation and .indication(Form atViolation) Evaluate HT-SIG A detected. Set PHY-RXEND signal extension coding rate .indication sensitivity + 10 Check contents in (RxEndStatus) dB) HT-SIG for Unsupported mode: supported mode Set PHY-RXSTART Supported .indication End of Wait mode (RXVECTOR) then set Set PHY-CCA Setup PSDU RX PHY-RXEND .indication(IDLE). Set .indication(Unsuppor Set Length PHY-RXEND tedRate) Set PHY-RXSTART .indication .indication (RxEndStatus) (RXVECTOR) End of Wait For Reserved HT-SIG For unsupported Indication: set PHY-CCA modes: set PHY-CCA .indication(IDLE) when .indication(IDLE) receive level drops when predicted below threshold duration based on (minimum modulation and coding rate NOTEâ€”This state machine does not describe the operation TXTIME has elapsed sensitivity + 20 dB) of optional features, such as LDPC or STBC. Figure 19-27â€”PHY receive state machine 2418 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications After the PHY-CCA.indication(BUSY, channel-list) primitive is issued, the PHY entity shall begin receiving the training symbols and searching for SIGNAL and HT-SIG in order to set the length of the data stream, the demodulation type, code type, and the decoding rate. If signal loss occurs before validating L-SIG and/or HT-SIG, the HT PHY shall not generate a PHY-CCA.indication(IDLE) primitive until the received level drops below the CCA sensitivity level (for a missed preamble) specified in 19.3.19.5. If the check of the HT- SIG CRC is not valid, a PHY-RXSTART.indication primitive is not issued. The PHY shall indicate the error condition by issuing a PHY-RXEND.indication(FormatViolation) primitive. The HT PHY shall not generate a PHY-CCA.indication(IDLE) primitive until the received level drops below the CCA sensitivity level (for a missed preamble) specified in 19.3.19.5. If the PHY preamble reception is successful and a valid HT-SIG CRC is indicated: â€” Upon reception of an HT-mixed format preamble, the HT PHY shall not generate a PHY- CCA.indication(IDLE) primitive for the predicted duration of the transmitted frame, as defined by TXTIME in 19.4.3, for all supported and unsupported modes except Reserved HT-SIG Indication. Reserved HT-SIG Indication is defined in the fourth list item below. â€” Upon reception of a GF preamble by an HT STA that does not support GF, the HT PHY shall not generate a PHY-CCA.indication(IDLE) primitive until either the predicted duration of the packet from the contents of the HT-SIG field, as defined by TXTIME in 19.4.3, except Reserved HT-SIG Indication, elapses or until the received level drops below the receiver minimum sensitivity level of BPSK, R=1/2 in Table 19-23 + 10 dB (â€“72 dBm for 20 MHz, â€“69 dBm for 40 MHz). Reserved HT- SIG Indication is defined in the fourth list item below. â€” Upon reception of a GF preamble by an HT STA that supports GF, the HT PHY shall not generate a PHY-CCA.indication(IDLE) primitive for the predicted duration of the transmitted frame, as defined by TXTIME in 19.4.3, for all supported and unsupported modes except Reserved HT-SIG Indication. Reserved HT-SIG Indication is defined in the fourth list item below. â€” If the HT-SIG indicates a Reserved HT-SIG Indication, the HT PHY shall not generate a PHY- CCA.indication(IDLE) primitive until the received level drops below the CCA sensitivity level (minimum modulation and coding rate sensitivity + 20 dB) specified in 19.3.19.5. Reserved HT-SIG Indication is defined as an HT-SIG with MCS field in the range 77â€“127 or Reserved field = 0 or STBC field = 3 and any other HT-SIG field bit combinations that do not correspond to modes of PHY operation defined in Clause 19. Subsequent to an indication of a valid HT-SIG CRC, a PHY-RXSTART.indication(RXVECTOR) primitive shall be issued. If dot11TimingMsmtActivated is true, the PHY shall do the following: â€” Complete receiving the PHY header and verify the validity of the PHY Header. â€” If the PHY header reception is successful (and the SIGNAL field is completely recognizable and supported), a PHY-RXSTART.indication(RXVECTOR) primitive shall be issued and RX_START_OF_FRAME_OFFSET parameter within the RXVECTOR shall be forwarded (see 19.2.2). NOTEâ€”The RX_START_OF_FRAME_OFFSET value is used as described in 6.3.57 in order to estimate when the start of the preamble for the incoming frame was detected on the medium at the receive antenna connector. The RXVECTOR associated with this primitive includes the parameters specified in Table 19-1. Upon reception of a GF preamble by an HT STA that does not support GF, the FORMAT field of RXVECTOR is equal to HT_GF, the remaining fields may be empty, and the PHY shall indicate the error condition by issuing a PHY-RXEND.indication(FormatViolation) primitive. If the HT-SIG indicates an unsupported mode or Reserved HT-SIG Indication, the PHY shall indicate the error condition by issuing a PHY- RXEND.indication(UnsupportedRate) primitive. Following training and SIGNAL fields, the coded PSDU (which comprises the coded PHY SERVICE field and scrambled and coded PSDU) shall be received. If signal loss occurs during reception prior to completion of the PSDU reception, the error condition shall be reported to the MAC using a 2419 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications PHY-RXEND.indication(CarrierLost) primitive. After waiting for the intended end of the PSDU, if no signal extension is present (as defined in 19.3.2), the PHY shall generate a PHY-CCA.indication(IDLE) primitive and return to RX IDLE state. Otherwise, the receiver waits for the duration of the signal extension before returning to the RX IDLE state. The received PSDU bits are assembled into octets, decoded, and presented to the MAC using a series of PHY-DATA.indication(DATA) primitive exchanges. The number of PSDU octets is indicated in the HT Length field of the HT-SIG. The PHY shall proceed with PSDU reception. After the reception of the final bit of the last PSDU octet and possible tail and padding bits, the receiver shall be returned to the RX IDLE state if no signal extension is present (as defined in 19.3.2), as shown in Figure 19-27. Otherwise, the receiver waits for the duration of the signal extension before returning to the RX IDLE state. A PHY- RXEND.indication(NoError) primitive shall be issued on entry to the RX IDLE state. While in the Signal Extension state, if the receiver detects a CS/CCA event, it issues an RXEND.indication primitive (with the RXERROR parameter set to NoError or CarrierLost, depending on whether a carrier lost event occurred during the reception of the PPDU), leaves the Signal Extension state, and enters the Detect SIG state. This sequence occurs when signal-extended PPDUs are transmitted while separated by a RIFS. If the binary convolutional code is used, any data received after the indicated data length are considered pad bits (to fill out an OFDM symbol) and should be discarded. 19.4 HT PLME 19.4.1 PLME SAP sublayer management primitives Table 19-24 lists the MIB attributes that may be accessed by the PHY entities and the intralayer of higher level LMEs. These attributes are accessed via the PLME-GET, PLME-SET, PLME-RESET, and PLME- CHARACTERISTICS primitives defined in 6.2 and 6.5.4. 19.4.2 PHY MIB HT PHY MIB attributes are defined in Annex C with specific values defined in Table 19-24. The â€œOperational semanticsâ€ column in Table 19-24 contains two types: static and dynamic. â€” Static MIB attributes are fixed and cannot be modified for a given PHY implementation. â€” Dynamic MIB attributes are interpreted according to the MAX-ACCESS field of the MIB attribute. When MAX-ACCESS is equal to read-only, the MIB attribute value may be updated by the PLME and read from the MIB attribute by management entities. When MAX-ACCESS is equal to read- write, the MIB attribute may be read and written by management entities. Table 19-24â€”HT PHY MIB attributes Default Operational Managed object value/range semantics dot11PHYOperationTable dot11PHYType HT (X'07') Static dot11CurrentRegDomain Implementation dependent Dynamic 2420 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 19-24â€”HT PHY MIB attributes (continued) Default Operational Managed object value/range semantics dot11PHYAntennaTable dot11CurrentTxAntenna Implementation dependent Dynamic dot11DiversitySupportImplemented Implementation dependent Static dot11CurrentRxAntenna Implementation dependent Dynamic dot11AntennaSelectionOptionImplemented false/Boolean Static dot11TransmitExplicitCSIFeedbackASOptionImplemented false/Boolean Static dot11TransmitIndicesFeedbackASOptionImplemented false/Boolean Static dot11ExplicitCSIFeedbackASOptionImplemented false/Boolean Static dot11TransmitIndicesComputationASOptionImplemented false/Boolean Static dot11ReceiveAntennaSelectionOptionImplemented false/Boolean Static dot11TransmitSoundingPPDUOptionImplemented false/Boolean Static dot11PHYTxPowerTable dot11NumberSupportedPowerLevelsImplemented Implementation dependent Static dot11TxPowerLevel1 Implementation dependent Static dot11TxPowerLevel2 Implementation dependent Static dot11TxPowerLevel3 Implementation dependent Static dot11TxPowerLevel4 Implementation dependent Static dot11TxPowerLevel5 Implementation dependent Static dot11TxPowerLevel6 Implementation dependent Static dot11TxPowerLevel7 Implementation dependent Static dot11TxPowerLevel8 Implementation dependent Static dot11CurrentTxPowerLevel Implementation dependent Dynamic dot11PhyDSSSTable dot11CurrentChannel Implementation dependent Dynamic dot11RegDomainsSupportedTable dot11RegDomainsImplementedValue Implementation dependent Static dot11FrequencyBandsSupported Implementation dependent Static dot11PHYAntennasListTable dot11SupportedTxAntenna Implementation dependent Dynamic dot11SupportedRxAntenna Implementation dependent Static dot11DiversitySelectionRx Implementation dependent Dynamic 2421 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 19-24â€”HT PHY MIB attributes (continued) Default Operational Managed object value/range semantics dot11SupportedDataRatesTxTable dot11SupportedDataratesTxValue X'02' = 1 Mb/s (2.4) Static X'04' = 2 Mb/s (2.4) X'0B' = 5.5 Mb/s (2.4) X'16' = 11 Mb/s (2.4) X'0C' = 6 Mb/s X'12' = 9 Mb/s X'18' = 12 Mb/s X'24' = 18 Mb/s X'30' = 24 Mb/s X'48' = 36 Mb/s X'60' = 48 Mb/s X'6C' = 54 Mb/s dot11SupportedDataRatesRxTable dot11SupportedDataRatesRxTable X'02' = 1 Mb/s (2.4) Static X'04' = 2 Mb/s (2.4) X'0B' = 5.5 Mb/s (2.4) X'16' = 11 Mb/s (2.4) X'0C' = 6 Mb/s X'12' = 9 Mb/s X'18' = 12 Mb/s X'24' = 18 Mb/s X'30' = 24 Mb/s X'48' = 36 Mb/s X'60' = 48 Mb/s X'6C' = 54 Mb/s dot11HRDSSSPHYTable dot11ShortPreambleOptionImplemented true Static dot11PHYOFDMTable dot11CurrentFrequency Implementation dependent Dynamic dot11TIThreshold Implementation dependent Dynamic dot11ChannelStartingFactor Implementation dependent Dynamic dot11PHYERPTable dot11ShortSlotTimeOptionImplemented Implementation dependent Static dot11ShortSlotTimeOptionActivated Implementation dependent Dynamic 2422 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 19-24â€”HT PHY MIB attributes (continued) Default Operational Managed object value/range semantics dot11PHYHTTable dot11FortyMHzOperationImplemented false/Boolean Static dot11FortyMHzOperationActivated false/Boolean Dynamic dot11CurrentPrimaryChannel Implementation dependent Dynamic dot11CurrentSecondaryChannel Implementation dependent Dynamic dot11NumberOfSpatialStreamsImplemented Implementation dependent Static dot11NumberOfSpatialStreamsActivated Implementation dependent Dynamic dot11HTGreenfieldOptionImplemented false/Boolean Static dot11HTGreenfieldOptionActivated false/Boolean Dynamic dot11ShortGIOptionInTwentyImplemented false/Boolean Static dot11ShortGIOptionInTwentyActivated false/Boolean Dynamic dot11ShortGIOptionInFortyImplemented false/Boolean Static dot11ShortGIOptionInFortyActivated false/Boolean Dynamic dot11LDPCCodingOptionImplemented false/Boolean Static dot11LDPCCodingOptionActivated false/Boolean Dynamic dot11TxSTBCOptionImplemented false/Boolean Static dot11TxSTBCOptionActivated false/Boolean Dynamic dot11RxSTBCOptionImplemented false/Boolean Static dot11RxSTBCOptionActivated false/Boolean Dynamic dot11BeamFormingOptionImplemented false/Boolean Static dot11BeamFormingOptionActivated false/Boolean Dynamic dot11SupportedMCSTxTable dot11SupportedMCSTxValue MCS 0â€“76 for 20 MHz; Static MCS 0â€“76 for 40 MHz (MCS 0â€“7 for 20 MHz mandatory at non-AP STA; MCS 0â€“15 for 20 MHz mandatory at AP) dot11SupportedMCSRxTable dot11SupportedMCSRxValue MCS 0â€“76 for 20 MHz; Static MCS 0â€“76 for 40 MHz (MCS 0â€“7 for 20 MHz mandatory at non-AP STA; MCS 0â€“15 for 20 MHz mandatory at AP) 2423 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 19-24â€”HT PHY MIB attributes (continued) Default Operational Managed object value/range semantics dot11TransmitBeamformingConfigTable dot11ReceiveStaggerSoundingOptionImplemented false/Boolean Static dot11TransmitStaggerSoundingOptionImplemented false/Boolean Static dot11ReceiveNDPOptionImplemented false/Boolean Static dot11TransmitNDPOptionImplemented false/Boolean Static dot11ImplicitTransmitBeamformingOptionImplemented false/Boolean Static dot11CalibrationOptionImplemented Implementation dependent Static dot11ExplicitCSITransmitBeamformingOptionImplemented false/Boolean Static dot11ExplicitNonCompressedBeamformingMatrixOption- false/Boolean Static Implemented dot11ExplicitTransmitBeamformingCSIFeedbackOption- Implementation dependent Static Implemented dot11ExplicitNoncompressedBeamformingFeedbackOption- Implementation dependent Static Implemented dot11ExplicitCompressedBeamformingFeedbackOption- Implementation dependent Static Implemented dot11NumberBeamFormingCSISupportAntenna Implementation dependent Static dot11NumberNonCompressedBeamformingMatrixSupport- Implementation dependent Static Antenna dot11NumberCompressedBeamformingMatrixSupportAntenna Implementation dependent Static dot11TxMCSSetDefined false/Boolean Static dot11TxRxMCSSetNotEqual false/Boolean Static dot11TxMaximumNumberSpatialStreamsSupported false/Boolean Static dot11TxUnequalModulationSupported false/Boolean Static 19.4.3 TXTIME calculation The value of the TXTIME parameter returned by the PLME-TXTIME.confirm primitive or calculated for the PHY receive procedure shall be calculated for HT-mixed format according to the Equation (19-90) and Equation (19-91) for short and long GI, respectively, and for HT-greenfield format according to Equation (19-92) and Equation (19-93) for short and long, respectively: TXTIME = T LEG_PREAMBLE + T L_SIG + T HT_PREAMBLE + T HT_SIG (19-90) T SYMS N SYM + T SYM -------------------------------- + SignalExtension T SYM 2424 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications TXTIME = T LEG_PREAMBLE + T L_SIG + T HT_PREAMBLE + T HT_SIG (19-91) + T SYM N SYM + SignalExtension TXTIME = T GF_HT_PREAMBLE + T HT_SIG + T SYMS N SYM + SignalExtension (19-92) TXTIME = T GF_HT_PREAMBLE + T HT_SIG + T SYM N SYM + SignalExtension (19-93) where T LEG_PREAMBLE = T L-STF + T L-LTF is the duration of the non-HT preamble THT_PREAMBLE is the duration of the HT preamble in HT-mixed format, given by T HT â€“ STF + T HT â€“ LTF 1 + N HT - LTF â€“ 1 T HT â€“ LTFs TGF_HT_PREAMBLE is the duration of the preamble in HT-greenfield format, given by T HT â€“ GF â€“ STF + T HT â€“ LTF 1 + N HT - LTF â€“ 1 T HT â€“ LTFs TSYM, TSYMS, THT-SIG, TL-STF, THT-STF, THT-GF-STF, TL-LTF, THT-LTF1 and THT-LTFs are defined in Table 19-6 SignalExtension is 0 Âµs when TXVECTOR parameter NO_SIG_EXTN is true and is aSignalExtension as defined in Table 19-25 when TXVECTOR parameter NO_SIG_EXTN is false NHT-LTF is defined in Equation (19-22) NSYM is defined in Equation (19-32) for BCC and Equation (19-41) for LDPC For non-HT modes of operation, refer to Clause 17 and Clause 18 for TXTIME calculations, except that frames transmitted with a value of NON_HT_DUP_OFDM for the TXVECTOR parameter NON_HT_MODULATION shall use Equation (18-1) for TXTIME calculation. 19.4.4 HT PHY The static HT PHY characteristics, provided through the PLME-CHARACTERISTICS service primitive, shall be as shown in Table 19-25. The definitions for these characteristics are given in 6.5.4 Table 19-25â€”HT PHY characteristics Characteristics Value aRIFSTime 2 Âµs aSlotTime When operating in the 2.4 GHz band: If dot11OperatingClassesRequired is false, long = 20 Âµs If dot11OperatingClassesRequired is true, long = 20 Âµs plus any coverage-class-dependent aAirPropagationTime (see Table 9-79) If dot11OperatingClassesRequired is false, short = 9 Âµs If dot11OperatingClassesRequired is true, short = 9 Âµs plus any coverage-class-dependent aAirPropagationTime (see Table 9- 79) When operating in the 5 GHz band: If dot11OperatingClassesRequired is false, 9 Âµs If dot11OperatingClassesRequired is true, 9 Âµs plus any coverage-class-dependent aAirPropagationTime (see Table 9- 79) 2425 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 19-25â€”HT PHY characteristics (continued) Characteristics Value aSIFSTime 10 Âµs when operating in the 2.4 GHz band 16 Âµs when operating in the 5 GHz bands aSignalExtension 0 Âµs when operating in the 5 GHz band 6 Âµs when operating in the 2.4 GHz band aCCATime Implementation dependent, see 10.3.7. aRxPHYStartDelay 28 Âµs for HT-mixed format, 24 Âµs for HT-greenfield format aRxTxTurnaroundTime Implementation dependent, see 10.3.7. aTxPHYDelay Implementation dependent, see 10.3.7. aRxPHYDelay Implementation dependent, see 10.3.7. aRxTxSwitchTime Implementation dependent, see 10.3.7. aTxRampOnTime Implementation dependent, see 10.3.7. aAirPropagationTime As indicated by the coverage class (see 10.21.5). aMACProcessingDelay Implementation dependent, see 10.3.7. aPreambleLength 16 Âµs aSTFOneLength 8 Âµs aSTFTwoLength 4 Âµs aLTFOneLength 8 Âµs aLTFTwoLength 4 Âµs aPHYHeaderLength 4 Âµs for HT-mixed format, N/A for HT-greenfield format aPHYSigTwoLength 8 Âµs aPHYServiceLength 16 bits aPHYConvolutionalTailLen 6 bits gth aPSDUMaxLength 65 535 octets aPPDUMaxTime 10 ms aIUStime 8 Âµs aDTT2UTTTime 32 Âµs aCWmin 15 aCWmax 1023 aMaxCSIMatricesReportDel 250 ms ay For non-HT modes of operation, refer to Clause 17 and Clause 18 for PHY characteristics. 2426 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 19.5 Parameters for HT MCSs Table 19-26 defines the symbols used in the rate-dependent parameter tables. Table 19-26â€”Symbols used in MCS parameter tables Symbol Explanation NSS Number of spatial streams R Coding rate NBPSC Number of coded bits per single carrier (total across spatial streams) NBPSCS(iSS) Number of coded bits per single carrier for each spatial stream, iSS = 1,...,NSS NSD Number of complex data numbers per spatial stream per OFDM symbol NSP Number of pilot values per OFDM symbol NCBPS Number of coded bits per OFDM symbol NDBPS Number of data bits per OFDM symbol NES Number of BCC encoders for the DATA field NTBPS Total bits per subcarrier In the MCS parameter tables that follow, data rates for a 400 ns GI are rounded to 1 decimal place. The rate-dependent parameters for mandatory 20 MHz, NSS = 1 MCSs with NES = 1 shall be as shown in Table 19-27. Table 19-27â€”MCS parameters for mandatory 20 MHz, NSS = 1, NES = 1 Data rate (Mb/s) MCS Modulation R NBPSCS(iSS) NSD NSP NCBPS NDBPS Index 400 ns GI 800 ns GI (see NOTE) 0 BPSK 1/2 1 52 4 52 26 6.5 7.2 1 QPSK 1/2 2 52 4 104 52 13.0 14.4 2 QPSK 3/4 2 52 4 104 78 19.5 21.7 3 16-QAM 1/2 4 52 4 208 104 26.0 28.9 4 16-QAM 3/4 4 52 4 208 156 39.0 43.3 5 64-QAM 2/3 6 52 4 312 208 52.0 57.8 6 64-QAM 3/4 6 52 4 312 234 58.5 65.0 7 64-QAM 5/6 6 52 4 312 260 65.0 72.2 NOTEâ€”Support of 400 ns GI is optional on transmit and receive. 2427 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The rate-dependent parameters for optional 20 MHz, NSS = 2 MCSs with NES = 1 and EQM of the spatial streams shall be as shown in Table 19-28. Table 19-28â€”MCS parameters for optional 20 MHz, NSS = 2, NES = 1, EQM Data rate (Mb/s) MCS Modulation R NBPSCS(iSS) NSD NSP NCBPS NDBPS Index 800 ns GI 400 ns GI 8 BPSK 1/2 1 52 4 104 52 13.0 14.4 9 QPSK 1/2 2 52 4 208 104 26.0 28.9 10 QPSK 3/4 2 52 4 208 156 39.0 43.3 11 16-QAM 1/2 4 52 4 416 208 52.0 57.8 12 16-QAM 3/4 4 52 4 416 312 78.0 86.7 13 64-QAM 2/3 6 52 4 624 416 104.0 115.6 14 64-QAM 3/4 6 52 4 624 468 117.0 130.0 15 64-QAM 5/6 6 52 4 624 520 130.0 144.4 The rate-dependent parameters for optional 20 MHz, NSS = 3 MCSs with NES = 1 and EQM of the spatial streams shall be as shown in Table 19-29. Table 19-29â€”MCS parameters for optional 20 MHz, NSS = 3, NES = 1, EQM Data rate (Mb/s) MCS Modulation R NBPSCS(iSS) NSD NSP NCBPS NDBPS Index 800 ns GI 400 ns GI 16 BPSK 1/2 1 52 4 156 78 19.5 21.7 17 QPSK 1/2 2 52 4 312 156 39.0 43.3 18 QPSK 3/4 2 52 4 312 234 58.5 65.0 19 16-QAM 1/2 4 52 4 624 312 78.0 86.7 20 16-QAM 3/4 4 52 4 624 468 117.0 130.0 21 64-QAM 2/3 6 52 4 936 624 156.0 173.3 22 64-QAM 3/4 6 52 4 936 702 175.5 195.0 23 64-QAM 5/6 6 52 4 936 780 195.0 216.7 2428 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The rate-dependent parameters for optional 20 MHz, NSS = 4 MCSs with NES = 1 and EQM of the spatial streams shall be as shown in Table 19-30. Table 19-30â€”MCS parameters for optional 20 MHz, NSS = 4, NES = 1, EQM Data rate (Mb/s) MCS Modulation R NBPSCS(iSS) NSD NSP NCBPS NDBPS Index 800 ns GI 400 ns GI 24 BPSK 1/2 1 52 4 208 104 26.0 28.9 25 QPSK 1/2 2 52 4 416 208 52.0 57.8 26 QPSK 3/4 2 52 4 416 312 78.0 86.7 27 16-QAM 1/2 4 52 4 832 416 104.0 115.6 28 16-QAM 3/4 4 52 4 832 624 156.0 173.3 29 64-QAM 2/3 6 52 4 1248 832 208.0 231.1 30 64-QAM 3/4 6 52 4 1248 936 234.0 260.0 31 64-QAM 5/6 6 52 4 1248 1040 260.0 288.9 The rate-dependent parameters for optional 40 MHz, NSS = 1 MCSs with NES = 1 shall be as shown in Table 19-31. Table 19-31â€”MCS parameters for optional 40 MHz, NSS = 1, NES = 1 Data rate (Mb/s) MCS Modulation R NBPSCS(iSS) NSD NSP NCBPS NDBPS Index 800 ns GI 400 ns GI 0 BPSK 1/2 1 108 6 108 54 13.5 15.0 1 QPSK 1/2 2 108 6 216 108 27.0 30.0 2 QPSK 3/4 2 108 6 216 162 40.5 45.0 3 16-QAM 1/2 4 108 6 432 216 54.0 60.0 4 16-QAM 3/4 4 108 6 432 324 81.0 90.0 5 64-QAM 2/3 6 108 6 648 432 108.0 120.0 6 64-QAM 3/4 6 108 6 648 486 121.5 135.0 7 64-QAM 5/6 6 108 6 648 540 135.0 150.0 2429 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The rate-dependent parameters for optional 40 MHz, NSS = 2 MCSs with NES = 1 and EQM of the spatial streams shall be as shown in Table 19-32. Table 19-32â€”MCS parameters for optional 40 MHz, NSS = 2, NES = 1, EQM Data rate (Mb/s) MCS Modulation R NBPSCS(iSS) NSD NSP NCBPS NDBPS Index 800 ns GI 400 ns GI 8 BPSK 1/2 1 108 6 216 108 27.0 30.0 9 QPSK 1/2 2 108 6 432 216 54.0 60.0 10 QPSK 3/4 2 108 6 432 324 81.0 90.0 11 16-QAM 1/2 4 108 6 864 432 108.0 120.0 12 16-QAM 3/4 4 108 6 864 648 162.0 180.0 13 64-QAM 2/3 6 108 6 1296 864 216.0 240.0 14 64-QAM 3/4 6 108 6 1296 972 243.0 270.0 15 64-QAM 5/6 6 108 6 1296 1080 270.0 300.0 The rate-dependent parameters for optional 40 MHz, NSS = 3 MCSs, with EQM of the spatial streams shall be as shown in Table 19-33. Table 19-33â€”MCS parameters for optional 40 MHz, NSS = 3, EQM Data rate (Mb/s) MCS Modulation R NBPSCS(iSS) NSD NSP NCBPS NDBPS NES Index 800 ns GI 400 ns GI 16 BPSK 1/2 1 108 6 324 162 1 40.5 45.0 17 QPSK 1/2 2 108 6 648 324 1 81.0 90.0 18 QPSK 3/4 2 108 6 648 486 1 121.5 135.0 19 16-QAM 1/2 4 108 6 1296 648 1 162.0 180.0 20 16-QAM 3/4 4 108 6 1296 972 1 243.0 270.0 21 64-QAM 2/3 6 108 6 1944 1296 2 324.0 360.0 22 64-QAM 3/4 6 108 6 1944 1458 2 364.5 405.0 23 64-QAM 5/6 6 108 6 1944 1620 2 405.0 450.0 2430 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The rate-dependent parameters for optional 40 MHz, NSS = 4 MCSs, with EQM of the spatial streams shall be as shown in Table 19-34. Table 19-34â€”MCS parameters for optional 40 MHz, NSS = 4, EQM Data rate (Mb/s) MCS Modulation R NBPSCS(iSS) NSD NSP NCBPS NDBPS NES Index 800 ns GI 400 ns GI 24 BPSK 1/2 1 108 6 432 216 1 54.0 60.0 25 QPSK 1/2 2 108 6 864 432 1 108.0 120.0 26 QPSK 3/4 2 108 6 864 648 1 162.0 180.0 27 16-QAM 1/2 4 108 6 1728 864 1 216.0 240.0 28 16-QAM 3/4 4 108 6 1728 1296 2 324.0 360.0 29 64-QAM 2/3 6 108 6 2592 1728 2 432.0 480.0 30 64-QAM 3/4 6 108 6 2592 1944 2 486.0 540.0 31 64-QAM 5/6 6 108 6 2592 2160 2 540.0 600.0 The rate-dependent parameters for optional 40 MHz MCS 32 format with NSS = 1 and NES = 1 shall be as shown in Table 19-35. Table 19-35â€”MCS parameters for optional 40 MHz MCS 32 format, NSS = 1, NES = 1 Data rate (Mb/s) MCS Modulation R NBPSCS(iSS) NSD NSP NCBPS NDBPS Index 800 ns GI 400 ns GI 32 BPSK 1/2 1 48 4 48 24 6.0 6.7 The rate-dependent parameters for optional 20 MHz, NSS = 2 MCSs with NES = 1 and UEQM of the spatial streams shall be as shown in Table 19-36. Table 19-36â€”MCS parameters for optional 20 MHz, NSS = 2, NES = 1, UEQM Modulation Data rate (Mb/s) MCS Index R NBPSC NSD NSP NCBPS NDBPS Stream 1 Stream 2 800 ns GI 400 ns GI 33 16-QAM QPSK 1/2 6 52 4 312 156 39 43.3 34 64-QAM QPSK 1/2 8 52 4 416 208 52 57.8 35 64-QAM 16-QAM 1/2 10 52 4 520 260 65 72.2 36 16-QAM QPSK 3/4 6 52 4 312 234 58.5 65.0 37 64-QAM QPSK 3/4 8 52 4 416 312 78 86.7 38 64-QAM 16-QAM 3/4 10 52 4 520 390 97.5 108.3 2431 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The rate-dependent parameters for optional 20 MHz, NSS = 3 MCSs with NES = 1 and UEQM of the spatial streams shall be as shown in Table 19-37. Table 19-37â€”MCS parameters for optional 20 MHz, NSS = 3, NES = 1, UEQM Modulation Data rate (Mb/s) MCS R NBPSC NSD NSP NCBPS NDBPS Index 800 ns 400 ns Stream 1 Stream 2 Stream 3 GI GI 39 16-QAM QPSK QPSK 1/2 8 52 4 416 208 52 57.8 40 16-QAM 16-QAM QPSK 1/2 10 52 4 520 260 65 72.2 41 64-QAM QPSK QPSK 1/2 10 52 4 520 260 65 72.2 42 64-QAM 16-QAM QPSK 1/2 12 52 4 624 312 78 86.7 43 64-QAM 16-QAM 16-QAM 1/2 14 52 4 728 364 91 101.1 44 64-QAM 64-QAM QPSK 1/2 14 52 4 728 364 91 101.1 45 64-QAM 64-QAM 16-QAM 1/2 16 52 4 832 416 104 115.6 46 16-QAM QPSK QPSK 3/4 8 52 4 416 312 78 86.7 47 16-QAM 16-QAM QPSK 3/4 10 52 4 520 390 97.5 108.3 48 64-QAM QPSK QPSK 3/4 10 52 4 520 390 97.5 108.3 49 64-QAM 16-QAM QPSK 3/4 12 52 4 624 468 117 130.0 50 64-QAM 16-QAM 16-QAM 3/4 14 52 4 728 546 136.5 151.7 51 64-QAM 64-QAM QPSK 3/4 14 52 4 728 546 136.5 151.7 52 64-QAM 64-QAM 16-QAM 3/4 16 52 4 832 624 156 173.3 The rate-dependent parameters for optional 20 MHz, NSS = 4 MCSs with NES = 1 and UEQM in the spatial streams shall be as shown in Table 19-38. Table 19-38â€”MCS parameters for optional 20 MHz, NSS = 4, NES = 1, UEQM Data rate Modulation (Mb/s) MCS R NBPSC NSD NSP NCBPS NDBPS Index 800 ns 400 ns Stream 1 Stream 2 Stream 3 Stream 4 GI GI 53 16-QAM QPSK QPSK QPSK 1/2 10 52 4 520 260 65 72.2 54 16-QAM 16-QAM QPSK QPSK 1/2 12 52 4 624 312 78 86.7 55 16-QAM 16-QAM 16-QAM QPSK 1/2 14 52 4 728 364 91 101.1 56 64-QAM QPSK QPSK QPSK 1/2 12 52 4 624 312 78 86.7 57 64-QAM 16-QAM QPSK QPSK 1/2 14 52 4 728 364 91 101.1 58 64-QAM 16-QAM 16-QAM QPSK 1/2 16 52 4 832 416 104 115.6 59 64-QAM 16-QAM 16-QAM 16-QAM 1/2 18 52 4 936 468 117 130.0 2432 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 19-38â€”MCS parameters for optional 20 MHz, NSS = 4, NES = 1, UEQM (continued) Data rate Modulation (Mb/s) MCS R NBPSC NSD NSP NCBPS NDBPS Index 800 ns 400 ns Stream 1 Stream 2 Stream 3 Stream 4 GI GI 60 64-QAM 64-QAM QPSK QPSK 1/2 16 52 4 832 416 104 115.6 61 64-QAM 64-QAM 16-QAM QPSK 1/2 18 52 4 936 468 117 130.0 62 64-QAM 64-QAM 16-QAM 16-QAM 1/2 20 52 4 1040 520 130 144.4 63 64-QAM 64-QAM 64-QAM QPSK 1/2 20 52 4 1040 520 130 144.4 64 64-QAM 64-QAM 64-QAM 16-QAM 1/2 22 52 4 1144 572 143 158.9 65 16-QAM QPSK QPSK QPSK 3/4 10 52 4 520 390 97.5 108.3 66 16-QAM 16-QAM QPSK QPSK 3/4 12 52 4 624 468 117 130.0 67 16-QAM 16-QAM 16-QAM QPSK 3/4 14 52 4 728 546 136.5 151.7 68 64-QAM QPSK QPSK QPSK 3/4 12 52 4 624 468 117 130.0 69 64-QAM 16-QAM QPSK QPSK 3/4 14 52 4 728 546 136.5 151.7 70 64-QAM 16-QAM 16-QAM QPSK 3/4 16 52 4 832 624 156 173.3 71 64-QAM 16-QAM 16-QAM 16-QAM 3/4 18 52 4 936 702 175.5 195.0 72 64-QAM 64-QAM QPSK QPSK 3/4 16 52 4 832 624 156 173.3 73 64-QAM 64-QAM 16-QAM QPSK 3/4 18 52 4 936 702 175.5 195.0 74 64-QAM 64-QAM 16-QAM 16-QAM 3/4 20 52 4 1040 780 195 216.7 75 64-QAM 64-QAM 64-QAM QPSK 3/4 20 52 4 1040 780 195 216.7 76 64-QAM 64-QAM 64-QAM 16-QAM 3/4 22 52 4 1144 858 214.5 238.3 The rate-dependent parameters for optional 40 MHz, NSS = 2 MCSs with NES = 1 and UEQM of the spatial streams shall be as shown in Table 19-39. Table 19-39â€”MCS parameters for optional 40 MHz, NSS = 2, NES = 1, UEQM Modulation Data rate (Mb/s) MCS Index R NBPSC NSD NSP NCBPS NDBPS Stream 1 Stream 2 800 ns GI 400 ns GI 33 16-QAM QPSK 1/2 6 108 6 648 324 81 90 34 64-QAM QPSK 1/2 8 108 6 864 432 108 120 35 64-QAM 16-QAM 1/2 10 108 6 1080 540 135 150 36 16-QAM QPSK 3/4 6 108 6 648 486 121.5 135 37 64-QAM QPSK 3/4 8 108 6 864 648 162 180 38 64-QAM 16-QAM 3/4 10 108 6 1080 810 202.5 225 2433 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The rate-dependent parameters for optional 40 MHz, NSS = 3 MCSs, with UEQM of the spatial streams shall be as shown in Table 19-40. Table 19-40â€”MCS parameters for optional 40 MHz, NSS = 3, UEQM Modulation Data rate (Mb/s) MCS R NBPSC NSD NSP NCBPS NDBPS NES Index 800 ns 400 ns Stream 1 Stream 2 Stream 3 GI GI 39 16-QAM QPSK QPSK 1/2 8 108 6 864 432 1 108 120 40 16-QAM 16-QAM QPSK 1/2 10 108 6 1080 540 1 135 150 41 64-QAM QPSK QPSK 1/2 10 108 6 1080 540 1 135 150 42 64-QAM 16-QAM QPSK 1/2 12 108 6 1296 648 1 162 180 43 64-QAM 16-QAM 16-QAM 1/2 14 108 6 1512 756 1 189 210 44 64-QAM 64-QAM QPSK 1/2 14 108 6 1512 756 1 189 210 45 64-QAM 64-QAM 16-QAM 1/2 16 108 6 1728 864 1 216 240 46 16-QAM QPSK QPSK 3/4 8 108 6 864 648 1 162 180 47 16-QAM 16-QAM QPSK 3/4 10 108 6 1080 810 1 202.5 225 48 64-QAM QPSK QPSK 3/4 10 108 6 1080 810 1 202.5 225 49 64-QAM 16-QAM QPSK 3/4 12 108 6 1296 972 1 243 270 50 64-QAM 16-QAM 16-QAM 3/4 14 108 6 1512 1134 1 283.5 315 51 64-QAM 64-QAM QPSK 3/4 14 108 6 1512 1134 1 283.5 315 52 64-QAM 64-QAM 16-QAM 3/4 16 108 6 1728 1296 2 324 360 The rate-dependent parameters for optional 40 MHz, NSS = 4 MCSs, with UEQM of the spatial streams shall be as shown in Table 19-41. Table 19-41â€”MCS parameters for optional 40 MHz, NSS = 4, UEQM Data rate Modulation (Mb/s) MCS R NBPSC NSD NSP NCBPS NDBPS NES Index Stream Stream Stream Stream 800 ns 400 ns 1 2 3 4 GI GI 53 16- QPSK QPSK QPSK 1/2 10 108 6 1080 540 1 135 150 QAM 54 16- 16- QPSK QPSK 1/2 12 108 6 1296 648 1 162 180 QAM QAM 55 16- 16- 16- QPSK 1/2 14 108 6 1512 756 1 189 210 QAM QAM QAM 56 64- QPSK QPSK QPSK 1/2 12 108 6 1296 648 1 162 180 QAM 57 64- 16- QPSK QPSK 1/2 14 108 6 1512 756 1 189 210 QAM QAM 2434 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 19-41â€”MCS parameters for optional 40 MHz, NSS = 4, UEQM (continued) Data rate Modulation (Mb/s) MCS R NBPSC NSD NSP NCBPS NDBPS NES Index Stream Stream Stream Stream 800 ns 400 ns 1 2 3 4 GI GI 58 64- 16- 16- QPSK 1/2 16 108 6 1728 864 1 216 240 QAM QAM QAM 59 64- 16- 16- 16- 1/2 18 108 6 1944 972 1 243 270 QAM QAM QAM QAM 60 64- 64- QPSK QPSK 1/2 16 108 6 1728 864 1 216 240 QAM QAM 61 64- 64- 16- QPSK 1/2 18 108 6 1944 972 1 243 270 QAM QAM QAM 62 64- 64- 16- 16- 1/2 20 108 6 2160 1080 1 270 300 QAM QAM QAM QAM 63 64- 64- 64- QPSK 1/2 20 108 6 2160 1080 1 270 300 QAM QAM QAM 64 64- 64- 64- 16- 1/2 22 108 6 2376 1188 1 297 330 QAM QAM QAM QAM 65 16- QPSK QPSK QPSK 3/4 10 108 6 1080 810 1 202.5 225 QAM 66 16- 16- QPSK QPSK 3/4 12 108 6 1296 972 1 243 270 QAM QAM 67 16- 16- 16- QPSK 3/4 14 108 6 1512 1134 1 283.5 315 QAM QAM QAM 68 64- QPSK QPSK QPSK 3/4 12 108 6 1296 972 1 243 270 QAM 69 64- 16- QPSK QPSK 3/4 14 108 6 1512 1134 1 283.5 315 QAM QAM 70 64- 16- 16- QPSK 3/4 16 108 6 1728 1296 2 324 360 QAM QAM QAM 71 64- 16- 16- 16- 3/4 18 108 6 1944 1458 2 364.5 405 QAM QAM QAM QAM 72 64- 64- QPSK QPSK 3/4 16 108 6 1728 1296 2 324 360 QAM QAM 73 64- 64- 16- QPSK 3/4 18 108 6 1944 1458 2 364.5 405 QAM QAM QAM 74 64- 64- 16- 16- 3/4 20 108 6 2160 1620 2 405 450 QAM QAM QAM QAM 75 64- 64- 64- QPSK 3/4 20 108 6 2160 1620 2 405 450 QAM QAM QAM 76 64- 64- 64- 16- 3/4 22 108 6 2376 1782 2 445.5 495 QAM QAM QAM QAM 2435 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 20. Directional multi-gigabit (DMG) PHY specification 20.1 DMG PHY introduction 20.1.1 Scope The DMG PHY supports three modulation methods: â€” A control modulation using MCS 0 (the DMG control mode; see 20.4) â€” A single carrier (SC) modulation using MCS 1 to MCS 12, MCS 9.1, 12.1, 12.2, 12.3, 12.4, 12.5 and 12.6 (the DMG SC mode; see 20.6) and MCS 25 to MCS 31 (the DMG low-power SC mode; see 20.7) â€” An OFDM modulation using MCS 13 to MCS 24 (the DMG OFDM mode; see 20.5) All DMG modulation methods share a similar preamble (see 20.3.6). The services provided to the MAC by the DMG PHY consist of the following protocol functions: a) A function that defines a method of mapping the PHY service data units (PSDU) into a framing format (PPDU) suitable for sending and receiving PSDUs between two or more STAs. b) A function that defines the characteristics and method of transmitting and receiving data through a wireless medium between two or more STAs. Depending on the DMG MCSs, these STAs support a mixture of DMG SC mode, DMG OFDM mode, DMG low-power SC mode, and DMG control mode. 20.1.2 DMG PHY functions The DMG PHY contains two functional entities: the PHY and the layer management function (PLME). Each of these functions is described in detail in 20.3 to 20.12. The DMG PHY service is provided to the MAC through the PHY service primitives defined in Clause 8. 20.1.2.1 PHY management entity (PLME) The PLME performs management of the local PHY functions in conjunction with the MLME. 20.1.2.2 Service specification method The models represented by figures and state diagrams are intended to be illustrations of the functions provided. It is important to distinguish between a model and a real implementation. The models are optimized for simplicity and clarity of presentation, but do not necessarily reflect any particular implementation. The service of a layer or sublayer is the set of capabilities that it offers to a user in the next higher layer (or sublayer). Abstract services are specified here by describing the service primitives and parameters that characterize each service. This definition is independent of any particular implementation. 20.2 DMG PHY service interface 20.2.1 Introduction The PHY interfaces to the MAC through the TXVECTOR, RXVECTOR, and the PHYCONFIG_VECTOR. Using the TXVECTOR, the MAC supplies the PHY with per-PPDU transmit parameters. Using the RXVECTOR, the PHY informs the MAC of the received packet parameters. Using the PHYCONFIG_VECTOR, the MAC configures the PHY for operation, independent of frame transmission or reception. 2436 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This interface is an extension of the generic PHY service interface defined in 8.3.4. 20.2.2 TXVECTOR and RXVECTOR parameters The parameters in Table 20-1 are defined as part of the TXVECTOR parameter list in the PHY- TXSTART.request primitive and/or as part of the RXVECTOR parameter list in the PHY- RXSTART.indication primitive. Table 20-1â€”TXVECTOR and RXVECTOR parameters RXVECTOR TXVECTOR Parameter Value MCS The MCS parameter is an enumerated type that indicates the modulation Y Y and coding scheme used in the transmission of the packet. Values are integers in the range 0 to 31 and the values 9.1, 12.1, 12.2, 12.3, 12.4, 12.5 and 12.6. â€” An MCS value of 0 indicates the use of DMG control mode. â€” MCS values of 1 to 12 and 9.1, 12.1, 12.2, 12.3, 12.4, 12.5, 12.6 indicate use of single carrier modulations. The value is an index to Table 20-19. â€” MCS values of 13 to 24 indicates use of OFDM modulations. The value is an index to Table 20-14. â€” MCS values of 25 to 31 indicate use of DMG low-power SC mode. The value is an index to Table 20-23. LENGTH Indicates the number of octets in the PSDU in the range 1 to 262 143. Y Y ADD-PPDU Enumerated Type: Y Y â€” ADD-PPDU indicates that this PPDU is immediately followed by another PPDU with no IFS or preamble on the subsequent PPDU. â€” NO-ADD-PPDU indicates no additional PPDU follows this PPDU. PACKET-TYPE Enumerated Type: Y Y â€” TRN-R-PACKET indicates either a packet whose data part is followed by one or more TRN subfields, or a packet that is requesting TRN subfields to be appended to a future response packet. â€” TRN-T-PACKET indicates a packet whose data part is followed by one or more TRN subfields. The transmitter may change AWV configuration at the beginning of each TRN subfield. This parameter is reserved if TRN-LEN is 0. TRN-LEN TRN-LEN indicates the length of the training field. Values are in the Y Y range 0â€“16 (see 20.10.2.2.3). AGGREGATION Indicates whether the PSDU contains an A-MPDU. Y Y Enumerated Type: â€” AGGREGATED indicates this is a PSDU with A-MPDU aggregation. â€” NOT_AGGREGATED indicates this is a PSDU without A-MPDU aggregation. 2437 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 20-1â€”TXVECTOR and RXVECTOR parameters (continued) RXVECTOR TXVECTOR Parameter Value RSSI The allowed values for the RSSI parameter are in the range 0 through N Y RSSI maximum. This parameter is a measure by the PHY of the power observed at the input of the antennas plus the antenna gain, or equivalent antenna gain for a phased-array antenna, used to receive the current PPDU. RSSI shall be measured during the reception of the PHY pream- ble. RSSI is intended to be used in a relative manner, and it shall be a monotonically increasing function of the received power. SNR This parameter indicates the SNR measured during the reception of a N Y DMG control mode packet. Values are â€“13 dB to 50.75 dB in 0.25 dB steps. RCPI Is a measure of the received RF power measured over the preamble of a N Y received frame. Refer to 20.3.10 for the definition of RCPI. ANT_CONFIG Indicates which antenna configuration(s) is to be used throughout the Y N transmission of the packet, and when to switch between configurations. Values are implementation dependent. CHAN_MEASURE- Channel as measured during the reception of TRN subfields. Each mea- N Y MENT surement includes 63 complex numbers. TIME_OF_DEPAR- Enumerated type: O N TURE_REQUESTED â€” true indicates that the MAC entity requests that the PHY PHY entity measures and reports time of departure parameters corresponding to the time when the first frame energy is sent by the transmitting port. â€” false indicates that the MAC entity requests that the PHY PHY entity neither measures nor reports time of departure parameters. RX_START_OF_- 0 to 232â€“1. An estimate of the offset (in 10 nanosecond units) from the N See FRAME_OFFSET point in time at which the start of the preamble corresponding to the NO incoming frame arrived at the receive antenna connector to the point in TE time at which this primitive is issued to the MAC. DTP_TYPE Enumerated: Y Y â€” STATIC indicating static tone paring (see 20.5.3.2.4.6.2). â€” DYNAMIC indicating dynamic tone pairing (see 20.5.3.2.4.6.3). DTP_INDICATOR An update to the DTP tone map is indicated by changing the value of this Y Y parameter from 0 to 1 or from 1 to 0 (see 10.40) BEAM_TRACK- This parameter indicates whether beam tracking is requested. Enumer- Y Y ING_REQUEST ated type: Beam tracking requested or Beam tracking not requested 2438 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 20-1â€”TXVECTOR and RXVECTOR parameters (continued) RXVECTOR TXVECTOR Parameter Value LAST_RSSI In the TXVECTOR, LAST_RSSI indicates the received power level of Y Y the last packet with a valid PHY header that was received a SIFS before transmission of the current packet; otherwise, it is 0 (10.3.2.3.3). In the RXVECTOR, LAST_RSSI indicates the value of the LAST_RSSI field from the PCLP header of the received packet. Valid values are inte- gers in the range 0 to 15: â€” Values of 2 to 14 represent power levels (â€“71+valueÃ—2) dBm. â€” A value of 15 represents power greater than or equal to â€“42 dBm. â€” A value of 1 represents power less than or equal to â€“68 dBm. â€” A value of 0 indicates that the previous packet was not received a SIFS before the current transmission. Turnaround Set to 1 or 0 as specified in 10.3.2.3.3. Y Y NOTEâ€” â€œYâ€ if dot11TimingMsmtActivated is true, otherwise â€œNâ€. 20.2.3 TXSTATUS parameters The parameters listed in Table 20-2 are defined as part of the TXSTATUS parameter list in the PHY-TXSTART.confirm(TXSTATUS) primitive. Table 20-2â€”TXSTATUS parameters Parameter Value TIME_OF_DEPARTURE When the first frame energy is sent by the transmitting port, in units equal to 1/TIME_OF_DEPARTURE_ClockRate. This parameter is present only if TIME_OF_DEPARTURE_RE- QUESTED is true in the corresponding request. TIME_OF_DEPARTURE_ClockRate 0 to 216â€“1. The clock rate, in units of MHz, is used to generate the TIME_OF_DEPARTURE value. This parameter is present only if TIME_OF_DEPARTURE_REQUESTED is true in the corre- sponding request. TX_START_OF_FRAME_OFFSET 0 to 232â€“1. An estimate of the offset (in 10 nanosecond units) from the point in time at which the start of the preamble corresponding to the frame was transmitted at the transmit antenna connector to the point in time at which this primitive is issued to the MAC. 20.3 Common parameters 20.3.1 Channelization The DMG PHY operates in the channels defined in Annex E and shall support at least channel number 2. 2439 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The channel center frequency is defined as: Channel center frequency = Channel starting frequency + Channel spacing Ã— Channel number where channel starting frequency, channel spacing and channel number are as defined in Annex E. 20.3.2 Transmit mask The transmitted spectrum shall adhere to the transmit spectrum mask shown in the Figure 20-1. The transmit spectrum shall have a 0 dBr (dB relative to the maximum spectral density of the signal) bandwidth not exceeding 1.88 GHz, â€“17 dBr at a 1.2 GHz offset, â€“22 dBr at a 2.7 GHz offset and â€“30 dBr at a 3.06 GHz offset and above, inside the channels allowed for the regulatory domain in which the device is transmitting. The measurement shall be made using a 1 MHz resolution bandwidth and a 300 kHz video bandwidth. The transmit mask shall be measured on data packets longer than 10 Âµs without training fields. -17dBr -22dBr -30dBr -3.06 -2.7 -1.2 -0.94 0.94 1.2 2.7 3.06 (f-fc) GHz Figure 20-1â€”Transmit mask 20.3.3 Common requirements 20.3.3.1 Introduction This subclause describes the common requirement from all four DMG modes: control, SC, OFDM, and low- power SC. In all of the modes, all defined fields are transmitted bit 0 first in time. 20.3.3.2 Center frequency tolerance 20.3.3.2.1 General The transmitter center frequency tolerance shall be Â± 20 ppm maximum. 20.3.3.2.2 Center frequency convergence The transmitter center frequency shall converge to within 1 ppm of its final value within 0.9 Âµs from the start of the packet. 20.3.3.3 Symbol clock tolerance The symbol clock frequency tolerance shall be Â± 20 ppm maximum. The transmit center frequency and the symbol clock frequency shall be derived from the same reference oscillator. 2440 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 20.3.3.4 Transmit center frequency leakage The transmitter center frequency leakage shall not exceed â€“23 dB relative to the overall transmitted power or, equivalently, in OFDM (MCS 13-24), +2.5 dB relative to the average power of a subcarrier, measured over a subcarrier spacing bandwidth. 20.3.3.5 Transmit rampup and rampdown The transmit power-on ramp is defined as the time it takes for a transmitter to rise from less than 10% to greater than 90% of the average power to be transmitted in the frame. The transmit power-on ramp shall be less than 10 ns. The transmit power-down ramp is defined as the time it takes the transmitter to fall from greater than 90% to less than 10% of the maximum power to be transmitted in the frame. The transmit power-down ramp shall be less than 10 ns. 20.3.3.6 Antenna setting Antenna setting shall remain constant for the transmission of the entire packet except for the case of transmission of BRP-TX packets (see 20.10.2.2). During the transmission of BRP-TX packets, it shall remain constant for the transmission of the STF, CE field, and Data field. 20.3.3.7 Maximum input requirement The receiver maximum input level is the maximum power level at the receive antenna(s) of the incoming signal, in dBm, present at the input of the receiver antenna for which the error rate criterion (defined in 20.3.3.8) is met. A receiver shall have a receiver maximum input level at the receive antenna(s) of at least 10 microwatts/cm2 for each of the modulation formats that the receiver supports. 20.3.3.8 Receive sensitivity For MCS 0, the PER shall be less than 5% for a PSDU length of 256 octets with the MCS dependent input levels listed in Table 20-3 defined at the antenna connector(s). For the other MCSs, the PER shall be less than 1% for a PSDU length of 4096 octets with the MCS dependent input levels listed in Table 20-3 defined at the antenna connector(s). NOTEâ€”For RF power measurements performed over the air, the input level shall be corrected to compensate for the antenna gain in the implementation. The gain of the antenna is the maximum estimated gain by the manufacturer. In the case of the phased-array antenna, the gain of the phased-array antenna is the maximum sum of estimated element gain minus 3 dB implementation loss. Table 20-3 assumes 5 dB implementation loss and 10 dB noise factor (Noise Figure). Table 20-3â€”Receiver sensitivity Receive sensitivity MCS (dBm) 0 â€“78 1 â€“68 2 â€“66 3 â€“65 2441 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 20-3â€”Receiver sensitivity (continued) Receive sensitivity MCS (dBm) 4 â€“64 5 â€“62 6 â€“63 7 â€“62 8 â€“61 9 â€“59 9.1 â€“57 10 â€“55 11 â€“54 12 â€“53 12.1 â€“51 12.2 â€“50 12.3 â€“48 12.4 â€“46 12.5 â€“44 12.6 â€“42 13 â€“66 14 â€“64 15 â€“63 16 â€“62 17 â€“60 18 â€“58 19 â€“56 20 â€“54 21 â€“53 22 â€“51 23 â€“49 24 â€“47 25 â€“64 26 â€“60 27 â€“57 28 â€“57 29 â€“57 30 â€“57 31 â€“57 2442 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 20.3.4 Timing-related parameters Table 20-4 defines timing-related parameters. Table 20-4â€”Timing-related parameters Parameter Value NSD: Number of data subcarriers 336 NSP: Number of pilot subcarriers 16 NDC: Number of DC subcarriers 3 NST: Total Number of subcarriers 355 NSR: Number of subcarriers occupying half of the overall BW 177 NGI 64 NSPB 448 F : subcarrier frequency spacing 5.156 25 MHz (2640 MHz / 512) Fs: OFDM sample rate 2640 MHz Fc: SC chip rate 1760 MHz = â…” Fs Ts: OFDM Sample Time 0.38 ns=1 / Fs Tc: SC Chip Time 0.57 ns=1 / Fc TDFT: OFDM IDFT/DFT period 0.194 Âµs TGI: guard interval duration 48.4 ns= TDFT/4 Tseq 72.7 ns=128 Ã— Tc TSTF: Detection sequence duration 1236 ns=17Ã— Tseq TCE: Channel Estimation sequence duration 655 ns=9 Ã— Tseq TSYM: Symbol Interval 0.242 Âµs= TDFT + TGI THEADER: Header Duration 0.242 Âµs=TSYM (OFDM) 0.582 Âµs =2 Ã— 512 Ã— Tc (SC and low-power SC) FCCP: control mode chip rate 1760 MHz TCCP: control mode chip time 0.57 ns = 1 / FCCP TSTF-CP: control mode short training field duration 3.636 Âµs =50 Ã— Tseq TCE-CP: control mode channel estimation field duration 655 ns=9 Ã— Tseq TData NSYM Ã— TSYM (OFDM) (NBLKS Ã— 512 + 64) Ã— Tc (SC) NOTEâ€”NSYM is defined in 20.5.3.2.3.3 and NBLKS is defined in 20.6.3.2.3.3. Table 20-5 defines parameters used frequently in Clause 20. 2443 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 20-5â€”Frequently used parameters Symbol Explanation NCBPS Number of coded bits per symbol N DBPS Number of data bits per symbol N BPSC Number of coded bits per single carrier R Code rate 20.3.5 Mathematical conventions in the signal description 20.3.5.1 General The transmitted signal is described in complex base-band signal notation. The actual transmitted signal is related to the complex baseband signal r t by the following relation: r RF t = Re r t exp j2 f c t where fC is the center frequency of the carrier The transmitted RF signal is generated by modulating the complex baseband signal, which consists of several fields. The fields and the timing boundaries for the various fields are shown in Figure 20-2. Short Training field CE Header Data AGC and TRN subfields tCE t Header tData tTRN Figure 20-2â€”Packet structure The time offset, t Field , determines the starting time of the corresponding field. r PPDU t = r STF t + r CE t â€“ t CE + r Header t â€“ t Header + r Data t â€“ t Data + r TRN t â€“ t TRN where t CE = T STF t Header = t CE + T CE t Data = t Header + T Header t TRN = t Data + T Data Each OFDM base band waveform r Field nT S , for the fields above, is defined via the discrete inverse Fourier transform as: r Field nT S = w TField nT S X k exp j2 k F nT S â€“ T GI k 2444 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications where Xk is the complex constellation point to be transmitted on subcarrier k n is the discrete time index The window w TField nT S is user defined and is used to smooth the transition between fields. The base band waveform for fields defined by time domain sequences or for single carrier transmission is r Field nT C = x n where x n is the constellation point n Conversion from the sampled digital domain to the continuous time domain is beyond the scope of this document. Filtering for pulse shaping such as in GMSK is beyond the scope of this standard. 20.3.5.2 Windowing function The windowing function w TField nT S is used to smooth the transition between adjacent fields in the PPDU where OFDM modulation is employed. See Figure 20-3. No windowing is applied to preamble fields or to SC modulated fields. THeader TSYM STF CE Header Symbol 1 Symbol 2 TR TR Figure 20-3â€”Illustration of windowing function An example of a windowing function is given by â€“TR TR sin --- 1--- + ----- t 2 - --------- t ------ 2 2 TR 2 2 wT t = T T 1 -----R- t T â€“ -----R- 2 2 2 1 tâ€“T T T sin --- --- â€“ ----------- T â€“ -----R- t T + -----R- 2 2 TR 2 2 The transition region creates an overlap (with length TR) between adjacent fields. The field wave form r Field nT S is extended cyclically to fill the part of the transition region in which it is undefined. If the transition region vanishes (i.e., TR=0), the windowing function degenerates to a rectangular window. The choice of windowing function is implementation dependent, as long as transmit EVM and transmit mask requirements are met. 2445 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 20.3.6 Common preamble 20.3.6.1 General The preamble is the part of the PPDU that is used for packet detection, AGC, frequency offset estimation, synchronization, indication of modulation (SC or OFDM) and channel estimation. The format of the preamble is common to both OFDM packets and SC packets and consists of a Short Training field followed by a Channel Estimation field. The content of the Short Training field is the same between SC and OFDM packets (see 20.3.6.2), but the content of the Channel Estimation field is not the same between such packets (see 20.3.6.3). Figure 20-4 illustrates the SC packet preamble, and Figure 20-5 illustrates the OFDM packet preamble. Ga128 Ga128 Ga128 Ga128 Ga128 Ga128 Ga128 -Ga128 Gu512 Gv512 Gv 128 Short Training field (STF) 2176 Tc Channel Estimation field (CEF) 1152 Tc Figure 20-4â€”SC preamble Ga 128 Ga128 Ga128 Ga128 Ga128 Ga128 Ga128 -Ga 128 Gv 512 Gu512 Gv 128 Short Training field (STF) 2176 Tc Channel Estimation field (CEF) 1152 Tc Figure 20-5â€”OFDM preamble 20.3.6.2 Short Training field The Short Training field is composed of 16 repetitions of sequences Ga128(n) of length 128 defined in 20.11, followed by a single repetition of â€“Ga128(n). The waveform for the Short Training field is n Ga 128 n mod 128 exp j --- n = 0 1 16 128 â€“ 1 2 r STF nT c = n â€“ Ga 128 n mod 128 exp j --- n = 16 128 17 128 â€“ 1 2 where mod is the modulus operation 2446 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 20.3.6.3 Channel Estimation field The Channel Estimation field is used for channel estimation, as well as indication of which modulation is going to be used for the packet. The Channel Estimation field is composed of a concatenation of two sequences Gu512(n) and Gv512(n), where the last 128 samples of Gu512(n) and Gv512(n) are equal to the last 128 samples used in the Short Training field. They are followed by a 128 samples sequence Gv128(n) equal to the first 128 samples of both Gv512(n) and Gu512(n). The Gu512 and Gv512 sequences are defined as G u512 = â€“ Gb 128 â€“ Ga Gb â€“ Ga 128 128 128 G v512 = â€“ Gb 128 Ga â€“ Ga 128 128 â€“ Gb 128 where Ga128 and Gb128 are as defined in 20.11 When the data field of the packet is modulated using single carrier, the Gu512 and Gv512 fields are concatenated in the order illustrated in Figure 20-6. When the data field of the packet is modulated using OFDM, the Gu512 and Gv512 fields are concatenated in the order illustrated in Figure 20-7. Gu 512 Gv 512 Gv128 ... Ga 128 Ga 128 Ga 128 -Ga 128 -Gb 128 -Ga 128 Gb 128 -Ga 128 -Gb 128 Ga 128 -Gb 128 -Ga 128 -Gb 128 Short Training field Channel Estimation field Figure 20-6â€”Channel Estimation field for SC packets Gv512 Gu 512 Gv128 ... Ga 128 Ga 128 Ga 128 -Ga 128 -Gb 128 Ga 128 -Gb 128 -Ga 128 -Gb 128 -Ga 128 Gb 128 -Ga 128 -Gb 128 Short Training field Channel Estimation field Figure 20-7â€”Channel Estimation field for OFDM packets The waveform for the channel estimation sequence is n r CESC nT c = Gu 512 n + Gv 512 n â€“ 512 + Gv 128 n â€“ 1024 exp j --- n = 0 1 1151 2 n r CE OFDM nT c = Gv 512 n + Gu 512 n â€“ 512 + Gv 128 n â€“ 1024 exp j --- n = 0 1 1151 2 Note that sequences Gu512(n) and Gv512(n) are defined for 0 â‰¤ n â‰¤ 511. For other values of n, Gu512(n) and Gv512(n) are set to 0. 2447 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 20.3.6.4 Transmission of the preamble and BRP fields in an OFDM packet 20.3.6.4.1 General The preamble sequence defined in the above subclauses and the BRP fields defined in 20.10.2.2.5, 20.10.2.2.6, and 20.10.2.2.7 are specified at the SC chip rate (Tc). For transmission in the OFDM (nominal) sample rate, the signal is resampled with a 3/2 rate change. The resampling is done by upsampling by a factor of 3, filtering by the filter h Filt defined in 20.3.6.4.2, and downsampling by a factor of 2 (see equation below). The resampling is performed using a specific filter h Filt since the OFDM receiver needs to know this filter to correct for its response during channel estimation. To define the transmission of the preamble when the packet is an OFDM packet, the preamble waveform is defined below. Let r preamble nT c = r STF nT c + r CE nT c â€“ t ce , where r CE is r CESC or r CEOFDM as appropriate. Then: T T OFDM 2 r preamble n -----s = r preamble n -----c n = 0 3 6 2 3 0 otherwise Kâ€“1 OFDM 2 Ts OFDM 2 T rÌƒ preamble n ----- = r preamble n â€“ k -----s h Filt k n = 0 1 2 2 K=0 rÌƒ preamble nT s = r OFDM 2 2n T Ts OFDM -----s â€“ K â€“ 1- ---- preamble ------------ - n=0 1 2 2 2 where K is the length of the filter defined in 20.3.6.4.2 OFDM 2 rÌƒ preamble n = 0 for n 0 20.3.6.4.2 hFilt definition The filter h Filt is defined by the following coefficients (from h0 to h70): [-1,0,1,1,-2,-3,0,5,5,-3,-9,-4,10,14,-1,-20,-16,14,33,9,-35,-42,11,64,40,-50,-96,-15,120,126,-62,-256, -148,360,985,1267,985,360,-148,-256,-62,126,120,-15,-96,-50,40,64,11,-42,-35,9,33,14,-16,-20,-1,14,10, 3 h -4,-9,-3,5,5,0,-3,-2,1,1,0,-1]. Normalized to have a norm of 3 so that h Filt k = -------------------k . 70 2 hl l=0 2448 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 20.3.7 HCS calculation for headers of DMG control mode, DMG OFDM mode, and DMG SC mode The header check sequence (HCS) is a CRC of the header bits. The header is considered to be a stream of bits B0,â€¦,BM-1. The CRC is based on CRC 16-CCITT. The value of the CRC field is the 1s complement of 16 CRC D = M D I D D modG D where Mâ€“1 Mâ€“2 M D = B0 D + B1 D + + B M â€“ 1 is the header bits represented as polynomial (over the binary field) where B0 is bit 0 of the header and BM-1 is bit M-1 of the header Mâ€“1 k I D = D is an initialization polynomial added to the first 16 bits of the header (setting the shift k = M â€“ 16 register bits to 1) 16 12 5 G D = D + D + D + 1 is the CRC generating polynomial 15 14 CRC D = x 0 D + x 1 D + x 14 D + x 15 The CRC field is transmitted with x15 first. For a block diagram and an example of how to calculate the CRC, see 15.3.3.7. 20.3.8 Common LDPC parity matrices 20.3.8.1 General Four Low-Density Parity-Check (LDPC) codes are specified, each of a different rate but with a common codeword size of 672 bits. Each of the parity-check matrices H is partitioned into square submatrices of size Z x Z. The submatrices are either cyclic-permutations of the identity matrix, or null submatrices with all zero entries. A location with integer i denotes the cyclic-permutation submatrix Pi obtained from the Z x Z identity matrix by cyclically shifting the columns to the right by i elements. The matrix Po is the Z x Z identity matrix. An empty location denotes a null submatrix of size Z x Z. Examples with Z = 4: 1 0 0 0 0 1 0 0 0 0 0 1 P0 = 0 1 0 0 P = 0 0 1 1 0 P = 1 0 3 0 0 0 0 1 0 0 0 0 1 0 1 0 0 0 0 0 1 1 0 0 0 0 0 1 0 2449 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 20.3.8.2 Rate 1/2 LDPC code matrix H = 336 rows x 672 columns, Z = 42 Table 20-6â€”Rate 1/2 LDPC code matrix (Each nonblank element i in the table is the cyclic permutation matrix Pi of size Z Ã— Z; blank entries represent the zero matrix of size Z Ã— Z) 40 38 13 5 18 34 35 27 30 2 1 36 31 7 34 10 41 27 18 12 20 15 6 35 41 40 39 28 3 28 29 0 22 4 28 27 23 31 23 21 20 12 0 13 22 34 31 14 4 13 22 24 20.3.8.3 Rate 5/8 LDPC code matrix H = 252 rows x 672 columns, Z = 42 Table 20-7â€”Rate 5/8 LDPC code matrix (Each nonblank element i in the table is the cyclic permutation matrix Pi of size Z Ã— Z; blank entries represent the zero matrix of size Z Ã— Z) 20 36 34 31 20 7 41 34 10 41 30 27 18 12 20 14 2 25 15 6 35 41 40 39 28 3 28 29 0 22 4 28 27 24 23 31 23 21 20 9 12 0 13 22 34 31 14 4 22 24 20.3.8.4 Rate 3/4 LDPC code matrix H = 168 rows x 672 columns, Z = 42 Table 20-8â€”Rate 3/4 LDPC code matrix (Each nonblank element i in the table is the cyclic permutation matrix Pi of size Z Ã— Z; blank entries represent the zero matrix of size Z Ã— Z) 35 19 41 22 40 41 39 6 28 18 17 3 28 29 30 0 8 33 22 17 4 27 28 20 27 24 23 37 31 18 23 11 21 6 20 32 9 12 29 0 13 25 22 4 34 31 3 14 15 4 14 18 13 13 22 24 2450 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 20.3.8.5 Rate 13/16 LDPC code matrix H = 126 rows x 672 columns, Z = 42 Table 20-9â€”Rate 13/16 LDPC code matrix (Each nonblank element i in the table is the cyclic permutation matrix Pi of size Z Ã— Z; blank entries represent the zero matrix of size Z Ã— Z) 29 30 0 8 33 22 17 4 27 28 20 27 24 23 37 31 18 23 11 21 6 20 32 9 12 29 10 0 13 25 22 4 34 31 3 14 15 4 2 14 18 13 13 22 24 20.3.9 Scrambler The header and data fields following the scrambler initialization field (including data padding bits) shall be scrambled by XORing each bit in turn with a length 127 periodic sequence generated by the polynomial 7 4 S x = x + x + 1 . The PHY header bits, with the exception of the first seven bits for SC and OFDM and the first five bits for control mode, are placed one after the other, bit 7 first (bit 5 first for DMG control mode). The octets of the PSDU and the pad bits shall be placed into a bit stream with bit 0 (LSB) of each octet first and bit 7 of each octet (MSB) last. The generation of the sequence and the XOR operation are defined in Figure 20-8. Data In x7 x6 x5 x4 x3 x2 x1 Scrambled Data Out Figure 20-8â€”Data scrambler For each PPDU, the transmitter shall select a nonzero seed value for the scrambler (bits x1 through x7). The seed value should be selected in a pseudorandom fashion. The seed value is sent in the Scrambler Initialization field of the PHY header. Each data bit in the data field of the PPDU is then XORed with the scrambler output (x4 x7) and then the scrambler content is shifted once. 20.3.10 Received channel power indicator (RCPI) measurement The RCPI is a measure of the received RF power in the selected channel as measured at the DMG Antenna output. This parameter shall be measured by the PHY of the received RF power in the channel measured over the preamble of the received frame. The RCPI encoding is defined in 15.4.6.6. RCPI shall equal the received RF power with an accuracy of Â± 5 dB with 95% confidence interval within the specified dynamic range of the receiver. The received RF power shall be determined assuming a receiver noise equivalent bandwidth equal to the channel width multiplied by 1.1. The relative error between RF power measurements made within a 1 second interval should be less than Â± 1 dB. 2451 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 20.4 DMG control mode 20.4.1 Introduction Transmission and reception of control mode PPDUs is mandatory. DMG control mode uses the same chip rate as the DMG SC mode. DMG control mode is transmitted when the TXVECTOR indicates MCS 0. The modulation and coding scheme for the DMG control mode is shown in Table 20-10. Table 20-10â€”DMG control mode modulation and coding scheme MCS index Modulation Code rate Data rate 0 DBPSK 1/2a 27.5 Mb/sa aCode rate and data rate might be lower due to codeword shortening. 20.4.2 PPDU format The DMG control mode PPDU is composed of the Preamble, Header, Data field, and possibly AGC and TRN subfields. This is shown in Figure 20-9. Preamble Header Block Data AGC subfields TRN subfields Figure 20-9â€”DMG control mode PPDU format 20.4.3 Transmission 20.4.3.1 Preamble 20.4.3.1.1 General The preamble is the part of the DMG control mode PPDU that is used for packet detection, AGC, frequency offset estimation, synchronization, indication of frame type and channel estimation. The preamble is composed of two parts as shown in Figure 20-10: the Short Training field and the Channel Estimation field. Gb128 Gb128 Gb128 Gb128 ... Gb 128 -Gb128 -Ga128 G U512 G V512 G V128 Short Training field (STF) 6400 T c Channel Estimation field (CEF) 1152 T c Figure 20-10â€”DMG control mode preamble 2452 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 20.4.3.1.2 Short Training field The Short Training field is composed of 48 repetitions of the sequence Gb128(n) of length 128, followed by a single â€“Gb128(n) sequence (for synchronization) and then a single â€“Ga128(n) sequence. The sequences Ga128(n) and Gb128(n) are defined in 20.11. The waveform for the Short Training field is n Gb 128 n mod 128 exp j --- n=0 1 48 128 â€“ 1 2 r STF nT c = n â€“ G b 128 n mod 128 exp j --- n = 48 128 49 128 â€“ 1 2 n â€“ G a 128 n mod 128 exp j --- n = 49 128 50 128 â€“ 1 2 where mod is the modulus operation. Note that sequences Ga128(n) and Gb128(n) are defined for 0â‰¤nâ‰¤127. For other n they are set to 0. 20.4.3.1.3 Channel Estimation field The Channel Estimation field is the same as the Channel Estimation field of the DMG SC mode, as defined in Figure 20-6 of 20.3.6.3. 20.4.3.2 Header 20.4.3.2.1 General In the DMG control mode, the preamble is followed by the header block. The header consists of several fields that define the details of the PPDU to be transmitted. The header fields are described in Table 20-11. Table 20-11â€”DMG control mode header fields Number of Field name Starting bit Description bits Differential encoder 1 0 Used to initialize the differential encoding. initialization Scrambler 4 1 Bits X1â€“X4 of the initial scrambler state. Initialization Length 10 5 Number of data octets in the PSDU. Range 14â€“1023. Packet Type 1 15 As defined in Table 20-17. Training Length 5 16 Length of the training field. The use of this field is defined in 20.10.2.2.3. 2453 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 20-11â€”DMG control mode header fields (continued) Number of Field name Starting bit Description bits Turnaround 1 21 As defined in Table 20-1. Reserved bits 2 22 HCS 16 24 Header Check sequence. Calculation of the header check sequence is defined in 20.3.7. All of the numeric fields are encoded in unsigned binary, least significant bit first. Reserved bits are set to 0 by the transmitter and shall be ignored by the receiver. 20.4.3.2.2 Generation of HCS bits The header check sequence (HCS) is calculated over bits 0-23 and uses CRC 16-CCITT as described in 20.3.7. 20.4.3.2.3 Header encoding and modulation The header bits followed by the HCS bits are prepended to the data field bits and passed into the data field encoder per 20.4.3.3. The minimal payload length is 14 octets. 20.4.3.3 Data field 20.4.3.3.1 General The Data field consists of the payload data of the PSDU. The PSDU is scrambled, encoded, modulated and spread as described in the following subclauses. 20.4.3.3.2 Scrambler The operation of the scrambler is defined in 20.3.9. Bits x1, x2, x3, x4 of the scrambler shift register are initialized using the bits in the scrambler initialization bits from the header, bits x5, x6, x7 are set to 1. The header is scrambled starting from bit 5. The scrambling of the data field continues the scrambling of the header with no reset. 20.4.3.3.3 Encoder The DMG control mode header and data is encoded using an effective LDPC code rate less than or equal to 1/2, generated from the data PHY rate 3/4 LDPC parity check matrix, with shortening. The following steps are used for the encoding: 1) L CWD = 168 is the maximal number of data bits in each LDPC codeword. LHDR=5 is the length of the header (including HCS) in octets. LFDCW=6 is the length of the additional data in the first LDPC codeword in octets. 2) The total (header and additional data) number of bits in the first LDPC codeword is L DPFCW = L HDR + L FDCW 8 = 88 . 2454 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 3) Length â€“ 6 8 The number of LDPC codewords is N CW = 1 + ---------------------------------------- . - L CWD 4) The number of bits in the second and any subsequent LDPC codeword (if present), except the last, is L DPCW = Length â€“ 6 8 . ----------------------------------------- N CW â€“ 1 5) The number of bits in the last LDPC codeword is L DPLCW = Length â€“ 6 8 â€“ N CW â€“ 2 L DPCW . 128 â€“ 6 8 NOTEâ€”For example, if Length = 128 , then N CW = 1 + ------------------------------- = 7 , L DPCW = 163 , and - L CWD L DPLCW = 161 . In the first LDPC block, the 88 bits of L DPFCW consist of 40 header+HCS bits along with 48 bits of the data. 20.4.3.3.4 Modulation The scrambled and coded bit stream is converted into a stream of complex constellation points using differential binary phase shift keying (DBPSK) as follows. The encoded bit stream [c 0 c 1 c 2 c 3 c 4, ] is converted to the nondifferential stream s k = 2c k â€“ 1 . The differential sequence is created by setting d k = s k d k â€“ 1 . For the differential encoding purposes d(â€“1) is defined to be 1. s 0 is the first bit of the encoded header bits. 20.4.3.3.5 Spreading The constellation points are spread using the sequence Ga32(n), which is defined in 20.11. The waveform for the modulated and spread data field is n n r DATA nT c = Ga 32 n mod 32 d ------ exp j --- n = 0 1 2 32 2 where d k is the modulated constellation point k. 20.4.4 Performance requirements 20.4.4.1 Transmit requirements 20.4.4.1.1 Introduction Transmitter performance requirements of the DMG control mode are defined in 20.4.4.1.2. 20.4.4.1.2 Transmit EVM The transmit EVM accuracy test shall be performed by instrumentation capable of converting the transmitted signal into a stream of complex samples, with sufficient accuracy in terms of I/Q arm amplitude and phase balance, dc offsets, phase noise, etc. The instrumentation shall perform carrier lock, symbol timing recovery, and amplitude adjustment while making the measurements. The instrumentation shall incorporate a rake receiver or equalizer to minimize error resulting from multipath. If used, the equalizer 2455 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications shall be trained using information in the preamble (STF and/or CEF). For the DMG control mode EVM, the signal is first de-spread using Ga32. The EVM is then calculated on the resulting symbols according to the formula below: Ns 1 2 2 EVM = 20 log 10 ---------------- Ii â€“ Ii + Qi â€“ Qi N s P avg i=1 where NS is the number of symbols to be measured NS should be greater than 511 P avg is the average power of the constellation (I i,Q i) is the complex coordinates of the measured symbol i (I i ,Q i ) is the complex coordinates of the ideal constellation point for the measured symbol i The test equipment should use a root-raised cosine filter with roll-off factor of 0.25 for the pulse shaping filter when conducting EVM measurement. The transmit pulse shaping used is left to the implementer. The EVM shall not exceed a data-rate dependent value according to Table 20-12. Table 20-12â€”DMG control mode EVM requirements MCS index Description EVM value [dB] 0 DMG control mode â€“6 modulation 20.4.4.2 Receive requirements 20.4.4.2.1 Introduction Subclause 20.4.4.2 describes the performance requirement from the DMG control mode receiver. 20.4.4.2.2 CCA The start of a valid DMG control mode transmission at a receive level greater than -68dBm shall cause CCA to indicate busy with a probability > 90% within 3 Âµs. 20.5 DMG OFDM mode 20.5.1 Introduction Transmission and reception of DMG OFDM mode PPDUs is optional. The use of the DMG OFDM mode is obsolete. Consequently, this option may be removed in a later revision of the standard. 2456 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 20.5.2 PPDU format An OFDM frame is composed of the Short Training field (STF), the channel estimation field (CE), the Header, OFDM symbols and optional training fields (see 20.10.2.2.2), as shown in Figure 20-11. Short Training field CE Header Sym Sym Sym Sym AGC subfields TRN subfields Figure 20-11â€”OFDM frame format 20.5.3 Transmission 20.5.3.1 Header 20.5.3.1.1 General In the DMG OFDM mode, the preamble is followed by the PHY header. The PHY header consists of several fields that define the details of the PPDU being transmitted. The encoding and modulation of the header is described in 20.5.3.1.4. The header fields are described in Table 20-13. Table 20-13â€”DMG OFDM mode header fields Number of Field name Start bit Description bits Scrambler 7 0 Bits X1â€“X7 of the initial scrambler state. Initialization MCS 5 7 Index into the Modulation and Coding Scheme table. Length 18 12 Number of data octets in the PSDU. Range 1â€“262 143. Additional PPDU 1 30 Contains a copy of the parameter ADD-PPDU from the TXVECTOR. A value of 1 indicates that this PPDU is immediately followed by another PPDU with no IFS or preamble on the subsequent PPDU. A value of 0 indicates that no additional PPDU follows this PPDU. Packet Type 1 31 See the definition in Table 20-17. Training Length 5 32 Corresponds to the TXVECTOR parameter TRN-LEN. If the Beam Tracking Request field is 0, the Training Length field indicates the length of the training field. The use of this field is defined in 20.10.2.2.3. A value of 0 indi- cates that no training field is present in this PPDU. If the Beam Tracking Request field is 1 and the Packet Type field is 1, the Training Length field indicates the length of the training field appended to this PPDU. If the Packet Type field is 0, the Training Length field indicates the length of the training field requested for receive training. 2457 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 20-13â€”DMG OFDM mode header fields (continued) Number of Field name Start bit Description bits Aggregation 1 37 Set to 1 to indicate that the PPDU in the data portion of the packet contains an A-MPDU; otherwise, set to 0. Beam Tracking 1 38 Corresponds to the TXVECTOR parameter Request BEAM_TRACKING_REQUEST. Set to 1 to indicate the need for beam tracking (10.38.7); otherwise, set to 0. The Beam Tracking Request field is reserved when the Training Length field is 0. Tone Pairing Type 1 39 Set to 0 to indicate Static Tone Pairing (20.5.3.2.4.6.2); Set to 1 to indicate Dynamic Tone Pairing (20.5.3.2.4.6.3). Only valid if MCS field value is in the range 13 to 17; otherwise reserved. DTP Indicator 1 40 Bit flip used to indicate DTP update. Only valid when the Tone Pairing Type field is 1 and the MCS field value is in the range 13 to 17; otherwise reserved. Last RSSI 4 41 Contains a copy of the parameter LAST_RSSI from the TXVECTOR. The value is an unsigned integer: â€” Values of 2 to 14 represent power levels (â€“71 + value Ã— 2) dBm. â€” A value of 15 represents a power greater than or equal to â€“42 dBm. â€” A value of 1 represents a power less than or equal to â€“68 dBm. Value of 0 indicates that the previous packet was not received a SIFS before the current transmission. Turnaround 1 45 As defined in Table 20-1. Reserved 2 46 HCS 16 48 Header check sequence. Definition of this field calculation is in 20.5.3.1.3. All of the numeric fields are encoded in unsigned binary, least significant bit first. Reserved bits are set to 0 by the transmitter and shall be ignored by the receiver. If the Additional PPDU field is equal to 1, the Training Length field shall be set to 0. 20.5.3.1.2 Modulation and coding scheme The modulation and coding scheme (MCS) field specifies the modulation and code rate used in the PPDU. The modulation and coding schemes for OFDM modulations are defined in Table 20-14. A device that supports OFDM shall support MCSs 13-17 for both transmit and receive. 2458 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 20-14â€”DMG OFDM mode modulation and coding schemes Data rate MCS index Modulation Code rate NBPSC NCBPS NDBPS (Mb/s) 13 SQPSK 1/2 1 336 168 693.00 14 SQPSK 5/8 1 336 210 866.25 15 QPSK 1/2 2 672 336 1386.00 16 QPSK 5/8 2 672 420 1732.50 17 QPSK 3/4 2 672 504 2079.00 18 16-QAM 1/2 4 1344 672 2772.00 19 16-QAM 5/8 4 1344 840 3465.00 20 16-QAM 3/4 4 1344 1008 4158.00 21 16-QAM 13/16 4 1344 1092 4504.50 22 64-QAM 5/8 6 2016 1260 5197.50 23 64-QAM 3/4 6 2016 1512 6237.00 24 64-QAM 13/16 6 2016 1638 6756.75 20.5.3.1.3 Generation of the HCS bits Calculation of the HCS for bits 0â€“47 of the header is defined in 20.3.7. 20.5.3.1.4 Header encoding and modulation The header is encoded using a single OFDM symbol. The bits are scrambled and encoded as follows: 1) The 64 header bits (B1, B2, â€¦, BLH), where LH = 64, are scrambled as described in 20.3.9, starting from the eighth bit, to create q=(q1,q2,â€¦,qLH). 2) The sequence q is padded with 440 zeros to obtain a total of 504 bits, (q1,q2,â€¦,qLH,0LH+1,0LH+2,â€¦0504), which are then encoded using the rate 3/4 LDPC code as described in 20.5.3.2.3.3. 168 parity bits, p1,p2,â€¦,p168, are generated. 3) A sequence c1 is generated as (q1,q2,â€¦,qLH,p9,p10,â€¦p168). 4) A sequence c2 is generated as (q1,q2,â€¦,qLH,p1,p2,â€¦p84, p93,p94,â€¦p168) XORed with a one-time pad sequence generated using the scrambler defined in 20.3.9, with the shift register is initialized to all 1s. 5) A sequence c3 is generated as (q1,q2,â€¦,qLH,p1,p2,â€¦p160) XORed with the continuation of the one- time pad sequence generated in step 4). 6) The sequences c1,c2 and c3 are concatenated to form the 672-bit sequence c=(c1,c2,c3,â€¦,c672)=(c1,c2,c3). 2459 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 7) The 672-bit sequence, c, is then mapped as QPSK as described in 20.5.3.2.4.3, pilots are inserted as described in 20.5.3.2.5 and the resulting sequence d0,d1,...,dSD-1 is modulated as an OFDM symbol as follows: N SR 1 r Header qT s = ------------------- w T SYM qT s D k + p 1 P k exp j2 k F qT s â€“ T GI N Tones k = â€“ N SR where p1 and Pk are defined in 20.5.3.2.5 and Dk is defined in 20.5.3.2.6. 20.5.3.2 Data field 20.5.3.2.1 General The data field consists of the payload data of the PSDU and possible padding. The data are padded with zeros, scrambled, encoded and modulated as described in the following subclauses. The amount of padding is defined in 20.5.3.2.3. 20.5.3.2.2 Scrambler The operation of the scrambler is defined in 20.3.9. The scrambling of the data field continues the scrambling of the header with no reset. 20.5.3.2.3 Encoding 20.5.3.2.3.1 General The data are encoded by a systematic LDPC encoder. LDPC is a block code. Each block of bits (B1, B2,...,Bk) is concatenated with a block of parity bits (p1,p2,â€¦.,pn-k) to create a codeword c=(B1, B2,...,Bk,p1,p2,â€¦.,pn-k) such that HcT=0. H is an (n-k)Ã—n parity check matrix. The block size n is 672 bits. The code rate, R, is equal to k/n. The set of code rates is defined in Table 20-15. The parity check matrices are defined in 20.5.3.2.3.2. The encoding process is defined in 20.5.3.2.3.3. Table 20-15â€”LDPC code rates Code rate Codeword size Number of data bits 1/2 672 336 5/8 672 420 3/4 672 504 13/16 672 546 20.5.3.2.3.2 Parity check matrices See 20.3.8. 2460 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 20.5.3.2.3.3 LDPC encoding process The LDPC encoding process is composed of several steps including determining the number of padding bits, padding with zeros and the coding of every word. 1) First the total number of padding bits NPAD is calculated, using the number of LDPC codeword NCW and the number of OFDM symbols NSYM: N CW = Length --------------------------8- L CW R N CW L CW N SYM = -------------------------- - N CBPS If BRP packet and N SYM aBRPminOFDMblocks ; N SYM = aBRPminOFDMblocks N PAD = R N SYM N CBPS â€“ Length 8 N CBPS Recalculate N CW = N SYM --------------- L CW where LCW=672 is the LDPC codeword length, Length is the length of the PSDU defined in the header field, R is the code rate and NCBPS is the number of code bits per symbol as defined in the MCS table. 2) The PSDU is concatenated with NPAD zeros. They are scrambled using the continuation of the scrambler sequence that scrambled the PSDU. 3) The output stream of the scrambler is broken into blocks of LCWD= RÃ—LCW bits such as the mâ€™th m m m data word is b 1 b2 b LCWD . m m m 4) To each data word, n-k=LCW-RÃ—LCW parity bits p 1 p2 p n â€“k are added to create the T m m m m m m m codeword c = b1 b2 b L CWD p 1 p n â€“ k such that Hc = 0. 5) The codewords are the concatenated one after the other to create the coded bits stream c1 c2 c NSYM NCBPS . 20.5.3.2.4 Modulation mapping 20.5.3.2.4.1 General The coded bits are mapped to complex constellation points for the modulation specified in the MCS as described in the following subclauses. 20.5.3.2.4.2 SQPSK modulation In SQPSK (Spread QPSK) modulation, the input stream is broken into groups of NCBPS bits â€“ c0 q q c1 q c NCBPS â€“1 . Each pair of bits q q N CBPS is converted into a c2k c2k + 1 k = 0 1 -------------- -â€“1 2 q 1 q q complex constellation point d k = ------- 2c 2 k â€“ 1 + j 2c 2 k â€“ 1 . This generates the constellation points 2 2461 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications for half the OFDM subcarriers. For the other subcarriers, d Pq k = conj d kq N CBPS for k = 0 1 --------------- â€“ 1 2 where the indices P(k), in the range NCBPS / 2 to NCBPS â€“ 1, are as defined in 20.5.3.2.4.6. 20.5.3.2.4.3 QPSK modulation q q q a) The input stream is broken into groups of NCBPS bits â€“ c 0 c1 c NCBPS â€“1 . Each group of four q q q q bits c4 k c4 k + 1 c4 k + 2 c4 k + 3 is converted into two complex constellation points q 1 q q q 1 q q x 2 k = ------- 2c 4 k â€“ 1 + j 2c 4 k + 2 â€“ 1 x 2 k + 1 = ------- 2c 4 k + 1 â€“ 1 + j 2c 4 k + 3 â€“ 1 . The block 2 2 q q q x0 x1 x N CBPS is created. --------------- â€“ 1 2 b) Each pair of constellation points q q N SD is converted into x2 k x2 k + 1 k = 0 1 --------- â€“ 1 2 1 = Q x 2 k x 2 k + 1 where the matrix Q = ------- 1 2 and the indices P(k), in the range q q q q dk dP k 5 â€“2 1 NSD / 2 to NSD â€“ 1, are as defined in 20.5.3.2.4.6. c) The output is the stream of blocks q q q d0 d1 d NSD â€“ 1 q = 1 N SYM . 20.5.3.2.4.4 16-QAM modulation q q q The input stream is broken into groups of NCBPS bits c 0 c1 c NCBPS â€“1 . Each group of eight bits q q q q q q q q N SD is c 4 k c 4 k + 1 c 4 k + 2 c 4 k + 3 c 4 k + 2 NSD c 4 k + 1 + 2 NSD c 4 k + 2 + 2 NSD c 4 k + 3 + 2 NSD k = 0 1 2 -------- -â€“1 2 q q converted into two complex constellation points x 2 k x 2 k + 1 such that q 1 q q q x 2 k = ---------- 4c 4 k â€“ 2 â€“ 2c 4 k â€“ 1 2c 4 k + 1 â€“ 1 10 q q q + j 4c 4 k + 2 â€“ 2 â€“ 2c 4 k + 2 â€“ 1 2c 4 k + 3 â€“ 1 and q 1 q q q x 2 k + 1 = ---------- 4c 4 k + 2 NSD â€“ 2 â€“ 2c 4 k + 2 NSD â€“ 1 2c 4 k + 1 + 2 N SD â€“ 1 10 q q q + j 4c 4 k + 2 + 2 NSD â€“ 2 â€“ 2c 4 k + 2 + 2 NSD â€“ 1 2c 4 k + 3 + 2 NSD â€“ 1 2462 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The output is the stream of blocks q q q x0 x1 x NSD â€“ 1 q = 0 1 N SYM â€“ 1 . 20.5.3.2.4.5 64-QAM modulation q q q The input stream is broken into groups of NCBPS bits c 0 c1 c NCBPS â€“1 . The constellation point for the kâ€™th subcarrier in the qâ€™th symbol is q 1 q q q q q q d k = ---------- 8c 6 m â€“ 4 â€“ 2c 6 m â€“ 1 4c 6 m + 1 â€“ 2 + 2c 6 m â€“ 1 2c 6 m + 1 â€“ 1 2c 6 m + 2 â€“ 1 42 1 q q q q q q + j ---------- 8c 6 m + 3 â€“ 4 â€“ 2c 6 m + 3 â€“ 1 4c 6 m + 4 â€“ 2 + 2c 6 m + 3 â€“ 1 2c 6 m + 4 â€“ 1 2c 6 m + 5 â€“ 1 42 m = 112 k mod 3 + --k- k=0 1 N SD â€“ 1 3 NOTEâ€”This mapping provides interleaving between three LDPC codewords on a subcarrier basis. The mapping is shown in Figure 20-12. Q c6kc6k+1c6k+2c6k+3c6k+4c6k+5 000 100 001 100 011 100 010 100 110 100 111 100 101 100 100 100 7 000 101 001 101 011 101 010 101 110 101 111 101 101 101 100 101 5 000 111 001 111 011 111 010 111 110 111 111 111 101 111 100 111 3 000 110 001 110 011 110 010 110 110 110 111 110 101 110 100 110 1 -7 -5 -3 -1 1 3 5 7 I 000 010 001 010 011 010 010 010 110 010 111 010 101 010 100 010 -1 000 011 001 011 011 011 010 011 110 011 111 011 101 011 100 011 -3 000 001 001 001 011 001 010 001 110 001 111 001 101 001 100 001 -5 000 000 001 000 011 000 010 000 110 000 111 000 101 000 100 000 -7 Figure 20-12â€”64-QAM modulation mapping 2463 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 20.5.3.2.4.6 Tone pairing for SQPSK and QPSK 20.5.3.2.4.6.1 General When SQPSK or QPSK modulations are employed in OFDM, bit sequences are mapped to pairs of symbols q q N SD N SD d k d P k where k is in the range 0 k -------- - â€“ 1 and P(k) is in the range -------- - P k N SD â€“ 1 in order 2 2 to exploit frequency diversity. The indices k and P(k) determine which pair of OFDM subcarriers each pair of symbols are carried on. All DMG modes shall support Static Tone Pairing (STP) where a constant mapping between k and P(k) is employed. The PHY header is always encoded using STP. A STA may employ Dynamic Tone Pairing (DTP) where the mapping between k and P(k) are determined by the receiving STA and fed back to the transmitting STA. A STA may use DTP when transmitting to a DTP- capable STA, from which it has received DTP feedback. 20.5.3.2.4.6.2 Static tone pairing (STP) When applied to the payload, STP is indicated by the value 0 in the Tone Pairing Type field in the PHY header. STP is always applied to the PHY header. When STP is applied, the QPSK or SQPSK symbol-pair indices k and P(k) are such that N SD N SD P k = k + -------- - for k = 0 1 2 -------- -â€“1 2 2 20.5.3.2.4.6.3 Dynamic tone pairing (DTP) When applied, DTP is indicated by the value 1 in the Tone Pairing Type field in the PHY header. DTP can be applied only to the payload of a PPDU employing MCS 13-17. When DTP is applied, the SQPSK symbol-pair indices, k and P(k), are such that k N SD P k = ToneIndexOffset ------------ + mod k N TPG for k = 0 1 2 -------- -â€“1 N TPG 2 where NTPG denotes the number of tones per group N SD ToneIndexOffset(l) denotes the starting index of the l-th group of tone pairs, for l = 0 1 2 ----------- -â€“1 N TPG N SD The values of NTPG and ToneIndexOffset(l) for l = 0 1 2 ----------- - â€“ 1 are derived from the DTP Report N TPG element (9.4.2.146) included in the last received DTP Report frame (9.6.20.9). 2464 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The number of tone-pairs per group, NTPG, is derived as N SD N TPG = --------- - 2N G where NG is the number of DTP groups, which is equal to 42 The tone index offsets, ToneIndexOffset(l), are derived as N SD ToneIndexOffset l = N TPG GroupPairIndex l + -------- - 2 where GroupPairIndex(l) is the value of the GroupPairIndex(l) subfield of the DTP Report element 20.5.3.2.5 Pilot sequence Pilot tones are inserted at tones â€“150, â€“130, â€“110, â€“90, â€“70, â€“50, â€“30, â€“10, 10, 30, 50, 70, 90, 110, 130,150. The values of the pilots at these tones is [â€“1, 1, â€“1, 1, 1, â€“1, â€“1, â€“1, â€“1, â€“1, 1, 1, 1, â€“1, 1, 1], respectively. The pilot sequence P is created by creating a sequence of zeros corresponding to tones â€“NSR to NSR. The pilots are then inserted at the corresponding tones with the values specified above. At OFDM symbol n the pilot sequence is multiplied by the value 2Ã—pnâ€“1, where pn is the value generated by the shift register defined in 20.5.3.2.2 if x1,x2,â€¦x7 are all set to 1 at the first OFDM symbol. 20.5.3.2.6 OFDM modulation The stream of complex constellation points dk is broken into groups of NSD points dm,n where m=1,2,â€¦,NSD and n=1,2,â€¦,NSYM. The baseband signal for the data phase is 1 r DATA qT s = ------------------- N Tones N SYM N SR w TSYM qT s â€“ n â€“ 1 T SYM D k n + p n + 1 P k exp j2 k F qT s â€“ n â€“ 1 T SYM â€“ T GI n=1 k = â€“ N SR where pn, P are defined in 20.5.3.2.5 N Tones = N ST â€“ N DC is the number of active subcarriers 2465 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 0 k=0 1 10 30 50 70 90 110 130 150 Dk n = dM k n Otherwise k + 178 â€“ 177 k â€“ 151 k + 177 â€“ 149 k â€“ 131 k + 176 â€“ 129 k â€“ 111 k + 175 â€“ 109 k â€“ 91 k + 174 â€“ 89 k â€“ 71 k + 173 â€“ 69 k â€“ 51 k + 172 â€“ 49 k â€“ 31 k + 171 â€“ 29 k â€“ 11 M k = k + 170 â€“9 k â€“2 k + 167 2 k 9 k + 166 11 k 29 k + 165 31 k 49 k + 164 51 k 69 k + 163 71 k 89 k + 162 91 k 109 k + 161 111 k 129 k + 160 131 k 149 k + 159 151 k 177 The header symbol uses p n with n = 1. 20.5.4 Performance requirements 20.5.4.1 Transmit requirements 20.5.4.1.1 Introduction This subclause describes the performance requirement from the DMG OFDM mode transmitter. 20.5.4.1.2 Transmit EVM The transmit EVM accuracy test shall be performed by instrumentation capable of converting the transmitted signal into a stream of complex samples, with sufficient accuracy in terms of I/Q arm amplitude and phase balance, dc offsets, phase noise, etc. The sampled signal shall be processed in a manner similar to an actual receiver, according to the following steps, or an equivalent procedure: a) Start of frame shall be detected. b) Transition from short sequences to channel estimation sequences shall be detected, and fine timing (with one sample resolution) shall be established. c) Frequency offsets shall be estimated and corrected. d) The frame shall be de-rotated according to estimated frequency offset. e) The complex channel response coefficients shall be estimated for each of the subcarriers using information contained in the preamble (STF and/or CEF). 2466 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications f) For each of the OFDM symbols: transform the symbol into subcarrier received values, estimate the phase from the pilot subcarriers, derotate the subcarrier values according to estimated phase, and divide each subcarrier value with a complex estimated channel response coefficient. g) For subcarrier, compute the Euclidean distance to the ideal location for the symbol, or pilot. h) Compute the RMS average of all errors in a packet. It is given by N SYM 2 2 Nf I i j k â€“I i j k + Q i j k â€“Q i j k 1- ---- j=1 k K -------------------------------------------------------------------------------------------------------------------------------------------------- EVM = 20 log 10 Nf N ST â€“ N DC N SYM P 0 i=1 where Nf is the number of frames i is the frame index k is the carrier index K is the set of pilot and data subcarriers {1,2, â€¦, (NSR â€“ 1), (NSR + NDC), (NSR+NDC+1),â€¦, NST} j is the symbol index N SYM is the number of symbols N ST is the total number of subcarriers I*,Q* is the ideal constellation point for I and Q, respectively P0 is the average power of the constellation (I*,Q*) computed over the ith frame The measurements shall occur only on the OFDM symbols, the measurement shall be performed on at least 10 frames with 16 symbols at least in each of them. Random data shall be used. The EVM RMS error shall not exceed an MCS dependent value as found in Table 20-16. Table 20-16â€”DMG OFDM mode EVM requirements MCS index Modulation Coding rate EVM value [dB] 13 SQPSK 1/2 â€“7 14 SQPSK 5/8 â€“9 15 QPSK 1/2 â€“10 16 QPSK 5/8 â€“11 17 QPSK 3/4 â€“13 18 16-QAM 1/2 â€“15 19 16-QAM 5/8 â€“17 20 16-QAM 3/4 â€“19 21 16-QAM 13/16 â€“20 2467 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 20-16â€”DMG OFDM mode EVM requirements (continued) MCS index Modulation Coding rate EVM value [dB] 22 64-QAM 5/8 â€“22 23 64-QAM 3/4 â€“24 24 64-QAM 13/16 â€“26 20.5.4.1.3 Tx flatness When using the DMG OFDM mode and only while transmitting OFDM symbols, the average energy of the OFDM Symbols constellations in each of the subcarriers with indices â€“146 to â€“2 and +2 to +145 shall deviate no more than Â± 2 dB from their average energy. The average energy of the constellations in each of the subcarriers with indices â€“147 to â€“177 and +147 to +177 shall deviate no more than +2/â€“4 dB from the average energy of subcarriers with indices â€“177 to â€“2 and +2 to +177. 20.5.4.1.4 Time of Departure accuracy The Time of Departure accuracy test evaluates TIME_OF_DEPARTURE against aTxPHYTxStartRMS and aTxPHYTxStartRMS against TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH as defined in Annex P with the following test parameters: 6 â€” MULTICHANNEL_SAMPLING_RATE is 2640 10 sample/s â€” FIRST_TRANSITION_FIELD is Short Training field â€” SECOND_TRANSITION_FIELD is Channel Estimation field â€” TRAINING_FIELD is Channel Estimation field â€” TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH is 80 ns NOTEâ€”The indicated windowing applies to the time of departure accuracy test equipment, and not the transmitter or receiver. 20.5.4.2 Receive requirements 20.5.4.2.1 Introduction Subclause 20.5.4.2 describes the performance requirement for an OFDM receiver. 20.5.4.2.2 CCA The start of a valid DMG OFDM mode or DMG SC mode transmission at a receive level greater than the minimum sensitivity for MCS 1 (â€“68 dBm) shall cause CCA to indicate busy with a probability >90% within 1 Âµs. 20.6 DMG SC mode 20.6.1 Introduction Transmission and reception of DMG SC mode PPDUs is mandatory for selected MCSs. 2468 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 20.6.2 PPDU format A SC frame is composed of the Short Training field (STF), the channel estimation field (CE), the Header, SC blocks and optional training fields, as shown in Figure 20-13. Short Training field CE Header BLK BLK BLK BLK AGC subfields TRN subfields Figure 20-13â€”SC frame format 20.6.3 Transmission 20.6.3.1 Header 20.6.3.1.1 General In the DMG SC mode, the preamble is followed by the header. The header consists of several fields that define the details of the PPDU to be transmitted. The encoding and modulation of the header is described in 20.6.3.1.4. The header fields are described in Table 20-17. Table 20-17â€”DMG SC mode header fields Number Field name Start bit Description of bits Scrambler 7 0 Bits X1â€“X7 of the initial scrambler state. Initialization Base MCS 5 7 Modulation and Coding Scheme (see Table 20-19) Length 18 12 If the Extended SC MCS Indication field is 0, indicates the number of data octets in the PSDU; range 1â€“262 143. If the Extended SC MCS Indication field is 1, the Length field value is set to Base_Length1 â€“ Base_Length2 â€“ N 4 , where N is the number of data octets in the PSDU, and Base_Length1 and Base_Length2 are computed according to Table 20-18. The number of data octets in the PSDU shall not exceed 262 143. Additional PPDU 1 30 Contains a copy of the parameter ADD-PPDU from the TXVEC- TOR. A value of 1 indicates that this PPDU is immediately fol- lowed by another PPDU with no IFS or preamble on the subsequent PPDU. A value of 0 indicates that no additional PPDU follows this PPDU. Packet Type 1 31 Corresponds to the TXVECTOR parameter PACKET-TYPE. â€” Packet Type = 0 (BRP-RX packet, see 20.10.2.2.3), indicates either a PPDU whose data part is followed by one or more TRN subfields (when the Beam Tracking Request field is 0 or in DMG control mode), or a PPDU that contains a request for TRN subfields to be appended to a future response PPDU (when the Beam Tracking Request field is 1). â€” Packet Type = 1 (BRP-TX packet, see 20.10.2.2.3), indicates a PPDU whose data part is followed by one or more TRN sub- fields. The transmitter may change AWV at the beginning of each TRN subfield. The field is reserved when the Training Length field is 0. 2469 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 20-17â€”DMG SC mode header fields (continued) Number Field name Start bit Description of bits Training Length 5 32 Corresponds to the TXVECTOR parameter TRN-LEN. If the Beam Tracking Request field is 0, the Training Length field indicates the length of the training field. The use of this field is defined in 20.10.2.2.3. A value of 0 indicates that no training field is present in this PPDU. If the Beam Tracking Request field is 1 and the Packet Type field is 1, the Training Length field indicates the length of the training field appended to this PPDU. If the Packet Type field is 0, the Training Length field indicates the length of the training field requested for receive training. Aggregation 1 37 Set to 1 to indicate that the PPDU in the data portion of the packet contains an A-MPDU; otherwise, set to 0. Beam Tracking 1 38 Corresponds to the TXVECTOR parameter BEAM_TRACK- Request ING_REQUEST. Set to 1 to indicate the need for beam tracking (10.38.7); otherwise, set to 0. The Beam Tracking Request field is reserved when the Training Length field is 0. Last RSSI 4 39 Contains a copy of the parameter LAST_RSSI from the TXVEC- TOR. The value is an unsigned integer: Values 2 to 14 represent power levels (â€“71+valueÃ—2) dBm. A value of 15 represents a power greater than or equal to â€“42 dBm. A value of 1 represents a power less than or equal to â€“68 dBm. A value of 0 indicates that the previous packet was not received a SIFS before the current transmission. Turnaround 1 43 As defined in Table 20-1. Extended SC 1 44 The Extended SC MCS Indication field combined with the Base MCS Indication MCS field indicates the MCS. The Extended SC MCS Indication field indicates whether the Length field shall be calculated according to Table 20-18. Reserved 3 45 HCS 16 48 Header check sequence All of the numeric fields are encoded in unsigned binary, least significant bit first. Reserved bits are set to 0 by the transmitter and shall be ignored by the receiver. If the Additional PPDU field is equal to 1, the Training Length field shall be set to 0. When the MCS belongs to the set {9.1, 12.1, 12.2, 12.3, 12.4, 12.5, 12.6}, bits (X7, X6) of the initial scrambler state are set to (Base_Length2 â€“ N) mod 4, where N is the number of data octets in the PSDU, and Base_Length2 is computed according to Table 20-18. Bits (X1â€“X5) are selected in a pseudorandom fashion making sure that at least one bit in X1â€“X7 is nonzero. 2470 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications X1â€“X7 are sent in the Scrambler Initialization field, as defined in 20.6.3.1.4, and 20.6.3.2.2. Table 20-18â€”Parameters for computing Length field value in SC header when Extended SC MCS Indication field is set to 1 Base_Length1 Base_Length2 MCS (See NOTEs 1 and 2) (See NOTEs 1 and 3) 9.1 N BLKS 4 N BLKS 56 ------------------------ 42 --------------------------- 68.25 3 39 12.1 N BLKS 4 N BLKS 8 ------------------------ 52.5 ------------------------ 68.25 3 3 12.2 N BLKS 4 N BLKS 112 ------------------------ 63 ------------------------------ 68.25 3 39 12.3 N BLKS 4 ------------------------ 68.25 N BLKS 210 3 12.4 N BLKS 8 ------------------------ 42 N BLKS 252 3 12.5 N BLKS 8 ------------------------ 52.5 N BLKS 273 3 12.6 N BLKS 8 N BLKS 56 ------------------------ 63 --------------------------- 68.25 3 13 NOTE 1â€”NBLKS is the number of symbol blocks defined in 20.6.3.2.3.3. NOTE 2â€”Base_Length1 is the maximum Length value such that the packet with the base MCS specified in SC header has the given NBLKS. NOTE 3â€”Base_Length2 is the maximum number of data octets in PSDU such that the packet with the extended MCS has the given NBLKS. 20.6.3.1.2 Modulation and coding scheme The modulation and coding scheme defines the modulation and code rate that is used in the PPDU. The modulation and coding schemes for SC are defined in Table 20-19. Table 20-19â€”DMG SC mode modulation and coding schemes Extended Base SC MCS Code Data rate MCS MCS Modulation NCBPS Repetition Indication rate (Mb/s) field field 1 1 0 Ï€/2-BPSK 1 2 1/2 385 2 2 0 Ï€/2-BPSK 1 1 1/2 770 3 3 0 Ï€/2-BPSK 1 1 5/8 962.5 2471 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 20-19â€”DMG SC mode modulation and coding schemes (continued) Extended Base SC MCS Code Data rate MCS MCS Modulation NCBPS Repetition Indication rate (Mb/s) field field 4 4 0 Ï€/2-BPSK 1 1 3/4 1155 5 5 0 Ï€/2-BPSK 1 1 13/16 1251.25 6 6 0 Ï€/2-QPSK 2 1 1/2 1540 7 7 0 Ï€/2-QPSK 2 1 5/8 1925 8 8 0 Ï€/2-QPSK 2 1 3/4 2310 9 9 0 Ï€/2-QPSK 2 1 13/16 2502.5 9.1 6 1 Ï€/2-QPSK 2 1 7/8 2695 10 10 0 Ï€/2-16-QAM 4 1 1/2 3080 11 11 0 Ï€/2-16-QAM 4 1 5/8 3850 12 12 0 Ï€/2-16-QAM 4 1 3/4 4620 12.1 7 1 Ï€/2-16-QAM 4 1 13/16 5005 12.2 8 1 Ï€/2-16-QAM 4 1 7/8 5390 12.3 9 1 Ï€/2-64-QAM 6 1 5/8 5775 12.4 10 1 Ï€/2-64-QAM 6 1 3/4 6390 12.5 11 1 Ï€/2-64-QAM 6 1 13/16 7507.5 12.6 12 1 Ï€/2-64-QAM 6 1 7/8 8085 Transmit and receive support for MCS 4 and below is mandatory. Other MCSs are optional. 20.6.3.1.3 Generation of the HCS bits Calculation of the HCS for bits 0â€“47 of the header is defined in 20.3.7. 20.6.3.1.4 Header encoding and modulation The header is encoded using a two SC block of NSPB symbols with NGI guard symbols. The bits are scrambled and encoded as follows: 1) The input header bits (B1, B2, â€¦, BLH), where LH = 64, are scrambled as described in 20.3.9, starting from the eighth bit. to create d1s=(q1,q2,â€¦,qLH) 2) The LDPC codeword c = (q1,q2,â€¦,qLH,01,02,â€¦,0504-LH,p1,p2,â€¦,p168) is created by concatenating 504-LH zeros to the LH bits of d1s and then generating the parity bits p1,p2,â€¦,p168 such that HcT = 0, where H is the parity check matrix for the rate 3/4 LDPC code specified in 20.6.3.2.3.2. 3) Remove bits LH+1 to 504 and bits 665 to 672 of the codeword c to create the sequence cs1=(q1,q2,â€¦,qLH,p1,p2,â€¦,p160). 4) Remove bits LH+1 to 504 and bits 657 to 664 of the codeword c to create the sequence cs2 = (q1,q2,...,qLH,p1,p2,...,p152,p161,p162,...,p168) and then XOR with a PN sequence that is generated 2472 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications from the LFSR used for data scramblings defined in 20.3.9. The LFSR is initialized to the all 1s vector. 5) cs1 and cs2 are concatenated to form the sequence (cs1, cs2). The resulting 448 bits are then mapped as Ï€/2-BPSK as described in 20.6.3.2.4.2. The NGI guard symbols are then prepended to the resulting NCBPB symbols as described in 20.6.3.2.5. The same resulting NCBPB symbols are multiplied by -1 and repeated, and then prepended with NGI guard symbols as described in 20.6.3.2.5. The resulting sequence is then appended after the sequence created in step 5). 20.6.3.2 Data field 20.6.3.2.1 General The data field consists of the payload data of the PSDU and possible padding. The data are padded with zeros, scrambled, encoded and modulated as described in the following subclauses. The amount of padding is defined in 20.6.3.2.3. 20.6.3.2.2 Scrambler The operation of the scrambler is defined in 20.3.9. The scrambling of the PSDU continues the scrambling of the header with no reset of the scrambler. 20.6.3.2.3 Encoding 20.6.3.2.3.1 General The data are encoded by a systematic LDPC encoder. The LDPC is a block code. Each block of information bits (B1, B2,...,Bk) is concatenated with a block of parity bits (p1,p2,â€¦.,pn-k) to create a codeword c=(B1, B2,...,Bk,p1,p2,â€¦.,pn-k) such that HcT=0, where H is the (n-k)Ã—n parity check matrix. The block size n is 672 bits. The code rate, R, is equal to k/n. The set of code rates is defined in Table 20-20. The parity check matrices are defined in 20.6.3.2.3.2. The encoding process is defined in 20.6.3.2.3.3. Table 20-20â€”LDPC code rates Code rate Codeword size Number of data bits 1/2 672 336 5/8 672 420 3/4 672 504 13/16 672 546 7/8 624 546 20.6.3.2.3.2 Parity check matrices See 20.3.8. 2473 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 20.6.3.2.3.3 LDPC encoding process The LDPC encoding process is composed of several steps that includes deciding the number of shortening/ repetition bits in every codeword, the shortening itself, the coding of each word and then any repetition of bits. a) First the total number of data pad bits NDATA_PAD is calculated, using the number of LDPC codewords NCW: Length 8 N CW = ------------------------- L CW ---------- R if BRP packet and N CW N CWmin ; N CW = N CWmin L CW N DATA PAD = N CW --------- - R â€“ Length 8 where LCW is the LDPC codeword length, which is 624 for code rate R=7/8, 672 for all other code rates Length is the length of the PSDU defined in the header field (in octets) is the repetition factor (1 or 2) R is the code rate NCWmin is defined for BRP packets in Table 20-24. The scrambled PSDU is concatenated with NDATA_PAD zeros. They are scrambled using the continu- ation of the scrambler sequence that scrambled the PSDU input bits. b) The procedure for converting the scrambled PSDU data to LDPC codewords depends on the repetition factor. 1) If = 1 and the code rate is not 7/8, i) The output stream of the scrambler is broken into blocks of LCWD = LCW Ã—R bits such that m m m the mth data word is b 1 b2 b LCWD m N CW . m m m ii) To each data word, n-k=LCW-RÃ—LCW parity bits p 1 p2 p n â€“ k are added to create T m m m m m m m the codeword c = b1 b2 b L CWD p 1 p n â€“ k such that Hc = 0 2) If = 1 and the code rate is 7/8, 48 bits are punctured from the parity bits of the rate 13/16 parity bits: i) The output stream of the scrambler is broken into blocks of 546 bits such that the mth data m m m word is b 1 b2 b 546 m N CW . m m m ii) To each data word, 126 parity bits p 1 p2 p 126 are added to create the code word T m m m m m m m m cÌƒ = b1 b2 b 546 p 1 p 126 such that HcÌƒ = 0 . The code word c is m generated from cÌƒ by removing the first 48 parity bits so that m m m m m m m c = b1 b2 b 546 p 49 , p 50 p 126 2474 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 3) If Ï = 2, i) The data bits in each codeword b 1 b 2 b LZ where L Z = L CW 2 are concatenated with L CW 2 zeros to produce a sequence of length of 2LZ b1 b2 b LZ 0 1 0 2 0 LZ . ii) The LDPC codeword c = b 1 b 2 bLZ 0 1 0 2 0 LZ p 1 p 2 p 336 is created by T generating the parity bits p 1 p 2 p 336 such that Hc = 0 , where H is the parity matrix for rate 1/2 LDPC coding specified in 20.3.8. iii) Replace bits L Z + 1 to 336 of the codeword c with bits from the sequence b 1 b 2 bLZ XORed by a PN sequence that is generated from the LFSR used for data scrambling as defined in 20.3.9. The LFSR is initialized to the all 1s vector and reinitialized to the same vector after every codeword. c) The codewords are then concatenated one after the other to create the coded bits stream c1 c2 c LCW NCW . d) The number of symbol blocks, NBLKS, and the number of symbol block padding bits, NBLK_PAD, are calculated: N CW L CW N BLKS = ------------------------ - N CBPB N BLK PAD = N BLKS N CBPB â€“ N CW L CW where NCBPB is the number of coded bits per symbol block, per Table 20-21 in 20.6.3.2.5. e) The coded bit stream is concatenated with NBLK_PAD zeros. They are scrambled using the continuation of the scrambler sequence that scrambled the PSDU input bits. 20.6.3.2.4 Modulation mapping 20.6.3.2.4.1 General The coded and padded bit stream is converted into a stream of complex constellation points according to the modulation specified in the MCS table. 20.6.3.2.4.2 Ï€/2-BPSK modulation In Ï€/2-BPSK modulation, the input bit stream is mapped according to the following equation: sÌƒ k = 2 c k â€“ 1 , where ck is the kth input coded (or scrambled pad) bit. Each output symbol is then rotated j k 2 according to the following equation: s k = sÌƒ k e . The constellation bit encoding for BPSK is depicted in Figure 20-14. NOTEâ€”With appropriate choice of transmit filtering, Ï€/2-BPSK is equivalent to a precoded pulse-shaped MSK (e.g., GMSK). The precoder is simply b out k = b in k b in kâ€“1 k = 0 1 , where bin,k is the scrambled input stream, bin,-1 is 0, bout,k is the input to the (G)MSK modulator. 2475 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications +i 0 1 -1 +1 -i Figure 20-14â€”BPSK constellation bit encoding 20.6.3.2.4.3 Ï€/2-QPSK modulation In Ï€/2-QPSK modulation, the input bit stream is grouped into sets of 2 bits and mapped according to the 1 following equation: sÌƒ k = ------- 2c 2 k â€“ 1 + j 2c 2 k + 1 â€“ 1 exp â€“ j --- , where k is the output symbol index, 2 4 j k 2 k = 0, 1, â€¦. Each output symbol is then rotated according to the following equation: s k = sÌƒ k e . The constellation bit encoding for QPSK is depicted in Figure 20-15. j C(2k)=0,C(2k+1)=1 -1 1 C(2k)=0,C(2k+1)=0 C(2k)=1,C(2k+1)=1 -j C(2k)=1,C(2k+1)=0 Figure 20-15â€”QPSK constellation bit encoding 20.6.3.2.4.4 Ï€/2-16-QAM modulation In Ï€/2-16-QAM modulation, the input bit stream is grouped into sets of 4 bits and mapped according to the following equation: 1 sÌƒ k = ---------- 4c 4 k â€“ 2 â€“ 2c 4 k â€“ 1 2c 4 k + 1 â€“ 1 + j 4c 4 k + 2 â€“ 2 â€“ j 2c 4 k + 2 â€“ 1 2c 4 k + 3 â€“ 1 10 2476 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications where k is the output symbol index, k =0, 1, â€¦. Each output symbol is then rotated according to the j k 2 following equation: s k = sÌƒ k e . The constellation bit encoding for 16-QAM is depicted in Figure 20-16. Q c4kc4k+1c4k+2c4k+3 00 10 01 10 11 10 10 10 3 00 11 01 11 11 11 10 11 1 -3 -1 1 3 I 00 01 01 01 11 01 10 01 -1 00 00 01 00 11 00 10 00 -3 Figure 20-16â€”16-QAM constellation bit encoding 20.6.3.2.4.5 Ï€/2-64-QAM modulation In Ï€/2-64-QAM modulation, the input bit stream is grouped in sets of 6 bits and mapped according to the following equation: sÌƒ k = 1 ---------- 8c 6 k â€“ 4 â€“ 2c 6 k â€“ 1 4c 6 k + 1 â€“ 2 + 2c 6 k â€“ 1 2c 6 k + 1 â€“ 1 2c 6 k + 2 â€“ 1 + 42 j- --------- 8c 6 k + 3 â€“ 4 â€“ 2c 6 k + 3 â€“ 1 4c 6 k + 4 â€“ 2 + 2c 6 k + 3 â€“ 1 2c 6 k + 4 â€“ 1 2c 6 k + 5 â€“ 1 42 where k is the output symbol index, k=0,1, â€¦. Each output symbol is then rotated according to the following j-------k- 2 equation s k = sÌƒ k e . The constellation bit encoding for 64-QAM is depicted in Figure 20-17. 2477 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Q c6kc6k+1c6k+2c6k+3c6k+4c6k+5 000 100 001 100 011 100 010 100 110 100 111 100 101 100 100 100 7 000 101 001 101 011 101 010 101 110 101 111 101 101 101 100 101 5 000 111 001 111 011 111 010 111 110 111 111 111 101 111 100 111 3 000 110 001 110 011 110 010 110 110 110 111 110 101 110 100 110 1 -7 -5 -3 -1 1 3 5 7 I 000 010 001 010 011 010 010 010 110 010 111 010 101 010 100 010 -1 000 011 001 011 011 011 010 011 110 011 111 011 101 011 100 011 -3 000 001 001 001 011 001 010 001 110 001 111 001 101 001 100 001 -5 000 000 001 000 011 000 010 000 110 000 111 000 101 000 100 000 -7 Figure 20-17â€”64-QAM constellation bit encoding 20.6.3.2.5 Symbol blocking and guard insertion Each group of NCBPB bits is prepended by Ï€/2-BPSK symbols generated by the 64 point Golay sequence Ga64 defined in 20.11. NCBPB values are shown in Table 20-21. The starting index for the first symbol for Ï€/2 rotation is 0. Table 20-21â€”Values of NCBPB Symbol mapping NCBPB Ï€/2-BPSK 448 Ï€/2-QPSK 896 Ï€/2-16-QAM 1792 Ï€/2-64-QAM 2688 If the Additional PPDU field within the PHY header is equal to 0, the final block transmitted is followed by the same Golay sequence guard interval. See Figure 20-18. If the Additional PPDU field within the PHY header is equal to 1, the final block transmitted of the last PPDU in an A-PPDU is followed by the same Golay sequence guard interval. 2478 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications GI DATA GI DATA GI DATA GI 64 448 symbols 64 448 symbols 64 448 symbols 64 Figure 20-18â€”Block transmission 20.6.4 Performance requirements 20.6.4.1 Transmit requirements 20.6.4.1.1 Transmit EVM The transmit EVM accuracy test shall be performed by instrumentation capable of converting the transmitted signal into a stream of complex samples, with sufficient accuracy in terms of I/Q arm amplitude and phase balance, dc offsets, phase noise, etc. The instrumentation shall perform carrier lock, symbol timing recovery and amplitude adjustment and equalization while making the measurements. The equalizer shall be trained using information in the SC preamble (STF and/or CEF). For the DMG SC mode EVM, measuring Ns samples at the sample rate, the measured symbols should not contain the first and the last hundred symbols of a given packet (ramp up/ down). The EVM is calculated according to the formula below: Ns 1 2 2 EVM = 20 log 10 ---------------- Ii â€“ Ii â€“ I0 + Qi â€“ Qi â€“ Q0 N s P avg i=1 where Ns is the number of samples to be measured and Ns shall be 1000, Pavg is the average power of the constellation, I i Q i is the complex coordinates of the measured symbol i, I i Qi is the complex coordinates of the ideal constellation point for the measured symbol i, and (Io, Qo) is the complex DC term chosen to minimize EVM. The test equipment should use a root-raised cosine filter with roll-off factor of 0.25 for the pulse shaping filter when conducting EVM measurement. The transmit pulse shaping used is left to the implementer. The relative constellation error (EVM) shall not exceed an MCS dependent value according to Table 20-22. Table 20-22â€”DMG SC mode EVM requirements MCS Modulation Coding rate EVM value [dB] 1 Ï€/2-BPSK 1/2 with repetition â€“6 2 Ï€/2-BPSK 1/2 â€“7 3 Ï€/2-BPSK 5/8 â€“9 4 Ï€/2-BPSK 3/4 â€“10 5 Ï€/2-BPSK 13/16 â€“12 2479 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 20-22â€”DMG SC mode EVM requirements (continued) MCS Modulation Coding rate EVM value [dB] 6 Ï€/2-QPSK 1/2 â€“11 7 Ï€/2-QPSK 5/8 â€“12 8 Ï€/2-QPSK 3/4 â€“13 9 Ï€/2-QPSK 13/16 â€“15 9.1 Ï€/2-QPSK 7/8 â€“16 10 Ï€/2-16-QAM 1/2 â€“19 11 Ï€/2-16-QAM 5/8 â€“20 12 Ï€/2-16-QAM 3/4 â€“21 12.1 Ï€/2-16-QAM 13/16 â€“22 12.2 Ï€/2-16-QAM 7/8 â€“23 12.3 Ï€/2-64-QAM 5/8 â€“26 12.4 Ï€/2-64-QAM 3/4 â€“27 12.5 Ï€/2-64-QAM 13/16 â€“29 12.6 Ï€/2-64-QAM 7/8 â€“31 20.6.4.1.2 Time of Departure accuracy The Time of Departure accuracy test evaluates TIME_OF_DEPARTURE against aTxPHYTxStartRMS and aTxPHYTxStartRMS against TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH as defined in Annex P with the following test parameters: â€” MULTICHANNEL_SAMPLING_RATE is 1760x106 sample/s â€” FIRST_TRANSITION_FIELD is Short Training field â€” SECOND_TRANSITION_FIELD is Channel Estimation field â€” TRAINING_FIELD is Channel Estimation field â€” TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH is 80 ns NOTEâ€”The indicated windowing applies to the time of departure accuracy test equipment, and not the transmitter or receiver. 20.6.4.2 Receive requirements 20.6.4.2.1 Introduction This subclause describes the receiver requirements of the DMG SC mode. 20.6.4.2.2 CCA The start of a valid DMG SC mode transmission at a receive level greater than the minimum sensitivity for MCS 1 (â€“68 dBm) shall cause CCA to indicate busy with a probability > 90% within 1 Âµs. The receiver shall hold the carrier sense signal busy for any signal 20 dB above the minimum sensitivity for MCS 1. 2480 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 20.7 DMG low-power SC mode 20.7.1 Introduction The DMG low-power SC mode is an optional SC mode that can provide lower processing power requirements for DMG transceivers. 20.7.2 Transmission 20.7.2.1 Preamble The DMG low-power SC mode uses the same preamble as the DMG SC mode. 20.7.2.2 Header 20.7.2.2.1 General The DMG low-power SC mode header fields are the same fields as in the DMG SC mode (see Table 20-17 in 20.6.3.1). The DMG low-power SC mode modulation and coding schemes are listed in Table 20-23. Table 20-23â€”DMG low-power SC mode modulation and coding schemes Effective Rate MCS Modulation Coding scheme NCPB code rate (Mb/s) 25 /2-BPSK 13/28 RS(224,208)+Block-Code(16,8) 392 626 26 /2-BPSK 13/21 RS(224,208)+Block-Code(12,8) 392 834 27 /2-BPSK 52/63 RS(224,208)+SPC(9,8) 392 1112 28 /2-QPSK 13/28 RS(224,208)+Block-Code(16,8) 392 1251 29 /2-QPSK 13/21 RS(224,208)+Block-Code(12,8) 392 1668 30 /2-QPSK 52/63 RS(224,208)+SPC(9,8) 392 2224 31 /2-QPSK 13/14 RS(224,208)+Block-Code(8,8) 392 2503 20.7.2.2.2 Header encoding and modulation The DMG low-power SC mode header is encoded and modulated as defined in 20.6.3.1.4. 20.7.2.3 Data field 20.7.2.3.1 General The data field consists of the payload data of the PSDU and possible padding. The data are padded with zeros, scrambled, encoded and modulated as described in the following subclauses. 20.7.2.3.2 Scrambler The operation of the scrambler is defined in 20.3.9. The scrambling of the PSDU continues the scrambling of the header with no reset of the scrambler. The padding bits are also scrambled. 2481 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 20.7.2.3.3 Encoding 20.7.2.3.3.1 General Data is encoded using an outer RS(224,208) block code and a short inner code. The inner code is a (16,8) block code for MCSs 25 and 28, a (12,8) block code for MCSs 26 and 29, and a (9,8) single parity check (SPC) block code for MCSs 27 and 30 and the identity block-code for MCS 31. The encoding is further detailed in the following steps: 1) First, the number of block padding bits is calculated: a) The total number of Reed Solomon codewords is N RS = Length 208 and the total number of RS encoded symbols is given by Length + N RS 16 ; b) After Reed Solomon encoding, the data is encoded with a short block code (N,8) where N can take one of the following values 8, 9, 12, or 16 depending on the MCS as shown in Table 20-23. Therefore: i) The total number of encoded bits is N EB = N Length + N RS 16 ; ii) The total number of 512 (in length) blocks (each containing 392 data symbols) is N BLKS = N EB N CBPS 392 . If BRP packet and N BLKS N BLKS_MIN ; N BLKS = N BLKS_MIN , where N BLKS MIN = 18 . The total number of zero block padding bits is N BLK PAD = N BLKS N CBPS 392 â€“ N EB . 2) The data is broken into blocks of length 208Ã—8 bits (except for possibly the last block). 3) Each block is encoded using the RS(224,208) block code as described in 20.7.2.3.3.2, except perhaps the last block, which is encoded by a shortened version of the code (i.e., if the last block length is K, the shortened block code is RS(16+K,K). 4) The Reed Solomon encoded data stream is further encoded using the block code(N,8) as described in 20.7.2.3.3.3. 5) The coded bit stream is concatenated with N BLK _ PAD zeros. They are scrambled with the continuation of the scrambler sequence that scrambled the PSDU input bits. 6) Each set of 7 octets is interleaved using a uniform interleaver of 7 rows and 8 columns. The 7 octets are written row wise and read column wise, i.e., the index i of a bit after interleaving is related to the index k of a bit before interleaving by the following rule: i = 8 k mod 7 + k 7 k = 0 1 55 . 7) The resulting bit stream is modulated and then blocked as described in 20.7.2.3.4 and 20.7.2.3.5. 20.7.2.3.3.2 RS encoding The RS block code is based on the polynomial 16 k g x = x+a k=1 2 3 4 8 where a = 0x02 is a root of the primitive polynomial p x = 1 + x + x + x + x . We assume that an octet b 0 b 1 b 2 b 3 b 4 b 5 b 6 b 7 (b0 is the LSB) represented by the polynomial 7 6 5 4 3 2 M = b7 x + b6 x + b5 x + b4 x + b3 x + b2 x + b1 x + b0 . 2482 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The RS is a systematic block code. Given a block of octets m = m M â€“ 1 m M â€“ 2 m0 , the additional 15 16 k parity octets r = r 15 r 14 r 0 are calculated by setting r = x m x mod g x , where r x = rk x k=0 Mâ€“1 k 8 and m x = mk x and where the calculation is performed over GF 2 . The parity octets r are k=0 appended to the uncoded block m to generate the encoded RS block m M â€“ 1 m M â€“ 2 m 0 r 15 r 14 r0 . 20.7.2.3.3.3 (N,8) Block-coding Every octet b 1 8 = b 0 b 1 b 2 b 3 b 4 b 5 b 6 b 7 is encoded into an N-bit codeword c 1 N = b1 8 p1 Nâ€“8 such that c 1 N = b1 8G8 N, where the generator matrix G 8 N is given by the following expressions for N = 8, 9, 12, and 16, respectively: G8x8 is the identity matrix. 1 0 0 0 0 0 0 0 1 0 1 0 0 0 0 0 0 1 0 0 1 0 0 0 0 0 1 G8 9 = 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 1 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0 0 0 0 0 0 1 1 0 0 0 1 0 0 0 0 0 0 1 0 1 0 0 0 1 0 0 0 0 0 0 1 0 1 G8 12 = 0 0 0 1 0 0 0 0 0 0 1 1 0 0 0 0 1 0 0 0 1 0 1 1 0 0 0 0 0 1 0 0 1 1 0 1 0 0 0 0 0 0 1 0 1 1 1 0 0 0 0 0 0 0 0 1 0 1 1 1 1 0 0 0 0 0 0 0 0 1 1 0 1 0 1 0 0 1 0 0 0 0 0 0 0 0 1 1 0 1 0 1 0 0 1 0 0 0 0 0 1 0 0 1 1 0 1 0 G8 16 = 0 0 0 1 0 0 0 0 0 1 0 0 1 1 0 1 0 0 0 0 1 0 0 0 1 0 1 0 0 1 1 0 0 0 0 0 0 1 0 0 0 1 0 1 0 0 1 1 0 0 0 0 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 0 0 1 1 1 0 1 0 1 0 0 2483 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 20.7.2.3.4 Modulation The same Ï€/2-BPSK described in 20.6.3.2.4.2 and Ï€/2-QPSK described in 20.6.3.2.4.2 are used in the DMG low-power SC mode. 20.7.2.3.5 Blocking The blocking for the low-power SC is illustrated in Figure 20-19. The data is partitioned into blocks of length 512 wherein each 512-block is constructed from 8 subblocks. Each subblock is of length 64. The first subblock is a G64, which is the Ï€/2-BPSK symbols sequence generated by the 64 point Golay sequence Ga64 defined in 20.11. The starting index for the first symbol Ï€/2 rotation is 0, and subblocks 2 to 8 are constructed in the same way, i.e., a data portion of 56 symbols followed by a guard interval of 8 symbols. Note that each 512-block carries 392 symbols of data and 120 symbols of guard. Sub-block1 Sub-block2 Sub-block3 Sub-block8 Ga64 d56 G8 d56 G8 ... d56 G8 Block -1 512 chips Block -2 512 chips Block -3 512 chips ... Block -N 512 chips Ga64 Figure 20-19â€”Blocking for DMG low-power SC mode If the Additional PPDU field within the PHY header is equal to 0, the final block transmitted is followed by Ga64. If the Additional PPDU field within the PHY header is equal to 1, the final block transmitted of the last PPDU in an A-PPDU is followed by Ga64. The G8 guard interval is a copy of the last 8 samples of Ga64. NOTEâ€”A STA might estimate the channel impulse response from the CEF, and decides whether to equalize using the 512-block or the short 64-subblock. For example, if the channel impulse response energy is almost concentrated in 8 taps, a 64-equalizer can be used; otherwise, a 512-equalizer is used. 20.8 PHY transmit procedure The PHY transmit procedure is shown in Figure 20-20. In order to transmit data, a PHY-TXSTART.request primitive shall be enabled so that the PHY entity shall be in the transmit state. Further, the PHY shall be set to operate at the appropriate frequency through station management via the PLME, as specified in 20.12. Other transmit parameters, such as MCS and transmit power, are set via the PHY SAP with the PHY- TXSTART.request(TXVECTOR) primitive, as described in 20.2.2. Transmission of the PHY preamble may start if TIME_OF_DEPARTURE_REQUESTED is false, and shall start immediately if TIME_OF_DEPARTURE_REQUESTED is true, based on the parameters passed in the PHY-TXSTART.request primitive. 2484 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications PHY-TXSTART.confirm PHY-TXHEADEREND PHY-TXEND.request PHY-TXSTART.request PHY-DATA.request PHY-DATA.request PHY-TXEND.confirm PHY-DATA.confirm PHY-DATA.confirm .indication (TXVECTOR) MPDU Header PSDU Scrambling + encoding Bit Padding IF needed STF + CE Header C-PSDU AGC TRN STF+CE Header Data (Variable length) AGC TRN DMG control mode bits, SC blocks or OFDM symbols Figure 20-20â€”PHY transmit procedure The preamble format (control, SC, or OFDM mode) depend on the MCS in the PHY-TXSTART.request. The PHY shall calculate the length of the packet according the MCS and the length specified in the PHY-TXSTART.request primitive, adding padding bits if necessary. The PHY continues with the encoding and transmission of the header according to the parameters of the PHY-TXSTART.request(TXVECTOR) primitive. The PHY proceeds with PSDU transmission through a series of data octet transfers from the MAC. The data are encoded as described in 20.4.3.2.3, 20.5.3.2.3, and 20.6.3.2.3. The encoded data are then modulated as described in 20.4, 20.5, 20.6, and 20.7, depending on the MCS requested in the PHY-TXSTART.request primitive. Transmission can be prematurely terminated by the MAC through the PHY-TXEND.request primitive. PHY-TXSTART shall be disabled by receiving a PHY-TXEND.request primitive. Transmission of the PSDU is completed with the transmission of the last bits of the (encoded) PSDU. If no TRN-T/R fields are specified in the PHY-TXSTART.request primitive, the PHY shall issue a PHY- TXEND.confirm primitive after the transmission of the last bits. If TRN units are requested in the PHY- TXSTART.request primitive, the transmission continues with the transmission of AGC subfields and TRN units. The PHY issues the PHY-TXEND.confirm primitive to the MAC after the transmission of the last TRN unit. The packet transmission shall be completed, and the PHY entity shall enter the receive state (i.e., PHY-TXSTART shall be disabled). Each PHY-TXEND.request primitive is acknowledged with a PHY- TXEND.confirm primitive from the PHY. A typical transmit state machine is shown in Figure 20-21. 2485 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Initialize MCS=0 Set TX parameters MCS>0 Tx DMG SC/ Tx DMG control OFDM mode STF mode STF 120 Length >0 Prepare OFDM Prepare SC data Tx CP header data Get PSDU Octet Get PSDU Octet Encode and Decrement Octets Decrement Octets Transmit CP in CW in CW header word. Decrement Length Decrement Length CW Zero Pad CW Zero Pad Prepare CP data Pad with zeros to Pad with zeros to Get PSDU Octet Ncs>0 a full CW if Ncw>1 a full CW if Ncw>0 Decrement Length necessary necessary TX OFDM Data TX SC Data TX CP data Encode and TX Encode and TX Encode and OFDM LDPC code SC LDPC code transmit CP LDPC word, decrement Ncw>1 word, decrement code word. NCW NCW Decrement Ncw Ncw=0 Ncw=0 BLK Zero Pad Pad with zeros to a full SC blk if necessary Switch RX state Figure 20-21â€”Typical Tx state machine (Training Length = 0 is assumed; some optional features such as DMG SC low-power mode are not shown) 2486 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 20.9 PHY receive procedure A typical PHY receive procedure is shown in Figure 20-22. CS/CCA state RX state PHY_RXSTART.indication PHY_RXEND.indication PHY_CCA.indication PHY_DATA.indication PHY_DATA.indication PHY_CCA.indication (STATE=busy) (RXVECTOR) (NoError) (IDLE) MPDU Header PSDU Decoded and descrambled Issued at the same time Bit Padding Header Câ€PSDU IF needed Determine PHY type Measure Channel Measure RSSI STF CE Header Data (Variable length) AGC TRN DMG Control mode bits, SC blocks or OFDM symbols Figure 20-22â€”PHY receive procedure Upon receiving the STF, the PHY measures signal strength. This activity is indicated by the PHY to the MAC by issuing a PHY-CCA.indication(BUSY) primitive. After the PHY-CCA.indication(BUSY) primitive is issued, the PHY entity shall search for the CE field and begin receiving the CE field. The PHY demodulates the header according to the PHY type determined the reception of the CE field. If the CE field indicated a SC mode, the receiver is capable of receiving low- power SC mode, and dot11LowPowerSCPHYActivated is true, then the PHY shall attempt to demodulate both a SC header and an SC low-power header. The PHY shall decode the header and determine the MCS, length and other parameters needed for the demodulation of the packet. Subsequently, if dot11TimingMsmtActivated is true, a PHY-RXSTART.indication(RXVECTOR) primitive shall be issued and RX_START_OF_FRAME_OFFSET parameter within the RXVECTOR shall be forwarded (see 20.2.2). NOTEâ€”The RX_START_OF_FRAME_OFFSET value is used as described in 6.3.57 in order to estimate when the start of the preamble for the incoming frame was detected on the medium at the receive antenna connector. At the end of the data portion of a packet that has the Training Length field in the PHY header equal to 0, the PHY shall issue a PHY-RXEND.indication(No_Error) primitive to the MAC. If the Training Length field in the PHY header is greater than 0, the PHY shall continue to receive these training fields after the data 2487 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications portion of the packet and measure the channel. After the end of the training fields, the PHY shall generate a PHY-CCA.indication(IDLE) primitive and the PHY-RXEND.indication(NoError) primitive. In the case of signal loss before the decoding of the header or in the case of an invalid header, the PHY shall not generate a PHY-CCA.indication(IDLE) primitive until the received level drops below a value that is 20 dB higher than the receive sensitivity of MCS 1. In the case of signal loss after decoding of a valid header, the PHY shall not generate a PHY-CCA.indication(IDLE) primitive until the expected end of the packet, including AGC and TRN fields. A typical receive state machine is shown in Figure 20-23. 20.10 Beamforming 20.10.1 Beamforming concept Beamforming enables a pair of STAs to train their transmit and receive antennas for subsequent communication. A beamformed link is established following the successful completion of BF training, which is described in 10.38. DMG STAs use a quasi-omni antenna pattern. The antenna gain of the main beam of a quasi-omni antenna pattern shall be at most 15 dB lower than the antenna gain in the main beam for a directional pattern. 20.10.2 Beamforming frame format 20.10.2.1 Sector-level sweep PPDUs transmitted during transmit sector sweep are DMG control mode PPDUs. PPDUs transmitted during receive sector sweep are DMG control mode or DMG SC mode PPDUs. 20.10.2.2 Beam refinement 20.10.2.2.1 General Beam refinement is a process where a STA can improve its antenna configuration (or antenna weight vectors) both for transmission and reception. If the SLS beamforming training did not include an RSS, as in the case where both devices have more than one transmit sector per antenna, beam refinement can serve as the first receive antenna configuration training. The procedure of beam refinement is described in 10.38.6.4. In the beam refinement procedure, BRP packets are used to train the receiver and transmitter antenna. There are two types of BRP packets: BRP-RX packets and BRP-TX packets: â€” BRP-RX packets are packets that have TRN training subfields appended to them. These packets enable receiver antenna weight vector training. â€” BRP-TX packets are packets that have TRN training subfields appended to them. The transmitting STA may change antenna configuration at the beginning of each subfield. The receiving STA per- forms measurements on these subfields and sends feedback to the STA that transmits the BRP-TX packet. 20.10.2.2.2 BRP packet structure The TRN-LEN parameter in the TVXVECTOR or RXVECTOR of a BRP packet shall be greater than zero. If the PACKET-TYPE parameter in the RXVECTOR or TXVECTOR is equal to TRN-R-PACKET, then the BEAM_TRACKING_REQUEST parameter in the corresponding RXVECTOR or TXVECTOR shall be set to Beam Tracking Not Requested. 2488 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Rx Idle DMG control mode STF CCA/CS DMG SC/OFDM mode STF Bad CRC SC/OFDM STF CP CCA STF Detect CE type Process CEF SC CEF OFDM CEF PHY-CCA.indication (IDLE) Rx OFDM Rx CP Header Rx SC Header Header BLK Bad CRC Bad CRC Check CRC Check CRC Check CRC PHY-CCA.indication (IDLE) CRC OK CRC OK CRC OK Rx OFDM End of Packet Header Nbit=0 Rx SC Header Wait Rx Bit TRN Length>0 Wait until End of Decrement Supported MCS Supported MCS Packet Time Coded bit counter Unsupported MCS Signal Lost Nbits>0 Nbit=0 PHY-RXEND.indication TRN Length>0 Rx Symbol Rx BLK (Carrier Lost) Signal Lost Signal Lost Sym CNT>0 BLK CNT>0 Decode Symbol Decode BLK Decode and Decode and Descramble. Descramble. Decrement Length Decrement Length Sym CNT=0 BLK CNT=0 TRN Length>0 TRN Length>0 TRN Process AGC and TRN-R/T fields. SYM CNT=0 BLK CNT=0 TRN Length=0 TRN Length=0 Nbit=0 End of PSDU TRN Length=0 PHY-RXEND.indica- tion (No_error) PHY-CCA.indication (IDLE) Figure 20-23â€”Typical Rx state machine (some optional features such as DMG low-power SC mode are not shown) 2489 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Each BRP packet is composed of an STF, a CE field, and a data field followed by a training field containing an AGC training field and a TRN field. This is shown in Figure 20-24. STF STF CE CE Header Header Data Data AGC AGC TRN TRN field field TRN TRN TRN TRN TRN TRN TRN TRN TRN TRN TRN TRN TRN TRN TRN TRN CE CE CE CE subfield subfield subfield subfield subfield subfield subfield subfield subfield subfield subfield subfield subfield subfield subfield subfield TRN-Unit Figure 20-24â€”BRP packet structure 20.10.2.2.3 BRP packet header fields The Packet Type and Training Length fields present within the SC mode header, control mode header, LP SC mode header, and OFDM mode header are used to indicate that a packet is BRP packet and the length of the training fields, respectively. A value of 0 in the Packet Type field and a value of 0 in the Beam Tracking Request field indicate a BRP- RX packet. A value of 1 in the Packet Type field indicates a BRP-TX packet. A value of N in the Training Length field indicates 4Ã—N AGC subfields and that the TRN-R/T field has N TRN-Units. The value N in the Training Length field of a BRP-RX packet is equal to the value of the L-RX field requested by the intended receiver of the BRP-RX packet at a previously received BRP Request field (see 9.5.4). 20.10.2.2.4 BRP packet duration The minimum duration of the data field of a BRP packet when sent in an SC mode is aBRPminSCblocks SC blocks (see 20.6.3.2.5) and, if needed, the data field of the packet shall be extended by extra zero padding to generate the required number of SC blocks. Table 20-24 contains the values of NCWmin for each MCS necessary to compute the padding described in 20.6.3.2.3.3. The minimum duration of the data field of a BRP packet when sent in an DMG OFDM mode is aBRPminOFDMblocks OFDM blocks and, if needed, the data field of the packet shall be extended by extra zero padding to generate the required number of OFDM symbols. The minimum duration of the data field of a BRP packet when sent with the low-power SC mode is NBLKS_MIN low-power SC blocks (see 20.7.2.3.3). 2490 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 20-24â€”Zero filling for DMG SC mode BRP packets Data rate MCS index Modulation NCBPS Repetition Code rate NCWmin (Mb/s) 1 Ï€/2-BPSK 1 2 1/2 385 12 2 Ï€/2-BPSK 1 1 1/2 770 12 3 Ï€/2-BPSK 1 1 5/8 962.5 12 4 Ï€/2-BPSK 1 1 3/4 1155 12 5 Ï€/2-BPSK 1 1 13/16 1251.25 12 6 Ï€/2-QPSK 2 1 1/2 1540 23 7 Ï€/2-QPSK 2 1 5/8 1925 23 8 Ï€/2-QPSK 2 1 3/4 2310 23 9 Ï€/2-QPSK 2 1 13/16 2502.5 23 9.1 Ï€/2-QPSK 2 1 7/8 2695 25 10 Ï€/2-16-QAM 4 1 1/2 3080 46 11 Ï€/2-16-QAM 4 1 5/8 3850 46 12 Ï€/2-16-QAM 4 1 3/4 4620 46 12.1 Ï€/2-16-QAM 4 1 13/16 5005 46 12.2 Ï€/2-16-QAM 4 1 7/8 5390 49 12.3 Ï€/2-64-QAM 6 1 5/8 5775 69 12.4 Ï€/2-64-QAM 6 1 3/4 6930 69 12.5 Ï€/2-64-QAM 6 1 13/16 7507.5 69 12.6 Ï€/2-64-QAM 6 1 7/8 8085 74 20.10.2.2.5 AGC field The beam refinement AGC fields are composed of 4N repetitions of the sequence [Ga64 Ga64 Ga64 Ga64 Ga64] when the packet is transmitted using the OFDM or SC mode and [Gb64 Gb64 Gb64 Gb64 Gb64] when the packet is transmitted using the control mode. The sequences Ga64 and Gb64 are defined in 20.11. The sequences are transmitted using rotated Ï€/2-BPSK modulation. Any transmit signal transients that occur due to this TX AWV configuration change shall completely settle by the end of the first Ga64 or Gb64 subsequence. In a BRP-TX packet, the transmitter may change the TX AWV configuration at the beginning of each AGC subfield. The set of AWVs used for the AGC subfields should be the same as that used for the TRN-T subfields. In a BRP-RX packet, the transmitter shall use the same TX AWV as in the preamble and data fields of the packet. 20.10.2.2.6 TRN field The TRN field enable transmitter and receiver AWV training. The TRN field has the form shown in Figure 20-25. 2491 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications CE TRN1 TRN2 TRN3 TRN4 CE TRN5 TRN6 TRN7 TRN8 â€¦ TRN-Unit TRN-Unit Figure 20-25â€”TRN field definition The TRN field is composed of N TRN-Units. Each TRN-Unit is composed of a CE subfield and 4 TRN subfields. Each subfield CE matches the Channel Estimation field defined in 20.3.6.3. The 4N subfields TRN1 through TRN4N each consist of the sequence [Ga128 â€“Gb128 Ga128 Gb128 Ga128]. The sequences Ga128 and Gb128 are defined in Table 20-25 and Table 20-26, respectively, in 20.11. The sequences are transmitted using rotated Ï€/2-BPSK modulation. In a BRP-RX packet, all of the TRN and CE subfields are transmitted using the same AWV as the preamble and data field of the packet. In a BRP-TX packet, the CE subfield shall be transmitted using the same AWV as the preamble and data field of the packet. In a BRP-TX packet, the transmitter may change AWV at the beginning of each TRN subfield. Any transmit signal transients that occur due to TX AWV configuration changes at the beginning of TRN subfields shall settle by the end of the first 64 samples of the subfield. 20.10.2.2.7 Channel measurement The good autocorrelation properties of the Golay sequence enable reconstructing part of the impulse response of the channel between the transmitter and the receiver. The receiver should find the tap with largest amplitude in the channel during the CE field of the BRP-RX. It selects thereafter the set of taps that is measured around the tap with the largest amplitude, according to dot11ChanMeasFBCKNtaps. It can select a contiguous set of taps or select a noncontiguous set of taps, and include the tap delays subfield as part of the subfield measurement. It then measures the phase and amplitude of the corresponding channel taps in each of the TRN-T field repetition (except for those using the CE AWV configuration). The beam refinement feedback subfield k-1 is the relative amplitude and phase of this tap in the kâ€™th repetition compared to this tap in the first TRN-T subfield. 20.10.2.2.8 BRP resampling in an OFDM packet The BRP AGC, CE, and Tn/Rn fields are specified at the SC chip rate (Tc). When appended to an OFDM packet, the signal is resampled as defined in 20.3.3.2. 20.11 Golay sequences The following Golay sequences are used in the preamble, in the single carrier guard interval and in beam refinement TRN-R/T and AGC fields: Ga128(n), Gb128(n), Ga64(n), Gb64(n), Ga32(n), Gb32(n). These are 3 pairs of complementary sequences. The subscript denotes the length of the sequences. These sequences are generated using the following recursive procedure: A0 n = n B0 n = n Ak n = Wk Ak â€“ 1 n + Bk â€“ 1 n â€“ Dk Bk n = Wk Ak â€“ 1 n â€“ Bk â€“ 1 n â€“ Dk k Note that A k n B k n are zero for n < 0 and for n 2 . 2492 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Ga128(n)=A7(128-n), Gb128(n)=B7(128-n) when the procedure uses Dk = [1 8 2 4 16 32 64] (k=1,2,â€¦,7) and Wk = [â€“1 â€“1 â€“1 â€“1 +1 â€“1 â€“1]. Ga64(n)=A6(64-n), Gb64(n)=B6(64-n) when the procedure uses Dk= [2 1 4 8 16 32] and Wk =[1 1 -1 -1 1 -1]. Ga32(n)=A5(32-n), Gb32(n)=B5(32-n) when the procedure uses Dk=[1 4 8 2 16] and Wk =[-1 1 -1 1 -1]. The sequences are defined in Table 20-25, Table 20-26, Table 20-27, Table 20-28, Table 20-29, and Table 20-30. The sequences in the tables are normative, the description above is informative. Table 20-25â€”The sequence Ga128(n) The Sequence Ga128(n), to be transmitted from left to right, up to down +1 +1 -1 -1 -1 -1 -1 -1 -1 +1 -1 +1 +1 -1 -1 +1 +1 +1 -1 -1 +1 +1 +1 +1 -1 +1 -1 +1 -1 +1 +1 -1 -1 -1 +1 +1 +1 +1 +1 +1 +1 -1 +1 -1 -1 +1 +1 -1 +1 +1 -1 -1 +1 +1 +1 +1 -1 +1 -1 +1 -1 +1 +1 -1 +1 +1 -1 -1 -1 -1 -1 -1 -1 +1 -1 +1 +1 -1 -1 +1 +1 +1 -1 -1 +1 +1 +1 +1 -1 +1 -1 +1 -1 +1 +1 -1 +1 +1 -1 -1 -1 -1 -1 -1 -1 +1 -1 +1 +1 -1 -1 +1 -1 -1 +1 +1 -1 -1 -1 -1 +1 -1 +1 -1 +1 -1 -1 +1 Table 20-26â€”The sequence Gb128(n) The Sequence Gb128(n), to be transmitted from left to right, up to down -1 -1 +1 +1 +1 +1 +1 +1 +1 -1 +1 -1 -1 +1 +1 -1 -1 -1 +1 +1 -1 -1 -1 -1 +1 -1 +1 -1 +1 -1 -1 +1 +1 +1 -1 -1 -1 -1 -1 -1 -1 +1 -1 +1 +1 -1 -1 +1 -1 -1 +1 +1 -1 -1 -1 -1 +1 -1 +1 -1 +1 -1 -1 +1 +1 +1 -1 -1 -1 -1 -1 -1 -1 +1 -1 +1 +1 -1 -1 +1 +1 +1 -1 -1 +1 +1 +1 +1 -1 +1 -1 +1 -1 +1 +1 -1 +1 +1 -1 -1 -1 -1 -1 -1 -1 +1 -1 +1 +1 -1 -1 +1 -1 -1 +1 +1 -1 -1 -1 -1 +1 -1 +1 -1 +1 -1 -1 +1 Table 20-27â€”The sequence Ga64(n) The Sequence Ga64(n), to be transmitted from left to right, up to down -1 -1 +1 -1 +1 -1 -1 -1 +1 +1 -1 +1 +1 -1 -1 -1 -1 -1 +1 -1 +1 -1 -1 -1 -1 -1 +1 -1 -1 +1 +1 +1 -1 -1 +1 -1 +1 -1 -1 -1 +1 +1 -1 +1 +1 -1 -1 -1 +1 +1 -1 +1 -1 +1 +1 +1 +1 +1 -1 +1 +1 -1 -1 -1 Table 20-28â€”The sequence Gb64(n) The sequence Gb64(n), to be transmitted from left to right, up to down +1 +1 -1 +1 -1 +1 +1 +1 -1 -1 +1 -1 -1 +1 +1 +1 +1 +1 -1 +1 -1 +1 +1 +1 +1 +1 -1 +1 +1 -1 -1 -1 -1 -1 +1 -1 +1 -1 -1 -1 +1 +1 -1 +1 +1 -1 -1 -1 +1 +1 -1 +1 -1 +1 +1 +1 +1 +1 -1 +1 +1 -1 -1 -1 Table 20-29â€”The sequence Ga32(n) The Sequence Ga32(n), to be transmitted from left to right +1 +1 +1 +1 +1 -1 +1 -1 -1 -1 +1 +1 +1 -1 -1 +1 +1 +1 -1 -1 +1 -1 -1 +1 -1 -1 -1 -1 +1 -1 +1 -1 Table 20-30â€”The sequence Gb32(n) The Sequence Gb32(n), to be transmitted from left to right -1 -1 -1 -1 -1 +1 -1 +1 +1 +1 -1 -1 -1 +1 +1 -1 +1 +1 -1 -1 +1 -1 -1 +1 -1 -1 -1 -1 +1 -1 +1 -1 2493 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 20.12 DMG PLME 20.12.1 PLME SAP sublayer management primitives Table 20-31 lists the MIB attributes that may be accessed by the PHY entities and the intra-layer of higher level LMEs. These attributes are accessed via the PLME-GET, PLME-SET, PLME-RESET, and PLME- CHARACTERISTICS primitives defined in 6.5. 20.12.2 DMG PHY MIB All DMG PHY MIB attributes are defined in Annex C, with specific values defined in Table 20-31. The column titled â€œOperational semanticsâ€ in Table 20-31 contains two types: static and dynamic. Static MIB attributes are fixed and cannot be modified for a given PHY implementation. Dynamic MIB attributes can be modified by some management entity. Table 20-31â€”DMG PHY MIB attribute default values Default Operational Managed object value/range semantics dot11PHYOperationTable dot11PHYtype DMG Static dot11PHYDMGTable dot11LowPowerSCPHYImplemented Boolean Static dot11LowPowerSCPHYActivated Boolean Dynamic 20.12.3 TXTIME calculation The value of the TXTIME parameter returned by the PLME-TXTIME.confirm primitive shall be calculated according to the following equations. For the DMG OFDM mode and for the DMG SC mode (NTRN is Training Length field defined in the header â€“ see, for example, Table 20-13): TXTIME T STF + T CE + T header + T Data N TRN = 0 = T STF + T CE + T header + max T Data + T C + N TRN T TRN â€“ Unit N TRN 0 and SC T STF + T CE + T header + max T Data T SYM + N TRN T TRN â€“ Unit N TRN 0 and OFDM where Î± = aBRPminSCblocks Î² = aSCBlockSize Î³ = aSCGILength Î´ = aBRPminOFDMblocks T TRN â€“ Unit = aBRPTRNBlock T C 2494 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications For the DMG control mode: TXTIME = T STF â€“ CP + T CE â€“ CP + 11 8 + Length â€“ 6 8 + N CW 168 TC 32 + N TRN T TRN â€“ Unit where NCW calculation is defined in 20.4.3.3.3. 20.12.4 DMG PHY The static DMG PHY characteristics, provided through the PLME-CHARACTERISTICS service primitive, shall be as shown in Table 20-32. The definitions for these characteristics are given in 6.5.4. Table 20-32â€”DMG PHY characteristics PHY parameter Value aRIFSTime 1 Âµs aSIFSTime 3 Âµs aRxPHYDelay Implementation dependent, see 10.3.7. aRxTxTurnaroundTime Implementation dependent, see 10.3.7. aCCATime Implementation dependent, see 10.3.7. aRxTxSwitchTime Implementation dependent, see 10.3.7. aRxPHYStartDelay DMG control mode: 10 Âµs; DMG SC and SC low- power modes: 3.6 Âµs; DMG OFDM mode: 3.3 Âµs aMACProcessingDelay Implementation dependent, see 10.3.7. aTxPHYDelay Implementation dependent, see 10.3.7. aTxRampOnTime Implementation dependent, see 10.3.7. aDataPreambleLength 1891 ns aControlPHYPreambleLength 4291 ns aSBIFSTime 1 Âµs aSBIFSAccuracy 0.03 Âµs aAirPropagationTime 100 ns aDMGDetectionThres â€“48 dBm aBRPIFS 40 Âµs aSlotTime 5 Âµs aCWmin 15 aCWmax 1023 aBRPminSCblocks 18 aBRPminOFDMblocks 20 aBRPTRNBlock 4992 2495 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 20-32â€”DMG PHY characteristics (continued) PHY parameter Value aSCGILength 64 aSCBlockSize 512 aPPDUMaxTime 2 ms aPSDUMaxLength 262 143 octets 2496 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 21. Very high throughput (VHT) PHY specification 21.1 Introduction 21.1.1 Introduction to the VHT PHY Clause 21 specifies the PHY entity for a very high throughput (VHT) orthogonal frequency division multiplexing (OFDM) system. In addition to the requirements in Clause 21, a VHT STA shall be capable of transmitting and receiving PPDUs that are compliant with the mandatory PHY specifications defined in Clause 19. The VHT PHY is based on the HT PHY defined in Clause 19, which in turn is based on the OFDM PHY defined in Clause 17. The VHT PHY extends the maximum number of space-time streams supported to eight and provides support for downlink multi-user (MU) transmissions. A downlink MU transmission supports up to four users with up to four space-time streams per user with the total number of space-time streams not exceeding eight. NOTEâ€”MU transmission is different from VHT SU group addressed transmission. The VHT PHY provides support for 20 MHz, 40 MHz, 80 MHz, and 160 MHz contiguous channel widths and support for 80+80 MHz noncontiguous channel width. The VHT PHY data subcarriers are modulated using binary phase shift keying (BPSK), quadrature phase shift keying (QPSK), 16-quadrature amplitude modulation (16-QAM), 64-QAM, and 256-QAM. Forward error correction (FEC) coding (convolutional or LDPC coding) is used with coding rates of 1/2, 2/3, 3/4, and 5/6. A VHT STA shall support the following features: â€” Non-HT and non-HT duplicate formats (transmit and receive) for all channel widths supported by the VHT STA â€” HT-mixed format (transmit and receive) â€” VHT format (transmit and receive) â€” 20 MHz, 40 MHz, and 80 MHz channel widths â€” Single spatial stream VHT-MCSs 0 to 7 (transmit and receive) in all supported channel widths â€” Binary convolutional coding A VHT STA may support the following features: â€” HT-greenfield format (transmit and receive) â€” 2 or more spatial streams (transmit and receive) â€” 400 ns short guard interval (transmit and receive) â€” Beamforming sounding (by sending a VHT NDP) â€” Responding to transmit beamforming sounding (by providing compressed beamforming feedback) â€” STBC (transmit and receive) â€” LDPC (transmit and receive) â€” VHT MU PPDUs (transmit and receive) â€” Support for 160 MHz channel width â€” Support for 80+80 MHz channel width â€” VHT-MCSs 8 and 9 (transmit and receive) 2497 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 21.1.2 Scope The services provided to the MAC by the VHT PHY consist of the following protocol functions: a) A function that defines a method of mapping the PSDUs into a framing format (PPDU) suitable for sending and receiving PSDUs between two or more STAs. b) A function that defines the characteristics and method of transmitting and receiving data through a wireless medium between two or more STAs. Depending on the PPDU format, these STAs support a mixture of VHT, Clause 19 and Clause 17 PHYs. 21.1.3 VHT PHY functions 21.1.3.1 General The VHT PHY contains two functional entities: the PHY function and the physical layer management function (i.e., the PLME). Both of these functions are described in detail in 21.3 and 21.4. The VHT PHY service is provided to the MAC through the PHY service primitives defined in Clause 8. The VHT PHY service interface is described in 21.2. 21.1.3.2 PHY management entity (PLME) The PLME performs management of the local PHY functions in conjunction with the MLME. 21.1.3.3 Service specification method The models represented by figures and state diagrams are intended to be illustrations of the functions provided. It is important to distinguish between a model and a real implementation. The models are optimized for simplicity and clarity of presentation, but do not necessarily reflect any particular implementation. The service of a layer is the set of capabilities that it offers to a user in the next higher layer. Abstract services are specified here by describing the service primitives and parameters that characterize each service. This definition is independent of any particular implementation. 21.1.4 PPDU formats The structure of the PPDU transmitted by a VHT STA is determined by the TXVECTOR parameters as defined in Table 21-1. In a VHT STA the FORMAT parameter determines the overall structure of the PPDU and can take one of the following values: â€” Non-HT format (NON_HT), based on Clause 17 and including non-HT duplicate format. â€” HT-mixed format (HT_MF) as specified in Clause 19. â€” HT-greenfield format (HT_GF) as specified in Clause 19. â€” VHT format (VHT). PPDUs of this format contain a preamble compatible with Clause 17 and Clause 19 STAs. The non-VHT portion of the VHT format preamble (the parts of VHT preamble preceding the VHT-SIG-A field) is defined so that it can be decoded by these STAs. NOTEâ€”Required support for these formats is defined in 11.40, 19.1.1, and 21.1.1. A VHT PPDU can be further categorized as a VHT SU PPDU or a VHT MU PPDU. A VHT PPDU using a group ID value of 0 or 63 is a VHT SU PPDU and either carries only one PSDU or no PSDU. A VHT PPDU 2498 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications using a group ID value in the range 1 to 62 is a VHT MU PPDU and carries one or more PSDUs to one or more users. 21.2 VHT PHY service interface 21.2.1 Introduction The PHY provides an interface to the MAC through an extension of the generic PHY service interface defined in 8.3.4. The interface includes TXVECTOR, RXVECTOR, and PHYCONFIG_VECTOR. Using the TXVECTOR, the MAC supplies the PHY with per-PPDU transmit parameters. Using the RXVECTOR, the PHY informs the MAC of the received PPDU parameters. Using the PHYCONFIG_VECTOR, the MAC configures the PHY for operation, independent of frame transmission or reception. 21.2.2 TXVECTOR and RXVECTOR parameters The parameters in Table 21-1 are defined as part of the TXVECTOR parameter list in the PHY- TXSTART.request primitive and/or as part of the RXVECTOR parameter list in the PHY- RXSTART.indication primitive. Table 21-1â€”TXVECTOR and RXVECTOR parameters RXVECTOR TXVECTOR Parameter Condition Value Determines the format of the PPDU. Y Y Enumerated type: NON_HT indicates Clause 17 (Orthogonal frequency division FORMAT multiplexing (OFDM) PHY specification) or non-HT duplicate PPDU format. In this case, the modulation is determined by the NON_HT_MODULATION parameter. HT_MF indicates HT-mixed format. HT_GF indicates HT-greenfield format. VHT indicates VHT format. FORMAT is NON_HT In TXVECTOR, indicates the format type of the transmitted non- Y Y NON_HT_MODULATION HT PPDU. In RXVECTOR, indicates the estimated format type of the received non-HT PPDU. Enumerated type: OFDM indicates Clause 17 (Orthogonal frequency division multiplexing (OFDM) PHY specification) format NON_HT_DUP_OFDM indicates non-HT duplicate format Otherwise Not present N N 2499 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-1â€”TXVECTOR and RXVECTOR parameters (continued) RXVECTOR TXVECTOR Parameter Condition Value FORMAT is VHT Not present N N NOTEâ€”The Length field of the L-SIG in VHT PPDUs is L_LENGTH defined in Equation (21-24) using the TXTIME value defined by Equation (21-109) and Equation (21-110), which in turn depend on other parameters including the TXVECTOR parameter APEP_LENGTH. Otherwise See corresponding entry in Table 19-1 FORMAT is VHT Not present N N L_DATARATE NOTEâ€”The RATE field in the L-SIG field in a VHT PPDU is set to the value representing 6 Mb/s in the 20 MHz channel spacing column of Table 17-6. Otherwise See corresponding entry in Table 19-1 FORMAT is VHT Not present N N LSIGVALID Otherwise See corresponding entry in Table 19-1 FORMAT is VHT Not present N N SERVICE Otherwise See corresponding entry in Table 19-1 FORMAT is VHT Not present N N SMOOTHING Otherwise See corresponding entry in Table 19-1 FORMAT is VHT Not present N N AGGREGATION Otherwise See corresponding entry in Table 19-1 FORMAT is VHT Not present N N NUM_EXTEN_SS Otherwise See corresponding entry in Table 19-1 2500 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-1â€”TXVECTOR and RXVECTOR parameters (continued) RXVECTOR TXVECTOR Parameter Condition Value FORMAT is VHT Not present N N ANTENNA_SET Otherwise See corresponding entry in Table 19-1 FORMAT is VHT Indicates the number of transmit chains. Y N N_TX Otherwise See corresponding entry in Table 19-1 FORMAT is VHT and Set to COMPRESSED_SV Y N EXPANSION_MAT_TYPE EXPANSION_MAT is present. Otherwise See corresponding entry in Table 19-1 FORMAT is VHT Contains a vector in the number of selected subcarriers M N EXPANSION_MAT containing feedback matrices as defined in 21.3.11.2 based on U the channel measured during the training symbols of a previous VHT NDP PPDU. Otherwise See corresponding entry in Table 19-1 FORMAT is VHT and Set to COMPRESSED_SV N Y CHAN_MAT_TYPE PSDU_LENGTH equals 0 FORMAT is VHT and Not present N N PSDU_LENGTH is greater than 0 Otherwise See corresponding entry in Table 19-1 FORMAT is VHT and Contains a set of compressed beamforming feedback matrices as N Y PSDU_LENGTH equals 0 defined in 21.3.11.2 based on the channel measured during the CHAN_MAT training symbols of the received VHT NDP PPDU. FORMAT is VHT and Not present N N PSDU_LENGTH is greater than 0 Otherwise See corresponding entry in Table 19-1 2501 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-1â€”TXVECTOR and RXVECTOR parameters (continued) RXVECTOR TXVECTOR Parameter Condition Value FORMAT is VHT Contains an array of delta SNR values as defined in 9.4.1.51 M Y based on the channel measured during the training symbols of U DELTA_SNR the received VHT NDP PPDU. NOTEâ€”In the RXVECTOR this parameter is present only for VHT NDP PPDUs for MU sounding. Otherwise Not present N N See corresponding entry in Table 19-1 RCPI FORMAT is VHT Contains an array of received SNR measurements for each N Y spatial stream. SNR indications of 8 bits are supported. SNR shall be the sum of the decibel values of SNR per tone divided by SNR the number of tones represented in each stream as described in 9.4.1.49 Otherwise See corresponding entry in Table 19-1 FORMAT is VHT Not present N N NO_SIG_EXTN Otherwise See corresponding entry in Table 19-1 FORMAT is VHT Indicates which FEC encoding is used. M Y FEC_CODING Enumerated type: U BCC_CODING indicates binary convolutional code. LDPC_CODING indicates low-density parity check code. Otherwise See corresponding entry in Table 19-1 FORMAT is VHT Indicates whether STBC is used. Y Y 0 indicates no STBC (NSTS=NSS in the Data field). STBC 1 indicates STBC is used (NSTS=2NSS in the Data field). This parameter is 0 for a VHT MU PPDU. Otherwise See corresponding entry in Table 19-1 FORMAT is VHT Indicates whether a short guard interval is used in the Y Y transmission of the Data field of the PPDU. Enumerated type: GI_TYPE LONG_GI indicates short GI is not used in the Data field of the PPDU. SHORT_GI indicates short GI is used in the Data field of the PPDU. Otherwise See corresponding entry in Table 19-1 2502 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-1â€”TXVECTOR and RXVECTOR parameters (continued) RXVECTOR TXVECTOR Parameter Condition Value FORMAT is VHT The allowed values for the TXPWR_LEVEL_INDEX parameter Y N TXPWR_LEVEL_INDEX are in the range 1 to numberOfOctets(dot11TxPowerLevelExtended)/2. This parameter is used to indicate which of the available transmit output power levels defined in dot11TxPowerLevelExtended shall be used for the current transmission. Otherwise See corresponding entry in Table 19-1 FORMAT is VHT The allowed values for the RSSI parameter are in the range 0 to N Y 255. This parameter is a measure by the PHY of the power observed at the antennas used to receive the current PPDU RSSI measured during the reception of the VHT-LTF field. RSSI is intended to be used in a relative manner, and it is a monotonically increasing function of the received power. Otherwise See corresponding entry in Table 19-1 FORMAT is VHT Indicates the modulation and coding scheme used in the M Y transmission of the PPDU. U MCS Integer: range 0 to 9 Otherwise See corresponding entry in Table 19-1 FORMAT is HT_MF, Indicates the MCS that the STAâ€™s receiver recommends. N O REC_MCS HT_GF or VHT Otherwise Not present N N 2503 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-1â€”TXVECTOR and RXVECTOR parameters (continued) RXVECTOR TXVECTOR Parameter Condition Value FORMAT is HT_MF or See corresponding entry in Table 19-1 HT_GF FORMAT is VHT Indicates the channel width of the transmitted PPDU: Y Y Enumerated type: CBW20 for 20 MHz CBW40 for 40 MHz CBW80 for 80 MHz CBW160 for 160 MHz CBW80+80 for 80+80 MHz CH_BANDWIDTH FORMAT is NON_HT In TXVECTOR, indicates the channel width of the transmitted Y Y PPDU. In RXVECTOR, indicates the estimated channel width of the received PPDU. Enumerated type: CBW40, CBW80, CBW160, or CBW80+80 if NON_HT_MODULATION equals NON_HT_DUP_OFDM CBW20 if NON_HT_MODULATION equals OFDM NOTEâ€”On reception, where valid, the CH_BAND- WIDTH_IN_NON_HT parameter is likely to be a more reliable indication of subformat and channel width than the NON_HT_- MODULATION and CH_BANDWIDTH parameters, since for non-HT or non-HT duplicate frames, CH_BANDWIDTH is a receiver estimate of the bandwidth, whereas CH_BAND- WIDTH_IN_NON_HT is the signaled bandwidth. FORMAT is NON_HT In TXVECTOR, if present, indicates whether the transmitter is O Y DYN_BANDWIDTH_IN_NON_HT capable of Static or Dynamic bandwidth operation. In RXVECTOR, if valid, indicates whether the transmitter is capable of Static or Dynamic bandwidth operation. Enumerated type: Static if the transmitter is capable of Static bandwidth operation Dynamic if the transmitter is capable of Dynamic bandwidth operation NOTEâ€”In the RXVECTOR, the validity of this parameter is determined by the MAC based on the contents of the received MPDU. Otherwise Not present N N 2504 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-1â€”TXVECTOR and RXVECTOR parameters (continued) RXVECTOR TXVECTOR Parameter Condition Value FORMAT is NON_HT In TXVECTOR, if present, indicates the channel width of the O Y CH_BANDWIDTH_IN_NON_HT transmitted PPDU, which is signaled via the scrambling sequence. In RXVECTOR, if valid, indicates the channel width of the received PPDU, which is signaled via the scrambling sequence. Enumerated type: CBW20, CBW40, CBW80, CBW160, CBW80+80 NOTEâ€”In the RXVECTOR, the validity of this parameter is determined by the MAC based on the contents of the currently received MPDU (e.g., RTS) or the previous MPDU in an exchange (e.g., the RTS preceding a CTS). Otherwise Not present N N FORMAT is VHT Not present N N LENGTH Otherwise See corresponding entry in Table 19-1 FORMAT is VHT If equal to 0, indicates a VHT NDP PPDU for both RXVECTOR M O and TXVECTOR. U APEP_LENGTH If greater than 0 in the TXVECTOR, indicates the number of octets in the range 1 to 1 048 575 in the A-MPDU pre-EOF padding (see 10.13.2) carried in the PSDU. If greater than 0 in the RXVECTOR, this parameter is the value obtained from the VHT-SIG-B Length field multiplied by 4. Otherwise Not present N N FORMAT is VHT Indicates the number of octets in the VHT PSDU in the range 0 N Y PSDU_LENGTH to aPSDUMaxLength octets (see Table 21-29). A value of 0 indicates a VHT NDP PPDU. Otherwise Not present N N FORMAT is VHT and Index for user in MU transmission. Integer: range 0-3. M O USER_POSITION 1 â‰¤ GROUP_ID â‰¤ 62 U NOTEâ€”The entries in the USER_POSITION array are in ascending order. Otherwise Not present N N FORMAT is VHT Indicates the number of space-time streams. M Y NUM_STS Integer: range 1-8 for SU, 1-4 per user in the TXVECTOR and 0- U 4 in the RXVECTOR for MU. NUM_STS summed over all users is in the range 1 to 8. Otherwise Not present N N 2505 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-1â€”TXVECTOR and RXVECTOR parameters (continued) RXVECTOR TXVECTOR Parameter Condition Value FORMAT is VHT Indicates the group ID. Y Y GROUP_ID Integer: range 0-63 (see Table 21-12) A value of 0 or 63 indicates a VHT SU PPDU. A value in the range 1 to 62 indicates a VHT MU PPDU. Otherwise Not present N N FORMAT is VHT and Provides an abbreviated indication of the intended recipient(s) of Y Y PARTIAL_AID GROUP_ID is 0 or 63 the PSDU (see 10.20). Integer: range 0-511. Otherwise Not present N N FORMAT is VHT Indicates the number of users with nonzero space-time streams. Y N NUM_USERS Integer: range 1 to 4. Otherwise Not present N N FORMAT is VHT and Set to 1 if a beamforming steering matrix is applied to the Y O BEAMFORMED GROUP_ID is 0 or 63 waveform in an SU transmission. Set to 0 otherwise. NOTEâ€”When BEAMFORMED is set to 1, frequency domain smoothing as part of channel estimation is not recommended. Otherwise Not present N N FORMAT is VHT Indicates whether a VHT AP allows non-AP VHT STAs in Y Y TXOP_PS_NOT_ALLOWED TXOP power save mode to enter doze state during the TXOP. 0 indicates that the VHT AP allows non-AP VHT STAs to enter doze state during a TXOP. 1 indicates that the VHT AP does not allow non-AP VHT STAs to enter doze state during a TXOP. Otherwise Not present N N 2506 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-1â€”TXVECTOR and RXVECTOR parameters (continued) RXVECTOR TXVECTOR Parameter Condition Value See corresponding entry in Table 19-1 TIME_OF_DEPARTURE_REQUESTED dot11TimingMsmtActivat 0 to 232â€“ 1. An estimate of the offset (in 10 ns units) from the N Y RX_START_OF_FRAME_OFFSET ed is true point in time at which the start of the preamble corresponding to the incoming frame arrived at the receive antenna connector to the point in time at which this primitive is issued to the MAC. Otherwise Not present N N NOTEâ€”In the â€œTXVECTORâ€ and â€œRXVECTORâ€ columns, the following apply: Y = Present; N = Not present; O = Optional; MU indicates that the parameter is present once for a VHT SU PPDU and present per user for a VHT MU PPDU. Parameters specified to be present per user are conceptually supplied as an array of values indexed by u, where u takes values 0 to NUM_USERS-1. 21.2.3 PHYCONFIG_VECTOR parameters The PHYCONFIG_VECTOR carried in a PHY-CONFIG.request primitive for a VHT PHY contains an OPERATING_CHANNEL parameter, which identifies the operating or primary channel. The PHY shall set dot11CurrentPrimaryChannel to the value of this parameter. The PHYCONFIG_VECTOR carried in a PHY-CONFIG.request primitive for a VHT PHY contains a CHANNEL_WIDTH parameter, which identifies the operating channel width and takes one of the values 20 MHz, 40 MHz, 80 MHz, 160 MHz, and 80+80 MHz. The PHY shall set dot11CurrentChannelWidth to the value of this parameter. 2507 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The PHYCONFIG_VECTOR carried in a PHY-CONFIG.request primitive for a VHT PHY contains a CENTER_FREQUENCY_SEGMENT_0 parameter, which identifies the center frequency of the channel (or of segment 0 if the CHANNEL_WIDTH parameter indicates 80+80 MHz) and takes a value between 1 and 200. The PHY shall set dot11CurrentChannelCenterFrequencyIndex0 to the value of this parameter. The PHYCONFIG_VECTOR carried in a PHY-CONFIG.request primitive for a VHT PHY contains a CENTER_FREQUENCY_SEGMENT_1 parameter, which takes the value 0 if the CHANNEL_WIDTH parameter does not indicate 80+80 MHz, and otherwise identifies the center frequency of segment 1 and takes a value between 1 and 200. The PHY shall set dot11CurrentChannelCenterFrequencyIndex1 to the value of this parameter. 21.2.4 Effects of CH_BANDWIDTH parameter on PPDU format Table 21-2 shows the valid combinations of the FORMAT, NON_HT_MODULATION, and CH_BANDWIDTH parameters and the corresponding PPDU format and value of CH_OFFSET (if applicable). Other combinations are reserved. Table 21-2â€”Interpretation of FORMAT, NON_HT_MODULATION, CH_BANDWIDTH, and CH_OFFSET parameters NON_HT_ FORMAT CH_BANDWIDTH CH_OFFSET PPDU format MODULATION VHT N/A CBW20 N/A The STA transmits a VHT PPDU (when FORMAT is VHT) of 20 MHz bandwidth. If the BSS bandwidth is wider than 20 MHz, then the transmission shall use the primary 20 MHz channel. VHT N/A CBW40 N/A The STA transmits a VHT PPDU (when FORMAT is VHT) of 40 MHz bandwidth. If the BSS bandwidth is wider than 40 MHz, then the transmission shall use the primary 40 MHz channel. HT_MF or N/A HT_CBW20 and CH_OFF_20U The STA transmits an HT-mixed HT_GF CHANNEL_WIDTH PPDU (when FORMAT is in HT_MF) or HT-greenfield PPDU PHYCONFIG_VEC (when FORMAT is HT_GF) of 20 TOR > 20 MHz and MHz bandwidth. The transmission f S20 idx < f P20 idx shall use the primary 20 MHz channel. HT_MF or N/A HT_CBW20 and CH_OFF_20L The STA transmits an HT-mixed HT_GF CHANNEL_WIDTH PPDU (when FORMAT is in HT_MF) or HT-greenfield PPDU PHYCONFIG_VEC (when FORMAT is HT_GF) of 20 TOR > 20 MHz and MHz bandwidth. The transmission f S20 idx > f P20 idx shall use the primary 20 MHz channel. HT_MF or N/A HT_CBW20 and CH_OFF_20 The STA transmits an HT-mixed HT_GF CHANNEL_WIDTH PPDU (when FORMAT is in HT_MF) or HT-greenfield PPDU PHYCONFIG_VEC (when FORMAT is HT_GF) of 20 TOR = 20 MHz MHz bandwidth. 2508 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-2â€”Interpretation of FORMAT, NON_HT_MODULATION, CH_BANDWIDTH, and CH_OFFSET parameters (continued) NON_HT_ FORMAT CH_BANDWIDTH CH_OFFSET PPDU format MODULATION HT_MF or N/A HT_CBW40 CH_OFF_40 The STA transmits an HT-mixed HT_GF PPDU (when FORMAT is HT_MF) or HT-greenfield PPDU (when FORMAT is HT_GF) of 40 MHz bandwidth. If the BSS bandwidth is wider than 40 MHz, then the transmission shall use the primary 40 MHz channel. VHT N/A CBW80 The STA transmits a VHT PPDU of 80 MHz bandwidth. If the BSS bandwidth is 160 MHz or 80+80 MHz, then the transmission shall use the primary 80 MHz channel. VHT N/A CBW160 The STA transmits a VHT PPDU of 160 MHz bandwidth. VHT N/A CBW80+80 The STA transmits a VHT PPDU of 80+80 MHz bandwidth. NON_HT OFDM CBW20 The STA transmits a NON_HT PPDU with NON_HT_MODULATION set to OFDM using the primary 20 MHz channel as defined in Clause 17. NON_HT NON_HT_DUP_ CBW40 The STA transmits a NON_HT OFDM PPDU with NON_HT_MODULATION set to NON_HT_DUP_OFDM using two adjacent 20 MHz channels as defined in 21.3.10.12. If the BSS bandwidth is wider than 40 MHz, then the transmission shall use the primary 40 MHz channel. The one 20 MHz channel higher in frequency is rotated +90Âº relative to the 20 MHz channel lowest in frequency as defined in Equation (21-15). NON_HT NON_HT_DUP_ CBW80 The STA transmits a NON_HT OFDM PPDU with NON_HT_MODULATION set to NON_HT_DUP_OFDM using four adjacent 20 MHz channels as defined in 21.3.10.12. If the BSS BSS bandwidth is 160 MHz or 80+80 MHz, then the transmission shall use the primary 80 MHz channel. The three 20 MHz channels higher in frequency are rotated +180Âº relative to the 20 MHz channel lowest in frequency as defined in Equation (21-16). 2509 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-2â€”Interpretation of FORMAT, NON_HT_MODULATION, CH_BANDWIDTH, and CH_OFFSET parameters (continued) NON_HT_ FORMAT CH_BANDWIDTH CH_OFFSET PPDU format MODULATION NON_HT NON_HT_DUP_ CBW160 The STA transmits a NON_HT OFDM PPDU with NON_HT_MODULATION set to NON_HT_DUP_OFDM using eight adjacent 20 MHz channels as defined in 21.3.10.12. The second, third, fourth, sixth, seventh, and eighth 20 MHz channels in the order of increasing frequency are rotated +180Âº relative to the 20 MHz channel lowest in frequency as defined in Equation (21-17). NON_HT NON_HT_DUP_ CBW80+80 The STA transmits a NON_HT OFDM PPDU with NON_HT_MODULATION set to NON_HT_DUP_OFDM using two nonadjacent frequency segments, with each frequency segment consisting of four adjacent 20 MHz channels as defined in 21.3.10.12. In each frequency segment, the three 20 MHz channels higher in frequency are rotated +180Âº relative to the 20 MHz channel lowest in frequency as defined in Equation (21-16). 2510 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 21.2.5 Support for NON_HT and HT formats 21.2.5.1 General A VHT STA logically contains Clause 17, Clause 19, and Clause 21 PHYs. The MAC interfaces to the PHYs via the Clause 21 PHY service interface, which in turn interacts with the Clause 17 and Clause 19 PHY service interfaces as shown in Figure 21-1, Figure 21-2, and Figure 21-3. Clause 21 Clause 21 PHY-TXSTART.request(TXVECTOR) PHY-TXSTART.confirm FORMAT= FORMAT = NON_HT and FORMAT = NON_HT and FORMAT PHY-DATA.request HT NON_HT_MODULATION NON_HT_MODULATION = = VHT PHY-DATA.confirm = OFDM NON_HT_DUP_OFDM PHY-TXEND.request PHY-TXEND.confirm Clause 21 Clause 17 Transmit TXVECTOR TXVECTOR PHY-TXSTART.confirm Procedure Clause 19 21.2.5.3 Clause 17 21.2.5.2 PHY-DATA.request PHY-TXSTART.confirm PHY-TXSTART.confirm PHY-DATA.confirm PHY-DATA.request Clause 19 PHY-DATA.request Clause 17 PHY-TXEND.request PHY-DATA.confirm PHY- PHY-DATA.confirm PHY- PHY-TXEND.confirm PHY-TXEND.request TXSTART PHY-TXEND.request TXSTART PHY-TXEND.confirm .request PHY-TXEND.confirm .request (TXVECTOR) (TXVECTOR) Clause 19 Transmit Procedure; Clause 17 Transmit Procedure; Clause 17 21.3.10.12 and Clause 21 Clause 19 PPDU extended by 21.2.4 Clause 17 PPDU extended by 21.2.4 and Transmit 21.3.10 non-HT VHT PPDU and 21.3.9.2, and with 21.3.9.1, and with Procedure duplicate PPDU 21.3.17.1 instead of 19.3.18.1 and 21.3.17.1 instead of 17.3.9.3 and 21.3.17.4.2 instead of 19.3.18.4 21.3.17.4.2 instead of 17.3.9.7.2 Figure 21-1â€” PHY interaction on transmit for various PPDU formats Clause 21 PHY-RXSTART.indication(RXVECTOR) Clause 21 PHY-DATA.indication PHY-RXEND.indication 21.2.5.2 Clause 17 21.2.5.3 Clause 19 PHY-DATA.indication PHY-DATA.indication Note: Not all PHY-RXEND.indication PHY-RXEND.indication parameters are shown Clause 17 Clause 17 Clause 19 Clause 19 Clause 21 PHY-RXSTART Receive PHY-RXSTART Receive Receive .indication Procedure .indication Procedure Procedure (RXVECTOR) (RXVECTOR) NON_HT + NON_HT + HT OFDM NON_HT_DUP_OFDM VHT Format Detection Figure 21-2â€”PHY interaction on receive for various PPDU formats 2511 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Clause 21 PHY-CONFIG.request Clause 21 PHY-CONFIG.confirm Clause 21 PHY-CCARESET.request (PHYCONFIG_VECTOR) PHY-CCARESET.confirm PHY-CCA.indication Configure all PHYs. Confirm configuration of all PHYs. The PHY-CCA and PHY-CCARESET primitives from Clause 17 and Clause 19 21.2.5.2 21.2.5.3 Clause 17 PHY- Clause 19 PHY- are unused (CCA requirements are CONFIG.confirm CONFIG.confirm defined in Clause 21.3.18.5 instead). Clause 17 PHY- Clause 19 PHY- CONFIG.request CONFIG.request Clause 21 Clause 21 (PHYCONFIG_ (PHYCONFIG_ VECTOR) VECTOR) Figure 21-3â€”PHY-CONFIG and CCA interaction with Clause 17, Clause 19, and Clause 21 PHYs 21.2.5.2 Support for NON_HT format when NON_HT_MODULATION is OFDM When a PHY-TXSTART.request(TXVECTOR) primitive with the FORMAT parameter equal to NON_HT and the NON_HT_MODULATION parameter equal to OFDM is issued, the behavior of the VHT PHY is defined in Clause 17 with additional requirements described in the following subclauses: â€” 21.3.9.1 â€” 21.3.17.1 instead of 17.3.9.3 â€” 21.3.17.4.2 instead of 17.3.9.7.2 where the Clause 21 TXVECTOR parameters in Table 21-1 are mapped to Clause 17 TXVECTOR parameters in Table 17-1 according to Table 21-3. NOTEâ€”When the FORMAT parameter is set to NON_HT and the NON_HT_MODULATION parameter is set to NON_HT_DUP_OFDM in a PHY-TXSTART.request(TXVECTOR) primitive, the behavior of the VHT PHY is defined in Clause 21. When the VHT PHY receives a Clause 21 PHY-CONFIG.request(PHYCONFIG_VECTOR) primitive, the VHT PHY shall, for the purposes of OFDM PPDU transmission and reception, behave as if it were a Clause 17 PHY that had received a PHY-CONFIG.request(PHYCONFIG_VECTOR) primitive but with the CHANNEL_WIDTH, CENTER_FREQUENCY_SEGMENT_0, and CENTER_FREQUENCY_SEGMENT_1 parameters discarded from PHYCONFIG_VECTOR. As defined in 21.3.20, once a PPDU is received and detected as a NON_HT PPDU, the behavior of the VHT PHY is defined in Clause 17. The RXVECTOR parameters from the Clause 17 PHY-RXSTART.indication primitive are mapped to the Clause 21 RXVECTOR parameters as defined in Table 21-3. VHT PHY parameters not listed in the table are not present. Table 21-3â€”Mapping of VHT PHY parameters for NON_HT operation 5 GHz operation defined by VHT PHY Parameter Parameter List Clause 17 L_LENGTH LENGTH TXVECTOR/RXVECTOR L_DATARATE DATARATE TXVECTOR/RXVECTOR TXPWR_LEVEL_INDEX TXPWR_LEVEL_INDEX TXVECTOR 2512 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-3â€”Mapping of VHT PHY parameters for NON_HT operation (continued) 5 GHz operation defined by VHT PHY Parameter Parameter List Clause 17 RSSI RSSI RXVECTOR SERVICE SERVICE TXVECTOR/RXVECTOR RCPI RCPI RXVECTOR CH_BANDWIDTH_IN_NON_HT CH_BANDWIDTH_IN_NON_HT TXVECTOR/RXVECTOR DYN_BANDWIDTH_IN_NON_HT DYN_BANDWIDTH_IN_NON_HT TXVECTOR/RXVECTOR OPERATING_CHANNEL OPERATING_CHANNEL PHYCONFIG_VECTOR CHANNEL_WIDTH discarded PHYCONFIG_VECTOR CENTER_FREQUENCY_SEGMENT_ discarded PHYCONFIG_VECTOR 0 CENTER_FREQUENCY_SEGMENT_ discarded PHYCONFIG_VECTOR 1 21.2.5.3 Support for HT formats When a PHY-TXSTART.request(TXVECTOR) primitive is received with the TXVECTOR parameter FORMAT equal to HT_MF or HT_GF, the behavior of the PHY is defined by Clause 19 with additional requirements defined in the following subclauses: â€” 21.3.9.2 â€” 21.3.17.1 instead of 19.3.18.1 â€” 21.3.17.4.2 instead of 19.3.18.4 The Clause 21 TXVECTOR parameters in Table 21-1 are mapped directly to Clause 19 TXVECTOR parameters in Table 19-1 and the Clause 19 PHY-TXSTART.request(TXVECTOR) primitive is issued. The PHY shall use a value of CH_OFFSET in the Clause 19 TXVECTOR that is consistent with Table 21-2. When the VHT PHY receives a Clause 21 PHY-CONFIG.request(PHYCONFIG_VECTOR) primitive, the VHT PHY shall, for the purposes of HT PPDU transmission and reception, behave as if it were a Clause 19 PHY that had received PHY-CONFIG.request(PHYCONFIG_VECTOR) primitive but with the CHANNEL_WIDTH, CENTER_FREQUENCY_SEGMENT_0, and CENTER_FREQUENCY_SEGMENT_1 parameters discarded from the PHYCONFIG_VECTOR and the SECONDARY_CHANNEL_OFFSET parameter set to SECONDARY_CHANNEL_NONE if dot11CurrentChannelWidth indicates 20 MHz, to SECONDARY_CHANNEL_ABOVE if f P20 idx f S20 idx , or to SECONDARY_CHANNEL_BELOW otherwise. As defined in 21.3.20, once a PPDU is received and detected as an HT PPDU, the behavior of the VHT PHY is defined in Clause 19. The RXVECTOR parameters in Table 19-1 from the Clause 19 PHY- RXSTART.indication primitive are mapped directly to the RXVECTOR parameters in Table 21-1 and a Clause 21 PHY-RXSTART.indication primitive is issued. 21.2.6 TXSTATUS parameters The parameters listed in Table 20-2 are defined as part of the TXSTATUS parameter list in the PHY- TXSTART.confirm(TXSTATUS) primitive. 2513 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 21.3 VHT PHY 21.3.1 Introduction This subclause provides the procedure by which PSDUs are converted to and from transmissions on the wireless medium. During transmission, a PSDU (in the SU case) or one or more PSDUs (in the MU case) are processed (i.e., scrambled and coded) and appended to the PHY preamble to create the PPDU. At the receiver, the PHY preamble is processed to aid in the detection, demodulation, and delivery of the PSDU. Pre-VHT modulated fields refer to the L-STF, L-LTF, L-SIG, and VHT-SIG-A fields, while VHT modulated fields refer to the VHT-STF, VHT-LTF, VHT-SIG-B, and Data fields (see Figure 21-17). 21.3.2 VHT PPDU format A single PPDU format is defined for this PHY: the VHT PPDU format. Figure 21-4 shows the VHT PPDU format. 8 Î¼s 8 Î¼s 4 Î¼s 8 Î¼s 4 Î¼s 4 Î¼s per VHT-LTF symbol 4 Î¼s L- VHT- VHT- L-STF L-LTF VHT-SIG-A VHT-LTF Data SIG STF SIG-B Figure 21-4â€”VHT PPDU format The fields of the VHT PPDU format are summarized in Table 21-4. Table 21-4â€”Fields of the VHT PPDU Field Description L-STF Non-HT Short Training field L-LTF Non-HT Long Training field L-SIG Non-HT SIGNAL field VHT-SIG-A VHT Signal A field VHT-STF VHT Short Training field VHT-LTF VHT Long Training field VHT-SIG-B VHT Signal B field Data The Data field carrying the PSDU(s) The VHT-SIG-A, VHT-STF, VHT-LTF, and VHT-SIG-B fields exist only in VHT PPDUs. In a VHT NDP the Data field is not present. The number of symbols in the VHT-LTF field, NVHTLTF, can be either 1, 2, 4, 6, or 8 and is determined by the total number of space-time streams across all users being transmitted in the VHT PPDU (see Table 21-13). 2514 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 21.3.3 Transmitter block diagram The generation of each field in a VHT PPDU uses many of the following blocks: a) PHY padding b) Scrambler c) BCC encoder parser d) FEC (BCC or LDPC) encoders e) Stream parser f) Segment parser (for 160 MHz and 80+80 MHz transmissions) g) BCC interleaver h) Constellation mapper i) Pilot insertion j) Replicate over multiple 20 MHz (if BW > 20 MHz) k) Multiply by 1st column of PVHTLTF l) LDPC tone mapper m) Segment deparser n) Space time block code (STBC) encoder o) Cyclic shift diversity (CSD) per STS insertion p) Spatial mapper q) Inverse discrete Fourier transform (IDFT) r) Cyclic shift diversity (CSD) per chain insertion s) Guard interval (GI) insertion t) Windowing Figure 21-5 to Figure 21-16 show example transmitter block diagrams. The actual structure of the transmitter is implementation dependent. In particular, Figure 21-5 shows the transmit process for the L-SIG and VHT-SIG-A fields of a VHT PPDU using one frequency segment. These transmit blocks are also used to generate L-STF and L-LTF fields, except that the BCC encoder and interleaver are not used for these fields. Insert GI Analog and and RF Window 20 MHz if BW > 20 MHz Insert GI Replicate over multiple Constellation Mapper Analog CSD and BCC Interleaver and RF BCC Encoder Window IDFT ... Insert GI Analog CSD and and RF Window Single Spatial Stream NTX Transmit Chains Figure 21-5â€”Transmitter block diagram for the L-SIG and VHT-SIG-A fields 2515 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Figure 21-6 and Figure 21-7 show the transmit process for generating the VHT-SIG-B field of a VHT SU PPDU and VHT MU PPDU, respectively, in 20 MHz, 40 MHz, and 80 MHz channel widths. Figure 21-8 and Figure 21-9 show the transmit process for generating the VHT_SIG-B field of a 160 MHz and 80+80 MHz VHT SU PPDU, respectively. Insert GI Analog IDFT and and RF Window Multiply by 1st Column of PVHTLTF VHT-SIG-B Bit Repetition Constellation Mapper CSD Insert GI Analog Spatial Mapping if BW > 20 MHz BCC Interleaver per IDFT and BCC Encoder and RF STS Window ... ... CSD Insert GI Analog per IDFT and and RF STS Window Single Spatial Stream NSTS Space-Time NTX Transmit Chains Streams Figure 21-6â€”Transmitter block diagram for the VHT-SIG-B field of a 20 MHz, 40 MHz, and 80 MHz VHT SU PPDU VHT-SIG-B Bit Repetition Insert GI Multiply by User Specific Elements of 1st Column Analog Constellation Mapper IDFT and of PVHTLTF for User 0 and RF BCC Interleaver Window if BW>20MHz BCC Encoder CSD per STS ... Insert GI CSD Analog IDFT and per STS and RF Window NSTS, 0 Spatial Mapping Single Spatial Stream User 0 Space-time Streams ... ... Elements of 1st Column of VHT-SIG-B Bit Repetition Multiply by User Specific CSD PVHTLTF for User Nuser-1 Constellation Mapper per STS BCC Interleaver if BW>20MHz BCC Encoder ... CSD per STS Insert GI Analog IDFT and and RF Window Single Spatial Stream NSTS, Nuser-1 User Nuser-1 Space-time Streams NSTS,total NTx Transmit Chains Space-time Streams Figure 21-7â€”Transmitter block diagram for the VHT-SIG-B field of a 20 MHz, 40 MHz, and 80 MHz VHT MU PPDU 2516 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Insert GI Analog IDFT and and RF Constellation Window Interleaver CSD mapper VHT-SIG-B Bit Repetition Multiply By 1st Column of PVHTLTF BCC per STS Segment Deparser if BW=160MHz Insert GI BCC Encoder Segment Parser Analog IDFT and Spatial Mapping and RF Window Constellation ... Interleaver ... mapper BCC Insert GI Analog IDFT and CSD and RF Window per STS Single Spatial Stream NSTS Space-Time NTX Transmit Chains Streams Figure 21-8â€”Transmitter block diagram for the VHT-SIG-B field of a 160 MHz VHT SU PPDU Insert GI Analog IDFT and and RF Window Multiply By 1 st Column of P VH TLTF CSD per STS CSD per STS Interleaver Cons tellation mapper Insert GI Spatial Mapping Analog BCC Interleaver IDFT and V HT-SIG -B Bit Repetition and RF tellation mapper Window Multiply By 1 st Column of P VH TLTF CSD Interleav er if BW=80+ 80MHz CSD ... ...... per STS BCC Enc oder CSD per STS Segment per STSCSD Parser mapper CSD Spatial Mapping per STS Interleav er BCC per STS Constellation Cons mapper Interleav er Cons tellation CSD ...... BCCBCC Insert GI CSD CSD ... BCC Constellation per STS CSD Analog IDFT and Interleaver per STSper mapper STS per STS and RF Window Constellation mapper Insert GI BCC ...... BCC Constellation CSD CSD Analog IDFT and Interleaver mapper per STS per STS and RF Window NSTS Space-Time NTX Transmit Chains for each of the Single Spatial Stream Streams two segments Figure 21-9â€”Transmitter block diagram for the VHT-SIG-B field of an 80+80 MHz VHT SU PPDU Figure 21-10 shows the transmitter blocks used to generate the Data field of a 20 MHz, 40 MHz, and 80 MHz VHT SU PPDU with BCC encoding. A subset of these transmitter blocks consisting of the constellation mapper and CSD blocks, as well as the blocks to the right of, and including, the spatial mapping block, are also used to generate the VHT-LTF fields. This is illustrated in Figure 21-21. A subset of these transmitter blocks consisting of the constellation mapper and CSD blocks, as well as the blocks to the right of, and including, the spatial mapping block, are also used to generate the VHT-STF field but without k the multiplication by A VHT - LTF (defined in Equation (21-40)). 2517 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Constellation BCC Encoder Interleaver mapper BCC Insert GI Analog IDFT and and RF Window BCC Encoder Parser CSD per Constellation Interleaver Spatial Mapping STS Insert GI mapper Stream Parser PHY Padding Analog BCC Scrambler IDFT and ... and RF STBC Window ... ... ... Constellation BCC Encoder Insert GI Interleaver CSD per Analog mapper Single Data Stream IDFT and STS and RF BCC Window NES Data Streams NSS Spatial Streams NSTS Space-Time NTX Transmit Chains Streams Figure 21-10â€”Transmitter block diagram for the Data field of a 20 MHz, 40 MHz, or 80 MHz VHT SU PPDU with BCC encoding Figure 21-11 shows the transmitter blocks used to generate the Data field of a 20 MHz, 40 MHz, and 80 MHz VHT SU PPDU with LDPC encoding for a single frequency segment. LDPC Constellation tone mapper mapper LDPC Constellation CSD per Spatial Mapping tone Stream Parser mapper LDPC Encoder STS PHY Padding mapper Scrambler STBC ... ... ... LDPC CSD per Constellation tone STS mapper mapper Insert GI Analog and IDFT and RF Window ... Insert GI Analog and IDFT and RF Window Insert GI Analog and IDFT and RF Window Figure 21-11â€”Transmitter block diagram for the Data field of a 20 MHz, 40 MHz, or 80 MHz VHT SU PPDU with LDPC encoding 2518 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Figure 21-12 shows the transmit process for generating the Data field of a 20 MHz, 40 MHz, or 80 MHz VHT MU PPDU with BCC and LDPC encoding. Constellation LDPC tone mapper mapper Stream Parser PHY Padding Scrambler Constellation LDPC tone CSD Encoder mapper mapper per STS LDPC ... ... Constellation LDPC tone CSD Spatial Mapping mapper mapper per STS User 0 (Using LDPC) ... ... BCC Encoder Parser BCC Constellation CSD Encoder BCC Interleaver mapper per STS PHY Padding Stream Parser Scrambler ... ... Encoder BCC BCC Constellation CSD Interleaver mapper per STS User Nuser-1 (Using BCC) Insert GI Analog and IDFT and RF Window ... Insert GI Analog and IDFT and RF Window Insert GI Analog and IDFT and RF Window Figure 21-12â€”Transmitter block diagram for the Data field of a 20 MHz, 40 MHz, or 80 MHz VHT MU PPDU 2519 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Figure 21-13 and Figure 21-14 show the transmit process for generating the Data field of a 160 MHz VHT SU PPDU with BCC and LDPC encoding, respectively. BCC Constellation BCC Encoder Segment Interleaver mapper Parser Segment Constellation Deparser Interleaver mapper CSD per STS BCC Encoder Parser BCC Encoder Spatial Mapping Stream Parser PHY Padding Scrambler STBC BCC Encoder BCC Constellation Segment Interleaver mapper CSD Parser Segment BCC Constellation Deparser per STS Interleaver mapper Insert GI Analog and IDFT and RF Window Insert GI Analog and IDFT and RF Window Figure 21-13â€”Transmitter block diagram for the Data field of a 160 MHz VHT SU PPDU with BCC encoding Constellation LDPC tone Segment mapper mapper Parser Segment Deparser Constellation LDPC tone mapper mapper CSD per STS Spatial Mapping LDPC Encoder Stream Parser PHY Padding Scrambler STBC Constellation LDPC tone Segment mapper mapper CSD Parser Segment Deparser per STS Constellation LDPC tone mapper mapper Insert GI Analog and IDFT and RF Window Insert GI Analog and IDFT and RF Window Figure 21-14â€”Transmitter block diagram for the Data field of a 160 MHz VHT SU PPDU with LDPC encoding 2520 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Figure 21-15 and Figure 21-16 show the transmit process for generating the Data field of an 80+80 MHz VHT SU PPDU with BCC and LDPC encoding, respectively. BCC Constellation BCC Encoder Segment Parser Interleaver mapper Constellation BCC Interleaver Constellation LDPC tone CSD mapper Interleaver mapper mapper per STS Spatial Mapping BCC Encoder Parser BCC Encoder Stream Parser PHY Padding ... STBC Scrambler Spatial Mapping ... ... STBC ... BCC Encoder BCC Constellation CSD Segment Interleaver mapper Parser per STS BCC Constellation CSD Interleaver mapper per STS Insert GI Analog and IDFT and RF Window Insert GI Analog and IDFT and RF Window ... Insert GI Analog and IDFT and RF Window Insert GI Analog and IDFT and RF Window Figure 21-15â€”Transmitter block diagram for the Data field of an 80+80 MHz VHT SU PPDU with BCC encoding 2521 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Constellation LDPC tone Segment Parser mapper mapper Constellation LDPC tone CSD mapper mapper per STS Spatial Mapping ...... LDPC Encoder Stream Parser PHY Padding STBC ...... Scrambler Spatial Mapping ... STBC Constellation LDPC tone CSD Segment mapper mapper Parser per STS Constellation LDPC tone CSD mapper mapper per STS Insert GI Analog and IDFT and RF Window Insert GI Analog and IDFT and RF Window ... Insert GI Analog and IDFT and RF Window Insert GI Analog and IDFT and RF Window Figure 21-16â€”Transmitter block diagram for the Data field of an 80+80 MHz VHT SU PPDU with LDPC encoding 21.3.4 Overview of the PPDU encoding process 21.3.4.1 General This subclause provides an overview of the VHT PPDU encoding process. 21.3.4.2 Construction of L-STF Construct the L-STF field as defined in 21.3.8.2.2 with the following highlights: a) Determine the CH_BANDWIDTH from the TXVECTOR. b) Sequence generation: Generate the L-STF sequence over the CH_BANDWIDTH as described in 21.3.8.2.2. c) Phase rotation: Apply appropriate phase rotation for each 20 MHz subchannel as described in 21.3.7.4 and 21.3.7.5. d) IDFT: Compute the inverse discrete Fourier transform. e) CSD: Apply CSD for each transmit chain and frequency segment as described in 21.3.8.2.1. f) Insert GI and apply windowing: Prepend a GI (LONG_GI) and apply windowing as described in 21.3.7.4. 2522 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications g) Analog and RF: Upconvert the resulting complex baseband waveform associated with each transmit chain to an RF signal according to the center frequency of the desired channel and transmit. Refer to 21.3.7.4 and 21.3.8 for details. 21.3.4.3 Construction of the L-LTF Construct the L-LTF field as defined in 21.3.8.2.3 with the following highlights: a) Determine the CH_BANDWIDTH from the TXVECTOR. b) Sequence generation: Generate the L-LTF sequence over the CH_BANDWIDTH as described in 21.3.8.2.3. c) Phase rotation: Apply appropriate phase rotation for each 20 MHz subchannel as described in 21.3.7.4 and 21.3.7.5. d) IDFT: Compute the inverse discrete Fourier transform. e) CSD: Apply CSD for each transmit chain and frequency segment as described in 21.3.8.2.1. f) Insert GI and apply windowing: Prepend a GI ( 2 LONG_GI ) and apply windowing as described in 21.3.7.4. g) Analog and RF: Upconvert the resulting complex baseband waveform associated with each transmit chain to an RF signal according to the center frequency of the desired channel and transmit. Refer to 21.3.7.4 and 21.3.8 for details. 21.3.4.4 Construction of L-SIG Construct the L-SIG field as the SIGNAL field defined by 21.3.8.2.4 with the following highlights: a) In a VHT PPDU set the RATE subfield in the SIGNAL field to 6 Mb/s. Set the Length, Parity, and Tail bits in the SIGNAL field as described in 21.3.8.2.4. b) BCC encoder: Encode the SIGNAL field by a convolutional encoder at the rate of R=1/2 as described in 21.3.10.5.3. c) BCC interleaver: Interleave as described in 21.3.10.8. d) Constellation Mapper: BPSK modulate as described in 21.3.10.9. e) Pilot insertion: Insert pilots as described in 21.3.10.11. f) Duplication and phase rotation: Duplicate the L-SIG field over each 20 MHz of the CH_BANDWIDTH. Apply appropriate phase rotation for each 20 MHz subchannel as described in 21.3.7.4 and 21.3.7.5. g) IDFT: Compute the inverse discrete Fourier transform. h) CSD: Apply CSD for each transmit chain and frequency segment as described in 21.3.8.2.1. i) Insert GI and apply windowing: Prepend a GI (LONG_GI) and apply windowing as described in 21.3.7.4. j) Analog and RF: Upconvert the resulting complex baseband waveform associated with each transmit chain to an RF signal according to the center frequency of the desired channel and transmit. Refer to 21.3.7.4 and 21.3.8 for details. 21.3.4.5 Construction of VHT-SIG-A The VHT-SIG-A field consists of two symbols, VHT-SIG-A1 and VHT-SIG-A2, as defined in 21.3.8.3.3 and is constructed as follows: a) Obtain the CH_BANDWIDTH, STBC, GROUP_ID, PARTIAL_AID (SU only), NUM_STS, GI_TYPE, FEC_CODING, MCS (SU only), BEAMFORMED (SU only), NUM_USERS, and TXOP_PS_NOT_ALLOWED from the TXVECTOR. Add the reserved bits, append the calculated CRC, then append the N tail tail bits as shown in 21.3.8.3.3. This results in 48 uncoded bits. 2523 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications b) BCC encoder: Encode the data by a convolutional encoder at the rate of R=1/2 as described in 17.3.5.6 c) BCC interleaver: Interleave as described in 17.3.5.7. d) Constellation mapper: BPSK modulate the first 48 interleaved bits as described in 17.3.5.8 to form the first symbol of VHT-SIG-A. BPSK modulate the second 48 interleaved bits and rotate by 90Â° counter-clockwise relative to the first symbol to form the second symbol of VHT-SIG-A. e) Pilot insertion: Insert pilots as described in 117.3.5.9. f) Duplication and phase rotation: Duplicate VHT-SIG-A1 and VHT-SIG-A2 over each 20 MHz of the CH_BANDWIDTH. Apply the appropriate phase rotation for each 20 MHz subchannel as described in 21.3.7.4 and 21.3.7.5. g) IDFT: Compute the inverse discrete Fourier transform. h) CSD: Apply CSD for each transmit chain and frequency segment as described in 21.3.8.2.1. i) Insert GI and apply windowing: Prepend a GI (LONG_GI) and apply windowing as described in 21.3.7.4. j) Analog and RF: Upconvert the resulting complex baseband waveform associated with each transmit chain to an RF signal according to the center frequency of the desired channel and transmit. Refer to 21.3.7.4 and 21.3.8 for details. 21.3.4.6 Construction of VHT-STF The VHT-STF field is defined in 21.3.8.3.4 and is constructed as follows: a) Sequence generation: Generate the VHT-STF in the frequency domain over the bandwidth indicated by CH_BANDWIDTH as described in 21.3.8.3.4. b) Phase rotation: Apply appropriate phase rotation for each 20 MHz subchannel as described in 21.3.7.4 and 21.3.7.5. c) CSD: Apply CSD for each space-time stream and frequency segment as described in 21.3.8.3.2. d) Spatial mapping: Apply the Q matrix as described in 21.3.10.11.1. e) IDFT: Compute the inverse discrete Fourier transform. f) Insert GI and apply windowing: Prepend a GI (LONG_GI) and apply windowing as described in 21.3.7.4. g) Analog and RF: Upconvert the resulting complex baseband waveform associated with each transmit chain to an RF signal according to the center frequency of the desired channel and transmit. Refer to 21.3.7.4 and 21.3.8 for details. 21.3.4.7 Construction of VHT-LTF The VHT-LTF field is defined in 21.3.8.3.5 and constructed as follows: a) Sequence generation: Generate the VHT-LTF sequence in the frequency domain over the bandwidth indicated by CH_BANDWIDTH as described in 21.3.8.3.5. b) Phase rotation: Apply appropriate phase rotation for each 20 MHz subchannel as described in 21.3.7.4 and 21.3.7.5. c) AVHT-LTF matrix mapping: Apply the PVHT-LTF matrix to the data tones of the VHT-LTF sequence and apply the RVHT-LTF matrix to the pilot tones as described in 21.3.8.3.5. d) CSD: Apply CSD for each space-time stream and frequency segment as described in 21.3.8.3.2. e) Spatial mapping: Apply the Q matrix as described in 21.3.10.11.1. f) IDFT: Compute the inverse discrete Fourier transform. g) Insert GI and apply windowing: Prepend a GI (LONG_GI) and apply windowing as described in 21.3.7.4. 2524 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications h) Analog and RF: Upconvert the resulting complex baseband waveform associated with each transmit chain to an RF signal according to the center frequency of the desired channel and transmit. Refer to 21.3.7.4 and 21.3.8 for details. 21.3.4.8 Construction of VHT-SIG-B The VHT-SIG-B field is constructed per-user as follows: a) Obtain the VHT-MCS (for MU only) and APEP_LENGTH from the TXVECTOR. b) VHT-SIG-B bits: Set the VHT-MCS (for MU only) and VHT-SIG-B Length field as described in 21.3.8.3.6. Add the reserved bits (for SU only) and N tail bits of tail. In an NDP set VHT-SIG-B to the fixed bit pattern for the bandwidth used as described in 21.3.8.3.6. c) VHT-SIG-B Bit Repetition: Repeat the VHT-SIG-B bits as a function of CH_BANDWIDTH as defined in 21.3.8.3.6. d) BCC encoder: Encode the VHT-SIG-B field using BCC at rate R=1/2 as described in 17.3.5.6. e) Segment parser (if needed): In a 160 MHz or 80+80 MHz transmission, divide the output bits of the BCC encoder into two frequency subblocks as described in 21.3.10.7. This block is bypassed for 20 MHz, 40 MHz, and 80 MHz VHT PPDU transmissions. f) BCC interleaver: Interleave as described in 21.3.10.8. g) Constellation mapper: Map to a BPSK constellation as defined in 17.3.5.8. h) Segment deparser (if needed): In a 160 MHz transmission, merge the two frequency subblocks into one frequency segment as described in 21.3.10.9.3. This block is bypassed for 20 MHz, 40 MHz, 80 MHz, and 80+80 MHz VHT PPDU transmissions. i) Pilot insertion: Insert pilots following the steps described in 21.3.10.10. j) P VHT - LTF matrix mapping: Apply the mapping of the 1st column of the P VHT - LTF matrix to the data subcarriers as described in 21.3.8.3.6. The total number of data and pilot subcarriers is the same as in the Data field. k) CSD: Apply CSD for each space-time stream and frequency segment as described in 21.3.8.3.2. l) Spatial mapping: Apply the Q matrix as described in 21.3.10.11.1. m) Phase rotation: Apply the appropriate phase rotations for each 20 MHz subchannel as described in 21.3.7.4 and 21.3.7.5. n) IDFT: Compute the inverse discrete Fourier transform. o) Insert GI and apply windowing: Prepend a GI (LONG_GI) and apply windowing as described in 21.3.7.4. p) Analog and RF: Upconvert the resulting complex baseband waveform associated with each transmit chain to an RF signal according to the center frequency of the desired channel and transmit. Refer to 21.3.7.4 and 21.3.8 for details. 21.3.4.9 Construction of the Data field in a VHT SU PPDU 21.3.4.9.1 Using BCC The construction of the Data field in a VHT SU PPDU with BCC encoding proceeds as follows: a) Insert the CRC calculated for VHT-SIG-B in the SERVICE field as described in 21.3.10.2 and append the PSDU to the SERVICE field. b) PHY padding: Append the PHY pad bits and tail bits to the PSDU. c) Scrambler: Scramble the PHY padded data. d) BCC encoder: Divide the scrambled bits between the encoders by sending bits to different encoders in a round robin manner. The number of encoders is determined by rate-dependent parameters described in 21.5. BCC encode as described in 21.3.10.5.2 and 21.3.10.5.3. 2525 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications e) Stream parser: Rearrange the output of the BCC encoders into blocks as described in 21.3.10.6. f) Segment parser (if needed): In a 160 MHz or 80+80 MHz transmission, divide the output bits of each stream parser into two frequency subblocks as described in 21.3.10.7. This block is bypassed for 20 MHz, 40 MHz, and 80 MHz VHT PPDU transmissions. g) BCC interleaver: Interleave as described in 21.3.10.8. h) Constellation mapper: Map to BPSK, QPSK, 16-QAM, 64-QAM, or 256-QAM constellation points as described in 21.3.10.9. i) Segment deparser (if needed): In a 160 MHz transmission, merge the two frequency subblocks into one frequency segment as described in 21.3.10.9.3. This block is bypassed for 20 MHz, 40 MHz, 80 MHz, and 80+80 MHz VHT PPDU transmissions. j) STBC: Apply STBC as described in 21.3.10.9.4. k) Pilot insertion: Insert pilots following the steps described in 21.3.10.10. l) CSD: Apply CSD for each space-time stream and frequency segment as described in 21.3.8.3.2. m) Spatial mapping: Apply the Q matrix as described in 21.3.10.11.1. n) Phase rotation: Apply the appropriate phase rotations for each 20 MHz subchannel as described in 21.3.7.4 and 21.3.7.5. o) IDFT: In an 80+80 MHz transmission, map each frequency subblock to a separate IDFT. Compute the inverse discrete Fourier transform. p) Insert GI and apply windowing: Prepend a GI (SHORT_GI or LONG_GI) and apply windowing as described in 21.3.7.4. q) Analog and RF: Upconvert the resulting complex baseband waveform associated with each transmit chain to an RF signal according to the center frequency of the desired channel and transmit. Refer to 21.3.7.4 and 21.3.8 for details. 21.3.4.9.2 Using LDPC The construction of the Data field in a VHT SU PPDU with LDPC encoding proceeds as follows: a) Insert the CRC calculated for VHT-SIG-B in the SERVICE field as described in 21.3.10.2 and append the PSDU to the SERVICE field. b) PHY padding: Append the PHY pad bits to the PSDU. There are no tail bits. c) Scrambler: Scramble the PHY padded data. d) LDPC encoder: The scrambled bits are encoded using the LDPC code with the APEP_LENGTH in the TXVECTOR as described in 21.3.10.5.4. e) Stream parser: The output of the LDPC encoder is rearranged into blocks as described in 21.3.10.6. f) Segment parser (if needed): In a 160 MHz or 80+80 MHz transmission, divide the output bits of each stream parser into two frequency subblocks as described in 21.3.10.7. This block is bypassed for 20 MHz, 40 MHz, and 80 MHz VHT PPDU transmissions. g) Constellation mapper: Map to BPSK, QPSK, 16-QAM, 64-QAM or 256-QAM constellation points as described in 21.3.10.9. h) LDPC tone mapper: The LDPC tone mapping shall be performed on all LDPC encoded streams as described in 21.3.10.9.2. i) Segment deparser (if needed): In a 160 MHz transmission, merge the two frequency subblocks into one frequency segment as described in 21.3.10.9.3. This block is bypassed for 20 MHz, 40 MHz, 80 MHz, and 80+80 MHz VHT PPDU transmissions. j) STBC: Apply STBC as described in 21.3.10.9.4. k) Pilot insertion: Insert pilots following the steps described in 21.3.10.10. l) CSD: Apply CSD for each space-time stream and frequency segment as described in 21.3.8.3.2. 2526 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications m) Spatial mapping: Apply the Q matrix as described in 21.3.10.11.1. n) Phase rotation: Apply the appropriate phase rotations for each 20 MHz subchannel as described in 21.3.7.4 and 21.3.7.5. o) IDFT: In an 80+80 MHz transmission, map each frequency subblock to a separate IDFT. Compute the inverse discrete Fourier transform. p) Insert GI and apply windowing: Prepend a GI (SHORT_GI or LONG_GI) and apply windowing as described in 21.3.7.4. q) Analog and RF: Upconvert the resulting complex baseband waveform associated with each transmit chain to an RF signal according to the center frequency of the desired channel and transmit. Refer to 21.3.7.4 and 21.3.8 for details. 21.3.4.10 Construction of the Data field in a VHT MU PPDU 21.3.4.10.1 General In an MU transmission, the PPDU encoding process is performed independently on a per-user basis up to the input of the Spatial Mapping block, except that CSD is performed with a knowledge of the space time stream starting index for that user. All user data is combined and mapped to the transmit chains in the Spatial Mapping block. 21.3.4.10.2 Using BCC A Data field with BCC encoding is constructed using steps a) to k) in 21.3.4.9.1, then applying CSD for a VHT MU PPDU (as described in 21.3.8.3.2). 21.3.4.10.3 Using LDPC A Data field with LDPC encoding is constructed using steps a) to k) in 21.3.4.9.2, then applying CSD as for a VHT MU PPDU (as described in 22.3.8.3.2). 21.3.4.10.4 Combining to form a VHT MU PPDU The per-user data is combined as follows: a) Spatial Mapping: The Q matrix is applied as described in 21.3.10.11.1. The combining of all user data is done in this block. b) Phase rotation: Apply the appropriate phase rotations for each 20 MHz subchannel as described in 21.3.7.4 and 21.3.7.5. c) IDFT: Compute the inverse discrete Fourier transform. d) Insert GI and apply windowing: Prepend a GI (SHORT_GI or LONG_GI) and apply windowing as described in 21.3.7.4. e) Analog and RF: Upconvert the resulting complex baseband waveform associated with each transmit chain to an RF signal according to the center frequency of the desired channel and transmit. Refer to 21.3.7.4 and 21.3.8 for details. 21.3.5 VHT modulation and coding scheme (VHT-MCS) The VHT-MCS is a value that determines the modulation and coding used in the Data field of the PPDU. It is a compact representation that is carried in the VHT-SIG-A field for VHT SU PPDUs and in the VHT- SIG-B field for VHT MU PPDUs. Rate-dependent parameters for the full set of VHT-MCSs are shown in Table 21-30 to Table 21-61 (in 21.5). These tables give rate-dependent parameters for VHT-MCSs with indices 0 to 9, with number of spatial streams from 1 to 8 and bandwidth options of 20 MHz, 40 MHz, 2527 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 80 MHz, and either 160 MHz or 80+80 MHz. Equal modulation (EQM) is applied to all streams for a particular user. 21.3.6 Timing-related parameters Refer to Table 19-6 for timing-related parameters for non-VHT formats. Table 21-5 defines the timing-related parameters for VHT format. Table 21-5â€”Timing-related constants Parameter CBW20 CBW40 CBW80 CBW80+80 CBW160 Description NSD 52 108 234 234 468 Number of complex data numbers per frequency segment NSP 4 6 8 8 16 Number of pilot values per frequency segment NST 56 114 242 242 484 Total number of subcarriers per frequency segment. See NOTE. NSR 28 58 122 122 250 Highest data subcarrier index per frequency segment NSeg 1 1 1 2 1 Number of frequency segments âˆ†F 312.5 kHz Subcarrier frequency spacing TDFT 3.2 Âµs IDFT/DFT period TGI 0.8 Âµs = TDFT /4 Guard interval duration TGI2 1.6 Âµs Double guard interval TGIS 0.4 Âµs = TDFT /8 Short guard interval duration TSYML 4 Âµs = TDFT + TGI = 1.25 TDFT Long GI symbol interval TSYMS 3.6 Âµs = TDFT + TGIS = 1.125 TDFT Short GI symbol interval TSYM TSYML or TSYMS depending on the GI used (see Table 21-8) Symbol interval TL-STF 8 Âµs = 10 x TDFT /4 Non-HT Short Training field duration TL-LTF 8 Âµs = 2 x TDFT + TGI2 Non-HT Long Training field duration TL-SIG 4 Âµs = TSYML Non-HT SIGNAL field duration TVHT-SIG-A 8 Âµs = 2TSYML VHT Signal A field duration 2528 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-5â€”Timing-related constants (continued) Parameter CBW20 CBW40 CBW80 CBW80+80 CBW160 Description TVHT-STF 4 Âµs = TSYML VHT Short Training field duration TVHT-LTF 4 Âµs = TSYML Duration of each VHT- LTF symbol TVHT-SIG-B 4 Âµs = TSYML VHT Signal B field duration Nservice 16 Number of bits in the SERVICE field Ntail 6 Number of tail bits per BCC encoder NOTEâ€”NST = NSD + NSP Table 21-6 defines parameters used frequently in Clause 21. Table 21-6â€”Frequently used parameters Symbol Explanation NCBPS, NCBPS,u Number of coded bits per symbol for user u, u = 0, ..., Nuserâ€“1. For a VHT SU PPDU, NCBPS = NCBPS,0 For a VHT MU PPDU, NCBPS is undefined NCBPSS, NCBPSS,u Number of coded bits per symbol per spatial stream. For the VHT-SIG-B field, NCBPSS is common for all users. N SD for a 20 MHz, 40 MHz, 80 MHz, and 160 MHz PPDU N CBPSS = 2N SD for an 80+80 MHz PPDU for all users. For the Data field, NCBPSS,u equals the number of coded bits per symbol per spatial stream for user u, u = 0, ..., Nuserâ€“1. For the Data field of a VHT SU PPDU, NCBPSS = NCBPSS,0 For the Data field of a VHT MU PPDU, NCBPSS is undefined NCBPSSI, NCBPSSI,u Number of coded bits per symbol per spatial stream per BCC interleaver block. For a VHT SU PPDU, N CBPSS for a 20 MHz, 40 MHz, or 80 MHz PPDU N CBPSSI = N CBPSS ----------------- for a 160 MHz or 80+80 MHz PPDU 2 For a VHT MU PPDU for user u, u = 0, ..., Nuserâ€“1 N CBPSS u for a 20 MHz, 40 MHz, or 80 MHz PPDU N CBPSSI u = N CBPSS u --------------------- for a 160 MHz or 80+80 MHz PPDU 2 For a VHT MU PPDU, NCBPSSI is undefined. 2529 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-6â€”Frequently used parameters (continued) Symbol Explanation NDBPS, NDBPS,u Number of data bits per symbol for user u, u = 0, ..., Nuserâ€“1. For a VHT SU PPDU, NDBPS = NDBPS,0 For a VHT MU PPDU, NDBPS is undefined NBPSCS, NBPSCS,u Number of coded bits per subcarrier per spatial stream for user u, u = 0, ..., Nuserâ€“1. For a VHT SU PPDU, NBPSCS = NBPSCS,0 For a VHT MU PPDU, NBPSCS is undefined NRX Number of receive chains Nuser For pre-VHT modulated fields, Nuser = 1. For VHT modulated fields, Nuser represents the number of users in the transmission (equal to the TXVECTOR parameter NUM_USERS). NSTS, NSTS,u For pre-VHT modulated fields, NSTS,u = 1 (see NOTE). For VHT modulated fields, NSTS,u is the number of space-time streams for user u, u = 0,â€¦, Nuserâ€“1. For a VHT SU PPDU, NSTS = NSTS,0. For a VHT MU PPDU, NSTS is undefined. NSTS,total For VHT modulated fields, NSTS,total is the total number of space-time streams in a PPDU. N user â€“ 1 N STS total = N STS u u=0 For pre-VHT modulated fields, NSTS,total is undefined. Note that NSTS,total = NSTS for a VHT SU PPDU. NSS, NSS,u Number of spatial streams. For the VHT-SIG-B field, NSS = 1 for each user. For the Data field, NSS,u is the number of spatial streams for user u, u = 0,â€¦, Nuserâ€“ 1. For the Data field of a VHT SU PPDU, NSS = NSS,0. For the Data field of a VHT MU PPDU, NSS is undefined. NTX Number of transmit chains NES, NES,u The number of BCC encoders. For the VHT-SIG-B field, NES = 1 for each user. For a Data field encoded using BCC, NES,u is the number of BCC encoders for user u, u = 0,â€¦, Nuserâ€“1. For the Data field encoded using LDPC, NES = 1 for a VHT SU PPDU and NES,u = 1 for a VHT MU PPDU for user u, u = 0, â€¦Nuserâ€“1. For the Data field of a VHT SU PPDU, NES = NES,0. For the Data field of a VHT MU PPDU, NES is undefined. NVHT-LTF Number of VHT-LTF symbols (see 21.3.8.3.5) 2530 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-6â€”Frequently used parameters (continued) Symbol Explanation R, Ru Ru is the coding rate for user u, u = 0, ..., Nuserâ€“1. For a VHT SU PPDU, R = R0 For a VHT MU PPDU, R is undefined Mu For pre-VHT modulated fields, Mu = 0. For VHT modulated fields, M 0 = 0 for uâ€“1 u = 0 and M u = N STS u' for u = 1, â€¦Nuserâ€“1. u' = 0 NOTEâ€”For pre-VHT modulated fields, u is 0 only since Nuser = 1. 21.3.7 Mathematical description of signals 21.3.7.1 Notation For a description of the conventions used for the mathematical description of the signals, see 17.3.2.5. In addition, the following notational conventions are used in Clause 21: Q indicates the element in row m and column n of matrix Q , where 1 m Nrow and 1 n Ncol m n Nrow and Ncol are the number of rows and columns, respectively, of the matrix Q Q indicates a matrix consisting of columns M to N of matrix Q M:N 21.3.7.2 Subcarrier indices in use For description on subcarrier indices over which the signal is transmitted for non-HT and HT PPDUs, see 19.3.7. For a 20 MHz VHT PPDU transmission, the 20 MHz is divided into 64 subcarriers. The signal is transmitted on subcarriers â€“28 to â€“1 and 1 to 28, with 0 being the center (DC) subcarrier. For a 40 MHz VHT PPDU transmission, the 40 MHz is divided into 128 subcarriers. The signal is transmitted on subcarriers â€“58 to â€“2 and 2 to 58. For an 80 MHz VHT PPDU transmission, the 80 MHz is divided into 256 subcarriers. The signal is transmitted on subcarriers â€“122 to â€“2 and 2 to 122. For a 160 MHz VHT PPDU transmission, the 160 MHz is divided into 512 subcarriers. The signal is transmitted on subcarriers â€“250 to â€“130, â€“126 to â€“6, 6 to 126, and 130 to 250. For an 80+80 MHz VHT PPDU transmission, each 80 MHz frequency segment is divided into 256 subcarriers. In each frequency segment, the signal is transmitted on subcarriers â€“122 to â€“2 and 2 to 122. 2531 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 21.3.7.3 Channel frequencies Let fc idx0 = dot11CurrentChannelCenterFrequencyIndex0 (21-1) fc idx1 = dot11CurrentChannelCenterFrequencyIndex1 (21-2) f P20 idx = dot11CurrentPrimaryChannel (21-3) f CH start = dot11ChannelStartingFactor 500 kHz (21-4) where dot11CurrentChannelCenterFrequencyIndex0, dot11CurrentChannelCenterFrequencyIndex1, and dot11CurrentPrimaryChannel are defined in Table 21-22. When dot11CurrentChannelWidth (see Table 21-22) is 20 MHz, f P20 idx = f c idx0 . For dot11CurrentChannelWidth greater than 20 MHz, f P20 idx and f c idx0 shall have the relationship specified in Equation (21-5). N 20MHz f P20 idx = fc idx0 â€“4 ---------------- - â€“ n P20 + 2 (21-5) 2 where 2 if dot11CurrentChannelWidth indicates 40 MHz N 20MHz = 4 if dot11CurrentChannelWidth indicates 80 MHz and 80+80 MHz 8 if dot11CurrentChannelWidth indicates 160 MHz n P20 is an integer with possible range 0 n P20 N 20MHz â€“ 1 When dot11CurrentChannelWidth is 40 MHz, 80 MHz, 160 MHz, or 80+80 MHz, â€” The primary 20 MHz channel is the channel with 20 MHz bandwidth centered at f CH start + 5 f P20 idx MHz. â€” The secondary 20 MHz channel is the channel with 20 MHz bandwidth centered at f CH start + 5 f S 20 idx , where f S 20 idx is given in Equation (21-6). f P20 idx +4 if n P20 is even f S20 idx = (21-6) f P20 idx â€“4 if n P20 is odd When dot11CurrentChannelWidth is 80 MHz, 160 MHz, or 80+80 MHz, â€” The primary 40 MHz channel is the channel with 40 MHz bandwidth centered at f CH start + 5 f P40 idx MHz, where f P40 idx is given in Equation (21-7). â€” The secondary 40 MHz channel is the channel with 40 MHz bandwidth centered at f CH start + 5 f S 40 idx MHz, where f S 40 idx is given in Equation (21-8). N 20MHz f P40 idx = fc idx0 â€“8 ---------------- - â€“ n P40 + 4 (21-7) 4 2532 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications f P40 idx +8 if n P40 is even f S40 idx = (21-8) f P40 idx â€“8 if n P40 is odd where n P40 = n P20 2 When dot11CurrentChannelWidth is 160 MHz, â€” The primary 80 MHz channel is the channel with 80 MHz bandwidth centered at f CH start + 5 f P80 idx MHz, where f P80 idx is given in Equation (21-9). â€” The secondary 80 MHz channel is the channel with 80 MHz bandwidth centered at f CH start + 5 f S80 idx MHz where f S80 idx is given in Equation (21-10). N 20MHz f P80 idx = fc idx0 â€“ 16 ---------------- - â€“ n P80 + 8 (21-9) 8 f P80 idx + 16 if n P80 is even f S80 idx = (21-10) f P80 idx â€“ 16 if n P80 is odd where n P80 = n P20 4 . When dot11CurrentChannelWidth is 80+80 MHz, â€” The primary 80 MHz channel is the channel with 80 MHz bandwidth centered at f CH start + 5 f P80 idx MHz, where f P80 idx = f c idx0 . â€” The secondary 80 MHz channel is the channel with 80 MHz bandwidth centered at f CH start + 5 f S80 idx MHz where f S80 idx = f c idx1 . 21.3.7.4 Transmitted signal The transmitted signal is described in complex baseband signal notation. The actual transmitted signal is related to the complex baseband signal by the relation shown in Equation (21-11). i i TX 1 i Seg i TX i r RFSeg (t) = Re --------------- r PPDU (t)exp(j2 f c Seg t) (21-11) N Seg i Seg = 0 N Seg â€“ 1 ; i TX = 1 N TX where N Seg represents the number of frequency segments in the transmit signal, as defined in Table 21-5; i Seg i TX r PPDU (t) represents the complex baseband signal of frequency segment iSeg and transmit chain iTX; i f c Seg represents the center frequency of the portion of the PPDU transmitted in frequency segment iSeg. Table 21-7 shows f ciSeg as a function of the channel starting frequency and dot11CurrentChannelWidth (see Table 21-22) where f P20 idx , f P40 idx , and f P80 idx are given in Equation (21-4), Equation (21-5), Equation (21-7), and Equation (21-9), respectively. NOTEâ€”Transmitted signals might have different impairments such as phase offset or phase noise between the two fre- quency segments, which is not shown in Equation (21-11) for simplicity. See 21.3.17.3. 2533 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-7â€”Center frequency of the portion of the PPDU transmitted in frequency segment iSeg f ciSeg = f CH start +5 f i Seg dot11CurrentChannel CH_BANDWIDTH Width f 0 f 1 20 MHz CBW20 fc idx0 â€“ CBW20 f P20 idx â€“ 40 MHz CBW40 fc idx0 â€“ CBW20 f P20 idx â€“ 80 MHz CBW40 f P40 idx â€“ CBW80 fc idx0 â€“ CBW20 f P20 idx â€“ CBW40 f P40 idx â€“ 160 MHz CBW80 f P80 idx â€“ CBW160 fc idx0 â€“ CBW20 f P20 idx â€“ CBW40 f P40 idx â€“ 80+80 MHz CBW80 f P80 idx â€“ CBW80+80 min f c idx0 fc idx1 max f c idx0 fc idx1 The transmitted RF signal is derived by upconverting the complex baseband signal, which consists of several fields. The timing boundaries for the various fields are shown in Figure 21-17 where NVHTLTF is the number of VHT-LTF symbols and is defined in Table 21-13. Non-VHT portion VHT portion Pre-VHT-modulated fields VHT modulated fields VHT-LTF Data VHT- VHT- VHT- VHT- VHT- Data Data L-STF L-LTF L-SIG VHT-SIG-A LTF LTF LTF STF SIG-B symbol symbol symbol symbol symbol NVHTLTF t=0 tL-LTF tL-SIG tVHT-SIG-A tVHT-STF tVHT-LTF tVHT-SIG-B tVHT-Data Figure 21-17â€”Timing boundaries for VHT PPDU fields 2534 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The time offset, t Field , determines the starting time of the corresponding field relative to the start of L-STF (t = 0). The signal transmitted on frequency segment i Seg and transmit chain i TX shall be as shown in Equation (21-12). i Seg i TX i Seg i TX i Seg i TX r PPDU (t) = r L-STF (t) + r L-LTF (t â€“ t L-LTF) (21-12) i Seg i TX i Seg i TX + r L-SIG (t â€“ t L-SIG) + r VHT-SIG-A(t â€“ t VHT-SIG-A) i Seg i TX i Seg i TX + r VHT-STF(t â€“ t VHT-STF) + r VHT-LTF (t â€“ t VHT-LTF) i Seg i TX i Seg i TX + r VHT-SIG-B(t â€“ t VHT-SIG-B) + r VHT-Data(t â€“ t VHT-Data) where 0 i Seg N Seg â€“ 1 1 i TX N TX t L-LTF = T L-STF t L-SIG = t L-LTF + T L-LTF t VHT-SIG-A = t L-SIG + T L-SIG t VHT-STF = t VHT-SIG-A + T VHT-SIG-A t VHT-LTF = t VHT-STF + T VHT-STF t VHT-SIG-B = t VHT-LTF + N VHT - LTF T VHT-LTF t VHT-Data = t VHT-SIG-B + T VHT-SIG-B Seg TX i i Each field, r Field (t) , is defined as the summation of one or more subfields, where each subfield is defined to be an inverse discrete Fourier transform as specified in Equation (21-13). N SR N user â€“ 1 N STS u i Seg i TX 1 i Seg m r Subfield (t) = ------------------------------- w TSubfield(t) i Q k Seg k BW X k u (21-13) Tone i TX M u + m N Field N Norm k = â€“ N SR u=0 m=1 exp(j2 k F t â€“ T GI Field â€“ T CS VHT Mu + m ) This general representation holds for all subfields. The total power of the time domain VHT modulated field signals summed over all transmit chains should not exceed the total power of the time domain pre-VHT modulated field signals summed over all transmit chains. For notational simplicity, the parameter BW is omitted from some bandwidth dependent terms. In Equation (21-13) the following notions are used: Tone Tone N Field Table 21-8 summarizes the various values of N Field as a function of bandwidth per frequency segment. 2535 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-8â€”Tone scaling factor and guard interval duration values for PHY fields Tone N Field as a function of bandwidth per frequency segment Guard interval Field duration 20 MHz 40 MHz 80 MHz 160 MHz L-STF 12 24 48 96 - L-LTF 52 104 208 416 TGI2 L-SIG 52 104 208 416 TGI VHT-SIG-A 52 104 208 416 TGI VHT-STF 12 24 48 96 - VHT-LTF 56 114 242 484 TGI VHT-SIG-B 56 114 242 484 TGI VHT-Data 56 114 242 484 TGI or TGIS (see NOTE 2) NON_HT_DUP_OFDM-Data - 104 208 416 TGI (see NOTE 1) NOTE 1â€”For notational convenience, NON_HT_DUP_OFDM-Data is used as a label for the Data field of a NON_HT PPDU with format type NON_HT_DUP_OFDM. NOTE 2â€”TGI denotes guard interval duration when TXVECTOR parameter GI_TYPE equals LONG_GI, TGIS denotes short guard interval duration when TXVECTOR parameter GI_TYPE equals SHORT_GI. N Norm For pre-VHT modulated fields, N Norm = N TX . For VHT modulated fields, N Norm = N STS total where N STS total is given in Table 21-6. w TSubfield(t) is a windowing function. An example function, w TSubfield(t) , is given in 17.3.2.5. T Subfield is TL- STF for L-STF, TL-LTF for L-LTF, TL-SIG for L-SIG, TSYML for VHT-SIG-A, TVHT-STF for VHT-STF, TVHT-LTF for VHT-LTF and TVHT-SIG-B for VHT-SIG-B. T Subfield is TSYM for VHT- Data, that is TSYML when not using the short guard interval (Short GI field of VHT-SIG-A is 0) and TSYMS when using the short guard interval (Short GI field of VHT-SIG-A is 1). Q kiSeg is the spatial mapping matrix for the subcarrier k in frequency segment i Seg . For pre-VHT modulated fields, Q kiSeg is a column vector with N TX elements with element i TX being i TX i TX exp(â€“ j2 k F T CS ) , where T CS represents the cyclic shift for transmitter chain i TX whose values are given in Table 21-10. For VHT modulated fields, Q kiSeg is a matrix with N TX rows and N STS total columns. k BW is defined in 21.3.7.5 F is the subcarrier frequency spacing given in Table 21-5. i m X k Seg u is the frequency domain symbol in subcarrier k of user u for frequency segment i Seg of space- Seg i m time stream m. Some of the X k u within â€“ N SR k N SR have a value of 0. Examples of such cases include the DC tones, guard tones on each side of the transmit spectrum, as well as 2536 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications the unmodulated tones of L-STF and VHT-STF fields. Note that the multiplication matrices Seg i m k A VHT - LTF and P VHT - LTF are included in the calculation of X k u for the VHT-LTF and VHT- SIG-B fields, respectively. T GI Field is the guard interval duration used for each OFDM symbol in the field. For L-STF and VHT- STF, T GI Field = T GI but it can be omitted from Equation (21-13) due to the periodic property of L-STF and VHT-STF over every 0.8 Âµs. For the L-SIG, VHT-SIG-A, VHT-LTF, and VHT- SIG-B fields, T GI Field is defined in the â€œGuard interval durationâ€ column of Table 21-8. T CS VHT(l) For pre-VHT modulated fields, T CS VHT(l) = 0 . For VHT modulated fields, T CS VHT(l) represents the cyclic shift per space-time stream, whose value is defined in Table 21-11. Mu is defined in Table 21-6. 21.3.7.5 Definition of tone rotation The function k BW is used to represent a rotation of the tones. BW in k BW is determined by the TXVECTOR parameter CH_BANDWIDTH as defined in Table 21-9. Table 21-9â€”CH_BANDWIDTH and k BW CH_BANDWIDTH k BW CBW20 k 20 CBW40 k 40 CBW80 k 80 CBW160 k 160 CBW80+80 k 80 per frequency segment For a 20 MHz PPDU transmission, k 20 = 1 (21-14) For a 40 MHz PPDU transmission, 1 k 0 k 40 = (21-15) j k 0 For an 80 MHz PPDU transmission, 1 k â€“ 64 k 80 = (21-16) â€“1 k â€“ 64 For an 80+80 MHz PPDU transmission, each 80 MHz frequency segment shall use the phase rotation for 80 MHz PPDU transmissions as defined in Equation (21-16). 2537 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications For a 160 MHz PPDU transmission, 1 k â€“ 192 â€“1 â€“ 192 k 0 k 160 = (21-17) 1 0 k 64 â€“1 64 k 21.3.8 VHT preamble 21.3.8.1 Introduction A VHT preamble is defined to carry the required information to operate in either single user or multi-user mode. To maintain compatibility with non-VHT STAs, specific non-VHT fields are defined that can be received by non-VHT STAs compliant with Clause 17 or Clause 19. The non-VHT fields are followed by VHT fields specific to VHT STAs. 21.3.8.2 Non-VHT portion of VHT format preamble 21.3.8.2.1 Cyclic shift for pre-VHT modulated fields i TX The cyclic shift value T CS for the L-STF, L-LTF, L-SIG, and VHT-SIG-A fields of the PPDU for transmit chain iTX out of a total of NTX are defined in Table 21-10. Table 21-10â€”Cyclic shift values for L-STF, L-LTF, L-SIG, and VHT-SIG-A fields of the PPDU i TX T CS values for L-STF, L-LTF, L-SIG, and VHT-SIG-A fields of the PPDU Total Cyclic shift for transmit chain iTX (in units of ns) number of transmit chains (NTX) per 1 2 3 4 5 6 7 8 >8 frequency segment 1 0 â€“ â€“ â€“ â€“ â€“ â€“ â€“ â€“ 2 0 â€“200 â€“ â€“ â€“ â€“ â€“ â€“ â€“ 3 0 â€“100 â€“200 â€“ â€“ â€“ â€“ â€“ â€“ 4 0 â€“50 â€“100 â€“150 â€“ â€“ â€“ â€“ â€“ 5 0 â€“175 â€“25 â€“50 â€“75 â€“ â€“ â€“ â€“ 6 0 â€“200 â€“25 â€“150 â€“175 â€“125 â€“ â€“ â€“ 7 0 â€“200 â€“150 â€“25 â€“175 â€“75 â€“50 â€“ â€“ 8 0 â€“175 â€“150 â€“125 â€“25 â€“100 â€“50 â€“200 â€“ Between >8 0 â€“175 â€“150 â€“125 â€“25 â€“100 â€“50 â€“200 â€“200 and 0 inclusive 2538 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 21.3.8.2.2 L-STF definition The L-STF field for a 20 MHz or 40 MHz transmission is defined by Equation (19-8) and Equation (19-9), respectively, in 19.3.9.3.3. For 80 MHz, the L-STF field is defined by Equation (21-18). Note that these equations do not include the phase rotation per 20 MHz subchannel. S â€“122 122 = S â€“58 58 0 0 0 0 0 0 0 0 0 0 0 S â€“58 58 (21-18) where S â€“58 58 is defined in Equation (19-9) For 160 MHz, the L-STF is defined by Equation (21-19). S â€“250 250 = S â€“122 122 0 0 0 0 0 0 0 0 0 0 0 S â€“122 122 (21-19) where S â€“122 122 is defined in Equation (21-18) For an 80+80 MHz transmission, each 80 MHz frequency segment shall use the L-STF pattern for the 80 MHz ( S â€“122 122 ) defined in Equation (21-18). The time domain representation of the signal on frequency segment i Seg and transmit chain i TX shall be as specified in Equation (21-20). N SR i Seg i TX 1 i (t) = ----------------------------- w TL-STF(t) TX r L-STF k BW S k exp j2 k F t â€“ T CS (21-20) Tone N L-STF N TX k = â€“ NSR where i TX T CS represents the cyclic shift for transmit chain i TX with a value given in Table 21-10 k BW is defined by Equation (21-14), Equation (21-15), Equation (21-16). and Equation (21-17) Tone N L-STF has the value given in Table 21-8 21.3.8.2.3 L-LTF definition For a 20 MHz or 40 MHz transmission, the L-LTF pattern in the VHT preamble is defined by Equation (19-11) and Equation (19-12) in 19.3.9.3.4, respectively. For an 80 MHz transmission, the L-LTF pattern is defined by Equation (21-21). Note that these equations do not include the phase rotation per 20 MHz subchannel. L â€“122 122 = L â€“58 58 0 0 0 0 0 0 0 0 0 0 0 L â€“58 58 (21-21) where L â€“58 58 is defined in Equation (19-12) For a 160 MHz transmission, the L-LTF is defined by Equation (21-22). Note that this equation does not include the phase rotations per 20 MHz subchannel. 2539 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications L â€“250 250 = L â€“122 122 0 0 0 0 0 0 0 0 0 0 0 L â€“122 122 (21-22) where L â€“122 122 is given by Equation (21-21) For an 80+80 MHz transmission, each 80 MHz frequency segment shall use the L-LTF pattern for the 80 MHz L-LTF pattern ( L â€“122 122 ) defined in Equation (21-21). The time domain representation of the signal on frequency segment i Seg and transmit chain i TX shall be as defined in Equation (21-23). N SR i Seg i TX 1 i r L-LTF (t) = ------------------------------ w TL-LTF(t) k BW L k exp j2 k F TX t â€“ T GI2 â€“ T CS (21-23) Tone N L-LTF N TX k = â€“ N SR where i TX T CS represents the cyclic shift for transmitter chain i TX with a value given in Table 21-10 k BW is defined by Equation (21-14), Equation (21-15), Equation (21-16), and Equation (21-17) Tone N L-LTF has the value given in Table 21-8 21.3.8.2.4 L-SIG definition The L-SIG field is used to communicate rate and length information. The structure of the L-SIG field is defined in Figure 17-5. In a VHT PPDU, the RATE field shall be set to the value representing 6 Mb/s in the 20 MHz channel spacing column of Table 17-6. In a non-HT duplicate PPDU, the RATE field is defined in 17.3.4.2 using the L_DATARATE parameter in the TXVECTOR. The LENGTH field shall be set to the value given by Equation (21-24). TXTIME â€“ 20 Length = ---------------------------------- 3â€“3 (21-24) 4 where TXTIME (in Âµs) is defined in 21.4.3 The LSB of the binary expression of the Length value shall be mapped to B5. In a non-HT duplicate PPDU, the LENGTH field is defined in 17.3.4.3 using the L_LENGTH parameter in the TXVECTOR. The Reserved (R) field shall be set to 0. The Parity (P) field has the even parity of bits 0-16. The SIGNAL TAIL field shall be set to 0. The L-SIG field shall be encoded, interleaved, and mapped following the steps described in 17.3.5.6, 17.3.5.7, and 17.3.5.8. The stream of 48 complex numbers generated by these steps is denoted by 2540 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dk k = 0 47 . Pilots shall be inserted as described in 17.3.5.9. The time domain waveform of the L-SIG field shall be as given by Equation (21-25). i Seg i TX 1 r L-SIG (t) = ---------------------------- w TL-SIG(t) (21-25) Tone N L-SIG N TX N 20MHz â€“ 1 26 k â€“ K Shift i BW BW Dk 20 + p0 Pk i TX i BW = 0 k = â€“ 26 exp j2 k â€“ K Shift i BW F t â€“ T GI â€“ T CS where N 20MHz is defined in 21.3.7.3 K Shift(i) = N 20MHz â€“ 1 â€“ 2i 32 0 k = 0 7 21 Dk 20 = (21-26) d Mr k otherwise 20 k + 26 â€“ 26 k â€“ 22 k + 25 â€“ 20 k â€“ 8 r M 20 k = k + 24 â€“6 k â€“1 (21-27) k + 23 1 k 6 k + 22 8 k 20 k + 21 22 k 26 Pk is defined in 17.3.5.10 p0 is the first pilot value in the sequence defined in 17.3.5.10 Tone N L-SIG has the value given in Table 21-8 k BW is defined in Equation (21-14), Equation (21-15), Equation (21-16), and Equation (21-17) i TX T CS represents the cyclic shift for transmitter chain i TX with a value given in Table 21-10 NOTEâ€” M 20 r (k) is a â€œreverseâ€ function of the function M(k) defined in 17.3.5.10. 2541 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 21.3.8.3 VHT portion of VHT format preamble 21.3.8.3.1 Introduction The VHT portion of the VHT format preamble consists of the VHT-SIG-A, VHT-STF, VHT-LTF, and VHT-SIG-B fields. 21.3.8.3.2 Cyclic shift for VHT modulated fields The cyclic shift values defined in this subclause apply to the VHT-STF, VHT-LTF, VHT-SIG-B, and Data fields of the VHT PPDU. The cyclic shift values defined in 21.3.8.2.1 apply to VHT-SIG-A field in the VHT format preamble. Throughout the VHT modulated fields of the preamble, cyclic shifts are applied to prevent unintended beamforming when correlated signals are transmitted in multiple space-time streams. The same cyclic shift is also applied to these streams during the transmission of the Data field of the VHT PPDU. The cyclic shift value T CS VHT n for the VHT modulated fields for space-time stream n out of NSTS,total total space-time streams is shown in Table 21-11. Table 21-11â€”Cyclic shift values for the VHT modulated fields of a PPDU T CS VHT n values for the VHT modulated fields of a PPDU Total number Cyclic shift for space-time stream n (ns) of space-time streams (NSTS,total) 1 2 3 4 5 6 7 8 1 0 â€“ â€“ â€“ â€“ â€“ â€“ â€“ 2 0 â€“400 â€“ â€“ â€“ â€“ â€“ â€“ 3 0 â€“400 â€“200 â€“ â€“ â€“ â€“ â€“ 4 0 â€“400 â€“200 â€“600 â€“ â€“ â€“ â€“ 5 0 â€“400 â€“200 â€“600 â€“350 â€“ â€“ â€“ 6 0 â€“400 â€“200 â€“600 â€“350 â€“650 â€“ â€“ 7 0 â€“400 â€“200 â€“600 â€“350 â€“650 â€“100 â€“ 8 0 â€“400 â€“200 â€“600 â€“350 â€“650 â€“100 â€“750 In a VHT MU PPDU, the cyclic shifts are applied sequentially across the space-time streams as follows: the cyclic shift of the space-time stream number m of user u is given by T CS VHT M u + m of the row corresponding to NSTS,total in Table 21-11. 2542 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 21.3.8.3.3 VHT-SIG-A definition The VHT-SIG-A field carries information required to interpret VHT PPDUs. The structure of the VHT-SIG- A field for the first part (VHT-SIG-A1) is shown in Figure 21-18 and for the second part (VHT-SIG-A2) is shown in Figure 21-19. B0 B1 B2 B3 B4 B9 B10 B12 B13 B15 B16 B18 B19 B21 B22 B23 TXOP_PS_NOT Composite Name: NSTS/Partial AID _ALLOWED Reserved Reserved Group ID STBC BW SU Name: SU NSTS Partial AID MU Name: MU[0] NSTS MU[1] NSTS MU[2] NSTS MU[3] NSTS Bits: 2 1 1 6 3 3 3 3 1 1 Figure 21-18â€”VHT-SIG-A1 structure B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 B10 B17 B18 B23 Composite Name: SU VHT-MCS/MU[1-3] Coding Beam- SU/MU[0] Coding formed Short GI NSYM Disambiguation OFDM Symbol LDPC Extra Reserved Short GI CRC Beam- Tail SU Name: SU VHT-MCS formed MU Name: MU[1] MU[2] MU[3] Reserved Reserved Coding Coding Coding Bits: 1 1 1 1 1 1 1 1 1 1 8 6 Figure 21-19â€”VHT-SIG-A2 structure NOTEâ€”Integer fields are represented in unsigned binary format with the least significant bit in the lowest numbered bit position. The VHT-SIG-A field contains the fields listed in Table 21-12. The mapping of the fields is also described in Table 21-12. Note that the mapping of the STBC field, the NSTS/Partial AID field, the SU/MU[0] Coding field, the SU VHT-MCS/MU[1-3] Coding field, and the Beamformed field is different for VHT SU and MU PPDUs. The VHT-SIG-A field is composed of two parts, VHT-SIG-A1 and VHT-SIG-A2, each containing 24 data bits, as shown in Table 21-12. VHT-SIG-A1 is transmitted before VHT-SIG-A2. The VHT-SIG-A symbols shall be BCC encoded at rate, R = 1/2, be interleaved, be mapped to a BPSK constellation, and have pilots inserted following the steps described in 17.3.5.6, 17.3.5.7, 17.3.5.8, and 17.3.5.9, respectively. The first and second half of the stream of 96 complex numbers generated by these steps (before pilot insertion) is divided into two groups of 48 complex numbers d k n k = 0 47 , where n = 0 1 , respectively. The first 48 complex numbers form the first symbol of VHT-SIG-A and the second 48 complex numbers form the second symbol of VHT-SIG-A after rotating by 90Â° counter-clockwise relative to the first symbol. The first symbol of VHT-SIG-A, which does not have the 90Â° rotation, is used to differentiate VHT PPDUs from HT PPDUs, while the second symbol of VHT-SIG-A, which has the 90Â° rotation, is used to differentiate VHT PPDUs from non-HT PPDUs. 2543 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-12â€”Fields in the VHT-SIG-A field Two parts of Number Bit Field Description VHT-SIG-A of bits B0-B1 BW 2 Set to 0 for 20 MHz, 1 for 40 MHz, 2 for 80 MHz, and 3 for 160 MHz and 80+80 MHz B2 Reserved 1 Reserved. Set to 1. B3 STBC 1 For a VHT SU PPDU: Set to 1 if space time block coding (see 21.3.10.9.4) is used and set to 0 otherwise. For a VHT MU PPDU: Set to 0. B4-B9 Group ID 6 Set to the value of the TXVECTOR parameter GROUP_ID. A value of 0 or 63 indicates a VHT SU PPDU; otherwise, indicates a VHT MU PPDU. B10-B21 NSTS/Partial 12 For a VHT MU PPDU: NSTS is divided into 4 user AID positions of 3 bits each. User position p, where 0 p 3 , uses bits B( 10 + 3p ) to B( 12 + 3p ). The number of space- time streams for user u are indicated at user position p = USER_POSITION u where u = 0 1 NUM_USERS â€“ 1 and the notation A[b] denotes the value of array A at index b. Zero space-time streams are indicated at positions not listed in the USER_POSITION array. Each user position is set as follows: Set to 0 for 0 space-time streams VHT-SIG-A1 Set to 1 for 1 space-time stream Set to 2 for 2 space-time streams Set to 3 for 3 space-time streams Set to 4 for 4 space-time streams Values 5-7 are reserved For a VHT SU PPDU: B10-B12 Set to 0 for 1 space-time stream Set to 1 for 2 space-time streams Set to 2 for 3 space-time streams Set to 3 for 4 space-time streams Set to 4 for 5 space-time streams Set to 5 for 6 space-time streams Set to 6 for 7 space-time streams Set to 7 for 8 space-time streams B13-B21 Partial AID: Set to the value of the TXVECTOR parameter PARTIAL_AID. Partial AID provides an abbreviated indication of the intended recipient(s) of the PSDU (see 10.20). B22 TXOP_PS_ 1 Set to 0 by VHT AP if it allows non-AP VHT STAs in NOT_ALLO TXOP power save mode to enter doze state during a TXOP. WED Set to 1 otherwise. The bit is reserved and set to 1 in VHT PPDUs transmitted by a non-AP VHT STA. B23 Reserved 1 Set to 1 2544 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-12â€”Fields in the VHT-SIG-A field (continued) Two parts of Number Bit Field Description VHT-SIG-A of bits B0 Short GI 1 Set to 0 if short guard interval is not used in the Data field. Set to 1 if short guard interval is used in the Data field. B1 Short GI 1 Set to 1 if short guard interval is used and NSYM mod 10 = 9; NSYM otherwise, set to 0. NSYM is defined in 21.4.3. Disambiguati on B2 SU/MU[0] 1 For a VHT SU PPDU, B2 is set to 0 for BCC, 1 for LDPC Coding For a VHT MU PPDU, if the MU[0] NSTS field is nonzero, then B2 indicates the coding used for user u with USER_POSITION[u] = 0; set to 0 for BCC and 1 for LDPC. If the MU[0] NSTS field is 0, then this field is reserved and set to 1. B3 LDPC Extra 1 Set to 1 if the LDPC PPDU encoding process (if an SU OFDM PPDU), or at least one LDPC userâ€™s PPDU encoding process Symbol (if a VHT MU PPDU), results in an extra OFDM symbol (or symbols) as described in 21.3.10.5.4 and 21.3.10.5.5. Set to 0 otherwise. B4-B7 SU VHT- 4 For a VHT SU PPDU: MCS/MU[1- VHT-MCS index 3] Coding For a VHT MU PPDU: If the MU[1] NSTS field is nonzero, then B4 indicates VHT-SIG-A2 coding for user u with USER_POSITION[u] = 1: set to 0 for BCC, 1 for LDPC. If the MU[1] NSTS field is 0, then B4 is reserved and set to 1. If the MU[2] NSTS field is nonzero, then B5 indicates coding for user u with USER_POSITION[u] = 2: set to 0 for BCC, 1 for LDPC. If the MU[2] NSTS field is 0, then B5 is reserved and set to 1. If the MU[3] NSTS field is nonzero, then B6 indicates coding for user u with USER_POSITION[u] = 3: set to 0 for BCC, 1 for LDPC. If the MU[3] NSTS field is 0, then B6 is reserved and set to 1. B7 is reserved and set to 1 B8 Beamformed 1 For a VHT SU PPDU: Set to 1 if a beamforming steering matrix is applied to the waveform in an SU transmission, set to 0 otherwise. For a VHT MU PPDU: Reserved and set to 1 NOTEâ€”If equal to 1 smoothing is not recommended. B9 Reserved 1 Reserved and set to 1 B10-B17 CRC 8 CRC calculated as in 19.3.9.4.4 with c7 in B10. Bits 0-23 of HT-SIG1 and bits 0-9 of HT-SIG2 are replaced by bits 0-23 of VHT-SIG-A1 and bits 0-9 of VHT-SIG-A2, respectively. B18-B23 Tail 6 Used to terminate the trellis of the convolutional decoder. Set to 0. 2545 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The time domain waveform for the VHT-SIG-A field in a VHT PPDU shall be as specified in Equation (21-28). 1 i Seg i TX 1 r VHT-SIG-A(t) = --------------------------------------- w TSYML(t â€“ nT SYML) (21-28) Tone N VHT-SIG-A N TX n=0 26 N 20MHz â€“ 1 k â€“ K Shift i BW BW j n Dk n BW + pn + 1 Pk k = â€“ 26 i BW = 0 i TX exp j2 k â€“ K Shift i BW F t â€“ nT SYML â€“ T GI â€“ T CS where N 20MHz and K Shift(i) are defined in 21.3.8.2.4 0 k = 0 7 21 Dk n 20 = d Mr k n otherwise 20 r ( k) M 20 is defined in Equation (21-27) P k and p n are defined in 17.3.5.10 Tone N VHT-SIG-A has the value given in Table 21-8 k BW is defined in Equation (21-14), Equation (21-15), Equation (21-16), and Equation (21-17) i TX T CS represents the cyclic shift for transmitter chain i TX with a value given in Table 21-10 NOTEâ€”This definition results in a QBPSK modulation on the second symbol of VHT-SIG-A where the constellation of the data tones is rotated by 90Âº counter-clockwise relative to the first symbol of VHT-SIG-A and relative to the non-HT signal field in VHT PPDUs (Figure 21-20). In VHT PPDUs, the VHT-SIG-A is transmitted with the same number of subcarriers and the same cyclic shifts as the preceding non-HT portion of the preamble. For an 80+80 MHz transmission, each frequency segment shall use the time domain waveform for 80 MHz transmissions. Q Q Q L-SIG VHT-SIG-A1 VHT-SIG-A2 +1 +1 +1 1 0 1 I 0 1 I I -1 +1 -1 +1 -1 +1 -1 -1 -1 0 Figure 21-20â€”Data tone constellation in the VHT PPDU pre-VHT modulated fields 2546 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 21.3.8.3.4 VHT-STF definition The main purpose of the VHT-STF field is to improve automatic gain control estimation in a MIMO transmission. The duration of the VHT-STF field is TVHT-STF regardless of the Short GI field setting in VHT-SIG-A. The frequency domain sequence used to construct the VHT-STF field in a 20 MHz transmission is identical to the HT-STF field. In a 40 MHz and an 80 MHz transmission, the VHT-STF field is constructed from the 20 MHz version by frequency shifting a duplicate of it to each 20 MHz subchannel and applying appropriate phase rotations per 20 MHz subchannel. For a 20 MHz transmission, the frequency domain sequence is given by Equation (21-29). VHTS â€“28 28 = HTS â€“28 28 (21-29) where HTS â€“28 28 is defined in Equation (19-19) For a 40 MHz transmission, the frequency domain sequence is given by Equation (21-30). VHTS â€“58 58 = HTS â€“58 58 (21-30) where HTS â€“58 58 is defined in Equation (19-20) For an 80 MHz transmission, the frequency domain sequence is given by Equation (21-31). VHTS â€“122 122 = VHTS â€“58 58 0 0 0 0 0 0 0 0 0 0 0 VHTS â€“58 58 (21-31) where VHTS â€“58 58 is given by Equation (21-30) For a 160 MHz transmission, the frequency domain sequence is given by Equation (21-32). VHTS â€“250 250 = VHTS â€“122 122 0 0 0 0 0 0 0 0 0 0 0 VHTS â€“122 122 (21-32) where VHTS â€“122 122 is given by Equation (21-31) NOTEâ€”Equation (21-29), Equation (21-30), Equation (21-31), and Equation (21-32) do not show the phase rotation per 20 MHz subchannel. For an 80+80 MHz transmission, each 80 MHz frequency segment shall use the VHT-STF pattern for the 80 MHz ( VHTS â€“122 122 ) defined in Equation (21-31). The time domain representation of the signal on frequency segment i Seg and transmit chain i TX shall be as specified in Equation (21-33). 2547 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications i Seg i TX 1 r VHT-STF(t) = ------------------------------------------------ w TVHT-STF(t) (21-33) Tone N VHT-STF N STS total N SR N user â€“ 1 N STS u Q kiSeg i TX M u + m k BW VHTS k k = â€“ N SR u=0 m=1 exp j2 k F t â€“ T CS,VHT(M u + m) where Tone N VHT-STF has the value given in Table 21-8 T CS,VHT(n) is given in Table 21-11 Q kiSeg is defined in 21.3.10.11.1 k BW is defined in Equation (21-14), Equation (21-15), Equation (21-16), and Equation (21-17) 21.3.8.3.5 VHT-LTF definition The VHT Long Training field (VHT-LTF) field provides a means for the receiver to estimate the MIMO channel between the set of constellation mapper outputs (or, if STBC is applied, the STBC encoder outputs) and the receive chains. The transmitter provides training for NSTS,total space-time streams (spatial mapper inputs) used for the transmission of the PSDU(s). For each tone, the MIMO channel that can be estimated is an NRX NSTS,total matrix. A VHT transmission has a preamble that contains VHT-LTF symbols, where the data tones of each VHT-LTF symbol are multiplied by entries belonging to a matrix PVHT-LTF, to enable channel estimation at the receiver. The pilot tones of each VHT-LTF symbol are multiplied by the entries of a matrix RVHT-LTF defined in the following text. The multiplication of the pilot tones in the VHT-LTF symbol by the RVHT-LTF matrix instead of the PVHT-LTF matrix allows receivers to track phase and frequency offset during MIMO channel estimation using the VHT-LTF. The number of VHT-LTF symbols, NVHT-LTF, is a function of the total number of space-time streams NSTS,total as shown in Table 21-13. As a result the VHT-LTF field consists of one, two, four, six or eight symbols. Table 21-13â€”Number of VHT-LTFs required for different numbers of space-time streams NSTS,total NVHTLTF 1 1 2 2 3 4 4 4 5 6 6 6 7 8 8 8 2548 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Let LTF left and LTF right be the sequences defined in Equation (21-34) and Equation (21-35), respectively. LTF left = 1 1 â€“1 â€“1 1 1 â€“1 1 â€“ 1 1 1 1 1 1 1 â€“ 1 â€“ 1 1 1 â€“1 1 â€“1 1 1 1 1 (21-34) LTF right = 1 â€“1 â€“1 1 1 â€“1 1 â€“1 1 â€“1 â€“1 â€“1 â€“1 â€“1 1 1 â€“1 â€“1 1 â€“1 1 â€“1 1 1 1 1 (21-35) NOTEâ€” LTF left is identical to the leftmost 26 elements of Equation (17-8), and LTF right is identical to the rightmost 26 elements of Equation (17-8). In a 20 MHz transmission, the VHT-LTF sequence transmitted is given by Equation (21-36). VHT-LTF â€“28 28 = 1 1 LTF left 0 LTF right â€“ 1 â€“ 1 (21-36) = HT-LTF â€“28 28 where HT-LTF â€“28 28 is defined in Equation (19-23) In a 40 MHz transmission, the VHT-LTF sequence transmitted is given by Equation (21-37). VHT-LTF â€“58 58 = LTF left 1 LTF right â€“ 1 â€“ 1 â€“ 1 1 0 0 0 â€“ 1 1 1 â€“ 1 LTF left 1 LTF right (21-37) = HT-LTF â€“58 58 where HT-LTF â€“58 58 is defined in Equation (19-24) In an 80 MHz transmission, the VHT-LTF sequence transmitted is given by Equation (21-38). VHT-LTF â€“122 122 = LTF left 1 LTF right â€“ 1 â€“ 1 â€“ 1 1 1 â€“ 1 1 â€“ 1 1 1 â€“ 1 LTF left 1 LTF right (21-38) 1 â€“1 1 â€“1 0 0 0 1 â€“1 â€“1 1 LTF left 1 LTF right â€“ 1 â€“ 1 â€“ 1 1 1 â€“ 1 1 â€“ 1 1 1 â€“ 1 LTF left 1 LTF right In a 160 MHz transmission, the VHT-LTF sequence transmitted is given by Equation (21-39). VHT-LTF â€“250 250 = VHT-LTF â€“122 122 0 0 0 0 0 0 0 0 0 0 0 VHT-LTF â€“122 122 (21-39) where VHT-LTF â€“122 122 is given in Equation (21-38) NOTEâ€”Equation (21-36), Equation (21-37), Equation (21-38), and Equation (21-39) do not show the phase rotation per 20 MHz subchannel. For a 80+80 MHz transmission, each 80 MHz frequency segment shall use the 80 MHz VHT-LTF sequence, VHT-LTF â€“122 122 , defined in Equation (21-38). 2549 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The generation of the time domain VHT-LTF symbols per frequency segment is shown in Figure 21-21 k where A VHT - LTF is given in Equation (21-40). k AVHT-LTF 1,n VHT-LTFk x IDFT ... ... CSD Qk ... 1:N STS,total IDFT x k AVHT-LTF N STS,total ,n Figure 21-21â€”Generation of VHT-LTF symbols per frequency segment R VHT - LTF if k K Pilot k A VHT (21-40) - LTF = P VHT - LTF otherwise where K Pilot is the set of subcarrier indices for the pilot tones. For a 20 MHz transmission, K Pilot = 7 21 . For a 40 MHz transmission, K Pilot = 11 25 53 . For an 80 MHz transmission, K Pilot = 11 39 75 103 . For a 160 MHz transmission, K Pilot = 25 53 89 117 139 167 203 231 . For an 80+80 MHz transmission, K Pilot for each 80 MHz frequency segment is identical to K Pilot for an 80 MHz transmission. R VHT - LTF is a N VHT - LTF N VHT - LTF matrix whose elements are defined in Equation (21-41). R VHT - LTF = P VHT - LTF 1 m n N VHT - LTF (21-41) m n 1 n P VHT - LTF is defined in Equation (21-42) The time domain representation of the waveform transmitted on frequency segment iSeg of transmit chain iTX shall be as described by Equation (21-42). 2550 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications N VHT-LTF â€“ 1 i Seg i TX 1 r VHT-LTF(t) = ------------------------------------------------ w TVHT-LTF(t â€“ nT VHT-LTF) (21-42) Tone N VHT-LTF N STS total n=0 N SR N user â€“ 1 N STS u Q kiSeg k BW k A VHT - LTF VHT-LTF k i TX M u + m Mu + m n+1 k = â€“ N SR u=0 m=1 exp j2 k F t â€“ nT VHT-LTF â€“ T GI â€“ T CS,VHT(M u + m) where Tone N VHT-LTF has the value given in Table 21-8 T CS,VHT(n) is given in Table 21-11 Q kiSeg is defined in 21.3.10.11.1 k BW is defined in Equation (21-14), Equation (21-15), Equation (21-16), and Equation (21-17) k A VHT - LTF is defined in Equation (21-40) P4 4 N STS total 4 P VHT - LTF = P6 6 N STS total = 5 6 (21-43) P8 8 N STS total = 7 8 where P4 4 is defined in Equation (19-27) The VHT-LTF mapping matrix for six VHT-LTF symbols, P 6 6, is defined in Equation (21-44). 1 â€“1 1 1 1 â€“1 1 2 1 â€“w w w3 w4 â€“w5 P6 = 1 â€“w 2 w4 w6 w8 â€“ w 10 (21-44) 6 1 â€“w 3 w6 w9 w 12 â€“ w 15 1 â€“w 4 w8 w 12 w 16 â€“ w 20 1 â€“w 5 w 10 w 15 w 20 â€“ w 25 where w = exp â€“ j2 6 The VHT-LTF mapping matrix for eight VHT-LTF symbols, P 8 8 , is defined in Equation (21-45). P4 4 P4 4 P8 8 = (21-45) P4 4 â€“P4 4 where P4 4 is defined in Equation (19-27) 2551 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications As defined in Table 21-5, the duration of each VHT-LTF symbol is T VHT-LTF regardless of the Short GI field setting in VHT-SIG-A. 21.3.8.3.6 VHT-SIG-B definition The VHT-SIG-B field is one symbol and contains 26 bits in a 20 MHz PPDU, 27 bits in a 40 MHz PPDU, and 29 bits in 80 MHz, 160 MHz, and 80+80 MHz PPDUs for each user. The fields in the VHT-SIG-B field are listed in Table 21-14. For fields consisting of multiple bits, the LSB of the value occupies the lowest numbered bit of the field. For example, for an MU transmission using VHT-MCS 5 (0101 in binary) in 20 MHz bandwidth, the VHT-SIG-B field bits are set as follows: B16=1, B17=0, B18=1, and B19=0. Table 21-14â€”Fields in the VHT-SIG-B field VHT MU PPDU Allocation (bits) VHT SU PPDU Allocation (bits) Field 80 MHz, 80 MHz, Description 20 MHz 40 MHz 160 MHz, 20 MHz 40 MHz 160 MHz, 80+80 MHz 80+80 MHz VHT-SIG-B B0-B15 B0-B16 B0-B18 B0-B16 B0-B18 B0-B20 Length of A- Length (16) (17) (19) (17) (19) (21) MPDU pre-EOF padding in units of four octets VHT-MCS B16-B19 B17-B20 B19-B22 N/A N/A N/A (4) (4) (4) Reserved N/A N/A N/A B17-B19 B19-B20 B21-B22 All 1s (3) (2) (2) Tail B20-B25 B21-B26 B23-B28 B20-B25 B21-B26 B23-B28 All 0s (6) (6) (6) (6) (6) (6) Total # bits 26 27 29 26 27 29 NOTEâ€”Due to the limitations in the maximum A-MPDU length, B19-20 are always 0 for an 80 MHz, 160 MHz, and 80+80 MHz VHT SU PPDU. The VHT-SIG-B Length field for user u shall be set using Equation (21-46). APEP_LENGTH VHT-SIG-B Length (for user u in units of 4 octets) = -------------------------------------------u- (21-46) 4 where APEP_LENGTHu is the TXVECTOR parameter APEP_LENGTH for user u (in octets) The VHT-SIG-B bits for an NDP transmission in various channel widths shall be set as defined in Table 21-15. 2552 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-15â€”VHT-SIG-B bits (before Tail field) in NDP for various channel widths Channel B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 B10 B11 B12 B13 B14 B15 B16 B17 B18 B19 B20 B21 B22 Width 20 MHz 0 0 0 0 0 1 1 1 0 1 0 0 0 1 0 0 0 0 1 0 â€“ â€“ â€“ 40 MHz 1 0 1 0 0 1 0 1 1 0 1 0 0 0 1 0 0 0 0 1 1 - â€“ 80 MHz, 160 MHz, or 80+80 0 1 0 1 0 0 1 1 0 0 1 0 1 1 1 1 1 1 1 0 0 1 0 MHz For a 40 MHz transmission, the VHT-SIG-B bits are repeated twice. For an 80 MHz transmission, the VHT- SIG-B bits are repeated four times and a pad bit appended that is set to 0. For a 160 MHz and 80+80 MHz transmission, the VHT-SIG-B bits are first repeated four times and a pad bit appended that is set to 0 as in the 80 MHz transmission. Then, the resulting 117 bits are repeated again to fill the 234 available bits. The repetition of the VHT-SIG-B bits for various channel width PPDUs is shown in Figure 21-22. 6 tail 20 MHz 20 bits bits 6 tail 6 tail 40 MHz 21 bits 21 bits bits bits Repeated 6 tail 6 tail 6 tail 6 tail 1 Pad 80 MHz 23 bits 23 bits 23 bits 23 bits bits bits bits bits bit Repeated 160 MHz 6 tail 6 tail 6 tail 6 tail 1 Pad 6 tail 6 tail 6 tail 6 tail 1 Pad 23 bits 23 bits 23 bits 23 bits 23 bits 23 bits 23 bits 23 bits 80+80 MHz bits bits bits bits bit bits bits bits bits bit Repeated Repeated Figure 21-22â€”VHT-SIG-B bits in 20 MHz, 40 MHz, 80 MHz, 160 MHz, and 80+80 MHz transmissions For each user u, the VHT-SIG-B field shall be BCC encoded at rate R = 1/2 as defined in 17.3.5.6, be segment parsed as defined in 21.3.10.7, be interleaved as defined in 21.3.10.8, be mapped to a BPSK constellation as defined in 17.3.5.8, be segment deparsed as defined in 21.3.10.9.3, and have pilots inserted following the steps described in 21.3.10.10. The VHT-SIG-B field constellation points are mapped to NSTS,u space-time streams by the user-specific elements of the first column of the PVHT-LTF matrix, which is defined in clause 21.3.8.3.5. The total number of data subcarriers and pilot subcarriers are the same as in the Data field. The space-time streams per each frequency segment are input into the CSD block, which is defined in Table 21-11 and follow the same transmission flow as the Data field from there on. The duration of the VHT-SIG-B field is TVHT-SIG-B, regardless of the value of the TXVECTOR parameter GI_TYPE. The time domain waveform for the VHT-SIG-B field in a VHT PPDU is specified by Equation (21-47). 2553 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications i Seg i TX 1 r VHT-SIG-B(t) = ---------------------------------------------------- w TVHT-SIG-B(t) (21-47) Tone N VHT-SIG-B N STS total N SR N user â€“ 1 N STS u i u k Q kiSeg k BW P VHT - LTF Mu + m 1 D k Seg BW + p 3 P 0 i TX M u + m k = â€“ N SR u=0 m=1 exp j2 k F t â€“ T GI â€“ T CS,VHT(M u + m) where Tone N VHT-SIG-B has the value given in Table 21-8 T CS,VHT(n) is given in Table 21-11 Q kiSeg is defined in 21.3.10.11.1 pn is defined in 17.3.5.10 P nk is defined in 21.3.10.10 k BW is defined in Equation (21-14), Equation (21-15), Equation (21-16), and Equation (21-17) P VHT - LTF is given in Equation (21-43) i Seg u Let d k be the stream of complex numbers generated for VHT-SIG-B for user u at subcarrier k (logical index, starting with 0) on frequency segment iSeg (prior to multiplication by PVHT-LTF). For a 20 MHz VHT transmission, i Seg u 0 k=0 7 21 Dk 20 = i Seg u (21-48) d Mr k otherwise 20 k + 28 â€“ 28 k â€“ 22 k + 27 â€“ 20 k â€“ 8 r M 20 k = k + 26 â€“6 k â€“1 (21-49) k + 25 1 k 6 k + 24 8 k 20 k + 23 22 k 28 For a 40 MHz VHT transmission, i Seg u 0 k=0 1 11 25 53 Dk 40 = i Seg u (21-50) d Mr k otherwise 40 2554 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications k + 58 â€“ 58 k â€“ 54 k + 57 â€“ 52 k â€“ 26 k + 56 â€“ 24 k â€“ 12 r k + 55 â€“ 10 k â€“ 2 M 40 k = (21-51) k + 52 2 k 10 k + 51 12 k 24 k + 50 26 k 52 k + 49 54 k 58 For an 80 MHz VHT transmission, i Seg u 0 k=0 1 11 39 75 103 Dk 80 = i Seg u (21-52) d Mr k otherwise 80 k + 122 â€“ 122 k â€“ 104 k + 121 â€“ 102 k â€“ 76 k + 120 â€“ 74 k â€“ 40 k + 119 â€“ 38 k â€“ 12 r k + 118 â€“ 10 k â€“ 2 M 80 k = (21-53) k + 115 2 k 10 k + 114 12 k 38 k + 113 40 k 74 k + 112 76 k 102 k + 111 104 k 122 For a 160 MHz VHT transmission, i Seg u 0 k=0 1 2 3 4 5 25 53 89 117 127 128 129 139 167 203 231 Dk 160 = i Seg u d Mr otherwise 160 k (21-54) 2555 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications k + 250 â€“ 250 k â€“ 232 k + 249 â€“ 230 k â€“ 204 k + 248 â€“ 202 k â€“ 168 k + 247 â€“ 166 k â€“ 140 k + 246 â€“ 138 k â€“ 130 k + 243 â€“ 126 k â€“ 118 k + 242 â€“ 116 k â€“ 90 k + 241 â€“ 88 k â€“ 54 k + 240 â€“ 52 k â€“ 26 r k + 239 â€“ 24 k â€“6 M 160 k = (21-55) k + 228 6 k 24 k + 227 26 k 52 k + 226 54 k 88 k + 225 90 k 116 k + 224 118 k 126 k + 221 130 k 138 k + 220 140 k 166 k + 219 168 k 202 k + 218 204 k 230 k + 217 232 k 250 For an 80+80 MHz VHT transmission, each frequency segment shall follow the 80 MHz VHT transmission format as specified in Equation (21-52) and Equation (21-53). 21.3.9 Transmission of NON_HT and HT PPDUs with multiple transmit chains 21.3.9.1 Transmission of 20 MHz NON_HT PPDUs with more than one transmit chain A VHT STA that transmits a NON_HT PPDU shall apply the cyclic shifts defined in Table 21-10 to the preamble and Data field. 21.3.9.2 Transmission of HT PPDUs with more than four transmit chains A VHT STA that transmits an HT PPDU with FORMAT equal to HT_MF shall apply the cyclic shifts defined in Table 21-10 for the non-HT portion of the PPDU, including the HT-SIG field. 21.3.10 Data field 21.3.10.1 General The number of OFDM symbols in the Data field is determined by the Length field in L-SIG (see Equation (21-24)), the preamble duration and the setting of the Short GI field in VHT-SIG-A (see 21.3.8.3.3). When BCC encoding is used, the Data field shall consist of the SERVICE field, the PSDU, the PHY pad bits, and the tail bits ( N tail N ES bits for SU and N tail N ES u bits for each user u in MU). When LDPC encoding is used, the Data field shall consist of the SERVICE field, the PSDU, and the PHY pad bits. No tail bits are present when LDPC encoding is used. 2556 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The padding flow is as follows. The MAC delivers a PSDU that fills the available octets in the Data field of the PPDU for each user u. The PHY determines the number of pad bits to add and appends them to the PSDU. The number of pad bits added will always be 0 to 7 per user. When user u of a VHT MU PPDU uses BCC encoding, the number of pad bits is calculated using Equation (21-56). In the case of SU ignore u in Equation (21-56). N PAD u = N SYM N DBPS u â€“ 8 PSDU_LENGTH u â€“ N service â€“ N tail N ES u (21-56) where PSDU_LENGTH u is defined in 21.4.3 N SYM is the number of symbols in the Data field and is given by Equation (21-111) for a VHT SU PPDU and by Equation (21-67) for a VHT MU PPDU For an SU PPDU, if LDPC encoding is used then the PHY padding bits are calculated using Equation (21- 57). N PAD = N SYM init N DBPS â€“ 8 PSDU_LENGTH â€“ N service (21-57) where PSDU_LENGTH is defined in 21.4.3 N SYM init is given by Equation (21-62) For a VHT MU PPDU, if LDPC encoding is used for user u then the PHY padding bits are calculated using Equation (21-58). N PAD u = N SYM_max_init N DBPS u â€“ 8 PSDU_LENGTH u â€“ N service (21-58) where PSDU_LENGTH u is defined in 21.4.3 N SYM_max_init is given by Equation (21-65) The Data field of the VHT PPDU contains data for one or more users. For a VHT MU PPDU, the data processing, from scrambling to constellation mapping shall happen on a per-user basis. In the following subclauses, this process is described from a single userâ€™s point of view. 21.3.10.2 SERVICE field The SERVICE field is as shown in Table 21-16. Table 21-16â€”SERVICE field Bits Field Description B0-B6 Scrambler Initialization Set to 0 B7 Reserved Set to 0 B8-B15 CRC CRC calculated over VHT-SIG-B (excluding tail bits) 2557 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 21.3.10.3 CRC calculation for VHT-SIG-B The CRC calculation and insertion is illustrated in Figure 21-23. VHT-SIG-B SERVICE field 20 bits (20 MHz), 21 bits (40 MHz), Tail Scrambler Init Reserved CRC 23 bits (80 MHz, 160 MHz and 80+80 MHz) (6 bits) (7 bits) (1 bit) (8 bits) Figure 21-23â€”VHT-SIG-B and SERVICE field relationship The value of the CRC field shall be the 1s complement of Equation (21-59). crc(D) = M(D) I(D) D 8 modG D (21-59) where M D = m0 DN â€“ 1 + m1 DN â€“ 2 + + mN â€“ 2 D + mN â€“ 1 N is the number of bits over which the CRC is generated; 20 for 20 MHz, 21 for 40 MHz, and 23 for 80 MHz/160 MHz/80+80 MHz mi is bit i of VHT-SIG-B Nâ€“1 I D = D i are initialized values that are added modulo 2 to the first 8 bits of VHT-SIG-B i = Nâ€“8 G D = D 8 + D 2 + D + 1 is the CRC generating polynomial crc D = c 0 D 7 + c 1 D 6 + + c6 D + c7 Figure 19-8 shows the operation of the CRC. First, the shift register is reset to all 1s. The bits are then passed through the XOR operation at the input. When the last bit has entered, the output is generated by shifting the bits out of the shift register, c7 first, through an inverter. As an example, if bits {m0, â€¦ m22} are given by {1 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1}, the CRC bits {c7, â€¦ c0} are {0 0 0 1 1 1 0 0}. The CRC field is transmitted with c7 first. Hence, c7 is mapped to B8 of the SERVICE field, c6 is mapped to B9, â€¦, and c0 is mapped to B15 of the SERVICE field. 21.3.10.4 Scrambler The SERVICE, PSDU, and PHY pad parts of the Data field shall be scrambled by the scrambler defined in 17.3.5.5. The Clause 17 TXVECTOR parameters CH_BANDWIDTH_IN_NON_HT and DYN_BANDWIDTH_IN_NON_HT are not present; therefore, the initial state of the scrambler is set to a pseudorandom nonzero seed. Different users in a VHT MU PPDU may use different pseudorandom nonzero seeds. 2558 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 21.3.10.5 Coding 21.3.10.5.1 General The Data field shall be encoded using either the binary convolutional code (BCC) defined in 21.3.10.5.2 and 21.3.10.5.3 or the low density parity check (LDPC) code defined in 21.3.10.5.4. The encoder is selected by the SU/MU[0] Coding, MU[1] Coding, MU[2] Coding, or MU[3] Coding fields in VHT-SIG-A, as defined in 21.3.8.3.3. When BCC FEC encoding is used, the number of encoders is determined by rate-dependent parameters as defined in 21.5. The operation of the BCC FEC is described in 21.3.10.5.2 and 21.3.10.5.3. The operation of the LDPC coder is described in 21.3.10.5.4. Support for the reception of a BCC encoded Data field is mandatory. 21.3.10.5.2 BCC encoder parsing operation If multiple encoders are used, the scrambled SERVICE, PSDU, and PHY pad bits are divided between the encoders by sending bits to different encoders in a round robin manner. Bit i to encoder j of user u, denoted x i ju , is as specified in Equation (21-60). N DBPS u b NES u + j u ; 0 i N SYM ------------------ - â€“ N tail 0 j N ES u â€“ 1 N ES u xi j u = (21-60) N DBPS u N DBPS u 0 ; N SYM ------------------ - â€“ N tail i N SYM ------------------ - 0 j N ES u â€“ 1 N ES u N ES u where bk,u is bit k of the scrambled SERVICE, PSDU, and pad bits of user u NSYM is the number of symbols in the Data field and is given by Equation (21-111) for a VHT SU PPDU and by Equation (21-67) for a VHT MU PPDU NOTEâ€”Tail bits with value 0 are being appended to each BCC encoder parser output sequence in Equation (21-60). 21.3.10.5.3 Binary convolutional coding and puncturing The BCC encoder parser output sequences of user u x i ju 0 i N SYM N DBPS u N ES u 0 j N ES u â€“ 1 each of which is separately encoded by a rate R = Â½ convolutional encoder defined in 17.3.5.6. After encoding, the encoded data is punctured by the method defined in 17.3.5.6 (except for rate 5/6), to achieve the rate selected by the modulation and coding scheme. In the case that rate 5/6 coding is selected, the puncturing scheme will be the same as described in 19.3.11.6. 21.3.10.5.4 LDPC coding For a VHT SU PPDU using LDPC coding to encode the Data field, the LDPC code and encoding process described in 19.3.11.7 shall be used with the following modifications. First, all bits in the Data field including the scrambled SERVICE, PSDU, and pad bits are encoded. Thus, N pld for VHT PPDUs shall be computed using Equation (21-61) instead of Equation (19-35). N pld = N SYM init N DBPS (21-61) where N SYM init is given by Equation (21-62) 2559 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 8 APEP_LENGTH + N service N SYM init = m STBC -------------------------------------------------------------------------- (21-62) m STBC N DBPS where m STBC is equal to 2 when STBC is used, and 1 otherwise APEP_LENGTH is the TXVECTOR parameter APEP_LENGTH Following the calculation of N pld , N avbits shall be computed using Equation (21-63) instead of Equation (19-36). N avbits = N SYM init N CBPS (21-63) In addition, if N SYM computed in Equation (19-41) in step d) of 19.3.11.7.5 is greater than N SYM init , then the LDPC Extra OFDM Symbol field of VHT-SIG-A shall be set to 1. Otherwise, the LDPC Extra OFDM Symbol field of VHT-SIG-A shall be set to 0. LDPC codes used in VHT MU PPDUs shall also follow the definitions in 19.3.11.7. Refer to 21.3.10.5.5 for a description of the LDPC encoding process for VHT MU PPDUs. 21.3.10.5.5 Encoding process for VHT MU PPDUs For a VHT MU PPDU, first compute the initial number of OFDM symbols for each user using Equation (21-64). 8 APEP_LENGTH u + N service + N tail N ES u --------------------------------------------------------------------------------------------------------------- when user u uses BCC N DBPS u N SYM_init u = (21-64) 8 APEP_LENGTH u + N service ---------------------------------------------------------------------------- when user u uses LDPC N DBPS u where APEP_LENGTH u is the TXVECTOR parameter APEP_LENGTH for user u Based on the above equation, compute the largest initial number of symbols over all users using Equation (21-65). N user â€“ 1 N SYM_max_init = max N SYM_init u u=0 (21-65) Then, for each user u that uses LDPC in the VHT MU PPDU, the final number of symbols in the Data field (NSYM,u) shall be computed as follows. First, perform step a) in 19.3.11.7.5 with the exception that Npld is computed using Equation (21-66) instead of Equation (19-35). N pld = N SYM_max_init N DBPS u (21-66) Then, perform steps b) through d) in 19.3.11.7.5 with NCBPS and R replaced with NCBPS,u and Ru, respectively. NSYM,u for user u shall then be equal to the value of NSYM obtained at the end of step d) using Equation (19-41). 2560 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The purpose of going through steps a) to d) in 19.3.11.7.5 in the above paragraph is to compute NSYM,u. Thus, at this stage NSYM,u for each user may be calculated without actually encoding the data using LDPC. For BCC users, N SYM u = N SYM_init u . Then, compute the number of symbols in the Data field using Equation (21-67). N user â€“ 1 N SYM = max N SYM u u=0 (21-67) When constructing the Data field for user u encoded using LDPC code, the MAC follows the padding procedure described in 10.13.6 and delivers a PSDU that contains PSDU_LENGTHu octets (see 21.4.3). The PHY follows the padding procedure described in 21.3.10.1 to fill N SYM_max_init symbols, where N SYM_max_init is defined in Equation (21-65). Then, for each user, all bits in the Data field including the scrambled SERVICE, PSDU, and pad bits shall be encoded using the LDPC encoding process specified in 19.3.11.7.5 with the following modifications. First, N pld shall be computed using Equation (21-66) instead of Equation (19-35). Also, replace NCBPS and R with NCBPS,u and Ru, respectively. Next, step d) in 19.3.11.7.5 is replaced with step d) below: d) If NSYM computed in Equation (21-67) is equal to N SYM_max_init , then the number of bits to be punctured, N punc , from the codewords after encoding is computed as shown in Equation (19-38). If NSYM computed in Equation (21-67) is greater than N SYM_max_init , then the number of bits to be punctured, N punc , from the codewords after encoding is computed using Equation (19-39) and Equation (20-40). Note also that Navbits has now been updated in Equation (19-39) in this case. The punctured bits shall be equally distributed over all NCW codewords with the first rem(N punc N CW) codewords punctured 1 bit more than the remaining codewords. Define N ppcw = N punc N CW . When N ppcw 0 , the puncturing is performed by discarding parity bits p n â€“ k â€“ Nppcw â€“ 1 p n â€“ k â€“ 1 of the first rem(N punc N CW) codewords and discarding parity bits p n â€“ k â€“ N ppcw p n â€“ k â€“ 1 of the remaining codewords after encoding. When constructing the Data field for users encoded using BCC, the MAC follows the padding procedure described in 10.13.6 and delivers a PSDU that contains PSDU_LENGTHu octets. The PHY follows the padding procedure described in 21.3.10.1 to fill up NSYM symbols computed in Equation (21-67). Then, for each user, all bits in the Data field including the scrambled SERVICE, PSDU, and pad bits shall be encoded using the BCC encoding process specified in 21.3.10.5.2 and 21.3.10.5.3. Note that this process results in the BCC tail bits being placed at the very end of the PPDU. In addition, if NSYM computed in Equation (21-67) is greater than N SYM_max_init computed in Equation (21-65), then the LDPC Extra OFDM Symbol field of VHT-SIG-A2 shall be set to 1. Otherwise, the LDPC Extra OFDM Symbol field of VHT-SIG-A2 shall be set to 0. 21.3.10.6 Stream parser After coding and puncturing, the data bit streams at the output of the FEC encoders are processed in groups of NCBPS bits. Each of these groups is rearranged into NSS blocks of NCBPSS bits (NSS,u blocks of NCBPSS,u bits in the case of an MU transmission). This operation is referred to as stream parsing and is described in this subclause. The description is given in terms of an SU transmission. For MU transmissions, the rearrangements are carried out in the same way per user. 2561 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The number of bits assigned to a single axis (real or imaginary) of a constellation point in a spatial stream is denoted by Equation (21-68). N BPSCS s = max 1 ---------------- - (21-68) 2 The sum of these over all streams is S = N SS s Consecutive blocks of s bits are assigned to different spatial streams in a round robin fashion. Let N CBPS N Block = --------------- - (21-69) N ES S and N CBPS â€“ N Block N ES S M = ------------------------------------------------------- - (21-70) s N ES For the first N Block N ES S bits of each OFDM symbol, S bits from the output of first encoder are divided among all spatial streams, s bits per stream. Then, S bits from the output of next encoder are used, and so on. If N CBPS is greater than N Block N ES S , then for the last N CBPS â€“ N Block N ES S bits of each OFDM symbol, M s bits from the output of the first encoder are fed into spatial streams 1 through M (s bits per spatial stream), and then M s bits from the output of the next encoder are used for spatial stream M + 1 through 2M â€“ 1 mod N SS + 1 , and so on, where z mod t is the remainder resulting from the division of integer z by integer t. The following equations are an equivalent description to the above procedure. Bit i at the output of encoder j is assigned to input bit k of spatial stream i SS where k-- mod N k = 0 1 N Block N ES s â€“ 1 ES s j = (21-71) L k = N Block N ES s N CBPSS â€“ 1 ----- M and i SS â€“ 1 s + S k - + k mod s --------------- k = 0 1 N Block N ES s â€“ 1 i = N ES s (21-72) L mod M s + N Block S + k mod s k = N Block N ES s N CBPSS â€“ 1 where i SS = 1 2 N SS i = 0 1 N CBPS N ES â€“ 1 j = 0 1 N ES â€“ 1 k = 0 1 N CBPSS â€“ 1 2562 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications L = k' N + i â€“ 1 --- SS SS s k' = k â€“ N Block N ES s NOTEâ€”NCBPS is greater than N Block N ES S in only the following cases: â€” 160 MHz and 80+80 MHz, NSS = 5, VHT-MCS = 5 â€” 160 MHz and 80+80 MHz, NSS = 5, VHT-MCS = 6 â€” 160 MHz and 80+80 MHz, NSS = 7, VHT-MCS = 5 â€” 160 MHz and 80+80 MHz, NSS = 7, VHT-MCS = 6 21.3.10.7 Segment parser The description in this subclause is given in terms of an SU transmission. For MU transmissions, the rearrangements are carried out in the same way per user. For a 160 MHz or an 80+80 MHz transmission, the output bits of each stream parser are first divided into blocks of NCBPSS bits (NCBPSS,u bits in the case of an MU transmission). Then, each block is further divided into two frequency subblocks of N CBPSS 2 bits as shown in Equation (21-73). N CBPSS yk l = x k - + l s N + k mod(s N ) k = 0 1 ----------------- â€“ 1 (21-73) 2 s N ES --------------- s N ES ES ES 2 where xm is the m th bit of a block of N CBPSS bits, m= 0 to N CBPSS â€“ 1 l is the frequency subblock index, l = 0 1 yk l is bit k of the frequency subblock l s is defined in Equation (21-68) If NCBPSS is not divisible by 2s N ES , then apply the segment parsing method described in Equation (21-73) for N CBPSS sets of 2s N ES segment parser input bits. At this point, each stream parser 2s N ES N CBPSS mod(2s N ES) output has 2s N res ( N res = ---------------------------------------------------- - N ES integer ) residue bits. Then, the residue bits are 2s divided into subsets of s bits, with each subset being assigned to different subblock ( l = 0 1 ) in a round robin fashion. The first s bits are assigned to the subblock with index l = 0 . Repeat Nres times (until all bits are distributed to the two subblocks). That is, if N CBPSS is not divisible by 2s N ES , each block is further divided into two subblocks of N CBPSS 2 bits as shown in Equation (21-74). x k - + l s N + k mod(s N ) k = 0 1 N CBPSS 2s N ES s N ES â€“ 1 (21-74) 2 s N ES --------------- ES ES s N ES yk l = N CBPSS x k - + 2s k mod(s N ES) k = N CBPSS 2s N ES s N ES ---------------- -â€“1 2 s N ES --------------- - + l s + k mod s ---------------------------------- 2 s N ES s 2563 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Segment parser is bypassed for a 20 MHz, 40 MHz, or 80 MHz VHT PPDU transmission, i.e., as specified in Equation (21-75). yk l = xk k = 0 1 N CBPSS â€“ 1 (21-75) where l is the frequency subblock index. l = 0 for a 20, 40 or 80 MHz VHT PPDU transmission. yk l is bit k of the frequency subblock l xm is bit m of a block of N CBPSS bits, m = 0 to N CBPSS â€“ 1 21.3.10.8 BCC interleaver For ease of explanation, the operation of the interleaver is described for the SU case. For user u of an MU transmission, the interleaver operates in the same way on the output bits for the user from the stream parser by replacing NSS, NCBPSS, NCBPSSI, and NBPSCS with NSS,u, NCBPSS,u, NCBPSSI,u, and NBPSCS,u, respectively. That is, the operation of the interleaver is the same as if the transmission were an SU one, consisting of bits from only that user. This subclause describes the interleaver used in the case of BCC encoding. The interleaver described in this subclause shall be bypassed in the case of LDPC encoding. In a 20 MHz, 40 MHz, or 80 MHz VHT PPDU transmission, the bits at the output of the stream parser are processed in groups of NCBPS bits. Each of these groups is divided into NSS blocks of NCBPSS bits, and each block shall be interleaved by an interleaver based on the Clause 17 interleaver. In a 160 MHz or an 80+80 MHz VHT PPDU transmission, each frequency subblock of NCBPSS/2 output bits from the segment parser is interleaved by the interleaver for 80 MHz defined in this subclause. This interleaver, which is based on entering the data in rows, and reading it out in columns, has a different number of columns N COL and rows N ROW for different bandwidths. The values of N COL and N ROW are given in Table 21-17. Table 21-17â€”Number of rows and columns in the interleaver Parameter 20 MHz 40 MHz 80 MHz N COL 13 18 26 N ROW 4 N BPSCS 6 N BPSCS 9 N BPSCS N ROT (NSS â‰¤ 4) 11 29 58 N ROT (NSS > 4) 6 13 28 After the operations based on the Clause 17 interleaver have been applied and if more than one spatial stream exists, a third operation called frequency rotation is applied to the additional spatial streams. The parameter for the frequency rotation is NROT. The values of NROT are given in Table 21-17. An additional parameter is the spatial stream index i SS = 1 2 N SS . The output of the third operation is a function of the spatial stream index. 2564 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The interleaving is defined using three permutations. The first permutation is given by the rule shown in Equation (21-76). k i = N ROW k mod N COL + ------------ k = 0 1 N CBPSSI â€“ 1 (21-76) - N COL The second permutation is defined by the rule shown in Equation (21-77). N COL i j = s -i + i + N CBPSSI â€“ ------------------ - mod s i = 0 1 N CBPSSI â€“ 1 (21-77) s N CBPSSI where s is defined in Equation (21-68) If 2 N SS 4 , a frequency rotation is applied to the output of the second permutation as shown in Equation (21-78). i SS â€“ 1 r = jâ€“ 2 i SS â€“ 1 mod 3 + 3 -------------- - N ROT N BPSCS mod N CBPSSI (21-78) 3 j = 0 1 N CBPSSI â€“ 1 where i SS = 1 2 N SS is the spatial steam index on which this interleaver is operating If N SS 4 , a frequency rotation is applied to the output of the second permutation as shown in Equation (21- 79). r = j â€“ J(i SS) N ROT N BPSCS mod N CBPSSI j = 0 1 N CBPSSI â€“ 1 (21-79) where i SS = 1 2 N SS is the spatial steam index on which this interleaver is operating, and J iSS is an integer as defined in Table 21-18. Table 21-18â€” J(iSS) values i SS J i SS 1 0 2 5 3 2 4 7 5 3 6 6 7 1 8 4 2565 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The deinterleaver uses the following three operations to perform the inverse permutations. Let r denote the index of the bit in the received block (per spatial stream). The first operation reverses the third (frequency rotation) permutation of the interleaver. When N SS = 1 , this reversal is performed by j = r (r = 0 1 N CBPSSI â€“ 1 ). When 2 N SS 4 , this reversal is performed by as shown in Equation (21-80). i SS â€“ 1 j = r+ 2 i SS â€“ 1 mod 3 + 3 -------------- - N ROT N BPSCS mod N CBPSSI (21-80) 3 r = 0 1 N CBPSSI â€“ 1 When N SS 4 , this reversal is performed by Equation (21-81). j = r + J(i SS) N ROT N BPSCS mod N CBPSSI r = 0 1 N CBPSSI â€“ 1 (21-81) where J(i SS) is defined in Table 21-18 The second operation defined by Equation (21-82) reverses the second permutation in the interleaver. N COL j i = s -j + j + ------------------ - mod s j = 0 1 N CBPSSI â€“ 1 (21-82) s N CBPSSI where s is defined in Equation (21-68) The third operation defined in Equation (21-83) reverses the first permutation of the interleaver. k = N COL i â€“ N CBPSSI â€“ 1 i ------------- i = 0 1 N CBPSSI â€“ 1 (21-83) N ROW 21.3.10.9 Constellation mapping 21.3.10.9.1 General The mapping between bits at the output of the interleaver and complex constellation points for BPSK, QPSK, 16-QAM, and 64-QAM follows the rules defined in 17.3.5.8. For 256-QAM, the mapping is shown in Figure 21-24, Figure 21-25, Figure 21-26, and Figure 21-27. The bit string convention in Figure 21-24, Figure 21-25, Figure 21-26, and Figure 21-27 follows the bit string convention outlined in 17.3.5.8. The streams of complex numbers in frequency subblock l for user u are denoted 2566 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Figure 21-24â€”Constellation bit encoding for 256-QAM (1st quadrant) 2567 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Figure 21-25â€”Constellation bit encoding for 256-QAM (2nd quadrant) 2568 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Figure 21-26â€”Constellation bit encoding for 256-QAM (3rd quadrant) 2569 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Figure 21-27â€”Constellation bit encoding for 256-QAM (4th quadrant) 2570 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications d' k i n l u; k=0 1 N SD â€“ 1 for 20 MHz, 40 MHz, 80 MHz, and 80+80 MHz; (21-84) Â· N SD Â· k = 0 1 --------- â€“ 1 for 160 MHz; 2 i = 1 N SS u ; n = 0 1 N SYM â€“ 1 ; l = 0 for 20 MHz, 40 MHz, and 80 MHz; l = 0 1 for 160 MHz and 80+80 MHz; u = 0 N user â€“ 1 The normalization factor, KMOD, for 256-QAM is 1 170 . 21.3.10.9.2 LDPC tone mapping The LDPC tone mapping shall be performed on all LDPC encoded streams as described in this subclause and using an LDPC tone-mapping distance parameter D TM . D TM is constant for each bandwidth and its value for different bandwidths is given in Table 21-19. LDPC tone mapping shall not be performed on streams that are encoded using BCC. Table 21-19â€”LDPC tone mapping distance for each bandwidth 160 MHz, Parameter 20 MHz 40 MHz 80 MHz 80+80 MHz D TM 4 6 9 9 For a VHT PPDU transmission, the LDPC tone mapping for LDPC-coded streams corresponding to user u is done by permuting the stream of complex numbers generated by the constellation mappers (see Equation (21-84)) to obtain d'' t(k) i n l u = d' k i n l u; k=0 1 N SD â€“ 1 for 20 MHz, 40 MHz, 80 MHz and 80+80 MHz; (21-85) Â· N SD Â· k = 0 1 --------- â€“ 1 for 160 MHz; 2 i = 1 N SS u ; n = 0 1 N SYM â€“ 1 ; l = 0 for 20 MHz, 40 MHz, and 80 MHz; l = 0 1 for 160 MHz and 80+80 MHz; u = 0 N user â€“ 1 2571 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications where N SD k D TM D TM k mod --------- - + ----------------- for 20 MHz, 40 MHz, 80 MHz, and 80+80 MHz D TM N SD t(k) = (21-86) N SD 2 k D TM D TM k mod --------------- - + ----------------- for 160 MHz D TM N SD 2 As a result of the LDPC tone mapping operation above, each two consecutively generated complex constellation numbers d' k i n l u and d' k + 1 i n l u will be transmitted on two data tones that are separated by at least D TM â€“ 1 other data tones. Note that the operation above is equivalent to block-interleaving the complex numbers d' 0 i n l u for each i, n, and u using a matrix with D TM rows and d' NSD â€“ 1 i n l u N SD N SD D TM (for 20 MHz, 40 MHz, 80 MHz, or 80+80 MHz) or ----------------- - (for 160 MHz) columns, where 2 D TM d' 0 i n l u d' NSD â€“ 1 i n l u are written row-wise into the matrix, and d'' 0 i n l u d'' NSD â€“ 1 i n l u are read column-wise from the matrix. NOTEâ€”LDPC tone mapping is performed separately for the upper and lower 80 MHz segments of a 160 MHz of 80+80 MHz transmission as indicated by the frequency subblock index l in Equation (21-85) and Equation (21-86). Since LDPC tone mapping is not performed on BCC-coded streams, for BCC-coded streams, the following applies: d'' k i n l u = d' k i n l u; k=0 1 N SD â€“ 1 for 20 MHz, 40 MHz, 80 MHz and 80+80 MHz; (21-87) Â· N SD Â· k = 0 1 --------- â€“ 1 for 160 MHz; 2 i = 1 N SS u ; n = 0 1 N SYM â€“ 1 ; l = 0 for 20 MHz, 40 MHz, and 80 MHz; l = 0 1 for 160 MHz and 80+80 MHz; u = 0 N user â€“ 1 21.3.10.9.3 Segment deparser In a 160 MHz VHT PPDU transmission, the two frequency subblocks at the output of the LDPC tone mapper for LDPC or constellation mapper for BCC are combined into one frequency segment as shown in Equation (21-88). N SD d'' k i n 0 u if 0 k --------- â€“ 1 2 d kiSeg i n u = i Seg = 0 (21-88) N SD d'' k â€“ NSD 2 i n 1 u if -------- - k N SD â€“ 1 2 2572 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications In a 20 MHz, 40 MHz, or 80 MHz VHT PPDU transmission, the segment deparsing is not performed. Hence, d kiSeg i n u = d'' k i n 0 u 0 k N SD â€“ 1 i Seg = 0 (21-89) In an 80+80 MHz VHT PPDU transmission, the segment deparsing is not performed. Hence, d kiSeg i n u = d '' k i n i Seg u 0 k N SD â€“ 1 i Seg = 0 1 (21-90) NOTEâ€”As per Table 21-7, f c 0 (center frequency for frequency segment iSeg=0) is always less than f c 1 in case of 80+80 MHz VHT PPDU transmissions. Hence, d '' k i n 0 u (frequency subblock 0) is always transmitted in the frequency segment lower in frequency, while d '' k i n 1 u (frequency subblock 1) is always transmitted in the frequency segment higher in frequency. 21.3.10.9.4 Space-time block coding This subclause defines a set of optional robust transmission techniques that are applicable only when using STBC coding for VHT SU PPDUs. In this case, NSS,0 spatial streams are mapped to NSTS,0 space-time streams. These techniques are based on STBC. When the VHT-SIG-A STBC field is 1, a symbol operation shall occur between the constellation mapper and the spatial mapper as defined in this subclause. STBC shall not be applied in a VHT MU PPDU. Hence, the user subscript u is 0 in this subclause. If STBC is applied, the stream of complex numbers, i d k Seg i n 0; k = 0 N SD â€“ 1 ; i = 1 N SS 0 ; n = 0 N SYM â€“ 1 , generated by the segment deparser, is the input to the STBC encoder, which produces as output the stream of complex numbers i dÌƒ k Seg i STS n 0; k = 0 N SD â€“ 1 ; i STS = 1 N STS 0 ; n = 0 N SYM â€“ 1 . For given values of k and i, STBC processing operates on the complex modulation symbols in sequential pairs of OFDM symbols so i Seg i Seg i Seg i Seg i Seg that the value of dÌƒ k 2i â€“ 1 2m 0 and dÌƒ k 2 i 2 m 0 depend on d k i 2m 0 and d k i 2m + 1 0 . Also, dÌƒ k 2i â€“ 1 2m + 1 0 i Seg i Seg i Seg and dÌƒ k 2i 2m + 1 0 depend on d k i 2 m 0 and d k i 2 m + 1 0 . This is defined in Table 21-20. Note that the segment index i Seg is omitted in Table 21-20 for simplicity. Table 21-20â€”Constellation mapper output to spatial mapper input for STBC N STS N SS i STS dÌƒ k i STS 2m 0 dÌƒ k i STS 2m + 1 0 2 1 1 dk dk 1 2m 0 1 2m + 1 0 2 â€“ d k* 1 d k* 1 2m + 1 0 2m 0 4 2 1 dk dk 1 2m 0 1 2m + 1 0 2 â€“ d k* 1 d k* 1 2m + 1 0 2m 0 3 dk dk 2 2m 0 2 2m + 1 0 4 â€“ d k* 2 d k* 2 2m + 1 0 2m 0 2573 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-20â€”Constellation mapper output to spatial mapper input for STBC (continued) N STS N SS i STS dÌƒ k i STS 2m 0 dÌƒ k i STS 2m + 1 0 6 3 1 dk dk 1 2m 0 1 2m + 1 0 2 â€“ d k* 1 d k* 1 2m + 1 0 2m 0 3 dk dk 2 2m 0 2 2m + 1 0 4 â€“ d k* 2 d k* 2 2m + 1 0 2m 0 5 dk dk 3 2m 0 3 2m + 1 0 6 â€“ d k* 3 d k* 3 2m + 1 0 2m 0 8 4 1 dk dk 1 2m 0 1 2m + 1 0 2 â€“ d k* 1 d k* 1 2m + 1 0 2m 0 3 dk dk 2 2m 0 2 2m + 1 0 4 â€“ d k* 2 d k* 2 2m + 1 0 2m 0 5 dk dk 3 2m 0 3 2m + 1 0 6 â€“ d k* 3 d k* 3 2m + 1 0 2m 0 7 dk dk 4 2m 0 4 2m + 1 0 8 â€“ d k* 4 d k* 4 2m + 1 0 2m 0 i i If STBC is not applied, dÌƒ k Seg i n 0 = d k Seg i n 0 and N STS 0 = N SS 0 . NOTEâ€”When STBC is applied, an odd number of space-time streams is not allowed, and N STS 0 = 2N SS 0 . 21.3.10.10 Pilot subcarriers In a 20 MHz transmission, four pilot tones shall be inserted in subcarriers k â€“ 21 â€“ 7 7 21 . The pilot mapping P nk for subcarrier k for symbol n shall be as specified in Equation (21-91). P n â€“21 â€“ 7 7 21 = 1 1 n mod 4 1 1 n + 1 mod 4 1 1 n + 2 mod 4 1 1 n + 3 mod 4 (21-91) P nk â€“ 21 â€“ 7 7 21 = 0 where 1 is given by the N STS = 1 row of Table 19-19 1 m In a 40 MHz transmission, six pilot tones shall be inserted in subcarriers â€“53, â€“25, â€“11, 11, 25, and 53. The pilot mapping P nk for subcarrier k for symbol n shall be as specified in Equation (21-92). 2574 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications P n â€“53 â€“ 25 â€“ 11 11 25 53 = 1 1 n mod 6 1 1 n + 1 mod 6 1 1 n + 5 mod 6 (21-92) P nk â€“ 53 â€“ 25 â€“ 11 11 25 53 = 0 where 1 is given by the NSTS = 1 row of Table 19-20 1 m In an 80 MHz transmission, eight pilot tones shall be inserted in subcarriers â€“103, â€“75, â€“39, â€“11, 11, 39, 75, and 103. The pilot mapping P nk for subcarrier k for symbol n shall be as specified in Equation (21-93). P n â€“103 â€“ 75 â€“ 39 â€“ 11 11 39 75 103 = n mod 8 n + 1 mod 8 n + 7 mod 8 (21-93) P nk â€“ 103 â€“ 75 â€“ 39 â€“ 11 11 39 75 103 = 0 where m is defined in Table 21-21 Table 21-21â€”Pilot values for 80 MHz transmission 0 1 2 3 4 5 6 7 1 1 1 â€“1 â€“1 1 1 1 In a 160 MHz transmission, the 80 MHz pilot mapping is replicated in the two 80 MHz subchannels of the 160 MHz transmission. Specifically, 16 pilot tones shall be inserted in subcarriers â€“231, â€“203, â€“167, â€“139, â€“117, â€“89, â€“53, â€“25, 25, 53, 89, 117, 139, 167, 203, and 231. The pilot mapping P nk for subcarrier k for symbol n shall be as specified in Equation (21-94). P n â€“231 â€“ 203 â€“ 167 â€“ 139 â€“ 117 â€“ 89 â€“ 53 â€“ 25 25 53 89 117 139 167 203 231 (21-94) = n mod 8 n + 1 mod 8 n + 2 mod 8 n + 3 mod 8 n + 4 mod 8 n + 5 mod 8 n + 6 mod 8 n + 7 mod 8 n mod 8 n + 1 mod 8 n + 2 mod 8 n + 3 mod 8 n + 4 mod 8 n + 5 mod 8 n + 6 mod 8 n + 7 mod 8 P nk â€“ 231 â€“ 203 â€“ 167 â€“ 139 â€“ 117 â€“ 89 â€“ 53 â€“ 25 25 53 89 117 139 167 203 231 = 0 where m is given in Table 21-21 In an 80+80 MHz transmission, each frequency segment shall follow the 80 MHz pilot tone allocation and values defined for 80 MHz transmission as specified in Equation (21-93) and Table 21-21. The above pilot mapping shall be copied to all space-time streams before the space-time stream cyclic shifts are applied. 21.3.10.11 OFDM modulation 21.3.10.11.1 Transmission in VHT format The time domain waveform of the Data field of a VHT PPDU from frequency segment i Seg and transmit chain iTX, 1 iTX NTX shall be as defined in Equation (21-95). 2575 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications N SYM â€“ 1 i Seg i TX 1 r VHT-Data(t) = ------------------------------------------------- w TSYM(t â€“ nT SYM) (21-95) Tone N VHT-Data N STS total n=0 N SR N user â€“ 1 N STS u i u Q kiSeg k BW DÌƒ k Seg m n BW + p n + 4 P nk i TX M u + m k = â€“ N SR u=0 m=1 exp j2 k F t â€“ nT SYM â€“ T GI Data â€“ T CS,VHT(M u + m) where pn is defined in 17.3.5.10 P nk is defined in 21.3.10.10 k BW is defined in Equation (21-14), Equation (21-15), Equation (21-16), and Equation (21-17) i u DÌƒ k Seg m n BW is the transmitted constellation for user u at subcarrier k, space-time stream m, and Data field OFDM symbol n and is defined in Equation (21-96) through Equation (21-99) Tone N VHT-Data has the value given in Table 21-8 T CS,VHT(n) is given in Table 21-11 T GI Data is the guard interval duration. T GI Data = T GI when not using the short guard interval (Short GI field of VHT-SIG-A2 is 0) and T GI Data = T GIS when using the short guard interval (Short GI field of VHT-SIG-A2 is 1). T GI and T GIS are given in Table 21-5. In a 20 MHz VHT transmission, i u 0 k=0 7 21 DÌƒ k Seg m n 20 = i (21-96) dÌƒ MSeg r otherwise 20 k m n u where r (k) is defined in Equation (21-49) M 20 In a 40 MHz VHT transmission, i u 0 k=0 1 11 25 53 DÌƒ k Seg m n 40 = i (21-97) dÌƒ MSeg r otherwise 40 k m n u where r (k) is defined in Equation (21-51) M 40 2576 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications In an 80 MHz transmission, i u 0 k=0 1 11 39 75 103 DÌƒ k Seg m n 80 = i (21-98) dÌƒ MSeg r otherwise 80 k m n u where r (k) is defined in Equation (21-53) M 80 In a 160 MHz transmission, i u 0 k=0 1 2 3 4 5 25 53 89 117 127 128 129 139 167 203 231 DÌƒ k Seg m n 160 = i dÌƒ MSeg r otherwise 160 k m n u (21-99) where r (k) is defined in Equation (21-55) M 160 In an 80+80 MHz transmission, each frequency segment shall follow the 80 MHz VHT subcarrier mapping as specified in Equation (21-98) and Equation (21-53). Q kiSeg is a spatial mapping/steering matrix with NTX rows and NSTS,total columns for subcarrier k in frequency segment i Seg . Q kiSeg may be frequency dependent. Refer to the examples of Q k listed in 19.3.11.11.2 for examples of Q kiSeg that could be used for VHT SU PPDUs. Note that implementations are not restricted to the spatial mapping matrix examples listed in 19.3.11.11.2 and the number of transmit chains NTX could be greater than 4. For VHT SU PPDUs to which beamforming is applied, Q kiSeg is a beamforming steering matrix and is derived from the TXVECTOR parameter EXPANSION_MAT. For VHT MU PPDUs, Q kiSeg is the DL-MU-MIMO steering matrix and is derived from the TXVECTOR parameter EXPANSION_MAT. The beamforming steering matrices and DL-MU-MIMO steering matrices are implementation specific. 21.3.10.12 Non-HT duplicate transmission When the TXVECTOR parameter FORMAT is NON_HT and the TXVECTOR parameter NON_HT_MODULATION is NON_HT_DUP_OFDM, the transmitted PPDU is a non-HT duplicate. Non- HT duplicate transmission is used to transmit to non-HT OFDM STAs, HT STAs, or VHT STAs that may be present in a part of a 40 MHz, 80 MHz, or 160 MHz channel (see Table 21-2). The VHT-SIG-A, VHT-STF, VHT-LTF, and VHT-SIG-B fields are not transmitted. The L-STF, L-LTF, and L-SIG fields shall be transmitted in the same way as in the VHT transmission, with the exceptions for the Rate and Length fields which shall follow 17.3.4. In a 40 MHz non-HT duplicate transmission, the Data field shall be as defined by Equation (19-61). For 80 MHz and 160 MHz non-HT duplicate transmissions, the Data field shall be as defined by Equation (21-100). 2577 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications N SYM â€“ 1 i TX 1 r non-HT BW (t) = ----------------------------------------------------------- w TSYM(t â€“ nT SYM) (21-100) Tone N NON_HT_DUP_OFDM-Data n=0 26 N 20MHz â€“ 1 k â€“ K Shift(i BW) BW Dk n + pn + 1 Pk k = â€“ 26 i BW = 0 i exp(j2 k â€“ K Shift(i BW) F t â€“ nT SYM â€“ T GI â€“ T CS TX ) where N 20MHz and K Shift(i) are defined in 21.3.8.2.4 Pk and pn are defined in 17.3.5.10 Dk,n is defined in Equation (21-26) k BW is defined in Equation (21-16) and Equation (21-17) i T CS TX represents the cyclic shift for transmitter chain i TX with a value given in Table 21-10 Tone N NON_HT_DUP_OFDM-Data has the value given in Table 21-8 In an 80+80 MHz non-HT duplicate transmission, data transmission in each frequency segment shall be as defined for an 80 MHz non-HT duplicate transmission in Equation (21-100). 21.3.11 SU-MIMO and DL-MU-MIMO Beamforming 21.3.11.1 General SU-MIMO and DL-MU-MIMO beamforming are techniques used by a STA with multiple antennas (the beamformer) to steer signals using knowledge of the channel to improve throughput. With SU-MIMO beamforming all space-time streams in the transmitted signal are intended for reception at a single STA. With DL-MU-MIMO beamforming, disjoint subsets of the space-time streams are intended for reception at different STAs. For SU-MIMO beamforming, the steering matrix Qk can be determined from the beamforming feedback matrix Vk that is sent back to the beamformer by the beamformee using the compressed beamforming feedback matrix format as defined in 19.3.12.3.6. The feedback report format is described in 9.4.1.49. For DL-MU-MIMO beamforming, the receive signal vector in subcarrier k at beamformee u, T T T T T yk u = yk 0 yk 1 yk N RX â€“ 1 , is shown in Equation (21-101), where x k = x k 0 xk 1 xk N user â€“ 1 u denotes the transmit signal vector in subcarrier k for all Nuser beamformees, with T xk u = xk 0 xk 1 xk N STS u â€“ 1 being the transmit signal for beamformee u. yk u = Hk u Qk 0 Qk 1 Qk N user â€“ 1 xk + n (21-101) where Hk,u is the channel matrix from the beamformer to beamformee u in subcarrier k with dimensions N RXu N TX 2578 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications N RXu is the number of receive antennas at beamformee u Qk u is a steering matrix for beamformee u in subcarrier k with dimensions N TX N STSu Nuser is the number of VHT MU PPDU recipients (see Table 21-6) n is a vector of additive noise and may include interference The DL-MU-MIMO steering matrix Q k = Q k 0 Qk 1 Qk N user â€“ 1 can be determined by the beamformer using the beamforming feedback matrices for subcarrier k from beamformee u, Vk,u, and SNR information for subcarrier k from beamformee u, SNRk,u, where u = 0 1 N user â€“ 1 . The steering matrix that is computed (or updated) using new beamforming feedback matrices and new SNR information from some or all of participating beamformees might replace the existing steering matrix Q k for the next DL- MU-MIMO data transmission. The beamformee group for the MU transmission is signaled using the Group ID field in VHT-SIG-A (see 21.3.8.3.3 and 21.3.11.4). 21.3.11.2 Beamforming Feedback Matrix V Upon receipt of a VHT NDP sounding PPDU, the beamformee shall remove the space-time stream CSD in Table 21-11 from the measured channel before computing a set of matrices for feedback to the beamformer. The beamforming feedback matrix, Vk,u, found by the beamformee u for subcarrier k shall be compressed in the form of angles using the method described in 19.3.12.3.6. The angles, k,u and k,u , are quantized according to Table 9-68. The number of bits for quantization is chosen by the beamformee, based on the indication from the beamformer as to whether the feedback is requested for SU-MIMO beamforming or DL- MU-MIMO beamforming. The compressed beamforming feedback using 19.3.12.3.6 is the only Clause 21 beamforming feedback format defined. The beamformee shall generate the beamforming feedback matrices with the number of rows (Nr) equal to the NSTS of the NDP. After receiving the angle information, k,u and k,u , the beamformer reconstructs Vk,u using Equation (19-79). For SU-MIMO beamforming, the beamformer can use this Vk,0 matrix to determine the steering matrix Qk. For DL-MU-MIMO beamforming, the beamformer may calculate a steering matrix Qk = Qk 0 Qk 1 Qk N user â€“ 1 using Vk,u and SNRk,u ( 0 u N user â€“ 1 ) in order to suppress crosstalk between participating beamformees. The method used by the beamformer to calculate the steering matrix Qk is implementation specific. The beamformee decides the tone grouping value to be used in the beamforming feedback matrix V. A beamformer shall support all tone grouping values and Codebook Information values. 21.3.11.3 Maximum Number of Total Spatial Streams in VHT MU PPDUs An MU beamformee capable STA shall support reception of VHT MU PPDUs with the total number of space-time streams across the N_user users being less than or equal to the value indicated in the Maximum NSTS,total subfield of the Supported VHT-MCS and NSS Set field of the VHT Capabilities element. 21.3.11.4 Group ID A value in the Group ID field in VHT-SIG-A (see 21.3.8.3.3) in the range 1 to 62 indicates a VHT MU PPDU. Prior to transmitting a VHT MU PPDU, group assignments have been established by the AP for DL- MU-MIMO capable STAs using the Group ID Management frame as defined in 9.6.23.3. 2579 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications After the PHY is configured using the PHYCONFIG_VECTOR parameter GROUP_ID_MANAGEMENT, the following lookup tables are populated: a) Group ID to Membership Status, denoted by MembershipStatusInGroupID[g] for 1 g 62 b) Group ID to User Position, denoted by UserPositionInGroupID[g] for 1 g 62 When a STA receives a VHT MU PPDU where the Group ID field in VHT-SIG-A has the value k and where MembershipStatusInGroupID[k] is equal to 1, then the number of space-time streams for that STA is indicated in the MU[UserPositionInGroupID[k]] NSTS field in VHT-SIG-A. The space-time streams of different users are ordered in accordance to user position values, i.e., the space-time streams for the user in user position 0 come first, followed by the space-time streams for the user in position 1, followed by the space-time streams for the user in position 2, and followed by the space-time streams for the user in position 3. A STA is also able to identify the space-time streams intended for other STAs that act as interference. VHT- LTF symbols in the VHT MU PPDU are used to measure the channel for the space-time streams intended for the STA and can also be used to measure the channel for the interfering space-time streams. To successfully demodulate the space-time streams intended for the STA, the STA may use the channel state information for all space-time streams to reduce the effect of interfering space-time streams. If a STA finds that it is not a member of the group, or the STA is a member of the group but the corresponding MU NSTS field in VHT-SIG-A indicates that there are zero space-time streams for the STA in the PPDU, then the STA may elect to not process the remainder of the PPDU. 21.3.12 VHT preamble format for sounding PPDUs NDP is the only VHT sounding format. The format of a VHT NDP PPDU is shown in Figure 21-28. 8 Î¼s 8 Î¼s 4 Î¼s 8 Î¼s 4 Î¼s 4 Î¼s per VHT-LTF symbol 4 Î¼s L- VHT- VHT- L-STF L-LTF VHT-SIG-A VHT-LTF SIG STF SIG-B Figure 21-28â€”VHT NDP format NOTEâ€”The number of VHT-LTF symbols in the NDP is determined by the SU NSTS field in VHT-SIG-A. The VHT NDP PPDU has the following properties: â€” Uses the VHT PPDU format but without the Data field. â€” Is a VHT SU PPDU as indicated by the VHT-SIG-A field. â€” Has the data bits of the VHT-SIG-B field set to a fixed bit pattern (see 21.3.8.3.6). 21.3.13 Regulatory requirements Wireless LANs (WLANs) implemented in accordance with this standard are subject to equipment certification and operating requirements established by regional and national regulatory administrations. The PHY specification establishes minimum technical requirements for interoperability, based upon established regulations at the time this standard was issued. These regulations are subject to revision or may be superseded. Requirements that are subject to local geographic regulations are annotated within the PHY specification. Regulatory requirements that do not affect interoperability are not addressed in this standard. Implementers are referred to the regulatory sources in Annex D for further information. Operation in 2580 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications countries within defined regulatory domains might be subject to additional or alternative national regulations. 21.3.14 Channelization A VHT channel is specified by the four PLME MIB fields specified in Table 21-22. Table 21-22â€”Fields to specify VHT channels Field Meaning dot11CurrentChannelWidth Channel width. Possible values represent 20 MHz, 40 MHz, 80 MHz, 160 MHz, and 80+80 MHz channels. dot11CurrentChannelCenterFrequencyIndex0 For a 20 MHz, 40 MHz, 80 MHz, or 160 MHz channel, denotes the channel center frequency. For an 80+80 MHz channel, denotes the center frequency of the frequency segment 0, which is the frequency segment containing the primary channel. Valid range is 1 to 200. See Equation (21-102). dot11CurrentChannelCenterFrequencyIndex1 For an 80+80 MHz channel, denotes the center frequency of the frequency segment 1, which is the frequency segment that does not contain the primary channel. Valid range is 1 to 200. See Equation (21-102). For a 20 MHz, 40 MHz, 80 MHz, or 160 MHz channel, set to 0. dot11CurrentPrimaryChannel Denotes the location of the primary 20 MHz channel. Valid range is 1 to 200. See Equation (21-103). Given dot11CurrentChannelCenterFrequencyIndex0 and dot11CurrentChannelCenterFrequencyIndex1, the respective center frequency is given by Equation (21-102). Channel center frequency [MHz] (21-102) = Channel starting frequency + 5 dot11CurrentChannelCenterFrequencyIndex where Channel starting frequency is given by the operating class (Annex E) dot11CurrentChannelCenterFrequencyIndex is either dot11CurrentChannelCenterFrequencyIndex0 or dot11CurrentChannelCenterFrequencyIndex1 The center frequency of the primary 20 MHz channel is given by Equation (21-103). Primary 20 MHz channel center frequency [MHz] (21-103) = Channel starting frequency + 5 dot11CurrentPrimaryChannel The channel starting frequency is defined as dot11ChannelStartingFactor Ã— 500 kHz. If a channel center frequency is 5.000 GHz, it shall be indicated by dot11ChannelStartingFactor = 8000 and dot11CurrentPrimaryChannel = 200. For an 80+80 MHz channel, any two channels that would each be allowed as 80 MHz channels and whose center frequencies are separated by greater than 80 MHz (difference between dot11CurrentChannelCenterFrequencyIndex0 and dot11CurrentChannelCenterFrequencyIndex1 corresponds to a frequency difference greater than 80 MHz) may be used. 2581 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications For example, a channel specified by channel starting frequency = 5000 MHz dot11CurrentChannelWidth = 80 MHz dot11CurrentChannelCenterFrequencyIndex0 = 42 dot11CurrentPrimaryChannel = 36 is an 80 MHz channel with a center frequency of 5210 MHz and the primary 20 MHz channel centered at 5180 MHz. A channel specified by channel starting frequency = 5000 MHz dot11CurrentChannelWidth = 160 MHz dot11CurrentChannelCenterFrequencyIndex0 = 50 dot11CurrentPrimaryChannel = 56 is a 160 MHz channel with a center frequency of 5250 MHz and the primary 20 MHz channel centered at 5280 MHz. A channel specified by channel starting frequency = 5000 MHz dot11CurrentChannelWidth = 80+80 MHz dot11CurrentChannelCenterFrequencyIndex0 =155 dot11CurrentChannelCenterFrequencyIndex1 = 106 dot11CurrentPrimaryChannel = 161 is an 80+80 MHz channel in which frequency segment 0 has 80 MHz bandwidth and center frequency of 5775 MHz. Frequency segment 1 also has 80 MHz bandwidth and center frequency of 5530 MHz. The primary 20 MHz channel is centered at 5805 MHz. 21.3.15 Slot time The slot time for the VHT PHY shall be 9 s for 20 MHz, 40 MHz, 80 MHz, 160 MHz, and 80+80 MHz channel spacing. 21.3.16 Transmit and receive port impedance Transmit and receive antenna connector impedance for each transmit and receive antenna is defined in 17.3.8.7. 21.3.17 VHT transmit specification 21.3.17.1 Transmit spectrum mask NOTE 1â€”In the presence of additional regulatory restrictions, the device has to meet both the regulatory requirements and the mask defined in this subclause. NOTE 2â€”Transmit spectral mask figures in this subclause are not drawn to scale. NOTE 3â€”For rules regarding TX center frequency leakage levels, see 21.3.17.4.2. The spectral mask requirements in this subclause do not apply to the RF LO. For a 20 MHz mask PPDU of non-HT, HT or VHT format, the interim transmit spectral mask shall have a 0 dBr (dB relative to the maximum spectral density of the signal) bandwidth of 18 MHz, â€“20 dBr at 11 MHz frequency offset, â€“28 dBr at 20 MHz frequency offset, and â€“40 dBr at 30 MHz frequency offset and above. The interim transmit spectral mask for frequency offsets in between 9 and 11 MHz, 11 and 20 MHz, and 20 and 30 MHz shall be linearly interpolated in dB domain from the requirements for 9 MHz, 11 MHz, 20 MHz, and 30 MHz frequency offsets. The transmit spectrum shall not exceed the maximum of the 2582 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications interim transmit spectral mask and â€“53 dBm/MHz at any frequency offset. Figure 21-29 shows an example of the resulting overall spectral mask when the â€“40 dBr spectrum level is above â€“53 dBm/MHz. PSD 0 dBr -20 dBr -28 dBr -40 dBr Freq [MHz] -30 -20 -11 -9 9 11 20 30 Figure 21-29â€”Example transmit spectral mask for 20 MHz mask PPDU For a 40 MHz mask PPDU of non-HT, non-HT duplicate, HT or VHT format, the interim transmit spectral mask shall have a 0 dBr (dB relative to the maximum spectral density of the signal) bandwidth of 38 MHz, â€“20 dBr at 21 MHz frequency offset, â€“28 dBr at 40 MHz frequency offset, and â€“40 dBr at 60 MHz frequency offset and above. The interim transmit spectral mask for frequency offsets in between 19 and 21 MHz, 21 and 40 MHz, and 40 and 60 MHz shall be linearly interpolated in dB domain from the requirements for 19 MHz, 21 MHz, 40 MHz, and 60 MHz frequency offsets. The transmit spectrum shall not exceed the maximum of the interim transmit spectral mask and â€“56 dBm/MHz at any frequency offset greater than 19 MHz. Figure 21-30 shows an example of the resulting overall spectral mask when the â€“40 dBr spectrum level is above â€“56 dBm/MHz. PSD 0 dBr -20 dBr -28 dBr -40 dBr Freq [MHz] -60 -40 -21 -19 19 21 40 60 Figure 21-30â€”Example transmit spectral mask for 40 MHz mask PPDU For an 80 MHz mask PPDU of non-HT, non-HT duplicate, HT or VHT format, the interim transmit spectral mask shall have a 0 dBr (dB relative to the maximum spectral density of the signal) bandwidth of 78 MHz, â€“20 dBr at 41 MHz frequency offset, â€“28 dBr at 80 MHz frequency offset, and â€“40 dBr at 2583 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 120 MHz frequency offset and above. The interim transmit spectral mask for frequency offsets in between 39 and 41 MHz, 41 and 80 MHz, and 80 and 120 MHz shall be linearly interpolated in dB domain from the requirements for 39 MHz, 41 MHz, 80 MHz, and 120 MHz frequency offsets. The transmit spectrum shall not exceed the maximum of the interim transmit spectrum mask and â€“59 dBm/MHz at any frequency offset. Figure 21-31 shows an example of the resulting overall spectral mask when the â€“40 dBr spectrum level is above â€“59 dBm/MHz. PSD 0 dBr -20 dBr -28 dBr -40 dBr Freq [MHz] -120 -80 -41 -39 39 41 80 120 Figure 21-31â€”Example transmit spectral mask for 80 MHz mask PPDU For a 160 MHz mask PPDU of non-HT, non-HT duplicate, HT or VHT format, the interim transmit spectral mask shall have a 0 dBr (dB relative to the maximum spectral density of the signal) bandwidth of 158 MHz, â€“20 dBr at 81 MHz frequency offset, â€“28 dBr at 160 MHz frequency offset, and â€“40 dBr at 240 MHz frequency offset and above. The interim transmit spectral mask for frequency offsets in between 79 and 81 MHz, 81 and 160 MHz, and 160 and 240 MHz shall be linearly interpolated in dB domain from the requirements for 79 MHz, 81 MHz, 160 MHz, and 240 MHz frequency offsets. The transmit spectrum shall not exceed the maximum of the interim transmit spectrum mask and â€“59 dBm/MHz at any frequency offset. Figure 21-32 shows an example of the resulting overall spectral mask when the â€“40 dBr spectrum level is above â€“59 dBm/MHz. PSD 0 dBr -20 dBr -28 dBr -40 dBr Freq [MHz] -240 -160 -81 -79 79 81 160 240 Figure 21-32â€”Example transmit spectral mask for 160 MHz mask PPDU 2584 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications For an 80+80 MHz mask PPDU of non-HT duplicate or VHT format, the overall transmit spectral mask is constructed in the following manner. First, the 80 MHz interim spectral mask is placed on each of the two 80 MHz segments. Then, for each frequency at which both of the 80 MHz interim spectral masks have values greater than â€“40 dBr and less than â€“20 dBr, the sum of the two interim mask values (summed in linear domain) shall be taken as the overall spectral mask value. Next, for each frequency at which neither of the two 80 MHz interim masks have values greater than or equal to â€“20 dBr and less than or equal to 0 dBr, the higher value of the two interim masks shall be taken as the overall interim spectral value. Finally, for any frequency region where the mask value has not been defined yet, linear interpolation (in dB domain) between the nearest two frequency points with the interim spectral mask value defined shall be used to define the interim spectral mask value. The transmit spectrum shall not exceed the maximum of the interim transmit spectrum mask and â€“59 dBm/MHz at any frequency offset. Figure 21-33 shows an example of a transmit spectral mask for a noncontiguous transmission using two 80 MHz channels where the center frequency of the two 80 MHz channels are separated by 160 MHz and the â€“40 dBr spectrum level is above â€“59 dBm/MHz. PSD PSD 0 dBr 0 dBr 80 MHz Mask 1 80 MHz Mask 2 -20 dBr -20 dBr -28 dBr -28 dBr -40 dBr -40 dBr -120 -80 -41 -39 0 39 41 80 120 f[MHz] -120 -80 -41 -39 0 39 41 80 120 f[MHz] PSD 0 dBr Overall transmit spectral mask (bold line) -20 dBr both of the 80 MHz -25 dBr -28 dBr neither of the two 80 spectral masks have MHz masks have values greater than values greater than -40 dBr and less or equal to -20 dBr than -20 dBr and less than or equal to 0 dBr -40 dBr f[MHz] -200 -160 -121 -119 -80 -41 -39 39 41 80 119 121 160 200 higher Original lin. Original higher value Mask 1 sum Mask 2 value Figure 21-33â€”Example transmit spectral mask for 80+80 MHz mask PPDU Different center frequency separation between the two 80 MHz frequency segments of the spectral mask as well as different peak levels of each 80 MHz frequency segment of the spectral mask are possible, in which case a similar procedure in determining the spectral mask as in Figure 21-33 is followed. The transmit spectral mask for noncontiguous transmissions using two nonadjacent 80 MHz channels is applicable only in regulatory domains that allow for such transmissions. Measurements shall be made using a 100 kHz resolution bandwidth and a 30 kHz video bandwidth. 2585 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 21.3.17.2 Spectral flatness Spectral flatness measurements shall be conducted using BPSK modulated PPDUs. Demodulate the PPDUs according to the following (or equivalent) procedure: a) Start of PPDU shall be detected. b) Transition from L-STF to L-LTF shall be detected and fine timing shall be established. c) Coarse and fine frequency offsets shall be estimated. d) Symbols in a PPDU shall be derotated according to estimated frequency offset. e) For each VHT-LTF symbol, transform the symbol into subcarrier received values, estimate the phase from the pilot subcarriers, and derotate the subcarrier values according to the estimated phase. f) For each of the data OFDM symbols: transform the symbol into subcarrier received values. The spectral flatness test shall be performed over at least 20 PPDUs. The PPDUs under test shall be at least 16 data OFDM symbols long. Evaluate spectral flatness using the subcarrier received values or the magnitude of the channel estimation. Let E i avg denote the magnitude of the channel estimation on subcarrier i or the average constellation energy of a BPSK modulated subcarrier i in a VHT data symbol. In a contiguous non-HT duplicate or VHT transmission having a bandwidth listed in Table 21-23, E i avg of each of the subcarriers with indices listed as tested subcarrier indices shall not deviate by more than the specified maximum deviation in Table 21-23 from the average of E i avg over subcarrier indices listed as averaging subcarrier indices. Averaging of E i avg is done in the linear domain. Table 21-23â€”Maximum transmit spectral flatness deviations Bandwidth of Maximum Averaging subcarrier Tested subcarrier indices Format transmission deviation indices (inclusive) (inclusive) (MHz) (dB) â€“16 to â€“1 and +1 to +16 Â±4 20 â€“16 to â€“1 and +1 to +16 â€“28 to â€“17 and +17 to +28 +4/â€“6 â€“42 to â€“2 and +2 to +42 Â±4 40 â€“42 to â€“2 and +2 to +42 â€“58 to â€“43 and +43 to +58 +4/â€“6 VHT â€“84 to â€“2 and +2 to +84 Â±4 80 â€“84 to â€“2 and +2 to +84 â€“122 to â€“85 and +85 to +122 +4/â€“6 â€“172 to â€“130, â€“126 to â€“44, +44 to â€“172 to â€“130, â€“126 to â€“44, Â±4 +126, and +130 to +172 160 +44 to +126, and +130 to +172 â€“250 to â€“173, â€“43 to â€“6, +6 to +4/â€“6 +43, and +173 to +250 2586 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-23â€”Maximum transmit spectral flatness deviations (continued) Bandwidth of Maximum Averaging subcarrier Tested subcarrier indices Format transmission deviation indices (inclusive) (inclusive) (MHz) (dB) â€“42 to â€“33, â€“31 to â€“6, +6 to +31, â€“42 to â€“33, â€“31 to â€“6, Â±4 40 and +33 to +42 +6 to +31, and +33 to +42 â€“43 to â€“58 and +43 to +58 +4/â€“6 â€“84 to â€“70,â€“58 to â€“33, â€“31 to â€“6, â€“84 to â€“70, â€“58 to â€“33, Â±4 +6 to +31, +33 to +58, +70 to +84 80 â€“31 to â€“6, +6 to +31, +33 to +58, +70 to +84 â€“122 to â€“97, â€“95 to â€“85 and +85 +4/â€“6 to +95, +97 to +122 non-HT duplicate â€“172 to â€“161, â€“159 to â€“134, â€“172 to â€“161, â€“159 to â€“134, â€“122 to â€“97, â€“95 to â€“70, â€“122 to â€“97, â€“95 to â€“70, â€“58 to â€“44, +44 to +58, â€“58 to â€“44, +44 to +58, Â±4 +70 to +95, +97 to +122, +70 to +95, +97 to +122, +134 to +159, +161 to +172 +134 to +159, +161 to +172 160 â€“250 to â€“225, â€“223 to â€“198, â€“186 to â€“173, â€“43 to â€“33, â€“31 to â€“6, +6 to +31, +33 to +43, +4/â€“6 +173 to +186, +198 to +223, +225 to +250 In an 80+80 MHz transmission, each segment shall meet the spectral flatness requirement for an 80 MHz transmission. For the spectral flatness test, the transmitting STA shall be configured to use a spatial mapping matrix Qk (see 21.3.10.11) with flat frequency response. Each output port under test of the transmitting STA shall be connected through a cable to one input port of the testing instrumentation. The requirements apply to 20 MHz, 40 MHz, 80 MHz, and 160 MHz contiguous transmissions as well as 80+80 MHz transmissions. 21.3.17.3 Transmit center frequency and symbol clock frequency tolerance The symbol clock frequency and transmit center frequency tolerance shall be Â±20 ppm maximum. The transmit center frequency and the symbol clock frequency for all transmit antennas and frequency segments shall be derived from the same reference oscillator. Transmit signals with TXVECTOR parameter CH_BANDWIDTH set to CBW160 or CBW80+80 may be generated using two separate RF LOs, one for each of the lower and upper 80 MHz frequency portions. NOTEâ€”The signal phase of the two 80 MHz frequency portions might not be correlated. 21.3.17.4 Modulation accuracy 21.3.17.4.1 Introduction to modulation accuracy tests Transmit modulation accuracy specifications are described in 21.3.17.4.2 and 21.3.17.4.3. The test method is described in 21.3.17.4.4. 21.3.17.4.2 Transmit center frequency leakage TX LO leakage shall meet the following requirements for all formats and bandwidths except 80+80 MHz where the RF LO falls outside both frequency segments: 2587 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” When the RF LO is in the center of the transmitted PPDU BW, the power measured at the center of transmission BW using resolution BW 312.5 kHz shall not exceed the average power per-subcarrier of the transmitted PPDU, or equivalently, ( P â€“ 10 log 10(N ST) ), where P is the transmit power per antenna in dBm, and NST is defined in Table 21-5. â€” When the RF LO is not at the center of the transmitted PPDU BW, the power measured at the location of the RF LO using resolution BW 312.5 kHz shall not exceed the maximum of â€“32 dB relative to the total transmit power and â€“20 dBm, or equivalently max(P â€“ 32 â€“ 20) , where P is the transmit power per antenna in dBm, and NST is defined in Table 21-5. For an 80+80 MHz transmission where the RF LO falls outside both frequency segments, the RF LO shall follow the spectral mask requirements as defined in 21.3.17.1. The transmit center frequency leakage is specified per antenna. 21.3.17.4.3 Transmitter constellation error The relative constellation RMS error, calculated by first averaging over subcarriers, frequency segments, VHT PPDUs, and spatial streams (see Equation (19-89)) shall not exceed a data-rate dependent value according to Table 21-24. The number of spatial streams under test shall be equal to the number of utilized transmitting STA antenna (output) ports and also equal to the number of utilized testing instrumentation input ports. In the test, NSS = NSTS (no STBC) shall be used. Each output port of the transmitting STA shall be connected through a cable to one input port of the testing instrumentation. The requirements apply to 20 MHz, 40 MHz, 80 MHz, and 160 MHz contiguous transmissions as well as 80+80 MHz noncontiguous transmissions. Table 21-24â€”Allowed relative constellation error versus constellation size and coding rate Relative constellation error Modulation Coding rate (dB) BPSK 1/2 â€“5 QPSK 1/2 â€“10 QPSK 3/4 â€“13 16-QAM 1/2 â€“16 16-QAM 3/4 â€“19 64-QAM 2/3 â€“22 64-QAM 3/4 â€“25 64-QAM 5/6 â€“27 256-QAM 3/4 â€“30 256-QAM 5/6 â€“32 For non-HT duplicate transmissions, requirements defined in 17.3.9.7.4 apply to each 20 MHz subchannel. 2588 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 21.3.17.4.4 Transmitter modulation accuracy (EVM) test The transmit modulation accuracy test shall be performed by instrumentation capable of converting the transmitted signals into a stream of complex samples at sampling rate greater than or equal to the bandwidth of the signal being transmitted; except that â€” For non-HT duplicate transmissions, each 20 MHz subchannel may be tested independently while all subchannels are being transmitted and â€” For noncontiguous transmissions, each frequency segment may be tested independently while both segments are being transmitted. In this case, transmit modulation accuracy of each segment shall meet the required value in Table 21-24 using only the subcarriers within the corresponding segment. The instrument shall have sufficient accuracy in terms of I/Q arm amplitude and phase balance, DC offsets, phase noise, and analog to digital quantization noise. A possible embodiment of such a setup is converting the signals to a low IF frequency with a microwave synthesizer, sampling the signal with a digital oscilloscope and decomposing it digitally into quadrature components. The sampled signal shall be processed in a manner similar to an actual receiver, according to the following steps, or equivalent procedure: a) Start of PPDU shall be detected. b) Transition from L-STF to L-LTF shall be detected and fine timing shall be established. c) Coarse and fine frequency offsets shall be estimated. d) Symbols in a PPDU shall be derotated according to estimated frequency offset. e) For each VHT-LTF symbol, transform the symbol into subcarrier received values, estimate the phase from the pilot subcarriers, and derotate the subcarrier values according to the estimated phase. f) Estimate the complex channel response coefficient for each of the subcarriers and each of the transmit streams. g) For each of the data OFDM symbols: transform the symbol into subcarrier received values, estimate the phase from the pilot subcarriers, derotate the subcarrier values according to the estimated phase, group the results from all of the receiver chains in each subcarrier to a vector, and multiply the vector by a zero-forcing equalization matrix generated from the estimated channel. h) For each data-carrying subcarrier in each spatial stream, find the closest constellation point and compute the Euclidean distance from it. i) Compute the average across PPDUs of the RMS of all errors per PPDU as given by Equation (19- 89). NOTEâ€”In the case the transmit modulation accuracy test is performed simultaneously for the two frequency segments of the 80+80 MHz transmissions, NST in Equation (19-89) represents the total number of subcarriers of both 80 MHz fre- quency segments. The test shall be performed over at least 20 PPDUs ( N f as defined in Equation (19-89)). The PPDUs under test shall be at least 16 data OFDM symbols long. Random data shall be used for the symbols. 2589 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 21.3.17.5 Time of Departure accuracy The Time of Departure accuracy test evaluates TIME_OF_DEPARTURE against aTxPHYTxStartRMS and aTxPHYTxStartRMS against TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH as defined in Annex P with the following test parameters: â€” MULTICHANNEL_SAMPLING_RATE is: 6 fH â€“ fL 20 10 1 + ------------------- - sample/s, for a CH_BANDWIDTH parameter equal to CBW20 20 MHz 6 fH â€“ fL 40 10 1 + ------------------- - sample/s, for a CH_BANDWIDTH parameter equal to CBW40 40 MHz 6 fH â€“ fL 80 10 1 + ------------------- - sample/s, for a CH_BANDWIDTH parameter equal to CBW80 80 MHz 6 fH â€“ fL 160 10 1 + ---------------------- - sample/s, for a CH_BANDWIDTH parameter equal to CBW160 160 MHz or CBW80+80 where fH is the nominal center frequency in Hz of the highest channel in the channel set fL is the nominal center frequency in Hz of the lowest channel in the channel set, the channel set is the set of channels upon which frames providing measurements are transmitted, the channel set comprises channels uniformly spaced across f H â€“ f L 50 MHz â€” FIRST_TRANSITION_FIELD is L-STF. â€” SECOND_TRANSITION_FIELD is L-LTF. â€” TRAINING_FIELD is L-LTF windowed in a manner which should approximate the windowing described in 17.3.2.5 with TTR = 100 ns. â€” TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH is 80 ns. NOTEâ€”The indicated windowing applies to the time of departure accuracy test equipment, and not the transmitter or receiver. 21.3.18 VHT receiver specification For tests in this subclause, the input levels are measured at the antenna connectors and are referenced as the average power per receive antenna. The number of spatial streams under test shall be equal to the number of utilized transmitting STA antenna (output) ports and also equal to the number of utilized Device Under Test input ports. Each output port of the transmitting STA shall be connected through a cable to one input port of the Device Under Test. 21.3.18.1 Receiver minimum input sensitivity The packet error ratio (PER) shall be less than 10% for a PSDU length of 4096 octets with the rate- dependent input levels listed in Table 21-25. The test in this subclause and the minimum sensitivity levels specified in Table 21-25 apply only to non-STBC modes, 800 ns GI, BCC, and VHT PPDUs. 2590 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-25â€”Receiver minimum input level sensitivity Minimum Minimum Minimum Minimum sensitivity sensitivity sensitivity sensitivity Rate (160 MHz or Modulation (20 MHz (40 MHz (80 MHz (R) 80+80 MHz PPDU) PPDU) PPDU) PPDU) (dBm) (dBm) (dBm) (dBm) BPSK 1/2 â€“82 â€“79 â€“76 â€“73 QPSK 1/2 â€“79 â€“76 â€“73 â€“70 QPSK 3/4 â€“77 â€“74 â€“71 â€“68 16-QAM 1/2 â€“74 â€“71 â€“68 â€“65 16-QAM 3/4 â€“70 â€“67 â€“64 â€“61 64-QAM 2/3 â€“66 â€“63 â€“60 â€“57 64-QAM 3/4 â€“65 â€“62 â€“59 â€“56 64-QAM 5/6 â€“64 â€“61 â€“58 â€“55 256-QAM 3/4 â€“59 â€“56 â€“53 â€“50 256-QAM 5/6 â€“57 â€“54 â€“51 â€“48 21.3.18.2 Adjacent channel rejection Adjacent channel rejection for W MHz channels (where W is 20, 40, 80 or 160) shall be measured by setting the desired signalâ€™s strength 3 dB above the rate-dependent sensitivity specified in Table 21-25 and raising the power of the interfering signal of W MHz bandwidth until 10% PER is caused for a PSDU length of 4096 octets. The difference in power between the signals in the interfering channel and the desired channel is the corresponding adjacent channel rejection. The center frequency of the adjacent channel shall be placed W MHz away from the center frequency of the desired signal. Adjacent channel rejection for 80+80 MHz channels shall be measured by setting the desired signalâ€™s strength 3 dB above the rate-dependent sensitivity specified in Table 21-25. Then, an interfering signal of 80 MHz bandwidth is introduced, where the center frequency of the interfering signal is placed 80 MHz away from the center frequency of the frequency segment lower in frequency of the desired signal. The power of the interfering signal is raised until 10% PER is caused for a PSDU length of 4096 octets. Let P 1 be the power difference between the interfering and desired signal. Next, the interfering signal of 80 MHz bandwidth is moved to a frequency where the center frequency of the interfering signal is 80 MHz away from the center frequency of the frequency segment higher in frequency of the desired signal. The power of the interfering signal is raised until 10% PER is caused for a PSDU length of 4096 octets. Let P 2 be the power difference between the interfering and desired signal. The smaller value between P 1 and P 2 is the corresponding adjacent channel rejection. The interfering signal in the adjacent channel shall be a signal compliant with the VHT PHY, unsynchronized with the signal in the channel under test, and shall have a minimum duty cycle of 50%. The corresponding rejection shall be no less than specified in Table 21-26. The test in this subclause and the adjacent sensitivity levels specified in Table 21-26 apply only to non- STBC modes, 800 ns GI, BCC, and VHT PPDUs. 2591 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-26â€”Minimum required adjacent and nonadjacent channel rejection levels Adjacent channel rejection Nonadjacent channel rejection (dB) (dB) Rate Modulation (R) 20/40/80/ 20/40/80/ 80+80 MHz 80+80 MHz 160 MHz 160 MHz Channel Channel Channel Channel BPSK 1/2 16 13 32 29 QPSK 1/2 13 10 29 26 QPSK 3/4 11 8 27 24 16-QAM 1/2 8 5 24 21 16-QAM 3/4 4 1 20 17 64-QAM 2/3 0 â€“3 16 13 64-QAM 3/4 â€“1 â€“4 15 12 64-QAM 5/6 â€“2 â€“5 14 11 256-QAM 3/4 â€“7 â€“10 9 6 256-QAM 5/6 â€“9 â€“12 7 4 The measurement of adjacent channel rejection for 160 MHz operation in a regulatory domain is required only if such a frequency band plan is permitted in that regulatory domain. 21.3.18.3 Nonadjacent channel rejection Nonadjacent channel rejection for W MHz channels (where W is 20, 40, 80, or 160) shall be measured by setting the desired signalâ€™s strength 3 dB above the rate-dependent sensitivity specified in Table 21-25, and raising the power of the interfering signal of W MHz bandwidth until a 10% PER occurs for a PSDU length of 4096 octets. The difference in power between the signals in the interfering channel and the desired channel is the corresponding nonadjacent channel rejection. The nonadjacent channel rejection shall be met with any nonadjacent channels located at least 2Ã—W MHz away from the center frequency of the desired signal. Nonadjacent channel rejection for 80+80 MHz channels shall be measured by setting the desired signalâ€™s strength 3 dB above the rate-dependent sensitivity specified in Table 21-25. Then, an interfering signal of 80 MHz bandwidth is introduced, where the center frequency of the interfering signal is placed at least 160 MHz away from the center frequency of the frequency segment lower in frequency of the desired signal. The center frequency of the interfering signal shall also be at least 160 MHz away from the center frequency of the frequency segment higher in frequency of the desired signal. The power of the interfering signal is raised until 10% PER is caused for a PSDU length of 4096 octets. Let P 1 be the power difference between the interfering and desired signal. Next, the interfering signal of 80 MHz bandwidth is moved to a frequency where the center frequency of the interfering signal is at least 160 MHz away from the center frequency of the frequency segment higher in frequency of the desired signal. The center frequency of the interfering signal shall also be at least 160 MHz away from the center frequency of the frequency segment lower in frequency of the desired signal. The power of the interfering signal is raised until 10% PER is caused for a PSDU length of 4096 octets. Let P 2 be the difference in power between the signals in the interfering channel and the desired channel. The smaller value between P 1 and P 2 is the corresponding nonadjacent channel rejection. 2592 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The interfering signal in the nonadjacent channel shall be a signal compliant with the VHT PHY, unsynchronized with the signal in the channel under test, and shall have a minimum duty cycle of 50%. The corresponding rejection shall be no less than specified in Table 21-26. The test in this subclause and the nonadjacent sensitivity levels specified in Table 21-26 apply only to non- STBC modes, 800 ns GI, BCC, and VHT PPDUs. The measurement of nonadjacent channel rejection for 160 MHz operation in a regulatory domain is required only if such a frequency band plan is permitted in that regulatory domain. 21.3.18.4 Receiver maximum input level The receiver shall provide a maximum PER of 10% at a PSDU length of 4096 octets, for a maximum input level of â€“30 dBm, measured at each antenna for any baseband VHT modulation. 21.3.18.5 CCA sensitivity 21.3.18.5.1 General The thresholds in this subclause are compared with the signal level at each receiving antenna. 21.3.18.5.2 CCA sensitivity for operating classes requiring CCA-ED For the operating classes requiring CCA-Energy Detect (CCA-ED), the PHY shall also indicate a medium busy condition when CCA-ED detects a channel busy condition. For improved spectrum sharing, CCA-ED is required in some bands. The behavior class indicating CCA-ED is given in Table D-2. The operating classes requiring the corresponding CCA-ED behavior class are given in E.1. The PHY of a STA that is operating within an operating class that requires CCA-ED shall operate with CCA-ED. CCA-ED shall detect a channel busy condition when the received signal strength exceeds the CCA-ED threshold as given by dot11OFDMEDThreshold for the primary 20 MHz channel, dot11OFDMEDThreshold for the secondary 20 MHz channel (if present), dot11OFDMEDThreshold + 3 dB for the secondary 40 MHz channel (if present), and dot11OFDMEDThreshold + 6 dB for the secondary 80 MHz channel (if present). The CCA-ED thresholds for the operating classes requiring CCA-ED are subject to the criteria in D.2.5. NOTEâ€”The requirement to detect a channel busy condition as stated in 21.3.18.5.3 and 21.3.18.5.4 is a mandatory energy detect requirement on all Clause 21 receivers. Support for CCA-ED is an additional requirement that relates spe- cifically to the sensitivities described in D.2.5. 21.3.18.5.3 CCA sensitivity for signals occupying the primary 20 MHz channel The PHY shall issue a PHY-CCA.indication(BUSY, {primary}) primitive if one of the conditions listed in Table 21-27 is met in an otherwise idle 20 MHz, 40 MHz, 80 MHz, 160 MHz, or 80+80 MHz operating channel width. With >90% probability, the PHY shall detect the start of a PPDU that occupies at least the primary 20 MHz channel under the conditions listed in Table 21-27 within a period of aCCATime (see 21.4.4) and hold the CCA signal busy (PHY-CCA.indication(BUSY, channel-list) primitive) for the duration of the PPDU. 2593 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-27â€”Conditions for CCA BUSY on the primary 20 MHz Operating channel width Conditions 20 MHz, 40 MHz, 80 MHz, The start of a 20 MHz NON_HT PPDU in the primary 20 MHz channel as 160 MHz, or 80+80 MHz defined in 17.3.10.6. The start of an HT PPDU under the conditions defined in 19.3.19.5. The start of a 20 MHz VHT PPDU in the primary 20 MHz channel at or above â€“82 dBm. 40 MHz, 80 MHz, 160 MHz, The start of a 40 MHz non-HT duplicate or VHT PPDU in the primary 40 MHz or 80+80 MHz channel at or above â€“79 dBm. The start of an HT PPDU under the conditions defined in 19.3.19.5. 80 MHz, 160 MHz, or The start of an 80 MHz non-HT duplicate or VHT PPDU in the primary 80 MHz 80+80 MHz channel at or above â€“76 dBm. 160 MHz or 80+80 MHz The start of a 160 MHz or 80+80 MHz non-HT duplicate or VHT PPDU at or above â€“73 dBm. The receiver shall issue a PHY-CCA.indication(BUSY, {primary}) primitive for any signal that exceeds a threshold equal to 20 dB above the minimum modulation and coding rate sensitivity (â€“82 + 20 = â€“62 dBm) in the primary 20 MHz channel within a period of aCCATime after the signal arrives at the receiverâ€™s antenna(s); then the receiver shall not issue a PHY-CCA.indication(BUSY,{secondary}), PHY- CCA.indication(BUSY,{secondary40}), PHY-CCA.indication(BUSY,{secondary80}), or PHY- CCA.indication(IDLE) primitive while the threshold continues to be exceeded. 21.3.18.5.4 CCA sensitivity for signals not occupying the primary 20 MHz channel The PHY shall issue a PHY-CCA.indication(BUSY, {secondary}) primitive if the conditions for issuing PHY-CCA.indication(BUSY, {primary}) primitive are not present and one of the following conditions are present in an otherwise idle 40 MHz, 80 MHz, 160 MHz, or 80+80 MHz operating channel width: â€” Any signal within the secondary 20 MHz channel at or above a threshold of â€“62 dBm within a period of aCCATime after the signal arrives at the receiverâ€™s antenna(s); then the PHY shall not issue a PHY-CCA.indication(BUSY,{secondary40}), PHY-CCA.indication(BUSY,{secondary80}), or PHY-CCA.indication(IDLE) primitive while the threshold continues to be exceeded. â€” A 20 MHz NON_HT, HT_MF, HT_GF or VHT PPDU detected in the secondary 20 MHz channel at or above â€“72 dBm with >90% probability within a period aCCAMidTime (see 21.4.4). The PHY shall issue a PHY-CCA.indication(BUSY, {secondary40}) primitive if the conditions for issuing a PHY-CCA.indication(BUSY, {primary}) and PHY-CCA.indication(BUSY, {secondary}) primitive are not present and one of the following conditions are present in an otherwise idle 80 MHz, 160 MHz, or 80+80 MHz operating channel width: â€” Any signal within the secondary 40 MHz channel at or above a threshold of â€“59 dBm within a period of aCCATime after the signal arrives at the receiverâ€™s antenna(s); then the PHY shall not issue a PHY-CCA.indication(BUSY, {secondary80}) primitive or PHY-CCA.indication(IDLE) primitive while the threshold continues to be exceeded. â€” A 40 MHz non-HT duplicate, HT_MF, HT_GF or VHT PPDU detected in the secondary 40 MHz channel at or above â€“72 dBm with >90% probability within a period aCCAMidTime (see 21.4.4). â€” A 20 MHz non-HT, HT_MF, HT_GF or VHT PPDU detected in any 20 MHz sub-channel of the secondary 40 MHz channel at or above â€“72 dBm with >90% probability within a period aCCAMidTime. 2594 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The PHY shall issue a PHY-CCA.indication(BUSY, {secondary80}) primitive if the conditions for PHY- CCA.indication(BUSY, {primary}), PHY-CCA.indication(BUSY, {secondary}), and PHY- CCA.indication(BUSY, {secondary40}) primitive are not present and one of the following conditions are present in an otherwise idle 160 MHz or 80+80 MHz operating channel width: â€” Any signal within the secondary 80 MHz channel at or above â€“56 dBm. â€” An 80 MHz non-HT duplicate or VHT PPDU detected in the secondary 80 MHz channel at or above â€“69 dBm with >90% probability within a period aCCAMidTime (see 21.4.4). â€” A 40 MHz non-HT duplicate, HT_MF, HT_GF or VHT PPDU detected in any 40 MHz sub-channel of the secondary 80 MHz channel at or above â€“72 dBm with >90% probability within a period aCCAMidTime. â€” A 20 MHz NON_HT, HT_MF, HT_GF or VHT PPDU detected in any 20 MHz sub-channel of the secondary 80 MHz channel at or above â€“72 dBm with >90% probability within a period aCCAMidTime. 21.3.18.6 RSSI The RSSI parameter returned in the RXVECTOR shall be calculated during the reception of the VHT-LTFs and shall be a monotonically increasing function of the received power. 21.3.19 PHY transmit procedure There are two paths for the transmit PHY procedure: â€” The first path, for which typical transmit procedures are shown in Figure 21-34, is selected if the FORMAT parameter of the PHY-TXSTART.request(TXVECTOR) primitive is VHT. These transmit procedures do not describe the operation of optional features, such as LDPC, STBC or MU. â€” The second path is to follow the transmit procedure in Clause 17 if the FORMAT parameter of the PHY-TXSTART.request(TXVECTOR) primitive is NON_HT and the NON_HT_MODULATION parameter is set to NON_HT_DUP_OFDM except that the signal referred to in Clause 17 is instead generated simultaneously on each of the 20 MHz channels that are indicated by the CH_BANDWIDTH parameter as defined in 21.3.8 and 21.3.10.12. NOTE 1â€”For a VHT MU PPDU the A-MPDU is per user in the MAC sublayer and the VHT Training Symbols, VHT- SIG-B, and Data are per user in the PHY in Figure 21-34, with the number VHT Training Symbols depending on the total number of space-time streams across all users. NOTE 2â€”The transmit procedure for NON_HT format where NON_HT_MODULATION is OFDM is specified in 21.2.5.2. The transmit procedure for HT_MF and HT_GF formats is specified in 21.2.5.3. In both paths, in order to transmit data, the MAC generates a PHY-TXSTART.request primitive, which causes the PHY entity to enter the transmit state. Further, the PHY is set to operate at the appropriate frequency through station management via the PLME, as specified in 21.4. Other transmit parameters, such as VHT-MCS Coding types and transmit power, are set via the PHY SAP using the PHY- TXSTART.request(TXVECTOR) primitive, as described in 21.2.2. The remainder of the clause applies to the first path. The PHY indicates the state of the primary channel and other channels (if any) via the PHY-CCA.indication primitive (see 21.3.18.5 and 8.3.5.12). Transmission of the PPDU shall be initiated by the PHY after receiving the PHY-TXSTART.request(TXVECTOR) primitive. The TXVECTOR elements for the PHY- TXSTART.request primitive are specified in Table 21-1. Transmission of the PHY preamble may start if TIME_OF_DEPARTURE_REQUESTED is false, and shall start immediately if TIME_OF_DEPARTURE_REQUESTED is true, based on the parameters passed in the PHY-TXSTART.request primitive. 2595 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications PHY-TXSTART.confirm PHY-TXEND.request PHY-DATA.request PHY-DATA.confirm PHY-DATA.request PHY-DATA.confirm PHY-TXSTART.request PHY-TXEND.confirm (TXVECTOR) â€¦â€¦â€¦â€¦..â€¦â€¦â€¦â€¦ MAC A-MPDU including EOF padding Bit Padding VHT- VHT- if needed L-SIG Service PSDU SIG-A SIG-B Tail Bits Scrambling + encoding VHT- VHT- VHT VHT- L-STF L-LTF L-SIG SIG-A SIG-A Training Data (Variable number of OFDM symbols) SIG-B Sym 1 Sym 2 Symbols PHY Coded Coded Coded OFDM OFDM OFDM Coded OFDM, VHT-MCS indicated in BPSK, QBPSK, BPSK, VHT-SIG-A Rate Â½ Rate Â½ Rate Â½ Coded OFDM BPSK, Rate Â½ NOTEâ€”This procedure does not describe the operation of optional features, such as MU-MIMO, LDPC or STBC. Figure 21-34â€”PHY transmit procedure for SU transmission If all of the following conditions are met: â€” If dot11TODImplemented and dot11TODActivated are true or if dot11TimingMsmtActivated is true, â€” The TXVECTOR parameter TIME_OF_DEPARTURE_REQUESTED is true, then the PHY shall issue a PHY-TXSTART.confirm(TXSTATUS) primitive to the MAC, forwarding the TIME_OF_DEPARTURE corresponding to the time when the first frame energy is sent by the transmitting port and TIME_OF_DEPARTURE_ClockRate parameter within the TXSTATUS vector. If dot11TimingMsmtActivated is true, then the PHY shall forward the value of TX_START_OF_FRAME_OFFSET in TXSTATUS vector. After the PHY preamble transmission is started, the PHY entity immediately initiates data scrambling and data encoding. The encoding method for the Data field is based on the FEC_CODING, CH_BANDWIDTH, NUM_STS, STBC, MCS, and NUM_USERS parameter of the TXVECTOR, as described in 21.3.2. The SERVICE field and PSDU are encoded as described in 21.3.3. The data shall be exchanged between the MAC and the PHY through a series of PHY-DATA.request(DATA) primitives issued by the MAC, and PHY-DATA.confirm primitives issued by the PHY. Zero to seven PHY padding bits are appended to the PSDU to make the number of bits in the coded PSDU an integer multiple of the number of coded bits per OFDM symbol. Transmission can be prematurely terminated by the MAC through the PHY-TXEND.request primitive. PSDU transmission is terminated by receiving a PHY-TXEND.request primitive. Each PHY- TXEND.request primitive is acknowledged with a PHY-TXEND.confirm primitive from the PHY. In an SU transmission, normal termination occurs after the transmission of the final bit of the last PSDU octet, according to the number of OFDM symbols indicated by NSYM (see 21.4.3). 2596 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications In the PHY, the GI or short GI is inserted in every data OFDM symbol as a countermeasure against delay spread. When the PPDU transmission is completed the PHY entity enters the receive state. A typical state machine implementation of the transmit PHY for an SU transmission is provided in Figure 21-35. Request (.request) and confirmation (.confirm) primitives are issued once per state as shown. This state machine does not describe the operation of optional features, such as multi-user, LDPC or STBC. 21.3.20 PHY receive procedure A typical PHY receive procedure is shown in Figure 21-36 for VHT format. A typical state machine implementation of the receive PHY is given in Figure 21-37. This receive procedure and state machine do not describe the operation of optional features, such as LDPC or STBC. If the detected format indicates a NON_HT PPDU, refer to the receive procedure and state machine in Clause 17. If the detected format indicates an HT PPDU format, refer to the receive procedure and state machine in Clause 19. Further, through station management (via the PLME) the PHY is set to the appropriate frequency, as specified in 21.4. The PHY has also been configured with group information (i.e., group membership and position in group) so that it can receive data intended for the STA. Other receive parameters, such as RSSI and indicated DATARATE, may be accessed via the PHY SAP. Upon receiving the transmitted PHY preamble overlapping the primary 20 MHz channel, the PHY measures a receive signal strength. The PHY indicates this activity to the MAC by issuing a PHY-CCA.indication primitive. A PHY-CCA.indication(BUSY, channel-list) primitive is also issued as an initial indication of reception of a signal as specified in 21.3.18.5. The channel-list parameter of the PHY-CCA.indication primitive is absent when the operating channel width is 20 MHz. The channel-list parameter is present and includes the element primary when the operating channel width is 40 MHz, 80 MHz, 160 MHz, or 80+80 MHz. The PHY shall not issue a PHY-RXSTART.indication primitive in response to a PPDU that does not overlap the primary 20 MHz channel. The PHY includes the most recently measured RSSI value in the PHY-RXSTART.indication(RXVECTOR) primitive issued to the MAC. After the PHY-CCA.indication(BUSY, channel-list) primitive is issued, the PHY entity shall begin receiving the training symbols and searching for L-SIG in order to set the maximum duration of the data stream. If the check of the L-SIG parity bit is not valid, a PHY-RXSTART.indication primitive is not issued, and instead the PHY shall issue the error condition PHY-RXEND.indication(FormatViolation) primitive. If a valid L-SIG parity bit is indicated, the VHT PHY shall maintain PHY- CCA.indication(BUSY, channel-list) primitive for the predicted duration of the transmitted PPDU, as defined by RXTIME in Equation (21-105), for all supported modes, unsupported modes, Reserved VHT- SIG-A Indication, invalid VHT-SIG-A CRC and invalid L-SIG Length field value. The L-SIG Length field value of a VHT PPDU is invalid if it is not divisible by 3. Reserved VHT-SIG-A Indication is defined as a VHT-SIG-A with Reserved bits equal to 0 or MU[u] NSTS fields (u = 0, 1, 2, 3) set to 5-7 or Short GI field set to 0 and Short GI NSYM Disambiguation field set to 1, or a combination of VHT-MCS and NSTS not included in 21.5 or any other VHT-SIG-A field bit combinations that do not correspond to modes of PHY operation defined in Clause 21. If the VHT-SIG-A indicates an unsupported mode, the PHY shall issue a PHY-RXEND.indication(UnsupportedRate) primitive. If the VHT-SIG-A indicates an invalid CRC or Reserved VHT-SIG-A Indication or if the L-SIG Length field is invalid, the PHY shall issue the error condition PHY-RXEND.indication(FormatViolation) primitive. 2597 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications PHY-TXSTART.request (TXVECTOR) TX PSDU OCTET PHY-DATA. request(DATA) Get octet from MAC, FORMAT= scramble, encode and Initialize NON_HT Refer buffer to Clause 17 FORMAT= PHY-DATA.confirm HT_MF or HT_GF Refer to Buffer contains a Set TX parameters Clause 19 symbolâ€™s worth of data or last octet otherwise && received from MAC PHY-DATA request(DATA) FORMAT= VHT Last Symbol? TX L-Preamble Yes No TX L-STF TX L-LTF TX L-SIG in BPSK rate 1/2 PADDING & TAIL Add 0 to 7 PHY padding bits, scramble, encode, and TX VHT-Preamble buffer, encode & buffer tail bits (BCC only) TX VHT-SIG-A1 (BPSK) TX VHT-SIG-A2 (QBPSK) TX SYMBOL TX VHT Training Symbols TX VHT-SIG-B (BPSK) TX Data Use MCS and number of space-time streams set by Decrement Symbol TXVECTOR Decrement symbol 16 bit service field prepended, count Symbol Count > 0 padding and tail bits appended to PSDU Symbol Count = 0 Switch to RX state SETUP MPDU TX A PHY-TXSTART.confirm PHY-DATA.request(DATA) Set symbol count to NSYM At any stage in the A above flow diagram, if a PHY-TXEND.request is received NOTEâ€”This state machine does not describe the operation of optional features, such as MU-MIMO, LDPC or STBC. Figure 21-35â€”PHY transmit state machine for SU transmission 2598 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications CS/CCA state RX state PHY-RXSTART.indication PHY-RXEND.indication (NoError, RXVECTOR) PHY-DATA.indication PHY-DATA.indication PHY-DATA.indication PHY-CCA.indication PHY-CCA.indication (Busy,primary) (RXVECTOR) â€¦â€¦â€¦â€¦..â€¦â€¦â€¦â€¦ (IDLE) MAC A-MPDU Decoding Delay VHT- L-SIG PSDU SIG-A Decoded and Pad (if present) descrambled and Tail bits Measure RSSI Measure RSSI Measure RCPI PHY VHT- VHT- VHT- VHT- Data (Variable number of OFDM L-STF L-LTF L-SIG SIG-A SIG-A Training SIG-B symbols) Sym 1 Sym 2 Symbols Coded Coded Coded OFDM OFDM OFDM Coded OFDM, VHT-MCS indicated in BPSK, QBPSK, BPSK, VHT-SIG-A Rate Â½ Rate Â½ Rate Â½ Coded OFDM BPSK, Rate Â½ NOTEâ€”This procedure does not describe the operation of optional features, such as LDPC or STBC. This procedure describes the case where VHT-SIG-A indicates a mode not requiring decoding of VHT-SIG-B. Figure 21-36â€”PHY receive procedure for SU transmission After receiving a valid L-SIG and VHT-SIG-A indicating a supported mode, the PHY entity shall begin receiving the VHT training symbols and VHT-SIG-B. If the received group ID in VHT-SIG-A has a value indicating a VHT SU PPDU (see 10.20), the PHY entity may choose not to decode VHT-SIG-B. If VHT- SIG-B is not decoded, subsequent to an indication of a valid VHT-SIG-A CRC, a PHY- RXSTART.indication(RXVECTOR) primitive shall be issued. Subsequently, if dot11TimingMsmtActivated is true, a PHY-RXSTART.indication(RXVECTOR) primitive shall be issued and RX_START_OF_FRAME_OFFSET parameter within the RXVECTOR shall be forwarded (see 20.2.2). NOTEâ€”The RX_START_OF_FRAME_OFFSET value is used as described in 6.3.57 in order to estimate when the start of the preamble for the incoming frame was detected on the medium at the receive antenna connector. The RXVECTOR associated with this primitive includes the parameters specified in Table 21-1. If the Group ID field in VHT-SIG-A has a value indicating a VHT MU PPDU (see 10.20), the PHY, in a STA that is MU beamformee capable, shall decode VHT-SIG-B. If the VHT-SIG-B indicates an unsupported mode, the PHY shall issue the error condition PHY-RXEND.indication(UnsupportedRate) primitive. If VHT-SIG-B was decoded the PHY may check the VHT-SIG-B CRC in the SERVICE field. If the VHT- SIG-B CRC in the SERVICE field is not checked a PHY-RXSTART.indication(RXVECTOR) primitive shall be issued. The RXVECTOR associated with this primitive includes the parameters specified in Table 21-1. 2599 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications RX IDLE state CS/CCA Set PHY-CCA.indication(BUSY,primary) End of Wait Detect SIG HT_SIG (HT GF preamble): RX Symbol Determine type of Refer to 19.3.23 Set PHY- SIG field CCA.indication() in accordance L-SIG with 21.3.18.5 Carrier lost Valid Signal Detect L-SIG If SERVICE field and Decode Symbol Receive L-SIG field Signal Not Valid VHT-SIG-B Carrier Lost: Decode and decoded Set PHY-RXEND.indication descramble Signal Valid and CRC (CarrierLost) Set RxEndStatus = symbol checked (CarrierLost, Null) RX L-SIG Otherwise Parity Fail: RX and test CRC Set PHY-RXEND.indication (FormatViolation) Parity CRC CRC N_symbol>0 fail pass Detect HT-SIG HT_SIG (HT MF preamble): A Decrement N_symbol Determine Refer to 19.3.23 whether HT-SIG follows L-SIG PHY-DATA.indication Not HT-SIG (DATA) Carrier Lost: (bit removing if Set PHY-RXEND.indication Detect VHT-SIG-A Not VHT-SIG-A: needed) (CarrierLost) Determine whether Refer to 17.3.12 Decrement Time Decrement symbol VHT-SIG-A follows count L-SIG Wait for intended N_symbol=0 VHT-SIG-A end of PSDU based CRC Fail: Set PHY-RXEND.indication on RXTIME End of PSDU RX RX VHT-SIG-A (FormatViolation) RX and test CRC Time = 0 Set RxEndStatus = (NoError, RXVECTOR) Unsupported mode: Set PHY-RXSTART.indication CRC OK End of Wait (RXVECTOR) Evaluate VHT- then set PHY-RXEND.indication SIG-A Set PHY- (UnsupportedRate) Check contents in CCA.indication(IDLE Supported ) VHT-SIG-A for mode, no supported mode VHT-SIG-B Reserved VHT-SIG-A Indication decoding and Invalid L-LENGTH: Supported mode, Set PHY-RXEND.indication VHT-SIG-B (FormatViolation) decoding RX VHT-SIG-B Unsupported mode: RX Set PHY- RXSTART.indication(RXV ECTOR) then set Evaluate VHT-SIG-B PHY-RXEND.indication (UnsupportedRate) Check contents in VHT-SIG-B for supported mode Filtered out: Supported Set mode PHY-RXSTART.indication(RXVECTOR) then set Determine if PPDU is NOTEâ€”This state machine does not PHY-RXEND.indication filtered out or not (Filtered) describe the operation of optional features, Evaluate whether the PPDU is filtered out or not such as LDPC, STBC or partial AID. based on PHYCONFIG_VECTOR End of Wait Not filtered out For unsupported modes, Reserved VHT-SIG-A Indication, VHT-SIG-A CRC Setup PSDU RX failure or filtered PPDU: set PHY-CCA.indication(IDLE) A Set N_symbols = NSYM when predicted duration Set PHY-RXSTART.indication based on RXTIME has (RXVECTOR) elapsed. Figure 21-37â€”PHY receive state machine 2600 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The PHY optionally filters out the PPDU based on the GroupID, MU[0-3] NSTS and Partial AID fields of VHT-SIG-A and the contents of the PHYCONFIG_VECTOR as follows: â€” The PHY shall not filter out the PPDU if one of the following is true: â€” (g = 0) and (l00 is true) and (partialaid is included in PARTIAL_AID_LIST_GID00) â€” (g = 63) and (l63 is true) and (partialaid is included in PARTIAL_AID_LIST_GID63) â€” (1 g 62) and (MembershipStatusInGroupID[g] = 1) and (nSTS[UserPositionInGroupID[g]] > 0) â€” where â€” lNN is the one of the LISTEN_TO_GIDNN parameters of the PHYCONFIG_VECTOR â€” MembershipStatusInGroupID[g] is the Membership Status Array field of the GROUP_ID_MANAGEMENT parameter of the PHYCONFIG_VECTOR for group g â€” g is the value of the GroupID field of VHT-SIG-A â€” nSTS[u] is the value of the MU[u] NSTS field of VHT-SIG-A â€” UserPositionInGroupID[g] is the User Position Array field of the GROUP_ID_MANAGE- MENT parameter of the PHYCONFIG_VECTOR for group g â€” partialaid is the value of the Partial AID field of VHT-SIG-A â€” Otherwise, the PHY may filter out the PPDU. If the PPDU is filtered out, the PHY shall issue a PHY-RXEND.indication(Filtered) primitive. Following training and signal fields, the Data field shall be received. The number of symbols in the Data field is determined by Equation (21-104). N' SYM â€“ 1 if Short GI = 1 and Short GI NSYM Disambiguation = 1 N SYM = (21-104) N' SYM otherwise where T L-STF + T L-LTF + T L-SIG + T VHT-SIG-A + RXTIME â€“ T VHT-STF + N VHT - LTF T VHT-LTF + T VHT-SIG-B N' SYM = --------------------------------------------------------------------------------------------------------------------------------------------------- T SYM RXTIME( s = LENGTH + 3- 4 + 20 (21-105) -------------------------------- 3 where LENGTH is the LENGTH field in L-SIG. The value of the PSDU_LENGTH parameter returned in the RXVECTOR using BCC encoding is calculated using Equation (21-106). N SYM N DBPS â€“ N service â€“ N tail N ES PSDU_LENGTH = ----------------------------------------------------------------------------------- (21-106) 8 where N SYM is given by Equation (21-104) For a VHT SU PPDU, the SU/MU[0] Coding field of VHT-SIG-A2 indicates the type of coding. The PHY entity shall use an LDPC decoder to decode the C-PSDU if this bit is 1; otherwise, BCC decoding shall be used. For an MU transmission, the SU/MU[0] Coding, MU[1] Coding, MU[2] Coding and MU[3] Coding 2601 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications fields of VHT-SIG-A2 indicate the type of coding for user u with USER_POSITION[u] = 0, 1, 2, and 3, respectively. The PHY entity shall use an LDPC decoder to decode the C-PSDU for the respective user if its bit for its C-PSDU is 1. BCC decoding shall be used otherwise. When an LDPC decoder is to be used, NSYM,init is obtained from Equation (21-107). N SYM init if LDPC Extra OFDM Symbol = 0 N SYM init = N SYM init â€“ 1 if LDPC Extra OFDM Symbol = 1 and STBC = 0 (21-107) N SYM init â€“ 2 if LDPC Extra OFDM Symbol = 1 and STBC = 1 where LDPC Extra OFDM Symbol and STBC are fields in VHT-SIG-A (see Table 21-12) The value of the PSDU_LENGTH parameter returned in the RXVECTOR using LDPC encoding is calculated using Equation (21-108). N SYM init N DBPS â€“ N service PSDU_LENGTH = ------------------------------------------------------------- (21-108) 8 where N SYM init is given by Equation (21-107) The value of the PSDU_LENGTH parameter returned in the RXVECTOR for an NDP is 0. If VHT-SIG-B is decoded and the VHT-SIG-B CRC in the SERVICE field is checked and not valid, the PHY shall issue the error condition PHY-RXEND.indication(FormatViolation) primitive. If the VHT-SIG-B field is decoded and the VHT-SIG-B CRC field is checked and valid, a PHY- RXSTART.indication(RXVECTOR) primitive shall be issued. The RXVECTOR associated with this primitive includes the parameters specified in Table 21-1. If signal loss occurs during reception prior to completion of the PSDU reception, the error condition shall be reported to the MAC using a PHY-RXEND.indication(CarrierLost) primitive. After waiting for the intended end of the PSDU as determined by Equation (21-105), the PHY shall generate a PHY- CCA.indication(IDLE) primitive and return to RX IDLE state. The received PSDU bits are assembled into octets, decoded, and presented to the MAC using a series of PHY-DATA.indication(DATA) primitive exchanges. Any final bits that cannot be assembled into a complete octet are considered pad bits and discarded. After the reception of the final bit of the last PSDU octet, and possible padding and tail bits, the receiver shall be returned to the RX IDLE state, as shown in Figure 21-37. A PHY-RXEND.indication(NoError) primitive shall be issued on entry to the RX IDLE state. 21.4 VHT PLME 21.4.1 PLME SAP sublayer management primitives Table 21-28 lists the MIB attributes that may be accessed by the PHY entities and the intralayer of higher level LMEs. These attributes are accessed via the PLME-GET, PLME-SET, PLME-RESET, and PLME- CHARACTERISTICS primitives defined in 6.5. 2602 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-28â€”VHT PHY MIB attributes Default value/ Operational Managed object range semantics dot11PHYOperationTable dot11PHYType vht(9) Static dot11PHYTxPowerTable dot11NumberSupportedPowerLevelsImplemented Implementation Static dependent dot11TxPowerLevel1 Implementation Static dependent dot11TxPowerLevel2 Implementation Static dependent dot11TxPowerLevel3 Implementation Static dependent dot11TxPowerLevel4 Implementation Static dependent dot11TxPowerLevel5 Implementation Static dependent dot11TxPowerLevel6 Implementation Static dependent dot11TxPowerLevel7 Implementation Static dependent dot11TxPowerLevel8 Implementation Static dependent dot11CurrentTxPowerLevel Implementation Static dependent dot11TxPowerLevelExtended Implementation Static dependent dot11CurrentTxPowerLevelExtended Implementation Static dependent dot11PHYHTTable dot11CurrentPrimaryChannel Implementation Dynamic dependent dot11CurrentSecondaryChannel Implementation Dynamic dependent dot11FortyMHzOperationImplemented false/Boolean Static dot11FortyMHzOperationActivated false/Boolean Dynamic dot11NumberOfSpatialStreamsImplemented Implementation Static dependent dot11NumberOfSpatialStreamsActivated Implementation Dynamic dependent dot11HTGreenfieldOptionImplemented false/Boolean Static dot11HTGreenfieldOptionActivated false/Boolean Dynamic 2603 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-28â€”VHT PHY MIB attributes (continued) Default value/ Operational Managed object range semantics dot11ShortGIOptionInTwentyImplemented false/Boolean Static dot11ShortGIOptionInTwentyActivated false/Boolean Dynamic dot11ShortGIOptionInFortyImplemented false/Boolean Static dot11ShortGIOptionInFortyActivated false/Boolean Dynamic dot11LDPCCodingOptionImplemented false/Boolean Static dot11LDPCCodingOptionActivated false/Boolean Dynamic dot11TxSTBCOptionImplemented false/Boolean Static dot11TxSTBCOptionActivated false/Boolean Dynamic dot11RxSTBCOptionImplemented false/Boolean Static dot11RxSTBCOptionActivated false/Boolean Dynamic dot11BeamFormingOptionImplemented false/Boolean Static dot11BeamFormingOptionActivated false/Boolean Dynamic dot11PHYVHTTable dot11CurrentChannelWidth Implementation Dynamic dependent dot11CurrentChannelCenterFrequencyIndex0 Implementation Dynamic dependent dot11CurrentChannelCenterFrequencyIndex1 Implementation Dynamic dependent dot11VHTChannelWidthOptionImplemented Implementation Static dependent dot11VHTShortGIOptionIn80Implemented false/Boolean Static dot11VHTShortGIOptionIn80Activated false/Boolean Dynamic dot11VHTShortGIOptionIn160and80p80Implemented false/Boolean Static dot11VHTShortGIOptionIn160and80p80Activated false/Boolean Dynamic dot11VHTLDPCCodingOptionImplemented false/Boolean Static dot11VHTLDPCCodingOptionActivated false/Boolean Dynamic dot11VHTTxSTBCOptionImplemented false/Boolean Static dot11VHTTxSTBCOptionActivated false/Boolean Dynamic dot11VHTRxSTBCOptionImplemented false/Boolean Static dot11VHTRxSTBCOptionActivated false/Boolean Dynamic dot11VHTMaxNTxChainsImplemented Implementation Static dependent dot11VHTMaxNTxChainsActivated Implementation Dynamic dependent 2604 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-28â€”VHT PHY MIB attributes (continued) Default value/ Operational Managed object range semantics dot11TransmitBeamformingConfigTable dot11ReceiveStaggerSoundingOptionImplemented false/Boolean Static dot11TransmitStaggerSoundingOptionImplemented false/Boolean Static dot11ReceiveNDPOptionImplemented false/Boolean Static dot11TransmitNDPOptionImplemented false/Boolean Static dot11ImplicitTransmitBeamformingOptionImplemented false/Boolean Static dot11CalibrationOptionImplemented Implementation Static dependent dot11ExplicitCSITransmitBeamformingOptionImplement false/Boolean Static ed dot11ExplicitNonCompressedBeamformingMatrixOptionI false/Boolean Static mplemented dot11ExplicitTransmitBeamformingCSIFeedbackOptionI Implementation Static mplemented dependent dot11ExplicitNoncompressedBeamformingFeedbackOptio Implementation Static nImplemented dependent dot11ExplicitCompressedBeamformingFeedbackOptionI Implementation Static mplemented dependent dot11NumberBeamFormingCSISupportAntenna Implementation Static dependent dot11NumberNonCompressedBeamformingMatrixSuppor Implementation Static tAntenna dependent dot11NumberCompressedBeamformingMatrixSupportAnt Implementation Static enna dependent dot11VHTTransmitBeamformingConfigTable dot11VHTSUBeamformeeOptionImplemented false/Boolean Static dot11VHTSUBeamformerOptionImplemented false/Boolean Static dot11VHTMUBeamformeeOptionImplemented false/Boolean Static dot11VHTMUBeamformerOptionImplemented false/Boolean Static dot11VHTNumberSoundingDimensions Implementation Static dependent dot11VHTBeamformeeNTxSupport Implementation Static dependent 21.4.2 PHY MIB VHT PHY MIB attributes are defined in Annex C with specific values defined in Table 21-28. The â€œOperational semanticsâ€ column in Table 21-28 contains two types: static and dynamic. â€” Static MIB attributes are fixed and cannot be modified for a given PHY implementation. â€” Dynamic MIB attributes are interpreted according to the MAX-ACCESS field of the MIB attribute. 2605 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications When MAX-ACCESS is read-only, the MIB attribute value may be updated by the PLME and read from the MIB attribute by management entities. When MAX-ACCESS is read-write, the MIB attribute may be read and written by management entities but shall not be updated by the PLME. 21.4.3 TXTIME and PSDU_LENGTH calculation The value of the TXTIME parameter returned by the PLME-TXTIME.confirm primitive shall be calculated for a VHT PPDU using Equation (21-109) for short GI and Equation (21-110) for long GI. T SYMS N SYM TXTIME = T LEG_PREAMBLE + T L-SIG + T VHT-SIG-A + T VHT_PREAMBLE + T VHT-SIG-B + T SYML ----------------------------------- (21-109) T SYML TXTIME = T LEG_PREAMBLE + T L-SIG + T VHT-SIG-A + T VHT_PREAMBLE + T VHT-SIG-B + T SYML N SYM (21-110) where T LEG_PREAMBLE = T L-STF + T L-LTF T VHT_PREAMBLE = T VHT-STF + N VHT - LTF T VHT-LTF T SYML , T SYMS , T VHT-SIG-A , T VHT-SIG-B , T L-STF , T VHT-STF , T L-LTF , and T VHT-LTF are defined in Table 21- 5 N VHT - LTF is defined in Table 21-13 For an NDP, there is no Data field and N SYM = 0 . For a VHT SU PPDU using BCC encoding, the total number of data symbols in the Data field is given by Equation (21-111). 8 APEP_LENGTH + N service + N tail N ES N SYM = m STBC -------------------------------------------------------------------------------------------------------- (21-111) m STBC N DBPS where m STBC is equal to 2 when STBC is used, and 1 otherwise For a VHT SU PPDU using LDPC encoding, the total number of data symbols in the Data field, N SYM , is given in 21.3.10.5.4 (computed using Equation (19-41) in step d) of 19.3.11.7.5). For a VHT MU PPDU, the total number of data symbols in the Data field, N SYM , is given by Equation (21-67). The value of the PSDU_LENGTH parameter returned in the PLME-TXTIME.confirm primitive for a VHT SU PPDU using BCC encoding is calculated using Equation (21-112). N SYM N DBPS â€“ N service â€“ N tail N ES PSDU_LENGTH = ----------------------------------------------------------------------------------- (21-112) 8 where N SYM is given by Equation (21-111) 2606 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The value of the PSDU_LENGTH parameter returned in the PLME-TXTIME.confirm primitive for a VHT SU PPDU using LDPC encoding is calculated using Equation (21-113). N SYM init N DBPS â€“ N service PSDU_LENGTH = ------------------------------------------------------------- (21-113) 8 where N SYM init is given by Equation (21-62) The value of the PSDU_LENGTH parameter for user u returned in the PLME-TXTIME.confirm primitive and in the RXVECTOR for a VHT MU PPDU is calculated using Equation (21-114). N SYM N DBPS u â€“ N service â€“ N tail N ES u ------------------------------------------------------------------------------------------- when BCC is used for user u 8 PSDU_LENGTH u = (21-114) N SYM_max_init N DBPS u â€“ N service ------------------------------------------------------------------------- - when LDPC is used for user u 8 where N SYM is given by Equation (21-67), N SYM_max_init is given by Equation (21-65), The value of the PSDU_LENGTH parameter returned in the PLME-TXTIME.confirm primitive for an NDP is 0. 21.4.4 VHT PHY The static VHT PHY characteristics, provided through the PLME-CHARACTERISTICS service primitive, shall be as shown in Table 19-25 unless otherwise listed in Table 21-29. The definitions for these characteristics are given in 6.5. Table 21-29â€”VHT PHY characteristics Characteristics Value aCCAMidTime 25 Âµs aPPDUMaxTime 5.484 ms aPSDUMaxLength 4 692 480 octets (see NOTE 1) aRxPHYStartDelay 36 + 4 Ã— the maximum possible value for NVHT-LTF supported + 4 (see NOTE 2) NOTE 1â€”This is the maximum length in octets for a VHT SU PPDU with a bandwidth of 160 MHz or 80+80 MHz, VHT-MCS 9, and 8 spatial streams, and limited by 1504 possible Short GI data symbols in aPPDUMaxTime. This is the maximum PSDU length a VHT PHY could support assuming no restrictions in MAC. See 10.3.2 and 9.2.4.7.1 for additional restrictions on the maximum number of octets the MAC could support. NOTE 2â€”This value arises from the time to the end of VHT-SIG-B (see Figure 21-4) plus the need to decode the first symbol of the Data field in order to extract the SERVICE field and check the CRC it contains. 2607 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 21.5 Parameters for VHT-MCSs The rate-dependent parameters for 20 MHz, 40 MHz, 80 MHz, 160 MHz, and 80+80 MHz N SS = 1 8 are given in Table 21-30 through Table 21-61. Support for 400 ns GI is optional in all cases. Support for VHT-MCS 8 and 9 (when valid) is optional in all cases. A VHT STA shall support single spatial stream VHT-MCSs within the range VHT-MCS 0 to VHT-MCS 7 for all channel widths for which it has indicated support regardless of the Tx or Rx Highest Supported Long GI Data Rate subfield values in the Supported VHT-MCS and NSS Set field. When more than one spatial stream is supported, the Tx or Rx Highest Supported Long GI Data Rate subfield values in the Supported VHT-MCS and NSS Set field may result in a reduced VHT-MCS range (cut-off) for N SS = 2 8 . Support for 20 MHz, 40 MHz, and 80 MHz with N SS = 1 is mandatory. Support for 20 MHz, 40 MHz, and 80 MHz with N SS = 2 8 is optional. Support for 160 MHz and 80+80 MHz with N SS = 1 8 is optional. NES values were chosen to yield an integer number of punctured blocks for each BCC encoder per OFDM symbol. Table 21-30 to Table 21-33, Table 21-38 to Table 21-41, Table 21-46 to Table 21-49, and Table 21-54 to Table 21-57 define VHT-MCSs not only for SU transmission but also for user u of MU transmission. In the case of VHT-MCSs for MU transmission, the parameters, NSS, R, NBPSCS, NCBPS, NDBPS, and NES are replaced with NSS,u, Ru, NBPSCS,u, NCBPS,u, NDBPS,u, and NES,u, respectively. Note that the 400 ns GI rate values are rounded to 1 decimal place. Table 21-30â€”VHT-MCSs for mandatory 20 MHz, NSS = 1 Data rate (Mb/s) VHT- MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES 400 ns GI Index 800 ns GI (See NOTE) 0 BPSK 1/2 1 52 4 52 26 1 6.5 7.2 1 QPSK 1/2 2 52 4 104 52 1 13.0 14.4 2 QPSK 3/4 2 52 4 104 78 1 19.5 21.7 3 16-QAM 1/2 4 52 4 208 104 1 26.0 28.9 4 16-QAM 3/4 4 52 4 208 156 1 39.0 43.3 5 64-QAM 2/3 6 52 4 312 208 1 52.0 57.8 6 64-QAM 3/4 6 52 4 312 234 1 58.5 65.0 7 64-QAM 5/6 6 52 4 312 260 1 65.0 72.2 8 256-QAM 3/4 8 52 4 416 312 1 78.0 86.7 9 Not valid NOTEâ€”Support of 400 ns GI is optional on transmit and receive. 2608 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-31â€”VHT-MCSs for optional 20 MHz, NSS = 2 VHT- Data rate (Mb/s) MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES Index 800 ns GI 400 ns GI 0 BPSK 1/2 1 52 4 104 52 1 13.0 14.4 1 QPSK 1/2 2 52 4 208 104 1 26.0 28.9 2 QPSK 3/4 2 52 4 208 156 1 39.0 43.3 3 16-QAM 1/2 4 52 4 416 208 1 52.0 57.8 4 16-QAM 3/4 4 52 4 416 312 1 78.0 86.7 5 64-QAM 2/3 6 52 4 624 416 1 104.0 115.6 6 64-QAM 3/4 6 52 4 624 468 1 117.0 130.0 7 64-QAM 5/6 6 52 4 624 520 1 130.0 144.4 8 256-QAM 3/4 8 52 4 832 624 1 156.0 173.3 9 Not valid Table 21-32â€”VHT-MCSs for optional 20 MHz, NSS = 3 VHT- Data rate (Mb/s) MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES Index 800 ns GI 400 ns GI 0 BPSK 1/2 1 52 4 156 78 1 19.5 21.7 1 QPSK 1/2 2 52 4 312 156 1 39.0 43.3 2 QPSK 3/4 2 52 4 312 234 1 58.5 65.0 3 16-QAM 1/2 4 52 4 624 312 1 78.0 86.7 4 16-QAM 3/4 4 52 4 624 468 1 117.0 130.0 5 64-QAM 2/3 6 52 4 936 624 1 156.0 173.3 6 64-QAM 3/4 6 52 4 936 702 1 175.5 195.0 7 64-QAM 5/6 6 52 4 936 780 1 195.0 216.7 8 256-QAM 3/4 8 52 4 1248 936 1 234.0 260.0 9 256-QAM 5/6 8 52 4 1248 1040 1 260.0 288.9 2609 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-33â€”VHT-MCSs for optional 20 MHz, NSS = 4 VHT- Data rate (Mb/s) MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES Index 800 ns GI 400 ns GI 0 BPSK 1/2 1 52 4 208 104 1 26.0 28.9 1 QPSK 1/2 2 52 4 416 208 1 52.0 57.8 2 QPSK 3/4 2 52 4 416 312 1 78.0 86.7 3 16-QAM 1/2 4 52 4 832 416 1 104.0 115.6 4 16-QAM 3/4 4 52 4 832 624 1 156.0 173.3 5 64-QAM 2/3 6 52 4 1248 832 1 208.0 231.1 6 64-QAM 3/4 6 52 4 1248 936 1 234.0 260.0 7 64-QAM 5/6 6 52 4 1248 1040 1 260.0 288.9 8 256-QAM 3/4 8 52 4 1664 1248 1 312.0 346.7 9 Not valid Table 21-34â€”VHT-MCSs for optional 20 MHz, NSS = 5 VHT- Data rate (Mb/s) MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES Index 800 ns GI 400 ns GI 0 BPSK 1/2 1 52 4 260 130 1 32.5 36.1 1 QPSK 1/2 2 52 4 520 260 1 65.0 72.2 2 QPSK 3/4 2 52 4 520 390 1 97.5 108.3 3 16-QAM 1/2 4 52 4 1040 520 1 130.0 144.4 4 16-QAM 3/4 4 52 4 1040 780 1 195.0 216.7 5 64-QAM 2/3 6 52 4 1560 1040 1 260.0 288.9 6 64-QAM 3/4 6 52 4 1560 1170 1 292.5 325.0 7 64-QAM 5/6 6 52 4 1560 1300 1 325.0 361.1 8 256-QAM 3/4 8 52 4 2080 1560 1 390.0 433.3 9 Not valid 2610 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-35â€”VHT-MCSs for optional 20 MHz, NSS = 6 VHT- Data rate (Mb/s) MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES Index 800 ns GI 400 ns GI 0 BPSK 1/2 1 52 4 312 156 1 39.0 43.3 1 QPSK 1/2 2 52 4 624 312 1 78.0 86.7 2 QPSK 3/4 2 52 4 624 468 1 117.0 130.0 3 16-QAM 1/2 4 52 4 1248 624 1 156.0 173.3 4 16-QAM 3/4 4 52 4 1248 936 1 234.0 260.0 5 64-QAM 2/3 6 52 4 1872 1248 1 312.0 346.7 6 64-QAM 3/4 6 52 4 1872 1404 1 351.0 390.0 7 64-QAM 5/6 6 52 4 1872 1560 1 390.0 433.3 8 256-QAM 3/4 8 52 4 2496 1872 1 468.0 520.0 9 256-QAM 5/6 8 52 4 2496 2080 1 520.0 577.8 Table 21-36â€”VHT-MCSs for optional 20 MHz, NSS = 7 VHT- Data rate (Mb/s) MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES Index 800 ns GI 400 ns GI 0 BPSK 1/2 1 52 4 364 182 1 45.5 50.6 1 QPSK 1/2 2 52 4 728 364 1 91.0 101.1 2 QPSK 3/4 2 52 4 728 546 1 136.5 151.7 3 16-QAM 1/2 4 52 4 1456 728 1 182.0 202.2 4 16-QAM 3/4 4 52 4 1456 1092 1 273.0 303.3 5 64-QAM 2/3 6 52 4 2184 1456 1 364.0 404.4 6 64-QAM 3/4 6 52 4 2184 1638 1 409.5 455.0 7 64-QAM 5/6 6 52 4 2184 1820 1 455.0 505.6 8 256-QAM 3/4 8 52 4 2912 2184 2 546.0 606.7 9 Not valid 2611 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-37â€”VHT-MCSs for optional 20 MHz, NSS = 8 VHT- Data rate (Mb/s) MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES Index 800 ns GI 400 ns GI 0 BPSK 1/2 1 52 4 416 208 1 52.0 57.8 1 QPSK 1/2 2 52 4 832 416 1 104.0 115.6 2 QPSK 3/4 2 52 4 832 624 1 156.0 173.3 3 16-QAM 1/2 4 52 4 1664 832 1 208.0 231.1 4 16-QAM 3/4 4 52 4 1664 1248 1 312.0 346.7 5 64-QAM 2/3 6 52 4 2496 1664 1 416.0 462.2 6 64-QAM 3/4 6 52 4 2496 1872 1 468.0 520.0 7 64-QAM 5/6 6 52 4 2496 2080 1 520.0 577.8 8 256-QAM 3/4 8 52 4 3328 2496 2 624.0 693.3 9 Not valid Table 21-38â€”VHT-MCSs for mandatory 40 MHz, NSS = 1 Data rate (Mb/s) VHT- MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES 400 ns GI Index 800 ns GI (See NOTE) 0 BPSK 1/2 1 108 6 108 54 1 13.5 15.0 1 QPSK 1/2 2 108 6 216 108 1 27.0 30.0 2 QPSK 3/4 2 108 6 216 162 1 40.5 45.0 3 16-QAM 1/2 4 108 6 432 216 1 54.0 60.0 4 16-QAM 3/4 4 108 6 432 324 1 81.0 90.0 5 64-QAM 2/3 6 108 6 648 432 1 108.0 120.0 6 64-QAM 3/4 6 108 6 648 486 1 121.5 135.0 7 64-QAM 5/6 6 108 6 648 540 1 135.0 150.0 8 256-QAM 3/4 8 108 6 864 648 1 162.0 180.0 9 256-QAM 5/6 8 108 6 864 720 1 180.0 200.0 NOTEâ€”Support of 400 ns GI is optional on transmit and receive. 2612 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-39â€”VHT-MCSs for optional 40 MHz, NSS = 2 VHT- Data rate (Mb/s) MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES Index 800 ns GI 400 ns GI 0 BPSK 1/2 1 108 6 216 108 1 27.0 30.0 1 QPSK 1/2 2 108 6 432 216 1 54.0 60.0 2 QPSK 3/4 2 108 6 432 324 1 81.0 90.0 3 16-QAM 1/2 4 108 6 864 432 1 108.0 120.0 4 16-QAM 3/4 4 108 6 864 648 1 162.0 180.0 5 64-QAM 2/3 6 108 6 1296 864 1 216.0 240.0 6 64-QAM 3/4 6 108 6 1296 972 1 243.0 270.0 7 64-QAM 5/6 6 108 6 1296 1080 1 270.0 300.0 8 256-QAM 3/4 8 108 6 1728 1296 1 324.0 360.0 9 256-QAM 5/6 8 108 6 1728 1440 1 360.0 400.0 Table 21-40â€”VHT-MCSs for optional 40 MHz, NSS = 3 VHT- Data rate (Mb/s) MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES Index 800 ns GI 400 ns GI 0 BPSK 1/2 1 108 6 324 162 1 40.5 45.0 1 QPSK 1/2 2 108 6 648 324 1 81.0 90.0 2 QPSK 3/4 2 108 6 648 486 1 121.5 135.0 3 16-QAM 1/2 4 108 6 1296 648 1 162.0 180.0 4 16-QAM 3/4 4 108 6 1296 972 1 243.0 270.0 5 64-QAM 2/3 6 108 6 1944 1296 1 324.0 360.0 6 64-QAM 3/4 6 108 6 1944 1458 1 364.5 405.0 7 64-QAM 5/6 6 108 6 1944 1620 1 405.0 450.0 8 256-QAM 3/4 8 108 6 2592 1944 1 486.0 540.0 9 256-QAM 5/6 8 108 6 2592 2160 1 540.0 600.0 2613 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-41â€”VHT-MCSs for optional 40 MHz, NSS = 4 VHT- Data rate (Mb/s) MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES Index 800 ns GI 400 ns GI 0 BPSK 1/2 1 108 6 432 216 1 54.0 60.0 1 QPSK 1/2 2 108 6 864 432 1 108.0 120.0 2 QPSK 3/4 2 108 6 864 648 1 162.0 180.0 3 16-QAM 1/2 4 108 6 1728 864 1 216.0 240.0 4 16-QAM 3/4 4 108 6 1728 1296 1 324.0 360.0 5 64-QAM 2/3 6 108 6 2592 1728 1 432.0 480.0 6 64-QAM 3/4 6 108 6 2592 1944 1 486.0 540.0 7 64-QAM 5/6 6 108 6 2592 2160 1 540.0 600.0 8 256-QAM 3/4 8 108 6 3456 2592 2 648.0 720.0 9 256-QAM 5/6 8 108 6 3456 2880 2 720.0 800.0 Table 21-42â€”VHT-MCSs for optional 40 MHz, NSS = 5 VHT- Data rate (Mb/s) MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES Index 800 ns GI 400 ns GI 0 BPSK 1/2 1 108 6 540 270 1 67.5 75.0 1 QPSK 1/2 2 108 6 1080 540 1 135.0 150.0 2 QPSK 3/4 2 108 6 1080 810 1 202.5 225.0 3 16-QAM 1/2 4 108 6 2160 1080 1 270.0 300.0 4 16-QAM 3/4 4 108 6 2160 1620 1 405.0 450.0 5 64-QAM 2/3 6 108 6 3240 2160 1 540.0 600.0 6 64-QAM 3/4 6 108 6 3240 2430 2 607.5 675.0 7 64-QAM 5/6 6 108 6 3240 2700 2 675.0 750.0 8 256-QAM 3/4 8 108 6 4320 3240 2 810.0 900.0 9 256-QAM 5/6 8 108 6 4320 3600 2 900.0 1000.0 2614 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-43â€”VHT-MCSs for optional 40 MHz, NSS = 6 VHT- Data rate (Mb/s) MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES Index 800 ns GI 400 ns GI 0 BPSK 1/2 1 108 6 648 324 1 81.0 90.0 1 QPSK 1/2 2 108 6 1296 648 1 162.0 180.0 2 QPSK 3/4 2 108 6 1296 972 1 243.0 270.0 3 16-QAM 1/2 4 108 6 2592 1296 1 324.0 360.0 4 16-QAM 3/4 4 108 6 2592 1944 1 486.0 540.0 5 64-QAM 2/3 6 108 6 3888 2592 2 648.0 720.0 6 64-QAM 3/4 6 108 6 3888 2916 2 729.0 810.0 7 64-QAM 5/6 6 108 6 3888 3240 2 810.0 900.0 8 256-QAM 3/4 8 108 6 5184 3888 2 972.0 1080.0 9 256-QAM 5/6 8 108 6 5184 4320 2 1080.0 1200.0 Table 21-44â€”VHT-MCSs for optional 40 MHz, NSS = 7 VHT- Data rate (Mb/s) MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES Index 800 ns GI 400 ns GI 0 BPSK 1/2 1 108 6 756 378 1 94.5 105.0 1 QPSK 1/2 2 108 6 1512 756 1 189.0 210.0 2 QPSK 3/4 2 108 6 1512 1134 1 283.5 315.0 3 16-QAM 1/2 4 108 6 3024 1512 1 378.0 420.0 4 16-QAM 3/4 4 108 6 3024 2268 2 567.0 630.0 5 64-QAM 2/3 6 108 6 4536 3024 2 756.0 840.0 6 64-QAM 3/4 6 108 6 4536 3402 2 850.5 945.0 7 64-QAM 5/6 6 108 6 4536 3780 2 945.0 1050.0 8 256-QAM 3/4 8 108 6 6048 4536 3 1134.0 1260.0 9 256-QAM 5/6 8 108 6 6048 5040 3 1260.0 1400.0 2615 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-45â€”VHT-MCSs for optional 40 MHz, NSS = 8 VHT- Data rate (Mb/s) MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES Index 800 ns GI 400 ns GI 0 BPSK 1/2 1 108 6 864 432 1 108.0 120.0 1 QPSK 1/2 2 108 6 1728 864 1 216.0 240.0 2 QPSK 3/4 2 108 6 1728 1296 1 324.0 360.0 3 16-QAM 1/2 4 108 6 3456 1728 1 432.0 480.0 4 16-QAM 3/4 4 108 6 3456 2592 2 648.0 720.0 5 64-QAM 2/3 6 108 6 5184 3456 2 864.0 960.0 6 64-QAM 3/4 6 108 6 5184 3888 2 972.0 1080.0 7 64-QAM 5/6 6 108 6 5184 4320 2 1080.0 1200.0 8 256-QAM 3/4 8 108 6 6912 5184 3 1296.0 1440.0 9 256-QAM 5/6 8 108 6 6912 5760 3 1440.0 1600.0 Table 21-46â€”VHT-MCSs for mandatory 80 MHz, NSS = 1 Data rate (Mb/s) VHT- NCBP MCS Modulation R NBPSCS NSD NSP NDBPS NES 400 ns GI Index S 800 ns GI (See NOTE) 0 BPSK 1/2 1 234 8 234 117 1 29.3 32.5 1 QPSK 1/2 2 234 8 468 234 1 58.5 65.0 2 QPSK 3/4 2 234 8 468 351 1 87.8 97.5 3 16-QAM 1/2 4 234 8 936 468 1 117.0 130.0 4 16-QAM 3/4 4 234 8 936 702 1 175.5 195.0 5 64-QAM 2/3 6 234 8 1404 936 1 234.0 260.0 6 64-QAM 3/4 6 234 8 1404 1053 1 263.3 292.5 7 64-QAM 5/6 6 234 8 1404 1170 1 292.5 325.0 8 256-QAM 3/4 8 234 8 1872 1404 1 351.0 390.0 9 256-QAM 5/6 8 234 8 1872 1560 1 390.0 433.3 NOTEâ€”Support of 400 ns GI is optional on transmit and receive. 2616 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-47â€”VHT-MCSs for optional 80 MHz, NSS = 2 VHT- Data rate (Mb/s) MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES Index 800 ns GI 400 ns GI 0 BPSK 1/2 1 234 8 468 234 1 58.5 65.0 1 QPSK 1/2 2 234 8 936 468 1 117.0 130.0 2 QPSK 3/4 2 234 8 936 702 1 175.5 195.0 3 16-QAM 1/2 4 234 8 1872 936 1 234.0 260.0 4 16-QAM 3/4 4 234 8 1872 1404 1 351.0 390.0 5 64-QAM 2/3 6 234 8 2808 1872 1 468.0 520.0 6 64-QAM 3/4 6 234 8 2808 2106 1 526.5 585.0 7 64-QAM 5/6 6 234 8 2808 2340 2 585.0 650.0 8 256-QAM 3/4 8 234 8 3744 2808 2 702.0 780.0 9 256-QAM 5/6 8 234 8 3744 3120 2 780.0 866.7 Table 21-48â€”VHT-MCSs for optional 80 MHz, NSS = 3 VHT- Data rate (Mb/s) MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES Index 800 ns GI 400 ns GI 0 BPSK 1/2 1 234 8 702 351 1 87.8 97.5 1 QPSK 1/2 2 234 8 1404 702 1 175.5 195.0 2 QPSK 3/4 2 234 8 1404 1053 1 263.3 292.5 3 16-QAM 1/2 4 234 8 2808 1404 1 351.0 390.0 4 16-QAM 3/4 4 234 8 2808 2106 1 526.5 585.0 5 64-QAM 2/3 6 234 8 4212 2808 2 702.0 780.0 6 Not valid 7 64-QAM 5/6 6 234 8 4212 3510 2 877.5 975.0 8 256-QAM 3/4 8 234 8 5616 4212 2 1053.0 1170.0 9 256-QAM 5/6 8 234 8 5616 4680 3 1170.0 1300.0 2617 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-49â€”VHT-MCSs for optional 80 MHz, NSS = 4 VHT- Data rate (Mb/s) MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES Index 800 ns GI 400 ns GI 0 BPSK 1/2 1 234 8 936 468 1 117.0 130.0 1 QPSK 1/2 2 234 8 1872 936 1 234.0 260.0 2 QPSK 3/4 2 234 8 1872 1404 1 351.0 390.0 3 16-QAM 1/2 4 234 8 3744 1872 1 468.0 520.0 4 16-QAM 3/4 4 234 8 3744 2808 2 702.0 780.0 5 64-QAM 2/3 6 234 8 5616 3744 2 936.0 1040.0 6 64-QAM 3/4 6 234 8 5616 4212 2 1053.0 1170.0 7 64-QAM 5/6 6 234 8 5616 4680 3 1170.0 1300.0 8 256-QAM 3/4 8 234 8 7488 5616 3 1404.0 1560.0 9 256-QAM 5/6 8 234 8 7488 6240 3 1560.0 1733.3 Table 21-50â€”VHT-MCSs for optional 80 MHz, NSS = 5 VHT- Data rate (Mb/s) MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES Index 800 ns GI 400 ns GI 0 BPSK 1/2 1 234 8 1170 585 1 146.3 162.5 1 QPSK 1/2 2 234 8 2340 1170 1 292.5 325.0 2 QPSK 3/4 2 234 8 2340 1755 1 438.8 487.5 3 16-QAM 1/2 4 234 8 4680 2340 2 585.0 650.0 4 16-QAM 3/4 4 234 8 4680 3510 2 877.5 975.0 5 64-QAM 2/3 6 234 8 7020 4680 3 1170.0 1300.0 6 64-QAM 3/4 6 234 8 7020 5265 3 1316.3 1462.5 7 64-QAM 5/6 6 234 8 7020 5850 3 1462.5 1625.0 8 256-QAM 3/4 8 234 8 9360 7020 4 1755.0 1950.0 9 256-QAM 5/6 8 234 8 9360 7800 4 1950.0 2166.7 2618 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-51â€”VHT-MCSs for optional 80 MHz, NSS = 6 VHT- Data rate (Mb/s) MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES Index 800 ns GI 400 ns GI 0 BPSK 1/2 1 234 8 1404 702 1 175.5 195.0 1 QPSK 1/2 2 234 8 2808 1404 1 351.0 390.0 2 QPSK 3/4 2 234 8 2808 2106 1 526.5 585.0 3 16-QAM 1/2 4 234 8 5616 2808 2 702.0 780.0 4 16-QAM 3/4 4 234 8 5616 4212 2 1053.0 1170.0 5 64-QAM 2/3 6 234 8 8424 5616 3 1404.0 1560.0 6 64-QAM 3/4 6 234 8 8424 6318 3 1579.5 1755.0 7 64-QAM 5/6 6 234 8 8424 7020 4 1755.0 1950.0 8 256-QAM 3/4 8 234 8 11 232 8424 4 2106.0 2340.0 9 Not valid Table 21-52â€”VHT-MCSs for optional 80 MHz, NSS = 7 VHT- Data rate (Mb/s) MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES Index 800 ns GI 400 ns GI 0 BPSK 1/2 1 234 8 1638 819 1 204.8 227.5 1 QPSK 1/2 2 234 8 3276 1638 1 409.5 455.0 2 QPSK 3/4 2 234 8 3276 2457 3 614.3 682.5 3 16-QAM 1/2 4 234 8 6552 3276 2 819.0 910.0 4 16-QAM 3/4 4 234 8 6552 4914 3 1228.5 1365.0 5 64-QAM 2/3 6 234 8 9828 6552 4 1638.0 1820.0 6 Not valid 7 64-QAM 5/6 6 234 8 9828 8190 6 2047.5 2275.0 8 256-QAM 3/4 8 234 8 13 104 9828 6 2457.0 2730.0 9 256-QAM 5/6 8 234 8 13 104 10 920 6 2730.0 3033.3 2619 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-53â€”VHT-MCSs for optional 80 MHz, NSS = 8 VHT- Data rate (Mb/s) MCS Modulation R NBPSCS NSD NSP NCBPS NDBPS NES Index 800 ns GI 400 ns GI 0 BPSK 1/2 1 234 8 1872 936 1 234.0 260.0 1 QPSK 1/2 2 234 8 3744 1872 1 468.0 520.0 2 QPSK 3/4 2 234 8 3744 2808 2 702.0 780.0 3 16-QAM 1/2 4 234 8 7488 3744 2 936.0 1040.0 4 16-QAM 3/4 4 234 8 7488 5616 3 1404.0 1560.0 5 64-QAM 2/3 6 234 8 11 232 7488 4 1872.0 2080.0 6 64-QAM 3/4 6 234 8 11 232 8424 4 2106.0 2340.0 7 64-QAM 5/6 6 234 8 11 232 9360 6 2340.0 2600.0 8 256-QAM 3/4 8 234 8 14 976 11 232 6 2808.0 3120.0 9 256-QAM 5/6 8 234 8 14 976 12 480 6 3120.0 3466.7 Table 21-54â€”VHT-MCSs for optional 160 MHz and 80+80 MHz, NSS = 1 VHT- Data rate (Mb/s) MCS Modulation R NBPSCS NSDâˆ™NSeg NSP NCBPS NDBPS NES Index 800 ns GI 400 ns GI 0 BPSK 1/2 1 468 16 468 234 1 58.5 65.0 1 QPSK 1/2 2 468 16 936 468 1 117.0 130.0 2 QPSK 3/4 2 468 16 936 702 1 175.5 195.0 3 16-QAM 1/2 4 468 16 1872 936 1 234.0 260.0 4 16-QAM 3/4 4 468 16 1872 1404 1 351.0 390.0 5 64-QAM 2/3 6 468 16 2808 1872 1 468.0 520.0 6 64-QAM 3/4 6 468 16 2808 2106 1 526.5 585.0 7 64-QAM 5/6 6 468 16 2808 2340 2 585.0 650.0 8 256-QAM 3/4 8 468 16 3744 2808 2 702.0 780.0 9 256-QAM 5/6 8 468 16 3744 3120 2 780.0 866.7 2620 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-55â€”VHT-MCSs for optional 160 MHz and 80+80 MHz, NSS = 2 VHT- Data rate (Mb/s) MCS Modulation R NBPSCS NSDâˆ™NSeg NSP NCBPS NDBPS NES Index 800 ns GI 400 ns GI 0 BPSK 1/2 1 468 16 936 468 1 117.0 130.0 1 QPSK 1/2 2 468 16 1872 936 1 234.0 260.0 2 QPSK 3/4 2 468 16 1872 1404 1 351.0 390.0 3 16-QAM 1/2 4 468 16 3744 1872 1 468.0 520.0 4 16-QAM 3/4 4 468 16 3744 2808 2 702.0 780.0 5 64-QAM 2/3 6 468 16 5616 3744 2 936.0 1040.0 6 64-QAM 3/4 6 468 16 5616 4212 2 1053.0 1170.0 7 64-QAM 5/6 6 468 16 5616 4680 3 1170.0 1300.0 8 256-QAM 3/4 8 468 16 7488 5616 3 1404.0 1560.0 9 256-QAM 5/6 8 468 16 7488 6240 3 1560.0 1733.3 Table 21-56â€”VHT-MCSs for optional 160 MHz and 80+80 MHz, NSS = 3 VHT- Data rate (Mb/s) MCS Modulation R NBPSCS NSDâˆ™NSeg NSP NCBPS NDBPS NES Index 800 ns GI 400 ns GI 0 BPSK 1/2 1 468 16 1404 702 1 175.5 195.0 1 QPSK 1/2 2 468 16 2808 1404 1 351.0 390.0 2 QPSK 3/4 2 468 16 2808 2106 1 526.5 585.0 3 16-QAM 1/2 4 468 16 5616 2808 2 702.0 780.0 4 16-QAM 3/4 4 468 16 5616 4212 2 1053.0 1170.0 5 64-QAM 2/3 6 468 16 8424 5616 3 1404.0 1560.0 6 64-QAM 3/4 6 468 16 8424 6318 3 1579.5 1755.0 7 64-QAM 5/6 6 468 16 8424 7020 4 1755.0 1950.0 8 256-QAM 3/4 8 468 16 11 232 8424 4 2106.0 2340.0 9 Not valid 2621 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-57â€”VHT-MCSs for optional 160 MHz and 80+80 MHz, NSS = 4 VHT- Data rate (Mb/s) MCS Modulation R NBPSCS NSDâˆ™NSeg NSP NCBPS NDBPS NES Index 800 ns GI 400 ns GI 0 BPSK 1/2 1 468 16 1872 936 1 234.0 260.0 1 QPSK 1/2 2 468 16 3744 1872 1 468.0 520.0 2 QPSK 3/4 2 468 16 3744 2808 2 702.0 780.0 3 16-QAM 1/2 4 468 16 7488 3744 2 936.0 1040.0 4 16-QAM 3/4 4 468 16 7488 5616 3 1404.0 1560.0 5 64-QAM 2/3 6 468 16 11 232 7488 4 1872.0 2080.0 6 64-QAM 3/4 6 468 16 11 232 8424 4 2106.0 2340.0 7 64-QAM 5/6 6 468 16 11 232 9360 6 2340.0 2600.0 8 256-QAM 3/4 8 468 16 14 976 11 232 6 2808.0 3120.0 9 256-QAM 5/6 8 468 16 14 976 12 480 6 3120.0 3466.7 Table 21-58â€”VHT-MCSs for optional 160 MHz and 80+80 MHz, NSS = 5 VHT- Data rate (Mb/s) MCS Modulation R NBPSCS NSDâˆ™NSeg NSP NCBPS NDBPS NES Index 800 ns GI 400 ns GI 0 BPSK 1/2 1 468 16 2340 1170 1 292.5 325.0 1 QPSK 1/2 2 468 16 4680 2340 2 585.0 650.0 2 QPSK 3/4 2 468 16 4680 3510 2 877.5 975.0 3 16-QAM 1/2 4 468 16 9360 4680 3 1170.0 1300.0 4 16-QAM 3/4 4 468 16 9360 7020 4 1755.0 1950.0 5 64-QAM 2/3 6 468 16 14 040 9360 5 2340.0 2600.0 6 64-QAM 3/4 6 468 16 14 040 10 530 5 2632.5 2925.0 7 64-QAM 5/6 6 468 16 14 040 11 700 6 2925.0 3250.0 8 256-QAM 3/4 8 468 16 18 720 14 040 8 3510.0 3900.0 9 256-QAM 5/6 8 468 16 18 720 15 600 8 3900.0 4333.3 2622 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-59â€”VHT-MCSs for optional 160 MHz and 80+80 MHz, NSS = 6 VHT- Data rate (Mb/s) MCS Modulation R NBPSCS NSDâˆ™NSeg NSP NCBPS NDBPS NES Index 800 ns GI 400 ns GI 0 BPSK 1/2 1 468 16 2808 1404 1 351.0 390.0 1 QPSK 1/2 2 468 16 5616 2808 2 702.0 780.0 2 QPSK 3/4 2 468 16 5616 4212 2 1053.0 1170.0 3 16-QAM 1/2 4 468 16 11 232 5616 3 1404.0 1560.0 4 16-QAM 3/4 4 468 16 11 232 8424 4 2106.0 2340.0 5 64-QAM 2/3 6 468 16 16 848 11 232 6 2808.0 3120.0 6 64-QAM 3/4 6 468 16 16 848 12 636 6 3159.0 3510.0 7 64-QAM 5/6 6 468 16 16 848 14 040 8 3510.0 3900.0 8 256-QAM 3/4 8 468 16 22 464 16 848 8 4212.0 4680.0 9 256-QAM 5/6 8 468 16 22 464 18 720 9 4680.0 5200.0 Table 21-60â€”VHT-MCSs for optional 160 MHz and 80+80 MHz, NSS = 7 VHT- Data rate (Mb/s) MCS Modulation R NBPSCS NSDâˆ™NSeg NSP NCBPS NDBPS NES Index 800 ns GI 400 ns GI 0 BPSK 1/2 1 468 16 3276 1638 1 409.5 455.0 1 QPSK 1/2 2 468 16 6552 3276 2 819.0 910.0 2 QPSK 3/4 2 468 16 6552 4914 3 1228.5 1365.0 3 16-QAM 1/2 4 468 16 13 104 6552 4 1638.0 1820.0 4 16-QAM 3/4 4 468 16 13 104 9828 6 2457.0 2730.0 5 64-QAM 2/3 6 468 16 19 656 13 104 7 3276.0 3640.0 6 64-QAM 3/4 6 468 16 19 656 14 742 7 3685.5 4095.0 7 64-QAM 5/6 6 468 16 19 656 16 380 9 4095.0 4550.0 8 256-QAM 3/4 8 468 16 26 208 19 656 12 4914.0 5460.0 9 256-QAM 5/6 8 468 16 26 208 21 840 12 5460.0 6066.7 2623 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 21-61â€”VHT-MCSs for optional 160 MHz and 80+80 MHz, NSS = 8 VHT- Data rate (Mb/s) MCS Modulation R NBPSCS NSDâˆ™NSeg NSP NCBPS NDBPS NES Index 800 ns GI 400 ns GI 0 BPSK 1/2 1 468 16 3744 1872 1 468.0 520.0 1 QPSK 1/2 2 468 16 7488 3744 2 936.0 1040.0 2 QPSK 3/4 2 468 16 7488 5616 3 1404.0 1560.0 3 16-QAM 1/2 4 468 16 14 976 7488 4 1872.0 2080.0 4 16-QAM 3/4 4 468 16 14 976 11 232 6 2808.0 3120.0 5 64-QAM 2/3 6 468 16 22 464 14 976 8 3744.0 4160.0 6 64-QAM 3/4 6 468 16 22 464 16 848 8 4212.0 4680.0 7 64-QAM 5/6 6 468 16 22 464 18 720 9 4680.0 5200.0 8 256-QAM 3/4 8 468 16 29 952 22 464 12 5616.0 6240.0 9 256-QAM 5/6 8 468 16 29 952 24 960 12 6240.0 6933.3 2624 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 22. Television very high throughput (TVHT) PHY specification 22.1 Introduction 22.1.1 Introduction to the TVHT PHY Clause 22 specifies the PHY entity for a television very high throughput (TVHT) orthogonal frequency division multiplexing (OFDM) system. Three basic channel units (BCUs) are defined as 6 MHz, 7 MHz, or 8 MHz, depending on the regulatory domain, and denoted in the rest of this clause as a BCU or TVHT_W. Many of the terms used in this clause refer to different bands, depending on the regulatory domain. These terms include â€” TVHT_2W, which represents two contiguous BCUs (12 MHz, 14 MHz, or 16 MHz) â€” TVHT_W+W, which represents two noncontiguous BCU (6+6 MHz, 7+7 MHz, or 8+8 MHz) â€” TVHT_4W, which represents four contiguous BCUs (24 MHz, 28 MHz, or 32 MHz) â€” TVHT_2W+2W, which represents two noncontiguous frequency segments, each of which is com- posed of two BCUs (12+12 MHz, 14+14 MHz, or 16+16 MHz) The TVHT PHY is based on the VHT PHY as defined in 21.3, 21.4, 21.5, and on Clause 17. All TVHT transmissions in one BCU shall use the VHT PHY parameters for 40 MHz channel defined in 21.3, 21.4, and 21.5 with a sampling clock change to fit into each of the BCU bandwidths and with the number of encoders (NES) always being 1 (for SU-MIMO and per user in MU-MIMO). Table 22-8 describes the sampling clock for each of the BCUs and the basic PHY parameters for transmission over one BCU. For all VHT PPDUs and non-HT PPDUs in TVWS band, timing-related parameters shall be used as defined in Table 22-5 and Table 22-8; frequently used parameters shall be used as defined in Table 22-6 and Table 22-9; phase rotation parameter k BW shall be replaced by k M , which is defined in Table 22-12; and cyclic shift parameters shall be used as defined in 22.3.8.3.2. As shown in Table 22-8, the design is based on defining 144 OFDM tones in the 6 MHz and 8 MHz channel units and using up to tone 58 on each side of the DC tone for data and pilots, exactly matching the VHT 40 MHz PHY parameters. The 7 MHz channel unit is split into 168 tones to maintain the same tone spacing and PHY design as used for 6 MHz channels (note the ratio of 168 to 144 is identical to the ratio of 7 to 6). The choice of 144 and not 128 was made to reduce the PHY channel BW from 6 MHz to 5 1/3 MHz in order to allow sharper filtering to achieve 55 dB ACLR. The TVHT PHY defines the following transmission modes that incorporate transmission on one, two, or four BCUs: a) Mandatory transmission mode - one BCU (TVHT_MODE_1) b) Optional transmission modes - multi-BCUs 1) Two contiguous BCUs (TVHT_MODE_2C) 2) Two noncontiguous BCUs (TVHT_MODE_2N) 3) Four contiguous BCUs (TVHT_MODE_4C) 4) Two noncontiguous frequency segments, each of which comprises two contiguous BCUs (TVHT_MODE_4N) 2625 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The tone spacing, DFT duration, and other timing parameters remain unchanged for all optional modes compared with the definition in Table 22-8. The number of occupied tones in each BCU of any optional mode is the same as the number defined in Table 22-8. The location of the occupied tones in each BCU of any optional mode is shown in Table 22-9. The DATA encoding process for multi-BCUs transmission is similar to one BCU transmission and is defined in 22.3.10. A TVHT STA shall support the following features: â€” TVHT_MODE_1 (one BCU) â€” Single spatial stream MCSs 0 to 7 (transmit and receive) â€” Binary convolutional coding â€” Normal and short guard interval (transmit and receive) A TVHT STA may support the following features: â€” TVHT_MODE_2C, TVHT_MODE_2N, TVHT_MODE_4C, or TVHT_MODE_4N (two or four BCUs) â€” Two or more spatial streams (transmit and receive) â€” Beamforming sounding (by sending a VHT NDP frame) â€” Respond to transmit beamforming sounding (provide compressed beamforming feedback) â€” STBC (transmit and receive) â€” LDPC (transmit and receive) â€” VHT MU PPDUs (transmit and receive) â€” MCSs 8 and 9 (transmit and receive) 22.1.2 Scope The services provided to the MAC by the TVHT PHY consist of a protocol function that defines the characteristics and method of transmitting and receiving data through a wireless medium between two or more STAs. These STAs support a TVHT PHY. 22.1.3 TVHT PHY functions 22.1.3.1 General See 21.1.3.1 with â€œTVHTâ€ replacing â€œVHTâ€. 22.1.3.2 PHY management entity (PLME) See 21.1.3.2. 22.1.3.3 Service specification method See 21.1.3.3 with â€œTVHTâ€ replacing â€œVHTâ€. 2626 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 22.1.4 PPDU formats The structure of the PPDU transmitted by a TVHT STA is determined by the TXVECTOR parameters as defined in 22.2.2. The FORMAT parameter determines the overall structure of the PPDU and includes the following: â€” Non-HT format (NON_HT), based on Clause 17. Support for non-HT format is mandatory. â€” VHT format (VHT). Support for TVHT_W VHT format is mandatory. 22.2 TVHT PHY service interface 22.2.1 Introduction See 21.2.1. 22.2.2 TXVECTOR and RXVECTOR parameters The TXVECTOR and RXVECTOR parameters are defined in Table 22-1. The TXVECTOR parameter FORMAT shall be set to NON_HT or VHT. When the TXVECTOR parameter FORMAT equals NON_HT, then NON_HT_MODULATION shall be set to NON_HT_DUP_OFDM. When the TXVECTOR parameter FORMAT equals NON_HT, the TXVECTOR parameter L_DATARATE indicates the data rate used to transmit the PSDU in Mb/s. The allowed values are 6 Mb/s, 9 Mb/s, 12 Mb/s, 18 Mb/s, 24 Mb/s, 36 Mb/s, 48 Mb/s, and 54 Mb/s divided by 7.5 for 6 MHz and 7 MHz unit channels and by 5.625 for 8 MHz channels. When the TXVECTOR parameter FORMAT equals VHT, the TXVECTOR parameter CH_BANDWIDTH indicates the channel width of the transmitted PPDU: Enumerated type: â€” TVHT_W for one BCU â€” TVHT_2W for two contiguous BCUs â€” TVHT_W+W for two noncontiguous BCUs â€” TVHT_4W for four contiguous BCUs â€” TVHT_2W+2W for two noncontiguous frequency segments, each of which comprises two contiguous BCUs Note that TVHT_W represents the broadcast channel bandwidth for the regulatory domain, e.g., TVHT_W is 6 MHz, 7 MHz, or 8 MHz. TVHT_2W represents two contiguous BCUs with the same regulatory domain, e.g., TVHT_2W is 12 MHz, 14 MHz, or 16 MHz. When the TXVECTOR parameter FORMAT equals NON_HT, the TXVECTOR parameter CH_BANDWIDTH indicates the channel width of the transmitted PPDU on transmission and the estimated channel width of the received PPDU on reception: Enumerated type: â€” TVHT_W, TVHT_2W, TVHT_W+W, TVHT_4W, TVHT_2W+2W When the TXVECTOR parameter FORMAT equals VHT, the TXVECTOR parameter NUM_STS indicates the number of space-time streams: range 1 to 4 for SU, 1 to 3 per user for MU. NUM_STS summed over all 2627 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications users shall be less than or equal to 4. The TXVECTOR parameter NUM_STS is not present when the TXVECTOR parameter FORMAT equals to NON_HT. Table 22-1â€”TXVECTOR and RXVECTOR parameters RXVECTOR TXVECTOR Parameter Condition Value Determines the format of the PPDU. Y Y Enumerated type: FORMAT NON_HT indicates non-HT duplicated PPDU format. In this case, the modulation is determined by the NON_HT_MODULATION parameter. VHT indicates VHT format. FORMAT is NON_HT In TXVECTOR, indicates the format type of the transmitted non- Y Y NON_HT_MODULATION HT PPDU. In RXVECTOR, indicates the estimated format type of the received non-HT PPDU. Enumerated type: NON_HT_DUP_OFDM indicates non-HT duplicate format. Otherwise Not present N N FORMAT is NON_HT Indicates the length of the PSDU in octets in the range 1 to 4095. Y Y This value is used by the PHY to determine the number of octet L_LENGTH transfers that occur between the MAC and the PHY. FORMAT is VHT Not present N N NOTEâ€”The Length field of the L-SIG in VHT PPDUs is defined in Equation (22-9) using the scaling factor defined in 22.3.8.2.1. FORMAT is NON_HT Indicates the data rate used to transmit the PSDU in Mb/s. The Y Y allowed values are 6, 9, 12, 18, 24, 36, 48, and 54 divided by 7.5 for L_DATARATE 6 MHz and 7 MHz unit channels and by 5.625 for 8 MHz channels. FORMAT is VHT Not present N N NOTEâ€”The RATE field in the L-SIG field in a VHT PPDU is set to the value representing 6/X Mb/s in TVWS band â€œModulation BPSK and Coding rate 1/2â€ row of Table 22-4. FORMAT is VHT Indicates the number of transmit chains. Y N N_TX Otherwise Not present N N FORMAT is VHT and Set to COMPRESSED_SV Y N EXPANSION_MAT_TYPE EXPANSION_MAT is present. Otherwise See corresponding entry in Table 19-1 2628 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 22-1â€”TXVECTOR and RXVECTOR parameters (continued) RXVECTOR TXVECTOR Parameter Condition Value FORMAT is VHT Contains a vector in the number of selected subcarriers containing M N EXPANSION_MAT feedback matrices as defined in 22.3.11.2 based on the channel U measured during the training symbols of a previous VHT NDP PPDU. Otherwise See corresponding entry in Table 19-1 FORMAT is VHT and Set to COMPRESSED_SV N Y CHAN_MAT_TYPE PSDU_LENGTH NOTEâ€”This parameter is present only for TVHT NDP PPDUs. equals zero FORMAT is VHT and Not present N N PSDU_LENGTH is greater than zero Otherwise See corresponding entry in Table 19-1 FORMAT is VHT and Contains a set of compressed beamforming feedback matrices as N Y PSDU_LENGTH defined in 21.3.11.2 based on the channel measured during the CHAN_MAT equals zero training symbols of the received VHT NDP PPDU. FORMAT is VHT and Not present N N PSDU_LENGTH is greater than zero Otherwise See corresponding entry in Table 19-1 FORMAT is VHT Contains an array of delta SNR values as defined in 9.4.1.52 based M Y on the channel measured during the training symbols of the U DELTA_SNR received VHT NDP PPDU. NOTEâ€”In the RXVECTOR this parameter is present only for VHT NDP PPDUs for MU sounding. Otherwise Not present N N Is a measure of the received RF power averaged over all of the N Y RCPI receive chains in the Data field of a received PPDU. Refer to 19.3.19.6 for the definition of RCPI. FORMAT is VHT Contains an array of measures of the received SNR for each spatial N Y stream. SNR indications of 8 bits are supported. SNR shall be the sum of the decibel values of SNR per tone divided by the number of SNR tones represented in each stream as described in 9.4.1.50. Otherwise See corresponding entry in Table 19-1 FORMAT is VHT Not present N N NO_SIG_EXTN Otherwise See corresponding entry in Table 19-1 2629 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 22-1â€”TXVECTOR and RXVECTOR parameters (continued) RXVECTOR TXVECTOR Parameter Condition Value FORMAT is HT Indicates which FEC encoding is used. M Y FEC_CODING Enumerated type: U BCC_CODING indicates binary convolutional code. LDPC_CODING indicates low-density parity check code. Otherwise See corresponding entry in Table 19-1 FORMAT is VHT Indicates whether STBC is used. Y Y 0 indicates no STBC (NSTS=NSS in the Data field). STBC 1 indicates STBC is used (NSTS=2NSS in the Data field). Otherwise See corresponding entry in Table 19-1 FORMAT is VHT Indicates whether a short guard interval is used in the transmission Y Y of the Data field of the PPDU. Enumerated type: GI_TYPE LONG_GI indicates short GI is not used in the Data field of the PPDU. SHORT_GI indicates short GI is used in the Data field of the PPDU. Otherwise Not present N N FORMAT is VHT The allowed values for the TXPWR_LEVEL_INDEX parameter Y N TXPWR_LEVEL_INDEX are in the range 1 to numberOfOctets(dot11TxPowerLevelExtended)/2. This parameter is used to indicate which of the available transmit output power levels defined in dot11TxPowerLevelExtended shall be used for the current transmission. Otherwise See corresponding entry in Table 19-1 FORMAT is VHT The allowed values for the RSSI parameter are in the range 0 to N Y 255. This parameter is a measure by the PHY of the power observed at the antennas used to receive the current PPDU measured during RSSI the reception of the TVHT-LTF field. RSSI is intended to be used in a relative manner, and it is a monotonically increasing function of the received power. Otherwise See corresponding entry in Table 19-1 FORMAT is VHT Indicates the modulation and coding scheme used in the M Y transmission of the PPDU. U MCS Integer: range 0 to 9 Otherwise See corresponding entry in Table 19-1 FORMAT is VHT Indicates the MCS that the STAâ€™s receiver recommends. N O REC_MCS Otherwise Not present N N 2630 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 22-1â€”TXVECTOR and RXVECTOR parameters (continued) RXVECTOR TXVECTOR Parameter Condition Value FORMAT is VHT Indicates the channel width of the transmitted PPDU: Y Y Enumerated type: TVHT_W for one BCU TVHT_2W for two contiguous BCUs TVHT_W+W for two noncontiguous BCUs CH_BANDWIDTH TVHT_4W for four contiguous BCUs TVHT_2W+2W for two noncontiguous frequency segments, each of which comprises two contiguous BCUs FORMAT is NON_HT In TXVECTOR, indicates the channel width of the transmitted Y Y PPDU. In RXVECTOR, indicates the estimated channel width of the received PPDU. Enumerated type: TVHT_W, TVHT_2W, TVHT_W+W, TVHT_4W, TVHT_2W+2W if NON_HT_MODULATION equals NON_HT_DUP_OFDM FORMAT is NON_HT In TXVECTOR, if present, indicates whether the transmitter is O Y DYN_BANDWIDTH_IN_NON_HT capable of Static or Dynamic bandwidth operation. In RXVECTOR, if valid, indicates whether the transmitter is capable of Static or Dynamic bandwidth operation. Enumerated type: Static if the transmitter is capable of Static bandwidth operation Dynamic if the transmitter is capable of Dynamic bandwidth operation NOTEâ€”In the RXVECTOR, the validity of this parameter is determined by the MAC based on the contents of the received MPDU. Otherwise Not present N N FORMAT is NON_HT In TXVECTOR, if present, indicates the channel width of the O Y CH_BANDWIDTH_IN_NON_HT transmitted PPDU, which is signaled via the scrambling sequence. In RXVECTOR, if valid, indicates the channel width of the received PPDU, which is signaled via the scrambling sequence. Enumerated type: TVHT_W, TVHT_2W, TVHT_W+W, TVHT_4W, TVHT_2W+2W. NOTEâ€”In the RXVECTOR, the validity of this parameter is determined by the MAC based on the contents of the received MPDU. Otherwise Not present N N FORMAT is VHT If equal to 0, indicates a TVHT NDP PPDU for both RXVECTOR M O and TXVECTOR. U APEP_LENGTH If greater than zero, in the TXVECTOR, indicates the number of octets in the range 1 to 1 048 575 in the A-MPDU pre-EOF padding (see 10.13.2) carried in the PSDU. If greater than zero, in the RXVECTOR, is the value obtained from the VHT-SIG-B Length field multiplied by 4. Otherwise Not present N N 2631 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 22-1â€”TXVECTOR and RXVECTOR parameters (continued) RXVECTOR TXVECTOR Parameter Condition Value FORMAT is VHT Indicates the number of octets in the VHT PSDU in the range 0 to N Y PSDU_LENGTH 1 065 600 octets. A value of 0 indicates a VHT NDP PPDU. Otherwise Not present N N FORMAT is VHT and Index for user in MU transmission. Integer: range 0 to 3. M O USER_POSITION 1 â‰¤ GROUP_ID â‰¤ 62 NOTEâ€”The entries in the USER_POSITION array are in U ascending order. Otherwise Not present N N FORMAT is VHT Indicates the number of space-time streams. M Y NUM_STS Integer: range 1 to 4 for SU, 1 to 3 per user in the TXVECTOR, and U 0 to 4 in the RXVECTOR for MU. NUM_STS summed over all users is between 1 and 4. Otherwise Not present N N FORMAT is VHT Indicates the group ID. Y Y GROUP_ID Integer: range 0 to 63 (see Table 22-12) A value of 0 or 63 indicates a VHT SU PPDU. A value in the range 1 to 62 indicates a VHT MU PPDU. Otherwise Not present N N FORMAT is VHT and Provides an abbreviated indication of the intended recipient(s) of Y Y PARTIAL_AID GROUP_ID is 0 or 63 the PSDU (see 9.1710.20). Integer: range 0 to 511. Otherwise Not present N N FORMAT is VHT Indicates the number of users with nonzero space-time streams. Y N NUM_USERS Integer: range 1 to 4. Otherwise Not present N N FORMAT is VHT and Set to 1 if a beamforming steering matrix is applied to the Y O BEAMFORMED GROUP_ID is 0 or 63 waveform in an SU transmission. Set to 0 otherwise. NOTEâ€”When BEAMFORMED is set to 1, smoothing is not recommended. Otherwise Not present N N 2632 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 22-1â€”TXVECTOR and RXVECTOR parameters (continued) RXVECTOR TXVECTOR Parameter Condition Value FORMAT is VHT Indicates whether a TVHT AP allows non-AP TVHT STAs in Y Y TXOP_PS_NOT_ALLOWED TXOP power save mode to enter doze state during the TXOP. 0 indicates that the TVHT AP allows non-AP TVHT STAs to enter doze state during a TXOP. 1 indicates that the TVHT AP does not allow non-AP TVHT STAs to enter doze state during a TXOP. Otherwise Not present N N Boolean value: O N TIME_OF_DEPARTURE_REQUESTED true indicates that the MAC entity requests that the PHY entity measures and reports time of departure parameters corresponding to the time when the first PPDU energy is sent by the transmitting port. false indicates that the MAC entity requests that the PHY entity neither measures nor reports time of departure parameters. dot11TimingMsmtActi 0 to 232â€“ 1. An estimate of the offset (in 10 ns units) from the point N Y RX_START_OF_FRAME_OFFSET vated is true in time at which the start of the preamble corresponding to the incoming frame arrived at the receive antenna connector to the point in time at which this primitive is issued to the MAC. Otherwise Not present N N NOTE 1â€”In the â€œTXVECTORâ€ and â€œRXVECTORâ€ columns, the following apply: Y = Present; N = Not present; O = Optional; MU indicates that the parameter is present once for a VHT SU PPDU and present per user for a VHT MU PPDU. Parameters specified to be present per user are conceptually supplied as an array of values indexed by u, where u takes values 0 to NUM_USERS â€“ 1. NOTE 2â€”On reception, where valid, the CH_BANDWIDTH_IN_NON_HT parameter is likely to be a more reliable indication of subformat and channel width than the NON_HT_MODULATION and CH_BANDWIDTH parameters, since for non-HT or non-HT duplicate frames, CH_BANDWIDTH is a receiver estimate of the bandwidth, whereas CH_BANDWIDTH_IN_NON_HT is the signaled bandwidth. 2633 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 22.2.3 Effects of CH_BANDWIDTH parameter on PPDU format Table 22-2 shows the PPDU format as a function of the CH_BANDWIDTH and FORMAT parameters. Table 22-2â€”PPDU format as a function of CH_BANDWIDTH parameter FORMAT CH_BANDWIDTH PPDU format VHT TVHT_W The STA transmits a VHT PPDU in TVWS bands (when FORMAT is VHT) with TVHT_MODE_1. VHT TVHT_2W The STA transmits a VHT PPDU in TVWS bands (when FORMAT is VHT) with TVHT_MODE_2C. VHT TVHT_4W The STA transmits a VHT PPDU in TVWS bands (when FORMAT is VHT) with TVHT_MODE_4C. VHT TVHT_W+W The STA transmits a VHT PPDU in TVWS bands (when FORMAT is VHT) with TVHT_MODE_2N. VHT TVHT_2W+2W The STA transmits a VHT PPDU in TVWS bands (when FORMAT is VHT) with TVHT_MODE_4N. NON_HT TVHT_W The STA transmits a NON_HT PPDU with NON_HT_MODULATION set to NON_HT_DUP_OFDM using one TVHT_W channel as defined in 22.3.10.12. If the BSS bandwidth is wider than TVHT_W, then the transmission shall use the primary TVHT_W channel. NON_HT TVHT_2W The STA transmits a NON_HT PPDU with NON_HT_MODULATION set to NON_HT_DUP_OFDM using two adjacent TVHT_W channels as defined in 22.3.10.12. If the BSS bandwidth is wider than TVHT_2W, then the transmission shall use the primary TVHT_2W channel. NON_HT TVHT_4W The STA transmits a NON_HT PPDU with NON_HT_MODULATION set to NON_HT_DUP_OFDM using four adjacent TVHT_W channels as defined in 22.3.10.12. NON_HT TVHT_W+W The STA transmits a NON_HT PPDU with NON_HT_MODULATION set to NON_HT_DUP_OFDM using two nonadjacent frequency segments, with each frequency segment consisting of single TVHT_W channels as defined in 22.3.10.12. NON_HT TVHT_2W+2W The STA transmits a NON_HT PPDU with NON_HT_MODULATION set to NON_HT_DUP_OFDM using two nonadjacent frequency segments, with each frequency segment consisting of two adjacent TVHT_W channels as defined in 22.3.10.12. 22.2.4 Support for NON_HT and HT formats Transmission of HT PPDUs is not supported in Clause 22. Except for Non-HT duplicate transmission defined in 22.3.10.12, transmission of NON_HT is not supported in Clause 22. Non-HT duplicate transmission is based on Clause 17, unless otherwise stated in Clause 22. Non-HT PPDU format is same as in Figure 17-1. Overview of the PPDU encoding process is defined in 17.3.2.2 except for following modifications: 2634 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Modulation-dependent parameters for Non-HT duplicate mode in TVWS band is defined in Table 22-3. Timing related parameters are defined in Table 22-5. tSIGNAL in Equation (17-2) is equal to 16 multiplied by X Âµs, and tDATA in Equation (17-2) is equal to 20 multiplied by X Âµs where X is 7.5 for 6 MHz and 7 MHz unit channels and X is 5.625 for 8 MHz channels. Table 22-3â€”Modulation-dependent parameters for Non-HT duplicate mode in TVWS band Coded Data Coded Data rate Coding bits per bits per bits per (Mb/s) Modulation rate OFDM OFDM subcarrier (TVWS (R) symbol symbol (NBPSC) band) (NCBPS) (NDBPS) BPSK 1/2 1 48 24 6/X (see NOTE) BPSK 3/4 1 48 36 9/X (see NOTE) QPSK 1/2 2 96 48 12/X (see NOTE) QPSK 3/4 2 96 72 18/X (see NOTE) 16-QAM 1/2 4 192 96 24/X (see NOTE) 16-QAM 3/4 4 192 144 36/X (see NOTE) 64-QAM 2/3 6 288 192 48/X (see NOTE) 64-QAM 3/4 6 288 216 54/X (see NOTE) NOTEâ€”In TVWS band, X depends on regulatory domain, i.e., 7.5 for 6 MHz and 7 MHz unit channels and 5.625 for 8 MHz channels. The timings for preamble are multiplied by X where X is 7.5 for 6 MHz and 7 MHz unit channels and X is 5.625 for 8 MHz channels. Constructions of L-STF, L-LTF, and L-SIG are same as in 22.3.4.2, 22.3.4.3, and 22.3.4.4 except for the value field parameters in L-SIG. Interpretation of the bits R1-R4 in the SIGNAL field is modified as in Table 22-4. Table 22-4â€”RATE field in L-SIG R1-R4 Modulation Coding rate 1101 BPSK 1/2 1111 BPSK 3/4 0101 QPSK 1/2 0111 QPSK 3/4 1001 16-QAM 1/2 1011 16-QAM 3/4 0001 64-QAM 2/3 0011 64-QAM 3/4 2635 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 22-5 and Table 22-6 define the timing-related parameters for Non-HT format and location of occupied tones. Table 22-5â€”Timing-related constants in Non-HT PPDU Parameter 6 MHz 7 MHz 8 MHz Description NSD 96 96 96 Number of complex data numbers per BCU NSP 8 8 8 Number of pilot values per BCU NST 104 104 104 Total number of subcarriers per BCU NSR 58 58 58 Highest data subcarrier index per BCU 6 MHz 2 7 MHz 2 8 MHz 5 âˆ†F ----------------- = 41 --- kHz ----------------- = 41 --- kHz ----------------- = 55 --- kHz Subcarrier frequency spacing 144 3 168 3 144 9 TDFT 24 Âµs 24 Âµs 18 Âµs IDFT/DFT period TGI 6 Âµs = TDFT /4 6 Âµs = TDFT /4 4.5 Âµs = TDFT /4 Guard interval duration TGIS 3 Âµs = TDFT /8 3 Âµs = TDFT /8 2.25 Âµs = TDFT /8 Short guard interval duration Other timing parameters are derived as in Table 17-5 using the definition of TFFT in Table 22-5. Table 22-6 defines the number of occupied tones and their location in all transmission modes. Zero denotes the DC tone of any contiguous segment. Refer to Table 21-6 for parameters definition. The definitions in the table are applicable to Clause 22 with the exception that in each transmission mode in Clause 22 NCBPSSI = NCBPSS for SU and MU PPDUs. 22.3 TVHT PHY sublayer 22.3.1 Introduction See 21.3.1. 22.3.2 VHT PPDU format in TVWS bands A single PPDU format is defined for this PHY: the VHT PPDU format in TVWS bands. Figure 22-1 shows the VHT PPDU format in TVWS bands, with the timing parameters (8 Âµs and 4 Âµs) in Figure 21-4 replaced by numbers from Table 22-8. 60 Î¼s 60 Î¼s 30 Î¼s 60 Î¼s 30 Î¼s 30 Î¼s pe r TVHT-LTF symbo l 30 Î¼s for 6 and 7 MHz ch annels 45 Î¼s 45 Î¼s 22.5 Î¼s 45 Î¼s 22.5 Î¼s 22.5 Î¼s pe r TVHT-LTF symbo l 22.5 Î¼s for 8 MHz ch annels TVHT TVHT- L-STF L-LTF L-SIG TVHT-SIG-A TVHT-LTF Data -STF SIG-B Figure 22-1â€”VHT PPDU format in TVWS bands The fields of the VHT PPDU format in TVWS bands are summarized in Table 22-7. 2636 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 22-6â€”Tone location in Non-HT PPDU TVHT_ TVHT_ TVHT_ TVHT_ TVHT_ Parameter Description MODE_1 MODE_2C MODE_2N MODE_4C MODE_4N NST 104 104 104 104 104 Total number of occupied subcarriers per BCU NTT 104 208 208 416 416 Total number of occupied subcarriers across all BCUs Subcarrier â€“58 to â€“33, â€“130 to â€“105, â€“58 to â€“33, â€“274 to â€“249, â€“130 to â€“105, Location of index â€“31 to â€“6, â€“103 to â€“78, â€“31 to â€“6, â€“247 to â€“222, â€“103 to â€“78, occupied +6 to +31, â€“66 to â€“41, +6 to +31, â€“210 to â€“185, â€“66 to â€“41, subcarriers for and +33 to â€“39 to â€“14, and +33 to â€“183 to â€“158, â€“39 to â€“14, 6 MHz and 8 MHz +58 +14 to +39, +58 for each â€“130 to â€“105, +14 to +39, channel units +41 to +66, BCU â€“103 to â€“78, +41 to +66, +78 to +103, â€“66 to â€“41, +78 to +103, and +105 to â€“39 to â€“14, and +105 to +130 +14 to +39, +130 for each +41 to +66, BCU +78 to +103, +105 to +130, +158 to +183, +185 to +210, +222 to +247, and +249 to +274 Subcarrier â€“58 to â€“33, â€“142 to â€“117, â€“58 to â€“33, â€“310 to â€“285, â€“142 to Location of index â€“31 to â€“6, â€“115 to â€“90, â€“31 to â€“6, â€“283 to â€“258, â€“117, â€“115 to occupied +6 to +31, â€“78 to â€“53, +6 to +31, â€“246 to â€“221, â€“90, â€“78 to subcarriers for and +33 to â€“51 to â€“26, and +33 to â€“219 to â€“194, â€“53, â€“51 to 7 MHz +58 +26 to +51, +58 for each â€“142 to â€“117, â€“26, +26 to +53 to +78, BCU â€“115 to â€“90, +51, +53 to +90 to +115, â€“78 to â€“53, +78, +90 to and +117 to â€“51 to â€“26, +115, and +142 +26 to +51, +117 to +142 +53 to +78, for each BCU +90 to +115, +117 to +142, +194 to +219, +221 to +246, +258 to +283, and +285 to +310 The TVHT-SIG-A, TVHT-STF, TVHT-LTF, and TVHT-SIG-B fields exist only in VHT PPDU in TVWS bands. In a TVHT NDP, the Data field is not present. The number of symbols in the TVHT-LTF field, NTVHTLTF, can be 1, 2, or 4 and is determined by the total number of space-time streams across all users being transmitted in the VHT PPDU in TVWS bands (see Table 21-13). 22.3.3 Transmitter block diagram The transmit process for the L-SIG and TVHT-SIG-A fields of a VHT PPDU using one BCU is shown in Figure 21-5, with â€œTVHTâ€ replacing â€œVHTâ€ and with bandwidth corrected according to TVHT bandwidth. 2637 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 22-7â€”Fields of the VHT PPDU in TVWS bands Field Description L-STF Non-HT Short Training field L-LTF Non-HT Long Training field L-SIG Non-HT SIGNAL field TVHT-SIG-A TVHT Signal A field TVHT-STF TVHT Short Training field TVHT-LTF TVHT Long Training field TVHT-SIG-B TVHT Signal B field Data The Data field includes the PSDU The transmit process for generating the TVHT-SIG-B field of a VHT SU PPDU and VHT MU PPDU using one frequency segment is shown in Figure 21-5 and Figure 21-7, respectively, with â€œTVHTâ€ replacing â€œVHTâ€ and with bandwidth corrected according to TVHT bandwidth. The transmit process for generating the Data field of a SU PPDU in TVHT_MODE_1, TVHT_MODE_2C, or TVHT_MODE_4C with BCC and LDPC encodings, using one BCU, is shown Figure 21-10 and Figure 21-11, respectively, with â€œTVHTâ€ replacing â€œVHTâ€ and with bandwidth corrected according to TVHT bandwidth. Single BCC encoder shall be assumed in Figure 21-10. The transmit process for generating the Data field of a MU PPDU in TVHT_MODE_1, TVHT_MODE_2C, or TVHT_MODE_4C with BCC and LDPC encoding is shown in Figure 21-12, with â€œTVHTâ€ replacing â€œVHTâ€ and with bandwidth corrected according to TVHT bandwidth. In the case of BCC encoding, single BCC encoder shall be assumed in Figure 21-12. Figure 22-2 and Figure 22-3 show the transmit process for generating the Data field of a TVHT_MODE_2N or TVHT_MODE_4N SU PPDU with BCC and LDPC encoding, respectively, where the subcarrier allocation block allocates the subcarriers for the two IDFTs in each transmit path by the subcarrier mapper as described in 22.3.10.11. 22.3.4 Overview of the PPDU encoding process 22.3.4.1 General This subclause provides an overview of the VHT PPDU in TVWS bands encoding process. 22.3.4.2 Construction of L-STF Construct the L-STF field as defined in 22.3.8.2.2 following the procedure in 21.3.4.2 reading â€œClause 22â€ for references to â€œClause 21â€ except the following: c) Duplication and phase rotation: Duplicate the L-STF over the BCUs of the CH_BANDWIDTH. Apply appropriate phase rotation as defined in 22.3.7. 2638 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Subcarrier Allocation BCC Constellation Interleaver mapper Spatial Mapping Stream Parser PHY Padding BCC Encoder Scrambler STBC Subcarrier Allocation CSD BCC Constellation per STS Interleaver mapper Insert GI Analog and IDFT and RF Window Insert GI Analog and IDFT and RF Window Insert GI Analog and IDFT and RF Window Insert GI Analog and IDFT and RF Window Figure 22-2â€”Transmitter block diagram for the Data field of a TVHT_MODE_2N or TVHT_- MODE_4N SU PPDU with BCC encoding 22.3.4.3 Construction of the L-LTF Construct the L-LTF field as defined in L-LTF definition following the procedure in 21.3.4.3 reading â€œClause 22â€ for references to â€œClause 21â€ except the following: c) Duplication and phase rotation: Duplicate the L-LTF over the BCUs of the CH_BANDWIDTH. Apply appropriate phase rotation as defined in 22.3.7. 22.3.4.4 Construction of L-SIG Construct the L-SIG field as the SIGNAL field defined by 22.3.8.2.4 following the procedure in 21.3.4.4 reading â€œClause 22â€ for references to â€œClause 21â€ except the following: a) For a VHT PPDU in TVWS bands, set the RATE subfield in the SIGNAL field R1-R4 to 1101. Set the Length, Parity, and Tail bits in the SIGNAL field as defined in 22.3.8.2.4. Add calculated one bit parity and Ntail bits into the L-SIG symbol. f) Duplication and phase rotation: Duplicate the L-SIG field over the BCUs of the CH_BANDWIDTH. Apply appropriate phase rotation as defined in 22.3.7. 2639 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Subcarrier Allocation Constellation LDPC Tone mapper Mapper LDPC Encoder PHY Padding Spatial Mapping Scrambler Stream Parser STBC Subcarrier Allocation CSD Constellation LDPC Tone per STS mapper Mapper Insert GI Analog and IDFT and RF Window Insert GI Analog and IDFT and RF Window Insert GI Analog and IDFT and RF Window Insert GI Analog and IDFT and RF Window Figure 22-3â€”Transmitter block diagram for the Data field of a TVHT_MODE_2N or TVHT_MODE_4N SU PPDU with LDPC encoding 22.3.4.5 Construction of TVHT-SIG-A The TVHT-SIG-A field consists of two symbols, TVHT-SIG-A1 and TVHT-SIG-A2, constructed as defined in 22.3.8.3.3 following the procedure in 21.3.4.5 reading â€œClause 22â€ for references to â€œClause 21â€ except the following: e) Pilot insertion: Insert pilots following the steps defined in 22.3.10.10. f) Duplication and phase rotation: Duplicate TVHT-SIG-A1 and TVHT-SIG-A2 over of the BCUs of the CH_BANDWIDTH. Apply the appropriate phase rotation as defined in 22.3.7. i) Insert GI and apply windowing: Prepend a GI (LONG_GI) and apply windowing as defined in 22.3.7. 22.3.4.6 Construction of TVHT-STF Construct the TVHT-STF field for each BCU as defined in 22.3.8.3.4 with channel bandwidth being 40 MHz, following the procedure in 21.3.4.6 reading â€œClause 22â€ for references to â€œClause 21â€ except the following: b) Phase rotation: Apply appropriate phase rotation as defined in 22.3.7. f) Insert GI and apply windowing: Prepend a GI (LONG_GI) and apply windowing as defined in 22.3.7. 2640 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications In multiple BCU transmissions TVHT_MODE_2C, TVHT_MODE_2N, TVHT_MODE_4C, and TVHT_MODE_4N, the TVHT-STF subcarriers of one BCU are repeated in each BCU with an appropriate phase rotation factor being applied as described in 22.3.8.3.4. 22.3.4.7 Construction of TVHT-LTF Construct the TVHT-LTF field for each BCU as defined in 22.3.8.3.5 with channel bandwidth being 40 MHz, following the procedure in 21.3.4.7 reading â€œClause 22â€ for references to â€œClause 21â€ except the following: b) Phase rotation: Apply appropriate phase rotation as defined in 22.3.7. g) Insert GI and apply windowing: Prepend a GI (LONG_GI) and apply windowing as defined in 22.3.7. In multiple BCU transmissions TVHT_MODE_2C, TVHT_MODE_2N, TVHT_MODE_4C, and TVHT_MODE_4N, the TVHT-LTF subcarriers of one BCU are repeated in each BCU with an appropriate phase rotation factor being applied as described in 22.3.8.3.5. 22.3.4.8 Construction of TVHT-SIG-B The TVHT-SIG-B field is constructed per-user for each BCU as defined in 21.3.4.8 with channel bandwidth being 40 MHz, reading â€œClause 22â€ for references to â€œClause 21â€ except the following: i) Pilot insertion: Insert pilots following the steps defined in 22.3.10.10. m) Phase rotation: Apply the appropriate phase rotations as defined in 22.3.7. o) Insert GI and apply windowing: Prepend a GI (LONG_GI) and apply windowing as defined in 22.3.7. In multiple BCU transmissions TVHT_MODE_2C, TVHT_MODE_2N, TVHT_MODE_4C, and TVHT_MODE_4N, the TVHT-SIG-B subcarriers of one BCU are repeated in each BCU with an appropriate phase rotation factor being applied as described in 22.3.8.3.6. 22.3.4.9 Construction of the Data field in an SU PPDU 22.3.4.9.1 Using BCC The construction of the Data field in a VHT SU PPDU with BCC encoding proceeds as defined in 21.3.4.9.1 reading â€œClause 22â€ for references to â€œClause 21â€ except the following: d) BCC encoder: Only one encoder is used. f) Segment parser is omitted. i) Segment deparser is omitted. l) CSD: Apply CSD for each space-time stream and frequency segment as described in 22.3.8.3.2. n) Phase rotation: Apply the appropriate phase rotations as defined in 22.3.7. o) IDFT: When in TVHT_MODE_2N or VHT_MODE_4N, allocate the subcarriers for the two IDFTs in each transmit path as described in 22.3.10.11. p) Insert GI and apply windowing: Prepend a GI (SHORT_GI or LONG_GI) and apply windowing as defined in 22.3.7. 2641 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 22.3.4.9.2 Using LDPC The construction of the Data field in a VHT SU PPDU with LDPC encoding proceeds as defined in 21.3.4.9.2 reading â€œClause 22â€ for references to â€œClause 21â€ except the following: f) Segment parser is omitted. i) Segment deparser is omitted. l) CSD: Apply CSD for each space-time stream and frequency segment as described in 22.3.8.3.2. n) Phase rotation: Apply the appropriate phase rotations as defined in 22.3.7. When in TVHT_- MODE_2N or VHT_MODE_4N, allocate the subcarriers for the two IDFTs in each transmit path as described in 21.3.10.11.1. o) IDFT: When in TVHT_MODE_2N or VHT_MODE_4N, allocate the subcarriers for the two IDFTs in each transmit path as described in 22.3.10.11. p) Insert GI and apply windowing: Prepend a GI (SHORT_GI or LONG_GI) and apply windowing as defined in 22.3.7. 22.3.4.10 Construction of the Data field in an MU PPDU 22.3.4.10.1 General See 21.3.4.10.1. 22.3.4.10.2 Using BCC A Data field with BCC encoding is constructed using the process defined in 22.3.4.9.1 before the spatial mapping block and repeated for each user that uses BCC encoding. 22.3.4.10.3 Using LDPC A Data field with LDPC encoding is constructed using the process defined in 22.3.4.9.2 before the spatial mapping block and repeated for each user that uses LDPC encoding. 22.3.4.10.4 Combining to form an MU PPDU The per-user data is combined as defined in 21.3.4.10.4 except the following: a) Spatial mapping: The Q matrix is applied as defined in 22.3.10.11. The combining of all user data is done in this block. b) Phase rotation: Apply the appropriate phase rotations as defined in 22.3.7. d) Insert GI and apply windowing: Prepend a GI (SHORT_GI or LONG_GI) and apply windowing as defined in 22.3.7. e) Analog and RF: Upconvert the resulting complex baseband waveform associated with each transmit chain to an RF signal according to the center frequency of the desired channel and transmit. Refer to 22.3.7 and 22.3.8 for details. 22.3.5 Modulation and coding scheme (MCS) The MCS is a value that determines the modulation and coding used in the Data field of the PPDU. It is a compact representation that is carried in the TVHT-SIG-A field for SU PPDUs and in the TVHT-SIG-B field for MU PPDUs. Rate-dependent parameters for the full set of MCSs are shown in Table 22-26 to Table 22- 37 (in 22.5). These tables give rate-dependent parameters for MCSs with indices 0 to 9, with number of spatial streams from 1 to 4 and bandwidth options of one, two, or four BCUs. Equal modulation (EQM) is applied to all streams for a particular user. 2642 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 22-26 to Table 22-29 show rate-dependent parameters for MCSs for one to four streams for one BCU operation. Table 22-30 to Table 22-33 show rate-dependent parameters for MCSs for one to four streams for dual BCU operation. Table 22-34 to Table 22-37 show rate-dependent parameters for MCSs for one to four streams for quad BCU operation. 22.3.6 Timing-related parameters Table 22-8 and Table 22-9 define the timing-related parameters for VHT format and location of occupied tones in TVWS bands. Table 22-8â€”Timing-related parameters Parameter 6 MHz 7 MHz 8 MHz Description NSD 108 108 108 Number of complex data numbers per BCU NSP 6 6 6 Number of pilot values per BCU NST 114 114 114 Total number of subcarriers per BCU NSR 58 58 58 Highest data subcarrier index per BCU 6 MHz 2 7 MHz 2 8 MHz 5 âˆ†F ----------------- = 41 --- kHz ----------------- = 41 --- kHz ----------------- = 55 --- kHz Subcarrier frequency spacing 144 3 168 3 144 9 TDFT 24 Âµs 24 Âµs 18 Âµs IDFT/DFT period TGI 6 Âµs = TDFT /4 6 Âµs = TDFT /4 4.5 Âµs = TDFT /4 Guard interval duration The rest of the timing parameters are derived as in Table 21-5 using the definition of TDFT in Table 22-8. Table 22-9 defines the number of occupied tones and their location in all transmission modes. Zero denotes the DC tone of any contiguous segment. Table 22-9â€”Tone location TVHT_ TVHT_ TVHT_ TVHT_ TVHT_ Parameter Description MODE_1 MODE_2C MODE_2N MODE_4C MODE_4N NST 114 114 114 114 114 Total number of occupied subcarriers per BCU NTT 114 228 228 456 456 Total number of occupied subcarriers across all BCUs 2643 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 22-9â€”Tone location (continued) TVHT_ TVHT_ TVHT_ TVHT_ TVHT_ Parameter Description MODE_1 MODE_2C MODE_2N MODE_4C MODE_4N Subcarrier â€“58 to â€“2 â€“130 to â€“74, â€“58 to â€“2 â€“274 to â€“218, â€“130 to â€“74, Location of index and +2 to â€“70 to â€“14, and +2 to â€“214 to â€“158, â€“70 to â€“14, occupied +58 +14 to +70, +58 for each â€“130 to â€“74, +14 to +70, subcarriers for and +74 to BCU â€“70 to â€“14, and +74 to 6 MHz and 8 MHz +130 +14 to +70, +130 for channel units +74 to +130, each BCU +158 to +214, and +218 to +274 Subcarrier â€“58 to â€“2 â€“142 to â€“86, â€“58 to â€“2 â€“310 to â€“254, â€“142 to â€“86, Location of index and +2 to â€“82 to â€“26, and +2 to â€“250 to â€“194, â€“82 to â€“26, occupied +58 +26 to +82, +58 for each â€“142 to â€“86, +26 to +82, subcarriers for and +86 to BCU â€“82 to â€“26, and +86 to 7 MHz +142 +26 to +82, +142 for +86 to +142, each BCU +194 to +250, and +254 to +310 Refer to Table 21-6 for the frequency parameters. The definitions in the table are applicable to Clause 22 with the exception that in each transmission mode in Clause 22 NCBPSSI = NCBPSS for SU and MU PPDUs. 22.3.7 Mathematical description of signals For a description of the conventions used for the mathematical description of the signals, see 17.3.2.5. For all VHT PPDU in TVWS bands transmission modes the signal is transmitted on subcarriers as defined in Table 22-9. Let fc idx0 = dot11CurrentTVHTChannelCenterFrequencyIndex0 (see Table 22-17) fc idx1 = dot11CurrentTVHTChannelCenterFrequencyIndex1 (see Table 22-17) f PW idx = dot11CurrentPrimaryChannel (see Table 22-17), where TVHT_W refers to a BCU of 6 MHz, 7 MHz, or 8 MHz f CH start = Channel starting frequency given in the operation class (E.1) When dot11CurrentTVHTChannelWidth is TVHT_W, TVHT_2W, TVHT_W+W, TVHT_4W, or TVHT_2W+2W, fPW,idx and fc,idx1 shall have the relationship specified in Equation (22-1). f PW idx = fc idx0 + n PW (22-1) where 1 in TVHT_W and TVHT_W+W N PW = 2 in TVHT_2W and TVHT_2W+2W 4 in TVHT_4W n PW is an integer with possible range 0 n PW N PW â€“ 1 2644 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications When dot11CurrentTVHTChannelWidth is TVHT_W, TVHT_2W, TVHT_W+W, TVHT_4W, or TVHT_2W+2W, â€” The primary TVHT_W channel is the channel with TVHT_W bandwidth centered at f CH start + TVHT_W f PW idx , where f PW idx is given in Equation (22-1). When dot11CurrentTVHTChannelWidth is TVHT_2W, TVHT_4W, or TVHT_2W+2W, â€” The secondary TVHT_W channel is the channel with TVHT_W bandwidth centered at f CH start + TVHT_W f S W idx , where f SW idx is given in Equation (22-2). f PW idx +1 if n PW is even f SW idx = (22-2) f PW idx â€“1 if n PW is odd When dot11CurrentTVHTChannelWidth is TVHT_W+W, â€” The secondary TVHT_W channel is the channel with TVHT_W bandwidth centered at f CH start + TVHT_W f S W idx , where f SW idx is given in Equation (22-3). f SW idx = fc idx1 (22-3) When dot11CurrentTVHTChannelWidth is TVHT_2W, TVHT_4W, or TVHT_2W+2W, â€” The primary TVHT_2W channel is the channel with TVHT_2W bandwidth centered at f CH start + TVHT_W f P2W idx + 0.5 TVHT_W MHz, where f P2W idx is given in Equation (22-4). â€” The secondary TVHT_2W channel is the channel with TVHT_2W bandwidth centered at f CH start + TVHT_W f S 2 W idx + 0.5 TVHT_W MHz, where f S 2 W idx is given in Equation (22-5). 1 in TVHT_2W and TVHT_2W+2W f P2W idx = fc idx0 +2 n P2W 0 n P2W NP 2 W â€“ 1 NP 2 W = (22-4) 2 in TVHT_4W When dot11CurrentTVHTChannelWidth is TVHT_4W, â€” The secondary TVHT_2W channel is the channel with TVHT_2W bandwidth centered at f CH start + TVHT_W f S 2 W idx + 0.5 TVHT_W MHz, where f S 2 W idx is given in Equation (22-5). f P2W idx +2 if n P2W is even f S2W idx = (22-5) f P2W idx â€“2 if n P2W is odd When dot11CurrentTVHTChannelWidth is TVHT_2W+2W, â€” The secondary TVHT_2W channel is the channel with TVHT_2W bandwidth centered at f CH start + TVHT_W f S 2 W idx + 0.5 TVHT_W MHz, where f S 2 W idx is given in Equation (22-3). The transmitted signal is defined in complex baseband signal notation. The actual transmitted signal is related to the complex baseband signal by the relation shown in Equation (21-11) in Clause 21. i f c Seg represents the center frequency of the PPDU transmitted in frequency segment i Seg in each transmission mode in Clause 22. Note that in TVHT_MODE_2C and TVHT_MODE_4C, the gap between the center frequencies of the adjacent segments is as shown in Table 22-9. 2645 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 22-10 shows f ciSeg as a function of dot11CurrentTVHTChannelWidth. Table 22-10â€”Center frequency of a PPDU transmitted in frequency segment iSeg f ciSeg = f CH start + TVHT_W f i Seg + Correction dot11CurrentTVHTCh CH_BANDWIDTH annelWidth (f 0 ,Correction) (f 1 ,Correction) TVHT_W TVHT_W (f c idx0,0) â€” TVHT_2W TVHT_W (f PW idx,0) â€” TVHT_2W (f c idx0,0.5 TVHT_W) â€” TVHT_W+W TVHT_W (f PW idx,0) TVHT_W+W (f c idx0,0) (f c idx1,0) TVHT_4W TVHT_W (f PW idx,0) â€” TVHT_2W (f P2W idx,0.5 TVHT_W) â€” TVHT_4W (f c idx0,1.5 TVHT_W) â€” TVHT_2W+2W TVHT_W (f c idx0,0) TVHT_2W (f c idx0,0.5 TVHT_W) TVHT_2W+2W (f c idx0,0.5 TVHT_W) (f c idx1,0.5 TVHT_W) NOTEâ€”Transmitted signals in TVHT_MODE_2N and TVHT_MODE_4N might have different impairments such as phase offset or phase noise between the two frequency segments in TVHT_MODE_2N or TVHT_MODE_4N, which is not shown in Equation (21-11) for simplicity. See 22.3.17.3. The transmitted RF signal is derived by upconverting the complex baseband signal, which consists of several fields. The signal transmitted on frequency segment i Seg of transmit chain i TX is described by Equation (21-12) in 21.3.7. The timing boundaries for the various fields are shown in Figure 21-17. Each field is defined as the summation of one or more subfields, where each subfield is defined to be an inverse discrete Fourier transform as specified in Equation (21-13) and where references to Table 21-5, Table 21-6, Table 21-8, Table 22-9, Table 21-10, and Table 21-11 are replaced by the corresponding descriptions in Clause 22 including Table 22-8, Table 22-9, Table 22-11, and Table 22-12. Tone Table 22-11 summarizes the various values of N Field as a function of number of BCUs (TVHT_MODE_1 has one BCU, TVHT_MODE_2C and TVHT_MODE_2N have two BCUs, and TVHT_MODE_4C and TVHT_MODE_4N have four BCUs). 2646 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 22-11â€”Tone scaling factor and guard interval duration values for PHY fields Tone N Field as a function of the number of BCUs Guard interval Field duration One Two Four L-STF 24 48 96 â€” L-LTF 104 208 416 TGI2 L-SIG 104 208 416 TGI TVHT-SIG-A 104 208 416 TGI TVHT-STF 24 48 96 - TVHT-LTF 114 228 456 TGI TVHT-SIG- 114 228 456 TGI VHT-Data 114 228 484 TGI or TGIS (see NOTE 2) NON_HT_DUP_OFDM-Data (see NOTE 1) 104 208 416 TGI NOTE 1â€”For notational convenience, NON_HT_DUP_OFDM-Data is used as a label for the Data field of a NON_HT PPDU with format type NON_HT_DUP_OFDM. NOTE 2â€”TGI denotes guard interval duration when TXVECTOR parameter GI_TYPE equals LONG_GI, TGIS denotes short guard interval duration when TXVECTOR parameter GI_TYPE equals SHORT_GI. In addition, the parameter k BW in Equation (21-13) is replaced by k M as defined in Table 22-12. Table 22-12â€”Transmission mode and Gamma subk,M Transmission mode k M TVHT_MODE_1, k 1 per segment TVHT_MODE_2N TVHT_MODE_2C, k 2 per two contiguous segments TVHT_MODE_4N TVHT_MODE_4C k 4 For TVHT_MODE_1 and TVHT_MODE_2N PPDU transmission, 1 k 0 k 1 = (22-6) j k 0 For TVHT_MODE_2C and TVHT_MODE_4N PPDU transmission, 1 k â€“ 72 for 6 MHz and 8 MHz channels, k â€“ 84 for 7 MHz channels k 2 = (22-7) â€“1 k â€“ 72 for 6 MHz and 8 MHz channels, k â€“ 84 for 7 MHz channels 2647 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications For TVHT_MODE_4C PPDU transmission, 1 k â€“ 216 for 6 MHz and 8 MHz channels, k â€“ 252 for 7 MHz channels â€“1 â€“ 216 k 0 for 6 MHz and 8 MHz channels, â€“ 252 k 0 for 7 MHz channels k 4 = (22-8) 1 0 k 72 for 6 MHz and 8 MHz channels, 0 k 84 for 7 MHz channels â€“1 k 72 for 6 MHz and 8 MHz channels, k 84 for 7 MHz channels 22.3.8 TVHT preamble 22.3.8.1 Introduction A TVHT preamble is defined to carry the required information to operate in either single user or multi-user mode. 22.3.8.2 Non-TVHT portion of TVHT format preamble 22.3.8.2.1 Cyclic shift definition for pre-TVHT modulated fields i TX The cyclic shift value T CS for the L-STF, L-LTF, L-SIG, and TVHT-SIG-A fields of the PPDU for transmit chain i TX out of a total of N TX is defined in Table 21-10 with a scaling factor to account for the change in sampling clock frequency. The CSD delay values shall be multiplied by the corresponding correction values for the 6 MHz, 7 MHz, and 8 MHz channels, respectively. The scaling factor for transmissions over 6 MHz and 7 MHz channels is 7.5. The scaling factor for transmissions over 8 MHz channels is 5.625. As an example, the CSD value for antenna-2 with 2-transmit antennas is â€“200 ns, and the corresponding CSD value for 6 MHz channels is â€“1.5 Âµs. 22.3.8.2.2 L-STF definition The L-STF field for each BCU in any transmission mode is defined by Equation (19-9) in 19.3.9.3.3. The time domain representation of the signal on BCU i Seg in transmit chain i TX is specified in Equation (21-20), where k BW is replaced by k M as defined in Table 22-12 and where N SR and âˆ†F are defined in Table 22-8. 22.3.8.2.3 L-LTF definition The L-LTF field for each BCU in any transmission mode is defined by Equation (19-12) in 19.3.9.3.4. Note that these equations do not include the phase rotations as defined in Table 22-12. The time domain representation of the signal in transmit chain i TX is specified in Equation (21-23), where k BW is replaced by k M as defined in Table 22-12 and where N SR is defined in Table 22-8. 22.3.8.2.4 L-SIG definition The L-SIG field is used to communicate data rate and length information. The structure of the L-SIG field is defined in Figure 17-5. 2648 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications In a VHT PPDU, the RATE field shall be set to the value corresponding to 6 Mb/s in the 20 MHz channel spacing column of Table 17-6. In a NON_HT_DUP PPDU, the RATE field is defined in 17.3.4.2 using the L_DATARATE parameter in the TXVECTOR. The LENGTH field shall be set to the value given by Equation (22-9). LENGTH = TXTIME â€“ 20 scaling factor 4 scaling factor 3â€“3 (22-9) where the scaling factor is defined in 22.3.8.2.1 and TXTIME is defined in 22.4.3. In a non-HT duplicate PPDU, the LENGTH field is defined in 17.3.4.3 using the L_LENGTH parameter in the TXVECTOR. The time domain waveform of the L-SIG field in each BCU is specified in Equation (21-25) using N 20MHz = 2, where k BW is replaced by k M as defined in Table 22-12 and where the rest of the variables are specified in 22.3.7. 22.3.8.3 TVHT portion of TVHT format preamble 22.3.8.3.1 Introduction The TVHT portion of the VHT format preamble consists of the TVHT-SIG-A, TVHT-STF, TVHT-LTF, and TVHT-SIG-B fields. Notational conventions are specified in 21.3.8.3.1. 22.3.8.3.2 Cyclic shift for TVHT modulated fields The definition, application, and CSD values are defined in 21.3.8.3.2 with scaling factors as defined in 22.3.8.2.1. 22.3.8.3.3 TVHT-SIG-A definition The TVHT-SIG-A field carries information required to interpret VHT PPDU in TVWS bands and is defined in 21.3.8.3.3. The time domain waveform of the TVHT-SIG-A field in each BCU is specified in Equation (21-28), where N 20MHz = 2 and where the rest of the variables are specified in 22.3.7. Fields in the TVHT-SIG-A fields are the same as in Table 21-12 except for the description B0-B1 (BW) and B10-B21 in TVHT-SIG-A1. Description of B0-B1 is specified in Table 22-13 Table 22-13â€”B0-B1 (BW) in TVHT-SIG-A1 B0-B1 TVHT_MODE 00 Not used 10 TVHT_MODE_1 01 TVHT_MODE_2C and TVHT_MODE_2N 11 TVHT_MODE_4C and TVHT_MODE_4N 2649 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Description of B10-B21 (NSTS/Partial AID) is specified as follows: For an MU PPDU: NSTS is divided into 4 user positions of 3 bits each. User position p, where 0 p uses bits B(10+3p)-B(12+3p). The number of space-time streams for user u is indicated at user position p = USER_POSITION[u] where u = 0, 1, ..., NUM_USER â€“ 1 and where the notation A[b] denotes the value of array A at index b. Zero space-time streams are indicated at positions not listed in the USER_POSITION array. Set to 0 for 0 space time streams Set to 1 for 1 space time stream Set to 2 for 2 space time streams Set to 3 for 3 space time streams Values 4 to 7 are reserved For an SU PPDU: B10-B12 Set to 0 for 1 space time stream Set to 1 for 2 space time streams Set to 2 for 3 space time streams Set to 3 for 4 space time streams Values 4 to 7 are reserved B13-B21 Partial AID: Set to the value of the TXVECTOR parameter PARTIAL_AID. Partial AID provides an abbreviated indication of the intended recipient(s) of the PSDU (see 10.20). 22.3.8.3.4 TVHT-STF definition The TVHT-STF field for each BCU in any transmission mode is defined by Equation (21-30) in 21.3.8.3.4. The time domain waveform of the TVHT-STF field in each BCU is specified in Equation (21-33), where k BW is replaced by k M as defined in Table 22-12 and where N SR is defined in Table 22-8. 22.3.8.3.5 TVHT-LTF definition The TVHT-LTF field is defined in 21.3.8.3.5. The TVHT-LTF sequence transmitted for each BCU in any transmission mode is defined by Equation (21-37). The time domain waveform of the TVHT-LTF field in each BCU is specified in Equation (21-42), where k BW is replaced by k M as defined in Table 22-12 and where N SR is defined in Table 22-8. 22.3.8.3.6 TVHT-SIG-B definition The TVHT-SIG-B field for each BCU in any transmission mode is as defined in 21.3.8.3.6 for 40 MHz bandwidth. The 27 TVHT-SIG-B bits are first repeated twice, then BCC encoded, interleaved, and made into constellations as described by Figure 21-22 and the corresponding text in 21.3.8.3.6. If the channel bandwidth of the current PPDU is TVHT_W, then the IDFT is conducted as defined in 21.3.8.3.6. 2650 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The time domain waveform for the TVHT-SIG-B field in each BCU in a VHT PPDU is the same as Equation (21-47) with channel bandwidth being 40 MHz. If the channel bandwidth of the current PPDU is larger than TVHT_W, then the TVHT-SIG-B subcarriers as described above are repeated in each BCU, with appropriate phase rotation factors k M being applied as shown in Table 22-12, before conducting IDFT. 22.3.9 Transmission of NON_HT and HT PPDUs with multiple antennas A TVHT STA that transmits a NON_HT PPDU shall apply the cyclic shifts defined in 22.3.8.2.1 for L-STF, L-LTF, and L-SIG fields of the PPDU. 22.3.10 Data field 22.3.10.1 General See 21.3.10.1, with â€œTVHTâ€ replacing â€œVHTâ€. 22.3.10.2 SERVICE field See 21.3.10.2, with â€œTVHTâ€ replacing â€œVHTâ€. 22.3.10.3 CRC calculation for TVHT-SIG-B The CRC calculation and insertion is illustrated in Figure 21-23. The value of the CRC field shall be the 1s complement of Equation (21-59) with the values of N set to 21 for all Modes. 22.3.10.4 Scrambler See 21.3.10.4 with â€œTVHTâ€ replacing â€œVHTâ€. 22.3.10.5 Coding See 21.3.10.5 with â€œTVHTâ€ replacing â€œVHTâ€. 22.3.10.6 Stream parser After coding and puncturing, the data bit streams at the output of the FEC encoders are processed in groups of NCBPS bits. Each of these groups is rearranged into NSS blocks of NCBPSS bits (NSS,u blocks of NCBPSS,u bits in the case of an MU transmission). This operation is referred to as stream parsing and is described in 21.3.10.6. 22.3.10.7 Segment parser The segment parser as described in 21.3.10.7 is not used in Clause 22. All modes of operation use a common interleaver in the case of BCC or use a common tone mapper in the case of LDPC. 22.3.10.8 BCC interleaver The BCC interleaver and deinterleaver for one BCU (TVHT_MODE_1) is as defined in 21.3.10.8 for 40 MHz. 2651 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The BCC interleaver and deinterleaver for TVHT_MODE_2C, TVHT_MODE_2N, TVHT_MODE_4C, and TVHT_MODE_4N reuse the same formulas as described in 21.3.10.8 for 40 MHz with new values for N COL , N ROW , and N ROT as defined in Table 22-14. Table 22-14â€”Number of rows and columns in the interleaver TVHT_MODE_2C, TVHT_MODE_4C, Parameter TVHT_MODE_1 TVHT_MODE_2N TVTH_MODE_4N N COL 18 27 48 N ROW 6 N BPSCS 8 N BPSCS 9 N BPSCS N ROT (NSS â‰¤ 4) 29 46 78 22.3.10.9 Constellation mapping 22.3.10.9.1 General The mapping between bits at the output of the interleaver and complex constellation points is as described in 21.3.10.9.1. The streams of complex numbers in frequency subblock l for user u are denoted d' k i n l u ; k= 0 1 N SD â€“ 1 ; i = 1 N SS u ; n = 0 1 N SYM â€“ 1 ; l = 0 for all transmission modes. 22.3.10.9.2 LDPC tone mapping The LDPC tone mapping for one BCU (TVHT_MODE_1) is as defined in 21.3.10.9.2 for 40 MHz. The LDPC tone mapping for TVHT_MODE_2C, TVHT_MODE_2N, TVHT_MODE_4C, and TVHT_MODE_4N reuses the same formulas as described in 21.3.10.9.2 for 40 MHz with values for D TM as defined in Table 22-15. Table 22-15â€”LDPC Tone Mapping Distance for each transmission mode TVHT_MODE_2C, TVHT_MODE_4C, Parameter TVHT_MODE_1 TVHT_MODE_2N TVHT_MODE_4N D TM 6 8 9 For all Clause 22 transmission Modes, the LDPC tone mapping for LDPC-coded streams corresponding to user u is done by permuting the stream of complex numbers d' k i n l u; k=0 1 N SD â€“ 1 ; i = 1 N SS u ; n = 0 1 N SYM â€“ 1 ; l = 0 for all transmission modes. generated by the constellation mappers, to obtain d' t k i n l u; k=0 1 N SD â€“ 1 ; i = 1 N SS u ; n = 0 1 N SYM â€“ 1 ; l = 0 for all transmission modes. 2652 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications where N SD k D TM t(k) = D TM k mod --------- - + ----------------- for all transmission modes D TM N SD 22.3.10.9.3 Segment deparser The segment deparser is not used in Clause 22 as no segment parser is used in Clause 22. 22.3.10.9.4 Space-time block coding See 21.3.10.9.4 with â€œTVHTâ€ replacing â€œVHTâ€. 22.3.10.10 Pilot subcarriers For TVHT_MODE_1 transmission, six pilot tones shall be inserted in subcarriers â€“53, â€“25, â€“11, 11, 25, and 53. The pilots are generated as described in 21.3.10.10 for 40 MHz transmission. When multiple BCUs are used (TVHT_MODE_2C, TVHT_MODE_2N, TVHT_MODE_4C, and TVHT_MODE_4N), each BCU shall use the same pilot tones, which are generated as described in 21.3.10.10 for 40 MHz transmission. 22.3.10.11 OFDM modulation transmission in VHT format For TVHT transmissions, the signal from transmit chain iTX, 1 iTX NTX shall be as specified in Equation (21-95), where k BW is replaced by k M as defined in Table 22-12 and where N SR and âˆ†F are defined in Table 22-8. For TVHT_MODE_1 transmission, parameters shall be selected to be the same with 40 MHz VHT transmission as defined in 21.3.10.11.1. For multi-segment transmissions TVHT_MODE_2C and TVHT_MODE_4C, each frequency segment shall follow the waveform as described in Equation (21-95), and the data and pilot subcarriers are allocated to the IDFT block according to the subcarrier mapping as specified in Table 22-9 in consecutive order from the lowest subcarrier to the highest subcarrier. For multi-segment transmissions TVHT_MODE_2N and TVHT_MODE_4N, each frequency segment shall follow the waveform as described in Equation (21-95), and the data and pilot subcarriers are allocated by the subcarrier allocation block, as shown in Figure 22-2, to the two IDFT blocks according to the subcarrier mapping as specified in Equation (21-95) and Table 22-9 in consecutive order from the lowest subcarrier to the highest subcarrier in each of the two frequency segments, the lower half of the subcarriers are mapped to the IDFT corresponding to the lower frequency segment, and the upper half of the subcarriers are mapped to the IDFT corresponding to the upper frequency segment. 22.3.10.12 Non-HT duplicate transmission When the TXVECTOR parameter FORMAT is NON_HT and the TXVECTOR parameter NON_HT_MODULATION is NON_HT_DUP_OFDM, the transmitted PPDU shall be a non-HT duplicate. Multiple BCUs non-HT duplicate transmission is used to transmit to TVHT STAs that may be present in a part of a channel. For non-HT duplicate transmission, the Data field shall be as defined in 21.3.10.12, with â€œTVHTâ€ replacing â€œVHTâ€ and with references to â€œClause 22â€ replacing references to â€œClause 21â€, using the parameter values 2653 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications defined in Table 22-16. The Data field shall be as defined by Equation (21-100) with following modifications. N 20MHz is defined in Table 22-16. KShift(i) in Equation (21-100) is replaced by K Shift i = N â€“ 1 â€“ 2i 32 + 8 N 20MHz 4 + 8 N 20MHz 8 â€“ 16 i 2 . 20MHz i Tone T CS TX represents the cyclic shift of the transmit chain i and is defined in 22.3.8.2.1. N NON_HT_DUP_OFDM-Data TX is defined in Table 22-16. Table 22-16â€”Parameters for Non-HT duplicate transmissions TVHT_ TVHT_ TVHT_ TVHT_ TVHT_ Parameter MODE_1 MODE_2C MODE_2N MODE_4C MODE_4N N 20MHz 2 4 2 8 4 Tone N NON_HT_DUP_OFDM-Data 104 208 104 416 208 In addition, the parameter k BW is replaced by k M as defined in Table 22-12. For a noncontiguous TVHT_W+W or TVHT_2W+2W non-HT duplicate transmission, data transmission in each frequency segment shall be as defined for a TVHT_W or TVHT_2W non-HT duplicate transmission, respectively. 22.3.11 SU-MIMO and MU-MIMO Beamforming 22.3.11.1 General SU-MIMO and DL-MU-MIMO beamforming in TVWS band is used as defined in 21.3.11.1 reading â€œClause 22â€ for references to â€œClause 21â€ except for feedback report format described in 9.4.1.50. 22.3.11.2 Beamforming Feedback Matrix V Beamforming Feedback Matrix V is constructed as defined in 21.3.11.2 reading â€œClause 22â€ for reference to â€œClause 21â€ except for CSD values defined in 22.3.8.3.2. 22.3.11.3 Group ID See 21.3.11.4 with â€œTVHTâ€ replacing â€œVHTâ€. 22.3.12 TVHT preamble format for sounding PPDUs The format of a VHT NDP PPDU in TVWS bands is constructed as defined Figure 22-1. NOTEâ€”The number of TVHT-LTF symbols in the NDP is determined by the SU NSTS field in TVHT-SIG-A. The TVHT NDP PPDU has the following properties: â€” Uses the TVHT PPDU format but without the Data field. â€” Is a TVHT SU PPDU as indicated by the TVHT-SIG-A field. â€” Has the data bits of the TVHT-SIG-B field set to a fixed bit pattern (see 22.3.8.3.6). 22.3.13 Regulatory requirements See 21.3.13. 2654 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 22.3.14 Channelization A TVHT channel is specified by the four PLME MIB fields specified in Table 22-17. Table 22-17â€”Fields to specify TVHT channels Field Meaning dot11CurrentTVHTChannel Channel width. Possible values represent TVHT_W, TVHT_2W, TVHT_W+W, Width TVHT_4W, TVHT_2W+2W. dot11CurrentTVHTChannelC In TVHT_MODE_1, TVHT_MODE_2C, and TVHT_MODE_4C operation enterFrequencyIndex0 denotes the center frequency of the lowest TV channel. In TVHT_MODE_2N and TVHT_MODE_4N operation, denotes the center frequency of the lowest TV channel in the frequency segment that contains the primary channel. Valid range is 1 to 200. See Equation (22-10). dot11CurrentTVHTChannelC In TVHT_MODE_2N and TVHT_MODE_4N operation, denotes the center enterFrequencyIndex1 frequency of the lowest TV channel in the frequency segment that does not contain the primary channel. Valid range is 1 to 200. See Equation (22-10). Undefined for TVHT_MODE_1, TVHT_MODE_2C, and TVHT_MODE_4C operation. dot11CurrentPrimaryChannel Denotes the location of the primary TVHT_W channel. Valid range is 1 to 200. See Equation (22-11). Given dot11CurrentTVHTChannelCenterFrequencyIndex0 and dot11CurrentTVHTChannelCenterFrequencyIndex1, the respective center frequency is given by Equation (22-10). Channel center frequency [MHz] = Channel starting frequency (22-10) + TVHT_W dot11CurrentChannelCenterFrequencyIndex + ChannelCenterFrequencyCorrection where Channel starting frequency is given by the Operating Class (E.1) and dot11CurrentTVHTChannelCenterFrequencyIndex is either dot11CurrentTVHTChannelCenterFrequen- cyIndex0 or dot11CurrentTVHTChannelCenterFrequencyIndex1 and ChannelCenterFrequencyCorrection is 0 for TVHT_MODE_1 and TVHT_MODE_2N, 0.5 TVHT_W for TVHT_MODE_2C and TVHT+MODE_4N , 1.5 TVHT_W for TVHT_MODE_4C. NOTEâ€”Channel starting frequency is the frequency that results in the regulatory domainâ€™s channel number being the RLAN channel number, i.e., the center frequency of the channel for index 0. For example, the center frequency of U.S. TV channel 2 is 57 MHz. The center frequency of U.S. TV channel 2 is obtained by Equation (22-10) as follows: Channel center frequency [MHz] = Channel starting frequency + TVHT_W Ã— dot11CurrentTVHTChannelCenterFrequencyIndex + ChannelCenterFrequencyCorrection = (0.045 Ã— 1000) + 6 Ã— 2 + 0 = 57 MHz. The center frequency of the primary TVHT_W channel is given by Equation (22-11). 2655 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Primary channel center frequency [MHz] (22-11) = Channel starting frequency + TVHT_W dot11CurrentPrimaryChannel The channel starting frequency is given by the Operating Class (see E.1). For TVHT_MODE_2N operation, any two non-identical channels may be used. For TVHT_MODE_4N operation, any two channels that would each be allowed as TVHT_2W channels and whose center frequencies are separated by greater than TVHT_2W (difference between dot11CurrentTVHTChannelCenterFrequencyIndex0 and dot11CurrentTVHTChannelCenterFrequencyIndex1 corresponds to a frequency difference greater than 2) may be used. For example, in the United States, a channel specified by dot11CurrentTVHTChannelWidth = TVHT_2W (12 MHz) dot11CurrentTVHTChannelCenterFrequencyIndex0 = 15 dot11CurrentPrimaryChannel = 16 is a 12 MHz channel with a center frequency of 482 MHz and the primary 6 MHz channel centered at 485 MHz. A channel specified by dot11CurrentTVHTChannelWidth = TVHT_4W (24 MHz) dot11CurrentTVHTChannelCenterFrequencyIndex0 = 14 dot11CurrentPrimaryChannel = 17 is a 24 MHz channel with a center frequency of 482 MHz and the primary 6 MHz channel centered at 491 MHz. A channel specified by dot11CurrentTVHTChannelWidth = TVHT_2W+2W (12+12 MHz) dot11CurrentTVHTChannelCenterFrequencyIndex0 =15 dot11CurrentTVHTChannelCenterFrequencyIndex1 = 40 dot11CurrentPrimaryChannel = 16 is an 12+12 MHz channel in which frequency segment 0 has 12 MHz bandwidth and center frequency of 482 MHz. Frequency segment 1 also has 12 MHz bandwidth and center frequency of 632 MHz. The primary 6 MHz channel is centered at 485 MHz. 22.3.15 Slot time The slot time for the TVHT PHY shall be 24 Âµs for 6 MHz and 7 MHz channel units and 20 Âµs for 8 MHz channel units. 22.3.16 Transmit and receive port impedance Transmit and receive antenna connector impedance for each transmit and receive antenna is defined in 17.3.8.7. 2656 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 22.3.17 TVHT transmit specification 22.3.17.1 Transmit spectrum mask For transmission in TVHT_MODE_1, TVHT_MODE_2C, and TVHT_MODE_4C, the transmit spectral mask shall be as described for 40 MHz mask PPDU in 21.3.17.1 with the frequency axis multiplied by the frequency scaling factor as defined in Table 22-18. Table 22-18â€”Spectral mask frequency scaling factor for contiguous transmission Scaling for 6 MHz Scaling for 7 MHz Scaling for 8 MHz Mode channels channels channels TVHT_MODE_1 6 / 40 7 / 40 8 / 40 TVHT_MODE_2C 12 / 40 14 / 40 16 / 40 TVHT_MODE_4C 24 / 40 28 / 40 32 / 40 For transmission in mode TVHT_MODE_4N, the transmit spectral mask shall be as described for 80+80 MHz mask PPDU in 21.3.17.1 with the frequency axis multiplied by the frequency scaling factor as defined in Table 22-19. Table 22-19â€”Spectral mask frequency scaling factor for TVHT_MODE_4N Scaling for 6 MHz Scaling for 7 MHz Scaling for 8 MHz Mode channels channels channels TVHT_MODE_4N 12 / 80 14 / 80 16 / 80 NOTE 1â€”In the presence of additional regulatory restrictions, the device has to meet both the regulatory requirements (measured as defined in the relevant regulation) and the mask defined in this subclause. NOTE 2â€”For rules regarding TX center frequency leakage levels, see 22.3.17.4.2. For a TVHT_W+W mask PPDU of VHT or non-HT duplicate format, the overall transmit spectral mask is constructed in the following manner. First, the 40 MHz interim transmit spectral mask shall have a 0 dBr (dB relative to the maximum spectral density of the signal) bandwidth of 38 MHz, â€“20 dBr at 21 MHz frequency offset, â€“28 dBr at 40 MHz frequency offset, and â€“40 dBr at 60 MHz frequency offset and above. The 40 MHz interim transmit spectral mask for frequency offsets in between 19 MHz and 21 MHz, 21 MHz and 40 MHz, and 40 MHz and 60 MHz shall be linearly interpolated in dB domain from the requirements for 19 MHz, 21 MHz, 40 MHz, and 60 MHz frequency offsets. Then the 40 MHz interim spectral mask frequency points are scaled as defined in Table 22-20 to produce a TVHT_W interim spectral mask. Then, the TVHT_W interim spectral mask is placed on each of the two segments to produce the TVHT_W+W interim spectral mask. Then, for each frequency at which both of the TVHT_W interim spectral masks have values greater than â€“40 dBr and less than â€“20 dBr, the sum of the two TVHT_W interim mask values (summed in linear domain) shall be taken as the overall TVHT_W+W interim spectral mask value. Next, for each frequency at which neither of the two TVHT_W interim masks has values greater than or equal to â€“ 20 dBr and less than or equal to 0 dBr, the higher value of the two interim masks shall be taken as the overall TVHT_W+W interim mask spectral value. Finally, for any frequency region where the TVHT_W+W interim mask value has not been defined yet, linear interpolation (in dB domain) between the nearest two frequency points with the TVHT_W+W interim spectral mask value defined shall be used to define the 2657 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications TVHT_W+W interim spectral mask value. The transmit spectrum shall not exceed the maximum of the TVHT_W+W interim transmit spectrum mask and â€“59 dBm/MHz at any frequency offset. Table 22-20â€”Spectral mask frequency scaling factor for TVHT_MODE_2N Scaling for 6 MHz Scaling for 7 MHz Scaling for 8 MHz Mode channels channels channels TVHT_MODE_2N 6 / 40 7 / 40 8 / 40 Example transmit spectral mask for a TVHT_W+W mask PPDU for BCU of 6 MHz and spacing of 12 MHz is shown in Figure 22-4. P P S S 0 D 0 D dBr dBr 6 MHz 6 MHz -20 Mask 1 -20 Mask 2 dBr dBr -28 -28 dBr dBr -40 -40 - - dBr - - dBr 2 3 2 3 3 2 3 2 . . f[MH . . f[MH . . . . -9 -6 0 9 0 9 0 6 9 z] -9 -6 0 9 0 9 0 6 9 z] 2 7 2 7 2 2 7 2 5 5 5 5 5 5 5 5 P S 0 D dBr Overall transmit spectral mask (bold line) both of the 6 -20 neither of the dBr two 6 MHz MHz sp ectral -25 -28 masks have masks have dBr dBr values values grea ter than grea ter than -40 dBr and or equa l to - less than -20 20 dBr and dBr less than or equ al to 0 -40 dBr dBr - - 2 3 3 2 - - . . f[MH . . 8.92 9.07 -15 -12 9.07 8.92 -6 0 9 9 0 6 5 5 12 15 z] higher 5 5 Original lin. 2 7 Original higher 7 2 5 5 value Mask 1 5 5 sum Mask 2 value Figure 22-4â€”Example transmit spectral mask for an 6+6 MHz mask PPDU 22.3.17.2 Spectral flatness Spectral flatness measurements shall be conducted using BPSK modulated PPDUs. See 22.3.17.4.4 for the demodulation procedure of the PPDUs as well as the number of PPDUs and OFDM symbols to be used for testing. 2658 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Let E i avg denote the average constellation energy of a BPSK modulated subcarrier i in a TVHT data symbol. For TVHT_MODE_1 contiguous non-HT duplicate or TVHT transmission having a bandwidth listed in Table 22-21, E i avg of each of the subcarriers with indices listed as tested subcarrier indices shall not deviate by more than the specified maximum deviation in Table 22-21 from the average of E i avg over subcarrier indices listed as averaging subcarrier indices. Averaging of E i avg is done in the linear domain. Table 22-21â€”Maximum transmit spectral flatness deviations Bandwidth of Maximum Averaging subcarrier Tested subcarrier Format transmission deviation indices (inclusive) indices (inclusive) (MHz) (dB) VHT TVHT_W â€“42 to â€“2 and +2 to +42 â€“42 to â€“2 and +2 to +42 Â±4 â€“58 to â€“43 and +43 to +58 +4/â€“6 non-HT duplicate TVHT_W â€“42 to â€“33, â€“31 to â€“6, +6 â€“42 to â€“33, â€“31 to â€“6, +6 Â±4 to +31, and +33 to +42 to +31, and +33 to +42 â€“43 to â€“58 and +43 to +58 +4/â€“6 For transmissions consisting of multiple contiguous or noncontiguous BCUs, each BCU shall meet the spectral flatness requirement for TVHT_MODE_1 transmission. For the spectral flatness test, the transmitting STA shall be configured to use a spatial mapping matrix Qk (see 22.3.10.11) with flat frequency response. Each output port under test of the transmitting STA shall be connected through a cable to one input port of the testing instrumentation. 22.3.17.3 Transmit center frequency and symbol clock frequency tolerance The transmitter center frequency maximum allowable deviation shall be Â±25 ppm. Carrier (LO) and symbol clock frequencies for the all transmit chains and BCUs shall be derived from the same reference oscillator. NOTEâ€”For multi-channel operation, the signal phase of each BCU might be uncorrelated. The symbol clock frequency tolerance shall be maximum Â±25 ppm. The transmit center frequency and the symbol clock frequency for all transmit antennas and contiguous BCUs shall be derived from the same reference oscillator. 22.3.17.4 Modulation accuracy 22.3.17.4.1 Introduction to modulation accuracy tests Transmit modulation accuracy specifications are defined in 22.3.17.4.2 and 22.3.17.4.3. The test method is described in 21.3.17.4.4. 2659 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 22.3.17.4.2 Transmit center frequency leakage For transmissions using all formats except noncontiguous where the RF LO falls outside both BCUs, TX LO leakage shall meet the following requirements: â€” When the RF LO is in the center of the transmitted PPDU BW, the power measured at the center of transmission BW using resolution BW (6/144 or 8/144) MHz shall not exceed the average power per subcarrier of the transmitted PPDU, or equivalently ( P â€“ 10 log 10(N ST) ), where P is the transmit power per antenna in dBm and NST is defined in Table 22-8. â€” When the RF LO is not at the center of the transmitted PPDU BW, the power measured at the location of the RF LO using resolution BW (6/144 or 8/144) MHz shall not exceed the maximum of â€“32 dB relative to the total transmit power and â€“20 dBm, or equivalently max(P â€“ 32 â€“ 20) , where P is the transmit power per antenna in dBm and NST is defined in Table 22-8. For transmissions using TVHT_MODE_2N and TVHT_MODE_4N, where the RF LO falls outside both BCUs, the RF LO shall follow the spectral mask requirements as defined in 22.3.17.1. 22.3.17.4.3 Transmitter constellation error For all modes defined in TVHT PHY, the requirements for transmit constellation RMS error are same as defined in 21.3.17.4.3. For non-HT duplicate transmissions, requirements defined in 17.3.9.7.4 apply to all parts of the channel bandwidth. The channel bandwidth is determined by the TXVECTOR parameter CH_BANDWIDTH. 22.3.17.4.4 Transmitter modulation accuracy (EVM) test For the transmit modulation accuracy test, the same methodology as that defined in 21.3.17.4.4 shall be applied per BCU (termed frequency segment in Clause 21). The channel bandwidth is determined by the TXVECTOR parameter CH_BANDWIDTH. 22.3.17.5 Time of Departure accuracy For Time of Departure accuracy test, the test parameters defined in 21.3.17.5 shall be used for evaluation of TOD except the channel bandwidth, TTR and TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH. The channel bandwidth is determined by TXVECTOR parameter CH_BANDWIDTH in 22.2.2. TTR and TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH shall be multiplied by the corresponding scaling factor for the 6 MHz, 7 MHz, and 8 MHz channels, where the scaling factor is defined in 22.3.8.2.1. 22.3.18 TVHT receiver specification 22.3.18.1 General See 21.3.18. 22.3.18.2 Receiver minimum input sensitivity The packet error ratio (PER) shall be less than 10% for a PSDU length of 4096 octets with the rate- dependent input levels listed in Table 22-22. The test in this subclause and the minimum sensitivity levels specified in Table 22-22 apply only to non-STBC modes, long GI, BCC, and VHT PPDU in TVWS bands. 2660 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 22-22â€”Receiver minimum input level sensitivity Minimum sensitivity (dBm) 12/14 MHz 24/28 MHz 32 MHz 16 MHz Rate 6 or 7 (TVHT_ (TVHT_ (TVHT_ Modulation (TVHT_ (R) MHz MODE_2C) MODE_4C 8 MHz MODE_4C) MODE_2C) (TVHT_ or 6+6/7+7 or 12+12/ (TVHT_ or 16+16/ or 8+8 MHz MODE_1) MHz 14+14 MHz MODE_1) 16+16 MHz (TVHT_ (TVHT_ (TVHT_ (TVHT_ MODE_2N) MODE_2N) MODE_4N) MODE_4N) BPSK 1/2 â€“88 â€“85 â€“82 â€“87 â€“84 â€“81 QPSK 1/2 â€“85 â€“82 â€“79 â€“84 â€“81 â€“78 QPSK 3/4 â€“83 â€“80 â€“77 â€“82 â€“79 â€“76 16-QAM 1/2 â€“80 â€“77 â€“74 â€“79 â€“76 â€“73 16-QAM 3/4 â€“76 â€“73 â€“70 â€“75 â€“72 â€“69 64-QAM 2/3 â€“72 â€“69 â€“66 â€“71 â€“68 â€“65 64-QAM 3/4 â€“71 â€“68 â€“65 â€“70 â€“67 â€“64 64-QAM 5/6 â€“70 â€“67 â€“64 â€“69 â€“66 â€“63 256-QAM 3/4 â€“65 â€“62 â€“59 â€“64 â€“61 â€“58 256-QAM 5/6 â€“63 â€“60 â€“57 â€“62 â€“59 â€“56 22.3.18.3 Adjacent channel rejection Adjacent channel rejection for TVHT_MODE_1, TVHT_MODE_2C, and TVHT_MODE_4C follow the definition in the first paragraph of 21.3.18.2 and use the values in Table 22-23. Adjacent channel rejection for TVHT_MODE_2N (TVHT_W+W) and TVHT_MODE_4N (TVWT_2W+2W) follows the definition in the second paragraph of 21.3.18.2, where â€œ80 MHzâ€ is replaced by â€œTVHT_Wâ€ for TVHT_MODE_2N and â€œTVHT_2Wâ€ for TVHT_MODE_4N, and uses the values in Table 22-23. The definitions in the rest of 21.3.18.2 apply to Clause 22 using the values in Table 22-23. 22.3.18.4 Nonadjacent channel rejection Nonadjacent channel rejection for TVHT_MODE_1, TVHT_MODE_2C, and TVHT_MODE_4C channels follows the definition in the first paragraph of 21.3.18.3 and use the values in Table 22-23. Nonadjacent channel rejection for TVHT_MODE_2N (TVHT_W+W) and TVHT_MODE_4N (TVWT_2W+2W) follows the definition in the second paragraph of 21.3.18.3, where â€œ80 MHzâ€ is replaced by â€œTVHT_Wâ€ for TVHT_MODE_2N and â€œTVHT_2Wâ€ for TVHT_MODE_4N, and uses the values in Table 22-23. 2661 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 22-23â€”Minimum required adjacent and nonadjacent channel rejection levels Adjacent channel rejection (dB) Nonadjacent channel rejection (dB) 6+6 MHz 6 MHz, 7 MHz, (TVHT_MODE 6 MHz, 7 MHz, 6+6 MHz 8 MHz, 12 MHz _2N), 7+7 MHz 8 MHz, 12 MHz (TVHT_MODE_ (TVHT_MODE_ (TVHT_MODE (TVHT_MODE_ 2N), 7+_7 MHz 2C), 14 MHz _2N), 8+8 MHz 2C), 14 MHz (TVHT_MODE_ (TVHT_MODE_ (TVHT_MODE (TVHT_MODE_ 2N), 8+8 MHz Modulation Rate (R) 2C), 16 MHz _2N), 12+12 2C), 16 MHz (TVHT_MODE_ (TVHT_MODE_ MHz (MTVHT_MOD 2N), 12+12 MHz 2C), 24 MHz (TVHT_MODE E_2C), 24 MHz (TVHT_MODE_ (TVHT_MODE_ _4N), 14+14 (TVHT_MODE_ 4N), 14+14 MHz 4C), 28 MHz MHz 4C), 28 MHz (TVHT_MODE_ (TVHT_MODE_ (TVHT_MODE (TVHT_MODE_ 4N), 16+16 MHz 4C), 32 MHz _4N), 16+16 4C), 32 MHz (TVHT_MODE_ (TVHT_MODE_ MHz (TVHT_MODE_ 4N) 4C) (TVHT_MODE 4C) _4N) BPSK 1/2 16 13 32 29 QPSK 1/2 13 10 29 26 QPSK 3/4 11 8 27 24 16-QAM 1/2 8 5 24 21 16-QAM 3/4 4 1 20 17 64-QAM 2/3 0 â€“3 16 13 64-QAM 3/4 â€“1 â€“4 15 12 64-QAM 5/6 â€“2 â€“5 14 11 256-QAM 3/4 â€“7 â€“10 9 6 256-QAM 5/6 â€“9 â€“12 7 4 The definitions in the rest of 21.3.18.3 apply to Clause 22 using the values in Table 22-23. 22.3.18.5 Receiver maximum input level The receiver shall provide a maximum PER of 10% at a PSDU length of 4096 octets, for a maximum input level of â€“20 dBm, measured at each antenna for any baseband TVHT modulation. 22.3.18.6 CCA sensitivity 22.3.18.6.1 General The thresholds in this subclause are compared with the signal level at each receiving antenna. 2662 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 22.3.18.6.2 CCA sensitivity for operating classes requiring CCA-ED For the operating classes requiring CCA-Energy Detect (CCA-ED), the PHY shall also indicate a medium busy condition when CCA-ED detects a channel busy condition. For improved spectrum sharing, CCA-ED is required in some bands. The behavior class indicating CCA-ED is given in Table D-2. The operating classes requiring the corresponding CCA-ED behavior class are given in E.1. The PHY of a STA that is operating within an operating class that requires CCA-ED shall operate with CCA-ED. CCA-ED shall detect a channel busy condition when the received signal strength exceeds the CCA-ED threshold as given by dot11OFDMEDThreshold for the primary TVHT_W channel, dot11OFDMEDThreshold for the secondary TVHT_W channel (if present) and dot11OFDMEDThreshold + 3 dB for the secondary TVHT_2W channel (if present). The CCA-ED thresholds for the operating classes requiring CCA-ED are subject to the criteria in D.2.5. NOTEâ€”The requirement to detect a channel busy condition as stated in 22.3.18.6.3 and 22.3.18.6.4 is a mandatory energy detect requirement on all Clause 22 receivers. Support for CCA-ED is an additional requirement that relates specifically to the sensitivities described in D.2.5. 22.3.18.6.3 CCA sensitivity for signals occupying the primary channel The PHY shall issue a PHY-CCA.indication(BUSY, {primary}) primitive if one of the conditions listed in Table 22-24 is met in an otherwise idle TVHT_W (TVHT_MODE_1), TVHT_2W (TVHT_MODE_2C), TVHT_4W (TVHT_MODE_4C), TVHT_W+W (TVHT_MODE_2N), and TVHT_2W+2W (TVHT_MODE_4N) operating channel width. With >90% probability, the PHY shall detect the start of a PPDU that occupies at least the primary TVHT_W channel under the conditions listed in Table 22-24 within a period of aCCATime (see 22.4.4) and hold the CCA signal busy (PHY-CCA.indication(BUSY, channel- list)) for the duration of the PPDU. Table 22-24â€”Conditions for CCA BUSY on the primary channel Frequency segment width Conditions 6 MHz The start of a 6 MHz non-HT duplicate or VHT PPDU in TVWS bands in the primary 6 MHz channel at or above â€“88 dBm. 7 MHz The start of a 7 MHz non-HT duplicate or VHT PPDU in TVWS bands in the primary 7 MHz channel at or above â€“88 dBm. 8 MHz The start of a 8 MHz non-HT duplicate or VHT PPDU in TVWS bands in the primary 8 MHz channel at or above â€“87 dBm. The receiver shall issue a PHY-CCA.indication(BUSY, {primary}) primitive for any signal that exceeds a threshold equal to 20 dB above the minimum modulation and coding rate sensitivity (â€“88 + 20 = â€“68 dBm in the case of 6 MHz channel) in the primary TVHT_W channel within a period of aCCATime after the signal arrives at the receiverâ€™s antenna(s); then the receiver shall not issue a PHY- CCA.indication(BUSY,{secondary}), PHY-CCA.indication(BUSY,{secondaryTVHT_2W}), or PHY- CCA.indication(IDLE) primitive while the threshold continues to be exceeded. 2663 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 22.3.18.6.4 CCA sensitivity for signals not occupying the primary channel The PHY shall issue a PHY-CCA.indication(BUSY, {secondary}) primitive if the conditions for issuing a PHY-CCA.indication(BUSY, {primary}) primitive are not present and one of the following conditions is present in an otherwise idle TVHT_2W (TVHT_MODE_2C), TVHT_4W (TVHT_MODE_4C), TVHT_W+W (TVHT_MODE_2N), and TVHT_2W+2W (TVHT_MODE_4N) operating channel width: â€” Any signal within the secondary channel at or above a threshold (â€“68 dBm for 6 MHz, â€“68 dBm for 7 MHz, and â€“67 dBm for 8 MHz) within a period of aCCATime after the signal arrives at the receiverâ€™s antenna(s); then the PHY shall not issue a PHY- CCA.indication(BUSY,{secondaryTVHT_2W}) or PHY-CCA.indication(IDLE) primitive while the threshold continues to be exceeded. â€” A TVHT_W non-HT duplicate or VHT PPDU in TVWS bands detected in the secondary channel at or above a threshold (â€“81 dBm for 6 MHz, â€“81 dBm for 7 MHz, and â€“80 dBm for 8 MHz) with >90% probability within a period aCCAMidTime (see 22.4.4). The PHY shall issue a PHY-CCA.indication(BUSY, {secondaryTVHT_2W}) primitive if the conditions for issuing a PHY-CCA.indication(BUSY, {primary}) primitive and a PHY-CCA.indication(BUSY, {secondary}) primitive are not present and one of the following conditions is present in an otherwise idle TVHT_4W (TVHT_MODE_4C) and TVHT_2W+2W (TVHT_MODE_4N) operating channel width: â€” Any signal within the secondary TVHT_2W channel at or above a threshold (â€“65 dBm for 12 MHz, â€“65 dBm for 14 MHz, and â€“64 dBm for 16 MHz) within a period of aCCATime after the signal arrives at the receiverâ€™s antenna(s); then the PHY shall not issue a PHY-CCA.indication(IDLE) primitive while the threshold continues to be exceeded. â€” A TVHT_2W non-HT duplicate or VHT PPDU in TVWS bands detected in the secondary TVHT_2W channel at or above a threshold (â€“78 dBm for 6+6 MHz, â€“78 dBm for 7+7 MHz, and â€“77 dBm for 8+8 MHz or 16 MHz) with >90% probability within a period aCCAMidTime (see 22.4.4). â€” A TVHT_W non-HT duplicate or VHT PPDU in TVWS bands detected in any TVHT_W subchannel of the secondary TVHT_2W channel at or above a threshold (â€“81 dBm for 6 MHz, â€“81 dBm for 7 MHz, and â€“80 dBm for 8 MHz) with >90% probability within a period aCCAMidTime. 22.3.18.7 RSSI See 21.3.18.6 with â€œTVHTâ€ replacing â€œVHTâ€. 22.3.19 PHY transmit procedure See 21.3.19 with â€œTVHTâ€ replacing â€œVHTâ€. 22.3.20 PHY receive procedure See 21.3.20 with â€œTVHTâ€ replacing â€œVHTâ€. 2664 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 22.4 TVHT PLME 22.4.1 PLME SAP sublayer management primitives See 21.4.1 with â€œTVHTâ€ replacing â€œVHTâ€. 22.4.2 PHY MIB See 21.4.2 with â€œtvht(10)â€ replacing â€œvht(9)â€, â€œTVHTâ€ replacing â€œVHTâ€, and â€œIn4Wâ€ replacing â€œIn80â€ and with the removal of â€œdot11VHTShortGIOptionIn160and80p80Implementedâ€ and â€œdot11VHTShortGIOptionIn160and80p80Activatedâ€. 22.4.3 TXTIME and PSDU_LENGTH calculation See 21.4.3 with â€œTVHTâ€ replacing â€œVHTâ€. 22.4.4 TVHT PHY The static TVHT PHY characteristics, provided through the PLME-CHARACTERISTICS service primitive, shall be as shown in Table 19-25 except parameters listed in Table 22-25 and aPreambleLength, aSTFOneLength, aSTFTwoLength, aLTFOneLength, aLTFTwoLength, aPHYHeaderLength, and aPHYSigTwoLength, which are multiplied by 7.5 for 6 MHz and 7 MHz unit channels and by 5.625 for 8 MHz unit channels. The definitions for these characteristics are given in 6.5. Table 22-25â€”TVHT PHY characteristics Characteristics Value aSlotTime 24 Âµs (BCUs: 6 MHz or 7 MHz) plus any coverage-class-dependent aAirPropagationTime (see Table 9-79) 20 Âµs (BCUs: 8 MHz) plus any coverage-class-dependent aAirPropagationTime (see Table 9-79) aSIFSTime 120 Âµs (BCUs: 6 MHz or 7 MHz) 90 Âµs (BCUs: 8 MHz) aSignalExtension 0 Âµs aCCATime < 15 Âµs (6 MHz or 7 MHz) < 11.25 Âµs (8 MHz) aCCAMidTime < 94 Âµs (6 MHz or 7 MHz) < 70 Âµs (8 MHz) aAirPropagationTime As indicated by the coverage class (see 10.21.5) aPPDUMaxTime 20 ms aPSDUMaxLength 1 401 120 octets (see NOTE 1) aRxPHYStartDelay (36 + 4 Ã— the maximum possible value for NVHT-LTF supported + 4) Ã— 7.5 (6 and 7 MHz channels) or 5.625 (8 MHz channels) (see NOTE 2) NOTE 1â€”This is the maximum length in octets for SU PPDUs with a bandwidth of 32 MHz or 16+16 MHz, MCS9 and 4 spatial streams, limited by 973 possible Short GI data symbols in aPPDUMaxTime. NOTE 2â€”This value arises from the time to the end of TVHT-SIG-B (see Figure 22-1) plus the need to decode the first symbol of the Data field in order to extract the SERVICE field and check the CRC it contains. 2665 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 22.5 Parameters for TVHT MCSs The rate-dependent parameters for one BCU mode (6 MHz, 7 MHz, and/or 8 MHz) and corresponding two and four BCU modes with N SS = 1 4 are given in Table 22-26 through Table 22-37. Support for MCS 8 and 9 (when valid) is optional in all cases. A TVHT STA shall support single spatial stream MCSs within the range MCS 0 to MCS 7 for all channel widths for which it has indicated support regardless of the Tx or Rx Highest Supported Data Rate subfield values in the TVHT Supported MCS Set field. When more than one spatial stream is supported, the Tx or Rx Highest Supported Data Rate subfield values in the TVHT Supported MCS Set field may result in a reduced MCS range (cut-off) for N SS = 2 4 . Support for 6 MHz, 7 MHz, or 8 MHz with N SS = 1 is mandatory. Support for 6 MHz, 7 MHz, and 8 MHz with N SS = 2 4 is optional. Support for two BCU modes with 12 MHz, 14 MHz, and 16 MHz or with 6+6 MHz, 7+7 MHz, and 8+8 MHz with N SS = 1 4 is optional. Support for four BCU modes with 24 MHz, 28 MHz, and 32 MHz or with 12+12 MHz, 14+14 MHz, and 16+16 MHz with N SS = 1 4 is optional. NES values were chosen to yield an integer number of punctured blocks per OFDM symbol. Note that N ES values are 1 for all Clause 22 modulations. Table 22-26 through Table 22-37 define TVHT MCSs not only for SU transmission but also for user u of MU transmission. In the case of TVHT MCSs for MU transmission, the parameters, NSS, R, NBPSCS, NCBPS, and NDBPS are replaced with NSS,u, Ru, NBPSCS,u, NCBPS,u, and NDBPS,u, respectively. In the MCS parameter tables that follow, data rates for a 400 ns GI are rounded to 1 decimal place. Table 22-26â€”TVHT MCSs for TVHT_MODE_1, NSS = 1 Data rate Data rate (Mb/s) for (Mb/s) for 6 MHz or 8 MHz MCS 7 MHz Modulation R NBPSCS NSD NSP NCBPS NDBPS Index 6.0 3.0 4.5 2.25 Âµs Âµs Âµs Âµs GI GI GI GI 0 BPSK 1/2 1 108 6 108 54 1.8 2.0 2.4 2.7 1 QPSK 1/2 2 108 6 216 108 3.6 4.0 4.8 5.3 2 QPSK 3/4 2 108 6 216 162 5.4 6.0 7.2 8.0 3 16-QAM 1/2 4 108 6 432 216 7.2 8.0 9.6 10.7 4 16-QAM 3/4 4 108 6 432 324 10.8 12.0 14.4 16.0 5 64-QAM 2/3 6 108 6 648 432 14.4 16.0 19.2 21.3 6 64-QAM 3/4 6 108 6 648 486 16.2 18.0 21.6 24.0 7 64-QAM 5/6 6 108 6 648 540 18.0 20.0 24.0 26.7 8 256-QAM 3/4 8 108 6 864 648 21.6 24.0 28.8 32.0 9 256-QAM 5/6 8 108 6 864 720 24.0 26.7 32.0 35.6 2666 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 22-27â€”TVHT MCSs for TVHT_MODE_1, NSS = 2 Data rate Data rate (Mb/s) for (Mb/s) for 6 MHz or 8 MHz MCS 7 MHz Modulation R NBPSCS NSD NSP NCBPS NDBPS Index 6.0 3.0 4.5 2.25 Âµs Âµs Âµs Âµs GI GI GI GI 0 BPSK 1/2 1 108 6 216 108 3.6 4.0 4.8 5.3 1 QPSK 1/2 2 108 6 432 216 7.2 8.0 9.6 10.7 2 QPSK 3/4 2 108 6 432 324 10.8 12.0 14.4 16.0 3 16-QAM 1/2 4 108 6 864 432 14.4 16.0 19.2 21.3 4 16-QAM 3/4 4 108 6 864 648 21.6 24.0 28.8 32.0 5 64-QAM 2/3 6 108 6 1296 864 28.8 32.0 38.4 42.7 6 64-QAM 3/4 6 108 6 1296 972 32.4 36.0 43.2 48.0 7 64-QAM 5/6 6 108 6 1296 1080 36.0 40.0 48.0 53.3 8 256-QAM 3/4 8 108 6 1728 1296 43.2 48.0 57.6 64.0 9 256-QAM 5/6 8 108 6 1728 1440 48.0 53.3 64.0 71.1 Table 22-28â€”TVHT MCSs for TVHT_MODE_1, NSS = 3 Data rate Data rate (Mb/s) for (Mb/s) for 6 MHz or 8 MHz MCS 7 MHz Modulation R NBPSCS NSD NSP NCBPS NDBPS Index 6.0 3.0 4.5 2.25 Âµs Âµs Âµs Âµs GI GI GI GI 0 BPSK 1/2 1 108 6 324 162 5.4 6.0 7.2 8.0 1 QPSK 1/2 2 108 6 648 324 10.8 12.0 14.4 16.0 2 QPSK 3/4 2 108 6 648 486 16.2 18.0 21.6 24.0 3 16-QAM 1/2 4 108 6 1296 648 21.6 24.0 28.8 32.0 4 16-QAM 3/4 4 108 6 1296 972 32.4 36.0 43.2 48.0 5 64-QAM 2/3 6 108 6 1944 1296 43.2 48.0 57.6 64.0 6 64-QAM 3/4 6 108 6 1944 1458 48.6 54.0 64.8 72.0 7 64-QAM 5/6 6 108 6 1944 1620 54.0 60.0 72.0 80.0 8 256-QAM 3/4 8 108 6 2592 1944 64.8 72.0 86.4 96.0 9 256-QAM 5/6 8 108 6 2592 2160 72.0 80.0 96.0 106.7 2667 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 22-29â€”TVHT MCSs for TVHT_MODE_1, NSS = 4 Data rate Data rate (Mb/s) for (Mb/s) for 6 MHz or 8 MHz MCS 7 MHz Modulation R NBPSCS NSD NSP NCBPS NDBPS Index 6.0 3.0 4.5 2.25 Âµs Âµs Âµs Âµs GI GI GI GI 0 BPSK 1/2 1 108 6 432 216 7.2 8.0 9.6 10.7 1 QPSK 1/2 2 108 6 864 432 14.4 16.0 19.2 21.3 2 QPSK 3/4 2 108 6 864 648 21.6 24.0 28.8 32.0 3 16-QAM 1/2 4 108 6 1728 864 28.8 32.0 38.4 42.7 4 16-QAM 3/4 4 108 6 1728 1296 43.2 48.0 57.6 64.0 5 64-QAM 2/3 6 108 6 2592 1728 57.6 64.0 76.8 85.3 6 64-QAM 3/4 6 108 6 2592 1944 64.8 72.0 86.4 96.0 7 64-QAM 5/6 6 108 6 2592 2160 72.0 80.0 96.0 106.7 8 256-QAM 3/4 8 108 6 3456 2592 86.4 96.0 115.2 128.0 9 256-QAM 5/6 8 108 6 3456 2880 96.0 106.7 128.0 142.2 Table 22-30â€”TVHT MCSs for TVHT_MODE_2C and TVHT_MODE_2N, NSS = 1 Data rate Data rate (Mb/s) for (Mb/s) for 6 MHz or 8 MHz MCS 7 MHz Modulation R NBPSCS NSDâˆ™NSeg NSP NCBPS NDBPS Index 6.0 3.0 4.5 2.25 Âµs Âµs Âµs Âµs GI GI GI GI 0 BPSK 1/2 1 216 12 216 108 3.6 4.0 4.8 5.3 1 QPSK 1/2 2 216 12 432 216 7.2 8.0 9.6 10.7 2 QPSK 3/4 2 216 12 432 324 10.8 12.0 14.4 16.0 3 16-QAM 1/2 4 216 12 864 432 14.4 16.0 19.2 21.3 4 16-QAM 3/4 4 216 12 864 648 21.6 24.0 28.8 32.0 5 64-QAM 2/3 6 216 12 1296 864 28.8 32.0 38.4 42.7 6 64-QAM 3/4 6 216 12 1296 972 32.4 36.0 43.2 48.0 7 64-QAM 5/6 6 216 12 1296 1080 36.0 40.0 48.0 53.3 8 256-QAM 3/4 8 216 12 1728 1296 43.2 48.0 57.6 64.0 9 256-QAM 5/6 8 216 12 1728 1440 48.0 53.3 64.0 71.1 2668 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 22-31â€”TVHT MCSs for TVHT_MODE_2C and TVHT_MODE_2N, NSS = 2 Data rate Data rate (Mb/s) for (Mb/s) for 6 MHz or 8 MHz MCS NSDâˆ™ 7 MHz Modulation R NBPSCS NSP NCBPS NDBPS Index NSeg 6.0 3.0 4.5 2.25 Âµs Âµs Âµs Âµs GI GI GI GI 0 BPSK 1/2 1 216 12 432 216 7.2 8.0 9.6 10.7 1 QPSK 1/2 2 216 12 864 432 14.4 16.0 19.2 21.3 2 QPSK 3/4 2 216 12 864 648 21.6 24.0 28.8 32.0 3 16-QAM 1/2 4 216 12 1728 864 28.8 32.0 38.4 42.7 4 16-QAM 3/4 4 216 12 1728 1296 43.2 48.0 57.6 64.0 5 64-QAM 2/3 6 216 12 2592 1728 57.6 64.0 76.8 85.3 6 64-QAM 3/4 6 216 12 2592 1944 64.8 72.0 86.4 96.0 7 64-QAM 5/6 6 216 12 2592 2160 72.0 80.0 96.0 106.7 8 256-QAM 3/4 8 216 12 3456 2592 86.4 96.0 115.2 128.0 9 256-QAM 5/6 8 216 12 3456 2880 96.0 106.7 128.0 142.2 Table 22-32â€”TVHT MCSs for TVHT_MODE_2C and TVHT_MODE_2N, NSS = 3 Data rate Data rate (Mb/s) for (Mb/s) for 6 MHz or 8 MHz MCS NSDâˆ™ 7 MHz Modulation R NBPSCS NSP NCBPS NDBPS Index NSeg 6.0 3.0 4.5 2.25 Âµs Âµs Âµs Âµs GI GI GI GI 0 BPSK 1/2 1 216 12 648 324 10.8 12.0 14.4 16.0 1 QPSK 1/2 2 216 12 1296 648 21.6 24.0 28.8 32.0 2 QPSK 3/4 2 216 12 1296 972 32.4 36.0 43.2 48.0 3 16-QAM 1/2 4 216 12 2592 1296 43.2 48.0 57.6 64.0 4 16-QAM 3/4 4 216 12 2592 1944 64.8 72.0 86.4 96.0 5 64-QAM 2/3 6 216 12 3888 2592 86.4 96.0 115.2 128.0 6 64-QAM 3/4 6 216 12 3888 2916 97.2 108.0 129.6 144.0 7 64-QAM 5/6 6 216 12 3888 3240 108. 120.0 144.0 160.0 8 256-QAM 3/4 8 216 12 5184 3888 129.6 144.0 172.8 192.0 9 256-QAM 5/6 8 216 12 5184 4320 144.0 160.0 192.0 213.3 2669 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 22-33â€”TVHT MCSs for TVHT_MODE_2C and TVHT_MODE_2N, NSS = 4 Data rate Data rate (Mb/s) for (Mb/s) for 6 MHz or 8 MHz MCS NSDâˆ™ 7 MHz Modulation R NBPSCS NSP NCBPS NDBPS Index NSeg 6.0 3.0 4.5 2.25 Âµs Âµs Âµs Âµs GI GI GI GI 0 BPSK 1/2 1 216 12 864 432 14.4 16.0 19.2 21.3 1 QPSK 1/2 2 216 12 1728 864 28.8 32.0 38.4 42.7 2 QPSK 3/4 2 216 12 1728 1296 43.2 48.0 57.6 64.0 3 16-QAM 1/2 4 216 12 3456 1728 57.6 64.0 76.8 85.3 4 16-QAM 3/4 4 216 12 3456 2592 86.4 96.0 115.2 128.0 5 64-QAM 2/3 6 216 12 5184 3456 115.2 128.0 153.6 170.7 6 64-QAM 3/4 6 216 12 5184 3888 129.6 144.0 172.8 192.0 7 64-QAM 5/6 6 216 12 5184 4320 144.0 160.0 192.0 213.3 8 256-QAM 3/4 8 216 12 6912 5184 172.8 192.0 230.4 256.0 9 256-QAM 5/6 8 216 12 6912 5760 192.0 213.3 256.0 284.4 Table 22-34â€”TVHT MCSs for TVHT_MODE_4C and TVHT_MODE_4N, NSS = 1 Data rate Data rate (Mb/s) for (Mb/s) for 6 MHz or 8 MHz MCS 7 MHz Modulation R NBPSCS NSD NSP NCBPS NDBPS Index 6.0 3.0 4.5 2.25 Âµs Âµs Âµs Âµs GI GI GI GI 0 BPSK 1/2 1 432 24 432 216 7.2 8.0 9.6 10.7 1 QPSK 1/2 2 432 24 864 432 14.4 16.0 19.2 21.3 2 QPSK 3/4 2 432 24 864 648 21.6 24.0 28.8 32.0 3 16-QAM 1/2 4 432 24 1728 864 28.8 32.0 38.4 42.7 4 16-QAM 3/4 4 432 24 1728 1296 43.2 48.0 57.6 64.0 5 64-QAM 2/3 6 432 24 2592 1728 57.6 64.0 76.8 85.3 6 64-QAM 3/4 6 432 24 2592 1944 64.8 72.0 86.4 96.0 7 64-QAM 5/6 6 432 24 2592 2160 72.0 80.0 96.0 106.7 8 256-QAM 3/4 8 432 24 3456 2592 86.4 96.0 115.2 128.0 9 256-QAM 5/6 8 432 24 3456 2880 96.0 106.7 128.0 142.2 2670 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 22-35â€”TVHT MCSs for TVHT_MODE_4C and TVHT_MODE_4N, NSS = 2 Data rate Data rate (Mb/s) for (Mb/s) for 6 MHz or 8 MHz MCS 7 MHz Modulation R NBPSCS NSD NSP NCBPS NDBPS Index 6.0 3.0 4.5 2.25 Âµs Âµs Âµs Âµs GI GI GI GI 0 BPSK 1/2 1 432 24 864 432 14.4 16.0 19.2 21.3 1 QPSK 1/2 2 432 24 1728 864 28.8 32.0 38.4 42.7 2 QPSK 3/4 2 432 24 1728 1296 43.2 48.0 57.6 64.0 3 16-QAM 1/2 4 432 24 3456 1728 57.6 64.0 76.8 85.3 4 16-QAM 3/4 4 432 24 3456 2592 86.4 96.0 115.2 128.0 5 64-QAM 2/3 6 432 24 5184 3456 115.2 128.0 153.6 170.7 6 64-QAM 3/4 6 432 24 5184 3888 129.6 144.0 172.8 192.0 7 64-QAM 5/6 6 432 24 5184 4320 144.0 160.0 192.0 213.3 8 256-QAM 3/4 8 432 24 6912 5184 172.8 192.0 230.4 256.0 9 256-QAM 5/6 8 432 24 6912 5760 192.0 213.3 256.0 284.4 Table 22-36â€”TVHT MCSs for TVHT_MODE_4C and TVHT_MODE_4N, NSS = 3 Data rate Data rate (Mb/s) for (Mb/s) for 6 MHz or 8 MHz MCS 7 MHz Modulation R NBPSCS NSD NSP NCBPS NDBPS Index 6.0 3.0 4.5 2.25 Âµs Âµs Âµs Âµs GI GI GI GI 0 BPSK 1/2 1 432 24 1296 648 21.6 24.0 28.8 32.0 1 QPSK 1/2 2 432 24 2592 1296 43.2 48.0 57.6 64.0 2 QPSK 3/4 2 432 24 2592 1944 64.8 72.0 86.4 96.0 3 16-QAM 1/2 4 432 24 5184 2592 86.4 96.0 115.2 128.0 4 16-QAM 3/4 4 432 24 5184 3888 129.6 144.0 172.8 192.0 5 64-QAM 2/3 6 432 24 7776 5184 172.8 192.0 230.4 256.0 6 64-QAM 3/4 6 432 24 7776 5832 194.4 216.0 259.2 288.0 7 64-QAM 5/6 6 432 24 7776 6480 216.0 240.0 288.0 320.0 8 256-QAM 3/4 8 432 24 10 368 7776 259.2 288.0 345.6 384.0 9 256-QAM 5/6 8 432 24 10 368 8640 288.0 320.0 384.0 426.7 2671 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table 22-37â€”TVHT MCSs for TVHT_MODE_4C and TVHT_MODE_4N, NSS = 4 Data rate Data rate (Mb/s) for (Mb/s) for 6 MHz or 8 MHz MCS 7 MHz Modulation R NBPSCS NSD NSP NCBPS NDBPS Index 6.0 3.0 4.5 2.25 Âµs Âµs Âµs Âµs GI GI GI GI 0 BPSK 1/2 1 432 24 1728 864 28.8 32.0 38.4 42.7 1 QPSK 1/2 2 432 24 3456 1728 57.6 64.0 76.8 85.3 2 QPSK 3/4 2 432 24 3456 2592 86.4 96.0 115.2 128.0 3 16-QAM 1/2 4 432 24 6912 3456 115.2 128.0 153.6 170.7 4 16-QAM 3/4 4 432 24 6912 5184 172.8 192.0 230.4 256.0 5 64-QAM 2/3 6 432 24 10 368 6912 230.4 256.0 307.2 341.3 6 64-QAM 3/4 6 432 24 10 368 7776 259.2 288.0 345.6 384.0 7 64-QAM 5/6 6 432 24 10 368 8640 288.0 320.0 384.0 426.7 8 256-QAM 3/4 8 432 24 13 824 10 368 345.6 384.0 460.8 512.0 9 256-QAM 5/6 8 432 24 13 824 11 520 384.0 426.7 512.0 568.9 2672 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Annex A (informative) Bibliography Bibliographical references are resources that provide additional or helpful material but do not need to be understood or used to implement this standard. Reference to these resources is made for informational use only. [B1] 3GPP TS 23.167, IMS emergency sessions architecture: http://www.3gpp.org/ftp/Specs/html-info/ 23167.htm. [B2] 3GPP TR 21.905, Vocabulary for 3GPP Specifications.49 [B3] 3GPP TS 22.067: Enhanced Multi-Level Precedence and Pre-emption service (EMLPP); Stage 1. [B4] 3GPP2 X.S0060-0 IMS emergency sessions architecture: http://www.3gpp2.org/Public_html/specs/ X.S0060-0_v1.0_080729.pdf. [B5] ANSI Z136.1-1993, American National Standard for the Safe Use of Lasers.50 [B6] Arazi, E. G., A Commonsense Approach to the Theory of Error Correcting Codes, MIT Press, 1988. [B7] ARIB RCR STD-33 (5.0), Low Power Data Communication/Wireless LAN System, ARIB, Feb. 1999.51 [B8] ARIB STD-T71 (5.0), Broadband Mobile Access Communication System (CSMA), ARIB, Dec. 2007. [B9] Code of Federal Regulations (CFR), Title 47, Telecommunication, Oct. 2001.52 [B10] Code of Federal Regulations, Title 47, Telecommunication, Part 90, Private Land Mobile Radio Services, Section 90.210(m), Emission masks. [B11] Engwer, D., and Zweig, J., â€œAlgorithmically Derived Hop Sequences,â€ submission 99/195 to the IEEE P802.11 Working Group, Sept. 1999. [B12] â€œEthernet, a local area network: Data link layer and physical layer specifications version 1.0.â€ Digital Equipment Corporation, Intel Corporation, Xerox Corporation, Sept. 1980. [B13] ETSI EN 300 328, Electromagnetic compatibility and Radio spectrum Matters (ERM); Wideband transmission systems; Data transmission equipment operating in the 2,4 GHz ISM band and using wide band modulation techniques; Harmonized EN covering essential requirements under article 3.2 of the R&TTE Directive.53 493GPP documents are available from the 3rd Generation Partnership Project Web site (http://www.3gpp.org). 50 ANSI publications are available from the American National Standards Institute (http://www.ansi.org). 51 ARIB publications are available from the Association of Radio Industries and Businesses (www.arib.or.jp). 52The CFR is available from the U.S. Government Printing Office (www.gpo.gov). 53 ETSI publications are available from the European Telecommunications Standards Institute (www.etsi.org). 2673 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications [B14] ETSI EN 302 571 V1.1.1 (2008-09), Intelligent Transport Systems (ITS); Radiocommunications equipment operating in the 5 855 MHz to 5 925 MHz frequency band; Harmonized EN covering the essential requirements of article 3.2 of the R&TTE Directive. [B15] ETSI ES 202 663 V1.1.0 (2010-01), Intelligent Transport Systems (ITS); European profile standard for the physical and medium access control layer of Intelligent Transport Systems operating in the 5 GHz frequency band. [B16] GSMA, IR.34 v4.6, Inter-Service provider IP Backbone Guidelines, http://gsmworld.com/documents/ IR3446.pdf, Apr. 2009. [B17] IANA Protocol Assignments for the Internet Key Exchange (IKE) Attributes, http://www.iana.org/ assignments/ipsec-registry. [B18] IEC 60825-1:1993, Safety of laser productsâ€”Part 1: Equipment classification, requirements and userâ€™s guide.54 [B19] IEEE Standards Registration Authorityâ€”Frequently Asked Questions.55 [B20] IEEE Standards Registration Authorityâ€”Guidelines for Use Organizationally Unique Identifier (OUI) and Company ID (CID). [B21] IEEE Std 1609.0â„¢-2013, IEEE Guide for Wireless Access in Vehicular Environments (WAVE)â€” Architecture.56,57 [B22] IEEE Std 802.1ACâ„¢-2012, IEEE Standard for Local and metropolitan area networksâ€”Media Access Control (MAC) Service Definition. [B23] IEEE Std 802.1Dâ„¢-2004, IEEE Standard for Local and metropolitan area networksâ€”Media Access Control (MAC) Bridges. [B24] IEEE Std 802.1Hâ„¢-1995, IEEE Standards for Local and metropolitan area networksâ€” Recommended Practice for Media Access Control (MAC) Bridging of Ethernet V2.0 in IEEE 802 Local Area Networks [now known as ISO/IEC Technical Report 11802-5:1997; see Clause 2]. [B25] IETF ECRIT, Extended ECRIT architecture supporting unauthenticated emergency services, http:// tools.ietf.org/html/draft-schulzrinne-ecrit-unauthenticated-access. [B26] IETF RFC 1157, Simple Network Management Protocol (SNMP), J. Case, M. Fedor, M. Schoffstall, and J. Davin, May 1990.58 [B27] IETF RFC 1305, Network Time Protocol (Version 3) Specification, Implementation and Analysis. [B28] IETF RFC 2202, Test Cases for HMAC-MD5 and HMAC-SHA-1, P. Cheng and R. Glenn, Sept. 1997 (status: informational). 54IEC publications are available from the International Electrotechnical Commission (http://www.iec.ch/). IEC publications are also available in the United States from the American National Standards Institute (http://www.ansi.org). 55 This document is available from The Institute of Electrical and Electronics Engineers (http://standards.ieee.org/regauth/faqs.html). 56 The IEEE standards or products referred to in this annex are trademarks owned by The Institute of Electrical and Electronics Engineers, Inc. 57IEEE publications are available from The Institute of Electrical and Electronics Engineers (http://standards.ieee.org/). 58 IETF documents (i.e., RFCs) are available for download at http://www.rfc-archive.org/. 2674 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications [B29] IETF RFC 2212, Specification of the Guaranteed Quality of Service. [B30] IETF RFC 2215, General Characterization Parameters for Integrated Service Network Elements. [B31] IETF RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. [B32] IETF RFC 2548, Microsoft Vendor-specific RADIUS Attributes. [B33] IETF RFC 2865, Remote Authentication Dial in User Service (RADIUS). [B34] IETF RFC 2898, PKCS #5: Password-Based Cryptography Specification Version 2.0 [B35] IETF RFC 2903, Generic AAA architecture, C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, and D. Spence, Aug. 2000 (status informational). [B36] IETF RFC 3222, Terminology for Forwarding Information Base (FIB) based Router Performance. [B37] IETF RFC 3290, An Informal Management Model for Diffserv Routers. [B38] IETF RFC 3561, Ad hoc On-Demand Distance Vector (AODV) Routing, C. Perkins, E. Belding- Royer, and S. Das, July 2003. (status: experimental). [B39] IETF RFC 3580, IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines, P. Congdon, B. Aboba, A. Smith, G. Zorn, and J. Roese, Sept. 2003. [B40] IETF RFC 3588, Diameter Base Protocol. [B41] IETF RFC 3693, Geopriv Requirements, Feb. 2004. [B42] IETF RFC 3748, Extensible Authentication Protocol (EAP). [B43] IETF RFC 4493, The AES-CMAC Algorithm. [B44] IETF RFC 4776, Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information, H. Schulzrinne, Nov. 2006. [B45] IETF RFC 4862, IPv6 Stateless Address Autoconfiguration, S. Thomson, T. Narten, T. Jinmei, Sept. 2007. [B46] IETF RFC 5031, A Uniform Resource Name (URN) for Emergency and Other Well-Known Services, H. Schulzrinne, Jan. 2008. [B47] IETF RFC 5139, Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO), M. Thomson, Feb. 2008. [B48] International Code Council, Inc., International Building Code 2006, Nov. 2006, ISBN-13: 978-1- 58001-251-5. [B49] ISO/IEC 14977:1996, Information technology â€” Syntactic metalanguage â€” Extended BNF.59 59 ISO/IEC publications are available from the ISO Central Secretariat (http://www.iso.ch/). ISO/IEC publications are also available in the United States from the American National Standards Institute (http://www.ansi.org/). 2675 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications [B50] ITU Radio Regulations, volumes 1â€“4.60 [B51] ITU-R Recommendation TF.460-6 (2002), Standard-Frequency and Time-Signal Emissions. [B52] ITU-T Recommendation V.41 (11/88), Code-independent error-control system. [B53] ITU-T Recommendation V.42, Error-correcting procedures for DCEs using asynchronous-to- synchronous conversion. [B54] ITU-T Recommendation X.210 (11/93), Information technologyâ€”Open systems interconnectionâ€” Basic Reference Model: Conventions for the definition of OSI services (common text with ISO/IEC 10731). [B55] Maric, S. V., and Titlebaum, E. L., â€œA Class of Frequency Hop Codes with Nearly Ideal Characteristics for Use in Multiple-Access Spread-Spectrum Communications and Radar and Sonar Systems,â€ IEEE Transactions on Communications, vol. 40, no. 9, pp. 1442â€“1447, Sept. 1992. [B56] NENA 08-002, Functional and Interface Standards for Next Generation 9-1-1 (i3), ver. 1.0, http:// www.nena.org/standards/technical/voip/functional-interface-NG911-i3. [B57] Rumbaugh, J., Jacobson, I., and Booch, G., The Unified Modeling Language (UML) Reference Manual (Second Edition), Reading, MA: Addison-Wesley Longman, 2004. 60 ITU, ITU-R, and ITU-T publications are available from the International Telecommunications Union (http://www.itu.int/). 2676 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Annex B (normative) Protocol Implementation Conformance Statement (PICS) proforma B.1 Introduction The supplier of a protocol implementation that is claimed to comply with IEEE Std 802.11-2016 shall complete the following protocol implementation conformance statement (PICS) proforma. A completed PICS proforma is the PICS for the implementation in question. The PICS is a statement of which capabilities and options of the protocol have been implemented. This annex might not be compatible with operation in any Regulatory Domain or describe combinations of usable features in any Regulatory Domain. The PICS has a number of uses, including use: a) By the protocol implementer, as a checklist to reduce the risk of failure to comply with the standard through oversight; b) By the supplier and acquirer, or potential acquirer, of the implementation, as a detailed indication of the capabilities of the implementation, stated relative to the common basis for understanding provided by the standard PICS proforma; c) By the user, or potential user, of the implementation, as a basis for initially checking the possibility of interworking with another implementation (note that, while interworking is not guaranteed, failure to interwork can often be predicted from incompatible PICS proformas); d) By a protocol tester, as the basis for selecting appropriate tests against which to assess the claim for compliance of the implementation. B.2 Abbreviations and special symbols B.2.1 Symbols for Status column M mandatory O optional O. optional â€” Support of at least one of the group of options labeled by the same numeral is required. The scope of the group of options is limited to a single table (i.e., subclause) within the PICS. pred: predicate identification B.2.2 General abbreviations for Item and Support columns N/A not applicable AD address function AVT audio video transport CF implementation under test (IUT) configuration DMG-M directional multi-gigabit (DMG) medium access control (MAC) features DMG-P directional multi-gigabit (DMG) physical layer (PHY) features DS direct sequence DSE dynamic station enablement 2677 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ERP extended rate physical layer (PHY) FR frame reception FS frame exchange sequence FT frame transmission HRDS high rate direct sequence HTM high-throughput (HT) medium access control (MAC) features HTP high-throughput (HT) physical layer (PHY) features HWM hybrid wireless mesh protocol (HWMP) path selection protocol capability IW interworking with external networks MD multidomain MP mesh protocol OC operating classes OF orthogonal frequency division multiplexing (OFDM) PC protocol capability RM radio management QB quality-of-service (QoS) base functionality QD quality-of-service (QoS) enhanced distributed channel access (EDCA) QMF quality-of-service Management frame QP quality-of-service (QoS) hybrid coordination function (HCF) controlled channel access (HCCA) SM spectrum management TDLS tunneled direct-link setup TVHTM television very high throughput medium access control (MAC) features TVHTP television very high throughput physical layer (PHY) features TVWS television white spaces VHTM Very high throughput MAC VHTP Very high throughput PHY WNM wireless network management WS white spaces B.3 Instructions for completing the PICS proforma B.3.1 General structure of the PICS proforma The first parts of the PICS proforma, Implementation identification and Protocol summary, are to be completed as indicated with the information necessary to identify fully both the supplier and the implementation. The main part of the PICS proforma is a fixed questionnaire, divided into subclauses, each containing a number of individual items. Answers to the questionnaire items are to be provided in the rightmost column, either by simply marking an answer to indicate a restricted choice (usually Yes or No) or by entering a value or a set or a range of values. (Note that there are some items where two or more choices from a set of possible answers may apply. All relevant choices are to be marked in these cases.) Each item is identified by an item reference in the first column. The second column contains the question to be answered. The third column contains the reference or references to the material that specifies the item in the main body of this standard. The remaining columns record the status of each item, i.e., whether support is mandatory, optional, or conditional, and provide the space for the answers (see also B.3.4). Marking an item as supported is to be interpreted as a statement that all relevant requirements of the subclauses and normative annexes, cited in the References column for the item, are met by the implementation. 2678 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A supplier may also provide, or be required to provide, further information, categorized as either Additional Information or Exception Information. When present, each kind of further information is to be provided in a further subclause of items labeled A or X, respectively, for cross-referencing purposes, where is any unambiguous identification for the item (e.g., simply a numeral). There are no other restrictions on its format or presentation. A completed PICS proforma, including any Additional Information and Exception Information, is the PICS for the implementation in question. NOTEâ€”Where an implementation is capable of being configured in more than one way, a single PICS might be able to describe all such configurations. However, the supplier has the choice of providing more than one PICS, each covering some subset of the implementationâ€™s capabilities, if this makes for easier and clearer presentation of the information. B.3.2 Additional information Items of Additional Information allow a supplier to provide further information intended to assist in the interpretation of the PICS. It is not intended or expected that a large quantity of information will be supplied, and a PICS can be considered complete without any such information. Examples of such Additional Information might be an outline of the ways in which an (single) implementation can be set up to operate in a variety of environments and configurations, or information about aspects of the implementation that are outside the scope of this standard but have a bearing upon the answers to some items. References to items of Additional Information may be entered next to any answer in the questionnaire, and may be included in items of Exception Information. B.3.3 Exception information It may happen occasionally that a supplier wishes to answer an item with mandatory status (after any conditions have been applied) in a way that conflicts with the indicated requirement. No preprinted answer is found in the Support column for this. Instead, the supplier shall write the missing answer into the Support column, together with an X reference to an item of Exception Information, and shall provide the appropriate rationale in the Exception Information item itself. An implementation for which an Exception Information item is required in this way does not comply with this standard. NOTEâ€”A possible reason for the situation described above is that a defect in this standard has been reported, a correction for which is expected to change the requirement not met by the implementation. B.3.4 Conditional status The PICS proforma contains a number of conditional items. These are items for which both the applicability of the item itself, and its status if it does apply, mandatory or optional, are dependent upon whether certain other items are supported. Where a group of items is subject to the same condition for applicability, a separate preliminary question about the condition appears at the head of the group, with an instruction to skip to a later point in the questionnaire if the N/A answer is selected. Otherwise, individual conditional items are indicated by a conditional symbol in the Status column. A conditional symbol is of the form â€œ:â€ or â€œOâ€ (or â€œO.â€), where â€œâ€ is a predicate as described below, and â€œâ€ is one of the status symbols â€œMâ€ or â€œOâ€ (or â€œO.â€). 2679 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If the value of a predicate is true, the conditional symbol is applicable, and yields the status given by S. If any applicable conditional symbol yields mandatory status, the conditional item has mandatory status. Otherwise, if any applicable conditional symbol (including one of the form â€œOâ€ (or â€œO.â€)) yields optional status, the conditional item has optional status. In either case, the support column is to be completed in the usual way. If no conditional symbol is applicable, the conditional item is not relevant and the N/A answer is to be marked. A predicate is one of the following: a) An item-reference for an item in the PICS proforma: the value of the predicate is true if the item is marked as supported and is false otherwise. b) An expression constructed by combining item-references using the boolean operators (in decreasing order of precedence) â€œNOTâ€, â€œANDâ€, and â€œORâ€, with or without the use of parenthetical groupings: the value of the predicate is true if the expression evaluates to true and is false otherwise. NOTEâ€”If optional feature F1 requires features F2 and F3, this can be represented in the PICS in one of two ways: â€” The status for conditional items F2 and F3 is â€œF1:Mâ€ and the status for conditional item F1 is â€œOâ€, or â€” The status for conditional item F1 is â€œF2 AND F3:Oâ€. If feature F1 is required if feature F2 or F3 is supported, and is optional otherwise, this can be represented in the PICS in one way: â€” The status for conditional item F1 is â€œF2 OR F3:Mâ€ and â€œOâ€. If feature F1 is required if feature F2 or F3 is supported, and is not relevant otherwise, this can be represented in the PICS in one way: â€” The status for conditional item F1 is â€œF2 OR F3:Mâ€. If feature F1 is required if feature F2 is supported, is optional if feature F3 is supported, and is not relevant otherwise, this can be represented in the PICS in one way: â€” The status for conditional item F1 is â€œF2:Mâ€ and â€œF3:Oâ€. Conditional symbols can be given in any order. Each item referenced in a predicate, or in a preliminary question for grouped conditional items, is indicated by an asterisk in the Item column. 2680 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4 PICS proformaâ€”IEEE Std 802.11-201661 B.4.1 Implementation identification Supplier Contact point for queries about the PICS Implementation Name(s) and Version(s) Other information necessary for full identification, e.g., name(s) and version(s) of the machines and/or operating system(s), system names NOTE 1â€”Only the first three items are required for all implementations. Other information might be completed as appropriate in meeting the requirement for full identification. NOTE 2â€”The terms Name and Version need to be interpreted appropriately to correspond with a supplierâ€™s terminology (e.g., Type, Series, Model). B.4.2 Protocol summary Identification of protocol standard IEEE Std 802.11-2016 Identification of amendments and corrigenda to this Amd. : Corr. : PICS proforma that have been completed as part of this PICS Amd. : Corr. : Have any exception items been required? Yes No (See B.3.3; the answer Yes means that the implementation does not comply with IEEE Std 802.11- 2016.) Date of statement (yyyy-mm-dd) 61 Copyright release for PICS proforma: Users of this standard may freely reproduce the PICS proforma in this annex so that it can be used for its intended purpose and may further publish the completed PICS. 2681 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.3 IUT configuration Item IUT configuration References Status Support What is the configuration of the IUT? * CFAP Access point (AP) 4.3 O.1 Yes No * Independent station (neither an AP, nor a 4.3 O.1 Yes No CFIndepSTA mesh STA, nor a STA operating outside the context of a BSS) *CFSTAofA Operation in an infrastructure BSS 4.3 CFIndepSTA: Yes No N/A P M *CFIBSS Operation in an independent BSS (IBSS) 4.3 CFIndepSTA: Yes No N/A O *CF2.3 Reserved *CFPBSS Operation in a PBSS 4.3.3 CFIndepSTA AND CFDMG:M CFDMG:O.7 *CFPCP Operation as a PCP 4.3.3 CFPBSS:M Yes No *CFPBSSnot Operation not as a PCP 4.3.3 CFPBSS:M Yes No PCP NOTEâ€”See CFMBSS for mesh STA and CFOCB for OCB operation. CF3 Reserved * CFDSSS Direct sequence spread spectrum (DSSS) â€” O.2 Yes No PHY for the 2.4 GHz band CFHRDSSS: M CF5 Reserved * CFOFDM Orthogonal frequency division â€” O.2 Yes No multiplexing (OFDM) PHY CFHT5G:M CFTVHT:M * High rate direct sequence spread â€” O.2 Yes No CFHRDSSS spectrum (HR/DSSS) PHY CFERP:M * CFMD Multidomain operation capability 10.21 O Yes No implemented * CFERP Extended Rate PHY (ERP) 18 O.2 Yes No CF2G4:M * CFSM Spectrum management 9.4.1.4, O Yes No 11.8, 11.9 *CFOC Operating classes capability 9.4.2.10, O Yes No N/A implemented 17.3.8.4.2, 17.3.8.6, 17.4.2 Annex D, Annex E 2682 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.3 IUT configuration (continued) Item IUT configuration References Status Support * CFQoS Quality of service (QoS) 10.22, O Yes No N/A 10.24, 4.3.13, CFHT OR 4.3.20.3 CFMBSS OR CFQMF OR CFAVT:M CFDMG:M CFTVHT:M * CFRM Radio Measurement 9.4.1.4, (CFMD AND Yes No N/A 11.11 CFOC):O *CFInfraST Infrastructure mode 4.3.4 CFAP OR Yes No N/A A CFSTAofAP: M CFDMG:O.7 *CF3G6 3.65â€“3.70 GHz band in the United States 9.4.2.52, CFOFDM Yes No N/A 11.12, AND CFMD 17.3.6, AND CFSM 17.3.10.6, AND CFOC:O Annex D, Annex E *CFHT High-throughput (HT) PHY 9.4.2.56 O.2 Yes No CFVHT:M * CFHT2G4 HT operation in 2.4 GHz band 19 CFHT:O.6 Yes No N/A * CFHT5G HT operation in 5 GHz band 19 CFHT:O.6 Yes No N/A CFVHT:M *CF5G9 5.9 GHz band Annex E CFOFDM:O Yes No N/A *CFTDLS Tunneled direct-link setup supported 11.23 O Yes No N/A *CFWNM Wireless network management (WNM) ((CFMD AND Yes No N/A CFOC AND CFRM):O *CFIW Interworking with external networks 9.4.2.27 O Yes No service *CFMBSS Operation in a mesh BSS (MBSS) 4.3.20 (NOT Yes No N/A CFDMG):O.1 *CFQMF QoS management frame (QMF) policy 11.26 O Yes No N/A *CFAVT Robust audio/video transport (AVT) 4.3.23 O Yes No CF24 Reserved *CFDMG Directional multi-gigabit (DMG) PHY 9.4.2.128 O.2 Yes No CFDMG:M *CFMBO Multi-band operation 9.6.21, At least two of Yes No N/A 11.32 CFDSSS, CFOFDM, CF3G6, CF5G9, CFDMG:O *CFVHT Very High Throughput (VHT) features 9.4.2.158 O.2 Yes No *CFTVHT TVWS Operation Annex D, O Yes No Annex E 2683 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.3 IUT configuration (continued) Item IUT configuration References Status Support *CFOCB Operation outside the context of a BSS 11.21 O.1 Yes No (OCB) CF5G9:M *CFESM Extended spectrum management 10.21.3 O Yes No CFVHT OR CFTVHT:M B.4.4 MAC protocol B.4.4.1 MAC protocol capabilities Item Protocol capability References Status Support Are the following MAC protocol capabilities supported? PC1 Authentication service 4.5.4.2, 4.5.4.3, CFInfraSTA Yes No N/A 11.21, 12.2 AND not CFDMG:M CFIBSS OR CFDMG:M PC1.1 Authentication state 11.3 PC1:M Yes No PC1.2 Open System authentication 12.2.2 PC1 AND not Yes No CFDMG:M PC1.3 Shared Key authentication 12.2.3, 12.5 PC2:M Yes No N/A * PC2 Wired equivalent privacy (WEP) 4.5.4.4, 12.3.2 O Yes No algorithm This capability is deprecated (applicable only to systems that are backward compatible). PC2.1 WEP encryption procedure 12.3.2 PC2:M Yes No N/A PC2.2 WEP decryption procedure 12.3.2 PC2:M Yes No N/A PC3 Distributed coordination function 10.2, 10.3 M Yes No (DCF) PC3.1 Network allocation vector 10.3.2.1, 10.3.4, M Yes No (NAV) function 10.4.3.3 PC3.2 Interframe space usage and 10.3.2.3, 10.3.4, M Yes No timing 10.3.7 PC3.3 Random Backoff function 10.3.3 M Yes No PC3.4 DCF Access procedure 10.3.4.2, 10.3.4.5 M Yes No PC3.5 Random Backoff procedure 10.3.4.3 M Yes No PC3.6 Recovery procedures and 10.3.4.4 M Yes No retransmit limits PC3.7 Request to send (RTS)/clear 10.3.2.4, M Yes No to send (CTS) procedure 10.3.2.5, 10.3.2.7 PC3.8 Individually addressed MAC 10.3.5 M Yes No protocol data unit (MPDU) transfer 2684 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.4.1 MAC protocol capabilities (continued) Item Protocol capability References Status Support PC3.9 Group addressed MPDU 10.3.6 M Yes No transfer PC3.10 MAC-level acknowledgment 10.3.2.2, 10.3.2.9 M Yes No PC3.11 Duplicate detection and 10.3.2.11 M Yes No recovery PC3.12 Dynamic EIFS 10.3.7 O Yes No * PC4 Point coordinator 10.2, 10.4 not CFDMG Yes No N/A The PCF mechanism is obsolete. AND Consequently, this option may be CFAP:O removed in a later revision of the standard. PC4.1 Maintenance of contention 10.4.2, 10.4.3 PC4:M Yes No N/A free period (CFP) structure and timing PC4.2 Point coordination function 10.4.4 PC4:M Yes No N/A (PCF) MPDU transfer from point coordinator * PC4.3 PCF MPDU transfer to point 10.4.4 PC4:O Yes No N/A coordinator PC4.4 Overlapping point coordinator 10.4.4.3 PC4:M Yes No N/A provisions PC4.5 Polling list maintenance 10.4.5 PC4.3:M Yes No N/A * PC5 Contention free (CF)-Pollable 10.2, 10.4 not CFDMG Yes No N/A The PCF mechanism is obsolete. AND Consequently, this option may be CFSTAofAP: removed in a later revision of the O standard. PC5.1 Interpretation of CFP 10.4.2, 10.4.3 PC5:M Yes No N/A structure and timing PC5.2 PCF MPDU transfer to/from 10.4.4 PC5:M Yes No N/A and CF-Pollable station (STA) PC5.3 Polling list update 10.4.5 PC5:M Yes No N/A PC6 Fragmentation 10.3, 10.5 M Yes No PC7 Defragmentation 10.3, 10.6 M Yes No PC8 MAC data service 10.2.8, 10.8 M Yes No PC8.1 ReorderableGroupAddressed 10.8 M Yes No service class PC8.2 StrictlyOrdered service class 10.8 O Yes No Note that the use of the StrictlyOrdered service class is obsolete and the StrictlyOrdered service class might be removed in a future revision of the standard. PC9 Multirate support 10.7 M Yes No PC9.1 Rate selection using Rx Supported 10.7.12.1, CFVHT:M Yes No N/A VHT-MCS and NSS Set / Tx 10.7.12.2 CFTVHT:M Supported VHT-MCS and NSS Set 2685 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.4.1 MAC protocol capabilities (continued) Item Protocol capability References Status Support PC9.2 Rate selection constraints for VHT 10.7.12.3 CFVHT:O Yes No N/A PPDUs CFTVHT:O * PC10 Multiple outstanding MAC 10.8 O Yes No service data unit (MSDU) support PC10.1 Multiple outstanding MSDU 10.8 PC10:M Yes No N/A transmission restrictions PC11 Timing synchronization function 11.1 CFAP OR Yes No (TSF) CFIndepSTA: M PC11.1 Timing in an infrastructure 11.1.2.1, 11.1.5 CFInfraSTA: Yes No N/A network M PC11.2 Timing in an independent 11.1.2.2, 11.1.5 CFIBSS:M Yes No N/A basic service set (IBSS) PC11.3 Beacon generation function 11.1.3 CFAP OR Yes No CFIBSS OR CFPCP:M PC11.4 TSF synchronization and 11.1.2, 11.1.3 CFAP OR Yes No N/A accuracy CFIndepSTA: M PC11.5 Infrastructure basic service set 11.1.4 CFAP:M Yes No N/A (BSS) initialization PC11.6 IBSS initialization 11.1.4 CFIBSS:M Yes No N/A PC11.7 Passive scanning 11.1.4 (CFSTAofAP Yes No N/A OR CFIBSS OR CFPBSSnotP CP):O.1 PC11.8 Active scanning 11.1.4 (CFSTAofAP Yes No N/A OR CFIBSS OR CFPBSSnotP CP):O.1 PC11.9 Probe response 11.1.4 (NOT Yes No N/A CFOCB):M PC11.10 Reserved PC12 Infrastructure power management 11.2.3 CFInfraSTA Yes No N/A AND not CFDMG:M PC12.1 STA power management 11.2.3.2, 11.2.3.9 (CFSTAofAP Yes No N/A modes or CFIBSS):M PC12.2 Traffic indication map (TIM) 11.2.3.3, 11.2.3.4 CFAP:M Yes No N/A transmission PC12.3 AP function during contention 11.2.3.6 CFAP:M Yes No N/A period (CP) PC12.4 AP function during CFP 11.2.3.7 PC4:M Yes No N/A PC12.5 Non-AP STA receive function 11.2.3.8 CFSTAofAP: Yes No N/A during CP M 2686 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.4.1 MAC protocol capabilities (continued) Item Protocol capability References Status Support PC12.6 Non-AP STA receive function 11.2.3.9 PC5:M Yes No N/A during CFP PC12.7 Aging function 11.2.3.12 CFAP:M Yes No N/A PC13 IBSS power management 11.2.4 CFIBSS:M Yes No N/A PC13.1 Initialization of power 11.2.4.3 CFIBSS:M Yes No N/A management PC13.2 STA power state transitions 11.2.4.4 CFIBSS:M Yes No N/A PC13.3 Announcement traffic f CFIBSS:M Yes No N/A indication message (ATIM) and frame transmission *PC14 (Re)Association 4.5, 11.3, 11.3.5, CFInfraSTA Yes No N/A OR CFPCP:M CFPBSSnotP CP:O PC14.1 Association state 11.3.5 PC14:M Yes No N/A PC14.2 STA association procedure 11.3.5.2 CFSTAofAP: Yes No N/A M CFPBSSnotP CP:O PC14.3 AP association procedure 11.3.5.3 CFAP OR Yes No N/A CFPCP:M PC14.4 STA reassociation procedure 11.3.5.4 CFSTAofAP: Yes No N/A M CFPBSSnotP CP:O PC14.5 AP reassociation procedure 11.3.5.5 CFAP OR Yes No N/A CFPCP:M PC15 Management information base Annex C M Yes No (MIB) PC15.1 dot11SMTbase, Annex C M Yes No dot11SmtAuthenticationAlgor ithms * PC15.2 dot11SMTprivacy Annex C PC2:M Yes No N/A PC15.3 dot11MACbase, Annex C M Yes No dot11CountersGroup, dot11GroupAddressesTable * PC15.4 dot11MACStatistics Annex C O Yes No PC15.5 dot11ResourceTypeID Annex C M Yes No PC16 Set 9.4.1.4 CFERP:M Yes No N/A dot11ShortPreambleOptionImple mented to 1 PC17 Reserved PC18 Reserved PC19 Reserved PC20 Set Short Slot Time subfield as 9.4.1.4 CFERP:M Yes No N/A described in reference 2687 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.4.1 MAC protocol capabilities (continued) Item Protocol capability References Status Support PC21 Monitor each received short time 9.4.1.4 CFERP:M Yes No N/A slot subfield and take action as described in reference. PC22 Transmit the ERP element in each 9.4.1.4 CFERP:M Yes No N/A transmitted Beacon or Probe Response frame in the format and with content as described in reference PC23 Receive the ERP element and 9.4.1.4 CFERP:M Yes No N/A employ a protection mechanism when required prior to transmitting information using ERP-OFDM modulation PC24 Determine the value of aCWmin 10.3.9 CFERP:M Yes No N/A based on the characteristic rate set as described in the reference PC25 Transmit control response frames 10.7 CFERP:M Yes No N/A at the largest basic rates less than equal to the rate received and with the same PHY options or use the highest mandatory rate if no basic rate meets the above criterion PC26 Transmit group addressed frames 10.7 CFERP:M Yes No N/A at a rate contained in the BSSBasicRateSet parameter PC27 Transmit individually addressed 10.7 CFERP:M Yes No N/A frames at any supported rate selected by a rate switching mechanism as long as it is supported by the destination STA PC28 Reserved PC29 Use ERP element to control use of 10.26 CFERP:M Yes No N/A protection mechanism as described in the reference PC30 Updated NAV is long enough to 10.26 CFERP:M Yes No N/A cover frame and any response PC31 Support transmission of CTS-to- 10.3.2.12 CFERP:O Yes No N/A self sequence as described in the CFTVHT:O references PC32 Support reception of CTS-to-self 10.3.2.12 CFERP:M Yes No N/A sequence as described in the CFTVHT:M references PC33 Update NAV 10.26 CFERP:M Yes No N/A * PC34 Robust security network 9.3.2.1, 9.4.1.4, O Yes No association (RSNA) 4.5.4.4, 11.3.4, 11.3.5, 12.9.2, 12.9.2.2, 12.9.2.4, 12.9.2.6, 12.9.2.8, 12.5.3 PC34.1 RSNE 9.4.2.25 PC34:M Yes No N/A 2688 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.4.1 MAC protocol capabilities (continued) Item Protocol capability References Status Support PC34.1.1 Group cipher suite 9.4.2.25 PC34.1:M Yes No N/A PC34.1.2 Pairwise cipher suite list 9.4.2.25 PC34.1:M Yes No N/A PC34.1.2.1 Counter mode with cipher-block 12.5.3 PC34:M Yes No N/A chaining message authentication code protocol (CCMP) data confidentiality protocol using CCMP-128 PC34.1.2.1.1 CCMP cryptographic 12.5.3.3 PC34.1.2.1:M Yes No N/A encapsulation procedure using CCMP-128 PC34.1.2.1.2 CCMP decapsulation procedure 12.5.3.4 PC34.1.2.1:M Yes No N/A using CCMP-128 PC34.1.2.2 Temporal key integrity protocol 12.5.2 PC34:O Yes No N/A (TKIP) data confidentiality protocol PC34.1.2.2.1 TKIP cryptographic 12.5.2.1.2 PC34.1.2.2:M Yes No N/A encapsulation procedure PC34.1.2.2.2 TKIP decapsulation procedure 12.5.2.1.3 PC34.1.2.2:M Yes No N/A PC34.1.2.2.3 TKIP countermeasures 12.5.2.4 PC34.1.2.2:M Yes No N/A PC34.1.2.2.4 TKIP security services 12.5.2.3 PC34.1.2.2:M Yes No N/A management PC34.1.2.3 Galois/counter mode protocol 12.5.5 (CFDMG and Yes No N/A (GCMP) PC34):M *PC34.1.3 Authentication key management 9.4.2.25, 12.5.1 PC34.1:M Yes No N/A (AKM) suite list PC34.1.3.1 IEEE 802.1X-defined/RSNA key 9.4.2.25 PC34.1:M Yes No N/A management PC34.1.3.2 Preshared key (PSK)/ 9.4.2.25 PC34.1:M Yes No N/A RSNA key management PC34.1.3.3 RSNA key management 12.7 PC34.1:M Yes No N/A PC34.1.3.3.1 Key hierarchy 12.7, 12.8 PC34.1:M Yes No N/A PC34.1.3.3.1.1 Pairwise key hierarchy 12.7.1.3 PC34.1:M Yes No N/A PC34.1.3.3.1.2 Group key hierarchy 12.7.1.4 PC34.1:M Yes No N/A PC34.1.3.3.2 4-way handshake 12.7.6 PC34.1:M Yes No N/A PC34.1.3.3.3 Group key handshake 12.7.7 PC34.1:M Yes No N/A PC34.1.4 RSN capabilities 9.4.2.25, 12.2.3 PC34.1:M Yes No N/A PC34.1.5 RSNA preauthentication 12.6.10.2 PC34.1:O Yes No N/A PC34.1.6 RSNA security association 12.6 PC34.1:M Yes No N/A management 2689 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.4.1 MAC protocol capabilities (continued) Item Protocol capability References Status Support PC34.1.7 RSNA pairwise master key 12.6.1, 12.6.10.3 PC34.1:M Yes No N/A security association (PMKSA) caching PC34.1.8 RSNA extended service set (ESS) 12.6.10, 12.6.14 (PC34.1 and Yes No N/A CFAP):M PC34.1.8.1 RSNA PeerKey handshake 12.7.8 PC34.1.8:O Yes No N/A PC34.1.9 RSNA IBSS 12.6.5, 12.6.11, (PC34.1 and Yes No N/A 12.6.15 CFIBSS):O *PC 34.1.10 Management frame protection 9.2.4.1.10, PC34:O Yes No N/A 9.4.1.11, 9.4.2.25.4, 9.6.3, 12.3.3.3.5, 12.5.2.1.2, 12.5.2.1.3, 12.5.2.2, 12.5.3.3.3, 12.5.3.3.6, 12.5.3.4.2, 12.5.3.4.4, 12.6.3, 12.9.2.3, 12.9.2.5, 12.9.2.7, 12.9.2.9 *PC 34.1.10.1 BIP 11, 12.5.4 PC34.1.10:M Yes No N/A PC 34.1.10.1.1 Management MIC element 9.4.2.55 PC34.1.10.1: Yes No N/A M PC 34.1.11 AKM: IEEE 802.1X 9.4.2.25, 12.7 PC34:O Yes No N/A authentication with SHA-256 PRF PC 34.1.12 AKM: PSK with SHA-256 PRF 9.4.2.25, 12.7 PC34:O Yes No N/A PC34.1.13 RSNA rekeying 12.6.21 PC34:O Yes No N/A PC34.1.14 Multi-band RSNA 12.6.22 CFMBO Yes No N/A AND PC34:M *PC35 Fast basic service set (BSS) 13 CFInfraSTA: Yes No N/A transition (FT) O PC35.1 Mobility Domain element (MDE) 9.4.2.47 PC35:M Yes No N/A PC35.2 Fast basic service set (BSS) 9.4.2.48 PC35 AND Yes No N/A Transition element (FTE) PC34:M PC35.3 Timeout Interval element (TIE) 9.4.2.49 PC35:M Yes No N/A PC35.4 Fast basic service set (BSS) 9.4.1.1 PC35:M Yes No N/A Transition (FT) authentication algorithm PC35.5 Fast basic service set (BSS) 9.6.9 PC35:M Yes No N/A Transition (FT) Action frames PC35.6 Fast basic service set (BSS) 9.4.2.25, 12.7.1.7 PC35 AND Yes No N/A Transition (FT) key management PC34:M based on IEEE Std 802.1X 2690 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.4.1 MAC protocol capabilities (continued) Item Protocol capability References Status Support PC35.7 Fast basic service set (BSS) 9.4.2.25, 12.7.1.7 PC35 AND Yes No N/A Transition (FT) key management PC34:M based on preshared keys (PSKs) PC35.8 Fast basic service set (BSS) 12.7.1.7 PC35 AND Yes No N/A Transition (FT) key hierarchy PC34:M PC35.9 FT initial mobility domain 13.4 PC35 AND Yes No N/A association PC34:M PC35.10 Fast Basic Service Set (BSS) 13.5 PC35:M Yes No N/A Transition (FT) Protocol PC35.10.1 Fast Basic Service Set (BSS) 13.5.2, 13.5.3, PC35 AND Yes No N/A Transition (FT) Protocol in robust 13.7.1 PC34:M security network (RSN) PC35.10.2 Fast Basic Service Set (BSS) 13.5.4, 13.5.5, PC35:M Yes No N/A Transition (FT) Protocol in 13.7.2 nonrobust security network (non- RSN) *PC35.11 Fast Basic Service Set (BSS) 13.6 PC35:O Yes No N/A transition (FT) resource request protocol PC35.11.1 Resource Request protocol over 13.6.2 PC35.11:M Yes No N/A the air PC35.11.2 Resource Request protocol over 13.6.3, 13.10 PC35.11:M Yes No N/A the distribution system (DS) PC35.12 QoS procedures for fast basic 13.11 (CFQoS AND Yes No N/A service set (BSS) transition PC35 or CFDMG AND PC35):M *PC35.13 Resource Information Container 9.4.2.50, 13.11 PC35:M Yes No N/A (RIC) Data element (RDE) PC35.13.1 Resource Request Procedures at 13.11.3.1 PC35.13:M Yes No N/A the fast basic service set (BSS) transition originator (FTO) PC35.13.2 Resource Request Procedures at 13.11.3.2 PC35.13:M Yes No N/A the target access point (AP) *PC35.14 Remote Request Procedures at the 13.10 PC35:M Yes No N/A current access point (AP) PC35.14.1 Remote Request/Response frame 13.10.3 PC35.14:O Yes No N/A support PC35.14.2 Vendor-specific remote request 13.10.3 PC35.14:O Yes No N/A broker (RRB) mechanism PC36 SA Query Procedure 9.6.10, 11.14 PC34.1.10:M Yes No N/A *PC37 Power save multi-poll (PSMP) 9.6.12.4, 10.29 not Yes No CFDMG:O *PC37.1 Scheduled PSMP 9.4.2.30, 11.4.6 PC37:M Yes No N/A PC37.1.1 PSMP additions to TSPEC 9.4.2.30 PC37.1:M Yes No N/A PC37.1.2 AP role in scheduled PSMP 10.29.2.2, (PC37.1 AND Yes No N/A sequence 10.29.2.3 CFAP):M 2691 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.4.1 MAC protocol capabilities (continued) Item Protocol capability References Status Support PC37.1.3 STA role in scheduled PSMP 10.29.2.2, (PC37.1 AND Yes No N/A sequence 10.29.2.3 CFIndepSTA) :M *PC37.2 Unscheduled PSMP 10.29.4 PC37:M Yes No N/A PC37.2.1 PSMP additions to TSPEC 9.4.2.30 (CFAP AND Yes No N/A PC37.2):M (CFIndepSTA AND PC37.2):O PC37.3 Creation, scheduling, and 9.6.12.4, (PC37 AND Yes No N/A transmission of PSMP frame 10.29.2.1 CFAP):M PC37.4 Reception and interpretation of 9.6.12.4 (PC37 AND Yes No N/A PSMP frame CFIndepSTA) :M PC37.5 Multi-TID block ack rules in 9.3.1.8.5, PC37:M Yes No N/A PSMP sequence 9.3.1.9.4, 10.29.2.7, 11.17.2 PC37.6 Multi-phase PSMP 10.29.2.5 PC37:M Yes No N/A PC38 dot11OCBActivated is false when 11.21 (CFSTAofAP Yes No N/A STA is a BSS member OR CFIBSS):M PC39 Simultaneous authentication of 12.4 CFMBSS:M Yes No N/A equals (SAE) *PC40 Multi-band Operation 11.33 CFMBO:O Yes No N/A *PC40.1 FST Setup 9.4.2.138, PC40:M Yes No N/A 9.4.2.151, 9.4.2.152, 9.6.21.2, 9.6.21.3, 9.6.21.5, 9.6.21.6, 11.33.2.1, 11.33.2.2 PC40.2 FST TS switching 9.4.2.30, PC40.1:M Yes No N/A 9.4.2.141, 9.6.3.2.2, 9.6.3.3.2, 9.6.3.4, 9.6.5.2, 9.6.5.3, 9.6.5.4, 11.33.2.3 PC40.3 FST Teardown PC40.3.1 Transmission of FST Teardown 9.6.21.4, 11.33.3 PC40.1:O Yes No N/A PC40.3.2 Reception of FST Teardown 9.6.21.4, 11.33.3 PC40.1:M Yes No N/A PC41 MMSL cluster operation 11.34 O Yes No N/A PC42 Quieting adjacent BSS operation 11.37 O Yes No N/A PC43 Beacon RSSI 11.45 O Yes No N/A PC44 Estimated throughput 11.46 O Yes No N/A 2692 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.4.2 MAC frames Item MAC frame References Status Support Is transmission of the following 9 MAC frames supported? FT1 Association Request 9 CFSTAofAP:M Yes No N/A CFPBSSnotPC P:O FT2 Association Response 9 (CFAP OR Yes No N/A CFPCP):M FT3 Reassociation Request 9 CFSTAofAP:M Yes No N/A CFPBSSnotPC P:O FT4 Reassociation Response 9 (CFAP OR Yes No N/A CFPCP):M FT5 Probe Request 9 (CFSTAofAP Yes No N/A or CFIBSS OR CFPBSSnotPC P OR CFMBSS):M FT6 Probe Response 9 (CFAP OR Yes No N/A CFIBSS OR CFPCP OR CFMBSS):M FT7 Beacon 9 (CFAP OR Yes No N/A CFIBSS OR CFMBSS) AND not CFDMG:M FT8 ATIM 9 CFIBSS:M Yes No N/A FT9 Disassociation 9 CFInfraSTA:M Yes No N/A CFPBSS:O FT10 Authentication 9 CFInfraSTA:M Yes No N/A CFIBSS OR CFPBSS:O FT11 Deauthentication 9 (NOT Yes No N/A CFOCB):M not CFDMG:M FT12 Power save (PS)-Poll 9 not CFDMG Yes No N/A AND CFSTAofAP:M FT13 RTS 9 M Yes No FT14 CTS 9 not CFDMG:M Yes No FT15 Acknowledgment (Ack) 9 M Yes No FT16 CF-End 9 not CFDMG Yes No N/A AND PC4:M O FT17 CF-End +CF-Ack 9 not CFDMG Yes No N/A AND PC4:M FT18 Data 9 not CFDMG:M Yes No FT19 Data +CF-Ack 9 not CFDMG Yes No N/A AND (PC4 OR PC5):M 2693 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.4.2 MAC frames (continued) Item MAC frame References Status Support FT20 Data +CF-Poll 9 not CFDMG Yes No N/A AND PC4.3:M FT21 Data +CF-Ack +CF-Poll 9 not CFDMG Yes No N/A AND PC4.3:M FT22 Null 9 not CFDMG:M Yes No FT23 CF-Ack (no data) 9 not CFDMG Yes No N/A AND (PC4 OR PC5):M FT24 CF-Poll (no data) 9 not CFDMG Yes No N/A AND PC4.3:M FT25 CF-Ack +CF-Poll (no data) 9 not CFDMG Yes No N/A AND PC4.3:M FT26 Timing Advertisement frame 9 O Yes No FT27 QoS Data 9 CFQoS:M Yes No N/A FT28 QoS Null (no data) 9 CFQoS:M Yes No N/A FT29 BlockAckReq 9 CFDMG:M Yes No N/A CFQoS:O FT30 BlockAck 9 CFDMG:M Yes No N/A CFQoS:O CFHT:M FT31 Poll 9 CFDMG:M Yes No N/A FT32 SPR 9 CFDMG:M Yes No N/A FT33 Grant 9 CFDMG:M Yes No N/A FT34 DMG CTS 9 CFDMG:M Yes No N/A FT35 DMG DTS 9 CFDMG:M Yes No N/A FT36 SSW 9 CFDMG:M Yes No N/A FT37 SSW-Feedback 9 CFDMG:M Yes No N/A FT38 SSW-Ack 9 CFDMG:M Yes No N/A FT39 DMG Beacon 9 CFDMG:M Yes No N/A FT40 VHT NDP Announcement 9 VHTM4.1:M Yes No N/A TVHTM4.1:M FT41 Beamforming Report Poll 9 VHTM4.1:O Yes No N/A VHTM4.3:M TVHTM4.1:O TVHTM4.3:M FT42 Transmission of Operating Mode 9.6.23.4, O Yes No N/A Notification frame and Operating 9.4.2.166, Mode Notification element 11.42 Is reception of the following MAC 9 frames supported? *FR1 Association Request 9 (CFAP OR Yes No N/A CFPCP):M *FR2 Association Response 9 (CFSTAofAP1 Yes No N/A OR CFPBSSnotPC P):M 2694 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.4.2 MAC frames (continued) Item MAC frame References Status Support FR3 Reassociation Request 9 (CFAP OR Yes No N/A CFPCP):M FR4 Reassociation Response 9 (CFSTAofAP Yes No N/A OR CFPBSSnotPC P):M FR5 Probe Request 9 (CFAP OR Yes No N/A CFIBSS OR CFPCP OR CFMBSS):M FR6 Probe Response 9 (CFSTAofAP Yes No N/A OR CFIBSS OR CFPBSSnotPC P OR CFMBSS):M FR7 Beacon 9 (NOT Yes No N/A CFOCB):M not CFDMG:M FR8 ATIM 9 (CFSTAofAP Yes No N/A OR CFIBSS OR CFMBSS) AND not CFDMG:M FR9 Disassociation 9 FR1 OR FR2:M Yes No N/A FR10 Authentication 9 CFAP AND not Yes No N/A CFDMG:M CFIBSS OR CFPBSS OR (CFAP AND CFDMG):O FR11 Deauthentication 9 FR10:M Yes No N/A FR12 PS-Poll 9 CFAP:M Yes No N/A FR13 RTS 9 M Yes No FR14 CTS 9 not CFDMG:M Yes No FR15 Ack 9 M Yes No FR16 CF-End 9 (NOT Yes No N/A CFOCB):M FR17 CF-End +CF-Ack 9 not CFDMG Yes No N/A AND (PC4 OR PC5):M FR18 Data 9 not CFDMG:M Yes No FR19 Data +CF-Ack 9 (NOT Yes No N/A CFOCB):M not CFDMG:M FR20 Data +CF-Poll 9 not CFDMG Yes No N/A AND PC5:M FR21 Data +CF-Ack +CF-Poll 9 not CFDMG Yes No N/A AND PC5:M FR22 Null 9 not CFDMG:M Yes No 2695 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.4.2 MAC frames (continued) Item MAC frame References Status Support FR23 CF-Ack (no data) 9 not CFDMG Yes No N/A AND (PC4 OR PC5):M FR24 CF-Poll (no data) 9 not CFDMG Yes No N/A AND PC5:M FR25 CF-Ack +CF-Poll (no data) 9 not CFDMG Yes No N/A AND PC5:M FR26 Timing Advertisement frame 9 O Yes No FR27 QoS Data 9 CFQoS:M Yes No N/A FR28 QoS Null (no data) 9 CFQoS:M Yes No N/A FR29 BlockAckReq 9 CFQoS:O Yes No N/A HTM3.1:M FR30 BlockAck 9 CFQoS:O Yes No N/A HTM3.5:M FR31 Poll 9 CFDMG:M Yes No N/A FR32 SPR 9 CFDMG:M Yes No N/A FR33 Grant 9 CFDMG:M Yes No N/A FR34 DMG CTS 9 CFDMG:M Yes No N/A FR35 DMG DTS 9 CFDMG:M Yes No N/A FR36 Reserved FR37 SSW 9 CFDMG:M Yes No N/A FR38 SSW-Feedback 9 CFDMG:M Yes No N/A FR39 SSW-Ack 9 CFDMG:M Yes No N/A FR40 DMG Beacon 9 (CFSTAofAP Yes No N/A OR CFIBSS OR CFPBSS) AND CFDMG:M FR41 VHT NDP Announcement 9 VHTM4.2:M Yes No N/A TVHTM4.2:M FR42 Beamforming Report Poll 9 VHTM4.2:O Yes No N/A VHTM4.4:M TVHTM4.2:O TVHTM4.4:M FR43 Reception of Operating Mode 9.6.23.4, CFVHT:M Yes No N/A Notification frame and Operating 9.4.2.166, CFTVHT:M Mode Notification element 11.42 2696 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.4.3 Frame exchange sequences Frame exchange Item References Status Support sequence Are the following frame exchange sequences supported? FS1 Basic frame exchange 10.3.2.5, 10.3.2.7, M Yes No sequences 10.3.2.9, 10.3.5, 10.3.6, 10.4.3 FS2 CF-frame exchange 10.4.3, 10.4.4 (PC4 OR PC5):M Yes No N/A sequences B.4.4.4 MAC addressing functions Item MAC Address function References Status Support Are the following MAC Addressing functions supported? AD1 STA universal individual IEEE 802 9.2.4.3 M Yes No address AD2 BSS identification (BSSID) 9.2.4.3, 11.1.4 M Yes No generation AD3 Receive address matching 9.2.4.3, 9.3.2.1 M Yes No AD4 Wildcard BSSID 9.2.4.3.4, 9.3.2 CFOCB:M Yes No N/A AD5 MAC and PHY operation resumes with 11.21 CFOCB:M Yes No N/A appropriate MIB attributes in less than 2 TU AD6 Group addressed mesh Data frame 9.2.3, 9.2.4.1, CFMBSS:M Yes No N/A addressing (3 address frame) 9.2.4.3, 9.3.5 AD7 Individually addressed mesh Data frame 9.2.3, 9.2.4.1, CFMBSS:M Yes No N/A addressing (4 address frame) 9.2.4.3, 9.3.5 AD8 Proxied group addressed mesh Data 9.2.3, 9.2.4.1, CFMBSS:M Yes No N/A frame addressing (4 address frame) 9.2.4.3, 9.2.4.7.3, 9.3.5 AD9 Proxied individually addressed mesh 9.2.3, 9.2.4.1, CFMBSS:M Yes No N/A Data frame addressing (6 address frame) 9.2.4.3, 9.2.4.7.3, 9.3.5 AD10 Multihop Action frame addressing (4 9.2.3, 9.2.4.1, CFMBSS:M Yes No N/A address frame) 9.2.4.3, 9.2.4.7.3, 9.6.18, 9.3.5 AD11 TA filtering for mesh STA 9.2.4.3, 9.3.2.1, CFMBSS:M Yes No N/A 9.3.5 2697 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.5 Direct sequence PHY functions Item PHY feature References Status Support PHY sublayer procedures 15.3 DS1 Preamble prepend on transmit (TX) 15.3.1 M Yes No DS1.1 PHY frame format 15.3.2, 15.3.3 M Yes No DS1.2 PHY integrity check generation 15.3.3, 15.3.3.7 M Yes No DS1.3 TX rate change capability 15.2.3.4, 15.3.5 M Yes No DS1.4 Supported data rates 15.1, 15.2.3.4 M Yes No DS1.5 Data whitener scrambler 15.3.4 M Yes No DS1.6 Scrambler initialization 15.3.4 M Yes No DS2 Preamble process on receive (RX) 15.3.1 DS2.1 PHY frame format 15.3.2, 15.3.3 M Yes No DS2.2 PHY integrity check verify 15.3.3, 15.3.3.7 M Yes No DS2.3 RX Rate change capability 15.2.3.4, 15.3.5 M Yes No DS2.4 Data whitener descrambler 15.3.4 M Yes No DS3 Pseudonoise (PN) code sequence 15.4.4.4 M Yes No DS4 Chipping continue on power-down 15.3.6 O Yes No *DS5 Operating channel capability 15.3.6, 15.4.4.3 * DS5.1 North America (FCC) 15.3.6, 15.4.4.3 DS5:O.1 Yes No N/A DS5.1.1 Channel 1 15.3.6, 15.4.4.3 DS5.1:M Yes No N/A DS5.1.2 Channel 2 15.3.6, 15.4.4.3 DS5.1:M Yes No N/A DS5.1.3 Channel 3 15.3.6, 15.4.4.3 DS5.1:M Yes No N/A DS5.1.4 Channel 4 15.3.6, 15.4.4.3 DS5.1:M Yes No N/A DS5.1.5 Channel 5 15.3.6, 15.4.4.3 DS5.1:M Yes No N/A DS5.1.6 Channel 6 15.3.6, 15.4.4.3 DS5.1:M Yes No N/A DS5.1.7 Channel 7 15.3.6, 15.4.4.3 DS5.1:M Yes No N/A DS5.1.8 Channel 8 15.3.6, 15.4.4.3 DS5.1:M Yes No N/A DS5.1.9 Channel 9 15.3.6, 15.4.4.3 DS5.1:M Yes No N/A DS5.1.10 Channel 10 15.3.6, 15.4.4.3 DS5.1:M Yes No N/A DS5.1.11 Channel 11 15.3.6, 15.4.4.3 DS5.1:M Yes No N/A * DS5.2 Canada (IC) 15.3.6, 15.4.4.3 DS5:O.1 Yes No N/A DS5.2.1 Channel 1 15.3.6, 15.4.4.3 DS5.2:M Yes No N/A DS5.2.2 Channel 2 15.3.6, 15.4.4.3 DS5.2:M Yes No N/A DS5.2.3 Channel 3 15.3.6, 15.4.4.3 DS5.2:M Yes No N/A DS5.2.4 Channel 4 15.3.6, 15.4.4.3 DS5.2:M Yes No N/A DS5.2.5 Channel 5 15.3.6, 15.4.4.3 DS5.2:M Yes No N/A DS5.2.6 Channel 6 15.3.6, 15.4.4.3 DS5.2:M Yes No N/A DS5.2.7 Channel 7 15.3.6, 15.4.4.3 DS5.2:M Yes No N/A DS5.2.8 Channel 8 15.3.6, 15.4.4.3 DS5.2:M Yes No N/A DS5.2.9 Channel 9 15.3.6, 15.4.4.3 DS5.2:M Yes No N/A DS5.2.10 Channel 10 15.3.6, 15.4.4.3 DS5.2:M Yes No N/A 2698 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.5 Direct sequence PHY functions (continued) Item PHY feature References Status Support DS5.2.11 Channel 11 15.3.6, 15.4.4.3 DS5.2:M Yes No N/A * DS5.3 Europe (ETSI) 15.3.6, 15.4.4.3 DS5:O.1 Yes No N/A DS5.3.1 Channel 1 15.3.6, 15.4.4.3 DS5.3:M Yes No N/A DS5.3.2 Channel 2 15.3.6, 15.4.4.3 DS5.3:M Yes No N/A DS5.3.3 Channel 3 15.3.6, 15.4.4.3 DS5.3:M Yes No N/A DS5.3.4 Channel 4 15.3.6, 15.4.4.3 DS5.3:M Yes No N/A DS5.3.5 Channel 5 15.3.6, 15.4.4.3 DS5.3:M Yes No N/A DS5.3.6 Channel 6 15.3.6, 15.4.4.3 DS5.3:M Yes No N/A DS5.3.7 Channel 7 15.3.6, 15.4.4.3 DS5.3:M Yes No N/A DS5.3.8 Channel 8 15.3.6, 15.4.4.3 DS5.3:M Yes No N/A DS5.3.9 Channel 9 15.3.6, 15.4.4.3 DS5.3:M Yes No N/A DS5.3.10 Channel 10 15.3.6, 15.4.4.3 DS5.3:M Yes No N/A DS5.3.11 Channel 11 15.3.6, 15.4.4.3 DS5.3:M Yes No N/A DS5.3.12 Channel 12 15.3.6, 15.4.4.3 DS5.3:M Yes No N/A DS5.3.13 Channel 13 15.3.6, 15.4.4.3 DS5.3:M Yes No N/A * DS5.4 France 15.3.6, 15.4.4.3 DS5:O.1 Yes No N/A DS5.4.1 Channel 10 15.3.6, 15.4.4.3 DS5.4:M Yes No N/A DS5.4.2 Channel 11 15.3.6, 15.4.4.3 DS5.4:M Yes No N/A DS5.4.3 Channel 12 15.3.6, 15.4.4.3 DS5.4:M Yes No N/A DS5.4.4 Channel 13 15.3.6, 15.4.4.3 DS5.4:M Yes No N/A * DS5.5 Spain 15.3.6, 15.4.4.3 DS5:O.1 Yes No N/A DS5.5.1 Channel 10 15.3.6, 15.4.4.3 DS5.5:M Yes No N/A DS5.5.2 Channel 11 15.3.6, 15.4.4.3 DS5.5:M Yes No N/A * DS5.6 Japan 15.3.6, 15.4.4.3 DS5:O.1 Yes No N/A * DS5.7 China 15.3.6, 15.4.4.3 DS5:O.1 Yes No N/A DS5.7.1 Channel 1 15.3.6, 15.4.4.3 DS5.7:M Yes No N/A DS5.7.2 Channel 2 15.3.6, 15.4.4.3 DS5.7:M Yes No N/A DS5.7.3 Channel 3 15.3.6, 15.4.4.3 DS5.7:M Yes No N/A DS5.7.4 Channel 4 15.3.6, 15.4.4.3 DS5.7:M Yes No N/A DS5.7.5 Channel 5 15.3.6, 15.4.4.3 DS5.7:M Yes No N/A DS5.7.6 Channel 6 15.3.6, 15.4.4.3 DS5.7:M Yes No N/A DS5.7.7 Channel 7 15.3.6, 15.4.4.3 DS5.7:M Yes No N/A DS5.7.8 Channel 8 15.3.6, 15.4.4.3 DS5.7:M Yes No N/A DS5.7.9 Channel 9 15.3.6, 15.4.4.3 DS5.7:M Yes No N/A DS5.7.10 Channel 10 15.3.6, 15.4.4.3 DS5.7:M Yes No N/A DS5.7.11 Channel 11 15.3.6, 15.4.4.3 DS5.7:M Yes No N/A DS5.7.12 Channel 12 15.3.6, 15.4.4.3 DS5.7:M Yes No N/A DS5.7.13 Channel 13 15.3.6, 15.4.4.3 DS5.7:M Yes No N/A DS6 Bits to symbol mapping 15.4.4.5 DS6.1 1 Mb/s 15.4.4.5 M Yes No 2699 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.5 Direct sequence PHY functions (continued) Item PHY feature References Status Support DS6.2 2 Mb/s 15.4.4.5 M Yes No *DS7 CCA functionality 15.4.6.5 DS7.1 Energy Only (RSSI above threshold) 15.4.6.5 DS7:O.2 Yes No N/A DS7.2 IEEE 802.11 DSSS correlation 15.4.6.5 DS7:O.2 Yes No N/A DS7.3 Both methods 15.4.6.5 DS7:O.2 Yes No N/A DS7.4 Hold CCA busy for packet duration of 15.3.7 M Yes No a correctly received PPDU but carrier lost during reception of MPDU DS7.5 Hold CCA busy for packet duration of 15.3.7 M Yes No a correctly received but out of specification PPDU DS8 Transmit antenna selection O Yes No DS9 Receive antenna diversity 15.2.3.8 O Yes No *DS10 Antenna connector(s) availability 15.4.4.10 O Yes No DS10.1 50 impedance 15.4.4.10 DS10:M Yes No N/A *DS11 Transmit power level support 15.4.5.4 O Yes No DS11.1 If greater than 100 mW capability 15.4.5.4 DS11:M Yes No N/A DS12 Spurious emissions compliance 15.4.4.6 M Yes No DS13 TX-to-RX turnaround time 15.4.4.7 M Yes No DS14 RX-to-TX turnaround time 15.4.4.8 M Yes No DS15 Slot time 15.4.4.9 M Yes No DS16 Energy detection (ED) reporting time 15.4.4.9, M Yes No 15.4.6.5 DS17 Minimum transmit power level 15.4.5.3 M Yes No DS18 Transmit spectral mask compliance 15.4.5.5 M Yes No DS19 Transmitted center frequency 15.4.5.6 M Yes No tolerance DS20 Chip clock frequency tolerance 15.4.5.7 M Yes No DS21 Transmit power-on ramp 15.4.5.8 M Yes No DS22 Transmit power-down ramp 15.4.5.8 M Yes No DS23 Radio frequency (RF) carrier 15.4.5.9 M Yes No suppression DS24 Transmit modulation accuracy 15.4.5.10 M Yes No DS25 Receiver minimum input level 15.4.6.2 M Yes No sensitivity DS26 Receiver maximum input level 15.4.6.3 M Yes No DS27 Receiver adjacent channel rejection 15.4.6.4 M Yes No DS28 MIB 15.4.2, Annex C M Yes No DS28.1 dot11PhyDSSSComplianceGroup, 15.4.2 M Yes No dot11PhyRegDomainsSupportGroup, and dot11PhyOperationComplianceGroup 2700 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.6 OFDM PHY functions Item Feature References Status Support OF1: OFDM PHY Specific Service Parameters OF1.1 TXVECTOR parameter: LENGTH 17.2.2.2 M Yes No OF1.2 TXVECTOR parameter: DATARATE 17.2.2.3 M Yes No OF1.2.1 DATARATE = 6.0 Mb/s 17.2.2.3 M Yes No *OF1.2.2 DATARATE = 9.0 Mb/s 17.2.2.3 O Yes No OF1.2.3 DATARATE = 12.0 Mb/s 17.2.2.3 M Yes No *OF1.2.4 DATARATE = 18.0 Mb/s 17.2.2.3 O Yes No *OF1.2.5 DATARATE = 24.0 Mb/s 17.2.2.3, (NOT Yes No Annex E CF3G6):M CF3G6:O *OF1.2.6 DATARATE = 36.0 Mb/s 17.2.2.3 O Yes No *OF1.2.7 DATARATE = 48.0 Mb/s 17.2.2.3 O Yes No *OF1.2.8 DATARATE = 54.0 Mb/s 17.2.2.3 O Yes No OF1.3 TXVECTOR parameter: SERVICE 17.2.2.4 M Yes No OF1.4 TXVECTOR parameter: 17.2.2.5 M Yes No TXPWR_LEVEL_INDEX OF1.5 RXVECTOR parameter: LENGTH 17.2.3.2 M Yes No OF1.6 RXVECTOR parameter: RSSI 17.2.3.3 M Yes No *OF1.7 10 MHz Channel spacing 17.2.2, CFOC:O Yes No N/A 17.2.3, CF3G6 17.2.3.4, AND Annex E DSE2:M *OF1.7.1 DATARATE = 3 Mb/s 17.2.2, CFOC Yes No N/A (10 MHz channel spacing) 17.2.3, AND 17.2.3.4 OF1.7:M *OF1.7.2 DATARATE = 4.5 Mb/s 17.2.2, CFOC Yes No N/A (10 MHz channel spacing) 17.2.3, AND 17.2.3.4 OF1.7:O *OF1.7.3 DATARATE = 6 Mb/s 17.2.2, CFOC Yes No N/A (10 MHz channel spacing) 17.2.3, AND 17.2.3.4 OF1.7:M *OF1.7.4 DATARATE = 9 Mb/s 17.2.2, CFOC Yes No N/A (10 MHz channel spacing) 17.2.3, AND 17.2.3.4 OF1.7:O *OF1.7.5 DATARATE = 12 Mb/s 17.2.2, CFOC Yes No N/A (10 MHz channel spacing) 17.2.3, AND 17.2.3.4 OF1.7:M *OF1.7.6 DATARATE = 18 Mb/s 17.2.2, CFOC Yes No N/A (10 MHz channel spacing) 17.2.3, AND 17.2.3.4 OF1.7:O *OF1.7.7 DATARATE = 24 Mb/s 17.2.2, CFOC Yes No N/A (10 MHz channel spacing) 17.2.3, AND 17.2.3.4 OF1.7:O *OF1.7.8 DATARATE = 27 Mb/s 17.2.2, CFOC Yes No N/A (10 MHz channel spacing) 17.2.3, AND 17.2.3.4 OF1.7:O 2701 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.6 OFDM PHY functions (continued) Item Feature References Status Support *OF1.8 5 MHz Channel spacing 17.2.2, CFOC:O Yes No N/A 17.2.3, CF3G6 17.2.3.4, AND Annex E DSE2:M CF3G6 AND DSE3:M *OF1.8.1 DATARATE = 1.5 Mb/s 17.2.2, CFOC Yes No N/A (5 MHz channel spacing) 17.2.3, AND 17.2.3.4 OF1.8:M *OF1.8.2 DATARATE = 2.25 Mb/s 17.2.2, CFOC Yes No N/A (5 MHz channel spacing) 17.2.3, AND 17.2.3.4 OF1.8:O *OF1.8.3 DATARATE = 3 Mb/s 17.2.2, CFOC Yes No N/A (5 MHz channel spacing) 17.2.3, AND 17.2.3.4 OF1.8:M *OF1.8.4 DATARATE = 4.5 Mb/s 17.2.2, CFOC Yes No N/A (5 MHz channel spacing) 17.2.3, AND 17.2.3.4 OF1.8:O *OF1.8.5 DATARATE = 6 Mb/s 17.2.2, CFOC Yes No N/A (5 MHz channel spacing) 17.2.3, AND 17.2.3.4 OF1.8:M *OF1.8.6 DATARATE = 9 Mb/s 17.2.2, CFOC Yes No N/A (5 MHz channel spacing) 17.2.3, AND 17.2.3.4 OF1.8:O *OF1.8.7 DATARATE = 12 Mb/s 17.2.2, CFOC Yes No N/A (5 MHz channel spacing) 17.2.3, AND 17.2.3.4 OF1.8:O *OF1.8.8 DATARATE = 13.5 Mb/s 17.2.2, CFOC Yes No N/A (5 MHz channel spacing) 17.2.3, AND 17.2.3.4 OF1.8:O OF2: OFDM PHY Sublayer OF2.1 RATE-dependent parameters 17.3.2.3 M Yes No OF2.2 Timing related parameters 17.3.2.4 M Yes No OF2.3 PHY preamble: SYNC 17.3.3 M Yes No OF2.4 PHY header: SIGNAL 17.3.4 M Yes No OF2.5 PHY header: LENGTH 17.3.4.2 M Yes No OF2.6 PHY header: RATE 17.3.4.3 M Yes No OF2.7 PHY header: parity, reserve 17.3.4.4 M Yes No OF2.8 PHY header: SIGNAL TAIL 17.3.4.4 M Yes No OF2.9 PHY header: SERVICE 17.3.5.2 M Yes No OF2.10 PHY protocol data unit (PPDU): TAIL 17.3.5.3 M Yes No OF2.11 PPDU: PAD 17.3.5.4 M Yes No OF2.12 PHY/OFDM PHY data scrambler 17.3.5.5 M Yes No and descrambler OF2.13 Convolutional encoder 17.3.5.6 M Yes No OF2.13.1 Rate R = 1/2 17.3.5.6 M Yes No 2702 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.6 OFDM PHY functions (continued) Item Feature References Status Support OF2.13.2 Punctured coding R = 2/3 17.3.5.6 OF1.2.7:M Yes No N/A OF2.13.3 Punctured coding R = 3/4 17.3.5.6 OF1.2.2 Yes No N/A OR OF1.2.4 OR OF1.2.6 OR OF1.2.8:M OF2.14 Data interleaving 17.3.5.7 M Yes No OF2.15 Subcarrier modulation mapping 17.3.5.8 M Yes No OF2.15.1 Binary phase shift keying (BPSK) 17.3.5.8 M Yes No OF2.15.2 Quadrature phase shift keying (QPSK) 17.3.5.8 M Yes No OF2.15.3 16-quadrature amplitude modulation 17.3.5.8 M Yes No (QAM) OF2.15.4 64-QAM 17.3.5.8 OF1.2.7 Yes No N/A OR OF1.2.8:M OF2.16 Pilot subcarriers 17.3.5.9 M Yes No OF2.17 OFDM modulation 17.3.5.6 M Yes No OF2.18 Packet duration calculation M Yes No OF2.19 CCA OF2.19.1 CCA: RSSI 17.3.6 M Yes No OF2.19.2 CCA: indication to MAC sublayer 17.3.6 M Yes No *OF2.19.3 CCA-ED functionality 17.3.10.6 CF3G6:M Yes No N/A OF2.19.3.1 CCA-ED energy only (RPI above 17.3.10.6 OF2.19.3: Yes No N/A threshold) M OF2.19.3.2 Hold CCA busy for packet duration of a 17.3.10.6 OF2.19.3: Yes No N/A correctly received PPDU, but carrier lost M during reception of MPDU OF2.20 PHY data modulation and modulation rate 17.3.7 M Yes No change OF2.21 Modulation-dependent parameters 17.3.2.3 CFOC Yes No N/A (10 MHz channel spacing) AND OF1.7:M OF2.22 Timing-related parameters 17.3.2.4 CFOC Yes No N/A (10 MHz channel spacing) AND OF1.7:M OF2.23 PHY header: RATE 17.3.4.2 CFOC Yes No N/A (10 MHz channel spacing) AND OF1.7:M OF2.24 Modulation-dependent parameters 17.3.2.3 CFOC Yes No N/A (5 MHz channel spacing) AND OF1.8:M OF2.25 Timing-related parameters 17.3.2.4 CFOC Yes No N/A (5 MHz channel spacing) AND OF1.8:M 2703 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.6 OFDM PHY functions (continued) Item Feature References Status Support OF2.26 PHY header: RATE 17.3.4.2 CFOC Yes No N/A (5 MHz channel spacing) AND OF1.8:M OF3: PDM Operating Specification General OF3.1 Occupied channel bandwidth OF3.1.1 20 MHz channel spacing 17.3.8.2 M Yes No OF3.1.2 10 MHz channel spacing 17.3.8.2 CFOC Yes No N/A AND OF1.7:M OF3.1.3 5 MHz channel spacing 17.3.8.2 CFOC Yes No N/A AND OF1.8:M OF3.2 Operating frequency range 17.3.8.4.1 *OF3.2.1 4.9 GHz band Annex E CFOC:O Yes No N/A *OF3.2.2 5.0 GHz band Annex E CFOC:M Yes No N/A OF3.2.3 5.15â€“5.25 GHz band 17.3.8.4 O.1 Yes No OF3.2.4 5.25â€“5.35 GHz band 17.3.8.4 O.1 Yes No *OF3.2.5 5.47â€“5.725 GHz band Annex E CFSM:M Yes No N/A OF3.2.6 5.725â€“5.85 GHz band 17.3.8.4 O.1 Yes No *OF3.2.7 3.65â€“3.70 GHz band Annex D, CF3G6:M Yes No N/A Annex E OF3.2.8 5.9 GHz band Annex E CF5G9:M Yes No N/A OF3.3 Channelization OF3.3.1 5.15â€“5.25 GHz (20 MHz channel Annex E O.1 Yes No spacing) OF3.3.2 5.25â€“5.35 GHz (20 MHz channel spacing) Annex E O.1 Yes No OF3.3.3 5.725â€“5.825 GHz (20 MHz channel Annex E O.1 Yes No spacing) OF3.3.4 5.15â€“5.25 GHz band in Japan (20 MHz Annex E CFOC:M Yes No N/A channel spacing) OF3.3.5 5.47â€“5.725 GHz (20 MHz channel Annex E CFSM Yes No N/A spacing) AND OF3.2.5:M OF3.3.6 5.725â€“5.85 GHz (20 MHz channel Annex E O.1 Yes No spacing) OF3.3.7 4.9 GHz band (20 MHz channel spacing) Annex E CFOC Yes No N/A AND OF3.2.1:M OF3.3.8 5.0 GHz band (20 MHz channel spacing) Annex E CFOC Yes No N/A AND OF3.2.2:M OF3.3.9 4.9 GHz band (10 MHz channel spacing) Annex E CFOC Yes No N/A AND OF3.2.1 AND OF1.7:M 2704 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.6 OFDM PHY functions (continued) Item Feature References Status Support OF3.3.10 5.0 GHz band (10 MHz channel spacing) Annex E CFOC Yes No N/A AND OF3.2.2 AND OF1.7:M OF3.3.11 4.9 GHz band (5 MHz channel spacing) Annex E CFOC Yes No N/A AND OF3.2.1 AND OF1.8:M OF3.3.12 5.0 GHz band (5 MHz channel spacing) Annex E CFOC Yes No N/A AND OF3.2.2 AND OF1.8:M OF3.3.13 3.65â€“3.70 GHz (20 MHz channel spacing) Annex E CF3G6 Yes No N/A AND OF3.2.7:M OF3.3.14 3.65â€“3.70 GHz (10 MHz channel spacing) Annex E CF3G6 Yes No N/A AND OF3.2.7 AND OF1.7:M OF3.3.15 3.65â€“3.70 GHz (5 MHz channel spacing) Annex E CF3G6 Yes No N/A AND OF3.2.7 AND OF1.8:M OF3.3.16 5.9 GHz band (10 MHz channel spacing) Annex E CF5G9:O Yes No N/A OF3.3.17 5.9 GHz band (20 MHz channel spacing) Annex E CF5G9:O Yes No N/A OF3.3.18 5.9 GHz band (5 MHz channel spacing) Annex E CF5G9:O Yes No N/A OF3.4 Number of operating channels Annex E M Yes No OF3.5 Operating channel frequencies Annex E M Yes No OF3.6 Transmit and receive in band and out of Annex E M Yes No band spurious emission OF3.6.1 Interference-limited areas, 4.9 GHz band Annex E CFOC Yes No N/A (20 MHz channel spacing) AND OF3.2.1:M OF3.6.2 Interference-limited areas, 5.0 GHz band Annex E CFOC Yes No N/A (20 MHz channel spacing) AND OF3.2.2:M OF3.6.3 Interference-limited areas, 4.9 GHz band Annex E CFOC Yes No N/A (10 MHz channel spacing) AND OF3.2.1 AND OF1.7:O 2705 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.6 OFDM PHY functions (continued) Item Feature References Status Support OF3.6.4 Interference-limited areas, 5.0 GHz band Annex E CFOC Yes No N/A (10 MHz channel spacing) AND OF3.2.2 AND OF1.7:O OF3.6.5 Interference-limited areas, 4.9 GHz band Annex E CFOC Yes No N/A (5 MHz channel spacing) AND OF3.2.1 AND OF1.8:O OF3.6.6 Interference-limited areas, 5.0 GHz band Annex E CFOC Yes No N/A (5 MHz channel spacing) AND OF3.2.2 AND OF1.8:O OF3.7 Reserved OF3.8 Slot time 17.3.8.6 M Yes No OF3.8.1 Slot time (20 MHz channel spacing) 17.3.8.6 CFOC Yes No N/A AND OC2:M OF3.8.2 Slot time (10 MHz channel spacing) 17.3.8.6 CFOC Yes No N/A AND OC3 AND OF1.7:M OF3.8.3 Slot time (5 MHz channel spacing) 17.3.8.6 CFOC Yes No N/A AND OC4 AND OF1.8:M OF3.9 Transmit and receive antenna connector 17.3.8.7 M Yes No impedance OF4: PHY Transmit Specification OF4.1 Transmit power levels M Yes No OF4.1.1 Power level (5.15â€“5.25 GHz) 17.3.9.2 OF3.3.1:M Yes No N/A OF4.1.2 Power level (5.25â€“5.35 GHz) 17.3.9.2 OF3.3.2:M Yes No N/A OF4.1.3 Power level (5.725â€“5.825 GHz) 17.3.9.2 OF3.3.3:M Yes No N/A *OF4.1.4 Power Level (5.850â€“5.925 GHz), Class A D.2.2 CF5G9:M Yes No N/A *OF4.1.5 Power Level (5.850â€“5.925 GHz), Class B D.2.2 CF5G9:O Yes No N/A *OF4.1.6 Power Level (5.850â€“5.925 GHz), Class C D.2.2 CF5G9:O Yes No N/A *OF4.1.7 Power Level (5.850â€“5.925 GHz), Class D D.2.2 CF5G9:O Yes No N/A OF4.2 Spectrum mask 17.3.9.3 M Yes No OF4.3 Spurious 17.3.9.4 M Yes No OF4.4 Center frequency tolerance 17.3.9.5 M Yes No OF4.5 Clock frequency tolerance 17.3.9.6 M Yes No OF4.6 Modulation accuracy Yes No OF4.6.1 Center frequency leakage 17.3.9.7.2 M Yes No 2706 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.6 OFDM PHY functions (continued) Item Feature References Status Support OF4.6.2 Spectral flatness 17.3.9.7.3 M Yes No OF4.6.3 Transmitter constellation error < â€“5 dB 17.3.9.7.4 M Yes No OF4.6.4 Transmitter constellation error < â€“8 dB 17.3.9.7.4 OF1.2.2:M Yes No N/A OF4.6.5 Transmitter constellation error < â€“10 dB 17.3.9.7.4 M Yes No OF4.6.6 Transmitter constellation error < â€“13 dB 17.3.9.7.4 OF1.2.4:M Yes No N/A OF4.6.7 Transmitter constellation error < â€“16 dB 17.3.9.7.4 M Yes No OF4.6.8 Transmitter constellation error < â€“19 dB 17.3.9.7.4 OF1.2.6:M Yes No N/A OF4.6.9 Transmitter constellation error < â€“22 db 17.3.9.7.4 OF1.2.7:M Yes No N/A OF4.6.10 Transmitter constellation error < â€“25 dB 17.3.9.7.4 OF1.2.8:M Yes No N/A OF4.7 Power level, 4.9 GHz band 17.3.9.2 CFOC Yes No N/A (20 MHz channel spacing) AND OF3.12.1: M OF4.8 Power level, 5.0 GHz band 17.3.9.2 CFOC Yes No N/A (20 MHz channel spacing) AND OF3.12.2: M OF4.9 Power level, 5.47â€“5.725 GHz band 17.3.9.2 CFOC Yes No N/A AND OF3.12.3: M OF4.10 Power level, 4.9 GHz band 17.3.9.2 CFOC Yes No N/A (10 MHz channel spacing) AND OF3.12.1 AND OF1.7:M OF4.11 Power level, 5.0 GHz band 17.3.9.2 CFOC Yes No N/A (10 MHz channel spacing) AND OF3.12.2 AND OF1.7:M OF4.12 Power level, 4.9 GHz band 17.3.9.2 CFOC Yes No N/A (5 MHz channel spacing) AND OF3.12.1 AND OF1.8:M OF4.13 Power level, 5.0 GHz band 17.3.9.2 CFOC Yes No N/A (5 MHz channel spacing) AND OF3.12.2 AND OF1.8:M OF4.13a Power level, 3.65â€“3.70 GHz (20 MHz Annex E CF3G6 Yes No N/A channel spacing) AND OF3.2.7:M OF4.13b Power level, 3.65â€“3.70 GHz (10 MHz Annex E CF3G6 Yes No N/A channel spacing) AND OF3.2.7 AND OF1.7:M 2707 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.6 OFDM PHY functions (continued) Item Feature References Status Support OF4.13c Power level, 3.65â€“3.70 GHz (5 MHz Annex E CF3G6 Yes No N/A channel spacing) AND OF3.2.7 AND OF1.8:M OF4.14 Spectrum mask 17.3.9.3 CFOC:M Yes No N/A (20 MHz channel spacing) OF4.15 Spectrum mask 17.3.9.3 CFOC Yes No N/A (10 MHz channel spacing) AND OF1.7:M OF4.15.1 Spectrum mask, Class A D.2.3 OF4.1.4:M Yes No N/A (10 MHz channel spacing) OF4.15.2 Spectrum mask, Class B D.2.3 OF4.1.5:M Yes No N/A (10 MHz channel spacing) OF4.15.3 Spectrum mask, Class C D.2.3 OF4.1.6:M Yes No N/A (10 MHz channel spacing) OF4.15.4 Spectrum mask, Class D D.2.3 OF4.1.7:M Yes No N/A (10 MHz channel spacing) OF4.16 Spectrum mask 17.3.9.3 CFOC Yes No N/A (5 MHz channel spacing) AND OF1.8:M OF4.17 Transmitter constellation error (10 MHz channel spacing) OF4.17.1 Transmitter constellation error < â€“5 dB 17.3.9.7.4 CFOC Yes No N/A (10 MHz channel spacing) AND OF1.7.1:M OF4.17.2 Transmitter constellation error < â€“8 dB 17.3.9.7.4 CFOC Yes No N/A (10 MHz channel spacing) AND OF1.7.2:M OF4.17.3 Transmitter constellation error < â€“10 dB 17.3.9.7.4 CFOC Yes No N/A (10 MHz channel spacing) AND OF1.7.3:M OF4.17.4 Transmitter constellation error < â€“13 dB 17.3.9.7.4 CFOC Yes No N/A (10 MHz channel spacing) AND OF1.7.4:M OF4.17.5 Transmitter constellation error < â€“16 dB 17.3.9.7.4 CFOC Yes No N/A (10 MHz channel spacing) AND OF1.7.5:M OF4.17.6 Transmitter constellation error < â€“19 dB 17.3.9.7.4 CFOC Yes No N/A (10 MHz channel spacing) AND OF1.7.6:M OF4.17.7 Transmitter constellation error < â€“22 dB 17.3.9.7.4 CFOC Yes No N/A (10 MHz channel spacing) AND OF1.7.7:M OF4.17.8 Transmitter constellation error < â€“25 dB 17.3.9.7.4 CFOC Yes No N/A (10 MHz channel spacing) AND OF1.7.8:M OF4.18 Transmitter constellation error (5 MHz channel spacing) 2708 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.6 OFDM PHY functions (continued) Item Feature References Status Support OF4.18.1 Transmitter constellation error < â€“5 dB 17.3.9.7.4 CFOC Yes No N/A (5 MHz channel spacing) AND OF1.8.1:M OF4.18.2 Transmitter constellation error < â€“8 dB 17.3.9.7.4 CFOC Yes No N/A (5 MHz channel spacing) AND OF1.8.2:M OF4.18.3 Transmitter constellation error < â€“10 dB 17.3.9.7.4 CFOC Yes No N/A (5 MHz channel spacing) AND OF1.8.3:M OF4.18.4 Transmitter constellation error < â€“13 dB 17.3.9.7.4 CFOC Yes No N/A (5 MHz channel spacing) AND OF1.8.4:M OF4.18.5 Transmitter constellation error < â€“16 dB 17.3.9.7.4 CFOC Yes No N/A (5 MHz channel spacing) AND OF1.8.5:M OF4.18.6 Transmitter constellation error < â€“19 dB 17.3.9.7.4 CFOC Yes No N/A (5 MHz channel spacing) AND OF1.8.6:M OF4.18.7 Transmitter constellation error < â€“22 dB 17.3.9.7.4 CFOC Yes No N/A (5 MHz channel spacing) AND OF1.8.7:M OF4.18.8 Transmitter constellation error < â€“25 dB 17.3.9.7.4 CFOC Yes No N/A (5 MHz channel spacing) AND OF1.8.8:M OF5: PHY Receiver Specifications OF5.1 Minimum input level sensitivity at packet error ratio (PER) = 10% with 1000 octet frames OF5.1.1 â€“82 dBm for 6 Mb/s 17.3.10.2 M Yes No OF5.1.2 â€“81 dBm for 9 Mb/s 17.3.10.2 OF1.2.2:M Yes No N/A OF5.1.3 â€“79 dBm for 12 Mb/s 17.3.10.2 M Yes No OF5.1.4 â€“77 dBm for 18 Mb/s 17.3.10.2 OF1.2.4:M Yes No N/A OF5.1.5 â€“74 dBm for 24 Mb/s 17.3.10.2 M Yes No OF5.1.6 â€“70 dBm for 36 Mb/s 17.3.10.2 OF1.2.6:M Yes No N/A OF5.1.7 â€“66 dBm for 48 Mb/s 17.3.10.2 OF1.2.7:M Yes No N/A OF5.1.8 â€“65 dBm for 54 Mb/s 17.3.10.2 OF1.2.8:M Yes No N/A OF5.2 Adjacent channel rejection 17.3.10.3 M Yes No OF5.2.1 Optional adjacent channel rejection 17.3.10.3 O Yes No OF5.3 Nonadjacent channel rejection 17.3.10.4 M Yes No OF5.3.1 Optional nonadjacent channel rejection 17.3.10.4 O Yes No OF5.4 Maximum input level 17.3.10.5 M Yes No OF5.5 CCA sensitivity 17.3.10.6 M Yes No OF5.6 Maximum input level sensitivity at packet error ratio (PER) = 10% with 1000 octet frames (10 MHz channel spacing) 2709 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.6 OFDM PHY functions (continued) Item Feature References Status Support OF5.6.1 â€“85 dBm for 3 Mb/s 17.3.10.2 CFOC Yes No N/A (10 MHz channel spacing) AND OF1.7.1:M OF5.6.2 â€“84 dBm for 4.5 Mb/s 17.3.10.2 CFOC Yes No N/A (10 MHz channel spacing) AND OF1.7.2:M OF5.6.3 â€“82 dBm for 6 Mb/s 17.3.10.2 CFOC Yes No N/A (10 MHz channel spacing) AND OF1.7.3:M OF5.6.4 â€“80 dBm for 9 Mb/s 17.3.10.2 CFOC Yes No N/A (10 MHz channel spacing) AND OF1.7.4:M OF5.6.5 â€“77 dBm for 12 Mb/s 17.3.10.2 CFOC Yes No N/A (10 MHz channel spacing) AND OF1.7.5:M OF5.6.6 â€“73 dBm for 18 Mb/s 17.3.10.2 CFOC Yes No N/A (10 MHz channel spacing) AND OF1.7.6:M OF5.6.7 â€“69 dBm for 24 Mb/s 17.3.10.2 CFOC Yes No N/A (10 MHz channel spacing) AND OF1.7.7:M OF5.6.8 â€“68 dBm for 27 Mb/s 17.3.10.2 CFOC Yes No N/A (10 MHz channel spacing) AND OF1.7.8:M OF5.7 Adjacent channel rejection 17.3.10.3 CFOC Yes No N/A (10 MHz channel spacing) AND OF1.7:M OF5.8 Nonadjacent channel rejection 17.3.10.4 CFOC Yes No N/A (10 MHz channel spacing) AND OF1.7:M OF5.9 Maximum input level 17.3.10.5 CFOC Yes No N/A (10 MHz channel spacing) AND OF1.7:M OF5.10 CCA sensitivity 17.3.10.6 CFOC Yes No N/A (10 MHz channel spacing) AND OF1.7:M OF5.11 Maximum input level sensitivity at packet error ratio (PER) = 10% with 1000 octet frames (5 MHz channel spacing) OF5.11.1 â€“85 dBm for 3 Mb/s 17.3.10.2 CFOC Yes No N/A (5 MHz channel spacing) AND OF1.8.1:M OF5.11.2 â€“84 dBm for 4.5 Mb/s 17.3.10.2 CFOC Yes No N/A (5 MHz channel spacing) AND OF1.8.2:M OF5.11.3 â€“82 dBm for 6 Mb/s 17.3.10.2 CFOC Yes No N/A (5 MHz channel spacing) AND OF1.8.3:M OF5.11.4 â€“80 dBm for 9 Mb/s 17.3.10.2 CFOC Yes No N/A (5 MHz channel spacing) AND OF1.8.4:M 2710 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.6 OFDM PHY functions (continued) Item Feature References Status Support OF5.11.5 â€“77 dBm for 12 Mb/s 17.3.10.2 CFOC Yes No N/A (5 MHz channel spacing) AND OF1.8.5:M OF5.11.6 â€“73 dBm for 18 Mb/s 17.3.10.2 CFOC Yes No N/A (5 MHz channel spacing) AND OF1.8.6:M OF5.11.7 â€“69 dBm for 24 Mb/s 17.3.10.2 CFOC Yes No N/A (5 MHz channel spacing) AND OF.1.8.7:M OF5.11.8 â€“68 dBm for 27 Mb/s 17.3.10.2 CFOC Yes No N/A (5 MHz channel spacing) AND OF1.8.8:M OF5.12 Adjacent channel rejection 17.3.10.3 CFOC Yes No N/A (5 MHz channel spacing) AND OF1.8:M OF5.13 Nonadjacent channel rejection 17.3.10.4 CFOC Yes No N/A (5 MHz channel spacing) AND OF1.8:M OF5.14 Maximum input level 17.3.10.5 CFOC Yes No N/A (5 MHz channel spacing) AND OF1.8:M OF5.15 CCA sensitivity 17.3.10.6 CFOC Yes No N/A (5 MHz channel spacing) AND OF1.8:M OF6: Transmit PHY OF6.1 Transmit: transmit on MAC request 17.3.11 M Yes No OF6.2 Transmit: format and data encoding 17.3.11 M Yes No OF6.3 Transmit: timing 17.3.11 M Yes No OF7: Receive PHY OF7.1 Receive: receive and data decoding 17.3.12 M Yes No OF8: PLME OF8.1 PLME: support PLME SAP 17.4.1 M Yes No management primitives OF8.2 PLME: support PHY MIB 17.4.2 M Yes No OF8.3 PLME: support PHY characteristics 17.4.3 M Yes No OF8.4 PLME:support PHY characteristics 17.4.2 CFOC:M Yes No N/A (dot11ChannelStartingFactor) OF9 Reserved 2711 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.6 OFDM PHY functions (continued) Item Feature References Status Support OF10: Geographic Area Specific Requirements *OF10.1 Geographic areas 17.3.8.3, M Yes No 17.3.8.4, 17.3.8.5,17. 3.9.4 OF10.2 Regulatory domain extensions 17.3.8.4.3, CFOC:M Yes No N/A 17.3.8.5, 17.3.9.2, 17.3.9.3, Annex E B.4.7 High rate, direct sequence PHY functions Item PHY feature References Status Support Are the following PHY features supported? HRDS1 Long preamble and header procedures 16.2 M Yes No HRDS1.1 Long direct sequence preamble 16.2.1 M Yes No prepended on TX HRDS1.2 Long PHY integrity check generation 16.2.3 M Yes No HRDS1.3 TX rate change capability 16.2.3.4 M Yes No HRDS1.4 Supported data rates 16.1, 16.2.3.4 M Yes No HRDS1.5 Data scrambler 16.2.4 M Yes No HRDS1.6 Scrambler initialization 16.2.4 M Yes No HRDS2 Reserved *HRDS3 Short preamble and header procedures 16.2 O Yes No HRDS3.1 Short preamble prepended on TX 16.2.2 HRDS3:M Yes No N/A HRDS3.2 Short header transmission 16.2.3.9, 16.2.3.10, HRDS3:M Yes No N/A 16.2.3.11, 16.2.3.12, 16.2.3.13, 16.2.3.14, 16.2.3.15 HRDS4 Long preamble process on RX 16.2.6 M Yes No HRDS4.1 PHY format 16.2.6 M Yes No HRDS4.2 PHY integrity check verify 16.2.6 M Yes No HRDS4.3 RX Rate change capability 16.2.6 M Yes No HRDS4.4 Data whitener descrambler 16.2.6 M Yes No *HRDS5 Short preamble process on RX 16.2.6 HRDS3:M Yes No N/A HRDS5.1 PHY format 16.2.6 HRDS5:M Yes No N/A HRDS5.2 PHY integrity check verify 16.2.6 HRDS5:M Yes No N/A HRDS5.3 RX rate change capability 16.2.6 HRDS5:M Yes No N/A HRDS5.4 Data whitener descrambler 16.2.6 HRDS5:M Yes No N/A 2712 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.7 High rate, direct sequence PHY functions (continued) Item PHY feature References Status Support *HRDS6 Operating channel capability â€” â€” â€” *HRDS6.1 North America (FCC) 16.3.6.3 HRDS6:O.3 Yes No N/A HRDS6.1.1 Channel 1 16.3.6.3 HRDS6.1:M Yes No N/A HRDS6.1.2 Channel 2 16.3.6.3 HRDS6.1:M Yes No N/A HRDS6.1.3 Channel 3 16.3.6.3 HRDS6.1:M Yes No N/A HRDS6.1.4 Channel 4 16.3.6.3 HRDS6.1:M Yes No N/A HRDS6.1.5 Channel 5 16.3.6.3 HRDS6.1:M Yes No N/A HRDS6.1.6 Channel 6 16.3.6.3 HRDS6.1:M Yes No N/A HRDS6.1.7 Channel 7 16.3.6.3 HRDS6.1:M Yes No N/A HRDS6.1.8 Channel 8 16.3.6.3 HRDS6.1:M Yes No N/A HRDS6.1.9 Channel 9 16.3.6.3 HRDS6.1:M Yes No N/A HRDS6.1.10 Channel 10 16.3.6.3 HRDS6.1:M Yes No N/A HRDS6.1.11 Channel 11 16.3.6.3 HRDS6.1:M Yes No N/A *HRDS6.2 Canada (IC) 16.3.6.3 HRDS6:O.3 Yes No N/A HRDS6.2.1 Channel 1 16.3.6.3 HRDS6.2:M Yes No N/A HRDS6.2.2 Channel 2 16.3.6.3 HRDS6.2:M Yes No N/A HRDS6.2.3 Channel 3 16.3.6.3 HRDS6.2:M Yes No N/A HRDS6.2.4 Channel 4 16.3.6.3 HRDS6.2:M Yes No N/A HRDS6.2.5 Channel 5 16.3.6.3 HRDS6.2:M Yes No N/A HRDS6.2.6 Channel 6 16.3.6.3 HRDS6.2:M Yes No N/A HRDS6.2.7 Channel 7 16.3.6.3 HRDS6.2:M Yes No N/A HRDS6.2.8 Channel 8 16.3.6.3 HRDS6.2:M Yes No N/A HRDS6.2.9 Channel 9 16.3.6.3 HRDS6.2:M Yes No N/A HRDS6.2.10 Channel 10 16.3.6.3 HRDS6.2:M Yes No N/A HRDS6.2.11 Channel 11 16.3.6.3 HRDS6.2:M Yes No N/A *HRDS6.3 Europe (ETSI) 16.3.6.3 HRDS6:O.3 Yes No N/A HRDS6.3.1 Channel 1 16.3.6.3 HRDS6.3:M Yes No N/A HRDS6.3.2 Channel 2 16.3.6.3 HRDS6.3:M Yes No N/A HRDS6.3.3 Channel 3 16.3.6.3 HRDS6.3:M Yes No N/A HRDS6.3.4 Channel 4 16.3.6.3 HRDS6.3:M Yes No N/A HRDS6.3.5 Channel 5 16.3.6.3 HRDS6.3:M Yes No N/A HRDS6.3.6 Channel 6 16.3.6.3 HRDS6.3:M Yes No N/A HRDS6.3.7 Channel 7 16.3.6.3 HRDS6.3:M Yes No N/A HRDS6.3.8 Channel 8 16.3.6.3 HRDS6.3:M Yes No N/A HRDS6.3.9 Channel 9 16.3.6.3 HRDS6.3:M Yes No N/A HRDS6.3.10 Channel 10 16.3.6.3 HRDS6.3:M Yes No N/A HRDS6.3.11 Channel 11 16.3.6.3 HRDS6.3:M Yes No N/A HRDS6.3.12 Channel 12 16.3.6.3 HRDS6.3:M Yes No N/A HRDS6.3.13 Channel 13 16.3.6.3 HRDS6.3:M Yes No N/A *HRDS6.4 France 16.3.6.3 HRDS6:O.3 Yes No N/A 2713 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.7 High rate, direct sequence PHY functions (continued) Item PHY feature References Status Support HRDS6.4.1 Channel 10 16.3.6.3 HRDS6.4:M Yes No N/A HRDS6.4.2 Channel 11 16.3.6.3 HRDS6.4:M Yes No N/A HRDS6.4.3 Channel 12 16.3.6.3 HRDS6.4:M Yes No N/A HRDS6.4.4 Channel 13 16.3.6.3 HRDS6.4:M Yes No N/A *HRDS6.5 Spain 16.3.6.3 HRDS6:O.3 Yes No N/A HRDS6.5.1 Channel 10 16.3.6.3 HRDS6.5:M Yes No N/A HRDS6.5.2 Channel 11 16.3.6.3 HRDS6.5:M Yes No N/A *HRDS6.6 Japan 16.3.6.3 HRDS6:O.3 Yes No N/A HRDS6.6.1 Channel 1 16.3.6.3 HRDS6.6:M Yes No N/A HRDS6.6.2 Channel 2 16.3.6.3 HRDS6.6:M Yes No N/A HRDS6.6.3 Channel 3 16.3.6.3 HRDS6.6:M Yes No N/A HRDS6.6.4 Channel 4 16.3.6.3 HRDS6.6:M Yes No N/A HRDS6.6.5 Channel 5 16.3.6.3 HRDS6.6:M Yes No N/A HRDS6.6.6 Channel 6 16.3.6.3 HRDS6.6:M Yes No N/A HRDS6.6.7 Channel 7 16.3.6.3 HRDS6.6:M Yes No N/A HRDS6.6.8 Channel 8 16.3.6.3 HRDS6.6:M Yes No N/A HRDS6.6.9 Channel 9 16.3.6.3 HRDS6.6:M Yes No N/A HRDS6.6.10 Channel 10 16.3.6.3 HRDS6.6:M Yes No N/A HRDS6.6.11 Channel 11 16.3.6.3 HRDS6.6:M Yes No N/A HRDS6.6.12 Channel 12 16.3.6.3 HRDS6.6:M Yes No N/A HRDS6.6.13 Channel 13 16.3.6.3 HRDS6.6:M Yes No N/A HRDS6.6.14 Channel 14 16.3.6.3 HRDS6.6:M Yes No N/A *HRDS6.7 China (Radio Administration The Radio 16.3.6.3 HRDS6:O.3 Yes No N/A Administration of P.R.China) HRDS6.7.1 Channel 1 16.3.6.3 HRDS6.7:M Yes No N/A HRDS6.7.2 Channel 2 16.3.6.3 HRDS6.7:M Yes No N/A HRDS6.7.3 Channel 3 16.3.6.3 HRDS6.7:M Yes No N/A HRDS6.7.4 Channel 4 16.3.6.3 HRDS6.7:M Yes No N/A HRDS6.7.5 Channel 5 16.3.6.3 HRDS6.7:M Yes No N/A HRDS6.7.6 Channel 6 16.3.6.3 HRDS6.7:M Yes No N/A HRDS6.7.7 Channel 7 16.3.6.3 HRDS6.7:M Yes No N/A HRDS6.7.8 Channel 8 16.3.6.3 HRDS6.7:M Yes No N/A HRDS6.7.9 Channel 9 16.3.6.3 HRDS6.7:M Yes No N/A HRDS6.7.10 Channel 10 16.3.6.3 HRDS6.7:M Yes No N/A HRDS6.7.11 Channel 11 16.3.6.3 HRDS6.7:M Yes No N/A HRDS6.7.12 Channel 12 16.3.6.3 HRDS6.7:M Yes No N/A HRDS6.7.13 Channel 13 16.3.6.3 HRDS6.7:M Yes No N/A HRDS7 Reserved HRDS8 Complementary code keying (CCK) bits to symbol mapping 2714 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.7 High rate, direct sequence PHY functions (continued) Item PHY feature References Status Support HRDS8.1 5.5 Mb/s 16.3.6.6 M Yes No HRDS8.2 11 Mb/s 16.3.6.6 M Yes No HRDS9 Reserved *HRDS10 CCA functionality 16.3.8.5 HRDS10.1 CCA Mode 1, energy only (RSSI above 16.3.8.5 HRDS10:O.4 Yes No N/A threshold) HRDS10.2 CCA Mode 4, CS with timer 16.3.8.5 HRDS10:O.4 Yes No N/A HRDS10.3 CCA Mode 5, energy detect with high 16.3.8.5 HRDS10:O.4 Yes No N/A rate CS HRDS10.4 Hold CCA busy for packet duration of a 16.2.6 M Yes No correctly received PPDU, but carrier lost during reception of MPDU. HRDS10.5 Hold CCA busy for packet duration of a 16.2.6 M Yes No correctly received, but out of spec, PPDU. HRDS11 Transmit antenna selection 16.3.5 O Yes No HRDS12 Receive antenna diversity 16.3.5 O Yes No *HRDS13 Antenna connector(s) availability 16.3.6.7 O Yes No HRDS13.1 If available (50 impedance) 16.3.6.7 HRDS13:M Yes No N/A *HRDS14 Transmit power level support 16.3.7.3 O Yes No HRDS14.1 If greater than 100 mW capability 16.3.7.3 HRDS14:M Yes No N/A HRDS15 Spurious emissions compliance 16.3.6.7 M Yes No HRDS16 TX-to-RX turnaround time 16.3.6.8 M Yes No HRDS17 RX-to-TX turnaround time 16.3.6.9 M Yes No HRDS18 Slot time 16.3.6.10 M Yes No HRDS19 ED reporting time 16.3.6.9, 16.3.8.5 M Yes No HRDS20 Minimum transmit power level 16.3.7.3 M Yes No HRDS21 Transmit spectral mask compliance 16.3.7.4 M Yes No HRDS22 Transmitted center frequency tolerance 16.3.7.5 M Yes No HRDS23 Chip clock frequency tolerance 16.3.7.6 M Yes No HRDS24 Transmit power-on ramp 16.3.7.7 M Yes No HRDS25 Transmit power-down ramp 16.3.7.7 M Yes No HRDS26 RF carrier suppression 16.3.7.8 M Yes No HRDS27 Transmit modulation accuracy 16.3.7.9 M Yes No HRDS28 Receiver minimum input level 16.3.8.2 M Yes No sensitivity HRDS29 Receiver maximum input level 16.3.8.3 M Yes No HRDS30 Receiver adjacent channel rejection 16.3.8.4 M Yes No HRDS31 MIB 16.3.2 M Yes No HRDS31.1 PHY object class 16.3.3 M Yes No 2715 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.8 Regulatory domain extensions Item Protocol capability References Status Support MD1 Country element 9.3.3.3, CFMD:M Yes No N/A 9.3.3.11, Length 9.4.2.9 Country String First Channel Number Maximum Transmit Power Level Number of Channels MD2 Inclusion of the Request information 9.3.3.10 CFMD:O Yes No N/A in the Probe Request frame MD3 Reserved MD4 Reserved MD5 Request mechanism MD5.1 Request element 9.4.2.10 CFMD:M Yes No N/A Format Element ID Order of the Requested Elemented IDs MD5.2 Extended Request element 9.4.2.11 CFMD:M Yes No N/A MD6 Entering a Regulatory Domain 10.21.2 CFMD:M Yes No N/A Lost Connectivity with its extended service set (ESS) Passive Scanning to learn Beacon information Transmit Probe Request MD7 Reserved MD8 Roaming requires Beacon frame with 11.1.4.4 CFMD:M Yes No N/A country element MD9 Actions to be taken upon the receipt 11.1.4.5 CFMD:M Yes No N/A of the Beacon frame MD10 Reserved MD11 Reserved MD12 Operating and Coverage classes 9.4.2.9 OC1:M Yes No N/A MD13 Reserved First Channel Number 10.21.3 CF3G6:M Yes No N/A MD14 Reserved Operating Class 10.21.3 CF3G6:M Yes No N/A *MD15 Operation with operating classes 10.21.3 CF3G6:M Yes No N/A MD15.1 Multiple classes in Country element 10.21.3 MD15:M Yes No N/A MD15.2 Multiple classes in (Re)Association 10.21.3 MD15:M Yes No N/A frames 2716 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.9 ERP functions Item PHY features References Status Support *ERP1 Transmit and Receive 18.3.2 CFERP:M Yes No N/A ERP-DSSS data rates 1 and 2 Mb/s and ERP- CCK data rates 5.5 and 11 Mb/s ERP1.1 Transmit and receive 18.3.2 CFERP:M Yes No N/A ERP-OFDM data rates of 6, 12, and 24 Mb/s ERP1.2 Transmit and receive 18.3.2 ERP1:O Yes No N/A ERP-OFDM data rate of 9 Mb/s ERP1.3 Transmit and receive 18.3.2 ERP1:O Yes No N/A ERP-OFDM data rate of 18 Mb/s ERP1.4 Transmit and receive 18.3.2 ERP1:O Yes No N/A ERP-OFDM data rate of 36 Mb/s ERP1.5 Transmit and receive 18.3.2 ERP1:O Yes No N/A ERP-OFDM data rate of 48 Mb/s ERP1.6 Transmit and receive 18.3.2 ERP1:O Yes No N/A ERP-OFDM data rate of 54 Mb/s ERP2 Reserved ERP3 Reserved ERP4 Support of ERP3 18.3.2 CFERP:O Yes No N/A required PPDU formats as described in reference ERP5 Able to transmit and 18.3.2 CFERP:M Yes No N/A receive long and short DSSS as well as OFDM preambles ERP6 Set SERVICE field bits 18.3.2.2 CFERP:M Yes No N/A for locked clocks, and length extension ERP7 Set B1 and B4 of long 18.3.2.2 CFERP:M Yes No N/A and short preamble PPDU SERVICE field to 0 ERP8 Set B2 to 1 in all long 18.3.2.2 CFERP:M Yes No N/A and short preamble PPDU SERVICE fields ERP9 Set B7 of the long and 18.3.2.2, CFERP:M Yes No N/A short preamble PPDU 18.3.2.3 SERVICE fields as described in the reference 2717 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.9 ERP functions (continued) Item PHY features References Status Support ERP10 Use Clause 16 (DSSS 10.26 CFERP:M Yes No N/A PHY specification for the 2.4 GHz band designated for ISM applications) or Clause 17 (High rate direct sequence spread spectrum (HR/DSSS) PHY specification) rates when using protection mechanisms ERP11 Reserved ERP12 Reserved ERP13 Reserved ERP14 Reserved ERP15 Reserved ERP16 Add signal extension of 18.3.2.4 CFERP:M Yes No N/A 6 Âµs ERP17 Simultaneous CCA on 18.3.4 CFERP:M Yes No N/A long preamble Barker, short preamble Barker, and OFDM ERP18 CCA with energy detect 18.3.4 CFERP:M Yes No N/A above threshold and CS ERP19 Reserved ERP20 Able to automatically 18.3.5 CFERP:M Yes No N/A detect format of long preamble Barker, short preamble Barker, and OFDM and receive appropriately ERP21 Comply with local 18.4.2 CFERP:M Yes No N/A regulatory frequency allocation requirements ERP22 Use frequency plan for 18.4.3 CFERP:M Yes No N/A 2.4 GHz ERP23 Comply with regulatory 18.4.4 CFERP:M Yes No N/A spurious emissions regulations ERP24 Slot time requirements 18.5.4 CFERP:M Yes No N/A ERP25 Implement Short Slot 18.5.4 CFERP:O Yes No N/A Time option ERP26 Use 10 Âµs short 18.4.6 CFERP:M Yes No N/A interframe space (SIFS) time ERP27 Comply with regulatory 18.4.7.2 CFERP:M Yes No N/A transmit power requirements ERP28 Â± 25 ppm frequency 18.4.7.4 CFERP:M Yes No N/A tolerance 2718 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.9 ERP functions (continued) Item PHY features References Status Support ERP29 Use locked clocks 18.4.7.4, CFERP:M Yes No N/A 18.4.7.5 ERP30 Tolerate input level of 18.4.8.4 CFERP:M Yes No N/A â€“20 dBm ERP31 Use specified transmit 18.5 CFERP:M Yes No N/A mask ERP32 Meet sensitivity for all 18.4.8.2 CFERP:M Yes No N/A supported data rates ERP33 Reject adjacent 18.4.8.3 CFERP:M Yes No N/A channels as in Table 18- 18 (Receiver performance requirements) in 18.3.10.2 (Receiver minimum input sensitivity) or in 17.3.8.4 (Receiver adjacent channel rejection) as appropriate ERP34 Reserved ERP35 Reserved ERP36 Reserved ERP37 Reserved ERP38 Reserved ERP39 Calculate ERP-OFDM 18.5.3.2 CFERP:M Yes No N/A TXTIME ERP40 Reserved ERP41 Reserved ERP42 Revert to long slot time 9.4.1.4 CFERP:M Yes No N/A when establishing association with a long slot time STA ERP43 Support TXVECTOR 10.3 CFERP:M Yes No N/A and RXVECTOR as described in reference ERP44 Reserved B.4.10 Spectrum management extensions Item IUT configuration References Status Support SM1 Country, Power Constraint, and 9.3.3.3, CFSM:M Yes No N/A transmit power control (TPC) 9.3.3.11, Report elements included in 9.4.2.9, Beacon and Probe Response frames 9.4.2.12, 9.4.2.15 SM1.1 Transmit Envelope element(s) in 9.4.2.162 CFSM AND Yes No N/A Beacon and Probe Response frames CFESM:M 2719 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.10 Spectrum management extensions (continued) Item IUT configuration References Status Support SM2 Spectrum Management Capability 9.4.1.4 CFSM:M Yes No N/A bit SM3 Power Capability and Supported 9.3.3.6, 9.3.3.7, CFSM:M Yes No N/A Channels elements in 11.6.1 (Re)Association frames SM4 Action frame protocol for spectrum 9.4.1.11, 9.6 CFSM:M Yes No N/A management actions SM4.1 Measurement Request frame 9.6.2.2 CFSM:M Yes No N/A SM4.2 Measurement Report frame 9.6.2.3 CFSM:M Yes No N/A SM4.3 TPC Request frame 9.6.2.4 CFSM:M Yes No N/A SM4.4 TPC Report frame 9.6.2.5 CFSM:M Yes No N/A SM4.5 Channel Switch Announcement 9.6.2.6 CFSM:M Yes No N/A frame SM5 Measurement requests SM5.1 Basic request 9.4.2.21.2 CFSM:M Yes No N/A SM5.2 CCA request 9.4.2.21.3 CFSM:O Yes No N/A SM5.3 Receive power indication (RPI) 9.4.2.21.4 CFSM:O Yes No N/A histogram SM5.4 Enabling/disabling requests and 9.4.2.21 CFSM:M Yes No N/A reports SM6 Measurement reports SM6.1 Basic report 9.4.2.22.2 CFSM:M Yes No N/A SM6.2 CCA report 9.4.2.22.3 CFSM:O Yes No N/A SM6.3 RPI histogram report 9.4.2.22.4 CFSM:O Yes No N/A SM6.4 Refusal to measure 9.4.2.22 CFSM:M Yes No N/A SM7 Quiet interval EMPTY SM7.1 AP-defined Quiet interval 9.3.3.3, (CFAP and Yes No N/A 9.3.3.11, CFSM):M 9.4.2.23, 11.6.2 SM7.2 STA-defined Quiet interval 9.3.3.3, (CFSTAofAP and Yes No N/A 9.3.3.11, CFSM):M 9.4.2.23, 11.6.2 SM7.3 STA support for Quiet interval 9.3.3.3, CFSM:M Yes No N/A 9.3.3.11, 9.4.2.23, 11.6.2 SM8 Association control based on 11.8, 11.9 (CFAP and Yes No N/A spectrum management capability CFSM):M SM9 Association control based on 11.8.2 (CFAP and Yes No N/A transmit power capability CFSM):M SM10 Maximum transmit power levels SM10.1 AP determination and 11.8.5 (CFAP AND Yes No N/A communication of local CFSM):M maximum transmit power level 2720 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.10 Spectrum management extensions (continued) Item IUT configuration References Status Support SM10.2 STA determination and 11.8.5 ((CFSTAofAP OR Yes No N/A communication of local CFIBSS) AND maximum transmit power level CFSM):M SM11 Selection of transmit power 11.8.6 CFSM:M Yes No N/A SM12 Adaptation of transmit power SM12.1 TPC report in Beacon and Probe 11.8.7 CFSM:M Yes No N/A Response frames SM13.1 Dynamic transmit power 11.8.7 CFSM:O Yes No N/A adaptation SM13 Testing channels for radar 11.9.4 CFSM:M Yes No N/A SM14 Detecting and discontinuing 11.9.5 CFSM:M Yes No N/A operations after detection of radar SM15 Requesting and reporting of 11.9.7 CFSM:M Yes No N/A measurements SM16 Autonomous reporting of radar 11.9.7 CFSM:M Yes No N/A SM17 IBSS dynamic frequency selection 9.4.2.24 (CFIBSS AND Yes No N/A (DFS) element including channel CFSM):M map SM18 DFS owner function 11.9.8 (CFIBSS AND Yes No N/A CFSM):M SM19 DFS owner recovery procedure 11.9.8 (CFIBSS AND Yes No N/A CFSM):M SM20 Channel switching procedure SM20.1 Transmission of channel switch 11.9.8 (CFAP AND Yes No N/A announcement and channel CFSM):M switching procedure by an AP SM20.2 Transmission of channel switch 11.9.8 (CFSTAofAP Yes No N/A announcement and channel AND CFSM):M switching procedure by a STA SM20.3 Reception of channel switch 11.9.8 CFSM:M Yes No N/A announcement and channel switching procedure by a STA SM20.4 Transmission of Wide 11.40.4 (CFAP AND Yes No N/A Bandwidth Channel Switch CFSM AND element in Channel CFESM):M Announcement frame and transmission of Wide Bandwidth Channel Switch subelement in Channel Switch Wrapper element in Beacon/Probe Response frames, and associated channel switching procedure by an AP 2721 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.10 Spectrum management extensions (continued) Item IUT configuration References Status Support SM20.5 Transmission of Wide 11.40.4 (CFIBSS AND Yes No N/A Bandwidth Channel Switch CFSM AND element in Channel CFESM):M Announcement frame and transmission of Wide Bandwidth Channel Switch subelement in Channel Switch Wrapper element in Beacon/Probe Response frames, and associated channel switching procedure by a STA. SM20.6 Reception of Wide Bandwidth 11.40.4 (CFSM AND Yes No N/A Channel Switch element in CFESM):M Channel Announcement frame and reception of Wide Bandwidth Channel Switch subelement in Channel Switch Wrapper element in Beacon/ Probe Response frames, and associated channel switching procedure by a STA. SM20.7 Transmission of New Transmit 11.40.4 (CFAP AND Yes No N/A Power Envelope element in CFSM AND Channel Announcement frame CFESM):M and transmission of New Transmit Power Envelope subelement in Channel Switch Wrapper element in Beacon/ Probe Response frames, and associated channel switching procedure by an AP. SM20.8 Transmission of New Transmit 11.40.4 (CFIBSS AND Yes No N/A Power Envelope element in CFSM AND Channel Announcement frame CFESM):M and transmission of New Transmit Power Envelope subelement in Channel Switch Wrapper element in Beacon/ Probe Response frames, and associated channel switching procedure by a STA. SM20.9 Reception of New Transmit 11.40.4 (CFSM AND Yes No N/A Power Envelope element in CFESM):M Channel Announcement frame and reception of New Transmit Power Envelope subelement in Channel Switch Wrapper element in Beacon/Probe Response frames, and associated channel switching procedure by a STA. SM20.1 Transmission of Future Channel 11.9.10 CFSM:O Yes No N/A 0 Guidance element by a STA. SM20.11 Reception of Future Channel 11.9.10 CFSM:O Yes No N/A Guidance element procedure by a STA. 2722 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.11 Operating classes extensions Item Protocol capability References Status Support OC1 Operating and coverage classes 9.4.2.9 CFMD AND Yes No N/A CFOC:M OC2 Operating and coverage classes 9.4.2.9, CFMD AND Yes No N/A (20 MHz channel spacing) 17.3.8.6 CFOC:M OC3 Operating and coverage classes 9.4.2.9, CFMD AND Yes No N/A (10 MHz channel spacing) 17.3.8.6 CFOC AND OF1.7:M OC4 Operating and coverage classes (5 9.4.2.9, CFMD AND Yes No N/A MHz channel spacing) 17.3.8.6 CFOC AND OF1.8:M OC5 Coverage classes 0â€“31 10.21.5 CF3G6:M Yes No N/A Coverage class operation when 10.21.5 CF3G6:M Yes No N/A not associated OC6 Power level, equivalent maximum 10.21.5 CF3G6:M Yes No N/A transmit power level and operating class Power level operation when not 10.21.5 CF3G6:M Yes No N/A associated OC7 Power level, different maximum 10.21.5 CF3G6:M Yes No N/A transmit power level and operating class Power level operation when not 10.21.5 CF3G6:M Yes No N/A associated OC 8 Operation with multiple country â€” OC1:O Yes No N/A elements B.4.12 QoS base functionality Item Protocol capability References Status Support QB1 QoS frame format QB1.1 QoS frame format 9.3.1.2â€“9.3.1.4, not CFDMG AND Yes No N/A 9.3.2.1, 9.3.3.3, CFQoS:M 9.3.3.6â€“9.3.3.9, 9.3.3.11, 9.3.3.14 QB1.2 QoS frame format 9.3.1.2, 9.3.1.4, CFDMG:M Yes No N/A 9.3.1.8, 9.3.1.9, 9.3.1.11â€“9.3.1.19, 9.3.2.1, 9.3.4.2, 9.3.3.6â€“9.3.3.9, 9.3.3.11, 9.3.3.14 QB2 Per traffic identifier (TID) 9.2.4.4, 9.2.4.5, CFQoS OR Yes No N/A duplicate detection 10.3.2.11 CFDMG:M QB3 Decode of no-acknowledgment 9.2.4.5.4, CFQoS OR Yes No N/A policy in QoS Data frames 10.22.2.7, CFDMG:M 10.22.2.11, 10.22.4.2, 10.22.4.3 2723 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.12 QoS base functionality (continued) Item Protocol capability References Status Support QB4 Block acknowledgments (block ack) QB4.1 Immediate block ack 9.3.1.8.1, CFQoS:O Yes No N/A 9.3.1.8.2, CFHT OR CFDMG Non-HT block ack is obsolete. 9.3.1.9.1, OR CFTVHT:M Support for this mechanism 9.3.1.9.2, 9.6.5, might be removed in a later 10.24 (except revision of the standard. 10.24.7 and 10.24.8), 11.5 *QB4.2 Delayed block ack 9.3.1.8.1, CFQoS:O Yes No N/A 9.3.1.8.2, Non-HT block ack is obsolete. 9.3.1.9.1, Support for this mechanism 9.3.1.9.2, 9.6.5, might be removed in a later 10.24 (except revision of the standard. 10.24.7 and 10.24.8), 11.5 QB4.3 Compressed Block Ack QB4.3.1 Compressed Block Ack 9.3.1.8.3 CFQoS:O Yes No N/A CFHT OR CFDMG OR CFTVHT:M QB4.3.2 Extended Compressed Block 9.3.1.8.4 CFDMG:O Yes No N/A Ack QB4.4 Multi-TID Block Ack 9.3.1.9.4 CFQoS:O Yes No N/A CFHT OR CFTVHT:M QB5 Automatic power save delivery 9.6.3, 11.2.3 (CFAP and Yes No N/A (APSD) CFQoS):O (CFIndepSTA and CFQoS):O QB6 Direct-link setup (DLS) 6.3.14, 9.4.2.19, (CFAP AND Yes No N/A 9.6.4, 11.7 CFQoS):M (CFSTAofAP AND CFQoS):O B.4.13 QoS enhanced distributed channel access (EDCA) Item Protocol capability References Status Support QD1 Support for four transmit queues 10.2.4.2, 10.22.2.1 not CFDMG AND Yes No N/A with a separate channel access CFQoS:M entity associated with each QD2 Per-channel access function 10.22.2.2, not CFDMG AND Yes No N/A differentiated channel access 10.22.2.4, CFQoS:M 10.22.2.11 QD3 Multiple frame transmission 10.22.2.7 CFQoS OR Yes No N/A support CFDMG:O QD4 Maintenance of within-queue 10.22.2.11 CFQoS OR Yes No N/A ordering, exhaustive CFDMG:M retransmission when sending non-QoS Data frames 2724 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.13 QoS enhanced distributed channel access (EDCA) (continued) Item Protocol capability References Status Support QD5 Interpretation of admission 9.4.2.13, 10.22.4.2 (CFSTAofAP AND Yes No N/A control mandatory (ACM) bit in (CFQoS OR EDCA Parameter Set element CFDMG)):M (CFPBSSnotPCP AND CFDMG): QD6 Contention based admission 9.4.2.14, 9.4.2.15, (CFAP AND Yes No N/A control 9.6.3.2â€“9.6.3.4, (CFQoS OR 10.22.4.2, 11.4 CFDMG)):O (CFSTAofAP AND (CFQoS OR CFDMG)):O (CFPCP AND CFDMG):O (CFPBSSnotPCP AND CFDMG):O QD7 Power management in an 11.2 (CFAP AND Yes No N/A infrastructure BSS or in an IBSS CFQoS):O (CFIndepSTA AND CFQoS):O QD8 Default EDCA parameters for 9.4.2.29, 10.22.2.2 CFOCB:M Yes No N/A communications outside context of BSS QD9 Duration/ID rules for QoS STA 9.2.5 CFQoS Yes No N/A B.4.14 QoS hybrid coordination function (HCF) controlled channel access (HCCA) Item Protocol Capability References Status Support QP1 Traffic specification (TSPEC) and 9.6.3 (CFAP AND Yes No N/A associated frame formats CFQoS):M (CFIndepSTA AND CFQoS):M QP2 HCCA rules 10.2.4.3, 10.22.3, (CFAP AND Yes No N/A 10.22.3.2â€“ CFQoS):M 10.22.3.5 (CFIndepSTA AND CFQoS):M QP3 HCCA schedule generation and 10.22.4 (CFAP AND Yes No N/A management CFQoS):M QP4 HCF frame exchange sequences 10.4.3, 10.22.2 (CFAP AND Yes No N/A CFQoS):M (CFIndepSTA AND CFQoS):M QP5 Traffic stream (TS) management 11.4 (CFAP AND Yes No N/A CFQoS):M (CFIndepSTA AND CFQoS):M 2725 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.14 QoS hybrid coordination function (HCF) controlled channel access (HCCA) (continued) Item Protocol Capability References Status Support QP6 Minimum TSPEC parameter set 10.22.4 (CFAP AND Yes No N/A CFQoS):M (CFIndepSTA AND CFQoS):M QP7 Power management in an 11.2.3.5, 11.2.3.6, (CFAP AND Yes No N/A infrastructure BSS 11.2.3.7, 11.2.3.8, CFQoS):M 11.2.3.9, (CFIndepSTA AND 11.2.3.10, CFQoS):M 11.2.3.11 B.4.15 Radio management extensions Item Protocol Capability References Status Support Are the following Radio Measurement capabilities supported? RM1 Radio Measurement 9.4.1.4 CFRM:M Yes No N/A Capability RM2 Action frame protocol for 9.6 CFRM:M Yes No N/A measurements RM2.1 Radio Measurement 9.6.7.2 CFRM:M Yes No N/A Request frame RM2.2 Radio Measurement 9.6.7.3 CFRM:M Yes No N/A Report frame RM2.3 Link Measurement 9.6.7.4 CFRM:M Yes No N/A Request frame RM2.4 Link Measurement 9.6.7.5 CFRM:M Yes No N/A Report frame RM2.4.1 Link Measurement 9.6.7.5 not CF DMG Yes No N/A Report frame AND CFRM:M RM2.4.2 Link Measurement 9.6.7.5, 9.4.2.149, CFDMG Yes No N/A Report frame 9.4.2.150, 10.39 AND CFRM:M RM2.5 Neighbor Report Request RM2.5.1 Generate and transmit 9.6.7.6 (CFRM Yes No N/A Neighbor Report Request AND CFSTAofAP ):M RM2.5.2 Receive and process 9.6.7.6 (CFRM Yes No N/A Neighbor Report Request AND CFAP):M RM2.6 Neighbor Report Response 2726 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.15 Radio management extensions (continued) Item Protocol Capability References Status Support RM2.6.1 Generate and transmit 9.4.2.37, 9.6.7.7 (CFRM Yes No N/A Neighbor Report AND Response CFAP):M RM2.6.2 Receive and process 9.4.2.37, 9.6.7.7 (CFRM Yes No N/A Neighbor Report AND Response CFSTAofAP ):M RM3 General protocol for 9.4.2.21, 9.4.2.22, CFRM:M Yes No N/A requesting and reporting 11.11, 11.11.6 of measurements RM3.1 Parallel Measurements 9.4.2.21, 9.4.2.22, CFRM:M Yes No N/A 11.11.6 RM3.2 Use of Enable, Request 9.4.2.21, 11.11.6, CFRM:M Yes No N/A and Report bits to enable/ 11.11.8 disable measurement requests and triggered autonomous reports Measurement Requests RM3.3 Enable Autonomous 9.4.2.21, 11.11.8 CFRM:M Yes No N/A Report RM3.4 Duration Mandatory 9.4.2.21, 11.11.4 CFRM:M Yes No N/A RM3.5 Incapable Indication 9.4.2.22 CFRM:M Yes No N/A RM3.6 Refused Indication 9.4.2.22, 11.11.5 CFRM:M Yes No N/A RM3.7 Repeated Measurement 9.6.7.2, 11.11.7 CFRM:M Yes No N/A RM3.8 Measurement Pause 9.4.2.21.12, CFRM:M Yes No N/A 11.11.9.7 RM4 Beacon Measurement 11.11, 11.11.9.1 CFRM:M Yes No N/A Type RM4.1 Beacon request 9.4.2.21.7 CFRM:M Yes No N/A RM4.2 Passive Measurement 9.4.2.21.7, 11.11.9.1 CFRM:M Yes No N/A mode RM4.3 Active Measurement 9.4.2.21.7, 11.11.9.1 CFRM:M Yes No N/A mode RM4.4 Beacon table mode 9.4.2.21.7, 11.11.9.1 CFRM:M Yes No N/A RM4.5 Reporting Conditions 9.4.2.21.7 CFRM:O Yes No N/A RM4.6 Beacon report 9.4.2.21.7 CFRM:M Yes No N/A RM4.7 Reporting Detail 9.4.2.21.7, CFRM:O Yes No N/A 9.4.2.22.7, 9.4.2.36 * RM5 Frame Measurement 11.11, 11.11.9.2 CFRM:O Yes No N/A Type RM5.1 Frame request 9.4.2.21.8 (CFRM Yes No N/A AND RM5):M 2727 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.15 Radio management extensions (continued) Item Protocol Capability References Status Support RM5.2 Frame report 9.4.2.22.8 (CFRM Yes No N/A AND RM5):M RM6 Channel Load 11.11, 11.11.9.3 CFRM:M Yes No N/A Measurement Type RM6.1 Channel Load request 9.4.2.21.5 CFRM:M Yes No N/A RM6.2 Channel Load report 9.4.2.22.5 CFRM:M Yes No N/A RM7 Noise Histogram 11.11, 11.11.9.4 CFRM:M Yes No N/A Measurement Type RM7.1 Noise Histogram request 9.4.2.21.6 CFRM:M Yes No N/A RM7.2 Noise Histogram report 9.4.2.22.6 CFRM:M Yes No N/A RM8 STA Statistics 11.11, 11.11.9.5 CFRM:M Yes No N/A Measurement Type RM8.1 STA Statistics request 9.4.2.21.9 CFRM:M Yes No N/A RM8.2 STA Statistics report 9.4.2.22.9 CFRM:M Yes No N/A RM9 LCI Measurement Type 11.11, 11.11.9.6 CFRM:M Yes No N/A RM9.1 LCI request 9.4.2.21.10 CFRM:M Yes No N/A RM9.1.1 Location Subject 9.4.2.21.10 CFRM:M Yes No N/A RM9.1.1.1 Location Subject third 9.4.2.21.10 CFRM:O Yes â–¡ No â–¡ N/A â–¡ party RM9.2 LCI report 9.4.2.22.10 CFRM:M Yes No N/A RM9.3 Azimuth 11.11, 11.11.9.6 CFRM:O Yes No N/A RM9.3.1 Azimuth Request 9.4.2.21.10 CFRM:O Yes No N/A RM9.3.2 Azimuth Response 9.4.2.22.10 CFRM:O Yes No N/A *RM10 Transmit Stream/ 11.11, 11.11.9.8 (CFRM Yes No N/A Category Measurement AND Type (CFQoS OR CFDMG)):O RM10.1 Transmit Stream/ 9.4.2.21.11 RM10:M Yes No N/A Category Measurement request RM10.2 Transmit Stream/ 9.4.2.22.11 RM10:M Yes No N/A Category Measurement report RM10.3 Triggered Transmit 9.4.2.22.11, RM10:O Yes No N/A Stream/Category 11.11.9.8 Measurement report RM11 AP Channel report 9.4.2.9, 9.4.2.36 (CFRM Yes No N/A AND CFAP):M 2728 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.15 Radio management extensions (continued) Item Protocol Capability References Status Support RM11.1 Generate and transmit 9.3.3.3, 9.3.3.11, (CFRM Yes No N/A AP Channel report 9.4.2.36 AND CFAP):M RM11.2 Receive and process AP 9.3.3.3, 9.3.3.11, (CFRM Yes No N/A Channel report 9.4.2.36 AND CFSTAofAP ):M RM12 Neighbor report 11.11, 11.11.10 CFRM:M Yes No N/A procedure RM12.1 Neighbor report 11.11.10.2, CFRM:M Yes No N/A procedure 11.11.10.3 RM12.2 TSF Offset in Neighbor 9.4.2.37, 11.11.10.3 CFRM:O Yes No N/A report RM13 RCPI Measurement RM13.1 RCPI Measurement for 15.4.6.6 (CFRM Yes No N/A DSSS PHY at 2.4 GHz AND CFDSSS):M RM13.2 RCPI Measurement for 17.2.3.6, 17.3.10.7 (CFRM Yes No N/A OFDM PHY at 5 GHz AND CFOFDM): M RM13.3 RCPI Measurement for 16.3.8.6 (CFRM Yes No N/A HR DSSS PHY at 2.4 AND GHz CFHRDSSS ):M RM13.4 RCPI Measurement for 18.2 (CFRM Yes No N/A Extended Rate PHY at AND 2.4 GHz CFERP):M RM14 RCPI Measurement during Active Scanning RM14.1 Respond with RCPI 11.1.4.3.2 (CFRM Yes No N/A element when requested AND (CFQoS OR CFDMG) AND CFAP):M RM14.2 Measurement of RCPI on 11.1.4.3.2 (CFRM Yes No N/A Probe Request frames AND (CFQoS OR CFDMG) AND CFAP):O RM15 RSNI Measurement 9.4.2.41 (CFRM Yes No N/A AND RM13):M RM16 TPC Information in Beacon and Probe Response frames 2729 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.15 Radio management extensions (continued) Item Protocol Capability References Status Support RM16.1 Country and TPC Report 9.3.3.3, 9.3.3.11, CFRM:M Yes No N/A elements included in 9.4.2.9, 9.4.2.17, Beacon and Probe 11.8 Response frames RM16.2 Power Constraint 9.3.3.3, 9.3.3.11, CFRM:O Yes No N/A element included in 9.4.2.14 Beacon and Probe Response frames RM17 Power Capability 9.3.3.6, 9.3.3.7, CFRM:M Yes No N/A elements in 11.9.2 (Re)Association frames RM18 Management Information Base RM18.1 dot11RadioMeasurement Annex C (CFRM Yes No N/A AND CFAP):M RM18.2 dot11SMTRMRequest Annex C (CFRM Yes No N/A AND CFAP):O RM18.3 dot11SMTRMReport Annex C (CFRM Yes No N/A AND CFAP):O RM18.4 dot11SMTRMConfig Annex C (CFRM Yes No N/A AND CFAP):O RM19 Measurement Pilot frame 6.3.3.2, 9.4.1.18, CFRM:O Yes No N/A 9.4.2.46, 11.8, 11.11.14, 11.11.5 RM20 BSS Average Access 9.3.3.3, 9.3.3.11, (CFAP AND Yes No N/A Delay elements included 9.4.2.39 CFRM):M in Beacon and Probe Response frames RM21 Antenna elements 9.3.3.3, 9.3.3.11, CFRM:M Yes No N/A included in Beacon and 9.4.2.40 Probe Response frames RM22 Measurement Pilot 9.3.3.11, 9.4.2.42, CFRM:O Yes No N/A Transmission element 9.4.2.46 and Multiple BSSID element, if required, included in Probe Response frame RM23 Quiet interval RM23.1 AP-defined Quiet 9.3.3.3, 9.3.3.11, (CFAP AND Yes No N/A Interval 9.4.2.23, 11.9.3 CFRM):M RM23.2 STA-defined Quiet 9.3.3.3, 9.3.3.11, (CFSTAofA Yes No N/A Interval 9.4.2.23, 11.9.3 P AND CFRM):M RM23.3 STA support for Quiet 9.3.3.3, 9.3.3.11, CFRM:M Yes No N/A Interval 9.4.2.23, 11.9.3 2730 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.15 Radio management extensions (continued) Item Protocol Capability References Status Support RM24 BSS Available 9.4.2.43 (CFAP AND Yes No N/A Admission Capacity (CFQoS OR CFDMG) AND CFRM):M RM25 BSS AC Access Delay 9.3.3.3, 9.3.3.11, not CFDMG Yes No N/A 9.4.2.44 AND (CFAP AND CFQoS AND CFRM):M RM26 BSS AC Access Delay 9.3.3.3, 9.3.3.11, CFDMG Yes No N/A 9.4.2.44 AND CFAP AND CFRM:M RM27 Directional channel 11.11, 11.32 quality measurement RM27.1 Directional Channel 8.4.2.23.16, 11.32 (CFRM Yes No N/A Quality request AND DMG- M19):O RM27.2 Directional Channel 8.4.2.24.15, 11.32 (CFRM Yes No N/A Quality report AND DMG- M19):M RM28 Directional measurement 11.11 type RM28.1 Directional Measurement 9.4.2.21.17 (CFRM Yes No N/A request AND CFDMG):O RM28.2 Directional Measurement 9.4.2.22.16 (CFRM Yes No N/A report AND CFDMG):O RM29 Directional statistics 11.11 measurement type RM29.1 Directional Statistics 9.4.2.21.18 (CFRM Yes No N/A Measurement Type AND CFDMG):O RM29.2 Directional Statistics 9.4.2.22.17 (CFRM Yes No N/A Measurement Type AND CFDMG):O 2731 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.16 DSE functions Item Protocol capability References Status Support *DSE1 Fixed STA operation with RegLoc 11.12.3 CF3G6:O.1 Yes No N/A *DSE2 Enabling STA operation with RegLoc 11.12.3 CF3G6:O.1 Yes No N/A DSE2.1 Enabling STA creation of DSE service 11.12.4 DSE2:M Yes No N/A area DSE2.2 Enabling STA operation with DSE 11.12.3 DSE2:M Yes No N/A *DSE3 Dependent STA operation with DSE 11.12.5 CF3G6:O.1 Yes No N/A DSE3.1 Dependent STA enablement 11.12.5 DSE3:M Yes No N/A DSE3.2 Dependent STA DSE time to 11.12.5 DSE3:M Yes No N/A enablement DSE3.3 Dependent STA DSE time to not 11.12.5 DSE3:M Yes No N/A transmit DSE3.4 Dependent STA DSE Registered 11.12.5 DSE3:M Yes No N/A Location Announcement frame DSE3.5 Dependent STA MLME- 6.3.7.5 DSE3:M Yes No N/A ASSOCIATE.response primitive DSE DSE3.6 Dependent STA MLME- 6.3.8.5 DSE3:M Yes No N/A REASSOCIATE.response primitive DSE DSE4 DSE request report procedure 11.12.5 (CF3G6 AND Yes No N/A Transmission of DSE measurement CFAP):M request by an AP 11.12.5 Yes No N/A Transmission of DSE measurement (CF3G6 AND report by a STA CFSTAofAP):M DSE5 STA association procedure 10.21.3, (CF3G6 AND Yes No N/A Transmission of Association Request 11.3.5.2, CFSTAofAP):M frame with Supported Operating 11.3.5.3 Classes element by a STA Transmission of Association Response (CF3G6 AND Yes No N/A frame with Supported Operating CFAP):M Classes element by an AP DSE6 STA reassociation procedure 11.3.5.4, (CF3G6 AND Yes No N/A Transmission of Reassociation Request 11.3.5.5 CFSTAofAP):M frame with Supported Operating Classes element by a STA Transmission of Reassociation (CF3G6 AND Yes No N/A Response frame with Supported CFAP):M Operating Classes element by an AP DSE7 Probe request procedure 11.10.1 CF3G6 AND Yes No N/A Transmission of Probe Request frame CFSTAofAP:M with Supported Operating Classes element by a STA DSE8 Probe response procedure 11.10.1 CF3G6 AND Yes No N/A Transmission of Probe Response frame CFAP:M with Supported Operating Classes element by an AP DSE9 Extended channel switching procedure 11.10.1 2732 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.16 DSE functions (continued) Item Protocol capability References Status Support DSE9.1 Transmission of extended channel 11.10.3 (CF3G6 AND Yes No N/A switch announcement frame/element CFAP):M and extended channel switching (CFAP AND procedure by an AP. CFVHT):M (CFAP AND CFTVHT):M DSE9.2 Transmission of extended channel 11.10.3 (CF3G6 AND Yes No N/A switch announcement frame/element CFIBSS):M and extended channel switching (CFIBSS AND procedure by a STA. CFVHT):M (CFIBSS AND CFTVHT):M DSE9.3 Reception of extended channel switch 11.10.3 CF3G6:M Yes No N/A announcement frame/element and CFVHT:M extended channel switching procedure CFTVHT:M by a STA. DSE9.4 Transmission of Wide Bandwidth 11.40.4 (CFAP AND Yes No N/A Channel Switch element in Extended CFESM):M Channel Announcement frame and transmission of Wide Bandwidth Channel Switch subelement in Channel Switch Wrapper element in Beacon/ Probe Response frames, and associated extended channel switching procedure by an AP. DSE9.5 Transmission of Wide Bandwidth 11.40.4 (CFIBSS AND Yes No N/A Channel Switch element in Extended CFESM):M Channel Announcement frame and transmission of Wide Bandwidth Channel Switch subelement in Channel Switch Wrapper element in Beacon/ Probe Response frames, and associated extended channel switching procedure by a STA. DSE9.6 Reception of Wide Bandwidth Channel 11.40.4 CFESM:M Yes No N/A Switch element in Extended Channel Announcement frame and reception of Wide Bandwidth Channel Switch subelement in Channel Switch Wrapper element in Beacon/Probe Response frames, and associated extended channel switching procedure by a STA. DSE9.7 Transmission of New Transmit Power 11.40.4 (CFAP AND Yes No N/A Envelope element in Extended CFESM):M Channel Announcement frame and transmission of New Transmit Power Envelope subelement in Channel Switch Wrapper element in Beacon/ Probe Response frames, and associated extended channel switching procedure by an AP. 2733 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.16 DSE functions (continued) Item Protocol capability References Status Support DSE9.8 Transmission of New Transmit Power 11.40.4 (CFIBSS AND Yes No N/A Envelope element in Extended CFESM):M Channel Announcement frame and transmission of NewTransmit Power Envelope subelement in Channel Switch Wrapper element in Beacon/ Probe Response frames, and associated extended channel switching procedure by a STA. DSE9.9 Reception of New Transmit Power 11.40.4 CFESM:M Yes No N/A Envelope element in Extended Channel Announcement frame and reception of New Transmit Power Envelope subelement in Channel Switch Wrapper element in Beacon/ Probe Response frames, and associated extended channel switching procedure by a STA. DSE9.10 Transmission of New Country element 11.40.4 (CFAP AND Yes No N/A in Extended Channel Announcement CFESM):M frame and transmission of New Country subelement in Channel Switch Wrapper element in Beacon/Probe Response frames, and associated extended channel switching procedure by an AP. DSE9.11 Transmission of New Country element 11.40.4 (CFIBSS AND Yes No N/A in Extended Channel Announcement CFESM):M frame and transmission of New Country subelement in Channel Switch Wrapper element in Beacon/Probe Response frames, and associated extended channel switching procedure by a STA. DSE9.12 Reception of New Country element in 11.40.4 CFESM:M Yes No N/A Extended Channel Announcement frame and reception of New Country subelement in Channel Switch Wrapper element in Beacon/Probe Response frames, and associated extended channel switching procedure by a STA. DSE10 DSE power constraint procedure 11.12.5 (CF3G6 AND Yes No N/A Transmission of DSE power constraint CFAP):M announcement by an enabling STA 11.12.5 Reception of DSE power constraint Yes No N/A announcement by a dependent STA CF3G6:M 2734 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.17 High-throughput (HT) features B.4.17.1 HT MAC features Item Protocol capability References Status Support Are the following MAC protocol features supported? HTM1 HT capabilities signaling HTM1.1 HT Capabilities element 9.4.2.56.1 CFHT:M Yes No N/A CFTVHT:M HTM1.2 Signaling of STA capabilities in 9.3.3.6, 9.3.3.8, (CFHT AND Yes No N/A Probe Request, (Re)Association 9.3.3.10, CFIndepSTA): Request frames 9.4.2.56 M (CFTVHT AND CFIndepSTA): M HTM1.3 Signaling of STA and BSS 9.3.3.3, 9.3.3.7, (CFHT AND Yes No N/A capabilities in Beacon, Probe 9.3.3.9, CFAP):M Response, (Re)Association 9.3.3.11, (CFTVHT Response frames 9.4.2.56 AND CFAP):M HTM2 Signaling of HT operation 9.4.2.57 (CFHT AND Yes No N/A CFAP):M (CFTVHT AND CFAP):M HTM3 MPDU aggregation HTM3.1 Reception of A-MPDU 9.4.2.56.3, CFHT:M Yes No N/A 10.13.2, 12.5 HTM3.2 A-MPDU format 9.7.1 CFHT:M Yes No N/A HTM3.3 A-MPDU contents 9.7.3 CFHT:M Yes No N/A HTM3.4 A-MPDU frame exchange 10.22.2.7 CFHT:M Yes No N/A sequences HTM3.5 Transmission of A-MPDU 9.4.2.56.3, 12.5 CFHT:O Yes No N/A CFVHT:M HTM4 MSDU aggregation HTM4.1 Reception of A-MSDUs 9.2.4.5, 9.3.2.2 CFHT:M Yes No N/A HTM4.2 A-MSDU format 9.3.2.2 CFHT:M Yes No N/A HTM4.3 A-MSDU content 9.3.2.2 CFHT:M Yes No N/A HTM4.4 Transmission of A-MSDUs 9.2.4.5, 9.3.2.2 CFHT:O Yes No N/A HTM5 Block Ack HTM5.1 Block ack mechanism 9.3.1.8, 9.3.1.9, CFHT:M Yes No N/A 9.4.1.14, 10.24, CFTVHT:M 11.16 HTM5.2 Use of compressed bitmap between 9.3.1.9.3, CFHT:M Yes No N/A HT STAs 10.24.6 CFTVHT:M HTM5.3 HT-immediate block ack extensions 10.24.7 CFHT:M Yes No N/A CFTVHT:M 2735 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.17.1 HT MAC features (continued) Item Protocol capability References Status Support HTM5.4 HT-delayed block ack extensions 10.24.8 CFHT AND Yes No N/A QB4.2:O HT-delayed block ack is obsolete. Support for this mechanism might CFTVHT AND be removed in a later revision of the QB4.2:O standard. HTM5.5 Multiple TID Block Ack 9.3.1.8.5, PC37:M Yes No N/A 9.3.1.9.4, 10.29.2.7 HTM6 Protection mechanisms for different HT PHY options HTM6.1 Protection of RIFS PPDUs in the 10.26.3.3 CFHT:M Yes No N/A presence of non-HT STAs HTM6.2 Protection of RIFS PPDUs in an 10.26.3.3 CFHT:M Yes No N/A IBSS HTM6.3 Protection of HT-greenfield PPDUs 10.26.3.1 HTP1.3:M Yes No N/A in the presence of non-HT STAs HTM6.4 Protection of HT-greenfield PPDUs 10.26.3.1 CFHT:M Yes No N/A in an IBSS *HTM7 L-SIG TXOP protection mechanism 10.26.5 CFHT:O Yes No N/A The L-SIG TXOP protection mechanism is obsolete. Consequently, the L-SIG TXOP protection mechanism might be removed in a later revision of this standard. HTM7.1 Update NAV according to L-SIG 10.26.5.4 HTM7:M Yes No N/A HTM8 Duration/ID rules for A-MPDU 9.7.3 CFHT:M Yes No N/A HTM9 Truncation of TXOP as TXOP holder 10.22.2.9 CFHT:O Yes No N/A CFTVHT:O HTM10 Reception of +HTC frames 9.2.4.1.10, CFHT:O Yes No N/A 9.4.2.56.5, 10.9 CFTVHT:O *HTM11 Reverse direction (RD) aggregation 10.28 CFHT:O Yes No N/A exchanges CFTVHT:O HTM11.1 Constraints regarding responses 10.28.4 HTM11:M Yes No N/A HTM12 Link adaptation HTM12.1 Use of the HT Control field for link 9.2.4.6, CFHT:O Yes No N/A adaptation in immediate response 9.3.3.15, CFTVHT:O exchange 10.31.2 HTM12.2 Link adaptation using explicit 9.3.3.15, CFHT:O Yes No N/A feedback mechanism 10.32.3 CFTVHT:O HTM13 Transmit beamforming *HTM13.1 Transmission of beamformed 10.32 CFHT:O Yes No N/A PPDUs *HTM13.2 Reception of beamformed PPDUs 10.32 CFHT:O Yes No N/A *HTM13.3 Initiate transmit beamforming frame 10.32.2 HTM13.1:O Yes No N/A exchange with implicit feedback HTM13.3.1 Reception of sounding PPDUs 10.32.2 HTM13.3:M Yes No N/A 2736 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.17.1 HT MAC features (continued) Item Protocol capability References Status Support *HTM13.4 Response to transmit beamforming 10.32.2 HTM13.2:O Yes No N/A frame exchange with implicit feedback HTM13.4.1 Transmission of sounding PPDUs 10.32.2 HTM13.4:M Yes No N/A *HTM13.5 Initiate transmit beamforming frame 9.6.12.6, HTM13.1:O Yes No N/A exchange with explicit feedback 10.32.3 HTM13.5.1 Transmission of sounding PPDUs 10.32.3 HTM13.5:M Yes No N/A *HTM13.6 Respond to transmit beamforming 10.32.3 HTM13.2:O Yes No N/A frame exchange with explicit feedback HTM13.6.1 Transmission of Action No Ack 9.6.12.6, HTM13.6:O.1 Yes No N/A +HTC frame including Action 10.32.3 payload of type CSI HTM13.6.2 Transmission of Action No Ack 9.6.12.7, HTM13.6:O.1 Yes No N/A +HTC frame including Action 10.32.3 payload of type â€œNoncompressed beamformingâ€ HTM13.6.3 Transmission of Action No Ack 9.6.12.8, HTM13.6:O.1 Yes No N/A +HTC frame including Action 10.32.3 payload of type â€œCompressed beamformingâ€ *HTM13.7 Calibration procedure 9.3.3.15, HTM13:O Yes No N/A 10.32.2.4 HTM14 Antenna selection (ASEL) 9.2.4.6, CFHT:O Yes No N/A 9.4.2.56.7, 9.6.12.9, 10.33 *HTM15 Null data packet (NDP) 10.34 CFHT:O Yes No N/A HTM16 Space-time block coding (STBC) support HTM16.1 STBC beacon transmission 11.1.3.2 HTP2.11:O Yes No N/A The use of the STBC beacon transmission mechanism is deprecated. HTM16.2 Dual CTS protection 10.3.2.8 HTP2.11:O Yes No N/A The use of the dual CTS mechanism is deprecated. HTM17 SM power save support *HTM17.1 AP support for non-AP STA 11.2.6 (CFHT AND Yes No N/A dynamic and static SM power save CFAP):M mode (CFTVHT AND CFAP):M *HTM17.2 STA support for local dynamic and 11.2.6 (CFHT AND Yes No N/A static SM power save mode CFIndepSTA): O (CFTVHT AND CFIndepSTA): O 2737 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.17.1 HT MAC features (continued) Item Protocol capability References Status Support HTM17.3 Transmit SM power save state 9.6.12.3, 11.2.6 HTM17.2:M Yes No N/A information using HT Capabilities element, or SM Power Save frame HTM17.4 Receive SM power save state 11.2.6 HTM17.1:M Yes No N/A information and support frame exchanges with STAs in SM power save mode HTM18 Mechanisms for coexistence of 11.16 CFHT:M Yes No N/A 20 MHz and 40 MHz channels HTM19 Channel selection methods for 11.16.3 (HTP2.3.4 Yes No N/A 20/40 MHz operation AND CFAP):M HTM20 20/40 MHz operation 11.16 HTP2.3.4:M Yes No N/A HTM21 Phased coexistence operation (PCO) The PCO mechanism is obsolete. Consequently, the PCO mechanism might be removed in a later revision of this standard. *HTM21.1 PCO capability at AP 11.17 (CFHT AND Yes No N/A CFAP):O HTM21.1.1 Rules for operation at a PCO 9.6.12.5, HTM21.1:M Yes No N/A active AP 11.17.2 *HTM21.2 STA support for PCO mode 11.17 (CFHT AND Yes No N/A CFIndepSTA): O HTM21.2.1 Rules for operation at PCO active 9.6.12.5, HTM21.2:M Yes No N/A STA 11.17.3 HTM22 Management information base (MIB) HTM22.1 dot11PhyHTComplianceGroup Annex C CFHT:M Yes No N/A HTM22.2 dot11PhyMCSGroup Annex C CFHT:M Yes No N/A B.4.17.2 HT PHY features Item Protocol capability References Status Support Are the following PHY protocol features supported? HTP1 PHY operating modes HTP1.1 Operation according to 18 19.1.4 CFHT:M Yes No N/A (Orthogonal frequency division multiplexing (OFDM) PHY specification) and/or Clause 19 (Extended Rate PHY (ERP) specification) HTP1.2 HT-mixed format 19.1.4 CFHT:M Yes No N/A *HTP1.3 HT-greenfield format 19.1.4 CFHT:O Yes No N/A HTP2 PHY frame format 2738 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.17.2 HT PHY features (continued) Item Protocol capability References Status Support HTP2.1 HT-mixed format PPDU format 19.3.2 CFHT:M Yes No N/A HTP2.2 HT-greenfield PPDU format 19.3.2 HTP1.3:M Yes No N/A HTP2.3 Modulation and coding schemes (MCS) HTP2.3.1 MCS 0 to MCS 7 in 20 MHz with 800 ns guard interval (GI) HTP2.3.1.1 Support for 20 MHz with 800 ns 19.3.5, 19.5 CFHT:M Yes No N/A GI MCS index 0 HTP2.3.1.2 Support for 20 MHz with 800 ns 19.3.5, 19.5 CFHT:M Yes No N/A GI MCS index 1 HTP2.3.1.3 Support for 20 MHz with 800 ns 19.3.5, 19.5 CFHT:M Yes No N/A GI MCS index 2 HTP2.3.1.4 Support for 20 MHz with 800 ns 19.3.5, 19.5 CFHT:M Yes No N/A GI MCS index 3 HTP2.3.1.5 Support for 20 MHz with 800 ns 19.3.5, 19.5 CFHT:M Yes No N/A GI MCS index 4 HTP2.3.1.6 Support for 20 MHz with 800 ns 19.3.5, 19.5 CFHT:M Yes No N/A GI MCS index 5 HTP2.3.1.7 Support for 20 MHz with 800 ns 19.3.5, 19.5 CFHT:M Yes No N/A GI MCS index 6 HTP2.3.1.8 Support for 20 MHz with 800 ns 19.3.5, 19.5 CFHT:M Yes No N/A GI MCS index 7 HTP2.3.2 MCS 8 to MCS 15 in 20 MHz with 800 ns GI HTP2.3.2.1 Support for 20 MHz with 800 ns 19.3.5, 19.5 (CFHT AND Yes No N/A GI MCS index 8 CFAP):M HTP2.3.2.2 Support for 20 MHz with 800 ns 19.3.5, 19.5 (CFHT AND Yes No N/A GI MCS index 9 CFAP):M HTP2.3.2.3 Support for 20 MHz with 800 ns 19.3.5, 19.5 (CFHT AND Yes No N/A GI MCS index 10 CFAP):M HTP2.3.2.4 Support for 20 MHz with 800 ns 19.3.5, 19.5 (CFHT AND Yes No N/A GI MCS index 11 CFAP):M HTP2.3.2.5 Support for 20 MHz with 800 ns 19.3.5, 19.5 (CFHT AND Yes No N/A GI MCS index 12 CFAP):M HTP2.3.2.6 Support for 20 MHz with 800 ns 19.3.5, 19.5 (CFHT AND Yes No N/A GI MCS index 13 CFAP):M HTP2.3.2.7 Support for 20 MHz with 800 ns 19.3.5, 19.5 (CFHT AND Yes No N/A GI MCS index 14 CFAP):M HTP2.3.2.8 Support for 20 MHz with 800 ns 19.3.5, 19.5 (CFHT AND Yes No N/A GI MCS index 15 CFAP):M HTP2.3.3 Transmit and receive support for 19.3.5, 19.5 CFHT:O Yes No N/A 400 ns GI *HTP2.3.4 Operation at 40 MHz 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5 Support for MCS with indices 16 to 76 HTP2.3.5.1 Support for MCS with index 16 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.2 Support for MCS with index 17 19.3.5, 19.5 CFHT:O Yes No N/A 2739 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.17.2 HT PHY features (continued) Item Protocol capability References Status Support HTP2.3.5.3 Support for MCS with index 18 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.4 Support for MCS with index 19 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.5 Support for MCS with index 20 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.6 Support for MCS with index 21 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.7 Support for MCS with index 22 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.8 Support for MCS with index 23 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.9 Support for MCS with index 24 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.10 Support for MCS with index 25 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.11 Support for MCS with index 26 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.12 Support for MCS with index 27 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.13 Support for MCS with index 28 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.14 Support for MCS with index 29 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.15 Support for MCS with index 30 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.16 Support for MCS with index 31 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.17 Support for MCS with index 32 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.18 Support for MCS with index 33 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.19 Support for MCS with index 34 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.20 Support for MCS with index 35 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.21 Support for MCS with index 36 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.22 Support for MCS with index 37 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.23 Support for MCS with index 38 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.24 Support for MCS with index 39 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.25 Support for MCS with index 40 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.26 Support for MCS with index 41 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.27 Support for MCS with index 42 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.28 Support for MCS with index 43 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.29 Support for MCS with index 44 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.30 Support for MCS with index 45 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.31 Support for MCS with index 46 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.32 Support for MCS with index 47 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.33 Support for MCS with index 48 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.34 Support for MCS with index 49 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.35 Support for MCS with index 50 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.36 Support for MCS with index 51 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.37 Support for MCS with index 52 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.38 Support for MCS with index 53 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.39 Support for MCS with index 54 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.40 Support for MCS with index 55 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.41 Support for MCS with index 56 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.42 Support for MCS with index 57 19.3.5, 19.5 CFHT:O Yes No N/A 2740 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.17.2 HT PHY features (continued) Item Protocol capability References Status Support HTP2.3.5.43 Support for MCS with index 58 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.44 Support for MCS with index 59 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.45 Support for MCS with index 60 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.46 Support for MCS with index 61 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.47 Support for MCS with index 62 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.48 Support for MCS with index 63 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.49 Support for MCS with index 64 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.50 Support for MCS with index 65 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.51 Support for MCS with index 66 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.52 Support for MCS with index 67 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.53 Support for MCS with index 68 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.54 Support for MCS with index 69 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.55 Support for MCS with index 70 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.56 Support for MCS with index 71 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.57 Support for MCS with index 72 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.58 Support for MCS with index 73 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.59 Support for MCS with index 74 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.60 Support for MCS with index 75 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.3.5.61 Support for MCS with index 76 19.3.5, 19.5 CFHT:O Yes No N/A HTP2.4 PHY timing parameters HTP2.4.1 Values in non-HT 20 MHz channel 19.3.6 CFHT:M Yes No N/A HTP2.4.2 Values in 20 MHz HT channel 19.3.6 CFHT:M Yes No N/A HTP2.4.3 Values in 40 MHz channel 19.3.6 HTP2.3.4:M Yes No N/A HTP2.5 HT Preamble field definition and coding HTP2.5.1 HT-mixed format preamble 19.3.9.2 CFHT:M Yes No N/A HTP2.5.2 HT-greenfield preamble 19.3.9.5 HTP1.3:M Yes No N/A HTP2.5.3 Extension HT Long Training 19.3.9.4.6 CFHT:O Yes No N/A fields (HT-ELTFs) HTP2.6 HT Data field definition and 19.3.11 CFHT:M Yes No N/A coding HTP2.6.1 Use of LDPC codes 19.3.11.7 CFHT:O Yes No N/A HTP2.7 Beamforming 19.3.12 CFHT:O Yes No N/A HTP2.8 Sounding PPDUs HTP2.8.1 HT preamble format for sounding 19.3.13 CFHT:O Yes No N/A PPDUs HTP2.8.2 Sounding with an NDP 19.3.13.2 HTM15:O Yes No N/A HTP2.8.3 Sounding PPDU for calibration 19.3.13.3 HTM14.7:M Yes No N/A HTP2.9 Channel numbering and channelization HTP2.9.1 Channel allocation for 20 MHz 17.3.8.4 CFHT:M Yes No N/A channels at 5 GHz 2741 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.17.2 HT PHY features (continued) Item Protocol capability References Status Support HTP2.9.2 Channel allocation for 20 MHz 18.4.3 CFHT:M Yes No N/A channels at 2.4 GHz HTP2.9.3 Channel allocation for 40 MHz 19.3.15.3 HTP2.3.4:M Yes No N/A channels at 5 GHz HTP2.9.4 Channel allocation for 40 MHz 19.3.15.2 HTP2.3.4:M Yes No N/A channels at 2.4 GHz HTP2.10 PHY transmit specification HTP2.10.1 PHY transmit specification for 19.3.18 CFHT:M Yes No N/A 20 MHz channel HTP2.10.2 PHY transmit specification for 19.3.18 HTP2.3.4:M Yes No N/A 40 MHz channel *HTP2.11 Space-time block coding (STBC) 19.3.11.9.2 CFHT:O Yes No N/A HTP2.12 PHY receive specification EMPTY HTP2.12.1 PHY receive specification for 19.3.19 CFHT:M Yes No N/A 20 MHz channel HTP2.12.2 PHY receive specification for 19.3.19 HTP2.3.4:M Yes No N/A 40 MHz channel HTP2.13 PPDU reception with RIFS 19.3.19.7 CFHT:M Yes No N/A B.4.18 Tunneled direct-link setup extensions Item Protocol capability References Status Support TDLS1 Tunneled direct-link setup 9.6.13, 11.23 CFIndepSTA Yes No N/A AND CFTDLS:M TDLS1.1 TDLS setup 9.4.2.62, CFIndepSTA Yes No N/A 9.6.13.2, AND 9.6.13.3, CFTDLS:M 9.6.13.4, 11.23.4 TDLS1.2 TDLS teardown 9.4.2.62, CFIndepSTA Yes No N/A 9.6.13.5, AND 11.23.5 CFTDLS:M TDLS1.3 TPK handshake 12.7.9 CFIndepSTA Yes No N/A AND CFTDLS:M TDLS1.4 TDLS peer PSM 9.4.2.62, CFIndepSTA Yes No N/A 9.4.2.63, AND 9.6.13.9, CFTDLS:O 9.6.13.10, 11.2.3.14 TDLS 1.5 TPU 9.4.2.62, CFIndepSTA Yes No N/A 9.4.2.65, AND 9.4.2.66, CFTDLS:O 9.6.13.6, 9.6.13.11, 11.2.3.15 2742 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.18 Tunneled direct-link setup extensions (continued) Item Protocol capability References Status Support TDLS 1.6 TDLS Channel Switching 9.4.2.62, CFIndepSTA Yes No N/A 9.4.2.64, AND CFMD 9.6.13.7, AND 9.6.13.8, CFOC AND 11.23.6 CFTDLS:O TDLS1.7 TDLS Discovery 9.4.2.62, CFIndepSTA Yes No N/A 9.6.8.16, AND CFMD 9.6.13.12, AND 11.23.3 CFOC AND CFTDLS:O B.4.19 WNM extensions Item Protocol capability References Status Support WNM1 Extended Capabilities element 9.4.2.27 CFWNM:M Yes â–¡ No â–¡ N/A â–¡ WNM2 STA Statistics (Triggered) and 11.11.8 CFWNM:M Yes â–¡ No â–¡ N/A â–¡ Multicast Diagnostics WNM2.1 Protocol for Triggered 11.11.8 CFWNM:M Yes â–¡ No â–¡ N/A â–¡ Measurements WNM2.2 Triggered STA Statistics 9.4.2.21.9, CFWNM:O Yes â–¡ No â–¡ N/A â–¡ 9.4.2.22.9, 9.6.7.2, 9.6.7.3, 11.11.9.5 WNM2.3 Multicast Diagnostics 9.4.2.21.13, CFWNM:M Yes â–¡ No â–¡ N/A â–¡ 9.4.2.22.12, 9.6.7.2, 9.6.7.3, 11.11.19 WNM3 Event 11.24.2 CFWNM:M Yes â–¡ No â–¡ N/A â–¡ WNM3.1 Event Request frame 9.4.2.67, (CFWNM Yes â–¡ No â–¡ N/A â–¡ 9.6.14.2 AND CFAP):M WNM3.2 Event Report frame 9.4.2.68, (CFWNM Yes â–¡ No â–¡ N/A â–¡ 9.6.14.3 AND CFIndepSTA) :M WNM4 Diagnostic 11.24.3 CFWNM:M Yes â–¡ No â–¡ N/A â–¡ WNM4.1 Diagnostic Request frame 9.4.2.69, (CFWNM Yes â–¡ No â–¡ N/A â–¡ 9.6.14.4 AND CFAP):M WNM4.2 Diagnostic Report frame 9.4.2.70, (CFWNM Yes â–¡ No â–¡ N/A â–¡ 9.6.14.5 AND CFIndepSTA) :M WNM4.3 Configuration Profile Diagnostic 9.4.2.70.3, CFWNM:M Yes â–¡ No â–¡ N/A â–¡ Type 11.24.3.2 2743 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.19 WNM extensions (continued) Item Protocol capability References Status Support WNM4.4 Manufacturer Information STA 9.4.2.70.2, CFWNM:M Yes â–¡ No â–¡ N/A â–¡ Report Diagnostic Type 11.24.3.3 WNM4.5 Association Diagnostic Type 9.4.2.69.2, CFWNM:M Yes â–¡ No â–¡ N/A â–¡ 9.4.2.70.4, 11.24.3.4 WNM4.6 IEEE 802.1X Authentication 9.4.2.69.3, (CFWNM Yes â–¡ No â–¡ N/A â–¡ Diagnostic Type 9.4.2.70.5, AND 11.24.3.5 PC34):M WNM5 Location 9.4.2.71, CFWNM:M Yes â–¡ No â–¡ N/A â–¡ 11.24.4 WNM5.1 Location Civic request/report 11.11.9.9 CFWNM:M Yes â–¡ No â–¡ N/A â–¡ WNM5.2 Location Identifier request/report 11.11.9.10 CFWNM:M Yes â–¡ No â–¡ N/A â–¡ WNM5.3 Location Track Notification 9.6.8.17, CFWNM:O Yes â–¡ No â–¡ N/A â–¡ 11.24.4 WNM5.3.1 Time of Departure Notifications 9.4.2.71, CFWNM:O Yes â–¡ No â–¡ N/A â–¡ 11.24.4 WNM5.3.2 Motion Detection Notifications 9.4.2.71, CFWNM:O Yes â–¡ No â–¡ N/A â–¡ 11.24.4 WNM5.4 Location Configuration Request 9.4.2.71, CFWNM:M Yes â–¡ No â–¡ N/A â–¡ frame 9.6.14.6 WNM5.4.1 Normal Indication 9.4.2.71, CFWNM:O Yes â–¡ No â–¡ N/A â–¡ 9.6.14.6 WNM5.4.2 Motion Indication 9.4.2.71, CFWNM:O Yes â–¡ No â–¡ N/A â–¡ 9.6.14.6 WNM5.5 Location Configuration Response 9.4.2.71, CFWNM:M Yes â–¡ No â–¡ N/A â–¡ frame 9.6.14.7 *WNM6 Multiple BSSID Support 11.1.3.8, CFWNM:O Yes â–¡ No â–¡ N/A â–¡ 11.1.4, 11.11.14 WNM6.1 Multiple BSSID element 9.4.2.46 WNM6:M Yes â–¡ No â–¡ N/A â–¡ WNM6.2 Multiple BSSID-index element 9.4.2.74 WNM6:M Yes â–¡ No â–¡ N/A â–¡ WNM7 BSS transition management 11.24.7 CFWNM:O Yes â–¡ No â–¡ N/A â–¡ WNM7.1 Neighbor Report element 9.4.2.37 (CFWNM Yes â–¡ No â–¡ N/A â–¡ AND CFAP):M WNM7.2 BSS Transition Management 9.6.14.8 (CFWNM Yes â–¡ No â–¡ N/A â–¡ Query frame AND CFAP):M WNM7.3 BSS Transition Management 9.6.14.9 (CFWNM Yes â–¡ No â–¡ N/A â–¡ Request frame AND CFIndepSTA) :M WNM7.4 BSS Transition Management 9.6.14.10 (CFWNM Yes â–¡ No â–¡ N/A â–¡ Response frame AND CFIndepSTA) :M 2744 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.19 WNM extensions (continued) Item Protocol capability References Status Support *WNM8 FMS 11.2.3.16 CFWNM:O Yes â–¡ No â–¡ N/A â–¡ WNM8.1 FMS Request frame 9.6.14.11 (CFIndepSTA Yes â–¡ No â–¡ N/A â–¡ AND WNM8):M WNM8.2 FMS Response frame 9.6.14.12 (CFAP AND Yes â–¡ No â–¡ N/A â–¡ WNM8):M WNM9 Proxy ARP 11.24.14 CFWNM:O Yes â–¡ No â–¡ N/A â–¡ *WNM10 Collocated Interference Reporting 11.24.10 CFWNM:O Yes â–¡ No â–¡ N/A â–¡ WNM10.1 Collocated Interference Request 9.6.14.13 WNM10:M Yes â–¡ No â–¡ N/A â–¡ frame WNM10.2 Collocated Interference Report 9.6.14.14 WNM10:M Yes â–¡ No â–¡ N/A â–¡ frame *WNM11 BSS max idle period 11.24.13 CFWNM:M Yes â–¡ No â–¡ N/A â–¡ WNM11.1 BSS Max Idle Period element 9.4.2.79 WNM11:M Yes â–¡ No â–¡ N/A â–¡ *WNM12 TFS 11.24.12 CFWNM:O Yes â–¡ No â–¡ N/A â–¡ WNM12.1 TFS Request frame 9.4.2.80, WNM12:M Yes â–¡ No â–¡ N/A â–¡ 9.6.14.15 WNM12.2 TFS Response frame 9.4.2.81, WNM12:M Yes â–¡ No â–¡ N/A â–¡ 9.6.14.16 WNM12.3 TFS Notify frame 9.6.14.17 (CFAP AND Yes â–¡ No â–¡ N/A â–¡ WNM12):M (CFIndepSTA AND WNM12):O *WNM13 WNM sleep mode 11.2.3.18 WNM12:O Yes â–¡ No â–¡ N/A â–¡ WNM13.1 WNM Sleep Mode Request frame 9.4.2.82, WNM13:M Yes â–¡ No â–¡ N/A â–¡ 9.6.14.19 WNM13.2 WNM Sleep Mode Response 9.4.2.82, WNM13:M Yes â–¡ No â–¡ N/A â–¡ frame 9.6.14.20 *WNM14 TIM Broadcast 11.2.3.17 CFWNM:O Yes â–¡ No â–¡ N/A â–¡ WNM14.1 TIM Broadcast Request frame 9.4.2.83, WNM14:M Yes â–¡ No â–¡ N/A â–¡ 9.6.14.21 WNM14.2 TIM Broadcast Response frame 9.4.2.84, WNM14:M Yes â–¡ No â–¡ N/A â–¡ 9.6.14.22 WNM14.3 TIM Broadcast frame 9.6.15.2 WNM14:M Yes â–¡ No â–¡ N/A â–¡ *WNM15 QoS Traffic Capability 11.24.10 (CFWNM Yes â–¡ No â–¡ N/A â–¡ AND CFIndepSTA) :O WNM15.1 QoS Traffic Capability element 9.4.2.78 WNM15:M Yes â–¡ No â–¡ N/A â–¡ WNM15.2 QoS Traffic Capability Update 9.6.14.23 WNM15:M Yes â–¡ No â–¡ N/A â–¡ frame WNM16 AC Station Count 11.24.11 (CFWNM Yes â–¡ No â–¡ N/A â–¡ AND CFIndepSTA) :O 2745 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.19 WNM extensions (continued) Item Protocol capability References Status Support WNM17 Timing Measurement 11.24.5 CFWNM:O Yes â–¡ No â–¡ N/A â–¡ WNM17.1 Timing Measurement Request 9.6.14.28 WNM17:M Yes â–¡ No â–¡ N/A â–¡ WNM17.2 Timing Measurement 9.6.15.3 WNM17:M Yes â–¡ No â–¡ N/A â–¡ *WNM18 Channel Usage 11.24.15 CFWNM:O Yes â–¡ No â–¡ N/A â–¡ WNM18.1 Channel Usage Request frame 9.4.2.86, WNM18:M Yes â–¡ No â–¡ N/A â–¡ 9.6.14.24 WNM18.2 Channel Usage Response frame 9.4.2.86, WNM18:M Yes â–¡ No â–¡ N/A â–¡ 9.6.14.25 *WNM19 DMS 11.24.16 (CFWNM Yes â–¡ No â–¡ N/A â–¡ AND CFHT):O (CFWNM AND CFTVHT):O WNM19.1 DMS Request frame 9.4.2.88, WNM19:M Yes â–¡ No â–¡ N/A â–¡ 9.6.14.26 WNM19.2 DMS Response frame 9.4.2.89, WNM19:M Yes â–¡ No â–¡ N/A â–¡ 9.6.14.27 WNM20 UTC TSF Offset 9.4.2.61, CFWNM:O Yes â–¡ No â–¡ N/A â–¡ 9.4.2.87, 11.22.3 WNM21 U-APSD coexistence 9.4.2.91, CFWNM:O Yes â–¡ No â–¡ N/A â–¡ 11.2.3.5.2 WNM22 WNM notification 11.24.17 (CFWNM Yes â–¡ No â–¡ N/A â–¡ AND CFHT):O (CFWNM AND CFTVHT):O WNM22.1 WNM Notification Request 9.6.14.29 WNM21:M Yes â–¡ No â–¡ N/A â–¡ frame WNM22.2 WNM Notification Response 9.6.14.30 WNM21:M Yes â–¡ No â–¡ N/A â–¡ frame WNM23 Fine timing measurement 11.24.6 CFWNM:O Yes â–¡ No â–¡ N/A â–¡ WNM23.1 Fine timing measurement request 9.6.8.32 WNM23:M Yes â–¡ No â–¡ N/A â–¡ (including LCI and/or location civic request) WNM23.2 Fine timing measurement 9.6.8.33 WNM23:M Yes â–¡ No â–¡ N/A â–¡ (including LCI and/or location civic report) WNM23.3 Request neighbor LCI and/or civic 11.11.10.2 (CFIndepSTA Yes â–¡ No â–¡ N/A â–¡ locations within neighbor report OR CFMBSS) request AND WNM23:M WNM23.4 Report neighbor LCI and/or civic 11.11.10.2 CFAP AND Yes â–¡ No â–¡ N/A â–¡ locations within neighbor report WNM23:M response 2746 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.19 WNM extensions (continued) Item Protocol capability References Status Support WNM23.5 Transmitter of Fine Timing 11.11.9.11 WNM23:M Yes â–¡ No â–¡ N/A â–¡ Measurement Range request and receiver of Fine Timing Measurement Range report WNM23.6 Receiver of Fine Timing 11.11.9.11 (CFIndepSTA Yes â–¡ No â–¡ N/A â–¡ Measurement Range request and OR CFMBSS) transmitter of Fine Timing AND Measurement Range report WNM23:M B.4.20 Interworking (IW) with external networks extensions Item Protocol capability References Status Support Are the following Interworking with External Networks capabilities supported? IW1 Interworking capabilities and 9.4.2.92, CFIW:M Yes No N/A Information 11.25.2 IW1.1 Interworking element 9.4.2.92 IW1:M Yes No N/A IW1.2 Access network type 9.4.2.92 IW1:M Yes No N/A IW1.3 Venue type 9.4.2.92 IW1:M Yes No N/A IW1.4 HESSID 9.4.2.92 IW1:M Yes No N/A IW2 Generic Advertisement Service 11.25.3 CFIW:M Yes No N/A IW2.1 Advertisement Protocol element 9.4.2.93 IW2:M Yes No N/A *IW2.2 GAS Protocol 11.25.3.2 IW2:M Yes No N/A *IW2.2.1 GAS frames 9.6.8 IW2:M Yes No N/A IW2.2.2 Access network query protocol 9.4.5 IW2.2:M Yes No N/A IW2.2.3 Query List 9.4.5.2 IW2.2.1:M Yes No N/A IW2.2.4 Capability List 9.4.5.3 IW2.2.1:M Yes No N/A IW2.2.5 Venue Name 9.4.5.4 IW2.2.1:O Yes No N/A IW2.2.6 Emergency Call Number 9.4.5.5 IW2.2.1:O Yes No N/A IW2.2.7 Network Authentication Type 9.4.5.6 IW2.2.1:O Yes No N/A IW2.2.8 Roaming Consortium 9.4.5.7 IW2.2.1:O Yes No N/A IW2.2.9 IP Address Type Availability 9.4.5.9 IW2.2.1:O Yes No N/A IW2.2.10 NAI Realm 9.4.5.10 IW2.2.1:O Yes No N/A IW2.2.11 3GPP Cellular Network 9.4.5.11 IW2.2.1:O Yes No N/A IW2.2.12 AP Geospatial Location 9.4.5.12 IW2.2.1:O Yes No N/A IW2.2.13 AP Civic Location 9.4.5.13 IW2.2.1:O Yes No N/A IW2.2.14 AP Location Public Identifier URI/ 9.4.5.14 IW2.2.1:O Yes No N/A FQDN IW2.2.15 Domain Name 9.4.5.15 IW2.2.1:O Yes No N/A IW2.2.16 Emergency Alert URI 9.4.5.16 IW2.2.1:O Yes No N/A 2747 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.20 Interworking (IW) with external networks extensions (continued) Item Protocol capability References Status Support IW2.2.17 Emergency NAI 9.4.5.17 IW2.2.1:O Yes No N/A IW2.2.18 Vendor Specific 9.4.5.8 IW2.2.1:O Yes No N/A IW2.2.19 MIH IS 9.4.2.93, IW2:O Yes No N/A 11.25.4 IW2.2.20 MIH Event and Command Services 9.4.2.93, IW2.2:O Yes No N/A Discovery 11.25.4 IW2.2.21 Emergency Alert System (EAS) 9.4.2.93, IW2.2:O Yes No N/A 9.4.2.97 IW2.2.22 Advertisement Protocol ID, Vendor 9.4.2.93 IW2.2:O Yes No N/A Specific IW2.2.23 TDLS Capability 9.4.5.18 IW2.21:O Yes No N/A IW2.2.24 Neighbor Report 9.4.5.19 IW2.21:O Yes No N/A IW2.3 GAS Initial Request frame 9.6.8.12 IW2:M Yes No N/A IW2.4 GAS Initial Response frame 9.6.8.13 IW2:M Yes No N/A IW2.5 GAS Comeback Request frame 9.6.8.14 IW2:M Yes No N/A IW2.6 GAS Comeback Response frame 9.6.8.15 IW2:M Yes No N/A IW3 QoS Mapping from External 10.22.4.2, CFIW:O Yes No N/A Networks 10.22.4.3, 11.25.9 IW3.1 QoS Map element 9.4.2.95 IW3:M Yes No N/A IW3.2 Transport of QoS Map 11.25.9 IW3:M Yes No N/A IW3.3 QoS Map Configure 9.6.3.6 IW3:M Yes No N/A IW4 MIH Support 6.4, 11.25.4 CFIW:O Yes No N/A IW4.1 MAC state generic convergence 6.4 IW4:M Yes No N/A function support IW4.2 Informational events 6.4.5 IW4:M Yes No N/A IW4.3 ESS status reporting 6.4.7 IW4:M Yes No N/A IW4.4 Network configuration 6.4.8 IW4:M Yes No N/A IW4.5 Network events 6.4.9 IW4:M Yes No N/A IW4.6 Network command interface 6.4.10 IW4:M Yes No N/A IW4.7 Mobility management 6.4.11 IW4:M Yes No N/A IW4.8 Network configuration 6.4.8 IW4:M Yes No N/A IW5 Extended channel switching 9.4.2.58, 11.1.4 (CF3G6 AND Yes No N/A enabled DSE9):M IW6 Expedited Bandwidth Request 9.4.2.94 CFIW:O Yes No N/A IW7 SSPN Interface 11.25.5 CFIW:O Yes No N/A 2748 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.21 Mesh protocol capabilities B.4.21.1 General mesh support Item Protocol capability Reference Status Support *MP1 Support of mesh capability 4.3.20, 14.1 CFMBSS: Yes No N/A M MP1.1 Mesh BSS scanning 14.2.2, 14.2.6 MP1:M Yes No N/A MP1.2 Candidate peer mesh STA 14.2.7 MP1:M Yes No N/A determination MP1.3 Active mesh profile 14.2.3, 14.2.4 MP1:M Yes No N/A determination MP1.4 Establishing a mesh BSS 14.2.8 MP1:M Yes No N/A MP1.5 Becoming a member of a mesh 14.2.8 MP1:M Yes No N/A BSS MP1.6 Announcement of mesh 14.2.3, 14.2.5 MP1:M Yes No N/A profile and supplemental information for the mesh discovery *MP2 Mesh peering management 14.3 CFMBSS: Yes No N/A (MPM) framework M *MP2.1 Mesh peering management 14.3 MP2:M Yes No N/A (MPM) protocol MP2.1.1 Processing of Mesh Peering 14.3.6 MP2.1:M Yes No N/A Open frame MP2.1.2 Processing of Mesh Peering 14.3.7 MP2.1:M Yes No N/A Confirm frame MP2.1.3 Processing of Mesh Peering 14.3.8 MP2.1:M Yes No N/A Close frame MP2.1.4 MPM finite state machine 14.4 MP2.1:M Yes No N/A *MP2.2 Authenticated mesh peering 14.5 MP2:O Yes No N/A exchange (AMPE) MP2.2.1 Mesh authentication using SAE 12.4, 14.3.3 MP2.2:M Yes No N/A MP2.2.2 Mesh authentication using IEEE 4.10, 14.3.3 MP2.2:O Yes No N/A Std 802.1X MP2.2.3 Protected mesh peering 14.5.3, 14.5.3 MP2.2:M Yes No N/A Management frame processing MP2.2.4 Mesh pairwise master key 12.6.12 MP2.2:M Yes No N/A security association (PMKSA) caching MP2.2.5 AMPE finite state machine 14.5.6 MP2.2:M Yes No N/A MP2.2.6 MGTK distribution 14.5.4 MP2.2:M Yes No N/A MP2.2.7 MGTK update 14.6 MP2.2:O Yes No N/A MP3 Mesh STA beaconing 14.13.3 CFMBSS: Yes No N/A M *MP4 Mesh STA synchronization 14.13.2 CFMBSS: Yes No N/A M *MP4.1 Neighbor offset synchronization 14.13.2 MP4:M Yes No N/A method MP4.1.1 Calculation of TSF offset 14.13.2.2.2 MP4.1:M Yes No N/A 2749 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.21.1 General mesh support (continued) Item Protocol capability Reference Status Support MP4.1.2 Clock drift adjustment 14.13.2.2.3 MP4.1:M Yes No N/A *MP4.2 Mesh beacon collision 14.13.4 MP4:O Yes No N/A avoidance (MBCA) MP4.2.1 Beacon timing advertisement 14.13.4.2 MP4.2:M Yes No N/A MP4.2.2 TBTT selection 14.13.4.3 MP4.2:M Yes No N/A MP4.2.3 TBTT adjustment 14.13.4.4 MP4.2:M Yes No N/A MP4.2.4 Frame transmission across 14.13.4.5 MP4.2:O Yes No N/A reported TBTT MP4.2.5 Delayed beacon transmission 14.13.4.6 MP4.2:O Yes No N/A *MP5 MCCA 10.23.3 CFMBSS: Yes No N/A O MP5.1 MCCAOP Advertisement 10.23.3.7 MP5:M Yes No N/A MP5.2 Neighbor MCCAOP 10.23.3.4, 10.23.3.5 MP5:M Yes No N/A Recognition MP5.3 MCCAOP Setup 10.23.3.6 MP5:M Yes No N/A MP5.4 Access during MCCAOPs 10.23.3.9 MP5:M Yes No N/A MP5.5 MCCAOP teardown 10.23.3.8 MP5:M Yes No N/A *MP6 Intra mesh congestion control 14.12 CFMBSS: Yes No N/A O MP6.1 Local congestion monitoring and 14.12 MP6:M Yes No N/A detection MP6.2 Congestion control signaling 14.12 MP6:M Yes No N/A MP6.3 Local rate control 14.12 MP6:M Yes No N/A *MP7 MBSS channel switching 11.9.8, 11.10.3 CFMBSS: Yes No N/A procedure M MP7.1 Transmission of channel switch 11.9.8, 11.10.3 MP7:M Yes No N/A advertisement MP7.2 Propagation of channel switch 11.9.8, 11.10.3 MP7:M Yes No N/A advertisement *MP8 Mesh power save operation 14.14 CFMBSS: Yes No N/A (operation in light or deep sleep O mode) MP8.1 Link-specific mesh power 14.14.2.2, 14.14.8 MP8:M Yes No N/A management mode setting MP8.2 Nonpeer mesh power 14.14.2.3 MP8:M Yes No N/A management mode setting MP8.3 Light sleep mode operation 14.14.8.4 MP8:M Yes No N/A MP8.4 Deep sleep mode operation 14.14.8.5 MP8:M Yes No N/A MP8.5 STA power state transitions 14.14.3 MP8:M Yes No N/A MP8.6 Mesh awake window 14.14.6 MP8:M Yes No N/A operation *MP9 Mesh power save support 14.14 CFMBSS: Yes No N/A M MP9.1 TIM transmission 14.14.4 MP9:M Yes No N/A 2750 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.21.1 General mesh support (continued) Item Protocol capability Reference Status Support MP9.2 Link-specific mesh power 14.14.2 MP9:M Yes No N/A management modes determination MP9.3 Group addressed frame 14.14.7 MP9:M Yes No N/A transmission MP9.4 Frame transmission to a mesh 14.14.7, 14.14.9 MP9:M Yes No N/A STA in light sleep mode MP9.5 Frame transmission to a mesh 14.14.7, 14.14.9 MP9:M Yes No N/A STA in deep sleep mode MP10 Airtime link metric 14.9 CFMBSS: Yes No N/A computation M *MP11 Link metric reporting 14.8.3 CFMBSS: Yes No N/A M MP11.1 Autonomous link metric 14.8.3 MP11:O Yes No N/A reporting MP11.2 Link metric reporting upon 14.8.3 MP11:M Yes No N/A request *MP12 Proxy operation 14.11.4 CFMBSS: Yes No N/A O MP12.1 Data forwarding at proxy mesh 14.11.3 MP12:M Yes No N/A gate MP12.2 Maintenance of proxy 14.11.4.2 CFMBSS: Yes No N/A information M MP12.3 Proxy update using Proxy Update 14.11.4 CFMBSS: Yes No N/A and Proxy Update Confirmation M frames MP12.4 Proxy update using HWMP Mesh 14.10.9, 14.10.10, HWM1:M Yes No N/A Path Selection frames 14.10.11 *MP13 Gate announcement 14.11.2 CFMBSS: Yes No N/A O MP13.1 GANN transmission 14.11.2 MP13:O Yes No N/A MP13.2 GANN reception and 14.11.2 CFMBSS: Yes No N/A propagation M *MP14 Mesh Control field handling 9.2.4.7.3 CFMBSS: Yes No N/A M MP14.1 Address Extension 9.2.4.7.3, 9.3.5 MP14:M Yes No N/A recognition MP14.2 Mesh TTL handling 9.2.4.7.3, 10.35.3, MP14:M Yes No N/A 10.35.4, 10.35.5 MP14.3 Mesh Sequence Number 9.2.4.7.3, 10.35.3, MP14:M Yes No N/A handling 10.35.4, 10.35.5, 10.35.6 *MP15 MSDU/MMPDU forwarding 10.35 CFMBSS: Yes No N/A O MP15.1 Individually addressed MSDU 10.35.3 MP15:M Yes No N/A forwarding MP15.2 Group addressed MSDU 10.35.4 MP15:M Yes No N/A forwarding 2751 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.21.1 General mesh support (continued) Item Protocol capability Reference Status Support MP15.3 MMPDU forwarding 10.35.5 MP15:M Yes No N/A MP15.4 Detection of duplicate MSDUs/ 10.35.6 CFMBSS: Yes No N/A MMPDUs M MP15.5 Treatment of unknown 10.35.8 CFMBSS: Yes No N/A destination M B.4.21.2 HWMP path selection protocol capabilities Item Protocol capability Reference Status Support *HWM1 Hybrid wireless mesh 14.10 CFMBSS:M Yes No N/A protocol (HWMP) *HWM1.1 On-demand path selection 14.10.3 HWM1:M Yes No N/A HWM1.1.1 PREQ processing for on-demand 14.10.9 HWM1.1:M Yes No N/A path selection HWM1.1.2 PREP processing for on-demand 14.10.10 HWM1.1:M Yes No N/A path selection HWM1.1.3 PERR processing for on-demand 14.10.11 HWM1.1:M Yes No N/A path selection *HWM1.2 Proactive tree building 14.10.4 HWM1:M Yes No N/A HWM1.2.1 PREQ processing for 14.10.9 HWM1.2:M Yes No N/A proactive tree building HWM1.2.2 PREP processing for 14.10.10 HWM1.2:M Yes No N/A proactive tree building HWM1.2.3 PERR processing for 14.10.11 HWM1.2:M Yes No N/A proactive tree building HWM1.2.4 RANN processing 14.10.12 HWM1.2:M Yes No N/A HWM2 Maintenance of forwarding 10.35.2, 14.10.8.4 MP15:M Yes No N/A information B.4.22 QMF extensions Item Protocol capability References Status Support QMF1 Extended Capabilities element 9.4.2.27 CFQMF:M Yes No N/A QMF2 Channel access procedures for 10.2.4.2 CFQMF:M Yes No N/A QMFs QMF3 Duplicate detection and recovery 10.3.2.11 CFQMF:M Yes No N/A for QMFs QMF4 QMF policy Configuration 11.26.2 CFQMF:M Yes No N/A QMF5 Interpreting QMF priority 11.26.3 CFQMF:M Yes No N/A QMF6 CCMP cryptographic encapsulation 12.5.3.3 (CFQMF AND Yes No N/A for QMFs PC34.1.10):M 2752 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.23 RobustAVT extensions Item Protocol capability References Status Support AVT1 Extended Capabilities element 9.4.2.27 CFAVT:M Yes No N/A AVT2 Groupcast with Retries (GCR) 11.24.16.3.2, (CFHT AND Yes No N/A 11.24.16.3.3, CFAVT AND 11.24.16.3.4, WNM19):M 11.24.16.3.5, (CFTVHT 11.24.16.3.6 AND CFAVT AND WNM19):M (CFAP AND Yes No N/A CFAVT AND WNM19 AND HTM4.4):M AVT2.1 Advanced GCR 9.4.2.27, (CFAVT AND Yes No N/A 10.24.10, QB5):O 11.24.16.3.7, 11.24.16.3.8 AVT3 Alternate EDCA transmit queues 10.2.4.2 CFAVT AND Yes No N/A CFHT:O AVT4 Stream Classification Service 11.27.2 CFAVT:O Yes No N/A (SCS) AVT4.1 SCS Request frame 9.6.19.2 AVT4:M Yes No N/A AVT4.2 SCS Response frame 9.6.19.3 AVT4:M Yes No N/A AVT4.3 Drop eligibility indicator (DEI) 11.27.2 (CFHT AND Yes No N/A AVT4):M (CFTVHT AND AVT4):M ATV5 Overlapping Basic Service Set 9.4.2.27, 11.28 (CFAP AND Yes No N/A (OBSS) Management (QP2 OR QD6) AND CFAVT):M ATV5.1 AP PeerKey 12.11 AVT5:O Yes No N/A ATV5.2 QLoad Report 11.28.2 AVT5:M Yes No N/A AVT5.2.1 QLoad Report element 9.4.2.123 AVT5.2:M Yes No N/A AVT5.2.2 QLoad Request frame 9.6.8.20 AVT5.2:M Yes No N/A AVT5.2.3 QLoad Report frame 9.6.8.21 AVT5.2:M Yes No N/A AVT5.2.4 Protected QLoad Report 9.6.8.21 (AVT5.2 AND Yes No N/A AVT5.1):O AVT5.3 HCCA TXOP Update Count 9.4.2.124 (AVT5 AND Yes No N/A element QP2):O AVT5.3.1 HCCA TXOP Negotiation 11.28.3 AVT5.3:O Yes No N/A AVT5.3.2 Protected HCCA TXOP 11.28.3 (AVT5.3 AND Yes No N/A Negotiation ATV5.1):O 2753 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.23 RobustAVT extensions (continued) Item Protocol capability References Status Support AVT6 GCR for Mesh 9.4.2.27, (WNM19 AND Yes No N/A 10.24.10, HTM4.4 AND 11.24.16.3.6, CFHT AND 11.24.16.3.7 CFAVT AND CFMBSS):O (WNM19 AND HTM4.4 AND CFTVHT AND CFAVT and CFMBSS):O B.4.24 DMG features B.4.24.1 DMG MAC features Item Protocol capability References Status Support Are the following MAC protocol features supported? DMG-M1 DMG capabilities signaling DMG-M1.1 DMG Capabilities element 9.4.2.128 CFDMG:M Yes No N/A DMG-M1.2 Signaling of STA capabilities in Probe 9.3.3.6, (CFDMG AND Yes No Request, (Re)Association Request frames 9.3.3.8, (CFSTAofAP N/A 9.3.3.10, OR CFIBSS 9.4.2.128 OR CFPBSSnotPC P)):M DMG-M1.3 Signaling of STA and BSS capabilities in 9.3.3.7, (CFDMG AND Yes No DMG Beacon, Probe Response, 9.3.3.9, (CFAP OR N/A (Re)Association Response frames 9.3.3.11, CFPCP)):M 9.3.4.2, 9.4.2.128 DMG-M2 Signaling of DMG operation 9.4.2.129 (CFDMG AND Yes No (CFAP OR N/A CFPCP)):M DMG-M3 MSDU aggregation DMG-M3.1 Reception of Basic A-MSDUs 9.2.4.5, CFDMG:M Yes No 9.3.2.2.2 N/A DMG-M3.2 Basic A-MSDU format 9.3.2.2.2 CFDMG:M Yes No N/A DMG-M3.3 Basic A-MSDU content 9.3.2.2.2 CFDMG:M Yes No N/A DMG-M3.4 Transmission of Basic A-MSDUs 9.2.4.5, CFDMG:O Yes No 9.3.2.2.2 N/A *DMG-M3.5 Reception of Short A-MSDU 9.2.4.5, CFDMG:O Yes No 9.3.2.2.2 N/A 2754 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.24.1 DMG MAC features (continued) Item Protocol capability References Status Support DMG-M3.6 Short A-MSDU format 9.3.2.2.3 (DMG-M3.5 Yes No OR DMG- N/A M3.8):M DMG-M3.7 Short A-MSDU content 9.3.2.2.3 (DMG-M3.5 Yes No OR DMG- N/A M3.8):M *DMG-M3.8 Transmission of Short A-MSDU 9.2.4.5, CFDMG:O Yes No 9.3.2.2.3 N/A DMG-M3.9 Negotiation of Short A-MSDU usage 9.4.2.30 CFDMG:M Yes No N/A DMG-M4 MPDU aggregation DMG-M4.1 Reception of A-MPDU 9.4.2.128.2, CFDMG:M Yes No 10.13.2, 11.3 N/A DMG-M4.2 A-MPDU format 9.7.1 CFDMG:M Yes No N/A DMG-M4.3 A-MPDU content 9.7.3 CFDMG:M Yes No N/A DMG-M4.4 Transmission of A-MPDU 9.4.2.128.2, CFDMG:O Yes No 10.13.2 N/A DMG-M5 A-PPDU aggregation 10.13-10.15 *DMG-M5.1 Reception of A-PPDU 9.4.2.128.2 CFDMG:O Yes No N/A DMG-M5.2 A-PPDU format 20.5.2, (DMG-M5.1 Yes No 20.6.2 OR DMG- N/A M5.3):M *DMG-M5.3 Transmission of A-PPDU 9.4.2.128.2 CFDMG:O Yes No N/A *DMG-M6 Reverse direction aggregation exchanges 9.4.2.128.2, CFDMG:O Yes No 10.28 N/A DMG-M6.1 Constraints regarding responses 10.28.3 DMG-M6:M Yes No N/A DMG-M7 DMG channel access DMG-M7.1 ATI transmission DMG- Transmission of Request 10.36.3 CFDMG AND Yes No M7.1.1 (CFAP OR N/A CFPCP):O DMG- Reception of Request 10.36.3 CFDMG AND Yes No M7.1.2 (CFSTAofAP N/A OR CFPBSSnotPC P):M 2755 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.24.1 DMG MAC features (continued) Item Protocol capability References Status Support DMG- Transmission of Response 10.36.3 CFDMG AND Yes No M7.1.3 (CFSTAofAP N/A OR CFPBSSnotPC P):M DMG- Reception of Response 10.36.3 CFDMG AND Yes No M7.1.4 (CFAP OR N/A CFPCP):M DMG-M7.2 DTI transmission 10.36.4 CFDMG:M Yes No N/A DMG-M7.3 Time allocation *DMG- Service period (SP) allocation 9.4.2.132, CFDMG AND Yes No M7.3.1 9.4.2.134, (CFAP OR N/A 9.4.2.137, CFPCP):O 10.36.6.2 *DMG- CBAP allocation 9.4.2.132, CFDMG AND Yes No M7.3.2 9.4.2.137, (CFAP OR N/A 10.36.6.2 CFPCP):O DMG- Interpretation of allocation 9.4.2.132, CFDMG AND Yes No M7.3.3 9.4.2.137, (CFInfraSTA N/A 10.36.5, OR CFIBSS 10.36.6.2 OR CFPCP OR CFPBSSnotPC P):M *DMG-M7.4 Contention based access period 10.36.5, CFDMG:M Yes No 10.36.6.2 N/A DMG- Distributed coordination function (DCF) M7.4.1 DMG- Network allocation vector (NAV) function 10.3.2.2, DMG-M7.4:M Yes No M7.4.1.1 10.3.4, N/A 10.36.10 DMG- Interframe space usage and timing 10.3.2.4, DMG-M7.4:M Yes No M7.4.1.2 10.3.4, N/A 10.3.7 DMG- Random Backoff function 10.3.3 DMG-M7.4:M Yes No M7.4.1.3 N/A DMG- DCF Access procedure 10.3, DMG-M7.4:M Yes No M7.4.1.4 10.3.4.2, N/A 10.3.4.5 DMG- Random Backoff procedure 10.3, DMG-M7.4:M Yes No M7.4.1.5 10.3.4.3 N/A DMG- Recovery procedures and retransmit limits 10.3.4.4 DMG-M7.4:M Yes No M7.4.1.6 N/A DMG- Request to send (RTS)/DMG clear to send 10.3.2.5, DMG-M7.4:M Yes No M7.4.1.7 (DMG CTS) procedure 10.3.2.7, N/A 10.3.2.8, 10.36.10 2756 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.24.1 DMG MAC features (continued) Item Protocol capability References Status Support DMG- Individually addressed MAC protocol data 10.3.5 DMG-M7.4:M Yes No M7.4.1.8 unit (MPDU) transfer N/A DMG- Group addressed MPDU transfer 10.3.6 DMG-M7.4:M Yes No M7.4.1.9 N/A DMG- MAC-level acknowledgment 10.3.2.3, DMG-M7.4:M Yes No M7.4.1.10 10.3.2.9 N/A DMG- Duplicate detection and recovery 10.3.2.11 DMG-M7.4:M Yes No M7.4.1.11 N/A DMG- Enhanced DCF (EDCA) M7.4.2 *DMG- Support for one transmit queue with AC_BE 10.2.4.2, DMG-M7.4:M Yes No M7.4.2.1 access category 10.22.2.1 N/A DMG- Support for four transmit queues with a 10.2.4.2, DMG- Yes No M7.4.2.2 separate channel access entity associated with 10.22.2.1 M7.4.2.1:O N/A each DMG- AC_BE access category and differentiated 10.22.2.2, DMG- Yes No M7.4.2.3 channel access 10.22.2.4, M7.4.2.1:M N/A 10.22.2.11 DMG-M7.5 Pseudo-static allocation DMG- Scheduling of pseudo-static allocation 9.4.2.113, DMG- Yes No M7.5.1 9.4.2.141, M7.3.1:O N/A 10.36.6.2, 10.36.6.5, 11.4.13.2 DMG- Operation within pseudo-static allocation 9.4.2.139, CFDMG AND Yes No M7.5.2 9.4.2.141, (CFAP OR N/A 10.36.6.2, CFSTAofAP 10.36.6.4 OR CFPCP OR CFPBSSnotPC P):M DMG-M7.6 Guard time 10.36.6.5 DMG- Yes No M7.3.1:M N/A DMG-M7.7 DMG protected period *DMG- Establishment of DMG protected period with 10.36.6.6 DMG- Yes No M7.7.1 RTS at source DMG STA M7.3.1:O N/A *DMG- Establishment of DMG protected period using 10.36.6.6 DMG- Yes No M7.7.2 a DMG CTS frame at destination DMG STA M7.3.1:M N/A DMG- Transmission of DMG DTS frame at 10.36.6.6 DMG- Yes No M7.7.3 destination DMG STA M7.7.2:O N/A DMG- Reception of DMG DTS frame at source DMG 10.36.6.6 DMG- Yes No M7.7.4 STA M7.7.1:M N/A DMG-M7.8 Service period recovery 10.36.6.7 DMG-M7.3.1 Yes No AND (CFAP N/A OR CFPCP):O 2757 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.24.1 DMG MAC features (continued) Item Protocol capability References Status Support DMG-M7.9 Dynamic allocation of service period 10.36.7 DMG- Polling period (PP) 9.4.2.143, M7.9.1 10.36.7.2 DMG- Transmission of Poll 9.3.1.11 CFDMG AND Yes No M7.9.1.1 (CFAP OR N/A CFPCP):O DMG- Reception of Poll 9.3.1.11 CFDMG AND Yes No M7.9.1.2 (CFSTAofAP N/A OR CFPBSSnotPC P):M DMG- Transmission of SPR 9.3.1.12 CFDMG AND Yes No M7.9.1.3 (CFSTAofAP N/A OR CFPBSSnotPC P):M DMG- Reception of SPR 9.3.1.12 CFDMG AND Yes No M7.9.1.4 (CFAP OR N/A CFPCP):M DMG- Grant period (GP) 10.36.7.3 M7.9.2 DMG- Transmission of Grant 9.3.1.13 CFDMG AND Yes No M7.9.2.1 (CFAP OR N/A CFPCP):O DMG- Reception of Grant 9.3.1.13 CFDMG AND Yes No M7.9.2.2 (CFSTAofAP N/A OR CFPBSSnotPC P):M DMG-M7.10 Dynamic truncation of service period 10.36.8 DMG- Transmission of CF-End 9.3.1.16 CFDMG:O Yes No M7.10.1 N/A DMG- Reception of CF-End 9.3.1.16 CFDMG:M Yes No M7.10.2 N/A DMG-M7.11 Dynamic extension of service period 10.36.9 DMG- Transmission of SPR 9.3.1.12 CFDMG AND Yes No M7.11.1 (CFSTAofAP N/A OR CFPBSSnotPC P):O DMG- Reception of SPR 9.3.1.12 CFDMG AND Yes No M7.11.2 (CFAP OR N/A CFPCP):M DMG- Transmission of Grant 9.3.1.13 CFDMG AND Yes No M7.11.3 (CFAP OR N/A CFPCP):O 2758 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.24.1 DMG MAC features (continued) Item Protocol capability References Status Support DMG- Reception of Grant 9.3.1.13 CFDMG AND Yes No M7.11.4 (CFSTAofAP N/A OR CFPBSSnotPC P):M DMG-M7.12 Isochronous and Asynchronous TS support DMG- Isochronous operation 9.4.2.132, DMG-M7.3.1 Yes No M7.12.1 9.4.2.134, AND N/A 9.4.2.137, (CFInfraSTA 11.4.13.2 OR CFPCP OR CFPBSSnotPC P):M DMG- Asynchronous operation 9.3.1.12, DMG-M7.3.1 Yes No M7.12.2 9.4.2.132, AND N/A 9.4.2.134, (CFInfraSTA 9.4.2.137, OR CFPCP OR 11.4.13.2 CFPBSSnotPC P):M DMG-M8 AP or PCP clustering DMG-M8.1 S-AP in centralized AP or PCP cluster 10.37 CFDMG:O Yes No N/A DMG-M8.2 Except when centralized AP or PCP clusters 10.37.2.2 CFDMG AND Yes No on all channels supported by the AP or PCP in (CFAP OR N/A the operating class, join a centralized AP or CFPCP) AND PCP cluster or cease activity on channel NOT DMG- M8.1:M DMG-M8.3 Other AP or PCP clustering 10.37 CFDMG:O Yes No N/A DMG-M9 DMG beamforming DMG-M9.1 Sector-level sweep 10.38.2, CFDMG:M Yes No 10.38.6.2 N/A DMG-M9.2 Beamforming in BTI 10.38.4 CFDMG:M Yes No N/A DMG-M9.3 Beamforming in A-BFT 10.38.5 CFDMG:M Yes No N/A DMG-M9.4 BRP setup 10.38.3.2 CFDMG:M Yes No N/A DMG-M9.5 MID 10.38.6.3.3 CFDMG:O Yes No N/A DMG-M9.6 BC 10.38.6.3.4 CFDMG:O Yes No N/A DMG-M9.7 BRP *DMG- BRP with BS-FBCK 10.38.3, CFDMG:M Yes No M9.7.1 10.38.6.4 N/A DMG- BRP with channel measurement 10.38.3, DMG- Yes No M9.7.2 10.38.6.4 M9.7.1:O N/A 2759 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.24.1 DMG MAC features (continued) Item Protocol capability References Status Support DMG-M9.8 Beam tracking 10.38.7 CFDMG:M Yes No N/A DMG-M10 DMG block ack with flow control 9.4.2.128.2, CFDMG:O Yes No 10.39 N/A DMG-M11 DMG link adaptation 10.39 CFDMG:O Yes No N/A DMG-M12 DMG dynamic tone pairing (DTP) 9.4.2.128.2, CFDMG:O Yes No 10.40 N/A DMG-M13 Timing synchronization function (TSF) in a PBSS DMG-M13.1 Timing in a PBSS 11.1.2.1, CFPCP AND Yes No 11.1.5 CFDMG:M N/A DMG-M13.2 PBSS initialization 11.1.4 CFPCP AND Yes No CFDMG:M N/A DMG-M14 Power management DMG-M14.1 STA power management without wakeup 11.2.7.2.2, CFDMG:M Yes No schedule 11.2.7.2.4 N/A DMG-M14.2 STA power management with wakeup 9.4.2.138, CFDMG:O Yes No schedule 11.2.7.2.3, N/A 11.2.7.2.4 DMG-M14.3 PCP power management 9.4.2.138, CFDMG:O Yes No 11.2.7.2.3 N/A DMG-M15 Authentication and association DMG-M15.1 Association state 11.3.1 M Yes No DMG-M15.2 STA association procedure 11.3.5.2 CFSTAofAP Yes No AND N/A CFDMG:M CFPBSSnotPC P AND CFDMG:O DMG-M15.3 AP or PCP association procedure 11.3.5.3 CFAP AND Yes No CFDMG:M N/A CFPCP AND CFDMG:O DMG-M15.4 Communicating PBSS information 11.3.7 (CFPCP OR Yes No CFPBSSnotPC N/A P) AND CFDMG:M DMG-M16 DMG beamformed link and BSS maintenance DMG-M16.1 Beamformed link maintenance *DMG- Negotiation of 9.5.6 CFDMG:M Yes No M16.1.1 dot11BeamLinkMaintenanceTime timer N/A DMG- Beamformed link maintenance procedure 11.29.1 DMG- Yes No M16.1.2 M16.1.1:O N/A 2760 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.24.1 DMG MAC features (continued) Item Protocol capability References Status Support DMG-M16.2 PCP handover 11.29.2 CFDMG:O Yes No N/A DMG-M17 DMG BSS Peer and Service Discovery 11.30 CFDMG:M Yes No N/A DMG-M18 Changing DMG BSS parameters 11.31 CFDMG:O Yes No N/A *DMG-M19 Spatial sharing and interference mitigation 11.32 CFDMG:O Yes No N/A DMG-M20 DMG Coexistence with other DMG systems 11.35 CFDMG:O Yes No N/A DMG-M21 Traffic specification (TSPEC and DMG 9.6.3 CFDMG:M Yes No TSPEC) and associated frame formats N/A DMG-M22 DMG frame formats DMG-M22.1 DMG Action field 9.6.20.1 CFDMG:M Yes No N/A DMG-M22.2 Announce frame 9.6.22.2 CFDMG:M Yes No N/A DMG-M22.3 Power Save Configuration 9.6.20.2, CFDMG:M Yes No 9.6.20.3 N/A DMG-M22.4 Information Request/Response 9.6.20.4, CFDMG:M Yes No 9.6.20.5 N/A DMG-M22.5 BRP 9.6.22.3 CFDMG:M Yes No N/A DMG-M22.6 Handover 9.6.20.6, DMG- Yes No 9.6.20.7 M16.2:M N/A DMG-M22.7 DTP 9.6.20.8, DMG-M12:M Yes No 9.6.20.9 N/A DMG-M22.8 DMG relay 9.6.20.10â€“ DMG-M23:M Yes No 9.6.20.24 N/A DMG-M23 DMG relay 10.40, 11.36 CFDMG:O Yes No N/A B.4.24.2 DMG PHY features Item Protocol capability References Status Support Are the following PHY protocol features supported? DMG-P1 PHY operating modes DMG-P1.1 Operation according to Clause 20 20 CFDMG:M Yes No N/A DMG-P2 PHY frame format 2761 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.24.2 DMG PHY features (continued) Item Protocol capability References Status Support *DMG-P2.1 DMG control mode format 20.4 CFDMG:M Yes No N/A *DMG-P2.2 DMG SC mode format 20.6 CFDMG:M Yes No N/A *DMG-P2.3 DMG OFDM mode format 20.5 CFDMG:O Yes No N/A *DMG-P2.4 DMG low-power SC mode format 20.7 CFDMG:O Yes No N/A DMG-P2.5 Modulation and coding schemes (MCS) DMG-P2.5.1 MCS 0 of DMG control mode DMG-P2.1:M Yes No N/A DMG-P2.5.2 MCS 1-12 of DMG SC mode DMG- MCS 1-4 DMG-P2.2:M Yes No P2.5.2.1 N/A DMG- MCS 5-12 DMG-P2.2:O Yes No P2.5.2.2 N/A DMG-P2.5.3 MCS 13-24 of DMG OFDM mode DMG- MCS 13-17 DMG-P2.3:M Yes No P2.5.3.1 N/A DMG- MCS 18-24 DMG-P2.3:O Yes No P2.5.3.2 N/A DMG-P2.5.4 MCS 25-31 of DMG low-power SC mode DMG-P2.4:M Yes No N/A DMG-P2.6 Common preamble format 20.3.6 CFDMG:M Yes No N/A DMG-P2.7 Use of LDPC codes 20.3.8 CFDMG:M Yes No N/A B.4.25 Very high throughput (VHT) features B.4.25.1 VHT MAC features Item Protocol capability References Status Support Are the following MAC protocol features supported? VHTM1 VHT capabilities signaling VHTM1.1 VHT Capabilities element 9.4.2.158.1 CFVHT:M Yes No N/A VHTM1.2 Signaling of STA capabilities in 9.3.3.6, 9.3.3.8, (CFVHT AND Yes No N/A Probe Request, (Re)Association 9.3.3.10, CFIndepSTA): Request frames 9.4.2.158.1 M (CFVHT AND CFMBSS):M 2762 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.25.1 VHT MAC features (continued) Item Protocol capability References Status Support VHTM1.3 Signaling of STA and BSS 9.3.3.3, 9.3.3.7, (CFVHT AND Yes No N/A capabilities in Beacon, Probe 9.3.3.9, CFAP):M Response, (Re)Association 9.3.3.11, (CFVHT AND Response frames 9.4.2.158 CFMBSS):M VHTM2 Signaling of VHT operation 9.4.2.159 (CFVHT AND Yes No N/A CFAP):M (CFVHT AND CFMBSS):M (CFVHT AND CFIBSS):M VHTM3 Link adaptation VHTM3.1 Use of the VHT variant HT Control 9.2.4.6, CFVHT:O Yes No N/A field for link adaptation in 9.3.3.15, immediate response exchange. 10.31.3 VHTM4 Transmit beamforming *VHTM4.1 SU Beamformer Capable 9.4.2.158 CFVHT:O Yes No N/A *VHTM4.2 SU Beamformee Capable 9.4.2.158 CFVHT:O Yes No N/A *VHTM4.3 MU Beamformer Capable 9.4.2.158 CFAP AND Yes No N/A VHTM4.1:O *VHTM4.4 MU Beamformee Capable 9.4.2.158 CFIndepSTA Yes No N/A AND VHTM4.2:O VHTM4.5 Transmission of null data packet 10.34 VHTM4.1:M Yes No N/A VHTM4.6 Reception of null data packet 10.34 VHTM4.2:M VHTM5 VHT Sounding Protocol VHTM5.1 VHT sounding protocol as SU 10.34.5 VHTM4.1:M Yes No N/A beamformer VHTM5.2 VHT sounding protocol as SU 10.34.5 VHTM4.2:M Yes No N/A beamformee VHTM5.3 VHT sounding protocol as MU 10.34.5 VHTM4.3:M Yes No N/A beamformer VHTM5.4 VHT sounding protocol as MU 10.34.5 VHTM4.4:M Yes No N/A beamformee VHTM6 TXOP Sharing VHTM6.1 Sharing of EDCA TXOP 10.22.2.6 CFVHT:O Yes No N/A VHTM6.2 Use of Primary and Secondary AC 10.22.2.6 VHTM6.1:M Yes No N/A VHTM7 VHT TXOP power saving 11.2.3.19 CFVHT:O Yes No N/A VHTM8 BSS Operation VHTM8.1 Use of primary 20 MHz, secondary 10.3.2.6, CFVHT:M Yes No N/A 20 MHz, and secondary 40 MHz 10.3.2.7 channels VHTM8.2 Use of secondary 80 MHz channels 11.40.1 (VHTP3.4 OR Yes No N/A for 160 MHz and 80+80 MHz VHTP3.5):M VHTM8.3 CCA on primary 20 MHz, secondary 11.40.5 CFVHT:M Yes No N/A 20 MHz, and secondary 40 MHz channels 2763 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.25.1 VHT MAC features (continued) Item Protocol capability References Status Support VHTM8.4 CCA on secondary 80 MHz channels 11.40.5 (VHTP3.4 OR Yes No N/A for 160 MHz and 80+80 MHz VHTP3.5):M VHTM9 Group ID VHTM9.1 Transmission of Group ID 9.6.23.3 VHTM4.3:M Yes No N/A Management frame VHTM9.2 Reception of Group ID Management 9.6.23.3 VHTM4.4:M frame VHTM10 Bandwidth signaling VHTM10.1 Support for non-HT bandwidth 10.3.2.6 CFVHT:M Yes No N/A signaling and static operation VHTM10.2 Support for non-HT bandwidth 10.3.2.6 CFVHT:O Yes No N/A signaling and dynamic operation VHTM11 VHT single MPDU format 10.13.7 CFVHT:M Yes No N/A VHTM12 Partial AID in VHT PPDU 10.20 CFVHT:M Yes No N/A VHTM13 Extended BSS Load element 9.4.2.160 CFVHT:O Yes No N/A VHTM13.1 Transmission of the Extended BSS 9.4.2.160 CFAP AND Yes No N/A Load element CFVHT:O VHTM14 Quiet Channel element VHTM14.1 Transmission of Quiet Channel 9.3.3.3, (CFAP OR Yes No N/A element by an AP or mesh station in 9.3.3.11, CFMBSS) Beacon and Probe Response frames 9.4.2.165, AND CFSM 11.9.3 AND CFVHT AND VHTP3.4:O VHTM14.2 Transmission of Quiet Channel 9.3.3.3, (CFIndepSTA Yes No N/A element by an independent station or 9.3.3.11, OR CFMBSS) mesh station in Beacon and Probe 9.4.2.165, AND CFSM Response frames 11.9.3 AND CFVHT AND VHTP3.4:O VHTM14.3 Reception of Quiet Channel element 9.3.3.3, (CFIndepSTA Yes No N/A by an independent station or mesh 9.3.3.11, OR CFMBSS) station in Beacon and Probe 9.4.2.165, AND CFSM Response frames 11.9.3 AND CFVHT:M VHTM15 Space-time block coding (STBC) VHTM15.1 STBC operation 9.4.2.158, VHTP9:M Yes No N/A 10.17 VHTM15.2 Transmission of at least 2x1 STBC 9.4.2.158.2 VHTP9:O.1 Yes No N/A VHTM15.3 Reception of 1 STBC spatial stream 9.4.2.158.2 VHTP9:O.1 Yes No N/A VHTM15.4 Reception of 2 STBC spatial streams 9.4.2.158.2 VHTM15.3:O Yes No N/A VHTM15.5 Reception of 3 STBC spatial streams 9.4.2.158.2 VHTM15.4:O Yes No N/A VHTM15.6 Reception of 4 STBC spatial streams 9.4.2.158.2 VHTM15.5:O Yes No N/A VHTM16 Highest Supported Long GI Data Rate 2764 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.25.1 VHT MAC features (continued) Item Protocol capability References Status Support VHTM16.1 Tx Highest Supported Long GI Data 9.4.2.158.3 CFVHT:M Yes No N/A Rate VHTM16.2 Rx Highest Supported Long GI Data 9.4.2.158.3 CFVHT:M Yes No N/A Rate NOTEâ€”Required support for MCS might be limited by the declaration of Tx and Rx Highest Supported Long GI Data Rates. B.4.25.2 VHT PHY features Item Protocol capability References Status Support Are the following PHY protocol features supported? VHTP1 PHY operating modes VHTP1.1 Operation according to Clause 17 21.1.4 CFVHT:M Yes No N/A (Orthogonal frequency division multiplexing (OFDM) PHY specification) and/or Clause 19 (high throughput) VHTP2 VHT format 21.3.2 CFVHT:M Yes No N/A VHTP3 BSS bandwidth VHTP3.1 20 MHz operation 11.40.1 CFVHT:M Yes No N/A VHTP3.2 40 MHz operation 11.40.1 CFVHT:M Yes No N/A VHTP3.3 80 MHz operation 11.40.1 CFVHT:M Yes No N/A VHTP3.4 160 MHz operation 11.40.1 CFVHT:O Yes No N/A VHTP3.5:M VHTP3.5 80+80 MHz operation 11.40.1 CFVHT:O Yes No N/A VHTP4 Bandwidth indication 17.3.5.5 CFVHT:M Yes No N/A VHTP5 PHY timing parameters VHTP5.1 Values in 20 MHz channel 21.3.6 CFVHT:M Yes No N/A VHTP5.2 Values in 40 MHz channel 21.3.6 CFVHT:M Yes No N/A VHTP5.3 Values in 80 MHz channel 21.3.6 CFVHT:M Yes No N/A VHTP5.4 Values in 160 MHz channel 21.3.6 VHTP3.4:M Yes No N/A VHTP5.5 Values in 80+80 MHz channel 21.3.6 VHTP3.5:M Yes No N/A VHTP6 VHT preamble 21.3.8 CFVHT:M Yes No N/A VHTP7 Use of LDPC Code 21.3.10.5.4 CFVHT:O Yes No N/A VHTP8 Modulation and coding schemes (MCS) VHTP8.1 CBW20, CBW40, and CBW80 21.5 VHTP8.1.1 VHT-MCS with Index 0-7 and 21.5 CFVHT:M Yes No N/A NSS = 1 VHTP8.1.2 VHT-MCS with Index 0-8 and 21.5 VHTP8.1.1:O Yes No N/A NSS = 1 2765 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.25.2 VHT PHY features (continued) Item Protocol capability References Status Support VHTP8.1.3 VHT-MCS with Index 0-9 and 21.5 VHTP8.1.2:O Yes No N/A NSS = 1 VHTP8.1.4 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A NSS = 2 VHTP8.1.5 VHT-MCS with Index 0-8 and 21.5 VHTP8.1.4:O Yes No N/A NSS = 2 VHTP8.1.6 VHT-MCS with Index 0-9 and 21.5 VHTP8.1.5:O Yes No N/A NSS = 2 VHTP8.1.7 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A NSS = 3 VHTP8.1.8 VHT-MCS with Index 0-8 and 21.5 VHTP8.1.7:O Yes No N/A NSS = 3 VHTP8.1.9 VHT-MCS with Index 0-9 and 21.5 VHTP8.1.7:O Yes No N/A NSS = 3 VHTP8.1.10 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A NSS = 4 VHTP8.1.11 VHT-MCS with Index 0-8 and 21.5 VHTP8.1.10:O Yes No N/A NSS = 4 VHTP8.1.12 VHT-MCS with Index 0-9 and 21.5 VHTP8.1.11:O Yes No N/A NSS = 4 VHTP8.1.13 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A NSS = 5 VHTP8.1.14 VHT-MCS with Index 0-8 and 21.5 VHTP8.1.13:O Yes No N/A NSS = 5 VHTP8.1.15 VHT-MCS with Index 0-9 and 21.5 VHTP8.1.14:O Yes No N/A NSS = 5 VHTP8.1.16 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A NSS = 6 VHTP8.1.17 VHT-MCS with Index 0-8 and 21.5 VHTP8.1.16:O Yes No N/A NSS = 6 VHTP8.1.18 VHT-MCS with Index 0-9 and 21.5 VHTP8.1.17:O Yes No N/A NSS = 6 VHTP8.1.19 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A NSS = 7 VHTP8.1.20 VHT-MCS with Index 0-8 and 21.5 VHTP8.1.19:O Yes No N/A NSS = 7 VHTP8.1.21 VHT-MCS with Index 0-9 and 21.5 VHTP8.1.20:O Yes No N/A NSS = 7 VHTP8.1.22 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A NSS = 8 VHTP8.1.23 VHT-MCS with Index 0-8 and 21.5 VHTP8.1.22:O Yes No N/A NSS = 8 VHTP8.1.24 VHT-MCS with Index 0-9 and 21.5 VHTP8.1.23:O Yes No N/A NSS = 8 VHTP8.2 CBW160 21.5 VHTP8.2.1 VHT-MCS with Index 0-7 and 21.5 VHTP3.4:M Yes No N/A NSS = 1 2766 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.25.2 VHT PHY features (continued) Item Protocol capability References Status Support VHTP8.2.2 VHT-MCS with Index 0-8 and 21.5 VHTP8.2.1:O Yes No N/A NSS = 1 VHTP8.2.3 VHT-MCS with Index 0-9 and 21.5 VHTP8.2.2:O Yes No N/A NSS = 1 VHTP8.2.4 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A NSS = 2 VHTP8.2.5 VHT-MCS with Index 0-8 and 21.5 VHTP8.2.4:O Yes No N/A NSS = 2 VHTP8.2.6 VHT-MCS with Index 0-9 and 21.5 VHTP8.2.5:O Yes No N/A NSS = 2 VHTP8.2.7 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A NSS = 3 VHTP8.2.8 VHT-MCS with Index 0-8 and 21.5 VHTP8.2.7:O Yes No N/A NSS = 3 VHTP8.2.9 VHT-MCS with Index 0-9 and 21.5 VHTP8.2.8:O Yes No N/A NSS = 3 VHTP8.2.10 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A NSS = 4 VHTP8.2.11 VHT-MCS with Index 0-8 and 21.5 VHTP8.2.10:O Yes No N/A NSS = 4 VHTP8.2.12 VHT-MCS with Index 0-9 and 21.5 VHTP8.2.11:O Yes No N/A NSS = 4 VHTP8.2.13 VHT-MCS with Index 0-7 and 21.5 CFVHT9:O Yes No N/A NSS = 5 VHTP8.2.14 VHT-MCS with Index 0-8 and 21.5 VHTP8.2.13:O Yes No N/A NSS = 5 VHTP8.2.15 VHT-MCS with Index 0-9 and 21.5 VHTP8.2.14:O Yes No N/A NSS = 5 VHTP8.2.16 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A NSS = 6 VHTP8.2.17 VHT-MCS with Index 0-8 and 21.5 VHTP8.2.16:O Yes No N/A NSS = 6 VHTP8.2.18 VHT-MCS with Index 0-9 and 21.5 VHTP8.2.17:O Yes No N/A NSS = 6 VHTP8.2.19 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A NSS = 7 VHTP8.2.20 VHT-MCS with Index 0-8 and 21.5 VHTP8.2.19:O Yes No N/A NSS = 7 VHTP8.2.21 VHT-MCS with Index 0-9 and 21.5 VHTP8.2.20:O Yes No N/A NSS = 7 VHTP8.2.22 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A NSS = 8 VHTP8.2.23 VHT-MCS with Index 0-8 and 21.5 VHTP8.2.22:O Yes No N/A NSS = 8 VHTP8.2.24 VHT-MCS with Index 0-9 and 21.5 VHTP8.2.23:O Yes No N/A NSS = 8 VHTP8.3 CBW80+80 21.5 2767 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.25.2 VHT PHY features (continued) Item Protocol capability References Status Support VHTP8.3.1 VHT-MCS with Index 0-7 and 21.5 VHTP3.5:M Yes No N/A NSS = 1 VHTP8.3.2 VHT-MCS with Index 0-8 and 21.5 VHTP8.3.1:O Yes No N/A NSS = 1 VHTP8.3.3 VHT-MCS with Index 0-9 and 21.5 VHTP8.3.2:O Yes No N/A NSS = 1 VHTP8.3.4 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A NSS = 2 VHTP8.3.5 VHT-MCS with Index 0-8 and 21.5 VHTP8.3.4:O Yes No N/A NSS = 2 VHTP8.3.6 VHT-MCS with Index 0-9 and 21.5 VHTP8.3.5:O Yes No N/A NSS = 2 VHTP8.3.7 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A NSS = 3 VHTP8.3.8 VHT-MCS with Index 0-8 and 21.5 VHTP8.3.7:O Yes No N/A NSS = 3 VHTP8.3.9 VHT-MCS with Index 0-9 and 21.5 VHTP8.3.8:O Yes No N/A NSS = 3 VHTP8.3.10 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A NSS = 4 VHTP8.3.11 VHT-MCS with Index 0-8 and 21.5 VHTP8.3.10:O Yes No N/A NSS = 4 VHTP8.3.12 VHT-MCS with Index 0-9 and 21.5 VHTP8.3.11:O Yes No N/A NSS = 4 VHTP8.3.13 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A NSS = 5 VHTP8.3.14 VHT-MCS with Index 0-8 and 21.5 VHTP8.3.13:O Yes No N/A NSS = 5 VHTP8.3.15 VHT-MCS with Index 0-9 and 21.5 VHTP8.3.14:O Yes No N/A NSS = 5 VHTP8.3.16 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A NSS = 6 VHTP8.3.17 VHT-MCS with Index 0-8 and 21.5 VHTP8.3.16:O Yes No N/A NSS = 6 VHTP8.3.18 VHT-MCS with Index 0-9 and 21.5 VHTP8.3.17:O Yes No N/A NSS = 6 VHTP8.3.19 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A NSS = 7 VHTP8.3.20 VHT-MCS with Index 0-8 and 21.5 VHTP8.3.19:O Yes No N/A NSS = 7 VHTP8.3.21 VHT-MCS with Index 0-9 and 21.5 VHTP8.3.20:O Yes No N/A NSS = 7 VHTP8.3.22 VHT-MCS with Index 0-7 and 21.5 CFVHT:O Yes No N/A NSS = 8 VHTP8.3.23 VHT-MCS with Index 0-8 and 21.5 VHTP8.3.22:O Yes No N/A NSS = 8 VHTP8.3.24 VHT-MCS with Index 0-9 and 21.5 VHTP8.3.23:O Yes No N/A NSS = 8 2768 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.25.2 VHT PHY features (continued) Item Protocol capability References Status Support VHTP8.4 Transmit and receive support for 21.5 CFVHT:O Yes No N/A 400 ns GI VHTP9 Space-time block coding (STBC) 21.3.10.9.4 CFVHT:O Yes No N/A VHTP10 Non-HT duplicate format 21.3.10.12 CFVHT:M Yes No N/A B.4.26 TVWS functions Item Protocol capability References Status Support WS1 Fixed STA TVWS operation 11.44, Annex D, E.2.5 CFTVHT:O Yes No N/A WS2 Master STA TVWS 11.44, 11.44.2, CFTVHT:O Yes No N/A operation Annex D, E.2.5 *WS3 Client STA TVWS operation 11.44.3, Annex D, CFTVHT:O Yes No N/A E.2.5 WS3.1 GDD dependent STA TVWS 11.44.3, Annex D, WS3:M Yes No N/A behavior E.2.5 WS4 Channel Availability Query 9.4.5.2, 9.6.8.25, CFTVHT:M Yes No N/A 11.44.4 WS5 Channel Schedule 9.4.5.3, 9.6.8.26, CFTVHT:M Yes No N/A Management 11.44.5 WS6 Contact Verification Signal 9.6.8.27, 11.44.6 CFTVHT:M Yes No N/A *WS7 Network Channel Control 6.3.101, 9.4.5.4, CFTVHT:M 9.6.8.30, 11.44.7 WS7.1 NCC Requesting STA 11.44.7.2 CFTVHT:M Yes No N/A WS7.2 NCC Responding STA 11.44.7.3 CFTVHT:O Yes No N/A WS8 White Space Map 9.4.2.170, 9.6.8.31, CFTVHT:M Yes No N/A Announcement 11.44.9 B.4.26.1 TVHT MAC features Item Protocol capability References Status Support Are the following MAC protocol features supported? TVHTM1 TVHT Capabilities element TVHTM1.1 VHT Capabilities element 9.4.2.158.1 CFTVHT:O Yes No N/A 2769 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.26.1 TVHT MAC features (continued) Item Protocol capability References Status Support TVHTM1.2 Signaling of STA capabilities in 9.3.3.6, 9.3.3.8, (CFTVHT Yes No N/A Probe Request, (Re)Association 9.3.3.10, AND Request frames 9.4.2.158.1 CFIndepSTA): O (CFTVHT AND CFMBSS):O TVHTM1.3 Signaling of STA and BSS 9.3.3.3, 9.3.3.7, (CFTVHT Yes No N/A capabilities in Beacon, Probe 9.3.3.9, AND CFAP):O Response, (Re)Association 9.3.3.11, (CFTVHT Response frames 9.4.2.158 AND CFMBSS):O TVHTM2 Signaling of VHT operation 9.4.2.159 (CFTVHT Yes No N/A AND CFAP):O (CFTVHT AND CFMBSS):O (CFTVHT AND CFIBSS):O TVHTM3 Link adaptation TVHTM3.1 Use of the VHT variant HT Control 9.2.4.6, CFTVHT:O Yes No N/A field for link adaptation in 9.3.3.15, immediate response exchange 10.28.3 TVHTM4 Transmit beamforming *TVHTM4.1 SU Beamformer Capable 9.4.2.158 CFTVHT:O Yes No N/A *TVHTM4.2 SU Beamformee Capable 9.4.2.158 CFTVHT:O Yes No N/A *TVHTM4.3 MU Beamformer Capable 9.4.2.158 CFAP AND Yes No N/A TVHTM4.1:O *TVHTM4.4 MU Beamformee Capable 9.4.2.158 CFIndepSTA Yes No N/A AND TVHTM4.2:O TVHTM4.5 Transmission of null data packet 10.31 TVHTM4.1:M Yes No N/A TVHTM4.6 Reception of null data packet 10.31 TVHTM4.2:M Yes No N/A TVHTM5 VHT sounding protocol TVHTM5.1 VHT sounding protocol as SU 10.34.5 TVHTM4.1:M Yes No N/A beamformer TVHTM5.2 VHT sounding protocol as SU 10.34.5 TVHTM4.2:M Yes No N/A beamformee TVHTM5.3 VHT sounding protocol as MU 10.34.5 TVHTM4.3:M Yes No N/A beamformer TVHTM5.4 VHT sounding protocol as MU 10.34.5 TVHTM4.4:M Yes No N/A beamformee TVHTM6 TXOP Sharing 2770 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.26.1 TVHT MAC features (continued) Item Protocol capability References Status Support TVHTM6.1 Sharing of EDCA TXOP 9.19.2.3a CFTVHT:O Yes No N/A TVHTM6.2 Use of Primary and Secondary AC 9.19.2.3a TVHTM6.1:M Yes No N/A TVHTM7 VHT TXOP power saving 10.2.1.4a CFTVHT:O Yes No N/A TVHTM8 BSS Operation TVHTM8.1 Use of primary TVHT_W, secondary 11.43 CFTVHT:O Yes No N/A TVHT_W, and secondary TVHT_2W channels TVHTM8.2 CCA on primary TVHT_W, 11.43 CFTVHT:O Yes No N/A secondary TVHT_W, and secondary TVHT_2W channels TVHTM9 Group ID TVHTM9.1 Transmission of Group ID 9.6.23.3 TVHTM4.3:M Yes No N/A Management frame TVHTM9.2 Reception of Group ID Management 9.6.23.3 TVHTM4.4:M Yes No N/A frame TVHTM10 Bandwidth signaling TVHTM10.1 Support for non-HT bandwidth 9.3.2.5a CFTVHT:M Yes No N/A signaling and static operation TVHTM10.2 Support for non-HT bandwidth 9.3.2.5a CFTVHT:O Yes No N/A signaling and dynamic operation TVHTM11 VHT single MPDU format 10.13.8 CFTVHT:M Yes No N/A TVHTM12 Partial AID in VHT PPDU 10.20 CFTVHT:M Yes No N/A TVHTM13 Extended BSS Load element 9.4.2.160 CFTVHT:O Yes No N/A TVHTM13.1 Transmission of the Extended BSS 9.4.2.160 CFAP AND Yes No N/A Load element CFTVHT:O TVHTM14 Quiet Channel element TVHTM14.1 Transmission of Quiet Channel 9.3.3.3, (CFAP OR Yes No N/A element by an AP or mesh STA in 9.3.3.11, CFMBSS) Beacon and Probe Response frames 9.4.2.165, AND CFSM 11.9.3 AND CFTVHT AND TVHTP3.4:O TVHTM14.2 Transmission of Quiet Channel 9.3.3.3, (CFIndepSTA Yes No N/A element by an independent STA or 9.3.3.11, OR CFMBSS) mesh STA in Beacon and Probe 9.4.2.165, AND CFSM Response frames 11.9.3 AND CFTVHT AND TVHTP3.4:O TVHTM14.3 Reception of Quiet Channel element 9.3.3.3, (CFIndepSTA Yes No N/A by an independent STA or mesh STA 9.3.3.11, OR CFMBSS) in Beacon and Probe Response 9.4.2.165, AND CFSM frames 11.9.3 AND CFTVHT:O 2771 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.26.1 TVHT MAC features (continued) Item Protocol capability References Status Support TVHTM15 Space-time block coding (STBC) TVHTM15.1 STBC operation 9.4.2.158, TVHTP9:M Yes No N/A 10.15 TVHTM15.2 Transmission of at least 2x1 STBC 9.4.2.158 TVHTP9:O.1 Yes No N/A TVHTM15.3 Reception of 1 STBC spatial stream 9.4.2.158 TVHTP9:O.1 Yes No N/A TVHTM15.4 Reception of 2 STBC spatial stream 9.4.2.158 TVHTM15.3:O Yes No N/A TVHTM15.5 Reception of 3 STBC spatial stream 9.4.2.158 TVHTM15.4:O Yes No N/A TVHTM15.6 Reception of 4 STBC spatial stream 9.4.2.158 TVHTM15.5:O Yes No N/A TVHTM16 Highest Supported Long GI Data Rate TVHTM16.1 Tx Highest Supported Long GI Data 9.4.2.158.3 CFTVHT:O Yes No N/A Rate TVHTM16.2 Rx Highest Supported Long GI Data 9.4.2.158.3 CFTVHT:O Yes No N/A Rate NOTEâ€”Required support for MCS might be limited by the declaration of Tx and Rx Highest Supported Long GI Data Rates. B.4.26.2 TVHT PHY features Item Protocol capability References Status Support Are the following PHY protocol features supported? TVHTP1 PHY operating modes Yes No N/A TVHTP2 VHT format 21.3.2 CFTVHT:M Yes No N/A TVHTP3 BSS bandwidth TVHTP3.1 TVHT_W operation 11.43 CFTVHT:M Yes No N/A TVHTP3.2 TVHT_2W operation 11.43 CFTVHT:O Yes No N/A TVHTP3.3 TVHT_W+W operation 11.43 CFTVHT:O Yes No N/A TVHTP3.4 TVHT_4W operation 11.43 CFTVHT:O Yes No N/A TVHTP3.5 TVHT_2W+2W operation 11.43 CFTVHT:O Yes No N/A TVHTP4 Bandwidth indication 17.3.5.5 CFVHT:M Yes No N/A TVHTP5 PHY timing parameters TVHTP5.1 Values in 6 MHz channel 22.3.6 CFTVHT:M Yes No N/A TVHTP5.2 Values in 7 MHz channel 22.3.6 CFTVHT:M Yes No N/A TVHTP5.3 Values in 8 MHz channel 22.3.6 CFTVHT:M Yes No N/A 2772 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.26.2 TVHT PHY features (continued) Item Protocol capability References Status Support TVHTP5.4 Values in non-HT 6 MHz, 7 MHz, and 22.2.4 CFTVHT:M Yes No N/A 8 MHz channels TVHTP6 TVHT preamble 22.3.8 CFTVHT:M Yes No N/A TVHTP7 Use of LDPC Code 11.5.4, 21.3 CFTVHT:O Yes No N/A TVHTP8 Modulation and coding schemes (MCS) TVHTP8.1 TVHT_MODE_1 22.5 TVHTP8.1.1 TVHT-MCS with Index 0-7 and 22.5 CFTVHT:M Yes No N/A NSS = 1 TVHTP8.1.2 TVHT-MCS with Index 0-8 and 22.5 TVHTP8.1.1:O Yes No N/A NSS = 1 TVHTP8.1.3 TVHT-MCS with Index 0-9 and 22.5 TVHTP8.1.2:O Yes No N/A NSS = 1 TVHTP8.1.4 TVHT-MCS with Index 0-7 and 22.5 CFTVHT:O Yes No N/A NSS = 2 TVHTP8.1.5 TVHT-MCS with Index 0-8 and 22.5 TVHTP8.1.4:O Yes No N/A NSS = 2 TVHTP8.1.6 TVHT-MCS with Index 0-9 and 22.5 TVHTP8.1.5:O Yes No N/A NSS = 2 TVHTP8.1.7 TVHT-MCS with Index 0-7 and 22.5 CFTVHT:O Yes No N/A NSS = 3 TVHTP8.1.8 TVHT-MCS with Index 0-8 and 22.5 TVHTP8.1.7:O Yes No N/A NSS = 3 TVHTP8.1.9 TVHT-MCS with Index 0-9 and 22.5 TVHTP8.1.7:O Yes No N/A NSS = 3 TVHTP8.1.10 TVHT-MCS with Index 0-7 and 22.5 CFTVHT:O Yes No N/A NSS = 4 TVHTP8.1.11 TVHT-MCS with Index 0-8 and 22.5 TVHTP8.1.10: Yes No N/A NSS = 4 O TVHTP8.1.12 TVHT-MCS with Index 0-9 and 22.5 TVHTP8.1.11: Yes No N/A NSS = 4 O TVHTP8.2 TVHT_MODE_2C and 22.5 TVHT_MODE_2N TVHTP8.2.1 TVHT-MCS with Index 0-7 and 22.5 (TVHTP3.2 Yes No N/A NSS = 1 AND TVHTP3.3):M TVHTP8.2.2 TVHT-MCS with Index 0-8 and 22.5 TVHTP8.2.1:O Yes No N/A NSS = 1 TVHTP8.2.3 TVHT-MCS with Index 0-9 and 22.5 TVHTP8.2.2:O Yes No N/A NSS = 1 2773 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.26.2 TVHT PHY features (continued) Item Protocol capability References Status Support TVHTP8.2.4 TVHT-MCS with Index 0-7 and 22.5 (TVHTP3.2 Yes No N/A NSS = 2 AND TVHTP3.3):O TVHTP8.2.5 TVHT-MCS with Index 0-8 and 22.5 TVHTP8.2.4:O Yes No N/A NSS = 2 TVHTP8.2.6 TVHT-MCS with Index 0-9 and 22.5 TVHTP8.2.5:O Yes No N/A NSS = 2 TVHTP8.2.7 TVHT-MCS with Index 0-7 and 22.5 (TVHTP3.2 Yes No N/A NSS = 3 AND TVHTP3.3):O TVHTP8.2.8 TVHT-MCS with Index 0-8 and 22.5 TVHTP8.2.7:O Yes No N/A NSS = 3 TVHTP8.2.9 TVHT-MCS with Index 0-9 and 22.5 TVHTP8.2.8:O Yes No N/A NSS = 3 TVHTP8.2.10 TVHT-MCS with Index 0-7 and 22.5 (TVHTP3.2 Yes No N/A NSS = 4 AND TVHTP3.3):O TVHTP8.2.11 TVHT-MCS with Index 0-8 and 22.5 TVHTP8.2.10: Yes No N/A NSS = 4 O TVHTP8.2.12 TVHT-MCS with Index 0-9 and 22.5 TVHTP8.2.11: Yes No N/A NSS = 4 O TVHTP8.3 TVHT_MODE_4C and 22.5 TVHT_MODE_4N TVHTP8.3.1 TVHT-MCS with Index 0-7 and 22.5 (TVHTP3.4 Yes No N/A NSS = 1 AND TVHTP3.5):M TVHTP8.3.2 TVHT-MCS with Index 0-8 and 22.5 TVHTP8.3.1:O Yes No N/A NSS = 1 TVHTP8.3.3 TVHT-MCS with Index 0-9 and 22.5 TVHTP8.3.2:O Yes No N/A NSS = 1 TVHTP8.3.4 TVHT-MCS with Index 0-7 and 22.5 (TVHTP3.4 Yes No N/A NSS = 2 AND TVHTP3.5):O TVHTP8.3.5 TVHT-MCS with Index 0-8 and 22.5 TVHTP8.3.4:O Yes No N/A NSS = 2 TVHTP8.3.6 TVHT-MCS with Index 0-9 and 22.5 TVHTP8.3.5:O Yes No N/A NSS = 2 TVHTP8.3.7 TVHT-MCS with Index 0-7 and 22.5 (TVHTP3.4 Yes No N/A NSS = 3 AND TVHTP3.5):O TVHTP8.3.8 TVHT-MCS with Index 0-8 and 22.5 TVHTP8.3.7:O Yes No N/A NSS = 3 TVHTP8.3.9 TVHT-MCS with Index 0-9 and 22.5 TVHTP8.3.8:O Yes No N/A NSS = 3 2774 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B.4.26.2 TVHT PHY features (continued) Item Protocol capability References Status Support TVHTP8.3.10 TVHT-MCS with Index 0-7 and 22.5 (TVHTP3.4 Yes No N/A NSS = 4 AND TVHTP3.5):O TVHTP8.3.11 TVHT-MCS with Index 0-8 and 22.5 TVHTP8.3.10: Yes No N/A NSS = 4 O TVHTP8.3.12 TVHT-MCS with Index 0-9 and 22.5 TVHTP8.3.11: Yes No N/A NSS = 4 O TVHTP9 Space-time block coding (STBC) 22.3.10.9.4 CFTVHT:O Yes No N/A 2775 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Annex C (normative) ASN.1 encoding of the MAC and PHY MIB C.1 General The MIB for the current revision of IEEE Std 802.11 is available online at the following URL: http:// www.ieee802.org/11/802.11mib.txt. The MAC and PHY MIBs are described in Abstract Syntax Notation One (ASN.1), defined in ISO/IEC 8824-1:1995, ISO/IEC 8824-2:1995, ISO/IEC 8824-3:1995 and ISO/IEC 8824-4:1995. C.2 Guidelines for IEEE 802.11 MIB authors/editors The MIB may be compiled using the "smitools" package from the Institute of Operating Systems and Computer Networks at the Technical University of Braunschweig, Germany. These tools may be accessed online using the following URL: http://www.ibr.cs.tu-bs.de/bin/smitools.cgi. Using this tool, the MIB should compile without generating warnings of severity 3 or lower. Specific points that authors and editors should pay attention to: â€” The MIB should compile as specified above prior to submission to IEEE-SA RevCom. â€” Use only the 7-bit US-ASCII character-set. In particular, use only straight single and double quotes. â€” Do not use symbols such as in units, instead spell out the units fully, i.e., "microseconds." â€” Follow the guidelines for writing MIB modules in http://www.rfc-editor.org/rfc/rfc4181.txt (including any updates thereto). â€” Pay attention to IETF recommendations on object types. â€” When adding a lot of new objects, consider adding a new module. â€” Consider seeking advice from an IETF MIB Doctor when creating significant new material. The IEEE has an arrangement with the IETF whereby the IEEE may ask for a MIB Advisor from the IETF MIB Doctors. â€” When an object is deprecated, add a line to the Description indicating why (IETF convention). C.3 MIB detail -- ********************************************************************** -- * IEEE 802.11 MIB -- ********************************************************************** IEEE802dot11-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Integer32, Counter32, Counter64, Unsigned32, TimeTicks, Gauge32 FROM SNMPv2-SMI DisplayString , MacAddress, RowStatus, TruthValue, 2776 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications TEXTUAL-CONVENTION FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF ifIndex, InterfaceIndex FROM IF-MIB; -- ********************************************************************** -- * MODULE IDENTITY -- ********************************************************************** ieee802dot11 MODULE-IDENTITY LAST-UPDATED "201612140000Z" ORGANIZATION "IEEE Std 802.11" CONTACT-INFO "Chair: Adrian P Stephens Postal: 64 Lambs Lane Cottenham, Cambridge, CB24 8TA, United Kingdom Tel: +44 1793 404825 E-mail: adrian.p.stephens@ieee.org Editor: Adrian P Stephens E-mail: adrian.p.stephens@ieee.org" DESCRIPTION "The MIB module for IEEE 802.11 entities. iso(1).member-body(2).us(840).ieee802dot11(10036)" REVISION "201612140000Z" DESCRIPTION "IEEE Std 802.11-2016 Note that not all objects within this MIB are referenced by a group, and not all groups are referenced by a MODULE-COMPLIANCE statement. Some existing groups and the dot11Compliance MODULE-COMPLIANCE have been modified since the previous revision of this standard." REVISION "201203300000Z" DESCRIPTION "IEEE Std 802.11-2012. Note that not all objects within this MIB are referenced by a group, and not all groups are referenced by a MODULE-COMPLIANCE statement. Some existing groups and the dot11Compliance MODULE-COMPLIANCE have been modified since the previous revision of this standard. Implementations should not claim compliance to dot11Compliance." ::= { us 10036 } -- ********************************************************************** -- * Tree Definition -- ********************************************************************** member-body OBJECT IDENTIFIER ::= { iso 2 } us OBJECT IDENTIFIER ::= { member-body 840 } -- ********************************************************************** -- * Major sections -- ********************************************************************** -- Station ManagemenT (SMT) Attributes -- DEFINED AS "The SMT object class provides the necessary support -- at the station to manage the processes in the station such that -- the station may work cooperatively as a part of an IEEE 802.11 -- network." 2777 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11smt OBJECT IDENTIFIER ::= { ieee802dot11 1 } -- dot11smt GROUPS -- dot11StationConfigTable ::= { dot11smt 1 } -- dot11AuthenticationAlgorithmsTable ::= { dot11smt 2 } -- dot11WEPDefaultKeysTable ::= { dot11smt 3 } -- dot11WEPKeyMappingsTable ::= { dot11smt 4 } -- dot11PrivacyTable ::= { dot11smt 5 } -- dot11SMTnotification ::= { dot11smt 6 } -- dot11MultiDomainCapabilityTable ::= { dot11smt 7 } -- dot11SpectrumManagementTable ::= { dot11smt 8 } -- dot11RSNAConfigTable ::= { dot11smt 9 } -- dot11RSNAConfigPairwiseCiphersTable ::= { dot11smt 10 } -- dot11RSNAConfigAuthenticationSuitesTable ::= { dot11smt 11 } -- dot11RSNAStatsTable ::= { dot11smt 12 } -- dot11OperatingClassesTable ::= { dot11smt 13 } -- dot11RadioMeasurement ::= { dot11smt 14 } -- dot11FastBSSTransitionConfigTable ::= { dot11smt 15 } -- dot11LCIDSETable ::= { dot11smt 16 } -- dot11HTStationConfigTable ::= { dot11smt 17 } -- dot11WirelessMgmtOptionsTable ::= { dot11smt 18} -- dot11LocationServicesNextIndex ::= { dot11smt 19} -- dot11LocationServicesTable ::= { dot11smt 20} -- dot11WirelessMGTEventTable ::= { dot11smt 21} -- dot11WirelessNetworkManagement ::= { dot11smt 22} -- dot11MeshSTAConfigTable ::= { dot11smt 23 } -- dot11MeshHWMPConfigTable ::= { dot11smt 24 } -- dot11RSNAConfigPasswordValueTable ::= { dot11smt 25 } -- dot11RSNAConfigDLCGroupTable ::= { dot11smt 26 } -- dot11DMGSTAConfigTable ::= { dot11smt 27 } -- dot11AVOptionsTable ::= { dot11smt 28 } -- dot11AVConfigTable ::= { dot11smt 29 } -- dot11APCTable ::= { dot11smt 30 } -- dot11VHTStationConfigTable ::= { dot11smt 31 } -- dot11TVHTStationConfigTable ::= { dot11smt 32 } -- dot11STALCITable ::= { dot11smt 33 } -- dot11STALCIConfigTable ::= { dot11smt 36 } -- dot11STACivicLocationConfigTable ::= { dot11smt 37 } -- MAC Attributes -- DEFINED AS "The MAC object class provides the necessary support -- for the access control, generation, and verification of frame -- check sequences (FCSs), and proper delivery of valid data to -- upper layers." dot11mac OBJECT IDENTIFIER ::= { ieee802dot11 2 } -- MAC GROUPS -- dot11OperationTable ::= { dot11mac 1 } -- dot11CountersTable ::= { dot11mac 2 } -- dot11GroupAddressesTable ::= { dot11mac 3 } -- dot11EDCATable ::= { dot11mac 4 } -- dot11QAPEDCATable ::= { dot11mac 5 } -- dot11QosCountersTable ::= { dot11mac 6 } -- dot11ResourceInfoTable ::= { dot11mac 7 } -- dot11DMGOperationTable ::= { dot11mac 8 } -- dot11DMGCountersTable ::= { dot11mac 9 } -- dot11BSSStatisticsTable ::= { dot11mac 10 } -- Resource Type ID dot11res OBJECT IDENTIFIER ::= { ieee802dot11 3 } dot11resAttribute OBJECT IDENTIFIER ::= { dot11res 1 } -- PHY Attributes -- DEFINED AS "The PHY object class provides the necessary support 2778 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications -- for required PHY operational information that may vary from PHY -- to PHY and from STA to STA to be communicated to upper layers." dot11phy OBJECT IDENTIFIER ::= { ieee802dot11 4 } -- PHY GROUPS -- dot11PhyOperationTable ::= { dot11phy 1 } -- dot11PhyAntennaTable ::= { dot11phy 2 } -- dot11PhyTxPowerTable ::= { dot11phy 3 } -- dot11PhyDSSSTable ::= { dot11phy 5 } -- dot11RegDomainsSupportedTable ::= { dot11phy 7 } -- dot11AntennasListTable ::= { dot11phy 8 } -- dot11SupportedDataRatesTxTable ::= { dot11phy 9 } -- dot11SupportedDataRatesRxTable ::= { dot11phy 10 } -- dot11PhyOFDMTable ::= { dot11phy 11 } -- dot11PhyHRDSSSTable ::= { dot11phy 12 } -- dot11HoppingPatternTable ::= { dot11phy 13 } -- dot11PhyERPTable ::= { dot11phy 14 } -- dot11PhyHTTable ::= { dot11phy 15 } -- dot11SupportedMCSTxTable ::= { dot11phy 16 } -- dot11SupportedMCSRxTable ::= { dot11phy 17 } -- dot11TransmitBeamformingConfigTable ::= { dot11phy 18 } -- dot11PHYDMGTable ::= { dot11phy 19 } -- dot11DMGBeamformingConfigTable ::= { dot11phy 22 } -- ********************************************************************** -- * Textual conventions for 802 definitions -- ********************************************************************** WEPKeytype ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents the type of WEP key." SYNTAX OCTET STRING (SIZE (5)) TSFType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents the type of TSF." SYNTAX OCTET STRING (SIZE (8)) -- ********************************************************************** -- * MIB attribute OBJECT-TYPE definitions follow -- ********************************************************************** -- ********************************************************************** -- * dot11StationConfig TABLE -- ********************************************************************** dot11StationConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11StationConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Station Configuration attributes. In tabular form to allow for multiple instances on an agent." ::= { dot11smt 1 } dot11StationConfigEntry OBJECT-TYPE SYNTAX Dot11StationConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11StationConfigTable. It is possible for there to be multiple IEEE 802.11 interfaces on one agent, each with its unique MAC address. The relationship between an IEEE 802.11 interface and an 2779 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications interface in the context of the Internet-standard MIB is one-to-one. As such, the value of an ifIndex object instance can be directly used to identify corresponding instances of the objects defined herein. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX { ifIndex } ::= { dot11StationConfigTable 1 } Dot11StationConfigEntry ::= SEQUENCE { dot11StationID MacAddress, dot11MediumOccupancyLimit Unsigned32, dot11CFPollable TruthValue, dot11CFPPeriod Unsigned32, dot11CFPMaxDuration Unsigned32, dot11AuthenticationResponseTimeout Unsigned32, dot11PrivacyOptionImplemented TruthValue, dot11PowerManagementMode INTEGER, dot11DesiredSSID OCTET STRING, dot11DesiredBSSType INTEGER, dot11OperationalRateSet OCTET STRING, dot11BeaconPeriod Unsigned32, dot11DTIMPeriod Unsigned32, dot11AssociationResponseTimeout Unsigned32, dot11DisassociateReason Unsigned32, dot11DisassociateStation MacAddress, dot11DeauthenticateReason Unsigned32, dot11DeauthenticateStation MacAddress, dot11AuthenticateFailStatus Unsigned32, dot11AuthenticateFailStation MacAddress, dot11MultiDomainCapabilityImplemented TruthValue, dot11MultiDomainCapabilityActivated TruthValue, dot11CountryString OCTET STRING, dot11SpectrumManagementImplemented TruthValue, dot11SpectrumManagementRequired TruthValue, dot11RSNAOptionImplemented TruthValue, dot11RSNAPreauthenticationImplemented TruthValue, dot11OperatingClassesImplemented TruthValue, dot11OperatingClassesRequired TruthValue, dot11QosOptionImplemented TruthValue, dot11ImmediateBlockAckOptionImplemented TruthValue, dot11DelayedBlockAckOptionImplemented TruthValue, dot11DirectOptionImplemented TruthValue, dot11APSDOptionImplemented TruthValue, dot11QAckOptionImplemented TruthValue, dot11QBSSLoadImplemented TruthValue, dot11QueueRequestOptionImplemented TruthValue, dot11TXOPRequestOptionImplemented TruthValue, dot11MoreDataAckOptionImplemented TruthValue, dot11AssociateInNQBSS TruthValue, dot11DLSAllowedInQBSS TruthValue, dot11DLSAllowed TruthValue, dot11AssociateStation MacAddress, dot11AssociateID Unsigned32, dot11AssociateFailStation MacAddress, dot11AssociateFailStatus Unsigned32, dot11ReassociateStation MacAddress, dot11ReassociateID Unsigned32, dot11ReassociateFailStation MacAddress, dot11ReassociateFailStatus Unsigned32, dot11RadioMeasurementImplemented TruthValue, dot11RadioMeasurementActivated TruthValue, dot11RMMeasurementNavSync Unsigned32, 2780 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11RMMeasurementPilotPeriod Unsigned32, dot11RMLinkMeasurementActivated TruthValue, dot11RMNeighborReportActivated TruthValue, dot11RMParallelMeasurementsActivated TruthValue, dot11RMRepeatedMeasurementsActivated TruthValue, dot11RMBeaconPassiveMeasurementActivated TruthValue, dot11RMBeaconActiveMeasurementActivated TruthValue, dot11RMBeaconTableMeasurementActivated TruthValue, dot11RMBeaconMeasurementReportingConditionsActivated TruthValue, dot11RMFrameMeasurementActivated TruthValue, dot11RMChannelLoadMeasurementActivated TruthValue, dot11RMNoiseHistogramMeasurementActivated TruthValue, dot11RMStatisticsMeasurementActivated TruthValue, dot11RMLCIMeasurementActivated TruthValue, dot11RMLCIAzimuthActivated TruthValue, dot11RMTransmitStreamCategoryMeasurementActivated TruthValue, dot11RMTriggeredTransmitStreamCategoryMeasurementActivated TruthValue, dot11RMAPChannelReportActivated TruthValue, dot11RMMIBActivated TruthValue, dot11RMMaxMeasurementDuration Unsigned32, dot11RMNonOperatingChannelMaxMeasurementDuration Unsigned32, dot11RMMeasurementPilotTransmissionInformationActivated TruthValue, dot11RMMeasurementPilotActivated Unsigned32, dot11RMNeighborReportTSFOffsetActivated TruthValue, dot11RMRCPIMeasurementActivated TruthValue, dot11RMRSNIMeasurementActivated TruthValue, dot11RMBSSAverageAccessDelayActivated TruthValue, dot11RMBSSAvailableAdmissionCapacityActivated TruthValue, dot11RMAntennaInformationActivated TruthValue, dot11FastBSSTransitionImplemented TruthValue, dot11LCIDSEImplemented TruthValue, dot11LCIDSERequired TruthValue, dot11DSERequired TruthValue, dot11ExtendedChannelSwitchActivated TruthValue, dot11RSNAProtectedManagementFramesActivated TruthValue, dot11RSNAUnprotectedManagementFramesAllowed TruthValue, dot11AssociationSAQueryMaximumTimeout Unsigned32, dot11AssociationSAQueryRetryTimeout Unsigned32, dot11HighThroughputOptionImplemented TruthValue, dot11RSNAPBACRequired TruthValue, dot11PSMPOptionImplemented TruthValue, dot11TunneledDirectLinkSetupImplemented TruthValue, dot11TDLSPeerUAPSDBufferSTAActivated TruthValue, dot11TDLSPeerPSMActivated TruthValue, dot11TDLSPeerUAPSDIndicationWindow Unsigned32, dot11TDLSChannelSwitchingActivated TruthValue, dot11TDLSPeerSTAMissingAckRetryLimit Unsigned32, dot11TDLSResponseTimeout Unsigned32, dot11OCBActivated TruthValue, dot11TDLSNavSync Unsigned32, dot11TDLSDiscoveryRequestWindow Unsigned32, dot11TDLSACDeterminationInterval Unsigned32, dot11WirelessManagementImplemented TruthValue, dot11BssMaxIdlePeriod Unsigned32, dot11BssMaxIdlePeriodOptions OCTET STRING, dot11TIMBroadcastInterval Unsigned32, dot11TIMBroadcastOffset Integer32, dot11TIMBroadcastHighRateTIMRate Unsigned32, dot11TIMBroadcastLowRateTIMRate Unsigned32, dot11StatsMinTriggerTimeout Unsigned32, dot11RMCivicMeasurementActivated TruthValue, dot11RMIdentifierMeasurementActivated TruthValue, 2781 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11TimeAdvertisementDTIMInterval Unsigned32, dot11TimeAdvertisementTimeError OCTET STRING, dot11TimeAdvertisementTimeValue OCTET STRING, dot11RM3rdPartyMeasurementActivated TruthValue, dot11InterworkingServiceImplemented TruthValue, dot11InterworkingServiceActivated TruthValue, dot11QosMapImplemented TruthValue, dot11QosMapActivated TruthValue, dot11EBRImplemented TruthValue, dot11EBRActivated TruthValue, dot11ESNetwork TruthValue, dot11SSPNInterfaceImplemented TruthValue, dot11SSPNInterfaceActivated TruthValue, dot11HESSID MacAddress, dot11EASImplemented TruthValue, dot11EASActivated TruthValue, dot11MSGCFImplemented TruthValue, dot11MSGCFActivated TruthValue, dot11MeshActivated TruthValue, dot11RejectUnadmittedTraffic TruthValue, dot11BSSBroadcastNullCount Unsigned32, dot11QMFActivated TruthValue, dot11QMFReconfigurationActivated TruthValue, dot11QMFPolicyChangeTimeout Unsigned32, dot11RobustAVStreamingImplemented TruthValue, dot11MultibandImplemented TruthValue, dot11DynamicEIFSActivated TruthValue, dot11VHTOptionImplemented TruthValue, dot11OperatingModeNotificationImplemented TruthValue, dot11TVHTOptionImplemented TruthValue, dot11ChannelScheduleManagementActivated TruthValue, dot11ContactVerificationSignalActivated TruthValue, dot11ContactVerificationSignalInterval Unsigned32, dot11NetworkChannelControlActivated TruthValue, dot11RLSSActivated TruthValue, dot11WhiteSpaceMapActivated TruthValue, dot11WSSTAType INTEGER, dot11GeolocationCapabilityActivated TruthValue, dot11GDDActivated TruthValue, dot11GDDEnablementTimeLimit Unsigned32, dot11GDDEnablementFailHoldTime Unsigned32, dot11GDDEnablementValidityTimer Unsigned32, dot11MaxMSDULength INTEGER, dot11ExtendedSpectrumManagementImplemented TruthValue, dot11EstimatedServiceParametersOptionImplemented TruthValue, dot11VHTExtendedNSSBWCapable TruthValue, dot11FutureChannelGuidanceActivated TruthValue } dot11StationID OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or external management entity. Changes take effect for the next MLME-START.request primitive. The purpose of dot11StationID is to allow a manager to identify a station for its own purposes. This attribute provides for that eventuality while keeping the true MAC address independent. Its syntax is MAC address, and the default value is the station's assigned, unique MAC address." ::= { dot11StationConfigEntry 1 } 2782 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11MediumOccupancyLimit OBJECT-TYPE SYNTAX Unsigned32 (0..1000) UNITS "TUs" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute indicates the maximum amount of time that a point coordinator (PC) may control the usage of the wireless medium (WM) without relinquishing control for long enough to allow at least one instance of DCF access to the medium. The maximum value of this variable is 1000." DEFVAL { 100 } ::= { dot11StationConfigEntry 2 } dot11CFPollable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. When this attribute is true, it indicates that the STA is able to respond to a CF-Poll with a Data frame within a SIFS. This attribute is false if the STA is not able to respond to a CF-Poll with a Data frame within a SIFS." ::= { dot11StationConfigEntry 3 } dot11CFPPeriod OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. In an AP, it is written by the MAC when it receives an MLME-START.request primitive. In a non-AP STA, it is written by the MAC when it receives an updated CF Parameter Set in a Beacon frame. The attribute describes the number of DTIM intervals between the start of CFPs. It is modified by MLME-START.request primitive." ::= { dot11StationConfigEntry 4 } dot11CFPMaxDuration OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "TUs" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. In an AP, it is written by the MAC when it receives an MLME-START.request primitive. In a non-AP STA, it is written by the MAC when it receives an updated CF Parameter Set in a Beacon frame. The attribute describes the maximum duration of the CFP that may be generated by the PCF. It is modified by MLME-START.request primitive." ::= { dot11StationConfigEntry 5 } dot11AuthenticationResponseTimeout OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) 2783 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MAX-ACCESS read-write STATUS Deprecated DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect for the next Authentication frame. This attribute specifies the number of time units (TUs) that a responding STA should wait for the next frame in the authentication sequence." ::= { dot11StationConfigEntry 6 } dot11PrivacyOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the IEEE 802.11 WEP option is implemented." DEFVAL { false } ::= { dot11StationConfigEntry 7 } dot11PowerManagementMode OBJECT-TYPE SYNTAX INTEGER { active(1), powersave(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when an MLME-POWERMGT.request primitive is received. This attribute specifies the power management mode of the STA. When equal to active, it indicates that the station is not in power save (PS) mode. When equal to powersave, it indicates that the station is in power save mode. The power management mode is transmitted in all frames according to the rules in 9.2.4.1.8." ::= { dot11StationConfigEntry 8 } dot11DesiredSSID OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect for the next MLME-SCAN.request primitive. This attribute reflects the Service Set ID (SSID) used in the SSID parameter of the most recent MLME-SCAN.request primitive. This value may be modified by an external management entity and used by the local SME to make decisions about the Scanning process." ::= { dot11StationConfigEntry 9 } dot11DesiredBSSType OBJECT-TYPE SYNTAX INTEGER { infrastructure(1), independent(2), any(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect for the next MLME-SCAN.request primitive. 2784 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This attribute specifies the type of BSS the station uses when scanning for a BSS with which to synchronize. This value is used to filter Probe Response frames and Beacon frames. When equal to infrastructure, the station synchronizes only with a BSS in which the Capability Information field has the ESS subfield equal to 1. When equal to independent, the station synchronizes only with a BSS whose Capability Information field has the IBSS subfield equal to 1. When equal to any, the station may synchronize to either type of BSS." ::= { dot11StationConfigEntry 10 } dot11OperationalRateSet OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1..126)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when joining or establishing a BSS. This attribute specifies the set of non-HT data rates at which the station is able to receive data. Each octet contains a value representing a rate. Each rate is within the range 2 to 127, corresponding to data rates in increments of 500 kb/s from 1 Mb/s to 63.5 Mb/s, and is supported (as indicated in the supported rates table) for receiving data. This value is reported in transmitted Beacon, Probe Request, Probe Response, Association Request, Association Response, Reassociation Request, and Reassociation Response frames, and is used to determine whether a BSS with which the station might synchronize is suitable. It is also used when starting a BSS, as specified in 6.3.4." ::= { dot11StationConfigEntry 11 } dot11BeaconPeriod OBJECT-TYPE SYNTAX Unsigned32 (1..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect for the next MLME-START.request primitive. For non-DMG STAs, this attribute specifies the number of TUs that a station uses for scheduling Beacon transmissions. For DMG STAs, this attribute specifies the number of TUs that a station uses for scheduling BTI and/or ATI in the beacon interval. This value is transmitted in Beacon and Probe Response frames." ::= { dot11StationConfigEntry 12 } dot11DTIMPeriod OBJECT-TYPE SYNTAX Unsigned32(1..255) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect for the next MLME-START.request primitive. This attribute specifies the number of beacon intervals that elapse between transmission of Beacon frames containing a TIM element whose DTIM Count field is 0. This value is transmitted in the DTIM Period field of Beacon frames." ::= { dot11StationConfigEntry 13 } dot11AssociationResponseTimeout OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-write 2785 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the number of TU that a requesting STA should wait for a response to a transmitted (Re)Association Request frame." ::= { dot11StationConfigEntry 14 } dot11DisassociateReason OBJECT-TYPE SYNTAX Unsigned32(0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a STA disassociates. This attribute holds the most recently transmitted Reason Code in a Disassociation frame. If no Disassociation frame has been transmitted, the value of this attribute is 0." REFERENCE "IEEE Std 802.11-2016, 9.4.1.7" ::= { dot11StationConfigEntry 15 } dot11DisassociateStation OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a STA disassociates. This attribute holds the MAC address from the Address 1 field of the most recently transmitted Disassociation frame. If no Disassociation frame has been transmitted, the value of this attribute is 0." ::= { dot11StationConfigEntry 16 } dot11DeauthenticateReason OBJECT-TYPE SYNTAX Unsigned32(0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a STA deauthenticates. This attribute holds the most recently transmitted Reason Code in a Deauthentication frame. If no Deauthentication frame has been transmitted, the value of this attribute is 0." REFERENCE "IEEE Std 802.11-2016, 9.4.1.7" ::= { dot11StationConfigEntry 17 } dot11DeauthenticateStation OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a STA deauthenticates. This attribute holds the MAC address from the Address 1 field of the most recently transmitted Deauthentication frame. If no Deauthentication frame has been transmitted, the value of this attribute is 0." ::= { dot11StationConfigEntry 18 } 2786 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11AuthenticateFailStatus OBJECT-TYPE SYNTAX Unsigned32(0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a STA fails to authenticate. This attribute holds the most recently transmitted Status Code in a failed Authentication frame. If no failed Authentication frame has been transmitted, the value of this attribute is 0." REFERENCE "IEEE Std 802.11-2016, 9.4.1.9" ::= { dot11StationConfigEntry 19 } dot11AuthenticateFailStation OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a STA fails to authenticate. This attribute holds the MAC address from the Address 1 field of the most recently transmitted failed Authentication frame. If no failed Authentication frame has been transmitted, the value of this attribute is 0." ::= { dot11StationConfigEntry 20 } dot11MultiDomainCapabilityImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of supporting multiple regulatory domains. The capability is disabled, otherwise." DEFVAL { false } ::= { dot11StationConfigEntry 21 } dot11MultiDomainCapabilityActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or external management entity. Changes take effect for the next MLME-START.request primitive. This attribute, when true, indicates that the capability of the station to operate in multiple regulatory domains is enabled." DEFVAL { false } ::= { dot11StationConfigEntry 22 } dot11CountryString OBJECT-TYPE SYNTAX OCTET STRING (SIZE(3)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME. Changes take effect for the next MLME-START.request primitive. 2787 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This attribute identifies the country or noncountry entity in which the station is operating. If it is a country, the first two octets of this string is the two character country code as described in document ISO 3166-1. The third octet is one of the following: 1. an ASCII space character, if the regulations under which the station is operating encompass all environments for the current frequency band in the country, 2. an ASCII 'O' character, if the regulations under which the station is operating are for an outdoor environment only, or 3. an ASCII 'I' character, if the regulations under which the station is operating are for an indoor environment only. 4. an ASCII 'X' character, if the station is operating under a noncountry entity. The first two octets of the noncountry entity is two ASCII 'XX' characters. 5. the hexadecimal representation of the Operating Class table number currently in use, from the set of tables defined in Annex E, e.g., Table E- 1 is represented as x'01'." ::= { dot11StationConfigEntry 23 } dot11SpectrumManagementImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of supporting spectrum management. The capability is disabled otherwise." DEFVAL { false } ::= { dot11StationConfigEntry 24 } dot11SpectrumManagementRequired OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or external management entity. Changes take effect for the next MLME-START.request primitive. A STA uses the defined TPC and DFS procedures if this attribute is true; otherwise it does not use the defined TPC and DFS procedures." DEFVAL { false } ::= { dot11StationConfigEntry 25 } dot11RSNAOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This variable indicates whether the entity is RSNA-capable." ::= { dot11StationConfigEntry 26 } 2788 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11RSNAPreauthenticationImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This variable indicates whether the entity supports RSNA preauthentication. This cannot be true unless dot11RSNAOptionImplemented is true." ::= { dot11StationConfigEntry 27 } dot11OperatingClassesImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of supporting operating classes. The capability is disabled otherwise." DEFVAL { false } ::= { dot11StationConfigEntry 28 } dot11OperatingClassesRequired OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or external management entity. Changes take effect for the next MLME-START.request primitive. A STA uses the defined operating classes procedures if this attribute is true." DEFVAL { false } ::= { dot11StationConfigEntry 29 } dot11QosOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of supporting QoS. The capability is disabled, otherwise." DEFVAL { false } ::= { dot11StationConfigEntry 30} dot11ImmediateBlockAckOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is 2789 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications capable of supporting immediate block ack. The capability is disabled, otherwise." DEFVAL { false } ::= { dot11StationConfigEntry 31} dot11DelayedBlockAckOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of supporting delayed block ack. The capability is disabled, otherwise." DEFVAL { false } ::= { dot11StationConfigEntry 32 } dot11DirectOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of sending and receiving frames from a non-AP STA in the BSS. The capability is disabled, otherwise." DEFVAL { false } ::= { dot11StationConfigEntry 33 } dot11APSDOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute is available only at an AP. When true, this attribute indicates that the AP implementation is capable of delivering data and polls to stations using APSD." ::= { dot11StationConfigEntry 34 } dot11QAckOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of interpreting the CF-Ack bit in a received frame with the Type subfield equal to Data even if the frame is not directed to the QoS station. The capability is disabled, otherwise. A STA is capable of interpreting the CF-Ack bit in a received Data frame if that station is the recipient of the Data frame, regardless of the value of this MIB variable." DEFVAL { false } ::= { dot11StationConfigEntry 35 } 2790 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11QBSSLoadImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute is available only at an AP. This attribute, when true, indicates that the AP implementation is capable of generating and transmitting the BSS load element in the Beacon and Probe Response frames. The capability is disabled, otherwise." DEFVAL { false } ::= { dot11StationConfigEntry 36 } dot11QueueRequestOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute is available only at an AP. This attribute, when true, indicates that the AP is capable of processing the Queue Size field in QoS Control field of QoS Data type frames. The capability is disabled, otherwise." DEFVAL { false } ::= { dot11StationConfigEntry 37 } dot11TXOPRequestOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute is available only at an AP. This attribute, when true, indicates that the AP is capable of processing the TXOP Duration requested field in QoS Control field of QoS Data type frames. The capability is disabled, otherwise." DEFVAL { false } ::= { dot11StationConfigEntry 38 } dot11MoreDataAckOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of interpreting the More Data bit in the Ack frames. The capability is disabled, otherwise." DEFVAL { false } ::= { dot11StationConfigEntry 39 } dot11AssociateInNQBSS OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION 2791 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that the station may associate in a non-QoS BSS. When false, this attribute indicates that the station does not associate in a non-QoS BSS." DEFVAL { true } ::= { dot11StationConfigEntry 40 } dot11DLSAllowedInQBSS OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute available at the AP, when true, indicates that STAs may set up DLS and communicate using DLS with other STAs in the BSS. When false, this attribute indicates that the stations do not set up DLS nor communicate with other STAs using DLS in the BSS." DEFVAL { true } ::= { dot11StationConfigEntry 41 } dot11DLSAllowed OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute available at non-AP STAs, when true, indicates that the STA may set up DLS or accept DLS Requests, and communicate with other STAs in the BSS using DLS. When false, this attribute indicates that the STA does not set up DLS nor accept DLS, nor communicate with other STAs in the BSS using DLS." DEFVAL { true } ::= { dot11StationConfigEntry 42} dot11AssociateStation OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a STA associates. This attribute indicates the MAC address from the Address 1 field of the most recently transmitted Association Response frame. If no Association Response frame has been transmitted, the value of this attribute is 0." ::= { dot11StationConfigEntry 43 } dot11AssociateID OBJECT-TYPE SYNTAX Unsigned32(0..2007) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a STA associates. 2792 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This attribute indicates the Association ID from the most recently transmitted Association Response frame. If no Association Response frame has been transmitted, the value of this attribute is 0." ::= { dot11StationConfigEntry 44 } dot11AssociateFailStation OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a STA fails to associate. This attribute indicates the MAC address from the Address 1 field of the most recently transmitted failed Association Response frame. If no failed Association Response frame has been transmitted, the value of this attribute is 0." ::= { dot11StationConfigEntry 45 } dot11AssociateFailStatus OBJECT-TYPE SYNTAX Unsigned32(0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a STA fails to associate. This attribute indicates the most recently transmitted Status Code in a failed Association Response frame. If no failed Association Response frame has been transmitted, the value of this attribute is 0." ::= { dot11StationConfigEntry 46 } dot11ReassociateStation OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a STA reassociates. This attribute indicates the MAC address from the Address 1 field of the most recently transmitted Reassociation Response frame. If no Reassociation Response frame has been transmitted, the value of this attribute is 0." ::= { dot11StationConfigEntry 47 } dot11ReassociateID OBJECT-TYPE SYNTAX Unsigned32(0..2007) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a STA reassociates. This attribute indicates the Association ID from the most recently transmitted Reassociation Response frame. If no Reassociation Response frame has been transmitted, the value of this attribute is 0." ::= { dot11StationConfigEntry 48 } dot11ReassociateFailStation OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION 2793 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications "This is a status variable. It is written by the MAC when a STA fails to reassociate. This attribute indicates the MAC address from the Address 1 field of the most recently transmitted failed Reassociation Response frame. If no failed Reassociation Response frame has been transmitted, the value of this attribute is 0." ::= { dot11StationConfigEntry 49 } dot11ReassociateFailStatus OBJECT-TYPE SYNTAX Unsigned32(0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a STA fails to reassociate. This attribute indicates the most recently transmitted Status Code in a failed Reassociation Response frame. If no failed Reassociation Response frame has been transmitted, the value of this attribute is 0." ::= { dot11StationConfigEntry 50 } dot11RadioMeasurementImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of supporting Radio Measurement. Otherwise it is not capable of performing Radio Measurement." DEFVAL { false } ::= { dot11StationConfigEntry 51 } dot11RadioMeasurementActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when any of the MIB variables listed in 9.4.2.45 is equal to true. Changes take effect with the next MLME-START.request primitive or MLME- JOIN.request primitive. This attribute, when true, indicates that one or more of the Radio Measurement Activated Capabilities MIB attributes, listed in 9.4.2.45, are equal to true. A STA may use the defined Radio Measurement procedures if this attribute is true." DEFVAL { false } ::= { dot11StationConfigEntry 52 } dot11RMMeasurementNavSync OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. The value of ProbeDelay to be used when making a beacon type measurement 2794 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications with measurement mode active." ::= { dot11StationConfigEntry 53 } dot11RMMeasurementPilotPeriod OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the number of TUs that a station uses for scheduling Measurement Pilot frame transmissions. This value is transmitted in Measurement Pilot frames. The default period is 25% of dot11BeaconPeriod." ::= { dot11StationConfigEntry 54 } dot11RMLinkMeasurementActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect for the next MLME-START.request primitive or MLME- JOIN.request primitive. This attribute, when true, indicates that dot11RadioMeasurementActivated is true and that the station capability for Link Measurement is enabled. A value of false indicates the station has no Link Measurement capability or that the capability is present but is disabled." DEFVAL { false } ::= { dot11StationConfigEntry 55 } dot11RMNeighborReportActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that dot11RadioMeasurementActivated is true and that the station capability for neighbor report is enabled. false indicates the station has no neighbor report capability or that the capability is present but is disabled." DEFVAL { false } ::= { dot11StationConfigEntry 56 } dot11RMParallelMeasurementsActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect for the next MLME-START.request primitive or MLME- JOIN.request primitive. This attribute, when true, indicates that dot11RadioMeasurementActivated is true and that the station capability for Parallel Measurements is enabled. false indicates the station has no Parallel Measurements 2795 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications capability or that the capability is present but is disabled." DEFVAL { false } ::= { dot11StationConfigEntry 57 } dot11RMRepeatedMeasurementsActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect for the next MLME-START.request primitive or MLME- JOIN.request primitive. This attribute, when true, indicates that dot11RadioMeasurementActivated is true and that the station capability for Repeated Measurements is enabled. false indicates the station has no Repeated Measurements capability or that the capability is present but is disabled." DEFVAL { false } ::= { dot11StationConfigEntry 58 } dot11RMBeaconPassiveMeasurementActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect for the next MLME-START.request primitive or MLME- JOIN.request primitive. This attribute, when true, indicates that dot11RadioMeasurementActivated is true and that the station capability for Beacon Passive Measurement is enabled. false indicates the station has no Beacon Passive Measurement capability or that the capability is present but is disabled." DEFVAL { false } ::= { dot11StationConfigEntry 59 } dot11RMBeaconActiveMeasurementActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect for the next MLME-START.request primitive or MLME- JOIN.request primitive. This attribute, when true, indicates that dot11RadioMeasurementActivated is true and that the station capability for Beacon Active Measurement is enabled. false indicates the station has no Beacon Active Measurement capability or that the capability is present but is disabled." DEFVAL { false } ::= { dot11StationConfigEntry 60 } dot11RMBeaconTableMeasurementActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect for the next MLME-START.request primitive or MLME- JOIN.request primitive. 2796 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This attribute, when true, indicates that dot11RadioMeasurementActivated is true and that the station capability for Beacon Table Measurement is enabled. false indicates the station has no Beacon Table Measurement capability or that the capability is present but is disabled." DEFVAL { false } ::= { dot11StationConfigEntry 61 } dot11RMBeaconMeasurementReportingConditionsActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect for the next MLME-START.request primitive or MLME- JOIN.request primitive. This attribute, when true, indicates that dot11RadioMeasurementActivated is true and that the station capability for Beacon Measurement Reporting Conditions is enabled. false indicates the station has no Beacon Measurement Reporting Conditions capability or that the capability is present but is disabled." DEFVAL { false } ::= { dot11StationConfigEntry 62 } dot11RMFrameMeasurementActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect for the next MLME-START.request primitive or MLME- JOIN.request primitive. This attribute, when true, indicates that dot11RadioMeasurementActivated is true and that the station capability for Frame Measurement is enabled. false indicates the station has no Frame Measurement capability or that the capability is present but is disabled." DEFVAL { false } ::= { dot11StationConfigEntry 63 } dot11RMChannelLoadMeasurementActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect for the next MLME-START.request primitive or MLME- JOIN.request primitive. This attribute, when true, indicates that dot11RadioMeasurementActivated is true and that the station capability for Channel Load Measurement is enabled. false indicates the station has no Channel Load Measurement capability or that the capability is present but is disabled." DEFVAL { false } ::= { dot11StationConfigEntry 64 } dot11RMNoiseHistogramMeasurementActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current 2797 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect for the next MLME-START.request primitive or MLME- JOIN.request primitive. This attribute, when true, indicates that dot11RadioMeasurementActivated is true and that the station capability for Noise Histogram Measurement is enabled. false indicates the station has no Noise Histogram Measurement capability or that the capability is present but is disabled." DEFVAL { false } ::= { dot11StationConfigEntry 65 } dot11RMStatisticsMeasurementActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that dot11RadioMeasurementActivated is true and that the station capability for Statistics Measurement is enabled. false indicates the station has no Statistics Measurement capability or that the capability is present but is disabled." DEFVAL { false } ::= { dot11StationConfigEntry 66 } dot11RMLCIMeasurementActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect for the next MLME-START.request primitive or MLME- JOIN.request primitive. This attribute, when true, indicates that dot11RadioMeasurementActivated is true and that the station capability for LCI Measurement is enabled. false indicates the station has no LCI Measurement capability or that the capability is present but is disabled." DEFVAL { false } ::= { dot11StationConfigEntry 67 } dot11RMLCIAzimuthActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect for the next MLME-START.request primitive or MLME- JOIN.request primitive. This attribute, when true, indicates that dot11RadioMeasurementActivated is true and that the station capability for LCI Azimuth Measurement is enabled. false indicates the station has no LCI Azimuth Measurement capability or that the capability is present but is disabled." DEFVAL { false } ::= { dot11StationConfigEntry 68 } dot11RMTransmitStreamCategoryMeasurementActivated OBJECT-TYPE 2798 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that dot11RadioMeasurementActivated is true and that the station capability for Transmit Stream/Category Measurement is enabled. false indicates the station has no Transmit Stream/Category Measurement capability or that the capability is present but is disabled." DEFVAL { false } ::= { dot11StationConfigEntry 69 } dot11RMTriggeredTransmitStreamCategoryMeasurementActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that dot11RadioMeasurementActivated is true and that the station capability for Triggered Transmit Stream/ Category Measurement is enabled. false indicates the station has no Triggered Transmit Stream/Category Measurement capability or that the capability is present but is disabled." DEFVAL { false } ::= { dot11StationConfigEntry 70 } dot11RMAPChannelReportActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect for the next MLME-START.request primitive or MLME- JOIN.request primitive. This attribute, when true, indicates that dot11RadioMeasurementActivated is true and that the station capability for AP Channel Report is enabled. false indicates the station has no AP Channel Report capability or that the capability is present but is disabled." DEFVAL { false } ::= { dot11StationConfigEntry 71 } dot11RMMIBActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that dot11RadioMeasurementActivated is true and that the station capability for RM MIB is enabled. false indicates the station has no RM MIB capability or that the capability is present but is disabled. See RM MIB details." DEFVAL { false } 2799 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ::= { dot11StationConfigEntry 72 } dot11RMMaxMeasurementDuration OBJECT-TYPE SYNTAX Unsigned32(0 .. 7) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute indicates the maximum measurement duration for operating channel measurements, where Max Measurement Duration in TUs = (2 ** (dot11RMMaxMeasurementDuration - 4)) * BeaconInterval Further details are provided in 11.11.4" ::= { dot11StationConfigEntry 73 } dot11RMNonOperatingChannelMaxMeasurementDuration OBJECT-TYPE SYNTAX Unsigned32(0 .. 7) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect for the next MLME-START.request primitive or MLME- JOIN.request primitive. This attribute indicates the maximum measurement duration for nonoperating channel measurements, where Non-OpMax Measurement Duration in TUs = (2 ** (dot11RMNonOperatingChannelMaxMeasurementDuration - 4)) * BeaconInterval Further details are provided in 11.11.4" ::= { dot11StationConfigEntry 74 } dot11RMMeasurementPilotTransmissionInformationActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that dot11RadioMeasurementActivated is true and that the station capability for Measurement Pilot Transmission information is enabled. false indicates the station has no Measurement Pilot Transmission information capability or that the capability is present but is disabled." DEFVAL { false } ::= { dot11StationConfigEntry 75 } dot11RMMeasurementPilotActivated OBJECT-TYPE SYNTAX Unsigned32(0 .. 7) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. 2800 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This attribute indicates the station capability for Measurement Pilot. The value 0 indicates the station has no Measurement Pilot capability or that the capability is present but is disabled. Activated values 1-7 are defined in Table 11-10." DEFVAL { 0 } ::= { dot11StationConfigEntry 76 } dot11RMNeighborReportTSFOffsetActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that dot11RadioMeasurementActivated is true and that the station capability for Neighbor Report TSF Offset is enabled. false indicates the station has no Neighbor Report TSF Offset capability or that the capability is present but is disabled." DEFVAL { false } ::= { dot11StationConfigEntry 77 } dot11RMRCPIMeasurementActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect for the next MLME-START.request primitive or MLME- JOIN.request primitive. This attribute, when true, indicates that dot11RadioMeasurementActivated is true and that the station capability for RCPI Measurement is enabled. false indicates the station has no RCPI Measurement capability or that the capability is present but is disabled." DEFVAL { false } ::= { dot11StationConfigEntry 78 } dot11RMRSNIMeasurementActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that dot11RadioMeasurementActivated is true and that the station capability for RSNI Measurement is enabled. false indicates the station has no RSNI Measurement capability or that the capability is present but is disabled." DEFVAL { false } ::= { dot11StationConfigEntry 79 } dot11RMBSSAverageAccessDelayActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. 2801 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Changes take effect for the next MLME-START.request primitive or MLME- JOIN.request primitive. This attribute, when true, indicates that dot11RadioMeasurementActivated is true and that the station capability for BSS Average Access Delay is enabled. false indicates the station has no BSS Average Access Delay capability or that the capability is present but is disabled." DEFVAL { false } ::= { dot11StationConfigEntry 80 } dot11RMBSSAvailableAdmissionCapacityActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect for the next MLME-START.request primitive or MLME- JOIN.request primitive. This attribute, when true, indicates that dot11RadioMeasurementActivated is true and that the station capability for BSS Available Admission Capacity is enabled. false indicates the station has no BSS Available Admission Capacity capability or that the capability is present but is disabled." DEFVAL { false } ::= { dot11StationConfigEntry 81 } dot11RMAntennaInformationActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect for the next MLME-START.request primitive or MLME- JOIN.request primitive. This attribute, when true, indicates that dot11RadioMeasurementActivated is true and that the station capability for Antenna information is enabled. false indicates the station has no Antenna information capability or that the capability is present but is disabled." DEFVAL { false } ::= { dot11StationConfigEntry 82 } dot11FastBSSTransitionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This object indicates if the entity is fast BSS transition capable." ::= { dot11StationConfigEntry 83 } dot11LCIDSEImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. 2802 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This attribute, when true, indicates that the station implementation is capable of supporting LCI DSE. The capability is disabled, otherwise." DEFVAL { false } ::= { dot11StationConfigEntry 84 } dot11LCIDSERequired OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME. A STA uses the Dependent Station Enablement procedures if this attribute is true." DEFVAL { false } ::= { dot11StationConfigEntry 85 } dot11DSERequired OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME. This attribute, when true, indicates that the station operation is dependent on enablement from enabling STAs. This attribute, when false, indicates that the station operation does not depend on enablement from STAs." DEFVAL { false } ::= { dot11StationConfigEntry 86 } dot11ExtendedChannelSwitchActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME when the device is initialized for operation in a band defined by an Operating Class. This attribute, when true, indicates that the station implementation is capable of supporting Extended Channel Switch Announcement. The capability is disabled, otherwise." DEFVAL { false } ::= { dot11StationConfigEntry 87 } --********************************************************** --* Management frame protection MIBs --********************************************************** dot11RSNAProtectedManagementFramesActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This variable indicates whether this STA enables management frame protection." DEFVAL { false } ::= { dot11StationConfigEntry 88} 2803 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11RSNAUnprotectedManagementFramesAllowed OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This variable indicates whether this STA supports RSNA STAs which do not provide robust management frames protection." DEFVAL { true } ::= { dot11StationConfigEntry 89} --********************************************************** --* SA Query Procedure MIBs --********************************************************** dot11AssociationSAQueryMaximumTimeout OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the number of TUs that an AP can wait, from the scheduling of the first SA Query Request to allow association process to be started without starting additional SA Query procedure if a successful SA Query Response is not received." DEFVAL { 1000 } ::= { dot11StationConfigEntry 90} dot11AssociationSAQueryRetryTimeout OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the number of TUs that an AP waits between issuing two subsequent MLME-SA-QUERY.request primitive primitives." DEFVAL { 201 } ::= { dot11StationConfigEntry 91} dot11HighThroughputOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates whether the entity is HT Capable." ::= { dot11StationConfigEntry 92} dot11RSNAPBACRequired OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION 2804 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This variable indicates whether this STA requires the Protection of block ack agreements." DEFVAL { false } ::= { dot11StationConfigEntry 93} dot11PSMPOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of supporting PSMP." DEFVAL { false } ::= { dot11StationConfigEntry 94 } dot11TunneledDirectLinkSetupImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute, when true, indicates that the STA implementation is capable of supporting Tunneled DirectLink Setup." DEFVAL { false } ::= { dot11StationConfigEntry 95 } dot11TDLSPeerUAPSDBufferSTAActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute, when true, indicates that the STA implementation is capable of supporting TPU." DEFVAL { false } ::= { dot11StationConfigEntry 96 } dot11TDLSPeerPSMActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute, when true, indicates that the STA implementation is capable of supporting TDLS peer PSM." DEFVAL { false } ::= { dot11StationConfigEntry 97 } dot11TDLSPeerUAPSDIndicationWindow OBJECT-TYPE SYNTAX Unsigned32 (1..256) MAX-ACCESS read-write STATUS current DESCRIPTION "This attribute indicates the minimum interval in Beacon Intervals between successive Peer Traffic Indication frames." DEFVAL { 1 } ::= { dot11StationConfigEntry 98 } dot11TDLSChannelSwitchingActivated OBJECT-TYPE SYNTAX TruthValue 2805 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute, when true, indicates that the STA implementation is capable of supporting TDLS Channel Switching." DEFVAL { false } ::= { dot11StationConfigEntry 99 } dot11TDLSPeerSTAMissingAckRetryLimit OBJECT-TYPE SYNTAX Unsigned32 (1..100) MAX-ACCESS read-write STATUS current DESCRIPTION "This attribute indicates the number of times the TDLS STA may retry a frame for which it does not receive an Ack frame from TDLS peer STA in power save mode after the TDLS peer STA does not receive an Ack frame to an individually addressed MPDU sent with the EOSP subfield equal to 1 or to an individually addressed MPDU that initiated a channel switch." DEFVAL { 3 } ::= { dot11StationConfigEntry 100 } dot11TDLSResponseTimeout OBJECT-TYPE SYNTAX Unsigned32 (1..255) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This attribute indicates the amount of time the STA waits before timing out a TDLS setup request." DEFVAL { 5 } ::= { dot11StationConfigEntry 101 } dot11OCBActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "A STA uses the defined outside the context of a BSS procedures if and only if this attribute is true. The default value of this attribute is false." DEFVAL { false } ::= { dot11StationConfigEntry 102 } dot11TDLSNavSync OBJECT-TYPE SYNTAX Unsigned32 (1..65535) UNITS "microseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This attribute indicates the amount of time the STA waits before transmitting on a new channel, in the absence of traffic on the channel that causes a CCA state to be created." DEFVAL { 1000 } ::= { dot11StationConfigEntry 103 } dot11TDLSDiscoveryRequestWindow OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-write STATUS current DESCRIPTION "This attribute indicates the minimum number of DTIM intervals between successive TDLS Discovery Request frames." DEFVAL { 2 } ::= { dot11StationConfigEntry 104 } 2806 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11TDLSACDeterminationInterval OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-write STATUS current DESCRIPTION "This attribute indicates the number of seconds during which the lowest AC of transmitted traffic is determined." DEFVAL { 1 } ::= { dot11StationConfigEntry 105 } dot11WirelessManagementImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of supporting one or more wireless network management services." ::= { dot11StationConfigEntry 106} dot11BssMaxIdlePeriod OBJECT-TYPE SYNTAX Unsigned32 (1..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute indicates that the number of 1000 TUs that pass before an AP disassociates an inactive non-AP STA. This value is transmitted in the Association Response and Reassociation Response frames." ::= { dot11StationConfigEntry 107} dot11BssMaxIdlePeriodOptions OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute indicates the options associated with the BSS max idle capability. This value is transmitted in the Association Response and Reassociation Response frames." ::= { dot11StationConfigEntry 108} dot11TIMBroadcastInterval OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute indicates the number of beacon periods between TIM frame transmissions. A value of 0 disables TIM Broadcast for the requesting sta- tion." DEFVAL { 0 } 2807 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ::= { dot11StationConfigEntry 109} dot11TIMBroadcastOffset OBJECT-TYPE SYNTAX Integer32 (-214748364..214748363) UNITS "microseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute indicates the offset with a tolerance of +/- 4 microseconds relative to the TBTT for which a TIM frame is scheduled for transmission." DEFVAL { 0 } ::= { dot11StationConfigEntry 110} dot11TIMBroadcastHighRateTIMRate OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "0.5 Mb/s" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute indicates the rate used to transmit the high data rate TIM frame. A value of 0 indicates that the high rate TIM frame is not transmitted." DEFVAL { 0 } ::= { dot11StationConfigEntry 111} dot11TIMBroadcastLowRateTIMRate OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "0.5 Mb/s" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute indicates the rate used to transmit the low data rate TIM frame. A value of 0 indicates that the low rate TIM frame is not transmitted." DEFVAL { 0 } ::= { dot11StationConfigEntry 112} dot11StatsMinTriggerTimeout OBJECT-TYPE SYNTAX Unsigned32 (10..7200) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute indicates the minimum allowable value for Triggered Timeout. A Triggered STA Statistics report is generated by the STA after the timeout if none of the trigger conditions are satisfied." DEFVAL { 10 } ::= { dot11StationConfigEntry 113 } 2808 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11RMCivicMeasurementActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that dot11RadioMeasurementActivated is true and that the station capability for Location Civic Measurement is enabled. false indicates the station has no Location Civic Measurement capability or that the capability is present but is disabled." DEFVAL { false } ::= { dot11StationConfigEntry 114 } dot11RMIdentifierMeasurementActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that dot11RadioMeasurementActivated is true and that the station capability for location identifier measurement is enabled. false indicates the station has no Location Identifier Measurement capability or that the capability is present but is disabled." DEFVAL { false } ::= { dot11StationConfigEntry 115 } dot11TimeAdvertisementDTIMInterval OBJECT-TYPE SYNTAX Unsigned32 (1..255) UNITS "dtims" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute indicates the interval in number of DTIMS when the Time Advertisement element is included in Beacon frames." DEFVAL { 1 } ::= { dot11StationConfigEntry 116 } dot11InterworkingServiceImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute when true, indicates the STA is capable of interworking with external networks. A STA setting this to true implements Interworking Service. When this is false, the STA does not implement Interworking Service." DEFVAL {false} ::= { dot11StationConfigEntry 117 } 2809 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11InterworkingServiceActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute when true, indicates the capability of the STA to interwork with external networks is enabled. The capability is disabled otherwise." DEFVAL {false} ::= { dot11StationConfigEntry 118 } dot11QosMapImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute available at STAs, when true, indicates the STA is capable of supporting the QoS Map procedures. When this is false, the STA does not implement QoS Map procedures." DEFVAL {false} ::= { dot11StationConfigEntry 119 } dot11QosMapActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates the capability of the STA to support QoS Map procedures is enabled. The capability is disabled otherwise." DEFVAL {false} ::= { dot11StationConfigEntry 120 } dot11EBRImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute available at STAs, when true, indicates the STA is capable of supporting Expedited Bandwidth Request procedures. When this is false, the STA does not implement Expedited Bandwidth Request procedures." DEFVAL {false} ::= { dot11StationConfigEntry 121 } dot11EBRActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write 2810 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates the capability of the STA to support Expedited Bandwidth Request procedures is enabled. The capability is disabled otherwise." DEFVAL {false} ::= { dot11StationConfigEntry 122 } dot11ESNetwork OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. The emergency services access network type equal to true indicates that the BSS is used exclusively for the purposes of accessing emergency services. This object is not used by non-AP STAs." ::= { dot11StationConfigEntry 123 } dot11SSPNInterfaceImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute when true, indicates the AP is capable of SSPN Interface service. When this is false, the STA does not implement SSPN Interface Service. This object is not used by non-AP STAs. The default value of this attribute is false." DEFVAL {false} ::= { dot11StationConfigEntry 124 } dot11SSPNInterfaceActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates the capability of the AP to provide SSPN Interface service is enabled. The capability is disabled, otherwise. The default value of this attribute is false." DEFVAL {false} ::= { dot11StationConfigEntry 125 } dot11HESSID OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-write STATUS current 2811 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect for the next MLME-START.request primitive. This attribute is used by an AP and is the 6-octet homogeneous ESS identifier field, whose value is set to one of the BSSIDs in the ESS. It is required that the same value of HESSID be used for all BSSs in the homogeneous ESS." ::= { dot11StationConfigEntry 126 } dot11EASImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute when true, indicates the STA is capable of emergency alert system notification with external networks. A STA setting this to true implements emergency alert system notification. When this is false, the STA does not implement emergency alert system notification." DEFVAL {false} ::= { dot11StationConfigEntry 127 } dot11EASActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute when true, indicates the STA is capable of supporting emergency alert system. The capability is disabled otherwise." DEFVAL {false} ::= { dot11StationConfigEntry 128 } dot11MSGCFImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute when true, indicates the non-AP STA is capable of supporting the MSGCF procedures defined in 6.4. When false, the non-AP STA does not implement MSGCF procedures. This object is not used by APs. The default value of this attribute is false." DEFVAL {false} ::= { dot11StationConfigEntry 129 } dot11MSGCFActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION 2812 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates the capability of the non-AP STA to provide the MSGCF is enabled. The capability is disabled, otherwise. The default value of this attribute is false." DEFVAL {false} ::= { dot11StationConfigEntry 130 } dot11TimeAdvertisementTimeError OBJECT-TYPE SYNTAX OCTET STRING (SIZE(5)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute indicates the Time Error value as defined in the Time Advertisement element Time Error field when the Time Capabilities field is set to 2. This field is included in the Time Advertisement element in Beacon and Probe Response frames." DEFVAL { ''H } ::= { dot11StationConfigEntry 131 } dot11TimeAdvertisementTimeValue OBJECT-TYPE SYNTAX OCTET STRING (SIZE(10)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute indicates the TimeAdvertisement Time Value as defined in the Time Advertisement element Time Value field when the Time Capabilities field is set to 2. The format is defined in Table 9-170 and is included in the Time Advertisement element in Beacon and Probe Response frames." ::= { dot11StationConfigEntry 132 } dot11RM3rdPartyMeasurementActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that dot11RadioMeasurementActivated is true and that the station capability for Third Party Location Measurement is enabled. false indicates the station has no Third Party Location Measurement capability or that the capability is present but is disabled." DEFVAL { false } ::= { dot11StationConfigEntry 133 } dot11RejectUnadmittedTraffic OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION 2813 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications "This is a control variable. It is written by an external management entity. Changes take effect at the next MLME-START.request primitive or MLME- JOIN.request primitive. This attribute when true indicates the STA's MA-UNITDATA primitive rejects frames whose requested priority corresponds to an AC for which admission control is mandatory and for which there is not an admitted TSPEC." DEFVAL { false } ::= {dot11StationConfigEntry 134} dot11BSSBroadcastNullCount OBJECT-TYPE SYNTAX Unsigned32 (1..64) MAX-ACCESS read-write STATUS deprecated DESCRIPTION "Deprecated because this variable is not referenced in the standard. This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the number of group addressed (QoS) Null frames an IBSS STA transmits before it changes power management modes." DEFVAL { 3 } ::= {dot11StationConfigEntry 135} dot11MeshActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. When this object is true, this indicates that the STA is a mesh STA. Configuration variables for mesh operation are found in the dot11MeshSTAConfigTable." ::= { dot11StationConfigEntry 136 } dot11QMFActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or external management entity. In an AP changes take effect for the next MLME-START.request primitive. In a non-AP STA that is not associated and is not a member of an IBSS, changes take effect as soon as practical in the implementation. In a non- AP STA that is associated, changes take effect at the end of the lifetime of the association. For a STA that is a member of an IBSS, changes take effect for the next MLME-START.request primitive or MLME-JOIN.request primitive. This attribute indicates whether the entity is QMF enabled or disabled." DEFVAL { false } ::= { dot11StationConfigEntry 137 } dot11QMFReconfigurationActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. 2814 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications It is written by the SME or external management entity. Changes take effect for the next MLME-START.request primitive or MLME- JOIN.request primitive. The purpose of dot11QMFReconfigurationActivated is to allow an SME to accept a QMF Policy Change request from another STA and respond with a QMF Policy frame." DEFVAL { false } ::= { dot11StationConfigEntry 138 } dot11QMFPolicyChangeTimeout OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or external management entity. Changes take effect as soon as practical in the implementation. This attribute indicates the minimum number of TUs that a STA waits to receive a response to a QMF Policy Change request before declaring that the request has failed and also the number of TUs that a STA waits after it has received a rejection to a QMF Policy Change request before issuing a repeat QMF Policy Change request to the same destination STA." DEFVAL { 5000 } ::= { dot11StationConfigEntry 139 } dot11RobustAVStreamingImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation supports robust AV streaming." DEFVAL { false } ::= { dot11StationConfigEntry 140 } dot11VHTOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates whether the entity is VHT Capable." ::= { dot11StationConfigEntry 141} dot11OperatingModeNotificationImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates whether the entity is Operating Mode Notification Capable." ::= { dot11StationConfigEntry 142} dot11TVHTOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only 2815 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates whether the entity is TVHT Capable." ::= { dot11StationConfigEntry 143} dot11MultibandImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. Multiband Support Activated This attribute, when true, indicates that the STA is capable of operating in multiple bands. Otherwise, it is false. The default value of this attribute is false." DEFVAL { false } ::= { dot11StationConfigEntry 144 } dot11ChannelScheduleManagementActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when the device is initialized for operation in a band defined by an Operating Class. This attribute, when true, indicates that the STA implementation is capable of supporting Channel Schedule Management Announcement. The capability is disabled, otherwise." DEFVAL { false } ::= { dot11StationConfigEntry 145 } dot11ContactVerificationSignalActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect for the next MLME-START.request primitive primitive. This attribute, when true, indicates that the system capability for contact verification signal is activated. false indicates that the STA has contact verification signal capability, but it is disabled." DEFVAL { false } ::= { dot11StationConfigEntry 146 } dot11ContactVerificationSignalInterval OBJECT-TYPE SYNTAX Unsigned32(1..255) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. dot11ContactVerificationSignalInterval indicates the maximum number of seconds that a GDD dependent STA may receive the Contact Verification Signal frame. Unless another value is mandated by regulatory authorities, 2816 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications the value is 60 seconds." DEFVAL { 60 } ::= { dot11StationConfigEntry 147 } dot11NetworkChannelControlActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when the device is initialized for operation in a band defined by an Operating Class. This attribute, when true, indicates that the STA implementation is capable of supporting network channel control. The capability is disabled, otherwise." DEFVAL { false } ::= { dot11StationConfigEntry 148 } dot11RLSSActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or an external management entity. Changes take effect as soon as possible in the device. This attribute, when true, indicates that the RLQP capability is activated. The capability is disabled, otherwise." DEFVAL { false } ::= { dot11StationConfigEntry 149 } dot11WhiteSpaceMapActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect for the next MLME-START.request primitive or MLME-JOIN.request primitive. This attribute, when true, indicates that the STA capability for white space map is activated. false indicates the STA has no white space map capability or that the capability is present but is disabled." DEFVAL { false } ::= { dot11StationConfigEntry 150 } dot11WSSTAType OBJECT-TYPE SYNTAX INTEGER {gddap(1), gddnonapsta(2), gddfixedsta(3), reserved(4)} MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when the device is initialized for operation in a band that requires Geolocation Database Control. This attribute specifies the type of STA mode for the purpose of channel availability query requirements. This value is used to set the desired channel availability query request parameters in using GAS frames carrying Channel Availability Query element of RLQP. When set to gddap, the STA indicates that it operates as a personal/portable AP STA after channel availability query. 2817 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications When set to gddnonapsta, the STA indicates that it operates as a personal/ portable non-AP STA after channel availability query. When set to gddfixedsta, the STA indicates that it operates as a fixed STA after channel availability query. When set to any other values, its use is reserved, and remains unspecified." ::= { dot11StationConfigEntry 151} dot11GeolocationCapabilityActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that the has obtained its device location information in geospatial coordinates for its position using its geolocation capability, as required for its device class, otherwise this is false." DEFVAL { false } ::= { dot11StationConfigEntry 152 } dot11GDDActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when the device is initialized for operation in a band that requires Geolocation Database Dependent behavior. This attribute, when true, indicates that the STA capability for operation with Geolocation Database Dependent behavior is activated. The capability is disabled, otherwise." DEFVAL { false } ::= { dot11StationConfigEntry 153 } dot11GDDEnablementTimeLimit OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when the device is initialized. Changes take effect as soon as practical in the implementation. dot11GDDEnablementTimeLimit indicates the maximum number of seconds that a GDD dependent STA may transmit in a frequency band under the control of a geolocation database while attaining GDD enablement with a GDD enabling STA. Unless another value is mandated by regulatory authorities, the value is 32 seconds." DEFVAL { 32 } ::= { dot11StationConfigEntry 155 } dot11GDDEnablementFailHoldTime OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when the device is initialized. Changes take effect as soon as practical in the implementation. 2818 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11GDDEnablementFailHoldTime indicates the number of seconds that a GDD dependent STA shall not transmit in a frequency band under control of a geolocation database when it fails to attain GDD enablement with an GDD enabling STA within dot11GDDEnablementTimeLimit seconds. Unless another value is mandated by regulatory authorities, the value is 512 seconds." DEFVAL { 512 } ::= { dot11StationConfigEntry 156 } dot11GDDEnablementValidityTimer OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when the device is initialized. Changes take effect as soon as practical in the implementation. dot11GDDEnablementValidityTimer indicates the number of seconds that a GDD dependent STA remains in GDDEnabled state. Unless another value is mandated by regulatory authorities, the value is 60 seconds." DEFVAL { 60 } ::= { dot11StationConfigEntry 157 } dot11MaxMSDULength OBJECT-TYPE SYNTAX INTEGER { normal(2304), long(7920) } UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates the maximum supported MSDU size. This is 7920 octets for a DMG STA and 2304 octets for a non-DMG STA." ::= { dot11StationConfigEntry 162 } dot11DynamicEIFSActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect for the next MLME-START.request primitive or MLME- JOIN.request primitive. This attribute indicates whether the entity uses a dynamic value for EIFS based on properties of the PPDU that causes the EIFS, or a fixed value." ::= { dot11StationConfigEntry 158 } dot11ExtendedSpectrumManagementImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the non-VHT station implementation is capable of supporting extended spectrum management. The capability is disabled at the non-VHT station otherwise." DEFVAL { false } ::= { dot11StationConfigEntry 161 } 2819 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11EstimatedServiceParametersOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the IEEE 802.11 Estimated Service Parameters option is implemented." DEFVAL { false } ::= { dot11StationConfigEntry 163 } dot11VHTExtendedNSSBWCapable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the VHT extended NSS BW support option is implemented. dot11VHTExtendedNSSBWCapable might be false when dot11VHTOptionImplemented is false." DEFVAL { false } ::= { dot11StationConfigEntry 165 } dot11FutureChannelGuidanceActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates the capability of the STA to support Future channel guidance procedures is enabled. The capability is disabled otherwise." DEFVAL {false} ::= { dot11StationConfigEntry 166 } -- ********************************************************************** -- * End of dot11StationConfig TABLE -- ********************************************************************** -- ********************************************************************** -- * dot11AuthenticationAlgorithms TABLE -- ********************************************************************** dot11AuthenticationAlgorithmsTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11AuthenticationAlgorithmsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This (conceptual) table of attributes is a set of all of the authentication algorithms and whether they are activated." REFERENCE "IEEE Std 802.11-2016, 9.4.1.1" ::= { dot11smt 2 } dot11AuthenticationAlgorithmsEntry OBJECT-TYPE SYNTAX Dot11AuthenticationAlgorithmsEntry MAX-ACCESS not-accessible STATUS current 2820 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DESCRIPTION "An Entry (conceptual row) in the Authentication Algorithms Table. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX { ifIndex, dot11AuthenticationAlgorithmIndex} ::= { dot11AuthenticationAlgorithmsTable 1 } Dot11AuthenticationAlgorithmsEntry ::= SEQUENCE { dot11AuthenticationAlgorithmIndex Unsigned32, dot11AuthenticationAlgorithm INTEGER, dot11AuthenticationAlgorithmActivated TruthValue } dot11AuthenticationAlgorithmIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The auxiliary variable used to identify instances of the columnar objects in the Authentication Algorithms Table." ::= { dot11AuthenticationAlgorithmsEntry 1 } dot11AuthenticationAlgorithm OBJECT-TYPE SYNTAX INTEGER { openSystem(1), sharedKey(2), fastBSSTransition(3), simultaneousAuthEquals(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute is the authentication algorithm described by this entry in the table. The following values can be used here Value = 1: Open system Value = 2: Shared key Value = 3: Fast BSS transition (FT) Value = 4: Simultaneous authentication of equals (SAE) A given value shall not be used more than once." ::= { dot11AuthenticationAlgorithmsEntry 2 } dot11AuthenticationAlgorithmActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute, when true, enables the acceptance of the authentication algorithm described in the corresponding table entry in authentication frames received that have odd authentication transactions sequence numbers. The default value of this attribute is true when the value of dot11AuthenticationAlgorithm is openSystem and false otherwise." ::= { dot11AuthenticationAlgorithmsEntry 3 } -- ********************************************************************** -- * End of dot11AuthenticationAlgorithms TABLE 2821 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications -- ********************************************************************** -- ********************************************************************** -- * dot11WEPDefaultKeys TABLE -- ********************************************************************** dot11WEPDefaultKeysTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11WEPDefaultKeysEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Conceptual table for WEP default keys. This table contains the four WEP default secret key values corresponding to the four possible Key ID values. The WEP default secret keys are logically WRITE-ONLY. Attempts to read the entries in this table return unsuccessful status and values of null or 0. The default value of each WEP default key is null." REFERENCE "IEEE Std 802.11-2016, 12.3.2" ::= { dot11smt 3 } dot11WEPDefaultKeysEntry OBJECT-TYPE SYNTAX Dot11WEPDefaultKeysEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An Entry (conceptual row) in the WEP Default Keys Table. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX { ifIndex, dot11WEPDefaultKeyIndex } ::= { dot11WEPDefaultKeysTable 1 } Dot11WEPDefaultKeysEntry ::= SEQUENCE { dot11WEPDefaultKeyIndex Unsigned32, dot11WEPDefaultKeyValue WEPKeytype } dot11WEPDefaultKeyIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The auxiliary variable used to identify instances of the columnar objects in the WEP Default Keys Table. The value of this variable is equal to the WEPDefaultKeyID + 1" ::= { dot11WEPDefaultKeysEntry 1 } dot11WEPDefaultKeyValue OBJECT-TYPE SYNTAX WEPKeytype MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. A WEP default secret key value." ::= { dot11WEPDefaultKeysEntry 2 } -- ********************************************************************** -- * End of dot11WEPDefaultKeys TABLE -- ********************************************************************** -- ********************************************************************** -- * dot11WEPKeyMappings TABLE 2822 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications -- ********************************************************************** dot11WEPKeyMappingsTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11WEPKeyMappingsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Conceptual table for WEP Key Mappings. The MIB supports the ability to share a separate WEP key for each RA/TA pair. The Key Mappings Table contains zero or one entry for each MAC address and contains two fields for each entry: WEPOn and the corresponding WEP key. The WEP key mappings are logically WRITE-ONLY. Attempts to read the entries in this table return unsuccessful status and values of null or 0. The default value for all WEPOn fields is false." REFERENCE "IEEE Std 802.11-2016, 12.3.2" ::= { dot11smt 4 } dot11WEPKeyMappingsEntry OBJECT-TYPE SYNTAX Dot11WEPKeyMappingsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An Entry (conceptual row) in the WEP Key Mappings Table. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX { ifIndex, dot11WEPKeyMappingIndex } ::= { dot11WEPKeyMappingsTable 1 } Dot11WEPKeyMappingsEntry ::= SEQUENCE { dot11WEPKeyMappingIndex Unsigned32, dot11WEPKeyMappingAddress MacAddress, dot11WEPKeyMappingWEPOn TruthValue, dot11WEPKeyMappingValue WEPKeytype, dot11WEPKeyMappingStatus RowStatus } dot11WEPKeyMappingIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The auxiliary variable used to identify instances of the columnar objects in the WEP Key Mappings Table." ::= { dot11WEPKeyMappingsEntry 1 } dot11WEPKeyMappingAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The MAC address of the STA for which the values from this key mapping entry are to be used." ::= { dot11WEPKeyMappingsEntry 2 } dot11WEPKeyMappingWEPOn OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Boolean as to whether WEP is to be used when communicating with the dot11WEPKeyMappingAddress STA." ::= { dot11WEPKeyMappingsEntry 3 } 2823 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11WEPKeyMappingValue OBJECT-TYPE SYNTAX WEPKeytype MAX-ACCESS read-create STATUS current DESCRIPTION "A WEP secret key value." ::= { dot11WEPKeyMappingsEntry 4 } dot11WEPKeyMappingStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status column used for creating, modifying, and deleting instances of the columnar objects in the WEP key mapping Table." DEFVAL { active } ::= { dot11WEPKeyMappingsEntry 5 } -- ********************************************************************** -- * End of dot11WEPKeyMappings TABLE -- ********************************************************************** -- ********************************************************************** -- * dot11Privacy TABLE -- ********************************************************************** dot11PrivacyTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11PrivacyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Group containing attributes concerned with IEEE 802.11 Privacy. Created as a table to allow multiple instantiations on an agent." ::= { dot11smt 5 } dot11PrivacyEntry OBJECT-TYPE SYNTAX Dot11PrivacyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11PrivacyTable Table. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX { ifIndex } ::= { dot11PrivacyTable 1 } Dot11PrivacyEntry ::= SEQUENCE { dot11PrivacyInvoked TruthValue, dot11WEPDefaultKeyID Unsigned32, dot11WEPKeyMappingLengthImplemented Unsigned32, dot11ExcludeUnencrypted TruthValue, dot11WEPICVErrorCount Counter32, dot11WEPExcludedCount Counter32, dot11RSNAActivated TruthValue, dot11RSNAPreauthenticationActivated TruthValue } dot11PrivacyInvoked OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. 2824 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications It is written by an external management entity. Changes take effect as soon as practical in the implementation. When this attribute is true, it indicates that some level of security is invoked for transmitting Data frames. For WEP-only clients, the security mechanism used is WEP. For RSNA-capable clients, an additional variable dot11RSNAActivated indicates whether RSNA is enabled. If dot11RSNAActivated is false or the MIB variable does not exist, the security mechanism invoked is WEP; if dot11RSNAActivated is true, RSNA security mechanisms invoked are configured in the dot11RSNAConfigTable." DEFVAL { false } ::= { dot11PrivacyEntry 1 } dot11WEPDefaultKeyID OBJECT-TYPE SYNTAX Unsigned32 (0..3) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute indicates the use of the first, second, third, or fourth element of the WEPDefaultKeys array when equal to values of zero, one, two, or three." REFERENCE "IEEE Std 802.11-2016, 12.3.2" DEFVAL { 0 } ::= { dot11PrivacyEntry 2 } dot11WEPKeyMappingLengthImplemented OBJECT-TYPE SYNTAX Unsigned32 (10..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. The maximum number of tuples that dot11WEPKeyMappings can hold." REFERENCE "IEEE Std 802.11-2016, 12.3.2" ::= { dot11PrivacyEntry 3 } dot11ExcludeUnencrypted OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. When this attribute is true, the STA does not indicate at the MAC service interface received MSDUs that have the Protected Frame subfield of the Frame Control field equal to 0. When this attribute is false, the STA may accept MSDUs that have the Protected Frame subfield of the Frame Control field equal to 0." DEFVAL { false } ::= { dot11PrivacyEntry 4 } dot11WEPICVErrorCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current 2825 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DESCRIPTION "This is a status variable. It is written by the MAC when an ICV error is detected. This counter increments when a frame is received with the Protected Frame subfield of the Frame Control field equal to 1 and the value of the ICV as received in the frame does not match the ICV value that is calculated for the contents of the received frame. ICV errors for TKIP are not counted in this variable but in dot11RSNAStatsTKIPICVErrors." ::= { dot11PrivacyEntry 5 } dot11WEPExcludedCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a bad frame is received. This counter increments when a frame is received with the Protected Frame subfield of the Frame Control field equal to 0 and the value of dot11ExcludeUnencrypted causes that frame to be discarded." ::= { dot11PrivacyEntry 6 } dot11RSNAActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect for the next MLME-START.request primitive or MLME- JOIN.request primitive. When this object is true, this indicates that RSNA is enabled on this entity. Configuration variables for RSNA operation are found in the dot11RSNAConfigTable. This object requires that dot11PrivacyInvoked also be equal to true." ::= { dot11PrivacyEntry 7 } dot11RSNAPreauthenticationActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. When this object is true, this indicates that RSNA preauthentication is enabled on this entity. This object requires that dot11RSNAActivated also be equal to true." ::= { dot11PrivacyEntry 8 } -- ********************************************************************** -- * End of dot11Privacy TABLE -- ********************************************************************** -- ********************************************************************** -- * dot11SMTnotification Objects -- ********************************************************************** 2826 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11SMTnotification OBJECT IDENTIFIER ::= { dot11smt 6 } dot11Disassociate NOTIFICATION-TYPE OBJECTS { ifIndex, dot11DisassociateReason, dot11DisassociateStation } STATUS current DESCRIPTION "The disassociate notification is sent when the STA sends a Disassociation frame. The value of the notification includes the MAC address of the MAC to which the Disassociation frame was sent and the reason for the disassociation. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." ::= { dot11SMTnotification 0 1 } dot11Deauthenticate NOTIFICATION-TYPE OBJECTS { ifIndex, dot11DeauthenticateReason, dot11DeauthenticateStation } STATUS current DESCRIPTION "The deauthenticate notification is sent when the STA sends a Deauthentication frame. The value of the notification includes the MAC address of the MAC to which the Deauthentication frame was sent and the reason for the deauthentication. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." ::= { dot11SMTnotification 0 2 } dot11AuthenticateFail NOTIFICATION-TYPE OBJECTS { ifIndex, dot11AuthenticateFailStatus, dot11AuthenticateFailStation } STATUS current DESCRIPTION "The authenticate failure notification is sent when the STA sends an Authentication frame with a status code other than SUCCESS. The value of the notification includes the MAC address of the MAC to which the Authentication frame was sent and the reason for the authentication failure. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Inter- face tables in this MIB module are indexed by ifIndex." ::= { dot11SMTnotification 0 3 } dot11Associate NOTIFICATION-TYPE OBJECTS { ifIndex, dot11AssociateStation, dot11AssociateID} STATUS current DESCRIPTION "The associate notification is sent when the STA sends an Association Response frame with a status code equal to SUCCESS. The value of the notification includes the MAC address of the MAC to which the Association Response frame was sent and the Association ID. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." ::= { dot11SMTnotification 0 4 } dot11AssociateFailed NOTIFICATION-TYPE OBJECTS { ifIndex, dot11AssociateFailStatus, dot11AssociateFailStation } STATUS current DESCRIPTION "The associate failed notification is sent when the STA sends an Association Response frame with a status code other than SUCCESS. The value of the notification includes the MAC address of the MAC to which the Association Response frame was sent and the reason for the association failure. ifIndex - Each IEEE 802.11 interface is represented by an 2827 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ifEntry. Interface tables in this MIB module are indexed by ifIndex." ::= { dot11SMTnotification 0 5 } dot11Reassociate NOTIFICATION-TYPE OBJECTS { ifIndex, dot11ReassociateStation, dot11ReassociateID} STATUS current DESCRIPTION "The reassociate notification is sent when the STA sends a Reassociation Response frame with a status code equal to SUCCESS. The value of the notification includes the MAC address of the MAC to which the Reassociation Response frame was sent and the Reassociation ID. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." ::= { dot11SMTnotification 0 6 } dot11ReassociateFailed NOTIFICATION-TYPE OBJECTS { ifIndex, dot11ReassociateFailStatus, dot11ReassociateStation } STATUS current DESCRIPTION "The reassociate failed notification is sent when the STA sends a Reassociation Response frame with a status code other than SUCCESS. The value of the notification includes the MAC address of the MAC to which the Reassociation Response frame was sent and the reason for the reassociation failure. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." ::= { dot11SMTnotification 0 7 } -- ********************************************************************** -- * End of dot11SMTnotification Objects -- ********************************************************************** -- ********************************************************************** -- * dot11MultiDomainCapability TABLE -- ********************************************************************** dot11MultiDomainCapabilityTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11MultiDomainCapabilityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This (conceptual) table of attributes for cross-domain mobility." ::= { dot11smt 7 } dot11MultiDomainCapabilityEntry OBJECT-TYPE SYNTAX Dot11MultiDomainCapabilityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the Multiple Domain Capability Table. IfIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB are indexed by ifIndex." INDEX { ifIndex, dot11MultiDomainCapabilityIndex } ::= { dot11MultiDomainCapabilityTable 1 } Dot11MultiDomainCapabilityEntry ::= SEQUENCE { dot11MultiDomainCapabilityIndex Unsigned32, dot11FirstChannelNumber Unsigned32, dot11NumberofChannels Unsigned32, dot11MaximumTransmitPowerLevel Integer32 } dot11MultiDomainCapabilityIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible 2828 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STATUS current DESCRIPTION "The auxiliary variable used to identify instances of the columnar objects in the multidomain Capability Table." ::= { dot11MultiDomainCapabilityEntry 1 } dot11FirstChannelNumber OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute indicates the value of the lowest channel number in the subband for the associated domain country string." DEFVAL { 0 } ::= { dot11MultiDomainCapabilityEntry 2 } dot11NumberofChannels OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute indicates the value of the total number of channels allowed in the subband for the associated domain country string." DEFVAL { 0 } ::= { dot11MultiDomainCapabilityEntry 3 } dot11MaximumTransmitPowerLevel OBJECT-TYPE SYNTAX Integer32 UNITS "dBm" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute indicates the maximum transmit power allowed in the subband for the associated domain country string." DEFVAL { 0 } ::= { dot11MultiDomainCapabilityEntry 4 } -- ******************************************************************** -- * End of dot11MultiDomainCapability TABLE -- ******************************************************************** -- ******************************************************************** -- * dot11SpectrumManagement TABLE -- ******************************************************************** dot11SpectrumManagementTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11SpectrumManagementEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "(Conceptual) table of attributes for spectrum management" ::= {dot11smt 8} dot11SpectrumManagementEntry OBJECT-TYPE 2829 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications SYNTAX Dot11SpectrumManagementEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the Spectrum Management Table. IfIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB are indexed by ifIndex." INDEX {ifIndex, dot11SpectrumManagementIndex} ::= { dot11SpectrumManagementTable 1 } Dot11SpectrumManagementEntry ::= SEQUENCE { dot11SpectrumManagementIndex Unsigned32, dot11ChannelSwitchTime Unsigned32, dot11PowerCapabilityMaxImplemented Integer32, dot11PowerCapabilityMinImplemented Integer32 } dot11SpectrumManagementIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The auxiliary variable used to identify instances of the columnar objects in the Spectrum Management Table." ::= { dot11SpectrumManagementEntry 1 } -- value 2 is reserved dot11ChannelSwitchTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "TUs" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute indicates assumed channel switch time. The minimum value of this attribute is 1 TU." DEFVAL { 2 } ::= { dot11SpectrumManagementEntry 3 } dot11PowerCapabilityMaxImplemented OBJECT-TYPE SYNTAX Integer32 UNITS "dBm" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates the maximum transmit Power Capability of this station." DEFVAL { 0 } ::= { dot11SpectrumManagementEntry 4 } dot11PowerCapabilityMinImplemented OBJECT-TYPE SYNTAX Integer32 UNITS "dBm" MAX-ACCESS read-only STATUS current DESCRIPTION 2830 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications "This is a capability variable. Its value is determined by device capabilities. This attribute indicates the minimum transmit Power Capability of this station." DEFVAL { -100 } ::= { dot11SpectrumManagementEntry 5 } -- ****************************************************************** -- * End of dot11SpectrumManagement TABLE -- ****************************************************************** -- ******************************************************************** -- * dot11RSNAConfig TABLE (RSNA and TSN) -- ******************************************************************** dot11RSNAConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11RSNAConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table containing RSNA configuration objects." ::= { dot11smt 9 } dot11RSNAConfigEntry OBJECT-TYPE SYNTAX Dot11RSNAConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11RSNAConfigTable." INDEX { ifIndex } ::= { dot11RSNAConfigTable 1 } Dot11RSNAConfigEntry ::= SEQUENCE { dot11RSNAConfigVersion Unsigned32, dot11RSNAConfigPairwiseKeysImplemented Unsigned32, dot11RSNAConfigGroupCipher OCTET STRING, dot11RSNAConfigGroupRekeyMethod INTEGER, dot11RSNAConfigGroupRekeyTime Unsigned32, dot11RSNAConfigGroupRekeyPackets Unsigned32, dot11RSNAConfigGroupRekeyStrict TruthValue, dot11RSNAConfigPSKValue OCTET STRING, dot11RSNAConfigPSKPassPhrase DisplayString, dot11RSNAConfigGroupUpdateCount Unsigned32, dot11RSNAConfigPairwiseUpdateCount Unsigned32, dot11RSNAConfigGroupCipherSize Unsigned32, dot11RSNAConfigPMKLifetime Unsigned32, dot11RSNAConfigPMKReauthThreshold Unsigned32, dot11RSNAConfigNumberOfPTKSAReplayCounters Unsigned32, dot11RSNAConfigSATimeout Unsigned32, dot11RSNAAuthenticationSuiteSelected OCTET STRING, dot11RSNAPairwiseCipherSelected OCTET STRING, dot11RSNAGroupCipherSelected OCTET STRING, dot11RSNAPMKIDUsed OCTET STRING, dot11RSNAAuthenticationSuiteRequested OCTET STRING, dot11RSNAPairwiseCipherRequested OCTET STRING, dot11RSNAGroupCipherRequested OCTET STRING, dot11RSNATKIPCounterMeasuresInvoked Unsigned32, dot11RSNA4WayHandshakeFailures Unsigned32, dot11RSNAConfigNumberOfGTKSAReplayCounters Unsigned32, dot11RSNAConfigSTKKeysImplemented Unsigned32, dot11RSNAConfigSTKCipher OCTET STRING, dot11RSNAConfigSTKRekeyTime Unsigned32, 2831 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11RSNAConfigSMKUpdateCount Unsigned32, dot11RSNAConfigSTKCipherSize Unsigned32, dot11RSNAConfigSMKLifetime Unsigned32, dot11RSNAConfigSMKReauthThreshold Unsigned32, dot11RSNAConfigNumberOfSTKSAReplayCounters Unsigned32, dot11RSNAPairwiseSTKSelected OCTET STRING, dot11RSNASMKHandshakeFailures Unsigned32, dot11RSNASAERetransPeriod Unsigned32, dot11RSNASAEAntiCloggingThreshold Unsigned32, dot11RSNASAESync Unsigned32 } -- dot11RSNAConfigEntry 1 has been deprecated. dot11RSNAConfigVersion OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. The highest RSNA version this entity supports. See 9.4.2.9." ::= { dot11RSNAConfigEntry 2 } dot11RSNAConfigPairwiseKeysImplemented OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This object indicates how many pairwise keys the entity supports for RSNA." ::= { dot11RSNAConfigEntry 3 } dot11RSNAConfigGroupCipher OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This object indicates the group cipher suite selector the entity uses. The group cipher suite in the RSNE takes its value from this variable. It consists of an OUI or CID (the first 3 octets) and a cipher suite identifier (the last octet)." ::= { dot11RSNAConfigEntry 4 } dot11RSNAConfigGroupRekeyMethod OBJECT-TYPE SYNTAX INTEGER { disabled(1), timeBased(2), packetBased(3), timepacketBased(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This object selects a mechanism for rekeying the RSNA GTK. The default is time-based, once per day. Rekeying the GTK is applicable only to an entity acting in the Authenticator role." 2832 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DEFVAL { timeBased } ::= { dot11RSNAConfigEntry 5 } dot11RSNAConfigGroupRekeyTime OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. The time after which the RSNA GTK is refreshed. The timer starts at the moment the GTK was set using the MLME-SETKEYS.request primitive." DEFVAL { 86400 } -- once per day ::= { dot11RSNAConfigEntry 6 } dot11RSNAConfigGroupRekeyPackets OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) UNITS "1000 packets" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. A packet count after which the RSNA GTK is refreshed. The packet counter starts at the moment the GTK was set using the MLME-SETKEYS.request primitive and it counts all packets encrypted using the current GTK." ::= { dot11RSNAConfigEntry 7 } dot11RSNAConfigGroupRekeyStrict OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This object signals that the GTK be refreshed whenever a STA leaves the BSS that possesses the GTK." ::= { dot11RSNAConfigEntry 8 } dot11RSNAConfigPSKValue OBJECT-TYPE SYNTAX OCTET STRING (SIZE(32)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. The PSK for when RSNA in PSK mode is the selected AKM suite. In that case, the PMK obtains its value from this object. This object is logically write-only. Reading this variable returns unsuccessful status or null or 0." ::= { dot11RSNAConfigEntry 9 } dot11RSNAConfigPSKPassPhrase OBJECT-TYPE SYNTAX DisplayString 2833 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. The PSK, for when RSNA in PSK mode is the selected AKM suite, is configured by dot11RSNAConfigPSKValue. An alternative manner of setting the PSK uses the password-to-key algorithm defined in J.4. This variable provides a means to enter a pass- phrase. When this object is written, the RSNA entity uses the password-to- key algorithm specified in J.4 to derive a preshared and populate dot11RSNAConfigPSKValue with this key. This object is logically write-only. Reading this variable returns unsuccessful status or null or 0." ::= { dot11RSNAConfigEntry 10 } -- dot11RSNAConfigEntry 11 and dot11RSNAConfigEntry 12 have been -- deprecated. dot11RSNAConfigGroupUpdateCount OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. The number of times message 1 in the RSNA group key handshake is retried per GTK handshake attempt." DEFVAL { 3 } ::= { dot11RSNAConfigEntry 13 } dot11RSNAConfigPairwiseUpdateCount OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. The number of times message 1 and message 3 in the RSNA 4-way handshake are retried per 4-way handshake attempt." DEFVAL { 3 } ::= { dot11RSNAConfigEntry 14 } dot11RSNAConfigGroupCipherSize OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) UNITS "bits" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This object indicates the length of the group cipher key." ::= { dot11RSNAConfigEntry 15 } dot11RSNAConfigPMKLifetime OBJECT-TYPE 2834 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications SYNTAX Unsigned32 (1..4294967295) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. The maximum lifetime of a PMK in the PMKSA cache." DEFVAL { 43200 } ::= { dot11RSNAConfigEntry 16 } dot11RSNAConfigPMKReauthThreshold OBJECT-TYPE SYNTAX Unsigned32 (1..100) UNITS "percentage" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. The percentage of the PMK lifetime that should expire before an IEEE 802.1X reauthentication occurs." DEFVAL { 70 } ::= { dot11RSNAConfigEntry 17 } dot11RSNAConfigNumberOfPTKSAReplayCounters OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. Specifies the number of PTKSA replay counters per association: 0 -> 1 replay counter, 1 -> 2 replay counters, 2 -> 4 replay counters, 3 -> 16 replay counters" DEFVAL { 3 } ::= { dot11RSNAConfigEntry 18 } dot11RSNAConfigSATimeout OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. The maximum time a security association takes to set up." DEFVAL { 60 } ::= { dot11RSNAConfigEntry 19 } dot11RSNAAuthenticationSuiteSelected OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. 2835 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications It is written by the RSNA Key Management in the SME when a security association is established. The selector of the last AKM suite negotiated." ::= { dot11RSNAConfigEntry 20 } dot11RSNAPairwiseCipherSelected OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the RSNA Key Management in the SME when a security association is established. The selector of the last pairwise cipher negotiated." ::= { dot11RSNAConfigEntry 21 } dot11RSNAGroupCipherSelected OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the RSNA Key Management in the SME when a security association is established. The selector of the last group cipher negotiated." ::= { dot11RSNAConfigEntry 22 } dot11RSNAPMKIDUsed OBJECT-TYPE SYNTAX OCTET STRING (SIZE(16)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the RSNA Key Management in the SME when a security association is established. The selector of the last PMKID used in the last 4-way handshake." ::= { dot11RSNAConfigEntry 23 } dot11RSNAAuthenticationSuiteRequested OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the RSNA Key Management in the SME when a security association is established. The selector of the last AKM suite requested." ::= { dot11RSNAConfigEntry 24 } dot11RSNAPairwiseCipherRequested OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the RSNA Key Management in the SME when a security association is established. The selector of the last pairwise cipher requested." 2836 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ::= { dot11RSNAConfigEntry 25 } dot11RSNAGroupCipherRequested OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the RSNA Key Management in the SME when a security association is established. The selector of the last group cipher requested." ::= { dot11RSNAConfigEntry 26 } dot11RSNATKIPCounterMeasuresInvoked OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. Counts the number of times that a TKIP MIC failure occurred two times within 60 s and TKIP countermeasures were invoked. This attribute counts both local and remote MIC failure events reported to this STA. It increments every time TKIP countermeasures are invoked" ::= { dot11RSNAConfigEntry 27 } dot11RSNA4WayHandshakeFailures OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the RSNA Key Management in the SME when the condition described below occurs. Counts the number of 4-way handshake failures." ::= { dot11RSNAConfigEntry 28 } dot11RSNAConfigNumberOfGTKSAReplayCounters OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. Specifies the number of GTKSA replay counters per association: 0 -> 1 replay counter, 1 -> 2 replay counters, 2 -> 4 replay counters, 3 -> 16 replay counters" DEFVAL { 3 } ::= { dot11RSNAConfigEntry 29 } dot11RSNAConfigSTKKeysImplemented OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. 2837 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This object indicates how many STKs the entity supports for RSNA." ::= { dot11RSNAConfigEntry 30 } dot11RSNAConfigSTKCipher OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This object specifies the ciphersuite used by the STK for a DLS link." ::= { dot11RSNAConfigEntry 31} dot11RSNAConfigSTKRekeyTime OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. The time after which an RSNA STK is refreshed. The timer starts at the moment the STK was set using the MLME-SETKEYS.request primitive." DEFVAL { 86400 } -- once per day ::= { dot11RSNAConfigEntry 32 } dot11RSNAConfigSMKUpdateCount OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. The number of times message 1 in the RSNA SMK handshake is retried per SMK handshake attempt." DEFVAL { 3 } ::= { dot11RSNAConfigEntry 33 } dot11RSNAConfigSTKCipherSize OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) UNITS "bits" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This object indicates the length of the STK cipher key." ::= { dot11RSNAConfigEntry 34 } dot11RSNAConfigSMKLifetime OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) UNITS "seconds" MAX-ACCESS read-write STATUS deprecated DESCRIPTION "Deprecated because mechanisms for use of cached SMKSAs are not defined. 2838 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. The maximum lifetime of an SMK in the SMKSA cache." DEFVAL { 43200 } ::= { dot11RSNAConfigEntry 35 } dot11RSNAConfigSMKReauthThreshold OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-write STATUS deprecated DESCRIPTION "Deprecated because mechanisms for use of cached SMKSAs are not defined. This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute indicates the number of seconds for which an SMK authentication is valid. If a new SMK authentication is not completed successfully before the number of seconds indicated by this attribute elapse, from the prior authentication, the STA deletes the SMKSA." ::= { dot11RSNAConfigEntry 36 } dot11RSNAConfigNumberOfSTKSAReplayCounters OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. Specifies the number of STKSA replay counters per association: 0 -> 1 replay counter, 1 -> 2 replay counters, 2 -> 4 replay counters, 3 -> 16 replay counters" DEFVAL { 3 } ::= { dot11RSNAConfigEntry 37 } dot11RSNAPairwiseSTKSelected OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the RSNA Key Management in the SME when a security association is established. The selector of the last STK cipher negotiated." ::= { dot11RSNAConfigEntry 38 } dot11RSNASMKHandshakeFailures OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the RSNA Key Management in the SME when the condition described below occurs. Counts the number of SMK handshake failures." ::= { dot11RSNAConfigEntry 39 } 2839 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11RSNASAERetransPeriod OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME when establishing or becoming a member of a BSS. Changes take effect for the next MLME-START.request primitive. This object specifies the initial retry timeout, in millisecond units, used by the SAE authentication and key establishment protocol." DEFVAL { 40 } ::= { dot11RSNAConfigEntry 40 } dot11RSNASAEAntiCloggingThreshold OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This object specifies the maximum number of SAE protocol instances allowed to simultaneously be in either Commit or Confirmed state." DEFVAL { 5 } ::= { dot11RSNAConfigEntry 41 } dot11RSNASAESync OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This object specifies the maximum number of synchronization errors that are allowed to happen prior to disassociation of the offending SAE peer." DEFVAL { 5 } ::= { dot11RSNAConfigEntry 42 } -- ******************************************************************** -- * End of dot11RSNAConfig TABLE -- ******************************************************************** -- ******************************************************************** -- * dot11RSNAConfigPairwiseCiphers TABLE -- ******************************************************************** dot11RSNAConfigPairwiseCiphersTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11RSNAConfigPairwiseCiphersEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists the pairwise ciphers supported by this entity. It allows enabling and disabling of each pairwise cipher by network management. The pairwise cipher suite list in the RSNE is formed using the information in this table." ::= { dot11smt 10 } dot11RSNAConfigPairwiseCiphersEntry OBJECT-TYPE SYNTAX Dot11RSNAConfigPairwiseCiphersEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION 2840 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications "The table entry, indexed by the interface index (or all interfaces) and the pairwise cipher." INDEX { ifIndex, dot11RSNAConfigPairwiseCipherIndex } ::= { dot11RSNAConfigPairwiseCiphersTable 1 } Dot11RSNAConfigPairwiseCiphersEntry ::= SEQUENCE { dot11RSNAConfigPairwiseCipherIndex Unsigned32, dot11RSNAConfigPairwiseCipherImplemented OCTET STRING, dot11RSNAConfigPairwiseCipherActivated TruthValue, dot11RSNAConfigPairwiseCipherSizeImplemented Unsigned32 } dot11RSNAConfigPairwiseCipherIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The auxiliary index into the dot11RSNAConfigPairwiseCiphersTable." ::= { dot11RSNAConfigPairwiseCiphersEntry 1 } dot11RSNAConfigPairwiseCipherImplemented OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. The selector of a supported pairwise cipher. It consists of an OUI or CID (the first 3 octets) and a cipher suite identifier (the last octet)." ::= { dot11RSNAConfigPairwiseCiphersEntry 2 } dot11RSNAConfigPairwiseCipherActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This object enables or disables the pairwise cipher." ::= { dot11RSNAConfigPairwiseCiphersEntry 3 } dot11RSNAConfigPairwiseCipherSizeImplemented OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) UNITS "bits" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This object indicates the length of the pairwise cipher key. This should be 256 for TKIP and 128 or 256 for CCMP and 128 or 256 for GCMP." ::= { dot11RSNAConfigPairwiseCiphersEntry 4 } -- ******************************************************************** -- * End of dot11RSNAConfigPairwiseCiphers TABLE -- ******************************************************************** -- ******************************************************************** -- * dot11RSNAConfigAuthenticationSuites TABLE -- ******************************************************************** 2841 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11RSNAConfigAuthenticationSuitesTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11RSNAConfigAuthenticationSuitesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists the AKM suites supported by this entity. Each AKM suite can be individually enabled and disabled. The AKM suite list in the RSNE is formed using the information in this table." ::= { dot11smt 11 } dot11RSNAConfigAuthenticationSuitesEntry OBJECT-TYPE SYNTAX Dot11RSNAConfigAuthenticationSuitesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) in the dot11RSNAConfigAuthenticationSuitesTable." INDEX { dot11RSNAConfigAuthenticationSuiteIndex } ::= { dot11RSNAConfigAuthenticationSuitesTable 1 } Dot11RSNAConfigAuthenticationSuitesEntry ::= SEQUENCE { dot11RSNAConfigAuthenticationSuiteIndex Unsigned32, dot11RSNAConfigAuthenticationSuiteImplemented OCTET STRING, dot11RSNAConfigAuthenticationSuiteActivated TruthValue } dot11RSNAConfigAuthenticationSuiteIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The auxiliary variable used as an index into the dot11RSNAConfigAuthenti- cationSuitesTable." ::= { dot11RSNAConfigAuthenticationSuitesEntry 1 } dot11RSNAConfigAuthenticationSuiteImplemented OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. The selector of an AKM suite. It consists of an OUI or CID (the first 3 octets) and a cipher suite identifier (the last octet)." ::= { dot11RSNAConfigAuthenticationSuitesEntry 2 } dot11RSNAConfigAuthenticationSuiteActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This variable indicates whether the corresponding AKM suite is enabled/ disabled." ::= { dot11RSNAConfigAuthenticationSuitesEntry 3 } -- ******************************************************************** -- * End of dot11RSNAConfigAuthenticationSuites TABLE -- ******************************************************************** -- ******************************************************************** 2842 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications -- * dot11RSNAStats TABLE -- ******************************************************************** dot11RSNAStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11RSNAStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table maintains per-STA statistics in an RSN. The entry with dot11RSNAStatsSTAAddress equal to FF-FF-FF-FF-FF-FF contains statistics for group addressed traffic." ::= { dot11smt 12 } dot11RSNAStatsEntry OBJECT-TYPE SYNTAX Dot11RSNAStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11RSNAStatsTable." INDEX { ifIndex, dot11RSNAStatsIndex } ::= { dot11RSNAStatsTable 1 } Dot11RSNAStatsEntry ::= SEQUENCE { dot11RSNAStatsIndex Unsigned32, dot11RSNAStatsSTAAddress MacAddress, dot11RSNAStatsVersion Unsigned32, dot11RSNAStatsSelectedPairwiseCipher OCTET STRING, dot11RSNAStatsTKIPICVErrors Counter32, dot11RSNAStatsTKIPLocalMICFailures Counter32, dot11RSNAStatsTKIPRemoteMICFailures Counter32, dot11RSNAStatsCCMPReplays Counter32, dot11RSNAStatsCCMPDecryptErrors Counter32, dot11RSNAStatsTKIPReplays Counter32, dot11RSNAStatsCMACReplays Counter32, dot11RSNAStatsRobustMgmtCCMPReplays Counter32, dot11RSNAStatsBIPMICErrors Counter32 } dot11RSNAStatsIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An auxiliary index into the dot11RSNAStatsTable." ::= { dot11RSNAStatsEntry 1 } dot11RSNAStatsSTAAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the RSNA Key Management in the SME. The MAC address of the STA to which the statistics in this conceptual row belong." ::= { dot11RSNAStatsEntry 2 } dot11RSNAStatsVersion OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. 2843 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications It is written by the RSNA Key Management in the SME. The RSNA version with which the STA associated." ::= { dot11RSNAStatsEntry 3 } dot11RSNAStatsSelectedPairwiseCipher OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the RSNA Key Management in the SME. The pairwise cipher suite Selector (as defined in 9.4.2.25.2) used during association, in transmission order." ::= { dot11RSNAStatsEntry 4 } dot11RSNAStatsTKIPICVErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. Counts the number of TKIP ICV errors encountered when decrypting packets for the STA." ::= { dot11RSNAStatsEntry 5 } dot11RSNAStatsTKIPLocalMICFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. Counts the number of MIC failures encountered when checking the integrity of packets received from the STA at this entity." ::= { dot11RSNAStatsEntry 6 } dot11RSNAStatsTKIPRemoteMICFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. Counts the number of MIC failures encountered by the STA identified by dot11StatsSTAAddress and reported back to this entity." ::= { dot11RSNAStatsEntry 7 } dot11RSNAStatsCCMPReplays OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. The number of received CCMP MPDUs discarded by the replay mechanism." ::= { dot11RSNAStatsEntry 8 } 2844 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11RSNAStatsCCMPDecryptErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. The number of received MPDUs discarded by the CCMP decryption algorithm." ::= { dot11RSNAStatsEntry 9 } dot11RSNAStatsTKIPReplays OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. Counts the number of TKIP replay errors detected." ::= { dot11RSNAStatsEntry 10 } dot11RSNAStatsCMACReplays OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. The number of received MPDUs discarded by the CMAC replay errors." ::= { dot11RSNAStatsEntry 12 } dot11RSNAStatsRobustMgmtCCMPReplays OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. The number of received robust Management frames discarded due to CCMP replay errors" ::= {dot11RSNAStatsEntry 13} dot11RSNAStatsBIPMICErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. The number of received MMPDUs discarded due to BIP MIC errors" ::= {dot11RSNAStatsEntry 14} -- ******************************************************************** -- * End of dot11RSNAStats TABLE -- ******************************************************************** -- ********************************************************************** -- * dot11OperatingClasses TABLE -- ********************************************************************** dot11OperatingClassesTable OBJECT-TYPE 2845 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications SYNTAX SEQUENCE OF Dot11OperatingClassesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "(Conceptual) table of attributes for operating classes" ::= {dot11smt 13} dot11OperatingClassesEntry OBJECT-TYPE SYNTAX Dot11OperatingClassesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the Operating Classes Table. IfIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB are indexed by ifIndex." INDEX {ifIndex, dot11OperatingClassesIndex} ::= { dot11OperatingClassesTable 1 } Dot11OperatingClassesEntry ::= SEQUENCE { dot11OperatingClassesIndex Unsigned32, dot11OperatingClass Unsigned32, dot11CoverageClass Unsigned32 } dot11OperatingClassesIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The auxiliary variable used to identify instances of the columnar objects in the Operating Classes Table." ::= { dot11OperatingClassesEntry 1 } dot11OperatingClass OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or external management entity when the device is initialized. This attribute indicates the operating class to be used." DEFVAL { 0 } ::= { dot11OperatingClassesEntry 2 } dot11CoverageClass OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or external management entity when the device is initialized. This attribute indicates the coverage class to be used." DEFVAL { 0 } ::= { dot11OperatingClassesEntry 3 } -- ******************************************************************** -- * End of dot11OperatingClasses TABLE -- ******************************************************************** -- ********************************************************************** 2846 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications -- * dot11BeaconRssi TABLE -- ********************************************************************** dot11BeaconRssiTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11BeaconRssiEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "(Conceptual) table of attributes for received Beacon RSSI." ::= {dot11smt 38} dot11BeaconRssiEntry OBJECT-TYPE SYNTAX Dot11BeaconRssiEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the received Beacon RSSI table." INDEX { dot11BeaconRssiIndex } ::= { dot11BeaconRssiTable 1 } Dot11BeaconRssiEntry ::= SEQUENCE { dot11BeaconRssiIndex Unsigned32, dot11BeaconMACAddress MacAddress, dot11BeaconRssi Unsigned32} dot11BeaconRssiIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The auxiliary variable used to identify instances of the columnar objects in the received Beacon Rssi table." ::= { dot11BeaconRssiEntry 1 } dot11BeaconMACAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by MAC upon receiving a Beacon frame. This attribute indicates the MAC address of the AP from which the beacon used for Beacon RSSI measurement was transmitted." ::= { dot11BeaconRssiEntry 2 } dot11BeaconRssi OBJECT-TYPE SYNTAX Integer32 UNITS "dBm" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by MAC upon receiving a Beacon frame. This attribute indicates the received signal strength of Beacon frames received on the channel, averaged (in linear domain) over all active receive chains. This may be time-averaged over recent history by a vendor-specific smoothing function." ::= { dot11BeaconRssiEntry 3 } -- ******************************************************************** -- * End of dot11BeaconRssi TABLE -- ******************************************************************** 2847 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications -- ******************************************************************** -- * dot11FastBSSTransitionConfig TABLE -- ******************************************************************** dot11FastBSSTransitionConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11FastBSSTransitionConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table containing fast BSS transition configuration objects." ::= { dot11smt 15 } dot11FastBSSTransitionConfigEntry OBJECT-TYPE SYNTAX Dot11FastBSSTransitionConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11FastBSSTransitionConfigTable." INDEX { ifIndex } ::= { dot11FastBSSTransitionConfigTable 1 } Dot11FastBSSTransitionConfigEntry ::= SEQUENCE { dot11FastBSSTransitionActivated TruthValue, dot11FTMobilityDomainID OCTET STRING, dot11FTOverDSActivated TruthValue, dot11FTResourceRequestSupported TruthValue, dot11FTR0KeyHolderID OCTET STRING, dot11FTR0KeyLifetime Unsigned32, dot11FTR1KeyHolderID OCTET STRING, dot11FTReassociationDeadline Unsigned32 } dot11FastBSSTransitionActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. When this object is true, this indicates that fast BSS transition (FT) is enabled on this entity. The entity advertises the FT-related elements in its Beacon and Probe Response frames. This object requires that dot11- FastBSSTransitionImplemented also be equal to true." ::= { dot11FastBSSTransitionConfigEntry 1 } dot11FTMobilityDomainID OBJECT-TYPE SYNTAX OCTET STRING (SIZE(2)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the Mobility Domain identifier (MDID) of this entity. The MDID is used to indicate a group of APs, within an ESS, between which a STA can use fast BSS transition services. Fast BSS transitions are allowed only between APs that have the same MDID and are within the same ESS. They are not allowed between APs with different MDIDs or in different ESSs. 2848 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Since fast BSS transition services are defined only within the scope of an ESS, there is no requirement that MDIDs be unique across ESSs." ::= { dot11FastBSSTransitionConfigEntry 2 } dot11FTOverDSActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. When this object is true, this indicates that fast BSS transition via the over-the-DS protocol as described in Clause 13 is enabled on this AP entity." ::= { dot11FastBSSTransitionConfigEntry 3 } dot11FTResourceRequestSupported OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. When this object is true, this indicates that the fast BSS transition (FT) resource request procedures of 13.10 are supported on this AP entity." ::= { dot11FastBSSTransitionConfigEntry 4 } dot11FTR0KeyHolderID OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1..48)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the PMK-R0 key holder identifier (R0KH-ID) of the Authenticator of this AP. NOTE: Backend protocol might allow longer NAS Client identifiers (e.g., RADIUS allows up to 253-octet NAS-Identifier), but when used with fast BSS transition, the maximum length is limited to 48 octets. Subclause 13.2.2 requires that the same value is used for the NAS Client identifier and dot11FTR0KeyHolderID." ::= { dot11FastBSSTransitionConfigEntry 5 } dot11FTR0KeyLifetime OBJECT-TYPE SYNTAX Unsigned32 (60..4294967295) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the default lifetime of the PMK-R0, in seconds, when a Session-Timeout attribute is not provided during the EAP authenti- cation. This attribute also applies when the PMK-R0 is derived from a PSK." DEFVAL { 1209600 } 2849 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ::= { dot11FastBSSTransitionConfigEntry 6 } dot11FTR1KeyHolderID OBJECT-TYPE SYNTAX OCTET STRING (SIZE(6)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the PMK-R1 key holder identifier (R1KH-ID) of the Authenticator of this AP. It is equal to a MAC address of the entity hold- ing the PMK-R1 in the Authenticator." ::= { dot11FastBSSTransitionConfigEntry 7 } dot11FTReassociationDeadline OBJECT-TYPE SYNTAX Unsigned32 (1000..4294967295) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the number of TUs that this target AP entity caches a PTKSA and reserves any specified resources for a STA while wait- ing for a reassociation from that STA. It is assumed that this value is administered consistently across the mobility domain." DEFVAL { 1000 } ::= { dot11FastBSSTransitionConfigEntry 8 } -- ********************************************************************* -- * End of dot11FastBSSTransitionConfig TABLE -- ********************************************************************* -- ******************************************************************** -- * dot11LCIDSE TABLE -- ******************************************************************** dot11LCIDSETable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11LCIDSEEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Group contains conceptual table of attributes for Dependent Station Enablement." ::= { dot11smt 16 } dot11LCIDSEEntry OBJECT-TYPE SYNTAX Dot11LCIDSEEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11LCIDSETable Indexed by dot11LCIDSEIndex." INDEX { dot11LCIDSEIndex } ::= { dot11LCIDSETable 1 } Dot11LCIDSEEntry ::= SEQUENCE { dot11LCIDSEIndex Unsigned32, dot11LCIDSEIfIndex InterfaceIndex, dot11LCIDSECurrentOperatingClass Unsigned32, dot11LCIDSELatitudeUncertainty Unsigned32, 2850 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11LCIDSELatitudeInteger Integer32, dot11LCIDSELatitudeFraction Integer32, dot11LCIDSELongitudeUncertainty Unsigned32, dot11LCIDSELongitudeInteger Integer32, dot11LCIDSELongitudeFraction Integer32, dot11LCIDSEAltitudeType INTEGER, dot11LCIDSEAltitudeUncertainty Unsigned32, dot11LCIDSEAltitude Integer32, dot11LCIDSEDatum Unsigned32, dot11RegLocAgreement TruthValue, dot11RegLocDSE TruthValue, dot11DependentSTA TruthValue, dot11DependentEnablementIdentifier Unsigned32, dot11DSEEnablementTimeLimit Unsigned32, dot11DSEEnablementFailHoldTime Unsigned32, dot11DSERenewalTime Unsigned32, dot11DSETransmitDivisor Unsigned32 } dot11LCIDSEIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index for LCI DSE elements in dot11LCIDSETable, greater than 0." ::= { dot11LCIDSEEntry 1 } dot11LCIDSEIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "Each IEEE 802.11 interface is represented by an ifEntry. Interface Tables in this MIB are indexed by ifIndex." ::= { dot11LCIDSEEntry 2 } dot11LCIDSECurrentOperatingClass OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME when the device is initialized. Current Operating Class is 8 bits indicating the particular Operating Class in use by the radio." ::= { dot11LCIDSEEntry 3 } dot11LCIDSELatitudeUncertainty OBJECT-TYPE SYNTAX Unsigned32 (0..63) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME when the device is initialized. Latitude uncertainty is defined in IETF RFC 6225." ::= { dot11LCIDSEEntry 4 } dot11LCIDSELatitudeInteger OBJECT-TYPE SYNTAX Integer32 (-359..359) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. 2851 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications It is written by the SME when the device is initialized. Latitude is represented as a 2s complement 34-bit fixed point value consisting of 9 bits of integer and 25 bits of fraction. This field contains the 9 bits of integer portion of the latitude." ::= { dot11LCIDSEEntry 5 } dot11LCIDSELatitudeFraction OBJECT-TYPE SYNTAX Integer32 (-16777215..16777215) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME when the device is initialized. Latitude is represented a 2s complement 34-bit fixed point value consisting of 9 bits of integer and 25 bits of fraction. This field contains the 25 bits of fraction portion of the latitude." ::= { dot11LCIDSEEntry 6 } dot11LCIDSELongitudeUncertainty OBJECT-TYPE SYNTAX Unsigned32 (0..63) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME when the device is initialized. Longitude uncertainty is defined in IETF RFC 6225." ::= { dot11LCIDSEEntry 7 } dot11LCIDSELongitudeInteger OBJECT-TYPE SYNTAX Integer32 (-359..359) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME when the device is initialized. Longitude is represented a 2s complement 34-bit fixed point value consisting of 9 bits of integer and 25 bits of fraction. This field contains the 9 bits of integer portion of the longitude." ::= { dot11LCIDSEEntry 8 } dot11LCIDSELongitudeFraction OBJECT-TYPE SYNTAX Integer32 (-16777215..16777215) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME when the device is initialized. Longitude is represented a 2s complement 34-bit fixed point value consisting of 9 bits of integer and 25 bits of fraction. This field contains the 25 bits of fraction portion of the longitude." ::= { dot11LCIDSEEntry 9 } dot11LCIDSEAltitudeType OBJECT-TYPE SYNTAX INTEGER { meters(1), floors(2), hagm(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME when the device is initialized. Altitude Type is 4 bits encoding the type of altitude. Codes defined are: 2852 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications meters : in 2s complement fixed-point 22-bit integer part with 8-bit fraction floors : in 2s complement fixed-point 22-bit integer part with 8-bit fraction hagm : Height Above Ground in meters, in 2s complement fixed-point 22-bit integer part with 8-bit fraction. " DEFVAL { 3 } ::= { dot11LCIDSEEntry 10 } dot11LCIDSEAltitudeUncertainty OBJECT-TYPE SYNTAX Unsigned32 (0..63) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME when the device is initialized. Altitude resolution is 6 bits indicating the number of valid bits in the altitude." ::= { dot11LCIDSEEntry 11 } dot11LCIDSEAltitude OBJECT-TYPE SYNTAX Integer32 (-536870912..536870911) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME when the device is initialized. Altitude is a 30-bit value defined by the Altitude type field. The field is encoded as a 2s complement fixed-point 22-bit integer part with 8-bit fraction." ::= { dot11LCIDSEEntry 12 } -- reserved: 13. was dot11LCIDSEAltitudeFraction dot11LCIDSEDatum OBJECT-TYPE SYNTAX Unsigned32 (1..3) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME when the device is initialized. Datum is a 3-bit value encoding the horizontal and vertical references used for the coordinates given in this LCI. IETF RFC 6225 defines the values of Datum. Type 1 is WGS-84, the coordinate system used by GPS. Type 2 is NAD83 with NAVD88 vertical reference. Type 3 is NAD83 with Mean Lower Low Water vertical datum. All other types are reserved." DEFVAL { 1 } ::= { dot11LCIDSEEntry 14 } dot11RegLocAgreement OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a DSE Enablement frame is received. RegLocAgreement reports the Enabling STA's Agreement status. false indicates it is operating away from national borders and outside national policy zones. true indicates it is operating by agreement near national borders or inside national policy zones." 2853 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DEFVAL { false } ::= { dot11LCIDSEEntry 15 } dot11RegLocDSE OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a DSE Enablement frame is received. RegLocDSE reports the Enabling STA's DSE status. false indicates Dependent STAs are not enabled. true indicates Dependent STA operation is enabled." DEFVAL { false } ::= { dot11LCIDSEEntry 16 } dot11DependentSTA OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a DSE Enablement frame is received. This attribute reports the Dependent STA status of the STA that sent the Beacon or Probe Response frame(s) with this information. false indicates that STA is not operating as a Dependent STA. true indicates that STA is operating as a Dependent STA." DEFVAL { true } ::= { dot11LCIDSEEntry 17 } dot11DependentEnablementIdentifier OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a DSE Enablement frame is received. This attribute reports the Dependent STA identifier assigned by the enabling STA to the dependent station." DEFVAL { 0 } ::= { dot11LCIDSEEntry 18 } dot11DSEEnablementTimeLimit OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME when the device is initialized. dot11DSEEnablementTimeLimit indicates the maximum number of seconds that a dependent STA may transmit in a DSE frequency band while attaining enablement with an enabling STA. Unless another value is mandated by regulatory authorities, the value is 32 seconds." DEFVAL { 32 } ::= { dot11LCIDSEEntry 19 } dot11DSEEnablementFailHoldTime OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION 2854 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications "This is a control variable. It is written by the SME when the device is initialized. dot11DSEEnablementFailHoldTime indicates the number of seconds that a dependent STA must not transmit in a DSE frequency band when it fails to attain enablement with an enabling STA within dot11DSEEnablementTimeLimit seconds. Unless another value is mandated by regulatory authorities, the value is 512 seconds." DEFVAL { 512 } ::= { dot11LCIDSEEntry 20} dot11DSERenewalTime OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME when the device is initialized. dot11DSERenewalTime indicates the maximum number of seconds that a dependent STA may operate in a DSE frequency band without receiving and decoding an enabling signal from its enabling STA. Unless another value is mandated by regulatory authorities, the value is 60 seconds." DEFVAL { 60 } ::= { dot11LCIDSEEntry 21} dot11DSETransmitDivisor OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME when the device is initialized. dot11DSETransmitDivisor indicates the value used by a dependent STA when operating in a DSE frequency band and transmitting. The dependent STA sends an Action frame when the sum of dot11TransmittedFragmentCount, dot11GroupTransmittedFrameCount and dot11ReceivedFragmentCount modulo dot11DSETransmitDivisor equals 0. Unless another value is mandated by regulatory authorities, the default value is 256." DEFVAL { 256 } ::= { dot11LCIDSEEntry 22} -- ******************************************************************** -- * End of dot11LCIDSE TABLE -- ******************************************************************** -- ********************************************************************** -- * dot11HTStationConfig TABLE -- ********************************************************************** dot11HTStationConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11HTStationConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Station Configuration attributes. In tabular form to allow for multiple instances on an agent." ::= { dot11smt 17 } dot11HTStationConfigEntry OBJECT-TYPE SYNTAX Dot11HTStationConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION 2855 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications "An entry (conceptual row) in the dot11HTStationConfig Table. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX { ifIndex } ::= { dot11HTStationConfigTable 1 } Dot11HTStationConfigEntry ::= SEQUENCE { dot11HTOperationalMCSSet OCTET STRING, dot11MIMOPowerSave INTEGER, dot11NDelayedBlockAckOptionImplemented TruthValue, dot11MaxAMSDULength INTEGER, dot11STBCControlFrameOptionImplemented TruthValue, dot11LsigTxopProtectionOptionImplemented TruthValue, dot11MaxRxAMPDUFactor Unsigned32, dot11MinimumMPDUStartSpacing Unsigned32, dot11PCOOptionImplemented TruthValue, dot11TransitionTime Unsigned32, dot11MCSFeedbackOptionImplemented INTEGER, dot11HTControlFieldSupported TruthValue, dot11RDResponderOptionImplemented TruthValue, dot11SPPAMSDUCapable TruthValue, dot11SPPAMSDURequired TruthValue, dot11FortyMHzOptionImplemented TruthValue } dot11HTOperationalMCSSet OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1..127)) MAX-ACCESS read-write STATUS deprecated DESCRIPTION "Deprecated as no longer used by IEEE Std 802.11-2016 This is a control variable. It is written by an external management entity. Changes take effect for the next MLME-START.request primitive or MLME- JOIN.request primitive. This attribute shall specify the set of MCS at which the station may transmit data. Each octet contains a value representing a rate. Each MCS shall be within the range 1 to 127, and shall be supported for receiving data. This value is reported in transmitted Beacon, Probe Request, Probe Response, Association Request, Association Response, Reassociation Request, and Reassociation Response frames, and is used to determine whether a BSS with which the station might synchronize is suitable. It is also used when starting a BSS, as specified in 11.3." ::= { dot11HTStationConfigEntry 1 } dot11MIMOPowerSave OBJECT-TYPE SYNTAX INTEGER { static(1), dynamic(2), mimo(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the PHY when the power save condition changes. This is an 8-bit integer value that identifies the configured power save state of MIMO." ::= { dot11HTStationConfigEntry 2 } dot11NDelayedBlockAckOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION 2856 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of supporting the No Acknowledgment option of the delayed block ack." DEFVAL { false } ::= { dot11HTStationConfigEntry 3 } dot11MaxAMSDULength OBJECT-TYPE SYNTAX INTEGER { short(3839), long(7935) } UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates the maximum supported size of an A-MSDU." ::= { dot11HTStationConfigEntry 4 } dot11STBCControlFrameOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of processing the received Control frames that are STBC frames." DEFVAL { false } ::= { dot11HTStationConfigEntry 5 } dot11LsigTxopProtectionOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of supporting L-SIG TXOP protection option." DEFVAL { false } ::= { dot11HTStationConfigEntry 6 } dot11MaxRxAMPDUFactor OBJECT-TYPE SYNTAX Unsigned32 (0..3) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates the maximum length of A-MPDU that the STA can receive. The Maximum Rx A-MPDU defined by this field is equal to 2 ** (13+dot11MaxRxAMPDUFactor) -1 octets." DEFVAL { 0 } ::= { dot11HTStationConfigEntry 7 } dot11MinimumMPDUStartSpacing OBJECT-TYPE SYNTAX Unsigned32 (0..7) MAX-ACCESS read-only 2857 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates the minimum time between the start of adjacent MPDUs within an A-MPDU. This time is measured at the PHY SAP; the number of octets between the start of two consecutive MPDUs in A-MPDU shall be equal or greater than (dot11MinimumMPDUStartSpacing*PHY-bit-rate)/8. The encoding of the minimum time to this attribute is: 0 - no restriction 1 - 1/4 microsecond 2 - 1/2 microsecond 3 - 1 microsecond 4 - 2 microseconds 5 - 4 microseconds 6 - 8 microseconds 7 - 16 microseconds" DEFVAL { 0 } ::= { dot11HTStationConfigEntry 8 } dot11PCOOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of supporting PCO." DEFVAL { false } ::= { dot11HTStationConfigEntry 9 } dot11TransitionTime OBJECT-TYPE SYNTAX Unsigned32 (0..3) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates that the maximum transition time within which the STA can switch between 20 MHz channel width and 40 MHz channel width with a high probability. The encoding of the transition time to this attribute is: 0 - no transition 1 - 400 microseconds 2 - 1500 microseconds 3 - 5000 microseconds" DEFVAL { 2 } ::= { dot11HTStationConfigEntry 10 } dot11MCSFeedbackOptionImplemented OBJECT-TYPE SYNTAX INTEGER { none(0), unsolicited (2), both (3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates the MCS feed back capability supported by the station implementation." DEFVAL { 0 } 2858 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ::= { dot11HTStationConfigEntry 11 } dot11HTControlFieldSupported OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of receiving HT Control field." DEFVAL { false } ::= { dot11HTStationConfigEntry 12 } dot11RDResponderOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable operating as an RD responder." DEFVAL { false } ::= { dot11HTStationConfigEntry 13 } dot11SPPAMSDUCapable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the STA implementation is capable of protecting the A-MSDU bit (Bit 7) in the QoS Control field when dot11RSNAActivated is true." DEFVAL { false } ::= { dot11HTStationConfigEntry 14 } dot11SPPAMSDURequired OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that the STA is configured to disallow (i.e., not to send or receive) PP A-MSDUs when dot11RSNAActivated is true." DEFVAL { false } ::= { dot11HTStationConfigEntry 15 } dot11FortyMHzOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. 2859 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This attribute, when true, indicates that the STA is capable of transmitting and receiving on a 40 MHz channel using a 40 MHz mask." DEFVAL { false } ::= { dot11HTStationConfigEntry 16 } -- ********************************************************************** -- * End of dot11HTStationConfig TABLE -- ********************************************************************** -- ********************************************************************** -- * dot11WirelessMgmtOptions TABLE -- ********************************************************************** dot11WirelessMgmtOptionsTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11WirelessMgmtOptionsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Wireless Management attributes. In tabular form to allow for multiple instances on an agent. This table only applies to the interface if dot11WirelessManagementImplemented is equal to true in the dot11StationConfigTable." ::= { dot11smt 18 } dot11WirelessMgmtOptionsEntry OBJECT-TYPE SYNTAX Dot11WirelessMgmtOptionsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11WirelessMgmtOptionsTable. For all Wireless Management features, an Activated MIB variable is used to activate/enable or deactivate/disable the corresponding feature. An Implemented MIB variable is used for an optional feature to indicate whether the feature is implemented. A mandatory feature does not have a corresponding Implemented MIB variable. It is possible for there to be multiple IEEE 802.11 interfaces on one agent, each with its unique MAC address. The relationship between an IEEE 802.11 interface and an interface in the context of the Internet-standard MIB is one-to-one. As such, the value of an ifIndex object instance can be directly used to identify corresponding instances of the objects defined herein. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX { ifIndex } ::= { dot11WirelessMgmtOptionsTable 1 } Dot11WirelessMgmtOptionsEntry ::= SEQUENCE { dot11LocationActivated TruthValue, dot11FMSImplemented TruthValue, dot11FMSActivated TruthValue, dot11EventsActivated TruthValue, dot11DiagnosticsActivated TruthValue, dot11MultiBSSIDImplemented TruthValue, dot11MultiBSSIDActivated TruthValue, dot11TFSImplemented TruthValue, dot11TFSActivated TruthValue, dot11WNMSleepModeImplemented TruthValue, dot11WNMSleepModeActivated TruthValue, dot11TIMBroadcastImplemented TruthValue, dot11TIMBroadcastActivated TruthValue, dot11ProxyARPImplemented TruthValue, dot11ProxyARPActivated TruthValue, dot11BSSTransitionImplemented TruthValue, dot11BSSTransitionActivated TruthValue, 2860 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11QoSTrafficCapabilityImplemented TruthValue, dot11QoSTrafficCapabilityActivated TruthValue, dot11ACStationCountImplemented TruthValue, dot11ACStationCountActivated TruthValue, dot11CoLocIntfReportingImplemented TruthValue, dot11CoLocIntfReportingActivated TruthValue, dot11MotionDetectionImplemented TruthValue, dot11MotionDetectionActivated TruthValue, dot11TODImplemented TruthValue, dot11TODActivated TruthValue, dot11TimingMsmtImplemented TruthValue, dot11TimingMsmtActivated TruthValue, dot11ChannelUsageImplemented TruthValue, dot11ChannelUsageActivated TruthValue, dot11TriggerSTAStatisticsActivated TruthValue, dot11SSIDListImplemented TruthValue, dot11SSIDListActivated TruthValue, dot11MulticastDiagnosticsActivated TruthValue, dot11LocationTrackingImplemented TruthValue, dot11LocationTrackingActivated TruthValue, dot11DMSImplemented TruthValue, dot11DMSActivated TruthValue, dot11UAPSDCoexistenceImplemented TruthValue, dot11UAPSDCoexistenceActivated TruthValue, dot11WNMNotificationImplemented TruthValue, dot11WNMNotificationActivated TruthValue, dot11UTCTSFOffsetImplemented TruthValue, dot11UTCTSFOffsetActivated TruthValue, dot11FineTimingMsmtRespActivated TruthValue, dot11FineTimingMsmtInitActivated TruthValue, dot11LciCivicInNeighborReport TruthValue, dot11RMFineTimingMsmtRangeRepImplemented TruthValue, dot11RMFineTimingMsmtRangeRepActivated TruthValue, dot11RMLCIConfigured TruthValue, dot11RMCivicConfigured TruthValue } dot11LocationActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that the capability of the station to provide location is enabled. The capability is disabled, otherwise." DEFVAL { false} ::= { dot11WirelessMgmtOptionsEntry 1 } dot11FMSImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of supporting FMS when the dot11WirelessManagementImplemented is equal to true." 2861 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ::= { dot11WirelessMgmtOptionsEntry 2 } dot11FMSActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that the capability of the station to provide FMS is enabled. The capability is disabled, otherwise" DEFVAL { false} ::= { dot11WirelessMgmtOptionsEntry 3 } dot11EventsActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that the capability of the station to provide Event Reporting is enabled. The capability is disabled, otherwise" DEFVAL { false} ::= { dot11WirelessMgmtOptionsEntry 4 } dot11DiagnosticsActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that the capability of the station to provide Diagnostic Reporting is enabled. The capability is disabled, otherwise." DEFVAL { false} ::= { dot11WirelessMgmtOptionsEntry 5 } dot11MultiBSSIDImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of supporting Multiple BSSID when the dot11WirelessManagementImplemented is equal to true." ::= { dot11WirelessMgmtOptionsEntry 6 } dot11MultiBSSIDActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. 2862 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that the capability of the station to provide Multi BSSID is enabled. The capability is disabled, otherwise." DEFVAL { false} ::= { dot11WirelessMgmtOptionsEntry 7 } dot11TFSImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of supporting TFS when the dot11WirelessManagementImplemented is equal to true." ::= { dot11WirelessMgmtOptionsEntry 8 } dot11TFSActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that TFS is enabled. TFS is disabled otherwise." DEFVAL { false} ::= { dot11WirelessMgmtOptionsEntry 9 } dot11WNMSleepModeImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of supporting WNM sleep mode when the dot11WirelessManagementImplemented is equal to true." ::= { dot11WirelessMgmtOptionsEntry 10 } dot11WNMSleepModeActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that WNM sleep mode is enabled. WNM sleep mode is disabled otherwise." DEFVAL { false} ::= { dot11WirelessMgmtOptionsEntry 11 } dot11TIMBroadcastImplemented OBJECT-TYPE SYNTAX TruthValue 2863 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of supporting TIM Broadcast when the dot11WirelessManagementImplemented is equal to true." ::= { dot11WirelessMgmtOptionsEntry 12} dot11TIMBroadcastActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that TIM broadcast is enabled. TIM broadcast is disabled otherwise." DEFVAL { false} ::= { dot11WirelessMgmtOptionsEntry 13} dot11ProxyARPImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of supporting the proxy ARP service, when the dot11WirelessManagementImplemented is equal to true." ::= { dot11WirelessMgmtOptionsEntry 14 } dot11ProxyARPActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that the capability of the AP to provide the proxy ARP service is enabled. The capability is disabled, otherwise." DEFVAL { false} ::= { dot11WirelessMgmtOptionsEntry 15 } dot11BSSTransitionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of supporting BSS transition management, when 2864 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications the dot11WirelessManagementImplemented is equal to true." ::= { dot11WirelessMgmtOptionsEntry 16 } dot11BSSTransitionActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that the capability of the station to provide BSS transition is enabled. The capability is disabled, otherwise. " DEFVAL { false} ::= { dot11WirelessMgmtOptionsEntry 17 } dot11QoSTrafficCapabilityImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of supporting QoS traffic capability when the dot11WirelessManagementImplemented is equal to true." ::= { dot11WirelessMgmtOptionsEntry 18 } dot11QoSTrafficCapabilityActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that the capability of the station to provide QoS traffic capability is enabled. QoS traffic capability is disabled otherwise." DEFVAL { false} ::= { dot11WirelessMgmtOptionsEntry 19 } dot11ACStationCountImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of supporting AC Station Count when the dot11WirelessManagementImplemented is equal to true." ::= { dot11WirelessMgmtOptionsEntry 20 } dot11ACStationCountActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION 2865 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that the capability of the station to provide AC Station Count is enabled. AC Station Count is disabled otherwise." DEFVAL { false} ::= { dot11WirelessMgmtOptionsEntry 21 } dot11CoLocIntfReportingImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of supporting Colocated Interference Reporting. The capability is disabled, otherwise." ::= { dot11WirelessMgmtOptionsEntry 22 } dot11CoLocIntfReportingActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that the capability of the station to support Colocated Interference Reporting is enabled. The capability is disabled, otherwise." DEFVAL { false} ::= { dot11WirelessMgmtOptionsEntry 23 } dot11MotionDetectionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of supporting motion detection when the dot11WirelessManagementImplemented is equal to true. " ::= { dot11WirelessMgmtOptionsEntry 24 } dot11MotionDetectionActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that the capability to support motion detection is enabled." DEFVAL { false} ::= { dot11WirelessMgmtOptionsEntry 25 } 2866 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11TODImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of supporting Time Of Departure for Clause 15 transmitted frames, Clause 17 transmitted frames, Clause 16 transmitted frames, Clause 18 transmitted frames and Clause 19 transmitted frames when the dot11WirelessManagementImplemented is equal to true." ::= { dot11WirelessMgmtOptionsEntry 26 } dot11TODActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that the capability to support Time Of Departure frames for transmitted Clause 15, Clause 17, Clause 16, Clause 18 and Clause 19 frames is enabled." DEFVAL { false} ::= { dot11WirelessMgmtOptionsEntry 27 } dot11TimingMsmtImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of supporting Timing Measurement capability when the dot11WirelessManagementImplemented is equal to true." ::= { dot11WirelessMgmtOptionsEntry 28 } dot11TimingMsmtActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect at the next occurrence of an MLME-START.request or MLME-JOIN.request primitive. This attribute, when true, indicates that the station capability for Timing Measurement is enabled. false indicates the station has no Timing Measurement capability or that the capability is present but is disabled." DEFVAL { false} ::= { dot11WirelessMgmtOptionsEntry 29 } dot11ChannelUsageImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current 2867 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of supporting Channel Usage when the dot11WirelessManagementImplemented is equal to true." ::= { dot11WirelessMgmtOptionsEntry 30 } dot11ChannelUsageActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that Channel Usage is enabled. Channel Usage is disabled otherwise." DEFVAL { false} ::= { dot11WirelessMgmtOptionsEntry 31 } dot11TriggerSTAStatisticsActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that the capability of the station to provide triggered STA statistics is enabled. The capability is disabled otherwise" DEFVAL { false} ::= { dot11WirelessMgmtOptionsEntry 32 } dot11SSIDListImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of supporting the SSID List capability when the dot11WirelessManagementImplemented is true." ::= { dot11WirelessMgmtOptionsEntry 33 } dot11SSIDListActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that the capability of the station to support the SSID List capability is enabled. The capability is disabled, otherwise" DEFVAL { false} 2868 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ::= { dot11WirelessMgmtOptionsEntry 34 } dot11MulticastDiagnosticsActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that the capability of the station to provide multicast diagnostic reporting is enabled. The capability is disabled, otherwise." DEFVAL { false} ::= { dot11WirelessMgmtOptionsEntry 35 } dot11LocationTrackingImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of supporting Location Track when the dot11WirelessManagementImplemented is true." ::= { dot11WirelessMgmtOptionsEntry 36 } dot11LocationTrackingActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that the capability of the station to provide Location Track is enabled. The capability is disabled otherwise." DEFVAL { false} ::= { dot11WirelessMgmtOptionsEntry 37 } dot11DMSImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of supporting DMS when the dot11WirelessManagementImplemented is true." ::= { dot11WirelessMgmtOptionsEntry 38 } dot11DMSActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. 2869 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that DMS is enabled. DMS is disabled otherwise." DEFVAL { false} ::= { dot11WirelessMgmtOptionsEntry 39 } dot11UAPSDCoexistenceImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the Station implementation is capable of supporting U-APSD coexistence when the dot11WirelessManagementImplemented is equal to true." ::= { dot11WirelessMgmtOptionsEntry 40} dot11UAPSDCoexistenceActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that U-APSD coexistence is enabled. U-APSD coexistence is disabled, otherwise." DEFVAL { false} ::= { dot11WirelessMgmtOptionsEntry 41} dot11WNMNotificationImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of supporting WNM notification when the dot11WirelessManagementImplemented is equal to true." ::= { dot11WirelessMgmtOptionsEntry 42} dot11WNMNotificationActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that the capability of the station to provide WNM notification is enabled. The capability is disabled, otherwise." DEFVAL { false} ::= { dot11WirelessMgmtOptionsEntry 43} dot11UTCTSFOffsetImplemented OBJECT-TYPE SYNTAX TruthValue 2870 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the Station implementation is capable of supporting UTC TSF Offset advertisement when the dot11WirelessManagementImplemented is equal to true." ::= { dot11WirelessMgmtOptionsEntry 44} dot11UTCTSFOffsetActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that UTC TSF Offset advertisement is enabled at the station. The capability is disabled, otherwise." DEFVAL { false} ::= { dot11WirelessMgmtOptionsEntry 45} dot11FineTimingMsmtRespActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect at the next occurrence of an MLME-START.request or MLME-JOIN.request primitive. This attribute, when true, indicates that the station capability for Fine Timing Measurement as a responder is enabled. false indicates the station has no Fine Timing Measurement capability as a responder or that the capability is present but is disabled." DEFVAL { false} ::= { dot11WirelessMgmtOptionsEntry 47 } dot11LciCivicInNeighborReport OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that the station includes LCI and civic location subelements in the Neighbor Report without regard to either dot11FineTimingMsmtRespActivated or dot11FineTimingMsmtInitActivated." DEFVAL { false} ::= { dot11WirelessMgmtOptionsEntry 48 } dot11RMFineTimingMsmtRangeRepImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. 2871 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of supporting fine timing measurement range reporting." ::= { dot11WirelessMgmtOptionsEntry 49} dot11RMFineTimingMsmtRangeRepActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that fine timing measurement range reporting is enabled at the station. The capability is disabled, otherwise." DEFVAL { false} ::= { dot11WirelessMgmtOptionsEntry 50} dot11FineTimingMsmtInitActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect at the next occurrence of an MLME-START.request or MLME-JOIN.request primitive. This attribute, when true, indicates that the station capability for Fine Timing Measurement as an initiator is enabled. false indicates the station has no Fine Timing Measurement capability as an initiator or that the capability is present but is disabled." DEFVAL { false} ::= { dot11WirelessMgmtOptionsEntry 51 } dot11RMLCIConfigured OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity which sets the Value to true after it configures dot11STALCIEntry. It is written by the STA when an external management entity configures dot11STALCIEntry. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that that the station is configured with an LCI location (LCI is not Unknown). false indicates the station is not configured with an LCI location or the configured LCI Location is set to Unknown (as defined in 9.4.2.22.10)." DEFVAL { false } ::= { dot11WirelessMgmtOptionsEntry 52 } dot11RMCivicConfigured OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity which sets the Value to true when it configures dot11STACivicLocationEntry. 2872 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications It is written by the STA when an external management entity configures dot11STALCIEntry. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that that the station is configured with a civic location (civic location is not Unknown). false indicates the station is not configured with an civic location or the configured civic Location is set to Unknown (as defined in 9.4.2.22.13)." DEFVAL { false } ::= { dot11WirelessMgmtOptionsEntry 53 } -- ******************************************************************** -- * dot11LocationServices TABLE -- ******************************************************************** dot11LocationServicesNextIndex OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "Identifies a hint for the next value of dot11LocationServicesIndex to be used in a row creation attempt for dot11LocationServicesTable. If no new rows can be created for some reason, such as memory, processing requirements, etc, the SME shall set this attribute to 0. It shall update this attribute to a proper value other than 0 as soon as it is capable of receiving new measurement requests. The nextIndex is not necessarily sequential nor monotonically increasing." ::= { dot11smt 19 } dot11LocationServicesTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11LocationServicesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Group contains conceptual table of attributes for WNM LocationServices." ::= { dot11smt 20 } dot11LocationServicesEntry OBJECT-TYPE SYNTAX Dot11LocationServicesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11LocationServicesTable Indexed by dot11LocationServicesIndex." INDEX { dot11LocationServicesIndex } ::= { dot11LocationServicesTable 1 } Dot11LocationServicesEntry ::= SEQUENCE { dot11LocationServicesIndex Unsigned32, dot11LocationServicesMACAddress MacAddress, dot11LocationServicesLIPIndicationMulticastAddress MacAddress, dot11LocationServicesLIPReportIntervalUnits INTEGER, dot11LocationServicesLIPNormalReportInterval Unsigned32, dot11LocationServicesLIPNormalFramesperChannel Unsigned32, dot11LocationServicesLIPInMotionReportInterval Unsigned32, dot11LocationServicesLIPInMotionFramesperChannel Unsigned32, dot11LocationServicesLIPBurstInterframeInterval Unsigned32, dot11LocationServicesLIPTrackingDuration Unsigned32, dot11LocationServicesLIPEssDetectionInterval Unsigned32, dot11LocationServicesLocationIndicationChannelList OCTET STRING, dot11LocationServicesLocationIndicationBroadcastDataRate 2873 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Unsigned32, dot11LocationServicesLocationIndicationOptionsUsed OCTET STRING, dot11LocationServicesLocationIndicationIndicationParameters OCTET STRING, dot11LocationServicesLocationStatus Unsigned32 } dot11LocationServicesIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This attribute contains an auxiliary index into the dot11LocationServicesTable." ::= { dot11LocationServicesEntry 1 } dot11LocationServicesMACAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute is the MAC address of the STA reporting location information." ::= { dot11LocationServicesEntry 2 } dot11LocationServicesLIPIndicationMulticastAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute is the destination address to which the Location Track Notification frames are sent in a BSS that is not an IBSS; see 9.4.2.71.2 and 11.24.4.1." ::= { dot11LocationServicesEntry 3 } dot11LocationServicesLIPReportIntervalUnits OBJECT-TYPE SYNTAX INTEGER { hours(0), minutes(1), seconds(2), milliseconds(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute contains the Location Indication Parameters Report Interval Units value." ::= { dot11LocationServicesEntry 4 } dot11LocationServicesLIPNormalReportInterval OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute contains the time interval, expressed in the units indicated in the Report Interval Units field, at which the reporting STA is expected to transmit one or more Location Track Notification frames if either dot11MotionDetectionActivated is false or the STA is stationary. The STA does not transmit Location Track Notification frames when the Normal Report Interval is 0." ::= { dot11LocationServicesEntry 5 } dot11LocationServicesLIPNormalFramesperChannel OBJECT-TYPE SYNTAX Unsigned32 (0..255) 2874 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute contains the number of Location Track Notification frames per channel sent or expected to be sent by the STA at each Normal Report Interval." ::= { dot11LocationServicesEntry 6 } dot11LocationServicesLIPInMotionReportInterval OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute contains the time interval, expressed in the units indicated in the Report Interval Units field, at which the STA reports its location by sending a Location Track Notification frame when the reporting STA is in motion. If dot11MotionDetectionActivated is false, this field is set to 0." ::= { dot11LocationServicesEntry 7} dot11LocationServicesLIPInMotionFramesperChannel OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute contains the number of Location Track Notification frames per channel sent or expected to be sent by the STA at each In-Motion Report Interval. If dot11MotionDetectionActivated is false, this field is set to 0." ::= { dot11LocationServicesEntry 8 } dot11LocationServicesLIPBurstInterframeInterval OBJECT-TYPE SYNTAX Unsigned32 (0..255) UNITS "milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute contains the target time interval between the transmissions of each of the Normal or In-Motion frames on the same channel. The Burst Inter-frame interval value is set to 0 to indicate that frames will be transmitted with no target inter-frame delay." ::= { dot11LocationServicesEntry 9 } dot11LocationServicesLIPTrackingDuration OBJECT-TYPE SYNTAX Unsigned32 (0..255) UNITS "minutes" MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute contains the amount of time that a STA sends the Location Track Notification frames. The duration starts as soon as the STA sends a Location Configuration Response frame with a Location Status value of Success. If the Tracking Duration value is a nonzero value the STA will send Location Track Notification frames, based on the Normal and In-Motion Report Interval field values, until the duration ends. If the Tracking Duration is 0 the STA will continuously send Location Track Notification frames as defined by Normal and In-Motion Report Interval field values until transmission is terminated based on 11.24.4.2 procedures." ::= { dot11LocationServicesEntry 10} dot11LocationServicesLIPEssDetectionInterval OBJECT-TYPE SYNTAX Unsigned32 (0..255) UNITS "minutes" MAX-ACCESS read-create 2875 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STATUS current DESCRIPTION "This attribute contains the interval that a STA checks for beacons transmitted by one or more APs belonging to the same ESS that configured the STA. If no beacons from the ESS are received for this period, the STA terminates transmission of Location Track Notification frames as described in 11.24.4.2 procedures. The ESS Detection Interval field is not used when the ESS Detection Interval field value is set to 0." ::= { dot11LocationServicesEntry 11} dot11LocationServicesLocationIndicationChannelList OBJECT-TYPE SYNTAX OCTET STRING (SIZE (2..254)) MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute contains one or more Operating Class and Channel octet pairs." ::= { dot11LocationServicesEntry 12} dot11LocationServicesLocationIndicationBroadcastDataRate OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute specifies the target data rate at which the STA transmits Location Track Notification frames. The Broadcast Target Data Rate field format is specified by the Rate Identification field defined in 9.4.1.33. A value of 0 indicates the STA transmits Location Track Notification frames at a rate chosen by the STA transmitting the Location Track Notification frames." DEFVAL { 0 } ::= { dot11LocationServicesEntry 13} dot11LocationServicesLocationIndicationOptionsUsed OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1)) MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute indicates the location configuration options used for transmitting Location Track Notification frames." ::= { dot11LocationServicesEntry 14} dot11LocationServicesLocationIndicationIndicationParameters OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..255)) MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute indicates the location Indication Parameters used for transmitting Location Track Notification frames." ::= { dot11LocationServicesEntry 15} dot11LocationServicesLocationStatus OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute contains the Location Status value as indicated in Table 9-175, Event Report Status." ::= { dot11LocationServicesEntry 16 } -- ******************************************************************** -- * End of dot11LocationServices TABLE -- ******************************************************************** 2876 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications -- ******************************************************************** -- * dot11WirelessMGTEvent TABLE -- ******************************************************************** dot11WirelessMGTEventTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11WirelessMGTEventEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Group contains the current list of WIRELESS Management reports that have been received by the MLME. The report tables shall be maintained as FIFO to preserve freshness, thus the rows in this table can be deleted for memory constraints or other implementation constraints determined by the vendor. New rows shall have different RprtIndex values than those deleted within the range limitation of the index. One easy way is to increment the EventIndex for new reports being written in the table." ::= { dot11smt 21 } dot11WirelessMGTEventEntry OBJECT-TYPE SYNTAX Dot11WirelessMGTEventEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11WirelessMGTEventTable Indexed by dot11WirelessMGTEventIndex." INDEX { dot11WirelessMGTEventIndex } ::= { dot11WirelessMGTEventTable 1 } Dot11WirelessMGTEventEntry ::= SEQUENCE { dot11WirelessMGTEventIndex Unsigned32, dot11WirelessMGTEventMACAddress MacAddress, dot11WirelessMGTEventType INTEGER, dot11WirelessMGTEventStatus INTEGER, dot11WirelessMGTEventTSF TSFType, dot11WirelessMGTEventUTCOffset OCTET STRING, dot11WirelessMGTEventTimeError OCTET STRING, dot11WirelessMGTEventTransitionSourceBSSID MacAddress, dot11WirelessMGTEventTransitionTargetBSSID MacAddress, dot11WirelessMGTEventTransitionTime Unsigned32, dot11WirelessMGTEventTransitionReason INTEGER, dot11WirelessMGTEventTransitionResult Unsigned32, dot11WirelessMGTEventTransitionSourceRCPI Unsigned32, dot11WirelessMGTEventTransitionSourceRSNI Unsigned32, dot11WirelessMGTEventTransitionTargetRCPI Unsigned32, dot11WirelessMGTEventTransitionTargetRSNI Unsigned32, dot11WirelessMGTEventRSNATargetBSSID MacAddress, dot11WirelessMGTEventRSNAAuthenticationType OCTET STRING, dot11WirelessMGTEventRSNAEAPMethod OCTET STRING, dot11WirelessMGTEventRSNAResult Unsigned32, dot11WirelessMGTEventRSNARSNElement OCTET STRING, dot11WirelessMGTEventPeerSTAAddress MacAddress, dot11WirelessMGTEventPeerOperatingClass Unsigned32, dot11WirelessMGTEventPeerChannelNumber Unsigned32, dot11WirelessMGTEventPeerSTATxPower Integer32, dot11WirelessMGTEventPeerConnectionTime Unsigned32, dot11WirelessMGTEventPeerPeerStatus Unsigned32, dot11WirelessMGTEventWNMLog OCTET STRING } dot11WirelessMGTEventIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-only STATUS current 2877 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DESCRIPTION "This attribute contains an auxiliary index into the dot11WirelessMGTEventTable." ::= { dot11WirelessMGTEventEntry 1 } dot11WirelessMGTEventMACAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute is the MAC address of the STA providing the Event report." ::= { dot11WirelessMGTEventEntry 2 } dot11WirelessMGTEventType OBJECT-TYPE SYNTAX INTEGER { transition(0), rsna(1), peerToPeer(2), wnmLog(3), vendorSpecific(221) } MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute indicates the request type of this WNM Event request." ::= { dot11WirelessMGTEventEntry 3 } dot11WirelessMGTEventStatus OBJECT-TYPE SYNTAX INTEGER { successful(0), requestFailed(1), requestRefused(2), requestIncapable(3), detectedFrequentTransition(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute contains the status value included in the Event report." ::= { dot11WirelessMGTEventEntry 4 } dot11WirelessMGTEventTSF OBJECT-TYPE SYNTAX TSFType MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute contains the value of the Event timestamp field." ::= { dot11WirelessMGTEventEntry 5 } dot11WirelessMGTEventUTCOffset OBJECT-TYPE SYNTAX OCTET STRING (SIZE(10)) MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute indicates the UTC Offset Time Value optionally included in the Event report." ::= { dot11WirelessMGTEventEntry 6} dot11WirelessMGTEventTimeError OBJECT-TYPE SYNTAX OCTET STRING (SIZE(5)) MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute contains the value of the Event Time Error field 2878 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications optionally included in the Event report." ::= { dot11WirelessMGTEventEntry 7} dot11WirelessMGTEventTransitionSourceBSSID OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute contains the value of the Source BSSID field in a Transition event report." ::= { dot11WirelessMGTEventEntry 8} dot11WirelessMGTEventTransitionTargetBSSID OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute contains the value of the Target BSSID field in a Transition event report." ::= { dot11WirelessMGTEventEntry 9} dot11WirelessMGTEventTransitionTime OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "TUs" MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute indicates the transition time for the reported transition event in TUs. The Transition time is defined as the time difference between the starting time and the ending time of a transition between APs, even if the transition results in remaining on the same AP. Start and end times for a transition event are defined in 11.24.2.2" ::= { dot11WirelessMGTEventEntry 10} dot11WirelessMGTEventTransitionReason OBJECT-TYPE SYNTAX INTEGER { unspecified(0), excessiveFrameLossRatesPoorConditions(1), excessiveDelayForCurrentTrafficStreams(2), insufficientQosCapacityForCurrentTrafficStreams(3), firstAssociationToEss(4), loadBalancing(5), betterApFound(6), deauthenticatedDisassociatedFromPreviousAp(7), certificateToken(8), apFailedIeee8021XEapAuthentication(9), apFailed4wayHandshake(10), excessiveDataMICFailures(11), exceededFrameTransmissionRetryLimit(12), ecessiveBroadcastDisassociations(13), excessiveBroadcastDeauthentications(14), previousTransitionFailed(15) } MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute indicates the reason for the reported BSS transition event. The format for this list of reasons is further detailed in 9.4.2.68.2." ::= { dot11WirelessMGTEventEntry 11} dot11WirelessMGTEventTransitionResult OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-only 2879 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STATUS current DESCRIPTION "This attribute indicates the result of the attempted transition and is set to one of the status codes specified in Table 9-46." ::= { dot11WirelessMGTEventEntry 12 } dot11WirelessMGTEventTransitionSourceRCPI OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute indicates the received channel power of the most recently measured frame from the Source BSSID before the STA reassociates to the Target BSSID. The Source RCPI is a logarithmic function of the received signal power, as defined in 9.4.2.38." ::= { dot11WirelessMGTEventEntry 13 } dot11WirelessMGTEventTransitionSourceRSNI OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute indicates the received signal-to-noise indication of the most recently measured frame from the Source BSSID before the STA reassociates to the Target BSSID. The Source RSNI is a logarithmic function of the signal-to-noise ratio, as defined in 9.4.2.41." ::= { dot11WirelessMGTEventEntry 14 } dot11WirelessMGTEventTransitionTargetRCPI OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute indicates the received channel power of the first measured frame just after STA reassociates to the Target BSSID. If association with target BSSID failed, the Target RCPI field indicates the received channel power of the most recently measured frame from the Target BSSID. The Target RCPI is a logarithmic function of the received signal power, as defined 9.4.2.38." ::= { dot11WirelessMGTEventEntry 15 } dot11WirelessMGTEventTransitionTargetRSNI OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute indicates the received signal-to-noise indication of the first measured frame just after STA reassociates to the Target BSSID. If association with target BSSID failed, the Target RCPI field indicates the received signal-to-noise indication of the most recently measured frame from the Target BSSID. The Target RSNI is a logarithmic function of the signal-to-noise ratio, as defined in 9.4.2.41." ::= { dot11WirelessMGTEventEntry 16 } dot11WirelessMGTEventRSNATargetBSSID OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute contains the value of the Target BSSID field in an RSNA event report." ::= { dot11WirelessMGTEventEntry 17 } dot11WirelessMGTEventRSNAAuthenticationType OBJECT-TYPE 2880 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications SYNTAX OCTET STRING (SIZE (4)) MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute indicates the AKM suite, as defined in Table 9-133. The first three octets indicate the OUI or CID. The last octet indicates the suite type." ::= { dot11WirelessMGTEventEntry 18 } dot11WirelessMGTEventRSNAEAPMethod OBJECT-TYPE SYNTAX OCTET STRING(SIZE (1..8)) MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute indicates a value that identifies the EAP Method. When the Authentication Type field is set to the value of either 00-0F-AC:1 (Authentication negotiated over IEEE Std 802.1X or using PMKSA caching as defined in 12.6.10.3) or 00-0F-AC:3 (AKM suite selector for fast BSS transition as defined in 12.7.1.7), the EAP Method field contains the IANA assigned EAP type defined at http://www.iana.org/assignments/eap-numbers. The EAP type contains either the legacy type (1 octet) or the expanded type (1 octet type = 254, 3-octet Vendor ID, 4-octet Vendor-Type). The EAP Method field is set to 0 otherwise." ::= { dot11WirelessMGTEventEntry 19 } dot11WirelessMGTEventRSNAResult OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute indicates the result of the RSNA event and is set to one of the status codes specified in Table 9-46." ::= { dot11WirelessMGTEventEntry 20} dot11WirelessMGTEventRSNARSNElement OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..257)) MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute contains the entire contents of the negotiated RSNE at the time of the authentication attempt. The format of the RSNE is defined in 9.4.2.25." ::= { dot11WirelessMGTEventEntry 21} dot11WirelessMGTEventPeerSTAAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute indicates the MAC address of the peer STA or IBSS BSSID is equal to the indicated MAC address. If this event is for a peer-to-peer link in an infrastructure BSS, this field contains the MAC address of the peer STA. If this event is for a peer-to-peer link in an IBSS, this field contains the BSSID of the IBSS." ::= { dot11WirelessMGTEventEntry 22 } dot11WirelessMGTEventPeerOperatingClass OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute indicates the channel set for this peer-to-peer event report. Country, Operating Class, and Channel Number together specify the channel frequency and spacing for this measurement request. Valid values 2881 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications of Operating Class are shown in Annex E." ::= { dot11WirelessMGTEventEntry 23 } dot11WirelessMGTEventPeerChannelNumber OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute indicates the current operating channel for this peer-to- peer event report. The Channel Number is defined only within the indicated Operating Class as shown in Annex E." ::= { dot11WirelessMGTEventEntry 24 } dot11WirelessMGTEventPeerSTATxPower OBJECT-TYPE SYNTAX Integer32 (-128..127) UNITS "dBm" MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute indicates the STA transmit power used for the peer-to-peer link. The STA Tx Power field indicates the target transmit power at the antenna with a tolerance of +/-5 dB for the lowest basic rate of the reporting STA. A value of -128 indicates that the value is unknown." ::= { dot11WirelessMGTEventEntry 25 } dot11WirelessMGTEventPeerConnectionTime OBJECT-TYPE SYNTAX Unsigned32 (0..16777215) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute indicates a value representing the connection time for the reported peer-to-peer event. If the Peer Status is 0, this field indicates the duration of the Direct Link. If the Peer Status is 1, this field indicates the time difference from the time the Direct Link was established to the time at which the reporting STA generated the event report. If the Peer Status is 2, this field indicates the duration of the IBSS membership. If the Peer Status is 3, this field indicates the time difference from the time the STA joined the IBSS to the time at which the reporting STA generated the event report. See 11.24.2.4." ::= { dot11WirelessMGTEventEntry 26 } dot11WirelessMGTEventPeerPeerStatus OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute indicates the Peer link connection status as indicated in Table 9-177. See 9.4.2.68.4." ::= { dot11WirelessMGTEventEntry 27 } dot11WirelessMGTEventWNMLog OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..2284)) MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute contains the entire syslog message, consisting of the PRI, HEADER, and MSG portion of a WNM log message as described in IETF RFC 5424. The TAG field of the MSG portion of the message is a 17 octet string containing the ASCII representation of the STA MAC address using hexadecimal notation with colons between octets. The octet containing the Individual/Group bit occurs last, and that bit is in the least significant position within that octet. See 11.24.2.5." ::= { dot11WirelessMGTEventEntry 28 } 2882 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications -- ******************************************************************** -- * End of dot11WirelessMGTEvent TABLE -- ******************************************************************** 2883 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications -- ********************************************************************** -- * IEEE 802.11 RM and WNM Interface MIB -- ********************************************************************** -- * The primary interface to the radio measurements and Wireless -- * Network Management functions is meant to be real-time information -- * obtained through the request/response mechanisms of RM and WNM. -- * A secondary interface to the measurements and management functions -- * is through retention of information in this MIB. Non-SNMP requests -- * for information are obtained via object IDs (OIDs) through the NDIS -- * or wireless interfaces in the operating systems. SNMP requests for -- * information are obtained via SNMP SETs and GETs (see [B26]). -- * dot11RMRequest and dot11RMReport Usage -- * -- * The dot11RMRequest and dot11RMReport portions of the RM MIB -- * provide access to the Radio Measurement service. By performing -- * SET operations on the various dot11RMRequest MIB objects, -- * radio measurements may be initiated directly on the local STA or -- * on any peer station within the same BSS. Subsequently, by -- * performing GET operations on the various dot11RMReport MIB -- * objects the results of the requested measurements may be -- * retrieved. -- * -- * In the diagram below, a radio measurement could be initiated -- * for STA x by performing a MIB.set operation on the RM MIB of -- * STA x and specifying the MAC address of STA x in -- * dot11RMRqstTargetAdd. Additionally, it is possible to have STA x -- * request a measurement from STA y by performing a MIB.set operation -- * on the SME MIB of STA x and specifying the MAC address of STA y in -- * dot11RMRqstTargetAdd. In both cases the result of the measurements -- * can be retrieved by performing a MIB.get operation on the RM MIB -- * of STA x upon completion of the measurement. -- * -- * -- * MIB.Set MIB.Set -- * or or -- * MIB.Get MIB.Get -- * +========|=========+ +========|=========+ -- * | SME | | | SME | | -- * | \ / | | \ / | -- * | +=========+ | | +=========+ | -- * | | RM and | | | | RM and | | -- * | | WNM MIB | | | | WNM MIB | | -- * | | | | | | | | -- * | | | | | | | | -- * | +=========+ | | +=========+ | -- * | | | | -- * | / \ | | / \ | -- * | | MREQUEST | | | MREQUEST | -- * +====+=============+ +====+=============+ -- * | | MREPORT | | | MREPORT | -- * | \ / MEASURE | Action frames | \ / MEASURE | -- * | | <==Measurement Request==> | | -- * | | <==Measurement Report===> | | -- * | MLME | | MLME | -- * +==================+ +==================+ -- * STA x STA y -- * -- * Each STA maintains a single dot11RMRequestTable in the SME MIB -- * used to initiate RM Measurement Requests. Each dot11RMRequestEntry -- * in the table represents an individual Measurement Request that -- * makes up a complete Measurement Request frame. -- * Multiple Measurement Requests may be concatenated into a single 2884 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications -- * Measurement Request frame by setting the same -- * dot11RMRqstToken value into multiple dot11RMRequestEntrys. -- * -- * Each row, dot11RMRequestEntry, of the dot11RMRequestTable -- * provides read-create access for the initiation of a measurement -- * request. The dot11RMRequestNextIndex object can be used to -- * determine which is the next available row. Each row corresponding to -- * one measurement in the sequence is created with a dot11RMRqstRowStatus -- * equal to notInService. Once the dot11RMRequestEntry(s) have been -- * created for a desired measurement sequence the corresponding -- * dot11RMRqstRowStatus(s) objects are set to active to indicate that -- * the SME can trigger the appropriate MLME primitives. Upon processing -- * the request, the SME returns the corresponding dot11RMRqstRowStatus(s) -- * object to notInService and are now available for additional -- * measurement requests. -- * -- * After a radio measurement is complete the RM populates the RMReport -- * objects with the results of the measurement. Each STA maintains a set -- * of RMReport tables, one corresponding to each measurement type. The -- * results of the entire measurement sequence are spread across the tables -- * based on the type of measurements requested. Each xxxReportEntry -- * within a xxxReportTable contains a xxxRprtRqstToken that corresponds -- * to the original dot11RMRqstToken in the measurement request. So the -- * results of the measurement can be collected by searching the appropriate -- * xxxReportTables and retrieve any reports with the matching request -- * token. -- * -- * Similar structures and mechanisms are used for WNM -- * Request and Reports. The WNM MIB definitions follow the RM MIB definitions -- * in this Annex. -- ********************************************************************** -- ******************************************************************** -- * Radio Measurement Interface MIB -- ******************************************************************** dot11RadioMeasurement OBJECT IDENTIFIER ::= { dot11smt 14 } -- ******************************************************************** -- * Radio Measurement Requests -- ******************************************************************** dot11RMRequest OBJECT IDENTIFIER ::= { dot11RadioMeasurement 1 } -- ******************************************************************** -- * dot11RMRequest TABLE -- ******************************************************************** dot11RMRequestNextIndex OBJECT-TYPE SYNTAX Unsigned32(0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when able to accept a new request. Identifies a hint for the next value of dot11RMRqstIndex to be used in a row creation attempt for dot11RMRequestTable. If no new rows can be created for some reason, such as memory, processing requirements, etc., the SME sets this attribute to 0. It updates this attribute to a proper value other than 0 as soon as it is capable of receiving new measurement requests. The nextIndex is not necessarily sequential nor monotonically increasing." ::= { dot11RMRequest 1 } dot11RMRequestTable OBJECT-TYPE 2885 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications SYNTAX SEQUENCE OF Dot11RMRequestEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This group contains the current list of requests for RM reports to be issued and have been issued until removed. A network manager adds an RM request by creating a row with createAndWait row status and then filling in the request parameters/attributes. The request becomes active to be issued when the row status is set to Active. The columnar objects or attributes other than the rowStatus are not written if the rowStatus is Active. The request rows can be deleted, if commanded by a network manager via changing the value of dot11RMRqstRowStatus to Destroy. This may leave orphaned rows if a manager crashes and forgets which rows are being used by it. One recommended way to manage orphaned or finished rows is to delete rows if their dot11RMRqstRowStatus remains other than Active for longer than a period (recommend at least 5 minutes, IETF RFC 2579). Or another recommended way is to delete older rows as needed based on their dot11RMRqstTimeStamp values. This can be done by the agent as well as the manager. " ::= { dot11RMRequest 2 } dot11RMRequestEntry OBJECT-TYPE SYNTAX Dot11RMRequestEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11RMRequestTable Indexed by dot11RMRqstIndex." INDEX { dot11RMRqstIndex } ::= { dot11RMRequestTable 1 } Dot11RMRequestEntry ::= SEQUENCE { dot11RMRqstIndex Unsigned32, dot11RMRqstRowStatus RowStatus, dot11RMRqstToken OCTET STRING, dot11RMRqstRepetitions Unsigned32, dot11RMRqstIfIndex InterfaceIndex, dot11RMRqstType INTEGER, dot11RMRqstTargetAdd MacAddress, dot11RMRqstTimeStamp TimeTicks, dot11RMRqstChanNumber Unsigned32, dot11RMRqstOperatingClass Unsigned32, dot11RMRqstRndInterval Unsigned32, dot11RMRqstDuration Unsigned32, dot11RMRqstParallel TruthValue, dot11RMRqstEnable TruthValue, dot11RMRqstRequest TruthValue, dot11RMRqstReport TruthValue, dot11RMRqstDurationMandatory TruthValue, dot11RMRqstBeaconRqstMode INTEGER, dot11RMRqstBeaconRqstDetail INTEGER, dot11RMRqstFrameRqstType INTEGER, dot11RMRqstBssid MacAddress, dot11RMRqstSSID OCTET STRING, dot11RMRqstBeaconReportingCondition INTEGER, dot11RMRqstBeaconThresholdOffset Integer32, dot11RMRqstSTAStatRqstGroupID INTEGER, dot11RMRqstLCIRqstSubject INTEGER, dot11RMRqstLCIAzimuthType INTEGER, dot11RMRqstLCIAzimuthResolution Unsigned32, dot11RMRqstPauseTime Unsigned32, dot11RMRqstTransmitStreamPeerQSTAAddress MacAddress, dot11RMRqstTransmitStreamTrafficIdentifier Unsigned32, dot11RMRqstTransmitStreamBin0Range Unsigned32, 2886 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11RMRqstTrigdQoSAverageCondition TruthValue, dot11RMRqstTrigdQoSConsecutiveCondition TruthValue, dot11RMRqstTrigdQoSDelayCondition TruthValue, dot11RMRqstTrigdQoSAverageThreshold Unsigned32, dot11RMRqstTrigdQoSConsecutiveThreshold Unsigned32, dot11RMRqstTrigdQoSDelayThresholdRange Unsigned32, dot11RMRqstTrigdQoSDelayThreshold Unsigned32, dot11RMRqstTrigdQoSMeasurementCount Unsigned32, dot11RMRqstTrigdQoSTimeout Unsigned32, dot11RMRqstChannelLoadReportingCondition INTEGER, dot11RMRqstChannelLoadReference Unsigned32, dot11RMRqstNoiseHistogramReportingCondition INTEGER, dot11RMRqstAnpiReference Unsigned32, dot11RMRqstAPChannelReport OCTET STRING, dot11RMRqstSTAStatPeerSTAAddress MacAddress, dot11RMRqstFrameTransmitterAddress MacAddress, dot11RMRqstVendorSpecific OCTET STRING, dot11RMRqstSTAStatTrigMeasCount Unsigned32, dot11RMRqstSTAStatTrigTimeout Unsigned32, dot11RMRqstSTAStatTrigCondition OCTET STRING, dot11RMRqstSTAStatTrigSTAFailedCntThresh Unsigned32, dot11RMRqstSTAStatTrigSTAFCSErrCntThresh Unsigned32, dot11RMRqstSTAStatTrigSTAMultRetryCntThresh Unsigned32, dot11RMRqstSTAStatTrigSTAFrameDupeCntThresh Unsigned32, dot11RMRqstSTAStatTrigSTARTSFailCntThresh Unsigned32, dot11RMRqstSTAStatTrigSTAAckFailCntThresh Unsigned32, dot11RMRqstSTAStatTrigSTARetryCntThresh Unsigned32, dot11RMRqstSTAStatTrigQoSTrigCondition OCTET STRING, dot11RMRqstSTAStatTrigQoSFailedCntThresh Unsigned32, dot11RMRqstSTAStatTrigQoSRetryCntThresh Unsigned32, dot11RMRqstSTAStatTrigQoSMultRetryCntThresh Unsigned32, dot11RMRqstSTAStatTrigQoSFrameDupeCntThresh Unsigned32, dot11RMRqstSTAStatTrigQoSRTSFailCntThresh Unsigned32, dot11RMRqstSTAStatTrigQoSAckFailCntThresh Unsigned32, dot11RMRqstSTAStatTrigQoSDiscardCntThresh Unsigned32, dot11RMRqstSTAStatTrigRsnaTrigCondition OCTET STRING, dot11RMRqstSTAStatTrigRsnaCMACICVErrCntThresh Unsigned32, dot11RMRqstSTAStatTrigRsnaCMACReplayCntThresh Unsigned32, dot11RMRqstSTAStatTrigRsnaRobustCCMPReplayCntThresh Unsigned32, dot11RMRqstSTAStatTrigRsnaTKIPICVErrCntThresh Unsigned32, dot11RMRqstSTAStatTrigRsnaTKIPReplayCntThresh Unsigned32, dot11RMRqstSTAStatTrigRsnaCCMPDecryptErrCntThreshUnsigned32, dot11RMRqstSTAStatTrigRsnaCCMPReplayCntThresh Unsigned32 } dot11RMRqstIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index for RM Request elements in dot11RMRequestTable, greater than 0." ::= { dot11RMRequestEntry 1 } dot11RMRqstRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement, and by the SME when accepting a measurement request. The Row Status column of the current row, used for tracking status of an 2887 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications individual request. When this attribute is set to Active, AND a measurement request can be unambiguously created based on the parameters in the row, then the MLME may proceed to issue the request to its intended targets when appropriate. If not, this attribute may be set to Not-ready immediately to indicate parametric errors. However, it is the network managers responsibility to correct the error. If the request is successfully issued to the target STA, then the rowStatus is set to notInService." REFERENCE "9.4.2.21" ::= { dot11RMRequestEntry 2 } dot11RMRqstToken OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when the table entry is created, i.e., when requesting a measurement.. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute indicates a unique string to identify a group of rows to be issued as parallel or sequential measurements. To guarantee the uniqueness of this token across multiple network managers, it is recommended that this token be prefixed with the IP address of the network manager creating this row. This token is not necessarily equivalent to the measurement tokens in RM request frames. If this attribute is an empty string, then this row of request is independent from other requests." DEFVAL { "" } ::= { dot11RMRequestEntry 3 } dot11RMRqstRepetitions OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute indicates the requested number of repetitions for all of the Measurement Request elements in this frame. A value of 0 in the Number of Repetitions field indicates Measurement Request elements are executed once without repetition." ::= { dot11RMRequestEntry 4 } dot11RMRqstIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. The ifIndex on which this row of the RM Request is to be issued." ::= { dot11RMRequestEntry 5 } dot11RMRqstType OBJECT-TYPE SYNTAX INTEGER { channelLoad(3), noiseHistogram(4), 2888 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications beacon(5), frame(6), staStatistics(7), lci(8), transmitStream(9), pause(255) } MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute indicates the measurement type of this RM request row." ::= { dot11RMRequestEntry 6 } dot11RMRqstTargetAdd OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. The MAC address of STA for this row of RM Request is to be issued to. If this attribute matches the MAC address of the dot11RMRqstIfIndex, then measurement request is for this STA itself to carry out." ::= { dot11RMRequestEntry 7 } dot11RMRqstTimeStamp OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by the SME when dot11RMRqstRowStatus is set to Active. This attribute indicates the sysUpTime Value the last time when the dot11RMRqstRowStatus is set to active or when this row is created the first time." ::= { dot11RMRequestEntry 8 } dot11RMRqstChanNumber OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. The target STA channel number on which to perform the measurements indicated in this request. The Channel Number is defined only within the indicated Operating Class for this measurement request. This attribute is ignored if dot11RMRqstType = STA Statistics, LCI, Transmit Stream/Category Measurement, or Measurement Pause. However, even in that case, the manager should set this attribute to the current channel for this interface, so that the row can be set to active when ready with all attributes indicated." ::= { dot11RMRequestEntry 9 } 2889 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11RMRqstOperatingClass OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute indicates the channel set for this measurement request. Country, Operating Class and Channel Number together specify the channel frequency and spacing for this measurement request. Valid values of Operating Class are shown in Annex E." REFERENCE "Annex E" ::= { dot11RMRequestEntry 10 } dot11RMRqstRndInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "TUs" MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute indicates the upper bound of the random delay to be used prior to making the measurement. See 11.11.3. This attribute is ignored if dot11RMRqstType = STA Statistics, LCI, Transmit Stream/Category Measurement or Measurement Pause." DEFVAL { 0 } ::= { dot11RMRequestEntry 11 } dot11RMRqstDuration OBJECT-TYPE SYNTAX Unsigned32 UNITS "TUs" MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute indicates the preferred or mandatory measurement duration for this Measurement Request. This attribute is ignored if dot11RMRqstType = LCI or Measurement Pause." DEFVAL { 0 } ::= { dot11RMRequestEntry 12 } dot11RMRqstParallel OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute indicates the parallel bit for this Measurement Request 2890 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications element. This attribute, when false, indicates that the measurement is performed in sequence. This attribute, when true, indicates that this measurement should start at the same time as the measurement described by the next Measurement Request element in the next row if the next row indicates the same value for dot11RMRqstToken." DEFVAL { false } ::= { dot11RMRequestEntry 13 } dot11RMRqstEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute indicates the enable bit for this Measurement Request element." DEFVAL { false } ::= { dot11RMRequestEntry 14 } dot11RMRqstRequest OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute indicates the request bit for this Measurement Request element. This attribute, when true, indicates that this STA accepts measurement requests from the target STA." DEFVAL { false } ::= { dot11RMRequestEntry 15 } dot11RMRqstReport OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute indicates the report bit for this Measurement Request element. This attribute, when true, indicates that the target STA may enable autonomous measurement reports to the requesting STA." DEFVAL { false } ::= { dot11RMRequestEntry 16 } dot11RMRqstDurationMandatory OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. 2891 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This attribute indicates the duration mandatory bit for this Measurement Request element. This attribute, when true, indicates that the indicated Measurement Duration is a mandatory duration for this measurement. This attribute, when false, indicates that the indicated Measurement Duration is a maximum duration for this measurement." DEFVAL { false } ::= { dot11RMRequestEntry 17 } dot11RMRqstBeaconRqstMode OBJECT-TYPE SYNTAX INTEGER { passive(0), active(1), beaconTable(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute indicates the Measurement Mode for this Beacon request. This attribute is valid only if the dot11RMRqstType is 5, indicating a Beacon request, and is ignored otherwise." DEFVAL { 0 } ::= { dot11RMRequestEntry 18 } dot11RMRqstBeaconRqstDetail OBJECT-TYPE SYNTAX INTEGER { noBody(0), fixedFieldsAndRequestedElements(1), allBody(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. dot11RMRqstBeaconRqstDetail indicates the Reporting Detail for Beacon request. This attribute is valid only if the dot11RMRqstType is 5, indicating a Beacon request, and is ignored otherwise." DEFVAL { 2 } ::= { dot11RMRequestEntry 19 } dot11RMRqstFrameRqstType OBJECT-TYPE SYNTAX INTEGER { frameCountRep(1) } MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. dot11RMRqstFrameRqstType indicates the Frame Request Type for the Frame request. This attribute is valid only if the dot11RMRqstType is 6, indicating a Frame request, and is ignored otherwise." DEFVAL { 1 } ::= { dot11RMRequestEntry 20 } dot11RMRqstBssid OBJECT-TYPE 2892 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications SYNTAX MacAddress MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. BSSID indicates the BSSID of the particular AP for which this measurement is requested. The BSSID is set to the wildcard BSSID when the measurement is to be performed on any AP(s) on the indicated channel. This attribute is valid only if the dot11RMRqstType is 5, indicating a Beacon request, and is ignored otherwise." DEFVAL { 'FFFFFFFFFFFF'H } ::= { dot11RMRequestEntry 21 } dot11RMRqstSSID OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute indicates the SSID for the measurement. Zero-length MIB element for SSID indicates the wildcard SSID. The SSID is set to the wildcard SSID when the measurement is to be performed on all ESSs/IBSSs on the indicated channel. This attribute is valid only if the dot11RMRqstType is 5, indicating a Beacon request, and is ignored otherwise." DEFVAL { ''H } ::= { dot11RMRequestEntry 22 } dot11RMRqstBeaconReportingCondition OBJECT-TYPE SYNTAX INTEGER { afterEveryMeasurement(0), rcpiAboveAbsoluteThreshold(1), rcpiBelowAbsoluteThreshold(2), rsniAboveAbsoluteThreshold(3), rsniBelowAbsoluteThreshold(4), rcpiAboveOffsetThreshold(5), rcpiBelowOffsetThreshold(6), rsniAboveOffsetThreshold(7), rsniBelowOffsetThreshold(8), rcpiInBound(9), rsniInBound(10) } MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute indicates when the Beacon Measurement results are to be reported to the requesting STA. This attribute is valid only if the dot11RMRqstType is 5, indicating a Beacon request, and is ignored otherwise." REFERENCE "IEEE Std 802.11, Table 9-89-Reporting Condition values for Beacon request" DEFVAL {0} ::= { dot11RMRequestEntry 23 } 2893 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11RMRqstBeaconThresholdOffset OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. Threshold/Offset provides either the threshold value or the offset value to be used for conditional reporting. For indicated reporting conditions 1-4, the integer range is (0..255). For indicated reporting conditions 5- 10, the integer range is (-127..+127). This attribute is valid only if the dot11RMRqstType is 5, indicating a Beacon request, and is ignored otherwise." DEFVAL { 0 } ::= { dot11RMRequestEntry 24 } dot11RMRqstSTAStatRqstGroupID OBJECT-TYPE SYNTAX INTEGER { dot11CountersTable(0), dot11MacStatistics(1), dot11QosCountersTableforUP0(2), dot11QosCountersTableforUP1(3), dot11QosCountersTableforUP2(4), dot11QosCountersTableforUP3(5), dot11QosCountersTableforUP4(6), dot11QosCountersTableforUP5(7), dot11QosCountersTableforUP6(8), dot11QosCountersTableforUP7(9), bSSAverageAccessDelays(10), dot11CountersGroup3Tablefor31(11), dot11CountersGroup3Tablefor32(12), dot11CountersGroup3Tablefor33(13), dot11CountersGroup3Tablefor34(14), dot11CountersGroup3Tablefor35(15), dot11RSNAStatsTable(16)} MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. The attribute indicates the group identity for this Measurement Request element. This attribute is valid only if the dot11RMRqstType is 7, indicating a STA statistics request, and is ignored otherwise." DEFVAL { 0 } ::= { dot11RMRequestEntry 25 } dot11RMRqstLCIRqstSubject OBJECT-TYPE SYNTAX INTEGER { local(0), remote(1) } MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. The attribute indicates the subject of the LCI request. This attribute is 2894 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications valid only if the dot11RMRqstType is 8, indicating an LCI request, and is ignored otherwise." DEFVAL { 0 } ::= { dot11RMRequestEntry 26 } -- 27 to 29 are reserved dot11RMRqstLCIAzimuthType OBJECT-TYPE SYNTAX INTEGER { frontSurfaceofSta(0), radioBeam(1) } MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute indicates the azimuth reference for the LCI Azimuth measurement request. This attribute is valid only if the dot11RMRqstType is 8, indicating an LCI request, and is ignored otherwise." DEFVAL{ 0 } ::= { dot11RMRequestEntry 30 } dot11RMRqstLCIAzimuthResolution OBJECT-TYPE SYNTAX Unsigned32 (0..15) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute is 4 bits indicating the number of valid bits in the fixed-point value of Azimuth of the LCI Azimuth measurement request. This attribute is valid only if the dot11RMRqstType is 8, indicating an LCI request, and is ignored otherwise." ::= { dot11RMRequestEntry 31 } dot11RMRqstPauseTime OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "10 TUs" MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute indicates the time period for which measurements are suspended or paused. Measurement Pause requests are used to provide time delays between the execution times of measurement request elements in a Measurement Request frame. This attribute is valid only if the dot11RMRqstType is 255, indicating an pause request, and is ignored otherwise." DEFVAL { 0 } ::= { dot11RMRequestEntry 32 } dot11RMRqstTransmitStreamPeerQSTAAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-create STATUS current DESCRIPTION 2895 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute indicates the peer STA address to be measured for a Transmit Stream/Category Measurement measurement. This attribute is valid only if the dot11RMRqstType is 9, indicating a transmit stream/category request, and is ignored otherwise." ::= { dot11RMRequestEntry 33 } dot11RMRqstTransmitStreamTrafficIdentifier OBJECT-TYPE SYNTAX Unsigned32(0..16) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute indicates the TC, or TS to be measured for a Transmit Stream/Category Measurement measurement. This attribute is valid only if the dot11RMRqstType is 9, indicating a transmit stream/category request, and is ignored otherwise." ::= { dot11RMRequestEntry 34 } dot11RMRqstTransmitStreamBin0Range OBJECT-TYPE SYNTAX Unsigned32(1..255) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute indicates the delay range for bin 0 of the transmit delay histogram. This attribute is valid only if the dot11RMRqstType is 9, indicating a transmit stream/category request, and is ignored otherwise." ::= { dot11RMRequestEntry 35 } dot11RMRqstTrigdQoSAverageCondition OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute, when true, indicates a request for triggered reporting with trigger based on the number of discarded MSDUs reaching the dot11RMRqstTrigdQoSAverageThreshold when averaged over dot11RMRqstTrigdQoSMeasurementCount consecutive MSDUs. This attribute is valid only if the dot11RMRqstType is 9, indicating a transmit stream/ category request, and is ignored otherwise." DEFVAL { false } ::= { dot11RMRequestEntry 36 } dot11RMRqstTrigdQoSConsecutiveCondition OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create 2896 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute, when true, indicates a request for triggered reporting with trigger based on the consecutive number of MSDUs discarded reaching dot11RMRqstTrigdQoSConsecutiveThreshold. This attribute is valid only if the dot11RMRqstType is 9, indicating a transmit stream/category request, and is ignored otherwise." DEFVAL { false } ::= { dot11RMRequestEntry 37 } dot11RMRqstTrigdQoSDelayCondition OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute, when true, indicates a request for triggered reporting with trigger based on the consecutive number of MSDUs that experience a transmit delay greater than dot11RMRqstTrigdQoSDelayThresholdRange reaching dot11RMRqstTrigdQoSDelayThreshold. This attribute is valid only if the dot11RMRqstType is 9, indicating a transmit stream/category request, and is ignored otherwise." DEFVAL { false } ::= { dot11RMRequestEntry 38 } dot11RMRqstTrigdQoSAverageThreshold OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute indicates the trigger threshold for triggered Transmit Stream/Category Measurement based on average MSDUs discarded. Trigger occurs if the number of MSDUs discarded over the moving average number of transmitted MSDUs in dot11RMRqstTrigdQoSMeasurementCount reaches this threshold. This attribute is valid only if the dot11RMRqstType is 9, indicating a transmit stream/category request, and is ignored otherwise." DEFVAL { 10 } ::= { dot11RMRequestEntry 39 } dot11RMRqstTrigdQoSConsecutiveThreshold OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute indicates the trigger threshold for triggered Transmit 2897 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Stream/Category Measurement based on consecutive MSDUs discarded. Trigger occurs if the consecutive number of MSDUs discarded reaches this threshold. This attribute is valid only if the dot11RMRqstType is 9, indicating a transmit stream/category request, and is ignored otherwise." DEFVAL { 5 } ::= { dot11RMRequestEntry 40 } dot11RMRqstTrigdQoSDelayThresholdRange OBJECT-TYPE SYNTAX Unsigned32 (0..3) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute indicates the minimum transmit delay for delayed MSDU counts. Trigger occurs if the a consecutive number of MSDUs experience a transmit delay greater than or equal to the lower bound of the bin of the Transmit Delay Histogram given by the value of this attribute + 2, e.g.,if this attribute is 1 the lower bound of bin 3. This attribute is valid only if the dot11RMRqstType is 9, indicating a transmit stream/category request, and is ignored otherwise." DEFVAL { 1 } ::= { dot11RMRequestEntry 41 } dot11RMRqstTrigdQoSDelayThreshold OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute indicates the number of consecutive delayed MSDUs needed for trigger. Trigger occurs if the consecutive number of MSDUs that experience a transmit delay greater than dot11RMRqstTrigdQoSDelayThresholdRange reaches this value. This attribute is valid only if the dot11RMRqstType is 9, indicating a transmit stream/ category request, and is ignored otherwise." DEFVAL { 20 } ::= { dot11RMRequestEntry 42 } dot11RMRqstTrigdQoSMeasurementCount OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute indicates the number of MSDUs to be used as a moving average count in the average error threshold and in determining the scope of the reported Transmit Stream/Category measurement in a triggered measurement report. This attribute is valid only if the dot11RMRqstType is 9, indicating a transmit stream/category request, and is ignored otherwise." DEFVAL { 100 } ::= { dot11RMRequestEntry 43 } 2898 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11RMRqstTrigdQoSTimeout OBJECT-TYPE SYNTAX Unsigned32 (1..255) UNITS "100 TUs" MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute indicates the timeout interval during which a measuring STA does not generate further triggered Transmit Stream/Category measurement reports after a trigger condition has been met and a report generated. This attribute is valid only if the dot11RMRqstType is 9, indicating a transmit stream/category request, and is ignored otherwise." DEFVAL { 20 } ::= { dot11RMRequestEntry 44 } dot11RMRqstChannelLoadReportingCondition OBJECT-TYPE SYNTAX INTEGER { afterEveryMeasurement(0), chanLoadAboveReference(1), chanLoadBelowReference(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute indicates when the Channel Load Measurement results are to be reported to the requesting STA. This attribute is valid only if the dot11RMRqstType is 3, indicating a Channel Load request, and is ignored otherwise." REFERENCE "IEEE Std 802.11, Table 9-84" DEFVAL {0} ::= { dot11RMRequestEntry 45 } dot11RMRqstChannelLoadReference OBJECT-TYPE SYNTAX Unsigned32 (0..255) UNITS "1/255" MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute indicates the channel load reporting condition reference value. The measured Channel Load is compared to this reference value and a report is issued if the reporting condition is satisfied. The reference value is in the same units as Channel Load and represents the fractional time of the measurement duration during which the STA determined the channel to be busy. This attribute is valid only if the dot11RMRqstType is 3, indicating a Channel Load request, and is ignored otherwise." DEFVAL { 5 } ::= { dot11RMRequestEntry 46 } dot11RMRqstNoiseHistogramReportingCondition OBJECT-TYPE 2899 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications SYNTAX INTEGER { afterEveryMeasurement(0), aNPIAboveReference(1), aNPIBelowReference(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute indicates when the Noise Histogram Measurement results are to be reported to the requesting STA. This attribute is valid only if the dot11RMRqstType is 4, indicating a Noise Histogram request, and is ignored otherwise." REFERENCE "IEEE Std 802.11, Table 9-86-Reporting Condition for Noise Histogram report" DEFVAL {0} ::= { dot11RMRequestEntry 47 } dot11RMRqstAnpiReference OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute indicates the noise histogram reporting condition ANPI reference value. The measured ANPI is compared to this reference value and a report is issued if the indicated reporting condition is satisfied. ANPIval = Floor((ANPIpower in dBm + 110)*2), for ANPI in the range -110 dBm to 0 dBm. ANPIval = 220 for ANPI > 0 dBm. ANPIval = 255 when ANPI is not available. This attribute is valid only if the dot11RMRqstType is 4, indicating a Noise Histogram request, and is ignored otherwise." DEFVAL { 5 } ::= { dot11RMRequestEntry 48 } dot11RMRqstAPChannelReport OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute indicates the specific channels to be used for the requested beacon measurements. The default value is null. Each octet indicates a different channel within the indicated Operating Class. This list of channels is the Channel List in the AP Channel Report element described in 9.4.2.36. This attribute is valid only if the dot11RMRqstType is 5, indicating a Beacon request, and is ignored otherwise." DEFVAL { ''H } ::= { dot11RMRequestEntry 49 } dot11RMRqstSTAStatPeerSTAAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-create STATUS current 2900 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute indicates the peer STA address to be measured for a STA statistics request. This attribute is valid only if the dot11RMRqstType is 7, indicating a statistics request, and is ignored otherwise." ::= { dot11RMRequestEntry 50 } dot11RMRqstFrameTransmitterAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute indicates the Transmitter Address (TA) of the frames to be counted in this Frame request. This attribute is valid only if the dot11RMRqstType is 6, indicating a Frame request, and is ignored otherwise." ::= { dot11RMRequestEntry 51 } dot11RMRqstVendorSpecific OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute provides an envelope for any optional vendor specific subelements which may be included in a Measurement Request element. The default value is null. This attribute is valid for all requests." DEFVAL { ''H } ::= { dot11RMRequestEntry 52 } dot11RMRqstSTAStatTrigMeasCount OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute indicates the number of MSDUs or MPDUs over which the trigger criterion is applied. This attribute is valid only if dot11RMRqstType is 7 (STA Statistics) and if the value of the attribute is not equal to 0." DEFVAL { 0 } ::= { dot11RMRequestEntry 53 } dot11RMRqstSTAStatTrigTimeout OBJECT-TYPE SYNTAX Unsigned32(0..65535) UNITS "100 TUs" MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute indicates the interval during which a measuring STA does not generate further triggered STA Statistics reports after a trigger condition has been met. This attribute is valid only if dot11RMRqstType is 2901 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 7 (STA Statistics)." DEFVAL { 0 } ::= { dot11RMRequestEntry 54 } dot11RMRqstSTAStatTrigCondition OBJECT-TYPE SYNTAX OCTET STRING (SIZE(2)) MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute indicates the trigger values used when requesting triggered STA Statistics reporting. The format of the STA Counter Trigger Condition field is shown in Figure 9-161." ::= { dot11RMRequestEntry 55 } dot11RMRqstSTAStatTrigSTAFailedCntThresh OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute indicates that a STA Statistics report should be generated (triggered) when the dot11FailedCount value has increased more than the threshold value indicated here. The counter increase is measured over the last n MSDUs or MPDUs, where n is the value of dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if dot11RMRqstType is 7 (STA Statistics), and if dot11RMRqstSTAStatRqstGroupID is 0 (dot11CountersTable) and if the value of the attribute is not equal to 0." DEFVAL { 0 } ::= { dot11RMRequestEntry 56 } dot11RMRqstSTAStatTrigSTAFCSErrCntThresh OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute indicates that a STA Statistics report should be generated (triggered) when the dot11FCSErrorCount value has increased more than the threshold value indicated here. The counter increase is measured over the last n MSDUs or MPDUs, where n is the value of dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if dot11RMRqstType is 7 (STA Statistics), and if dot11RMRqstSTAStatRqstGroupID is 0 (dot11CountersTable) and if the value of the attribute is not equal to 0." DEFVAL { 0 } ::= { dot11RMRequestEntry 57 } dot11RMRqstSTAStatTrigSTAMultRetryCntThresh OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute indicates that a STA Statistics report should be generated (triggered) when the dot11MultipleRetryCount value has increased more than the threshold value indicated here. The counter increase is measured over the last n MSDUs or MPDUs, where n is the value of dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if dot11RMRqstType is 7 (STA Statistics), and if dot11RMRqstSTAStatRqstGroupID is 0 (dot11CountersTable) and if the value of the attribute is not equal to 0." DEFVAL { 0 } ::= { dot11RMRequestEntry 58 } dot11RMRqstSTAStatTrigSTAFrameDupeCntThresh OBJECT-TYPE 2902 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute indicates that a STA Statistics report should be generated (triggered) when the dot11FrameDuplicateCount value has increased more than the threshold value indicated here. The counter increase is measured over the last n MSDUs or MPDUs, where n is the value of dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if dot11RMRqstType is 7 (STA Statistics), and if dot11RMRqstSTAStatRqstGroupID is 0 (dot11CountersTable) and if the value of the attribute is not equal to 0." DEFVAL { 0 } ::= { dot11RMRequestEntry 59 } dot11RMRqstSTAStatTrigSTARTSFailCntThresh OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute indicates that a STA Statistics report should be generated (triggered) when the dot11RTSFailureCount value has increased more than the threshold value indicated here. The counter increase is measured over the last n MSDUs or MPDUs, where n is the value of dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if dot11RMRqstType is 7 (STA Statistics), and if dot11RMRqstSTAStatRqstGroupID is 0 (dot11CountersTable) and if the value of the attribute is not equal to 0." DEFVAL { 0 } ::= { dot11RMRequestEntry 60 } dot11RMRqstSTAStatTrigSTAAckFailCntThresh OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute indicates that a STA Statistics report should be generated (triggered) when the dot11AckFailureCount value has increased more than the threshold value indicated here. The counter increase is measured over the last n MSDUs or MPDUs, where n is the value of dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if dot11RMRqstType is 7 (STA Statistics), and if dot11RMRqstSTAStatRqstGroupID is 0 (dot11CountersTable) and if the value of the attribute is not equal to 0." DEFVAL { 0 } ::= { dot11RMRequestEntry 61 } dot11RMRqstSTAStatTrigSTARetryCntThresh OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute indicates that a STA Statistics report should be generated (triggered) when the dot11RetryCount value has increased more than the threshold value indicated here. The counter increase is measured over the last n MSDUs or MPDUs, where n is the value of dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if dot11RMRqstType is 7 (STA Statistics), and if dot11RMRqstSTAStatRqstGroupID is 0 (dot11CountersTable) and if the value of the attribute is not equal to 0." DEFVAL { 0 } ::= { dot11RMRequestEntry 62 } dot11RMRqstSTAStatTrigQoSTrigCondition OBJECT-TYPE 2903 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications SYNTAX OCTET STRING (SIZE(2)) MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute indicates the trigger values used when requesting triggered QoS STA Statistics reporting. The format of the STA Counter Trigger Condition field is shown in Figure 9-163." ::= { dot11RMRequestEntry 63 } dot11RMRqstSTAStatTrigQoSFailedCntThresh OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute indicates that a STA Statistics report should be generated (triggered) when the dot11QosFailedCount value has increased more than the threshold value indicated here. The counter increase is measured over the last n MSDUs or MPDUs, where n is the value of dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if dot11RMRqstType is 7 (STA Statistics), and if dot11RMRqstSTAStatRqstGroupID is 2 to 9 (dot11QosCountersTable) and if the value of the attribute is not equal to 0." DEFVAL { 0 } ::= { dot11RMRequestEntry 64 } dot11RMRqstSTAStatTrigQoSRetryCntThresh OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute indicates that a STA Statistics report should be generated (triggered) when the dot11QosRetryCount value has increased more than the threshold value indicated here. The counter increase is measured over the last n MSDUs or MPDUs, where n is the value of dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if dot11RMRqstType is 7 (STA Statistics), and if dot11RMRqstSTAStatRqstGroupID is 2 to 9 (dot11QosCountersTable) and if the value of the attribute is not equal to 0." DEFVAL { 0 } ::= { dot11RMRequestEntry 65 } dot11RMRqstSTAStatTrigQoSMultRetryCntThresh OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute indicates that a STA Statistics report should be generated (triggered) when the dot11QosMultipleRetryCount value has increased more than the threshold value indicated here. The counter increase is measured over the last n MSDUs or MPDUs, where n is the value of dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if dot11RMRqstType is 7 (STA Statistics), and if dot11RMRqstSTAStatRqstGroupID is 2 to 9 (dot11QosCountersTable) and if the value of the attribute is not equal to 0." DEFVAL { 0 } ::= { dot11RMRequestEntry 66 } dot11RMRqstSTAStatTrigQoSFrameDupeCntThresh OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute indicates that a STA Statistics report should be generated 2904 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications (triggered) when the dot11QosFrameDuplicateCount value has increased more than the threshold value indicated here. The counter increase is measured over the last n MSDUs or MPDUs, where n is the value of dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if dot11RMRqstType is 7 (STA Statistics), and if dot11RMRqstSTAStatRqstGroupID is 2 to 9 (dot11QosCountersTable) and if the value of the attribute is not equal to 0." DEFVAL { 0 } ::= { dot11RMRequestEntry 67 } dot11RMRqstSTAStatTrigQoSRTSFailCntThresh OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute indicates that a STA Statistics report should be generated (triggered) when the dot11QosRTSFailureCount value has increased more than the threshold value indicated here. The counter increase is measured over the last n MSDUs or MPDUs, where n is the value of dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if dot11RMRqstType is 7 (STA Statistics), and if dot11RMRqstSTAStatRqstGroupID is 2 to 9 (dot11QosCountersTable) and if the value of the attribute is not equal to 0." DEFVAL { 0 } ::= { dot11RMRequestEntry 68 } dot11RMRqstSTAStatTrigQoSAckFailCntThresh OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute indicates that a STA Statistics report should be generated (triggered) when the dot11QosAckFailureCount value has increased more than the threshold value indicated here. The counter increase is measured over the last n MSDUs or MPDUs, where n is the value of dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if dot11RMRqstType is 7 (STA Statistics), and if dot11RMRqstSTAStatRqstGroupID is 2 to 9 (dot11QosCountersTable) and if the value of the attribute is not equal to 0." DEFVAL { 0 } ::= { dot11RMRequestEntry 69 } dot11RMRqstSTAStatTrigQoSDiscardCntThresh OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute indicates that a STA Statistics report should be generated (triggered) when the dot11QosDiscardedFrameCount value has increased more than the threshold value indicated here. The counter increase is measured over the last n MSDUs or MPDUs, where n is the value of dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if dot11RMRqstType is 7 (STA Statistics), and if dot11RMRqstSTAStatRqstGroupID is 2 to 9 (dot11QosCountersTable) and if the value of the attribute is not equal to 0." DEFVAL { 0 } ::= { dot11RMRequestEntry 70 } dot11RMRqstSTAStatTrigRsnaTrigCondition OBJECT-TYPE SYNTAX OCTET STRING (SIZE(2)) MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute indicates the trigger values used when requesting 2905 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications triggered RSNA STA Statistics reporting. The format of the STA Counter Trigger Condition field is shown in Figure 9-165." ::= { dot11RMRequestEntry 71 } dot11RMRqstSTAStatTrigRsnaCMACICVErrCntThresh OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute indicates that a STA Statistics report should be generated (triggered) when the dot11RSNAStatsBIPMICErrors value has increased more than the threshold value indicated here. The counter increase is measured over the last n MSDUs or MPDUs, where n is the value of dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if dot11RMRqstType is 7 (STA Statistics), and if dot11RMRqstSTAStatRqstGroupID is 16 (dot11RSNAStatsTable) and if the value of the attribute is not equal to 0." DEFVAL { 0 } ::= { dot11RMRequestEntry 72 } dot11RMRqstSTAStatTrigRsnaCMACReplayCntThresh OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute indicates that a STA Statistics report should be generated (triggered) when the dot11RSNAStatsCMACReplays value has increased more than the threshold value indicated here. The counter increase is measured over the last n MSDUs or MPDUs, where n is the value of dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if dot11RMRqstType is 7 (STA Statistics), and if dot11RMRqstSTAStatRqstGroupID is 16 (dot11RSNAStatsTable) and if the value of the attribute is not equal to 0." DEFVAL { 0 } ::= { dot11RMRequestEntry 73 } dot11RMRqstSTAStatTrigRsnaRobustCCMPReplayCntThresh OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute indicates that a STA Statistics report should be generated (triggered) when the dot11RSNAStatsRobustMgmtCCMPReplays value has increased more than the threshold value indicated here. The counter increase is measured over the last n MSDUs or MPDUs, where n is the value of dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if dot11RMRqstType is 7 (STA Statistics), and if dot11RMRqstSTAStatRqstGroupID is 16 (dot11RSNAStatsTable) and if the value of the attribute is not equal to 0." DEFVAL { 0 } ::= { dot11RMRequestEntry 74 } dot11RMRqstSTAStatTrigRsnaTKIPICVErrCntThresh OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute indicates that a STA Statistics report should be generated (triggered) when the dot11RSNAStatsTKIPICVErrors value has increased more than the threshold value indicated here. The counter increase is measured over the last n MSDUs or MPDUs, where n is the value of dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if dot11RMRqstType is 7 (STA Statistics), and if 2906 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11RMRqstSTAStatRqstGroupID is 16 (dot11RSNAStatsTable) and if the value of the attribute is not equal to 0." DEFVAL { 0 } ::= { dot11RMRequestEntry 75 } dot11RMRqstSTAStatTrigRsnaTKIPReplayCntThresh OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute indicates that a STA Statistics report should be generated (triggered) when the dot11RSNAStatsTKIPReplays value has increased more than the threshold value indicated here. The counter increase is measured over the last n MSDUs or MPDUs, where n is the value of dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if dot11RMRqstType is 7 (STA Statistics), and if dot11RMRqstSTAStatRqstGroupID is 16 (dot11RSNAStatsTable) and if the value of the attribute is not equal to 0." DEFVAL { 0 } ::= { dot11RMRequestEntry 76 } dot11RMRqstSTAStatTrigRsnaCCMPDecryptErrCntThresh OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute indicates that a STA Statistics report should be generated (triggered) when the dot11RSNAStatsCCMPDecryptErrors value has increased more than the threshold value indicated here. The counter increase is measured over the last n MSDUs or MPDUs, where n is the value of dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if dot11RMRqstType is 7 (STA Statistics), and if dot11RMRqstSTAStatRqstGroupID is 16 (dot11RSNAStatsTable) and if the value of the attribute is not equal to 0." DEFVAL { 0 } ::= { dot11RMRequestEntry 77 } dot11RMRqstSTAStatTrigRsnaCCMPReplayCntThresh OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute indicates that a STA Statistics report should be generated (triggered) when the dot11RSNAStatsCCMPReplays value has increased more than the threshold value indicated here. The counter increase is measured over the last n MSDUs or MPDUs, where n is the value of dot11RMRqstSTAStatTrigMeasCount. This attribute is valid only if dot11RMRqstType is 7 (STA Statistics), and if dot11RMRqstSTAStatRqstGroupID is 16 (dot11RSNAStatsTable) and if the value of the attribute is not equal to 0." DEFVAL { 0 } ::= { dot11RMRequestEntry 78 } -- ********************************************************************** -- * End of dot11RMRequest TABLE -- ********************************************************************** -- ******************************************************************** -- * Radio Measurement Reports -- * Report tables contain measurement reports received by this STA or -- * results of measurements performed by this STA. -- ******************************************************************** dot11RMReport OBJECT IDENTIFIER ::= { dot11RadioMeasurement 2 } 2907 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications -- ******************************************************************** -- * dot11ChannelLoadReport TABLE -- ******************************************************************** dot11ChannelLoadReportTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11ChannelLoadReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the current list of Channel Load reports that have been received by the MLME. The report tables are maintained as a FIFO to preserve freshness, thus the rows in this table can be deleted for memory constraints or other implementation constraints determined by the vendor. New rows have different RprtIndex values than those deleted within the range limitation of the index. One easy way is to increment RprtIndex for new reports being written in the table." ::= { dot11RMReport 1 } dot11ChannelLoadReportEntry OBJECT-TYPE SYNTAX Dot11ChannelLoadReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11ChannelLoadReportTable Indexed by dot11ChannelLoadRprtIndex." INDEX { dot11ChannelLoadRprtIndex } ::= { dot11ChannelLoadReportTable 1 } Dot11ChannelLoadReportEntry ::= SEQUENCE { dot11ChannelLoadRprtIndex Unsigned32, dot11ChannelLoadRprtRqstToken OCTET STRING, dot11ChannelLoadRprtIfIndex InterfaceIndex, dot11ChannelLoadMeasuringSTAAddr MacAddress, dot11ChannelLoadRprtChanNumber Unsigned32, dot11ChannelLoadRprtOperatingClass Unsigned32, dot11ChannelLoadRprtActualStartTime TSFType, dot11ChannelLoadRprtMeasurementDuration Unsigned32, dot11ChannelLoadRprtChannelLoad Unsigned32, dot11ChannelLoadRprtVendorSpecific OCTET STRING, dot11ChannelLoadRprtMeasurementMode INTEGER } dot11ChannelLoadRprtIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index for Channel Load report elements in dot11ChannelLoadReportTable, greater than 0." ::= { dot11ChannelLoadReportEntry 1 } dot11ChannelLoadRprtRqstToken OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the request token that was indicated in the Measurement request that generated this measurement report. This should be an exact match to the original dot11RMRqstToken attribute. Note that there may be multiple entries in the table that match this value since a single request may generate multiple measurement reports." ::= { dot11ChannelLoadReportEntry 2 } 2908 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11ChannelLoadRprtIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. The ifIndex of the interface over which this ChannelLoad Report was received." ::= { dot11ChannelLoadReportEntry 3 } dot11ChannelLoadMeasuringSTAAddr OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. The MAC address of the measuring STA for this row of the Channel Load report." ::= { dot11ChannelLoadReportEntry 4 } dot11ChannelLoadRprtChanNumber OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the channel number used for this Channel Load report. The Channel Number is defined only within the indicated Operating Class for this measurement report." ::= { dot11ChannelLoadReportEntry 5 } dot11ChannelLoadRprtOperatingClass OBJECT-TYPE SYNTAX Unsigned32(1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the channel set for this measurement report. Country, Operating Class and Channel Number together specify the channel frequency and spacing for this measurement report. Valid values of Operating Class are shown in Annex E." REFERENCE "Annex E" ::= { dot11ChannelLoadReportEntry 6 } dot11ChannelLoadRprtActualStartTime OBJECT-TYPE SYNTAX TSFType MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the TSF value at the time when the measurement started." ::= { dot11ChannelLoadReportEntry 7 } 2909 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11ChannelLoadRprtMeasurementDuration OBJECT-TYPE SYNTAX Unsigned32 UNITS "TUs" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the duration over which the ChannelLoad Report was measured." ::= { dot11ChannelLoadReportEntry 8 } dot11ChannelLoadRprtChannelLoad OBJECT-TYPE SYNTAX Unsigned32(0..255) UNITS "1/255" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. Channel Load contains the fractional duration over which the measuring STA determined the channel to be busy during the measurement duration." REFERENCE "9.4.2.22.5" ::= { dot11ChannelLoadReportEntry 9 } dot11ChannelLoadRprtVendorSpecific OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute provides an envelope for any optional vendor specific subelements which may be included in a measurement report element. The default value is null." DEFVAL { ''H } ::= { dot11ChannelLoadReportEntry 10 } dot11ChannelLoadRprtMeasurementMode OBJECT-TYPE SYNTAX INTEGER { success(0), incapableBit(1), refusedBit(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the outcome status for the measurement request which generated this measurement report; status is indicated using the following reason codes: 1 indicates this STA is incapable of generating the report, 2 indicates this STA is refusing to generate the report, 0 indicates the STA successfully carried out the measurement request." DEFVAL { 0 } ::= { dot11ChannelLoadReportEntry 11 } -- ******************************************************************** -- * End of dot11ChannelLoadReport TABLE 2910 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications -- ******************************************************************** -- ******************************************************************** -- * dot11NoiseHistogramReport TABLE -- ******************************************************************** dot11NoiseHistogramReportTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11NoiseHistogramReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the current list of Noise Histogram reports that have been received by the MLME. The report tables are maintained as a FIFO to preserve freshness, thus the rows in this table can be deleted for memory constraints or other implementation constraints determined by the vendor. New rows have different RprtIndex values than those deleted within the range limitation of the index. One easy way is to increment RprtIndex for new reports being written in the table." ::= { dot11RMReport 2 } dot11NoiseHistogramReportEntry OBJECT-TYPE SYNTAX Dot11NoiseHistogramReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11NoiseHistogramReportTable Indexed by dot11NoiseHistogramRprtIndex." INDEX { dot11NoiseHistogramRprtIndex } ::= { dot11NoiseHistogramReportTable 1 } Dot11NoiseHistogramReportEntry ::= SEQUENCE { dot11NoiseHistogramRprtIndex Unsigned32, dot11NoiseHistogramRprtRqstToken OCTET STRING, dot11NoiseHistogramRprtIfIndex InterfaceIndex, dot11NoiseHistogramMeasuringSTAAddr MacAddress, dot11NoiseHistogramRprtChanNumber Unsigned32, dot11NoiseHistogramRprtOperatingClass Unsigned32, dot11NoiseHistogramRprtActualStartTime TSFType, dot11NoiseHistogramRprtMeasurementDuration Unsigned32, dot11NoiseHistogramRprtAntennaID Unsigned32, dot11NoiseHistogramRprtANPI Unsigned32, dot11NoiseHistogramRprtIPIDensity0 Unsigned32, dot11NoiseHistogramRprtIPIDensity1 Unsigned32, dot11NoiseHistogramRprtIPIDensity2 Unsigned32, dot11NoiseHistogramRprtIPIDensity3 Unsigned32, dot11NoiseHistogramRprtIPIDensity4 Unsigned32, dot11NoiseHistogramRprtIPIDensity5 Unsigned32, dot11NoiseHistogramRprtIPIDensity6 Unsigned32, dot11NoiseHistogramRprtIPIDensity7 Unsigned32, dot11NoiseHistogramRprtIPIDensity8 Unsigned32, dot11NoiseHistogramRprtIPIDensity9 Unsigned32, dot11NoiseHistogramRprtIPIDensity10 Unsigned32, dot11NoiseHistogramRprtVendorSpecific OCTET STRING, dot11NoiseHistogramRprtMeasurementMode INTEGER} dot11NoiseHistogramRprtIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index for Noise Histogram elements in dot11NoiseHistogramReportTable, greater than 0." ::= { dot11NoiseHistogramReportEntry 1 } 2911 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11NoiseHistogramRprtRqstToken OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the request token that was indicated in the measurement request that generated this measurement report. This should be an exact match to the original dot11RMRqstToken attribute. Note that there may be multiple entries in the table that match this value since a single request may generate multiple measurement reports." ::= { dot11NoiseHistogramReportEntry 2 } dot11NoiseHistogramRprtIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. The ifIndex of the interface over which this Noise Histogram report was received. " ::= { dot11NoiseHistogramReportEntry 3 } dot11NoiseHistogramMeasuringSTAAddr OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. The MAC address of the measuring STA for this row of Noise Histogram report." ::= { dot11NoiseHistogramReportEntry 4 } dot11NoiseHistogramRprtChanNumber OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the channel number used for this Noise Histogram report. The Channel Number is defined only within the indicated Operating Class for this measurement report." ::= { dot11NoiseHistogramReportEntry 5 } dot11NoiseHistogramRprtOperatingClass OBJECT-TYPE SYNTAX Unsigned32(1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the channel set for this measurement report. Country, Operating Class and Channel Number together specify the channel frequency and spacing for this measurement report. Valid values of Operating Class are shown in Annex E." 2912 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications REFERENCE "Annex E" ::= { dot11NoiseHistogramReportEntry 6 } dot11NoiseHistogramRprtActualStartTime OBJECT-TYPE SYNTAX TSFType MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the TSF value at the time when the measurement started." ::= { dot11NoiseHistogramReportEntry 7 } dot11NoiseHistogramRprtMeasurementDuration OBJECT-TYPE SYNTAX Unsigned32 UNITS "TUs" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the duration over which the Noise Histogram report was measured." ::= { dot11NoiseHistogramReportEntry 8 } dot11NoiseHistogramRprtAntennaID OBJECT-TYPE SYNTAX Unsigned32(0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the identifying number for the antenna used for this measurement. The value 0 indicates that the antenna identifier is unknown. The value 255 indicates that the measurement was made with multiple antennas or that the antenna ID is unknown. The value 1 is used for a STA with only one antenna. STAs with more than one antenna assign Antenna IDs to each antenna as consecutive, ascending numbers. Each Antenna ID number represents a unique antenna characterized by a fixed relative position, a fixed relative direction, and a peak gain for that position and direction." ::= { dot11NoiseHistogramReportEntry 9 } dot11NoiseHistogramRprtANPI OBJECT-TYPE SYNTAX Unsigned32(0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the Average Noise Power Indicator (ANPI) for this Noise Histogram measurement. The ANPI value represents the average noise plus interference power on the measured channel at the antenna connector during the measurement duration. To calculate ANPI, the STA measures and uses IPI in the indicated channel when NAV is equal to 0 (when virtual CS mechanism indicates idle channel) except during frame transmission or reception." ::= { dot11NoiseHistogramReportEntry 10 } 2913 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11NoiseHistogramRprtIPIDensity0 OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the measured IPI density for non-IEEE-802.11 signals with measured power satisfying the condition: Power <= -92 dBm." ::= { dot11NoiseHistogramReportEntry 11 } dot11NoiseHistogramRprtIPIDensity1 OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the measured IPI density for non-IEEE-802.11 signals with measured power satisfying the condition: -92 dBm < Power <= - 9 dBm." ::= { dot11NoiseHistogramReportEntry 12 } dot11NoiseHistogramRprtIPIDensity2 OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the measured IPI density for non-IEEE-802.11 signals with measured power satisfying the condition: -89 dBm < Power <= - 86 dBm." ::= { dot11NoiseHistogramReportEntry 13 } dot11NoiseHistogramRprtIPIDensity3 OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the measured IPI density for non-IEEE-802.11 signals with measured power satisfying the condition: -86 dBm < Power <= - 83 dBm." ::= { dot11NoiseHistogramReportEntry 14 } dot11NoiseHistogramRprtIPIDensity4 OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the measured IPI density for non-IEEE-802.11 signals with measured power satisfying the condition: -83 dBm < Power <= - 80 dBm." ::= { dot11NoiseHistogramReportEntry 15 } 2914 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11NoiseHistogramRprtIPIDensity5 OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the measured IPI density for non-IEEE-802.11 signals with measured power satisfying the condition: -80 dBm < Power <= - 75 dBm." ::= { dot11NoiseHistogramReportEntry 16 } dot11NoiseHistogramRprtIPIDensity6 OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the measured IPI density for non-IEEE-802.11 signals with measured power satisfying the condition: -75 dBm < Power <= -70 dBm." ::= { dot11NoiseHistogramReportEntry 17 } dot11NoiseHistogramRprtIPIDensity7 OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the measured IPI density for non-IEEE-802.11 signals with measured power satisfying the condition: -70 dBm < Power <= -65 dBm." ::= { dot11NoiseHistogramReportEntry 18 } dot11NoiseHistogramRprtIPIDensity8 OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the measured IPI density for non-IEEE-802.11 signals with measured power satisfying the condition: -65 dBm < Power <= -60 dBm." ::= { dot11NoiseHistogramReportEntry 19 } dot11NoiseHistogramRprtIPIDensity9 OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the measured IPI density for non-IEEE-802.11 signals with measured power satisfying the condition: -60 dBm < Power <= -55 dBm." ::= { dot11NoiseHistogramReportEntry 20 } 2915 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11NoiseHistogramRprtIPIDensity10 OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the measured IPI density for non-IEEE-802.11 signals with measured power satisfying the condition: -55 dBm < Power." ::= { dot11NoiseHistogramReportEntry 21 } dot11NoiseHistogramRprtVendorSpecific OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute provides an envelope for any optional vendor specific subelements which may be included in a measurement report element. The default value is null." DEFVAL { ''H } ::= { dot11NoiseHistogramReportEntry 22 } dot11NoiseHistogramRprtMeasurementMode OBJECT-TYPE SYNTAX INTEGER { success(0), incapableBit(1), refusedBit(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the outcome status for the measurement request which generated this measurement report; status is indicated using the following reason codes: 1 indicates this STA is incapable of generating the report, 2 indicates this STA is refusing to generate the report, 0 indicates the STA successfully carried out the measurement request." DEFVAL { 0 } ::= { dot11NoiseHistogramReportEntry 23 } -- ******************************************************************** -- * End of dot11NoiseHistogramReport TABLE -- ******************************************************************** -- ******************************************************************** -- * dot11BeaconReport TABLE -- ******************************************************************** dot11BeaconReportTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11BeaconReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the current list of Beacon reports that have been received by the MLME. The report tables are maintained as FIFO to preserve freshness, thus the rows in this table can be deleted for memory constraints or other implementation constraints determined by the vendor. New rows have different RprtIndex values than those deleted within the 2916 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications range limitation of the index. One easy way is to increment RprtIndex for new reports being written in the table." ::= { dot11RMReport 3 } dot11BeaconReportEntry OBJECT-TYPE SYNTAX Dot11BeaconReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11BeaconReportTable Indexed by dot11BeaconRprtIndex." INDEX { dot11BeaconRprtIndex } ::= { dot11BeaconReportTable 1 } Dot11BeaconReportEntry ::= SEQUENCE { dot11BeaconRprtIndex Unsigned32, dot11BeaconRprtRqstToken OCTET STRING, dot11BeaconRprtIfIndex InterfaceIndex, dot11BeaconMeasuringSTAAddr MacAddress, dot11BeaconRprtChanNumber Unsigned32, dot11BeaconRprtOperatingClass Unsigned32, dot11BeaconRprtActualStartTime TSFType, dot11BeaconRprtMeasurementDuration Unsigned32, dot11BeaconRprtPhyType INTEGER, dot11BeaconRprtReportedFrameType INTEGER, dot11BeaconRprtRCPI Unsigned32, dot11BeaconRprtRSNI Unsigned32, dot11BeaconRprtBSSID MacAddress, dot11BeaconRprtAntennaID Unsigned32, dot11BeaconRprtParentTSF TSFType, dot11BeaconRprtReportedFrameBody OCTET STRING, dot11BeaconRprtVendorSpecific OCTET STRING, dot11BeaconRprtMeasurementMode INTEGER} dot11BeaconRprtIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index for Beacon reports in dot11BeaconReportTable, greater than 0." ::= { dot11BeaconReportEntry 1 } dot11BeaconRprtRqstToken OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the request token that was indicated in the measurement request that generated this measurement report. This should be an exact match to the original dot11RMRqstToken attribute. Note that there may be multiple entries in the table that match this value since a single request may generate multiple measurement reports." ::= { dot11BeaconReportEntry 2 } dot11BeaconRprtIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. 2917 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The ifIndex of the interface over which this Beacon report was received." ::= { dot11BeaconReportEntry 3 } dot11BeaconMeasuringSTAAddr OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. The MAC address of the measuring STA for this row of Beacon report." ::= { dot11BeaconReportEntry 4 } dot11BeaconRprtChanNumber OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the channel number used for this Beacon report. The Channel Number is defined only within the indicated Operating Class for this measurement report." ::= { dot11BeaconReportEntry 5 } dot11BeaconRprtOperatingClass OBJECT-TYPE SYNTAX Unsigned32(1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the channel set for this measurement report. Country, Operating Class and Channel Number together specify the channel frequency and spacing for this measurement report. Valid values of Operating Class are shown in Annex E." REFERENCE "Annex E" ::= { dot11BeaconReportEntry 6 } dot11BeaconRprtActualStartTime OBJECT-TYPE SYNTAX TSFType MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the TSF value at the time when the measurement started." ::= { dot11BeaconReportEntry 7 } dot11BeaconRprtMeasurementDuration OBJECT-TYPE SYNTAX Unsigned32 UNITS "TUs" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. 2918 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This attribute indicates the duration over which the Beacon report was measured." ::= { dot11BeaconReportEntry 8 } dot11BeaconRprtPhyType OBJECT-TYPE SYNTAX INTEGER { dsss(2), ofdm(4), hrdsss(5), erp(6), ht(7), dmg(8), vht(9), tvht(10)} MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the PHY Type for this row of Beacon report." ::= { dot11BeaconReportEntry 9 } dot11BeaconRprtReportedFrameType OBJECT-TYPE SYNTAX INTEGER { beaconOrProbeResponse(0), measurementPilot(1) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the frame type reported in dot11BeaconRprtReportedFrameBody" ::= { dot11BeaconReportEntry 10 } dot11BeaconRprtRCPI OBJECT-TYPE SYNTAX Unsigned32(0..255) UNITS "dBm" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the received channel power of the beacon or Probe Response frame as defined 9.4.2.38. RCPIval = Floor((RCPIpower in dBm + 110)*2), for RCPI in the range -110 dBm to 0 dBm. RCPIval = 220 for RCPI > 0 dBm. RCPIval = 255 when RCPI is not available." ::= { dot11BeaconReportEntry 11 } dot11BeaconRprtRSNI OBJECT-TYPE SYNTAX Unsigned32(0..255) UNITS "dB" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the received signal-to-noise ratio of the beacon or Probe Response frame. RSNI is the received signal-to-noise plus interference ratio derived from the measured RCPI for the received frame and from the measured ANPI for the channel used to receive the frame. RSNI 2919 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications is calculated by the ratio of the received signal power (RCPI - ANPI) over the noise plus interference power (ANPI) where RSNI = [(ratio(dB) + 10) * 2], for ratios in the range -10 dB to +118 dB." ::= { dot11BeaconReportEntry 12 } dot11BeaconRprtBSSID OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the BSSID of the beacon for this row of Beacon report." ::= { dot11BeaconReportEntry 13 } dot11BeaconRprtAntennaID OBJECT-TYPE SYNTAX Unsigned32(0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the identifying number for the antenna used for this measurement. The value 0 indicates that the antenna identifier is unknown. The value 255 indicates that this measurement was made with multiple antennas. The value 1 is used for a STA with only one antenna. STAs with more than one antenna assign Antenna IDs to each antenna as consecutive, ascending numbers. Each Antenna ID number represents a unique antenna characterized by a fixed relative position, a fixed relative direction, and a peak gain for that position and direction." ::= { dot11BeaconReportEntry 14 } dot11BeaconRprtParentTSF OBJECT-TYPE SYNTAX TSFType MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the TSF value of the serving measuring STA's TSF value at the time the measuring STA received the Beacon or Probe Response frame." ::= { dot11BeaconReportEntry 15 } dot11BeaconRprtReportedFrameBody OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..100)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the fixed fields and elements from the frame body of the Beacon, Measurement Pilot or Probe Response frame being received. All reported TIM elements are truncated to 4 octets." ::= { dot11BeaconReportEntry 16 } dot11BeaconRprtVendorSpecific OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-create 2920 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute provides an envelope for any optional vendor specific subelements which may be included in a measurement report element. The default value is null." DEFVAL { ''H } ::= { dot11BeaconReportEntry 17 } dot11BeaconRprtMeasurementMode OBJECT-TYPE SYNTAX INTEGER { success(0), incapableBit(1), refusedBit(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the outcome status for the measurement request which generated this measurement report; status is indicated using the following reason codes: 1 indicates this STA is incapable of generating the report, 2 indicates this STA is refusing to generate the report, 0 indicates the STA successfully carried out the measurement request." DEFVAL { 0 } ::= { dot11BeaconReportEntry 18 } -- ******************************************************************** -- * End of dot11BeaconReport TABLE -- ******************************************************************** -- ******************************************************************** -- * dot11FrameReport TABLE -- ******************************************************************** dot11FrameReportTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11FrameReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the current list of Frame reports that have been received by the MLME. The report tables are maintained as a FIFO to preserve freshness, thus the rows in this table can be deleted for memory constraints or other implementation constraints determined by the vendor. New rows have different RprtIndex values than those deleted within the range limitation of the index. One easy way is to increment RprtIndex for new reports being written in the table." ::= { dot11RMReport 4 } dot11FrameReportEntry OBJECT-TYPE SYNTAX Dot11FrameReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11FrameReportTable Indexed by dot11FrameRprtIndex." INDEX { dot11FrameRprtIndex } ::= { dot11FrameReportTable 1 } Dot11FrameReportEntry ::= SEQUENCE { dot11FrameRprtIndex Unsigned32, dot11FrameRprtIfIndex InterfaceIndex, 2921 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11FrameRprtRqstToken Unsigned32, dot11FrameRprtChanNumber Unsigned32, dot11FrameRprtOperatingClass Unsigned32, dot11FrameRprtActualStartTime TSFType, dot11FrameRprtMeasurementDuration Unsigned32, dot11FrameRprtTransmitSTAAddress MacAddress, dot11FrameRprtBSSID MacAddress, dot11FrameRprtPhyType INTEGER, dot11FrameRprtAvgRCPI Unsigned32, dot11FrameRprtLastRSNI Unsigned32, dot11FrameRprtLastRCPI Unsigned32, dot11FrameRprtAntennaID Unsigned32, dot11FrameRprtNumberFrames Unsigned32, dot11FrameRprtVendorSpecific OCTET STRING, dot11FrameRptMeasurementMode INTEGER} dot11FrameRprtIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index for Frame reports in dot11FrameReportTable, greater than 0." ::= { dot11FrameReportEntry 1 } dot11FrameRprtIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. The ifIndex of the interface over which this Frame report was received." ::= { dot11FrameReportEntry 2 } dot11FrameRprtRqstToken OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. INDEX for Frame requests in dot11FrameRequestTable that corresponds to this row of frame report. Since a single Frame request can generate multiple rows in the frame report table, one per BSSID, this dot11FrameRprtRqstToken indicates which request this particular row indicates. If this row of report is received without a particular request, this attribute should be 0" ::= { dot11FrameReportEntry 3 } dot11FrameRprtChanNumber OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the channel number used for this Frame report. The Channel Number is defined only within the indicated Operating Class for this measurement report." ::= { dot11FrameReportEntry 4 } 2922 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11FrameRprtOperatingClass OBJECT-TYPE SYNTAX Unsigned32(1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the channel set for this measurement report. Country, Operating Class and Channel Number together specify the channel frequency and spacing for this measurement report. Valid values of Operating Class are shown in Annex E." REFERENCE "Annex E" ::= { dot11FrameReportEntry 5 } dot11FrameRprtActualStartTime OBJECT-TYPE SYNTAX TSFType MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the TSF value at the time when measurement started." ::= { dot11FrameReportEntry 6 } dot11FrameRprtMeasurementDuration OBJECT-TYPE SYNTAX Unsigned32 UNITS "TUs" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the duration over which the Frame report was measured" ::= { dot11FrameReportEntry 7 } dot11FrameRprtTransmitSTAAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. The MAC address of STA for this row of Frame report that it has been received from." ::= { dot11FrameReportEntry 8 } dot11FrameRprtBSSID OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the BSSID of the STA that transmitted this frame." ::= { dot11FrameReportEntry 9 } 2923 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11FrameRprtPhyType OBJECT-TYPE SYNTAX INTEGER { dsss(2), ofdm(4), hrdsss(5), erp(6), ht(7), dmg(8), vht(9), tvht(10) } MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the PHY used for frame reception in this row of the frame report." ::= { dot11FrameReportEntry 10 } dot11FrameRprtAvgRCPI OBJECT-TYPE SYNTAX Unsigned32(0..255) UNITS "dBm" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the average value for the received channel power of all of the frames received and counted in this frame report entry as defined 9.4.2.38. RCPIval = Floor((RCPIpower in dBm + 110)*2), for RCPI in the range -110 dBm to 0 dBm. RCPIval = 220 for RCPI > 0 dBm. RCPIval = 255 when RCPI is not available." ::= { dot11FrameReportEntry 11 } dot11FrameRprtLastRSNI OBJECT-TYPE SYNTAX Unsigned32(0..255) UNITS "dBm" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the received signal-to-noise ratio of the received frame. RSNI is the received signal-to-noise plus interference ratio derived from the RCPI for the received frame and from the most recent ANPI value measured on the channel used to receive the frame. RSNI may be calculated by the ratio of the received signal power (RCPI - ANPI) over the noise plus interference power (ANPI) where RSNI = [(ratio(dB) + 10) * 2], for ratios in the range -10 dB to +118 dB. Other measurement techniques are allowed." ::= { dot11FrameReportEntry 12 } dot11FrameRprtLastRCPI OBJECT-TYPE SYNTAX Unsigned32(0..255) UNITS "dBm" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. 2924 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This attribute indicates the received channel power of the most recently measured frame in this frame report entry as defined 9.4.2.38. RCPIval = Floor((RCPIpower in dBm + 110)*2), for RCPI in the range -110 dBm to 0 dBm. RCPIval = 220 for RCPI > 0 dBm. RCPIval = 255 when RCPI is not available." ::= { dot11FrameReportEntry 13 } dot11FrameRprtAntennaID OBJECT-TYPE SYNTAX Unsigned32(0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the identifying number for the antenna used for this measurement. The value 0 indicates that the antenna identifier is unknown. The value 255 indicates that this measurement was made with multiple antennas. The value 1 is used for a STA with only one antenna. STAs with more than one antenna assign Antenna IDs to each antenna as consecutive, ascending numbers. Each Antenna ID number represents a unique antenna characterized by a fixed relative position, a fixed relative direction, and a peak gain for that position and direction." ::= { dot11FrameReportEntry 14 } dot11FrameRprtNumberFrames OBJECT-TYPE SYNTAX Unsigned32(0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the number of received frames in the Measurement Report frame for this row of the Frame report." ::= { dot11FrameReportEntry 15 } dot11FrameRprtVendorSpecific OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute provides an envelope for any optional vendor specific subelements which may be included in a measurement report element. The default value is null." DEFVAL { ''H } ::= { dot11FrameReportEntry 16 } dot11FrameRptMeasurementMode OBJECT-TYPE SYNTAX INTEGER { success(0), incapableBit(1), refusedBit(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the outcome status for the measurement request 2925 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications which generated this measurement report; status is indicated using the following reason codes: 1 indicates this STA is incapable of generating the report, 2 indicates this STA is refusing to generate the report, 0 indicates the STA successfully carried out the measurement request." DEFVAL { 0 } ::= { dot11FrameReportEntry 17 } -- ******************************************************************** -- * End of dot11FrameReport TABLE -- ******************************************************************** -- ******************************************************************** -- * dot11STAStatisticsReport TABLE -- ******************************************************************** dot11STAStatisticsReportTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11STAStatisticsReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the current list of STA Statistics reports that have been received by the MLME. The report tables are maintained as a FIFO to preserve freshness, thus the rows in this table can be deleted for memory constraints or other implementation constraints determined by the vendor. New rows have different RprtIndex values than those deleted within the range limitation of the index. One easy way is to increment RprtIndex for new reports being written in the table." ::= { dot11RMReport 5 } dot11STAStatisticsReportEntry OBJECT-TYPE SYNTAX Dot11STAStatisticsReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11STAStatisticsReportTable Indexed by dot11STAStatisticsReportIndex." INDEX { dot11STAStatisticsReportIndex } ::= { dot11STAStatisticsReportTable 1 } Dot11STAStatisticsReportEntry ::= SEQUENCE { dot11STAStatisticsReportIndex Unsigned32, dot11STAStatisticsReportToken OCTET STRING, dot11STAStatisticsIfIndex InterfaceIndex, dot11STAStatisticsSTAAddress MacAddress, dot11STAStatisticsMeasurementDuration Unsigned32, dot11STAStatisticsGroupID INTEGER, dot11STAStatisticsTransmittedFragmentCount Counter32, dot11STAStatisticsGroupTransmittedFrameCount Counter32, dot11STAStatisticsFailedCount Counter32, dot11STAStatisticsRetryCount Counter32, dot11STAStatisticsMultipleRetryCount Counter32, dot11STAStatisticsFrameDuplicateCount Counter32, dot11STAStatisticsRTSSuccessCount Counter32, dot11STAStatisticsRTSFailureCount Counter32, dot11STAStatisticsAckFailureCount Counter32, dot11STAStatisticsQosTransmittedFragmentCount Counter32, dot11STAStatisticsQosFailedCount Counter32, dot11STAStatisticsQosRetryCount Counter32, dot11STAStatisticsQosMultipleRetryCount Counter32, dot11STAStatisticsQosFrameDuplicateCount Counter32, dot11STAStatisticsQosRTSSuccessCount Counter32, dot11STAStatisticsQosRTSFailureCount Counter32, dot11STAStatisticsQosAckFailureCount Counter32, dot11STAStatisticsQosReceivedFragmentCount Counter32, 2926 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11STAStatisticsQosTransmittedFrameCount Counter32, dot11STAStatisticsQosDiscardedFrameCount Counter32, dot11STAStatisticsQosMPDUsReceivedCount Counter32, dot11STAStatisticsQosRetriesReceivedCount Counter32, dot11STAStatisticsReceivedFragmentCount Counter32, dot11STAStatisticsGroupReceivedFrameCount Counter32, dot11STAStatisticsFCSErrorCount Counter32, dot11STAStatisticsTransmittedFrameCount Counter32, dot11STAStatisticsAPAverageAccessDelay Unsigned32, dot11STAStatisticsAverageAccessDelayBestEffort Unsigned32, dot11STAStatisticsAverageAccessDelayBackground Unsigned32, dot11STAStatisticsAverageAccessDelayVideo Unsigned32, dot11STAStatisticsAverageAccessDelayVoice Unsigned32, dot11STAStatisticsStationCount Unsigned32, dot11STAStatisticsChannelUtilization Unsigned32, dot11STAStatisticsVendorSpecific OCTET STRING, dot11STAStatisticsRprtMeasurementMode INTEGER, dot11STAStatisticsRSNAStatsBIPMICErrors Counter32, dot11STAStatisticsRSNAStatsCMACReplays Counter32, dot11STAStatisticsRSNAStatsRobustMgmtCCMPReplays Counter32, dot11STAStatisticsRSNAStatsTKIPICVErrors Counter32, dot11STAStatisticsRSNAStatsTKIPReplays Counter32, dot11STAStatisticsRSNAStatsCCMPDecryptErrors Counter32, dot11STAStatisticsRSNAStatsCCMPReplays Counter32, dot11STAStatisticsReportingReasonSTACounters OCTET STRING, dot11STAStatisticsReportingReasonQosCounters OCTET STRING, dot11STAStatisticsReportingReasonRsnaCounters OCTET STRING, dot11STAStatisticsTransmittedAMSDUCount Counter32, dot11STAStatisticsFailedAMSDUCount Counter32, dot11STAStatisticsRetryAMSDUCount Counter32, dot11STAStatisticsMultipleRetryAMSDUCount Counter32, dot11STAStatisticsTransmittedOctetsInAMSDUCount Counter64, dot11STAStatisticsAMSDUAckFailureCount Counter32, dot11STAStatisticsReceivedAMSDUCount Counter32, dot11STAStatisticsReceivedOctetsInAMSDUCount Counter64, dot11STAStatisticsTransmittedAMPDUCount Counter32, dot11STAStatisticsTransmittedMPDUsInAMPDUCount Counter32, dot11STAStatisticsTransmittedOctetsInAMPDUCount Counter64, dot11STAStatisticsAMPDUReceivedCount Counter32, dot11STAStatisticsMPDUInReceivedAMPDUCount Counter32, dot11STAStatisticsReceivedOctetsInAMPDUCount Counter64, dot11STAStatisticsAMPDUDelimiterCRCErrorCount Counter32, dot11STAStatisticsImplicitBARFailureCount Counter32, dot11STAStatisticsExplicitBARFailureCount Counter32, dot11STAStatisticsChannelWidthSwitchCount Counter32, dot11STAStatisticsTwentyMHzFrameTransmittedCount Counter32, dot11STAStatisticsFortyMHzFrameTransmittedCount Counter32, dot11STAStatisticsTwentyMHzFrameReceivedCount Counter32, dot11STAStatisticsFortyMHzFrameReceivedCount Counter32, dot11STAStatisticsPSMPUTTGrantDuration Counter32, dot11STAStatisticsPSMPUTTUsedDuration Counter32, dot11STAStatisticsGrantedRDGUsedCount Counter32, dot11STAStatisticsGrantedRDGUnusedCount Counter32, dot11STAStatisticsTransmittedFramesInGrantedRDGCount Counter32, dot11STAStatisticsTransmittedOctetsInGrantedRDGCount Counter64, dot11STAStatisticsDualCTSSuccessCount Counter32, dot11STAStatisticsDualCTSFailureCount Counter32, dot11STAStatisticsRTSLSIGSuccessCount Counter32, dot11STAStatisticsRTSLSIGFailureCount Counter32, dot11STAStatisticsBeamformingFrameCount Counter32, dot11STAStatisticsSTBCCTSSuccessCount Counter32, dot11STAStatisticsSTBCCTSFailureCount Counter32, dot11STAStatisticsnonSTBCCTSSuccessCount Counter32, dot11STAStatisticsnonSTBCCTSFailureCount Counter32, 2927 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11STAStatisticsAverageMSDUSizeVideo Unsigned32, dot11STAStatisticsAverageMSDUSizeVoice Unsigned32, dot11STAStatisticsAverageBitrateVideo Unsigned32, dot11STAStatisticsAverageBitrateVoice Unsigned32 } dot11STAStatisticsReportIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index for STA Statistics reports in dot11STAStatisticsReportTable, greater than 0." ::= { dot11STAStatisticsReportEntry 1 } dot11STAStatisticsReportToken OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the token that was indicated in the measurement request that generated this measurement report. This should be an exact match to the original dot11RMRqstToken attribute. Note that there may be multiple entries in the table that match this value since a single request may generate multiple measurement reports." ::= { dot11STAStatisticsReportEntry 2 } dot11STAStatisticsIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. Identifies the Interface that this row of STA Statistics report has been received on" ::= { dot11STAStatisticsReportEntry 3 } dot11STAStatisticsSTAAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. The MAC address of the STA that returned this STA Statistics report." ::= { dot11STAStatisticsReportEntry 4 } dot11STAStatisticsMeasurementDuration OBJECT-TYPE SYNTAX Unsigned32 UNITS "TUs" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the duration over which the STA Statistics was measured. The value 0 for this attribute indicates that the reported 2928 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications statistics are a current snapshot of the statistics variables. A nonzero value for this attribute indicates that the reported statistics contain the difference in the corresponding statistics variables over the indicated duration." ::= { dot11STAStatisticsReportEntry 5 } dot11STAStatisticsGroupID OBJECT-TYPE SYNTAX INTEGER { dot11CountersTable(0), dot11MacStatistics(1), dot11QosCountersTableforUP0(2), dot11QosCountersTableforUP1(3), dot11QosCountersTableforUP2(4), dot11QosCountersTableforUP3(5), dot11QosCountersTableforUP4(6), dot11QosCountersTableforUP5(7), dot11QosCountersTableforUP6(8), dot11QosCountersTableforUP7(9), bSSAverageAccessDelays(10), dot11CountersGroup3Tablefor31(11), dot11CountersGroup3Tablefor32(12), dot11CountersGroup3Tablefor33(13), dot11CountersGroup3Tablefor34(14), dot11CountersGroup3Tablefor35(15), dot11RSNAStatsTable(16) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the value of dot11RMRqstSTAStatRqstGroupID returned from the STA in this STA Statistics report." DEFVAL { 0 } ::= { dot11STAStatisticsReportEntry 6 } dot11STAStatisticsTransmittedFragmentCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of dot11TransmittedFragmentCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 0 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 7 } dot11STAStatisticsGroupTransmittedFrameCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of dot11GroupTransmittedFrameCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced 2929 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 0 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 8 } dot11STAStatisticsFailedCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of dot11FailedCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 0 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 9 } dot11STAStatisticsRetryCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of dot11RetryCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 1 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 10 } dot11STAStatisticsMultipleRetryCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of dot11MultipleRetryCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 1 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 11 } dot11STAStatisticsFrameDuplicateCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of dot11FrameDuplicateCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced 2930 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 1 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 12 } dot11STAStatisticsRTSSuccessCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of dot11RTSSuccessCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 1 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 13 } dot11STAStatisticsRTSFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of dot11RTSFailureCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 1 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 14 } dot11STAStatisticsAckFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of dot11AckFailureCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 1 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 15 } dot11STAStatisticsQosTransmittedFragmentCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of dot11QosTransmittedFragmentCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the 2931 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 2-9 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 16 } dot11STAStatisticsQosFailedCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of dot11QosFailedCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 2-9 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 17 } dot11STAStatisticsQosRetryCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of dot11QosRetryCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 2-9 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 18 } dot11STAStatisticsQosMultipleRetryCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of dot11QosMultipleRetryCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 2-9 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 19 } dot11STAStatisticsQosFrameDuplicateCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of dot11QosFrameDuplicateCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a 2932 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 2-9 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 20 } dot11STAStatisticsQosRTSSuccessCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of dot11QosRTSSuccessCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 2-9 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 21 } dot11STAStatisticsQosRTSFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of dot11QosRTSFailureCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 2-9 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 22 } dot11STAStatisticsQosAckFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of dot11QosAckFailureCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 2-9 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 23 } dot11STAStatisticsQosReceivedFragmentCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of dot11QosReceivedFragmentCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates 2933 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 2-9 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 24 } dot11STAStatisticsQosTransmittedFrameCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of dot11QosTransmittedFrameCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 2-9 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 25 } dot11STAStatisticsQosDiscardedFrameCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of dot11QosDiscardedFrameCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 2-9 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 26 } dot11STAStatisticsQosMPDUsReceivedCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of dot11QosMPDUsReceivedCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 2-9 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 27 } dot11STAStatisticsQosRetriesReceivedCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of dot11QosRetriesReceivedCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates 2934 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 2-9 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 28 } dot11STAStatisticsReceivedFragmentCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of dot11ReceivedFragmentCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 0 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 29 } dot11STAStatisticsGroupReceivedFrameCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of dot11GroupReceivedFrameCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 0 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 30 } dot11STAStatisticsFCSErrorCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of dot11FCSErrorCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 0 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 31 } dot11STAStatisticsTransmittedFrameCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of dot11TransmittedFrameCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a 2935 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 0 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 32 } dot11STAStatisticsAPAverageAccessDelay OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of the AP Average Access Delay (AAD) returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced access delay value over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 10 and is ignored otherwise." REFERENCE "IEEE Std 802.11 9.4.2.39" ::= { dot11STAStatisticsReportEntry 33 } dot11STAStatisticsAverageAccessDelayBestEffort OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of the Average Access Delay (AAD) for the Best Effort Access Category returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced access delay value over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 10 and is ignored otherwise." REFERENCE "IEEE Std 802.11 9.4.2.44" ::= { dot11STAStatisticsReportEntry 34 } dot11STAStatisticsAverageAccessDelayBackground OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of the Average Access Delay (AAD) for the Background Access Category returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced access delay value over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 10 and is ignored otherwise." REFERENCE "IEEE Std 802.11 9.4.2.44" ::= { dot11STAStatisticsReportEntry 35 } dot11STAStatisticsAverageAccessDelayVideo OBJECT-TYPE SYNTAX Unsigned32 (0..255) 2936 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of the Average Access Delay (AAD) for the Video Access Category returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced access delay value over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 10 and is ignored otherwise." REFERENCE "IEEE Std 802.11 9.4.2.44" ::= { dot11STAStatisticsReportEntry 36 } dot11STAStatisticsAverageAccessDelayVoice OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of the Average Access Delay (AAD) for the Voice Access Category returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced access delay value over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 10 and is ignored otherwise." REFERENCE "IEEE Std 802.11 9.4.2.44" ::= { dot11STAStatisticsReportEntry 37 } dot11STAStatisticsStationCount OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of dot11AssociatedStationCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 10 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 38 } dot11STAStatisticsChannelUtilization OBJECT-TYPE SYNTAX Unsigned32 (0..255) UNITS "1/255" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of the Channel Utilization returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a 2937 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications nonzero value, this attribute indicates the difference in the Channel Utilization value over the indicated duration. The Channel Utilization is the time fraction during which the AP sensed the channel busy. This attribute is valid only if the dot11STAStatisticsGroupID is 10 and is ignored otherwise." REFERENCE "IEEE Std 802.11 9.4.2.28" ::= { dot11STAStatisticsReportEntry 39 } dot11STAStatisticsVendorSpecific OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute provides an envelope for any optional vendor specific subelements which may be included in a measurement report element. The default value is null." DEFVAL { ''H } ::= { dot11STAStatisticsReportEntry 40 } dot11STAStatisticsRprtMeasurementMode OBJECT-TYPE SYNTAX INTEGER { success(0), incapableBit(1), refusedBit(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the outcome status for the measurement request which generated this measurement report; status is indicated using the following reason codes: 1 indicates this STA is incapable of generating the report, 2 indicates this STA is refusing to generate the report, 0 indicates the STA successfully carried out the measurement request." DEFVAL { 0 } ::= { dot11STAStatisticsReportEntry 41 } dot11STAStatisticsRSNAStatsBIPMICErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of dot11RSNAStatsBIPMICErrors returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 16 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 42 } dot11STAStatisticsRSNAStatsCMACReplays OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION 2938 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of dot11RSNAStatsCMACReplays returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 16 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 43 } dot11STAStatisticsRSNAStatsRobustMgmtCCMPReplays OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of dot11RSNAStatsRobustMgmtCCMPReplays returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 16 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 44 } dot11STAStatisticsRSNAStatsTKIPICVErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of dot11RSNAStatsTKIPICVErrors returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 16 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 45 } dot11STAStatisticsRSNAStatsTKIPReplays OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of dot11RSNAStatsTKIPReplays returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 16 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 46 } dot11STAStatisticsRSNAStatsCCMPDecryptErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current 2939 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of dot11RSNAStatsCCMPDecryptErrors returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 16 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 47 } dot11STAStatisticsRSNAStatsCCMPReplays OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is 0, this attribute indicates the value of dot11RSNAStatsCCMPReplays returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 16 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 48 } dot11STAStatisticsReportingReasonSTACounters OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..1)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the trigger reason(s) for this Statistics report. Each bit indicates a different trigger condition. When the bit is set to 1, it indicates that the listed trigger threshold has been exceeded: B0 (least significant bit): dot11Failed, B1: dot11FCSError, B2: dot11MultipleRetry, B3: dot11FrameDuplicate, B4: dot11RTSFailure, B5: dot11AckFailureCount, B6: dot11Retry, B7: Reserved. This attribute is valid only if the dot11STAStatisticsGroupID is 0 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 49 } dot11STAStatisticsReportingReasonQosCounters OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..1)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the trigger reason(s) for this Statistics report. Each bit indicates a different trigger condition. When the bit is set to 1, it indicates that the listed trigger threshold has been exceeded: B0 (least significant bit): dot11QoSFailed, B1: dot11QoSRetry, 2940 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications B2: dot11QoSMultipleRetry, B3: dot11QoSFrameDuplicate, B4: dot11QoSRTSFailure, B5: dot11QoSAckFailure, B6: dot11QoSDiscarded, B7: Reserved. This attribute is valid only if the dot11STAStatisticsGroupID is 2-9 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 50 } dot11STAStatisticsReportingReasonRsnaCounters OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..1)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the trigger reason(s) for this Statistics report. Each bit indicates a different trigger condition. When the bit is set to 1, it indicates that the listed trigger threshold has been exceeded: B0 (least significant bit): dot11RSNAStatsBIPMICErrors, B1: dot11RSNAStatsCMACReplays, B2: dot11RSNAStatsRobustMgmtCCMPReplays, B3: dot11RSNAStatsTKIPICVErrors, B4: dot11RSNAStatsCCMPReplays, B5: dot11RSNAStatsCCMPDecryptErrors, B6: dot11RSNAStatsCCMPReplays, B7: Reserved. This attribute is valid only if the dot11STAStatisticsGroupID is 16 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 51 } dot11STAStatisticsTransmittedAMSDUCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11TransmittedAMSDUCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 11 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 52 } dot11STAStatisticsFailedAMSDUCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11FailedAMSDUCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 11 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 53 } 2941 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11STAStatisticsRetryAMSDUCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11RetryAMSDUCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 11 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 54 } dot11STAStatisticsMultipleRetryAMSDUCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11MultipleRetryAMSDUCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 11 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 55 } dot11STAStatisticsTransmittedOctetsInAMSDUCount OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11TransmittedOctetsInAMSDUCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 11 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 56 } dot11STAStatisticsAMSDUAckFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11AMSDUAckFailureCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 11 and is ignored otherwise." 2942 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ::= { dot11STAStatisticsReportEntry 57 } dot11STAStatisticsReceivedAMSDUCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11ReceivedAMSDUCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 11 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 58 } dot11STAStatisticsReceivedOctetsInAMSDUCount OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11ReceivedOctetsInAMSDUCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 11 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 59 } dot11STAStatisticsTransmittedAMPDUCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11TransmittedAMPDUCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 12 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 60 } dot11STAStatisticsTransmittedMPDUsInAMPDUCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11TransmittedMPDUsInAMPDUCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 12 and is ignored 2943 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications otherwise." ::= { dot11STAStatisticsReportEntry 61 } dot11STAStatisticsTransmittedOctetsInAMPDUCount OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11TransmittedOctetsInAMPDUCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 12 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 62 } dot11STAStatisticsAMPDUReceivedCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11AMPDUReceivedCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 12 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 63 } dot11STAStatisticsMPDUInReceivedAMPDUCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11MPDUInReceivedAMPDUCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 12 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 64 } dot11STAStatisticsReceivedOctetsInAMPDUCount OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11ReceivedOctetsInAMPDUCount returned from the STA in this 2944 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 12 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 65 } dot11STAStatisticsAMPDUDelimiterCRCErrorCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11AMPDUDelimiterCRCErrorCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 12 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 66 } dot11STAStatisticsImplicitBARFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11ImplicitBARFailureCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 13 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 67 } dot11STAStatisticsExplicitBARFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11ExplicitBARFailureCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 13 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 68 } dot11STAStatisticsChannelWidthSwitchCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. 2945 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11ChannelWidthSwitchCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 13 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 69 } dot11STAStatisticsTwentyMHzFrameTransmittedCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11TwentyMHzFrameTransmittedCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 13 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 70 } dot11STAStatisticsFortyMHzFrameTransmittedCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11FortyMHzFrameTransmittedCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 13 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 71 } dot11STAStatisticsTwentyMHzFrameReceivedCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11TwentyMHzFrameReceivedCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 13 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 72 } dot11STAStatisticsFortyMHzFrameReceivedCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION 2946 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11FortyMHzFrameReceivedCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 13 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 73 } dot11STAStatisticsPSMPUTTGrantDuration OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11PSMPUTTGrantDuration returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 13 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 74 } dot11STAStatisticsPSMPUTTUsedDuration OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11PSMPUTTUsedDuration returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 13 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 75 } dot11STAStatisticsGrantedRDGUsedCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11GrantedRDGUsedCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 14 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 76 } dot11STAStatisticsGrantedRDGUnusedCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION 2947 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11GrantedRDGUnusedCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 14 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 77 } dot11STAStatisticsTransmittedFramesInGrantedRDGCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11TransmittedFramesInGrantedRDGCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 14 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 78 } dot11STAStatisticsTransmittedOctetsInGrantedRDGCount OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11TransmittedOctetsInGrantedRDGCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 14 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 79 } dot11STAStatisticsDualCTSSuccessCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11DualCTSSuccessCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 14 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 80 } dot11STAStatisticsDualCTSFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only 2948 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11DualCTSFailureCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 14 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 81 } dot11STAStatisticsRTSLSIGSuccessCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11RTSLSIGSuccessCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 14 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 82 } dot11STAStatisticsRTSLSIGFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11RTSLSIGFailureCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 14 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 83 } dot11STAStatisticsBeamformingFrameCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11BeamformingFrameCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 15 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 84 } dot11STAStatisticsSTBCCTSSuccessCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only 2949 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11STBCCTSSuccessCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 15 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 85 } dot11STAStatisticsSTBCCTSFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11STBCCTSFailureCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 15 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 86 } dot11STAStatisticsnonSTBCCTSSuccessCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11nonSTBCCTSSuccessCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 15 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 87 } dot11STAStatisticsnonSTBCCTSFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of dot11nonSTBCCTSFailureCount returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced dot11 variable over the indicated duration. This attribute is valid only if the dot11STAStatisticsGroupID is 15 and is ignored otherwise." ::= { dot11STAStatisticsReportEntry 88 } dot11STAStatisticsAverageMSDUSizeVideo OBJECT-TYPE SYNTAX Unsigned32 (0..7935) MAX-ACCESS read-write 2950 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed or by an external management entity. Changes from an external management entity take effect as soon as practical in the implementation. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of the Average MSDU size for the Video Access Category returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced size over the indicated duration. Changes by an external management entity are ignored when dot11STAStatisticsMeasurementDuration is nonzero." DEFVAL { 1401 } ::= { dot11STAStatisticsReportEntry 89 } dot11STAStatisticsAverageMSDUSizeVoice OBJECT-TYPE SYNTAX Unsigned32 (0.. 7935) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed or by an external management entity. Changes from an external management entity take effect as soon as practical in the implementation. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of the Average MSDU size for the Voice Access Category returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced size over the indicated duration. Changes by an external management entity are ignored when dot11STAStatisticsMeasurementDuration is nonzero." DEFVAL { 365 } ::= { dot11STAStatisticsReportEntry 90 } dot11STAStatisticsAverageBitrateVideo OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed or by an external management entity. Changes from an external management entity take effect as soon as practical in the implementation. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of the Average PHY bit rate of MPDUs transmitted and received using the Video Access Category returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced size over the indicated duration. Changes by an external management entity are ignored when dot11STAStatisticsMeasurementDuration is nonzero." ::= { dot11STAStatisticsReportEntry 91 } dot11STAStatisticsAverageBitrateVoice OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a status variable. 2951 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications It is written by the SME when a measurement report is completed or by an external management entity. Changes from an external management entity take effect as soon as practical in the implementation. If dot11STAStatisticsMeasurementDuration is zero, this attribute indicates the value of the Average PHY bit rate of MPDUs transmitted and received using the Voice Access Category returned from the STA in this STA Statistics report. If dot11STAStatisticsMeasurementDuration indicates a nonzero value, this attribute indicates the difference in the referenced size over the indicated duration. Changes by an external management entity are ignored when dot11STAStatisticsMeasurementDuration is nonzero." ::= { dot11STAStatisticsReportEntry 92 } -- ******************************************************************** -- * End of dot11STAStatisticsReport TABLE -- ******************************************************************** -- ******************************************************************** -- * dot11LCIReport TABLE -- ******************************************************************** dot11LCIReportTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11LCIReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the current list of LCI reports that have been received by the MLME. The report tables are maintained as a FIFO to preserve freshness, thus the rows in this table can be deleted for memory constraints or other implementation constraints determined by the vendor. New rows have different RprtIndex values than those deleted within the range limitation of the index. One easy way is to increment RprtIndex for new reports being written in the table." ::= { dot11RMReport 6 } dot11LCIReportEntry OBJECT-TYPE SYNTAX Dot11LCIReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11LCIReportTable Indexed by dot11LCIReportIndex." INDEX { dot11LCIReportIndex } ::= { dot11LCIReportTable 1 } Dot11LCIReportEntry ::= SEQUENCE { dot11LCIReportIndex Unsigned32, dot11LCIReportToken OCTET STRING, dot11LCIIfIndex InterfaceIndex, dot11LCISTAAddress MacAddress, dot11LCILatitudeUncertainty Unsigned32, dot11LCILatitudeInteger Integer32, dot11LCILatitudeFraction Integer32, dot11LCILongitudeUncertainty Unsigned32, dot11LCILongitudeInteger Integer32, dot11LCILongitudeFraction Integer32, dot11LCIAltitudeType INTEGER, dot11LCIAltitudeUncertainty Unsigned32, dot11LCIAltitude Integer32, dot11LCIDatum Unsigned32, dot11LCIAzimuthType INTEGER, dot11LCIAzimuthResolution Unsigned32, dot11LCIAzimuth Integer32, dot11LCIVendorSpecific OCTET STRING, 2952 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11LCIRprtMeasurementMode INTEGER} dot11LCIReportIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index for LCI reports in dot11LCIReportTable, greater than 0." ::= { dot11LCIReportEntry 1 } dot11LCIReportToken OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the token that was indicated in the measurement request that generated this measurement report. This should be an exact match to the original dot11RMRqstToken attribute. Note that there may be multiple entries in the table that match this value since a single request may generate multiple measurement reports." ::= { dot11LCIReportEntry 2 } dot11LCIIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. Identifies the Interface that this row of LCI report has been received on" ::= { dot11LCIReportEntry 3 } dot11LCISTAAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. The MAC address of the STA that returned this LCI report." ::= { dot11LCIReportEntry 4 } dot11LCILatitudeUncertainty OBJECT-TYPE SYNTAX Unsigned32 (0..63) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the latitude uncertainty as 6 bits." ::= { dot11LCIReportEntry 5 } dot11LCILatitudeInteger OBJECT-TYPE SYNTAX Integer32 (-359..359) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. 2953 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications It is written by the SME when a measurement report is completed. This attribute indicates the latitude as a 34 bit fixed point value consisting of 9 bits of integer and 25 bits of fraction. This field contains the 9 bits of integer portion of Latitude." ::= { dot11LCIReportEntry 6 } dot11LCILatitudeFraction OBJECT-TYPE SYNTAX Integer32 (-16777215..16777215) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the latitude as a 34 bit fixed point value consisting of 9 bits of integer and 25 bits of fraction. This field contains the 25 bits of fraction portion of Latitude." ::= { dot11LCIReportEntry 7 } dot11LCILongitudeUncertainty OBJECT-TYPE SYNTAX Unsigned32 (0..63) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the longitude uncertainty as 6 bits." ::= { dot11LCIReportEntry 8 } dot11LCILongitudeInteger OBJECT-TYPE SYNTAX Integer32 (-359..359) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the longitude as a 34 bit fixed point value consisting of 9 bits of integer and 25 bits of fraction. This field contains the 9 bits of integer portion of Longitude." ::= { dot11LCIReportEntry 9 } dot11LCILongitudeFraction OBJECT-TYPE SYNTAX Integer32 (-16777215..16777215) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the longitude as a 34 bit fixed point value consisting of 9 bits of integer and 25 bits of fraction. This field contains the 25 bits of fraction portion of Longitude." ::= { dot11LCIReportEntry 10 } dot11LCIAltitudeType OBJECT-TYPE SYNTAX INTEGER { meters(1), floors(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. 2954 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This attribute indicates the altitude Type. Codes defined are: meters : in 2s complement fixed-point 22-bit integer part with 8-bit fraction floors : in 2s complement fixed-point 22-bit integer part with 8-bit fraction. " ::= { dot11LCIReportEntry 11 } dot11LCIAltitudeUncertainty OBJECT-TYPE SYNTAX Unsigned32 (0..63) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the altitude resolution as 6 bits indicating the number of valid bits in the altitude." ::= { dot11LCIReportEntry 12 } dot11LCIAltitude OBJECT-TYPE SYNTAX Integer32 (-536870912..536870911) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the altitude as a 30 bit value defined by the Altitude type field. The field is encoded as a 2s complement fixed-point 22-bit integer part with 8-bit fraction." ::= { dot11LCIReportEntry 13 } -- reserved: 14. Was dot11LCIAltitudeFraction. dot11LCIDatum OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the datum as an eight-bit value encoding the horizontal and vertical references used for the coordinates given in this LCI." ::= { dot11LCIReportEntry 15 } dot11LCIAzimuthType OBJECT-TYPE SYNTAX INTEGER { frontSurfaceOfSTA(0), radioBeam(1) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the azimuth Type as a one bit attribute encoding the type of Azimuth. Codes defined are: front surface of STA : in 2s complement fixed-point 9-bit integer; and radio beam : in 2s complement fixed-point 9-bit integer" ::= { dot11LCIReportEntry 16 } dot11LCIAzimuthResolution OBJECT-TYPE SYNTAX Unsigned32 (0..15) 2955 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the azimuth Resolution as 4 bits indicating the number of valid bits in the azimuth." ::= { dot11LCIReportEntry 17 } dot11LCIAzimuth OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the azimuth as a 9 bit value defined by the Azimuth Type field.The field is encoded as a 2s complement fixed-point 9- bit integer horizontal angle in degrees from true north." ::= { dot11LCIReportEntry 18 } dot11LCIVendorSpecific OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute provides an envelope for any optional vendor specific subelements which may be included in a measurement report element. The default value is null." DEFVAL { ''H } ::= { dot11LCIReportEntry 19 } dot11LCIRprtMeasurementMode OBJECT-TYPE SYNTAX INTEGER { success(0), incapableBit(1), refusedBit(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the outcome status for the measurement request which generated this measurement report; status is indicated using the following reason codes: 1 indicates this STA is incapable of generating the report, 2 indicates this STA is refusing to generate the report, 0 indicates the STA successfully carried out the measurement request." DEFVAL { 0 } ::= { dot11LCIReportEntry 20 } -- ******************************************************************** -- * End of dot11LCIReport TABLE -- ******************************************************************** -- ******************************************************************** -- * dot11TransmitStreamReport TABLE -- ******************************************************************** 2956 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11TransmitStreamReportTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11TransmitStreamReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the current list of Transmit Delay Metrics reports that have been received by the MLME. The report tables are maintained as a FIFO to preserve freshness, thus the rows in this table can be deleted for memory constraints or other implementation constraints determined by the vendor. New rows have different RprtIndex values than those deleted within the range limitation of the index. One easy way is to increment RprtIndex for new reports being written in the table." ::= { dot11RMReport 7 } dot11TransmitStreamReportEntry OBJECT-TYPE SYNTAX Dot11TransmitStreamReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11TransmitStreamReportTable Indexed by dot11TransmitStreamRprtIndex." INDEX { dot11TransmitStreamRprtIndex } ::= { dot11TransmitStreamReportTable 1 } Dot11TransmitStreamReportEntry ::= SEQUENCE { dot11TransmitStreamRprtIndex Unsigned32, dot11TransmitStreamRprtRqstToken OCTET STRING, dot11TransmitStreamRprtIfIndex InterfaceIndex, dot11TransmitStreamMeasuringSTAAddr MacAddress, dot11TransmitStreamRprtActualStartTime TSFType, dot11TransmitStreamRprtMeasurementDuration Unsigned32, dot11TransmitStreamRprtPeerSTAAddress MacAddress, dot11TransmitStreamRprtTID Unsigned32, dot11TransmitStreamRprtAverageQueueDelay Unsigned32, dot11TransmitStreamRprtAverageTransmitDelay Unsigned32, dot11TransmitStreamRprtTransmittedMSDUCount Unsigned32, dot11TransmitStreamRprtMSDUDiscardedCount Unsigned32, dot11TransmitStreamRprtMSDUFailedCount Unsigned32, dot11TransmitStreamRprtMultipleRetryCount Unsigned32, dot11TransmitStreamRprtCFPollsLostCount Unsigned32, dot11TransmitStreamRprtBin0Range Unsigned32, dot11TransmitStreamRprtDelayHistogram OCTET STRING, dot11TransmitStreamRprtReason INTEGER, dot11TransmitStreamRprtVendorSpecific OCTET STRING, dot11TransmitStreamRprtMeasurementMode INTEGER} dot11TransmitStreamRprtIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index for Transmit Delay Metrics Report elements in dot11TransmitStreamReportTable, greater than 0." ::= { dot11TransmitStreamReportEntry 1 } dot11TransmitStreamRprtRqstToken OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. 2957 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This attribute indicates the request token that was indicated in the measurement request that generated this measurement report. This should be an exact match to the original dot11RMRqstToken attribute. Note that there may be multiple entries in the table that match this value since a single request may generate multiple measurement reports." ::= { dot11TransmitStreamReportEntry 2 } dot11TransmitStreamRprtIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. The ifIndex of the interface on which this TransmitStream Report was received." ::= { dot11TransmitStreamReportEntry 3 } dot11TransmitStreamMeasuringSTAAddr OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. The MAC address of the measuring STA for this row of Transmit Delay Metrics report." ::= { dot11TransmitStreamReportEntry 4 } dot11TransmitStreamRprtActualStartTime OBJECT-TYPE SYNTAX TSFType MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the TSF value at the time when the measurement started or for a triggered Transmit Stream/Category Measurement report the TSF value at the reporting QoS STA when the trigger condition was met." ::= { dot11TransmitStreamReportEntry 5 } dot11TransmitStreamRprtMeasurementDuration OBJECT-TYPE SYNTAX Unsigned32 UNITS "TUs" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the duration over which the Transmit Delay Metrics Report was measured. In a triggered Transmit Stream/Category Measurement report, metrics are reported over a number of transmitted MSDUs rather than a duration, hence Measurement Duration is equal to 0." ::= { dot11TransmitStreamReportEntry 6 } dot11TransmitStreamRprtPeerSTAAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION 2958 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications "This is a status variable. It is written by the SME when a measurement report is completed. The MAC address present in the Address 1 field of the measured Data frames for this row of Transmit Stream/Category Measurement report." ::= { dot11TransmitStreamReportEntry 7 } dot11TransmitStreamRprtTID OBJECT-TYPE SYNTAX Unsigned32(0..16) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the TC or TS for which traffic is to be measured. Values 0 to 15 are defined. Values 16-255 are reserved." ::= { dot11TransmitStreamReportEntry 8 } dot11TransmitStreamRprtAverageQueueDelay OBJECT-TYPE SYNTAX Unsigned32 UNITS "TUs" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the average delay of the frames (MSDUs) that are passed to the MAC during the measurement duration for the indicated destination and the indicated Traffic Identifier. Queue Delay is measured from the time the MSDU is passed to the MAC until the transmission starts." ::= { dot11TransmitStreamReportEntry 9 } dot11TransmitStreamRprtAverageTransmitDelay OBJECT-TYPE SYNTAX Unsigned32 UNITS "TUs" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the average delay of the frames (MSDUs) that are successfully transmitted during the measurement duration for the indicated destination and the indicated Traffic Identifier. Delay is measured from the time the MSDU is passed to the MAC until the Ack frame is received from the intermediate destination." ::= { dot11TransmitStreamReportEntry 10} dot11TransmitStreamRprtTransmittedMSDUCount OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the number of MSDUs to the peer STA for the TC, or TS given by the Traffic Identifier successfully transmitted in the measurement duration." ::= {dot11TransmitStreamReportEntry 11} 2959 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11TransmitStreamRprtMSDUDiscardedCount OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the number of MSDUs to the peer STA for the TC, or TS given by the Traffic Identifier discarded due either to the number of transmit attempts exceeding dot11ShortRetryLimit or dot11LongRetryLimit as appropriate, or due to the MSDU lifetime having been reached." ::= {dot11TransmitStreamReportEntry 12} dot11TransmitStreamRprtMSDUFailedCount OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the number of MSDUs to the peer STA for the TC, or TS given by the Traffic Identifier discarded during the measurement duration due to the number of transmit attempts exceeding dot11ShortRetryLimit or dot11LongRetryLimit as appropriate." ::= {dot11TransmitStreamReportEntry 13} dot11TransmitStreamRprtMultipleRetryCount OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the number of MSDUs for the TC, or TS given by the Traffic Identifier that are successfully transmitted after more than one retransmission attempt." ::= {dot11TransmitStreamReportEntry 14} dot11TransmitStreamRprtCFPollsLostCount OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the number of QoS (+)CF-Poll frames transmitted to the peer STA where there was no response from the QoS STA." ::= {dot11TransmitStreamReportEntry 15} dot11TransmitStreamRprtBin0Range OBJECT-TYPE SYNTAX Unsigned32 UNITS "TUs" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the delay range for Bin 0 of the delay histogram." 2960 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ::= { dot11TransmitStreamReportEntry 16 } dot11TransmitStreamRprtDelayHistogram OBJECT-TYPE SYNTAX OCTET STRING (SIZE (6)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the histogram of delay of the frames (MSDUs) that are successfully transmitted during the measurement duration for the indicated Traffic Identifier and the indicated destination. Delay is measured from the time the MSDU is passed to the MAC until the Ack frame is received from the intermediate destination, in units of TUs." ::= { dot11TransmitStreamReportEntry 17 } dot11TransmitStreamRprtReason OBJECT-TYPE SYNTAX INTEGER { averageTrigger(0), consecutiveTrigger(1), delayTrigger(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the Reason field indicating the reason that the measuring QoS STA sent the Transmit Stream/Category measurement report." DEFVAL { 0 } ::= { dot11TransmitStreamReportEntry 18 } dot11TransmitStreamRprtVendorSpecific OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute provides an envelope for any optional vendor specific subelements which may be included in a measurement report element. The default value is null." DEFVAL { ''H } ::= { dot11TransmitStreamReportEntry 19 } dot11TransmitStreamRprtMeasurementMode OBJECT-TYPE SYNTAX INTEGER { success(0), incapableBit(1), refusedBit(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the outcome status for the measurement request which generated this measurement report; status is indicated using the following reason codes: 1 indicates this STA is incapable of generating the report, 2 indicates this STA is refusing to generate the report, 0 indicates the STA successfully carried out the measurement request." DEFVAL { 0 } 2961 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ::= { dot11TransmitStreamReportEntry 20 } -- ******************************************************************** -- * End of dot11TransmitStreamReport TABLE -- ******************************************************************** -- ******************************************************************** -- * Radio Measurement Configuration Information -- ******************************************************************** dot11RMConfig OBJECT IDENTIFIER ::= { dot11RadioMeasurement 3 } -- ******************************************************************** -- * dot11APChannelReport TABLE -- ******************************************************************** dot11APChannelReportTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11APChannelReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "AP Channel Report information, in tabular form." ::= { dot11RMConfig 1 } dot11APChannelReportEntry OBJECT-TYPE SYNTAX Dot11APChannelReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11APChannelReportTable. Each entry in the table is indexed by dot11APChannelReportIndex." INDEX { dot11APChannelReportIndex } ::= { dot11APChannelReportTable 1 } Dot11APChannelReportEntry ::= SEQUENCE { dot11APChannelReportIndex Unsigned32, dot11APChannelReportIfIndex InterfaceIndex, dot11APChannelReportOperatingClass Unsigned32, dot11APChannelReportChannelList OCTET STRING} dot11APChannelReportIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index for AP channel report entry in dot11APChannelReportTable, greater than 0." ::= { dot11APChannelReportEntry 1 } dot11APChannelReportIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. The ifIndex for this row of the AP channel report." ::= { dot11APChannelReportEntry 2 } dot11APChannelReportOperatingClass OBJECT-TYPE SYNTAX Unsigned32(1..255) MAX-ACCESS read-create STATUS current DESCRIPTION 2962 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the channel set for this AP Channel report. Country, Operating Class and Channel Number together specify the channel frequency and spacing for this measurement report. Valid values of Operating Class are shown in Annex E." REFERENCE "Annex E" ::= { dot11APChannelReportEntry 3 } dot11APChannelReportChannelList OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute lists the specific channels in this AP Channel report. The default value is null. Each octet indicates a different channel within the indicated Operating Class. This list of channels is the Channel List in the AP Channel Report element described in 9.4.2.36. " DEFVAL { ''H } ::= { dot11APChannelReportEntry 4 } -- ******************************************************************** -- * End of dot11APChannelReportTable TABLE -- ******************************************************************** -- ******************************************************************** -- * dot11RMNeighborReport TABLE -- ******************************************************************** dot11RMNeighborReportNextIndex OBJECT-TYPE SYNTAX Unsigned32(0..255) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Identifies the next available index for managing the neighbor report table. If this attribute is 0, it indicates that the neighbor report feature is not configurable via SNMP, or the table is full and new rows cannot be accepted." ::= { dot11RMConfig 2 } dot11RMNeighborReportTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11RMNeighborReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains pertinent information on a collection of BSSIDs that are candidates to which STAs can roam. The rows are created using createAndWait method and fill in the attributes. When the rowStatus is set to active, the row can be included in Neighbor Report elements. If there is an error, the rowStatus is set to notReady by SME. Since this table contains all Neighbor Report element entries for all interfaces enabled with the neighbor report feature, it is possible to have too many entries for one interface, while still remaining under the MaxTableSize. In that situation, SME includes neighbor report entries only with lower dot11RMNeighborReportIFIndex up to the maximum possible number of entries for a particular interface identified by ifIndex. SME sets the rowStatus to notInService for those rows that cannot be included in the Neighbor Report element for that interface." ::= { dot11RMConfig 3 } dot11RMNeighborReportEntry OBJECT-TYPE 2963 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications SYNTAX Dot11RMNeighborReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11RMNeighborReportTable" INDEX { dot11RMNeighborReportIndex } ::= { dot11RMNeighborReportTable 1 } Dot11RMNeighborReportEntry ::= SEQUENCE { dot11RMNeighborReportIndex Unsigned32, dot11RMNeighborReportIfIndex InterfaceIndex, dot11RMNeighborReportBSSID MacAddress, dot11RMNeighborReportAPReachability INTEGER, dot11RMNeighborReportSecurity TruthValue, dot11RMNeighborReportCapSpectrumMgmt TruthValue, dot11RMNeighborReportCapQoS TruthValue, dot11RMNeighborReportCapAPSD TruthValue, dot11RMNeighborReportCapRM TruthValue, dot11RMNeighborReportCapDelayBlockAck TruthValue, dot11RMNeighborReportCapImmediateBlockAck TruthValue, dot11RMNeighborReportKeyScope TruthValue, dot11RMNeighborReportOperatingClass Unsigned32, dot11RMNeighborReportChannelNumber Unsigned32, dot11RMNeighborReportPhyType INTEGER, dot11RMNeighborReportNeighborTSFInfo OCTET STRING, dot11RMNeighborReportPilotInterval Unsigned32, dot11RMNeighborReportPilotMultipleBSSID OCTET STRING, dot11RMNeighborReportRMEnabledCapabilities OCTET STRING, dot11RMNeighborReportVendorSpecific OCTET STRING, dot11RMNeighborReportRowStatus RowStatus, dot11RMNeighborReportMobilityDomain TruthValue, dot11RMNeighborReportCapHT TruthValue, dot11RMNeighborReportHTLDPCCodingCap TruthValue, dot11RMNeighborReportHTSupportedChannelWidthSet TruthValue, dot11RMNeighborReportHTSMPowerSave Unsigned32, dot11RMNeighborReportHTGreenfield TruthValue, dot11RMNeighborReportHTShortGIfor20MHz TruthValue, dot11RMNeighborReportHTShortGIfor40MHz TruthValue, dot11RMNeighborReportHTTxSTBC TruthValue, dot11RMNeighborReportHTRxSTBC Unsigned32, dot11RMNeighborReportHTDelayedBlockAck TruthValue, dot11RMNeighborReportHTMaxAMSDULength TruthValue, dot11RMNeighborReportHTDSSCCKModein40MHz TruthValue, dot11RMNeighborReportHTFortyMHzIntolerant TruthValue, dot11RMNeighborReportHTLSIGTXOPProtectionSupport TruthValue, dot11RMNeighborReportHTMaxAMPDULengthExponent Unsigned32, dot11RMNeighborReportHTMinMPDUStartSpacing Unsigned32, dot11RMNeighborReportHTRxMCSBitMask OCTET STRING, dot11RMNeighborReportHTRxHighestSupportedDataRate Unsigned32, dot11RMNeighborReportHTTxMCSSetDefined TruthValue, dot11RMNeighborReportHTTxRxMCSSetNotEqual TruthValue, dot11RMNeighborReportHTTxMaxNumberSpatialStreamsSupported Unsigned32, dot11RMNeighborReportHTTxUnequalModulationSupported TruthValue, dot11RMNeighborReportHTPCO TruthValue, dot11RMNeighborReportHTPCOTransitionTime Unsigned32, dot11RMNeighborReportHTMCSFeedback Unsigned32, dot11RMNeighborReportHTCSupport TruthValue, dot11RMNeighborReportHTRDResponder TruthValue, dot11RMNeighborReportHTImplictTransmitBeamformingReceivingCap TruthValue, 2964 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11RMNeighborReportHTReceiveStaggeredSoundingCap TruthValue, dot11RMNeighborReportHTTransmitStaggeredSoundingCap TruthValue, dot11RMNeighborReportHTReceiveNDPCap TruthValue, dot11RMNeighborReportHTTransmitNDPCap TruthValue, dot11RMNeighborReportHTImplicitTransmitBeamformingCap TruthValue, dot11RMNeighborReportHTTransmitBeamformingCalibration Unsigned32, dot11RMNeighborReportHTExplicitCSITransmitBeamformingCap TruthValue, dot11RMNeighborReportHTExplicitNonCompressedSteeringCap TruthValue, dot11RMNeighborReportHTExplicitCompressedSteeringCap TruthValue, dot11RMNeighborReportHTExplicitTransmitBeamformingFeedback Unsigned32, dot11RMNbRprtHTExplicitNonCompressedBeamformingFeedbackCap Unsigned32, dot11RMNeighborReportHTExplicitCompressedBeamformingFeedbackCap Unsigned32, dot11RMNeighborReportHTTransmitBeamformingMinimalGrouping Unsigned32, dot11RMNbRprtHTCSINumberofTxBeamformingAntennasSuppt Unsigned32, dot11RMNbRprtHTNonCompressedSteeringNumofTxBmfmingAntennasSuppt Unsigned32, dot11RMNbRprtHTCompressedSteeringNumberofTxBmfmingAntennasSuppt Unsigned32, dot11RMNbRprtHTCSIMaxNumberofRowsTxBeamformingSuppt Unsigned32, dot11RMNeighborReportHTTransmitBeamformingChannelEstimationCap Unsigned32, dot11RMNeighborReportHTAntSelectionCap TruthValue, dot11RMNeighborReportHTExplicitCSIFeedbackBasedTxASELCap TruthValue, dot11RMNeighborReportHTAntIndicesFeedbackBasedTxASELCap TruthValue, dot11RMNeighborReportHTExplicitCSIFeedbackBasedCap TruthValue, dot11RMNeighborReportHTAntIndicesFeedbackCap TruthValue, dot11RMNeighborReportHTRxASELCap TruthValue, dot11RMNeighborReportHTTxSoundingPPDUsCap TruthValue, dot11RMNeighborReportHTInfoPrimaryChannel Unsigned32, dot11RMNeighborReportHTInfoSecChannelOffset Unsigned32, dot11RMNeighborReportHTInfoSTAChannelWidth TruthValue, dot11RMNeighborReportHTInfoRIFSMode TruthValue, dot11RMNeighborReportHTInfoProtection Unsigned32, dot11RMNeighborReportHTInfoNonGreenfieldHTSTAsPresent TruthValue, dot11RMNeighborReportHTInfoOBSSNonHTSTAsPresent TruthValue, dot11RMNeighborReportHTInfoDualBeacon TruthValue, dot11RMNeighborReportHTInfoDualCTSProtection TruthValue, dot11RMNeighborReportHTInfoSTBCBeacon TruthValue, dot11RMNeighborReportHTInfoLSIGTXOPProtectionSup TruthValue, dot11RMNeighborReportHTInfoPCOActive TruthValue, dot11RMNeighborReportHTInfoPCOPhase TruthValue, dot11RMNeighborReportHTInfoBasicMCSSet OCTET STRING, dot11RMNeighborReportHTSecChannelOffset Unsigned32, dot11RMNeighborReportExtCapPSMPSupport TruthValue, dot11RMNeighborReportExtCapSPSMPSup TruthValue, 2965 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11RMNeighborReportExtCapServiceIntervalGranularity Unsigned32, dot11RMNeighborReportBSSTransitCandPreference Unsigned32, dot11RMNeighborReportBSSTerminationTSF TSFType, dot11RMNeighborReportBSSTerminationDuration Unsigned32 } dot11RMNeighborReportIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index for neighbor report configuration table in dot11RMNeighborReportTable, greater than 0." ::= { dot11RMNeighborReportEntry 1 } dot11RMNeighborReportIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. The ifIndex for this row of the neighbor report." ::= { dot11RMNeighborReportEntry 2 } dot11RMNeighborReportBSSID OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-write STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the BSSID of the AP described by this row of neighbor report." ::= { dot11RMNeighborReportEntry 3 } dot11RMNeighborReportAPReachability OBJECT-TYPE SYNTAX INTEGER { notReachable(1), unknown(2), reachable(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the reachability of the AP represented by the dot11RMNeighborReportBSSID." ::= { dot11RMNeighborReportEntry 4 } dot11RMNeighborReportSecurity OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute, when true, indicates that the neighbor AP identified by this BSSID supports the same security provisioning as used by the AP which provided this neighbor report. This attribute, when false, indicates either that the neighbor AP identified by this BSSID does not support the same security provisioning or that the security information for this 2966 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications neighbor AP is not available at this time." ::= { dot11RMNeighborReportEntry 5 } dot11RMNeighborReportCapSpectrumMgmt OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the spectrum management capability of the AP represented by dot11RMNeighborReportBSSID." ::= { dot11RMNeighborReportEntry 6 } dot11RMNeighborReportCapQoS OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the QoS capability of the AP represented by dot11RMNeighborReportBSSID." ::= { dot11RMNeighborReportEntry 7 } dot11RMNeighborReportCapAPSD OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the APSD capability of the AP represented by dot11RMNeighborReportBSSID." ::= { dot11RMNeighborReportEntry 8 } dot11RMNeighborReportCapRM OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute is equal to true when the AP, represented by dot11RMNeighborReportBSSID, transmits a RM Enabled Capabilities element; and is false otherwise." ::= { dot11RMNeighborReportEntry 9 } dot11RMNeighborReportCapDelayBlockAck OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the delayed block ack capability of the AP represented by dot11RMNeighborReportBSSID." ::= { dot11RMNeighborReportEntry 10 } 2967 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11RMNeighborReportCapImmediateBlockAck OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the immediate block ack capability of the AP represented by dot11RMNeighborReportBSSID." ::= { dot11RMNeighborReportEntry 11 } dot11RMNeighborReportKeyScope OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute, when true, indicates the neighbor AP identified by this BSSID has the same authenticator as the AP which provided this neighbor report. This attribute, when false, indicates that the neighbor AP identified by this BSSID has a different authenticator or that authenticator information is not available." ::= { dot11RMNeighborReportEntry 12 } dot11RMNeighborReportOperatingClass OBJECT-TYPE SYNTAX Unsigned32(1..255) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the channel set for this neighbor report entry. Country, Operating Class and Channel Number together specify the channel frequency and spacing for this measurement report. Valid values of Operating Class are shown in Annex E." REFERENCE "Annex E" ::= { dot11RMNeighborReportEntry 13 } dot11RMNeighborReportChannelNumber OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the current operating channel of the AP represented by the dot11RMNeighborReportBSSID. The Channel Number is defined only within the indicated Operating Class for this neighbor report entry." ::= { dot11RMNeighborReportEntry 14 } dot11RMNeighborReportPhyType OBJECT-TYPE SYNTAX INTEGER { dsss(2), ofdm(4), hrdsss(5), erp(6), ht(7), 2968 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dmg(8), vht(9), tvht(10) } MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the PHY Type of the neighbor AP identified by this BSSID." ::= { dot11RMNeighborReportEntry 15 } dot11RMNeighborReportNeighborTSFInfo OBJECT-TYPE SYNTAX OCTET STRING (SIZE (6)) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates TSF timing information for the neighbor AP identified by this BSSID. The TSF timing information includes the TSF Offset and the Beacon Interval, as defined in 9.4.2.37." ::= { dot11RMNeighborReportEntry 16 } dot11RMNeighborReportPilotInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "TUs" MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the Measurement Pilot Interval for the neighbor AP identified by this BSSID, as defined in 9.4.1.18." ::= { dot11RMNeighborReportEntry 17 } dot11RMNeighborReportPilotMultipleBSSID OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1)) UNITS "BSSID LSBs" MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates n, where 2**n is the maximum number of BSSIDs in the multiple BSSID set, as described in 11.11.14." ::= { dot11RMNeighborReportEntry 18 } dot11RMNeighborReportRMEnabledCapabilities OBJECT-TYPE SYNTAX OCTET STRING (SIZE(7)) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute indicates the detailed enabled capabilities of the AP represented by the dot11RMNeighborReportBSSID, as defined in 9.4.2.45." REFERENCE "IEEE Std 802.11 - 9.4.2.45" 2969 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ::= { dot11RMNeighborReportEntry 19 } dot11RMNeighborReportVendorSpecific OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This attribute provides an envelope for any optional vendor specific subelements which may be included in a measurement report element. The default value is null." DEFVAL { ''H } ::= { dot11RMNeighborReportEntry 20 } dot11RMNeighborReportRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. Contains the row status of the neighbor report, essentially used for indicating whether the row has all valid attributes filled in. Then set to active to be used in Neighbor Report elements. If any parameter is invalid, the SME sets this attribute back to notReady. It is the responsibility of the manager to correct the parameters." ::= { dot11RMNeighborReportEntry 21 } dot11RMNeighborReportMobilityDomain OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. Indicates a common mobility domain identifier (MDID) and an identical value of the FT Capability and Policy value." ::= { dot11RMNeighborReportEntry 22 } dot11RMNeighborReportCapHT OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. The High Throughput Bit when equal to 1 indicates that the AP represented by this BSSID is an HT AP including the HT Capabilities element in its Beacons and that the contents of that HT Capabilities element are identical to the HT Capabilities element advertised by the AP sending the report. See 9.4.2.37" ::= { dot11RMNeighborReportEntry 23 } dot11RMNeighborReportHTLDPCCodingCap OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. 2970 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications It is written by the SME when a measurement report is completed. This variable indicates support for receiving LDPC coded packets, equal to false if not supported, equal to true if supported. See 9.4.2.56.2" ::= { dot11RMNeighborReportEntry 24 } dot11RMNeighborReportHTSupportedChannelWidthSet OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates which channel widths the STA supports, equal to false if only 20 MHz operation is supported, equal to true if both 20 MHz and 40 MHz operation is supported. See 9.4.2.56.2" ::= { dot11RMNeighborReportEntry 25 } dot11RMNeighborReportHTSMPowerSave OBJECT-TYPE SYNTAX Unsigned32 (0..3) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates the SM power save mode, equal to 0 for static SM power save mode, equal to 1 for dynamic SM power save mode, equal to 3 for SM power save disabled or not supported, the value 2 is reserved; see 9.4.2.56.2" ::= { dot11RMNeighborReportEntry 26 } dot11RMNeighborReportHTGreenfield OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates support for the reception of PPDUs with HT- greenfield format, equal to false if not supported, equal to true if supported. See 9.4.2.56.2" ::= { dot11RMNeighborReportEntry 27 } dot11RMNeighborReportHTShortGIfor20MHz OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates short GI support for the reception of 20 MHz packets, equal to false if not supported, equal to true if supported See 9.4.2.56.2" ::= { dot11RMNeighborReportEntry 28 } dot11RMNeighborReportHTShortGIfor40MHz OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION 2971 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates short GI support for the reception of 40 MHz packets, equal to false if not supported, equal to true if supported. See 9.4.2.56.2" ::= { dot11RMNeighborReportEntry 29} dot11RMNeighborReportHTTxSTBC OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates support for the transmission of PPDUs using STBC, equal to false if not supported, equal to true if supported. See 9.4.2.56.2" ::= { dot11RMNeighborReportEntry 30} dot11RMNeighborReportHTRxSTBC OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates support for the reception of PPDUs using STBC, equal to 0 for no support, equal to 1 for support of one spatial stream, equal to 2 for support of one and two spatial streams, equal to 3 for support of one, two, and three spatial streams. See 9.4.2.56.2" ::= { dot11RMNeighborReportEntry 31} dot11RMNeighborReportHTDelayedBlockAck OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates support for HT-delayed block ack operation, equal to false if not supported, equal to true if supported. Support indicates that the STA is able to accept an ADDBA request for HT-delayed block ack. See 9.4.2.56.2" ::= { dot11RMNeighborReportEntry 32 } dot11RMNeighborReportHTMaxAMSDULength OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates maximum A-MSDU length, equal to false for 3839 octets, equal to true for 7935 octets. See 9.4.2.56.2" ::= { dot11RMNeighborReportEntry 33 } dot11RMNeighborReportHTDSSCCKModein40MHz OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create 2972 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates use of DSSS/CCK mode in a 40 MHz capable BSS operating in 20/40 MHz mode, equal to false if DSSS/CCK in 40 MHz is not allowed, equal to true if the DSSS/CCK in 40 MHz is allowed. See 9.4.2.56.2" ::= { dot11RMNeighborReportEntry 34 } dot11RMNeighborReportHTFortyMHzIntolerant OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates whether other BSSs receiving this information are required to prohibit 40 MHz transmissions, equal to true to prohibit 20/40 MHz BSS operation, otherwise equal to false. See 9.4.2.56.2" ::= { dot11RMNeighborReportEntry 35 } dot11RMNeighborReportHTLSIGTXOPProtectionSupport OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates support for the LSIG TXOP protection mechanism, equal to false if not supported, equal to true if supported. See 9.4.2.56.2" ::= { dot11RMNeighborReportEntry 36 } dot11RMNeighborReportHTMaxAMPDULengthExponent OBJECT-TYPE SYNTAX Unsigned32 (0..3) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates the maximum length of A-MPDU that the STA can receive. This field is an integer in the range 0 to 3. The length defined by this field is equal to 2 ** (13 + Maximum A-MPDU Length) - 1 octets. See 9.4.2.56.3" ::= { dot11RMNeighborReportEntry 37 } dot11RMNeighborReportHTMinMPDUStartSpacing OBJECT-TYPE SYNTAX Unsigned32 (0..7) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable determines the minimum time between the start of adjacent MPDUs within an AMPDU, measured at the PHY SAP, equal to 0 for no restriction, equal to 1 for 1/4 microsecond, equal to 2 for 1/2 microsecond, equal to 3 for 1 microsecond, equal to 4 for 2 microseconds, equal to 5 for 4 microseconds, equal to 6 for 8 microseconds, equal to 7 2973 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications for 16 microseconds. See 9.4.2.56.3" ::= { dot11RMNeighborReportEntry 38 } dot11RMNeighborReportHTRxMCSBitMask OBJECT-TYPE SYNTAX OCTET STRING (SIZE(10)) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable is a 77 bit bitmap that defines a set of MCS values, where bit B0 (i.e., the lsb of the first octet) corresponds to MCS 0 and bit B76 corresponds to MCS 76, equal to 0 when the MCS is not supported, equal to 1 when the MCS is supported. See 9.4.2.56.4" ::= { dot11RMNeighborReportEntry 39} dot11RMNeighborReportHTRxHighestSupportedDataRate OBJECT-TYPE SYNTAX Unsigned32 (1..1023) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable defines the highest HT PPDU data rate that the STA is able to receive, in units of 1 Mb/s. See 9.4.2.56.4" ::= { dot11RMNeighborReportEntry 40 } dot11RMNeighborReportHTTxMCSSetDefined OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates if the Tx MCS set is defined, equal to false if no Tx MCS set is defined, equal to true if Tx MCS set is defined. See 9.4.2.56.4" ::= { dot11RMNeighborReportEntry 41 } dot11RMNeighborReportHTTxRxMCSSetNotEqual OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates if the Tx MCS set is defined to be equal to the Rx MCS set, equal to false where no Tx MCS set is defined or where the Tx MCS Set is defined to be equal to the RX MCS Set, equal to true where the TX MCS set may differ from the Rx MCS set. See 9.4.2.56.4" ::= { dot11RMNeighborReportEntry 42 } dot11RMNeighborReportHTTxMaxNumberSpatialStreamsSupported OBJECT-TYPE SYNTAX Unsigned32 (0..3) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. 2974 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This variable indicates maximum number of spatial streams supported when the Tx MCS Set may differ from the Rx MCS set, equal to 0 where no TX MCS set is defined or where the Tx MCS set is defined to be equal to the RX MCS set or where the maximum number of spatial streams supported when transmitting is 1 spatial stream and the Tx MCS set may differ from the Rx MCS set, equal to 1 where the maximum number of spatial streams supported when transmitting is 2 spatial streams and the Tx MCS set may differ from the Rx MCS set, equal to 2 where the maximum number of spatial streams supported when transmitting is 3 spatial streams and the Tx MCS set may differ from the Rx MCS set, equal to 3 where the maximum number of spatial streams supported when transmitting is 4 spatial streams and the Tx MCS set may differ from the Rx MCS set. See 9.4.2.56.4" ::= { dot11RMNeighborReportEntry 43 } dot11RMNeighborReportHTTxUnequalModulationSupported OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates whether transmit UEQM is supported when the Tx MCS set may differ from the Rx MCS set, equal to false where no TX MCS set is defined or where the Tx MCS set is defined to be equal to the RX MCS set or when UEQM is not supported and the Tx MCS set may differ from the Rx MCS set, equal to true when UEQM is supported and the Tx MCS set may differ from the Rx MCS set. See 9.4.2.56.4" ::= { dot11RMNeighborReportEntry 44 } dot11RMNeighborReportHTPCO OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates support for PCO, equal to false if not supported, equal to true if supported. See 9.4.2.56.5" ::= { dot11RMNeighborReportEntry 45 } dot11RMNeighborReportHTPCOTransitionTime OBJECT-TYPE SYNTAX Unsigned32 (0..3) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates that the STA can switch between 20 MHz channel width and 40 MHz channel width within the indicated time, equal to 0 for no transition, equal to 1 for 400 microseconds, equal to 2 for 1.5 ms, equal to 3 for 5 ms. For the no transition case (equal to 0) the PCO active STA does not change its operation channel width and is able to receive 40 MHz PPDUs during the 20 MHz phase. See 9.4.2.56.5" ::= { dot11RMNeighborReportEntry 46 } dot11RMNeighborReportHTMCSFeedback OBJECT-TYPE SYNTAX Unsigned32 (0..3) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. 2975 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications It is written by the SME when a measurement report is completed. This variable indicates the capability of the STA to provide MFB, equal to 0 if the STA does not provide MFB, equal to 2 if the STA provide only unsolicited MFB, equal to 3 if the STA can provide MFB in response to MRQ as well as unsolicited MFB. Note the value 1 is reserved. See 9.4.2.56.5" ::= { dot11RMNeighborReportEntry 47 } dot11RMNeighborReportHTCSupport OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates support of the HT Control field, equal to false if not supported, equal to true if supported. See 9.4.2.56.5" ::= { dot11RMNeighborReportEntry 48 } dot11RMNeighborReportHTRDResponder OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates support for acting as a revere direction responder, equal to false if not supported, equal to true if supported. See 9.4.2.56.5" ::= { dot11RMNeighborReportEntry 49} dot11RMNeighborReportHTImplictTransmitBeamformingReceivingCap OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates whether this STA can receive Transmit Beamforming steered frames using implicit feedback, equal to false if not supported, equal to true if supported. See 9.4.2.56.6" ::= { dot11RMNeighborReportEntry 50 } dot11RMNeighborReportHTReceiveStaggeredSoundingCap OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates whether this STA can receive staggered sounding frames, equal to false if not supported, equal to true if supported. See 9.4.2.56.6" ::= { dot11RMNeighborReportEntry 51 } dot11RMNeighborReportHTTransmitStaggeredSoundingCap OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION 2976 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates whether this STA can transmit staggered sounding frames, equal to false if not supported, equal to true if supported. See 9.4.2.56.6" ::= { dot11RMNeighborReportEntry 52 } dot11RMNeighborReportHTReceiveNDPCap OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates whether this receiver can interpret NDPs as sounding frames, equal to false if not supported, equal to true if supported. See 9.4.2.56.6" ::= { dot11RMNeighborReportEntry 53 } dot11RMNeighborReportHTTransmitNDPCap OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates whether this STA can transmit NDPs as sounding frames, equal to false if not supported, equal to true if supported. See 9.4.2.56.6" ::= { dot11RMNeighborReportEntry 54 } dot11RMNeighborReportHTImplicitTransmitBeamformingCap OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates whether this STA can apply implicit transmit beamforming, equal to false if not supported, equal to true if supported. See 9.4.2.56.6" ::= { dot11RMNeighborReportEntry 55 } dot11RMNeighborReportHTTransmitBeamformingCalibration OBJECT-TYPE SYNTAX Unsigned32 (0..3) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates that the STA can participate in a calibration procedure initiated by another STA that is capable of generating an immediate response Sounding PPDU and can provide a CSI report in response to the receipt of a Sounding PPDU, equal to 0 if not supported, equal to 1 is the STA can respond to a calibration request using the CSI report but cannot initiate calibration, equal to 3 if the STA can both initiate and respond to a calibration request. See 9.4.2.56.6" ::= { dot11RMNeighborReportEntry 56 } 2977 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11RMNeighborReportHTExplicitCSITransmitBeamformingCap OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates whether this STA can apply transmit beamforming using SCI explicit feedback in its transmission, equal to false if not supported, equal to true if supported. See 9.4.2.56.6" ::= { dot11RMNeighborReportEntry 57 } dot11RMNeighborReportHTExplicitNonCompressedSteeringCap OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. The variable indicates whether this STA can apply transmit beamforming using noncompressed beamforming feedback matrix explicit feedback in its transmission, equal to false if not supported, equal to true if supported. See 9.4.2.56.6" ::= { dot11RMNeighborReportEntry 58 } dot11RMNeighborReportHTExplicitCompressedSteeringCap OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates whether this STA can apply transmit beamforming using compressed beamforming feedback matrix explicit feedback in its transmission, equal to false if not supported, equal to true if supported. See 9.4.2.56.6" ::= { dot11RMNeighborReportEntry 59} dot11RMNeighborReportHTExplicitTransmitBeamformingFeedback OBJECT-TYPE SYNTAX Unsigned32 (0..3) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates whether this receiver can return CSI explicit feedback, equal to 0 if not supported, equal to 1 for delayed feedback, equal to 2 for immediate feedback, equal to 3 for delayed and immediate feedback. See 9.4.2.56.6" ::= { dot11RMNeighborReportEntry 60 } dot11RMNbRprtHTExplicitNonCompressedBeamformingFeedbackCap OBJECT-TYPE SYNTAX Unsigned32 (0..3) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates whether this receiver can return noncompressed 2978 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications beamforming feedback matrix explicit feedback, equal to 0 if not supported, equal to 1 for delayed feedback, equal to 2 for immediate feedback, equal to 3 for delayed and immediate feedback. See 9.4.2.56.6" ::= { dot11RMNeighborReportEntry 61 } dot11RMNeighborReportHTExplicitCompressedBeamformingFeedbackCap OBJECT-TYPE SYNTAX Unsigned32 (0..3) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates whether this receiver can return compressed beamforming feedback matrix explicit feedback, equal to 0 if not supported, equal to 1 for delayed feedback, equal to 2 for immediate feedback, equal to 3 for delayed and immediate feedback. See 9.4.2.56.6" ::= { dot11RMNeighborReportEntry 62 } dot11RMNeighborReportHTTransmitBeamformingMinimalGrouping OBJECT-TYPE SYNTAX Unsigned32 (0..3) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates the minimal grouping used for explicit feedback reports, equal to 0 if the STA supports groups of 1 (no grouping), equal to 1 to indicate groups of 1, 2, equal to 2 to indicate groups of 1, 4, equal to 3 to indicate groups of 1, 2, 4. See 9.4.2.56.6" ::= { dot11RMNeighborReportEntry 63 } dot11RMNbRprtHTCSINumberofTxBeamformingAntennasSuppt OBJECT-TYPE SYNTAX Unsigned32 (0..3) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates the maximum number of beamformer antennas the beamformee can support when CSI feedback is required, equal to 0 for single Tx antenna sounding, equal to 1 for 2 Tx antenna sounding, equal to 2 for 3 Tx antenna sounding, equal to 3 for 4 Tx antenna sounding. See 9.4.2.56.6" ::= { dot11RMNeighborReportEntry 64 } dot11RMNbRprtHTNonCompressedSteeringNumofTxBmfmingAntennasSuppt OBJECT-TYPE SYNTAX Unsigned32 (0..3) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates the maximum number of beamformer antennas the beamformee can support when noncompressed beamforming feedback matrix is required, equal to 0 for single Tx antenna sounding, equal to 1 for 2 Tx antenna sounding, equal to 2 for 3 Tx antenna sounding, equal to 3 for 4 Tx antenna sounding. See 9.4.2.56.6" ::= { dot11RMNeighborReportEntry 65 } dot11RMNbRprtHTCompressedSteeringNumberofTxBmfmingAntennasSuppt OBJECT-TYPE 2979 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications SYNTAX Unsigned32 (0..3) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates the maximum number of beamformer antennas the beamformee can support when compressed beamforming feedback matrix is required, equal to 0 for single Tx antenna sounding, equal to 1 for 2 Tx antenna sounding, equal to 2 for 3 Tx antenna sounding, equal to 3 for 4 Tx antenna sounding. See 9.4.2.56.6" ::= { dot11RMNeighborReportEntry 66 } dot11RMNbRprtHTCSIMaxNumberofRowsTxBeamformingSuppt OBJECT-TYPE SYNTAX Unsigned32 (0..3) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates the maximum number of rows of CSI explicit feedback from the beamformee or calibration responder or transmit ASEL responder that a beamformer or calibration initiator or transmit ASEL initiator can support when SCI feedback is required, equal to 0 for a single row of CSI, equal to 1 for 2 rows of CSI, equal to 2 for 3 rows of CSI, equal to 3 for 4 rows of CSI. See 9.4.2.56.6" ::= { dot11RMNeighborReportEntry 67 } dot11RMNeighborReportHTTransmitBeamformingChannelEstimationCap OBJECT-TYPE SYNTAX Unsigned32 (0..3) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates the maximum number of space-time streams for which channel dimensions can be simultaneously estimated when receiving an NDP sounding PPDU or the extension portion of the HT-LTFs in a staggered sounding PPDU. Equal to 0 for 1 space-time stream, equal to 1 for 2 space- time streams, equal to 2 for 3 space-time streams, equal to 3 for 4 space- time streams. See 9.4.2.56.6" ::= { dot11RMNeighborReportEntry 68 } dot11RMNeighborReportHTAntSelectionCap OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates whether this STA supports ASEL, equal to false if not supported, equal to true if supported. See 9.4.2.56.7" ::= { dot11RMNeighborReportEntry 69} dot11RMNeighborReportHTExplicitCSIFeedbackBasedTxASELCap OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. 2980 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications It is written by the SME when a measurement report is completed. This variable indicates whether this STA has transmit ASEL capability based on explicit CSI feedback, equal to false if not supported, equal to true if supported. See 9.4.2.56.7" ::= { dot11RMNeighborReportEntry 70 } dot11RMNeighborReportHTAntIndicesFeedbackBasedTxASELCap OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates whether this STA has transmit ASEL capability based on antenna indices feedback, equal to false if not supported, equal to true if supported. See 9.4.2.56.7" ::= { dot11RMNeighborReportEntry 71 } dot11RMNeighborReportHTExplicitCSIFeedbackBasedCap OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates whether this STA can compute CSI and feedback in support of ASEL, equal to false if not supported, equal to true is supported. See 9.4.2.56.7" ::= { dot11RMNeighborReportEntry 72 } dot11RMNeighborReportHTAntIndicesFeedbackCap OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates whether this STA has Rx ASEL capability, equal to false if not supported, equal to true if supported. See 9.4.2.56.7" ::= { dot11RMNeighborReportEntry 73 } dot11RMNeighborReportHTRxASELCap OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates whether this STA has Rx ASEL capability, equal to false if not supported, equal to true if supported. See 9.4.2.56.7" ::= { dot11RMNeighborReportEntry 74 } dot11RMNeighborReportHTTxSoundingPPDUsCap OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. 2981 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This variable indicates whether this STA can transmit sounding PPDUs for ASEL training per request, equal to false if not supported, equal to true if supported. See 9.4.2.56.7" ::= { dot11RMNeighborReportEntry 75 } dot11RMNeighborReportHTInfoPrimaryChannel OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates the channel number of the primary channel, encoding: channel number of the primary channel. See 9.4.2.57" ::= { dot11RMNeighborReportEntry 76 } dot11RMNeighborReportHTInfoSecChannelOffset OBJECT-TYPE SYNTAX Unsigned32 (0..3) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates the offset of the secondary channel relative to the primary channel, equal to 1 if the secondary channel is above the primary channel, equal to 3 if the secondary channel is below the primary channel, equal to 0 if no secondary channel is present. The value 2 is reserved. See 9.4.2.57" ::= { dot11RMNeighborReportEntry 77 } dot11RMNeighborReportHTInfoSTAChannelWidth OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable defines the channel widths that may be used to transmit to the STA, equal to false for a 20 MHz channel width, equal to true allows use of any channel width in the supported channel width set. See 9.4.2.57" ::= { dot11RMNeighborReportEntry 78 } dot11RMNeighborReportHTInfoRIFSMode OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates whether use of RIFS is permitted within the BSS, equal to false if use of RIFS is prohibited, equal to true if use of RIFS is permitted. See 9.4.2.57" ::= { dot11RMNeighborReportEntry 79} dot11RMNeighborReportHTInfoProtection OBJECT-TYPE SYNTAX Unsigned32 (0..3) MAX-ACCESS read-create STATUS current DESCRIPTION 2982 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates protection requirements of HT transmissions. Equal to 0 if all STAs detected in the primary or the secondary channel or that are a member of this BSS are HT STAs and either all STAs that are known by the transmitting STA to be a member of this BSS are 20/40 MHz HT in a 20/ 40 MHz BSS or this BSS is a 20 MHz BSS. Equal to 1 (nonmember protection mode) if there is at least one non-HT STA detected in either the primary or the secondary channel or in both the primary and secondary channels and that is not known by the transmitting STA to be a member of this BSS and all STAs that are known by the transmitting STA to be a member of this BSS are HT STAs. Equal to 2 if all STAs detected in the primary or the secondary channel or that are known by the transmitting STA to be a member of this BSS are HT STAs and this BSS is a 20/40 MHz BSS and there is at least one 20 MHz HT STA associated with this BSS. Equal to 3 (non-HT mixed mode) otherwise. See 9.4.2.56.2" ::= { dot11RMNeighborReportEntry 80 } dot11RMNeighborReportHTInfoNonGreenfieldHTSTAsPresent OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates if any HT STAs that are not HT-greenfield capable have associated. Determines when a non-AP STA should use HT-greenfield protection. Present in Beacon and Probe Response frames transmitted by an AP. Equal to false if all HT STAs that are associated are HT-greenfield capable, equal to true if one or more HT STAs that are not HT-greenfield capable are associated. See 9.4.2.57" ::= { dot11RMNeighborReportEntry 81 } dot11RMNeighborReportHTInfoOBSSNonHTSTAsPresent OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates if the use of protection for non-HT STAs by OBSSs is determined to be desirable. Present in Beacon and Probe Response frames transmitted by an AP, equal to true if the use of protection for non-HT STAs by OBSSs is determined to be desirable, equal to false otherwise. See 9.4.2.57" ::= { dot11RMNeighborReportEntry 82 } dot11RMNeighborReportHTInfoDualBeacon OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates whether the AP transmits an STBC beacon, equal to false if no STBC beacon is transmitted, equal to true if an STBC beacon is transmitted. See 9.4.2.57" ::= { dot11RMNeighborReportEntry 83 } dot11RMNeighborReportHTInfoDualCTSProtection OBJECT-TYPE 2983 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable is used by the AP to set a NAV at STAs that do not support STBC and at STAs that can associate solely through the secondary beacon, equal to false if dual CTS protection is not required, equal to true if dual CTS protection is required. See 9.4.2.57" ::= { dot11RMNeighborReportEntry 84 } dot11RMNeighborReportHTInfoSTBCBeacon OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates whether the beacon containing this element is a primary or a STBC beacon, equal to false in a primary beacon, equal to true in a STBC beacon. See 9.4.2.57" ::= { dot11RMNeighborReportEntry 85 } dot11RMNeighborReportHTInfoLSIGTXOPProtectionSup OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates whether all HT STA in the BSS support L-SIG TXOP protection, equal to false if one or more HT STA in the BSS do not support L-SIG TXOP protection, equal to true if all HT STA in the BSS support L- SIG TXOP protection. See 9.4.2.57" ::= { dot11RMNeighborReportEntry 86 } dot11RMNeighborReportHTInfoPCOActive OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates whether PCO is active in the BSS, equal to false if PCO is not active in the BSS, equal to true if PCO is active in the BSS. See 9.4.2.57" ::= { dot11RMNeighborReportEntry 87} dot11RMNeighborReportHTInfoPCOPhase OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates the PCO phase of operation, equal to false indicates a switch to or continued 20 MHz phase, equal to true indicates a switch to or continuation of 40 MHz phase. See 9.4.2.57" 2984 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ::= { dot11RMNeighborReportEntry 88 } dot11RMNeighborReportHTInfoBasicMCSSet OBJECT-TYPE SYNTAX OCTET STRING (SIZE(16)) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates values that are supported by all HT STAs in the BSS. The Basic HT-MCS Set is a bitmap of size 128 bits. Bit 0 corresponds to MCS 0. A bit is equal to 1 to indicate support for that MCS, equal to 0 otherwise. See 9.4.2.57" ::= { dot11RMNeighborReportEntry 89 } dot11RMNeighborReportHTSecChannelOffset OBJECT-TYPE SYNTAX Unsigned32 (0..3) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates the position of the secondary channel relative to the primary channel, equal to 1 to indicate that the secondary channel is above the primary channel, equal to 3 to indicate the secondary channel is below the primary channel, equal to 0 to indicate that no secondary channel is present. The value 2 is reserved. See 9.4.2.20" ::= { dot11RMNeighborReportEntry 90 } dot11RMNeighborReportExtCapPSMPSupport OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates support for PSMP operation, equal to false if PSMP is not supported, equal to true if PSMP operation is supported. See 9.4.2.27" ::= { dot11RMNeighborReportEntry 91 } dot11RMNeighborReportExtCapSPSMPSup OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a measurement report is completed. This variable indicates support for scheduled PSMP, equal to false when PSMP is supported is equal to false and when the PSMP Capability field is equal to 1 if the STA does not support S-PSMP, equal to true when the PSMP Capability field is equal to 1 if the STA supports S-PSMP. See 9.4.2.27." ::= { dot11RMNeighborReportEntry 92 } dot11RMNeighborReportExtCapServiceIntervalGranularity OBJECT-TYPE SYNTAX Unsigned32 (0..7) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. 2985 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications It is written by the SME when a measurement report is completed. This variable indicates the duration of the shortest SI, equal to 0 for 5 ms, equal to 1 for 10 ms, equal to 2 for 15 ms, equal to 3 for 20 ms, equal to 4 for 25 ms, equal to 5 for 30 ms, equal to 6 for 35 ms, equal to 7 for 40 ms. See 9.4.2.27." ::= { dot11RMNeighborReportEntry 93 } dot11RMNeighborReportBSSTransitCandPreference OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute indicates the network preference for BSS transition to the BSS listed in this BSS Transition Candidate List Entries field in the BSS Transition Management Request frame, BSS Transition Management Query frame and BSS Transition Management Response frame. The Preference field value is a number ranging from 0 to 255 indicating an ordering of preferences for the BSS transition candidates for this STA. The value 0 indicates an excluded BSS. The values 1-255 the preferred relative ordering of BSSs, with 255 indicating the most preferred candidate and 1 indicating the least preferred candidate. Additional details describing use of the Preference field are provided in 11.24.7.3." ::= { dot11RMNeighborReportEntry 94 } dot11RMNeighborReportBSSTerminationTSF OBJECT-TYPE SYNTAX TSFType MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute indicates the value of the TSF timer when the BSS termination will occur in the future. A BSS Termination TSF field value of 0 indicates that termination of the BSS will occur imminently. Prior to termination of the BSS, all associated STAs are disassociated by the AP." ::= { dot11RMNeighborReportEntry 95 } dot11RMNeighborReportBSSTerminationDuration OBJECT-TYPE SYNTAX Unsigned32 (1..65535) UNITS "minutes" MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute indicates the number of minutes for which the BSS is not present. The Duration field value of 0 is reserved. The Duration field value is set to 65 535 when the BSS is terminated for a period longer than or equal to 65 535 minutes." ::= { dot11RMNeighborReportEntry 96 } -- ******************************************************************** -- * End of dot11RMNeighborReport TABLE -- ******************************************************************** -- ******************************************************************** -- * END of Radio Measurement Interface MIB -- ******************************************************************** -- ******************************************************************** -- * Wireless Network Management Interface MIB -- ******************************************************************** dot11WirelessNetworkManagement OBJECT IDENTIFIER ::= { dot11smt 22 } -- ******************************************************************** -- * Wireless network management requests 2986 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications -- ******************************************************************** dot11WNMRequest OBJECT IDENTIFIER ::= { dot11WirelessNetworkManagement 1 } -- ******************************************************************** -- * dot11WNMRequest TABLE -- ******************************************************************** dot11WNMRequestNextIndex OBJECT-TYPE SYNTAX Unsigned32(0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when able to accept a new request. Identifies a hint for the next value of dot11WNMRqstIndex to be used in a row creation attempt for dot11WNMRequestTable. If no new rows can be created for some reason, such as memory, processing requirements, etc, the SME shall set this attribute to 0. It shall update this attribute to a proper value other than 0 as soon as it is capable of receiving new measurement requests. The nextIndex is not necessarily sequential nor monotonically increasing." ::= { dot11WNMRequest 1 } dot11WNMRequestTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11WNMRequestEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This group contains the current list of requests for WNM reports to be issued and have been issued until removed. A network manager adds a WNM request by creating a row with createAndWait row status and then filling in the request parameters/attributes. The request becomes active to be issued when the row status is set to Active. The columnar objects or attributes other than the rowStatus shall not be written if the rowStatus is Active. The request rows can be deleted, if commanded by a network manager via changing the value of dot11WNMRqstRowStatus to Destroy. This may leave orphaned rows if a manager crashes and forgets which rows are being used by it. One recommended way to manage orphaned or finished rows is to delete rows if their dot11WNMRqstRowStatus remains other than Active for longer than a period (recommend at least 5 minutes, IETF RFC 2579). Or another recommended way is to delete older rows as needed based on their dot11WNMRqstTimeStamp values. This can be done by the agent as well as the manager." ::= { dot11WNMRequest 2 } dot11WNMRequestEntry OBJECT-TYPE SYNTAX Dot11WNMRequestEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11WNMRequestTable Indexed by dot11WNMRqstIndex." INDEX { dot11WNMRqstIndex } ::= { dot11WNMRequestTable 1 } Dot11WNMRequestEntry ::= SEQUENCE { dot11WNMRqstIndex Unsigned32, dot11WNMRqstRowStatus RowStatus, dot11WNMRqstToken OCTET STRING, dot11WNMRqstIfIndex InterfaceIndex, dot11WNMRqstType INTEGER, dot11WNMRqstTargetAdd MacAddress, dot11WNMRqstTimeStamp TimeTicks, 2987 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11WNMRqstRndInterval Unsigned32, dot11WNMRqstDuration Unsigned32, dot11WNMRqstMcstGroup MacAddress, dot11WNMRqstMcstTrigCon OCTET STRING, dot11WNMRqstMcstTrigInactivityTimeout Unsigned32, dot11WNMRqstMcstTrigReactDelay Unsigned32, dot11WNMRqstLCRRqstSubject INTEGER, dot11WNMRqstLCRIntervalUnits INTEGER, dot11WNMRqstLCRServiceInterval Unsigned32, dot11WNMRqstLIRRqstSubject INTEGER, dot11WNMRqstLIRIntervalUnits INTEGER, dot11WNMRqstLIRServiceInterval Unsigned32, dot11WNMRqstEventToken Unsigned32, dot11WNMRqstEventType INTEGER, dot11WNMRqstEventResponseLimit Unsigned32, dot11WNMRqstEventTargetBssid MacAddress, dot11WNMRqstEventSourceBssid MacAddress, dot11WNMRqstEventTransitTimeThresh Unsigned32, dot11WNMRqstEventTransitMatchValue OCTET STRING, dot11WNMRqstEventFreqTransitCountThresh Unsigned32, dot11WNMRqstEventFreqTransitInterval Unsigned32, dot11WNMRqstEventRsnaAuthType OCTET STRING, dot11WNMRqstEapType Unsigned32, dot11WNMRqstEapVendorId OCTET STRING, dot11WNMRqstEapVendorType OCTET STRING, dot11WNMRqstEventRsnaMatchValue OCTET STRING, dot11WNMRqstEventPeerMacAddress MacAddress, dot11WNMRqstOperatingClass Unsigned32, dot11WNMRqstChanNumber Unsigned32, dot11WNMRqstDiagToken Unsigned32, dot11WNMRqstDiagType INTEGER, dot11WNMRqstDiagTimeout Unsigned32, dot11WNMRqstDiagBssid MacAddress, dot11WNMRqstDiagProfileId Unsigned32, dot11WNMRqstDiagCredentials INTEGER, dot11WNMRqstLocConfigLocIndParams OCTET STRING, dot11WNMRqstLocConfigChanList OCTET STRING, dot11WNMRqstLocConfigBcastRate Unsigned32, dot11WNMRqstLocConfigOptions OCTET STRING, dot11WNMRqstBssTransitQueryReason INTEGER, dot11WNMRqstBssTransitReqMode OCTET STRING, dot11WNMRqstBssTransitDisocTimer Unsigned32, dot11WNMRqstBssTransitSessInfoURL OCTET STRING, dot11WNMRqstBssTransitCandidateList OCTET STRING, dot11WNMRqstColocInterfAutoEnable TruthValue, dot11WNMRqstColocInterfRptTimeout Unsigned32, dot11WNMRqstVendorSpecific OCTET STRING, dot11WNMRqstDestinationURI OCTET STRING } dot11WNMRqstIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index for WNM Request elements in dot11WNMRequestTable, greater than 0." ::= { dot11WNMRequestEntry 1 } dot11WNMRqstRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. 2988 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications It is written by an external management entity when requesting a measurement, and by the SME when accepting a management request. The Row Status column of the current row, used for tracking status of an individual request. When this attribute is set to Active, AND a measurement request can be unambiguously created based on the parameters in the row, then the MLME may proceed to issue the request to its intended targets when appropriate. If not, this attribute may be set to Not-ready immediately to indicate parametric errors. However, it is the network managers responsibility to correct the error. If the request is successfully issued to the target STA, then the rowStatus is set to notInService." ::= { dot11WNMRequestEntry 2 } dot11WNMRqstToken OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when the table entry is created, i.e., when requesting a measurement. Changes take effect when dot11RMRqstRowStatus is set to Active. This attribute indicates a unique string to identify this request. To guarantee the uniqueness of this token across multiple network managers, it is recommended that this token be prefixed with the IP address of the network manager creating this row. This token is not necessarily equivalent to the measurement tokens in WNM request frames." ::= { dot11WNMRequestEntry 3 } dot11WNMRqstIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-create STATUS current DESCRIPTION "The ifIndex for this row of WNM Request to be issued on." ::= { dot11WNMRequestEntry 4 } dot11WNMRqstType OBJECT-TYPE SYNTAX INTEGER { mcastDiagnostics(0), locationCivic(1), locationIdentifier(2), event(3), dignostic(4), locationConfiguration(5), bssTransitionQuery(6), bssTransitionRqst(7), fms(8), colocInterference(9) } MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute indicates the request type of this WNM request row." ::= { dot11WNMRequestEntry 5 } dot11WNMRqstTargetAdd OBJECT-TYPE SYNTAX MacAddress 2989 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. The MAC address of STA for this row of WNM Request is to be issued to. If this attribute matches the MAC address of the dot11WNMRqstIfIndex, then measurement request is for this STA itself to carry out." ::= { dot11WNMRequestEntry 6 } dot11WNMRqstTimeStamp OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute indicates the SysUpTime Value the last time when the dot11WNMRqstRowStatus is set to active or when this row is created the first time. This attribute shall be set by this STA or AP automatically, not by an SNMP manager." ::= { dot11WNMRequestEntry 7 } dot11WNMRqstRndInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "TUs" MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute indicates the upper bound of the random delay to be used prior to making the measurement. See 11.11.3." DEFVAL { 0 } ::= { dot11WNMRequestEntry 8 } dot11WNMRqstDuration OBJECT-TYPE SYNTAX Unsigned32 UNITS "TUs" MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute indicates the preferred or mandatory measurement duration for this Measurement Request." DEFVAL { 0 } ::= { dot11WNMRequestEntry 9 } dot11WNMRqstMcstGroup OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management 2990 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications request. Changes take effect when dot11WNMRqstRowStatus is set to Active. Multicast Group address indicates the MAC address of the multicast group for which diagnostics are requested. The BSSID shall be set to the wildcard BSSID when the measurement is to be performed on any multicast group on the operating channel. This attribute is valid only if the dot11WNMRqstType is 10, indicating a multicast diagnostic request, and is ignored otherwise." DEFVAL { 'FFFFFFFFFFFF'H } ::= { dot11WNMRequestEntry 10 } dot11WNMRqstMcstTrigCon OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1)) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute indicates the trigger condition for the Multicast Diagnostic request." ::= { dot11WNMRequestEntry 11 } dot11WNMRqstMcstTrigInactivityTimeout OBJECT-TYPE SYNTAX Unsigned32 (1..255) UNITS "100 TUs" MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute indicates the time interval value to be use as the threshold value for Trigger Inactivity Timeout trigger condition." ::= { dot11WNMRequestEntry 12 } dot11WNMRqstMcstTrigReactDelay OBJECT-TYPE SYNTAX Unsigned32 (1..255) UNITS "100 TUs" MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute indicates the time interval value during which a measuring STA does not generate further multicast triggered reports after a trigger condition has been met." ::= { dot11WNMRequestEntry 13 } dot11WNMRqstLCRRqstSubject OBJECT-TYPE SYNTAX INTEGER { local(0), remote(1) } MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. 2991 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The attribute indicates the subject of the Location Civic request." DEFVAL { 0 } ::= { dot11WNMRequestEntry 14 } dot11WNMRqstLCRIntervalUnits OBJECT-TYPE SYNTAX INTEGER { seconds(0), minutes(1), hours(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute indicates the units used in the Location Civic Request Service Interval." ::= { dot11WNMRequestEntry 15 } dot11WNMRqstLCRServiceInterval OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute indicates the time interval, expressed in the units indicated in the Location Civic Request Service Interval Units field, at which the STA requests to receive Location Civic reports. A Location Civic Request Service Interval of 0 indicates that only a single Location Civic report is requested." ::= { dot11WNMRequestEntry 16 } dot11WNMRqstLIRRqstSubject OBJECT-TYPE SYNTAX INTEGER { local(0), remote(1) } MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. The attribute indicates the subject of the Location Identifier request." DEFVAL { 0 } ::= { dot11WNMRequestEntry 17 } dot11WNMRqstLIRIntervalUnits OBJECT-TYPE SYNTAX INTEGER { seconds(0), minutes(1), hours(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. 2992 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute indicates the units used in the Location Identifier request Service Interval." ::= { dot11WNMRequestEntry 18 } dot11WNMRqstLIRServiceInterval OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute indicates the time interval, expressed in the units indicated in the Location Identifier Request Interval Units field, at which the STA requests to receive Location Identifier reports. A Location Identifier Request Service Interval of 0 indicates that only a single Location Identifier report is requested." ::= { dot11WNMRequestEntry 19 } dot11WNMRqstEventToken OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute indicates a unique string to identify this request." ::= { dot11WNMRequestEntry 20 } dot11WNMRqstEventType OBJECT-TYPE SYNTAX INTEGER { transition(0), rsna(1), peerToPeer(2), wnmLog(3), vendorSpecific(221) } MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute indicates the request type of this WNM Event request." ::= { dot11WNMRequestEntry 21 } dot11WNMRqstEventResponseLimit OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute indicates the maximum number of requested Event Reports to be included in the Event Report element. A value of 0 indicates that no 2993 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications limit is set on the number of Event Reports to be included in the Event Report element." ::= { dot11WNMRequestEntry 22 } dot11WNMRqstEventTargetBssid OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute is used to request that a Transition or RSNA Event Report includes the event entry when the target BSSID is equal to the indicated BSSID. A transition event is a STA movement or attempted movement from one BSS (the source BSS) in one ESS to another BSS (the target BSS) within the same ESS. The BSSID shall be set to the wildcard BSSID when the transitions to any BSSID is requested." DEFVAL { 'FFFFFFFFFFFF'H } ::= { dot11WNMRequestEntry 23 } dot11WNMRqstEventSourceBssid OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute is used to request that a Transition Event Report includes the transition event entry when the source BSSID is equal to the indicated BSSID. A transition event is a STA movement or attempted movement from one BSS (the source BSS) in one ESS to another BSS (the target BSS) within the same ESS. The BSSID shall be set to the wildcard BSSID when the transitions from any BSSID is requested." DEFVAL { 'FFFFFFFFFFFF'H } ::= { dot11WNMRequestEntry 24 } dot11WNMRqstEventTransitTimeThresh OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "TUs" MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute indicates a value representing the transition time to be used as the threshold value for the Transition Time condition in TUs. The Transition Time is defined in 11.24.2.2" ::= { dot11WNMRequestEntry 25 } dot11WNMRqstEventTransitMatchValue OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1)) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. 2994 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This attribute indicates a request for the specified transition results that match the bit descriptions of this field. B0 indicates match when transition is successful. B1 indicates match when transition fails." ::= { dot11WNMRequestEntry 26 } dot11WNMRqstEventFreqTransitCountThresh OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute indicates the minimum number of matching transitions detected in the measurement duration to generate a Transition Event report." ::= { dot11WNMRequestEntry 27 } dot11WNMRqstEventFreqTransitInterval OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "TUs" MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute indicates the sliding window time interval during which the STA detects matching transitions to determine if the Frequent Transition Count Threshold is exceeded in order to generate a Transition Event report." ::= { dot11WNMRequestEntry 28 } dot11WNMRqstEventRsnaAuthType OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4)) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute is used to request that an RSNA Event Report include the event entry when its RSNA Authentication Type matches the indicated RSNA authentication type value." ::= { dot11WNMRequestEntry 29 } dot11WNMRqstEapType OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute is used to request that an RSNA Event Report include the event entry when its EAP Type matches the indicated EAP type value. Valid EAP Type numbers are assigned by IANA and are defined at http:// www.iana.org/assignments/eap-numbers." ::= { dot11WNMRequestEntry 30 } 2995 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11WNMRqstEapVendorId OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..3)) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute is used to request that an RSNA Event Report include the event entry when its EAP Vendor ID matches the indicated vendor ID value. The EAP Vendor ID field is included when the EAP Type field is set to 254 and is excluded otherwise." ::= { dot11WNMRequestEntry 31 } dot11WNMRqstEapVendorType OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..4)) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute is used to request that an RSNA Event Report include the event entry when its EAP Vendor Type matches the indicated EAP vendor type value. The EAP Vendor ID field is included when the EAP Type field is set to 254 and is excluded otherwise." ::= { dot11WNMRequestEntry 32 } dot11WNMRqstEventRsnaMatchValue OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1)) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute indicates a request for the specified transition results that match the bit descriptions of this field. B0 (least significant bit) indicates match when RSNA is successful. B1 indicates match when RSNA fails." ::= { dot11WNMRequestEntry 33 } dot11WNMRqstEventPeerMacAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute is used to request that a peer-to-peer event report includes the transition event entry when the MAC address of the peer STA or IBSS BSSID is equal to the indicated MAC address. The MAC address shall be set to the wildcard BSSID when the transitions from any peer STA or IBSS BSSID is requested." DEFVAL { 'FFFFFFFFFFFF'H } ::= { dot11WNMRequestEntry 34 } dot11WNMRqstOperatingClass OBJECT-TYPE SYNTAX Unsigned32(1..255) 2996 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute indicates the channel set for this WNM request. Country, Operating Class and Channel Number together specify the channel frequency and spacing for this measurement request. Valid values of Operating Class are shown in Annex E." ::= { dot11WNMRequestEntry 35 } dot11WNMRqstChanNumber OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute indicates the current operating channel for this WNM request. The Channel Number is defined only within the indicated Operating Class as shown in Annex E." ::= { dot11WNMRequestEntry 36 } dot11WNMRqstDiagToken OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute indicates a unique string to identify this request." ::= { dot11WNMRequestEntry 37 } dot11WNMRqstDiagType OBJECT-TYPE SYNTAX INTEGER { cancelRequest(0), manufacturerInfoStaRep(1), configurationProfile(2), associationDiag(3), ieee8021xAuthDiag(4), vendorSpecific(221) } MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute indicates the request type of this WNM Diagnostic request." ::= { dot11WNMRequestEntry 38 } dot11WNMRqstDiagTimeout OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION 2997 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute indicates a value representing the time interval after a Diagnostic Report is generated during which no additional Diagnostic Reports shall be sent." ::= { dot11WNMRequestEntry 39 } dot11WNMRqstDiagBssid OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute indicates a request for a Diagnostic Report from the indicated BSSID. The BSSID shall be set to the wildcard BSSID when diagnostics from any BSSID is requested." DEFVAL { 'FFFFFFFFFFFF'H } ::= { dot11WNMRequestEntry 40 } dot11WNMRqstDiagProfileId OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute indicates a unique identifier for referencing a configuration profile available on a device. The value of the identifier can be any arbitrary value, as long as it is uniquely associated to a single configuration profile on the device sending the identifier." ::= { dot11WNMRequestEntry 41 } dot11WNMRqstDiagCredentials OBJECT-TYPE SYNTAX INTEGER { none(0), preSharedKey(1), usernamePassword(2), x509Certificate(3), otherCertificate(4), oneTimePassword(5), token(6) } MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute indicates the type of credential used for the IEEE 802.1X authentication." ::= { dot11WNMRequestEntry 42 } dot11WNMRqstLocConfigLocIndParams OBJECT-TYPE SYNTAX OCTET STRING (SIZE(16)) MAX-ACCESS read-create STATUS current 2998 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute indicates STA Location reporting characteristics. The format of these Location Indication Parameters are detailed in 9.4.2.71.2." ::= { dot11WNMRequestEntry 43 } dot11WNMRqstLocConfigChanList OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..252)) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute lists location reporting channel information for this location configuration request. The default value is null. Each pair of octets indicates a different operating class and channel number for this request. The detailed format for this list of channels is described in 9.4.2.71.3." DEFVAL { ''H } ::= { dot11WNMRequestEntry 44 } dot11WNMRqstLocConfigBcastRate OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "0.5 Mb/s" MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute indicates the target data rate at which the STA transmits Location Track Notification frames. A value of 0 indicates the STA transmits Location Track Notification frames at a rate chosen by the STA transmitting the Location Track Notification frames." ::= { dot11WNMRequestEntry 45 } dot11WNMRqstLocConfigOptions OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute indicates the location track indication options used; see 9.4.2.71.9." DEFVAL { ''H } ::= { dot11WNMRequestEntry 46 } dot11WNMRqstBssTransitQueryReason OBJECT-TYPE SYNTAX INTEGER { unspecified(0), excessiveFrameLossRatesPoorConditions(1), excessiveDelayForCurrentTrafficStreams(2), insufficientQosCapacityForCurrentTrafficStreams(3), firstAssociationToEss(4), 2999 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications loadBalancing(5), betterApFound(6), deauthenticatedDisassociatedFromPreviousAp(7), apFailedIeee8021XEapAuthentication(8), apFailed4wayHandshake(9), receivedTooManyReplayCounterFailures(10), receivedTooManyDataMICFailures(11), exceededMaxNumberOfRetransmissions(12), receivedTooManyBroadcastDisassociations(13), receivedTooManyBroadcastDeauthentications(14), previousTransitionFailed(15), lowRSSI(16) } MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute indicates the reason for the BSS Transition Query. The format for this list of reasons is further detailed in 9.4.2.68.2." ::= { dot11WNMRequestEntry 47 } dot11WNMRqstBssTransitReqMode OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1)) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute indicates the type of BSS request transition. B0 (least significant bit) indicates the Preferred Candidate list is included in this frame. B1 indicates an abridged format for all BSSIDs not listed in this frame. B2 indicates that the STA will be disassociated for the current AP. B3 indicates the BSS is shutting down and that the STA will be disassociated. B4 indicates that the will be disassociated from the ESS. The format for this field is detailed in 9.6.14.9." ::= { dot11WNMRequestEntry 48 } dot11WNMRqstBssTransitDisocTimer OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute indicates the number of TBTTs until the serving AP sends a Disassociation frame to this STA. The value 0 indicates unknown. If the Disassociation Imminent bit of the Request Mode field is set to 0, this field is ignored." ::= { dot11WNMRequestEntry 49 } dot11WNMRqstBssTransitSessInfoURL OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management 3000 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute contains a variable-length field formatted in accordance with IETF RFC 3986-2005." ::= { dot11WNMRequestEntry 50 } dot11WNMRqstBssTransitCandidateList OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..11426)) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute lists one or more Neighbor Report elements described in 9.4.2.37. If the STA has no Transition Candidate information in response to the BSS Transition Management Query frame, the candidate list is null. " ::= { dot11WNMRequestEntry 51 } dot11WNMRqstColocInterfAutoEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute, when true, indicates that the requesting STA requests the receiving STA to send the Collocated Interference Response frames periodically with the Report Period interval, as defined in 9.6.14.13, or when the STA detects a change in the collocated interference." ::= { dot11WNMRequestEntry 52 } dot11WNMRqstColocInterfRptTimeout OBJECT-TYPE SYNTAX Unsigned32 (0..127) UNITS "100 TUs" MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute indicates the minimum duration between two consecutive Collocated Interference Response frames from the reporting STA." ::= { dot11WNMRequestEntry 53 } dot11WNMRqstVendorSpecific OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute provides an envelope for any optional vendor specific subelements that may be included in a WNM request element. The default value is null." DEFVAL { ''H } ::= { dot11WNMRequestEntry 54} 3001 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11WNMRqstDestinationURI OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..253)) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity when making a management request. Changes take effect when dot11WNMRqstRowStatus is set to Active. This attribute provides the Destination URI which defines an alternate destination for the WNM request. The alternate destination may be an internet address on an Ethernet adapter, for example, to be used when the wireless link to the requesting entity is unavailable or unreliable. The default value is null." DEFVAL { ''H } ::= { dot11WNMRequestEntry 55} -- ********************************************************************** -- * End of dot11WNMRequest TABLE -- ********************************************************************** -- ******************************************************************** -- * Wireless network management reports: -- * Report tables contain WNM reports received by this STA or -- * results of WNM requests performed by this STA. -- ******************************************************************** dot11WNMReport OBJECT IDENTIFIER ::= { dot11WirelessNetworkManagement 2 } -- ******************************************************************** -- * dot11WNMVendorSpecificReport TABLE -- ******************************************************************** dot11WNMVendorSpecificReportTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11WNMVendorSpecificReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Group contains the current list of Vendor Specific reports that have been received by the MLME. The report tables shall be maintained as FIFO to preserve freshness, thus the rows in this table can be deleted for memory constraints or other implementation constraints determined by the vendor. New rows shall have different RprtIndex values than those deleted within the range limitation of the index. One easy way is to increment RprtIndex for new reports being written in the table." ::= { dot11WNMReport 1 } dot11WNMVendorSpecificReportEntry OBJECT-TYPE SYNTAX Dot11WNMVendorSpecificReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11WNMVendorSpecificReportTable Indexed by dot11WNMVendorSpecificRprtIndex." INDEX { dot11WNMVendorSpecificRprtIndex } ::= { dot11WNMVendorSpecificReportTable 1 } Dot11WNMVendorSpecificReportEntry ::= SEQUENCE { dot11WNMVendorSpecificRprtIndex Unsigned32, dot11WNMVendorSpecificRprtRqstToken OCTET STRING, dot11WNMVendorSpecificRprtIfIndex InterfaceIndex, dot11WNMVendorSpecificRprtContent OCTET STRING } 3002 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11WNMVendorSpecificRprtIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index for Vendor Specific Report elements in dot11WNMVendorSpecificReportTable, greater than 0." ::= { dot11WNMVendorSpecificReportEntry 1 } dot11WNMVendorSpecificRprtRqstToken OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the request token that was indicated in the WNM request that generated this measurement report. This should be an exact match to the original dot11WNMRqstToken attribute. Note that there may be multiple entries in the table that match this value since a single request may generate multiple WNM reports." ::= { dot11WNMVendorSpecificReportEntry 2 } dot11WNMVendorSpecificRprtIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The ifIndex for this row of WNMVendorSpecific report has been received on." ::= { dot11WNMVendorSpecificReportEntry 3 } dot11WNMVendorSpecificRprtContent OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute provides an envelope for all of the vendor specific subelements that may be included in a WNM Vendor Specific request element. The default value is null." DEFVAL { ''H } ::= { dot11WNMVendorSpecificReportEntry 4 } -- ******************************************************************** -- * End of dot11WNMVendorSpecificReport TABLE -- ******************************************************************** -- ******************************************************************** -- * dot11WNMMulticastDiagnosticReport TABLE -- ******************************************************************** dot11WNMMulticastDiagnosticReportTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11WNMMulticastDiagnosticReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Group contains the current list of Multicast Diagnostic reports that have been received by the MLME. The report tables shall be maintained as FIFO to preserve freshness, thus the rows in this table can be deleted for memory constraints or other implementation constraints determined by the vendor. New rows shall have different RprtIndex values than those deleted 3003 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications within the range limitation of the index. One easy way is to increment RprtIndex for new reports being written in the table." ::= { dot11WNMReport 2 } dot11WNMMulticastDiagnosticReportEntry OBJECT-TYPE SYNTAX Dot11WNMMulticastDiagnosticReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11WNMMulticastDiagnosticReportTable Indexed by dot11WNMMulticastDiagnosticRprtIndex." INDEX { dot11WNMMulticastDiagnosticRprtIndex } ::= { dot11WNMMulticastDiagnosticReportTable 1 } Dot11WNMMulticastDiagnosticReportEntry ::= SEQUENCE { dot11WNMMulticastDiagnosticRprtIndex Unsigned32, dot11WNMMulticastDiagnosticRprtRqstToken OCTET STRING, dot11WNMMulticastDiagnosticRprtIfIndex InterfaceIndex, dot11WNMMulticastDiagnosticRprtMeasurementTime TSFType, dot11WNMMulticastDiagnosticRprtDuration Unsigned32, dot11WNMMulticastDiagnosticRprtMcstGroup MacAddress, dot11WNMMulticastDiagnosticRprtReason OCTET STRING, dot11WNMMulticastDiagnosticRprtRcvdMsduCount Unsigned32, dot11WNMMulticastDiagnosticRprtFirstSeqNumber Unsigned32, dot11WNMMulticastDiagnosticRprtLastSeqNumber Unsigned32, dot11WNMMulticastDiagnosticRprtMcstRate Unsigned32 } dot11WNMMulticastDiagnosticRprtIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index for Multicast Diagnostics reports in dot11WNMMulticastDiagnosticReportTable, greater than 0." ::= { dot11WNMMulticastDiagnosticReportEntry 1 } dot11WNMMulticastDiagnosticRprtRqstToken OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the request token that was indicated in the WNM request that generated this measurement report. This should be an exact match to the original dot11WNMRqstToken attribute. Note that there may be multiple entries in the table that match this value since a single request may generate multiple WNM reports." ::= { dot11WNMMulticastDiagnosticReportEntry 2 } dot11WNMMulticastDiagnosticRprtIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The ifIndex for this row of WNMMulticastDiagnostic report been received on." ::= { dot11WNMMulticastDiagnosticReportEntry 3 } dot11WNMMulticastDiagnosticRprtMeasurementTime OBJECT-TYPE SYNTAX TSFType MAX-ACCESS read-only 3004 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the value of the STA TSF timer at the time the measurement started. In a triggered Multicast Diagnostics report, this is the TSF value at the reporting STA when the trigger condition was met. When the reason for sending the report is Performance Measurement and the Multicast Received MSDU Count is nonzero, the Measurement Time field is set to the value of the STA TSF timer at the time of the first multicast MSDU received during the measurement interval." ::= { dot11WNMMulticastDiagnosticReportEntry 4 } dot11WNMMulticastDiagnosticRprtDuration OBJECT-TYPE SYNTAX Unsigned32 UNITS "TUs" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the period over which the Multicast Diagnostics report was generated." ::= { dot11WNMMulticastDiagnosticReportEntry 5 } dot11WNMMulticastDiagnosticRprtMcstGroup OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. Multicast Group address indicates the MAC address of the multicast group for this report element." ::= { dot11WNMMulticastDiagnosticReportEntry 6 } dot11WNMMulticastDiagnosticRprtReason OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the reason why the measuring STA sent the Multicast Diagnostics report. B0 (least significant bit) indicates Inactivity Timeout Trigger. B1 indicates the measurement result from the completed measurement. These are defined further in 9.4.2.22.12." ::= { dot11WNMMulticastDiagnosticReportEntry 7 } dot11WNMMulticastDiagnosticRprtRcvdMsduCount OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the total number of multicast MSDUs with the indicated Multicast MAC Address that were received during the Measurement Duration. In a triggered multicast diagnostics measurement this is the 3005 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications total number of MSDUs received between the acceptance of the multicast diagnostics measurement request and the occurrence of the trigger condition for MSDUs with the indicated Multicast MAC Address." ::= { dot11WNMMulticastDiagnosticReportEntry 8 } dot11WNMMulticastDiagnosticRprtFirstSeqNumber OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the twelve least significant bits of the First Sequence Number field. When the LSB of the first octet of the Multicast MAC address field in the multicast diagnostic request is set to 1, the twelve LSBs of the First Sequence Number field contain the sequence number of the first frame received with destination address equal to the value in the Multicast MAC address field during the measurement period. When the LSB of the first octet of the Multicast MAC address field in the multicast diagnostic request is set to 0, the twelve LSBs of the First Sequence Number field contain the sequence number of the first group addressed frame, that does not have the broadcast MAC address as its destination, received during the measurement period. The four most significant bits of the First Sequence Number field are set to 0. This field is set to 0 if the Multicast Received MSDU Count is 0." ::= { dot11WNMMulticastDiagnosticReportEntry 9 } dot11WNMMulticastDiagnosticRprtLastSeqNumber OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the twelve least significant bits of the Last Sequence Number field. When the LSB of the first octet of the Multicast MAC address field in the multicast diagnostic request is set to 1, the twelve LSBs of the Last Sequence Number field contain the sequence number of the last frame received with destination address equal to the value in the Multicast MAC address field during the measurement period. When the LSB of the first octet of the Multicast MAC address field in the multicast diagnostic request is 0, the twelve LSBs of the Last Sequence Number field contain the sequence number of the last group addressed frame, that does not have the broadcast MAC address as its destination, received during the measurement period. The four most significant bits of the Last Sequence Number field are set to 0. This field is set to 0 if the Multicast Received MSDU Count is 0." ::= { dot11WNMMulticastDiagnosticReportEntry 10 } dot11WNMMulticastDiagnosticRprtMcstRate OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "0.5 Mb/s" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the highest data rate at which the STA has received a group addressed frame during the measurement period. The Multicast Rate field is encoded with the MSB set to 1 to indicate that the data rate is in the basic rate set, and set to 0 to indicate that the data 3006 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications rate is not in the basic rate set. The remaining 15 bit value is multiplied by 0.5 Mb/s to indicate the data rate. The Multicast Rate field is set to 0 by the STA to indicate that it has not received a group addressed frame during the measurement period." ::= { dot11WNMMulticastDiagnosticReportEntry 11 } -- ******************************************************************** -- * End of dot11WNMMulticastDiagnosticReport TABLE -- ******************************************************************** -- ******************************************************************** -- * dot11WNMLocationCivicReport TABLE -- ******************************************************************** dot11WNMLocationCivicReportTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11WNMLocationCivicReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Group contains the current list of Location Civic reports that have been received by the MLME. The report tables shall be maintained as FIFO to preserve freshness, thus the rows in this table can be deleted for memory constraints or other implementation constraints determined by the vendor. New rows shall have different RprtIndex values than those deleted within the range limitation of the index. One easy way is to increment RprtIndex for new reports being written in the table." ::= { dot11WNMReport 3 } dot11WNMLocationCivicReportEntry OBJECT-TYPE SYNTAX Dot11WNMLocationCivicReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11WNMLocationCivicReportTable Indexed by dot11WNMLocationCivicRprtIndex." INDEX { dot11WNMLocationCivicRprtIndex } ::= { dot11WNMLocationCivicReportTable 1 } Dot11WNMLocationCivicReportEntry ::= SEQUENCE { dot11WNMLocationCivicRprtIndex Unsigned32, dot11WNMLocationCivicRprtRqstToken OCTET STRING, dot11WNMLocationCivicRprtIfIndex InterfaceIndex, dot11WNMLocationCivicRprtCivicLocation OCTET STRING } dot11WNMLocationCivicRprtIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index for Location Civic reports in dot11WNMLocationCivicReportTable, greater than 0." ::= { dot11WNMLocationCivicReportEntry 1 } dot11WNMLocationCivicRprtRqstToken OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the request token that was indicated in the WNM request that generated this measurement report. This should be an exact match to the original dot11WNMRqstToken attribute. Note that there may be 3007 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications multiple entries in the table that match this value since a single request may generate multiple WNM reports." ::= { dot11WNMLocationCivicReportEntry 2 } dot11WNMLocationCivicRprtIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The ifIndex for this row of WNMLocationCivic report been received on." ::= { dot11WNMLocationCivicReportEntry 3 } dot11WNMLocationCivicRprtCivicLocation OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates a variable octet field and contains a list of civic address elements in TLV format as defined in IETF RFC 4776." ::= { dot11WNMLocationCivicReportEntry 4} -- ******************************************************************** -- * End of dot11WNMLocationCivicReport TABLE -- ******************************************************************** -- ******************************************************************** -- * dot11WNMLocationIdentifierReport TABLE -- ******************************************************************** dot11WNMLocationIdentifierReportTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11WNMLocationIdentifierReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Group contains the current list of Location Identifier reports that have been received by the MLME. The report tables shall be maintained as FIFO to preserve freshness, thus the rows in this table can be deleted for memory constraints or other implementation constraints determined by the vendor. New rows shall have different RprtIndex values than those deleted within the range limitation of the index. One easy way is to increment RprtIndex for new reports being written in the table." ::= { dot11WNMReport 4 } dot11WNMLocationIdentifierReportEntry OBJECT-TYPE SYNTAX Dot11WNMLocationIdentifierReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11WNMLocationIdentifierReportTable Indexed by dot11WNMLocationIdentifierRprtIndex." INDEX { dot11WNMLocationIdentifierRprtIndex } ::= { dot11WNMLocationIdentifierReportTable 1 } Dot11WNMLocationIdentifierReportEntry ::= SEQUENCE { dot11WNMLocationIdentifierRprtIndex Unsigned32, dot11WNMLocationIdentifierRprtRqstToken OCTET STRING, dot11WNMLocationIdentifierRprtIfIndex InterfaceIndex, dot11WNMLocationIdentifierRprtExpirationTSF TSFType, dot11WNMLocationIdentifierRprtPublicIdUri OCTET STRING } dot11WNMLocationIdentifierRprtIndex OBJECT-TYPE 3008 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index for Location Identifier reports in dot11WNMLocationIdentifierReportTable, greater than 0." ::= { dot11WNMLocationIdentifierReportEntry 1 } dot11WNMLocationIdentifierRprtRqstToken OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the request token that was indicated in the WNM request that generated this measurement report. This should be an exact match to the original dot11WNMRqstToken attribute. Note that there may be multiple entries in the table that match this value since a single request may generate multiple WNM reports." ::= { dot11WNMLocationIdentifierReportEntry 2 } dot11WNMLocationIdentifierRprtIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The ifIndex for this row of WNMLocationIdentifier report been received on." ::= { dot11WNMLocationIdentifierReportEntry 3 } dot11WNMLocationIdentifierRprtExpirationTSF OBJECT-TYPE SYNTAX TSFType MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the value of the STA TSF timer when the Public Identifier URI/FQDN field value is no longer valid. The Expiration TSF field set to 0 indicates the Public Identifier URI/FQDN does not expire." ::= { dot11WNMLocationIdentifierReportEntry 4 } dot11WNMLocationIdentifierRprtPublicIdUri OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute contains concatenated Public Identifier URI/FQDN subelements, one per Public Identifier URI or FQDN. The format for a Public Identifier URI/FQDN subelement is further detailed in 9.4.2.22.14." ::= { dot11WNMLocationIdentifierReportEntry 5} -- ******************************************************************** -- * End of dot11WNMLocationIdentifierReport TABLE -- ******************************************************************** -- ******************************************************************** -- * dot11WNMEventTransitReport TABLE 3009 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications -- ******************************************************************** dot11WNMEventTransitReportTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11WNMEventTransitReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Group contains the current list of Transition Event reports that have been received by the MLME. The report tables shall be maintained as FIFO to preserve freshness, thus the rows in this table can be deleted for memory constraints or other implementation constraints determined by the vendor. New rows shall have different RprtIndex values than those deleted within the range limitation of the index. One easy way is to increment RprtIndex for new reports being written in the table." ::= { dot11WNMReport 5 } dot11WNMEventTransitReportEntry OBJECT-TYPE SYNTAX Dot11WNMEventTransitReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11WNMEventTransitReportTable Indexed by dot11WNMEventTransitRprtIndex." INDEX { dot11WNMEventTransitRprtIndex } ::= { dot11WNMEventTransitReportTable 1 } Dot11WNMEventTransitReportEntry ::= SEQUENCE { dot11WNMEventTransitRprtIndex Unsigned32, dot11WNMEventTransitRprtRqstToken OCTET STRING, dot11WNMEventTransitRprtIfIndex InterfaceIndex, dot11WNMEventTransitRprtEventStatus INTEGER, dot11WNMEventTransitRprtEventTSF TSFType, dot11WNMEventTransitRprtUTCOffset OCTET STRING, dot11WNMEventTransitRprtTimeError OCTET STRING, dot11WNMEventTransitRprtSourceBssid MacAddress, dot11WNMEventTransitRprtTargetBssid MacAddress, dot11WNMEventTransitRprtTransitTime Unsigned32, dot11WNMEventTransitRprtTransitReason INTEGER, dot11WNMEventTransitRprtTransitResult Unsigned32, dot11WNMEventTransitRprtSourceRCPI Unsigned32, dot11WNMEventTransitRprtSourceRSNI Unsigned32, dot11WNMEventTransitRprtTargetRCPI Unsigned32, dot11WNMEventTransitRprtTargetRSNI Unsigned32 } dot11WNMEventTransitRprtIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index for Transition Event Report elements in dot11WNMEventTransitReportTable, greater than 0." ::= { dot11WNMEventTransitReportEntry 1 } dot11WNMEventTransitRprtRqstToken OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the request token that was indicated in the WNM request that generated this measurement report. This should be an exact match to the original dot11WNMRqstToken attribute. Note that there may be 3010 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications multiple entries in the table that match this value since a single request may generate multiple WNM reports." ::= { dot11WNMEventTransitReportEntry 2 } dot11WNMEventTransitRprtIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The ifIndex for this row of WNMEventTransit report been received on." ::= { dot11WNMEventTransitReportEntry 3 } dot11WNMEventTransitRprtEventStatus OBJECT-TYPE SYNTAX INTEGER { successful(0), requestFailed(1), requestRefused(2), requestIncapable(3), detectedFrequentTransition(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute contains the status value included in the Event report." ::= { dot11WNMEventTransitReportEntry 4 } dot11WNMEventTransitRprtEventTSF OBJECT-TYPE SYNTAX TSFType MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute contains the value of the Event timestamp field." ::= { dot11WNMEventTransitReportEntry 5 } dot11WNMEventTransitRprtUTCOffset OBJECT-TYPE SYNTAX OCTET STRING (SIZE(10)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the UTC Offset Time Value optionally included in the Event report." ::= { dot11WNMEventTransitReportEntry 6 } dot11WNMEventTransitRprtTimeError OBJECT-TYPE SYNTAX OCTET STRING (SIZE(5)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute contains the value of the Event Time Error field optionally included in the Event report." ::= { dot11WNMEventTransitReportEntry 7 } 3011 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11WNMEventTransitRprtSourceBssid OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the source BSSID for the reported transition event." ::= { dot11WNMEventTransitReportEntry 8 } dot11WNMEventTransitRprtTargetBssid OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the target BSSID for the reported transition event." ::= { dot11WNMEventTransitReportEntry 9 } dot11WNMEventTransitRprtTransitTime OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "TUs" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the transition time for the reported transition event in TUs. The Transition time is defined as the time difference between the starting time and the ending time of a transition between APs, even if the transition results in remaining on the same AP. Start and end times for a transition event are defined in 11.24.2.2" ::= { dot11WNMEventTransitReportEntry 10 } dot11WNMEventTransitRprtTransitReason OBJECT-TYPE SYNTAX INTEGER { unspecified(0), excessiveFrameLossRatesPoorConditions(1), excessiveDelayForCurrentTrafficStreams(2), insufficientQosCapacityForCurrentTrafficStreams(3), firstAssociationToEss(4), loadBalancing(5), betterApFound(6), deauthenticatedDisassociatedFromPreviousAp(7), apFailedIeee8021XEapAuthentication(8), apFailed4wayHandshake(9), receivedTooManyReplayCounterFailures(10), receivedTooManyDataMICFailures(11), exceededMaxNumberOfRetransmissions(12), receivedTooManyBroadcastDisassociations(13), receivedTooManyBroadcastDeauthentications(14), previousTransitionFailed(15), lowRSSI(16) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. 3012 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications It is written by the SME when a management report is completed. This attribute indicates the reason for the reported BSS Transition event. The format for this list of reasons is further detailed in 9.4.2.68.2." ::= { dot11WNMEventTransitReportEntry 11 } dot11WNMEventTransitRprtTransitResult OBJECT-TYPE SYNTAX Unsigned32(0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the result of the attempted transition and is set to one of the status codes specified in Table 9-46 in 9.4.1.9." ::= { dot11WNMEventTransitReportEntry 12 } dot11WNMEventTransitRprtSourceRCPI OBJECT-TYPE SYNTAX Unsigned32(0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the received channel power of the most recently measured frame from the Source BSSID before the STA reassociates to the Target BSSID. The Source RCPI is a logarithmic function of the received signal power, as defined 9.4.2.38." ::= { dot11WNMEventTransitReportEntry 13 } dot11WNMEventTransitRprtSourceRSNI OBJECT-TYPE SYNTAX Unsigned32(0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the received signal-to-noise indication of the most recently measured frame from the Source BSSID before the STA reassociates to the Target BSSID. The Source RSNI is a logarithmic function of the signal-to-noise ratio, as defined in 9.4.2.41." ::= { dot11WNMEventTransitReportEntry 14 } dot11WNMEventTransitRprtTargetRCPI OBJECT-TYPE SYNTAX Unsigned32(0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the received channel power of the first measured frame just after STA reassociates to the Target BSSID. If association with target BSSID failed, the Target RCPI field indicates the received channel power of the most recently measured frame from the Target BSSID. The Target RCPI is a logarithmic function of the received signal power, as defined 9.4.2.38." ::= { dot11WNMEventTransitReportEntry 15 } dot11WNMEventTransitRprtTargetRSNI OBJECT-TYPE SYNTAX Unsigned32(0..255) 3013 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the received signal-to-noise indication of the first measured frame just after STA reassociates to the Target BSSID. If association with target BSSID failed, the Target RCPI field indicates the received signal-to-noise indication of the most recently measured frame from the Target BSSID. The Target RSNI is a logarithmic function of the signal-to-noise ratio, as defined in 9.4.2.41." ::= { dot11WNMEventTransitReportEntry 16 } -- ******************************************************************** -- * End of dot11WNMEventTransitReport TABLE -- ******************************************************************** -- ******************************************************************** -- * dot11WNMEventRsnaReport TABLE -- ******************************************************************** dot11WNMEventRsnaReportTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11WNMEventRsnaReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Group contains the current list of RSNA Event reports that have been received by the MLME. The report tables shall be maintained as FIFO to preserve freshness, thus the rows in this table can be deleted for memory constraints or other implementation constraints determined by the vendor. New rows shall have different RprtIndex values than those deleted within the range limitation of the index. One easy way is to increment RprtIndex for new reports being written in the table." ::= { dot11WNMReport 6 } dot11WNMEventRsnaReportEntry OBJECT-TYPE SYNTAX Dot11WNMEventRsnaReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11WNMEventRsnaReportTable Indexed by dot11WNMEventRsnaRprtIndex." INDEX { dot11WNMEventRsnaRprtIndex } ::= { dot11WNMEventRsnaReportTable 1 } Dot11WNMEventRsnaReportEntry ::= SEQUENCE { dot11WNMEventRsnaRprtIndex Unsigned32, dot11WNMEventRsnaRprtRqstToken OCTET STRING, dot11WNMEventRsnaRprtIfIndex InterfaceIndex, dot11WNMEventRsnaRprtEventStatus INTEGER, dot11WNMEventRsnaRprtEventTSF TSFType, dot11WNMEventRsnaRprtUTCOffset OCTET STRING, dot11WNMEventRsnaRprtTimeError OCTET STRING, dot11WNMEventRsnaRprtTargetBssid MacAddress, dot11WNMEventRsnaRprtAuthType OCTET STRING, dot11WNMEventRsnaRprtEapMethod OCTET STRING, dot11WNMEventRsnaRprtResult Unsigned32, dot11WNMEventRsnaRprtRsnElement OCTET STRING } dot11WNMEventRsnaRprtIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current 3014 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DESCRIPTION "Index for RSNA Event Report elements in dot11WNMEventRsnaReportTable, greater than 0." ::= { dot11WNMEventRsnaReportEntry 1 } dot11WNMEventRsnaRprtRqstToken OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the request token that was indicated in the WNM request that generated this measurement report. This should be an exact match to the original dot11WNMRqstToken attribute. Note that there may be multiple entries in the table that match this value since a single request may generate multiple WNM reports." ::= { dot11WNMEventRsnaReportEntry 2 } dot11WNMEventRsnaRprtIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The ifIndex for this row of WNMEventRsna report been received on." ::= { dot11WNMEventRsnaReportEntry 3 } dot11WNMEventRsnaRprtEventStatus OBJECT-TYPE SYNTAX INTEGER { successful(0), requestFailed(1), requestRefused(2), requestIncapable(3), detectedFrequentTransition(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute contains the status value included in the Event report." ::= { dot11WNMEventRsnaReportEntry 4 } dot11WNMEventRsnaRprtEventTSF OBJECT-TYPE SYNTAX TSFType MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute contains the value of the Event timestamp field." ::= { dot11WNMEventRsnaReportEntry 5 } dot11WNMEventRsnaRprtUTCOffset OBJECT-TYPE SYNTAX OCTET STRING (SIZE(10)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. 3015 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This attribute indicates the UTC Offset Time Value optionally included in the Event report." ::= { dot11WNMEventRsnaReportEntry 6 } dot11WNMEventRsnaRprtTimeError OBJECT-TYPE SYNTAX OCTET STRING (SIZE(5)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute contains the value of the Event Time Error field optionally included in the Event report." ::= { dot11WNMEventRsnaReportEntry 7 } dot11WNMEventRsnaRprtTargetBssid OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the BSSID of the AP accepting the authorization attempt." ::= { dot11WNMEventRsnaReportEntry 8 } dot11WNMEventRsnaRprtAuthType OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the AKM suite, as defined in Table 9-133 in 9.4.2.25.3. The first three octets indicate the OUI or CID. The last octet indicates the suite type." ::= { dot11WNMEventRsnaReportEntry 9 } dot11WNMEventRsnaRprtEapMethod OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1..8)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates a value that identifies the EAP Method. When the Authentication Type field is set to the value of either 00-0F-AC:1 (Authentication negotiated over IEEE Std 802.1X or using PMKSA caching as defined in 12.6.10.3) or 00-0F-AC:3 (AKM suite selector for fast BSS transition as defined in 12.7.1.7), the EAP Method field contains the IANA assigned EAP type defined at http://www.iana.org/assignments/eap-numbers. The EAP type contains either the legacy type (1 octet) or the expanded type (1 octet type = 254, 3-octet Vendor ID, 4-octet Vendor-Type). The EAP Method field is set to 0 otherwise." ::= { dot11WNMEventRsnaReportEntry 10 } dot11WNMEventRsnaRprtResult OBJECT-TYPE SYNTAX Unsigned32(0..65535) MAX-ACCESS read-only STATUS current 3016 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the result of the RSNA event and is set to one of the status codes specified in Table 9-46 in 9.4.1.9." ::= { dot11WNMEventRsnaReportEntry 11 } dot11WNMEventRsnaRprtRsnElement OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute contains the entire contents of the negotiated RSNE at the time of the authentication attempt. The maximum length of the RSNE field is less than the maximum length of an RSNE, as defined in 9.4.2.25. If the length of the RSNE included here exceeds the maximum length of the RSNE field, the RSNE shall be truncated to the maximum length allowed for the RSNE field." ::= { dot11WNMEventRsnaReportEntry 12 } -- ******************************************************************** -- * End of dot11WNMEventRsnaReport TABLE -- ******************************************************************** -- ******************************************************************** -- * dot11WNMEventPeerReport TABLE -- ******************************************************************** dot11WNMEventPeerReportTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11WNMEventPeerReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Group contains the current list of peer-to-peer event reports that have been received by the MLME. The report tables shall be maintained as FIFO to preserve freshness, thus the rows in this table can be deleted for memory constraints or other implementation constraints determined by the vendor. New rows shall have different RprtIndex values than those deleted within the range limitation of the index. One easy way is to increment RprtIndex for new reports being written in the table." ::= { dot11WNMReport 7 } dot11WNMEventPeerReportEntry OBJECT-TYPE SYNTAX Dot11WNMEventPeerReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11WNMEventPeerReportTable Indexed by dot11WNMEventPeerRprtIndex." INDEX { dot11WNMEventPeerRprtIndex } ::= { dot11WNMEventPeerReportTable 1 } Dot11WNMEventPeerReportEntry ::= SEQUENCE { dot11WNMEventPeerRprtIndex Unsigned32, dot11WNMEventPeerRprtRqstToken OCTET STRING, dot11WNMEventPeerRprtIfIndex InterfaceIndex, dot11WNMEventPeerRprtEventStatus INTEGER, dot11WNMEventPeerRprtEventTSF TSFType, dot11WNMEventPeerRprtUTCOffset OCTET STRING, dot11WNMEventPeerRprtTimeError OCTET STRING, 3017 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11WNMEventPeerRprtPeerMacAddress MacAddress, dot11WNMEventPeerRprtOperatingClass Unsigned32, dot11WNMEventPeerRprtChanNumber Unsigned32, dot11WNMEventPeerRprtStaTxPower Integer32, dot11WNMEventPeerRprtConnTime Unsigned32, dot11WNMEventPeerRprtPeerStatus INTEGER } dot11WNMEventPeerRprtIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index for Peer-to-Peer Event Report elements in dot11WNMEventPeerReportTable, greater than 0." ::= { dot11WNMEventPeerReportEntry 1 } dot11WNMEventPeerRprtRqstToken OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the request token that was indicated in the WNM request that generated this measurement report. This should be an exact match to the original dot11WNMRqstToken attribute. Note that there may be multiple entries in the table that match this value since a single request may generate multiple WNM reports." ::= { dot11WNMEventPeerReportEntry 2 } dot11WNMEventPeerRprtIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The ifIndex for this row of WNMEventPeer report been received on." ::= { dot11WNMEventPeerReportEntry 3 } dot11WNMEventPeerRprtEventStatus OBJECT-TYPE SYNTAX INTEGER { successful(0), requestFailed(1), requestRefused(2), requestIncapable(3), detectedFrequentTransition(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute contains the status value included in the Event report." ::= { dot11WNMEventPeerReportEntry 4 } dot11WNMEventPeerRprtEventTSF OBJECT-TYPE SYNTAX TSFType MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. 3018 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This attribute contains the value of the Event timestamp field." ::= { dot11WNMEventPeerReportEntry 5 } dot11WNMEventPeerRprtUTCOffset OBJECT-TYPE SYNTAX OCTET STRING (SIZE(10)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the UTC Offset Time Value optionally included in the Event report." ::= { dot11WNMEventPeerReportEntry 6 } dot11WNMEventPeerRprtTimeError OBJECT-TYPE SYNTAX OCTET STRING (SIZE(5)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute contains the value of the Event Time Error field optionally included in the Event report." ::= { dot11WNMEventPeerReportEntry 7 } dot11WNMEventPeerRprtPeerMacAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the MAC address of the peer STA or IBSS BSSID. If this event is for a peer-to-peer link in an infrastructure BSS, this field contains the MAC address of the peer STA. If this event is for a peer-to- peer link in an IBSS, this field contains the BSSID of the IBSS." ::= { dot11WNMEventPeerReportEntry 8 } dot11WNMEventPeerRprtOperatingClass OBJECT-TYPE SYNTAX Unsigned32(1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the channel set for this peer-to-peer event report. Country, Operating Class and Channel Number together specify the channel frequency and spacing for this measurement request. Valid values of Operating Class as shown in Annex E." ::= { dot11WNMEventPeerReportEntry 9 } dot11WNMEventPeerRprtChanNumber OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the current operating channel for this peer-to- 3019 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications peer event report. The Channel Number is defined only within the indicated Operating Class as shown in Annex E." ::= { dot11WNMEventPeerReportEntry 10 } dot11WNMEventPeerRprtStaTxPower OBJECT-TYPE SYNTAX Integer32 (-128..127) UNITS "dBm" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the STA transmit power used for the peer-to-peer link. The STA Tx Power field indicates the target transmit power at the antenna with a tolerance of +/-5 dB for the lowest basic rate of the reporting STA." ::= { dot11WNMEventPeerReportEntry 11 } dot11WNMEventPeerRprtConnTime OBJECT-TYPE SYNTAX Unsigned32 (0..16777215) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates a value representing the connection time for the reported peer-to-peer event. If the Peer Status is 0, this field indicates the duration of the Direct Link. If the Peer Status is 1, this field indicates the time difference from the time the Direct Link was established to the time at which the reporting STA generated the event report. If the Peer Status is 2, this field indicates the duration of the IBSS membership. If the Peer Status is 3, this field indicates the time difference from the time the STA joined the IBSS to the time at which the reporting STA generated the event report. See 11.24.2.4." ::= { dot11WNMEventPeerReportEntry 12 } dot11WNMEventPeerRprtPeerStatus OBJECT-TYPE SYNTAX INTEGER { directLinkTerminated(0), directLinkActive(1), ibssMembershipTerminated(2), ibssMembershipActive(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the peer link connection status." ::= { dot11WNMEventPeerReportEntry 13 } -- ******************************************************************** -- * End of dot11WNMEventPeerReport TABLE -- ******************************************************************** -- ******************************************************************** -- * dot11WNMEventWNMLogReport TABLE -- ******************************************************************** dot11WNMEventWNMLogReportTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11WNMEventWNMLogReportEntry 3020 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MAX-ACCESS not-accessible STATUS current DESCRIPTION "Group contains the current list of WNMLog Event reports that have been received by the MLME. The report tables shall be maintained as FIFO to preserve freshness, thus the rows in this table can be deleted for memory constraints or other implementation constraints determined by the vendor. New rows shall have different RprtIndex values than those deleted within the range limitation of the index. One easy way is to increment RprtIndex for new reports being written in the table." ::= { dot11WNMReport 8 } dot11WNMEventWNMLogReportEntry OBJECT-TYPE SYNTAX Dot11WNMEventWNMLogReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11WNMEventWNMLogReportTable Indexed by dot11WNMEventWNMLogRprtIndex." INDEX { dot11WNMEventWNMLogRprtIndex } ::= { dot11WNMEventWNMLogReportTable 1 } Dot11WNMEventWNMLogReportEntry ::= SEQUENCE { dot11WNMEventWNMLogRprtIndex Unsigned32, dot11WNMEventWNMLogRprtRqstToken OCTET STRING, dot11WNMEventWNMLogRprtIfIndex InterfaceIndex, dot11WNMEventWNMLogRprtEventStatus INTEGER, dot11WNMEventWNMLogRprtEventTSF TSFType, dot11WNMEventWNMLogRprtUTCOffset OCTET STRING, dot11WNMEventWNMLogRprtTimeError OCTET STRING, dot11WNMEventWNMLogRprtContent OCTET STRING } dot11WNMEventWNMLogRprtIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index for WNMLog Event Report elements in dot11WNMEventWNMLogReportTable, greater than 0." ::= { dot11WNMEventWNMLogReportEntry 1 } dot11WNMEventWNMLogRprtRqstToken OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the request token that was indicated in the WNM request that generated this measurement report. This should be an exact match to the original dot11WNMRqstToken attribute. Note that there may be multiple entries in the table that match this value since a single request may generate multiple WNM reports." ::= { dot11WNMEventWNMLogReportEntry 2 } dot11WNMEventWNMLogRprtIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The ifIndex for this row of WNMEventWNMLog report been received on." ::= { dot11WNMEventWNMLogReportEntry 3 } 3021 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11WNMEventWNMLogRprtEventStatus OBJECT-TYPE SYNTAX INTEGER { successful(0), requestFailed(1), requestRefused(2), requestIncapable(3), detectedFrequentTransition(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute contains the status value included in the Event report." ::= { dot11WNMEventWNMLogReportEntry 4 } dot11WNMEventWNMLogRprtEventTSF OBJECT-TYPE SYNTAX TSFType MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute contains the value of the Event timestamp field." ::= { dot11WNMEventWNMLogReportEntry 5 } dot11WNMEventWNMLogRprtUTCOffset OBJECT-TYPE SYNTAX OCTET STRING (SIZE(10)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the UTC Offset Time Value optionally included in the Event report." ::= { dot11WNMEventWNMLogReportEntry 6 } dot11WNMEventWNMLogRprtTimeError OBJECT-TYPE SYNTAX OCTET STRING (SIZE(5)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute contains the value of the Event Time Error field optionally included in the Event report." ::= { dot11WNMEventWNMLogReportEntry 7 } dot11WNMEventWNMLogRprtContent OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..2284)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute contains the entire syslog message, consisting of the PRI, HEADER, and MSG portion of a WNM log message as described in IETF RFC 5424. The TAG field of the MSG portion of the message is a 17 octet string 3022 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications containing the ASCII representation of the STA MAC address using hexadecimal notation with colons between octets. The octet containing the Individual/Group bit occurs last, and that bit is in the least significant position within that octet. See 11.24.2.5." ::= { dot11WNMEventWNMLogReportEntry 8 } -- ******************************************************************** -- * End of dot11WNMEventWNMLogReport TABLE -- ******************************************************************** -- ******************************************************************** -- * dot11WNMDiagMfrInfoReport TABLE -- ******************************************************************** dot11WNMDiagMfrInfoReportTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11WNMDiagMfrInfoReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Group contains the current list of Manufacturer Information STA reports that have been received by the MLME. The report tables shall be maintained as FIFO to preserve freshness, thus the rows in this table can be deleted for memory constraints or other implementation constraints determined by the vendor. New rows shall have different RprtIndex values than those deleted within the range limitation of the index. One easy way is to increment RprtIndex for new reports being written in the table." ::= { dot11WNMReport 9 } dot11WNMDiagMfrInfoReportEntry OBJECT-TYPE SYNTAX Dot11WNMDiagMfrInfoReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11WNMDiagMfrInfoReportTable Indexed by dot11WNMDiagMfrInfoRprtIndex." INDEX { dot11WNMDiagMfrInfoRprtIndex } ::= { dot11WNMDiagMfrInfoReportTable 1 } Dot11WNMDiagMfrInfoReportEntry ::= SEQUENCE { dot11WNMDiagMfrInfoRprtIndex Unsigned32, dot11WNMDiagMfrInfoRprtRqstToken OCTET STRING, dot11WNMDiagMfrInfoRprtIfIndex InterfaceIndex, dot11WNMDiagMfrInfoRprtEventStatus INTEGER, dot11WNMDiagMfrInfoRprtMfrOi OCTET STRING, dot11WNMDiagMfrInfoRprtMfrIdString OCTET STRING, dot11WNMDiagMfrInfoRprtMfrModelString OCTET STRING, dot11WNMDiagMfrInfoRprtMfrSerialNumberString OCTET STRING, dot11WNMDiagMfrInfoRprtMfrFirmwareVersion OCTET STRING, dot11WNMDiagMfrInfoRprtMfrAntennaType OCTET STRING, dot11WNMDiagMfrInfoRprtCollocRadioType INTEGER, dot11WNMDiagMfrInfoRprtDeviceType INTEGER, dot11WNMDiagMfrInfoRprtCertificateID OCTET STRING} dot11WNMDiagMfrInfoRprtIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index for Manufacturer Information STA Report elements in dot11WNMDiagMfrInfoReportTable, greater than 0." ::= { dot11WNMDiagMfrInfoReportEntry 1 } dot11WNMDiagMfrInfoRprtRqstToken OBJECT-TYPE SYNTAX OCTET STRING 3023 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the request token that was indicated in the WNM request that generated this measurement report. This should be an exact match to the original dot11WNMRqstToken attribute. Note that there may be multiple entries in the table that match this value since a single request may generate multiple WNM reports." ::= { dot11WNMDiagMfrInfoReportEntry 2 } dot11WNMDiagMfrInfoRprtIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The ifIndex for this row of WNMDiagMfrInfo report been received on." ::= { dot11WNMDiagMfrInfoReportEntry 3 } dot11WNMDiagMfrInfoRprtEventStatus OBJECT-TYPE SYNTAX INTEGER { successful(0), requestFailed(1), requestRefused(2), requestIncapable(3), detectedFrequentTransition(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute contains the status value included in the Event report." ::= { dot11WNMDiagMfrInfoReportEntry 4} dot11WNMDiagMfrInfoRprtMfrOi OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..5)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the Manufacturer OI for the reported Manufacturer Information STA Diagnostic." ::= { dot11WNMDiagMfrInfoReportEntry 5 } dot11WNMDiagMfrInfoRprtMfrIdString OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the Manufacturer ID string for the reported Manufacturer Information STA Diagnostic. The ID attribute contains an ASCII string indicating the manufacturer identifier of the wireless network adaptor. This string is not null terminated." ::= { dot11WNMDiagMfrInfoReportEntry 6 } 3024 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11WNMDiagMfrInfoRprtMfrModelString OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the Manufacturer model string for the reported Manufacturer Information STA Diagnostic. The model attribute contains an ASCII string indicating the model of the wireless network adaptor. This string is not null terminated." ::= { dot11WNMDiagMfrInfoReportEntry 7 } dot11WNMDiagMfrInfoRprtMfrSerialNumberString OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the Manufacturer serial number string for the reported Manufacturer Information STA Diagnostic. The serial number attribute contains an ASCII string indicating the serial number of the wireless network adaptor. This string is not null terminated." ::= { dot11WNMDiagMfrInfoReportEntry 8 } dot11WNMDiagMfrInfoRprtMfrFirmwareVersion OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the Manufacturer firmware version string for the reported Manufacturer Information STA Diagnostic. The firmware version attribute contains an ASCII string identifying the version of firmware currently installed on the wireless network adaptor. This string is not null terminated." ::= { dot11WNMDiagMfrInfoReportEntry 9 } dot11WNMDiagMfrInfoRprtMfrAntennaType OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the Manufacturer antenna type string for the reported Manufacturer Information STA Diagnostic. The first octet of this string indicates the antenna count, and the second octet indicates the antenna gain. The antenna gain indicates the peak gain in dBi of the antenna connected to the wireless network adaptor. The remaining octets contain an ASCII string indicating the type of antenna connected to the wireless network adaptor." ::= { dot11WNMDiagMfrInfoReportEntry 10 } dot11WNMDiagMfrInfoRprtCollocRadioType OBJECT-TYPE SYNTAX INTEGER { reserved(0), cellular(1), 3025 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications cordless(2), gps(3), ieee80211(4), ieee80215(5), ieee80216(6), ieee80220(7), ieee80222(8), digitalAudioBroadcasting(9), digitalVideoBroadcasting(10) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute contains the type of the collocated radio." ::= { dot11WNMDiagMfrInfoReportEntry 11 } dot11WNMDiagMfrInfoRprtDeviceType OBJECT-TYPE SYNTAX INTEGER { reserved(0), referenceDesign(1), accessPointWirelessRouterSoho(2), enterpriseAccessPoint(3), broadbandGateway(4), digitalStillCamera(5), portableVideoCamera(6), networkedWebCamera(7), digitalAudioStationary(8), digitalAudioPortable(9), setTopBoxMediaServer(10), tvMonitorDigitalPictureFrame(11), gameConsoleGameAdaptor(12), gamingDevice(13), mediaServerMediaAdaptor(14), networkStorageDevice(15), externalCard(16), internalCard(17), ultraMobilPc(18), notebookComputer(19), personalDigitalAssistant(20), printerPrintServer(21), phoneDualMode(22), phoneSingleMode(23), smartphoneDualMode(24), smartphoneSingleMode(25), otherDevices(221) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the type of device in which the IEEE 802.11 STA resides." ::= { dot11WNMDiagMfrInfoReportEntry 12 } dot11WNMDiagMfrInfoRprtCertificateID OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..251)) MAX-ACCESS read-only STATUS current DESCRIPTION 3026 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the Certificate ID for the reported Manufacturer Information STA Diagnostic." ::= { dot11WNMDiagMfrInfoReportEntry 13 } -- ******************************************************************** -- * End of dot11WNMDiagMfrInfoReport TABLE -- ******************************************************************** -- ******************************************************************** -- * dot11WNMDiagConfigProfReport TABLE -- ******************************************************************** dot11WNMDiagConfigProfReportTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11WNMDiagConfigProfReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Group contains the current list of Configuration Profile reports that have been received by the MLME. The report tables shall be maintained as FIFO to preserve freshness, thus the rows in this table can be deleted for memory constraints or other implementation constraints determined by the vendor. New rows shall have different RprtIndex values than those deleted within the range limitation of the index. One easy way is to increment RprtIndex for new reports being written in the table." ::= { dot11WNMReport 10 } dot11WNMDiagConfigProfReportEntry OBJECT-TYPE SYNTAX Dot11WNMDiagConfigProfReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11WNMDiagConfigProfReportTable Indexed by dot11WNMDiagConfigProfRprtIndex." INDEX { dot11WNMDiagConfigProfRprtIndex } ::= { dot11WNMDiagConfigProfReportTable 1 } Dot11WNMDiagConfigProfReportEntry ::= SEQUENCE { dot11WNMDiagConfigProfRprtIndex Unsigned32, dot11WNMDiagConfigProfRprtRqstToken OCTET STRING, dot11WNMDiagConfigProfRprtIfIndex InterfaceIndex, dot11WNMDiagConfigProfRprtEventStatus INTEGER, dot11WNMDiagConfigProfRprtProfileId Unsigned32, dot11WNMDiagConfigProfRprtSupportedOperatingClasses OCTET STRING, dot11WNMDiagConfigProfRprtTxPowerMode INTEGER, dot11WNMDiagConfigProfRprtTxPowerLevels OCTET STRING, dot11WNMDiagConfigProfRprtCipherSuite OCTET STRING, dot11WNMDiagConfigProfRprtAkmSuite OCTET STRING, dot11WNMDiagConfigProfRprtEapType Unsigned32, dot11WNMDiagConfigProfRprtEapVendorID OCTET STRING, dot11WNMDiagConfigProfRprtEapVendorType OCTET STRING, dot11WNMDiagConfigProfRprtCredentialType INTEGER, dot11WNMDiagConfigProfRprtSSID OCTET STRING, dot11WNMDiagConfigProfRprtPowerSaveMode INTEGER } dot11WNMDiagConfigProfRprtIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index for Configuration Profile Report elements in dot11WNMDiagConfigProfReportTable, greater than 0." 3027 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ::= { dot11WNMDiagConfigProfReportEntry 1 } dot11WNMDiagConfigProfRprtRqstToken OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the request token that was indicated in the WNM request that generated this measurement report. This should be an exact match to the original dot11WNMRqstToken attribute. Note that there may be multiple entries in the table that match this value since a single request may generate multiple WNM reports." ::= { dot11WNMDiagConfigProfReportEntry 2 } dot11WNMDiagConfigProfRprtIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The ifIndex for this row of WNMDiagConfigProf report been received on." ::= { dot11WNMDiagConfigProfReportEntry 3 } dot11WNMDiagConfigProfRprtEventStatus OBJECT-TYPE SYNTAX INTEGER { successful(0), requestFailed(1), requestRefused(2), requestIncapable(3), detectedFrequentTransition(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute contains the status value included in the Event report." ::= { dot11WNMDiagConfigProfReportEntry 4} dot11WNMDiagConfigProfRprtProfileId OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates a unique identifier for referencing a configuration profile available on a device. The value of the identifier can be any arbitrary value, as long as it is uniquely associated to a single configuration profile on the device sending the identifier." ::= { dot11WNMDiagConfigProfReportEntry 5 } dot11WNMDiagConfigProfRprtSupportedOperatingClasses OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. 3028 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This attribute indicates the current Operating Class followed by a list of each Supported Operating Class, as defined in 9.4.2.54. Each octet contains an integer representing an operating class. Operating Classes are defined in Annex E. The default value is null." DEFVAL { ''H } ::= { dot11WNMDiagConfigProfReportEntry 6 } dot11WNMDiagConfigProfRprtTxPowerMode OBJECT-TYPE SYNTAX INTEGER { fixedPowerMode(0), automaticPowerMode(1) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the power mode of the STA." ::= { dot11WNMDiagConfigProfReportEntry 7 } dot11WNMDiagConfigProfRprtTxPowerLevels OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute lists the power levels for the STA. Each octet contains an integer representing a power level encoded as a 2s complement value in dBm, rounded to the nearest integer. If the Power Mode is automatic, the list contains only the minimum and the maximum power levels for the STA. If the Power Mode is fixed, the list contains one or more fixed power level settings available at this STA, arranged in increasing numerical order." ::= { dot11WNMDiagConfigProfReportEntry 8 } dot11WNMDiagConfigProfRprtCipherSuite OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the cipher suite, as defined in Table 9-131. The first three octets indicate the OUI or CID. The last octet indicates the suite type." ::= { dot11WNMDiagConfigProfReportEntry 9 } dot11WNMDiagConfigProfRprtAkmSuite OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the AKM suite, as defined in Table 9-133 in 9.4.2.25.3. The first three octets indicate the OUI or CID. The last octet indicates the suite type." ::= { dot11WNMDiagConfigProfReportEntry 10 } 3029 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11WNMDiagConfigProfRprtEapType OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the single EAP method used by the STA. Valid EAP Type numbers are assigned by IANA and are defined at http://www.iana.org/ assignments/eap-numbers." ::= { dot11WNMDiagConfigProfReportEntry 11 } dot11WNMDiagConfigProfRprtEapVendorID OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..3)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the EAP Vendor ID number for the EAP method used by the STA. The EAP Vendor ID field is included when the EAP Type field is set to 254 and is excluded otherwise." ::= { dot11WNMDiagConfigProfReportEntry 12 } dot11WNMDiagConfigProfRprtEapVendorType OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..4)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the EAP Vendor Type number for the EAP method used by the STA. The EAP Vendor Type field is included when the EAP Type field is set to 254 and is excluded otherwise." ::= { dot11WNMDiagConfigProfReportEntry 13 } dot11WNMDiagConfigProfRprtCredentialType OBJECT-TYPE SYNTAX INTEGER { none(0), preSharedKey(1), userNamePassword(2), x509Certificate(3), otherCertificate(4), oneTimePassword(5), token(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the type of IEEE 802.1X credentials used by the STA for this authentication diagnostic." ::= { dot11WNMDiagConfigProfReportEntry 14 } dot11WNMDiagConfigProfRprtSSID OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1..32)) MAX-ACCESS read-only STATUS current DESCRIPTION 3030 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the SSID for the diagnostic report, as defined in 9.4.2.2." ::= { dot11WNMDiagConfigProfReportEntry 15 } dot11WNMDiagConfigProfRprtPowerSaveMode OBJECT-TYPE SYNTAX INTEGER { unknownMode(0), none(1), psDtims1Mode(2), psDtims0Mode(3), uapsdMode(4), sapsdMode(5), upsmpMode(6), spsmpMode(7), smpsMode(8), wnmSleepMode(9), fmsMode(10), timBroadcastMode(11), tfsMode(12), tdlsPeerUapsdMode(13), tdlsPeerPsmMode(14) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the power save mode in use by the STA, as defined in Table 9-185." ::= { dot11WNMDiagConfigProfReportEntry 16 } -- ******************************************************************** -- * End of dot11WNMDiagConfigProfReport TABLE -- ******************************************************************** -- ******************************************************************** -- * dot11WNMDiagAssocReport TABLE -- ******************************************************************** dot11WNMDiagAssocReportTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11WNMDiagAssocReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Group contains the current list of Association Diagnostic reports that have been received by the MLME. The report tables shall be maintained as FIFO to preserve freshness, thus the rows in this table can be deleted for memory constraints or other implementation constraints determined by the vendor. New rows shall have different RprtIndex values than those deleted within the range limitation of the index. One easy way is to increment RprtIndex for new reports being written in the table." ::= { dot11WNMReport 11 } dot11WNMDiagAssocReportEntry OBJECT-TYPE SYNTAX Dot11WNMDiagAssocReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11WNMDiagAssocReportTable Indexed by dot11WNMDiagAssocRprtIndex." INDEX { dot11WNMDiagAssocRprtIndex } 3031 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ::= { dot11WNMDiagAssocReportTable 1 } Dot11WNMDiagAssocReportEntry ::= SEQUENCE { dot11WNMDiagAssocRprtIndex Unsigned32, dot11WNMDiagAssocRprtRqstToken OCTET STRING, dot11WNMDiagAssocRprtIfIndex InterfaceIndex, dot11WNMDiagAssocRprtEventStatus INTEGER, dot11WNMDiagAssocRprtBssid MacAddress, dot11WNMDiagAssocRprtOperatingClass Unsigned32, dot11WNMDiagAssocRprtChannelNumber Unsigned32, dot11WNMDiagAssocRprtStatusCode Unsigned32 } dot11WNMDiagAssocRprtIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index for Association Diagnostic Report elements in dot11WNMDiagAssocReportTable, greater than 0." ::= { dot11WNMDiagAssocReportEntry 1 } dot11WNMDiagAssocRprtRqstToken OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the request token that was indicated in the WNM request that generated this measurement report. This should be an exact match to the original dot11WNMRqstToken attribute. Note that there may be multiple entries in the table that match this value since a single request may generate multiple WNM reports." ::= { dot11WNMDiagAssocReportEntry 2 } dot11WNMDiagAssocRprtIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The ifIndex for this row of WNMDiagAssoc report been received on." ::= { dot11WNMDiagAssocReportEntry 3 } dot11WNMDiagAssocRprtEventStatus OBJECT-TYPE SYNTAX INTEGER { successful(0), requestFailed(1), requestRefused(2), requestIncapable(3), detectedFrequentTransition(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute contains the status value included in the Event report." ::= { dot11WNMDiagAssocReportEntry 4 } dot11WNMDiagAssocRprtBssid OBJECT-TYPE SYNTAX MacAddress 3032 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the BSSID for the target AP for this Association Diagnostic report." ::= { dot11WNMDiagAssocReportEntry 5 } dot11WNMDiagAssocRprtOperatingClass OBJECT-TYPE SYNTAX Unsigned32(1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the channel set for the target AP for this Association Diagnostic report. Country, Operating Class and Channel Number together specify the channel frequency and spacing for this measurement request. Valid values of Operating Class as shown in Annex E." ::= { dot11WNMDiagAssocReportEntry 6 } dot11WNMDiagAssocRprtChannelNumber OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the operating channel of the target AP for this Association Diagnostic report. The Channel Number is defined only within the indicated Operating Class as sown in Annex E." ::= { dot11WNMDiagAssocReportEntry 7 } dot11WNMDiagAssocRprtStatusCode OBJECT-TYPE SYNTAX Unsigned32(0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the result of the association diagnostic and is set to one of the status codes specified in Table 9-46 in 9.4.1.9." ::= { dot11WNMDiagAssocReportEntry 8 } -- ******************************************************************** -- * End of dot11WNMDiagAssocReport TABLE -- ******************************************************************** -- ******************************************************************** -- * dot11WNMDiag8021xAuthReport TABLE -- ******************************************************************** dot11WNMDiag8021xAuthReportTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11WNMDiag8021xAuthReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Group contains the current list of IEEE 802.1X Authentication Diagnostic reports that have been received by the MLME. The report tables shall be maintained as FIFO to preserve freshness, thus the rows in this table can 3033 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications be deleted for memory constraints or other implementation constraints determined by the vendor. New rows shall have different RprtIndex values than those deleted within the range limitation of the index. One easy way is to increment RprtIndex for new reports being written in the table." ::= { dot11WNMReport 12 } dot11WNMDiag8021xAuthReportEntry OBJECT-TYPE SYNTAX Dot11WNMDiag8021xAuthReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11WNMDiag8021xAuthReportTable Indexed by dot11WNMDiag8021xAuthRprtIndex." INDEX { dot11WNMDiag8021xAuthRprtIndex } ::= { dot11WNMDiag8021xAuthReportTable 1 } Dot11WNMDiag8021xAuthReportEntry ::= SEQUENCE { dot11WNMDiag8021xAuthRprtIndex Unsigned32, dot11WNMDiag8021xAuthRprtRqstToken OCTET STRING, dot11WNMDiag8021xAuthRprtIfIndex InterfaceIndex, dot11WNMDiag8021xAuthRprtEventStatus INTEGER, dot11WNMDiag8021xAuthRprtBssid MacAddress, dot11WNMDiag8021xAuthRprtOperatingClass Unsigned32, dot11WNMDiag8021xAuthRprtChannelNumber Unsigned32, dot11WNMDiag8021xAuthRprtEapType Unsigned32, dot11WNMDiag8021xAuthRprtEapVendorID OCTET STRING, dot11WNMDiag8021xAuthRprtEapVendorType OCTET STRING, dot11WNMDiag8021xAuthRprtCredentialType INTEGER, dot11WNMDiag8021xAuthRprtStatusCode Unsigned32 } dot11WNMDiag8021xAuthRprtIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index for IEEE 802.1X Authentication Diagnostic Report elements in dot11WNMDiag8021xAuthReportTable, greater than 0." ::= { dot11WNMDiag8021xAuthReportEntry 1 } dot11WNMDiag8021xAuthRprtRqstToken OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the request token that was indicated in the WNM request that generated this measurement report. This should be an exact match to the original dot11WNMRqstToken attribute. Note that there may be multiple entries in the table that match this value since a single request may generate multiple WNM reports." ::= { dot11WNMDiag8021xAuthReportEntry 2 } dot11WNMDiag8021xAuthRprtIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The ifIndex for this row of WNMDiag8021xAuth report been received on." ::= { dot11WNMDiag8021xAuthReportEntry 3 } dot11WNMDiag8021xAuthRprtEventStatus OBJECT-TYPE 3034 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications SYNTAX INTEGER { successful(0), requestFailed(1), requestRefused(2), requestIncapable(3), detectedFrequentTransition(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute contains the status value included in the Event report." ::= { dot11WNMDiag8021xAuthReportEntry 4 } dot11WNMDiag8021xAuthRprtBssid OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the BSSID for the target AP for this Authentication Diagnostic report." ::= { dot11WNMDiag8021xAuthReportEntry 5 } dot11WNMDiag8021xAuthRprtOperatingClass OBJECT-TYPE SYNTAX Unsigned32(1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the channel set for the target AP for this Authentication Diagnostic report. Country, Operating Class and Channel Number together specify the channel frequency and spacing for this measurement request. Valid values of Operating Class as shown in Annex E." ::= { dot11WNMDiag8021xAuthReportEntry 6 } dot11WNMDiag8021xAuthRprtChannelNumber OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the operating channel of the target AP for this Authentication Diagnostic report. The Channel Number is defined only within the indicated Operating Class as shown in Annex E." ::= { dot11WNMDiag8021xAuthReportEntry 7 } dot11WNMDiag8021xAuthRprtEapType OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the single EAP method used by the STA. Valid EAP 3035 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Type numbers are assigned by IANA and are defined at http://www.iana.org/ assignments/eap-numbers." ::= { dot11WNMDiag8021xAuthReportEntry 8 } dot11WNMDiag8021xAuthRprtEapVendorID OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..3)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the EAP Vendor ID number for the EAP method used by the STA. The EAP Vendor ID field is included when the EAP Type field is set to 254 and is excluded otherwise." ::= { dot11WNMDiag8021xAuthReportEntry 9 } dot11WNMDiag8021xAuthRprtEapVendorType OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..4)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the EAP Vendor Type number for the EAP method used by the STA. The EAP Vendor Type field is included when the EAP Type field is set to 254 and is excluded otherwise." ::= { dot11WNMDiag8021xAuthReportEntry 10 } dot11WNMDiag8021xAuthRprtCredentialType OBJECT-TYPE SYNTAX INTEGER { none(0), preSharedKey(1), userNamePassword(2), x509Certificate(3), otherCertificate(4), oneTimePassword(5), token(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the type of IEEE 802.1X credentials used by the STA for this authentication diagnostic." ::= { dot11WNMDiag8021xAuthReportEntry 11 } dot11WNMDiag8021xAuthRprtStatusCode OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the result of the authentication diagnostic and is set to one of the status codes specified in Table 9-46." ::= { dot11WNMDiag8021xAuthReportEntry 12 } -- ******************************************************************** -- * End of dot11WNMDiag8021xAuthReport TABLE 3036 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications -- ******************************************************************** -- ******************************************************************** -- * dot11WNMLocConfigReport TABLE -- ******************************************************************** dot11WNMLocConfigReportTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11WNMLocConfigReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Group contains the current list of location configuration reports that have been received by the MLME. The report tables shall be maintained as FIFO to preserve freshness, thus the rows in this table can be deleted for memory constraints or other implementation constraints determined by the vendor. New rows shall have different RprtIndex values than those deleted within the range limitation of the index. One easy way is to increment RprtIndex for new reports being written in the table." ::= { dot11WNMReport 13 } dot11WNMLocConfigReportEntry OBJECT-TYPE SYNTAX Dot11WNMLocConfigReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11WNMLocConfigReportTable Indexed by dot11WNMLocConfigRprtIndex." INDEX { dot11WNMLocConfigRprtIndex } ::= { dot11WNMLocConfigReportTable 1 } Dot11WNMLocConfigReportEntry ::= SEQUENCE { dot11WNMLocConfigRprtIndex Unsigned32, dot11WNMLocConfigRprtRqstToken OCTET STRING, dot11WNMLocConfigRprtIfIndex InterfaceIndex, dot11WNMLocConfigRprtLocIndParams OCTET STRING, dot11WNMLocConfigRprtLocIndChanList OCTET STRING, dot11WNMLocConfigRprtLocIndBcastRate Unsigned32, dot11WNMLocConfigRprtLocIndOptions OCTET STRING, dot11WNMLocConfigRprtStatusConfigSubelemId INTEGER, dot11WNMLocConfigRprtStatusResult INTEGER, dot11WNMLocConfigRprtVendorSpecificRprtContent OCTET STRING } dot11WNMLocConfigRprtIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index for Location Configuration Report elements in dot11WNMLocConfigReportTable, greater than 0." ::= { dot11WNMLocConfigReportEntry 1 } dot11WNMLocConfigRprtRqstToken OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the request token that was indicated in the WNM request that generated this measurement report. This should be an exact match to the original dot11WNMRqstToken attribute. Note that there may be multiple entries in the table that match this value since a single request may generate multiple WNM reports." 3037 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ::= { dot11WNMLocConfigReportEntry 2 } dot11WNMLocConfigRprtIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The ifIndex for this row of WNMLocConfig report been received on." ::= { dot11WNMLocConfigReportEntry 3 } dot11WNMLocConfigRprtLocIndParams OBJECT-TYPE SYNTAX OCTET STRING (SIZE(16)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates STA Location reporting characteristics. The format of these Location Indication Parameters are detailed in 9.4.2.71.2." ::= { dot11WNMLocConfigReportEntry 4 } dot11WNMLocConfigRprtLocIndChanList OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..254)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute lists location indication reporting channel information for this location configuration report. The default value is null. Each pair of octets indicates a different Operating Class and channel number for this request. The detailed format for this list of channels as described in 9.4.2.71.3." DEFVAL { ''H } ::= { dot11WNMLocConfigReportEntry 5 } dot11WNMLocConfigRprtLocIndBcastRate OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "0.5 Mb/s" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the data rate at which the STA broadcasts its Location Track Notification frames." ::= { dot11WNMLocConfigReportEntry 6 } dot11WNMLocConfigRprtLocIndOptions OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the location track indication options used; see 9.4.2.71.9." ::= { dot11WNMLocConfigReportEntry 7} 3038 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11WNMLocConfigRprtStatusConfigSubelemId OBJECT-TYPE SYNTAX INTEGER { multipleSubelemIds(0), locationIndicationParams(1), locationIndicationChannels(2), locationStatus(3), radioInformation(4), motion(5), locationIndicationBcastDataRate(6), timeOfDeparture(7), vendorSpecific(8) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute is set to a specific Location Parameters subelement ID transmitted in a Location Configuration Request frame. If the following StatusResult attribute field value applies to more than one subelement then the Config subelement ID is set to 0. If the Status field value applies to one subelement, then a Location Status subelement may be included in the Location Configuration Response for each configuration subelement that has a non-Success Status value." ::= { dot11WNMLocConfigReportEntry 8 } dot11WNMLocConfigRprtStatusResult OBJECT-TYPE SYNTAX INTEGER { successful(0), requestFailed(1), requestRefused(2), requestIncapable(3), detectedFrequentTransition(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute contains the resulting status of the Location Configuration Request frame for the indicated Location Parameter subelement ID, as listed in Table 9-175, Event Report Status." ::= { dot11WNMLocConfigReportEntry 9 } dot11WNMLocConfigRprtVendorSpecificRprtContent OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute provides an envelope for all of the vendor specific subelements that may be included in Location Configuration Report element. The default value is null." DEFVAL { ''H } ::= { dot11WNMLocConfigReportEntry 10 } -- ******************************************************************** -- * End of dot11WNMLocConfigReport TABLE -- ******************************************************************** 3039 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications -- ******************************************************************** -- * dot11WNMBssTransitReport TABLE -- ******************************************************************** dot11WNMBssTransitReportTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11WNMBssTransitReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Group contains the current list of BSS Transition Management reports that have been received by the MLME. The report tables shall be maintained as FIFO to preserve freshness, thus the rows in this table can be deleted for memory constraints or other implementation constraints determined by the vendor. New rows shall have different RprtIndex values than those deleted within the range limitation of the index. One easy way is to increment RprtIndex for new reports being written in the table." ::= { dot11WNMReport 14 } dot11WNMBssTransitReportEntry OBJECT-TYPE SYNTAX Dot11WNMBssTransitReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11WNMBssTransitReportTable Indexed by dot11WNMBssTransitRprtIndex." INDEX { dot11WNMBssTransitRprtIndex } ::= { dot11WNMBssTransitReportTable 1 } Dot11WNMBssTransitReportEntry ::= SEQUENCE { dot11WNMBssTransitRprtIndex Unsigned32, dot11WNMBssTransitRprtRqstToken OCTET STRING, dot11WNMBssTransitRprtIfIndex InterfaceIndex, dot11WNMBssTransitRprtStatusCode INTEGER, dot11WNMBssTransitRprtBSSTerminationDelay Unsigned32, dot11WNMBssTransitRprtTargetBssid MacAddress, dot11WNMBssTransitRprtCandidateList OCTET STRING } dot11WNMBssTransitRprtIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index for BSS Transition Management Report elements in dot11WNMBssTransitReportTable, greater than 0." ::= { dot11WNMBssTransitReportEntry 1 } dot11WNMBssTransitRprtRqstToken OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the request token that was indicated in the WNM request that generated this measurement report. This should be an exact match to the original dot11WNMRqstToken attribute. Note that there may be multiple entries in the table that match this value since a single request may generate multiple WNM reports." ::= { dot11WNMBssTransitReportEntry 2 } dot11WNMBssTransitRprtIfIndex OBJECT-TYPE SYNTAX InterfaceIndex 3040 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MAX-ACCESS read-only STATUS current DESCRIPTION "The ifIndex for this row of WNMBssTransit report been received on." ::= { dot11WNMBssTransitReportEntry 3 } dot11WNMBssTransitRprtStatusCode OBJECT-TYPE SYNTAX INTEGER { accept(0), rejectUnspecified(1), rejectInsufficientBeacons(2), rejectInsufficientCapacity(3), rejectBssTerminationUndesired(4), rejectBssTerminationDelayRequest(5), rejectBssTransitionCandidateListprovided(6), rejectNoSuitableBssTransitionCandidates(7), rejectLeavingEss(8) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the status of this BSS Transition report." ::= { dot11WNMBssTransitReportEntry 4 } dot11WNMBssTransitRprtBSSTerminationDelay OBJECT-TYPE SYNTAX Unsigned32 (1..255) UNITS "minutes" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the time that the responding STA requests the BSS to delay termination. This attribute is included only if the Status Code field value is set to 5." ::= { dot11WNMBssTransitReportEntry 5 } dot11WNMBssTransitRprtTargetBssid OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the target BSSID for this BSS Transition report." ::= { dot11WNMBssTransitReportEntry 6 } dot11WNMBssTransitRprtCandidateList OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..11426)) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute lists one or more Neighbor Report elements which are BSS transition candidates for this request. The Neighbor Report elements are described in 9.4.2.37." ::= { dot11WNMBssTransitReportEntry 7 } 3041 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications -- ******************************************************************** -- * End of dot11WNMBssTransitReport TABLE -- ******************************************************************** -- ******************************************************************** -- * dot11WNMColocInterfReport TABLE -- ******************************************************************** dot11WNMColocInterfReportTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11WNMColocInterfReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Group contains the current list of Collocated Interference reports that have been received by the MLME. The report tables shall be maintained as FIFO to preserve freshness, thus the rows in this table can be deleted for memory constraints or other implementation constraints determined by the vendor. New rows shall have different RprtIndex values than those deleted within the range limitation of the index. One easy way is to increment RprtIndex for new reports being written in the table." ::= { dot11WNMReport 16 } dot11WNMColocInterfReportEntry OBJECT-TYPE SYNTAX Dot11WNMColocInterfReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11WNMColocInterfReportTable Indexed by dot11WNMColocInterfRprtIndex." INDEX { dot11WNMColocInterfRprtIndex } ::= { dot11WNMColocInterfReportTable 1 } Dot11WNMColocInterfReportEntry ::= SEQUENCE { dot11WNMColocInterfRprtIndex Unsigned32, dot11WNMColocInterfRprtRqstToken OCTET STRING, dot11WNMColocInterfRprtIfIndex InterfaceIndex, dot11WNMColocInterfRprtPeriod Unsigned32, dot11WNMColocInterfRprtInterfLevel Integer32, dot11WNMColocInterfRprtInterfAccuracy Unsigned32, dot11WNMColocInterfRprtInterfIndex Unsigned32, dot11WNMColocInterfRprtInterfInterval Integer32, dot11WNMColocInterfRprtInterfBurstLength Integer32, dot11WNMColocInterfRprtInterfStartTime Integer32, dot11WNMColocInterfRprtInterfCenterFreq Integer32, dot11WNMColocInterfRprtInterfBandwidth Unsigned32 } dot11WNMColocInterfRprtIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index for Collocated Interference Report elements in dot11WNMColocInterfReportTable, greater than 0." ::= { dot11WNMColocInterfReportEntry 1 } dot11WNMColocInterfRprtRqstToken OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. 3042 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This attribute indicates the request token that was indicated in the WNM request that generated this measurement report. This should be an exact match to the original dot11WNMRqstToken attribute. Note that there may be multiple entries in the table that match this value since a single request may generate multiple WNM reports." ::= { dot11WNMColocInterfReportEntry 2 } dot11WNMColocInterfRprtIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. The ifIndex for this row of WNMColocInterf report been received on." ::= { dot11WNMColocInterfReportEntry 3 } dot11WNMColocInterfRprtPeriod OBJECT-TYPE SYNTAX Unsigned32(0..255) UNITS "100 TU" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates how often the STA periodically reports the collocated interference. If the Report Period field is set to 0, then the reporting is not periodic, and a report is generated when the STA detects a change in the collocated interference. See 11.24.9 for further details." ::= { dot11WNMColocInterfReportEntry 4 } dot11WNMColocInterfRprtInterfLevel OBJECT-TYPE SYNTAX Integer32(-128..127) UNITS "dBm" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the maximum level of the collocated interference power in units of dBm over all receive chains averaged over a 4 s period during an interference period and across interference bandwidth. When the interference level is unknown, the field is set to +127 dBm. When the interference level is equal or greater than 126 dBm, the field is set to +126 dBm. If no collocated interference is present the field is set to - 128 dBm. When the interference level is equal or lower than -127 dBm, the field is set to -127 dBm. The interference level is referenced to the antenna connector (see definition in Clause 3) used for reception, like RCPI." ::= { dot11WNMColocInterfReportEntry 5 } dot11WNMColocInterfRprtInterfAccuracy OBJECT-TYPE SYNTAX Unsigned32(0..15) UNITS "dB" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. 3043 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This attribute indicates the expected accuracy of the estimate of interference in dB with 95% confidence interval. If the Interference Level field is X (dBm) and the expected accuracy field is Y (dB), the actual interference level is in the range X - Y to X +Y with the probability of 95%. If the accuracy is unknown then the Expected Accuracy field is set to 15." ::= { dot11WNMColocInterfReportEntry 6 } dot11WNMColocInterfRprtInterfIndex OBJECT-TYPE SYNTAX Unsigned32(0..15) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the interference index that is unique for each type of interference source. The field set to 0 indicates that no collocated interference is present. See 11.24.9 for further details." ::= { dot11WNMColocInterfReportEntry 7 } dot11WNMColocInterfRprtInterfInterval OBJECT-TYPE SYNTAX Integer32 UNITS "microseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the interval between two successive periods of interference. When the interval between two successive periods of interference is variable the field is set to 2**32-1. When the interval between two successive periods of interference is equal or greater than 2**32-2 the field is set to 2**32-2. If no collocated interference is present the field is set to 0." ::= { dot11WNMColocInterfReportEntry 8 } dot11WNMColocInterfRprtInterfBurstLength OBJECT-TYPE SYNTAX Integer32 UNITS "microseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the duration of each period of interference. When the duration of each period of interference is variable the field is set to 2**32-1). When the duration of each period of interference is equal or greater than 2**32-2, the field is set to 2**32-2. If no collocated interference is present the field is set to 0." ::= { dot11WNMColocInterfReportEntry 9 } dot11WNMColocInterfRprtInterfStartTime OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute contains the least significant 4 octets (i.e., B0-B31) of the TSF timer at the start of the interference burst. When either the 3044 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Interference Interval or the Interference Burst Length fields are set to 2**32-1, this field indicates the average duty cycle. The average duty cycle value is defined as Floor((2**32-2) * [average interference burst length (microsecond)]/[average interference interval (microsecond)] + 0.5). When the interference is nonperiodic the Interference Start Time field is set to 0. If no collocated interference is present the field is set to 0." ::= { dot11WNMColocInterfReportEntry 10 } dot11WNMColocInterfRprtInterfCenterFreq OBJECT-TYPE SYNTAX Integer32 UNITS "5 kHz" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates center frequency of interference. When center frequency is unknown, the center frequency of the STA's operating channel is reported. If no collocated interference is present the field is set to 0." ::= { dot11WNMColocInterfReportEntry 11 } dot11WNMColocInterfRprtInterfBandwidth OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "5 kHz" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when a management report is completed. This attribute indicates the bandwidth at the -3 dB roll-off point of the interference signal. When bandwidth of the interference signal is unknown, the field is set to 65 535. When bandwidth of the interference signal is equal or greater than 65 534 the field is set to 65 534. If no collocated interference is present the field is set to 0." ::= { dot11WNMColocInterfReportEntry 12 } -- ******************************************************************** -- * End of dot11WNMColocInterfReport TABLE -- ******************************************************************** -- ******************************************************************** -- * END of Wireless Network Management Interface MIB -- ******************************************************************** -- ********************************************************************** -- * END of IEEE 802.11 RM and WNM Interface MIB -- ********************************************************************** 3045 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications -- ********************************************************************** -- * dot11MeshSTAConfig TABLE -- ********************************************************************** dot11MeshSTAConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11MeshSTAConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Mesh Station Configuration attributes. In tabular form to allow for multiple instances on an agent." ::= { dot11smt 23 } dot11MeshSTAConfigEntry OBJECT-TYPE SYNTAX Dot11MeshSTAConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11MeshStationConfigTable. It is possible for there to be multiple IEEE 802.11 interfaces on one agent, each with its unique MAC address. The relationship between an IEEE 802.11 interface and an interface in the context of the Internet-standard MIB is one-to-one. As such, the value of an ifIndex object instance can be directly used to identify corresponding instances of the objects defined herein. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Inter- face tables in this MIB module are indexed by ifIndex." INDEX { ifIndex } ::= { dot11MeshSTAConfigTable 1 } Dot11MeshSTAConfigEntry ::= SEQUENCE { dot11MeshID OCTET STRING, dot11MeshNumberOfPeerings Unsigned32, dot11MeshAcceptingAdditionalPeerings TruthValue, dot11MeshConnectedToMeshGate TruthValue, dot11MeshSecurityActivated TruthValue, dot11MeshActiveAuthenticationProtocol INTEGER, dot11MeshMaxRetries Unsigned32, dot11MeshRetryTimeout Unsigned32, dot11MeshConfirmTimeout Unsigned32, dot11MeshHoldingTimeout Unsigned32, dot11MeshConfigGroupUpdateCount Unsigned32, dot11MeshActivePathSelectionProtocol INTEGER, dot11MeshActivePathSelectionMetric INTEGER, dot11MeshForwarding TruthValue, dot11MeshTTL Unsigned32, dot11MeshGateAnnouncements TruthValue, dot11MeshGateAnnouncementInterval Unsigned32, dot11MeshActiveCongestionControlMode INTEGER, dot11MeshActiveSynchronizationMethod INTEGER, dot11MeshNbrOffsetMaxNeighbor Unsigned32, dot11MBCAActivated TruthValue, dot11MeshBeaconTimingReportInterval Unsigned32, dot11MeshBeaconTimingReportMaxNum Unsigned32, dot11MeshDelayedBeaconTxInterval Unsigned32, dot11MeshDelayedBeaconTxMaxDelay Unsigned32, dot11MeshDelayedBeaconTxMinDelay Unsigned32, dot11MeshAverageBeaconFrameDuration Unsigned32, dot11MeshSTAMissingAckRetryLimit Unsigned32, dot11MeshAwakeWindowDuration Unsigned32, dot11MCCAImplemented TruthValue, dot11MCCAActivated TruthValue, dot11MAFlimit Unsigned32, dot11MCCAScanDuration Unsigned32, 3046 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11MCCAAdvertPeriodMax Unsigned32, dot11MCCAMinTrackStates Unsigned32, dot11MCCAMaxTrackStates Unsigned32, dot11MCCAOPtimeout Unsigned32, dot11MCCACWmin Unsigned32, dot11MCCACWmax Unsigned32, dot11MCCAAIFSN Unsigned32 } dot11MeshID OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect for the next MLME-START.request primitive. This attribute reflects the Mesh ID configured in this entity." ::= { dot11MeshSTAConfigEntry 1 } dot11MeshNumberOfPeerings OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute indicates the number of mesh peering currently maintained by the STA. This value is reflected in the Number of Peerings subfield in the Mesh Formation Info field in the Mesh Configuration element." ::= { dot11MeshSTAConfigEntry 2 } dot11MeshAcceptingAdditionalPeerings OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute indicates whether the station is willing to accept additional peerings. This value is reflected in the Accepting Additional Mesh Peerings subfield in the Mesh Capability field in the Mesh Configuration element." ::= { dot11MeshSTAConfigEntry 3 } dot11MeshConnectedToMeshGate OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute indicates whether the station has a mesh path to a mesh gate. This value is reflected in the Connected to Mesh Gate subfield in the Mesh Formation Info field in the Mesh Configuration element." ::= { dot11MeshSTAConfigEntry 4 } 3047 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11MeshSecurityActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect for the next MLME-START.request primitive. This attribute specifies whether the station is security enabled." ::= { dot11MeshSTAConfigEntry 5 } dot11MeshActiveAuthenticationProtocol OBJECT-TYPE SYNTAX INTEGER { null (0), sae (1), ieee8021x (2), vendorSpecific (255) } MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect for the next MLME-START.request primitive. This attribute specifies the active authentication protocol." DEFVAL { null } ::= { dot11MeshSTAConfigEntry 6 } dot11MeshMaxRetries OBJECT-TYPE SYNTAX Unsigned32 (0..16) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the maximum number of Mesh Peering Open retries that can be sent to establish a new mesh peering instance in a mesh BSS." DEFVAL { 2 } ::= { dot11MeshSTAConfigEntry 7 } dot11MeshRetryTimeout OBJECT-TYPE SYNTAX Unsigned32 (1..255) UNITS "milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the initial retry timeout used by the Mesh Peering Open message." DEFVAL { 40 } ::= { dot11MeshSTAConfigEntry 8 } dot11MeshConfirmTimeout OBJECT-TYPE SYNTAX Unsigned32 (1..255) UNITS "milliseconds" MAX-ACCESS read-write STATUS current 3048 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the initial retry timeout used by the Mesh Peering Open message." DEFVAL { 40 } ::= { dot11MeshSTAConfigEntry 9 } dot11MeshHoldingTimeout OBJECT-TYPE SYNTAX Unsigned32 (1..255) UNITS "milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the confirm timeout used by the mesh peering management to close a mesh peering." DEFVAL { 40 } ::= { dot11MeshSTAConfigEntry 10 } dot11MeshConfigGroupUpdateCount OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies how many times the Mesh Group Key Inform frame will be retried per mesh group key handshake attempt." DEFVAL { 3 } ::= { dot11MeshSTAConfigEntry 11 } dot11MeshActivePathSelectionProtocol OBJECT-TYPE SYNTAX INTEGER { hwmp (1), vendorSpecific (255) } MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect for the next MLME-START.request primitive. This attribute specifies the active path selection protocol." DEFVAL { hwmp } ::= { dot11MeshSTAConfigEntry 12 } dot11MeshActivePathSelectionMetric OBJECT-TYPE SYNTAX INTEGER { airtimeLinkMetric (1), vendorSpecific (255) } MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect for the next MLME-START.request primitive. This attribute specifies the active path selection metric." DEFVAL { airtimeLinkMetric } ::= { dot11MeshSTAConfigEntry 13 } 3049 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11MeshForwarding OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the ability of a mesh STA to forward MSDUs." DEFVAL { true } ::= { dot11MeshSTAConfigEntry 14 } dot11MeshTTL OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the value of Mesh TTL subfield set at a source mesh STA." DEFVAL { 31 } ::= { dot11MeshSTAConfigEntry 15 } dot11MeshGateAnnouncements OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies whether the mesh STA activates mesh gate announcements." DEFVAL { false } ::= { dot11MeshSTAConfigEntry 16 } dot11MeshGateAnnouncementInterval OBJECT-TYPE SYNTAX Unsigned32 (1..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the gate announcement interval. The gate announcement interval is the number of seconds between the transmission of two gate announcements." DEFVAL { 10 } ::= { dot11MeshSTAConfigEntry 17 } dot11MeshActiveCongestionControlMode OBJECT-TYPE SYNTAX INTEGER { null (0), congestionControlSignaling (1), vendorSpecific (255) } MAX-ACCESS read-write STATUS current 3050 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect for the next MLME-START.request primitive. This attribute specifies the active congestion control protocol." DEFVAL { null } ::= { dot11MeshSTAConfigEntry 18 } dot11MeshActiveSynchronizationMethod OBJECT-TYPE SYNTAX INTEGER { neighborOffsetSynchronization (1), vendorSpecific (255) } MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect for the next MLME-START.request primitive. This attribute specifies the MBSS's active synchronization method." DEFVAL { neighborOffsetSynchronization } ::= { dot11MeshSTAConfigEntry 19 } dot11MeshNbrOffsetMaxNeighbor OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute specifies the maximum number of neighbor STAs with which the mesh STA maintains synchronization using the neighbor offset synchronization method." DEFVAL { 50 } ::= { dot11MeshSTAConfigEntry 20 } dot11MBCAActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies whether the station activates mesh beacon collision avoidance mechanisms." DEFVAL { false } ::= { dot11MeshSTAConfigEntry 21 } dot11MeshBeaconTimingReportInterval OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. This attribute specifies when the Beacon Timing element is present in Beacon frames. The Beacon Timing element is present when the DTIM Count value in the Beacon frame is zero or equal to an integer multiple of the set value." 3051 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DEFVAL { 4 } ::= { dot11MeshSTAConfigEntry 22 } dot11MeshBeaconTimingReportMaxNum OBJECT-TYPE SYNTAX Unsigned32 (0..50) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the maximum number of the Beacon Timing Information field contained in a Beacon Timing element in the transmitting Beacon frames." DEFVAL { 16 } ::= { dot11MeshSTAConfigEntry 23 } dot11MeshDelayedBeaconTxInterval OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the interval of the delayed beacon transmission for the purpose of MBCA. The value is expressed in units of Beacon Interval. The value 0 indicates that the delayed beacon transmission is disabled." DEFVAL { 0 } ::= { dot11MeshSTAConfigEntry 24 } dot11MeshDelayedBeaconTxMaxDelay OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "microseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the maximum delay time from a TBTT of delayed beacon transmissions for the purpose of MBCA." DEFVAL { 2048 } ::= { dot11MeshSTAConfigEntry 25 } dot11MeshDelayedBeaconTxMinDelay OBJECT-TYPE SYNTAX Unsigned32 (0..4023) UNITS "microseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the minimum delay time from a TBTT of delayed beacon transmissions for the purpose of MBCA." DEFVAL { 0 } ::= { dot11MeshSTAConfigEntry 26 } 3052 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11MeshAverageBeaconFrameDuration OBJECT-TYPE SYNTAX Unsigned32 (0..16383) UNITS "microseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the average duration of the last 16 Beacon frames of other mesh STAs received by this mesh STA." ::= { dot11MeshSTAConfigEntry 27 } dot11MeshSTAMissingAckRetryLimit OBJECT-TYPE SYNTAX Unsigned32 (0..100) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the number of times the mesh STA may retry a frame for which it does not receive an Ack frame for a STA in power save mode after the mesh STA does not receive an Ack frame to an individually addressed MPDU sent with the EOSP subfield set to 1." ::= { dot11MeshSTAConfigEntry 28 } dot11MeshAwakeWindowDuration OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the duration of the mesh Awake Window in TUs. This value is reflected in the value of the Mesh Awake Window element." ::= { dot11MeshSTAConfigEntry 29 } dot11MCCAImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute specifies whether the MCCA is implemented in this station." ::= { dot11MeshSTAConfigEntry 30 } dot11MCCAActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies whether the station is MCCA enabled." DEFVAL { false } 3053 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ::= { dot11MeshSTAConfigEntry 31 } dot11MAFlimit OBJECT-TYPE SYNTAX Unsigned32 (0..255) UNITS "1/255" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the maximum MCCA access fraction allowed at the mesh STA." DEFVAL { 128 } ::= { dot11MeshSTAConfigEntry 32 } dot11MCCAScanDuration OBJECT-TYPE SYNTAX Unsigned32 (1..65535) UNITS "TUs" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the duration after the activation of MCCA that the mesh STA shall not initiate or accept MCCAOP Setup Requests." DEFVAL { 3200 } -- (2 ** 5) * 100 ::= { dot11MeshSTAConfigEntry 33 } dot11MCCAAdvertPeriodMax OBJECT-TYPE SYNTAX Unsigned32 (0..255) UNITS "DTIM intervals" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the maximum interval that a mesh STA with dot11MCCAActivated equal to true waits for an MCCAOP advertisement." DEFVAL { 1 } ::= { dot11MeshSTAConfigEntry 34 } dot11MCCAMinTrackStates OBJECT-TYPE SYNTAX Unsigned32 (83..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a capability variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the smallest number of MCCAOP reservations that the MAC entity is able to track." DEFVAL { 83 } ::= { dot11MeshSTAConfigEntry 35 } dot11MCCAMaxTrackStates OBJECT-TYPE 3054 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications SYNTAX Unsigned32 (83..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. The lower bound is given by the current value of dot11MCCAMinTrackStates. This attribute specifies the maximum number of MCCAOP reservations that the MAC entity is able to track." DEFVAL { 83 } ::= { dot11MeshSTAConfigEntry 36 } dot11MCCAOPtimeout OBJECT-TYPE SYNTAX Unsigned32 UNITS "TUs" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the timeout value for an MCCAOP teardown." DEFVAL { 10000 } ::= { dot11MeshSTAConfigEntry 37 } dot11MCCACWmin OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the value of the minimum size of the window that shall be used by the mesh STA during the MCCAOP for which it is the MCCAOP owner for generating a random number for the backoff." DEFVAL { 0 } ::= { dot11MeshSTAConfigEntry 38 } dot11MCCACWmax OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the value of the maximum size of the window that shall be used by the mesh STA during the MCCAOP for which it is the MCCAOP owner for generating a random number for the backoff. The value of this attribute shall be such that it could always be expressed in the form of 2**X - 1, where X is an integer." DEFVAL { 31 } ::= { dot11MeshSTAConfigEntry 39 } dot11MCCAAIFSN OBJECT-TYPE SYNTAX Unsigned32 (0..15) MAX-ACCESS read-write STATUS current 3055 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the number of slots, after a SIFS, that the mesh STA shall sense the medium idle either before transmitting or executing a backoff during an MCCAOP for which it is the MCCAOP owner." DEFVAL { 1 } ::= { dot11MeshSTAConfigEntry 40 } -- ********************************************************************** -- * End of dot11MeshSTAConfig TABLE -- ********************************************************************** -- ********************************************************************** -- * dot11MeshHWMPConfig TABLE -- ********************************************************************** dot11MeshHWMPConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11MeshHWMPConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Mesh Station HWMP Configuration attributes. In tabular form to allow for multiple instances on an agent." ::= { dot11smt 24 } dot11MeshHWMPConfigEntry OBJECT-TYPE SYNTAX Dot11MeshHWMPConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11MeshHWMPConfigTable. It is possible for there to be multiple IEEE 802.11 interfaces on one agent, each with its unique MAC address. The relationship between an IEEE 802.11 interface and an interface in the context of the Internet-standard MIB is one-to-one. As such, the value of an ifIndex object instance can be directly used to identify corresponding instances of the objects defined herein. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX { ifIndex } ::= { dot11MeshHWMPConfigTable 1 } Dot11MeshHWMPConfigEntry ::= SEQUENCE { dot11MeshHWMPmaxPREQretries Unsigned32, dot11MeshHWMPnetDiameter Unsigned32, dot11MeshHWMPnetDiameterTraversalTime Unsigned32, dot11MeshHWMPpreqMinInterval Unsigned32, dot11MeshHWMPperrMinInterval Unsigned32, dot11MeshHWMPactivePathToRootTimeout Unsigned32, dot11MeshHWMPactivePathTimeout Unsigned32, dot11MeshHWMProotMode INTEGER, dot11MeshHWMProotInterval Unsigned32, dot11MeshHWMPrannInterval Unsigned32, dot11MeshHWMPtargetOnly INTEGER, dot11MeshHWMPmaintenanceInterval Unsigned32, dot11MeshHWMPconfirmationInterval Unsigned32 } dot11MeshHWMPmaxPREQretries OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-write 3056 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the number of Action frames containing a PREQ element that an originator mesh STA can send to a particular path target for a specific path discovery." DEFVAL { 3 } ::= { dot11MeshHWMPConfigEntry 1} dot11MeshHWMPnetDiameter OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the estimate of the maximum number of hops that it takes for an HWMP element to propagate across the mesh BSS." DEFVAL { 31 } ::= { dot11MeshHWMPConfigEntry 2} dot11MeshHWMPnetDiameterTraversalTime OBJECT-TYPE SYNTAX Unsigned32 (1..65535) UNITS "TUs" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the estimate of the interval of time that it takes for an HWMP element to propagate across the mesh BSS." DEFVAL { 500 } ::= { dot11MeshHWMPConfigEntry 3} dot11MeshHWMPpreqMinInterval OBJECT-TYPE SYNTAX Unsigned32 (1..65535) UNITS "TUs" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the minimum interval of time during which a mesh STA can send only one Action frame containing a PREQ element." DEFVAL { 100 } ::= { dot11MeshHWMPConfigEntry 4} dot11MeshHWMPperrMinInterval OBJECT-TYPE SYNTAX Unsigned32 (1..65535) UNITS "TUs" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. 3057 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Changes take effect as soon as practical in the implementation. This attribute specifies the minimum interval of time during which a mesh STA can send only one Action frame containing a PERR element." DEFVAL { 100 } ::= { dot11MeshHWMPConfigEntry 5} dot11MeshHWMPactivePathToRootTimeout OBJECT-TYPE SYNTAX Unsigned32 (1..65535) UNITS "TUs" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This object shall specify the time for which mesh STAs receiving a proactive PREQ element shall consider the forwarding information to the root mesh STA to be valid; it needs to be greater than dot11MeshHWMProotInterval." DEFVAL { 5000 } ::= { dot11MeshHWMPConfigEntry 6} dot11MeshHWMPactivePathTimeout OBJECT-TYPE SYNTAX Unsigned32 (1..65535) UNITS "TUs" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the time for which mesh STAs receiving a PREQ element to individual target(s) shall consider the forwarding information to be valid." DEFVAL { 5000 } ::= { dot11MeshHWMPConfigEntry 7} dot11MeshHWMProotMode OBJECT-TYPE SYNTAX INTEGER { noRoot(0), proactivePREQnoPREP(2), proactivePREQwithPREP(3), rann(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute controls the configuration of a mesh STA as root mesh STA. A mesh STA is configured as a root mesh STA if dot11MeshHWMProotMode is set to 2, 3 or 4. Different values correspond to different modes of the root mesh STA. The mesh STA is not a root mesh STA when the attribute is set to 0." DEFVAL { noRoot } ::= { dot11MeshHWMPConfigEntry 8} dot11MeshHWMProotInterval OBJECT-TYPE SYNTAX Unsigned32 (1..65535) UNITS "TUs" 3058 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the minimum interval of time during which a root mesh STA can send only one Action frame containing a proactive PREQ element." DEFVAL { 2000 } ::= { dot11MeshHWMPConfigEntry 9} dot11MeshHWMPrannInterval OBJECT-TYPE SYNTAX Unsigned32 (1..65535) UNITS "TUs" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the minimum interval of time during which a mesh STA can send only one Action frame containing a RANN element." DEFVAL { 2000 } ::= { dot11MeshHWMPConfigEntry 10} dot11MeshHWMPtargetOnly OBJECT-TYPE SYNTAX INTEGER { intermediateMSTA(0), targetOnly(1) } MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute, when set to intermediateMSTA (0), allows intermediate mesh STAs to respond with a PREP element to a PREQ element if they have valid forwarding information to the requested target. When set to targetOnly (1), only the target mesh STA is allowed to respond with a PREP element to a PREQ element." DEFVAL { targetOnly } ::= { dot11MeshHWMPConfigEntry 11} dot11MeshHWMPmaintenanceInterval OBJECT-TYPE SYNTAX Unsigned32 (1..65535) UNITS "TUs" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the minimum interval of time during which a mesh STA can send only one Action frame containing a PREQ element for path maintenance." DEFVAL { 2000 } ::= { dot11MeshHWMPConfigEntry 12} dot11MeshHWMPconfirmationInterval OBJECT-TYPE SYNTAX Unsigned32 (1..65535) UNITS "TUs" 3059 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the minimum interval of time during which a mesh STA can send only one Action frame containing a PREQ element for root path confirmation." DEFVAL { 2000 } ::= { dot11MeshHWMPConfigEntry 13} -- ******************************************************************** -- * End of dot11MeshHWMPConfig TABLE -- ******************************************************************** -- ******************************************************************* -- * dot11RSNAConfigPasswordValue TABLE -- ******************************************************************* dot11RSNAConfigPasswordValueTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11RSNAConfigPasswordValueEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "When SAE authentication is the selected AKM suite, this table is used to locate the binary representation of a shared, secret, and potentially low-entropy word, phrase, code, or key that will be used as the authentication credential between a TA/RA pair. This table is logically write-only. Reading this table returns unsuccessful status or null or zero." ::= { dot11smt 25 } dot11RSNAConfigPasswordValueEntry OBJECT-TYPE SYNTAX Dot11RSNAConfigPasswordValueEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the Password Value Table" INDEX { dot11RSNAConfigPasswordValueIndex } ::= { dot11RSNAConfigPasswordValueTable 1 } Dot11RSNAConfigPasswordValueEntry ::= SEQUENCE { dot11RSNAConfigPasswordValueIndex Unsigned32, dot11RSNAConfigPasswordCredential OCTET STRING, dot11RSNAConfigPasswordPeerMac MacAddress } dot11RSNAConfigPasswordValueIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The auxiliary variable used to identify instances of the columnar objects in the Password Value table." ::= { dot11RSNAConfigPasswordValueEntry 1 } dot11RSNAConfigPasswordCredential OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-write STATUS current 3060 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This variable is a binary representation of a shared, secret, and potentially low-entropy word, phrase, code or key used as an authentication credential. Any character-based word or phrase shall be converted into a canonical binary representation according to 12.4.3 before populating the Password Credential." ::= { dot11RSNAConfigPasswordValueEntry 2 } dot11RSNAConfigPasswordPeerMac OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This variable represents the MAC address of the peer that is to be authenticated. A wildcard BSSID is permitted when passwords are shared among peers." ::= { dot11RSNAConfigPasswordValueEntry 3 } -- ******************************************************************* -- * End of dot11RSNAConfigPasswordValue TABLE -- ******************************************************************* -- ******************************************************************* -- * dot11RSNAConfigDLCGroup TABLE -- ******************************************************************* dot11RSNAConfigDLCGroupTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11RSNAConfigDLCGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table gives a prioritized list of domain parameter set Identifiers for discrete logarithm cryptography (DLC) groups." ::= { dot11smt 26 } dot11RSNAConfigDLCGroupEntry OBJECT-TYPE SYNTAX Dot11RSNAConfigDLCGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the DLC Group Table." INDEX { dot11RSNAConfigDLCGroupIndex } ::= { dot11RSNAConfigDLCGroupTable 1 } Dot11RSNAConfigDLCGroupEntry ::= SEQUENCE { dot11RSNAConfigDLCGroupIndex Unsigned32, dot11RSNAConfigDLCGroupIdentifier Unsigned32 } dot11RSNAConfigDLCGroupIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION 3061 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications "The variable used to identify instances of the columnar objects in the DLC Group Table. Entries are sorted based on the Group Index according to the priority of the Group Identifier relative to other objects. More preferred Group Identifiers will have a lower index in the Group Entry." ::= { dot11RSNAConfigDLCGroupEntry 1 } dot11RSNAConfigDLCGroupIdentifier OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This variable uniquely identifies a domain parameter set for a group in the IANA registry `Group Description' attributes for IETF RFC 2409 (IKE)." ::= { dot11RSNAConfigDLCGroupEntry 2 } -- ********************************************************************* -- * End of dot11RSNAConfigDLCGroup TABLE -- ********************************************************************* -- ******************************************************************* -- * dot11DMGSTAConfigTable TABLE -- ******************************************************************* dot11DMGSTAConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11DMGSTAConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is a table management object. The dot11DMGSTAConfig Table" ::= { dot11smt 27 } dot11DMGSTAConfigEntry OBJECT-TYPE SYNTAX Dot11DMGSTAConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is an entry in the dot11DMGSTAConfig Table. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX { ifIndex } ::= { dot11DMGSTAConfigTable 1 } Dot11DMGSTAConfigEntry ::= SEQUENCE { dot11DMGOptionImplemented TruthValue, dot11RelayActivated TruthValue, dot11REDSActivated TruthValue, dot11RDSActivated TruthValue, dot11MultipleMACActivated TruthValue, dot11ClusteringActivated TruthValue } dot11DMGOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only 3062 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. DMG Capable Object This attribute, when true, indicates the STA is DMG capable. This attribute, when false, indicates the STA is not DMG capable. The default value of this attribute is false." DEFVAL { false } ::= { dot11DMGSTAConfigEntry 1 } dot11RelayActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates the DMG STA is Relay capable. This attribute, when false, indicates the STA is not Relay capa- ble. The default value of this attribute is false." DEFVAL { false } ::= { dot11DMGSTAConfigEntry 2 } dot11REDSActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates the DMG STA is capable of operating as a REDS. This attribute, when false, indicates the STA is not capable of operating as a REDS." DEFVAL { false } ::= { dot11DMGSTAConfigEntry 3 } dot11RDSActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates the DMG STA is capable of operating as a RDS. This attribute, when false, indicates the STA is not capable of operating as a RDS." DEFVAL { false } ::= { dot11DMGSTAConfigEntry 4 } dot11MultipleMACActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. If dot11MultipleMACActivated is true, the STA is capable of managing more than one MAC address." 3063 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DEFVAL { false } ::= { dot11DMGSTAConfigEntry 5 } dot11ClusteringActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. If dot11ClusteringActivated is true, the STA is capable of supporting AP or PCP Clustering." DEFVAL { false } ::= { dot11DMGSTAConfigEntry 6 } -- ******************************************************************* -- * End of dot11DMGSTAConfigTable TABLE -- ******************************************************************* -- ********************************************************************** -- * dot11AVOptions TABLE -- ********************************************************************** dot11AVOptionsTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11AVOptionsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "AV streaming attributes. In tabular form to allow for multiple instances on an agent. This table applies to the interface only if dot11RobustAVStreamingImplemented is true in the dot11StationConfigTable. Otherwise this table should be ignored." ::= { dot11smt 28 } dot11AVOptionsEntry OBJECT-TYPE SYNTAX Dot11AVOptionsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11AVOptionsTable. For all AV Streaming features, an Activated MIB variable is used to activate/enable or deactivate/disable the corresponding feature. An Implemented MIB variable is used for an optional feature to indicate whether the feature is implemented. A mandatory feature does not have a corresponding Implemented MIB variable. It is possible for there to be multiple IEEE 802.11 interfaces on one agent, each with its unique MAC address. The relationship between an IEEE 802.11 interface and an interface in the context of the Internet-standard MIB is one-to-one. As such, the value of an ifIndex object instance can be directly used to identify corresponding instances of the objects defined herein. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX { ifIndex } ::= { dot11AVOptionsTable 1 } Dot11AVOptionsEntry ::= SEQUENCE { dot11GCRActivated TruthValue, dot11AdvancedGCRImplemented TruthValue, dot11AdvancedGCRActivated TruthValue, dot11SCSImplemented TruthValue, 3064 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11SCSActivated TruthValue, dot11QLoadReportActivated TruthValue, dot11AlternateEDCAActivated TruthValue, dot11GCRGroupMembershipAnnouncementActivated TruthValue, dot11PublicHCCATXOPNegotiationImplemented TruthValue, dot11PublicHCCATXOPNegotiationActivated TruthValue, dot11ProtectedHCCATXOPNegotiationImplemented TruthValue, dot11ProtectedHCCATXOPNegotiationActivated TruthValue, dot11ProtectedQLoadReportImplemented TruthValue, dot11ProtectedQLoadReportActivated TruthValue, dot11MeshGCRImplemented TruthValue, dot11MeshGCRActivated TruthValue } dot11GCRActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME or external management entity. Changes take effect for the next MLME-START.request primitive or MLME-JOIN.request primitive. This attribute, when true, indicates that the station implementation supports the GCR procedures as defined in 11.24.16.3 and that this has been activated." DEFVAL { false } ::= { dot11AVOptionsEntry 1 } dot11AdvancedGCRImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation supports the Advanced GCR features." DEFVAL { false } ::= { dot11AVOptionsEntry 2 } dot11AdvancedGCRActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME or external management entity. Changes take effect for the next MLME-START.request primitive or MLME-JOIN.request primitive. This attribute, when true, indicates that the station implementation supports the GCR procedures as defined in 11.24.16.3 and that this has been activated." DEFVAL { false } ::= { dot11AVOptionsEntry 3 } dot11SCSImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. 3065 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation supports the stream classification service." DEFVAL { false } ::= { dot11AVOptionsEntry 4 } dot11SCSActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME or external management entity. Changes take effect for the next MLME-START.request primitive or MLME-JOIN.request primitive. This attribute, when true, indicates that the station implementation supports the stream classification service and that this has been activated." DEFVAL { false } ::= { dot11AVOptionsEntry 5 } dot11QLoadReportActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME or external management entity. Changes take effect for the next MLME-START.request primitive. This attribute, when true, indicates that the AP performs the QLoad report procedures described in 11.28.2." DEFVAL { false } ::= { dot11AVOptionsEntry 6 } dot11AlternateEDCAActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME or external management entity. Changes take effect for the next MLME-START.request primitive. This attribute, when true, indicates that the station can additionally use the Alternate EDCA transmit queues." DEFVAL { false } ::= { dot11AVOptionsEntry 7 } dot11GCRGroupMembershipAnnouncementActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME or external management entity. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that the STA sends unsolicited Group Membership Response frames when its dot11GroupAddressesTable changes." DEFVAL { false } 3066 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ::= { dot11AVOptionsEntry 8 } dot11PublicHCCATXOPNegotiationImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation supports the negotiation of HCCA TXOPs using Public Action frames." DEFVAL { true } ::= { dot11AVOptionsEntry 9 } dot11PublicHCCATXOPNegotiationActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or external management entity. Changes take effect for the next MLME-START.request primitive. This attribute, when true, indicates that the AP can negotiate HCCA TXOPs using Public Action frames." DEFVAL { true } ::= { dot11AVOptionsEntry 10 } dot11ProtectedHCCATXOPNegotiationImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation supports the negotiation of HCCA TXOPs using protected dual of Public Action frames." DEFVAL { true } ::= { dot11AVOptionsEntry 11 } dot11ProtectedHCCATXOPNegotiationActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or external management entity. Changes take effect for the next MLME-START.request primitive. This attribute, when true, indicates that the AP can negotiate HCCA TXOPs using protected dual of Public Action frames." DEFVAL { true } ::= { dot11AVOptionsEntry 12 } dot11ProtectedQLoadReportImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. 3067 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This attribute, when true, indicates that the station implementation supports the reporting of QLoad using protected dual of Public Action frames." DEFVAL { true } ::= { dot11AVOptionsEntry 13 } dot11ProtectedQLoadReportActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or external management entity. Changes take effect for the next MLME-START.request primitive. This attribute, when true, indicates that the AP can report QLoad using protected dual of Public Action frames." DEFVAL { true } ::= { dot11AVOptionsEntry 14 } dot11MeshGCRImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the mesh station implementation supports the Advanced GCR features." DEFVAL { false } ::= { dot11AVOptionsEntry 15 } dot11MeshGCRActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME or external management entity. Changes take effect for the next MLME-START.request primitive or MLME- JOIN.request primitive. This attribute, when true, indicates that the mesh station implementation supports the GCR procedures as defined in 11.24.16.3 and that this has been activated." DEFVAL { false } ::= { dot11AVOptionsEntry 16 } -- ********************************************************************** -- * End of dot11AVOptions TABLE -- ********************************************************************** -- ********************************************************************** -- * dot11AVConfig TABLE -- ********************************************************************** dot11AVConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11AVConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "AV streaming attributes. In tabular form to allow for multiple instances 3068 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications on an agent. This table only applies to the interface if dot11RobustAVStreamingImplemented is true in the dot11StationConfigTable. Otherwise this table should be ignored." ::= { dot11smt 29 } dot11AVConfigEntry OBJECT-TYPE SYNTAX Dot11AVConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11AVConfigTable. It is possible for there to be multiple IEEE 802.11 interfaces on one agent, each with its unique MAC address. The relationship between an IEEE 802.11 interface and an interface in the context of the Internet-standard MIB is one-to-one. As such, the value of an ifIndex object instance can be directly used to identify corresponding instances of the objects defined herein. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX { ifIndex } ::= { dot11AVConfigTable 1 } Dot11AVConfigEntry ::= SEQUENCE { dot11GCRPolicyChangeTimeout Unsigned32, dot11QLoadReportIntervalDTIM Unsigned32, dot11HCCATXOPBeaconTimeout Unsigned32, dot11GCRConcealmentAddress MacAddress, dot11QLoadReportDelay Unsigned32, dot11ShortDEIRetryLimit Unsigned32, dot11LongDEIRetryLimit Unsigned32, dot11UnsolicitedRetryLimit Unsigned32, dot11DefaultSurplusBandwidthAllowance Unsigned32 } dot11GCRPolicyChangeTimeout OBJECT-TYPE SYNTAX Unsigned32(5..18000) UNITS "100 TUs" MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by the SME or external management entity. Changes take effect for the next MLME-START.request primitive or MLME-JOIN.request primitive. This attribute indicates the interval after which a STA updates its GCR delivery mode or retransmission policy state using the procedures defined in 11.24.16.3.4." DEFVAL { 100 } ::= { dot11AVConfigEntry 1 } dot11QLoadReportIntervalDTIM OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect at the next MLMESTART.request primitive. This attribute describes the number of DTIM intervals between transmissions of Beacon frames containing a Qload Report element." ::= { dot11AVConfigEntry 2 } 3069 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11HCCATXOPBeaconTimeout OBJECT-TYPE SYNTAX Unsigned32 (1..100) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the MAC or external management entity. Changes take effect for the next MLME-START.request primitive. This attribute specifies the number of beacon periods an AP defers scheduling new potentially conflicting HCCA TXOPs while performing the HCCA TXOP procedures defined in 11.28.3." DEFVAL { 3 } ::= { dot11AVConfigEntry 3 } dot11GCRConcealmentAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or external management entity. In a non-AP STA or mesh STA receiving GCR service, it is written by the MAC when it receives a DMS Response frame that contains a DMS Status field with a GCR Response subelement and a Response Type subfield set to Accept. In an AP or mesh STA providing GCR service, changes take effect for the next MLME-START.request primitive. In a non-AP STA or mesh STA receiving GCR service, changes take effect as soon as practical in the implementation. The purpose of dot11GCRConcealmentAddress is to define the group address that is used by the GCR procedures (as defined in 11.24.16.3.5) to conceal group addressed frames from STAs that do not support GCR." DEFVAL {'010FAC474352'H} ::= { dot11AVConfigEntry 4 } dot11QLoadReportDelay OBJECT-TYPE SYNTAX Unsigned32 (1..60) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect at the next MLMESTART.request primitive. This attribute describes the maximum number of seconds an AP delays sending an unsolicited QLoad Report action frame." DEFVAL { 10 } ::= { dot11AVConfigEntry 5 } dot11ShortDEIRetryLimit OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. For frames where the DEI subfield has the value of one and length less than or equal to dot11RTSThreshold, this attribute indicates the maximum number of transmission attempts that are made before a failure condition is indicated. The default value of this attribute is 5." DEFVAL { 5 } 3070 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ::= { dot11AVConfigEntry 6 } dot11LongDEIRetryLimit OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-write STATUS current DESCRIPTION " This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. For frames where the DEI subfield has the value of one and length greater than dot11RTSThreshold, this attribute indicates the maximum number of transmission attempts that are made before a failure condition is indicated. The default value of this attribute is 3." DEFVAL { 3 } ::= { dot11AVConfigEntry 7 } dot11UnsolicitedRetryLimit OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute indicates the maximum number of transmission attempts of a frame delivered using the GCR unsolicited retry retransmission policy." DEFVAL { 7 } ::= { dot11AVConfigEntry 8 } dot11DefaultSurplusBandwidthAllowance OBJECT-TYPE SYNTAX Unsigned32 (100..255) MAX-ACCESS read-write STATUS current DESCRIPTION " This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This object specifies the default percentage surplus bandwidth allowance when calculating medium time. " DEFVAL { 110 } ::= { dot11AVConfigEntry 9 } -- ******************************************************************** -- * End of dot11AVConfig TABLE -- ******************************************************************** -- ******************************************************************** -- * dot11APC TABLE -- ******************************************************************** dot11APCTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11APCEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Group contains conceptual table of attributes for MIB-based HCCA TXOP negotiation." ::= { dot11smt 30 } 3071 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11APCTableEntry OBJECT-TYPE SYNTAX Dot11APCEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11APCTable, Indexed by dot11APCIndex." INDEX { dot11APCIndex } ::= { dot11APCTable 1 } Dot11APCEntry ::= SEQUENCE { dot11APCIndex Unsigned32, dot11APCEntryAvoidanceDuration Unsigned32, dot11APCEntryAvoidanceServiceInterval Unsigned32, dot11APCEntryAvoidanceOffset Unsigned32, dot11APCEntryMACAddress MacAddress } dot11APCIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The auxiliary variable used to identify instances of the columnar objects in the HCCA TXOP Table." ::= { dot11APCTableEntry 1 } dot11APCEntryAvoidanceDuration OBJECT-TYPE SYNTAX Unsigned32 (0..131071) UNITS "32 microseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute contains the duration of a TXOP reservation that the AP attempts to avoid when scheduling new HCCA TXOPs." ::= { dot11APCTableEntry 2 } dot11APCEntryAvoidanceServiceInterval OBJECT-TYPE SYNTAX Unsigned32 (0..255) UNITS "ms" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute contains the duration of the period between successive HCCA TXOPs. When zero, no period has been reserved." ::= { dot11APCTableEntry 3 } dot11APCEntryAvoidanceOffset OBJECT-TYPE SYNTAX Unsigned32 (0..131071) UNITS "TUs" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. 3072 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This attribute contains the offset from the scheduled start of the Beacon transmission until the start of the time period for a TXOP reservation that the AP attempts to avoid when scheduling new HCCA TXOPs." ::= { dot11APCTableEntry 4 } dot11APCEntryMACAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute contains the MAC address of the peer AP that has scheduled an HCCA TXOP in the time period defined by dot11APCEntryAvoidanceDuration, dot11APCEntryAvoidanceServiceInterval, and dot11APCEntryAvoidanceOffset." ::= { dot11APCTableEntry 5 } -- ******************************************************************** -- * End of dot11APC TABLE -- ******************************************************************** -- ********************************************************************* -- * dot11VHTStationConfig TABLE -- ********************************************************************** dot11VHTStationConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11VHTStationConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Station Configuration attributes. In tabular form to allow for multiple instances on an agent." ::= { dot11smt 31 } dot11VHTStationConfigEntry OBJECT-TYPE SYNTAX Dot11VHTStationConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the dot11VHTStationConfig Table. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX { ifIndex } ::= { dot11VHTStationConfigTable 1 } Dot11VHTStationConfigEntry ::= SEQUENCE { dot11MaxMPDULength INTEGER, dot11VHTMaxRxAMPDUFactor Unsigned32, dot11VHTControlFieldOptionImplemented TruthValue, dot11VHTTXOPPowerSaveOptionImplemented TruthValue, dot11VHTRxVHTMCSMap OCTET STRING, dot11VHTRxHighestDataRateSupported Unsigned32, dot11VHTTxVHTMCSMap OCTET STRING, dot11VHTTxHighestDataRateSupported Unsigned32, dot11VHTOBSSScanCount Unsigned32 } dot11MaxMPDULength OBJECT-TYPE SYNTAX INTEGER { short(3895), medium(7991), long(11454) } UNITS "octets" MAX-ACCESS read-only 3073 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates the maximum supported size of an MPDU received in a VHT PPDU." ::= { dot11VHTStationConfigEntry 1 } dot11VHTMaxRxAMPDUFactor OBJECT-TYPE SYNTAX Unsigned32 (0..7) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates the maximum length of A-MPDU that the STA can receive. The Maximum Rx A-MPDU defined by this field is equal to 2^(13+dot11VHTMaxRxAMPDUFactor) -1 octets." DEFVAL { 0 } ::= { dot11VHTStationConfigEntry 2 } dot11VHTControlFieldOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of receiving the VHT variant HT Control field." DEFVAL { false } ::= { dot11VHTStationConfigEntry 3 } dot11VHTTXOPPowerSaveOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the station implementation is capable of VHT TXOP power save operation." DEFVAL { false } ::= { dot11VHTStationConfigEntry 4 } dot11VHTRxVHTMCSMap OBJECT-TYPE SYNTAX OCTET STRING (SIZE(8)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. Each octet represents the highest VHT-MCS supported (for Rx) on the number of streams represented by the octet position (first octet represents 1 stream, second octet represents 2 streams, etc.) A value 0 indicates that VHT-MCSs 0-7 are supported. A value 1 indicates that VHT-MCSs 0-8 are supported. A value 2 indicates that VHT-MCSs 0-9 are supported. A value 3 indicates no support for that number of spatial streams." ::= { dot11VHTStationConfigEntry 5 } 3074 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11VHTRxHighestDataRateSupported OBJECT-TYPE SYNTAX Unsigned32 UNITS "Mb/s" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. Represents the highest data rate that the STA is capable of receiving." ::= { dot11VHTStationConfigEntry 6 } dot11VHTTxVHTMCSMap OBJECT-TYPE SYNTAX OCTET STRING (SIZE(8)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. Each octet represents the highest VHT-MCS supported (for Tx) on the number of streams represented by the octet position (first octet represents 1 stream, second octet represents 2 streams, etc.). A value 0 indicates that VHT-MCSs 0-7 are supported. A value 1 indicates that VHT-MCSs 0-8 are supported. A value 2 indicates that VHT-MCSs 0-9 are supported. A value 3 indicates no support for that number of spatial streams." ::= { dot11VHTStationConfigEntry 7 } dot11VHTTxHighestDataRateSupported OBJECT-TYPE SYNTAX Unsigned32 UNITS "Mb/s" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. Represents the highest data rate that the STA is capable of transmitting." DEFVAL { 0 } ::= { dot11VHTStationConfigEntry 8 } dot11VHTOBSSScanCount OBJECT-TYPE SYNTAX Unsigned32 (3..100) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute indicates the minimum number of scan operations performed on a channel to detect another OBSS." DEFVAL { 3 } ::= { dot11VHTStationConfigEntry 9 } -- ******************************************************************** -- * End of dot11VHTStationConfigTable TABLE -- ******************************************************************** -- ********************************************************************* -- * dot11TVHTStationConfig TABLE -- ********************************************************************** dot11TVHTStationConfigTable OBJECT-TYPE 3075 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications SYNTAX SEQUENCE OF Dot11TVHTStationConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Station Configuration attributes. In tabular form to allow for multiple instances on an agent." ::= { dot11smt 32 } dot11TVHTStationConfigEntry OBJECT-TYPE SYNTAX Dot11TVHTStationConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the dot11HTStationConfig Table. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX { ifIndex } ::= { dot11TVHTStationConfigTable 1 } Dot11TVHTStationConfigEntry ::= SEQUENCE { dot11TVHTMaxMPDULength INTEGER, dot11TVHTMaxRxAMPDUFactor Unsigned32, dot11TVHTControlFieldOptionImplemented TruthValue, dot11TVHTTXOPPowerSaveOptionImplemented TruthValue, dot11TVHTRxVHTMCSMap OCTET STRING, dot11TVHTRxHighestDataRateSupported Unsigned32, dot11TVHTTxVHTMCSMap OCTET STRING, dot11TVHTTxHighestDataRateSupported Unsigned32, dot11TVHTOBSSScanCount Unsigned32 } dot11TVHTMaxMPDULength OBJECT-TYPE SYNTAX INTEGER { short(3895), medium(7991), long(11454) } UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates the maximum supported size of an MPDU received in a TVHT PPDU." ::= { dot11TVHTStationConfigEntry 1 } dot11TVHTMaxRxAMPDUFactor OBJECT-TYPE SYNTAX Unsigned32 (0..7) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates the maximum length of A-MPDU that the STA can receive. The Maximum Rx A-MPDU defined by this field is equal to 2^(13+dot11TVHTMaxRxAMPDUFactor)-1 octets." DEFVAL { 0 } ::= { dot11TVHTStationConfigEntry 2 } dot11TVHTControlFieldOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. 3076 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This attribute, when true, indicates that the STA implementation is capable of receiving the VHT variant HT Control field." DEFVAL { false } ::= { dot11TVHTStationConfigEntry 3 } dot11TVHTTXOPPowerSaveOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the STA implementation is capable of VHT TXOP power save operation." DEFVAL { false } ::= { dot11TVHTStationConfigEntry 4 } dot11TVHTRxVHTMCSMap OBJECT-TYPE SYNTAX OCTET STRING (SIZE(8)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. Each octet represents the highest VHT-MCS supported (for Rx) on the number of streams represented by the octet position (first octet represents 1stream, second octet represents 2 streams, etc.). A value 0 indicates that VHT-MCSs 0-7 are supported. A value 1 indicates that VHT-MCSs 0-8 are supported. A value 2 indicates that VHT-MCSs 0-9 are supported. A value 3 indicates no support for that number of spatial streams." ::= { dot11TVHTStationConfigEntry 5 } dot11TVHTRxHighestDataRateSupported OBJECT-TYPE SYNTAX Unsigned32 UNITS "Mb/s" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. Represents the highest data rate that the STA is capable of receiving." ::= { dot11TVHTStationConfigEntry 6 } dot11TVHTTxVHTMCSMap OBJECT-TYPE SYNTAX OCTET STRING (SIZE(8)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. Each octet represents the highest VHT-MCS supported (for Tx) on the number of streams represented by the octet position (first octet represents 1 stream, second octet represents 2 streams, etc.). A value 0 indicates that VHT-MCSs 0-7 are supported. A value 1 indicates that VHT-MCSs 0-8 are supported. A value 2 indicates that VHT-MCSs 0-9 are supported. A value 3 indicates no support for that number of spatial streams." ::= { dot11TVHTStationConfigEntry 7 } dot11TVHTTxHighestDataRateSupported OBJECT-TYPE SYNTAX Unsigned32 UNITS "Mb/s" MAX-ACCESS read-only STATUS current 3077 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. Represents the highest data rate that the STA is capable of transmitting." DEFVAL { 0 } ::= { dot11TVHTStationConfigEntry 8 } dot11TVHTOBSSScanCount OBJECT-TYPE SYNTAX Unsigned32 (3..100) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute indicates the minimum number of scan operations performed on a channel to detect another OBSS." DEFVAL { 3 } ::= { dot11TVHTStationConfigEntry 9 } -- ******************************************************************** -- * End of dot11TVHTStationConfigTable TABLE -- ******************************************************************** -- ******************************************************************** -- * dot11STALCI TABLE -- ******************************************************************** dot11STALCITable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11STALCIEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table represents the geolocation of the STA as specified in 11.44.1." ::= { dot11smt 33 } dot11STALCIEntry OBJECT-TYPE SYNTAX Dot11STALCIEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "STA's location information in geospatial coordinates" INDEX {dot11STALCIIndex } ::= { dot11STALCITable 1 } Dot11STALCIEntry ::= SEQUENCE { dot11STALCIIndex Unsigned32, dot11STALCILatitudeUncertainty Unsigned32, dot11STALCILatitudeInteger Integer32, dot11STALCILatitudeFraction Integer32, dot11STALCILongitudeUncertainty Unsigned32, dot11STALCILongitudeInteger Integer32, dot11STALCILongitudeFraction Integer32, dot11STALCIAltitudeType INTEGER, dot11STALCIAltitudeUncertainty Unsigned32, dot11STALCIAltitude Integer32, dot11STALCIDatum INTEGER } dot11STALCIIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current 3078 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DESCRIPTION "Index for STA LCI elements in dot11STALCITable, greater than 0." ::= { dot11STALCIEntry 1 } dot11STALCILatitudeUncertainty OBJECT-TYPE SYNTAX Unsigned32 (0..63) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Latitude uncertainty is 6 bits indicating the amount of uncertainty in latitude value. A value of 0 is reserved to indicate that the uncertainty is unknown; values greater than 34 are reserved. This field is derived from IETF RFC 6225." ::= { dot11STALCIEntry 2 } dot11STALCILatitudeInteger OBJECT-TYPE SYNTAX Integer32 (-359..359) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Latitude is a 2s complement 34 bit fixed point value consisting of 9 bits of integer and 25 bits of fraction. This field contains the 9 bits of integer portion of Latitude. This field is derived from IETF RFC 6225." ::= { dot11STALCIEntry 3 } dot11STALCILatitudeFraction OBJECT-TYPE SYNTAX Integer32 (-16777215..16777215) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Latitude is a 2s complement 34 bit fixed point value consisting of 9 bits of integer and 25 bits of fraction. This field contains the 25 bits of fraction portion of Latitude. This field is derived from IETF RFC 6225." ::= { dot11STALCIEntry 4 } dot11STALCILongitudeUncertainty OBJECT-TYPE SYNTAX Unsigned32 (0..63) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Longitude uncertainty is 6 bits indicating the amount of uncertainty in longitude value. A value of 0 is reserved to indicate that the uncertainty is unknown; values greater than 34 are reserved. This field is derived from IETF RFC 6225." ::= { dot11STALCIEntry 5 } dot11STALCILongitudeInteger OBJECT-TYPE 3079 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications SYNTAX Integer32 (-359..359) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Longitude is a 2s complement 34 bit fixed point value consisting of 9 bits of integer and 25 bits of fraction. This field contains the 9 bits of integer portion of Longitude. This field is derived from IETF RFC 6225." ::= { dot11STALCIEntry 6 } dot11STALCILongitudeFraction OBJECT-TYPE SYNTAX Integer32 (-16777215..16777215) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Longitude is a 2s complement 34 bit fixed point value consisting of 9 bits of integer and 25 bits of fraction. This field contains the 25 bits of fraction portion of Longitude. This field is derived from IETF RFC 6225." ::= { dot11STALCIEntry 7 } dot11STALCIAltitudeType OBJECT-TYPE SYNTAX INTEGER { meters(1), floors(2), hagm (3) } MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Altitude Type is four bits encoding the type of altitude. Codes defined are: meters in 2s complement fixed-point 22-bit integer part with 8-bit fraction floors: in 2s complement fixed-point 22-bit integer part with 8-bit fraction hagm: Height Above Ground in meters, in 2s complement fixed-point 22-bit integer part with 8-bit fraction This field is derived from IETF RFC 6225." ::= { dot11STALCIEntry 8 } dot11STALCIAltitudeUncertainty OBJECT-TYPE SYNTAX Unsigned32 (0..63) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Altitude uncertainty is 6 bits indicating the amount of uncertainty in the altitude value. A value of 0 is reserved to indicate that altitude uncertainty is not known; values above 30 are also reserved. Altitude uncertainty applies only to Altitude Type 1. This field is derived from 3080 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications IETF RFC 6225." ::= { dot11STALCIEntry 9 } dot11STALCIAltitude OBJECT-TYPE SYNTAX Integer32 (-536870912..536870911) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Altitude is a 30 bit value defined by the Altitude type field. The field is encoded as a 2s complement fixed-point 22-bit integer part with 8-bit fraction. This field is derived from IETF RFC 6225." ::= { dot11STALCIEntry 10 } -- Reserved: 11. Was dot11STALCIAltitudeFraction. dot11STALCIDatum OBJECT-TYPE SYNTAX INTEGER { wgs84 (1), nad83navd88 (2), nad93mllwvd (3) } MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Datum is an 8-bit value encoding the horizontal and vertical references used for the coordinates given in this LCI. IETF RFC 6225 defines the values of Datum. Type 1 is WGS-84, the coordinate system used by GPS. Type 2 is NAD83 with NAVD88 vertical reference. Type 3 is NAD83 with Mean Lower Low Water vertical datum. All other types are reserved. This field is derived from IETF RFC 6225." ::= { dot11STALCIEntry 12 } -- ********************************************************************** -- * End of dot11STALCI TABLE -- ********************************************************************** -- ******************************************************************** -- * dot11STALCIConfig Table -- ******************************************************************** dot11STALCIConfig OBJECT-TYPE SYNTAX SEQUENCE OF Dot11STALCIConfiguration MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object represents the sequence of STAâ€™s geospatial coordinates." ::= { dot11smt 36 } dot11STALCIConfiguration OBJECT-TYPE SYNTAX Dot11STALCIConfiguration MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object represents the geospatial coordinates of the STA." INDEX { ifIndex } ::= { dot11STALCIConfigTable 1 } Dot11STALCIConfiguration ::= 3081 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications SEQUENCE { dot11STALCIConfigLatitudeUncertainty Unsigned32, dot11STALCIConfigLatitudeInteger Integer32, dot11STALCIConfigLatitudeFraction Integer32, dot11STALCIConfigLongitudeUncertainty Unsigned32, dot11STALCIConfigLongitudeInteger Integer32, dot11STALCIConfigLongitudeFraction Integer32, dot11STALCIConfigAltitudeType INTEGER, dot11STALCIConfigAltitudeUncertainty Unsigned32, dot11STALCIConfigAltitude Integer32, dot11STALCIConfigDatum INTEGER } dot11STALCIConfigLatitudeUncertainty OBJECT-TYPE SYNTAX Unsigned32 (0..63) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Latitude uncertainty is 6 bits indicating the amount of uncertainty in latitude value. A value of 0 is reserved to indicate that the uncertainty is unknown; values greater than 34 are reserved. This field is derived from IETF RFC 6225." ::= { dot11STALCIConfiguration 1 } dot11STALCIConfigLatitudeInteger OBJECT-TYPE SYNTAX Integer32 (-359..359) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Latitude is a 2s complement 34 bit fixed point value consisting of 9 bits of integer and 25 bits of fraction. This field contains the 9 bits of integer portion of Latitude. This field is derived from IETFRFC 6225." ::= { dot11STALCIConfiguration 2 } dot11STALCIConfigLatitudeFraction OBJECT-TYPE SYNTAX Integer32 (-16777215..16777215) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Latitude is a 2s complement 34 bit fixed point value consisting of 9 bits of integer and 25 bits of fraction. This field contains the 25 bits of fraction portion of Latitude. This field is derived from IETFRFC 6225." ::= { dot11STALCIConfiguration 3 } dot11STALCIConfigLongitudeUncertainty OBJECT-TYPE SYNTAX Unsigned32 (0..63) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Longitude uncertainty is 6 bits indicating the amount of uncertainty in longitude value. A value of 0 is reserved to 3082 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications indicate that the uncertainty is unknown; values greater than 34 are reserved. This field is derived from IETFRFC 6225." ::= { dot11STALCIConfiguration 4 } dot11STALCIConfigLongitudeInteger OBJECT-TYPE SYNTAX Integer32 (-359..359) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Longitude is a 2s complement 34 bit fixed point value consisting of 9 bits of integer and 25 bits of fraction. This field contains the 9 bits of integer portion of Longitude. This field is derived from IETFRFC 6225." ::= { dot11STALCIConfiguration 5 } dot11STALCIConfigLongitudeFraction OBJECT-TYPE SYNTAX Integer32 (-16777215..16777215) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Longitude is a 2s complement 34 bit fixed point value consisting of 9 bits of integer and 25 bits of fraction. This field contains the 25 bits of fraction portion of Longitude. This field is derived from IETF RFC 6225." ::= { dot11STALCIConfiguration 6 } dot11STALCIConfigAltitudeType OBJECT-TYPE SYNTAX INTEGER { meters(1), floors(2), hagm (3) } MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Altitude Type is four bits encoding the type of altitude. Codes defined are: meters in 2s complement fixed-point 22-bit integer part with 8-bit fraction floors: in 2s complement fixed-point 22-bit integer part with 8-bit fraction hagm: Height Above Ground in meters, in 2s complement fixed-point 22-bit integer part with 8-bit fraction This field is derived from IETF RFC 6225." ::= { dot11STALCIConfiguration 7 } dot11STALCIConfigAltitudeUncertainty OBJECT-TYPE SYNTAX Unsigned32 (0..63) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Altitude uncertainty is 6 bits indicating the amount of uncertainty in the altitude value. A value of 0 is reserved to 3083 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications indicate that altitude uncertainty is not known; values above 30 are also reserved. Altitude uncertainty applies only to Altitude Type 1. This field is derived from IETF RFC 6225." ::= { dot11STALCIConfiguration 8 } dot11STALCIConfigAltitude OBJECT-TYPE SYNTAX Integer32 (-536870912..536870911) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Altitude is a 30 bit value defined by the Altitude type field. The field is encoded as a 2s complement fixed-point 22-bit integer part with 8-bit fraction. This field is derived from IETF RFC 6225." ::= { dot11STALCIConfiguration 9 } dot11STALCIConfigDatum OBJECT-TYPE SYNTAX INTEGER { wgs84 (1), nad83navd88 (2), nad93mllwvd (3) } MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Datum is an 8-bit value encoding the horizontal and vertical References used for the coordinates given in this LCI. IETF RFC 6225 defines the values of Datum. Type 1 is WGS-84, the coordinate system used by GPS. Type 2 is NAD83 with NAVD88 vertical reference. Type 3 is NAD83 with Mean Lower Low Water vertical datum. All other types are reserved. This field is derived from IETF RFC 6225." ::= { dot11STALCIConfiguration 10 } -- ******************************************************************** -- * End of dot11STALCIConfig -- ******************************************************************** -- ******************************************************************** -- * dot11STACivicLocationConfig Table -- ******************************************************************** dot11STACivicLocationConfig OBJECT-TYPE SYNTAX SEQUENCE OF Dot11STACivicLocationConfiguration MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object represents the sequence of STAâ€™s civic location." ::= { dot11smt 37 } dot11STACivicLocationConfiguration OBJECT-TYPE SYNTAX Dot11STACivicLocationConfiguration MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object represents the civic location of the STA." INDEX { ifIndex } ::= { dot11STACivicLocationConfigTable 1 } Dot11STACivicLocationConfiguration ::= SEQUENCE { dot11STACivicLocationType INTEGER, 3084 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11STACivicLocation OCTET STRING } dot11STACivicLocationType OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Civic Location type is defined in 9.4.2.21.14." ::= { dot11STACivicLocationConfiguration 1 } dot11STACivicLocation OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Civic Location is defined in 9.4.2.22.13." ::= { dot11STACivicLocationConfiguration 2 } -- ******************************************************************** -- * End of dot11STACivicLocationConfig -- ******************************************************************** -- ********************************************************************** -- * MAC Attribute Templates -- ********************************************************************** -- ********************************************************************** -- * dot11Operation TABLE -- ********************************************************************** dot11OperationTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11OperationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Group contains MAC attributes pertaining to the operation of the MAC. This has been implemented as a table in order to allow for multiple instantiations on an agent." ::= { dot11mac 1 } dot11OperationEntry OBJECT-TYPE SYNTAX Dot11OperationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11OperationEntry Table. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX { ifIndex } ::= { dot11OperationTable 1 } Dot11OperationEntry ::= SEQUENCE { dot11MACAddress MacAddress, dot11RTSThreshold Unsigned32, dot11ShortRetryLimit Unsigned32, 3085 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11LongRetryLimit Unsigned32, dot11FragmentationThreshold Unsigned32, dot11MaxTransmitMSDULifetime Unsigned32, dot11MaxReceiveLifetime Unsigned32, dot11ManufacturerID DisplayString, dot11ProductID DisplayString, dot11CAPLimit Unsigned32, dot11HCCWmin Unsigned32, dot11HCCWmax Unsigned32, dot11HCCAIFSN Unsigned32, dot11ADDBAResponseTimeout Unsigned32, dot11ADDTSResponseTimeout Unsigned32, dot11ChannelUtilizationBeaconIntervals Unsigned32, dot11ScheduleTimeout Unsigned32, dot11DLSResponseTimeout Unsigned32, dot11QAPMissingAckRetryLimit Unsigned32, dot11EDCAAveragingPeriod Unsigned32, dot11HTProtection INTEGER, dot11RIFSMode TruthValue, dot11PSMPControlledAccess TruthValue, dot11ServiceIntervalGranularity Unsigned32, dot11DualCTSProtection TruthValue, dot11LSIGTXOPFullProtectionActivated TruthValue, dot11NonGFEntitiesPresent TruthValue, dot11PCOActivated TruthValue, dot11PCOFortyMaxDuration Unsigned32, dot11PCOTwentyMaxDuration Unsigned32, dot11PCOFortyMinDuration Unsigned32, dot11PCOTwentyMinDuration Unsigned32, dot11FortyMHzIntolerant TruthValue, dot11BSSWidthTriggerScanInterval Unsigned32, dot11BSSWidthChannelTransitionDelayFactor Unsigned32, dot11OBSSScanPassiveDwell Unsigned32, dot11OBSSScanActiveDwell Unsigned32, dot11OBSSScanPassiveTotalPerChannel Unsigned32, dot11OBSSScanActiveTotalPerChannel Unsigned32, dot112040BSSCoexistenceManagementSupport TruthValue, dot11OBSSScanActivityThreshold Unsigned32 } dot11MACAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. Unique MAC Address assigned to the STA." ::= { dot11OperationEntry 1 } dot11RTSThreshold OBJECT-TYPE SYNTAX Unsigned32 (0..65536) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute indicates the number of octets in a PSDU, below which an RTS/CTS handshake is not performed, except as RTS/CTS is used as a cross modulation protection mechanism as defined in 10.26. An RTS/CTS handshake is performed at the beginning of any frame exchange sequence where the PSDU is with the Type subfield equal to Data or Management, the PSDU has 3086 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications an individual address in the Address 1 field, and the length of the PSDU is greater than this threshold. Setting this attribute to be larger than the maximum PSDU size has the effect of turning off the RTS/CTS handshake for frames of Data or Management type transmitted by this STA. Setting this attribute to 0 has the effect of turning on the RTS/CTS handshake for all frames of Data or Management type transmitted by this STA." DEFVAL { 65536 } ::= { dot11OperationEntry 2 } dot11ShortRetryLimit OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute indicates the maximum number of transmission attempts of a frame, in a PSDU of length that is less than or equal to dot11RTSThreshold, that are made before a failure condition is indicated." DEFVAL { 7 } ::= { dot11OperationEntry 3 } dot11LongRetryLimit OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute indicates the maximum number of transmission attempts of a frame, in a PSDU of length that is greater than dot11RTSThreshold, that is made before a failure condition is indicated." DEFVAL { 4 } ::= { dot11OperationEntry 4 } dot11FragmentationThreshold OBJECT-TYPE SYNTAX Unsigned32 (256..65535) UNITS "octets" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the maximum size of an individually addressed MPDU beyond which the corresponding MSDU or MMPDU is fragmented, except when an MSDU is transmitted under an HT-immediate or HT-delayed block ack agreement, or when an MSDU is carried in an A-MSDU, or when an MSDU or MMPDU is carried in an A-MPDU that does not contain a VHT single MPDU. Fields added to the MPDU by security encapsulation are not counted against the limit specified by this attribute. An MSDU or MMPDU might be fragmented even if it is smaller." DEFVAL { 65535 } ::= { dot11OperationEntry 5 } dot11MaxTransmitMSDULifetime OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) UNITS "TUs" MAX-ACCESS read-write 3087 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. The MaxTransmitMSDULifetime is the elapsed time, after the initial transmission of an MSDU, after which further attempts to transmit the MSDU are terminated." DEFVAL { 512 } ::= { dot11OperationEntry 6 } dot11MaxReceiveLifetime OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) UNITS "TUs" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. The MaxReceiveLifetime is the elapsed time, after the initial reception of a fragmented MMPDU or MSDU, after which further attempts to reassemble the MMPDU or MSDU are terminated." DEFVAL { 512 } ::= { dot11OperationEntry 7 } dot11ManufacturerID OBJECT-TYPE SYNTAX DisplayString (SIZE(0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. The ManufacturerID includes, at a minimum, the name of the manufacturer. It may include additional information at the manufacturer's discretion. The default value of this attribute is null." ::= { dot11OperationEntry 8 } dot11ProductID OBJECT-TYPE SYNTAX DisplayString (SIZE(0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. The ProductID includes, at a minimum, an identifier that is unique to the manufacturer. It may include additional information at the manufacturer's discretion. The default value of this attribute is null." ::= { dot11OperationEntry 9 } dot11CAPLimit OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the maximum number of TUs a Controlled access 3088 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications phase(CAP) can last." ::= { dot11OperationEntry 10 } dot11HCCWmin OBJECT-TYPE SYNTAX Unsigned32 -- (0..aCWmin) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the value of the minimum size of the window that is used by the HC for generating a random number for the backoff. The value of this attribute is such that it could always be expressed in the form of 2**X - 1, where X is an integer." DEFVAL { 0 } ::= { dot11OperationEntry 11 } dot11HCCWmax OBJECT-TYPE SYNTAX Unsigned32 -- (0..aCWmax) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the value of the maximum size of the window that is used by the HC for generating a random number for the backoff. The value of this attribute is such that it could always be expressed in the form of 2**X - 1, where X is an integer." DEFVAL { 0 } ::= { dot11OperationEntry 12 } dot11HCCAIFSN OBJECT-TYPE SYNTAX Unsigned32 (1..15) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the number of slots, after a SIFS, that the HC senses the medium idle either before transmitting or executing a backoff." DEFVAL { 1 } ::= { dot11OperationEntry 13 } dot11ADDBAResponseTimeout OBJECT-TYPE SYNTAX Unsigned32 (1..65535) UNITS "seconds" MAX-ACCESS read-write STATUS deprecated DESCRIPTION "Deprecated as no longer used by IEEE Std 802.11-2016 This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the timeout for an ADDBA Response frame that is a response to an ADDBA Request frame." DEFVAL { 1 } ::= { dot11OperationEntry 14 } 3089 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11ADDTSResponseTimeout OBJECT-TYPE SYNTAX Unsigned32 (1..65535) MAX-ACCESS read-write STATUS deprecated DESCRIPTION "Deprecated as no longer used by IEEE Std 802.11-2016 This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the maximum number of seconds an ADDTS request is to be responded." DEFVAL { 1 } ::= { dot11OperationEntry 15 } dot11ChannelUtilizationBeaconIntervals OBJECT-TYPE SYNTAX Unsigned32 (1..100) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute indicates the number of beacon intervals over which the channel busy time should be averaged." DEFVAL { 50 } ::= { dot11OperationEntry 16 } dot11ScheduleTimeout OBJECT-TYPE SYNTAX Unsigned32 (1..100) UNITS "TUs" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute indicates the duration after which a STA could go into power save mode." DEFVAL { 10 } ::= { dot11OperationEntry 17 } dot11DLSResponseTimeout OBJECT-TYPE SYNTAX Unsigned32 (1..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the maximum number of seconds a direct link request is to be responded." DEFVAL { 10 } ::= { dot11OperationEntry 18 } dot11QAPMissingAckRetryLimit OBJECT-TYPE SYNTAX Unsigned32 (1..100) MAX-ACCESS read-write STATUS current DESCRIPTION 3090 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute indicates the number of times the AP may retry a frame for which it does not receive an Ack frame for a STA in power save mode after receiving a PS-Poll frame and sending an individually addressed response or after the AP does not receive an Ack frame to an individually addressed MPDU sent with the EOSP subfield equal to 1." ::= { dot11OperationEntry 19 } dot11EDCAAveragingPeriod OBJECT-TYPE SYNTAX Unsigned32 (1..100) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute indicates the number of seconds over which the admitted_- time and used_time are computed." DEFVAL { 5 } ::= { dot11OperationEntry 20 } dot11HTProtection OBJECT-TYPE SYNTAX INTEGER { htNoProtection (0), htNonmemberProtection(1), ht20MHzProtection(2), htNonHTmixed(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute indicates the level of protection that needs to be provided to the transmissions in an IEEE 802.11 network with HT STAs." DEFVAL { htNoProtection } ::= { dot11OperationEntry 21 } dot11RIFSMode OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that use of RIFS is allowed in the BSS." DEFVAL { false } ::= { dot11OperationEntry 22 } dot11PSMPControlledAccess OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. 3091 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Changes take effect as soon as practical in the implementation. This attribute, when true indicates that the AP accepts associations only from STAs for which dot11PSMPOptionImplemented is true." DEFVAL { false } ::= { dot11OperationEntry 23 } dot11ServiceIntervalGranularity OBJECT-TYPE SYNTAX Unsigned32 (0..7) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute indicates the SI granularity to be used for scheduled PSMP. The value of the granularity is given by (dot11ServiceIntervalGranularity+1)*5 ms." DEFVAL { 0 } ::= { dot11OperationEntry 24 } dot11DualCTSProtection OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute, when true indicates that the AP uses dual CTS protection to protect the non-STBC frame and STBC frame transmissions." DEFVAL { false } ::= { dot11OperationEntry 25 } dot11LSIGTXOPFullProtectionActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that the LSIG TXOP protection may be used by STAs that have the attribute dot11LsigTxopProtectionOptionImplemented equal to true." DEFVAL { false } ::= { dot11OperationEntry 26 } dot11NonGFEntitiesPresent OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME when it determines that the presence of greenfield stations in the BSS has changed. This attribute, when true, indicates that STA that are not HT-greenfield Capable are present in the BSS." DEFVAL { false } ::= { dot11OperationEntry 27 } 3092 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11PCOActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that the PCO is activated." DEFVAL { false } ::= { dot11OperationEntry 28 } dot11PCOFortyMaxDuration OBJECT-TYPE SYNTAX Unsigned32 (1..200) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. The attribute indicates the maximum duration of 40 MHz phase in TU under PCO operation. The value of this attribute shall be equal to or larger than dot11PCOFortyMinDuration." DEFVAL { 30 } ::= { dot11OperationEntry 29 } dot11PCOTwentyMaxDuration OBJECT-TYPE SYNTAX Unsigned32 (1..200) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. The attribute indicates the maximum duration of 20 MHz phase in TU under PCO operation. The value of this attribute shall be equal to or larger than dot11PCOTwentyMinDuration." DEFVAL { 30 } ::= { dot11OperationEntry 30 } dot11PCOFortyMinDuration OBJECT-TYPE SYNTAX Unsigned32 (1..200) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. The attribute indicates the minimum duration of 40 MHz phase in TU under PCO operation." DEFVAL { 20 } ::= { dot11OperationEntry 31 } dot11PCOTwentyMinDuration OBJECT-TYPE SYNTAX Unsigned32 (1..200) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. 3093 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications It is written by an external management entity. Changes take effect as soon as practical in the implementation. The attribute indicates the minimum duration of 20 MHz phase in TU under PCO operation." DEFVAL { 20 } ::= { dot11OperationEntry 32 } dot11FortyMHzIntolerant OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that the STA requests that 40 MHz mask PPDUs are not transmitted within range of the STA." DEFVAL { false } ::= { dot11OperationEntry 33 } dot11BSSWidthTriggerScanInterval OBJECT-TYPE SYNTAX Unsigned32 (10..900) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute indicates the maximum interval between scan operations to be performed to detect BSS channel width trigger events." DEFVAL { 300 } ::= { dot11OperationEntry 34 } dot11BSSWidthChannelTransitionDelayFactor OBJECT-TYPE SYNTAX Unsigned32 (5..100) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute indicates the minimum ratio between the delay time in performing a switch from 20 MHz BSS operation to 20/40 MHz BSS operation and the maximum interval between OBSS scan operations." DEFVAL { 5 } ::= { dot11OperationEntry 35 } dot11OBSSScanPassiveDwell OBJECT-TYPE SYNTAX Unsigned32 (5..1000) UNITS "TUs" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute indicates the minimum amount of time that the STA continuously scans each channel when performing a passive OBSS scan 3094 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications operation." DEFVAL { 20 } ::= { dot11OperationEntry 36 } dot11OBSSScanActiveDwell OBJECT-TYPE SYNTAX Unsigned32 (10..1000) UNITS "TUs" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute indicates the minimum amount of time that the STA continuously scans each channel when performing an active OBSS scan operation." DEFVAL { 10 } ::= { dot11OperationEntry 37 } dot11OBSSScanPassiveTotalPerChannel OBJECT-TYPE SYNTAX Unsigned32 (200..10000) UNITS "TUs" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute indicates the minimum total amount of time that the STA scans each channel when performing a passive OBSS scan operation." DEFVAL { 200 } ::= { dot11OperationEntry 38 } dot11OBSSScanActiveTotalPerChannel OBJECT-TYPE SYNTAX Unsigned32 (20..10000) UNITS "TUs" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute indicates the minimum total amount of time that the STA scans each channel when performing an active OBSS scan operation." DEFVAL { 20 } ::= { dot11OperationEntry 39 } dot112040BSSCoexistenceManagementSupport OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the STA supports the transmission and reception of the 20/40 BSS Coexistence Management frame." DEFVAL { false } ::= { dot11OperationEntry 40 } dot11OBSSScanActivityThreshold OBJECT-TYPE 3095 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications SYNTAX Unsigned32 (0..100) UNITS "0.01%" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute indicates the maximum total time that a STA may be active on the medium during a period of dot11BSSWidthChannelTransitionDelayFactor * dot11BSSWidthTriggerScanInterval seconds without being obligated to perform OBSS Scan operations. The default value of this attribute is 25, which equates to 0.25%." DEFVAL { 25 } ::= { dot11OperationEntry 41} -- ********************************************************************** -- * End of dot11Operation TABLE -- ********************************************************************** -- ********************************************************************** -- * dot11Counters TABLE -- ********************************************************************** dot11CountersTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11CountersEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Group containing attributes that are MAC counters. Implemented as a table to allow for multiple instantiations on an agent." ::= { dot11mac 2 } dot11CountersEntry OBJECT-TYPE SYNTAX Dot11CountersEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11CountersEntry Table. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX { ifIndex } ::= { dot11CountersTable 1 } Dot11CountersEntry ::= SEQUENCE { dot11TransmittedFragmentCount Counter32, dot11GroupTransmittedFrameCount Counter32, dot11FailedCount Counter32, dot11RetryCount Counter32, dot11MultipleRetryCount Counter32, dot11FrameDuplicateCount Counter32, dot11RTSSuccessCount Counter32, dot11RTSFailureCount Counter32, dot11AckFailureCount Counter32, dot11ReceivedFragmentCount Counter32, dot11GroupReceivedFrameCount Counter32, dot11FCSErrorCount Counter32, dot11TransmittedFrameCount Counter32, dot11WEPUndecryptableCount Counter32, dot11QosDiscardedFragmentCount Counter32, dot11AssociatedStationCount Counter32, 3096 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11QosCFPollsReceivedCount Counter32, dot11QosCFPollsUnusedCount Counter32, dot11QosCFPollsUnusableCount Counter32, dot11QosCFPollsLostCount Counter32, dot11TransmittedAMSDUCount Counter32, dot11FailedAMSDUCount Counter32, dot11RetryAMSDUCount Counter32, dot11MultipleRetryAMSDUCount Counter32, dot11TransmittedOctetsInAMSDUCount Counter64, dot11AMSDUAckFailureCount Counter32, dot11ReceivedAMSDUCount Counter32, dot11ReceivedOctetsInAMSDUCount Counter64, dot11TransmittedAMPDUCount Counter32, dot11TransmittedMPDUsInAMPDUCount Counter32, dot11TransmittedOctetsInAMPDUCount Counter64, dot11AMPDUReceivedCount Counter32, dot11MPDUInReceivedAMPDUCount Counter32, dot11ReceivedOctetsInAMPDUCount Counter64, dot11AMPDUDelimiterCRCErrorCount Counter32, dot11ImplicitBARFailureCount Counter32, dot11ExplicitBARFailureCount Counter32, dot11ChannelWidthSwitchCount Counter32, dot11TwentyMHzFrameTransmittedCount Counter32, dot11FortyMHzFrameTransmittedCount Counter32, dot11TwentyMHzFrameReceivedCount Counter32, dot11FortyMHzFrameReceivedCount Counter32, dot11PSMPUTTGrantDuration Counter32, dot11PSMPUTTUsedDuration Counter32, dot11GrantedRDGUsedCount Counter32, dot11GrantedRDGUnusedCount Counter32, dot11TransmittedFramesInGrantedRDGCount Counter32, dot11TransmittedOctetsInGrantedRDGCount Counter64, dot11BeamformingFrameCount Counter32, dot11DualCTSSuccessCount Counter32, dot11DualCTSFailureCount Counter32, dot11STBCCTSSuccessCount Counter32, dot11STBCCTSFailureCount Counter32, dot11nonSTBCCTSSuccessCount Counter32, dot11nonSTBCCTSFailureCount Counter32, dot11RTSLSIGSuccessCount Counter32, dot11RTSLSIGFailureCount Counter32, dot11PBACErrors Counter32, dot11DeniedAssociationCounterDueToBSSLoad Counter32, dot11TransmittedMSDUOctetsCount Counter64, dot11ReceivedMSDUOctetsCount Counter64 } dot11TransmittedFragmentCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a fragment is successfully transmitted. This counter is incremented for an acknowledged MPDU with an individual address in the Address 1 field or an MPDU with a group address in the Address 1 field with the Type subfield equal to Data or Management." ::= { dot11CountersEntry 1 } dot11GroupTransmittedFrameCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current 3097 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DESCRIPTION "This is a status variable. It is written by the MAC when a group addressed frame is transmitted. This counter is incremented only when the group bit is set in the destination MAC address of a successfully transmitted MSDU. When operating as a STA in an infrastructure BSS, where these frames are directed to the AP, this implies having received an acknowledgment to all associated MPDUs." ::= { dot11CountersEntry 2 } dot11FailedCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. This counter increments when an MSDU is not transmitted successfully due to the number of transmit attempts exceeding either the dot11ShortRetryLimit or dot11LongRetryLimit." ::= { dot11CountersEntry 3 } dot11RetryCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. This counter increments when an MSDU is successfully transmitted after one or more retransmissions." ::= { dot11CountersEntry 4 } dot11MultipleRetryCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. This counter increments when an MSDU is successfully transmitted after more than one retransmission." ::= { dot11CountersEntry 5 } dot11FrameDuplicateCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. This counter increments when a frame is received that the Sequence Control field indicates is a duplicate." ::= { dot11CountersEntry 6 } dot11RTSSuccessCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current 3098 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DESCRIPTION "This is a status variable. It is written by the MAC when a CTS frame is received in response to an RTS. This counter increments when a CTS frame is received in response to an RTS." ::= { dot11CountersEntry 7 } dot11RTSFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. This counter increments when a CTS frame is not received in response to an RTS." ::= { dot11CountersEntry 8 } dot11AckFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. This counter increments when an Ack frame is not received when expected." ::= { dot11CountersEntry 9 } dot11ReceivedFragmentCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a fragment is successfully received. This counter is incremented for each successfully received MPDU with the Type subfield equal to Data or Management." ::= { dot11CountersEntry 10 } dot11GroupReceivedFrameCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a group addressed frame is received. This counter increments when an MSDU is received with the group bit set in the destination MAC address." ::= { dot11CountersEntry 11 } dot11FCSErrorCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. 3099 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This counter increments when an FCS error is detected in a received MPDU." ::= { dot11CountersEntry 12 } dot11TransmittedFrameCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a frame is successfully transmitted. This counter increments for each successfully transmitted MSDU." ::= { dot11CountersEntry 13 } dot11WEPUndecryptableCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. This counter increments when a frame is received with the Protected Frame subfield of the Frame Control field equal to 1 and the WEPOn value for the key mapped to the transmitter's MAC address indicates that the frame should not have been encrypted or that frame is discarded due to the receiving STA not implementing the privacy option." ::= { dot11CountersEntry 14 } dot11QosDiscardedFragmentCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. This counter increments for each QoS Data frame that has been discarded." ::= { dot11CountersEntry 15 } dot11AssociatedStationCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a STA associates or disassociates. This counter, only available at AP, increments when a station associates or reassociates. This counter decrements when a station disassociates." ::= { dot11CountersEntry 16 } dot11QosCFPollsReceivedCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a CF-Poll is received. This counter increments for each QoS (+)CF-Poll that has been received." ::= { dot11CountersEntry 17 } dot11QosCFPollsUnusedCount OBJECT-TYPE 3100 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a CF-Poll is unused. This counter increments for each QoS (+)CF-Poll that has been received but not used." ::= { dot11CountersEntry 18 } dot11QosCFPollsUnusableCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. This counter increments for each QoS (+)CF-Poll that has been received but could not be used due to the TXOP size being smaller than the time that is required for one frame exchange sequence." ::= { dot11CountersEntry 19 } dot11QosCFPollsLostCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. This counter increments for each QoS (+)CF-Poll that has been issued where there was no response from the QoS STA." ::= { dot11CountersEntry 20 } dot11TransmittedAMSDUCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a transmitted A-MSDU is acknowledged. This counter shall be incremented for an acknowledged A-MSDU frame with an individual address in the Address 1 field or an A-MSDU frame with a group address in the Address 1 field." ::= { dot11CountersEntry 21 } dot11FailedAMSDUCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. This counter shall be incremented when an A-MSDU is not transmitted successfully due to the number of transmit attempts exceeding either the dot11ShortRetryLimit or dot11LongRetryLimit." ::= { dot11CountersEntry 22 } dot11RetryAMSDUCount OBJECT-TYPE SYNTAX Counter32 3101 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a transmitted A-MSDU is acknowledged only after one or more retransmissions. This counter shall be incremented when an A-MSDU is successfully transmitted after one or more retransmissions." ::= { dot11CountersEntry 23 } dot11MultipleRetryAMSDUCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a transmitted A-MSDU is acknowledged only after more than one retransmission. This counter shall be incremented when an A-MSDU is successfully transmitted after more than one retransmission." ::= { dot11CountersEntry 24 } dot11TransmittedOctetsInAMSDUCount OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when an A-MSDU is transmitted. This counter shall be incremented by the number of octets in the frame body of an A-MSDU frame when an A-MSDU frame is successfully transmitted." ::= { dot11CountersEntry 25 } dot11AMSDUAckFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. This counter shall be incremented when an acknowledgment to an A-MSDU is not received when expected. This acknowledgment can be in an Ack or Block- Ack frame." ::= { dot11CountersEntry 26 } dot11ReceivedAMSDUCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when an A-MSDU is received. This counter shall be incremented for a received A-MSDU frame with the station's MAC address in the Address 1 field or an A-MSDU frame with a group address in the Address 1 field." ::= { dot11CountersEntry 27 } dot11ReceivedOctetsInAMSDUCount OBJECT-TYPE SYNTAX Counter64 3102 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when an A-MSDU is received. This counter shall be incremented by the number of octets in the frame body of an A-MSDU frame when an A-MSDU frame is received." ::= { dot11CountersEntry 28 } dot11TransmittedAMPDUCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when an A-MPDU is transmitted. This counter shall be incremented when an A-MPDU is transmitted." ::= { dot11CountersEntry 29 } dot11TransmittedMPDUsInAMPDUCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when an A-MPDU is transmitted. This counter shall increment by the number of MPDUs in the A-MPDU when an A-MPDU is transmitted." ::= { dot11CountersEntry 30 } dot11TransmittedOctetsInAMPDUCount OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when an A-MPDU is transmitted. This counter shall be incremented by the number of octets in the A-MPDU frame when an A-MPDU frame is transmitted." ::= { dot11CountersEntry 31 } dot11AMPDUReceivedCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when an A-MPDU is received. This counter shall be incremented when the MAC receives an A-MPDU from the PHY." ::= { dot11CountersEntry 32 } dot11MPDUInReceivedAMPDUCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when an A-MPDU is received. 3103 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This counter shall be incremented by the number of MPDUs received in the A-MPDU when an A-MPDU is received." ::= { dot11CountersEntry 33 } dot11ReceivedOctetsInAMPDUCount OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when an A-MPDU is received. This counter shall be incremented by the number of octets in the A-MPDU frame when an A-MPDU frame is received." ::= { dot11CountersEntry 34 } dot11AMPDUDelimiterCRCErrorCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. This counter shall be incremented when an MPDU delimiter has a CRC error when this is the first CRC error in the received A-MPDU or when the previous delimiter has been decoded correctly." ::= { dot11CountersEntry 35 } dot11ImplicitBARFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. This counter shall be incremented when the expected BlockAck frame is not received in response to an Implicit BlockAckReq frame." ::= { dot11CountersEntry 36 } dot11ExplicitBARFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. This counter shall be incremented when the expected BlockAck frame is not received in response to an Explicit BlockAckReq frame." ::= { dot11CountersEntry 37 } dot11ChannelWidthSwitchCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the bandwidth is switched. This counter shall be increment when the bandwidth used is switched from 20 to 40 or vice-versa." 3104 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ::= { dot11CountersEntry 38 } dot11TwentyMHzFrameTransmittedCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a frame is transmitted only on the primary channel. This counter shall be incremented when a frame is transmitted only on the primary channel." ::= { dot11CountersEntry 39 } dot11FortyMHzFrameTransmittedCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a frame is transmitted on both control and secondary channels. This counter shall be incremented when a frame is transmitted on both control and secondary channels." ::= { dot11CountersEntry 40 } dot11TwentyMHzFrameReceivedCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a frame is received only on the primary channel. This counter shall be incremented when a frame is received only on the primary channel." ::= { dot11CountersEntry 41 } dot11FortyMHzFrameReceivedCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a frame is received on both the control and secondary channels. This counter shall be incremented when a frame is received on both the control and secondary channels." ::= { dot11CountersEntry 42 } dot11PSMPUTTGrantDuration OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a PSMP-UTT is granted. This counter contains the cumulative duration of PSMP-UTT granted to the STA, in units of 4 microseconds." 3105 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ::= { dot11CountersEntry 43 } dot11PSMPUTTUsedDuration OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a PSMP-UTT is used. This counter contains the cumulative duration of transmission by the STA during its allocated PSMP-UTT, in units of 4 microseconds" ::= { dot11CountersEntry 44 } dot11GrantedRDGUsedCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when an RDG is used. This counter at the RD initiator shall be incremented when an allocated RDG is used by the station, apart from transmitting a response frame such as Ack or BlockAck frames." ::= { dot11CountersEntry 45 } dot11GrantedRDGUnusedCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when an RDG is not used. This counter at the initiator shall be incremented when an allocated RDG is not used by the station, apart from transmitting a response frame such as Ack or BlockAck frames." ::= { dot11CountersEntry 46 } dot11TransmittedFramesInGrantedRDGCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when an RDG is used. This counter at the initiator shall be incremented for every frame, other than response frames such as Ack or BlockAck frames, transmitted by the station during a granted RDG." ::= { dot11CountersEntry 47 } dot11TransmittedOctetsInGrantedRDGCount OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when an RDG is used. This counter at the initiator shall be incremented by the number of octets in the frame body of a frame, other than response frames such as Ack or BlockAck frames, transmitted by the station during a granted RDG." 3106 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ::= { dot11CountersEntry 48 } dot11BeamformingFrameCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a frame with beamforming parameters is sent. This counter shall be incremented when the transmitter sends a frame with new/updated beamforming parameters." ::= { dot11CountersEntry 49 } dot11DualCTSSuccessCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a dual CTS is sent. This counter shall be incremented when AP sends a dual CTS in response to a STA initiating TXOP in extended range." ::= { dot11CountersEntry 50 } dot11DualCTSFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a dual CTS is not sent. This counter shall be incremented when AP fails to send a dual CTS in response to a STA initiating TXOP in extended range." ::= { dot11CountersEntry 51 } dot11STBCCTSSuccessCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when no collision is detected. This counter shall be incremented when AP does not detect a collision PIFS after sending a CTS to self STBC frame in extended range." ::= { dot11CountersEntry 52 } dot11STBCCTSFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a collision is detected. This counter shall be incremented when AP detects a collision PIFS after sending a CTS to self STBC frame in extended range." ::= { dot11CountersEntry 53 } dot11nonSTBCCTSSuccessCount OBJECT-TYPE SYNTAX Counter32 3107 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when no collision is detected. This counter shall be incremented when AP does not detect a collision PIFS after sending a CTS to self that is an non-STBC frame in extended range." ::= { dot11CountersEntry 54 } dot11nonSTBCCTSFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a collision is detected. This counter shall be incremented when AP detects a collision PIFS after sending a CTS to self that is an non-STBC frame in extended range." ::= { dot11CountersEntry 55 } dot11RTSLSIGSuccessCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. This counter shall be incremented when the duration/ID field is set according to the rules of L-SIG TXOP protection in the received CTS following a transmission of RTS in L-SIG TXOP protection mode." ::= { dot11CountersEntry 56 } dot11RTSLSIGFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. This counter shall be incremented when the duration/ID field is not set according to the rules of L-SIG TXOP protection in the received CTS following a transmission of RTS in L-SIG TXOP protection mode." ::= { dot11CountersEntry 57 } dot11PBACErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. This variable indicates the number of errors encountered in the PBAC procedures." ::= { dot11CountersEntry 58} dot11DeniedAssociationCounterDueToBSSLoad OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current 3108 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DESCRIPTION "This is a status variable. It is written by the SME when the condition described below occurs. This counter, available at a WNM AP, shall increment when an (re)association request is denied because the AP has insufficient bandwidth to handle the additional STA." ::= { dot11CountersEntry 59} dot11TransmittedMSDUOctetsCount OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when an MSDU is successfully transmitted. This counter is incremented by the number of octets in the MSDU when an MSDU is successfully transmitted." ::= { dot11CountersEntry 60 } dot11ReceivedMSDUOctetsCount OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when an MSDU is received that is addressed to the STA (either individually or globally). This counter is incremented by the number of octets in the MSDU." ::= { dot11CountersEntry 61 } -- ********************************************************************** -- * End of dot11Counters TABLE -- ********************************************************************** -- ********************************************************************** -- * dot11GroupAddresses TABLE -- ********************************************************************** dot11GroupAddressesTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11GroupAddressesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual table containing a set of MAC addresses identifying the multicast-group addresses for which this STA receives frames. The default value of this attribute is null." ::= { dot11mac 3 } dot11GroupAddressesEntry OBJECT-TYPE SYNTAX Dot11GroupAddressesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An Entry (conceptual row) in the Group Addresses Table. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX { ifIndex, dot11GroupAddressesIndex } ::= { dot11GroupAddressesTable 1 } 3109 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Dot11GroupAddressesEntry ::= SEQUENCE { dot11GroupAddressesIndex InterfaceIndex, dot11GroupAddress MacAddress, dot11GroupAddressesStatus RowStatus } dot11GroupAddressesIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The auxiliary variable used to identify instances of the columnar objects in the Group Addresses Table." ::= { dot11GroupAddressesEntry 1 } dot11GroupAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-create STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. MAC address identifying multicast-group addresses from which this STA receives frames." ::= { dot11GroupAddressesEntry 2 } dot11GroupAddressesStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status column used for creating, modifying, and deleting instances of the columnar objects in the Group Addresses Table." DEFVAL { active } ::= { dot11GroupAddressesEntry 3 } -- ********************************************************************** -- * End of dot11GroupAddresses TABLE -- ********************************************************************** -- ********************************************************************** -- * SMT EDCA Config TABLE -- ********************************************************************** dot11EDCATable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11EDCAEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Conceptual table for EDCA default parameter values at a non-AP STA. This table contains the four entries of the EDCA parameters corresponding to four possible ACs. Index 1 corresponds to AC_BK, index 2 to AC_BE, index 3 to AC_VI, and index 4 to AC_VO." REFERENCE "IEEE Std 802.11-2012, 10.2.4.2" ::= { dot11mac 4 } dot11EDCAEntry OBJECT-TYPE SYNTAX Dot11EDCAEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION 3110 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications "An Entry (conceptual row) in the EDCA Table. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX { ifIndex, dot11EDCATableIndex } ::= { dot11EDCATable 1 } Dot11EDCAEntry ::= SEQUENCE { dot11EDCATableIndex Unsigned32, dot11EDCATableCWmin Unsigned32, dot11EDCATableCWmax Unsigned32, dot11EDCATableAIFSN Unsigned32, dot11EDCATableTXOPLimit Unsigned32, dot11EDCATableMSDULifetime Unsigned32, dot11EDCATableMandatory TruthValue } dot11EDCATableIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The auxiliary variable used to identify instances of the columnar objects in the EDCA Table. The value of this variable is 1, if the value of the AC is AC_BK. 2, if the value of the AC is AC_BE. 3, if the value of the AC is AC_VI. 4, if the value of the AC is AC_VO." ::= { dot11EDCAEntry 1 } dot11EDCATableCWmin OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the MAC upon receiving an EDCA Parameter Set. Changes take effect as soon as practical in the implementation. This attribute specifies the value of the minimum size of the window that is used by a STA for a particular AC for generating a random number for the backoff. The value of this attribute is such that it could always be expressed in the form of 2**X - 1, where X is an integer. See Table 9-137 and Table 9-138." ::= { dot11EDCAEntry 2 } dot11EDCATableCWmax OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the MAC upon receiving an EDCA Parameter Set. Changes take effect as soon as practical in the implementation. This attribute specifies the value of the maximum size of the window that is used by a STA for a particular AC for generating a random number for the backoff. The value of this attribute is such that it could always be expressed in the form of 2**X - 1, where X is an integer. See Table 9-137 and Table 9-138." ::= { dot11EDCAEntry 3 } dot11EDCATableAIFSN OBJECT-TYPE SYNTAX Unsigned32 (2..15) 3111 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the MAC upon receiving an EDCA Parameter Set element. Changes take effect as soon as practical in the implementation. This attribute specifies the number of slots, after a SIFS, that the STA, for a particular AC, senses the medium idle either before transmitting or executing a backoff. See Table 9-137 and Table 9-138." ::= { dot11EDCAEntry 4 } dot11EDCATableTXOPLimit OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "32 microseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MLME upon receiving an EDCA Parameter Set element. This attribute specifies the maximum duration of an EDCA TXOP for a given AC, for a non-AP non-OCB STA. The default value for this attribute is given (in different units) in Table 9-137. REFERENCE IEEE Std 802.11-2016, 9.4.2.29" ::= { dot11EDCAEntry 5 } dot11EDCATableMSDULifetime OBJECT-TYPE SYNTAX Unsigned32 (0..500) UNITS "TUs" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the MAC upon receiving an EDCA Parameter Set in a Beacon frame. Changes take effect as soon as practical in the implementation. This attribute specifies the maximum duration an MSDU, for a given AC, would be retained by the MAC before it is discarded." DEFVAL { 500 } ::= { dot11EDCAEntry 6 } dot11EDCATableMandatory OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the MAC upon receiving an EDCA Parameter Set in a Beacon frame. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that admission control is mandatory for the given AC. When false, this attribute indicates that admission control is not mandatory for the given AC." DEFVAL { false } ::= { dot11EDCAEntry 7 } -- ********************************************************************** -- * End of SMT EDCA Config TABLE -- ********************************************************************** -- ********************************************************************** 3112 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications -- * SMT AP EDCA Config TABLE -- ********************************************************************** dot11QAPEDCATable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11QAPEDCAEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Conceptual table for EDCA default parameter values at the AP. This table contains the four entries of the EDCA parameters corresponding to four possible ACs. Index 1 corresponds to AC_BK, index 2 to AC_BE, index 3 to AC_VI, and index 4 to AC_VO." REFERENCE "IEEE Std 802.11-2012, 10.22.2" ::= { dot11mac 5 } dot11QAPEDCAEntry OBJECT-TYPE SYNTAX Dot11QAPEDCAEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An Entry (conceptual row) in the EDCA Table. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Inter- face tables in this MIB module are indexed by ifIndex." INDEX { ifIndex, dot11QAPEDCATableIndex } ::= { dot11QAPEDCATable 1 } Dot11QAPEDCAEntry ::= SEQUENCE { dot11QAPEDCATableIndex Unsigned32, dot11QAPEDCATableCWmin Unsigned32, dot11QAPEDCATableCWmax Unsigned32, dot11QAPEDCATableAIFSN Unsigned32, dot11QAPEDCATableTXOPLimit Unsigned32, dot11QAPEDCATableMSDULifetime Unsigned32, dot11QAPEDCATableMandatory TruthValue } dot11QAPEDCATableIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The auxiliary variable used to identify instances of the columnar objects in the EDCA Table. The value of this variable is 1, if the value of the AC is AC_BK. 2, if the value of the AC is AC_BE. 3, if the value of the AC is AC_VI. 4, if the value of the AC is AC_VO." ::= { dot11QAPEDCAEntry 1 } dot11QAPEDCATableCWmin OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the value of the minimum size of the window that is used by an AP for a particular AC for generating a random number for the backoff. The value of this attribute is such that it could always be expressed in the form of 2**X - 1, where X is an integer. The default 3113 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications value for this attribute is aCWmin, if dot11QAPEDCATableIndex is 1 or 2. (aCWmin+1)/2 - 1, if dot11QAPEDCATableIndex is 3. (aCWmin+1)/4 - 1, if dot11QAPEDCATableIndex is 4." ::= { dot11QAPEDCAEntry 2 } dot11QAPEDCATableCWmax OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the value of the maximum size of the window that is used by an AP for a particular AC for generating a random number for the backoff. The value of this attribute is such that it could always be expressed in the form of 2**X - 1, where X is an integer. The default value for this attribute is aCWmax, if dot11QAPEDCATableIndex is 1. 4*(aCWmin+1) - 1, if dot11QAPEDCATableIndex is 2. aCWmin, if dot11QAPEDCATableIndex is 3. (aCWmin+1)/2 - 1, if dot11QAPEDCATableIndex is 4." ::= { dot11QAPEDCAEntry 3 } dot11QAPEDCATableAIFSN OBJECT-TYPE SYNTAX Unsigned32 (1..15) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the number of slots, after a SIFS, that the AP, for a particular AC, senses the medium idle either before transmitting or executing a backoff. The default value for this attribute is 7, if dot11QAPEDCATableIndex is 1, 3, if dot11QAPEDCATableIndex is 2 1, otherwise." ::= { dot11QAPEDCAEntry 4 } dot11QAPEDCATableTXOPLimit OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "32 microseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the maximum duration of an EDCA TXOP for a given AC, for an AP. The default value for this attribute is given (in different units) in Table 9-137. REFERENCE IEEE Std 802.11-2016, 9.4.2.29" ::= { dot11QAPEDCAEntry 5 } dot11QAPEDCATableMSDULifetime OBJECT-TYPE SYNTAX Unsigned32 (0..500) UNITS "TUs" MAX-ACCESS read-write STATUS current 3114 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute specifies the maximum duration an MSDU, for a given AC, would be retained by the MAC at the AP before it is discarded." DEFVAL { 500 } ::= { dot11QAPEDCAEntry 6 } dot11QAPEDCATableMandatory OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that admission control is mandatory for the given AC. When false, this attribute indicates that admission control is not mandatory for the given AC. The default value for this parameter is false." ::= { dot11QAPEDCAEntry 7 } -- ********************************************************************** -- * End of SMT AP EDCA Config TABLE -- ********************************************************************** -- ********************************************************************** -- * dot11QosCounters TABLE -- ********************************************************************** dot11QosCountersTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11QosCountersEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Group containing attributes that are MAC counters implemented as a table to allow for multiple instantiations on an agent." ::= { dot11mac 6 } dot11QosCountersEntry OBJECT-TYPE SYNTAX Dot11QosCountersEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An Entry (conceptual row) in the EDCA Table. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX { ifIndex, dot11QosCountersIndex } ::= { dot11QosCountersTable 1 } Dot11QosCountersEntry ::= SEQUENCE { dot11QosCountersIndex Unsigned32, dot11QosTransmittedFragmentCount Counter32, dot11QosFailedCount Counter32, dot11QosRetryCount Counter32, dot11QosMultipleRetryCount Counter32, dot11QosFrameDuplicateCount Counter32, dot11QosRTSSuccessCount Counter32, dot11QosRTSFailureCount Counter32, 3115 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11QosAckFailureCount Counter32, dot11QosReceivedFragmentCount Counter32, dot11QosTransmittedFrameCount Counter32, dot11QosDiscardedFrameCount Counter32, dot11QosMPDUsReceivedCount Counter32, dot11QosRetriesReceivedCount Counter32 } dot11QosCountersIndex OBJECT-TYPE SYNTAX Unsigned32 (1..16) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The auxiliary variable used to identify instances of the columnar objects in the QoSCounter Table. The value of this variable is equal to TID + 1." ::= { dot11QosCountersEntry 1 } dot11QosTransmittedFragmentCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a QoS fragment is transmitted. This counter is incremented for an acknowledged MPDU, for a particular UP, with an individual address in the Address 1 field or an MPDU with a group address in the Address 1 field, either belonging to a particular TID. This counter has relevance only for TIDs between 0 and 7." ::= { dot11QosCountersEntry 2 } dot11QosFailedCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. This counter increments when an MSDU, for a particular UP, is not transmitted successfully due to the number of transmit attempts exceeding either the dot11ShortRetryLimit or dot11LongRetryLimit. This counter has relevance only for TIDs between 0 and 7." ::= { dot11QosCountersEntry 3 } dot11QosRetryCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. This counter increments when an MSDU, of a particular UP, is successfully transmitted after one or more retransmissions. This counter has relevance only for TIDs between 0 and 7." ::= { dot11QosCountersEntry 4 } dot11QosMultipleRetryCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. 3116 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This counter increments when an MSDU, of a particular UP, is successfully transmitted after more than one retransmissions. This counter has relevance only for TIDs between 0 and 7." ::= { dot11QosCountersEntry 5 } dot11QosFrameDuplicateCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. This counter increments when a frame, of a particular UP, is received that the Sequence Control field indicates is a duplicate. This counter has relevance only for TIDs between 0 and 7." ::= { dot11QosCountersEntry 6 } dot11QosRTSSuccessCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a CTS frame is received in response to an RTS. This counter increments when a CTS frame is received in response to an RTS that has been sent for the transmission of an MPDU of a particular UP. This counter has relevance only for TIDs between 0 and 7." ::= { dot11QosCountersEntry 7 } dot11QosRTSFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. This counter increments when a CTS frame is not received in response to an RTS that has been sent for the transmission of an MPDU of a particular UP. This counter has relevance only for TIDs between 0 and 7." ::= { dot11QosCountersEntry 8 } dot11QosAckFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. This counter increments when an Ack frame is not received in response to an MPDU of a particular UP. This counter has relevance only for TIDs between 0 and 7." ::= { dot11QosCountersEntry 9 } dot11QosReceivedFragmentCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION 3117 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications "This is a status variable. It is written by the MAC when a QoS fragment is received. This counter is incremented for each successfully received MPDU with the Type subfield equal to Data of a particular UP. This counter has relevance only for TIDs between 0 and 7." ::= { dot11QosCountersEntry 10 } dot11QosTransmittedFrameCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a QoS frame is transmitted. This counter increments for each successfully transmitted MSDU of a particular UP. This counter has relevance only for TIDs between 0 and 7." ::= { dot11QosCountersEntry 11 } dot11QosDiscardedFrameCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. This counter increments for each Discarded MSDU of a particular UP. This counter has relevance only for TIDs between 0 and 7." ::= { dot11QosCountersEntry 12 } dot11QosMPDUsReceivedCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when a QoS MPDU is received. This counter increments for each received MPDU of a particular TID." ::= { dot11QosCountersEntry 13 } dot11QosRetriesReceivedCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MAC when the condition described below occurs. This counter increments for each received MPDU of a particular TID with the Retry subfield equal to 1." ::= { dot11QosCountersEntry 14 } -- ********************************************************************** -- * End of dot11QosCounters TABLE -- ********************************************************************** -- ********************************************************************** -- * Resource Type Attribute Templates -- ********************************************************************** dot11ResourceTypeIDName OBJECT-TYPE 3118 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications SYNTAX DisplayString (SIZE(4)) MAX-ACCESS read-only STATUS current DESCRIPTION "Contains the name of the Resource Type ID managed object. The attribute is read-only and always contains the value RTID. This attribute value is not used as a naming attribute for any other managed object class." REFERENCE "IEEE Std 802.1F-1993, A.7" DEFVAL { "RTID" } ::= { dot11resAttribute 1 } -- ********************************************************************** -- * dot11ResourceInfo TABLE -- ********************************************************************** dot11ResourceInfoTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11ResourceInfoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "provides a means of indicating, in data readable from a managed object, information that identifies the source of the implementation." REFERENCE "IEEE Std 802.1F-1993, A.7. Note that this standard has been withdrawn." ::= { dot11resAttribute 2 } dot11ResourceInfoEntry OBJECT-TYPE SYNTAX Dot11ResourceInfoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11ResourceInfo Table. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX { ifIndex } ::= { dot11ResourceInfoTable 1 } Dot11ResourceInfoEntry ::= SEQUENCE { dot11manufacturerOUI OCTET STRING, dot11manufacturerName DisplayString, dot11manufacturerProductName DisplayString, dot11manufacturerProductVersion DisplayString } dot11manufacturerOUI OBJECT-TYPE SYNTAX OCTET STRING (SIZE(3)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. Takes the value of an IEEE assigned unique identifier (OUI or CID)." ::= { dot11ResourceInfoEntry 1 } dot11manufacturerName OBJECT-TYPE SYNTAX DisplayString (SIZE(0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. 3119 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications A printable string used to identify the manufacturer of the resource. Maximum string length is 128 octets." ::= { dot11ResourceInfoEntry 2 } dot11manufacturerProductName OBJECT-TYPE SYNTAX DisplayString (SIZE(0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. A printable string used to identify the manufacturer's product name of the resource. Maximum string length is 128 octets." ::= { dot11ResourceInfoEntry 3 } dot11manufacturerProductVersion OBJECT-TYPE SYNTAX DisplayString (SIZE(0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. Printable string used to identify the manufacturer's product version of the resource. Maximum string length is 128 octets." ::= { dot11ResourceInfoEntry 4 } -- ********************************************************************** -- * End of dot11ResourceInfo TABLE -- ********************************************************************** -- ******************************************************************* -- * dot11DMGOperation TABLE -- ******************************************************************* dot11DMGOperationTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11DMGOperationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is a Table management object. The dot11DMGOperation Table" ::= { dot11mac 8 } dot11DMGOperationEntry OBJECT-TYPE SYNTAX Dot11DMGOperationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is an entry in the dot11DMGOperation Table. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX { ifIndex } ::= { dot11DMGOperationTable 1 } Dot11DMGOperationEntry ::= SEQUENCE { dot11MaxLostBeacons Unsigned32, dot11MinBHIDuration Unsigned32, dot11PSRequestSuspensionInterval Unsigned32, dot11BroadcastSTAInfoDuration Unsigned32, dot11NbrOfChangeBeacons Unsigned32, 3120 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11ImplicitHandoverLostBeacons Unsigned32, dot11MinPPDuration Unsigned32, dot11SPIdleTimeout Unsigned32, dot11QABTimeout Unsigned32, dot11ClusterEnableTime Unsigned32, dot11PNWarningThresholdLow Unsigned32, dot11PNWarningThresholdHigh Unsigned32, dot11BeaconSPDuration Unsigned32, dot11PNExhaustionThresholdLow Unsigned32, dot11PNExhaustionThresholdHigh Unsigned32, dot11MaxNumberOfClusteringMonitoringPeriods Unsigned32, dot11DMGEcssPolicyDetailUpdateDurationMax Unsigned32, dot11DMGEcssClusterReportDurationMin Unsigned32, dot11DMGNavSync Unsigned32 } dot11MaxLostBeacons OBJECT-TYPE SYNTAX Unsigned32 (1..32) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or an external management entity. Changes take effect as soon as practical in the implementation. Maximum Number of Lost Beacons" DEFVAL { 4 } ::= { dot11DMGOperationEntry 1 } dot11MinBHIDuration OBJECT-TYPE SYNTAX Unsigned32 (1..100000) UNITS "microseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or an external management entity. Changes take effect as soon as practical in the implementation. Minimum Beacon Header Interval duration." DEFVAL { 5000 } ::= { dot11DMGOperationEntry 2 } dot11PSRequestSuspensionInterval OBJECT-TYPE SYNTAX Unsigned32 (1..64) UNITS "beacon intervals" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or an external management entity. Changes take effect as soon as practical in the implementation. PS Request Suspension Interval" DEFVAL { 8 } ::= { dot11DMGOperationEntry 3 } dot11BroadcastSTAInfoDuration OBJECT-TYPE SYNTAX Unsigned32 (1..512) UNITS "beacon intervals" MAX-ACCESS read-write STATUS current DESCRIPTION 3121 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications "This is a control variable. It is written by the SME or an external management entity. Changes take effect as soon as practical in the implementation. Broadcast STA Information Duration." DEFVAL { 32 } ::= { dot11DMGOperationEntry 5 } dot11NbrOfChangeBeacons OBJECT-TYPE SYNTAX Unsigned32 (1..32) UNITS "beacon intervals" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or an external management entity. Changes take effect as soon as practical in the implementation. Number of Change Beacons." DEFVAL { 4 } ::= { dot11DMGOperationEntry 6 } dot11ImplicitHandoverLostBeacons OBJECT-TYPE SYNTAX Unsigned32 (1..32) UNITS "beacon intervals" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or an external management entity. Changes take effect as soon as practical in the implementation. Implicit handover lost beacons." DEFVAL { 8 } ::= { dot11DMGOperationEntry 7 } dot11MinPPDuration OBJECT-TYPE SYNTAX Unsigned32 (1..100000) UNITS "microseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or an external management entity. Changes take effect as soon as practical in the implementation. The MinPPDuration subfield indicates the minimum duration of the PP and GP as part of the dynamic allocation of service period mechanism." DEFVAL { 200 } ::= { dot11DMGOperationEntry 8 } dot11SPIdleTimeout OBJECT-TYPE SYNTAX Unsigned32 (1..100000) UNITS "microseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or an external management entity. Changes take effect as soon as practical in the implementation. The SPIdleTimeout subfield indicates time during which a STA expects to receive a frame from its partner STA." 3122 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DEFVAL { 200 } ::= { dot11DMGOperationEntry 9 } dot11QABTimeout OBJECT-TYPE SYNTAX Unsigned32 (1..64000) UNITS "milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or an external management entity. Changes take effect as soon as practical in the implementation. Quiet Adjacent BSS Operation Timeout." DEFVAL { 1000 } ::= { dot11DMGOperationEntry 10 } dot11ClusterEnableTime OBJECT-TYPE SYNTAX Unsigned32 (1..32) UNITS "beacon intervals" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or an external management entity. Changes take effect as soon as practical in the implementation. Frequency with which a non-AP and non-PCP is allowed to retransmit a cluster request element to its AP or PCP." DEFVAL { 8 } ::= { dot11DMGOperationEntry 11 } dot11PNWarningThresholdLow OBJECT-TYPE SYNTAX INTEGER (0..4294967295) UNITS "packet number" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or an external management entity. Changes take effect as soon as practical in the implementation. Threshold used for generating a warning to the MLME about a potential PN exhaustion. Threshold is a 48 bit integer. This field contains the least significant 32 bits of the threshold." DEFVAL { 4294967295 } ::= { dot11DMGOperationEntry 12 } dot11PNWarningThresholdHigh OBJECT-TYPE SYNTAX INTEGER (0..65535) UNITS "packet number" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or an external management entity. Changes take effect as soon as practical in the implementation. Threshold used for generating a warning to the MLME about a potential PN exhaustion. Threshold is a 48 bit integer. This field contains the most significant 16 bits of the threshold." DEFVAL { 65535 } 3123 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ::= { dot11DMGOperationEntry 13 } dot11BeaconSPDuration OBJECT-TYPE SYNTAX Unsigned32 (1..100000) UNITS "microseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or an external management entity. Changes take effect as soon as practical in the implementation. The size of a Beacon SP used for AP or PCP clustering." DEFVAL { 600 } ::= { dot11DMGOperationEntry 14 } dot11PNExhaustionThresholdLow OBJECT-TYPE SYNTAX INTEGER (0..4294967295) UNITS "packet number" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or an external management entity. Changes take effect as soon as practical in the implementation. Threshold used for indicating an imminent PN exhaustion. Threshold is a 48 bit integer. This field contains the least significant 32 bits of the threshold." DEFVAL { 4294967295 } ::= { dot11DMGOperationEntry 15 } dot11PNExhaustionThresholdHigh OBJECT-TYPE SYNTAX INTEGER (0..65535) UNITS "packet number" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or an external management entity. Changes take effect as soon as practical in the implementation. Threshold used for indicating an imminent PN exhaustion. Threshold is a 48 bit integer. This field contains the most significant 16 bits of the threshold." DEFVAL { 65535 } ::= { dot11DMGOperationEntry 16 } dot11MaxNumberOfClusteringMonitoringPeriods OBJECT-TYPE SYNTAX Unsigned32 (1..16) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or an external management entity. Changes take effect as soon as practical in the implementation. Number of clustering monitoring periods until determination of the loss of an S-AP or S-PCP." DEFVAL { 3 } ::= { dot11DMGOperationEntry 17 } 3124 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11DMGEcssPolicyDetailUpdateDurationMax OBJECT-TYPE SYNTAX Unsigned32 (10..30000) UNITS "TUs" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or an external management entity. Changes take effect as soon as practical in the implementation. Maximum duration between attempts by a member AP or member PCP in a centralized AP or PCP cluster to receive a DMG Beacon frame from the S-AP of the centralized AP or PCP cluster" DEFVAL { 1000 } ::= { dot11DMGOperationEntry 18 } dot11DMGEcssClusterReportDurationMin OBJECT-TYPE SYNTAX Unsigned32 (100..36000000) UNITS "TUs" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or an external management entity. Changes take effect as soon as practical in the implementation. Minimum duration between the transmission of interference reports by a member AP or member PCP in a centralized AP or PCP cluster to the S-AP of the centralized AP or PCP cluster" DEFVAL { 1000 } ::= { dot11DMGOperationEntry 19 } dot11DMGNavSync OBJECT-TYPE SYNTAX Unsigned32 (0..10000) UNITS "microseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or an external management entity. Changes take effect as soon as practical in the implementation. Delay to be used by a DMG STA prior to transmitting a Probe Request frame." DEFVAL { 0 } ::= { dot11DMGOperationEntry 20 } -- ******************************************************************* -- * End of dot11DMGOperation TABLE -- ******************************************************************* -- ******************************************************************* -- * dot11DMGCounters TABLE -- ******************************************************************* dot11DMGCountersTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11DMGCountersEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is a Table management object. The dot11DMGCountersTable Table" ::= { dot11mac 9 } 3125 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11DMGCountersEntry OBJECT-TYPE SYNTAX Dot11DMGCountersEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is an entry in the dot11DMGCountersTable Table. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX { ifIndex } ::= { dot11DMGCountersTable 1 } Dot11DMGCountersEntry ::= SEQUENCE { dot11RSNAStatsGCMPReplays Unsigned32, dot11RSNAStatsRobustMgmtGCMPReplays Unsigned32 } dot11RSNAStatsGCMPReplays OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME or an external management entity. Counter for the number of times an MPDU with the Type subfield equal to Data is discarded due to PN violation." DEFVAL { 0 } ::= { dot11DMGCountersEntry 1 } dot11RSNAStatsRobustMgmtGCMPReplays OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME or an external management entity. Counter for the number of times a Management frame is discarded due to PN violation." DEFVAL { 0 } ::= { dot11DMGCountersEntry 2 } -- ******************************************************************* -- * End of dot11DMGCounters TABLE -- ******************************************************************* -- ******************************************************************* -- * dot11BSSStatisticsTable TABLE -- ******************************************************************* dot11BSSStatisticsTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11BSSStatisticsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is a Table management object. The dot11BSSStatisticsTable Table contains objects related to BSS Statistics. It is present only in an AP." ::= { dot11mac 10 } dot11BSSStatisticsEntry OBJECT-TYPE SYNTAX Dot11BSSStatisticsEntry 3126 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is an entry in the dot11BSSStatisticsTable Table. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX { ifIndex } ::= { dot11BSSStatisticsTable 1 } Dot11BSSStatisticsEntry ::= SEQUENCE { dot11BSSLoadChannelUtilization Unsigned32, dot11BSSLoadAvailableAdmissionCapacity Unsigned32, dot11BSSLoadAssocAttemptCount Unsigned32, dot11BSSLoadAssocFailCount Unsigned32, dot11BSSLoadReassocAttemptCount Unsigned32, dot11BSSLoadReassocFailCount Unsigned32 } dot11BSSLoadChannelUtilization OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MLME. This object indicates the percentage of time, linearly scaled with 255 representing 100%, that the AP sensed the medium was busy, as indicated by either the physical or virtual carrier sense (CS) mechanism." REFERENCE "IEEE Std 802.11-2016, 9.4.2.28" DEFVAL { 0 } ::= { dot11BSSStatisticsEntry 1 } dot11BSSLoadAvailableAdmissionCapacity OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "32 microseconds/second" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MLME. This object indicates the remaining amount of medium time available via explicit admission control." REFERENCE "IEEE Std 802.11-2016, 9.4.2.28" DEFVAL { 0 } ::= { dot11BSSStatisticsEntry 2 } dot11BSSLoadAssocAttemptCount OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MLME. This object contains the count of the number of association procedures started at the AP. It reports the count of such events since the AP started the operation of its BSS (i.e., since the last MLME-START.request primitive)." DEFVAL { 0 } ::= { dot11BSSStatisticsEntry 3 } dot11BSSLoadAssocFailCount OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-only 3127 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STATUS current DESCRIPTION "This is a status variable. It is written by the MLME. This object contains the count of the number of unsuccessful association procedures at the AP (i.e., it is the number of association procedures started less those that completed successfully). It reports the count of such events since the AP started the operation of its BSS (i.e., since the last MLME-START.request primitive)." DEFVAL { 0 } ::= { dot11BSSStatisticsEntry 4 } dot11BSSLoadReassocAttemptCount OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MLME. This object contains the count of the number of reassociation procedures started at the AP. It reports the count of such events since the AP started the operation of its BSS (i.e., since the last MLME-START.request primitive)." DEFVAL { 0 } ::= { dot11BSSStatisticsEntry 5 } dot11BSSLoadReassocFailCount OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MLME. This object contains the count of the number of unsuccessful reassociation procedures at the AP (i.e., it is the number of reassociation procedures started less those that completed successfully). It reports the count of such events since the AP started the operation of its BSS (i.e., since the last MLME-START.request primitive)." DEFVAL { 0 } ::= { dot11BSSStatisticsEntry 6 } -- ********************************************************************** -- * PHY Attribute Templates -- ********************************************************************** -- ********************************************************************** -- * dot11PhyOperation TABLE -- ********************************************************************** dot11PhyOperationTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11PhyOperationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "PHY level attributes concerned with operation. Implemented as a table indexed on ifIndex to allow for multiple instantiations on an Agent." ::= { dot11phy 1 } dot11PhyOperationEntry OBJECT-TYPE SYNTAX Dot11PhyOperationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11PhyOperation Table. 3128 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX { ifIndex } ::= { dot11PhyOperationTable 1 } Dot11PhyOperationEntry ::= SEQUENCE { dot11PHYType INTEGER, dot11CurrentRegDomain Unsigned32, dot11TempType INTEGER } dot11PHYType OBJECT-TYPE SYNTAX INTEGER { dsss(2), ofdm(4), hrdsss(5), erp(6), ht(7), dmg(8), vht(9), tvht(10) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the PHY. This is an 8-bit integer value that identifies the supported PHY type. Currently defined values and their corresponding PHY types are: DSSS 2.4 GHz = 2, OFDM = 4, HRDSSS = 5, ERP = 6, HT = 7, DMG = 8, VHT = 9, TVHT = 10" ::= { dot11PhyOperationEntry 1 } dot11CurrentRegDomain OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME when the device is initialized. The current regulatory domain this instance of the PHY is supporting. This object corresponds to one of the RegDomains listed in dot11RegDomainsSupported." ::= { dot11PhyOperationEntry 2 } dot11TempType OBJECT-TYPE SYNTAX INTEGER { tempType1(1), tempType2(2) } MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The use of dot11TempType is deprecated because no associated behavior is described in IEEE Std 802.11-2016, and this entity may be removed in a later revision of the standard. This is a status variable. It is written by the PHY. There are different operating temperature requirements dependent on the anticipated environmental conditions. This attribute describes the current PHY's operating temperature range capability. Currently defined values and their corresponding temperature ranges are: 3129 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Type 1 = X'01'-Commercial range of 0 to 40 degrees C, Type 2 = X'02'-Industrial range of -30 to 70 degrees C." ::= { dot11PhyOperationEntry 3 } -- ********************************************************************** -- * End of dot11PhyOperation TABLE -- ********************************************************************** -- ********************************************************************** -- * dot11PhyAntenna TABLE -- ********************************************************************** dot11PhyAntennaTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11PhyAntennaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Group of attributes for PhyAntenna. Implemented as a table indexed on ifIndex to allow for multiple instances on an agent." ::= { dot11phy 2} dot11PhyAntennaEntry OBJECT-TYPE SYNTAX Dot11PhyAntennaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11PhyAntenna Table. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX { ifIndex } ::= { dot11PhyAntennaTable 1 } Dot11PhyAntennaEntry ::= SEQUENCE { dot11CurrentTxAntenna Unsigned32, dot11DiversitySupportImplemented INTEGER, dot11CurrentRxAntenna Unsigned32, dot11AntennaSelectionOptionImplemented TruthValue, dot11TransmitExplicitCSIFeedbackASOptionImplemented TruthValue, dot11TransmitIndicesFeedbackASOptionImplemented TruthValue, dot11ExplicitCSIFeedbackASOptionImplemented TruthValue, dot11TransmitIndicesComputationASOptionImplemented TruthValue, dot11ReceiveAntennaSelectionOptionImplemented TruthValue, dot11TransmitSoundingPPDUOptionImplemented TruthValue, dot11NumberOfActiveRxAntennas Unsigned32 } dot11CurrentTxAntenna OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. The current antenna being used to transmit. This value is one of the values appearing in dot11TxAntennaImplemented. This may be used by a management agent to control which antenna is used for transmission." ::= { dot11PhyAntennaEntry 1 } dot11DiversitySupportImplemented OBJECT-TYPE SYNTAX INTEGER { fixedlist(1), notsupported(2), dynamic(3) } 3130 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This implementation's support for diversity, encoded as: X'01'-diversity is available and is performed over the fixed list of antennas defined in dot11DiversitySelectionRxImplemented. X'02'-diversity is not supported. X'03'-diversity is supported and control of diversity is also available, in which case the attribute dot11DiversitySelectionRxImplemented can be dynamically modified by the LME." ::= { dot11PhyAntennaEntry 2 } dot11CurrentRxAntenna OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the PHY. The current antenna being used to receive, if the dot11 DiversitySupport indicates that diversity is not supported. The selected antenna is one of the antennae marked for receive in the dot11AntennasListTable." ::= { dot11PhyAntennaEntry 3 } dot11AntennaSelectionOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that ASEL is supported by the station implementation." DEFVAL { false } ::= { dot11PhyAntennaEntry 4 } dot11TransmitExplicitCSIFeedbackASOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the transmit ASEL based on explicit CSI feedback is supported by the station implementation." DEFVAL { false } ::= { dot11PhyAntennaEntry 5 } dot11TransmitIndicesFeedbackASOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. 3131 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This attribute, when true, indicates that the transmit ASEL based on antenna indices feedback is supported by the station implementation." DEFVAL { false } ::= { dot11PhyAntennaEntry 6 } dot11ExplicitCSIFeedbackASOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the computation of CSI and feedback the results to support the peer to do ASEL is supported by the station implementation." DEFVAL { false } ::= { dot11PhyAntennaEntry 7 } dot11TransmitIndicesComputationASOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the transmit ASEL based on antenna indices selection computation and feedback the results to support the peer to do ASEL is supported by the station implementation." DEFVAL { false } ::= { dot11PhyAntennaEntry 8 } dot11ReceiveAntennaSelectionOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the receive ASEL is supported by the station implementation." DEFVAL { false } ::= { dot11PhyAntennaEntry 9 } dot11TransmitSoundingPPDUOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the transmission of sounding PPDUs is supported by the station implementation." DEFVAL { false } ::= { dot11PhyAntennaEntry 10 } dot11NumberOfActiveRxAntennas OBJECT-TYPE SYNTAX Unsigned32 (1..4) MAX-ACCESS read-only STATUS current 3132 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DESCRIPTION "This is a status variable. It is written by the PHY. This attribute indicates the number of current active antennas being used to receive." ::= { dot11PhyAntennaEntry 11 } -- ********************************************************************** -- * End of dot11PhyAntenna TABLE -- ********************************************************************** -- ********************************************************************** -- * dot11PhyTxPower TABLE -- ********************************************************************** dot11PhyTxPowerTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11PhyTxPowerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Group of attributes for dot11PhyTxPowerTable. Implemented as a table indexed on STA ID to allow for multiple instances on an Agent." ::= { dot11phy 3} dot11PhyTxPowerEntry OBJECT-TYPE SYNTAX Dot11PhyTxPowerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11PhyTxPower Table. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX { ifIndex } ::= { dot11PhyTxPowerTable 1 } Dot11PhyTxPowerEntry ::= SEQUENCE { dot11NumberSupportedPowerLevelsImplemented Unsigned32, dot11TxPowerLevel1 Unsigned32, dot11TxPowerLevel2 Unsigned32, dot11TxPowerLevel3 Unsigned32, dot11TxPowerLevel4 Unsigned32, dot11TxPowerLevel5 Unsigned32, dot11TxPowerLevel6 Unsigned32, dot11TxPowerLevel7 Unsigned32, dot11TxPowerLevel8 Unsigned32, dot11CurrentTxPowerLevel Unsigned32, dot11TxPowerLevelExtended OCTET STRING, dot11CurrentTxPowerLevelExtended Unsigned32 } dot11NumberSupportedPowerLevelsImplemented OBJECT-TYPE SYNTAX Unsigned32 (1..8) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. The number of power levels supported by the PHY. This attribute can have a value of 1 to 8." ::= { dot11PhyTxPowerEntry 1 } 3133 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11TxPowerLevel1 OBJECT-TYPE SYNTAX Unsigned32 (0..10000) UNITS "mW" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. The transmit output power for LEVEL1. This is also the default power level." ::= { dot11PhyTxPowerEntry 2 } dot11TxPowerLevel2 OBJECT-TYPE SYNTAX Unsigned32 (0..10000) UNITS "mW" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. The transmit output power for LEVEL2." ::= { dot11PhyTxPowerEntry 3 } dot11TxPowerLevel3 OBJECT-TYPE SYNTAX Unsigned32 (0..10000) UNITS "mW" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. The transmit output power for LEVEL3." ::= { dot11PhyTxPowerEntry 4 } dot11TxPowerLevel4 OBJECT-TYPE SYNTAX Unsigned32 (0..10000) UNITS "mW" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. The transmit output power for LEVEL4." ::= { dot11PhyTxPowerEntry 5 } dot11TxPowerLevel5 OBJECT-TYPE SYNTAX Unsigned32 (0..10000) UNITS "mW" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. The transmit output power for LEVEL5." ::= { dot11PhyTxPowerEntry 6 } dot11TxPowerLevel6 OBJECT-TYPE SYNTAX Unsigned32 (0..10000) UNITS "mW" 3134 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. The transmit output power for LEVEL6." ::= { dot11PhyTxPowerEntry 7 } dot11TxPowerLevel7 OBJECT-TYPE SYNTAX Unsigned32 (0..10000) UNITS "mW" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. The transmit output power for LEVEL7." ::= { dot11PhyTxPowerEntry 8 } dot11TxPowerLevel8 OBJECT-TYPE SYNTAX Unsigned32 (0..10000) UNITS "mW" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. The transmit output power for LEVEL8." ::= { dot11PhyTxPowerEntry 9 } dot11CurrentTxPowerLevel OBJECT-TYPE SYNTAX Unsigned32 (1..8) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the PHY. Set to min(N,8) where N is an index into dot11TxPowerLevel or dot11TxPowerLevelExtended and identifies the transmit power level currently being used to transmit data. Some PHYs also use this value to determine the receiver sensitivity requirements for CCA." ::= { dot11PhyTxPowerEntry 10 } dot11TxPowerLevelExtended OBJECT-TYPE SYNTAX OCTET STRING (SIZE(2..256)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. It has an even number of octets. It is organized as a variable length list of octet pairs, where each octet pair defines a big-endian 16-bit integer. The N-th integer represents the N-th EIRP, in units of 250 microWatts. The values dot11TxPowerLevel1 to dot11TxPowerLevel inclusive, in order, correspond to the first to min(8, dot11NumberSupportedPowerLevelsImplemented)-th integers in this variable. Where dot11TxPowerLevel1 to dot11TxPowerLevel inclusive contain EIRP 3135 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications values then, when converted from units of milliWatts to 250 microWatts, they shall appear in order in positions 1 to min(8, dot11NumberSupportedPowerLevelsImplemented) in this variable." ::= { dot11PhyTxPowerEntry 11 } dot11CurrentTxPowerLevelExtended OBJECT-TYPE SYNTAX Unsigned32 (1..128) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the PHY. Contains an index into the integer array in dot11TxPowerLevelExtended (where the value 1 indicates the first value in dot11TxPowerLevelExtended, and so on) that identifies the transmit output power currently being used to transmit data." ::= { dot11PhyTxPowerEntry 12 } -- ********************************************************************** -- * End of dot11PhyTxPower TABLE -- ********************************************************************** -- ********************************************************************** -- * dot11PhyDSSSEntry TABLE -- ********************************************************************** dot11PhyDSSSTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11PhyDSSSEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry of attributes for dot11PhyDSSSEntry. Implemented as a table indexed on ifIndex to allow for multiple instances on an Agent." ::= { dot11phy 5 } dot11PhyDSSSEntry OBJECT-TYPE SYNTAX Dot11PhyDSSSEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11PhyDSSSEntry Table. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX { ifIndex } ::= { dot11PhyDSSSTable 1 } Dot11PhyDSSSEntry ::= SEQUENCE { dot11CurrentChannel Unsigned32, dot11CCAModeSupported Unsigned32, dot11CurrentCCAMode INTEGER, dot11EDThreshold Integer32 } dot11CurrentChannel OBJECT-TYPE SYNTAX Unsigned32 (1..14) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the PHY. The current operating frequency channel of the DSSS PHY. Valid channel 3136 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications numbers are as defined in 15.4.4.3" ::= { dot11PhyDSSSEntry 1 } dot11CCAModeSupported OBJECT-TYPE SYNTAX Unsigned32 (1..7) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. dot11CCAModeSupported is a bit-significant value, representing all of the CCA modes supported by the DSSS PHY in addition to detection of energy above -62 dBm (which is always supported). Valid values are: energy detect only (edonly) = 01, carrier sense only (csonly) = 02, carrier sense and energy detect (csanded)= 04 or the logical sum of any of these values." ::= { dot11PhyDSSSEntry 2 } dot11CurrentCCAMode OBJECT-TYPE SYNTAX INTEGER { edonly(1), csonly(2), csanded(4), cswithtimer(8), hrcsanded(16) } MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. The current CCA method in operation for a DSSS or HR/DSSS PHY, in addition to detection of energy above -62 dBm (which is always supported). Valid values are: energy detect only (edonly) = 01, carrier sense only (csonly) = 02, carrier sense and energy detect (csanded)= 04 carrier sense with timer (cswithtimer)= 08 high rate carrier sense and energy detect (hrcsanded)=16, subject to the support indicated in dot11CCAModeSupported (for the DSSS PHY) or dot11HRCCAModeImplemented (for the HR/DSSS PHY)." ::= { dot11PhyDSSSEntry 3 } dot11EDThreshold OBJECT-TYPE SYNTAX Integer32(-100..-70) UNITS "dBm" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. The current energy detect threshold being used by the DSSS PHY or HR/DSSS PHY." ::= { dot11PhyDSSSEntry 4 } -- ********************************************************************** -- * End of dot11PhyDSSSEntry TABLE -- ********************************************************************** -- ********************************************************************** 3137 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications -- * dot11RegDomainsSupported TABLE -- ********************************************************************** dot11RegDomainsSupportedTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11RegDomainsSupportedEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "Superceded by dot11OperatingClassesTable. There are different operational requirements dependent on the regulatory domain. This attribute list describes the regulatory domains the PHY supportS in this implementation. Currently defined values and their corresponding Regulatory Domains are: FCC (USA) = X'10', DOC (Canada) = X'20', ETSI (most of Europe) = X'30', Spain = X'31', France = X'32', Japan = X'40', China = X'50', Other = X'00' " ::= { dot11phy 7} dot11RegDomainsSupportedEntry OBJECT-TYPE SYNTAX Dot11RegDomainsSupportedEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "Superceded by dot11OperatingClassesTable. An entry in the dot11RegDomainsSupportedTable. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX { ifIndex, dot11RegDomainsSupportedIndex } ::= { dot11RegDomainsSupportedTable 1 } Dot11RegDomainsSupportedEntry ::= SEQUENCE { dot11RegDomainsSupportedIndex Unsigned32, dot11RegDomainsImplementedValue INTEGER } dot11RegDomainsSupportedIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "The auxiliary variable used to identify instances of the columnar objects in the RegDomainsSupport Table." ::= { dot11RegDomainsSupportedEntry 1 } dot11RegDomainsImplementedValue OBJECT-TYPE SYNTAX INTEGER { other (0), fcc(16), doc(32), etsi(48), spain (49), france(50), japan (64)} MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. There are different operational requirements dependent on the regulatory domain. This attribute list describes the regulatory domains the PHY 3138 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications supports in this implementation. Currently defined values and their corresponding Regulatory Domains are: FCC (USA) = X'10', DOC (Canada) = X'20', ETSI (most of Europe) = X'30', Spain = X'31', France = X'32', Japan = X'40', China = X'50' " ::= { dot11RegDomainsSupportedEntry 2 } -- ********************************************************************** -- * End of dot11RegDomainsSupported TABLE -- ********************************************************************** -- ********************************************************************** -- * dot11AntennasList TABLE -- ********************************************************************** dot11AntennasListTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11AntennasListEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table represents the list of antennae. An antenna can be marked to be capable of transmitting, receiving, and/or for participation in receive diversity. Each entry in this table represents a single antenna with its properties. The maximum number of antennae that can be contained in this table is 255." ::= { dot11phy 8 } dot11AntennasListEntry OBJECT-TYPE SYNTAX Dot11AntennasListEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11AntennasListTable, representing the properties of a single antenna. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX { ifIndex, dot11AntennaListIndex } ::= { dot11AntennasListTable 1 } Dot11AntennasListEntry ::= SEQUENCE { dot11AntennaListIndex Unsigned32, dot11TxAntennaImplemented TruthValue, dot11RxAntennaImplemented TruthValue, dot11DiversitySelectionRxImplemented TruthValue } dot11AntennaListIndex OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The unique index of an antenna which is used to identify the columnar objects in the dot11AntennasList Table." ::= { dot11AntennasListEntry 1 } dot11TxAntennaImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. 3139 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications When true, this object indicates that the antenna represented by dot11AntennaIndex can be used as a transmit antenna." ::= { dot11AntennasListEntry 2 } dot11RxAntennaImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. When true, this object indicates that the antenna represented by the dot11AntennaIndex can be used as a receive antenna." ::= { dot11AntennasListEntry 3 } dot11DiversitySelectionRxImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. When true, this object indicates that the antenna represented by dot11AntennaIndex can be used for receive diversity. This object is true only if the antenna can be used as a receive antenna, as indicated by dot11RxAntennaImplemented." ::= { dot11AntennasListEntry 4 } -- ********************************************************************** -- * End of dot11AntennasList TABLE -- ********************************************************************** -- ********************************************************************** -- * dot11SupportedDataRatesTx TABLE -- ********************************************************************** dot11SupportedDataRatesTxTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11SupportedDataRatesTxEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Transmit bit rates supported by the PHY, represented by a count from X'02-X'7f, corresponding to data rates in increments of 500 kb/s from 1 Mb/s to 63.5 Mb/s subject to limitations of each individual PHY." ::= { dot11phy 9 } dot11SupportedDataRatesTxEntry OBJECT-TYPE SYNTAX Dot11SupportedDataRatesTxEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An Entry (conceptual row) in the dot11SupportedDataRatesTx Table. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX { ifIndex, dot11SupportedDataRatesTxIndex } ::= { dot11SupportedDataRatesTxTable 1 } Dot11SupportedDataRatesTxEntry ::= SEQUENCE { dot11SupportedDataRatesTxIndex Unsigned32, dot11ImplementedDataRatesTxValue Unsigned32 } 3140 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11SupportedDataRatesTxIndex OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index object that identifies which data rate to access. Range is 1..255." ::= { dot11SupportedDataRatesTxEntry 1 } dot11ImplementedDataRatesTxValue OBJECT-TYPE SYNTAX Unsigned32 (2..127) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. The Transmit bit rates supported by the PHY, represented by a count from X'02-X'7f, corresponding to data rates in increments of 500 kb/s from 1 Mb/s to 63.5 Mb/s subject to limitations of each individual PHY." ::= { dot11SupportedDataRatesTxEntry 2 } -- ********************************************************************** -- * End of dot11SupportedDataRatesTx TABLE -- ********************************************************************** -- ********************************************************************** -- * dot11SupportedDataRatesRx TABLE -- ********************************************************************** dot11SupportedDataRatesRxTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11SupportedDataRatesRxEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The receive bit rates supported by the PHY, represented by a count from X'002-X'7f, corresponding to data rates in increments of 500 kb/s from 1 Mb/s to 63.5 Mb/s." ::= { dot11phy 10 } dot11SupportedDataRatesRxEntry OBJECT-TYPE SYNTAX Dot11SupportedDataRatesRxEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An Entry (conceptual row) in the dot11SupportedDataRatesRx Table. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX { ifIndex, dot11SupportedDataRatesRxIndex } ::= { dot11SupportedDataRatesRxTable 1 } Dot11SupportedDataRatesRxEntry ::= SEQUENCE { dot11SupportedDataRatesRxIndex Unsigned32, dot11ImplementedDataRatesRxValue Unsigned32 } dot11SupportedDataRatesRxIndex OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index object that identifies which data rate to access. Range is 1..255." ::= { dot11SupportedDataRatesRxEntry 1 } 3141 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11ImplementedDataRatesRxValue OBJECT-TYPE SYNTAX Unsigned32 (2..127) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. The receive bit rates supported by the PHY, represented by a count from X'02-X'7f, corresponding to data rates in increments of 500 kb/s from 1 Mb/s to 63.5 Mb/s." ::= { dot11SupportedDataRatesRxEntry 2 } -- ********************************************************************** -- * End of dot11SupportedDataRatesRx TABLE -- ********************************************************************** -- ********************************************************************** -- * dot11PhyOFDM TABLE -- ********************************************************************** dot11PhyOFDMTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11PhyOFDMEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Group of attributes for dot11PhyOFDMTable. Implemented as a table indexed on ifindex to allow for multiple instances on an Agent." ::= { dot11phy 11 } dot11PhyOFDMEntry OBJECT-TYPE SYNTAX Dot11PhyOFDMEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11PhyOFDM Table. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX { ifIndex } ::= { dot11PhyOFDMTable 1 } Dot11PhyOFDMEntry ::= SEQUENCE { dot11CurrentFrequency Unsigned32, dot11TIThreshold Integer32, dot11FrequencyBandsImplemented Unsigned32, dot11ChannelStartingFactor Unsigned32, dot11FiveMHzOperationImplemented TruthValue, dot11TenMHzOperationImplemented TruthValue, dot11TwentyMHzOperationImplemented TruthValue, dot11PhyOFDMChannelWidth INTEGER, dot11OFDMCCAEDImplemented TruthValue, dot11OFDMCCAEDRequired TruthValue, dot11OFDMEDThreshold Unsigned32, dot11STATransmitPowerClass INTEGER, dot11ACRType INTEGER } dot11CurrentFrequency OBJECT-TYPE SYNTAX Unsigned32 (0..200) MAX-ACCESS read-only STATUS current DESCRIPTION 3142 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications "This is a status variable. It is written by the PHY. The number of the current operating frequency channel of the OFDM PHY." ::= { dot11PhyOFDMEntry 1 } dot11TIThreshold OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS deprecated DESCRIPTION "Superseded by PHY-specific or regulatory CCA energy detect limits. The Threshold being used to detect a busy medium (frequency). CCA reports a busy medium upon detecting the RSSI above this threshold." ::= { dot11PhyOFDMEntry 2 } dot11FrequencyBandsImplemented OBJECT-TYPE SYNTAX Unsigned32 (1..127) MAX-ACCESS read-only STATUS deprecated DESCRIPTION "Superseded by subband-specific supported operating classes. This is a capability variable. Its value is determined by device capabilities. The capability of the OFDM PHY implementation to operate in the 4.9 GHz and 5 GHz bands. Coded as an integer value with bit 0 LSB as follows: bit 0 .. capable of operating in the 5.15-5.25 GHz band bit 1 .. capable of operating in the 5.25-5.35 GHz band bit 2 .. capable of operating in the 5.725-5.825 GHz band bit 3 .. capable of operating in the 5.47-5.725 GHz band bit 4 .. capable of operating in the lower Japanese (5.15-5.25 GHz) band bit 5 .. capable of operating in the 5.03-5.091 GHz band bit 6 .. capable of operating in the 4.94-4.99 GHz band For example, for an implementation capable of operating in the 5.15-5.35 GHz bands this attribute would take the value 3." ::= { dot11PhyOFDMEntry 3 } dot11ChannelStartingFactor OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. The base factor from which channel center frequencies are calculated. This number is multiplied by 500 kHz to form the base frequency to be added to the channel number x 5 MHz." DEFVAL { 10000 } ::= { dot11PhyOFDMEntry 4 } dot11FiveMHzOperationImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the 5 MHz Operation is implemented." 3143 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DEFVAL { false } ::= { dot11PhyOFDMEntry 5 } dot11TenMHzOperationImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the 10 MHz Operation is implemented." DEFVAL { false } ::= { dot11PhyOFDMEntry 6 } dot11TwentyMHzOperationImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the 20 MHz Operation is implemented." DEFVAL { true } ::= { dot11PhyOFDMEntry 7 } dot11PhyOFDMChannelWidth OBJECT-TYPE SYNTAX INTEGER { width5MHz(1), width10MHz(2), width20MHz(3)} MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME. Changes take effect as soon as practical in the implementation. This is an 8-bit integer value that identifies the OFDM PHY channel width. Currently defined values and their corresponding Channel widths are: 5 MHz = 01, 10 MHz = 02, 20 MHz = 03" ::= { dot11PhyOFDMEntry 8 } dot11OFDMCCAEDImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates that the OFDM PHY is capable of CCA-Energy Detect." ::= { dot11PhyOFDMEntry 9 } dot11OFDMCCAEDRequired OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME when the device is initialized for operation in a band defined by an Operating Class. 3144 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This attribute indicates that the PHY CCA-Energy Detect functionality is enabled." ::= { dot11PhyOFDMEntry 10 } dot11OFDMEDThreshold OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written the SME when the device is initialized for operation in a band defined by an Operating Class, or written by an external management entity. Changes take effect as soon as practical in the implementation. The current Energy Detect Threshold being used by the OFDM PHY." ::= { dot11PhyOFDMEntry 11 } dot11STATransmitPowerClass OBJECT-TYPE SYNTAX INTEGER { classA(1), classB(2), classC(3), classD(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "The station transmit power class: Class A=1, Class B=2, Class C=3, Class D=4 (as defined in D.2.2)." DEFVAL { 1 } ::= { dot11PhyOFDMEntry 12 } dot11ACRType OBJECT-TYPE SYNTAX INTEGER { standard(1), enhanced(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME. The Adjacent and Nonadjacent Channel Rejection performance: when this attribute = 1 the levels in Table 17-18 apply; when this attribute = 2 the levels in Table 17-19 apply." DEFVAL { 1 } ::= { dot11PhyOFDMEntry 13 } -- ********************************************************************** -- * End of dot11PhyOFDM TABLE -- ********************************************************************** -- ********************************************************************** -- * dot11PhyHRDSSSEntry TABLE -- ********************************************************************** dot11PhyHRDSSSTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11PhyHRDSSSEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry of attributes for dot11PhyHRDSSSEntry. Implemented as a table indexed on ifIndex to allow for multiple instances on an Agent." ::= { dot11phy 12 } dot11PhyHRDSSSEntry OBJECT-TYPE SYNTAX Dot11PhyHRDSSSEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION 3145 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications "An entry in the dot11PhyHRDSSSEntry Table. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX { ifIndex } ::= { dot11PhyHRDSSSTable 1 } Dot11PhyHRDSSSEntry ::= SEQUENCE { dot11ShortPreambleOptionImplemented TruthValue, dot11HRCCAModeImplemented Unsigned32 } dot11ShortPreambleOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the short preamble option as defined in 16.2.2.3 is implemented." DEFVAL { false } ::= { dot11PhyHRDSSSEntry 1 } dot11HRCCAModeImplemented OBJECT-TYPE SYNTAX Unsigned32 (1..31) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. dot11HRCCAModeImplemented is a bit-significant value, representing all of the CCA modes supported by the HR/DSSS PHY, in addition to detection of energy above -62 dBm (which is always supported). Valid values are: energy detect only (edonly) = 01, carrier sense with timer (cswithtimer)= 08, high rate carrier sense and energy detect (hrcsanded)= 16 or the logical sum of any of these values." ::= { dot11PhyHRDSSSEntry 5 } -- ********************************************************************** -- * End of dot11PhyHRDSSSEntry TABLE -- ********************************************************************** -- ********************************************************************** -- * dot11HoppingPattern TABLE -- ********************************************************************** dot11HoppingPatternTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11HoppingPatternEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "This attribute is deprecated because the frequency hopping PHY is no longer present in IEEE Std 802.11-2016. The (conceptual) table of attributes necessary for a frequency hopping implementation to be able to create the hopping sequences necessary to operate in the subband for the associated domain country string." ::= { dot11phy 13 } 3146 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11HoppingPatternEntry OBJECT-TYPE SYNTAX Dot11HoppingPatternEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "This attribute is deprecated because the frequency hopping PHY is no longer present in IEEE Std 802.11-2016. An entry (conceptual row) in the Hopping Pattern Table that indicates the random hopping sequence to be followed. IfIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB are indexed by ifIndex." INDEX { ifIndex, dot11HoppingPatternIndex } ::= { dot11HoppingPatternTable 1 } Dot11HoppingPatternEntry ::= SEQUENCE { dot11HoppingPatternIndex Unsigned32, dot11RandomTableFieldNumber Unsigned32 } dot11HoppingPatternIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "This attribute is deprecated because the frequency hopping PHY is no longer present in IEEE Std 802.11-2016. The auxiliary variable used to identify instances of the columnar objects in the Hopping Pattern Table." ::= { dot11HoppingPatternEntry 1 } dot11RandomTableFieldNumber OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This attribute is deprecated because the frequency hopping PHY is no longer present in IEEE Std 802.11-2016. This is a control variable. It is written by the SME when the device is initialized. This attribute indicates the value of the starting channel number in the hopping sequence of the subband for the associated domain country string." DEFVAL { 0 } ::= { dot11HoppingPatternEntry 2 } -- ********************************************************************** -- * End of dot11HoppingPattern TABLE -- ********************************************************************** -- ********************************************************************** -- * dot11PhyERP TABLE -- ********************************************************************** dot11PhyERPTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11PhyERPEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry of attributes for dot11PhyERPEntry. Implemented as a table indexed on ifIndex to allow for multiple instances on an Agent." 3147 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ::= { dot11phy 14 } dot11PhyERPEntry OBJECT-TYPE SYNTAX Dot11PhyERPEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11PhyERPEntry Table. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX {ifIndex} ::= { dot11PhyERPTable 1 } Dot11PhyERPEntry ::= SEQUENCE { dot11ShortSlotTimeOptionImplemented TruthValue, dot11ShortSlotTimeOptionActivated TruthValue } dot11ShortSlotTimeOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the Short Slot Time option as defined in 9.4.1.4 is implemented." DEFVAL { false } ::= { dot11PhyERPEntry 5} dot11ShortSlotTimeOptionActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that the Short Slot Time option as defined in 9.4.1.4 is enabled." DEFVAL { false } ::= { dot11PhyERPEntry 6 } -- ********************************************************************** -- * End of dot11PhyERP TABLE -- ********************************************************************** -- ********************************************************************** -- * dot11 Phy HT TABLE -- ********************************************************************** dot11PhyHTTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11PhyHTEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry of attributes for dot11PhyHTTable. Implemented as a table indexed on ifIndex to allow for multiple instances on an Agent." ::= { dot11phy 15 } dot11PhyHTEntry OBJECT-TYPE SYNTAX Dot11PhyHTEntry 3148 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11PhyHTEntry Table. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX {ifIndex} ::= { dot11PhyHTTable 1 } Dot11PhyHTEntry ::= SEQUENCE { dot11FortyMHzOperationImplemented TruthValue, dot11FortyMHzOperationActivated TruthValue, dot11CurrentPrimaryChannel Unsigned32, dot11CurrentSecondaryChannel Unsigned32, dot11NumberOfSpatialStreamsImplemented Unsigned32, dot11NumberOfSpatialStreamsActivated Unsigned32, dot11HTGreenfieldOptionImplemented TruthValue, dot11HTGreenfieldOptionActivated TruthValue, dot11ShortGIOptionInTwentyImplemented TruthValue, dot11ShortGIOptionInTwentyActivated TruthValue, dot11ShortGIOptionInFortyImplemented TruthValue, dot11ShortGIOptionInFortyActivated TruthValue, dot11LDPCCodingOptionImplemented TruthValue, dot11LDPCCodingOptionActivated TruthValue, dot11TxSTBCOptionImplemented TruthValue, dot11TxSTBCOptionActivated TruthValue, dot11RxSTBCOptionImplemented TruthValue, dot11RxSTBCOptionActivated TruthValue, dot11BeamFormingOptionImplemented TruthValue, dot11BeamFormingOptionActivated TruthValue, dot11HighestSupportedDataRate Unsigned32, dot11TxMCSSetDefined TruthValue, dot11TxRxMCSSetNotEqual TruthValue, dot11TxMaximumNumberSpatialStreamsSupported Unsigned32, dot11TxUnequalModulationSupported TruthValue } dot11FortyMHzOperationImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the 40 MHz Operation is implemented." DEFVAL { false } ::= { dot11PhyHTEntry 1 } dot11FortyMHzOperationActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that the 40 MHz Operation is enabled." DEFVAL { false } ::= { dot11PhyHTEntry 2 } 3149 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11CurrentPrimaryChannel OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the PHY. This attribute indicates the operating channel. If 20/40 MHz BSS is currently in use then this attribute indicates the primary channel." ::= { dot11PhyHTEntry 3 } dot11CurrentSecondaryChannel OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the PHY. This attribute indicates the channel number of the secondary channel. If 20/40 MHz BSS is not currently in use, this attribute value shall be 0." ::= { dot11PhyHTEntry 4 } dot11NumberOfSpatialStreamsImplemented OBJECT-TYPE SYNTAX Unsigned32 (1..8) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates the maximum number of spatial streams imple- mented." DEFVAL { 2 } ::= { dot11PhyHTEntry 5 } dot11NumberOfSpatialStreamsActivated OBJECT-TYPE SYNTAX Unsigned32 (1..8) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute indicates the maximum number of spatial streams enabled." DEFVAL { 2 } ::= { dot11PhyHTEntry 6 } dot11HTGreenfieldOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the HT-greenfield option is implemented." DEFVAL { false } ::= { dot11PhyHTEntry 7 } dot11HTGreenfieldOptionActivated OBJECT-TYPE 3150 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that the HT-greenfield option is enabled." DEFVAL { false } ::= { dot11PhyHTEntry 8 } dot11ShortGIOptionInTwentyImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the Short Guard option is implemented for 20 MHz operation." DEFVAL { false } ::= { dot11PhyHTEntry 9 } dot11ShortGIOptionInTwentyActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that the Short Guard option is enabled for 20 MHz operation." DEFVAL { false } ::= { dot11PhyHTEntry 10 } dot11ShortGIOptionInFortyImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the Short Guard option is implemented for 40 MHz operation." DEFVAL { false } ::= { dot11PhyHTEntry 11 } dot11ShortGIOptionInFortyActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that the Short Guard option is enabled for 40 MHz operation." 3151 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DEFVAL { false } ::= { dot11PhyHTEntry 12 } dot11LDPCCodingOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the LDPC coding option is implemented." DEFVAL { false } ::= { dot11PhyHTEntry 13 } dot11LDPCCodingOptionActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that the LDPC coding option is enabled." DEFVAL { false } ::= { dot11PhyHTEntry 14 } dot11TxSTBCOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the entity is capable of transmitting frames using STBC option." DEFVAL { false } ::= { dot11PhyHTEntry 15 } dot11TxSTBCOptionActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that the entity's capability of transmitting frames using STBC option is enabled." DEFVAL { false } ::= { dot11PhyHTEntry 16 } dot11RxSTBCOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. 3152 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This attribute, when true, indicates that the entity is capable of receiving frames that are sent using the STBC." DEFVAL { false } ::= { dot11PhyHTEntry 17 } dot11RxSTBCOptionActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that the entity's capability of receiving frames that are sent using the STBC is enabled." DEFVAL { false } ::= { dot11PhyHTEntry 18 } dot11BeamFormingOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the beamforming option is implemented." DEFVAL { false } ::= { dot11PhyHTEntry 19 } dot11BeamFormingOptionActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that the beamforming option is enabled." DEFVAL { false } ::= { dot11PhyHTEntry 20 } dot11HighestSupportedDataRate OBJECT-TYPE SYNTAX Unsigned32 (0..600) UNITS "Mb/s" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute shall specify the Highest Data Rate at which the station may receive data." DEFVAL { 0 } ::= { dot11PhyHTEntry 21 } dot11TxMCSSetDefined OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write 3153 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that the Tx MCS set is defined." DEFVAL { false } ::= { dot11PhyHTEntry 22 } dot11TxRxMCSSetNotEqual OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the PHY. This attribute, when true, indicates that the supported Tx and Rx MCS sets are not equal." DEFVAL { false } ::= { dot11PhyHTEntry 23 } dot11TxMaximumNumberSpatialStreamsSupported OBJECT-TYPE SYNTAX Unsigned32 (0..3) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates the Tx maximum number of spatial streams sup- ported." DEFVAL { 0 } ::= { dot11PhyHTEntry 24 } dot11TxUnequalModulationSupported OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that Tx UEQM is supported." DEFVAL { false } ::= { dot11PhyHTEntry 25 } -- ********************************************************************** -- * End of dot11 PHY HT TABLE -- ********************************************************************** -- ********************************************************************** -- * dot11 Supported MCS Tx TABLE -- ********************************************************************** dot11SupportedMCSTxTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11SupportedMCSTxEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "he Transmit MCS supported by the PHY, represented by a count from 1 to 127, subject to limitations of each individual PHY." ::= { dot11phy 16 } 3154 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11SupportedMCSTxEntry OBJECT-TYPE SYNTAX Dot11SupportedMCSTxEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An Entry (conceptual row) in the dot11SupportedMCSTx Table. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX { ifIndex, dot11SupportedMCSTxIndex } ::= { dot11SupportedMCSTxTable 1 } Dot11SupportedMCSTxEntry ::= SEQUENCE { dot11SupportedMCSTxIndex Unsigned32, dot11SupportedMCSTxValue Unsigned32 } dot11SupportedMCSTxIndex OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index object that identifies which MCS to access. Range is 1..255." ::= { dot11SupportedMCSTxEntry 1 } dot11SupportedMCSTxValue OBJECT-TYPE SYNTAX Unsigned32 (1..127) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. The Transmit MCS supported by the PHY, represented by a count from 1 to 127, subject to limitations of each individual PHY." ::= { dot11SupportedMCSTxEntry 2 } -- ********************************************************************** -- * End of dot11 Supported MCS Tx TABLE -- ********************************************************************** -- ********************************************************************** -- * dot11 Supported MCS Rx TABLE -- ********************************************************************** dot11SupportedMCSRxTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11SupportedMCSRxEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The receive MCS supported by the PHY, represented by a count from 1 to 127, subject to limitations of each individual PHY." ::= { dot11phy 17 } dot11SupportedMCSRxEntry OBJECT-TYPE SYNTAX Dot11SupportedMCSRxEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An Entry (conceptual row) in the dot11SupportedMCSRx Table. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX { ifIndex, dot11SupportedMCSRxIndex } ::= { dot11SupportedMCSRxTable 1 } 3155 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Dot11SupportedMCSRxEntry ::= SEQUENCE { dot11SupportedMCSRxIndex Unsigned32, dot11SupportedMCSRxValue Unsigned32 } dot11SupportedMCSRxIndex OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index object that identifies which MCS to access. Range is 1..255." ::= { dot11SupportedMCSRxEntry 1 } dot11SupportedMCSRxValue OBJECT-TYPE SYNTAX Unsigned32 (1..127) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. The receive MCS supported by the PHY, represented by a count from 1 to 127, subject to limitations of each individual PHY." ::= { dot11SupportedMCSRxEntry 2 } -- ********************************************************************** -- * End of dot11 Supported MCS Rx TABLE -- ********************************************************************** -- ********************************************************************** -- * dot11 Transmit Beamforming Config TABLE -- ********************************************************************** dot11TransmitBeamformingConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11TransmitBeamformingConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry of attributes for dot11TransmitBeamformingConfigTable. Implemented as a table indexed on ifIndex to allow for multiple instances on an Agent." ::= { dot11phy 18 } dot11TransmitBeamformingConfigEntry OBJECT-TYPE SYNTAX Dot11TransmitBeamformingConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11TransmitBeamformingConfig Table. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX {ifIndex} ::= { dot11TransmitBeamformingConfigTable 1 } Dot11TransmitBeamformingConfigEntry ::= SEQUENCE { dot11ReceiveStaggerSoundingOptionImplemented TruthValue, dot11TransmitStaggerSoundingOptionImplemented TruthValue, dot11ReceiveNDPOptionImplemented TruthValue, dot11TransmitNDPOptionImplemented TruthValue, dot11ImplicitTransmitBeamformingOptionImplemented TruthValue, dot11CalibrationOptionImplemented INTEGER, dot11ExplicitCSITransmitBeamformingOptionImplemented TruthValue, dot11ExplicitNonCompressedBeamformingMatrixOptionImplemented 3156 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications TruthValue, dot11ExplicitTransmitBeamformingCSIFeedbackOptionImplemented INTEGER, dot11ExplicitNonCompressedBeamformingFeedbackOptionImplemented INTEGER, dot11ExplicitCompressedBeamformingFeedbackOptionImplemented INTEGER, dot11NumberBeamFormingCSISupportAntenna Unsigned32, dot11NumberNonCompressedBeamformingMatrixSupportAntenna Unsigned32, dot11NumberCompressedBeamformingMatrixSupportAntenna Unsigned32 } dot11ReceiveStaggerSoundingOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the STA implementation supports the receiving of staggered sounding frames." DEFVAL { false } ::= { dot11TransmitBeamformingConfigEntry 1 } dot11TransmitStaggerSoundingOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the STA implementation supports the transmission of staggered sounding frames." DEFVAL { false } ::= { dot11TransmitBeamformingConfigEntry 2 } dot11ReceiveNDPOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the STA implementation is capable of receiving NDP as sounding frames." DEFVAL { false } ::= { dot11TransmitBeamformingConfigEntry 3 } dot11TransmitNDPOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the STA implementation is capable of transmitting NDP as sounding frames." DEFVAL { false } ::= { dot11TransmitBeamformingConfigEntry 4 } 3157 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11ImplicitTransmitBeamformingOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that STA implementation is capable of applying implicit transmit beamforming." DEFVAL { false } ::= { dot11TransmitBeamformingConfigEntry 5 } dot11CalibrationOptionImplemented OBJECT-TYPE SYNTAX INTEGER { inCapable (0), unableToInitiate (1), ableToInitiate (2), fullyCapable (3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates the level of calibration supported by the STA implementation." DEFVAL { inCapable } ::= { dot11TransmitBeamformingConfigEntry 6 } dot11ExplicitCSITransmitBeamformingOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that STA implementation is capable of applying transmit beamforming using CSI explicit feedback in its transmission." DEFVAL { false } ::= { dot11TransmitBeamformingConfigEntry 7 } dot11ExplicitNonCompressedBeamformingMatrixOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that STA implementation is capable of applying transmit beamforming using noncompressed beamforming feedback matrix explicit feedback in its transmission." DEFVAL { false } ::= { dot11TransmitBeamformingConfigEntry 8 } dot11ExplicitTransmitBeamformingCSIFeedbackOptionImplemented OBJECT-TYPE SYNTAX INTEGER { inCapable (0), delayed (1), immediate (2), unsolicitedImmediate (3), 3158 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications aggregated (4), delayedAggregated (5), immediateAggregated(6), unsolicitedImmediateAggregated (7) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates the level of CSI explicit feedback returned by the STA implementation." DEFVAL { inCapable } ::= { dot11TransmitBeamformingConfigEntry 9 } dot11ExplicitNonCompressedBeamformingFeedbackOptionImplemented OBJECT-TYPE SYNTAX INTEGER { inCapable (0), delayed (1), immediate (2), unsolicitedImmediate (3), aggregated (4), delayedAggregated (5), immediateAggregated(6), unsolicitedImmediateAggregated (7) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates the level of noncompressed beamforming feedback matrix explicit feedback returned by the STA implementation." DEFVAL { inCapable } ::= { dot11TransmitBeamformingConfigEntry 10 } dot11ExplicitCompressedBeamformingFeedbackOptionImplemented OBJECT-TYPE SYNTAX INTEGER { inCapable (0), delayed (1), immediate (2), unsolicitedImmediate (3), aggregated (4), delayedAggregated (5), immediateAggregated(6), unsolicitedImmediateAggregated (7) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates the level of noncompressed beamforming feedback matrix explicit feedback returned by the STA implementation." DEFVAL { inCapable } ::= { dot11TransmitBeamformingConfigEntry 11 } dot11NumberBeamFormingCSISupportAntenna OBJECT-TYPE SYNTAX Unsigned32 (1..4) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. 3159 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This attribute indicates the maximum number of beamforming antennas the beamformee can support when CSI feedback is required." ::= { dot11TransmitBeamformingConfigEntry 12 } dot11NumberNonCompressedBeamformingMatrixSupportAntenna OBJECT-TYPE SYNTAX Unsigned32 (1..4) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates the maximum number of beamforming antennas the beamformee can support when noncompressed beamforming feedback matrix feedback is required." ::= { dot11TransmitBeamformingConfigEntry 13 } dot11NumberCompressedBeamformingMatrixSupportAntenna OBJECT-TYPE SYNTAX Unsigned32 (1..8) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates the maximum number of beamforming antennas the beamformee can support when compressed beamforming feedback matrix feedback is required." ::= { dot11TransmitBeamformingConfigEntry 14 } -- ********************************************************************** -- * End of dot11 Transmit Beamforming Config TABLE -- ********************************************************************** -- ******************************************************************* -- * dot11 Phy DMG TABLE -- ******************************************************************* dot11PHYDMGTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11PHYDMGEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry of attributes for dot11PhyDMGTable. Implemented as a table indexed on ifIndex to allow for multiple instances on an Agent." ::= { dot11phy 19 } dot11PHYDMGEntry OBJECT-TYPE SYNTAX Dot11PHYDMGEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in dot11PHYDMGTable. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX {ifIndex} ::= { dot11PHYDMGTable 1 } Dot11PHYDMGEntry ::= SEQUENCE { dot11LowPowerSCPHYImplemented TruthValue, dot11LowPowerSCPHYActivated TruthValue } 3160 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11LowPowerSCPHYImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the low power SC mode is imple- mented." DEFVAL { false } ::= { dot11PHYDMGEntry 1 } dot11LowPowerSCPHYActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute, when true, indicates that the low power SC mode is activated." DEFVAL { false } ::= { dot11PHYDMGEntry 2 } -- ******************************************************************* -- * End of dot11 PHY DMG TABLE -- ******************************************************************* -- ******************************************************************* -- * dot11DMGBeamformingConfig TABLE -- ******************************************************************* dot11DMGBeamformingConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11DMGBeamformingConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is a Table management object. The dot11DMGBeamformingConfig Table" ::= { dot11phy 22 } dot11DMGBeamformingConfigEntry OBJECT-TYPE SYNTAX Dot11DMGBeamformingConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is an entry in the dot11DMGBeamformingConfigTable Table. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX { ifIndex } ::= { dot11DMGBeamformingConfigTable 1 } Dot11DMGBeamformingConfigEntry ::= SEQUENCE { dot11MaxBFTime Unsigned32, dot11BFTXSSTime Unsigned32, dot11MaximalSectorScan Unsigned32, dot11ABFTRTXSSSwitch Unsigned32, dot11RSSRetryLimit Unsigned32, dot11RSSBackoff Unsigned32, dot11BFRetryLimit Unsigned32, 3161 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11BeamLinkMaintenanceTime Unsigned32, dot11AntennaSwitchingTime Unsigned32, dot11ChanMeasFBCKNtaps Unsigned32, dot11BeamTrackingTimeLimit Unsigned32 } dot11MaxBFTime OBJECT-TYPE SYNTAX Unsigned32 (1..16) UNITS "beacon intervals" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or an external management entity. Changes take effect as soon as practical in the implementation. Maximum Beamforming Time." DEFVAL { 4 } ::= { dot11DMGBeamformingConfigEntry 1 } dot11BFTXSSTime OBJECT-TYPE SYNTAX Unsigned32 (1..256) UNITS "milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or an external management entity. Changes take effect as soon as practical in the implementation. Timeout until the initiator restarts ISS." DEFVAL { 100 } ::= { dot11DMGBeamformingConfigEntry 2 } dot11MaximalSectorScan OBJECT-TYPE SYNTAX Unsigned32 (1..32) UNITS "beacon intervals" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or an external management entity. Changes take effect as soon as practical in the implementation. Maximal Sector Scan." DEFVAL { 8 } ::= { dot11DMGBeamformingConfigEntry 3 } dot11ABFTRTXSSSwitch OBJECT-TYPE SYNTAX Unsigned32 (1..32) UNITS "beacon intervals" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or an external management entity. Changes take effect as soon as practical in the implementation. A-BFT Transmit Sector Sweep Switch." DEFVAL { 4 } ::= { dot11DMGBeamformingConfigEntry 4 } dot11RSSRetryLimit OBJECT-TYPE SYNTAX Unsigned32 (1..32) 3162 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or an external management entity. Changes take effect as soon as practical in the implementation. Responder Sector Sweep Retry Limit" DEFVAL { 8 } ::= { dot11DMGBeamformingConfigEntry 5 } dot11RSSBackoff OBJECT-TYPE SYNTAX Unsigned32 (1..32) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or an external management entity. Changes take effect as soon as practical in the implementation. Responder Sector Sweep Backoff" DEFVAL { 8 } ::= { dot11DMGBeamformingConfigEntry 6 } dot11BFRetryLimit OBJECT-TYPE SYNTAX Unsigned32 (1..32) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the SME or an external management entity. Changes take effect as soon as practical in the implementation. Beamforming Retry Limit" DEFVAL { 8 } ::= { dot11DMGBeamformingConfigEntry 7 } dot11BeamLinkMaintenanceTime OBJECT-TYPE SYNTAX Unsigned32 (0..64000000) UNITS "microseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the MAC or SME. Changes take effect as soon as practical in the implementation. Beam Link Maintenance Time dot11BeamLinkMaintenanceTime = BeamLink_Maintenance_Unit * BeamLink_Maintenance_Value. Otherwise, the dot11BeamLinkMaintenanceTime is left undefined. An undefined value of the dot11BeamLinkMaintenanceTime indicates that the STA does not participate in beamformed link maintenance." DEFVAL { 0 } ::= { dot11DMGBeamformingConfigEntry 8 } dot11AntennaSwitchingTime OBJECT-TYPE SYNTAX Unsigned32 (0..64000000) UNITS "microseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the MAC or SME. Changes take effect as soon as practical in the implementation." 3163 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DEFVAL { 0 } ::= { dot11DMGBeamformingConfigEntry 9 } dot11ChanMeasFBCKNtaps OBJECT-TYPE SYNTAX Unsigned32 (0..64000000) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the MAC or SME. Changes take effect as soon as practical in the implementation. Number of channel measurement taps." DEFVAL { 0 } ::= { dot11DMGBeamformingConfigEntry 10 } dot11BeamTrackingTimeLimit OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "microseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by the MAC or SME. Changes take effect as soon as practical in the implementation. BRP tracking initiator time limit." DEFVAL { 10000 } ::= { dot11DMGBeamformingConfigEntry 11 } -- ******************************************************************* -- * End of dot11DMGBeamformingConfig TABLE -- ******************************************************************* -- ********************************************************************** -- * dot11 Phy VHT TABLE -- ********************************************************************** dot11PhyVHTTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11PhyVHTEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry of attributes for dot11PhyVHTTable. Implemented as a table indexed on ifIndex to allow for multiple instances on an Agent." ::= { dot11phy 23 } dot11PhyVHTEntry OBJECT-TYPE SYNTAX Dot11PhyVHTEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11PhyHTEntry Table. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX {ifIndex} ::= { dot11PhyVHTTable 1 } Dot11PhyVHTEntry ::= SEQUENCE { dot11VHTChannelWidthOptionImplemented INTEGER, dot11CurrentChannelWidth INTEGER, dot11CurrentChannelCenterFrequencyIndex0 Unsigned32, dot11CurrentChannelCenterFrequencyIndex1 Unsigned32, dot11VHTShortGIOptionIn80Implemented TruthValue, dot11VHTShortGIOptionIn80Activated TruthValue, 3164 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11VHTShortGIOptionIn160and80p80Implemented TruthValue, dot11VHTShortGIOptionIn160and80p80Activated TruthValue, dot11VHTLDPCCodingOptionImplemented TruthValue, dot11VHTLDPCCodingOptionActivated TruthValue, dot11VHTTxSTBCOptionImplemented TruthValue, dot11VHTTxSTBCOptionActivated TruthValue, dot11VHTRxSTBCOptionImplemented TruthValue, dot11VHTRxSTBCOptionActivated TruthValue, dot11VHTMUMaxUsersImplemented Unsigned32, dot11VHTMUMaxNSTSPerUserImplemented Unsigned32, dot11VHTMUMaxNSTSTotalImplemented Unsigned32, dot11VHTMaxNTxChainsImplemented Unsigned32, dot11VHTMaxNTxChainsActivated Unsigned32 } dot11VHTChannelWidthOptionImplemented OBJECT-TYPE SYNTAX INTEGER { contiguous80(0), contiguous160(1), noncontiguous80plus80(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates the channel widths supported: 20/40/80 MHz, 20/ 40/80/160 MHz or 20/40/80/160/80+80 MHz." DEFVAL { contiguous80 } ::= { dot11PhyVHTEntry 1 } dot11CurrentChannelWidth OBJECT-TYPE SYNTAX INTEGER { cbw20(0), cbw40(1), cbw80(2), cbw160(3), cbw80p80(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. This attribute indicates the operating channel width." DEFVAL { cbw20 } ::= { dot11PhyVHTEntry 2 } dot11CurrentChannelCenterFrequencyIndex0 OBJECT-TYPE SYNTAX Unsigned32 (0..200) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. For a 20 MHz, 40 MHz, 80 MHz, or 160 MHz channel, denotes the channel center frequency. For an 80+80 MHz channel, denotes the center frequency of frequency segment 0. See 21.3.14." DEFVAL { 0 } ::= { dot11PhyVHTEntry 3 } dot11CurrentChannelCenterFrequencyIndex1 OBJECT-TYPE SYNTAX Unsigned32 (0..200) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. For an 80+80 MHz channel, denotes the center frequency of frequency segment 1. Set to 0 for a 20 MHz, 40 MHz, 80 MHz, or 160 MHz channel. See 21.3.14." 3165 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DEFVAL { 0 } ::= { dot11PhyVHTEntry 4 } dot11VHTShortGIOptionIn80Implemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the device is capable of receiving 80 MHz short guard interval packets." DEFVAL { false } ::= { dot11PhyVHTEntry 5 } dot11VHTShortGIOptionIn80Activated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. Changes made while associated with an AP or while operating a BSS should take effect only after disassociation or the deactivation of the BSS, respectively. This attribute, when true, indicates that the reception of 80 MHz short guard interval packets is enabled." DEFVAL { false } ::= { dot11PhyVHTEntry 6 } dot11VHTShortGIOptionIn160and80p80Implemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the device is capable of receiving 160 MHz and 80+80 MHz short guard interval packets." DEFVAL { false } ::= { dot11PhyVHTEntry 7 } dot11VHTShortGIOptionIn160and80p80Activated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. Changes made while associated with an AP or while operating a BSS should take effect only after disassociation or the deactivation of the BSS, respectively. This attribute, when true, indicates that the reception of 160 MHz and 80+80 MHz short guard interval packets is enabled." DEFVAL { false } ::= { dot11PhyVHTEntry 8 } dot11VHTLDPCCodingOptionImplemented OBJECT-TYPE 3166 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the LDPC coding option for VHT packets is implemented." DEFVAL { false } ::= { dot11PhyVHTEntry 9 } dot11VHTLDPCCodingOptionActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. Changes made while associated with an AP or while operating a BSS should take effect only after disassociation or the deactivation of the BSS, respectively. This attribute, when true, indicates that the LDPC coding option for VHT packets is enabled." DEFVAL { false } ::= { dot11PhyVHTEntry 10 } dot11VHTTxSTBCOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the device is capable of transmitting VHT PPDUs using STBC." DEFVAL { false } ::= { dot11PhyVHTEntry 11 } dot11VHTTxSTBCOptionActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. Changes made while associated with an AP or while operating a BSS should take effect only after disassociation or the deactivation of the BSS, respectively. This attribute, when true, indicates that the entity's capability for transmitting VHT PPDUs using STBC is enabled." DEFVAL { false } ::= { dot11PhyVHTEntry 12 } dot11VHTRxSTBCOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION 3167 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the device is capable of receiving VHT PPDUs using STBC." DEFVAL { false } ::= { dot11PhyVHTEntry 13 } dot11VHTRxSTBCOptionActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. Changes made while associated with an AP or while operating a BSS should take effect only after disassociation or the deactivation of the BSS, respectively. This attribute, when true, indicates that the entity's capability for receiving VHT PPDUs using STBC is enabled." DEFVAL { false } ::= { dot11PhyVHTEntry 14 } dot11VHTMUMaxUsersImplemented OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates the maximum number of users to which this device is capable of transmitting within a VHT MU PPDU." DEFVAL { 1 } ::= { dot11PhyVHTEntry 15 } dot11VHTMUMaxNSTSPerUserImplemented OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates the maximum number of space-time streams per user that this device is capable of transmitting within a VHT MU PPDU." DEFVAL { 1 } ::= { dot11PhyVHTEntry 16 } dot11VHTMUMaxNSTSTotalImplemented OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates the maximum number of space-time streams for all users that this device is capable of transmitting within a VHT MU PPDU." DEFVAL { 1 } ::= { dot11PhyVHTEntry 17 } 3168 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11VHTMaxNTxChainsImplemented OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates the maximum number of transmit chains within this device." DEFVAL { 1 } ::= { dot11PhyVHTEntry 18 } dot11VHTMaxNTxChainsActivated OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute indicates the maximum number of transmit chains that are activated within this device, unless this attribute exceeds dot11VHTMaxNTxChainsImplemented, in which case the maximum number of transmit chains that are activated within this device is equal to dot11VHTMaxNTxChainsImplemented." DEFVAL { 2147483647} ::= { dot11PhyVHTEntry 19 } -- ********************************************************************** -- * End of dot11PhyVHT TABLE -- ********************************************************************** -- ********************************************************************** -- * dot11 VHT Transmit Beamforming Config TABLE -- ********************************************************************** dot11VHTTransmitBeamformingConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11VHTTransmitBeamformingConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry of attributes for dot11VHTTransmitBeamformingConfigTable. Implemented as a table indexed on ifIndex to allow for multiple instances on an Agent." ::= { dot11phy 24 } dot11VHTTransmitBeamformingConfigEntry OBJECT-TYPE SYNTAX Dot11VHTTransmitBeamformingConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11VHTTransmitBeamformingConfig Table. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX {ifIndex} ::= { dot11VHTTransmitBeamformingConfigTable 1 } Dot11VHTTransmitBeamformingConfigEntry ::= SEQUENCE { dot11VHTSUBeamformeeOptionImplemented TruthValue, dot11VHTSUBeamformerOptionImplemented TruthValue, dot11VHTMUBeamformeeOptionImplemented TruthValue, 3169 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11VHTMUBeamformerOptionImplemented TruthValue, dot11VHTNumberSoundingDimensions Unsigned32, dot11VHTBeamformeeNTxSupport Unsigned32 } dot11VHTSUBeamformeeOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the STA supports the SU Beamformee role." DEFVAL { false } ::= { dot11VHTTransmitBeamformingConfigEntry 1 } dot11VHTSUBeamformerOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the STA supports the SU Beamformer role." DEFVAL { false } ::= { dot11VHTTransmitBeamformingConfigEntry 2 } dot11VHTMUBeamformeeOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the STA supports the MU Beamformee role." DEFVAL { false } ::= { dot11VHTTransmitBeamformingConfigEntry 3 } dot11VHTMUBeamformerOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the STA supports the MU Beamformer role." DEFVAL { false } ::= { dot11VHTTransmitBeamformingConfigEntry 4 } dot11VHTNumberSoundingDimensions OBJECT-TYPE SYNTAX Unsigned32 (1..8) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. 3170 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This attribute indicates the number of antennas used by the beamformer when sending beamformed transmissions." ::= { dot11VHTTransmitBeamformingConfigEntry 5 } dot11VHTBeamformeeNTxSupport OBJECT-TYPE SYNTAX Unsigned32 (1..8) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates the maximum number of space-time streams that the STA can receive in a VHT NDP, the maximum value for NSTS, total that can be sent to the STA in a VHT MU PPDU if the STA is MU beamformee capable and the maximum value of Nr that the STA transmits in a VHT Compressed Beamforming frame." ::= { dot11VHTTransmitBeamformingConfigEntry 6 } -- ********************************************************************** -- * End of dot11 VHT Transmit Beamforming Config TABLE -- ********************************************************************** -- ********************************************************************** -- * dot11 Phy TVHT TABLE -- ********************************************************************** dot11PhyTVHTTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11PhyTVHTEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry of attributes for dot11PhyTVHTTable. Implemented as a table indexed on ifIndex to allow for multiple instances on an Agent." ::= { dot11phy 25 } dot11PhyTVHTEntry OBJECT-TYPE SYNTAX Dot11PhyTVHTEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11PhyTVHTEntry Table. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX {ifIndex} ::= { dot11PhyTVHTTable 1 } Dot11PhyTVHTEntry ::= SEQUENCE { dot11TVHTChannelWidthOptionImplemented INTEGER, dot11TVHTCurrentChannelWidth INTEGER, dot11TVHTCurrentChannelCenterFrequencyIndex0 Unsigned32, dot11TVHTCurrentChannelCenterFrequencyIndex1 Unsigned32, dot11TVHTShortGIOptionIn4WImplemented TruthValue, dot11TVHTShortGIOptionIn4WActivated TruthValue, dot11TVHTLDPCCodingOptionImplemented TruthValue, dot11TVHTLDPCCodingOptionActivated TruthValue, dot11TVHTTxSTBCOptionImplemented TruthValue, dot11TVHTTxSTBCOptionActivated TruthValue, dot11TVHTRxSTBCOptionImplemented TruthValue, dot11TVHTRxSTBCOptionActivated TruthValue, dot11TVHTMUMaxUsersImplemented Unsigned32, dot11TVHTMUMaxNSTSPerUserImplemented Unsigned32, 3171 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11TVHTMUMaxNSTSTotalImplemented Unsigned32, dot11TVHTMaxNTxChainsImplemented Unsigned32, dot11TVHTMaxNTxChainsActivated Unsigned32 } dot11TVHTChannelWidthOptionImplemented OBJECT-TYPE SYNTAX INTEGER { tvhtmode1(0), tvhtmode2c(1), tvhtmode2n(2), tvhtmode4c(3), tvhtmode4n(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates the channel widths supported: W MHz, 2W MHz, W+W MHz, 4W MHz or 2W+2W MHz." DEFVAL { tvhtmode1 } ::= { dot11PhyTVHTEntry 1 } dot11TVHTCurrentChannelWidth OBJECT-TYPE SYNTAX INTEGER { tvhtw(0), tvht2w(1), tvhtwpw(2), tvht4w(3), tvht2wp2w(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. This attribute indicates the operating channel width." DEFVAL { tvhtw } ::= { dot11PhyTVHTEntry 2 } dot11TVHTCurrentChannelCenterFrequencyIndex0 OBJECT-TYPE SYNTAX Unsigned32 (0..200) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. For a W MHz, 2W MHz or 4W MHz channel, denotes the channel center frequency. For an W+W or 2W+2W MHz channel, denotes the center frequency of frequency segment 0. See 22.3.14." DEFVAL { 0 } ::= { dot11PhyTVHTEntry 3 } dot11TVHTCurrentChannelCenterFrequencyIndex1 OBJECT-TYPE SYNTAX Unsigned32 (0..200) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. For an W+W or 2W+2W MHz channel, denotes the center frequency of frequency segment 1. Set to 0 for a W MHz, 2W MHz or 4W MHz channel. See 22.3.14." DEFVAL { 0 } ::= { dot11PhyTVHTEntry 4 } dot11TVHTShortGIOptionIn4WImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. 3172 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This attribute, when true, indicates that the device is capable of receiving 4W MHz short guard interval packets." DEFVAL { false } ::= { dot11PhyTVHTEntry 5 } dot11TVHTShortGIOptionIn4WActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. Changes made while associated with an AP or while operating a BSS should take effect only after disassociation or the deactivation of the BSS, respectively. This attribute, when true, indicates that the reception of 4W MHz short guard interval packets is enabled." DEFVAL { false } ::= { dot11PhyTVHTEntry 6 } dot11TVHTLDPCCodingOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the LDPC coding option for TVHT packets is implemented." DEFVAL { false } ::= { dot11PhyTVHTEntry 7 } dot11TVHTLDPCCodingOptionActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. Changes made while associated with an AP or while operating a BSS should take effect only after disassociation or the deactivation of the BSS, respectively. This attribute, when true, indicates that the LDPC coding option for TVHT packets is enabled." DEFVAL { false } ::= { dot11PhyTVHTEntry 8 } dot11TVHTTxSTBCOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the device is capable of transmitting TVHT PPDUs using STBC." DEFVAL { false } 3173 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ::= { dot11PhyTVHTEntry 9 } dot11TVHTTxSTBCOptionActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. Changes made while associated with an AP or while operating a BSS should take effect only after disassociation or the deactivation of the BSS, respectively. This attribute, when true, indicates that the entity's capability for transmitting TVHT PPDUs using STBC is enabled." DEFVAL { false } ::= { dot11PhyTVHTEntry 10 } dot11TVHTRxSTBCOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the device is capable of receiving TVHT PPDUs using STBC." DEFVAL { false } ::= { dot11PhyTVHTEntry 11 } dot11TVHTRxSTBCOptionActivated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. Changes made while associated with an AP or while operating a BSS should take effect only after disassociation or the deactivation of the BSS, respectively. This attribute, when true, indicates that the entity's capability for receiving TVHT PPDUs using STBC is enabled." DEFVAL { false } ::= { dot11PhyTVHTEntry 12 } dot11TVHTMUMaxUsersImplemented OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates the maximum number of users to which this device is capable of transmitting within a TVHT MU PPDU." DEFVAL { 1 } ::= { dot11PhyTVHTEntry 13 } dot11TVHTMUMaxNSTSPerUserImplemented OBJECT-TYPE SYNTAX Unsigned32 3174 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates the maximum number of space-time streams per user that this device is capable of transmitting within a TVHT MU PPDU." DEFVAL { 1 } ::= { dot11PhyTVHTEntry 14 } dot11TVHTMUMaxNSTSTotalImplemented OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates the maximum number of space-time streams for all users that this device is capable of transmitting within a TVHT MU PPDU." DEFVAL { 1 } ::= { dot11PhyTVHTEntry 15 } dot11TVHTMaxNTxChainsImplemented OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates the maximum number of transmit chains within this device." DEFVAL { 1 } ::= { dot11PhyTVHTEntry 16 } dot11TVHTMaxNTxChainsActivated OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity. Changes take effect as soon as practical in the implementation. This attribute indicates the maximum number of transmit chains that are activated within this device, unless this attribute exceeds dot11TVHTMaxNTxChainsImplemented, in which case the maximum number of transmit chains that are activated within this device is equal to dot11TVHTMaxNTxChainsImplemented." DEFVAL { 2147483647 } ::= { dot11PhyTVHTEntry 17 } -- ********************************************************************** -- * End of dot11PhyTVHT TABLE -- ********************************************************************** -- ********************************************************************** -- * dot11 TVHT Transmit Beamforming Config TABLE -- ********************************************************************** dot11TVHTTransmitBeamformingConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11TVHTTransmitBeamformingConfigEntry 3175 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry of attributes for dot11TVHTTransmitBeamformingConfigTable. Implemented as a table indexed on ifIndex to allow for multiple instances on an Agent." ::= { dot11phy 26 } dot11TVHTTransmitBeamformingConfigEntry OBJECT-TYPE SYNTAX Dot11TVHTTransmitBeamformingConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot11TVHTTransmitBeamformingConfig Table. ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex." INDEX {ifIndex} ::= { dot11TVHTTransmitBeamformingConfigTable 1 } Dot11TVHTTransmitBeamformingConfigEntry ::= SEQUENCE { dot11TVHTSUBeamformeeOptionImplemented TruthValue, dot11TVHTSUBeamformerOptionImplemented TruthValue, dot11TVHTMUBeamformeeOptionImplemented TruthValue, dot11TVHTMUBeamformerOptionImplemented TruthValue, dot11TVHTNumberSoundingDimensions Unsigned32, dot11TVHTBeamformeeNTxSupport Unsigned32 } dot11TVHTSUBeamformeeOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the STA supports the SU Beamformee role." DEFVAL { false } ::= { dot11TVHTTransmitBeamformingConfigEntry 1 } dot11TVHTSUBeamformerOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the STA supports the SU Beamformer role." DEFVAL { false } ::= { dot11TVHTTransmitBeamformingConfigEntry 2 } dot11TVHTMUBeamformeeOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the STA supports the MU 3176 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Beamformee role." DEFVAL { false } ::= { dot11TVHTTransmitBeamformingConfigEntry 3 } dot11TVHTMUBeamformerOptionImplemented OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the STA supports the MU Beamformer role." DEFVAL { false } ::= { dot11TVHTTransmitBeamformingConfigEntry 4 } dot11TVHTNumberSoundingDimensions OBJECT-TYPE SYNTAX Unsigned32 (1..8) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates the number of antennas used by the beamformer when sending beamformed transmissions." ::= { dot11TVHTTransmitBeamformingConfigEntry 5 } dot11TVHTBeamformeeNTxSupport OBJECT-TYPE SYNTAX Unsigned32 (1..8) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute indicates the maximum number of space-time streams that the STA can receive in a TVHT NDP, the maximum value for NSTS, total that can be sent to the STA in a TVHT MU PPDU if the STA is MU beamformee capable and the maximum value of Nr that the STA transmits in a TVHT Compressed Beamforming frame." ::= { dot11TVHTTransmitBeamformingConfigEntry 6 } -- ********************************************************************** -- * End of dot11 TVHT Transmit Beamforming Config TABLE -- ********************************************************************** -- Interworking Management (IMT) Attributes -- DEFINED AS "The Interworking management object class provides -- the necessary support for an SSPN Interface function to manage -- interworking with external systems. IMT objects are conceptual -- objects for Interworking Service and are defined only for the -- AP." dot11imt OBJECT IDENTIFIER ::= {ieee802dot11 6} -- IMT GROUPS -- dot11BSSIdTable ::= { dot11imt 1 } -- dot11InterworkingTable ::= { dot11imt 2 } -- dot11APLCITable ::= { dot11imt 3 } -- dot11APCivicLocationTable ::= { dot11imt 4 } -- dot11RoamingConsortiumTable ::= { dot11imt 5 } -- dot11DomainNameTable ::= { dot11imt 6 } 3177 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications -- Generic Advertisement Service (GAS) Attributes -- DEFINED AS "The Generic Advertisement Service management -- object class provides the necessary support for an Advertisement -- service to interwork with external systems." -- GAS GROUPS -- dot11GASAdvertisementTable ::= { dot11imt 7 } --********************************************************************** -- * dot11BSSId TABLE --********************************************************************** dot11BSSIdTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11BSSIdEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object is a table of BSSIDs contained within an Access Point (AP)." ::= { dot11imt 1 } dot11BSSIdEntry OBJECT-TYPE SYNTAX Dot11BSSIdEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object provides the attributes identifying a particular BSSID within an AP." INDEX { dot11APMacAddress } ::= { dot11BSSIdTable 1 } Dot11BSSIdEntry ::= SEQUENCE{ dot11APMacAddress MacAddress } dot11APMacAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. Changes take effect for the next MLME-START.request primitive. This object specifies the MAC address of the BSSID represented on a particular BSSID interface and uniquely identifies this entry." ::= { dot11BSSIdEntry 1 } --********************************************************************** -- * End of dot11BSSId TABLE --********************************************************************** --********************************************************************** -- * dot11Interworking TABLE --********************************************************************** dot11InterworkingTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11InterworkingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table represents the non-AP STAs associated to the AP. An entry is created automatically by the AP when the STA becomes associated to the AP. The corresponding entry is deleted when the STA disassociates. Each STA added to this table is uniquely identified by its MAC address. This table 3178 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications is moved to a new AP following a successful STA BSS transition event." ::= { dot11imt 2 } dot11InterworkingEntry OBJECT-TYPE SYNTAX Dot11InterworkingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry represents a conceptual row in the dot11InterworkingTable and provides information about permissions received from an SSPN Interface. If a non-AP STA does not receive permissions for one or more of these objects, then the object's default values or AP's locally defined configuration may be used instead. If the AP's local policy(s) is more restrictive than an object's value received from the SSPN Interface, then the AP's local policy shall be enforced. An entry is identified by the AP's MAC address to which the STA is associated and the STA's MAC address." INDEX { dot11APMacAddress, dot11NonAPStationMacAddress } ::= { dot11InterworkingTable 1 } Dot11InterworkingEntry ::= SEQUENCE { dot11NonAPStationMacAddress MacAddress, dot11NonAPStationUserIdentity DisplayString, dot11NonAPStationInterworkingCapability BITS, dot11NonAPStationAssociatedSSID OCTET STRING, dot11NonAPStationUnicastCipherSuite OCTET STRING, dot11NonAPStationBroadcastCipherSuite OCTET STRING, dot11NonAPStationAuthAccessCategories BITS, dot11NonAPStationAuthMaxVoiceRate Unsigned32, dot11NonAPStationAuthMaxVideoRate Unsigned32, dot11NonAPStationAuthMaxBestEffortRate Unsigned32, dot11NonAPStationAuthMaxBackgroundRate Unsigned32, dot11NonAPStationAuthMaxVoiceOctets Unsigned32, dot11NonAPStationAuthMaxVideoOctets Unsigned32, dot11NonAPStationAuthMaxBestEffortOctets Unsigned32, dot11NonAPStationAuthMaxBackgroundOctets Unsigned32, dot11NonAPStationAuthMaxHCCAHEMMOctets Unsigned32, dot11NonAPStationAuthMaxTotalOctets Unsigned32, dot11NonAPStationAuthHCCAHEMM TruthValue, dot11NonAPStationAuthMaxHCCAHEMMRate Unsigned32, dot11NonAPStationAuthHCCAHEMMDelay Unsigned32, dot11NonAPStationAuthSourceMulticast TruthValue, dot11NonAPStationAuthMaxSourceMulticastRate Unsigned32, dot11NonAPStationVoiceMSDUCount Counter32, dot11NonAPStationDroppedVoiceMSDUCount Counter32, dot11NonAPStationVoiceOctetCount Counter32, dot11NonAPStationDroppedVoiceOctetCount Counter32, dot11NonAPStationVideoMSDUCount Counter32, dot11NonAPStationDroppedVideoMSDUCount Counter32, dot11NonAPStationVideoOctetCount Counter32, dot11NonAPStationDroppedVideoOctetCount Counter32, dot11NonAPStationBestEffortMSDUCount Counter32, dot11NonAPStationDroppedBestEffortMSDUCount Counter32, dot11NonAPStationBestEffortOctetCount Counter32, dot11NonAPStationDroppedBestEffortOctetCount Counter32, dot11NonAPStationBackgroundMSDUCount Counter32, dot11NonAPStationDroppedBackgroundMSDUCount Counter32, dot11NonAPStationBackgroundOctetCount Counter32, dot11NonAPStationDroppedBackgroundOctetCount Counter32, dot11NonAPStationHCCAHEMMMSDUCount Counter32, dot11NonAPStationDroppedHCCAHEMMMSDUCount Counter32, dot11NonAPStationHCCAHEMMOctetCount Counter32, dot11NonAPStationDroppedHCCAHEMMOctetCount Counter32, 3179 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11NonAPStationMulticastMSDUCount Counter32, dot11NonAPStationDroppedMulticastMSDUCount Counter32, dot11NonAPStationMulticastOctetCount Counter32, dot11NonAPStationDroppedMulticastOctetCount Counter32, dot11NonAPStationPowerManagementMode INTEGER, dot11NonAPStationAuthDls TruthValue, dot11NonAPStationVLANId Unsigned32, dot11NonAPStationVLANName DisplayString, dot11NonAPStationAddtsResultCode INTEGER} dot11NonAPStationMacAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME after a non-AP STA associates to the BSS. This object specifies the MAC address of the non-AP STA for this entry and uniquely identifies this entry." ::= { dot11InterworkingEntry 1 } dot11NonAPStationUserIdentity OBJECT-TYPE SYNTAX DisplayString (SIZE(0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME after a non-AP STA associates to the BSS. This attribute reflects the user identity for the subscriber operating this non-AP STA" ::= { dot11InterworkingEntry 2 } dot11NonAPStationInterworkingCapability OBJECT-TYPE SYNTAX BITS { interworkingCapability(0), qosMapCapability(1), expeditedBwReqCapability(2), msgcfCapability(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME after a non-AP STA associates to the BSS. This attribute defines the Interworking capabilities possessed by a non-AP STA. Interworking Capability is set to 1 when the STA includes the Interworking element in its (re)association request. The QosMapCapability, ExpeditedBwReqCapability and MSGCFCapability bits reflect the same values and meanings as those defined in 9.4.2.27" ::= { dot11InterworkingEntry 3 } dot11NonAPStationAssociatedSSID OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. 3180 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications It is written by the SME after a non-AP STA associates to the BSS. This attribute reflects the SSID to which the non-AP STA is associated" ::= { dot11InterworkingEntry 4 } dot11NonAPStationUnicastCipherSuite OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME after a non-AP STA authenticates with the BSS. The selector of the AKM cipher suite that is currently in use by the non- AP STA. It consists of an OUI or CID (the first 3 octets) and a cipher suite identifier (the last octet)." ::= { dot11InterworkingEntry 5 } dot11NonAPStationBroadcastCipherSuite OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME after a non-AP STA authenticates with the BSS. The selector of an AKM suite for broadcast and group addressed frame transmissions. It consists of an OUI or CID (the first 3 octets) and a cipher suite identifier the last octet)." ::= { dot11InterworkingEntry 6 } dot11NonAPStationAuthAccessCategories OBJECT-TYPE SYNTAX BITS { bestEffort(0), background(1), video(2), voice(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME after the AP receives the permissions for the non-AP STA from the SSPN Interface. The object that represents the access categories which the non-AP STA is permitted to use when admission control is configured on that AC. An AC is permitted to be used if its corresponding bit is set to 1; otherwise it is not permitted to be used." DEFVAL { { bestEffort, background, video, voice } } ::= { dot11InterworkingEntry 7 } dot11NonAPStationAuthMaxVoiceRate OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) UNITS "kb/s" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME after the AP receives the permissions for the 3181 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications non-AP STA from the SSPN Interface. This attribute indicates the maximum authorized data rate the non-AP STA may use, either transmitting to an AP or receiving from an AP on the voice access category. If this rate is exceeded, the AP should police the flows traversing this AC. The value '4294967295', which is the default value, means that the SSP is not requesting the AP to limit the data rate used by the non-AP STA. Local configuration of the AP, however, may cause the rate to be limited, especially when the AC is configured for mandatory admission control." DEFVAL {4294967295} ::= { dot11InterworkingEntry 8 } dot11NonAPStationAuthMaxVideoRate OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) UNITS "kb/s" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME after the AP receives the permissions for the non-AP STA from the SSPN Interface. This attribute indicates the maximum authorized data rate the non-AP STA may use, either transmitting to an AP or receiving from an AP on the video access category. If this rate is exceeded, the AP should police the flows traversing this AC. The value '4294967295', which is the default value, means that the SSP is not requesting the AP to limit the data rate used by the non-AP STA. Local configuration of the AP, however, may cause the rate to be limited, especially when the AC is configured for mandatory admission control." DEFVAL {4294967295} ::= { dot11InterworkingEntry 9 } dot11NonAPStationAuthMaxBestEffortRate OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) UNITS "kb/s" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME after the AP receives the permissions for the non-AP STA from the SSPN Interface. This attribute indicates the maximum authorized data rate the non-AP STA may use, either transmitting to an AP or receiving from an AP on the best effort access category. If this rate is exceeded, the AP should police the flows traversing this AC. The value '4294967295', which is the default value, means that the SSP is not requesting the AP to limit the data rate used by the non-AP STA. Local configuration of the AP, however, may cause the rate to be limited, especially when the AC is configured for mandatory admission control." DEFVAL {4294967295} ::= { dot11InterworkingEntry 10 } dot11NonAPStationAuthMaxBackgroundRate OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) UNITS "kb/s" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. 3182 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications It is written by the SME after the AP receives the permissions for the non-AP STA from the SSPN Interface. This attribute indicates the maximum authorized data rate the non-AP STA may use, either transmitting to an AP or receiving from an AP on the background access category. If this rate is exceeded, the AP should police the flows traversing this AC. The value '4294967295', which is the default value, means that the SSP is not requesting the AP to limit the data rate used by the non-AP STA. Local configuration of the AP, however, may cause the rate to be limited, especially when the AC is configured for mandatory admission control." DEFVAL {4294967295} ::= { dot11InterworkingEntry 11 } dot11NonAPStationAuthMaxVoiceOctets OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME after the AP receives the permissions for the non-AP STA from the SSPN Interface. This attribute indicates the maximum authorized total octet count that a STA may use on the voice access category. If this octet count is exceeded, the AP should disassociate the non-AP STA. A value of 0 indicates that there is no octet limit." DEFVAL {0} ::= { dot11InterworkingEntry 12 } dot11NonAPStationAuthMaxVideoOctets OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME after the AP receives the permissions for the non-AP STA from the SSPN Interface. This attribute indicates the maximum authorized total octet count that a STA may use on the video access category. If this octet count is exceeded, the AP should disassociate the non-AP STA. A value of 0 indicates that there is no octet limit." DEFVAL {0} ::= { dot11InterworkingEntry 13 } dot11NonAPStationAuthMaxBestEffortOctets OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME after the AP receives the permissions for the non-AP STA from the SSPN Interface. This attribute indicates the maximum authorized total octet count that a STA may use on the best effort access category. If this octet count is exceeded, the AP should disassociate the non-AP STA. A value of 0 indicates that there is no octet limit." DEFVAL {0} 3183 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ::= { dot11InterworkingEntry 14 } dot11NonAPStationAuthMaxBackgroundOctets OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME after the AP receives the permissions for the non-AP STA from the SSPN Interface. This attribute indicates the maximum authorized total octet count that a STA may use on the background access category. If this octet count is exceeded, the AP should disassociate the non-AP STA. A value of 0 indicates that there is no octet limit." DEFVAL {0} ::= { dot11InterworkingEntry 15 } dot11NonAPStationAuthMaxHCCAHEMMOctets OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME after the AP receives the permissions for the non-AP STA from the SSPN Interface. This attribute indicates the maximum authorized total octet count that a STA may use with HCCA or HEMM access. If this octet count is exceeded, the AP should disassociate the non-AP STA. A value of 0 indicates that there is no octet limit." DEFVAL {0} ::= { dot11InterworkingEntry 16 } dot11NonAPStationAuthMaxTotalOctets OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME after the AP receives the permissions for the non-AP STA from the SSPN Interface. This attribute indicates the maximum authorized total octet count that a STA may use on all access categories combined. If this octet count is exceeded, the AP should disassociate the non-AP STA. A value of 0 indicates that there is no octet limit." DEFVAL {0} ::= { dot11InterworkingEntry 17 } dot11NonAPStationAuthHCCAHEMM OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME after the AP receives the permissions for the non-AP STA from the SSPN Interface. This attribute, when true, indicates that the non-AP STA is permitted by 3184 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications the SSP to request HCCA or HEMM service via ADDTS frames. If this attribute is false, then HCCA or HEMM service is not permitted by the SSP." DEFVAL {true} ::= { dot11InterworkingEntry 18 } dot11NonAPStationAuthMaxHCCAHEMMRate OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) UNITS "kb/s" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME after the AP receives the permissions for the non-AP STA from the SSPN Interface. This attribute indicates the maximum authorized data rate the non-AP STA may use, either transmitting to an AP or receiving from an AP via HCCA or HEMM. The value '4294967295', which is the default value, means that the SSP is not requesting the AP to limit the data rate used by the non-AP STA. Local configuration of the AP, however, may cause the rate to be otherwise limited." DEFVAL {4294967295} ::= { dot11InterworkingEntry 19 } dot11NonAPStationAuthHCCAHEMMDelay OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) UNITS "microseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME after the AP receives the permissions for the non-AP STA from the SSPN Interface. This attribute indicates the delay bound for frames queued at an AP to a non-AP STA in the HCCA or HEMM queue. An AP should deliver frames to the non-AP STA within the time period specified in this attribute. When a non- AP STA requests admission control to the HCCA or HEMM queue, the requested delay will be equal to or higher than this value. The value '4294967295', which is the default value, means that the SSP is not requesting the AP limit the delay bound in this queue for transmissions to the non-AP STA." DEFVAL {4294967295} ::= { dot11InterworkingEntry 20 } dot11NonAPStationAuthSourceMulticast OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME after the AP receives the permissions for the non-AP STA from the SSPN Interface. This attribute, when true, indicates that the AP's MAC sublayer shall perform rate limiting to enforce the resource utilization limit in dot11NonAPStationAuthMaxSourceMulticastRate in the dot11InterworkingEntry identified by the source MAC address of the received frame. If this attribute is false, at an AP for which dot11SSPNInterfaceActivated is true, upon receipt of a frame with the Type subfield equal to Data with group DA, then the AP's MAC sublayer shall discard the frame." 3185 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DEFVAL {true} ::= { dot11InterworkingEntry 21 } dot11NonAPStationAuthMaxSourceMulticastRate OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) UNITS "kb/s" MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME after the AP receives the permissions for the non-AP STA from the SSPN Interface. This attribute indicates the maximum authorized data rate which the non-AP STA may transmit group addressed frames to an AP. If this rate is exceeded, the AP should police the flows. The value '4294967295', which is the default value, means that the SSP is not requesting the AP to limit the multicast data rate used by the non-AP STA." DEFVAL {4294967295} ::= { dot11InterworkingEntry 22 } dot11NonAPStationVoiceMSDUCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the AP's MAC after the completion of an MA- UNITDATA.confirm or MA-UNITDATA.indication primitive. For EDCA operation, this counter shall be incremented for each MSDU successfully transmitted by the AP on the voice access category and for each MSDU successfully received on either user priority 6 or 7." ::= { dot11InterworkingEntry 23 } dot11NonAPStationDroppedVoiceMSDUCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the AP's MAC after the completion of an MA- UNITDATA.confirm or MA-UNITDATA.indication primitive. For EDCA operation, this counter shall be incremented for each MSDU dropped by the AP on the voice access category." ::= { dot11InterworkingEntry 24 } dot11NonAPStationVoiceOctetCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the AP's MAC after the completion of an MA- UNITDATA.confirm or MA-UNITDATA.indication primitive. For EDCA operation, this counter shall be incremented by the octet length of each MSDU successfully transmitted by the AP on the voice access category and by the octet length of each MSDU successfully received on 3186 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications either user priority 6 or 7." ::= { dot11InterworkingEntry 25 } dot11NonAPStationDroppedVoiceOctetCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the AP's MAC after the completion of an MA- UNITDATA.confirm or MA-UNITDATA.indication primitive. For EDCA operation, this counter shall be incremented for each octet dropped by the AP on the voice access category." ::= { dot11InterworkingEntry 26 } dot11NonAPStationVideoMSDUCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the AP's MAC after the completion of an MA- UNITDATA.confirm or MA-UNITDATA.indication primitive. For EDCA operation, this counter shall be incremented for each MSDU successfully transmitted by the AP on the video access category and for each MSDU successfully received on either user priority 4 or 5." ::= { dot11InterworkingEntry 27 } dot11NonAPStationDroppedVideoMSDUCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the AP's MAC after the completion of an MA- UNITDATA.confirm or MA-UNITDATA.indication primitive. For EDCA operation, this counter shall be incremented for each MSDU dropped by the AP on the video access category." ::= { dot11InterworkingEntry 28 } dot11NonAPStationVideoOctetCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the AP's MAC after the completion of an MA- UNITDATA.confirm or MA-UNITDATA.indication primitive. For EDCA operation, this counter shall be incremented by the octet length of each MSDU successfully transmitted by the AP on the voice access category and by the octet length of each MSDU successfully received on either user priority 4 or 5." ::= { dot11InterworkingEntry 29 } dot11NonAPStationDroppedVideoOctetCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only 3187 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STATUS current DESCRIPTION "This is a status variable. It is written by the AP's MAC after the completion of an MA- UNITDATA.confirm or MA-UNITDATA.indication primitive. For EDCA operation, this counter shall be incremented for each octet dropped by the AP on the video access category." ::= { dot11InterworkingEntry 30 } dot11NonAPStationBestEffortMSDUCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the AP's MAC after the completion of an MA- UNITDATA.confirm or MA-UNITDATA.indication primitive. For EDCA operation, this counter shall be incremented for each MSDU successfully transmitted by the AP on the best effort access category and for each MSDU successfully received on either user priority 0 or 3. For DCF or PCF operation, this counter shall be incremented for each MSDU successfully transmitted or received by the AP." ::= { dot11InterworkingEntry 31 } dot11NonAPStationDroppedBestEffortMSDUCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the AP's MAC after the completion of an MA- UNITDATA.confirm or MA-UNITDATA.indication primitive. For EDCA operation, this counter shall be incremented for each MSDU dropped by the AP on the best effort access category and for each MSDU dropped by the AP on either user priority 0 or 3. For DCF or PCF operation, this counter shall be incremented for each MSDU dropped by the AP." ::= { dot11InterworkingEntry 32 } dot11NonAPStationBestEffortOctetCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the AP's MAC after the completion of an MA- UNITDATA.confirm or MA-UNITDATA.indication primitive. For EDCA operation, this counter shall be incremented by the octet length of each MSDU successfully transmitted by the AP on the best effort access category and by the octet length of each MSDU successfully received on either user priority 0 or 3. For DCF or PCF operation, this counter shall be incremented the octet length of each MSDU successfully transmitted or received by the AP." ::= { dot11InterworkingEntry 33 } dot11NonAPStationDroppedBestEffortOctetCount OBJECT-TYPE 3188 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the AP's MAC after the completion of an MA- UNITDATA.confirm or MA-UNITDATA.indication primitive. For EDCA operation, this counter shall be incremented for the octet length of each MSDU dropped by the AP on the best effort access category and by the octet length of each MSDU dropped by the AP for either user priority 0 or 3. For DCF or PCF operation, this counter shall be incremented for the octet length of each MSDU dropped by the AP." ::= { dot11InterworkingEntry 34 } dot11NonAPStationBackgroundMSDUCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the AP's MAC after the completion of an MA- UNITDATA.confirm or MA-UNITDATA.indication primitive. For EDCA operation, this counter shall be incremented for each MSDU successfully transmitted by the AP on the background access category and for each MSDU successfully received on either user priority 1 or 2." ::= { dot11InterworkingEntry 35 } dot11NonAPStationDroppedBackgroundMSDUCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the AP's MAC after the completion of an MA- UNITDATA.confirm or MA-UNITDATA.indication primitive. For EDCA operation, this counter shall be incremented for each MSDU dropped by the AP on the background access category" ::= { dot11InterworkingEntry 36 } dot11NonAPStationBackgroundOctetCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the AP's MAC after the completion of an MA- UNITDATA.confirm or MA-UNITDATA.indication primitive. For EDCA operation, this counter shall be incremented by the octet length of each MSDU successfully transmitted by the AP on the background access category and by the octet length of each MSDU successfully received on either user priority 1 or 2." ::= { dot11InterworkingEntry 37 } dot11NonAPStationDroppedBackgroundOctetCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only 3189 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STATUS current DESCRIPTION "This is a status variable. It is written by the AP's MAC after the completion of an MA- UNITDATA.confirm or MA-UNITDATA.indication primitive. For EDCA operation, this counter shall be incremented by the octet length of each MSDU dropped by the AP on the background access category" ::= { dot11InterworkingEntry 38 } dot11NonAPStationHCCAHEMMMSDUCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the AP's MAC after the completion of an MA- UNITDATA.confirm or MA-UNITDATA.indication primitive. For HCCA or HEMM operation, this counter shall be incremented for each MSDU successfully transmitted by the AP and for each MSDU successfully received on either." ::= { dot11InterworkingEntry 39 } dot11NonAPStationDroppedHCCAHEMMMSDUCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the AP's MAC after the completion of an MA- UNITDATA.confirm or MA-UNITDATA.indication primitive. For HCCA or HEMM operation, this counter shall be incremented for each MSDU dropped by the AP." ::= { dot11InterworkingEntry 40 } dot11NonAPStationHCCAHEMMOctetCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the AP's MAC after the completion of an MA- UNITDATA.confirm or MA-UNITDATA.indication primitive. For HCCA or HEMM operation, this counter shall be incremented by the octet length of each MSDU successfully transmitted by the AP and by the octet length of each MSDU successfully received." ::= { dot11InterworkingEntry 41 } dot11NonAPStationDroppedHCCAHEMMOctetCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the AP's MAC after the completion of an MA- UNITDATA.confirm or MA-UNITDATA.indication primitive. 3190 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications For HCCA or HEMM operation, this counter shall be incremented by the octet length of each MSDU dropped by the AP." ::= { dot11InterworkingEntry 42 } dot11NonAPStationMulticastMSDUCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the AP's MAC after the completion of an MA- UNITDATA.confirm or MA-UNITDATA.indication primitive. For Multicast operation, this counter shall be incremented for each Multicast MSDU successfully transmitted by the AP and for each Multicast MSDU successfully received at the AP." ::= { dot11InterworkingEntry 43 } dot11NonAPStationDroppedMulticastMSDUCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the AP's MAC after the completion of an MA- UNITDATA.confirm or MA-UNITDATA.indication primitive. For Multicast operation, this counter shall be incremented for each Multicast MSDU dropped by the AP." ::= { dot11InterworkingEntry 44 } dot11NonAPStationMulticastOctetCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the AP's MAC after the completion of an MA- UNITDATA.confirm or MA-UNITDATA.indication primitive. For Multicast operation, this counter shall be incremented by the octet length of each MSDU successfully transmitted by the AP and by the octet length of each Multicast MSDU successfully received." ::= { dot11InterworkingEntry 45 } dot11NonAPStationDroppedMulticastOctetCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the AP's MAC after the completion of an MA- UNITDATA.confirm or MA-UNITDATA.indication primitive. For Multicast operation, this counter shall be incremented by the octet length of each Multicast MSDU dropped by the AP." ::= { dot11InterworkingEntry 46 } dot11NonAPStationPowerManagementMode OBJECT-TYPE 3191 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications SYNTAX INTEGER { active(1), powersave(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the AP's MAC after the non-AP STA changes it's power management mode. This attribute indicates the power management mode of the non-AP STA." ::= { dot11InterworkingEntry 47 } dot11NonAPStationAuthDls OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is a control variable. It is written by the SME after the AP receives the permissions for the non-AP STA from the SSPN Interface. This attribute, when true, indicates that the non-AP STA is permitted by the SSPN Interface to use direct link service (DLS). Note this attribute is an SSP permission and is independent of whether DLS is allowed in the BSS as governed by dot11DLSAllowedInQBSS. This service is disabled otherwise." DEFVAL {true} ::= { dot11InterworkingEntry 48 } dot11NonAPStationVLANId OBJECT-TYPE SYNTAX Unsigned32 (0..4095) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME after a non-AP STA associates to the BSS. This attribute indicates the VLAN ID on the an external network to which frames from the non-AP STA are bridged." ::= { dot11InterworkingEntry 49 } dot11NonAPStationVLANName OBJECT-TYPE SYNTAX DisplayString (SIZE(0..64)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME after a non-AP STA associates to the BSS. This attribute indicates the VLAN name corresponding to the VLAN ID on the external network to which frames from the non-AP STA are bridged." ::= { dot11InterworkingEntry 50 } dot11NonAPStationAddtsResultCode OBJECT-TYPE SYNTAX INTEGER { success(1), invalidParameters(2), rejectedWithSuggestedChanges(3), rejectedForDelayPeriod(4), rejectedForSspPermissions(5), rejectedWithSuggestedBssTransition (6), 3192 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications requestedTclasNotSupported (7), tclasResourcesExhausted (8), rejectedHomeWithSuggestedChanges (9) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the AP's HC after the AP transmits an ADDTS Response frame to the non-AP STA or after the AP includes a RIC element in a Reassociation Response frame. This attribute indicates the most recent result code returned by the AP in an ADDTS Response." ::= { dot11InterworkingEntry 51 } -- ********************************************************************** -- * End of dot11Interworking TABLE -- ********************************************************************** -- ********************************************************************** -- * dot11APLCI TABLE -- ********************************************************************** dot11APLCITable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11APLCIEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table represents the Geospatial location of the AP as specified in 9.4.2.22.10." ::= { dot11imt 3 } dot11APLCIEntry OBJECT-TYPE SYNTAX Dot11APLCIEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "AP location in geospatial coordinates" INDEX { dot11APLCIIndex } ::= { dot11APLCITable 1 } Dot11APLCIEntry ::= SEQUENCE { dot11APLCIIndex Unsigned32, dot11APLCILatitudeUncertainty Unsigned32, dot11APLCILatitudeInteger Integer32, dot11APLCILatitudeFraction Integer32, dot11APLCILongitudeUncertainty Unsigned32, dot11APLCILongitudeInteger Integer32, dot11APLCILongitudeFraction Integer32, dot11APLCIAltitudeType INTEGER, dot11APLCIAltitudeUncertainty Unsigned32, dot11APLCIAltitude Integer32, dot11APLCIDatum INTEGER, dot11APLCIAzimuthType INTEGER, dot11APLCIAzimuthResolution Unsigned32, dot11APLCIAzimuth Integer32 } dot11APLCIIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible 3193 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STATUS current DESCRIPTION "Index for AP LCI elements in dot11APLCITable, greater than 0." ::= { dot11APLCIEntry 1 } dot11APLCILatitudeUncertainty OBJECT-TYPE SYNTAX Unsigned32 (0..63) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Latitude uncertainty is defined in IETF RFC 6225." ::= { dot11APLCIEntry 2 } dot11APLCILatitudeInteger OBJECT-TYPE SYNTAX Integer32 (-90..90) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Latitude is a 34 bit fixed point value consisting of 9 bits of integer and 25 bits of fraction. This field contains the 9 bits of integer portion of Latitude." ::= { dot11APLCIEntry 3 } dot11APLCILatitudeFraction OBJECT-TYPE SYNTAX Integer32 (-16777215..16777215) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Latitude is a 34 bit fixed point value consisting of 9 bits of integer and 25 bits of fraction. This field contains the 25 bits of fraction portion of Latitude." ::= { dot11APLCIEntry 4 } dot11APLCILongitudeUncertainty OBJECT-TYPE SYNTAX Unsigned32 (0..63) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Longitude uncertainty is defined in IETF RFC 6225." ::= { dot11APLCIEntry 5 } dot11APLCILongitudeInteger OBJECT-TYPE SYNTAX Integer32 (-180..180) MAX-ACCESS read-write 3194 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Longitude is a 34 bit fixed point value consisting of 9 bits of integer and 25 bits of fraction. This field contains the 9 bits of integer portion of Longitude." ::= { dot11APLCIEntry 6 } dot11APLCILongitudeFraction OBJECT-TYPE SYNTAX Integer32 (-16777215..16777215) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Longitude is a 2s complement 34 bit fixed point value consisting of 9 bits of integer and 25 bits of fraction. This field contains the 25 bits of fraction portion of Longitude." ::= { dot11APLCIEntry 7 } dot11APLCIAltitudeType OBJECT-TYPE SYNTAX INTEGER { meters(1), floors(2), hagm (3) } MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Altitude Type is four bits encoding the type of altitude. Codes defined are: meters in 2s complement fixed-point 22-bit integer part with 8-bit fraction floors in 2s complement fixed-point 22-bit integer part with 8- bit fraction hagm: Height Above Ground in meters, in 2s complement fixed- point 22-bit integer part with 8-bit fraction." ::= { dot11APLCIEntry 8 } dot11APLCIAltitudeUncertainty OBJECT-TYPE SYNTAX Unsigned32 (0..63) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Altitude resolution is 6 bits indicating the number of valid bits in the altitude." ::= { dot11APLCIEntry 9 } dot11APLCIAltitude OBJECT-TYPE SYNTAX Integer32 (-536870912..536870911) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. 3195 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Altitude is a 30 bit value defined by the Altitude type field. The field is encoded as a 2s complement fixed-point 22-bit integer part with 8-bit fraction." ::= { dot11APLCIEntry 10 } -- Reserved: 11. Was dot11APLCIAltitudeFraction. dot11APLCIDatum OBJECT-TYPE SYNTAX INTEGER { wgs84 (1), nad83navd88 (2), nad93mllwvd (3) } MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Datum is a 3-bit value encoding the horizontal and vertical references used for the coordinates given in this LCI. IETF RFC 6225 defines the values of Datum. Type 1 is WGS-84, the coordinate system used by GPS. Type 2 is NAD83 with NAVD88 vertical reference. Type 3 is NAD83 with Mean Lower Low Water vertical datum. All other types are reserved." ::= { dot11APLCIEntry 12 } dot11APLCIAzimuthType OBJECT-TYPE SYNTAX INTEGER { frontSurfaceOfSTA(0), radioBeam(1) } MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Azimuth Type is a one bit attribute encoding the type of Azimuth. Codes defined are: front surface of STA: in 2s complement fixed-point 9-bit integer radio beam: in 2s complement fixed-point 9-bit integer." ::= { dot11APLCIEntry 13 } dot11APLCIAzimuthResolution OBJECT-TYPE SYNTAX Unsigned32 (0..15) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Azimuth Resolution is 4 bits indicating the number of valid bits in the azimuth." ::= { dot11APLCIEntry 14 } dot11APLCIAzimuth OBJECT-TYPE SYNTAX Integer32 (-511..511) MAX-ACCESS read-write 3196 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Azimuth is a 9 bit value defined by the Azimuth Type field.The field is encoded as a 2s complement fixed-point 9-bit integer horizontal angle in degrees from true north." ::= { dot11APLCIEntry 15 } -- ********************************************************************** -- * End of dot11APLCI TABLE -- ********************************************************************** -- ********************************************************************** -- * dot11APCivicLocation TABLE -- ********************************************************************** dot11APCivicLocationTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11ApCivicLocationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table represents the location of the AP in civic format using the Civic Address Type elements defined in IETF RFC 5139 [B47]." ::= { dot11imt 4 } dot11APCivicLocationEntry OBJECT-TYPE SYNTAX Dot11ApCivicLocationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Civic Address location of the AP described with Civic Address Type elements defined in IETF RFC 5139 [B47]." INDEX {dot11APCivicLocationIndex} ::= {dot11APCivicLocationTable 1} Dot11ApCivicLocationEntry ::= SEQUENCE { dot11APCivicLocationIndex Unsigned32, dot11APCivicLocationCountry OCTET STRING, dot11APCivicLocationA1 OCTET STRING, dot11APCivicLocationA2 OCTET STRING, dot11APCivicLocationA3 OCTET STRING, dot11APCivicLocationA4 OCTET STRING, dot11APCivicLocationA5 OCTET STRING, dot11APCivicLocationA6 OCTET STRING, dot11APCivicLocationPrd OCTET STRING, dot11APCivicLocationPod OCTET STRING, dot11APCivicLocationSts OCTET STRING, dot11APCivicLocationHno OCTET STRING, dot11APCivicLocationHns OCTET STRING, dot11APCivicLocationLmk OCTET STRING, dot11APCivicLocationLoc OCTET STRING, dot11APCivicLocationNam OCTET STRING, dot11APCivicLocationPc OCTET STRING, dot11APCivicLocationBld OCTET STRING, dot11APCivicLocationUnit OCTET STRING, dot11APCivicLocationFlr OCTET STRING, dot11APCivicLocationRoom OCTET STRING, dot11APCivicLocationPlc OCTET STRING, dot11APCivicLocationPcn OCTET STRING, dot11APCivicLocationPobox OCTET STRING, dot11APCivicLocationAddcode OCTET STRING, 3197 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11APCivicLocationSeat OCTET STRING, dot11APCivicLocationRd OCTET STRING, dot11APCivicLocationRdsec OCTET STRING, dot11APCivicLocationRdbr OCTET STRING, dot11APCivicLocationRdsubbr OCTET STRING, dot11APCivicLocationPrm OCTET STRING, dot11APCivicLocationPom OCTET STRING } dot11APCivicLocationIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Index for APCivicLocation elements in dot11APCivicLocationTable, greater than 0." ::= { dot11APCivicLocationEntry 1 } dot11APCivicLocationCountry OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute contains the two uppercase characters which correspond to the alpha-2 codes in ISO 3166-1. Example: US." ::= { dot11APCivicLocationEntry 2 } dot11APCivicLocationA1 OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute contains the national subdivisions (state, Region, province, prefecture). Example: California. The A1 element is used for the top level subdivision within a country. In the absence of a country- specific guide on how to use the A-series of elements, the second part of the ISO 3166-2 code for a country subdivision SHOULD be used. The ISO 3166-2 code is a formed of a country code and hyphen plus a code of one, two or three characters or numerals. For the A1 element, the leading country code and hyphen are omitted and only the subdivision code is included. For example, the codes for Canada include CA-BC, CA-ON, CA-QC; Luxembourg has just three single character codes: LU-D, LU-G And LU-L; Australia uses both two and three character codes: AU-ACT, AU-NSW, AU-NT; France uses numerical codes for mainland France and letters for territories: FR-75, FR-NC." ::= { dot11APCivicLocationEntry 3 } dot11APCivicLocationA2 OBJECT-TYPE 3198 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute contains the county, parish, gun (JP), district (IN). Example: King's County." ::= { dot11APCivicLocationEntry 4 } dot11APCivicLocationA3 OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute contains the city, township, shi (JP). Example: San Francisco." ::= { dot11APCivicLocationEntry 5 } dot11APCivicLocationA4 OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute contains the city division, borough, city district, ward, chou (JP). Example: Manhattan." ::= { dot11APCivicLocationEntry 6 } dot11APCivicLocationA5 OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute contains the neighborhood, block. Example: Morningside Heights." ::= { dot11APCivicLocationEntry 7 } dot11APCivicLocationA6 OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. 3199 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This attribute contains the street. Example: Broadway. The A6 element is retained for use in those countries that require this level of detail. Where A6 was previously used for street names in IETF RFC 5139 [B47], it will not be used, the RD element will be used for thoroughfare data. However, without additional information these fields will not be interchanged when converting between different civic formats. Where Civic address information is obtained from another format, such as the DHCP form IETF RFC 4776 [B44], the A6 element will be copied directly from the source format." ::= { dot11APCivicLocationEntry 8 } dot11APCivicLocationPrd OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute contains the leading street direction. Example: NW." ::= { dot11APCivicLocationEntry 9 } dot11APCivicLocationPod OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute contains the trailing street suffix. Example: SW." ::= { dot11APCivicLocationEntry 10 } dot11APCivicLocationSts OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute contains the street suffix. Example: Avenue, 'Platz, Street'." ::= { dot11APCivicLocationEntry 11 } dot11APCivicLocationHno OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute contains the numeric part only of the House number. Example: 123." 3200 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ::= { dot11APCivicLocationEntry 12 } dot11APCivicLocationHns OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute contains the house number suffix. Example: A, 1/2" ::= { dot11APCivicLocationEntry 13 } dot11APCivicLocationLmk OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute contains the landmark or vanity address. Example: Low Library." ::= { dot11APCivicLocationEntry 14 } dot11APCivicLocationLoc OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute contains additional location information. Example: Room 543." ::= { dot11APCivicLocationEntry 15 } dot11APCivicLocationNam OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute contains the name (residence, business, or office occupant. Example: Joe's Barbershop." ::= { dot11APCivicLocationEntry 16 } dot11APCivicLocationPc OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. 3201 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute contains the postal code. Example: 10027-0401." ::= { dot11APCivicLocationEntry 17 } dot11APCivicLocationBld OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute contains the building (structure). Example: Hope Theater." ::= { dot11APCivicLocationEntry 18 } dot11APCivicLocationUnit OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute contains the unit (apartment, suite). Example: 12a." ::= { dot11APCivicLocationEntry 19 } dot11APCivicLocationFlr OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute contains the floor number. Example: 5." ::= { dot11APCivicLocationEntry 20 } dot11APCivicLocationRoom OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute contains the room. Example: 450F." ::= { dot11APCivicLocationEntry 21 } dot11APCivicLocationPlc OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. 3202 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute contains the place type. Example: office." ::= { dot11APCivicLocationEntry 22 } dot11APCivicLocationPcn OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute contains the postal community name. Example: Leonia." ::= { dot11APCivicLocationEntry 23 } dot11APCivicLocationPobox OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute contains the post office box (P.O. Box). Example: U40." ::= { dot11APCivicLocationEntry 24 } dot11APCivicLocationAddcode OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute contains the additional code. Example: 13203000003." ::= { dot11APCivicLocationEntry 25 } dot11APCivicLocationSeat OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute contains the seat (desk, cubicle, workstation). Example: WS 181." ::= { dot11APCivicLocationEntry 26 } dot11APCivicLocationRd OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-write STATUS current 3203 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute contains the primary road or street. Example: Broadway." ::= { dot11APCivicLocationEntry 27 } dot11APCivicLocationRdsec OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute contains the road section. Example: 14.In some countries a thoroughfare can be broken up into sections, and it is not uncommon for street numbers to be repeated between sections. A road section identifier might be needed to make that an address unique. For example, West Alice Parade has 5 sections, each numbered from 1; unless the section is specified 7 West Alice Parade could exist in 5 different places." ::= { dot11APCivicLocationEntry 28 } dot11APCivicLocationRdbr OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute contains the road branch. Example: 'Lane 7'. Minor streets can share the same name, so that they can only Be distinguished by the major thoroughfare with which they intersect. For example, both West Alice Parade, Section 3 and Bob Street could both be interested by a Carol Lane. This element is used to specify a road branch where the name of the branch does not uniquely identify the road. Road branches MAY also be used where a major thoroughfare is split into sections." ::= { dot11APCivicLocationEntry 29 } dot11APCivicLocationRdsubbr OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute contains the road sub-branch. Example: Alley 8." ::= { dot11APCivicLocationEntry 30 } dot11APCivicLocationPrm OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION 3204 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute contains the road premodifier. Example: Old." ::= { dot11APCivicLocationEntry 31 } dot11APCivicLocationPom OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute contains the road post-modifier. Example: Extended." ::= { dot11APCivicLocationEntry 32 } -- ********************************************************************** -- * End of dot11APCivicLocation TABLE -- ********************************************************************** -- ********************************************************************** -- * dot11RoamingConsortium TABLE -- ********************************************************************** dot11RoamingConsortiumTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11RoamingConsortiumEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is a Table of OIs which are to be transmitted in an ANQP Roaming Consortium ANQP-element. Each table entry corresponds to a roaming consortium or single SSP. The first 3 entries in this table are transmitted in Beacon and Probe Response frames." ::= { dot11imt 5 } dot11RoamingConsortiumEntry OBJECT-TYPE SYNTAX Dot11RoamingConsortiumEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each OI identifies a roaming consortium (group of SSPs with inter-SSP roaming agreement) or a single SSP. A non-AP STA in possession of security credentials for the SSPN(s) identified by the OI should be able to successfully authenticate to this AP." INDEX { dot11RoamingConsortiumOI } ::= { dot11RoamingConsortiumTable 1 } Dot11RoamingConsortiumEntry ::= SEQUENCE { dot11RoamingConsortiumOI OCTET STRING, dot11RoamingConsortiumRowStatus RowStatus } dot11RoamingConsortiumOI OBJECT-TYPE SYNTAX OCTET STRING (SIZE(16)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. 3205 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute contains the IEEE defined OI as defined in 9.4.1.32." ::= { dot11RoamingConsortiumEntry 1 } dot11RoamingConsortiumRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object represents the status column for a conceptual row in this table." ::= { dot11RoamingConsortiumEntry 2 } -- ********************************************************************** -- * End of dot11RoamingConsortium TABLE -- ********************************************************************** -- ********************************************************************** -- * dot11DomainName TABLE -- ********************************************************************** dot11DomainNameTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11DomainNameEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is a table of Domain Names which form the Domain Name list in access network query protocol. The Domain Name list may be transmitted to a non- AP STA in a GAS Response. Each table entry corresponds to a single Domain Name." ::= { dot11imt 6 } dot11DomainNameEntry OBJECT-TYPE SYNTAX Dot11DomainNameEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. Each Domain Name identifies a domain names of the entity operating the IEEE 802.11 access network." INDEX { dot11DomainNameOui } ::= { dot11DomainNameTable 1 } Dot11DomainNameEntry ::= SEQUENCE { dot11DomainName OCTET STRING, dot11DomainNameRowStatus RowStatus, dot11DomainNameOui OCTET STRING } dot11DomainName OBJECT-TYPE SYNTAX OCTET STRING (SIZE(255)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. 3206 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This attribute contains a Domain Name of up to 255 octets formatted in accordance with the 'Preferred Name Syntax' as defined in IETF RFC 1035." ::= { dot11DomainNameEntry 1 } dot11DomainNameRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object represents the status column for a conceptual row in this table." ::= { dot11DomainNameEntry 2 } dot11DomainNameOui OBJECT-TYPE SYNTAX OCTET STRING (SIZE(3..5)) MAX-ACCESS read-write STATUS current DESCRIPTION "This object represents an IEEE assigned unique identifier (OUI, OUI-36 or CID), used as an index into the Domain Name table." ::= { dot11DomainNameEntry 3 } -- ********************************************************************** -- * End of dot11DomainName TABLE -- ********************************************************************** -- ********************************************************************** -- * dot11GASAdvertisement TABLE -- ********************************************************************** dot11GASAdvertisementTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11GASAdvertisementEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object is a table of GAS counters that allows for multiple instantiations of those counters on a STA." ::= { dot11imt 7 } dot11GASAdvertisementEntry OBJECT-TYPE SYNTAX Dot11GASAdvertisementEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object provides the attributes identifying a GAS counter within a STA." INDEX { dot11GASAdvertisementId } ::= { dot11GASAdvertisementTable 1 } Dot11GASAdvertisementEntry ::= SEQUENCE{ dot11GASAdvertisementId Unsigned32, dot11GASPauseForServerResponse TruthValue, dot11GASResponseTimeout Unsigned32, dot11GASComebackDelay Unsigned32, dot11GASResponseBufferingTime Unsigned32, dot11GASQueryResponseLengthLimit Unsigned32, dot11GASQueries Counter32, dot11GASQueryRate Gauge32, dot11GASResponses Counter32, dot11GASResponseRate Gauge32, dot11GASNoRequestOutstanding Counter32, dot11GASResponsesDiscarded Counter32, 3207 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11GASFailedResponses Counter32 } dot11GASAdvertisementId OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. The 1 octet identification number for the GAS Advertisement Protocol, as defined in Table 9-215, for which statistics are stored the logical row of the GASAdvertisement table." ::= { dot11GASAdvertisementEntry 1 } dot11GASPauseForServerResponse OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute is used only by the responding STA in a GAS exchange. When true, it indicates that the responding STA does not transmit a GAS Initial Response frame until it receives the query response from the Advertisement Server or a timeout occurs. When false, the STA does not wait for a response from the Advertisement Server before transmitting the GAS Initial Response frame. The setting of this MIB object is outside the scope of this standard." ::= { dot11GASAdvertisementEntry 2 } dot11GASResponseTimeout OBJECT-TYPE SYNTAX Unsigned32 (1000..65535) UNITS "TUs" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This parameter shall indicate the GAS response timeout value." DEFVAL {5000} ::= { dot11GASAdvertisementEntry 3 } dot11GASComebackDelay OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "TUs" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This object identifies the GAS Comeback Delay to be used for this 3208 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Advertisement Protocol" DEFVAL {1000} ::= { dot11GASAdvertisementEntry 4 } dot11GASResponseBufferingTime OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "TUs" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This object defines the time duration after the expiration of the GAS Comeback Delay that a STA will buffer a Query Response. Upon expiration of this time, the STA may discard the Query Response." DEFVAL {1000} ::= { dot11GASAdvertisementEntry 5 } dot11GASQueryResponseLengthLimit OBJECT-TYPE SYNTAX Unsigned32 (1..127) MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This object indicates the maximum number of octets an AP will transmit in one or more Query Response fields contained within GAS Comeback Response frame(s). A value of 127 means the maximum limit enforced is contained by the maximum allowable number of fragments in the GAS Query Fragment Response ID" ::= { dot11GASAdvertisementEntry 6 } dot11GASQueries OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME after transmission of an MLME-GAS.request or receipt of an MLME-GAS.indication primitive. The number of GAS queries sent or received for the protocol identified by dot11GASAdvertisementId." ::= { dot11GASAdvertisementEntry 7 } dot11GASQueryRate OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is updated by the SME after receipt of an MLME-GAS.indication primitive. The number of GAS queries per minute received for the protocol identified 3209 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications by dot11GASAdvertisementId, averaged over the previous ten minutes." ::= { dot11GASAdvertisementEntry 8 } dot11GASResponses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the SME after transmission of an MLME-GAS.response primitive or receipt of an MLME-GAS.confirm primitive. The number of GAS responses sent or received for the protocol identified by dot11GASAdvertisementId." ::= { dot11GASAdvertisementEntry 9 } dot11GASResponseRate OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is updated by the SME after transmission of an MLME-GAS.response primitive. The number of responses to GAS queries per minute transmitted by an AP for the protocol identified by dot11GASAdvertisementId, averaged over the previous ten minutes. This MIB variable is not used in non-AP STAs." ::= { dot11GASAdvertisementEntry 10 } dot11GASNoRequestOutstanding OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is updated by the SME after transmission of an MLME-GAS.response primitive. This counter shall be incremented each time a STA returns a status code of NO_OUTSTANDING_GAS_REQUEST in a GAS Initial Response or GAS Comeback Response frame for the protocol identified by dot11GASAdvertisementId." ::= { dot11GASAdvertisementEntry 13 } dot11GASResponsesDiscarded OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is updated by the SME after transmission of an MLME-GAS.response primitive. This counter shall be incremented each a STA discards a GAS response due to the expiration of the dot11GASResponseBufferingTime timer for the protocol identified by dot11GASAdvertisementId." ::= { dot11GASAdvertisementEntry 14 } dot11GASFailedResponses OBJECT-TYPE SYNTAX Counter32 3210 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is updated by the SME after transmission of an MLME-GAS.response primitive. This counter shall be incremented each time a STA commences transmitting a GAS response but fails to successfully complete the transmission of all GAS fragments in that response due to the expiratin of the dot11GASResponseTimeout timer for the protocol identified by dot11GASAdvertisementId." ::= { dot11GASAdvertisementEntry 15 } -- ********************************************************************** -- * End of dot11GASAdvertisement TABLE -- ********************************************************************** -- ********************************************************************** -- * MAC state generic convergence function -- ********************************************************************** -- MAC state generic convergence function attributes -- DEFINED AS "The MAC state generic convergence function object -- class provides the necessary support for support of event-driven -- triggers to higher layer protocols and the capabilities to -- support those triggers." dot11MSGCF OBJECT IDENTIFIER ::= { ieee802dot11 7} -- MAC state generic convergence function GROUPS -- dot11MACStateConfigTable ::= { dot11MSGCF 1 } -- dot11MACStateParameterTable ::= { dot11MSGCF 2 } -- dot11MACStateESSLinkTable ::= { dot11MSGCF 3 } -- ********************************************************************* -- * dot11ESSLinkIdentifier type definition -- ********************************************************************* Dot11ESSLinkIdentifier ::= OCTET STRING (SIZE(0..38)) -- This object type holds the identifier for an IEEE 802.11 -- network. It is composed of the SSID string concatenated -- with the HESSID, if present. -- ********************************************************************* -- * dot11MACStateConfig TABLE -- ********************************************************************* dot11MACStateConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11MACStateConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table holds configuration parameters for the IEEE 802.11 MAC state generic convergence function." ::= { dot11MSGCF 1 } dot11MACStateConfigEntry OBJECT-TYPE SYNTAX Dot11MACStateConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry represents a conceptual row in the dot11MACStateConfigTable and provides information about network configuration parameters used in 3211 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications the MAC state generic convergence function." INDEX { dot11MSCEESSLinkIdentifier, dot11MSCENonAPStationMacAddress } ::= { dot11MACStateConfigTable 1 } Dot11MACStateConfigEntry ::= SEQUENCE { dot11ESSDisconnectFilterInterval Unsigned32, dot11ESSLinkDetectionHoldInterval Unsigned32, dot11MSCEESSLinkIdentifier Dot11ESSLinkIdentifier, dot11MSCENonAPStationMacAddress MacAddress } dot11ESSDisconnectFilterInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "TUs" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute is set to the time that will elapse after an MLME- DISASSOCIATE.confirm or MLME-DEAUTHENTICATE.confirm primitive without a subsequent association before the link is declared down. This interval is intended to allow a non-AP STA time to transition to another AP within the same ESS before declaring that the link to the ESS is lost." ::= { dot11MACStateConfigEntry 1 } dot11ESSLinkDetectionHoldInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "TUs" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute is set to the time that an ESS is held in the dot11MACStateESSLink table after its last observation before purging the entry from the table." ::= { dot11MACStateConfigEntry 2 } dot11MSCEESSLinkIdentifier OBJECT-TYPE SYNTAX Dot11ESSLinkIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is an auxiliary variable used to identify instances of the columnar objects in the dot11MACStateConfigTable table." ::= { dot11MACStateConfigEntry 3 } dot11MSCENonAPStationMacAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is an auxiliary variable used to identify instances of the columnar objects in the dot11MACStateConfigTable table." 3212 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ::= { dot11MACStateConfigEntry 4 } -- ********************************************************************* -- * End of dot11MACStateConfig TABLE -- ********************************************************************* -- ********************************************************************* -- * dot11MACStateParameter TABLE -- ********************************************************************* dot11MACStateParameterTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11MACStateParameterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table holds the current parameters used for each IEEE 802.11 network for IEEE 802.11 MAC convergence functions." ::= { dot11MSGCF 2 } dot11MACStateParameterEntry OBJECT-TYPE SYNTAX Dot11MACStateParameterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry represents a conceptual row in the dot11MACStateParameterTable and provides information about link configuration parameters used in the MAC state generic convergence function." INDEX { dot11MSPEESSLinkIdentifier, dot11MSPENonAPStationMacAddress } ::= { dot11MACStateParameterTable 1 } Dot11MACStateParameterEntry ::= SEQUENCE { dot11ESSLinkDownTimeInterval Unsigned32, dot11ESSLinkRssiDataThreshold Unsigned32, dot11ESSLinkRssiBeaconThreshold Unsigned32, dot11ESSLinkDataSnrThreshold Unsigned32, dot11ESSLinkBeaconSnrThreshold Unsigned32, dot11ESSLinkBeaconFrameErrorRateThresholdInteger Unsigned32, dot11ESSLinkBeaconFrameErrorRateThresholdFraction Unsigned32, dot11ESSLinkBeaconFrameErrorRateThresholdExponent Unsigned32, dot11ESSLinkFrameErrorRateThresholdInteger Unsigned32, dot11ESSLinkFrameErrorRateThresholdFraction Unsigned32, dot11ESSLinkFrameErrorRateThresholdExponent Unsigned32, dot11PeakOperationalRate Unsigned32, dot11MinimumOperationalRate Unsigned32, dot11ESSLinkDataThroughputInteger Unsigned32, dot11ESSLinkDataThroughputFraction Unsigned32, dot11ESSLinkDataThroughputExponent Unsigned32, dot11MSPEESSLinkIdentifier Dot11ESSLinkIdentifier, dot11MSPENonAPStationMacAddress MacAddress } dot11ESSLinkDownTimeInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "TUs" MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. 3213 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications This attribute defines the time interval over which the MAC state generic convergence function will attempt to predict the failure of an IEEE 802.11 network. The convergence function should issue predicted network failure events at least this time interval before the network failure is detected." ::= { dot11MACStateParameterEntry 2 } dot11ESSLinkRssiDataThreshold OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute defines the threshold value for RSSI on Data frames. When the RSSI drops below this threshold, a report is issued." ::= { dot11MACStateParameterEntry 3 } dot11ESSLinkRssiBeaconThreshold OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute defines the threshold value for RSSI on Beacon frames. When the RSSI drops below this threshold, a report is issued." ::= { dot11MACStateParameterEntry 4 } dot11ESSLinkBeaconSnrThreshold OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute defines the threshold value for SNR on received Beacon frames. When the SNR drops below this threshold, a report is issued" ::= { dot11MACStateParameterEntry 5 } dot11ESSLinkDataSnrThreshold OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. This attribute defines the threshold value for SNR on received Data frames. When the SNR drops below this threshold, a report is issued." ::= { dot11MACStateParameterEntry 6 } dot11ESSLinkBeaconFrameErrorRateThresholdInteger OBJECT-TYPE 3214 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. The Beacon frame error rate is stored in scientific notation as a significant and exponent. This attribute contains the integer value of the significand." ::= { dot11MACStateParameterEntry 7 } dot11ESSLinkBeaconFrameErrorRateThresholdFraction OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. The Beacon frame error rate is stored in scientific notation as a significant and exponent. This attribute contains the fractional value of the significand." ::= { dot11MACStateParameterEntry 8 } dot11ESSLinkBeaconFrameErrorRateThresholdExponent OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. The Beacon frame error rate is stored in scientific notation as a significant and exponent. This attribute contains the integer value of the exponent." ::= { dot11MACStateParameterEntry 9 } dot11ESSLinkFrameErrorRateThresholdInteger OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. The frame error rate of the network is stored in scientific notation as a significant and exponent. This attribute contains the integer value of the significand." ::= { dot11MACStateParameterEntry 10 } dot11ESSLinkFrameErrorRateThresholdFraction OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION 3215 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. The frame error rate of the network is stored in scientific notation as a significant and exponent. This attribute contains the fractional value of the significand." ::= { dot11MACStateParameterEntry 11 } dot11ESSLinkFrameErrorRateThresholdExponent OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. The frame error rate of the network is stored in scientific notation as a significant and exponent. This attribute contains the integer value of the exponent." ::= { dot11MACStateParameterEntry 12 } dot11PeakOperationalRate OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. The highest operational rate used for transmission of Data frames, encoded as defined in 9.4.2.3." ::= { dot11MACStateParameterEntry 13 } dot11MinimumOperationalRate OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. The lowest operational rate used for transmission of Data frames, encoded as defined in 9.4.2.3." ::= { dot11MACStateParameterEntry 14 } dot11ESSLinkDataThroughputInteger OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. The data throughput rate is of the network is stored in scientific 3216 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications notation as a significant and exponent. This attribute contains the integer value of the significand." ::= { dot11MACStateParameterEntry 15 } dot11ESSLinkDataThroughputFraction OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. The data throughput rate is of the network is stored in scientific notation as a significant and exponent. This attribute contains the fractional value of the significand." ::= { dot11MACStateParameterEntry 16 } dot11ESSLinkDataThroughputExponent OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "This is a control variable. It is written by an external management entity or the SME. Changes take effect as soon as practical in the implementation. The data throughput rate is of the network is stored in scientific notation as a significant and exponent. This attribute contains the integer value of the exponent." ::= { dot11MACStateParameterEntry 17 } dot11MSPEESSLinkIdentifier OBJECT-TYPE SYNTAX Dot11ESSLinkIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is an auxiliary variable used to identify instances of the columnar objects in the dot11MACStateParameterTable table." ::= { dot11MACStateParameterEntry 18 } dot11MSPENonAPStationMacAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is an auxiliary variable used to identify instances of the columnar objects in the dot11MACStateParameterTable table." ::= { dot11MACStateParameterEntry 19 } -- ********************************************************************* -- * End of dot11MACStateParameter TABLE -- ********************************************************************* -- ********************************************************************* -- * dot11MACStateESSLink TABLE -- ********************************************************************* dot11MACStateESSLinkDetectedTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot11MACStateESSLinkDetectedEntry 3217 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table holds the detected IEEE 802.11 network list used for MAC convergence functions." ::= { dot11MSGCF 3 } dot11MACStateESSLinkDetectedEntry OBJECT-TYPE SYNTAX Dot11MACStateESSLinkDetectedEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry represents a conceptual row in the dot11MACStateESSLinkTable and provides information about available networks for use in the MAC state generic convergence function." INDEX { dot11MSELDEESSLinkIdentifier, dot11MSELDENonAPStationMacAddress } ::= { dot11MACStateESSLinkDetectedTable 1 } Dot11MACStateESSLinkDetectedEntry ::= SEQUENCE { dot11ESSLinkDetectedIndex Unsigned32, dot11ESSLinkDetectedNetworkId OCTET STRING, dot11ESSLinkDetectedNetworkDetectTime Unsigned32, dot11ESSLinkDetectedNetworkModifiedTime Unsigned32, dot11ESSLinkDetectedNetworkMIHCapabilities BITS, dot11MSELDEESSLinkIdentifier Dot11ESSLinkIdentifier, dot11MSELDENonAPStationMacAddress MacAddress } dot11ESSLinkDetectedIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index for ESSLinkDetected elements in dot11ESSLinkDetectedTable, greater than 0." ::= { dot11MACStateESSLinkDetectedEntry 1 } dot11ESSLinkDetectedNetworkId OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MSGCF after reception of an MSGCF-ESS-LINK- DETECTED.indication primitive. The string used to identify the network represented by this row in the table. It is composed of the SSID of the network concatenated with the HESSID, if present." ::= { dot11MACStateESSLinkDetectedEntry 2 } dot11ESSLinkDetectedNetworkDetectTime OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MSGCF after reception of an MSGCF-ESS-LINK- DETECTED.indication primitive. The STA's TSF timer when any BSSID supporting the network was first 3218 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications detected." ::= { dot11MACStateESSLinkDetectedEntry 4 } dot11ESSLinkDetectedNetworkModifiedTime OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MSGCF after reception of an MSGCF-ESS-LINK- DETECTED.indication primitive. The STA's TSF timer value when changes were made to any part of this row in the table, such as by addition of a BSSID to the BSSID list." ::= { dot11MACStateESSLinkDetectedEntry 5 } dot11ESSLinkDetectedNetworkMIHCapabilities OBJECT-TYPE SYNTAX BITS { mihIsSupport(0), mihCsEsSupport(1) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is a status variable. It is written by the MSGCF after reception of an MSGCF-ESS-LINK- DETECTED.indication primitive. The object reports whether the network supports IEEE 802.21 MIH information services and/or IEEE 802.21 MIH command/event services. These values are determined by examining the Interworking information in frames that caused the network to be detected." ::= { dot11MACStateESSLinkDetectedEntry 6 } dot11MSELDEESSLinkIdentifier OBJECT-TYPE SYNTAX Dot11ESSLinkIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is an auxiliary variable used to identify instances of the columnar objects in the dot11MACStateESSLinkDetectedTable table." ::= { dot11MACStateESSLinkDetectedEntry 7 } dot11MSELDENonAPStationMacAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is an auxiliary variable used to identify instances of the columnar objects in the dot11MACStateESSLinkDetectedTable table." ::= { dot11MACStateESSLinkDetectedEntry 8 } -- ********************************************************************* -- * End of dot11MACStateESSLink TABLE -- ********************************************************************* -- ********************************************************************** -- * Compliance Information -- ********************************************************************** 3219 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11Conformance OBJECT IDENTIFIER ::= { ieee802dot11 5 } dot11Groups OBJECT IDENTIFIER ::= { dot11Conformance 1 } dot11Compliances OBJECT IDENTIFIER ::= { dot11Conformance 2 } -- ********************************************************************** -- * Groups - units of compliance -- ********************************************************************** dot11SMTbase OBJECT-GROUP OBJECTS { dot11StationID, dot11MediumOccupancyLimit, dot11CFPollable, dot11CFPPeriod, dot11CFPMaxDuration, dot11AuthenticationResponseTimeout, dot11PrivacyOptionImplemented, dot11PowerManagementMode, dot11DesiredSSID, dot11DesiredBSSType, dot11OperationalRateSet, dot11BeaconPeriod, dot11DTIMPeriod, dot11AssociationResponseTimeout } STATUS deprecated DESCRIPTION "Superseded by dot11SMTbase2. The SMT object class provides the necessary support at the STA to manage the processes in the STA such that the STA may work cooperatively as a part of an IEEE 802.11 network." ::= { dot11Groups 1 } dot11SMTprivacy OBJECT-GROUP OBJECTS { dot11PrivacyInvoked, dot11WEPKeyMappingLengthImplemented, dot11ExcludeUnencrypted, dot11WEPICVErrorCount, dot11WEPExcludedCount, dot11WEPDefaultKeyID, dot11WEPDefaultKeyValue, dot11WEPKeyMappingWEPOn, dot11WEPKeyMappingValue, dot11WEPKeyMappingAddress, dot11WEPKeyMappingStatus } STATUS current DESCRIPTION "The SMTPrivacy package is a set of attributes that are present if WEP is implemented in the STA." ::= { dot11Groups 2 } dot11MACbase OBJECT-GROUP OBJECTS { dot11MACAddress, dot11GroupAddress, dot11GroupAddressesStatus, dot11RTSThreshold, dot11ShortRetryLimit, dot11LongRetryLimit, dot11FragmentationThreshold, dot11MaxTransmitMSDULifetime, dot11MaxReceiveLifetime, dot11ManufacturerID, dot11ProductID } STATUS deprecated 3220 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DESCRIPTION "Superseded by dot11MACbase2. The MAC object class provides the necessary support for the access control, generation, and verification of frame check sequences (FCSs), and proper delivery of valid data to upper layers." ::= { dot11Groups 3 } dot11MACStatistics OBJECT-GROUP OBJECTS { dot11RetryCount, dot11MultipleRetryCount, dot11RTSSuccessCount, dot11RTSFailureCount, dot11AckFailureCount, dot11FrameDuplicateCount } STATUS current DESCRIPTION "The MACStatistics package provides extended statistical information on the operation of the MAC. This package is completely optional." ::= { dot11Groups 4 } dot11ResourceTypeID OBJECT-GROUP OBJECTS { dot11ResourceTypeIDName, dot11manufacturerOUI, dot11manufacturerName, dot11manufacturerProductName, dot11manufacturerProductVersion } STATUS current DESCRIPTION "Attributes used to identify a STA, its manufacturer, and various product names and versions." ::= { dot11Groups 5 } dot11SmtAuthenticationAlgorithms OBJECT-GROUP OBJECTS { dot11AuthenticationAlgorithm, dot11AuthenticationAlgorithmActivated } STATUS current DESCRIPTION "Authentication Algorithm Table." ::= { dot11Groups 6 } dot11PhyOperationComplianceGroup OBJECT-GROUP OBJECTS { dot11PHYType, dot11CurrentRegDomain, dot11TempType } STATUS deprecated DESCRIPTION "Superseded by dot11PhyOperationComplianceGroup2. PHY operations attributes." ::= { dot11Groups 7 } dot11PhyAntennaComplianceGroup OBJECT-GROUP OBJECTS { dot11CurrentTxAntenna, dot11DiversitySupportImplemented, dot11CurrentRxAntenna } STATUS deprecated DESCRIPTION "Attributes for Data Rates for IEEE Std 802.11." ::= { dot11Groups 8 } dot11PhyTxPowerComplianceGroup OBJECT-GROUP OBJECTS { dot11NumberSupportedPowerLevelsImplemented, 3221 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11TxPowerLevel1, dot11TxPowerLevel2, dot11TxPowerLevel3, dot11TxPowerLevel4, dot11TxPowerLevel5, dot11TxPowerLevel6, dot11TxPowerLevel7, dot11TxPowerLevel8, dot11CurrentTxPowerLevel } STATUS current DESCRIPTION "Attributes for Control and Management of transmit power." ::= { dot11Groups 9 } dot11PhyDSSSComplianceGroup OBJECT-GROUP OBJECTS { dot11CurrentChannel, dot11CCAModeSupported, dot11CurrentCCAMode, dot11EDThreshold } STATUS current DESCRIPTION "Attributes that configure the DSSS PHY for IEEE Std 802.11." ::= { dot11Groups 11 } dot11PhyRegDomainsSupportGroup OBJECT-GROUP OBJECTS { dot11RegDomainsImplementedValue } STATUS deprecated DESCRIPTION "Attributes that specify the supported Regulation Domains." ::= { dot11Groups 13 } dot11PhyAntennasListGroup OBJECT-GROUP OBJECTS { dot11TxAntennaImplemented, dot11RxAntennaImplemented, dot11DiversitySelectionRxImplemented } STATUS current DESCRIPTION "Attributes that specify the supported Regulation Domains." ::= { dot11Groups 14 } dot11PhyRateGroup OBJECT-GROUP OBJECTS { dot11ImplementedDataRatesTxValue, dot11ImplementedDataRatesRxValue } STATUS current DESCRIPTION "Attributes for Data Rates for IEEE Std 802.11." ::= { dot11Groups 15 } dot11CountersGroup OBJECT-GROUP OBJECTS { dot11TransmittedFragmentCount, dot11GroupTransmittedFrameCount, dot11FailedCount, dot11ReceivedFragmentCount, dot11GroupReceivedFrameCount, dot11FCSErrorCount, dot11WEPUndecryptableCount, dot11TransmittedFrameCount } STATUS deprecated 3222 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DESCRIPTION "Superseded by dot11CountersGroup2. Attributes from the dot11CountersGroup that are not described in the dot11MACStatistics group. These objects are mandatory." ::= { dot11Groups 16 } dot11NotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { dot11Disassociate, dot11Deauthenticate, dot11AuthenticateFail, dot11Associate, dot11AssociateFailed, dot11Reassociate, dot11ReassociateFailed } STATUS current DESCRIPTION "IEEE 802.11 notifications" ::= { dot11Groups 17 } dot11SMTbase2 OBJECT-GROUP OBJECTS { dot11MediumOccupancyLimit, dot11CFPollable, dot11CFPPeriod, dot11CFPMaxDuration, dot11AuthenticationResponseTimeout, dot11PrivacyOptionImplemented, dot11PowerManagementMode, dot11DesiredSSID, dot11DesiredBSSType, dot11OperationalRateSet, dot11BeaconPeriod, dot11DTIMPeriod, dot11AssociationResponseTimeout, dot11DisassociateReason, dot11DisassociateStation, dot11DeauthenticateReason, dot11DeauthenticateStation, dot11AuthenticateFailStatus, dot11AuthenticateFailStation } STATUS deprecated DESCRIPTION "Superseded by dot11SMTbase3. The SMTbase2 object class provides the necessary support at the STA to manage the processes in the STA such that the STA may work cooperatively as a part of an IEEE 802.11 network." ::= { dot11Groups 18 } dot11PhyOFDMComplianceGroup OBJECT-GROUP OBJECTS { dot11CurrentFrequency, dot11TIThreshold, dot11FrequencyBandsImplemented, dot11ChannelStartingFactor } STATUS deprecated DESCRIPTION "Superseded by dot11PhyOFDMComplianceGroup2. Attributes that configure the OFDM PHY for IEEE Std 802.11." ::= { dot11Groups 19 } dot11SMTbase3 OBJECT-GROUP OBJECTS { dot11MediumOccupancyLimit, 3223 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11CFPollable, dot11CFPPeriod, dot11CFPMaxDuration, dot11AuthenticationResponseTimeout, dot11PrivacyOptionImplemented, dot11PowerManagementMode, dot11DesiredSSID, dot11DesiredBSSType, dot11OperationalRateSet, dot11BeaconPeriod, dot11DTIMPeriod, dot11AssociationResponseTimeout, dot11DisassociateReason, dot11DisassociateStation, dot11DeauthenticateReason, dot11DeauthenticateStation, dot11AuthenticateFailStatus, dot11AuthenticateFailStation, dot11MultiDomainCapabilityImplemented, dot11MultiDomainCapabilityActivated, dot11CountryString } STATUS deprecated DESCRIPTION "Superseded by dot11SMTbase4. The SMTbase3 object class provides the necessary support at the STA to manage the processes in the STA such that the STA may work cooperatively as a part of an IEEE 802.11 network, when the STA is capable of multidomain operation. This object group should be implemented when the multidomain capability option is implemented." ::= { dot11Groups 20 } dot11MultiDomainCapabilityGroup OBJECT-GROUP OBJECTS { dot11FirstChannelNumber, dot11NumberofChannels, dot11MaximumTransmitPowerLevel } STATUS current DESCRIPTION "The dot11MultiDomainCapabilityGroup object class provides the objects necessary to manage the channels usable by a STA, when the multidomain capability option is implemented." ::= { dot11Groups 21 } dot11PhyHRDSSSComplianceGroup OBJECT-GROUP OBJECTS { dot11CurrentChannel, dot11CCAModeSupported, dot11CurrentCCAMode, dot11EDThreshold, dot11ShortPreambleOptionImplemented, dot11HRCCAModeImplemented } STATUS current DESCRIPTION "Attributes that configure the HRDSSS PHY for IEEE Std 802.11." ::= { dot11Groups 23 } dot11PhyERPComplianceGroup OBJECT-GROUP OBJECTS { dot11CurrentChannel, dot11ShortPreambleOptionImplemented, dot11ShortSlotTimeOptionImplemented, dot11ShortSlotTimeOptionActivated } STATUS current DESCRIPTION 3224 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications "Attributes that configure the ERP." ::= { dot11Groups 24 } dot11RSNAadditions OBJECT-GROUP OBJECTS { dot11RSNAActivated, dot11RSNAPreauthenticationActivated } STATUS current DESCRIPTION "This object class provides the objects from the IEEE 802.11 MIB required to manage RSNA functionality. Note that additional objects for managing this functionality are located in the IEEE 802.11 RSN MIB." ::= { dot11Groups 25 } dot11SMTbase4 OBJECT-GROUP OBJECTS { dot11MediumOccupancyLimit, dot11CFPollable, dot11CFPPeriod, dot11CFPMaxDuration, dot11AuthenticationResponseTimeout, dot11PrivacyOptionImplemented, dot11PowerManagementMode, dot11DesiredSSID, dot11DesiredBSSType, dot11OperationalRateSet, dot11BeaconPeriod, dot11DTIMPeriod, dot11AssociationResponseTimeout, dot11DisassociateReason, dot11DisassociateStation, dot11DeauthenticateReason, dot11DeauthenticateStation, dot11AuthenticateFailStatus, dot11AuthenticateFailStation, dot11MultiDomainCapabilityImplemented, dot11MultiDomainCapabilityActivated, dot11CountryString, dot11RSNAOptionImplemented } STATUS deprecated DESCRIPTION "Superseded by dot11SMTbase5. The SMTbase4 object class provides the necessary support at the IEEE STA to manage the processes in the STA so that the STA may work cooperatively as a part of an IEEE 802.11 network." ::= { dot11Groups 26 } -- ******************************************************************** -- * Groups - units of compliance - RSN -- ******************************************************************** dot11RSNBase OBJECT-GROUP OBJECTS { dot11RSNAConfigVersion, dot11RSNAConfigPairwiseKeysImplemented, dot11RSNAConfigGroupCipher, dot11RSNAConfigGroupRekeyMethod, dot11RSNAConfigGroupRekeyTime, dot11RSNAConfigGroupRekeyPackets, dot11RSNAConfigGroupRekeyStrict, dot11RSNAConfigPSKValue, dot11RSNAConfigPSKPassPhrase, dot11RSNAConfigGroupUpdateCount, dot11RSNAConfigPairwiseUpdateCount, dot11RSNAConfigGroupCipherSize, dot11RSNAConfigPairwiseCipherImplemented, 3225 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11RSNAConfigPairwiseCipherActivated, dot11RSNAConfigPairwiseCipherSizeImplemented, dot11RSNAConfigAuthenticationSuiteImplemented, dot11RSNAConfigAuthenticationSuiteActivated, dot11RSNAConfigNumberOfPTKSAReplayCounters, dot11RSNAConfigSATimeout, dot11RSNAConfigNumberOfGTKSAReplayCounters, dot11RSNAAuthenticationSuiteSelected, dot11RSNAPairwiseCipherSelected, dot11RSNAGroupCipherSelected, dot11RSNAPMKIDUsed, dot11RSNAAuthenticationSuiteRequested, dot11RSNAPairwiseCipherRequested, dot11RSNAGroupCipherRequested, dot11RSNATKIPCounterMeasuresInvoked, dot11RSNA4WayHandshakeFailures, dot11RSNAStatsSTAAddress, dot11RSNAStatsVersion, dot11RSNAStatsSelectedPairwiseCipher, dot11RSNAStatsTKIPICVErrors, dot11RSNAStatsTKIPLocalMICFailures, dot11RSNAStatsTKIPRemoteMICFailures, dot11RSNAStatsCCMPReplays, dot11RSNAStatsCCMPDecryptErrors, dot11RSNAStatsTKIPReplays, dot11RSNAConfigSTKKeysImplemented, dot11RSNAConfigSTKCipher, dot11RSNAConfigSTKRekeyTime, dot11RSNAConfigSMKUpdateCount, dot11RSNAConfigSTKCipherSize, dot11RSNAConfigNumberOfSTKSAReplayCounters, dot11RSNAPairwiseSTKSelected, dot11RSNAPreauthenticationImplemented, dot11RSNASMKHandshakeFailures } STATUS current DESCRIPTION "The dot11RSNBase object class provides the necessary support for managing RSNA functionality in the STA." ::= { dot11Groups 27 } dot11RSNPMKcachingGroup OBJECT-GROUP OBJECTS { dot11RSNAConfigPMKLifetime, dot11RSNAConfigPMKReauthThreshold } STATUS current DESCRIPTION "The dot11RSNPMKcachingGroup object class provides the necessary support for managing PMKSA caching functionality in the STA." ::= { dot11Groups 28 } dot11RSNSMKcachingGroup OBJECT-GROUP OBJECTS { dot11RSNAConfigSMKLifetime, dot11RSNAConfigSMKReauthThreshold } STATUS deprecated DESCRIPTION "Deprecated because mechanisms for use of cached SMKSAs are not defined. The dot11RSNSMKcachingGroup object class provides the necessary support for managing SMKSA caching functionality in the STA." ::= { dot11Groups 29 } dot11SMTbase5 OBJECT-GROUP OBJECTS { dot11MediumOccupancyLimit, 3226 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11CFPollable, dot11CFPPeriod, dot11CFPMaxDuration, dot11AuthenticationResponseTimeout, dot11PrivacyOptionImplemented, dot11PowerManagementMode, dot11DesiredSSID, dot11DesiredBSSType, dot11OperationalRateSet, dot11BeaconPeriod, dot11DTIMPeriod, dot11AssociationResponseTimeout, dot11DisassociateReason, dot11DisassociateStation, dot11DeauthenticateReason, dot11DeauthenticateStation, dot11AuthenticateFailStatus, dot11AuthenticateFailStation, dot11MultiDomainCapabilityImplemented, dot11MultiDomainCapabilityActivated, dot11CountryString, dot11SpectrumManagementImplemented, dot11SpectrumManagementRequired, dot11RSNAOptionImplemented, dot11OperatingClassesImplemented, dot11OperatingClassesRequired } STATUS current DESCRIPTION "The SMTbase5 object class provides the necessary support at the STA to manage the processes in the STA so that the STA may work cooperatively as a part of an IEEE 802.11 network, when the STA is capable of multidomain operation. This object group should be implemented when the multidomain capability option is implemented." ::= { dot11Groups 30 } dot11MACbase2 OBJECT-GROUP OBJECTS { dot11MACAddress, dot11GroupAddress, dot11GroupAddressesStatus, dot11RTSThreshold, dot11ShortRetryLimit, dot11LongRetryLimit, dot11FragmentationThreshold, dot11MaxTransmitMSDULifetime, dot11MaxReceiveLifetime, dot11ManufacturerID, dot11ProductID, dot11CAPLimit, dot11HCCWmin, dot11HCCWmax, dot11HCCAIFSN, dot11ADDBAResponseTimeout, dot11ADDTSResponseTimeout, dot11ChannelUtilizationBeaconIntervals, dot11ScheduleTimeout, dot11DLSResponseTimeout, dot11QAPMissingAckRetryLimit, dot11EDCAAveragingPeriod } STATUS deprecated DESCRIPTION "Superseded by dot11MACbase3. The MAC object class provides the necessary support for the access control, generation, and verification of frame check sequences (FCSs), and proper delivery of valid data to upper layers." ::= { dot11Groups 31 } 3227 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11CountersGroup2 OBJECT-GROUP OBJECTS { dot11TransmittedFragmentCount, dot11GroupTransmittedFrameCount, dot11FailedCount, dot11ReceivedFragmentCount, dot11GroupReceivedFrameCount, dot11FCSErrorCount, dot11WEPUndecryptableCount, dot11TransmittedFrameCount, dot11QosDiscardedFragmentCount, dot11AssociatedStationCount, dot11QosCFPollsReceivedCount, dot11QosCFPollsUnusedCount, dot11QosCFPollsUnusableCount } STATUS deprecated DESCRIPTION "Superseded by dot11CountersGroup3. Attributes from the dot11CountersGroup that are not described in the dot11MACStatistics group. These objects are mandatory." ::= { dot11Groups 32 } dot11Qosadditions OBJECT-GROUP OBJECTS { -- dot11EDCATable, dot11EDCATableCWmin, dot11EDCATableCWmax, dot11EDCATableAIFSN, dot11EDCATableTXOPLimit, dot11EDCATableMSDULifetime, dot11EDCATableMandatory, -- dot11QAPEDCATable, dot11QAPEDCATableCWmin, dot11QAPEDCATableCWmax, dot11QAPEDCATableAIFSN, dot11QAPEDCATableTXOPLimit, dot11QAPEDCATableMSDULifetime, dot11QAPEDCATableMandatory, -- dot11QosCountersTable dot11QosTransmittedFragmentCount, dot11QosFailedCount, dot11QosRetryCount, dot11QosMultipleRetryCount, dot11QosFrameDuplicateCount, dot11QosRTSSuccessCount, dot11QosRTSFailureCount, dot11QosAckFailureCount, dot11QosReceivedFragmentCount, dot11QosTransmittedFrameCount, dot11QosDiscardedFrameCount, dot11QosMPDUsReceivedCount, dot11QosRetriesReceivedCount } STATUS current DESCRIPTION "This object class provides the objects from the IEEE 802.11 MIB required to manage QoS functionality." ::= { dot11Groups 33 } dot11SMTbase6 OBJECT-GROUP OBJECTS { dot11MediumOccupancyLimit, 3228 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11CFPollable, dot11CFPPeriod, dot11CFPMaxDuration, dot11AuthenticationResponseTimeout, dot11PrivacyOptionImplemented, dot11PowerManagementMode, dot11DesiredSSID, dot11DesiredBSSType, dot11OperationalRateSet, dot11BeaconPeriod, dot11DTIMPeriod, dot11AssociationResponseTimeout, dot11DisassociateReason, dot11DisassociateStation, dot11DeauthenticateReason, dot11DeauthenticateStation, dot11AuthenticateFailStatus, dot11AuthenticateFailStation, dot11MultiDomainCapabilityImplemented, dot11MultiDomainCapabilityActivated, dot11CountryString, dot11RSNAOptionImplemented, dot11OperatingClassesImplemented, dot11OperatingClassesRequired, dot11QosOptionImplemented, dot11ImmediateBlockAckOptionImplemented, dot11DelayedBlockAckOptionImplemented, dot11DirectOptionImplemented, dot11APSDOptionImplemented, dot11QAckOptionImplemented, dot11QBSSLoadImplemented, dot11QueueRequestOptionImplemented, dot11TXOPRequestOptionImplemented, dot11MoreDataAckOptionImplemented, dot11AssociateInNQBSS, dot11DLSAllowedInQBSS, dot11DLSAllowed } STATUS deprecated DESCRIPTION "Superseded by dot11SMTbase7. The SMTbase6 object class provides the necessary support at the STA to manage the processes in the STA such that the STA may work cooperatively as a part of an IEEE 802.11 network." ::= { dot11Groups 34 } dot11PhyOFDMComplianceGroup2 OBJECT-GROUP OBJECTS { dot11CurrentFrequency, dot11TIThreshold, dot11FrequencyBandsImplemented, dot11ChannelStartingFactor, dot11FiveMHzOperationImplemented, dot11TenMHzOperationImplemented, dot11TwentyMHzOperationImplemented, dot11PhyOFDMChannelWidth } STATUS deprecated DESCRIPTION "Superseded by dot11PhyOFDMComplianceGroup3. Attributes that configure the OFDM PHY for IEEE Std 802.11." ::= { dot11Groups 35} dot11SMTbase7 OBJECT-GROUP OBJECTS{ dot11MediumOccupancyLimit, 3229 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11CFPollable, dot11CFPPeriod, dot11CFPMaxDuration, dot11AuthenticationResponseTimeout, dot11PrivacyOptionImplemented, dot11PowerManagementMode, dot11DesiredSSID, dot11DesiredBSSType, dot11OperationalRateSet, dot11BeaconPeriod, dot11DTIMPeriod, dot11AssociationResponseTimeout, dot11DisassociateReason, dot11DisassociateStation, dot11DeauthenticateReason, dot11DeauthenticateStation, dot11AuthenticateFailStatus, dot11AuthenticateFailStation, dot11MultiDomainCapabilityImplemented, dot11MultiDomainCapabilityActivated, dot11CountryString, dot11SpectrumManagementImplemented, dot11SpectrumManagementRequired, dot11RSNAOptionImplemented, dot11OperatingClassesImplemented, dot11OperatingClassesRequired, dot11QosOptionImplemented, dot11ImmediateBlockAckOptionImplemented, dot11DelayedBlockAckOptionImplemented, dot11DirectOptionImplemented, dot11APSDOptionImplemented, dot11QAckOptionImplemented, dot11QBSSLoadImplemented, dot11QueueRequestOptionImplemented, dot11TXOPRequestOptionImplemented, dot11MoreDataAckOptionImplemented, dot11AssociateInNQBSS, dot11DLSAllowedInQBSS, dot11DLSAllowed, dot11AssociateStation, dot11AssociateID, dot11AssociateFailStation, dot11AssociateFailStatus, dot11ReassociateStation, dot11ReassociateID, dot11ReassociateFailStation, dot11ReassociateFailStatus, dot11RadioMeasurementImplemented, dot11RadioMeasurementActivated, dot11RMMeasurementNavSync, dot11RMMeasurementPilotPeriod, dot11RMLinkMeasurementActivated, dot11RMNeighborReportActivated, dot11RMParallelMeasurementsActivated, dot11RMRepeatedMeasurementsActivated, dot11RMBeaconPassiveMeasurementActivated, dot11RMBeaconActiveMeasurementActivated, dot11RMBeaconTableMeasurementActivated, dot11RMBeaconMeasurementReportingConditionsActivated, dot11RMFrameMeasurementActivated, dot11RMChannelLoadMeasurementActivated, dot11RMNoiseHistogramMeasurementActivated, dot11RMStatisticsMeasurementActivated, dot11RMLCIMeasurementActivated, 3230 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11RMLCIAzimuthActivated, dot11RMTransmitStreamCategoryMeasurementActivated, dot11RMTriggeredTransmitStreamCategoryMeasurementActivated, dot11RMAPChannelReportActivated, dot11RMMIBActivated, dot11RMMaxMeasurementDuration, dot11RMNonOperatingChannelMaxMeasurementDuration, dot11RMMeasurementPilotTransmissionInformationActivated, dot11RMMeasurementPilotActivated, dot11RMNeighborReportTSFOffsetActivated, dot11RMRCPIMeasurementActivated, dot11RMRSNIMeasurementActivated, dot11RMBSSAverageAccessDelayActivated, dot11RMBSSAvailableAdmissionCapacityActivated, dot11RMAntennaInformationActivated} STATUS deprecated DESCRIPTION "Superseded by dot11SMTbase8. The SMTbase7 object class provides the necessary support at the STA to manage the processes in the STA such that the STA may work cooperatively as a part of an IEEE 802.11 network, when the STA is capable of multidomain operation. This object group should be implemented when the multidomain capability option is implemented." ::= { dot11Groups 36 } dot11SMTRMRequest OBJECT-GROUP OBJECTS { dot11RMRqstRowStatus, dot11RMRqstToken, dot11RMRqstRepetitions, dot11RMRqstIfIndex, dot11RMRqstType, dot11RMRqstTargetAdd, dot11RMRqstTimeStamp, dot11RMRqstChanNumber, dot11RMRqstOperatingClass, dot11RMRqstRndInterval, dot11RMRqstDuration, dot11RMRqstParallel, dot11RMRqstEnable, dot11RMRqstRequest, dot11RMRqstReport, dot11RMRqstDurationMandatory, dot11RMRqstBeaconRqstMode, dot11RMRqstBeaconRqstDetail, dot11RMRqstFrameRqstType, dot11RMRqstBssid, dot11RMRqstSSID, dot11RMRqstBeaconReportingCondition, dot11RMRqstBeaconThresholdOffset, dot11RMRqstSTAStatRqstGroupID, dot11RMRqstLCIRqstSubject, dot11RMRqstLCIAzimuthType, dot11RMRqstLCIAzimuthResolution, dot11RMRqstPauseTime, dot11RMRqstTransmitStreamPeerQSTAAddress, dot11RMRqstTransmitStreamTrafficIdentifier, dot11RMRqstTransmitStreamBin0Range, dot11RMRqstTrigdQoSAverageCondition, dot11RMRqstTrigdQoSConsecutiveCondition, dot11RMRqstTrigdQoSDelayCondition, dot11RMRqstTrigdQoSAverageThreshold, dot11RMRqstTrigdQoSConsecutiveThreshold, dot11RMRqstTrigdQoSDelayThresholdRange, 3231 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11RMRqstTrigdQoSDelayThreshold, dot11RMRqstTrigdQoSMeasurementCount, dot11RMRqstTrigdQoSTimeout, dot11RMRqstChannelLoadReportingCondition, dot11RMRqstChannelLoadReference, dot11RMRqstNoiseHistogramReportingCondition, dot11RMRqstAnpiReference, dot11RMRqstAPChannelReport, dot11RMRqstSTAStatPeerSTAAddress, dot11RMRqstFrameTransmitterAddress, dot11RMRqstVendorSpecific } STATUS current DESCRIPTION "The SMTRMRequest package is a set of attributes that are present if the STA supports the Radio Measurement service." ::= { dot11Groups 37 } dot11SMTRMReport OBJECT-GROUP OBJECTS { dot11ChannelLoadRprtRqstToken, dot11ChannelLoadRprtIfIndex, dot11ChannelLoadMeasuringSTAAddr, dot11ChannelLoadRprtChanNumber, dot11ChannelLoadRprtOperatingClass, dot11ChannelLoadRprtActualStartTime, dot11ChannelLoadRprtMeasurementDuration, dot11ChannelLoadRprtChannelLoad, dot11ChannelLoadRprtVendorSpecific, dot11ChannelLoadRprtMeasurementMode, dot11NoiseHistogramRprtRqstToken, dot11NoiseHistogramRprtIfIndex, dot11NoiseHistogramMeasuringSTAAddr, dot11NoiseHistogramRprtChanNumber, dot11NoiseHistogramRprtOperatingClass, dot11NoiseHistogramRprtActualStartTime, dot11NoiseHistogramRprtMeasurementDuration, dot11NoiseHistogramRprtAntennaID, dot11NoiseHistogramRprtANPI, dot11NoiseHistogramRprtIPIDensity0, dot11NoiseHistogramRprtIPIDensity1, dot11NoiseHistogramRprtIPIDensity2, dot11NoiseHistogramRprtIPIDensity3, dot11NoiseHistogramRprtIPIDensity4, dot11NoiseHistogramRprtIPIDensity5, dot11NoiseHistogramRprtIPIDensity6, dot11NoiseHistogramRprtIPIDensity7, dot11NoiseHistogramRprtIPIDensity8, dot11NoiseHistogramRprtIPIDensity9, dot11NoiseHistogramRprtIPIDensity10, dot11NoiseHistogramRprtVendorSpecific, dot11NoiseHistogramRprtMeasurementMode, dot11BeaconRprtRqstToken, dot11BeaconRprtIfIndex, dot11BeaconMeasuringSTAAddr, dot11BeaconRprtChanNumber, dot11BeaconRprtOperatingClass, dot11BeaconRprtActualStartTime, dot11BeaconRprtMeasurementDuration, dot11BeaconRprtPhyType, dot11BeaconRprtReportedFrameType, dot11BeaconRprtRCPI, dot11BeaconRprtRSNI, dot11BeaconRprtBSSID, dot11BeaconRprtAntennaID, 3232 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11BeaconRprtParentTSF, dot11BeaconRprtReportedFrameBody, dot11BeaconRprtVendorSpecific, dot11BeaconRprtMeasurementMode, dot11FrameRprtIfIndex, dot11FrameRprtRqstToken, dot11FrameRprtChanNumber, dot11FrameRprtOperatingClass, dot11FrameRprtActualStartTime, dot11FrameRprtMeasurementDuration, dot11FrameRprtTransmitSTAAddress, dot11FrameRprtBSSID, dot11FrameRprtPhyType, dot11FrameRprtAvgRCPI, dot11FrameRprtLastRSNI, dot11FrameRprtLastRCPI, dot11FrameRprtAntennaID, dot11FrameRprtNumberFrames, dot11FrameRprtVendorSpecific, dot11FrameRptMeasurementMode, dot11STAStatisticsReportToken, dot11STAStatisticsIfIndex, dot11STAStatisticsSTAAddress, dot11STAStatisticsMeasurementDuration, dot11STAStatisticsGroupID, dot11STAStatisticsTransmittedFragmentCount, dot11STAStatisticsGroupTransmittedFrameCount, dot11STAStatisticsFailedCount, dot11STAStatisticsRetryCount, dot11STAStatisticsMultipleRetryCount, dot11STAStatisticsFrameDuplicateCount, dot11STAStatisticsRTSSuccessCount, dot11STAStatisticsRTSFailureCount, dot11STAStatisticsAckFailureCount, dot11STAStatisticsQosTransmittedFragmentCount, dot11STAStatisticsQosFailedCount, dot11STAStatisticsQosRetryCount, dot11STAStatisticsQosMultipleRetryCount, dot11STAStatisticsQosFrameDuplicateCount, dot11STAStatisticsQosRTSSuccessCount, dot11STAStatisticsQosRTSFailureCount, dot11STAStatisticsQosAckFailureCount, dot11STAStatisticsQosReceivedFragmentCount, dot11STAStatisticsQosTransmittedFrameCount, dot11STAStatisticsQosDiscardedFrameCount, dot11STAStatisticsQosMPDUsReceivedCount, dot11STAStatisticsQosRetriesReceivedCount, dot11STAStatisticsReceivedFragmentCount, dot11STAStatisticsGroupReceivedFrameCount, dot11STAStatisticsFCSErrorCount, dot11STAStatisticsTransmittedFrameCount, dot11STAStatisticsAPAverageAccessDelay, dot11STAStatisticsAverageAccessDelayBestEffort, dot11STAStatisticsAverageAccessDelayBackground, dot11STAStatisticsAverageAccessDelayVideo, dot11STAStatisticsAverageAccessDelayVoice, dot11STAStatisticsStationCount, dot11STAStatisticsChannelUtilization, dot11STAStatisticsVendorSpecific, dot11STAStatisticsRprtMeasurementMode, dot11LCIReportToken, dot11LCIIfIndex, dot11LCISTAAddress, dot11LCILatitudeUncertainty, 3233 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11LCILatitudeInteger, dot11LCILatitudeFraction, dot11LCILongitudeUncertainty, dot11LCILongitudeInteger, dot11LCILongitudeFraction, dot11LCIAltitudeType, dot11LCIAltitudeUncertainty, dot11LCIAltitude, dot11LCIDatum, dot11LCIAzimuthType, dot11LCIAzimuthResolution, dot11LCIAzimuth, dot11LCIVendorSpecific, dot11LCIRprtMeasurementMode, dot11TransmitStreamRprtRqstToken, dot11TransmitStreamRprtIfIndex, dot11TransmitStreamMeasuringSTAAddr, dot11TransmitStreamRprtActualStartTime, dot11TransmitStreamRprtMeasurementDuration, dot11TransmitStreamRprtPeerSTAAddress, dot11TransmitStreamRprtTID, dot11TransmitStreamRprtAverageQueueDelay, dot11TransmitStreamRprtAverageTransmitDelay, dot11TransmitStreamRprtTransmittedMSDUCount, dot11TransmitStreamRprtMSDUDiscardedCount, dot11TransmitStreamRprtMSDUFailedCount, dot11TransmitStreamRprtMultipleRetryCount, dot11TransmitStreamRprtCFPollsLostCount, dot11TransmitStreamRprtBin0Range, dot11TransmitStreamRprtDelayHistogram, dot11TransmitStreamRprtReason, dot11TransmitStreamRprtVendorSpecific, dot11TransmitStreamRprtMeasurementMode } STATUS current DESCRIPTION "The SMTRMReport package is a set of attributes that are present if the STA supports the Radio Measurement service." ::= { dot11Groups 38 } dot11SMTRMConfig OBJECT-GROUP OBJECTS { dot11APChannelReportIfIndex, dot11APChannelReportOperatingClass, dot11APChannelReportChannelList, dot11RMNeighborReportIfIndex, dot11RMNeighborReportBSSID, dot11RMNeighborReportAPReachability, dot11RMNeighborReportSecurity, dot11RMNeighborReportCapSpectrumMgmt, dot11RMNeighborReportCapQoS, dot11RMNeighborReportCapAPSD, dot11RMNeighborReportCapRM, dot11RMNeighborReportCapDelayBlockAck, dot11RMNeighborReportCapImmediateBlockAck, dot11RMNeighborReportKeyScope, dot11RMNeighborReportChannelNumber, dot11RMNeighborReportOperatingClass, dot11RMNeighborReportPhyType, dot11RMNeighborReportNeighborTSFInfo, dot11RMNeighborReportPilotInterval, dot11RMNeighborReportPilotMultipleBSSID, dot11RMNeighborReportRMEnabledCapabilities, dot11RMNeighborReportVendorSpecific, dot11RMNeighborReportRowStatus, 3234 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11RMNeighborReportCapHT, dot11RMNeighborReportHTLDPCCodingCap, dot11RMNeighborReportHTSupportedChannelWidthSet, dot11RMNeighborReportHTSMPowerSave, dot11RMNeighborReportHTGreenfield, dot11RMNeighborReportHTShortGIfor20MHz, dot11RMNeighborReportHTShortGIfor40MHz, dot11RMNeighborReportHTTxSTBC, dot11RMNeighborReportHTRxSTBC, dot11RMNeighborReportHTDelayedBlockAck, dot11RMNeighborReportHTMaxAMSDULength, dot11RMNeighborReportHTDSSCCKModein40MHz, dot11RMNeighborReportHTFortyMHzIntolerant, dot11RMNeighborReportHTLSIGTXOPProtectionSupport, dot11RMNeighborReportHTMaxAMPDULengthExponent, dot11RMNeighborReportHTMinMPDUStartSpacing, dot11RMNeighborReportHTRxMCSBitMask, dot11RMNeighborReportHTRxHighestSupportedDataRate, dot11RMNeighborReportHTTxMCSSetDefined, dot11RMNeighborReportHTTxRxMCSSetNotEqual, dot11RMNeighborReportHTTxMaxNumberSpatialStreamsSupported, dot11RMNeighborReportHTTxUnequalModulationSupported, dot11RMNeighborReportHTPCO, dot11RMNeighborReportHTPCOTransitionTime, dot11RMNeighborReportHTMCSFeedback, dot11RMNeighborReportHTCSupport, dot11RMNeighborReportHTRDResponder, dot11RMNeighborReportHTImplictTransmitBeamformingReceivingCap, dot11RMNeighborReportHTReceiveStaggeredSoundingCap, dot11RMNeighborReportHTTransmitStaggeredSoundingCap, dot11RMNeighborReportHTReceiveNDPCap, dot11RMNeighborReportHTTransmitNDPCap, dot11RMNeighborReportHTImplicitTransmitBeamformingCap, dot11RMNeighborReportHTTransmitBeamformingCalibration, dot11RMNeighborReportHTExplicitCSITransmitBeamformingCap, dot11RMNeighborReportHTExplicitNonCompressedSteeringCap, dot11RMNeighborReportHTExplicitCompressedSteeringCap, dot11RMNeighborReportHTExplicitTransmitBeamformingFeedback, dot11RMNbRprtHTExplicitNonCompressedBeamformingFeedbackCap, dot11RMNeighborReportHTExplicitCompressedBeamformingFeedbackCap, dot11RMNeighborReportHTTransmitBeamformingMinimalGrouping, dot11RMNbRprtHTCSINumberofTxBeamformingAntennasSuppt, dot11RMNbRprtHTNonCompressedSteeringNumofTxBmfmingAntennasSuppt, dot11RMNbRprtHTCompressedSteeringNumberofTxBmfmingAntennasSuppt, dot11RMNbRprtHTCSIMaxNumberofRowsTxBeamformingSuppt, dot11RMNeighborReportHTTransmitBeamformingChannelEstimationCap, dot11RMNeighborReportHTAntSelectionCap, dot11RMNeighborReportHTExplicitCSIFeedbackBasedTxASELCap, dot11RMNeighborReportHTAntIndicesFeedbackBasedTxASELCap, dot11RMNeighborReportHTExplicitCSIFeedbackBasedCap, dot11RMNeighborReportHTAntIndicesFeedbackCap, dot11RMNeighborReportHTRxASELCap, dot11RMNeighborReportHTTxSoundingPPDUsCap, dot11RMNeighborReportHTInfoPrimaryChannel, dot11RMNeighborReportHTInfoSecChannelOffset, dot11RMNeighborReportHTInfoSTAChannelWidth, dot11RMNeighborReportHTInfoRIFSMode, dot11RMNeighborReportHTInfoProtection, dot11RMNeighborReportHTInfoNonGreenfieldHTSTAsPresent, dot11RMNeighborReportHTInfoOBSSNonHTSTAsPresent, dot11RMNeighborReportHTInfoDualBeacon, dot11RMNeighborReportHTInfoDualCTSProtection, dot11RMNeighborReportHTInfoSTBCBeacon, dot11RMNeighborReportHTInfoLSIGTXOPProtectionSup, 3235 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11RMNeighborReportHTInfoPCOActive, dot11RMNeighborReportHTInfoPCOPhase, dot11RMNeighborReportHTInfoBasicMCSSet, dot11RMNeighborReportHTSecChannelOffset, dot11RMNeighborReportExtCapPSMPSupport, dot11RMNeighborReportExtCapSPSMPSup, dot11RMNeighborReportExtCapServiceIntervalGranularity } STATUS current DESCRIPTION "The SMTRMConfig package is a set of attributes that are present if the STA supports the Radio Measurement service." ::= { dot11Groups 39 } dot11FTComplianceGroup OBJECT-GROUP OBJECTS { -- Dot11FastBSSTransitionConfigEntry dot11FastBSSTransitionActivated, dot11FTMobilityDomainID, dot11FTOverDSActivated, dot11FTResourceRequestSupported, dot11FTR0KeyHolderID, dot11FTR0KeyLifetime, dot11FTR1KeyHolderID, dot11FTReassociationDeadline, -- Dot11RMNeighborReportEntry dot11RMNeighborReportMobilityDomain } STATUS current DESCRIPTION "This object class provides the objects from the IEEE 802.11 MIB required to manage fast BSS transition functionality. Note that additional objects for managing this functionality are located in the dot11FastBSS TransitionConfigTable." ::= { dot11Groups 40} dot11SMTbase8 OBJECT-GROUP OBJECTS { dot11MediumOccupancyLimit, dot11CFPollable, dot11CFPPeriod, dot11CFPMaxDuration, dot11AuthenticationResponseTimeout, dot11PrivacyOptionImplemented, dot11PowerManagementMode, dot11DesiredSSID, dot11DesiredBSSType, dot11OperationalRateSet, dot11BeaconPeriod, dot11DTIMPeriod, dot11AssociationResponseTimeout, dot11DisassociateReason, dot11DisassociateStation, dot11DeauthenticateReason, dot11DeauthenticateStation, dot11AuthenticateFailStatus, dot11AuthenticateFailStation, dot11MultiDomainCapabilityImplemented, dot11MultiDomainCapabilityActivated, dot11CountryString, dot11SpectrumManagementImplemented, dot11SpectrumManagementRequired, dot11RSNAOptionImplemented, dot11OperatingClassesImplemented, dot11OperatingClassesRequired, dot11QosOptionImplemented, dot11ImmediateBlockAckOptionImplemented, dot11DelayedBlockAckOptionImplemented, 3236 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11DirectOptionImplemented, dot11APSDOptionImplemented, dot11QAckOptionImplemented, dot11QBSSLoadImplemented, dot11QueueRequestOptionImplemented, dot11TXOPRequestOptionImplemented, dot11MoreDataAckOptionImplemented, dot11AssociateInNQBSS, dot11DLSAllowedInQBSS, dot11DLSAllowed, dot11AssociateStation, dot11AssociateID, dot11AssociateFailStation, dot11AssociateFailStatus, dot11ReassociateStation, dot11ReassociateID, dot11ReassociateFailStation, dot11ReassociateFailStatus, dot11RadioMeasurementImplemented, dot11RadioMeasurementActivated, dot11RMMeasurementNavSync, dot11RMMeasurementPilotPeriod, dot11RMLinkMeasurementActivated, dot11RMNeighborReportActivated, dot11RMParallelMeasurementsActivated, dot11RMRepeatedMeasurementsActivated, dot11RMBeaconPassiveMeasurementActivated, dot11RMBeaconActiveMeasurementActivated, dot11RMBeaconTableMeasurementActivated, dot11RMBeaconMeasurementReportingConditionsActivated, dot11RMFrameMeasurementActivated, dot11RMChannelLoadMeasurementActivated, dot11RMNoiseHistogramMeasurementActivated, dot11RMStatisticsMeasurementActivated, dot11RMLCIMeasurementActivated, dot11RMLCIAzimuthActivated, dot11RMTransmitStreamCategoryMeasurementActivated, dot11RMTriggeredTransmitStreamCategoryMeasurementActivated, dot11RMAPChannelReportActivated, dot11RMMIBActivated, dot11RMMaxMeasurementDuration, dot11RMNonOperatingChannelMaxMeasurementDuration, dot11RMMeasurementPilotTransmissionInformationActivated, dot11RMMeasurementPilotActivated, dot11RMNeighborReportTSFOffsetActivated, dot11RMRCPIMeasurementActivated, dot11RMRSNIMeasurementActivated, dot11RMBSSAverageAccessDelayActivated, dot11RMBSSAvailableAdmissionCapacityActivated, dot11RMAntennaInformationActivated, dot11FastBSSTransitionImplemented } STATUS deprecated DESCRIPTION "Superseded by dot11SMTbase9. The SMTbase8 object class provides the necessary support at the STA to manage the processes in the STA so that the STA may work cooperatively as a part of an IEEE 802.11 network, when the STA is capable of multidomain operation. This object group should be implemented when the multidomain capability option is implemented." ::= { dot11Groups 41 } dot11PhyOFDMComplianceGroup3 OBJECT-GROUP OBJECTS { dot11CurrentFrequency, 3237 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11FrequencyBandsImplemented, dot11ChannelStartingFactor, dot11FiveMHzOperationImplemented, dot11TenMHzOperationImplemented, dot11TwentyMHzOperationImplemented, dot11PhyOFDMChannelWidth, dot11OFDMCCAEDImplemented, dot11OFDMCCAEDRequired, dot11OFDMEDThreshold, dot11STATransmitPowerClass, dot11ACRType } STATUS current DESCRIPTION "Attributes that configure the OFDM PHY for IEEE Std 802.11." ::= { dot11Groups 42} dot11SMTbase9 OBJECT-GROUP OBJECTS { dot11MediumOccupancyLimit, dot11CFPollable, dot11CFPPeriod, dot11CFPMaxDuration, dot11AuthenticationResponseTimeout, dot11PrivacyOptionImplemented, dot11PowerManagementMode, dot11DesiredSSID, dot11DesiredBSSType, dot11OperationalRateSet, dot11BeaconPeriod, dot11DTIMPeriod, dot11AssociationResponseTimeout, dot11DisassociateReason, dot11DisassociateStation, dot11DeauthenticateReason, dot11DeauthenticateStation, dot11AuthenticateFailStatus, dot11AuthenticateFailStation, dot11MultiDomainCapabilityImplemented, dot11MultiDomainCapabilityActivated, dot11CountryString, dot11RSNAOptionImplemented, dot11OperatingClassesImplemented, dot11OperatingClassesRequired, dot11QosOptionImplemented, dot11ImmediateBlockAckOptionImplemented, dot11DelayedBlockAckOptionImplemented, dot11DirectOptionImplemented, dot11APSDOptionImplemented, dot11QAckOptionImplemented, dot11QBSSLoadImplemented, dot11QueueRequestOptionImplemented, dot11TXOPRequestOptionImplemented, dot11MoreDataAckOptionImplemented, dot11AssociateInNQBSS, dot11DLSAllowedInQBSS, dot11DLSAllowed, dot11RadioMeasurementImplemented, dot11RadioMeasurementActivated, dot11FastBSSTransitionImplemented, dot11LCIDSEImplemented, dot11LCIDSERequired, dot11DSERequired, dot11ExtendedChannelSwitchActivated } STATUS deprecated DESCRIPTION "Superseded by dot11SMTbase10. 3238 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The SMTbase9 object class provides the necessary support at the STA to manage the processes in the STA such that the STA may work cooperatively as a part of an IEEE 802.11 network, when the STA is capable of multidomain operation. This object group should be implemented when the multidomain capability option is implemented." ::= { dot11Groups 43 } dot11PhyAntennaComplianceGroup2 OBJECT-GROUP OBJECTS { dot11CurrentTxAntenna, dot11DiversitySupportImplemented, dot11CurrentRxAntenna, dot11AntennaSelectionOptionImplemented, dot11TransmitExplicitCSIFeedbackASOptionImplemented, dot11TransmitIndicesFeedbackASOptionImplemented, dot11ExplicitCSIFeedbackASOptionImplemented, dot11TransmitIndicesComputationASOptionImplemented, dot11ReceiveAntennaSelectionOptionImplemented } STATUS current DESCRIPTION "Attributes for Data Rates for IEEE Std 802.11." ::= { dot11Groups 44 } dot11MACbase3 OBJECT-GROUP OBJECTS { dot11MACAddress, dot11GroupAddress, dot11GroupAddressesStatus, dot11RTSThreshold, dot11ShortRetryLimit, dot11LongRetryLimit, dot11FragmentationThreshold, dot11MaxTransmitMSDULifetime, dot11MaxReceiveLifetime, dot11ManufacturerID, dot11ProductID, dot11CAPLimit, dot11HCCWmin, dot11HCCWmax, dot11HCCAIFSN, dot11ADDBAResponseTimeout, dot11ADDTSResponseTimeout, dot11ChannelUtilizationBeaconIntervals, dot11ScheduleTimeout, dot11DLSResponseTimeout, dot11QAPMissingAckRetryLimit, dot11EDCAAveragingPeriod, dot11HTProtection, dot11RIFSMode, dot11PSMPControlledAccess, dot11ServiceIntervalGranularity, dot11DualCTSProtection, dot11LSIGTXOPFullProtectionActivated, dot11NonGFEntitiesPresent, dot11PCOActivated, dot11PCOFortyMaxDuration, dot11PCOTwentyMaxDuration, dot11PCOFortyMinDuration, dot11PCOTwentyMinDuration } STATUS deprecated DESCRIPTION "Superseded by dot11MACbase4. The MAC object class provides the necessary support for the access control, generation, and verification of frame check sequences (FCSs), and proper delivery of valid data to upper layers." 3239 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ::= { dot11Groups 45 } dot11CountersGroup3 OBJECT-GROUP OBJECTS { dot11TransmittedFragmentCount, dot11TransmittedFrameCount, dot11FailedCount, dot11ReceivedFragmentCount, dot11GroupReceivedFrameCount, dot11FCSErrorCount, dot11WEPUndecryptableCount, dot11TransmittedFrameCount, dot11QosDiscardedFragmentCount, dot11AssociatedStationCount, dot11QosCFPollsReceivedCount, dot11QosCFPollsUnusedCount, dot11QosCFPollsUnusableCount, dot11QosCFPollsLostCount, dot11TransmittedAMSDUCount, dot11FailedAMSDUCount, dot11RetryAMSDUCount, dot11MultipleRetryAMSDUCount, dot11TransmittedOctetsInAMSDUCount, dot11AMSDUAckFailureCount, dot11ReceivedAMSDUCount, dot11ReceivedOctetsInAMSDUCount, dot11TransmittedAMPDUCount, dot11TransmittedMPDUsInAMPDUCount, dot11TransmittedOctetsInAMPDUCount, dot11AMPDUReceivedCount, dot11MPDUInReceivedAMPDUCount, dot11ReceivedOctetsInAMPDUCount, dot11AMPDUDelimiterCRCErrorCount, dot11ImplicitBARFailureCount, dot11ExplicitBARFailureCount, dot11ChannelWidthSwitchCount, dot11TwentyMHzFrameTransmittedCount, dot11FortyMHzFrameTransmittedCount, dot11TwentyMHzFrameReceivedCount, dot11FortyMHzFrameReceivedCount, dot11PSMPUTTGrantDuration, dot11PSMPUTTUsedDuration, dot11GrantedRDGUsedCount, dot11GrantedRDGUnusedCount, dot11TransmittedFramesInGrantedRDGCount, dot11TransmittedOctetsInGrantedRDGCount, dot11BeamformingFrameCount, dot11DualCTSSuccessCount, dot11DualCTSFailureCount, dot11STBCCTSSuccessCount, dot11STBCCTSFailureCount, dot11nonSTBCCTSSuccessCount, dot11nonSTBCCTSFailureCount, dot11RTSLSIGSuccessCount, dot11RTSLSIGFailureCount } STATUS deprecated DESCRIPTION "Superseded by dot11CountersGroup4. Attributes from the dot11CountersGroup that are not described in the dot11MACStatistics group. These objects are mandatory." ::= { dot11Groups 46 } dot11SMTbase10 OBJECT-GROUP OBJECTS { 3240 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11MediumOccupancyLimit, dot11CFPollable, dot11CFPPeriod, dot11CFPMaxDuration, dot11AuthenticationResponseTimeout, dot11PrivacyOptionImplemented, dot11PowerManagementMode, dot11DesiredSSID, dot11DesiredBSSType, dot11OperationalRateSet, dot11BeaconPeriod, dot11DTIMPeriod, dot11AssociationResponseTimeout, dot11DisassociateReason, dot11DisassociateStation, dot11DeauthenticateReason, dot11DeauthenticateStation, dot11AuthenticateFailStatus, dot11AuthenticateFailStation, dot11MultiDomainCapabilityImplemented, dot11MultiDomainCapabilityActivated, dot11CountryString, dot11RSNAOptionImplemented, dot11OperatingClassesImplemented, dot11OperatingClassesRequired, dot11QosOptionImplemented, dot11ImmediateBlockAckOptionImplemented, dot11DelayedBlockAckOptionImplemented, dot11DirectOptionImplemented, dot11APSDOptionImplemented, dot11QAckOptionImplemented, dot11QBSSLoadImplemented, dot11QueueRequestOptionImplemented, dot11TXOPRequestOptionImplemented, dot11MoreDataAckOptionImplemented, dot11AssociateInNQBSS, dot11DLSAllowedInQBSS, dot11DLSAllowed, dot11AssociateStation, dot11AssociateID, dot11AssociateFailStation, dot11AssociateFailStatus, dot11ReassociateStation, dot11ReassociateID, dot11ReassociateFailStation, dot11ReassociateFailStatus, dot11RadioMeasurementImplemented, dot11RadioMeasurementActivated, dot11FastBSSTransitionImplemented, dot11LCIDSEImplemented, dot11LCIDSERequired, dot11DSERequired, dot11ExtendedChannelSwitchActivated, dot11HighThroughputOptionImplemented, dot11RSNAPBACRequired, dot11PSMPOptionImplemented } STATUS deprecated DESCRIPTION "Superceded by dot11SMTbase 11. The SMTbase10 object class provides the necessary support at the STA to manage the processes in the STA such that the STA may work cooperatively as a part of an IEEE 802.11 network." ::= { dot11Groups 47 } 3241 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11PhyMCSGroup OBJECT-GROUP OBJECTS { dot11SupportedMCSTxValue, dot11SupportedMCSRxValue } STATUS current DESCRIPTION "Attributes for MCS for IEEE 802.11 HT." ::= { dot11Groups 48 } dot11PhyHTComplianceGroup OBJECT-GROUP OBJECTS { dot11HighThroughputOptionImplemented, dot11FortyMHzOperationImplemented, dot11FortyMHzOperationActivated, dot11FortyMHzIntolerant, dot11FortyMHzOptionImplemented, dot11CurrentPrimaryChannel, dot11CurrentSecondaryChannel, dot11HTGreenfieldOptionImplemented, dot11HTGreenfieldOptionActivated, dot11ShortGIOptionInTwentyImplemented, dot11ShortGIOptionInTwentyActivated, dot11ShortGIOptionInFortyImplemented, dot11ShortGIOptionInFortyActivated, dot11LDPCCodingOptionImplemented, dot11LDPCCodingOptionActivated, dot11TxSTBCOptionImplemented, dot11TxSTBCOptionActivated, dot11RxSTBCOptionImplemented, dot11RxSTBCOptionActivated, dot11BeamFormingOptionImplemented, dot11BeamFormingOptionActivated, dot11NumberOfSpatialStreamsImplemented, dot11NumberOfSpatialStreamsActivated, dot11HighestSupportedDataRate, dot11TxMCSSetDefined, dot11TxRxMCSSetNotEqual, dot11TxMaximumNumberSpatialStreamsSupported, dot11TxUnequalModulationSupported, dot11TransmitSoundingPPDUOptionImplemented, dot11NumberOfActiveRxAntennas } STATUS current DESCRIPTION "Attributes that configure the HT PHY for IEEE Std 802.11." ::= { dot11Groups 49 } dot11HTMACAdditions OBJECT-GROUP OBJECTS { dot11HTOperationalMCSSet, dot11MIMOPowerSave, dot11NDelayedBlockAckOptionImplemented, dot11MaxAMSDULength, dot11STBCControlFrameOptionImplemented, dot11LsigTxopProtectionOptionImplemented, dot11MaxRxAMPDUFactor, dot11MinimumMPDUStartSpacing, dot11PCOOptionImplemented, dot11TransitionTime, dot11MCSFeedbackOptionImplemented, dot11HTControlFieldSupported, dot11RDResponderOptionImplemented, dot11BSSWidthTriggerScanInterval, dot11BSSWidthChannelTransitionDelayFactor, dot11OBSSScanPassiveDwell, 3242 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11OBSSScanActiveDwell, dot11OBSSScanPassiveTotalPerChannel, dot11OBSSScanActiveTotalPerChannel, dot112040BSSCoexistenceManagementSupport, dot11OBSSScanActivityThreshold, dot11SPPAMSDUCapable, dot11SPPAMSDURequired } STATUS deprecated DESCRIPTION "Deprecated as contains an object no longer used by IEEE Std 802.11-2016 Attributes that configure the HT PHY for IEEE Std 802.11." ::= { dot11Groups 50 } dot11TransmitBeamformingGroup OBJECT-GROUP OBJECTS { dot11ReceiveStaggerSoundingOptionImplemented, dot11TransmitStaggerSoundingOptionImplemented, dot11ReceiveNDPOptionImplemented, dot11TransmitNDPOptionImplemented, dot11ImplicitTransmitBeamformingOptionImplemented, dot11CalibrationOptionImplemented, dot11ExplicitCSITransmitBeamformingOptionImplemented, dot11ExplicitNonCompressedBeamformingMatrixOptionImplemented, dot11ExplicitTransmitBeamformingCSIFeedbackOptionImplemented, dot11ExplicitNonCompressedBeamformingFeedbackOptionImplemented, dot11ExplicitCompressedBeamformingFeedbackOptionImplemented, dot11NumberBeamFormingCSISupportAntenna, dot11NumberNonCompressedBeamformingMatrixSupportAntenna, dot11NumberCompressedBeamformingMatrixSupportAntenna } STATUS current DESCRIPTION "Attributes that configure the Beamforming for IEEE 802.11 HT." ::= { dot11Groups 51 } dot11SMTbase11 OBJECT-GROUP OBJECTS { dot11MediumOccupancyLimit, dot11CFPollable, dot11CFPPeriod, dot11CFPMaxDuration, dot11AuthenticationResponseTimeout, dot11PrivacyOptionImplemented, dot11PowerManagementMode, dot11DesiredSSID, dot11DesiredBSSType, dot11OperationalRateSet, dot11BeaconPeriod, dot11DTIMPeriod, dot11AssociationResponseTimeout, dot11DisassociateReason, dot11DisassociateStation, dot11DeauthenticateReason, dot11DeauthenticateStation, dot11AuthenticateFailStatus, dot11AuthenticateFailStation, dot11MultiDomainCapabilityImplemented, dot11MultiDomainCapabilityActivated, dot11CountryString, dot11SpectrumManagementImplemented, dot11SpectrumManagementRequired, dot11RSNAOptionImplemented, dot11OperatingClassesImplemented, dot11OperatingClassesRequired, 3243 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11QosOptionImplemented, dot11ImmediateBlockAckOptionImplemented, dot11DelayedBlockAckOptionImplemented, dot11DirectOptionImplemented, dot11APSDOptionImplemented, dot11QAckOptionImplemented, dot11QBSSLoadImplemented, dot11QueueRequestOptionImplemented, dot11TXOPRequestOptionImplemented, dot11MoreDataAckOptionImplemented, dot11AssociateInNQBSS, dot11DLSAllowedInQBSS, dot11DLSAllowed, dot11AssociateStation, dot11AssociateID, dot11AssociateFailStation, dot11AssociateFailStatus, dot11ReassociateStation, dot11ReassociateID, dot11ReassociateFailStation, dot11ReassociateFailStatus, dot11RadioMeasurementImplemented, dot11RadioMeasurementActivated, dot11RMMeasurementNavSync, dot11RMMeasurementPilotPeriod, dot11RMLinkMeasurementActivated, dot11RMNeighborReportActivated, dot11RMParallelMeasurementsActivated, dot11RMRepeatedMeasurementsActivated, dot11RMBeaconPassiveMeasurementActivated, dot11RMBeaconActiveMeasurementActivated, dot11RMBeaconTableMeasurementActivated, dot11RMBeaconMeasurementReportingConditionsActivated, dot11RMFrameMeasurementActivated, dot11RMChannelLoadMeasurementActivated, dot11RMNoiseHistogramMeasurementActivated, dot11RMStatisticsMeasurementActivated, dot11RMLCIMeasurementActivated, dot11RMLCIAzimuthActivated, dot11RMTransmitStreamCategoryMeasurementActivated, dot11RMTriggeredTransmitStreamCategoryMeasurementActivated, dot11RMAPChannelReportActivated, dot11RMMIBActivated, dot11RMMaxMeasurementDuration, dot11RMNonOperatingChannelMaxMeasurementDuration, dot11RMMeasurementPilotTransmissionInformationActivated, dot11RMMeasurementPilotActivated, dot11RMNeighborReportTSFOffsetActivated, dot11RMRCPIMeasurementActivated, dot11RMRSNIMeasurementActivated, dot11RMBSSAverageAccessDelayActivated, dot11RMBSSAvailableAdmissionCapacityActivated, dot11FastBSSTransitionImplemented, dot11LCIDSEImplemented, dot11LCIDSERequired, dot11DSERequired, dot11ExtendedChannelSwitchActivated, dot11HighThroughputOptionImplemented, dot11WirelessManagementImplemented, dot11RSNAPBACRequired, dot11PSMPOptionImplemented } STATUS deprecated DESCRIPTION "Superseded by dot11SMTbase12. 3244 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The SMTbase11 object class provides the necessary support at the STA to manage the processes in the STA so that the STA may work cooperatively as a part of an IEEE 802.11 network, when the STA is capable of multidomain operation. This object group should be implemented when the multidomain capability option is implemented." ::= { dot11Groups 53 } dot11SMTWNMRequest OBJECT-GROUP OBJECTS { dot11WNMRqstRowSta- tus, dot11WNMRqstToken, dot11WNMRqstIfIndex, dot11WNMRqstType, dot11WNMRqstTargetAdd, dot11WNMRqstTimeStamp, dot11WNMRqstRndInterval, dot11WNMRqstDuration, dot11WNMRqstMcstGroup, dot11WNMRqstMcstTrigCon, dot11WNMRqstMcstTrigInactivityTimeout, dot11WNMRqstMcstTrigReactDelay, dot11WNMRqstLCRRqstSubject, dot11WNMRqstLCRIntervalUnits, dot11WNMRqstLCRServiceInterval, dot11WNMRqstLIRRqstSubject, dot11WNMRqstLIRIntervalUnits, dot11WNMRqstLIRServiceInterval, dot11WNMRqstEventToken, dot11WNMRqstEventType, dot11WNMRqstEventResponseLimit, dot11WNMRqstEventTargetBssid, dot11WNMRqstEventSourceBssid, dot11WNMRqstEventTransitTimeThresh, dot11WNMRqstEventTransitMatchValue, dot11WNMRqstEventFreqTransitCountThresh, dot11WNMRqstEventFreqTransitInterval, dot11WNMRqstEventRsnaAuthType, dot11WNMRqstEapType, dot11WNMRqstEapVendorId, dot11WNMRqstEapVendorType, dot11WNMRqstEventRsnaMatchValue, dot11WNMRqstEventPeerMacAddress, dot11WNMRqstOperatingClass, dot11WNMRqstChanNumber, dot11WNMRqstDiagToken, dot11WNMRqstDiagType, dot11WNMRqstDiagTimeout, dot11WNMRqstDiagBssid, dot11WNMRqstDiagProfileId, dot11WNMRqstDiagCredentials, dot11WNMRqstLocConfigLocIndParams, dot11WNMRqstLocConfigChanList, dot11WNMRqstLocConfigBcastRate, dot11WNMRqstLocConfigOptions, dot11WNMRqstBssTransitQueryReason, dot11WNMRqstBssTransitReqMode, dot11WNMRqstBssTransitDisocTimer, dot11WNMRqstBssTransitSessInfoURL, dot11WNMRqstBssTransitCandidateList, dot11WNMRqstColocInterfAutoEnable, dot11WNMRqstColocInterfRptTimeout, dot11WNMRqstVendorSpecific } STATUS current DESCRIPTION 3245 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications "The SMTWNMRequest package is a set of attributes that shall be present if the STA supports the WNM service." ::= { dot11Groups 54 } dot11SMTWNMReport OBJECT-GROUP OBJECTS { dot11WNMVendorSpecificRprtRqstToken, dot11WNMVendorSpecificRprtIfIndex, dot11WNMVendorSpecificRprtContent, dot11WNMMulticastDiagnosticRprtRqstToken, dot11WNMMulticastDiagnosticRprtIfIndex, dot11WNMMulticastDiagnosticRprtMeasurementTime, dot11WNMMulticastDiagnosticRprtDuration, dot11WNMMulticastDiagnosticRprtMcstGroup, dot11WNMMulticastDiagnosticRprtReason, dot11WNMMulticastDiagnosticRprtRcvdMsduCount, dot11WNMMulticastDiagnosticRprtFirstSeqNumber, dot11WNMMulticastDiagnosticRprtLastSeqNumber, dot11WNMMulticastDiagnosticRprtMcstRate, dot11WNMLocationCivicRprtRqstToken, dot11WNMLocationCivicRprtIfIndex, dot11WNMLocationCivicRprtCivicLocation, dot11WNMLocationIdentifierRprtRqstToken, dot11WNMLocationIdentifierRprtIfIndex, dot11WNMLocationIdentifierRprtExpirationTSF, dot11WNMLocationIdentifierRprtPublicIdUri, dot11WNMEventTransitRprtRqstToken, dot11WNMEventTransitRprtIfIndex, dot11WNMEventTransitRprtEventStatus, dot11WNMEventTransitRprtEventTSF, dot11WNMEventTransitRprtUTCOffset, dot11WNMEventTransitRprtTimeError, dot11WNMEventTransitRprtSourceBssid, dot11WNMEventTransitRprtTargetBssid, dot11WNMEventTransitRprtTransitTime, dot11WNMEventTransitRprtTransitReason, dot11WNMEventTransitRprtTransitResult, dot11WNMEventTransitRprtSourceRCPI, dot11WNMEventTransitRprtSourceRSNI, dot11WNMEventTransitRprtTargetRCPI, dot11WNMEventTransitRprtTargetRSNI, dot11WNMEventRsnaRprtRqstToken, dot11WNMEventRsnaRprtIfIndex, dot11WNMEventRsnaRprtEventStatus, dot11WNMEventRsnaRprtEventTSF, dot11WNMEventRsnaRprtUTCOffset, dot11WNMEventRsnaRprtTimeError, dot11WNMEventRsnaRprtTargetBssid, dot11WNMEventRsnaRprtAuthType, dot11WNMEventRsnaRprtEapMethod, dot11WNMEventRsnaRprtResult, dot11WNMEventRsnaRprtRsnElement, dot11WNMEventPeerRprtRqstToken, dot11WNMEventPeerRprtIfIndex, dot11WNMEventPeerRprtEventStatus, dot11WNMEventPeerRprtEventTSF, dot11WNMEventPeerRprtUTCOffset, dot11WNMEventPeerRprtTimeError, dot11WNMEventPeerRprtPeerMacAddress, dot11WNMEventPeerRprtOperatingClass, dot11WNMEventPeerRprtChanNumber, dot11WNMEventPeerRprtStaTxPower, dot11WNMEventPeerRprtConnTime, dot11WNMEventPeerRprtPeerStatus, 3246 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11WNMEventWNMLogRprtRqstToken, dot11WNMEventWNMLogRprtIfIndex, dot11WNMEventWNMLogRprtEventStatus, dot11WNMEventWNMLogRprtEventTSF, dot11WNMEventWNMLogRprtUTCOffset, dot11WNMEventWNMLogRprtTimeError, dot11WNMEventWNMLogRprtContent, dot11WNMDiagMfrInfoRprtRqstToken, dot11WNMDiagMfrInfoRprtIfIndex, dot11WNMDiagMfrInfoRprtEventStatus, dot11WNMDiagMfrInfoRprtMfrOi, dot11WNMDiagMfrInfoRprtMfrIdString, dot11WNMDiagMfrInfoRprtMfrModelString, dot11WNMDiagMfrInfoRprtMfrSerialNumberString, dot11WNMDiagMfrInfoRprtMfrFirmwareVersion, dot11WNMDiagMfrInfoRprtMfrAntennaType, dot11WNMDiagMfrInfoRprtCollocRadioType, dot11WNMDiagMfrInfoRprtDeviceType, dot11WNMDiagMfrInfoRprtCertificateID, dot11WNMDiagConfigProfRprtRqstToken, dot11WNMDiagConfigProfRprtIfIndex, dot11WNMDiagConfigProfRprtEventStatus, dot11WNMDiagConfigProfRprtProfileId, dot11WNMDiagConfigProfRprtSupportedOperatingClasses, dot11WNMDiagConfigProfRprtTxPowerMode, dot11WNMDiagConfigProfRprtTxPowerLevels, dot11WNMDiagConfigProfRprtCipherSuite, dot11WNMDiagConfigProfRprtAkmSuite, dot11WNMDiagConfigProfRprtEapType, dot11WNMDiagConfigProfRprtEapVendorID, dot11WNMDiagConfigProfRprtEapVendorType, dot11WNMDiagConfigProfRprtCredentialType, dot11WNMDiagConfigProfRprtSSID, dot11WNMDiagConfigProfRprtPowerSaveMode, dot11WNMDiagAssocRprtRqstToken, dot11WNMDiagAssocRprtIfIndex, dot11WNMDiagAssocRprtEventStatus, dot11WNMDiagAssocRprtBssid, dot11WNMDiagAssocRprtOperatingClass, dot11WNMDiagAssocRprtChannelNumber, dot11WNMDiagAssocRprtStatusCode, dot11WNMDiag8021xAuthRprtRqstToken, dot11WNMDiag8021xAuthRprtIfIndex, dot11WNMDiag8021xAuthRprtEventStatus, dot11WNMDiag8021xAuthRprtBssid, dot11WNMDiag8021xAuthRprtOperatingClass, dot11WNMDiag8021xAuthRprtChannelNumber, dot11WNMDiag8021xAuthRprtEapType, dot11WNMDiag8021xAuthRprtEapVendorID, dot11WNMDiag8021xAuthRprtEapVendorType, dot11WNMDiag8021xAuthRprtCredentialType, dot11WNMDiag8021xAuthRprtStatusCode, dot11WNMLocConfigRprtRqstToken, dot11WNMLocConfigRprtIfIndex, dot11WNMLocConfigRprtLocIndParams, dot11WNMLocConfigRprtLocIndChanList, dot11WNMLocConfigRprtLocIndBcastRate, dot11WNMLocConfigRprtLocIndOptions, dot11WNMLocConfigRprtStatusConfigSubelemId, dot11WNMLocConfigRprtStatusResult, dot11WNMLocConfigRprtVendorSpecificRprtContent, dot11WNMBssTransitRprtRqstToken, dot11WNMBssTransitRprtIfIndex, dot11WNMBssTransitRprtStatusCode, 3247 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11WNMBssTransitRprtBSSTerminationDelay, dot11WNMBssTransitRprtTargetBssid, dot11WNMBssTransitRprtCandidateList, dot11WNMColocInterfRprtRqstToken, dot11WNMColocInterfRprtIfIndex, dot11WNMColocInterfRprtPeriod, dot11WNMColocInterfRprtInterfLevel, dot11WNMColocInterfRprtInterfAccuracy, dot11WNMColocInterfRprtInterfIndex, dot11WNMColocInterfRprtInterfInterval, dot11WNMColocInterfRprtInterfBurstLength, dot11WNMColocInterfRprtInterfStartTime, dot11WNMColocInterfRprtInterfCenterFreq, dot11WNMColocInterfRprtInterfBandwidth } STATUS current DESCRIPTION "The SMTWNMReport package is a set of attributes that shall be present if the STA supports the WNM service." ::= { dot11Groups 55 } dot11SMTbase12 OBJECT-GROUP OBJECTS { dot11MediumOccupancyLimit, dot11CFPollable, dot11CFPPeriod, dot11CFPMaxDuration, dot11AuthenticationResponseTimeout, dot11PrivacyOptionImplemented, dot11PowerManagementMode, dot11DesiredSSID, dot11DesiredBSSType, dot11OperationalRateSet, dot11BeaconPeriod, dot11DTIMPeriod, dot11AssociationResponseTimeout, dot11DisassociateReason, dot11DisassociateStation, dot11DeauthenticateReason, dot11DeauthenticateStation, dot11AuthenticateFailStatus, dot11AuthenticateFailStation, dot11MultiDomainCapabilityImplemented, dot11MultiDomainCapabilityActivated, dot11CountryString, dot11SpectrumManagementImplemented, dot11SpectrumManagementRequired, dot11RSNAOptionImplemented, dot11OperatingClassesImplemented, dot11OperatingClassesRequired, dot11QosOptionImplemented, dot11ImmediateBlockAckOptionImplemented, dot11DelayedBlockAckOptionImplemented, dot11DirectOptionImplemented, dot11APSDOptionImplemented, dot11QAckOptionImplemented, dot11QBSSLoadImplemented, dot11QueueRequestOptionImplemented, dot11TXOPRequestOptionImplemented, dot11MoreDataAckOptionImplemented, dot11AssociateInNQBSS, dot11DLSAllowedInQBSS, dot11DLSAllowed, dot11AssociateStation, dot11AssociateID, 3248 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11AssociateFailStation, dot11AssociateFailStatus, dot11ReassociateStation, dot11ReassociateID, dot11ReassociateFailStation, dot11ReassociateFailStatus, dot11RadioMeasurementImplemented, dot11RadioMeasurementActivated, dot11RMMeasurementNavSync, dot11RMMeasurementPilotPeriod, dot11RMLinkMeasurementActivated, dot11RMNeighborReportActivated, dot11RMParallelMeasurementsActivated, dot11RMRepeatedMeasurementsActivated, dot11RMBeaconPassiveMeasurementActivated, dot11RMBeaconActiveMeasurementActivated, dot11RMBeaconTableMeasurementActivated, dot11RMBeaconMeasurementReportingConditionsActivated, dot11RMFrameMeasurementActivated, dot11RMChannelLoadMeasurementActivated, dot11RMNoiseHistogramMeasurementActivated, dot11RMStatisticsMeasurementActivated, dot11RMLCIMeasurementActivated, dot11RMLCIAzimuthActivated, dot11RMTransmitStreamCategoryMeasurementActivated, dot11RMTriggeredTransmitStreamCategoryMeasurementActivated, dot11RMAPChannelReportActivated, dot11RMMIBActivated, dot11RMMaxMeasurementDuration, dot11RMNonOperatingChannelMaxMeasurementDuration, dot11RMMeasurementPilotTransmissionInformationActivated, dot11RMMeasurementPilotActivated, dot11RMNeighborReportTSFOffsetActivated, dot11RMRCPIMeasurementActivated, dot11RMRSNIMeasurementActivated, dot11RMBSSAverageAccessDelayActivated, dot11RMBSSAvailableAdmissionCapacityActivated, dot11FastBSSTransitionImplemented, dot11LCIDSEImplemented, dot11LCIDSERequired, dot11DSERequired, dot11ExtendedChannelSwitchActivated, dot11HighThroughputOptionImplemented, dot11WirelessManagementImplemented, dot11MeshActivated, dot11RSNAPBACRequired, dot11PSMPOptionImplemented} STATUS deprecated DESCRIPTION "Superseded by dot11SMTbase13. The SMTbase12 object class provides the necessary support at the STA to manage the processes in the STA such that the STA may work cooperatively as a part of an IEEE 802.11 network." ::= { dot11Groups 57 } dot11OperatingClassesGroup OBJECT-GROUP OBJECTS { dot11OperatingClass, dot11CoverageClass } STATUS current DESCRIPTION "Attributes that configure the OFDM PHY for IEEE Std 802.11 in many regulatory domains." 3249 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ::= { dot11Groups 58 } dot11PhyOperationComplianceGroup2 OBJECT-GROUP OBJECTS { dot11PHYType, dot11CurrentRegDomain } STATUS current DESCRIPTION "PHY operations attributes." ::= { dot11Groups 59 } dot11MeshComplianceGroup OBJECT-GROUP OBJECTS { -- dot11MeshSTAConfigTable dot11MeshID, dot11MeshNumberOfPeerings, dot11MeshAcceptingAdditionalPeerings, dot11MeshConnectedToMeshGate, dot11MeshSecurityActivated, dot11MeshActiveAuthenticationProtocol, dot11MeshMaxRetries, dot11MeshRetryTimeout, dot11MeshConfirmTimeout, dot11MeshHoldingTimeout, dot11MeshActivePathSelectionProtocol, dot11MeshActivePathSelectionMetric, dot11MeshForwarding, dot11MeshTTL, dot11MeshGateAnnouncements, dot11MeshActiveCongestionControlMode, dot11MeshActiveSynchronizationMethod, dot11MeshNbrOffsetMaxNeighbor, dot11MBCAActivated, dot11MCCAImplemented, dot11MCCAActivated } STATUS current DESCRIPTION "This object class provides the objects from the IEEE 802.11 MIB required to manage mandatory mesh functionality. Note that additional objects for managing mesh functionality are located in the dot11MeshOptionGroup, dot11MeshHWMPComplianceGroup, and dot11PasswordAuthComplianceGroup." ::= { dot11Groups 56} dot11MeshOptionGroup OBJECT-GROUP OBJECTS { -- dot11MeshSTAConfigTable dot11MeshConfigGroupUpdateCount, dot11MeshGateAnnouncementInterval, dot11MeshBeaconTimingReportInterval, dot11MeshBeaconTimingReportMaxNum, dot11MeshDelayedBeaconTxInterval, dot11MeshDelayedBeaconTxMaxDelay, dot11MeshDelayedBeaconTxMinDelay, dot11MeshAverageBeaconFrameDuration, dot11MeshSTAMissingAckRetryLimit, dot11MeshAwakeWindowDuration, dot11MAFlimit, dot11MCCAScanDuration, dot11MCCAAdvertPeriodMax, dot11MCCAMinTrackStates, dot11MCCAMaxTrackStates, dot11MCCAOPtimeout, dot11MCCACWmin, dot11MCCACWmax, dot11MCCAAIFSN 3250 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications } STATUS current DESCRIPTION "This object class provides the objects from the IEEE 802.11 MIB required to manage optional mesh functionality. Note that other objects for managing mesh functionality are located in the dot11MeshComplianceGroup, dot11MeshHWMPComplianceGroup, and dot11PasswordAuthComplianceGroup." ::= { dot11Groups 60 } dot11MeshHWMPComplianceGroup OBJECT-GROUP OBJECTS { -- dot11MeshHWMPConfigTable dot11MeshHWMPmaxPREQretries, dot11MeshHWMPnetDiameter, dot11MeshHWMPnetDiameterTraversalTime, dot11MeshHWMPpreqMinInterval, dot11MeshHWMPperrMinInterval, dot11MeshHWMPactivePathToRootTimeout, dot11MeshHWMPactivePathTimeout, dot11MeshHWMProotMode, dot11MeshHWMProotInterval, dot11MeshHWMPrannInterval, dot11MeshHWMPtargetOnly, dot11MeshHWMPmaintenanceInterval, dot11MeshHWMPconfirmationInterval } STATUS current DESCRIPTION "This object class provides the objects from the IEEE 802.11 MIB required to manage HWMP path selection functionality. Note that other objects for managing mesh functionality are located in the dot11MeshComplianceGroup, dot11MeshOptionGroup, and dot11PasswordAuthComplianceGroup." ::= { dot11Groups 61 } dot11PasswordAuthComplianceGroup OBJECT-GROUP OBJECTS { -- dot11RSNAConfigTable dot11RSNASAERetransPeriod, dot11RSNASAEAntiCloggingThreshold, dot11RSNASAESync, -- dot11RSNAConfigPasswordValueTable -- dot11RSNAConfigPasswordValueIndex, dot11RSNAConfigPasswordCredential, dot11RSNAConfigPasswordPeerMac, -- dot11RSNAConfigDLCGroupTable -- dot11RSNAConfigDLCGroupIndex, dot11RSNAConfigDLCGroupIdentifier } STATUS current DESCRIPTION "This object class provides the objects from the IEEE 802.11 MIB required to manage password authentication. Note that other objects for managing mesh functionality are located in the dot11MeshComplianceGroup, dot11MeshOptionGroup, and dot11MeshHWMPComplianceGroup." ::= { dot11Groups 62 } dot11QMFComplianceGroup OBJECT-GROUP OBJECTS { dot11QMFActivated, dot11QMFReconfigurationActivated, dot11QMFPolicyChangeTimeout } STATUS current DESCRIPTION "This object group provides the objects from the IEEE 802.11 MIB required 3251 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications to manage QoS Management Frame functionality." ::= { dot11Groups 63 } dot11DMGComplianceGroup OBJECT-GROUP OBJECTS {dot11MultibandImplemented, dot11DMGOptionImplemented, dot11RelayActivated, dot11REDSActivated, dot11RDSActivated, dot11RSNAProtectedManagementFramesActivated, dot11MultipleMACActivated, dot11ClusteringActivated, dot11LowPowerSCPHYImplemented, dot11LowPowerSCPHYActivated } STATUS current DESCRIPTION "Attributes that configure the DMG Group for IEEE Std 802.11." ::= { dot11Groups 64 } dot11DMGOperationsComplianceGroup OBJECT-GROUP OBJECTS {dot11MaxLostBeacons, dot11MinBHIDuration, dot11PSRequestSuspensionInterval, dot11BroadcastSTAInfoDuration, dot11NbrOfChangeBeacons, dot11ImplicitHandoverLostBeacons, dot11MinPPDuration, dot11SPIdleTimeout, dot11QABTimeout, dot11ClusterEnableTime, dot11PNWarningThresholdLow,dot11PNWarningThresholdHigh, dot11BeaconSPDuration, dot11PNExhaustionThresholdLow,dot11PNExhaustionThresholdHigh, dot11MaxNumberOfClusteringMonitoringPeriods, dot11DMGEcssPolicyDetailUpdateDurationMax, dot11DMGEcssClusterReportDurationMin, dot11DMGNavSync } STATUS current DESCRIPTION "Attributes that configure the DMG Operation for IEEE Std 802.11." ::= { dot11Groups 65 } dot11DMGBeamformingComplianceGroup OBJECT-GROUP OBJECTS {dot11MaxBFTime, dot11BFTXSSTime, dot11MaximalSectorScan, dot11ABFTRTXSSSwitch, dot11RSSRetryLimit, dot11RSSBackoff, dot11BFRetryLimit, dot11BFTXSSTime, dot11BeamLinkMaintenanceTime,dot11BeamTrackingTimeLimit } STATUS current DESCRIPTION "Attributes that configure the DMG Beamforming functionality for IEEE Std 802.11." ::= { dot11Groups 66 } dot11DMGCountersComplianceGroup OBJECT-GROUP OBJECTS {dot11RSNAStatsGCMPReplays, dot11RSNAStatsRobustMgmtGCMPReplays } STATUS current DESCRIPTION "Attributes that are used as counters for a DMG capable Station for IEEE Std 802.11." ::= { dot11Groups 67 } dot11AVSBase OBJECT-GROUP OBJECTS { dot11RobustAVStreamingImplemented, dot11GCRActivated, dot11AdvancedGCRImplemented, 3252 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11AdvancedGCRActivated, dot11SCSImplemented, dot11SCSActivated, dot11QLoadReportActivated, dot11AlternateEDCAActivated, dot11PublicHCCATXOPNegotiationActivated, dot11GCRGroupMembershipAnnouncementActivated, dot11MeshGCRImplemented, dot11MeshGCRActivated, dot11PublicHCCATXOPNegotiationImplemented, dot11PublicHCCATXOPNegotiationActivated, dot11ProtectedHCCATXOPNegotiationImplemented, dot11ProtectedHCCATXOPNegotiationActivated, dot11ProtectedQLoadReportImplemented, dot11ProtectedQLoadReportActivated, dot11QLoadReportIntervalDTIM, dot11HCCATXOPBeaconTimeout, dot11GCRConcealmentAddress, dot11GCRPolicyChangeTimeout, dot11QLoadReportDelay, dot11DefaultSurplusBandwidthAllowance, dot11ShortDEIRetryLimit, dot11LongDEIRetryLimit, dot11UnsolicitedRetryLimit, dot11STAStatisticsAverageMSDUSizeVideo, dot11STAStatisticsAverageMSDUSizeVoice, dot11STAStatisticsAverageBitrateVideo, dot11STAStatisticsAverageBitrateVoice } STATUS current DESCRIPTION "The AVSBase package is a set of attributes that are present if the STA supports the robust audio video streaming features." ::= { dot11Groups 68 } dot11AVSAPCGroup OBJECT-GROUP OBJECTS { dot11APCEntryAvoidanceDuration, dot11APCEntryAvoidanceServiceInterval, dot11APCEntryAvoidanceOffset, dot11APCEntryMACAddress } STATUS current DESCRIPTION "The AVSAPCGroup package is a set of attributes that are present if the STA supports HCCA TXOP negotiation." ::= { dot11Groups 69 } dot11TVWSComplianceGroup OBJECT-GROUP OBJECTS { dot11ChannelScheduleManagementActivated, dot11ContactVerificationSignalActivated, dot11NetworkChannelControlActivated, dot11WhiteSpaceMapActivated, dot11GDDActivated, dot11TVHTOptionImplemented } STATUS current DESCRIPTION "Attributes that configure the TVWS Group for IEEE Std 802.11." ::= { dot11Groups 70 } dot11SpectrumManagementGroup OBJECT-GROUP 3253 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications OBJECTS { -- Dot11SpectrumManagementEntry -- dot11SpectrumManagementIndex, dot11ChannelSwitchTime, dot11PowerCapabilityMaxImplemented, dot11PowerCapabilityMinImplemented } STATUS current DESCRIPTION "This object class provides the objects from the IEEE 802.11 MIB for spectrum management." ::= { dot11Groups 72 } dot11ProtectedManagementFrameGroup OBJECT-GROUP OBJECTS { -- Dot11StationConfigEntry dot11RSNAProtectedManagementFramesActivated, dot11RSNAUnprotectedManagementFramesAllowed, dot11AssociationSAQueryMaximumTimeout, dot11AssociationSAQueryRetryTimeout, -- dot11RSNAStatsEntry dot11RSNAStatsCMACReplays, dot11RSNAStatsRobustMgmtCCMPReplays, dot11RSNAStatsBIPMICErrors} STATUS current DESCRIPTION "This object class provides the objects from the IEEE 802.11 MIB required to operate management frame protection." ::= { dot11Groups 73 } dot11LCIDSEGroup OBJECT-GROUP OBJECTS { -- Dot11LCIDSEEntry -- dot11LCIDSEIndex, dot11LCIDSEIfIndex, dot11LCIDSECurrentOperatingClass, dot11LCIDSELatitudeUncertainty, dot11LCIDSELatitudeInteger, dot11LCIDSELatitudeFraction, dot11LCIDSELongitudeUncertainty, dot11LCIDSELongitudeInteger, dot11LCIDSELongitudeFraction, dot11LCIDSEAltitudeType, dot11LCIDSEAltitudeUncertainty, dot11LCIDSEAltitude, dot11LCIDSEDatum, dot11RegLocAgreement, dot11RegLocDSE, dot11DependentSTA, dot11DependentEnablementIdentifier, dot11DSEEnablementTimeLimit, dot11DSEEnablementFailHoldTime, dot11DSERenewalTime, dot11DSETransmitDivisor } STATUS current DESCRIPTION "This object class provides the objects from the IEEE 802.11 MIB required to enable 3650-3700 MHz Operation in USA." ::= { dot11Groups 74 } dot11TDLSComplianceGroup OBJECT-GROUP OBJECTS { -- Dot11StationConfigEntry dot11TunneledDirectLinkSetupImplemented, dot11TDLSPeerUAPSDBufferSTAActivated, 3254 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11TDLSPeerPSMActivated, dot11TDLSPeerUAPSDIndicationWindow, dot11TDLSChannelSwitchingActivated, dot11TDLSPeerSTAMissingAckRetryLimit, dot11TDLSResponseTimeout, dot11OCBActivated, dot11TDLSNavSync, dot11TDLSDiscoveryRequestWindow, dot11TDLSACDeterminationInterval } STATUS current DESCRIPTION "This object class provides the objects from the IEEE 802.11 MIB required to operate tunneled direct link setup." ::= { dot11Groups 75 } dot11VHTTransmitBeamformingGroup OBJECT-GROUP OBJECTS { dot11VHTSUBeamformeeOptionImplemented, dot11VHTSUBeamformerOptionImplemented, dot11VHTMUBeamformeeOptionImplemented, dot11VHTMUBeamformerOptionImplemented, dot11VHTNumberSoundingDimensions, dot11VHTBeamformeeNTxSupport } STATUS current DESCRIPTION "Attributes that configure VHT transmit beamforming for IEEE Std 802.11." ::= { dot11Groups 76 } dot11PhyVHTComplianceGroup OBJECT-GROUP OBJECTS { dot11VHTChannelWidthOptionImplemented, dot11CurrentChannelWidth, dot11CurrentChannelCenterFrequencyIndex0, dot11CurrentChannelCenterFrequencyIndex1, dot11VHTShortGIOptionIn80Implemented, dot11VHTShortGIOptionIn80Activated, dot11VHTShortGIOptionIn160and80p80Implemented, dot11VHTShortGIOptionIn160and80p80Activated, dot11VHTLDPCCodingOptionImplemented, dot11VHTLDPCCodingOptionActivated, dot11VHTTxSTBCOptionImplemented, dot11VHTTxSTBCOptionActivated, dot11VHTRxSTBCOptionImplemented, dot11VHTRxSTBCOptionActivated, dot11VHTMUMaxUsersImplemented, dot11VHTMUMaxNSTSPerUserImplemented, dot11VHTMUMaxNSTSTotalImplemented, dot11VHTMaxNTxChainsImplemented, dot11VHTMaxNTxChainsActivated} STATUS current DESCRIPTION "Attributes that configure the VHT PHY." ::= { dot11Groups 77 } dot11VHTMACAdditions OBJECT-GROUP OBJECTS { dot11VHTOptionImplemented, dot11OperatingModeNotificationImplemented, dot11MaxMPDULength, dot11VHTMaxRxAMPDUFactor, dot11VHTControlFieldOptionImplemented, dot11VHTTXOPPowerSaveOptionImplemented, dot11VHTRxVHTMCSMap, dot11VHTRxHighestDataRateSupported, 3255 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11VHTTxVHTMCSMap, dot11VHTTxHighestDataRateSupported, dot11VHTOBSSScanCount, dot11VHTExtendedNSSBWCapable } STATUS current DESCRIPTION "Attributes that configure the VHT MAC." ::= { dot11Groups 78 } dot11PhyTxPowerComplianceGroup2 OBJECT-GROUP OBJECTS { dot11TxPowerLevelExtended, dot11CurrentTxPowerLevelExtended } STATUS current DESCRIPTION "Additional attributes for Control and Management of transmit power." ::= { dot11Groups 79 } dot11TVHTTransmitBeamformingGroup OBJECT-GROUP OBJECTS { dot11TVHTSUBeamformeeOptionImplemented, dot11TVHTSUBeamformerOptionImplemented, dot11TVHTMUBeamformeeOptionImplemented, dot11TVHTMUBeamformerOptionImplemented, dot11TVHTNumberSoundingDimensions, dot11TVHTBeamformeeNTxSupport } STATUS current DESCRIPTION "Attributes that configure TVHT transmit beamforming for IEEE Std 802.11." ::= { dot11Groups 80 } dot11PhyTVHTComplianceGroup OBJECT-GROUP OBJECTS { dot11TVHTChannelWidthOptionImplemented, dot11TVHTCurrentChannelWidth, dot11TVHTCurrentChannelCenterFrequencyIndex0, dot11TVHTCurrentChannelCenterFrequencyIndex1, dot11TVHTShortGIOptionIn4WImplemented, dot11TVHTShortGIOptionIn4WActivated, dot11TVHTLDPCCodingOptionImplemented, dot11TVHTLDPCCodingOptionActivated, dot11TVHTTxSTBCOptionImplemented, dot11TVHTTxSTBCOptionActivated, dot11TVHTRxSTBCOptionImplemented, dot11TVHTRxSTBCOptionActivated, dot11TVHTMUMaxUsersImplemented, dot11TVHTMUMaxNSTSPerUserImplemented, dot11TVHTMUMaxNSTSTotalImplemented, dot11TVHTMaxNTxChainsImplemented, dot11TVHTMaxNTxChainsActivated } STATUS current DESCRIPTION "Attributes that configure the TVHT PHY." ::= { dot11Groups 81 } dot11MACbase4 OBJECT-GROUP OBJECTS { dot11MACAddress, dot11GroupAddress, dot11GroupAddressesStatus, dot11RTSThreshold, 3256 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11ShortRetryLimit, dot11LongRetryLimit, dot11FragmentationThreshold, dot11MaxTransmitMSDULifetime, dot11MaxReceiveLifetime, dot11ManufacturerID, dot11ProductID, dot11CAPLimit, dot11HCCWmin, dot11HCCWmax, dot11HCCAIFSN, dot11ChannelUtilizationBeaconIntervals, dot11ScheduleTimeout, dot11DLSResponseTimeout, dot11QAPMissingAckRetryLimit, dot11EDCAAveragingPeriod, dot11HTProtection, dot11RIFSMode, dot11PSMPControlledAccess, dot11ServiceIntervalGranularity, dot11DualCTSProtection, dot11LSIGTXOPFullProtectionActivated, dot11NonGFEntitiesPresent, dot11PCOActivated, dot11PCOFortyMaxDuration, dot11PCOTwentyMaxDuration, dot11PCOFortyMinDuration, dot11PCOTwentyMinDuration } STATUS current DESCRIPTION "The MAC object class provides the necessary support for the access control, generation, and verification of frame check sequences (FCSs), and proper delivery of valid data to upper layers." ::= { dot11Groups 84 } dot11CountersGroup4 OBJECT-GROUP OBJECTS { dot11TransmittedFragmentCount, dot11TransmittedFrameCount, dot11FailedCount, dot11ReceivedFragmentCount, dot11GroupReceivedFrameCount, dot11FCSErrorCount, dot11WEPUndecryptableCount, dot11TransmittedFrameCount, dot11QosDiscardedFragmentCount, dot11AssociatedStationCount, dot11QosCFPollsReceivedCount, dot11QosCFPollsUnusedCount, dot11QosCFPollsUnusableCount, dot11QosCFPollsLostCount, dot11TransmittedAMSDUCount, dot11FailedAMSDUCount, dot11RetryAMSDUCount, dot11MultipleRetryAMSDUCount, dot11TransmittedOctetsInAMSDUCount, dot11AMSDUAckFailureCount, dot11ReceivedAMSDUCount, dot11ReceivedOctetsInAMSDUCount, dot11TransmittedAMPDUCount, dot11TransmittedMPDUsInAMPDUCount, dot11TransmittedOctetsInAMPDUCount, dot11AMPDUReceivedCount, dot11MPDUInReceivedAMPDUCount, dot11ReceivedOctetsInAMPDUCount, 3257 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11AMPDUDelimiterCRCErrorCount, dot11ImplicitBARFailureCount, dot11ExplicitBARFailureCount, dot11ChannelWidthSwitchCount, dot11TwentyMHzFrameTransmittedCount, dot11FortyMHzFrameTransmittedCount, dot11TwentyMHzFrameReceivedCount, dot11FortyMHzFrameReceivedCount, dot11PSMPUTTGrantDuration, dot11PSMPUTTUsedDuration, dot11GrantedRDGUsedCount, dot11GrantedRDGUnusedCount, dot11TransmittedFramesInGrantedRDGCount, dot11TransmittedOctetsInGrantedRDGCount, dot11BeamformingFrameCount, dot11DualCTSSuccessCount, dot11DualCTSFailureCount, dot11STBCCTSSuccessCount, dot11STBCCTSFailureCount, dot11nonSTBCCTSSuccessCount, dot11nonSTBCCTSFailureCount, dot11RTSLSIGSuccessCount, dot11RTSLSIGFailureCount, dot11TransmittedMSDUOctetsCount, dot11ReceivedMSDUOctetsCount } STATUS current DESCRIPTION "Attributes from the dot11CountersGroup that are not described in the dot11MACStatistics group. These objects are mandatory." ::= { dot11Groups 85 } dot11BSSStatisticsGroup OBJECT-GROUP OBJECTS { dot11AssociatedStationCount, dot11BSSLoadChannelUtilization, dot11BSSLoadAvailableAdmissionCapacity, dot11BSSLoadAssocAttemptCount, dot11BSSLoadAssocFailCount, dot11BSSLoadReassocAttemptCount, dot11BSSLoadReassocFailCount } STATUS current DESCRIPTION "The BSS Statistics group defines those objects that provide access to local measurements by an AP of its BSS." ::= { dot11Groups 86 } dot11HTMACAdditions2 OBJECT-GROUP OBJECTS { dot11MIMOPowerSave, dot11NDelayedBlockAckOptionImplemented, dot11MaxAMSDULength, dot11STBCControlFrameOptionImplemented, dot11LsigTxopProtectionOptionImplemented, dot11MaxRxAMPDUFactor, dot11MinimumMPDUStartSpacing, dot11PCOOptionImplemented, dot11TransitionTime, dot11MCSFeedbackOptionImplemented, dot11HTControlFieldSupported, dot11RDResponderOptionImplemented, dot11BSSWidthTriggerScanInterval, dot11BSSWidthChannelTransitionDelayFactor, 3258 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11OBSSScanPassiveDwell, dot11OBSSScanActiveDwell, dot11OBSSScanPassiveTotalPerChannel, dot11OBSSScanActiveTotalPerChannel, dot112040BSSCoexistenceManagementSupport, dot11OBSSScanActivityThreshold, dot11SPPAMSDUCapable, dot11SPPAMSDURequired } STATUS current DESCRIPTION "Attributes that configure the HT PHY for IEEE Std 802.11." ::= { dot11Groups 87 } -- dot11SMTbase13 includes all changes made between IEEE Std 802.11-2012 and IEEE Std 802.11-2016. -- Amendments to Std 802.11-2016 should not make any modifications to dot11SMTbase13. The first amendment needing to modify the dot11SMTbase object should deprecate dot11SMTbase13 and define a replacement to hold changes. dot11SMTbase13 OBJECT-GROUP OBJECTS { dot11MediumOccupancyLimit, dot11CFPollable, dot11CFPPeriod, dot11CFPMaxDuration, dot11PrivacyOptionImplemented, dot11PowerManagementMode, dot11DesiredSSID, dot11DesiredBSSType, dot11OperationalRateSet, dot11BeaconPeriod, dot11DTIMPeriod, dot11AssociationResponseTimeout, dot11DisassociateReason, dot11DisassociateStation, dot11DeauthenticateReason, dot11DeauthenticateStation, dot11AuthenticateFailStatus, dot11AuthenticateFailStation, dot11MultiDomainCapabilityImplemented, dot11MultiDomainCapabilityActivated, dot11CountryString, dot11SpectrumManagementImplemented, dot11SpectrumManagementRequired, dot11RSNAOptionImplemented, dot11OperatingClassesImplemented, dot11OperatingClassesRequired, dot11QosOptionImplemented, dot11ImmediateBlockAckOptionImplemented, dot11DelayedBlockAckOptionImplemented, dot11DirectOptionImplemented, dot11APSDOptionImplemented, dot11QAckOptionImplemented, dot11QBSSLoadImplemented, dot11QueueRequestOptionImplemented, dot11TXOPRequestOptionImplemented, dot11MoreDataAckOptionImplemented, dot11AssociateInNQBSS, dot11DLSAllowedInQBSS, dot11DLSAllowed, dot11AssociateStation, dot11AssociateID, dot11AssociateFailStation, 3259 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11AssociateFailStatus, dot11ReassociateStation, dot11ReassociateID, dot11ReassociateFailStation, dot11ReassociateFailStatus, dot11RadioMeasurementImplemented, dot11RadioMeasurementActivated, dot11RMMeasurementNavSync, dot11RMMeasurementPilotPeriod, dot11RMLinkMeasurementActivated, dot11RMNeighborReportActivated, dot11RMParallelMeasurementsActivated, dot11RMRepeatedMeasurementsActivated, dot11RMBeaconPassiveMeasurementActivated, dot11RMBeaconActiveMeasurementActivated, dot11RMBeaconTableMeasurementActivated, dot11RMBeaconMeasurementReportingConditionsActivated, dot11RMFrameMeasurementActivated, dot11RMChannelLoadMeasurementActivated, dot11RMNoiseHistogramMeasurementActivated, dot11RMStatisticsMeasurementActivated, dot11RMLCIMeasurementActivated, dot11RMLCIAzimuthActivated, dot11RMTransmitStreamCategoryMeasurementActivated, dot11RMTriggeredTransmitStreamCategoryMeasurementActivated, dot11RMAPChannelReportActivated, dot11RMMIBActivated, dot11RMMaxMeasurementDuration, dot11RMNonOperatingChannelMaxMeasurementDuration, dot11RMMeasurementPilotTransmissionInformationActivated, dot11RMMeasurementPilotActivated, dot11RMNeighborReportTSFOffsetActivated, dot11RMRCPIMeasurementActivated, dot11RMRSNIMeasurementActivated, dot11RMBSSAverageAccessDelayActivated, dot11RMBSSAvailableAdmissionCapacityActivated, dot11FastBSSTransitionImplemented, dot11LCIDSEImplemented, dot11LCIDSERequired, dot11DSERequired, dot11ExtendedChannelSwitchActivated, dot11HighThroughputOptionImplemented, dot11WirelessManagementImplemented, dot11MeshActivated, dot11RSNAPBACRequired, dot11PSMPOptionImplemented, dot11MaxMSDULength, dot11ExtendedSpectrumManagementImplemented, dot11EstimatedServiceParametersOptionImplemented, dot11FutureChannelGuidanceActivated } STATUS current DESCRIPTION "The SMTbase13 object class provides the necessary support at the STA to manage the processes in the STA such that the STA may work cooperatively as a part of an IEEE 802.11 network." ::= { dot11Groups 92 } dot11FineTimingMeasurement OBJECT-GROUP OBJECTS { dot11WirelessManagementImplemented, dot11FineTimingMsmtRespActivated, dot11FineTimingMsmtInitActivated, dot11LciCivicInNeighborReport, 3260 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11RMFineTimingMsmtRangeRepImplemented, dot11RMFineTimingMsmtRangeRepActivated, dot11RMLCIMeasurementActivated, dot11RMLCIConfigured, dot11RMCivicMeasurementActivated, dot11RMCivicConfigured } STATUS current DESCRIPTION "Attributes that configure the Fine Timing Measurement feature for IEEE Std 802.11." ::= { dot11Groups 93 } -- ********************************************************************** -- * Compliance Statements -- ********************************************************************** dot11Compliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities that implement the IEEE 802.11 MIB." MODULE -- this module MANDATORY-GROUPS { dot11SMTbase13, dot11MACbase4, dot11CountersGroup4, dot11SmtAuthenticationAlgorithms, dot11ResourceTypeID, dot11PhyOperationComplianceGroup2 } GROUP dot11PhyDSSSComplianceGroup DESCRIPTION "Implementation of this group is required when object dot11PHYType is dsss. This group is mutually exclusive to the following groups: dot11PhyOFDMComplianceGroup3 dot11PhyHRDSSSComplianceGroup dot11PhyERPComplianceGroup dot11PhyHTComplianceGroup dot11DMGComplianceGroup dot11PhyVHTComplianceGroup dot11PhyTVHTComplianceGroup" GROUP dot11PhyOFDMComplianceGroup3 DESCRIPTION "Implementation of this group is required when object dot11PHYType is ofdm. This group is mutually exclusive to the following groups: dot11PhyDSSSComplianceGroup dot11PhyHRDSSSComplianceGroup dot11PhyERPComplianceGroup dot11PhyHTComplianceGroup dot11DMGComplianceGroup dot11PhyVHTComplianceGroup dot11PhyTVHTComplianceGroup" GROUP dot11PhyHRDSSSComplianceGroup DESCRIPTION "Implementation of this group is required when object dot11PHYType is hrdsss. This group is mutually exclusive to the following groups: 3261 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications dot11PhyDSSSComplianceGroup dot11PhyOFDMComplianceGroup3 dot11PhyERPComplianceGroup dot11PhyHTComplianceGroup dot11DMGComplianceGroup dot11PhyVHTComplianceGroup dot11PhyTVHTComplianceGroup" GROUP dot11PhyERPComplianceGroup DESCRIPTION "Implementation of this group is required when object dot11PHYType is erp. This group is mutually exclusive to the following groups: dot11PhyDSSSComplianceGroup dot11PhyOFDMComplianceGroup3 dot11PhyHRDSSSComplianceGroup dot11PhyHTComplianceGroup dot11DMGComplianceGroup dot11PhyVHTComplianceGroup dot11PhyTVHTComplianceGroup" GROUP dot11PhyHTComplianceGroup DESCRIPTION "Implementation of this group is required when object dot11PHYType is ht. This group is mutually exclusive to the following groups: dot11PhyDSSSComplianceGroup dot11PhyOFDMComplianceGroup3 dot11PhyHRDSSSComplianceGroup dot11PhyERPComplianceGroup dot11DMGComplianceGroup dot11PhyVHTComplianceGroup dot11PhyTVHTComplianceGroup" GROUP dot11PhyVHTComplianceGroup DESCRIPTION "Implementation of this group is required when object dot11PHYType is vht. This group is mutually exclusive to the following groups: dot11PhyDSSSComplianceGroup dot11PhyOFDMComplianceGroup3 dot11PhyHRDSSSComplianceGroup dot11PhyERPComplianceGroup dot11DMGComplianceGroup dot11PhyHTComplianceGroup dot11PhyTVHTComplianceGroup" GROUP dot11PhyTVHTComplianceGroup DESCRIPTION "Implementation of this group is required when object dot11PHYType is tvht. This group is mutually exclusive to the following groups: dot11PhyDSSSComplianceGroup dot11PhyOFDMComplianceGroup3 dot11PhyHRDSSSComplianceGroup dot11PhyERPComplianceGroup dot11PhyHTComplianceGroup dot11DMGComplianceGroup dot11PhyVHTComplianceGroup" GROUP dot11HTMACAdditions2 DESCRIPTION "The dot11HTMACAdditions2 group is optional." GROUP dot11SMTprivacy DESCRIPTION "The dot11SMTprivacy group is optional." 3262 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications GROUP dot11MACStatistics DESCRIPTION "The dot11MACStatistics group is optional." GROUP dot11PhyTxPowerComplianceGroup DESCRIPTION "The dot11PhyTxPowerComplianceGroup group is optional." GROUP dot11PhyTxPowerComplianceGroup2 DESCRIPTION "The dot11PhyTxPowerComplianceGroup2 group is optional, but dependent on dot11PhyTxPowerComplianceGroup." GROUP dot11PhyRegDomainsSupportGroup DESCRIPTION "The dot11PhyRegDomainsSupportGroup group is optional." GROUP dot11PhyAntennasListGroup DESCRIPTION "The dot11PhyAntennasListGroup group is optional." GROUP dot11PhyRateGroup DESCRIPTION "The dot11PhyRateGroup group is optional." GROUP dot11MultiDomainCapabilityGroup DESCRIPTION "The dot11MultiDomainCapabilityGroup group is optional." GROUP dot11RSNAadditions DESCRIPTION "The dot11RSNAadditions group is optional." GROUP dot11OperatingClassesGroup DESCRIPTION "The dot11OperatingClassesGroup group is optional." GROUP dot11Qosadditions DESCRIPTION "The dot11Qosadditions group is optional." GROUP dot11FTComplianceGroup DESCRIPTION "The dot11FTComplianceGroup group is optional." GROUP dot11PhyAntennaComplianceGroup2 DESCRIPTION "The dot11PhyAntennaComplianceGroup2 group is optional." GROUP dot11PhyMCSGroup DESCRIPTION "The dot11PhyMCSGroup group is optional." GROUP dot11TransmitBeamformingGroup DESCRIPTION "The dot11TransmitBeamformingGroup group is optional." GROUP dot11VHTTransmitBeamformingGroup DESCRIPTION "The dot11VHTTransmitBeamformingGroup group is optional." GROUP dot11VHTMACAdditions DESCRIPTION 3263 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications "The dot11VHTMACAdditions group is optional." GROUP dot11DMGComplianceGroup DESCRIPTION "Implementation of this group is required when the object dot11PHYType is dmg. This group is mutually exclusive to the following groups: dot11PhyDSSSComplianceGroup dot11PhyOFDMComplianceGroup3 dot11PhyHRDSSSComplianceGroup dot11PhyERPComplianceGroup dot11PhyHTComplianceGroup dot11PhyVHTComplianceGroup dot11PhyTVHTComplianceGroup" GROUP dot11DMGOperationsComplianceGroup DESCRIPTION "DMG Operations Compliance Group" GROUP dot11DMGBeamformingComplianceGroup DESCRIPTION "DMG Beamforming Compliance Group" GROUP dot11DMGCountersComplianceGroup DESCRIPTION "DMG Counters Compliance Group." GROUP dot11TVWSComplianceGroup DESCRIPTION "The dot11TVWSComplianceGroup is optional." GROUP dot11BSSStatisticsGroup DESCRIPTION "Implementation of this group is optional by an AP" -- OPTIONAL-GROUPS { -- dot11SMTprivacy, -- dot11MACStatistics, -- dot11PhyTxPowerComplianceGroup, -- dot11PhyRegDomainsSupportGroup, -- dot11PhyAntennasListGroup, -- dot11PhyRateGroup, -- dot11MultiDomainCapabilityGroup, -- dot11RSNAadditions, -- dot11OperatingClassesGroup, -- dot11Qosadditions, -- dot11RMCompliance, -- dot11FTComplianceGroup, -- dot11PhyAntennaComplianceGroup2, -- dot11HTMACadditions2, -- dot11PhyMCSGroup, -- dot11TransmitBeamformingGroup, -- dot11TVHTTransmitBeamformingGroup, -- dot11PhyTVHTComplianceGroup, -- dot11WNMCompliance, -- dot11BSSStatisticsGroup, -- dot11VHTTransmitBeamformingGroup, -- dot11PhyVHTComplianceGroup, -- dot11VHTMACAdditions, -- dot11TVWSComplianceGroup } ::= { dot11Compliances 1 } -- ******************************************************************** 3264 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications -- * Compliance Statements - RSN -- ******************************************************************** dot11RSNCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities that implement the IEEE 802.11 RSN MIB." MODULE -- this module MANDATORY-GROUPS { dot11RSNBase } -- OPTIONAL-GROUPS { dot11RSNPMKcachingGroup } ::= { dot11Compliances 2 } -- ******************************************************************** -- * Compliance Statements - RM -- ******************************************************************** dot11RMCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities that implement the IEEE 802.11 MIB for Measurement Services." MODULE -- this module MANDATORY-GROUPS { dot11SMTRMRequest, dot11SMTRMReport, dot11SMTRMConfig } -- OPTIONAL-GROUPS { } ::= { dot11Compliances 3 } -- ******************************************************************** -- * Compliance Statements - Mesh -- ******************************************************************** dot11MeshCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities that implement the IEEE 802.11 MIB for Mesh." MODULE -- this module MANDATORY-GROUPS { dot11MeshComplianceGroup, dot11MeshHWMPComplianceGroup, dot11PasswordAuthComplianceGroup } -- OPTIONAL-GROUPS { dot11MeshOptionGroup } ::= { dot11Compliances 4 } -- ******************************************************************** -- * Compliance Statements - WNM -- ******************************************************************** dot11WNMCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION " This object class provides the objects from the IEEE 802.11 MIB required to manage wireless network management functionality. Note that additional objects for managing this functionality are located in the IEEE 802.11 WNM MIB." MODULE -- this module MANDATORY-GROUPS { dot11SMTRMRequest, dot11SMTRMReport, dot11SMTRMConfig } GROUP dot11SMTbase12 DESCRIPTION "At least the dot11WirelessManagementImplemented object is required from dot11SMTbase12" GROUP dot11FineTimingMeasurement 3265 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications DESCRIPTION "The dot11FineTimingMeasurement group is optional" OBJECT dot11WirelessManagementImplemented DESCRIPTION "Required object" ::= { dot11Compliances 5 } -- ******************************************************************** -- * Compliance Statements - QMF -- ******************************************************************** dot11QMFCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "This object class provides the objects from the IEEE 802.11 MIB required to manage QoS Management Frame functionality." MODULE -- this module MANDATORY-GROUPS { dot11QMFComplianceGroup } ::= { dot11Compliances 6 } -- ******************************************************************** -- * Compliance Statements - AVS -- ******************************************************************** dot11AVSCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities that implement the IEEE Std 802.11 Robust Audio/Video Streaming feature. Note that additional objects for managing this functionality are located in the IEEE 802.11 AVS MIB." MODULE -- this module GROUP dot11AVSBase DESCRIPTION "At least the dot11RobustAVStreamingImplemented object is required from dot11StationConfigEntry." OBJECT dot11RobustAVStreamingImplemented DESCRIPTION "Required object" ::= { dot11Compliances 7 } dot11AVSAPCCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities that implement the IEEE Std 802.11 HCCA TXOP Negotiation feature. Note that additional objects for managing this functionality are located in the IEEE 802.11 AVS MIB." MODULE -- this module MANDATORY-GROUPS { dot11AVSBase } GROUP dot11AVSAPCGroup DESCRIPTION "At least the dot11RobustAVStreamingImplemented object is required from dot11StationConfigEntry." OBJECT dot11RobustAVStreamingImplemented DESCRIPTION "Required object" ::= { dot11Compliances 8 } -- ******************************************************************* -- * Compliance Statements - DMG -- ******************************************************************* dot11DMGCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities that implement the IEEE 802.11 MIB for DMG operation." 3266 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications MODULE -- this module MANDATORY-GROUPS { dot11DMGComplianceGroup, dot11DMGOperationsComplianceGroup, dot11DMGBeamformingComplianceGroup, dot11DMGCountersComplianceGroup } ::= { dot11Compliances 9 } -- ******************************************************************** -- * Compliance Statements - Spectrum Management -- ******************************************************************** dot11SpectrumManagementCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "This object class provides the objects from the IEEE 802.11 MIB used to operate higher throughput." MODULE -- this module MANDATORY-GROUPS { dot11SpectrumManagementGroup } -- OPTIONAL-GROUPS { } ::= { dot11Compliances 10 } -- ******************************************************************** -- * Compliance Statements - Management frame protection -- ******************************************************************** dot11ProtectedManagementFrameCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "This object class provides the objects from the IEEE 802.11 MIB required to operate management frame protection." MODULE -- this module MANDATORY-GROUPS { dot11ProtectedManagementFrameGroup } -- OPTIONAL-GROUPS { } ::= { dot11Compliances 11 } -- ******************************************************************** -- * Compliance Statements - LCIDSE -- ******************************************************************** dot11LCIDSECompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "This object class provides the objects from the IEEE 802.11 MIB required to enable 3650-3700 MHz Operation in USA." MODULE -- this module MANDATORY-GROUPS { dot11LCIDSEGroup } -- OPTIONAL-GROUPS { } ::= { dot11Compliances 12 } -- ******************************************************************** -- * Compliance Statements - TDLS -- ******************************************************************** dot11TDLSCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "This object class provides the objects from the IEEE 802.11 MIB required to manage tunneled direct link setup." MODULE -- this module MANDATORY-GROUPS { dot11TDLSComplianceGroup } -- OPTIONAL-GROUPS { } ::= { dot11Compliances 13 } -- ******************************************************************** -- * Compliance Statements - VHT -- ******************************************************************** dot11VHTCompliance MODULE-COMPLIANCE 3267 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STATUS current DESCRIPTION "This object class provides the objects from the IEEE 802.11 MIB used to operate at very high throughput." MODULE -- this module MANDATORY-GROUPS { dot11PhyVHTComplianceGroup, dot11PhyTxPowerCompliance- Group2, dot11VHTTransmitBeamformingGroup, dot11VHTMACAdditions } -- OPTIONAL-GROUPS { } ::= { dot11Compliances 14 } -- ******************************************************************** -- * Compliance Statements - TVWS -- ******************************************************************** dot11TVHTCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities that implement the IEEE 802.11 MIB for TVWS operation." MODULE -- this module MANDATORY-GROUPS { dot11PhyTVHTComplianceGroup, dot11PhyTxPowerComplianceGroup2, dot11TVHTTransmitBeamformingGroup, dot11VHTMACAdditions, dot11TVWSComplianceGroup } ::= { dot11Compliances 15 } -- ********************************************************************** -- * End of IEEE 802.11 MIB -- ********************************************************************** END 3268 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Annex D (normative) Regulatory references D.1 External regulatory references This annex and Annex E provide information and specifications for operation in many regulatory domains. WLANs implemented in accordance with this standard and the specifications and definitions referenced in it are subject to equipment certification and operating requirements established by regional and national regulatory administrations. The specification establishes minimum technical requirements for interoperability, based upon established regulations at the time this standard was issued. These regional and national regulations are subject to revision or may be superseded. Regulatory requirements that do not affect interoperability are not addressed in this standard. Implementers are referred to the regulatory sources in Table D-1 for further information. Operation in countries within defined regulatory domains may be subject to additional or alternative national regulations. The documents listed in Table D-1 specify current regulatory requirements for various frequency bands and geographic areas at the time this standard was developed. They are provided for information only and are subject to change or revision at any time. Table D-1â€”Regulatory requirement list Geographic Approval Approval standards Documents area authority Canada Minister of Industry RSS-210 â€” License-exempt Radio Industry Apparatus (All Frequency Bands): Canada Category I Equipment China Ministry of Industry and Information Xin Bu Wu [2002] #353, MIIT Technology (MIIT) Xin Bu Wu [2002] #277, Gong Xin Bu Wu Han [2012] #620 Europe European Conference of Postal and ECC DEC (04) 08, CEPT Telecommunications (CEPT) ETSI EN 300 328 [B13], Administrations and its Electronic ETSI EN 301 893, Communications Committee (ECC). ETSI ES 202 663 [B15], Also, European Radiocommunications ETSI EN 302 571 [B14], Clause 5 Office, European Telecommunications Standards Institute (ETSI) Japan Ministry of Internal Affairs and MIC Equipment Ordinance (EO) for MIC Communications (MIC) Regulating Radio Equipment Articles 7, 49.20, 49.21a 3269 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table D-1â€”Regulatory requirement list (continued) Geographic Approval Approval standards Documents area authority United States Federal Communications Commission 47 CFR [B9], Part 15, FCC (FCC) Sections 15.205, 15.209, 15.247 and 15.255; and Subpart E, Sections 15.401â€“15.407, and Subpart H, Sections 15.701â€“15.716, Section 90.210, Sections 90.371â€“383, Sections 90.1201â€“90.1217, Sections 90.1301â€“90.1337, Section 95.639, Sections 95.1501â€“1511 aFrequency planning for licensed STAs in Japan is performed by the regulatory authority and the licensees, addressing the coexistence among STAs operating with a variety of air propagation times and the coexistence between STAs using 20 MHz channel spacing, STAs operating with 10 MHz channel spacing, and STAs operating with 5 MHz channel spacing. Note also the CCA mechanism is preserved in licensed operation. Behavior limits are listed in Table D-2. Table D-2â€”Behavior limits Behavior limit Description NomadicBehavior The location of the station may change but is stationary while in use. The nomadic use EIRP power limits apply if the country allows more than one transmit power limit in the band. This behavior is specified only in bands where behavior 10 License Exempt bands is also allowed. LicenseExemptBehavior Frequency bands where some fixed stations can be operated without a license at a higher radiated transmit power than permitted for nomadic use. This behavior is specified only in bands where behavior 1 nomadic use is also allowed. PrimaryChannelLowerBehaviora 20/40 MHz BSS primary channel with secondary channel above the primary channel or 20 MHz BSS primary channel operated by a 40MC HT AP and also 20 MHz operational channel for a non-AP STA when the non-AP STA is associated with a 40MC HT AP. See NOTE. PrimaryChannelUpperBehaviora 14 20/40 MHz BSS primary channel with secondary channel below the primary channel or 20 MHz BSS primary channel operated by a 40MC HT AP and also 20 MHz operational channel for a non-AP STA when the non- AP STA is associated with a 40MC HT AP. See NOTE. CCA-EDBehaviorb The PHY shall also indicate a medium busy condition when CCA- EnergyDetect detects a channel busy condition. DFS_50_100_Behavior A station operating in a band where radiolocation radar is primary, and station operation has in-service monitoring requirements for 50-100 Âµs radar pulses. ITS_nonmobile_operations Operations related to an ITS station operating at a fixed location registered with regulatory authorities, e.g., a Dedicated Short Range Communication Services (DSRCS) Roadside Unit (RSU). 3270 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table D-2â€”Behavior limits (continued) Behavior limit Description ITS_mobile_operations Operations related to an ITS mobile station, e.g., a vehicleâ€™s DSRCS On- board Unit (OBU). 80+ In a channel width that contains two or more frequency segments, the frequency segment that does not contain the primary 80 MHz channel (see NOTE 2) UseEirpForVHTTxPowEnv A STA that sends one or more Transmit Power Envelope elements shall indicate EIRP in the Local Maximum Transmit Power Unit Interpretation subfield in one of the Transmit Power Envelope elements GeoDB A STA operating in a TVWS band where broadcast TV operation is primary and STA operation has GDB requirements. When operating in TVWS, channel numbers are as assigned in regulation. NOTE 1â€”The fields that specify the 40 MHz channels are described in 19.3.15.4. NOTE 2â€”For an example using an operating class with an 80+ Behavior limit, see 9.4.2.9. The maximum number of frequency segments is PHY dependent. aFor 20 MHz operation where the operating class signifies 40 MHz channel spacing, the 20 MHz channel corresponds to the channel number indicated. bProcedures that may be used to improve sharing spectrum in addition to explicit regulatory requirements. D.2 Radio performance specifications D.2.1 Transmit and receive in-band and out-of-band spurious emissions Spurious transmissions shall comply with national regulations. D.2.2 Transmit power levels The maximum allowable output power is measured in accordance with practices specified by the appropriate regulatory bodies. The maximum allowable STA transmit power classifications for ITS nonmobile operations in the U.S. 5.85â€“ 5.925 GHz band are shown in Table D-3. Table D-3â€”Maximum STA transmit power classification for the 5.85â€“5.925 GHz band in the United States STA transmit power Maximum STA transmit power Maximum permitted EIRP classification (mW) (dBm) A 1 23 B 10 23 C 100 33 D 760 33 for nongovernment Note that for this class higher power is permitted as long as the power level is reduced to this level 44.8 for government at the antenna input and the emission mask specifications are met. 3271 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications D.2.3 Transmit spectrum mask Transmit spectrum masks defined in regulation are subject to change or revision at any time. For operation in the 5.85â€“5.925 GHz band the transmitted spectrum shall be as follows: a) For any STA using 5 MHz channel spacing, the transmitted spectral density shall have a 0 dBr bandwidth not exceeding 4.5 MHz and shall not exceed the spectrum mask created using the permitted power spectral density levels listed in Table D-4 for the transmit power class of the STA. b) For any STA using 10 MHz channel spacing, the transmitted spectral density shall have a 0 dBr bandwidth not exceeding 9 MHz and shall not exceed the spectrum mask created using the permitted power spectral density levels listed in Table D-5 for the transmit power class of the STA. c) For any STA using 20 MHz channel spacing, the transmitted spectral density shall have a 0 dBr bandwidth not exceeding 18 MHz and shall not exceed the spectrum mask created using the permitted power spectral density levels listed in Table D-6 for the transmit power class of the STA. Table D-4â€”Spectrum mask data for 5 MHz channel spacing Permitted power spectral density, dBr STA transmit power class Â± 2.25 MHz Â± 2.5 MHz Â± 2.75 MHz Â±5 MHz Â± 7.5 MHz offset offset offset offset offset (Â±f1) (Â±f2) (Â±f3) (Â±f4) (Â±f5) Class A 0 â€“10 â€“20 â€“28 â€“40 Class B 0 â€“16 â€“20 â€“28 â€“40 Class C 0 â€“26 â€“32 â€“40 â€“50 Class D 0 â€“35 â€“45 â€“55 â€“65 Table D-5â€”Spectrum mask data for 10 MHz channel spacing Permitted power spectral density, dBr STA transmit power class Â± 4.5 MHz Â± 5.0 MHz Â± 5.5 MHz Â± 10 MHz Â± 15 MHz offset offset offset offset offset (Â±f1) (Â±f2) (Â±f3) (Â±f4) (Â±f5) Class A 0 â€“10 â€“20 â€“28 â€“40 Class B 0 â€“16 â€“20 â€“28 â€“40 Class C 0 â€“26 â€“32 â€“40 â€“50 Class D 0 â€“35 â€“45 â€“55 â€“65 3272 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table D-6â€”Spectrum mask data for 20 MHz channel spacing Permitted power spectral density, dBr STA transmit power class Â± 10.0 MHz Â± 11 MHz Â± 20 MHz Â± 30 MHz Â± 9 MHz offset offset offset offset offset (Â±f1) (Â±f2) (Â±f3) (Â±f4) (Â±f5) Class A 0 â€“10 â€“20 â€“28 â€“40 Class B 0 â€“16 â€“20 â€“28 â€“40 Class C 0 â€“26 â€“32 â€“40 â€“50 Class D 0 â€“35 â€“45 â€“55 â€“65 The transmit spectral mask is created and applied as shown in Figure D-1 about the channel center frequency (Fc) defined by the channel starting frequency and channel number from the operating class. The 0 dBr level is the maximum power spectral density measured in the channel. The measurements of transmit spectral density are made using a 100 kHz resolution bandwidth and a 30 kHz video bandwidth. Power Spectral Density (dB) Permitted Level at f1 (0dBr) Transmit Spectrum Mask (not to scale) Example Signal Spectrum Permitted Level at f2 (not to scale) Permitted Level at f3 Permitted Level at f4 Permitted Level at f5 -f5 -f4 -f3 -f1 -f2 Fc +f1 +f2 +f3 +f4 +f5 Frequency (MHz) Figure D-1â€”Transmit spectrum mask and application D.2.4 Transmit Mask M This subclause defines the characteristics of transmit mask M. The power spectral density of the emissions shall be attenuated below the output power of the transmitter as follows: a) On any frequency removed from the center frequency between 0-45% of the channel bandwidth (BW): 0 dB. b) On any frequency removed from the center frequency between 45-50% of the channel bandwidth: 568 log (% of (BW)/45) dB. 3273 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications c) On any frequency removed from the center frequency between 50-55% of the channel bandwidth: 26 + 145 log (% of BW/50) dB. d) On any frequency removed from the center frequency between 55-100% of the channel bandwidth: 32 + 31 log (% of (BW)/55) dB. e) On any frequency removed from the center frequency between 100-150% of the channel bandwidth: 40 + 57 log (% of (BW)/100) dB. f) On any frequency removed from the center frequency between above 150% of the channel band- width: 50 dB or 55 + 10 log (P) dB, whichever is the lesser attenuation. g) The 0 dB reference is measured relative to the highest average power of the fundamental emission measured across the designated channel bandwidth using a resolution bandwidth of 100 kHz and a video bandwidth of 30 kHz. The power spectral density is the power measured within the resolution bandwidth of the measurement device divided by the resolution bandwidth of the measurement device. Emission levels are also based on the use of measurement instrumentation employing a reso- lution bandwidth of at least one percent of the occupied bandwidth. D.2.5 CCA-ED threshold CCA-ED thresholds for operation in specific bands are given in E.2. 3274 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Annex E (normative) Country elements and operating classes E.1 Country information and operating classes WLANs implemented in accordance with this standard and the specifications and definitions referenced in it may be subject to equipment certification and operating requirements established by regional and national regulatory administrations. The specification establishes minimum technical requirements for interoperability, taking into consideration established regulations at the time this standard was issued. These regional and national regulations may be revised or may be superseded. Regulatory requirements that do not affect interoperability are not addressed in this standard. Implementers are referred to the regulatory sources in Table D-1 and their successors for further information. Operation in countries within defined regulatory domains may be subject to additional or alternative national regulations. The Country element (see 9.4.2.9) allows a STA to configure its PHY and MAC for operation when the Operating Triplet field is present. The Operating Triplet field indicates both PHY and MAC configuration characteristics and operational characteristics. The First Channel Number field of subsequent Subband Triplet fields is based on the dot11ChannelStartingFactor that is indicated by the Operating Class field. The operating class is an index into a set of values for radio operation in a regulatory domain. The operating class tables also contain pointers to behaviors and signal detection limits in Annex D where further operational requirements may be found. The channel starting frequency variable is a frequency, used together with an operating class number and a channel number, to calculate a channel center frequency. A â€œâ€”â€ in the Channel starting frequency column of the operating classes tables (Table E-1 through Table E-5) indicates the channel starting frequency is not defined by the operating class and is derived from regulation. Channel spacing is the frequency difference between nonoverlapping adjacent channel center frequencies when using the maximum bandwidth of one frequency segment allowed for this operating class. The channel set is the list of integer channel numbers that are legal for a regulatory domain and class. A â€œâ€” â€ in the Channel set column of the operating classes tables (Table E-1 through Table E-5) indicates either that the values in the channel center frequency index field apply for calculating channel center frequencies of this operating class, or where both the channel set field and the channel center frequency index field are â€œâ€”â€ indicates that the channel set is not defined by the operating class and is derived from regulation. The channel center frequency index is the set of integer channel numbers that correspond to frequency segments and that are allowed for the operating class. Aâ€œâ€”â€ in the Channel center frequency index column of the operating classes tables (Table E-1 through Table E-5) indicates either that the values in the channel set field apply for calculating channel center frequencies of this operating class or, when both the Channel set and the Channel center frequency index column of the operating classes tables (Table E-1 through Table E-5) are â€œâ€”â€, indicates that the channel center frequency index is not defined by the operating class and is derived from regulation. A behavior limits set is an enumerated list, each element of which points to a row in Table D-2 containing behavior limits in various regulatory domains. 3275 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Operating classes for operation in the United States are enumerated in Table E-1. Table E-1â€”Operating classes in the United States Global Channel Channel Channel Operating operating starting spacing Channel set center Behavior limits set class class (see frequency frequency Table E-4) (GHz) (MHz) index 1 115 5 20 36, 40, 44, 48 â€” 2 118 5 20 52, 56, 60, 64 â€” DFS_50_100_Behavior 3 124 5 20 149, 153, 157, 161 â€” NomadicBehavior 4 121 5 20 100, 104, 108, 112, â€” DFS_50_100_Behavior, 116, 120, 124, 128, UseEirpForVHTTxPowEnv 132, 136, 140, 144 5 125 5 20 149, 153, 157, 161, â€” LicenseExemptBehavior 165 6 103 4.9375 5 1, 2, 3, 4, 5, 6, 7, 8, â€” 9, 10 7 103 4.9375 5 1, 2, 3, 4, 5, 6, 7, 8, â€” 9, 10 8 102 4.89 10 11, 13, 15, 17, 19 â€” 9 102 4.89 10 11, 13, 15, 17, 19 â€” 10 101 4.85 20 21, 25 â€” 11 101 4.85 20 21, 25 â€” 12 81 2.407 25 1, 2, 3, 4, 5, 6, 7, 8, â€” LicenseExemptBehavior 9, 10, 11 13 94 3.000 20 133, 137 â€” CCA-EDBehavior 14 95 3.000 10 132, 134, 136, 138 â€” CCA-EDBehavior 15 96 3.0025 5 131, 132, 133, 134, â€” CCA-EDBehavior 135, 136, 137, 138 16a â€” 5.0025 5 170â€“184 â€” ITS_nonmobile_operations, ITS_mobile_operations 17a, b â€” 5 10 171â€“184 â€” ITS_nonmobile_operations, ITS_mobile_operations 18a, b â€” 5 20 172â€“183 â€” ITS_nonmobile_operations, ITS_mobile_operations 19â€“21 Reserved Reserved Reserved Reserved Reserved Reserved 22 116 5 40 36, 44 â€” PrimaryChannelLowerBehavior 23 119 5 40 52, 60 â€” PrimaryChannelLowerBehavior 24 122 5 40 100, 108, 116, 124, â€” PrimaryChannelLowerBehavior, 132, 140 DFS_50_100_Behavior, UseEirpForVHTTxPowEnv 25 126 5 40 149, 157 â€” PrimaryChannelLowerBehavior 26 126 5 40 149, 157 â€” LicenseExemptBehavior, PrimaryChannelLowerBehavior 27 117 5 40 40, 48 â€” PrimaryChannelUpperBehavior 3276 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table E-1â€”Operating classes in the United States (continued) Global Channel Channel Channel Operating operating starting center class class (see frequency spacing Channel set frequency Behavior limits set (MHz) Table E-4) (GHz) index 28 120 5 40 56, 64 â€” PrimaryChannelUpperBehavior 29 123 5 40 104, 112, 120, 128, â€” NomadicBehavior, 136, 144 PrimaryChannelUpperBehavior, DFS_50_100_Behavior, UseEirpForVHTTxPowEnv 30 127 5 40 153, 161 â€” NomadicBehavior, PrimaryChannelUpperBehavior 31 127 5 40 153, 161 â€” LicenseExemptBehavior, PrimaryChannelUpperBehavior 32 83 2.407 40 1â€“7 â€” LicenseExemptBehavior, PrimaryChannelLowerBehavior 33 84 2.407 40 5â€“11 â€” LicenseExemptBehavior, PrimaryChannelUpperBehavior 34 180 56.16 2160 1, 2, 3, 4, 5, 6 â€” â€” 35â€“127 Reserved Reserved Reserved Reserved Reserved Reserved 128 128 5 80 â€” 42, 58, UseEirpForVHTTxPowEnv 106, 122, 138, 155 129 129 5 160 â€” 50, 114 UseEirpForVHTTxPowEnv 130 130 5 80 â€” 42, 58, 80+, 106, 122, UseEirpForVHTTxPowEnv 138, 155 131â€“255 Reserved Reserved Reserved Reserved Reserved Reserved NOTE 1â€”The channel spacing for operating classes 22 to 33 specifies the maximum radio bandwidth of one frequency segment. In these operating classes, the AP operating in a 20/40 MHz BSS, and the operating channel width for a non-AP STA is either 20 MHz or 40 MHz. NOTE 2â€”The channel spacing for operating classes 128, 129, and 130 specifies the maximum radio bandwidth of one frequency segment. aThis operating class specifies a list of channels in the 5.9 GHz band. Current regulations may only permit a subset of these channels. bIt is the responsibility of management layers outside the scope of this standard to ensure that channels in use at any location are nonoverlapping. 3277 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Operating classes for operation in Europe are enumerated in Table E-2. Table E-2â€”Operating classes in Europe Global Channel Channel Channel Operating operating starting Channel center spacing Behavior limits set class class (see frequency (MHz) set frequenc Table E-4) (GHz) y index 1 115 5 20 36, 40, â€” 44, 48 2 118 5 20 52, 56, â€” NomadicBehavior 60, 64 3 121 5 20 100, 104, â€” 108, 112, 116, 120, 124, 128, 132, 136, 140 4 81 2.407 25 1, 2, 3, 4, â€” LicenseExemptBehavior 5, 6, 7, 8, 9, 10, 11, 12, 13 5 116 5 40 36, 44 â€” PrimaryChannelLowerBehavior 6 119 5 40 52, 60 â€” PrimaryChannelLowerBehavior 7 122 5 40 100, 108, â€” PrimaryChannelLowerBehavior 116, 124, 132 8 117 5 40 40, 48 â€” PrimaryChannelUpperBehavior 9 120 5 40 56, 64 â€” PrimaryChannelUpperBehavior 10 123 5 40 104, 112, â€” PrimaryChannelUpperBehavior 120, 128, 136 11 83 2.407 40 1â€“9 â€” LicenseExemptBehavior, PrimaryChannelLowerBehavior 12 84 2.407 40 5â€“13 â€” LicenseExemptBehavior, PrimaryChannelUpperBehavior 13a â€” 5.0025 5 171â€“184 â€” ITS_nonmobile_operations, ITS_mobile_operations 14a, b â€” 5 10 171â€“184 â€” ITS_nonmobile_operations, ITS_mobile_operations 15a, b â€” 5 20 172â€“183 â€” ITS_nonmobile_operations, ITS_mobile_operations 16 â€” 5 20 100, 104, â€” ITS_nonmobile_operations, 108, 112, ITS_mobile_operations 116, 120, 124, 128, 132, 136, 140 3278 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table E-2â€”Operating classes in Europe (continued) Global Channel Channel Channel Operating operating starting Channel center spacing Behavior limits set class class (see frequency (MHz) set frequenc Table E-4) (GHz) y index 17 125 5 20 149, 153, â€” 157, 161, 165, 169 18 180 56.16 2160 1, 2, 3, 4 â€” â€” 19â€“127 Reserved Reserved Reserved Reserved Reserved Reserved 128 128 5 80 â€” 42, 58, UseEirpForVHTTxPowEnv 106, 122 129 129 5 160 â€” 50, 114 UseEirpForVHTTxPowEnv 130 130 5 80 â€” 42, 58, 80+, 106, 122 UseEirpForVHTTxPowEnv 131â€“255 Reserved Reserved Reserved Reserved Reserved Reserved NOTE 1â€”The channel spacing for operating classes 5 to 12 specifies the maximum radio bandwidth of one frequency segment In these operating classes, the AP operates in a 20/40 MHz BSS, and the operating channel width for a non-AP STA is either 20 MHz or 40 MHz. NOTE 2â€”The channel spacing for operating classes 128, 129, and 130 specifies the maximum radio bandwidth of one frequency segment. aThis operating class specifies a list of channels in the 5.9 GHz band. Current regulations may only permit a subset of these channels. bIt is the responsibility of management layers outside the scope of this standard to ensure that channels in use at any location are nonoverlapping. Operating classes for operation in Japan are enumerated in Table E-3. Note that some of the operating classes in this table were never used and are obsolete. The obsolete operating classes indicated by an asterisk (*) might be removed in a future revision of the standard. Table E-3â€”Operating classes in Japan Global Channel Channel Channel Operating operating starting center spacing Channel set Behavior limits set class class (see frequency frequency (MHz) Table E-4) (GHz) index 1 115 5 20 34, 38, 42, 46a â€” 36, 40, 44, 48 2* 112 5 20 8, 12, 16 â€” 3 112 5 20 8, 12, 16 â€” 4* 112 5 20 8, 12, 16 â€” 5* 112 5 20 8, 12, 16 â€” 6 112 5 20 8, 12, 16 â€” 3279 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table E-3â€”Operating classes in Japan (continued) Global Channel Channel Channel Operating operating starting center spacing Channel set Behavior limits set class class (see frequency frequency (MHz) Table E-4) (GHz) index 7* 109 4 20 184, 188, 192, â€” 196 8 109 4 20 184, 188, 192, â€” 196 9* 109 4 20 184, 188, 192, â€” 196 10* 109 4 20 184, 188, 192, â€” 196 11 109 4 20 184, 188, 192, â€” 196 12* 113 5 10 7, 8, 9, 11 â€” 13 113 5 10 7, 8, 9, 11 â€” 14* 113 5 10 7, 8, 9, 11 â€” 15* 113 5 10 7, 8, 9, 11 â€” 16* 110 4 10 183, 184, 185, â€” 187, 188, 189 17 110 4 10 183, 184, 185, â€” 187, 188, 189 18* 110 4 10 183, 184, 185, â€” 187, 188, 189 19* 110 4 10 183, 184, 185, â€” 187, 188, 189 20 110 4 10 183, 184, 185, â€” 187, 188, 189 21* 114 5.0025 5 6, 7, 8, 9, 10, 11 â€” 22 114 5.0025 5 6, 7, 8, 9, 10, 11 â€” 23* 114 5.0025 5 6, 7, 8, 9, 10, 11 â€” 24* 114 5.0025 5 6, 7, 8, 9, 10, 11 â€” 25 111 4.0025 5 182, 183, 184, â€” 185, 186, 187, 188, 189 26 111 4.0025 5 182, 183, 184, â€” 185, 186, 187, 188, 189 27* 111 4.0025 5 182, 183, 184, â€” 185, 186, 187, 188, 189 3280 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table E-3â€”Operating classes in Japan (continued) Global Channel Channel Channel Operating operating starting center spacing Channel set Behavior limits set class class (see frequency frequency (MHz) Table E-4) (GHz) index 28* 111 4.0025 5 182, 183, 184, â€” 185, 186, 187, 188, 189 29 111 4.0025 5 182, 183, 184, â€” 185, 186, 187, 188, 189 30 81 2.407 25 1, 2, 3, 4, 5, 6, 7, â€” LicenseExemptBehavior 8, 9, 10, 11, 12, 13 31 82 2.414 25 14 â€” LicenseExemptBehavior 32 118 5 20 52, 56, 60, 64 â€” 33 118 5 20 52, 56, 60, 64 â€” 34 121 5 20 100, 104, 108, â€” DFS_50_100_Behavior 112, 116, 120, 124, 128, 132, 136, 140 35* 121 5 20 100, 104, 108, â€” DFS_50_100_Behavior 112, 116, 120, 124, 128, 132, 136, 140 36 116 5 40 36, 44 â€” PrimaryChannelLowerBehavior 37 119 5 40 52, 60 â€” PrimaryChannelLowerBehavior 38* 119 5 40 52, 60 â€” PrimaryChannelLowerBehavior 39 122 5 40 100, 108, 116, â€” PrimaryChannelLowerBehavior, 124, 132 DFS_50_100_Behavior 40* 122 5 40 100, 108, 116, â€” PrimaryChannelLowerBehavior, 124, 132 DFS_50_100_Behavior 41 117 5 40 40, 48 â€” PrimaryChannelUpperBehavior 42 120 5 40 56, 64 â€” PrimaryChannelUpperBehavior 43* 120 5 40 56, 64 â€” PrimaryChannelUpperBehavior 44 123 5 40 104, 112, 120, â€” PrimaryChannelUpperBehavior, 128, 136 DFS_50_100_Behavior 45* 123 5 40 104, 112, 120, â€” PrimaryChannelUpperBehavior, 128, 136 DFS_50_100_Behavior 46 104 4 40 184, 192 â€” PrimaryChannelLowerBehavior 47* 104 4 40 184, 192 â€” PrimaryChannelLowerBehavior 48* 104 4 40 184, 192 â€” PrimaryChannelLowerBehavior 49* 104 4 40 184, 192 â€” PrimaryChannelLowerBehavior 3281 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table E-3â€”Operating classes in Japan (continued) Global Channel Channel Channel Operating operating starting center spacing Channel set Behavior limits set class class (see frequency frequency (MHz) Table E-4) (GHz) index 50* 104 4 40 184, 192 â€” PrimaryChannelLowerBehavior 51 105 4 40 188, 196 â€” PrimaryChannelUpperBehavior 52* 105 4 40 188, 196 â€” PrimaryChannelUpperBehavior 53* 105 4 40 188, 196 â€” PrimaryChannelUpperBehavior 54* 105 4 40 188, 196 â€” PrimaryChannelUpperBehavior 55* 105 4 40 188, 196 â€” PrimaryChannelUpperBehavior 56 83 2.407 40 1â€“9 â€” LicenseExemptBehavior, PrimaryChannelLowerBehavior 57 84 2.407 40 5â€“13 â€” LicenseExemptBehavior, PrimaryChannelUpperBehavior 58 121 5 20 100, 104, 108, â€” NomadicBehavior, 112, 116, 120, LicenseExemptBehavior 124, 128, 132, 136, 140 59 180 56.16 2160 1, 2, 3, 4 â€” â€” 60â€“127 Reserved Reserved Reserved Reserved Reserved Reserved 128 128 5 80 â€” 42, 58, 106, UseEirpForVHTTxPowEnv 122 129 129 5 160 â€” 50, 114 UseEirpForVHTTxPowEnv 130 130 5 80 â€” 42, 58, 106, 80+, 122 UseEirpForVHTTxPowEnv 131â€“255 Reserved Reserved Reserved Reserved Reserved Reserved NOTE 1â€”The channel spacing for operating classes 34â€“55 specifies the maximum radio bandwidth of one frequency segment In these regulatory domains, the AP operates in a 20/40 MHz BSS, and the operating channel width of a non- AP STA is either NOTE 2â€”The channel spacing for operating classes 128, 129, and 130 specifies the maximum radio bandwidth of one frequency segment. a The use of channels 34, 38, 42, and 46 was included in the initial 5 GHz rules in May, 2005 and cannot be used after May 2012. 3282 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Operating classes for operation anywhere in the world are enumerated in Table E-4, and are used in addition to the operating classes enumerated in Table E-1, Table E-2, Table E-3 and (see 9.4.2.54). Where a BSS includes STAs that do not support global operating classes, then all requests and Action frames to those STAs that convey elements containing operating classes shall use nonglobal operating class values. Table E-4â€”Global operating classes Channel Channel Nonglobal Channel Operating starting Channel center operating spacing Behavior limits set class frequency set frequency class(es) (MHz) (GHz) index 1â€“80 â€” Reserved Reserved Reserved â€” Reserved 81 E-1-12, 2.407 25 1, 2, 3, 4, â€” E-2-4, 5, 6, 7, 8, E-3-30, 9, 10, 11, E-5-7 12, 13 82 E-3-31 2.414 25 14 â€” 83 E-1-32, 2.407 40 1, 2, 3, 4, â€” PrimaryChannelLowerBehavior E-2-11, 5, 6, 7, 8, E-3-56, 9 E-5-8 84 E-1-33, 2.407 40 5, 6, 7, 8, â€” PrimaryChannelUpperBehavior E-2-12, 9, 10, 11, E-3-57, 12, 13 E-5-9 85 â€” â€” 6, 7, 8 â€” â€” GeoDB 86 â€” â€” 12, 14, 16 â€” â€” GeoDB 87 â€” â€” 24, 28, 32 â€” â€” GeoDB 88-93 â€” Reserved Reserved Reserved Reserved Reserved 94 E-1-13 3 20 133, 137 â€” CCA-EDBehavior 95 E-1-14 3 10 132, 134, â€” CCA-EDBehavior 136, 138 96 E-1-15 3.0025 5 131, 132, â€” CCA-EDBehavior 133, 134, 135, 136, 137, 138 97â€“100 â€” Reserved Reserved Reserved Reserved Reserved 101 E-1-10,11 4.85 20 21, 25 â€” 102 E-1-8,9 4.89 10 11, 13, â€” 15, 17, 19 103 E-1-6,7 4.9375 5 1, 2, 3, 4, â€” 5, 6, 7, 8, 9, 10 104 E-3- 4 40 184, 192 â€” PrimaryChannelLowerBehavior 46,47,48, 49,50 3283 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table E-4â€”Global operating classes (continued) Channel Channel Nonglobal Channel Operating starting Channel center operating spacing Behavior limits set class frequency set frequency class(es) (MHz) (GHz) index 105 E-3- 4 40 188, 196 â€” PrimaryChannelUpperBehavior 51,52,53, 54,55 106 â€” 4 20 191, 195 â€” 107 â€” 4 10 189, 191, â€” 193, 195, 197 108 â€” 4.0025 5 188, 189, â€” 190, 191, 192, 193, 194, 195, 196, 197 109 E-3- 4 20 184, 188, â€” 7,8,9,10,11 192, 196 110 E-3- 4 10 183, 184, â€” 16,17,18, 185, 186, 19,20 187, 188, 189 111 E-3- 4.0025 5 182, 183, â€” 25,26,27, 184, 185, 28,29 186, 187, 188, 189 112 E-3- 5 20 8, 12, 16 â€” 2,3,4,5,6 113 E-3- 5 10 7, 8, 9, â€” 12,13,14,15 10, 11 114 E-3- 5.0025 5 6, 7, 8, 9, â€” 21,22,23,24 10, 11 115 E-1-1, 5 20 36, 40, â€” UseEirpForVHTTxPowEnv E-2-1, 44, 48 E-3-1, E-5-1 116 E-1-22, 5 40 36, 44 â€” PrimaryChannelLowerBehavior, E-2-5, UseEirpForVHTTxPowEnv E-3-36, E-5-4 117 E-1-27, 5 40 40, 48 â€” PrimaryChannelUpperBehavior, E-2-8, UseEirpForVHTTxPowEnv E-3-41 118 E-1-2, 5 20 52, 56, â€” DFS_50_100_Behavior, E-2-2, 60, 64 UseEirpForVHTTxPowEnv E-3-32,33, E-5-2 3284 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table E-4â€”Global operating classes (continued) Channel Channel Nonglobal Channel Operating starting Channel center operating spacing Behavior limits set class frequency set frequency class(es) (MHz) (GHz) index 119 E-1-23, 5 40 52, 60 â€” PrimaryChannelLowerBehavior, E-2-6, DFS_50_100_Behavior, E-3-37,38, UseEirpForVHTTxPowEnv E-5-5 120 E-1-28, 5 40 56, 64 â€” PrimaryChannelUpperBehavior, E-2-9, DFS_50_100_Behavior, E-3-42,43 UseEirpForVHTTxPowEnv 121 E-1-4, 5 20 100, 104, â€” DFS_50_100_Behavior, E-2-3, 108, 112, UseEirpForVHTTxPowEnv E-3-34, 116, 120, 35,58 124, 128, 132, 136, 140, 144 122 E-1-24, 5 40 100, 108, â€” PrimaryChannelLowerBehavior, E-2-7, 116, 124, DFS_50_100_Behavior, E-3-39,40 132, 140 UseEirpForVHTTxPowEnv 123 E-1-29, 5 40 104, 112, â€” PrimaryChannelUpperBehavior, E-2-10, 120, 128, DFS_50_100_Behavior, E-3-44,45 136, 144 UseEirpForVHTTxPowEnv 124 E-1-3 5 20 149, 153, â€” NomadicBehavior, 157, 161 UseEirpForVHTTxPowEnv 125 E-1-5, 5 20 149, 153, â€” LicenseExemptBehavior, E-2-17, 157, 161, UseEirpForVHTTxPowEnv E-5-3 165, 169 126 E-1-25,26, 5 40 149, 157 â€” PrimaryChannelLowerBehavior, E-5-6 UseEirpForVHTTxPowEnv 127 E-1-30,31 5 40 153, 161 â€” PrimaryChannelUpperBehavior, UseEirpForVHTTxPowEnv 128 E-1-128, 5 80 â€” 42, 58, 106, UseEirpForVHTTxPowEnv E-2-128, 122, 138, E-3-128 155 E-5-128 129 E-1-129, 5 160 â€” 50, 114 UseEirpForVHTTxPowEnv E-2-129, E-3-129 E-5-129 130 E-1-130, 5 80 â€” 42, 58, 106, 80+, E-2-130, 122, 138, UseEirpForVHTTxPowEnv E-3-130 155 E-5-130 131â€“179 â€” Reserved Reserved Reserved Reserved Reserved 180 E-1-34, 56.16 2160 1, 2, 3, 4, â€” â€” E-2-18, 5, 6 E-3-59 181â€“191 â€” Reserved Reserved Reserved â€” Reserved 3285 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table E-4â€”Global operating classes (continued) Channel Channel Nonglobal Channel Operating starting Channel center operating spacing Behavior limits set class frequency set frequency class(es) (MHz) (GHz) index 192â€“254 â€” Vendor Vendor Vendor â€” Vendor specific specific specific specific 255 â€” Reserved Reserved Reserved â€” Reserved NOTE 1â€”The channel spacing for operating classes 116, 117, 119, 120, 122, 123, 126, and 127 specifies the maximum radio bandwidth of one frequency segment In these operating classes, the AP operates in a 20/40 MHz BSS, and the operating channel width for a non-AP STA is either 20 MHz or 40 MHz. NOTE 2â€”The channel spacing for operating classes 128, 129, and 130 specifies the maximum radio bandwidth of one frequency segment. For Behavior limit GeoDB, the channel starting frequency shall be the frequency that results in the regulatory domainâ€™s channel number being the RLAN channel number. Operating classes for operation in China are enumerated in Table E-5. Table E-5â€”Operating classes in China Global Channel Channel Channel Operating operating starting Channel center spacing Behavior limits set class class (see frequency set frequency (MHz) Table E-4) (GHz) index 1 115 5 20 36, 40, â€” UseEirpForVHTTxPowEnv 44, 48 2 118 5 20 52, 56, â€” DFS_50_100_Behavior, 60, 64 UseEirpForVHTTxPowEnv 3 125 5 20 149, 153, â€” UseEirpForVHTTxPowEnv 157, 161, 165 4 116 5 40 36, 44 â€” PrimaryChannelLowerBeha vior UseEirpForVHTTxPowEnv 5 119 5 40 52, 60 â€” PrimaryChannelLowerBeha vior DFS_50_100_Behavior UseEirpForVHTTxPowEnv 6 126 5 40 149, 157 â€” PrimaryChannelLowerBeha vior UseEirpForVHTTxPowEnv 7 81 2.407 25 1, 2, 3, 4, â€” LicenseExemptBehavior 5, 6, 7, 8, 9, 10, 11, 12, 13 8 83 2.407 40 1-9 â€” LicenseExemptBehavior, PrimaryChannelLowerBeha vior 3286 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table E-5â€”Operating classes in China (continued) Global Channel Channel Channel Operating operating starting Channel center spacing Behavior limits set class class (see frequency set frequency (MHz) Table E-4) (GHz) index 9 84 2.407 40 5-13 â€” LicenseExemptBehavior, PrimaryChannelUpperBeha vior 10â€“127 Reserved Reserved Reserved Reserved Reserved Reserved 128 128 5 80 â€” 42, 58, 155 UseEirpForVHTTxPowEnv 129 129 5 160 â€” 50 UseEirpForVHTTxPowEnv 130 130 5 80 â€” 42, 58, 155 80+ UseEirpForVHTTxPowEnv 131â€“255 Reserved Reserved Reserved Reserved Reserved Reserved NOTE 1â€”The channel spacing for operating classes 4 to 6 specifies the maximum radio bandwidth of one frequency segment In these operating classes, the AP operates in a 20/40 MHz BSS, and the operating channel width for a non- AP STA is either 20 MHz or 40 MHz. NOTE 2â€”The channel spacing for operating classes 128, 129, and 130 specifies the maximum radio bandwidth of one frequency segment. Nonglobal operating classes refer to the operating classes enumerated in the leftmost column of Table E-1, Table E-2, Table E-3, and Table E-5 (see 9.4.2.54). NOTE 1â€”The following example Country element (see Figure 9-130) describes U.S. operation (â€˜55â€™, â€˜53â€™) using both Table E-1 class 12 (nonglobal) and Table E-4 class 81 (global) for the 2.4 GHz band, 11 channels at 20 dBm limit (in hexadecimal): â€˜07â€™, â€˜0Fâ€™, â€˜55â€™, â€˜53â€™, â€˜04â€™, â€˜C9â€™, â€˜0Câ€™, â€˜0â€™, â€˜01â€™, â€˜0Bâ€™, â€˜14â€™, â€˜C9â€™, â€˜51â€™, â€˜0â€™, â€˜01â€™, â€˜0Bâ€™, â€˜14â€™. NOTE 2â€”The following example Country element describes U.S. operation for an 80+80 MHz BSS using Table E-4 classes 116, 128 and 130 at a 100 mW limit for 40 MHz. The contents (in decimal) are '07' [Country element ID], '18' [Length], '85', '83', '04' [Country string indicating United States and Table E-4], '201', '116', '0' [Operating Triplet field for 20/40 MHz with the primary 20 MHz channel on the lower 20 MHz], '36', '1', '20' [Subband triplet field indicating 20 dBm on the 40 MHz channel 36+40], '201','128', '0' [Operating Triplet field for 80 MHz], '201', '130', '0', '201', '128', '0' [Pair of Operating Triplet field indicating 80+80 MHz]. Although the Operating Triplet fields for 80 MHz and 80+80 MHz only express BSS bandwidths rather than specific regulatory permissions (so are optional), they are included in this example. Vendor Specific operating classes are used to carry information not defined in this standard within a single defined format, so that reserved operating classes are not usurped for nonstandard purposes and so that interoperability is more easily achieved in the presence of nonstandard information. E.2 Band-specific operating requirements E.2.1 General Subclause E.2 contains requirements specific to particular bands and regulatory domains. E.2.2 3650â€“3700 MHz in the United States The registration authority is the FCCâ€™s Universal Licensing System (ULS). 3287 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Regulations specify the following: â€” Certified mobile and portable STAs do not need to be registered, but they â€œmustâ€ operate under the control of an enabling STA (using DSE procedures). â€” A registered STA â€œmustâ€ be a fixed STA. â€” A registered STA â€œmustâ€ not operate as an enabling STA until the licensee has registered it as a â€œbase stationâ€ in ULS. Enabling STAs and fixed STAs are registered STAs. Dependent non-AP STAs and dependent APs are dependent STAs. A STA shall use the following: â€” CCA-ED â€” CS/CCA â€” TPC â€” DFS For OFDM PHY operation in this specific band, the CCA-ED thresholds shall be less than or equal to â€“72 dBm for 20 MHz channel widths, â€“75 dBm for 10 MHz channel widths, and â€“78 dBm for 5 MHz channel widths (minimum sensitivity for BPSK, R=1/2 + 10 dB in Table 17-18). No STA shall use channel switch announcement. No station may transmit for more than 4 ms without carrier sensing, whether transmitting fragments or frames, unless it is controlled by another STA. A STA shall have the following equal to true: â€” dot11LCIDSERequired â€” dot11SpectrumManagementRequired â€” dot11MultiDomainCapabilityActivated â€” dot11ExtendedChannelSwitchActivated A STA shall be capable of receiving all channels associated with operating classes 13â€“15. A STA shall be capable of transmitting on all channels associated with operating class 15. A STA shall set the value of dot11DSETransmitDivisor to 256 and the other dot11DSE timer values as shown in Table E-6. Table E-6â€”DSE timer limits Parameter Seconds dot11DSEEnablementTimeLimit 32 dot11DSEEnablementFailHoldTime 512 dot11DSERenewalTime 60 3288 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications E.2.3 5.9 GHz band in the United States (5.850â€“5.925 GHz) STAs operating with a behavior limit of ITS_nonmobile_operations in Table D-2 are required to be registered with the FCC ULS. The registration includes the following: â€” Classification by coverage size, which is defined by EIRP, and â€” Identification of channels the STA is permitted to use. A STA shall be classified for operation in this band by their maximum transmit power capability, as listed in Table D-3 in D.2.2. A STA shall be compliant with the spectral emission requirements for their class listed in D.2.3. A STA shall have dot11OCBActivated equal to true. EPD as defined in IEEE Std 802-2014 shall be used for transmission of all MSDUs. E.2.4 5.9 GHz band in Europe (5.855â€“5.925 GHz) A STA shall have dot11OCBActivated equal to true. EPD as defined in IEEE Std 802-2014 shall be used for transmission of all MSDUs. E.2.5 TVWS band in the United States and Canada (54 MHz to 698 MHz) Each GDD enabling STA and AP in TVWS determines the available TV channels at its location using its own geographic location identification and TV bands database access capabilities. Each GDD dependent STA in TVWS receives an available TV channel list from the STA that enables its operation. The registration authorities are FCC designated TV bands administrators (FCC 47 CFR [B9], sections 15.713-715). NOTEâ€”IEEE 802.11 terms differ from FCC 47 CFR [B9], section 15.703, in many particulars. However, generally, a GDD enabling STA is Fixed or Mode II TVBD, and each GDD dependent STA has only one GDD enabling STA at any time. Generally, GDD dependent STAs are Mode I TVBDs. Each Fixed or Mode II TVBD is required to contact an authorized TV bands device database and operate based on the information received from that TV bands database. Fixed and Mode II TVBDs are certified to operate with specific TV bands databases using protocols specified by TV bands database administrators. FCC regulations require an encrypted Contact Verification Signal be received by Mode I TVBD to verify the integrity of the list of available channels FCC 47 CFR, section 15.711. Canadian regulation RSS-196 allows Remote Rural Broadband operation at transmit powers to 125 W in 6 MHz. The Canadian Minister of Industry held a consultation documented in SMSE-012-12, wherein a decision to act in concert with FCC license-exempt low power regulations was taken. It is expected that Canadian RSS-210 will be revised to align with FCC 47 CFR, Part 15, Subpart H-Television Band Devices. STAs operating in TVWS shall use â€” CS/CCA â€” DFS No STA operating in TVWS shall use Channel Switch Announcement. STAs operating in TVWS shall have the following equal to true â€” dot11GDDActivated â€” dot11OperatingClassesRequired â€” dot11SpectrumManagementRequired 3289 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” dot11MultiDomainCapabilityActivated â€” dot11ContactVerificationSignalActivated For GDD dependent STA operation in TVWS, the GDD enabling signal (see 11.44.2) is received directly from a GDD enabling STA and is a Beacon frame or Probe Response frame containing a Geodatabase Inband Enabling Signal field indicating that enablement in the frequency band is possible. All GDD dependent STAs shall set the dot11GDD timer values as shown in Table E-7. Table E-7â€”TVWS GDD timer limits Parameter Seconds dot11GDDEnablementTimeLimit 32 dot11GDDEnablementFailHoldTime 512 dot11ContactVerificationSignalInterval 60 dot11GDDEnablementValidityTimer 60 NOTEâ€”Be aware that most protocols above the MAC operate in the opposite endianness from what is used in Table E-8 and Table E-9. The Device Identification Information format is shown in Table E-8. Table E-8â€”Device Identification Information Value fields Length Scope/ Name Type Value (octets) Country code FCC ID 4 14 The device identification contains the 14-octet FCC US ID of the device. Industry Canada 5 11 The device identification contains the 11-octet CA ID Industry Canada ID of the device. This value not present in the United States. Device Serial 6 4 The Device Serial Number field contains the US Number manufacturerâ€™s serial number. This field is present only if the Device Class field (Table 9-264) is equal to 2 (GDD AP) or 3 (GDD fixed STA); otherwise, this field is not present. The WSM Information Value fields format is shown in Table E-9. In some regulatory domains, an AP can retrieve the WSM information from the GDB through the upper layer protocol (e.g., IETF Protocol to Access WS database â€˜paws-protocolâ€™). When the AP retrieves the WSM information from the upper layer, it may translate it to the WSM Information field format shown in Table E-9, which is the link-layer-specific information. NOTEâ€”In the United States, an example of full Map 1 for a U.S. GDD non-AP STA describing two available channels with power limits of 100 mW and 40 mW is shown as 85, 0x06, 0x00, 0x03, 0x15, 0x28, 0x33, 0x20. Type is 85, Length is 0x06, Device Class is 0x00, a full map with MapID 1 is 0x03, TV channel 21 is 0x15, 20 dBm Maximum Power Level is 0x28, TV channel 51 is 0x33, 16 dBm Maximum Power Level is 0x20. 3290 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table E-9â€”WSM Information Value fields Scope/ Length Name Value Country (octets) code Device Class 1 Single octet TLV comprising fields in Table 9-264. WSM Map ID 1 Bit 0: The Type bit, which indicates whether the following WSM channel list is a full channel list or a partial channel list. If the Type bit is 1, the following channel list is a full channel list; and if the Type bit is 0, the following channel list is a partial channel list. Bits 1â€“7: The Map version field, which identifies the version of the WSM. Channel Number 1 The Channel Number field is a positive integer value as defined WSM, US in E.1 that indicates the available TV channel for WLAN operation. When the Channel Number field and Maximum Power Level field pairs are repeated, they are listed in ascending TV channel order. Maximum Power 1 The Maximum Power Level field indicates the maximum WSM, US Level power, in units of 0.5 dBm, allowed to be transmitted on the channel indicated in the Channel Number field. E.2.6 TVWS band in Europe Each GDD enabling STA and AP in TVWS determines the available TV channels at its location using its own geographic location identification and TV bands database access capabilities. Each GDD dependent STA in TVWS receives an available TV channel list from the STA that enables its operation. The Harmonized Standard for unlicensed device operation in TVWS is EN 301 598. STAs operating in TVWS shall use: â€” CS/CCA â€” DFS No STA operating in TVWS shall use Channel Switch Announcement. STAs operating in TVWS shall have the following equal to true â€” dot11GDDActivated â€” dot11OperatingClassesRequired â€” dot11SpectrumManagementRequired â€” dot11MultiDomainCapabilityActivated â€” dot11ContactVerificationSignalActivated For GDD dependent STA operation in TVWS, the GDD enabling signal (see 11.44.2) is received directly from a GDD enabling STA and is a Beacon frame or Probe Response frame containing a Geodatabase Inband Enabling Signal field indicating that enablement in the frequency band is possible. 3291 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications All GDD dependent STAs shall set the dot11GDD timer values as shown in Table E-10. Table E-10â€”TVWS GDD timer limits Parameter Seconds dot11GDDEnablementTimeLimit 32 dot11GDDEnablementFailHoldTime 512 dot11ContactVerificationSignalInterval 60 dot11GDDEnablementValidityTimer 60 3292 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Annex F (normative) HT LDPC matrix definitions Table F-1 defines the matrix prototypes of the parity-check matrices for a codeword block length n = 648 bits, with a subblock size Z = 27 bits. Table F-1â€”Matrix prototypes for codeword block length n = 648 bits, subblock size is Z = 27 bits (a) Coding rate R = 1/2. 0 - - - 0 0 - - 0 - - 0 1 0 - - - - - - - - - - 22 0 - - 17 - 0 0 12 - - - - 0 0 - - - - - - - - - 6 - 0 - 10 - - - 24 - 0 - - - 0 0 - - - - - - - - 2 - - 0 20 - - - 25 0 - - - - - 0 0 - - - - - - - 23 - - - 3 - - - 0 - 9 11 - - - - 0 0 - - - - - - 24 - 23 1 17 - 3 - 10 - - - - - - - - 0 0 - - - - - 25 - - - 8 - - - 7 18 - - 0 - - - - - 0 0 - - - - 13 24 - - 0 - 8 - 6 - - - - - - - - - - 0 0 - - - 7 20 - 16 22 10 - - 23 - - - - - - - - - - - 0 0 - - 11 - - - 19 - - - 13 - 3 17 - - - - - - - - - 0 0 - 25 - 8 - 23 18 - 14 9 - - - - - - - - - - - - - 0 0 3 - - - 16 - - 2 25 5 - - 1 - - - - - - - - - - 0 (b) Coding rate R = 2/3. 25 26 14 - 20 - 2 - 4 - - 8 - 16 - 18 1 0 - - - - - - 10 9 15 11 - 0 - 1 - - 18 - 8 - 10 - - 0 0 - - - - - 16 2 20 26 21 - 6 - 1 26 - 7 - - - - - - 0 0 - - - - 10 13 5 0 - 3 - 7 - - 26 - - 13 - 16 - - - 0 0 - - - 23 14 24 - 12 - 19 - 17 - - - 20 - 21 - 0 - - - 0 0 - - 6 22 9 20 - 25 - 17 - 8 - 14 - 18 - - - - - - - 0 0 - 14 23 21 11 20 - 24 - 18 - 19 - - - - 22 - - - - - - 0 0 17 11 11 20 - 21 - 26 - 3 - - 18 - 26 - 1 - - - - - - 0 (c) Coding rate R = 3/4. 16 17 22 24 9 3 14 - 4 2 7 - 26 - 2 - 21 - 1 0 - - - - 25 12 12 3 3 26 6 21 - 15 22 - 15 - 4 - - 16 - 0 0 - - - 25 18 26 16 22 23 9 - 0 - 4 - 4 - 8 23 11 - - - 0 0 - - 9 7 0 1 17 - - 7 3 - 3 23 - 16 - - 21 - 0 - - 0 0 - 24 5 26 7 1 - - 15 24 15 - 8 - 13 - 13 - 11 - - - - 0 0 2 2 19 14 24 1 15 19 - 21 - 2 - 24 - 3 - 2 1 - - - - 0 (d) Coding rate R = 5/6. 17 13 8 21 9 3 18 12 10 0 4 15 19 2 5 10 26 19 13 13 1 0 - - 3 12 11 14 11 25 5 18 0 9 2 26 26 10 24 7 14 20 4 2 - 0 0 - 22 16 4 3 10 21 12 5 21 14 19 5 - 8 5 18 11 5 5 15 0 - 0 0 7 7 14 14 4 16 16 24 24 10 1 7 15 6 10 26 8 18 21 14 1 - - 0 3293 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table F-2 defines the matrix prototypes of the parity-check matrices for a codeword block length n = 1296 bits, with a subblock size Z = 54 bits. Table F-2â€”Matrix prototypes for codeword block length n = 1296 bits, subblock size is Z = 54 bits (a) Coding rate R = 1/2. 40 - - - 22 - 49 23 43 - - - 1 0 - - - - - - - - - - 50 1 - - 48 35 - - 13 - 30 - - 0 0 - - - - - - - - - 39 50 - - 4 - 2 - - - - 49 - - 0 0 - - - - - - - - 33 - - 38 37 - - 4 1 - - - - - - 0 0 - - - - - - - 45 - - - 0 22 - - 20 42 - - - - - - 0 0 - - - - - - 51 - - 48 35 - - - 44 - 18 - - - - - - 0 0 - - - - - 47 11 - - - 17 - - 51 - - - 0 - - - - - 0 0 - - - - 5 - 25 - 6 - 45 - 13 40 - - - - - - - - - 0 0 - - - 33 - - 34 24 - - - 23 - - 46 - - - - - - - - 0 0 - - 1 - 27 - 1 - - - 38 - 44 - - - - - - - - - - 0 0 - - 18 - - 23 - - 8 0 35 - - - - - - - - - - - - 0 0 49 - 17 - 30 - - - 34 - - 19 1 - - - - - - - - - - 0 (b) Coding rate R = 2/3. 39 31 22 43 - 40 4 - 11 - - 50 - - - 6 1 0 - - - - - - 25 52 41 2 6 - 14 - 34 - - - 24 - 37 - - 0 0 - - - - - 43 31 29 0 21 - 28 - - 2 - - 7 - 17 - - - 0 0 - - - - 20 33 48 - 4 13 - 26 - - 22 - - 46 42 - - - - 0 0 - - - 45 7 18 51 12 25 - - - 50 - - 5 - - - 0 - - - 0 0 - - 35 40 32 16 5 - - 18 - - 43 51 - 32 - - - - - - - 0 0 - 9 24 13 22 28 - - 37 - - 25 - - 52 - 13 - - - - - - 0 0 32 22 4 21 16 - - - 27 28 - 38 - - - 8 1 - - - - - - 0 (c) Coding rate R = 3/4. 39 40 51 41 3 29 8 36 - 14 - 6 - 33 - 11 - 4 1 0 - - - - 48 21 47 9 48 35 51 - 38 - 28 - 34 - 50 - 50 - - 0 0 - - - 30 39 28 42 50 39 5 17 - 6 - 18 - 20 - 15 - 40 - - 0 0 - - 29 0 1 43 36 30 47 - 49 - 47 - 3 - 35 - 34 - 0 - - 0 0 - 1 32 11 23 10 44 12 7 - 48 - 4 - 9 - 17 - 16 - - - - 0 0 13 7 15 47 23 16 47 - 43 - 29 - 52 - 2 - 53 - 1 - - - - 0 (d) Coding rate R = 5/6. 48 29 37 52 2 16 6 14 53 31 34 5 18 42 53 31 45 - 46 52 1 0 - - 17 4 30 7 43 11 24 6 14 21 6 39 17 40 47 7 15 41 19 - - 0 0 - 7 2 51 31 46 23 16 11 53 40 10 7 46 53 33 35 - 25 35 38 0 - 0 0 19 48 41 1 10 7 36 47 5 29 52 52 31 10 26 6 3 2 - 51 1 - - 0 3294 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table F-3 defines the matrix prototypes of the parity-check matrices for a codeword block length n = 1944 bits, with a subblock size Z = 81 bits. Table F-3â€”Matrix prototypes for codeword block length n = 1944 bits, subblock size is Z = 81 bits (a) Coding rate R = 1/2. 57 - - - 50 - 11 - 50 - 79 - 1 0 - - - - - - - - - - 3 - 28 - 0 - - - 55 7 - - - 0 0 - - - - - - - - - 30 - - - 24 37 - - 56 14 - - - - 0 0 - - - - - - - - 62 53 - - 53 - - 3 35 - - - - - - 0 0 - - - - - - - 40 - - 20 66 - - 22 28 - - - - - - - 0 0 - - - - - - 0 - - - 8 - 42 - 50 - - 8 - - - - - 0 0 - - - - - 69 79 79 - - - 56 - 52 - - - 0 - - - - - 0 0 - - - - 65 - - - 38 57 - - 72 - 27 - - - - - - - - 0 0 - - - 64 - - - 14 52 - - 30 - - 32 - - - - - - - - 0 0 - - - 45 - 70 0 - - - 77 9 - - - - - - - - - - - 0 0 - 2 56 - 57 35 - - - - - 12 - - - - - - - - - - - 0 0 24 - 61 - 60 - - 27 51 - - 16 1 - - - - - - - - - - 0 (b) Coding rate R = 2/3. 61 75 4 63 56 - - - - - - 8 - 2 17 25 1 0 - - - - - - 56 74 77 20 - - - 64 24 4 67 - 7 - - - - 0 0 - - - - - 28 21 68 10 7 14 65 - - - 23 - - - 75 - - - 0 0 - - - - 48 38 43 78 76 - - - - 5 36 - 15 72 - - - - - 0 0 - - - 40 2 53 25 - 52 62 - 20 - - 44 - - - - 0 - - - 0 0 - - 69 23 64 10 22 - 21 - - - - - 68 23 29 - - - - - - 0 0 - 12 0 68 20 55 61 - 40 - - - 52 - - - 44 - - - - - - 0 0 58 8 34 64 78 - - 11 78 24 - - - - - 58 1 - - - - - - 0 (c) Coding rate R = 3/4. 48 29 28 39 9 61 - - - 63 45 80 - - - 37 32 22 1 0 - - - - 4 49 42 48 11 30 - - - 49 17 41 37 15 - 54 - - - 0 0 - - - 35 76 78 51 37 35 21 - 17 64 - - - 59 7 - - 32 - - 0 0 - - 9 65 44 9 54 56 73 34 42 - - - 35 - - - 46 39 0 - - 0 0 - 3 62 7 80 68 26 - 80 55 - 36 - 26 - 9 - 72 - - - - - 0 0 26 75 33 21 69 59 3 38 - - - 35 - 62 36 26 - - 1 - - - - 0 (d) Coding rate R = 5/6. 13 48 80 66 4 74 7 30 76 52 37 60 - 49 73 31 74 73 23 - 1 0 - - 69 63 74 56 64 77 57 65 6 16 51 - 64 - 68 9 48 62 54 27 - 0 0 - 51 15 0 80 24 25 42 54 44 71 71 9 67 35 - 58 - 29 - 53 0 - 0 0 16 29 36 41 44 56 59 37 50 24 - 65 4 65 52 - 4 - 73 52 1 - - 0 3295 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Annex G (normative) Frame exchange sequences G.1 General The allowable frame exchange sequences are defined using an extension of the EBNF format as defined in ISO/IEC 14977:1996 [B49]. The elements of this syntax that are used here are as follows: â€” [a] = a is optional. â€” {a} = a is repeated zero or more times. â€” n{a} = a is repeated n or more times. For example, 3{a} requires 3 or more "a". This notation is an extension to ISO/IEC 14977 and equivalent to n*a{a} as defined in that standard. â€” a|b|c|... = selection between mutually exclusive alternatives, a, b, c .... â€” ( ) = grouping, e.g., "a (b|c)" is equivalent to "a b | a c". â€” (* a *) = â€œaâ€ is a comment. Comments are placed before the text they relate to. â€” < > = order of frames not relevant. For example, is either "a b" or "b a." â€” A rule is terminated by a semicolon ";" â€” The meaning of whitespace is changed from ISO/IEC 14977. The name of terminals do not contain whitespace, and the concatenate-symbol (comma in ISO/IEC 14977) is replaced by white space. Whitespace appearing between the names of terminals indicates concatenation. Otherwise, whitespace is not significant and is used to highlight the nesting of grouped terms. Two types of terminals are defined: â€” Frames. The name of a frame is shown in bold and identified by its type/subtype (e.g., Beacon, Data). Frames are shown with an initial capital letter. â€” Attributes. The name of attributes are shown in italic. An attribute is introduced by the "+" character. The attribute specifies a condition that applies to the frame (or alternatively, for the attributes that start +mu, the A-MPDU) that precedes it. Where there are multiple attributes applied, they are gen- erally ordered in the same order of the fields in the frame to which they refer. The syntax a+(b|c) where b and c are attributes is equivalent to (a+b) | (a+c). In this syntax the names of nonterminals are shown in a normal font, i.e., a sequence of words joined by hyphens (e.g., cf-frame-exchange-sequence). The attributes are defined in Table G-1. Table G-1â€”Attributes applicable to frame exchange sequence definition Attribute Description a-mpdu Frame is part of an A-MPDU aggregate. See NOTE 2. a-mpdu-end Frame is the last frame in an A-MPDU aggregate. See NOTE 2. block-ack QoS Data frame has ack policy equal to Block Ack. broadcast Frame RA is the broadcast address. 3296 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table G-1â€”Attributes applicable to frame exchange sequence definition (continued) Attribute Description CF Beacon contains a CFP element. CF-Ack Data type CF-Ack subtype bit (Frame Control field B4) equal to 1 or CF-End +CF-Ack frame. CF-Poll Data type CF-Poll subtype bit (Frame Control field B5) equal to 1. csi An Action frame carrying channel state feedback (i.e., CSI, uncompressed beamforming, or compressed beamforming feedback matrices). csi-request A +HTC frame with the Feedback Request field equal to a value > 0. delayed BlockAck or BlockAckReq frame under a delayed policy. delayed-no-ack BlockAck or BlockAckReq frame has the BA Ack Policy or BAR Ack Policy field, respectively, equal to No Acknowlegement. DTIM Beacon is a DTIM. frag Frame has its More Fragments subfield equal to 1. group Frame RA has i/g bit equal to 1. HTC +HTC frame, i.e., a frame that contains the HT Control field, including the Control Wrapper frame. See NOTE. implicit-bar QoS Data frame in an A-MPDU with Normal Ack policy. individual Frame RA has i/g bit equal to 0. last Frame has its More Fragments subfield equal to 0. L-sig L-sig duration not equal to PPDU duration. action-no-ack Management frame of subtype Action No Ack. mfb A +HTC frame with the MFB field is not equal to all 1s. more-psmp A PSMP frame with the More PSMP field equal to 1. mrq A +HTC frame with the MRQ subfield equal to 1. mu-ppdu-end This attribute delineates the end of a VHT MU PPDU. See NOTE 3 and NOTE 4. mu-user-respond The preceding frame or A-MPDU is part of a VHT MU PPDU and is addressed to a user from which an immediate response is expected. See NOTE 3 and NOTE 4. mu-user-not-respond The preceding frame or A-MPDU is part of a VHT MU PPDU and is addressed to a user from which no immediate response is expected. See NOTE 3 and NOTE 4. ndp-announce A +HTC frame with the HT NDP Announcement subfield equal to 1. no-ack QoS Data frame with the Ack Policy subfield equal to No Ack. no-more-psmp A PSMP frame with the More PSMP field equal to 0. normal-ack QoS Data frame with the Ack Policy subfield equal to Normal Ack. non-QAP Frame is transmitted by a non-AP QoS STA. non-stbc PPDU TXVECTOR STBC parameter is equal to 0. null Data type Null Data subtype bit (Frame Control field B6) equal to 1. pifs Frame is transmitted following a PIFS. psmp-ack Ack Policy field of QoS Data frame is equal to PSMP Ack. 3297 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table G-1â€”Attributes applicable to frame exchange sequence definition (continued) Attribute Description QAP Frame is transmitted by a QoS AP. QoS Data type QoS subtype bit (Frame Control field B7) equal to 1. RD Frame includes an HT Control field in which the RDG/More PPDU subfield is equal to 1. self Frame RA = TA. sounding PPDU TXVECTOR SOUNDING parameter is present and equal to SOUNDING. stbc PPDU TXVECTOR STBC parameter is equal to a value >0. to-ap Frame is addressed to the AP. trq Frame is a +HTC frame with the TRQ field equal to 1. NOTE 1â€”A Control frame that contains the HT Control field is always transmitted using the Control Wrapper frame. NOTE 2â€”In the case of VHT single MPDU, a single MPDU is carried in a A-MPDU, but the attributes +a- mpdu and +a-mpdu-end are not used. NOTE 3â€”+mu-ppdu-end, +mu-user-respond and +mu-user-other are used in productions that generate VHT MU PPDUs, according to the pattern: ["an A-MPDU (which might contain a VHT single MPDU) needing a response" +mu-user-respond ] {"an A-MPDU (which might contain a VHT single MPDU) not needing a response" +mu-user-not-respond} +mu-ppdu-end. There is at least one of +mu-user-respond or +mu-user-not- respond in a VHT MU PPDU. NOTE 4â€”In the sequence A+mu-user-respond B+mu-user-not-respond â€¦ +mu-ppdu-end, although the terms A, B â€¦ (which represent one or more frames) are listed sequentially in these productions, the per-user sequence of frames represented by A, B, ... are transmitted simultaneously per-user using a VHT MU PPDU. G.2 Basic sequences An allowable frame exchange sequence is defined by the rule frame-exchange-sequence. Except where modified by the pifs attribute, frames are separated by a SIFS or RIFS. (* This rule defines all of the allowable frame exchange sequences *) frame-exchange-sequence = ( [CTS] (Management +broadcast | Data +group) ) | ( [CTS | RTS CTS | PS-Poll] {frag-frame Ack} last-frame Ack ) | (PS-Poll Ack) | ( [Beacon +DTIM ] {cf-sequence} [CF-End [+CF-Ack] ] )| hcf-sequence | mcf-sequence; (* A frag-frame is a nonfinal part of an individually addressed MSDU or MMPDU *) frag-frame = (Data | Management) +individual +frag; (* This is the last (or only) part of a an individually addressed MSDU or MMPDU *) last-frame = (Data | Management) +individual +last; (* A cf-sequence expresses all of the sequences that may be generated within a contention free period. The first frame in this sequence is sent by the AP. *) cf-sequence = 3298 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications (*Broadcast *) Beacon | Management +broadcast | Data +group [+QoS] | (* CF poll with data *) (Data+individual +CF-Poll [+CF-Ack] (Data +individual +CF-Ack [Data +null +CF-Ack] | Data +null +CF-Ack) ) | (* CF poll without data *) Data +individual +null +CF-Poll [+CF-Ack] (Data +null | (Data +individual (Data +null +CF-Ack | Ack ) ) )| (* individual management *) (Management +individual Ack) | (* All of the sequences initiated by an HC *) hcf-sequence; G.3 EDCA and HCCA sequences (* An hcf-sequence represents all of the sequences that may be generated under HCCA. The sequence may be initiated by an HC within a CFP, or it may be initiated by a STA using EDCA channel access. *) hcf-sequence = ( [CTS] 1{(Data +group [+QoS] ) | Management +broadcast) +pifs} | ( [CTS] 1{txop-sequence} ) | (* HC only, polled TXOP delivery *) ( [RTS CTS] non-cf-ack-piggybacked-qos-poll-sequence ) | (* HC only, polled TXOP delivery *) cf-ack-piggybacked-qos-poll-sequence | (* HC only, self TXOP delivery or termination *) Data +self +null +CF-Poll +QoS; (* A cf-ack-piggybacked-qos-poll-sequence is the start of a polled TXOP that also delivers a CF-Ack. There are two main variants, polls that deliver data and, therefore, need acknowledgment and polls that do not. *) cf-ack-piggybacked-qos-poll-sequence= (qos-poll-requiring-no-ack +CF-Ack ( [CTS +self] polled-txop-content | polled-txop-termination) ) | (qos-poll-requiring-ack +CF-Ack ( Ack ( 3299 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications polled-txop-content | polled-txop-termination) ) | cf-ack-piggybacked-qos-data-sequence); (* A non-cf-ack-piggybacked-qos-poll-sequence is the start of a polled TXOP that does not deliver a CF- Ack. Except for this, it is identical to the CF-Ack version. *) non-cf-ack-piggybacked-qos-poll-sequence= (qos-poll-requiring-no-ack ( [CTS +self] polled-txop-content | polled-txop-termination) ) | (qos-poll-requiring-ack ( Ack ( polled-txop-content | polled-txop-termination) ) | cf-ack-piggybacked-qos-data-sequence); (* This sequence is the delivery of a single frame that is the TXOP poll frame that does not require acknowledgment either because the frame carries no data or because the frame carries data that do not require immediate acknowledgment. *) qos-poll-requiring-no-ack = Data +null +CF-Poll +QoS | Data +individual +CF-Poll +QoS +(no-ack|block-ack); (* A qos-poll-requiring-ack is the delivery of a single frame that is a TXOP poll frame, but also carries data that require immediate acknowledgment. *) qos-poll-requiring-ack = Data +individual +CF-Poll [+CF-Ack] +QoS +normal-ack; (* Polled-txop-content is what may occur after the delivery of a polled TXOP. A QoS STA transmits the first frame in this sequence *) polled-txop-content = 1{txop-sequence} [polled-txop-termination]; (* A polled-txop-termination may be used by a QoS STA to terminate the polled TXOP. The Data frame is addressed to the HC, which regains control of the medium and may reuse any unused polled TXOP duration. *) polled-txop-termination = Data +individual +null +QoS +normal-ack Ack; (* A TXOP (either polled or EDCA) may be filled with txop-sequences, which are initiated by the TXOP holder. *) txop-sequence = ( ( (RTS CTS) | CTS +self) Data +individual +QoS +(block-ack | no-ack) ) | [RTS CTS] (txop-part-requiring-ack txop-part-providing-ack )| [RTS CTS] (Management | (Data +QAP)) +individual Ack | [RTS CTS] (BlockAckReq BlockAck) | ht-txop-sequence; (* These frames require acknowledgment *) txop-part-requiring-ack = 3300 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Data +individual [+null] | Data +individual [+null] +QoS +normal-ack | BlockAckReq +delayed | BlockAck +delayed; (* These frames provide acknowledgment to the txop-part-requiring-ack *) txop-part-providing-ack= Ack | cf-ack-piggybacked-qos-poll-sequence | (* An HC responds with a new polled TXOP on expiration of current TXOP *) cf-ack-piggybacked-qos-data-sequence | (* An HC responds with CF-Ack and its own data on expiration of TXOP *) Data +CF-Ack; (* An HC has received a frame requiring acknowledgment with a duration value indicating the end of the TXOP. The HC continues the CAP by transmitting its own data. *) cf-ack-piggybacked-qos-data-sequence = ( Data +individual +CF-Ack +QoS +(no-ack|block-ack) polled-txop-content ) | ( Data +individual +CF-Ack +QoS+normal-ack ( Ack polled-txop-content | Data +CF-Ack | cf-ack-piggybacked-qos-poll-sequence ) ) ; (* An mcf-sequence represents all of the sequences that may be generated under MCF. The sequence may be initiated by a mesh STA using EDCA channel access or MCCA channel access. *) mcf-sequence = ( [CTS] |{(Data+group+QoS ) | Management+broadcast} ) | ( [CTS] 1{txop-sequence} ) | group-mccaop-abandon; (* A group-mccaop-abandon is the delivery of a single QoS Null frame by a mesh STA that has dot11MCCAActivated true. *) group-mccaop-abandon = Data+broadcast+null+QoS G.4 HT and VHT sequences (* The ht-txop-sequence describes the additional sequences that may be initiated by an HT STA that is the holder of a TXOP *) ht-txop-sequence = L-sig-protected-sequence | ht-nav-protected-sequence | dual-cts-protected-sequence | 1{initiator-sequence}; (* an L-sig-protected-sequence is a sequence protected using the L-sig TXOP protection feature *) L-sig-protected-sequence = L-sig-protection-set 1{initiator-sequence} resync-sequence; (* an ht-nav-protected sequence consists of setting the NAV, performing one or more initiator-sequences and then resetting the NAV if time permits *) ht-nav-protected-sequence = nav-set 1{initiator-sequence} [resync-sequence] ; 3301 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications (* a dual-cts-protected-sequence is a sequence protected using the dual CTS protection feature *) dual-cts-protected-sequence = dual-cts-nav-set 1{initiator-sequence} [dual-cts-nav-reset]; (* a dual-cts-nav-set is an initial exchange that establishes NAV protection using dual CTS protection. *) dual-cts-nav-set = (* A dual CTS initiated by a non-AP HT STA that is not STBC-capable, preceded by an optional CTS frame addressed to the AP. *) ( [ CTS+to-ap+non-stbc+non-QAP ] RTS+non-stbc+non-QAP CTS+non-stbc+QAP [ CTS+stbc+pifs+QAP ] )| (* A dual CTS initiated by a non-AP STA that is STBC-capable, preceded by an optional CTS frame addressed to the AP. *) ( [ CTS+to-ap+stbc+non-QAP ] RTS+stbc+non-QAP CTS+stbc+QAP CTS+non-stbc+QAP )| (* An STBC initiator-sequence (i.e., containing STBC PPDUs) transmitted by the AP is protected by non-STBC CTS to self *) (CTS+self+non-stbc+QAP) | (* A non-STBC initiator-sequence transmitted by the AP is protected by STBC CTS to self *) (CTS+self+stbc+QAP); (* a dual-cts-nav-reset resets the NAV in the vicinity of the transmitting non-AP STA, and resets the NAV of both STBC and non-STBC-capable STA in the vicinity of the AP *) dual-cts-nav-reset = [CF-End+non-QAP] CF-End+stbc+QAP CF-End+non-stbc+QAP); (* an ma-no-ack-htc represents an Action No Ack + HTC frame *) ma-no-ack-htc = Management+action-no-ack+HTC; (* This is the sequence of frames that establish protection using the L-sig TXOP protection method *) L-sig-protection-set = (RTS+L-sig[+HTC] CTS+L-sig[+HTC]) | (Data+individual+L-sig [+HTC][+null][+QoS+normal-ack] Ack [+HTC] +L-sig) | ( 1{ Data+L-sig[+HTC]+individual+QoS+implicit-bar+a-mpdu}+a-mpdu-end BlockAck+L-sig[+HTC] )| (BlockAckReq+L-sig[+HTC] (BlockAck[+HTC]|Ack[+HTC])+L-sig) | (BlockAck+L-sig[+HTC] Ack[+HTC])+L-sig); (* These are the series of frames that establish NAV protection for an HT sequence *) nav-set = (RTS[+HTC] CTS[+HTC]) | CTS+self | (Data[+HTC]+individual[+null][+QoS+normal-ack] Ack) | Data[+HTC]+individual[+QoS+(block-ack)] | Data+group[+null][+QoS] | 3302 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ( 1{ Data[+HTC]+individual+QoS+implicit-bar+a-mpdu}+a-mpdu-end BlockAck[+HTC] )| (BlockAckReq[+HTC] (BlockAck[+HTC]|Ack[+HTC])) | (BlockAck[+HTC] Ack) 1{vht-rts-cts}; (* The vht-rts-cts term applies to RTS transmitted by a VHT STA to another VHT STA. When the RTS is transmitted using a non-HT or non-HT duplicate PPDU, the transmission of the RTS is delayed so that at least a PIFS has elapsed since the previous frame exchange sequence (see 10.22.2.7) and the RTS is transmitted with a signaling TA (see 10.3.2.6). *) vht-rts-cts = RTS+pifs [+HTC] CTS[+HTC]; resync-sequence = CF-End | (CF-End+non-QAP CF-End+QAP); (* This is an initiator sequence. The different forms arise from whether the initiator transmits a frame that requires a BlockAck frame, and whether it delivers an RDG. When an RDG is delivered, the response is distinguished according to whether it demands a BlockAck frame response from the initiator. *) initiator-sequence = (* No BlockAck frame expected, no RDG *) burst | (* block ack request delivered, BlockAck frame expected. No RD *) (burst-bar (BlockAck|Ack) [+HTC]) | (* No block ack request delivered, RDG *) (burst-rd ( burst | burst-bar initiator-sequence-ba ) )| (burst-rd-bar (BlockAck|Ack) [+HTC]) | (burst-rd-bar ( burst-ba | burst-ba-bar initiator-sequence-ba ) )| ht-ack-sequence | psmp-burst | link-adaptation-exchange ; (* This is the same as the initiator-sequence, except the initiator is constrained to generate a BlockAck frame response because a previous RD response contained a block ack request *) initiator-sequence-ba = burst-ba | (burst-ba-bar (BlockAck|Ack)[+HTC)) | (burst-ba-rd ( burst | burst-bar initiator-sequence-ba ) )| (burst-ba-rd-bar (BlockAck|Ack)[+HTC]) | (burst-ba-rd-bar ( burst-ba | burst-ba-bar initiator-sequence-ba 3303 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ) ); (* These are sequences that occur within an ht-txop-sequence that have an ack response *) ht-ack-sequence = (BlockAck+delayed[+HTC] [+mu-user-respond other-users]Ack[+HTC]) | (BlockAckReq+delayed[+HTC][+mu-user-respond other-users] Ack[+HTC]) | (Data[+HTC]+individual[+null][+QoS+normal-ack][+mu-user-respond other- users] Ack[+HTC]); (* The per-user parts of a VHT MU PPDU that do not require a response *) other-users = {ppdu-not-requiring-response-per-user +mu-user-not-respond} +mu-ppdu-end; (* A burst is a sequence of one or more packets, none of them requiring a response *) burst = 1{ppdu-not-requiring-response}; (* A burst containing a block ack request *) burst-bar = {ppdu-not-requiring-response} ppdu-bar; (* A burst containing a BlockAck frame *) burst-ba = ppdu-ba {ppdu-not-requiring-response}; (* A burst containing a BlockAck frame and block ack request, either in the same packet, or in separate packets. *) burst-ba-bar = (ppdu-ba {ppdu-not-requiring-response} ppdu-bar) | ppdu-ba-bar; (* A burst delivering an RDG *) burst-rd = {ppdu-not-requiring-response} ppdu-rd; (* A burst containing a block ack request and delivering an RDG *) burst-rd-bar = burst ppdu-rd-bar; (* A burst containing a BlockAck frame and delivering an RDG *) burst-ba-rd = (ppdu-ba {ppdu-not-requiring-response} ppdu-rd) | ppdu-ba-rd; (* A burst containing a block ack request and BlockAck frame and delivering an RDG *) burst-ba-rd-bar = (ppdu-ba {ppdu-not-requiring-response} ppdu-rd-bar) | ppdu-ba-rd-bar; (* The per-user part of a PPDU not requiring a response is either a single frame not requiring response, or an A-MPDU of such frames.*) ppdu-not-requiring-response-per-user = frame-not-requiring-response-non-ampdu | (* Includes VHT single MPDU *) 1{frame-not-requiring-response-ampdu+a-mpdu}+a-mpdu-end; (* A PPDU not requiring a response is either a single frame not requiring response, or an A-MPDU of such frames.*) ppdu-not-requiring-response = ppdu-not-requiring-response-per-user [+mu-user-not-respond other-users]; (* A frame-not-requiring-response-non-ampdu is a frame that does not require a response and that may be sent outside A-MPDU. It includes frames that do not require a response and that are not allowed within an A-MPDU. *) 3304 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications frame-not-requiring-response-non-ampdu = Data[+HTC]+QoS+no-ack | frame-not-requiring-response-ampdu; (* A frame-not-requiring-response-ampdu is a frame that does not require a response and can be sent within an A-MPDU. It is one of the delayed BlockAck frames sent with the BAR/BA Ack Policy subfield set to No Acknowledgment, or Data that does not require an immediate ack, or an Action No Ack frame. A frame-not- requiring-response may be included with any of the following sequences in any position, except the initial position when this contains a BlockAck frame or Multi-TID BlockAck frame: ppdu-bar, ppdu-ba-bar, ppdu- ba, ppdu-rd, ppdu-rd-bar, ppdu-ba-rd-bar, psmp-ppdu *) frame-not-requiring-response-ampdu = BlockAck[+HTC]+delayed-no-ack | BlockAckReq[+HTC]+delayed-no-ack | Data[+HTC]+QoS+block-ack | ma-no-ack-htc; (* A PPDU containing a block ack request is either a non-A-MPDU BlockAckReq frame, or an A-MPDU containing Data carrying implicit block ack request*). ppdu-bar= ( (BlockAckReq[+HTC] | (1{Data[+HTC]+QoS+implicit-bar+a-mpdu} + a-mpdu-end); ) [+mu-user-respond other-users]; (* A PPDU containing both BlockAck frame and block ack request is an A-MPDU that contains a BlockAck frame, plus either a BlockAckReq frame, or one or more Data frames carrying implicit block ack request. *) ppdu-ba-bar= ( BlockAck[+HTC]+a-mpdu ( BlockAckReq[+HTC]+a-mpdu | 1{Data[+HTC]+QoS+implicit-bar+a-mpdu} ) + a-mpdu-end ) [+mu-user-respond other-users]; (*A PPDU containing BlockAck frame is either a non-A-MPDU BlockAck frame, or an A-MPDU containing a BlockAck frame, and also containing data that does not carry implicit block ack request. *) ppdu-ba= ( BlockAck[+HTC] | ( BlockAck[+HTC]+a-mpdu 1{Data[+HTC]+QoS+(no-ack|block-ack)+a-mpdu} ) + a-mpdu-end; ) [+mu-user-respond other-users]; (* A PPDU delivering an RDG, but not delivering a block ack request is either a Data frame, not requiring immediate acknowledgment, or a BlockAck frame or BlockAckReq frame, not requiring immediate acknowledgment *). ppdu-rd= ( Data+HTC[+null]+QoS+(no-ack|block-ack)+RD | (BlockAck|BlockAckReq)+HTC+delayed-no-ack+RD | ( 1{Data+HTC+QoS+RD+a-mpdu} ) + a-mpdu-end; ) [+mu-user-respond other-users]; (* A PPDU containing a block ack request and delivering an RDG is either an non-A-MPDU BlockAckReq frame, or an A-MPDU containing at least one Data frame with RD and implicit-bar. *) ppdu-rd-bar= ( BlockAckReq+HTC+RD | 3305 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ( 1{Data+HTC+QoS+implicit-bar+RD+a-mpdu} ) + a-mpdu-end; ) [+mu-user-respond other-users]; (* A PPDU containing a BlockAck frame and granting RD is either an unaggregated BlockAck frame or an A-MPDU that contains a BlockAck frame and at least one Data frame containing RD, but not implicit block ack request. *) ppdu-ba-rd= ( BlockAck+HTC+RD | ( BlockAck+a-mpdu ( 1{Data+HTC+QoS+(no-ack|block-ack)+RD+a-mpdu} ) ) + a-mpdu-end; ) [+mu-user-respond other-users]; (* A PPDU containing a BlockAck frame, block ack request and granting RD is an A-MPDU that contains a BlockAck frame and either an explicit BlockAckReq frame (and no Data frames) or Data frames carrying the implicit block ack request. The RD attribute is present in all frames carrying an HT Control field, and at least one of these frames is present. This constraint is not expressed in the syntax below. *) ppdu-ba-rd-bar= ( ( BlockAck[+HTC+RD]+a-mpdu BlockAckReq[+HTC+RD]+a-mpdu ) + a-mpdu-end | ( BlockAck[+HTC+RD]+a-mpdu 1{ Data[+HTC+RD]+QoS+implicit-bar+a-mpdu} ) + a-mpdu-end; ) [+mu-user-respond other-users]; (* A PSMP burst is a sequence of PSMP sequence ending with a last-psmp-sequence *) psmp-burst = {non-last-psmp-sequence} last-psmp-sequence; non-last-psmp-sequence = PSMP+more-psmp+QAP downlink-phase uplink-phase; last-psmp-sequence = PSMP+no-more-psmp+QAP downlink-phase uplink-phase; (* The downlink phase is a sequence of allocations to STA as defined in the PSMP frame during which they may expect to receive. *) downlink-phase = {psmp-allocated-time}; (* The uplink phase is a sequence of allocations to STA as defined in the PSMP frame during which they are allowed to transmit *) uplink-phase = {psmp-allocated-time}; (* During a time allocation, one or more packets may be transmitted of contents defined by psmp-ppdu *) psmp-allocated-time = 1{psmp-ppdu}; (* The packets that may be transmitted during PSMP are isolated Multi-TID BlockAck or Multi-TID BlockAckReq frames (under an HT-immediate block ack policy), BlockAck or BlockAckReq frames (under an HT-delayed or immediate block ack policy), isolated Data frames, or an A-MPDU containing an optional Multi-TID BlockAck frame and one or more Data frames sent under the PSMP Ack Ack Policy, or an A-MPDU containing both Multi-TID BlockAck and Multi-TID BlockAckReq frames, but no data. Any number of Action No Ack frames may be present in either A-MPDU. *) psmp-ppdu = Multi-TID BlockAck | (*HT-immediate*) 3306 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Multi-TID BlockAckReq | (*HT-immediate*) BlockAck | (*HT-delayed or immediate*) BlockAckReq | (*HT-delayed or immediate*) Data[+HTC]+individual+QoS+psmp-ack | ( [Multi-TID BlockAck+a-mpdu] {Management+action-no-ack[+HTC] } 1{Data[+HTC]+individual+QoS+psmp-ack+a-mpdu}; ) + a-mpdu-end | ( Multi-TID BlockAck+a-mpdu { Management+action-no-ack[+HTC] } Multi-TID BlockAckReq+a-mpdu ) + a-mpdu-end; (* A link adaptation exchange is a frame exchange sequence in which over-the-WM signaling is used to control or return the results of link measurements so that the initiator device can choose effective values for its TXVECTOR parameters. *) link-adaptation-exchange = mcs-adaptation | implict-txbf | explicit-txbf | vht-bf; (* An mcs-adaptation exchange includes an MCS measurement request and subsequent MFB. The MRQ and MFB may be present in any +HTC frame. The exchange can occur either as a fast exchange, in which the feedback is supplied in a response frame, an exchange in which the response is supplied along with some other Data frame within the same TXOP, or an exchange in which the response is supplied in a subsequent TXOP won by the MCS responder. Only the fast response is shown in the syntax that follows. The sequences shown below are representative examples only and are not exhaustive.*) mcs-adaptation = (* RTS/CTS *) (RTS+HTC+mrq CTS+HTC+mfb) | (* non-aggregated Data/Ack *) (Data+HTC+QoS+mrq+normal-ack Ack+HTC+mfb) | (* non-aggregated BlockAck *) (BlockAckReq+HTC+mrq (BlockAck+HTC+mfb | Ack+HTC+mfb)) | (* aggregated data with implicit block ack request and MRQ *) ( ( 1{Data[+HTC]+mrq [+rdg] +QoS+implicit-bar+a-mpdu} ) + a-mpdu-end ( (* Unaggregated BlockAck frame response *) BlockAck+HTC +mfb | (* Aggregated BlockAck frame response *) ( BlockAck[+HTC+mfb] +a-mpdu 1{Data[+HTC+mfb]+QoS+(no-ack|block-ack)+a-mpdu} ) + a-mpdu-end 3307 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ) ); (* An implicit-txbf (implicit transmit beamforming) starts with the transmission of a request to sound the channel. The initiator measures the channel based on the sounding packet and updates its beamforming feedback matrices based on its observations of the sounding packet. No channel measurements are sent over the air.*) implict-txbf = (RTS+HTC+trq CTS+sounding) | (Data+HTC+trq+QoS+normal-ack (Ack+sounding | Ack+HTC+ndp-announce NDP) )| (BlockAckReq+HTC+trq (BlockAck+sounding | BlockAck+HTC+ndp-announce NDP ) )| (BlockAck+HTC+trq+delayed (Ack+sounding | Ack+HTC+ndp-announce NDP ) ) (* The trq/sounding protocol also operates within aggregates. In this case the TRQ is carried in all +HTC frames (of which there has to be at least one) within the TRQ initiatorâ€™s transmission. The response PPDU either is a sounding PPDU, or carries at least one +HTC frame with an ndp-announce, in which case the following PPDU is an NDP sounding PPDU. The following syntax is an simplified representation of this sequence. *) ([BlockAck+HTC+trq+a-mpdu] {Data+HTC+trq+QoS+a-mpdu}+a-mpdu- end) ( ([BlockAck+HTC+a-mpdu] {Data+HTC+QoS+a-mpdu}+a-mpdu-end+sounding) )| ( ([BlockAck+HTC+ndp-announce+a-mpdu] {Data+HTC+ndp-announce+QoS+a-mpdu}+a-mpdu-end) ) NDP | (BlockAck+HTC+sounding) | (BlockAck+HTC+ndp-announce NDP); (* During operation of explicit transmit beamforming (explicit-txbf), there are three encodings of feedback information. These are not distinguished here and are all identified by the csi attribute. The feedback position may be immediate, aggregate, or delayed. Immediate feedback follows a SIFS after the sounding PPDU (identified by the sounding attribute) or the NDP. Aggregate feedback occurs during an aggregate within the same TXOP and may accompany Data frames in the same PPDU. Delayed feedback occurs during a subsequent TXOP during which the CSI responder is TXOP initiator. Only immediate feedback is described in the syntax below. The frame indicating any csi-request is carried in a sounding PPDU or followed by an NDP. The CSI response is carried in an Action No Ack frame, which may be aggregated with a response that is a BlockAck or Ack frame. There are also two sets of sequences â€œstaggeredâ€ and â€œNDPâ€ that use either staggered sounding, or NDP sounding respectively.*) explicit-txbf = explicit-txbf-staggered | explicit-txbf-NDP; 3308 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications (* Staggered sounding. In this case, the sounding request is present in a frame that also generates an immediate response. The response is aggregated with the feedback in an A-MPDU. *) explicit-txbf-staggered = ( Data+HTC+csi-request+QoS+normal-ack+sounding (Ack+a-mpdu Management+action-no-ack +csi+a-mpdu-end) )| ( BlockAckReq+HTC+csi-request+sounding (BlockAck+a-mpdu Management+action-no-ack +csi+a-mpdu-end) )| ( BlockAckReq+HTC+csi-request+delayed+sounding (Ack+a-mpdu Management+action-no-ack+csi+a-mpdu-end) ); (* NDP sounding. In this case, the HT NDP announcement is present in a frame that also generates an immediate response. The beamformer transmits an NDP once the immediate response is received, and the beamformee transmits immediate feedback once it receives the NDP. *) explicit-txbf-NDP = ( RTS+HTC+csi-request+ndp-announce CTS NDP Management+action-no-ack +csi )| ( Data+HTC+csi-request+QoS+normal-ack+ndp-announce Ack NDP Management+action-no-ack +csi )| ( BlockAckReq+HTC+csi-request+ndp-announce BlockAck NDP Management+action-no-ack +csi )| ( BlockAckReq+HTC+csi-request+delayed+ndp-announce Ack NDP Management+action-no-ack +csi ); (* The VHT beamforming sequence starts with a VHT NDP Announcement frame, followed by a VHT NDP. One of the STAs in the sequence responds immediately with explicit feedback. The VHT AP might poll the other STAs to obtain their feedback before generating an MU transmission. The names of the frames include spaces, so they are delimited using parentheses. *) vht-bf = (VHT NDP Announcement) (VHT NDP) vht-feedback 3309 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications {(Beamforming Report Poll) vht-feedback}; (* VHT feedback is provided using VHT Compressed Beamforming frames. Multiple frames may be needed to provide feedback. *) vht-feedback = (VHT Compressed Beamforming frame) | (* VHT single MPDU or non-VHT PPDU *) 1{(VHT Compressed Beamforming frame) +a-mpdu} +a-mpdu-end; 3310 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Annex H (normative) Usage of Ethertype 89-0d The Ethertype 89-0d frame body is specified in Figure H-1, omitting any possible security header and trailer. LLC SNAP Payload Type Payload Octets: 3 5 1 variable Figure H-1â€”Ethertype 89-0d frame body LLC is defined in ISO/IEC 8802-2:1998. SNAP is defined in IEEE Std 802-2014. The formatting of the SNAP header is according to IETF RFC 1042. The Ethertype is set to 89-0d. The Payload Type field is set to one of the values in Table H-1. Table H-1â€”Payload Type field values Protocol name Payload type Subclause Remote Request/Response 1 13.10.3 TDLS 2 11.23.2 FST 3 11.33.5 RLQP 4 11.25.3.4 Reserved 5â€“255 The Payload depends on the value inside the Payload Type field and is defined in the subclauses listed in Table H-1. 3311 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Annex I (informative) Examples of encoding a frame for OFDM PHYs and DMG PHYs I.1 Example 1 - BCC encoding I.1.1 Introduction The purpose of this annex is to show an example of encoding a frame for the OFDM PHY, as described in Clause 17. This example covers all of the encoding details defined by this standard. The encoding illustration goes through the following stages: a) Generating the short training sequence section of the preamble; b) Generating the long preamble sequence section of the preamble; c) Generating the SIGNAL field bits; d) Coding and interleaving the SIGNAL field bits; e) Mapping the SIGNAL field into frequency domain; f) Pilot insertion; g) Transforming into time domain; h) Delineating the data octet stream into a bit stream; i) Prepending the SERVICE field and adding the pad bits, thus forming the DATA; j) Scrambling and zeroing the tail bits; k) Encoding the DATA with a convolutional encoder and puncturing; l) Mapping into complex 16-QAM symbols; m) Pilot insertion; n) Transforming from frequency to time and adding a circular prefix; o) Concatenating the OFDM symbols into a single, time-domain signal. In the description of time domain waveforms, a complex baseband signal at 20 Msample/s shall be used. This example uses the 36 Mb/s data rate and a message of 100 octets. These parameters are chosen in order to illustrate as many nontrivial aspects of the processing as possible: â€” Use of several bits per symbol (4 in this case); â€” Puncturing of the convolutional code; â€” Interleaving, which uses the LSBâ€“MSB swapping stage; â€” Scrambling of the pilot subcarriers. In each Annex I table that has â€œBinary valueâ€ columns, the bit positions of the binary values are specified in the header of the table. 3312 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications I.1.2 The message for the BCC example The message being encoded consists of the first 72 characters (shown in bold and including line breaks) of the well-known â€œOde to Joyâ€ by F. Schiller: Joy, bright spark of divinity, Daughter of Elysium, Fire-insired we tread Thy sanctuary. Thy magic power re-unites All that custom has divided, All men become brothers Under the sway of thy gentle wings. The message is converted to ASCII; then it is prepended with an appropriate MAC header and an FCS is added. The resulting 100 octet PSDU is shown in Table I-1. Table I-1â€”The message for the BCC example Octet ## Val Val Val Val Val 1...5 0x04 0x02 0x00 0x2E 0x00 6...10 0x60 0x08 0xCD 0x37 0xA6 11...15 0x00 0x20 0xD6 0x01 0x3C 16...20 0xF1 0x00 0x60 0x08 0xAD 21...25 0x3B 0xAF 0x00 0x00 0x4A 26...30 0x6F 0x79 0x2C 0x20 0x62 31...35 0x72 0x69 0x67 0x68 0x74 36...40 0x20 0x73 0x70 0x61 0x72 41...45 0x6B 0x20 0x6F 0x66 0x20 46...50 0x64 0x69 0x76 0x69 0x6E 51...55 0x69 0x74 0x79 0x2C 0x0A 56...60 0x44 0x61 0x75 0x67 0x68 61...65 0x74 0x65 0x72 0x20 0x6F 66...70 0x66 0x20 0x45 0x6C 0x79 71...75 0x73 0x69 0x75 0x6D 0x2C 76...80 0x0A 0x46 0x69 0x72 0x65 81...85 0x2D 0x69 0x6E 0x73 0x69 86...90 0x72 0x65 0x64 0x20 0x77 91...95 0x65 0x20 0x74 0x72 0x65 96...100 0x61 0x67 0x33 0x21 0xB6 3313 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications I.1.3 Generation of the preamble I.1.3.1 Generation of the short sequences The short sequences section of the preamble is described by its frequency domain representation, given in Table I-2. Table I-2â€”Frequency domain representation of the short sequences ## Re Im ## Re Im ## Re Im ## Re Im â€“32 0.0 0.0 â€“16 1.472 1.472 0 0.0 0.0 16 1.472 1.472 â€“31 0.0 0.0 â€“15 0.0 0.0 1 0.0 0.0 17 0.0 0.0 â€“30 0.0 0.0 â€“14 0.0 0.0 2 0.0 0.0 18 0.0 0.0 â€“29 0.0 0.0 â€“13 0.0 0.0 3 0.0 0.0 19 0.0 0.0 â€“28 0.0 0.0 â€“12 â€“1.472 â€“1.472 4 â€“1.472 â€“1.472 20 1.472 1.472 â€“27 0.0 0.0 â€“11 0.0 0.0 5 0.0 0.0 21 0.0 0.0 â€“26 0.0 0.0 â€“10 0.0 0.0 6 0.0 0.0 22 0.0 0.0 â€“25 0.0 0.0 â€“9 0.0 0.0 7 0.0 0.0 23 0.0 0.0 â€“24 1.472 1.472 â€“8 â€“1.472 â€“1.472 8 â€“1.472 â€“1.472 24 1.472 1.472 â€“23 0.0 0.0 â€“7 0.0 0.0 9 0.0 0.0 25 0.0 0.0 â€“22 0.0 0.0 â€“6 0.0 0.0 10 0.0 0.0 26 0.0 0.0 â€“21 0.0 0.0 â€“5 0.0 0.0 11 0.0 0.0 27 0.0 0.0 â€“20 â€“1.472 â€“1.472 â€“4 1.472 1.472 12 1.472 1.472 28 0.0 0.0 â€“19 0.0 0.0 â€“3 0.0 0.0 13 0.0 0.0 29 0.0 0.0 â€“18 0.0 0.0 â€“2 0.0 0.0 14 0.0 0.0 30 0.0 0.0 â€“17 0.0 0.0 â€“1 0.0 0.0 15 0.0 0.0 31 0.0 0.0 One period of the IFFT on the contents of Table I-2 is given in Table I-3. Table I-3â€”One period of IFFT of the short sequences ## Re Im ## Re Im ## Re Im ## Re Im 0 0.046 0.046 1 â€“0.132 0.002 2 â€“0.013 â€“0.079 3 0.143 â€“0.013 4 0.092 0.000 5 0.143 â€“0.013 6 â€“0.013 â€“0.079 7 â€“0.132 0.002 8 0.046 0.046 9 0.002 â€“0.132 10 â€“0.079 â€“0.013 11 â€“0.013 0.143 12 0.000 0.092 13 â€“0.013 0.143 14 â€“0.079 â€“0.013 15 0.002 â€“0.132 16 0.046 0.046 17 â€“0.132 0.002 18 â€“0.013 â€“0.079 19 0.143 â€“0.013 20 0.092 0.000 21 0.143 â€“0.013 22 â€“0.013 â€“0.079 23 â€“0.132 0.002 3314 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-3â€”One period of IFFT of the short sequences (continued) ## Re Im ## Re Im ## Re Im ## Re Im 24 0.046 0.046 25 0.002 â€“0.132 26 â€“0.079 â€“0.013 27 â€“0.013 0.143 28 0.000 0.092 29 â€“0.013 0.143 30 â€“0.079 â€“0.013 31 0.002 â€“0.132 32 0.046 0.046 33 â€“0.132 0.002 34 â€“0.013 â€“0.079 35 0.143 â€“0.013 36 0.092 0.000 37 0.143 â€“0.013 38 â€“0.013 â€“0.079 39 â€“0.132 0.002 40 0.046 0.046 41 0.002 â€“0.132 42 â€“0.079 â€“0.013 43 â€“0.013 0.143 44 0.000 0.092 45 â€“0.013 0.143 46 â€“0.079 â€“0.013 47 0.002 â€“0.132 48 0.046 0.046 49 â€“0.132 0.002 50 â€“0.013 â€“0.079 51 0.143 â€“0.013 52 0.092 0.000 53 0.143 â€“0.013 54 â€“0.013 â€“0.079 55 â€“0.132 0.002 56 0.046 0.046 57 0.002 â€“0.132 58 â€“0.079 â€“0.013 59 â€“0.013 0.143 60 0.000 0.092 61 â€“0.013 0.143 62 â€“0.079 â€“0.013 63 0.002 â€“0.132 The single period of the short training sequence is extended periodically for 161 samples (about 8 s), and then multiplied by the window function: 0.5 k=0 W k = 1 1 k 159 0.5 k = 160 The last sample serves as an overlap with the following OFDM symbol. The 161 samples vector is shown in Table I-4. The time-windowing feature illustrated here is not part of the normative specifications. Table I-4â€”Time domain representation of the short sequence ## Re Im ## Re Im ## Re Im ## Re Im 0 0.023 0.023 1 â€“0.132 0.002 2 â€“0.013 â€“0.079 3 0.143 â€“0.013 4 0.092 0.000 5 0.143 â€“0.013 6 â€“0.013 â€“0.079 7 â€“0.132 0.002 8 0.046 0.046 9 0.002 â€“0.132 10 â€“0.079 â€“0.013 11 â€“0.013 0.143 12 0.000 0.092 13 â€“0.013 0.143 14 â€“0.079 â€“0.013 15 0.002 â€“0.132 16 0.046 0.046 17 â€“0.132 0.002 18 â€“0.013 â€“0.079 19 0.143 â€“0.013 20 0.092 0.000 21 0.143 â€“0.013 22 â€“0.013 â€“0.079 23 â€“0.132 0.002 24 0.046 0.046 25 0.002 â€“0.132 26 â€“0.079 â€“0.013 27 â€“0.013 0.143 28 0.000 0.092 29 â€“0.013 0.143 30 â€“0.079 â€“0.013 31 0.002 â€“0.132 32 0.046 0.046 33 â€“0.132 0.002 34 â€“0.013 â€“0.079 35 0.143 â€“0.013 36 0.092 0.000 37 0.143 â€“0.013 38 â€“0.013 â€“0.079 39 â€“0.132 0.002 40 0.046 0.046 41 0.002 â€“0.132 42 â€“0.079 â€“0.013 43 â€“0.013 0.143 3315 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-4â€”Time domain representation of the short sequence (continued) ## Re Im ## Re Im ## Re Im ## Re Im 44 0.000 0.092 45 â€“0.013 0.143 46 â€“0.079 â€“0.013 47 0.002 â€“0.132 48 0.046 0.046 49 â€“0.132 0.002 50 â€“0.013 â€“0.079 51 0.143 â€“0.013 52 0.092 0.000 53 0.143 â€“0.013 54 â€“0.013 â€“0.079 55 â€“0.132 0.002 56 0.046 0.046 57 0.002 â€“0.132 58 â€“0.079 â€“0.013 59 â€“0.013 0.143 60 0.000 0.092 61 â€“0.013 0.143 62 â€“0.079 â€“0.013 63 0.002 â€“0.132 64 0.046 0.046 65 â€“0.132 0.002 66 â€“0.013 â€“0.079 67 0.143 â€“0.013 68 0.092 0.000 69 0.143 â€“0.013 70 â€“0.013 â€“0.079 71 â€“0.132 0.002 72 0.046 0.046 73 0.002 â€“0.132 74 â€“0.079 â€“0.013 75 â€“0.013 0.143 76 0.000 0.092 77 â€“0.013 0.143 78 â€“0.079 â€“0.013 79 0.002 â€“0.132 80 0.046 0.046 81 â€“0.132 0.002 82 â€“0.013 â€“0.079 83 0.143 â€“0.013 84 0.092 0.000 85 0.143 â€“0.013 86 â€“0.013 â€“0.079 87 â€“0.132 0.002 88 0.046 0.046 89 0.002 â€“0.132 90 â€“0.079 â€“0.013 91 â€“0.013 0.143 92 0.000 0.092 93 â€“0.013 0.143 94 â€“0.079 â€“0.013 95 0.002 â€“0.132 96 0.046 0.046 97 â€“0.132 0.002 98 â€“0.013 â€“0.079 99 0.143 â€“0.013 100 0.092 0.000 101 0.143 â€“0.013 102 â€“0.013 â€“0.079 103 â€“0.132 0.002 104 0.046 0.046 105 0.002 â€“0.132 106 â€“0.079 â€“0.013 107 â€“0.013 0.143 108 0.000 0.092 109 â€“0.013 0.143 110 â€“0.079 â€“0.013 111 0.002 â€“0.132 112 0.046 0.046 113 â€“0.132 0.002 114 â€“0.013 â€“0.079 115 0.143 â€“0.013 116 0.092 0.000 117 0.143 â€“0.013 118 â€“0.013 â€“0.079 119 â€“0.132 0.002 120 0.046 0.046 121 0.002 â€“0.132 122 â€“0.079 â€“0.013 123 â€“0.013 0.143 124 0.000 0.092 125 â€“0.013 0.143 126 â€“0.079 â€“0.013 127 0.002 â€“0.132 128 0.046 0.046 129 â€“0.132 0.002 130 â€“0.013 â€“0.079 131 0.143 â€“0.013 132 0.092 0.000 133 0.143 â€“0.013 134 â€“0.013 â€“0.079 135 â€“0.132 0.002 136 0.046 0.046 137 0.002 â€“0.132 138 â€“0.079 â€“0.013 139 â€“0.013 0.143 140 0.000 0.092 141 â€“0.013 0.143 142 â€“0.079 â€“0.013 143 0.002 â€“0.132 144 0.046 0.046 145 â€“0.132 0.002 146 â€“0.013 â€“0.079 147 0.143 â€“0.013 148 0.092 0.000 149 0.143 â€“0.013 150 â€“0.013 â€“0.079 151 â€“0.132 0.002 152 0.046 0.046 153 0.002 â€“0.132 154 â€“0.079 â€“0.013 155 â€“0.013 0.143 156 0.000 0.092 157 â€“0.013 0.143 158 â€“0.079 â€“0.013 159 0.002 â€“0.132 160 0.023 0.023 3316 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications I.1.3.2 Generation of the long sequences The frequency domain representation of the long training sequence part of the preamble is given in Table I-5. Table I-5â€”Frequency domain representation of the long sequences ## Re Im ## Re Im ## Re Im ## Re Im â€“32 0.000 0.000 â€“16 1.000 0.000 0 0.000 0.000 16 1.000 0.000 â€“31 0.000 0.000 â€“15 1.000 0.000 1 1.000 0.000 17 â€“1.000 0.000 â€“30 0.000 0.000 â€“14 1.000 0.000 2 â€“1.000 0.000 18 â€“1.000 0.000 â€“29 0.000 0.000 â€“13 1.000 0.000 3 â€“1.000 0.000 19 1.000 0.000 â€“28 0.000 0.000 â€“12 1.000 0.000 4 1.000 0.000 20 â€“1.000 0.000 â€“27 0.000 0.000 â€“11 â€“1.000 0.000 5 1.000 0.000 21 1.000 0.000 â€“26 1.000 0.000 â€“10 â€“1.000 0.000 6 â€“1.000 0.000 22 â€“1.000 0.000 â€“25 1.000 0.000 â€“9 1.000 0.000 7 1.000 0.000 23 1.000 0.000 â€“24 â€“1.000 0.000 â€“8 1.000 0.000 8 â€“1.000 0.000 24 1.000 0.000 â€“23 â€“1.000 0.000 â€“7 â€“1.000 0.000 9 1.000 0.000 25 1.000 0.000 â€“22 1.000 0.000 â€“6 1.000 0.000 10 â€“1.000 0.000 26 1.000 0.000 â€“21 1.000 0.000 â€“5 â€“1.000 0.000 11 â€“1.000 0.000 27 0.000 0.000 â€“20 â€“1.000 0.000 â€“4 1.000 0.000 12 â€“1.000 0.000 28 0.000 0.000 â€“19 1.000 0.000 â€“3 1.000 0.000 13 â€“1.000 0.000 29 0.000 0.000 â€“18 â€“1.000 0.000 â€“2 1.000 0.000 14 â€“1.000 0.000 30 0.000 0.000 â€“17 1.000 0.000 â€“1 1.000 0.000 15 1.000 0.000 31 0.000 0.000 The time domain representation is derived by performing IFFT on the contents of Table I-5, cyclically extending the result to get the cyclic prefix, and then multiplying with the window function given in I.1.3.1. The resulting 161 points vector is shown in Table I-6. The samples are appended to the short sequence section by overlapping and adding element 160 of Table I-4 to element 0 of Table I-6. Table I-6â€”Time domain representation of the long sequence ## Re Im ## Re Im ## Re Im ## Re Im 0 â€“0.078 0.000 1 0.012 â€“0.098 2 0.092 â€“0.106 3 â€“0.092 â€“0.115 4 â€“0.003 â€“0.054 5 0.075 0.074 6 â€“0.127 0.021 7 â€“0.122 0.017 8 â€“0.035 0.151 9 â€“0.056 0.022 10 â€“0.060 â€“0.081 11 0.070 â€“0.014 12 0.082 â€“0.092 13 â€“0.131 â€“0.065 14 â€“0.057 â€“0.039 15 0.037 â€“0.098 16 0.062 0.062 17 0.119 0.004 18 â€“0.022 â€“0.161 19 0.059 0.015 3317 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-6â€”Time domain representation of the long sequence (continued) ## Re Im ## Re Im ## Re Im ## Re Im 20 0.024 0.059 21 â€“0.137 0.047 22 0.001 0.115 23 0.053 â€“0.004 24 0.098 0.026 25 â€“0.038 0.106 26 â€“0.115 0.055 27 0.060 0.088 28 0.021 â€“0.028 29 0.097 â€“0.083 30 0.040 0.111 31 â€“0.005 0.120 32 0.156 0.000 33 â€“0.005 â€“0.120 34 0.040 â€“0.111 35 0.097 0.083 36 0.021 0.028 37 0.060 â€“0.088 38 â€“0.115 â€“0.055 39 â€“0.038 â€“0.106 40 0.098 â€“0.026 41 0.053 0.004 42 0.001 â€“0.115 43 â€“0.137 â€“0.047 44 0.024 â€“0.059 45 0.059 â€“0.015 46 â€“0.022 0.161 47 0.119 â€“0.004 48 0.062 â€“0.062 49 0.037 0.098 50 â€“0.057 0.039 51 â€“0.131 0.065 52 0.082 0.092 53 0.070 0.014 54 â€“0.060 0.081 55 â€“0.056 â€“0.022 56 â€“0.035 â€“0.151 57 â€“0.122 â€“0.017 58 â€“0.127 â€“0.021 59 0.075 â€“0.074 60 â€“0.003 0.054 61 â€“0.092 0.115 62 0.092 0.106 63 0.012 0.098 64 â€“0.156 0.000 65 0.012 â€“0.098 66 0.092 â€“0.106 67 â€“0.092 â€“0.115 68 â€“0.003 â€“0.054 69 0.075 0.074 70 â€“0.127 0.021 71 â€“0.122 0.017 72 â€“0.035 0.151 73 â€“0.056 0.022 74 â€“0.060 â€“0.081 75 0.070 â€“0.014 76 0.082 â€“0.092 77 â€“0.131 â€“0.065 78 â€“0.057 â€“0.039 79 0.037 â€“0.098 80 0.062 0.062 81 0.119 0.004 82 â€“0.022 â€“0.161 83 0.059 0.015 84 0.024 0.059 85 â€“0.137 0.047 86 0.001 0.115 87 0.053 â€“0.004 88 0.098 0.026 89 â€“0.038 0.106 90 â€“0.115 0.055 91 0.060 0.088 92 0.021 â€“0.028 93 0.097 â€“0.083 94 0.040 0.111 95 â€“0.005 0.120 96 0.156 0.000 97 â€“0.005 â€“0.120 98 0.040 â€“0.111 99 0.097 0.083 100 0.021 0.028 101 0.060 â€“0.088 102 â€“0.115 â€“0.055 103 â€“0.038 â€“0.106 104 0.098 â€“0.026 105 0.053 0.004 106 0.001 â€“0.115 107 â€“0.137 â€“0.047 108 0.024 â€“0.059 109 0.059 â€“0.015 110 â€“0.022 0.161 111 0.119 â€“0.004 112 0.062 â€“0.062 113 0.037 0.098 114 â€“0.057 0.039 115 â€“0.131 0.065 116 0.082 0.092 117 0.070 0.014 118 â€“0.060 0.081 119 â€“0.056 â€“0.022 120 â€“0.035 â€“0.151 121 â€“0.122 â€“0.017 122 â€“0.127 â€“0.021 123 0.075 â€“0.074 124 â€“0.003 0.054 125 â€“0.092 0.115 126 0.092 0.106 127 0.012 0.098 128 â€“0.156 0.000 129 0.012 â€“0.098 130 0.092 â€“0.106 131 â€“0.092 â€“0.115 132 â€“0.003 â€“0.054 133 0.075 0.074 134 â€“0.127 0.021 135 â€“0.122 0.017 136 â€“0.035 0.151 137 â€“0.056 0.022 138 â€“0.060 â€“0.081 139 0.070 â€“0.014 140 0.082 â€“0.092 141 â€“0.131 â€“0.065 142 â€“0.057 â€“0.039 143 0.037 â€“0.098 144 0.062 0.062 145 0.119 0.004 146 â€“0.022 â€“0.161 147 0.059 0.015 3318 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-6â€”Time domain representation of the long sequence (continued) ## Re Im ## Re Im ## Re Im ## Re Im 148 0.024 0.059 149 â€“0.137 0.047 150 0.001 0.115 151 0.053 â€“0.004 152 0.098 0.026 153 â€“0.038 0.106 154 â€“0.115 0.055 155 0.060 0.088 156 0.021 â€“0.028 157 0.097 â€“0.083 158 0.040 0.111 159 â€“0.005 0.120 160 0.078 0 I.1.4 Generation of the SIGNAL field I.1.4.1 SIGNAL field bit assignment The SIGNAL field bit assignment follows 17.3.4 and Figure 17-5. The transmitted bits are shown in Table I- 7, where bit 0 is transmitted first. Table I-7â€”Bit assignment for SIGNAL field ## Bit Meaning ## Bit Meaning 0 1 RATE: R1 12 0 â€” 1 0 RATE: R2 13 0 â€” 2 1 RATE: R3 14 0 â€” 3 1 RATE: R4 15 0 â€” 4 0 Reserved 16 0 LENGTH (MSB) 5 0 LENGTH (LSB) 17 0 Parity 6 0 â€” 18 0 SIGNAL TAIL 7 1 â€” 19 0 SIGNAL TAIL 8 0 â€” 20 0 SIGNAL TAIL 9 0 â€” 21 0 SIGNAL TAIL 10 1 â€” 22 0 SIGNAL TAIL 11 1 â€” 23 0 SIGNAL TAIL 3319 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications I.1.4.2 Coding the SIGNAL field bits The bits are encoded by the rate 1/2 convolutional encoder to yield the 48 bits given in Table I-8. Table I-8â€”SIGNAL field bits after encoding ## Bit ## Bit ## Bit ## Bit ## Bit ## Bit 0 1 8 1 16 0 24 0 32 0 40 0 1 1 9 0 17 0 25 0 33 1 41 0 2 0 10 1 18 0 26 1 34 1 42 0 3 1 11 0 19 0 27 1 35 1 43 0 4 0 12 0 20 0 28 1 36 0 44 0 5 0 13 0 21 0 29 1 37 0 45 0 6 0 14 0 22 1 30 1 38 0 46 0 7 1 15 1 23 0 31 0 39 0 47 0 I.1.4.3 Interleaving the SIGNAL field bits The encoded bits are interleaved according to the interleaver of 17.3.5.7. A detailed breakdown of the interleaving operation is described in I.1.6.2. The interleaved SIGNAL field bits are shown in Table I-9. Table I-9â€”SIGNAL field bits after interleaving ## Bit ## Bit ## Bit ## Bit ## Bit ## Bit 0 1 8 1 16 0 24 1 32 0 40 1 1 0 9 1 17 0 25 0 33 0 41 0 2 0 10 0 18 0 26 0 34 1 42 0 3 1 11 1 19 1 27 0 35 0 43 1 4 0 12 0 20 0 28 0 36 0 44 0 5 1 13 0 21 1 29 0 37 1 45 1 6 0 14 0 22 0 30 1 38 0 46 0 7 0 15 0 23 0 31 1 39 0 47 0 I.1.4.4 SIGNAL field frequency domain The encoded and interleaved bits are BPSK modulated to yield the frequency domain representation given in Table I-10. Locations â€“21, â€“7, 7, and 21 are skipped and are used for pilot insertion. 3320 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-10â€”Frequency domain representation of SIGNAL field ## Re Im ## Re Im ## Re Im ## Re Im â€“32 0.000 0.000 â€“16 1.000 0.000 0 0.000 0.000 16 â€“1.000 0.000 â€“31 0.000 0.000 â€“15 â€“1.000 0.000 1 1.000 0.000 17 â€“1.000 0.000 â€“30 0.000 0.000 â€“14 1.000 0.000 2 â€“1.000 0.000 18 1.000 0.000 â€“29 0.000 0.000 â€“13 â€“1.000 0.000 3 â€“1.000 0.000 19 â€“1.000 0.000 â€“28 0.000 0.000 â€“12 â€“1.000 0.000 4 â€“1.000 0.000 20 â€“1.000 0.000 â€“27 0.000 0.000 â€“11 â€“1.000 0.000 5 â€“1.000 0.000 21 X X â€“26 1.000 0.000 â€“10 â€“1.000 0.000 6 â€“1.000 0.000 22 1.000 0.000 â€“25 â€“1.000 0.000 â€“9 â€“1.000 0.000 7 X X 23 â€“1.000 0.000 â€“24 â€“1.000 0.000 â€“8 â€“1.000 0.000 8 1.000 0.000 24 1.000 0.000 â€“23 1.000 0.000 â€“7 X X 9 1.000 0.000 25 â€“1.000 0.000 â€“22 â€“1.000 0.000 â€“6 â€“1.000 0.000 10 â€“1.000 0.000 26 â€“1.000 0.000 â€“21 X X â€“5 1.000 0.000 11 â€“1.000 0.000 27 0.000 0.000 â€“20 1.000 0.000 â€“4 â€“1.000 0.000 12 1.000 0.000 28 0.000 0.000 â€“19 â€“1.000 0.000 â€“3 1.000 0.000 13 â€“1.000 0.000 29 0.000 0.000 â€“18 â€“1.000 0.000 â€“2 â€“1.000 0.000 14 â€“1.000 0.000 30 0.000 0.000 â€“17 1.000 0.000 â€“1 â€“1.000 0.000 15 1.000 0.000 31 0.000 0.000 Four pilot subcarriers are added by taking the values {1.0,1.0,1.0,â€“1.0}, multiplying them by the first element of sequence p0â€¦126, given in Equation (17-22) (in 17.3.5.10), and inserting them into location {â€“21, â€“7,7,21}, respectively. The resulting frequency domain values are given in Table I-11. Table I-11â€”Frequency domain representation of SIGNAL field with pilots inserted ## Re Im ## Re Im ## Re Im ## Re Im â€“32 0.000 0.000 â€“16 1.000 0.000 0 0.000 0.000 16 â€“1.000 0.000 â€“31 0.000 0.000 â€“15 â€“1.000 0.000 1 1.000 0.000 17 â€“1.000 0.000 â€“30 0.000 0.000 â€“14 1.000 0.000 2 â€“1.000 0.000 18 1.000 0.000 â€“29 0.000 0.000 â€“13 â€“1.000 0.000 3 â€“1.000 0.000 19 â€“1.000 0.000 â€“28 0.000 0.000 â€“12 â€“1.000 0.000 4 â€“1.000 0.000 20 â€“1.000 0.000 â€“27 0.000 0.000 â€“11 â€“1.000 0.000 5 â€“1.000 0.000 21 â€“1.000 0.000 â€“26 1.000 0.000 â€“10 â€“1.000 0.000 6 â€“1.000 0.000 22 1.000 0.000 â€“25 â€“1.000 0.000 â€“9 â€“1.000 0.000 7 1.000 0.000 23 â€“1.000 0.000 â€“24 â€“1.000 0.000 â€“8 â€“1.000 0.000 8 1.000 0.000 24 1.000 0.000 3321 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-11â€”Frequency domain representation of SIGNAL field with pilots inserted (continued) ## Re Im ## Re Im ## Re Im ## Re Im â€“23 1.000 0.000 â€“7 1.000 0.000 9 1.000 0.000 25 â€“1.000 0.000 â€“22 â€“1.000 0.000 â€“6 â€“1.000 0.000 10 â€“1.000 0.000 26 â€“1.000 0.000 â€“21 1.000 0.000 â€“5 1.000 0.000 11 â€“1.000 0.000 27 0.000 0.000 â€“20 1.000 0.000 â€“4 â€“1.000 0.000 12 1.000 0.000 28 0.000 0.000 â€“19 â€“1.000 0.000 â€“3 1.000 0.000 13 â€“1.000 0.000 29 0.000 0.000 â€“18 â€“1.000 0.000 â€“2 â€“1.000 0.000 14 â€“1.000 0.000 30 0.000 0.000 â€“17 1.000 0.000 â€“1 â€“1.000 0.000 15 1.000 0.000 31 0.000 0.000 I.1.4.5 SIGNAL field time domain The time domain representation is derived by performing IFFT on the contents of Table I-11, extending cyclically, and multiplying by the window function 0.5 k=0 W k = 1 1 k 79 0.5 k = 80 The resulting 81 samples vector is shown in Table I-12. Note that the time-windowing feature illustrated here is not a part of the normative specifications. Table I-12â€”Time domain representation of SIGNAL field ## Re Im ## Re Im ## Re Im ## Re Im 0 0.031 0.000 1 0.033 â€“0.044 2 â€“0.002 â€“0.038 3 â€“0.081 0.084 4 0.007 â€“0.100 5 â€“0.001 â€“0.113 6 â€“0.021 â€“0.005 7 0.136 â€“0.105 8 0.098 â€“0.044 9 0.011 â€“0.002 10 â€“0.033 0.044 11 â€“0.060 0.124 12 0.010 0.097 13 0.000 â€“0.008 14 0.018 â€“0.083 15 â€“0.069 0.027 16 â€“0.219 0.000 17 â€“0.069 â€“0.027 18 0.018 0.083 19 0.000 0.008 20 0.010 â€“0.097 21 â€“0.060 â€“0.124 22 â€“0.033 â€“0.044 23 0.011 0.002 24 0.098 0.044 25 0.136 0.105 26 â€“0.021 0.005 27 â€“0.001 0.113 28 0.007 0.100 29 â€“0.081 â€“0.084 30 â€“0.002 0.038 31 0.033 0.044 32 0.062 0.000 33 0.057 0.052 34 0.016 0.174 35 0.035 0.116 36 â€“0.051 â€“0.202 37 0.011 0.036 38 0.089 0.209 39 â€“0.049 â€“0.008 40 â€“0.035 0.044 41 0.017 â€“0.059 42 0.053 â€“0.017 43 0.099 0.100 44 0.034 â€“0.148 45 â€“0.003 â€“0.094 46 â€“0.120 0.042 47 â€“0.136 â€“0.070 3322 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-12â€”Time domain representation of SIGNAL field (continued) ## Re Im ## Re Im ## Re Im ## Re Im 48 â€“0.031 0.000 49 â€“0.136 0.070 50 â€“0.120 â€“0.042 51 â€“0.003 0.094 52 0.034 0.148 53 0.099 â€“0.100 54 0.053 0.017 55 0.017 0.059 56 â€“0.035 â€“0.044 57 â€“0.049 0.008 58 0.089 â€“0.209 59 0.011 â€“0.036 60 â€“0.051 0.202 61 0.035 â€“0.116 62 0.016 â€“0.174 63 0.057 â€“0.052 64 0.062 0.000 65 0.033 â€“0.044 66 â€“0.002 â€“0.038 67 â€“0.081 0.084 68 0.007 â€“0.100 69 â€“0.001 â€“0.113 70 â€“0.021 â€“0.005 71 0.136 â€“0.105 72 0.098 â€“0.044 73 0.011 â€“0.002 74 â€“0.033 0.044 75 â€“0.060 0.124 76 0.010 0.097 77 0.000 â€“0.008 78 0.018 â€“0.083 79 â€“0.069 0.027 80 â€“0.109 0.000 The SIGNAL field samples are appended with one sample overlap to the preamble, given in Table I-6. I.1.5 Generating the DATA bits for the BCC example I.1.5.1 Delineating, SERVICE field prepending, and zero padding The transmitted message shown in Table I-1 contains 100 octets or, equivalently, 800 bits. The bits are prepended by the 16 SERVICE field bits and are appended by 6 tail bits. The resulting 822 bits are appended by some number of bits with value 0 to yield an integer number of OFDM symbols. For the 36 Mb/s mode, there are 144 data bits per OFDM symbol; the overall number of bits is 822 144 144 = 864. Hence, 864 â€“ 822 = 42 zero bits are appended. The DATA bits are shown in Table I-13. Table I-13â€”The DATA bits before scrambling Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal Bit ## B7 B0 B15 B8 B23 B16 value value value 000-023 00000000 00000000 00000100 0x00 0x00 0x04 024-047 00000010 00000000 00101110 0x02 0x00 0x2E 048-071 00000000 01100000 00001000 0x00 0x60 0x08 072-095 11001101 00110111 10100110 0xCD 0x37 0xA6 096-119 00000000 00100000 11010110 0x00 0x20 0xD6 120-143 00000001 00111100 11110001 0x01 0x3C 0xF1 144-167 00000000 01100000 00001000 0x00 0x60 0x08 168-191 10101101 00111011 10101111 0xAD 0x3B 0xAF 192-215 00000000 00000000 01001010 0x00 0x00 0x4A 3323 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-13â€”The DATA bits before scrambling (continued) Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal Bit ## B7 B0 B15 B8 B23 B16 value value value 216-239 01101111 01111001 00101100 0x6F 0x79 0x2C 240-263 00100000 01100010 01110010 0x20 0x62 0x72 264-287 01101001 01100111 01101000 0x69 0x67 0x68 288-311 01110100 00100000 01110011 0x74 0x20 0x73 312-335 01110000 01100001 01110010 0x70 0x61 0x72 336-359 01101011 00100000 01101111 0x6B 0x20 0x6F 360-383 01100110 00100000 01100100 0x66 0x20 0x64 384-407 01101001 01110110 01101001 0x69 0x76 0x69 408-431 01101110 01101001 01110100 0x6E 0x69 0x74 432-455 01111001 00101100 00001010 0x79 0x2C 0x0A 456-479 01000100 01100001 01110101 0x44 0x61 0x75 480-503 01100111 01101000 01110100 0x67 0x68 0x74 504-527 01100101 01110010 00100000 0x65 0x72 0x20 528-551 01101111 01100110 00100000 0x6F 0x66 0x20 552-575 01000101 01101100 01111001 0x45 0x6C 0x79 576-599 01110011 01101001 01110101 0x73 0x69 0x75 600-623 01101101 00101100 00001010 0x6D 0x2C 0x0A 624-647 01000110 01101001 01110010 0x46 0x69 0x72 648-671 01100101 00101101 01101001 0x65 0x2D 0x69 672-695 01101110 01110011 01101001 0x6E 0x73 0x69 696-719 01110010 01100101 01100100 0x72 0x65 0x64 720-743 00100000 01110111 01100101 0x20 0x77 0x65 744-767 00100000 01110100 01110010 0x20 0x74 0x72 768-791 01100101 01100001 01100111 0x65 0x61 0x67 792-815 00110011 00100001 10110110 0x33 0x21 0xB6 816-839 00000000 00000000 00000000 0x00 0x00 0x00 840-863 00000000 00000000 00000000 0x00 0x00 0x00 3324 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications I.1.5.2 Scrambling the BCC example The 864 bits are scrambled by the scrambler defined in 17.3.5.5. The initial state of the scrambler is the state 1011101. The generated scrambling sequence is given in Table I-14. Table I-14â€”Scrambling sequence for seed 1011101 ## Bit ## Bit ## Bit ## Bit ## Bit ## Bit ## Bit ## Bit 0 0 16 1 32 0 48 1 64 0 80 0 96 0 112 1 1 1 17 0 33 1 49 1 65 1 81 0 97 0 113 0 2 1 18 1 34 1 50 1 66 1 82 1 98 1 114 0 3 0 19 0 35 0 51 1 67 1 83 1 99 0 115 1 4 1 20 1 36 1 52 0 68 0 84 1 100 0 116 1 5 1 21 0 37 0 53 1 69 0 85 0 101 1 117 0 6 0 22 0 38 0 54 0 70 0 86 1 102 0 118 0 7 0 23 1 39 0 55 0 71 1 87 1 103 0 119 0 8 0 24 1 40 0 56 1 72 1 88 1 104 0 120 1 9 0 25 1 41 1 57 0 73 1 89 1 105 0 121 0 10 0 26 0 42 0 58 1 74 1 90 0 106 0 122 1 11 1 27 0 43 1 59 0 75 1 91 0 107 0 123 1 12 1 28 1 44 0 60 0 76 1 92 1 108 1 124 1 13 0 29 1 45 1 61 0 77 1 93 0 109 0 125 0 14 0 30 1 46 0 62 1 78 0 94 1 110 0 126 1 15 1 31 1 47 1 63 1 79 0 95 1 111 0 After scrambling, the 6 bits in location 816 (i.e., bit 817) to 821 (i.e., bit 822) are set to 0. The scrambled DATA bits are shown in Table I-15. Table I-15â€”The DATA bits after scrambling Binary Binary Binary Hexadecimal Hexadecimal Hexadecimal Bit ## Value Value Value value value value B0 B7 B8 B15 B16 B23 000-023 01101100 00011001 10001001 0x6C 0x19 0x89 024-047 10001111 01101000 00100001 0x8F 0x68 0x21 048-071 11110100 10100101 01100001 0xF4 0xA5 0x61 072-095 01001111 11010111 10101110 0x4F 0xD7 0xAE 096-119 00100100 00001100 11110011 0x24 0x0C 0xF3 120-143 00111010 11100100 10111100 0x3A 0xE4 0xBC 3325 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-15â€”The DATA bits after scrambling (continued) Binary Binary Binary Hexadecimal Hexadecimal Hexadecimal Bit ## Value Value Value value value value B0 B7 B8 B15 B16 B23 144-167 01010011 10011000 11000000 0x53 0x98 0xC0 168-191 00011110 00110101 10110011 0x1E 0x35 0xB3 192-215 11100011 11111000 00100101 0xE3 0xF8 0x25 216-239 01100000 11010110 00100101 0x60 0xD6 0x25 240-263 00110101 00110011 11111110 0x35 0x33 0xFE 264-287 11110000 01000001 00101011 0xF0 0x41 0x2B 288-311 10001111 01010011 00011100 0x8F 0x53 0x1C 312-335 10000011 01000001 10111110 0x83 0x41 0xBE 336-359 00111001 00101000 01100110 0x39 0x28 0x66 360-383 01000100 01100110 11001101 0x44 0x66 0xCD 384-407 11110110 10100011 11011000 0xF6 0xA3 0xD8 408-431 00001101 11010100 10000001 0x0D 0xD4 0x81 432-455 00111011 00101111 11011111 0x3B 0x2F 0xDF 456-479 11000011 01011000 11110111 0xC3 0x58 0xF7 480-503 11000110 01010010 11101011 0xC6 0x52 0xEB 504-527 01110000 10001111 10011110 0x70 0x8F 0x9E 528-551 01101010 10010000 10000001 0x6A 0x90 0x81 552-575 11111101 01111100 10101001 0xFD 0x7C 0xA9 576-599 11010001 01010101 00010010 0xD1 0x55 0x12 600-623 00000100 01110100 11011001 0x04 0x74 0xD9 624-647 11101001 00111011 11001101 0xE9 0x3B 0xCD 648-671 10010011 10001101 01111011 0x93 0x8D 0x7B 672-695 01111100 01110000 00000010 0x7C 0x70 0x02 696-719 00100000 10011001 10100001 0x20 0x99 0xA1 720-743 01111101 10001010 00100111 0x7D 0x8A 0x27 744-767 00010111 00111001 00010101 0x17 0x39 0x15 768-791 10100000 11101100 10010101 0xA0 0xEC 0x95 792-815 00010110 10010001 00010000 0x16 0x91 0x10 816-839 00000000 11011100 01111111 0x00 0xDC 0x7F 840-863 00001110 11110010 11001001 0x0E 0xF2 0xC9 3326 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications I.1.6 Generating the first DATA symbol for the BCC example I.1.6.1 Coding the DATA bits The scrambled bits are coded with a rate convolutional code. The DATA encoded bits are shown in Table I-16. Table I-16â€”The BCC encoded DATA bits Binary Binary Binary Binary Bit Hexadecimal Hexadecimal Hexadecimal Hexadecimal Value Value Value Value ## value value value value B0B7 B8B15 B16B23 B24B31 0000 00101011 00001000 10100001 11110000 0x2B 0x08 0xA1 0xF0 - 0031 0032 10011101 10110101 10011010 00011101 0x9D 0xB5 0x9A 0x1D - 0063 0064 01001010 11111011 11101000 11000010 0x4A 0xFB 0xE8 0xC2 - 0095 0096 10001111 11000000 11001000 01110011 0x8F 0xC0 0xC8 0x73 - 0127 0128 11000000 01000011 11100000 00011001 0xC0 0x43 0xE0 0x19 - 0159 0160 11100000 11010011 11101011 10110010 0xE0 0xD3 0xEB 0xB2 - 0191 0192 10101111 10011000 11111101 01011001 0xAF 0x98 0xFD 0x59 - 0223 0224 00001111 10001011 01101001 01100110 0x0F 0x8B 0x69 0x66 - 0255 0256 00001100 10101010 11011001 00010000 0x0C 0xAA 0xD9 0x10 - 0287 0288 01010110 10001011 10100110 01000000 0x56 0x8B 0xA6 0x40 - 0319 0320 01100100 10110011 00100001 10011110 0x64 0xB3 0x21 0x9E - 0351 0352 10001110 10010001 11000001 00000101 0x8E 0x91 0xC1 0x05 - 0383 3327 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-16â€”The BCC encoded DATA bits (continued) Binary Binary Binary Binary Bit Hexadecimal Hexadecimal Hexadecimal Hexadecimal Value Value Value Value ## value value value value B0B7 B8B15 B16B23 B24B31 0384 10110111 10110111 11000101 11011000 0xB7 0xB7 0xC5 0xD8 - 0415 0416 10000000 00101111 10100010 11011101 0x80 0x2F 0xA2 0xDD - 0447 0448 01101111 00101011 10010111 01100001 0x6F 0x2B 0x97 0x61 - 0479 0480 11011001 11011101 00001101 00010010 0xD9 0xDD 0x0D 0x12 - 0511 0512 01110110 00100111 00000010 01001100 0x76 0x27 0x02 0x4C - 0543 0544 10010010 10111100 00010010 01001011 0x92 0xBC 0x12 0x4B - 0575 0576 01101010 11110111 01110000 00100011 0x6A 0xF7 0x70 0x23 - 0607 0608 00100111 10001110 00000001 10110100 0x27 0x8E 0x01 0xB4 - 0639 0640 11010110 11000011 01101010 01100000 0xD6 0xC3 0x6A 0x60 - 0671 0672 01001101 01001011 11001011 01010001 0x4D 0x4B 0xCB 0x51 - 0703 0704 10011100 10110000 10000000 11101011 0x9C 0xB0 0x80 0xEB - 0735 0736 10001001 00110100 00010100 01000000 0x89 0x34 0x14 0x40 - 0767 0768 01101100 10011110 00101100 01010001 0x6C 0x9E 0x2C 0x51 - 0799 0800 01001011 01111100 01101001 00010001 0x4B 0x7C 0x69 0x11 - 0831 3328 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-16â€”The BCC encoded DATA bits (continued) Binary Binary Binary Binary Bit Hexadecimal Hexadecimal Hexadecimal Hexadecimal Value Value Value Value ## value value value value B0B7 B8B15 B16B23 B24B31 0832 00010101 10000110 11111101 10111110 0x15 0x86 0xFD 0xBE - 0863 0864 01011110 11111001 10111110 00101000 0x5E 0xF9 0xBE 0x28 - 0895 0896 11101111 11001010 01010101 00000011 0xEF 0xCA 0x55 0x03 - 0927 0928 11111101 00100110 10010001 00111011 0xFD 0x26 0x91 0x3B - 0959 0960 10010101 11101100 01011011 00100011 0x95 0xEC 0x5B 0x23 - 0991 0992 10011001 01011111 00101000 00111110 0x99 0x5F 0x28 0x3E - 1023 1024 11010100 11101001 11110111 10111000 0xD4 0xE9 0xF7 0xB8 - 1055 1056 00010011 01110101 10001110 11110010 0x13 0x75 0x8E 0xF2 - 1087 1088 10100000 00011011 01101100 11101001 0xA0 0x1B 0x6C 0xE9 - 1119 1120 00000111 01011101 10110000 10111111 0x07 0x5D 0xB0 0xBF - 1151 I.1.6.2 Interleaving the DATA bits The interleaver is defined as a two-permutation process. The index of the coded bit before the first permutation shall be denoted by k; i shall be the index after the first and before the second permutation; and j shall be the index after the second permutation, just prior to modulation mapping. The mapping from k to i is shown in Table I-17, and the mapping from i to j is shown in Table I-18. As a specific example, consider the case of k = 17 (the 18th bit after encoding and puncturing). It is mapped by the first permutation to i = 13 and by the second permutation to j = 12 (the 13th bit before mapping). The interleaved bits are shown in Table I-19. 3329 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-17â€”First permutation k i k i k i k i k i k i k i k i 0 0 24 97 48 3 72 100 96 6 120 103 144 9 168 106 1 12 25 109 49 15 73 112 97 18 121 115 145 21 169 118 2 24 26 121 50 27 74 124 98 30 122 127 146 33 170 130 3 36 27 133 51 39 75 136 99 42 123 139 147 45 171 142 4 48 28 145 52 51 76 148 100 54 124 151 148 57 172 154 5 60 29 157 53 63 77 160 101 66 125 163 149 69 173 166 6 72 30 169 54 75 78 172 102 78 126 175 150 81 174 178 7 84 31 181 55 87 79 184 103 90 127 187 151 93 175 190 8 96 32 2 56 99 80 5 104 102 128 8 152 105 176 11 9 108 33 14 57 111 81 17 105 114 129 20 153 117 177 23 10 120 34 26 58 123 82 29 106 126 130 32 154 129 178 35 11 132 35 38 59 135 83 41 107 138 131 44 155 141 179 47 12 144 36 50 60 147 84 53 108 150 132 56 156 153 180 59 13 156 37 62 61 159 85 65 109 162 133 68 157 165 181 71 14 168 38 74 62 171 86 77 110 174 134 80 158 177 182 83 15 180 39 86 63 183 87 89 111 186 135 92 159 189 183 95 16 1 40 98 64 4 88 101 112 7 136 104 160 10 184 107 17 13 41 110 65 16 89 113 113 19 137 116 161 22 185 119 18 25 42 122 66 28 90 125 114 31 138 128 162 34 186 131 19 37 43 134 67 40 91 137 115 43 139 140 163 46 187 143 20 49 44 146 68 52 92 149 116 55 140 152 164 58 188 155 21 61 45 158 69 64 93 161 117 67 141 164 165 70 189 167 22 73 46 170 70 76 94 173 118 79 142 176 166 82 190 179 23 85 47 182 71 88 95 185 119 91 143 188 167 94 191 191 Table I-18â€”Second permutation i j i j i j i j i j i j i j i j 0 0 24 24 48 48 72 72 96 96 120 120 144 144 168 168 1 1 25 25 49 49 73 73 97 97 121 121 145 145 169 169 2 2 26 26 50 50 74 74 98 98 122 122 146 146 170 170 3 3 27 27 51 51 75 75 99 99 123 123 147 147 171 171 4 4 28 28 52 52 76 76 100 100 124 124 148 148 172 172 3330 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-18â€”Second permutation (continued) i j i j i j i j i j i j i j i j 5 5 29 29 53 53 77 77 101 101 125 125 149 149 173 173 6 6 30 30 54 54 78 78 102 102 126 126 150 150 174 174 7 7 31 31 55 55 79 79 103 103 127 127 151 151 175 175 8 8 32 32 56 56 80 80 104 104 128 128 152 152 176 176 9 9 33 33 57 57 81 81 105 105 129 129 153 153 177 177 10 10 34 34 58 58 82 82 106 106 130 130 154 154 178 178 11 11 35 35 59 59 83 83 107 107 131 131 155 155 179 179 12 13 36 37 60 61 84 85 108 109 132 133 156 157 180 181 13 12 37 36 61 60 85 84 109 108 133 132 157 156 181 180 14 15 38 39 62 63 86 87 110 111 134 135 158 159 182 183 15 14 39 38 63 62 87 86 111 110 135 134 159 158 183 182 16 17 40 41 64 65 88 89 112 113 136 137 160 161 184 185 17 16 41 40 65 64 89 88 113 112 137 136 161 160 185 184 18 19 42 43 66 67 90 91 114 115 138 139 162 163 186 187 19 18 43 42 67 66 91 90 115 114 139 138 163 162 187 186 20 21 44 45 68 69 92 93 116 117 140 141 164 165 188 189 21 20 45 44 69 68 93 92 117 116 141 140 165 164 189 188 22 23 46 47 70 71 94 95 118 119 142 143 166 167 190 191 23 22 47 46 71 70 95 94 119 118 143 142 167 166 191 190 Table I-19â€”Interleaved bits of first DATA symbol ## Bit ## Bit ## Bit ## Bit ## Bit ## Bit 0 0 32 0 64 0 96 0 128 0 160 0 1 1 33 1 65 0 97 1 129 0 161 0 2 1 34 1 66 0 98 1 130 0 162 0 3 1 35 1 67 1 99 0 131 1 163 0 4 0 36 0 68 0 100 1 132 1 164 0 5 1 37 0 69 0 101 1 133 0 165 0 6 1 38 1 70 0 102 1 134 1 166 0 7 1 39 1 71 0 103 0 135 1 167 0 8 1 40 0 72 1 104 0 136 0 168 0 9 1 41 0 73 0 105 0 137 1 169 0 3331 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-19â€”Interleaved bits of first DATA symbol (continued) ## Bit ## Bit ## Bit ## Bit ## Bit ## Bit 10 1 42 0 74 0 106 1 138 1 170 0 11 1 43 0 75 1 107 1 139 0 171 0 12 0 44 0 76 1 108 1 140 1 172 1 13 0 45 0 77 0 109 0 141 0 173 1 14 0 46 0 78 1 110 0 142 1 174 0 15 0 47 0 79 0 111 0 143 1 175 1 16 1 48 1 80 0 112 1 144 1 176 1 17 1 49 0 81 0 113 1 145 0 177 0 18 1 50 1 82 0 114 1 146 0 178 1 19 0 51 1 83 1 115 1 147 1 179 1 20 1 52 1 84 1 116 0 148 1 180 0 21 1 53 1 85 1 117 1 149 0 181 0 22 1 54 1 86 0 118 0 150 0 182 1 23 1 55 1 87 1 119 1 151 0 183 1 24 1 56 0 88 0 120 0 152 0 184 0 25 1 57 0 89 0 121 1 153 1 185 1 26 0 58 0 90 0 122 1 154 0 186 1 27 0 59 1 91 1 123 0 155 0 187 0 28 0 60 0 92 0 124 1 156 0 188 1 29 1 61 0 93 0 125 0 157 0 189 1 30 0 62 0 94 1 126 0 158 1 190 0 31 0 63 1 95 0 127 1 159 1 191 1 I.1.6.3 Mapping into symbols The frequency domain symbols are generated by grouping 4 coded bits and mapping into complex 16-QAM symbols according to Table 17-14 (in 17.3.5.8). For instance, the first 4 bits (0 1 1 1) are mapped to the complex value, â€“0.316 + 0.316j, inserted at subcarrier #26. Four pilot subcarriers are added by taking the values {1.0,1.0,1.0,â€“1.0}, multiplying them by the second element of sequence p, given in Equation (17-22) (in 17.3.5.10), and inserting them into location {â€“21,â€“7,7,21}, respectively. The frequency domain is shown in Table I-20. The time domain samples are produced by performing IFFT, cyclically extending, and multiplying with the window function in the same manner as described in I.1.4.5. The time domain samples are appended with one sample overlap to the SIGNAL field symbol. 3332 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-20â€”Frequency domain of first DATA symbol ## Re Im ## Re Im ## Re Im ## Re Im â€“32 0.000 0.000 â€“16 â€“0.949 0.316 0 0.000 0.000 16 â€“0.316 â€“0.949 â€“31 0.000 0.000 â€“15 â€“0.949 â€“0.949 1 â€“0.316 0.949 17 â€“0.949 0.316 â€“30 0.000 0.000 â€“14 â€“0.949 â€“0.949 2 0.316 0.949 18 â€“0.949 â€“0.949 â€“29 0.000 0.000 â€“13 0.949 0.316 3 â€“0.949 0.316 19 â€“0.949 â€“0.949 â€“28 0.000 0.000 â€“12 0.316 0.316 4 0.949 â€“0.949 20 â€“0.949 â€“0.949 â€“27 0.000 0.000 â€“11 â€“0.949 â€“0.316 5 0.316 0.316 21 â€“1.000 0.000 â€“26 â€“0.316 0.316 â€“10 â€“0.949 â€“0.316 6 â€“0.316 â€“0.316 22 0.316 â€“0.316 â€“25 â€“0.316 0.316 â€“9 â€“0.949 â€“0.316 7 1.000 0.000 23 0.949 0.316 â€“24 0.316 0.316 â€“8 â€“0.949 â€“0.949 8 â€“0.316 0.949 24 â€“0.949 0.316 â€“23 â€“0.949 â€“0.949 â€“7 1.000 0.000 9 0.949 â€“0.316 25 â€“0.316 0.949 â€“22 0.316 0.949 â€“6 0.949 â€“0.316 10 â€“0.949 â€“0.316 26 0.316 â€“0.316 â€“21 1.000 0.000 â€“5 0.949 0.949 11 0.949 0.316 27 0.000 0.000 â€“20 0.316 0.316 â€“4 â€“0.949 â€“0.316 12 â€“0.316 0.949 28 0.000 0.000 â€“19 0.316 â€“0.949 â€“3 0.316 â€“0.316 13 0.949 0.316 29 0.000 0.000 â€“18 â€“0.316 â€“0.949 â€“2 â€“0.949 â€“0.316 14 0.949 â€“0.316 30 0.000 0.000 â€“17 â€“0.316 0.316 â€“1 â€“0.949 0.949 15 0.949 â€“0.949 31 0.000 0.000 I.1.7 Generating the additional DATA symbols The generation of the additional five data symbols follows the same procedure as described in Clause 4. Special attention should be paid to the scrambling of the pilot subcarriers. Table I-21 lists the polarity of the pilot subcarriers and the elements of the sequence p0â€¦126 for the DATA symbols. For completeness, the pilots in the SIGNAL are included as well. The symbols are appended one after the other with a one-sample overlap. Table I-21â€”Polarity of the pilot subcarriers i OFDM symbol Element of pi Pilot at #â€“21 Pilot at #â€“7 Pilot at #7 Pilot at #21 0 SIGNAL 1 1.0 +0 j 1.0 +0 j 1.0 +0 j â€“1.0 +0 j 1 DATA 1 1 1.0 +0 j 1.0 +0 j 1.0 +0 j â€“1.0 +0 j 2 DATA 2 1 1.0 +0 j 1.0 +0 j 1.0 +0 j â€“1.0 +0 j 3 DATA 3 1 1.0 +0 j 1.0 +0 j 1.0 +0 j â€“1.0 +0 j 4 DATA 4 â€“1 â€“1.0 +0 j â€“1.0 +0 j â€“1.0 +0 j 1.0 +0 j 5 DATA 5 â€“1 â€“1.0 +0 j â€“1.0 +0 j â€“1.0 +0 j 1.0 +0 j 6 DATA 6 â€“1 â€“1.0 +0 j â€“1.0 +0 j â€“1.0 +0 j 1.0 +0 j 3333 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications I.1.8 The entire packet for the BCC example The packet in its entirety is shown in the tables in this subclause. These tables illustrate the short training sequence section (Table I-22), the long training sequence section (Table I-23), the SIGNAL field (Table I-24), and the six DATA symbols (Table I-25 to Table I-30). Table I-22â€”Time domain representation of the short training sequence ## Real Imag ## Real Imag ## Real Imag ## Real Imag 0 0.023 0.023 1 â€“0.132 0.002 2 â€“0.013 â€“0.079 3 0.143 â€“0.013 4 0.092 0.000 5 0.143 â€“0.013 6 â€“0.013 â€“0.079 7 â€“0.132 0.002 8 0.046 0.046 9 0.002 â€“0.132 10 â€“0.079 â€“0.013 11 â€“0.013 0.143 12 0.000 0.092 13 â€“0.013 0.143 14 â€“0.079 â€“0.013 15 0.002 â€“0.132 16 0.046 0.046 17 â€“0.132 0.002 18 â€“0.013 â€“0.079 19 0.143 â€“0.013 20 0.092 0.000 21 0.143 â€“0.013 22 â€“0.013 â€“0.079 23 â€“0.132 0.002 24 0.046 0.046 25 0.002 â€“0.132 26 â€“0.079 â€“0.013 27 â€“0.013 0.143 28 0.000 0.092 29 â€“0.013 0.143 30 â€“0.079 â€“0.013 31 0.002 â€“0.132 32 0.046 0.046 33 â€“0.132 0.002 34 â€“0.013 â€“0.079 35 0.143 â€“0.013 36 0.092 0.000 37 0.143 â€“0.013 38 â€“0.013 â€“0.079 39 â€“0.132 0.002 40 0.046 0.046 41 0.002 â€“0.132 42 â€“0.079 â€“0.013 43 â€“0.013 0.143 44 0.000 0.092 45 â€“0.013 0.143 46 â€“0.079 â€“0.013 47 0.002 â€“0.132 48 0.046 0.046 49 â€“0.132 0.002 50 â€“0.013 â€“0.079 51 0.143 â€“0.013 52 0.092 0.000 53 0.143 â€“0.013 54 â€“0.013 â€“0.079 55 â€“0.132 0.002 56 0.046 0.046 57 0.002 â€“0.132 58 â€“0.079 â€“0.013 59 â€“0.013 0.143 60 0.000 0.092 61 â€“0.013 0.143 62 â€“0.079 â€“0.013 63 0.002 â€“0.132 64 0.046 0.046 65 â€“0.132 0.002 66 â€“0.013 â€“0.079 67 0.143 â€“0.013 68 0.092 0.000 69 0.143 â€“0.013 70 â€“0.013 â€“0.079 71 â€“0.132 0.002 72 0.046 0.046 73 0.002 â€“0.132 74 â€“0.079 â€“0.013 75 â€“0.013 0.143 76 0.000 0.092 77 â€“0.013 0.143 78 â€“0.079 â€“0.013 79 0.002 â€“0.132 80 0.046 0.046 81 â€“0.132 0.002 82 â€“0.013 â€“0.079 83 0.143 â€“0.013 84 0.092 0.000 85 0.143 â€“0.013 86 â€“0.013 â€“0.079 87 â€“0.132 0.002 88 0.046 0.046 89 0.002 â€“0.132 90 â€“0.079 â€“0.013 91 â€“0.013 0.143 92 0.000 0.092 93 â€“0.013 0.143 94 â€“0.079 â€“0.013 95 0.002 â€“0.132 96 0.046 0.046 97 â€“0.132 0.002 98 â€“0.013 â€“0.079 99 0.143 â€“0.013 100 0.092 0.000 101 0.143 â€“0.013 102 â€“0.013 â€“0.079 103 â€“0.132 0.002 104 0.046 0.046 105 0.002 â€“0.132 106 â€“0.079 â€“0.013 107 â€“0.013 0.143 108 0.000 0.092 109 â€“0.013 0.143 110 â€“0.079 â€“0.013 111 0.002 â€“0.132 3334 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-22â€”Time domain representation of the short training sequence (continued) ## Real Imag ## Real Imag ## Real Imag ## Real Imag 112 0.046 0.046 113 â€“0.132 0.002 114 â€“0.013 â€“0.079 115 0.143 â€“0.013 116 0.092 0.000 117 0.143 â€“0.013 118 â€“0.013 â€“0.079 119 â€“0.132 0.002 120 0.046 0.046 121 0.002 â€“0.132 122 â€“0.079 â€“0.013 123 â€“0.013 0.143 124 0.000 0.092 125 â€“0.013 0.143 126 â€“0.079 â€“0.013 127 0.002 â€“0.132 128 0.046 0.046 129 â€“0.132 0.002 130 â€“0.013 â€“0.079 131 0.143 â€“0.013 132 0.092 0.000 133 0.143 â€“0.013 134 â€“0.013 â€“0.079 135 â€“0.132 0.002 136 0.046 0.046 137 0.002 â€“0.132 138 â€“0.079 â€“0.013 139 â€“0.013 0.143 140 0.000 0.092 141 â€“0.013 0.143 142 â€“0.079 â€“0.013 143 0.002 â€“0.132 144 0.046 0.046 145 â€“0.132 0.002 146 â€“0.013 â€“0.079 147 0.143 â€“0.013 148 0.092 0.000 149 0.143 â€“0.013 150 â€“0.013 â€“0.079 151 â€“0.132 0.002 152 0.046 0.046 153 0.002 â€“0.132 154 â€“0.079 â€“0.013 155 â€“0.013 0.143 156 0.000 0.092 157 â€“0.013 0.143 158 â€“0.079 â€“0.013 159 0.002 â€“0.132 Table I-23â€”Time domain representation of the long training sequence ## Real Imag ## Real Imag ## Real Imag ## Real Imag 160 â€“0.055 0.023 161 0.012 â€“0.098 162 0.092 â€“0.106 163 â€“0.092 â€“0.115 164 â€“0.003 â€“0.054 165 0.075 0.074 166 â€“0.127 0.021 167 â€“0.122 0.017 168 â€“0.035 0.151 169 â€“0.056 0.022 170 â€“0.060 â€“0.081 171 0.070 â€“0.014 172 0.082 â€“0.092 173 â€“0.131 â€“0.065 174 â€“0.057 â€“0.039 175 0.037 â€“0.098 176 0.062 0.062 177 0.119 0.004 178 â€“0.022 â€“0.161 179 0.059 0.015 180 0.024 0.059 181 â€“0.137 0.047 182 0.001 0.115 183 0.053 â€“0.004 184 0.098 0.026 185 â€“0.038 0.106 186 â€“0.115 0.055 187 0.060 0.088 188 0.021 â€“0.028 189 0.097 â€“0.083 190 0.040 0.111 191 â€“0.005 0.120 192 0.156 0.000 193 â€“0.005 â€“0.120 194 0.040 â€“0.111 195 0.097 0.083 196 0.021 0.028 197 0.060 â€“0.088 198 â€“0.115 â€“0.055 199 â€“0.038 â€“0.106 200 0.098 â€“0.026 201 0.053 0.004 202 0.001 â€“0.115 203 â€“0.137 â€“0.047 204 0.024 â€“0.059 205 0.059 â€“0.015 206 â€“0.022 0.161 207 0.119 â€“0.004 208 0.062 â€“0.062 209 0.037 0.098 210 â€“0.057 0.039 211 â€“0.131 0.065 212 0.082 0.092 213 0.070 0.014 214 â€“0.060 0.081 215 â€“0.056 â€“0.022 216 â€“0.035 â€“0.151 217 â€“0.122 â€“0.017 218 â€“0.127 â€“0.021 219 0.075 â€“0.074 220 â€“0.003 0.054 221 â€“0.092 0.115 222 0.092 0.106 223 0.012 0.098 224 â€“0.156 0.000 225 0.012 â€“0.098 226 0.092 â€“0.106 227 â€“0.092 â€“0.115 3335 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-23â€”Time domain representation of the long training sequence (continued) ## Real Imag ## Real Imag ## Real Imag ## Real Imag 228 â€“0.003 â€“0.054 229 0.075 0.074 230 â€“0.127 0.021 231 â€“0.122 0.017 232 â€“0.035 0.151 233 â€“0.056 0.022 234 â€“0.060 â€“0.081 235 0.070 â€“0.014 236 0.082 â€“0.092 237 â€“0.131 â€“0.065 238 â€“0.057 â€“0.039 239 0.037 â€“0.098 240 0.062 0.062 241 0.119 0.004 242 â€“0.022 â€“0.161 243 0.059 0.015 244 0.024 0.059 245 â€“0.137 0.047 246 0.001 0.115 247 0.053 â€“0.004 248 0.098 0.026 249 â€“0.038 0.106 250 â€“0.115 0.055 251 0.060 0.088 252 0.021 â€“0.028 253 0.097 â€“0.083 254 0.040 0.111 255 â€“0.005 0.120 256 0.156 0.000 257 â€“0.005 â€“0.120 258 0.040 â€“0.111 259 0.097 0.083 260 0.021 0.028 261 0.060 â€“0.088 262 â€“0.115 â€“0.055 263 â€“0.038 â€“0.106 264 0.098 â€“0.026 265 0.053 0.004 266 0.001 â€“0.115 267 â€“0.137 â€“0.047 268 0.024 â€“0.059 269 0.059 â€“0.015 270 â€“0.022 0.161 271 0.119 â€“0.004 272 0.062 â€“0.062 273 0.037 0.098 274 â€“0.057 0.039 275 â€“0.131 0.065 276 0.082 0.092 277 0.070 0.014 278 â€“0.060 0.081 279 â€“0.056 â€“0.022 280 â€“0.035 â€“0.151 281 â€“0.122 â€“0.017 282 â€“0.127 â€“0.021 283 0.075 â€“0.074 284 â€“0.003 0.054 285 â€“0.092 0.115 286 0.092 0.106 287 0.012 0.098 288 â€“0.156 0.000 289 0.012 â€“0.098 290 0.092 â€“0.106 291 â€“0.092 â€“0.115 292 â€“0.003 â€“0.054 293 0.075 0.074 294 â€“0.127 0.021 295 â€“0.122 0.017 296 â€“0.035 0.151 297 â€“0.056 0.022 298 â€“0.060 â€“0.081 299 0.070 â€“0.014 300 0.082 â€“0.092 301 â€“0.131 â€“0.065 302 â€“0.057 â€“0.039 303 0.037 â€“0.098 304 0.062 0.062 305 0.119 0.004 306 â€“0.022 â€“0.161 307 0.059 0.015 308 0.024 0.059 309 â€“0.137 0.047 310 0.001 0.115 311 0.053 â€“0.004 312 0.098 0.026 313 â€“0.038 0.106 314 â€“0.115 0.055 315 0.060 0.088 316 0.021 â€“0.028 317 0.097 â€“0.083 318 0.040 0.111 319 â€“0.005 0.120 Table I-24â€”Time domain representation of the SIGNAL field (1 symbol) ## Real Imag ## Real Imag ## Real Imag ## Real Imag 320 0.109 0.000 321 0.033 â€“0.044 322 â€“0.002 â€“0.038 323 â€“0.081 0.084 324 0.007 â€“0.100 325 â€“0.001 â€“0.113 326 â€“0.021 â€“0.005 327 0.136 â€“0.105 328 0.098 â€“0.044 329 0.011 â€“0.002 330 â€“0.033 0.044 331 â€“0.060 0.124 332 0.010 0.097 333 0.000 â€“0.008 334 0.018 â€“0.083 335 â€“0.069 0.027 336 â€“0.219 0.000 337 â€“0.069 â€“0.027 338 0.018 0.083 339 0.000 0.008 340 0.010 â€“0.097 341 â€“0.060 â€“0.124 342 â€“0.033 â€“0.044 343 0.011 0.002 3336 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-24â€”Time domain representation of the SIGNAL field (1 symbol) (continued) ## Real Imag ## Real Imag ## Real Imag ## Real Imag 344 0.098 0.044 345 0.136 0.105 346 â€“0.021 0.005 347 â€“0.001 0.113 348 0.007 0.100 349 â€“0.081 â€“0.084 350 â€“0.002 0.038 351 0.033 0.044 352 0.062 0.000 353 0.057 0.052 354 0.016 0.174 355 0.035 0.116 356 â€“0.051 â€“0.202 357 0.011 0.036 358 0.089 0.209 359 â€“0.049 â€“0.008 360 â€“0.035 0.044 361 0.017 â€“0.059 362 0.053 â€“0.017 363 0.099 0.100 364 0.034 â€“0.148 365 â€“0.003 â€“0.094 366 â€“0.120 0.042 367 â€“0.136 â€“0.070 368 â€“0.031 0.000 369 â€“0.136 0.070 370 â€“0.120 â€“0.042 371 â€“0.003 0.094 372 0.034 0.148 373 0.099 â€“0.100 374 0.053 0.017 375 0.017 0.059 376 â€“0.035 â€“0.044 377 â€“0.049 0.008 378 0.089 â€“0.209 379 0.011 â€“0.036 380 â€“0.051 0.202 381 0.035 â€“0.116 382 0.016 â€“0.174 383 0.057 â€“0.052 384 0.062 0.000 385 0.033 â€“0.044 386 â€“0.002 â€“0.038 387 â€“0.081 0.084 388 0.007 â€“0.100 389 â€“0.001 â€“0.113 390 â€“0.021 â€“0.005 391 0.136 â€“0.105 392 0.098 â€“0.044 393 0.011 â€“0.002 394 â€“0.033 0.044 395 â€“0.060 0.124 396 0.010 0.097 397 0.000 â€“0.008 398 0.018 â€“0.083 399 â€“0.069 0.027 Table I-25â€”Time domain representation of the DATA field: symbol 1of 6 ## Real Imag ## Real Imag ## Real Imag ## Real Imag 400 â€“0.139 0.050 401 0.004 0.014 402 0.011 â€“0.100 403 â€“0.097 â€“0.020 404 0.062 0.081 405 0.124 0.139 406 0.104 â€“0.015 407 0.173 â€“0.140 408 â€“0.040 0.006 409 â€“0.133 0.009 410 â€“0.002 â€“0.043 411 â€“0.047 0.092 412 â€“0.109 0.082 413 â€“0.024 0.010 414 0.096 0.019 415 0.019 â€“0.023 416 â€“0.087 â€“0.049 417 0.002 0.058 418 â€“0.021 0.228 419 â€“0.103 0.023 420 â€“0.019 â€“0.175 421 0.018 0.132 422 â€“0.071 0.160 423 â€“0.153 â€“0.062 424 â€“0.107 0.028 425 0.055 0.140 426 0.070 0.103 427 â€“0.056 0.025 428 â€“0.043 0.002 429 0.016 â€“0.118 430 0.026 â€“0.071 431 0.033 0.177 432 0.020 â€“0.021 433 0.035 â€“0.088 434 â€“0.008 0.101 435 â€“0.035 â€“0.010 436 0.065 0.030 437 0.092 â€“0.034 438 0.032 â€“0.123 439 â€“0.018 0.092 440 0.000 â€“0.006 441 â€“0.006 â€“0.056 442 â€“0.019 0.040 443 0.053 â€“0.131 444 0.022 â€“0.133 445 0.104 â€“0.032 446 0.163 â€“0.045 447 â€“0.105 â€“0.030 448 â€“0.110 â€“0.069 449 â€“0.008 â€“0.092 450 â€“0.049 â€“0.043 451 0.085 â€“0.017 452 0.090 0.063 453 0.015 0.153 454 0.049 0.094 455 0.011 0.034 456 â€“0.012 0.012 457 â€“0.015 â€“0.017 458 â€“0.061 0.031 459 â€“0.070 â€“0.040 3337 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-25â€”Time domain representation of the DATA field: symbol 1of 6 (continued) ## Real Imag ## Real Imag ## Real Imag ## Real Imag 460 0.011 â€“0.109 461 0.037 â€“0.060 462 â€“0.003 â€“0.178 463 â€“0.007 â€“0.128 464 â€“0.059 0.100 465 0.004 0.014 466 0.011 â€“0.100 467 â€“0.097 â€“0.020 468 0.062 0.081 469 0.124 0.139 470 0.104 â€“0.015 471 0.173 â€“0.140 472 â€“0.040 0.006 473 â€“0.133 0.009 474 â€“0.002 â€“0.043 475 â€“0.047 0.092 476 â€“0.109 0.082 477 â€“0.024 0.010 478 0.096 0.019 479 0.019 â€“0.023 Table I-26â€”Time domain representation of the DATA field: symbol 2 of 6 ## Real Imag ## Real Imag ## Real Imag ## Real Imag 480 â€“0.058 0.016 481 â€“0.096 â€“0.045 482 â€“0.110 0.003 483 â€“0.070 0.216 484 â€“0.040 0.059 485 0.010 â€“0.056 486 0.034 0.065 487 0.117 0.033 488 0.078 â€“0.133 489 â€“0.043 â€“0.146 490 0.158 â€“0.071 491 0.254 â€“0.021 492 0.068 0.117 493 â€“0.044 0.114 494 â€“0.035 0.041 495 0.085 0.070 496 0.120 0.010 497 0.057 0.055 498 0.063 0.188 499 0.091 0.149 500 â€“0.017 â€“0.039 501 â€“0.078 â€“0.075 502 0.049 0.079 503 â€“0.014 â€“0.007 504 0.030 â€“0.027 505 0.080 0.054 506 â€“0.186 â€“0.067 507 â€“0.039 â€“0.027 508 0.043 â€“0.072 509 â€“0.092 â€“0.089 510 0.029 0.105 511 â€“0.144 0.003 512 â€“0.069 â€“0.041 513 0.132 0.057 514 â€“0.126 0.070 515 â€“0.031 0.109 516 0.161 â€“0.009 517 0.056 â€“0.046 518 â€“0.004 0.028 519 â€“0.049 0.000 520 â€“0.078 â€“0.005 521 0.015 â€“0.087 522 0.149 â€“0.104 523 â€“0.021 â€“0.051 524 â€“0.154 â€“0.106 525 0.024 0.030 526 0.046 0.123 527 â€“0.004 â€“0.098 528 â€“0.061 â€“0.128 529 â€“0.024 â€“0.038 530 0.066 â€“0.048 531 â€“0.067 0.027 532 0.054 â€“0.050 533 0.171 â€“0.049 534 â€“0.108 0.132 535 â€“0.161 â€“0.019 536 â€“0.070 â€“0.072 537 â€“0.177 0.049 538 â€“0.172 â€“0.050 539 0.051 â€“0.075 540 0.122 â€“0.057 541 0.009 â€“0.044 542 â€“0.012 â€“0.021 543 0.004 0.009 544 â€“0.030 0.081 545 â€“0.096 â€“0.045 546 â€“0.110 0.003 547 â€“0.070 0.216 548 â€“0.040 0.059 549 0.010 â€“0.056 550 0.034 0.065 551 0.117 0.033 552 0.078 â€“0.133 553 â€“0.043 â€“0.146 554 0.158 â€“0.071 555 0.254 â€“0.021 556 0.068 0.117 557 â€“0.044 0.114 558 â€“0.035 0.041 559 0.085 0.070 3338 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-27â€”Time domain representation of the DATA field: symbol 3 of 6 ## Real Imag ## Real Imag ## Real Imag ## Real Imag 560 0.001 0.011 561 â€“0.099 â€“0.048 562 0.054 â€“0.196 563 0.124 0.035 564 0.092 0.045 565 â€“0.037 â€“0.066 566 â€“0.021 â€“0.004 567 0.042 â€“0.065 568 0.061 0.048 569 0.046 0.004 570 â€“0.063 â€“0.045 571 â€“0.102 0.152 572 â€“0.039 â€“0.019 573 â€“0.005 â€“0.106 574 0.083 0.031 575 0.226 0.028 576 0.140 â€“0.010 577 â€“0.132 â€“0.033 578 â€“0.116 0.088 579 0.023 0.052 580 â€“0.171 â€“0.080 581 â€“0.246 â€“0.025 582 â€“0.062 â€“0.038 583 â€“0.055 â€“0.062 584 â€“0.004 â€“0.060 585 0.034 0.000 586 â€“0.030 0.021 587 0.075 â€“0.122 588 0.043 â€“0.080 589 â€“0.022 0.041 590 0.026 0.013 591 â€“0.031 â€“0.018 592 0.059 0.008 593 0.109 0.078 594 0.002 0.101 595 â€“0.016 0.054 596 â€“0.059 0.070 597 0.017 0.114 598 0.104 â€“0.034 599 â€“0.024 â€“0.059 600 â€“0.081 0.051 601 â€“0.040 â€“0.069 602 â€“0.069 0.058 603 â€“0.067 0.117 604 0.007 â€“0.131 605 0.009 0.028 606 0.075 0.117 607 0.118 0.030 608 â€“0.041 0.148 609 0.005 0.098 610 0.026 0.002 611 â€“0.116 0.045 612 â€“0.020 0.084 613 0.101 0.006 614 0.205 â€“0.064 615 0.073 â€“0.063 616 â€“0.174 â€“0.118 617 â€“0.024 0.026 618 â€“0.041 0.129 619 â€“0.042 â€“0.053 620 0.148 â€“0.126 621 â€“0.030 â€“0.049 622 â€“0.015 â€“0.021 623 0.089 â€“0.069 624 â€“0.119 0.011 625 â€“0.099 â€“0.048 626 0.054 â€“0.196 627 0.124 0.035 628 0.092 0.045 629 â€“0.037 â€“0.066 630 â€“0.021 â€“0.004 631 0.042 â€“0.065 632 0.061 0.048 633 0.046 0.004 634 â€“0.063 â€“0.045 635 â€“0.102 0.152 636 â€“0.039 â€“0.019 637 â€“0.005 â€“0.106 638 0.083 0.031 639 0.226 0.028 Table I-28â€”Time domain representation of the DATA field: symbol 4 of 6 ## Real Imag ## Real Imag ## Real Imag ## Real Imag 640 0.085 â€“0.065 641 0.034 â€“0.142 642 0.004 â€“0.012 643 0.126 â€“0.043 644 0.055 0.068 645 â€“0.020 0.077 646 0.008 â€“0.056 647 â€“0.034 0.046 648 â€“0.040 â€“0.134 649 â€“0.056 â€“0.131 650 0.014 0.097 651 0.045 â€“0.009 652 â€“0.113 â€“0.170 653 â€“0.065 â€“0.230 654 0.065 â€“0.011 655 0.011 0.048 656 â€“0.091 â€“0.059 657 â€“0.110 0.024 658 0.074 â€“0.034 659 0.124 0.022 660 â€“0.037 0.071 661 0.015 0.002 662 0.028 0.099 663 â€“0.062 0.068 664 0.064 0.016 665 0.078 0.156 666 0.009 0.219 667 0.147 0.024 668 0.106 0.030 669 â€“0.080 0.143 670 â€“0.049 â€“0.100 671 â€“0.036 â€“0.082 672 â€“0.089 0.021 673 â€“0.070 â€“0.029 674 â€“0.086 0.048 675 â€“0.066 â€“0.015 3339 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-28â€”Time domain representation of the DATA field: symbol 4 of 6 (continued) ## Real Imag ## Real Imag ## Real Imag ## Real Imag 676 â€“0.024 0.002 677 â€“0.030 â€“0.023 678 â€“0.032 0.020 679 â€“0.002 0.212 680 0.158 â€“0.024 681 0.141 â€“0.119 682 â€“0.146 0.058 683 â€“0.155 0.083 684 â€“0.002 â€“0.030 685 0.018 â€“0.129 686 0.012 â€“0.018 687 â€“0.008 â€“0.037 688 0.031 0.040 689 0.023 0.097 690 0.014 â€“0.039 691 0.050 0.019 692 â€“0.072 â€“0.141 693 â€“0.023 â€“0.051 694 0.024 0.099 695 â€“0.127 â€“0.116 696 0.094 0.102 697 0.183 0.098 698 â€“0.040 â€“0.020 699 0.065 0.077 700 0.088 â€“0.147 701 â€“0.039 â€“0.059 702 â€“0.057 0.124 703 â€“0.077 0.020 704 0.030 â€“0.120 705 0.034 â€“0.142 706 0.004 â€“0.012 707 0.126 â€“0.043 708 0.055 0.068 709 â€“0.020 0.077 710 0.008 â€“0.056 711 â€“0.034 0.046 712 â€“0.040 â€“0.134 713 â€“0.056 â€“0.131 714 0.014 0.097 715 0.045 â€“0.009 716 â€“0.113 â€“0.170 717 â€“0.065 â€“0.230 718 0.065 â€“0.011 719 0.011 0.048 720 â€“0.026 â€“0.021 721 â€“0.002 0.041 722 0.001 0.071 723 â€“0.037 â€“0.117 Table I-29â€”Time domain representation of the DATA field: symbol 5 of 6 ## Real Imag ## Real Imag ## Real Imag ## Real Imag 724 â€“0.106 â€“0.062 725 0.002 0.057 726 â€“0.008 â€“0.011 727 0.019 0.072 728 0.016 0.059 729 â€“0.065 â€“0.077 730 0.142 â€“0.062 731 0.087 0.025 732 â€“0.003 â€“0.103 733 0.107 â€“0.152 734 â€“0.054 0.036 735 â€“0.030 â€“0.003 736 0.058 â€“0.020 737 â€“0.028 0.007 738 â€“0.027 â€“0.099 739 0.049 â€“0.075 740 0.174 0.031 741 0.134 0.156 742 0.060 0.077 743 â€“0.010 â€“0.022 744 â€“0.084 0.040 745 â€“0.074 0.011 746 â€“0.163 0.054 747 â€“0.052 â€“0.008 748 0.076 â€“0.042 749 0.043 0.101 750 0.058 â€“0.018 751 0.003 â€“0.090 752 0.059 â€“0.018 753 0.023 â€“0.031 754 0.007 â€“0.017 755 0.066 â€“0.017 756 â€“0.135 â€“0.098 757 â€“0.056 â€“0.081 758 0.089 0.154 759 0.120 0.122 760 0.102 0.001 761 â€“0.141 0.102 762 0.006 â€“0.011 763 0.057 â€“0.039 764 â€“0.059 0.066 765 0.132 0.111 766 0.012 0.114 767 0.047 â€“0.106 768 0.160 â€“0.099 769 â€“0.076 0.084 770 â€“0.049 0.073 771 0.005 â€“0.086 772 â€“0.052 â€“0.108 773 â€“0.073 0.129 774 â€“0.129 â€“0.034 775 â€“0.153 â€“0.111 776 â€“0.193 0.098 777 â€“0.107 â€“0.068 778 0.004 â€“0.009 779 â€“0.039 0.024 780 â€“0.054 â€“0.079 781 0.024 0.084 782 0.052 â€“0.002 783 0.028 â€“0.044 3340 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-29â€”Time domain representation of the DATA field: symbol 5 of 6 (continued) ## Real Imag ## Real Imag ## Real Imag ## Real Imag 784 0.040 0.018 785 â€“0.002 0.041 786 0.001 0.071 787 â€“0.037 â€“0.117 788 â€“0.106 â€“0.062 789 0.002 0.057 790 â€“0.008 â€“0.011 791 0.019 0.072 792 0.016 0.059 793 â€“0.065 â€“0.077 794 0.142 â€“0.062 795 0.087 0.025 796 â€“0.003 â€“0.103 797 0.107 â€“0.152 798 â€“0.054 0.036 799 â€“0.030 â€“0.003 Table I-30â€”Time domain representation of the DATA field: symbol 6 of 6 ## Real Imag ## Real Imag ## Real Imag ## Real Imag 800 0.029 â€“0.026 801 â€“0.047 0.077 802 â€“0.007 â€“0.002 803 0.050 â€“0.021 804 0.046 â€“0.040 805 â€“0.061 â€“0.099 806 â€“0.121 0.008 807 0.014 0.050 808 0.145 0.034 809 0.001 â€“0.046 810 â€“0.058 â€“0.121 811 0.040 0.001 812 â€“0.029 0.041 813 0.002 â€“0.066 814 0.015 â€“0.054 815 0.010 â€“0.029 816 0.008 â€“0.119 817 â€“0.134 0.002 818 0.064 0.079 819 0.095 â€“0.102 820 â€“0.069 â€“0.014 821 0.156 0.037 822 0.047 â€“0.008 823 â€“0.076 0.025 824 0.117 â€“0.143 825 0.056 â€“0.042 826 0.002 0.075 827 â€“0.039 â€“0.058 828 â€“0.092 0.014 829 â€“0.041 0.047 830 â€“0.058 0.092 831 0.012 0.154 832 0.079 0.091 833 â€“0.067 0.017 834 â€“0.102 â€“0.032 835 0.039 0.084 836 â€“0.036 0.014 837 â€“0.001 â€“0.046 838 0.195 0.131 839 0.039 0.067 840 â€“0.007 0.045 841 0.051 0.008 842 â€“0.074 â€“0.109 843 â€“0.033 0.070 844 â€“0.028 0.176 845 â€“0.041 0.045 846 0.014 â€“0.084 847 0.054 â€“0.040 848 0.110 â€“0.020 849 0.014 â€“0.021 850 0.006 0.139 851 0.008 0.011 852 â€“0.060 â€“0.040 853 0.008 0.179 854 0.008 0.020 855 0.044 â€“0.114 856 0.021 â€“0.015 857 â€“0.008 â€“0.052 858 0.091 â€“0.109 859 â€“0.025 â€“0.040 860 â€“0.049 0.006 861 â€“0.043 â€“0.041 862 â€“0.178 â€“0.026 863 â€“0.073 â€“0.057 864 0.000 â€“0.031 865 â€“0.047 0.077 866 â€“0.007 â€“0.002 867 0.050 â€“0.021 868 0.046 â€“0.040 869 â€“0.061 â€“0.099 870 â€“0.121 0.008 871 0.014 0.050 872 0.145 0.034 873 0.001 â€“0.046 874 â€“0.058 â€“0.121 875 0.040 0.001 876 â€“0.029 0.041 877 0.002 â€“0.066 878 0.015 â€“0.054 879 0.010 â€“0.029 880 0.004 â€“0.059 3341 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications I.2 Generating encoded DATA bitsâ€”LDPC example 1 LDPC example 1 is similar to the BCC example. This example illustrates LDPC shortening, encoding, and puncturing of a single codeword. Input TXVECTOR parameters for LDPC example 1: â€” FEC_CODING = LDPC_CODING = 1 (LDPC encoder; not BCC) â€” CH_BANDWIDTH = HT_CBW20 = 0 (CH_BANDWIDTH = 0 => 20 MHz) â€” MCS = 4 (MCS = 4; QAM 16; Coding rate = 3/4) â€” Coding rate R = 3/4 â€” LENGTH = 100 octets (with 16-bit SERVICE field becomes 102 Octets = 816 bits to scramble and encode) â€” STBC = 0 (STBC = 0 => OFF; m_STBC=1) I.2.1 The message for LDPC example 1 The message being encoded consists of the first 72 characters (shown in bold and including line breaks) of the well-known â€œOde to Joyâ€ by F. Schiller: Joy, bright spark of divinity, Daughter of Elysium, Fire-insired we tread Thy sanctuary. Thy magic power re-unites All that custom has divided, All men become brothers Under the sway of thy gentle wings. The message is converted to ASCII; then it is prepended with an appropriate MAC header, and an FCS is added. The resulting 100 octet PSDU is shown in Table I-31. NOTE 1â€”The message for LDPC example 1 is identical to the message for the BCC example; in other words, the FCS field (octets 97â€“100) has the same value. NOTE 2â€”The DurationID field (i.e., octets 3 and 4) remains 0x02E = 46 Âµs. Table I-31â€”Message for LDPC example 1 Octet ## Value Value Value Value Value 1...5 0x04 0x02 0x00 0x2E 0x00 6...10 0x60 0x08 0xCD 0x37 0xA6 11...15 0x00 0x20 0xD6 0x01 0x3C 16...20 0xF1 0x00 0x60 0x08 0xAD 21...25 0x3B 0xAF 0x00 0x00 0x4A 26...30 0x6F 0x79 0x2C 0x20 0x62 31...35 0x72 0x69 0x67 0x68 0x74 36...40 0x20 0x73 0x70 0x61 0x72 3342 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-31â€”Message for LDPC example 1 (continued) Octet ## Value Value Value Value Value 41...45 0x6B 0x20 0x6F 0x66 0x20 46...50 0x64 0x69 0x76 0x69 0x6E 51...55 0x69 0x74 0x79 0x2C 0x0A 56...60 0x44 0x61 0x75 0x67 0x68 61...65 0x74 0x65 0x72 0x20 0x6F 66...70 0x66 0x20 0x45 0x6C 0x79 71...75 0x73 0x69 0x75 0x6D 0x2C 76...80 0x0A 0x46 0x69 0x72 0x65 81...85 0x2D 0x69 0x6E 0x73 0x69 86...90 0x72 0x65 0x64 0x20 0x77 91...95 0x65 0x20 0x74 0x72 0x65 96...100 0x61 0x67 0x33 0x21 0xB6 I.2.2 Prepending the SERVICE field for LDPC example 1 The transmitted message shown in Table I-31 contains 100 octets, or equivalently, 800 bits. The bits are prepended by the 16 SERVICE field bits (bits 0â€“15 in Table I-32), as defined in 19.3.11.2, but tail bits and padding bits are not appended as in the BCC example. The resulting 816 bits are shown in Table I-32. Table I-32â€”DATA bits for LDPC example 1 before scrambling Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal Bit ## B7 B0 B15 B8 B23 B16 value value value 000â€“023 00000000 00000000 00000100 0x00 0x00 0x04 024â€“047 00000010 00000000 00101110 0x02 0x00 0x2E 048â€“071 00000000 01100000 00001000 0x00 0x60 0x08 072â€“095 11001101 00110111 10100110 0xCD 0x37 0xA6 096â€“119 00000000 00100000 11010110 0x00 0x20 0xD6 120â€“143 00000001 00111100 11110001 0x01 0x3C 0xF1 144â€“167 00000000 01100000 00001000 0x00 0x60 0x08 168â€“191 10101101 00111011 10101111 0xAD 0x3B 0xAF 192â€“215 00000000 00000000 01001010 0x00 0x00 0x4A 216â€“239 01101111 01111001 00101100 0x6F 0x79 0x2C 240â€“263 00100000 01100010 01110010 0x20 0x62 0x72 264â€“287 01101001 01100111 01101000 0x69 0x67 0x68 3343 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-32â€”DATA bits for LDPC example 1 before scrambling (continued) Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal Bit ## B7 B0 B15 B8 B23 B16 value value value 288â€“311 01110100 00100000 01110011 0x74 0x20 0x73 312â€“335 01110000 01100001 01110010 0x70 0x61 0x72 336â€“359 01101011 00100000 01101111 0x6B 0x20 0x6F 360â€“383 01100110 00100000 01100100 0x66 0x20 0x64 384â€“407 01101001 01110110 01101001 0x69 0x76 0x69 408â€“431 01101110 01101001 01110100 0x6E 0x69 0x74 432â€“455 01111001 00101100 00001010 0x79 0x2C 0x0A 456â€“479 01000100 01100001 01110101 0x44 0x61 0x75 480â€“503 01100111 01101000 01110100 0x67 0x68 0x74 504â€“527 01100101 01110010 00100000 0x65 0x72 0x20 528â€“551 01101111 01100110 00100000 0x6F 0x66 0x20 552â€“575 01000101 01101100 01111001 0x45 0x6C 0x79 576â€“599 01110011 01101001 01110101 0x73 0x69 0x75 600â€“623 01101101 00101100 00001010 0x6D 0x2C 0x0A 624â€“647 01000110 01101001 01110010 0x46 0x69 0x72 648â€“671 01100101 00101101 01101001 0x65 0x2D 0x69 672â€“695 01101110 01110011 01101001 0x6E 0x73 0x69 696â€“719 01110010 01100101 01100100 0x72 0x65 0x64 720â€“743 00100000 01110111 01100101 0x20 0x77 0x65 744â€“767 00100000 01110100 01110010 0x20 0x74 0x72 768â€“791 01100101 01100001 01100111 0x65 0x61 0x67 792â€“815 00110011 00100001 10110110 0x33 0x21 0xB6 3344 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications I.2.3 Scrambling LDPC example 1 The 816 bits are scrambled by the scrambler defined in 17.3.5.5. The initial state of the scrambler is the state 1011101 binary (0x5D). The scrambled sequence is given in Table I-33. NOTEâ€”The scrambled entries for the correct FCS field value are given in bits 784â€“815. Table I-33â€”DATA bits for LDPC example 1 after scrambling Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal Bit ## B0 B7 B8 B15 B16 B23 value value value 000â€“023 01101100 00011001 10001001 0x6C 0x19 0x89 024â€“047 10001111 01101000 00100001 0x8F 0x68 0x21 048â€“071 11110100 10100101 01100001 0xF4 0xA5 0x61 072â€“095 01001111 11010111 10101110 0x4F 0xD7 0xAE 096â€“119 00100100 00001100 11110011 0x24 0x0C 0xF3 120â€“143 00111010 11100100 10111100 0x3A 0xE4 0xBC 144â€“167 01010011 10011000 11000000 0x53 0x98 0xC0 168â€“191 00011110 00110101 10110011 0x1E 0x35 0xB3 192â€“215 11100011 11111000 00100101 0xE3 0xF8 0x25 216â€“239 01100000 11010110 00100101 0x60 0xD6 0x25 240â€“263 00110101 00110011 11111110 0x35 0x33 0xFE 264â€“287 11110000 01000001 00101011 0xF0 0x41 0x2B 288â€“311 10001111 01010011 00011100 0x8F 0x53 0x1C 312â€“335 10000011 01000001 10111110 0x83 0x41 0xBE 336â€“359 00111001 00101000 01100110 0x39 0x28 0x66 360â€“383 01000100 01100110 11001101 0x44 0x66 0xCD 384â€“407 11110110 10100011 11011000 0xF6 0xA3 0xD8 408â€“431 00001101 11010100 10000001 0x0D 0xD4 0x81 432â€“455 00111011 00101111 11011111 0x3B 0x2F 0xDF 456â€“479 11000011 01011000 11110111 0xC3 0x58 0xF7 480â€“503 11000110 01010010 11101011 0xC6 0x52 0xEB 504â€“527 01110000 10001111 10011110 0x70 0x8F 0x9E 528â€“551 01101010 10010000 10000001 0x6A 0x90 0x81 552â€“575 11111101 01111100 10101001 0xFD 0x7C 0xA9 576â€“599 11010001 01010101 00010010 0xD1 0x55 0x12 600â€“623 00000100 01110100 11011001 0x04 0x74 0xD9 624â€“647 11101001 00111011 11001101 0xE9 0x3B 0xCD 648â€“671 10010011 10001101 01111011 0x93 0x8D 0x7B 3345 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-33â€”DATA bits for LDPC example 1 after scrambling (continued) Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal Bit ## B0 B7 B8 B15 B16 B23 value value value 672â€“695 01111100 01110000 00000010 0x7C 0x70 0x02 696â€“719 00100000 10011001 10100001 0x20 0x99 0xA1 720â€“743 01111101 10001010 00100111 0x7D 0x8A 0x27 744â€“767 00010111 00111001 00010101 0x17 0x39 0x15 768â€“791 10100000 11101100 10010101 0xA0 0xEC 0x95 792â€“815 00010110 10010001 00010000 0x16 0x91 0x10 I.2.4 Inserting shortening bits for LDPC example 1 The equations of 19.3.11.7.5 are solved to calculate the following derived parameters for LDPC example 1 from the input TXVECTOR parameters: â€” NCW = 1 (number of codewords) â€” LLDPC = 1944 (size of codeword) â€” NCBPS = 208 (number of coded bits per symbol) â€” Navbits = 1248 (number of available bits) â€” Nshrt = 642 (number of bits to be shortened) â€” Npunc = 54 (number of bits to be punctured) â€” NSYM = 6 (number of OFDM symbols) â€” Nrep = 0 (number of bits to be repeated) The results of applying shortening bits, as prescribed in paragraph (c) of 19.3.11.7.5, is given in Table I-34. NOTEâ€”Nshrt = 642 shortening bits have been inserted as 0s in bits 816â€“1457. Table I-34â€”DATA bits for LDPC example 1 after insertion of shortening bits Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal Bit ## B0 B7 B8 B15 B16 B23 value value value 0000â€“0023 01101100 00011001 10001001 0x6C 0x19 0x89 0024â€“0047 10001111 01101000 00100001 0x8F 0x68 0x21 0048â€“0071 11110100 10100101 01100001 0xF4 0xA5 0x61 0072â€“0095 01001111 11010111 10101110 0x4F 0xD7 0xAE 0096â€“0119 00100100 00001100 11110011 0x24 0x0C 0xF3 0120â€“0143 00111010 11100100 10111100 0x3A 0xE4 0xBC 0144â€“0167 01010011 10011000 11000000 0x53 0x98 0xC0 0168â€“0191 00011110 00110101 10110011 0x1E 0x35 0xB3 0192â€“0215 11100011 11111000 00100101 0xE3 0xF8 0x25 3346 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-34â€”DATA bits for LDPC example 1 after insertion of shortening bits (continued) Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal Bit ## B0 B7 B8 B15 B16 B23 value value value 0216â€“0239 01100000 11010110 00100101 0x60 0xD6 0x25 0240â€“0263 00110101 00110011 11111110 0x35 0x33 0xFE 0264â€“0287 11110000 01000001 00101011 0xF0 0x41 0x2B 0288â€“0311 10001111 01010011 00011100 0x8F 0x53 0x1C 0312â€“0335 10000011 01000001 10111110 0x83 0x41 0xBE 0336â€“0359 00111001 00101000 01100110 0x39 0x28 0x66 0360â€“0383 01000100 01100110 11001101 0x44 0x66 0xCD 0384â€“0407 11110110 10100011 11011000 0xF6 0xA3 0xD8 0408â€“0431 00001101 11010100 10000001 0x0D 0xD4 0x81 0432â€“0455 00111011 00101111 11011111 0x3B 0x2F 0xDF 0456â€“0479 11000011 01011000 11110111 0xC3 0x58 0xF7 0480â€“0503 11000110 01010010 11101011 0xC6 0x52 0xEB 0504â€“0527 01110000 10001111 10011110 0x70 0x8F 0x9E 0528â€“0551 01101010 10010000 10000001 0x6A 0x90 0x81 0552â€“0575 11111101 01111100 10101001 0xFD 0x7C 0xA9 0576â€“0599 11010001 01010101 00010010 0xD1 0x55 0x12 0600â€“0623 00000100 01110100 11011001 0x04 0x74 0xD9 0624â€“0647 11101001 00111011 11001101 0xE9 0x3B 0xCD 0648â€“0671 10010011 10001101 01111011 0x93 0x8D 0x7B 0672â€“0695 01111100 01110000 00000010 0x7C 0x70 0x02 0696â€“0719 00100000 10011001 10100001 0x20 0x99 0xA1 0720â€“0743 01111101 10001010 00100111 0x7D 0x8A 0x27 0744â€“0767 00010111 00111001 00010101 0x17 0x39 0x15 0768â€“0791 10100000 11101100 10010101 0xA0 0xEC 0x95 0792â€“0815 00010110 10010001 00010000 0x16 0x91 0x10 0816â€“0839 00000000 00000000 00000000 0x00 0x00 0x00 0840â€“0863 00000000 00000000 00000000 0x00 0x00 0x00 0864â€“0887 00000000 00000000 00000000 0x00 0x00 0x00 0888â€“0911 00000000 00000000 00000000 0x00 0x00 0x00 0912â€“0935 00000000 00000000 00000000 0x00 0x00 0x00 0936â€“0959 00000000 00000000 00000000 0x00 0x00 0x00 0960â€“0983 00000000 00000000 00000000 0x00 0x00 0x00 3347 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-34â€”DATA bits for LDPC example 1 after insertion of shortening bits (continued) Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal Bit ## B0 B7 B8 B15 B16 B23 value value value 0984â€“1007 00000000 00000000 00000000 0x00 0x00 0x00 1008â€“1031 00000000 00000000 00000000 0x00 0x00 0x00 1032â€“1055 00000000 00000000 00000000 0x00 0x00 0x00 1056â€“1079 00000000 00000000 00000000 0x00 0x00 0x00 1080â€“1103 00000000 00000000 00000000 0x00 0x00 0x00 1104â€“1127 00000000 00000000 00000000 0x00 0x00 0x00 1128â€“1151 00000000 00000000 00000000 0x00 0x00 0x00 1152â€“1175 00000000 00000000 00000000 0x00 0x00 0x00 1176â€“1199 00000000 00000000 00000000 0x00 0x00 0x00 1200â€“1223 00000000 00000000 00000000 0x00 0x00 0x00 1224â€“1247 00000000 00000000 00000000 0x00 0x00 0x00 1248â€“1271 00000000 00000000 00000000 0x00 0x00 0x00 1272â€“1295 00000000 00000000 00000000 0x00 0x00 0x00 1296â€“1319 00000000 00000000 00000000 0x00 0x00 0x00 1320â€“1343 00000000 00000000 00000000 0x00 0x00 0x00 1344â€“1367 00000000 00000000 00000000 0x00 0x00 0x00 1368â€“1391 00000000 00000000 00000000 0x00 0x00 0x00 1392â€“1415 00000000 00000000 00000000 0x00 0x00 0x00 1416â€“1439 00000000 00000000 00000000 0x00 0x00 0x00 1440â€“1457 00000000 00000000 00 - - - - - - 0x00 0x00 0x0- I.2.5 Encoding data for LDPC example 1 The DATA with shortening bits are LDPC encoded as a single (NCW =1) codeword (LLDPC =944; R=3/4) as prescribed by paragraph (c) of 19.3.11.7.5. The results are given in Table I-35. NOTEâ€”The LDPC encoder appends 486 bits (i.e., bits 1458â€“1943) after the shortening bits. Table I-35â€”DATA bits for LDPC example 1 after LDPC encoding Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal Bit ## B0 B7 B8 B15 B16 B23 value value value 0000â€“0023 01101100 00011001 10001001 0x6C 0x19 0x89 0024â€“0047 10001111 01101000 00100001 0x8F 0x68 0x21 0048â€“0071 11110100 10100101 01100001 0xF4 0xA5 0x61 3348 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-35â€”DATA bits for LDPC example 1 after LDPC encoding (continued) Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal Bit ## B0 B7 B8 B15 B16 B23 value value value 0072â€“0095 01001111 11010111 10101110 0x4F 0xD7 0xAE 0096â€“0119 00100100 00001100 11110011 0x24 0x0C 0xF3 0120â€“0143 00111010 11100100 10111100 0x3A 0xE4 0xBC 0144â€“0167 01010011 10011000 11000000 0x53 0x98 0xC0 0168â€“0191 00011110 00110101 10110011 0x1E 0x35 0xB3 0192â€“0215 11100011 11111000 00100101 0xE3 0xF8 0x25 0216â€“0239 01100000 11010110 00100101 0x60 0xD6 0x25 0240â€“0263 00110101 00110011 11111110 0x35 0x33 0xFE 0264â€“0287 11110000 01000001 00101011 0xF0 0x41 0x2B 0288â€“0311 10001111 01010011 00011100 0x8F 0x53 0x1C 0312â€“0335 10000011 01000001 10111110 0x83 0x41 0xBE 0336â€“0359 00111001 00101000 01100110 0x39 0x28 0x66 0360â€“0383 01000100 01100110 11001101 0x44 0x66 0xCD 0384â€“0407 11110110 10100011 11011000 0xF6 0xA3 0xD8 0408â€“0431 00001101 11010100 10000001 0x0D 0xD4 0x81 0432â€“0455 00111011 00101111 11011111 0x3B 0x2F 0xDF 0456â€“0479 11000011 01011000 11110111 0xC3 0x58 0xF7 0480â€“0503 11000110 01010010 11101011 0xC6 0x52 0xEB 0504â€“0527 01110000 10001111 10011110 0x70 0x8F 0x9E 0528â€“0551 01101010 10010000 10000001 0x6A 0x90 0x81 0552â€“0575 11111101 01111100 10101001 0xFD 0x7C 0xA9 0576â€“0599 11010001 01010101 00010010 0xD1 0x55 0x12 0600â€“0623 00000100 01110100 11011001 0x04 0x74 0xD9 0624â€“0647 11101001 00111011 11001101 0xE9 0x3B 0xCD 0648â€“0671 10010011 10001101 01111011 0x93 0x8D 0x7B 0672â€“0695 01111100 01110000 00000010 0x7C 0x70 0x02 0696â€“0719 00100000 10011001 10100001 0x20 0x99 0xA1 0720â€“0743 01111101 10001010 00100111 0x7D 0x8A 0x27 0744â€“0767 00010111 00111001 00010101 0x17 0x39 0x15 0768â€“0791 10100000 11101100 10010101 0xA0 0xEC 0x95 0792â€“0815 00010110 10010001 00010000 0x16 0x91 0x10 0816â€“0839 00000000 00000000 00000000 0x00 0x00 0x00 0840â€“0863 00000000 00000000 00000000 0x00 0x00 0x00 3349 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-35â€”DATA bits for LDPC example 1 after LDPC encoding (continued) Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal Bit ## B0 B7 B8 B15 B16 B23 value value value 0864â€“0887 00000000 00000000 00000000 0x00 0x00 0x00 0888â€“0911 00000000 00000000 00000000 0x00 0x00 0x00 0912â€“0935 00000000 00000000 00000000 0x00 0x00 0x00 0936â€“0959 00000000 00000000 00000000 0x00 0x00 0x00 0960â€“0983 00000000 00000000 00000000 0x00 0x00 0x00 0984â€“1007 00000000 00000000 00000000 0x00 0x00 0x00 1008â€“1031 00000000 00000000 00000000 0x00 0x00 0x00 1032â€“1055 00000000 00000000 00000000 0x00 0x00 0x00 1056â€“1079 00000000 00000000 00000000 0x00 0x00 0x00 1080â€“1103 00000000 00000000 00000000 0x00 0x00 0x00 1104â€“1127 00000000 00000000 00000000 0x00 0x00 0x00 1128â€“1151 00000000 00000000 00000000 0x00 0x00 0x00 1152â€“1175 00000000 00000000 00000000 0x00 0x00 0x00 1176â€“1199 00000000 00000000 00000000 0x00 0x00 0x00 1200â€“1223 00000000 00000000 00000000 0x00 0x00 0x00 1224â€“1247 00000000 00000000 00000000 0x00 0x00 0x00 1248â€“1271 00000000 00000000 00000000 0x00 0x00 0x00 1272â€“1295 00000000 00000000 00000000 0x00 0x00 0x00 1296â€“1319 00000000 00000000 00000000 0x00 0x00 0x00 1320â€“1343 00000000 00000000 00000000 0x00 0x00 0x00 1344â€“1367 00000000 00000000 00000000 0x00 0x00 0x00 1368â€“1391 00000000 00000000 00000000 0x00 0x00 0x00 1392â€“1415 00000000 00000000 00000000 0x00 0x00 0x00 1416â€“1439 00000000 00000000 00000000 0x00 0x00 0x00 1440â€“1463 00000000 00000000 00100110 0x00 0x00 0x26 1464â€“1487 00111101 10101001 10011100 0x3D 0xA9 0x9C 1488â€“1511 01000000 11010111 10110010 0x40 0xD7 0xB2 1512â€“1535 10000110 11100011 10111111 0x86 0xE3 0xBF 1536â€“1559 01000011 10100101 11011001 0x43 0xA5 0xD9 1560â€“1583 00001101 00000110 11010110 0x0D 0x06 0xD6 1584â€“1607 01100000 11110100 00011111 0x60 0xF4 0x1F 1608â€“1631 00110001 00001100 00010011 0x31 0x0C 0x13 1632â€“1655 01110110 00001111 10011111 0x76 0x0F 0x9F 3350 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-35â€”DATA bits for LDPC example 1 after LDPC encoding (continued) Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal Bit ## B0 B7 B8 B15 B16 B23 value value value 1656â€“1679 11011010 10011111 10101001 0xDA 0x9F 0xA9 1680â€“1703 01110100 01011001 11011100 0x74 0x59 0xDC 1704â€“1727 10001001 11110010 11100010 0x89 0xF2 0xE2 1728â€“1751 11011000 01101000 10100001 0xD8 0x68 0xA1 1752â€“1775 01100011 00011101 10100101 0x63 0x1D 0xA5 1776â€“1799 10100110 10000000 11010001 0xA6 0x80 0xD1 1800â€“1823 10001001 01010111 11011100 0x89 0x57 0xDC 1824â€“1847 10110011 01011101 00110011 0xB3 0x5D 0x33 1848â€“1871 01110000 11011100 10110010 0x70 0xDC 0xB2 1872â€“1895 11110110 00111001 00111101 0xF6 0x39 0x3D 1896â€“1919 00100011 10011011 00110110 0x23 0x9B 0x36 1920â€“1943 00111110 00010101 00010001 0x3E 0x15 0x11 I.2.6 Removing shortening bits and puncturing for LDPC example 1 The shortening bits, applied before LDPC encoding, are now removed as prescribed in paragraph (c) of 19.3.11.7.5. Finally, either puncturing is applied as described in paragraph (d) of the same subclause, or the copying of repeated bits is applied as described in paragraph (e) of the same subclause. In LDPC example 1, because Npunc = 54 is nonzero and Nrep = 0, puncturing is prescribed and completes the LDPC encoding process. The results are given in Table I-36. NOTEâ€”The Nshrt = 642 shortening bits have been removed, and the Npunc = 54 bits have been punctured from Table I-35 to produce bits 816â€“1247 of Table I-36. Table I-36â€”DATA bits after puncturing and removal of shortening bits Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal Bit ## B0 B7 B8 B15 B16 B23 value value value 0000â€“0023 01101100 00011001 10001001 0x6C 0x19 0x89 0024â€“0047 10001111 01101000 00100001 0x8F 0x68 0x21 0048â€“0071 11110100 10100101 01100001 0xF4 0xA5 0x61 0072â€“0095 01001111 11010111 10101110 0x4F 0xD7 0xAE 0096â€“0119 00100100 00001100 11110011 0x24 0x0C 0xF3 0120â€“0143 00111010 11100100 10111100 0x3A 0xE4 0xBC 0144â€“0167 01010011 10011000 11000000 0x53 0x98 0xC0 0168â€“0191 00011110 00110101 10110011 0x1E 0x35 0xB3 3351 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-36â€”DATA bits after puncturing and removal of shortening bits (continued) Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal Bit ## B0 B7 B8 B15 B16 B23 value value value 0192â€“0215 11100011 11111000 00100101 0xE3 0xF8 0x25 0216â€“0239 01100000 11010110 00100101 0x60 0xD6 0x25 0240â€“0263 00110101 00110011 11111110 0x35 0x33 0xFE 0264â€“0287 11110000 01000001 00101011 0xF0 0x41 0x2B 0288â€“0311 10001111 01010011 00011100 0x8F 0x53 0x1C 0312â€“0335 10000011 01000001 10111110 0x83 0x41 0xBE 0336â€“0359 00111001 00101000 01100110 0x39 0x28 0x66 0360â€“0383 01000100 01100110 11001101 0x44 0x66 0xCD 0384â€“0407 11110110 10100011 11011000 0xF6 0xA3 0xD8 0408â€“0431 00001101 11010100 10000001 0x0D 0xD4 0x81 0432â€“0455 00111011 00101111 11011111 0x3B 0x2F 0xDF 0456â€“0479 11000011 01011000 11110111 0xC3 0x58 0xF7 0480â€“0503 11000110 01010010 11101011 0xC6 0x52 0xEB 0504â€“0527 01110000 10001111 10011110 0x70 0x8F 0x9E 0528â€“0551 01101010 10010000 10000001 0x6A 0x90 0x81 0552â€“0575 11111101 01111100 10101001 0xFD 0x7C 0xA9 0576â€“0599 11010001 01010101 00010010 0xD1 0x55 0x12 0600â€“0623 00000100 01110100 11011001 0x04 0x74 0xD9 0624â€“0647 11101001 00111011 11001101 0xE9 0x3B 0xCD 0648â€“0671 10010011 10001101 01111011 0x93 0x8D 0x7B 0672â€“0695 01111100 01110000 00000010 0x7C 0x70 0x02 0696â€“0719 00100000 10011001 10100001 0x20 0x99 0xA1 0720â€“0743 01111101 10001010 00100111 0x7D 0x8A 0x27 0744â€“0767 00010111 00111001 00010101 0x17 0x39 0x15 0768â€“0791 10100000 11101100 10010101 0xA0 0xEC 0x95 0792â€“0815 00010110 10010001 00010000 0x16 0x91 0x10 0816â€“0839 10011000 11110110 10100110 0x98 0xF6 0xA6 0840â€“0863 01110001 00000011 01011110 0x71 0x03 0x5E 0864â€“0887 11001010 00011011 10001110 0xCA 0x1B 0x8E 0888â€“0911 11111101 00001110 10010111 0xFD 0x0E 0x97 0912â€“0935 01100100 00110100 00011011 0x64 0x34 0x1B 0936â€“0959 01011001 10000011 11010000 0x59 0x83 0xD0 0960â€“0983 01111100 11000100 00110000 0x7C 0xC4 0x30 3352 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-36â€”DATA bits after puncturing and removal of shortening bits (continued) Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal Bit ## B0 B7 B8 B15 B16 B23 value value value 0984â€“1007 01001101 11011000 00111110 0x4D 0xD8 0x3E 1008â€“1031 01111111 01101010 01111110 0x7F 0x6A 0x7E 1032â€“1055 10100101 11010001 01100111 0xA5 0xD1 0x67 1056â€“1079 01110010 00100111 11001011 0x72 0x27 0xCB 1080â€“1103 10001011 01100001 10100010 0x8B 0x61 0xA2 1104â€“1127 10000101 10001100 01110110 0x85 0x8C 0x76 1128â€“1151 10010110 10011010 00000011 0x96 0x9A 0x03 1152â€“1175 01000110 00100101 01011111 0x46 0x25 0x5F 1176â€“1199 01110010 11001101 01110100 0x72 0xCD 0x74 1200â€“1223 11001101 11000011 01110010 0xCD 0xC3 0x72 1224â€“1247 11001011 11011000 11100100 0xCB 0xD8 0xE4 I.3 Generating encoded DATA bitsâ€”LDPC example 2 LDPC example 2 exercises the alternative branches of the LDPC encoding procedure not exercised in LDPC example 1. Example 2 also exhibits LDPC shortening, encoding, and padding by repetition and employs multiple codewords and diversifies the TXVECTOR parametersâ€”all without making the length of this example cumbersome. The length of the text of the message is increased by 40 octets, from 72 characters to 112 characters, in order to illustrate padding (rather than puncturing) and encoding of multiple codewords. Input TXVECTOR parameters for LDPC example 2: â€” FEC_CODING = LDPC_CODING = 1 (LDPC encoder; not BCC) â€” CH_BANDWIDTH = HT_CBW40 = 1 (CH_BANDWIDTH = 1 => 40 MHz) â€” MCS = 1 (MCS = 1; QPSK; coding rate = 1/2) â€” Coding rate R = 1/2 â€” LENGTH = 140 octets (with 16-bit SERVICE field becomes 142 octets = 1136 bits to scramble and encode) â€” STBC = 1 (STBC = 1 => ON; m_STBC = 2) I.3.1 The message for LDPC example 2 The message being encoded consists of the first 112 characters (shown in bold and including line breaks) of the well-known â€œOde to Joyâ€ by F. Schiller: Joy, bright spark of divinity, Daughter of Elysium, Fire-insired we tread Thy sanctuary. 3353 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Thy magic power re-unites All that custom has divided, All men become brothers Under the sway of thy gentle wings. The message is converted to ASCII; then it is prepended with an appropriate MAC header and an FCS is added. The resulting 140 octet PSDU is shown in Table I-37. Because of the additional 40 characters, note that the message for LDPC example 2 has a different FCS field (octets 137â€“140) than the previous examples and that the DurationID field (i.e., octets 3 and 4) changes to 0x036 = 54 Âµs. Table I-37â€”Message for LDPC example 2 Octet ## Value Value Value Value Value 1...5 0x04 0x02 0x00 0x36 0x00 6...10 0x60 0x08 0xCD 0x37 0xA6 11...15 0x00 0x20 0xD6 0x01 0x3C 16...20 0xF1 0x00 0x60 0x08 0xAD 21...25 0x3B 0xAF 0x00 0x00 0x4A 26...30 0x6F 0x79 0x2C 0x20 0x62 31...35 0x72 0x69 0x67 0x68 0x74 36...40 0x20 0x73 0x70 0x61 0x72 41...45 0x6B 0x20 0x6F 0x66 0x20 46...50 0x64 0x69 0x76 0x69 0x6E 51...55 0x69 0x74 0x79 0x2C 0x0A 56...60 0x44 0x61 0x75 0x67 0x68 61...65 0x74 0x65 0x72 0x20 0x6F 66...70 0x66 0x20 0x45 0x6C 0x79 71...75 0x73 0x69 0x75 0x6D 0x2C 76...80 0x0A 0x46 0x69 0x72 0x65 81...85 0x2D 0x69 0x6E 0x73 0x69 86...90 0x72 0x65 0x64 0x20 0x77 91...95 0x65 0x20 0x74 0x72 0x65 96...100 0x61 0x64 0x0A 0x54 0x68 101...105 0x79 0x20 0x73 0x61 0x6E 106...110 0x63 0x74 0x75 0x61 0x72 111...115 0x79 0x2E 0x0A 0x54 0x68 116...120 0x79 0x20 0x6D 0x61 0x67 121...125 0x69 0x63 0x20 0x70 0x6F 3354 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-37â€”Message for LDPC example 2 (continued) Octet ## Value Value Value Value Value 126...130 0x77 0x65 0x72 0x20 0x72 131...135 0x65 0x2D 0x75 0x6E 0x69 136...140 0x74 0x3B 0xDB 0xB5 0x22 I.3.2 Prepending the SERVICE field for LDPC example 2 The transmitted message shown in Table I-37 contains 140 octets, or equivalently, 1120 bits. The bits are prepended by the 16 SERVICE field bits (bits 0â€“15 in Table I-38), as defined by 19.3.11.2, but tail bits and padding bits are not appended as in the BCC example. The resulting 1136 bits are shown in Table I-38. Table I-38â€”DATA bits for LDPC example 2 before scrambling Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal Bit ## B7 B0 B15 B8 B23 B16 value value value 0000â€“0023 00000000 00000000 00000100 0x00 0x00 0x04 0024â€“0047 00000010 00000000 00110110 0x02 0x00 0x36 0048â€“0071 00000000 01100000 00001000 0x00 0x60 0x08 0072â€“0095 11001101 00110111 10100110 0xCD 0x37 0xA6 0096â€“0119 00000000 00100000 11010110 0x00 0x20 0xD6 0120â€“0143 00000001 00111100 11110001 0x01 0x3C 0xF1 0144â€“0167 00000000 01100000 00001000 0x00 0x60 0x08 0168â€“0191 10101101 00111011 10101111 0xAD 0x3B 0xAF 0192â€“0215 00000000 00000000 01001010 0x00 0x00 0x4A 0216â€“0239 01101111 01111001 00101100 0x6F 0x79 0x2C 0240â€“0263 00100000 01100010 01110010 0x20 0x62 0x72 0264â€“0287 01101001 01100111 01101000 0x69 0x67 0x68 0288â€“0311 01110100 00100000 01110011 0x74 0x20 0x73 0312â€“0335 01110000 01100001 01110010 0x70 0x61 0x72 0336â€“0359 01101011 00100000 01101111 0x6B 0x20 0x6F 0360â€“0383 01100110 00100000 01100100 0x66 0x20 0x64 0384â€“0407 01101001 01110110 01101001 0x69 0x76 0x69 0408â€“0431 01101110 01101001 01110100 0x6E 0x69 0x74 0432â€“0455 01111001 00101100 00001010 0x79 0x2C 0x0A 0456â€“0479 01000100 01100001 01110101 0x44 0x61 0x75 0480â€“0503 01100111 01101000 01110100 0x67 0x68 0x74 3355 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-38â€”DATA bits for LDPC example 2 before scrambling Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal Bit ## B7 B0 B15 B8 B23 B16 value value value 0504â€“0527 01100101 01110010 00100000 0x65 0x72 0x20 0528â€“0551 01101111 01100110 00100000 0x6F 0x66 0x20 0552â€“0575 01000101 01101100 01111001 0x45 0x6C 0x79 0576â€“0599 01110011 01101001 01110101 0x73 0x69 0x75 0600â€“0623 01101101 00101100 00001010 0x6D 0x2C 0x0A 0624â€“0647 01000110 01101001 01110010 0x46 0x69 0x72 0648â€“0671 01100101 00101101 01101001 0x65 0x2D 0x69 0672â€“0695 01101110 01110011 01101001 0x6E 0x73 0x69 0696â€“0719 01110010 01100101 01100100 0x72 0x65 0x64 0720â€“0743 00100000 01110111 01100101 0x20 0x77 0x65 0744â€“0767 00100000 01110100 01110010 0x20 0x74 0x72 0768â€“0791 01100101 01100001 01100100 0x65 0x61 0x64 0792â€“0815 00001010 01010100 01101000 0x0A 0x54 0x68 0816â€“0839 01111001 00100000 01110011 0x79 0x20 0x73 0840â€“0863 01100001 01101110 01100011 0x61 0x6E 0x63 0864â€“0887 01110100 01110101 01100001 0x74 0x75 0x61 0888â€“0911 01110010 01111001 00101110 0x72 0x79 0x2E 0912â€“0935 00001010 01010100 01101000 0x0A 0x54 0x68 0936â€“0959 01111001 00100000 01101101 0x79 0x20 0x6D 0960â€“0983 01100001 01100111 01101001 0x61 0x67 0x69 0984â€“1007 01100011 00100000 01110000 0x63 0x20 0x70 1008â€“1031 01101111 01110111 01100101 0x6F 0x77 0x65 1032â€“1055 01110010 00100000 01110010 0x72 0x20 0x72 1056â€“1079 01100101 00101101 01110101 0x65 0x2D 0x75 1080â€“1103 01101110 01101001 01110100 0x6E 0x69 0x74 1104â€“1127 00111011 11011011 10110101 0x3B 0xDB 0xB5 1128â€“1135 00100010 -------- -------- 0x22 ---- ---- 3356 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications I.3.3 Scrambling LDPC example 2 The 1136 bits are scrambled by the scrambler defined in 17.3.5.5. The initial state of the scrambler is the state 1011101 binary (0x5D). The scrambled sequence is given in Table I-39. Table I-39â€”DATA bits for LDPC example 2 after scrambling Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal Bit ## B0 B7 B8 B15 B16 B23 value value value 0000â€“0023 01101100 00011001 10001001 0x6C 0x19 0x89 0024â€“0047 10001111 01101000 00111001 0x8F 0x68 0x39 0048â€“0071 11110100 10100101 01100001 0xF4 0xA5 0x61 0072â€“0095 01001111 11010111 10101110 0x4F 0xD7 0xAE 0096â€“0119 00100100 00001100 11110011 0x24 0x0C 0xF3 0120â€“0143 00111010 11100100 10111100 0x3A 0xE4 0xBC 0144â€“0167 01010011 10011000 11000000 0x53 0x98 0xC0 0168â€“0191 00011110 00110101 10110011 0x1E 0x35 0xB3 0192â€“0215 11100011 11111000 00100101 0xE3 0xF8 0x25 0216â€“0239 01100000 11010110 00100101 0x60 0xD6 0x25 0240â€“0263 00110101 00110011 11111110 0x35 0x33 0xFE 0264â€“0287 11110000 01000001 00101011 0xF0 0x41 0x2B 0288â€“0311 10001111 01010011 00011100 0x8F 0x53 0x1C 0312â€“0335 10000011 01000001 10111110 0x83 0x41 0xBE 0336â€“0359 00111001 00101000 01100110 0x39 0x28 0x66 0360â€“0383 01000100 01100110 11001101 0x44 0x66 0xCD 0384â€“0407 11110110 10100011 11011000 0xF6 0xA3 0xD8 0408â€“0431 00001101 11010100 10000001 0x0D 0xD4 0x81 0432â€“0455 00111011 00101111 11011111 0x3B 0x2F 0xDF 0456â€“0479 11000011 01011000 11110111 0xC3 0x58 0xF7 0480â€“0503 11000110 01010010 11101011 0xC6 0x52 0xEB 0504â€“0527 01110000 10001111 10011110 0x70 0x8F 0x9E 0528â€“0551 01101010 10010000 10000001 0x6A 0x90 0x81 0552â€“0575 11111101 01111100 10101001 0xFD 0x7C 0xA9 0576â€“0599 11010001 01010101 00010010 0xD1 0x55 0x12 0600â€“0623 00000100 01110100 11011001 0x04 0x74 0xD9 0624â€“0647 11101001 00111011 11001101 0xE9 0x3B 0xCD 0648â€“0671 10010011 10001101 01111011 0x93 0x8D 0x7B 0672â€“0695 01111100 01110000 00000010 0x7C 0x70 0x02 3357 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-39â€”DATA bits for LDPC example 2 after scrambling Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal Bit ## B0 B7 B8 B15 B16 B23 value value value 0696â€“0719 00100000 10011001 10100001 0x20 0x99 0xA1 0720â€“0743 01111101 10001010 00100111 0x7D 0x8A 0x27 0744â€“0767 00010111 00111001 00010101 0x17 0x39 0x15 0768â€“0791 10100000 11101100 01010101 0xA0 0xEC 0x55 0792â€“0815 10001010 00111111 01101011 0x8A 0x3F 0x6B 0816â€“0839 10110110 11011000 10110001 0xB6 0xD8 0xB1 0840â€“0863 10001000 10000100 00001111 0x88 0x84 0x0F 0864â€“0887 00101100 10001000 10101000 0x2C 0x88 0xA8 0888â€“0911 11111000 10010010 10100000 0xF8 0x92 0xA0 0912â€“0935 10110111 10011110 00111100 0xB7 0x9E 0x3C 0936â€“0959 01100100 01010101 00001110 0x64 0x55 0x0E 0960â€“0983 01111000 11111011 01110011 0x78 0xFB 0x73 0984â€“1007 01010100 00000000 01000010 0x54 0x00 0x42 1008â€“1031 10101011 10000010 10111111 0xAB 0x82 0xBF 1032â€“1055 11100111 11001011 00100110 0xE7 0xCB 0x26 1056â€“1079 11110011 01000000 00001101 0xF3 0x40 0x0D 1080â€“1103 00000111 01101010 00010101 0x07 0x6A 0x15 1104â€“1127 00010111 11111111 10100101 0x17 0xFF 0xA5 1128â€“1135 11011100 -------- -------- 0xDC ---- ---- I.3.4 Inserting the shortening bits for LDPC example 2 The equations of 19.3.11.7.5 are solved to calculate the following derived parameters for LDPC example 2 from the input TXVECTOR parameters: â€” NCW = 2 (number of codewords) â€” LLDPC = 1296 (size of codeword) â€” NCBPS = 216 (number of coded bits per symbol) â€” Navbits = 2592 (number of available bits) â€” Nshrt = 160 (number of bits to be shortened) â€” Npunc = 0 (number of bits to be punctured) â€” NSYM = 12 (number of OFDM symbols) â€” Nrep = 160 (number of bits to be repeated) 3358 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The results of applying shortening bits, as prescribed in paragraph (c) of 19.3.11.7.5, is given in Table I-40. NOTEâ€”Nshrt = 160 shortening bits have been inserted as 0s: 80 0s at bits 568â€“647 and 80 0s at bits 1216â€“1295; this order equally distributes the shortening bits across the NCW = 2 codewords. Table I-40â€”DATA bits for LDPC example 2 after insertion of shortening bits Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal Bit ## B0 B7 B8 B15 B16 B23 value value value 0000â€“0023 01101100 00011001 10001001 0x6C 0x19 0x89 0024â€“0047 10001111 01101000 00111001 0x8F 0x68 0x39 0048â€“0071 11110100 10100101 01100001 0xF4 0xA5 0x61 0072â€“0095 01001111 11010111 10101110 0x4F 0xD7 0xAE 0096â€“0119 00100100 00001100 11110011 0x24 0x0C 0xF3 0120â€“0143 00111010 11100100 10111100 0x3A 0xE4 0xBC 0144â€“0167 01010011 10011000 11000000 0x53 0x98 0xC0 0168â€“0191 00011110 00110101 10110011 0x1E 0x35 0xB3 0192â€“0215 11100011 11111000 00100101 0xE3 0xF8 0x25 0216â€“0239 01100000 11010110 00100101 0x60 0xD6 0x25 0240â€“0263 00110101 00110011 11111110 0x35 0x33 0xFE 0264â€“0287 11110000 01000001 00101011 0xF0 0x41 0x2B 0288â€“0311 10001111 01010011 00011100 0x8F 0x53 0x1C 0312â€“0335 10000011 01000001 10111110 0x83 0x41 0xBE 0336â€“0359 00111001 00101000 01100110 0x39 0x28 0x66 0360â€“0383 01000100 01100110 11001101 0x44 0x66 0xCD 0384â€“0407 11110110 10100011 11011000 0xF6 0xA3 0xD8 0408â€“0431 00001101 11010100 10000001 0x0D 0xD4 0x81 0432â€“0455 00111011 00101111 11011111 0x3B 0x2F 0xDF 0456â€“0479 11000011 01011000 11110111 0xC3 0x58 0xF7 0480â€“0503 11000110 01010010 11101011 0xC6 0x52 0xEB 0504â€“0527 01110000 10001111 10011110 0x70 0x8F 0x9E 0528â€“0551 01101010 10010000 10000001 0x6A 0x90 0x81 0552â€“0575 11111101 01111100 00000000 0xFD 0x7C 0x00 0576â€“0599 00000000 00000000 00000000 0x00 0x00 0x00 0600â€“0623 00000000 00000000 00000000 0x00 0x00 0x00 0624â€“0647 00000000 00000000 00000000 0x00 0x00 0x00 0648â€“0671 10101001 11010001 01010101 0xA9 0xD1 0x55 0672â€“0695 00010010 00000100 01110100 0x12 0x04 0x74 3359 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-40â€”DATA bits for LDPC example 2 after insertion of shortening bits (continued) Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal Bit ## B0 B7 B8 B15 B16 B23 value value value 0696â€“0719 11011001 11101001 00111011 0xD9 0xE9 0x3B 0720â€“0743 11001101 10010011 10001101 0xCD 0x93 0x8D 0744â€“0767 01111011 01111100 01110000 0x7B 0x7C 0x70 0768â€“0791 00000010 00100000 10011001 0x02 0x20 0x99 0792â€“0815 10100001 01111101 10001010 0xA1 0x7D 0x8A 0816â€“0839 00100111 00010111 00111001 0x27 0x17 0x39 0840â€“0863 00010101 10100000 11101100 0x15 0xA0 0xEC 0864â€“0887 01010101 10001010 00111111 0x55 0x8A 0x3F 0888â€“0911 01101011 10110110 11011000 0x6B 0xB6 0xD8 0912â€“0935 10110001 10001000 10000100 0xB1 0x88 0x84 0936â€“0959 00001111 00101100 10001000 0x0F 0x2C 0x88 0960â€“0983 10101000 11111000 10010010 0xA8 0xF8 0x92 0984â€“1007 10100000 10110111 10011110 0xA0 0xB7 0x9E 1008â€“1031 00111100 01100100 01010101 0x3C 0x64 0x55 1032â€“1055 00001110 01111000 11111011 0x0E 0x78 0xFB 1056â€“1079 01110011 01010100 00000000 0x73 0x54 0x00 1080â€“1103 01000010 10101011 10000010 0x42 0xAB 0x82 1104â€“1127 10111111 11100111 11001011 0xBF 0xE7 0xCB 1128â€“1151 00100110 11110011 01000000 0x26 0xF3 0x40 1152â€“1175 00001101 00000111 01101010 0x0D 0x07 0x6A 1176â€“1199 00010101 00010111 11111111 0x15 0x17 0xFF 1200â€“1223 10100101 11011100 00000000 0xA5 0xDC 0x00 1224â€“1247 00000000 00000000 00000000 0x00 0x00 0x00 1248â€“1271 00000000 00000000 00000000 0x00 0x00 0x00 1272â€“1295 00000000 00000000 00000000 0x00 0x00 0x00 I.3.5 Encoding the data for LDPC example 2 The DATA with shortening bits are LDPC encoded as two (NCW = 2) codewords (LLDPC = 1296; R = 1/2) as prescribed by paragraph (c) of 19.3.11.7.5. The results are given in Table I-41. NOTEâ€”The LDPC encoder appends 648 bits as follows: bits 648â€“1295 after the first shortened codeword and another 648 bits (bits 1944â€“2591) after the second shortened codeword. 3360 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-41â€”DATA bits for LDPC example 2 after LDPC encoding Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal Bit ## B0 B7 B8 B15 B16 B23 value value value 0000â€“0023 01101100 00011001 10001001 0x6C 0x19 0x89 0024â€“0047 10001111 01101000 00111001 0x8F 0x68 0x39 0048â€“0071 11110100 10100101 01100001 0xF4 0xA5 0x61 0072â€“0095 01001111 11010111 10101110 0x4F 0xD7 0xAE 0096â€“0119 00100100 00001100 11110011 0x24 0x0C 0xF3 0120â€“0143 00111010 11100100 10111100 0x3A 0xE4 0xBC 0144â€“0167 01010011 10011000 11000000 0x53 0x98 0xC0 0168â€“0191 00011110 00110101 10110011 0x1E 0x35 0xB3 0192â€“0215 11100011 11111000 00100101 0xE3 0xF8 0x25 0216â€“0239 01100000 11010110 00100101 0x60 0xD6 0x25 0240â€“0263 00110101 00110011 11111110 0x35 0x33 0xFE 0264â€“0287 11110000 01000001 00101011 0xF0 0x41 0x2B 0288â€“0311 10001111 01010011 00011100 0x8F 0x53 0x1C 0312â€“0335 10000011 01000001 10111110 0x83 0x41 0xBE 0336â€“0359 00111001 00101000 01100110 0x39 0x28 0x66 0360â€“0383 01000100 01100110 11001101 0x44 0x66 0xCD 0384â€“0407 11110110 10100011 11011000 0xF6 0xA3 0xD8 0408â€“0431 00001101 11010100 10000001 0x0D 0xD4 0x81 0432â€“0455 00111011 00101111 11011111 0x3B 0x2F 0xDF 0456â€“0479 11000011 01011000 11110111 0xC3 0x58 0xF7 0480â€“0503 11000110 01010010 11101011 0xC6 0x52 0xEB 0504â€“0527 01110000 10001111 10011110 0x70 0x8F 0x9E 0528â€“0551 01101010 10010000 10000001 0x6A 0x90 0x81 0552â€“0575 11111101 01111100 00000000 0xFD 0x7C 0x00 0576â€“0599 00000000 00000000 00000000 0x00 0x00 0x00 0600â€“0623 00000000 00000000 00000000 0x00 0x00 0x00 0624â€“0647 00000000 00000000 00000000 0x00 0x00 0x00 0648â€“0671 00001001 11000001 11111011 0x09 0xC1 0xFB 0672â€“0695 01101000 11001101 00000101 0x68 0xCD 0x05 0696â€“0719 10110110 11000111 01100101 0xB6 0xC7 0x65 0720â€“0743 10100101 10011001 11100000 0xA5 0x99 0xE0 0744â€“0767 01110011 01110000 01101101 0x73 0x70 0x6D 0768â€“0791 01011110 01111001 11100011 0x5E 0x79 0xE3 3361 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-41â€”DATA bits for LDPC example 2 after LDPC encoding (continued) Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal Bit ## B0 B7 B8 B15 B16 B23 value value value 0792â€“0815 01100111 00100111 01011110 0x67 0x27 0x5E 0816â€“0839 10010101 10101000 11110110 0x95 0xA8 0xF6 0840â€“0863 00110101 01001000 10100111 0x35 0x48 0xA7 0864â€“0887 00100110 00101001 00110001 0x26 0x29 0x31 0888â€“0911 00101110 00011001 11110100 0x2E 0x19 0xF4 0912â€“0935 00110100 01101111 01010000 0x34 0x6F 0x50 0936â€“0959 01010000 11101001 11000100 0x50 0xE9 0xC4 0960â€“0983 00000110 11011001 11101110 0x06 0xD9 0xEE 0984â€“1007 11111000 00011011 11011001 0xF8 0x1B 0xD9 1008â€“1031 01101100 10000110 11010011 0x6C 0x86 0xD3 1032â€“1055 11101001 01100100 11001000 0xE9 0x64 0xC8 1056â€“1079 11110001 10100001 00001011 0xF1 0xA1 0x0B 1080â€“1103 11000010 01000100 01010100 0xC2 0x44 0x54 1104â€“1127 10100000 10001100 10111011 0xA0 0x8C 0xBB 1128â€“1151 10100011 11100100 10101001 0xA3 0xE4 0xA9 1152â€“1175 10101011 01010000 11100010 0xAB 0x50 0xE2 1176â€“1199 01110000 00101000 00110110 0x70 0x28 0x36 1200â€“1223 11111100 00110000 00110100 0xFC 0x30 0x34 1224â€“1247 01101010 01001001 00100010 0x6A 0x49 0x22 1248â€“1271 11010101 00000111 11001111 0xD5 0x07 0xCF 1272â€“1295 00110101 00111010 10001110 0x35 0x3A 0x8E 1296â€“1319 10101001 11010001 01010101 0xA9 0xD1 0x55 1320â€“1343 00010010 00000100 01110100 0x12 0x04 0x74 1344â€“1367 11011001 11101001 00111011 0xD9 0xE9 0x3B 1368â€“1391 11001101 10010011 10001101 0xCD 0x93 0x8D 1392â€“1415 01111011 01111100 01110000 0x7B 0x7C 0x70 1416â€“1439 00000010 00100000 10011001 0x02 0x20 0x99 1440â€“1463 10100001 01111101 10001010 0xA1 0x7D 0x8A 1464â€“1487 00100111 00010111 00111001 0x27 0x17 0x39 1488â€“1511 00010101 10100000 11101100 0x15 0xA0 0xEC 1512â€“1535 01010101 10001010 00111111 0x55 0x8A 0x3F 1536â€“1559 01101011 10110110 11011000 0x6B 0xB6 0xD8 1560â€“1583 10110001 10001000 10000100 0xB1 0x88 0x84 3362 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-41â€”DATA bits for LDPC example 2 after LDPC encoding (continued) Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal Bit ## B0 B7 B8 B15 B16 B23 value value value 1584â€“1607 00001111 00101100 10001000 0x0F 0x2C 0x88 1608â€“1631 10101000 11111000 10010010 0xA8 0xF8 0x92 1632â€“1655 10100000 10110111 10011110 0xA0 0xB7 0x9E 1656â€“1679 00111100 01100100 01010101 0x3C 0x64 0x55 1680â€“1703 00001110 01111000 11111011 0x0E 0x78 0xFB 1704â€“1727 01110011 01010100 00000000 0x73 0x54 0x00 1728â€“1751 01000010 10101011 10000010 0x42 0xAB 0x82 1752â€“1775 10111111 11100111 11001011 0xBF 0xE7 0xCB 1776â€“1799 00100110 11110011 01000000 0x26 0xF3 0x40 1800â€“1823 00001101 00000111 01101010 0x0D 0x07 0x6A 1824â€“1847 00010101 00010111 11111111 0x15 0x17 0xFF 1848â€“1871 10100101 11011100 00000000 0xA5 0xDC 0x00 1872â€“1895 00000000 00000000 00000000 0x00 0x00 0x00 1896â€“1919 00000000 00000000 00000000 0x00 0x00 0x00 1920â€“1943 00000000 00000000 00000000 0x00 0x00 0x00 1944â€“1967 01100100 10110110 01010100 0x64 0xB6 0x54 1968â€“1991 00110001 00000001 01100001 0x31 0x01 0x61 1992â€“2015 00101001 00010011 01110000 0x29 0x13 0x70 2016â€“2039 01010000 10000000 11001110 0x50 0x80 0xCE 2040â€“2063 01000101 11000000 10101000 0x45 0xC0 0xA8 2064â€“2087 11001101 11111000 01111100 0xCD 0xF8 0x7C 2088â€“2111 01010011 01010001 01001110 0x53 0x51 0x4E 2112â€“2135 11010011 10101110 00010011 0xD3 0xAE 0x13 2136â€“2159 11110000 11101101 10111111 0xF0 0xED 0xBF 2160â€“2183 10001110 10010100 00110100 0x8E 0x94 0x34 2184â€“2207 11111011 00010000 11011001 0xFB 0x10 0xD9 2208â€“2231 10111110 00110001 10011111 0xBE 0x31 0x9F 2232â€“2255 01100000 00011100 10100110 0x60 0x1C 0xA6 2256â€“2279 01010101 11111001 10100110 0x55 0xF9 0xA6 2280â€“2303 10101010 00111000 01110001 0xAA 0x38 0x71 2304â€“2327 01111010 10101100 10110010 0x7A 0xAC 0xB2 2328â€“2351 11110101 11010001 10000001 0xF5 0xD1 0x81 2352â€“2375 01010000 11110001 00001011 0x50 0xF1 0x0B 3363 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-41â€”DATA bits for LDPC example 2 after LDPC encoding (continued) Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal Bit ## B0 B7 B8 B15 B16 B23 value value value 2376â€“2399 10111101 10010011 10001011 0xBD 0x93 0x8B 2400â€“2423 10100010 10010110 00100101 0xA2 0x96 0x25 2424â€“2447 11100011 01101100 11000111 0xE3 0x6C 0xC7 2448â€“2471 00000101 00011000 00101000 0x05 0x18 0x28 2472â€“2495 11110011 00111001 11011000 0xF3 0x39 0xD8 2496â€“2519 00010001 01110101 00010111 0x11 0x75 0x17 2520â€“2543 11011101 11111011 11010010 0xDD 0xFB 0xD2 2544â€“2567 10101010 11101011 10100110 0xAA 0xEB 0xA6 2568â€“2591 10000101 10110011 01011000 0x85 0xB3 0x58 I.3.6 Removing shortening bits and repetition for LDPC example 2 The shortening bits, applied before LDPC encoding, are now removed as prescribed in paragraph (c) of 19.3.11.7.5. Finally, either puncturing is applied as described in paragraph (d) of the same subclause, or the copying of repeated bits is applied as described in paragraph (e) of the same subclause. In LDPC example 2, because Npunc = 0 and Nrep = 160 are nonzero, repetition is prescribed and completes the LDPC encoding process. The results are given in Table I-42. NOTEâ€”The first 80 shortening bits (bits 568â€“647 from Table I-41) have been removed from the first codeword between bits 567 and 568 of Table I-42, and the second 80 shortening bits (bits 1864â€“1943 of Table I-41) have been removed between bits 1215 and 1216 of Table I-42. Also, 80 bits have been repeated from the beginning of the first codeword (bits 0â€“79) to the end of the first codeword (bits 1216â€“1295), and 80 bits have been repeated from the beginning of the second codeword (bits 1296â€“1375) to end of the second codeword (bits 2512â€“2591) in Table I-42. Table I-42â€”DATA bits after removal of shortening bits and copying of repetition bits Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal Bit ## B0 B7 B8 B15 B16 B23 value value value 0000â€“0023 01101100 00011001 10001001 0x6C 0x19 0x89 0024â€“0047 10001111 01101000 00111001 0x8F 0x68 0x39 0048â€“0071 11110100 10100101 01100001 0xF4 0xA5 0x61 0072â€“0095 01001111 11010111 10101110 0x4F 0xD7 0xAE 0096â€“0119 00100100 00001100 11110011 0x24 0x0C 0xF3 0120â€“0143 00111010 11100100 10111100 0x3A 0xE4 0xBC 0144â€“0167 01010011 10011000 11000000 0x53 0x98 0xC0 0168â€“0191 00011110 00110101 10110011 0x1E 0x35 0xB3 3364 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-42â€”DATA bits after removal of shortening bits and copying of repetition bits (continued) Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal Bit ## B0 B7 B8 B15 B16 B23 value value value 0192â€“0215 11100011 11111000 00100101 0xE3 0xF8 0x25 0216â€“0239 01100000 11010110 00100101 0x60 0xD6 0x25 0240â€“0263 00110101 00110011 11111110 0x35 0x33 0xFE 0264â€“0287 11110000 01000001 00101011 0xF0 0x41 0x2B 0288â€“0311 10001111 01010011 00011100 0x8F 0x53 0x1C 0312â€“0335 10000011 01000001 10111110 0x83 0x41 0xBE 0336â€“0359 00111001 00101000 01100110 0x39 0x28 0x66 0360â€“0383 01000100 01100110 11001101 0x44 0x66 0xCD 0384â€“0407 11110110 10100011 11011000 0xF6 0xA3 0xD8 0408â€“0431 00001101 11010100 10000001 0x0D 0xD4 0x81 0432â€“0455 00111011 00101111 11011111 0x3B 0x2F 0xDF 0456â€“0479 11000011 01011000 11110111 0xC3 0x58 0xF7 0480â€“0503 11000110 01010010 11101011 0xC6 0x52 0xEB 0504â€“0527 01110000 10001111 10011110 0x70 0x8F 0x9E 0528â€“0551 01101010 10010000 10000001 0x6A 0x90 0x81 0552â€“0575 11111101 01111100 00001001 0xFD 0x7C 0x09 0576â€“0599 11000001 11111011 01101000 0xC1 0xFB 0x68 0600â€“0623 11001101 00000101 10110110 0xCD 0x05 0xB6 0624â€“0647 11000111 01100101 10100101 0xC7 0x65 0xA5 0648â€“0671 10011001 11100000 01110011 0x99 0xE0 0x73 0672â€“0695 01110000 01101101 01011110 0x70 0x6D 0x5E 0696â€“0719 01111001 11100011 01100111 0x79 0xE3 0x67 0720â€“0743 00100111 01011110 10010101 0x27 0x5E 0x95 0744â€“0767 10101000 11110110 00110101 0xA8 0xF6 0x35 0768â€“0791 01001000 10100111 00100110 0x48 0xA7 0x26 0792â€“0815 00101001 00110001 00101110 0x29 0x31 0x2E 0816â€“0839 00011001 11110100 00110100 0x19 0xF4 0x34 0840â€“0863 01101111 01010000 01010000 0x6F 0x50 0x50 0864â€“0887 11101001 11000100 00000110 0xE9 0xC4 0x06 0888â€“0911 11011001 11101110 11111000 0xD9 0xEE 0xF8 0912â€“0935 00011011 11011001 01101100 0x1B 0xD9 0x6C 0936â€“0959 10000110 11010011 11101001 0x86 0xD3 0xE9 3365 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-42â€”DATA bits after removal of shortening bits and copying of repetition bits (continued) Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal Bit ## B0 B7 B8 B15 B16 B23 value value value 0960â€“0983 01100100 11001000 11110001 0x64 0xC8 0xF1 0984â€“1007 10100001 00001011 11000010 0xA1 0x0B 0xC2 1008â€“1031 01000100 01010100 10100000 0x44 0x54 0xA0 1032â€“1055 10001100 10111011 10100011 0x8C 0xBB 0xA3 1056â€“1079 11100100 10101001 10101011 0xE4 0xA9 0xAB 1080â€“1103 01010000 11100010 01110000 0x50 0xE2 0x70 1104â€“1127 00101000 00110110 11111100 0x28 0x36 0xFC 1128â€“1151 00110000 00110100 01101010 0x30 0x34 0x6A 1152â€“1175 01001001 00100010 11010101 0x49 0x22 0xD5 1176â€“1199 00000111 11001111 00110101 0x07 0xCF 0x35 1200â€“1223 00111010 10001110 01101100 0x3A 0x8E 0x6C 1224â€“1247 00011001 10001001 10001111 0x19 0x89 0x8F 1248â€“1271 01101000 00111001 11110100 0x68 0x39 0xF4 1272â€“1295 10100101 01100001 01001111 0xA5 0x61 0x4F 1296â€“1319 10101001 11010001 01010101 0xA9 0xD1 0x55 1320â€“1343 00010010 00000100 01110100 0x12 0x04 0x74 1344â€“1367 11011001 11101001 00111011 0xD9 0xE9 0x3B 1368â€“1391 11001101 10010011 10001101 0xCD 0x93 0x8D 1392â€“1415 01111011 01111100 01110000 0x7B 0x7C 0x70 1416â€“1439 00000010 00100000 10011001 0x02 0x20 0x99 1440â€“1463 10100001 01111101 10001010 0xA1 0x7D 0x8A 1464â€“1487 00100111 00010111 00111001 0x27 0x17 0x39 1488â€“1511 00010101 10100000 11101100 0x15 0xA0 0xEC 1512â€“1535 01010101 10001010 00111111 0x55 0x8A 0x3F 1536â€“1559 01101011 10110110 11011000 0x6B 0xB6 0xD8 1560â€“1583 10110001 10001000 10000100 0xB1 0x88 0x84 1584â€“1607 00001111 00101100 10001000 0x0F 0x2C 0x88 1608â€“1631 10101000 11111000 10010010 0xA8 0xF8 0x92 1632â€“1655 10100000 10110111 10011110 0xA0 0xB7 0x9E 1656â€“1679 00111100 01100100 01010101 0x3C 0x64 0x55 1680â€“1703 00001110 01111000 11111011 0x0E 0x78 0xFB 1704â€“1727 01110011 01010100 00000000 0x73 0x54 0x00 3366 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-42â€”DATA bits after removal of shortening bits and copying of repetition bits (continued) Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal Bit ## B0 B7 B8 B15 B16 B23 value value value 1728â€“1751 01000010 10101011 10000010 0x42 0xAB 0x82 1752â€“1775 10111111 11100111 11001011 0xBF 0xE7 0xCB 1776â€“1799 00100110 11110011 01000000 0x26 0xF3 0x40 1800â€“1823 00001101 00000111 01101010 0x0D 0x07 0x6A 1824â€“1847 00010101 00010111 11111111 0x15 0x17 0xFF 1848â€“1871 10100101 11011100 01100100 0xA5 0xDC 0x64 1872â€“1895 10110110 01010100 00110001 0xB6 0x54 0x31 1896â€“1919 00000001 01100001 00101001 0x01 0x61 0x29 1920â€“1943 00010011 01110000 01010000 0x13 0x70 0x50 1944â€“1967 10000000 11001110 01000101 0x80 0xCE 0x45 1968â€“1991 11000000 10101000 11001101 0xC0 0xA8 0xCD 1992â€“2015 11111000 01111100 01010011 0xF8 0x7C 0x53 2016â€“2039 01010001 01001110 11010011 0x51 0x4E 0xD3 2040â€“2063 10101110 00010011 11110000 0xAE 0x13 0xF0 2064â€“2087 11101101 10111111 10001110 0xED 0xBF 0x8E 2088â€“2111 10010100 00110100 11111011 0x94 0x34 0xFB 2112â€“2135 00010000 11011001 10111110 0x10 0xD9 0xBE 2136â€“2159 00110001 10011111 01100000 0x31 0x9F 0x60 2160â€“2183 00011100 10100110 01010101 0x1C 0xA6 0x55 2184â€“2207 11111001 10100110 10101010 0xF9 0xA6 0xAA 2208â€“2231 00111000 01110001 01111010 0x38 0x71 0x7A 2232â€“2255 10101100 10110010 11110101 0xAC 0xB2 0xF5 2256â€“2279 11010001 10000001 01010000 0xD1 0x81 0x50 2280â€“2303 11110001 00001011 10111101 0xF1 0x0B 0xBD 2304â€“2327 10010011 10001011 10100010 0x93 0x8B 0xA2 2328â€“2351 10010110 00100101 11100011 0x96 0x25 0xE3 2352â€“2375 01101100 11000111 00000101 0x6C 0xC7 0x05 2376â€“2399 00011000 00101000 11110011 0x18 0x28 0xF3 2400â€“2423 00111001 11011000 00010001 0x39 0xD8 0x11 2424â€“2447 01110101 00010111 11011101 0x75 0x17 0xDD 2448â€“2471 11111011 11010010 10101010 0xFB 0xD2 0xAA 2472â€“2495 11101011 10100110 10000101 0xEB 0xA6 0x85 3367 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-42â€”DATA bits after removal of shortening bits and copying of repetition bits (continued) Binary value Binary value Binary value Hexadecimal Hexadecimal Hexadecimal Bit ## B0 B7 B8 B15 B16 B23 value value value 2496â€“2519 10110011 01011000 10101001 0xB3 0x58 0xA9 2520â€“2543 11010001 01010101 00010010 0xD1 0x55 0x12 2544â€“2567 00000100 01110100 11011001 0x04 0x74 0xD9 2568â€“2591 11101001 00111011 11001101 0xE9 0x3B 0xCD I.4 DMG example data vectors Subclauses I.5 to I.8 contain example data vectors for the DMG PHY (see Clause 20). For each described node, there is a cross-reference in this annex that is of the form Reference: where the named file is one of the text files contained in the DMGEncodingExamples.zip file embedded in the IEEE 802.11 Working Group document 11-12/0751r0, located at https://mentor.ieee.org/802.11/dcn/12/ 11-12-0751-00-00ad-dmg-encoding-examples.docx). Depending on the node being illustrated, the text file might represent bit data, symbol data, or sample data: â€” For bit data, the text file contains a time ordered sequence of 1 and 0 characters, separated by spaces and without any carriage control characters. â€” For symbol data, the text file contains a time ordered sequence of signed integers, separated by spaces and without any carriage control characters. â€” For sample data, the text file contains a time ordered sequence of complex values, formatted as Â±Â±j, separated by spaces and without any carriage control characters. When referencing specific bits, symbols, or samples in the files, they are considered to be numbered starting from 1. This formatting of the text files has been chosen to facilitate import into other tools. For example, the files can be read using the MATLAB dlmread('filename') command. For DMG control mode, SC mode and low-power (LP) SC mode modulation samples, no spectrum shaping has been applied to the data because the implementation of spectrum shaping is not defined in this standard. For DMG OFDM mode modulation samples, no symbol shaping has been applied to the data because the implementation of OFDM symbol shaping is not defined in this standard. I.5 DMG Example 1 â€“ DMG control mode encoding I.5.1 DMG control mode preamble The DMG control mode preamble Short Training field (STF) and Channel Estimation field (CEF) are each constructed from a concatenation of real valued bipolar Golay sequences that is Ï€/2-BPSK modulated, as shown in Figure I-1. 3368 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Figure I-1â€”DMG control mode preamble expressed in Ga128 and Gb128 sequences The DMG control mode preamble is 7552 samples long. Reference: CPHY_Preamble Samples.txt I.5.2 Control mode header The DMG control mode header coding and modulation are shown in Figure I-2. I.5.2.1 DMG control mode header and payload bits Figure I-2 node . The 5 octets of header data followed by the payload data. The first 6 octets of the data payload are used to complete the construction of the single LDPC codeword of the DMG control mode header. For this example, the DMG control mode header bit fields are set as listed in Table I-43. Table I-43â€”DMG control mode header settings Field Value Scrambler Initialization 2 Length 120 Packet Type 0 Training Length 0 Turnaround 0 Reserved bits 0 The data payload octets are provided by a count, modulo 256, starting at 0. The resulting header and payload sequence is 1000 bits long, of which the first 88 bits are encoded in the header modulation block. For this example, with a payload of 120 octets, LDPFCW = 88, LDPCW = 152 and LDPLCW = 152. These numbers illustrate that the payload is not simply packed 168 bits at a time into the LDPC encoding, with the last few bits (modulo 168) in the last packet getting disproportionate coding gain. The specified calculation spreads the excess coding gain evenly across all of the packets, so the number of payload bits in each packet varies between approximately 120 and the maximum 168. Reference: Bits 1 to 88 of the file CPHY_Header and Payload bits.txt 3369 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Preamble Header Payload 8192 /2-DBPSK symbols 5 32x spreading with Ga32 and /2 rotation 256 Diff encoded bits 4 Differential encoder data parity 3 Strip zeros data parity Â¾ Rate LDPC data Pad zeros to 504 bits LDPFCW= 11 octets (88 bits) LHDR= 5 octets (40 bits) LFDCW = 6 octets (48 bits) 0 init scrambled header scrambled data payload 2 scrambler 1 4 10 bits 1 5 bits 1 2 16 bits data payload 1 Reserved (diff detect or init) Initialization Scrambler Length Packet type Training Length Turnaround Reserved bits HCS Figure I-2â€”DMG control mode header coding and modulation I.5.2.2 DMG control mode scrambled header and payload bits Figure I-2 node . The 5 header plus 6 data = 11 octets after scrambling. Reference: Bits 1 to 88 of the file CPHY_Scrambled Header and Payload bits.txt I.5.2.3 DMG control mode LDPC encoded header bits Figure I-2 node . In this example there are 7 LDPC codewords. The number of bits produced by the first codeword after zero stripping is 88 + 168 = 256, and the number of bits produced by each of the remaining 6 codewords is 152 + 168 = 320. The total number of bits after LDPC encoding is 256 + 6 x 320 = 2176, of which the first 256 bits correspond to the LDPC encoded header. Reference: Bits 1 to 256 of the file CPHY_LDPC Encoded Header and Payload bits.txt 3370 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications I.5.2.4 DMG control mode differentially encoded header symbols Figure I-2 node . The 256 LDPC encoded header bits are differentially encoded. Reference: Symbols 1 to 256 of the file CPHY_Diff Encoded Header and Payload symbols.txt I.5.2.5 DMG control mode header samples Figure I-2 node . The 256 differentially encoded bipolar symbol values are spread using the Ga32 Golay sequence, then /2 rotated to produce 8192 chips at Fc = 1760 MHz. Reference: Samples 1 to 8192 of the file CPHY_Header and Payload samples.txt I.5.3 DMG control mode payload The DMG control mode payload coding and modulation are shown in Figure I-3. Header Payload 5 32x spreading 32x spreading with Ga32 with Ga32 and /2 rotation and /2 rotation Diff encoded bits Diff encoded bits 4 Differential Differential encoder encoder data parity data parity 3 Strip zeros Strip zeros data parity data parity Â¾ Rate LDPC Â¾ Rate LDPC data Pad zeros to 504 bits data Pad zeros to 504 bits LDPCW = ~120...168 bits LDPLCW = ~120...168 bits last packet scrambled data middle packets scrambled data payload payload 2 scrambler scrambler payload 1 Figure I-3â€”DMG control mode payload coding and modulation I.5.3.1 DMG control mode payload bits Figure I-3 node . Reference: Bits 89 to 1000 of the file CPHY_Header and Payload bits.txt 3371 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications I.5.3.2 DMG control mode scrambled payload bits Figure I-3 node . Reference: Bits 89 to 1000 of the file CPHY_Scrambled Header and Payload bits.txt I.5.3.3 DMG control mode LDPC encoded payload bits Figure I-3 node . Reference: Bits 257 to 2176 of the file CPHY_LDPC Encoded Header and Payload bits.txt I.5.3.4 DMG control mode differentially encoded payload symbols Figure I-3 node . Reference: Symbols 257 to 2176 of the file CPHY_Diff Encoded Header and Data symbols.txt I.5.3.5 DMG control mode payload samples Figure I-3 node . In this example, the 320 differentially encoded bipolar symbol values from each of the 6 payload bearing LDPC codewords, including the last one, gives a total of 6 x 320 = 1920 symbols which are then spread using the Ga32 Golay sequence and /2 rotated to produce 61 440 chips at Fc = 1.76 GHz. Reference: Samples 8193 to 69 632 of the file CPHY_Header and Payload samples.txt I.6 DMG Example 2 â€“ DMG SC mode encoding I.6.1 DMG SC mode preamble The DMG SC mode preamble Short Training field (STF) and Channel Estimation field (CEF) are each constructed from a concatenation of real valued bipolar Golay sequences that is Ï€/2-BPSK modulated, as shown in Figure I-4. Figure I-4â€”DMG SC mode preamble expressed in Ga128 and Gb128 sequences The preamble is 3328 samples long. Reference: SCPHY_Preamble Samples.txt 3372 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications I.6.2 DMG SC mode header The DMG SC mode header coding and modulation are shown in Figure I-5. 6 Preamble Header Payload GI 448 x /2-BPSK symbols GI 448 x /2-BPSK symbols /2 rotation Guard interval is always BPSK GI 448 x BPSK symbols GI 448 x BPSK symbols x -1 448 x BPSK mapped symbols 448 bits BPSK mapping cs1 cs2 5 XOR with No change PN Sequence 64 bits parity 64 bits parity 4 64 bits 504 â€“ 64 = 440 padding zeros parity 3 Â¾ LDPC 64 bits 504 â€“ 64 = 440 padding zeros scram. init. scrambled header 2 scrambler 7 bits 5 bits 18 bits 11 5 bits 1 1 4 bits 1 4 bits 16 bits 1 Initialization Scrambler MCS Length Additional PPDU Packet type Training Length Aggregation Beam Tracking Request RSSI Last Turnaround Reserved HCS Figure I-5â€”DMG SC mode header coding and modulation 3373 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications I.6.2.1 DMG SC control header bits Figure I-5 node . The 8 octets of header data. For this example, the control SC mode header bit fields are set as listed in Table I-44. Table I-44â€”DMG SC control header settings Field Value Scrambler Initialization 66 MCS 2 Length 1000 Additional PPDU 0 Packet Type 0 Training Length 0 Aggregation 0 Beam Tracking Request 0 Last RSSI 0 Turnaround 0 Reserved bits 0 Reference: SCPHY_MCS2_Header bits.txt I.6.2.2 DMG SC mode scrambled header bits Figure I-5 node . The header bits after scrambling bits 8 to 64 of the header using the seed 66 (0x42). Reference: SCPHY_MCS2_Scrambled Header bits.txt I.6.2.3 DMG SC mode LDPC encoded header bits Figure I-5 node . The scrambled header data after LDPC encoding but prior to zero stripping. Reference: SCPHY_MCS2_LDPC Encoded Header bits.txt 3374 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications I.6.2.4 DMG SC mode LDPC data shortened bits Figure I-5 node . The dimension of DMG SC mode modulation blocks requires that the CS1 and CS2 sequences are each 224 bits long; this in turn requires that, in addition to the zeros, some of the parity bits are discarded in order to shorten the LDPC codewords to 224 bits. The data for the second shortened LDPC codeword is given as they are before they are scrambled to provide CS2. Reference: SCPHY_MCS2_Shortened LDPC for CS1 bits.txt Reference: SCPHY_MCS2_Shortened LDPC for CS2 bits.txt I.6.2.5 DMG SC mode CS1/CS2 sequence bits Figure I-5 node . The 448 bit concatenated CS1/CS2 sequence including the PN scrambling of CS2. Reference: SCPHY_MCS2_Final CS1 CS2 Sequence bits.txt I.6.2.6 DMG SC mode header samples Figure I-5 node . The fully modulated signal after BPSK mapping, duplication (with negation), guard interval addition and Ï€/2 rotation are applied. The 448 header bits are BPSK mapped to 448 modulation symbols and increased to 512 symbols by the addition of a 64 symbol guard interval. A second, negated, copy of the 448 modulation symbols is also increased to 512 symbols by the addition of a 64 symbol guard interval. The two 512 symbol blocks are concatenated and Ï€/2 rotated to create 1024 samples. Reference: SCPHY_MCS2_Header Samples.txt I.6.3 DMG SC mode payload The DMG SC mode payload coding and modulation are shown in Figure I-6 (for MCS1) and Figure I-7 (for MCS2â€“MCS12). 3375 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Data 5 GI 448 modulated symbols GI 448 modulated symbols GI 448 modulated symbols GI 448 modulated symbols GI 448 modulated symbols GI /2 rotation /2 rotation /2 rotation /2 rotation /2 rotation GI 448 modulated symbols GI 448 modulated symbols GI 448 modulated symbols GI 448 modulated symbols GI 448 modulated symbols GI NCBPB bits 4 BPSK mapping BPSK mapping BPSK mapping BPSK mapping BPSK mapping scrambled zeros (scrambler state continues from payload) No change scrambler LCWD parity LCWD parity LCWD parity LCWD parity LCWD parity NBLK_PAD zeros NCW x LCW bits LCW = 672 672 bits 672 bits bits LZ data LZ scrambled parity LZ data LZ scrambled parity LZ data LZ scrambled parity PN pattern PN pattern PN pattern Discarded 672 bits Discarded 672 bits Discarded 672 bits LZ data LZ zeros parity LZ data LZ zeros parity LZ data LZ zeros parity 3 (1/2) LDPC (1/2) LDPC (1/2) LDPC LZ data LZ zeros LZ data LZ zeros LZ data LZ zeros m=1 m=2 m = NCW LZ chunk LZ chunk LZ chunk of scrambled of scrambled of scrambled data data data scrambled data (scrambler state continues from header) 2 LCW LCW 1 LCW LZ R 2 2 4 scrambler For MCS1 only = 2, R = 1/2 PPDU Data (PSDU) NDATA_PAD zeros 1 Figure I-6â€”DMG SC mode MCS1 payload coding and modulation 3376 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Data 4 GI 448 modulated symbols GI 448 modulated symbols GI 448 modulated symbols GI 448 modulated symbols GI 448 modulated symbols GI /2 rotation /2 rotation /2 rotation /2 rotation /2 rotation GI 448 modulated symbols GI 448 modulated symbols GI 448 modulated symbols GI 448 modulated symbols GI 448 modulated symbols GI NCBPB BPSK, QPSK BPSK, QPSK BPSK, QPSK BPSK, QPSK BPSK, QPSK bits or QAM16 or QAM16 or QAM16 or QAM16 or QAM16 3 mapping mapping mapping mapping mapping scrambled zeros (scrambler state continues from payload) No change scrambler LCWD parity LCWD parity LCWD parity LCWD parity LCWD parity NBLK_PAD zeros NCW x LCW bits LCW = 672 bits 672 bits 672 bits LCWD parity LCWD parity LCWD parity (R) LDPC (R) LDPC (R) LDPC m=1 m=2 m = NCW LCWD = (R) x LCW LCWD = (R) x LCW LCWD = (R) x LCW LCWD- sized chunk LCWD- sized chunk LCWD- sized chunk scrambled data (scrambler state continues from header) 2 LCW LCW LCWD R R LCW R 1 scrambler = 1, R = set by MCS PPDU Data (PSDU) NDATA_PAD zeros 1 Figure I-7â€”DMG SC mode MCS2â€”MCS12 payload coding and modulation I.6.3.1 DMG SC mode MCS1 payload I.6.3.1.1 Payload bits Figure I-6 node . The payload at node is a count, modulo 256, starting at 0. For MCS1 each rate 1/2 LDPC codeword encodes 168 bits (with = 2 repetition) so the payload padding calculation gives NCW = 48 and NDATA_PAD = 64. There are 1000 Ã— 8 = 8000 payload bits plus 64 padding bits giving a total of 8 064 bits. Reference: SCPHY_MCS1_Payload bits.txt I.6.3.1.2 Scrambled payload bits Figure I-6 node . All 8 064 bits are scrambled according to a scrambler initialization value of 66. Reference: SCPHY_MCS1_Scrambled Payload bits.txt 3377 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications I.6.3.1.3 Rate 1/2 LDPC encoded bits before scrambled duplication Figure I-6 node . The rate 1/2 LDPC encoding of each block of Lz = 168 scrambled payload bits plus Lz = 168 padding zero bits. In this example, the 8064 actual payload bits are doubled, by repetition, to an effective payload of 16 128 bits, then doubled again to 32 256 bits by LDPC encoding. This node, unique to MCS1, is the raw LDPC encoded payload bits before scrambled duplication. Reference: SCPHY_MCS1_LDPC Encoder Output bits.txt I.6.3.1.4 Rate 1/2 LDPC encoded bits after scrambled duplication Figure I-6 node . The LDPC codewords after the Lz = 168 zeros have been replaced by the Lz = 168 re- scrambled data octets. The data at this node also includes the appended NBLK_PAD scrambled zeros; however, in this example, NBLK_PAD = 0, so there are still 32 256 bits. Each 448 bits in the reference file is the NCBPB = 448 bits required to build a modulation block of the MCS1 payload. Reference: SCPHY_MCS1_LDPC Encoded Payload Bits.txt I.6.3.1.5 Payload samples Figure I-6 node . The modulated signal after BPSK mapping, guard interval addition and /2 rotation has been applied. In this example, the 32 256 encoded bits are divided into 72 Ã— 448 bit blocks. BPSK mapping converts this to 72 Ã— 448 modulation symbols which the guard interval increases to 72 Ã— 512 modulation symbols. When the closing 64-symbol guard interval is added, it results in a total of 72 Ã— 512 + 64 = 36 928 payload samples. Reference: SCPHY_MCS1_Payload Samples.txt I.6.3.2 DMG SC mode MCS5 payload I.6.3.2.1 Payload bits Figure I-7 node . The payload at node is a count, modulo 256, starting at 0. For MCS5 each rate 13/16 LDPC codeword encodes 546 bits so the payload padding calculation gives NCW = 15 and NDATA_PAD = 190. There are 1000 Ã— 8 = 8000 payload bits plus 190 padding bits giving a total of 8 190 bits. Reference: SCPHY_MCS5_Payload bits.txt I.6.3.2.2 Scrambled payload bits Figure I-7 node . All 8 190 bits are scrambled according to a scrambler initialization value of 66. Reference: SCPHY_MCS5_Scrambled Payload bits.txt 3378 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications I.6.3.2.3 Rate 13/16 LDPC encoded payload bits Figure I-6 node . The rate 13/16 LDPC encoding of each block of LCWD = 546 scrambled payload bits. In this example, the 8 190 payload bits are increased to 10 080 bits by the LDPC encoding. The data at this node also includes the appended NBLK_PAD scrambled zeros. In this example, NBLK_PAD = 224, so the total number of bits is 10 080 + 224 = 10 304. Reference: SCPHY_MCS5_LDPC Encoded Payload Bits.txt I.6.3.2.4 Payload samples Figure I-7 node . The modulated signal after BPSK mapping, guard interval addition and /2 rotation has been applied. In this example, the 10 304 encoded bits are divided into 23 Ã— 448 bit blocks. BPSK mapping converts this to 23 Ã— 448 modulation symbols which the guard interval increases to 23 Ã— 512 modulation symbols. When the closing 64-symbol guard interval is added, it results in a total of 23 Ã— 512 + 64 = 11 840 payload samples. Reference: SCPHY_MCS5_Payload Samples.txt I.6.3.3 DMG SC mode MCS7 payload I.6.3.3.1 Payload bits Figure I-7 node . The payload at node is a count, modulo 256, starting at 0. For MCS7 each rate 5/8 LDPC codeword encodes 420 bits so the payload padding calculation gives NCW = 20 and NDATA_PAD = 400. There are 1000 Ã— 8 = 8000 payload bits plus 400 padding bits giving a total of 8 400 bits. Reference: SCPHY_MCS7_Payload bits.txt I.6.3.3.2 Scrambled payload bits Figure I-6 node . All 8 400 bits are scrambled according to a scrambler initialization value of 66. Reference: SCPHY_MCS7_Scrambled Payload bits.txt I.6.3.3.3 Rate 5/8 LDPC encoded payload bits Figure I-7 node . The rate 5/8 LDPC encoding of each block of LCWD = 420 scrambled payload bits. In this example, the 8 400 payload bits are increased to 13 440 bits by the LDPC encoding. The data at this node also includes the appended NBLK_PAD scrambled zeros. In this example, NBLK_PAD = 0, so there are still a total of 13 440 bits. Reference: SCPHY_MCS7_LDPC Encoded Payload Bits.txt 3379 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications I.6.3.3.4 Payload samples Figure I-7 node . The modulated signal after QPSK mapping, guard interval addition and /2 rotation has been applied. In this example, the 13 440 encoded bits are divided into 15 Ã— 896 bit blocks. QPSK mapping converts this to 15 Ã— 448 modulation symbols which the guard interval increases to 15 Ã— 512 modulation symbols. When the closing 64-symbol guard interval is added, it results in a total of 15 Ã— 512 + 64 = 7 744 payload samples. Reference: SCPHY_MCS7_Payload Samples.txt I.6.3.4 DMG SC mode MCS12 payload I.6.3.4.1 Payload bits Figure I-7 node . The payload at node is a count, modulo 256, starting at 0. For MCS12 each rate 3/4 LDPC codeword encodes 504 bits so the payload padding calculation gives NCW = 16 and NDATA_PAD = 64. There are 1000 Ã— 8 = 8000 payload bits plus 64 padding bits giving a total of 8 064 bits. Reference: SCPHY_MCS12_Payload bits.txt I.6.3.4.2 Scrambled payload bits Figure I-7 node . All 8 064 bits are scrambled according to a scrambler initialization value of 66. Reference: SCPHY_MCS12_Scrambled Payload bits.txt I.6.3.4.3 Rate 3/4 LDPC encoded payload bits Figure I-7 node . The rate 3/4 LDPC encoding of each block of LCWD = 504 scrambled payload bits. In this example, the 8 064 payload bits are increased to 10 752 bits by the LDPC encoding. The data at this node also includes the appended NBLK_PAD scrambled zeros. In this example, NBLK_PAD = 0, so there are still a total of 10 752 bits. Reference: SCPHY_MCS12_LDPC Encoded Payload Bits.txt I.6.3.4.4 Payload samples Figure I-7 node . The modulated signal after 16-QAM mapping, guard interval addition and /2 rotation has been applied. In this example, the 10 752 encoded bits are divided into 6 Ã— 1 792 bit blocks. 16-QAM mapping converts this to 6 Ã— 448 modulation symbols which the guard interval increases to 6 Ã— 512 modulation symbols. When the closing 64-symbol guard interval is added, it results in a total of 6 Ã— 512 + 64 = 3 136 payload samples. Reference: SCPHY_MCS12_Payload Samples.txt 3380 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications I.7 DMG Example 3 â€“ DMG OFDM mode encoding I.7.1 DMG OFDM mode preamble Figure I-8 illustrates that the DMG OFDM mode preamble is similar to the DMG SC mode preamble, but with the Gu512 and Gv512 parts of the CEF reversed. It is also resampled from 1.76 GSa/s to 2.64 GSa/s using the specified process of interpolation, resampling, and decimation. Figure I-8â€”DMG OFDM mode preamble Thus the DMG OFDM mode preamble sample count increases from 3 328 to 4 992. Reference: OFDMPHY_Preamble Samples.txt I.7.2 DMG OFDM mode header The DMG OFDM mode header coding is shown in Figure I-9. I.7.2.1 DMG OFDM mode header bits Figure I-9 node . The 8 octets of header data. For this example, the DMG OFDM mode header bit fields are set as listed in Table I-45. Reference: OFDMPHY_MCS13_Header bits.txt 3381 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NCBPS bits = 672 bits cs1 cs2 cs3 5 XOR with XOR with No change PN Sequence PN Sequence 64 bits parity 64 bits parity 64 bits parity 4 64 bits 504 â€“ 64 = 440 padding zeros parity 3 Â¾ LDPC 64 bits 504 â€“ 64 = 440 padding zeros scram. init. scrambled header 2 scrambler 7 bits 5 bits 18 bits 11 5 bits 1 1 1 1 4 bits 1 2 16 bits 1 Initialization Scrambler MCS Length Additional PPDU Packet type Training Length Aggregation Beam Tracking Request Tone Pairing Type DTP Indicator Last RSSI Turnaround Reserved HCS Figure I-9â€”DMG OFDM mode header coding Table I-45â€”DMG OFDM mode header settings Field Value Scrambler Initialization 66 MCS 13 Length 1000 Additional PPDU 0 Packet Type 0 Training Length 0 Aggregation 0 Beam Tracking Request 0 Tone Pairing Type 0 3382 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table I-45â€”DMG OFDM mode header settings (continued) Field Value DTP Indicator 0 Last RSSI 0 Turnaround 0 Reserved bits 0 I.7.2.2 DMG OFDM mode scrambled header bits Figure I-9 node . The header bits after scrambling bits 8 to 64 of the header using the seed 66 (0x42). Reference: OFDMPHY_MCS13_Scrambled Header bits.txt I.7.2.3 DMG OFDM mode LDPC encoded header bits Figure I-9 node . The scrambled header bits after LDPC encoding but prior to zero stripping. Reference: OFDMPHY_MCS13_LDPC Encoded Header Bits.txt I.7.2.4 DMG OFDM mode LDPC data shortened bits Figure I-9 node . The dimension of DMG OFDM mode modulation symbols requires that the CS1, CS2, and CS3 sequences are each 224 bits long; this in turn requires that, in addition to the zeros, some of the parity bits are discarded in order to shorten the LDPC codewords to 224 bits. The data for the second and third shortened LDPC codewords are given as they are before they are scrambled to provide CS2 and CS3. Reference: OFDMPHY_MCS13_Shortened LDPC for CS1 bits.txt Reference: OFDMPHY_MCS13_Shortened LDPC for CS2 bits.txt Reference: OFDMPHY_MCS13_Shortened LDPC for CS3 bits.txt I.7.2.5 DMG OFDM mode CS1/CS2/CS3 sequence bits Figure I-9 node . The 672 bit concatenated CS1/CS2/CS3 sequence including the PN scrambling of CS2 and CS3. Reference: OFDMPHY_MCS13_Final CS1 CS2 CS3 Sequence bits.txt 3383 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications I.7.3 DMG OFDM mode header modulation The DMG OFDM mode header modulation is shown in Figure I-10. Preamble Header Payload CP 3 Add cyclic prefix 512 time points Inverse FFT 512 frequency points 2 Null and pilot insertion (NCBPS / 2) points 1 x2 k f c4 k , c4 k 2 x2 k 1 f c4 k 1 , c4 k 3 N SD k 0,1, , 1 2 T T 1 1 2 dk , dP k Q x2 k , x2 k 1 , where Q 5 2 1 NCBPS bits = 672 From DMG OFDM mode header coding Figure I-10â€”DMG OFDM mode header modulation I.7.3.1 Constellation mapped data points Figure I-10 node . The LDPC encoded data is converted in the specified manner to 336 QPSK constellation point values prior to assignment to data carriers (in the same order as the data they were derived from). Note that because of the action of the Q matrix, these points look like 16-QAM when plotted. Reference: Samples 1 to 336 of the file OFDMPHY_MCS13_Constellation Mapped Data Points.txt I.7.3.2 IFFT input samples including data, pilot, DC and null carriers Figure I-10 node . At this node the data points have been mapped to the data carriers, the pilots, DC and null carriers have been assigned, and the resulting 512 point frequency domain vector is in the correct order for input to the inverse Fourier transform, i.e., with positive frequencies in the first 256 locations and negative frequencies in the second 256 locations. Reference: Samples 1 to 512 of the file OFDMPHY_MCS13_FFT Input Samples.txt 3384 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications I.7.3.3 Header samples Figure I-10 node . At this node the signal has been inverse Fourier transformed to produce a time record and the cyclic prefix has been appended to create the 640 sample OFDM symbol. Reference: OFDMPHY_MCS13_Header Samples.txt I.7.4 DMG OFDM mode payload coding As illustrated in Figure I-11, the LDPC encoding for the DMG OFDM mode case is identical to the DMG SC mode case, so no additional LDPC vectors are strictly necessary. However, the equations for computing the zero padding at the end of the payload are different from the DMG SC mode case so bit vectors for nodes 1, 2, and 3 are provided. NCW x LCW = NSYM x NCBPS bits LCW = 672 bits LCW = 672 bits LCW = 672 bits LCWD parity LCWD parity LCWD parity (R) LDPC (R) LDPC (R) LDPC m=1 m=2 m = NCW 3 LCWD = (R) x LCW LCWD = (R) x LCW LCWD = (R) x LCW LCWD- sized chunk LCWD- sized chunk LCWD- sized chunk 2 scrambled data (scrambler state continues from header) scrambler PPDU Data (PSDU) NPAD zeros 1 Figure I-11â€”DMG OFDM mode payload coding I.7.5 DMG OFDM mode MCS14 payload modulation The DMG OFDM mode SQPSK payload modulation is shown in Figure I-12. I.7.5.1 Payload bits Figure I-11 node . The payload comprises 1000 Ã— 8 bits. With NCBPS = 336 and rate 5/8 LDPC coding the DMG OFDM mode zero padding NPAD = 400, so the padded payload comprises 8 400 bits. Reference: OFDMPHY_MCS14_ Payload bits.txt I.7.5.2 Scrambled payload bits Figure I-11 node . All 8 400 bits are scrambled according to a scrambler initialization value of 66. Reference: OFDMPHY_MCS14_Scrambled Payload bits.txt 3385 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 2 Payload CP Add cyclic prefix 512 time points Inverse FFT 512 frequency points Null and pilot insertion NCBPS points 1 conjugation and static tone pairing (NCBPS / 2) points dk f c2 k , c2 k 1 NCBPS bits = 336 LCWD parity For SQPSK, half of an LDPC codeword is used for each OFDM symbol Figure I-12â€”DMG OFDM mode SQPSK payload modulation I.7.5.3 LDPC encoded payload bits Figure I-11 node . For this example, with NCBPS = 336 and rate 5/8 LDPC coding there are 20 LDPC codewords or 20 Ã— 672 = 13 440 bits at this node. Reference: OFDMPHY_MCS14_LDPC Encoded Payload bits.txt I.7.5.4 SQPSK constellation mapped data points Figure I-12 node . For SQPSK modulation, each block of NCBPS = 336 LDPC encoded bits is converted in the specified manner to 168 QPSK constellation point values and their complex conjugates prior to assignment to data carriers, in the same order as the data they were derived from. There are 336 constellation points for each block of 336 LDPC encoded bits, so there are 40 sets of 336 constellation points (13 440 point in total) at this node. Reference: Samples 337 to 13 776 of the file OFDMPHY_MCS14_Constellation Mapped Data Points.txt 3386 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications I.7.5.5 Payload samples Figure I-12 node . Each set of 336 constellation points is mapped to 512 frequency domain points then inverse Fourier transformed to 512 time domain points; adding the cyclic prefix creates a 640 sample OFDM symbol. There are 40 OFDM symbols in this example payload, giving a total of 40 Ã— 640 = 25 600 samples. Reference: OFDMPHY_MCS14_Payload Samples.txt I.7.6 DMG OFDM mode MCS17 payload modulation The DMG OFDM mode QPSK payload modulation is shown in Figure I-13. 2 Payload CP Add cyclic prefix 512 time points Inverse FFT 512 frequency points Null and pilot insertion (NCBPS / 2) points 1 x2 k f c4 k , c4 k 2 x2 k 1 f c4 k 1 , c4 k 3 N k 0,1, , SD 1 2 T T 1 1 2 dk , d P k Q x2 k , x2 k 1 , where Q 5 2 1 NCBPS bits = 672 LCWD parity For QPSK, 1 LDPC codeword is used for each OFDM symbol Figure I-13â€”DMG OFDM mode QPSK payload modulation I.7.6.1 Payload bits Figure I-11 node . The payload comprises 1000 Ã— 8 bits. With NCBPS = 672 and rate 3/4 LDPC coding the DMG OFDM mode zero padding NPAD = 64, so the padded payload comprises 8 064 bits. Reference: OFDMPHY_MCS17_ Payload bits.txt 3387 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications I.7.6.2 Scrambled payload bits Figure I-11 node . All 8 064 bits are scrambled according to a scrambler initialization value of 66. Reference: OFDMPHY_MCS17_Scrambled Payload bits.txt I.7.6.3 LDPC encoded payload bits Figure I-11 node . For this example, with NCBPS = 672 and rate 3/4 LDPC coding there are 16 LDPC codewords or 16 Ã— 672 = 10 752 bits at this node. Reference: OFDMPHY_MCS17_LDPC Encoded Payload bits.txt I.7.6.4 QPSK constellation mapped data points Figure I-13 node . For QPSK modulation, each block of NCBPS = 672 LDPC encoded bits is converted in the specified manner to 336 QPSK constellation point values prior to assignment to data carriers, in the same order as the data they were derived from. There are 336 constellation points for each block of 672 LDPC encoded bits, so there are 16 sets of 336 constellation points (5 376 point in total) at this node. Reference: Samples 337 to 5 712 of the file OFDMPHY_MCS17_Constellation Mapped Data Points.txt I.7.6.5 Payload samples Figure I-13 node . Each set of 336 constellation points is mapped to 512 frequency domain points then inverse Fourier transformed to 512 time domain points; adding the cyclic prefix creates a 640 sample OFDM symbol. There are 16 OFDM symbols in this example payload giving a total of 16 Ã— 640 = 10 240 samples. Reference: OFDMPHY_MCS17_Payload Samples.txt I.7.7 DMG OFDM mode MCS19 payload modulation The DMG OFDM mode 16-QAM payload modulation is shown in Figure I-14. I.7.7.1 Payload bits Figure I-11 node . The payload comprises 1000 Ã— 8 bits. With NCBPS = 1 344 and rate 5/8 LDPC coding the DMG OFDM mode zero padding NPAD = 400, so the padded payload comprises 8 400 bits. Reference: OFDMPHY_MCS19_ Payload bits.txt I.7.7.2 Scrambled payload bits Figure I-11 node . All 8 400 bits are scrambled according to a scrambler initialization value of 66. Reference: OFDMPHY_MCS19_Scrambled Payload bits.txt 3388 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 2 Payload CP Add cyclic prefix 512 time points Inverse FFT 512 frequency points Null and pilot insertion (NCBPS / 4) points 1 NCBPS bits = 1344 LCWD parity LCWD parity For 16-QAM, 2 LDPC codewords are used for each OFDM symbol Figure I-14â€”DMG OFDM mode 16-QAM payload modulation I.7.7.3 LDPC encoded payload bits Figure I-11 node . For this example, with NCBPS = 1 344 and rate 5/8 LDPC coding there are 20 LDPC codewords or 20 Ã— 672 = 13 440 bits at this node. Reference: OFDMPHY_MCS19_LDPC Encoded Payload bits.txt I.7.7.4 16-QAM constellation mapped data points Figure I-14 node . For 16-QAM modulation, each block of NCBPS = 1 344 LDPC encoded bits is converted in the specified manner to 336 16-QAM constellation point values prior to assignment to data carriers, in the same order as the data they were derived from. There are 336 constellation points for each block of 1 344 LDPC encoded bits, so there are 10 sets of 336 constellation points (3360 points in total) at this node. Reference: Samples 337 to 3 696 of the file OFDMPHY_MCS19_Constellation Mapped Data Points.txt 3389 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications I.7.7.5 Payload samples Figure I-14 node . Each set of 336 constellation points is mapped to 512 frequency domain points then inverse Fourier transformed to 512 time domain points; adding the cyclic prefix creates a 640 sample OFDM symbol. There are 10 OFDM symbols in this example payload giving a total of 10 Ã— 640 = 6 400 samples. Reference: OFDMPHY_MCS19_Payload Samples.txt I.7.8 DMG OFDM mode MCS23 payload modulation The DMG OFDM mode 64-QAM payload modulation is shown in Figure I-15. 2 Payload CP Add cyclic prefix 512 time points Inverse FFT 512 frequency points Null and pilot insertion (NCBPS / 6) points 1 NCBPS bits = 2016 LCWD parity LCWD parity LCWD parity For 64-QAM, 3 LDPC codewords are used for each OFDM symbol Figure I-15â€”DMG OFDM mode 64-QAM payload modulation I.7.8.1 Payload bits Figure I-11 node . The payload comprises 1000 Ã— 8 bits. With NCBPS = 2 016 and rate 3/4 LDPC coding the DMG OFDM mode zero padding NPAD = 1 072, so the padded payload comprises 9 072 bits. Reference: OFDMPHY_MCS23_ Payload bits.txt 3390 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications I.7.8.2 Scrambled payload bits Figure I-11 node . All 9 072 bits are scrambled according to a scrambler initialization value of 66. Reference: OFDMPHY_MCS23_Scrambled Payload bits.txt I.7.8.3 LDPC encoded bits Figure I-11 node . For this example, with NCBPS = 2 016 and rate 3/4 LDPC coding there are 18 LDPC codewords or 18 Ã— 672 = 12 096 bits at this node. Reference: OFDMPHY_MCS23_LDPC Encoded Payload bits.txt I.7.8.4 64-QAM constellation mapped data points Figure I-15 node . For 64-QAM modulation, each block of NCBPS = 2 016 LDPC encoded bits is converted in the specified manner to 336 64-QAM constellation point values prior to assignment to data carriers, in the same order as the data they were derived from. There are 336 constellation points for each block of 2 016 LDPC encoded bits, so there are 6 sets of 336 constellation points (2 016 points in total) at this node. Reference: Samples 337 to 2352 of the file OFDMPHY_MCS23_Constellation Mapped Data Points.txt I.7.8.5 Payload samples Figure I-15 node . Each set of 336 constellation points is mapped to 512 frequency domain points then inverse Fourier transformed to 512 time domain points; adding the cyclic prefix creates a 640 sample OFDM symbol. There are 6 OFDM symbols in this example payload giving a total of 6 Ã— 640 = 3 840 samples. Reference: OFDMPHY_MCS23_Payload Samples.txt I.8 DMG Example 4 â€“ DMG low-power SC mode encoding I.8.1 DMG low-power SC mode preamble The DMG low-power SC mode preamble is identical to the DMG SC mode preamble. I.8.2 DMG low-power SC mode header The DMG low-power SC mode header fields are the same as the DMG SC mode header fields. The DMG low-power SC mode header is encoded and modulated in the same way as the DMG SC mode header. 3391 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications I.8.3 DMG low-power SC mode MCS26 payload The DMG low-power SC mode payload coding and modulation are shown in Figure I-16. Payload 6 /2-BPSK/QPSK block /2-BPSK/QPSK block /2-BPSK/QPSK block Ga 64 /2 rotation 512 modulation symbols Ga64 G8 N EB N BLKS NCBPS 392 first block 512-64 -(7 x 8) = 392 modulation symbols last block BPSK or QPSK mapping 5 N BLKS N CBPS 392 bits 7 row x 8 column bit interleaver NBLK _PAD NEB = N x (Length + NRS x 16) scrambled zeros Add padding 4 (N,8) Block Code 3 16 parity 208 data octets octets N RS Length 208 2 RS(224,208) scrambled "Length" scrambled data octets (scrambler state continues from header) zeros scrambler scrambler NBLK_PAD PPDU Data (PSDU) â€“ "Length" octets zeros 1 Figure I-16â€”DMG low-power SC mode payload coding and modulation I.8.3.1 Payload bits Figure I-16 node . The payload at node is a count, modulo 256, starting at 0. For MCS26, the DMG low-power SC mode payload padding calculation gives NDATA_PAD = 368; however, unlike the other modes, this padding data is not appended before FEC computation. 3392 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications So there are just 1000 Ã— 8 = 8000 payload bits. Reference: LPSCPHY_MCS26_Payload bits.txt I.8.3.2 Scrambled payload bits Figure I-16 node . All 8000 bits are scrambled according to a scrambler initialization value of 66. Reference: LPSCPHY_MCS26_Scrambled Payload bits.txt I.8.3.3 RS(224,208) encoded payload bits Figure I-16 node . In this example, there are 4 RS(224,208) codewords and one shortened RS(184,168) codeword, giving a total of (4 Ã— 224 + 1 Ã— 184) Ã— 8 = 8 640 bits at this node. Reference: LPSCPHY_MCS26_RS(224,208) Output bits.txt I.8.3.4 (12,8) block coded payload bits Figure I-16 node . The (12,8) block coder increases the effective bits from 8 640 to 12 960. Reference: LPSCPHY_MCS26_Block Coded Payload bits.txt I.8.3.5 Interleaved payload bits Figure I-16 node . Before interleaving the block coder output is padded with NDATA_PAD = 368 scrambled zeros to give 13 328 bits (34 x 392). The interleaver then redistributes these bits in time, as specified. Reference: LPSCPHY_MCS26_RS Encoded and Interleaved Payload bits.txt I.8.3.6 Payload samples Figure I-16 node . Each block of 392 bits from the interleaver output is BPSK mapped to 392 modulation symbols, prepended with a Ga64 sequence as a guard interval and punctuated by G8 (last 8 samples of Ga64) guard intervals, then /2 rotated, thus resulting in a 512 symbol /2-BPSK modulation block. In this example, there are 34 modulation blocks and, as specified, the last one is followed by a terminating Ga64 guard interval sequence, so there are 34 Ã— 512 + 64 = 17 472 samples at this node. Reference: LPSCPHY_MCS26_Payload Samples.txt I.8.4 DMG low-power SC mode MCS30 payload I.8.4.1 Payload bits Figure I-16 node . The payload at node is a count, modulo 256, starting at 0. For MCS30, the DMG low-power SC mode payload padding calculation gives NDATA_PAD = 472; however, unlike the other modes, this padding data is not appended before FEC computation. So there are just 1000 Ã— 8 = 8000 payload bits. Reference: LPSCPHY_MCS30_Payload bits.txt 3393 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications I.8.4.2 Scrambled payload bits Figure I-16 node . All 8000 bits are scrambled according to a scrambler initialization value of 66. Reference: LPSCPHY_MCS30_Scrambled Payload bits.txt I.8.4.3 RS(224,208) encoded payload bits Figure I-16 node . In this example, there are 4 RS(224,208) codewords and one shortened RS(184,168) codeword, giving a total of (4 Ã— 224 + 1 Ã— 184) Ã— 8 = 8 640 bits at this node. Reference: LPSCPHY_MCS30_RS(224,208) Output bits.txt I.8.4.4 Spc(9,8) block coded payload bits Figure I-16 node . The (9,8) block coder increases the effective bits from 8 640 to 9 720. Reference: LPSCPHY_MCS30_Block Coded Payload bits.txt I.8.4.5 Interleaved payload bits Figure I-16 node . Before interleaving the block coder output is padded with NDATA_PAD = 472 scrambled zeros to give 10 192 bits (26 Ã— 392). The interleaver then redistributes these bits in time, as specified. Reference: LPSCPHY_MCS30_RS Encoded and Interleaved Payload bits.txt I.8.4.6 Payload samples Figure I-16 node . Each block of 784 bits from the interleaver output is QPSK mapped to 392 modulation symbols, prepended with a Ga64 sequence as a guard interval and punctuated by G8 (last 8 samples of Ga64) guard intervals, then /2 rotated, thus resulting in a 512 symbol /2-BPSK modulation block. In this example, there are 13 modulation blocks and, as specified, the last one is followed by a terminating Ga64 guard interval sequence, so there are 13 Ã— 512 + 64 = 6 720 samples at this node. Reference: LPSCPHY_MCS30_Payload Samples.txt 3394 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Annex J (informative) RSNA reference implementations and test vectors J.1 TKIP temporal key mixing function reference implementation and test vector J.1.1 TKIP temporal key mixing function reference implementation This clause provides a C-language reference implementation of the temporal key mixing function. /*********************************************************************** Contents: Generate IEEE 802.11 per-frame ARC4 key hash test vectors Date: April 19, 2002 Notes: This code is written for pedagogical purposes, NOT for performance. ************************************************************************/ #include #include #include #include #include typedef unsigned char byte; /* 8-bit byte (octet) */ typedef unsigned short u16b; /* 16-bit unsigned word */ typedef unsigned long u32b; /* 32-bit unsigned word */ /* macros for extraction/creation of byte/u16b values */ #define RotR1(v16) ((((v16) >> 1) & 0x7FFF) ^ (((v16) & 1) << 15)) #define Lo8(v16) ((byte)( (v16) & 0x00FF)) #define Hi8(v16) ((byte)(((v16) >> 8) & 0x00FF)) #define Lo16(v32) ((u16b)( (v32) & 0xFFFF)) #define Hi16(v32) ((u16b)(((v32) >>16) & 0xFFFF)) #define Mk16(hi,lo) ((lo) ^ (((u16b)(hi)) << 8)) /* select the Nth 16-bit word of the Temporal Key byte array TK[] */ #define TK16(N) Mk16(TK[2*(N)+1],TK[2*(N)]) /* S-box lookup: 16 bits --> 16 bits */ #define _S_(v16) (Sbox[0][Lo8(v16)] ^ Sbox[1][Hi8(v16)]) 3395 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications /* fixed algorithm "parameters" */ #define PHASE1_LOOP_CNT 8 /* this needs to be "big enough" */ #define TA_SIZE 6 /* 48-bit transmitter address */ #define TK_SIZE 16 /* 128-bit Temporal Key */ #define P1K_SIZE 10 /* 80-bit Phase1 key */ #define ARC4_KEY_SIZE 16 /* 128-bit ARC4KEY (104 bits unknown)*/ /* configuration settings */ #define DO_SANITY_CHECK 1 /* validate properties of S-box? */ /* 2-byte by 2-byte subset of the full AES S-box table */ const u16b Sbox[2][256]= /* Sbox for hash (can be in ROM) */ { { 0xC6A5,0xF884,0xEE99,0xF68D,0xFF0D,0xD6BD,0xDEB1,0x9154, 0x6050,0x0203,0xCEA9,0x567D,0xE719,0xB562,0x4DE6,0xEC9A, 0x8F45,0x1F9D,0x8940,0xFA87,0xEF15,0xB2EB,0x8EC9,0xFB0B, 0x41EC,0xB367,0x5FFD,0x45EA,0x23BF,0x53F7,0xE496,0x9B5B, 0x75C2,0xE11C,0x3DAE,0x4C6A,0x6C5A,0x7E41,0xF502,0x834F, 0x685C,0x51F4,0xD134,0xF908,0xE293,0xAB73,0x6253,0x2A3F, 0x080C,0x9552,0x4665,0x9D5E,0x3028,0x37A1,0x0A0F,0x2FB5, 0x0E09,0x2436,0x1B9B,0xDF3D,0xCD26,0x4E69,0x7FCD,0xEA9F, 0x121B,0x1D9E,0x5874,0x342E,0x362D,0xDCB2,0xB4EE,0x5BFB, 0xA4F6,0x764D,0xB761,0x7DCE,0x527B,0xDD3E,0x5E71,0x1397, 0xA6F5,0xB968,0x0000,0xC12C,0x4060,0xE31F,0x79C8,0xB6ED, 0xD4BE,0x8D46,0x67D9,0x724B,0x94DE,0x98D4,0xB0E8,0x854A, 0xBB6B,0xC52A,0x4FE5,0xED16,0x86C5,0x9AD7,0x6655,0x1194, 0x8ACF,0xE910,0x0406,0xFE81,0xA0F0,0x7844,0x25BA,0x4BE3, 0xA2F3,0x5DFE,0x80C0,0x058A,0x3FAD,0x21BC,0x7048,0xF104, 0x63DF,0x77C1,0xAF75,0x4263,0x2030,0xE51A,0xFD0E,0xBF6D, 0x814C,0x1814,0x2635,0xC32F,0xBEE1,0x35A2,0x88CC,0x2E39, 0x9357,0x55F2,0xFC82,0x7A47,0xC8AC,0xBAE7,0x322B,0xE695, 0xC0A0,0x1998,0x9ED1,0xA37F,0x4466,0x547E,0x3BAB,0x0B83, 0x8CCA,0xC729,0x6BD3,0x283C,0xA779,0xBCE2,0x161D,0xAD76, 0xDB3B,0x6456,0x744E,0x141E,0x92DB,0x0C0A,0x486C,0xB8E4, 0x9F5D,0xBD6E,0x43EF,0xC4A6,0x39A8,0x31A4,0xD337,0xF28B, 0xD532,0x8B43,0x6E59,0xDAB7,0x018C,0xB164,0x9CD2,0x49E0, 0xD8B4,0xACFA,0xF307,0xCF25,0xCAAF,0xF48E,0x47E9,0x1018, 0x6FD5,0xF088,0x4A6F,0x5C72,0x3824,0x57F1,0x73C7,0x9751, 0xCB23,0xA17C,0xE89C,0x3E21,0x96DD,0x61DC,0x0D86,0x0F85, 0xE090,0x7C42,0x71C4,0xCCAA,0x90D8,0x0605,0xF701,0x1C12, 0xC2A3,0x6A5F,0xAEF9,0x69D0,0x1791,0x9958,0x3A27,0x27B9, 0xD938,0xEB13,0x2BB3,0x2233,0xD2BB,0xA970,0x0789,0x33A7, 0x2DB6,0x3C22,0x1592,0xC920,0x8749,0xAAFF,0x5078,0xA57A, 0x038F,0x59F8,0x0980,0x1A17,0x65DA,0xD731,0x84C6,0xD0B8, 0x82C3,0x29B0,0x5A77,0x1E11,0x7BCB,0xA8FC,0x6DD6,0x2C3A, }, 3396 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications { /* second half of table is byte-reversed version of first! */ 0xA5C6,0x84F8,0x99EE,0x8DF6,0x0DFF,0xBDD6,0xB1DE,0x5491, 0x5060,0x0302,0xA9CE,0x7D56,0x19E7,0x62B5,0xE64D,0x9AEC, 0x458F,0x9D1F,0x4089,0x87FA,0x15EF,0xEBB2,0xC98E,0x0BFB, 0xEC41,0x67B3,0xFD5F,0xEA45,0xBF23,0xF753,0x96E4,0x5B9B, 0xC275,0x1CE1,0xAE3D,0x6A4C,0x5A6C,0x417E,0x02F5,0x4F83, 0x5C68,0xF451,0x34D1,0x08F9,0x93E2,0x73AB,0x5362,0x3F2A, 0x0C08,0x5295,0x6546,0x5E9D,0x2830,0xA137,0x0F0A,0xB52F, 0x090E,0x3624,0x9B1B,0x3DDF,0x26CD,0x694E,0xCD7F,0x9FEA, 0x1B12,0x9E1D,0x7458,0x2E34,0x2D36,0xB2DC,0xEEB4,0xFB5B, 0xF6A4,0x4D76,0x61B7,0xCE7D,0x7B52,0x3EDD,0x715E,0x9713, 0xF5A6,0x68B9,0x0000,0x2CC1,0x6040,0x1FE3,0xC879,0xEDB6, 0xBED4,0x468D,0xD967,0x4B72,0xDE94,0xD498,0xE8B0,0x4A85, 0x6BBB,0x2AC5,0xE54F,0x16ED,0xC586,0xD79A,0x5566,0x9411, 0xCF8A,0x10E9,0x0604,0x81FE,0xF0A0,0x4478,0xBA25,0xE34B, 0xF3A2,0xFE5D,0xC080,0x8A05,0xAD3F,0xBC21,0x4870,0x04F1, 0xDF63,0xC177,0x75AF,0x6342,0x3020,0x1AE5,0x0EFD,0x6DBF, 0x4C81,0x1418,0x3526,0x2FC3,0xE1BE,0xA235,0xCC88,0x392E, 0x5793,0xF255,0x82FC,0x477A,0xACC8,0xE7BA,0x2B32,0x95E6, 0xA0C0,0x9819,0xD19E,0x7FA3,0x6644,0x7E54,0xAB3B,0x830B, 0xCA8C,0x29C7,0xD36B,0x3C28,0x79A7,0xE2BC,0x1D16,0x76AD, 0x3BDB,0x5664,0x4E74,0x1E14,0xDB92,0x0A0C,0x6C48,0xE4B8, 0x5D9F,0x6EBD,0xEF43,0xA6C4,0xA839,0xA431,0x37D3,0x8BF2, 0x32D5,0x438B,0x596E,0xB7DA,0x8C01,0x64B1,0xD29C,0xE049, 0xB4D8,0xFAAC,0x07F3,0x25CF,0xAFCA,0x8EF4,0xE947,0x1810, 0xD56F,0x88F0,0x6F4A,0x725C,0x2438,0xF157,0xC773,0x5197, 0x23CB,0x7CA1,0x9CE8,0x213E,0xDD96,0xDC61,0x860D,0x850F, 0x90E0,0x427C,0xC471,0xAACC,0xD890,0x0506,0x01F7,0x121C, 0xA3C2,0x5F6A,0xF9AE,0xD069,0x9117,0x5899,0x273A,0xB927, 0x38D9,0x13EB,0xB32B,0x3322,0xBBD2,0x70A9,0x8907,0xA733, 0xB62D,0x223C,0x9215,0x20C9,0x4987,0xFFAA,0x7850,0x7AA5, 0x8F03,0xF859,0x8009,0x171A,0xDA65,0x31D7,0xC684,0xB8D0, 0xC382,0xB029,0x775A,0x111E,0xCB7B,0xFCA8,0xD66D,0x3A2C, } }; #if DO_SANITY_CHECK /* ********************************************************************** * Routine: SanityCheckTable -- verify Sbox properties * * Inputs: Sbox * Output: None, but an assertion fails if the tables are wrong * Notes: * The purpose of this routine is solely to illustrate and 3397 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications * verify the following properties of the Sbox table: * - the Sbox is a "2x2" subset of the AES table: * Sbox + affine transform + MDS. * - the Sbox table can be easily designed to fit in a * 512-byte table, using a byte swap * - the Sbox table can be easily designed to fit in a * 256-byte table, using some shifts and a byte swap ********************************************************************** */ void SanityCheckTable(void) { const static int M_x = 0x11B; /* AES irreducible polynomial */ const static byte Sbox8[256] = { /* AES 8-bit Sbox */ 0x63,0x7c,0x77,0x7b,0xf2,0x6b,0x6f,0xc5, 0x30,0x01,0x67,0x2b,0xfe,0xd7,0xab,0x76, 0xca,0x82,0xc9,0x7d,0xfa,0x59,0x47,0xf0, 0xad,0xd4,0xa2,0xaf,0x9c,0xa4,0x72,0xc0, 0xb7,0xfd,0x93,0x26,0x36,0x3f,0xf7,0xcc, 0x34,0xa5,0xe5,0xf1,0x71,0xd8,0x31,0x15, 0x04,0xc7,0x23,0xc3,0x18,0x96,0x05,0x9a, 0x07,0x12,0x80,0xe2,0xeb,0x27,0xb2,0x75, 0x09,0x83,0x2c,0x1a,0x1b,0x6e,0x5a,0xa0, 0x52,0x3b,0xd6,0xb3,0x29,0xe3,0x2f,0x84, 0x53,0xd1,0x00,0xed,0x20,0xfc,0xb1,0x5b, 0x6a,0xcb,0xbe,0x39,0x4a,0x4c,0x58,0xcf, 0xd0,0xef,0xaa,0xfb,0x43,0x4d,0x33,0x85, 0x45,0xf9,0x02,0x7f,0x50,0x3c,0x9f,0xa8, 0x51,0xa3,0x40,0x8f,0x92,0x9d,0x38,0xf5, 0xbc,0xb6,0xda,0x21,0x10,0xff,0xf3,0xd2, 0xcd,0x0c,0x13,0xec,0x5f,0x97,0x44,0x17, 0xc4,0xa7,0x7e,0x3d,0x64,0x5d,0x19,0x73, 0x60,0x81,0x4f,0xdc,0x22,0x2a,0x90,0x88, 0x46,0xee,0xb8,0x14,0xde,0x5e,0x0b,0xdb, 0xe0,0x32,0x3a,0x0a,0x49,0x06,0x24,0x5c, 0xc2,0xd3,0xac,0x62,0x91,0x95,0xe4,0x79, 0xe7,0xc8,0x37,0x6d,0x8d,0xd5,0x4e,0xa9, 0x6c,0x56,0xf4,0xea,0x65,0x7a,0xae,0x08, 0xba,0x78,0x25,0x2e,0x1c,0xa6,0xb4,0xc6, 0xe8,0xdd,0x74,0x1f,0x4b,0xbd,0x8b,0x8a, 0x70,0x3e,0xb5,0x66,0x48,0x03,0xf6,0x0e, 0x61,0x35,0x57,0xb9,0x86,0xc1,0x1d,0x9e, 0xe1,0xf8,0x98,0x11,0x69,0xd9,0x8e,0x94, 0x9b,0x1e,0x87,0xe9,0xce,0x55,0x28,0xdf, 0x8c,0xa1,0x89,0x0d,0xbf,0xe6,0x42,0x68, 0x41,0x99,0x2d,0x0f,0xb0,0x54,0xbb,0x16 }; 3398 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications int i,k,k2,k3; byte bitmap[0x2000]; /* show that smaller tables can be used */ for (i=0;i<256;i++) { k = Sbox8[i]; k2 = (k << 1) ^ ((k & 0x80) ? M_x : 0); k3 = k ^ k2; assert(Sbox[0][i] == ((k2 << 8) ^ k3)); assert(Sbox[1][i] == ((k3 << 8) ^ k2)); } /* now make sure that it's a 16-bit permutation */ memset(bitmap,0,sizeof(bitmap)); for (i=0;i<0x10000;i++) { k = _S_(i); /* do an S-box lookup: 16 --> 16 bits */ assert(k < (1 << 16)); assert((bitmap[k >> 3] & (1 << (k & 7))) == 0); bitmap[k >> 3] |= 1 << (k & 7); } for (i=0;i> 1); /* Copy 96 bits of PPK[0..5] to ARC4KEY[4..15] (little-endian) */ for (i=0;i<6;i++) { ARC4KEY[4+2*i] = Lo8(PPK[i]); ARC4KEY[5+2*i] = Hi8(PPK[i]); } } /* 3401 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications ********************************************************************** * Routine: doTestCase -- execute a test case, and print results ********************************************************************** */ void DoTestCase(byte *ARC4KEY,u32b IV32,u16b IV16,const byte *TA,const byte *TK) { int i; u16b P1K[P1K_SIZE/2]; /* "temp" copy of phase1 key */ printf("\nTK ="); for (i=0;i> (24-8*i)) & 0xFF); printf("]"); printf("\nIV16 = %04X",IV16); Phase1(P1K,TK,TA,IV32); printf("\nP1K ="); for (i=0;i #include #include #include #include "Michael.h" // Rotation functions on 32 bit values #define ROL32( A, n ) \ ( ((A) << (n)) | ( ((A)>>(32-(n))) & ( (1UL << (n)) - 1 ) ) ) #define ROR32( A, n ) ROL32( (A), 32-(n) ) UInt32 Michael::getUInt32( Byte * p ) // Convert from Byte[] to UInt32 in a portable way { UInt32 res = 0; for( int i=0; i<4; i++ ) { res |= (*p++) << (8*i); } return res; } void Michael::putUInt32( Byte * p, UInt32 val ) // Convert from UInt32 to Byte[] in a portable way { for( int i=0; i<4; i++ ) { *p++ = (Byte) (val & 0xff); val >>= 8; } } void Michael::clear() { // Reset the state to the empty message. L = K0; R = K1; 3410 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications nBytesInM = 0; M = 0; } void Michael::setKey( Byte * key ) { // Set the key K0 = getUInt32( key ); K1 = getUInt32( key + 4 ); // and reset the message clear(); } Michael::Michael( Byte * key ) { setKey( key ); } Michael::~Michael() { // Wipe the key material K0 = 0; K1 = 0; // And the other fields as well. //Note that this sets (L,R) to (K0,K1) which is just fine. clear(); } void Michael::appendByte( Byte b ) { // Append the byte to our word-sized buffer M |= b << (8*nBytesInM); nBytesInM++; // Process the word if it is full. if( nBytesInM >= 4 ) { L ^= M; R ^= ROL32( L, 17 ); L += R; R ^= ((L & 0xff00ff00) >> 8) | ((L & 0x00ff00ff) << 8); L += R; R ^= ROL32( L, 3 ); L += R; R ^= ROR32( L, 2 ); L += R; 3411 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications // Clear the buffer M = 0; nBytesInM = 0; } } void Michael::append( Byte * src, int nBytes ) { // This is simple while( nBytes > 0 ) { appendByte( *src++ ); nBytes--; } } void Michael::getMIC( Byte * dst ) { // Append the minimum padding appendByte( 0x5a ); appendByte( 0 ); appendByte( 0 ); appendByte( 0 ); appendByte( 0 ); // and then 0s until the length is a multiple of 4 while( nBytesInM != 0 ) { appendByte( 0 ); } // The appendByte function has already computed the result. putUInt32( dst, L ); putUInt32( dst+4, R ); // Reset to the empty message. clear(); } void Michael::hexToBin( char *src, Byte * dst ) { // Simple wrapper hexToBin( src, strlen( src ), dst ); } void Michael::hexToBin( char *src, int nChars, Byte * dst ) { assert( (nChars & 1) == 0 ); int nBytes = nChars/2; 3412 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications // Straightforward conversion for( int i=0; i #define USE_VECTOR_1 // Use test vector #1 as GCMP input // #define USE_VECTOR_2 // Use test vector #2 as GCMP input // Prototype int tcSubWord(int x); int tcSubByte(int x); void tcAESfunc(int StartofRound[4], int RoundKey[44]); void tcKeyExpansion(int x[4], int RoundKey[44]); void tcAdjustText(int move, int data[4]); int tcMixColumns(int x); int tcMultEight(int x, int y); void tcMultGF(int x[4], int y[4], int Zout[4]); int main(void) { // Function parameter int i, j, temp[4]; int Nr = 16; // 256-octet * 8-bit / 128-bit // Input for main int ENCDEC=1; // Indication of Encryption and Decryption: 1 Enc 0 Dec #ifdef USE_VECTOR_1 // Input for GCMP test vector #1 // Key for system 128-bit int Key[4]={0xaaaaaaaa, 0xaaaaaaaa, 0xaaaaaaaa, 0xaaaaaaaa}; // Initialization Vector 96-bit + 1 (32-bit) int IV[4]={0xffffffff, 0xffff0000, 0x00000001, 0x00000001}; // Additional Authenticated Data int AAD[2][4]={{0x20020000, 0x00000000, 0xffffffff, 0xffffffff}, {0xffffffff, 0x00000000, 0x00000000, 0x00000000}}; // FC, A1=0s, A2=Fs, A3=Fs // Length of AAD and Cipher Text int LENAC[4]={0x00000000, 0x000000b0, 0x00000000, 0x00000800}; #endif // USE_VECTOR_1 #ifdef USE_VECTOR_2 // Input for GCMP test vector #2 (see also plaintext input below) // Key for system 128-bit int Key[4]={0xc97c1f67, 0xce371185, 0x514a8a19, 0xf2bdd52f}; // Initialization Vector 96-bit + 1 (32-bit) int IV[4]={0x5030f184, 0x44080089, 0x5f5f2b08, 0x00000001}; // 88 40 0f d2 e1 28 a5 7c 50 30 f1 84 44 08 50 30 f1 84 44 08 00 00 03 00 // Additional Authenticated Data int AAD[2][4]={{0x88400fd2, 0xe128a57c, 0x5030f184, 0x44085030}, {0xf1844408, 0x00000300, 0x00000000, 0x00000000}}; // FC, A1=0f-d2-e1-28-a5-7c, // A2=50-30-f1-84-44-08, A3=50-30-f1-84-44-08 // Length of AAD and Cipher Text 3433 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications int LENAC[4]={0x00000000, 0x000000c0, 0x00000000, 0x00000140}; #endif // USE_VECTOR_2 int TextIn[16][4]; // AES parameter // Round Keys, Generated by Input Keys and use for AES int RoundKey[44]; // Input/output of AES function int StartofRound[4]; // HASH output, AES function with 0s input int HASH[4]; // First output of AES function with Y0 input, // which uses for generating Tag int EKY0[4]; // Output Text, which is either Cipher/Plain text. // Length should much with TextIn int TextOut[16][4]; // GF parameter int MultIn[4]; // Input of Multiplication int Tag[4] = {0, 0, 0, 0};// Tag output // Processing Parameter int p_flag = 1; // Indication of end of process int LengthTxt[2]; // Block length of text that is Plain/Cipher Text int TxtRemain; // The last block of text, range is between 0 to 127 int Txt_flag = 0; // Indication of last text is not 128-bit // ===== Main Process ===== // Generate 1500 Octets '0' Text for (i=0;i> 7; if ((LENAC[3] & 0x0000007f) == 0) { LengthTxt[1] = LENAC[3] >> 7; } else { LengthTxt[1] = (LENAC[3] >> 7) + 1; TxtRemain = LENAC[3] & 0x0000007F; Txt_flag = 1; } // Generate HASH, which uses for GF(2^128) function // AES function with 0s input for (i=0;i<4;i++) { StartofRound[i] = 0; } tcAESfunc(StartofRound, RoundKey); for (i=0;i<4;i++) { HASH[i] = StartofRound[i]; } // GF 2^128 with AAD for (i=0;i<2;i++) { for (j=0;j<4;j++) { MultIn[j] = AAD[i][j] ^ Tag[j]; } tcMultGF(HASH, MultIn, Tag); } // Generate Encryption Key and Tag // AES function with Yi input to generate Encryption Keys // First output for which Y0 input is used for generating Tag i = 0; while (p_flag) { // Set IV as a Input of AES for (j=0;j<4;j++) { StartofRound[j] = IV[j]; } // AES function tcAESfunc(StartofRound, RoundKey); printf("AES Number %02d is %08x %08x %08x %08x\n", i, StartofRound[0], StartofRound[1], StartofRound[2], StartofRound[3]); // Increment IV by '1' IV[3] = IV[3] + 1; // Set EKY0 for Tag if (i == 0) { for (j=0;j<4;j++) { EKY0[j] = StartofRound[j]; } } // Xor Input Text and Encryption Keys // Check the last Block of processing else if (LengthTxt[1] == 0) { if (LengthTxt[0] == 0) { p_flag = 0; for (j=0;j<4;j++) { TextOut[i-1][j] = TextIn[i-1][j] ^ 3435 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications StartofRound[j]; } // Adjust the length textout for (j=0;j<4;j++) { temp[j] = TextOut[i-1][j]; } if (Txt_flag == 1) { tcAdjustText(TxtRemain, temp); } for (j=0;j<4;j++) { TextOut[i-1][j] = temp[j]; } // XOR with last text and former Tag for (j=0;j<4;j++) { if (ENCDEC == 1) { MultIn[j] = TextOut[i-1][j] ^ Tag[j]; } else { MultIn[j] = TextIn[i-1][j] ^ Tag[j]; } } tcMultGF(HASH, MultIn, Tag); } else { LengthTxt[0]--; LengthTxt[1]--; for (j=0;j<4;j++) { TextOut[i-1][j] = TextIn[i-1][j] ^ StartofRound[j]; if (ENCDEC == 1) { MultIn[j] = TextOut[i-1][j] ^ Tag[j]; } else { MultIn[j] = TextIn[i-1][j] ^ Tag[j]; } } tcMultGF(HASH, MultIn, Tag); } } else { for (j=0;j<4;j++) { TextOut[i-1][j] = TextIn[i-1][j] ^ StartofRound[j]; if (ENCDEC == 1) { MultIn[j] = TextOut[i-1][j] ^ Tag[j]; } else { MultIn[j] = TextIn[i-1][j] ^ Tag[j]; } } tcMultGF(HASH, MultIn, Tag); } i++; LengthTxt[1]--; } // Generate Tag // 1. XOR with LENAC and Tag for (j=0;j<4;j++) { MultIn[j] = LENAC[j] ^ Tag[j]; } 3436 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications // 2. GF(2^128) tcMultGF(HASH, MultIn, Tag); // 3. XOR with EKY0 and Tag for (j=0;j<4;j++) { Tag[j] = EKY0[j] ^ Tag[j]; } // Display for (i=0;i>24) & 0x000000FF); AfterSubWord = tcSubWord(AfterRotWord); AfterXorWithRcon = AfterSubWord ^ Rcon[i/4-1]; RoundKey[i] = RoundKey[i-4] ^ AfterXorWithRcon; } else { RoundKey[i] = RoundKey[i-4] ^ RoundKey[i-1]; 3438 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications } } } // Adjust the Plain/Cipher Text Size if it is not multiply by 128-bit void tcAdjustText(int move, int data[4]) { int i; // Move to MSB -> LSB i = 128 - move; while (i) { data[3] = ((data[3] >> 1) & 0x7FFFFFFF) ^ ((data[2] << 31) & 0x80000000); data[2] = ((data[2] >> 1) & 0x7FFFFFFF) ^ ((data[1] << 31) & 0x80000000); data[1] = ((data[1] >> 1) & 0x7FFFFFFF) ^ ((data[0] << 31) & 0x80000000); data[0] = (data[0] >> 1) & 0x7FFFFFFF; i--; } // Move to LSB -> MSB i = 128 - move; while (i) { data[0] = ((data[0] << 1) & 0xFFFFFFFE) ^ ((data[1] >> 31) & 0x00000001); data[1] = ((data[1] << 1) & 0xFFFFFFFE) ^ ((data[2] >> 31) & 0x00000001); data[2] = ((data[2] << 1) & 0xFFFFFFFE) ^ ((data[3] >> 31) & 0x00000001); data[3] = (data[3] << 1) & 0xFFFFFFFE; i--; } } // 32-bit SubByte function int tcSubWord(int x) { int r = 0; int i; int temp; for (i=0;i<4;i++) { temp = (x >> i*8) & 0xFF; r = r ^ tcSubByte(temp) << i*8; } return r; } // S-Box Lookup Table int tcSubByte(int x) { int r; switch(x) { case 0x00 : r = 0x63; break; case 0x01 : r = 0x7c; break; case 0x02 : r = 0x77; break; case 0x03 : r = 0x7b; break; case 0x04 : r = 0xf2; break; case 0x05 : r = 0x6b; break; case 0x06 : r = 0x6f; break; 3439 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications case 0x07 : r = 0xc5; break; case 0x08 : r = 0x30; break; case 0x09 : r = 0x01; break; case 0x0A : r = 0x67; break; case 0x0B : r = 0x2b; break; case 0x0C : r = 0xfe; break; case 0x0D : r = 0xd7; break; case 0x0E : r = 0xab; break; case 0x0F : r = 0x76; break; case 0x10 : r = 0xca; break; case 0x11 : r = 0x82; break; case 0x12 : r = 0xc9; break; case 0x13 : r = 0x7d; break; case 0x14 : r = 0xfa; break; case 0x15 : r = 0x59; break; case 0x16 : r = 0x47; break; case 0x17 : r = 0xf0; break; case 0x18 : r = 0xad; break; case 0x19 : r = 0xd4; break; case 0x1A : r = 0xa2; break; case 0x1B : r = 0xaf; break; case 0x1C : r = 0x9c; break; case 0x1D : r = 0xa4; break; case 0x1E : r = 0x72; break; case 0x1F : r = 0xc0; break; case 0x20 : r = 0xb7; break; case 0x21 : r = 0xfd; break; case 0x22 : r = 0x93; break; case 0x23 : r = 0x26; break; case 0x24 : r = 0x36; break; case 0x25 : r = 0x3f; break; case 0x26 : r = 0xf7; break; case 0x27 : r = 0xcc; break; case 0x28 : r = 0x34; break; case 0x29 : r = 0xa5; break; case 0x2A : r = 0xe5; break; case 0x2B : r = 0xf1; break; case 0x2C : r = 0x71; break; case 0x2D : r = 0xd8; break; case 0x2E : r = 0x31; break; case 0x2F : r = 0x15; break; case 0x30 : r = 0x04; break; case 0x31 : r = 0xc7; break; case 0x32 : r = 0x23; break; case 0x33 : r = 0xc3; break; case 0x34 : r = 0x18; break; case 0x35 : r = 0x96; break; case 0x36 : r = 0x05; break; case 0x37 : r = 0x9a; break; case 0x38 : r = 0x07; break; case 0x39 : r = 0x12; break; case 0x3A : r = 0x80; break; case 0x3B : r = 0xe2; break; case 0x3C : r = 0xeb; break; case 0x3D : r = 0x27; break; case 0x3E : r = 0xb2; break; case 0x3F : r = 0x75; break; case 0x40 : r = 0x09; break; case 0x41 : r = 0x83; break; 3440 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications case 0x42 : r = 0x2c; break; case 0x43 : r = 0x1a; break; case 0x44 : r = 0x1b; break; case 0x45 : r = 0x6e; break; case 0x46 : r = 0x5a; break; case 0x47 : r = 0xa0; break; case 0x48 : r = 0x52; break; case 0x49 : r = 0x3b; break; case 0x4A : r = 0xd6; break; case 0x4B : r = 0xb3; break; case 0x4C : r = 0x29; break; case 0x4D : r = 0xe3; break; case 0x4E : r = 0x2f; break; case 0x4F : r = 0x84; break; case 0x50 : r = 0x53; break; case 0x51 : r = 0xd1; break; case 0x52 : r = 0x00; break; case 0x53 : r = 0xed; break; case 0x54 : r = 0x20; break; case 0x55 : r = 0xfc; break; case 0x56 : r = 0xb1; break; case 0x57 : r = 0x5b; break; case 0x58 : r = 0x6a; break; case 0x59 : r = 0xcb; break; case 0x5A : r = 0xbe; break; case 0x5B : r = 0x39; break; case 0x5C : r = 0x4a; break; case 0x5D : r = 0x4c; break; case 0x5E : r = 0x58; break; case 0x5F : r = 0xcf; break; case 0x60 : r = 0xd0; break; case 0x61 : r = 0xef; break; case 0x62 : r = 0xaa; break; case 0x63 : r = 0xfb; break; case 0x64 : r = 0x43; break; case 0x65 : r = 0x4d; break; case 0x66 : r = 0x33; break; case 0x67 : r = 0x85; break; case 0x68 : r = 0x45; break; case 0x69 : r = 0xf9; break; case 0x6A : r = 0x02; break; case 0x6B : r = 0x7f; break; case 0x6C : r = 0x50; break; case 0x6D : r = 0x3c; break; case 0x6E : r = 0x9f; break; case 0x6F : r = 0xa8; break; case 0x70 : r = 0x51; break; case 0x71 : r = 0xa3; break; case 0x72 : r = 0x40; break; case 0x73 : r = 0x8f; break; case 0x74 : r = 0x92; break; case 0x75 : r = 0x9d; break; case 0x76 : r = 0x38; break; case 0x77 : r = 0xf5; break; case 0x78 : r = 0xbc; break; case 0x79 : r = 0xb6; break; case 0x7A : r = 0xda; break; case 0x7B : r = 0x21; break; case 0x7C : r = 0x10; break; 3441 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications case 0x7D : r = 0xff; break; case 0x7E : r = 0xf3; break; case 0x7F : r = 0xd2; break; case 0x80 : r = 0xcd; break; case 0x81 : r = 0x0c; break; case 0x82 : r = 0x13; break; case 0x83 : r = 0xec; break; case 0x84 : r = 0x5f; break; case 0x85 : r = 0x97; break; case 0x86 : r = 0x44; break; case 0x87 : r = 0x17; break; case 0x88 : r = 0xc4; break; case 0x89 : r = 0xa7; break; case 0x8A : r = 0x7e; break; case 0x8B : r = 0x3d; break; case 0x8C : r = 0x64; break; case 0x8D : r = 0x5d; break; case 0x8E : r = 0x19; break; case 0x8F : r = 0x73; break; case 0x90 : r = 0x60; break; case 0x91 : r = 0x81; break; case 0x92 : r = 0x4f; break; case 0x93 : r = 0xdc; break; case 0x94 : r = 0x22; break; case 0x95 : r = 0x2a; break; case 0x96 : r = 0x90; break; case 0x97 : r = 0x88; break; case 0x98 : r = 0x46; break; case 0x99 : r = 0xee; break; case 0x9A : r = 0xb8; break; case 0x9B : r = 0x14; break; case 0x9C : r = 0xde; break; case 0x9D : r = 0x5e; break; case 0x9E : r = 0x0b; break; case 0x9F : r = 0xdb; break; case 0xA0 : r = 0xe0; break; case 0xA1 : r = 0x32; break; case 0xA2 : r = 0x3a; break; case 0xA3 : r = 0x0a; break; case 0xA4 : r = 0x49; break; case 0xA5 : r = 0x06; break; case 0xA6 : r = 0x24; break; case 0xA7 : r = 0x5c; break; case 0xA8 : r = 0xc2; break; case 0xA9 : r = 0xd3; break; case 0xAA : r = 0xac; break; case 0xAB : r = 0x62; break; case 0xAC : r = 0x91; break; case 0xAD : r = 0x95; break; case 0xAE : r = 0xe4; break; case 0xAF : r = 0x79; break; case 0xB0 : r = 0xe7; break; case 0xB1 : r = 0xc8; break; case 0xB2 : r = 0x37; break; case 0xB3 : r = 0x6d; break; case 0xB4 : r = 0x8d; break; case 0xB5 : r = 0xd5; break; case 0xB6 : r = 0x4e; break; case 0xB7 : r = 0xa9; break; 3442 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications case 0xB8 : r = 0x6c; break; case 0xB9 : r = 0x56; break; case 0xBA : r = 0xf4; break; case 0xBB : r = 0xea; break; case 0xBC : r = 0x65; break; case 0xBD : r = 0x7a; break; case 0xBE : r = 0xae; break; case 0xBF : r = 0x08; break; case 0xC0 : r = 0xba; break; case 0xC1 : r = 0x78; break; case 0xC2 : r = 0x25; break; case 0xC3 : r = 0x2e; break; case 0xC4 : r = 0x1c; break; case 0xC5 : r = 0xa6; break; case 0xC6 : r = 0xb4; break; case 0xC7 : r = 0xc6; break; case 0xC8 : r = 0xe8; break; case 0xC9 : r = 0xdd; break; case 0xCA : r = 0x74; break; case 0xCB : r = 0x1f; break; case 0xCC : r = 0x4b; break; case 0xCD : r = 0xbd; break; case 0xCE : r = 0x8b; break; case 0xCF : r = 0x8a; break; case 0xD0 : r = 0x70; break; case 0xD1 : r = 0x3e; break; case 0xD2 : r = 0xb5; break; case 0xD3 : r = 0x66; break; case 0xD4 : r = 0x48; break; case 0xD5 : r = 0x03; break; case 0xD6 : r = 0xf6; break; case 0xD7 : r = 0x0e; break; case 0xD8 : r = 0x61; break; case 0xD9 : r = 0x35; break; case 0xDA : r = 0x57; break; case 0xDB : r = 0xb9; break; case 0xDC : r = 0x86; break; case 0xDD : r = 0xc1; break; case 0xDE : r = 0x1d; break; case 0xDF : r = 0x9e; break; case 0xE0 : r = 0xe1; break; case 0xE1 : r = 0xf8; break; case 0xE2 : r = 0x98; break; case 0xE3 : r = 0x11; break; case 0xE4 : r = 0x69; break; case 0xE5 : r = 0xd9; break; case 0xE6 : r = 0x8e; break; case 0xE7 : r = 0x94; break; case 0xE8 : r = 0x9b; break; case 0xE9 : r = 0x1e; break; case 0xEA : r = 0x87; break; case 0xEB : r = 0xe9; break; case 0xEC : r = 0xce; break; case 0xED : r = 0x55; break; case 0xEE : r = 0x28; break; case 0xEF : r = 0xdf; break; case 0xF0 : r = 0x8c; break; case 0xF1 : r = 0xa1; break; case 0xF2 : r = 0x89; break; 3443 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications case 0xF3 : r = 0x0d; break; case 0xF4 : r = 0xbf; break; case 0xF5 : r = 0xe6; break; case 0xF6 : r = 0x42; break; case 0xF7 : r = 0x68; break; case 0xF8 : r = 0x41; break; case 0xF9 : r = 0x99; break; case 0xFA : r = 0x2d; break; case 0xFB : r = 0x0f; break; case 0xFC : r = 0xb0; break; case 0xFD : r = 0x54; break; case 0xFE : r = 0xbb; break; case 0xFF : r = 0x16; break; default : r = 0x00; printf("S-BOX Error!!"); break; } return r; } // MixColumns function for AES int tcMixColumns(int x) { int r; int s0, s1, s2, s3; s0 = (tcMultEight(0x02,(x>>24) & 0xFF))^ (tcMultEight(0x03,(x>>16) & 0xFF))^ ((x>>8) & 0xFF)^ (x & 0xFF); s1 = ((x>>24) & 0xFF)^ (tcMultEight(0x02,(x>>16) & 0xFF))^ (tcMultEight(0x03,(x>>8) & 0xFF))^ (x & 0xFF); s2 = ((x>>24) & 0xFF)^ ((x>>16) & 0xFF)^ (tcMultEight(0x02,(x>>8) & 0xFF))^ (tcMultEight(0x03,x & 0xFF)); s3 = (tcMultEight(0x03,(x>>24) & 0xFF))^ ((x>>16) & 0xFF)^ ((x>>8) & 0xFF)^ (tcMultEight(0x02,x & 0xFF)); r = ((s0<<24) & 0xFF000000) ^ ((s1<<16) & 0x00FF0000) ^ ((s2<<8) & 0x0000FF00) ^ (s3 & 0x000000FF); return r; } // Multiplication in GF(2^8) int tcMultEight(int x, int y) { int r = 0x1b; int i, z = 0; int y_flag = 0; for (i=0;i<8;i++) { if (((x>>i) & 1) == 1) { z = z ^ y; } if (((y >> 7) & 1) == 1) { y_flag = 1; } y = (y << 1) & 0xFF; if (y_flag == 1) { y = y ^ r; } y_flag = 0; } return z; } 3444 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications // Multiplication in GF(2^128) void tcMultGF(int x[4], int y[4], int Zout[4]) { int i,j,k=0; int r[4] = {0xe1000000, 0x00000000, 0x00000000, 0x00000000}; int z[4] = {0x00000000, 0x00000000, 0x00000000, 0x00000000}; int V[4]; for (i=0;i<4;i++) { V[i] = x[i]; } for (i=0;i<4;i++) { for (j=0;j<32;j++) { if (((y[i]>>(31-j)) & 1) == 1) { for (k=0;k<4;k++) { z[k] = z[k] ^ V[k]; } } if ((V[3] & 1) == 0) { V[3] = ((V[3] >> 1) & 0x7fffffff) ^ ((V[2] << 31) & 0x80000000); V[2] = ((V[2] >> 1) & 0x7fffffff) ^ ((V[1] << 31) & 0x80000000); V[1] = ((V[1] >> 1) & 0x7fffffff) ^ ((V[0] << 31) & 0x80000000); V[0] = ((V[0] >> 1) & 0x7fffffff); } else { V[3] = ((V[3] >> 1) & 0x7fffffff) ^ ((V[2] << 31) & 0x80000000); V[2] = ((V[2] >> 1) & 0x7fffffff) ^ ((V[1] << 31) & 0x80000000); V[1] = ((V[1] >> 1) & 0x7fffffff) ^ ((V[0] << 31) & 0x80000000); V[0] = ((V[0] >> 1) & 0x7fffffff); for (k=0;k<4;k++) { V[k] = V[k] ^ r[k]; } } } } for (i=0;i<4;i++) { Zout[i] = z[i]; } } 3445 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Annex K (informative) TSPECs and Admission control K.1 Example use of TSPEC for admission control Admission control, in general, depends on vendorsâ€™ implementations of schedulers, available channel capacity, link conditions, retransmission limits, and the scheduling requirements of a given TSPEC. However, for any given channel capacity, link conditions, and retransmission limits, some TSPEC constructions might be categorically rejected because a scheduler cannot create a meaningful schedule for that TSPEC. There needs to be, for example, be a minimum number of specified fields in the TSPEC in order for the admission control mechanism to create a valid TSPEC. Table K-1 below lists the valid TSPEC fields that need to be present for all admission control algorithms to admit a TSPEC. This represents a set of necessary parameters in order for TSPEC to be admitted; it is not sufficient in and of itself to guarantee TSPEC admittance, which depends upon channel conditions and other factors. Such TSPECs are said to be admissible. In the table, S means specified, X means unspecified, and Opt means â€œoptional.â€ Table K-1â€”Admissible TSPECs Continuous time Controlled-access Bursty traffic Contention based TSPEC parameter QoS traffic CBR traffic (HCCA) traffic (EDCA) (HCCA) (HCCA) Nominal MSDU S S X S Size Minimum Nominal MSDU S Service Interval size/mean data rate, Usually set to 0 or a S X if specified (VoIP small number (e.g., typically uses this) 1) Maximum Opt Same as Minimum Service Interval S S (Used to indicate SI aggregation limit) Inactivity Always specified X Interval Suspension Interval Opt Minimum Data Rate Specified if peak Equal to mean data Specified if peak X data rate is specified rate data rate is specified Mean Data Rate S S Opt S Burst Size X X S Opt Minimum PHY Always specified Rate Peak Data Rate Opt Opt Should be specified Equal to Mean Data Should be specified Opt if Minimum Data Rate if Minimum Data Rate is specified Rate is specified 3446 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table K-1â€”Admissible TSPECs (continued) Continuous time Controlled-access Bursty traffic Contention based TSPEC parameter QoS traffic CBR traffic (HCCA) traffic (EDCA) (HCCA) (HCCA) Delay Bound S S Opt Opt Surplus Bandwidth Allow- Is specified if the delay bound is present S ance Medium Time (not specified by non-AP STA; only an output from the HC) K.2 Recommendation for implementation of contention based admission control K.2.1 Use of ACM (admission control mandatory) subfield It is recommended that admission control not be required for the access categories AC_BE and AC_BK. The ACM subfield for these categories should be set to 0. The AC parameters chosen by the AP should account for unadmitted traffic in these ACs. When dot11SSPNInterfaceActivated is true, it is recommended that any STA authenticated through an SSPN interface use admission control to access categories AC_VO and AC_VI to produce network utilization consistent with the policy imposed by the SSPN for admission. AC parameters chosen by the AP should further account for any unadmitted traffic in AC_VO and AC_VI that might be reserved for users of a particular SSPN. K.2.2 Deriving medium time An AP should use the following procedure to derive the value of the Medium Time field in its ADDTS Response frame. There are two requirements to consider: 1) the traffic requirements of the application, and 2) the expected error performance of the medium. The application requirements are captured by the following TSPEC fields: Nominal MSDU Size and Mean Data Rate. Note that the Nominal MSDU Size field is the nominal A-MSDU size, where A-MSDU aggregation is employed. The medium requirements are captured by the following TSPEC fields: Surplus Bandwidth Allowance and Minimum PHY Rate. The following formula describes how Medium Time, in units of 32 Âµs periods per second, can be calculated: Medium Time = Surplus Bandwidth Allowance Packets Per Second Frame Exchange Time- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 0x2000 32 where a) if A-MPDU aggregation is not employed (i.e., TS Info Ack Policy = 00 (Normal Acknowledg- ment)): 3447 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Mean Data Size Packets Per Second =--------------------------------------------------------------------- - 8 Nominal MSDU Size Frame Exchange Time = duration (Nominal MPDU Size, Minimum PHY Rate) + SIFS + duration (Ack Size, Ack Rate) Nominal MPDU Size = MAC Header Size + Nominal MSDU Size + Security Encapsulation Size + FCS Size b) if A-MPDU aggregation is employed (i.e., TS Info Ack Policy = 11 (Block Ack)): Mean Data Rate Packets Per Second = ---------------------------------------------------------------------------------------------------------------------------------------- - 8 Nominal MSDU Size Nominal MSDUAggregation Frame Exchange Time = duration (Nominal A-MPDU Size, Minimum PHY Rate) + SIFS + duration (BlockAck Size, BlockAck Rate) Nominal A-MPDU Size = Nominal MSDU Aggregation Ã— Nominal A-MPDU Subframe Size â€“ Padding Size Nominal A-MPDU Subframe Size = MPDU Delimiter Size + MAC Header Size + Nominal MSDU Size + Security Encapsulation Size + FCS Size + Padding Size Padding Size = 3 â€“ (MAC Header Size + Nominal MSDU Size + Security Encapsulation Size + 3) mod 4 and where Sizes are in octets; Rates are in b/s; durations and Times are in Âµs; Surplus Bandwidth Allowance is the unsigned integer value passed MAC Header Size = 26 MPDU Delimiter Size = 4 Security Encapsulation Size = 16 (CCMP), 20 (GCMP and TKIP), 8 (WEP) or 0 (open system) Ack Size = 14 3448 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications BlockAck Size = 32 FCS Size = 4 SIFSIFS = 10 when operating in the 2.4 GHz band, 16 when operating in the 5 GHz band, 3 when operat- ing in the 60 GHz band Ack/BlockAck Rate is the rate used for the Ack/BlockAck frame, given the Minimum PHY Rate, subject to the corresponding multirate rules duration () is the PLME-TXTIME primitive defined in clauses 6.5.5 and 6.5.6 that returns the duration of a PPDU based on the PSDU size and the PHY data rate and PHY employed, e.g., clauses 16.3.4, 17.4.3, 18.5.3.2, 19.4.3 and 20.12.3 Notes: â€” Division does not truncate. â€” Any signal extension is included, even for the acknowledgment frame which ends the frame exchange. â€” If protection frames are used, then they are included in the Frame Exchange Time too. Each frame contributes an additional term: Frame Exchange Time += duration (Protection Frame Size, Protection Frame Rate) + SIFS where RTS Protection Frame Size = 20 CTS Protection Frame Size = 14 Protection Frame Rate is the rate used for the protection frame, given the Minimum PHY Rate, subject to the corresponding multirate and protection rules An AP assumes that a STA will use CTS-to-self protection if an ERP element directs use of protection. â€” The assumption is made that HT Control headers and beamforming frames are not normally used and so their contribution to Medium Time is negligible. â€” The Nominal A-MPDU Subframe Size can be increased by the AP where necessary to account for the Minimum MPDU Start Spacing. For example, if the Minimum PHY Rate is 65 Mb/s and the Minimum MPDU Start Spacing is 16 Âµs then the minimum Nominal A-MPDU Subframe Size is 132 octets (including 2 octets of pad). â€” A STA might request TSPEC fields that would result in violation of other applicable constraints such as the receiverâ€™s maximum A-MSDU or A-MPDU size, any maximum PPDU duration, or, for uplink or bidirectional TSPECs, any nonzero TXOP limit. An AP receiving such a request is likely to reject it. An AP might also reject requests that cannot be satisfied for reasons that the STA is not always aware of, such as, for uplink or bidirectional TSPECs, the APâ€™s maximum Block Ack Buffer Size. â€” Where A-MPDU aggregation is employed, HT-immediate Block Ack is assumed. K.3 Guidelines and reference design for sample scheduler and admission control unit K.3.1 Guidelines for deriving service schedule parameters The HC establishes the SI for each admitted TS for a STA to derive the aggregate minimum SI contained in the STAâ€™s service schedule. The SI for each TS is equal to the maximum SI contained in the TSPEC, if it 3449 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications exists; otherwise, it is the nominal MSDU size divided by the mean data rate. The SI contained in the service schedule is equal to the smallest SI for any TSPEC. The HC can use an aggregate â€œtoken bucket specificationâ€ to police a STAâ€™s admitted flows. The HC derives the aggregate mean data rate and aggregate burst size to establish the aggregate token bucket specification. The aggregate mean data rate is equal to the sum of the mean data rates of all of the STAâ€™s admitted TSs. The aggregate burst size is equal to the sum of the burst size of all of the STAâ€™s admitted TSs. An aggregate token bucket is initialized with the aggregate burst size. Tokens are added to the token bucket at the aggregate mean data rate. Alternatively the method of summing TSPECs for statistical multiplexing, as described in T.2.3, can be used. When dot11SSPNInterfaceActivated is true, the HC polices all traffic flows from a non-AP STA authenticated against the maximum authorized data rates stored in the dot11InterworkingTable. Each SSPN- authenticated STA is given a maximum bandwidth allowance by the SSPN for each access category as well as scheduled access. The AP polices the SSPN-authenticated STA traffic flows to the maximum bandwidth allowance provided by the SSPN. K.3.2 Reference design for sample scheduler and admission control unit K.3.2.1 General This subclause provides the guidelines for the design of a simple scheduler and admission control unit (the unit that administers admission policy in the HCâ€™s SME) that meet the minimum performance requirements as specified in 10.22.4.3. The scheduler and admission control unit use the minimum set of mandatory TSPEC fields as specified in 10.22.4.3. K.3.2.2 Sample scheduler This subclause includes the reference design for a sample scheduler. This scheduler uses the mandatory set of TSPEC fields to generate a schedule: Mean Data Rate, Nominal MSDU Size, and Maximum Service Interval or Delay Bound. If both Maximum Service Interval and Delay Bound parameters are specified in the TSPEC, the scheduler uses the Maximum Service Interval parameter for the calculation of the schedule. The schedule generated by the scheduler satisfies the requirements specified in 10.22.4.3. The schedule for an admitted stream is calculated in two steps. The first step is the calculation of the scheduled SI. In the second step, the TXOP duration for a given SI is calculated for the stream. The calculation of the scheduled service interval is done as follows: First, the scheduler calculates the minimum of all maximum SIs for all admitted streams. Let this minimum be m. Second, the scheduler chooses a number lower than m that is a submultiple of the beacon interval. This value is the scheduled SI for all STAs with admitted streams. See Figure K-1. Figure K-1â€”Schedule for stream from STA i For the calculation of the TXOP duration for an admitted stream, the scheduler uses the following parameters: Mean Data Rate and Nominal MSDU Size; and from the negotiated TSPEC, the Scheduled Service Interval calculated above, Physical Transmission Rate, Maximum Allowable Size of MSDU, and 3450 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Overhead. The Physical Transmission Rate is the minimum PHY rate negotiated in the TSPEC. If the minimum PHY rate is not committed in the ADDTS Response frame, the scheduler can use the observed PHY rate as the Physical Transmission Rate. The Overhead includes IFSs, Ack frames and CF-Poll frames. For simplicity, details for the Overhead calculation are omitted in this description. The TXOP duration is calculated as follows: First, the scheduler calculates the number of MSDUs that can arrive at the Mean Data Rate during the SI: SI Ni = ----------------i Li where SI is the Scheduled Service Interval is the Mean Data Rate L is the Nominal MSDU Size Then the scheduler calculates the TXOP duration as the maximum of â€” Time to transmit N i frames at R i and â€” Time to transmit one maximum size MSDU at R i (plus overhead): Ni Li M TXOP i = max (--------------- - + O,----- + O) Ri Ri where R is the Physical Transmission Rate M is the maximum possible size of MSDU O is the Overhead in time units An example is shown in Figure K-1. Stream from STA i is admitted. The beacon interval is 100 ms and the maximum SI for the stream is 60 ms. The scheduler calculates a scheduled SI ( SI ) equal to 50 ms using the steps explained above is this annex. The same process is repeated continuously while the maximum SI for the admitted stream is larger than the current SI. An example is shown in Figure K-2. Figure K-2â€”Schedule for streams from STAs i to k If a new stream is admitted with a maximum SI smaller than the current SI, the scheduler needs to change the current SI to a smaller number than the maximum SI of the newly admitted stream. Therefore, the TXOP duration for the current admitted streams needs also to be recalculated with the new SI. If a stream is dropped, the scheduler might use the time available to resume contention. The scheduler might also choose to move the TXOPs for the STAs following the STA dropped to use the unused time. An example is shown in Figure K-3, when the stream for STA j is removed. However, this option might require the announcement of a new schedule to all STAs. 3451 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Figure K-3â€”Reallocation of TXOPs when a stream is dropped Different modifications can be implemented to improve the performance of the minimum scheduler. For example, a scheduler might generate different scheduled SIs ( SI ) for different STAs, and/or a scheduler might consider accommodating retransmissions while allocating TXOP durations. K.3.2.3 Admission control unit This subclause describes a reference design for an admission control unit (ACU) that administers admission of TS. The ACU uses the same set of parameters that the scheduler uses in K.3.2.2. When a new stream requests admission, the admission control process is done in three steps. First, the ACU calculates the number of MSDUs that arrive at the mean data rate during the scheduled SI. The scheduled SI (SI) is the one that the scheduler calculates for the stream as specified in K.3.2.2. For the calculation of the number of MSDUs, the ACU uses the equation for Ni shown in K.3.2.2. Second, the ACU calculates the TXOP duration that needs to be allocated for the stream. The ACU uses the equation for TXOPi shown in K.3.2.2. Finally, the ACU determines that the stream can be admitted when the following inequality is satisfied: k TXOP k + 1 TXOP i T â€“ T CP ----------------------- -+ ----------------- ------------------ SI SI T i=1 where k is the number of existing streams k+1 is used as index for the newly arriving stream T indicates the beacon interval TCP is the time used for EDCA traffic Subclause 10.22.3.3 requires that the ACU complies with the dot11CAPlimit, i.e., the scheduler does not allocate TXOPs that exceed dot11CAPlimit. The ACU might also consider additional time to allow for retransmissions. The ACU allows admitted streams to have an allocated access to the channel. Any modification can be implemented for the design of the ACU. For example, UP-based ACU is possible by examining the UP field in TSPEC to decide whether to admit, retain, or drop a stream. If the UP is not specified, a default value of 0 is used. If a higher UP stream needs to be serviced, an ACU might drop lower UP streams. K.4 TSPEC construction TSPECs are constructed at the SME from application requirements supplied via the SME and with information specific to the MAC layer. However, in this subclause a description is given of how and where certain parameters can be chosen. The following parameters typically arise from the application: Nominal MSDU Size, Maximum MSDU Size, Minimum Service Interval, Maximum Service Interval, Inactivity Interval, Minimum Data Rate, Mean Data Rate, Burst Size, Peak Data Rate, and Delay Bound. The 3452 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications following parameters are generated locally within the MAC: Minimum PHY Rate and Surplus Bandwidth Allowance, although the Maximum Service Interval and Minimum Service Intervals can be generated within the MLME as well. This subclause describes how the parameters that are typically generated within the MAC can be derived. Note that a TSPEC can also be generated autonomously by the MAC without any initiation by the SME. However, if a TSPEC is generated subsequently by the SME, the TSPEC generated autonomously by the MAC might be overridden (see 11.4.4.5). Typically, TSPEC fields not determined by the application are built upon the assumption that the following exist: â€” A probability p of not transmitting the frame (because it would have exceeded its delay bound) â€” An MSDU length (which can be considered fixed for constant-bit-rate applications) â€” Application throughput and delay requirements â€” A channel model of error, in particular a channel error probability for the (fixed) frame length â€” Possibly country-specific limits on TXOP limits K.4.1 Surplus Bandwidth Allocation Typically, it can be assumed that the scheduler would attempt to schedule TXOPs distributed throughout a small multiple of beacon intervals (if not a single beacon interval). In addition, TXOP limits would typically be chosen to be as short as possible (within the constraints of the minimum PHY rate, acknowledgment policy, and so forth), consistent with the goal of maximizing throughput. In other words, because of overhead, not to mention the requirements for transmitting a single Poll frame, MPDU, and possibly Ack frame, the TXOPs need to be at least of a certain duration. The channel model implies an error ratio and an assumption about dependency (joint probability distribution of channel errors sequentially, i.e., burst error probabilities). For example, if the channel causes errors independently from frame to frame and the error probability is the same for all frames of the same length at all times, this channel would be said to be an independent, identically distributed error channel. With p as the probability of dropping the frame, and pe as the probability of the frame not being transmitted successfully (i.e., either the Data frame or the Ack frame associated with it is in error), let Np be the number of retries required to maintain the probability of dropping the frame to be p. The probability of any given packet being dropped in such a channel after Np retries is given by Np + 1 p drop = p e For example, in such a channel, if pe = 0.1 and pdrop = 10â€“8, then up to seven retries within the delay bound are required, and the scheduler should consider these retransmissions in the cumulative TXOP allocations. The Surplus Bandwidth Allowance (SBA) parameter causes the requesting STA to be allocated a minimum amount of excess time by the scheduler so that the application dropped packet rates are bounded. The probability of not successfully transmitting k packets is given by the cumulative distribution function of the Binomial Distribution. 3453 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The binomial probability mass function is n! k nâ€“k b k n p = ----------------------- p 1 â€“ p k! n â€“ k ! where n is the number of trials p is the probability of success for each trial. The binomial cumulative distribution function is n B k n p = b y n p y=0 Assuming a certain packet error ratio (PER), Pe, the number of extra packets, N, that are required in order to have a probability, Pns, of not successfully transmitting S packets is given: n B S S + N 1 â€“ Pe = b y S + N 1 â€“ Pe y=0 Then SBA = (S+N)/S Now, if just one packet is lost, then the lost packet ratio, LPR, is LPR = 1/(S+N) The condition where Pns < LPR represents a practical point for determining the value of N. Medium Time used for EDCA Admission Control is based upon one second periods and HCCA Medium time, used to aggregate TSPECs (see T.2.3) also uses the one second period. Hence, for each application, S is the number of packets that are desired to be sent in each one second period. For example, consider a voice application: PER, Pe = 0.1 or probability of success is 1 â€“ Pe = 0.9 Number of packets per second, S = 50 Probability of not having 50 successful packets, Pns = 0.87% for N = 13 Lost packet ratio for 1 lost packet, LPR = 1.59% SBA = 1.26 Take the example of a video stream at 380 packets per second (about 4 Mb/s): Number of packets per second, S = 380 Probability of not having 380 successful packets, Pns = 0.2% for N = 64 3454 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Lost packet ratio for 1 lost packet, LPR = 0.23% SBA = 1.168 It can be seen that the value for SBA varies with S, the number of required packets per second. A reasonable estimate for SBA is given by SBA = â€“0.033 ln (S) + 1.37 Table K-2 is a table of SBA for various values of S, and the SBA estimate derived by using the formula above. Table K-2â€”SBA vs Packets/s S Packets/s SBA Estimated SBA 50 1.26 1.241 95 1.221 1.220 190 1.189 1.197 285 1.179 1.183 380 1.168 1.174 475 1.164 1.167 570 1.160 1.161 665 1.156 1.156 760 1.154 1.151 855 1.151 1.147 950 1.151 1.144 1900 1.139 1.121 The values for SBA as shown in Table K-2 are based upon a one second time period and hence are what should be used in the TSEC for EDCA Admission Control. The value used in an HCCA TSPEC might be different, as will now be explained. In an HCCA TSPEC the SBA relates the overhead required in each scheduled period. A voice stream, for example, only sends one packet every 20 ms. Obviously an SBA of 1.26 is meaningless as it does not allow even one retry. To allow just one retry, the minimum SBA is 2.0, Similarly for a video example of say 6 packets per schedule period, to allow at least one retry would require an SBA of (6+1)/6 = 1.167 Hence, for an HCCA TSPEC: Calculate packets per SI: Rm PPSI = ------------------------- - S n 8 SI 3455 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications where Rm is the mean data rate (b/s) Sn is the nominal MDSU size (octets) SI is the service interval (seconds) PPSI + 1 Then Minimum HCCA SBA = MAX SBA ---------------------- . PPSI Table K-3 shows the recommended SBA values for HCCA TSPECs for various video streams. Table K-3â€”Table HCCA SBA for video streams Min HCCA Video, Mb/s Pkts per SI SBA, (1 sec) HCCA SBA SBA 1 1 2.000 1.221 2.000 2 3 1.333 1.189 1.333 3 4 1.250 1.179 1.250 4 6 1.167 1.168 1.168 5 7 1.143 1.164 1.164 6 9 1.111 1.160 1.160 7 10 1.100 1.156 1.156 8 12 1.083 1.154 1.154 9 13 1.077 1.151 1.151 10 15 1.067 1.151 1.151 20 30 1.033 1.139 1.139 In summary, the suggested value for SBA is derived as follows: â€” Calculate Packets per sec, PPS Rm PPS = ------------- - Sn 8 where Rm is the mean data rate (b/s) Sn is the nominal MDSU size (octets) NOTEâ€”Nominal MSDU = MDSU or A-MSDU â€” Calculate SBA SBA = â€“0.033 Ln (PPS) + 1.37 EDCA Admission Control TSPEC and Medium Time calculation uses SBA. For HCCA TSPEC: â€” Calculate packets per SI, PPSI Rm PPSI = ------------------------- - S n 8 SI 3456 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications where Rm is the mean data rate (b/s) Sn is the nominal MDSU size (octets) SI is the service interval (seconds) PPSI + 1 â€” HCCA SBA = MAX SBA ---------------------- PPSI HCCA Medium Time uses SBA in place of HCCA SBA, if different. K.4.2 Minimum and Maximum Service Interval K.4.2.1 Scheduled traffic The HC uses the Maximum Service Interval for the calculation of the schedule. The value of the Minimum Service Interval is an indication that the traffic is CBR or VBR. For CBR traffic the minimum and maximum Service Intervals should be set to the same value. For example, most voice traffic requires a minimum and maximum service interval value of 20 ms. In the case of VBR traffic, such as video, Minimum Service Interval should be set to 0 and the Maximum Service Interval set to the service interval required by the application, e.g., to correspond to the codec that is to be used For example, Maximum Service Interval is set to 16 ms for many real time video applications. K.4.2.2 Use of Maximum Service Interval with Aggregation of Packets Aggregation of MPDUs or MSDUs introduces delay to the packets, but the use of aggregated packets is to be encouraged because of the increased efficiency. In the case of scheduled traffic, the aggregation of packets is such that the number of MSDUs that are aggregated into a single packet (A-MSDU or A-MPDU) does not exceed the scheduling service interval. Consider the following example: â€” Video packet = 1316B (7*188 MPEG2-TS) â€” Nominal MSDU Size = 1364 (octets) â€” Mean Data Rate = 4 Mb/s â€” Maximum Service Interval = 16 ms 6 Nominal MSDUs per SI = 4 10 = 3 --------------------- 1364 8 Hence, to comply with the 16 ms SI, the limit for aggregation is 3, (an A-MSDU of 3 MSDUs, or an A- MPDU consisting of 3 MSDUs). In the case of EDCA Admission Control, where regular scheduling is not used, the value of the Maximum Service Interval is used to indicate the limit of aggregation of nominal MSDUs and the acceptable latency between packets. Using aggregation reduces the Medium Time and Used Time required. For example, assuming a minimum PHY Rate of 39 Mb/s for the example used above, the accurate Medium Time returned by the AP would be 13 783 Âµs. If the AP assumed that A-MPDUs were to be used, then the accurate Medium Time would be 11 681 Âµs, a 15% reduction. Hence, an AP could â€˜forceâ€™ a STA to use aggregation, or alternatively could assume aggregation when it is considering the total traffic as part of its admittance policy. 3457 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Nominal MSDU Size is the size of the MSDU or A-MSDU belonging to the TS. Consider another example: â€” Video packet = 1316B (7*188 MPEG2-TS) â€” Nominal MSDU Size = 4137 (A-MSDU of 3 MSDUs) â€” Mean Data Rate = 10 Mb/s â€” Maximum Service Interval = 16 ms 6 Nominal MSDUs per SI = 10 10 = 4 --------------------- 4137 8 Hence, further aggregation is possible and an A-MPDU consisting of 4 A-MSDUs could be sent and still comply with the latency or SI requirement. Note that the TSPEC is invalid if the Nominal MSDUs per Maximum Service Interval is less than 1. K.4.3 Minimum, Mean, and Peak Data Rate In an HCCA TSPEC, for CBR traffic the Minimum, Mean and Maximum Data Rate fields should contain the same value but it is allowable to just specify the Mean Data Rate noting that the Minimum and Maximum Service Intervals are the same. In an EDCA TSPEC, for CBR traffic the Minimum, Mean and Maximum Data Rate fields should contain the same value but it is allowable to just specify the Mean Data Rate. For VBR traffic it is desirable to populate the Minimum, Mean and Peak data rate fields. If a TSPEC has the Minimum Data Rate (Rmin) and Peak Data Rate (Rmax) fields populated, then the standard deviation of that stream, Ïƒ, can be estimated as: = 0.25 R max â€“ R min If a TSPEC has the Mean Data Rate (Rmean) and Peak Data Rate fields populated, then the standard deviation of that stream, Ïƒ, can be estimated as: = 0.5 R max â€“ R mean ) If there are n streams, the values of the mean Î¼ and standard deviation Ïƒ, of the total stream traffic should be calculated using: = n 2 tot = n This is of particular use to EDCA admission control policy. When summing streams for EDCA Admission Control, the EDCA Overhead Factor needs to be taken into account; see T.2.7. 3458 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Annex L (informative) Examples and sample code for encoding a TIM Partial Virtual Bitmap L.1 Introduction The purpose of this annex is to show an examples of encoding a Partial Virtual Bitmap field of the TIM element, as described in 9.4.2.6. Sample C code is provided in L.3. L.2 Examples The following examples help clarify the use of TIM values, both with and without the multiple BSSID capability. The first example is one in which there are no group addressed MSDUs buffered in the AP but there is traffic for two STAs queued in the AP. STAs with AID 2 and AID 7 have data buffered in the AP. Figure L-1 shows the values of the Bitmap Control and Partial Virtual Bitmap fields that would be part of the TIM element for this example. Figure L-1â€”Partial Virtual Bitmap example #1 The next example is one in which group addressed MSDUs are buffered in the AP as well as traffic for STAs. The DTIM Count field in the TIM element equals 0. STAs with AID 2, AID 7, AID 22 and AID 24 have data buffered in the AP. Figure L-2 shows the values of the Bitmap Control and Partial Virtual Bitmap fields. Another example is one in which group addressed MSDUs are buffered in the AP as well as traffic for STAs. The DTIM Count field in the TIM element equals 0. Only the node with AID 24 has data buffered in the AP. In this example, the Bitmap Offset is used to start the Partial Virtual Bitmap at the third octet. Figure L-3 shows the values of the Bitmap Control and Partial Virtual Bitmap fields. The three examples listed above describe the construction of the Partial Virtual Bitmap when multiple BSSID operation is not supported. The following three examples demonstrate how to construct the Partial Virtual Bitmap, when multiple BSSID operation is supported. 3459 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Bitmap Offset B0 B7 AID 0 1 0 0 0 0 0 0 0 Bitmap Control AID 1 1 0 1 0 0 0 0 1 AID 8 0 0 0 0 0 0 0 0 Partial Virtual Bitmap AID 16 0 0 0 0 0 0 1 0 AID 24 1 0 0 0 0 0 0 0 Figure L-2â€”Partial Virtual Bitmap example #2 Bitmap Offset B0 B7 AID 0 1 1 0 0 0 0 0 0 Bitmap Control AID 16 0 0 0 0 0 0 0 0 AID 24 1 0 0 0 0 0 0 0 Partial Virtual Bitmap Figure L-3â€”Partial Virtual Bitmap example #3 The first example showing multiple BSSID operation is one in which there are eight BSSIDs and the lowest possible AID that can be assigned to any STA in this example is 8. There are no group addressed frames buffered in the AP for any of the eight BSSIDs. However, STAs with AID 9 and AID 11 have an individually addressed frames buffered in the AP. Figure L-4 shows the values of the Bitmap Control and Partial Virtual Bitmap fields that would be part of the TIM element for this example when either Method A or Method B is used. It is noted that Method B reduces to Method A in this example. Figure L-4â€”Partial Virtual Bitmap example #4, Method A and Method B In the next example, there are eight BSSIDs and the lowest possible AID that can be assigned to any STA in this example is 8. There are group addressed frames buffered at the AP for the transmitted BSSID, and the DTIM Count field in the TIM element of the transmitted BSSID is 0. The nontransmitted BSSID with BSSID Index 3 also has the DTIM Count field set to 0 and has buffered group addressed frames. All other nontransmitted BSSIDs have no buffered group addressed frames. In addition, STAs with AID 12, AID 17, 3460 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications AID 22 and AID 24 have data buffered at the AP. Figure L-5 shows the values of the Bitmap Control and Partial Virtual Bitmap fields that would be part of the TIM element for this example when either Method A or Method B is used. It is noted that Method B reduces to Method A in this example. Transmitted BSSID Bitmap Offset group addressed traffic B0 indication/AID 0 B7 1 0 0 0 0 0 0 0 Bitmap Control Nontransmitted BSSID group addressed traffic 1 0 0 1 0 0 0 0 indication AID 8 0 0 0 0 1 0 0 0 Partial Virtual Bitmap AID 16 0 1 0 0 0 0 1 0 AID 24 1 0 0 0 0 0 0 0 Figure L-5â€”Partial Virtual Bitmap example #5, Method A or Method B In the third example, there are sixteen BSSIDs and the lowest possible AID that can be assigned to any STA is 16 (n=4, k=15, see 9.4.2.6. There are no group addressed frames buffered at the AP for the transmitted BSSID, and the DTIM Count field in the TIM element of the transmitted BSSID is 0. The nontransmitted BSSID Index 3 also has the DTIM Count field set to 0 and has group addressed frames buffered at the AP. All other nontransmitted BSSIDs have no buffered group addressed frames. In addition, the STA with AID 39 has individually addressed frames buffered at the AP. Figure L-6 and Figure L-7 show the values of the Bitmap Control and Partial Virtual Bitmap fields that would be part of the TIM element for this example when Method A (N2=4, see 9.4.2.6) and Method B (N0=2, N1=4, N2=4, see 9.4.2.6) are used, respectively. Bitmap Offset (always 0 for Method A) Transmitted BSSID group B0 B7 addressed traffic indication/ AID 0 0 0 0 0 0 0 0 0 Bitmap Control Nontransmitted BSSID group 0 0 0 1 0 0 0 0 addressed traffic indication bits 0 0 0 0 0 0 0 0 AID 16 (begin use of individually addressed 0 0 0 0 0 0 0 0 Partial Virtual Bitmap frame buffering) AID 24 0 0 0 0 0 0 0 0 AID 32 0 0 0 0 0 0 0 1 AID 39 Figure L-6â€”Partial Virtual Bitmap example #6, Method A 3461 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Figure L-7â€”Partial Virtual Bitmap example #6, Method B L.3 Sample C code The following C source code illustrates how to construct the Partial Virtual Bitmap. Because this is an illustration, no efficiency or appropriateness for actual implementation is implied. #include #include #define ADD_TIM_BIT 0 #define REMOVE_TIM_BIT 1 #define TIM_ELEMENT_ID 5 #define TIM_BASE_SIZE 3 /* size of TIM fixed fields */ #define AID_SIZE 2008 /* valid AIDs are numBssids thru 2007 */ #define VBM_SIZE 251 /* size of VBM array = 2008/8 = 251 */ #define MAX_BSSIDS 128 /* maximum possible number of BSSIDs per AP, is a power of 2 */ typedef unsigned char UINT8; typedef unsigned short int UINT16; struct _tim { UINT8 Element_id; UINT8 IELength; UINT8 DtimCount; UINT8 DtimPeriod; UINT8 BitMapControl; UINT8 PartialVirtualBitMap [VBM_SIZE]; }; UINT8 virtualBitMap [VBM_SIZE]; UINT8 mcast_pending [MAX_BSSIDS] = {0}; UINT8 dtimCount [MAX_BSSIDS] = {0}; UINT8 dtimPeriod [MAX_BSSIDS] = {5}; void Build_TIM (struct _tim *Tim, char TIM_method, UINT16 numBssids) { UINT8 octetIndex = 0; UINT8 octetIndex0 = 0; UINT8 octetIndex1 = 0; UINT8 offset = 0; UINT8 lengthOfPartialVirtualBitMap = 0; UINT8 bcast_octet = 0; 3462 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications UINT8 bcast_bit = 0; UINT8 max_bcast_octetIndex = 0; UINT16 bssidIndex = 0; UINT16 N2 = 0; /* Compute the largest octet_index for bcast indication */ max_bcast_octetIndex = (numBssids - 1) / 8; /* Initialize PartialVirtualBitMap */ for (octetIndex = 0; octetIndex < VBM_SIZE; octetIndex++) Tim->PartialVirtualBitMap [octetIndex] = 0; octetIndex = 0; if (numBssids == 1) { /* Find the first nonzero octet in the Partial Virtual Bitmap */ for (octetIndex = 0; ((virtualBitMap [octetIndex] == 0) && (octetIndex < VBM_SIZE)); octetIndex++) /* empty */ ; if (octetIndex < VBM_SIZE) offset = octetIndex & 0xFE; /* Find the last nonzero octet in the Partial Virtual Bitmap */ for (octetIndex = (VBM_SIZE - 1); ((virtualBitMap [octetIndex] == 0) && (octetIndex > 0)); octetIndex--) /* empty */ ; lengthOfPartialVirtualBitMap = octetIndex - offset + 1; Tim->IELength = lengthOfPartialVirtualBitMap + TIM_BASE_SIZE; Tim->BitMapControl = offset; /* Copy the virtual Bitmap octets that are nonzero */ /* Note: A NULL virtualBitMap will still add a single octet of 0 */ for (octetIndex = 0; octetIndex < lengthOfPartialVirtualBitMap; octetIndex++) Tim->PartialVirtualBitMap [octetIndex] = virtualBitMap [offset + octetIndex]; } if (numBssids > 1) { /* Update the broadcast/multicast bits, when numBssids > 1 */ for (bssidIndex = 1; bssidIndex < numBssids; bssidIndex++) { bcast_octet = (bssidIndex >> 3) & 0xff; bcast_bit = 0x01 << (bssidIndex & 0x07); if (mcast_pending [bssidIndex]) virtualBitMap [bcast_octet] |= bcast_bit; else virtualBitMap [bcast_octet] &= ~bcast_bit; } for (octetIndex0 = 0; (octetIndex0 < VBM_SIZE) && (virtualBitMap [octetIndex0] == 0); octetIndex0++) /* empty */ ; /* Partial virtual bitmap (PVB) contains neither bcast nor buffered ucast traffic, PVB is a single all-0 octet */ if (octetIndex0 == VBM_SIZE) { lengthOfPartialVirtualBitMap = 1; offset = 0; Tim->IELength = lengthOfPartialVirtualBitMap + TIM_BASE_SIZE; Tim->BitMapControl = offset; Tim->PartialVirtualBitMap [0] = virtualBitMap [0]; } for (octetIndex1 = (max_bcast_octetIndex + 1); ((octetIndex1 < VBM_SIZE) && (virtualBitMap [octetIndex1] == 0)); octetIndex1++) /* empty */ ; /* PVB only contains bcast indication, no buffered ucast traffic */ if ((octetIndex1 == VBM_SIZE) && (octetIndex0 < VBM_SIZE)) 3463 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications { lengthOfPartialVirtualBitMap = max_bcast_octetIndex + 1; offset = 0; Tim->IELength = lengthOfPartialVirtualBitMap + TIM_BASE_SIZE; Tim->BitMapControl = offset; for (octetIndex = 0; octetIndex < (max_bcast_octetIndex + 1); octetIndex++) /* empty */ ; Tim->PartialVirtualBitMap [octetIndex] = virtualBitMap [octetIndex]; } /* PVB contains ucast indication with or without buffered bcast traffic */ for (octetIndex = 0; octetIndex < (max_bcast_octetIndex + 1); octetIndex++) Tim->PartialVirtualBitMap [octetIndex] = virtualBitMap [octetIndex]; if ((octetIndex1 < VBM_SIZE) && (octetIndex0 < VBM_SIZE)) { if (TIM_method == 'A') { offset = 0; for (octetIndex = (VBM_SIZE - 1); (virtualBitMap [octetIndex] == 0) && (octetIndex > (max_bcast_octetIndex + 1)); octetIndex--) /* empty */ ; N2 = octetIndex; lengthOfPartialVirtualBitMap = N2 - offset + 1; for (octetIndex = (max_bcast_octetIndex + 1); (octetIndex <= N2); octetIndex++) Tim->PartialVirtualBitMap [octetIndex] = virtualBitMap [octetIndex]; Tim->IELength = lengthOfPartialVirtualBitMap + TIM_BASE_SIZE; Tim->BitMapControl = offset; } if (TIM_method == 'B') { offset = octetIndex1 - (max_bcast_octetIndex + 1); offset = offset & 0xFE; /* The result of (max_bcast_octetIndex + 1) + offset is equal to N1 that is described in 9.4.2.6 for the TIM element. */ for (octetIndex = (VBM_SIZE - 1); ((virtualBitMap [octetIndex] == 0) && (octetIndex > (max_bcast_octetIndex + 1))); octetIndex--) /* empty */ ; N2 = octetIndex; lengthOfPartialVirtualBitMap = N2 - offset + 1; for (octetIndex = (max_bcast_octetIndex + 1); octetIndex <= (lengthOfPartialVirtualBitMap - 1); octetIndex++) Tim->PartialVirtualBitMap [octetIndex] = virtualBitMap [offset + octetIndex]; Tim->IELength = lengthOfPartialVirtualBitMap + TIM_BASE_SIZE; Tim->BitMapControl = offset; } } } Tim->Element_id = TIM_ELEMENT_ID; Tim->DtimCount = dtimCount [0]; Tim->DtimPeriod = dtimPeriod [0]; /* Update broadcast/ multicast indication bit for transmitted BSSID if necessary */ if ((Tim->DtimCount == 0) && mcast_pending [0]) Tim->BitMapControl |= 0x01; } void Update_VirtualBitMap (UINT16 station_id, UINT8 Action) 3464 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications { UINT16 aid = station_id; UINT8 aid_octet; UINT8 aid_bit; if ((aid > 0) && (aid < AID_SIZE)) { /* Get AID position in the Partial Virtual Bitmap. */ aid_octet = (aid >> 3) & 0xff; aid_bit = 0x01 << (aid & 0x07); if (Action == REMOVE_TIM_BIT) virtualBitMap [aid_octet] &= ~aid_bit; else virtualBitMap [aid_octet] |= aid_bit; } } int main (void) { struct _tim Tim; UINT8 ExampleCase; UINT16 count = 0; char TIM_method; UINT16 numBssids = 1; /* The value of ExampleCase depends on the test case, allowed values are 1 to 22 */ ExampleCase = 1; /* The value of TIM_method depends on the method to use, allowed values are 'A' and 'B' */ TIM_method = 'A'; switch (ExampleCase) { /* Nine examples with numBssids = 1, no difference between Method A and B */ case 1: mcast_pending [0] = 0; Update_VirtualBitMap (2, ADD_TIM_BIT); Update_VirtualBitMap (7, ADD_TIM_BIT); break; case 2: mcast_pending [0] = 1; Update_VirtualBitMap (2, ADD_TIM_BIT); Update_VirtualBitMap (7, ADD_TIM_BIT); Update_VirtualBitMap (22, ADD_TIM_BIT); Update_VirtualBitMap (24, ADD_TIM_BIT); break; case 3: mcast_pending [0] = 1; Update_VirtualBitMap (24, ADD_TIM_BIT); break; case 4: mcast_pending [0] = 0; Update_VirtualBitMap (3, ADD_TIM_BIT); Update_VirtualBitMap (37, ADD_TIM_BIT); Update_VirtualBitMap (43, ADD_TIM_BIT); break; case 5: mcast_pending [0] = 0; Update_VirtualBitMap (35, ADD_TIM_BIT); break; case 6: mcast_pending [0] = 0; Update_VirtualBitMap (43, ADD_TIM_BIT); break; case 7: mcast_pending [0] = 0; Update_VirtualBitMap (35, ADD_TIM_BIT); Update_VirtualBitMap (35, REMOVE_TIM_BIT); 3465 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications break; case 8: mcast_pending [0] = 1; Update_VirtualBitMap (13, ADD_TIM_BIT); Update_VirtualBitMap (43, ADD_TIM_BIT); Update_VirtualBitMap (63, ADD_TIM_BIT); Update_VirtualBitMap (73, ADD_TIM_BIT); break; case 9: mcast_pending [0] = 1; Update_VirtualBitMap (2007, ADD_TIM_BIT); break; /* Thirteen examples with numBssids > 1, TIM_method = 'A' or 'B' */ case 10: numBssids = 8; Update_VirtualBitMap (9, ADD_TIM_BIT); Update_VirtualBitMap (11, ADD_TIM_BIT); break; case 11: numBssids = 8; mcast_pending [0] = 1; mcast_pending [3] = 1; Update_VirtualBitMap (12, ADD_TIM_BIT); Update_VirtualBitMap (17, ADD_TIM_BIT); Update_VirtualBitMap (22, ADD_TIM_BIT); Update_VirtualBitMap (24, ADD_TIM_BIT); break; case 12: numBssids = 16; mcast_pending [3] = 1; Update_VirtualBitMap (39, ADD_TIM_BIT); break; case 13: numBssids = 8; mcast_pending [5] = 1; mcast_pending [7] = 1; Update_VirtualBitMap (23, ADD_TIM_BIT); break; case 14: numBssids = 8; mcast_pending [2] = 1; mcast_pending [7] = 1; Update_VirtualBitMap (10, ADD_TIM_BIT); break; case 15: numBssids = 15; mcast_pending [5] = 1; mcast_pending [7] = 1; Update_VirtualBitMap (2007, ADD_TIM_BIT); break; case 16: numBssids = 15; mcast_pending [5] = 1; mcast_pending [7] = 1; Update_VirtualBitMap (1997, ADD_TIM_BIT); Update_VirtualBitMap (1999, ADD_TIM_BIT); break; case 17: numBssids = 32; for (count = 0; count < numBssids; count += 2) mcast_pending [count] = 1; Update_VirtualBitMap (32, ADD_TIM_BIT); Update_VirtualBitMap (33, ADD_TIM_BIT); Update_VirtualBitMap (39, ADD_TIM_BIT); break; case 18: numBssids = 14; mcast_pending [5] = 1; mcast_pending [7] = 1; break; 3466 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications case 19: numBssids = 14; mcast_pending [0] = 1; mcast_pending [12] = 1; break; case 20: numBssids = 15; Update_VirtualBitMap (38, ADD_TIM_BIT); break; case 21: numBssids = 15; mcast_pending [0] = 1; Update_VirtualBitMap (44, ADD_TIM_BIT); break; case 22: numBssids = 16; break; default: break; } Build_TIM (&Tim, TIM_method, numBssids); printf ("\nCase = %d, method %c.\n", ExampleCase, TIM_method); printf ("numBssids = %d.\n", numBssids); printf ("Element_id = %d.\n", Tim.Element_id); printf ("IELength = %d.\n", Tim.IELength); printf ("DtimCount = %d.\n", Tim.DtimCount); printf ("DtimPeriod = %d.\n", Tim.DtimPeriod); printf ("BitMapControl = 0x%02X\n", Tim.BitMapControl); if (Tim.IELength - TIM_BASE_SIZE > 0) { int octetIndex; for (octetIndex = 0; octetIndex < Tim.IELength - TIM_BASE_SIZE; octetIndex++) printf ("PartialVirtualBitMap [%d] = 0x%02X\n", octetIndex, Tim.PartialVirtualBitMap [octetIndex]); } return 0; } /* The End. */ 3467 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Annex M (informative) Integration function M.1 Introduction The purpose of this annex is to guide the implementor of an ESSâ€™s infrastructure that includes a portal that integrates the ESSâ€™s infrastructure with a wired LAN. M.2 Ethernet V2.0/IEEE 802.3 LAN integration function It is recommended that any ESSâ€™s infrastructure that logically incorporates a portal that integrates the ESSâ€™s infrastructure with an Ethernet V2.0/IEEE 802.3 LAN use the procedures defined in ISO/IEC Technical Report 11802-5:1997 (previously known as IEEE Std 802.1H-1997), with the two-entry selective translation table (STT) shown in Table M-1, to perform the integration service. Note that the majority of such IEEE 802.11 implementations currently use this STT, rather than the single-entry STT recommended in Annex A of IEEE Std 802.1H-1997 [B24]. Table M-1â€”IEEE 802.11 integration service STT Encoding in Type field Ethernet Protocol use type value First octet Second octet AppleTalk Address Resolution Protocol 0x80F3 80 F3 Novell NetWare Internetwork Packet exchange (IPX) 0x8137 81 37 M.3 Example The tables below illustrate the translations performed by the integration service using the encapsulation/ decapsulation procedures defined in ISO/IEC Technical Report 11802-5:1997 with the IEEE 802.11 integration service STT. These tables show how the octets in an IEEE 802.11 MSDU correspond to the octets in the Ethernet/IEEE 802.3 MSDU that represents the same LLC SDU on the integrated Ethernet/ IEEE 802.3 LAN. Table M-2 shows the encapsulation example, and Table M-3 shows the decapsulation example. In the tables below the rows that have a 81-00 Type/Length field value represent bridging between an Ethernet/IEEE 802.3 LAN and an IEEE 802.11 LAN. Both LANs are carrying VLAN-tagged MSDUs (User Priority=4, DEI=0, VLAN ID=1893). 3468 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table M-2â€”Ethernet/IEEE 802.3 to IEEE 802.11 translation Type / Protocol LLC header IEEE 802.11 LLC header Length IP 08-00 â€” AA-AA-03-00-00-00-08-00 IP 802.3a length AA-AA-03-00-00-00-08-00 AA-AA-03-00-00-00-08-00 IP ARP 08-06 â€” AA-AA-03-00-00-00-08-06 AppleTalk (1) 80-9B â€” AA-AA-03-00-00-00-80-9B AppleTalk (2) length AA-AA-03-08-00-07-80-9B AA-AA-03-08-00-07-80-9B AppleTalk AARP (1) 80-F3 â€” AA-AA-03-00-00-F8-80-F3 AppleTalk AARP (2) length AA-AA-03-00-00-00-80-F3 AA-AA-03-00-00-00-80-F3 IPX Ethernet II 81-37 â€” AA-AA-03-00-00-F8-81-37 IPX SNAP length AA-AA-03-00-00-00-81-37 AA-AA-03-00-00-00-81-37 IPX 802.2 length E0-E0-03 E0-E0-03 IPX 802.3b length FF-FF FF-FF VLAN-tagged IP 81-00 87-65-08-00 AA-AA-03-00-00-00-81-00-87-65- AA-AA-03-00-00-00-08-00c aThis format of IP packet over IEEE Std 802.3 is deprecated, and the change to the canonical Ethernet IP format is not considered harmful. bThe use of this nonstandard format happens to work with these rules, even though the FF-FF is not actually a valid LLC header value. (The broadcast LSAP is not valid as a source SAP in LLC. See IEEE Std 802.2.) cThe sequence of octets AA-AA-03-00-00-00-81-00-87-65 represents the SNAP-encoded VLAN header. The sequence of octets AA-AA-03-00-00-00-08-00 represents the IEEE 802.1Hâ„¢-translated Type/Length field, using the same translation as the untagged IP MSDU on the first line of Table M-2. Table M-3â€”IEEE 802.11 to Ethernet/IEEE 802.3 translation Type / Protocol IEEE 802.11 LLC header LLC header Length IP AA-AA-03-00-00-00-08-00 08-00 â€” IP 802.3a AA-AA-03-00-00-00-08-00 length â€” IP ARP AA-AA-03-00-00-00-08-06 08-06 â€” AppleTalk (1) AA-AA-03-00-00-00-80-9B 80-9B â€” AppleTalk (2) AA-AA-03-08-00-07-80-9B length AA-AA-03-08-00-07-80-9B AppleTalk AARP (1) AA-AA-03-00-00-F8-80-F3 80-F3 â€” AppleTalk AARP (2) AA-AA-03-00-00-00-80-F3 length AA-AA-03-00-00-00-80-F3 IPX Ethernet II AA-AA-03-00-00-F8-81-37 81-37 â€” 3469 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table M-3â€”IEEE 802.11 to Ethernet/IEEE 802.3 translation (continued) Type / Protocol IEEE 802.11 LLC header LLC header Length IPX SNAP AA-AA-03-00-00-00-81-37 length AA-AA-03-00-00-00-81-37 IPX 802.2 E0-E0-03 length E0-E0-03 IPX 802.3 FF-FF length FF-FF VLAN-tagged IP AA-AA-03-00-00-00-81-00-87-65- 81-00 87-65-08-06 ARP AA-AA-03-00-00-00-08-06 a This format of IP packet does not survive the trip across the non-IEEE-802.3 LAN intact. M.4 Integration service versus bridging There are a number of differences between the IEEE 802.11 integration service and the service provided by an IEEE 802.1D bridge [B23]. In the IEEE 802.11 architecture a portal provides the minimum connectivity between an IEEE 802.11 WLAN and a non-IEEE-802.11 LAN. Requiring an IEEE 802.1D bridge in order to be compliant with IEEE Std 802.11 would unnecessarily render some implementations noncompliant. The most important distinction is that a portal has only one â€œportâ€ (in the sense of IEEE Std 802.1D, for example) through which it accesses the DS. This renders it unnecessary to update bridging tables inside a portal each time a STA changes its association status. In other words, the details of distributing MSDUs inside the IEEE 802.11 WLAN need not be exposed to the portal. Another difference is that the DS is not an IEEE 802 LAN (although it carries IEEE 802 LLC SDUs). Requiring that the DS implements all behaviors of an IEEE 802 LAN places an undue burden on the architecture. Finally, it is an explicit intent of this standard to permit transparent integration of an IEEE 802.11 WLAN into another non-IEEE-802.11 LAN, including passing bridge PDUs through a portal. While an implementer might wish to attach an IEEE 802.1D bridge to the portal (note that the non-IEEE-802.11 LAN interface on the bridge need not be any particular type of LAN), it is not an architectural requirement of this standard to do so. 3470 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Annex N (informative) AP functional description N.1 Introduction This informative annex seeks to clarify the AP functional description. At times there is some confusion surrounding the term AP and the relation of that term to the AP functions and common implementations of AP devices. The core IEEE 802.11 conceptual definitions that surround the AP (refer to Clause 4) are abstract (and can sometimes cause confusion), but Clause 4 definitions are crafted to be flexible and hence serve to allow the adaptation and extension of this standard in a wide variety of ways. In this annex a wireless local area network (WLAN) system is a system that includes the distribution system (DS), access point (AP), and portal entities. It is also the logical location of distribution and integration service functions of an extended service set (ESS). A WLAN system contains an optional portal and one or more APs in addition to the DS. N.2 Terminology An enhanced description of these access entities begins with clarification of several terms. This standard defines an entity called a STA. STAs can operate in different modes. The possible operational modes of a STA are: a) Infrastructure mobile STAs b) Independent mobile STAs c) Access control mode STAs d) Mesh STAs The mobile STAs are the STA entities that are ordinarily moving around, but might also be in a fixed location. The mobile adjective prefix often helps in visualizing the type of STA under discussion. Infrastructure mobile STAs operate in infrastructure BSS mode, i.e., they are the users of an AP. Devices that incorporate an infrastructure mobile STA are referred to in this annex by the term mobile unit. A mobile unit device might consist of just a mobile STA implementation, but also likely includes an SME and a client. The exact configuration of the mobile unit it is not relevant to the descriptions in this annex. Independent mobile STAs operate in IBSS mode. Independent mobile STAs form autonomous networks that do not require an AP. A STA can also form an integral part of an AP. To do so, the STA operates in access control mode. This type of STA is called an access control mode STA (ACM_STA). The primary function of an AP is to provide the mobile units with access to the DS, as shown in the Unified Modeling Language (UML) use case diagram in Figure N-1. Complete UML specifications can be found in Rumbaugh [B57]. The UML diagram shows a system boundary box containing a single use case (ellipse). Entities that are outside the system boundary box are shown as stick people. These external entities represent the actors (formal term), or users, of the system. Since the actors are outside the system boundary, their 3471 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications internal behavior is not described (i.e., it is out of scope for the current view). Instead, references to the external entities are limited to descriptions of their interactions with, and expectations of, the system, which is accomplished by describing the use cases and scenarios (i.e., functions) of the system and later (in Figure N-4) a decomposition of the entities (objects and behaviors) within the system that provide that functionality. The use case diagram employs connecting lines to indicate relationships between the various artifacts present in the diagram. Relationship lines lacking arrows on both ends indicate that there is a bidirectional relationship between the artifacts. Figure N-1â€”Very high level UML use case diagram for the AP The DS enables communication between mobile units and the construction of collections of APs. To enable communication between mobile units and a non-IEEE-802.11 LAN entity requires the presence of a (logical) portal from the DS to the non-IEEE-802.11 LAN. Often the functions of an AP (which includes an ACM_STA), a DS, and a portal, are combined into a single device, referred to in this annex as an access unit (AU). While reference to that basic implementation is commonplace, it is helpful to discuss the abstract case: a WLAN system. The WLAN system includes the DS, an optional portal, APs, and the APâ€™s STAs. It is also the logical location of distribution and integration service functions of an ESS. An infrastructure WLAN system contains one or more APs and zero or one portal in addition to the DS. The primary function of a WLAN system is to provide the mobile units with access to the non-IEEE-802.11 LAN, as shown in Figure N-2. A secondary function is to provide the mobile units with access to each other. Figure N-2â€”Very high level UML use case diagram for the WLAN system 3472 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The primary functions of the WLAN system can be further characterized as follows: a) Provide non-IEEE-802.11 LAN access. 1) Includes mobile unit validation. 2) Includes moving data between the mobile units and the non-IEEE-802.11 LAN. i) Uses a special data movement function called filtering data. b) Configure the system. Those high-level use cases of the WLAN system are shown in the UML use case diagram in Figure N-3. The UML diagram shows multiple use cases with two types of relationships between those use cases: include and generalization. The include relationship â€œincludesâ€ functionality in one use case that is described by another use case. The â€œprovide LAN Accessâ€ use case includes the functionality of the â€œValidate mobile unitâ€ use case. The generalization relationship indicates that one use case is a more general form of another use case. The relationship line with a hollow triangle at the end indicates that the â€œMove Dataâ€ use case is a more generalized form of the â€œFilter Dataâ€ use case. Or, equivalently, â€œFilter Dataâ€ is a more specialized form of â€œMove Data.â€ The constraint artifact (in the lower left corner of the diagram) requires the WLAN system and the mobile units to be set to the same SSID. Figure N-3â€”High-level UML use case diagram for the WLAN system The primary functions of the WLAN system, depicted in the UML object model diagram in Figure N-4, are provided by the AP, and DS entities, the latter via the DSSs. The portal is merely a conceptual link from the DS to the non-IEEE-802.11 LAN. The UML object model diagram shows a package containing a set of object classes. References to the actors (external entities) are limited to descriptions of their interactions 3473 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications with, and expectations of, the object classes, which is accomplished by describing the attributes and behaviors of the class entities. The object model diagram uses connecting lines to indicate interfaces (called associations in UML terminology) between the various artifacts present in the diagram. UML association lines lacking arrows on both ends indicate that there is a bidirectional interface between the artifacts. The UML association lines are annotated with multiplicity counts to indicate the how many entities might fill the position at that end of the association. Figure N-4â€”High-level UML entity diagram for the WLAN system Figure N-4 also shows the relationships between the WLAN system entities. There exists a bidirectional association between zero or more [0..*] mobile units and a single (given) ACM_STA. The solid diamond terminated line indicates that there is a composition relationship between the ACM_STA and the AP, i.e., the AP is composed of (or always has an) ACM_STA. Hence there is a one-to-one mapping between APs and ACM_STAs. This composition and one-to-one relationship can also be drawn as shown in Figure N-5. These two forms are equivalent. There are one or more [1..*] APs connected to a single DS. The DS in turn connects to zero or one [0..1] portal. The portal connects to a single non-IEEE-802.11 LAN. 3474 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Figure N-5â€”AP UML composition diagram (alternate syntax) N.3 Primary ACM_STA functions The primary functions of an ACM_STA are as follows: a) Instantiate the infrastructure BSS. b) Move data between the mobile units and the AP. Instantiating the infrastructure BSS consists of advertising the BSS and defining timing for the entire BSS (i.e., infrastructure mode TSF). Advertising the BSS includes creating an infrastructure mode Beacon frame, transmitting that Beacon frame, and replying to mobile unit probe requests with corresponding probe response transmissions. Beacon frames and probe responses provide a way for the mobile units to find, join with the ACM_STA, and (subsequently) associate with the AP. This includes, for example, the AP providing channel, regulatory, and country information to the mobile units. Moving data between the mobile units and the AP consists of translating between MSDUs and MPDUs, buffering data, and transmitting/receiving MPDUs via an IEEE 802.11 PHY. N.4 Primary AP functions The primary functions of an AP are as follows: a) Provide DS access for the mobile units. 1) Includes mobile unit validation and extends (in some cases) to notifying the DS. 2) Includes moving data between the mobile units and the DS. i) Uses a special data movement function called data filtering. b) Configure the AP (both the AP itself and the included ACM_STA). Those high-level use cases of the AP are shown in the UML use case diagram in Figure N-6. The UML extend relationship â€œextendsâ€ a use case with optional functions provided by another use case that are applied only in some scenarios. In Figure N-6, the â€œNotify the DSâ€ use case extends the â€œValidate mobile unitâ€ use case in some scenarios. 3475 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Figure N-6â€”High-level UML use case diagram for the AP The AP provides DS access for the mobile units, including validating the mobile units (e.g., via STA and/or client authentication) and providing access and admission control (e.g., via the association process). An AP is literally a point of access to the DS (and, by extension, to the non-IEEE-802.11 LAN beyond). Upon validating a mobile unit, the AP updates the DS mapping of the mobile unit to the AP. DS mapping updates can, for example, be based on (re)association requests (received from the ACM_STA) or aging of inactive links (based on session timers). An AP might also receive access control updates directly from other APs, via a protocol outside the scope of this standard, in the form of inter-AP notifications of mobile unit association events and transitions. In this way, mobile unit validation and subsequent changes in mobile unit access control lead to adjustments in how data are allowed to move through the AP (i.e., between the mobile units and the DS). Providing DS access for the mobile units also includes moving data between the mobile units and the DS, which is accomplished by moving MSDUs between the ACM_STA and the DS (bidirectionally). The moving data function includes â€œfiltering data.â€ The filtering data function controls which MSDUs (if any) are moved between the DS and the mobile units. For example, filtering of data to and from a particular mobile unit is adjusted based on the various stages of validation of that mobile unit. The AP also provides a function for configuration. Configuring the AP includes configuring the AP itself as well as the included ACM_STA. For example, configuration might include setting the local values of the SSID, PHY channel, beacon interval, and so on. 3476 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications N.5 Primary DS functions The primary functions of the DS (i.e., the DSSs) are as follows: a) Map mobile unit to AP (for DS-to-mobile unit traffic delivery). b) Move data. The DSâ€™s mobile unit-to-AP map determines which AP is to be used for a given mobile unitâ€™s data delivery. This function includes mapping update adjustments, which are based on notification from the APs, of changes in mobile unit access control. Moving data consists of moving MSDUs among the APs (including returning MSDUs to the source AP for mobile unit-to-mobile unit communications) and between the APs and the portal. N.6 Primary portal function The primary function of a portal is as follows: a) Move data with a special data movement function called data transformation. Moving data consists of moving MSDUs between the DS and the external non-IEEE-802.11 LAN. Moving data through the portal transforms the MSDUs using the integration function. The integration function translates external non-IEEE-802.11-LAN MSDUs to and from IEEE 802.11 MSDUs using, for example, the procedures defined in Annex M. 3477 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Annex O (informative) Additional VHT and HT information O.1 VHT and HT waveform generator tool As an informative extension to this standard, waveform generator tools have been written to model the PHY transmission process described in Clause 17, Clause 18, Clause 19, and Clause 21. The waveform generator can be downloaded from the public IEEE 802.11 document website. The waveform generator code that includes Clause 17, Clause 18, and Clause 19 is contained in document 11-06/1715, and the waveform generator description is contained in document 11-06/1714 (HT code). A description of the waveform generator that includes Clause 17, Clause 19, and Clause 21 and the waveform generator code itself may be found in document 11-11/0517 (VHT code). The purpose of these tools is to promote common understanding of complex PHY algorithms, facilitate device interoperability by providing reference test vectors, and assist researchers in industry and academia to develop next generation wireless solutions. The code is written in the MATLAB computing language and can be configured to generate test vectors for most PHY configurations, defined by this standard. Instructions on how to configure and run the tools are specified in the referenced documents. A command line interface is used to configure the VHT code tool. For consistency with this standard, the configuration interface is made very similar to the TXVECTOR parameters defined in 21.2.2. A command line interface and graphic user interface (GUI) exist to configure the HT code tool. For consistency with this standard, the configuration interface is made very similar to the TXVECTOR parameters defined in 19.2.2. The waveform generator tool produces test vectors for all transmitter blocks, defined in Figure 19-2 and Figure 19-3, generating reference samples in both frequency and time domains. Outputs of the tool are time domain samples for all transmitting chains. O.2 A-MPDU deaggregation This subclause contains a description of the deaggregation process. Other implementations are also possible. The receiver checks the MPDU delimiter for validity based on the CRC. It can also check that the length indicated is within the value of the LENGTH parameter indicated in RXVECTOR. If the MPDU delimiter is valid, the MPDU is extracted from the A-MPDU. The next MPDU delimiter is expected at the first multiple of 4 octets immediately after the current MPDU. This process is continued until the end of the PPDU is reached. 3478 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If the MPDU delimiter is not valid, the deaggregation process skips forward 4 octets and checks to see whether the new location contains a valid MPDU delimiter. It continues searching until either a valid delimiter is found or the end of the PSDU is reached based on the value of the LENGTH parameter indicated in the RXVECTOR.62 An A-MPDU parsing (deaggregation) algorithm is expressed (as a C programming language snippet) in Figure O-1. void Parse_A_MPDU (int length) { int offset = 0; /* Octet offset from start of PSDU */ while (offset+4 < length) { if (valid_MPDU_delimiter(offset) && get_MPDU_length(offset) <= (length -(offset+4))) { /* Valid delimiter */ /* Receive the MPDU */ Receive_MPDU(offset+4, get_MPDU_length(offset)); /* advance by MPDU length rounded up to a multiple of 4 */ offset += 4 + 4*((get_MPDU_length(offset)+3)/4); } else /* Invalid delimiter */ { /* Advance 4 octets and try again */ offset += 4; } } } NOTE 1â€”This algorithm is not optimized for efficiency. NOTE 2â€”The delimiter signature can be used to reduce the amount of computation required while scanning for a valid delimiter. In this case, the receiver tests each possible delimiter for a matching Delimiter Signature field. Only when a match is discovered does it then check the CRC. Figure O-1â€”A-MPDU parsing 62 This procedure occasionally wrongly interprets a random bit-pattern as a valid delimiter. When this happens, the MAC attempts to interpret a random MPDU. The MAC discards it with a high probability based on a check of the FCS field. 3479 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications O.3 Example of an RD exchange sequence Figure O-2 shows an example of the operation of the RD rules, defined in 10.28. Remaining TXOP Duration (t) Remaining TXOP Duration (t0) Remaining TXOP Duration (t1) PPDU addressed to PPDU addressed to PPDU addressed to STA B STA C STA C Duration/ID = t Duration/ID = t0 Duration/ID = t1 Data + HTC Data + HTC Data + HTC (RDG = 1) (RDG = 1) (RDG = 1) BA + HTC (RDG =1) Data Data BA BA STA A Response Burst Data + HTC (More Data + HTC (More BA + HTC (More PPDU = 1) PPDU = 0) PPDU = 0) Data STA B Response Burst Response Burst Data + HTC (More Data + HTC (More Data + HTC (More BA + HTC (More PPDU = 0) PPDU = 0) PPDU = 0) PPDU = 0) Data STA C Figure O-2â€”Example of RD exchange sequence showing response burst The following is a summary of Figure O-2: a) STA A (acting as RD initiator) transmits a PPDU containing MPDUs addressed to STA B (acting as RD responder). The Ack Policy field of the QoS Data frames in this PPDU is set to Implicit Block Ack Request. One or more MPDUs within this PPDU include an HT Control field with the RDG/ More PPDU subfield set to 1, indicating an RDG. The Duration/ID field of MPDUs within the PPDU contains the remaining duration of the TXOP, t s. b) STA B (the RD responder) responds with the transmission of a +HTC BlockAck frame in which the RDG/More PPDU subfield is set to 1, indicating that another PPDU will follow a SIFS or RIFS after the end of the PPDU containing the BlockAck frame. c) STA B transmits a PPDU (the second PPDU of an RD response burst) to STA A, with the Ack Policy field of its QoS Data frames set to Implicit Block Ack Request and containing one or more +HTC MPDUs in which the RDG/More PPDU subfield is set to 0, indicating that this is the last PPDU in the response burst. d) STA A (the RD initiator) regains control of the TXOP and transmits a BlockAck frame addressed to STA B to acknowledge the MPDUs transmitted by STA B in the RD response burst. e) STA A (the RD initiator) transmits a PPDU containing MPDUs addressed to STA C (acting as RD responder). The Ack Policy field of the QoS Data frames in this PPDU is set to Implicit Block Ack. This PPDU includes one or more +HTC MPDUs in which the RDG/More PPDU subfield is set to 1, indicating an RDG. The Duration/ID field of MPDUs in the PPDU contains the remaining duration of the TXOP, t0 s. 3480 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications f) STA C (the RD responder) transmits a PPDU to STA A, containing one or more +HTC MPDUs with the RDG/More PPDU subfield set to 0, indicating that this is the last PPDU in the response burst. This PPDU contains a BlockAck frame that is a response to the implicit block ack request of the previous PPDU, plus QoS Data frames with the Ack Policy field set to Implicit Block Ack. g) STA A (the RD initiator) regains control of the TXOP and transmits a BlockAck frame to STA C that acknowledges the MPDUs transmitted by STA C. This PPDU contains one or more +HTC MPDUs with the RDG/More PPDU subfield set to 1, indicating an RDG. The Duration/ID field of MPDUs in the PPDU contains the remaining duration of the TXOP, t1 s. h) STA C (the RD responder) transmits a PPDU to STA A, containing QoS data +HTC MPDUs with the Ack Policy field set to Implicit Block Ack Request and the RDG/More PPDU subfield set to 0. This is the only PPDU in the RD response burst. i) STA A transmits a BlockAck frame to STA C that acknowledges the MPDUs transmitted by STA C in the RD response burst. O.4 Illustration of determination of NDP addresses Determination of NDP SA and DA are illustrated in Figure O-3 and Figure O-4. MPDU with two or more addresses HT NDP Announcement =1 ... RA1 TA1 ... NDP NDP ... Calibration Position =0 Address 1 Address 2 HTC Destination address of each NDP = RA1 Source address of each NDP = TA1 MPDU requiring an immediate response HT NDP Announcement =1 NDP Destination address = RA1 ... RA1 TA1 ... NDP Calibration Position =0 NDP Source address = TA1 Address 1 Address 2 HTC Response RA HT NDP Announcement =0 ... ... 2 Calibration Position =0 Address 1 HTC MPDU requiring an immediate response Destination address of each NDP = RA2 (HT NDP Announcement=1) HT NDP Announcement =0 ... RA1 TA1 ... Source address of each NDP = RA1 Calibration Position =0 (there is no Address 2 field in the HT NDP announcement in this example) Address 1 Address 2 HTC Response RA HT NDP Announcement =1 ... ... NDP NDP ... 2 Calibration Position =0 Address 1 HTC Figure O-3â€”Determination of NDP source and destination for unidirectional NDP sequences 3481 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Destination address of first NDP = RA MPDU containing two or more addresses Destination address of second NDP = TA Source address of first NDP = TA HT NDP Announcement =1 Source address of second NDP = RA ... RA TA ... NDP1 Calibration Position =1 Optional response Address 1 Address 2 HTC HT NDP Announcement =0 ... ... NDP2 Calibration Position =2 HTC Figure O-4â€”Determination of NDP source and destination for bidirectional NDP sequence O.5 20/40 MHz BSS establishment and maintenance O.5.1 Signaling 20/40 MHz BSS capability and operation A BSS that occupies 40 MHz of bandwidth and that is administered by an HT AP is called a 20/40 MHz BSS. An HT AP that has dot11FortyMHzOperationImplemented equal to true sets the Supported Channel Width Set subfield of the HT Capabilities element to a nonzero value. The AP might also operate a 20/40 MHz BSS. The Supported Channel Width Set subfield of the HT Capabilities element that is transmitted by the AP indicates the possible operating mode of the BSS and of the AP, but the value in this field is not an indication of the current BSS bandwidth of either the AP or the BSS. An HT AP signals the operating width of the BSS through the Secondary Channel offset field of the HT Operation element. A nonzero value in this field indicates that a secondary channel exists; in other words, the BSS is a 20/40 MHz BSS. A value of 0 in this field indicates that the BSS is operating as a 20 MHz BSS. An HT AP that has dot11FortyMHzOperationActivated equal to true sets its STA Channel Width field of the HT Operation element to a nonzero value. This field signals the current operating mode of the AP, not the BSS. An HT AP might operate a 20/40 MHz BSS while it is operating as a 20 MHz device. Such a situation would support, for example, 40 MHz bandwidth DLS traffic among associated STAs, but only 20 MHz bandwidth traffic between STAs and the AP. O.5.2 Establishing a 20/40 MHz BSS Before starting a 20/40 MHz BSS, a 40MC HT AP is required by the rules defined in 11.16.5 to examine the channels of the current regulatory domain to determine whether the operation of a 20/40 MHz BSS might unfairly interfere with the operation of existing 20 MHz BSSs. The AP (or some of its associated HT STAs) is required to scan all of the channels of the current regulatory domain in order to ascertain the operating channels of any existing 20 MHz BSSs and 20/40 MHz BSSs. This type of scanning is called OBSS scanning. The particulars of OBSS scanning are controlled by the following MIB attributes: â€” dot11FortyMHzOptionImplemented â€” dot112040BSSCoexistenceManagementSupport â€” dot11FortyMHzIntolerant â€” dot11BSSWidthTriggerScanInterval â€” dot11BSSWidthChannelTransitionDelayFactor â€” dot11OBSSScanPassiveDwell â€” dot11OBSSScanActiveDwell 3482 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” dot11OBSSScanPassiveTotalPerChannel â€” dot11OBSSScanActiveTotalPerChannel â€” dot11OBSSScanActivityThreshold Specific values for these MIB attributes are provided to set minimum scan times for passive scanning of each channel, and a separate minimum time is provided for active scanning of each channel. A total minimum amount of scanning per channel is required before a determination can be made to allow the operation of a 20/40 MHz BSS. The rules that are applied when determining whether a 20/40 MHz BSS can be established are intended to avoid a full or partial overlap of the secondary channel of the 20/40 MHz BSS with an existing primary channel of either a 20 MHz BSS or a 20/40 MHz BSS. The lack of partially overlapping channels in the 5 GHz band allows these rules to be written as recommendations, while in the 2.4 GHz band, they are requirements. An additional constraint on establishing a 20/40 MHz BSS includes the allowance for any IEEE 802.11 device to explicitly prohibit the operation of the 20/40 BSS mode due to other considerations. For example, if an IEEE 802.15.1â„¢ WPAN device is operating in the area, that device is likely to be unable to communicate successfully with a paired receiver if the number of available IEEE 802.15.1 WPAN channels falls below a given threshold. Operation of a 20/40 MHz BSS in the 2.4 GHz band can contribute to the reduction of the number of available IEEE 802.15.1 WPAN channels, possibly pushing the available channels below that threshold. To promote sharing of the spectrum resource under such circumstances, it might be desirable to prohibit the operation of a 20/40 MHz BSS. As such, the 20/40 BSS coexistence mechanism allows a STA to transmit Management frames containing a value of 1 for the Forty MHz Intolerant field. (The MIB attribute dot11FortyMHzIntolerant determines the setting of the value of the Forty MHz Intolerant field in transmitted frames, and the setting of the value of the MIB attribute is beyond the scope of this standard.) Receivers of such frames on any channel in the band are not allowed to establish a 20/40 MHz BSS anywhere in the band for a duration of dot11BSSWidthChannelTransitionDelayFactor Ã— dot11BSSWidth- TriggerScanInterval seconds. To effect this requirement, monitoring STAs and APs maintain a countdown timer to indicate that a prohibition is in force. The countdown timer is reloaded with the value dot11BSSWidthChannelTransitionDelayFactor Ã— dot11BSSWidthTriggerScanInterval seconds each time that the STA or AP observes a Management frame containing a value of 1 for the Forty MHz Intolerant field. STAs communicate changes in their countdown counter (i.e., transitions between a zero value and a nonzero value) to their associated AP through the 20 MHz BSS Width Request field of the 20/40 BSS Coexistence Management frame. O.5.3 Monitoring channels for other BSS operation Some of the STAs that are associated with a 20/40 MHz BSS perform monitoring so that the conditions which allowed the establishment of the 20/40 MHz BSS do not change to conditions that would disallow the existence of the 20/40 MHz BSS. Monitoring STAs keep a local record of channels that are in use by other BSSs. STAs that receive Beacon frames determine the primary channel by examining the DSSS Parameter Set element. Secondary channel existence and channel information are determined by examining the Secondary Channel Offset field of the 20/40 BSS Coexistence element. Monitoring STAs also record receptions of frames that contain a value of 1 for the Forty MHz Intolerant field. Any changes to the local record that would create a prohibition against 20/40 MHz BSS operation are immediately reported to the associated AP through the transmission of a 20/40 BSS Coexistence Management frame (i.e., with the 20 MHz BSS Width Request field set to 1). The reception of a 20 MHz BSS Width Request field equal to 1 at the AP causes the AP to switch the BSS to 20 MHz operation immediately. 3483 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Any change of a channel in use that had not previously been in use is also reported immediately within a 20/40 BSS Coexistence Management frame. The AP examines the new in-use channel information to determine whether any changes in BSS width operation are required (i.e., to see if any changes have occurred that indicate an overlap of the secondary channel). If a change to 20 MHz BSS operation is required, the change occurs immediately. Conditions that prevent the operation of a 20/40 MHz BSS might be transient. If the number of channels in use is reduced or all STA signaling 40 MHz intolerance leave the area, an AP might choose to revert to 20/40 MHz operation, if allowed to do so. However, the conditions that allow 20/40 MHz BSS operation have to persist for a period of dot11BSSWidthChannelTransitionDelayFactor Ã— dot11BSSWidthTrigger- ScanInterval seconds before a STA can signal that the conditions have changed, and the same period of time has elapsed before an AP can resume 20/40 MHz BSS operation. STAs that do not monitor channels through OBSS scanning and do not report any channel information or received Forty MHz Intolerant field information to their associated AP are listed here: â€” Non-HT STAs â€” HT STAs that are exempt from scanning as specified in 11.16.6 â€” HT APs, once the 20/40 MHz BSS is established â€” HT STAs that are associated with an AP whose BSS is operating on a channel that is not in the 2.4 GHz band â€” HT STAs that are associated with an HT AP that is not 40-MHz-capable (as indicated by a value of 0 in the Supported Channel Width Set subfield of the HT Capabilities element) All other HT STAs that are associated with a 40-MHz-capable HT AP whose BSS is operating on a channel in the 2.4 GHz band monitor channels through OBSS scanning and report any channel information or received Forty MHz Intolerant field information to their associated AP. All MIB attributes that are employed by the 20/40 BSS Coexistence mechanism are maintained by the AP, which has the ability to provide updates to the MIB attribute values to the associated STA by transmitting an OBSS Scan Parameters element. 3484 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Annex P (informative) Location and Time Difference accuracy test P.1 Location via Time Difference of arrival The location of a device might be determined using multiple methods, including: â€” Signal strength at different sensors â€” Time of flight between the device and different sensors â€” Time difference of arrival between the device and pairs of sensors A typical implementation of the time difference of arrival method requires that the sensors are co-channel, have synchronized clocks, and receive the same transmission from the device. The sensorâ€™s time of arrival measurements are shared, and the device location is determined via multilateration, i.e., each pair of sensor measurements provides a time difference of arrival measurement that represents a hyperbola in 2D space of most likely candidate locations, and the overlap of the multiple hyperbola from multiple pairs of sensors leads to the location estimate. The single time of departure is not relevant in this typical multilateration implementation as it is canceled out when time differences of arrival are computed. When the sensors are on different channels, such as APs in a typical multi-channel deployment, the device transmits on each channel and thus with multiple times of departure. In this environment it is necessary for the device to advertise each time of departure so that it can be subtracted from the times of arrivals measured by sensors on different channels. Furthermore, the deviceâ€™s clock frequency typically does not match the clock frequency of the synchronized sensors, and so the device should transmit on the same channel multiple widely spaced times in order for the sensors to estimate the deviceâ€™s clock frequency relative to themselves and to be able to suitably scale the deviceâ€™s advertised times of departure. An example transmission sequence comprises frames transmitted on channels 1, 6, 11, 1 at 2.4 GHz. From this, the deviceâ€™s clock frequency can be determined relative to the synchronized APs on channel 1, and all APs on channels 1, 6, and 11 can measure a time of arrival. These four transmissions enable a single location calculation. The Time of Departure Accuracy test in P.2 is designed to measure errors within such a transmission sequence that would degrade a multi-channel time difference of arrival location scheme. P.2 Time Difference of departure accuracy test The Time Difference of Departure accuracy test is an informative description of how time difference of departure accuracy can be measured for any parameterizable PHY waveform. This accuracy test does not apply when the Time of Departure timestamps are exclusively used for timing measurement (see 11.24.5). The Time Difference of Departure accuracy test is parameterized by the following test parameters: â€” TIME_OF_DEPARTURE(j,i), 1 j 500, 1 i I (scalar entries) â€” MULTICHANNEL_SAMPLING_RATE (scalar) â€” FIRST_TRANSITION_FIELD(j,i), 1 j 500, 1 i I (waveform entries) â€” SECOND_TRANSITION_FIELD(j,i), 1 j 500, 1 i I (waveform entries) â€” TRAINING_FIELD(j,i), 1 j 500, 1 i I (waveform entries) â€” TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH (scalar) 3485 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications TIME_OF_DEPARTURE(j,i) is exposed externally through the TOD Timestamp field in the Time of Departure subelement in Location Track Notification frames. The Time Difference of Departure accuracy test is performed as follows or in an equivalent or more accurate manner. The Time Difference of Departure accuracy test is performed by instrumentation capable of converting signals transmitted on one or more channels into a stream of complex samples at fs sample/s or more, with sufficient accuracy in terms of I/Q arm amplitude and phase balance, dc offsets, phase noise, etc, and at a fixed delay from the transmitter. The minimum sampling rate is MULTICHANNEL_SAMPLING_RATE sample/s respectively. A possible embodiment of such a setup is converting the signal to a low IF frequency with a cabled microwave synthesizer, sampling the signal with a digital oscilloscope and decomposing it digitally into quadrature components. The sampled signal is processed in a manner similar to an actual time of arrival processor, according to the following steps: a) Repeat steps b) to j) indexed by j = 1, â€¦ , 500 b) Repeat steps c) to i) indexed by i = 1, â€¦ , I c) Start of frame is detected. d) Channel number, coarse and fine frequency offsets are estimated. e) The packet is derotated according to estimated frequency offsets. f) The transition from FIRST_TRANSITION_FIELD(j,i) to SECOND_TRANSITION_FIELD(j,i) is detected; and fine timing (with one sample resolution) is established. g) The TRAINING_FIELD(j,i) of the derotated signal is up-sampled to meet the TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH requirement. For example, a TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH of 1 ns requires up-sampling of at least 1 GHz. h) The up-sampled signal is cross-correlated with a reference waveform of the TRAINING_FIELD(j,i) i) The measured time of departure xj,i is determined from the time of the peak of the magnitude of the cross-correlation. NOTEâ€”The time of the peak of the magnitude of the cross-correlation is actually a time of arrival measurement that equals the time of departure up to a fixed delay. Since the fixed delay is removed within step j), the fixed need not be known or explicitly compensated for. j) Having repeated steps c) to i) I times, the (j,i)th time of departure error ej,i is calculated as TIME_OF_DEPARTURE(j,i) minus the synchronized time of departure. Defining xj = [xj,1,..,xj,I]T as the I measured times of departure, y = [TIME_OF_DEPARTURE(j,1), â€¦ TIME_OF_DEPARTURE(j,I)]T, ej = [ej,1, ej,I]T are the I time of departure errors and Xj = [1I Ã—1, xj], where 1I Ã—1 is an I Ã—1 matrix of 1s, then the relative clock intercept, rcij, and slope, rcsj, between device and instrumentation are determined as the linear least squares line of best fit: i.e., [rcij, rcsj]T = (XjTXj)â€“1XjTy j. With these definitions and calculations, the synchronized time of departure sj = [sj,1,..,sj,I]T equals rcsj Ã— xj + rcij Ã— 1I Ã—1, and so the I time of departure errors equal ej = yj â€“ sj. k) Having repeated steps b) to j) 500 times, there are 500 Ã— I values of the time of departure errors e = [e1,1, e500,I ] l) The Time Difference of Departure accuracy test is passed if both of the following conditions are met: 1) The RMS value of e is less than aTxPHYTxStartRMS. 2) aTxPHYTxStartRMS is less than TIME_OF_DEPARTURE_ACCURACY_TEST_THRESH, where the units of e, aTxPHYTxStartRMS, and TIME_OF_DEPARTURE_ ACCURACY_TEST_THRESH are properly accounted for. 3486 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications NOTE 1â€”One possible implementation of a time of departure measurement system is a free-running oscillator clocking (a) the digital-to-analog converter(s) used to transmit the packet, (b) a 32-bit continuously counting counter and (c) a hardware finite state machine such that PHY-TXSTART.request primitive causes a transition within the finite state machine that in turn causes frame transmission at the DACs a fixed number of cycles later; where the time of departure is recorded as the value of the counter at that transition minus aTxPHYTxStartRFDelay (using TIME_OF_DEPARTURE_ClockRate), where aTxPHYTxStartRFDelay can vary by channel. In this implementation, the principal source of time of departure error is short-term oscillator imperfection (e.g., phase noise) and RF group delay variation across channels uncompensated by aTxPHYTxStartRFDelay. NOTE 2â€”1 ns of time of departure error corresponds to approximately 0.3 m of distance error, so high location accuracy depends upon a tight time of departure standard deviation. P.3 Differential Distance Computation using Fine Timing Measurement frames In Figure P-1 the Observing STA is able to listen to the Fine Timing Measurement frame exchange between the Sending and Receiving STAs. The time of flight of a line of sight transmission between the Sending and Receiving STAs is denoted as T. At the Observing STA, the time of Arrival (ToA) of message M and its Ack frame are respectively tc1 and tc2. At the Sending STA, the time of departure (ToD) of message M and the ToA of its Ack frame are t1 and t4 respectively. The differential distance between the Observing STA and each of the Sending and Receiving STAs, denoted as DSR, is defined as: D SR = c T SO â€“ T RO where c is speed of the light. TSO is the time of flight between the Sending STA and the Observing STA TRO is the time of flight between the Receiving STA and the Observing STA DSR can now be computed as: D SR = c tc 1 â€“ tc 2 â€“ T â€“ t1 â€“ t4 An Observing STA can use the ToA and the time stamps (t1 and t4) received in the following messages in the message exchange to refine its computation of the differential distance to the Sending and Receiving STAs. In Figure P-1 the Receiving and Sending STAs can be APs. The APs can learn about neighboring APs that support the FTM protocol and an AP can initiate a FTM message exchange on a periodic basis (e.g., the beacon interval or a multiple of the beacon interval) with its neighbor APs. Monitoring and receiving these messages can enable Observing STAs to estimate their differential distance with the AP pairs. An Observing STA that is able to determine its differential distance to at least three pairs of Sending and Receiving STAs can determine its location using the principle of hyperbolic navigation. An Observing STA can potentially determine its location by monitoring the FTM exchanges of a single AP (Sending STA) if there are three or more neighbor APs of the Sending STA that support FTM. 3487 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications t1 = ToD(M) Action frame M contains: Dialog Token = n t2 = ToA (M) Follow On Dialog Token = 0 t3 = ToD(Ack) t4 = ToA(Ack) Action frame M Contains: Dialog Token = m â‰ n Follow On Dialog Token = n t1 and t4 are known ToD Timestamp = t1 ToA Timestamp = t4 SME at receiving STA estimates RTT as (t4-t1)-(t3-t2) . . . Action frame M Contains: Dialog Token = 0 Follow On Dialog Token = p ToD Timestamp = t1' ToA Timestamp = t4' tc1 = ToA (M) tc2 = ToA (Ack) Sending Observing Receiving STA STA STA Figure P-1â€”Parameters recorded by Observing STA when monitoring an FTM message exchange 3488 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Annex Q (informative) Example use of the Destination URI for Event and Diagnostic Reports Q.1 Destination URI payload An example of the payload used to transmit Event and Diagnostic reports shown in Table Q-1. The protocol used to transport the Destination URI payload is beyond the scope of this standard. An example use of the Destination URI is given in Q.2. Table Q-1â€”Destination URI payload Size (octets) Information 6 BSSID 6 Reporting STA Address variable Event or Diagnostic Report frame contents Q.2 Use of HTTP (or HTTPS) for Destination URI of Event and Diagnostic Reports Under certain conditions a non-AP STA might need to send Event and Diagnostic reports to an AP using the Destination URI advertised by the AP in the request frame. A suitable higher layer protocol that could be used to transport the Event or Diagnostic report is HTTP or HTTPS. For example, consider the following: 1) IT is investigating a WLAN coverage problem and uses a non-AP STA with a WLAN and Ethernet adapters to collect some additional information. 2) The non-AP STA with MAC 00-ff-fd-00-00-01 has received a request for a Diagnostic report from AP 00-ff-fe-00-00-10 and is in fringe coverage. The non-AP STA has an Ethernet adapter that is connected. 3) The AP includes an Alternate Destination URI of http://www.myserver.mycompany.com in the Diagnostic Report frame. 4) The non-AP STA loses WLAN connectivity while trying to transmit a Diagnostic Report frame to the AP and the non-AP STAâ€™s SME determines that it can use the Alternate Destination URI to send the Diagnostic Report frame using the Ethernet link. 5) The non-AP STA POSTs the Diagnostic report as follows: POST /wnm/msg/00-ff-fd-00-00-01/msg1 HTTP/1.1 Host: http://www.myserver.mycompany.com Content-Type: application/octet-stream Content-Encoding-Type: base64 3489 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Content-Length: i (length of data as specified in Figure 9-697 in 9.6.14.5) In the HTTPS case, the non-AP STA would need to be provisioned with credentials to establish the TLS connection prior to posting the message over HTTP. The HTTP post would work as described previously. 3490 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Annex R (informative) Interworking with external networks R.1 General The purpose of this informative annex is to describe and clarify the support for interworking with external networks including the support for network discovery and selection, QoS mapping, SSPN interface, and emergency services and to provide some background information and recommended practices. R.2 Network discovery and selection R.2.1 General Interworking service provides features to support the network discovery and selection process a STA uses to choose the network with which to associate. GAS provides a non-AP STA access to an advertisement server (e.g., an access network server or an IEEE 802.21 information server), which can provide a rich set of information to aid the network discovery and selection process. In addition, interworking service provides lightweight features that also facilitate this process. The following subclauses describe several use cases illustrating how these features can be used to aid in network discovery and selection: â€” Airport: A traveling businesswoman needs to connect via an airport hotspot to her enterprise net- work to download email and information from the customer database. â€” Shopping: A shopper visits a shopping mall and wants to use a smartphone to discover items on sale. â€” Sales meeting: A salesman visiting a customer accesses his guest network. â€” Museum: A visitor to a museum uses a smartphone to obtain virtual docent service. â€” Emergency call: A traveler needs to make an emergency call while in another country. â€” Emergency alert: A traveler, having enabled the display of emergency alerts, arrives at a new desti- nation. R.2.2 Airport A traveling businesswoman arrives for the first time at an airport having a WLAN. This user wants to download email onto her laptop utilizing the airportâ€™s hotspot, a chargeable network. Once associated, the woman needs to connect via VPN connection back to her companyâ€™s servers to access email and information from the customer database. This is performed as follows: a) The laptopâ€™s non-AP STA performs an active scan by transmitting a Probe Request frame containing the wildcard SSID and an Interworking element with Access Network Type subfield set to â€œChargeable Public Network.â€ In response, it receives Probe Response frames from several of the airportâ€™s APs, in the immediate neighborhood, for the SSID â€œNarita Hotspot.â€ b) The Probe Response frame received by the laptop indicated the following capabilities: 1) Extended Capabilities element indicates: AP provides interworking service. 3491 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 2) Interworking element indicates: venue group = 1 (Assembly) and venue type = 3 (passenger terminal), Internet = 1 (Internet access available), ASRA = 1 (there is an additional step required for network access). 3) Advertisement Protocol element including the Advertisement Protocol ID set to MIH Information Service. 4) Roaming Consortium element present containing an OI for â€œHotspot Roaming International.â€ 5) There is no RSNE present in the received Beacon frame. c) Since the laptopâ€™s SME does not recognize the Roaming Consortium OI, it invokes the GAS protocol to query the networkâ€™s IEEE 802.21 IS. The IEEE 802.21 ISâ€™s response indicates the roaming partners for â€œNarita Hotspotâ€ and the laptop have security credentials for one of them. d) Since the AP indicated ASRA = 1, the SME again invokes the GAS protocol to retrieve the Network Authentication Type ANQP-element. The response indicates that https redirection is in use and provides the Redirect URL of hotspot.narita.co.jp. Note that this is helpful since some networks use conditional redirectionâ€”that is, access to a walled garden is provided for free, but a subscription fee is required to access the Internet. e) Since the laptopâ€™s SME now knows it should be able to successfully authenticate with the network, the STA associates to the AP. f) The following operations are then carried out by higher layers operating within the laptop: 1) The laptopâ€™s SME autonomously launches an http client and provides to it the URL of hotspot.narita.co.jp, which provides the proper security credentials to the network and thereby successfully authenticates it to the network. 2) The VPN client is autonomously launched and a secure session to the userâ€™s corporate network is established. Then the user launches the email application to download email and other required information. R.2.3 Shopping A shopper visits a shopping mall and wants to use a smartphone to discover items on sale. In this mall, the mallâ€™s IT department is providing WLAN facilities for all of the stores in the mall; therefore, there is only one SSID for shoppers (i.e., there is not a different SSID for each store in the mall). The user arrives at the mall and taps an icon on the screen to put the smartphone in â€œshopping mode.â€ The smartphoneâ€™s shopping application causes the non-AP STA to carry out the following steps: a) The smartphoneâ€™s non-AP STA performs an active scan by transmitting a Probe Request frame containing the wildcard SSID and an Interworking element with Access Network Type subfield set to â€œFree Public Network.â€ In response, it receives Probe Response frames from several of the mallâ€™s APs, but only one SSID is provided, which is â€œSilicon Valley Mall.â€ The mallâ€™s APs did not transmit Probe Response frames for the SSIDs â€œEngineering,â€ â€œDeliveries,â€ and â€œJanitorialâ€ since their access network type is â€œPrivate network.â€ b) The Probe Response frame received by the smartphone indicated the following capabilities: 1) Extended Capabilities element indicates: AP provides interworking service. 2) Interworking element indicates: venue group = 6 (mercantile) and venue type = 4 (shopping mall), Internet = 0 (unspecified). 3) RSNE indicates: IEEE 802.1X authentication. c) Since the AP indicated Interworking service is available, the smartphoneâ€™s non-AP STA uses the MLME-GAS.request primitive to invoke GAS to request the Capability List ANQP-element (see 9.4.5.3). In the Capability List ANQP-element, the AP has indicated support for Venue Name and Domain Name. Subsequent to receipt of the Capability List ANQP-element, the non-AP STA invokes the MLME-GAS.request primitive to retrieve the other two lists. 3492 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications d) Next, the non-AP STAâ€™s supplicant searches the received Domain Name list to determine whether it has any stored credentials for these domains. If so, 1) The smartphone autonomously associates to the â€œSilicon Valley Mall Shoppingâ€ SSID and displays the following information: i) Venue name: Silicon Valley Mall, 1234 Main Street, Rownhams, CA 98765-1234 ii) SSID: Silicon Valley Mall iii) Venue type: Shopping Mall 2) The supplicant autonomously provides the security credentials for the selected domain. e) Higher layer protocols then download discount coupons being offered for items on sale. R.2.4 Sales meeting A salesman travels across town to a meeting at ACME Manufacturing. While there, this user needs to send email to get a document from engineering. On his laptop, he requests the WLAN via the laptopâ€™s UI to search for guest networks. The laptop performs the following steps: a) The laptopâ€™s non-AP STA performs an active scan by transmitting a Probe Request frame containing the wildcard SSID and an Interworking element with Access Network Type subfield set to â€œPrivate Network with Guest Access.â€ In response, it receives Probe Response frames from several of ACME Manufacturingâ€™s APs, but only one SSID is provided, which is â€œGuest.â€ ACME Manufacturingâ€™s APs did not transmit Probe Responses for the SSIDs â€œEngineeringâ€ and â€œFinanceâ€ since their access network type is â€œPrivate network.â€ b) The Probe Response frame received by the laptop indicated the following capabilities: 1) Extended Capabilities element indicates: AP provides interworking service. 2) Interworking element indicates: Internet is available, venue group = 2 (Business) and venue type = 8 (Research and Development Facility). 3) RSNE indicates: IEEE 802.1X authentication with CCMP-128 pairwise and group cipher suites. c) Since the AP indicated interworking service is available, the laptopâ€™s non-AP STA uses the MLME- GAS.request primitive to invoke GAS to request the Capability List ANQP-element (see 9.4.5.3). In the Capability List ANQP-element, the AP has indicated support for venue name. Upon receipt of the Capability List ANQP-element, the non-AP STA again invokes the MLME-GAS.request primitive to retrieve the venue name. d) The laptopâ€™s UI displays the following information and automatically associates to the network: 1) SSID: Guest (Type: Private network with Guest access) 2) Venue name: ACME Manufacturing, 1234 Main Street, Rownhams, CA 98765-1234 3) Venue type: Research and Development Facility 4) Internet is available e) Upon prompt, the user enters the username and password supplied by his point of contact from ACME Manufacturing and is then able to send and receive email. R.2.5 Museum A visitor enters a museum that is advertising virtual docent service (audio tracks describing each of the major exhibits). The visitor taps an icon on a smartphone and requests it to search for free networks. The smartphone then carries out the following: a) The smartphoneâ€™s non-AP STA performs an active scan by transmitting a Probe Request frame containing the wildcard SSID and an Interworking element with Access Network Type subfield set to â€œFree Public Network.â€ In response, it receives Probe Response frames from several of the 3493 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications museumâ€™s APs, but only one SSID is provided, which is â€œVisitors.â€ The museumâ€™s APs did not transmit Probe Response frames for the SSID â€œMaintenanceâ€ since its access network type is â€œPrivate network.â€ b) The Probe Response frame received by the smartphone indicated the following capabilities: 1) Extended Capabilities element indicates: AP provides interworking service. 2) Interworking element indicates: venue group = 1 (assembly), venue type = 9 (museum), and ASRA = 0 (no additional steps are required for access). c) Since the AP indicated interworking service is available, the smartphoneâ€™s non-AP STA uses the MLME-GAS.request primitive to invoke GAS to request the Capability List ANQP-element (see 9.4.5.3). In the Capability List ANQP-element, the AP has indicated support for venue name. Upon receipt of the Capability List ANQP-element, the non-AP STA again invokes the MLME- GAS.request primitive to retrieve the venue name. d) The smartphoneâ€™s UI displays the following information, asking the user whether they wish to connect to the network: 1) Venue name: Museum of Modern Art (MOMA) 2) SSID: Visitors 3) Venue type: Museum 4) No authentication required e) The user taps the â€œConnectâ€ icon on the smartphoneâ€™s display. Note that the smartphoneâ€™s non-AP STA knows that the network uses Open System authentication since there is no RSNE present in the beacon and ASRA = 0. R.2.6 Emergency call A traveler needs to make an emergency call while in another country. The traveler might not be aware of the emergency call numbers that are used in that country. Being in this new location for the first time, the traveler is not aware of which local access points provide access for emergency calling. (Note that emergency calling requires higher layer application(s) that are outside the scope of this standard.) This is performed as follows: a) The travelerâ€™s non-AP STA performs an active scan by transmitting a Probe Request frame containing the wildcard SSID and an Interworking element. (If the non-AP STA is already associated with an AP that has indicated support for emergency service in its beacon, the probe request would not be necessary.) b) In response, it receives Probe Response frames from one or more APs indicating support for emergency service in the Access Network Options field of the Interworking element. 1) Extended Capabilities element indicates: AP provides interworking service. 2) Emergency services reachability is indicated by the ESR and UESA fields in the Access Network Options field in the Interworking element. 3) A dedicated emergency services network is indicated by the Access Network Type field in the Interworking element. c) The travelerâ€™s non-AP STA then requests the Emergency Call Number ANQP-element with a GAS Initial Request frame. d) The GAS Initial Response frame from the AP provides the Emergency Call Number, for example the sequence of digits â€œ911â€ or an emergency service URN label, URI pair â€œurn:service:sos.fire, tel:112;sip:+15555551002@fire.comâ€ [B46]. e) This information is passed to the higher layer application in the travelerâ€™s non-AP STA. f) The travelerâ€™s non-AP STA then associates with the AP. 3494 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications g) The travelerâ€™s non-AP STA then places the emergency call, with an expedited bandwidth request (EBR) in an ADDTS frame to provide priority to the emergency call. R.2.7 Emergency alert A traveler has enabled the display of emergency alerts on a wireless device (non-AP STA) by appropriately setting the higher layer emergency alert application on the device. The traveler arrives at a new destination and turns on the device. The device, when switched on, will perform a search and then associate with an AP to which the traveler has a subscription or associate with an open AP (if the traveler has enabled the device to do that). During the steps leading up to association, the device, when it becomes aware of an emergency alert, will obtain and display it. The emergency alert will likely be obtained from the AP that has the service to which the traveler has subscribed, but the device might also obtain the emergency alert from other APs, if an AP to which the traveler has a subscription is not available. This is performed as follows: a) The travelerâ€™s non-AP STA performs an active scan by transmitting a Probe Request frame containing the wildcard SSID. If it is associated with an AP, it checks the beacon. b) In response, it receives Probe Response frames from one or more APs, which it checks (or, alternately, checks the beacon) for the subscription and also whether the Emergency Alert element indicates that there are emergency alert message(s). c) If there are one or more emergency alert messages to be downloaded, the Emergency Alert Identifier element provides an Alert Identifier Hash value. d) The device uses the hash of each of the available emergency message(s) to determine whether that message has already been received or whether it is a new message that needs to be downloaded. e) If there are one or more emergency alert messages to be downloaded, the device forms the EAS Message URI by concatenating the Emergency Alert URI with the hexadecimal numerals of the Alert Identifier Hash, using the specified method. f) Should the device be unassociated with an AP when it determines that a new emergency alert is available, it retrieves the EAS message using either GAS procedures with Advertisement Protocol ID field set to the value for EAS. If the device is associated with the AP, it retrieves the EAS message using either GAS procedures with Advertisement Protocol ID field set to the value for EAS or, for example, using HTTP. R.3 QoS mapping guidelines for interworking with external networks R.3.1 General The EDCA and HCCA mechanism defined in 10.22 provide QoS control at the MAC layer. However, the QoS control parameters used by the EDCA and HCCA cannot match directly with other QoS control parameters of the interworked external networks, e.g., SSPN. For example, the SSPN could have different metrics for defining the QoS levels. Destination Network 1 (DN1) and DN2 can use DSCP values differently, in which case, STA1 and STA2 would require different QoS mapping information. Therefore, mapping from these external QoS control parameters to the QoS parameters of this standard is necessary. The QoS parameters mapping can be used for both uplink and downlink data transmission: â€” For uplink: at the non-AP STA, external QoS parameters are mapped to IEEE 802.11 QoS parameters, e.g., DSCP to IEEE 802.11 User Priority and in turn to EDCA ACs. This mapping helps the non-AP STA to construct correct QoS requests to the AP, e.g., the ADDTS Request frame and to transmit frames at the correct priority. â€” For downlink: at the AP, DSCP values are mapped to EDCA UPs. Optionally, the non-AP STA can use TSPEC and TCLAS elements in an ADDTS Request frame to set up a traffic stream in the BSS. 3495 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications In this method, the User Priority is specified in the TCLAS element. The policy used by the AP to choose a specific method to map frames to user priorities is outside the scope of this standard. Different external networks can use different DSCP sets for the same services as described in R.3.3. For example, a 3GPP network can use different code points from that of an enterprise network. The QoS Map distribution mechanism defined in 11.25.9 provides means to communicate to the STAâ€™s mapping informa- tion from the network. R.3.2 Determination of the mapping for a STA The QoS mapping to be applied depends upon the network the non-AP STA is accessing. In an interworking IEEE 802.11 infrastructure setting, the same physical AP can serve non-AP STAs from different SSPNs on different BSSIDs. As such, these STAs are separated into different BSSs. Figure R-1 presents an example of the scenario using authentication, authorization, and accounting (AAA). In Figure R-1, AAA Server 1 controls access to DN-1 and AAA Server 2 controls access to DN-2. DN 1 BSS VLAN Tunnel 1 STA1 AAA AAA Interface AAA STA3 AP DS Client Server 1 STA2 AP Portals VLAN AAA Tunnel 2 Server 2 DN 2 Figure R-1â€”Interworking IEEE 802.11 infrastructure supporting multiple SSPNs R.3.3 Example of QoS mapping from different networks IEEE 802.1D UPs map to EDCA ACs, as described in Table 10-1. The use of DSCP sets differs from network to network. Table R-1 shows examples of DCSP mappings. NOTEâ€”The mapping of the DSCP to 3GPP Traffic Class is available in GSMA, IR.34 v4.6 [B16] (similar to that of GSMA IREG34). See TR 21.905 [B2] for definition of general packet radio service (GPRS) roaming exchange. Table R-1 is extended to cover the EDCA ACs mapping. This mapping can also apply to other networks that adopt the 3GPP QoS definitions, e.g., 3GPP2. 3496 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table R-1â€”Mapping table of DSCP to 3GPP QoS information and EDCA ACs UP EDCA (as in DiffServ QoS Requirement on 3GPP QoS Information DSCP Access IEEE PHB GPRS Roaming Exchange Category Std 802.1D) Traffic Class THP Max Max MSDU MSDU Delay Jitter Loss Error Ratio Conversational N/A EF 101110 20 ms 5 ms 0.5% 10-6 AC_VO 7, 6 Streaming N/A AF41 -6 100010 40 ms 5 ms 0.5% 10 AV_VI 5, 4 Interactive 1 AF31 011010 250 ms N/A 0.1% 10-8 AC_BE 3 -8 2 AF21 010010 300 ms N/A 0.1% 10 AC_BE 3 3 AF11 001010 350 ms N/A 0.1% 10-8 AC_BE 0 -8 Background N/A BE 000000 400 ms N/A 0.1% 10 AC_BK 2,1 Table R-2 shows an example mapping based on application classes defined in IETF RFC 4594. Mapping between DSCP and UP can be done using Exception fields or by range. The use of DSCP Exception fields will map a DSCP to a UP according to Table R-2. Mapping by range will require the setting of DSCP ranges as shown in Table R-3. Table R-2â€”Example Enterprise DSCP to UP/AC mapping IEEE Per-hop 802.1D) Application Class behavior Access Category User (PHB) Priority Network Control CS6 7 AC_VO Telephony EF 6 AC_VO RT Interactive CS4 6 AC_VO Multimedia Conference AF4x 5 AC_VI Signaling CS5 5 AC_VI Broadcast Video CS3 4 AC_VI Multimedia Stream AF3x 4 AC_VI Low Latency Data AF2x 3 AC_BE High Throughput Data AF1x 2 AC_BK OAM CS2 3 AC_BE Standard DF 0 AC_BE Low Priority/Background CS1 1 AC_BK 3497 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Table R-3â€”UP to DSCP range mapping example UP Range DSCP Low DSCP High UP 0 Range 0 0 UP 1 Range 1 9 UP 2 Range 10 16 UP 3 Range 17 23 UP 4 Range 24 31 UP 5 Range 32 40 UP 6 Range 41 47 UP 7 Range 48 63 Furthermore mapping by range will require an additional exceptional element to map DSCP 32 to UP 6. NOTEâ€”Twenty-one DSCP Exception fields are provided to give more flexibility in defining the QoS mapping. This number is equal to the number of FIBs (Forwarding Information Bases) defined by IETF RFC 3222. R.4 Interworking and SSPN interface support R.4.1 General The interworking service architecture defines the scope of the SSPN interface. This interface is provided by the IEEE 802.11 MAC to support the interworking service. In an interworking scenario, the IEEE 802.11 infrastructure is operating in infrastructure mode. Figure R-2 shows an example implementation of the control aspect of the Interworking Interface. As shown in the figure, the Interworking Interface consists of two parts: the generic SSPN Interface between the AP and the AAA Client; and the AAA Interface between the AAA Client and the corresponding AAA Server in the SSPN. Depending on the implementation the AAA Client can be collocated with the AP or stand alone serving as a proxy or translation agent between the SSPN Interface and AAA Interface. The AAA Interface serves as a transparent carrier of the SSPN interface. The possible interactions over the SSPN interface are defined in 11.25.5. The information transferred over the SSPN Interface is defined in R.4.2. This interface results in parameters being set in the dot11InterworkingTable MIB. The APâ€™s SME thereafter uses these parameters to permit or deny, as appropriate, services to non-AP STAs. 3498 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications WLAN System BSS1 Interworking STA1 AP Interface STA2 SSPN AAA SSPN Portal Interface Client AAA DS AAA Server Interface ESS AP STA4 STA3 BSS2 Figure R-2â€”Basic architecture of the interworking service R.4.2 SSPN interface parameters The parameters for each associated non-AP STA defined in this clause cross the SSPN Interface, i.e., between AP and AAA Client as shown in Table R-4. Table R-4â€”SSPN Interface information or permission parameters From AN to From SSPN Per non-AP Information or permission name SSPN to AN STA entry Non-AP STA MAC + + Non-AP STA User ID + + + Non-AP STA Interworking Capability + + Link Layer Encryption Method + + Authorized Priority + + Authorized Rate + + Authorized Delay + + Authorized Service Access Type + + Authorized Service Access Information + + Non-AP STA Transmission Count + + Non-AP STA Location Information + + Non-AP STA State Information + + 3499 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The SSPN Interface parameters are stored in the AP with corresponding MIB attributes as defined in Annex C, and are used by the Interworking Service Management function in the SME. The MIB variables themselves, which are used by the AP SME, are read only. R.4.2.1 Non-AP STA MAC This parameter is the MAC address of the non-AP STA accessing the interworking service through the AP. It can be requested by the external network, e.g., a 3GPP network, for fraud prevention. The non-AP STA MAC address is normally available through MLME SAP, e.g., MLME-ASSOCIATE.indication primitive, and should be forwarded by the AS to the AAA Server entity in the SSPN through the AAA Interface. The following MIB attribute is used: â€” dot11NonAPStationMacAddress R.4.2.2 Non-AP STA User ID This parameter contains the subscriber information of the non-AP STA for the interworking service. It is provided by the non-AP STA through the RSNA establishment process to the AAA Server; in turn, the AAA Server provides it back to the AP via the SSPN interface. It is in the form of an NAI, i.e., it contains both the userâ€™s identity and its SSP information. NOTEâ€”The reason the AAA Server provides the user identity back to the AP is that some EAP methods use encrypted tunnels to maintain confidentiality of the user and thus the AP might not otherwise be able to learn the userâ€™s identity. The following MIB attribute is used: â€” dot11NonAPStationUserIdentity R.4.2.3 Non-AP STA Interworking Capability This parameter is derived from the non-AP STAâ€™s Extended Capabilities element, which is included in (Re)Association Request frames.The AP SME obtains this information from the MLME SAP, e.g., MLME- ASSOCIATE.indication primitive. This information needs to be passed over the SSPN interface since the service authorization decisions can depend on the non-AP STA capabilities. The following MIB attribute is used: â€” dot11NonAPStationInterworkingCapability R.4.2.4 Link Layer Encryption Method This parameter indicates the link layer encryption method selected during the RSNA establishment process for protecting the unicast communication between the non-AP STA and the AP. The cipher suite format of this parameter is drawn from the RSNE defined in 9.4.2.25. The AP obtains this information about the STA via the MLME SAP. In the interworking service, the SSPN also participates in the selection of the cipher suite selection, as described in 11.25.5. Therefore, the link layer encryption method selected will meet or exceed the security requirement of the SSPN. NOTEâ€”In interworking, the SSPN can require visibility and configurability of the STA access. With this information available to the SSPN, the operator would be able to have better control, e.g., barring access to IEEE 802.11 networks if null encryption is used. This is also related to the operator networkâ€™s configuration, e.g., if preauthentication should be supported. 3500 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The following MIB attribute is used: â€” dot11NonAPStationUnicastCipherSuite R.4.2.5 Authorized Priority This parameter is used for admission control and user-priority policing at the AP. It is based on the Infrastructure Authorization Information delivered from the SSPN during the AAA procedure. The Authorized Priority specifies the authorized User Priorities that the non-AP STA is allowed to use during the Interworking access. It also specifies whether the non-AP STA can use HCCA. For EDCA operation, the following MIB attribute is used: â€” dot11NonAPStationAuthAccessCategories MIB attribute after mapping the priority according to Table 10-1. For HCCA operation, the following MIB attribute is used: â€” dot11NonAPStationAuthHCCAHEMM R.4.2.6 Authorized Maximum Rate This parameter is used for admission control decisions or policing actions at the AP. It is based on the Infrastructure Authorization Information delivered from the SSPN during the AAA procedure. For EDCA operation, this parameter contains a list of four MaxRate values indicating the maximum rate allowed for each of the access categories. For HCCA operation, there is one MaxRate value. Each of the MaxRate values is an unsigned integer and in the unit of kilobits per second. An additional value provides the maximum rate at which a non-AP STA can source group addressed frames. The following MIB attributes are used: â€” dot11NonAPStationAuthMaxVoiceRate, â€” dot11NonAPStationAuthMaxVideoRate, â€” dot11NonAPStationAuthMaxBestEffortRate, â€” dot11NonAPStationAuthMaxBackgroundRate, â€” dot11NonAPStationAuthMaxHCCAHEMMRate â€” dot11NonAPStationAuthMaxSourceMulticastRate. R.4.2.7 Authorized Service Access Type This per-non-AP STA parameter indicates the access type allowed for the non-AP STA based on the SSPN decision. The AP will use this information for authorization requests from the STA, e.g., allow or disallow direct link operation and group addressed services. The parameter uses truth values to indicate the service type authorized. The following MIB attributes are used: â€” dot11NonAPStationAuthDls is to authorize a non-AP STA to use DLS â€” dot11NonAPStationAuthMaxSourceMulticastRate is to authorize a non-AP STA to source group addressed stream(s) to toward the network R.4.2.8 Authorized Delay This parameter is used for admission control decisions at the AP. It is based on the Infrastructure Authorization Information delivered from the SSPN during the AAA procedure. This parameter is used only for HCCA operation, and contains one value. An AP should deliver frames to a non-AP STA within the time 3501 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications period specified in this attribute. Furthermore, when a non-AP STA requests admission control, the requested delay is approved only if it is greater than or equal to the value stored in the corresponding parameter. Each parameter is an unsigned integer that measures delay in units of microseconds. The following MIB attribute is used: â€” dot11NonAPStationAuthHCCAHEMMDelay R.4.2.9 Authorized Service Access Information This parameter contains the relevant information for the AP to enforce the authorized service access type indicated in the Authorized Service Access Type parameter. The Authorized Service Access parameters provide the VLAN assignment (VLAN ID and VLAN Name) to which frames to or from the non-AP STA are bridged. The following MIB attributes are used: â€” dot11NonAPStationVLANId â€” dot11NonAPStationVLANName R.4.2.10 Non-AP STA Transmission Count This parameter indicates the count of the data traffic transmitted to and received from a non-AP STA. Such information would be used by the on-line charging and accounting function, especially for the IEEE 802.11 WLAN local service, where the data traffic does not necessarily go through the SSPN network. In such cases, Layer 3 accounting/charging information is not reliable since addresses could be spoofed. Layer 2 would be a better place to collect such information since due to the cryptographic security association that exists between the non-AP STA and AP. The following MIB attributes are used: â€” dot11NonAPStationVoiceMSDUCount, â€” dot11NonAPStationVideoMSDUCount, â€” dot11NonAPStation-BestEffortMSDUCount, â€” dot11NonAPStationBackgroundMSDUCount, â€” dot11NonAPStationHCCAHEMMMSDUCount, â€” dot11NonAPStationMulticastMSDUCount, â€” dot11NonAPStationVoiceOctetCount, â€” dot11NonAPStationVideoOctetCount, â€” dot11NonAPStationBestEffortOctetCount, â€” dot11NonAPStationBackgroundOctetCount, â€” dot11NonAPStationHCCAHEMMOctetCount, â€” dot11NonAPStationMulticastOctetCount MIB attributes R.4.2.11 Non-AP STA Location Information This parameter provides information about the STAâ€™s location to the SSPN. It is required by the SSPN applying location based service control. In the IEEE 802.11 network, the non-AP STA location is approximated using the APâ€™s location information. This parameter includes two type of formats, Geospatial and Civic Location. 3502 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The following MIB attributes are used: â€” dot11APLCITable, â€” dot11APCivicLocationTable R.4.2.12 Non-AP STA State Information This parameter indicates whether the power management mode of the non-AP STA is either active mode or PS mode. The following MIB attributes are used: â€” dot11NonAPStationPowerManagementMode R.5 Interworking with external networks and emergency call support R.5.1 General Emergency services define the IEEE 802.11 functionality to support an emergency call (e.g., E911) service as part of an overall multi-layer solution, specifically capability advertisement and access to emergency services by STAs not having proper security credentials. â€œMulti-layerâ€ indicates that emergency services will be provided by protocols developed in part by other standards bodies; see IETF ECRIT [B25], 3GPP TS 23.167 [B1], and 3GPP TS 22.067 [B3]. Three features of interworking with external networks support emergency call services. The first feature is a mechanism for a non-AP STA to signal to an AP that a call is an emergency call. This is useful in the case where the access category to be used to carry the emergency call traffic (typically AC_VO) is configured for mandatory admission control. If the WLAN is congested, then the AP can deny the TSPEC request for bandwidth to carry the call. However, if the AP is able to determine that the call is an emergency call, then it can invoke other options to admit the TSPEC request. The second and third features provide the means for a client without proper security credentials to be able to place an emergency call. The second feature makes use of the Interworking element, which can be included in Association Request frames in order to bypass the IEEE 802.1X port at an AP for unauthenticated access to emergency services. This is described further in R.5.5. The third feature makes use of an SSID configured for Open Authentication to provide emergency services and is described in R.5.3. The STA has the burden to confirm the availability of emergency services from the IEEE 802.11 network, including that the network is authorized for emergency services. The time it takes for a client to find an authorized emergency services network is related to the speed of forward progress the authorized network can make over the air with the STA, relative to all of the other networks (attackers as well), and is inversely related to the number of false advertisements. A STA can confirm the availability of emergency services by observing the value of the access network type, ESR and UESA fields in the Interworking element of any received Beacon or Probe Response frame. R.5.2 Background on emergency call support over IEEE 802.11 infrastructure Special handling for emergency service calls is required over IEEE Std 802.11. To use a public hotspot a user will go typically through an authentication process (e.g., EAP-based, or http/https redirect or DNS redirection) before being able to use it for emergency calls. 3503 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications There is a need to support these emergency services both when the user has a relationship with the IEEE 802.11 network (credentials to access the network) and when it does not have any relationship with the IEEE 802.11 network. The former case requires no changes to the authentication processâ€”the user, having already been authenticated to and associated with the WLAN, simply dials the emergency number thereby placing the call. In the latter case, the non-AP STA will be able to gain access to the network without using security credentials and make an emergency call. Another difficulty is that once the user gains access to the network, there is no mechanism to prioritize their emergency traffic in the IEEE 802.11 MAC over that of other users, even with IEEE 802.11 QoS capability. Supporting emergency services, such as E911 calling, requires a multi-layer solution with support at various protocol layers. Apart from MAC level access and support for transfer of data between non-AP STA and AP with appropriate QoS at layer 2, there is a clear need, above this layer, to set up the call, conduct call control and management, and use an appropriate audio codec. One specific example is when a user arrives in a new country and needs to make an emergency call in a public hotspot where there is no prior relationship with the available WLAN network or WLAN hotspot operator. NOTEâ€”The callback feature, if required in a regulatory domain, is dealt with at a higher layer. R.5.3 System aspects for emergency call support An IEEE 802.11 infrastructure by itself cannot ensure that all factors are compatible for an emergency service call to actually take place. The client device might have to register with a call manager (SIP agent or some other signaling endpoint) for the call to be placed successfully. Different signaling systems such as SIP, H.323, etc., can be deployed for supporting emergency service calling. Higher layers can also verify an emergency service call is being placed so that appropriate level of resources can be granted to the emergency call. Voice endpoints (e.g., non-AP STAs) can use different codecs such as G.711, AMR, and iLBC. All these functionalities are outside the scope of this standard. IEEE Std 802.11 can provide priority for emergency traffic both for the initial call establishment and during an ongoing emergency call, which assumes advertisement of this functionality supported in the BSS. This subclause describes general design assumptions to support emergency services with IEEE Std 802.11: a) It is assumed that there is a higher layer (above IEEE 802.11 Layer 2) protocol (or protocol suite) for making emergency calls or using any other emergency services. b) In order to make the emergency call procedure work properly, the non-AP STA has the following responsibilities: 1) Recognize the userâ€™s request to make an emergency call. 2) Select an AP that supports QoS and EBR capability. 3) Non-AP STA will associate with the AP if it is not already done so. In an RSN, if the user does not have valid authentication credentials for network access then non-AP STA can bypass the RSN that will provide access to the network to make emergency calls. 4) If location information is required in a particular regulatory domain, request location information from the WLAN. If the STA cannot determine its own location by its own means, then Location information should be obtained from the network prior to initiating the 3504 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications emergency call request. There are two methods a non-AP STA can use to obtain location services from the IEEE 802.11 network: i) If the non-AP STA can use location information in geospatial format (i.e., latitude, longitude and altitude), then the LCI report procedures (11.11.9.6) can be used to obtain this information. The AP advertises its capability for the LCI report procedures by setting the LCI Measurement Capability Enabled field to 1 in the RM Enabled Capabilities field in the RM Enabled Capabilities element, and the non-AP STA transmits an LCI request to the AP. NOTEâ€”The non-AP STA can receive an LCI report with the incapable field set. According to the procedures in 11.11.9.6, the non-AP STA can resubmit an LCI request with a location subject of â€œremote.â€ If the AP still responds with incapable, then location services are not available from the AP via the LCI report procedures. ii) If the non-AP STA requires location information in Civic or geospatial formats, then an APâ€™s wireless network management capability can be used. In this case, an AP advertises its ability to provide its location in Civic or geospatial format by setting the Civic Location or Geospatial Location field in the Extended Capabilities element to 1 respectively in the Beacon frame. A non-AP STA can also request its location using the procedures in 11.25.7. An AP that advertises its ability to provide its location in civic or geospatial format does not return an â€œincapableâ€ response if a requesting STA requests the â€œremoteâ€ location. 5) Selects one of possibly several SSPNs advertising support for emergency services and VoIP service. c) There are two methods described in this annex by which a user lacking security credentials can gain access to the network. The method selected in any particular deployment is at the discretion of the IEEE 802.11 infrastructure provider, SSPN or system administrator as appropriate. The AP and non- AP STA should permit users lacking security credentials to gain access to a network using one of two methods: 1) Using an emergency services association (see 9.4.2.92) in a BSS configured for RSNA. Using this type of association means the AP and non-AP STA will exchange unprotected frames for emergency service access only during the lifetime of the association. In this situation, cryptographic keys are not exchanged, the IEEE 802.1X uncontrolled port is bypassed without invoking the IEEE 802.1X state machine. Since protection is used for authenticated STAs, their traffic is protected. 2) Using an SSID configured for Open System authentication. Network elements necessary to complete an emergency call are reachable via this SSID. How to reach these network elements (e.g., a call manager) and which protocol to use (e.g., SIP) are outside the scope of this standard. d) The AP can separate the backhaul of emergency services traffic from other traffic, typically via a dedicated VLAN. To ease burden of implementation on the network side, some basic means should exist to allow easy filtering, routing and basic access control of â€œregularâ€ BSS traffic and emergency-type BSS traffic. This can be assisted by the downloading of emergency call number information, as described in 9.4.5.5. R.5.4 Description of the Expedited Bandwidth Request element For access categories configured for mandatory admission control, a non-AP STA requests bandwidth using a TSPEC element in an ADDTS Request frame. The TSPEC Request includes parameters describing the characteristics of the traffic stream, but no information on the use of the traffic stream. The Expedited Bandwidth Request (EBR) element describes the â€œuseâ€ of a traffic stream. To use this element, it is the responsibility of the station to transmit this element in response to certain call signaling messages. How this 3505 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications is done is outside the scope for the interworking service. The following bandwidth uses are provided in the EBR element: â€” Emergency call, defined in NENA 08-002 [B56] â€” Public first responder (e.g., fire department) â€” Private first responder (e.g., enterprise security guard) â€” Multi-level precedence and preemption (MLPP) MLPP services are provided by other voice networking technologies such as 3GPP (see 3GPP TS 22.067 [B3]), H.323 (see ITU-T H4.60.14) and other proprietary signaling protocols. MLPP is used as a subscription service to provide differentiated levels of consumer service; it is also used by military organizations so that commanding officers will not get a network busy signal. If the AP is provided additional information regarding the nature of the Traffic Stream, it can invoke additional policy that can be configured on the AP to accept the TSPEC request when it would be otherwise denied. Policy configured at AP defines how bandwidth is allocated. Specification of these policies is outside the scope of interworking with external networks. Policy examples include the following: â€” No action â€” Preemptive action: delete a TS of lower priority if necessary to make room for new TS â€” Use capacity allocated for nonvoice services if priority is above a certain value (assuming TSPEC is for AC_VO) â€” Interpret MLPP codes as defined 3GPP specification â€” Interpret MLPP codes as defined in proprietary specification R.5.5 Access to emergency services in an RSN If an infrastructure BSS requires authentication and encryption with RSN, a non-AP STA placing an emergency call associates and authenticate to the network by using an emergency services association (see 9.4.2.92). If the non-AP STA has user credentials that allow it to use a particular network, the non-AP STA can use its credentials to authenticate to the SSPN through the IEEE 802.11 infrastructure. When a mesh STA has an emergency services association, and it receives a Mesh Peering Open frame that includes the Interworking element, with ASRA bit equal to 1 and UESA bit equal to 0, and the Authenticated Mesh Peering Exchange element (see 9.4.2.118) it allows access to emergency services. If the mesh STA has user credentials that allow the accessing mesh STA to use the mesh network, the mesh STA can use its credentials to authenticate with the accessing mesh peer. In order to use an emergency services association in an infrastructure BSS, a STA lacking security credentials can associate with a BSS in which emergency services are accessible by including an Interworking element with the UESA field set to 1 in a (Re)Association Request frame. An AP receiving this type of (re)association request recognizes this as a request for unauthenticated emergency access. The AP can look up the VLAN ID to use with a AAA Server, or it can have an emergency services VLAN configured. The STA can either have, policies configured locally for quality-of-service parameters and network access restrictions, or it can look them up through external policy servers. When a mesh STA has an emergency services association, and it receives a Mesh Peering Open frame, from a mesh STA lacking security credentials, that includes the Interworking element, with ASRA bit equal to 1 and UESA bit equal to 1, and the Mesh Peering Management element (see 9.4.2.102) it allows access to emergency services. When an emergency services association is used, an infrastructure BSS or an MBSS should be designed to restrict access to emergency services only (or alternatively prioritize the emergency services to the highest level of access). Methods of such restriction are beyond the scope of this standard, but can include an isolated VLAN for emergency services, filtering rules in the AP or network entity (e.g., router) in an 3506 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications external network to limit network access to only network elements involved in emergency calls, and per- session bandwidth control to place an upper limit on resource utilization. R.6 Peer information Peer information allows TDLS peer STAs to discover their capabilities. An example of peer information could be expressed in an XML format as follows: tdls 00-01-02-03-04-05 00-0a-0b-0c-0d-0e < network info> < DHCP> No < IP address>192.168.2.1 < Subnet> 255.255.255.0 myphone The minimum required peer information for TDLS is contained in â€œwireless info.â€ The â€œmac addressâ€ field contains the MAC address of the transmitting STA and the â€œbssidâ€ identifies the BSS in which the STA is a member. The â€œnetwork infoâ€ could optionally be used to aid the peer devices in establishing a TDLS link. R.7 Calculating Estimated Throughput In response to the receipt of MLME-ESTIMATED-THROUGHPUT.request, ESP STAs can determine values for EstimatedThroughputInbound and EstimatedThroughputOutbound for each AC of a current or potential link to another STA using Equation (R-1): EST AirtimeFraction MPDU pPPDU A_MSDU_B 8 EstimatedThroughput = --------------------------------------------------------------------------------------------------------------------------------- - (R-1) PPDU Dur where EstimatedThroughput is in bits/second PPDUDur is the expected duration of a single PPDU, in seconds ESTAirtimeFraction is dimensionless. It is the estimated portion of airtime that is available for outbound transmissions for this link as indicated in the Estimated Service Parameters element received from the STA with the MAC address that matches the PeerMACAddress in the MLME- ESTIMATED-THROUGHPUT.request primitive min(x,y) is the minimum of x and y max(x,y) is the maximum of x and y MPDUpPPDU = min(BA_WIN_Size, max(1,MPDU_pA_MPDU)) BA_WIN_Size = min(BA_WIN_SizeTX,BA_WIN_SizeRX) 3507 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications BA_WIN_SizeTX is the expected block ack window size of the transmitter of the PPDUs containing MPDUs with the Type field equal to Data BA_WIN_SizeRX is the expected block ack window size of the receiver of the PPDUs containing MPDUs with the Type field equal to Data PPDUR MPDU_pA_MPDU = min( ---------------------- PPDUR DataRate - ) - ---------------------------------------------------------------------- MPDU SS MAC Hdr + A_MSDU_B 8 MPDU_pA_MPDU is dimensionless PPDUR = DPDUR â€“ PHDUR PPDUR is the PPDU payload duration, in seconds DPDUR is the Data PPDU duration target of the transmitter of the PPDUs containing MPDUs with the Type subfield equal to Data, in seconds PHDUR is the PHY header duration, estimated based on the expected PPDU format of the PPDUs containing MPDUs with the Type subfield equal to Data, in seconds MPDUSS is the minimum MPDU start spacing of the receiver of the PPDUs containing MPDUs with the Type subfield equal to Data, in seconds MACHdr is the number of octets of MAC header information for an A-MSDU A_MSDU_B = min(A_MSDU_BTX, A_MSDU_BRX) A_MSDU_BTX is the maximum A-MSDU size of the transmitter of the PPDUs containing MPDUs with the Type subfield equal to Data, in octets A_MSDU_BRX is the maximum A-MSDU size of the receiver of the PPDUs containing MPDUs with the Type subfield equal to Data, in octets MAC Hdr + A_MSDU_B MPDU pPPDU 8 PPDU Dur = ------------------------------------------------------------------------------------------------------------- - DSYM DUR + PHDUR DataRate DSYM DUR DSYMDUR is the duration of one PPDU payload symbol for the expected PHY format of the PPDUs containing MPDUs with the Type subfield equal to Data, in seconds. If multiple symbol durations are possible, then the shortest symbol duration is assumed DataRate is calculated using equation Equation (R-2), in b/s NSS_max Ntone- -------------------------------------------- DataRate = min(log 2(1 + SNR_tone) MaxBitsPerSc) (R-2) DSYM DUR where RSSI + P adjust ----------------------------------- 10 SNR_tone = 10 RSSI is the RSSI of Beacon or Probe Response frames received from the STA with the MAC address that matches the PeerMACAddress in the MLME-ESTIMATED- THROUGHPUT.request primitive, in dBm P_adjust is the implementation specific power adjustment parameter used to convert RSSI into SNR, as well as take into account potential transmit power differences between Beacon/Probe Response frames to data frames, in dBm. NSS_max is the maximum number of spatial streams allowed in the link based on the capabilities of the two STAs Ntone is N_SD Ã— N_Seg if the expected PPDU format is VHT, and N_SD otherwise, where N_SD is defined as number of subcarriers in Table 17-16 for non-HT format, NSD in Table 19-6 for HT format and NSD in Table 21-5 for VHT format. If multiple PPDU bandwidths are available, the N_SD of the widest 3508 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications possible PPDU bandwidth allowed between the two STAs based on capabilities is assumed. 40 ------ if 256-QAM 5/6 modulation is allowed in the link 6 MaxBitsPerSc = 6 if 256-QAM 3/4 modulation is allowed in the link but 256-QAM 5/6 modulation is not 5 otherwise Note that some of the parameters of Equation (R-2) have values that are AC dependent. 3509 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Annex S (informative) Mesh BSS operation S.1 Clarification of mesh Data frame format A mesh Data frame consists of MAC header, frame body, and the FCS. The fields in the MAC header are described in 9.2.3. In a mesh Data frame containing a single MSDU, the Mesh Control field is placed immediately before the Data (PDU) in the encrypted Frame Body. The Data (PDU) comprises the LLC/SNAP headers and the higher layer data. This is shown in the example frame format for a CCMP-128-encrypted mesh Data frame containing a single MSDU in Figure S-1. When the mesh Data frame is fragmented, only the first fragment contains the Mesh Control field. 6 or up to Octets: 2 2 6 6 6 2 6 2 4 8 18 2304 8 4 Frame Body Frame Control Duration/ID Address 1 Address 2 Address 3 Address 4 Sequence CCMP Header Mesh Control DATA (PDU) Control Control Control QoS FCS HT MIC MAC Header, Not encrypted Encrypted using CCMP-128 Figure S-1â€”Format of a CCMP-128-encrypted mesh Data frame containing a single MSDU NOTEâ€”A DMG STA does not send mesh Data frames, and all other STAs have a maximum MSDU size of 2304 octets (see Table 9-19). S.2 Operational considerations for interworking S.2.1 Formation and maintenance of the IEEE 802.1D spanning tree No special action is required to support formation of the IEEE 802.1D spanning tree. Spanning tree control messages are typically delivered to bridges in group addressed frames. These messages are Data frames from the point of view of the mesh BSS. 3510 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications S.3 Power save parameters selection S.3.1 General Power save mechanisms enable mesh STA operation in doze state. In doze state a mesh STA might set the transceivers off. The power save mechanism might adjust the mesh power management mode of a mesh STA for various reasons that are beyond the scope of the standard, including but not limited to traffic load or scanning and network maintenance needs. This annex specifies recommendations on how a mesh STA selects mesh power management modes based on traffic load, recommendations on how to do scanning in mesh BSSs that might contain mesh STAs in light or deep sleep mode, and recommended default values for power save related parameters. S.3.2 Selecting the mesh power management mode based on traffic load A mesh STA might adjust its mesh power management mode based on the traffic load or the QoS requirements of the forwarded traffic. If a mesh STA has high traffic load or if a mesh STA is congested, the mesh STA should operate in active mode on the corresponding mesh peering to reduce delays or overhead that might be created by the operation in light or deep sleep mode. A mesh STA might consider staying in active mode for all peer mesh STAs, even if only a single link is congested. When mesh STA operates in active mode, the mesh STA might receive frames at any time and mesh peer service periods might be triggered on demand, as in case of an AP that receives a trigger frame at times controlled by a non-AP STA. If traffic load is moderate or low and best effort data is transmitted, a mesh STA might consider staying in light sleep mode for all or some mesh peerings. The mesh STA in light sleep mode for a mesh peering receives beacons from the peer mesh STA with periodic indication of buffered traffic. If traffic load is low or no traffic is transmitted, a mesh STA might consider staying in deep sleep mode for a mesh peering. The mesh STA does not need to wake up to receive a beacon from the peer mesh STA to which it is in deep sleep mode. The mesh STA might use deep sleep mode to control the number of times it enters the awake state to receive Beacon frame from a peer mesh STA. If the mesh STA is in deep sleep mode for all of its mesh peering, the mesh STA needs only to remain in awake state during its own beacon transmission and mesh awake window. The mesh STA that forwards real time traffic (AC3 or AC2 with EDCA) should be in active mode for the corresponding link. A mesh STA forwarding real time traffic with EDCA might stay in light or deep sleep mode for the corresponding link, if the mesh STA is capable of initiating mesh peer service periods frequently and the other forwarding peer mesh STAs are in active mode. Poor handling of the mesh power management modes might result to delays and inappropriate QoS of the forwarded MSDUs. S.3.3 Scanning of mesh BSSs A mesh BSS might have mesh STAs that alternate awake state and doze state. With active scanning only devices in awake state at the transmission time of Probe Request frame might be found. However, with passive scanning also mesh STAs in light or deep sleep mode for a mesh peering can be found. Since mesh STAs in light or deep sleep mode might transmit beacons at long intervals, a mesh STA seeking for candidate mesh STAs for a new mesh peerings should perform passive scanning relatively for a longer 3511 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications time compared to passive scanning in BSS infrastructure mode. Mesh STAs in light or deep sleep mode with long DTIM interval might not be discovered with short scanning durations. Mesh STAs that operate in light or deep sleep mode for a mesh peering might use a short DTIM interval, if they intend to establish new mesh peerings. S.3.4 Default parameters The following are the recommended default values for power save related parameters for mesh STAs: Table S-1â€”Default parameters for mesh STAs that intend to operate in light or deep sleep mode for mesh peerings For moderate power save For aggressive power save Beacon period 200 TU 800 TU DTIM Period 4 1 Mesh awake window 10 TU 10 TU A mesh STA that is eager to conserve power and likely to remain in deep sleep mode with most of the mesh peerings should utilize the value from aggressive power save parameters. Although mesh STAs might utilize individual parameters regardless of the parameters used by neighbor mesh STAs or peer mesh STAs, each implementer should recognize balance between the power save efficiency and delay in the service initiation. S.3.5 MSDU forwarding in an MBSS containing mesh STAs in light or deep sleep mode The battery powered mesh STAs should avoid forwarding MSDUs, to avoid power consumption and possible additional delays and inefficiencies that power save mechanisms might cause. If a light or deep sleep mode mesh STA forwards MSDUs, it should select its mesh power management mode based on the traffic load and the traffic type as described in S.3.2. A mesh STA might save power by selecting the light or deep sleep mode for a mesh peering as follows: â€” A mesh STA that is â€œmains poweredâ€ might apply light or deep sleep mode if it does not have MSDUs to forward â€” A mesh STA that is â€œbattery poweredâ€ might freely use all mesh power management modes Mesh STAs that are in light or deep sleep mode for a mesh peering might degrade the corresponding link metric value. The use of worse metric values reduces the probability of a link being used for MSDU forwarding. If the mesh STA will operate in active mode for the link in forwarding path, it should apply the link metric value without degradation. S.3.6 Synchronization maintenance of mesh STAs in deep sleep mode A mesh STA in deep sleep mode for a mesh peering might not receive Beacon frames from the corresponding peer mesh STA, but the mesh STA is required to maintain synchronization with the neighbor peer mesh STAs. Neighbor offset synchronization method imposes the maintenance of TSF offset values 3512 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications between neighbor peer mesh STAs, which generally requires the reception of Beacon frame or Probe Response frame. The simplest way to maintain the synchronization is that the mesh STA in deep sleep mode for a mesh peering listens to the corresponding peer mesh STAâ€™s Beacon frame for certain periods and check the TSF offset value. S.4 SIV key wrapping test vector This test vector is from the appendix of IETF RFC 5297. Input: ----- Key: fffefdfc fbfaf9f8 f7f6f5f4 f3f2f1f0 f0f1f2f3 f4f5f6f7 f8f9fafb fcfdfeff Associated Data (ad): 10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627 Plaintext: 11223344 55667788 99aabbcc ddee S2V-CMAC-AES ------------ CMAC(zero): 0e04dfaf c1efbf04 01405828 59bf073a double(): 1c09bf5f 83df7e08 0280b050 b37e0e74 CMAC(ad): f1f922b7 f5193ce6 4ff80cb4 7d93f23b xor: edf09de8 76c642ee 4d78bce4 ceedfc4f double(): dbe13bd0 ed8c85dc 9af179c9 9ddbf819 pad: 11223344 55667788 99aabbcc ddee8000 xor: cac30894 b8eaf254 035bc205 40357819 CMAC(final): 85632d07 c6e8f37f 950acd32 0a2ecc93 CTR-AES ------- CTR: 85632d07 c6e8f37f 150acd32 0a2ecc93 3513 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications E(K,CTR): 51e218d2 c5a2ab8c 4345c4a6 23b2f08f ciphertext: 40c02b96 90c4dc04 daef7f6a fe5c output ------ IV || C: 85632d07 c6e8f37f 950acd32 0a2ecc93 40c02b96 90c4dc04 daef7f6a fe5c S.5 Airtime link metric usage example The airtime cost constants (Table 14-4) and estimates of the average data rate and frame error rate will vary from one implementation and configuration of the IEEE 802.11 PHY and MAC to the other. While no mechanism is defined to measure the average data rate and the frame error rate, numeric values are not expected to exhibit large variations in amplitude over the lifetime of a path. Unstable measurements might cause path selection instabilities. An example of an airtime link metric is provided to illustrate how it might be calculated. Assume a DSSS PHY with an average data rate of 1 Mb/s to a given neighbor and a frame size of 8192 bits. The overhead O for the Data frame comprises the PHY preamble (144 Âµs) and the PHY header (48 Âµs). The payload Bit is 8192 bits at an r of 1 Mb/s, or 8192 Âµs. The data transmission time is therefore 8416 Âµs. Other transmission times for different frame types are calculated in the same way (based on their size, rate, and overhead). If RTS/CTS is used, the data transmission time (including PHY preamble and header) is 8416 Âµs, the RTS transmission time (including PHY preamble and header) is 352 Âµs, the CTS frame transmission time (including PHY preamble and header) is 304 Âµs, the Ack frame transmission time (including PHY preamble and header) is 304 Âµs and the interframe spacing overhead is 390 Âµs. The total time, including overhead, is 9766 Âµs. This airtime and overhead value is converted to units of 0.01 TU (10.24 Âµs), i.e., 953.71 (rounded to 954). If the frame error rate to the neighbor is 0%, the metric is 954. If the frame error rate is 80%, the metric is 4769 (i.e., 953.71/(1â€“0.8), rounded). S.6 Generation of proactive PREP elements in the proactive PREQ mechanism of HWMP S.6.1 General In the proactive PREQ mechanism of HWMP, the generation of a proactive PREP element in response to the receipt of a proactive PREQ element depends on the value of the Proactive PREP subfield in the received proactive PREQ element (see 14.10.4.2). Furthermore, if the Proactive PREP subfield is 0, the mesh STA 3514 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications might respond with the proactive PREP element in case it needs a bidirectional path between the root mesh STA and itself. This is usually the case if the mesh STA has data to be sent to the root mesh STA. This clause provides a unified mechanism that controls the generation of proactive PREP elements in the proactive PREQ mechanism of HWMP. A proactive PREQ element is defined by all of the following: â€” The Target Address is set to all 1s; and â€” The TO subfield in the Per Target Flags field is 1. S.6.2 Additions to forwarding information The forwarding information to a root mesh STA contains two additional Boolean information fields. The Proactive PREP field indicates whether the mesh STA will generate a proactive PREP element to the root mesh STA in response to a proactive PREQ element (Proactive PREP = 1) or not (Proactive PREP = 0). The Proactive PREP Sent field indicates whether the mesh STA has sent a proactive PREP element to the root mesh STA (Proactive PREP Sent = 1) or not (Proactive PREP Sent = 0). Both fields are initialized with 0. S.6.3 Actions when sending Data frames as source mesh STA If a mesh STA receives proactive PREQ elements with the Proactive PREP subfield set to 0, the recipient mesh STA sends a proactive PREP element before sending a Data frame as source mesh STA only if the mesh STA has data to send to the root mesh STA, which requires establishing a bidirectional path with the root mesh STA and the field Proactive PREP Sent of the forwarding information to the root mesh STA is not set (=0). If the mesh STA sends a Data frame as source mesh STA to the root mesh STA, the mesh STA sets the field Proactive PREP of the forwarding information to 1. S.6.4 Actions on receipt of a proactive PREQ element If the mesh STA receives a proactive PREQ element, the field Proactive PREP Sent of the forwarding information to the root mesh STA is set to 0. If the field Proactive PREP of the forwarding information to the root mesh STA is 1, the mesh STA generates a proactive PREP element to the root mesh STA (see 14.10.10.3 Case D), sets the field Proactive PREP of the forwarding information to 0, and sets the field Proactive PREP Sent of the forwarding information to 1. If the Proactive PREP subfield of the Flags field of the received proactive PREQ element is 1, the mesh STA sets the field Proactive PREP of the forwarding information to the root mesh STA to 1. S.6.5 Generation of proactive PREP elements A mesh STA will generate a proactive PREP element according to 14.10.10.3 Case D if one of the following applies: â€” [The mesh STA has received a proactive PREQ element] AND [in the forwarding information to the root mesh STA of the proactive PREQ element, field Proactive PREP is set to 1 AND field Proactive PREP Sent is set to 0]. â€” [The mesh STA has data to send to the root mesh STA, which requires establishing a bidirectional path with the root mesh STA] AND [the field Proactive PREP Sent of the forwarding information to the root mesh STA is not set (=0)]. 3515 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications If the mesh STA generates a proactive PREP to the root mesh STA, the field Proactive PREP Sent of the forwarding information is set to 1 and the field Proactive PREP of the forwarding information is set to 0. S.7 Generation of PREQ elements in proactive RANN mechanism of HWMP S.7.1 General In the proactive RANN mechanism of HWMP, the generation of a PREQ element for root path confirmation in response to the receipt of a RANN element depends on the path metric from the mesh STA to the root mesh STA as computed by the RANN element propagation. However, the RANN mechanism does not set up the necessary forwarding information. This is done with individually addressed PREQ elements. This clause provides further details to the generation of individually addressed PREQ elements in the proactive RANN mechanism of HWMP. An individually addressed PREQ element is defined by the following: â€” The Addressing Mode subfield in the Flags field is 1 (individually addressed). S.7.2 Additions to forwarding information The forwarding information to a root mesh STA contains an additional address field. The RANN element Sender Address field contains the MAC address of the neighbor peer mesh STA that has sent the RANN element with the best metric. S.7.3 Actions when sending Data frames as source mesh STA If the mesh STA sends a Data frame as source mesh STA to the root mesh STA, the mesh STA uses the forwarding information to the root mesh STA. The RANN element Sender Address is not used for forwarding mesh Data frames to the root mesh STA. S.7.4 Actions on receipt of proactive RANN element If the mesh STA receives a proactive RANN element, the field RANN element Sender Address of the forwarding information to the root mesh STA is set to the sender of the RANN element if the metric to the root mesh STA is better than the path metric of the existing mesh path in the forwarding information. In this case, the mesh STA generates an individually addressed PREQ element to the root mesh STAâ€”see 14.10.10.3 Case D (Root Path Confirmation (Original Transmission)). This individually addressed PREQ element is not sent according to the general forwarding information. Instead, it is sent to the neighbor peer mesh STA indicated in the RANN element Sender Address field. Since all mesh STAs between the mesh STA and the root mesh STA have already a value in the RANN element Sender Address field, the individually address PREQ element will eventually reach the root mesh STA. Since the TO subfield in the Per Target Flags field is 1, only the root mesh STA will generate a PREQ element as reply to the individually addressed PREQ element. The individually addressed PREQ elements will set up forwarding information (that can be used for forwarding mesh Data frames) from the root mesh STA toward the mesh STA that initiated the root path confirmation in all intermediate mesh STAs according to the normal HWMP procedures. 3516 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Note, since the PREQ element is sent in an individually addressed frame, every sender of the individually addressed PREQ element will be able to determine whether the next mesh STA toward the root mesh STA has received the PREQ element. The root mesh STA will generate a PREP element according to the normal HWMP proceduresâ€”see 14.10.10.3 Case A (Original Transmission). S.7.5 Actions on receipt of a PREP element The PREP element generated by the root mesh STA will be forwarded on the mesh path from the root mesh STA to the mesh STA as set up by the individually addressed PREQ element. The PREP element will be propagated and will eventually reach the mesh STA. The PREP element will set up forwarding information (that can be used for forwarding mesh Data frames) toward the root mesh STA in the mesh STA that initiated the root path confirmation and in all intermediate mesh STAs on this path according to the normal HWMP procedures. After establishing the forwarding information (mesh path) toward the root mesh STA, the path to the root mesh STA is updated to the better one. Note that since the PREP element is sent in an individually addressed frame, every sender of the PREP element will be able to determine whether the next mesh STA has received the PREP element. 3517 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Annex T (informative) Overlapping BSS (OBSS) management T.1 Introduction When two or more BSSs overlap, the available bandwidth is shared and hence reduced for each BSS. The basic access mechanism, such as DCF, is able to work across OBSSs. Similarly, if EDCA is used, the OBSS might be considered a larger network, and access to the WM is basically shared according to the EDCA access mechanism. Note that for both DCF and EDCA overlapping networks, the sharing is affected by the relative traffic; and if more than two APs are sharing, the problem of â€œneighbor captureâ€ might occur. The neighbor capture effect might occur when a BSS is in the middle of two other BSSs that are hidden from each other, where it might suffer a disproportionate degradation in throughput, relative to the total traffic in all three BSSs. A particular problem arises when there is some expectation of QoS. If EDCA admission control is in use, then it can be used to regulate the QoS traffic on its own BSS, but it might not take into account the EDCA admitted traffic on an OBSS. The result is that the QoS is compromised if each BSS admits traffic up to its local maximum. Similarly a BSS using HCCA might schedule traffic in its own BSS, to â€œguaranteeâ€ a service, but, if not controlled, this might suppress overlapping EDCA admission control BSS. Furthermore, if two HCCA BSSs overlap and they do not coordinate their scheduled TXOPs, then a degradation of QoS might result. The features described in this annex have been introduced in order to allow a degree of management for OBSSs and for mitigation of the basic problems outlined above. T.2 QLoad Report element T.2.1 General The fields and their uses in the QLoad Report element are as follows: â€” Potential Traffic Self field value represents the potential QoS traffic load that this AP is expecting and is provided as an indication to other APs that might be considering selecting the same channel and for sharing when an OBSS situation occurs. The Potential Traffic Self field also includes the peak number of AC_VO and AC_VI EDCA streams. â€” Allocated Traffic Self field value represents the total QoS traffic and the numbers of AC_VI and AC_VO streams that are active at that time. This field is provided to enable an on-demand sharing scheme. It might be used by the other APs in OBSSs to determine if the AP has either overallocated in a proportional sharing scheme or is using an on-demand sharing scheme. â€” Allocated Traffic Shared field contains the sum of the Allocated Traffic Self field values for OBSSs and is used to protect an AP from the neighbor capture effect where an AP that has neighbors that are hidden from each other. It indicates to other APs in OBSSs if this AP has either overallocated in a proportional sharing scheme, or might be using an on-demand sharing scheme. â€” EDCA Access Factor field value represents the total QoS traffic bandwidth requirement for all of the APs in OBSSs and is used to indicate potential overallocation. It also enables a proportional sharing scheme. The Potential Traffic Self fields from QLoad Report elements of nearby co-channel APs are used for estimating the overhead bandwidth required due to EDCA contention and is used in the determination of the EDCA Access Factor. â€” HCCA Peak field value represents the total peak HCCA TXOP requirement for the BSS and is provided so that other overlapping APs can determine whether the AP has overallocated. 3518 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications â€” HCCA Access Factor field contains the sum of all of the HCCA Peak field values in all of the QLoad Reports of all of the overlapping APs, including its own. This value is used when HCCA APs are sharing as defined in 11.28.2. â€” Overlap field value is the number of other APs that are on the same channel and from which Beacon frames are being regularly received. It might be used to aid the channel selection process. T.2.2 Calculating medium time This annex uses the function defined in Equation (T-1) for calculating and estimating medium times in both ACM and non-ACM QoS modes: mediumTime(s,d,m,p) = s Ã—pps Ã— MPDUExchangeTime (T-1) where d - pps = ------------ (T-2) 8 m MPDUExchangeTime = duration(m,p) + SIFS + duration(14,p) (T-3) duration() is the PLME-TXTIME primitive that returns the duration of a frame based on its payload size and the PHY data rate employed. s, d, m and p are parameters that are passed in to the mediumTime function (Also see the definition of MPDUExchangeTime in 10.22.4.2.3.) T.2.3 Calculation of potential traffic self The Potential Traffic Self field value represents the sum of all of the streams derived from all of the potential EDCA admission control and HCCA QoS traffic. The individual TSPEC elements provided by the non-AP STAs are used by the AP to calculate mean, maximum, and minimum values for â€” Medium time, in multiples of 32 Âµs per second, in the case of EDCA admission control â€” HCCA medium time, in the case of HCCA; where HCCA medium time is the TXOP time scheduled by the HC converted to multiples of 32 Î¼s over a 1 s period, by dividing the scheduled TXOP time by the SI that the HC has allocated The AP maintains a tuple that contains the maximum values from Allocated Traffic Self field. The values of this tuple are calculated using a) The mean and standard deviation from the Allocated Traffic Self field that had the largest value of the Mean subfield b) The AC_VO Streams subfield from the Allocated Traffic Self field that had the largest value c) The AC_VI Streams subfield from the Allocated Traffic Self field that had the largest value This tuple is calculated over fixed, consecutive seven-day periods and is reset at the start of each new period. If, at any time, any of the maximum values in the tuple are greater than those in the corresponding subfields of the Potential Traffic Self field, then those fields in the Potential Traffic Self field are set to the value(s) in the tuple. If the AP refuses an ADDTS request due to a perceived overallocation (for example, step b) 4) in the proportional sharing scheme described in T.4.2.2), then the AP adds the TSPEC values of the rejected request to the tuple. 3519 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications At the end of each seven-day period, if any of the maximum values in the tuple are less than those in the corresponding subfields of the Potential Traffic Self field, then those subfields in the Potential Traffic Self fields are set to the value(s) in the tuple. NOTE It is not required that the start and end of the seven-day periods be synchronized across OBSSs. After the first seven-day period, each AP advertises its correct potential load irrespective of its start time. TSPECs provide for mean, maximum, and minimum bit rate values, which allow for statistical multiplexing of streams. The result of summing multiple streams is a composite stream, which should be reported in the Potential Traffic Self field. The summing of streams to produce a composite stream is achieved by using the mean and standard deviation of each stream. The mean (MEAN), maximum (MAX), and minimum (MIN) values of the medium time or HCCA medium time should be calculated using the values provided in the individual TSPECs, as follows: For a TSPEC for stream, i, the mean value, Î¼, is: MINi = mediumTime(Surplus Bandwidth Allowance, Nominal MSDU Size, Minimum Data Rate, Minimum PHY Rate) (T-4) MEANi = mediumTime(Surplus Bandwidth Allowance, Nominal MSDU Size, Mean Data Rate, Minimum PHY Rate) (T-5) MAXi = mediumTime(Surplus Bandwidth Allowance, Nominal MSDU Size, Peak Data Rate, Minimum PHY Rate) (T-6) Î¼i = MEANi (T-7) If the Minimum Data Rate and Peak Data Rate fields were provided in the TSPEC element, Ïƒ is: Ïƒi = 0.25 MAX i â€“ MIN i (T-8) Else if the Peak Data Rate field was provided in the TSPEC element, Ïƒ is: MAX i â€“ MIN i Ïƒi = -------------------------------- - (T-9) 2 Otherwise: Ïƒi = 0 (T-10) When the non-AP STA does not have any active TSPECs, the should AP monitor the mean and maximum frame reception and transmission rates for AC_VI and AC_VO (for example, by regular sampling of changes to dot11QosMPDUsReceivedCount and dot11QosTransmittedFrameCount of each AC) to calculate the potential load information as follows: For a QoS traffic capability, the mean value, Î¼, is: Î¼0 = mediumTime(dot11DefaultSurplusBandwidthAllowance/100, dot11STAStatisticsAverageMSDUSizeVideo, MAXt[VI],dot11STAStatisticsAverageBitrateVideo) (T-11) 3520 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Î¼1 = mediumTime(dot11DefaultSurplusBandwidthAllowance/100, dot11STAStatisticsAverageMSDUSizeVoice, MAXt[VO], dot11STAStatisticsAverageBitrateVoice) (T-12) and the standard deviation, Ïƒ, is: Ïƒ0 = 0 (T-13) Ïƒ1 = 0 (T-14) The values reported in the Potential Traffic Self field represent the composite stream of all of the individual streams of all associated STAs, and this composite stream should be calculated as follows: Potential traffic self mean is: Î¼tot = Î£Î¼i (T-15) Potential traffic self standard deviation: Ïƒtot = 2 (T-16) i T.2.4 Calculation of allocated traffic self The Allocated Traffic Self field value represents the total BSS load of all streams that the AP has allocated at any one time and the number of AC_VI and AC_VO streams that make up that total. The AP should calculate the mean and standard deviation using the Minimum Data Rate, Mean Data Rate, and Peak Data Rate fields of admitted TSPECs and to recalculate the Allocated Traffic Self field value as each TS is added or deleted. The values of the Mean and Standard Deviation subfields placed in the Allocated Traffic Self field for i allocated streams should be calculated using Equation (T-17) to Equation (T-24). MINi = mediumTime(Surplus Bandwidth Allowance, Nominal MSDU Size, Minimum Data Rate, Minimum PHY Rate) (T-17) MEANi = mediumTime(Surplus Bandwidth Allowance, Nominal MSDU Size, Mean Data Rate, Minimum PHY Rate) (T-18) MAXi = mediumTime(Surplus Bandwidth Allowance, Nominal MSDU Size, Peak Data Rate, Minimum PHY Rate) (T-19) If TSPECi has the Minimum Data Rate and Peak Data Rate fields populated, Ïƒ is: Ïƒi = 0.25 MAX i â€“ MIN i (T-20) Else if TSPECi has the Mean Data Rate and Peak Data Rate fields populated, Ïƒ is: MAX i â€“ MEAN i Ïƒi = -------------------------------------- - (T-21) 2 Otherwise: Ïƒi = 0 (T-22) 3521 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Mean = Î£Î¼i (T-23) Standard deviation = 2 (T-24) i When admission control is not used, the AP should monitor the mean and maximum frame reception and transmission rates for AC_VI and AC_VO (for example, by regular sampling of changes to dot11QosMPDUsReceivedCount and dot11QosTransmittedFrameCount of each AC). The MAX, MEAN, and standard deviation (STDEV) at time t for access category AC are as given in Equation (T-25), Equation (T-26), and Equation (T-27). MEANi = o (duration(s, b) + SIFS + duration(14,b)) pt (T-25) MAXt is the maximum value of MEANt since MLME-START.confirm MAX t â€“ MEAN t STDEVt = -------------------------------------- - (T-26) 2 where d p t = ----- dot11QosMPDUsReceivedCount AC + (T-27) dt dot11QosTransmittedFrameCount AC â€“ dot11QosFrameDuplicateCount AC o = dot11DefaultSurplusBandwidthAllowance s = dot11STAStatisticsAverageMSDUSizeVideo b = dot11STAStatisticsAverageBitrateVideo duration() is the PLME-TXTIME primitive that returns the duration of a packet based on its payload size and the PHY data rate employed NOTE The differentiation above calculates the frames per second for the given AC. T.2.5 Calculation of allocated traffic shared The Allocated Traffic Shared field value is the sum of the values expressed in the Allocated Traffic Self fields of all APs in OBSSs, including in its own Allocated Traffic Self field. The values of the mean Î¼ and standard deviation Ïƒ, placed in the Allocated Traffic Shared field, for n OBSSs should be calculated using Equation (T-28) and Equation (T-29). Î¼ = Î£Î¼n (T-28) Ïƒ= 2 (T-29) n T.2.6 Calculation of EDCA Access Factor The EDCA Access Factor is the total traffic requirement for all of the OBSSs. The value of EDCA Access Factor might be greater than 1. The EDCA Access Factor should be calculated from the addition of all of the Potential Traffic Self fields of the APs that are overlapping as follows: 3522 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications First calculate the overlap traffic for all of the APs in OBSSs. Each AP notes the reported Potential Traffic Self fields for every OBSS, including the APâ€™s own Potential Traffic Self field, and calculates the maximum traffic of the composite stream, using Equation (T-30), Equation (T-31), and Equation (T-32). Overlap traffic = Î¼tot + 2 Ïƒtot (T-30) where, for i Potential Traffic Self fields Î¼tot = Î£Î¼i (T-31) Ïƒtot = 2 (T-32) i This overlap traffic value is in multiples of 32 Âµs per second. The following procedure should be used to calculate the EDCA Access Factor: a) Sum the AC_VI and AC_VO priority streams reported in the Potential Traffic Self fields of its own QLoad report and all of the QLoad reports of APs in OBSSs, and determine the EDCA Overhead Factor as recommended in T.2.7. b) Multiply the overlap traffic and the resulting EDCA Overhead Factor together. This value represents the total overlap traffic requirement for the OBSSs in multiples of 32 Âµs per second. c) Convert the total overlap traffic to a fraction (seconds per second) by multiplying by 32 Ã— 10-6. d) Round the resulting fraction value rounded down to a multiple of 1/64. For example, if the total overlap traffic is 74 268 (32 Âµs/s), this is 2.376 576 (seconds/second). Now 2.376 576 Ã— 64 = 152.1 rounded to 152. Hence, the EDCA Access Factor octet, in this case, would be 1001100 (152 in decimal, representing the fraction 152/64). T.2.7 EDCA Overhead Factor The Potential Traffic Self field also includes the number of AC_VI and AC_VO streams that make up the composite stream. The recommended calculation for medium time for an admitted EDCA is given in K.2.2. This value includes the duration of the packet plus SIFS and Ack frame times. The medium time, therefore, does not include the access time. For example, for a single stream, between each transmitted packet, there is a time period due to SIFS, AIFSN, and contention window, and for two or more streams, there is also the time when each packet is delayed while another packet is being transmitted. Hence, in order to calculate the total time or bandwidth required to service multiple EDCA streams, an overhead is present. A fixed value of 1.34 should be used for EDCA Overhead Factor. The value of the EDCA Overhead Factor is dependent upon many factors, including â€” Number and mix of streams, voice and video â€” Mixture of PHY rates and PHYs â€” Mixture of streamsâ€™ data rates â€” Use and mix of aggregated MSDUs â€” Choice of EDCA parameters including different settings in OBSSs Based on a range of simulations, the value of EDCA Overhead Factor is normally in the range 1.26 to 1.43. These simulations, however, were not exhaustive and did not include the effects of hidden nodes and non-IEEE 802.11 interference. 3523 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications T.2.8 Calculation of HCCA Access Factor The HCCA Access Factor should be calculated as follows: a) Sum the HCCA Peak field values in all of the QLoad reports of all of the APs in OBSSs, including its own. b) Convert the total peak traffic to a fraction (seconds per second) by multiplying by 32 Ã— 10-6. c) Round the resulting fraction value to the nearest 1/64 and enter the result into the HCCA Access Factor field. For example, if the total overlap traffic is 74 268 (32 Âµs/s), this is 2.376 576 (seconds/second). Now 2.376 576 Ã— 64 = 152.1 rounded to 152. Hence, the HCCA Access Factor octet, in this case, would be 152 (representing the fraction 152/64). T.3 Channel selection using QLoad report T.3.1 General In addition to the channel selection described below, it is advised that other factors such as traffic from IBSSs, energy from non-IEEE-802.11 systems, and device constraints on the AP or STAs anticipated within the BSS be considered, and regulatory constraints need to be complied with. The most effective mitigation to OBSS is for an AP to operate on channels that are free or that are occupied by another AP that is not fully loaded with QoS traffic. In the absence of a centralized channel assignment algorithm, an AP should use the Overlap and Potential Traffic Self fields of the QLoad Report element as part of its channel selection procedure. An AP might use the Overlap field and Potential Traffic Self field information when deciding the best channel to select. If there are sufficient channels for an AP to find a channel with no other APs within range, then an AP is advised to select one of them. When selecting a channel, the AP should scan to see whether there is a free channel taking account of BSS channel width and channel spacing. If a free channel is not available, then it is advised to select channels that have the least number of QoS APs present. There might be more than one channel with the same number of QoS APs present. At this point, the AP is advised to select, in turn, the candidate channels and send a QLoad Request frame to each AP on that channel. The AP is advised to examine the Overlap and Potential Traffic Self fields of the QLoad Report element to make its final selection. T.3.2 AP with admission control mandatory If no â€œemptyâ€ channels are available, then an AP with the ACM (admission control mandatory) bit in the EDCA Parameter Set element set for AC_VI or AC_VO should implement a channel selection procedure to share with one or more APs, in the following preference order: a) Non-QoS AP where the EDCA Parameter Set element is not present in the Beacon frame b) QoS AP with the ACM bit set for AC_VI or AC_VO and with an indication of support for QLoad reporting (i.e., the QLoad Report field equal to 1 in the Extended Capabilities element) c) QoS AP with an HC and with an indication of support for QLoad reporting (i.e., the QLoad Report field equal to 1 in the Extended Capabilities element) d) QoS AP with an HC and with no indication of support for QLoad reporting e) QoS AP with the ACM bit set for AC_VI or AC_VO and with no indication of support for QLoad reporting 3524 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications f) QoS AP where the EDCA Parameter Set element is present in the Beacon frame and the ACM bit is not set for AC_VI or AC_VO T.3.3 AP with an HC If no â€œemptyâ€ channels are available, then an AP with an HC should implement a channel selection procedure to share with one or more APs, in the following preference order: a) Non-QoS AP where the EDCA Parameter Set element is not present in the Beacon frame b) QoS AP where the EDCA Parameter Set element is present in the Beacon frame and the ACM bit is not set for AC_VI or AC_VO c) QoS AP with the ACM bit set for AC_VI or AC_VO and with an indication of support for QLoad reporting (i.e., the QLoad Report field equal to 1 in the Extended Capabilities element) d) QoS AP with an HC and with an indication of support for QLoad reporting (i.e., the QLoad Report field equal to 1 in the Extended Capabilities element) e) QoS AP with the ACM bit set for AC_VI or AC_VO and with no indication of support for QLoad reporting f) QoS AP with an HC and with no indication of support for QLoad reporting T.3.4 Channel selection procedures Channel selection should be performed as follows: a) Create a list of the available channels. Typically this is the list of channels allowed by regulation in the operating regulatory domain; however, this list might be modified by management policy (e.g., removing overlapping channels, avoiding radar detect channels). b) Create an array for each available channel that allows the recording of the QoS AP count, ACM bit count, HC count, overlap count, and potential load for that channel. c) Step through the list of available channels, listening for beacons for at least dot11OBSSScanPassiveTotalPerChannel TUs per channel. d) Upon completion of the scan of a channel, process the beacons received on that channel, filtered to the set of unique BSSIDs: 1) Using the capabilities signaled in the beacon, modify the QoS AP count, ACM bit count, HC count, overlap count, and potential load of the channel array for the primary channel indicated in the received beacon. 2) If the AP is using a channel bandwidth that is greater than the channel spacing (e.g., when using the 2.4 GHz band or when the overlapping AP allows 40 MHz HT PPDUs in its BSS), also update the channel array for channels that are affected by this OBSS. For example, a beacon received on channel 2 indicating a 20 MHz BSS also affects channels 1, 3, and 4. e) Upon completion of scanning all of the channels, the AP has information on the number of APs and the potential load of each channel, including co-channel BSSs. f) If the channel array indicates that there are channels with no other APs, one of these â€œemptyâ€ channels should be chosen randomly. g) Otherwise, create a list of candidate channels by selecting only the channels with the lowest number of QoS APs. For example, if the channel scan procedure indicated that there were two QoS APs on channel 3, three QoS APs on channel 6, and two QoS APs on channel 11, the list of candidate channels would contain 3 and 11. 1) If this list contains one or more channels with non-QoS APs, then filter the list for the least number of APs. 2) If this list contains more than one channel, one of these channels should be chosen randomly. 3525 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications h) If this list contains more than one channel and the AP has been configured to set the ACM bit for AC_VI or AC_VO: 1) Filter the list for the minimum count of QoS AP where the EDCA Parameter Set element is present in the Beacon frame and the ACM bit is not set for AC_VI or AC_VO. 2) If this list contains more than one channel, filter the list for the minimum count of QoS AP with the ACM bit set for AC_VI or AC_VO and with no indication of support for QLoad reporting. 3) If this list contains more than one channel, filter the list for the minimum count of QoS AP with an HC and with no indication of support for QLoad reporting. 4) If this list contains more than one channel, filter the list for the minimum count of QoS AP with an HC and with an indication of support for QLoad reporting (i.e., the QLoad Report field equal to 1 in the Extended Capabilities element). 5) If this list contains more than one channel, filter the list for the minimum count of QoS AP with the ACM bit set for AC_VI or AC_VO and with an indication of support for QLoad reporting (i.e., the QLoad Report field equal to 1 in the Extended Capabilities element). i) If this list contains more than one channel and the AP has an HC: 1) Filter the list for the minimum count of QoS AP with an HC and with no indication of support for QLoad reporting. 2) If this list contains more than one channel, filter the list for the minimum count of QoS AP with the ACM bit set for AC_VI or AC_VO and with no indication of support for QLoad reporting. 3) If this list contains more than one channel, filter the list for the minimum count of QoS AP with an HC and with an indication of support for QLoad reporting (i.e., the QLoad Report field equal to 1 in the Extended Capabilities element). 4) If this list contains more than one channel, filter the list for the minimum count of QoS AP with the ACM bit set for AC_VI or AC_VO and with an indication of support for QLoad reporting (i.e., the QLoad Report field equal to 1 in the Extended Capabilities element). 5) If this list contains more than one channel, filter the list for the minimum count of QoS AP where the EDCA Parameter Set element is present in the Beacon frame and the ACM bit is not set for AC_VI or AC_VO. j) If this list contains more than one channel, filter the list to the set of channels with the minimum overlap count. k) If this list contains more than one channel, filter the list to the set of channels with the minimum potential load. l) From the remaining channels in this list, randomly choose one of these channels. T.4 Sharing in an OBSS situation T.4.1 General If the EDCA Access Factor is greater than one, then there is a potential overallocation of the WM. APs should avoid overallocation in the channel selection process, but if overallocation exists, then a sharing scheme should be used to provide each AP with a fair share of the bandwidth, but more importantly, so that any already admitted or scheduled QoS streams are not impaired by the addition of streams from any OBSS. The EDCA Access Factor, HCCA Access Factor, and Potential Traffic Self fields in the QLoad Report element are provided to enable sharing schemes to be used. The sharing scheme also protects an AP from the neighbor capture effect where it has neighbors that are hidden from each other. A major objective of an OBSS sharing scheme is that if a QoS stream is allocated or scheduled, then it is not compromised by the addition of further streams from any OBSS that would cause the medium to be overallocated. This objective is achieved if the APs in OBSSs cooperate. 3526 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications T.4.2 Sharing schemes T.4.2.1 General Two sharing schemes are suggested: proportional sharing and on-demand sharing. In each sharing scheme, the purpose is to keep the total allocated traffic to a value where overallocation does not occur. The absolute maximum allocation is 1 s/s (100%). In the following descriptions of the two suggested sharing schemes, this value is referred to as the maximum allocation value (MAV). It is suggested that in order to provide some protection to non-QoS traffic, each AP select a value for MAV: MAV = (M + 1)/(M + N + 1) s/s (T-33) where M is the number of overlapping APs that are robust AV streaming STAs N is the number of overlapping APs that are not robust AV streaming STAs There is no requirement that each AP select the same MAV. T.4.2.2 Proportional sharing scheme The proportional sharing scheme described in this subclause is an example of a static sharing policy, as described in Table 9-226 and 11.28.2.2. When using the proportional sharing scheme, the AP examines the sum of the EDCA Access Factors and HCCA Access Factors in the QLoad reports from each OBSS, including its own Qload report, and determines the maximum. This maximum value is termed the combined access factor. If the maximum value from the combined access factor is less than or equal to MAV, the AP is advised to allocate only up to its advertised potential traffic self traffic. If the maximum value from the combined access factor is greater than MAV, then the AP is advised to allocate only up to a value of its potential traffic self divided by the combined access factor, multiplied by MAV. In the proportional sharing scheme, before an AP allocates a new medium time or schedules a new TXOP in response to an ADDTS Request frame, it checks that this addition does not exceed its sharing limit, as follows: a) If the EDCA Access Factor is less than or equal to MAV, then the AP allocates up to its advertised potential traffic self, with the composite stream (MAX traffic) calculated as shown in Equation (T-34). MAX traffic = Î¼tot + 2 Ïƒtot (T-34) b) If the EDCA Access Factor is greater than MAV, the AP carries out the following: 1) Calculate the peak traffic value of the potential traffic self using Equation (T-35). Peak = Î¼tot + 2 Ïƒtot (T-35) 2) Divide this value by the combined access factor and multiply by MAV. This value is termed the maximum allowable potential traffic self traffic. 3) Calculate the resulting value of the allocated traffic self if the new TSPEC is accepted, as explained in Equation (T.2.4), and then calculate the resulting peak value using Equation (T-36). Peak = Î¼tot + 2 Ïƒtot (T-36) 3527 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications 4) If the resulting peak value, calculated in step 3), is greater than the maximum allowable potential traffic self traffic, then the AP is advised to reject the ADDTS Request frame. 5) If the resulting peak value, calculated in step 3), is less than the maximum allowable potential traffic self traffic and the ADDTS Request frame is set for EDCA admission, then the AP is advised to accept the request. 6) The AP then checks that it is possible to schedule TXOPs using the HCCA TXOP advertisement as described in Equation (11.28.3). If the new stream is allocated, then the AP updates the appropriate fields in its QLoad Report element. T.4.2.3 On-demand sharing scheme The on-demand sharing scheme described in this subclause is an example of a dynamic sharing policy, as described in Table 9-226 and 11.28.2.2. The on-demand sharing scheme is as follows: a) Before allocating a new stream, the AP examines the Allocated Traffic Shared field values in the QLoad reports from each OBSS, including its own Qload report, and selects the maximum Allocated Traffic Shared field value that has the highest peak value, using Equation (T-37). Peak = Î¼tot + 2 Ïƒtot (T-37) The AP also notes the number of AC_VI and AC_VO streams in this maximum Allocated Traffic Shared field. b) The AP adds the requested new stream (new) to the selected maximum Allocated Traffic Shared field value (max) determined in step a), using Equation (T-38) and Equation (T-38). Î¼ = Î¼new + Peak (T-38) Ïƒ= 2 + 2 (T-39) new max c) The AP then calculates the peak value for the new composite stream calculated in step b), using Equation (T-40). Peak = Î¼ + 2Ïƒ (T-40) d) Using the values of the AC_VI and AC_VO streams noted in step a), plus the stream represented by the new stream, the AP determines the new EDCA Access Factor and then the combined access factor, as described in T.4.2.2. e) Multiply the peak value calculated in step c) by the EDCA Access Factor, determined in step d). This value is the new peak traffic requirement. f) If this peak traffic requirement value calculated in step e) is greater than MAV, then the AP is advised to refuse to allocate the new stream. g) If the peak value calculated in step e) is less than or equal to MAV and the new allocation is for an EDCA admission ADDTS, then the AP allocates that new traffic. h) If the peak value calculated in step d) is less than or equal to MAV and the new allocation is for an HCCA ADDTS, the AP checks that it is possible to schedule TXOPs using the HCCA TXOP advertisement as described in 11.28.3. If the new stream is allocated, then the AP updates the appropriate fields in its QLoad Report element. 3528 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications The Allocated Traffic Self field in the QLoad Report element of a particular AP can be used by other APs as an indication of whether an AP has overallocated or is using an on-demand sharing scheme. If, using either the proportional or on-demand sharing schemes, an AP determines that the acceptance of a TSPEC would exceed the available allocation, or if a non-AP STA has a TSPEC refused, the non-AP STA could always request a new TSPEC that represents a lower medium time or TXOP. This request might be used, for example, where the non-AP STA or AP has the ability to send a more compressed stream. An AP might choose to use the on-demand sharing scheme until the maximum value of any access factor field in the QLoad Report elements from each OBSS reaches MAV. Once this condition has occurred, the AP could then use the proportional sharing for subsequent ADDTS requests. T.5 Mitigating consequences of OBSS sharing in presence of noncollaborating devices The performance of the channel selection and HCAA TXOP negotiation procedures described in this annex and 11.28 might become degraded by the presence of devices that willfully or accidentally behave in an uncooperative manner. It is suggested that implementations use additional heuristics (e.g., a history of collaboration, traffic monitoring, device configuration, or a combination of such) to assess the accuracy of the information they receive from neighboring APs in order to determine an appropriate collaboration strategy. An AP that maintains historical information of collaboration results with its neighboring APs could use this information to control its collaboration behavior. For example, an AP might choose to share a channel with an AP that had a history of successful collaboration. In another example, an AP might choose to avoid transmissions only during the HCCA TXOPs of neighboring APs with which it has a history of successful HCCA TXOP negotiation. When using HCCA TXOP negotiation, it is suggested that an AP perform some monitoring of the channel to assess whether the HCCA AP with which it is collaborating is using its advertised HCCA TXOPs. If the monitoring AP does not detect HCCA traffic during these advertised HCCA TXOPs, such a lack of traffic might indicate that the neighboring AP is willfully or accidentally behaving in an uncooperative manner by advertising HCCA TXOPs that it is not using, possibly as a method to suppress traffic in neighboring BSSs. The monitoring AP might wish to ignore the HCCA TXOP advertisements from APs that do not appear to be collaborating. Some of the OBSS procedures use unauthenticated Beacon frames and Public Action frames, which are susceptible to impersonation. If unauthenticated Beacon frames and Public Action frames are used, an AP might suffer a denial of service attack by another device impersonating the AP. This denial of service attack, due to the actions of the impersonating device, might cause neighboring APs to falsely ascertain the AP is not collaborating. An AP could enable protected HCCA TXOP negotiation and protected QLoad reporting to provide protection against impersonation. The AP PeerKey protocol is used in the generation of the PMK to prove that an AP has the private key that corresponds to its public key. Impersonation of protected HCCA TXOP negotiation and protected QLoad report management from an AP is prevented while the AP maintains possession of this private key and this private key is not possessed by any other devices. 3529 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Annex U (informative) Functions of the centralized coordination service root (CCSR) Via unspecified means over the DS, a centralized coordination service root (CCSR) performs the following functions: â€” Allows APs to enroll or unenroll from the CCSS. â€” Provides a directory service, wherein the CCSR responds to a directory service request that includes a MAC address with an indication of whether the MAC address is an S-AP within the CCSS. â€” Configures the beacon interval, ClusterMaxMem, Beacon SP duration, TXSS offset, TXSS CBAP duration, and TXSS CBAP MaxMem (see 10.37.2.2) of each S-AP. â€” Aligns the rate of increment of TSFs of S-APs within the CCSS. â€” Configures the individual TSF offsets of each S-AP in order to minimize the temporal, spatial, and frequency overlap of BHIs of the BSSs in the same CCSS. â€” Provides to each S-AP the cluster time offset availability information from nearby co-channel S-APs. â€” Configures each S-AP with certain medium access policies for its centralized AP or PCP cluster (see 10.37.3.4). The CCSR is permitted to configure different S-APs with different medium access policies. â€” Configures each S-AP with a list of one or more channels in an operating class that the S-AP is excluded from operating upon and that the S-AP advertises via the Channel Usage procedures (see 11.24.15). The excluded channels are available to STAs that are operating in the area covered by the ECAPC, yet are not within the ECAPC. 3530 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Annex V (informative) TSPEC aggregation for DMG BSSs Examples of TSPEC aggregation include, but are not limited to, the following: â€” Traffic streams between DMG STA A and DMG STA B, having an access policy of SPCA, even if they flow in opposite directions, sharing an SP allocation created with DMG STA A as Source AID and DMG STA B as Destination AID. â€” Traffic streams between DMG STA A and other DMG STAs, having an access policy of EDCA, even if they flow in opposite directions (some having DMG STA A as source and some having DMG STA A as destination), sharing a CBAP allocation created with DMG STA A as Source AID and broadcast Destination AID. Figure V-1 and Figure V-2 show examples of TSPEC aggregation in a DMG BSS. Note that TSPEC 3 in Figure V-1 (for both SPCA and EDCA cases) can flow only through an RD grant. STA A STA B TSPEC 1 Destination AID: B TSPEC 3 Access Policy: SPCA Destination AID: A (Service Period Channel Access) Access Policy: SPCA (Service Period Channel Access) SP Allocation TSPEC 2 Source AID: A Destination AID: B Destination AID: B Access Policy: SPCA (Service Period Channel Access) â€”TSPECs are added and deleted in any order, without losing the allocation â€”Allocation admission is by the AP or PCP; flow admission is performed by the flow endpoints STA A STA B TSPEC 1 Destination AID: B TSPEC 3 Access Policy: EDCA Destination AID: A (Contentionâ€based channel access) Access Policy: EDCA (Contentionâ€based channel access) CBAP Allocation TSPEC 2 Source AID: A DMG Destination AID: C Destination AID: broadcast STA C Access Policy: EDCA (Contentionâ€based channel access) Figure V-1â€”Example of TSPEC aggregation (SPCA and EDCA access policies) 3531 Copyright Â© 2016 IEEE. All rights reserved. IEEE Std 802.11-2016 IEEE Standard for Information Technologyâ€”Local and Metropolitan Area Networksâ€”Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications STA A STA B TSPEC 1 Destination AID: B TSPEC 4 Access Policy: SPCA Destination AID: A (Service Period Channel Access) Access Policy: SPCA SP Allocation (Service Period Channel Access) TSPEC 2 Source AID: A Destination AID: B Destination AID: B Access Policy: SEMM (SPCA, EDCA mixed mode) CBAP Allocation CBAP Allocation TSPEC 3 Source AID: A Source AID: broadcast Destination AID: C Destination AID: broadcast Destination AID: broadcast Access Policy: EDCA (Contentionâ€based channel access) STA C Figure V-2â€”Example of TSPEC aggregation (SPCA, EDCA, and SEMM access policies) 3532 Copyright Â© 2016 IEEE. All rights reserved. *&&& TUBOEBSETJFFFPSH 1IPOF 'BY Ã*&&&